KDE4 proposal: Paths in i18n strings

[Krzysztof Lichota]

Chusslove Illich napisał(a):
> We have two distinct problems to address here.
> 
> 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.

If you want it to be extensible by user, you should overload functions,
not methods. For example, user could provide method:
KLocalizedString arg(MyType t);
which would transform his type into localized string.
This way using normal C++ type matching you could extend
KLocalizedString type system. KDE could provide standard functions for
common types:
KLocalizedString arg(KUrl t);
KLocalizedString arg(QDir t);
etc.

> 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.

If type is defined by user, there is always room for mistakes, forgotten
calls, etc. Type should be determined by compiler.

> 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.

I think it should be solved by passing some KLocalizedStringFormatter
class to toString() method. This class would contain methods to print
arguments based on type (or use some overloaded functions for user
defined types). This means KLocalizedString should keep arguments and
their types for later processing.

By default toString() (or rather conversion method for type QString)
could use formatter which prints normal text.

> 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.

I have been playing with similar idea as described above, but for Qt,
not KDE. I have modified some widgets to accept only special QtTrString
class which was container for translated strings. Basically the
conclusion was that any text passed to widget which is shown on screen
must be localizable string, i.e. everything except widget names.
I have played with it for a while and even got it to change dynamically
translations in runtime, but I have abandoned it due to lack of time.
But I still think it is a way to go ;)
You can see the leftovers of the project here:
http://dyntrans.sourceforge.net/screenshots.php
http://dyntrans.sourceforge.net/

> 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"

I think creating many Xi18n prefixes will confuse developers and it is
not extensible for other formatting types.

	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/20060704/90e8e383/attachment.sig>