General developer forum

Users can't change language on my custom form page

 
Picture of Martin Greenaway
Users can't change language on my custom form page
 

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.

 
Average of ratings: -
Picture of Martin Greenaway
Re: Users can't change language on my custom form page
 

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.

 
Average of ratings: -