Building a Japanese Localization Glossary:
Terminology Management for Consistent SaaS Translation

TL;DR

Key Takeaways

• Japanese has a larger inconsistency error surface than English — three scripts and multiple register levels mean a single term can appear in more incorrect forms. This is why inconsistency complaints are more frequent and more visible in Japanese.
• The glossary must include forbidden alternatives — listing only the approved term is insufficient. Without explicitly documenting what is forbidden (管理画面 if you chose ダッシュボード), translators and writers will introduce forbidden forms unknowingly.
• The katakana-versus-kanji decision follows a two-question framework — established kanji form used in Japanese business software? Use kanji. Borrowed technical term without natural kanji equivalent? Use katakana. Do not apply a blanket rule.
• Start with 50 core terms, not 500 — a glossary that covers the most visible surfaces and is actually enforced beats a comprehensive one that accumulates unchecked. Expand after the workflow is proven.
• TBX is the correct vendor format — it integrates directly with CAT tools (Phrase, memoQ) and enforces the glossary at the translation memory level, not through post-hoc review.

Why Japanese Terminology Inconsistency Is More Damaging Than in English

In English, the term "dashboard" has one form and one spelling. A translator who disagrees with it might write "control panel" — but that is one alternative. In Japanese, the same concept can be rendered as ダッシュボード (katakana), 管理画面 (kanji compound, meaning management screen), コントロールパネル (longer katakana), ダッシュ (abbreviated katakana), or 管理ページ (kanji plus English-origin page). Each carries a distinct connotation. Each is wrong relative to the others if you have chosen one as your product term.

The multiplication effect of scripts is the core issue. Every Japanese term has at least a kanji and a kana reading, and many technical terms also have an anglicized katakana form. A translator working without a glossary does not encounter one alternative to the approved term — they encounter a field of plausible options, and professional translators make different choices based on their background, their impression of the target audience, and their familiarity with the product. Without a glossary enforcing a single choice, inconsistency across a product surface is not a possibility — it is a certainty.

Japanese users also read script inconsistency as a quality signal more sharply than English readers read synonym variation. When a Japanese user sees ダッシュボード in the product nav, 管理画面 in the help center, and ダッシュ in an in-app tooltip, the inconsistency is not just terminological — it signals that different people wrote these surfaces and that no one reviewed for consistency. In a B2B procurement context, this is the kind of signal that raises questions about whether the vendor's product is mature enough for enterprise use.

What Belongs in a Japanese Localization Glossary

A Japanese localization glossary is not a dictionary and not a style guide, though it overlaps with both. It is a term-level enforcement document. It answers, for each entry: what is the approved Japanese term, how is it read, where is it used, what alternatives are forbidden, and what does usage in context look like. A glossary that omits any of these fields is incomplete and will produce inconsistency where it has gaps.

The four categories of content that belong in a Japanese localization glossary are these:

1. UI terms: Every label that appears in the product interface — navigation items, button text, dialog headings, status labels, error states. These are the highest-visibility terms and the ones where inconsistency is most damaging, because they appear on every session and in every screenshot a user shares with a colleague.
2. Product-specific nouns: Feature names, workflow names, object names that are specific to your product and have no generic Japanese equivalent. These require a decision, often between a Japanese translation, a katakana transliteration, or leaving the English term in place. Once made, the decision must be documented and enforced consistently.
3. Forbidden alternatives: Every approved term has at least one plausible alternative that should not be used. The glossary must list these explicitly and flag them as forbidden. Without this field, a new translator or writer encounters the concept, does not find it in the glossary, and makes a fresh choice — which may match a forbidden alternative that was rejected for good reasons.
4. Tone rules: Register-level decisions that affect multiple terms — for example, whether the product uses です/ます throughout or switches to a more casual register in certain contexts, whether keigo is ever appropriate (in formal notifications), and how imperative instructions are handled in UI labels versus documentation.

The Dashboard Problem: ダッシュボード vs 管理画面 vs コントロールパネル

The "dashboard" question is the representative case for Japanese terminology decision-making, and every Japanese localization project encounters it. The three primary options each carry different connotations that affect user comprehension and product positioning.

ダッシュボード is the katakana transliteration of "dashboard." It is the most widely used term for the main overview screen in Japanese SaaS products. It reads as product-specific and modern. It does not carry a functional description of what the screen does — a user who has not used your product before does not know from the term alone what ダッシュボード contains. This is exactly how Dashboard functions in English: it is a proper name for a product screen, not a functional description. For most SaaS products with a dashboard-centric design, ダッシュボード is the correct choice.

管理画面 (kanri gamen — management screen) is a functional description that many Japanese users use as a generic term for any admin interface. It describes what the screen does rather than naming it. This makes it useful as a generic reference in help content ("the admin screen") but problematic as a product term, because it implies the screen's function rather than identifying it as a specific named element of the product. Using 管理画面 as your product term also makes it harder to distinguish between your product's dashboard and the general concept of an admin area.

コントロールパネル (control panel in katakana) skews older and enterprise-infrastructure. It carries associations with server administration and legacy software. Unless your product is explicitly infrastructure management software where this connotation is appropriate, コントロールパネル reads as dated for a modern SaaS product.

Katakana vs Kanji Decision Framework

Every Japanese glossary decision involves a script choice, and teams without a framework for making this choice produce inconsistent glossaries — katakana here, kanji there, no clear principle behind either. The two-question framework below resolves most cases cleanly.

