sanity-plugin-intl-input: Default Document Missing the `__i18n_lang` Field

Issue

I have a Page schema (_type: "page") that I want to translate with document wide based translation.

When creating a new Page document, the default document (fr) does not have a __i18n_lang field. If I create a translated version (en), the __i18n_lang is present. The fr page document’s _id also does not match the i18n.{base-document-id}.{language} pattern but from what I understand that is normal?

I have to go into the Translations Maintenance and “fix” the “missing the language field” for the __i18n_lang field to appear on the french document. Is it possible to not have to manually add the __i18n_lang field by “fixing” it and have it instead appear when the Page is created?

Thanks

Config (intl-input.json)

{
  "base": "fr",
  "languages": ["fr", "en"],
  "idStructure": "subpath",
  "referenceBehavior": "hard"
}

Versions

sanity: 2.12.2
sanity-plugin-intl-input: 5.2.1

About this issue

Original URL
State: open
Created 3 years ago
Reactions: 2
Comments: 20 (3 by maintainers)

Most upvoted comments

Hi, we tested adding an initialValue callback to the document schema to get around this issue:

initialValue: () => ({
  __i18n_lang: 'en-US',
})

Seems to work for our use case. Do you see any issues with it?

Matbj on Nov 11, 2021

For us it works fine when publishing, but it would be great if they could be added when creating a new document as you don’t always want to publish at once before creating translations. Is this even possible?

heggemsnes on Oct 21, 2021

@SSylvain1989 on the document level

Matbj on May 9, 2022

Hello , i’m having the same issue , where did you put this initialValue please ? @Matbj thanks for your help

SSylvain1989 on May 9, 2022

That’s surprising to me. We’re not getting a _lang field on the translated documents. For us the __i18n_lang field is set on both base and translation.

Matbj on Nov 11, 2021

@chr-ge Also experiencing this issue. We are using GrapQL as detailed here, so the field is i18n_lang instead of __i18n_lang, but the issue is the same. @LiamMartens No custom publish action for us.

nboliver on Jul 22, 2021

Is this documented somewhere? I feel it is quite not intuitive. Is there any way to have this behavior as well for draft documents? Ideally the querying for both draft and published documents should be very similar, for example if building a live preview in a website.

alexbchr on Jul 9, 2021

@chr-ge the language field gets added on publish for the default document. Draft documents won’t contain it immediately

LiamMartens on Jul 9, 2021