Translation Is Not Automation. It Is Another LLM Wiki.

I want this blog to become readable in English.

But “English support” should not mean an automatic translation button. It should not mean mechanically converting Korean sentences into English. This blog is already being built on top of a knowledge architecture, as argued in An LLM Wiki starts with knowledge architecture, not a vector database. The translation system should follow the same principle.

English translation should become its own writing pipeline and its own LLM Wiki.

Translation is not an output. It is a knowledge operating system.

If we treat blog translation as a simple task, the workflow looks like this.

Korean post -> English translation -> publish

That does not scale. Every article would force the same decisions again: how to explain “LLM Wiki,” whether “작업 기억” should become working memory or operational memory, and how much of the Korean rhythm should be preserved.

The workflow we need is closer to this.

Korean source
-> text analysis
-> translation strategy
-> English draft
-> editorial review
-> English publication
-> translation decisions accumulated in the Translation LLM Wiki

The important part is not only the translated article. The important part is that the decisions made during translation do not disappear. We need to record which expression was chosen, why a literal translation was rejected, which concepts should remain as proper terms, and which paragraphs were reshaped for English readers.

The default is 0.3 literal, 0.7 adaptive.

The default translation setting for this blog is:

translation_approach = {literal: 0.3, adaptive: 0.7}
reader_expertise = {beginner: 0.1, intermediate: 0.3, expert: 0.6}

Technical concepts must remain precise. But the finished article must read like an English essay, not like a Korean sentence map. Terms and definitions can lean more literal. Titles, openings, metaphors, and paragraph flow should lean more adaptive.

For example, the Korean title “LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다” can be translated literally:

The core of an LLM Wiki is not a vector DB, but knowledge architecture.

That is understandable, but it is not a strong English blog title. A better editorial version is:

An LLM Wiki Starts with Knowledge Architecture, Not a Vector Database

That difference is the point of dynamic translation. The ratio changes by sentence. A title may need 0.8 adaptation. A concept definition or code comment may need 0.6 literal fidelity.

Build a separate Translation LLM Wiki.

Sustainable English publishing needs a dedicated translation wiki. This is not just an appendix to the blog. It is the memory store that the translation agent must consult every time.

translation-wiki/
  glossary.md
  term-decisions.md
  voice-and-tone.md
  title-patterns.md
  metaphor-bank.md
  article-map.md
  review-checklist.md

glossary.md is a vocabulary file, but not a generic dictionary. It should preserve the conceptual style of this blog.

## LLM Wiki

- keep: LLM Wiki
- explain as: a knowledge architecture where notes, citations, indexes, and agent-readable context accumulate over time
- avoid: AI encyclopedia
- reason: This is a core concept of the blog, so it should not be flattened into a generic noun.

term-decisions.md records judgments.

## 작업 기억

- default: working memory
- use operational memory when the context is about agent execution state
- avoid short-term memory unless contrasting with long-term memory

As these files accumulate, the translation agent stops starting from zero. Translation becomes more consistent, and the English voice of the blog becomes clearer.

Choose a strategy for each article.

Not every post should be translated in the same way.

Tool Calling is not function calling. It is interface design. is a conceptual engineering essay. Terminological precision matters. The contrast between function calling and interface design is the core of the article, so key sentences should stay relatively literal.

By contrast, PKM in the age of vibe coding carries more cultural context and metaphor. We have to decide whether to keep “vibe coding,” explain it, or adapt it into a broader phrase such as agentic coding culture.

The translation process should start with this analysis:

1. Identify the genre.
2. Estimate the reader level.
3. Understand the author's intent.
4. Analyze the overall tone.
5. Notice cultural references.
6. Detect linguistic features such as metaphors, slang, and recurring terms.

Then the strategy changes by article type.

Essay: adaptive 0.7
Technical explainer: literal 0.45, adaptive 0.55
Tutorial: literal 0.55, adaptive 0.45
Concept manifesto: adaptive title, literal definitions

This is dynamic translation. It is not a single fixed prompt. It is a system where the grammar of translation changes according to the text.

The blog structure must connect source and translation.

The English post should not be hidden under the Korean article as a secondary artifact. It should be an independent post. At the same time, it should remain tightly linked to the source.

lang: ko
translation_group: llm-wiki-knowledge-architecture
translated_versions:
  en: /en/2026/06/20/llm-wiki-knowledge-architecture/

The English post should carry its own metadata.

lang: en
translation_group: llm-wiki-knowledge-architecture
translation_of: /2026/06/20/llm-wiki-knowledge-architecture/
translation_status: reviewed
translation_strategy:
  literal: 0.3
  adaptive: 0.7
reader_level:
  beginner: 0.1
  intermediate: 0.3
  expert: 0.6

With this metadata, the article template can render a language switcher:

한국어 원문 | English

Later, translation_group lets us track the source article, translated article, translation notes, and term decisions as one unit.

The translation agent is an editorial assistant.

In this system, the LLM is not an automatic translator. It is an editorial assistant for translation.

Its job is:

1. Read the source and analyze genre and tone.
2. Look up term decisions in the Translation LLM Wiki.
3. Propose a translation strategy for the article.
4. Draft the English version.
5. Check for omissions and over-interpretation against the source.
6. Rewrite the title, opening, and headings for English readers.
7. Write new translation decisions back into the wiki.

The final step is essential. Each translation should improve the Translation LLM Wiki. A good translation is not a one-off deliverable. It becomes context for the next translation.

There are three quality standards.

Translation quality cannot be judged only by whether the English is grammatically correct. This blog needs at least three standards.

First, fidelity to the source. The core argument must not change. Paragraph order may change for English readers, but the logic must remain intact.

Second, natural English prose. If the translation simply preserves Korean sentence order, it fails. The English version must read as an English article.

Third, conceptual consistency. Terms such as LLM Wiki, tool calling, agentic workflow, and working memory should not drift from post to post.

Before publication, the review checklist should ask:

[ ] Is the title clickable for English readers?
[ ] Does the opening read as an English article, not an explanation of a Korean original?
[ ] Do key terms match the Translation LLM Wiki?
[ ] Did we avoid adding claims that are not in the source?
[ ] Did we reduce Korean-style repetition where needed?
[ ] Did code and YAML preserve their meaning?
[ ] Were new term decisions written back to the wiki?

Start small.

We do not need a complete multilingual platform on day one.

The first implementation can be small:

1. Create translation-wiki/.
2. Add glossary.md, voice-and-tone.md, and term-decisions.md.
3. Translate one representative post carefully.
4. Connect the Korean and English posts through frontmatter.
5. Add a language switcher to the article template.
6. Record translation decisions in the wiki.
7. Use the wiki for the next translation.

That makes English translation more than a blog feature. It becomes a second knowledge layer of the blog.

Conclusion

English support for this blog is not a translation feature.

It is the work of redesigning Korean ideas into a knowledge structure that English-speaking readers can enter. Automatic translation is fast, but it is not enough to preserve the texture of the concepts this blog is building.

What we need is careful translation, a dynamic translation strategy, and a Translation LLM Wiki that accumulates editorial decisions.

If the Korean article is the source knowledge, the English article is the interface that carries that knowledge into another language community. The memory system that makes that interface stable is the Translation LLM Wiki.