How Memolog Translates Japanese into Natural English

Memolog publishes articles in Japanese and English. When we first added multilingual support, we wrote only the Japanese articles and generated the English versions automatically with Azure AI Translator.

That approach made it quick to provide English pages. As the number of articles grew, however, we became increasingly concerned about English that conveyed the meaning but still sounded unnatural. Literal titles and descriptions in search results could undermine a reader’s trust before they even reached the article.

We now treat machine translation as a first draft rather than a finished product. Before publishing, we rewrite it as natural English, conduct an independent review, and verify that the JA and EN versions are synchronized. This article looks at the old and new workflows and the problems we set out to solve.

Table of Contents

• Key takeaway
• How we initially automated English translation with Azure AI Translator
• Why machine translation alone was not enough
• Our current English translation workflow
• How we make the English read naturally
• How we prevent JA and EN from falling out of sync
• What matters for SEO
• What we learned from this workflow
• Summary

Key takeaway

Memolog now treats Japanese as the de facto source of truth and uses machine translation only to create the first English draft.

We produce each English version in five steps:

1. Generate an English first draft from Japanese using Azure AI Translator
2. Use an Azure OpenAI GPT model to rewrite literal phrasing as natural technical English
3. Have an independent editor polish the entire article so it reads naturally in English
4. Have a separate reviewer check both fidelity to the Japanese and the naturalness of the English
5. Record hashes for both JA and EN, then have CI reject any state in which only one version has changed

We did not simply replace one translation model with a more capable one. The most important part of this workflow is separating translation, editing, fact-checking, and synchronization verification.

How we initially automated English translation with Azure AI Translator

When we first implemented multilingual support, the repository contained only the Japanese articles. Azure AI Translator ran as part of the GitHub Actions build.

The translation script translates the frontmatter title and excerpt, along with the article body. It excludes elements such as code fences, inline code, URLs, and MDX imports from translation. The result is generated as an English article and served at an English URL.

For authentication, we use GitHub Actions OpenID Connect (OIDC) and a user-assigned managed identity instead of an API key. GitHub does not store long-lived secrets for Azure; the workflow calls Azure AI Translator with an Entra ID token.

This approach provided these benefits:

• Authors only need to write the Japanese article
• Every new article automatically gets an English page
• Code and product names remain protected while JA and EN use the same URL structure
• A shared layout manages multilingual SEO elements such as canonical, hreflang, sitemaps, and inLanguage

As an initial approach to multilingual support, this was a practical way to provide English content with limited operational overhead.

Why machine translation alone was not enough

Translation errors were not the only problem. Even grammatically correct output can sound unnatural as an English article.

For example, preserving Japanese word order can obscure both the subject and the conclusion. A literal translation of 「先に結論」 as Conclusion first is understandable, but Key takeaway is a more natural heading in an English technical article.

Japanese can omit subjects and objects that are clear from context; leaving them implicit in English can make the referent ambiguous. On the other hand, adding too much explanation during translation can introduce meaning or certainty that the Japanese source does not contain.

The parts that concerned us most were:

We are not assuming that machine-translated pages automatically rank lower. What matters is whether the page helps readers who arrive from search and whether its title and body communicate the intended meaning accurately.

Google Search Central’s Creating helpful, reliable, people-first content likewise recommends creating content for people rather than search engines. Because we publish the English page as the same article, our quality bar is not merely “understandable.” The article should read naturally to an English-speaking audience.

Our current English translation workflow

We no longer publish machine translation output directly. It now passes through several stages first.

1. Write the article in Japanese as the source of truth

We finish the Japanese article first. If we find an ambiguity that cannot be expressed safely in English, we do not guess. We revise the Japanese source before continuing.

This policy makes the source of truth unambiguous.

2. Create the first draft with Azure AI Translator

We send only the target article to Azure AI Translator to generate the first English draft. We specify the file name instead of retranslating every article on each run.

Before translation, the script protects the following elements to preserve the Markdown structure:

• Code fences and inline code
• URLs and Markdown links
• MDX imports and components
• Product names, identifiers, and terms that should not be replaced
• Headings and fragments referenced by the table of contents

3. Post-edit with a GPT model

We pass the Azure AI Translator output to an Azure OpenAI GPT model one fragment at a time. The model rewrites each fragment as concise, natural US technical prose without changing the Japanese meaning.

This is more than proofreading. The instructions tell the model to treat the machine translation as a draft and rebuild the sentence structure. To keep facts from changing, the script also verifies that numbers, product names, identifiers, and Markdown placeholders remain intact.

Only fragments that fail verification are retried. If a fragment still cannot be rewritten safely, the script leaves a warning.

4. An independent editor polishes the full article

Fragment-level post-editing cannot guarantee consistent flow or word choice across an entire article. We therefore give the complete Japanese and English texts to an editor working in a separate context.

The editor is a fresh subagent launched from GitHub Copilot. It does not share the translation process’s conversation history. Its inputs are the Japanese source, the first English draft, the intended audience, and the editorial rules, and it edits only the English article. This separation limits the influence of earlier translation decisions and lets the editor read the piece from the beginning as an English article.

The editor checks for:

• Remaining literal phrasing
• Established English terminology for technical concepts
• A natural flow from headings through the body
• Inconsistent wording for the same concept across paragraphs
• Facts or assertions that do not appear in the Japanese source

5. A separate reviewer compares JA and EN for consistency

We do not reuse the editor’s context for the final review. A different reviewer compares the Japanese and English versions.

