Issue 53498

Summary:	Support for Indian and Bhutanese numbering systems, grouping not in thousands.
Product:	Internationalization	Reporter:	lists
Component:	i18npool	Assignee:	oc
Status:	CLOSED FIXED	QA Contact:	issues@l10n <issues>
Severity:	Trivial
Priority:	P3	CC:	issues, khirano, tml
Version:	OOo 2.0
Target Milestone:	---
Hardware:	All
OS:	All
Issue Type:	ENHANCEMENT	Latest Confirmation in:	---
Developer Difficulty:	---

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