Motivation

Configuration entities created after / in installation on sites get created in the site default language. That is because we can rightly assume you enter data in your own site language initially. That is absolutely fine for almost all things. You'd create views and enter their labels, empty text, etc. in your language. And so on. However for languages, you pick them from a predefined list of English language names in 95% (estimated). We save them with their English label. Then translate from there. So the assumption about config entities does not stand.

Proposal

1. Force language config entity creation to always save in langcode: en.
2. Change the UI label in custom language creation to 'Language name in English' to make this clear if custom languages are created (for 5% of uses - estimated).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kfritsche’s picture

Patch attached.

It forces the langcode='en' in the preSave method of the Language Entity.
Also changed the label of 'custom language' label to 'Language name in English'.

Tests for the preSave added.

Jose Reyero’s picture

Status: Needs review » Needs work

That makes sense though I'm not sure languages should get any special treatment, I mean as comparted to the rest of the configuration.
I was looking at the language list and wondering why English names are not wrapped in t() just like the country list... ?
Also wondering: is there any other case where we stick some (selected from a predefined list) readable string value into the configuration? And if so, which assumptions are we making about the language it is stored in?

(Which I'll try to reply myself, just looking for other similar cases atm)

Gábor Hojtsy’s picture

@Jose: treating them with t() would equally be special casing, no? Languages are configurable and therefore in CMI and therefore should not be t()-ed to apply the usual translation system from configuration. It will end up in t()'s storage either way.

webflo’s picture

Status: Needs work » Needs review
FileSize
3.21 KB

I think we can enforce the langcode during entity create.

Status: Needs review » Needs work

The last submitted patch, drupal-2031197-force-langcode-4.patch, failed testing.

andypost’s picture

Suppose better use preSave() here because language could be changed at form-level

webflo’s picture

Status: Needs work » Needs review
FileSize
5.48 KB

Ok. Back to preSave().

penyaskito’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
5.48 KB
827 bytes

Tested and reviewed it, and worked as expected. Just a nickpick:

+++ b/core/modules/language/lib/Drupal/language/Tests/LanguageConfigurationTest.phpundefined
@@ -100,6 +103,16 @@ function testLanguageConfiguration() {
+    // Remove English language and add a new Language to check if langcode of
+    // Language Entity is 'en'.

"Entity" should be lowercase.

andypost’s picture

Great! RTBC +1

Status: Reviewed & tested by the community » Needs work
Issue tags: -D8MI, -sprint, -language-config

The last submitted patch, drupal-2031197-force-langcode-8.patch, failed testing.

kfritsche’s picture

Status: Needs work » Needs review
Issue tags: +D8MI, +sprint, +language-config
kfritsche’s picture

Status: Needs review » Reviewed & tested by the community
Gábor Hojtsy’s picture

Looks good to me too!

YesCT’s picture

Issue tags: +RTBC July 1

This issue was RTBC and passing tests on July 1, the beginning of API freeze.

YesCT’s picture

Issue tags: -D8MI, -sprint, -language-config, -RTBC July 1
YesCT’s picture

Issue tags: +D8MI, +sprint, +language-config, +RTBC July 1
alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed fbec943 and pushed to 8.x. Thanks!

Gábor Hojtsy’s picture

Issue tags: -sprint

Yay, thanks!

Automatically closed -- issue fixed for 2 weeks with no activity.