On 1/4/06, Isak Savo <[EMAIL PROTECTED]> wrote:
I was unclear, but I think what I said was correct. There is a difference between wide character strings and multibyte character strings. gettext handles multibyte character strings, such as those encoded in UTF-7 and UTF-8 just fine. What it doesn't handle, at least not according to the gettext manual or in the latest sources, is _wide_ character strings, i.e. strings that use exactly one 4-byte wchar_t character instead of one or more 1-byte char characters to encode any single character.
Very nice. How I wish I'd found your page before I sat down and did all the hard work. Would have saved me a bunch of time. I'll add a link to your page from the fish homepage in the hope that it will improve your Google-ranking.
There I go only thinking of myself. I never bothered to investigate the situation for translators. :(
Cool. I guess that makes sense.
Doesn't that mean you need to provide a special translatiuon for the C locale, so that it will output Space instead of Screensaver|Space?
I hope to avoid this mostly by having few enough translatable strings that no such duplicates will be found! :)
Currently, there are ~250 translatable strings, I doubt the number will be over 500 when fish is fully translated.
--
Axel
Hi, I do translation coordination for the Autopackage project, and as
such, has some experience with gettext and the GNU i18n
infrastructure. I have never used catgets though, so I won't comment
on that.
2006/1/4, Axel Liljencrantz < [EMAIL PROTECTED]>:
> Notes:
>
> The support is incomplete, there is still a small number of strings in fish
> itself missing, and all the shellscript code (including the greeting
> message) is also untranslated. Also, there is no infrastructure for
> translating the fish manual or the help messages for commands, etc. These
> things will be coming, but just adding gettext support for the C code was a
> pretty big change, espacially since gettext doesn't really know how to
> handle wide characters.
Hmm, are you sure about this? I know I've used UTF-8 as the encoding
for the reference language (english) and it works fine. Some of the
reference strings contained multibyte characters IIRC. Granted though,
I use intltool as a wrapper over gettext so it might apply some magic
to make it work.
I was unclear, but I think what I said was correct. There is a difference between wide character strings and multibyte character strings. gettext handles multibyte character strings, such as those encoded in UTF-7 and UTF-8 just fine. What it doesn't handle, at least not according to the gettext manual or in the latest sources, is _wide_ character strings, i.e. strings that use exactly one 4-byte wchar_t character instead of one or more 1-byte char characters to encode any single character.
> Read the documentation section on how to do a translation for more info on
> how to do a translation.
I've written a tutorial/introduction about this for the Autopackage project:
http://www.autopackage.org/docs/i18n/
It's targeted against translating autopackage, but most of it applies
to other projects using gettext.
Very nice. How I wish I'd found your page before I sat down and did all the hard work. Would have saved me a bunch of time. I'll add a link to your page from the fish homepage in the hope that it will improve your Google-ranking.
> Pros for gettext:
> The gettext solution is much easier to implement. Just add _() around any
> string that should be translated, and do some initial setup.
> Available for translation of shellscripts in an easy, readable way
Not to mention the amount of other OSS projects using it, and tools
available to aid translations. Thinking of KBabel, gtranslator etc.
There I go only thinking of myself. I never bothered to investigate the situation for translators. :(
> Pros for catgets
> The catgets solution is easier to maintain, since you avoid the massive
> headache caused when you want to change an existing string in the
> sourcecode. (Gettext helps a bit by providing fuzzy matching, but my
> internal tests of the reliablity of this tool where not encouraging)
> catgets also avoids some of the problems where you can have the same string
> mean different things in different contexts. As an illustration of what this
> means, in an early windows version here in Sweden, the screensaver 'Space',
> which showed a speedy flight through space, was called 'mellanslag', which
> is the swedish name for the spacebar key.
Indeed a problem, but not unsolvable. Newer versions of gettext should
support the concept of "context" strings, meaning you can have
something like:
msgctxt "Screensaver"
msgid "Space"
msgstr "Rymd"
and
msgctxt "Keyboard Key"
msgid "Space"
msgstr "Mellanslag"
This is solved in the source code by something like:
pgettext ("Screensaver", "Space")
instead of just
gettext ("Space")
Cool. I guess that makes sense.
GLib (used by GTK) has another solution which prepends the msgid with
the context separated by a pipe (|) character:
msgid "Screensaver|Space"
msgstr "Rymd"
See http://developer.gnome.org/doc/API/2.0/glib/glib-I18N.html#Q-:CAPS
Doesn't that mean you need to provide a special translatiuon for the C locale, so that it will output Space instead of Screensaver|Space?
I haven't used any of them, and I don't know how well spread the
gettext context support is (the first of my examples). And I assume
you don't want fish to depend on glib :-)
I hope to avoid this mostly by having few enough translatable strings that no such duplicates will be found! :)
Currently, there are ~250 translatable strings, I doubt the number will be over 500 when fish is fully translated.
Isak
--
Axel
