i18n issue when translation equals original

[Chusslove Illich]

Huston, we have a problem...

When translation is pulled from a catalog, we need to know which language it
was. This is, for example, in order to format numbers and semantic tags,
according to its language. Gettext calls provide no way of checking whether
they found the translation or returned the original string. Instead, i18n
code currently checks if the translation and original are the same, and if
so, the language of the message is taken as English.

The problem strikes when the original and translation are same, but contain
placeholder for a number or a semantic tag, e.g. for "%1x%2" or
"<filename>%1</filename>: %2". i18n concludes it is an English message, and
uses English formatting. Going through current Swedish translation (well-
complete, near-English) reveals 400 such messages (out of 100.000). Some of
them may not have numbers as arguments, so this is a top limit.

What to do?

Anyone have an idea how to positively determine at runtime whether message
was translated or not? Without ditching gettext calls and making own code to
parse catalogs, that is :)

There is a possibility on the translation side too. With special stuff now
available in i18n, there are a few ways to translate a message differently
than the original in the verbatim sense, but get translation same as
original at runtime. The easiest is to append a dummy Transcript fence, but
don't ponder about this phrase. Simply, e.g. "%1x%2" would become "%1x%2|/|"
in the translation, and after i18n detects at runtime that the message is
translated, the |/| fence is just stripped and nothing else happens. We (as
in I :) could make a little something to Scripty to attach these fences and
put small comments where needed, without otherwise disturbing translators.
Does this make sense?

-- 
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/20070806/4e5c1feb/attachment.sig>