[2.x] Per-language config sets

I might be wrong, but that's due to the boolean type is not translatable type in Drupal 8?

I've to check the documentation if boolean can be translatable.

Moving to dev also.

If you look at the core schema here:
http://cgit.drupalcode.org/drupal/tree/core/config/schema/core.data_type...

It only allows label, text and date_format to be translatable.

As I can see it you can either:

1/ Define your own data type which is an extension of the boolean type and is translatable

OR

2/ Use hook_config_schema_info_alter to alter the original one.

In both cases I feel that is work for another contrib module such as i18n to provide that functionality from a separation of responsibility point of view.

Seems like to be a contrib (not eu_cookie_compliance) to handle the translation for booleans.

Not sure that making binary (on/off) values a label is a proper solution.

Also it require the proper hook_update_N in case we approve this patch.

I'm linking a Core issue, since is connected.

That patch makes absolutely no sense.

You want per-language configuration sets. This issue has nothing to do with translatability. See #12

@dpi, do you know of any module that helps in creating per-language configuration sets, or any module that has successfully implemented this? Any helper modules that we can make use of? Search on d.o for "per language config" returned nothing.

Adding some issues that I found on Google:

#2914987: Language-specific overrides support
#2275865: Per language settings (vs translated settings) are not directly supported

We could maybe cross-post to the core issue while working on this, or see if we can help config_override move their issue to RTBC?

We really need something along these lines for 2.x.

When we get around to this issue, we can't use this approach, as turning the checkboxes into select buttons doesn't provide a very good user experience.

What I'd like to explore instead is a system based on entities and fields/properties where language is one property.
That should offer much more flexibility.

This is now resolved in 2.0.x.