Repository navigation
Simplified Chinese (zh-CN) catalog — built against 1.18.0, ready for review #1
Description
Simplified Chinese (zh-CN) catalog — built against 1.18.0, ready for review
Hi! First of all, thank you for AionCore — it's a great tool.
I noticed the app ships 6 languages (PT-BR, EN, ES, DE, FR, RU), and that idiomas.json already has a
status pipeline (published / draft / planned), per-language gates, and the
machine / reviewed flags in each catalog's @meta. There is no Chinese entry yet, so I built a
complete zh-CN catalog and I'd like to contribute it through whatever route works for you.
What I have
Files (public gist): https://gist.github.com/Wattls/50cc53e0e9e35dfcee4e9d03342a6495
—zh-CN.json(369,464 bytes, LF line endings, no BOM) plusidiomas-zh-CN-entry.json.
zh-CN.json— 4,628 keys, 100 % coverage of the pt-BR source of 1.18.0
(0 missing keys,"complete": 1), byte-for-byte the same layout as your other catalogs:
@metafirst, then keys in the exact order ofpt-BR.json."@meta":
{ "lang": "zh-CN", "machine": true, "reviewed": false, "sourceHash": "e03ae3cc548d46f2bc06daaa4fbb3affdfe4f17ef537d94ce688c99baf1938dd", "complete": 1 }
— the samesourceHashyour 1.18.0pt-BRcarries, since the catalog was built from that source.
(Note:en/es/de/fr/rucarry a different value,3a898412…— see the question at the end.)
Flagged as machine translation, native review pending, which is
exactly howen/es/de/fr/rustarted (DG-15) — those entries inidiomas.jsonuse
gates: { criticalReviewed: 0, legal: "rotulado-maquina" }, and I'm proposing the same for zh-CN.
How it was validated
I ran your own ICU formatter (i18n/message-format.mjs, unchanged between 1.17.0 and 1.18.0) over
every one of the 4,628 values and compared the parsed argument sets against the pt-BR source:
| Check | Result |
|---|---|
parse() syntax errors |
0 |
Placeholders present in source but missing in zh-CN ({name}, {count}, …) |
0 |
| Placeholders in zh-CN that the source does not have | 0 |
ICU plural / select / selectordinal branch keywords preserved |
0 missing |
| Keys falling back to the English text (possible untranslated) | 0 |
| Keys identical to pt-BR (possible untranslated) | 0 |
| Empty values | 0 |
Raw result: {"keys": 4628, "parseErrors": 0, "missingArgs": 0, "extraArgs": 0, "sameAsEnglish": 0}
Notes on the technical handling:
- Cardinal/ordinal plural in Chinese has a single form. Every
plural/selectordinalwas kept
structurally intact (sameone/other/=0branch keys, same nesting, same argument names), with
the Chinese text repeated inside each branch — the same approach your other catalogs take. #inside plural branches,{arg}nesting depth, andselectbranch names were left untouched.- Brand and technical tokens left as-is:
Aion,Aion 2,AionCore,NCSOFT,Discord,YouTube,
Npcap,WebView2,Windows, hotkeys (Ctrl+Alt+B), URLs, file names, log paths. - Combat-power abbreviation unified to
CP(your PT source usesPC, your EN usesCP; the Chinese
catalog follows the EN reading). - Terminology aligned with common mainland-CN MMO wording: boss → 首领, party → 队伍, raid → 团队,
dungeon → 副本, skill → 技能, overlay → 悬浮窗, hotkey → 快捷键, timer → 计时器.
Version tracking
I built against the catalog set that shipped in 1.18.0 (4,628 keys) — including the whole bot.*
in-app helper namespace, the app.update.disabled.* notices, and the WebP/radar notice from this
release.
For transparency, the deltas I have carried so far are: 1.15.1 → 1.15.2 = 39 added / 18 changed /
2 removed; 1.15.2 → 1.16.0 = 81 added / 6 changed / 0 removed; 1.16.0 → 1.17.0 = 46 added /
19 changed / 1 removed; 1.17.0 → 1.18.0 = 72 added / 1 changed / 0 removed. I can re-run this
delta whenever you publish a new version, so the catalog can be kept current until it lands in your
pipeline.
One question about sourceHash in 1.18.0
Until 1.17.0 every catalog carried the same sourceHash, so it read naturally as "hash of the
pt-BR source". In 1.18.0 it splits into two values:
| Catalog | sourceHash |
|---|---|
pt-BR |
e03ae3cc548d46f2bc06daaa4fbb3affdfe4f17ef537d94ce688c99baf1938dd |
en / es / de / fr / ru |
3a89841211a46c16232e9690f468b8c84762de7f6470466caf979e134ac4119e |
I could not reproduce either value from the catalog files themselves (I tried ~30 serialisations:
raw bytes, @meta stripped, various indents/sort orders, per-entry joins). Could you say which is
right for a machine-translated catalog that was built from the shipped pt-BR source?
- (a) it should carry the pt-BR hash
e03ae3cc…— what I did in the gist; or - (b) it should carry the machine-batch hash
3a898412…, the same asen/es/de/fr/ru?
Either way it is a one-line change on my side.
Region naming (please sanity-check for your market)
Where the source says Taiwan, the catalog uses the official form 中国台湾 (Taiwan, China). This
affects 10 keys: app.region.name.taiwan, app.region.describe.taiwan, firstrun.region.taiwan,
firstrun.region.thailand.sub, agenda.region.taiwan, agenda.thailand.note, guide.mec.reg.tw,
feedback.region.name.tw, settings.eventos.regiao.keywords, settings.medidor.recursos.campo.desc.
Flagging it explicitly so it isn't a surprise — happy to change the wording if you prefer otherwise.
What I need from you
Since the source code is not public, I can't open a normal PR against the catalogs. Which do you prefer?
- I send you
zh-CN.json(plus theidiomas.jsonentry below) and you run it through
node tools/i18n/i18n.mjs checarand publish it as adraft(orpublished) language; or - you point me to the repository/branch where the catalog should land and I open a PR there; or
- any contributor route you'd rather use (
contato@aioncore.app).
Suggested idiomas.json entry — please confirm windowsLangId, innoName, innoIsl and
datamine.global against your tooling; I inferred them from the existing entries:
{
"code": "zh-CN",
"autonym": "简体中文",
"autonymShort": "中文",
"flag": "cn",
"dir": "ltr",
"pluralRules": { "cardinal": ["other"], "ordinal": ["other"] },
"windowsPrefixes": ["zh-Hans", "zh-CN", "zh-SG", "zh"],
"windowsLangId": 2052,
"innoName": "zhcn",
"innoIsl": "compiler:Languages\\ChineseSimplified.isl",
"electronPak": ["zh-CN"],
"datamine": { "global": "zh" },
"site": { "status": "planned", "path": "zh", "ogLocale": "zh_CN" },
"status": "draft",
"gates": { "criticalReviewed": 0, "legal": "rotulado-maquina", "motivo": "Machine-translated initial catalog, syntax-checked; native review pending." }
}One caveat worth your call. Your existing entries use bare language prefixes ("pt", "en", "fr"),
but a bare "zh" would also match a Traditional Chinese (zh-Hant-TW) Windows, silently dropping
those users into the Simplified catalog. That's why I propose the explicit, ordered
["zh-Hans", "zh-CN", "zh-SG", "zh"] — zh-Hans/zh-CN/zh-SG are matched before the generic zh.
If your matcher only handles bare prefixes, take ["zh"] and consider adding a zh-Hant catalog later
so parentTag() can do its job. Your call.
Legal / consent texts
The legal and consent texts (consent.*, legal.*, site.*_consent.*, site.telemetry.*,
site.field.*, site.never_sent.*, firstrun.*) are machine-translated and not human-reviewed.
Per your legais gate they should carry the machine-translation badge (legal: "rotulado-maquina") and
stay out of published until a native speaker reviews them — same as EN/ES/DE/FR/RU today. I'm glad to
do a focused second pass on just those keys if you want them cleaner before publishing.
Thanks again — the file is in the gist linked at the top; happy to re-send it however you prefer
(PR to a branch, e-mail to contato@aioncore.app, …). I can also keep it in sync with new releases
until it lands in your pipeline.
Activity
filvoch commentedon Oct 19, 2026
Hi @Wattls, thank you very much for this, and sorry for the slow reply. We checked your gist (last updated 19 Oct) against the pt-BR catalog of 1.20.1:
sourceHash9f1aae0a…is exactly the pt-BR hash of 1.20.1.Your questions
sourceHash: it is (a), the pt-BR hash. In current releases every catalog carries the pt-BR hash while it is up to date. The two values you saw in 1.18.0 were a transitional state with stale keys. When we import a catalog our tooling recomputes the@metaanyway.draftlanguage (not in the language picker and not in the installer), through our own validation (aplicar --validar, ICU and glossary checks) and then an independent review of the meaning, especially the consent and legal keys, which stay labeled as machine translation. Nothing ships before that, and publishing needs the CJK font and layout work on our side first.idiomas.jsonentry: we will correct the fields ourselves. We still have to checkdatamine(we have no Simplified Chinese game-name data for Global) and the Inno Setup language file. Your orderedwindowsPrefixes(zh-Hans,zh-CN,zh-SGbefore barezh) is a good point and we will keep it.i18n/folder in this repository, with issue labels and templates, so translations can come as pull requests. We will ping you here when it is ready; until then there is no need to resend anything, the gist is fine.One request: when that route is ready, we would like to use your translation under short contribution terms that we will publish in
CONTRIBUTING.md(use in AionCore, with credit if you want it). Please tell us here if you agree, and how you would like to be credited, if at all.Your offers are welcome: a second pass over the consent and legal keys, and keeping the catalog in sync with new releases. Are you a native Simplified Chinese speaker? It helps us to know how to label the review status.
filvoch commentedon Oct 19, 2026
@Wattls the pull request route is now open.
i18n/folder has the source catalog (pt-BR.json, from 1.20.1), the five published translations, a glossary and a translator's guide.CONTRIBUTING.mdhas the rules, how we recognise contributors and the short contribution terms (please read the Contribution terms section).node scripts/validate-i18n.mjs, Node 20+) runs on every pull request that changesi18n/.Please open a pull request that adds
i18n/zh-CN.json(from your gist; keep"machine": true, "reviewed": false, and set@meta.langtozh-CN). In the pull request, tick the contribution terms box and tell us how you want to be credited, if at all. Include your legal/consent second pass in the same pull request or a later one.It will enter the app as a draft after our own checks and a review of the meaning. About the Taiwan wording: we are still leaning towards the plain form for the server region and will confirm it here.
Thanks again!
Wattls commentedon Oct 21, 2026
Hi @filvoch — PR opened: #4 (
i18n: add Simplified Chinese (zh-CN)).i18n/zh-CN.json, 5,254 keys, same set and same order as youri18n/pt-BR.json,node scripts/validate-i18n.mjspasses locally and in CI.@metakept asmachine: true, reviewed: false, complete: 1,@meta.lang = zh-CN.Two things I'd like your call on
Hidden Cube→ 隐藏背包,Kinah→ 基纳,Combat Power→ 战斗力,Odyle energy→ 奥德能量,Abyss Points→ 深渊点数. Players see those exact words in the game client, so the meter matching the client matters more than matching the English UI here. If your glossary prefers the English originals, it is a mechanical replace — say which way you want it and I'll do it in one go.gainvsbuff. I use 收益 forgain(the rDPS explanation) and 增益 forbuff. Translating both as 增益 produces 队友增益增益 / 增益带来的增益. If your glossary pairs them differently, tell me and I'll align.Taiwan wording: left as the plain form (台湾 / 台服) as you preferred — that's your call on a server-region label, and I don't want to hold up the catalog over it.
Two things that may be useful to you
i18n/pt-BR.jsonin the repo is from 1.20.1, but my working catalog tracks 1.20.5 (5,583 keys: 15 added, 3 removed, 1 changed). Ping me when the source catalog is bumped and I'll send the full 5,583-key version in one PR, so it doesn't drift.datamine). The NPC and skill names are not in thei18ncatalogs at all — they live in the meter's embedded tables, which is why 战斗历史 and the HUD skill list are still English in 1.20.5 even with zh-CN selected. I do have the official zh-Hans name data for 9,780 NPCs and 9,268 skills (id-matched against the English names) and a 3,066-entry capped mapping that fits the meter's byte budget. If it's useful I'm happy to hand over the lists in whatever format your build pipeline wants, so the names can ship through your tooling instead of a local patch.filvoch commentedon Oct 21, 2026
Hi @Wattls, thank you, this is exactly what we hoped for. We went through PR #4 and your notes.
Your two questions
gainvsbuff: 收益 / 增益 is fine. We will keep that pair.One thing we noticed: your catalog uses 您 (82 times) where our 1.20.5 draft uses 你. You are the native speaker, so we will follow your tone unless you tell us 你 reads better for a game UI. Your call.
How we will take it
i18n/pt-BR.jsonto the current release; we will ping you here when it is done.Game names (NPCs and skills): yes, please. You are right that those live in the meter's embedded tables, not in the catalogs, which is why the combat history and the HUD skill list are still in English with zh-CN selected. We would gladly take your official zh-Hans lists (9,780 NPCs and 9,268 skills, matched by id). Plain JSON
id → nameis fine; we will fit it to our build and the byte budget. Please share it under the same contribution terms. We will confirm the exact place for it here before you spend time on a PR.Credit: noted as Wattls (GitHub). It will appear in the repository README and in the app's About screen, and we will say there that the Simplified Chinese catalog is his work.
Thanks for the careful work, and for keeping it in sync across releases.
filvoch commentedon Oct 21, 2026
@Wattls, two updates.
i18n/is now refreshed to release 1.20.6 (pt-BR.jsonsource plus all translations and the glossary). Your game terms are in the app and the site (隐藏背包, 基纳, 战斗力, 奥德能量, 深渊点数; 收益 / 增益 for gain / buff), and Wattls is credited in Settings › About of 1.20.6.Next, if you are willing: please open a PR with the full catalog for this source (the 1.20.6
i18n/pt-BR.json; your 1.20.5 delta is a subset). We import it through our checks as before.Two decisions we would like from you
Game names (NPCs and skills): thank you again for offering. We will confirm here the file format and where to put it before you spend time on a PR.
i18n(zh-CN): full catalog for the v1.20.6 source
Wattls commentedon Oct 21, 2026
Both answers are in #5 (
i18n(zh-CN): full catalog for the v1.20.6 source, validator green), but here they are directly:您 vs 你 → 你. Your count was right, and the inconsistency was mine:
legal.*andconsent.*were already 你, whilesupport.*,site.first_access.*,cfg.cubes.*,radar.rel.*andsettings.overlays.*had drifted to 您. A game UI should not change register between two neighbouring screens, and 您 reads stiff on a damage meter. All 87 remaining keys are 你 now, so the full catalog is one tone.Rift → 裂缝. This is settled by the client's own zh-Hans name data rather than by preference:
Rift→ 裂缝Time Rift→ 时间裂缝Rift Zone Swarm→ 裂缝地带虫子 (plus ~55 moreRift Zone …entries)裂缝 occurs 60+ times in the name data; 裂隙 occurs zero times. My catalog had 5 stray 裂隙 keys, all fixed. Worth adding to the glossary so it does not drift back.
Dungeon → 副本. The client has no generic label for it (dungeons are listed by proper name only: 克劳洞穴, 乌努库库峡谷…), so this one is convention: 副本 is what the Aion client and Chinese players use, and my catalog used it in all 78 keys with no 地下城 / 地牢 / 迷宫 variant anywhere.
The alternation you spotted is almost certainly these two keys, where the English source disagrees with the pt-BR one:
mech.category.colisaoguide.mec.cat.colisaoThe key and the pt-BR string say collision, the English says Dungeon. I translated by the pt-BR semantics. Tell me which is intended — if that category really is "Dungeon" the two become 副本 and I'll send a follow-up; if it is "Collision",
en.jsonis what needs the fix.cfg.about.translator.zhis translated too:简体中文翻译：{name}（GitHub）. Thank you for the credit — nice to see it land in About.One question on the 1.20.6 refresh:
i18n/pt-BR.jsonis byte-identical to 1.20.5 (same 5,584 keys, samesourceHash fec002c2…), so this catalog is the full set for the current source, not a delta. If 1.20.6 was supposed to carry new strings, the refresh may have picked up the wrong build — otherwise all good and nothing to do.Still holding on the NPC/skill name lists as you asked — plain
id → nameJSON is ready (9,780 NPCs / 9,268 skills, id-matched against the English names), just say the path and the format and I'll open it.filvoch commentedon Oct 21, 2026
@Wattls, thank you, this is great, and the catch on the 1.20.6 refresh was right. Everything below.
Decisions: all adopted
The
Dungeon/ 碰撞 question:enis the intended one. That category is the game's own category 600011, which the English client calls "Dungeon"; the Portuguese client calls the same category "Colisão". So pt-BR and en are two names for one thing, and the zh-CN should be 副本 (or the Chinese client's label for that category, if you can see one). Please include the two keys (mech.category.colisao,guide.mec.cat.colisao) as 副本 in your catalog.About the 1.20.6 refresh: it carries exactly one new string,
cfg.about.translator.zh(you already translated it). The real problem was on our side: the@meta.sourceHashinside the publicpt-BR.jsonis kept by hand and had gone stale since 1.20.5, so you copied the old value (fec002c2…) and our importer, which checks it against the real hash, would refuse the PR. That was our bug. We fixed the export so the public file carries the real hash, and the publicpt-BR.jsonnow hassourceHash=1e81ce42df760d1ca1a41fbf195e6c1681b2199bde1b8345703f43eb6511a2b7.What we need from you on PR #5: please update
@meta.sourceHashini18n/zh-CN.jsonto that value (and the two Dungeon keys, if you agree). Nothing else changes, and the check on your PR should stay green against the newpt-BR.json. We will then import it through our own checks as before.NPC and skill names: yes please. Our files are plain
{"id": "name"}objects, one per language and kind (npcs.json,skills.json), so exactly your format works. Please don't open a PR for these: this repository only holds the UI text. Attach them to this issue as a zip (drag and drop works), or share a gist, and tell us if the ids are the ones the game uses on the wire (we match them to the English names). We will fit them into our build on our side and credit you for the data too. Thanks again for the care.Wattls commentedon Oct 21, 2026
Name lists — ready now, I only needed your word on the where.
What I have, plain
id → name, UTF-8 JSON, sorted by id:zh-Hans-npcs.jsonzh-Hans-skills.jsonAbnormal_TRUE,HPHeal…)Omitted on purpose: 1,124 NPCs and 38 skills where the client text is identical to English, plus 573
???placeholders. A missing id means "use the English name" — nothing is silently empty.One gotcha worth knowing. Ids
2000000/2000001(Punching Bag) are deliberately left in English. The meter's embeddednamestables are told apart by the value of2000001(Punching Bag/Sandsack/Мешок с песком…), so localising it breaks detection. If your build keys the tables by id instead of by that probe, translate them like any other entry.Where to put it: say the path —
i18n/names/zh-Hans-npcs.jsonandi18n/names/zh-Hans-skills.jsonwould be my guess — and I'll open the PR in a few minutes. If you would rather not carry datamined client text in a public repository, say so and I'll send both files tocontato@aioncore.appinstead. Your call; I'm not going to publish them without it.Optional bonus: I can add
isBossto each NPC entry so the combat history can filter bosses without a second lookup. Costs me one line if you want it.Wattls commentedon Oct 21, 2026
Done on both, and thank you for the sourceHash explanation — good to know the value is maintained by hand rather than computed, that is exactly the kind of thing that silently breaks a PR.
PR #5 updated (commit
10c2dbf):@meta.sourceHashis now1e81ce42df760d1ca1a41fbf195e6c1681b2199bde1b8345703f43eb6511a2b7, and both Dungeon keys are 副本. Nothing else changed;validateis green against the refreshedpt-BR.json. Verified on the pushed file: 5,584 keys, 0 remaining 您, 0 remaining 裂隙.On category 600011: I looked, and the client's name data has no generic label for it — dungeons are listed by proper name only (克劳洞穴, 乌努库库峡谷…), with
difficultyas the only extra field. So there is no Chinese client label to copy; 副本 it is, by the same convention as the other 78 keys.Name lists — gist, as you asked (unlisted, no PR):
https://gist.github.com/Wattls/c41d123b00ecdf4abc10386154fde7a7
zh-Hans-npcs.json— 8,081 entries,{"id": "name"}exactly like your fileszh-Hans-skills.json— 9,230 entrieszh-Hans-names-README.md— the two caveats, in case they matter to your buildYes, the ids are the wire ids. Evidence rather than assurance:
namestable — 7,796 of the 8,081 exported ids appear in that 8,674-entry table.target_mob_codemy meter has ever recorded from the packet stream (151 of them). 149 have a Chinese name in this list. The other two are correct absences, not gaps:2920174isEarth Spirit, which the client leaves in English in both languages (so it is omitted by the "zh == en" rule), and2920503is a???placeholder.So every id the game has actually sent me resolves — a missing id in the file means "same as English", never "unknown".
Your credits are appreciated more than you probably realise. Tell me if you would rather have the
isBossflag inline; it is one line for me and saves you a second lookup.filvoch commentedon Oct 22, 2026
@Wattls, thank you, all received.
PR #5. We saw the update (the
sourceHashand the two 副本 keys,validategreen). Our importer is the stricter gate (it also checks our glossary, keep-as-written terms and edge spaces), and your catalog differs from our glossary in a few places that we have to reconcile on our side (Rift/裂缝, Dungeon/副本, a few "never translate" names such as AionCore Meter, and some leading/trailing spaces). We are doing that now and will import it as a machine-translated draft with the seal, keeping the consent/legal/privacy keys out until we review them. Please leave PR #5 open as it is; once it is in a release we will close the loop here. The merge button is the owner's, so your commit will count in the contributors list.Name lists. Got the gist, thank you, and thanks for the evidence on the ids. We are integrating
zh-Hans-npcs.jsonandzh-Hans-skills.jsoninto the meter's own name tables, with "missing id = English name" as you designed it. Notes:isBoss: not needed for now, thank you. We will tell you if that changes.We will post here when the draft is ready to test. If you are willing, we would love your eyes on a build in Chinese before it ships.
i18n(zh-CN): align edge whitespace and keep-as-written names with the…
i18n(zh-CN): edge spaces and keep-as-written names
Wattls commentedon Oct 22, 2026
Thanks for merging #5. One thing worth flagging: it merged at
10c2dbf, and I had pushed a second commit two minutes later — so main has the pre-fix version of a few keys. Rather than leave you to reconcile, I went and audited the two categories you named.PR #6 → 15 keys,
validategreen, nothing else touched: #6Edge spaces — 4 keys. You were right, and these are worse than cosmetics: the space is the join.
meter.format.parts_separator' · ''·'' · 'win.session.player.overheal_suffix' · cura efetiva …''· 有效治疗 …'' · 有效治疗 …'guide.video.playlist_prefix'Playlist · ''播放列表 ·''播放列表 · 'app.diag.readme{files}\n{files}{files}\nI had collapsed them on the theory that Chinese does not want edge spaces — true for prose, wrong for these four. Left as they are in main, the UI renders
DPS·HPS, glues a heal suffix to the number before it, and glues a video title to 播放列表.Keep-as-written — 11 keys.
AionCore Meterin 6 keys (I had translated it to 统计器;cfg.account.retentionhad also lost a character and read 「AionCore 统计」 — a genuine typo, my fault), andAion 2in 5 keys (I had used 《永恒之塔 2》 — the Chinese title from the first game; on Global the client says Aion 2, so Latin is right).Answering the rest:
isBoss: dropping it, no need to ask again if that changes — it is one command.filvoch commentedon Oct 22, 2026
@Wattls, thank you, this is exactly the kind of catch we needed (the glued
DPS·HPSwas the worst one). We had already restored the edge spaces and the keep-as-written names (Aion 2,AionCore Meter) in our own import, so PR #6 matches what we did; we will check the two against each other before shipping.Credit wording, for your eyes. This is what Settings › About will show in Simplified Chinese (the title and the role line next to your name, which is a link to your GitHub):
Does that read naturally? If you would prefer 致谢 / 贡献者 or a different role wording, tell us and we will use yours.
Chinese build: yes please, thank you. When the draft (catalog plus the NPC and skill names) ships we will post here exactly what to install. Your three suggestions are the right ones to check: text that wraps badly, terms that do not match the client, and the consent/legal block. The mechanical diff of every NPC and skill name against the client data would be a great second check once the name tables are in.
Gist stays up until we say the integration shipped. Thanks for dropping
isBoss.filvoch commentedon Oct 22, 2026
@Wattls, both drafts are in our main now (for the next release): your catalog (#5 and #6, with your support-page texts and tone 你) and the NPC/skill names. Where you gave an opinion we used yours; where you did not (统计 vs 统计器 for the meter, 全球服 for Global, 奥德能量 for Odyle) we kept our glossary choice, and we would like to hear if you disagree. We will post here what to install once the release is out.
Wattls commentedon Oct 22, 2026
A few strings in the settings panel and the event list are wrong or untranslated. Not reopening anything we
already settled.
settings.medidor.recursos.shugo.title— shipped as 「显示休古钥匙」. The game's own zh-Hans table hasSecret Shugo Weapon→ 树古秘密兵器, so Shugo = 树古. (My earlier file had 舒戈, which was wrong.)rules.event.name.shugo— 「休古庆典与小游戏」 → 「树古庆典」. The client's event list shows just「树古庆典」, and a timer that names the event differently from the game reads as a different event. If you
want "minigames" kept in the label, that's your call — I only made it match the client.
settings.medidor.recursos.ludra.title/.desc— still 「显示 Ludra」 and 「深渊重铸：Ludra」.Eternal Ludra→ 永劫卢德莱, so Ludra = 卢德莱.settings.medidor.recursos.muspel.title/.desc— still 「显示 Muspel」 and 「Muspel 圣杯」.Muspel Guardian Statue→ 穆斯费尔守护像, so Muspel = 穆斯费尔. These two were never translated in thefirst place — my fault, they're on me. I also dropped "Chalice": it isn't a game term anywhere in the client
tables (
chalice/cálice/ 圣杯 = 0 hits), so a Chinese player would be looking at a name the game nevershows. If it's your own label for that counter, say so and I'll put 「穆斯费尔圣杯」 back.
mech.category.colisao/guide.mec.cat.colisao— I asked you for 副本 for category 600011; I was wrong.The client's own header for that menu is 「远征」, so 远征 is the term that matches the game. My commit
put 副本 into the glossary — that one's on me too.
mech.category.santuario+ the strip texts — 圣所 → 圣域. The client keeps two words apart:Sanctumis 圣所 (Sanctum Barghest = 圣所地狱犬, Sanctum Watchtower = 圣所监视塔),Sanctuaryis 圣域(Sanctuary Guardian = 圣域守卫). The strip lists sanctuaries, so 圣所 was the wrong word there.
Delta for those keys and the handful of strings that mention them:
https://gist.github.com/Wattls/8a2928c2ffdf813c9258b5269a5b0bc4 — key set unchanged, nothing else touched.
filvoch commentedon Oct 22, 2026
@Wattls, AionCore 1.21.0 is out and the public
i18n/is refreshed from it. It includes: your catalog (#5 and #6, with your support-page texts and the 你 tone), the Simplified Chinese NPC and skill names from your gist, and the credit in Settings › About ("Simplified Chinese translation and game names"). Where you did not give an opinion we kept our glossary choices (统计器, 全球服, 奥德能量); tell us if you disagree.To try it: install the update (or the latest installer from the release page), set the language to 简体中文 in Settings, and check the meter, Settings, the support tab and the NPC and skill names. The three things you offered to look at are the right ones: text that wraps badly, terms that do not match the client, and the consent/legal block. You can keep or remove the gist now; thank you again.