[opensuse-translation] Towards 11.0 (yast)
You probably noticed that we are cleaning up the translation SVN. The first translation round is going to start next week :) Here are some details: - bluetooth and SLE related modules are gone (and saved in the yast2 memory files). - packages renamed to packages-ncurses - packages-qt renamed to qt -- 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:
You probably noticed that we are cleaning up the translation SVN. The first translation round is going to start next week :)
Here are some details:
I forgot to mention: Today, Jiri submitted all the POTs for proofreading. Now I'm running the merge with the existing PO translation files. -- 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
Dnia 2008-03-25 15:06, Użytkownik Karl Eichwalder napisał:
You probably noticed that we are cleaning up the translation SVN. The first translation round is going to start next week :)
Here are some details:
I forgot to mention:
Today, Jiri submitted all the POTs for proofreading. Now I'm running the merge with the existing PO translation files.
Hallo Karl, How long will this review take? Does it mean that we will get some fuzzies when results will come back to repository? English proofreading will probably have little impact on translations, so would it be possible then to merge its results differently? I mean in the other direction - merge the reviewed msgids to .po files. The normal merge + translation memory makes the translation work harder, because some good translations are usually lost or old ones from memory creep in. Of course the changed items should be marked as fuzzy, but we would be sure that the translations are "original". I know there's no tool for such a merge, but maybe half day work of one person would save some translators' time ;-) regards, Wadim -- Aviary.pl l10n team e-mail: wdziedzic@aviary.pl jabber: nikdo@jabberpl.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
wadim dziedzic <wdziedzic@aviary.pl> writes:
How long will this review take?
It ends today and may start or continue later in April.
Does it mean that we will get some fuzzies when results will come back to repository?
Yes, fuzzies are to be expected.
English proofreading will probably have little impact on translations, so would it be possible then to merge its results differently? I mean in the other direction - merge the reviewed msgids to .po files. The normal merge + translation memory makes the translation work harder, because some good translations are usually lost or old ones from memory creep in. Of course the changed items should be marked as fuzzy, but we would be sure that the translations are "original".
Unfortunately, this is not possible. msgmerge does not know whether a message is new or just changed up to some degree. In the near future we a probably able to carry over the old translation somehow; this way, PO file editors could display diffs easily (I think this already works somehow in kbabel). Old translation: msgid "apple" msgstr "jablko" Now consider a newly introduced string such as "apples": #, fuzzy #| apple msgid "apples" msgstr "jablko" I'm not sure about the final getext syntax, though.
I know there's no tool for such a merge, but maybe half day work of one person would save some translators' time ;-)
Yes, that's a valid concern. Maybe, later this year ;-( Cheers, Karl -- 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
Onsdag den 26. Marts 2008 13:22:50 skrev Karl Eichwalder:
Does it mean that we will get some fuzzies when results will come back to repository?
Yes, fuzzies are to be expected.
English proofreading will probably have little impact on translations, so would it be possible then to merge its results differently? I mean in the other direction - merge the reviewed msgids to .po files. The normal merge + translation memory makes the translation work harder, because some good translations are usually lost or old ones from memory creep in. Of course the changed items should be marked as fuzzy, but we would be sure that the translations are "original".
Unfortunately, this is not possible. msgmerge does not know whether a message is new or just changed up to some degree. In the near future we a probably able to carry over the old translation somehow; this way, PO file editors could display diffs easily (I think this already works somehow in kbabel). Old translation:
msgid "apple" msgstr "jablko"
Now consider a newly introduced string such as "apples":
#, fuzzy #| apple msgid "apples" msgstr "jablko"
I'm not sure about the final getext syntax, though.
Not sure if the functionality is hiding in KBabel somewhere, but KDE(4) PO-files use this syntax, and LoKalize supports it and shows diff. It's freaking fantastic. Especially with those dreaded large, multi line strings where someone moved a comma, and you spend five minutes figuring out what they changed. Here's a screenshot of such a case, for your enjoyment. Notice the diff toolview on the bottom left: http://suse.linuxin.dk/lokalize-diff.png --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Onsdag den 26. Marts 2008 15:00:03 skrev Martin Schlander:
Onsdag den 26. Marts 2008 13:22:50 skrev Karl Eichwalder:
msgmerge does not know whether a message is new or just changed up to some degree. In the near future we a probably able to carry over the old translation somehow; this way, PO file editors could display diffs easily (I think this already works somehow in kbabel).
Not sure if the functionality is hiding in KBabel somewhere
KBabel has diffmode... and it's not "hidden" at all, sorry. --------------------------------------------------------------------- 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 The Wednesday 2008-03-26 at 15:00 +0100, Martin Schlander wrote:
Not sure if the functionality is hiding in KBabel somewhere, but KDE(4) PO-files use this syntax, and LoKalize supports it and shows diff. It's
kbabel also shows diff, but not from the compendium memory; it is one of the buggy features, I think. You have to go to tools, diff, open file for diff, and there you select the previous version of the .po file. Next, you click on "diffmode", pgup, pgdn, and it should show both versions of the current msg. About the syntax you mention, I have no idea if it supports it or not; I'll tell you when I try one file like that.
freaking fantastic. Especially with those dreaded large, multi line strings where someone moved a comma, and you spend five minutes figuring out what they changed.
Here's a screenshot of such a case, for your enjoyment. Notice the diff toolview on the bottom left: http://suse.linuxin.dk/lokalize-diff.png
Well, kbabel diffmode is not so "cute". Unfortunately, I still find lokalize lacking in some features I use, and easy to crash. I found an action that crashes repeatedly. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH6mvvtTMYHG2NR9URAl3lAJwNHbDVtLIBDqSC8cDKjDFcUNlRDwCfTxBu s1ioh4li37KSHzYqE5sVD50= =L2cY -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Onsdag den 26. Marts 2008 16:29:50 skrev Carlos E. R.:
About the syntax you mention, I have no idea if it supports it or not; I'll tell you when I try one file like that.
Here's an example of it from kalzium.po in KDE4.1: #: src/tools/obconverter.cpp:189 #, fuzzy #| msgid "No element selected" msgid "No files selected" msgstr "Intet grundstof markeret" And KBabel does seem to support it.
Well, kbabel diffmode is not so "cute". Unfortunately, I still find lokalize lacking in some features I use, and easy to crash. I found an action that crashes repeatedly.
Well, yeah, LoKalize is part of KDE 4.1 and thus pre-alpha, but I find it very promising, and other PO editors have issues also. KBabel will probably remain my primary tool for a while. --------------------------------------------------------------------- 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 The Wednesday 2008-03-26 at 16:45 +0100, Martin Schlander wrote:
Here's an example of it from kalzium.po in KDE4.1:
#: src/tools/obconverter.cpp:189 #, fuzzy #| msgid "No element selected" msgid "No files selected" msgstr "Intet grundstof markeret"
And KBabel does seem to support it.
Good to know.
Well, kbabel diffmode is not so "cute". Unfortunately, I still find lokalize lacking in some features I use, and easy to crash. I found an action that crashes repeatedly.
Well, yeah, LoKalize is part of KDE 4.1 and thus pre-alpha, but I find it very promising, and other PO editors have issues also.
Yep, all have issues. I installed kde4 from the dvd and the kde4 stable repo (with the sole idea of trying LoKalize), and it... f*d my kde3 install. The kde4 uses black backgrounds, and now in kde3 some apps show in white and some in black, like kwrite. Everything is messed up.
KBabel will probably remain my primary tool for a while.
Here too. It's buggy, but it is still the best. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH6ukvtTMYHG2NR9URAg5EAJ4ocdfwKK3UsboZV6URsPaOry8LcgCfZaQN oiFNUwMmUmtpJUZxR/U/OcQ= =3pMp -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
participants (5)
-
Carlos E. R. -
Carlos E. R. -
Karl Eichwalder -
Martin Schlander -
wadim dziedzic