@harness-engineering/cli 1.6.2 → 1.8.0

package/dist/agents/skills/shared/i18n-knowledge/frameworks/react-intl.yaml

@@ -0,0 +1,47 @@
+name: "React Intl (FormatJS)"
+description: "ICU MessageFormat-based i18n library for React, part of the FormatJS ecosystem"
+platforms: ["web"]
+message_format: "icu"
+
+detection:
+  package_json_keys:
+    dependencies: ["react-intl", "@formatjs/intl", "@formatjs/intl-messageformat"]
+    devDependencies: ["@formatjs/cli", "eslint-plugin-formatjs", "@formatjs/ts-transformer"]
+  file_patterns: ["src/**/*.{ts,tsx,js,jsx}"]
+  config_files: [".formatjsrc", ".formatjsrc.json"]
+
+conventions:
+  key_format: "dot-notation"
+  file_format: "json"
+  file_structure: "lang/{locale}.json"
+  plural_syntax: "ICU {count, plural, one {# item} other {# items}}"
+  interpolation_syntax: "{variable}"
+
+recommended_tooling:
+  extraction: ["@formatjs/cli extract"]
+  linting: ["eslint-plugin-formatjs"]
+  pseudo_locale: ["@formatjs/cli compile --pseudo-locale"]
+
+anti_patterns:
+  - pattern: "String concatenation inside FormattedMessage"
+    severity: error
+    instead: "Use ICU MessageFormat with placeholders: <FormattedMessage id='greeting' values={{name}} />"
+  - pattern: "Using defaultMessage as the translation key"
+    severity: warning
+    instead: "Use explicit message IDs (dot-notation) for stable keys; defaultMessage is a fallback, not an ID"
+  - pattern: "Inline messages without extraction"
+    severity: warning
+    instead: "Run @formatjs/cli extract to generate message catalogs; do not manually maintain translation files"
+  - pattern: "Using dangerouslySetInnerHTML with translated strings"
+    severity: error
+    instead: "Use FormattedMessage rich text support: <FormattedMessage values={{b: chunks => <b>{chunks}</b>}} />"
+  - pattern: "Not wrapping date/number formatting with FormatJS APIs"
+    severity: warning
+    instead: "Use intl.formatDate(), intl.formatNumber(), and intl.formatRelativeTime() for locale-aware formatting"
+
+migration_notes:
+  from:
+    - framework: "i18next"
+      guidance: "Convert {{variable}} interpolation to {variable}; convert i18next plural suffixes (_one, _other) to ICU plural syntax; update extraction pipeline from i18next-parser to @formatjs/cli"
+    - framework: "vue-i18n"
+      guidance: "Convert $t() calls to useIntl().formatMessage(); convert named interpolation to ICU syntax; move from SFC i18n blocks to centralized message files"

package/dist/agents/skills/shared/i18n-knowledge/frameworks/vue-i18n.yaml

@@ -0,0 +1,47 @@
+name: "Vue I18n"
+description: "Internationalization plugin for Vue.js with SFC support and composition API integration"
+platforms: ["web"]
+message_format: "icu"
+
+detection:
+  package_json_keys:
+    dependencies: ["vue-i18n", "@intlify/vue-i18n-extensions", "@intlify/unplugin-vue-i18n"]
+    devDependencies: ["@intlify/vite-plugin-vue-i18n", "@intlify/eslint-plugin-vue-i18n"]
+  file_patterns: ["src/**/*.vue", "src/locales/**/*.{json,yaml}"]
+  config_files: ["vue-i18n.config.ts", "i18n.ts"]
+
+conventions:
+  key_format: "dot-notation"
+  file_format: "json"
+  file_structure: "src/locales/{locale}.json"
+  plural_syntax: "ICU {count, plural, one {# item} other {# items}} or pipe syntax: item | items"
+  interpolation_syntax: "{variable} or @:key for linked messages"
+
+recommended_tooling:
+  extraction: ["@intlify/cli"]
+  linting: ["@intlify/eslint-plugin-vue-i18n"]
+  pseudo_locale: ["custom generator with vue-i18n message compiler"]
+
+anti_patterns:
+  - pattern: "Using v-html with translated strings"
+    severity: error
+    instead: "Use the <i18n-t> component with named slots for HTML in translations — v-html creates XSS risk"
+  - pattern: "Hardcoding messages in template attributes"
+    severity: warning
+    instead: "Use $t() in attribute bindings: :placeholder=\"$t('search.placeholder')\" instead of hardcoded strings"
+  - pattern: "Not using SFC <i18n> blocks for component-local messages"
+    severity: info
+    instead: "Put component-specific messages in <i18n> blocks to co-locate translations with the component"
+  - pattern: "Ignoring SSR hydration mismatch with locale detection"
+    severity: error
+    instead: "Detect locale server-side (Accept-Language header) and pass to client to prevent hydration mismatch"
+  - pattern: "Using legacy API ($t) in Composition API components"
+    severity: warning
+    instead: "Use useI18n() composable in <script setup> components for type-safe translation access"
+
+migration_notes:
+  from:
+    - framework: "vue-i18n v8 (Vue 2)"
+      guidance: "Migrate from VueI18n class to createI18n(); update $t() to useI18n().t() in Composition API; convert <i18n> blocks to new format"
+    - framework: "i18next"
+      guidance: "Convert {{variable}} to {variable}; map namespaces to vue-i18n scoped messages; replace useTranslation() with useI18n()"

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

