DrupalCon Portland 2024 is coming up next month! The event provides good opportunities to get help with three major transitions of Drupal in 2024. Drupal 7's end of life is near, while Drupal 11 is released this year. Finally, DrupalCI testing is superceeded by much improved GitLab CI pipelines shortly after DrupalCon. Here are some highlights of related events to not miss at DrupalCon!
Drupal 7
After 16 years, I was back in Brussels for another FOSDEM last weekend. Back then, as the lead maintainer, I presented about the brand new Drupal 6 version. Now I revisited the pieces that made the Drupal 8 Multilingual Initiative super successful (dedicated post about that coming soon). That reminded me how much I used this website and other custom websites to support initiatives I worked on, and how I neglected to take care of the site in recent years. I wanted to move a bit forward, and kind of got carried away in the best way possible.
I finally stopped putting it off and took the opportunity to test myself on the Acquia Certified Developer exam. To be honest I put it off for quite long. As a household name in the community I had fears it will prove I am not good enough and funnily enough, I did worst on back end development (ooops!) and 10% better on site building. My overall result is actually the same as Angie Byron at 85%. I'm flawless with fundamental web concepts at least. Ha!
As a computer science major who transferred into more of a mix of development, leadership, events and content production, I don't have much of an experience with tech certification exams. My only encounter was with the CIW certifications 13 or so years ago, which I took back in the day to be able to teach the CIW courses at a local private school. Judging from that experience and common wisdom, I expected paperbook style questions where I need to know the order and name of arguments and options on l()
as well recite row styles of views and available options of date fields. The reality cannot be farther from that.
After reviewing language support and translation for many of Drupal's pieces, we arrived at a pretty complex question, building multilingual navigation. The question is especially of importance because we often need to put translated content in menus, and the cross of translation of content and translation of menus can easily get us into the woods. Let's build some simple solutions for different use cases to see how to think of multilingual menus.
As some of you might be aware, a group of talented and very determined people sprinted in Berlin about a month ago just to improve the i18n module for almost a week. A lot of great improvements made it in including tests, translatable contact forms and even some great usability improvements. Jose Reyero and Friederike Schmiedebach have great posts about the sprint.
Before continuing my article series, I wanted to touch quickly on the usability improvements, because my previous piece presented a pretty grim picture of textgroup based translation solutions such as blocks. Well, i18n module is still using that backend, but the new user interface improvements will make the translation process much more transparent and a lot easier to work with when managing Drupal configuration.
My last post where I've explained how Internationalization module re-implements some of Field API and where it does not do that it misses crucial functionality did not get much discussion. Therefore I decided to turn the key point at the end to the center of discussion: that either Drupal core will do fields for all user input (content and configuration alike, all through form your site name to your views empty text), or i18n module needs to do it in contrib. There is a clear need for input widgets, validators, permission handling, storage and output formatters and rendering used consistently. If it is not done by core, it will keep being a bolted-on half-failing approach despite best efforts in contrib. Please discuss at http://groups.drupal.org/node/154434
The other important post that we need your input on is about removing all UI strings from code. There are various issues with having them in code, while there are also various disadvantages to removing them from there. There are performance, translatability and even user experience concerns involved. This post is already getting some discussion, but we need much more. This could be a huge, fundamental change, so all your input is welcome. Don't say we did not ask you. Please discuss at http://groups.drupal.org/node/154394
Your input helps shape Drupal 8 and how Drupal supports building multilingual sites for years to come. Have your voice heard now!
There is great discussion forming on my previous posts on exportables and user provided text as well as the dangers of using t() for user editable data, and I can only hope we can keep that up! In that tradition, I'm cross-posting this piece to groups.drupal.org as well for discussion.
Regular readers could find this boring, but let's reiterate the three working modes that all objects should ideally be able to handle in Drupal to support multilingual site building.
- Being able to mark an object as in one language.
- Being able to mark an object as in one language and relate it to others as being a translation set. This is useful when you want to use the different language objects in different relations, track their history separately, have different permissions and workflows for them, etc.
- Being able to translate pieces of the object that need translation and leave the rest alone. Load the right language variant of the object dynamically as needed. This is very useful for keeping external relations intact and sharing common fields between translations effortlessly.
There are certain things, where not all of these make sense. For the site's name for example, people would probably only use either (1) or (3). For a block for example, people should be able to use either based on their needs. (2) is useful to place blocks differently on translated pages, (3) is good to keep the placement consistent without effort. This can be different on a per-block basis. Same applies to nodes, menus, taxonomy, views, rules, and so on.
In my previous post titled Drupal's multilingual problem - why t() is the wrong answer posted on my blog and on groups.drupal.org for feedback, I've detailed issues with using t() as a translation tool for "user provided data". This post goes into some further details, a discussion of current solutions which could form basis for discussion of future solutions.
How can we even tell the difference between code and user provided translatables?
It is fair to assume that many multilingual sites will not have English as their default language (many not even as any of their supported languages), so we cannot assume that blocks, menus, and so on are entered in English. However, source code based strings are considered part of the user interface, and as such assumed to be written in English. What does this has to do with default configurations set up by modules and How do we reconcile this with the growing popularity of exportables and features (as in Feature module generated versioned export packages)? Let's look at these two questions.
Drupal is a great system to run foreign language websites on. The core itself is written in English and modules and themes are expected to follow suit. For developers, very simple wrapper functions are available to mark your translatable strings and let Drupal translate them to whatever language needed. These are the famous t(), the less famous format_plural() and a whole family of other functions. See my cheat sheet (PDF) and the drupal.org documentation for more on this.
Then there is "the other side", whatever does not come from code. Drupal works pretty well and very consistent if you want all of those to be in a foreign language (i.e. not English), but not in multiple languages (any of which can be English at that point). Drupal only has direct multilingual support in nodes (+ fields of entitites) and for path aliases. But life with Drupal means you work with all kinds of other objects like blocks, views, rules, content types, etc which are not "language-aware".
Unfortunately for building multilingual Drupal sites, this is the biggest problem that needs to be worked around. The contributed Internationalization module attempts to fill in the gaps, provide language associations and different workflows for translating these language-unaware objects. This works to some degree, but is really not easy without much help from the modules implementing these objects.
I just got back from Drupalcamp Stockholm 2011, which was an action-packed two days for me to say the least. Due to a busy schedule, I was only able to arrive last minute the night before and leave just right after my sessions on the second day. Once again I decided to do a multilingual session all over again starting from the drawing board. There are lots of new things happening plus I think I'm developing better models to explain the components involved, so I think it was a good idea to build a new presentation. I've also presented on Drupal Security on behalf of the security team, which I hope turned out to be a very informative introduction to some of the most important things to look for when securing sites.