Bug 730237

Summary:	RFE: As a gettext-based project maintainer I don't want to have to worry about locale mapping when importing a package to Zanata
Product:	[Retired] Zanata	Reporter:	Akira TAGOH <tagoh>
Component:	Component-UI	Assignee:	Ding-Yi Chen <dchen>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Ding-Yi Chen <dchen>
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	pnemade, sflaniga, sshedmak, zanata-bugs
Target Milestone:	---	Keywords:	Improvement, UserStory
Target Release:	1.6.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	729522
Bug Blocks:

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.