translate

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.
+```

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
+<trans-unit id="..." size-unit="char" translate="yes" xml:space="preserve">
+  <source>Post</source>
+  <target state="translated">Bogfør</target>  ← da-DK example
+  <note from="Developer" annotates="source" priority="2">Button caption</note>
+</trans-unit>
+```
+
+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.