KDE4 proposal: Paths in i18n strings

[Chusslove Illich]

> [: Jarosław Staniek :]
> I described you the mening of %'1'. Again, it's about formatting paths
> and filenames, nothing more. [...]
>
> Wait, I proposed QFile, KUrl, etc. overloads for a case when developer
> already owns a QFile, KUrl variable. No need to cast QFile(pathstr) (as
> proposed by you not me) in this case. OK now?

Sorry for any misunderstanding. It is simply my observation (wrong?) that 
there may be many cases where one would have path not as QFile etc., and 
would cast just for the output.

But I have nothing against Frans' idea that i18nPath() also receive QFile 
and whatever else related directly.

There is another possible annoyance with just taking QFile without a 
wrapper. Programmer might be unaware that being able to use QFile directly 
is not just a convenience, but produces markup as well. So he might 
*additionally* put markup inside message string. Having wrappers makes 
this mistake less likely.

>> [: Chusslove Illich :]
>> pi18n("Error in %1 at %2:", argPath(file), lineno);
>
> [: Jarosław Staniek :]
> and compare to:
> pi18n("Error in %'1' at %2:", file, lineno);
> or:
> pi18n("Error in %file1 at %2:", file, lineno);

It would really be trouble to go with special placeholders. For example, we 
wanted to move to standard Gettext extractor in order to discard our 
patched Gettext, and the infrastructure needed to hide this from 
translators would be much more demanding.

If, on the other hand, we would just let it out to translators, then first 
we would loose Gettext's qt-format (Gettext knows about it) and checks 
that go with it, and second, there would be quite some errors of 
translators "translating" placeholders -- like file in %file1, or quotes 
to proper quotes.

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060705/8cddc44d/attachment.sig>