Allow overriding user language primary keys used

[iksent]

Preflight Checklist

• I have completed all Troubleshooting Steps.
• I'm on the latest version of Directus.
• There's no other issue that already describes my problem.

Describe the Bug

See steps to reproduce

To Reproduce

1. Create a model with auto-configured translations
2. Set "Use Current User Language" to "Enable" at "Translations" at "Display" tab:
   
3. Create 2 translations:
   
4. Change profile language to something else from English (I choose Russian):
   
5. Go to model items table and see, that there is an "English" default item displayed instead of Russian:
   

Errors Shown

No response

What version of Directus are you using?

9.5.1

What version of Node.js are you using?

14.17.5

What database are you using?

MariaDB

What browser are you using?

Chrome

What operating system are you using?

macOS

How are you deploying Directus?

running locally

[azrikahar]

I can't seem to reproduce this neither on v9.5.0 nor the latest version v9.5.1 (I'd still recommend actually confirming this on the latest version in accordance to the Preflight Checklist in this and future issues 👍):

9nnJdJIbaz.mp4

Not sure what could be happening here, but I'd also recommend trying to replicate this on a fresh Directus instance + fresh DB on your end and see whether it happens or not.

[iksent]

Sorry, we are on the latest 9.5.1, will change it in the description now.

Weird! I just moved my DB to the remote server and the issue is still persists...

Should I send you my database?

[iksent]

Oh! I just found that it displays chaotically:

Can you please try to create more items?

[azrikahar]

Sorry, we are on the latest 9.5.1, will change it in the description now.

Weird! I just moved my DB to the remote server and the issue is still persists...

No worries! Would it be possible for you to test on a fresh instance as a sanity check? But feel free to hold off on this first as I think we should approach this from the following steps first.

Should I send you my database?

That is definitely a great plan, but I do wish to try the following checks first since honestly the possibilities of things outside of user or userStore in Pinia affecting this is pretty unlikely.

Currently the language display grabs the user's language, so it'll be helpful if you can verify the /users/me endpoint upon refresh shows the correct language before/after language switches:

qqiZ2SknUJ.mp4

Oh! I just found that it displays chaotically:

Can you please try to create more items?

Tried to create more items as shown above 👍 Still wondering if this is something purely app side or relates to the returned API result. Perhaps you can try with another browser as well just to rule out any chance of browser-related issues.

[iksent]

1. Yes, /me endpoint returns correct language:

2. Tried Safari (instead of Chrome), same problem:

[iksent]

I've just figured it out, that sort param is set to ID:

And this probably leads to incorrect display:

So try to create RU/DE items firstly (start to filling them first)?

[azrikahar]

I can confirm the returned API does indicate that they are in order of creation, but the Translations display seems to still be working as intended in my case:

7Dlw3hc73X.mp4

---

Took a second look and it seems like your languages table uses languages_code rather than languages_id (auto generated):

My current running theory would be somehow there's something funky with your translation/language relation thus it is failing the logic here:

directus/app/src/displays/translations/translations.vue

Line 103 in f4275b4

props.value.find((val) => val?.[relation.value.field]?.[langPkField] === user.currentUser?.language) ?? item;

and since the Left Hand Side with the langPkField fails, your current display now defaults to the RHS which is the first translation item.

Would you mind taking a schema snapshot and share it here? Feel free to use the following template since GH doesn't allow .yaml file uploads (and I personally feel although zip file works, it's also nice to be able to see the schema at a glance without needing to download + unzip it 😁)

<details>
<summary>Schema Snapshot</summary>

```yaml
# paste your yaml here
```

</details>

[iksent]

@azrikahar sorry i think my db is private. Can I email you personally?

[azrikahar]

No worries! I think we may not need to anymore as I just realized something... I believe what's happening here is because your language codes are en & ru, but your userStore (as we verified before) are returning en-US & ru-RU. Would you be able to verify this, with backup of course, and change your language codes according to the xx-XX format?

[iksent]

Yes, we changed it specially to "en" and "ru" to match our client's locales at Next.js, which is "en" & "ru" by default (and also we don't need to separate en-us from en-gb)

I will try to do it asap and back with a news ;)

[iksent]

@azrikahar, you were right!
This was the problem: changing languages codes to en-US & ru-RU solves the problem.

How can we fix this problem? Is it will be correct to try match languages based on lang prefix "en-" & "ru-"? It will solve my problem, but this is not a 100% universal solution (if such a solution exists).

---

Another interesting issue is that "Code" field editing is allowed in my configs:

But I can't edit it in the UI:

[azrikahar]

Thanks for confirming!

Is it will be correct to try match languages based on lang prefix "en-" & "ru-"?

This does sound like a plausible solution. There is sort of a similar logic applied when we're matching locales from date-fns and fullcalendar:

directus/app/src/utils/get-date-fns-locale/get-date-fns-locale.ts

Line 9 in 0537663

const localesToTry = [lang, lang.split('-')[0], 'en-US'];

directus/app/src/utils/get-fullcalendar-locale/get-fullcalendar-locale.ts

Line 6 in 0537663

const localesToTry = [lang, lang.split('-')[0], 'en-US'];

It will solve my problem, but this is not a 100% universal solution (if such a solution exists).

Technically ya it might be truly universal if we can allow "mappings", such as "abc" equals "en-US", "def" equals "ru-RU", but I think that'd end up being (potentially) confusing & likely doesn't conform to the 80/20 rule.

But I can't edit it in the UI:

It's currently it is not possible to edit primary keys (although IIRC it was briefly discussed before on making it possible).

---

Alternatively, we can make the display item based on "language indicator field OR primary key" by modifying the logic here:

directus/app/src/displays/translations/translations.vue

Line 93 in 0537663

const langPkField = relationPrimaryKeyField.value?.field;

so that for your use case, users can add an additional field to indicate en is mapped to en-US, and you'll use the en-US field as the displayed field.

[rijkvanzanten]

Heya! Thank you for taking the time to submit this request!

It has been over 90 days, and this discussion has not received at least 15 votes from the community. This means that we don't feel like there's enough community interest to warrant further R&D into this topic at this time. 🧊

This request will now be closed to keep our discussions tidy. Please reach out if you have any questions!

For more information, see our Feature Request Process.