I looked up the Ticket after I found this thread and found an interesting answer, that6 dynamic language switching at runtime seem to be possible since the total switch to Ivy:
referring to the answer of petebacondarwin
https://github.com/angular/angular/issues/38953#issuecomment-862492065
Later a discussion is held over some problems but in general it should work
That is great feedback, thank you @napei. I am pleased to say that many of your points are actually supported (if not well documented) by the built-in i18n now:
dynamic locale switching (of course)
Indeed this will not be supported natively in Angular.
one build output, many languages (faster build times)
This is now the default for i18n since Ivy
JSON language files. I had a hard time getting used to XLIFF and making i18n tools work with it, I also confused other people that worked with me with XLIFF as its not necessarily the prettiest thing. JSON also integrates much nicer with external tools (when I started using it I chose to deploy weblate)
Built-in i18n now supports consuming and extracting to two JSON formats: a simple key-value one, and the slightly more sophisticated ARB format.
I can get translation data from inside TS which helps for stuff like dynamic buttons or other messages. I've since moved away from putting strings in TS but it was a thing I could do, so I used it.
Since Ivy this is also now supported in the form of static backtick strings that are "tagged" with $localize.
Lazy-loading translations along with lazy-loaded routes. Completely irrelevant with non-runtime methods because it's all static content and probably wasteful but still, useful to normalise how things are done along with lazy-loading modules in Angular.
It is actually now possible to lazy load translations, if you are willing to do the translation of messages in the browser rather than getting the benefit of compile-time translation. This is an area that is not well documented, but @alexcotelin is working on an example and some docs for this.
Observables. I can subscribe to language changes, look at the current language, do things to state in NGRX etc.
As a corollary to no-dynamic locale switching, this will not be supported built-in.
No redirects, language is set from a user account/localStorage and loaded first without redirecting to locale-specific sites /en or /id etc. This also simplified deployment (firebase) beccause I don't have to do anything extra in server-land. It's not an SSR app (yet) so I don't have access to, for example, determining the Accept-Language header and redirect before serving. (Maybe there's other ways but never was bothered to look).
As part of the ability to do the translation in the browser, mentioned above, it is possible to set the locale at bootstrap time based on something other than the URL, so this is also effectively supported.