Locale in KF5 / Qt5

[Chusslove Illich]

> [: John Layt :]
> [...] settings such as date format, number format, etc for a given country
> and language.

There is a problem in this concept when interaction with translation is
taken into account. Consider the message:

  int volNumFiles;
  ...
  i18n("Number of files on the volume: %1", volNumFiles)

As it is now, the number will be unconditionally formatted according to
chosen locale. But, if this message is not translated to the "language of
that locale", then you will get an English sentence with number formatted
not to English ortography.

There are two problems here.

First is that it depends on the "user culture", or even individual user,
whether current behavior is acceptable. There were two conflicting bug
reports to that:

  https://bugs.kde.org/show_bug.cgi?id=178149
  https://bugs.kde.org/show_bug.cgi?id=188646

The German reporter argued that the current behavior is the proper one:
German-format number in an English sentence. The Arabic reporter, however,
thought that Arabic-format number in an English sentence is ridiculous.

The second problem is that, if one would want to automatically choose locale
for formatting arguments based on the language of translated message, there
is actually no technical link between language and locale. At most, the
locale name is parsed for a language code; the other way around is more
ambiguous. And if the user makes selection of language and locale, any link
is out of the window.

An even more glaring example would be inserting a date, if date names are
pulled from locale rather translated through i18n() calls (as it would be
the case in Qt+CLDR solution, I suppose).

So the question is, can we do anything here?

In the second bug report above, a solution was proposed that the user
explicitly links the used languages to locales. Thus, the German reporter
above would link the English language to a German locale, whereas the Arabic
reporter would link the English language to an English locale (or French,
who knows). This looks clean to me, but may be a bit over the top?
Especially when taking into account that user can tweak locale in details,
so should he be able to tweak all linked locales...

> My proposal for KF5 is to use QLocale and CLDR as the source of the locale
> settings. [...]

Did you perhaps look into the procedure for modifying a CLDR locale
definition? How much friction could be expected there?

I ask this because I made two observations. First is that, upon inspection,
many little details in the CLDR locale for my language are wrong. This means
that, for some reason, the CLDR locale got less attention from meticulous
peple than either KDE or glibc locales. The other observation is that CLDR
mentions Openoffice as one of its users, but in Openoffice all of the locale
details for my language I could check are correct. Taken together, these two
observations give me an ominous feeling; but this is just anecdotal evidence.

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110710/158dab41/attachment.sig>