Languages should be configuration entities

locale interface translation - could be converted into "storable entities" and use efq for newly introduced administrative UI

This is not in language module?!

Re-tagging

I'm sorry, but I don't see anything else in Language module or Locale module that could be converted into config aside from the stuff we are currently converting into config already.

@sun: do you think the configured list of languages themselves should not be in CMI (and therefore should not have translation support, such as the possibility to show a language name it its native form)? Or is that already covered in another issue? That is a key feature we removed temporarily with the explicit intention of getting it back by converting the list to CMI and having CMI language support take care of the rest.

oh, sorry. I thought there was an issue for converting languages already. Yeah, that makes sense.

Clarifying issue title.

Adding related issue #1164682: links with a known language need language identifier to return to after this issue has been fixed.

Bring on sprint. This is important to get back the feature we lost with the removal of native language names (via config translation).

Updated issue summary as well. Who wants to take this on? :)

I'm going to work on this during this week.

@dagmar: how is it going?

I'm on it :)

I have some questions, mostly related to #1216094: We call too many things 'language', clean that up

I'm using the code that @sun wrote here #1588422-84: Convert contact categories to configuration system to convert Languages into Configurables. So basically I have to create a new class called Language that extends ConfigEntityBase.

But it seems that this class already exists in core core/lib/Drupal/Core/Language/Language.php introduced in #1497230: Use Dependency Injection to handle object definitions and it has almost the same properties that the one I'm creating for this issue.

So, the main issue here is, should be provide two different clases for language? One for the configuration handling and other for the language object? If yes, what name should I use for the config class?

Or we just could make the class mentioned above extends the ConfigEntityBase class. What would be the performance implications of doing this?

Also, we have to define a pattern to save the config files. What should I use, the name of the language, for example

language.spanish.yml
language.french.yml

Or the langcode, language.es.yml, language.fr.yml

And finally, again, because we have a lot of things called language, we should define a name to group the languages avialable for the site.

This is because we already have config files that start with 'language', for example, language.mappings.yml, so maybe we could use the name 'site_language' to have something like this:

language.site_language.es.yml <  config for Spanish language
language.site_language.fr.yml  <  config for French language
language.site_language.it.yml  <  config for Italian language

language.mappings.yml  <  general config

I think language.$langcode.yml is fine, mappings, etc. are not valid language codes. I think the substructure proposed looks a bit ugly. We definitely should not use the lowercase English names of the languages, that is derived data (and might change). As for reusing the Language object, if we are not doing that, sounds like when we load or need to save languages, we'd need to convert back and forth, which does not sound good. Loading of languages we do on most if not all page loads already.

Here are some updates. Sorry I cannot provide a patch yet because there are some important decisions to take.

First: We cannot, or better, it wouldn't be nice to have Language as entities, for several reasons:

1. Entities expect a default language. So...
2. Entities may have bundles and revisions and a lot of things that I know are optionals but don't really make sense for this kind of configurations.

But, even if we decide to go for the entity path, I still have problems with thinks like $language->default. If this is a property of the entity... Does this means that we will have a columns for that propery in the language table? or maybe there is a way to define properties for entities that are not saved in the db. How can I do that?

Related to the file names, sun suggested via IRC to use language.something.[langcode] to make easier to load all the languages using the prefix language.something.

Attaching a patch with the work in progress to ilustrate some new issues.

This is not even testeable due ConfigurationEntity is not avilable at install level.

To fix this issue we need the following problem solved.

Alternative 1:

Make ConfigEntityBase as Core component with also implies make Entity a core component.

Alternative 2:

Provide a more generical class to handle objects that are not entities as configurations. And basically replicate a lot of code.

Is there another option to fix this?

+++ b/core/lib/Drupal/Core/Language/Language.phpundefined
@@ -16,17 +17,66 @@ namespace Drupal\Core\Language;
+   * Language code, e.g. 'de' or 'en-US'.

e.g. needs a comma after it

+++ b/core/modules/config/config.infoundefined
@@ -3,3 +3,7 @@ description = Allows administrators to manage configuration changes.
 core = 8.x
+; @todo D8: Config module is required for all modules that implement
+;   ConfigEntityBase. Move the entity system and ConfigEntity* into a
+;   Drupal\Core component to remove this required dependency.
+required = TRUE

