🌐 Expand Korean localization coverage across web and mobile

[devy1540]

Description

This PR expands Korean localization coverage across the browser and Expo applications.

• Replaces remaining hardcoded user-facing strings with locale keys across navigation, libraries, books, readers, smart lists, book clubs, server settings, user management, OPDS, and shared controls.
• Adds the corresponding en-US source strings and complete ko-KR translations while preserving 1:1 locale key parity.
• Localizes validation messages, status text, accessibility labels, notifications, and count-dependent copy.
• Moves LocaleProvider above the browser error boundary so startup failures render translated fallback copy instead of raw keys such as errorScene.criticalHeading.
• Adds or updates regression coverage for the translated error fallback, reader controls, and API key inspection.

The motivation is to remove mixed English/Korean UI and untranslated raw keys from the Korean experience. The reported error fallback occurred because the locale provider was mounted inside the router while the error boundary was outside it; an error thrown during router startup therefore rendered without locale context.

This affects visible UI copy and localization wiring in the browser and Expo clients. It does not change backend APIs or data models.

This contribution was developed with assistance from OpenAI Codex. I reviewed the changes and validated them locally before submission.

How to contribute: https://github.com/stumpapp/stump/blob/main/.github/CONTRIBUTING.md

Validation performed:

• Locale parity: en-US 2,770 keys, ko-KR 2,770 keys, 0 missing and 0 extra keys.
• Browser tests: 5 suites and 12 tests passed.
• corepack yarn workspace @stump/browser check-types
• corepack yarn workspace @stump/i18n check-types
• ESLint and Prettier checks for the error-boundary regression fix.
• git diff --check

Screenshots

Not included in this draft. The localized error fallback behavior is covered by a regression test that selects ko-KR, triggers the app error boundary, and verifies the Korean heading and home link.

Ready?

Please read each item and check the boxes:

• I read the contributing guidelines
• I searched for existing issues or pull requests that may be related to my contribution
• This PR is based into nightly and not main
• I added tests and/or documentation for my changes if applicable
• I disclosed any use of LLMs in the creation of this PR (if applicable)

Stump Contributor License Agreement

By contributing to Stump, you agree that your contributions will be licensed under the following licenses (where applicable):

• The expo application is licensed under GPL-3.0
• All other code in the repository is licensed under MIT License

[aaronleopold]

Thank you for drastically improving the coverage of translated strings!

In general, large-scale changes like this should be brought up in an issue or discussion first so that certain avoidable issues can be ironed out before effort has been made. At least at a glance, you've added locale keys for most if not all of the currently untranslated surface, but a lot of the keys aren't as grouped as I typically would like them to be organized. A good example of this is readerUi, there are easily multiple nested subgroups that could have been utilized to group things together which really makes maintenance significantly easier down the road (e.g., some of the keys are for selects and other inputs but at a glance would not know because of the flat structure). I try to group things by component and/or semantically to make it easier to find and connect in the code. It also helps cut duplication, where there are some instances of here. It's also just a lot more approachable than a flat structure for a human to read the content, which I optimize for heavily and don't care about LLM optimizations

Can we try to group things a bit more thoroughly, to keep things aligned with the existing practices in the repo? There are many references for how things are structured to pull from, but can try to point some good ones out if needed.

[devy1540]

Thanks for the feedback — I agree that I should have opened an issue or discussion before making a change of this size.
I’ll reorganize the newly added keys around components and semantic groups and remove duplicated entries. For readerUi, I’m considering groups such as search, navigation, locations, appearance, imageReader, timer, and errors.
Before updating all references, could you point me to one or two existing namespaces that best represent the structure you prefer? Also, would you prefer this cleanup to remain in this PR, or should the localization work be split into smaller PRs?

[aaronleopold]

Yeah of course, here are a few that I think are good examples:

• mobileApp.epubSettings or mobileApp.readerSettings i think are analogous examples for your readerUi
• mobileApp.localLibrary.downloadsHeaderSortMenu good example for splitting things that need to be split by data type (if applicable)
• settingsScene good example for splitting by route + component
• createOrUpdateSmartListForm.queryBuilder at a glance is another analogous example for your readerUi

In general, the keys under mobileApp are newer and better examples.

Also, would you prefer this cleanup to remain in this PR, or should the localization work be split into smaller PRs?

I think if you wanted to get the fixes you made into nightly earlier, e.g., moving the locale provider up a level so the error screen is properly localized, that would be more approachable to review faster. Otherwise, I'm fine with a single sweep of localization changes in one PR.

That said I'm not against splitting it up of course, it always helps, I'd say just avoid stacking PRs to avoid conflicts as they get squash merged (unless you don't care about dealing with them 😄)

[devy1540]

Thanks, those examples are very helpful.
I got ahead of myself because I was eager to improve the localization coverage, and I regret moving forward with such a large change before opening an issue or discussion to align on the approach.
I’ll keep the follow-up work in this branch and update this PR as a single localization sweep. I’ll reorganize the new keys using the newer mobileApp namespaces and the other examples you shared as references, remove duplicated entries, and sync the branch with the latest nightly.
Thanks again for taking the time to clarify the preferred structure.

[devy1540]

@aaronleopold

I’ve pushed the follow-up refactor to this branch in b9f7ebd.

The previously flat web translation keys are now organized by route/component and semantic group. In particular:

• readerUi settings and option values are grouped by concern and data type
• settingsUi has been removed, with its keys moved under settingsScene or the relevant form/component namespace
• Other flat UI namespaces, including bookClubUi, entityUi, libraryUi, filterUi, and controlUi, were reorganized similarly
• Shared strings are reused where appropriate to reduce duplication

I kept the follow-up work in this PR, as suggested.

Validation:

• en-US / ko-KR key parity: 2,752 keys each
• No missing static or dynamic translation references in the changed calls
• Browser and i18n type checks pass
• Browser tests: 160 passed
• ESLint: 0 errors
• Prettier and git diff --check pass

When you have time, I’d appreciate another review of the updated structure.

[aaronleopold]

Hey @devy1540, I'll try to take another look towards the end of the week. Thank you!