Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
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
Summary: RFE: As a gettext-based project maintainer I don't want to have to worry abou...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Zanata
Classification: Retired
Component: Component-UI
Version: unspecified
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 1.6.1
Assignee: Ding-Yi Chen
QA Contact: Ding-Yi Chen
URL:
Whiteboard:
Depends On: 729522
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-12 09:22 UTC by Akira TAGOH
Modified: 2012-11-06 02:34 UTC (History)
4 users (show)

Fixed In Version: 1.6.1-SNAPSHOT (20120606-0019)
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-03 05:27:47 UTC

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 716789 0 unspecified CLOSED RFE: "project create" from command-line should auto-create the zanata.xml file 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 729522 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Bugzilla 807113 0 medium CLOSED Review Request: zanata-util - Helper scripts for using Zanata 2021-02-22 00:41:40 UTC

Internal Links: 716789 729522 807113

Description Akira TAGOH 2011-08-12 09:22:32 UTC 
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-15 02:53:42 UTC 
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 04:33:13 UTC 
Assigning to Scrum product owner for prioritisation.
Comment 3 Ding-Yi Chen 2011-09-09 03:52:04 UTC 
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 05:58:16 UTC 
Assigned to Runa for prioritization.
Comment 5 Ding-Yi Chen 2012-04-11 04:16:17 UTC 
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 04:08:45 UTC 
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 05:35:48 UTC 
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.