Description of problem: Letting project maintainer specify the source locale has following benefit: 1. It is clear to see what is the source locale, especially for non-English source projects. 2. Source locale will not be shown as translatable languages in web UI, so translators will not waste their time on it. 3. Source locale will not be shown in zanata.xml, so using client won't treat source locale as translation. Expected results: 1. Project maintainer should be able to specify the source locale in project and version create and edit pages. 2. Default source locale should be en_US.
This would also affect the upload features, since HDocuments have a locale attribute. It would make sense to check that the HDocument locale matches the project's source locale, and warn if they are different.
Couldn't we rather have a mechanism to say "you're translating the source locale for this document - would you rather 1-1 copy the whole document for this locale instead?" to which it would just copy all of the untranslated targets from the source... ? Is there a use case for a document that the source locale translation targets may differ from the source locale?
For the source locale, we should copy the source to translation and make it read only. At least from a user perspective. I would think we would not allow maintainers to choose the source language as translation language in the first place. But maybe the first option would cover all use cases.
(In reply to Damian Jansen from comment #2) > Couldn't we rather have a mechanism to say "you're translating the source > locale for this document - would you rather 1-1 copy the whole document for > this locale instead?" to which it would just copy all of the untranslated > targets from the source... ? Say, if the source document is written by ja_JP and want to translate to other languages. In our current UI, how do you tell Zanata ja_JP is the source locale? In client we have --src-lang, but nothing in web UI. (In reply to Luke Brooker from comment #3) > For the source locale, we should copy the source to translation and make it > read only. At least from a user perspective. > > I would think we would not allow maintainers to choose the source language > as translation language in the first place. But maybe the first option would > cover all use cases. I would prefer source language is list (so people won't complain about "why no ja_JP"), but mark as source language thus not translatable.
*** Bug 1199316 has been marked as a duplicate of this bug. ***
In order to i18n doc project, it would make sense that English file to be attached allowing translators to localize. A project owner should be responsible to provide a source file attached with a English file when creating a project. In the Revision History of the book, it can state that the non-english source file has been translated into English by whom for i18n purpose. Example from Fedora, Spanish community wished to publish a book for Fedora and brought the idea to fedora-docs and fedora-trans. In order to make a book translatable for others, the book first was translated into English by fedora-trans-es (part of Spanish community) and then published as well uploaded to Transifex.
In Zanata, we do have a way to display a reference language in addition to source language. For example, if the source language is Spanish, and English translation is completed. Translators can 1. go to translation editor 2. click "Editor option" (the gear icon), this should open the editor option panel 3. In editor option panel and choose en-US as reference language. You should now see English translation shown right under the source text in the row you selected and editing.
Created attachment 999713 [details] zh-TW translator reference zh-CN Screenshot for zh-TW translator reference zh-CN
Confirmed with Noriko that Ding's solution is good, hence I am closing this bug as it satisfies the need for the use cases where non-English sources are pushed to zanata, package maintaner and translator would be able to choose en_US as a reference language.
Wait, what I have shown Noriko is workaround, to make this feature complete, we at lest need 1. UI to specify source locale in WebUI 2. UI to show the non-Engligh source locale in project page 3. UI to show the non-Engligh source locale in project-version page 4. (Optional) UI to show that non-English project in project list.