Website service Makefile and Localization package fixes (#12)
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 commit is contained in:
@@ -0,0 +1,37 @@
|
||||
import Foundation
|
||||
|
||||
/// A backend that resolves localized strings for an explicit locale and reports the languages it serves.
|
||||
///
|
||||
/// This is the seam that decouples ``Localize`` and ``LanguageList`` from *how* localizations are stored
|
||||
/// and resolved. The shipping implementation, ``StringCatalog``, reads a raw `.xcstrings` catalog so it
|
||||
/// behaves identically on Darwin and Linux. A future backend — for example one built on
|
||||
/// `String(localized:)` for a native Apple app that needs plural and device variations — can conform
|
||||
/// without changing any caller.
|
||||
///
|
||||
/// Resolution never fails: an implementation returns the key itself when it has no localization for it,
|
||||
/// mirroring Foundation's `String(localized:)`. This is the contract both a dictionary lookup and the
|
||||
/// native API can honour, since the native API cannot distinguish a missing key from a translation that
|
||||
/// happens to equal the key.
|
||||
protocol CatalogResolving: Sendable {
|
||||
|
||||
// MARK: Properties
|
||||
|
||||
/// The source (development) language, used as the final fallback when a locale has no localization.
|
||||
var sourceLanguage: String { get }
|
||||
|
||||
/// Every language the backend can resolve strings for, including the source language.
|
||||
var languages: Set<String> { get }
|
||||
|
||||
// MARK: Methods
|
||||
|
||||
/// Resolves a catalog key in the given locale.
|
||||
/// - Parameters:
|
||||
/// - key: the catalog key to look up.
|
||||
/// - locale: the locale to resolve the key in.
|
||||
/// - Returns: the localized string, falling back to the source language, then to the key itself.
|
||||
func string(
|
||||
for key: String,
|
||||
in locale: Locale
|
||||
) -> String
|
||||
|
||||
}
|
||||
Reference in New Issue
Block a user