Am 05.03.2016 um 16:30 schrieb Antoine Belvire:

Hello,

Le 05/03/2016 14:05, Alexander Melentev a écrit :

...

Hi all I've just noticed it today, but hope somebody will give a hint when this has actually happened. I ran zypper and found out that it's translations are not taken from our svn trunk anymore.

I did a bug report for this: https://bugzilla.opensuse.org/show_bug.cgi?id=968588.

It was triggered by this: https://build.opensuse.org/request/show/360451 which was decided because of this bug: https://bugzilla.novell.com/show_bug.cgi?id=948924.

Are you missing translations or are there bugs in the SLE translations? Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

On 07.03.2016 08:07, Antoine Belvire wrote:

Le 07/03/2016 07:55, Stephan Kulow a écrit :

...

Am 05.03.2016 um 16:30 schrieb Antoine Belvire:

...

Hello,

Le 05/03/2016 14:05, Alexander Melentev a écrit :

...

Hi all I've just noticed it today, but hope somebody will give a hint when this has actually happened. I ran zypper and found out that it's translations are not taken from our svn trunk anymore.

I did a bug report for this: https://bugzilla.opensuse.org/show_bug.cgi?id=968588.

It was triggered by this: https://build.opensuse.org/request/show/360451 which was decided because of this bug: https://bugzilla.novell.com/show_bug.cgi?id=948924.

Are you missing translations or are there bugs in the SLE translations?

Greetings, Stephan

I can speak only for French: missing translations and strange translations. Community version is clearly better to me.

Hi Antoine, Please report strange translations as openSUSE Leap bugs - no one gains anything if you leave strange translations to Leap users. Translations that exist in master, but are not in TW zypper are a bug, but we can't continue with "them vs us" when it comes to supported languages. If the SLE translators doesn't listen to your feedback, we need to talk to them again - but first we need that feedback. I can't talk to them, this needs to be a discussion held in french ;) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Hi, The best would be: for everything the community translate, always use community translations for openSUSE products. As simple as that. Regards, Luiz pt_BR translator 2016-03-07 10:04 GMT-03:00 Alexander Melentev :

Hi Stephan,

I can confirm Antoine's problem descriptions for Russian also, a lot of SLE translations were made using machine translation some years ago and also merged to openSUSE. I've joined openSUSE-i18n a few days before 11.0 release and all these years were spent in wiping out/fixing/polishing those strange translations. Currently I have thousands of differences and I can hardly imagine reporting them all. It looks like other languages have similar problems: we can't push our translations to SLE, cause there is another team with their own translations, but we cannot accept SLE translations to openSUSE, cause of lower quality. Currently it looks like SLE is considered as a better source of translations while it is not (well, at least for French and Russian, but probably for some other languages also). Maybe it makes sense to prefer openSUSE-i18n over SLE or build separate lang packages with community translations for Leap, so that users can select what is better for them? Cause even if we all somehow agree on fixing all the translations, it is a huge work which will take a lot of time.

2016-03-07 12:47 GMT+03:00 Stephan Kulow :

...

On 07.03.2016 08:07, Antoine Belvire wrote:

...

Le 07/03/2016 07:55, Stephan Kulow a écrit :

...

Am 05.03.2016 um 16:30 schrieb Antoine Belvire:

...

Hello,

Le 05/03/2016 14:05, Alexander Melentev a écrit :

...

Hi all I've just noticed it today, but hope somebody will give a hint when this has actually happened. I ran zypper and found out that it's translations are not taken from our svn trunk anymore.

I did a bug report for this: https://bugzilla.opensuse.org/show_bug.cgi?id=968588.

It was triggered by this: https://build.opensuse.org/request/show/360451 which was decided because of this bug: https://bugzilla.novell.com/show_bug.cgi?id=948924.

Are you missing translations or are there bugs in the SLE translations?

Greetings, Stephan

I can speak only for French: missing translations and strange translations. Community version is clearly better to me.

Hi Antoine,

Please report strange translations as openSUSE Leap bugs - no one gains anything if you leave strange translations to Leap users.

Translations that exist in master, but are not in TW zypper are a bug, but we can't continue with "them vs us" when it comes to supported languages.

If the SLE translators doesn't listen to your feedback, we need to talk to them again - but first we need that feedback. I can't talk to them, this needs to be a discussion held in french ;)

Greetings, Stephan

-- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

-- Regards, Minton. -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

On 2016-03-07 15:42, Stephan Kulow wrote:

On 07.03.2016 15:00, Luiz Fernando Ranghetti wrote:

...

Hi,

The best would be: for everything the community translate, always use community translations for openSUSE products. As simple as that.

I can understand your point of view, but it's not "as simple as that".

It has been that way since ever. I can tell that the Spanish team rejected the SLE translation and we have always done our own translation. There were always different and separate translation directories for openSUSE and SLE. If you insist on on merging them, you get these problems. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-03-07 17:49, Stephan Kulow wrote:

Am 07.03.2016 um 15:48 schrieb Carlos E. R.:

...

On 2016-03-07 15:42, Stephan Kulow wrote:

...

On 07.03.2016 15:00, Luiz Fernando Ranghetti wrote:

...

Hi,

The best would be: for everything the community translate, always use community translations for openSUSE products. As simple as that.

I can understand your point of view, but it's not "as simple as that".

...

It has been that way since ever. I can tell that the Spanish team That is far from true. What is true is that we had a couple of openSUSE releases over the last years which were completely decoupled from SLE releases and we fixed that for Leap 42.1.

Not for Spanish. We took good care to reject the SLE translations and use our own. We voted years ago and took a decision. Leap was not translated at all on our part. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

2016-03-07 11:51 GMT-03:00 Richard Brown :

On 7 March 2016 at 15:42, Stephan Kulow wrote:

...

On 07.03.2016 15:00, Luiz Fernando Ranghetti wrote:

...

Hi,

The best would be: for everything the community translate, always use community translations for openSUSE products. As simple as that.

I can understand your point of view, but it's not "as simple as that".

Agreed, I think a much better starting point is by filing bugs against those translations in Leap and Tumbleweed that have been contributed to openSUSE from SUSE

Remember, it's an equally valid point of view that SUSE is a community contributor to openSUSE too..

who is to say that those translations are innately more invalid than those from other community members?

Both points of view are valid, but nothing can be fixed in either direction with concrete, solid, measurable items requiring actions

So, please, please, file the bugs --

Hi, What if, as an hypothetical example, there is an translation error/new strings in zypper that only affect Leap, but not SLE. The SLE translators will fix it or not as it's out of they job scope? Just for the records the pt_BR don't have all this mess, its just different, both are correct and valid, but I prefer our... :-P Regards, Luiz -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

2016-03-07 17:51 GMT+03:00 Richard Brown :

On 7 March 2016 at 15:42, Stephan Kulow wrote:

...

On 07.03.2016 15:00, Luiz Fernando Ranghetti wrote:

...

Hi,

The best would be: for everything the community translate, always use community translations for openSUSE products. As simple as that.

I can understand your point of view, but it's not "as simple as that".

Agreed, I think a much better starting point is by filing bugs against those translations in Leap and Tumbleweed that have been contributed to openSUSE from SUSE Please see my simple calculation in previous mail proving it impossible for one man. Also I am pretty sure that e.g. Russian translation is not coming from SUSE at all, so a separate company took care of it.

Remember, it's an equally valid point of view that SUSE is a community contributor to openSUSE too.. Oh, please don't bring this fairy tale here, we all live in the real world and understand that "All contributors are equal, but SUSE is more equal than others". But we are all fine with that situation, cause it was always like that. I am forbidden to fix any error in SLE translations, but SUSE developers prefer SLE translations over community ones even for community releases like openSUSE. It is more or less understandable for Leap as it is "SLE-based", but pushing it to Tumbleweed is just too much.

who is to say that those translations are innately more invalid than those from other community members? And who is to say those translations are better than community ones? "Equality" works in both directions =) Well, the translations quality is completely different issue. I can say for my native language only and I understand that my word is not a proof here, but that's the only feedback you have: my translations are not perfect, I know this, but

