Difference between revisions of "GettextForWesnothDevelopers"
(Removed some dead links which are probably no longer useful) |
(Removed various obsolete sections) |
||
| Line 2: | Line 2: | ||
Warning: this page still contains a couple of outdated items to be removed. | Warning: this page still contains a couple of outdated items to be removed. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== How to move strings from one textdomain to another == | == How to move strings from one textdomain to another == | ||
| Line 33: | Line 16: | ||
any translation update gets used instead of the current one) | any translation update gets used instead of the current one) | ||
* check ''cvs diff'' and commit | * check ''cvs diff'' and commit | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Open items == | == Open items == | ||
| Line 78: | Line 52: | ||
this data. Otherwise we can just hardcode a list of known languages - indeed, we start with an hardcoded list (like | this data. Otherwise we can just hardcode a list of known languages - indeed, we start with an hardcoded list (like | ||
what gcompris does). | what gcompris does). | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== General design of gettext use == | == General design of gettext use == | ||
| Line 123: | Line 75: | ||
descriptive string and a ''^'' character, thanks to the ''sgettext'' implementation partly stolen from the gettext | descriptive string and a ''^'' character, thanks to the ''sgettext'' implementation partly stolen from the gettext | ||
manual (eg. ''foo_prefix = _ "foo prefix^"'') | manual (eg. ''foo_prefix = _ "foo prefix^"'') | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== See Also == | == See Also == | ||
Revision as of 19:45, 6 July 2012
This page is used to help Wesnoth developers to work with the internationalization (i18n) system, based on GNU gettext.
Warning: this page still contains a couple of outdated items to be removed.
Contents
How to move strings from one textdomain to another
- run make -C po update-po and commit, to be sure to only commit your own changes
- move the file into the corect po/*/POTFILES.in
- add or change #define GETTEXT_DOMAIN "wesnoth-lib" at top of the file, before the includes
- update the target POT file to include the new strings in its template (eg. make -C po/wesnoth-editor
wesnoth-editor.pot-update)
- copy the translations using utils/po2po (eg. ./utils/po2po wesnoth wesnoth-editor)
- update the source POT file to get rid of the old strings (eg. make -C po/wesnoth update-po), then preferably
remove the translation from obsolete strings in all languages, to make sure, in case the strings have to move back, that any translation update gets used instead of the current one)
- check cvs diff and commit
Open items
- understand how symbols["noun"] is currently set in playrurn.cpp::delete_recall_unit::button_pressed() and
find a way to handle that.
- understand mapgen.cpp::generate_name() and find a way to handle that.
- find how we will handle hotkeys and their localization
(https://savannah.nongnu.org/bugs/?func=detailitem&item_id=9982)
- prefix and suffix stuff (eg. "game name prefix|") should be allowed to be empty in the translation when they are
not in English. Find a clean way to do that, other than using a space (ideas: unicode no-width space ? use a format string instead, like "${name}'s game") (**solved**, basically:
string_map i18n_symbols;
i18n_symbols["login"] = preferences::login();
name_entry_.assign(new gui::textbox(disp_,width-20,
vgettext("$login's game", i18n_symbols)));
)
- In the pre-gettext era, the list of languages presented to the user is detected at runtime. We could do this as
well by looking at available wesnoth message catalogs for gettext. But the values we would get are things like "fr", which are problematic because:
- the locales to use are things like fr_FR or fr_CA, and the one to use appears to depend on the system what locales
are available on the local system (please prove me I'm wrong), whereas the available translation usually have no area code (eg. "fr"). This makes choosing a locale to get an autodetected translation quite tricky, so we'll hardcode the list for now.
- we need a simple way of presenting the user with the name of the language, in that language. Since those strings
should be the same regardless of the current locale being used, gettext itself is of no use here. Those language names are available on GNU/Linux in /usr/share/locale/all_languages (thanks Cedric), but we need a portable API to access this data. Otherwise we can just hardcode a list of known languages - indeed, we start with an hardcoded list (like what gcompris does).
General design of gettext use
Gettextized programs usually contain the English strings within program code, with calls like printf (_("Hello world. "));, so that the binary can work (in English) when the system does not support i18n. However, in Wesnoth all strings were moved into translations/english.cfg, and fetched using a label, like in translate_string("hello_world");.
So we will need to put such strings (mostly GUI material) back into the C++ files. That part will be quite easy, except we'll have to deal with importing existing translations. We will use the wesnoth text domain for this (that is, a single wesnoth.po file for each language).
The general idea for strings in WML files is to use distinct text domains for each campaign, so that campaign writers can easily ship translations together with their campaigns. It will require WML files to declare which text domain they belong to.
If some strings look the same in english but should not necessarily look identical in translations (eg. all those prefix/suffix strings, many of which are empty in english). To hande this, those strings can be prefixed with any descriptive string and a ^ character, thanks to the sgettext implementation partly stolen from the gettext manual (eg. foo_prefix = _ "foo prefix^")