adamduncan / eleventy-plugin-i18n-demo

Demo site for eleventy-plugin-i18n

eleventy-plugin-i18n-demo

Demo site for eleventy-plugin-i18n.

Goal

• Leverage Eleventy's data cascade to build a clever, language-aware {{ 'hello' | i18n }} filter, backed by multilingual dictionary translations.
• Package the filter up into a plugin, so can be easily configured and used in any Eleventy site.
• Add a data argument and interpolate values into the translations: { 'hello_name': 'Hello, {{ name }}!' }
• Write up tutorial to build on some great concepts (multilingual, language toggle) in this area. Dive further into how to architect and implement multilingual Eleventy sites, and leverage the plugin (e.g. smart language switching).
• Explore shipping additional pluralize filter for i18n usage {{ 'hello' | i18n | pluralize(3) }} (Awesome suggestion from @alexcarpenter).

TL;DR just riffin'

• We start with logical country-code directories for the site src (/en or /en-GB). Country codes or country codes with language suffixes (if we're talking dialects) are both fair game.
• Set country-specific locale data in each language directory. This data is used deeper in the country sites' cascade, as well as at the document level for lang and dir attributes.
• As we maintain independent site trees per language, the guts of the content pages will likely be written in their respective languages. But;
• With "UI text" though, in layouts, forms, and reusable components we often find ourselves hard-coding little chunks of copy throughout. What if we lift these out into a structured dictionary of terms and translations? (We could also break this down into any number/schema of dictionary files per language.)
• Then we give ourselves a clever i18n filter to play with:
  • This takes a key to look up in the dictionary. It uses lodash.get-style dot notation to support structured dictionary objects. E.g. {{ 'actions.click' | i18n }} 😎
  • Under the hood, the i18n function will be clever enough to infer its language "scope" based on page.url language prefix.
  • We can interpolate values from a data object, by passing it as the first argument: {{ 'hello_name' | i18n({ name: 'Eve' }) }}.
  • To override page locale, we can pass a language code as the second argument: {{ 'hello' | i18n({}, 'fr-FR') }}. (Note: we still pass an empty data object—or undefined—here if no interpolation is needed).
  • If a dictionary lookup can't be found, we can also set fallbackLocales via plugin options. This key/value maps lanaguages to their fallbacks. E.g. { 'en-US': 'en-GB' } or use a wildcard to catch all { '*': 'en-GB' }. Let's warn the user in the console when fallbacks are used.
  • If neither a translation nor its fallback can be found, let's return the original key and really warn the user that something's definitely lost in translation.
• One more thing: Because we know about our locales.json up front, and our site is structured predictably, we can easily create a smart language-switcher component. This will automatically link you through to the correct page in each respective language based on the page you're on. No extra front matter or permalinking required. 😗

P.S. I've naively taken translations here from Google translate. I'm sure they're wrong, but would love to get them right! If you speak Spanish or Arabic and can correct me, I'd love for you to reach out: @duncanadam.