@@ -0,0 +1,66 @@
+name: "Ecommerce"
+description: "i18n challenges in ecommerce — address formats, measurement units, tax display, and payment localization across markets"
+
+requirements:
+  - area: "Address Format"
+    description: "Address field order and content varies dramatically by country — Japan puts postal code first, US puts it last"
+    severity: error
+    locales_affected: "all"
+    examples:
+      - bad: "Fixed form: Street, City, State, Zip, Country"
+        good: "Use Google's libaddressinput or similar to render country-specific address forms"
+  - area: "Measurement Units"
+    description: "Product dimensions, weight, and volume must display in locale-expected units"
+    severity: warning
+    locales_affected: "all"
+    examples:
+      - bad: "Showing all dimensions in inches regardless of locale"
+        good: "Display metric units (cm, kg, L) for most locales; imperial (in, lb, fl oz) for US/UK where expected"
+  - area: "Tax Display"
+    description: "VAT-inclusive (most of world) vs tax-exclusive (US) pricing causes confusion if not handled per locale"
+    severity: error
+    locales_affected: "all"
+    examples:
+      - bad: "Showing $99.99 without indicating whether tax is included"
+        good: "Show 'incl. VAT' for EU locales, separate tax line for US locales, GST-inclusive for AU/NZ"
+  - area: "Phone Number Formatting"
+    description: "Phone number input and display must support international formats"
+    severity: warning
+    locales_affected: "all"
+    examples:
+      - bad: "Validating phone with regex: /^\\d{10}$/"
+        good: "Use libphonenumber for validation and formatting; store in E.164 format (+1234567890)"
+  - area: "Sizing Charts"
+    description: "Clothing and shoe sizes vary by country — US 8 is EU 38 for women's shoes"
+    severity: warning
+    locales_affected: "all"
+    examples:
+      - bad: "Showing only US sizes for international customers"
+        good: "Display size conversion charts; show locale-primary sizing with equivalents"
+
+anti_patterns:
+  - pattern: "Hardcoding address field order"
+    reason: "Japan: postal-code, prefecture, city, street; Germany: street, postal-code city; varied worldwide"
+    instead: "Use a country-aware address component that adapts field order per shipping country"
+  - pattern: "Validating postal codes with a single regex"
+    reason: "Postal code formats range from 5 digits (US) to alphanumeric (UK: SW1A 1AA) to none (Ireland historically)"
+    instead: "Use country-specific postal code validation or a library like i18n-postal-code"
+  - pattern: "Displaying prices without currency context"
+    reason: "$99 is ambiguous — USD, CAD, AUD, and others use $; customer may see wrong currency"
+    instead: "Always show the currency code or unambiguous symbol; use Intl.NumberFormat with currency"
+  - pattern: "Shipping method names not localized"
+    reason: "'2-Day Shipping' is meaningless outside the origin country's postal system"
+    instead: "Show estimated delivery date instead of carrier-specific service names"
+
+regulations:
+  - name: "EU Consumer Rights Directive"
+    locales: ["EU member states"]
+    impact: "Prices must be displayed inclusive of VAT in the currency of the target market"
+  - name: "GDPR"
+    locales: ["EU member states"]
+    impact: "Privacy policy and consent language must be in the user's language and legally accurate per jurisdiction"
+  - name: "California Consumer Privacy Act (CCPA)"
+    locales: ["en-US"]
+    impact: "Privacy notices must be accessible; consider multilingual California population"
+
+reference_products: ["shopify.com", "amazon.com", "etsy.com", "zalando.com"]

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

