Post-editing text (Gemini)

How we do it now (from 2026-11-06)

Looking at Google's billing, it cost about 1,000 yen for a single day on 11-04 Pacific Time (11-04 17:00 to 11-05 17:00 JST). Most of that was for the Pro model called by our local tools. We asked section by section, requested a redo when it missed the mark, and had it revise the same page over and over to compare models, which drove up the call count. Using it like this every day would come to about 360,000 yen a year (1,000 yen × 365 days). That was simply too expensive for touching up text.

So, we now follow this order instead:

1. The writer does their own routine polishing. When the writer is an AI, that AI revises its own work. It does not call external APIs. When you worry about quirks in your own writing, ask a separate AI that does not know the previous conversation, purely for polishing. This is to get a fresh pair of eyes.
2. Use the site's proofreading feature only when you want a fresh pair of eyes, such as before publishing. When you click "✍" on the editing screen, a cheaper model (Gemini Flash) suggests revisions. Only the parts where you review the comparison and click "Accept" are incorporated into the main text. It can be used up to 50 times a day across the whole site. Checks for blocked words, numbers, and certainty markers are the same as the method on this page.
3. Use the expensive model (Pro) only when requested by the person who decides on publishing. We also set our local tools to use Flash unless specified by name.

Conclusion

• We divide the roles. The writer handles content and decisions, Gemini handles Japanese readability, and the person who decides on publishing handles making the page public.
• We have Gemini revise only text. Before sending, tags, code, headings, and links are replaced with ⟦number⟧ tokens. That way, Gemini only sees plain sentences.
• We verify the responses programmatically. We compare the order and count of tokens, alphanumeric words (part numbers and G-codes), certainty markers like "estimated" and "unverified", and sentence length. Here is the crucial point: if even one check fails, we do not use that section.
• In the end, the writer compares and decides. Any places where the meaning has shifted are reverted. Also, for places where Gemini noted that the text was hard to understand, the writer rewrites the original sentence.
• We also consider publication safety. Before sending to Gemini, tools check for any words that must not be published. We only send documents meant for public release.
• [Test] On "How to use rigid tapping" (12 sections), we revised the instructions twice. On the third run, all 12 sections passed the automated checks, resulting in 52 edits. The writer read through the entire text, and there were no shifts in meaning.

1. Steps

1. First, the writer writes the text. They decide on the content, numbers, and sources, and add certainty markers (such as estimated, unverified, [source]).
2. Next, tools check whether it is safe to publish. If there are blocked words like company names, personal names, server names, or tokens, processing stops right there. The blocked-words list is kept in an unpublished file. This is because the words themselves are information that must not be made public.
3. Then, tools replace elements with tokens. Tags, code (pre, code), headings, and links are turned into ⟦number⟧ tokens.
4. After that, Gemini polishes the Japanese. Text is sent section by section (by h2). The response is received as JSON. Its contents are the revised text and notes on places where the meaning was unclear and could not be revised.
5. Next, tools verify it programmatically. If it fails, we ask for a redo only once, giving the reason. If it still fails, we leave that section as it was originally.
6. From here, the writer compares and decides. They read through the entire comparison, where deleted text is shown in red and added text in green.
7. Finally, the writer saves the changes. If another person has edited the page while reading, the site's write endpoint will reject the save. This is to avoid overwriting that person's edits. For public pages, saving pushes the changes to the live site within a few dozen seconds. When making large revisions, it is safer to give a quick heads-up to the person who decides on publishing beforehand.
8. The person who decides on publishing marks it as published. For new pages, the person who decides on publishing applies the published mark.

2. Why divide the roles

3. Instructions to Gemini

The same instructions are sent every time (system instructions). The key points are as follows:

• First, keep sentences short and write one thing per sentence. Fix awkward word order and repetitive phrasing.
• Use the polite "desu/masu" style. We use a gentle tone, as if speaking to the reader (tool option: --tone desu). Eventually AI will read it too, but for now we want people to read it. Short words that connect the flow may be added, but do not add facts or numerical values. You can also edit older plain-style pages while keeping them in plain style.
• Keep gentle phrasing. Avoid condensing native Japanese words into Sino-Japanese compounds (do not change "比べ" (comparing) to "比較" (comparison), "反転のとき" (when reversing) to "反転時" (at reversal), or "確かめる" (check) to "確認する" (verify)).
• Do not delete half-width spaces between Japanese text and alphanumeric characters.
• Do not change the meaning. Keep facts, numbers, units, model numbers, symbols, and formulas as they are. Do not add anything new or remove anything.
• Do not weaken definitive statements of decisions or procedures ("〜する" [do] / "〜します" [will do]) into recommendations or impressions such as "〜すると安心です" (it is reassuring to...). Do not strengthen recommendations into rules, either. Keep statements about safety or hazardous work at their exact original strength.
• Do not use connecting words like "そのため" (therefore) or "というのも" (the reason is) to add cause-and-effect relationships not present in the original sentence. Use them only when the original sentence already states a reason.
• Keep uncertainty markers and tags such as "[原典]" (source), and do not separate them from the sentences they qualify.
• Do not paraphrase technical terms ("索引" [index], "行き過ぎ" [overshoot], "下穴" [pilot hole], "有効径" [pitch diameter], etc.).
• Keep all ⟦number⟧ marks in the exact same order.

