printk() indexing [LWN.net]

printk() indexing

Posted May 30, 2021 20:17 UTC (Sun) by mathstuf (subscriber, #69389)
In reply to: printk() indexing by madscientist
Parent article: printk() indexing

Gah, I was thinking about it backwards. I now see what you mean. Since the key is the "default text", if it changes, the translations automatically need changed as well. Versus where the key is some ID where if the default text is updated, the other translations need some marker to indicate that they need to sync up.

It's not an easy problem. How does Gettext deal with text which is spelled the same but has different meanings depending on context? Let's say there's a button with the text "Bark" on it. How is it indicated that one wants "dog bark", "bark a shin", or "tree bark" with the default text as a key? I assume there is some way to plumb some kind of intent message through to the interface translators use?

to post comments

printk() indexing

Posted May 30, 2021 21:17 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

You can just put Bark(Tree) in the message and provide translation for English.

printk() indexing

Posted Jun 1, 2021 13:28 UTC (Tue) by flussence (guest, #85566) [Link]

I've even proposed that as good practice somewhere before. Just in case people need more selling on the idea:

The source code naturally contains LC_MESSAGES=C strings; those don't need to be written for anyone but the author and can shamelessly be optimised for high jargon density and minimum mental context switching. It gives a motive to write a human translation later, and even if that's just en_US with few changes you've now made a map of the terrain for anyone else to work with. There's a long tail of other benefits besides (such as, the one I started the thread with).

printk() indexing

Posted May 30, 2021 21:27 UTC (Sun) by mbunkus (subscriber, #87248) [Link] (3 responses)

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

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.