printk() indexing [LWN.net]

printk() indexing

Posted May 30, 2021 21:27 UTC (Sun) by mbunkus (subscriber, #87248)
In reply to: printk() indexing by mathstuf
Parent article: printk() indexing

The gettext system knows a concept called "Contexts". This is basically a second parameter for the translation functions that works as a disambiguation. You'd have calls to 'pgettext("dog", "bark")' and 'pgettext("tree", "bark")', and both would show up in PO files as two separate entries to translate. How you name contexts is totally up to you.

Contexts are optional. The most basic function, 'gettext("bark")', works without a context.

See here for more details: https://www.gnu.org/software/gettext/manual/html_node/Con...

to post comments

printk() indexing

Posted May 31, 2021 12:30 UTC (Mon) by eru (subscriber, #2753) [Link] (2 responses)

That requires original authors to use contexts assiduously, because they may not even be aware when a translation depends on it. In Microsoft's web mail, the English word "Empty" was used in two senses (something is empty, or as a command to empty a folder). The Finnish localisation seemed to have been made with a simple string substitution, and used a word that was appropriate only for the first meaning. (This has since been fixed).

printk() indexing

Posted May 31, 2021 14:09 UTC (Mon) by mbunkus (subscriber, #87248) [Link]

Yeah sure, but good knowledge about the pitfalls of translation (or in general: localization) is always required for good translations. The question I answered was "how does gettext deal with terms that have different meanings in different contexts", and in order to solve this in any way, shape or form, requires awareness of the possibility of different meanings. No matter the translation system in use.

Systems that use symbols instead of real text in the source files also require the author to have that awareness so that the author can use two different symbols in different places, even if both symbols' corresponding text in the original language is the same.

Localization is a complex topic. You cannot magic complexity away. All systems add to that complexity in certain ways, some more than others. Some systems only seem to do away with part of the complexity, but at the cost of flexibility and expressiveness, leading to awkward or wrong translations.

printk() indexing

Posted May 31, 2021 18:07 UTC (Mon) by madscientist (subscriber, #16861) [Link]

Localization / internationalization is hard, there's no doubt about it. Successful i18n is an ongoing conversation between the code maintainer and the translator about what is needed vs. what is feasible.

There's no way every maintainer can know enough about all the different languages and their needs to get everything right the first time; that's not the goal. The maintainer's responsibility is to be receptive to the issues raised by the translator to make their job easier and a good translation possible.