Take Your App Multilingual (No Rewrite)

Source: Dev.to

Find the Middle Ground

There’s a pragmatic middle ground between “English only” and “fully localized in 40 languages.” Most teams never find it because the discussion jumps straight from “we need Spanish” to “okay, let’s implement i18n across the entire codebase.” That’s a months‑long project. There are faster ways to start.

Start with User‑Facing Content

Focus on the parts of your application where language actually matters to the user experience:

• Product descriptions
• Help articles
• Email notifications
• Error messages
• Onboarding flows

These are the places where a non‑English speaker hits a wall. They might tolerate an English navigation bar—button labels are often recognizable across languages—but a help article that explains a critical feature or an error message that tells them what went wrong must be in their language.

Translating content is a much smaller, more contained project than internationalizing an entire UI framework, and it delivers most of the user value.

Machine Translation vs. Human Translation

The Evolution of MT

Five years ago, machine translation (MT) was a punchline. Google Translate could turn a French restaurant menu into surrealist poetry, and professional human translators were the only serious option.

That’s changed. Modern MT handles most European and major Asian languages well. It’s not perfect—it struggles with idioms, cultural references, and highly technical jargon—but for straightforward content (product descriptions, support articles, transactional emails) the quality is genuinely usable.

When MT Works (and When It Doesn’t)

• First category: MT gets you 80‑90 % of the way there.
• Second category: You still need human translators—but that’s a much smaller volume of content.

Detecting the Right Language

Before you translate anything, you need to know what language your users actually want. Guessing wrong is worse than not translating at all. Several signals can help:

1. Browser language headers – the most reliable automatic signal. Every HTTP request includes an Accept-Language header that lists the user’s preferred languages.
   Example: es-MX,es;q=0.9,en;q=0.8 → Mexican Spanish > General Spanish > English.

2. Account settings – the gold standard. Users explicitly choose a language in their profile. Works only for logged‑in users who have configured their settings.

3. Content language detection – useful for user‑generated input (support tickets, form submissions). Detect the language of the submitted text and respond in kind.

4. Geographic signals – a rough proxy (e.g., a user in Japan probably prefers Japanese). This fails for expatriates, travelers, and multilingual countries (Switzerland, India). Use it only as a default that users can override.

Pragmatic layering

• Primary: Account settings (if available)
• Secondary: Browser Accept-Language header
• Tertiary: Detect language of user‑generated content

Prioritizing What to Translate

You can’t translate everything at once. Here’s a practical priority list:

1. Onboarding flows – Highest priority. If a user can’t understand the signup process, they’ll never become a user.
2. Transactional emails – Order confirmations, password resets, billing notifications. Users need to understand these to use your service.
3. Error messages – A payment‑failure error in English is useless to a Spanish‑speaking user. Translating errors reduces support tickets dramatically.
4. Help documentation & support articles – Enables self‑service and scales better than hiring multilingual support staff.
5. Marketing pages – Last in priority but first in visibility. Prospects who don’t read English likely found you via localized search results, so localized landing pages are essential.

Translating Content Programmatically

// Example: calling a translation API
const response = await fetch('https://api.apiverve.com/v1/translator', {
  method: 'POST',
  headers: {
    'x-api-key': 'YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    text: 'Your payment was processed successfully.',
    target: 'es'               // target language code
    // source: 'en'            // optional; omitted → auto‑detect
  })
});

const { data } = await response.json();
// data.translatedText → "Su pago fue procesado exitosamente."
// data.sourceLang    → "en"

• Note: The source parameter is optional. When omitted, the API auto‑detects the source language, which is handy for processing user‑generated content where you don’t know the original language.

Where Do Translated Strings Live?

This depends on your architecture. Common patterns include:

• Separate JSON/YAML files per locale (e.g., en.json, es.json).
• Database tables for dynamic content (product descriptions, help articles).
• CMS‑driven localization where editors manage translations directly in the content management system.

Choose the approach that aligns with how you store and serve your content.

Internationalization Strategies

Where to Store Translations

• Database – If your product descriptions are in a database, add a locale column and store translated versions as separate rows.
  Same content ID, different locale.

• Translation files – Works for UI strings. JSON files keyed by locale (en.json, es.json, fr.json) are the standard i18n approach. Most frontend frameworks have built‑in support for this pattern.

  // en.json
  {
    "welcome": "Welcome",
    "login": "Log in"
  }
  
  // es.json
  {
    "welcome": "Bienvenido",
    "login": "Iniciar sesión"
  }

• Generated on the fly – Good for content that changes frequently or where the translation doesn’t need to be perfect.
  Example: Real‑time translation of support‑chat messages. The user sees the translation immediately, even if it isn’t hand‑polished.

• Cached after first translation – Balances cost and freshness. Translate the content the first time it’s requested in a given language, cache the result, and serve from cache thereafter. This limits API calls while keeping translations available.

The right approach often combines these methods:

• Static UI strings in translation files.
• Database content with locale columns.
• Real‑time translation for chat and user‑generated content.

Choosing Which Languages to Add First

Choosing languages is a business decision, not a purely technical one.

1. Check your analytics – Where are your existing users?

   • If 15 % of traffic comes from Spanish‑speaking countries, Spanish is the obvious first language.
   • If you have growing traffic from Brazil, Portuguese should be high on the list.

2. Consider your market strategy – Expanding into a specific region? Translate for that region’s languages before you launch there, not after.

3. Think about language reach –

   • Spanish – 20 + countries.
   • French – Europe, Africa, the Americas.
   • Mandarin – World’s largest population.
   • Arabic – Wide geographic band.

   These high‑reach languages provide the most return per translation investment.

4. Language similarity – If you’ve already translated to Spanish, Portuguese is a smaller incremental effort—the languages share significant vocabulary and structure. This is one of those rare cases where the second step is genuinely easier than the first.

Improving Translation Quality Over Time

• Machine translation is a starting point, not a final state. Over time, improve translations using feedback.

• User‑generated corrections – Add a small “Suggest better translation” link so bilingual users can contribute. Crowdsourced corrections improve quality organically.

• Human review of high‑traffic pages – Your homepage, pricing page, and checkout flow deserve professional translation. The cost is modest and the impact on conversion is measurable.

• Support‑ticket analysis – Track tickets by language. If Spanish‑speaking users consistently contact support about a specific feature, the translated documentation for that feature probably needs work.

• Accept that translation quality is a spectrum – Shipping an 80 % translation today beats shipping a perfect one six months from now. The users you’d lose in those six months aren’t coming back.

Practical API Usage

• Translate content – Use the Translation API.
• Detect source language – Use the Language Detection API.

These services let you reach a global audience without starting from scratch.

Originally published at APIVerve Blog.