views:

37

answers:

2

I am interested in the "best approach" to making sure your Linux & GTK based application is built from the ground up to support i18n and localization with minimal amount of pain.

I've always heard that localization can be a real pain point to implement, so I am wondering if there is a good guideline and/or approach that can help make it as straight forward to have i18n and localization support in an application?

Here's an example guideline that I read, however this is Microsoft Windows specific... WPF Globalization and Localization Overview

+2  A: 

Use gettext. It's the standard method of supporting I18N on Linux (and can be used on other platforms as well).

The documentation looks intimidating but it basically boils down to changing your code from:

printf("Hello World!");

to

printf(gettext("Hello World!"));

then the program xgettext will extract all the strings in gettext() into PO files which can be edited using tools like poedit


Here's a nice short tutorial on how to use gettext: A tutorial on Native Language Support using GNU gettext. It basically covers the typical workflow of using gettext. Another nice article is PHP centric:Gettext - O'Reilly Media. Google around for "gettext tutorial" and you'll probably find more.

slebetman
I would add that interfaces built with GtkBuilder also use Gettext for translation.
dmitry_vk
I would also add that you have to include the `glib/gi18n.h` header and that this `#define`s `_()` as an alias for `gettext()`, so you can `printf(_("Hello world!"));`
ptomato
Also, autotools work very well with gettext, they simplify the process of creating message catalogs for your translators to translate.
ptomato
+1  A: 

I think you mean internationalization... If you internationalize your pgram from teh beginning, rather than later on, localization is easy.

Some things to watch out for:

  • Don't use concatenated strings.
  • Don't use concatenated strings.
  • Don't assume the adjective/noun order is the same in each language
  • Remember when you are designing your UI that other languages may be longer or shorter in general. German for example is around 1.5x longer, while Japanese and Chinese do not require the same amount of space.
  • Use a few words to get your message across. Why? Each word is going to cost you when you get your resources translated. < strings = < expense.
  • Store dates/times in UTC
NinjaCat
Yes I did, i18n is a common shorthand for internationalization :)
Pharaun
I know that :) What I was referring to was when you said "localization can be a pain"... it's the i18n that is the pain. l10n is a piece of cake if you have internationalized your product well.
NinjaCat
Aha, gotcha, that does make sense, my bad. But also another thing to be concerned about l10n is stuff such as right to left language esp if you have custom widgets. Then uh locale specific icons/etc... But I suppose that might still fall under the umbra of i18n :)
Pharaun
Completely agree. Images... especially if you are going to move to a bi-directional language such as Hebrew/Arabic, images will have to be re-done. Text in images is usually a hassle to localize... you have to get the string translated and create new images. Keep the text out of the images...
NinjaCat