Bug 824200 - RFE: Add the ability to specify custom locales that are not enabled by default.
Summary: RFE: Add the ability to specify custom locales that are not enabled by default.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Zanata
Classification: Retired
Component: Component-Logic, Component-UI, Usability
Version: 1.6-SNAPSHOT
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 1.6
Assignee: Carlos Munoz
QA Contact: Joyce Chang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-23 00:39 UTC by Carlos Munoz
Modified: 2013-03-04 03:19 UTC (History)
4 users (show)

Fixed In Version: verified in Zanata version 1.6.0-beta-2-SNAPSHOT (20120531-0020).
Doc Type: Bug Fix
Doc Text:
Cause Certain projects need to define their own specific languages only for their use. Consequence Zanata only allows for a given set of languages to be specified, and they will be visible by all projects. Change Zanata now allows for a free-form language entry which allows system admins to define their own languages under certain restrictions: 1. Zanata must be able to determine plural information for the language. 2. No duplicate language names. 3. If there is a similar language already registered, Zanata will warn the admin about this but will allow them to proceed if needed. Zanata will also allow languages to be "enabled by default". This means that a language will be visible by all projects (unless the project has its own custom language list). Result Admins can now add languages that will not be visible to all projects by default. Individual projects can override their language list and add these languages if they are required, but all projects with a default language list will not see them.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-22 00:58:04 UTC
Embargoed:
sflaniga: needinfo-


Attachments (Terms of Use)

Description Carlos Munoz 2012-05-23 00:39:22 UTC
Admin users should be able to add any locale that they wish, provided that plural information can be determined for it. Locales can also be "disabled by default" which means that only projects which specifically ask for the locale will be able to see it.

Comment 1 Carlos Munoz 2012-05-24 03:24:04 UTC
Added a new property on languages called 'enabled by default'. This property determines whether a language is enabled for projects that don't specifically define languages. 

The language manager screen has changed a bit, allowing to control the 'enabled by default' and 'active' properties using checkboxes and asking for a confirmation before changes. Also added visual highlighting to non-active languages for an easier to read screen.

Replaced the drop down box when creating a new language on the server by a text field. The text field should allow any language name to be entered and suggest options while typing. 

The server will validate the following on the typed language name:
That the language name is valid (i.e won't get rejected by the server, for example 'en-')
That there is plural form available for the language name.
That there are no underscores ('_') in the language name. If this is the case, the server will offer to correct the name automatically.

In addition to these validations, the server will also warn if there are similar language names already registered in the server (such as 'en-US' and 'en-us') but will not prevent the user from creating the language in that case.

Comment 3 Joyce Chang 2012-05-31 01:44:31 UTC
> 
> In addition to these validations, the server will also warn if there are
> similar language names already registered in the server (such as 'en-US' and
> 'en-us') but will not prevent the user from creating the language in that
> case.


This functionality may cause a situation where admins can accidentally a locale in different cases, for example, admin can create JA where ja already existed. If different cases are allowed, it will confuse new translators wheather choose JA or ja to join in.

Comment 4 Carlos Munoz 2012-05-31 01:57:45 UTC
I agree with this, but there are some scenarios where we don't want to restrict the creation of the language. The warning is there in case the admin user is not aware that another language already exists with a similar name, but we are leaving the option open for the user to be able to create it if it is needed.

Comment 5 Joyce Chang 2012-05-31 02:56:06 UTC
verified in Zanata version 1.6.0-beta-2-SNAPSHOT (20120531-0020).

Comment 6 Carlos Munoz 2012-06-06 01:36:20 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause
Certain projects need to define their own specific languages only for their use. 

Consequence
Zanata only allows for a given set of languages to be specified, and they will be visible by all projects.

Change
Zanata now allows for a free-form language entry which allows system admins to define their own languages under certain restrictions: 1. Zanata must be able to determine plural information for the language. 2. No duplicate language names. 3. If there is a similar language already registered, Zanata will warn the admin about this but will allow them to proceed if needed.

Zanata will also allow languages to be "enabled by default". This means that a language will be visible by all projects (unless the project has its own custom language list).

Result
Admins can now add languages that will not be visible to all projects by default. Individual projects can override their language list and add these languages if they are required, but all projects with a default language list will not see them.


Note You need to log in before you can comment on or make changes to this bug.