`LOCALE_ID` is always `en-US` during server side renderring, and inconsistent with browser build

[clark0x]

LOCALE_ID is always en-US during server side renderring. And if we run the same prodution build in browser, LOCALE_ID is correct as expect.

Bug Report or Feature Request (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request

Command (mark with an x)

- [ ] new
- [x] build
- [ ] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Versions

Angular CLI: 6.1.5
Node: 8.11.2
OS: darwin x64
Angular: 6.1.6
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, platform-server, router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.7.5
@angular-devkit/build-angular     0.7.5
@angular-devkit/build-optimizer   0.7.5
@angular-devkit/build-webpack     0.7.5
@angular-devkit/core              0.7.5
@angular-devkit/schematics        0.7.5
@angular/cli                      6.1.5
@ngtools/webpack                  6.1.5
@schematics/angular               0.7.5
@schematics/update                0.7.5
rxjs                              6.3.1
typescript                        2.9.2
webpack                           4.9.2

Repro steps

Checkout https://github.com/clarkorz/angular6-ssr-issue-locale-fix-to-en

$ git clone git@github.com:clarkorz/angular6-ssr-issue-locale-fix-to-en.git
$ cd angular6-ssr-issue-locale-fix-to-en
$ yarn
$ yarn build:i18n-ssr
$ yarn serve:ssr

Access es endpoint, expect LOCALE_ID to be es.

$ curl http://localhost:4000/es/

...
<app-root ng-version="6.1.6"><h1>Hello</h1><p>locale is en-US</p></app-root>
...

If I run the same prodution build in browser, I got es for LOCALE_ID:

$ yarn serve:browser

Open browser to access http://localhost:5000/es/, I got es in browser and LOCALE_ID is es in console.

The log given by the failure

LOCALE_ID is always en-US during server side renderring.

// in another terminal
$ curl http://localhost:4000/es/

// in serve terminal
Node Express server listening on http://localhost:4000
LOCALE_ID is en-US

Desired functionality

LOCALE_ID should be as same as the --i18n-locale parameter of ng build or configuration parameter i18nLocale in angular.json.

LOCALE_ID should be consistent on both server side and browser side.

Mention any other details that might be useful

No.

[alan-agius4]

Hi, from the looks of it you are only generating a single server application https://github.com/clarkorz/angular6-ssr-issue-locale-fix-to-en/blob/master/angular.json#L143, which can only load a single locale.

You have 3 browsers configurations production-es, production-en, production, and a single build for the server being production which rightly so is taking the default locale that being en-US.

I am going to leave this open to add docs related to this.

[demurgos]

I sent a PR a few months ago to allow having multiple locales with the same server. It was closed because this use case was supposed to be better supported natively. Is it still planned?

[alan-agius4]

Yeah, with the new renderer the translations will be applied at runtime.

[ahmadalfy]

Any update on this?

[markudevelop]

Here is a solution:

Use your server.ts file to send the locale and inject your own custom LOCALE_ID :)

[ahmadalfy]

Do you have a suggestion how to use that on express ?

[mgechev]

Looks like this is the intended behavior. We can add a guide on i18n with SSR, but if we go in this direction we should probably track that separately.

[ahmadalfy]

@mgechev how do you suggest we do that? You can direct me and I will be glad to write down the missing part to the docs except that I don't know how to fix it. Thank you

[mgechev]

You can find some workarounds here.

We're working on a more dynamic localization implementation that will enable simpler behavior.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}