Version: (using Devel) Installed from: Compiled sources OS: Linux I observe this bug with the latest KDE 4.1.x stable SVN checkout. It was original filed as bug #167915 for Lokalize, but apparently it’s bug in KDE instead: My locale settings are not correctly used for displaying numbers. I have set my regional settings to use a space as a thousand separator, so the number 2389 should be displayed as ‘2 389’ (see attachment). However, in Lokalize, it is displayed as ’2,389’, i.e., with a comma as the thousand separator instead. Again, see attachment (the numbers on the statusbar).
Created attachment 26575 [details] My regional settings
Created attachment 26576 [details] Screenshot from Lokalize
The number format is mandated by the language of the text, i.e. English text English numbers, Norwegian text Norwegian numbers. This is controlled by the two messages in kdelibs4.po with context "number-format:...", and (both) Norwegian POs specify it as "us", whereas, according to your description, it should be "euro2".
OK, I’ll fix that. But have I understand things correctly in that this means that the «euro2» setting now will override what the user has set as his/her regional settings (so that these settings will actually never be used)? In that case, I still think this bug report is perfectly valid.
> [: Karl Ove Hufthammer :] > But have I understand things correctly in that this means that the «euro2» setting now will override what the user has set as his/her regional settings (so that these settings will actually never be used)? Right. The exception are "live" numbers, i.e. those which can be expected to be copied around (tables, calculator display, etc.). These always follow System Settings -- providing, of course, that the programmer didn't forget to use correct formatting functions. > In that case, I still think this bug report is perfectly valid. The assumption is that in each language there is a standard way to write numbers, i.e. that there is no reason to provide users a way to choose orthographically incorrect number representation in running text. Probably not exactly on the level of allowing personal preference of inverted question or exclamation sign, but along those lines. E.g. I find it rather strange to have my language's number format in English text, or vice-versa (well, not so much vice-versa :) On the other hand, if this proves awkward for some language, for whatever reason, there are provisions to easily implement strict adherence to System Settings; translator would just have to set those messages in kdelibs4.po to, say, "system". Only that noone requested it yet, so I was lazy to do it. Should I? Just say the word :)
> On the other hand, if this proves awkward for some language, for whatever > reason, there are provisions to easily implement strict adherence to System > Settings; translator would just have to set those messages in kdelibs4.po to, > say, "system". Only that noone requested it yet, so I was lazy to do it. Should > I? Just say the word :) Yes, please do. (Although I must admit that I *am* partially convinced by your answer that it’s most sensible to let the number format follow the language of the text, so I just *might* continue to use ‘euro2’ in my translations even if ‘system’ was implemented …) Does it really work that way, BTW? Are untranslated strings displayed using the US English settings while translated strings are displayed using the settings in kdelibs4.po? (The reason I ask, is that in other applications that use gettext, there is really no natural way of knowing if the string returned by i18n() is the original string or a translation (without comparing them, which wouldn’t work if the original is equal to the translation).)
> [: Karl Ove Hufthammer :] > Yes, please do. Done. Both for trunk and 4.1 branch. Though I wouldn't close this bug just yet, until you can confirm that it works as you would expect. > Does it really work that way, BTW? Are untranslated strings displayed using the US English settings while translated strings are displayed using the settings in kdelibs4.po? Precisely. That is, unless you now select "system" in kdelibs4.po, when any number will be according to system settings. > (The reason I ask, is that in other applications that use gettext, there is really no natural way of knowing if the string returned by i18n() is the original string or a translation (without comparing them, which wouldn’t work if the original is equal to the translation).) At one point I got upset precisely because of that, i.e. how to know which language did the translation came from. Turned out that raw gettext calls will return the same const char* pointer given to them if there was no translation, as opposed to different pointer if the translation was there, but same string-wise. Since i18n() uses these raw calls under the hood, by this it can check the language.
Fixed by this commit to ki18n: https://phabricator.kde.org/R249:b0dbb285bd2119fe980a714f7d01ec140f2b8138