Rename $user language property to langcode

Just some greps to get an idea

find . -exec grep -nH "\->language" {} \; | grep account
find . -exec grep -nH "\->language" {} \; | grep user

I have changed the $user->language to $user->langcode and $account->language to $account->langcode.
Also changed the language in database schema to langcode (user.install).

Second try...

Patch attached.

+++ b/core/modules/simpletest/tests/upgrade/drupal-7.language.database.phpundefined
@@ -524,3 +524,40 @@ db_update('system')->fields(array(
+db_insert('users')->fields(array(
+  'uid',
+  'name',
+  'pass',
+  'mail',
+  'theme',
+  'signature',
+  'signature_format',
+  'created',
+  'access',
+  'login',
+  'status',
+  'timezone',
+  'language',
+  'picture',
+  'init',
+  'data',
+))
+->values(array(
+  'uid' => '12',
+  'name' => 'testuser',
+  'pass' => 'testpass',
+  'mail' => 'test@mydomain.com',
+  'signature' => '',
+  'signature_format' => '',
+  'created' => REQUEST_TIME,
+  'access' => 0,
+  'login' => 0,
+  'status' => 1,
+  'timezone' => '',
+  'language' => 'und',
+  'picture' => '',
+  'init' => 'test@mydomain.com',
+  'data' => '',
+))
+->execute();

This is not required. We can just use

db_insert('users')->fields(array(
  'uid' => '12',
  'name' => 'testuser',
  'pass' => 'testpass',
  'mail' => 'test@mydomain.com',
  'signature' => '',
  'signature_format' => '',
  'created' => REQUEST_TIME,
  'access' => 0,
  'login' => 0,
  'status' => 1,
  'timezone' => '',
  'language' => 'und',
  'picture' => '',
  'init' => 'test@mydomain.com',
  'data' => '',
))
->execute();

+++ b/core/modules/user/user.installundefined
@@ -351,6 +351,16 @@ function user_update_8000() {
+  );
+  db_change_field('users', 'language', 'langcode', $langcode_spec);
+  db_add_index('users', 'users_uid_langcode', array('uid', 'langcode'));

Is this a completely new index? If yes, what does it have to do with the patch? If not, where do we remove the old index? :)

Changed upgrade test method, and new index is removed.

Ok, looks good now!

3rd try... (needs merging with Kalman's upgrade patch)

Merged with balagan's patch in comment 14.

+++ b/core/modules/user/user.installundefined
@@ -351,8 +351,16 @@ function user_update_8000() {
   }
+  ¶
+  $langcode_spec = array(

There is some unwanted whitespace in the line above $langcode_spec

Sorry Gábor, I attached the unmerged file.

Attached again

I changed the patch based on Gábor's comments.

The remaining failed tests need to be fixed.

Some of the failed tests are fixed. The openID test fix is remained.

In #1444992-12: Add langcode property in file schema, Damien says:

{node}.language and {users}.language are two *completely* different animals. The language attached to the user is the *default language of the user*, not the language of the user entity.

It seems like between this issue, that one, #1444966: Add langcode property in taxonomy schema, and perhaps others, we're trying to have a consistent langcode property for all entity types, but that for users, the meaning of this property is different. Should we actually be renaming this property to something like preferred_langcode and adding a separate langcode column for identifying the language of the entity itself?

@effulgentsia: I think that would be #1410114: Rename $user language property to something else

Oops, hadn't seen that was closed. Hmm....

Hah! I hadn't seen that issue, or that Gabor proposed the same name :)

The new patch is attached.

#30: 1439680-30.patch queued for re-testing.

This is just a reroll of #30 for chasing HEAD.

Re #32: yeah, I think we should deal with both langcode and preferred_langcode in this one issue.

Here's a patch that renames the existing language field to preferred_langcode, and adds a *new* langcode field that defaults to LANGUAGE_NONE, just as in #1444992: Add langcode property in file schema and #1444966: Add langcode property in taxonomy schema. I see no reason why core should assume that langcode has any relationship to preferred_langcode. Instead, when we figure out what logic core and contrib should use for determining the langcode of taxonomy terms and files, then I imagine a similar logic/workflow will be needed for account profiles, independently of users configuring their preferred site language. But, this is just my naive gut feeling. If you have experience to suggest there is a relationship between the two that we should maintain, please educate me.

Merging this into a combined issue in #1454538: Add langcode property to all entity types; for the user entity, distinguish entity language from user's language preference. Will address #37 in that patch.