• when using the Language Repository I get an unknown language when calling get('en')
• also looping threw them there is no English whatsoever

What is up with that?

As outlined in #80 , CLDR supports currencyGroup and currencyDecimal for de-AT and fr-CH.

This PR adds support for these symbols by extracting the two relevant snippets in FormatterTrait::localizeNumber() and FormatterTrait::parseNumber() into two methods which are then overridden in CurrencyFormatter.

I've also added tests for the two supported locales for both currencies (to ensure it's working) and numbers (to ensure it only affects currencies).

Thank you for this package, I'm happily using it in a few projects!

Let me know if you'd like me to make any changes.

• Walloon (official iso 'wa' code)
• Taiwanese (or Taiyu)
• Montenegrin (official iso 'cnr')

We make some translations in and to these languages. Could you please add them so we can add them to our website? Or how can we add them ourselves?

Thank you

In catalan, gallego or euskera cultures, we expect the same number format as in spanish es_ES culture, ie:

spanish (es or es_ES): 12,5 € euskera (eu or eu_ES): 12,5 € gallego (gl or gl_ES): 12,5 €

Hello,

I'm looking into using this library for a project in Canada and as such need support for Inuktitut (iu) (which is an official language in the territory of Nunavut). I notice that Inuktitut does not appear in the generated resources, even though it is not one of the $ignoredLocales: https://github.com/commerceguys/intl/blob/90b4f75c4917927a1960c0dcaa002a91ab97f5d5/scripts/generate_base.php#L31-L57

I appreciate the rationale behind #79 but I'm wondering:

1. Why it's not included in the library even though it's not explicitly ignored.
2. If this language could be included in the library, as there are regulatory requirements for its support in Nunavut which our application must meet.

Thanks in advance!

When I submitted #82 , I noticed Travis wasn't testing against PHP 7.4. This PR also lists PHP 7.4 (current stable) as test targets for Travis.

Reason why I created a separate PR is to address potential PHP 7.4 failures separately from the new features in my other PR. I hope that's oaky!

Every single number formatter out there (intl, number_format, Java's DecimalFormatter, the Ruby on Rails helper) also rounds. I've always found it bizarre (showing a value should not modify it), but silently truncating (like we do now) isn't ideal either.

The generally expected rounding modes are: ceiling, floor, up, down, half up, half down, half even (default in intl/icu), half odd. We can support the last four with round(). The first two will be tricky because ceil() and floor() have floating point bugs (which round() doesn't). Rounding down is truncating. Rounding up would need special code.

Maybe we can get away with supporting only the round() ones?

This line of code https://github.com/commerceguys/intl/blob/0fc176165f45d9f3dd9af50a05293c3fa99e4691/src/Formatter/CurrencyFormatter.php#L105 and also https://github.com/commerceguys/intl/blob/0fc176165f45d9f3dd9af50a05293c3fa99e4691/src/Formatter/CurrencyFormatter.php#L108 makes no sense because in defaultOptions those array items are already set, so if your options array doesn't contain the minimum_fraction_digits or/and maximum_fraction_digits they will never be taken from the Currency config with the method getFractionDigits().

This causes the problems like this:

1. Currency is EUR
2. Currency fractionDigits is 2 (set in yml file, talking here about Drupal 8 implementation).
3. In price formatter no minimum or maximum fraction digits is set, so the format method in CurrencyFormatter uses the defaultOptions instead, they have as values: null, but still isset() returns true in lines 105 and 108.
4. Formatted price with number 5.123123 is shown like 5.123123 instead of 5.12 .

Proposed solution:

• replace !isset($options['minimum_fraction_digits'])) to empty($options['minimum_fraction_digits']))
• replace !isset($options['maximum_fraction_digits'])) to empty($options['maximum_fraction_digits']))

This way null value will force the method to get the settings from the Currency itself.

Pull request link: https://github.com/commerceguys/intl/pull/77

One of the examples in the readme makes no sense.

How can 1234.99 suddenly equal 123,456.99?

