Localization on Fields vs Documents

[good-idea]

Just for discussion:

Sanity handles localization on a field level. Prime seems to be set up to do this on a document level.

I suppose there's "right" way to do this because use cases will differ, for instance:

On a travel website, we might want to display a different homepage based on the viewer's locale. This page would be a document with fields like:

• Cover Photo
• Travel Recommendations
• Customer testimonials

British users will see recommendations to (for example) the Caribbean, while Cuban users will see recommendations to New York or London.

Localization on documents would make the most sense here.

On the other hand, on a blog/journal website, an Article document might look like:

• Title
• Author
• Body
• Further Reading
  • Link
  • Description

Here, the Further Reading field would be an array of entries. The article is going to have the same "further reading" no matter what the translation is. But, the Spanish translation would need to have a description in Spanish.

If localization were only on a document level, users of the CMS would need to manually add the Further Reading entries for each translation - which could lead to a lot of extra work and inconsistency.

Is this something you'd be interested in supporting? I guess it brings up a lot of questions, and both technical and UX issues..

[mpartipilo]

We were having this discussion over at issue #43

Another headless CMS doing localized fields quite well is Cockpit.

[birkir]

Could you show me how the query would look like? I am having a hard time figuring out what it would work like, could your usecase be solved by adding * support?

query {
  Article(id:"foo") {
    title
    author {
      name
    }
    body
    furtherReading(lang:"*") {
      link
      description 
    }
  }
}

Or is the further reading a group field but not an document field?

If it's a group field I understand the scenario.

[good-idea]

Sorry I missed the other issue! I'll answer your question about queries here but we can move all discussion over there after.

I was imagining the furtherReading field to be a group. Overall, my concerns were more about the capabilities and UI of the frontend of the CMS.

As far as queries go, I imagine the most common use case would be setting a language/locale on the first scalar, for instance:

query {
  Article(id:"foo", lang: "es") {
	title
  }
}

Other nice-to-haves:

• Get a list of available translations for a field: title_translations -> ['es', 'en', 'de']

• Get a specific translation: title_en or `titleEN: title(locale:"en")

• Fall back to a default translation for a field if the current language is unavailable

  • (and be able to prevent the fallback)

• Add a lang: 'xx' arg to any "internationalized" scalar to get all fields (and child fields) in that language. For instance:

  query {
    Article(id:"foo", lang: "es") {
  	title # Spanish title
  
      furtherReading {
        description # Spanish description
      }
  
      furtherReadingDE: furtherReading(lang: "de") {
        description # German description
      }
    }
  }
  

I put together a quick demo that does all (or most) of this to explore what this could look / feel like:

• Playground
• Demo