I am not a professional translator at all, but I've spent many years translating openSUSE. People reported the issues they saw and I fixed'em and reported back, but when Leap was released I had plently of awkward moments with other guys from Russian community as I had to reject thei reports and say things like "It wasn't me", "I have nothing to do with this" and "Sorry, I can't fix this for you". I completely understand that there was no bad will in pushing SLE translations to Leap (for e.g. Russian the decision was just plain wrong), but please understand that I have only good will either trying to prevent pushing them at least to TW. the quality of SLE translations is really different from file to file. A couple of recent yast modules had pretty good translations and I have even merged them to our trunk to not duplicate the work, but the older the message is, the higher chances are its translation is rubbish. As the merge of "rubbish" messages happened many years ago let's call them "legacy translations". So the main problem with SLE translations quality as I see it is that no proofreading was done for legacy ones. Current state of things is broken: we have two different sets of translations and no way to collaborate on merging them without conflict of interests (SLE translators are paid ones and we are community volunteers). I am more than willing to help fix this, but we really need some more valid way than reporting issues one-by-one...

Both points of view are valid, but nothing can be fixed in either direction with concrete, solid, measurable items requiring actions Would you mind to re-phrase? I've lost your point here.

-- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

-- Regards, Minton. -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

On 08.03.2016 09:33, Carlos E. R. wrote:

On 2016-03-08 00:55, Alexander Melentev wrote:

Now, on leap, there is no directory at all and we simply can not work at all.

Lo siento, pero es tiempo para cambiar. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Carlos E. R. wrote:

On 2016-03-08 11:53, Stephan Kulow wrote:

...

On 08.03.2016 09:33, Carlos E. R. wrote:

...

On 2016-03-08 00:55, Alexander Melentev wrote:

...

Now, on leap, there is no directory at all and we simply can not work at all.

Lo siento, pero es tiempo para cambiar.

Feel free to talk to the rest of the Spanish team or find more contributors somewhere. I asked them to push forward, to find how to contribute now. I simply am unable to see how I can contribute translations to Leap. Other team members have expressed similar thoughts. None stepped up, as far as I know.

As to factory aka tumbleweed, only one member was actively translating but he abandoned when he saw that his work was not used. His .po files where uploaded to trunk, but nobody pushed them to the devs. He had to stop trying.

I think it's safe to say that noone is happy with the current situation. We need to do something about it and that most likely means some compromise for all involved parties. In the specific case of zypper for example I have a hard time understanding why it's translations are on svn.o.o rather than right in the source repo on github in a po subdirectory next to the code. Ie like pretty much any other upstream project. If translations were there it would be pretty clear which ones are used and where contributions have to go. No matter whether done by paid translators or volunteers. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

On 2016-03-10 16:24, Ludwig Nussel wrote:

Carlos E. R. wrote:

I think it's safe to say that noone is happy with the current situation. We need to do something about it and that most likely means some compromise for all involved parties. In the specific case of zypper for example I have a hard time understanding why it's translations are on svn.o.o rather than right in the source repo on github in a po subdirectory next to the code. Ie like pretty much any other upstream project. If translations were there it would be pretty clear which ones are used and where contributions have to go. No matter whether done by paid translators or volunteers.

On all the upstream projects where I participate, translators have no access to the source tree. That's only for developers. For instance, with the "Translation Project" (http://translationproject.org/), developers submit the .pot file in a manner I don't know to a centralized server for all translated projects in the "Translation Project", and from there, a robot mails notices to the translators. These pick the files from that server (we have read access to this one, not write), translate them, and submit them via email robot back to the server. I suppose the robot sends an email to the devs to pick it up. Translation is only done once the developers submit a release, not for work in progress (would be similar to factory). Check how KDE team work (upstream). I will not describe it, as I don't work there, but they have directories where all files are stored for translation. Other people here can describe the process (I think somebody did, not very long ago). You see, the separation in a different server that centralizes translation work is normal. As a translator, I can not go navigating a zillion directories to find files to translate. A coder normally works in the scope of a project, say "zypper". There he sees many *.c files, say, and works in some of them. I suppose. But a translator works in the scope of many different and separate programs, say "KDE", where he will see many *.pot and *.po files, one per package or program typically. I need them centralized. It doesn't matter to me much what is the method or engine that does the centralization. I need a single directory, at most a few, in which I can see at a glance work to be done. If there is a team of translators, I also need something to assign and control who does what file. If you want to change that methodology round, ok go ahead. But if me doesn't like it or feel comfortable with the new method, I won't be able to work with it. Nor will I be able to instruct others on how to proceed. Others may work with the new method, of course, and instruct others in turn. But this is what has not happened, at least on the Spanish team, and I'm afraid nobody is translating leap nor tumbleweed. Please do not blame me: I asked other people to go ahead. I'm only the messenger, the relator. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-03-10 19:04, Karl Ove Hufthammer wrote:

