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.
Question: What is it that normally traps the 'lang' url parameter from the language menu and does something with it? Is it the renderer, or one of the includes, or something buried deep in the bowels of the system? I've never had to worry about this before, it's always just *worked*, but I've clearly broken something somehow and in the absence of any Javascript errors in the browser console, or any debug errors in the Apache log, I'm a bit stumped.