@harness-engineering/cli 1.7.0 → 1.8.0

package/dist/agents/skills/shared/i18n-knowledge/industries/healthcare.yaml

@@ -0,0 +1,66 @@
+name: "Healthcare"
+description: "i18n challenges in healthcare — patient safety through unambiguous dates, medical terminology precision, and regulatory compliance"
+
+requirements:
+  - area: "Date Format Safety"
+    description: "Ambiguous dates in medical contexts can be life-threatening — 01/02 could mean Jan 2 or Feb 1"
+    severity: error
+    locales_affected: "all"
+    examples:
+      - bad: "Prescription date: 01/02/2025"
+        good: "Prescription date: 02 Jan 2025 (unambiguous month name format per FDA/EMA guidance)"
+  - area: "Medical Terminology Precision"
+    description: "Medical terms must not be machine-translated — incorrect translation of drug names or dosages risks patient safety"
+    severity: error
+    locales_affected: "all"
+    examples:
+      - bad: "Auto-translating 'once' (English: one time) which means 'eleven' in Spanish"
+        good: "Use verified medical glossaries; have translations reviewed by locale-specific medical professionals"
+  - area: "Unit of Measurement"
+    description: "Dosage units, body measurements, and lab values use different systems by region"
+    severity: error
+    locales_affected: "all"
+    examples:
+      - bad: "Displaying weight in pounds for a metric-system locale"
+        good: "Detect locale and display in expected units (kg/cm for most locales, lb/in for US)"
+  - area: "Patient Consent Forms"
+    description: "Informed consent must be in the patient's language and meet local legal requirements"
+    severity: error
+    locales_affected: "all"
+    examples:
+      - bad: "Presenting consent form only in English for non-English-speaking patients"
+        good: "Provide certified translations of consent forms in all supported patient languages"
+  - area: "Instructions for Use (IFU)"
+    description: "Medical device IFU must be translated per MDR/IVDR requirements for EU markets"
+    severity: error
+    locales_affected: ["EU member states"]
+    examples:
+      - bad: "Shipping medical device with English-only IFU to Germany"
+        good: "Include IFU in the official language(s) of each target market per MDR Article 10(11)"
+
+anti_patterns:
+  - pattern: "Machine-translating drug names or medical procedures"
+    reason: "Drug brand names differ by country; procedures have specific medical terminology per locale"
+    instead: "Use locale-specific medical dictionaries and have all medical content reviewed by qualified translators"
+  - pattern: "Using ambiguous date formats in clinical records"
+    reason: "Date misinterpretation in medical contexts can lead to wrong treatment timing"
+    instead: "Use DD-MMM-YYYY format (02-Jan-2025) in clinical records per ICH guidelines"
+  - pattern: "Displaying lab reference ranges without locale context"
+    reason: "Reference ranges and units vary by country (mmol/L vs mg/dL for blood glucose)"
+    instead: "Store values in a canonical unit and convert for display based on locale medical conventions"
+  - pattern: "Truncating patient names to fit fixed-width fields"
+    reason: "Names in many scripts (Arabic, Devanagari, CJK) may be truncated incorrectly, causing identity errors"
+    instead: "Use flexible-width name fields; never truncate patient identification information"
+
+regulations:
+  - name: "FDA 21 CFR Part 11"
+    locales: ["en-US"]
+    impact: "Electronic records must maintain data integrity including proper date/time formatting"
+  - name: "EU MDR (Medical Device Regulation)"
+    locales: ["EU member states"]
+    impact: "Labeling and IFU must be in the official language(s) of the member state where the device is sold"
+  - name: "HIPAA"
+    locales: ["en-US"]
+    impact: "Translation workflows must maintain PHI security; translators need BAA agreements"
+
+reference_products: ["epic.com", "cerner.com", "athenahealth.com"]

package/dist/agents/skills/shared/i18n-knowledge/industries/legal.yaml

