Re: Problem with gtranslator and utf-8 (slovak and azeri translations)

["R.I.P. Deaddog" <maddog linuxhall org>]

On Mon, 28 Jan 2002, Pablo Saratxaga wrote:

> > #. *  if the gtranslator user wants to it so. It could be that the \xb7 
> > character
> ...
> > #: src/zpmd.h:38
> > msgid ""
> > msgstr ""
> > 
> > ... and we have two empty msgids ... :-(
> > 
> > So, where is the problem?
> 
> The problem is hardcoding the value \xb7, that is bad.
> \xb7 is an illegal value for all multibyte encodings.
> 
> There are two solutions (and only two solutions) to that problem:
> 
> - use utf-8 in the sources, encode the middle point in utf-8 and force the
>   use of utf-8 for all the po files of gtranslator

Even the first solution won't work for 100%. When converting back from
utf-8 to local charset, there's no corresponding char for the middle dot
in all multibyte locale, hence the middle dot still won't work right for
these locales -- though msgfmt doesn't complain anymore, that's the good
point.

> - use ascii only in the sources, change the \xb7 to some ascii only value
>   (like "." or "#" or "_" or whatever)

Yes, this idea suggested by Gediminas can be a good solution; use ascii
by default, and put some comment to tell iso8859-* translators to use
\xb7 instead, while other encodings should use their own char.

> The charset encoding used in msgid and msgstr fields for a po files MUST be
> the same.
> There are only two ways to achieve that: never use any non-ascii char
> in the msgid; or use exclusively utf-8 (the only encoding suitable for all
> languages)
> 
> > I'm using gettext-0.10.38 and intltool-0.12.
> 
> With old versions that problem didn't show up, as no checking was done on
> po files at all.
> But now it cannot be ignored any longer.
> 
> xmms is another program that has such problem, making all utf-8, japanese,
> korean and chinese translations fail.

I'd like to add some more -- gnumeric for example.

Abel