[Owncloud] L10N and the way to translate

[Florian Hülsmann]

Hi Florian,

The point is...

 > 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,

we wouldn't have to. AFAIK everything's done by Transifex's "tx" tool 
and translation strings are managed on the web.

Cheers,

Florian (huh^^)

Am 28.05.2012 01:11, schrieb 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
> _______________________________________________
> Owncloud mailing list
> Owncloud at kde.org
> https://mail.kde.org/mailman/listinfo/owncloud

-- 
Florian Hülsmann
<fh at cbix.de>
http://cbix.de