Re: [opensuse-translation] openSUSE Weblate
I have made a closer look at openSUSE Weblate after the Tomáš Chvátal explanation. Simple comparison: I use Lokalize and subversion's commands update, status and commit in 99.9% of translation work. I must have subversion installed, base knowledge about subversion background. There must be local working directory in PC. Statistics is available only once a day. Download/upload .po files is simple in Weblate. There is not needed any additional SW and any working directory to synchronise. I can still use Lokalize. Statistics is online. Ferdinand -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org
Den 11. okt. 2015 10:02, Ferdinand Galko skreiv:
I have made a closer look at openSUSE Weblate after the Tomáš Chvátal explanation.
Simple comparison:
I use Lokalize and subversion's commands update, status and commit in 99.9% of translation work. I must have subversion installed, base knowledge about subversion background. There must be local working directory in PC. Statistics is available only once a day.
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).
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. The reason I’m asking, is that I’ve used other Web-based translation systems where the people implementing it said not to worry, as one could still download and upload files and translate offline, but where doing so involved clicking on each translation file (several clicks per file), wait a seemingly random amount of time (varying from a few minutes to a few hours) to receive an e-mail. Also, there needs to be a way of mass-downloading the *template* files (.pot) instead of the translation files. Is this possible with Weblate? For my team, I need to do the merging with templates myself (for reasons I’ll not going into here, but they are good reasons, which saves work and improves quality). 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. -- Karl Ove Hufthammer -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org
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.) 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.) 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). 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. -- 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 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
Karl Ove Hufthammer <karl@huftis.org> 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. -- 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
Dne 12.10.2015 v 11:02 Karl Eichwalder napsal(a):
Karl Ove Hufthammer <karl@huftis.org> 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-12 11:02, Karl Eichwalder wrote:
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.
Some editors keep old versions of the strings in the same file as comments, so that on the next round of translations we can automatically see (highlighted) what exactly was changed in each string. Thus ALL comments in the .po file must be preserved. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYcP60ACgkQja8UbcUWM1zg6QD+J1FAbhD9oPdtDy9yEAYYXB1y nheBx2AItSx8N+NeCBwA/3SPJlQSLC06WB1ViKvrCoZNWAmANm/TwClyg1zDETx5 =uWVK -----END PGP SIGNATURE----- -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-10-12 11:12, Tomáš Chvátal wrote:
I told ya, it was not ready for announcement, we wanted to do it in this or next week...
Then, why didn't you create a separate test environment, instead of using our working files? - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYbsR8ACgkQtTMYHG2NR9UE4QCfZJyjBfWUkP9pn8An0cJ9GVvu RNcAn0/3/UTCrBtjJ6PWt+WiWC5THsho =51fM -----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: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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYbtG0ACgkQtTMYHG2NR9XndwCfcjSJKrfmoENzjVay/VWCpBSE QoYAn3026XIkyte9QogX7w0vjZVzMiNk =PITD -----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. - 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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. Finally, the translator submits the po file. No one can submit another po, so there are no conflicts. If the pot was changed meanwhile, there are two methods: a) the translator picks the pot and merges the modifications onto his working copy, and continues working before submitting it. b) he does the merge on the svn server. Notice that it is paramount that a single translator works on a given file all the time, and if possible, year after year, to ensure consistency and quality. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYcQTsACgkQja8UbcUWM1yL8wD/ZQrp1cHfHp66yibH0xygYHIV +MsNMzXvi72LY1tp2+0A/3+uvD2mXO/XL2YGFC/wKLKxjneMROfcS2i/B9jwbfZ6 =CsjL -----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. - 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-13 08:41, Michal Hrusecky wrote:
Carlos E. R. - 1:24 13.10.15 wrote:
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.
I may have missed it in all the bickshedding ;-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYc8jcACgkQja8UbcUWM1wTAQD+NSw+wI7Dv/ot8hBur3WGWpz6 lPxNT+EGqB6V5UtmVGoA/2NgERYrVRMB5JJB6+YxK7GtVvT1QMW8LtbsVK4kMT5X =hz+Z -----END PGP SIGNATURE----- -- 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: SHA1 On 2015-10-13 19:25, Karl Ove Hufthammer wrote:
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?
This is the second time today I hear this, yes.
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:
Yes. And what Karl Eichwalder did was ask one by one those developers for the pots. By email, phone, whatever. A lot of work. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYdQFsACgkQtTMYHG2NR9UeJQCeJnk5wlkxhHFK2Ul2Km9v1JzH ZfUAn39TX0tXNKeBgN59W67ZgbkpEwkN =7322 -----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 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
Den 11. okt. 2015 18:42, Carlos E. R. skreiv:
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.
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: 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). 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). 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. 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. -- 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 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
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.
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. -- Kind Regards, Michael
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
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).
And the local instance of GIT pushes changes to the upstream GIT.
-- 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
Am Montag, 12. Oktober 2015, 18:27:45 schrieb Tomáš Chvátal:
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 :)
That seems reasonable to me, but I'm a little bit concerned that these details get lost in the general discussion. I know that the beta has not started yet, but have you thought about how to discuss/fixate these details? Is there a wiki-style page for discussions or should this be done via an issue tracking software? -- Kind Regards, Michael
-----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
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 No, it _must_ be, because it is now one of two main distributions produced by the openSUSE Project Even for Leap, we must consider that the very concept of 'frozen' releases is becoming less and less relevant. Heck, even SUSE Linux Enterprise has modules which are constantly updated and so would require constant translations Our tools and processes need to update to face that challenge You cannot keep on doing things the way you always used to. This is no disrespect to the fine work you and others have done with translations in the past, but the things have to change. Welcome to 2015.
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 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 You had an opportunity to step up and help shape the solution to those problems. You declined. That makes you dependant on others to find solutions for you. Others have. You can either work with them to make it better, or be quiet, anything else is hypocrisy.
You have a you vs us the instant that a group (with suse addresses) implement huge changes to things without talking with the rest, that happen to have outside addresses.
Carlos, let me say this very clearly The _contributors_ who are _contributing_ Weblate are _CONTRIBUTORS_ like you 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. 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. -- 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
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. -- 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
On 13 October 2015 at 13:34, Carlos E. R. <robin.listas@telefonica.net> wrote:
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.
I trust the opinion and advice of those people on this thread and elsewhere who believe that we have the tools, technique, and the talent to do so. It's especially easy to give such trust when the message isn't just "this is possible" but "this is possible and we're going to do it"
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.
The only thing my email address ( rbrownccb@opensuse.org ) is a symptom of is 10 years of contribution to this project in a whole bunch of different capacities.
However, this might succeed with a "wiki" or collaborative type of approach, which weblate supports, because there are possibly hundreds of translators, translating simultaneously a few strings. At the price of consistency and diminished quality, of course.
Choose your pill ;-)
Let me see Weblate - Lower barrier to entry, workflow that encourages collaborative working, leading to more people understanding and working on Translation over time - Translated Tumbleweed - Better Translated Leap - Lower co-ordination requirements - Better alignment with Project's current products - Better alignment with development workflow Current - High barrier of entry - Single/limited translators are seen as a good thing in the name of 'quality' (any proof to back that up? On the development side of thing we're building a pretty impressive codebase without preventing new people contributing) - Many points of failure - High co-ordination requirements (more points of failure, translators sitting idle waiting for 'orders') - No Tumbleweed translation - No/Poorly Translated Leap Based on the information available on this thread alone, I know what my choice would be.
That's why experienced translators baulk at translating factory. Not because procedures or tools.
That's fine, at this point I'd rather encourage contributions from enthusiastic amateurs who believe they can do something, and try to make it happen, than experienced experts who believe that the situation is impossible so do nothing. Worst case, we end up where we are right now having learned something Best case, we end up with the best translated Linux distributions on the planet Win-Win -- 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
On 13 October 2015 at 14:28, Carlos E. R. <carlos.e.r@opensuse.org> wrote:
-----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.
- --
Oh that's quite alright, I think some of the 'devel team' have fixed that.. you can find the files to translate on http://l10n.opensuse.org/ ;) -- 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 <RBrownCCB@opensuse.org>: 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
Dne 14.10.2015 v 02:20 Alexander Melentev napsal(a):
2015-10-13 11:57 GMT+03:00 Richard Brown <RBrownCCB@opensuse.org>:
Carlos E. R. wrote:
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.
It is already possible to download them. Example: https://l10n.opensuse.org/projects/libstorage/master/cs/download/ Mass-upload is possible as well. I agree that publishing easy mass download scripts specially targeted to openSUSE server would be useful.
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.
There is an API: http://weblate.readthedocs.org/en/weblate-2.4/api.html (Well, we actually have 2.3 installed. I want to update to 2.4 + feature patches once it will be packaged. The version that will be installed will appear in M17N repo in OBS. Currently it is in home:Nijel:weblate.)
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.
Well, a small subset of packages with a low frequency of updates was intended as testcase. Once Weblate will be updated to version 2.4 and migrated to production servers, we planned official announce and officially start of beta testing. But people discovered the test server even earlier than I deleted files in LCN, probably in the scout bug, libgnomesu (with translation work-flow broken in LCN SVN trunk for > 5 years) or eiciel (which is not an openSUSE project, but most translations were done in Novell), and started to edit usin Weblate. First conflict appeared. I did not want to cause more conflicts, so I decided to delete files for test projects in LCN SVN. Migration of Release Notes (untranslatable for Leap until that migration) made our experiments visible earlier that we planned.
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.
No more translations migration will be done now. Migration of all packages would need a discussion with larger audience. I even think that several pot/po files in LCN SVN are just dead and unmaintained for years, and will need to merge, upstream or drop. As you mentioned, the LCN SVN process is not automated. Obsoleting of packages is not automated as well, and pot files tend to stay forever. -- 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
-----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 <RBrownCCB@opensuse.org>: 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
Hi all, I was travelling last days and now I am catching up with the long discussion. Now I must start the inline ranting... On 13/10/15 16: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
No, it _must_ be, because it is now one of two main distributions produced by the openSUSE Project
You are warmly invited to provide translations, if it _must_ be. The mantra is "whose wo do, decide"; here the "whose wo do" are the translators, so they decide. If you are not a translator, you are not entitled to decide because you don't do. Or is the mantra applicable only to those that code/develop/put packages together?
Even for Leap, we must consider that the very concept of 'frozen' releases is becoming less and less relevant.
Has someone asked comments from translators about possible issues with the new Leap? I have seen none, but since "those who do, decide" is applicable also here, Leap has been decided by those who actually make the distribution, so it was their right to decide.
Heck, even SUSE Linux Enterprise has modules which are constantly updated and so would require constant translations
I don't care at all, unless someone knowing this spends a minute to inform the translators about this. Wait, it is completely not my problem, as volunteers are not supposed to translate SLE parts and anyway their work will not be used for openSUSE when translation refers to parts coming from SLE.
Our tools and processes need to update to face that challenge
OK.
You cannot keep on doing things the way you always used to. This is no disrespect to the fine work you and others have done with translations in the past, but the things have to change. Welcome to 2015.
Sorry but my feeling is that really few have some consideration for the work of translators and only a small subset of them seems to consider the work of translators important enough to be taken and included in the distribution.
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
As wonderful as things might have been from your perspective, the reality is that the output of 'your' part was not working correctly
Well, to some sense this is the case, but for sure not translator's fault. The output of the translators is a bunch of files with the translations; if no one uses them, it is not a translator's fault at all. Example: https://bugzilla.opensuse.org/show_bug.cgi?id=906691 There the new translation has been ignored for 4 years. Is it my fault? No. You are putting the fault on translator's shoulders ("the output of 'your' part was not working correctly") instead of on the real culprit: the process of taking the completed translations was not working correctly. This is not equivalent to what you said and it matches better the reality.
Just look at Tumbleweed - Mostly untranslated, by your own omission
Is this a translator's fault?
Just look at Leap - Untranslated, by your own omission
Is this a translator's fault? Take the Italian translation I am providing: the files in the SVN are 100% translated. If Tumbleweed/Leap are distributed not translated, is it my fault?
You had an opportunity to step up and help shape the solution to those problems.
You declined.
That makes you dependant on others to find solutions for you. Others have. You can either work with them to make it better, or be quiet, anything else is hypocrisy.
You can work with them to make it better if *you know* that something is changing to improve the situation. Where is the communication of the changes? No communication at all, until it has been discovered by noting files disappear from the SVN server.
You have a you vs us the instant that a group (with suse addresses) implement huge changes to things without talking with the rest, that happen to have outside addresses.
Carlos, let me say this very clearly
The _contributors_ who are _contributing_ Weblate are _CONTRIBUTORS_ like you
But when the time of decision comes, it seems to me that some contributors are more contributors than others...
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.
This is just a nice phrase, but is it applied in the real world? and moreover, does it imply that the value is given in equal way to different contributions?
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.
I will continue my rant on your other mail... Best, Andrea -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-10-14 20:00, Stanislav Brabec wrote:
Dne 13.10.2015 v 01:29 Carlos E. R. napsal(a):
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.
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. What is needed then is an rpm that holds the partial translations, and only translations, not libraries or programs. Just place them in an optional repo, and keep it automatically updated by a cron job. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYemk4ACgkQtTMYHG2NR9UQRwCeIm2L7jUFvqMjrs1WDwkoBwtT ttAAmgIMQauFrvwdgl8h6sw3dpwSnYcl =P1/B -----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: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
On 2015-10-14 20:45, Stanislav Brabec wrote:
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.
Oh :-o
It is just an idea, nothing is written yet.
I see... But you want this on every machine? :-? It could cause unwanted internet activity. Consider that not everybody has full internet access. It can be metered, or caped. Thus this should be optional feature. For translators and testers, that's different. Oh, and the .mo has to match the application version: you can not just download the latest. :-' -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYfreYACgkQtTMYHG2NR9VIoACfVAymtJPLgzltYYJagyeQ23K6 TkcAn2BcybPJ07J2VoLkI2pb8add6oip =EpUT -----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." <carlos.e.r@opensuse.org> 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-10-19 12:51, Karl Eichwalder wrote:
"Carlos E. R." <carlos.e.r@opensuse.org> 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.
What do you mean, about SLE and openSUSE different translations? What do you propose? :-? - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYkzisACgkQtTMYHG2NR9WWfgCeKcdlG4ilnYH1Y9vmwt2LfnvM PjMAoIc5DMh4mVQPhzGX2xZ8QEioUM6q =/cdA -----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." <carlos.e.r@opensuse.org> 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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? - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYk/j0ACgkQja8UbcUWM1yUcQD/deCo97v1ev0bu8abercJfwIY vVkPBJyx/e2T8sbt91kA/3F5sV8CpMhIZmDJs5y3T35zlUqs/QfPPNzhilUj16aM =4y6x -----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." <carlos.e.r@opensuse.org> 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-19 16:34, Karl Eichwalder wrote:
"Carlos E. R." <carlos.e.r@opensuse.org> 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.
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. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYlASQACgkQja8UbcUWM1ys1QD/UljYjlbeL29D7sGTwJuRsL27 +3OF5L5ad1C1JHXmmSQA/0wNM9OqGcoHXDtBFswzQ1OQsGAMY27XH05zihGG9nAs =Ttx9 -----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." <carlos.e.r@opensuse.org> 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-19 17:10, Karl Eichwalder wrote:
"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.
But I do not want to see my translation in SLES, nor do I want to see their translation in openSUSE. This is documented policy since ever, agreed by decision of majority members of the Spanish team. Those who do, decide, remember ;-) 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. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYlF+MACgkQja8UbcUWM1wbRAD9FLD+pLl04i4dSKOcz5CCKW2k AFD2M851LZQee91plxIA/jeeRr7YYjNPs/p9TK9/h3useySaDzMBccEMp2xR6hl8 =9txd -----END PGP SIGNATURE----- -- 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. <carlos.e.r@opensuse.org> 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-19 18:46, Richard Brown wrote:
On 19 October 2015 at 18:18, Carlos E. R. <carlos.e.r@opensuse.org> 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?
Of course I do. Or we do, because it is not only me; as usual, I'm only once which talks more ;-) There is in fact an ethics conflict, like it or not. Me, for instance, object to translate a file that an SLES paid translator intended or hoped to translate, because I'm reducing his earnings, his sustenance. Some one from another team said here, not a week ago, that he had team member(s) whose employer would be quite annoyed at finding that he was translating for free files for SLES, that his company intended to translate. A very serious concern, he said. Translators in my team told me in the past that they did not want to translate applications that were only available on SLES - the typical example was the yast registration module. Others simply object to translate something that ends in SLES, and not being paid for it. But nobody can object if an SLES paid translator picks the translation from an openSUSE, and uses it as is. The gettext system does not track credits, and the translations are open. By the way... I just looked at a random 2013 po from yast (what I have available this instant without moving from my comfortable chair). It is copyrighted by SUSE (some by SuSE), there is no mention of GPL inside. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYlT1EACgkQja8UbcUWM1xSnQEAnQpDihY1M+/HyaH4es93PoIY FwQf8wDG649t7CpswS0A/1pofyjJPu/DvFOLvZKYimF3eJQuGtC787mHzqQhKMz2 =elZ/ -----END PGP SIGNATURE----- -- 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
Dne 14.10.2015 v 23:06 Karl Ove Hufthammer napsal(a):
Den 14. okt. 2015 20:00, Stanislav Brabec skreiv:
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
It was as easy as you write in ancient age of desktop toolkits. Now the messages are spread over many translation domains. Typical GNOME application loads strings from the application itself, gtk, atk, glib, glibc, some of GNOME libraries, possibly gstreamer and other). For example, such as simple application like gnome-calculator loads: atk10 glib20 gnome-calculator gtksourceview-3.0 gtk30 gtk30-properties pulseaudio -- 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
-----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 15.10.2015 v 15:30 Carlos E. R. napsal(a):
And in the case of openSUSE translators, we only translate those things where openSUSE is the upstream, meaning that things are easier to locate ;-)
Even there you can see strings and buttons translated in other domain. Not as easy as it looks. I even write a string locator to make this task easier: https://en.opensuse.org/Help:Translations:Bugs#watch-gettext https://build.opensuse.org/package/show/home:sbrabec/watch-gettext
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.
It would be nice, but I have no idea how it could be done. Some windows are even built on fly. For glade or other UI builder, it could be easy however. -- 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 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 12.10.2015 v 18:22 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 ;-)
Sorry for confusion, the is OR, not AND: Translation reached 100% => push it NOW Translation got any change => wait 2 hours, and if no edit appears, push (2 hours is the default for l10n.opensuse.org, upstream default is 2 days.)
Normally something like 70-75% completeness is required for translations to be shipped (if any criteria at all).
YaST team would like to see 50%. It is not yet implemented, but it is something to consider. Anyway, even 1% sometimes makes sense: One string is visible daily, the rest are error messages. User is angry to always see English string, and translates just this single string. By the way, I wrote a translation string locator for similar purposes: https://en.opensuse.org/Help:Translations:Bugs#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
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. -- 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 <martin.schlander@gmail.com>:
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
Dne 14.10.2015 v 18:21 Luiz Fernando Ranghetti napsal(a):
2015-10-14 13:12 GMT-03:00 Martin Schlander <martin.schlander@gmail.com>:
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)
Exactly. 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... Just now, only Tumbleweed is going to be imported. openSUSE Weblate is in too early stage for SLE12sp1 and Leap. It probably makes sense to hard join openSUSE branches and Tumbleweed. People reviewing translations in openSUSE Tumbleweed will be the same as people involved in openSUSE releases. 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 -- 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
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
Dne 14.10.2015 v 19:13 Michael Skiba napsal(a):
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?
It depends on different managers and their budget, but I would say that paid translators will be kept. 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. It needs a change. The translation imported to GitHub by me already include strings from SLE12 SP1 that were missing in trunk. Review of changes is still an open question, but the Mass Review Request API was implemented to Weblate this week.
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.
From a legal aspect, you are translating GPL product, and in say 99.5% you are translating a GPL product released free for public. Anybody can legally branch GPL product and make a commercial product, so I see no problem in this point. But yes, I can see a problem if you translate that say 0.5% of strings that are SLE specific. You are still translating GPL product, but it is provided solely as a service to our customers. I guess that could be fixable if: 1. Each string has visible branches where it is translated. 2. Weblate would allow you to translate only subset of branches (i. e. it will make SLE specific strings invisible). Such feature does not exist yet, but I guess it could be implemented. Regarding my 0.5% guess: Our current software development policy is simple: Each change in SLE has to be earlier or later reflected somehow in Tumbleweed. In case of straightforward upstreaming of the patch, the string will appear in Tumbleweed early after SLE. But sometimes Tumbleweed is far ahead from SLE, and strings there will be different. => SLE specific string will exist. Here is my guess based on my translation-update-upstream work: - 90% of strings are common for Tumbleweed and SLE. - 9% of strings were sometimes in Tumbleweed in past, but now they are no more there. But SLE still uses it (and Leap will probably inherit them as well). - 0.5% of strings were never in Tumbleweed, but were inherited from SLE to Leap. - 0.5% of strings are solely for SLE product, and will never reach anything other. -- 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
-----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
-----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. The policy varies per language team. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYem8IACgkQtTMYHG2NR9WXywCffOnCtV0B3T7j4LNF/iZamjoU s/YAn2qaG2WY+AUgA+1IN1Nsq+jbucs/ =8rfF -----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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-10-14 20:39, Stanislav Brabec wrote:
Dne 14.10.2015 v 20:15 Carlos E. R. napsal(a):
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.
But you see, translators here work in the open. If the team is large enough, they have their set of rules and glossaries that they work with. Nobody knows what the paid translators use; often they are good, but their choices often are 90 degrees to the team decisions. That's why several teams decided to ignore them, less work and more consistent quality. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYfrLAACgkQtTMYHG2NR9Wa+wCZAdd4Dd0s5VIibgeWFeVjBrca 2DoAnjTkFMQfCQn6bVuZbJ2C/KSe1JSf =dV3C -----END PGP SIGNATURE----- -- 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
Karl Ove Hufthammer <karl@huftis.org> writes:
(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.)
Concerning yast, there is currently no need to submit "unofficial" languages to SLE 12 SP1. Additionally to the "official" languages I take the other languages from trunk and put all in one yast2-trans source package. This will be build on SLE 12 SP1 and Leap 42.1. Once Leap 42.1 and SLE 12 SP1 are done, we will check how we best continue with the next releases. It would be great if you'd install Leap and report whether translations are in place. -- 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
participants (15)
-
Alexander Melentev -
Andrea Turrini -
Carlos E. R. -
Carlos E. R. -
Ferdinand Galko -
Karl Eichwalder -
Karl Ove Hufthammer -
Luiz Fernando Ranghetti -
Martin Schlander -
Michael Skiba -
Michal Hrusecky -
Richard Brown -
Stanislav Brabec -
Stanislav Brabec -
Tomáš Chvátal