@@ -0,0 +1,66 @@
+name: "Legal"
+description: "i18n challenges in legal technology — jurisdiction-specific terminology, unambiguous dates, and certified translation requirements"
+
+requirements:
+  - area: "Contract Date Formats"
+    description: "Ambiguous dates in legal documents can invalidate contracts or cause disputes"
+    severity: error
+    locales_affected: "all"
+    examples:
+      - bad: "Effective date: 01/02/2025 (ambiguous month/day)"
+        good: "Effective date: 2 January 2025 (unambiguous written month format)"
+  - area: "Legal Terminology Precision"
+    description: "Legal terms have specific meanings per jurisdiction — 'tort' in common law vs civil law systems"
+    severity: error
+    locales_affected: "all"
+    examples:
+      - bad: "Machine-translating 'consideration' (legal: something of value in a contract)"
+        good: "Use jurisdiction-specific legal glossaries maintained by qualified legal translators"
+  - area: "Jurisdiction-Specific Formatting"
+    description: "Legal citations, court names, and statutory references follow jurisdiction-specific formats"
+    severity: warning
+    locales_affected: "all"
+    examples:
+      - bad: "Using US legal citation format (Bluebook) for EU legal documents"
+        good: "Apply jurisdiction-appropriate citation styles (OSCOLA for UK, Guide des citations for France)"
+  - area: "Right-to-Left Legal Documents"
+    description: "Legal documents in Arabic and Hebrew must maintain correct reading order, especially for numbered clauses"
+    severity: error
+    locales_affected: ["ar", "he"]
+    examples:
+      - bad: "Generating Arabic legal PDF with LTR numbered lists"
+        good: "Use RTL-aware document generation with proper clause numbering direction"
+  - area: "Certified Translation Requirements"
+    description: "Legal documents often require certified or sworn translations with specific attestation formats"
+    severity: error
+    locales_affected: "all"
+    examples:
+      - bad: "Using uncertified machine translation for court filings"
+        good: "Use certified translators; include translator attestation in format required by target jurisdiction"
+
+anti_patterns:
+  - pattern: "Machine-translating legal contracts without human review"
+    reason: "Legal language is precise and jurisdiction-specific; MT errors can create unintended obligations"
+    instead: "Use qualified legal translators with jurisdiction expertise; MT may assist but never replace review"
+  - pattern: "Using the same legal terms across jurisdictions"
+    reason: "'Privacy policy' has different legal implications and required content across GDPR, CCPA, LGPD, PIPA"
+    instead: "Maintain jurisdiction-specific legal content; do not just translate — adapt to local legal frameworks"
+  - pattern: "Displaying contract amounts without locale-appropriate number formatting"
+    reason: "A contract for 1.000 means 1 in English but 1000 in German — financial disputes result"
+    instead: "Spell out amounts in words alongside numerals in legal documents; use locale-correct formatting"
+  - pattern: "Fixed-width contract templates for all languages"
+    reason: "German legal text expands 30-35% over English; Arabic/Hebrew need RTL-aware templates"
+    instead: "Use flexible document templates that adapt to text direction and expansion per locale"
+
+regulations:
+  - name: "GDPR (Article 12)"
+    locales: ["EU member states"]
+    impact: "Privacy information must be provided in clear and plain language — implies user's language"
+  - name: "LGPD (Brazil)"
+    locales: ["pt-BR"]
+    impact: "Data processing notices must be in Portuguese and comply with Brazilian data protection law"
+  - name: "Hague Convention"
+    locales: ["all signatory countries"]
+    impact: "International legal documents must follow apostille and translation requirements per country"
+
+reference_products: ["clio.com", "docusign.com", "ironclad.com"]

package/dist/agents/skills/shared/i18n-knowledge/locales/ar.yaml

@@ -0,0 +1,41 @@
+locale: "ar"
+name: "Arabic"
+native_name: "العربية"
+script: "Arabic"
+direction: rtl
+cldr_plural_categories: [zero, one, two, few, many, other]
+expansion_factor: 1.25
+script_characteristics:
+  avg_char_width: "standard"
+  requires_complex_shaping: true
+  line_break_rules: "standard"
+bidi_considerations:
+  mirror_icons: true
+  mirror_layout: true
+  mixed_direction_text: true
+  calendar_system: "gregorian"
+  digit_system: "arabic-indic"
+number_format:
+  decimal_separator: "٫"
+  grouping_separator: "٬"
+  grouping_size: 3
+date_format:
+  short: "DD/MM/YYYY"
+  long: "DD Month YYYY"
+  first_day_of_week: "saturday"
+common_pitfalls:
+  - pitfall: "Six plural forms — the most of any major language"
+    example: "Arabic has zero, one, two, few (3-10), many (11-99), and other (100+) — binary singular/plural fails"
+    fix: "Use ICU MessageFormat with all 6 CLDR categories; test with values 0, 1, 2, 3, 11, and 100"
+  - pitfall: "Letter reshaping based on position"
+    example: "Arabic letters change shape depending on position (initial, medial, final, isolated)"
+    fix: "Never split Arabic strings mid-word; use proper Arabic-capable fonts and text rendering engines"
+  - pitfall: "Layout mirroring — not just text direction"
+    example: "Navigation, icons, progress bars, and sliders must all mirror for RTL"
+    fix: "Use CSS logical properties (margin-inline-start, padding-inline-end) instead of left/right"
+  - pitfall: "Mixed LTR content within RTL context"
+    example: "Numbers, URLs, code, and brand names remain LTR within an RTL paragraph — bidi algorithm needed"
+    fix: "Use Unicode bidi algorithm correctly; wrap embedded LTR content with dir='ltr' or bidi control characters"
+  - pitfall: "Arabic-Indic digits vs Western digits"
+    example: "Some Arabic locales use ٠١٢٣٤٥٦٧٨٩ instead of 0123456789 — user expectation varies by region"
+    fix: "Default to Western digits for digital interfaces; provide Arabic-Indic digit option per user preference"

