Apply language_save and language_load to the locale management UI

Tagging.

This is unfortunately not so simple :) It is not going to work like this. You need to load the object first, overwrite its values as appropriate and then save. If you save it without its other values that are not present in the form, you got to remove those things...

Much better. :) Not obvious, but you are missing that the _save() issue has complete handling for changing of the default language, so that part of the code is entirely superfluous with the _save() implementation :) That function has this for default languages with the patch applied:

  if (!empty($language->default)) {
    // Set the new version of this language as default in a variable.
    $default_language = language_default();
    variable_set('language_default', $language);
 
    // If this is different to the previous default language, save that one
    // as non-default too.
    if ($language->language != $default_language->language) {
      $default_language->default = FALSE;
      locale_language_save($default_language);
    }
  }

So we can get rid of that up to the form redirect. Then also I'm not sure why do we need a return; at the end of the function, looks like cruft (not your mistake of course, but why not remove it?)

Well, it should come from the database via your language_load() in your patch. It is not in the form definitely.

You are right, this is missing from language_load(). I think this should indeed go to language_load, not here. Let's assume here that the load patch does this and get @andypost include it in the load patch :)

I think this looks pretty good. It needs the load to land of course, but its basically nice and dandy :) Much nicer than before the patch :)

@andypost: yeah, we can easily assure we have one default language now that we have it in a variable, but depending on the settings' storage in the future it might or might not be possible to put in a transaction. I think we should follow along here and not try to figure out all pieces at once. Going in smaller pieces helps us solve some real problems and allow us to focus on the remaining ones later instead of trying to deal with a huge mass of stuff.

Note that this should also be applied to the language overview submission page: http://api.drupal.org/api/drupal/modules--locale--locale.admin.inc/funct...

Looks good, however, I think we can get rid of the cache_clear() and module_invoke_all() at the end. I think this is the last multilingual_settings_changed piece and we can kill it from the locale.api.php now that we don't use it (coupled with the patch to save the language). If you see other uses of it, don't remove it, but otherwise, please do :) The save API will invoke the right hooks to inform other modules per language and it will clear the cache proper as well, so we don't need those here.

Otherwise I was concerned about whether the data we get from language list are full language objects, so we can just send them to be saved. Looks like we might actually have that data, so great :)

Tagging for base language system.

Adding UI language translation tag (both this one and language-base apply).

Add parent issue