Skip to content

f-string wants a keep_en glossary row, and P05 has to allow it #34

Description

@tamnd

tutorial/inputoutput.po has an entry whose whole msgid is the word f-string. It has now cost five model calls across two tier 1 runs and still has nothing in the memory.

Every one of those calls did the right thing. f-string is a term of art that stays in English in Vietnamese Python documentation, so the model returned it unchanged, and P05 refused the answer for being identical to the source.

The classifier is not the place to fix this. f-string is not code, it is a word, and a rule broad enough to catch it would catch real prose. It is a glossary matter: a keep_en row saying the term stays as it is.

That leaves the second half, which is the one that needs a decision. P05 refuses an answer that is empty or identical to the source, and for an entry whose entire msgid is a keep_en term, identical to the source is the correct answer. So P05 needs to know about the glossary, or the stage needs to satisfy such an entry from the glossary without a call at all.

The second reads better. An entry that is exactly one keep_en term has one correct translation, it is known before any call is made, and spending a call to be told what we already knew is the same mistake the classifier was just fixed for. It would come through as source: passthrough with the glossary version recorded, which is a claim the audit can check.

Worth counting how many entries in the corpus are exactly one keep_en term before choosing, since if it is only this one the simpler answer may be a glossary row and an explicit P05 exemption.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is wrongglossaryTerminology contract and the matcher

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions