Remove the Field Language API

Some of this is touched by #2019055: Switch from field-level language fallback to entity-level language fallback so I guess we need to wait a bit and see what's left to clean up after.

Added field_language_fallback()

field_available_languages()
"Collects the available language codes for the given entity type and field"

This is meaningfully used only by field_invoke_method/field_invoke_method_multiple, where I think we can safely replace it with an inline check for field translatability + EntityInterface::getTranslationLanguages(). My current feeling is that the whole D7 approach of dealing with language at field level is obsolete in D8, where we have the notion of entity translation. Once we are able to move all the field_attach_* functions to entity controllers, we should no longer need to know field language in most scenarios.
I think it should be safe to remove the alter hook as the main use case behind it was supporting language of parts, which @fago suggested to support through a dedicated field item property.

field_content_languages()
"Returns available content language codes"

This can be safely replaced by a call to language_list(Language::STATE_ALL), which is how it is currently implemented in D8 btw.

field_language_fallback_enabled()
"Checks whether field language fallback is enabled"

Deprecated in #2019055: Switch from field-level language fallback to entity-level language fallback.

field_is_translatable()
"Checks whether a field has language support"

Since we no longer have the notion of translation handler, we can simply rely on the 'translatable' property of the field definition. We have an issue for the details: #2018685: Remove field_is_translatable().

field_has_translation_handler()
"Checks if a module is registered as a translation handler for a given entity"

Totally obsolete, it should already be deprecated. To be removed ASAP.

field_valid_language()
"Ensures that a given language code is valid"

A small utility function which should turn less and less useful as soon as the migration to the Entity Field API proceeds.

field_language()
"Returns the display language code for the fields attached to the given entity"

Deprecated in #2019055: Switch from field-level language fallback to entity-level language fallback.

+ in field.module: field_language_fallback()
"Applies language fallback rules to the fields attached to the given entity"

Deprecated in #2019055: Switch from field-level language fallback to entity-level language fallback.

Updated issue summary.

field_language_fallback() has been moved to field.multilingual.inc

Updated issue summary.

We need to fix the OP issues first. Rolling a patch should be fairly easy at the point.

More tags

Added issue summary.

Unpostponing now that #2019055: Switch from field-level language fallback to entity-level language fallback is in.

Sorry, but I think we should wait for #2095195: Remove deprecated field_attach_form_*() too :(

Ok, let's wait for #1988612: Apply formatters and widgets to rendered entity base fields, starting with node.title then.

Totally agreed on the beta target tag.

So, if I understand this right, we are going to remove everything here aside from the linked issues, correct?

Yup, that was more or less what I thought.

#2155665: Update field_valid_language() calls in edit.module now has a patch — please review so this issue gets unblocked :)

I'll have a look to them tonight :)

+++ b/core/modules/field/lib/Drupal/field/Tests/TranslationWebTest.php
@@ -103,7 +103,7 @@ function testFieldFormTranslationRevisions() {
-    $available_langcodes = array_flip(field_available_languages($this->entity_type, $this->field));
+    $available_langcodes = array_keys($entity->getTranslationLanguages());

This test is broken because getTranslationLanguages() returns actual languages that entity contain, and there's no alter hook that was used to add additional languages

Fix last test, RTBC +1

This looks good to me as well, but leaving to plach to RTBC, or at least +1.

Looks great, thanks!

All the old function usages are converted to the new API and the removed test is just obsolete now: the new logic is already covered by the Entity Translation API tests.

The removed hook was never used AFAIK, as no UI was implemented in contrib to support language of parts. Moreover in Prague we agreed that to support that a composite field carrying the field content language would be better suited.

Raising to beta blocker per #2061107-9: Remove deprecated procedural functions in Field API, since this is a requirement for it. Note that this patch actually does remove the field_language() and field_valid_language() functions, counter to the request in #2061107-9: Remove deprecated procedural functions in Field API, but:
a) The patch that got RTBC'd was posted here prior to that request, and
b) I don't know if it's possible to leave these functions in as wrappers to anything and have them be functional in a way that a caller would expect, since the entire concept of these functions is nonsensical with D8's entity translation API.

Yeah, that seems fine. There's no point in leaving two competing translation systems in, deprecated or no.

Committed and pushed to 8.x. Thanks!

This will need a change notice.

Updated the Entity Translation API change notice with a section on replacing the D7 API:

https://drupal.org/node/2040323#field-language-api

Looks good to me.