KDE4 proposal: Paths in i18n strings
Krzysztof Lichota
krzysiek at lichota.net
Fri Jul 7 15:55:12 BST 2006
Frans Englich napisaĆ(a):
> 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.
Yes, in such case there must be something to add "meaning" to it.
> I wonder what people include in their strings. Perhaps everything can be
> divided into semantical categories.
Console output, application names, URLs. Every bit of additional
information can be used to make presentation more useful and appealing.
URLs can be transformed into links, application names into "Run app"
buttons, etc. :)
>> 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.
Exactly. Including plurals. i18n("%1 files").arg(numFiles) should be
automatically transformed into plural form for different values of
numFiles :)
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/efb722ef/attachment.sig>
More information about the kde-core-devel
mailing list