This feature request is for @angular/localize
When doing ng build --localize e.g. for 3 languages, for default one en-US, en-GB, and nl, the ng build creates 3 folders inside dist which means there is no default files under dist, thus application can be only accessed with http://localhost:3000/en-US if you set port to 3000.
If you have a solution in mind, please describe it.
Can we introduce default baseHref to be empty string "", and to add e.g. new property (outputhPath) to sourceLocale in angular.json to be root as default?
Have you considered any alternative solutions or workarounds?
I've found a way to add rsync command to extract default folder to root like this e.g.
rsync -a dist/en-US/* dist/ && rm -rf dist/en-US and to set baseHref property inside angular.json file with this:
"i18n": {
"sourceLocale": {
"baseHref": ""
},
}
This way, my app loads at _http://localhost:3000_ as usual.
@miki995 you can solve it in many ways.
you can specify "outputPath": "dist", for you default locale, but this build needs to be run first then (angular clears destination folder during the build)
I personally prefer to have every language separated and do redirect with this nginx config
location / {
try_files $uri /en/$uri /en/index.html;
}
Your first solution needs 2 builds which I don't want, why 10 mins, when we can do in 5.
Second one is a nice workaround, but my app url is ugly then with /en :D. App should have default state :D
I personally create a "root" html file that I insert into the root of the dist folder.
You might want to do stuff like saving preferred language into localhost, and other stuff... so I just have this "root-index" file copied to the dist root folder after a build..
I personally like the fact that there is a language-folder for each supported language.
The folder where localized distributable code is a matter for the Angular CLI project. I am transferring this issue there; but it is worth knowing that the current approach of using the locale id in the path was a conscious design decision... cc @clydin
The behavior is indeed intentional. There is no default build when localizing. Each build is specialized using the provided locale (source locale included). This specialization includes inlining the locale identifier, injecting locale data, and inlining all translations (removing runtime $localize calls). The only difference with the source locale is that no translation file is loaded. All other operations are still performed; making all builds unique to their respective locale.
The built output on the filesystem is also not in any way coupled to the deployment strategy or web server configuration. The files can be moved, altered, or served in any way necessary to satisfy the needs of the project. Some projects even use client language detection at the root level to automatically redirect to the appropriate locale variant.
@petebacondarwin @clydin Thanks for making it clear to me. I appreciate that. Cheers!
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._
Most helpful comment
The behavior is indeed intentional. There is no default build when localizing. Each build is specialized using the provided locale (source locale included). This specialization includes inlining the locale identifier, injecting locale data, and inlining all translations (removing runtime
$localizecalls). The only difference with the source locale is that no translation file is loaded. All other operations are still performed; making all builds unique to their respective locale.The built output on the filesystem is also not in any way coupled to the deployment strategy or web server configuration. The files can be moved, altered, or served in any way necessary to satisfy the needs of the project. Some projects even use client language detection at the root level to automatically redirect to the appropriate locale variant.