-
Notifications
You must be signed in to change notification settings - Fork 12k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Multi-Domain Locale Detection in Angular SSR #29111
Comments
Just my two cents: I had to do that for a backend (not using Angular SSR), and I found it rather elegant to do it by relying on the Accept-Language header. The reverse-proxy in front of the backend would be configured to set the appropriate Accept-Language header value based on the domain. This limits the configuration that needs to be done on the backend side. And relying on the Accept-Language header could also be a good thing for simpler deployments where there is a single URL to serve the app, and where the Accept-Language header coming from the browser is used to decide which locale to use. |
In certain scenarios, users build applications with the same `baseHref` when using i18n, primarily for deploying localized applications across multiple domains. To address this, we are removing the deprecation of `i18n.baseHref` and will revisit potential options as part of angular#29111 Instead of deprecating `i18n.baseHref`, we now issue a warning when it is used with SSR, as this may lead to undefined behavior. Closes angular#29396
…rning In certain scenarios, users build applications with the same `baseHref` when using i18n, primarily for deploying localized applications across multiple domains. To address this, we are removing the deprecation of `i18n.baseHref` and will revisit potential options as part of angular#29111 Instead of deprecating `i18n.baseHref`, we now issue a warning when it is used with SSR, as this may lead to undefined behavior. Closes angular#29396
…rning In certain scenarios, users build applications with the same `baseHref` when using i18n, primarily for deploying localized applications across multiple domains. To address this, we are removing the deprecation of `i18n.baseHref` and will revisit potential options as part of #29111 Instead of deprecating `i18n.baseHref`, we now issue a warning when it is used with SSR, as this may lead to undefined behavior. Closes #29396
…rning In certain scenarios, users build applications with the same `baseHref` when using i18n, primarily for deploying localized applications across multiple domains. To address this, we are removing the deprecation of `i18n.baseHref` and will revisit potential options as part of #29111 Instead of deprecating `i18n.baseHref`, we now issue a warning when it is used with SSR, as this may lead to undefined behavior. Closes #29396 (cherry picked from commit 8535c11)
Description
Currently, Angular SSR does not provide built-in functionality to detect the domain in a multi-domain setup and serve the appropriate localized version of the application. This feature would allow Angular SSR to dynamically render pages with the correct locale based on the domain.
Use Case:
example.com
,fr.example.com
,example.de
) need SSR to serve the appropriate locale.example.com
→ English contentfr.example.com
→ French contentexample.de
→ German contentDescribe the solution you'd like
Allow SSR to use the detected domain to select the corresponding locale configuration. Which simplifies multi-language deployment without relying on path-based locales (e.g.,
/en
,/fr
).Describe alternatives you've considered
No response
The text was updated successfully, but these errors were encountered: