This PR contains the work done to get the Website service building and running correctly in its Linux container. The service depends on the local _Localization_ package, whose String-Catalog localization was Darwin-only and broke the Docker build. Thus the localization internals have been reworked to be platform-agnostic and fixes the container build context so the local package is actually available during the build.
* Localization package
* Replaced the Darwin-only `String.LocalizationValue` / `String(localized:)` path with a StringCatalog type that reads raw JSON from a given `.xcstrings` file, so lookups resolve identically on macOS and Linux.
* The `LanguageList` now derives available languages from the catalog instead of `Bundle.localizations`
* The `Negotiate` does explicit _Accept-Language_ matching (exact tag, then primary subtag) instead of the Linux-broken `Bundle.preferredLocalizations`.
* Switched the catalog resource rule from `.process` to `.copy` (in both Localization and Website manifests) so the raw `.xcstrings` ships verbatim on every platform.
* Introduced a `CatalogResolving` protocol as a seam between the localizers and the storage backend, enabling test injection and a future native-Apple backend without changing callers.
* Website Docker build
* Build context moved to the repository root so the relative-path `Localization` package is inside the context; `Dockerfile`, `docker-compose.override.yml`, and the _img-release_ make target updated to the new context/paths.
* Added a root `.dockerignore` to keep the context lean.
Reviewed-on: rock-n-code/loud-amsterdam#12
Co-authored-by: Javier Cicchelli <javier@rock-n-code.com>
Co-committed-by: Javier Cicchelli <javier@rock-n-code.com>
This PR contains the work done to refactor the _Localization_ package and tidy the project a little bit.
To provider further details about the work:
* The `Negotiate` function was moved to the _Localization_ package.
* The `WebsiteRequestContext` context no longer resolves a default language at creation; it starts empty and relies on the `LocalizationMiddleware` middleware to fill it in.
* Fixed the local dependency path to Packages/Localization for the **Website** package as it only resolved inside the Xcode workspace before, breaking swift build, the Makefile, and the Docker build).
* Updated the `README` file to document language negotiation, the GET /health route, and the full middleware chain; doc comments across the moved/renamed types were brought back in sync with the code.
Reviewed-on: rock-n-code/loud-amsterdam#11
Co-authored-by: Javier Cicchelli <javier@rock-n-code.com>
Co-committed-by: Javier Cicchelli <javier@rock-n-code.com>
This PR contains the work done to introduce server-side localization support to the **Website** service so the landing and error pages are served in the visitor's negotiated language, backed by a new reusable Localization package.
To provide further details about the work:
* Created the _Localization_ package — a bundle-bound `Localize` method and a `LanguageList` type.
* Language negotiation — `NegotiateLanguage` method picks the best supported language from the request's _Accept-Language_ header (falling back to the default); the `LocalizationMiddleware` middleware resolves it per request and stores it on a new `LocalizedRequestContext` / `WebsiteRequestContext` context.
* Localized responses — `LocalizedHTMLCollectionResponse` pre-renders each page once per language and caches the bytes (with `Content-Language` + `Vary: Accept-Language`), reused by the `RootController` controller and `NotFoundMiddleware` middleware.
* The `CachedHTMLResponse` response gained custom-header support.
* Localized pages — the `IndexPage` and `ErrorPage` pages now resolve their strings via `Localize` method;
* Added `Localizable.xcstrings` catalogs.
* Wired the `LocalizationMiddleware` middlewaer into the router.
Reviewed-on: rock-n-code/loud-amsterdam#10
Co-authored-by: Javier Cicchelli <javier@rock-n-code.com>
Co-committed-by: Javier Cicchelli <javier@rock-n-code.com>
javier