JDK-4336841 : Arabic locales do not have \u0660 as zero digit base
  • Type: Bug
  • Component: globalization
  • Sub-Component: translation
  • Affected Version: 1.3.0,6
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2000-05-09
  • Updated: 2007-05-11
  • Resolved: 2007-05-11
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
Name: rlT66838			Date: 05/09/2000


java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)

When formatting numbers for the Arabic locales, the European digits are used
instead of the Arabic digits.  While some Arabic locales might use European
digits as a default this is not the case everyone.  The following code uses
NumberFormat to format a number using the default locale.

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import java.text.*;
import java.util.*;
import java.lang.*;

public class ArabicTest extends JPanel {
    static JFrame frame;

    public ArabicTest() {
	NumberFormat nf = NumberFormat.getInstance();

	JLabel label = new JLabel(nf.format(1234567.89));
	label.setFont(new Font("Lucida Sans", Font.PLAIN, 22));
	add(label);
    }

    public static void main(String s[]) {
	ArabicTest panel = new ArabicTest();
	
	frame = new JFrame("ArabicTest");
	frame.addWindowListener(new WindowAdapter() {
	    public void windowClosing(WindowEvent e) {System.exit(0);}
	});
	frame.getContentPane().add("Center", panel);
	frame.pack();
	frame.setVisible(true);
    }
}


If we ran this as follows:

java -Duser.language=ar -Duser.region=EG ArabicTest

we should get the number formatted using the Arabic digits.  I have tried this
with every Arabic locale and it doesn't work.
(Review ID: 103178) 
======================================================================

Same issue reported by a CAP member:

 
There is an bug for numbers with the arabic locale. The Arab is using
arabic-indic digits. All arabic locales is using the default (english) 
number format because there in no entry "NumberElements" in the
LocaleElements_ar.class. You can verify it with:
 
     java.util.Locale locale = new java.util.Locale("ar");
     //java.util.Locale locale = new java.util.Locale("th", "TH", "TH");
     //java.util.Locale locale = new java.util.Locale("hi", "IN");
     java.text.DecimalFormat df = (java.text.DecimalFormat)java.text.DecimalFormat.getNumberInstance(locale);
     System.out.println(df.format(12345));
 
We have find only 2 Locales with other digits "th_TH_TH" and "hi_IN".
 

###@###.### 2005-04-14 14:50:34 GMT

Comments
EVALUATION A comment from Norbert Lindenberg is: Quote start: Correct, the current fix cannot be put back - you'd first have to find a solution for input text coming from Arabic legacy encodings and for output text going into Arabic legacy encodings. The ISO-8859-6 standard only covers the digits U+0030 - U+0039. To enable real Arabic digits, we'd have to add one-way mappings from the Unicode Arabic digits to the corresponding (but Western) ISO-8859-6 code points. Similar changes would have to happen for other Arabic encodings. For input, DecimalFormat would have to accept Western digits besides the non-Western digits indicated by DecimalFormatSymbols. Quote end. As per above we rely on the implementation above which I think is described in 4337267 and maybe others.
09-01-2006

