We recently helped implement a Japanese translation for a client’s site - which was a pretty sizable challenge! The site was already broken down by country, but all the countries were in English. We ran into some unexpected challenges and wanted to break down how we overcame them.
How We Did It
We used a handful of modules to implement the basic translation functionality: locale, i18n, I18n_block, I18n_menu, I18n_string, and i18n_translation. These modules got us most of the way - read on for how we handled the rest!
Challenges
Urls
One major frustration was that much of the built-in url detection in Drupal for functionality such as placing blocks ignores the language code in the url, which is how we were handling the translations. We could have likely written custom code for this, but for most blocks, we solved by making a context that detected both the language of the page and the language-neutral/English url. This got extra complex with pages for the Japan site that were in English and Japanese. We were not using “en” in the urls - the English urls had nothing added for the language, and the Japanese urls had “ja.” So the English url for the Japan page would be www.example.com/jp/my-content and the Japanese url for the Japan page would be www.example.com/ja/jp/my-content. Phew!
Menus
Menus are a translation problem all their own, and there are several ways to tackle them. Did we want separate menus for each language? Or did we want to translate the existing menu? We started with the former approach, thinking that the content could differ. This was difficult to implement and we wound up with a bug we could never find the root cause of or fix. If you switched from a Japanese language page to an English language page, or vice-versa, the menus would disappear. If you cleared the cache, they’d come back. It was bizarre, and despite a good amount of digging, we never figured it out (if you’ve run into this, we’d love to know! Give us a shout on twitter @ChromaticHQ!). With the launch date looming, we decided to take a different approach and translate the existing menus (thus having only one instance of each menu, in two languages). This went much more smoothly!
Custom Language Toggles
We used the i18n suite of modules, which has a ton of excellent built-in functionality. It also added some things we didn’t want, like some language toggle links and buttons that weren’t quite right, and in places we didn’t want. We had to alter a couple of views to get rid of these, and create our own buttons with the proper links and in the proper places.
Views
One odd problem we had was with Views. The client had a view on a page that showed all of a certain content type, and naturally, wanted the English page to only show results in English, and Japanese results when on the Japanese page. This was easy enough - except that most of the English results had been left as “Language Neutral.” We’d hoped to be able to get the view to show all of these results, but quite a bit of debugging left us puzzled as to why we couldn’t make the default language (en) and “language neutral” both appear. Since those neutral nodes were, in fact, English, we solved the issue by running an update hook to change them to English. Problem solved!
Translating Various Strings
The bulk of translation on this site involved nodes, but there were a handful of other strings to be translated, as well. Thanks to good coding practices, these were all wrapped in t() and available to us to translate. We did run into some frustration with translating blocks, however. After setting up the block to be translatable, when a user clicks “translate,” they are directed to a form with a greyed-out field. The solution to that was going back to the string translation interface and searching for the string. This is on my list of possible contrib issues to go look into!
Lessons Learned
We spent most of our time getting the translation piece from 85% done to 100% done - it’s that final push that can be the hardest! When dealing with some unknowns, always pad out extra time. Be flexible, and don’t be afraid to abandon your current approach and try something completely different instead of spending hours in the weeds troubleshooting. You’re almost never the first person to try something in Drupal - so let the community help you! We used custom code to put the pieces together, but we didn’t reinvent the wheel for this project. We utilized existing contrib modules and core functionality to get everything working smoothly.
There was also a good deal of trust involved in this project as no one on our team, nor our client liaison, spoke or read Japanese! The client had an internal review team for that, and we simply had to trust all of the content we were given. It was a little unnerving working on something in a completely different alphabet and having no idea if there were any mistakes, but everything worked out. I’ve since worked on more multi-language sites and gotten more used to the feeling of looking at a page without knowing what the content says. It takes some getting used to!
Roadmap Your Drupal 7 Transition
We’re offering free 45 minute working sessions to help you assess your organizations level of risk, roadmap your transition plan, and identify viable options!
Drop us a note, and we’ll reach out to schedule a time.
