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