# Term Translation Research > Research evidence-backed translations and established terms across domain-specific, industry, and general usage. Use when selecting English/Japanese terminology, validating standard translations, resolving product wording collisions, or proposing audience-specific term usage with citations. - Skill: `japboy/term-translation-research` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add japboy/term-translation-research` - Raw SKILL.md: https://api.skillmd.com/api/skills/japboy/term-translation-research/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search - Author: japboy (https://skillmd.com/u/japboy) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/japboy/term-translation-research --- # Term Translation Research Use this skill to recommend term translations with explicit evidence, audience scope, and adoption status. Treat "domain-specific", "industry", and "general" usage as separate layers rather than collapsing them into one answer. ## Core Rules - Ground every recommendation in cited sources or explicitly mark it `unverified`. - Prefer official, primary, and product-maintained sources over secondary summaries. - Separate a concept decision from a wording decision: first define the concept, then compare candidate terms. - Do not call a wording an established term merely because it is understandable or frequent in search results. - Use finite candidate statuses: `established`, `preferred`, `acceptable`, `descriptive`, `avoid`, or `unverified`. - Always classify proposals into local fixes and fundamental solutions. Research follows a finite state machine: - `R0 Defined` - `R1 SearchPlanned` - `R2 EvidenceCollected` - `R3 CandidatesCompared` - `R4 Complete` or `R4 Unverified` Before searching, set a finite evidence budget. By default, inspect at most three high-authority sources for each applicable usage layer plus two targeted collision or freshness checks across the task. Extend the budget once only when the user requests broader research or a material contradiction cannot otherwise be classified; state the extension and its reason. ## Workflow 1. Define the term problem. - Identify source term, target language, concept definition, domain, target audience, product surface, and known collisions. - If the user provides an internal page, glossary, repository, or design artifact, treat it as domain-specific evidence and inspect it before public sources. - If the missing context would change the recommendation, ask one concise question. Otherwise proceed and list assumptions. 2. Gather evidence by layer. - Domain-specific: internal glossaries, product UI, code identifiers, Notion pages, design files, support docs, and brand guidelines. - Industry: standards bodies, government ministries, international organizations, professional associations, academic glossaries, and product-maintained terminology portals. - General: dictionaries, public-sector explainers, general audience guides, style guides, and mainstream usage. - Use search counts, blogs, and generated summaries only as weak supporting evidence, never as the deciding source. - Record publication or update date, retrieval date, last verification date, and freshness status when the source exposes them. 3. Load the detailed reference when making a recommendation. - Use [REFERENCE.md](references/REFERENCE.md) for the source hierarchy, evidence fields, status definitions, red flags, and output schema. - Load only the relevant sections if the task is narrow. 4. Compare candidates. - For each candidate, check concept fit, source authority, adoption breadth, audience clarity, collision risk, brand/product fit, and date freshness. - Distinguish "technically correct for specialists" from "clear for general users". - When two terms collide, prefer preserving the higher-authority established term and rename the lower-authority product or general label. 5. Recommend usage by audience. - If one candidate is clearly established for the target layer, recommend it. - If no established term exists, say so and propose a `preferred` or `descriptive` alternative with caveats. - If specialist and general-audience needs differ, provide a use-by-audience table rather than forcing one term. 6. Stop with an explicit terminal state. - Use `R4 Complete` when the concept, audience, and usage layer are explicit; the selected status meets the evidence rule in `references/REFERENCE.md`; collision and freshness checks are complete; and material contradictions are resolved or disclosed. - Use `R4 Unverified` when the evidence budget is exhausted and any required source, concept match, collision result, or freshness result remains missing. Report the missing evidence instead of continuing open-ended search. ## Output Shape Use the compact shape for one term, one audience, and no material collision: 1. **Decision**: term, audience, status, confidence, and terminal state. 2. **Why**: short evidence-backed rationale. 3. **Local Fixes** and **Fundamental Solutions**: include `none` when no proposal is warranted. 4. **Unknowns**: omit only in `R4 Complete` when none remain. Use the substantive shape when comparing multiple candidates or audiences, or when there is a collision, regulatory constraint, material contradiction, or stale evidence: 1. **Decision**: recommended term, target audience, and status. 2. **Use By Audience**: domain-specific, industry, and general usage. 3. **Evidence Matrix**: candidate, layer, status, source authority, fit, risks. 4. **Local Fixes**: immediate wording or collision-resolution choices. 5. **Fundamental Solutions**: glossary, termbase, naming policy, or review workflow changes that address root causes. 6. **Unknowns**: missing sources, stale evidence, or follow-up validation. 7. **Terminal State**: `R4 Complete` or `R4 Unverified` and the stopping reason. Keep citations close to the claim they support. Prefer concise paraphrase over long quotations.