- Issue created by @colorfield
 - Merge request !1chore: use entity language path if it's configured β (Merged) created by colorfield
 Automatically closed - issue fixed for 2 weeks with no activity.
Itβs common to set the language path as a replacement of the language ID, in URL prefixes /admin/config/regional/language/detection/url, so e.g. zh-hans language ID is cn in the URL.
Currently, the @entityLanguage directive always returns the ID. This can lead to issues in some situations:
@entityPath directive, there can be a mismatch between the path prefix and language ID used by some processesA side issue is GraphQL enums. If we want to have a representation of locales with enums, we cannot use dashes.
So values like this cannot be used for enums. Example, for Swiss German:
gsw-bernede-CHAs the @loadEntity directive uses the UrlLanguage data producer when we want to load an entity by path, it already handles the language URL prefixes. So we could use the language path for the @entityLanguage directive, fallback to the ID if it's not configured, and make sure to convert - to _ so it's GraphQL enum friendly.
The downside of doing this dash conversion is that the frontend will have to deal with reverse _ to - in some cases.
Then, we still need to check other methods to load an entity.
Another approach would be to use a GraphQL language type that can hold several values.
This last approach is probably more sustainable but can also lead to extra complexity.
Active
1.0
Code
Automatically closed - issue fixed for 2 weeks with no activity.