Default Document Missing the __i18n_lang Field

[chr-ge]

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

[LiamMartens]

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

[alexbchr]

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.

[chr-ge]

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

Hey @LiamMartens, thanks for the reply. Even after I publish my document, I still do not get the __i18n_lang field added and the document id remains the same (no i18n prefix).

[LiamMartens]

@chr-ge interesting - do you have a custom publish action in your studio which overrides the one from i18n maybe?

[chr-ge]

@chr-ge interesting - do you have a custom publish action in your studio which overrides the one from i18n maybe?

Yes I do, updating it with the resolver from your package has fixed it. Only thing is I had to do this:

import intlResolver from 'sanity-plugin-intl-input/lib/actions'

const PublishWithi18nAction = intlResolver(props)[0]

to access the publish action and use it. Is there a better way of doing this?

[nboliver]

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

[emilpriverrc]

Hello, Have the same issue. The field __i18n_lang is not added when publishing a document. The user need to use the translation tool and force Sanity to add __i18n_lang.

Using version 5.0.6

[KuulArt]

Hi, I am having the same issue. The default language is not created when publishing documents.

• sanity: 2.17.2
• sanity-plugin-intl-input: 5.2.1

[heggemsnes]

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?

[LiamMartens]

@heggemsnes to be honest I am not sure if that's even possible; would have to look into it ..

[heggemsnes]

Maybe we could plug into some initalValue? Not sure if it applies in this use case.

[frontshift]

@LiamMartens Took me a while to figure out why I was unable to preview draft documents for a given language. Would be really good if this was possible.

If not, the workarounds I can think of right now are

• To immediately unpublish the document after an initial publish.
• To add a status toggle, e.g. isLive to the documents and add this to the Groq query to only return documents with the flag set to false when in preview mode.
  Not ideal but at least you don't have to worry about getting a page cache generated when a user accesses the site a the same time you publish the document.

[Matbj]

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?

[frontshift]

@Matbj Thanks dude, I just started out and didn't know about the initialValue property.
This seems to be working for me. However, the document version for the base language gets the __i18n_lang prop added, whereas the non base language translations have the _lang property. Not sure if I'm missing something here...
I worked around this by querying for both fields, e.g.
*[_type == "post" && (__i18n_lang == "${lang}" || _lang == "${lang}") && slug.current == $slug]

[Matbj]

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.

[SSylvain1989]

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

[Matbj]

@SSylvain1989 on the document level

[SSylvain1989]

@Matbj yes, but which one ?
document-internationalization.json

or

schema.js ?

Thanks again, really appreciate your help

[Matbj]

Those of post, author, category, blockContent that are of type document should have it set.

Here's how we did it:

i18_LANG_FIELD is set to __i18n_lang
and
i18_BASE_LANG is set to en-US

[SSylvain1989]

we don't have the same structure file, maybe i miss something , i will look around , thanks again 👍