Bug 1156236 - RFE: As a project maintainer, I want to be able to use the latest list of languages defined in the server for a project when using the client.
Summary: RFE: As a project maintainer, I want to be able to use the latest list of lan...
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Zanata
Classification: Retired
Component: Component-zanata-client, Component-zanata-client-ivy   
(Show other bugs)
Version: development
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: 3.7
Assignee: Patrick Huang
QA Contact: Damian Jansen
URL:
Whiteboard:
Keywords:
: 1194439 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-23 23:40 UTC by Carlos Munoz
Modified: 2015-07-23 04:12 UTC (History)
9 users (show)

Fixed In Version: 3.7.0-SNAPSHOT (git-jenkins-zanata-server-github-pull-requests-2918)
Doc Type: Bug Fix
Doc Text:
Story Points: 5
Clone Of:
Environment:
Last Closed: 2015-07-22 02:19:50 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 831887 None None None Never
Red Hat Bugzilla 961185 None None None Never

Internal Trackers: 831887 961185

Description Carlos Munoz 2014-10-23 23:40:36 UTC
Project maintainers would like to keep their language codes in zanata.xml in sync with the Zanata server. A command line client command that allows them to synchronize the information stored on the server (initially just locales, but maybe later could include project type, etc) with their local zanata.xml would be of great value.

(Originally requested for OpenStack's workflow)

Comment 1 Isaac Rooskov 2014-11-05 05:19:19 UTC
Notes from evaluation meeting:

As a project maintainer I do not want to add languages to zanata.xml myself

- Do maintainers wish to do all their configuration in the local xml file or just from the command line?

- sync means merge or just update from server to client?



Implementation for Sprint 14.12:

- Implement REST service to fetch locales from server with ability to specify mappings 

- Client to use up-to-date locale list from server instead of local zanata.xml, with warning that locale list in zanata.xml is deprecated



Extra feature to come into the future (out of scope for this story):

- Add client commands to add locale to a project or list locales available

Comment 2 David Mason 2014-11-12 03:40:27 UTC
Notes from additional developer meeting:

Clarified implementation to try, and decided on the following approach:

 - allow maintainers to specify locale mappings in the language list for a project and project-version
 - ensure there is a REST endpoint to fetch the list of enabled locales for a project-version, with appropriate behaviour for mapped locales.
 - order of precedence for locales during push and pull in the client should be (from highest to lowest):

    1. locales specified on the command line
    2. locales fetched from the server
    3. locales in zanata.xml

 - <locales> in zanata.xml will still be supported (as a fallback)
 - zanata init will no longer add <locales> to zanata.xml
 - downloaded zanata.xml from the server will no longer include <locales>

 - this does not include any pushing of locales from zanata.xml to the server
 - this does not include any writing of locales from the server to zanata.xml

Comment 3 Patrick Huang 2015-01-09 02:06:26 UTC
RE: order of precedence for locales during push and pull in the client should be (from highest to lowest):
    1. locales specified on the command line
    2. locales fetched from the server
    3. locales in zanata.xml

How are we going to do with locales in zanata.xml exactly? If a locale in zanata.xml differ from what's on the server, there are a few scenarios:

 1. server doesn't have this locale -> we should ignore this entry and give warning (we give warning to having locales in the file already)

 2. server has this locale but don't have a map-from -> we should use the map-from in zanata.xml (?)

 3. server has this locale but have a different map-from -> use server value and give warning (although a more thorough implementation may be try both and see which one can find translation files)

 4. server has map-from but zanata.xml doesn't -> use server's value

I am not sure about scenario 2. It seems to be the only case where locales in zanata.xml can be used. Otherwise no use at all!

Comment 4 Carlos Munoz 2015-01-09 02:29:06 UTC
The client should definitely warn when a locale list in zanata.xml is present as a reminder to switch to the new way of doing things.

As for locales, and reading the notes above, if the locales are specified on the xml, then these are the ones to use (+ the warning). There is no need to look at it on a locale-per-locale basis, it's an all or nothing thing.

We are keeping support for locales in zanata.xml for backwards compatibility, so if a project has moved to the new way of configuring locale aliases, they also need to make sure their zanata.xml is correct. This is why Zanata will stop adding locales on the generated zanata.xml

Comment 5 Patrick Huang 2015-01-09 02:51:39 UTC
(In reply to Carlos Munoz from comment #4)
> The client should definitely warn when a locale list in zanata.xml is
> present as a reminder to switch to the new way of doing things.
> 
> As for locales, and reading the notes above, if the locales are specified on
> the xml, then these are the ones to use (+ the warning). There is no need to
> look at it on a locale-per-locale basis, it's an all or nothing thing.
> 
> We are keeping support for locales in zanata.xml for backwards
> compatibility, so if a project has moved to the new way of configuring
> locale aliases, they also need to make sure their zanata.xml is correct.
> This is why Zanata will stop adding locales on the generated zanata.xml

Then the order of precedence for locales will become (from highest to lowest):
    1. locales specified on the command line
    2. locales in zanata.xml
    3. locales fetched from the server
(swap 2 and 3)

Comment 6 Carlos Munoz 2015-01-09 03:03:36 UTC
I hadn't noticed the difference in the order. But you are right, as there is no way the client can know if the locales offered by the server are intentionally unaliased or not.

Comment 7 Sean Flanigan 2015-02-24 01:37:47 UTC
The name of this bug is nothing like the implementation.  Where's the pull request for that anyway?

Comment 8 Michelle Kim 2015-02-25 06:35:56 UTC
*** Bug 1194439 has been marked as a duplicate of this bug. ***

Comment 9 David Mason 2015-03-02 01:32:32 UTC
Server changes: https://github.com/zanata/zanata-server/pull/651
Client changes: https://github.com/zanata/zanata-client/pull/48 (depend on server changes)

Comment 10 Damian Jansen 2015-03-04 03:14:59 UTC
Verified merge (master) at bcb2e36ef8cd3847b3f54836addcd07ec28d7d75


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