[Owncloud] L10N and the way to translate

[Florian Rüchel]

On the subject of how we translate string in ownCloud. I couldn't find a
lot of discussion on this subject and since I just joined in ownCloud, I
hope I can get some feedback on the reasons why certain decisions were made.

First off all, I come from Joomla and my main experience originates from
here. I have worked with other CMS in PHP but most of what I will state
is based on the Joomla practices.

The ownCloud way: As you all know, ownCloud translates by using an array
called $TRANSLATIONS and calls it via the language interfaces
t()-function. The general practice (at least in all the code I found),
was to use the english text as the key for all languages.

The Joomla way: Joomla offers a static function (which internally also
calls a language-instance) to translate strings. In Joomla the general
practice is to use a describing string like COM_CONTENT_ARTICLE_TITLE
which would then be translated to the current language. All strings are
defined in a language-ini file which is read by the PHP-parser.

Now here comes my opinion:
I have a hard with one language being the key for another. I imagine
wanting to change that string. I would have to change it in *every*
lang-file. Of course, I can accomplish that with scripts and such, but
it strikes my as no good practice.

So the first point would be: Why not use artificial strings like in
Joomla for translation. One note on the Joomla practice. Even in Joomla
I could call something like JText::_("No calendars found."); to
translate my string. Joomla would convert it to "NO_CALENDARS_FOUND"
(not sure about the full stop here), which means you only need to create
a string for the english language once you want to change that string.
Still not the best practice, but it would help keeping a system where
you save a translation file for english.
I am not sure if this would be possible in ownCloud, I have to dig
further into the code to see whether it accepts an english translation file.

The other (and minor) point is the way the strings are kept in an array:
It is only somewhat of a feeling that I can't quite describe. Having a
language file with ini-Syntax seems a lot more clean to me. You save the
work before and after the strings (like "<?php $TRANSLATIONS = array("
and such and save yourself the trouble of the complicated assignment via
"=>" and ",". Instead you just put each language string in one line with
a syntax like
LANG_STRING="Translated text". The only downside here is if you want to
include the " character, you have to find a way. The joomla approach is
to put _QQ_ instead of ".


As soon as I have more room and have dug further into the core code, I
will write this style of handling the language, because I really prefer
it. I just want to hear your opinions on whether I will keep this to my
apps or there is an option to get it into the core at some time (in
which case I will integrate it into my core and provide you with the
sources).

I am looking forward to hearing your opinions and especially to learn
about the reasons behind the decision of your approach.

Cheers,
javex