package/dist/agents/skills/shared/i18n-knowledge/locales/de.yaml

@@ -0,0 +1,35 @@
+locale: "de"
+name: "German"
+native_name: "Deutsch"
+script: "Latin"
+direction: ltr
+cldr_plural_categories: [one, other]
+expansion_factor: 1.35
+script_characteristics:
+  avg_char_width: "narrow"
+  requires_complex_shaping: false
+  line_break_rules: "standard"
+number_format:
+  decimal_separator: ","
+  grouping_separator: "."
+  grouping_size: 3
+date_format:
+  short: "DD.MM.YYYY"
+  long: "DD. Month YYYY"
+  first_day_of_week: "monday"
+common_pitfalls:
+  - pitfall: "Long compound words overflowing containers"
+    example: "'Geschwindigkeitsbegrenzung' (speed limit) is 26 characters with no natural break point"
+    fix: "Use CSS hyphens: auto with lang='de', or soft hyphens (U+00AD) for compound word break hints"
+  - pitfall: "Formal vs informal address (Sie/du)"
+    example: "Using informal 'du' in a banking app where formal 'Sie' is expected"
+    fix: "Establish formal/informal convention per product and apply consistently across all translations"
+  - pitfall: "Noun capitalization rules"
+    example: "Lowercasing a translated noun — all German nouns are capitalized regardless of position"
+    fix: "Never apply text-transform: lowercase to German text; preserve translator-specified capitalization"
+  - pitfall: "Text expansion of 30-35% breaking UI layouts"
+    example: "'Submit' (6 chars) becomes 'Absenden' (8 chars); 'Settings' becomes 'Einstellungen' (13 chars)"
+    fix: "Design for at least 35% text expansion; German is often the longest common Western European language"
+  - pitfall: "Date format with periods"
+    example: "Using DD/MM/YYYY instead of DD.MM.YYYY — German dates use periods as separators"
+    fix: "Use Intl.DateTimeFormat('de') for correct date formatting with period separators"

package/dist/agents/skills/shared/i18n-knowledge/locales/en.yaml

@@ -0,0 +1,32 @@
+locale: "en"
+name: "English"
+native_name: "English"
+script: "Latin"
+direction: ltr
+cldr_plural_categories: [one, other]
+expansion_factor: 1.0
+script_characteristics:
+  avg_char_width: "narrow"
+  requires_complex_shaping: false
+  line_break_rules: "standard"
+number_format:
+  decimal_separator: "."
+  grouping_separator: ","
+  grouping_size: 3
+date_format:
+  short: "MM/DD/YYYY"
+  long: "Month DD, YYYY"
+  first_day_of_week: "sunday"
+common_pitfalls:
+  - pitfall: "Assuming English word order applies universally"
+    example: "'Welcome, {name}!' — many languages place the name first or use different greeting structures"
+    fix: "Use complete translatable sentences with placeholders, never concatenate greeting + name"
+  - pitfall: "Using English-only date format assumptions"
+    example: "03/04/2025 is March 4 in US English but April 3 in most other locales"
+    fix: "Always use locale-aware date formatting (Intl.DateTimeFormat) and avoid ambiguous numeric dates"
+  - pitfall: "Hardcoding singular/plural as the only two forms"
+    example: "count === 1 ? 'item' : 'items' — works for English but fails for languages with more plural forms"
+    fix: "Use ICU MessageFormat or framework plural support that references CLDR plural rules"
+  - pitfall: "Relying on ASCII-only input validation"
+    example: "Regex [a-zA-Z]+ rejects valid names like 'René' or 'Müller'"
+    fix: "Use Unicode-aware patterns (\\p{Letter}) or avoid restricting character sets in name fields"

