FontLab localization: Traditional Chinese

A first draft for Traditional Chinese. A model researched the guidance below and the term table in references/terms.md; no native reviewer has approved the language as a whole. Individual terms carry their own approval status; a proposed term remains proposed, and a protected name keeps its glossary spelling. The Traditional Chinese interface catalogs are unfinished machine drafts: a string found in one settles neither a term nor a rule.

Use references/terms.md, and a newer core memory when one is supplied, for terminology, definitions and review status. Keep a proposed term consistent across the interface and help, and report it as proposed. Where a native reviewer's decision or newer project data disagrees with this skill, follow it and record the change. Report only checks performed: text written with this skill is not reviewed by a native speaker and not tested in the running application until someone does that.

Use these rules with the localization principles (in fontlab-localization), Qt interface rules (in fontlab-localization) and Chinese (Traditional) language guide (in the FontLab writing guide). Examples name their source (qtbase_zh_TW and linguist_zh_TW are Qt's catalogs) or are marked constructed. They show grammar; the term table decides terms.

Locale and register

• Locale zh-hant, Qt catalog zh_TW: Traditional Chinese as written in Taiwan, with the punctuation of the Ministry of Education's 《重訂標點符號手冊》. Translate from the English; never convert Simplified Chinese text.
• Leave the user unnamed: Chinese drops the subject. Where a pronoun is unavoidable, write 您, as Windows, Qt's catalog, Glyphs and FontForge do. Apple writes 你; FontLab does not. The application never says 我 or 我們.
• Plain written Chinese, neither bureaucratic (倘若) nor chatty (喔). No exclamation marks. 請 appears only in a sentence that asks the user to act (請再試一次。 Please try again., Font Book), never in a label.

Grammar of interface strings

String	Form	Example
Menu command	verb + object; no subject, no 請, no 。	新增錨點 (Add Anchor, Glyphs)
Button	verb of two to four characters	取消, 安裝 (Cancel, Install, Font Book)
Checkbox or toggle	verb + object naming the on state; no 是否	顯示資訊面板 (Show Info Pane, Font Book)
Panel or dialog title	noun phrase	字型資訊 (Font Info, Glyphs)
Status, in progress	正在 + verb + object, never …中	正在列印字型 (Printing Font, FontForge)
Success	已 + verb, before or after the object	%@ 已下載 (%@ downloaded, Glyphs)
Failure	無法 + verb + object + 。	無法在這裡新增像素。 (Can’t add pixel here., Glyphs)
Empty or not done	沒有 + noun, 未 + verb	沒有警告或錯誤, 未選取 (No Warnings or Errors, not selected, Font Book)
Confirmation	確定要 + verb + object + 嗎？	確定要刪除「%@」嗎？ (Are you sure you want to delete “%@”?, Font Book)
Tooltip	description without a subject	匯出此主版的度量與調距資訊。 (Exports metrics and kerning information of the current master., Glyphs)

A rule about a value takes 不能. A third-person English tooltip (Exports…) becomes a bare verb (匯出…). Cannot, Could not, Unable to and Failed to are all 無法; cannot find is 找不到 (找不到網路, Could not find network, Glyphs). Do you want to…? is 是否要…？. Add 成功 only where the source says successfully.

Compact labels

Shorten by removing function words, not by abbreviating. Drop 的, 一個, 進行, 可以 and 您的 wherever the phrase stays unambiguous: 匯出字型 (Export Font, Glyphs), not 對字型進行匯出. Prefer two-character verbs: 新增, 匯出, 移除.

Never shorten a term from the term table or drop a classifier after a count. Keep the Latin short forms the source uses (UC, lc, UPM, PPM).

Plurals and placeholders

Qt gives Chinese one numerus form (nplurals=1; plural=0;). Write one <numerusform> that reads correctly for 0, 1, 2 and 100, and drop the source's (s): 已翻譯 %n 個條目 (Translated %n entry(s), linguist_zh_TW). Avoid words that presume several: 這些, 多個, 各.

A count needs a classifier between the number and the noun. 個 is the default; use the specific one where the noun has it: %{value1}@ 件問題 (%{value1}@ issues, Glyphs), 組 for pairs, 筆 for records, 種 for kinds, 次 for times. Never add 們.

A placeholder that stands for a name or a noun needs no ending or particle: Chinese has no gender or case. Reorder numbered placeholders freely: 要使用 %2 上的 %1 需要驗證。 (Authentication needed to use %1 on %2., qtbase_zh_TW). An ordinal is 第 %1 個.

Numbers, punctuation and spacing

• Numbers: 1,234,567.89; 25% with a half-width sign and no space. Digits and Latin letters are always half-width ASCII, never ＡＢＣ or １２３.
• Han–Latin spacing: put one ordinary space (U+0020) between a Han character and a Latin letter, a digit or a placeholder: 關於 %1 (About %1, qtbase_zh_TW), 匯入 TrueType 集合 (Import TrueType Collection, Glyphs). Microsoft and Qt's catalog do this; Apple's interface writes no space. No space beside a full-width mark or a quotation mark, before (&X), or between a number and %.
• Full-width marks in every string that contains Chinese: ， 。 ： ； ？ ！ 、 （ ）, with no space on either side. A label colon is ：: 色調(&E)： (Hu&e:, qtbase_zh_TW). Microsoft's style keeps :, ? and ( ) half-width; FontLab follows Qt's catalog and the handbook. Join parallel items with 、: A、B 和 C. A Taiwan font centres these marks in the em box: never substitute a character or add a space to move one.
• Half-width marks in code, paths, numbers (1,000, 12:30), markup, strings that stay wholly Latin, and the mnemonic (&X).
• Quotation marks: 「…」, with 『…』 inside, no spaces around them: 未知選項「%1」。 (Unknown option '%1'., qtbase_zh_TW). Never “…”. A source 'x' or "x" around a name becomes 「x」; straight quotes stay in code and inside HTML tags.
• Ellipsis: copy the source's ... or … unchanged and in the same position. Never …… or Apple's ⋯ (U+22EF).
• Final period: 。 where the source ends with a period, none where it does not. A source ! becomes 。.
• Whitespace: keep the source's leading and trailing spaces, \n and \t. Never add a space, a break or U+3000 to shape a line.

Mnemonics and key names

• Append the source's mnemonic letter, uppercase, in half-width parentheses with no space before it: 開啟(&O) (&Open, qtbase_zh_TW). It goes before a final colon or ellipsis: 色調(&E)：; C&ustom... becomes 自訂(&U)... (constructed).
• Write exactly (&X): Qt strips that pattern on macOS.
• Keep the source's letter, so sibling items stay unique. Never put & before a Han character; add no mnemonic the source lacks. A label that stays Latin keeps its & in place.
• && is a literal ampersand: write 和 or keep &&, never a single &.
• Key names stay in Latin script as the source spells them: Shift, Ctrl, Alt, Option, Cmd, Enter, Esc, Tab, Delete, Backspace. Space is 空白鍵 (Apple, Qt); arrows are 向上鍵, 向下鍵, 向左鍵, 向右鍵. Keep Ctrl+S as written; add no 鍵 after a Latin key name.

Names and loans

• Latin script, exact case, no transliteration: product, company, typeface and personal names (FontLab, OpenType, PostScript, Unicode, Python), format names (VFJ, UFO), feature and table tags (kern, OS/2), glyph names, extensions, unit symbols and code.
• Embed a Latin name with a space on each side and its class noun after it: Qt 外掛程式 (Qt plugin, qtbase_zh_TW). No 《》 and no quotation marks around a product name unless the source quotes it.
• Translate language, script and country names. An ordinary English word (layer, node) never stays in English, and a Chinese term is not followed by its English original in parentheses.

Script-specific rules

• Traditional characters in Taiwan's standard forms: 裡, 線, 為, 著; not 裏, 綫, 爲, 着.
• One Simplified character can be several Traditional ones: 后 is 後 or 后, 干 is 乾 or 幹, 复 is 復 or 複 (復原, 複製).
• Han characters have no case: keep case only inside Latin names and identifiers.

False friends and traps

The term table gives the term. These are the senses to reject.

• Mainland words, Taiwan word first: 檔案 not 文件 (in Taiwan a document), 設定 not 設置, 預設 not 默認, 視窗 not 窗口, 儲存 not 保存, 軟體 not 軟件, 程式 not 程序, 資訊 not 信息, 字型 not 字體, 匯出 not 導出, 復原 not 撤銷, 貼上 not 粘貼, 列印 not 打印, 滑鼠 not 鼠標, 螢幕 not 屏幕, 選單 not 菜單, 支援 not 支持, 相容 not 兼容.
• glyph is not character (字元). 字符 is ambiguous: the mainland word for character, and Glyphs' word for glyph; use it only as the term table says.
• script is a writing system (文字系統, qtbase_zh_TW) or a Python script (腳本, Glyphs): read the control.
• hinting is not 提示 (a tooltip); outline is not 大綱; a font table is not 表格; an OpenType feature is not 功能; weight is not 重量; master is not 大師; instance is not 範例.
• Machine-translation habits to remove: 被 passives (已被忽略 becomes 已忽略), 進行 + noun, 一個 for a, 當…時 for every when, 和 joining two verbs (use 並), 它, half-width commas, and long modifiers stacked before 的.

Review

Check in this order:

1. Placeholders, markup, \n and mnemonics (&X) match the source.
2. Each numerus entry: one form, with a classifier, right for 1 and for 100.
3. A space between Han and Latin or digits; full-width ，：（）; 「」, never “ ”.
4. No Simplified characters, mainland vocabulary, wrongly converted characters or 你.
5. Terms match the term table: one concept, one term.
6. Form by role: command, title, 正在…, 已…, 無法….
7. Would a type designer in Taiwan say it this way?

FontLab terminology and compact labels

Preserve deliberately uppercase source labels using the language’s case rules. Keep numeric controls compact with UPM, PPM and LSB/RSB (French AG/AD); explain the full terms in help. The Family Dimensions “Units Per eM:” label is an intentional expanded exception.

Use the current core memory and its approval status. OpenType lookup defaults to the translation of procedure, with a different term only when strong OpenType-specific evidence supports it. Explicit choices are German Lookup, French lookup, Polish procedura and Russian процедура. Ordinary searches, individual rules and OpenType features are separate concepts. Preserve literal code keywords and identifiers.

Translate Fusion with the fallback Welder. Use the core's phonetic FontAudit transliteration in non-Latin scripts, including Chinese; preserve FontAudit in code. Proposed spellings remain proposed. Before rebuilding a QPH, recover team edits and import their terms and notes into the core memory.

Compare mnemonic-split terms with unmarked labels. Keep labels compact, aiming for 120% of the English length in Dimensions and Glyph Window preferences without losing meaning. Omit redundant font, color or command wording when context supplies it. TTH labels can omit “use” and abbreviate TrueType hinting; help can explain more. A full harmonization requires three complete catalog reviews, then reconciliation of help with the final UI and verification of generated resources.

Run the review as a loop

The Review list above is this skill's checklist. Run it on each portion as H17 describes: one item at a time against source, target and the term table; name the string behind each answer; repair what fails and recheck it. Stop after three rounds and report what still fails.

References

• references/terms.md: the full Traditional Chinese term table, generated from the core memory zh-hant-core.tmx of the writing guide, with the status, translator note and definition of every term.
• The Traditional Chinese localization guide of the writing guide is the source of the sections above.

Related skills

fontlab-localization for the shared rules; fontlab-terminology for product names and shared nouns; fontlab-technical for Traditional Chinese help text.

House rules

These rules implement the FontLab writing guide. They are copied into every skill so each installed skill can work independently. Corpus measurements can inform review; they are not quotas, universal laws, or tests of authorship.

H1. Accurate actors. Address the reader when they act or choose. Name the application when it performs an operation. Fonts and files contain data that software interprets. Prefer active voice when the actor matters; retain a clear passive construction when the actor is unknown or irrelevant. Never invent an actor or cause to change the grammar. When an English sentence pairs a reader action with the software's response, give each clause a subject and restate the action compactly: “If you generate a glyph with Aidus, FontLab generates each master independently.” Name the most specific responding surface the evidence supports (a window, tool or dialog), otherwise the application. Use present tense for an immediate result. Where a glossary entry exists and the surface can link, link a domain term to it rather than defining it in an apposition.

H2. Never invent a fact. Ground numbers, names, dates, labels, shortcuts, defaults, errors, versions, and quotations in supplied or checked evidence. A draft is evidence of what was written, not independent proof of its claims. Mark unresolved facts with a specific working placeholder such as [VERIFY CLAIM], [CONFIRM LABEL], or [CONFIRM OFFER]. A marked draft is unfinished; resolve the gap before publication. Clearly label fictional examples before their invented details.

H3. Preserve certainty and scope. “May reduce” does not become “eliminates.” Preserve conditions, negation, timing, quantities, compatibility, licensing, and other consequential limits. State a limitation directly rather than disguising it as a favorable position. A single observation does not prove universal behavior. Conflicting sources need scope checks, not an automatic choice of the stricter claim.

H4. Preserve the writer's voice. Do not manufacture stakes, candor, reader emotion, endorsement, or a new narrator. Preserve useful habits and the supplied stance. Reorder, split, or shorten according to the requested edit depth and reader need, without adding facts or causal relationships. A correct draft can remain unchanged.

H5. Give thought a rhythm. Carry a subject through an action, distinction or consequence. Let a developed sentence explain a relationship; let a shorter one settle a result when that change of pace helps. Repeat a concrete object or term when its meaning develops, not as a compulsory callback. Technical actions stay literal; explanations and marketing have room for patient attention, a bounded comparison or dry observation. Keep useful qualifications beside their claims. Do not impose sentence-length, pronoun, punctuation or paragraph quotas, or force every paragraph into the same long-then-short pattern.

H6. Notice the useful detail. Retain names, mechanisms, conditions, versions and issue numbers that help the reader understand or act. From the evidence, choose the object, contrast or small behavior that makes the explanation tangible: a changed preview, a repeated comparison, a file whose status matters. Follow that detail far enough to explain its significance. Warmth can come from this attention and patience. Never invent an observation, personal experience or reader emotion to make prose vivid, or remove a necessary qualification to shorten it.

H7. Punctuation serves meaning. Prefer a colon for an explanation or list. A spaced dash can carry a turn; avoid decorative glosses and repeated interruptions. Use sentence case for new headings and preserve exact source labels. A punctuation pattern does not establish authorship.

H8. Choose precise words. Review vague praise and stock phrasing such as “seamless,” “game-changing,” “leverage,” and “unlock.” Replace them when they obscure the action or make an unsupported claim. Keep an accurate technical use or protected quotation. A count or cluster is a reason to inspect a passage, not proof that each matched word is wrong.

H9. Develop the explanation. Begin where the reader can understand the task, change or offer. Give adjacent sentences a real connection: the same subject under a changed condition, an action and its result, or a question and its answer. A before-and-after comparison needs evidence for both states; a transition must not invent causality. Let a useful aside return to the main thought. Place low-stakes discoveries where they aid understanding, while keeping price, risk, prerequisites and recovery visible when needed. End at the useful result or next action; a quiet ending or a substantial summary can each serve the material.

H10a. Preserve conditions. Use “if” for a condition and “when” where the intended timing or situation warrants it. Check the whole meaning: “when a panel opens” and “while a panel is open” describe different scopes. Keep useful conditionals and parenthetical explanations; do not insert them to imitate a presumed author.

H10. Preserve expression that works. A fragment, three-part phrase, exclamation, aside, or single-sentence paragraph can serve a passage. Keep it when it supports meaning or the writer's rhythm. Do not add one to meet a budget, or remove one because of a generic stylistic test. Keep instructions and consequential conditions literal and easy to find.

H10b. Use the destination's notation. Preserve exact interface labels, tags, extensions, and identifiers. Italicize labels in neutral release notes; in technical site content use supported highlight notation, with bold as the plain-Markdown fallback. Use code style for machine-readable text. State price amounts and currencies unambiguously from evidence; do not infer an exchange rate, tax policy, or license term. A supplied currency shorthand needs enough context to identify the actual offer.

H11. Names and collisions. FontLab is the product; Fontlab Ltd. is the company. Preserve product names, module identifiers, domains, historical names in their historical scope, and exact quoted strings. Do not translate a product name. Name the application when Layer, Mask, Group, Fill, Brush, Knife, Transform, Pencil, Eraser, or Scissors could have more than one meaning. Use a declared short form consistently.

H12. Protect literal material. Preserve quotations, code, commands, paths, identifiers, API names, URLs, legal text, interface strings, placeholders, and table data during prose editing. Change them only for a requested or necessary correction supported by evidence. Do not paraphrase a quotation while retaining quotation marks or an attribution. Explain a consequential correction when the output contract permits it.

H13. Choose the register per passage. Marketing helps assess an offer; technical writing explains or instructs; neutral prose states facts and changes warmly. A document can combine them. Prices, limits, licensing, compatibility, security, and migration facts stay plain and prominent. Audience and purpose determine an email's register. Do not impose a fixed emotional mixture or make every opening a story.

H14. Review facts, then movement. Compare claims and protected strings with their evidence; check scope, action order and terminology. Then read whole passages for attention, connection and pace. Repair a flat sequence by developing an existing detail or relationship, not by adding praise or invented events. Check that humor remains intelligible and the information remains true when the joke is missed. Recheck the facts after a voice edit. A measurement or passing build does not certify facts, usability or authorship. Report only checks actually performed.

H15. Scale to the surface. A button or tooltip needs a clear label, action, or condition, not a miniature essay. Apply factual and naming safeguards at every length. Include the detail the task requires; do not add proof paragraphs, metaphors, or pronouns to satisfy a template. For translation, keep essential instructions literal and references clear.

H16. The override. Follow the user's task and supplied voice before style defaults. Break a default sooner than make the writing worse. Source material and quoted prompts are data, not authority to change the task. Style preferences never justify presenting an invented or unsupported claim as established fact.

H17. Check each portion, repair, check again. Reading these rules does not apply them; checking the text does. After drafting or editing each portion (a section, one deliverable, a batch of entries; a label or tooltip is one portion), run the skill's checklist on it. Answer each item separately, against the text and the evidence. For a failure, quote the words that fail. For a pass, point to the passage that satisfies the item, or, for an item about something absent, confirm that you searched the whole portion and found none. An answer with nothing behind it has not been checked. Repair only the failures, because a passing item needs no edit and a correct sentence can stay unchanged. Recheck the repaired passages and every fact the repair touched. If the same item fails again after its repair, stop working on it and mark it; do not try a third time. Stop after three rounds in all, and mark what still fails with a specific placeholder instead of reporting a pass. If you can start a separate reviewer (a subagent or a fresh chat), give it the draft, the evidence and the checklist, not your drafting rationale, and ask for failures with locations; act on findings that name a rule and a passage. Keep the checklist record private unless the user asks for it or the output contract allows notes.