Bunny's Language Linker: New WordPress Plugin [en]

[fr] Un nouveau plugin WordPress que je viens d'écrire. Celui-ci vous permet de gérer les liens entre pages équivalentes de deux versions linguistiques d'un site. Par exemple, si vous avez http://stephanie-booth.com/en et http://stephanie-booth.com/fr (deux installations WordPress séparées!), le plugin vous aidera à faire en sorte qu'il y ait des liens entre http://stephanie-booth.com/en/about et http://stephanie-booth.com/fr/a-propos.

Ladies and Gentlemen, I’m proud to announce the WordPress plugin Bunny’s Language Linker (zip, phps).

I’ve been wanting to write this plugin for ages, and I’ve finally done it this evening. This is a plugin for people who have a WordPress site with content duplicated in more than one language, like I’m going to have with stephanie-booth.com. For example, you have an “about” page in English, and another “about” page in German. This plugin helps you create and manage links between such “sister” pages. (“Pages”, not “posts”. It doesn’t work with posts at all.)

The plugin adds an extra field to the page editing form, inviting you to input the page slug of the sister page:

Bunny's Language Linker - Admin view

The screenshot is a bit small, but there on the right, there is a little box with “a-propos” — the slug of the French sister page. It works with more than one other language, too. You just need to edit the settings in the plugin file to specify which languages you’re playing with (instructions are in the plugin file). If I had sites in 3 other languages, say French, Spanish, and German, my settings line in the plugin file would look like this:

$bll_other_languages=array('fr', 'es', 'de');

And the little box would provide three different fields for the page slugs of the different localized sites. (OK, I’m making this sound complicated, sorry.)

The plugin then automatically adds links to the sister pages you’ve indicated. Here’s what it could look like:

Bunny's Language Linker - Page view

There’s a readme file with the plugin which will give you some more details. I’ll soon have a client site in production using that plugin, so if these explanations weren’t very clear, hopefully the demonstration will help.

Advice for a Translating Tool [en]

[fr] Quelques conseils pour mettre en place un outil de traduction d'interfaces en ligne.

I was asked for some advice for a soon-to-be-released online interface translation tool. (Hint: maybe my advice would be more useful earlier on in the project…) Here’s what I said:

  1. allow for regional forking of languages. e.g. there was a merciless
    war on the French wikipedia between the French and the Belgians over
    “Endive” which is called “Chicon” in Belgium. One is not more right than
    another, and these differences can be important.

  2. remember that words which are the same in English can have two
    different translations in other languages. e.g. “Upload” can be
    translated as “Téléchargez” (imperative verb form) or “Téléchargement”
    (noun)

  3. if you’re doing some sort of string-based thing (which I suppose
    you are) like translate.wordpress.com, let people see what they’re
    translating in context. (See the interface in English, with the place
    the string is in highlighted, and then see the interface in French,
    with the string highlighted too.)

Note: yes, this person had already watched my Google Tech Talk on languages online — and yes, I’m going to collect my language stuff somewhere neat on a static page at some point.

English Only: Barrier to Adoption [en]

Foreword: this turned into a rather longer post than I had expected. The importance of language and localization online is one of my pet topics (I’ve just decided that it would be what I’d talk about at BlogCamp, rather than teenagers and stuff), so I do tend to get carried away a little.

I was surprised last night to realise that this wasn’t necessarily obvious — so I think it’s probably worth a blog post.

The fact a service is in English only is a showstopper for many non-native speakers, hence a barrier to wider adoption in Europe.

But doesn’t everybody speak English, more or less? Isn’t it the lingua franca of today that everybody speaks? It isn’t. At least not in the French-speaking part of Switzerland, and I’m certain there are many other places in Europe where the situation is similar.

Come and spend a little time in Lausanne, for example, and try communicating in English with the man on the street. Even if many people have done a couple of years of English at school, most have never had any use for it after that and have promptly forgotten it. German is a way more important “foreign language” around here, as it is the linguistic majority in Switzerland, and most administrative centers of big companies (and the government) are in the German-speaking part of the country (which doesn’t mean that everybody speaks German, either).

The people who are reasonably comfortable with English around here will most often be those who have taken up higher academic studies, particularly in scientific subjects (“soft” and “hard” science alike).

And if I’m the person who comes to your mind when you think “Swiss”, think again — my father is British, I was born in England, went to an English medium school and spoke English at home until I was 8, conversed regularly with English-speaking grandparents during my growing years, and never stopped reading in English: all that gave me enough of a headstart that even though my English had become very rusty at the end of my teens, I dove into the English-speaking internet with a passion, and spent an anglophone year in India. So, no. I’m not your average Lausanne-living French-speaker. I’m a strange bilingual beast.

