Bug 1156236
| Summary: | 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. | ||
|---|---|---|---|
| Product: | [Retired] Zanata | Reporter: | Carlos Munoz <camunoz> |
| Component: | Component-zanata-client, Component-zanata-client-ivy | Assignee: | Patrick Huang <pahuang> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Damian Jansen <djansen> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | development | CC: | dchen, djansen, lyz, me, noriko, pahuang, sflaniga, yshao, zanata-bugs |
| Target Milestone: | --- | ||
| Target Release: | 3.7 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Carlos Munoz
2014-10-23 23:40:36 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 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
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!
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 (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) 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. The name of this bug is nothing like the implementation. Where's the pull request for that anyway? *** Bug 1194439 has been marked as a duplicate of this bug. *** Server changes: https://github.com/zanata/zanata-server/pull/651 Client changes: https://github.com/zanata/zanata-client/pull/48 (depend on server changes) Verified merge (master) at bcb2e36ef8cd3847b3f54836addcd07ec28d7d75 |