Is it possible to generate independent separate builds for different locales?

[mandeepm91]

This is not an issue but a question. It's the first time I am using Gatsby and this plugin gatsby-plugin-intl. My site consists of only static pages and I am using the config to support two locales en and ja.

My requirement is to generate separate builds and host them on separate domains. For example ja.example.com should serve the Japanese site and en.example.com should serve the English site. Is it possible to tweak the build process of Gatsby to generate independent builds for both?

Like instead of public directory, I want to generate two separate directories, public-en and public-ja and then use those builds for my deployment.

[mandeepm91]

After tweaking with the config a bit, here is what I came up with. I am using the environment variable LANG in gatsby-config.js to set the default language and a onPostBuild function in gatsby-node.js to rename the public directory to public-${process.env.LANG} and removing the subdirectories en and ja from the generated build.

Here is my config in the gatsby-config.js

    {
      resolve: `gatsby-plugin-intl`,
      options: {
        path: `${__dirname}/src/i18n/translations`,
        languages: ['en', 'ja'],
        defaultLanguage: process.env.LANG || 'en',
      },
    },

And here is the gatsby-node.js

const path = require('path')
const fs = require('fs-extra')

exports.onPostBuild = function() {
  const language = process.env.LANG
  const publicDir = `public-${language}`
  fs.removeSync(path.join(__dirname, publicDir))
  fs.removeSync(path.join(__dirname, 'public', 'en'))
  fs.removeSync(path.join(__dirname, 'public', 'ja'))
  fs.renameSync(path.join(__dirname, 'public'), path.join(__dirname, publicDir))
}

And some scripts I am using in package.json.

    "build": "yarn && rm -rf public/* && LANG=en gatsby build",
    "build:prod": "LANG=en gatsby build",
    "build:jp": "LANG=ja gatsby build",

This works fine as per my requirements. I would still be interested in knowing if there is any downside to this approach or is there any better (recommended) way to accomplish what I am doing.

[jhoffmcd]

I think this would actually perhaps be the preferred approach at scale. You could easily have all this automated and have CI build and deploy individual builds where the env variable is set to language for that build.