Say you have a board with other language packs installed, for example, Spanish.

Then you have some extensions installed. Some have the Spanish pack, but some only have English.

Well, the way add_lang_ext() and set_lang() work in the user class, when the extensions without the Spanish pack are loaded, they cause the $user->lang_name to be switched to the $config['default_lang'] and that persists.

Meaning that $user->lang_name will remain English.

So the Spanish capable extensions will appear in English, even though the user may be have set Spanish for their board preference. This effectively breaks the multi-lingual capabilities of the extensions system. It only takes one extension that does not have the user's set language included with it, to cause all extensions to default to English (or the board default lang)

The problem is occurring due to line 621-647 in the user class, where if a language file isn't found, revert to english.

Somehow, the $user->lang_name needs to be given back the $user->data['lang_name'] at the right time so extensions with the optional language load in that language, and extensions that do not have it load in the correct fallback language.