Archived Posts from this Category
Archived Posts from this Category
I’m delighted and proud to have been invited back to give my tutorial to the 38th Internationalization and Unicode Conference (IUC38) this November in Santa Clara, California.
Title: Building multilingual websites in Drupal 7 and Joomla 3
Date: Monday, November 3, 2014, 10:30-12:00. Track 3, tutorial morning session 2.
Here’s my abstract:
A practical look at the language and locale capabilities of Joomla! 3 and Drupal 7, two leading free software content management systems (CMSs). They let you build more powerful, more international websites faster. We look at: their core internationalisation and locale services, and localisation of UI and content. Each platform just had a major release, with advances in internationalisation. You will leave with specific tips for building your own site. We don’t assume Joomla or Drupal experience, but do include material for advanced practioners. A good tutorial for web site product managers, web designers, developers, and managers of international web teams.
Another stimulating Internationalisation and Unicode Conference (IUC36) just finished up last week (October 22-24, 2012). As usual it was rich with interesting people, stimulating subjects, and inspiration. My tutorial, Building multilingual websites in Drupal 7 and Joomla! 2.5, was well-attended and seemed to go well. My final paper and slides are posted at the preceding link.
I want to pass along a tip about confusing field names used in the Ads Factory component for Joomla for geographic data. I encountered this while customising this component for a client. At first I thought it was a bug, but now I think it’s just an odd naming convention.
Ads Factory, by Romanian developers The Factory, is a commercial component for Joomla 1.5 which lets you add classified ads to your Joomla site. (My client had me working with version 1.x on Joomla 1.5, but I see there is also a version 2.1 of Ads Factory which is Joomla 1.6 native.) There are quite a few places where Ads Factory includes geographic information: each user record can record a latitude and longitude for that user; each ad can record a latitude and longitude for the advertised merchandise; and there is way to make a “radius search”, i.e. find all ads within a given distance of a user-specified location.
These latitude and longitude values are stored in database fields with name suffixes “X” and “Y”. The user’s latitude and longitude are stored in fields “GoogleX” and “GoogleY” of the Ads Factory user table. Similarly, but not completely consistently, the ad’s latitude and longitude are stored in fields “MapX” and “MapY” of the Ads Factory ads table. The confusion comes in understanding which field stores the latitude, and which stores the longitude.
Latitude is, of course, the signed number of degrees north of the equator of a point on the earth’s surface. It ranges from +90.0 (the North Pole) to 0.0 (the Equator) to -90.0 (the South Pole). Thus, it’s a vertical coordinate. Longitude is the signed number of degrees east of the 0° meridian (roughly Greenwich, England). It ranges from +180.0 to -180.0. My part of North America is 122-123° west of Greenwich, so we have longitudes of -123.0 to -122.0 or so. It’s a horizontal coordinate. This is a well-established convention in many mapping standards.
Tidy Cartesian mathematicians like me use the convention of (X,Y) coordinates, where X is the horizontal coordinate and Y is the vertical coordinate. This is a well-established convention in geometry and graphics (though there are some exceptions).
My first interpretation of Ads Factory field names like “GoogleX” and “GoogleY” was to interpret them according to the Cartesian convention: X is horizontal, and so stores longitude, while Y is vertical, and so stores latitude. Thus (MapX, MapY) would be (longitude, latitude), the opposite of what one expects from mapping. Odd. I was surprised to find some parts of the code storing latitude in X (the horizontal coordinate!) and longitude in Y (the vertical!), which was surely a bug. I was horrified when it appeared that every part of this code had the same bug!
Then I understood the convention. Ads Factory’s developer appear to have used the (X, Y) convention to indicate just the order of the coordinates, but not their Cartesian meaning. (MapX, MapY) means (latitude, longitude), as is conventional in mapping. X is the vertical coordinate, Y is the horizontal coordinate, in the Ads Factory context. If you remember that X means “first”, not horizontal, and Y means “second”, not vertical, the Ads Factory field names are self-consistent, and the code uses them correctly.
I haven’t seen any Ads Factory documentation which explains this, so I hope this note will help some of you Ads Factory enhancers who are using these fields.
Postscript: what did my client ask me to do with Ads Factory for their site? Modify the radius search to search around the user’s latitude and longitude, instead of a location the user enters. Also, to sort the keyword and category search results by distance from the user. Quite straightforward to do, though it requires customisations to the Ads Factory code that have to be re-done everytime one upgrades the Ads Factory component.
Once again I was fortunate enough to be invited to present at this year’s Internationalization and Unicode Conference (IUC). I have posted the paper and slides for my tutorial, Building Multilingual Websites in Drupal and Joomla, over on jdlh.com.
This was my abstract, from the Unicode conference program for my talk: Continue Reading »
Thursday, 8. October 2009, 18:30-20:30hAt The Network Hub, 422 Richards Street, 3rd floor, Vancouver, BC V6B 2Z3. tel +1 604 767 8778.
A monthly meeting of the Vancouver Joomla User Group. Admission free. All people interested in learning more about the Joomla! content management system, and helping others learn more, are welcome.
Last week I gave a presentation, International and multilingual Drupal and Joomla! sites. I’ve posted my slides and handouts at that link for anyone who wants to catch up on them.
The occasion was LinuxFest Northwest 2009, held at Bellingham Technical College in Bellingham, WA, USA. It was a delightful event. It’s thoroughly grassroots and volunteer, it has a friendly and accessible vibe, yet it attracts very knowledgeable people.
This was a great opportunity for me to investigate Drupal 6’s internationalisation (i18n). As part of the research for my paper, I set up a basic Drupal 6 site with UI strings and content translated into Japanese and English languages. I found that Drupal 6 has very good support for multilingual site hosting. However, there were some tricky aspects to installing the right modules and then setting up the system configuration. I summarise them in the presentation, but it’s probably worth writing some better documentation.
Oh right, I forgot to mention: I’ve been accepted to present to the 32nd Internationalization & Unicode Conference this September! I’m presenting on a topic which I’ve been working on lately: multilingual websites. The title is: Web 2.0 goes to Babel: Multilingual websites and user-supplied content.
I want my site, jdlh.com, to be a multilingual site that communicates the business I want to do and lets me explore the tools for being world-ready. For nearly two years, I’ve worked to get a combination of tools that would do the job. I’m happy to say that this week I finally assembled a plausible solution. The final piece was sh404SEF, after some patching, with Joomla! 1.0.x and Joom!Fish.
jdlh.com supports content in multiple languages (English, Japanese, and German so far), and also a user interface in multiple languages (the same three now, but could differ). Each URL can include a language code between the domain name (”jdlh.com”) and the path to the content. The language codes look like “/en/” for English, “/de/” for German, and “/ja/” for Japanese. The codes are based on RFC 3066 . Where there is a language code in a URL, the site presents content localised for that language, to the extent possible. The content may not always available in that language, so the site may present the content in a fall-back language.
Where there is no language code in a URL, especially in the basic domain name http://jdlh.com/, the site looks at the HTTP Accept-Language header to determine which language the user prefers, and redirects the browser to content with that language code.
It’s important to me that the URLs of content on my site be concise, comprehensible to humans, and stable over time. I like Jakob Nielsen’s “URL as UI” column, and the W3C’s “Cool URIs don’t change“, and try to follow them.
jdlh.com is built using Joomla!, a free software content management system (CMS). Version 1.0.x of Joomla!, which I use as of early 2008, can be coaxed into using UTF-8 text encoding and tolerating multi-lingual content. I add in Joom!Fish, a Joomla component which helps manage content in multiple parallel languages, and provides useful language utilities like that UI widget at the top of the page, to select between languages.
Joomla has many strengths, but easy-to-read URLs aren’t among them. Left to itself, a Joomla URL is an opaque stream of numbers and codes. Turning those URLs into human-friendly URLs, which are concise, comprehensible to humans, and stable over time is the work of a “SEF” (Search-Engine-Friendly) component. Joomla has had several, but the first which satisifed us for jdlh.com is one called sh404SEF (see also sh404SEF on Joomla extensions and sh404SEF on siliana.net).
There has been a tough interaction between Joomla, Joom!Fish, and sh404SEF (and its ill-starred predecessors). Since mid-2006, Joomla would work with either of the other two, but not both together. Even as Joomla! moved forward to version 1.5.x, which has a better foundation for multilingual sites, I was held back to Joomla 1.0.x because Joom!Fish didn’t support the new version yet. Finally, in late February 2008, I discovered version 1.3.1 “TEST PR build 255″ of sh404SEF, which seemed to work well with Joom!Fish (currently 1.8.2) and Joomla (currently 1.0.15).
I made a patch to sh404SEF, one of the modules that extends the Joomla! content management system that runs this website. What the patch does is to ensure that all three of the languages supported on this website are treated equally in the URLs of this site. Without the patch, the “/en/” tag for URLs of English-language content would be missing in some cases. See my article “Default-language patch for sh404SEF published” for a description of the patch, and a link to the code.