Created attachment 33719 [details]
patch to make some changes to support fa_IR locale

Grabbing issue.

Hi Farzaneh,

I'm missing the locale data fa_IR.xml file itself, please attach it separately.

Thanks
  Eike

Before we can add your contribution we need the Joint Copyright Assignment form
(JCA) filled out by you, please see
http://contributing.openoffice.org/programming.html#jca

Created attachment 33943 [details]
I haven't tested it yet, but it seems that these additional (trivial) changes would also be necessary.

Though the changes themselfs are trivial it would mean to add several modules to
a CWS that otherwise wouldn't even have to be touched and add unnecessary
complexity in handling. Especially for changing names in comments this is
superfluous, and module binfilter should not be touched at all without pressing
reasons. I suggest to refrain from renaming the define for these reasons and
live on with LANGUAGE_FARSI instead.

Btw, what aboout the JCA?

  Eike

Created attachment 36301 [details]
fa_IR locale data (fa_IR.xml)

Created attachment 36302 [details]
Patch for marking Persian as a CTL and RTL language (consider the previous patches as deprecated)

And about the JCA:
The company (Sharif FarsiWeb, Inc.) signed it and I emailed it on February 2nd,
but the name is not listed among the approved people and companies here:
http://www.openoffice.org/copyright/copyrightapproved.html
Anything else I should do now?

Hi Farzaneh,

I entered your missing JCA on http://wiki.services.openoffice.org/wiki/Pending_JCAs
If there is anything else you could add, for example whether you sent a fax and
on which date if so, please add to that entry.

Thanks
  Eike

As already mentioned on IRC, the locale data's scientific and percent number
format codes look like they might be problematic and not trigger the desired
functionality in the number formatter. However, Farzaneh says it works fine..
we'll see ;-)

Btw, the bRTL changes to vcl/source/app/settings.cxx and on some application
levels are not needed anymore in recent milestones as of m163, this is now
controlled in i18npool/source/isolang/mslangid.cxx method MsLangId::isRightToLeft()

In CWS locdat204:

scp2/source/ooo/file_ooo.scp  1.158.40.1
setup_native/source/win32/msi-encodinglist.txt  1.12.24.1
i18npool/source/localedata/localedata.cxx  1.42.8.2
i18npool/source/localedata/data/Attic/fa_IR.xml  1.1.2.1
i18npool/source/localedata/data/localedata_others.map  1.11.8.2
i18npool/source/localedata/data/makefile.mk  1.34.6.2

Farzaneh, please note that the percent formats did not work, as
suspected.. the U+066A Arabic Percent Sign is not supported yet, and
therefor the number format was not categorized as a percent format by
the number formatter, and the value displayed was not divided by 100
first. I changed the two format codes to contain the normal '%' percent
sign instead, and also moved it to the end of the format code to be able
to paste such numbers and re-parse them again as numerical context.

For the same reason, the U+2212 Minus Sign not being supported,
I exchanged that in the currency format codes with the normal '-' ASCII
minus.

For these unsupported Unicode characters I created issue 67579.

The scientific format codes using "'x' Extended Arabic-Indic Digits '^'"
didn't work at all, they just displayed the digits of the number
interspersed with those characters of the format code, but were not
recognized as scientific format by the number formatter and the value
was not rescaled. I changed the format codes to the usual
>[NatNum1]0٫00E+000< respectively >[NatNum1]0٫00E+00<,

As the IRR currency has 0 decimals, I changed the currency format codes
containing 2 decimals such that they don't have decimals. Format codes
are duplicated now in the .xml file, but have to be present for
compatibility reasons. The number formatter sorts that out and doesn't
display the duplicated formats.

Currency formats containing a [NatNum1] modifier currently can't be
properly used as a default currency format, see issue 53633. The number
formatter generates a default currency format without the [NatNum1]
modifier instead. The user has to manually apply a [NatNum1] format from
the list if needed.

Btw, please note that bracketed modifiers like [NatNum1] have to be the
very first part of subformat codes, preceding them with other
characters, like it was the case in the percent formats and the negative
subformats of the currency formats does not work, the modifier
characters would then be part of the displayed value. The modifiers are
applied to an entire subformat anyway, so there is no need to position
them right in front of the digit keys.

After all, it seems there is quite some work left to do to fully support
Persian locales with all twists. Also NatNum1 transliteration has to be
implemented for 'fa', and the Persian calendar needs implementation.

Thanks
  Eike

Reassigning to QA.

Created attachment 38044 [details]
testcase specification

Created attachment 38045 [details]
Testdoc

verified in internal build cws_locdat204

.

closed because fix available in OOom180