Problem/Motivation

#1879930-49: Language selectors are not showing localized to the page language onwards attempted to do this refactoring but figured out that there are a lot of side effects. We should either contain the side effects or do them as separate issues. #2341341: Change public 'name' property access on languages to getName() and add back setName() is open to change public property access on the name property so ConfigurableLanguage and Language instances will be swappable with their interfaces being compatible.

Proposed resolution

Once #2341341: Change public 'name' property access on languages to getName() and add back setName() and #1879930: Language selectors are not showing localized to the page language lands, refactor ConfigurableLanguageManager::getLanguages() to not use the low level APIs and return ConfigurableLangugae instances by doing entity_load_multiple() with all the languages. Postponed on those issues.

Remaining tasks

Refactor. Review. Commit.

User interface changes

None.

API changes

ConfigurableLanguageManager::getLanguages() will return ConfigurableLanguage instances. It is documented it returns LanguageInterface instances, so this is not a *strict* API change, but code using the return value often assumes direct property access on the name property, which is not on the ConfigurableLanguage, so this may still have side effects for non-core code.

Comments

YesCT’s picture

Issue tags: +D8MI, +language-base
Gábor Hojtsy’s picture

Status: Postponed » Closed (won't fix)

That code now has this comment from a previous attempt:

      // ... Ideally this could
      // use the entity API to load and instantiate ConfigurableLanguage
      // objects. However the entity API depends on the language system, so that
      // would result in infinite loops. We use the configuration system
      // directly and instantiate runtime Language objects...

So won't fix.