KDE4 proposal: Paths in i18n strings

[Frans Englich]

On Friday 07 July 2006 08:47, Krzysztof Lichota wrote:
> Chusslove Illich napisał(a):
[...]

> >> If type is defined by user, there is always room for mistakes, forgotten
> >> calls, etc. Type should be determined by compiler.
> >
> > I'd say it is unavoidable that user has to specify the meaning. For
> > example, an outside reported message ("Foo reported: %1") could have
> > special formatting, and it is certainly going to be just some general
> > string type. I guess paths too are frequently just a string.
>
> I thought we are talking about passing something like QPath, for the
> purpose of transforming it to platform-dependent representation :)
> Using strings as paths makes it harder and error-prone.

Even though I like the idea very much, I don't think it works. For paths it 
works because they have natural non-QString representations(such as QDir), 
and therefore one can overload without trouble. But if we select another 
category, such as "identifier" instead of "path", the only types are 
QChar/QString. So, then we end up with:

i18n("Some string content %1", myArg);

Should %1 be marked as an identifier or be treated regularly? No one can tell. 
argIdentifier() is need here.

So there are some semantical categories where one can't rely on overloading. 
Also, as soon one overloads one type, one have hard coded it to a particular 
semantical meaning. For example, in i18n("foo %1"), myQDirVar), a QDir can 
only be treated as a path. I think it's ok for that case, but perhaps it 
doesn't hold for other cases.

I wonder what people include in their strings. Perhaps everything can be 
divided into semantical categories.

[...]
> My point is that if there are 2 prefixes and developer will have to
> choose which, in some cases he chooses wrong. Applying
> internationalization should be no-brainer: "put i18n around the string".

Yes, I would like to emphasize this too. If one have to think about output 
format and pay much attention to the type of argument that's inserted into a 
string, we'll get a lot of bugs. It should be simple, transparent and 
generic.


Cheers,

		Frans