[yast-devel] new translation server and YaST
We are now working on a launch of a new translation server: https://l10n.opensuse.org/ We just added first few projects, but we plan to migrate all translations there after the beta phase. Benefits: No more need for picking pot from GitHub, uploading it to LCN SVN, waiting, picking translations back. Weblate is built on top of GIT, and translation can be automatically uploaded to GIT. Imagine that openSUSE LCN SVN has projects, where nobody picked translations for 7 years! Weblate features translation merge across branches. We can create common translation covering both SLE and openSUSE. No more divergences in translations. The only work on developers side is (in the current version) updating of po files against the latest pot and pushing it to the git repo. (And even it can be automatized in future.) What will be needed before YaST can be added to Weblate: 1) Decide how YaST will manipulate with po files. Currently all po files for all repositories reside in a single repository (and later in a single package). It was useful in time of manual downloads and uploads, where no -lang package merging was implemented. Now it will complicate fully automatic work flow, as pot files needs to be transferred across repositories (at least until somebody invents a robot for it). 2) Decide how YaST will accept translations. Standard way is an automatic pushing of translations to git using rules defined by Weblate (currently 100% reached or no changes in last 2 hours) by dedicated user (opensuse-i18n). I was pointed to the problem that YaST developers may need to review some strings and edit their test suites. I guess that there can be techniques that can help with watching of such special changes. But in general, I think that developers have no chance to review translations. Another way is pull request (GitHub only). With pull requests, developers will get pull request on each change mentioned above. Pull request could possibly add a lot of work to you. Imagine, that 50 modules with 16 languages can generate nearly 1000 pull requests in on translation round. Third way is manual pulling from the Weblate on request. I would avoid this as much as possible. If you update po files in GitHub, you will get conflict, and problem would need manual git merge. 3) Have cleanly defined branch for SLE (and possibly other projects). I guess it is already done in a such way: All projects, where translations are maintained in parallel for different versions, need to have branch in the repository. Weblate will then be able to push the correct po file to each branch. 4) Merge openSUSE and SLE translations. openSUSE and SLE translations diverged over the time, as there is no merging process. Translation team agreed on merge of both. The merge is planned to be performed on Weblate side: 3a) GitHub will import openSUSE translations. 3b) Weblate will import SLE translations as change suggestions. 3c) Translators will be asked to perform review. 3d) The standard process will post merged translations to GitHub. Technical details: Steps that need to be done on import to Weblate: 1. The last import from LCN SVN trunk branch will be done. 2. po and pot files will be removed from LCN SVN trunk branch. 3. These translations will be pushed to GitHub (one shot). 4. Weblate web service (in GitHub webhooks) will be added to each project configuration. 5. opensuse-i18n robot will be allowed to push to your project (not needed in case of pull requests) 6. Project will be imported to l10n.opensuse.org 7. master branch will be added to that project 8. The last import from LCN SVN SLE branches. 9. po and pot files will be removed from LCN SVN SLE branches. 10. Particular SLE branches will be added to that project. 11. These translations will be added to Weblate as suggestions. 12. Translators will be asked for review and string merge. 13. When the merge will happen, robot will push merged translations to GitHub. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Mon, 12 Oct 2015 22:23:39 +0200 Stanislav Brabec <sbrabec@suse.com> wrote:
We are now working on a launch of a new translation server: https://l10n.opensuse.org/
We just added first few projects, but we plan to migrate all translations there after the beta phase.
Benefits:
No more need for picking pot from GitHub, uploading it to LCN SVN, waiting, picking translations back. Weblate is built on top of GIT, and translation can be automatically uploaded to GIT. Imagine that openSUSE LCN SVN has projects, where nobody picked translations for 7 years!
Weblate features translation merge across branches. We can create common translation covering both SLE and openSUSE. No more divergences in translations.
That sounds good in general, but SLE translations is done by external company and openSUSE ones by community, so question is if both agreed on it. In general YaST will use whatever translators find comfortable.
The only work on developers side is (in the current version) updating of po files against the latest pot and pushing it to the git repo. (And even it can be automatized in future.)
This is also what we do for svn, so I do not see difference.
What will be needed before YaST can be added to Weblate:
1) Decide how YaST will manipulate with po files. Currently all po files for all repositories reside in a single repository (and later in a single package). It was useful in time of manual downloads and uploads, where no -lang package merging was implemented. Now it will complicate fully automatic work flow, as pot files needs to be transferred across repositories (at least until somebody invents a robot for it).
YaST just generate pot files and upload to svn. Then it is up to ke how it is proceed further.
2) Decide how YaST will accept translations.
Standard way is an automatic pushing of translations to git using rules defined by Weblate (currently 100% reached or no changes in last 2 hours) by dedicated user (opensuse-i18n). I was pointed to the problem that YaST developers may need to review some strings and edit their test suites. I guess that there can be techniques that can help with watching of such special changes. But in general, I think that developers have no chance to review translations.
I do not expect that developers will review translations.
Another way is pull request (GitHub only). With pull requests, developers will get pull request on each change mentioned above. Pull request could possibly add a lot of work to you. Imagine, that 50 modules with 16 languages can generate nearly 1000 pull requests in on translation round.
no way for us. We have more then 100 modules.
Third way is manual pulling from the Weblate on request. I would avoid this as much as possible. If you update po files in GitHub, you will get conflict, and problem would need manual git merge.
YaST team in general do not care about translations, just fixing non-translatable strings and similar issues.
3) Have cleanly defined branch for SLE (and possibly other projects).
I guess it is already done in a such way:
yes, see https://yastgithubio.readthedocs.org/en/latest/maintenance-branches/#mainten...
All projects, where translations are maintained in parallel for different versions, need to have branch in the repository. Weblate will then be able to push the correct po file to each branch.
4) Merge openSUSE and SLE translations.
openSUSE and SLE translations diverged over the time, as there is no merging process. Translation team agreed on merge of both.
if translation team want to merge it, we are fine with it.
The merge is planned to be performed on Weblate side:
3a) GitHub will import openSUSE translations. 3b) Weblate will import SLE translations as change suggestions. 3c) Translators will be asked to perform review. 3d) The standard process will post merged translations to GitHub.
Technical details:
Steps that need to be done on import to Weblate:
1. The last import from LCN SVN trunk branch will be done. 2. po and pot files will be removed from LCN SVN trunk branch. 3. These translations will be pushed to GitHub (one shot). 4. Weblate web service (in GitHub webhooks) will be added to each project configuration. 5. opensuse-i18n robot will be allowed to push to your project (not needed in case of pull requests) 6. Project will be imported to l10n.opensuse.org 7. master branch will be added to that project 8. The last import from LCN SVN SLE branches. 9. po and pot files will be removed from LCN SVN SLE branches. 10. Particular SLE branches will be added to that project. 11. These translations will be added to Weblate as suggestions. 12. Translators will be asked for review and string merge. 13. When the merge will happen, robot will push merged translations to GitHub.
In general I do not see problem with these steps. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Josef Reidinger <jreidinger@suse.cz> writes:
That sounds good in general, but SLE translations is done by external company and openSUSE ones by community, so question is if both agreed on it.
Yes, the technical aspect is easy. The tough part is to evaluate the differences and take a decision agreed by all parties.
YaST just generate pot files and upload to svn. Then it is up to ke how it is proceed further.
Translations done by contracted vendors (coordinated by Shane and Padraig in Dublin) are to be used on SLE products. These translations will also be used on Leap because Leap inherits the yast2-trans package from SLE 12 SP1. From the SVN trunk branch (aka factory translations), I'll add translations of those languages that are not done by the vendors. -- Karl Eichwalder SUSE Linux GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 13.10.2015 09:40, Josef Reidinger wrote:
The only work on developers side is (in the current version) updating of po files against the latest pot and pushing it to the git repo. (And even it can be automatized in future.)
This is also what we do for svn, so I do not see difference.
Someone still needs to run `create pot file for $this repository`, but this can be automated quite "easily", for instance, in Jenkins. I already have a script that can generate all pot files for all Yast repositories at once, also considering that not all Yast repositories need to have the "latest" branch, especially SLE 11 might have, e.g. only `SP2` branch, and nothing "younger".
1) Decide how YaST will manipulate with po files. Currently all po files for all repositories reside in a single repository (and later in a single package). It was useful in time of manual downloads and uploads, where no -lang package merging was implemented. Now it will complicate fully automatic work flow, as pot files needs to be transferred across repositories (at least until somebody invents a robot for it).
YaST just generate pot files and upload to svn. Then it is up to ke how it is proceed further.
Yes, but IIUC - now these translations are expected to be pushed to Yast repositories automagically from the server, which is actually no way from my POV. Currently, there are no pot/mo/whatever files in Yast repos.
2) Decide how YaST will accept translations.
Standard way is an automatic pushing of translations to git using rules defined by Weblate (currently 100% reached or no changes in last 2 hours) by dedicated user (opensuse-i18n). I was pointed to the problem that YaST developers may need to review some strings and edit their test suites. I guess that there can be techniques that can help with watching of such special changes. But in general, I think that developers have no chance to review translations.
I do not expect that developers will review translations.
Agree
Another way is pull request (GitHub only). With pull requests, developers will get pull request on each change mentioned above. Pull request could possibly add a lot of work to you. Imagine, that 50 modules with 16 languages can generate nearly 1000 pull requests in on translation round.
no way for us. We have more then 100 modules.
+1 but Code Review process is currently mandatory for ALL YAST REPOS.
Third way is manual pulling from the Weblate on request. I would avoid this as much as possible. If you update po files in GitHub, you will get conflict, and problem would need manual git merge.
YaST team in general do not care about translations, just fixing non-translatable strings and similar issues.
And I would like this to keep the same. But what would be actually acceptable (for me) is to create ${yast_module}-translation repository anywhere at GitHub (be it under SUSE/openSUSE/yast) for every single Yast repository ... or even one repository yast-translations. We would then grant RW access to your auto-user to this/these repo(s) and we could automagically update pot files generated from code.
Steps that need to be done on import to Weblate:
3. These translations will be pushed to GitHub (one shot).
You might want to keep the history, in this case, my team might still have some tools for SVN2GIT conversion...
5. opensuse-i18n robot will be allowed to push to your project (not needed in case of pull requests)
Yes, if we talk about a special repository for translations with special rules: no review needed. Thanks for taking care and also for contacting the team in advance Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Lukas Ocilka <lukas.ocilka@suse.com> writes:
Someone still needs to run `create pot file for $this repository`, but this can be automated quite "easily", for instance, in Jenkins.
I already have a script that can generate all pot files for all Yast repositories at once, also considering that not all Yast repositories need to have the "latest" branch, especially SLE 11 might have, e.g. only `SP2` branch, and nothing "younger".
I'm fine with changing, but I'm not fine with changing procedures that affects products already done (only if behlert would approve it). This means that SLE 11 SPx and SLE 12 (SP0) translation updates -- if needed -- should be done as usual (submitting pot files to the SVN, translating, and then packaging yast2-trans). The same applies for SLE 12 SP1. [for the future: the less work for me, the better.] -- Karl Eichwalder SUSE Linux GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 13.10.2015 v 16:53 Karl Eichwalder napsal(a):
Lukas Ocilka <lukas.ocilka@suse.com> writes:
Someone still needs to run `create pot file for $this repository`, but this can be automated quite "easily", for instance, in Jenkins.
I already have a script that can generate all pot files for all Yast repositories at once, also considering that not all Yast repositories need to have the "latest" branch, especially SLE 11 might have, e.g. only `SP2` branch, and nothing "younger".
I'm fine with changing, but I'm not fine with changing procedures that affects products already done (only if behlert would approve it).
This means that SLE 11 SPx and SLE 12 (SP0) translation updates -- if needed -- should be done as usual (submitting pot files to the SVN, translating, and then packaging yast2-trans). The same applies for SLE 12 SP1.
There is no plan to migrate in SLE11 and SLE12SP < 2. It is unsure even in case of future SLE12 SP2. openSUSE Leap 42 will probably inherit translations from SLE12 (GA or SP1), probably with exception of Release Notes, which are already migrated, and its Leap version never appeared in LCN SVN. It depends on result of future translation merge. Whichever it will be, it will surely bring some changes in translations, possibly including terminology change. I am not sure, whether we will want it for SLE12 SP2. Managers will decide in future, depending on feedback of the new translations and processes. But we would like to get it to SLE13. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 13.10.2015 v 16:42 Lukas Ocilka napsal(a):
On 13.10.2015 09:40, Josef Reidinger wrote:
The only work on developers side is (in the current version) updating of po files against the latest pot and pushing it to the git repo. (And even it can be automatized in future.)
This is also what we do for svn, so I do not see difference.
Someone still needs to run `create pot file for $this repository`, but this can be automated quite "easily", for instance, in Jenkins.
Yes, it is already part of many automated tasks, even a part of make dist of many projects, "make update-po" target etc. Now you will not need to pick pot, submit it elsewhere, then check and submit translations back. And the best thing: New po files will appear in the git repo as soon as translator completes it.
I already have a script that can generate all pot files for all Yast repositories at once, also considering that not all Yast repositories need to have the "latest" branch, especially SLE 11 might have, e.g. only `SP2` branch, and nothing "younger".
Yes, YaST already maintains this in scripts. Problems appear especially outside YaST, where nobody picks translations back for years.
1) Decide how YaST will manipulate with po files. Currently all po files for all repositories reside in a single repository (and later in a single package). It was useful in time of manual downloads and uploads, where no -lang package merging was implemented. Now it will complicate fully automatic work flow, as pot files needs to be transferred across repositories (at least until somebody invents a robot for it).
YaST just generate pot files and upload to svn. Then it is up to ke how it is proceed further.
Yes, but IIUC - now these translations are expected to be pushed to Yast repositories automagically from the server, which is actually no way from my POV. Currently, there are no pot/mo/whatever files in Yast repos.
Weblate operates on po files. It does not care (yet) about pot. It just expects that po files are processed by msgmerge (ideally with --previous) after string changes. Weblate can work with both models: - many po files in different translation domains in one repo - many repos with one translation domain
I do not expect that developers will review translations.
Agree
Arvin mentioned that there are some special cases: That is not entirely true. I had wrong translations break the testsuite, e.g. "kB" translated as "KB". Also when "kB" was first translated as "ko" in French the testsuite had to be adopted.
+1 but Code Review process is currently mandatory for ALL YAST REPOS.
Weblate will never push any code changes. (With possible future exception of ALL_LINGUAS line in configure.ac.
Third way is manual pulling from the Weblate on request. I would avoid this as much as possible. If you update po files in GitHub, you will get conflict, and problem would need manual git merge.
YaST team in general do not care about translations, just fixing non-translatable strings and similar issues.
And I would like this to keep the same. But what would be actually acceptable (for me) is to create ${yast_module}-translation repository anywhere at GitHub (be it under SUSE/openSUSE/yast) for every single Yast repository ... or even one repository yast-translations.
It depends on your decision. po files inside source repos are the most straightforward, but many other options exist, as long as you can easily automate the process from update-po to release.
Steps that need to be done on import to Weblate:
3. These translations will be pushed to GitHub (one shot).
You might want to keep the history, in this case, my team might still have some tools for SVN2GIT conversion...
Git keeps the history, and it is the only history that is kept. Translations cannot run on more places at once. Conflicts happen.
5. opensuse-i18n robot will be allowed to push to your project (not needed in case of pull requests)
Yes, if we talk about a special repository for translations with special rules: no review needed.
However the robot has a theoretical privilege to commit code to GIT, it will never do. Weblate allows users only editing po files and nothing else (well, in future also LINGUAS* and ALL_LINGUAS line in configure.ac). Eventual hack of Weblate server would be easily detectable in the git log. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, Oct 13, 2015 at 05:39:27PM +0200, Stanislav Brabec wrote:
I do not expect that developers will review translations.
Arvin mentioned that there are some special cases:
I just found another case where I have to twiddle with translations: ar.po in snapper is broken (multi plural form stuff) and make aborts: ar.po:6: nplurals = 6... ar.po:486: ...but some messages have only 2 plural forms msgfmt: found 1 fatal error ar.po: 180 translated messages. Makefile:466: recipe for target 'ar.mo' failed make: *** [ar.mo] Error 1 So I will now delete ar.po or remove the "Plural-Forms:" statement. If some robot commits it again and again (whenever someone translates a single message) this will result in lots of build failures and manual work. Please make sure the translations don't have mistakes like that. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Wed, Oct 14, 2015 at 11:50:22AM +0200, Arvin Schnell wrote:
On Tue, Oct 13, 2015 at 05:39:27PM +0200, Stanislav Brabec wrote:
I do not expect that developers will review translations.
Arvin mentioned that there are some special cases:
I just found another case where I have to twiddle with translations: ar.po in snapper is broken (multi plural form stuff) and make aborts:
ar.po:6: nplurals = 6... ar.po:486: ...but some messages have only 2 plural forms msgfmt: found 1 fatal error ar.po: 180 translated messages. Makefile:466: recipe for target 'ar.mo' failed make: *** [ar.mo] Error 1
So I will now delete ar.po or remove the "Plural-Forms:" statement. If some robot commits it again and again (whenever someone translates a single message) this will result in lots of build failures and manual work.
Please make sure the translations don't have mistakes like that.
I have realized that weblate (or the new process) pushed that broken translations file and opened bug #950313. Unfortunately it shows that "accepting" code/translations without even being able to reject them is dangerous. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 14.10.2015 v 12:09 Arvin Schnell napsal(a):
On Wed, Oct 14, 2015 at 11:50:22AM +0200, Arvin Schnell wrote:
On Tue, Oct 13, 2015 at 05:39:27PM +0200, Stanislav Brabec wrote:
I do not expect that developers will review translations.
Arvin mentioned that there are some special cases:
I just found another case where I have to twiddle with translations: ar.po in snapper is broken (multi plural form stuff) and make aborts:
ar.po:6: nplurals = 6... ar.po:486: ...but some messages have only 2 plural forms msgfmt: found 1 fatal error ar.po: 180 translated messages. Makefile:466: recipe for target 'ar.mo' failed make: *** [ar.mo] Error 1
So I will now delete ar.po or remove the "Plural-Forms:" statement. If some robot commits it again and again (whenever someone translates a single message) this will result in lots of build failures and manual work.
Please make sure the translations don't have mistakes like that.
I have realized that weblate (or the new process) pushed that broken translations file and opened bug #950313.
Unfortunately it shows that "accepting" code/translations without even being able to reject them is dangerous.
It has nothing to do with Weblate. It is a problem of LCN SVN translation, that was discovered just now because nobody imported existing ar.po since 2014-09-04. Actually, Weblate will not allow to push translatio with broken plurals. Broken by: commit 5e6cef124c910e6c472e28e8fe54f20230744c5c Author: Stanislav Brabec <sbrabec@suse.com> Date: Thu Oct 8 20:56:34 2015 +0200 Update translations from LCN SVN trunk revision 93498. Problem with plurals already happened several times in SLES. Actually, it is a dark side of gettext utilities that they can produce invalid po files with broken plurals, and only msgfmt -c will discover it. Thanks for pointing to this problem. I'll revive ar.po with broken string marked as fuzzy and validate all imports that I already did. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Arvin Schnell <aschnell@suse.com> writes:
On Tue, Oct 13, 2015 at 05:39:27PM +0200, Stanislav Brabec wrote:
I do not expect that developers will review translations.
Arvin mentioned that there are some special cases:
I just found another case where I have to twiddle with translations: ar.po in snapper is broken (multi plural form stuff) and make aborts:
ar.po:6: nplurals = 6...
Standa, you will probably have to install some kind of po-check pre-commit hook. We have such a script in SVN. BTW, snapper.ar.po translations in trunk and SLE12-SP1 are fine. -- Karl Eichwalder SUSE Linux GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 14.10.2015 v 12:16 Karl Eichwalder napsal(a):
Arvin Schnell <aschnell@suse.com> writes:
On Tue, Oct 13, 2015 at 05:39:27PM +0200, Stanislav Brabec wrote:
I do not expect that developers will review translations.
Arvin mentioned that there are some special cases:
I just found another case where I have to twiddle with translations: ar.po in snapper is broken (multi plural form stuff) and make aborts:
ar.po:6: nplurals = 6...
Standa, you will probably have to install some kind of po-check pre-commit hook. We have such a script in SVN.
It has nothing to do with Weblate. Actually, Weblate will not allow to push translation with broken plurals. Broken by me personally: commit 5e6cef124c910e6c472e28e8fe54f20230744c5c Author: Stanislav Brabec <sbrabec@suse.com> Date: Thu Oct 8 20:56:34 2015 +0200 Update translations from LCN SVN trunk revision 93498. Problem with plurals already happened several times in SLES in translation-update-upstream. I have tools that prevent it while importing, but I did not expect that it will happen on Factory + SLE merge. Actually, it is a dark side of gettext utilities that they can produce invalid po files with broken plurals, and only msgfmt -c will discover it. Thanks for pointing to this problem. I'll revive ar.po with broken string marked as fuzzy and validate all imports that I already did.
BTW, snapper.ar.po translations in trunk and SLE12-SP1 are fine.
My mistake. I did msgcat of trunk and SLE12-SP1 to get the best coverage. Generally it is a good thing, but it requires plural check. I already encountered this problem in past in my translation-update-upstream. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 14.10.2015 11:50, Arvin Schnell wrote:
On Tue, Oct 13, 2015 at 05:39:27PM +0200, Stanislav Brabec wrote:
I do not expect that developers will review translations.
Arvin mentioned that there are some special cases:
I just found another case where I have to twiddle with translations: ar.po in snapper is broken (multi plural form stuff) and make aborts:
ar.po:6: nplurals = 6... ar.po:486: ...but some messages have only 2 plural forms msgfmt: found 1 fatal error ar.po: 180 translated messages. Makefile:466: recipe for target 'ar.mo' failed make: *** [ar.mo] Error 1
So I will now delete ar.po or remove the "Plural-Forms:" statement. If some robot commits it again and again (whenever someone translates a single message) this will result in lots of build failures and manual work.
Please make sure the translations don't have mistakes like that.
Hmm, that's right. Our pull requests support checking the new code in Travis. Then it says if all is OK. So, if we do not use PRs with that, packages could be broken quite easily. For that (and other reasons, such as security), I still prefer having translations in a different repository. Additionally, these translation packages can be submitted and built continuously, but they also need to have checks for consistency. Bye Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 14.10.2015 v 12:32 Lukas Ocilka napsal(a):
So, if we do not use PRs with that, packages could be broken quite easily. For that (and other reasons, such as security), I still prefer having translations in a different repository.
As I wrote in another mail, Weblate should not do such mistakes. It should push only valid translations. Actually, Weblate reports such problems as errors. I am reporting a new Weblate feature request: Don't allow translators to force-ignore some errors: https://github.com/nijel/weblate/issues/875
Additionally, these translation packages can be submitted and built continuously, but they also need to have checks for consistency.
It should be easy to force "msgfmt -c" check. It should catch all fatal problems. If any other check is needed, please let me know. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Op woensdag 14 oktober 2015 14:56:11 schreef Stanislav Brabec:
As I wrote in another mail, Weblate should not do such mistakes. It should push only valid translations.
Actually, Weblate reports such problems as errors.
I am reporting a new Weblate feature request: Don't allow translators to force-ignore some errors: https://github.com/nijel/weblate/issues/875
Additionally, these translation packages can be submitted and built continuously, but they also need to have checks for consistency.
It should be easy to force "msgfmt -c" check. It should catch all fatal problems. If any other check is needed, please let me know.
This is in fact what happens on the SVN server of KDE. It refuses the commit with a proper error message indication the output of msgfmt -c so it is quite easy to correct the error and resubmit the commit. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 14.10.2015 v 15:05 Freek de Kruijf napsal(a):
Op woensdag 14 oktober 2015 14:56:11 schreef Stanislav Brabec:
It should be easy to force "msgfmt -c" check. It should catch all fatal problems. If any other check is needed, please let me know.
This is in fact what happens on the SVN server of KDE. It refuses the commit with a proper error message indication the output of msgfmt -c so it is quite easy to correct the error and resubmit the commit.
Exactly the same happens in Weblate. But Weblate allows to force-ignore some errors. Weblate has even more checks that are not present in gettext itself. Example: msgfmt The feature just requests removal of possibility to force-ignore checks fatal for "msgfmt -c". -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 14.10.2015 14:56, Stanislav Brabec wrote:
Dne 14.10.2015 v 12:32 Lukas Ocilka napsal(a):
So, if we do not use PRs with that, packages could be broken quite easily. For that (and other reasons, such as security), I still prefer having translations in a different repository.
As I wrote in another mail, Weblate should not do such mistakes. It should push only valid translations.
Actually, Weblate reports such problems as errors.
Tomas just told me that they will be "fatal" now, which is good as we want to prevent from breaking consistency in our repos.
I am reporting a new Weblate feature request: Don't allow translators to force-ignore some errors: https://github.com/nijel/weblate/issues/875
Additionally, these translation packages can be submitted and built continuously, but they also need to have checks for consistency.
It should be easy to force "msgfmt -c" check. It should catch all fatal problems. If any other check is needed, please let me know.
I hope this will be enough. Thanks Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Lukas Ocilka <lukas.ocilka@suse.com> writes:
It should be easy to force "msgfmt -c" check. It should catch all fatal problems. If any other check is needed, please let me know.
I hope this will be enough.
It was not always able to detect all ycp or ruby string formatters. But in the end, there is nother better (missing features have to be reported upstream). -- Karl Eichwalder SUSE Linux GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 3.11.2015 v 15:13 Karl Eichwalder napsal(a):
Lukas Ocilka <lukas.ocilka@suse.com> writes:
It should be easy to force "msgfmt -c" check. It should catch all fatal problems. If any other check is needed, please let me know.
I hope this will be enough.
It was not always able to detect all ycp or ruby string formatters. But in the end, there is nother better (missing features have to be reported upstream).
Weblate has its own checks, more complex than msgfmt -c. But they are warnings just now. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, Nov 03, 2015 at 03:54:10PM +0100, Stanislav Brabec wrote:
Dne 3.11.2015 v 15:13 Karl Eichwalder napsal(a):
Lukas Ocilka <lukas.ocilka@suse.com> writes:
It should be easy to force "msgfmt -c" check. It should catch all fatal problems. If any other check is needed, please let me know.
I hope this will be enough.
It was not always able to detect all ycp or ruby string formatters. But in the end, there is nother better (missing features have to be reported upstream).
Weblate has its own checks, more complex than msgfmt -c. But they are warnings just now.
Please make them *fatal errors* in weblate so that such mistakes don't end up in the repos of e.g. libstorage or snapper. Regards, Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 3.11.2015 v 16:02 Arvin Schnell napsal(a):
On Tue, Nov 03, 2015 at 03:54:10PM +0100, Stanislav Brabec wrote:
Weblate has its own checks, more complex than msgfmt -c. But they are warnings just now.
Please make them *fatal errors* in weblate so that such mistakes don't end up in the repos of e.g. libstorage or snapper.
It's not yet possible. But it is a planned feature: https://github.com/nijel/weblate/issues/875 -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 13.10.2015 v 16:42 Lukas Ocilka napsal(a):
On 13.10.2015 09:40, Josef Reidinger wrote:
The only work on developers side is (in the current version) updating of po files against the latest pot and pushing it to the git repo. (And even it can be automatized in future.)
This is also what we do for svn, so I do not see difference.
Someone still needs to run `create pot file for $this repository`, but this can be automated quite "easily", for instance, in Jenkins.
Yes, it is already part of many automated tasks, even a part of make dist of many projects, "make update-po" target etc. Now you will not need to pick pot, submit it elsewhere, then check and submit translations back. And the best thing: New po files will appear in the git repo as soon as translator completes it.
I already have a script that can generate all pot files for all Yast repositories at once, also considering that not all Yast repositories need to have the "latest" branch, especially SLE 11 might have, e.g. only `SP2` branch, and nothing "younger".
Yes, YaST already maintains this in scripts. Problems appear especially outside YaST, where nobody picks translations back for years.
1) Decide how YaST will manipulate with po files. Currently all po files for all repositories reside in a single repository (and later in a single package). It was useful in time of manual downloads and uploads, where no -lang package merging was implemented. Now it will complicate fully automatic work flow, as pot files needs to be transferred across repositories (at least until somebody invents a robot for it).
YaST just generate pot files and upload to svn. Then it is up to ke how it is proceed further.
Yes, but IIUC - now these translations are expected to be pushed to Yast repositories automagically from the server, which is actually no way from my POV. Currently, there are no pot/mo/whatever files in Yast repos.
Weblate operates on po files. It does not care (yet) about pot. It just expects that po files are processed by msgmerge (ideally with --previous) after string changes. Weblate can work with both models: - many po files in different translation domains in one repo - many repos with one translation domain
I do not expect that developers will review translations.
Agree
Arvin mentioned that there are some special cases: That is not entirely true. I had wrong translations break the testsuite, e.g. "kB" translated as "KB". Also when "kB" was first translated as "ko" in French the testsuite had to be adopted.
+1 but Code Review process is currently mandatory for ALL YAST REPOS.
Weblate will never push any code changes. (With possible future exception of ALL_LINGUAS line in configure.ac.
Third way is manual pulling from the Weblate on request. I would avoid this as much as possible. If you update po files in GitHub, you will get conflict, and problem would need manual git merge.
YaST team in general do not care about translations, just fixing non-translatable strings and similar issues.
And I would like this to keep the same. But what would be actually acceptable (for me) is to create ${yast_module}-translation repository anywhere at GitHub (be it under SUSE/openSUSE/yast) for every single Yast repository ... or even one repository yast-translations.
It depends on your decision. po files inside source repos are the most straightforward, but many other options exist, as long as you can easily automate the process from update-po to release.
Steps that need to be done on import to Weblate:
3. These translations will be pushed to GitHub (one shot).
You might want to keep the history, in this case, my team might still have some tools for SVN2GIT conversion...
Git keeps the history, and it is the only history that is kept. Translations cannot run on more places at once. Conflicts happen.
5. opensuse-i18n robot will be allowed to push to your project (not needed in case of pull requests)
Yes, if we talk about a special repository for translations with special rules: no review needed.
However the robot has a theoretical privilege to commit code to GIT, it will never do. Weblate allows users only editing po files and nothing else (well, in future also LINGUAS* and ALL_LINGUAS line in configure.ac). Eventual hack of Weblate server would be easily detectable in the git log. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Mon, Oct 12, 2015 at 10:23:39PM +0200, Stanislav Brabec wrote:
What will be needed before YaST can be added to Weblate:
1) Decide how YaST will manipulate with po files. Currently all po files for all repositories reside in a single repository (and later in a single package). It was useful in time of manual downloads and uploads, where no -lang package merging was implemented. Now it will complicate fully automatic work flow, as pot files needs to be transferred across repositories (at least until somebody invents a robot for it).
Are you asking for the translations to get moved to the corresponding packages, e.g. that the translations of yast2-installation are included in the yast/installation repository and maybe also the yast2-installation.rpm?
2) Decide how YaST will accept translations.
Currently Karl is the maintainer of yast2-trans so the YaST team is not involved. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 13.10.2015 v 17:05 Arvin Schnell napsal(a):
On Mon, Oct 12, 2015 at 10:23:39PM +0200, Stanislav Brabec wrote:
What will be needed before YaST can be added to Weblate:
1) Decide how YaST will manipulate with po files. Currently all po files for all repositories reside in a single repository (and later in a single package). It was useful in time of manual downloads and uploads, where no -lang package merging was implemented. Now it will complicate fully automatic work flow, as pot files needs to be transferred across repositories (at least until somebody invents a robot for it).
Are you asking for the translations to get moved to the corresponding packages, e.g. that the translations of yast2-installation are included in the yast/installation repository and maybe also the yast2-installation.rpm?
I am just saying that it as an option. Most other projects have its translations in their po or locale directories in the repositories. And they consider it as an optimal solution. It is not the case of YaST. Was this decision based on the SVN LCN work-flow, or it was considered as best solution for YaST in general? From the packaging side, now we have a good and well working tools for creating of translation bundles. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, Oct 13, 2015 at 05:26:15PM +0200, Stanislav Brabec wrote:
Dne 13.10.2015 v 17:05 Arvin Schnell napsal(a):
On Mon, Oct 12, 2015 at 10:23:39PM +0200, Stanislav Brabec wrote:
What will be needed before YaST can be added to Weblate:
1) Decide how YaST will manipulate with po files. Currently all po files for all repositories reside in a single repository (and later in a single package). It was useful in time of manual downloads and uploads, where no -lang package merging was implemented. Now it will complicate fully automatic work flow, as pot files needs to be transferred across repositories (at least until somebody invents a robot for it).
Are you asking for the translations to get moved to the corresponding packages, e.g. that the translations of yast2-installation are included in the yast/installation repository and maybe also the yast2-installation.rpm?
I am just saying that it as an option.
Most other projects have its translations in their po or locale directories in the repositories. And they consider it as an optimal solution. It is not the case of YaST.
Was this decision based on the SVN LCN work-flow, or it was considered as best solution for YaST in general?
I think it is done that way to save disk space and esp. RAM during installation. We have about 80 translations and they are around 0.5 MB each, so having all of them in the inst-sys adds 40MB. Currently translation packages are inserted into the inst-sys on demand. If you make subpackages, e.g. yast2-installation-trans-cz, we would end up with 1000 translation packages.
From the packaging side, now we have a good and well working tools for creating of translation bundles.
Please explain what a translation bundle is. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 13.10.2015 v 17:35 Arvin Schnell napsal(a):
On Tue, Oct 13, 2015 at 05:26:15PM +0200, Stanislav Brabec wrote:
Was this decision based on the SVN LCN work-flow, or it was considered as best solution for YaST in general?
I think it is done that way to save disk space and esp. RAM during installation. We have about 80 translations and they are around 0.5 MB each, so having all of them in the inst-sys adds 40MB.
This has now a solution called translation bundles. See below. It was invented just for the same reason. GNOME and many other projects already release translations together with sources. In past (~10 years ago), packages contained all translations in the main package. Now it is not an issue any more.
Currently translation packages are inserted into the inst-sys on demand.
If you make subpackages, e.g. yast2-installation-trans-cz, we would end up with 1000 translation packages.
Currently it would be yast2-installation-lang with all translations in one.
From the packaging side, now we have a good and well working tools for creating of translation bundles.
Please explain what a translation bundle is.
The tools work in this way: foo.spec defines sub-package foo-lang (all languages inside, with special RPM tags identifying language specific files). Tools in OBS collect all lang files from defined subset of packages (currently gnome, kde, common), joins them and re-splits it by language. It means that enduser will install say bundle-lang-gnome-de and not gnome-calculator-lang. But it is still possible to install new version of gnome-calculator with new translations gnome-calculator-lang. These translations will take precedence. (This is a SUSE glibc specific feature.) -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 13.10.2015 18:05, Stanislav Brabec wrote:
Currently translation packages are inserted into the inst-sys on demand.
If you make subpackages, e.g. yast2-installation-trans-cz, we would end up with 1000 translation packages.
Currently it would be yast2-installation-lang with all translations in one.
As the Installer still contains a lot of Yast packages, the inst-sys would be quite big, but there is a simple solution: We can extend the inst-sys by the selected language only on-the-fly and unload any other extension which is not needed anymore. We already do it with some other packages (e.g., cracklib).
From the packaging side, now we have a good and well working tools for creating of translation bundles.
Please explain what a translation bundle is.
The tools work in this way:
foo.spec defines sub-package foo-lang (all languages inside, with special RPM tags identifying language specific files).
Tools in OBS collect all lang files from defined subset of packages (currently gnome, kde, common), joins them and re-splits it by language.
It means that enduser will install say bundle-lang-gnome-de and not gnome-calculator-lang.
And can we specify our own bundle? Such as bundle-lang-installer-es?
But it is still possible to install new version of gnome-calculator with new translations gnome-calculator-lang. These translations will take precedence. (This is a SUSE glibc specific feature.)
That's nice, because I'd like to have a self-healing functionality for the installer: Downloading and applying current updates for the installer before it's "really started". Thanks Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 14.10.2015 v 09:52 Lukas Ocilka napsal(a):
On 13.10.2015 18:05, Stanislav Brabec wrote:
And can we specify our own bundle? Such as bundle-lang-installer-es?
Yes, the mechanism could be extended. It is purely OBS+ZYPP+rpm solution, which has nothing to do with source code organization.
But it is still possible to install new version of gnome-calculator with new translations gnome-calculator-lang. These translations will take precedence. (This is a SUSE glibc specific feature.)
That's nice, because I'd like to have a self-healing functionality for the installer: Downloading and applying current updates for the installer before it's "really started".
Yes. The only cost of it is installation of the lang package that contains all translations of particular package. (Splitting lang packages to one-file packages is technically possible, but probably nobody probably wants thousands micro packages in repositories.) Here are technical ZYPP+rpm details: Symbols recommended by gnome-calculator: gnome-calculator-lang (The symbol is recommended only. => If you want, you can install gnome-calculator without any lang package.) What packages provide gnome-calculator-lang? bundle-lang-gnome-cs-13.2-12.5.noarch bundle-lang-gnome-en-13.2-12.5.noarch ... Symbols provided by bundle-lang-gnome-cs: ... locale(gnome-calculator:cs) ... gnome-calculator-lang = 3.16.2 ... Symbols provided by gnome-calculator-lang: gnome-calculator-lang = 3.16.2 gnome-calculator-lang-all = 3.16.2 ZYPP is smart enough to evaluate: gnome-calculator is installed AND language selection is cs => recommend bundle-lang-gnome-cs to fulfill the requirement -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 14.10.2015 v 09:52 Lukas Ocilka napsal(a):
On 13.10.2015 18:05, Stanislav Brabec wrote:
And can we specify our own bundle? Such as bundle-lang-installer-es?
Yes, the mechanism could be extended. It is purely OBS+ZYPP+rpm solution, which has nothing to do with source code organization.
But it is still possible to install new version of gnome-calculator with new translations gnome-calculator-lang. These translations will take precedence. (This is a SUSE glibc specific feature.)
That's nice, because I'd like to have a self-healing functionality for the installer: Downloading and applying current updates for the installer before it's "really started".
Yes. The only cost of it is installation of the lang package that contains all translations of particular package. (Splitting lang packages to one-file packages is technically possible, but probably nobody probably wants thousands micro packages in repositories.) Here are technical ZYPP+rpm details: Symbols recommended by gnome-calculator: gnome-calculator-lang (The symbol is recommended only. => If you want, you can install gnome-calculator without any lang package.) What packages provide gnome-calculator-lang? bundle-lang-gnome-cs-13.2-12.5.noarch bundle-lang-gnome-en-13.2-12.5.noarch ... Symbols provided by bundle-lang-gnome-cs: ... locale(gnome-calculator:cs) ... gnome-calculator-lang = 3.16.2 ... Symbols provided by gnome-calculator-lang: gnome-calculator-lang = 3.16.2 gnome-calculator-lang-all = 3.16.2 ZYPP is smart enough to evaluate: gnome-calculator is installed AND language selection is cs => recommend bundle-lang-gnome-cs to fulfill the requirement -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 13.10.2015 v 17:05 Arvin Schnell napsal(a):
On Mon, Oct 12, 2015 at 10:23:39PM +0200, Stanislav Brabec wrote:
What will be needed before YaST can be added to Weblate:
1) Decide how YaST will manipulate with po files. Currently all po files for all repositories reside in a single repository (and later in a single package). It was useful in time of manual downloads and uploads, where no -lang package merging was implemented. Now it will complicate fully automatic work flow, as pot files needs to be transferred across repositories (at least until somebody invents a robot for it).
Are you asking for the translations to get moved to the corresponding packages, e.g. that the translations of yast2-installation are included in the yast/installation repository and maybe also the yast2-installation.rpm?
I am just saying that it as an option. (See my reply to Lukáš.) Most other projects have its translations in their po or locale directories in the repositories. And they consider it as an optimal solution. It is not the case of YaST. Was this decision based on the SVN LCN work-flow, or it was considered as best solution for YaST in general? From the packaging side, now we have a good and well working tools for creating of translation bundles. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.com Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (7)
-
Arvin Schnell -
Freek de Kruijf -
Josef Reidinger -
Karl Eichwalder -
Lukas Ocilka -
Stanislav Brabec -
Stanislav Brabec