Barcelona CMI/D8MI discussion notes

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
xjm's picture

Currently there are a few different proposals for how to do multilingual configuration:

Meta: http://drupal.org/node/1448330
Option A (sun): http://drupal.org/node/1617334
- Option C (chx): http://drupal.org/node/1617334

Option B (José): http://drupal.org/node/1616594

Helpful and colourfuldiagram: http://drupal.org/files/D8CMID8MI-2.png

Many conflicting questions/goals:

  1. How much awareness does the calling code have to have about i18n?
  2. Is i18n something we're baking in to configuration system, or are we better served by a more generic contextual system?
  3. Should configuration be overridable at runtime at all?

We should try and figure out what things are most important.

System requirements:

1) "tag" configuration with language (e.g. "This view is in English, this view is in Dutch") — this solves the use case of "I have a German site and all of my views are German, not English and then translated"
2) The ability to translate "in-object" properties (e.g. This is the primary view. It's in English. These specific properties are German, French, etc.)
3) Store language in CMI 'somehow' so you can stage / export / etc. translations.
4) Not all properties are neccessarily translatable; need to keep metadata about what is and isn't. (e.g. never want to translate machine name)
5) Need to be able to get a list of all translations for a given CMI object.

Two main directions:

A) Store language in the CMI files directly alongside the properties.
Advantage:
- Simplicity: one-off just for multilanguage, doesn't try to solve all of the problems.
- re-u
Disadvantages:
- Memory usage: individual files are larger because they contain all translation
- Conflicts: Two people translating english/german at the same time could blow away each others' changes.

B) Store tranlations in separate files: e.g. a canonical "view.yml" and then derivative ones with translatable info (view.de.yml). Builds in a new layer in the configuration system that's aware it's overridden.
Advantages:
- Separaet files means less chances for conflicts when different people translating
- Memory usage better; only load one primary thing + potentially one other sub-file for a translation, rather than entire thing.
Disadvantages:
- Complexity: overrides, multiple conflicting contexts handling

In either approach, it's a wash performance-wise for single-language sites, because the original file will load without any extra stuff.
However, for multilingual you are looking at either larger files everywhere or loading two files.

Difference is between pre-compiling a list of available multilingual templates:

e.g.

$templates = array(
'en' => 'Welcome to our site',
'fr' => 'Bonjour',
'de' => 'Guten tag',
);

...

foreach ($users as $user) {
mail($user->mail, $user->lang, $templates[$user->lang]);
}

...

vs.

foreach ($users as $user) {
$config = config("contact.mail.$user->lang.yaml");
mail($user->mail, $user->lang, $config->template);
}

Another use case;

"Main menu" setting.

In English = "main_menu"

In German = "das_main_menu"

DX:

A: Optional language must be passed through the entire call chain (within an object vs. explicitly)
B: Call change is unchanged, language returned from $context *** What about WSCCI here? Symfony response object
C: Call change unchanged, all results returned to callers (in an array or whatever) and caller must pick which (via helper function, wrapping it into t() essentially)