i18n and QStrings

Andras Mantia amantia at kde.org
Sat Nov 29 18:58:03 GMT 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 29 November 2003 19:10, Thiago Macieira wrote:
> Andras Mantia wrote:
> >Hi,
> >
> > As today I hit the problem that my QString got damaged after a i18n call
> > (it contained unicode chars - eg.  ű = udoubleacute - and it was replaced
> > by ?) because i18n() expects const char *, I think it would be a good
> > idea to add a QString i18n(const QString& text) which would call simply
> > be:
> >
> >QString i18n(const QString& text)
> >{
> >   return i18n(text.utf8());
> >}
> >
> >Is it a bad idea? Yeah, I don't really know which one will be picked up in
> >case of i18n("foo")...
>
> i18n expects an 8-bit encoded text, not a Unicode text. Why do you need to
> translate something that is already Unicode?
Because it's in English? In our case we have user loadable toolbars. Each 
toolbar has a name, read from an XML file. Those names should be translated 
(if the toolbars are shipped by default with Quanta), so we muse use 
i18n(toolbarname). The toolbarname is a QString. But it's also possible to 
rename a toolbar. In this case toolbarname may contain non-English chars, but 
as soon as the same i18n(toolbarname) is called (for example in the place 
where the toolbar name is actually set), it doesn't return toolbarname as 
expected, but a modified string. One would expect that i18n(text) == text if 
text is not translated. Currently i18n(text.utf8()) == text as the above 
addition would help in this case.

Andras

- -- 
Quanta Plus developer - http://quanta.sourceforge.net
K Desktop Environment - http://www.kde.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/yOw7TQdfac6L/08RAlFpAKDKLdUXJNeFl/xFvUpLGu6Bqs8+6wCfWfLE
goWReyERLRAlTyElZn4z90c=
=F6ip
-----END PGP SIGNATURE-----




More information about the kde-core-devel mailing list