KDE4 proposal: Paths in i18n strings

[Frans Englich]

On Wednesday 05 July 2006 16:44, Chusslove Illich wrote:
> >> [: Chusslove Illich :]
> >> i18n("Filename: %1", argPath(fname)); // -> Filename: <b>%1</b>
> >> pi18n("Filename: %1", argPath(fname)); // -> Filename: "%1"
> >
> > [: Frans Englich :]
> > I don't think this works. Where something will end up isn't necessarily
> > determined at compile time, but is a dynamic thing. It all depends on
> > where messages will be redirected. [...]
>
> My head is about to split :)
>
> So far, programmers also had to decide what format message will take, ie.
> to put or not rich text. And I think we should really avoid having some
> widgets take QString's and other KLocalizedString's, that'd be a mess.

Agreed. I don't suggest that any widgets should be changed in anyway. (What 
makes you think that would be required?)

> So, while perhaps not optimal, I think it should be kept simple: QString's
> still bread and butter of GUI, and KLocalizedString's only for commando
> actions (ie. programmer wants to insert argument later, pick translation
> from different language, delay translation, etc.)

If that alternative is chosen, no i18n related calls(such as i18nPath()) can 
use rich text since the markup will end up in the console. And I think that's 
a pity, because all this could work out *really* nice.

I would with interest see why my suggestion of adding a QString operator to 
KLocalizedString combined with letting i18n return KLocalizedString, doesn't 
hold.


Cheers,

		Frans