EVALUATION should add {"NumberElements", new String[] { "\u0660", // decimal separator ",", // group (thousands) separator ";", // list separator "%", // percent sign "0", // native 0 digit "#", // pattern digit "-", // minus sign "E", // exponential "\u2030", // per mille "\u221e", // infinity "\ufffd" // NaN } } in 'LocaleElements_ar.java' ###@###.### 2002-11-22 ###@###.### 2002-11-25 java i18n team is investigating. this bug might be too risky to fix in mantis. We will not change the current NumberFormat implementation to use the Unicode Arabic digits. This is an issue of display vs. data: While many Arabic speakers want to see their numbers displayed using Arabic digits, using the Unicode digits \u0660-\u0669 in the data would cause incompatibilities and is therefore not desirable. Instead of changing the data representation, we're therefore planning to solve the problem using Arabic numeral shaping. See RFE 4337267. ###@###.### 2002-12-03 It turns out that we already use non-ASCII digits for two locales: hi_IN and th_TH_TH. Also, ICU4J and CLDR use the Arabic digits for several Arabic locales. This indicates that the compatibility issue (which was meant as compatibility with other applications) can't be that serious. The correct localization should therefore be decided per locale based on local standards and preferences. ###@###.### 2005-04-14 20:51:09 GMT Let me first correct genereal NumberElements section: {"NumberElements", new String[] { ".", // decimal separator ",", // group (thousands) separator ";", // list separator "%", // percent sign "\u0660", // native 0 digit "#", // pattern digit "-", // minus sign "E", // exponential "\u2030", // per mille "\u221e", // infinity "\ufffd" // NaN } } This may go to the sun.text.resources.FormatData_ar.java. It is now under investigation whether it could be general for all countries using Arabian or must be customized per country. ###@###.### 2005-04-19 08:53:32 GMT Based on the CLDR 1.2 the native zero digit is going to be set folowing: ar: \u0660 ar_AE: inherited ar_BH: inherited ar_DZ: 0 ar_EG: inherited ar_IN: inherited ar_IQ; inherited ar_JO: inherited ar_KW: inherited ar_LB: inherited ar_LY: inherited ar_MA: 0 ar_OM: inherited ar_QA: inherited ar_SA: inherited ar_SD: inherited ar_SY: inherited ar_TN: 0 ar_YE: inherited ******** l10n evaluation template - begin *********** Evaluation : The arabic relevant FormatData resource bundles are going to be change accorging the CLDR 1.2 sccsdiff info (e.g. sccs diffs -r1.30 1.31 Activator_fr.java): ------- FormatData_ar.java ------- 109a110,124 > { "NumberElements", > new String[] { > ".", // decimal separator > ",", // group (thousands) separator > ";", // list separator > "%", // percent sign > "\u0660", // native 0 digit > "#", // pattern digit > "-", // minus sign > "E", // exponential > "\u2030", // per mille > "\u221e", // infinity > "\ufffd" // NaN > } > }, ------- FormatData_ar_DZ.java ------- 33a34,48 > { "NumberElements", > new String[] { > ".", // decimal separator > ",", // group (thousands) separator > ";", // list separator > "%", // percent sign > "0", // native 0 digit > "#", // pattern digit > "-", // minus sign > "E", // exponential > "\u2030", // per mille > "\u221e", // infinity > "\ufffd" // NaN > } > } ------- FormatData_ar_MA.java ------- 33a34,48 > { "NumberElements", > new String[] { > ".", // decimal separator > ",", // group (thousands) separator > ";", // list separator > "%", // percent sign > "0", // native 0 digit > "#", // pattern digit > "-", // minus sign > "E", // exponential > "\u2030", // per mille > "\u221e", // infinity > "\ufffd" // NaN > } > } ------- FormatData_ar_TN.java ------- 33a34,48 > { "NumberElements", > new String[] { > ".", // decimal separator > ",", // group (thousands) separator > ";", // list separator > "%", // percent sign > "0", // native 0 digit > "#", // pattern digit > "-", // minus sign > "E", // exponential > "\u2030", // per mille > "\u221e", // infinity > "\ufffd" // NaN > } > } List file(s) to be delivered : j2se/src/share/classes/sun/text/resources/FormatData_ar.java j2se/src/share/classes/sun/text/resources/FormatData_ar_DZ.java j2se/src/share/classes/sun/text/resources/FormatData_ar_MA.java j2se/src/share/classes/sun/text/resources/FormatData_ar_TN.java Target Build : Additional Info : ******** l10n evaluation template - end*********** ###@###.### 2005-05-04 15:01:05 GMT
04-05-2005

WORK AROUND Name: rlT66838 Date: 05/09/2000 The workaround is to use the setZero method on DecimalFormatSymbols. The following code demonstrates this workaround: import java.awt.*; import java.awt.event.*; import javax.swing.*; import java.text.*; import java.util.*; import java.lang.*; public class ArabicTest extends JPanel { static JFrame frame; public ArabicTest() { NumberFormat nf = NumberFormat.getInstance(); if ((Locale.getDefault().getLanguage() == "ar") && nf instanceof DecimalFormat) { DecimalFormat df = (DecimalFormat)nf; DecimalFormatSymbols dfs = df.getDecimalFormatSymbols(); dfs.setZeroDigit('\u0660'); df.setDecimalFormatSymbols(dfs); } JLabel label = new JLabel(nf.format(1234567.89)); label.setFont(new Font("Lucida Sans", Font.PLAIN, 22)); add(label); } public static void main(String s[]) { ArabicTest panel = new ArabicTest(); frame = new JFrame("ArabicTest"); frame.addWindowListener(new WindowAdapter() { public void windowClosing(WindowEvent e) {System.exit(0);} }); frame.getContentPane().add("Center", panel); frame.pack(); frame.setVisible(true); } } Now, running the same test java -Duser.language=ar ArabicTest will result in the correct output. ======================================================================
11-06-2004