Repository navigation
Add LocalizedString support to Text - #892
VictorPuga wants to merge 4 commits into
Conversation
LocalizedStringResource now conforms to InlineElement, so it can be used anywhere inline content is accepted. Resources are resolved using the page's language and the new Site.localizationBundle, which defaults to .main. Any bundle set on an individual resource is ignored. Text gains an initializer taking a LocalizedStringResource, and the InlineElement initializer is disfavored so string literals are localized. String variables still render verbatim. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The LocalizedStringResource tests no longer build a bundle in a temporary directory. They now resolve strings from a Localizable.xcstrings catalog in the test target, which is processed into Bundle.module. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
Thanks for your work @VictorPuga. This looks good to me, but I'll be curious to see whether this works on Linux. We've had issues with string catalogs & LocalizedStringResource in the past. |
|
Yeah, I just tried out building a site with this localization on Linux and got a bunch of errors. Let me try and find an alternative. |
LocalizedStringResource is not available on Linux, and string catalogs processed by SwiftPM there are copied as-is instead of compiled into .lproj files, so Bundle lookups find nothing. Ignite now has its own LocalizedString type, which string literals and interpolations create, and reads Localizable.xcstrings directly as JSON on every platform. Strings resolve using the page's language, falling back from the full language identifier to the language code, then the source language, then the key. Plural and device variations are not supported. Site.localizationBundle is replaced by Site.localizationCatalog, a URL that defaults to nil. The catalog must be declared as a .copy resource, because .process compiles it and removes the original file. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Remove the unused SwiftUI import from the Button tests, and check for built files with FileManager instead of URL.checkPromisedItemIsReachable(), which only exists on Apple platforms. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
VictorPuga
changed the title
|
I've pushed a new approach:
The test suite passes on both macOS and Linux (aarch64, Swift 6.3.2). I also fixed two Apple-only calls in existing tests that broke the Linux build. Plural and device variations aren't supported yet. Could you take another look? |
Oof I'm not convinced this is a good idea. From the get-go I can see pluralization & variants are not supported, and we're adding a lot of boilerplate for something that should be supported out-of-the-box :/
This I could live with. Maybe... I think a proper solution here would be to use OS-conditional flags to use string catalogs natively on macOS, and only do the workarounds on Linux. But even then I'm wary of the boilerplate this will require, especially because we should make sure we have feature-parity between OS-es. @twostraws what do you think? |
|
FWIW, I opened an issue in swift-foundation to ask whether a cross-platform |
String literals passed to
Textare now looked up in the site'sLocalizable.xcstrings, using the page's language.Stringvariables still render verbatim.LocalizedStringResourcedoesn't exist on Linux, and SwiftPM doesn't compile.xcstringsthere. So this adds aLocalizedStringtype that reads the catalog JSON directly, with identical output on macOS and Linux.Site.localizationCatalog: URL?points at the catalog and defaults tonil. Ship it as a.copyresource, since.processremoves the original file.Lookup order is the full language identifier, the language code, the source language, then the key. Plural and device variations are not supported.
🤖 Generated with Claude Code