Two years ago, H. S. Teoh presented a proof of concept for
[automatic extraction of gettext-style translation
strings](https://forum.dlang.org/post/mailman.2526.1585832475.31109.digitalmar...@puremagic.com). I recently combined that idea with the existing [mofile](https://code.dlang.org/packages/mofile) package for reading translation tables in GNU gettext format, and the result is a feature rich solution for the support of multiple natural languages in D applications: https://code.dlang.org/packages/gettext. Perhaps not surprisingly, it can do more than GNU gettext itself.
I'd like to thank Steven Schveighoffer and Adam Ruppe for
[valuable forum
assistance](https://forum.dlang.org/post/afkbwsdrspndwgkai...@forum.dlang.org), and SARC B.V. for sponsoring. Some extracts from the [readme](https://github.com/veelo/gettext#readme) are included below:
# Features
- Concise translation markers that can be aliased to your
preference.
- All marked strings that are seen by the compiler are extracted
automatically.
- All (current and future) [D string literal
formats](https://dlang.org/spec/lex.html#string_literals) are
supported.
- Static initializers of fields, constants, immutables, manifest
constants and anonimous enums can be marked as translatable (a D
specialty).
- Concatenations of translatable strings, untranslated strings
and single chars are supported, even in initializers.
- Arrays of translatable strings are supported, also when
statically initialized.
- Plural forms are language dependent, and play nice with format
strings.
- Multiple identical strings are translated once, unless they are
given different contexts.
- Notes to the translator can be attached to individual
translatable strings.
- Code occurrences of strings are communicated to the translator.
- Available languages are discovered and selected at run-time.
- Platfom independent, not linked with C libraries.
- Automated generation of the translation table template.
- Automated merging into existing translations (requires [GNU
`gettext` utilities](https://www.gnu.org/software/gettext/)).
- Automated generation of binary translation tables (requires
[GNU `gettext` utilities](https://www.gnu.org/software/gettext/)).
- Includes utility for listing unmarked strings in the project.
# Usage
## Marking strings
Prepend `tr!` in front of every string literal that needs to be
translated. For instance:
```d
writeln(tr!"This string is to be translated");
writeln("This string will remain untranslated.");
```
## Plural forms
Sentences that should change in plural form depending on a number
should supply both singlular and plural forms with the number
like this:
```d
// Before:
writefln("%d green bottle(s) hanging on the wall", n);
// After:
writeln(tr!("one green bottle hanging on the wall",
"%d green bottles hanging on the wall")(n));
```
Note that the format specifier (`%d`, or `%s`, etc.) is optional
in the singular form.
Many languages have not just two forms like the English language
does, and translations in those languages can supply all the
forms that the particular language requires. This is handled by
the translator, and is demonstrated in [the example
below](https://github.com/veelo/gettext#example-1).
## Custom markers
If `tr` is too verbose for you, you can change it to whatever you
want:
```d
import gettext : _ = tr;
writeln(_!"No green bottles...");
```
## Marking format strings
Translatable strings can be format strings, used with
`std.format` and `std.stdio.writefln` etc. These format strings
do support plural forms, but the argument that determines the
form must be supplied to `tr` and not to `format`. The
corresponding format specifier will not be seen by `format` as it
will have been replaced with a string by `tr`. Example:
```d
format(tr!("Welcome %s, you may make a wish",
"Welcome %s, you may make %d wishes")(n), name);
```
The format specifier that selects the form is the last specifier
in the format string (here `%d`). In many sentences, however, the
specifier that should select the form cannot be the last. In
these cases, format specifiers must be given a position argument,
where the highest position determines the form:
```d
foreach (i, where; [tr!"hand", tr!"bush"])
format(tr!("One bird in the %1$s", "%2$d birds in the
%1$s")(i + 1), where);
```
Again, the specifier with the highest position argument will
never be seen by `format`. On a side note, some translations may
need a reordering of words, so translators may need to use
position arguments in their translated format strings anyway.
Note: Specifiers with and without a position argument must not be
mixed.
## Concatenations
Translators will be able to produce the best translations if they
get to work with full sentences, like
```d
auto message = format(tr!`Could not open the file "%s" for
reading.`, file);
```
However, in support of legacy code, concatenations of strings do
