Do Not Deprecate baseHref in i18n Configuration

[jusfeel]

Which @angular/* package(s) are relevant/related to the feature request?

localize

Description:

The recent deprecation of the baseHref field in the i18n.sourceLocale configuration causes significant issues for projects that rely on a shared base URL for multiple localized builds.

While the subPath feature is a welcome addition for structuring locale builds, it is limiting for developers who:

1. Want locale-specific builds in subdirectories (subPath) without altering the <base> tag in index.html.
2. Depend on a static baseHref for all builds due to server or application constraints.

Current Behavior:

With subPath enabled:

Angular modifies the <base href> tag in index.html to include the locale-specific subpath (e.g., /zh-hans/), and there is no built-in way to override this behavior.
Without baseHref:

Developers are forced to implement error-prone and maintenance-heavy post-build scripts to reset the <base> tag to their desired value.

Expected Behavior:

Projects with subPath configured should still have the option to:

Use baseHref as a static value across all locale builds.
Separate the functionality of subPath (output directory) from the <base> tag in index.html.

Proposed solution

Instead of fully deprecating baseHref, it could coexist with subPath to give developers more flexibility. Suggested behavior:

1. baseHref takes precedence if defined. This ensures that:

   • The <base> tag in index.html uses baseHref for all builds.
   • subPath is only used for structuring the output directory, not modifying index.html.

2. If baseHref is not specified, the current subPath behavior remains unchanged.

Alternatives considered

Developers are forced to implement error-prone and maintenance-heavy post-build scripts to reset the tag to their desired value.

[alan-agius4]

Can you please share your i18n configure?

[jusfeel]

      "i18n": {
        "sourceLocale": {
            "code": "en",
            "baseHref": ""
        },
        "locales": {
          "zh-hans": {
            "translation": "src/locale/messages.zh-hans.xlf",
            "baseHref": ""
          }
        }
      }

<base href="/">

[zip-fa]

He is probably talking about two different domains, eg:

https://my-cool-app.com
https://zh-audience-app.cn

Where single app is served and / url is different locale.
But this only possible when:

1. Developer moves en/zh locale from directory to / with custom script
2. I don't understand how SSR will work in that case; probably manifest will be generated with two '' entries

So i am pretty unsure on this issue. Probably moving i18n to configuration will be more suitable

[anisabboud]

I'm facing a similar issue/dilemma trying to transition to subPath.

Consider the following angular.json configuration:

      "i18n": {  // Define i18n locales - https://angular.dev/guide/i18n/merge.
        "sourceLocale": { "code": "en", "baseHref": "" },  // English primary language (default /).
        "locales": {
          "de": "src/i18n/messages.de.xlf",  // German secondary language (<base href="/de/">).
          "es-419": "src/i18n/messages.es-419.xlf",  // Spanish secondary language (<base href="/es/">).
          "fr": "src/i18n/messages.fr.xlf",  // French secondary language (<base href="/fr/">).
          "it": "src/i18n/messages.it.xlf",  // Italian secondary language (<base href="/it/">).

          "de-base": { "translation": "src/i18n/messages.de.xlf", "baseHref": "" },  // German customer (default /).
          "fr-base": { "translation": "src/i18n/messages.fr.xlf", "baseHref": "" },  // French customer (default /).
          "it-base": { "translation": "src/i18n/messages.it.xlf", "baseHref": "" },  // Italian customer (default /).

          "en-seco": { "translation": "src/i18n/messages.xlf", "baseHref": "en" }  // Non-english primary with English secondary (<base href="/en/">).
        }
      },

This configuration provides the flexibility to create different multi-language builds for different customers. E.g.,

          "configurations": {
            "us": { "localize": ["en", "es"] },  // American customer - English by default, with ability to switch language to Spanish.
            "ch": { "localize": ["de-base", "fr", "it", "en-seco"] },  // Swiss customer - German by default, with ability to switch language to French, Italian, or English as secondary languages.
            "it": { "localize": ["it"] },  // Italian customer - Italian only.
          }

I know this might be pushing the limits of what's possible in the current configuration, but since your goal is to improve the configuration, it would be great if the case above could be handled/supported (or at least not be rendered impossible).
With the new update (deprecating baseHref in favor of subPath), ng serve no longer works:
Error: Invalid i18n configuration: Locales 'en' and 'de-base' cannot have the same subPath: ''.

---

Suggestion

Perhaps subPath should be configured/overridden under the "localize" array, and not under "i18n" > "locales"?

"localize" would take an array of locales (just like now), and the first locale in the array would be considered the default (baseHref "/") while the rest of the locales in the array would have their subPath set to the locale code by default, unless specifically overridden.

In such case, the configuration above could be simplified as follows:

      "i18n": {
        "sourceLocale": "en",  // English.
        "locales": {
          "de": "src/i18n/messages.de.xlf",  // German.
          "es-419": "src/i18n/messages.es-419.xlf",  // Spanish.
          "fr": "src/i18n/messages.fr.xlf",  // French.
          "it": "src/i18n/messages.it.xlf",  // Italian.
        }
      },

          "configurations": {
            "us": { "localize": ["en", {"locale": "es-419", "subPath": "es"}] },  // "en" would be at baseHref "/". Example of overriding subPath for Spanish to "/es/".
            "ch": { "localize": ["de", "fr", "it", "en"] },  // "de" would be at baseHref "/", while the other languages would be at "/fr/", "/it/", "/en/".
            "it": { "localize": ["it"] },  // "it" would be at baseHref "/" in this build.
          }

This would also solve a minor issue we currently have with the previous setup, where we define another locale (e.g., it-base) in addition to the standard locale (e.g., it) to support both cases of Italian as the primary language (baseHref "/") as well as Italian as a secondary language (baseHref "/it/"): When we inject(LOCALE_ID), it injects "it-base" instead of "it", and similarly in the HTML: <html lang="it-base">. This is behaving "OK", but it's not ideal.
The suggested configuration (moving "subPath" in the schema from "locales" to "localize") would solve this as well.