I have done a few websites and applications with support for multiple languages where I’ve used language xml files and a keyword inside my code. For my web app, I believe that method sucks. I love to read and understand my HTML code. This code doesn’t make any sense:
<h1><?= translate('main_headline'); ?></h1>
It looks good at the beginning but just ends up with unhappy programmers since the process of adding new features now requires putting stuff in XMLs all the time.
My solution (I just wrote a simple test PHP parser an hour ago, do you think this will work on a large scale project?)
I’m using english as my base language and this is how my source file looks:
<h1>{{ I love colors }}</h1>
My parser will use the text (a real text) as the key for a dictionary array. In this example, I’m translating from US english to UK english.
$dictionary['I love colors']['en_GB'] = 'I love colours'
No dictionary is required for my base language since it’s already in the source file.
There is a lot more to it like cache, fallbacks, dictionary storage etc. Do you think it will work in a large scale projects? It there something I haven’t considered?
One flaw with this is that two different parts of the application may require different translations for the same word/phrase. The most obvious example is a homograph, e.g. “close” (nearby) and “close (shut), but there are other possibilities too.
A contrived phrase example is:
In one part, “I love my colors” just refers to literal colors.
In another, it means “I love my flag”
Should:
be “Me encantan mis colores” or “Me encanta mi bandera”. It has to somehow be both.
That is why either a unique ID or line number is typically used in the message catalog.