Currency patterns and fraction information

[Isaac Jurado]

On Fri, Nov 7, 2014 at 7:07 PM, John Emmons <emmo at us.ibm.com> wrote:
>
> Isaac, the reason is that the currency pattern can more generally
> apply to ANY currency, not just the one that is most commonly used in
> the country.  For example, in the Japanese locale, I have the default
> currency pattern of "¤#,##0.00" which would apply as "€1,234.56" for
> euros, or "¥1,235" for yen.

I understand.  Following Mr. Davis' suggestion, I've been reviewing the
ICU code and I can see how currency data overrides the pattern.  If I
was not mistaken, the bulk of the logic is implemented within the
DecimalFormat class:

  http://source.icu-project.org/repos/icu/icu/tags/release-52-1/source/i18n/decimfmt.cpp

When using the ".setCurrency()" method, the currency pattern is applied,
but then the MaxFractionDigits and MinFractionDigits are overriden by
currency data.  However, when only ".applyPattern()" is used, the
fraction digit bounds are those from the given pattern.

Therefore, currency data can still be programatically overriden by a
call to ".applyPattern()" after calling ".setCurrency()".  This
particular scenario has been trigerring a sort of inconsistency alarm in
my personal reasoning, hence the initial motivation of my question.

In the end, I drew the following conclusions:

  1. By default, currency data completely overrides currency pattern in
     terms of number of decimal/fraction digits (as Mr. Davis wrote).

  2. Nevertheless, libraries still offer ultimate flexibility so a
     pattern can override currency data, and this should be interpreted
     as a feature, not a bug

For the record, my original intention is to patch the Python Babel [1]
package in order to comply with currency data obtained from CLDR.

Thank you both Mr. Emmons and Mr. Davis for your answers.

Kind regards.

[1] http://babel.pocoo.org/

-- 
Isaac Jurado