Showing posts with label MS Word. Show all posts
Showing posts with label MS Word. Show all posts

Tuesday, October 06, 2026

Square brackets in certified translations: the translator's voice, and how to format it in one pass

Not everything on the page of an official document is text. There are seals, stamps, signatures, barcodes, letterheads, coats of arms, handwritten notes, and the occasional line that is half cut off by the scanner. A translation still has to account for all of it, and the standard way to do that is to describe each element in square brackets: [Signature], [Barcode], [QR Code], [Inked stamp: …], [illegible].

Two kinds of parentheticals

Official documents are full of round parentheses. The source author puts them there, so they get translated like everything else. Square brackets are different: they signal that the text inside is the translator's, not the author's.

A reviewer, a credential evaluator, or an immigration officer should be able to tell at a glance what the document says and what the translator adds to the document. Brackets make that distinction visible. They are used for:

  • Non-text elements (seals, stamps, signatures, logos, barcodes, QR codes)
  • Text that can't be read or is partly missing ([illegible], [partially cut off])
  • Handwritten additions, and descriptions of the paper or layout when relevant
  • The occasional clarification, such as the original term next to a translated entity name

Conventions vary somewhat between agencies, clients and authorities, so always check what the recipient expects.

Making them stand out

Some translators go one step further and set all bracketed notes in a different font or size, for instance a smaller italic sans-serif. In a one-page certificate with a dozen notes, formatting each by hand is tedious and error-prone. Word can do it in a single pass with a wildcard search.

How to do it

  1. Open Find and Replace (Windows: Home > Replace; Mac: Edit > Find > Advanced Find and Replace), click More >>, and tick Use wildcards.
  2. In Find what, enter \[*\]
  3. In Replace with, enter ^&, which puts back whatever was matched. With the cursor still in that box, click Format > Font and choose the font, size or style you want.
  4. Click Replace All.
Word's Find and Replace dialog with "Use wildcards" checked, Find what set to \[*\], and Replace with set to ^& with a font format applied.

Find and Replace with wildcards enabled: search for \[*\] and replace with ^&, applying a new font to every bracketed note.

A few notes:

  • The backslashes are needed because [ and ] are special characters in wildcard mode.
  • When you're done, put the cursor in the Replace box and click No Formatting. Otherwise the font setting carries over to your next search and replace.
  • The pattern matches anything between square brackets, so it also catches the long descriptive line at the top of a document. A bracket that runs across a paragraph break won't match.
  • Text boxes, headers and footers may need a separate pass, as in the spell check blind spot I wrote about recently.

Monday, August 24, 2026

The spell check blind spot hiding in your Word documents

If you work with multilingual Word documents — and if you're reading a translation blog, you probably do — you've likely run into this: you select all the text, change the proofing language, run spell check, and everything looks clean. Then a client or colleague points out a misspelled word in a footnote. Or a text box. Or a header that somehow never got the memo.

This isn't a one-off glitch. It's a structural blind spot in how Word handles language, and it's common enough that I ended up writing a macro to fix it properly, once and for all.

Why this happens

In Word, language is a piece of direct formatting — the same category as bold or font size. When you press Ctrl+A and change the proofing language, you're only changing the language of whatever Ctrl+A actually selected. And Ctrl+A selects the main body text only.

It does not reach:

  • Headers and footers
  • Footnotes and endnotes
  • Comments
  • Text boxes and other floating shapes
  • The language baked into the document's styles themselves

Each of these is either a separate "story" in Word's internal model, or a separate object entirely, or a property of a style rather than of any visible text. Ctrl+A has no idea they exist.

The consequence: a document that looks "fully switched" to French, say, can still have an English footer that spell check quietly skips, or flags using the wrong dictionary. Worse, even if you painstakingly fix every visible instance by hand, a style's own internal language setting can still be wrong — meaning if someone later clears formatting on a paragraph, or types fresh text under that style, it silently reverts to the old language.

For anyone handling multilingual documentation, DTP files, or translated deliverables, this is exactly the kind of thing that slips past a visual review and turns up in a client's QA pass instead.

What the macro does

I built a Word VBA macro — EnhancedSpellchecker — that walks every part of a document that can independently carry a language, and forces it all to match one target language you pick. Then it runs Word's own spell checker, so you see the result immediately.


 

Concretely, it works in three passes:

Pass 1 — every story range, including linked chains such as different headers per section:

For Each storyRng In ActiveDocument.StoryRanges
    Do
        storyRng.LanguageID = TargetLanguage
        storyRng.NoProofing = False
        Set storyRng = storyRng.NextStoryRange
    Loop Until storyRng Is Nothing
Next storyRng

StoryRanges gives you one range per story type — body text, headers, footers, footnotes, endnotes, comments. Some of these are linked chains (for example, a document with different headers per section), so the inner Do...Loop walks NextStoryRange until the chain runs out, rather than assuming one range is the whole story.

Pass 2 — floating shapes with text, such as text boxes and callouts, which live outside any story range entirely:

For Each shp In ActiveDocument.Shapes
    If shp.TextFrame.HasText Then
        shp.TextFrame.TextRange.LanguageID = TargetLanguage
        shp.TextFrame.TextRange.NoProofing = False
    End If
Next shp

(One thing that surprised me while building this: Word's InlineShape object — pictures, embedded OLE objects, ActiveX controls — has no TextFrame property at all, and text boxes can never become inline shapes in Word's model. So every shape that can hold proofable text is already reachable here, in Shapes. No separate pass needed.)

Pass 3 — every style stored in the document, so the fix survives "Clear Formatting" and applies automatically to new text typed later:

For Each stl In ActiveDocument.Styles
    If stl.NameLocal <> "No Proofing" Then
        stl.LanguageID = TargetLanguage
        stl.NoProofing = False
    End If
Next stl

This is the pass most similar macros skip, and it's the one that matters most for long-term correctness. Direct formatting fixes what's on the page right now; the style-level fix addresses the root cause, so the document doesn't quietly drift back to the wrong language later. Note that it deliberately leaves any "No Proofing" style alone, since that style typically exists on purpose — to mark things like code samples that shouldn't be spell-checked at all.

What this solves in practice

Run the macro once, pick your target language from Word's standard language dialog, and it:

  • Applies that language consistently across the entire document — content and structure alike
  • Turns proofing back on everywhere it had been switched off
  • Leaves deliberately-excluded content (like a "No Proofing" style) untouched
  • Immediately runs spell check, so you can see and fix what's left

For anyone managing multilingual templates, recurring document types, or files that get re-used and edited over months or years, this closes a gap that's otherwise very easy to miss — and very visible when a client catches it instead of you.

Want the full macro?

The three snippets above show the core logic, but the complete macro includes proper error handling, state restoration (so it doesn't leave Word's language auto-detection permanently disabled), and full inline documentation explaining each decision — plus a companion guide covering installation, keyboard shortcuts, and known edge cases.

It's hosted on GitHub. Get in touch using the form on the right and I'll send you the link.