The country is rendered in the wrong language when the entity is translatable

It's too late to make a change this big in 8.x-1.x, but it sounds sensible for 2.0.x.

The patch needs a reroll though.

Rerolled the patch in #6 as an MR against 2.x, thanks!

Tests are failing with:

Error: Class "Drupal\Tests\address\Kernel\Formatter\EntityTest" not found

I think that 2.0.x has an extra test case ("AddressDefaultFormatterTest::testUruguayAddress") which also needs to be converted.

Let's try to fix the tests.

bojanz → closed merge request !36

The problem here can be narrowed down. The country is rendered in an unexpected language.

For country and zone fields, the fix is simple, we follow core and use $langcode.
Address fields are a bit more complex, they have their own getLocale() getter, which returns the locale stored by initializeLocale:

  /**
   * Initializes and returns the langcode property for the current field.
   *
   * Some countries use separate address formats for the local language VS
   * other languages. For example, China uses major-to-minor ordering
   * when the address is entered in Chinese, and minor-to-major when the
   * address is entered in other languages.
   * This means that the address must remember which language it was
   * entered in, to ensure consistent formatting later on.
   *
   * - For translatable entities this information comes from the field langcode.
   * - Non-translatable entities have no way to provide this information, since
   *   the field langcode never changes. In this case the field must store
   *   the interface language at the time of address creation.
   * - It is also possible to override the used language via field settings,
   *   in case the language is always known (e.g. a field storing the "english
   *   address" on a chinese article).
   *
   * The langcode property is interpreted by getLocale(), and in case it's NULL,
   * the field langcode is returned instead (indicating a non-multilingual site
   * or a translatable parent entity).
   *
   * @return string|null
   *   The langcode, or NULL if the field langcode should be used instead.
   */
  public function initializeLangcode() {

We are already using getLocale() elsewhere in the formatters, we just forgot to use it when fetching the country list.

Two other problems I noticed:
1) The Italian test is not needed, we can use the existing Taiwan test instead, which has an additional benefit of also ensuring the field order and subdivision names are selected via the right langcode.
2) We need to update the used cache contexts.

So, let's try this.

The last submitted patch, 19: 3144823-19.patch, failed testing. View results →

Manual testing showed $langcode to be preferable to $address->getLocale() for non-translatable entities. Reverting to the original approach, and adding a comment explaining why.

$address->getLocale() and $langcode are the same for translatable entities.
For non-translatable entities $address->getLocale() exists to record the langcode at the time of address creation, so that we can rerender the address the same way (e.g. if it was created in Chinese, when we render, we continue to maintain the major-to-minor field order and the subdivisions in Chinese script). However, if we did the same for countries, then the site admin would be unable to recognize to which country the address belongs to. So we'll maintain old behavior and continue to show the country in the current interface language in that case.

Committed. Thanks to everyone at the European Commission for pushing this fix forward!

Automatically closed - issue fixed for 2 weeks with no activity.