How Memolog Translates Japanese into Natural English

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

That approach made it easy to publish English pages quickly. As the article library grew, however, we started noticing passages that conveyed the meaning but still sounded unnatural in English. Literal-sounding titles and descriptions in search results could undermine readers’ 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 the draft as natural English, conduct an independent review, and verify that the JA and EN versions are synchronized. This article compares the old and new workflows and explains 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
• Review practices we added later
• 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 converts the frontmatter title and excerpt, along with the article body, from Japanese to English. It leaves code fences, inline code, URLs, MDX imports, and similar elements untranslated. The script generates the result as an English article, which the site serves at an English URL.

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

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 it clear which language is the source of truth.

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.

GitHub Copilot launches a fresh subagent as the editor. It does not share the translation process’s conversation history. Instead, it receives the Japanese source, the first English draft, the intended audience, and the editorial rules as new inputs and edits only the English article. This separation keeps earlier translation decisions from shaping the edit and lets the editor approach the piece as an English article from the start.

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 reports 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 and the independent reviewer use the checklist. The editor reduces translation-like phrasing, and the reviewer catches anything the editing pass missed.

Protect proper nouns and facts programmatically

The model handles natural phrasing, but the script still checks:

• 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, we can preserve existing wording and update only what changed. We can also verify that the published English is identical to the version reviewed locally.

Review practices we added later

As we continued using the workflow, we found that a naturalness pass could flatten the author’s distinctive phrasing into something bland. We also found that a style suited to technical articles did not necessarily work for travel writing. That led us to expand the review method in the translation Skill over time.

Classify findings as Required, Recommended, or Keep

The independent reviewer places each finding in one of three categories:

Every Required and Recommended finding must quote the current English and provide a complete English-only replacement. We do not accept preference-only suggestions that merely make the prose more neutral. We verify any proposed change to the name of a person, organization, business, venue, product, or dish against an official or otherwise authoritative source instead of inferring a reading from kanji.

Match the tone to the article and each section

The translation Skill now applies to all four categories: tech, community, photo, and daily. The category provides the starting context, not a uniform style preset for the entire article. The purpose of each section determines its local tone.

• Tech articles use concise, precise technical English while preserving product names, release states, limitations, numbers, and uncertainty
• Community articles keep event details and the author’s role factual while describing conversations and atmosphere in approachable language
• Photo articles keep the photograph at the center, with concise prose, objective alt text for visible content, and captions that provide brief editorial context
• Daily articles preserve chronology, reactions, humor, food and place details, and a natural first-person voice

In an article that combines a technical event with travel, for example, the technical explanation stays precise while the journey and meals can become more conversational. Clear transitions make the shift feel intentional. We also keep personal observations that reveal the author’s perspective, convey a sense of place, or add humor, even when they are not central to the main topic. We do not invent asides in English or loosen technical claims merely to create contrast.

Finish with a paragraph-by-paragraph pass

The final review reads every paragraph as independent English prose. It checks not only grammar but also idiomatic collocations, clear references, repetitive sentence openings, and how the rhythm sounds when read aloud.

This pass is not meant to polish every paragraph into the same voice. Short reactions, casual phrasing, mild self-deprecation, and deliberate repetition remain when they sound natural and carry the author’s personality. Avoiding technically polished but generic prose is now part of the quality bar.

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 file.

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