Language settings: custom user setting doesn't override default system one.. everywhere

[vdobrev]

Ok, my setup is as follows:

• 2 languages: 'english' and 'bulgarian'
• default config setting is 'english'
• custom user setting is 'bulgarian'

Once user logs to the admin

• the system language is used for the general texts (english\application_lang.php)
• the custom language is used for custom models and profiler (bulgarian\profiler_lang.php)

I believe the idea is to change language althogether, now all my contexts and system messages are still in english, and yes, i can make the default setting to 'bulgarian', but then my 'english' users will be seeing the contexts and system texts in 'bulgarian'..

see below the files loaded log from profiler:

application\config\application.php application\config\autoload.php application\config\config.php ... application\language\english\application_lang.php ... application\modules\operators\language\bulgarian\operators_lang.php application\modules\operators\language\english\operators_lang.php ... bonfire\codeigniter\language\bulgarian\profiler_lang.php bonfire\codeigniter\language\english\profiler_lang.php ... bonfire\modules\users\language\english\users_lang.php bonfire\modules\users\libraries\auth.php bonfire\modules\users\models\user_model.php index.php themes\admin\index.php themes\admin\partials_footer.php themes\admin\partials_header.php

[mwhitneysdsu]

Do you have complete language files in the following locations?

/application/language/bulgarian/application_lang.php /application/language/bulgarian/datatable_lang.php /bonfire/codeigniter/language/bulgarian/_lang.php /bonfire/modules//language/bulgarian/*_lang.php

I'm not particularly surprised to see that there may be an issue with this, I just want to make sure that the language set you're using is as complete as possible before looking for other potential causes.

If possible, maybe you could submit a pull request with the language files. Then I could setup a user with the same language in my development environment and get a better idea of what you're seeing. For now, I'll see if I can replicate the issue with one of the other languages.

[vdobrev]

Yes, all files are present and you can actually see it with available files also... I did a clean install of Bonfire-develop and just changed the user language setting to Portuguese, only to find out the same issue - the application_lang was still loaded from the English folder.. And you can then change config to load Portuguese, while you switch back your user to English.. the result is attached ;) And you can confirm that in <5min.. so I'd really appreciate you looking into this, thanks in advance!

bonfire_dev-langs-issue

[mwhitneysdsu]

The non-English files are definitely not complete in Bonfire-develop (I'm not sure when they could have last been considered complete), though the French and Brazilian Portuguese are likely closest to complete. This is what gives the odd mix of English and Portuguese when using the (non-Brazillian) Portuguese on the User Profile. (Account Details, Display Name, Language, Timezone, and the Reports context are all missing from the Portuguese language file).

In previous versions of Bonfire, all of those missing items would have been broken in one way or another, sometimes leading to errors. One of the changes in 0.7 was to fall back if the line wasn't found in the current language. I'm not familiar with the details at the moment, but this usually leads to missing language items being loaded from the English files.

Further, some areas need some definite improvement in this area. I'm not even sure if the "User successfully updated" message is pulled from a language file, for instance.

[mwhitneysdsu]

Another item I just noticed: there are some instances where a template message will be set with one language while the page itself uses another language when switching user languages. My best initial guess on this would be that the new language file is loaded after the template message is set. I specifically noticed this on the /users/profile page of an English site switching a user between English, Portuguese, and Persian languages, in that order. "Profile successfully updated" is displayed on each change, until I switch away from Persian (back to English), at which point I get "مشخصات با موفقیت به روز رسانی شد."

In all cases, though, the fields on the user profile matched the language currently set for the user, with the exception that fields that didn't exist in the Portuguese file were pulled from the English file.

I also find it somewhat interesting that the language dropdown itself is always in English.

[vdobrev]

If you have to consider just one simple check: the name of the Content context - $lang['bf_context_content'] is available and translated in Portuguese, yet it doesn't show as defined in \application\language\portuguese\application_lang.php => "Conteudo", but rather stays with its default english text, which can only mean that the user defined language is simply not loaded (as it's also not on the profiler list)..

[vdobrev]

Furthermore, I now believe the issue is limited only to the application_lang.php (or just the \application\language\ folder), as all other modules load fine..

[mwhitneysdsu]

I owe you an apology on this one. Apparently my dev environment is out of step in relation to this particular problem (which may help me solve it if I can figure out what's different). I setup a test environment that exhibits the problem pretty much as you've described it. At the moment I'm using Persian to compare the environments, because it is not only fairly complete, it appears there's a related problem with handling right-to-left languages properly. At first I thought the users module might also be messed up, but most of the language values used on the user profile are in the application_lang.php file as well (rather than the users module's language file).

[mwhitneysdsu]

The fix in 665b4af appears to fix the obvious issues on my end, please let me know if it takes care of it on your end as well. If you just want to make a quick change in your environment to see if it works, you can edit /application/core/Authenticated_Controller.php to change the beginning of the __construct() function from this:

public function __construct()
{
        parent::__construct();

        $this->load->library('users/auth');

        // Make sure we're logged in.
        $this->auth->restrict();

        $this->set_current_user();

to this:

public function __construct()
{
        $this->load->library('users/auth');

        parent::__construct();

        // Make sure we're logged in.
        $this->auth->restrict();

        //$this->set_current_user();

[sourcejedi]

Good debugging! $autoload['language'] won't work for the same reason :-), it should probably be marked as unsupported in config/autoload.php. Blame CI.

If you want to favor correctness over speed - you could move everything from Authenticated_Controller to Base_Controller. (All except the auth->restrict()). If it needs optimizing at some point, make it an option when calling the constructor. If it means too much unused PHP code on front-end pages, move it to a library (presumably auth).

[vdobrev]

Great job figuring that out, Mat! I can confirm that fixed it on my end also.. thanks again!