Carlos E. R. skreiv 10. mars 2016 18:32:

...

On all the upstream projects where I participate, translators have no access to the source tree. That's only for developers.

I have participated in several projects where the translators (at least some of them) have commit access to the source tree.

Me in none. Only here, openSUSE, I have access to the translation svn server. On the rest, I access by email, automated or fully manual.

...

For instance, with the "Translation Project" ... Translation is only done once the developers submit a release, not for work in progress (would be similar to factory).

IMHO, the way the ‘Translation Project’ works is far from ideal. Your last comment is a case in point; it’s much better if the translators can work on translations continuously, instead of just before a release (and then have to translate a large number of strings at once). And having to send e-mails to update translations is a pain.

I dislike working on a translation continuously. It is a pain. I translate a string, and the next day a dev changes it and I have to change it too. Once, a dev revised (sed?) all strings adding stops to hundreds of sentences. I had to re-translate hundreds of strings. Of course, trivial change, but still, many strings. Hours. I prefer working on a project that is not changing. It is a personal choice. That's why I don't translate factory (even if I could, which currently I can't). Others do like to translate factory. Aside that, the TP is quite bureaucratical, yes.

...

Check how KDE team work (upstream). I will not describe it, as I don't work there, but they have directories where all files are stored for translation. Other people here can describe the process (I think somebody did, not very long ago).

I work as a translator for KDE. There the translators have commit access, and fetch and commit translations using SVN. It works extremely well. Translators just have to do a

svn up

to fetch the files, translate them and then do a

svn commit

But not against the source tree the devs use, but your own, for translation, right?

The translations automatically appear in the released applications (it feels almost like magic :) ). And the translations files are automatically updated (with new/changes strings) each night¹. Easy peasy, and no hassle for the translators. (And when an application is renamed, moved, split into an application + library or have other changes that need changes in the translation files (this happens frequently), the nice people at KDE automatically do the needed changes to all the translation files.)

What about different releases, how are they handled?

In KDE, all applications used to live in the same SVN repository. But a few years ago they were split into multiple Git repositories, stored in several different places (e.g., some at GitHub) (and a few applications stayed in SVN). But it was decided that keeping the central SVN (not Git) repository for translations would be best. So that’s what we use, and it works perfectly. Each language has its own directory (and there’s of course also a templates directory).

The other option would be for the translator to manually hunt down each and every application and library (there are many hundreds) repository, and manually fetch the source code and commit the translations to them (or send pull requests), which would of course be untenable. Even having to download the hundred of gigabytes of data from the repositories would be difficult for most translators. But now they just have to type

svn up

To get all the latest translations files (for one’s language) to translate. It’s even faster than launching a browser. :) Could anything be simpler?

Yes, the methodology at KDE is wonderful :-) I would love that here.

Footnote: ¹ I said that in KDE the translations files are automatically updated (with new/changes strings) each night. Note that it’s also possible to opt out of this (by placing a ‘magic’ file in one language’s translation directory), and merge the translation files oneselves, if one prefers. Some teams prefer this, and there are some advantages in getting to decide when (and how) to update the translation files.

It gets a nuisance when your working copy doesn't match the copy on the svn. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-03-10 21:35, Karl Ove Hufthammer wrote:

Carlos E. R. skreiv 10. mars 2016 19:20:

...

But not against the source tree the devs use, but your own, for translation, right?

Originally, it was the same source tree, and every KDE contributor (including translator coordinators) had commit access (except for certain directories).

Aha.

...

What about different releases, how are they handled?

KDE currently has *four* branches, which we can call (slightly simplifying the names) KDE 4 stable, KDE 4 trunk, KDE 5 stable and KDE 5 trunk. Each application exists in one or more of these.

