How Localization for Node Summaries Works in Understand-Anything: Japanese, Korean, and Russian

Node summaries in the Understand-Anything plugin are localized through a multi-layer pipeline that injects language-specific markdown guidelines into LLM prompts, validates schema defaults, and renders translated UI strings in the dashboard.

The Egonex-AI/Understand-Anything repository implements a deterministic localization system that adapts node summaries for Japanese, Korean, and Russian output. This architecture combines runtime locale injection with static guidance files to ensure consistent translation of technical concepts and summary styling across all generated graph nodes.

Core Architecture for Node Summary Localization

The localization pipeline begins with strict type definitions and schema validation that ensure every node carries translatable content.

Type Definitions and Schema Defaults

In packages/core/src/types.ts (line 45), each graph node includes a mandatory summary field and an optional languageNotes field for language-specific hints. The schema validator in packages/core/src/schema.ts (lines 251-258) guarantees that no node enters the pipeline without displayable text by defaulting missing summaries to the node's name.

This foundation ensures that downstream localization always has a string to transform, whether the LLM generates original content or the system falls back to identifier labels.

Locale Guidance Files and Language Directives

The skill ships dedicated markdown files that encode cultural and stylistic conventions for each target language.

Japanese, Korean, and Russian Style Conventions

Each locale file in skills/understand/locales/ contains three critical components:

• Tag-naming conventions – Maps localized technical terms to canonical tags (e.g., Japanese "エントリーポイント" → entry-point)
• Summary style rules – Mandates active voice and length constraints (1-2 sentences)
• Layer name translations – Provides culturally appropriate architecture terms (Japanese "API層", Korean "API 계층", Russian "Слой API")

Example files include:

• Japanese: skills/understand/locales/ja.md – "1-2文のサマリーを日本語で記述…"
• Korean: skills/understand/locales/ko.md – "1-2문장의 요약을 한국어로 작성"
• Russian: skills/understand/locales/ru.md – "1-2 предложения-резюме на русском"

Runtime Injection via OUTPUT_LANGUAGE

When $OUTPUT_LANGUAGE is set to a non-English value, the skill dynamically loads the corresponding markdown file and appends its content under a ## Output Language Guidelines header. As documented in skills/understand/SKILL.md (line 408), this injection happens immediately before the LLM prompt is finalized, ensuring the model receives explicit instructions to generate summaries matching the target locale's conventions.

# Set the desired output language

export OUTPUT_LANGUAGE=ja   # Options: ja | ko | ru

# Execute the skill

pnpm run understand

# The skill injects the locale file into the prompt:

# ./skills/understand/locales/ja.md → LLM generates Japanese-styled summary

Dashboard UI Localization

While the core engine handles content generation, the dashboard manages display-layer localization through a dedicated locales system.

Runtime Language Selection

The frontend pulls UI strings—including the "summary" label—from packages/dashboard/src/locales/index.ts. This module exports a locales map that selects the appropriate language (en, ja, ko, ru) at runtime based on user preferences or environment settings.

import { locales } from "./locales";

function t(key: string, lang: string) {
  return locales[lang]?.[key] ?? locales.en[key];
}

// Component usage
<div>{t("summaryLabel", currentLang)}</div>

This separation of concerns allows the backend to generate localized content while the frontend renders matching interface labels without duplicating translation logic.

Implementation Workflow

The complete localization pipeline follows this deterministic sequence:

1. Schema Validation: core/src/schema.ts ensures every node has a summary field

2. Locale Loading: The skill reads the markdown file matching $OUTPUT_LANGUAGE

3. Prompt Injection: Guidance is appended to the LLM prompt under ## Output Language Guidelines

4. Content Generation: The LLM produces a summary following the injected style rules

5. UI Rendering: The dashboard displays the content using localized labels from dashboard/src/locales/

Programmatic locale loading (simplified implementation):

import { readFileSync } from "fs";
import path from "path";

function loadLocale(lang: string) {
  const localePath = path.resolve(
    __dirname,
    "..",
    "skills",
    "understand",
    "locales",
    `${lang}.md`
  );
  return readFileSync(localePath, "utf-8");
}

const localeGuidance = loadLocale(process.env.OUTPUT_LANGUAGE ?? "en");
const prompt = `${basePrompt}\n## Output Language Guidelines\n${localeGuidance}`;

Summary

• Type Safety: packages/core/src/types.ts defines the summary and languageNotes fields, while schema.ts enforces non-empty defaults
• Guidance Files: Markdown files in skills/understand/locales/ (ja.md, ko.md, ru.md) contain tag conventions and style rules for Japanese, Korean, and Russian
• Prompt Injection: The skill reads $OUTPUT_LANGUAGE and injects locale guidance into LLM prompts before generation
• UI Separation: dashboard/src/locales/index.ts handles frontend label translation independently from content generation
• Fallback Strategy: Schema validation ensures every node has displayable text even when LLM generation fails

Frequently Asked Questions

How does the system handle missing translations for node summaries?

The schema validator in packages/core/src/schema.ts (lines 251-258) automatically populates empty summary fields with the node's name, ensuring that the UI always has a string to display. This fallback occurs before localization, so the dashboard receives valid content even if the LLM fails to generate a language-specific summary.

What is the difference between core schema validation and UI localization?

Core schema validation ensures data integrity by guaranteeing that every graph node contains a summary field with non-empty content. UI localization, handled in dashboard/src/locales/index.ts, manages the translation of interface labels like "summary" or "layer" that surround the content. The core pipeline handles what text appears, while the dashboard handles how the interface describes that text.

Can the localization system support additional languages beyond Japanese, Korean, and Russian?

Yes. The architecture supports arbitrary language expansion by adding new markdown files to skills/understand/locales/ (e.g., de.md for German) and updating the locales export in dashboard/src/locales/index.ts. The skill automatically picks up new languages when $OUTPUT_LANGUAGE matches an available file basename, requiring no changes to the core injection logic.

How are language-specific tag conventions enforced in generated summaries?

The locale markdown files define explicit mappings between localized technical terms and canonical tags. When injected into the LLM prompt under ## Output Language Guidelines, these rules instruct the model to use culturally appropriate terminology (e.g., Japanese "API層" instead of "API Layer") while maintaining consistent internal tag references. This ensures that generated summaries remain semantically compatible with the graph structure while displaying localized vocabulary.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}