On Wed, Aug 30, 2023 at 02:18:37PM +0200, Jonas Hahnfeld via Bug reports for
the GNU Texinfo documentation system wrote:
> Hi all,
>
> I've been playing with the Texinfo 7.0.90 pretest version and adapting
> the proposed customization file for LilyPond (again a few breaking
> changes, I can only hope future versions calm down on this...). One
> thing that seems broken are translated document strings, for example in
> the navigation buttons. Consider the attached german.texi (but adding
> "@documentlanguage de" to any document should do) and compile with:
> $ texi2any --html --split=node -o german_output german.texi
>
> If you see Next, Previous, and Up, that's wrong. That said, I'm not
> sure if it's maybe a problem with installation from git (even though
> Texinfo 6.7 and 6.8 installed from source work fine) and would first
> appreciate an independent confirmation before I could try bisecting.
This breakage can be explained, but I am not sure if it is satisfactory.
In the Texinfo 7.0.90 pretest, "contexts" were used for getting many of
the translated strings. For example, the "Next" string is translated with
pgdt('Next direction string', 'Next')}
The context here is "Next direction string". This goes via
Locale::Messages::pgettext which implements the gettext interface:
https://www.gnu.org/software/gettext/manual/html_node/Contexts.html
This won't work with any of the existing translation files, unfortunately!
The reason is that these contexts have never been provided to translators
before, so the translation files don't include them.
These contexts have broken all of these translations, possibly for
no present benefit (it would have a benefit in the future if the word
"Next" had to be translated in more than one way in different contexts
in some language).
If translators provide updated translations that include the contexts, then
the translations will work again.
I wonder if there is anything that can be done with the gettext API to
try for a translation both with and without a context. What occurs to
me is testing the return value of pgettext, seeing if it is equal to the
input string, and if it is (so the translation failed), calling gettext
instead (without the context).
Another option, I guess, would be to post-process the files we get from
the Translation Project (https://translationproject.org/html/welcome.html)
somehow to add these contexts in.