package/dist/agents/skills/shared/i18n-knowledge/locales/es.yaml

@@ -0,0 +1,35 @@
+locale: "es"
+name: "Spanish"
+native_name: "Español"
+script: "Latin"
+direction: ltr
+cldr_plural_categories: [one, other]
+expansion_factor: 1.25
+script_characteristics:
+  avg_char_width: "narrow"
+  requires_complex_shaping: false
+  line_break_rules: "standard"
+number_format:
+  decimal_separator: ","
+  grouping_separator: "."
+  grouping_size: 3
+date_format:
+  short: "DD/MM/YYYY"
+  long: "DD de Month de YYYY"
+  first_day_of_week: "monday"
+common_pitfalls:
+  - pitfall: "Ignoring inverted punctuation marks"
+    example: "Displaying 'How are you?' without the opening inverted question mark"
+    fix: "Spanish requires opening punctuation: 'Como estas?' — ensure translation tools preserve these characters"
+  - pitfall: "Not accounting for es-ES vs es-MX vs es-419 differences"
+    example: "Using 'ordenador' (Spain) when targeting Latin America where 'computadora' is standard"
+    fix: "Support regional variants (es-ES, es-MX, es-419) or use neutral Spanish as a fallback"
+  - pitfall: "Assuming gender-neutral nouns"
+    example: "Translating 'the user' — Spanish requires gendered articles (el usuario / la usuaria)"
+    fix: "Design UI strings to avoid gendered references or provide both forms where grammar requires it"
+  - pitfall: "Text expansion breaking fixed-width layouts"
+    example: "'Settings' (8 chars) becomes 'Configuracion' (13 chars) — a 62% expansion"
+    fix: "Design containers to accommodate 20-25% text expansion; test with Spanish translations early"
+  - pitfall: "Incorrect number formatting"
+    example: "Displaying 1,234.56 instead of 1.234,56 for Spanish locales"
+    fix: "Use Intl.NumberFormat('es') to format numbers with correct decimal comma and period grouping"

package/dist/agents/skills/shared/i18n-knowledge/locales/fi.yaml

@@ -0,0 +1,35 @@
+locale: "fi"
+name: "Finnish"
+native_name: "Suomi"
+script: "Latin"
+direction: ltr
+cldr_plural_categories: [one, other]
+expansion_factor: 1.40
+script_characteristics:
+  avg_char_width: "narrow"
+  requires_complex_shaping: false
+  line_break_rules: "standard"
+number_format:
+  decimal_separator: ","
+  grouping_separator: "\u00A0"
+  grouping_size: 3
+date_format:
+  short: "DD.MM.YYYY"
+  long: "DD. MonthTA YYYY"
+  first_day_of_week: "monday"
+common_pitfalls:
+  - pitfall: "Extreme text expansion due to agglutinative grammar"
+    example: "'in the house' translates to 'talossa' (one word); but compound phrases can be very long"
+    fix: "Design for up to 40% expansion; Finnish is one of the longest Western languages for UI strings"
+  - pitfall: "15 grammatical cases affecting word forms"
+    example: "'talo' (house) has forms: talon, taloa, talossa, talosta, taloon, talolla, talolta, talolle..."
+    fix: "Never programmatically construct Finnish phrases — let translators handle case inflection in full sentences"
+  - pitfall: "Vowel harmony in suffixes"
+    example: "Suffixes must match the vowel pattern of the root word — back vowels (a, o, u) vs front vowels (ä, ö, y)"
+    fix: "Do not attempt to programmatically add Finnish suffixes; always use translator-provided complete forms"
+  - pitfall: "No grammatical gender but complex number agreement"
+    example: "Finnish has no gendered nouns, but number-noun agreement is partitive: '1 talo' but '2 taloa'"
+    fix: "Use CLDR plural rules (Finnish has only one/other) and let translators handle partitive case in plural form"
+  - pitfall: "Long words breaking fixed layouts"
+    example: "'lentokonesuihkuturbiinimoottoriapumekaanikkoaliupseerioppilas' — valid compound word"
+    fix: "Use CSS overflow-wrap: break-word and hyphens: auto with lang='fi' to handle extreme compound words"

package/dist/agents/skills/shared/i18n-knowledge/locales/fr.yaml