echo $numberFormatter->format('1234.99'); // 123,456.99

I've noticed that NumberFormatter underwent some changes from 0.* tot 1.*. More specifically the percent style got some breaking changes. I'm just curious if the following ones are intended.

// version 0.*
$formatter->format(75, ['style' => 'percent']); // 75%

// version 1.*
$formatter->format(75, ['style' => 'percent']); // 7500%

// version 0.*
$formatter->format(0.75, ['style' => 'percent']); // 0.75%

// version 1.*
$formatter->format(0.75, ['style' => 'percent']); // Exception (floats cannot be passed)
$formatter->format('0.75', ['style' => 'percent']); // 75%

Thanks for your great library!

The currency codes in base.json for CN, VG and ZA are incorrect due to the array ordering of the CLDR data. (See currencyData.json#L979, #L3221, and #L3348.) CN has CNX instead of CNY, VG has GBP instead of USD and ZA has ZAL instead of ZAR. These are all historic or non-tender currencies.

In most countries in the list, the current currency is the last in the array, and in generate.php#L78 you are using key(end($currencyData['region'][$countryCode])) to retrieve it. These three countries are differently sorted for some reason, and the current currency is not the last in the array.

Rather than rely on the sorting, which could be arbitrary (although it only has these 3 exceptions at the moment), could you use the _from, _to and _tender values to filter the currency array before returning the last key?

Here is a messy example that I made quickly to identify what was wrong with these three countries:

// Determine the current currency for this country.
if (isset($currencyData['region'][$countryCode])) {

    $currencyCandidates = $currencyData['region'][$countryCode];
    $currencyCandidates = array_filter($currencyData['region'][$countryCode], function($currency) {

        $currency = end($currency);

        if (!isset($currency['_tender']) || $currency['_tender'] !== 'false') {
            $active = isset($currency['_to']) ? new DateTime <= new DateTime($currency['_to']) : true;
            $active = $active && (isset($currency['_from']) ? new DateTime >= new DateTime($currency['_from']) : true);

            return $active;
        }

    });

    if (!empty($currencyCandidates)) {
        $currentCurrency = key(end($currencyCandidates));
    }
    else {
        $currentCurrency = null;
    }

    $baseData[$countryCode]['currency_code'] = $currentCurrency;
}

Our number format for Farsi ("fa") puts the currency symbol before the amount.

However, PHP's native NumberFormatter varies the symbol location based on the currency:

$formatter = new \NumberFormatter('fa', \NumberFormatter::CURRENCY);
echo $formatter->formatCurrency('645000', 'USD'); // Symbol before the amount
echo $formatter->formatCurrency('645000', 'IRR'); // Symbol after the amount

This could be related to #65, where our logic is too simplistic.

As discussed in https://www.drupal.org/project/commerce/issues/2936294, trim() only works for ASCII and does not work on multibyte utf8 characters. Let's use a preg_replace() instead.

We currently rely on the pattern to give us the complete layout of the final number. But CLDR has additional rules that say when a space should be inserted around a currency symbol/code, which look like this:

"currencySpacing": {
            "beforeCurrency": {
              "currencyMatch": "[:^S:]",
              "surroundingMatch": "[:digit:]",
              "insertBetween": " "
            },
            "afterCurrency": {
              "currencyMatch": "[:^S:]",
              "surroundingMatch": "[:digit:]",
              "insertBetween": " "
            }
          },

Yes, that's quite confusing, which is why I missed it previously.

Looks like this is a good opportunity to check how our formatting logic compares with the ICU4J one.

Relevant links: https://github.com/angular/angular/issues/20708 https://github.com/andyearnshaw/Intl.js/issues/221

Show an example that would have helped me out. This examples shows the conversion of a number from english to french and highlights how a number should be parsed in it's source language before formatting in the target language.

First of all, thanks for all the hard work put into this, really useful for myself and my team. This is not really an issue report but more of a question.

Do you guys have any estimation/plans regarding introducing date formats support? Thanks