In part 1 of this series, I introduced the workflow we use for managing i18n-friendly configuration using Features.
Last week, I described a technique to query and display nodes in all available translations. This worked well enough, but a performance-minded reader pointed out that the query generated by Views (that includes N self-joins for N enabled languages) would not scale to a large number of nodes.
My usual approach when implementing new ideas is to ensure the logic works first, and only handle optimization when needed. It's a strategy that has worked well for me in the past.
Here's a little puzzle: display a table of nodes, each row containing the same content in all available translations.
How would you do it? Stumped, I asked that question on Stack Overflow a few years ago, but never received a satisfactory reply.
Then, a couple of days ago, someone asked me if I had solved it. I hadn't thought of that puzzle since then, but I would have felt bad answering no. So, with 3 years of i18n work under my belt, I decided to give it another go.
Last week, I started writing about my tribulations managing the configuration of a multisite, multilingual application using Features, i18n, and friends. I listed the site components that needed to be managed, and described the basics of saving string translations in a feature.
This week, I'll describe a particularly challenging component I had to deal with: inoffensive-sounding menu items. Should be easy, right?
In my role as development team leader, I am responsible for the application architecture that allows other team members to focus on building functionality with minimum friction and rework. As such, one of my biggest tasks is to ensure that new features and configurations can be reliably deployed to the various stages: development, testing and production.
My current project is an Arabic/English application built on Drupal 7, that is deployed in multisite fashion to several partners.