The locality.name data is missed in PlainFormater

It looks like I'm not the only one who is happy with the patch. What's keeping it from being merged?

I use this patch for 6 year for all projects. Will be nice if it will be merged.

We're still missing a test.

For "Italien" Addresses there is no locality.code. The locality name is just a string in 'locaity'. And what does code in this context mean? I understand "code" for the country is the ISO shortcut. But why would the city name e.g. "Berlin" for a German address be in `locality.code` and not `locality.name` ?

See:

Added only tests per @dww comment that check plain address formatter ,so this should fail.
There are 2 tests: one to check if all address data present in plain formatter output and the other checks if all data is shown when some property is optional and empty (apart from country_code which determines empty field).

Now I apply same tests from #17 with fixes from #9 into one patch.
This should now pass.

For "Italien" Addresses there is no locality.code. The locality name is just a string in 'locaity'. And what does code in this context mean? I understand "code" for the country is the ISO shortcut. But why would the city name e.g. "Berlin" for a German address be in `locality.code` and not `locality.name` ?

The template file that you're modifying tells you this:

 * if a subdivision (dependent_locality, locality, administrative_area) was
 * entered, the array will always have a code. If it's a predefined subdivision,
 * it will also have a name. The code is always preferred.

This is because if a subdivision is predefined, it has two names, "name" which is supposed to be used in the UI when selecting a value, and "code" which is supposed to be shown when rendering an address. Sometimes this "code" matches the "name", sometimes it matches an ISO code, depending on the rules for that country. The use of "code" to mean user-facing label is unfortunate, but we inherited that decision from Google 10 years ago and we can't change it.

We can extend the comment in the template file to explain what I just explained here.

@sickness29
Thank you for illustrating a case in which the current code fails, something I've been asking for since 2019.

However, we already have a AddressPlainFormatterTest in Drupal\Tests\address\Kernel\Formatter, can we add a new test case there instead of introducing an independent test?

Furthermore, the twig file changes don't seem correct, the twig file now looks like this:

  {% if locality.name %}
    {{ locality.name }} <br>
  {% endif %}
  {% if dependent_locality.code %}
    {{ dependent_locality.code }} <br>
  {% endif %}
  {% if locality.code or postal_code or administrative_area.code %}
    {{ locality.code }} {{ postal_code }} {{ administrative_area.code }} <br>
  {% endif %}

So we output the locality, then the dependent_locality, then the locality again?

I still think this patch should not make any changes to the twig file itself, nor should it switch "code" for "name" in the formatter plugin.

Hi @bojanz
I have added changes to Kernel\Formatter\AddressPlainFormatterTest to illustrate the issue in test failure.
When only country and admin area were selected, there is no admin area in output, however it should be as we allow optional values.
I will add this same test with fix as next comment

The issue with output should now be fixed

Fix looks great now. Needs a reroll though, 📌 Usage of content language instead of the language of the interface. Needs work changed the tests.

Committed #21 to 8.x-1.x, changing version to focus on the 2.0.x reroll.

Rerolled.

And committed.

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