For MyMacs.ca, locale is not only for languages

Phase 2 of the development of MyMacs.ca which was launched earlier this year [see backgrounder] focused on 2 major tasks: the integration of Mac’s Central Division to the Western Division (for which the website has initially developed), small tweaks and improvements and performance enhancements. In this post, we focus on the integration.

Locale is not only for languages

The implementation requirements were fairly simple: site administrators would be able to publish content to either or both regions (eg: West and Central), and users would see the appropriate content based on their IP address or profile settings.

We initially looked at how this could be done with taxonomy or PURL but it then became apparent that the simplest and most elegant way to proceed was to use locale. Locale, according to its description, adds language handling functionality and enables the translation of the user interface to languages other than English. But you don’t need to limit yourself to that. If we had to rewrite this definition in the context of this project we would say: Locale adds the ability to create and serve contextual content based on user preferences, URL prefix or (sub)domain name. In other words, we have substituted the concept of languages for regions.

In practical terms this is rather simple. We assigned the existing region (the existing language using en as language identifier) to a URL prefix (we used w for West) and then created an additional custom region (en-CA) with another prefix (c for Central). This meant that the content existing prior to this change would be region agnostic and as such be available with any prefix or none.

By enabling the Language switcher block and the Multilingual support for the appropriate content type, one could create content that could be accessed either only by visitors of one region or by both by using the “language neutral” option.

A little help from our i18n friend

We tried to keep this “perversion” of the Locale module to a minimum by avoiding the use of the internationalisation module. We soon faced the not-too-surprising reality check of the demanding blocks and views. In order for us to serve region specific links and blocks to the user without duplicating the same menus and blocks, we had to enable i18n. The i18n module allows administrators to define if a block or menu item is region sensitive and serve it to it’s appropriate audience. This allowed us to have both region-specific “About” and “Contact” pages for the site.

Are you a W or a C person?

As you may well know, Drupal has two classes of users: anonymous and authenticated. As such, we have two different systems serving the appropriate content for these two groups.

Anonymous users’ provenance is determined using the MaxMind geolocation service. We initially opted for an integration with their webservice but in a few instances its performance was prohibitive. We opted for the free CSV version which is slightly less precise than the service but much faster and reliable.

Once we determine the user’s IP we store their location in a cookie and redirect them to the appropriate content using the URL prefix. The cookie allows us to potentially abstract the IP query next time the user returns to the site. In other words, we prevent the geoip system to be queried and benefit on the performance front.

Authenticated users set their region through the province selection in the registration process. This site uses the content profile module to store information about the user. A bit of custom code ties and translates the changes a user makes to the province/country fields in the content profile to an actual user language. This in turns dictates which locale to use and which content to present.

We’ve also developed some code that extends the geoip_language.module (included in the geoip module) to allow the mapping provinces/states to languages (in addition to mapping countries which is already provided by the module). We’re still debating what the best way to contribute this code back to the community would be. Stay tuned!

The Moral of the Story

As it is true with Drupal (and also with most things in life) it is often surprising what can be done with ideas, concepts and things that already exist by using some creativity. This is one of the real strengths of open source and community initiatives.