-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-11 14:58, Karl Ove Hufthammer wrote:

Den 11. okt. 2015 10:46, Karl Ove Hufthammer skreiv:

...

Is it easy to download and upload *all* the files in one go, and using the command line? That’s a requirement for me for having an efficient work flow.

I’ve now registered at https://l10n.opensuse.org/, and done some testing. (BTW, it seems like anyone with an openSUSE (i.e. Bugzilla) account can register, and make any changes to any translations in any language.)

So, no control :-( Quality goes out of the window.

At least currently, it looks it’s *not* possible to mass-download or mass-upload translation files. One have to use the Web interface, go to each application and download a single file (three clicks, but quite a few more if you include choosing the download location). For uploading, you have to repeat a similar procedure. And there is no way of downloading the template files (.pot files) *at all*.

:-(

And, worryingly, translators’ comments (comments that can be added to a translation file for each string, for example to clarify why the translation was done the way it was, as a reminder to future translators and to oneself) are *stripped* from the translation file.

:-(

That is, if you do offline translation, add a translator’s comment, upload the file, and download the file again, the translator’s comment is gone! (And it’s not visible in the Weblate interface either.) That’s a quite severe bug. (This also means that any translators’ comments that were in the original files in SVN that were ‘stolen’ (not my words) are now gone if you download them from Weblate, so don’t do that.)

Oh, my. :-( This is terrible. I can't work that way. I'm not selfish, I simply can not work that way. (you can still get the old version in svn, though)

Also, committing of the translated files doesn’t seem to work. When I uploaded a file, I got this error message: ‘Failed to push to remote branch on libcamgm/master.’

Maybe it is disabled for "testing".

So perhaps even if a file is translated in Weblate, one isn’t guaranteed that it’s actually pushed to the source code repository and included in future application releases? Though this might perhaps just be a feature that isn’t implemented yet, as openSUSE Weblate is still in beta, so I’m not too worried about this (yet).

Maybe.

All in all, *currently* it doesn’t look like Weblate is ready for use; there is some very basic functionality missing. But we can of course be optimistic that this will be fixed before Weblate is implemented as the official way of translating.

I'm not having fun :-( - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYaksAACgkQja8UbcUWM1wkfQEAkyTh0KAnLaydIAhO0lv3tZbP fTlougqpq0pWlqVyuhkA/3oW5DSwTY6i0nOCOQG/Ea7qMvmWwkJnz4vWwTkN5zku =RHR3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Dne 12.10.2015 v 11:02 Karl Eichwalder napsal(a):

Karl Ove Hufthammer writes:

...

And, worryingly, translators’ comments (comments that can be added to a translation file for each string, for example to clarify why the translation was done the way it was, as a reminder to future translators and to oneself) are *stripped* from the translation file.

This is a showstopper and must be fixed.

https://github.com/nijel/weblate/issues/874 -- 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: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Dne Ne 11. října 2015 14:58:59, Karl Ove Hufthammer napsal(a):

Den 11. okt. 2015 10:46, Karl Ove Hufthammer skreiv:

...

Is it easy to download and upload *all* the files in one go, and using the command line? That’s a requirement for me for having an efficient work flow.

I’ve now registered at https://l10n.opensuse.org/, and done some testing. (BTW, it seems like anyone with an openSUSE (i.e. Bugzilla) account can register, and make any changes to any translations in any language.)

Which I said in my mail is known. And the reason why it was not open beta. When Standa is around today I will talk to him and we will fire newer version containing multiple fixes (not sure now on the state of the reviews, but simply consider it to be done before it is actually fully in progress).

At least currently, it looks it’s *not* possible to mass-download or mass-upload translation files. One have to use the Web interface, go to each application and download a single file (three clicks, but quite a few more if you include choosing the download location). For uploading, you have to repeat a similar procedure. And there is no way of downloading the template files (.pot files) *at all*.

This is also one of the features that is must for internal use. So it seems something borked so we will need to tweak it up. Again follow the process as I said on how to report issues.

And, worryingly, translators’ comments (comments that can be added to a translation file for each string, for example to clarify why the translation was done the way it was, as a reminder to future translators and to oneself) are *stripped* from the translation file. That is, if you do offline translation, add a translator’s comment, upload the file, and download the file again, the translator’s comment is gone! (And it’s not visible in the Weblate interface either.) That’s a quite severe bug. (This also means that any translators’ comments that were in the original files in SVN that were ‘stolen’ (not my words) are now gone if you download them from Weblate, so don’t do that.)

Didn't happen when I tried it but again is a bug, quite severe one, so shall be fixed.

Also, committing of the translated files doesn’t seem to work. When I uploaded a file, I got this error message: ‘Failed to push to remote branch on libcamgm/master.’ So perhaps even if a file is translated in Weblate, one isn’t guaranteed that it’s actually pushed to the source code repository and included in future application releases? Though this might perhaps just be a feature that isn’t implemented yet, as openSUSE Weblate is still in beta, so I’m not too worried about this (yet).

This looks like the hoook on github was not yet enabled on cangmgm. Try the same on eciel, as that one I already translated for testing it should work there. But it is soft-fail. You translate and it is kept, and when the hook on the github repo is added it auto-publishes without loss.

All in all, *currently* it doesn’t look like Weblate is ready for use; there is some very basic functionality missing. But we can of course be optimistic that this will be fixed before Weblate is implemented as the official way of translating.

I told ya, it was not ready for announcement, we wanted to do it in this or next week... Tom

Dne 12.10.2015 v 11:12 Tomáš Chvátal napsal(a):

Dne Ne 11. října 2015 14:58:59, Karl Ove Hufthammer napsal(a):

...

Den 11. okt. 2015 10:46, Karl Ove Hufthammer skreiv:

...

Is it easy to download and upload *all* the files in one go, and using the command line? That’s a requirement for me for having an efficient work flow.

I’ve now registered at https://l10n.opensuse.org/, and done some testing. (BTW, it seems like anyone with an openSUSE (i.e. Bugzilla) account can register, and make any changes to any translations in any language.)

Which I said in my mail is known. And the reason why it was not open beta.

https://github.com/nijel/weblate/issues/867 https://github.com/nijel/weblate/issues/868

When Standa is around today I will talk to him and we will fire newer version containing multiple fixes (not sure now on the state of the reviews, but simply consider it to be done before it is actually fully in progress).

...

At least currently, it looks it’s *not* possible to mass-download or mass-upload translation files. One have to use the Web interface, go to each application and download a single file (three clicks, but quite a few more if you include choosing the download location). For uploading, you have to repeat a similar procedure. And there is no way of downloading the template files (.pot files) *at all*.

This is also one of the features that is must for internal use. So it seems something borked so we will need to tweak it up. Again follow the process as I said on how to report issues.

Weblate currently does not handle pot files. It expects, that the developer of the package does mass msgmerge. It is either possible to ask maintainer of git repositories to add pot files to the repo, or add a new feature to Weblate.

...

And, worryingly, translators’ comments (comments that can be added to a translation file for each string, for example to clarify why the translation was done the way it was, as a reminder to future translators and to oneself) are *stripped* from the translation file. That is, if you do offline translation, add a translator’s comment, upload the file, and download the file again, the translator’s comment is gone! (And it’s not visible in the Weblate interface either.) That’s a quite severe bug. (This also means that any translators’ comments that were in the original files in SVN that were ‘stolen’ (not my words) are now gone if you download them from Weblate, so don’t do that.)

Didn't happen when I tried it but again is a bug, quite severe one, so shall be fixed.

Looks like a bug. Translations had to be stolen, otherwise people could translate in two places at once. Anyway, both openSUSE LCN SVN and GitHub are versioning systems. The version committed to GIT by me was only passed through msgmerge. It should contain all comments. It is possible to recover all comments.

...

Also, committing of the translated files doesn’t seem to work. When I uploaded a file, I got this error message: ‘Failed to push to remote branch on libcamgm/master.’ So perhaps even if a file is translated in Weblate, one isn’t guaranteed that it’s actually pushed to the source code repository and included in future application releases? Though this might perhaps just be a feature that isn’t implemented yet, as openSUSE Weblate is still in beta, so I’m not too worried about this (yet).

This looks like the hoook on github was not yet enabled on cangmgm. Try the same on eciel, as that one I already translated for testing it should work there. But it is soft-fail. You translate and it is kept, and when the hook on the github repo is added it auto-publishes without loss.

This is already fixed: This was a GitHub configuration problem. opensuse-i18n is member of openSUSE committers group, which is allowed to push to most openSUSE projects. But not all. Now it is fixed and all edits are in the GitHub.

...

All in all, *currently* it doesn’t look like Weblate is ready for use; there is some very basic functionality missing. But we can of course be optimistic that this will be fixed before Weblate is implemented as the official way of translating.

I told ya, it was not ready for announcement, we wanted to do it in this or next week...

We needed to import some projects and get feedback. I'll stop importing more projects, and fix all reported problems. -- 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: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Carlos E. R. - 15:24 12.10.15 wrote:

On 2015-10-12 15:12, Stanislav Brabec wrote:

...

Weblate currently does not handle pot files. It expects, that the developer of the package does mass msgmerge.

This breaks workflow of translators doing work on, say, lokalize, on their local file (which can take days), and then the pot being modified upstream. On upload there would be a conflict.

And what is difference whether it is in git or SVN? When you are offline and you are not the only one working on stuff, you can have conflicts. Only difference I see is that git is quite good at handling those. -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Carlos E. R. - 1:24 13.10.15 wrote:

On 2015-10-12 19:30, Michal Hrusecky wrote:

...

Carlos E. R. - 15:24 12.10.15 wrote:

...

On 2015-10-12 15:12, Stanislav Brabec wrote:

...

Weblate currently does not handle pot files. It expects, that the developer of the package does mass msgmerge.

This breaks workflow of translators doing work on, say, lokalize, on their local file (which can take days), and then the pot being modified upstream. On upload there would be a conflict.

And what is difference whether it is in git or SVN? When you are offline and you are not the only one working on stuff, you can have conflicts. Only difference I see is that git is quite good at handling those.

Because a translator picks a file and works on it, maybe for days, before submitting it. Other translators are told by the system not to touch that file, ie, it is locked.

Yep, which is the feature that is currently being worked on as you could read in one the mails to this mailing list. -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Den 12. okt. 2015 15:12, Stanislav Brabec skreiv:

Weblate currently does not handle pot files. It expects, that the developer of the package does mass msgmerge.

Hm, I’m not sure I understand. To do a msgmerge you’ll need a .pot file. But do I understand you correctly in that it’s still the developer’s responsibility to *extract strings* from the applications, to make them available for the translators? One of the current (and long-standing) problem with the current translation system was that the developer’s *didn’t* do this. That is, basically the following thing happened: 1. A developer (or typically several) developed an application, with included some user-visible strings, that needed to be translated. 2. The developer ran xgettext to create a translation template (a file containing all the translatable strings). 3. The translation template was put on the translation server (e.g. https://svn.opensuse.org/svn/opensuse-i18n/branches/openSUSE-13_2-Branch/lcn...) 4. The translators translated the files. 5. The developer(s) fetched the translation when preparing a release, and included them in the release. Everything was fine so far. But typically the following then happened: 6. The developer(s) improved the application, adding some strings, changing some and removing others. 7. The translation template was never updated, so the translators didn’t even *know* there were any changes, and also had no possibility of supplying updated translations. 8. The application was released (perhaps many times, over several years) with missing translations. Will Weblate improve on this situation? Currently there application even in ‘trunk’ with translation template files that haven’t seen any updates since as far back as 2005. For some applications, this isn’t a problem (there just haven’t *been* any updates of the application (or at least no update that adds new strings or modifies old ones)). But for many, it’s outdated translation files. For comparison, in KDE this is never a problem; a script automatically regenerates all translation template files for *all* applications each night (currently a little more 2000 template files – yes KDE has quite a few applications (and libraries)). -- Karl Ove Hufthammer -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-11 10:46, Karl Ove Hufthammer wrote:

Den 11. okt. 2015 10:02, Ferdinand Galko skreiv:

You are aware that Lokalize has built in project manager, right? With this, you have *continously* updated statistics; i.e., every time save your translation file, the statistics in the project view is updated (both with numbers and with colour-coded bars).

Yes.

...

Download/upload .po files is simple in Weblate. There is not needed any additional SW and any working directory to synchronise.

Is it easy to download and upload *all* the files in one go, and using the command line? That’s a requirement for me for having an efficient work flow.

And to a single directory, or lokalize will not see all them at a glance in the project view. Or any other GUI po editor we have.

Also, how are branches (i.e. 13.2, 42.0, Tumbleweed, trunk/Factory) in Weblate? Is there a separate repository/project/folder for each branch?

If all this is possible, I won’t see much of a problem with openSUSE using Weblate. I’ll be able to use my normal workflow (just replacing ‘svn up’ and ‘svn commit’ with two other commands). And for versioning, I’ll (hopefully) be able to continue to use the current SVN repository (perhaps with a different, more sensible, directory structure). As long as one person on each team was responsible for downloading from Weblate to SVN, and uploading from SVN to Weblate (two simple commands to run), other people could continue to use SVN (and other tools based on this, such as Vertaal) just like they do now.

Vertaal will no longer work. It does not support GIT, and Gabriel said in the past he would not do that large modification. So, using weblate, we need some other method in which coordinators can assign files to translators, not a free for all. In online edit mode on weblate apparently I see one message at a time, with delays when going from one to the next, but it handles collisions between translators. Many people can work on the same file simultaneously. True. But this destroys consistency of the translation. I don't know if locking a file is possible, so that only one person can work on it. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYakXYACgkQja8UbcUWM1xWxwD8DrYW1WqsXaNAhkNtGiroFLqs RnY9JWv0HumlOyT2aroA/1mM+qeIn5STbIBdOQD9sKVoFjYfPZdfeobzR/AF3NCr =QIYe -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-11 19:02, Karl Ove Hufthammer wrote:

Den 11. okt. 2015 18:42, Carlos E. R. skreiv:

What I was thinking of when writing the above was to *continue* to use the current SVN server for hosting the translation files, but uploading the results to Weblate (to automatically export them to the various tools hosted in Git, so that they would be available in openSUSE packages). It would work like this:

Ah, I see. Yes.

One person would run a simple script, called fetch-and-merge.sh, for example, which would download the updated templates from Weblate and (optionally, with a per-language setting) merge existing translations with the templates. This script should be run regularly (e.g., once per day).

A cronjob, running on the svn machine.

The translation templates and translation would be organized in the ‘by-language’ directory structure detailed in http://pology.nedohodnik.net/doc/user/en_US/ch-summit.html#sec-susetup

so that each team had a separate directory to do all their work in

(which is the preferred directory layout for most translation tools too).

Is it not how is it in the current svn tree? :-?

The various translators would use the tools they prefer to update the translation files. Some teams may use Vertaal to coordinate everything.

One person would run a simple script, called upload-translations.sh, for example, to mass-upload all the translations to Weblate.

And other teams would be able to use weblate if they prefer. What about the stripped comments? Maybe they would remain in the SV, which would be the master copy. Per team choice.

Variant (perhaps the preferred one?): Each *team coordinator* would be responsible for running upload-translations.sh and/or fetch-and-merge.sh for his/her language.

If Weblate supported command-line based mass-downloading of templates files (*.pot) and mass-uploading of translations files (*.po), this would actually be *very* easy to accomplish. We would only need a few line of shell scripting.

This would be a nice solution for all, yes :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYam2cACgkQja8UbcUWM1zc0AD/feuGEaH5r8CkGXn9Pn8Gv+QZ A1XNmW4aOWREOr+5bEgA/R2XLZxCdnNe7ooBiUmiV1lce52oCr2QoWCOaF2zUdrz =64iy -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Dne 12.10.2015 v 14:19 Michael Skiba napsal(a):

Am Sonntag, 11. Oktober 2015, 19:02:36 schrieb Karl Ove Hufthammer:

...

If Weblate supported command-line based mass-downloading of templates files (*.pot) and mass-uploading of translations files (*.po), this would actually be *very* easy to accomplish. We would only need a few line of shell scripting.

Yes, Weblate heavily depends on GIT. It is a three stage process: Work in progress is kept in the local cache. Once the translations matches defined criteria (reached 100%, 2 hours since last chage), file from the cache goes to the local instance of GIT. And the local instance of GIT pushes changes to the upstream GIT.

From my understanding weblate is based off on git. So downloading all the files from commandline would be something like git clone/git pull, which should be scriptable.

Weblate could do simpler mass downloading than git clone. As weblate holds an up-to-date copy of all translated projects, it can provide only requested po file instead of the full repository. Writing such scripts will be easy. -- 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: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Dne Po 12. října 2015 18:22:49, Martin Schlander napsal(a):

Mandag den 12. oktober 2015 17:07:13 skrev Stanislav Brabec:

...

Once the translations matches defined criteria (reached 100%, 2 hours since last chage), file from the cache goes to the local instance of GIT.

That's a pretty harsh criteria ;-)

Normally something like 70-75% completeness is required for translations to be shipped (if any criteria at all).

2 hours of no activity OR 100% completion. Not and ;-) We might put there some limit like at least 50% to ensure we don't ship yast with one zulu translation or something similar later on tho :) Tom

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-12 18:27, Tomáš Chvátal wrote:

Dne Po 12. října 2015 18:22:49, Martin Schlander napsal(a):

...

Mandag den 12. oktober 2015 17:07:13 skrev Stanislav Brabec:

...

Once the translations matches defined criteria (reached 100%, 2 hours since last chage), file from the cache goes to the local instance of GIT.

That's a pretty harsh criteria ;-)

Normally something like 70-75% completeness is required for translations to be shipped (if any criteria at all).

2 hours of no activity OR 100% completion. Not and ;-)

We might put there some limit like at least 50% to ensure we don't ship yast with one zulu translation or something similar later on tho :)

You can't put any limit. Translators need to be able to submit their partial work anytime, and this not been lost, so that he can continue the work whenever he can pick it up, or another translator picks it up. And about not publishing... being able to download an rpm with a partially done translation would help sometimes, in order to run that application and see the partial result in place. For example, for checking if a string overflows or does not wrap correctly. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYcQmEACgkQja8UbcUWM1xFfAD9Hun+aI3A6/loo6L1ISf8YrVd 1fAgzBJZQvzlNlOQAcUBAIYWi+dk7fNc5d2JJEqWfxv+XcYtRiGrms1RAUoIePtQ =xtZO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-13 10:57, Richard Brown wrote:

Carlos E. R. wrote:

...

Notice the important detail: the translator works on finished versions of the code, not on transient versions - which is why Factory can not be translated.

Tumbleweed can be translated, indeed it should be

It can't, no matter what you do. There is no string freeze phase. You insist because you know nothing about translating. It is not a question of tools or procedures.

The project's guiding principles ( https://en.opensuse.org/openSUSE:Guiding_principles ) make it clear that we're a project that values respect for other persons and contributions.

Exactly! They did not respect us!

If you wish to continue to disrespect the Weblate contributors by discriminating against them because of their email address, if you continue to act in this mindset of 'us' vs 'them', I strongly encourage you to find another project that will tolerate your world view, because it will not be accepted here.

No, their mail address, and yours, is just a symptom. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYc7DYACgkQja8UbcUWM1w6sQD/Q6xb2hWUrQ7XRaDh1qX0p+jg FxnFbygMHL8a2lp/wK8A/3XqB26x1lo9eVxba5u/G/Gy2uZmOs3U55sEzBWdp2X4 =tIc3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-13 13:44, Michal Hrusecky wrote:

Carlos E. R. - 13:34 13.10.15 wrote:

...

On 2015-10-13 10:57, Richard Brown wrote:

...

Carlos E. R. wrote:

...

Notice the important detail: the translator works on finished versions of the code, not on transient versions - which is why Factory can not be translated.

Tumbleweed can be translated, indeed it should be

It can't, no matter what you do. There is no string freeze phase. You insist because you know nothing about translating. It is not a question of tools or procedures.

So let's wait for Weblate deployment to be finished and let's prove you wrong ;-) Yes it will not be translated to 100% all time, but we can have most of it translated most of the time.

Then you will have to test and document it all. Which is what I did, years ago. I made procedures, documented them and the tools. I had to discover how things worked and explain it to others. It took years of work. Well, now I'm tired, and I will not do that huge effort again. I don't feel up to that task. It's up to the people that are modifying the system to do it for us, this time. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYc9IoACgkQja8UbcUWM1yOQAD/XhLcaTwCv5uN8AvzlV2KeTjr ADwhpNr7vuCarapQlzcBAJD9FV8N5EjohIbSzc1o3uaY0RktpNveHWJIUbTPplje =d1te -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-13 14:10, Richard Brown wrote:

- No/Poorly Translated Leap

This is the fault of the devel team, not the translating team. If they don't provide the files to translate, they can't be translated. Simple. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYc+N4ACgkQja8UbcUWM1xmWgEAmRDmlIvvNXv0OM4O9FIHFowf GE1SSN/KuteRaHdzwEsA/RzfFb/UtuiMMaKLfX56vzyQyyhYIElk4Z3hgHXQ5kvQ =g4fn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Carlos E. R. wrote:

...

They were not working because the developers were not doing their part. So, they are not happy and they change it, good, but destroying our side of the system, the side that was working correctly, bad.

More 'us' vs 'them' - Stop it Richard, please, stop pushing this "'us' vs 'them'" on Carlos and all of us. We are all adult people here, we all understand there is no 'versus' between devs and translators. Every team is doing its part of

As wonderful as things might have been from your perspective, the reality is that the output of 'your' part was not working correctly

Just look at Tumbleweed - Mostly untranslated, by your own omission

Just look at Leap - Untranslated, by your own omission As it was already pointed out, the whole process was just not fitting

2015-10-13 11:57 GMT+03:00 Richard Brown : the job for the sake of benefitting the project we all love, everything is fine here. Just a lack of communication between 'us' AND 'them', which can lead to undesirable consequences for the project as a whole. As you admitted in the following email, "communication about Weblate could have been handled better", so I suggest we all start to handle it better now. For instance, by stopping false accusations like these: the needs of these new release types, so saying that this situation is translators' own omission is an exaggeration. Once again, consequent steps for translating openSUSE are like this: Stage 1: 1.1) generate translation templates from the software (handled by devs, semi-automated work) 1.2) publish translation templates on i18n SVN (handled by devs, manual work) Stage 2: 1.3/2.1) generate translatable files from templates and push to i18n SVN where translators can get them by language (handled by translation coordinators: keichwa and sometimes community volunteers including myself; manual/semi-automated work) 2.2) get the files for your language and translate (handled by translators, manual work) 2.3) push translated files back to i18n SVN where devs can reach them (handled by translators, automated work: svn commit) Stage 3: 3.1) get the translated files from i18n SVN and push them for packaging for release (handled by devs/packagers, manual/semi-automated work) So, Tumbleweed was not performing well on stage 3 and Leap has never passed stage 1. Lack of performance and lots of manual work are easily noticeable in this 'old' process, so several developers decided to fix this and came up with the new solution, which brings some automation to stages 1 and 3. It is great, cause these stages failed most in the old approach, and now they should be passed like a breeze. From developers' point of view this should speed up the whole process significantly, cause 4 out of 6 steps will be automated. From translators point of view it is not that great because the price for speeding up other stages is ruining the only automated step of the old way and making harder others. Imagine we all are on the big ship: devs are the central section at the very core of the ship, translator's section is along a broadside. For historical reasons we have some water of noticable level in our sections which slows down the whole ship, but we somehow got used to it. Developers are smart guys and craft a new pumping station that pushes the water out of their section through the wall. Developers see the falling water level in their section and expect the ship to go faster, but it is not happening. Guess why? Because nobody asked the translators sitting behind this wall, the water level in their section is rising and the ship is still too heavy. Additional valve to pour the water through the broadside would correct the whole situation, but it was not included in this brand new pumping station. Back to the real life: all the translators will be really grateful for new tools that will fix the issues of the old way. There is absolutely nothing wrong in taking action to make everyone's life easier, but please consider that this introduced some problems, which are severely more notable from translators' side: 1. Stealing real content. "Never test on production" is a widely known postulate. I don't know the correct idiomatic expression in English, but here in Russia we call it "blood-written rule". Release notes of upcoming Leap release will get near to zero new translations, since it was taken out of "old but somewhat working" SVN server and put to "not yet an open beta" weblate server which no new translator is familiar with. 2. Scalability. When everything will be migrated to weblate it will result in almost 200 separate repos/projects. On currently deployed Weblate I saw no option to mass-download files of one language from all (or subset of) projects. Same for uploading. Managing that file by file in web UI is too much for one individual. Can we expect some API/scripting support on server side to be able to push a bunch of files at once from command line? That would really become the needed "valve" to speed everything up. 3. Communication. Knowing only by accident about significant changes gone live was not a pleasant experience and this thread was started in bad feelings. It is getting too big for detailed discussion, and my previous questions about proper ways to talk to weblate guys were not answered. I really would like to see devs/translators communication improving. Can we organize a separate technical discussion or even better an IRC meeting? I clearly saw form this and other discussions (incl. ongoing in yast-devel) that devs and translators have different understanding and priorities of the same process, so some meeting/detailed discussion would definitely help us to understand each other better. --- Best regards, Minton. -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-14 02:20, Alexander Melentev wrote:

...

Carlos E. R. wrote:

...

They were not working because the developers were not doing their part. So, they are not happy and they change it, good, but destroying our side of the system, the side that was working correctly, bad.

More 'us' vs 'them' - Stop it Richard, please, stop pushing this "'us' vs 'them'" on Carlos and all of us. We are all adult people here, we all understand there is no 'versus' between devs and translators. Every team is doing its

...

As wonderful as things might have been from your perspective, the reality is that the output of 'your' part was not working correctly

Just look at Tumbleweed - Mostly untranslated, by your own omission

Just look at Leap - Untranslated, by your own omission As it was already pointed out, the whole process was just not fitting the needs of these new release types, so saying that this situation is translators' own omission is an exaggeration. Once again, consequent steps for translating openSUSE are like this: Stage 1: 1.1) generate translation templates from the software (handled by devs, semi-automated work) 1.2) publish translation templates on i18n SVN (handled by devs, manual work) Stage 2: 1.3/2.1) generate translatable files from templates and push to i18n SVN where translators can get them by language (handled by

2015-10-13 11:57 GMT+03:00 Richard Brown : part of the job for the sake of benefitting the project we all love, everything is fine here. Just a lack of communication between 'us' AND 'them', which can lead to undesirable consequences for the project as a whole. As you admitted in the following email, "communication about Weblate could have been handled better", so I suggest we all start to handle it better now. For instance, by stopping false accusations like these: translation coordinators: keichwa and sometimes community volunteers including myself; manual/semi-automated work) 2.2) get the files for your language and translate (handled by translators, manual work) 2.3) push translated files back to i18n SVN where devs can reach them (handled by translators, automated work: svn commit) Stage 3: 3.1) get the translated files from i18n SVN and push them for packaging for release (handled by devs/packagers, manual/semi-automated work) So, Tumbleweed was not performing well on stage 3 and Leap has never passed stage 1.

Lack of performance and lots of manual work are easily noticeable in this 'old' process, so several developers decided to fix this and came up with the new solution, which brings some automation to stages 1 and 3. It is great, cause these stages failed most in the old approach, and now they should be passed like a breeze. From developers' point of view this should speed up the whole process significantly, cause 4 out of 6 steps will be automated. From translators point of view it is not that great because the price for speeding up other stages is ruining the only automated step of the old way and making harder others. Imagine we all are on the big ship: devs are the central section at the very core of the ship, translator's section is along a broadside. For historical reasons we have some water of noticable level in our sections which slows down the whole ship, but we somehow got used to it. Developers are smart guys and craft a new pumping station that pushes the water out of their section through the wall. Developers see the falling water level in their section and expect the ship to go faster, but it is not happening. Guess why? Because nobody asked the translators sitting behind this wall, the water level in their section is rising and the ship is still too heavy. Additional valve to pour the water through the broadside would correct the whole situation, but it was not included in this brand new pumping station.

Back to the real life: all the translators will be really grateful for new tools that will fix the issues of the old way. There is absolutely nothing wrong in taking action to make everyone's life easier, but please consider that this introduced some problems, which are severely more notable from translators' side: 1. Stealing real content. "Never test on production" is a widely known postulate. I don't know the correct idiomatic expression in English, but here in Russia we call it "blood-written rule". Release notes of upcoming Leap release will get near to zero new translations, since it was taken out of "old but somewhat working" SVN server and put to "not yet an open beta" weblate server which no new translator is familiar with. 2. Scalability. When everything will be migrated to weblate it will result in almost 200 separate repos/projects. On currently deployed Weblate I saw no option to mass-download files of one language from all (or subset of) projects. Same for uploading. Managing that file by file in web UI is too much for one individual. Can we expect some API/scripting support on server side to be able to push a bunch of files at once from command line? That would really become the needed "valve" to speed everything up. 3. Communication. Knowing only by accident about significant changes gone live was not a pleasant experience and this thread was started in bad feelings. It is getting too big for detailed discussion, and my previous questions about proper ways to talk to weblate guys were not answered. I really would like to see devs/translators communication improving. Can we organize a separate technical discussion or even better an IRC meeting? I clearly saw form this and other discussions (incl. ongoing in yast-devel) that devs and translators have different understanding and priorities of the same process, so some meeting/detailed discussion would definitely help us to understand each other better.

