Internationalization support and format strings

[Bastiaan Veelo]

On Friday, 3 October 2025 at 22:53:09 UTC, Bruno Haible wrote:
> 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.

```d
foreach (i, where; [tr!"hand", tr!"bush"])
     writefln(tr!("One bird in the %1$s",
                  "%2$d birds in the %1$s")(i + 1), where)
```

It appears to me that you misread that code. This is a 
(contrived) example of explicit ordering of placeholders 
(https://youtu.be/FYKrXsnzrIM?si=F-MaAh0rWMoa0cj-&t=1534). I fail 
to see the generation of repetitive msgids, there are just three 
in this example. If you think that looping over translatable 
strings is a bad idea then that is fine by me, but it is not a 
flaw in the package to support such feature.

>    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.

They don't.

>    - 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.

There are no generated strings. The strings in the code are the 
strings to be translated. There is full compliance with the 
manual that you reference here.

>    - It is impossible for the programmer to attach translator 
> comments in such scenarios.

Yes, comments are fully supported, adding them here is trivial. 
https://youtu.be/FYKrXsnzrIM?si=YcsCqnohRnzG61ZH&t=1711

> 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.

Again, a feature of the package is not a misfeature just because 
using it is a bad idea. Code generation is an integral feature of 
the language, and this package supports it (and it didn't need to 
do anything special for it, it just works due to the approach 
taken).

> 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"),

You can, using conditional compilation.

> - when cross-compiling (because you can't execute the 
> just-compiled code during the build process).

It is a separate and different build. You would configure the 
xgettext config to be native, then cross-compile to any other 
targets. No traces of extraction code appear in non-xgettext 
builds.

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

Well observed. There is nothing in the standard that disallows 
this. 
https://www.gnu.org/software/gettext/manual/gettext.html#PO-Files. They are fully supported by the GNU gettext utilities. I think it is a useful feature.

I applaude adding support for D in official GNU software, and I 
thank you for the work that you put into it. I am sorry that I 
didn't see your post earlier. There are different tradeoffs to 
using GNU xgettext and using --config=xgettext. The biggest 
downside of the latter is that string extraction takes about as 
long as a full build; GNU xgettext is likely much quicker. What 
this gets you is platform independence and complete language 
coverage without maintenance 
(https://youtu.be/FYKrXsnzrIM?si=yFTIrhN5KWSa5uc8&t=2915). Which 
is why you haven't seen any updates to 
https://code.dlang.org/packages/gettext.

-- Bastiaan.