KDE4 proposal: Paths in i18n strings

Krzysztof Lichota krzysiek at lichota.net
Fri Jul 7 16:09:54 BST 2006


Chusslove Illich napisaƂ(a):
>> 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.
> 
> Well, QFile itself has to get a path string, isn't it so? So our argPath() 
> (or i18nPath() by Frans, a better name I guess) could inside also cast to 
> QFile, and then proceed...

I don't think it solves the main problem I see: if strings are used as
paths you have to parse them. And to parse them you have to know what
format they are in (Unix, Windows, MacOS, etc.). This would certainly
lead to troubles like passing formatted strings (for example:
"C:\tmp\something") into i18n and not getting the right representation
or keeping two separate strings, one with real path and one with
formatted path (which is a big mess). I think the only solution, which
must be enforced, is to use only semantic representation like QFile or QDir.

>> I'd prefer to see Qt adopting this kind of translatable strings
>> for Qt :)
> 
> I agree this would be nice, however I have a feeling that we are already 
> pushing the envelope here, and that even if perfectly reasonable, Qt folks 
> won't jump to overhaul their localization infrastructure in the start of 
> 4.x series.

Certainly they cannot as this is binary and source-incompatible change.
But maybe there will think of it for Qt 5.x :)

	Krzysztof Lichota


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060707/c8bab8aa/attachment.sig>


More information about the kde-core-devel mailing list