The reviewer is another fresh GitHub Copilot subagent. Working in a context separate from the editor, it compares the completed Japanese and English texts in read-only mode. It returns only differences in meaning, unnatural phrasing, and specific English revisions. This technical separation helps prevent the editor from reviewing and justifying their own work.

The review covers omitted, added, or changed meaning; unnatural English; terminology; tables; headings; and the consistency of examples. Findings include specific English replacements. After applying them, we run another independent review.

We separate the steps because people reviewing their own rewrites can easily read the intended meaning into the text.

How we make the English read naturally

Producing natural English takes more than a single pass through a translation model.

Translate the intent, not each sentence literally

Translating each Japanese sentence into English in the same order tends to produce prose that reads like a translation. We preserve the purpose of each paragraph while restructuring subjects, sentence order, and headings for English readers.

That does not mean the structure or facts can change freely. We draw a clear line between rewriting for readability and adding content.

Catch recurring translation patterns with a checklist

English can convey the intended meaning accurately and still sound machine-translated. Over time, we found that the same patterns kept recurring. We added an English Naturalness Checklist to the bilingual-blog-sync Skill and made these six perspectives part of the editorial process:

• Avoid using organize as a catch-all verb; choose the verb that names the actual action
• Avoid repeatedly starting sentences with So; state the relationship directly or vary the transition
• Turn nominalizations back into verbs where practical
• Remove unnecessary can inherited from Japanese 〜することができる phrasing; keep it when ability or permission is the point
• Split a long sentence into two at a meaningful boundary
• Put cause and effect in a natural English order instead of preserving Japanese word order

These are editorial perspectives, not mechanical replacement rules. We apply them only when the context supports a change and never alter the author’s claims or facts.

Both the editor working in a fresh context and the independent reviewer who compares JA and EN use the checklist. The editor reduces translation-like phrasing; the reviewer catches anything the editing pass missed.

Protect proper nouns and facts programmatically

Even though we rely on the model for natural phrasing, the script checks the following items:

• Numbers and dates
• Brand names such as Azure, GitHub, and Microsoft
• Product names such as Azure AI Translator
• Uppercase identifiers
• Placeholders used to restore Markdown

Separating what may be rephrased from what must remain character-for-character identical helps preserve both fluency and accuracy.

Make automated output reviewable as a source file

We do not treat reviewed English as a temporary generated artifact. It is version-controlled as a source file paired with the Japanese article.

Reviewers can inspect the English text in a Pull Request diff. On later revisions, they can preserve existing wording and update only what changed. We can also verify that the published English is identical to the version reviewed locally.

How we prevent JA and EN from falling out of sync

Manually reviewing the English introduces another risk: someone might update the Japanese article and forget its English counterpart.

To prevent that, Memolog records the SHA-256 hashes of the synchronized Japanese and English files in a synchronization record.

npm run sync:blog-en -- <slug>.mdx

If either file changes after those hashes are recorded, the following check fails:

npm run check:blog-en

CI rejects the following states:

• A new Japanese article has no reviewed English override
• Only the Japanese or English file has changed since synchronization
• An English override exists but is missing from the synchronization record
• A deletion or rename leaves only one file in the pair

We are not migrating every existing article at once. An article without an English override remains a legacy article with a pinned Japanese hash, and the previous automatic translation process continues to supply its English version. The next time that article is updated, it moves to the new reviewed workflow.

This phased migration improves quality without removing existing English pages.

What matters for SEO

The technical requirements of multilingual SEO and the quality of the English itself are separate concerns.

Memolog uses separate URLs for each language and configures canonical, hreflang, the sitemap, the Open Graph locale, and JSON-LD inLanguage. As Google Search Central explains in Tell Google about localized versions of your page, these signals tell search engines how pages in different languages relate to one another.

Those settings do not make the English easier to read. The title and excerpt are the first elements people see in search results and on social media. The headings help them find information within the page, and the body supports technical decisions. All of these elements need to read naturally as one coherent article.

We divide these responsibilities as follows:

Instead of adding English keywords for SEO, we want English readers to understand whether an article matches their search intent and then read it without confusion.

What we learned from this workflow

Rebuilding the system showed us that no single model determines translation quality.

Azure AI Translator is well suited to producing a complete first draft quickly. A GPT model is well suited to rewriting that draft as natural prose. Neither can completely prevent added facts or altered notation, however, so programmatic checks and independent review remain necessary.

The hardest problem was not the English translation itself, but the ongoing process of keeping articles current. Even if we produce natural English at publication, failing to reflect later Japanese updates means publishing different information in JA and EN. Hash-based synchronization checks do not improve the prose directly, but they are essential for preserving reviewed quality over time.

This workflow takes more time and processing than machine translation alone. We therefore migrate existing articles as needed and apply the new quality standard to new and updated articles. For this site, improving incrementally while keeping existing pages available works better than trying to perfect everything at once.

Summary

Memolog’s English translation process has evolved from converting Japanese text into English to verifying the quality of each article as English content.

Today, Japanese is the source of truth. Azure AI Translator produces the first draft, and an Azure OpenAI GPT model rewrites it as natural technical English. Independent editing and review come next. Finally, we record the JA and EN hashes so CI can prevent synchronization gaps.

Technical multilingual SEO settings are necessary, but they do not create a readable English article on their own. Machine translation remains a practical starting point; the important part is designing a workflow that addresses naturalness, fidelity, and synchronization whenever an article changes.

References

• Google Search Central: Creating helpful, reliable, people-first content
• Google Search Central: Tell Google about localized versions of your page
• Microsoft Learn: Azure AI Translator documentation
• Microsoft Learn: Azure sign-in using OpenID Connect