But mechanical translation is a bit of an unthinking brute. In this example, I had a code snippet which contained the word "link".

Should that word be translated? Obviously not! The code isn't valid unless the element name is in English - and it probably doesn't make sense to reverse the text direction.

Luckily, the HTML specification allows authors to mark specific bits of their page as unsuitable for automatic translations. The translate global attribute can be applied to your markup like this:

<code translate="no">
   &amp;lt;link … &amp;gt;
   &amp;lt;meta … &amp;gt;
   &amp;lt;strong&amp;gt;Hello&amp;lt;/strong&amp;gt;
</code>

Nothing inside that code block will be translated. Hurrah!

But there are some problems with this approach.

Consider this pseudo-code:

// Reverse the polarity of the neutron flow.
$neutron = $atom.flow( direction="backwards" );

Fairly obviously, the code itself shouldn't be translated. It simply won't run unless the syntax is precisely as written. But what about the comment at the top? It would probably be useful to have that translated, right?

It is possible to mark up different parts of a document to be translatable even if their parent isn't:

<code translate="no">
   <span translate="yes">// Reverse the polarity of the neutron flow.</span>
   $neutron = $atom.flow( direction="backwards" );
</code>

At least, that's my understanding of the specification.

This brings us on to another complex problem. Consider this code block which might be embedded in a page as an example:

// Ensure the age is calculated from the user's birthday
var age = today.date - user.birthday;

If translated into Chinese, the comment might say:

// 确保年龄是根据用户的生日计算的
var age = today.date - user.birthday;

But is it useful to have variable names be different between comments and the code?

In some contexts yes, in others no!

And that's where we hit the limits of the current crop of machine-translation algorithms. Without a holistic view of the entire page, and a semantic understanding of how previous words relate to subsequent words, there will always be glitches and gotchas like this.

For now, I'm marking my code blocks as non-translatable but letting comments be fully translated. If you have strong opinions about this - please leave a comment!

About A Minute is an amuse-bouche for podcast listeners. No long intro and outro. No waffling on. No adverts, competitions, arguing, or begging for iTunes reviews. You get to listen to an interesting person chat for about a minute - that's it!

Get About A Minute as soon as each episode goes live.

Stick this Podcast Feed into your podcatcher Or you can Subscribe on iTunes

Intro music "Gran Vals" performed by Brian Streckfus. Stopwatch Icon by Ilsur Aptukov from The Noun Project.

This podcast is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

All these languages are valuable and hugely important to their communities. Many have a Wikipedia version written in their language.

Unfortunately, very few phones support these languages.

This poses a problem for QRpedia. They way the system works is this:

1. Read the phone's language
2. Look for a suitable translation in Wikipedia
3. Return the correct article
4. If a translation doesn't exist, return a list of available articles

Suppose The National Library of Wales has a QRpedia code for the Black Book of Carmarthen. A Welsh speaker will probably wish to go to the Welsh version of the article. However, their phone does not support the Welsh language (unless it is a Samsung S5600) and is set to English.

QRpedia, therefore, redirects them to the English version and doesn't give them a chance to read in their native language.

This is a problem we have faced with both Catalan and Norwegian.

Catalan

Catalan faces the very same problem as Welsh does in the previous theoretical example. Many people speak it but, because it's rare for a phone to support it, their phones are set to Spanish.

This was how we solved the problem:

• If the QRpedia code was for a Catalan page (ca.wikipedia)...
• If the phone's language is Catalan (CA) take them to the Catalan Wikipedia.
• If the phone's language is Spanish (ES) take them to a language choice screen - they can then select between Spanish, Catalan, or any other available language.
• If the phone's language is anything else (say EN) take them to the article in their language.

QRpedia doesn't store the user's language choice - so the user has to choose every time the scan which language they want.

The reasons we don't store the language choice is that it would be very hard to undo if the user made a mistake, or ever wanted to change their language.

Norwegian

The Norwegians have two languages - Bokmål and Nynorsk.

The standard language codes are NB and NN. However, most phones only support NB - with the language header of NB-NO. To complicate matters, the NB Wikiedia is located at NO.wikipedia!

So, after much discussion with some Norwegians, I discovered that comparatively few people read NN. So, we came up with the following fix.

• If the phone's language is Bokmål (NB-NO) take them to the NO Wikipedia.
• If the phone's language is Nynorsk (NN-NO) take them to the NN Wikipedia.

However, very few phones support NN (none have ever used QRpedia) so I'm not sure if this is the correct approach.

Others

There are lots of other languages with Wikipedia supports, but which aren't well supported on phones. Wikipedia is available in nearly 300 different languages - from Scots and Simple English to Esperanto and Latin. Although, curiously, there's no separate Wikipedia for British English - or other regional English variants, nor is there one in Klingon

The Future

So, what should QRpedia do in the future? How should it handle all the thousands of languages in conjunction with the hundreds of Wikipedia languages?

That's where you come in.

If you've got a good idea on how we handle your favourite language - drop a comment on this blog.

If you're a coder, QRpedia is open-source. Check out the code and leave a comment, or raise a bug.

We need your help to determine what we do next.