When creating a translation, it defaults to English:US instead of the default language in the project settings

[sxsws]

When the project settings default language is set to something other than EN:US, the first translation when making a new translation still defaults to EN:US instead of whatever the project default is.

[azrikahar]

Technically project settings default language was added quite recently via #8196, so let's treat this as a feature request. Just to be sure, you are mentioning the translations interface within an item right? Though we may also need to propagate this elsewhere like collection/field translations or translated strings as well to be really thorough.

[sxsws]

Places I've seen this happen so far: field translation, folder translation (folder in data model) so I'd assume it's all if not most places it's possible to add a translation.

[miagg]

I have the same problem. I'm trying to do the following but without success.

1. Make the translations preview display the default language translation
2. When creating a new translation, choose the default language instead of the first language in the db

Isn't this highlighted option supposed to do all of the above? For me it does not work.

[azrikahar]

Would you mind sharing a schema snapshot so that I can attempt to investigate it better? Thanks!

[miagg]

sure! Thanks for your support.
schema.yaml.zip

[azrikahar]

There is this line, which I figured should've made it work when you enter default language as 2 (especially the val?.[relation.value.field]?.[langPkField] === props.defaultLanguage condition check):

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

Lines 96 to 98 in 06cd118

	let item =
	props.value.find((val) => val?.[relation.value.field]?.[langPkField] === props.defaultLanguage) ??
	props.value[0];

However you are using integer primary key, so in terms of strict equality, it fails, as seen here:

and here's a brief testing on changing it to loose equality instead, and it does work now:

Code_Xqx7JTTVsF.mp4

@rijkvanzanten should we just cast val?.[relation.value.field]?.[langPkField] to string here? There shouldn't be any problem with such change right? Can't think of any off the top of my head 🤔

[miagg]

This is exactly what I thought the problem might be. I was expecting the value to cast to an integer since it's numeric so that strict equality would work by trying entering a raw value of 2 but I didn't have any luck. I can't think of a reason loose equality would cause any harm here also. Thanks for tracking this!

[rijkvanzanten]

@rijkvanzanten should we just cast val?.[relation.value.field]?.[langPkField] to string here? There shouldn't be any problem with such change right? Can't think of any off the top of my head 🤔

Works for me 👍🏻

[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.