Not missing anything, that is actually what I do on the app where I have multi-language support. 
I extract the language from several places, prioritising the URL query parameter, then session, headers, (etc…) and as last resort the localStorage.
greven
2
sodapopcan
Ya, the stuff under the line in my response was supposed to signify the end of the response specifically to you 
Although really the whole response is an open question. I’ve found localStorage really annoying for these types of things—as mentioned by Koko, it’s good if it’s client-side only as it’s simple, otherwise you need to do the extra ceremony to ensure a non-janky experience.
1
longnightElixir
For not to lose (logined ) user’s unsaved input and page position, in my opinion, we should avoid page reload as possible as we can; ideally, when user changed their prefer GUI language, lead to GUI display content change only.
So I’m also considering through a controller as you said, but instead, we emit the request by a XMLHttpRequest from javascript. But this approach brings in another problem: the session updated thing do not triggle current (user’s staying ) liveview update, I may have to place a handle_event to do that, in every liveview; What do you think about this way ?
0
sodapopcan
It’s of course totally up to you how you want to do it, I mostly added my second for others who might find this thread.
I don’t know your specific application’s needs, but it’s generally advised to keep things as simple as possible. I certainly understanding thinking of every edge case, but when it comes to changing languages, most people are only going to pick once and be done with it. I wouldn’t worry about things like form state because who is going to start filling out a form in a language they don’t understand then switch their language half-way through? Again, I’m speaking generally and don’t know your application’s needs, perhaps this is a real use-case for you.
I’m having trouble finding it but people were talking here recently about a workaround to setting session data over LiveViews. I’m not sure if it actually works yet or needs an update to the framework first. The problem is that not being able to set session data over websockets is a limitation of websockets itself. With what you’re suggesting, you would need to be able to send the LiveView’s PID along with the request so the controller could message it back with the new lang (after storing the language in the session) via handle_info where you could re-fetch the page’s data. Perhaps you can find the thread or someone else could speak to if this is possible or not, but it seems like a lot of ceremony and localStorage is probably the better option for you (for now, at least). Or see if you can find that thread. It was this year I’m pretty sure.
2