[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: KGeography needs your help
From:       Krzysztof Lichota <krzysiek () lichota ! net>
Date:       2005-08-11 7:50:04
Message-ID: 42FB032C.6050003 () lichota ! net
[Download RAW message or body]

Chusslove Illich wrote:
>>Also books about OO programming tell to derive one class from another
>>if there are of a same kind. That is not eaxctly the case here, as
>>QString is a class for holding a string and KI18N is for processing
>>translations.
> 
> 
> Yes, I also feel some confusion with is-a/has-a distinction here, but one 
> can say that KI18n is a QString, but a smarter one, which knows how to 
> translate itself into another language :)

I think KI18n is not QString, because it does not allow changing 
contents. It is a translation container.

So it should not derive from QString. but implement some subset of its 
methods (for example arg(), length()) but excluding others, for example 
those risky from translation point of view (I think operator "+" falls 
into this category, as it seems concatenation of translations might 
break some languages).

> There is a practical problem too, programmer can do (and does) something 
> like:
> 
> QString tmp = i18n("Blah, blah, %1");
> ...
> tmp.arg(somearg);
> 
> Here the translation would be forced at the point of assignment, and script 
> wouldn't be called at all because not all arguments have been supplied. 
> But to avoid this, not only that KI18n shouldn't be inherited, but there 
> shouldn't even be QString cast operator in non-inherited KI18n class. This 
> would result in the cleanest solution, but breaking *all* current i18n 
> code and programming habits:
> 
> QString msg = i18n("Blah, blah, %1").arg(somearg).t();
> 
> where method t() would stand for "it's assembled, translate it".
> 
> So, if we don't want to break all i18n code and programming habits, than 
> perhaps solution with inheritance is not that different from the 
> non-inherited with implicit cast to QString.

I think transition to KDE4 would be perfect moment for breaking 
compatibility, so we should do it once, but properly, even if it means 
breaking and fixing a lot of code.

Solution with t() is OK for me. It gives additional consistency checking 
of translations, as it should be called only on "completely translated" 
(i.e. having all arguments) string. I volunteer to fix it in code if 
this is necessary :)

BTW. Have you noticed that we could get rid of special handling of 
plurals by programmers (which they seem to forget to use)?
Programmers could use i18n("%1 files").arg(numFiles) and the rest would 
be translators task :)
In method arg(int) we can even check if translation supports plurals and 
spit some warning if it does not.

The only problem would be for English team to provide plurals for 
English texts, but I have already been speaking for some time in favor 
of making English translated language :)

Regards

	Krzysztof Lichota (Polish team)
[prev in list] [next in list] [prev in thread] [next in thread]