@@ -0,0 +1,35 @@
+locale: "fr"
+name: "French"
+native_name: "Français"
+script: "Latin"
+direction: ltr
+cldr_plural_categories: [one, other]
+expansion_factor: 1.20
+script_characteristics:
+  avg_char_width: "narrow"
+  requires_complex_shaping: false
+  line_break_rules: "standard"
+number_format:
+  decimal_separator: ","
+  grouping_separator: "\u202F"
+  grouping_size: 3
+date_format:
+  short: "DD/MM/YYYY"
+  long: "DD Month YYYY"
+  first_day_of_week: "monday"
+common_pitfalls:
+  - pitfall: "Missing spaces before high punctuation"
+    example: "Bonjour! instead of 'Bonjour !' — French requires a non-breaking space before ; : ! and ?"
+    fix: "Insert a narrow non-breaking space (U+202F) before semicolon, colon, exclamation, and question marks"
+  - pitfall: "Confusing French number grouping"
+    example: "Displaying 1,234 instead of 1 234 — French uses narrow no-break space as grouping separator"
+    fix: "Use Intl.NumberFormat('fr') which correctly uses U+202F as the grouping separator"
+  - pitfall: "Not handling fr-FR vs fr-CA differences"
+    example: "Canadian French uses different vocabulary ('courriel' vs 'email') and some formatting conventions"
+    fix: "Support fr-FR and fr-CA as separate locales when targeting both markets"
+  - pitfall: "Gendered agreement in dynamic strings"
+    example: "'Vous etes connecte' vs 'Vous etes connectee' — adjective ending depends on user gender"
+    fix: "Use inclusive writing patterns or avoid gendered past participles in UI strings where possible"
+  - pitfall: "Quotation mark style"
+    example: "Using English \"quotes\" instead of French guillemets with spaces: 'texte'"
+    fix: "Ensure translation process converts quotation marks to locale-appropriate style (guillemets for French)"

package/dist/agents/skills/shared/i18n-knowledge/locales/he.yaml

@@ -0,0 +1,41 @@
+locale: "he"
+name: "Hebrew"
+native_name: "עברית"
+script: "Hebrew"
+direction: rtl
+cldr_plural_categories: [one, two, other]
+expansion_factor: 1.20
+script_characteristics:
+  avg_char_width: "standard"
+  requires_complex_shaping: false
+  line_break_rules: "standard"
+bidi_considerations:
+  mirror_icons: true
+  mirror_layout: true
+  mixed_direction_text: true
+  calendar_system: "gregorian"
+  digit_system: "western"
+number_format:
+  decimal_separator: "."
+  grouping_separator: ","
+  grouping_size: 3
+date_format:
+  short: "DD.MM.YYYY"
+  long: "DD b-Month YYYY"
+  first_day_of_week: "sunday"
+common_pitfalls:
+  - pitfall: "Dual number form (unique to Hebrew among major languages)"
+    example: "Hebrew has a special form for exactly two: 'יום אחד' (1 day), 'יומיים' (2 days), 'ימים' (3+ days)"
+    fix: "Use CLDR plural categories [one, two, many, other] — do not skip the 'two' form"
+  - pitfall: "RTL layout mirroring without Hebrew-specific testing"
+    example: "Icons that should NOT mirror in RTL (checkmarks, media play buttons) get mirrored anyway"
+    fix: "Create an icon exception list for bidirectional layouts; test with native Hebrew speakers"
+  - pitfall: "Nikud (vowel diacritics) in UI text"
+    example: "Modern Hebrew usually omits nikud — adding it looks childish or overly formal in a UI context"
+    fix: "Use unvocalized Hebrew for UI strings unless targeting children's educational content"
+  - pitfall: "Mixed Hebrew and English in tech interfaces"
+    example: "Hebrew UI with English brand names, code, or tech terms creates complex bidi paragraphs"
+    fix: "Wrap English terms in spans with dir='ltr' to prevent bidi algorithm from reordering them"
+  - pitfall: "Hebrew calendar for date display"
+    example: "Some users expect Hebrew calendar dates alongside or instead of Gregorian dates"
+    fix: "Use Intl.DateTimeFormat('he-IL', {calendar: 'hebrew'}) when Hebrew calendar is needed"

package/dist/agents/skills/shared/i18n-knowledge/locales/hi.yaml

