Turkmen Translator
← Journal
Published October 23, 2026· software localization, cat tools, qa, turkmen

The Variable Won't Take a Turkmen Suffix

Placeholder checks in CAT tools assume you can drop a token anywhere and the sentence still works. In an agglutinative language, that assumption breaks — and the QA flag can't tell a real bug from correct grammar.

A string came in last week that read {count} files deleted. Simple. Four words, one variable. My QA profile in the CAT tool wanted the variable intact, in place, untouched. Fine. Except Turkmen doesn't let me leave it alone, and the check doesn't know that.

In English the number just sits there in front of the noun and everyone moves on. In Turkmen the noun after a quantifier stays singular, so the plural -lar has no business showing up, and the real work happens at the end of the clause with case and tense. Word order flips. The variable that opened the English sentence ends up buried in the middle of mine, or shoved toward the back. The tool sees a token that moved and a token count that still matches and calls it a day. It never asks the question that actually matters: does the suffix I need to glue onto that number exist as text I'm allowed to type?

The token is a brick wall

Here's the part no English-first QA rule accounts for. A placeholder like {count} or %d renders at runtime as a bare numeral. In an agglutinative language you routinely want to hang a suffix off that numeral — a case ending, a question particle, a possessive. The text I'd need to write doesn't attach to a token in the editor, because the token is opaque. It's a brick. You can put words before it and after it, but you can't reach inside it or bolt a -ny onto its tail and have the tool understand that's deliberate.

So you get three bad options. You rewrite the sentence to avoid touching the variable, which sometimes produces stiff, obviously-translated Turkmen. You add the suffix as loose text right after the placeholder and pray the runtime concatenation doesn't put a space there. Or you flag it to the PM and ask whether the dev can switch to a format that supports grammatical variation. Most of the time nobody wants to hear the third one, because it means a code change for a language with, let's be honest, a small user base.

ICU MessageFormat was supposed to help, and for plurals in some languages it does. But the plural categories are built around a model where the number governs the noun's form. Turkmen's whole trick is that the number doesn't pluralize the noun. So the category machinery is solving a problem I don't have while ignoring the one I do — the ending on the number itself, driven by its role in the clause, not its value. one / other buckets don't capture that. You end up writing the same string into both buckets and the elaborate structure earns nothing.

What the QA check actually protects

I want to be fair to the tag and placeholder checks. They exist because real builds break when a %s goes missing or a paired tag loses its partner. I've shipped UI strings where a dropped {0} meant a blank space where a filename should be. That's a genuine runtime failure, and the automated check catches it faster than any human rereading 1,400 strings at the end of a long day. Keep it on. Always keep it on.

The problem is the check is binary and the grammar is not. It verifies presence, order-independence, and count. It cannot verify fit. And because it throws a warning the moment a variable lands somewhere unexpected, it trains you to make the text behave for the checker instead of for the reader. That's the quiet cost. You start writing to satisfy the panel, and the Turkmen gets a little worse every time you do.

My rule now: the placeholder check gets to veto a missing or duplicated token, no argument. It does not get a vote on word order or on whether a sentence reads naturally. When it flags a variable I deliberately moved, I clear it by hand and I don't second-guess myself. The log will show a dismissed warning. Good. That dismissal is me doing my job, not me being sloppy.

What I'd ask the agency for

If you're a PM sending software strings into Turkmen — or Finnish, or Hungarian, or Turkish, anything that stacks suffixes — two things make the QA actually useful instead of noisy.

Give me the context of how the variable renders. Is {count} an integer, or could it be formatted text? Will there be a space inserted on concatenation? That one answer decides whether I can suffix it at all. A screenshot or a developer comment field beats a guess every time.

And let me annotate a false positive once so it stays quiet. Most tools support locking a QA dismissal to a segment or a pattern. Nobody turns it on. So the same correct structure gets flagged across forty strings and the end-of-file report looks like a crime scene when nothing's wrong.

The check isn't the problem. Treating its silence as proof of quality is. A clean placeholder report means the tokens survived. It says nothing about whether the sentence can carry a suffix, and that's the sentence a Turkmen user has to read.