Skip to content
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

Closed
1 task
eufri opened this issue Nov 25, 2024 · 4 comments · Fixed by #29011
Closed
1 task

Set locale baseHref to '/' is not working with AngularNodeAppEngine #28967

eufri opened this issue Nov 25, 2024 · 4 comments · Fixed by #29011

Comments

@eufri
Copy link

eufri commented Nov 25, 2024

Command

build

Is this a regression?

  • Yes, this behavior used to work in the previous version

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.

      "i18n": {
        "sourceLocale": {
          "code": "en",
          "baseHref": "/"
        },
        "locales": {
          "de": "src/messages/messages.de.xlf",
          "es": "src/messages/messages.es.xlf"
        }
      }

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.

if (!entryPoints.has(potentialLocale) && entryPoints.has("")) {
    return this.getEntryPointExports("");
}

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

Angular: 19.0.0
... animations, common, compiler, compiler-cli, core, forms
... localize, platform-browser, platform-browser-dynamic
... platform-server, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1900.1
@angular-devkit/build-angular   19.0.1
@angular-devkit/core            19.0.1
@angular-devkit/schematics      19.0.1
@angular/cli                    19.0.1
@angular/ssr                    19.0.1
@schematics/angular             19.0.1
rxjs                            7.8.1
typescript                      5.6.3
zone.js                         0.15.0

Anything else relevant?

No response

@alan-agius4
Copy link
Collaborator

Although the baseHref is set to /, the files are emitted in /en, suggesting that this option might either be used incorrectly or there is another issue at play. In the case of a purely client-side application, the / path would not exist.

//cc @clydin

@eufri
Copy link
Author

eufri commented Nov 26, 2024

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.
My use case is that I just don't want a locale prefix to be added for a specific default locale. But if I understand you correctly, this was never actually officially supported? If not, is there any chance that this will be supported in the near future? If this will not be supported, I think you can close this issue and I'll look for other solutions to achieve this as I can't change the URLs anymore unfortunately.

@alan-agius4 alan-agius4 self-assigned this Nov 28, 2024
@alan-agius4
Copy link
Collaborator

@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.

@eufri
Copy link
Author

eufri commented Nov 28, 2024

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.

alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 2, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 2, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 2, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 2, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 2, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 2, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 3, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 3, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 3, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 3, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 3, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 3, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 3, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 4, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 4, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 4, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 4, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 6, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 6, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 6, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 6, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 6, 2024
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
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Dec 7, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants