RFC: i18n: strict translation call-to-catalog mapping

[Chusslove Illich]

> [: Oswald Buddenhagen :]
> fwiw, irrespective of the missing hierarchy, the real problem is of course
> that all these short strings are not properly annotated.

In practice, this would be sufficient if people were very careful (see next
point). But, there is the more basic issue of one piece of code polluting
the "translation namespace" of another. Qualitatively it can be compared to
not having a namespace mechanism in a programming language, or even not
having lexical scoping -- people can quite manage without them, but it's
annoying when you know there exists better. And that better in this case is
just plain Gettext, which does not have the issue. So I personally have hard
time telling someone "oh, that's the library X translation popping up in
your application Y, add context yourself or tell maintainer of X to add
context" with a straight face.

> scripty should make reports and bug the respective maintainers when
> strings do not comply with some minimum disambiguation criteria (these
> could be statistically determined).

Krazy has been doing this for several years now. It reports missing contexts
to a number of manually indicated problematic strings, as well as when the
message is a single adjective (for several hundred most frequent
adjectives), which should absolutely never be without context. But to no
great avail. So by now programmer behavior has been sufficiently established
in this respect, a fact to count with.

> now, i'm not sure i would solve it exactly this way - the extra argument
> seems wasteful (just like in all the inlined tr() calls). i'd probably let
> the build system generate non-inline per module i18n functions and alias
> the generic one via #define to it.

Argh, one extra argument wasteful, compared to everything else going on
under the hood :) Better to compare it with the gain of no longer searching
for translation through average n/2 loaded catalogs...

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120405/eb04a75a/attachment.sig>