When Brightcove.com was first built the package react-i18n-next was added as a way to handle hard-coded strings in templates and components. Eventually with a variety of folks working in the codebase and some noteable changes to our handling of langs on our site some issues arose around our usage of i18n that needed to be addressed.
While this issue technically could have been solved by a thorough audit of our templates and components, where I kept i18n in place and focused on setting the lang for everything in 1 global context, I felt compelled to get one more dependency out of brightcove.com.
The problem
i18n was set up to handle, essentially, all text that didn't come from Contentful on brightcove.com. That sentence is in and of itself misleading, as the individual strings i18n was looking to were sourced from Contentful, but ultimately written to a static JSON file at build time.
To give some background: brightcove.com is built on Gatsby, a static site generator built around React. Due to the static nature of Gatsby, your site deploys are tied to a build process where all the content is sourced from your CMS and added to a graphql data layer that's then accessible at various points in your application. At build time you feed that data to page templates (made up of React components) and the output is rendered as static HTML (hence the 'static' in static site generation).
Gatsby has a robust set of tooling around localization+internationalization where i18n is the main player. Unfortunately in our situation:
- Whoever set i18n up initially was largely basing it around client-side detection of the user's preferred language, which while helpful as a feature is ultimately not the main purpose we were using i18n for. This led to inconsistency in where and when the language was being set (and re-set) by i18n throughout our pages and nested components.
- Even the basic set of tooling for SSG in i18n was more than we needed.
As I said above I could have just left i18n in place and done a thorough re-work of our language setting to be truly static, but again I'd rather add it and rebuild when we get to that need than keep another dependency functioning that needs to initialize and load everywhere its called throughout our pages.
The solution
Set the language of the page at the highest level we could, get the translations for that lang and set them in our global context so they can be accessed by the child components that use them.
A note about useStaticQuery and why I had to do this a different way
I personally believe that useStaticQuery was the better (read: cleaner looking + easier to manage) way to go about getting these translations fed to our components, but it would make previewing changes outside of a build nearly impossible with how we were previewing content at the time. As I write this I'm realizing there might be a workaround with our current setup so maybe this is a 2-part project lol
Setting our lang in one global place
So here's the core of our issue: the lang that pages + components were looking to was getting set and reset at both the page and component level. As such, users in languages outside of en would see content load in English, then all the instances of i18n would find and set their langs and update to (hopefully) the lang of the page they're on.
Throughout different templates I kept seeing
if(typeof window === 'undefined'){
setLang('en')
i18n.setLanguage('en')
}
typeof window === 'undefined' shows up all over SSG to determine if the app is being run on the server or in the browser. The above is saying 'if running on the server make the lang stored in our context + i18n English', which is a fair fallback, but we know what language every page will be in at build time. There's no need for an init state, the init should be the lang. My assumption is someone was setting up i18n to watch for the browser/user language, and figured we should keep all the hardcoded elements in English when staticlly generated.
Since our build process is closely tied to and very aware of the locale of the content its building, we can update the context provider present throughout brightcove.com to have and keep the correct lang.
We have a global <Layout> component used by each page that's wrapped in a <StoreProvider> to which we pass the page's lang. Now any/all components inside our pages can access the lang directly via const { lang } = useContext(StoreContext) where StoreContext is the context object provided by <StoreProvider>.
Pass a list of translations to global context
Previously in our gatsby-node file we'd source our translated strings from Contentful and write them to JSON files. Translations would show up in our markup as t('My translated string') and i18n used that key to lookup the translation in the JSON file for that lang.
Now we still source them during the build process in gatsby-node but they get passed to the createPages calls with the content's locale to be passed to the <StoreProvider>. From there it's a (relatively) simple paste + replace to swap out the t() calls for our new translations context object.
Conclusion
Like I said I did more tearing out and rebuilding than was needed to solve the problem, but in the end I think we have a cleaner DX for accessing this info, and the user gets served a page entirely in their language, not a moment of EN before the rest of our site catches up.