-
Notifications
You must be signed in to change notification settings - Fork 63
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".
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:
- Edit the above yaml properties
- Change your website redirection script (if you have one)
- Provide X% of translated basic content.
- 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.
Website Content comes in two flavors: basic and rich.
Basic content is the flat text of blogposts, pages, and non-interactive content. Think pages and posts. Basic content is the fuel for your websites clicks. Polyglot gives basic content fallback support.
Rich content is interactive, flashy, and composed of shorter strings. Think navbars and dropdowns. Rich content is more technical, and keeps your visitors on the site. There is no fallback support for missing rich content.
For the sake of this example, assume you are adding German Language support to your English website.
Basic content should have a yaml frontmatter that can be edited. You can identify a page's language by adding:
lang: de
to the pages frontmatter. Then your German website will use that page in lieu of whatever English version was provided.
If a supported languages' (German) website doesn't have a german page, it defaults to the default languages' (English) page instead.
Rich content is more complex, as it typically operates on small strings. There are multiple ways to iterate over rich content. Remember, rich content will NOT have fallback support. You must support all languages in your rich content, or the site will not compile!
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