Question 1: Does the term have an established kanji form used in Japanese business software? If yes, use kanji. 設定 (Settings), 権限 (Permissions), 連携 (Integrations/Connections), 招待 (Invitation), 承認 (Approval), 通知 (Notification) all have established kanji forms that Japanese business users encounter daily. Using katakana for these terms — セッティング, パーミッション, インビテーション — reads as informal, foreign, or mistaken.

Question 2: Is the term a borrowed word or product concept that entered Japanese through software and lacks a natural kanji equivalent? If yes, use katakana. ダッシュボード (Dashboard), テンプレート (Template), ワークフロー (Workflow), インテグレーション (Integration as a product concept), アナリティクス (Analytics) all arrived with software and have no kanji form that Japanese users actually use. Forcing kanji onto these terms — 制御盤 for Dashboard, 型板 for Template — produces results that read as bizarre or archaic.

The hard cases are terms where both forms circulate in the market. 連携 (kanji) and インテグレーション (katakana) both mean "integration" and both appear in Japanese SaaS products. In this case, the kanji form is almost always the safer choice for a B2B audience — it reads as more precise and more native. The exception is when your product category has clearly converged on the katakana form: if every competitor product in your category uses インテグレーション, matching that convention may matter more than the kanji-first principle.

Glossary Structure: The Six Required Fields

A Japanese localization glossary entry needs six fields to be actionable. Entries with fewer fields will generate questions from translators and will be ignored by writers who cannot find clear answers in them.

1. Source term (English): the exact string as it appears in the English product.
2. Japanese term: the approved Japanese translation, in the correct script.
3. Reading: the hiragana reading of the Japanese term. Essential for terms that contain kanji, because translators and writers need to confirm they have the right homophone.
4. Usage note: one to two sentences explaining where the term is used, which register applies, and any context-specific variation (for example, a term that appears as a noun in the nav and as a verb stem in step instructions).
5. Forbidden alternatives: the specific Japanese forms that must not be used, with a one-line note on why each was rejected. This is the field most often omitted and most often responsible for glossary drift.
6. Example in context: one or two example sentences showing the term used correctly. This field makes the glossary usable without additional explanation and reduces translator questions.

Sample Glossary Table: 20 Common SaaS Terms

Maintaining the Glossary as the Product Evolves

A glossary written at project launch and never updated becomes the most reliable source of inconsistency in the product within two years. Product features are renamed, UI labels change, new feature categories are introduced, and competitors converge on different terminology that starts influencing user expectations. Without a maintenance workflow, the glossary drifts from the product reality and translators and writers who encounter the discrepancy start working around it.

Three triggers should initiate a glossary review cycle: a feature rename, a major UI restructuring, and the introduction of a new feature category with no existing glossary coverage. Each of these creates a window where new terms are introduced without glossary entries, and that window is when inconsistency compounds.

The practical maintenance approach for a small-to-medium localization program is a quarterly glossary audit: compare the current glossary against the product's live Japanese UI strings, identify any terms in the UI that are not in the glossary or that differ from the glossary entry, and add or update entries. This quarterly cycle is slower than real-time maintenance but faster than the two-year drift that produces major inconsistency problems.

Glossary Tooling: TBX, CAT Integration, and Vendor Sharing

A Japanese localization glossary that exists as a Google Sheet and is shared with translators as a PDF attachment is not a glossary — it is a document that translators consult if they remember to open it and if it is current when they open it. Effective glossary management requires integration with the translation workflow at the tool level.

The industry standard format is TBX (TermBase eXchange), an ISO-standard XML format that CAT tools (Phrase, memoQ, SDL Trados, Memsource) can import directly and use to flag non-compliant terms during translation. A translator working in memoQ with a TBX glossary loaded will see a warning when they translate "Dashboard" as 管理画面 if ダッシュボード is the approved term and 管理画面 is listed as forbidden. This enforcement happens at translation time, not in post-review — which is when inconsistency is cheapest to fix.

For sharing with vendors who do not use CAT tools, a tab-separated CSV with the same six fields is a practical alternative. Excel is widely used in practice but is not recommended as the master format — it lacks version control, does not integrate with translation workflows, and produces format drift when multiple people edit it. Maintain the master in TBX or a terminology management system such as Phrase TMS or TermWeb; export to Excel or PDF for human review cycles only.

Building the First Glossary from Scratch: 50 Core Terms

The most common reason Japanese localization programs do not have a glossary is that the initial scope feels overwhelming. A complete glossary for a mature SaaS product may have hundreds of entries, and the prospect of auditing the entire product before writing a single term causes teams to defer indefinitely. The correct starting point is 50 core terms — enough to cover the most visible surfaces without requiring a complete product audit.

The 50 terms should be drawn from five categories, with approximately equal weight:

• Top-level navigation labels (8–10 terms): the items in your global nav, which appear on every page and set the term expectations users carry into all other surfaces.
• Primary action buttons and CTAs (8–10 terms): Save, Cancel, Confirm, Delete, Invite, Export, Import, Submit — the verbs that drive user actions throughout the product.
• Core feature names (10–15 terms): the two to five features that define your product and the sub-features within them. If your product is a project management tool, these are Project, Task, Milestone, Board, Sprint.
• Error and status states (5–8 terms): Error, Warning, Success, Loading, Pending, Archived, Draft, Published. These appear throughout the product and across every surface.
• High-frequency help center terms (10–12 terms): the terms that appear most frequently in your KB article titles and step instructions. These are often the same as the nav labels, but may include more technical terms depending on the product.

Japanese Localization Glossary Checklist

Frequently Asked Questions