We are heading towards the first Drupal 8 beta and there are several opportunities to help fix your pet peeves, help round out the Drupal 8 Multilingual features and just explore what is there and find and reproduce bugs if you are not that deep into development even. The following events host sprints where well known names of some of the Drupal 8 Multilingual team will be present. Meet and join us there to help get Drupal 8 to release sooner!
As you may have heard, Drupal Dev Days is going back to DrupalCon Europe 2008's host town Szeged, Hungary on March 24th to 30th, 2014! This is the ideal place for Drupal Dev Days, a whole week of sprinting with learning and participation opportunities plenty on Drupal coding and all the related technologies involved. Here are five good reasons to register for this event now:
It is the biggest distraction-free sprint to work out remaining issues in Drupal 8 in the whole year. The sprint runs from Monday morning to Sunday night. Szeged wants to provide enough but also be out of your way to be awesome! For example, we booked the same venue up until midnight each day.
We believe it is essential for a successful core sprint to have core committers on location. Szeged will have Alex Pott and Nathaniel Catchpole with Angie Byron supporting from home while we sleep. If you are a core developer in any capacity, having these two great leads directly at the same place is an amazing opportunity.
Of course there is no requirement to be a core developer to attend! If you want to join the list of almost 1800 Drupal 8 developers though, Drupalize.me is flying in Joe Shindelar and Amber Himes to deliver the Community Tools Workshop to get you on board with all the tools and processes used in Drupal core and contributed module/theme development. Great new skill to have under your sleeves in 2014. There is not much hard about it once you get started.
We are taking the BADCamp/DrupalCon labs concept and provide options for speakers to deliver 2 hour and 4 hour long workshops for a fuller deep-dive on development topics. Even if you don't want to be a developer of Drupal itself in any capacity, there is a good chance that if you earn money with Drupal, you would benefit from some of these deep-dives. This is a unique format that other events don't offer. (Admittedly we are short on submitted sessions so far. If you, yourself would love to deliver such a deep-dive or a regular session, see http://szeged2014.drupaldays.org/program/sessions, submissions close on January 15th (in 12 days)!)
Szeged is a great cozy town! Many of those who have been there in 2008 asked us repeatedly to organise a come-back opportunity. Here it is and it only costs 30 EUR now! See our interview video on Szeged experiences at http://szeged2014.drupaldays.org/community/attendees. You won't regret coming.
Drupal 8 is coming up! Check out https://drupal.org/drupal-8.0 for all the goodness that is coming! While on the surface, a freshly installed Drupal 8 does not look all that different than Drupal 7 (the backend looks and the menus are similar), the underlying system is way more powerful and flexible. We turned flexibility up a notch in countless areas.
How best to get to know this new version? Well, there are blog posts and videos plenty as we get closer to Drupal 8 being more stable. I am writing an article series on multilingual improvements myself. We do know that some people learn great on a focused day of training though, so some of us decided to offer community training (read: really cheap!) before DrupalCamp Vienna on several Drupal 8 topics.
I'm really looking forward this training because I have seven years of experience commercially training people on HTML, Perl, PHP, XML, XSLT, Drupal, etc. and really love the work that is going into assembling materials and setting up a coherent system to teach capabilities and possibilities. I am also looking for this opportunity to find more Drupal 8 bugs (which I will both in preparation and we will as part of the training, I'm sure - Drupal 8 is not yet ready after all). This is a great opportunity to do some deep-dives into what changed in Drupal 8 and learn the new best practices.
I did presentations about Drupal 8 multilingual improvements at various camps and DrupalCons and the feedback was amazing. Someone wrote in Prague: Good session, maybe it would need a little bit more time or limit the content. Presentator felt little overconfident, but that may be just me. He certainly knows what he is talking about.. I cannot help the strong confidence, as I really think Drupal 8 is going to rock your socks off in terms of multilingual improvements. But this is the opportunity to have plenty time to explore all the changes and get to know in a way you would not have a chance for a long while at least.
As people say, the best way to learn is by doing! Did you ever want to have a better multilingual solution in Drupal? Well, Drupal 8 is a big chance. While not everything will be perfect, it will be worlds apart from Drupal 7 in all the good ways. To quote some feedback from DrupalCon Prague: The work you have done for translations is a 'game changer' for the future of Drupal. and Can't wait to be able to use it on production!
The best way to get started is to help fix the remaining issues! You not only get to have your hands on the new features in Drupal 8 and learn the intricacies of them, but also get mentorship on how to build with them and also help Drupal 8 get out sooner and be a better solution. We also have a lot of fun! Full of win!
DrupalCamp Budapest is on the 16th and 17th of November in Hungary, with the second day purely reserved for sprints. This is a great opportunity for hungarian speakers to engage in some core work. Early arrival and leaving late on the sprint day helps to make a dent! I'll be there.
I'll also be in full force at and after DrupalCamp Vienna in Austria. This is an English speaking international event. Given Vienna is an entities/fields stronghold, we'll get to work with fago, fubhy, yched, etc. The sprints run between the 24th and 26th of November. So far I'm the only one specifically signed up for the multilingual sprint there, so don't let me be lonely!
I just presented a fully up to date version of my multilingual Drupal 8 talk this week at DrupalCon Prague to a packed audience of people sitting even on the floor to learn what is coming in Drupal 8. To quote one of the feedback posts I got: Great presentation of all the beautiful work that has been done for making multilanguage easier and more flexible in Drupal 8. Can't wait to be able to use it on production! Watch this talk to figure out why!
DrupalCon Prague is in the middle of Europe, so it is just natural that there are lots of multilingal content at this event. The following is a run-down of where you may want to go to get information, ask questions and even better: get involved!
Get all the information
Translation management (Thu, 1-2pm) by Michael Schmid and Cristophe Galli explores the tmgmt module suite for workflows and third party integration for translations.
Multilingual site tools in Drupal 8 (Tue, 1-2pm) is my session about the work done by 800+ contributors to make Drupal 8 step up several levels in multilingual support. Come to explore all the ways Drupal 8 is going to make your life much easier!
Ask all your questions
Creating a multilingual site (Thu 10:45-11:45am) is a BoF organized by the fine people at Lingotek where you can see their integrated translation solutions in action on Drupal 7.
Translation management tool deep dive (Thu 14:15-15:15) is a BoF to go hands-on with tmgmt and ask all the questions that did not fit into the session.
Find me at the Acquia booth on Tuesday from 2-4pm to talk about multilingual, Drupal 8 and many other things I do or Acquia does.
I usually organise a "Multilingual therapy" BoF to bring your pains and doubts, and just answer all random questions. With so much BoF coverage I think you'll find your answers. If not, I'll try my best to be there at these BoFs anyway, so we can get things sorted there too.
Work with us and get the best hands-on help
Did you ever want to have someone be able to step in and help you when learning a new system? Well, we need people to help make Drupal 8 rock and you will enjoy exploring and getting first hand help from us. Deal?
Thanks to sponsorship by Capgemini and others, we'll work from the Saturday before DrupalCon to the Sunday after to further Drupal 8's multilingual features. We already resolved almost 500 issues and gotten a long way from Drupal 7 to improve multilingual experiences for all users, but there are more things to work on still!
The first eight parts of this extensive series explained several great improvements in the base language system in Drupal 8, then we had five articles explaining all the great new software translation features. We are far from done yet! We still have two major categories of improvements to cover, namely content and configuration language and translation. Before we move on to the details, I wanted to post an introduction because there are very similar motivations and guiding principles around the improvements we made and this is going to make your life way easier compared to Drupal 7!
The glue module maze in Drupal 7
Drupal core in Drupal 7 provides translation capabilities for nodes, but no other content or configuration. Want to translate your blocks or taxonomy terms or menus? No luck. Unfortunately the base system does not understand or support multilingual content and configuration for these, so the rest of the modules cannot depend on that or know what to assume.
In Drupal 7 taxonomy terms are entities, but you have two choices to translate them. Either use the entity_translation contributed module (and the title module) or the i18n module suite. Both attempt to augment the system from the outside to apply their translation scheme on taxonomy terms, and other modules are not really aware of this. Display caching or taxonomy term lookup or autocomplete would not be naturally aware that there may be language concerns involved.
In Drupal 7 menus or blocks are not even entities, so they map to the generic i18n_string service provided by i18n module with their own respective mapping modules (i18n_menu and i18n_block).
Site settings like your site name or user account emails are not exempt from the need for glue modules. The variable suite of base modules are needed to provide the generic API that i18n_variable module will use to provide translation for these variables.
Once you get into contrib land, eg. translating views or webforms, yet more glue modules are needed. For Views, you need i18nviews, for webform, you need webform_localization (note the lack of consistent naming scheme).
These modules provide different levels of integrations and varying user interfaces to support your translation needs. The combination of the original modules as well as i18n, title and variable and the glue modules for each contrib module to make them work with this system ends up in a pretty sizable solution. It works in the end, but this is not what we aim for in Drupal 8.
Drupal 8 has general base solutions in core
Instead in Drupal 8 the configuration and content system is (almost) all encompassing, so you mostly either work with a configuration (entity) or a content (entity). Content entities all have fields. They at least have base fields, but most support configurable fields, so you can customize fields on blocks or taxonomy terms. Both base fields and configurable fields come with native support for multilingual storage, editing and rendering. When you deal with a node or custom block, you can equally have the fields set translatable.
This was made possible by the incredible effort of the configuration management initiative to get a generic configuration system in core and apply it to almost everything that cannot be considered content combined with the huge work of the entity system maintainers and application of the content entity system to much wider systems in core.
When common base systems are used, we don't need specialized mapper modules (and a separate system to map to) to maintain translation information and even contributed modules will be aware of the possibility of language variance and how to deal with it. The common base systems are also great when you need to write code against contact categories or block placements, you can use the same APIs and expect identical behavior.
Best of all, contributed modules applying the same base systems will not stand alone, they would use best practices built in core and work automatically with translations for configuration and content. No need for specialized systems and glue modules!
The extent of multilingual support for content and config
You'll read a lot more about these details in later tidbits. If you don't understand these, that is normal, just wanted to give a quick summary and heads up for what is coming.
The configuration system has full support for multilingual override values, so all elements stored in configuration may have language variants. There is also a contextual access system for configuration, so you can load values with specific language overrides, etc. These overrides are stored with the configuration and are fully deployment friendly as well. Default (shipped) configuration is translatable with the interface/software translation system. Such as shipped Views, content types, fields, etc. This works for all your in-house modules as well as contributed modules. Finally, there is a configuration translation user interface in core that provides a translation user interface almost fully automatically for your configuration (given the developer provided configuration schemas). Just covering these details will take up several tidbits so hold on for the details!
The content entity system also became really impressive. With several elements converted to content entities (menu items, contact forms, custom blocks, etc.) and fieldability available almost universally, storing multilingual content with content entities is natural. Fields provide native multilingual storage and core has a new content translation module that serves a user interface for this functionality applying to all content entity types.
So what is content and configuration then?
I made the following figure to illustrate how the entity system as well as configuration and content relate.
Image
Basically in Drupal 8, there are some configuration elements that are global, but most that you will encounter are itemized and therefore use the configuration entity system. Then almost everything else is based off of the content system. The good news is multilingual coverage is going to be fully available for all of the configuration pieces and content elements. So long as your contributed module or custom code is outside of these APIs, you'll be on your own for multilingual coverage. (Core has path aliases for example which have a custom implementation, but that retains multilingual coverage as a custom implementation.)
Embrace the improvements
For your multilingual needs, the emergence of a generally used entity/field system and a unified configuration system are a bliss. To build new code against these will require less learning and more widely accessible knowledge, and to support foreign language and multilingual sites will be natural due to the base systems doing the heavy lifting. This is just not possible with Drupal 7 however hard we try.
Read on with the upcoming tidbits for more details and insights!
This book has been sitting on my desk for so long precisely so I make sure I share my enthusiasm for it with more of you. I've been suggesting this book to several friends and so far the feedback from them was also overwhelmingly positive.
While Chip and Dan Heath do not deal much with software development and absolutely not open source in this book, I'd boldly say this is one of the greatest books I've read for those who want to get something done in an open source development environment. There are countless great stories in this book from all areas of life. From getting children with cancer to take their pills through saving species to attracting more customers to your carwash, it deals with situations when you seemingly don't have any directing power over the change you want to see in behavior/direction from your peers. You are not a boss, you don't pay these people, maybe you don't even know who they are, but you want to see a positive change happen.
Check out this video for example with a short summary of one of the tips that feels very relevant to the state of Drupal 8:
The authors built the structure of this book around a metaphor from University of Virginia psychologist Jonathan Haidt, saying our emotional side is an Elephant and our rational side is its Rider. The whole book is structured around tips to direct the rider (eg. provide specific guidance for the critical moves), motivate the elephant (eg. shrink the change or show how its already underway) and shape the path (eg. build habits to get there in a natural way).
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.
Image
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.
Image
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.
Image
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
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.
