[opensuse-translation] zypper in openSUSE using SLED translations instead of openSUSE ones
Hi Karl and all! I noted that the zypper in the update repository uses SLED translations instead of the one we do. I find it while using zypper, a saw that the message who appears in the screen was differente than the one I translate (and had a typo in pt_BR :-) zypp.pt_BR: * original string: Retrieving repository '%s' metadata * SLED: Recuperandoos metadados do repositório '%s' (Should be >> "Recuperando os..") * openSUSE: Obtendo os metadados do repositório '%s' The sentences are equivalent, no problem there, the problem is that this string is translated for openSUSE so why use the SLED version? Regards. Luiz -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Hi!
I can confirm for german, that many (only?) SLED translations are used
atm for Factory. For example the Yast or the desktop translations
reintroduced errors already fixed for openSUSE and uses in many parts
a worse and less consistent translation as openSUSE in 11.1. If it is
sure that they don't affect or overwrite our translations in openSUSE
it would be ok for me, but I really wonder if paying someone for these
"translations" is really well invested money...
Kind regards, Jannick
2009/2/26 Luiz Fernando Ranghetti
Hi Karl and all!
I noted that the zypper in the update repository uses SLED translations instead of the one we do.
I find it while using zypper, a saw that the message who appears in the screen was differente than the one I translate (and had a typo in pt_BR :-)
zypp.pt_BR:
* original string: Retrieving repository '%s' metadata
* SLED: Recuperandoos metadados do repositório '%s' (Should be >> "Recuperando os..")
* openSUSE: Obtendo os metadados do repositório '%s'
The sentences are equivalent, no problem there, the problem is that this string is translated for openSUSE so why use the SLED version?
Regards.
Luiz -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2009-02-26 at 18:24 -0300, Luiz Fernando Ranghetti wrote:
Hi Karl and all!
I noted that the zypper in the update repository uses SLED translations instead of the one we do.
I find it while using zypper, a saw that the message who appears in the screen was differente than the one I translate (and had a typo in pt_BR :-)
Confirmed. :-///
Spanish is using the SLE/SLED translation of zypper - at least.
# rpm -q zypper
zypper-1.0.5-2.1.2
That's the binary rpm. The sources are here:
http://download.opensuse.org/update/11.1/rpm/src/zypper-1.0.5-2.1.2.src.rpm
Expanding the es.po file, I see:
# Copyright (C) 2006 SuSE Linux Products GmbH, Nuernberg
# This file is distributed under the same license as the package.
#
msgid ""
msgstr ""
"Project-Id-Version: zypper\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2008-12-09 18:17+0100\n"
"PO-Revision-Date: 2009-01-06 09:41\n"
"Last-Translator: Novell Language
Fredag 27. februar 2009 03:26:13 skrev Carlos E. R.:
I find this demeaning of our work. I'll have to consider stoping my collaboration if this is not reverted, for all files affected.
:-|
If you are going to use somebody else's translation, after all the work we have invested, I see no use in translating anything further. You can do it on your own. :-/
Well, as this after all is volunteer work I don't actually find it "demeaning" but I do find it counter productive. I don't know about other languages but for my language (nb), openSUSE translations are generally of a higher quality than SLES/SLED translations. Therefore, the quality of openSUSE translations will drop considerably every time SLED/SLES translations are merged before a translation round. This is a general observation and I'm sure there are examples to the opposite effect, both for other languages and for individual strings. Still, I don't think it is a good idea to replace good translations with bad ones, and I find it particularly counter-productive to reinsert typos and translation errors from SLED/SLES that openSUSE translators have corrected during previous rounds It feels rather meaningless to proofread the same strings and correct the same errors over and over again, and translators will of course give up in the end and just leave these bad translation "as is". I do exactly that, i.e. give up an leave reoccurring errors, but I don't like it because files with funny translations will be tagged with my name if I am the last person who has edited a particular file, although most of the funny stuff is produced elsewhere :-). . Here is my suggestion: DO NOT MERGE SLES/SLED TRANSLATIONS AT ALL but make the SLES/SLED translation memory available as a tmx file or something for openSUSE translatiors, That way we can use or disregard the SLES/SLED translation for any particular string. Cheers Olav -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Olav P. skrev:
Here is my suggestion:
DO NOT MERGE SLES/SLED TRANSLATIONS AT ALL but make the SLES/SLED translation memory available as a tmx file or something for openSUSE translatiors, That way we can use or disregard the SLES/SLED translation for any particular string.
Having it mandatory for SLES/SLED translators to use openSUSE translations at least for reference *and* to either QA the whole result in their paid time or use the existing volunteer QA and align the rest of SLES/SLED translations and terminology according to openSUSE would also be an option. My guess is that the quality assurance in SLES/SLED is not on a par with the open effort, that is or at least may be using peer review. Who does the QA in SLES/SLED in the respective languages? At the very least, some communication between the two translation efforts might turn this dual effort situation into something productive both in terms of output and quality. In both varieties. BR, Gudmund -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
On Fri, Feb 27, 2009 at 9:55 AM, Gudmund Areskoug
Olav P. skrev: Having it mandatory for SLES/SLED translators to use openSUSE translations at least for reference *and* to either QA the whole result in their paid time or use the existing volunteer QA and align the rest of SLES/SLED translations and terminology according to openSUSE would also be an option.
A big part of open translations go unchanged and unreviewed into SLE, so it's not that SLE translators change every string. The problem is, that the translations were "forked" from open trunk sometime in october. Now these forked translations come back - in the naive workflow (merge SLE to openSUSE) much of changes in open branch between october could be lost now.
My guess is that the quality assurance in SLES/SLED is not on a par with the open effort, that is or at least may be using peer review. Who does the QA in SLES/SLED in the respective languages?
The QA for SLE doesn't check all strings - AFAIK only these which are not 100% match. There's also a terminology issue - translations for SLE must follow the Novell's dictionary and style guidelines and they are not always the same as these used by open teams. I can only say, that for Polish this dictionary and guidelines do not play very good with GNOME and other linux translations, which come to SLE. Another thing is that SLE does not supports all languages that openSUSE supports - when an SLE-not-supported language is merged back into openSUSE, then this is a simple step backward, because all fixes since october are overwritten with old version. Wadim -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Fredag 27 februar 2009 10:58:03 skrev Wadim Dziedzic:
Another thing is that SLE does not supports all languages that openSUSE supports - when an SLE-not-supported language is merged back into openSUSE, then this is a simple step backward, because all fixes since october are overwritten with old version.
Surely this doesn't occur, or? Here I was feeling relieved that Danish wasn't among the SLE-languages this time around. Either way, I think this whole mess again underlines how bad an idea the concurrent development of SLE and openSUSE was. Hopefully whoever is responsible has learnt from this mistake and will plan better for SLE12. It must be possible to produce and release SLE without screwing over openSUSE in a major way in the process - even if history implies otherwise. -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
On Thursday 26 February 2009 22:24:24 Luiz Fernando Ranghetti wrote:
Hi Karl and all!
Karl is on vacation and will be back on Monday AFAIK. I don't know why and how bad exactly we screwed up and would suggest that we wait for Karl on Monday to dig into this and drive fixing it. I'm glad that it takes some time until the next SLED gets released and I hope we can all learn from it - and fix the problems introduced without problems, Sorry, Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2009-02-27 at 08:28 +0100, Olav P. wrote:
Fredag 27. februar 2009 03:26:13 skrev Carlos E. R.:
I find this demeaning of our work. I'll have to consider stoping my collaboration if this is not reverted, for all files affected.
:-|
If you are going to use somebody else's translation, after all the work we have invested, I see no use in translating anything further. You can do it on your own. :-/
Well, as this after all is volunteer work I don't actually find it "demeaning" but I do find it counter productive.
Well, I don't know how else to name it. Requesting volunteer work, and then throwing it away, using instead paid work from somebody else... why then should I bother to work at all? Let Novell pay for all the translation, and I'll give my time to another outside project where they do appreciate my time :-( It is the other way round. If you pay for a job, you can do as you please with the result. If you request free volunteers, you can not happily throw away the result, because next time you will not get volunteers. We are proud of our work and want to see it used, not thrown away.
I don't know about other languages but for my language (nb), openSUSE translations are generally of a higher quality than SLES/SLED translations.
Therefore, the quality of openSUSE translations will drop considerably every time SLED/SLES translations are merged before a translation round.
It hasn't been a merge, but a full replace.
This is a general observation and I'm sure there are examples to the opposite effect, both for other languages and for individual strings.
Still, I don't think it is a good idea to replace good translations with bad ones, and I find it particularly counter-productive to reinsert typos and translation errors from SLED/SLES that openSUSE translators have corrected during previous rounds
Absolutely.
It feels rather meaningless to proofread the same strings and correct the same errors over and over again, and translators will of course give up in the end and just leave these bad translation "as is". I do exactly that, i.e. give up an leave reoccurring errors, but I don't like it because files with funny translations will be tagged with my name if I am the last person who has edited a particular file, although most of the funny stuff is produced elsewhere :-). .
Absolutely.
Here is my suggestion:
DO NOT MERGE SLES/SLED TRANSLATIONS AT ALL but make the SLES/SLED translation memory available as a tmx file or something for openSUSE translatiors, That way we can use or disregard the SLES/SLED translation for any particular string.
I'm not sure I want the memory there, because the utilities using memory would do automatic translations using the strings of SLED, not ours (or viceversa). We can't be sure of what set they will use. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmn14oACgkQtTMYHG2NR9UxowCeMFfFdXi7K5IMGkT9p7mquSvS wwcAnRV0kXglT9p6g7i3Zul3R85rk4bW =ADp1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
On Fri, Feb 27, 2009 at 12:14 PM, Martin Schlander
Surely this doesn't occur, or? Here I was feeling relieved that Danish wasn't among the SLE-languages this time around.
Hard to say :-) maybe not supported locales were updated from 11.1? Don't know :) I'm not saying that this merge is a completely wrong idea - we already wanted to do it ourself for Polish. The only problem is merging translations changed in either of branches. wd -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
On Friday 27 February 2009 13:07:36 Carlos E. R. wrote:
On Friday, 2009-02-27 at 08:28 +0100, Olav P. wrote:
Fredag 27. februar 2009 03:26:13 skrev Carlos E. R.:
I find this demeaning of our work. I'll have to consider stoping my collaboration if this is not reverted, for all files affected.
:-|
If you are going to use somebody else's translation, after all the work we have invested, I see no use in translating anything further. You can do it on your own. :-/
Well, as this after all is volunteer work I don't actually find it "demeaning" but I do find it counter productive.
Well, I don't know how else to name it. Requesting volunteer work, and then throwing it away, using instead paid work from somebody else... why then should I bother to work at all? Let Novell pay for all the translation, and I'll give my time to another outside project where they do appreciate my time :-(
It is the other way round. If you pay for a job, you can do as you please with the result. If you request free volunteers, you can not happily throw away the result, because next time you will not get volunteers.
We are proud of our work and want to see it used, not thrown away.
It is used - and I really appreciate the great work done! The problem was that work was done in parallel AFAIU - but I just don't know all details. Please read also Karl's email from earlier with subject "Before starting with 11.2 translations".
I don't know about other languages but for my language (nb), openSUSE translations are generally of a higher quality than SLES/SLED translations.
Therefore, the quality of openSUSE translations will drop considerably every time SLED/SLES translations are merged before a translation round.
It hasn't been a merge, but a full replace.
And since we use svn we should be able to revert such things. Let's give Karl a chance to return from his vacation and comment on it.
This is a general observation and I'm sure there are examples to the opposite effect, both for other languages and for individual strings.
Still, I don't think it is a good idea to replace good translations with bad ones, and I find it particularly counter-productive to reinsert typos and translation errors from SLED/SLES that openSUSE translators have corrected during previous rounds
Absolutely.
It feels rather meaningless to proofread the same strings and correct the same errors over and over again, and translators will of course give up in the end and just leave these bad translation "as is". I do exactly that, i.e. give up an leave reoccurring errors, but I don't like it because files with funny translations will be tagged with my name if I am the last person who has edited a particular file, although most of the funny stuff is produced elsewhere :-). .
Absolutely.
Here is my suggestion:
DO NOT MERGE SLES/SLED TRANSLATIONS AT ALL but make the SLES/SLED translation memory available as a tmx file or something for openSUSE translatiors, That way we can use or disregard the SLES/SLED translation for any particular string.
I'm not sure I want the memory there, because the utilities using memory would do automatic translations using the strings of SLED, not ours (or viceversa). We can't be sure of what set they will use.
Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Carlos E. R. skrev:
On Friday, 2009-02-27 at 08:28 +0100, Olav P. wrote:
Here is my suggestion:
DO NOT MERGE SLES/SLED TRANSLATIONS AT ALL but make the SLES/SLED translation memory available as a tmx file or something for openSUSE translatiors, That way we can use or disregard the SLES/SLED translation for any particular string.
I'm not sure I want the memory there, because the utilities using memory would do automatic translations using the strings of SLED, not ours (or viceversa). We can't be sure of what set they will use.
Yes we can, if we use the right tools, and use them properly. CAT tools typically always put the user - the translator - in charge. Merging sounds like a good idea, and it probably is - if (and only if) it's done properly. There has to be a human being in control, and one that's able to communicate between the SLES/SLED and openSUSE translation worlds. Otherwise we'll be getting something only slightly better than Babelfish in the end. BR, Gudmund -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Am Friday 27 February 2009 12:28:51 schrieb Andreas Jaeger:
On Thursday 26 February 2009 22:24:24 Luiz Fernando Ranghetti wrote:
Hi Karl and all!
Karl is on vacation and will be back on Monday AFAIK. I don't know why and how bad exactly we screwed up and would suggest that we wait for Karl on Monday to dig into this and drive fixing it.
I'm glad that it takes some time until the next SLED gets released and I hope we can all learn from it - and fix the problems introduced without problems,
I can at least tell some: the problem was mainly that packages that were meant purely for SLE (i.e. only containting SLE languages, not all openSUSE ones) were checked in into Factory to get the bug fixes within that packages into Factory fast. That this regressed the translations for the moment in Factory was seen as smaller evil. What should not have happened is that the zypper maintainer "merged" SLE and openSUSE translations for an 11.1 online update. Of course Jan did with good intention, taking that SLE translations had more time - but now he knows better ;( But this is tracked in bug 473004 and there is already a new update in testing that is fixing this problem. There isn't and never was an intention to automatically merge the SLE translations. The SLE translators had a different time scale, different requirements and different tools - so it's clear that there is no simple merging. The code11 branch is there and open and you can grab from it what's considered good or file bug reports if you consider something bad (if you care for SLE, of course noone expects you too). Again: We will not throw away any translation work done for 11.1 when going towards 11.2 - the opposite is true. I went great lengths to rewrite the desktop files handling to give you a way to look at conflicts. And not even about SLE conflicts, but I already do not dare to throw away work that upstream did differently. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2009-02-27 at 15:49 +0100, Stephan Kulow wrote: ...
But this is tracked in bug 473004 and there is already a new update in testing that is fixing this problem.
There isn't and never was an intention to automatically merge the SLE translations. The SLE translators had a different time scale, different requirements and different tools - so it's clear that there is no simple merging. The code11 branch is there and open and you can grab from it what's considered good or file bug reports if you consider something bad (if you care for SLE, of course noone expects you too).
Again: We will not throw away any translation work done for 11.1 when going towards 11.2 - the opposite is true. I went great lengths to rewrite the desktop files handling to give you a way to look at conflicts. And not even about SLE conflicts, but I already do not dare to throw away work that upstream did differently.
Thanks... I can go now for my "siesta" with a tranquilized mind :-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmoE38ACgkQtTMYHG2NR9XztACdFJ6A5hYRJM0jbiFw84GXYwr0 vIkAn1r3tpadUvf9o2ebyo6MbINrqT+9 =H86N -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Stephan Kulow
Am Friday 27 February 2009 12:28:51 schrieb Andreas Jaeger:
I'm glad that it takes some time until the next SLED gets released and I hope we can all learn from it
Branch SLE earlier ;) But this probably is not an option. Maybe, I should have warned the openSUSE translators in advance. Otherwise, too many warnings are also annoying, and right from the beginning it was pretty clear to me that "SLE translations in Factory" is just a temporary issue and SVN is not affected at all.
- and fix the problems introduced without problems,
I can at least tell some: the problem was mainly that packages that were meant purely for SLE (i.e. only containting SLE languages, not all openSUSE ones) were checked in into Factory to get the bug fixes within that packages into Factory fast. That this regressed the translations for the moment in Factory was seen as smaller evil.
Yes, this also happened with the YaST translations. Now we have yast2-trans with yast translations from the trunk (= openSUSE 11.2 plus community updates) in Factory as: https://build.opensuse.org/package/show?package=yast2-trans&project=openSUSE%3AFactory
There isn't and never was an intention to automatically merge the SLE translations. The SLE translators had a different time scale, different requirements and different tools - so it's clear that there is no simple merging. The code11 branch is there and open and you can grab from it what's considered good or file bug reports if you consider something bad (if you care for SLE, of course noone expects you too).
Yes, that's it.
Again: We will not throw away any translation work done for 11.1 when going towards 11.2 - the opposite is true. I went great lengths to rewrite the desktop files handling to give you a way to look at conflicts. And not even about SLE conflicts, but I already do not dare to throw away work that upstream did differently.
Thanks for this, coolo! -- Karl Eichwalder R&D / Documentation SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
participants (11)
-
Andreas Jaeger -
Carlos E. R. -
Carlos E. R. -
Gudmund Areskoug -
Jannick Kuhr -
Karl Eichwalder -
Luiz Fernando Ranghetti -
Martin Schlander -
Olav P. -
Stephan Kulow -
Wadim Dziedzic