Hi Yannick,
Ever since the initial translation tool was written, considerable
improvements were added to Chamilo 2 to tackle exactly this kind of
problem. There are no doubt still quite a few variables that don't
adhere to these "rules", but the infrastructure is definitely there to
allow it. Just a matter of consistently rolling it out everywhere. As a
general rule of thumb I'd say PHP-concatenated language-like strings are
evel and should be avoided whenever possible.
Best regards,
Hans
On 04/05/2011 21:58, Yannick Warnier wrote:
Hi all,
I suppose here should still be the better place to mention this. I have
tried, some time ago, to start structuring the language translation
process for Chamilo. The first and second (and only) chapters are
available here:
http://beeznest.wordpress.com/2010/04/09/translating-web-applications-lesson-1-string-identifiers/
http://beeznest.wordpress.com/2010/04/18/translating-web-applications-%
E2%80%93-lesson-2-include-punctuation/
These might be obvious to some of you, but I'm pretty sure about half of
us can still be surprised by the problems exposed.
But the point I want to make here is from the second chapter: language
translation can only be used well when it includes punctuation.
Why's that?
Not all languages work the same way ours do. The Arab language is known
for being written from right to left. The Japanese language is known for
using another kind of "dot" sign than we do.
If you give a string to be translated, say, of "This action cannot be
taken here" and you want to make this part re-usable in a similar
context where you append "Instead, you can do ABC", then you will
definitely have to put a dot in the middle.
Developers generally do that by using the programmatic form:
echo $language_variable1.'. '.$language_variable2;
However, put in the context of the Japanese language, you would have an
incorrect translation, because it should read:
echo $language_variable1.'。 '.$language_variable2;
See the other "dot" symbol? In some cases, you won't have the dot symbol
at all in Japanese, because the syllable "カ" (ka) marks a question
mark.
So in fact, the language variable should always include punctuation
(even when not absolutely necessary).
The Arabic form brings another problem in the same context:
echo $language_variable1.'. '.$language_variable2;
... would in fact have to be written ...
echo $language_variable2.' .'.$language_variable1;
Thanks to CSS, some minor elements of that problem go away, but you
still have the problem of ordering your sentence.
This is why all complete phrases should be translated entirely, even if
it means repeating some elements.
Also, when including a variable part into a translated sentence (like
"You have saved 46 items.", you should always register the phrase
entirely and include the variable part as a token, like so:
$lang_variable3 = "You have saved %d items.". This "%d" symbol (%s in
case of alphabetical string) should be replaced (I believe it is
already) by the Chamilo 2 translations system.
I'm making this point now because I'm seeing a few Chamilo 2.0 strings
in translate.chamilo.org from time to time and I'm a bit scared of
having to pass through all the translations again once we start
translating to Arabic or Japanese. It is very difficult to roll-out a
new version of language strings once it has already been translated into
several languages, so it generally generates bad quality automated
translations that we don't want to happen to any open-source software.
Yannick
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
--
*Hans De Bisschop*
Hoofddeskundige ICTO | Lead Developer Chamilo 2.0
Software Coordinator Chamilo Association
Erasmushogeschool Brussel
Nijverheidskaai 170 | B-1070 Brussel
T 02 559 02 54 | i 254
hans.de.bissc...@ehb.be <mailto:hans.de.bissc...@ehb.be> |
www.erasmushogeschool.be <http://www.erasmushogeschool.be/>
Kom eens langs: www.erasmushogeschool.be/infodagen
<http://www.erasmushogeschool.be/infodagen>
of lees onze elektronische nieuwsbrief: ehbrief.ehb.be
<http://ehbrief.ehb.be/>
P Before printing, think about the environment
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