Imagine somebody whose native language is not English, even though they may theoretically know enough English to get around if you parachuted them into London. (Let’s forget about the man on the street who barely understands you when you ask where the station is.) I like to think of my (step-)sister as a good test-case (not that I want to insist on the “step-“, but it explains why she isn’t bilingual). She took up the “modern languages” path at school, which means she did German, English, and Italian during her teenage years, and ended up being quite proficient in all three (she’s pretty good with languages). She went to university after that and used some English during her studies. But since then, she honestly hasn’t had much use for the language. She’ll read my blog in English, can converse reasonably comfortably, but will tend to watch the TV series I lend her in the dubbed French version.

I’m telling you this to help paint a picture of somebody which you might (legitimately) classify as “speaks English”, but for whom it represents an extra effort. And again, I’d like to insist, my sister would be very representative of most people around here who “speak English but don’t use it regularly at work”. That is already not representative of the general population, who “did a bit of English at school but forgot it all” and can barely communicate with the lost English-speaking tourist. Oh, and forget about the teenagers: they start English at school when they’re 13, and by the time they’re 15-16 they might (if they are lucky) have enough knowledge of it to converse on everyday topics (again: learning German starts a few years before that, and is more important in the business world). This is the state of “speaking English” around here.

A service or tool which is not available in French faces a barrier to adoption in the Suisse Romande on two levels:

  • first of all, there are people who simply don’t know enough English to understand what’s written on the sign-up page;
  • second, there are people who would understand most of what’s on the sign-up page, but for whom it represents and extra effort.

Let’s concentrate on the second batch. An *extra effort”?! Lazy people! Think of it. All this talk about making applications more usable, about optimizing the sign-up process to make it so painless that people can do it with their eyes closed? Well, throw a page in a foreign language at most normal people and they’ll perceive it as an extra difficulty. And it may very well be the one that just makes them navigate away from the page and never come back. Same goes for using the service or application once they have signed up: it makes everything more complicated, and people anticipate that.

Let’s look at some examples.

The first example isn’t exactly about a web service or application, but it shows how important language is for the adoption of new ideas (this isn’t anything groundbreaking if you look at human history, but sometimes the web seems to forget that the world hasn’t changed that much…). Thanks for bearing with me while I ramble on.

In February 2001, I briefly mentioned the WaSP Browser Push and realised that the French-speaking web was really “behind” on design and web standards ressources. I also realised that although there was interest for web standards, many French-speaking people couldn’t read the original English material. This encouraged me to blog in French about it, translate Zeldman’s article, launching the translation site pompage.net in the process. Pompage.net, and the associated mailing-list, followed a year or so later by OpenWeb, eventually became a hub for the budding francophone web standards community, which is still very active to this day.

(What happened with the Swiss Blog Awards is in my opinion another example of how important language issues are.)

Back to web applications proper. Flickr is an application I love, but I have a hard time getting people to sign up and use it, even when I’ve walked them through the lengthy Yahoo-ID process. WordPress.com, on the other hand, exists in French, and I can now easily persuade my friends and clients to open blogs there. There is a strong French-speaking WordPress community too. A few years ago, when the translation and support were not what they are now, a very nice little blogging tool named DotClear became hugely popular amongst francophone bloggers (and it still is!) in part because it was in French when other major blogging solutions were insufficient in that respect.

Regarding WordPress, I’d like to point out the community-driven translation effort to which everybody can contribute. Such an open way of doing things has its pitfalls (like dreadful, dreadful translations which linger on the home page until somebody comes along to correct them) but overall, I think the benefits outweigh the risks. In almost no time, dozens of localized versions can be made available, maintained by those who know the language best.

Let’s look at teenagers. When MySpace was all that was being talked about in the US, French-speaking teenagers were going wild on skyblog. MySpace is catching up a bit now because it also exists in French. Facebook? In English, nobody here has heard of it. Live Messenger aka MSN? Very much in French, unlike ICQ, which is only used here by anglophile early adopters.

Skype and GMail/GTalk are really taking off here now that they are available in French.

Learning to use a new service, or just trying out the latest toy, can be challenging enough an experience for the average user without adding the extra hurdle of having to struggle with an unfamiliar language. Even though a non-localized service like Flickr may be the home to various linguistic groups, it’s important to keep in mind that their members will tend to be the more “anglophone” of this language group, and are not representative.

The bottom line is that even with a lot of encouragement, most local people around here are not going to use a service which doesn’t talk to them in their language.

9:52 Afterthought credit:

I just realised that this article on why startups condense in America was the little seed planted a few days ago which finally brought me to writing this post. I haven’t read all the article, but this little part of it struck me and has been working in the background ever since:

What sustains a startup in the beginning is the prospect of getting their initial product out. The successful ones therefore make the first version as simple as possible. In the US they usually begin by making something just for the local market.

