Hi all,
I send this mail to both os-translation and yast-devel ML since it addresses both yast development and translation, so take care of these two ML when you reply.
I have just noted that the POT files for YaST have been updated, probably as the result of the conversion of YaST in Ruby.
As a result, the msgid strings now contain "\n" instead of "\n" to denote the new line inside the same msgid.
For instance, in printer.pot, the current string is
msgid "Started the CUPS daemon.\nWaiting half a minute for the CUPS daemon to get ready to operate...\n"
while before it was
msgid "" "Started the CUPS daemon.\n" "Waiting half a minute for the CUPS daemon to get ready to operate...\n"
Now, the question is: is this change expected and wanted?
Note that now we have around 3310 fuzzy and 40 untranslated strings so I think it is better to be sure that all these fuzzy strings are correct before starting fixing their translations.
Best, Andrea
On 08/01/2013 07:59 PM, Andrea Turrini wrote:
Hi all,
I send this mail to both os-translation and yast-devel ML since it addresses both yast development and translation, so take care of these two ML when you reply.
I have just noted that the POT files for YaST have been updated, probably as the result of the conversion of YaST in Ruby.
As a result, the msgid strings now contain "\n" instead of "\n" to denote the new line inside the same msgid.
For instance, in printer.pot, the current string is
msgid "Started the CUPS daemon.\nWaiting half a minute for the CUPS daemon to get ready to operate...\n"
while before it was
msgid "" "Started the CUPS daemon.\n" "Waiting half a minute for the CUPS daemon to get ready to operate...\n"
Now, the question is: is this change expected and wanted?
Note that now we have around 3310 fuzzy and 40 untranslated strings so I think it is better to be sure that all these fuzzy strings are correct before starting fixing their translations.
Best, Andrea
Which langauge, en_US or en_GB?
On 08/01/2013 09:24 PM, Ys wrote:
Which langauge, en_US or en_GB?
I checked on Italian (fully translated before the update of the YaST POT files), but a change in the POT file affects all languages...
Note that the updated strings are not yet in the PO files repository; I updated my *.it.po files from the POT manually.
Best, Andrea
Andrea Turrini andrea.turrini@gmail.com writes:
Thanks for spotting!
I checked on Italian (fully translated before the update of the YaST POT files), but a change in the POT file affects all languages...
Note that the updated strings are not yet in the PO files repository; I updated my *.it.po files from the POT manually.
Last week I merged half of our languages (from A to Italian). Now I'm wondering whether I should revert everything?
Στις 05/08/2013 12:39 μμ, ο/η Karl Eichwalder έγραψε:
Andrea Turrini andrea.turrini@gmail.com writes:
Thanks for spotting!
I checked on Italian (fully translated before the update of the YaST POT files), but a change in the POT file affects all languages...
Note that the updated strings are not yet in the PO files repository; I updated my *.it.po files from the POT manually.
Last week I merged half of our languages (from A to Italian). Now I'm wondering whether I should revert everything?
Guys, I already started translating using gtranslator. The original English text had only \n, so I used it. Now POT files changed everything and I lost everything. I must translate them again. What should I do? Can I get some files from 12.3 branch and send the translations? I'm kind of lost. Thanks Stathis
"Efstathios Iosifidis (aka diamond_gr)" iefstathios@gmail.com writes:
Guys, I already started translating using gtranslator. The original English text had only \n, so I used it. Now POT files changed everything and I lost everything. I must translate them again. What should I do? Can I get some files from 12.3 branch and send the translations?
In the meantime I reverted all languages where no translation work was done since the broken .pot file update. And I also reverted the .pot files. I wanted, I can also revert your translations (el). If you you want to keep "new" translation, just save them in a compendium file:
cd .../el msgcat --use-first -o compendium.el.po po/*.el.po
From the compendium file, you can reuse these translations easily later
on:
msgmerge -C compendium.el.po -U po/$FILE.el.po ../50-pot/$FILE.pot
To revert the faulty merge, I used this command (where $l is the language code, e.g., 'el'):
cd $l/po svn merge -rHEAD:80160 . svn ci -m'reverting to pre-ruby state' .
I hope I got it right...
Στις 05/08/2013 07:06 μμ, ο/η Karl Eichwalder έγραψε:
"Efstathios Iosifidis (aka diamond_gr)" iefstathios@gmail.com writes:
Guys, I already started translating using gtranslator. The original English text had only \n, so I used it. Now POT files changed everything and I lost everything. I must translate them again. What should I do? Can I get some files from 12.3 branch and send the translations?
In the meantime I reverted all languages where no translation work was done since the broken .pot file update. And I also reverted the .pot files. I wanted, I can also revert your translations (el). If you you want to keep "new" translation, just save them in a compendium file:
cd .../el msgcat --use-first -o compendium.el.po po/*.el.poFrom the compendium file, you can reuse these translations easily later
on:
msgmerge -C compendium.el.po -U po/$FILE.el.po ../50-pot/$FILE.potTo revert the faulty merge, I used this command (where $l is the language code, e.g., 'el'):
cd $l/po svn merge -rHEAD:80160 . svn ci -m'reverting to pre-ruby state' .I hope I got it right...
Thanks everyone for your help.
I'll stop translating (I already wrote to Greek list as well, although I'm the only one translating right now, since everyone is on vacation) until we have the green light to proceed. When that happens, I'll ask you then what do I have to do. Remember, I know only how to translate (and do marketing). I don't have a clue about repositories etc. So please don't be mad at me asking easy (or silly) questions.
Thanks again. Have summer phun, Stathis
On 08/05/2013 05:48 PM, Efstathios Iosifidis (aka diamond_gr) wrote:
Στις 05/08/2013 12:39 μμ, ο/η Karl Eichwalder έγραψε:
Andrea Turrini andrea.turrini@gmail.com writes:
Thanks for spotting!
I checked on Italian (fully translated before the update of the YaST POT files), but a change in the POT file affects all languages...
Note that the updated strings are not yet in the PO files repository; I updated my *.it.po files from the POT manually.
Last week I merged half of our languages (from A to Italian). Now I'm wondering whether I should revert everything?
Guys, I already started translating using gtranslator. The original English text had only \n, so I used it. Now POT files changed everything and I lost everything. I must translate them again.
Not really, since we are using svn.
What should I do?
As first thing, stop translating until we have a green light from yast devs.
Then, you can recover original translations as follows: inside your yast directory containing the po files, do a "svn log -v | less" and find the last revision before the merging. In my case r80771 since the following commit is the one from Karl (r82728).
Then you checkout again the repository at that specific revision: "svn co https://svn.opensuse.org/svn/opensuse-i18n/trunk/yast/el -r N" where you replace N by the revision found before.
Now you have a copy of your files before the massive change. Using these files, you can replace the new ones or copy the translations. But I think it is better if you ask Karl for the best solution to avoid other problems in case he decides to revert the changes.
Best, Andrea
Can I get some files from 12.3 branch and send the translations? I'm kind of lost. Thanks Stathis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2013-08-05 at 18:48 +0300, Efstathios Iosifidis (aka diamond_gr) wrote:
Guys, I already started translating using gtranslator. The original English text had only \n, so I used it. Now POT files changed everything and I lost everything. I must translate them again. What should I do? Can I get some files from 12.3 branch and send the translations? I'm kind of lost.
IMO, it is too early to start translating, specially YAST. Generally, you can start anytime, but any translation done before the freeze, can suffer blows like that.
Beta 1 is scheduled for Sept 15th...
I'm not familiar with gtranslator. Kbabel, for instance, memorizes all your translated strings, and can use those for the automated translation functionality. Of course, those strings are set fuzzy and you have to review them, but it is better than working from scratch.
- -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
Στις 05/08/2013 09:06 μμ, ο/η Carlos E. R. έγραψε:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2013-08-05 at 18:48 +0300, Efstathios Iosifidis (aka diamond_gr) wrote:
Guys, I already started translating using gtranslator. The original English text had only \n, so I used it. Now POT files changed everything and I lost everything. I must translate them again. What should I do? Can I get some files from 12.3 branch and send the translations? I'm kind of lost.
IMO, it is too early to start translating, specially YAST. Generally, you can start anytime, but any translation done before the freeze, can suffer blows like that.
Beta 1 is scheduled for Sept 15th...
I'm not familiar with gtranslator. Kbabel, for instance, memorizes all your translated strings, and can use those for the automated translation functionality. Of course, those strings are set fuzzy and you have to review them, but it is better than working from scratch.
Carlos, gtranslator has also similar thing you described. Our translations were 99% and after this change went to 90%. So as I mentioned, I'll be waiting your news to start translate. Thanks
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2013-08-01 at 18:59 +0200, Andrea Turrini wrote:
Hi all,
I send this mail to both os-translation and yast-devel ML since it addresses both yast development and translation, so take care of these two ML when you reply.
I'm only subscribed here; if I post to yast-devel-ml I don't know if it will be rejected.
msgid "" "Started the CUPS daemon.\n" "Waiting half a minute for the CUPS daemon to get ready to operate...\n"
Now, the question is: is this change expected and wanted?
What I know is that the translation tools will not detect the double slash, and will not flag as an error if a single slash is used. What will happen if we (translators) fail to use them?
Can our tools be modified so that those errors be flagged?
Why has that double slash got to be used? :-?
- -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
2013/8/2 Carlos E. R. carlos.e.r@opensuse.org:
What I know is that the translation tools will not detect the double slash, and will not flag as an error if a single slash is used. What will happen if we (translators) fail to use them?
If I remember correctly, \ is the escape sequence to have the character '' in the resulting string, as \n is the escape sequence for the new line. So, having \n in the original string should correspond to have the two characters '\n' in the resulting string. So, if we keep \n instead of \n in the translation, than the tool should complain for the different number of new lines; if we use \n, probably the user will see the characters '\n' in the string instead of the new line.
Can our tools be modified so that those errors be flagged?
No idea, also because '\' has a meaning, it is not an error.
Why has that double slash got to be used? :-?
It seems to be a problem with the string extraction tool (from a mail sent to yast-devel only):
On 08/02/2013 08:36 AM, Ladislav Slezak wrote:
Dne 1.8.2013 18:59, Andrea Turrini napsal(a):
As a result, the msgid strings now contain "\n" instead of "\n" to denote the new line inside the same msgid.
For instance, in printer.pot, the current string is
msgid "Started the CUPS daemon.\nWaiting half a minute for the CUPS daemon to get ready to operate...\n"
Yeah, I haven't noticed that, thanks for reporting this!
Now, the question is: is this change expected and wanted?
This was caused by switching from YCP to Ruby which needs using Ruby gettext (rxgettext) instead of GNU gettext (xgettext).
For me it looks like a bug, I'll investigate further.
Moreover many comments are missing, this is another incompatibility in rxgettext and needs to be solved.
For now ignore the new translations, and I think the last changes could be even reverted to not cause confusions for translators...
Best, Andrea
Dne 1.8.2013 18:59, Andrea Turrini napsal(a):
I have just noted that the POT files for YaST have been updated, probably as the result of the conversion of YaST in Ruby.
As a result, the msgid strings now contain "\n" instead of "\n" to denote the new line inside the same msgid.
For instance, in printer.pot, the current string is
msgid "Started the CUPS daemon.\nWaiting half a minute for the CUPS daemon to get ready to operate...\n"
while before it was
msgid "" "Started the CUPS daemon.\n" "Waiting half a minute for the CUPS daemon to get ready to operate...\n"
Now, the question is: is this change expected and wanted?
On the first sight it looks like a bug of a string extraction tool for Ruby (rxgettext). Ladislav (in CC) is looking at the problem now more deeply.
We'll send an update once we know more.
V Fri, 02 Aug 2013 08:37:09 +0200 David Majda dmajda@suse.cz napsáno:
Dne 1.8.2013 18:59, Andrea Turrini napsal(a):
I have just noted that the POT files for YaST have been updated, probably as the result of the conversion of YaST in Ruby.
As a result, the msgid strings now contain "\n" instead of "\n" to denote the new line inside the same msgid.
For instance, in printer.pot, the current string is
msgid "Started the CUPS daemon.\nWaiting half a minute for the CUPS daemon to get ready to operate...\n"
while before it was
msgid "" "Started the CUPS daemon.\n" "Waiting half a minute for the CUPS daemon to get ready to operate...\n"
Now, the question is: is this change expected and wanted?
On the first sight it looks like a bug of a string extraction tool for Ruby (rxgettext). Ladislav (in CC) is looking at the problem now more deeply.
We'll send an update once we know more.
So, now I've sent new pot files to your svn repository: the issue with newlines should be fixed (thanks to Ladislav).
There still might be some minor issue that some comments are missing (in some corner cases). This will be fixed once we found the reason for such behavior.
Jiri
Jiří Suchomel jsuchome@suse.cz writes:
So, now I've sent new pot files to your svn repository: the issue with newlines should be fixed (thanks to Ladislav).
Ok, thanks!
There still might be some minor issue that some comments are missing (in some corner cases). This will be fixed once we found the reason for such behavior.
This is not that good news; but it is acceptable if only a few corner cases are affected. But there are at least to other issues:
1/ ",ycp-format" flags are missing. This means we no longer are able to validate proper usage of format specifiers.
2/ The extractor does not seem to collapse duplicates into one entry. Thus nfs_server.pot is invalid:
msgfmt --check 50-pot/nfs_server.pot 50-pot/nfs_server.pot:122: duplicate message definition... 50-pot/nfs_server.pot:119: ...this is the location of the first definition
As a workaround, you can pipe the extracted strings through msguniq.
Wondering why ruby guys did not ask the GNU gettext maintainers to support ruby...
Dne 6.8.2013 13:05, Karl Eichwalder napsal(a):
1/ ",ycp-format" flags are missing. This means we no longer are able to validate proper usage of format specifiers.
Ouch, this is quite tricky.
We switched from YCP to Ruby so the "ycp-format" is actually not true anymore.
Although we wrap the translation code so the YCP %<num> format specifiers work in Ruby code, we cannot know if that wrapper is used during POT build. It can be manually removed and replaced by pure Ruby format.
(Well, maybe we could, but the parser would be too complicated and I don't think we would catch all possible use cases...)
I don't want to blindly add "ycp-format" marks everywhere although it would work right now as nobody probably has touched any translation text yet. But later there will be such changes for sure and then we won't know which format is correct.
I don't see any solution to this problem, I think we have just to live without the additional validation... :-(
2/ The extractor does not seem to collapse duplicates into one entry. Thus nfs_server.pot is invalid:
msgfmt --check 50-pot/nfs_server.pot 50-pot/nfs_server.pot:122: duplicate message definition... 50-pot/nfs_server.pot:119: ...this is the location of the first definition
Strange, there is some code for merging the duplicates and works quite well, it merged all duplicates correctly in my test cases.
I'll check creating this specific POT file...
Thanks for the feedback!
Ladislav
--
Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE
Ladislav Slezak lslezak@suse.cz writes:
We switched from YCP to Ruby so the "ycp-format" is actually not true anymore.
Sure, but pretending ycp-format would be the best approximation right now ;) With my tools (msgfmt), I would not be able to validate rb-format ;)
If the original ruby syntax is closer to C, we could go for the "c-format" flag.
I don't want to blindly add "ycp-format" marks everywhere although it would work right now as nobody probably has touched any translation text yet. But later there will be such changes for sure and then we won't know which format is correct.
Sure, at one point we would have to pay the price for the language switch. That's expected and acceptable.
I don't see any solution to this problem, I think we have just to live without the additional validation... :-(
It's probably tolerable for the time being. In the very, very past, yast used to crash there was something wrong with the format strings in the translations (such as $1 instead of %1, or "%1 at %1" instead of "%1 at %2"). Let's assume ruby is robust enough.
2/ The extractor does not seem to collapse duplicates into one entry. Thus nfs_server.pot is invalid:
msgfmt --check 50-pot/nfs_server.pot 50-pot/nfs_server.pot:122: duplicate message definition... 50-pot/nfs_server.pot:119: ...this is the location of the first definition
Strange, there is some code for merging the duplicates and works quite well, it merged all duplicates correctly in my test cases.
I'll check creating this specific POT file...
Ok, thanks for working on it!
translation@lists.opensuse.org
-
Andrea Turrini -
Carlos E. R. -
David Majda -
Efstathios Iosifidis (aka diamond_gr) -
Jiří Suchomel -
Karl Eichwalder -
Ladislav Slezak -
Ys