New i18n interface for KDE 4

Chusslove Illich caslav.ilic at gmx.net
Thu Sep 8 19:29:06 BST 2005


> [: Frerich Raabe :]
> [...] you also don't want all the read-write functions in your
> interface. You just want a few read-only conversions [...]

I don't think that we can prevent programmers from doing stupid things in 
this sense. As long as there is a conversion to QString, whoever wants to 
do something bad with the translation, can do it.

The only real way to prevent such things would be that approach with 
widgets taking KI18n's exclusively, but that we cannot achieve for those 
other reasons.

> 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 [...] that would solve the ambiguity you were
> seeing.

Hm, it shouldn't. The problem is not in KGuiItem, but in overloaded 
functions which can take either KGuiItem or QString. So the compiler must 
not decide which overloaded version to call, which conversion to perform.

> (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?)

I also consider changing its name to KI18nString or so, especially if 
inherited from QString :) i18n() call doesn't necessarily need to be for a 
GUI string...

> FWIW, KGuiItem should get explicit constructors anyway (that's been in
> kdelibs/TODO for quite some time now, too).

Something like that would fix problem with KGuiItem, but the one with 
QVariant would remain. And for QVariant we must either use explicit 
conversions in application code, or give to KI18n implicit conversion op 
to QVariant (which is completely out of the blue).

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

This is exactly what I want to avoid. With implicit conversions, you never 
know what is going to happen in the future (which is one of main reasons 
why they are frowned upon, that is, as far as I have seen in the books :), 
while inheritance relation guarantees that whatever eats QString's, can 
swallow KI18n's too.

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050908/3dbda83c/attachment.sig>


More information about the kde-core-devel mailing list