[Fish-users] I18n support for fish

[Axel Liljencrantz]

Hello, all

Since the total number of people who have expressed an interest at translating fish to another language at one time has now grown to a stunning TWO people, I have gone ahead and spent far too much of the last week _not_ playing with my Xbox 360, and instead adding gettext support for fish. The darcs tree should contain the result, including a swedish translation.

Notes:

The code has passed by own rigorous test suite (a.k.a. make all), but I don't have access to lots of cool machines, so I'd be very interested in hearing if things compile on various platforms. There are some semi-big changes in there... If you want to understand nothing, just doewnload the latset darcs fish, install it and 'set LANG sv_SE.utf8'. Prepare for some åäö!

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.

Read the documentation section on how to do a translation for more info on how to do a translation.

I tried out both catgets and gettext, which seem to be the common, open i18n libraries. The main differences between these two is that gettext indexes translations based on the english-language string, while catgets indexes translations on a unique ID that you have to manually assign to every translatable string. Translation don't seem to get a lot of love, though. The gettext example program doesn't compile, nor does the catgets example provided in the Glibc manual. The gettext manuals seems to partly be written as a discussion with itself. You'd almost think _I_ wrote them...

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

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.
catgets is more portable. Both seems to exist on Linux, Solaris and *BSD (only through ports), but only catgets is available on OSX and various other Unixes. This is not as big of an issue as it may seem, since it can be fixed by the user installing gettext. One could even bundle gettext with fish.

I dont really care either way about the catgets vs. gettext interface, both have their advantages. In the end, I chose to go with gettext because I felt that providing translatable strings in a readable, standardized way from shellscripts was an even bigger showstopper than translations on OSX out of the box.

I have made sure that fish should build even without gettext, but since _I_ wrote it, I don't expect the fallback to work on the first try. ;-) Please do test!

--
Axel