# Gettext

In computing, gettext is an internationalization and localization (i18n and l10n) system commonly used for writing multilingual programs on Unix-like computer operating systems. One of the main benefits of gettext is that it separates programming from translating. The most commonly used implementation of gettext is GNU gettext, released by the GNU Project in 1995. The runtime library is libintl. gettext provides an option to use different strings for any number of plural forms of nouns, but this feature has no support for grammatical gender. The main filename extensions used by this system are .POT (Portable Object Template), .PO (Portable Object) and .MO (Machine Object).

## History

Initially, POSIX provided no means of localizing messages. Two proposals were raised in the late 1980s, the 1988 Uniforum gettext and the 1989 X/Open catgets (XPG-3 § 5). Sun Microsystems implemented the first gettext in 1993. The Unix and POSIX developers never really agreed on what kind of interface to use (the other option is the X/Open catgets), so many C libraries, including glibc, implemented both. As of August 2019, whether gettext should be part of POSIX was still a point of debate in the Austin Group, despite the fact that its old foe has already fallen out of use. Concerns cited included its dependence on the system-set locale (a global variable subject to multithreading problems) and its support for newer C-language extensions involving wide strings.
The GNU Project decided that the message-as-key approach of gettext is simpler and more friendly. (Most other systems, including catgets, requires the developer to come up with "key" names for every string.) They released GNU gettext, a free software implementation of the system in 1995. Gettext, GNU or not, has since been ported to many programming languages. The simplicity of po and widespread editor support even lead to its adoption in non-program contexts for text documents or as an intermediate between other localization formats, with converters like po4a (po for anything) and Translate Toolkit emerging to provide such a bridge.

## Operation
### Programming

The basic interface of gettext is the gettext(const char*) function, which accepts a string that the user will see in the original language, usually English. To save typing time and reduce code clutter, this function is commonly aliased to _:
gettext then uses the supplied strings as keys for looking up translations, and will return the original string when no translation is available. This is in contrast to POSIX catgets, AmigaOS GetString, or Microsoft Windows LoadString where a programmatic ID (often an integer) is used. To handle the case where the same original-language text can have different meanings, gettext has functions like cgettext that accept an additional "context" string.
xgettext is run on the sources to produce a .pot (Portable Object Template) file, which contains a list of all the translatable strings extracted from the sources. Comments starting with /// are used to give translators hints, although other prefixes are also configurable to further limit the scope. One such common prefix is TRANSLATORS:.
For example, an input file with a comment might look like:
xgettext is run using the command:
The resultant .pot file looks like this with the comment (note that xgettext recognizes the string as a C-language printf format string):
In POSIX shell script, gettext provides a gettext.sh library one can include that provides the many same functions gettext provides in similar languages. GNU bash also has a simplified construct $"msgid" for the simple gettext function, although it depends on the C library to provide a gettext function.

### Translating

The translator derives a .po (Portable Object) file from the template using the msginit program, then fills out the translations. msginit initializes the translations so, for instance, for a French language translation, the command to run would be:
This will create fr.po. The translator then edits the resultant file, either by hand or with a translation tool like Poedit, or Emacs with its editing mode for .po files. An edited entry will look like:
Finally, the .po files are compiled with msgfmt into binary .mo (Machine Object) files. GNU gettext may use its own file name extension .gmo on systems with another gettext implementation. These are now ready for distribution with the software package.
GNU msgfmt can also perform some checks relevant to the format string used by the programming language. It also allows for outputting to language-specific formats other than MO; the X/Open equivalent is gencat.
In later phases of the developmental workflow, msgmerge can be used to "update" an old translation to a newer template. There is also msgunfmt for reverse-compiling .mo files, and many other utilities for batch processing.

### Running

The user, on Unix-type systems, sets the environment variable LC_MESSAGES, and the program will display strings in the selected language, if there is an .mo file for it.
Users on GNU variants can also use the environment variable LANGUAGE instead. Its main difference from the Unix variable is that it supports multiple languages, separated with a colon, for fallback.

## Plural form

The ngettext interface accounts for the count of a noun in the string. As with the convention of gettext, it is often aliased to N_ in practical use. Consider the code sample:
A header in the "" (empty string) entry of the PO file stores some metadata, one of which is the plural form that the language uses, usually specified using a C-style ternary operator. Suppose we want to translate for the Slovene language:
Since now there are four plural forms, the final po would look like:
Reference plural rules for languages are provided by the Unicode consortium. msginit also prefills the appropriate rule when creating a file for one specific language.

## Implementations

In addition to C, gettext has the following implementations: C# for both ASP.NET and for WPF, Perl, PHP, Python, R, Scala, and Node.js.
GNU gettext has native support for Objective-C, but there is no support for the Swift programming language yet. A commonly used gettext implementation on these Cocoa platforms is POLocalizedString. The Microsoft Outlook for iOS team also provides a LocalizedStringsKit library with a gettext-like API.