openSUSE:YaST development i18n
Internationalisation (i18n) are means of adapting computer software to different languages and regional differences. Internationalization is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes. This page attempts to cover the most common aspects of i18n-ing YaST - that is, necessary changes in code, testing i18n-related changes, generating pot-files etc. all that in order to make strings YaST modules translatable.
General questions
Q: Where do I get YaST translations for my language?
A: Install yast2-trans-$lang_code package.
Q: Where are YaST-specific files with translations located?
A: In /usr/share/YaST/locale/$lang_code/LC_MESSAGES, where $lang_code is two- or four-letter code of particular language (e.g. fr, cs, en_US,...). Their name consists of YaST module name and .mo suffix
Q: But my text editor shows only binary garbage when I try to view any of those *.mo files
A: Use msgunfmt from gettext-tools package for viewing, for example like this:
msgunfmt packager.mo | less
Making strings translatable
Q: How do I mark a string in YaST code for translation?
A: There are several ways of doing it, depending on the programming language you use.
- In YCP: use _ macro:
string i18n_string = _("My grandma has a green parrot") - In Perl: use __ (double underscore) macro:
my $i18n_string = __("My grandma has a green parrot") - In all languages, you may use gettext keyword, however make sure that your textdomain is correctly initialized (via bindtextdomain) and the code looks for the translation in YaST directory (see above)
Q: Can the '_' macro deal with plural forms?
A: Yes.
string l10n_string = _("My grandma has %1 green parrot", "My grandma has %1 green parrots", i);
Q: Can I translate strings in other (non-YaST) textdomains? Can I combine those within one source file?
A: Yes, but be careful when doing it. There are dedicated YCP string builtins you may use. dgettext will search for translatable strings in system-wide /usr/share/locale/$lang_code/LC_MESSAGES, use it like this:
string msgid = "My grandma has a green parrot";
// some-textdomain.mo file must exist in /usr/share/locale/$lang_code/LC_MESSAGES
// and it has to contain specified msgid entry
string l10n_string = dgettext("some-textdomain", msgid);
Or, if your translation files are on a completely different place, use the dpgettext builtin and specify the full path as one of the parameters like this:
string l10n_string = dpgettext("some-textdomain", "/path/to/l10n/files/", msgid);
Q: How do I generate pot-files for my module?
A: Just do make pot or y2tool y2makepot in the root directory of the module (you need yast2-devtools package for those). The good thing about this tool is that it can notify you about possible errors (e.g. missing 'textdomain' statement in the beginning, even though the file contains strings marked for translation).
Q: How can I make sure strings from my YaST package make it into yast2-trans packages?
A: If your YaST module sources are in YaST subversion, you don't have to care anymore. Pot-files from there are collected weekly (or as needed). If your module is however somewhere else, please write to translation coordination mailing list and arrange a suitable way of submitting pot-files with them.
Q: How do I make binary .mo out of .pot file?
A: Use msgfmt as follows:
msgfmt your-module.pot -o your-module.mo
Q: What is 'POTFILES' file in the root directory of YaST module good for?
A: It is an alternative way of specifying files with translatable strings. It contains file names (relative path to them) used for gathering strings for the package's pot-file, one on each line:
./src/modules/File.ycp ./src/clients/client.ycp ...
Q: Strings from my file are pulled into pot-file, but the file type is incorrectly identified as C source. What's wrong?
A: The file probably has no extension, which is used by xgettext to determine the programming language of the source code. Thus, C is used as a default fallback. This is a limitation of xgettext. You can workaround it by creating a symlink to that file with appropriate extension, e.g. for Perl source you do:
ln -s myfile myfile.pm