KDE4 proposal: Paths in i18n strings

[Chusslove Illich]

>> [: Chusslove Illich :]
>> I don't think marking output by placeholders is the best idea. [...]
>> would have to rely on repository infrastructure [...] Outside of code,
>> it is prefferable to have normal Gettext operation cycle.
>
> [: Jarosław Staniek :]
> 1. We depend on kde-xgettext anyway, I think it's true for projects
> outside of KDE SVN as well.

This will be no longer in KDE 4 -- we will use run-of-the-mill Gettext 
0.15.x, as it will have all that we need.

> 2. %N is not recogized by gettext as something special, is it?

Gettext will recognize it as qt-format, and I assume do some checks based 
on that, as it does for c-format. Current Gettext has this support a bit 
buggy though, as it relies on specification of qt-3.0.something, so 
someone should update that *sweating*

The only problem is %n placeholder (I mean verbatim, for plural messages), 
which is not of Qt world. But I am of the opinion that %n is just a dead 
weight now, so perhaps we should break the habit and throw it out -- than 
we would have pure qt-format strings.

> If my points are true, I still belive %'N' is usable, short, well
> defined, and makes the source code cleaner, and extendable (avoids BIC
> problems if we add another special case one day).

Regardles of the points above, there are other problems with %'N'.

One, although perhaps not too important, is implementation -- parsing of 
that could get ugly.

Then there are mistyped messages. One would think that programmers are 
going to have that fixed, but during conversion of KDE modules to new 
system, I found quite some messages with wrong placeholders and missing 
arguments. They were always for some rare conditions, that don't pop up 
during testing. So I really like to capture that stuff at compile-time 
when possible.

If I understood correctly, %'N' means "use markup like <b></b>, or quotes, 
depending on formatting class". How would then we have different markup 
for different semantics -- paths, URLs, outside messages, literals, etc.? 
Except of course using yet more special placeholder formats. So there is 
markup, one way or the other, so I'd say its better to apply it outside, 
around arguments, consistently and at compiler's watch.

As for BIC, it's not like we're dealing with something new here -- we know 
what kind of arguments were used so far, so they will be here to stay. And 
we can add new wrappers as they are determined to be really needed. It's 
like with tags in Docbook, one can afford not to throw out deprecated ones 
for quite some time.

> Moreover the whole gettext-based i18n is a magic after all...

In the sense of...? :)

-- 
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/20060704/1ee7a90c/attachment.sig>