ILanguageManager should be exposed as a REST resource

Bug #1414298 reported by Sumana Harihareswara on 2015-01-24
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNU Mailman
Undecided
Unassigned
Postorius
Undecided
Unassigned

Bug Description

Expose ILanguageManager as a REST resource, so that Postorius can use it to learn what languages a system supports, and thus provide list administrators with options for a list's preferred language. Refer to src/mailman/model/docs/languages.rst -- I imagine this will probably use a getUtility call to say,

  getUtility(ILanguageManager)

Background, based on my conversation with Barry yesterday (I may have gotten some things wrong):

The system knows it supports certain languages. This is set in a config file that only the site administrator can change -- a change in the config file requires a mailman restart in order to take effect. The Language Manager is per system.

The Language Manager is a utility, like the user manager (that is, essentially a singleton in the system; interfaces that have multiple implementations are not utilities). When the system boots up, it registers implementations of interfaces. These are ZopeInterfaces, as we use the Zope component architecture, ZCA.

Sumana Harihareswara (sumanah) wrote :

Also affects Postorius.

Once this is implemented in the REST API, change Postorius forms.py so it calls the API to ask that question when a list administrator is setting up a new list or changing preferences for a list, instead of hardcoding English as the only choice for the list's preferred language.

tags: added: i18n mailman3-suite-blocker

On Jan 24, 2015, at 01:42 PM, Sumana Harihareswara wrote:

>Expose ILanguageManager as a REST resource, so that Postorius can use it
>to learn what languages a system supports

Since languages must be enabled in the config files, they are system
resources, so they should probably live under the <api>/system/languages
resource, which would be read-only. GETing that would return the collection
of languages as resource entries. Individual languages could be GET'd via
their code, e.g. <api>/system/languages/it

Each language resource would return a JSON representation containing the code,
charset, and description. See ILanguage for that specification.

(Even though ILanguageManager supports .add(), exposing this to the API
doesn't make them persistent so I don't think POST, PATCH, or PUT should be
exposed in the REST API on that resource.)

Changed in mailman:
assignee: nobody → Sumana Harihareswara (sumanah)
Sumana Harihareswara (sumanah) wrote :

I am marking this as unassigned so that someone else can pick it up and work on it if they want, since it's unfair to hold on to it for two weeks without making progress on it; if I am able to pick it back up and work on it then I will assign it to myself once more.

Changed in mailman:
assignee: Sumana Harihareswara (sumanah) → nobody
Barry Warsaw (barry) wrote :

Actually, I've marked this Fixed Released, since this information is now available under the <api>/system/configuration path. Look for subresources that start with "language.<code>".

Changed in mailman:
status: New → Fix Released
Florian Fuchs (flo-fuchs) wrote :

This needs to be added to mailman.client. Here's the bug report:

https://bugs.launchpad.net/mailman.client/+bug/1444185

Sumana Harihareswara (sumanah) wrote :

Since Mailman Suite 3.0 will not be fully translatable, I've removed this from the mailman3 suite blockers. Let's target this for Postorius 1.1 and Mailman Suite 3.1.

tags: removed: mailman3-suite-blocker
Abhilash Raj (raj-abhilash1) wrote :

This bug has been moved to the new gitlab repo here: https://gitlab.com/mailman/postorius/issues/14

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers