Summary: | Arabic-Indic numeral system support | ||
---|---|---|---|
Product: | [Applications] systemsettings | Reporter: | Zayed Al-Saidi <zayed.alsaidi> |
Component: | kcm_language | Assignee: | Chusslove Illich <caslav.ilic> |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | CC: | caslav.ilic, chahibi, dr.khaled.hosny, finex, jlayt, munzirtaha |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Zayed Al-Saidi
2008-12-19 07:53:38 UTC
> [: Zayed Al-Saidi :]
> The ability to change between these two symbol sets is very important. I ask for an option to choose between these symbols when the Arabic Language is set.
It is important to know why exactly is the ability to change between the two sets important, because possible forms of the solution depend on that. I see two reasons:
1) Because in some Arabic-speaking countries Western Arabic digits are used, and in another Arabic-Indic. In this case, with the recent changes, Arabic translators can set that the numbers in messages are shown in Arabic-Indic when the user has chosen Arabic as language and a certain Arabic-speking country. But then the user has no other control of the format; e.g. cannot choose both Arabic language and that country, and still have Western Arabic digits.
2) Because any Arabic user, no matter what country, may prefer either type of digits. In this case, Arabic translators probably should not force Arabic-Indic format for certain countries, but we should come up with extra settings (to be shown in locale KCM) for users to select digits. This is in general harder to do than the previous: one must define exactly what new options are needed (just the choice of digit set?), design the GUI for them, and possibly figure out how to fit it with current Western-centric number formatting options.
Additionally, the first of these two solutions can govern only numbers in running text ("dead" numbers), in UI messages. For numbers which the user may input ("live" numbers), such as in spinboxes or spreadsheet cells, one would have to implement the second solution regardless.
That is to say, the second solution is anyway necessary, the question is just if the first solution is applicable on its own. If not, Arabic translators should for the moment avoid making use of it, and wait until the second solution is implemented too.
For time being, Arabic translation is done by using Western Arabic digits. I hope we can get the second solution in the kde 4.3. *** Bug 131365 has been marked as a duplicate of this bug. *** *** Bug 79862 has been marked as a duplicate of this bug. *** I've committed what I hope to be a good start toward thouroughly supporting non-Western Arabic numbers (the second solution above) in KDE 4.3: http://reviewboard.kde.org/r/666/ Aside from Arabic-Indic digit set, I've also added Eastern Arabic-Indic and Devenagari. To make Arabic-Indic digits default for an Arab country locale, one needs to go into its kdebase/runtime/l10n/COUNTRY/entry.desktop and add the following two lines: DigitSet=1 MonetaryDigitSet=1 (for completeness, if an interested party later peeks into this bug report: Eastern Arabic-Indic would be =2, Devenagari =3). Please comment if something is obviously out of order. One problem I am aware of right now. Non-Western Arabic digits are presently a locale setting just like any other, meaning that if selected, numbers will appear in that form in every KDE app, regardless if it is translated to Arabic or not. From talk with Youssef Chahibi, I've understood this is not the preferred treatment, that instead in non-translated (i.e. in English) KDE apps, numbers should stick to Western Arabic digits. The question now is: how necessary is to make this so immediately? Because while it could be done via so-so dirty hack, for KDE 4.4 I have in mind a thorough language-sensitivity solution. On the other hand, if necessary, this hack is not hard to implement... Thank you Chusslove for you really good work. For displaying Non-Western Arabic digits in untranslated Apps (i.e English), I think it is not acceptable, imagine that you are write in English using Non-Western Arabic digits (for example: Please give me ٤ apples. I'm sure you will ask yourself what the hell are ٤ ? ) . It is necessary. I propose a solution, just follow the backup language settings. Right now, if the app does not have a translation, it will fall-back to English_XX. Just follow that settings for digit-sets. > [: Zayed Al-Saidi :] > [...] imagine that you are write in English using Non-Western Arabic > digits (for example: Please give me ٤ apples. I'm sure you will ask > yourself what the hell are ٤ ? ) . It is necessary. For me it is also strange to see an English sentence with wrong decimal/ thousand separator, like "Total of 1,234 MB saved" meaning one and 0.234 of a megabyte instead of one thousand and 234 megabytes. But that's what happens everywhere when locale separators are not matching English. And it's even worse than digits, because it's ambiguous. So the planned comprehensive solution... > I propose a solution, just follow the backup language settings. Right now, > if the app does not have a translation, it will fall-back to English_XX. > Just follow that settings for digit-sets. ...would be just this, and amazingly it's rather hard to do :) The problem is we (as in wider than KDE) have no concept of language-dependency in locale settings, so this has to be built up somehow. Anyway, I did add the said hack for digits specifically, such that non- Western Arabic digits will now show up only if they are acceptable in the current language of the application, or even of a particular message (in case a message is not translated in mostly translated application). Now, there is unfortunately one more issue. While testing around, I've noticed that numbers in spinboxes are not at all localized; not only missing Arabic-Indic digits, but completely ignoring all locale settings. Which is, well, because they are handled by Qt rather than by KDE. So this is a deep problem, darn. I try kde4.2.87. and I find this new settings do not apply to the time and date applet and in khtml. Moreover, I choose default Arabic keyboard layout and every number I write display in form of Arabic form instead of Arabic-Indic form (which I select in the language settings). > [: Zayed Al-Saidi :] > I try kde4.2.87. and I find this new settings do not apply to the time and > date applet and in khtml. I've seen that this will happen with dates, but didn't know what should exactly be the result there. For example, in Hebrew calendar numbers in dates are written in a special way (not simple digit-for-digit substitution) even if other numbers in Hebrew are using Western Arabic digits. So, in locales that use them, should Indic Arabic digits apply to dates exactly like to numbers, with one-to-one correspondence to Western Arabic digits? If so, in locale settings we need another digit set selector in "Time and Date" tab... > Moreover, I choose default Arabic keyboard layout and every number I write > display in form of Arabic form instead of Arabic-Indic form (which I > select in the language settings). I'm not sure I understand this -- where do you write exactly? I mean, e.g. in KWrite digits are just characters, whatever the keyboard layout emits when the key is pressed, and have nothing to do with locale settings. It is only in specific KDE number-input fields (sans the problem with raw Qt input widgets mentioned above) that one should be able to write the number with any digit set (regardless of locale settings), but when this number is shown elsewhere, it should follow the locale settings. (In reply to comment #9) > I've seen that this will happen with dates, but didn't know what should > exactly be the result there. For example, in Hebrew calendar numbers in > dates are written in a special way (not simple digit-for-digit substitution) > even if other numbers in Hebrew are using Western Arabic digits. > > So, in locales that use them, should Indic Arabic digits apply to dates > exactly like to numbers, with one-to-one correspondence to Western Arabic > digits? If so, in locale settings we need another digit set selector in > "Time and Date" tab... In Arabic, we write time and date as any number, so if we choose Indic Arabic, the date and time should be written in Indic Arabic. I think the Hebrew calendar is special case. From Wikipedia "The Hebrew numerals are used only in special cases, like when using the Hebrew calendar, or numbering a list (similar to a, b, c, d, etc...). " http://en.wikipedia.org/wiki/Hebrew_numerals I do not know about others language. what about webpages ? > I'm not sure I understand this -- where do you write exactly? I mean, e.g. > in KWrite digits are just characters, whatever the keyboard layout emits > when the key is pressed, and have nothing to do with locale settings. I write that in kwrite. > [: Zayed Al-Saidi :] > In Arabic, we write time and date as any number, so if we choose Indic > Arabic, the date and time should be written in Indic Arabic. [...] Ok, I'll add the digit selector to date section in locale settings. Then if some locale-language needs to have it separate for amounts and dates, it will be possible to choose that too. > I write that in kwrite. Ah, yes, then the number characters which are output on keypress depend solely on the keyboard layout. You mentioned that you've tried with the default Arabic keyboard, which as far as I can see indeed has Western Arabic digits; but there are other variants (selectable in keyboard layout settings) which do have Arabic-Indic digits. I notice that Calendar (in taskbar and in the system settings) does not follow the number set I ought to have fixed taskbar and system settings calendars now. Please do continue reporting places like this, which need to be fixed to apply selected digit set. (With the unfortunate exception of Qt spinboxes, as mentioned above.) Regarding Qt spin-boxes, I see a commint that change them to KIntSpinBox instead of QSpinBox ( Revision 989742) . Will that help ? Can we close this one now? I think we can close this. If I see any position does not follow the digit set, I will report it as new bug. |