I am taking a punt that this question lives best here in General Dev rather than Languages, but happy to move it if that's the consensus.
I have a bi-lingual site, where I have rewritten the Core /user/edit.php page (for "reasons" - yes, I am aware of the auth plugin overrides, but we migrate users from one auth type to another during this process and have a whole other bunch of workflow requirements which meant this seemed to be the best way to handle it.)
All seems to be well with the edit user functionality, however my custom edit page seems (unlikely as it sounds) to have broken the language menu. Users who log on to the site, which uses Essential and is on a 2.9 version that can't immediately be upgraded, can change their language using the standard Language menu in the header. This works fine, until they visit my /user/edit.php page, at which point, they can no longer change their language whether on this page or any subsequent page. The page reloads, with the ?lang=xx option on the end of the url, but the page is still in English. If I have switched language *before* going into /user/edit.php, then the page displays in the other language correctly.
I am not explicitly trapping the optional_param('lang') and doing anything with it, but then, nor is the original page on which I based my changes.
Well, this is now solved:
* As part of this custom form, I extract the values from custom user profile fields, many of which are defined with multilang values.
* These values need to be processed in order to ensure that the key is the english value, regardless of the language of the value.
* In doing this, I'm using force_current_language('en') to ensure I get the key in english, then doing force_current_language($prevlang) to put it back.
Something something something, force_current_language('') instead of ($prevlang), profit.