feat: export locale_display_pattern

[aergonaut]

What are you trying to accomplish?

While CLDR contains translations of language names for simple locales in the <languages> element, complex locales, such as a locale with a region, may not always have a specific translation in every language. For example, pt-BR has a specific translation in English to "Brazilian Portuguese", but there is no specific translation for that locale in German.

When a complex locale has no specific translation, CLDR specifies that we should use the patterns in <localeDisplayPattern> to construct a display name out of the parts. The patterns are largely the same for most locales, but there are some slight differences, especially in choice of punctuation characters (half- vs full-width) for Asian languages, and use of spaces, so it's necessary to have separate patterns for each locale.

ruby-cldr doesn't currently export the contents of <localeDisplayPattern>, so projects cannot use ruby-cldr to consume these patterns through this library. At my team at Binti, we had to use cldr-json directly to get access to these patterns. I'd like to add support to export these patterns, so projects could use ruby-cldr instead.

...

What approach did you choose and why?

The approach in this PR is based on Cldr::Export::Data::Languages exporter.

It generates a locale_display_pattern.yml file with contents like the following:

---
de:
  locale_display_pattern:
    locale_key_type_pattern: "{0}: {1}"
    locale_pattern: "{0} ({1})"
    locale_separator: "{0}, {1}"

The keys are just the snake_case versions of the element names from CLDR.

...

What should reviewers focus on?

I think this is pretty straightforward, from a code perspective, but if it would be better to put this data in an existing file instead of a new one, I'm happy to change.

...

The impact of these changes

1 extra files per locale.

...

Testing

I made one test, to verify that the exporter creates the structure I expect for a given locale. If there's more testing that would be beneficial, I'm happy to add it.

...

Checklist

• I have added a CHANGELOG entry for this change (or determined that it isn't needed)

[movermeyer]

Thank you!