Search's whole interface is hard-coded English — there is no String Catalog, no .lproj, no NSLocalizedString, and no language setting, so the app reads English even on a Chinese system. Only the web pages themselves follow the user.
For a browser this small the copy is arguably the product, so I understand if translations don't fit the design. But I'd love to use Search day-to-day in Simplified Chinese, and I'm willing to build it.
The shape I imagine, as small as the rest of the app:
- Funnel the UI strings through one String Catalog (
Search.xcstrings) so Apple's tooling handles plural forms and languages, with zh-Hans as the first translation — mostly mechanical edits at the call sites, no behavior change.
- Follow the Mac's language by default; nothing in Settings unless it needs to be.
- Later, the same catalog could carry other languages for free.
Would a change like this be in scope? If so I'd start with one or two files (say Settings and TabBar) as a proof of concept before touching the rest — roughly 100–200 user-facing strings all in all.
Search's whole interface is hard-coded English — there is no String Catalog, no
.lproj, noNSLocalizedString, and no language setting, so the app reads English even on a Chinese system. Only the web pages themselves follow the user.For a browser this small the copy is arguably the product, so I understand if translations don't fit the design. But I'd love to use Search day-to-day in Simplified Chinese, and I'm willing to build it.
The shape I imagine, as small as the rest of the app:
Search.xcstrings) so Apple's tooling handles plural forms and languages, with zh-Hans as the first translation — mostly mechanical edits at the call sites, no behavior change.Would a change like this be in scope? If so I'd start with one or two files (say
SettingsandTabBar) as a proof of concept before touching the rest — roughly 100–200 user-facing strings all in all.