Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 236529 - [oocalc] [bn-IN] date input in english automatically gets converted to bengali digits
Summary: [oocalc] [bn-IN] date input in english automatically gets converted to bengal...
Alias: None
Product: Fedora
Classification: Fedora
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-04-16 07:10 UTC by Runa Bhattacharjee
Modified: 2013-03-04 02:21 UTC (History)
2 users (show)

Fixed In Version: 2.2.0-14.8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-05-13 15:57:59 UTC

Attachments (Terms of Use)
screenshot of oocalc bn_IN with date written in english converted to bengali due to the [NatNum1] specification (deleted)
2007-04-16 07:10 UTC, Runa Bhattacharjee
no flags Details

System ID Priority Status Summary Last Updated 76424 None None None Never

Description Runa Bhattacharjee 2007-04-16 07:10:30 UTC
Description of problem:

Date typed in english in the Bengali India locale gets converted to bengali
instead of remaining in english.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. start OpenOffice Calc in Bengali India locale: LANG=bn_IN.UTF-8 oocalc &
2. Check that the bn keyboard is *not* selected as the input method
2. type in a date in the format 12-04-2007  
3. press "Enter" and leave the cell
Actual results:

date typed in english automatically converts to bengali digits

Expected results:
date typed in english should remain in english

Additional info:

The digit conversion happens only for date formats. other numbers typed in
english remain in english.

date typed in bengali remains unchanged after leaving the cell.

This behaviour is due to the [NatNum1] specifications as described here:

I am putting sayamindu dasgupta in the cc for this bug as he had modified the
bn_IN.xml locale file to include this feature.

Comment 1 Runa Bhattacharjee 2007-04-16 07:10:30 UTC
Created attachment 152669 [details]
screenshot of oocalc bn_IN with date written in english converted to bengali due to the [NatNum1] specification

Comment 2 Caolan McNamara 2007-04-16 07:42:14 UTC
The default date format is used to display automatically detected dates in calc,
it will not matter what language-specific digits they are entered with. If they
are entered as bengali or english they are both then displayed in the default
format. So if the default format is changed to not have [NatNum1] then they will
all be displayed in english digits. 

So "data typed in english should remain in english" and "data typed in bengali
remains unchanged" is the current situation, changing the default for bengali to
not have NatNum1 will result in "data typed in english remains unchanged" and
"data typed in bengali should remain in bengali". You *cannot* retain dates
typed in bengali digits in bengali format, and those typed in english in english
format. A decision needs to be taken as to what is the better default one to use. 

But it is the case that or_IN, hi_IN, ml_IN etc don't have a [NatNum1] as their
default date format. Perhaps there is sufficiently similar reasoning for the
decision for those languages that might influence the bn_IN/bn_BD .xmls

Comment 3 Jamil Ahmed 2007-04-18 04:58:01 UTC
I think we can remove the [NatNum1] tag from Bengali locale files. It seems
bn_BD.xml is using bn_IN.xml's <LC_FORMAT>, so the patch is needed for bn_IN.xml

Hope Sayamindu will submit a patch in upstream.

Comment 4 Runa Bhattacharjee 2007-04-18 13:03:00 UTC
Issue submitted upstream:

Comment 5 Caolan McNamara 2007-05-03 19:30:45 UTC
semi-consensus is good enough for me, remove of NatNum1 checked into devel, will
be in >= openoffice_org-2.2.0-14.7

Note You need to log in before you can comment on or make changes to this bug.