> [: 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 (Часлав Илић)
signature.asc
Description: This is a digitally signed message part.