I agree to all that :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYhhMsACgkQja8UbcUWM1wQhwD6A5f16eXaswTDAAUja+2NGV7q pl66xXKVkMlG+wb+sJwA/An2svcvR0180/OcAHEYz0kHrv4jgAPn0VspOKKv7md0 =HC4j -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Dne 13.10.2015 v 01:29 Carlos E. R. napsal(a):

You can't put any limit.

Translators need to be able to submit their partial work anytime, and this not been lost, so that he can continue the work whenever he can pick it up, or another translator picks it up.

This is not intended as a limit for dropping translation. It is intended as a limit for releasing the translation in the final package. Half translated GUI looks very ugly and less professional than English-only.

And about not publishing... being able to download an rpm with a partially done translation would help sometimes, in order to run that application and see the partial result in place. For example, for checking if a string overflows or does not wrap correctly.

Agree. I am thinking about an application capable to download mo files in progress on fly from the translation server. Without making a test package and installation. It would just need hacking of few glibc calls with a preload. I already have a kit for it: https://github.com/openSUSE/watch-gettext -- 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: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Dne 14.10.2015 v 20:09 Carlos E. R. napsal(a):

You just need to place the mo file in the correct directory on the machine where testing is done, and restart the application. You do not need to code anything, AFAIK.

With a standard glibc calls, yes. But if you preload a special wrapper on textdomain() and bindtextdomain() and several others, it can download the file from the translation server instead of reading it from the system directory. It is just an idea, nothing is written yet. -- 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: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Dne 15.10.2015 v 15:20 Carlos E. R. napsal(a):

