New i18n interface for KDE 4

[Frerich Raabe]

On Thursday 08 September 2005 15:02, Chusslove Illich wrote:
> Second, there are nice-to-have properties that you mentioned, but there is
> also syntactic cleanliness of Scheme, as I pointed out in the other
> message, which is perfect for translation scripting. And to be quite
> frank, I used Scheme in form of Guile as a test engine also because it was
> damn easy to. I have yet to see how it goes with Perl or Python.

I don't really care much about what language you decide on in the end. You're 
prolly going to just use a tiny language, too. FWIW, I think you could just 
as well invent a little script language with five to ten constructs and use 
that. As long as what you need to do 95% of the time is easy to learn, it's 
really mood to me.

> >> [: Chusslove Illich :]
> >> First is that KI18n is inherited from QString, and only has the smart
> >> arg() methods which override QString's.
> >
> > [: Frerich Raabe :]
> > This sounds totally very wrong to me.
>
> I am certainly not a daily practitioner of C++, but I would like some more
> reasons for this. If for nothing else, to really purge it out of my head.
>
> Nicolas mentions the non-dependability on QString due to possible changes
> in next major Qt, which is nice, but I said I think that many other things
> would have to be fixed throughout Qt-using code if QString changes, so
> that KI18n would be just a drop in a sea. Or is it not so?

Well yes, leaving the point that QString just has first-class value semantics 
and it just not meant to be subclassed (which is Nicolas' point, I figure), 
you also don't want all the read-write functions in your interface. You just 
want a few read-only conversions - if any at all (guess lxr.kde.org can tell 
which).

> > Source-compatibility ought to be almost guaranteed (except on those
> > cases where you depend on two or three user-defined conversions in a
> > row, I guess) if you provide a 'operator QString() const;', no? The
> > compile would (should!) choose your special KI18N::arg() over those
> > provided by QString (it's one conversion less).
>
> Well, as I said, I did run some checks. In summary, for basic KDE modules,
> I got some 500+ conversion errors. Most of them (about 75%) were when the
> needed argument was a KGuiItem, which has implicit conversion to QString
> through one of the constructors.

KGuiItem specifically takes strings which are visible in the GUI,  maybe the 
constructor which takes QString should be removed altogether and use a K18N 
instead (which kinda emphasizes the 'Like a QString, but for user-visible 
strings in KDE applications' thing about K18N - maybe this should be called 
KGUIString or so?) - that would solve the ambiguity you were seeing. FWIW, 
KGuiItem should get explicit constructors anyway (that's been in kdelibs/TODO 
for quite some time now, too).

> Most of the rest were because of 
> QVariant, which also has a constructor from QString.

Okay those should probably looked at on a case-by-case basis.

- Frerich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050908/64991a44/attachment.sig>