This week, one of our articles went live with the wrong word glued to "Verboo Code" in Portuguese, and nobody caught it until after it was published in all three languages. In three other posts, the Chinese draft had a plain ASCII comma where it needed the full-width form instead. The fix always existed, it just depended on someone looking at the screen closely enough. We replaced that with a script, tested it against the real errors we had already lived through, and found a bug in the script itself in the middle of testing.
What slipped through the blog this week?
At least four times between September 21 and 23, 2026, always one of the same two problems: leftover ASCII punctuation in the Chinese draft, or a Portuguese gender error next to "Verboo Code" (the brand is always feminine in Portuguese, "a Verboo Code"). One of them was only caught after publishing.
| Date | Post | Error | When it was caught |
|---|---|---|---|
| Sep 21 | /rewind | ASCII comma in the zh draft | before publishing, in visual review |
| Sep 22 | Kimi K3 vs Claude Fable 5 | ASCII comma and colon in the zh draft | before publishing, with a script written on the spot just for this case |
| Sep 23 | Codex CLI in /resume | Portuguese gender error next to "Verboo Code" | only after publishing in all 3 languages, fixed with unpublish and republish |
| Sep 23 | Codex, 432 Workspace routing error | ASCII comma in the zh draft | before publishing, in visual review |
Why isn't visual review enough on its own?
Because the error is too small for the eye to catch every time. An ASCII comma in the middle of two hundred Chinese characters takes up almost the same width as the full-width version, and nobody stops to measure punctuation mark by punctuation mark. The gender error is worse: the wrong form is grammatically correct Portuguese, it is only wrong for this specific brand, so nothing about it stands out.
The September 23 case passed review from whoever wrote it, whoever generated the translation, and whoever checked it before publishing, and it still went live. It only surfaced in a check run afterward, on text that was already published.
How does the script we wrote work?
Four checks, each built on a regular expression, running against the draft's HTML before the first publish, not only after it:
python3 checar_padrao.py draft.html pt
python3 checar_padrao.py draft.html zhOne of the four, the gender one, is Portuguese specific, since English and Chinese have no grammatical gender to get wrong here:
GENERO = re.compile(
_B_INI + r"(o|do|no|ao|dos|nos|aos)\s+Verboo\s+Code" + _B_FIM,
re.IGNORECASE,
)The other three follow the same boundary logic: one catches both dash characters (Unicode marks U+2014 and U+2013) anywhere in the text; another catches an ASCII comma, colon, or semicolon glued to a Chinese character (range U+4E00 to U+9FFF); the last one catches the name of the offer Verboo Code no longer has. It exits with code 1 when it finds something, so it can sit as a gate before any publish call instead of depending on someone remembering to look at the screen.
The trap the script itself fell into
In the first version, the gender check and the old-offer check both used \b, Python's default word boundary. Testing it against a real Chinese sentence, with a Portuguese word glued right after a character with no space, the script found nothing. The reason: Python's \b treats a CJK character as a word character, so there is no boundary at all between a Chinese character and the letter right after it. The check was missing exactly the language where the punctuation problem is most common.
The fix replaced \b with a custom boundary that only counts a Latin letter or digit as part of a word:
_B_INI = r"(?<![A-Za-zÀ-ÿ0-9_])"
_B_FIM = r"(?![A-Za-zÀ-ÿ0-9_])"After the fix, the same test caught the word glued to the Chinese character, along with the ASCII punctuation next to it.
Does the script actually catch the errors that already happened?
We tested it against a reconstruction of both real cases, plus a clean text as control:
| Input | Result |
|---|---|
| A sentence rebuilding the September 23 gender error | Failed: found the wrong form next to "Verboo Code" |
| A Chinese sentence with an ASCII comma and colon glued to the characters | Failed: found both occurrences |
| "Verboo Code keeps the session. Normal punctuation, no problem at all." | OK: nothing found |
Run against the three drafts of this very article, pt, en and zh, the script found nothing in any of them. That makes sense: to explain the error without repeating it, this text describes the wrong form instead of reproducing the exact phrase, so there is nothing left for the check to mistake for a new mistake. That is the same reason the test table above uses a description instead of the literal sentence.
Writing the script, testing it, finding a bug in the check itself and fixing all of it fit into one morning of trying things, because no attempt was expensive. With Verboo Code, tokens are unlimited within the plan, so the fifth attempt costs the same as the first.