On 2015-10-14 20:45, Stanislav Brabec wrote:

...

Dne 14.10.2015 v 20:09 Carlos E. R. napsal(a):

But if you preload a special wrapper on textdomain() and bindtextdomain() and several others, it can download the file from the translation server instead of reading it from the system directory.

Oh :-o

...

It is just an idea, nothing is written yet.

I see...

But you want this on every machine? :-?

It was intended purely for testing purposes: Immediately see result of your po file edit.

Oh, and the .mo has to match the application version: you can not just download the latest. :-'

I guess that in future, we can have Leap and SLE branches and master. If you download the merged po/mo file, it will cover all of them, at cost of a bit larger size. -- 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: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

"Carlos E. R." writes:

On 2015-10-15 15:37, Stanislav Brabec wrote:

...

I guess that in future, we can have Leap and SLE branches and master.

If you download the merged po/mo file, it will cover all of them, at cost of a bit larger size.

SLE and openSUSE may translate the same string differently.

Yes, but this has to stop--the sooner, the better ;) You should talk to each other. -- 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: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

"Carlos E. R." writes:

...

...

SLE and openSUSE may translate the same string differently.

Yes, but this has to stop--the sooner, the better ;) You should talk to each other.

What do you mean, about SLE and openSUSE different translations? What do you propose? :-?

