[opensuse-translation] SLES translation
Hello, During review of the files of 12.1, I was translating also the SLES SP1 files using the meld program. Now that there's SLES SP2, I don't know where the files are so I'll translate them the same way. Can someone point me where those files are, please? Thanks Stathis -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org
Efstathios Iosifidis <iefstathios@gmail.com> writes:
During review of the files of 12.1, I was translating also the SLES SP1 files using the meld program. Now that there's SLES SP2, I don't know where the files are so I'll translate them the same way. Can someone point me where those files are, please?
SLES 11 SP2 files are in branches/SLE11/, which is kind of a trunk for the SLE 11 products. Sometime in the future, I'll move it to branches/SLE11SP2/. Because we do not have "official" Greek translations, it is ok to touch those. Translators of other languages, please do not change translations in branches/SLE* without talking about it first (the "official" SLE translations are stored in an external translation memory and it could happen that changes in our SVN will be overridden with files from the external memory). OTOH, it is perfectly ok and even highly encouraged to reuse the SLE translations for openSUSE. And further, if you notice strange varriants or other issues in the SLE translations, please report it. We'd like to "align" SLE and openSUSE translations as much as possible! -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org
On 04/04/12 08:36, Karl Eichwalder wrote:
OTOH, it is perfectly ok and even highly encouraged to reuse the SLE translations for openSUSE. And further, if you notice strange varriants or other issues in the SLE translations, please report it. We'd like to "align" SLE and openSUSE translations as much as possible!
Sorry for the late answer, but I was very busy last days. Said this, I resolutely refuse to use SLE translations since usually they are in a different style (even if we grant for the sake of argument that an uniform style is used at least in the file) that frequently does not match the one we (Italian translation team) agreed for all oS translations under our control. This means that in any case I have to check and adapt strings in order to have again the uniform style between all our translation files. Another thing is that some string seems to be obtained using Google Translator since the sentence contains the right words but its structure is completely messy. And I am sure that such a string does not come from previous oS translations since I reviewed all yast files before oS 12.1. Moreover I am very disappointed to find translations that have been replaced by *wrong* strings without marking them as fuzzy. I have already found several of such strings in current YaST files only because I dumped a "svn diff -r PREV file" before starting translations, dumps that I open in Kate for quickly finding differences between strings. Hopefully I scrolled them instead of searching "fuzzy", so I discovered such errors.Just as an example, in ldap-server there was a string referring to the system repair module instead of the partitioner module. I have no idea where such string comes from (I want to remark that it was changed without marking it as fuzzy). The main problem now is that I dumped only 7 files (those with a lot of fuzzy strings) and not all files, so currently I do not know whether there are other files containing *wrong* translations. Hence I have to waste my time finding the right version in the svn log for dumping a good diff and checking it. Best, Andrea PS: I'll file bug reports if and when I have some free time, obviously oS translations and all other activities have precedence... -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org
Andrea Turrini <andrea.turrini@gmail.com> writes:
Sorry for the late answer, but I was very busy last days. Said this,
Better late than never :)
I resolutely refuse to use SLE translations since usually they are in a different style (even if we grant for the sake of argument that an uniform style is used at least in the file) that frequently does not match the one we (Italian translation team) agreed for all oS translations under our control. This means that in any case I have to check and adapt strings in order to have again the uniform style between all our translation files.
Ok, that sounds like a rather serious issue. (For the record, for German that's not the case: there are differences, but the general approach is the same in SLES and openSUSE). So, we will to sort it out language by language and talk about the cause and the purpose of all this.
Another thing is that some string seems to be obtained using Google Translator since the sentence contains the right words but its structure is completely messy. And I am sure that such a string does not come from previous oS translations since I reviewed all yast files before oS 12.1.
I guess this will be an exception. But also note, while yast and some other components are at the same level on opensuse 12.1 and SLES 11 SP2, SLES 11 SP2 is still somehow based on the "code 11", even if many important feature are newer than 12.1...
Moreover I am very disappointed to find translations that have been replaced by *wrong* strings without marking them as fuzzy. I have already found several of such strings in current YaST files only because I dumped a "svn diff -r PREV file" before starting translations, dumps that I open in Kate for quickly finding differences between strings. Hopefully I scrolled them instead of searching "fuzzy", so I discovered such errors.Just as an example, in ldap-server there was a string referring to the system repair module instead of the partitioner module. I have no idea where such string comes from (I want to remark that it was changed without marking it as fuzzy).
I'll try to check it. I can assure you that lately nobody knowingly merged strings from the SLE11 branch into the trunk. Quite some time ago (SLES 10?) we did this and at the same time, we flagged these strings as fuzzy (IIRC).
The main problem now is that I dumped only 7 files (those with a lot of fuzzy strings) and not all files, so currently I do not know whether there are other files containing *wrong* translations. Hence I have to waste my time finding the right version in the svn log for dumping a good diff and checking it.
Thanks for your feedback and your warning! We will have to pay special attention.
PS: I'll file bug reports if and when I have some free time, obviously oS translations and all other activities have precedence...
Yes, that's reasonable. -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (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 2012-04-20 15:44, Karl Eichwalder wrote:
Andrea Turrini <> writes:
Sorry for the late answer, but I was very busy last days. Said this,
Better late than never :)
And I didn't notice!
I resolutely refuse to use SLE translations since usually they are in a different style (even if we grant for the sake of argument that an uniform style is used at least in the file) that frequently does not match the one we (Italian translation team) agreed for all oS translations under our control. This means that in any case I have to check and adapt strings in order to have again the uniform style between all our translation files.
This is exactly what the Spanish team decided time ago, IIRC. It is up to each translator to compare and reuse
Another thing is that some string seems to be obtained using Google Translator since the sentence contains the right words but its structure is completely messy. And I am sure that such a string does not come from previous oS translations since I reviewed all yast files before oS 12.1.
Wow.
Moreover I am very disappointed to find translations that have been replaced by *wrong* strings without marking them as fuzzy. I have already found several of such strings in current YaST files only because I dumped a "svn diff -r PREV file" before starting translations, dumps that I open in Kate for quickly finding differences between strings. Hopefully I scrolled them instead of searching "fuzzy", so I discovered such errors.Just as an example, in ldap-server there was a string referring to the system repair module instead of the partitioner module. I have no idea where such string comes from (I want to remark that it was changed without marking it as fuzzy).
Finding those can be time consuming, and very disappointing. Argh, now I have to read them in full. :-( - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk+RpfMACgkQIvFNjefEBxrZ/wCfZcag8g0agwhOFmAFzCDS8PSY LwUAn0tG9dsHygRFySkSBIOIB6Hq2+2n =9LX/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org
On 20/04/12 20:07, Carlos E. R. wrote:
such errors.Just as an example, in ldap-server there was a string referring to the system repair module instead of the partitioner module. I have no idea where such string comes from (I want to remark that it was changed without marking it as fuzzy).
Finding those can be time consuming, and very disappointing. Argh, now I have to read them in full. :-(
FYI, the file is storage, not ldap-server. Anyway, the wrong sentence is not present in the file at revision 71323 and it appears at the following commitment at revision 72902 (I am talking only about the Italian directory). After this commitment other 4 merges have occurred, intermixed with my translation commitments. Now, according to the svn log, I completely reviewed yast strings with commitments between r65427 and r66900; however in the meanwhile there were three merges (r65613, r65990, r66461) that may have introduced other wrong strings in already reviewed files. For the three merges, I think it should be enough to dump a diff between merge revision and the previous one and then look for non-fuzzy changed translations, so after this I am sure that files at revision 66900 are OK (except for my possible errors). Now, what is the best way to try to find other wrong sentences, if any? I think that dumping a diff between 66900 and HEAD will introduce a lot of false positives but it is the safest approach (less safer than reviewing completely yast files, but this requires a lot of time). Best, Andrea -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org
Andrea Turrini <andrea.turrini@gmail.com> writes:
Now, according to the svn log, I completely reviewed yast strings with commitments between r65427 and r66900; however in the meanwhile there were three merges (r65613, r65990, r66461) that may have introduced other wrong strings in already reviewed files.
If that's the case, the wrong string could originate from the memory files. If wanted, we can reset the memory files, this means I can easily rebuild them from good .po files.
For the three merges, I think it should be enough to dump a diff between merge revision and the previous one and then look for non-fuzzy changed translations, so after this I am sure that files at revision 66900 are OK (except for my possible errors).
Now, what is the best way to try to find other wrong sentences, if any? I think that dumping a diff between 66900 and HEAD will introduce a lot of false positives but it is the safest approach (less safer than reviewing completely yast files, but this requires a lot of time).
With the gettext tools (msgcomm) it is possible to filter out identical messages. Messages that only differ in line-numbers or line-breaks could also count as identical. Then normalize the remaining messages (msgcat) and finally diff them. -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org
participants (4)
-
Andrea Turrini -
Carlos E. R. -
Efstathios Iosifidis -
Karl Eichwalder