Multilingual PMO Automation: Architecture-First i18n Strategy

TL;DR

• Language localization requires architectural refactoring, not simple string replacement
• Decouple business logic from language values by using semantic codes in the data layer
• Externalize all text resources to language files, eliminating hardcoded strings in scripts
• Incremental migration with environment isolation prevents production disruptions
• Status migration example uses status_mapping.yaml to map Chinese codes to English keys

Body

When our PMO automation system needed to support English teams, we quickly learned that localization is not a frontend problem. The system was built entirely in Chinese—from 47 database tables to 23 Python scripts containing hardcoded conditional logic, plus n8n workflows with embedded Chinese copy. Over 300 independent items required changes. More critically, scripts made business decisions based on Chinese string values like if status == "待审批", creating tight coupling between language and logic.

The core issue is that language was not just presentation—it was the system itself. Scripts used Chinese values for status checks, database fields stored Chinese state representations, and workflows relied on Chinese text for routing decisions. Simply swapping Chinese for English would break Chinese users entirely, making true bilingual coexistence impossible with the original architecture.

The solution was a three-layer decoupling approach. First, we migrated the data layer to semantic codes: status_mapping.yaml defined mappings like “待审批” → “pending”, and a migration script updated all 47 tables. After migration, business code never references language strings. Second, we externalized all script text to language resource files—msg_templates/en.yaml and msg_templates/zh.yaml contain templates that scripts load dynamically based on user language preference. The send_reminder.py function now calls get_user_lang(project_id) to determine which template file to load, ensuring the same function handles both languages without conditional logic.

This approach enables incremental deployment: test environments validate the new architecture while production continues operating, and language switching becomes a configuration change rather than a code deployment.

Key Takeaways

If you are migrating legacy systems to multilingual support, begin by replacing all language-based conditional logic with semantic codes in your database layer.

If you have scripts that send user-facing messages, externalize those messages to language resource files and load them dynamically based on user preference.

If you are planning a bilingual rollout, use environment isolation and staged migration to validate changes in test before affecting production users.

If you want to avoid future i18n debt, establish a strict rule that business logic must never contain hardcoded language strings.

If you inherit a system with language-value dependencies, create a mapping file like status_mapping.yaml before attempting any replacement to ensure a clean, reversible migration path.

Read the Full Article (Chinese)

This is an abstract. The full technical walkthrough with code examples, n8n workflow modifications, and step-by-step migration procedures is available in Chinese.