@@ -0,0 +1,35 @@
+locale: "hi"
+name: "Hindi"
+native_name: "हिन्दी"
+script: "Devanagari"
+direction: ltr
+cldr_plural_categories: [one, other]
+expansion_factor: 1.30
+script_characteristics:
+  avg_char_width: "standard"
+  requires_complex_shaping: true
+  line_break_rules: "standard"
+number_format:
+  decimal_separator: "."
+  grouping_separator: ","
+  grouping_sizes: [3, 2]
+date_format:
+  short: "DD/MM/YYYY"
+  long: "DD Month YYYY"
+  first_day_of_week: "sunday"
+common_pitfalls:
+  - pitfall: "Indian number grouping system"
+    example: "1,23,45,678 not 12,345,678 — groups of 2 after the initial group of 3 (from the right)"
+    fix: "Use Intl.NumberFormat('hi-IN') which produces correct Indian grouping automatically"
+  - pitfall: "Devanagari ligatures and conjunct consonants"
+    example: "Two or more consonants combine into a single ligature glyph — font must support conjuncts"
+    fix: "Use fonts with comprehensive Devanagari OpenType support (Noto Sans Devanagari, Mangal)"
+  - pitfall: "Shirorekha (headline) connecting characters"
+    example: "Devanagari characters connect via a horizontal line at the top — breaking this line breaks readability"
+    fix: "Never insert spaces or line breaks within a Devanagari word; use proper shaping-aware text rendering"
+  - pitfall: "Hindi vs English digit display"
+    example: "Hindi can use Devanagari digits (१२३) or Western digits (123) — preference varies by context"
+    fix: "Default to Western digits for digital interfaces; use Devanagari digits only for traditional/cultural contexts"
+  - pitfall: "Font size requirements for Devanagari"
+    example: "Devanagari script has more vertical complexity than Latin — 12px may be too small for readability"
+    fix: "Use minimum 14px for Devanagari body text; the script has ascenders, descenders, and matras that need space"

package/dist/agents/skills/shared/i18n-knowledge/locales/it.yaml

@@ -0,0 +1,32 @@
+locale: "it"
+name: "Italian"
+native_name: "Italiano"
+script: "Latin"
+direction: ltr
+cldr_plural_categories: [one, other]
+expansion_factor: 1.20
+script_characteristics:
+  avg_char_width: "narrow"
+  requires_complex_shaping: false
+  line_break_rules: "standard"
+number_format:
+  decimal_separator: ","
+  grouping_separator: "."
+  grouping_size: 3
+date_format:
+  short: "DD/MM/YYYY"
+  long: "DD Month YYYY"
+  first_day_of_week: "monday"
+common_pitfalls:
+  - pitfall: "Article-noun gender agreement in dynamic content"
+    example: "'il file' (masculine) vs 'la cartella' (feminine) — article must match noun gender"
+    fix: "Include the article in the translatable string with the noun, never construct 'article + noun' dynamically"
+  - pitfall: "Double consonant sensitivity"
+    example: "Truncating words can break meaning — 'anno' (year) vs 'ano' (anus)"
+    fix: "Never truncate Italian words programmatically; use ellipsis on full word boundaries"
+  - pitfall: "Apostrophe handling in articles"
+    example: "'l'utente' (the user) — the apostrophe is grammatically required, not optional punctuation"
+    fix: "Ensure text processing and search indexing handle apostrophes within Italian words correctly"
+  - pitfall: "Text expansion in button labels"
+    example: "'Save' (4 chars) becomes 'Salva' (5 chars); 'Cancel' becomes 'Annulla' (7 chars)"
+    fix: "Allow for 15-20% expansion in Italian; test button and navigation labels with translated strings"

package/dist/agents/skills/shared/i18n-knowledge/locales/ja.yaml

