From f0b473e106841fe798717cb045b7e9b3d553c1ce Mon Sep 17 00:00:00 2001 From: Michael Dieringer <65093775+MichaelDieringer@users.noreply.github.com> Date: Sun, 14 Jun 2026 15:56:45 +0200 Subject: [PATCH] translate --- .../architecture/clarify-before-building.md | 94 ++++++++++++++++++ .../xliff-translation-workflow.md | 96 +++++++++++++++++++ 2 files changed, 190 insertions(+) create mode 100644 custom/knowledge/architecture/clarify-before-building.md create mode 100644 custom/knowledge/architecture/xliff-translation-workflow.md diff --git a/custom/knowledge/architecture/clarify-before-building.md b/custom/knowledge/architecture/clarify-before-building.md new file mode 100644 index 0000000..8767219 --- /dev/null +++ b/custom/knowledge/architecture/clarify-before-building.md @@ -0,0 +1,94 @@ +--- +bc-version: [all] +domain: architecture +keywords: [clarify, ambiguity, requirements, questions, before-coding, task-evaluation] +technologies: [al] +countries: [w1] +application-area: [all] +--- + +## Description + +Before writing any AL code, the agent must evaluate whether the task is +unambiguously defined. If the task can be interpreted in more than one way, +the agent must ask clarifying questions and wait for answers before proceeding. + +No code may be written, edited or deleted until the task is 100% clear. + +This rule exists because AL code changes affect compiled extensions, running +BC environments and test databases. An incorrect assumption costs more to +undo than a clarifying question costs to ask. + +## When to ask + +Ask before coding if any of the following is true: + +- The task mentions an object, field or flow that does not exist yet and the + design is not specified +- The expected behaviour could match more than one existing code path +- The task involves a business rule (amounts, thresholds, VAT, posting groups) + where an assumption could produce silently wrong ledger entries +- The scope is unclear: "fix this" or "make it work" without specifying what + correct behaviour looks like +- The counterparty type, document type, direction or posting flags are not + stated and cannot be unambiguously inferred from context +- The test assertions reference calculated values that depend on setup data + the agent has not yet read + +## How to ask + +State what you understand the task to be, then list the specific questions: + +``` +I understand the task as: [one sentence summary] + +Before I proceed, I need clarification on: +1. [specific question] +2. [specific question] + +I will not write any code until these are answered. +``` + +Do not write partial code while waiting. Do not write "placeholder" code. +Do not write code with TODO comments where a business decision is needed. + +## When NOT to ask + +Do not ask if: +- The task is fully specified with object names, field names, expected values + and posting behaviour +- The answer can be determined by reading existing source files or .md + documentation in the project +- The ambiguity is purely cosmetic (formatting, comment wording) + +If the answer is in the project's source files or documentation, read those +files first and resolve the ambiguity yourself before asking the developer. + +## Anti Pattern + +``` +// WRONG: Assuming and building +// Task: "write a test for the vendor flow" +// Agent assumes: Vendor, Incoming, Handle+Invoice, no contact +// Writes 80 lines of code +// Developer says: "I meant outgoing flow with a customer" +// Result: wasted work, possible production code changes to revert +``` + +## Best Practice + +``` +// CORRECT: Clarify first +// Task: "write a test for the vendor flow" + +I understand the task as: writing a test codeunit for a Settlement Voucher +flow where the counterparty is a Vendor. + +Before I proceed, I need clarification on: +1. Incoming (vendor delivers goods) or Outgoing (vendor picks up goods)? +2. Handle-only, Invoice-only, or combined Handle+Invoice in one run? +3. Should the test use an existing vendor from the database or create one + via LibraryPurchase.CreateVendor? + +I will not write any code until these are answered. +``` diff --git a/custom/knowledge/architecture/xliff-translation-workflow.md b/custom/knowledge/architecture/xliff-translation-workflow.md new file mode 100644 index 0000000..68a8279 --- /dev/null +++ b/custom/knowledge/architecture/xliff-translation-workflow.md @@ -0,0 +1,96 @@ +--- +bc-version: [all] +domain: architecture +keywords: [xliff, translation, xlf, caption, tooltip, enu, da-dk, de-de, no-nb, sv-se, de-at] +technologies: [al] +countries: [w1] +application-area: [all] +--- + +## Description + +CURABIS apps support the following locales: da-DK, de-DE, de-AT, nb-NO, sv-SE. +XLIFF translation is a batch operation — never line-by-line. The agent must +translate all trans-units in one pass without asking questions per string. + +## Tone and register + +Follow Microsoft Business Central's translation tone for each locale: + +- **da-DK**: Kort, direkte, professionel. Undgå høfligheds-De. Brug infinitiv + frem for bydeform. Brug BC-standardtermer: "Bogfør" ikke "Send til bogføring", + "Kreditor" ikke "Leverandør", "Finanspost" ikke "Finansregistrering". +- **de-DE**: Formell, Sie-Form. BC-Standardterminologie: "Buchen", "Kreditor", + "Sachposten". Substantive großschreiben. +- **de-AT**: Identisch mit de-DE. Keine österreichischen Dialektvarianten. +- **nb-NO**: Kort og profesjonell. BC-standardtermer: "Bokfør", "Leverandør", + "Finanspost". Bruk infinitiv. +- **sv-SE**: Kort, professionell. BC-standardtermer: "Bokför", "Leverantör", + "Redovisningspost". Undvik dialekt. + +## Workflow — one pass, no questions + +When asked to translate an XLIFF file: + +1. Read the entire source `.g.xlf` file in one operation +2. Translate ALL trans-units in memory +3. Write the complete translated file in one operation +4. Do not ask questions about individual strings +5. Do not pause between strings +6. Do not ask for confirmation per trans-unit + +If a term is ambiguous, apply the BC standard term for that locale and add a +single summary comment at the end — never interrupt the translation to ask. + +## Terms that must NOT be translated + +The following must remain in English in all locales: +- Object names used as identifiers (e.g. "Settlement Voucher") +- Field names that are part of the AL identifier (e.g. "Qty. to Invoice") +- Company names, product names, app names + +## Trans-unit structure + +```xml + + Post + Bogfør ← da-DK example + Button caption + +``` + +State must always be `translated` — never `needs-translation` or `new`. + +## Common BC terms reference + +| ENU | da-DK | de-DE | nb-NO | sv-SE | +|---|---|---|---|---| +| Post | Bogfør | Buchen | Bokfør | Bokför | +| Vendor | Kreditor | Kreditor | Leverandør | Leverantör | +| Customer | Debitor | Debitor | Kunde | Kund | +| Item | Vare | Artikel | Vare | Artikel | +| G/L Entry | Finanspost | Sachposten | Finanspost | Redovisningspost | +| Amount | Beløb | Betrag | Beløp | Belopp | +| Quantity | Antal | Menge | Antall | Antal | +| Invoice | Faktura | Rechnung | Faktura | Faktura | +| Receipt | Kvittering | Empfangsschein | Kvittering | Inleverans | +| Settlement | Afregning | Abrechnung | Avregning | Avräkning | +| Voucher | Bilag | Beleg | Bilag | Verifikation | +| Cash | Kontant | Bar | Kontant | Kontant | +| Threshold | Grænse | Grenzwert | Grense | Gräns | +| Incoming | Indgående | Eingehend | Inngående | Inkommande | +| Outgoing | Udgående | Ausgehend | Utgående | Utgående | +| Handle | Håndter | Verarbeiten | Håndter | Hantera | +| Weighbridge | Vægt | Fahrzeugwaage | Vekt | Våg | +| Scrap | Skrot | Schrott | Skrap | Skrot | + +## Error and warning messages + +Error messages follow the BC pattern: +- da-DK: Start with capital, end with period. "Du kan ikke bogføre et tomt bilag." +- de-DE: Formal, Sie-Form. "Sie können keinen leeren Beleg buchen." +- nb-NO: "Du kan ikke bokføre et tomt bilag." +- sv-SE: "Du kan inte bokföra ett tomt verifikat." + +ToolTip format (da-DK): "Angiver [hvad feltet indeholder]." — always starts +with "Angiver" for fields, "Åbner" for actions that open pages.