Up to date as of October 29th, 2015.
In the introduction to content and configuration translation piece we discussed what is considered content in Drupal 8. This is a somewhat misleading term because custom blocks, custom menu items and even user entities (user profiles) are considered content in terms of their implementation.
Content is always stored as entities. The main difference between configuration and content entities is configuration is usually created on the backend (think views, vocabularies, etc.) while content is usually created on the frontend (think free tagging taxonomy terms, comments, blog posts). This is not a black and white differentiation but it helps think of the categories. The other key differentiator is content entities usually get to have configurable fields. You can add new fields to user profiles, taxonomy terms or comments. Again there are exceptions, for example custom menu items cannot get configurable fields in core. Finally, there are even content entities that will not be stored, in Drupal 8 contact form submissions are content entities that live only until they are sent via email. For this tidbit we are concerned for content entities that are stored and multilingual.
In the fifth tidbit, we covered language assignment to content entities. That showed the Content language page under Regional and language configuration which lists all the content entity types and lets you configure language defaults and language selector visibility for bundles of each. That is very useful on multilingual sites where you don't translate posts, like a multilingual blog where you sometimes post in one language and then another.
If you also need content translation support, all you need to do is to enable the Content translation module and have multiple languages configured. The same screen can be used to configure content translatability that you already used to configure content language defaults. With content translation module enabled, the menu item changes from Content language to Content language and translation. Bingo!
This screen now lets you turn on and off translatability as well on an entity type and bundle (subtype) level. So you can configure nodes per content type, taxonomy terms per vocabulary, custom blocks per type, etc. Configuring a bundle to be translatable then opens a whole set of configuration on the field level. Built-in (base) fields are supported, so you can translate the title of nodes and name of taxonomy terms for example. Publishing metadata like author, creation date and change date "translation" lets you keep accountability on translations. Publication status tracking per language lets you implement workflows for translations, so you can keep some languages published while others are not (yet). Promotion and stickiness per language lets you keep different metadata per language variants. You can of course uncheck the ones which you do not intend to keep different per language.
Going further down on the field list, you'll notice that image fields even support translation on a sub-field level. That means that by default they offer to translate alt text and titles but keep the image itself the same across translations. This makes sense for product pictures for example. If you also need to have separate files per language, you can configure that too.
Finally, the article type also has a taxonomy tags reference field, which stores all related taxonomy terms. By making this field translatable, you can keep a different list of related taxonomy terms per language (Case A). It is also possible that you only want to translate the terms themselves, in which case you should uncheck this box and set the tags vocabulary terms to be translatable on the same page (Case B). That would mean you keep the same tags for all languages but translate the terms themselves. You can do both at once also (Case A+B) but that may be more confusing than useful.
If you already built multilingual sites with Drupal 7 that had content translation, you may notice this model is a refined version of the Drupal 7 Entity translation module (without awkward modules required like Title) rather than the Drupal 7 core content translation module. The core module in Drupal 7 keeps different copies of nodes and relates them together in a translation set. In Drupal 8 this feature is not available, instead you can configure translatability on a field (and in some cases subfield) basis. However if you configure all fields to be fully translatable, you can essentially reproduce the Drupal 7 behavior. Compared to the Drupal 7 core solution with different entity identifiers then, Drupal 8 will have the same entity identifier but a different language variant.
The biggest advantage of the Drupal 8 solution is you can configure to translate as much as needed and not more. With one unified solution to translate only some fields or all fields, (contributed) modules only need to deal with one system instead of two. With storing translations under one entity, modules that don't want or need to deal with multilingual scenarios can still consider the entity as one, no need for special translation set support. That is way more flexible than Drupal 7 and best of all it applies to all kinds of content, not just nodes. It is future proof for modules you enable like rules and commerce.
That's it for the basics. Next, we'll cover the user interfaces, permissions and basic workflow supported in core.
Issues to work on
- DONE!
Unfortunately language-aware entity types that cannot be translated (like Aggregator feed or File) will not show up in the master list for configuration. That is an oversight. Help at https://www.drupal.org/node/2397729 - It is also possible to configure translatability for entity bundles on their own edit screen and then their fields on the field edit screens respectively. This is a lot more tedious and error prone compared to the huge overview screen we covered in this article. It may lead to incorrect settings combinations, see https://drupal.org/node/1893596. It also leads to bugs such as https://drupal.org/node/1894596.
- PARTLY DONE: Miro Dietiker outlined some concerns with the in-entity translation system, some of which have since been resolved. The document is by far not up to date but would be interesting for anyone looking at possible technological challenges with the Drupal 8 approach in more complex environments: http://techblog.md-systems.ch/tutorial-howto/2012-06-drupal-8-multiling…. There is a meta issue at https://www.drupal.org/node/2465901 with links to some of the problems opened as drupal.org issues.
Default Image on "field_image
Default Image on "field_image" is not translatable unfortunately, even by checking checkboxes (File, Alt, Title)
widgetless
The current implementation only supports translation of things that don't have constraints or widgets. That is basically text/labels. Stuff like images, numbers, user ids, etc. would need validation and widgets specific to the use which is not currently supported. Another way to look at it is we support translating parts of configuration that is possible to distribute as community translations.