Is this really needed now? Seems like it's being dealt with in #1760786: Move entity system "back" into a Drupal\Core component

Also, that's a lot of public properties. Couldn't some of them serve better as protected?

Gonna see if this patch passes... it does what #1760786: Move entity system "back" into a Drupal\Core component wants to do... but we have the use-case :)

So all the Entity, ContentEntity and ConfigEntity classes have move to Drupal\Core\Entity - cause they are all entities.

re: #18 Language code, e.g. 'de' or 'en-US' is repeated three times in the code so this should be dealt with in a follow up (imho)
re: #18 requirement to enable config has gone!

One interesting question has the requirement to have the entity module enabled also gone?

There are two issues there:

1) Whether the existing Drupal\Core\Language should be the config entity class itself.

2) Every ConfigEntity gets a 'langcode' property injected by default, which clashes with the actual langcode here.

However, 1) cannot work without #1760786: Move entity system "back" into a Drupal\Core component + additionally moving ConfigEntity into Core, AND additionally #1763974: Convert entity type info into plugins... that's a huge dependency chain - let's not block us on that. ;)

For now, I'd recommend to

- Introduce a separate Drupal\language\Language ConfigEntity class that is being used by the admin interface to manage the configured languages.

- Try to use 'langcode' as the id-key of the Language config entity. If that works, good. Otherwise, resort to using 'id' as id-key.

After further investigations with the patch in #19 I would definitely echo the recommendation to introduce a separate Drupal\language\Language ConfigEntity class. There are some really difficult issues with making the current Language object a confgEntity because every entity can create a Language object in the entity->language() method. This leads to a dependency headache and lots of Fatal error: Maximum function nesting level of '100' reached, aborting! messages.

The patch in #19 should not be followed up. I'm not working on this issue anymore unless @dagmar unassigns himself...

@alexpott go ahead. I prefer that more experienced people in CMI work on this issue due it was more complicated that I expected in first place. I will be helping in other CMI issues in the meanwhile.