Bugzilla, or mail directly. -- 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: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

"Carlos E. R." writes:

On 2015-10-19 13:11, Karl Eichwalder wrote:

...

"Carlos E. R." <> writes:

...

...

...

SLE and openSUSE may translate the same string differently.

Yes, but this has to stop--the sooner, the better ;) You should talk to each other.

What do you mean, about SLE and openSUSE different translations? What do you propose? :-?

Bugzilla, or mail directly.

I'm sorry, I don't understand. What do you want reported in Bugzilla?

Which strings are translated differently. -- 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: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

"Carlos E. R." writes:

Sorry, but they are translated differently on purpose. In my team, we had agreed policy on some words and expressions which SLE doesn't follow. In fact, we don't know what their policies are.

We must sort this out in a documented way (bugzilla). If you want to see your translation on Leap, you must convince the SLE team. -- 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: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

On 19 October 2015 at 18:18, Carlos E. R. wrote:

In fact, if my translations are going to end up in SLES, we have a problem. And not only me, other translators have said so, in this mail list; some very recently.

Carlos, you realise your translations are contributed to an OPEN Project correct? The clue is in the name.. openSUSE Lets for example take the yast translations from 13.2 https://build.opensuse.org/package/view_file/openSUSE:13.2/yast2-trans/yast2... They are shipped under the GPL-2.0+ licence By definition, those translations can end up pretty much _ANYWHERE_ as long as end users retain the freedoms to run, study, share (copy) and modify the software As SLES is also distributed under the GPL, they're fully within their rights, under the licence which your translations are distributed under, to use your translations. If you don't like that, then don't contribute your translations to an open project which distributes it's code and translations under the GPL or GPL compatible licences.. -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Den 14. okt. 2015 20:00, Stanislav Brabec skreiv:

