Re: [Bug-gnubg] updated po files

[Joern Thyssen]

On Tue, Jun 15, 2004 at 10:33:45AM +0200, Petr Kadlec wrote
> Hi!
> 
> > i.e., line 5647 from gnubg.c. It's the header of .gnubgautorc. I think
> > the problem is that you've duplicated the header, so it's written in
> > both Czech and English. 
> 
> Yes, I did that, thinking that a script file should contain both
> language versions. But that was probably not a good idea. Anyway: 1.
> That dual translation has been in the file since the first version, I
> have not changed it in this version.  2. The formatting strings used
> are "%s" and "%1$s" (they should refer to the same argument). As I
> look to them now, I think that they really are not correct. I am not
> sure, but if the position specifier is used, it must be used with all
> arguments, maybe. So that instead of that "%s", "%1$s" should be used.
> 
> OK. I presume that the double-language idea was not really great, so
> that I will delete the czech translation (anyone who is editing his rc
> file by hand is probably english-capable anyway...), which should
> definitely fix the problem. The reason why this problem has not
> appeared until now is probably that you have upgraded your gettext,
> hasn't you? If that version improved its error detection capabilities,
> it could report the argument specifier error which my gettext gladly
> accepted.

Hmm, now that I think of it, I may have done a "touch cs.gmo" earlier to
supress update of it. 

I can see the point of having the header in both Czech and English, so
I'll try changing both identifiers to "%1$s", and see if this works. 
> 

> > That could be. What's the MD5 checksum of your cs.po (the one you've
> > committed)?
> 
> Well, my file has a different checksum, but if I convert the line ends
> using fromdos, I get exactly the same hash, which proves that CVS
> converts line ends during transfer (which is good and well).

Well, yes and no. For single byte character sets this is good. However,
for multiple byte characters sets this is problematic. For example, the
unicode character sequence for a c with a dot above is 0x01 0x0A. I
think cvs would convert this to 0x01 0x0A 0x0D inserting a line feed in
the text. Consider this imaginary UTF-8 sequence: 0x0A 0x56 being
converted by cvs to 0x0A 0x0D 0x56, which is probably an illegal UTF-8
sequence. 

Anyway, I can see that Kaoru has committed a fix.

J?rn