Drupal 8 multilingual tidbits 12: English can now be translated to

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.


Thomas Svenson's picture

It makes me giggle every time I read "English can now be translated to". Yes, in a way you can say it is a translation if you for example change the default US English to for example British English.

Personally I would say using something like "Make the built in US English editable", "Enable overriding of the build in US English" or "Allow customization of the build in US English".

Gábor Hojtsy's picture

Yeah, whether you understand this as translation probably depends on whether you actually change strings for a variant of English or just to enforce your preference of wording. Because this is implemented on the same translation user interface and with the same flow, I think it makes sense to say its translation or at least "translation" :)

Thomas Svenson's picture

Yes, I can see the "compromise" needed to be done here and that it would probably require quite a lot more code to make a distinct UI difference here.

PS: Nice if you could add the Comment Notify module here. I like when being alerted about replies/new comments to post I am active in ;)

dasjo's picture

cool! i just tested this in simplytest.me :)

i haven't worked much with translations in drupal 7, but i have seen cases where we introduced an artificial language to encapsulate our site/product-specific overrides.

what would be nice to have is a way to tag translations, so that one knows which translations are overridden on purpose.

could you elaborate on your thoughts on this whole language overrides challenge. what is your current approach and what do you think will be the best way to handle it in d8?

thanks & regards,

Gábor Hojtsy's picture

What do you mean by tagging translations? So you can filter for them on the backend? The translations saved as custom (eg. on this UI) can be exported separately (explained in http://hojtsy.hu/blog/2013-aug-13/drupal-8-multilingual-tidbits-11-strin...) and the UI for translation (http://hojtsy.hu/blog/2013-aug-20/drupal-8-multilingual-tidbits-13-much-...) includes a filter to filter down to customised strings only. In case of English to another English translation, you can also filter down to translated strings vs. untranslated.

Globalbility's picture

Will it also be possible to also implement unique language-specific fallbacks with contributed modules?

For entity translations I use the function language_fallback_get_candidates to get language specific fallback chains, but in D7 core this function is not applied for stings.

So I use another contributed module for string that is a hack:

Will fallbacks for strings now use core fallback function in D8? Or will fallback functions me unified?

Gábor Hojtsy's picture

Yes, you should be able to. Drupal 8's language negotiation API at this point is mostly renamed and consolidated functions similar to Drupal 7's API. https://drupal.org/node/1862202 is working on making it more object oriented.

Add new comment