Change record status: 
Project: 
Introduced in branch: 
8.x
Description: 

As part of our bigger effort to clean up our API in terms of where do you encounter language (a language object) or langcode (the identifier of a language), we modified the internal storage and as a consequence the applicable exposed parts of the field API to refer to langcode.

The main change in SQL storage is in field_sql_storage_update_8000 - that entity data and revision tables now use 'langcode' instead of 'language' as column names.

Many hooks and functions such as hook_field_language_alter(), hook_field_available_languages_alter(), etc. got their arguments renamed from language to langcode and languages to langcodes respectively. This should not affect code invoking them at all. (as they already worked with langcodes but were improperly named) Also, EntityFieldQuery's fieldCondition(), fieldLanguageCondition() and addFieldCondition() abstract language handling, but internally language_group was changed to langcode_group.

Finally, although the field attach functions abstract those from direct use, the utility functions _field_invoke_multiple(), _field_invoke_multiple_default(), _field_invoke() and _field_invoke_default() got their $options['language'] argument renamed to $options['langcode'] as well. If you use these functions directly, take note of these changes.

Impacts: 
Module developers
Updates Done (doc team, etc.)
Online documentation: 
Not done
Theming guide: 
Not done
Module developer documentation: 
Not done
Examples project: 
Not done
Coder Review: 
Not done
Coder Upgrade: 
Not done
Other: 
Other updates done

Comments

Note that one thing that has not changed is the the $element passed around in field forms and themes still uses '#language' rather than '#langcode'. So you can't just blindly replace all usage of '#language'.