A translation is only as finished as its least-read field

Every multilingual site has a translated layer and an untranslated one, and the line between them is not drawn by importance. It is drawn by visibility. Body text gets translated because a person reads it. The fields only machines read, such as the locale a share card declares, the filename of an image and the alt text a screen reader speaks, stay in the source language because nobody in the review loop ever sees them. A second language is only as finished as its least-read field, and that is exactly where it is least likely to be checked.

A reviewer reads the page, not the page's head

The normal way to approve a translation is to read it. A native speaker opens the Finnish page, reads the headline and the argument, fixes a clumsy sentence and signs off. That review is necessary, and blind to most of what makes the page Finnish to anything but a human eye.

A screen reader speaks the alt text of every image. A link pasted into Slack or LinkedIn does not show the article; it shows a card assembled from Open Graph tags in the page's head. Image search does not see what an illustration means; it sees a filename and an alt attribute. Each of these audiences meets a different layer, and none of those layers appears on the screen the reviewer is approving.

The failure is structural, not careless. The fields that leak are the ones outside the reviewer's view.

What our own Finnish pages said on 11 October

Before writing this, we read the rendered head of our own Finnish pages. The visible layer held up. The html lang attribute says fi, the title, description and structured-data headline are Finnish, and the interface is Finnish down to the label on the search button.

None of our pages declares an og:locale, and the Open Graph protocol is explicit about what that means: the default is en_US. Every Finnish post we have published has told every share card that it is American English. The heroes on posts older than a week still carry English alt text, so a Finnish screen-reader user hears an English scene description in the middle of a Finnish article. We found that on 6 October, fixed the rule for new images, and have not yet backfilled the old ones. Every hero file is named after the English slug. And our Twitter card still names @payloadcms as its creator, a default inherited from the template the site was built on, which nobody has looked at in either language.

That last one is not a translation problem at all, which is why it is the most telling. A field nobody reads is reviewed in no language, and a second language doubles the places where that is true.

Update, 15 October 2026: og:locale, the @payloadcms credit and the old English alt text are now fixed. The filenames stay English, as argued below. The paragraph above records 11 October.

Not every leak costs the same

Most of this does not deserve a panic. None of these fields is a ranking lever. Google's own multilingual guidance says it uses the visible content of a page to determine its language and ignores code-level signals such as the lang attribute. A share card that claims the wrong locale will not cost you a position in search.

The costs are narrower and more human. Alt text in the wrong language is the serious one, because it fails the reader who has no other way into the image. A share card labelled en_US is a small inaccuracy handed to every platform that reads it. Filenames sit at the bottom. Google's image guidance does say that if you localize your images you should translate the filenames too, but that advice concerns images you want found in image search. Our heroes are decorative, and we would rather store one file than a copy per language.

The honest rule is not "translate everything". It is to decide, field by field, what the second language owes its audience, then check those fields on the rendered page.

Template fields are where an engine should win

This is one place where an automated blog ought to beat a translation agency. Every field on our list is produced by a template, not written by hand. A human translator working in a document never sees og:locale, because it does not exist in the document. An engine owns the whole page, so the change that makes one post's head locale-aware makes every post's head locale-aware. That is the argument we made yesterday about reviewing the rule rather than the page, applied to language.

What an engine cannot do is notice the gap on its own. Ours emitted en_US on Finnish pages for six weeks, and nothing complained, because nothing was asked to. The check has to be written down: fetch the rendered page in each locale, read its head, and compare it field by field with the other language.

Count a locale as shipped when its head is translated

A second language is a maintenance commitment, and this is the part nobody budgets for, because nobody sees it. The body is what a buyer reads. The head is what the buyer's screen reader, browser and team chat read before the buyer arrives.

If you run a site in two languages, the test takes five minutes. Open one page in your second language, view its source, and read everything above the first paragraph. Whatever is still in the first language is what that audience has been told you did not finish. Our own list is filed: the locale tag is one line in a template, and the alt backfill is one script.