New i18n interface for KDE 4
Michael Olbrich
michael-olbrich at web.de
Thu Sep 15 12:28:42 BST 2005
On Tue, Sep 13, 2005 at 04:28:59PM +0200, Chusslove Illich wrote:
> > So I think we should stop discussing what is possible and think about
> > the best way of doing it.
>
> If you insist, I do have one untried idea, but it looks to me a bit
> grotesque. And it certainly changes the programming practices.
>
> As I mentioned before, we make KI18n non-inherited, without implicit
> conversions, but with a method to finalize the translation and return a
> QString, like that t(). But then, instead of making i18n() functions
> return KI18n, we make them as series of templates which return QString,
> like this:
>
> // Basic, no arguments
> QString i18n(const char *text) {
> return KI18n(text).t();
> }
[...]
> Second, if programmer wants to defer adding of arguments to a later point,
> he must call t() himself *and* use fourth, special version of i18n, which
> returns a KI18n, like this:
>
> KI18n msg = di18n("Blah, blah: %1");
> ...
> msg.arg(foo).t();
In that case, why use the class at all?
const char *msg = "Blah, blah: %1";
...
i18n(msg, foo);
Does the same job. However, both cases allow nasty things like:
QString msg = i18n("Blah, blah: %1");
...
msg.arg(foo);
Maybe whatever gettext replacement or preprocessor we get could do some
sanity checks here.
michael
More information about the kde-core-devel
mailing list