[RFC] Translations and Internationalization

[batisteo]

• Feature Name: translations
• Start Date: 2017-08-17
• RFC PR:
• Gutenberg Issue: https://github.com/Keats/gutenberg/issue/13

Summary

This feature aims to make Gutenberg support multilingual sites

Motivation

Why are we doing this? What use cases does it support? What is the expected outcome?

Guide-level explanation

Overview

URLs

Configuration

language_code is now understood as the default language

languages is an array of language codes as key, and the name in that language as value:

[languages]
en = "English"
fr = "Français"
pt_BR = "Português (BR)"
eo = "Esperanto"

The order matters: it could be rendered in the language selector widget.

The default language has to appear in the array, but don’t have to be the first language (even it might be more intuitive to be).

Content

File organization

The content files have to have the same name for multiple languages.
The language is defined in the extension prefix: {name}.{language_code}.{extension}

The language code can be omitted for the default language.

content
├── _index.md (or _index.en.md)
├── _index.fr.md
├── about.en.md
├── about.fr.md
└── some_section
    ├── _index.en.md
    └── _index.fr.md

Slug

I18n

Context

• lang: the current language code, always available, even for default language;

• language: the current language. language.code is equivalent to lang;

• config.languages: used for building the language selector by iterating the key / value pairs;

• section.languages listing the available translations for the current section;

• page.languages listing the available translations for the current page;

Misc

Language selector

RSS

Reference-level explanation

This is the technical portion of the RFC. Explain the design in sufficient detail that:

• Its interaction with other features is clear.
• It is reasonably clear how the feature would be implemented.
• Corner cases are dissected by example.

The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.

Drawbacks

Why should we not do this?

Rationale and Alternatives

• Why is this design the best in the space of possible designs?
• What other designs have been considered and what is the rationale for not choosing them?
• What is the impact of not doing this?

Unresolved questions

• What parts of the design do you expect to resolve through the RFC process before this gets merged?
• What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
• What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?

[batisteo]

[We might want to use the wiki for RFCs]

[Keats]

I think a PR creating a file like RFCs/i18n.md would be easier to track comments and updates. This way the repo also contains the design decisions once it's merged

…

On 17 Aug 2017 7:50 pm, "Baptiste Darthenay" ***@***.***> wrote: [*We might want to use the wiki <https://github.com/Keats/gutenberg/wiki> for RFCs*] — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#110 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAphoyIcFh4xVsabjK9JZsJAv1HN9IgZks5sZBrigaJpZM4O6Cdk> .

[Keats]

By the way for the languages map, I see more something like

default_language = "en"

[languages]

[languages.en]
title = "My blog"
description = "Hello world"

[languages.fr]
title = "Mon blog"

Which means renaming language_code to default_language as it is only used for i18n and is more explicit that way. Using maps like in the example above will give us the basic i18n needed for the template

[Keats]

Closing in favour of #111