Permalink
Reply
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:
- https://dconf.org/2023/slides/veelo.pdf page 77
explains how to generate repetitive msgids through the use of 'foreach' and the 'tr!' template.
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
>- 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).
>- 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.
>- 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.