Patch attached is a work-in-progress and will have test failures :( around language negotiation for some reasons that, at the moment, are not 100% apparent to me.

What the patch achieves:

• Creation of language config entities
• Upgrade of d7 site with languages to d8
• Removal of the language table

Things discovered:

• Using uasort and having an excpetion thrown and caught is a pain (see https://bugs.php.net/bug.php?id=50688). This happens if you use ConfigEntityBase::sort() instead of the new language_entity_sort() function. This is because language_list() gets called at a very low level of bootstrap and for some reason entity->label() calls the language() function which will catch a DependencyInjectionRuntimeException because the language_manager is not available yet!
• system_update_8000() needs to be convert the existing languages as these have to be available asap.

No interdiff attached as this is a complete re-roll based on the limited scope discussed in #21

Some of the tests fixed :)

the problem seems to be in entity_get_info using the language() function. So we need to have an exception for language entities.

 function entity_get_info($entity_type = NULL) {
-  $language_interface = language(LANGUAGE_TYPE_INTERFACE);
-
+  // We need a special exception for the language config entity as this call to
+  // language will lead to the turtles gettings language negotiaiton wrong.
+  if ($entity_type != 'language') {
+    $language_interface = language(LANGUAGE_TYPE_INTERFACE);
+  }
+  else {
+    $language_interface = new stdClass;
+    $language_interface->langcode = LANGUAGE_NOT_SPECIFIED;
+  }

Additionally since language_list() is statically cached there is no reason to use the entity static cache here either... in fact it might result in unexpected results if we do - although I'm not 100% on this. Since if we do all the language config entity manipulation through the entity sub system - then we should be able to rely on the cache?

I think this is not a case of adding php code to handle edge cases but one where the current config system (or at least the config entities) are failing for our purposes.

Since Entities depend on language, we cannot pretend to store languages as an entity. This is a conceptual issue and any code we add to handle it will be ugly. Also the dependencies schema this creates doesn't make sense at all since basically we need to load the full entity system for bootstrapping.

So IMHO either the config system should provide a way to handle storage of simple objects like languages without depending on heavyweight objects/systems like Entity, or we should handle 'manually' language storage, just like image styles are done atm (though I guess that will be converted to config entities too, right?)

We should not be using entity_get_info() for both ConfigEntity and ContentEntity. As soon as any content Entity bundle is converted to config, then it's going to explode there too (or look at taxonomy_vocabulary_get_names() and taxonomy_entity_info() for the Drupal 7 version of that problem). This is also a good reason to keep them as separate thingies instead of merging them later, unless we somehow find a way to replace the current info hook for entities with something else that doesn't have this infinite recursion issue.

from #31

So IMHO either the config system should provide a way to handle storage of simple objects like languages without depending on heavyweight objects/systems like Entity, or we should handle 'manually' language storage,

Is this possible without have to duplicate a lot of the entity system code?

from #32

We should not be using entity_get_info() for both ConfigEntity and ContentEntity

What do should we use then?

We can have hook_content_entity_info() and hook_config_entity_info(), something like that?

Well, we can have Entities that are not Entities, and we can add a big warning comment in the code like 'These are not real entities, don't use them as such'....

Just joking... (But really, Config_Entity extends Entity)

1. Instead of making it worse and more complicated why don't we assume we've placed some functionaliaty in the wrong place, and fix that (Entity extends ExportableThing) ?
2. I guess we should be creating another thread to discuss these issues that are CMI specific (for which I don't have the time today, sorry about raising the issue in the wrong place...)

(But really, Config_Entity extends Entity)

Yes the idea is that the lowest common denominator functionality lives in Entity, and ConfigEntity and ContentEntity then extend that if they need separate stuff, how much of that there is we don't know yet. Regardless, there needs to be different info hook for these - for a start ConfigEntity has hard-coded storage controller to CMI, whereas ContentEntity you can swap it around.

Ok I have created this issue #1782424: Provide a way to handle simple objects in Configuration System

#1760786: Move entity system "back" into a Drupal\Core component resolved the primary blocker, essentially making the entity system available very early. (Not fully done yet, but the goal is clear.)

#1763974: Convert entity type info into plugins will remove the module/hook system dependency from entity types.

And lastly, but I don't think it's relevant here, #1782460: Allow to reference another entity type to define an entity type's bundles intends to allow to use one entity type as the 'bundles' definition for another entity type.

There is no issue for removing the hard-coded enforcement of language support from entities yet, but given this issue here, I think that should (or has to) happen. Thus, I've created one:
#1782472: Hard-coded and enforced language support for entities conflicts with Language as a ConfigEntity

#1763974: Convert entity type info into plugins will remove the module/hook system dependency from entity types.

Yep, it would be nice if this would get us out of recursion problems.

Just committed that.

I think this technically could be done after December 1st, its not a new feature. It does help us restore the feature to translate language names (which we need to avoid a regression given we removed native language names in anticipation of this feature). Removing from sprint to focus on real new features and tagging with regression and revisit before release to keep track of the problem (hope these are the right tags).

Demoting in favor of #1802750: [Meta] Convert configurable data to ConfigEntity system.

Update according to current plans.

See also: #1828528: Add language module integration for views

I'd be tempted to mark #1512424: Add a LanguageInterface, and property setters/getters to Language class as a duplicate of this one.

Yes, saw that, thanks :)

New patch, just to see how far we can get currently.

untested, last minute changes are never a good idea

Yay, thanks for continuing with this :) My only question is why does it need to implement ArrayAccess? Languages are objects prior to this patch universally, so wherever there is array access attempted, that would be in itself a problem.

+++ b/core/includes/bootstrap.incundefined
@@ -2710,13 +2710,14 @@ function language_list($flags = LANGUAGE_CONFIGURABLE) {
       // Initialize default property so callers have an easy reference and can
       // save the same object without data loss.
-      foreach ($languages as $langcode => $info) {
+      foreach ($languages as $info) {
+        $langcode = $info['langcode'];
         $info['default'] = ($langcode == $default->langcode);
-        $languages[$langcode] = new Language($info);
+        $languages[$langcode] = new Language($info->getExportProperties());

@gabor That was for this snippet in bootstrap.inc , $info apparently is an array in HEAD, so when I started I was just adding that as a BC layer because I thought it would become an enormous patch, turns out, it probably isn't, so I'll remove that and fix failtures tonight :)

- edit - removed extra dreditor paste

Some obvious fixes, let's see now. ArrayAccess layer removed also.

Will fix a lot, effectively using 'language.entity' as prefix

Should be down to 2 failures - biggest change is the removal of views integration of {language}

Should be green.

Short version: Stupid langcode property.

Long version: don't use properties on config entities in case it's already used by the config entity system. I was using 'langcode' as the main id, but of course, during upgrade, there's two set() calls doing 'langcode' ...

I know there are a few tests failing to fix yet, but I took a look standards wise in the mean time. Patch attached for these things.

+++ b/core/includes/bootstrap.incundefined
@@ -2649,14 +2649,22 @@ function language_list($flags = LANGUAGE_CONFIGURABLE) {
+      // Use language module configuration if available. Always reset the
+      // entity cache as the language objects are statically cached.

this might wrap closer to 80 chars.

+++ b/core/modules/language/language.installundefined
@@ -117,3 +70,32 @@ function language_disable() {
+  foreach ($result as $language) {
+
+    config('language.entity.' . $language->langcode)

extra blank line.

+++ b/core/modules/language/language.moduleundefined
@@ -209,6 +209,18 @@ function language_entity_supported() {
+ * Helper callback for uasort() to sort configuration entities by weight and label.
+ */
+function language_entity_sort($a, $b) {

missing @param and @return
that's probably blocking as it's a core gate minimum for documentation:
http://drupal.org/core-gates#documentation-block-requirements

Also, the one line summary is longer than 80 chars.
http://drupal.org/node/1354#drupal

Isn't callback a menu or router thing? I think this is just a helper.

Actually, figuring out the type (besides just language entity in words) is kind of tricky, and the other sort helper I found (function _system_sort_requirements($a, $b) {
) doesn't have @param or @return either, so I didn't add them.

+++ b/core/modules/language/language.moduleundefined
@@ -469,23 +481,37 @@ function language_get_default_langcode($entity_type, $bundle) {
  * @param $language
- *   Language object with properties corresponding to 'language' table columns.
+ *   Language object with properties corresponding to the
+ *   'language' configuration properties.
  */
 function language_save($language) {

this can get wrapped closer to 80 chars.
(adding type to the @param and type hinting is probably out of scope).

ok, a bit more thought, and a google for "callback" (http://en.wikipedia.org/wiki/Callback_(computer_programming)
and I think callback is exactly this thing, a function name passed as an arg.

I looked around for more ($a, $b) kind of functions
grep -R "(\$a, \$b)" * | grep " function "
and one of them is almost identical to this:
sort() in core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php

tim.plunkett had a good idea in irc. This solves the @param dilema also.

+++ b/core/includes/bootstrap.incundefined
@@ -2649,14 +2649,29 @@ function language_list($flags = LANGUAGE_CONFIGURABLE) {
+      uasort($language_entities, function ($a, $b) {
+        $a_weight = isset($a->weight) ? $a->weight : 0;
+        $b_weight = isset($b->weight) ? $b->weight : 0;
+        if ($a_weight == $b_weight) {
+          return strnatcasecmp($a->name, $b->name);
+        }
+        return ($a_weight < $b_weight) ? -1 : 1;
+      });

Oh, my apologies, I made this recommendation out of context on IRC. This should just use Language::sort($language_entities);

+++ b/core/includes/bootstrap.incundefined
@@ -2649,14 +2649,29 @@ function language_list($flags = LANGUAGE_CONFIGURABLE) {
+        $languages[$langcode] = new Language(array(
+          'default' => ($langcode == $default->langcode),
+          'name' => $info->name,
+          'langcode' => $langcode,
+          'direction' => $info->direction,
+          'locked' => $info->locked,
+          'weight' => $info->weight,

Why not new Language((array) $info); or entity_create('language', (array) $info)?

+++ b/core/modules/language/language.moduleundefined
@@ -469,23 +469,37 @@ function language_get_default_langcode($entity_type, $bundle) {
 function language_save($language) {

This should be divided into LanguageStorageController::preSave() and LanguageStorageController::postSave().

+++ b/core/modules/language/lib/Drupal/language/Plugin/Core/Entity/Language.phpundefined
@@ -0,0 +1,78 @@
+ * Contains \Drupal\field\Plugin\Core\Entity\Language.

s/field/language

+++ b/core/modules/language/lib/Drupal/language/Plugin/Core/Entity/Language.phpundefined
@@ -0,0 +1,78 @@
+ *     "label" = "name",
...
+  /**
+   * The human-readable label for the language.
+   *
+   * @var string
+   */
+  public $name;

This needs an @todo to rename from name to label.

+++ b/core/modules/language/lib/Drupal/language/Plugin/Core/Entity/Language.phpundefined
@@ -0,0 +1,78 @@
+class Language extends ConfigEntityBase {

This needs a Drupal\language\LanguageInterface.

+++ b/core/modules/system/lib/Drupal/system/Tests/Module/DependencyTest.phpundefined
@@ -39,8 +39,9 @@ function testEnableWithoutDependency() {
+    $storage = drupal_container()->get('config.storage');

$this->container

+++ b/core/includes/bootstrap.incundefined
@@ -2652,7 +2652,14 @@ function language_list($flags = LANGUAGE_CONFIGURABLE) {
+      uasort($language_entities, function ($a, $b) {
+        $a_weight = isset($a->weight) ? $a->weight : 0;
+        $b_weight = isset($b->weight) ? $b->weight : 0;
+        if ($a_weight == $b_weight) {
+          return strnatcasecmp($a->name, $b->name);
+        }
+        return ($a_weight < $b_weight) ? -1 : 1;

Oh, my apologies, I made this recommendation out of context on IRC. This should just use Language::sort($language_entities);

+++ b/core/includes/bootstrap.incundefined
@@ -2649,14 +2649,29 @@ function language_list($flags = LANGUAGE_CONFIGURABLE) {
+ $languages[$langcode] = new Language(array(
+ 'default' => ($langcode == $default->langcode),
+ 'name' => $info->name,
+ 'langcode' => $langcode,
+ 'direction' => $info->direction,
+ 'locked' => $info->locked,
+ 'weight' => $info->weight,

That's not the language config entity, but Drupal\Core\Language\Language - Confusing as hell for now, this definitely needs to be made clearer :)

Fixed the last remaining tests. Renamed the entity id to 'language_entity', because, although unconfirmed (but most likely), probably raises some conflicts in that sense that it triggers some hooks (like locale_language_insert etc) it shouldn't. This makes sure it doesn't conflict at all.

Most stuff from #67 addressed , besides the sort, preSave() and postSave() and #68, which is not a big issue afaics - note the 'langcode' is important here, so passing on $info would not work at all.

Let's first see if the bot really like this one and then see if we can do more (list, moving calls, tests).

#69: 1754246-69.patch queued for re-testing.

This is an amazing patch! What else needs to be done to make this happen. It should happen before the API freeze :) @swentel, can you work on rerolling?

Will reroll this weekend and address the remaining points.

We miss an upgrade path too I guess ..

- edit - upgrade path test I mean

Suprised this was easy to reroll. Nothing address so far, going to bed now. I will look more tomorrow and/or sunday.

Also regarding my comment in #73, there are a lot of language upgrade tests already, so I guess I could just add a couple of lines in testLanguageUpgrade() to test whether the config files contain the content that we expect.

Bot crashed on disk space + fix in EntityQueryTest

So yeah, calling entity_load_multiple() in language_list() can't happen anymore, because that doesn't work during upgrades.

Added a test for comparing the config after an upgrade. Sorry for the lack of interdiff, I completely messed up my local install.

Gabor: can't take this further this weekend though, so someone else should bring it home, it's close if you tell me.

Missing things:
- move usort to Language
- move bits in language_save() to LanguageStorageController::preSave() and LanguageStorageController::postSave(), see #67 - although there's much to say to todo that in a follow imho.

So yeah, calling entity_load_multiple() in language_list() can't happen anymore, because that doesn't work during upgrades.

I don't think we should even call API functions like language_list() in update functions? Instead have the update-safe replacement in the update only? :)

Changes look good to me, keep this up :)

#89: language-1754246-89.patch queued for re-testing.

Looks great. I don't think I have major things, here are my notes:

+++ b/core/includes/bootstrap.incundefined
@@ -2476,15 +2476,25 @@ function language_list($flags = Language::STATE_CONFIGURABLE) {
+      // Use language module configuration if available. We can not use
+      // entity_load_multiple() because this breaks during updates.
+      $language_entities = config_get_storage_names_with_prefix('language.entity');

Should we just not use language_list() at all in upgrades and use entity_load_multiple() here?

+++ b/core/modules/language/language.moduleundefined
@@ -471,23 +471,35 @@ function language_get_default_langcode($entity_type, $bundle) {
+  // Assign language properties to language entity.
+  $language_entity->label = isset($language->name) ? $language->name : '';

I assume we should have a followup for renaming this in calling code?

+++ /dev/nullundefined
@@ -1,108 +0,0 @@
-<?php
-
-/**
- * @file
- * Provide views data and handlers for language.module.
- *
- * @ingroup views_module_handlers
- */
-
-/**
- * Implements hook_views_data().
- */

Is there generic views config entity support that could replicate this, or this is just a feature removed?

+++ b/core/modules/language/lib/Drupal/language/Plugin/Core/Entity/Language.phpundefined
@@ -0,0 +1,79 @@
+ *   id = "language_entity",
+ *   label = @Translation("Language"),
+ *   module = "language",
+ *   controllers = {
+ *     "storage" = "Drupal\Core\Config\Entity\ConfigStorageController"
+ *   },

Sounds like we also need followups to convert list/form controller as well, right?

+++ b/core/modules/language/lib/Drupal/language/Plugin/Core/Entity/Language.phpundefined
@@ -0,0 +1,79 @@
+  /**
+   * The direction of language (Left-to-Right = 0, Right-to-Left = 1).

This has constants in Language::, let's document those!

+++ b/core/modules/language/lib/Drupal/language/Plugin/Core/Entity/Language.phpundefined
@@ -0,0 +1,79 @@
+   * Flag indicating whether this language is locked or not.
+   *

Add: "Locked languages cannot be edited." to explain what this means IMHO :)

While it'd be great to get this in before code freeze, I'd consider it a release blocker via #1802750: [Meta] Convert configurable data to ConfigEntity system.

Should we just not use language_list() at all in upgrades and use entity_load_multiple() here?

Yes!

There's a variable_get() in here for the language count, that needs to move to state at some point, doesn't have to be here but I'm not sure which issue is dealing with that if not this one.

I don't think this issue should necessarily cover the count variable. I think I've seen an issue for it already, but cannot find right now. Maybe there is none...

It would be great not to postpone patches anymore on each other. We have 6 days to get patches like this committed in Drupal core.

All right, lets get the remaining pieces done then here and get this in! #1862202: Objectify the language system is being worked on heavily still.

+++ b/core/includes/bootstrap.incundefined
@@ -2478,6 +2478,7 @@ function language_list($flags = Language::STATE_CONFIGURABLE) {
     if (language_multilingual() || module_exists('language')) {
       // Use language module configuration if available. We can not use
       // entity_load_multiple() because this breaks during updates.
+      // @todo Use entity_load_by_properties() https://drupal.org/node/2026227
       $language_entities = config_get_storage_names_with_prefix('language.entity');

I don't think we should defer this todo to a follow, it should be done here. Other followups look good.

Plain reroll of #96.

Testbot, please test #102.

Needs follow-ups for ListController and FormController.
The language_admin_add_form conversion blocks removal of MENU_LOCAL_ACTION.

We hit a big issue here: langcode is the property in language, but also the language that the configuration is in, so we have a collision here. We agree about renaming langcode of language to id before we expected (#1512424: Add a LanguageInterface, and property setters/getters to Language class).

This is still WIP, but we can see the progress here.

Fixed the exception in DatabaseStorageControllerNG. Still WIP.

Two tests failing locally, lets see what the testbot thinks. #111 not taken into account (yet).
Sorry, no interdiff.

Rerolled.

1. For generating the uuids, I used: drush php-eval '$x = new \Drupal\Component\Uuid\Uuid(); print_r($x->generate() . PHP_EOL)'
2. OK.
3.

+++ b/core/modules/language/language.moduleundefined
@@ -801,16 +818,23 @@ function language_set_browser_drupal_langcode_mappings($mappings) {
function language_update_locked_weights() {
...
+ $languages = entity_load_multiple('language_entity', NULL, TRUE);
+ foreach ($languages as $language) {
+ if (!$language->locked && $language->weight > $max_weight) {
...
// Loop locked languages to maintain the existing order.
foreach (language_list(Language::STATE_LOCKED) as $language) {
$max_weight++;
...
+ config('language.entity.' . $language->id)
+ ->set('weight', $max_weight)
+ ->save();
any reason to load all languages twice?

Not really, I changed both to language_list($flag) because IMHO makes the code more legible. There shouldnt be any performance problem because of drupal_static there, but we can change that in a follow-up if needed.

4. Done.

Reverted the way of setting the weight.

Found one issue in language_update_locked_weights().

I think this whole langcode => id change proposal turned out to be way bigger a change than anticipated... So we can just do what the patch always attempted to. Make the config language entity different from the runtime Language object representation. We can at least temporarily make the Drupal\language\Language::langcode be the Drupal\language\Plugin\Core\Entity\Language::id. It looks confusing but its a massive change that we need to not make all at once IMHO.

Rerolled #102 and starting again from there.

Go!

Here is the interdiff for comment 126. Rerolled and removed the langcode property from Language Class and language_default().

Fixed failed tests in locale module by replacing langcode with id.

Fixed failed tests in locale module by replacing langcode with id.

Rerolled and move the language update to update_prepare_d8_language().

#102: language-1754246-102.patch queued for re-testing.

Fixed LanguageUpgradePathTest. All tests should pass.

Ooops. The last patch was outdated. This is the latest ...

Its important for d8mi progress.

I think important for D8MI would not be enough for it to be critical :)

1. First of all this is a CMI conversion that we are expected to complete either way.
2. Second, it needs to change the API for language, so it uses the 'id' property as config entity like everybody else does for the machine name (in this case language code).
3. And then it is a regression that we cannot translate the language name, it is only available in English. We will use config translation to get back the native name of language translation feature that was there in Drupal 7 but is currently not available.

Rerolled and just another cleanup. We can remove the type cast language_default(). (We added it as an intermediate step ...)

The re-roll in comment 114 was bad and introduced a lot of outdated code. This patch removes it again.

Okay I got through the whole patch, line by line. Was a long and hard journey.
Only thing I found is:

+++ b/core/modules/ckeditor/lib/Drupal/ckeditor/Plugin/Editor/CKEditor.php
@@ -208,9 +208,8 @@ public function getJSSettings(EditorEntity $editor) {
-      // @todo: Remove image and link plugins from CKEditor build.

Otherwise fine for me. Great job!

Did a fresh install, added a new language and tested a translation.
One follow-up which should be discussed. My default language was German and so the added language file looked like:

id: da
uuid: 18fc7b3e-99ac-4023-bc00-a04196302714
label: Danish
direction: '0'
weight: '0'
locked: '0'
status: '1'
langcode: de

langcode should be en. But this definitely doesn't concern this patch in any way.

Fixed the installer tests by injecting the selected language with drupal_static and restored the missing found by kfritsche. Thanks!

I believe we worked out the remaining pieces in this conversion. It is not a nice one in terms of the parallels of how the language entity and language runtime classes are doubled and how the installer needs to be tricked into the static language list. However the former is needed to make config language work with language entities (avoid circular dependency) and the later is needed since #1862202: Objectify the language system is not there yet. This also overlaps with several changes in that issue, so they need to get in succession. That will clean up the language system further.

I've manually tested this, looked at the config files generated and everything is working as expected.

This is a key step in making Drupal 8's language system work in the same way as the rest of the system and #1862202: Objectify the language system needs this to proceed.

git commit -m "Issue #1754246 by webflo, swentel, penyaskito, andypost, alexpott, YesCT, dagmar: Languages should be configuration entities."

So now we can go write the config schema, yay :) #2031185: Create configuration schema for language config entity

Also opened #2031197: Language configuration entities should be created in English at all times for the followup that @andypost and @kfritsche identified.

Added a change notice for this too since this may make some patches dealing with these lines of code fail as well. https://drupal.org/node/2031267

Fun follow-up #2032033: Upgrade path tests broken when language module is enabled.

Yay, removing from sprint.

up

Doesn't need revisiting.