KDE4 proposal: Paths in i18n strings

[Jarosław Staniek]

Chusslove Illich wrote:

>>> [: Chusslove Illich :]
>>> First is, how to tell what an argument is, so that formatter in
>>> KLocalizedString can act accordingly?
>>
>> [: Krzysztof Lichota :]
>> If you want it to be extensible by user [...]
> 
> Not exactly. We want to provide certain number of formattings for
> frequently occuring kinds of arguments, like paths, etc., so that user
> doesn't have to think what kind of formatting to apply (either tags or
> quotes inside message, or writing own formatting functions, or whatever).
> 
> However, one way or the other, user has to specify the semantics:
> 
> - with special placeholders: i18n("Path %'1'", pathstr)
> - with overloaded types: i18n("Path %1", QFile(pathstr))
> - with tag-functions: i18n("Path %1", argPath(pathstr))
> 
> To me, the third option seems best. I don't like special placeholders for
> the reasons I put up before, 

I described you the mening of %'1'. Again, it's about formatting paths and filenames, nothing more. From my experience it COVERS 90% cases when we need to emphasise a portion of message.

BTW, I'd like Krzysztof's idea about formatters, it's just good extension, BUT I am not yet sure about complexity of this API. To show that this extension will be useful, we may need to collect a set of common formats. I wonder that this is against K.I.S.S. idea.

> and for the overloaded types, why should user 
> think which type corresponds to desired meaning of the argument string?

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?

> The logic of the third option is exactly same as in markup languages, like
> Docbook.

I am not sure you can use argPath. It's too simple so can be in conflict with existing code, you need i18nArgPath() prefix at least or so.

>> [: Krzysztof Lichota :]
>> If type is defined by user, there is always room for mistakes, forgotten
>> calls, etc. Type should be determined by compiler.

Krzysztof, how do you want to force compiler to warn us about missing subs() in

ki18n("foo %1");

?


> I'd say it is unavoidable that user has to specify the meaning. For
> example, an outside reported message ("Foo reported: %1") could have
> special formatting, and it is certainly going to be just some general
> string type. I guess paths too are frequently just a string.
> 
>>> [: Chusslove Illich :]
>>> This is the second problem, how to signal "formatting class" for the
>>> arguments (rich, plain, ...)?
>>
>> [: Krzysztof Lichota :]
>> I think it should be solved by passing some KLocalizedStringFormatter
>> class to toString() method.
>> [...]
>> I think creating many Xi18n prefixes will confuse developers and it is
>> not extensible for other formatting types.
> 
> Well, compare:
> 
> ki18n("Error in %1 at %2:")
>      .subsPath(file).subs(lineno).toString(KLocalizedStringFormat::plain);
> 
> pi18n("Error in %1 at %2:", argPath(file), lineno);


and compare to:

pi18n("Error in %'1' at %2:", file, lineno);

or:
pi18n("Error in %file1 at %2:", file, lineno);

> 
> One has to have in mind the special position of i18n subsystem: it is not
> hot developement area and it is ubiquotous throughout code. For these
> reasons, people anyway need to learn it and will use it frequently (hence
> better the brevity), and we have solid base (like 100k messages) to make
> decisions. Eg. now we see need for rich and plain text, and I don't think
> there will be sudden expansion of other possibilities.

Yes there're not going to be more targets.

> 
> On the other hand, the first of the above examples would anyway be there.
> My logic is this: ki18n* functions are all peachy C++, and *i18n*
> templates are lean and mean workhorses for 99% of expected situations.
> 
>> 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 [...]
> 
> So it boils down to programmers being prohibited from using pure Qt
> widgets. Not that I personally have any strong opinion of that, but as far
> as I understood from previous discussions, that was considered an
> unreasonable request :)
> 

-- 
regards / pozdrawiam,
  Jaroslaw Staniek / OpenOffice Polska

Sponsored by OpenOffice Polska to work on
* Kexi & KOffice: http://www.kexi-project.org | http://koffice.org/kexi
* KDE3 & KDE4 Libraries For Developing MS Windows Applications:
                   http://www.kdelibs.com/wiki
See also:
* Kexi For MS Windows: http://kexi.pl/wiki/index.php/Kexi_for_MS_Windows
* Kexi Support:        http://www.kexi-project.org/support.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060704/d7b68762/attachment.htm>