@@ -0,0 +1,66 @@
+name: "Fintech"
+description: "i18n challenges in financial technology — currency precision, number formatting, and regulatory compliance across markets"
+
+requirements:
+  - area: "Currency Display"
+    description: "Currency formatting varies by locale — symbol position, decimal precision, and grouping separators differ"
+    severity: error
+    locales_affected: "all"
+    examples:
+      - bad: "'$' + amount.toFixed(2)"
+        good: "new Intl.NumberFormat(locale, { style: 'currency', currency: currencyCode }).format(amount)"
+  - area: "Currency Precision"
+    description: "Decimal places vary by currency — JPY has 0, USD/EUR have 2, BHD/KWD have 3"
+    severity: error
+    locales_affected: "all"
+    examples:
+      - bad: "amount.toFixed(2) for all currencies"
+        good: "Use Intl.NumberFormat with currency option which auto-selects correct decimal places"
+  - area: "Number Formatting"
+    description: "Thousands separators and decimal points vary — 1,234.56 (en) vs 1.234,56 (de) vs 1 234,56 (fr)"
+    severity: error
+    locales_affected: "all"
+    examples:
+      - bad: "amount.toString().replace(/\\B(?=(\\d{3})+(?!\\d))/g, ',')"
+        good: "new Intl.NumberFormat(locale).format(amount)"
+  - area: "Regulatory Date Formats"
+    description: "Financial regulations often mandate specific date formats — ambiguous dates (01/02/2025) cause compliance issues"
+    severity: error
+    locales_affected: "all"
+    examples:
+      - bad: "01/02/2025 (is this Jan 2 or Feb 1?)"
+        good: "Use unambiguous formats (2025-01-02) for regulatory documents; locale-specific for user display"
+  - area: "Financial Amount Display"
+    description: "Negative amounts, accounting notation, and color coding must follow locale conventions"
+    severity: warning
+    locales_affected: "all"
+    examples:
+      - bad: "Showing -$1,234.56 in all locales"
+        good: "Use Intl.NumberFormat with signDisplay and currencySign: 'accounting' for locale-correct negative display"
+
+anti_patterns:
+  - pattern: "Hardcoding currency symbol position"
+    reason: "Symbol placement varies: $100 (en-US), 100$ (fr-CA), 100 $ (fr-FR)"
+    instead: "Use Intl.NumberFormat with currency style which handles symbol placement per locale"
+  - pattern: "Converting currencies with hardcoded exchange rates"
+    reason: "Exchange rates change constantly; stale rates in code cause incorrect financial displays"
+    instead: "Fetch exchange rates from a reliable API; cache with appropriate TTL"
+  - pattern: "Using floating point for financial calculations"
+    reason: "IEEE 754 floating point causes rounding errors: 0.1 + 0.2 !== 0.3"
+    instead: "Use integer arithmetic in smallest currency unit (cents) or a decimal library"
+  - pattern: "Displaying amounts without locale-specific accounting format"
+    reason: "Negative amounts display differently: -$100 (US), ($100) (accounting), -100$ (other locales)"
+    instead: "Use Intl.NumberFormat with currencySign: 'accounting' for financial contexts"
+
+regulations:
+  - name: "PSD2 (Payment Services Directive 2)"
+    locales: ["EU member states"]
+    impact: "Transaction amounts must be displayed in the customer's local currency with correct formatting"
+  - name: "MiFID II"
+    locales: ["EU member states"]
+    impact: "Financial documents must show costs in the client's preferred currency with mandated precision"
+  - name: "RBI Guidelines"
+    locales: ["hi", "en-IN"]
+    impact: "Indian Rupee amounts must use Indian number grouping (lakhs/crores) in customer-facing displays"
+
+reference_products: ["wise.com", "stripe.com", "revolut.com", "mercury.com"]

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

