Sixty thousand words, an inherited memory, and a termbase that is wrong

Follow the style guide's process, not its content - because the termbase entry is a concept error, and the guide was written assuming the termbase is right.

1. Verify the concept from the product, not from the dictionary: string context, screenshots, a developer or product-owner confirmation that a tenant is a customer organisation in a shared database.
2. Gather evidence for a target term. In German ERP usage this is Mandant; Mieter and Pächter are both leasehold words and will read as a category error to any German administrator. Cite existing usage rather than asserting a preference.
3. Escalate as a decision request, not a complaint. One page: current entries, proposed Mandant, rationale, affected segment count, cost of changing later, options, and a 24-hour decision deadline. Meanwhile work the unaffected segments; do not sit idle and do not guess.
4. If approval is not given, follow the termbase and put your objection in writing, dated, before delivery.

The distinction that matters: silent compliance with a known error is a professional failure, and unilateral deviation is a contractual one. Documented escalation is the only position that is defensible in both directions.

Assume nothing about a memory whose vendor was terminated and whose last update predates the current product.

Audit. Pull metadata per TU: author, date, product version, termbase version, project. Then stratify a random sample across leverage bands - roughly 50 TUs at 100%, 100 at 70–99% fuzzy, 50 at 50–69% - and score against an error typology: wrong meaning, terminology, register (du/Sie), untranslated source, tag and placeholder damage, misalignment.

Automated checks across the whole memory, which cost minutes: termbase compliance, tag and placeholder integrity, number and unit consistency, source-target language detection, exact-duplicate conflicts, segments where source equals target.

Decision rule. Any systemic terminology error, or an error rate above about 2–3% in the 100% band, means the 100% matches are not free: downgrade them to fuzzy, or exclude them. State the number to the PM, not the concern: "of 7,200 words of 100% matches, 60% need review at minimum, which adds X words to the plan."

Convert to schedule. Rebuild the leverage table, re-estimate effort per band, and present the revised Friday feasibility with options: reduce scope by module, add a linguist, or move MT volume. The PM can only make that trade-off if you give them numbers on Monday.

Triage by segment type, not by a blanket 40%. MT-suitable: short UI strings, high-repetition patterns, terminology-bound content with a pushed glossary, no variables. MT-hostile: strings with placeholders or tags, error messages, legal and marketing text, hard length limits, and very short ambiguous segments ("Print", "Open", "Post") where the engine has no context and the post-editor has no reason to look.

Protect the code. Regex-mask placeholders and tags before the engine sees them, and check them back in afterwards. A post-edited string that has lost a variable is a production bug, not a style issue.

Define light post-editing in writing - terminology, meaning, grammar, no stylistic polishing - and measure it: pilot 300 segments, compare post-editing speed and quality against full editing, and report the actual gain. If the assumed productivity doesn't appear, say so on Tuesday, not Friday.

Coordinate three people. Shared glossary pushed to the engine and the CAT tool, a single query log reviewed once a day, a fifteen-minute sync, one nominated cross-checker, and a final automated QA pass (tags, numbers, terminology, string length for UI, du/Sie consistency) run on the whole delivery rather than per translator. Friday is realistic only if scope is phased by module - propose the phasing yourself.