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

[Oswald Buddenhagen]

On Wed, Apr 04, 2012 at 09:25:10PM +0200, Thomas Zander wrote:
> On Wednesday 04 April 2012 21.11.22 Chusslove Illich wrote:
> > > First, any Qt tr call has a context (typically the class name), am I
> > > correct that i18n() still does the same thing?
> > 
> > It doesn't: context is added manually, when judged or reported to be
> > needed. (And this is how it always was.)
> 
> Just to be clear; I  am talking about the 'context' as used in the first 
> argument to QCoreApplication::translate() method.
> 
chusslove understood you perfectly well. ;)
gettext never did that.
and in qt these auto-contexts are a pita, as they lead to a lot of
duplication within a single catalog. it's really not the right solution.
so chusslove is suggesting an auto-context feature which works on the
catalog level, not on the class level. seems pretty obvious to me.

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. that would also leave some
room for a heavier implementation of the translation function, e.g.,
automatically instantiating a QTranslator() (if gettext was not used).

fwiw, irrespective of the missing hierarchy, the real problem is of
course that all these short strings are not properly annotated. scripty
should make reports and bug the respective maintainers when strings do
not comply with some minimum disambiguation criteria (these could be
statistically determined).