Semantic marking for i18n

Mon Apr 23 00:14:19 BST 2007

> [: Olivier Goffart :]
> Anyway, not all i18n call are going to be displayed in place where it is
> possible to have HTML.
> How will i18n cope with that ?

Yes, that was a prime problem. The only automatic solution would be (as Frans 
and Krzysztof were saying in that thread) to proliferate the use of 
KLocalizedStrings throught the UI widgets, replacing QStrings. But, this 
would introduce discrepancy with Qt widgets, not to mention that there may be 
ambiguous situations for automatic format decision, which would, in my 
opinion, result in a mess.

So, that part I would leave to programmers, as it was so far. For example, if 
the message opens with <html> or <qt> tag, then rich formatting is used, 
otherwise plain. Even though Qt is less strict about this (tries to guess 
it's rich text by looking at other tags if <html>/<qt> is missing), it seems 
people were nevertheless remembering to put the <qt> tag.

Some heuristic may also be possible with semantic markings. Eg. if the message 
contains <para> tag, it's quite probably used where rich text is possible. 
And so on.

Krazy checks may also help, assuring that strings at typical UI widget calls 
(eg. at tooltip position) contain <html> tag...

-- 
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/20070423/2266488f/attachment.sig>