...

And about not publishing... being able to download an rpm with a partially done translation would help sometimes, in order to run that application and see the partial result in place. For example, for checking if a string overflows or does not wrap correctly.

Agree.

I am thinking about an application capable to download mo files in progress on fly from the translation server. Without making a test package and installation.

It would just need hacking of few glibc calls with a preload.

This look needlessly complicated. Since the translations are stored in SVN, it’s currently actually *very fast and easy* for a translator to test the translation of an application. You just have to run (quit the application if it’s running first): sudo msgfmt appname.po -o /usr/share/locale/langcode/LC_MESSAGES/appname.mo (where ‘langcode’ is the two-letter language code for the translation) and then start the application. I use a simple script which basically does the above, using a command like: test-trans appname (The script searches the translation directory and all subdirectories for appname.po, and then runs the ‘sudo msgfmt’ command mentions above with the correct filenames for the .po and .mo file.) I guess this tip should be documented on the translation wiki. I’ll add it when the details for the name translation frame work is in place (and documented). -- Karl Ove Hufthammer -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-10-15 15:15, Stanislav Brabec wrote:

For example, such as simple application like gnome-calculator loads: atk10 glib20 gnome-calculator gtksourceview-3.0 gtk30 gtk30-properties pulseaudio

Yes, but the translator only translates "gnome-calculator". The rest are not his problem; they are some other translator problem. Of course, they can happen to be the same person. And if the rest is not translated, it is of course confusing for the translator. And in the case of openSUSE translators, we only translate those things where openSUSE is the upstream, meaning that things are easier to locate ;-) On the other hand, what would be very nice for the translator is to have a mock-up, or dry-run, version of the applications we translate. So that we can trigger all the menus and dialogs without actually doing things in our systems, and see how they feel, how they look. This would benefit also the application designer, he would be able to see the application in the original language and check. Some of the dialogs only happen on certain hard to reach conditions, so we never see them. And some may apply very undesired changes to our running systems, which is why I seldom test them. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYfqo4ACgkQtTMYHG2NR9U56gCgii5fWZ/NGD7sEj87XqMtKT96 i0kAn3K7fFbPupgtxetORm9S3bSWAlL7 =Cabm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Dne 13.10.2015 v 01:29 Carlos E. R. napsal(a):

