Internationalization support and format strings

[Bruno Haible]

On Tuesday, 25 March 2025 at 16:00:09 UTC, Steven Schveighoffer 
wrote:
> https://code.dlang.org/packages/gettext
> I would focus on that one for de-facto standardization. Likely 
> it has a small number of users, but would be actively fixed if 
> issues are found.

No, this approach from https://code.dlang.org/packages/gettext is 
not suitable for wide-scale use, due to the following misfeatures:

1) https://dconf.org/2023/slides/veelo.pdf page 77
    explains how to generate repetitive msgids through the use of 
'foreach' and the 'tr!' template.
    Such generation of msgids is a bad idea for several reasons:
    - Care should be taken to not burden translators with 
unnecessary work. If a programmer does not want to write N 
strings, the translators should not have to translate N strings.
    - It is impossible for the programmer to review the msgids 
according to 
https://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html in such scenarios.
    - It is impossible for the programmer to attach translator 
comments in such scenarios.

2) https://github.com/veelo/gettext/blob/main/README.md says that 
they "scan any generated code that may be mixed in". But 
translators are humans and occasionally want to consult the 
actual source code for understanding the context of messages. 
They can't consult code produced by the compiler on-the-fly, nor 
can they consult the generated binary code.

3) It mixes library code and build-time add-ons into one file. 
This does not work
      - for internationalized libraries (because they are not an 
executable, that can be subject to "dub run --config=xgettext"),
      - when cross-compiling (because you can't execute the 
just-compiled code during the build process).

4) It generates non-standard POT files (with function names after 
the line numbers).