@@ -0,0 +1,38 @@
+locale: "ja"
+name: "Japanese"
+native_name: "日本語"
+script: "CJK"
+direction: ltr
+cldr_plural_categories: [other]
+expansion_factor: 0.8
+script_characteristics:
+  avg_char_width: "wide"
+  requires_complex_shaping: false
+  line_break_rules: "no-spaces"
+  cjk_width_handling: true
+  vertical_text_support: true
+  multiple_scripts: true
+number_format:
+  decimal_separator: "."
+  grouping_separator: ","
+  grouping_size: 3
+date_format:
+  short: "YYYY/MM/DD"
+  long: "YYYY年MM月DD日"
+  first_day_of_week: "sunday"
+common_pitfalls:
+  - pitfall: "No word boundaries for line breaking"
+    example: "Japanese text has no spaces between words — standard word-wrap algorithms fail"
+    fix: "Use CSS word-break: auto or overflow-wrap: anywhere; rely on browser's built-in CJK line-break rules"
+  - pitfall: "Three writing systems in one string"
+    example: "A single sentence may mix kanji, hiragana, and katakana — font fallback chains must cover all three"
+    fix: "Specify comprehensive font stacks: system CJK fonts first, then fallback Latin fonts"
+  - pitfall: "Full-width vs half-width characters"
+    example: "Full-width 'A' (U+FF21) vs half-width 'A' (U+0041) — both valid but visually different widths"
+    fix: "Normalize input to consistent width forms; use Unicode normalization (NFKC) for search and comparison"
+  - pitfall: "Character count vs visual width"
+    example: "10 CJK characters occupy roughly the same width as 20 Latin characters"
+    fix: "Use visual width measurement (canvas measureText or CSS ch units) instead of string.length for layout"
+  - pitfall: "Honorific levels affecting string length"
+    example: "Polite forms (desu/masu) are longer than casual forms — UI strings vary by politeness level"
+    fix: "Establish consistent politeness level (typically polite/desu-masu for apps) and apply uniformly"

package/dist/agents/skills/shared/i18n-knowledge/locales/ko.yaml

@@ -0,0 +1,38 @@
+locale: "ko"
+name: "Korean"
+native_name: "한국어"
+script: "Hangul"
+direction: ltr
+cldr_plural_categories: [other]
+expansion_factor: 1.0
+script_characteristics:
+  avg_char_width: "wide"
+  requires_complex_shaping: false
+  line_break_rules: "standard"
+  cjk_width_handling: true
+  vertical_text_support: false
+  multiple_scripts: false
+number_format:
+  decimal_separator: "."
+  grouping_separator: ","
+  grouping_size: 3
+date_format:
+  short: "YYYY. MM. DD."
+  long: "YYYY년 MM월 DD일"
+  first_day_of_week: "sunday"
+common_pitfalls:
+  - pitfall: "Korean has spaces between words unlike Japanese and Chinese"
+    example: "Korean uses spaces between words: '한국어 번역' — do not apply CJK no-space rules blindly"
+    fix: "Use standard word-wrap for Korean; it breaks between words unlike Chinese/Japanese character-level breaking"
+  - pitfall: "Honorific speech levels affecting text length"
+    example: "Korean has 7 speech levels — formal polite forms are longer than casual forms"
+    fix: "Standardize on formal polite level (합니다체) for apps and ensure consistent usage across all strings"
+  - pitfall: "Postposition particles attached to words"
+    example: "'파일을' (file + object marker) vs '파일이' (file + subject marker) — particle depends on context"
+    fix: "Include particles in the translatable string; never programmatically append Korean particles"
+  - pitfall: "Hangul syllable block composition"
+    example: "One Hangul syllable is composed of 2-3 jamo but displays as one character block"
+    fix: "Use Unicode NFC normalization for Korean text; decomposed jamo (NFD) render as separate components"
+  - pitfall: "Number grouping with man (10,000) convention"
+    example: "Large numbers sometimes group by 10,000 (만) instead of 1,000 in informal contexts"
+    fix: "Use Intl.NumberFormat('ko') for standard grouping; add 만/억 suffixes only where culturally appropriate"

package/dist/agents/skills/shared/i18n-knowledge/locales/nl.yaml

@@ -0,0 +1,32 @@
+locale: "nl"
+name: "Dutch"
+native_name: "Nederlands"
+script: "Latin"
+direction: ltr
+cldr_plural_categories: [one, other]
+expansion_factor: 1.20
+script_characteristics:
+  avg_char_width: "narrow"
+  requires_complex_shaping: false
+  line_break_rules: "standard"
+number_format:
+  decimal_separator: ","
+  grouping_separator: "."
+  grouping_size: 3
+date_format:
+  short: "DD-MM-YYYY"
+  long: "DD Month YYYY"
+  first_day_of_week: "monday"
+common_pitfalls:
+  - pitfall: "Long compound words similar to German"
+    example: "'arbeidsongeschiktheidsverzekering' (disability insurance) — 35 characters without spaces"
+    fix: "Apply CSS hyphens: auto with lang='nl' and test overflow behavior with real Dutch translations"
+  - pitfall: "Confusing nl-NL and nl-BE (Flemish)"
+    example: "Using 'fiets' vs regional vocabulary differences between Netherlands and Belgium"
+    fix: "Support nl-NL and nl-BE separately when targeting both markets; formatting conventions differ"
+  - pitfall: "IJ digraph capitalization"
+    example: "Capitalizing only the I in 'IJsselmeer' — IJ is a single unit and both letters must capitalize"
+    fix: "When applying text-transform: capitalize, handle the IJ digraph as a special case for Dutch"
+  - pitfall: "Diminutive suffixes in UI labels"
+    example: "Dutch uses diminutives extensively (-je, -tje, -pje) which can change word length unpredictably"
+    fix: "Test with actual translations rather than estimating expansion; diminutives can shorten or lengthen labels"

