We're proud to provide Drupal 8 services.

Localization means more than multilingual.

  • Agile/Kanban
Team Leadership

Blackboard is a global education technology company whose product offerings differ in various parts of the world, and in different languages. In order to provide relevant information for site visitors in different markets Blackboard’s new Drupal 8 site had to not only provide content in different languages, but also content specific to each visitor’s geographic location. It also needed to be faster and cheaper for Blackboard to spin up sites of varying complexity in new markets. 


The goal of localization for Blackboard’s corporate site was to provide site visitors from around the world with content specific to their region in their region’s language. This means that in addition to displaying content in different languages, we also needed to be able to incorporate regional and dialect-specific (think “color” vs “colour”) versions of content. Also, since not all product offerings are available in every region we needed region-specific navigation as well (to avoid linking to irrelevant content for some users). All of this variation needed to exist between each regional site while allowing some content types to be shared across each region, such as dynamic “resources”, “case studies” and partner content.


Location Detection: Not only did we need to provide the ability to display regional content, we also wanted users to be aware of it. In order to do this, we use Acquia’s GeoIP service in order to determine where the user is visiting from. If their country doesn’t match the regional content that they are viewing, we present a modal dialog to show them that we have a section of the site that may be better suited for them. Once they either follow the link or indicate that they are happy where they are we set a cookie so that they don’t continually see the alert. If they leave the section that they have selected, we again alert them but provide the option to stay where they have navigated to.

Regional Sections: In order to provide the regional sections of the site we relied heavily on the “group” module. Each region is a “group” entity, with its own content. We have several “group-level” fields that allow us to define things like language, navigation menus that will appear in each section for each group, region-specific 4xx error pages, and the alias that serves as the beginning of the alias for each page belonging to the group.

Each page node is a part of exactly one group. There may be pages in different groups with similar titles and content, but this model allowed us to have content in the same language and still handle regional colloquialisms, dialects, etc. While the distinct page nodes were distinct for each region, we still had to recognize that there were some types of content had to be reused across regional sections, because creating new educational resource nodes with identical content for each region would not be sustainable. Those content types are allowed to belong to multiple groups. Content listings are built in a way so that they only display content that belongs to the regional section that is currently being viewed.

Multilingual: Possibly the most obvious part of localization is enabling content to be displayed in multiple languages. Drupal’s standard multilingual functionality doesn’t really play nicely with a content model that supports multiple versions (product pages can vary between markets) of content in the same language (think spelling differences between American and British English). In order to accommodate the model Blackboard required, we decided to use Drupal’s language modules, but to leave content translation out of the equation. Instead, we would create different nodes for each language that content was to be displayed in. From the administrative side this approach caused us to lose the “translate” operation for nodes, but in turn gave us a huge amount of flexibility. We were still able to create a site that supports content being entered in 10+ languages (including RTL languages like Arabic), and accommodate localized nuance for each region as well.


Blackboard’s requirements were complex, and caused us to rethink our typical multilingual strategy. Instead of creating a site that supports content in multiple languages, the approach that was taken here grants the internal team at Blackboard to create their new regional sections on their site, taking into account available product offerings as well as language and regional nuance - creating a platform for a site that is not only multilingual, but truly global.  

Migrating from Workbench Moderation to Content Moderation.

Team Leadership

When the Commonwealth of Massachusetts first built their Drupal 8 site, they started in Workbench Moderation that allowed their authors to write content and put it into various moderation states such as “draft” or “needs review”. With over 600 content authors on the platform, this is a vital piece to help ensure content on the platforms meets their requirements. At the time of build, Workbench Moderation was in core and Content Moderation had not reached a stable release yet. Drupal 8 introduced Content Moderation in core and as part of our ongoing engagement with Mass.gov, we were asked to help with the heavy lifting associated with the upgrade in an effort to keep their site supported and up-to-date. The Commonwealth found this to be a greater challenge than expected and relied on LCM to facilitate the right migration path.

Our first step in initiating the migration was to investigate what we were dealing with. At the time, mass.gov had around 600,000 revisions with a moderation state that needed to be migrated from Workbench Moderation to Content Moderation. We started off by digging into Content Moderation’s code to fully understand the complexities and layers of the switch. We found the systems to be very different and with no pre-designed migration path, we deduced that we needed to create a handmade migration path from scratch, outside of a standard Drupal 8 migration. Once the initial configuration of this path was set up, the process was just to keep building the migration through trial and error and figuring out the fastest plan of action.

We knew that switching from Workbench Moderation to the new core module, Content Moderation meant the mass.gov site and its authors would benefit. For a government site, security is always a concern and therefore a top priority. When working with a core module, it is actively supported for security and for any updates that core has as opposed to still running on a contributed module. 

After we felt sound on the coding portion of the switch, we wanted to make sure we were in alignment about expected workflows, transitions, non-transitions, and revision states. We started with around 20 transitions in Workbench Moderation that we were able to consolidate to 5 transitions in Content Moderation for a more optimized workflow. 

We also worked on rebuilding some views such as the “all content view” and mass.gov’s specific dashboard called, “MyContent Block”, which contains all the content the logged in author is watching. 

After a successful switch, mass.gov users are leveraging Content Moderation to moderate content. We are implementing a patch to Content Moderation for the view for “filter by moderation state”. This filter was missing some indices that would cause MySQL to incorrectly do a full table scan instead of an indexed scan of content that caused a lot of performance issues. We ended up writing a patch to include the missing indices that would bring down the query load time on the “MyContent Block” view from 15,000 milliseconds to 200 milliseconds. We plan for this patch to be made available for other sites experiencing the same issue with a lot of content like Mass.gov does.

Overall, the goal was to make the switch as seamless as possible and create little to no changes to the content authoring experience. On the module itself, content authors did get some smaller UI changes such as the submission process with dropdowns for moderation states. When it came to deployment, authors trying to make changes during this window would have experienced downtime but we were strategic enough to initiate migration on Memorial Day weekend and experienced no content loss.

When we started the migration path, the expected migration time was 15-20 hours. When we executed deployment, we got the time down to 4 hours through our optimization efforts. The migration was incredibly successful on deployment and we experienced no issues!