D8MI

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.

Image

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.

Image

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.

Image

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.

Up to date as of October 16th, 2015.

Let's move on to improvements around the interface (shipped software) translation solutions in Drupal 8! The new version separates the responsibilities for the base language layer (Language module) from the software's translation (Interface Translation module), and largely expands on the features of the interface translation capability.

Automated translation downloads

The biggest pain in setting up Drupal for a foreign language or especially multiple foreign languages is downloading and importing all the translation files. If you have Drupal core and 50 modules and want to have your site in 3 languages, you need to manually identify the version numbers and project shortnames for the 50 projects and download translations for all three languages. 153 files in total (core included). Then all these files sitting on your desktop, you need to upload them through the web interface one by one to get them all imported to the Drupal database.

Of course this is very painful, so we built the Localization update module to automate it. It was a very logical next step to build this into Drupal 8!

Up to date as of October 16th, 2015.

We went through most of the great new base language features in Drupal 8, but one thing that was not yet covered is built-in transliteration support. Yes, you read that right. Drupal 8 includes a powerful backend system for transliteration and it even uses it for machine name generation on the frontend.

Here are a few examples on how Drupal prefills the machine name for a content type for a Hungarian, Czech and Marathi type respectively:

Image

Image

Image

You don't even need to have language module enabled to use the transliteration services. However language specific transliteration patterns are supported, and the overrides are alterable. See https://drupal.org/node/1842748 for documentation on how to tap into this new API.

While this concludes the list of new base language features, that is only one of the language related modules in core. The tidbits are far from over! Excited about Drupal 8 yet?

Issues to work on

• Transliteration is only applied to machine names in core. Files would be a natural next candidate. See existing discussions in https://drupal.org/node/1842718 (includes an early patch that includes file support) and https://drupal.org/node/567832. A specific issue for files is https://www.drupal.org/node/2492171. Contributed modules can implement transliteration for anything.

We just had a full-on week of sprinting in Dublin at Drupal Dev Days recently. I think we had the biggest group and have been actively recruiting more people as they came in. The photograph below shows people gathering for the initiative meeting we had in-person. Of course this is just a small part of the whole team, which is at last count over 800 people who participated on at least one issue!

Image

John Heaven made a series of videos about what's exciting in Drupal 8 as well as where people made progress in Dublin (below) and what is still to be done (to be published). Looks like I am not the only one who noticed the great results of the team! I'm really proud of all the amazing things we moved forward from the entity translation API all through cron support for localization downloads, major improvements to the internals of configuration translation and removing eval() from locale module!

Drupal 8 is shaping up to be outstanding for multilingual sites! I can't wait.

Up to date as of October 16th, 2015.

Once you have detailed language information on content, configuration, etc, which is now widely possible in Drupal 8 (see the tidbit on language assignment), you can use this data to pull out content for specific languages.

Everything is in blocks now

While not a multilingual change, it is hugely useful for multilingual use cases that everything is in blocks now. The page title, branding, breadcrumbs, menus, navigation tabs, and so on. This make it possible to customize page content much easier using the blocks controls, effectively giving site builders all the powers around page content.

Block visibility

Brand new in Drupal 8 are language visibility conditions for blocks provided by Language module. This combined with everything being a block allows you to swap out menus per language or localize the branding of the site.

Image

This option is made available if you have more than one configured language on your website. While prior versions of Drupal provided visibility settings based on user roles, content types, paths, etc. this is now expanded to languages too. Here you can pick specific languages, even multiple of them (applying in an or relation).

Up to date as of October 16th, 2015.

One of the strongly supported language features of Drupal is right to left (RTL) language support. For some Drupal core versions, introducing an RTL language on the site is easy. Language settings include the choice of left to right and right to left orientation per language. This is still the same in Drupal 8.

There are two notable improvements though. Language settings being at the front of the installer, we have clean support for right to left orientation from picking the install profile even:

Image

Also, Drupal 6 and 7 had a special solution for writing right to left CSS. For any CSS file in the system (file.css), you could have an RTL counterpart (file-rtl.css) that was automatically added to the page when needed. This was a Drupalism and browsers got much better at supporting attribute selectors in the past years, so now the right to left CSS is all integrated in the actual CSS files. You should now use attribute selectors such as [dir="rtl"] to target specific parts of the CSS at RTL displays. By keeping the right to left styles close to the base CSS, there is less chance for mistakes and missing or out of sync RTL styling, so we hope this will result in even better RTL support!

See https://drupal.org/node/2032405 for more information and code examples.

Issues to work on

• DONE! Ok, ok, I cheated a bit with the above screenshot. There is still a bug with the sidebar position of the installer in RTL. See https://drupal.org/node/2033137 - should be an easy one to fix though
• One more thing that you may notice on the screenshot is that even English text got the RTL treatment in terms of the placement of the end of sentence period. This is not a very easy problem to resolve. An issue is going for over two years at https://drupal.org/node/1165476 to resolve this by printing additional language and direction information in this case, so the browser knows which parts are not in the (RTL) language requested. This would be useful for left to right settings also to mark the language of parts that are untranslated. Creative ideas welcome!
• There still may be missing RTL styles, especially on the administration interface. See https://www.drupal.org/node/2359331 for a collection of issues dealing with the situation.

Up to date as of October 16th, 2015

As we touched on in the detection options tidbit and when talking about language configuration, the site default language used to be a very key (and higly dangerous to change) setting, because all the things that were in an unspecified language were assumed to be in that language. In Drupal 8, one of our most important goals was to make everything know its language as far and wide as possible.

Extensible special languages

Not everything can have a language even if it has a language property. Drupal 7 has one special language, Language neutral for these cases. This "language" is assigned to content which is not specifically in a language. People also used this to designate when the language was not known but some language needed to be assigned later. In Drupal 8, these two roles are separated into "Not applicable" and "Not specified" respectively. Also, these two special languages are stored as configuration with the other administrator configured languages (but are not shown on the configuration page to avoid confusion). Modules and distributions can add more special languages like these easily. These are locked (cannot be edited or removed), and when shown in a language list, they show after the manually configurable languages.