[Phpmyadmin-devel] localization

[Marc Delisle]

Sebastian Mendel a écrit :
> Marc Delisle schrieb:
>> Sebastian Mendel a écrit :
>>> Marc Delisle schrieb:
>>>> Sebastian Mendel a écrit :
>>>>> Marc Delisle schrieb:
>>>>>> Sebastian Mendel a écrit :
>>>>>>> Hi,
>>>>>>>
>>>>>>> i know we discussed this already - but i will bring it up again
>>>>>>>
>>>>>>> currently any string needs to be in the locale files, even original english
>>>>>>>
>>>>>>> this makes it harder for external developers with own plugins - whether they
>>>>>>> completely ignore our string files or they need to put their strings into
>>>>>>> our locale files
>>>>>>>
>>>>>>> i think it would be nice to have a function for this - like many other project
>>>>>>>
>>>>>>> i would suggest something like:
>>>>>>>
>>>>>>> _('query executed successfully');
>>>>>>>
>>>>>>>
>>>>>>>  - at least an english message is always displayed, even if not defined in
>>>>>>> locale files
>>>>>>>
>>>>>>>  - we could better handle placeholders, escaping,
>>>>>>>
>>>>>>>
>>>>>>> _('query %1 executed successfully', $array_strings, 'html');
>>>>>>> _('query {1} executed successfully', $array_strings, 'js');
>>>>>>> _('query {{1}} executed successfully', $array_strings, 'plain');
>>>>>>>
>>>>>>> we could split up language files into different parts - no need to always
>>>>>>> load all lang strings
>>>>>>>
>>>>>>> we do not need to put english messages in foreign lang files if not translated
>>>>>>>
>>>>>>> we could easily apply filters if required
>>>>>>>
>>>>>>> $str* does not pollute global name space
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>> Sebastian,
>>>>>> please give an example of the new calling sequence in this snippet:
>>>>>>
>>>>>> if (PMA_PHP_INT_VERSION < 50200) {
>>>>>>      echo '<div class="warning">' . sprintf($strUpgrade, 'PHP', '5.2.0') 
>>>>>> . '</div>' . "\n";
>>>>>> }
>>>>> _('You should upgrade to {{1}} or newer.', 'html', 'PHP 5.2.0');
>>>>> or
>>>>> _('You should upgrade to {{1}} or newer.', 'html', array('PHP 5.2.0'));
>>>>>
>>>>> or with html as default third parameter
>>>>>
>>>>> _('You should upgrade to {{1}} or newer.', array('PHP 5.2.0'));
>>>>>   You <u>should</u> upgrade to "<strong>PHP 5.2.0</strong>" or newer.
>>>>>
>>>>> _('You should upgrade to {{1}} or newer.', array('PHP 5.2.0'), 'js');
>>>>>   You <u>should</u> upgrade to \"<strong>PHP 5.2.0</strong>\" or newer.
>>>>>
>>>>> _('You should upgrade to {{1}} or newer.', array('PHP 5.2.0'), 'plain');
>>>>>   You _should_ upgrade to "*PHP 5.2.0*" or newer.
>>>>>
>>>>> _('You should upgrade to {{1}} or newer.', array('PHP 5.2.0'), 'plain|js');
>>>>>   You _should_ upgrade to \"*PHP 5.2.0*\" or newer.
>>>>>
>>>>>
>>>>> or
>>>>>
>>>>> _('Upgrade to {{1}}.', 'html', array('PHP 5.2.0'));
>>>>>
>>>>> at least the shortest possible but still meaningful text
>>>>>
>>>>> at least for simple words and short terms
>>>>>
>>>>> longer texts, explanations, helptexts a.s.o. still could use some sort of
>>>>> abbrevation
>>>>>
>>>>> _('query_cache_size explanation.', 'html', array('PHP 5.2.0'));
>>>>>
>>>>>
>>>>> en-US.inc.php
>>>>> [You should upgrade to {{1}} or newer.]
>>>>> You [u]should[/u] upgrade to "[b]{{1}}[/b]" or newer.
>>>>> ...
>>>>>
>>>>> de-DE.inc.php
>>>>> [You should upgrade to {{1}} or newer.]
>>>>> Sie [u]sollten[/u] auf "[b]{{1}}[/b]" oder neuer umsteigen.
>>>>> ...
>>>>>
>>>>>
>>>>> an optional call to PMA_lang_setContext() could be used for ambiguous words
>>>>> or as an additional parameter to _()
>>>>>
>>>>>
>>>>>
>>>>> gettext is also widely used tool for translation
>>>>>
>>>>> http://www.debian.org/doc/manuals/intro-i18n/ch-library.en.html#s-gettext
>>>>>
>>>>> (even in PHP)
>>>>>
>>>>> http://php.net/gettext
>>>>> http://pear.php.net/package/Translation2
>>>>> http://php-flp.sourceforge.net/getting_started_english.htm
>>>>>
>>>> So, we define a _() function which calls gettext functions which find 
>>>> the proper string, and displays the one in English if not found in the 
>>>> current language?
>>>>
>>>> But how do we specify which splitted file to use?
>>>>
>>>> And how do we decide how many splitted files there will be? Some are 
>>>> easy to decide, for example all the $strPriv messages, but others are 
>>>> used by more that one sub-system of PMA"
>>> splitting files was only one point - but does not imply that we should split
>>> files if not necessary - i did not check how much improvement this could give
>> I think speed improvements would not be noticeable.
>>
>> On the other hand, I don't know about the speed of this _() function. 
>> Does it have to open the lang file -- possibly two files -- for each 
>> message to display?
>>
>>> if we split, we could make some specific files and a generic file
>>>
>>> and it does not hurt to have some strings in more than one specific file -
>>> if required and gives any advantage
>> As a translator I would not like having a string in more than one file; 
>> in fact I would prefer just one file.
> 
> as a translater ... wouldn't hurt me ... ;-)
> 
> 
Ok let's see eventually if there are advantages.

On the other hand, I don't know about the speed of this _() function.
Does it have to open the lang file -- possibly two files -- for each
message to display?