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

List:       kde-i18n-doc
Subject:    Re: KGeography needs your help
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2005-08-11 12:48:29
Message-ID: 200508111448.30007.nicolasg () snafu ! de
[Download RAW message or body]

On Thursday 11 August 2005 09:50, Krzysztof Lichota wrote:
> 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.

Yes, especially as half of the code under the current i18n() implementation i 
not in the QString form but a const char*

>
> 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 :)

Sorry I do not like it. It changes much the way of developing. Developers 
already forget i18n(), they will be even more disoriented if there is a 
"magic" function to call.

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

That would mean that everybody needs scripting. That does not really to be 
wanted.

>
> 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 :)

That really seem redundant.

>
> Regards
>
> 	Krzysztof Lichota (Polish team)

Have a nice day!

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