Up to date as of October 16th, 2015.

Although the basic underlying building block of the interface translation system in Drupal 8 that is used to translate the software itself uses the same concepts as in Drupal 7 and before, most user facing features changed. We covered how it downloads translations automatically now from the community and how you can deviate from the source with customised translations as needed. We also discussed how English can be a translation target as well. We did not yet look at the user interface to actually make these customisations on your site, but you can bet that was improved a great deal too!

In Drupal 7 and before, the built-in user interface to translate Drupal is pretty awkward. First you need to go through an intermediary page that shows you the list of languages with their status, then the translation page itself is a filtered list with source strings and status information.

You cannot actually translate anything on this screen, you need to go in and edit translations for particular strings one by one. Then you get a list of big textareas for each language. If your target language is down on the page, you need to scroll down so much you cannot see the source string anymore.

We believe this model of translating one string to multiple languages at once is not very realistic. The more common workflow instead is for one translator to go through multiple strings for one language.

So what did we do in Drupal 8 about this? First of all, we removed the intermediary page. If you are interested in translation status for your software translations, that is now built into the main language list table (screenshot in previous tidbit). The separate intermediary page is gone. Second, we made the source string table much more useful by making the target string editable for one specific language on the form. This makes us loose the overview of which languages each string is translated to, but is way quicker for the actual translation job. Finally, we also integrated singular/plural translation support (and this of course works with languages with any number of plural variants as well). In Drupal 7, the translation interface cannot even display the singular/plural pairings due to how the data is stored in the database.

In summary, we cut out two unnecessary steps and brought in a very quick translation experience instead which even shows you which translations you changed as you go along (depicted with asterisk and yellow colouring). If you did not even know about this translation user interface in Drupal 7, there is a very good chance that was due to how hard it was to use. Drupal 8 gets you a much better solution in core! And finally, with good Drupal 8 tradition this administration interface is also responsive (adapts to varying screen sizes, even small mobile screens) and is also accessible.

Issues to work on

• All strings entered on this user interface are now recorded as customised translations. Maybe you want to fix missing strings in community translations without needing to protect those additions from possibly better updates from the community later. Discuss this in https://drupal.org/node/2069867

Up to date as of October 16th, 2015.

There are several improvements around English in Drupal 8. As we have seen in tidbit #3, English is now optional. You don't need to have it configured. If you do have it configured, it used to be a big problem however to handle it as a "translatable language". That is, to do text replacement in English text to satisfy your project requirements. For example where Drupal says "Log in" and "Log out", clients may request to see "Sign in" and "Sign out".

Using Drupal core alone, this was possible to achieve in Drupal 7 by configuring a "Custom English" language on the site with a language code different from "en", which then allowed you to replace text with your choosing. This quickly gets confusing though because then both the old "en" English language and your new "Custom English" will show up in language selectors, etc. If you disable the "en" English, then your old content saved with that langcode will not display properly. Its a whole can of worms. You may also use String overrides, but if you are using interface translation from core anyway, using one more module for the same task for a specific language is overkill.

Drupal 8 provides a simple and effective solution for this. By default, if you have English configured, it is not available as a translation target. However, you are only one checkbox away from enabling that feature.

Go edit English and make it available for translation. This will make English behave as any other language and from then on, you can "translate" to English as well.

All strings will still fall back on the built-in English text (eg. if you also have Hungarian on the site, untranslated strings in Hungarian will fall back on Drupal built-in English text). However when English is used for display, all your overrides will be effective. (Cross-language fallbacks can be implemented in contributed modules now with Drupal 8's service architecture for string lookups).

Issues to work on

• DONE! Even if you don't have English configured on your site, if you go edit configuration that has a language selector, it should not suddenly switch language. English needs to be present (and selected by default) in these cases. That is not currently the case. See and help with http://drupal.org/node/1936216 as you can.
• DONE! With good tradition, I also found a (minor UI) bug while writing this tidbit. Submitted that at https://drupal.org/node/2069271, hopefully the proposed fix will quickly land.

Up to date as of October 16th, 2015.

From previous tidbits, we know the Localization update module is now built-in in Drupal 8 and it is included in a deployment friendly way. We also covered the new context specific text translation APIs. There are a lot more user interface related changes and new functionality included, so let's dive into one of the more interesting ones!

We discussed how Drupal now downloads translations and updates your software translations from the Drupal community (thanks to the translation teams on https://localize.drupal.org/). However we know that not everybody is happy with the community translations proper. So another key feature we included in Drupal 8 is custom translation tracking. How does that work?

When you add or change a translation, we keep track that you did it for yourself, and when you import a translation file in the Gettext .po format (which is still possible manually), you can also specify if the translations in the file are your customisations or from the community. Although we do not store multiple translations of the same string, we keep track on each string whether it was provided locally or fetched from the community.

Why is this useful? Well, first of all, we can protect your translations from overwrites from the community. Now that translations can be automatically updated, your customisations would get lost if not properly tracked and protected. Automated updates protect your customisations using this tracking system. Second, you can identify these strings and work with them specifically. The translation interface includes filtering for customised translations and you can export only your customisations as well (see above), so you can reuse the same customisations on other sites. Nice, isn't it?

Issues to work on

Nothing I know at this time. Feel free to point out issues in the comments.

There are two great sessions accepted for DrupalCon Prague involved with multilingual features that you will love!

I'll talk about all the multilingual site tools in Drupal 8 that were added and improved thanks to over 800 (yes eight hundred) collaborators who keep working tirelessly so we have a fundamentally multilingual system in Drupal 8.

While Drupal 8 makes almost anything multilingual, overarching workflows and full multilingual site management tools are not included. That is where the Translation Management Tools session comes in. Come to Michael Schmid's and Christophe Galli's session to learn about the missing workflow and integration layer that is there for you in contrib.

See all the other accepted sessions for even more reasons to come at https://prague2013.drupal.org/sessions. Register for the conference at https://prague2013.drupal.org/register

Up to date as of October 16th, 2015.

In the previous tidbit, we looked at how Drupal 8 downloads software translations automatically, but what do software translations include? There are several new translation APIs for software translation in Drupal 8. Prior Drupal versions had the rule that you should use t() and format_plural() with little exceptions. Drupal 8 has much more complexity in this area, which may be a bliss or a curse depending on how you look at it. It definitely brings translation support to several areas that were not or poorly covered before. Buckle up, this 'tidbit' is more like a deep-dive into the woods of the API!

If you are not comfortable with code-talk, your key take-away should be that we now support a bigger part of the software to translate and in more flexible ways. We'll cover configuration translation from the user perspective for example in detail in later tidbits.