Pārbaudīt klientiem paredzētos tekstus mērķa valodā

Kad izmantot

Customer-facing copy in the target language has changed and must be checked before it is seen. Not for writing the copy in the first place — that belongs to growth.launch-website or growth.newsletter. Not for a contract or NDA translated for signature — that is documents.translate-contract, where the standard is legal equivalence, not marketing style. Not for a customer review or support reply already sent — that is growth.customer-reviews or support.answer-ticket.

Pirms sāc

• The source of truth is known — the file or record a future build reads. Checking a screenshot is not a check.
• The glossary exists (even five lines). Without it, S3 has nothing to check against.
• The target language is named. This playbook ships with the LV ruleset; each added language brings its own ruleset and terminology source.

Ko izpilde pieprasa1

Ceļš8 soļi

1. S1

   Scope the runaģents

   List the changed texts, their sources, the target language and where each will appear.

   Izdarīts, kad the run lists every text with its source location and publication channel.

2. S2

   Mechanical passaģents

   Run the language gate: diacritics present and correct, encoding clean (UTF-8), quotes and dashes as the brand uses them, spacing, obvious spelling.

   Izdarīts, kad a mechanical findings list exists, each with an exact location (file + line or CMS field).

3. S3

   Terminology passaģents

   Check domain terms against the company glossary; for terms the glossary does not cover, check the official terminology source. Flag any term that also appears in a signed contract or invoice template.

   Izdarīts, kad every flagged term has a verdict: matches glossary · proposed new term · conflict with contract wording.

4. S4

   Grammar and style passaģents

   Apply the target-language ruleset: agreement, case government, punctuation, register appropriate to the channel. Classify every finding: mechanical · terminological · style · blocking.

   Izdarīts, kad no finding is unclassified and blocking findings state why they block.

5. S5

   Back-check meaningaģents

   Compare the target text against the source text paragraph by paragraph: does it say the same thing — numbers, names, promises, conditions?

   Izdarīts, kad each paragraph carries a same / changed verdict, and every "changed" is explained.

   ⛔ A "correction" that changes a number, a promise or a condition is never mechanical — it goes to S6.

6. S6

   Rule on blocking and disputed findingsīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S6 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   Present blocking findings and any agent correction the owner may disagree with, each with the agent's reasoning.

   Izdarīts, kad every blocking finding has a decision: fix · accept as written.

   ⛔ "Accept as written" for a factual or contractual mismatch is not available to anyone — those are fixed.

7. S7

   Apply fixes in the sourceaģents

   Correct the source of truth, not the rendered page. Re-run the gate on the corrected source.

   Izdarīts, kad the re-run returns zero mechanical findings and the source contains the accepted wording.

8. S8

   Record and hand backaģents

   Attach the findings report to the run; add newly approved terms to the glossary; send the owner a summary: texts checked, findings fixed, findings accepted, anything still open.

   Izdarīts, kad the report is linked, the glossary is updated, and the summary is sent.

Pārbaudes — kā zinām, ka izdevās

• Re-run of the gate on the source returns zero mechanical findings (a clean run on the rendered page is not evidence).
• Diacritics and quotes render correctly in the browser or the actual channel, not only in the editor.
• Every term flagged in S3 matches the glossary or carries the owner's approval from S6.
• The S5 back-check has a verdict for every paragraph, including "same".

Ja noiet greizi

Ko atstāj katrs solis

1. S1the run lists every text with its source location and publication channel.
2. S2a mechanical findings list exists, each with an exact location (file + line or CMS field).
3. S3every flagged term has a verdict: matches glossary · proposed new term · conflict with contract wording.
4. S4no finding is unclassified and blocking findings state why they block.
5. S5each paragraph carries a same / changed verdict, and every "changed" is explained.
6. S6every blocking finding has a decision: fix · accept as written.
7. S7the re-run returns zero mechanical findings and the source contains the accepted wording.
8. S8the report is linked, the glossary is updated, and the summary is sent.

Ko saglabāt

The run id · the source text version checked · the findings report with verdicts · the S6 decisions (who, when) · the gate re-run output · the glossary diff.

Kā šī procedūra uzlabojas

After every 10 runs ask: how many findings were false positives the owner had to overturn — which rule produced them, and should it be relaxed? Did any finding reappear in a later run (a fix that never reached the source)? Did any blocking issue reach the public after publication? A new version changes the rule or the step that caused the false positive or the leak, and says so in its change note.