This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 730237 - RFE: As a gettext-based project maintainer I don't want to have to worry about locale mapping when importing a package to Zanata
RFE: As a gettext-based project maintainer I don't want to have to worry abou...
Status: CLOSED CURRENTRELEASE
Product: Zanata
Classification: Community
Component: Component-UI (Show other bugs)
unspecified
Unspecified Unspecified
high Severity high
: ---
: 1.6.1
Assigned To: Ding-Yi Chen
Ding-Yi Chen
: Improvement, UserStory
Depends On: 729522
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-12 05:22 EDT by Akira TAGOH
Modified: 2012-11-05 21:34 EST (History)
4 users (show)

See Also:
Fixed In Version: 1.6.1-SNAPSHOT (20120606-0019)
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-03 01:27:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Akira TAGOH 2011-08-12 05:22:32 EDT
Description of problem:
Importing po files with zanata.xml that genereated with the default languages fails in some case. that prevents smooth transition to zanata. I really hope the default value in zanata.xml or the project configuration on web UI should has more accurate values for gettext on zanata.xml. or let the project owner/maintainers to ask which facilities the project uses.

Version-Release number of selected component (if applicable):
1.3

How reproducible:
always

Steps to Reproduce:
1.create version with the default languages
2.install zanata.xml on the project root
3.zanata po push --import-po on po dir
  
Actual results:
a) error: Can not find the translation for eu
b) error: Can not find the translation for bn-BD
c) error: Can not find the translation for es-ES
d) error: Can not find the translation for de-DE
e) error: Can not find the translation for sr-Cyrl
f) error: Can not find the translation for zh-Hant-TW
g) error: Can not find the translation for zh-Hans-CN
h) error: Can not find the translation for ta-IN
i) error: Can not find the translation for pt-PT
j) error: Can not find the translation for sr-Latn

Expected results:
a) should import or fallback to eu_ES
b) should import or fallback to bn
c) should import or fallback to es
d) should import or fallback to de
e) should import or fallback to sr
f) should import or fallback to zh_TW
g) should import or fallback to zh_CN
h) should import or fallback to ta
i) should import or fallback to pt
j) should import or fallback to sr@latin

Additional info:
Comment 1 Sean Flanigan 2011-08-14 22:53:42 EDT
If I understand correctly, this is about a mismatch between the server-side locales (eu, bn-BD, es-ES, etc) and the client-side .po files (eu_ES, bn, es, etc).  

At present, the only mechanism for handling this mismatch is to edit zanata.xml on the client to provide mappings, eg:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<config xmlns="http://zanata.org/namespace/config/">
    <url>http://localhost:8080/zanata/</url> 
    <project>sample-project</project> 
    <project-version>1.1</project-version>
    <locales>
        <locale map-from="eu_ES">eu</locale>
        <locale map-from="bn">bn-BD</locale>
        <locale map-from="es">es-ES</locale>
        <locale map-from="de">de-DE</locale>
        <locale map-from="sr">sr-Cyrl</locale>
        <locale map-from="zh_TW">zh-Hant-TW</locale>
        <locale map-from="zh_CN">zh-Hans-CN</locale>
        <locale map-from="ta">ta-IN</locale>
        <locale map-from="pt">pt-PT</locale>
        <locale map-from="sr@latin">sr-Latn</locale>
    </locales>
</config>

This works, but it is fairly painful, considering it may have to be done once for each project.  (It would probably help if we at least provided some sample mappings as a comment when generating zanata.xml)

We should consider overhauling the way we map client-side locales to server-side locales, perhaps by moving it to the server, or possibly we could do away with mapping and implement some sort of intelligent locale grouping instead.  Such a  grouping would need to handle language teams and also translation statistics.  

That's just a couple of ideas, we should consider a lot more.  And we should try to find an easier way to reduce the problem in the meantime.
Comment 2 Sean Flanigan 2011-09-07 00:33:13 EDT
Assigning to Scrum product owner for prioritisation.
Comment 3 Ding-Yi Chen 2011-09-08 23:52:04 EDT
One of the intermediate goal can be: 

Zanata clients output the locale that the server currently support.

Such as:

zanata locale

Returns:
eu
bn-BD
es-ES
de-DE
zh-Hant-TW
zh-Hans-CN

From here, scripting monkeys like us can workout the generation of zanata.xml.
Comment 4 Ding-Yi Chen 2011-11-08 00:58:16 EST
Assigned to Runa for prioritization.
Comment 5 Ding-Yi Chen 2012-04-11 00:16:17 EDT
BTW, I have made a set of utilities, zanata-util, which address some thing like this. 

Specifically, use following command to generate zanata.xml you want.
zanata_zanata_xml_make -m -p gettext <ZanataServerUrl> <ProjectId> <VersionId>

zanata-util has passed package review, and is now in test repositories for rawhide, f17, f16, el6 and el5.
Comment 6 Ding-Yi Chen 2012-06-06 00:08:45 EDT
VERIFIED with Zanata version 1.6.1-SNAPSHOT (20120606-0019)

and as well as zanata-util-0.2.7
Comment 7 Parag Nemade 2012-07-03 01:35:48 EDT
I still have these issues with older version which is actually deployed. Hope to see new version in use as early as possible.

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