This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User language is ignored when viewing translations in a table #11546
Comments
I can't seem to reproduce this neither on 9nnJdJIbaz.mp4Not 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. |
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? |
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.
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 qqiZ2SknUJ.mp4
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. |
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.mp4Took a second look and it seems like your languages table uses My current running theory would be somehow there's something funky with your translation/language relation thus it is failing the logic here:
and since the Left Hand Side with the Would you mind taking a schema snapshot and share it here? Feel free to use the following template since GH doesn't allow
|
@azrikahar sorry i think my db is private. Can I email you personally? |
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 |
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 ;) |
@azrikahar, you were right! 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: |
Thanks for confirming!
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:
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.
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:
so that for your use case, users can add an additional field to indicate |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Preflight Checklist
Describe the Bug
See steps to reproduce
To Reproduce
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
The text was updated successfully, but these errors were encountered: