<html><head><meta name="qrichtext" content="1" /></head><body style="font-size:11pt;font-family:Monospace">
<p>Chusslove Illich wrote:</p>
<p></p>
<p>>>> [: Chusslove Illich :]</p>
<p>>>> First is, how to tell what an argument is, so that formatter in</p>
<p>>>> KLocalizedString can act accordingly?</p>
<p>>></p>
<p>>> [: Krzysztof Lichota :]</p>
<p>>> If you want it to be extensible by user [...]</p>
<p>> </p>
<p>> Not exactly. We want to provide certain number of formattings for</p>
<p>> frequently occuring kinds of arguments, like paths, etc., so that user</p>
<p>> doesn't have to think what kind of formatting to apply (either tags or</p>
<p>> quotes inside message, or writing own formatting functions, or whatever).</p>
<p>> </p>
<p>> However, one way or the other, user has to specify the semantics:</p>
<p>> </p>
<p>> - with special placeholders: i18n("Path %'1'", pathstr)</p>
<p>> - with overloaded types: i18n("Path %1", QFile(pathstr))</p>
<p>> - with tag-functions: i18n("Path %1", argPath(pathstr))</p>
<p>> </p>
<p>> To me, the third option seems best. I don't like special placeholders for</p>
<p>> the reasons I put up before, </p>
<p></p>
<p>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.</p>
<p></p>
<p>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.</p>
<p></p>
<p>> and for the overloaded types, why should user </p>
<p>> think which type corresponds to desired meaning of the argument string?</p>
<p></p>
<p>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?</p>
<p></p>
<p>> The logic of the third option is exactly same as in markup languages, like</p>
<p>> Docbook.</p>
<p></p>
<p>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.</p>
<p></p>
<p>>> [: Krzysztof Lichota :]</p>
<p>>> If type is defined by user, there is always room for mistakes, forgotten</p>
<p>>> calls, etc. Type should be determined by compiler.</p>
<p></p>
<p>Krzysztof, how do you want to force compiler to warn us about missing subs() in</p>
<p></p>
<p>ki18n("foo %1");</p>
<p></p>
<p>?</p>
<p></p>
<p></p>
<p>> I'd say it is unavoidable that user has to specify the meaning. For</p>
<p>> example, an outside reported message ("Foo reported: %1") could have</p>
<p>> special formatting, and it is certainly going to be just some general</p>
<p>> string type. I guess paths too are frequently just a string.</p>
<p>> </p>
<p>>>> [: Chusslove Illich :]</p>
<p>>>> This is the second problem, how to signal "formatting class" for the</p>
<p>>>> arguments (rich, plain, ...)?</p>
<p>>></p>
<p>>> [: Krzysztof Lichota :]</p>
<p>>> I think it should be solved by passing some KLocalizedStringFormatter</p>
<p>>> class to toString() method.</p>
<p>>> [...]</p>
<p>>> I think creating many Xi18n prefixes will confuse developers and it is</p>
<p>>> not extensible for other formatting types.</p>
<p>> </p>
<p>> Well, compare:</p>
<p>> </p>
<p>> ki18n("Error in %1 at %2:")</p>
<p>> .subsPath(file).subs(lineno).toString(KLocalizedStringFormat::plain);</p>
<p>> </p>
<p>> pi18n("Error in %1 at %2:", argPath(file), lineno);</p>
<p></p>
<p></p>
<p>and compare to:</p>
<p></p>
<p>pi18n("Error in %'1' at %2:", file, lineno);</p>
<p></p>
<p>or:</p>
<p>pi18n("Error in %file1 at %2:", file, lineno);</p>
<p></p>
<p>> </p>
<p>> One has to have in mind the special position of i18n subsystem: it is not</p>
<p>> hot developement area and it is ubiquotous throughout code. For these</p>
<p>> reasons, people anyway need to learn it and will use it frequently (hence</p>
<p>> better the brevity), and we have solid base (like 100k messages) to make</p>
<p>> decisions. Eg. now we see need for rich and plain text, and I don't think</p>
<p>> there will be sudden expansion of other possibilities.</p>
<p></p>
<p>Yes there're not going to be more targets.</p>
<p></p>
<p>> </p>
<p>> On the other hand, the first of the above examples would anyway be there.</p>
<p>> My logic is this: ki18n* functions are all peachy C++, and *i18n*</p>
<p>> templates are lean and mean workhorses for 99% of expected situations.</p>
<p>> </p>
<p>>> I have been playing with similar idea as described above, but for Qt,</p>
<p>>> not KDE. I have modified some widgets to accept only special QtTrString</p>
<p>>> class [...]</p>
<p>> </p>
<p>> So it boils down to programmers being prohibited from using pure Qt</p>
<p>> widgets. Not that I personally have any strong opinion of that, but as far</p>
<p>> as I understood from previous discussions, that was considered an</p>
<p>> unreasonable request :)</p>
<p>> </p>
<p></p>
<p>-- </p>
<p>regards / pozdrawiam,</p>
<p> Jaroslaw Staniek / OpenOffice Polska</p>
<p></p>
<p>Sponsored by OpenOffice Polska to work on</p>
<p>* Kexi & KOffice: http://www.kexi-project.org | http://koffice.org/kexi</p>
<p>* KDE3 & KDE4 Libraries For Developing MS Windows Applications:</p>
<p> http://www.kdelibs.com/wiki</p>
<p>See also:</p>
<p>* Kexi For MS Windows: http://kexi.pl/wiki/index.php/Kexi_for_MS_Windows</p>
<p>* Kexi Support: http://www.kexi-project.org/support.html</p>
</body></html>