Open chr-ge opened 3 years ago
@chr-ge the language field gets added on publish for the default document. Draft documents won't contain it immediately
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 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).
@chr-ge interesting - do you have a custom publish action in your studio which overrides the one from i18n maybe?
@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?
@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.
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
Hi, I am having the same issue. The default language is not created when publishing documents.
2.17.2
5.2.1
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 to be honest I am not sure if that's even possible; would have to look into it ..
Maybe we could plug into some initalValue? Not sure if it applies in this use case.
@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
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.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 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]
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.
Hello , i'm having the same issue , where did you put this initialValue please ? @Matbj thanks for your help
@SSylvain1989 on the document level
@Matbj yes, but which one ? document-internationalization.json
or
schema.js ?
Thanks again, really appreciate your help
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
we don't have the same structure file, maybe i miss something , i will look around , thanks again 👍
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 thei18n.{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 thePage
is created?Thanks
Config (intl-input.json)
Versions
2.12.2
5.2.1