internationalization in perl...

Daniel Pittman daniel at
Tue Nov 25 19:58:41 CST 2003

On Wed, 26 Nov 2003, gU5t4F wrote:


> Anyway, for my audacity in pointing out the flaws in their
> grand plan they have asked me to write a document describing
> exactly what needs to be done and how long it will take.

That will teach you to use your initiative. :)


> What are the steps that need to be taken to implement
> internationalization?

First, decide if what you really need is localization or

Most people and places don't seem to consider the difference, and they
*should* be tackled as distinct phases of the project, even if both are
done at the same time.

Also, consider your requirements: do you *really* need to support more
than one language at once?

Many projects and services don't actually need that, and it costs a
*lot* less to get a "German only" version of a product than a "German
and English" version...

Then, select your internal coding system (for i18n) or translation tool
(for l10n), and work out how that interfaces with your existing system.

Then, if the product is deployed, work out how you can divide it into
small segments where you can draw an "encoding boundary" around them.

Change each small segment, using a translating wrapper around the
outside, and get each part working before you pull the wrapper away and
let the i18n-ed or l10n-ed bits talk directly.

If it's not released, consider your timeline and see if you can release
a version without doing the inter-op stuff. Inter-op with pre-i18n seems
to double the time involved in a project, or more, in my experience.

Finally, don't forget that for either i18n or l10n, you need to pay the
piper ^W user interface designer to rework your layouts to fit
non-English text nicely on screen.

A number of scripts have expansion of between 25 and 50 percent over
English to express the same concept nicely, though good translators can
cut that.

Oh, and for l10n, don't forget to budget for people who *can* speak the
foreign language and the technical jargon, or for people to spend a
*long* time working with a technical translator...


> Are there any corners that can be cut by limiting the
> languages we support? (methinks not as i know we have to
> support chinese and japanese)

Why, yes. If you support only languages that work in the ISO-8859 space,
and a few others like Vietnamese, life is simple.

If you need to support the "Far East", life is hell. They bring in huge
problems, not least of which is that your UI becomes insanely complex.

It's usually less costly, as far as I know, to engineer a parallel line
of Far East code than retrofit it into an existing 8-bit encoding world.

Good luck. :)

Our quarrel with the world is an echo of the 
endless quarrel proceeding within us.
        -- Eric Hoffer

More information about the Melbourne-pm mailing list