blob: fb5e7c6fa3e0a579d9c3d974ca78f372e48e52cb [file] [log] [blame]
Internationalization notes
- apps:
- use setlocale to parse locale env vars and set to language code
- use textdomain to set the text domain of their app
- use bindtextdomain to tie the domain to a locale dir
- use gettext (possibly disguised as _) to translate in the current domain
- libraries:
- should only use bindtextdomain to tie a domain to a locale dir
- use dgettext (possibly disguised as _) to translate from a set domain
- How to make your plug-in code translatable:
- include <gst/gst-i18n-plugin.h> in all files that mark strings for
translation, or do the bindtextdomain call
- in plugin_init, add a block like this:
GST_DEBUG ("binding text domain %s to locale dir %s", GETTEXT_PACKAGE,
#endif /* ENABLE_NLS */
- mark all strings you want translated for translation by wrapping them in
- typically, these are all strings that serve as the message string for a
- but it could also consist of any strings that may end up being presented
to the user (for example mixer track)
Things to watch out for
- forgetting to bindtextdomain is an error that is not always noticeable,
- any plugin from the same module being init'd binds the text domain,
so you may forget it in B, and still have it work because A bound the
- without a bindtextdomain call, any domain is bound to the system locale
dir - so you could still have translations if it happens to be where the
translations are
- our translations are managed by the Translation Project
They are updated by the release manager for prereleases using
make download-po
As the translator project website clearly states, only accept translations
from the translation project, and direct would-be translators there:
"It would defeat the purpose of the teams if you were directly accepting PO
files from individual translators, or were having "contracts" with them. If
people write to you, wanting to volunteer as translators, direct them to, and the translation coordinator will send them
appropriate documentation."