Issue 53498 - Support for Indian and Bhutanese numbering systems, grouping not in thousands.
Support for Indian and Bhutanese numbering systems, grouping not in thousands.
Status: CLOSED FIXED
Product: Internationalization
Classification: Code
Component: i18npool
OOo 2.0
All All
: P3 trivial (vote)
: ---
Assigned To: oc
issues@l10n
:
: 54857 82848 (view as issue list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-18 14:37 UTC by lists
Modified: 2013-08-07 15:02 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation on: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description lists 2005-08-18 14:37:17 UTC
In India, the concept of lakh (100,000), crore (10,000,000) are the most normal
for numbering (and not one million). They group the number differently for
representation, following this scheme. One hundred thousand is written:

1,00,000

One million is 10,00,000

Ten million is 1,00,00,000

One thousand million is 1,00,00,00,000

One european billion is 10,00,00,00,00,000.

The first three characters starting from the right are grouped, and then numbers
are grouped two by two add infinity.

In CLDR this type of format is represented as #,##,###.## (or whatever number of
decimals).

The format would be an interesting addition to OOo, allowing it to represent
numbers as they are used in India and other countries, and allowing
compatibility with CLDR.
Comment 1 ooo 2005-08-18 16:37:34 UTC
Accepted. Would be quite some changes in the number formatter though. Luckily
enough I already prepared rtl_math_doubleToString() respectively its wrapper
::rtl::math::doubleToString() to be flexible in this regard :-)
Comment 2 ooo 2005-09-20 20:10:11 UTC
*** Issue 54857 has been marked as a duplicate of this issue. ***
Comment 3 erack 2008-01-26 16:16:47 UTC
I'll try to work on this during my spare time.

One question though: does the #,##,### rule apply to all Indian locales, or are
there some exceptions for specific languages even if the locale has IN country?

  Eike
Comment 4 erack 2008-02-16 16:13:41 UTC
In cws locales30:

unotools/inc/unotools/Attic/digitgroupingiterator.hxx  1.1.2.1
unotools/inc/unotools/localedatawrapper.hxx  1.29.48.2
unotools/source/i18n/localedatawrapper.cxx  1.37.48.2
svtools/inc/svtools/zformat.hxx  1.2.244.1
svtools/source/numbers/zforfind.cxx  1.47.168.1
svtools/source/numbers/zforlist.cxx  1.70.126.1
svtools/source/numbers/zformat.cxx  1.74.166.1
svtools/source/numbers/zforscan.cxx  1.47.168.1
svtools/source/numbers/zforscan.hxx  1.22.168.1
svtools/source/numbers/zforscan.hxx  1.22.168.2
svtools/source/numbers/zforscan.cxx  1.47.168.2
svtools/source/numbers/zforfind.cxx  1.47.168.2

Didn't have time for locale data change including new API and such. The *-IN and
*-BT locales are hard coded in unotools/source/i18n/localedatawrapper.cxx method
LocaleDataWrapper::getDigitGroupingImpl()

However, locale data needs not to be changed, LocaleDataWrapper::getNum() and
the like and number formatter do it right as soon as "use group separator" (aka
thousands) is activated. Parsing a #,##,### number in the number formatter
though does still not work, only grouping in thousands is recognized and leads
to numeric result. I think we can live with that for now.
Comment 5 ooo 2008-02-29 12:59:49 UTC
Reassigning to QA for verification.
Comment 6 oc 2008-03-05 09:35:31 UTC
verified in internal build cws_locales30
Comment 7 ooo 2008-07-01 16:33:39 UTC
*** Issue 82848 has been marked as a duplicate of this issue. ***
Comment 8 oc 2008-10-17 14:21:48 UTC
closed because fix available in builds OOO300_m9 and DEV300_m33