I am building a language switcher (“en”, “de”, “fr”, etc. select input box) of my website;
when user first access, I detemine their accept-language from request headers, and set it in current user’s session; the user may be guest/annonymous so they have no backend data records;
Then currrent user may switch to other prefer language; (!! inside liveview I have no ability to persist this changed state into session and cookie! and I think update to url query params is not elegant so I donot consider of that way)
Depends on the language we render corresponses content to user;
But when user navigate to other liveview, or refresh page, or “duplicate tab page” in their browser, we still offer the default detected language/content but not user prefer language/content, that’s not user expected.
so , do you have any advices? Thanks !
If you want to use cookies, just use a controller action to set it and redirect back to the liveview. Sure it’s a page reload but it’s not like they’ll be switching constantly.
What do you mean it doesn’t come with request?
You can read/write to the storage with a simple hook.
If it is a guest read/write from Local Storage, if the user upgrades to a DB backed account, you can read the local storage and store it in the DB, henceforth just give priority to the DB.
You can choose the sessionStorage or the localStorage if you want to persist after the tab closes.
I had never know that… after read that article, yes, it is a better approach ! thank you for share it ! Just a litter cons, it relied on client side javascript, … I have to reconsider my actual needs.
There is no problem relying on the client for things like this. There is no data privacy involved nor much complexity added. Embrace JS when you have to.
I agree with this sentiment 100%, but I gotta ask: why is this better in this situation than using a controller? (…other than a page refresh, of course.) If the translation is done on the backend, a JS hook means there will be a jump between default and selected languages when the websocket upgrades. At least this is the problem I’ve run into when using localStorage for stuff like this. You can skip the dead render but since OP’s situation involves guest users that don’t have db entries, I assume these are public pages so you’d want to keep it.
The controller version is also much simpler. The whole thing is:
defmodule LangController do
use Phoenix.Controller
def update(conn, params) do
conn
|> put_session(:language, params["lang"])
|> redirect(to: params["return_to"])
end
end
# router
post "/set-language", LangController, :update
# heex
<form action={~p"/set-language"} method="post">
<input type="hidden" name="return_to" value={~p"/current-url"} />
<select name="lang">
<option>...</option>
</select
</form>
# lv
def mount(_params, %{"lang" => lang}, socket) do
# ...
end
Am I missing something?
Also, I do agree that it’s generally better to put it in the URL, especially if URLs are meant to be shared (if it’s a closed app it’s not as big of a deal). There are libraries to help with this, like cldr_routes and the newer routex.
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.
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 ?
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.
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.