From what I’ve understood (I haven’t developed a KDE application myself), it’s the application developer’s responsibility to define (using a Web interface, I think) which branch (and source repository?) the above branches correspond to. Typically, ‘trunk’ is set to a ‘master’ branch, while the ‘stable’ version is set to ‘release-xx’ branch (which change over time). The translation template files are automatically extracted from the source repository (using a special script in the source repository).

The translators can choose to work on each branch (stored as a separate *directory* on the SVN server) separately (or perhaps just on the two stable branches), or in a special directory which (basically) contains the union of the files from each branch (so when you translate app.po, it will contain all the strings for ‘app’ which exist in at least on branch), using the ‘summit’ framework described here: http://pology.nedohodnik.net/doc/user/en_US/ch-summit.html

I see. Very nicely done.

...

It gets a nuisance when your working copy doesn't match the copy on the svn.

Are you thinking of the case that the PO file has been merged with an updated template file while you had uncommited changes? Yes, that’s one reason to run the merging script yourself.

Yes, exactly.

(Though even if you have a conflict, it’s less of a problem than people make it out to be; you would just answer ‘mine-full’ or ‘theirs-full’ when svn asks how you want to handle the conflict.)

Yes. I do mine full, then do a merge from the pot to get the modified/new/deleted strings. This might be automated, I guess. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

That sounds severe indeed. The main reason we can't just throw away the SLE translations is that the SLE translators also translate the manuals and having the tools and the documentation in sync is very valuable to customers. Now if the documentation also uses this machine translation way you describe, it makes you wonder how useful the Russian manual is ;( Well, even if I'm sure this manual is not that useful in Russian, that is not my main concern. I wasn't suggesting to "just throw away" anything, exactly because SLE translations are paid translations and

But as I said previously: if the problem with our translations is so bad, we need to fix it for real. Not just hide it for Tumbleweed. So it's great we're having this discussion, because I'm certain in the end we will see a solution that will please all Russian (open)SUSE users. I hope so, too. I am really willing to rectify this situation somehow, but reporting translation differences is a dead-born idea. yast+lcn have almost 35k messages, some SLE translations are OK, just different but some are horrible,but even if we all be really kind and say that only 10% worth a report, doing so with 10 bugreports a day will take me almost a year. So I would really like to have some other way to fix

2016-03-07 17:47 GMT+03:00 Stephan Kulow : they are there to add value to SLE releases to make customers happier. But I have nothing to do with this, I am community volunteer who translates openSUSE releases only, cause community contributions to SLE branches are forbidden. My point was about Leap (even though it is SLE-based) and TW as they are still openSUSE releases which deserve (and are implied) to have openSUSE translations. those issues. -- Regards, Minton. -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

Am 08.03.2016 um 06:24 schrieb Stephan Kulow:

Am 07.03.2016 um 23:53 schrieb Alexander Melentev:

...

but some are horrible,but even if we all be really kind and say that only 10% worth a report, doing so with 10 bugreports a day will take me almost a year. So I would really like to have some other way to fix those issues.

One bug report stating 10 horrible examples will be enough for us to get back to the SLE translators. Remember we pay them to do good translations, so we expect better than horrible.

To make that point clear: the 10 above is not a limit I meant to imply. The 10 was just picked up from Alexander's mail :) Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org

2016-03-14 8:39 GMT-03:00 Alexander Melentev :

2016-03-08 8:24 GMT+03:00 Stephan Kulow :

...

Am 07.03.2016 um 23:53 schrieb Alexander Melentev:

...

but some are horrible,but even if we all be really kind and say that only 10% worth a report, doing so with 10 bugreports a day will take me almost a year. So I would really like to have some other way to fix those issues.

One bug report stating 10 horrible examples will be enough for us to get back to the SLE translators. Remember we pay them to do good translations, so we expect better than horrible. Well, after some thinking about this I decided to report a couple of modules to see how this will be handled. But there's another problem: I need to report the bugs based on the SVN translations in some SLE branch. So, my main question is which SLE version is the souce for Leap translations? I'd appreciate a hint, so I can diff/sync/whatever... Moreover, should I report against Leap or SLE? I'm not a user of either of them.

Leap, so the bug is public by default, and we are caring for openSUSE mainly. Luiz -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org