Choose language via GUI

[GoogleCodeExporter]

Currently, the language can only be chosen via config-directive $language.
In an environment with multiple users with different mother tongues, it might 
be useful to choose the language when logging in or even after being logged in.

Original issue reported on code.google.com by crazy4ch...@gmail.com on 16 Apr 2013 at 11:56

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

in my opinion it mach better choose the language in automatic way.

I'd change (at row 414): 

if($language != 'en') {
    if(is_file('languages/lang_'.$language.'.php'))
        include('languages/lang_'.$language.'.php');
    elseif(is_file('lang_'.$language.'.php'))
        include('lang_'.$language.'.php');
}
WITH:

if(substr($_SERVER['HTTP_ACCEPT_LANGUAGE'], 0, 2) != 'en') {
    $language=substr($_SERVER['HTTP_ACCEPT_LANGUAGE'], 0, 2);
    if(is_file('languages/lang_'.$language.'.php'))
        include('languages/lang_'.$language.'.php');
    elseif(is_file('lang_'.$language.'.php'))
        include('lang_'.$language.'.php');
}
THIS WAY YOU CHECK YOUR FAVORITE LANGUAGE, IF THERE IS THE TRANSLATION FILE IT 
WILL BE LOADED. OTHERWISE IT WILL REMAIN "en" as default language.

In this case we can remove the $language variable both from 
phpliteadmin.config.php and row 55.

Of course $_SERVER['HTTP_ACCEPT_LANGUAGE'] can check desiderate languages and 
dialects as well (es en-us en-ca it-IT)  with priority for each one . But at 
present time the script don't support the dialecs.

I would introduce dialecs.

Finally we can consider another strategy:
Setup \\$language as undefined. This way we can primary check the favorite 
language (by $_SERVER['HTTP_ACCEPT_LANGUAGE']). But if $language is definied 
(and that laguage is avalible) we can force the script to use it. It will 
necessary very few php code for this.

What about?

(PS SORRY FOR MY ENGLISH) 

Original comment by franco7t...@gmail.com on 26 Apr 2013 at 1:17

[GoogleCodeExporter]

I agree automatically detecting the language would be nice. But still I would 
give the user the possibility to choose another language. Assume you are on 
holiday in some other country and use a computer there and it sets some 
language in HTTP_ACCEPT_LANGUAGE that you don't speak. You'd like to change the 
language.

So what I would propose:
1. If there is a language file for the language set in HTTP_ACCEPT_LANGUAGE, us 
this
2. If there is no file for the language set in http, use the default language 
as defined in $language (if this does not exist, use English)
3. The user can still choose another language at any time. If he does, store 
this language into a cookie and use this from now on.

Regarding dialects: As long as there are no translations for dialects, we don't 
need to support them. And I don't expect them to come too soon.

As far as I know, in HTTP_ACCEPT_LANGUAGE you can give multiple languages. So 
we should not only check the first. If we don't have a file for the first one, 
we should continue with the next one.

Also we need to be careful with HTTP_ACCEPT_LANGUAGE as it is user-input. You 
only use the first 2 characters, so I currently can't think of a way to exploit 
this. Stuff like '/.' could end up here, but would not hurt much. But we need 
to be aware that this is user input and might be malicious.

Original comment by crazy4ch...@gmail.com on 26 Apr 2013 at 1:48