How to handle localization with global variants?

Developer Support
1

Hi! I’m trying to handle localization using global variants, but our app is a site generator, so we have no way of knowing ahead of time what languages will be available in the given site. Is there any way to pull global variants and their available values from the headless API?

2

Usually the list and the static generation scheme for locales is preconfigured in your code, see eg nextjs: https://nextjs.org/docs/advanced-features/i18n-routing

So your Plasmic variants should match that

3

The thing is that our sites handle dozens of languages, but any single one has only up to five, and most of them just two. We don’t want to create dozens of variants for every site if we’re going to use usually just two of those. Variants seems to be the easiest way to handle localization, especially for non-coders who are going to work on the sites, but currently for it to work I’d need to create twenty pages for every page to handle all possible languages, of which we’d use only a small fraction. So I thought we could somehow fetch the list of variants used in a specific project and only create those.

4

Can you share a bit more detail about your setup?

Ignoring Plasmic for a second - how are these sites setup and how is localization setup in them? For instance, is each site a separate Next config? So each site can have a unique list of locales?

And are you saying each site connected to the same Plasmic project?

5

We’re using Gatsby, and in terms of content currently we’re using Sanity for everything, so basically we provide a slug in the env, on the basis of which the app pulls relevant site data from Sanity, which includes the list of languages relevant for the site. We then use gatsby-node.js to parse that information and build relevant pages. A few static pieces of content in certain components are stored in Locize, using react-i18next for localization, but most of the content is pulled from sanity, using our custom “translatable rich text” component, essentially an array of rich texts for any relevant languages. We wanted to move all this to Plasmic, which is infinitely more flexible than our current setup. We’d be using a separate project for every site.
So right now I’m thinking how to handle localization. It seems that variants are the simplest way for non-developers to type in content for various locales without using external tools. Therefore I’m trying to figure out a way to pull in all variants that are used in the given project, in order to do something similar to our previous setup - to build only the pages for locales relevant to the given project.

6

Got it - typically what we see is that the canonical “list of locales” is defined outside of Plasmic in the codebase, since you may have other pages/components/etc. that were not created in Plasmic (including code components used in Plasmic), and they would also need to be localized (often using some system like these).

If you would like that list of locales to come from Plasmic, there isn’t currently a way to query for the list of options in a global variant, but you can alternatively manage a list in the Plasmic headless CMS. (You would just need to keep this in sync with the list of variants, and the assumption is that this isn’t too annoying due to the list of locales not changing that much.)

And to render the correct Plasmic variant is just:

// This would be inside your gatsby-node, similar to what you might have today already, but locales can come from Plasmic CMS instead if you'd like it to.

locales.forEach(locale =>
  createPage({
    ...,
    context: { locale }
  })
)

// From <https://docs.plasmic.app/learn/localization/#approach-2-use-variants>

    <PlasmicRootProvider
      ...
      globalVariants={[{ name: 'locale', value: locale }]}
    >

Let me know if that helps.

1 Like
7

Yeah, the idea with the CMS might just solve that, thanks!