This works in America, because the local market is 300 million people. It wouldn’t work so well in Sweden. In a small country, a startup has a harder task: they have to sell internationally from the start.

The EU was designed partly to simulate a single, large domestic market. The problem is that the inhabitants still speak many different languages. So a software startup in Sweden is still at a disadvantage relative to one in the US, because they have to deal with internationalization from the beginning. It’s significant that the most famous recent startup in Europe, Skype, worked on a problem that was intrinsically international.

Requirements for a Multilingual WordPress Plugin [en]

[fr] Quelques réflexions concernant un plugin multilingue pour WordPress.

My blog has been bilingual for a long time now. I’ve hacked bilingualism into it and then plugged it in. Other plugins for multilingual bloggers have been written, and some unfortunately got stuck somewhere in the development limbo.

Defining specs is a hairy problem. They need to work for the person visiting the site (polyglot or monoglot). They need to work for the person (or people! translation often involves more than one person) writing the posts. They need to work for all the robots, search engines, and fancy browsers who deal with the site.

Here is what I would like a multiple language plugin to do (think “feature requirements”, suggestion, draft):

  1. Recognize the browser language preference of the visitor and serve “page furniture” and navigation in the appropriate language. This can be overridden by a cookie-set preference when clicking on a “language link”.
    • “WordPress” furniture can be provided by the normal localization files
    • how do we deal with other furniture content in the theme (navigation, taglines, etc.)? should the plugin provide with guidelines for theme localization? do such guidelines already exist? extra information appreciated on this point
    • “language links” shouldn’t be flags, but language names in their respective languages; can this list be generated automatically based on present localization files? otherwise, can it be set in an admin panel?
    • upon “language change” (clicking on a language link), could the localization (action) be done in an AHAH– or AJAX-like way?
    • inevitable hairy problem: tag and category localization
  2. Manage “lazy multilingualism” in the spirit of the Basic Bilingual plugin and “true multilingualism” elegantly and on a per-post basis.
    • allow for “other language abstracts”
    • allow for actual other language version of the post
    • given the “general user language” defined above, show posts in that language if a version for that language exists, with mention of other language versions or abstracts
    • if that language doesn’t exist, show post in “main blog language” or “main post language” (worst case scenario: the wordpress install default) and show alongside other language abstracts/versions
    • abstract in one language (would be “excerpt” in the “main” language) and existence of the post in that language are not mutually exclusive, both can coexist
    • does it make more sense to have one WordPress post per language version, or a single post with alternate language content in post_meta? For lazy multilingualism, it makes more sense to have a single WP post with meta content, but fore “translation multilingualism”, it would make more sense to have separate posts with language relationships between them clearly defined in post_meta
  3. Use good markup. See what Kevin wrote sometime back. Make it nice for both polyglot and monoglot visitors. Inspiration?
    • use <div lang="xx"> and also rel attributes
  4. Provide a usable admin panel.
    • when I’m writing the other version of a post, I need access to the initial version for translation or abstracting
    • ideally, different language version should be editable on the same admin panel, even if they are (in the WordPress database) different posts
    • languages in use in the blog should be defined in an options screen, and the plugin should use that information to adapt the writing and editing admin panels
    • idea: radio button to choose post language; N other language excerpt/abstract fields with radio buttons next to them too; abstract radio buttons change dynamically when main post language is set; in addition to other language abstract fields, another field which can contain a post id/url (would have to see what the best solution is) to indicate “this is an equivalent post in another language” (equivalent can be anything from strict translation to similar content and ideas); this means that when WP displays the blog, it must make sure it’s not displaying a post in language B which has an equivalent in language A (language A being the visitor’s preferred language as defined above)
  5. Manage URLs logically (whatever that means).
    • if one post in two languages means two posts in WP, they will each have their own slug; it could be nice, though, to be able to switch from one to an other by just adding the two-letter language code on the end of any URL; a bit of mod_rewrite magic should do it
  6. Integrate into the WordPress architecture in a way that will not break with each upgrade (use post-meta table to define language relationships between different posts, instead of modifying the posts table too much, for example.)
    • one post translated into two other languages = 3 posts in the WP posts table
    • excerpts and post relationships stored in post_meta
    • language stored in post_meta

I have an idea for plugin development. Once the specs are drafted out correctly, how about a bunch of us pool a few $ each to make a donation to (or “pay”) the person who would develop it? Who would be willing to contribute to the pool? Who would be willing to develop such a plugin (and not abandon the project half-way) in these conditions?

These specs need to be refined. We should start from the markup/reader end and get that sorted out first. Then, think about the admin panel/writer end. Then worry about code architecture. How does that sound?

We’ve started a discussion over on the microformats.org wiki. Please join us!

Update: this post is going to suffer from ongoing editing as I refine and add ideas.