Does not support langcode url prefixes more complex than 2 letters (e.g. zh-hans, zh-hant, haw)

I've raised a MR that replaces PathUtility with a new PathPrefixHelper service that does the stronger check for configured languages/countries rather than a general regexp.

It incorporates the work in ✨ Compatibility Drupal 10.3^ Active , mainly so the pipeline passes.

This feature is on the roadmap. See Development Plan on the module page. In general, I thought it would be good to use plugins for the prefix negotiation. I can imagine scenarios where it would make sense to chain the negotiation.

Interesting. I find the module's current approach (i.e. /LANGCODE-COUNTRYCODE/where LANGCODE is configured per language and COUNTRYCODE is configured per country) to be good and sufficient.

(Well, I suppose I found it disorienting that the langcode url prefix used is the one on configured on /admin/config/regional/language/detection/url which doesn't feel like it should be related, but "good enough for the moment", I thought).

I'd be interested to hear more of your thoughts about the scenarios where prefix-mapping would get more complex than that?

Regarding making it pluggable, my first thought is: if someone needed to do prefix negotiation differently, then surely the natural step would be for them to write an alternative Language Negotiation Plugin? Is there value in language_country_negotiation adding an extra plugin-layer further to this? Put another way: what code would be left in LanguageNegotiationLanguageCountryUrl if it deferred logic off to a sub-plugin?

And (still regarding making it pluggable), my second thought is: If the scenarios you imagine are rare, then perhaps the use of a service ("PathPrefixHelper" in the current MR) is a good enough solution? After all, if another module wishes to adjust how prefixes are parsed (but in a way that is pretty-close-to-standard), then they have the option of replacing or decorating language_country_negotiation.path_prefix_helper. (If we code with the expectation that it may be decorated, perhaps the class should be renamed, final modifier taken off, and its methods restructured to make it more useful to do this kind of thing?)

My third thought: The MR removes length/format assumptions of both LANGCODE and COUNTRYCODE which makes them potentially quite flexible. The only other thing I would add is something on the language-country-url configuration form that lists every country/language permutation and allows a custom prefix to be provided for each. This would be fairly simple to implement, and would surely afford maximum necessary flexibility?