Re: [Phpwebsite-developers] Re: the last crusade (is: Re: One among many)

[Philip M. <lis...@li...>]

I hope you don't mind me throwing my 2p in here, but the subject of
localisation is one that has been a major part of my career for the last 2
years.

This mail is not intended to sway you one way or the other, but I guess,
just to reassure you that any localisation effort runs into exactly the same
problems and other people have "been there before" :-)

As you no doubt know by now, localisation is never an easy task and there is
never one 'catch all' solution that caters for all situations, most often it
is a matter or compromise.

As a quick background on my experience in localisation:

I work for a B2B ASP providing ticketing software in 8 different languages
to a global audience.

The previous version of our software used a build-time translation system
only. The current version uses run-time translation combined with
user-configured, multilingual text.

The software provides the facility to change the language of the front-end
at any time during the purchase process.


Obviously, localisation incorporates more than just translations and we
regularly have to deal with different timezones and currency issues. I skim
over these as I don't think them relevant to phpWS.

The number of distinct phrases within our application is now within the
order of tens of thousands This affected our choice of how to deal with
translation.

We use a combination of translation agencies and in-house translation staff
to deal with translating the phrases, and the phrases are provided in the
form of a CSV file of the format:

placeholder,language_code,Phrase to translate,Context of the phrase.

'placeholder' is our system code for the text, and our pages have
translatable placeholders in them rather than English. Not so far removed
from phpWS, and pretty much the standard way of localising a product :-)

'language_code' is the language the phrase is in, be it en_GB es_ES, nl_NL,
pt_PR etc.

'Phrase to translate' is pretty self-explanatory.

'Context of the phrase' is important to translators as it gives them an
indication of the use of a phrase within the system.

e.g. The phrase 'Your account' comes with an attached context of 'This text
is a link. The user can click on this link to access their previous purchase
history, billing details and contact details.' It just helps to pin the
phrase down for accurate translation :-)

This allows us to:

* Split out translations for each language code
* Retain the placeholder -> phrase mapping
* Give the translator both the phrase to translate and the context of that
phrase.

We did toy around with other ideas for translation systems, but these were
ditched due to time constraints.

The best all-round idea that we came up with was to create a new user-level
for a translator.

This translator user would be shown the same interface as a normal user, but
as well as having the text in the right places in the interface, would be
presented with text boxes (alongside or below the translatable text) to
allow them to translate the phrase directly on the page, thus allowing the
translator to view the context of that phrase in-situ.

This is, however, not an easy feat. The best compromise is to try and give a
context for the phrase so that it can be accurately translated. :-)

IMHO, I agree with Brian that a build-time translation system is much more
suited to the needs of phpWS since there is no perceived need to change
languages on the fly.

However, I would also like to see a system where the admin could change the
wording of phrases within the user-facing portion of phpWS. I.e. the ability
to change the wording of 'Main Menu' or the 'sign up now' wording to suit
their needs, without having to hack the code directly. This could be done
with an include file...

There is no reason why this has to be run-time either. There is nothing to
stop someone setting up an online phpWS translation tool where any user can
alter the phrasing of a base language file to suit their needs, and then
download the result to plug into their system.

Finally, the result of spending 1/4 of my work time for the last 2 years on
product localisation has taught me that there are only 2 ways to release
apps in multi-lingual form:

1) Release the default language ahead of the others and then release the
translated versions when the translations are in.

2) Create a code-freeze deadline and have the phrases translated while the
software is in the testing phase, then release all languages simultaneously.

Case 1 allows development to continue regardless of the state of other
localised releases, while case 2 ties the development schedule into
translation deadlines but results in a better overall product.

I sincerely hope I didn't sound as if I was on a high horse here, and it was
not my intention to step on anyone's toes. I just thought you might like
some reassurance that localisation is a common and ongoing problem. With the
Web being global, respect is rightfully deserved by those that realise this
and work towards global solutions :-)

Regards, Phil
--
Philip McAllister
ph...@li...
"All I ask is the chance to prove that money can't make me happy." - Spike
Milligan