Maybe a simple model transformer could do the trick.

Unfortunately we rely on ICU for our localization data, and ICU does not provide the 3-letter codes. Do you know of any source that maps 2-letter codes to 3-letter codes?

@bschussek CLDR iirc.

Indeed, CLDR provides a mapping from alpha-2 to alpha-3 in the file codeMappings.json contained in json.zip. I suggest to make the following changes to Intl:

Add the constants NUMERIC, ALPHA2 and ALPHA3 to Intl:

class Intl
{
    const NUMERIC = 0;
    const ALPHA2 = 1;
    const ALPHA3 = 2;
}

Add the method getCountryCodes() to RegionBundleInterface with a $format parameter:

public function getCountryCodes($format = Intl::ALPHA2);

Add the parameter $indexBy to getCountryNames() of that same interface:

public function getCountryNames($locale = null, $indexBy = Intl::ALPHA2);

Change RegionBundleTransformationRule::beforeCompile() to include the numeric and alpha2 codes in the text resource bundles. This is probably the most "interesting" task :)

In the same turn as implementing this, it would be nice to also add corresponding getLocales(), getCurrencyCodes() and getLanguageCodes() methods to the other interfaces.

But, if you want to use ICU for country list, and just map alpha-2 to alpha-3 codes from CLDR, I have bad news for you. ICU and CLDR list of countries do not match.

Why doesn't it match?

@hhamon Not sure. It just does not get updated in sync. Some countries like South Sudan, Kosovo...are not recognized widely, and when new country becomes independent for example, ICU and CLDR will not update at the same time. They actually never have identical list of countries. Not sure why.

Ok! I was able to get a complete list of countries with ISO2 and ISO3 code.

Great. May be that CLDR is more complete then ICU.

AFAIK ICU (a library) relies on CLDR (data) - see the ICU Downloads page for example, where they list the included CLDR data for each release.

This is being worked on in #9206.

@hhamon did you find a workaround for this problem ?

@greg0ire In fact the alpha-3 codes sneaked in in #11920. You can access them with

Intl::getLanguageBundle()->getAlpha3Code('en');

Be prepared to adapt that code though, as this is not officially supported yet. This API will likely change in 2.7.

Nice. I'm stuck with an LTS though, so I'm no going to use it rightaway, but I'll keep that in mind for future projects.

@greg0ire This was in fact merged into 2.3.

Oh, great, I'll have a look then!

I'm running into this issue (SF 2.5) I can see getAlpha3Code() but we are talking about language here aren't we ?
As the issue was about the countries, should we simply lowercase the country Alpha2 passed to getAlpha3Code() ?

It is true, this issue is related to countries and the suggested solution/workaround is for languages. As far as I know the alpha3 code for languages is defined in the ISO 639b standard, not the ISO 3166. So the issue is still open to me, and a bit confusing what the alpha2toalpha3 actually does.
As a side note there is a need to translate in both directions, so alpha2 to alpha3 is not enough, and probably "translating" is not the right approach, we need to work with each list separately for consistency.

@davide-romanini not true, it's in ISO 3166-1.

@Glideh no, we're not talking about language, we're talking about territories.

Since this issue was opened the json linked by @webmozart is gone. CLDR is now on release 29, and the tools to generate the JSON are currently broke, afaik. However, you can find the 3-alpha, to 2-alpha character mapping in the file: ./common/supplemental/supplementalMetadata.xml. The documentation for that file seems to be incomplete, but it's clearly there in there..

      <territoryAlias type="AAA" replacement="AA" reason="overlong"/> <!-- null -->
      <territoryAlias type="ASC" replacement="AC" reason="overlong"/> <!-- Ascension Island -->
      <territoryAlias type="AND" replacement="AD" reason="overlong"/> <!-- Andorra -->
      <territoryAlias type="ARE" replacement="AE" reason="overlong"/> <!-- United Arab Emirates -->
      <territoryAlias type="AFG" replacement="AF" reason="overlong"/> <!-- Afghanistan -->
      <territoryAlias type="ATG" replacement="AG" reason="overlong"/> <!-- Antigua & Barbuda -->
      <territoryAlias type="AIA" replacement="AI" reason="overlong"/> <!-- Anguilla -->
      <territoryAlias type="ALB" replacement="AL" reason="overlong"/> <!-- Albania -->
      <territoryAlias type="ARM" replacement="AM" reason="overlong"/> <!-- Armenia -->
      <territoryAlias type="ANT" replacement="CW SX BQ" reason="overlong"/> <!-- null -->
      <territoryAlias type="AGO" replacement="AO" reason="overlong"/> <!-- Angola -->
      <territoryAlias type="ATA" replacement="AQ" reason="overlong"/> <!-- Antarctica -->
      <territoryAlias type="ARG" replacement="AR" reason="overlong"/> <!-- Argentina -->
      <territoryAlias type="ASM" replacement="AS" reason="overlong"/> <!-- American Samoa -->
      <territoryAlias type="AUT" replacement="AT" reason="overlong"/> <!-- Austria -->
      <territoryAlias type="AUS" replacement="AU" reason="overlong"/> <!-- Australia -->
      <territoryAlias type="ABW" replacement="AW" reason="overlong"/> <!-- Aruba -->
      <territoryAlias type="ALA" replacement="AX" reason="overlong"/> <!-- Åland Islands -->
      <territoryAlias type="AZE" replacement="AZ" reason="overlong"/> <!-- Azerbaijan -->
      <territoryAlias type="BIH" replacement="BA" reason="overlong"/> <!-- Bosnia & Herzegovina -->

The comment may also be useful if the library you're using to access CLDR doesn't support this xml,

        <!-- 3-letter ISO code values -->
        <!-- start of data generated with CountItems tool per http://sites.google.com/site/cldr/development/updating-codes/update-languagescriptregion-subtags -->

@EvanCarroll as I said and you confirmed again, this issue is concerned about country codes, and specifically 3-letter country codes, not language codes. So the suggested workaround:

  Intl::getLanguageBundle()->getAlpha3Code('en');

seems to solve a completely different problem (and I think it just don't work anymore on latest Intl). So the point is: this issue has been closed, but the problem has not been solved. Maybe is a "won't fix"? At least people coming here should be informed that the feature is not available..