Managing Supported Languages

Managing Supported Languages

in _config.yml, the following properties manage what languages are supported by your website. You can provide support for a new language by adding it these values (see below). Languages are identified by their official locale codes.

languages: ["en", "es", "fr", "de"]
default_lang: "en"
exclude_from_localization: ["images", "fonts"]

• languages: an array of locale codes identifying the languages supported by the website.
• default_lang: default language for the website. Should probably stay english.
• exclude_from_localization: folders and directories that are part of the built website, but don't need to be localized. This is primarily to cut back on build times, and because images and fonts are big parts of the website, ensures they are not needlessly "translated".

Adding a new language

Assuming you already have a functional single-language website, adding a new language won't be trivial. To truly make a multilingual website, you should expect to have to remake all of your content in the new language. That is truly the hardest part of making a multi-language website.

The following is a checklist of steps for whatever you will likely need to do to add a new language to your website:

1. Edit the above yaml properties
2. Change your website redirection script (if you have one)
3. Provide X% of translated basic content.
4. Provide 100% of translated rich content.

Lets look at those last two points.

Firstly, you (and your team, and your managers too if you have a few of those lying around) should discuss and choose what content you need translated over into the new website. You must choose your preferred X% of basic content to translate over. Consider analytics, popular pages and blogposts, and the flow of current and future users to your website.

Rule of Thumb: When in doubt, prioritize pages over legacy blogposts. If it means getting to launch a new language sooner, legacy blogposts may be more effort than they are worth translating.

Secondly, you must (or strongly ought to) provide 100% coverage of rich content through your site. Lets make that distinction.

Multilingual Content

Website Content comes in two flavors: basic and rich. Basic content is the flat text of blogposts, pages, and non-interactive content. Rich content is interactive, flashy, and composed of shorter strings.

Basic Content

Basic content should have a yaml frontmatter that can be edited. You can identify a page's language (in this case, German) by adding:

lang: de

to the pages front matter. Then the German website will use that page in lieu of whatever default language (English) version was provided.

If a supported language's (German's) website doesn't have a german page, it defaults to the default languages (English) page instead.

Multi-language Rich Content

Rich content is more complex, as it typically operates on small strings. There are multiple ways to iterate over rich content. Remember Multi-Language rich content will NOT have fallback support. You must support all languages in your rich content, or the site will not compile!

Liquid Tools

The following liquid tools are available for use:

• site.languages

{% for lang in site.languages %}
{{lang}}
{% endfor %}

site.languages points directly to the languages array in _config.yml . It can be accessed through liquid.

• site.default_lang

{{site.default_lang}}

site.default_lang points directly to the default_lang string in _config.yml . It can be accessed through liquid.

• site.active_lang

{% if site.active_lang == "es" %}
<h1>Hola! Como estas?</h1>
{% endif %}

site.active_lang is the locale code the page is being built for. This is "de" for the german version of a page, "es" for the spanish version, and so on. It can be accessed through liquid.

Using these tools, you can specify how to attach the correct rich content

Methods

• Access from .yml data

Problem: You have a short / Medium length string that should be different for german / english / french pages

Solution: to the _data folder, make a new .yml file containing the translations of your strings, identified by the appropriate locale code.

#hello.yml
en: Hello
es: Hola
de: Hallo
fr: Bonjour

Then, get the correct language and access it from the data array

{% assign lang = site.active_lang %}
{{site.data.hello[lang]}}

• Access from language folder

Problem: You have rich content that involves multiple language-specific strings arranged in a creative manner (think the masthead), or perhaps videos in seperate languages.

Solution: Organize your rich content into a series of folders, identified by their i18n codes. Then put the translated versions of the rich content into the appropriate folders.

Example:

.
├── de
│   └── about.html
├── en
│   └── about.html
├── es
│   └── about.html
└── fr
    └── about.html

Then in your html code, you can then access the correct language file with some liquid magic.

{% assign lang=site.active_lang %}
{% include home/masthead/{{lang}}/security_intelligence.html %}

There are other approaches to install rich content onto the website. Get creative!