[opensuse-translation] OpenSUSE 10.3?
Hello list, I have been "out of circulation" for a while and I have been reading the list backlog. I understand the official 10.3 translation rounds have not started yet. Will someone confirm this? I will be back in business in the beginning of August and hope this will not be too late to do the Norwegian 10.3 translations. Regards -- Olav --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Den Wednesday 11 July 2007 10:48:07 skrev Olav Pettershagen:
I have been "out of circulation" for a while and I have been reading the list backlog. I understand the official 10.3 translation rounds have not started yet. Will someone confirm this?
Official translation cycle starts july 19. But many, including Danish team have started already. The "official" part, seems to be mostly relevant to the "professional" tier1 language translators.
I will be back in business in the beginning of August and hope this will not be too late to do the Norwegian 10.3 translations.
Translation freeze is august 17. So you'd need to work fast. http://en.opensuse.org/Roadmap/10.3 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
On Wednesday 11 July 2007 11:14:44 Martin Schlander wrote:
Den Wednesday 11 July 2007 10:48:07 skrev Olav Pettershagen:
I have been "out of circulation" for a while and I have been reading the list backlog. I understand the official 10.3 translation rounds have not started yet. Will someone confirm this?
Official translation cycle starts july 19. But many, including Danish team have started already.
The "official" part, seems to be mostly relevant to the "professional" tier1 language translators.
I will be back in business in the beginning of August and hope this will not be too late to do the Norwegian 10.3 translations.
Translation freeze is august 17. So you'd need to work fast.
My birthday :-). --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Martin Schlander <suse@linuxin.dk> writes:
Official translation cycle starts july 19. But many, including Danish team have started already.
ATM, I try to merge the new .pot files with the existing translations, starting with "af" (Africans). Some modules are new and we merged MailServer.pot with mail.pot. Merging the YaST messages will take several hours. Merging LCN components is also work in progress; I will check tomorrow whether LCN is ready for the 1st translation cycle. -- 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
Karl Eichwalder <ke@suse.de> writes:
Merging LCN components is also work in progress; I will check tomorrow whether LCN is ready for the 1st translation cycle.
Merging is done. All yast and lcn files are ready for the 1st translation round. Fri, Aug 3 the round ens and the package maintainers will pick up the .po files from the suse-i18n SVN for Beta1. See http://en.opensuse.org/Roadmap/10.3 -- 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
Den Friday 20 July 2007 14:54:11 skrev Karl Eichwalder:
Merging is done. All yast and lcn files are ready for the 1st translation round.
Hm.. it seems that we have translations from "memory" again that are not marked fuzzy and thus impossible to check. This is really frustrating, because everytime we clean up errors and inconsistencies of the past they magically reappear in new strings. An example: pre-merge bootloader.da.po (lcn): 64 strings. post-merge bootloader.da.po (lcn): 68 strings, 1 string untranslated This means that at least 3 strings were translated from "memory". And there's a substantial risk that there's either errors reproduced from the memory, or that it breaks the "standards" we have agreed upon in the team, and thus makes our translations messy and inconsistent. To make sure this doesn't happen we would need to proof read the entire file, instead of just the new strings. Given our ambitions for quality and consistency using the memory means more work for us, not less. Of course one solution would be to fix all errors in the memory files, but that's not really feasible since the lcn one is >10.000 strings, and the yast one is just huuuuuuuuge. I'd really like it if all memory translations could be marked fuzzy, it would only take few minutes to verify those fuzzies. If that's not possible plan B would be not to use the memory at all. Using the memory makes it impossible to achieve high quality and consistency. One of our motivations for participating in translations was that we were very unhappy with state that translations were in before (pre 10.2) - needless to say the memory is not exactly helpful in changing that. Maybe in the future useful and trustworthy new memory can be generated, perhaps using only a few select files that we approve. Don't any of you guys on other teams have these concerns? You can check your respective memory files here: https://forgesvn1.novell.com/svn/suse-i18n/trunk/lcn/50-memory/ https://forgesvn1.novell.com/svn/suse-i18n/trunk/yast/50-memory/ For Danish team I only have to look at them for a couple of minutes to find several errors and translations that break our consistency. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Dnia 07/21/2007 10:10 PM, Użytkownik Martin Schlander napisał:
I'd really like it if all memory translations could be marked fuzzy, it would only take few minutes to verify those fuzzies. If that's not possible plan B would be not to use the memory at all.
Other possibility is to add a comment to given translation, which would allow us to search for strings taken from the memory.
Maybe in the future useful and trustworthy new memory can be generated, perhaps using only a few select files that we approve.
Don't any of you guys on other teams have these concerns?erronous
In release 10.1 the polish team was in similar situation. We have changed a big amounts of strings (a cleanup after previous tranlators) and we were also troubled and frustrated by reappearing old erroneous strings. At this time the localisation process was less open (no repository access etc.) and we could only suspect that old strings come form a kind of translation memory. Now, as we do not make revolutionary changes in existing translations we don't have such a big issuses (or maybe we do not notice the 'bad' strings ;-)) regards, Wadim Dziedzic -- Aviary.pl --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Martin Schlander <suse@linuxin.dk> writes:
Den Friday 20 July 2007 14:54:11 skrev Karl Eichwalder:
Merging is done. All yast and lcn files are ready for the 1st translation round.
Hm.. it seems that we have translations from "memory" again that are not marked fuzzy and thus impossible to check.
Just a note: Karl is on vacation and back on thursday. I'll expect him to followup on this and work with you on a solution, 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
Martin Schlander <suse@linuxin.dk> writes:
Den Friday 20 July 2007 14:54:11 skrev Karl Eichwalder:
Merging is done. All yast and lcn files are ready for the 1st translation round.
Hm.. it seems that we have translations from "memory" again that are not marked fuzzy and thus impossible to check.
Yes, see the attached mails; maybe, they did not make it through. I probably cannot the overall process right now -- we partially might depend on the feature to move messages from one module to the other easily. ATM, this works via memories. Checking multi-line helps texts is rather tedious. I completely agree with you that that's dangerous and I sure I can improve the process for > 10.3.
To make sure this doesn't happen we would need to proof read the entire file, instead of just the new strings.
I'd propose to merge the files on your own, ignoring the memories. Check out the previous version (= unmerged) and call msgmerge manually (untested): ll=MY_LANGUAGE cd 50-pot svn up for f in *.pot; do m=${f%pot}$ll.po if [ -f ../$ll/po/$m ]; then msgmerge -U ../$ll/po/$m $f else msgcat -o ../$ll/po/$m --use-first ../50-memory/head-info.$ll.po $f fi done
Of course one solution would be to fix all errors in the memory files, but that's not really feasible since the lcn one is >10.000 strings, and the yast one is just huuuuuuuuge.
The memory files are not static. If I update a memory file, contents from regular .po files always win.
Maybe in the future useful and trustworthy new memory can be generated, perhaps using only a few select files that we approve.
Yes, that would desirable. In the past I nuked the memory files form time to time and rebuilt them using the last three versions of the PO files only. It probably to time for such a cleanup
Don't any of you guys on other teams have these concerns?
You can check your respective memory files here: https://forgesvn1.novell.com/svn/suse-i18n/trunk/lcn/50-memory/ https://forgesvn1.novell.com/svn/suse-i18n/trunk/yast/50-memory/
For Danish team I only have to look at them for a couple of minutes to find several errors and translations that break our consistency.
-- Karl Eichwalder R&D / Documentation SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
Den Thursday 26 July 2007 11:57:20 skrev Karl Eichwalder:
Yes, see the attached mails; maybe, they did not make it through.
They did get through, but I somehow missed the part about applying the changes taking some time. Sorry. Since it's not feasible to mark all memory stuff fuzzy in 10.3 timeframe, would it be possible/reasonably easy for you to not use memory on DA at all when doing the final merge in a week's time? If it's possible I'll discuss with the team if we want memory or not - I'm not really sure anymore, seems a matter of "pick your poison". Do you have any idea how many new/changed strings were in the last merge in total? On our side we can only tell the amount of new fuzzies/untranslated, can you say anything about the number of strings merged totally to give us an idea how much "memory translaton" is done in such a merge, is it 200 strings? 500? 1000? 2000? more? I guess we can expect fewer new strings in the final merge than the last one, no?
Checking multi-line helps texts is rather tedious.
True, a huge PITA.
I completely agree with you that that's dangerous and I sure I can improve the process for > 10.3.
It's a difficult situation.. a) not using memory: Means a lot of extra work. b) marking all memory stuff fuzzy Means quite some extra work - apart from not being an option for 10.3 c) using the memory unconditionally Means poor quality by reproducing errors of the past, not complying with current translation team "standards", and some words that are translated differently in different contexts will look silly (e.g. "volume" can refer to sound or disk-related stuff requiring very different translation). This either means a lot less work and acceptance of poor quality. Or it means you have to proofread everything after the last merge for every release, which would mean an extreme amount of work, with short time to do it. I think we (read: you guys) should strive for giving teams an option between b) and c) in the future. Apart from pl answering here to the list, I've had discussions with fi and ru on IRC - they seem to be slightly worried about the issue, but nevertheless it seems they prefer c)
I'd propose to merge the files on your own, ignoring the memories.
We've already done a lot of work since the merge, I don't want to mess with it. Primarily worried about the future. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
В сообщении от Thursday 26 July 2007 15:41:16 Martin Schlander написал(а):
I completely agree with you that that's dangerous and I sure I can improve the process for > 10.3.
It's a difficult situation..
a) not using memory: Means a lot of extra work.
b) marking all memory stuff fuzzy Means quite some extra work - apart from not being an option for 10.3
c) using the memory unconditionally Means poor quality by reproducing errors of the past, not complying with current translation team "standards", and some words that are translated differently in different contexts will look silly (e.g. "volume" can refer to sound or disk-related stuff requiring very different translation). This either means a lot less work and acceptance of poor quality. Or it means you have to proofread everything after the last merge for every release, which would mean an extreme amount of work, with short time to do it.
I think we (read: you guys) should strive for giving teams an option between b) and c) in the future.
Apart from pl answering here to the list, I've had discussions with fi and ru on IRC - they seem to be slightly worried about the issue, but nevertheless it seems they prefer c)
I'd propose to merge the files on your own, ignoring the memories.
We've already done a lot of work since the merge, I don't want to mess with it. Primarily worried about the future. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
I personally vore for variant b), maybe you have missunderstood me. Proof reading additional fuzzy lines is not much work but leads to better quallity. Since memory strings are mostly correct this won't cause much of work. I'm not able to decide for our team, have to ask our coordinator. -- Regards, Nikolay Derkach --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Hi, I will be a somewhat "late" translator for 10.3. However, I can see where Martin and his Danish friends are coming from. In my case i have usually always "overruled" the official openSUSE TM by using my own TM, compiled and maintained locally on my hard disk. This approach has seldom been a major problem, mostly because I have done the major part of the openSUSE stuff from scratch and singlehandedly. However, it has sometimes been a bit annoying when substandard translations have been merged into new files, replacing former "good" translations. I don't know about Danish. Still, when it comes to Norwegian and since I have translated almost everything from scratch for many years, I suspect that the pollution of official TM's must come from some substandard translation efforts for SLES and/or SLED outside the SUSE/openSUSE workflow, perhaps from KDE/GNOME translations also? Could this assumption be correct, Klára and Karl? Olav On Thursday 26 July 2007 13:41:16 Martin Schlander wrote:
Den Thursday 26 July 2007 11:57:20 skrev Karl Eichwalder:
Yes, see the attached mails; maybe, they did not make it through.
They did get through, but I somehow missed the part about applying the changes taking some time. Sorry.
Since it's not feasible to mark all memory stuff fuzzy in 10.3 timeframe, would it be possible/reasonably easy for you to not use memory on DA at all when doing the final merge in a week's time?
If it's possible I'll discuss with the team if we want memory or not - I'm not really sure anymore, seems a matter of "pick your poison".
Do you have any idea how many new/changed strings were in the last merge in total? On our side we can only tell the amount of new fuzzies/untranslated, can you say anything about the number of strings merged totally to give us an idea how much "memory translaton" is done in such a merge, is it 200 strings? 500? 1000? 2000? more?
I guess we can expect fewer new strings in the final merge than the last one, no?
Checking multi-line helps texts is rather tedious.
True, a huge PITA.
I completely agree with you that that's dangerous and I sure I can improve the process for > 10.3.
It's a difficult situation..
a) not using memory: Means a lot of extra work.
b) marking all memory stuff fuzzy Means quite some extra work - apart from not being an option for 10.3
c) using the memory unconditionally Means poor quality by reproducing errors of the past, not complying with current translation team "standards", and some words that are translated differently in different contexts will look silly (e.g. "volume" can refer to sound or disk-related stuff requiring very different translation). This either means a lot less work and acceptance of poor quality. Or it means you have to proofread everything after the last merge for every release, which would mean an extreme amount of work, with short time to do it.
I think we (read: you guys) should strive for giving teams an option between b) and c) in the future.
Apart from pl answering here to the list, I've had discussions with fi and ru on IRC - they seem to be slightly worried about the issue, but nevertheless it seems they prefer c)
I'd propose to merge the files on your own, ignoring the memories.
We've already done a lot of work since the merge, I don't want to mess with it. Primarily worried about the future. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
-- Olav Pettershagen Grøndalen NO-2429 Tørberget Tel. +47 62454707 Mob. +47 48141781 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Karl, I realize you're probably very busy these days with all the new translation teams popping up, coming back from vacation etc., so you're excused if you missed my questions. But I would really like some answers to my questions before the next merge. Is it an option to not use memory at all for the last merge? Is it possible to give a very rough ballpark estimate of the new/changed/moved strings? Are we talking hundreds? thousands? several thousands? --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Martin Schlander <suse@linuxin.dk> writes:
Is it an option to not use memory at all for the last merge?
Yes, those teams who do not want memories used for merging, should empty the memory files in 50-memory (yast and lcn). Just copy head-info.LL.po to yast2.LL.po resp. to memory.LL.po .
Is it possible to give a very rough ballpark estimate of the new/changed/moved strings? Are we talking hundreds? thousands? several thousands?
We've no clue ;) Rough estimation is 10% additional or changed strings. IIRC, we had some 2500 new messages when starting translation cycle 1 -- so expect 250 messages. Maybe some more, since there was heavy activity with the package manangement stack recently. -- 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
Den Tuesday 31 July 2007 16:48:43 skrev Karl Eichwalder:
Yes, those teams who do not want memories used for merging, should empty the memory files in 50-memory (yast and lcn). Just copy head-info.LL.po to yast2.LL.po resp. to memory.LL.po .
Done. Thanks. Now I can rest easier. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
participants (6)
-
Andreas Jaeger -
Karl Eichwalder -
Martin Schlander -
Nikolay Derkach -
Olav Pettershagen -
wadim dziedzic