@@ -0,0 +1,69 @@
+name: "Gaming"
+description: "i18n challenges in gaming — character limits in UI, cultural adaptation, rating systems, and in-game text rendering"
+
+requirements:
+  - area: "Character Limits in HUD/UI"
+    description: "Game HUDs and menus have fixed-width pixel budgets — translated text must fit without overflow"
+    severity: error
+    locales_affected: "all"
+    examples:
+      - bad: "Fixed 120px button with English text 'Attack' that becomes 'Angreifen' (German, does not fit)"
+        good: "Design UI with flexible text containers or set per-locale character limits with translator guidance"
+  - area: "Cultural Adaptation"
+    description: "Colors, gestures, symbols, and themes have different meanings across cultures"
+    severity: warning
+    locales_affected: "all"
+    examples:
+      - bad: "Using white for death/mourning themes globally (white = mourning in East Asia, black in Western cultures)"
+        good: "Audit cultural symbols and adapt color meanings, gestures, and imagery per target market"
+  - area: "Rating Systems"
+    description: "Age ratings differ by region — ESRB (US), PEGI (EU), CERO (JP), USK (DE) have different criteria"
+    severity: error
+    locales_affected: "all"
+    examples:
+      - bad: "Showing ESRB rating to European players"
+        good: "Display the correct regional rating system with proper locale-specific rating icons and descriptions"
+  - area: "In-Game Text Rendering"
+    description: "Bitmap fonts may not support all scripts; dynamic text needs proper shaping for CJK, Arabic, Devanagari"
+    severity: error
+    locales_affected: ["ja", "zh-Hans", "zh-Hant", "ko", "ar", "he", "hi", "th"]
+    examples:
+      - bad: "Using a bitmap font that only contains Latin glyphs for all locales"
+        good: "Use Unicode-capable font rendering or locale-specific bitmap fonts with full glyph coverage"
+  - area: "Voiceover and Subtitle Synchronization"
+    description: "Dubbed audio and subtitles must match game timing — translated dialogue may be longer or shorter"
+    severity: warning
+    locales_affected: "all"
+    examples:
+      - bad: "Subtitles that flash too quickly because translated text is longer than English source"
+        good: "Adjust subtitle display timing based on translated text length; allow subtitle speed settings"
+
+anti_patterns:
+  - pattern: "Hardcoding text in texture/sprite assets"
+    reason: "Text baked into images cannot be translated without re-creating the entire asset per locale"
+    instead: "Render text dynamically over images; use text layers separate from background art"
+  - pattern: "Concatenating strings for item descriptions"
+    reason: "'Legendary' + 'Sword' + 'of Fire' — word order changes by language, adjective placement varies"
+    instead: "Use complete translatable strings: '{quality} {weapon} {element}' with locale-aware ordering"
+  - pattern: "Assuming left-to-right menu navigation for all locales"
+    reason: "Arabic and Hebrew players expect RTL menu flow and mirrored UI layouts"
+    instead: "Mirror the full game UI for RTL locales including menus, HUD, and inventory screens"
+  - pattern: "Using player-facing dates without locale formatting"
+    reason: "Event dates like '12/1' are ambiguous — December 1 or January 12 depending on locale"
+    instead: "Use locale-aware date formatting or unambiguous formats with month names for in-game events"
+  - pattern: "Embedding culturally specific humor or idioms"
+    reason: "Jokes and idioms rarely translate directly — they fall flat or cause offense in other cultures"
+    instead: "Flag humor/idioms for cultural adaptation (not just translation) in localization notes"
+
+regulations:
+  - name: "ESRB (Entertainment Software Rating Board)"
+    locales: ["en-US", "en-CA"]
+    impact: "Content descriptors and rating labels must be in English; may require Spanish for US market"
+  - name: "PEGI (Pan European Game Information)"
+    locales: ["EU member states"]
+    impact: "Rating icons and content descriptors must follow PEGI standards; some content prohibited in certain countries"
+  - name: "CERO (Computer Entertainment Rating Organization)"
+    locales: ["ja"]
+    impact: "Japanese rating system with different thresholds; some content requires modification for Japan market"
+
+reference_products: ["store.steampowered.com", "playstation.com", "xbox.com", "nintendo.com"]

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"