A locale field is a claim, not a description
Every record in this archive carries a locale. When it reads ru, a chain of consequences fires: the story is routed under /ru/journal, it is counted in the Russian edition, it is given a Russian byline, its reading time is printed with a Russian suffix, and it is wired into an hreflang cluster that tells search engines this is the Russian version of the piece.
None of that is a description of the text. It is an assertion about the text, made by a field. Google's own documentation on localized versions is blunt about the difference: it states that neither hreflang nor the HTML lang attribute is used to detect the language of a page, and that the language is determined algorithmically instead. The label is for us. The words are what gets read.
Nothing in this repository checks whether the two agree. The publication gate, shouldNoindexJournalPost in data/journal-data.js, reads the title, the SEO title, the description, the excerpt, the keywords and the tags, and matches them against a list of nine literal strings — lorem ipsum is one of them. Language is not among the things it looks at. No test in the suite asserts that a Russian post is in Russian.
So we wrote the check that did not exist and ran it on ourselves.
The test, and what it returned
For each of the 74 Russian-locale posts in data/generated-journal-posts.js we collected every prose string of three words or more: the title, the SEO title, the SEO description, the excerpt, the cover alt text, the CTA summary, every body heading, every body paragraph, every subsection heading and paragraph, both fields of every FAQ entry, every summary point and every checklist item.
A string is flagged when it contains at least one Latin letter and not a single Cyrillic character.
That rule cannot produce a false positive against real Russian prose, because real Russian prose contains Cyrillic. The only strings it could wrongly flag are Russian sentences written entirely in Latin transliteration, and the archive contains none. It will happily under-count in the other direction: a paragraph carrying forty English words and one Russian one passes clean. Every number below is therefore a floor, not a ceiling.
Across the Russian edition, 2,097 of 3,852 prose strings contain no Cyrillic at all. That is 54.44 per cent of everything the edition says.
At the level of whole articles: 43 of the 74 Russian posts are affected. Thirty-nine of them are at one hundred per cent — every string tested, from the headline to the last checklist item, comes back with no Cyrillic. One more sits at 97.2 per cent, with 69 of its 71 strings in English. The remaining three are lightly touched: two strings of 33, three of 56, two of 53. There is almost no middle. A Russian post in this archive is either fully Russian or fully not.
Counted by body words rather than by strings, 29,441 of the edition's 60,099 words sit in paragraphs with no Cyrillic — 48.99 per cent. Just under half of the Russian edition's prose, by volume, is English.
It lands on the parts a reader meets first
The damage is not buried in the tenth paragraph. It is concentrated in exactly the fields that a reader, a card and a search result see before anything else.
Of the 74 Russian posts: 42 have an English title. Forty-one have an English SEO title. Forty have an English SEO description. Forty have an English excerpt. Forty-two have English cover alt text, which is what a screen reader announces. Forty carry at least one English body heading, 40 carry at least one English FAQ question, and 40 carry at least one English checklist item.
The keyword lists tell the same story with a useful control built in. On the 43 affected posts, 377 of 397 keyword phrases — 95.0 per cent — contain no Cyrillic. On the 31 clean posts, the figure is 16 of 266, or 6.0 per cent. Latin characters in a Russian keyword list are not wrong on their own; brand names are Latin, and that is what the 6 per cent is. The contrast between 95 and 6 is the evidence, not the raw count.
These are not translations that failed
The intuitive explanation is that a translation step was skipped and the English original was left in place. The data does not support it.
Of the 39 fully-English Russian posts, only 8 have an English-locale sibling on the same base slug once a single leading en-, ru- or es- prefix is removed. None of those 8 shares a title with its sibling. Across the entire Russian edition, only 14 prose strings match a string from any English post after case and punctuation folding, spread over 11 posts.
In other words, these are not the English articles from the English edition sitting in the wrong folder. They are different English articles, written in English, filed as the Russian edition. A reader who switches language is not being shown an untranslated version of the story they were reading. They are being shown another story, also in English.
That distinction matters for the fix. A missing translation step can be re-run. Content generated in the wrong language has to be commissioned again.
The defect has edges, and the edges are the good news
Two boundaries emerged that we did not go looking for.
The first is a date. Every one of the 43 affected posts carries a publishedAt between 2026-06-29 and 2026-07-11. Of the 60 Russian posts dated on or before 2026-07-11, 43 are affected; of the 14 dated after it, none are. The clean posts run from 2026-07-01 to 2026-08-09, so the two groups overlap in time rather than sitting in separate eras — but nothing published after 11 July failed the test.
The second is a byline. All 43 carry the author string VITON13 Editorial (ru). That byline covers 60 Russian posts in total, so 17 of its own are clean. The other four Russian bylines in the file — VJOURNAL Editorial with 4 posts, Редакция VJOURNAL with 5, VITON13 Editorial Intelligence with 4 and Редакция VITON13 with 1 — are clean without exception: 0 of 14.
All 43 carry the status Published. None was held back, and none was flagged.
A defect with edges is a run, not a policy. Something changed on or around the second week of July and the Russian edition started coming out in Russian. This audit cannot say what changed, only that the change is visible in the data and that the earlier run was never revisited.
Spanish, as far as the same method can reach
The Cyrillic test does not transfer to Spanish, which shares an alphabet with English. The closest available substitute is a different question: is this Spanish string identical, after case and punctuation folding, to a string that appears in an English post?
Six are. They sit across 5 of the 74 Spanish posts: three FAQ questions, two body headings and one SEO title. No Spanish title matches an English title.
That test is weaker than the Cyrillic one in a specific way, and the difference should be stated rather than glossed. It can only catch English text that was copied from an English post in this same file. English prose written directly into a Spanish record, with no twin anywhere, would pass it invisibly. So the honest claim is narrow: under the strongest test we could apply to Spanish, no pattern resembling the Russian failure appeared. We are not asserting the Spanish edition is clean. We are reporting that we did not find the same fault, with a method that would have struggled to.
The byline was telling us the whole time
VJOURNAL's first-party dataset, generated on 12 August 2026 over a 207-post snapshot of the same file, lists six author strings for the entire archive: VITON13 Editorial on 60 posts, VITON13 Editorial (es) on 60, VITON13 Editorial (ru) on 60, VJOURNAL Editorial on 17, Redacción VJOURNAL on 5 and Редакция VJOURNAL on 5.
Look at the shape of the third one. VITON13 Editorial (ru) is not a desk name. It is an English desk name with a language code bolted on in brackets — a locale tag wearing a byline's clothes. Two of the six author strings are actual Russian and Spanish desk names; two are the English name with a suffix.
This is VJOURNAL's own reading rather than a fact the data states: where a pipeline treats a language as a formatting suffix on a name, it is not surprising to find it treating that language as a formatting suffix on an article. The byline that appears on all 43 untranslated posts is the byline that was never really translated either.
What the script cannot tell you
It cannot judge a translation. The 31 clean Russian posts pass a test for the presence of Cyrillic characters, which is an extraordinarily low bar. Whether they read like Russian written for Russian readers, or like English sentences wearing Russian words, is a question this method is structurally unable to answer, and we are not answering it here.
It cannot tell you whether anyone noticed. There is no analytics event in this repository that records a language mismatch, a bounce or a time on page against these posts. We have counted what was published, not what was experienced.
It cannot name a cause. We did not read pipeline logs, and we are not attributing the run to a specific generation job or model call. The date boundary and the byline boundary are observations about the records, not a reconstruction of what happened.
And it measures one file. data/generated-journal-posts.js is one of several sources merged into the archive the site serves; curated and desk-seeded posts live elsewhere and were outside this count. The 74 Russian posts audited here are the ones in that file on the day of the audit.
Two honest options, and one that is not
There are exactly two defensible responses. Translate the 43 properly, or relabel them: move them to the English edition, drop the ru locale, drop the Russian byline and let them be what they are. Either is honest.
The third path — leaving English prose under a ru locale, with a Russian byline, a Russian-suffixed reading time and an hreflang tag telling search engines this is the Russian version — is the only option that involves a claim we know to be false. It is also, until somebody acts on this, the status quo.
The check itself is trivial. The rule at the top of this article is one regular expression. A test asserting that every post with locale ru has at least one Cyrillic character in its title would have failed on 42 posts the day they were written, and would have cost less to write than this paragraph.
The reason it was never caught is not that the failure was subtle. Forty-two English headlines in a Russian edition are not subtle. The reason is that nobody had printed the count. This is the printout.
Questions and answers
How can I tell whether a multilingual website is actually translated?
Test the text, not the tags. For a language with its own script the check is one line: assert that every string a page renders contains at least one character from that script. For languages that share an alphabet, compare each string against the corresponding string in your source language and flag exact matches. Running the first test on VJOURNAL's Russian edition flagged 2,097 of 3,852 prose strings across 43 of 74 posts.
Does hreflang tell a search engine what language a page is written in?
No. Google's documentation on localized versions states that it does not use hreflang or the HTML lang attribute to detect a page's language and determines the language algorithmically instead. Those annotations describe how your versions relate to each other; they do not certify the contents. A page can be tagged as the Russian version and be read as an English page, which is precisely the situation this audit found on 43 posts.
How much of VJOURNAL's Russian edition is actually in Russian?
By strings, 45.56 per cent — 1,755 of 3,852 prose strings contain Cyrillic. By body word count, 51.01 per cent: 30,658 Russian words against 29,441 in paragraphs with no Cyrillic at all. By whole articles, 31 of 74 posts are clean. Thirty-nine are English from headline to checklist, one is 97 per cent English and three carry a handful of English strings each.
Why would an article in a site's Russian section be written in English?
In this case it was not a translation that failed. Only 8 of the 39 fully-English Russian posts have an English-edition counterpart on the same base slug, and none of those 8 shares its title, so the text was not copied over from the English edition. The posts appear to have been generated in English and filed under the Russian locale directly. All 43 carry a single byline and all were published within a fortnight of each other.
What is the cheapest test for missing translations on a site?
A script-presence assertion in your test suite, run against your own content records rather than your rendered pages. It needs no network access, no translation memory and no reviewer. On this archive it would have caught 42 English headlines the day they were written. The expensive part is not the test — it is publishing the number once the test starts failing.