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. > 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. > 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. > 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") 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 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 :-) Isak ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
