idi527
Copy of Using cldr with liveview · Issue #134 · elixir-cldr/cldr · GitHub
What’s the recommended way to use cldr / gettext with a liveview app? Right now I’m passign the locale into the session with Cldr.Plug.SetLocale plug and then set the locale again in the liveview’s mount/3 callback:
# in the router
plug Cldr.Plug.SetLocale,
apps: [:cldr, :gettext],
cldr: App.Cldr,
from: [:query, :accept_language]
plug :put_locale_into_session
@doc false
def put_locale_into_session(conn, _opts) do
%Cldr.LanguageTag{cldr_locale_name: locale} = conn.private.cldr_locale
put_session(conn, "locale", locale)
end
live "/some_live_path", AppLive
# in the live view
def mount(_params, %{"locale" => locale}, socket) do
App.Cldr.put_locale(locale)
# ...
end
because otherwise it doesn’t seem to work correctly with the locales being different in the ssr’ed page and when the live view mounts: in ssr the locale is correct (e.g. en):
%Cldr.LanguageTag{
canonical_locale_name: "en-Latn-US",
cldr_locale_name: "en",
extensions: %{},
gettext_locale_name: "en",
language: "en",
language_subtags: [],
language_variant: nil,
locale: %{},
private_use: [],
rbnf_locale_name: "en",
requested_locale_name: "en",
script: "Latn",
territory: "US",
transform: %{}
}
but then in live view it becomes en-001 (the default):
%Cldr.LanguageTag{
canonical_locale_name: "en-Latn-001",
cldr_locale_name: "en-001",
extensions: %{},
gettext_locale_name: nil,
language: "en",
language_subtags: [],
language_variant: nil,
locale: %{},
private_use: [],
rbnf_locale_name: "en",
requested_locale_name: "en-001",
script: "Latn",
territory: "001",
transform: %{}
}
So I wonder if anyone has used liveview cldr and how they resolved this problem and if there’s a less repetitive approach (something like plug macro would be great).
Trending in Questions
I’m working on a project that simulates the bumbl example in the programming phoenix book. It acts almost like an email client. We have a...
New
Hello,
I know there is an approach for handling lists that allows for optimized traversal, but I can’t recall the specific method (somet...
New
Hi everyone,
I am toying with the idea of building a “match maker” for giving personal help to people that wants to start coding.
I sta...
New
Documentation
While reading the Scoped Routes section, I noticed that the documentation currently refers to a problem without explainin...
New
So my question is quite simple and i have found no conclusive answer on forum, google or AI.
Should we use :erlang.float for Integer to ...
New
I recently noticed that Elixir’s Logger defaults its primary log level to :debug when no :logger, :level application configuration is pre...
New
Hi, I’ve just set up an application with ash_authentication. There is only magic link strategy for now, so there is no confirmation add o...
New
Other Trending Topics
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
I am happy to introduce the very α version of the new programming language compiled to BEAM.
Welcome Cure.
It has literally three kille...
New
Hi there! We created Gust: A task orchestrator inspired by Airflow.
For those who have never heard about Aiflow, it’s a Python-based wor...
New
Hi everyone!
The first release candidate for the Expert language server project is now available!
We’ve published a press release detai...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #security










Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
outlog
shipped first production liveview last week - I ended up wrapping everything in a liveview that holds state with locale etc - and then render pages (liveview components) depending on the action - so it’s kinda a router as well…
to make matters interesting it’s cookieless - so no passing the locale in the session.. had to do:
in my custom plug:
%{req_headers: req_headers} = conn
browser_accept_lang is the browser locale - conn_lang could be different if the user is on /:locale/some_page - the diff is needed to conditionally rewrite uris with /:locale
then in root template: (remember we have no session to pass things through easily)
in the liveview: so that the initial render is in correct lang - and then socket connects with locale params, so we also have them on “the socket” - see below:
in the js:
sfusato
Putting the locale in the session and later retrieving it in mount from the session works fine for me.
In the cookieless case, an option could also be using the
uriinhandle_paramsif your paths are localised:/en/something&/fr/...and extract it from there.Or, passing it from the client-side using
get_connect_paramsshould work as well, I suppose, though I haven’t tried it.One thing I’ve noticed is that if you are using
live_patchto change the locale,handle_paramswill be called as per the flow, you retrieve the new locale,Gettext.put_localeetc., but yourgettextcalls won’t get re-rendered and diff’ed unless you forcefully track them. I do it like this for the moment:@locale && gettext('text to translate').kip
This is likely a side effect of liveviews being separate processes.
Cldr.Plug.SetLocalesets the locale for the current process which, for a non-liveview request, is the process that executes the controller code.Therefore, as @idi527 is doing, the idea of setting the locale for the liveview process in the
mount/3call seems one way to do it. Or more functionally, add the locale tosocket.private.assignand use it directly.I haven’t dived into liveview yet so anyone willing to partner with me on this, please let me know?
@whatyouhide, do you have some thoughts on how to apply the locale of the original HTTP request to a liveview context - I think this conversation relates to Gettext in the same way.
kip
I think this is probably the right approach. Then perhaps its as simple as:
Again, not something I’ve dived into yet so guidance definitely appreciated - I’m all in to make this as simple as possible.
chrismccord
Folks have already well covered the options here with great advice. I wanted to point our that LV master here has a small section in the docs:
kip
Thanks Chris, glad we’re on the right track. I think I’ll add a helper to
ex_cldrto make it easy to leverage the session in this way for liveview (since in the case ofex_cldrthe locale it ultimately a struct and therefore some key munging will be required).idi527
The problem with this approach is that
put_localehas then to be called in each live view mount which is what I’m trying to avoid in OP.kip
Since each cldr function takes a
:localeparameter its not (and actually never) a requirement to useCldr.put_locale/2. So as long as the locale is put in the session and/or the socket, it’s still available for use - but you would need to add thelocale: localeoption toMyApp.Cldr.Number.to_string/2or other calls.idi527
This seems like duplication as well …
josevalim
There is no other option.
The docs linked by Chris also suggests a shared helper to be invoked on every LiveView, which is the approach I am also going with.