Skip to content
This repository has been archived by the owner on Mar 26, 2024. It is now read-only.

Support for @sanity/document-internationalization #292

Open
sorokin-energi opened this issue Mar 24, 2023 · 1 comment
Open

Support for @sanity/document-internationalization #292

sorokin-energi opened this issue Mar 24, 2023 · 1 comment

Comments

@sorokin-energi
Copy link

Hi,

@sanity/document-internationalization can add __i18n_lang, __i18n_refs and __i18n_base fields to schemas with i18n flag.

But it's also possible to use custom names on both global or schema level:
image

Two options are in my mind

  1. try to support specifically this official plugin
  2. try to support dynamic type extension (for instance with codegen option and something similar to openapi spec syntax)

Like

const type = defineType({
    name: 'myType'
    i18n: true,
    codegen: {
        extend: {
           __i18n_lang: { type: [String] },
           ...
        }  
    } 
})
@ochicf
Copy link
Contributor

ochicf commented Apr 3, 2023

Ideas to handle this in v1:

  • since the sanity config file is read by the package, it would be possible to know whether the document-i18n is in the plugins list
  • from a quick look at the plugin object, I don't think the configuration for the plugin is exposed, so if the plugin is detected a possible behaviour could be:
    • try to read the documentI18n property from the sanity codegen config, and use the fieldNames property set there
    • if the above is not set, generate the default fields (and add a log explaining this fact to the user in case needs to be changed)

Then the generator would add the configured/default field names for schemas with i18n: true.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants