Seven Languages: Why Localization Is a Reliability Feature

Tactic Remote now ships with full support for seven languages: English, Chinese (Simplified), Japanese, Korean, Spanish, German, and French. This isn't a "we ran the strings through a translation API" announcement. Localization in a developer tool that handles network configuration, terminal output, and system-level operations requires a different standard than consumer app translation.

This post covers our technical approach, the bugs that taught us to treat localization as reliability engineering, and what we're seeing from international adoption.

The Seven Languages

Our language selection was driven by user data and request volume during private beta:

We prioritized languages where we had both user demand and access to native-speaking developers who could validate technical accuracy. Developer tool localization requires domain expertise — translating "session" or "tunnel" or "hook" into Japanese requires understanding the term's technical meaning, not just its dictionary definition.

Beyond String Translation

The standard approach to iOS localization is straightforward: extract user-facing strings into .strings or .xcstrings files, provide translations, and let the system handle display. We do this, but the interesting engineering is in the layers below string substitution.

Locale-Aware Input Handling

The bug that changed our localization philosophy: German-locale users couldn't enter IP addresses during setup.

The iOS keyboard in German locale defaults to a comma decimal separator. When a German-locale user taps the "." key area on the numeric keyboard, they get a comma. An IPv4 address like 192.168.1.100 would be entered as 192,168,1,100 — which our validation rejected as malformed.

This wasn't a translation bug. It was a locale behavior bug. The UI strings were correctly translated, but the input mechanism was affected by a keyboard layout assumption. We fixed this by normalizing comma-to-period in IP address input fields and by presenting a custom keyboard configuration intended to show a period key for network address inputs.

This single bug accounted for an estimated 23% of setup failures among German-locale users before the fix. After deployment, German-locale first-run completion rates matched the English baseline within one release cycle.

Pluralization and Grammatical Agreement

String interpolation with counts is a classic localization pitfall. English handles it simply: "1 session" vs. "2 sessions." Other languages have more complex plural rules:

• Japanese and Korean have no grammatical plural — the same form is used regardless of count.
• French pluralizes most nouns at 2+, but some expressions behave differently.
• German compounds can change form based on grammatical case and plurality.

We use iOS's stringsdict plural rules system, which supports the CLDR plural categories (zero, one, two, few, many, other). Every user-facing string that includes a count goes through plural-aware formatting rather than naive string concatenation.

Right-to-Left Preparedness

None of our current seven languages require RTL layout, but our UI architecture accounts for it. All layout constraints use leading/trailing anchors rather than left/right. Text alignment is set to .natural. This means that when we add Arabic or Hebrew support — both languages with active developer communities — the layout work will be minimal.

MDX Content Localization

The Tactic Remote website and documentation are built with MDX. Localizing documentation content required a different strategy than app string localization.

Each MDX document can have locale-specific variants using a filename suffix convention: product-update.mdx (English default), product-update.zh-CN.mdx (Chinese), product-update.ja.mdx (Japanese), and so on. The content router detects the user's preferred language and serves the appropriate variant, falling back to English when a localized version doesn't exist.

This approach has a deliberate tradeoff: we don't translate every documentation page into every language. Technical setup guides and API references remain in English because they contain code samples, command-line instructions, and configuration values that are language-independent. We focus localization effort on content where language barriers actually block comprehension: product announcements, conceptual overviews, and onboarding flows.

Currently, 34% of our MDX content has at least one non-English variant. We prioritize based on page traffic and support ticket correlation — if a page generates support questions disproportionately from a specific language group, that page gets localized next.

The Reliability Argument

We treat localization as a reliability feature for a specific reason: a developer who cannot complete setup due to a locale-related input bug is in the same state as a developer who cannot connect due to a network error. The product is broken for them. The root cause being "we assumed an English keyboard layout" rather than "we have a TCP bug" doesn't change the user's experience.

This framing has practical consequences for our engineering process:

Locale-specific test matrix. Our CI runs critical path tests (setup flow, connection establishment, approval flow) under six non-English locale configurations. A regression in German-locale IP input would be caught before merge.

Localization bugs get severity-1 triage when they block core functionality. A mistranslated label is cosmetic. A locale-dependent input failure is a production incident.

String freeze before release. We freeze English strings 72 hours before each release, giving translators a stable target. Translations are validated by native-speaking developers on the team, not just linguists.

International Adoption

Since launching multi-language support, we've seen measurable shifts in our user base:

• Non-English locale users grew from 18% to 41% of weekly active users over six weeks.
• Chinese (Simplified) users are now the second-largest language group, representing 15% of weekly actives.
• Japanese users have the highest average session duration across all language groups — 52 minutes vs. 47 minutes overall.
• Setup completion rate across all locales is now within 2 percentage points of the English baseline. Before localization work, some locales had completion rates 15-20% lower than English.

The setup completion rate convergence is the metric we care about most. It validates that localization is closing reliability gaps, not just adding translated labels.

What's Next

We're expanding language support based on the same criteria: user demand plus access to native-speaking technical reviewers.

• Additional languages are being evaluated based on user demand and availability of native-speaking technical reviewers.
• We're building a community contribution workflow for translations, with a review process that ensures technical accuracy before merge.

For details on how language detection and fallback work, see Localization Architecture. If you'd like to contribute translations for an unsupported language, reach out through the Support page.