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).
Comment | File | Size | Author |
---|---|---|---|
#8 | interdiff.7-8.txt | 827 bytes | penyaskito |
#8 | drupal-2031197-force-langcode-8.patch | 5.48 KB | penyaskito |
#7 | drupal-2031197-force-langcode-7.patch | 5.48 KB | webflo |
#4 | drupal-2031197-force-langcode-4.patch | 3.21 KB | webflo |
#1 | drupal-2031197-force-langcode-1-test-only.patch | 1.72 KB | kfritsche |
Comments
Comment #1
kfritschePatch 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.
Comment #2
Jose Reyero CreditAttribution: Jose Reyero commentedThat 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)
Comment #3
Gábor Hojtsy@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.
Comment #4
webflo CreditAttribution: webflo commentedI think we can enforce the langcode during entity create.
Comment #6
andypostSuppose better use preSave() here because language could be changed at form-level
Comment #7
webflo CreditAttribution: webflo commentedOk. Back to preSave().
Comment #8
penyaskitoTested and reviewed it, and worked as expected. Just a nickpick:
"Entity" should be lowercase.
Comment #9
andypostGreat! RTBC +1
Comment #11
kfritsche#8: drupal-2031197-force-langcode-8.patch queued for re-testing.
Comment #12
kfritscheHEAD was broken (#2024833: Adopt load() and loadMultiple() on entity storage controllers), setting again to RTBC.
Comment #13
Gábor HojtsyLooks good to me too!
Comment #14
YesCT CreditAttribution: YesCT commentedThis issue was RTBC and passing tests on July 1, the beginning of API freeze.
Comment #15
YesCT CreditAttribution: YesCT commented#8: drupal-2031197-force-langcode-8.patch queued for re-testing.
Comment #16
YesCT CreditAttribution: YesCT commented#8: drupal-2031197-force-langcode-8.patch queued for re-testing.
Comment #17
alexpottCommitted fbec943 and pushed to 8.x. Thanks!
Comment #18
Gábor HojtsyYay, thanks!