You can't put any limit.

Translators need to be able to submit their partial work anytime, and this not been lost, so that he can continue the work whenever he can pick it up, or another translator picks it up.

This is not intended as a limit for dropping translation. It is intended as a limit for releasing the translation in the final package. Half translated GUI looks very ugly and less professional than English-only.

And about not publishing... being able to download an rpm with a partially done translation would help sometimes, in order to run that application and see the partial result in place. For example, for checking if a string overflows or does not wrap correctly.

Agree. I am thinking about an application capable to download mo files in progress on fly from the translation server. Without making a test package and installation. It would just need hacking of few glibc calls with a preload. I already have a kit for it: https://github.com/openSUSE/watch-gettext -- 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: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Den 12. okt. 2015 17:07, Stanislav Brabec skreiv:

...

From my understanding weblate is based off on git. So downloading all the files from commandline would be something like git clone/git pull, which should be scriptable.

Weblate could do simpler mass downloading than git clone.

As weblate holds an up-to-date copy of all translated projects, it can provide only requested po file instead of the full repository.

Great! (Though I guess one *usually* would want all files, or at least all files for a given language.) BTW, how are branches handled in Weblate? A given application may exist in various branches, at least a stable release (SLES 12) and a trunk release, but possibly other releases too (I see openSUSE 13.2 still receives updates, any maybe string updates too). The different versions have different sets of strings that need to be translated. I guess there is some sort of functionality for handling this is Weblate? (Having some sort of ‘subdirectory’-like structure would be fine, e.g. opensuse13.2/yast/snapper, trunk/yast/snapper, SLES12/yast/snapper.) BTW, this nothing new for translators. In KDE we currently manage translations for four different branches (KDE 4 stable, KDE 4 trunk, KDE 5 stable, KDE 5 trunk). -- Karl Ove Hufthammer -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

