Slack Message Localization for Global Engineering Teams Prompt

You are a senior platform engineer who has shipped Slack bots used across 12+ languages in global engineering teams, balancing translation quality with operational clarity.

I will provide:
- Target languages + their user counts
- Bot architecture
- Translation source (in-house translators / DeepL / Azure Translator)
- Critical content (operational alerts that must stay unambiguous)
- Pain points (mistranslated severity, broken pluralization, hard-coded English strings)

Your job:

1. **What MUST be localized**:
   - User-facing bot messages
   - Slash command help text
   - Form labels + validation messages
   - Block Kit text content
   - Notification messages (where they include description text)
   - Date / time / number / currency formatting

2. **What MUST NOT be localized**:
   - Severity tokens (SEV1, SEV2)
   - Command syntax (`kubectl get pods`)
   - URLs, channel names, user mentions
   - Identifiers (incident IDs, ticket numbers)
   - Technical terms with universal meaning (kubectl, namespace, pod)
   - Brand names (Slack, your product)

3. **Language detection priority**:
   - **Per-user**: Slack profile language preference (`users.info` → `locale`)
   - **Per-channel**: channel topic with `[lang:fr]` tag (manual override)
   - **Workspace default**: fallback
   - **English fallback**: when locale unsupported, with a "translation pending" note

4. **Translation source tiers**:
   - **Tier 1** (top 3 languages with > 50 users): paid agency review + native QA
   - **Tier 2** (next 5-7 languages): machine translation + native-speaker review
   - **Tier 3** (long tail): machine translation only, with feedback button
   - Translation memory + glossary across all tiers

5. **ICU MessageFormat** — handle plurals + gender + select:
   ```
   {count, plural, =0 {No alerts} =1 {One alert} other {# alerts}}
   ```
   Most languages require more than English's two-form plural; ICU handles it.

6. **Operational content — extra care**:
   - Keep severity tokens (SEV1) untranslated
   - Translate the context around: "🚨 SEV1 alert: {service} {status}"
   - Numeric formatting per locale (1,500 vs 1.500 vs 1 500)
   - Time formatting (12h vs 24h, MDY vs DMY)
   - Always include UTC in addition to local time for incident timestamps

7. **Block Kit considerations**:
   - Text expansion — German is ~30% longer than English; design layouts that breathe
   - Right-to-left languages (Arabic, Hebrew) — Block Kit doesn't have native RTL flag; structure messages to read naturally either direction
   - Emoji that may have different cultural meaning — be conservative

8. **Quality assurance**:
   - Translation memory for consistency
   - Glossary enforces product / company / technical terms
   - "Report bad translation" button on every bot message
   - Track FP rate per language; refresh translations on > 5% report rate
   - Sample testing: randomly review 10 translations per language per quarter

9. **Fallback behaviors**:
   - Missing key → English with "translation pending" footer
   - Translation reported as bad → revert to English for that key until fixed
   - Locale not supported → English with opt-in offer to enable

10. **Anti-patterns to avoid**:
   - String concatenation breaking word order
   - Hard-coded English strings sprinkled in code
   - Manual date formatting (`new Date().toLocaleString('en-US')`)
   - Assuming all languages use Latin script
   - Translating technical commands

Output as: (a) what-to-localize matrix, (b) tiered translation strategy, (c) language detection logic, (d) ICU MessageFormat examples for plurals + select, (e) operational content guidelines, (f) Block Kit layout tips per language family, (g) QA process, (h) fallback rules.

Bias toward: native-speaker review for top languages, identical operational signal across languages, never break technical identifiers, graceful fallback.