package/dist/agents/skills/shared/i18n-knowledge/locales/pl.yaml

@@ -0,0 +1,35 @@
+locale: "pl"
+name: "Polish"
+native_name: "Polski"
+script: "Latin"
+direction: ltr
+cldr_plural_categories: [one, few, many, other]
+expansion_factor: 1.30
+script_characteristics:
+  avg_char_width: "narrow"
+  requires_complex_shaping: false
+  line_break_rules: "standard"
+number_format:
+  decimal_separator: ","
+  grouping_separator: "\u00A0"
+  grouping_size: 3
+date_format:
+  short: "DD.MM.YYYY"
+  long: "DD Month YYYY"
+  first_day_of_week: "monday"
+common_pitfalls:
+  - pitfall: "Four plural forms with complex modular rules"
+    example: "1 plik, 2 pliki, 5 plikow, 22 pliki — similar to Russian but with different thresholds"
+    fix: "Use CLDR plural rules: one (1), few (2-4,22-24...), many (5-21,25-31...), other (fractional)"
+  - pitfall: "Special Polish characters in sorting and search"
+    example: "Polish has a, c, e, l, n, o, s, z, z — these sort differently than their base Latin equivalents"
+    fix: "Use Intl.Collator('pl') for sorting; Polish letters with diacritics have specific sort positions"
+  - pitfall: "Text expansion of 20-30%"
+    example: "'Settings' (8 chars) becomes 'Ustawienia' (10 chars); 'Delete' becomes 'Usun' (4 chars, shorter)"
+    fix: "Design for 30% expansion overall; individual strings may expand or contract unpredictably"
+  - pitfall: "Gendered past tense verbs"
+    example: "'You logged in' differs by gender: 'Zalogowales sie' (m) vs 'Zalogowalas sie' (f)"
+    fix: "Avoid past tense constructions in UI or use gender-neutral alternatives when possible"
+  - pitfall: "Consonant clusters in words"
+    example: "Polish has consonant clusters like 'wspolprace' that affect text-to-speech and hyphenation"
+    fix: "Use proper Polish hyphenation dictionaries; do not apply English hyphenation rules to Polish text"

package/dist/agents/skills/shared/i18n-knowledge/locales/pt.yaml

@@ -0,0 +1,32 @@
+locale: "pt"
+name: "Portuguese"
+native_name: "Português"
+script: "Latin"
+direction: ltr
+cldr_plural_categories: [one, other]
+expansion_factor: 1.25
+script_characteristics:
+  avg_char_width: "narrow"
+  requires_complex_shaping: false
+  line_break_rules: "standard"
+number_format:
+  decimal_separator: ","
+  grouping_separator: "."
+  grouping_size: 3
+date_format:
+  short: "DD/MM/YYYY"
+  long: "DD de Month de YYYY"
+  first_day_of_week: "monday"
+common_pitfalls:
+  - pitfall: "Treating pt-BR and pt-PT as identical"
+    example: "Using 'celular' (Brazil) where 'telemovel' (Portugal) is expected, or vice versa"
+    fix: "Support pt-BR and pt-PT as separate locales; vocabulary, spelling, and formatting differ significantly"
+  - pitfall: "Spelling reform inconsistencies"
+    example: "Mixing pre-2009 and post-2009 orthographic agreement spellings in the same interface"
+    fix: "Standardize on post-reform spelling and ensure all translation memory is updated consistently"
+  - pitfall: "Gendered language in user-facing strings"
+    example: "'Bem-vindo' (masculine) vs 'Bem-vinda' (feminine) — greeting depends on user gender"
+    fix: "Use gender-neutral alternatives like 'Boas-vindas' or provide both forms based on user profile"
+  - pitfall: "Brazilian vs European number formatting"
+    example: "pt-BR and pt-PT both use comma for decimal, but currency symbol placement may differ"
+    fix: "Use locale-specific formatting (pt-BR vs pt-PT) rather than generic pt for currency display"