2015-10-14 13:12 GMT-03:00 Martin Schlander :

Tirsdag den 13. oktober 2015 18:51:57 skrev Karl Ove Hufthammer:

...

BTW, how are branches handled in Weblate? A given application may exist in various branches, at least a stable release (SLES 12) and a trunk release, but possibly other releases too (I see openSUSE 13.2 still receives updates, any maybe string updates too). The different versions have different sets of strings that need to be translated.

I was told on IRC that weblate does support branches, but currently there are none, because SLE12sp1/Leap and Tumbleweed are pretty much all in sync currently.

Wonder if weblate will merge the different branches automatically, if the translator translates strings in one branch, which are valid for all the branches. --

Hi, Maybe something like the summit operation of pology [1] which some KDE teams use (it creates a po file from multiple branches) Regards, Luiz [1] http://pology.nedohodnik.net//doc/user/en_US/ch-summit.html -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Am Mittwoch, 14. Oktober 2015, 18:42:18 schrieb Stanislav Brabec:

You are translating one po file, and it is split to more branches, exactly like it is done in KDE. It would be very useful for projects with more live branches.

http://weblate.readthedocs.org/en/latest/faq.html#how-do-i-translate-several -branches-at-once

Just now, only Tumbleweed is going to be imported.

openSUSE Weblate is in too early stage for SLE12sp1 and Leap.

For some languages there have been paid translators for the SLE releases. Would that change with the new system where all branches are merged in one po file? We have a translator in our team that is highly concerned that translating for a commercial product - that SLE is - could get him in troubles with his employer. -- Kind Regards, Michael

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-10-14 20:26, Stanislav Brabec wrote:

Dne 14.10.2015 v 19:13 Michael Skiba napsal(a):

Their co-ordination with openSUSE is still an open question.

Up to now, there was no co-ordination. It was a permanently diverging one-way work. Nobody merged SLE translations back to LCN SVN trunk, nobody watched for differences.

This was intentional. We decided not to do it. Instead, it is up to each language team to decide what to do. Basically, each translator compares the SLE translation with his own and decides what to use, string by string. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYfq5kACgkQtTMYHG2NR9W2awCfQqZYjNAgKP3oMPFnrgYnDCtF KpAAnRC7cGNeUUDwi78mJYHhd+1WB+wQ =NxEN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Dne 14.10.2015 v 20:15 Carlos E. R. napsal(a):

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2015-10-14 18:42, Stanislav Brabec wrote:

...

In case of SLE, the same policy will apply in early stages. After string review, SLE maintainers want to have 100% control over imported strings. https://github.com/nijel/weblate/issues/868

The same has been true for openSUSE stables: we want full control, and we often reject or replace the SLE translations made by the paid team.

I think that even that could be possible. But I don't like that idea. I am not a translator, but I guess that having one code, two teams, two opinions and no consensus is not a good solution. Not only for programmers. The situation in SLE is a bit different: SLE team has its own testers. Not only a software testers, but also a translation testers. They click through all supported applications in all supported languages. They review all strings, and report wrong things they see. Once such review is done, no changes are allowed except reported bug fixes. openSUSE releases have no such teams, so enforcing processes different from Tumbleweed seems to me as an overkill. If anybody founds a bug, it fixes it for Tumbleweed, and it gets fixed for release, if there is enough time to release the fix. -- 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: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Den 14. okt. 2015 18:21, Luiz Fernando Ranghetti skreiv:

...

...

I was told on IRC that weblate does support branches, but currently there are none, because SLE12sp1/Leap and Tumbleweed are pretty much all in sync currently.

Wonder if weblate will merge the different branches automatically, if the translator translates strings in one branch, which are valid for all the branches.

Maybe something like the summit operation of pology [1] which some KDE teams use (it creates a po file from multiple branches)

Actually I (the Norwegian Nynorsk team) already *use* the Pology summit framework for translating openSUSE. It’s working very well. Currently, I use it to simultaneously translate openSUSE 13.2 and trunk. (I had planned to also add SLES 12 SP1 to the mix, for use in Tumbleweed, but I never got confirmation on whether it was OK for non-paid translator to commit files to the SLES 12 SP1 branch in SVN.) If it’s easy fast and easy to download and upload the translation files from/to Weblate and branches are supported there, I’ll continue using this approach (and of course I’ll offer any scripts and config files to other teams that want to use it). BTW, the Pology summit framework is much more powerful than a simple ‘handle the same file in two branches’ approach. For example, it can handle applications that are split into several catalogues in some branches (e.g. an application in ‘stable’ is split into a application + library in ‘trunk’ (or the other way around, where several files are merged into one, but only in certain branches)). It also has intelligent ordering of strings: If two strings (from different branches) are very similar, they are placed next to each other in the resulting file. The translator can then easily compare them. So if a string in ‘stable’ is improved in ‘trunk’, e.g. to make it clearer (but the stable English string is not changed, perhaps because of a string freeze), the translator can choose to apply the translation of the improved string to *both* ‘stable’ and ‘trunk’, to the benefit of the users of the translated application. And Pology has integration with Lokalize, where you can choose to show only strings from a certain branch (e.g. to prioritise translation of strings in the branch which is due to release soon). (Personally, I have never had any use of this branch-filtering feature, but I have found Pology filtering with Lokalize synchronisation/filtering *in general* to be quite useful.) -- Karl Ove Hufthammer -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org