Custom language codes not supported by getMatchingGlossarie()

The proposed resolution is implemented in the issue fork.

The glossary entities use the available languages provided by the API: https://developers.deepl.com/docs/api-reference/glossaries

In case of having custom language codes on your site, you should also use ISO 639-1 notation.
The correct language code for San Marino - Italian would be it-SM (https://localizely.com/locale-code/it-SM/) and not SM-IT, since the San Marino italian is a subset of the original italian language.

The glossary matching functionality will always take the first two letters based on ISO 639-1 and will use this for its matching logic.

Thanks for your input @steffenr!

I'm aware that it is common to follow the ISO 639-1 notation and it also works fine in most cases, but not in all....

Our current case is a bit different and not the most common. It is a global multilingual website where each country/market have their own area under one global domain. Each country/market has one or more languages and use language codes in the format country-language e.g. sm-it and sm-en for Italian and English languages for San Marino. We have at 75+ languages configured with fallback and other things. We have for example 20+ country specific English languages configured with fallback to one main English language (eu-en).

The glossary matching functionality will always take the first two letters based on ISO 639-1 and will use this for its matching logic.

You could get rid of fixLanguageMappings() completely if the code moved from the local language pairs to the remote language pairs in the job entity, as the remote language pairs will always use the format expected by DeepL and that is stored in DeepL's glossaries.

@beltofte: I just checked the MR and its working fine.
Using the remote language mappings really makes sense in getMatchingGlossaries. I just ask myself "why have i solved it the other way?" ;)

Thanks for your contribution!

Unfortunately we cannot use the same logic in 2.3.x, where the Source/ Target languages are retrieved via the API.
In case of English we would get EN-GB and EN-US.
So we will still need to fix the mapping manually - even if we get use the remote language mappings. But since we are using remote language mappings custom langcodes are working also.

Interesting. I'm quite busy this week and next week, but would be happy to help with testing our big multilingual installation on 2.3.x mid/ultimo February if it is not too late for your rollout plans.

@beltofte: Thanks for helping out.
I planned to release an alpha release mid/ end of february. Right now i'm also busy doing other projects.

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