[Owncloud] L10N and the way to translate

[Florian Rüchel]

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

this would mean any app developer should also create a translation for
his project on a site like transifex? Or deal with the above mentioned
problems?

>From your statement I read that the reason for the decision was then
that Transifex does not support such artifical strings?

Cheers,
Florian

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