Contrib.social

Language label logic when installing with language, adding and editing languages is confusing

Open on Drupal.org →
Created on 29 November 2017, about 7 years ago
Updated 16 February 2023, almost 2 years ago

Problem/Motivation

Creating languages right now is very inconsistent. I started looking into it because we have an issue in our install profile that the language was English and wouldn't update automatically when importing translations. What followed is a fun ride through language module and its history ;)

1. When installing Drupal in a specific language, the language label is created in English while everything else (as much as possible) is translated. This is related to #2031197: Language configuration entities should be created in English at all times → , but that is a very old issue and we do *not* create them with langcode en anymore, the argument there is also wrong about selecting from an english list, see 2.. What we should do at that point is create the entity with the localized language label, which we do have access to.

2. When then adding a second language, the language label list is being translated to the current language, so I see e.g. "Französisch" there.

3. When then adding that language, it is again created with the english label and the config entity has the langcode of my current language (de in my case). At that point, I would expect that it is created as "Französisch" since langcode is de. It could also be in french, if the langcode would be french. Optimaly, we'd also already create a french translation after importing the french translations.

4. When I now edit that language and save it, whether or not I change the label, the langcode is changed to fr. That's because of some strange/old code in \Drupal\language\Form\LanguageFormBase that defines a hidden langcode property, which then accidently overwrites the langcode when it is actually supposed to be a hidden property for the ID. This predates the rename of the langcode property to id on the language config entity. There is also no reason to have that in the first place, this is an entity form and we have the entity object already available.

Proposed resolution

1. Create the language entity in the installer with the localized language code.
3. Create additional languages with the translated label into the correct language (==langcode property). Look into creating a translation. Maybe that could be a follow-up because it is likely more complicated.
4. Remove the langcode property for existing language entities to avoid accidently overriding that.

Remaining tasks

User interface changes

API changes

Data model changes

🐛 Bug report
Status

Needs work

Version

10.0 ✨

Component
Language system  →

Last updated about 15 hours ago

  • Maintained by
  • 🇩🇪Germany @sun
Created by

🇨🇭Switzerland berdir Switzerland

Live updates comments and jobs are added and updated live.
  • D8MI

    (Drupal 8 Multilingual Initiative) is the tag used by the multilingual initiative to mark core issues (and some contributed module issues). For versions other than Drupal 8, use the i18n (Internationalization) tag on issues which involve or affect multilingual / multinational support. That is preferred over Translation.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024