gettext

Get the translation of a string as specified in the domain file (falls back to given msgid if no translation exists)

$ LANGUAGE=[locale] gettext [[-d|--domain]] [domain] "[msgid]"

$ gettext [[-h|--help]]

$ gettext [[-V|--version]]

gettext [OPTION]... [TEXTDOMAIN] MSGID [PLURAL_MSGID N]

-d TEXTDOMAIN, --domain=TEXTDOMAIN
    Specify the text domain to use. This indicates the name of the message catalog to search within.

-e, --expand-all
    Expand all escape sequences in the output string (e.g., `\n` for newline).

-n, --no-fallback
    Do not fall back to printing the untranslated MSGID if a translation is not found in the catalog.

-s, --string
    Treat the arguments as literal strings rather than file paths. This is the default behavior for the gettext command.

-c CONTEXT, --context=CONTEXT
    Specify the context for the message. This is used when a message can have different translations depending on its context (similar to `pgettext`).

-h, --help
    Display a brief help message and exit.

-V, --version
    Display version information for gettext and exit.

The gettext command is a fundamental utility within the GNU gettext internationalization (i18n) and localization (l10n) system. Its primary purpose is to retrieve a translated string for a given message ID from a message catalog.

This allows applications to display messages in the user's preferred language without requiring recompilation. When a program wants to display a message, it internally calls a `gettext()` function, passing an untranslated English string (the message ID). The gettext command-line utility mimics this behavior, enabling users or scripts to test translations or retrieve specific messages directly.

It searches for a compiled message catalog file (an .mo file) based on the specified text domain and the current locale settings (e.g., LC_MESSAGES, LANG). If a translation is found, it is printed to standard output; otherwise, the original message ID is returned. This system is crucial for creating multilingual software, separating translatable strings from the source code and managing them in easily editable .po (Portable Object) files, which are then compiled into binary .mo (Machine Object) files for efficient lookup.

• Locale Configuration: The command heavily relies on the correct setting of locale environment variables (e.g., LANG, LC_ALL, LC_MESSAGES). If these are not set or the corresponding message catalogs are missing, the command will often return the original message ID.
  
• Text Domain Path: Message catalogs (.mo files) must be located in standard system paths like /usr/share/locale or /usr/local/share/locale, or paths specified by applications using `bindtextdomain`. The gettext command-line tool itself does not offer direct options to specify arbitrary catalog search paths, relying on the default system configuration.
  
• Encoding: Ensure that your terminal's character encoding matches the encoding of the message catalog for proper display of translated characters. Incorrect encoding can lead to garbled output.

A text domain is a logical name for a set of message catalogs, typically corresponding to an application or library (e.g., `coreutils`, `gnome-shell`). When using gettext, you specify a text domain to tell it which catalog to look into for translations.

These are files containing the actual translations. .po (Portable Object) files are human-readable translation files, which are edited by translators. .mo (Machine Object) files are compiled binary versions of .po files, optimized for fast lookup by programs like gettext.

The locale system defines language, country, and character encoding settings for a user's environment. gettext uses the current locale (specifically the LC_MESSAGES or LANG environment variable) to determine which language version of a message catalog to load (e.g., en_US for American English, fr_FR for French).

The GNU gettext project was initiated by the Free Software Foundation in the early 1990s as a standard approach to internationalization for GNU software. The gettext utility is a core component, providing the runtime translation lookup mechanism. Its design was influenced by existing i18n approaches but aimed for a more robust and widely applicable solution for free software projects. It quickly became the de facto standard for i18n on Unix-like systems and is now integrated into many programming languages and frameworks, forming the backbone of most Linux desktop environment translations.

msgfmt(1), xgettext(1), msginit(1), msgmerge(1), localedef(1)