On Mon, 12 Oct 2015 22:23:39 +0200 Stanislav Brabec 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

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

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, 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 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, 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. (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

Dne 13.10.2015 v 16:53 Karl Eichwalder napsal(a):

Lukas Ocilka 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

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

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, 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 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: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 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

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

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

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

Dne 3.11.2015 v 15:13 Karl Eichwalder napsal(a):

Lukas Ocilka 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

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