fix: localize hardcoded Chinese UI strings and commit tags on Tab - #11
Open
cleinias wants to merge 3 commits into
Open
fix: localize hardcoded Chinese UI strings and commit tags on Tab#11cleinias wants to merge 3 commits into
cleinias wants to merge 3 commits into
Conversation
FreeTagPicker had two papercuts in the lorebook/keys editor:
1. Its default placeholder was a hardcoded Chinese literal ("请输入标签"),
so it showed Chinese regardless of the selected UI language. Route it
through i18n instead; the "Input or select tags" key already exists in
all four locale files (en/zh/ja/ko), it was simply never wired up.
2. A typed tag was only committed on Enter/comma — there was no Tab or
blur handling, so pressing Tab to move to the next field silently
discarded the pending key. Commit the pending tag on Tab as well as
Enter (extracted into commitQuery); Tab still moves focus afterwards.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The tool description under each entry in the Tool tab was rendered raw
(`<span>{desc}</span>`) instead of through i18n, and WelcomeBuilder's
description was a hardcoded Chinese literal — so it showed Chinese in
every UI language. Pass the description through `t()` like the tool name
already is, make WelcomeBuilder's description an English i18n key, and add
that key to the en/zh locale files (ja/ko fall back to English until
translated).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…eholders
The markdown persona-template completion (label, documentation, and the
${...} snippet placeholders such as 世界观 / 角色名 / 角色职业) was hardcoded
in Chinese, so it appeared Chinese in every UI language. Route them all
through i18n and add the keys to en/zh (ja/ko fall back to English). The
lone remaining Chinese in this file is a code comment, left untouched.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes several spots where UI strings were hardcoded in Chinese (shown regardless of the selected language), plus a related tag-input papercut.
Changes
1. TagPicker (lorebook keys / tags)
FreeTagPickerdefault placeholder was a hardcoded"请输入标签", so it showed Chinese in every locale. It now usest("Input or select tags")— a key already present in all four locale files, just never wired up.commitQuery); Tab still advances focus afterwards. (Chose Tab rather than a general on-blur to avoid racing with dropdown option selection.)2. Tool tab
<span>{desc}</span>) while the tool name already went throught(). Descriptions now go through i18n too, andWelcomeBuilder's hardcoded Chinese description becomes an English i18n key.3. FullscreenEditor
${…}snippet placeholders such as 世界观 / 角色名 / 角色职业) was hardcoded Chinese. All routed through i18n now. (The single remaining Chinese in that file is a code comment, left untouched.)Notes
enandzh;ja/kogracefully fall back to English until translated.tsc -bpasses.npm run lintcurrently fails for everyone because the flat ESLint config references a non-existentno-unused-variablerule — happy to file that separately if useful.