-
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
Set locale baseHref to '/' is not working with AngularNodeAppEngine #28967
Comments
Although the //cc @clydin |
If I remember correctly, back when I wasn't using SSR, I simply delivered the files from /en, and it wasn't a problem because the baseHref was correct everywhere when set to '/'. That was a few years ago though. |
@eufri, I think in general we should support this use case better. I already have ideas, I'll try to open a PR earlier next week. |
Thanks a lot @alan-agius4 ! If I can help you somehow, I am obviously happy to help, because I don't see any other (good) solutions and really need support for this. |
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `urlSegment` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `urlSegment` option is used, the `baseHref` is ignored. Instead, the `urlSegment` serves as both the base href and the name of the directory containing the localized version of the app. ### Configuration Example Below is an example configuration showcasing the use of `urlSegment`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` ### Example Directory Structure The following tree structure demonstrates how the `urlSegment` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `urlSegment` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `urlSegment` option is used, the `baseHref` is ignored. Instead, the `urlSegment` serves as both the base href and the name of the directory containing the localized version of the app. ### Configuration Example Below is an example configuration showcasing the use of `urlSegment`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` ### Example Directory Structure The following tree structure demonstrates how the `urlSegment` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `urlSegment` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `urlSegment` option is used, the `baseHref` is ignored. Instead, the `urlSegment` serves as both the base href and the name of the directory containing the localized version of the app. ### Configuration Example Below is an example configuration showcasing the use of `urlSegment`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` ### Example Directory Structure The following tree structure demonstrates how the `urlSegment` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `urlSegment` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `urlSegment` option is used, the `baseHref` is ignored. Instead, the `urlSegment` serves as both the base href and the name of the directory containing the localized version of the app. ### Configuration Example Below is an example configuration showcasing the use of `urlSegment`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` ### Example Directory Structure The following tree structure demonstrates how the `urlSegment` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `urlSegment` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `urlSegment` option is used, the `baseHref` is ignored. Instead, the `urlSegment` serves as both the base href and the name of the directory containing the localized version of the app. ### Configuration Example Below is an example configuration showcasing the use of `urlSegment`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` ### Example Directory Structure The following tree structure demonstrates how the `urlSegment` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `urlSegment` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `urlSegment` option is used, the `baseHref` is ignored. Instead, the `urlSegment` serves as both the base href and the name of the directory containing the localized version of the app. ### Configuration Example Below is an example configuration showcasing the use of `urlSegment`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` ### Example Directory Structure The following tree structure demonstrates how the `urlSegment` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `urlSegment` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `urlSegment` option is used, the `baseHref` is ignored. Instead, the `urlSegment` serves as both the base href and the name of the directory containing the localized version of the app. ### Configuration Example Below is an example configuration showcasing the use of `urlSegment`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` ### Example Directory Structure The following tree structure demonstrates how the `urlSegment` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `urlSegment` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `urlSegment` option is used, the `baseHref` is ignored. Instead, the `urlSegment` serves as both the base href and the name of the directory containing the localized version of the app. ### Configuration Example Below is an example configuration showcasing the use of `urlSegment`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` ### Example Directory Structure The following tree structure demonstrates how the `urlSegment` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `urlSegment` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `urlSegment` option is used, the `baseHref` is ignored. Instead, the `urlSegment` serves as both the base href and the name of the directory containing the localized version of the app. ### Configuration Example Below is an example configuration showcasing the use of `urlSegment`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` ### Example Directory Structure The following tree structure demonstrates how the `urlSegment` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `urlSegment` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `urlSegment` option is used, the `baseHref` is ignored. Instead, the `urlSegment` serves as both the base href and the name of the directory containing the localized version of the app. ### Configuration Example Below is an example configuration showcasing the use of `urlSegment`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` ### Example Directory Structure The following tree structure demonstrates how the `urlSegment` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `urlSegment` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `urlSegment` option is used, the `baseHref` is ignored. Instead, the `urlSegment` serves as both the base href and the name of the directory containing the localized version of the app. ### Configuration Example Below is an example configuration showcasing the use of `urlSegment`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` ### Example Directory Structure The following tree structure demonstrates how the `urlSegment` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `urlSegment` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `urlSegment` option is used, the `baseHref` is ignored. Instead, the `urlSegment` serves as both the base href and the name of the directory containing the localized version of the app. ### Configuration Example Below is an example configuration showcasing the use of `urlSegment`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` ### Example Directory Structure The following tree structure demonstrates how the `urlSegment` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `urlSegment` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `urlSegment` option is used, the `baseHref` is ignored. Instead, the `urlSegment` serves as both the base href and the name of the directory containing the localized version of the app. ### Configuration Example Below is an example configuration showcasing the use of `urlSegment`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` ### Example Directory Structure The following tree structure demonstrates how the `urlSegment` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `urlSegment` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `urlSegment` option is used, the `baseHref` is ignored. Instead, the `urlSegment` serves as both the base href and the name of the directory containing the localized version of the app. Below is an example configuration showcasing the use of `urlSegment`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` The following tree structure demonstrates how the `urlSegment` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `urlSegment` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `urlSegment` option is used, the `baseHref` is ignored. Instead, the `urlSegment` serves as both the base href and the name of the directory containing the localized version of the app. Below is an example configuration showcasing the use of `urlSegment`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` The following tree structure demonstrates how the `urlSegment` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `urlSegment` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `urlSegment` option is used, the `baseHref` is ignored. Instead, the `urlSegment` serves as both the base href and the name of the directory containing the localized version of the app. Below is an example configuration showcasing the use of `urlSegment`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` The following tree structure demonstrates how the `urlSegment` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `urlSegment` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `urlSegment` option is used, the `baseHref` is ignored. Instead, the `urlSegment` serves as both the base href and the name of the directory containing the localized version of the app. Below is an example configuration showcasing the use of `urlSegment`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` The following tree structure demonstrates how the `urlSegment` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `subPath` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `subPath` option is used, the `baseHref` is ignored. Instead, the `subPath` serves as both the base href and the name of the directory containing the localized version of the app. Below is an example configuration showcasing the use of `subPath`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` The following tree structure demonstrates how the `subPath` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` **DEPRECATED**: The `baseHref` option under `i18n.locales` and `i18n.sourceLocale` in `angular.json` is deprecated in favor of `subPath`. The `subPath` defines the URL segment for the locale, serving as both the HTML base HREF and the directory name for output. By default, if not specified, `subPath` will use the locale code. Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `subPath` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `subPath` option is used, the `baseHref` is ignored. Instead, the `subPath` serves as both the base href and the name of the directory containing the localized version of the app. Below is an example configuration showcasing the use of `subPath`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` The following tree structure demonstrates how the `subPath` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` DEPRECATED: The `baseHref` option under `i18n.locales` and `i18n.sourceLocale` in `angular.json` is deprecated in favor of `subPath`. The `subPath` defines the URL segment for the locale, serving as both the HTML base HREF and the directory name for output. By default, if not specified, `subPath` will use the locale code. Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `subPath` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `subPath` option is used, the `baseHref` is ignored. Instead, the `subPath` serves as both the base href and the name of the directory containing the localized version of the app. Below is an example configuration showcasing the use of `subPath`: ```json "i18n": { "sourceLocale": { "code": "en-US", "urlSegment": "" }, "locales": { "fr-BE": { "urlSegment": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "urlSegment": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` The following tree structure demonstrates how the `subPath` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` DEPRECATED: The `baseHref` option under `i18n.locales` and `i18n.sourceLocale` in `angular.json` is deprecated in favor of `subPath`. The `subPath` defines the URL segment for the locale, serving as both the HTML base HREF and the directory name for output. By default, if not specified, `subPath` will use the locale code. Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `subPath` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `subPath` option is used, the `baseHref` is ignored. Instead, the `subPath` serves as both the base href and the name of the directory containing the localized version of the app. Below is an example configuration showcasing the use of `subPath`: ```json "i18n": { "sourceLocale": { "code": "en-US", "subPath": "" }, "locales": { "fr-BE": { "subPath": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "subPath": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` The following tree structure demonstrates how the `subPath` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` DEPRECATED: The `baseHref` option under `i18n.locales` and `i18n.sourceLocale` in `angular.json` is deprecated in favor of `subPath`. The `subPath` defines the URL segment for the locale, serving as both the HTML base HREF and the directory name for output. By default, if not specified, `subPath` will use the locale code. Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `subPath` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `subPath` option is used, the `baseHref` is ignored. Instead, the `subPath` serves as both the base href and the name of the directory containing the localized version of the app. Below is an example configuration showcasing the use of `subPath`: ```json "i18n": { "sourceLocale": { "code": "en-US", "subPath": "" }, "locales": { "fr-BE": { "subPath": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "subPath": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` The following tree structure demonstrates how the `subPath` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` DEPRECATED: The `baseHref` option under `i18n.locales` and `i18n.sourceLocale` in `angular.json` is deprecated in favor of `subPath`. The `subPath` defines the URL segment for the locale, serving as both the HTML base HREF and the directory name for output. By default, if not specified, `subPath` will use the locale code. Closes angular#16997 and closes angular#28967
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose. This commit introduces a new `subPath` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `subPath` option is used, the `baseHref` is ignored. Instead, the `subPath` serves as both the base href and the name of the directory containing the localized version of the app. Below is an example configuration showcasing the use of `subPath`: ```json "i18n": { "sourceLocale": { "code": "en-US", "subPath": "" }, "locales": { "fr-BE": { "subPath": "fr", "translation": "src/i18n/messages.fr-BE.xlf" }, "de-BE": { "subPath": "de", "translation": "src/i18n/messages.de-BE.xlf" } } } ``` The following tree structure demonstrates how the `subPath` organizes localized build output: ``` dist/ ├── app/ │ └── browser/ # Default locale, accessible at `/` │ ├── fr/ # Locale for `fr-BE`, accessible at `/fr` │ └── de/ # Locale for `de-BE`, accessible at `/de` ``` DEPRECATED: The `baseHref` option under `i18n.locales` and `i18n.sourceLocale` in `angular.json` is deprecated in favor of `subPath`. The `subPath` defines the URL segment for the locale, serving as both the HTML base HREF and the directory name for output. By default, if not specified, `subPath` will use the locale code. Closes angular#16997 and closes angular#28967
Command
build
Is this a regression?
The previous version in which this bug was not present was
No response
Description
I have an application where English is the default locale and I don't want the prefix '/en' in the URL. With CommonEngine it was possible to set the baseHref in angular.json to '/' to achieve this.
Now I have migrated this application to Angular 19 and noticed that this does not seem to be possible anymore with AngularNodeAppEngine as the default locale 'en' is not recognized. The build is successful and all other locales work fine, except 'en'. Even the root path works, because the potentialLocale is '' (empty string) in this case, but no child routes can be found (at least not with ssr). Is this behavior expected? If so, are there still any workarounds to disable the locale prefix for a specific locale?
In a (maybe) naive approach, I tried adding the following line just before returning the entryPointExport in app-engine.ts#L146 and it worked, so it seems to be supported everywhere except in this particular location and therefore I really hope it's just a bug and I don't have to revert the migration.
Any help is appreciated, because everything else is already migrated.
Minimal Reproduction
Repo: https://github.com/eufri/angular-ssr-issue
Basically I have created a new app
ng new angular-ssr-issue --ssr --minimal --package-manager=yarn --routing --server-routing --skip-tests --ssr
Added localize package
ng add @angular/localize
And then added some test locales + messages and a child component +route
Exception or Error
Your Environment
Anything else relevant?
No response
The text was updated successfully, but these errors were encountered: