Hide Forgot
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:
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.
Assigning to Scrum product owner for prioritisation.
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.
Assigned to Runa for prioritization.
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.
VERIFIED with Zanata version 1.6.1-SNAPSHOT (20120606-0019) and as well as zanata-util-0.2.7
I still have these issues with older version which is actually deployed. Hope to see new version in use as early as possible.