KDE4 proposal: Paths in i18n strings

[Chusslove Illich]

We have two distinct problems to address here.

> [: Frans Englich :]
> To make KLocalizedString aware of types like QDir seems to solve the
> problem of paths, but how does one achieve the same improvement for other
> strings? What is it people generally inserting with %N, and what can be
> done for making it consistent?

> [: Jarosław Staniek :]
> For these cases what about something as simple as:  %'N' ? If only
> translators can stand "User '%1' joines", they'd most likely stand
> "User %'1' joined" as well (?)

First is, how to tell what an argument is, so that formatter in 
KLocalizedString can act accordingly?

My first idea would be to overload KLocalizedString::subs method 
generously, as it seems most in C++ spirit. For this, however, every type 
of argument would have to be below KLocalizedString in hierarchy, which is 
pretty damn low, as KLocalizedString is in kdecore.

I don't think marking output by placeholders is the best idea. Even if we 
could hide that from translators, it would still remain something 
out-of-the-world for programmers to learn, and they would have to rely on 
repository infrastructure (what if someone develops for KDE outside of our 
repository?). Outside of code, it is prefferable to have normal Gettext 
operation cycle.

But since using some semantic marking might indeed be most universal, how 
about wrapping arguments themselves? "Tags" would be set of same-prefix 
functions returning wrapper objects under control of KLocalizedString. For 
example:

i18n("Here is path %1 there is URL %2", argPath(myPath), argUrl(myUrl));

where:

KLocalizedString::ArgPath argPath(const QString &path);
KLocalizedString::ArgUrl argUrl(const QString &url);
etc.

and subs methods would be overloaded for these wrappers.

This would also go the way of semantics versus presentation, so it should 
be a familiar and consistent concept.

Looking this way, overloading for particular types might end up being same 
thing, but with unnecessary extra layer of indirection. One would easily 
expect then to find things like:

i18n("Here is path %1 there is URL %2", QFile(myPath), KURL(myUrl));

> [: Jarosław Staniek :]
> Posible problem: we may want to display the mesage with path to a log
> file or std(out|err}. The KLocalizedString class should know it's the
> case, so there may be aditional flag for doing this

This is the second problem, how to signal "formatting class" for the 
arguments (rich, plain, ...)?

The idea to toss KLocalizedString-s around as arguments to constructors, 
and have widgets request proper formatting class, might seem appealing at 
first moment. Eg. KLocalizedString could have extra toString*() methods, 
to signal the formatting class.

But, we have toyed several times with this idea in other contexts, and 
there always pops the same counter-argument: what about pure Qt widgets? 
They will want QString, period. Also, it would not be easy to say for 
unambiguously which constructor arguments should be KLocalizedString and 
which left QString.

So I think we could settle on one default formatting class, and have 
programmers chose others. For example, we can say i18n* calls do rich 
text, and have pi18n* calls for plain text.

i18n("Filename: %1", argPath(fname)); // -> Filename: <b>%1</b>
pi18n("Filename: %1", argPath(fname)); // -> Filename: "%1"

Of course, we would still have extra toString*() methods for ki18n* calls. 
And, for brevity and consistency, also have subs<TAG> methods when ki18n* 
are used:

ki18n("Filename: %1").subsPath(fname).toString();
ki18n("Filename: %1").subsPath(fname).toStringPlain();

***

Hm, this is all turning Docbook/Latex, isn't it? :)

-- 
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/20060703/6474f611/attachment.sig>