In the last post we looked at simple static text replacement where the text doesn’t change from request to request. But as soon as we use conditionals to build up a text string this simple lookup method is no longer sufficient.

Simple data inclusion

The simplest of dynamic text examples we have is a message telling us which page we are on.

<?php
$pageNo = 6;
echo "You are currently on page ", $pageNo;
?>

The first pitfall to avoid is to resist creating a translation string for the static-looking text You are currently on page. Yes, this is a static piece of text, but it requires additional context for the message to make sense. This is done in the code by tacking on the page number at the end of the string. The resulting string is You are currently on page 16 which makes sense without further context.

This works in English, but in other languages it may not be appropriate, or grammatically correct for the page number to be at the end. We need to ensure that the placement of the page number is as flexible as possible.

The most straightforward solution is to use a token to represent the $pageNo variable in the text string. And at request time replace these tokens with their variable amounts. This is a three step process:

• Refactor the static looking text to use a text replacement
• Process the refactored string at request time
• Add the refactored string to the translation table

The commonly accepted practice for tokens is to use a single word wrapped in curly brackets. I’d recommend this approach because translation strings are independent of any language limitations, it’s easy to do replacement in PHP. And if you need to use these translations in JavaScript then YUI’s YAHOO.lang.substitute() handles curly bracket replacement right out of the box. (The alternative is sprintf‘s %s syntax, but be careful if there are multiple tokens that could be in a different order to what you’d expect)

<?php
// Step 1: Refactor string
$pageNo = 6;
$pageMsg = "You are currently on page {page}";
echo $pageMsg;
?>

With this refactoring we are basically just echoing out a static string that’s sitting in a new variable. Between defining the variable and writing it out we need to add in some extra code to replace {page} with the actual page number:

<?php
// Step 2: Replace tokens
$pageMsg = "You are currently on page {page}";
$pageMsg = preg_replace('/{page}/', $pageNo, $pageMsg);
echo $pageMsg;
?>

The preg_replace looks for an occurrence of {page} and replaces it with the contents of the variable $pageNo.

Now we can treat the starting string as a static text string and add it to our translations array:

<?php
$translations = array(
	"pageMessage" => "You are currently on page {page}";
);
?>

And update our main code to reference this translation

<?php
// Step 3: Add to the translations dictionary
$pageMsg = $translations['pageMessage'];
$pageMsg = preg_replace('/{page}/', $pageNo, $pageMsg);
echo $pageMsg;
?>

The benefit of this approach is that the token can be anywhere in the string and now requires no code modifications if in one language the token needs to be somewhere other than at the end. We’ve removed the locale dependencies.

Grammatical differences

One of the difficult problems of creating text on the fly is grammatical differences between languages. We have to be careful where our code is implementing grammar rules. For example, here’s a PHP snippet that prints out the number of unread email items:

<?php
$unread = 2;
echo $unread, " unread email", ($unread==1)?'':'s';
?>

This just about works in English. But translating for a different locale we can’t assume the same grammar rules apply. Obviously pluralising a word isn’t as straightforward as adding the letter ‘s’ to the end.

This particular piece of code needs to be refactored to remove the grammar logic, and then it is in a state to be localised. The obvious first step, along with our text replacement token, is to remove the conditional logic and create two separate text strings:

<?php
$unread = 2;

// Select the right message
$unreadMsg = "{total} unread emails";
if ($unread==1) {
	$unreadMsg = "{total} unread email";
}

// Replace the token
$unreadMsg = preg_replace('/{total}/', $unread, $unreadMsg);

echo $unreadMsg;
?>

And we are back into the normal lines of replacing static text with a reference to a translation. (Although Polish pluralisation is more complicated, so would need more logic or perhaps a different approach – hat tip Brad).

String translation libraries

It becomes a little tedious to create a regex rule for every token that needs to be replaced. And there are classes or libraries to do this for just about any web-facing programming language. A very elegant solution is Ed Eliot’s PHP 5 text translation library.

Ed’s class gets the basics right:

• Translations are in a separate file, one per language
• Specifying the language code and it grabs the right translations file
• the Get method takes an array of token replacements, and applies them to the translations for you

Using images for buttons is nothing new. Accessibility wise, all you really need is some way of specifying a text-equivalent to the image, and you are essentially done.

The two main techniques of using imaged buttons are using the input type of image, or a button element styled with image replacement.

Typically the size of the image button comes directly from the design specification, which means that the text on the button has actually been a design decision, and the page design has taken that into consideration.

The result is a button that cannot be internationalised, for the following reasons:

• translating the button text means creating a new image for each translation
• the size of each image now has to change to accommodate the translated text.

There are two sane approaches to dealing with this situation, and it depends on the willingness of your designers to compromise in favour of international-friendly designs. But both solutions involve reimplementing the button markup, and if there are JavaScript event-handlers registered, there’s a strong possibility that these would need to be updated to take into account the changed markup.

The first solution is to get rid of the button image entirely, and use a proper submit input button. Then use CSS to style the button away from the default set into something closer to the original design, compromising the exacting details of text-shadows, rounded corners.

Designs that require a particular font, with specific kerning and other font metrics are unfit for internationalising websites, unless you can get your designer to guarantee that they will create and supply all the button images you need for every localisation from now on.

The second solution is to get the design team to create a tile-able button background big enough to cater for any reasonable width of text. Then using a sliding doors technique, a button element (or a cleverly marked-up submit button) can be styled to produce an elastic button background. All that’s left is to style the font of the real text as closely as reasonably possible to the original design specification.

By making the actual text back into real text your existing ways of translating text can be used, and localising forms becomes a matter of translations and other unique locale-specific requirements, not laboriously dealing with image manipulation.

Text inside images cause headaches in localising sites. It is far better to spend more time upfront coming up with a reasonable compromise that is based on text being real text, not an image.