We set the temperature (variability of answers) to 0.2. The model used during testing was gemini-pro-latest. Currently, our local tool defaults to Flash (see "Current Workflow").

4. Automated Checks

• Even if Gemini removes spaces between Japanese text and alphanumeric characters, our tool restores them automatically.
• Because headings and link text are protected inside tokens, section titles, page titles, and source names will not change.
• These are checks on structure, not meaning. Because meaning can change even without altering any numbers, we do not skip the manual side-by-side comparison by the author in Step 6.

5. Test Results

We tested this three times on How to Use Rigid Tapping (12 sections). The author of that page was an AI (Claude). The same author also read and compared the revisions. [Test]

Here are examples of good revisions from the third run.

• The third example shows Gemini correcting an error in the original phrasing (runout "falling" rather than increasing). The revised meaning matches the original intent.
• Here is a helpful catch by Gemini: it pointed out that in "when returning at I2, it doubles at the upper reversal", what "upper reversal" meant was unclear. As a result, the author revised the original text to "reversal at the starting height."
• The results of the third run were incorporated into that page.
• The process took only a few minutes for the entire page (about 20,000 characters).

This page itself was also rewritten using post-editing into the polite style (--tone desu). [Test]

• On the first run, even table header cells were turned into full sentences like "This is the responsibility." and "This is what we check." We addressed this by protecting table headers and short cells without punctuation inside tokens.
• On the second run, the tone became gentler. However, the author restored five spots: check-item cells that became rigid statements like "...has not decreased.", sentences quoted as comparison examples that were mistakenly converted to polite forms, and conclusion bullet points where "First" and "Next" were added so they read like a procedure.
• Because of this, we updated our instructions to leave text inside quotation marks and quoted example sentences untouched.

Comparing Models (2026-11-05)

With the same instructions (polite style, --tone desu), we had three models revise the same page. We used Control and Electrical Configuration (6 sections, approx. 2,300 characters), which has not been post-edited yet. We ran each model once. The revised text has not been applied to that page. [Test]

Here is what we found:

• All three passed every automated check. Every model preserved numbers, model numbers, and certainty words like "unverified."
• The way meaning shifted differed by model. pro and flash weakened decisions into recommendations like "...gives peace of mind." argon added connecting words that introduced cause-and-effect relationships not present in the original. None of these were caught by automated checks; you only notice them by reading the side-by-side comparison.
• pro was the only one that softened a safety-critical sentence (confirming with a licensed electrician). argon and flash kept it as a definitive statement: "we will confirm" or "we make sure to check." We read sentences about hazardous work with extra care across all models.
• argon was the fastest, taking roughly half the time of pro.
• When reading the comparison, searching for where words like "gives peace of mind," "therefore," or "the reason being" were added helps find shifts in meaning quickly.
• Since this was only one run per model, we cannot tell yet whether the differences are model tendencies or run-to-run variations (estimated). We did not measure costs per model.

So, we added two rules to the instructions and tried the same page once more (run 2). The additions were "Do not weaken decisions into recommendations" and "Do not add cause-and-effect connections not present in the original" (section 3). We also removed "...gives peace of mind" from the tone examples. [Test]

• Across all three, the spots that shifted in the first run retained their original strength. "Gives peace of mind" did not appear in any model's output.
• The softness of the tone was slightly more subdued than in the first run. The polite desu/masu style was maintained.
• This was also just a single test run. To verify whether the rules actually worked or if it was just coincidence, we need to test other pages as well (estimated).
• The text fed to the models and their respective outputs (runs 1 and 2) are placed on sub-pages below this one.

6. Considerations for Public Release

• This site is open to the world. Because of that, we avoid writing company names, department names, people's names, and commercial transaction details. We also do not write server names, connection methods, or tokens.
• We do not attach manufacturer drawings, catalogs, or images from sales pages. We draw diagrams ourselves. Quotes are kept short and include source citations.
• Unverified figures are marked as "unverified" or "estimated." For hazardous work, we write in a way that avoids misunderstandings.
• The list of blocked words is kept in a non-public location. Tools check against that list along with fixed patterns like IP addresses and token formats.
• We only send text intended for publication to Gemini. This is because, depending on the tier you use, content sent through the Gemini API may be used to improve services (depending on the terms; handling under our current tier is unverified). If the text is meant to be published anyway, sending it is not an issue.
• When an AI handles the writing, we include these rules in the instructions that must be read before starting work.

7. Uncertainties

• Even with the same instructions, Gemini's responses vary slightly each time. Because of this, we read through the side-by-side comparison every time.
• Also, when models are updated, their writing habits change too. The current instructions were settled on using gemini-pro-latest.
• Short phrases inside table cells can sometimes get over-edited (though there were no issues during our test runs).
• The cost was about 1,000 yen for a day of testing ("Current workflow"). We have not measured the cost per model or per page.