1<!DOCTYPE html> 2 <html lang="en"> 3 <head> 4 <link rel="stylesheet" type="text/css" href="/assets/static/pages_Layout-69d9ce51.BFXRn4rv.css"> 5 <link rel="stylesheet" type="text/css" href="/assets/static/css_font-530a5bb1.cDx1WW9I.css"> 6 <link rel="stylesheet" type="text/css" href="/assets/static/css_tailwind-8f883db8.BChjo3lx.css"> 7 <link rel="stylesheet" type="text/css" href="/assets/static/css_cookie-consent-859f3a0a.BQdK2uVt.css"> 8 <link rel="stylesheet" type="text/css" href="/assets/static/components_Code-3e34ba09.Cy0A5ozX.css"> 9 <link rel="stylesheet" type="text/css" href="/assets/static/components_ImageModal-d039a1a5.BdCCvhgx.css"> 10 <link rel="stylesheet" type="text/css" href="/assets/static/vanilla-cookieconsent-cb8de7a4.8y7aXeKw.css"> 11 <link rel="stylesheet" type="text/css" href="/assets/static/components_CustomerLogoMarquee-159ffaa2.ChPZWWJT.css"> 12 <meta charset="UTF-8" /> 13 14 15 <title>Blog - Locize</title><meta property="og:title" content="Blog - Locize" /> 16 <meta name="viewport" content="width=device-width,initial-scale=1"> 17 <link rel="icon" href="/img/favicon.ico"/><meta property="og:site_name" content="Locize"/><meta property="og:image" content="https://www.locize.com/img/blog/blog-default.png"/><meta property="og:locale" content="en_US"/><meta property="og:url" content="https://www.locize.com/blog"/><meta name="twitter:site" content="@locize"/><meta name="twitter:description" content="i18next tutorials, localization guides, product updates, and engineering insights from the team behind Locize and i18next."/><link rel="canonical" href="https://www.locize.com/blog"/><link rel="alternate" hrefLang="en" href="https://www.locize.com/blog"/><link rel="alternate" hrefLang="de" href="https://www.locize.com/de/blog"/><link rel="alternate" hrefLang="it" href="https://www.locize.com/it/blog"/><link rel="alternate" hrefLang="fr" href="https://www.locize.com/fr/blog"/><link rel="alternate" hrefLang="x-default" href="https://www.locize.com/blog"/><link rel="manifest" href="/manifest.json"/><link rel="shortcut icon" href="/img/favicon.ico"/><meta name="author" content="inweso Ltd liab. Co"/><meta name="language" content="en"/><meta name="revisit-after" content="7 days"/><meta name="format-detection" content="telephone=no"/><meta name="mobile-web-app-capable" content="yes"/><meta name="apple-mobile-web-app-capable" content="yes"/><meta name="apple-mobile-web-app-status-bar-style" content="default"/><meta name="slack-app-id" content="A71NM84Q6"/><meta name="keywords" content="locize blog, i18n, l10n, tutorials, insights, web development, localization management"/><meta property="og:type" content="website"/><meta property="og:url" content="https://www.locize.com/blog"/><meta name="twitter:card" content="summary_large_image"/><meta name="twitter:title" content="Blog - Locize"/><meta name="twitter:description" content="i18next tutorials, localization guides, product updates, and engineering insights from the team behind Locize and i18next."/><meta name="twitter:image" content="https://www.locize.com/img/blog/blog-default.png"/>
17<script type="application/ld+json">{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://www.locize.com/#organization","name":"Locize","legalName":"inweso GmbH","url":"https://www.locize.com","description":"Swiss company behind Locize, the translation management system built by the creators of i18next.","logo":{"@type":"ImageObject","@id":"https://www.locize.com/#logo","url":"https://www.locize.com/img/logo512.png","contentUrl":"https://www.locize.com/img/logo512.png","width":192,"height":192,"caption":"Locize"},"image":{"@id":"https://www.locize.com/#logo"},"email":"[email protected]","address":{"@type":"PostalAddress","addressCountry":"CH"},"contactPoint":{"@type":"ContactPoint","contactType":"customer support","email":"[email protected]","availableLanguage":["en","de"]},"sameAs":["https://x.com/locize","https://github.com/locize","https://www.youtube.com/channel/UCPYQjBbbXojUcB8qjeIB3uA","https://www.facebook.com/locize","https://www.instagram.com/i18next_locize/"]},{"@type":"WebSite","@id":"https://www.locize.com/#website","name":"Locize","url":"https://www.locize.com","description":"Continuous localization and translation management for software teams.","publisher":{"@id":"https://www.locize.com/#organization"},"inLanguage":["en","de","it","fr"]},{"@type":"TechArticle","@id":"https://www.locize.com/blog#page","headline":"Blog - Locize","description":"i18next tutorials, localization guides, product updates, and engineering insights from the team behind Locize and i18next.","url":"https://www.locize.com/blog","inLanguage":"en","isPartOf":{"@id":"https://www.locize.com/#website"},"publisher":{"@id":"https://www.locize.com/#organization"}}]}</script>
17<script> 18 window.dataLayer = window.dataLayer || []; 19 window.gtag = function() { 20 window.dataLayer.push(arguments); 21 } 22 window.gtag('consent', 'default', { 23 analytics_storage: 'denied', 24 ad_user_data: 'denied', 25 ad_personalization: 'denied', 26 ad_storage: 'denied', 27 wait_for_update: 500 28 }); 29 </script>
29 30 31 <meta name="description" content="i18next tutorials, localization guides, product updates, and engineering insights from the team behind Locize and i18next." /><meta property="og:description" content="i18next tutorials, localization guides, product updates, and engineering insights from the team behind Locize and i18next." /> 32 33 34 35 </head> 36 <body> 37 38 <div id="root"><link rel="preload" as="image" href="/img/locize_color.svg"/><link rel="preload" as="image" href="/img/locize_white.svg"/><div data-theme="light" class="min-h-screen text-base-content flex flex-col relative overflow-x-hidden bg-soft-brand-gradient"><a href="#page-content" class="sr-only focus:not-sr-only focus:absolute focus:z-[9999] focus:bg-primary focus:text-white focus:px-4 focus:py-2 focus:top-2 focus:left-2 focus:rounded">Skip to content</a><header class="sticky top-0 z-50 brand-header"><div class="max-w-[90rem] mx-auto px-4"><div class="navbar px-0 min-h-[3.75rem]"><div class="navbar-start"><a href="/" class="inline-flex items-center gap-3 no-underline"><img src="/img/locize_color.svg" alt="Locize" class="h-7 w-auto"/></a></div><div class="navbar-center hidden md:flex"><nav class="flex items-center gap-7 text-sm font-medium" aria-label="Primary"><a class="brand-nav-link" href="/how-it-works">How it works</a><a class="brand-nav-link" href="/for-your-team">For your team</a><a class="brand-nav-link" href="/pricing">Pricing</a><a class="brand-nav-link" href="/customers">Customers</a><a class="brand-nav-link" href="/services">Services</a><a class="brand-nav-link" href="/ai">AI</a><a class="brand-nav-link" href="/docs/introduction">Docs</a><a class="brand-nav-link" href="/blog">Blog</a></nav></div><div class="navbar-end gap-2"><a class="brand-btn-outline btn-sm no-underline" href="https://www.locize.app/login?from=header" rel="noopener noreferrer" target="_blank">Login</a><a class="brand-btn btn-sm no-underline" href="https://www.locize.app/register?from=header" rel="noopener noreferrer" target="_blank">Register</a></div></div><div class="md:hidden pb-2"><nav class="flex items-center gap-5 text-sm font-medium overflow-x-auto whitespace-nowrap [scrollbar-width:none] [-webkit-overflow-scrolling:touch]" aria-label="Primary"><a class="brand-nav-link" href="/how-it-works">How it works</a><a class="brand-nav-link" href="/for-your-team">For your team</a><a class="brand-nav-link" href="/pricing">Pricing</a><a class="brand-nav-link" href="/customers">Customers</a><a class="brand-nav-link" href="/services">Services</a><a class="brand-nav-link" href="/ai">AI</a><a class="brand-nav-link" href="/docs/introduction">Docs</a><a class="brand-nav-link" href="/blog">Blog</a></nav></div></div></header><main id="page-content" class="flex-1 relative z-10"><div class="max-w-[90rem] mx-auto px-4 py-4"><div class="max-w-3xl"><h1 class="text-4xl md:text-5xl leading-[1.05] tracking-tight">Blog</h1><p class="mt-3 text-base-content/70">Product updates, guides, and customer stories.</p></div><div class="mt-8 max-w-xl"><label class="text-sm font-medium mb-1 block" for="blog-search">Search</label><input id="blog-search" type="search" placeholder="Search postsâ¦" class="input input-bordered w-full" value=""/></div><div class="mt-5 flex flex-wrap gap-2"><button type="button" class="btn btn-sm no-underline brand-btn">ALL<span class="ml-1 text-gray-500">(<!-- -->131<!-- -->)</span></button><button type="button" class="btn btn-sm no-underline btn-ghost border border-base-200">COMPANY<span class="ml-1 text-gray-500">(<!-- -->8<!-- -->)</span></button><button type="button" class="btn btn-sm no-underline btn-ghost border border-base-200">ENGINEERING<span class="ml-1 text-gray-500">(<!-- -->11<!-- -->)</span></button><button type="button" class="btn btn-sm no-underline btn-ghost border border-base-200">GUIDES<span class="ml-1 text-gray-500">(<!-- -->77<!-- -->)</span></button><button type="button" class="btn btn-sm no-underline btn-ghost border border-base-200">OPEN SOURCE<span class="ml-1 text-gray-500">(<!-- -->3<!-- -->)</span></button><button type="button" class="btn btn-sm no-underline btn-ghost border border-base-200">PRODUCT<span class="ml-1 text-gray-500">(<!-- -->11<!-- -->)</span></button><button type="button" class="btn btn-sm no-underline btn-ghost border border-base-200">TUTORIALS<span class="ml-1 text-gray-500">(<!-- -->
3821<!-- -->)</span></button></div><div class="mt-8 grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-8"><a href="/blog/ai-act-transparency-code-of-practice" class="brand-card brand-card-hover flex flex-col h-full p-0 overflow-hidden no-underline group focus:outline-none focus:ring-2 focus:ring-[var(--brand-primary)]" aria-label="The EU AI Act transparency Code of Practice: who signed, and what it means for translated content" tabindex="0" style="position:relative"><div style="width:100%;height:192px;position:relative"><img src="/img/blog/ai-act-transparency-code-of-practice/thumbnail.jpg" alt="The EU AI Act transparency Code of Practice: who signed, and what it means for translated content" style="display:block;width:100%;height:100%;object-fit:cover;border-top-left-radius:inherit;border-top-right-radius:inherit" loading="lazy"/><span class="blog-badge blog-badge-right" style="position:absolute;top:0;right:0;z-index:10;margin:0">Guides</span></div><div class="flex flex-col flex-1 p-6"><h2 class="text-xl font-semibold tracking-tight mb-2 group-hover:underline">The EU AI Act transparency Code of Practice: who signed, and what it means for translated content</h2><p class="text-sm text-base-content/70 mb-4 leading-relaxed line-clamp-3">As of September 9, 2026, the European Commission's Code of Practice on transparency of AI-generated content lists 83 provider and 152 deployer signatories, and the list keeps growing. What the Code is, what signing commits a company to, why not signing is not non-compliance, and what it changes, and does not change, for machine- and AI-translated websites and apps under Article 50.</p><div class="mt-auto flex flex-wrap items-center gap-2 text-xs text-base-content/60"><span>September 9, 2026</span><span>⢠<!-- -->11 min read</span></div></div></a><a href="/blog/what-is-continuous-localization" class="brand-card brand-card-hover flex flex-col h-full p-0 overflow-hidden no-underline group focus:outline-none focus:ring-2 focus:ring-[var(--brand-primary)]" aria-label="What is continuous localization? Definition, workflow, and what it does not mean" tabindex="0" style="position:relative"><div style="width:100%;height:192px;position:relative"><img src="/img/blog/what-is-continuous-localization/thumbnail.jpg" alt="What is continuous localization? Definition, workflow, and what it does not mean" style="display:block;width:100%;height:100%;object-fit:cover;border-top-left-radius:inherit;border-top-right-radius:inherit" loading="lazy"/><span class="blog-badge blog-badge-right" style="position:absolute;top:0;right:0;z-index:10;margin:0">Guides</span></div><div class="flex flex-col flex-1 p-6"><h2 class="text-xl font-semibold tracking-tight mb-2 group-hover:underline">What is continuous localization? Definition, workflow, and what it does not mean</h2><p class="text-sm text-base-content/70 mb-4 leading-relaxed line-clamp-3">Continuous localization is a translation workflow that runs in parallel with development: new strings flow from the code to translators or AI automatically, and approved translations reach the running application without a release. The definition, the four stages, how it differs from batch localization, what you need before it works, and what it does not solve.</p><div class="mt-auto flex flex-wrap items-center gap-2 text-xs text-base-content/60"><span>September 7, 2026</span><span>⢠<!-- -->10 min read</span></div></div></a><a href="/blog/translation-glossary" class="brand-card brand-card-hover flex flex-col h-full p-0 overflow-hidden no-underline group focus:outline-none focus:ring-2 focus:ring-[var(--brand-primary)]" aria-label="What is a translation glossary? Definition, examples, and how it is enforced" tabindex="0" style="position:relative"><div style="width:100%;height:192px;position:relative"><img src="/img/blog/translation-glossary/thumbnail.jpg" alt="What is a translation glossary? Definition, examples, and how it is enforced" style="display:block;width:100%;height:100%;object-fit:cover;border-top-left-radius:inherit;border-top-right-radius:inherit" loading="lazy"/><span class="blog-badge blog-badge-right" style="position:absolute;top:0;right:0;z-index:10;margin:0">Guides</span></div><div class="flex flex-col flex-1 p-6"><h2 class="text-xl font-semibold tracking-tight mb-2 group-hover:underline">What is a translation glossary? Definition, examples, and how it is enforced</h2><p class="text-sm text-base-content/70 mb-4 leading-relaxed line-clamp-3">A translation glossary is the list of terms a product must translate the same way every time, with the approved translation per language. What belongs in one (preferred, allowed and forbidden terms), how it differs from a style guide and from a translation memory, why machine and AI translation need it more than human translators do, how it is enforced with automated checks, how teams build one, and what it does not fix.</p><div class="mt-auto flex flex-wrap items-center gap-2 text-xs text-base-content/60"><span>September 5, 2026</span><span>⢠<!-- -->10 min read</span></div></div></a><a href="/blog/coding-agents-translation" class="brand-card brand-card-hover flex flex-col h-full p-0 overflow-hidden no-underline group focus:outline-none focus:ring-2 focus:ring-[var(--brand-primary)]" aria-label="When coding agents translate your app: what breaks, what to keep" tabindex="0" style="position:relative"><div style="width:100%;height:192px;position:relative"><img src="/img/blog/coding-agents-translation/thumbnail.jpg" alt="When coding agents translate your app: what breaks, what to keep" style="display:block;width:100%;height:100%;object-fit:cover;border-top-left-radius:inherit;border-top-right-radius:inherit" loading="lazy"/><span class="blog-badge blog-badge-right" style="position:absolute;top:0;right:0;z-index:10;margin:0">Guides</span></div><div class="flex flex-col flex-1 p-6"><h2 class="text-xl font-semibold tracking-tight mb-2 group-hover:underline">When coding agents translate your app: what breaks, what to keep</h2><p class="text-sm text-base-content/70 mb-4 leading-relaxed line-clamp-3">AI coding agents now add translation keys and draft the translated strings as part of a code change, with more context than most translators ever get. What they do well, what does not carry over time (consistency across releases, review and provenance, terminology governance, QA over the whole corpus), how teams handle it today, and the agent-in-the-loop pattern that keeps the speed without losing the record.</p><div class="mt-auto flex flex-wrap items-center gap-2 text-xs text-base-content/60"><span>September 3, 2026</span><span>⢠<!-- -->11 min read</span></div></div></a><a href="/blog/translation-files-without-manual-json-editing" class="brand-card brand-card-hover flex flex-col h-full p-0 overflow-hidden no-underline group focus:outline-none focus:ring-2 focus:ring-[var(--brand-primary)]" aria-label="Managing translation files without manual JSON editing" tabindex="0" style="position:relative"><div style="width:100%;height:192px;position:relative"><img src="/img/blog/translation-files-without-manual-json-editing/thumbn
38ail.jpg" alt="Managing translation files without manual JSON editing" style="display:block;width:100%;height:100%;object-fit:cover;border-top-left-radius:inherit;border-top-right-radius:inherit" loading="lazy"/><span class="blog-badge blog-badge-right" style="position:absolute;top:0;right:0;z-index:10;margin:0">Guides</span></div><div class="flex flex-col flex-1 p-6"><h2 class="text-xl font-semibold tracking-tight mb-2 group-hover:underline">Managing translation files without manual JSON editing</h2><p class="text-sm text-base-content/70 mb-4 leading-relaxed line-clamp-3">Nobody decides to hand-edit translation files; teams end up there. What translation file management means, why JSON, YAML and resx files turn into merge conflicts, drift and keys nobody owns, how teams handle it today (code editors, spreadsheets, CI sync, a TMS, coding agents), what removing the manual editing does not solve, and where Locize fits.</p><div class="mt-auto flex flex-wrap items-center gap-2 text-xs text-base-content/60"><span>September 1, 2026</span><span>⢠<!-- -->11 min read</span></div></div></a><a href="/blog/translation-qa-checks" class="brand-card brand-card-hover flex flex-col h-full p-0 overflow-hidden no-underline group focus:outline-none focus:ring-2 focus:ring-[var(--brand-primary)]" aria-label="Translation QA: What Actually Breaks in Translations, and How to Catch It Automatically" tabindex="0" style="position:relative"><div style="width:100%;height:192px;position:relative"><img src="/img/blog/translation-qa-checks/thumbnail.jpg" alt="Translation QA: What Actually Breaks in Translations, and How to Catch It Automatically" style="display:block;width:100%;height:100%;object-fit:cover;border-top-left-radius:inherit;border-top-right-radius:inherit" loading="lazy"/><span class="blog-badge blog-badge-right" style="position:absolute;top:0;right:0;z-index:10;margin:0">Guides</span></div><div class="flex flex-col flex-1 p-6"><h2 class="text-xl font-semibold tracking-tight mb-2 group-hover:underline">Translation QA: What Actually Breaks in Translations, and How to Catch It Automatically</h2><p class="text-sm text-base-content/70 mb-4 leading-relaxed line-clamp-3">Most translation defects are not bad language, they are mechanical: a dropped placeholder, a broken HTML tag, a number that changed, the same term translated three different ways. What translation QA means, which errors appear in real translation data, what manual review keeps missing, and how automated linguistic checks catch the mechanical layer so human reviewers can focus on meaning.</p><div class="mt-auto flex flex-wrap items-center gap-2 text-xs text-base-content/60"><span>August 28, 2026</span><span>⢠<!-- -->8 min read</span></div></div></a><a href="/blog/many-projects-one-team" class="brand-card brand-card-hover flex flex-col h-full p-0 overflow-hidden no-underline group focus:outline-none focus:ring-2 focus:ring-[var(--brand-primary)]" aria-label="Many Projects, One Team: Access and Billing When Localization Outgrows One App" tabindex="0" style="position:relative"><div style="width:100%;height:192px;position:relative"><img src="/img/blog/many-projects-one-team/thumbnail.jpg" alt="Many Projects, One Team: Access and Billing When Localization Outgrows One App" style="display:block;width:100%;height:100%;object-fit:cover;border-top-left-radius:inherit;border-top-right-radius:inherit" loading="lazy"/><span class="blog-badge blog-badge-right" style="position:absolute;top:0;right:0;z-index:10;margin:0">Guides</span></div><div class="flex flex-col flex-1 p-6"><h2 class="text-xl font-semibold tracking-tight mb-2 group-hover:underline">Many Projects, One Team: Access and Billing When Localization Outgrows One App</h2><p class="text-sm text-base-content/70 mb-4 leading-relaxed line-clamp-3">The second app is where translation management quietly breaks: the same people re-invited everywhere, offboarding by memory, one invoice per project, and no answer to "who can change the German copy?". What the account layer above your projects has to do, and how organizations in Locize do it.</p><div class="mt-auto flex flex-wrap items-center gap-2 text-xs text-base-content/60"><span>August 9, 2026</span><span>⢠<!-- -->7 min read</span></div></div></a><a href="/blog/i18n-without-translation-files" class="brand-card brand-card-hover flex flex-col h-full p-0 overflow-hidden no-underline group focus:outline-none focus:ring-2 focus:ring-[var(--brand-primary)]" aria-label="i18n Without Translation Files? You Can Do That With i18next Today" tabindex="0" style="position:relative"><div style="width:100%;height:192px;position:relative"><img src="/img/blog/i18n-without-translation-files/thumbnail.jpg" alt="i18n Without Translation Files? You Can Do That With i18next Today" style="display:block;width:100%;height:100%;object-fit:cover;border-top-left-radius:inherit;border-top-right-radius:inherit" loading="lazy"/><span class="blog-badge blog-badge-right" style="position:absolute;top:0;right:0;z-index:10;margin:0">Guides</span></div><div class="flex flex-col flex-1 p-6"><h2 class="text-xl font-semibold tracking-tight mb-2 group-hover:underline">i18n Without Translation Files? You Can Do That With i18next Today</h2><p class="text-sm text-base-content/70 mb-4 leading-relaxed line-clamp-3">A new wave of i18n tools pitches "
38your code is the source of truth, translation files are build artifacts". The i18next ecosystem has supported exactly this workflow for years: natural-language keys, JSX serialization via Trans, saveMissing reporting, automatic AI translation, and CDN delivery with no locale files in your repo at all. The recipe, the honest trade-offs, and what "no files" does not solve.</p><div class="mt-auto flex flex-wrap items-center gap-2 text-xs text-base-content/60"><span>July 8, 2026</span><span>⢠<!-- -->5 min read</span></div></div></a><a href="/blog/i18n-formatting" class="brand-card brand-card-hover flex flex-col h-full p-0 overflow-hidden no-underline group focus:outline-none focus:ring-2 focus:ring-[var(--brand-primary)]" aria-label="i18n Formatting: Dates, Numbers & Currency with Intl and i18next (2026 Guide)" tabindex="0" style="position:relative"><div style="width:100%;height:192px;position:relative"><img src="/img/blog/i18n-formatting/thumbnail.jpg" alt="i18n Formatting: Dates, Numbers & Currency with Intl and i18next (2026 Guide)" style="display:block;width:100%;height:100%;object-fit:cover;border-top-left-radius:inherit;border-top-right-radius:inherit" loading="lazy"/><span class="blog-badge blog-badge-right" style="position:absolute;top:0;right:0;z-index:10;margin:0">Guides</span></div><div class="flex flex-col flex-1 p-6"><h2 class="text-xl font-semibold tracking-tight mb-2 group-hover:underline">i18n Formatting: Dates, Numbers & Currency with Intl and i18next (2026 Guide)</h2><p class="text-sm text-base-content/70 mb-4 leading-relaxed line-clamp-3">Hand-rolled "$" + toFixed(2) formatting is a bug in most locales: 1,234.56 is 1.234,56 in German and 1 234 567,89 in French, and yen has no decimal places. This guide covers Intl.NumberFormat, DateTimeFormat, RelativeTimeFormat, and how i18next wires them into translation strings with {{val, number}}, currency, datetime and custom formatters.</p><div class="mt-auto flex flex-wrap items-center gap-2 text-xs text-base-content/60"><span>July 7, 2026</span><span>⢠<!-- -->5 min read</span></div></div></a></div><div class="mt-10 flex items-center gap-3"><button type="button" class="btn btn-sm btn-ghost border border-base-200 disabled:opacity-50" disabled="">â Previous</button><div class="flex items-center gap-1 flex-wrap"><button type="button" class="btn btn-sm w-10 h-10 px-0 brand-btn">1</button><button type="button" class="btn btn-sm w-10 h-10 px-0 btn-ghost border border-base-200">2</button><button type="button" class="btn btn-sm w-10 h-10 px-0 btn-ghost border border-base-200">3</button><button type="button" class="btn btn-sm w-10 h-10 px-0 btn-ghost border border-base-200">4</button><button type="button" class="btn btn-sm w-10 h-10 px-0 btn-ghost border border-base-200">5</button><button type="button" class="btn btn-sm w-10 h-10 px-0 btn-ghost border border-base-200">6</button><button type="button" class="btn btn-sm w-10 h-10 px-0 btn-ghost border border-base-200">7</button><button type="button" class="btn btn-sm w-10 h-10 px-0 btn-ghost border border-base-200">8</button><button type="button" class="btn btn-sm w-10 h-10 px-0 btn-ghost border border-base-200">9</button><button type="button" class="btn btn-sm w-10 h-10 px-0 btn-ghost border border-base-200">10</button><button type="button" class="btn btn-sm w-10 h-10 px-0 btn-ghost border border-base-200">11</button><button type="button" class="btn btn-sm w-10 h-10 px-0 btn-ghost border border-base-200">12</button><button type="button" class="btn btn-sm w-10 h-10 px-0 btn-ghost border border-base-200">13</button><button type="button" class="btn btn-sm w-10 h-10 px-0 btn-ghost border border-base-200">14</button><button type="button" class="btn btn-sm w-10 h-10 px-0 btn-ghost border border-base-200">15</button></div><button type="button" class="btn btn-sm btn-ghost border border-base-200 disabled:opacity-50">Next â</button></div></div></main><footer class="border-t border-white/10 relative z-10 text-neutral-content bg-[linear-gradient(180deg,var(--brand-ink)_0%,color-mix(in_srgb,var(--brand-ink)_88%,white)_100%)]"><div class="max-w-[90rem] mx-auto px-4 py-6 pb-4"><div class="flex items-center justify-between gap-6"><a href="/" class="inline-flex items-center no-underline"><img src="/img/locize_white.svg" alt="Locize" class="h-7 w-auto"/></a><div class="flex items-center gap-3"><a class="btn btn-circle btn-sm btn-outline no-underline text-neutral-content/80 hover:text-[var(--brand-primary)]" href="mailto:[email protected]" aria-label="Email [email protected]" title="Email"><i class="material-icons" style="font-size:18px">mail</i></a><a class="btn btn-circle btn-sm btn-outline no-underline text-neutral-content/80 hover:text-[var(--brand-primary)]" href="https://x.com/locize" target="_blank" rel="noopener noreferrer" aria-label="Locize on X" title="X"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 640 640" class="w-4 h-4" fill="currentColor" aria-hidden="true"><path d="M453.2 112L523.8 112L369.6 288.2L551 528L409 528L297.7 382.6L170.5 528L99.8 528L264.7 339.5L90.8 112L236.4 112L336.9 244.9L453.2 112zM428.4 485.8L467.5 485.8L215.1 152L173.1 152L428.4 485.8z"></path></svg></a><a class="btn btn-circle btn-sm btn-outline no-underline text-neutral-content/80 hover:text-[var(--brand-primary)]" href="https://www.facebook.com/locize" target="_blank" rel="noopener noreferrer" aria-label="Locize on Facebook" title="Facebook"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 640 640" class="w-4 h-4" fill="currentColor" aria-hidden="true">
38<path d="M576 320C576 178.6 461.4 64 320 64C178.6 64 64 178.6 64 320C64 440 146.7 540.8 258.2 568.5L258.2 398.2L205.4 398.2L205.4 320L258.2 320L258.2 286.3C258.2 199.2 297.6 158.8 383.2 158.8C399.4 158.8 427.4 162 438.9 165.2L438.9 236C432.9 235.4 422.4 235 409.3 235C367.3 235 351.1 250.9 351.1 292.2L351.1 320L434.7 320L420.3 398.2L351 398.2L351 574.1C477.8 558.8 576 450.9 576 320z"></path></svg></a><a class="btn btn-circle btn-sm btn-outline no-underline text-neutral-content/80 hover:text-[var(--brand-primary)]" href="https://www.youtube.com/channel/UCPYQjBbbXojUcB8qjeIB3uA" target="_blank" rel="noopener noreferrer" aria-label="Locize on YouTube" title="YouTube"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 640 640" class="w-4 h-4" fill="currentColor" aria-hidden="true"><path d="M581.7 188.1C575.5 164.4 556.9 145.8 533.4 139.5C490.9 128 320.1 128 320.1 128C320.1 128 149.3 128 106.7 139.5C83.2 145.8 64.7 164.4 58.4 188.1C47 231 47 320.4 47 320.4C47 320.4 47 409.8 58.4 452.7C64.7 476.3 83.2 494.2 106.7 500.5C149.3 512 320.1 512 320.1 512C320.1 512 490.9 512 533.5 500.5C557 494.2 575.5 476.3 581.8 452.7C593.2 409.8 593.2 320.4 593.2 320.4C593.2 320.4 593.2 231 581.8 188.1zM264.2 401.6L264.2 239.2L406.9 320.4L264.2 401.6z"></path></svg></a><a class="btn btn-circle btn-sm btn-outline no-underline text-neutral-content/80 hover:text-[var(--brand-primary)]" href="https://www.instagram.com/i18next_locize/" target="_blank" rel="noopener noreferrer" aria-label="Locize on Instagram" title="Instagram"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 640 640" class="w-4 h-4" fill="currentColor" aria-hidden="true"><path d="M320.3 205C256.8 204.8 205.2 256.2 205 319.7C204.8 383.2 256.2 434.8 319.7 435C383.2 435.2 434.8 383.8 435 320.3C435.2 256.8 383.8 205.2 320.3 205zM319.7 245.4C360.9 245.2 394.4 278.5 394.6 319.7C394.8 360.9 361.5 394.4 320.3 394.6C279.1 394.8 245.6 361.5 245.4 320.3C245.2 279.1 278.5 245.6 319.7 245.4zM413.1 200.3C413.1 185.5 425.1 173.5 439.9 173.5C454.7 173.5 466.7 185.5 466.7 200.3C466.7 215.1 454.7 227.1 439.9 227.1C425.1 227.1 413.1 215.1 413.1 200.3zM542.8 227.5C541.1 191.6 532.9 159.8 506.6 133.6C480.4 107.4 448.6 99.2 412.7 97.4C375.7 95.3 264.8 95.3 227.8 97.4C192 99.1 160.2 107.3 133.9 133.5C107.6 159.7 99.5 191.5 97.7 227.4C95.6 264.4 95.6 375.3 97.7 412.3C99.4 448.2 107.6 480 133.9 506.2C160.2 532.4 191.9 540.6 227.8 542.4C264.8 544.5 375.7 544.5 412.7 542.4C448.6 540.7 480.4 532.5 506.6 506.2C532.8 480 541 448.2 542.8 412.3C544.9 375.3 544.9 264.5 542.8 227.5zM495 452C487.2 471.6 472.1 486.7 452.4 494.6C422.9 506.3 352.9 503.6 320.3 503.6C287.7 503.6 217.6 506.2 188.2 494.6C168.6 486.8 153.5 471.7 145.6 452C133.9 422.5 136.6 352.5 136.6 319.9C136.6 287.3 134 217.2 145.6 187.8C153.4 168.2 168.5 153.1 188.2 145.2C217.7 133.5 287.7 136.2 320.3 136.2C352.9 136.2 423 133.6 452.4 145.2C472 153 487.1 168.1 495 187.8C506.7 217.3 504 287.3 504 319.9C504 352.5 506.7 422.6 495 452z"></path></svg></a></div></div><div class="mt-6 border-t border-neutral-content/10 pt-6"><div class="grid grid-cols-2 md:grid-cols-5 gap-10"><div><div class="text-base font-semibold">Product</div><div class="mt-4 space-y-3 text-sm text-neutral-content/70"><a class="block no-underline hover:text-neutral-content" href="/pricing">Pricing</a><a class="block no-underline hover:text-neutral-content" href="/how-it-works">How it works</a><a class="block no-underline hover:text-neutral-content" href="/services">Services</a><span class="block"><a class="no-underline hover:text-neutral-content" href="/ai">AI</a> - <a class="no-underline hover:text-neutral-content" href="/why-not-just-use-ai">Why not just use AI?</a></span><a class="block no-underline hover:text-neutral-content" href="/continuous-localization">Continuous localization</a><a class="block no-underline hover:text-neutral-content" href="/file-formats">File Formats</a><a class="block no-underline hover:text-neutral-content" href="/docs/introduction">Docs</a></div></div><div><div class="text-base font-semibold">Solutions</div><div class="mt-4 space-y-3 text-sm text-neutral-content/70"><span class="block"><a class="no-underline hover:text-neutral-content" href="/i18next">i18next</a> or any other <a class="no-underline hover:text-neutral-content" href="/i18n-libraries">i18n library</a></span><a class="block no-underline hover:text-neutral-content" href="/javascript-localization">JavaScript localization</a><a class="block no-underline hover:text-neutral-content" href="/website-localization-services">Website localization services</a><a class="block no-underline hover:text-neutral-content" href="/software-localization-service">Software localization service</a><a class="block no-underline hover:text-neutral-content" href="/eu-accessibility-act-localization">EU Accessibility Act</a><a class="block no-underline hover:text-neutral-content" href="/for-your-team">For your team</a><a class="block no-underline hover:text-neutral-content" href="/multi-tenant">Multi-tenant</a></div></div><div><div class="text-base font-semibold">Company</div><div class="mt-4 space-y-3 text-sm text-neutral-content/70"><a class="block no-underline hover:text-neutral-content" href="/blog">Blog</a><a class="block no-underline hover:text-neutral-content" href="/customers">Case studies</a><a class="block no-underline hover:text-neutral-content" href="/security">Security</a><a class="block no-underline hover:text-neutral-content" href="/why-no-sales">Our Philosophy</a><a class="block no-underline hover:text-neutral-content" href="/compare">Compare Competitors</a><a class="block no-underline hover:text-neutral-content" href="/swiss-made-tms">Swiss-made TMS</a></div></div><div><div class="text-base font-semibold">Important Links</div><div class="mt-4 space-y-3 text-sm text-neutral-content/70"><a class="block no-underline hover:text-neutral-content" href="/terms">Terms</a><a class="block no-underline hover:text-neutral-content" href="/privacy">Privacy policy</a><a class="block no-underline hover:text-neutral-content" href="/dpa">DPA</a><a class="block no-underline hover:text-neutral-content" href="/ccpa">CCPA terms</a><a class="block no-underline hover:text-neutral-content" href="mailto:[email protected]">Support</a></div></div><div><div class="text-base font-semibold">Registration</div><div class="mt-5"><a class="brand-btn btn-md w-full no-underline" href="https://www.locize.app/register?from=footer" rel="noopener noreferrer" target="_blank">Register for free</a></div></div></div><div class="mt-6 border-t border-neutral-content/10 pt-4 flex flex-col sm:flex-row items-center justify-center gap-3 text-sm text-neutral-content/70"><span>© 2026 inweso Ltd liab. Co. All Rights Reserved.</span><div class="inline-flex items-center gap-2 text-xs"><span aria-hidden="true" class="text-neutral-content/50">·</span><span class="text-neutral-content/50">Language<!-- -->:</span><a href="/de/blog" class="text-neutral-content/80 hover:text-neutral-content no-underline">
38Deutsch</a><a href="/it/blog" class="text-neutral-content/80 hover:text-neutral-content no-underline">Italiano</a><a href="/fr/blog" class="text-neutral-content/80 hover:text-neutral-content no-underline">Français</a></div></div></div></div></footer></div><div class="fixed right-2 bottom-2 inline-flex items-center gap-2 bottom-utility-buttons z-50"><button class="brand-btn-outline btn-circle btn-sm no-underline" type="button" aria-label="Cookie preferences"><i class="material-icons" style="font-size:24px">cookie</i></button><button class="brand-btn-outline btn-circle btn-sm no-underline" type="button" aria-label="Scroll to top"><i class="material-icons" style="font-size:24px">arrow_upward</i></button></div></div> 39 40
40<script id="vike_pageContext" type="application/json">{"pageId":"\/pages\/blog\/index","routeParams":{},"data":{"posts":[{"slug":"ai-act-transparency-code-of-practice","title":"The EU AI Act transparency Code of Practice: who signed, and what it means for translated content","description":"As of September 9, 2026, the European Commission's Code of Practice on transparency of AI-generated content lists 83 provider and 152 deployer signatories, and the list keeps growing. What the Code is, what signing commits a company to, why not signing is not non-compliance, and what it changes, and does not change, for machine- and AI-translated websites and apps under Article 50.","date":"2026-09-09","category":"Guides","thumbnail":"\/img\/blog\/ai-act-transparency-code-of-practice\/thumbnail.jpg","readTime":"11 min read","searchText":"title: 'The EU AI Act transparency Code of Practice: who signed, and what it means for translated content', description: 'As of September 9, 2026, the European Commission\\'s Code of Practice on transparency of AI generated content lists 83 provider and 152 deployer signatories, and the list keeps growing. What the Code is, what signing commits a company to, why not signing is not non compliance, and what it changes, and does not change, for machine and AI translated websites and apps under Article 50.', date: '2026 09 09', thumbnail: '\/img\/blog\/ai act transparency code of practice\/thumbnail.jpg', image: '\/img\/blog\/ai act transparency code of practice\/title.jpg', category: 'Guides', tags: ['eu ai act', 'compliance', 'transparency', 'code of practice', 'ai', 'machine translation', 'localization', 'review', 'workflow'], faq: [ q: 'What is the Code of Practice on transparency of AI generated content?', a: 'A voluntary framework published by the European Commission that providers and deployers of generative AI systems can sign to demonstrate compliance with the transparency obligations of Article 50 of the EU AI Act. It has two sections: Section 1 for providers (machine readable marking and detection of AI generated content) and Section 2 for deployers (labelling of deepfakes and of AI generated text published to inform the public on matters of public interest). The Commission and the AI Board have assessed it as an adequate tool for demonstrating compliance; signatories can rely on its measures, while non signatories demonstrate compliance by other means.' , q: 'Who has signed the Code of Practice on transparency of AI generated content?', a: 'As of September 9, 2026, the Commission\\'s signatory table lists 83 organisations under Section 1 (the page\\'s own summary line says 82) and 152 under Section 2, about 190 in total. Section 1 examples the Commission itself names include Aleph Alpha, Anthropic, Black Forest Labs, Cohere, Google, Meta, Microsoft, Mistral, OpenAI and Synthesia; Section 2 examples include Bulgari, Fastweb, Getty Images, Iberdrola, Lenovo and Lufthansa. The Commission states the list is updated on an ongoing basis, so check the live page before quoting a number.' , q: 'Is signing the Code of Practice mandatory?', a: 'No. The Commission\\'s own FAQ states that signing is voluntary and that not signing does not constitute non compliance with the AI Act. The difference is procedural: signatories may rely on the Code\\'s measures to demonstrate compliance with Article 50, while providers and deployers that comply through other means have to show that those means are adequate, assessed individually by the market surveillance authorities. Signatories can also withdraw.' , q: 'Does the Code of Practice apply to machine translated or AI translated content?', a: 'Indirectly. The Code is a way to demonstrate compliance with Article 50; what Article 50 requires for translations is set by the Act and the Commission\\'s final guidelines of July 20, 2026. Under those guidelines a faithful AI translation counts as standard editing and is exempt from the machine readable marking duty of Article 50(2). The visible disclosure duty of Article 50(4) covers AI generated text published to inform the public on matters of public interest, and falls away where the text has undergone human review or editorial control with a person holding editorial responsibility. Signing the Code does not change either rule. This is not legal advice.' , q: 'What should a company that publishes AI translated content do now?', a: 'Decide which of its translated content falls under the public interest scope of Article 50(4), which for most UI strings and product copy is none of it, and for public health, safety, corporate reporting or public service content can be all of it. For that content, either apply a visible disclosure or run a documented human review with a named editorial responsibility, which the final guidelines illustrate with exactly the case of a human reviewed AI translation. Keep the record per translation. Whether to sign Section 2 of the Code on top is a separate, voluntary decision. Consult a lawyer for your own obligations.' ] The Code of Practice on transparency of AI generated content is a voluntary framework published by the European Commission that providers and deployers of generative AI systems can sign to demonstrate compliance with the marking and labelling obligations of Article 50 of the EU AI Act. As of September 9, 2026 , the Commission's signatory table names 83 organisations under Section 1 (providers) and 152 under Section 2 (deployers), and the Commission states that the list is updated on an ongoing basis. This post explains what the Code is and is not, who has signed it as of today, what a signature commits a company to, and the question that matters for anyone running a localized website or app: what the Code changes, and does not change, for machine and AI translated content. The underlying question, whether machine translated text is \"AI generated\" under the Act, is answered in the Article 50 explainer; this post starts where that one ends. This is not legal advice. This article summarizes public documents of the European Commission for orientation, with the date each fact was checked. The Code and the guidelines are non binding; authoritative interpretation of the AI Act rests with the CJEU. For decisions about your own obligations, consult a qualified lawyer. Key facts What it is: a voluntary code with two sections, Section 1 for providers (machine readable marking and detection) and Section 2 for deployers (labelling deepfakes and AI generated text on matters of public interest), assessed as adequate by the C
40ommission and the AI Board. Who signed, as of September 9, 2026: 83 Section 1 and 152 Section 2 signatories in the Commission's table (its summary line says 82), about 190 in total; the initial list was published on July 31, 2026, and the list remains open. Voluntary, in the Commission's own words: \"Signing the code of practice is voluntary. Not signing it does not constitute non compliance with the AI Act.\" Signatories may rely on the Code to demonstrate compliance; non signatories demonstrate it by other means. For translated content nothing moves: faithful AI translations are exempt from machine readable marking under the final guidelines of July 20, 2026; visible disclosure applies only to public interest text and falls away with documented human review under editorial responsibility. The Code is a way to demonstrate compliance, not a change to those rules. Dates around it: Article 50 applies since August 2, 2026; generative systems already on the market before that date have until December 2, 2026 for machine readable marking; signatory task forces were announced for September 2026. What the Code of Practice is, and what it is not Article 50 of the AI Act puts two content obligations on two different actors: providers of generative AI systems must mark their output in a machine readable way (Article 50(2)), and deployers must visibly disclose deepfakes and AI generated text published to inform the public on matters of public interest (Article 50(4)). Article 50(7) asks the Commission to encourage codes of practice that make those obligations workable, and the Code of Practice on transparency of AI generated content is the result. It has two sections that mirror the two obligations. Section 1 is for providers: rules for marking and detecting AI generated and manipulated content. It can also be signed by providers of marking and detection technology and by AI model providers whose models help others implement the measures. Section 2 is for deployers: rules for labelling deepfakes and certain AI generated or manipulated text published to inform the public on matters of public interest. The Commission also published a set of icons that deployers may use for labels. What the Code is not: it is not the law, and it is not the guidelines. The obligations are in the Act; how the Commission reads them is in the final guidelines on transparency obligations of July 20, 2026. The Code is a way to demonstrate that you meet the obligations. The Commission and the AI Board have confirmed, in the Commission's words, that \"the code is an adequate voluntary tool to demonstrate compliance with the AI Act transparency obligations\". Who signed, as of September 9, 2026 The Commission published the initial signatory list on July 31, 2026, two days before the obligations applied, and describes about 190 organisations \"across various sectors, including IT, telecom, education, and retail\", about half of them \"small and recent companies\". Counting the table on that page on September 9, 2026 gives 83 names under Section 1 and 152 under Section 2; the page's own summary line says 82 for Section 1, so treat the exact figure as approximate and the list as moving. The Commission's own examples for Section 1 are Aleph Alpha, Anthropic, Black Forest Labs, Cohere, Google, Meta, Microsoft, Mistral, OpenAI and Synthesia; for Section 2, Bulgari, Fastweb, Getty Images, Iberdrola, Lenovo and Lufthansa. Two observations matter for localization teams. First, the model and platform providers whose engines translation workflows commonly run on (Google, Microsoft, OpenAI, Mistral and Anthropic among them) are Section 1 signatories, which is where the machine readable marking duty sits. Second, the translation industry is barely represented by name: one translation technology company (EasyTranslate) appears under Section 1 as of that date, and no translation or localization vendor is among the Commission's own examples. Given that faithful translations sit outside the marking duty, that is consistent, and it implies nothing about anyone's compliance, because signing is voluntary. The Commission also announced that signatories would be invited to collaborate in two task forces \"to be launched in September 2026\" to share practices and advance implementation. As of the date of this post the Commission's page still describes them in the future tense. What signing commits a company to According to the Commission's signing FAQ, the mechanics are simple: Who can sign: providers of generative AI systems subject to Article 50(2) (Section 1); deployers subject to Article 50(4), particularly those using generative AI professionally in ways that affect public discourse (Section 2); plus AI model providers and providers of marking and detection technology (Section 1). What a signature is
40worth: signatories \"may rely on the code to demonstrate compliance with their obligations under Article 50\", with, in the Commission's words, \"clarity and increased legal certainty across the EU\". Providers and deployers that comply through other means \"will have to demonstrate that those measures are adequate\", assessed individually by market surveillance authorities. What it is not: an obligation. \"Signing the code of practice is voluntary. Not signing it does not constitute non compliance with the AI Act.\" Signatories can withdraw by letter at executive level. What Section 2 signatories commit to: disclosure and labelling of deepfakes and of certain AI generated or manipulated text published with the purpose of informing the public on matters of public interest, following the Code's measures. In other words, the Code trades a documented, EU wide recognised way of meeting the obligation for a public commitment to it. For a company whose exposure under Article 50 is small, that trade is often not worth the signature; for one that publishes AI generated public interest content across several member states, it may well be. What it means for translated content This is the part localization teams actually need, and it is shorter than the rest, because the Code does not change the rules that apply to translation; it only offers a way to demonstrate compliance with them. Machine readable marking is your provider's duty, and faithful translation is exempt from it. Article 50(2) sits with the provider of the AI system. The final guidelines of July 20, 2026 list \"AI generated translations of text\" among the examples of standard editing that benefit from the Article 50(2) exception, next to grammar correction and minor stylistic polishing, while summaries and rewrites that change meaning stay marking required. Your MT or AI provider signing Section 1 tells you how they demonstrate the marking of the output that does need marking; it does not create a marking duty for your translated UI strings. Visible disclosure is your duty, and it is narrow. Article 50(4) covers AI generated or manipulated text \"published with the purpose of informing the public on matters of public interest\". Product copy, UI strings, entertainment and ordinary advertising fall outside; public health and safety information, reporting on political or economic developments, corporate reports, public service information can fall inside. An AI translated help article on product safety is the kind of content to look at. The exemption that touches translation workflows is human review, not the Code. Article 50(4) does not apply where the content \"has undergone a process of human review or editorial control\" and a natural or legal person holds editorial responsibility for the publication. The final guidelines' own example of content that qualifies is, verbatim, an \"AI supported translation of a human written article whereby the translation has undergone human review\". Review has to be substantive (fact checking is named as a minimum ingredient), it has to be the last touch before publication, and the responsible person has to be findable. A signature on the Code is an alternative way for a deployer to demonstrate its Article 50(4) compliance; it does not replace the review, and it does not lower the bar for it. So, as of September 9, 2026, the practical position is unchanged from August 2: for the small share of translated content in Article 50(4)'s scope, either label it or review it under a named editorial responsibility and keep the record. Whether to sign Section 2 on top is a voluntary, company level decision that has little to do with translation and a lot to do with what else the company publishes with generative AI. How teams handle it today Ignore it, correctly or not. Most localized products publish nothing that informs the public on matters of public interest, and for them the honest answer to \"what do we need to do about the Code\" is \"nothing, but write down why\". The risk is the team that has not checked its help center, its status page or its investor pages against the scope. Sign Section 2. Deployers with substantial AI generated public interest output, typically media, public bodies and large corporates, take the documented route. As of September 9, 2026 that is 152 organisations. Document the review instead. Route AI translated public interest content through substantive human review with recorded decisions and a named responsible person, and rely on the Article 50(4) exemption. This is the path that overlaps with what a translation workflow does anyway, which is why it is the one most localization teams end up on. Ask the vendors. Ask MT and AI providers how they handle Article 50(2) marking, and whether they signed Section 1; the Commission's list answers the second question in seconds. Ask agencies and translation platforms how review decisions are recorded and exported. What the Code does not solve It is not binding and not a safe harbour in the legal sense. The Commission's assessment says the Code is adequate for demonstrating compliance; the last word on Article 50 belongs to the CJEU. It does not make anything reviewed. A Section 2 signature commits a deployer to labelling; it does not turn unreviewed machine output into reviewed content. The human review exemption is met by the review, not by the signature. It does not cover most translated content, because Article 50(4) does not. UI strings, product descriptions and marketing copy are outside the scope whether or not anyone signs anything. It is still forming. The task forces announced for September 2026 had not been described as launched on the Commission's pages as of this post; the list changes; the guidelines have a stated review path. Date every claim you make about it, including the ones in this post. How this works in Locize Locize does not sign anything on your behalf and does not make you compliant; no tool does. What it gives a deployer on the review path is the evidence the Article 50(4) exemption asks for: The review workflow holds AI and machine translations as proposals or marks them as needing review until a person with the right permission confirms, edits or declines them, per segment. Quality estimation scores every AI translation and routes low confidence ones into review, so substantive attention goes where the model is least sure. The history records who decided what and when, and the provenance export described
40in the Article 50 workflow guide packages it as CSV and JSON per version, language or namespace, with a review status per key that an auditor can read without the product. The needs review queue in the Locize editor: a pending proposal with the reviewer's decision, recorded per value Not sure whether any of your translated content is in scope at all? The Article 50 readiness check walks through the questions. If it is, create a project, enable review proposals for the languages that matter, and the record starts with the next translation. Frequently asked questions What is the Code of Practice on transparency of AI generated content? A voluntary framework published by the European Commission that providers and deployers of generative AI systems can sign to demonstrate compliance with the transparency obligations of Article 50 of the EU AI Act: Section 1 for providers (machine readable marking and detection), Section 2 for deployers (labelling deepfakes and AI generated public interest text). The Commission and the AI Board assessed it as adequate for that purpose. Who has signed the Code of Practice? As of September 9, 2026, the Commission's table lists 83 Section 1 and 152 Section 2 signatories, about 190 in total, with the Commission's own examples including Anthropic, Google, Meta, Microsoft, Mistral and OpenAI in Section 1 and Bulgari, Getty Images, Lenovo and Lufthansa in Section 2. The list is updated on an ongoing basis. Is signing the Code of Practice mandatory? No. In the Commission's words, signing is voluntary and not signing does not constitute non compliance. Signatories may rely on the Code to demonstrate compliance; non signatories demonstrate it by other means, assessed individually by market surveillance authorities. Does the Code of Practice apply to machine translated or AI translated content? Only indirectly, as a way to demonstrate Article 50 compliance. Under the final guidelines of July 20, 2026 a faithful AI translation is exempt from machine readable marking; the visible disclosure duty covers public interest text only and falls away with documented human review under a person holding editorial responsibility. Signing changes neither rule. This is not legal advice. What should a company that publishes AI translated content do now? Identify the translated content that informs the public on matters of public interest, which for most products is little or none. For that content, label it or review it substantively under a named editorial responsibility and keep the record per translation. Signing Section 2 is a separate, voluntary decision. Consult a lawyer for your own obligations."},{"slug":"what-is-continuous-localization","title":"What is continuous localization? Definition, workflow, and what it does not mean","description":"Continuous localization is a translation workflow that runs in parallel with development: new strings flow from the code to translators or AI automatically, and approved translations reach the running application without a release. The definition, the four stages, how it differs from batch localization, what you need before it works, and what it does not solve.","date":"2026-09-07","category":"Guides","thumbnail":"\/img\/blog\/what-is-continuous-localization\/thumbnail.jpg","readTime":"10 min read","searchText":"title: 'What is continuous localization? Definition, workflow, and what it does not mean', description: 'Continuous localization is a translation workflow that runs in parallel with development: new strings flow from the code to translators or AI automatically, and approved translations reach the running application without a release. The definition, the four stages, how it differs from batch localization, what you need before it works, and what it does not solve.', date: '2026 09 07', thumbnail: '\/img\/blog\/what is continuous localization\/thumbnail.jpg', image: '\/img\/blog\/what is continuous localization\/title.jpg', category: 'Guides', tags: ['continuous localization', 'localization', 'i18n', 'ci cd', 'workflow', 'translation management', 'cdn', 'automation', 'i18next'], faq: [ q: 'What is continuous localization?', a: 'Continuous localization is a translation workflow in which new and changed strings flow from the codebase to the people or systems that translate them automatically and continuously, in parallel with development, and approved translations are delivered to the running application without a release. It is the localization counterpart of continuous integration and continuous delivery: translation stops being a handoff before each release and becomes a process that is always running.' , q: 'How is continuous localization different from traditional localization?', a: 'In a traditional, batch workflow the strings wait: development freezes, files are exported, sent to translators, returned days or weeks later, imported and redeployed. In continuous localization nothing waits for a cut. Strings are detected as developers write them, translated while development continues, approved through a review gate rather than a freeze, and delivered at runtime. The difference is not the tool but where the strings sit between being written and being live.' , q: 'What do you need to implement continuous localization?', a: 'Four things: keys that originate in code (by extraction in CI or by runtime reporting), a single place where translators, machine translation and AI work on those keys with context, a review and publish gate that decides what goes live, and a delivery path that puts approved translations into the running application without a redeploy, typically a CDN. Versioning or branches to stage changes and automated consistency checks are the two additions most teams need next.' , q: 'Does continuous localization mean AI translation without human review?', a: 'No. Continuous describes the flow, not the quality policy. AI or machine translation can fill the first draft so that nothing waits, but what is published is decided by a gate: automated checks, a quality estimation score, and human review for the strings that need it. A pipeline that pushes unreviewed machine output straight to production is continuous and ungoverned, which is the combination that produces terminology drift and embarrassing releases.' , q: 'Is continuous localization worth it for a small team?', a: 'It pays off when translation is a release dependency: several deploys a week, more than a handful of languages, non developers who change text, or fixes that must ship faster than the release cycle. A team with two languages it reads
40itself and a few releases a year can keep a batch process; even then, delivering translations at runtime is usually worth having, because a typo fix without a deploy is useful at any size.' ] Continuous localization is a translation workflow in which new and changed strings flow from the codebase to the people or systems that translate them automatically and continuously, in parallel with development, and approved translations are delivered to the running application without a release. It is the localization counterpart of continuous integration and continuous delivery: instead of a translation handoff before each release, translation is a process that is always running, and a translation fix never waits for a deploy. This post is the definition: what the term means, what it does not mean, the four stages every implementation has, how it differs from the batch workflow it replaces, and what it does not solve. The product side, how Locize implements it, and the teams that use it that way are on the continuous localization page. Key facts Definition: translation that runs in parallel with development and delivers approved translations to the running application without a release. Continuous describes the flow, not the quality policy. Four stages in every implementation: detect (strings leave the code automatically), translate (people, machine translation and AI work while development continues), publish (a gate decides what goes live), deliver (the running application picks up approved translations). Batch versus continuous is a question of where strings wait: in an exported file on someone's desk, or in a pipeline that is always moving. What it is not: AI translation without review, a workflow without files by definition, or a substitute for terminology, review and quality checks. Those layers are what make continuous safe. What continuous localization means, and what it does not The word \"continuous\" is borrowed from continuous integration and continuous delivery on purpose. In those practices, code is integrated and shipped in small increments, all the time, instead of in large batches with a freeze before each one. Continuous localization applies the same idea to translation: the unit of work is the string, not the release, and the pipeline moves strings from code to translators to users without waiting for a cut. Three readings of the term are wrong often enough to spell out: It does not mean \"translate everything with AI and ship it\". Machine and AI translation are how the first draft stops waiting; what is published is still decided by checks and review. A pipeline that pushes unreviewed model output to production is continuous and ungoverned, which is the combination behind terminology drift and the occasional insulting error message. It does not require abolishing translation files. Some continuous setups have no locale files in the repository at all because the application loads translations at runtime; others generate the files in CI and commit them. Both are continuous if nothing waits for a manual handoff. It does not remove the need for a glossary, a review workflow or quality checks. It makes them more important, because more strings move faster. Continuous versus batch localization A batch workflow has a recognisable shape. Development reaches a cut. Someone exports the strings that changed, or all of them, into files or a spreadsheet. The files go to translators, in house or at an agency. Days or weeks later they come back, someone imports them, resolves what broke in the meantime, and the translations ship with the next deploy. Every step is a wait, and the feature that finished on the day of the cut ships in its default language only. A continuous workflow removes the cut. Strings are detected as developers write them. Translation happens while the feature is still being built. A review gate decides what is ready. Delivery does not depend on a deploy. The visible effects on an engineering team: translation stops being a release blocking dependency, and a wrong label in Polish is fixed in minutes rather than
40in the next release. The visible effect on a localization team: work arrives as a stream instead of as a pile. The four stages of a continuous localization workflow Every implementation, whatever the tooling, has the same four stages. 1. Detect: strings leave the code automatically A developer writes a translation call with a new key and a default value. Either a static extraction step in CI reads the calls and reports the keys, or the running application reports a key the first time it renders it (in i18next this is the option). Nobody exports anything; the key exists in the translation system with its default text before the pull request is merged. 2. Translate: people, machines and AI work while development continues New keys get a first draft from machine or AI translation, with the project's glossary and style guide as context, so that no language is empty while the feature is in progress. Translators and reviewers work on the same keys in an editor that shows the source, the context and the terminology. Development does not wait for this stage, and this stage does not wait for a release. 3. Publish: a gate, not a freeze What goes live is decided per string, not per release: automated checks for placeholders, numbers, tags and consistency; a quality estimation score for machine generated drafts; human review for the strings that need it. Versions or branches let a team stage translations for a feature that is not public yet. The gate replaces the freeze: the release train keeps running, and a translation joins it when it is ready. 4. Deliver: the running application picks up translations Approved translations reach users without a build: the application loads them at runtime from a content delivery network, with a cache lifetime that balances freshness against latency. Teams that need files for server side rendering or offline bundles download them in CI as generated artifacts. Either way, a fix published in the editor is live without a commit. How teams implement continuous localization today CI sync with generated files. Extraction runs in the pipeline, a sync step pushes new keys to the translation system and pulls translated files back, the files are committed or downloaded at build time. Continuous, with the files kept for builds that need them. Diff based sync matters here, so a pull request only translates the keys it added. Runtime reporting and CDN delivery. The application reports new keys as it runs (gated to development) and loads translations at runtime; the repository holds no locale files. The most direct form of the pattern, common in single page and mobile applications. A translation management system in the middle. Both of the above need a place where translators, machine translation and AI meet the keys, with review, history and publishing. The TMS is the stage 2 and stage 3 half of the workflow; the CI or runtime integration is the stage 1 and stage 4 half. AI in CI only. A workflow that extracts keys and machine translates them on push, with no editor and no review. Continuous by the definition above, and the setup that the \"what it does not mean\" section is about: nothing between the model and production. What breaks in it, and how to add the missing layer, is in when AI translations break. What you need before it works Keys originate in code. If someone still types keys into a file or a spreadsheet, stage 1 is manual and everything downstream waits for it. One source of truth. Translations live in one system; files, if any, are generated from it. Two sources of truth reintroduce the merge step that batch workflows spend their time on. A written quality policy. Which content types may ship on an AI draft plus automated checks, which need a person, which are held in review proposals until approved. Continuous flow without this policy is a faster way to ship mistakes. A staging mechanism. Versions or branches, so translations for unreleased features do not go live early and a production version can be promoted deliberately. Checks that run on the whole corpus. Placeholders, numbers, tags and cross key consistency need to be checked where all the strings are, on every save, not only on a diff. The taxonomy is in what actually breaks in translations. A measure. The one number that tells you whether the workflow is continuous: the time from a string being written to it being live in every language. If it is measured in release cycles, the workflow is batch with better tooling. What continuous localization does not solve Translation quality. Flow is not quality. Terminology governance, human review and quality checks are separate layers, and continuous flow raises the cost of skipping them. Context. A string that arrives from the code without a screenshot or a note is still ambiguous. Continuous detection makes context c
40apture more important, not less. Regulated content. Text that informs the public on matters of public interest can fall under the visible disclosure duty of Article 50 of the EU AI Act (in force since August 2, 2026), unless it has undergone documented human review with editorial responsibility. The workflow can record that review; it cannot decide which content needs it. The Article 50 explainer has the details, and none of this is legal advice. Small, slow projects. Two languages the team reads, a few releases a year: a batch process is fine. Runtime delivery is still usually worth having, because a typo fix without a deploy is useful at any size. How this works in Locize Locize was built by the i18next team around exactly this workflow, and the four stages map onto four pieces: Detect: with i18next locize backend reports keys from the running application; the CLI and the GitHub Actions do it from the pipeline, including diff based sync for pull requests. Translate: automatic translation drafts new keys with the glossary and style guide as context; translators and reviewers work in the editor. New keys arriving from the code and drafted in every target language by automatic translation, marked for review Publish: review proposals and needs review marks gate what goes live, versions and branches stage it, and automated checks run on every save. Deliver: approved translations are published to the CDN by default, with per version caching; the application loads them at runtime. How that looks in practice, with the comparison to a batch workflow and the teams that ship this way, is on the continuous localization page. The engineering view of the same transition, how a batch handoff breaks continuous deployment and what the wired in pipeline looks like, is in how batch translation workflows break continuous deployment. If you want to measure your own string to live time: create a project, connect one namespace, and time the next key from commit to every language. Frequently asked questions What is continuous localization? A translation workflow in which new and changed strings flow from the codebase to the people or systems that translate them automatically and continuously, in parallel with development, and approved translations are delivered to the running application without a release. It is the localization counterpart of continuous integration and continuous delivery. How is continuous localization different from traditional localization? In a batch workflow the strings wait: freeze, export, translate, import, redeploy. In continuous localization nothing waits for a cut: strings are detected as they are written, translated while development continues, gated by review rather than by a freeze, and delivered at runtime. The difference is where the strings sit between being written and being live. What do you need to implement continuous localization? Keys that originate in code, one place where translators, machine translation and AI work on them with context, a review and publish gate, and a delivery path that reaches the running application without a redeploy, usually a CDN. Versioning and corpus wide consistency checks are the two additions most teams need next. Does continuous localization mean AI translation without human review? No. Continuous describes the flow, not the quality policy. AI fills the first draft so nothing waits; what is published is decided by checks, a quality estimation score and human review where needed. Unreviewed machine output pushed straight to production is continuous and ungoverned. Is continuous localization worth it for a small team? When translation is a release dependency: several deploys a week, more than a handful of languages, non developers changing text, or fixes that must ship faster than the release cycle. A small team with two languages it reads itself can keep a batch process; runtime delivery is still usually worth having."},{"slug":"translation-glossary","title":"What is a translation glossary? Definition, examples, and how it is enforced","description":"A translation glossary is the list of terms a product must translate the same way every time, with the approved translation per language. What belongs in one (preferred, allowed and forbidden terms), how it differs from a style guide and from a translation memory, why machine and AI translation need it more than human translators do, how it is enforced with automated checks, how teams build one, and what it does not fix.","date":"2026-09-05","category":"Guides","thumbnail":"\/img\/blog\/translation-glossary\/thumbn
40ail.jpg","readTime":"10 min read","searchText":"title: 'What is a translation glossary? Definition, examples, and how it is enforced', description: 'A translation glossary is the list of terms a product must translate the same way every time, with the approved translation per language. What belongs in one (preferred, allowed and forbidden terms), how it differs from a style guide and from a translation memory, why machine and AI translation need it more than human translators do, how it is enforced with automated checks, how teams build one, and what it does not fix.', date: '2026 09 05', thumbnail: '\/img\/blog\/translation glossary\/thumbnail.jpg', image: '\/img\/blog\/translation glossary\/title.jpg', category: 'Guides', tags: ['glossary', 'terminology', 'termbase', 'localization', 'i18n', 'translation management', 'consistency', 'ai', 'machine translation', 'quality', 'tbx'], faq: [ q: 'What is a translation glossary?', a: 'A translation glossary (also called a termbase or terminology database) is a curated list of the terms a product must translate the same way every time, with the approved translation for each language and, where it matters, the variants that are allowed and the ones that are forbidden. It covers product and feature names, UI actions, legal and domain terms, and the words that must stay untranslated. It does not cover whole sentences, tone or grammar.' , q: 'What is the difference between a translation glossary and a translation memory?', a: 'A glossary stores terms: single words or short phrases with their approved translation per language, maintained by people who decide how the product speaks. A translation memory stores segments: sentences that were translated before, collected automatically as translation happens, and offered again when a similar sentence comes up. The glossary answers \"which word do we use for this concept\"; the memory answers \"have we translated this sentence before\". Most teams need both.' , q: 'What is the difference between a glossary and a style guide?', a: 'A glossary is a list of terms with their translations. A style guide is a set of rules about voice: tone, level of formality, target audience, and do and do not examples, usually per language. The glossary says the German word for subscription is Abo; the style guide says German addresses the user with the formal Sie. Both are inputs to translators, machine translation and AI, and neither replaces the other.' , q: 'Do I need a glossary for machine translation or AI translation?', a: 'More than for human translators. A translator remembers last month\\'s decisions; a model call does not, because every request starts without memory. A glossary is the mechanism that carries terminology decisions into the next request: its terms are injected into the translation prompt or applied as a lookup, and a forbidden term check catches the drift that still gets through. Without it, the same concept is rendered differently across batches and nobody notices until users see the screens side by side.' , q: 'How is a glossary enforced automatically?', a: 'As a check that runs on every saved translation, not as a document translators are asked to remember. Two findings cover it: the translation contains a term the glossary forbids, or the source text matches a glossary entry but the translation uses none of the approved terms for that language. A corpus wide consistency check complements this by surfacing terms that are translated inconsistently but are not in the glossary yet, which is exactly the list of what to add next.' , q: 'What file format is a translation glossary?', a: 'The exchange formats are TBX (TermBase eXchange, the ISO 30042 XML standard used by professional terminology systems) and UTX (a tab delimited format from AAMT). In practice many glossaries start as a spreadsheet with one row per concept and one column per language. A translation management system imports TBX or UTX, or lets you add terms directly, and keeps the glossary next to the translations it governs.' ] A translation glossary (also called a termbase or terminology database) is a curated list of the terms a product must translate the same way every time, with the approved translation for each language and, where it matters, the variants that are allowed and the ones that are forbidden. It covers the words that carry meaning for your users: product and feature names, UI actions, legal and domain terms, and the words that must stay untranslated. It does not cover sentences, tone or grammar; those belong to the translation memory and the style guide. This post is the definitional one: what an entry contains, how a glossary differs from the two things it is most often confused with, why machine and AI translation depend on it more than translators do, how it is enforced, and what it does not fix. Key facts One entry, one concept: the source term, the preferred translation per language, allowed alternatives, forbidden terms, and optionally a definition or usage note. \"Do not translate\" is a valid entry; product names live there. Glossary, style guide and translation memory are three different things: terms, rules of voice, and previously translated sentences. All three feed the same translator, the same model and the same agent. Machine and AI translation need it more than people do: every model request starts without memory, so the glossary is the only mechanism that carries a terminology decision into the next request. Enfor
40cement is a check, not a document: on every saved translation, a forbidden term or a missing approved term raises a finding; corpus wide consistency checks show which terms should be in the glossary but are not yet. What a glossary entry contains A glossary is a list of concepts, not a list of words, and that distinction decides whether it is useful. The entry for a concept like \"subscription\" holds: The source term as it appears in your product, ideally with a short definition or a usage note so that \"subscription\" the billing object is not confused with \"subscribe\" the newsletter action. The preferred translation per language. One term, the one the product uses everywhere: \"Abo\" in German, not \"Abonnement\", not \"Subskription\". Allowed alternatives , when a variant is acceptable in some contexts: a longer form for legal text, an abbreviation for a narrow button. Forbidden terms : the translations that were used at some point and must not come back, or a competitor's term, or a word that has a different meaning in your domain. Forbidden terms are what make a glossary enforceable, because \"use X\" is hard to check and \"never use Y\" is easy. Do not translate entries. Product names, brand names, trademarks and certain technical identifiers are glossary entries whose translation in every language equals the source. Without the entry, every translator and every model decides for themselves. A glossary of forty well chosen concepts is worth more than one of four hundred generic words. The concepts that belong in it are the ones where a wrong or inconsistent rendering costs something: money, trust, legal exposure, or a support ticket. Glossary, style guide, translation memory: three different things These are confused constantly, partly because a good translation tool shows all three next to the segment being translated. Glossary Style guide Translation memory Unit A term (word or short phrase) A rule (tone, formality, audience, do and do not) A segment (a sentence already translated) Written by People deciding how the product speaks People deciding how the brand sounds Nobody; collected automatically from past translations Answers Which word do we use for this concept? How do we address the user, in what register? Have we translated this sentence before? Changes when A product or domain term is introduced or renamed The brand voice changes Every time a translation is saved Enforced by Term checks on every save Injection into MT and AI prompts, human review Match suggestions with a similarity score The style guide tells the translator, the model or the agent that German uses the formal \"Sie\" and that the audience is developers; the glossary tells them that \"subscription\" is \"Abo\"; the translation memory tells them that \"Your subscription ends tomorrow\" was translated last year and how. Remove any one of the three and a specific class of defects returns. Why machine and AI translation need a glossary more than translators do A human translator who worked on your product last month remembers your product name, your German word for subscription and the fact that \"Open\" is a button. A machine translation engine or a language model does not, because each request starts without memory. Send the same source term in twelve batches over a year and you get several renderings, each defensible in isolation. Users see the screens side by side; the model never does. That makes the glossary the load bearing piece of any automated translation setup, in two distinct roles: 1. As an input. The relevant terms are applied to the request: injected into the AI prompt as \"use these exact translations\", or applied as a lookup by a machine translation engine that supports terminology. This is how last year's decision reaches this morning's batch. 2. As a check afterwards. Models paraphrase, engines ignore hints, and a forbidden term comes back anyway. A check that flags a forbidden term in a saved translation catches what the input did not prevent. The same logic applies to AI coding agents that draft translations inside a code change: the glossary has to be something the agent queries before drafting, not a document it may or may not have read. How a glossary is enforced A glossary that lives in a PDF is a wish. Enforcement means the glossary runs as a check where translations are saved, with findings attached to the segment: Forbidden term found. The translation contains a term the glossary forbids for that language. This is the high precision finding: there is no legitimate reason for the word to be there. Approved term missing. The source text matches a glossary entry, but the translation uses none of the approved terms for that language. Lower precision, because inflection and word order can hide a correct term, but it is the finding that catches a model quietly inventing its own rendering. Inconsistent translation of the same source value , corpus wide. Not strictly a glossary check, and that is the point: it finds the terms that are translated three different ways and are not in the glossary yet. The output of this check is the input to the next glossary review. Findings that reviewers can dismiss per segment, where a deviation is intentional, are what keep the checks switched on. A check without a scoped escape hatch gets disabled
40within weeks. The wider taxonomy of what automated checks catch, and the measured share of segments affected, is in what actually breaks in translations. How teams build and maintain glossaries today A spreadsheet. One row per concept, one column per language, shared with the agency. The most common starting point, and fine as a source; the problem is that it is not connected to anything, so enforcement is whoever remembers to open it. Term extraction from existing translations. Mining the corpus for recurring terms and, more usefully, for terms that are already translated inconsistently: those are the entries the glossary needs first. Tools can suggest candidates; a person approves them, because a glossary entry is a decision, not a statistic. A terminology exchange file. TBX (the ISO 30042 XML standard) and UTX (a tab delimited format from AAMT) move glossaries between translation tools and agencies; the TBX and UTX format reference covers both. A glossary inside the translation management system. Terms are shown to the translator next to the segment, injected into machine and AI translation, and checked on every save. This is the setup where the glossary stops being a document. The maintenance rule is the same everywhere: review the glossary whenever a product term is introduced or renamed, and whenever the consistency check surfaces a new disagreement. A glossary nobody updates is accurate about the product of two years ago. What a glossary does not solve Sentences. A glossary guarantees the term, not the sentence around it. Fluency, meaning and register are the job of the translator, the model with a style guide, and review. Ambiguity the entry did not anticipate. \"Open\" the verb and \"Open\" the status are two concepts; if the glossary has one entry, it enforces the wrong one somewhere. Entries need definitions, and the ambiguous cases need context or screenshots. Inflection and grammar. The German preferred term declines; a check has to tolerate \"Abos\" and \"Abonnements\" alike, and a naive exact match produces noise instead of findings. Quality of the decision itself. A glossary enforces consistency, not correctness. If the approved term is wrong, it is now wrong everywhere, consistently. That is still better than being wrong in three different ways, because one entry fixes it. How this works in Locize The glossary in Locize is a project level list of concepts with the preferred, allowed and forbidden terms per language. Building it. Import a TBX or UTX file, add terms by hand, or let Locize mine your existing translations: Scan for terms lists recurring terms across your keys, with the ones currently translated inconsistently first. Nothing is added automatically; you approve each candidate, pre filled with the translations already used in the project. Suggested glossary terms in Locize: recurring terms mined from the project, inconsistently translated ones listed first Using it. In the editor, every segment shows the matching glossary terms next to the translation, with the approved usage and the alternatives. The same terms are injected into automatic translation, bulk machine and AI translation and the AI assistant, together with the style guide, and exposed to AI coding agents through the MCP server's tool, described in the context tools post. The glossary panel in the Locize editor next to a segment, with the approved term and the translation memory match Enforcing it. Terms are checked every time a translation is updated: a forbidden term raises issue 230, a matched source term without an approved target term raises issue 231, both documented under glossary consistency checks. The corpus wide consistency check for the same source value translated differently runs on demand, for one segment or the whole project, and its findings are the shortlist for the next scan. If you want to know which terms your project is already translating inconsistently: create a project, import your translation files, open the glossary and click Scan for terms. The first list is usually longer than expected, and shorter than it will be next year. Frequently asked questions What is a translation glossary? A curated list of the terms a product must translate the same way every time, with the approved translation for each language and, where it matters, allowed variants and forbidden terms. It covers product and feature names, UI actions, legal and domain terms, and words that must stay untranslated; not sentences, tone or grammar. What is the difference between a translation glossary and a translation memory? A glossary stores terms with their approved translation, decided by people. A translation memory stores sentences translated before, collected automatically, and offers them again when a similar sentence comes up. The glossary answers \"which w
40ord do we use for this concept\"; the memory answers \"have we translated this sentence before\". What is the difference between a glossary and a style guide? A glossary lists terms and their translations. A style guide sets the rules of voice: tone, formality, audience, do and do not examples, per language. The glossary says subscription is \"Abo\" in German; the style guide says German addresses the user as \"Sie\". Neither replaces the other. Do I need a glossary for machine translation or AI translation? More than for human translators. A model request starts without memory, so the glossary is what carries terminology decisions into the next request, as injected terms and as a forbidden term check afterwards. Without it the same concept is rendered differently across batches. How is a glossary enforced automatically? As a check on every saved translation: a forbidden term in the translation, or a matched source term with none of the approved target terms, raises a finding on the segment. A corpus wide consistency check surfaces the terms that are not in the glossary yet. What file format is a translation glossary? TBX (ISO 30042 XML) and UTX (tab delimited, from AAMT) are the exchange formats; many glossaries start as a spreadsheet with one row per concept. A translation management system imports TBX or UTX or lets you add terms directly."},{"slug":"coding-agents-translation","title":"When coding agents translate your app: what breaks, what to keep","description":"AI coding agents now add translation keys and draft the translated strings as part of a code change, with more context than most translators ever get. What they do well, what does not carry over time (consistency across releases, review and provenance, terminology governance, QA over the whole corpus), how teams handle it today, and the agent-in-the-loop pattern that keeps the speed without losing the record.","date":"2026-09-03","category":"Guides","thumbnail":"\/img\/blog\/coding-agents-translation\/thumbnail.jpg","readTime":"11 min read","searchText":"title: 'When coding agents translate your app: what breaks, what to keep', description: 'AI coding agents now add translation keys and draft the translated strings as part of a code change, with more context than most translators ever get. What they do well, what does not carry over time (consistency across releases, review and provenance, terminology governance, QA over the whole corpus), how teams handle it today, and the agent in the loop pattern that keeps the speed without losing the record.', date: '2026 09 03', thumbnail: '\/img\/blog\/coding agents translation\/thumbnail.jpg', image: '\/img\/blog\/coding agents translation\/title.jpg', category: 'Guides', tags: ['ai', 'coding agents', 'agents', 'localization', 'i18n', 'translation management', 'mcp', 'review', 'glossary', 'eu ai act', 'workflow', 'i18next'], faq: [ q: 'Can AI coding agents translate an app?', a: 'Yes, and for a single change they often do it well: an agent that reads the codebase sees the component, the placeholder types, the adjacent copy and the git history, which is more context than most translators receive. What it does not carry over time is consistency across releases, a record of who approved what, terminology that was decided outside the current session, and quality checks over the whole corpus. The agent is a good drafter; the drafts need a system behind them.' , q: 'What breaks when a coding agent edits translation files directly?', a: 'Nothing visible in the pull request, which is the problem. Each run is stateless, so the same concept is rendered differently across releases, formality flips between screens, plural forms for languages with more than two forms are guessed inconsistently, and the only record of any translation decision is a commit by a bot. Automated checks that compare a translation with its source and with the rest of the language are not run on a diff, so structural defects and terminology drift accumulate unnoticed.' , q: 'What is the agent in the loop pattern for translation?', a: 'The agent stays the drafter, but drafts through the translation management system instead of into files: before writing it fetches the glossary, the style guide and matching translation memory entries; it reports new keys and pushes its translations declared as AI output, which places them in the review queue; a person with competence in the language confirms or edits each value in the editor; the decision is recorded in the history. The agent keeps the speed, the system keeps the consistency, the review and the record.' , q: 'Does the EU AI Act apply to translations drafted by a coding agent?', a: 'Article 50 of the EU AI Act applies since August 2, 2026. Under the European Commission\\'s final guidelines of July 20, 2026, a faithful AI translation is treated as standard editing and is exempt from the machine readable marking duty of Article 50(2). The visible disclosure duty of Article 50(4) only covers text published to inform the public on matters of public interest, and it falls away where the text has undergone human review or editorial control with a person holding editorial responsibility. For agent drafted strings that means: a documented review step is the exemption path. This is not legal advice; consult a lawyer for your own obligations.' , q: 'How do I make my coding agent use the glossary and style guide?', a: 'Give the agent tools instead of pasting documents into the prompt. Over the Locize MCP server it can call get glossary, get styleguide and search translation memory before drafting and get screenshot context for ambiguous strings; convention files (CLAUDE.md, AGENTS.md, .cursorrules) in the public locize agents repository make it do so by default. For projects that are not connected yet, i18next cli init agent note writes a short note into AGENTS.md so the next agent session knows the i18n setup and asks before wiring anything.' ] Agent assisted translation is the practice of letting an AI coding agent, the assistant that already reads and edits your codebase, add translation keys and draft the translated strings as part of a code change, instead of handing the strings to a separate translation step afterwards. It is fast, cheap, and for a single pull request often good. The problems are not in that pull request. They are in the twelfth one. This post is a category piece, not a comparison. It is about what agents genuinely do well, what does not carry from one release to the next, and the pattern that keeps the speed without losing the record. Key facts Agents with codebase context draft well: they see the component, the placeholder types, the adjacent copy and the git history, which is more context than most translators ever receive. What an agent does not carry over time: consistency across releases (every run is stateless), review and provenance (who approved what), terminology governance (a glossary it did not write and will not remember), and QA over the whole corpus rather than the diff. The failure mode is variance, not average quality: run twelve disagrees with run one, and n
40obody notices until users see the screens side by side. The agent in the loop pattern keeps the agent as the drafter and moves consistency, review and history into the translation management system it drafts through. What agents are actually good at The honest version starts with the strengths, because they are real. A coding agent asked to add a settings screen in six languages has, at the moment it writes the German label, more context than a translator receiving a spreadsheet: it knows the component is a button, that is a number and not a name, what the neighbouring strings say, what the previous developer named similar keys, and whether the value is interpolated into a sentence. It writes the key, the default value and the translations in one pass, with no handoff, no export and no waiting. It is also good at the plumbing that used to block localization entirely. Agents wire up an i18n library, wrap hardcoded strings, extract keys and run the sync command, and they do it for the side feature that no team would have budgeted a translation round for. Features that used to ship English only now ship in every language the project has. That is not a small thing, and no critique of agent translation should pretend it is. What breaks over time Everything below is invisible in a single pull request. It shows up across pull requests, which is why teams discover it late. Consistency across releases Each agent run starts from an empty context. Nothing in the session remembers that the product name stays untranslated, that \"subscription\" became \"Abo\" and not \"Abonnement\" in German three releases ago, or that the Spanish uses \"tú\" and not \"usted\". The agent picks a rendering that is defensible in isolation, and a different defensible rendering next month. Formality is the nastiest case: in languages where the distinction is grammatical, one screen addressing the user formally and the next one casually reads as broken, not as a style choice. Review and provenance When a customer, a lawyer or an auditor asks why the app said what it said in Italian, a pipeline of agent edited files has one answer: a commit by a bot, approved by a reviewer who could not read Italian and checked the diff for syntax. There is no reviewer of record, no decision trail per string, and no way to tell an agent's guess from a translator's choice once both sit in the same file. Since August 2, 2026 this is also a regulatory question: Article 50 of the EU AI Act applies, and under the Commission's final guidelines a faithful AI translation is exempt from machine readable marking, while text that informs the public on matters of public interest needs a visible disclosure unless it went through documented human review with a person holding editorial responsibility. The legal detail is in the Article 50 explainer; the practical consequence is that \"reviewed\" has to be something you can show, per segment, and a review workflow is what produces that evidence. None of this is legal advice. Terminology governance The glossary exists, usually as a document. The agent may or may not read it, may read it in one session and not the next, and cannot know that a term was added after its last run. Forbidden terms come back. Product names get translated. The fix that gets suggested, \"put the glossary in the agent's instructions\", works until the glossary has four hundred entries and the instructions have to cover everything else as well. Terminology is a data problem, and data that has to be remembered by a stateless process is not governed, it is hoped for. The glossary belongs in a system the agent can query, not in a prompt. QA over the corpus, not the diff An agent checks the strings it touched. The defects that actually reach production are cross key: the same source value translated three different ways across namespaces, a placeholder present in eleven languages and dropped in the twelfth, a number that changed on the way. Those are found by comparing every value of a language against its source and against the rest of that language, on every save, which no pull request review does. The taxonomy and how automated checks catch it is in what actually breaks in translations. Plurals, placeholders and the strings that carry risk Languages with more than two plural forms (Polish, Arabic, Russian) need forms the English source does not have. Agents produce them correctly in isolation and inconsistently in bulk, and a wrong key is a runtime bug, not a style issue. Then there are the strings where \"the model is usually right\" is not an acceptable bar: legal notices, pricing terms, medical and safety wording, accessibility labels. An agent treats them like any other string, because in the diff they look like any other string. How teams handle coding agent translation today Four setups cover most of what we see, and the honest note is that the first one is right for some teams. The agent edits the locale files in the pull request. Fastest, cheapest, and fine while the people on the team can read every language and nothing depends on the copy. The drift described above starts on day one and becomes visible around the tenth release. The agent plus an LLM in CI step. The agent adds the keys, a workflow on push machine translates the missing values. Removes the manual part entirely, and reproduces the same failure modes at pipeline speed: unreviewed output, no memory between runs, no terminology enforcement. The graduation path out of that setup is in when AI translations break. The agent drafts, a person reviews the diff. Better in spirit, weak in practice: a pull request reviewer sees twelve language files and can judge one or tw
40o of them. The review is real for the languages the reviewer reads and theatre for the rest. The agent drafts through a translation management system. The agent keeps doing the drafting, but the terminology, the memory of past decisions, the review queue and the history live in the system, and the agent reads from and writes to it. This is the pattern the rest of this post describes. The agent in the loop pattern: what to keep Whatever tooling you use, the pattern has five rules. 1. Terminology and voice come from the system, not the prompt. Before the agent drafts a string, it fetches the project's glossary (preferred, allowed and forbidden terms per language) and the style guide (tone, formality, audience). The instructions say \"look these up\", not \"here are four hundred terms\". 2. Reuse before invention. A translation memory lookup for similar source strings comes first. A high score match is reused, which is how the twelfth release stays consistent with the first one. 3. Provenance is declared, not inferred. The agent's output is pushed as AI output, which puts it in the review queue instead of in production. A person's edit is pushed as a person's edit. Once both are in the same file with no marker, the distinction is gone for good. 4. Review is per segment, by someone who reads the language, and recorded. Not a pull request approval, not a spot check of two languages: a reviewer confirms or edits each value in an editor that shows the source, the context and the glossary, and the decision is written to the history with their name and the time. 5. Checks run over the corpus after the merge, not only over the diff before it. Consistency, placeholders, numbers, tags: the checks that compare against the whole language have to run where the whole language is. What this does not solve Someone still has to read Polish. The pattern makes review cheap and targeted; it does not make it disappear. Quality estimation can route the confident drafts through and hold the doubtful ones, but the decision on a doubtful string is human work. The source text is agent written too. Agents write the English as well as the German, and English strings drift in terminology exactly like translations do. A forbidden term lint on new source strings catches part of it; a writer catches the rest. Risk strings are still a policy question. Which strings need a person regardless of confidence, which content falls under public interest disclosure, and who holds editorial responsibility for a publication are decisions a tool records but does not make. Small projects can skip all of it. Two languages the team reads, no revenue or compliance on the copy: let the agent edit the files. The signal to change is the first language nobody on the team reads. How this works in Locize Locize exposes the system side of the pattern to agents through its MCP server, reachable at from Claude, Cursor, GitHub Copilot and other MCP clients, with 28 tools in total. Agent driven translate loops (find the missing keys, fetch the source, push drafts, read the review queue) are a visible and steadily growing share of the traffic on that server. Context before drafting. returns preferred, allowed and forbidden terms per language; returns tone, formality, audience and usage rules; finds prior translations of similar source strings, exact and fuzzy; shows where an ambiguous key appears. All four are read only, and the context tools post walks through them. Drafts land in review, not in production. creates new keys without overwriting existing ones (and triggers automatic translation where it is enabled). takes a of for texts the agent generated or for a person's text; AI values are marked as needing review according to the project's rule (always, or only when the quality estimation score is below the threshold), and and with let the agent read the queue it just filled. A person decides, and the history says who. Reviewers confirm, edit or decline in the editor; the review workflow records every decision, and the provenance export described in the Article 50 workflow guide packages it as CSV and JSON. The needs review queue in the Locize editor: marked values and pending proposals, confirmed per value by a reviewer Defaults, so nobody has to remember the rules. The public locize agents repository holds convention files ( , , ) that make an agent fetch glossary, style guide and memory before translating and lint pull requests for forbidden terms. For projects that are not connected yet, (i18next cli 1.73 or newer) appends a short internationalization note to , so the next agent session knows where the locale files live, which commands to run, and that it should ask before wiring up a translation service. The agent keeps its speed. What changes is that its drafts arrive somewhere with a memory, a reviewer and a record. If your agent is already translating, create a project, connect the MCP server, and let the next pull request draft through it; the review queue will show you what the previous ones would have shipped. Frequently asked questions Can AI coding agents translate an app? Yes, and for a single change they often do it well: with the codebase in context an agent sees the component, the placeholder types, the adjacent copy and the git history. What it does not carry over time is consistency across releases, a record of who approved what, terminology decided outside the current session, and quality checks over the whole corpus. The agent is a good drafter; the drafts need a system behind them. What breaks when a coding agent edits translation files directly? Nothing visible in the pull request. Across pull requests, the same concept is rendered differently, formality flips between screens, plural forms for languages with more than two forms are guessed inconsistently, and the only record of any decision is a commit by a bot. Checks that compare a translation with its source and with the rest of the language are not run on a diff, so defects accumulate unnoticed. What is the agent in the loop pattern for translation? The agent stays the drafter but drafts through the translation management system: it fetches the glossary, the style guide and matching translation memory entries before writing, reports new keys and pushes its translations declared as AI output, which places them in the review queue; a person who reads the language confirms or edits each value, and the decision is recorded. Does the EU AI Act apply to translations drafted by a coding agent? Article 50 applies since August 2, 2026. Under the Commission's final guidelines of July 20, 2026, a faithful AI translation is exempt from machine readable marking; the visible disclosure duty only covers text published to inform the public on matters of public interest and falls away with documented human review under a person holding editorial responsibility. A recorded review step is the exemption path. This is not legal advice. How do I make my coding agent use the glossary and style guide? Give it tools instead of documents: over the Locize MCP server it calls get glossary, get styleguide and search translation memory before drafting, and get screenshot context for ambiguous strings; the convention files in the locize agents repository make that the default. For projects not connected yet, i18next cli init agent note leaves a note in AGENTS.md so the next agent session knows the setup and asks before wiring anything."},{"slug":"translation-files-without-manual-json-editing","title":"Managing translation files without manual JSON editing","description":"Nobody decides to hand-edit translation files; teams end up there. What translation file management means, why JSON, YAML and resx files turn into merge conflicts, drift and keys nobody owns, how teams handle it today (code editors, spreadsheets, CI sync, a TMS, coding agents), what removing the manual editing does not solve, and where Locize fits.","date":"2026-09-01","category":"Guides","thumbnail":"\/img\/blog\/translation-files-without-manual-json-editing\/thumbnail.jpg","readTime":"11 min read","searchText":"title: 'Managing translation files without manual JSON editing', description: 'Nobody decides to hand edit translation files; teams end up there. What translation file management means, why JSON, YAML and resx files turn into merge conflicts, drift and keys nobody owns, how teams handle it today (code editors, spreadsheets, CI sync, a TMS, coding agents), what removing the manual editing does not solve, and where Locize fits.', date: '2026 09 01', thumbnail: '\/img\/blog\/translation files without manual json editing\/thumbnail.jpg', image: '\/img\/blog\/translation files without manual json editing\/title.jpg', category: 'Guides', tags: ['translation files', 'json', 'i18n', 'localization', 'translation management', 'workflow', 'ci cd', 'i18next', 'developer experience', 'yaml', 'resx'], faq: [ q: 'How do I manage translation files without editing JSON by hand?', a: 'Make the files an output of the workflow instead of its user interface. Keys are created from the code, either by extraction in CI or by runtime reporting such as the i18next saveMissing option. Translators work in an editor that shows them the source text, the placeholders and the terminology. The JSON, YAML or resx files are then generated from that editor by a sync or download step, or replaced entirely by CDN delivery. Developers keep writing keys in code; nobody opens a locale file to type a translation.' , q: 'Should translators edit JSON files directly?', a: 'No. A translation file is a build input with strict syntax: a trailing comma, a single quote or an unescaped quotation mark makes the whole file invalid, and an invali
40d file typically fails silently at runtime. Translators also cannot see where a string appears, what a placeholder stands for or how the same term was translated elsewhere. Give them an editor and let the file be generated from it.' , q: 'What is the difference between key extraction and saveMissing?', a: 'Extraction scans the source code for translation calls and writes the keys it finds into files, usually in CI or before a commit; it is deterministic and works without running the application. saveMissing is an i18next runtime option: when the running application asks for a key that does not exist yet, the key is reported to the translation management system together with its default value, so keys appear while developers build the screen. Many teams use both: saveMissing during development, extraction as the check in CI.' , q: 'Do I still need translation files in my repository?', a: 'Only if your build needs them. With CDN delivery the application loads translations at runtime and the repository holds no locale files at all; a fix published in the editor is live without a commit or a deploy. Teams that need files for server side rendering, offline bundles or a static build download them in CI as generated artifacts, committed or ignored, but never edited by hand.' , q: 'Can AI coding agents manage translation files for me?', a: 'They can write and edit the files, which removes the typing but not the drift. An agent that edits twelve language files still produces text nobody reviewed, terminology that varies from one run to the next, and no record of who approved what. Agents work best as contributors to a managed workflow: they report new keys and draft translations, while consistency, review and history live in the translation management system.' ] Translation file management is the practice of keeping the files an application loads its translations from (JSON, YAML, , , and similar formats) complete, valid and in sync with the code that uses them, without developers or translators editing those files by hand. In most setups the files still exist. What changes is their role: they become an output of the translation workflow instead of its user interface. This post is about how teams end up hand editing translation files, what breaks when they do, what the alternatives actually look like, and what switching does not fix. Key facts A translation file is a build input, not a document: one trailing comma or unescaped quote makes it invalid, and an invalid file typically fails silently at runtime. Manual editing scales badly on two axes at once: the number of languages and the number of people who need to change text. One developer with two languages is fine; a translator in a pull request is not. What breaks: merge conflicts on locale files, drift between files and code (missing and orphaned keys), keys nobody owns, a deploy for every typo, and terminology that varies between files with no view across them. What removes the editing: keys that originate in code (extraction or runtime reporting), an editor for the people who write text, and files that are generated by a sync step or replaced by CDN delivery. Coding agents can contribute drafts; they do not replace that layer. Why teams end up hand editing translation files Nobody chooses this as a strategy. It starts as the obviously correct decision: i18next, react intl, vue i18n and their peers load a JSON file per language, so the first developer creates , adds , and edits both in the code editor. Nested or flat keys, placeholders, and plural suffixes: with one person and two languages, editing the file is the translation tool, and a good one. Then the users of that tool change while the tool stays. A third language arrives with a colleague who speaks it. A product manager wants to fix a label before the demo. An agency translator delivers Polish. Each of them is handed the same thing the first developer had: a file with strict syntax, no context, and a git workflow around it. The setup did not get worse. The people using it stopped being developers. The format itself adds traps that are invisible until they fire. JSON allows no trailing commas, no single quotes and no unescaped quotation marks inside strings. Plural forms are encoded as key suffixes that differ between the i18next JSON v3 and v4 conventions (the JSON format reference covers both). A placeholder renamed in one language renders literally on screen. And because the file is loaded at runtime, a syntax error does not fail the build; it fails the page, for the users of that language, after the deploy. What breaks Merge c
40onflicts on the most boring file in the repository Two feature branches each add keys to . JSON has no merge semantics: the conflict lands on the closing brace, someone resolves it by hand, and one branch's keys quietly disappear. Locale files are the file type with the highest conflict rate in many front end repositories, precisely because every feature touches them and nobody feels ownership of them. Drift between files and code Code references keys that no file contains, so the UI shows the key name or the English fallback. Files contain keys no code references anymore, so translators keep translating dead strings. The English file was updated, the German one was not, and nothing marks the German value as stale. Over a year the language files diverge structurally, and the only way to find out is to diff them by hand. Translators in git The moment a translator edits a file, the workflow demands a pull request. The reviewer cannot judge the Polish, so they review the diff for syntax. The translator cannot see where the string appears, what will contain or whether the button is wide enough. In practice the fix travels as a chat message that a developer pastes into the file, which is manual editing with an extra hop. Keys nobody owns Key naming is decided per pull request. , and coexist and nobody knows whether they are meant to differ. Renaming a key means touching every language file. Deleting one means hoping no screen still uses it. The file has no notion of who created a key, when, or why. A deploy for every typo In a file based setup a translation change is a code change: commit, build, deploy. A wrong label in Italian rides the next release train unless someone hotfixes production for a string. Teams learn to batch translation fixes, which is a polite name for leaving them broken for a while. Consistency across files is invisible The same source term is translated three different ways across namespaces, and no file level tool can show you, because the disagreement lives across files, not inside one. This is the most widespread defect class in real translation data, and the one manual review is worst at catching; the numbers are in what actually breaks in translations. How teams manage translation files today Most teams sit in one of five setups, and the honest picture is that each of them is right for someone. A code editor and conventions. VS Code with JSON validation and an extension such as i18n Ally that shows translation status per language. Works for a solo developer or a small team where everyone who edits text can read the format. Stops working the day a non developer needs to change a string. If this is where you are, the FAQ on opening and editing JSON files is the pragmatic guide. Spreadsheet round trips. Export the file to a sheet, send it to translators, import the result with a script. Familiar for translators, and a snapshot problem for everyone else: the sheet and the file diverge while the translation is out, and the merge back is manual again. Scripts and CI sync. A tool extracts keys from the source (for i18next, ), a script or a GitHub Action pushes them to a service and pulls the translated files back, optionally with machine or AI translation in between. This keeps the files generated and the developers away from them. It still needs an editor on the other side for the humans who review and correct, and it does not answer the ownership and consistency questions by itself. A translation management system. Keys arrive from code, translators work in an editor with context and terminology, files are exported or synced in the formats the build expects, or delivered over a CDN so the build stops needing them. This is the setup the other four grow into once more than one person writes text. Coding agents editing the files. The newest option: an agent adds the key to all twelve language files, drafts the translations and opens the pull request. It is genuinely good at the mechanical part. It also reintroduces the original problem at higher speed: text nobody reviewed, terminology that varies between runs, and no record beyond a commit by a bot. What fails in AI only pipelines, and the graduation path out of them, is covered in when AI translations break. What actually removes the manual editing Tool choice aside, four properties separate a workflow where nobody edits translation files from one where somebody still does. 1. Keys originate in code, not in files. Either a static extraction step reads the translation calls, or the running application reports a key the first time it is used. Both mean a developer never opens a locale file to add an entry. 2. The people who write text get an editor. Source text, placeholders, screenshots, the glossary, the history of the key, all languages side by side. A translator who can see the button does not need to guess its width. 3. Files are generated or gone. Either a sync or download step writes the files in the format the build expects, preserving structure and plural forms on the round trip, or the application loads translations at runtime and the repository contains
40no locale files at all. Diff based sync matters here: a pull request should translate only the keys it added, not re push the whole project. 4. Every change has an owner and a record. Who added the key, who translated it, who approved it, when it was published. A file has none of that; a pull request has a fraction of it. What this does not solve Removing file editing removes a chore. It does not remove the actual hard parts of localization, and a workflow change should not be sold as if it did. Key strategy is still yours. Natural language keys versus stable identifiers, namespaces per feature or per page: a tool moves the keys, it does not design them. The trade offs are in the guide to i18n key naming. Ambiguity still needs a human to notice. \"Open\" as a verb and \"Open\" as a status may need two translations; no sync step spots that. Context features and screenshots help the translator once someone has flagged the case. Quality is a separate layer. Terminology that must not drift, formality that must not flip mid app, and the question of who approved a translation are handled by a glossary, a review workflow and automated QA checks, not by where the files live. Sometimes the file is the right tool. One developer, two languages they can read, no revenue depending on the copy: a code editor is the cheapest correct setup. The upgrade signal is the second person who needs to change text. How this works in Locize Locize is built around the four properties above, for the i18next ecosystem first and for other formats through the CLI. Keys from code. With i18next locize backend and (gated to development, so production stays read only), every key the application renders for the first time is created in the project with its default value; locizify does the same for static sites with one script tag. Prefer a static pipeline? followed by , or for JSON, YAML, XLIFF, CSV, PO, RESX, Fluent, Properties and other formats, as described in the CLI documentation. An editor for everyone who writes text. The CAT view shows all languages of a key side by side, with filters for untranslated and needs review values, bulk actions, import and export in the supported formats, and a history per key that records who changed what and when. The Locize translation editor: all languages of a key side by side, with filters, bulk actions and the AI assistant Files generated, or none at all. and the GitHub Actions write the files your build expects; restricts a pull request to the keys it actually changed (locize cli 12.7 or newer, i18next cli 1.72 or newer). Or skip the files: translations are published to the CDN by default, and the application loads them at runtime, so a fix goes live without a commit or a redeploy. First drafts without a file either. New keys in the reference language are translated into every target language by automatic translation, with the project glossary and style guide injected into the request, and marked as needing review so a person confirms them in the editor rather than in a diff. The JSON file does not disappear from your life; it stops being the place where translation happens. If you want to see the difference on your own project, create a project, import the files you have today, and watch the next key arrive from your code instead of from your keyboard. Frequently asked questions How do I manage translation files without editing JSON by hand? Make the files an output of the workflow instead of its user interface. Keys are created from the code, by extraction in CI or by runtime reporting such as i18next's saveMissing option; translators work in an editor with source text, placeholders and terminology in front of them; the JSON, YAML or resx files are generated by a sync or download step, or replaced by CDN delivery. Should translators edit JSON files directly? No. A translation file is a build input with strict syntax, and an invalid file typically fails silently at runtime. Translators also cannot see where a string appears, what a placeholder stands for or how the term was translated elsewhere. Give them an editor and let the file be generated from it. What is the difference between key extraction and saveMissing? Extraction scans the source code for translation calls and writes the keys into files, deterministically and without running the application. saveMissing reports a missing key from the running application the first time it is used, together with its default value. Many teams use saveMissing during development and extraction as the check in CI. Do I still need translation files in my repository? Only if your build needs them. With CDN delivery the repository holds no locale files at all and a fix published in the editor is live without a deploy. Teams that need files for server side rendering or static builds download them in CI as generated artifacts, never edited by hand. Can AI coding agents manage translation files for me? They can write and edit the files, which removes the typing but not the drift: unreviewed text, terminology that varies between runs, no record of who approved what. Agents work best as contributors to a managed workflow, reporting new keys and drafting translations, while consistency, review and history live in the translation management system."},{"slug":"translation-qa-checks","title":"Translation QA: What Actually Breaks in Translations, and How to Catch It Automatically","de
40scription":"Most translation defects are not bad language, they are mechanical: a dropped placeholder, a broken HTML tag, a number that changed, the same term translated three different ways. What translation QA means, which errors appear in real translation data, what manual review keeps missing, and how automated linguistic checks catch the mechanical layer so human reviewers can focus on meaning.","date":"2026-08-28","category":"Guides","thumbnail":"\/img\/blog\/translation-qa-checks\/thumbnail.jpg","readTime":"8 min read","searchText":"title: 'Translation QA: What Actually Breaks in Translations, and How to Catch It Automatically', description: 'Most translation defects are not bad language, they are mechanical: a dropped placeholder, a broken HTML tag, a number that changed, the same term translated three different ways. What translation QA means, which errors appear in real translation data, what manual review keeps missing, and how automated linguistic checks catch the mechanical layer so human reviewers can focus on meaning.', date: '2026 08 28', thumbnail: '\/img\/blog\/translation qa checks\/thumbnail.jpg', image: '\/img\/blog\/translation qa checks\/title.jpg', category: 'Guides', tags: ['translation qa', 'linguistic qa', 'quality assurance', 'qa checks', 'localization', 'i18n', 'review', 'consistency', 'translation management', 'quality'], faq: [ q: 'What is translation QA?', a: 'Translation QA (quality assurance) is the practice of checking translated content for defects before it reaches users. It covers two layers: mechanical correctness (placeholders, HTML tags, numbers, punctuation, whitespace, consistent terminology) and linguistic quality (meaning, tone, fluency). The mechanical layer can be checked automatically and continuously; the linguistic layer needs human judgment or model based scoring.' , q: 'What are the most common errors in translations?', a: 'In real translation data the frequent defects are mechanical: interpolation placeholders or HTML tags that were changed or dropped, numbers that differ from the source, missing terminal punctuation, doubled or missing whitespace around concatenated values, repeated words, and the same source term translated inconsistently across keys. Outright mistranslation happens too, but it is rarer than the mechanical class and harder to detect automatically.' , q: 'Can translation QA be automated?', a: 'The mechanical layer can: checks for placeholders, tags, numbers, brackets, punctuation, casing, whitespace and cross key consistency run deterministically on every value, in every language, on every save. The judgment layer (is this translation accurate and appropriate?) cannot be fully automated; machine translation quality estimation (QE) can score it, and human review decides. A working QA setup combines both: automated checks filter the mechanical noise so reviewers spend their time on meaning.' , q: 'What is the difference between translation QA and quality estimation (QE)?', a: 'QA checks are deterministic rules that compare a translation against its source and against the rest of the corpus: they find structural defects and inconsistencies, and the same input always produces the same finding. Quality estimation is a model based score that predicts how good a (usually machine generated) translation is, without a reference. QE tells you which new translations deserve human attention; QA checks tell you which existing translations are structurally broken.' , q: 'Do automated checks replace human review?', a: 'No. Automated checks catch the mechanical layer: what is objectively comparable between source and translation. Whether the tone fits your brand, whether the terminology matches your domain, and whether the sentence actually means the right thing remains a human call (supported by glossaries, style guides and review workflows). The value of automation is that reviewers stop burning attention on missing brackets and doubled spaces.' ] Translation QA (translation quality assurance) is the practice of checking translated content for defects before it reaches users. It has two layers: the mechanical layer , everything that can be objectively compared between a source text and its translation (placeholders, HTML tags, numbers, punctuation, whitespace, terminology consistency), and the judgment layer , whether the translation actually says the right thing in the right tone. The first layer can be automated completely. The second cannot, and pretending otherwise is how broken releases ship. This post is about the first layer: what actually breaks in real translation data, why manual review keeps missing it, and what automated linguistic checks can and cannot do about it. Key facts Most translation defects are mechanical, not linguistic: changed placeholders, broken tags, differing numbers, dropped punctuation, whitespace damage, inconsistent terms. Measured across projects on Locize (August 2026): roughly 2.3% of translated segments trip at least one mechanical check, and 87% of sampled projects contain at least one inconsistently translated term. Mechanical defects are language aware: a correct check must know that German capitalizes nouns, Spanish opens questions with ¿, French counts a non breaking space before a colon as correct, and \"9pm\" may legitimately become \"21 Uhr\". Automated checks and human review split the work: checks catch what is comparable, reviewers judge what is not. QE
40scoring sits in between for machine generated translations. What actually breaks in translations Ask people what a translation error looks like and they describe a mistranslation: a sentence that says the wrong thing. Look into real translation data of software products and you find something less glamorous. The defects that reach production are overwhelmingly structural , and they cluster into a small taxonomy. Placeholders and markup The most damaging class. An interpolation placeholder like that a translator (or a machine) renamed, translated, or dropped does not render as slightly wrong text, it renders as a literal on screen, or crashes the formatter. The same goes for HTML and component tags: react i18next's component markers, a that lost its closing tag, a link that disappeared in one language. A broken tag usually renders as raw text for exactly the users who read that language, and for nobody in the office. Numbers A number that appears in the source and not in the translation (\"30 days\" translated as \"days\") changes meaning silently. The subtlety is that numbers legitimately change shape across locales: locale digit formats, Eastern Arabic and fullwidth digits, and 12 hour to 24 hour time conversions (\"9pm\" becoming \"21 Uhr\") are all correct. A useful check has to treat those as equal and still flag the genuinely missing quantity. Punctuation, casing, brackets A dropped trailing colon breaks a label that the UI concatenates with a value. A question mark that vanished turns a confirmation prompt into a statement. Spanish expects the inverted ¿ when a sentence ends in a question mark. Brackets are their own category: a translation with counts that differ from the source, or an unclosed bracket the source does not have, is usually a truncated or half edited value. And first letter casing differs legitimately between languages (German capitalizes nouns; headline fragments differ per language), so a naive comparison produces noise instead of findings. Whitespace Invisible and therefore popular: doubled spaces inside a value, or leading and trailing spaces that differ from the source. Trailing whitespace matters the moment your application concatenates translated fragments. French typography adds a twist, since a non breaking space before punctuation is correct French and must not be counted as a defect. Repetition \"The the\" happens in every language, usually as an editing leftover. The catch is that some doublings are grammatically correct: French reflexive constructions (\"nous nous retrouvons\"), German article sequences. A check that does not know this floods reviewers with false positives until they turn it off. Inconsistent terminology The quietest one, and in our data the most widespread: the same source value translated differently across keys. One \"Save\" button says \"Speichern\", another says \"Sparen\". A term is rarely translated wrong everywhere, but it is often translated wrong somewhere , and those disagreements are where mistranslations hide. This is not a per value check; it needs the whole corpus of a language to detect. Dangerous markup The security tail of the same problem: translation values are content that your application renders. A value containing , an handler or a URL is not a quality problem, it is an injection vector, because translator accounts and write scoped API keys are part of your attack surface whether you think of them that way or not. How common is this really? Measured across projects on Locize in August 2026: roughly 2.3% of translated segments trip at least one of the mechanical checks above, with whitespace, terminal punctuation and number mismatches leading the distribution. Cross key consistency is broader still: about 3.9% of segments have at least one sibling key translating the same source value differently, and 87% of sampled projects contain at least one such disagreement. One in forty segments sounds small until you multiply it by a product with twenty thousand segments in eight languages. It also concentrates in exactly the content that changed recently, which is the content your next release ships. How teams handle translation QA today Most teams that take translation quality seriously do some combination of the following: A human review pass per language, either by a second translator, an in country colleague, or an agency LQA round. This is the right tool for meaning and tone, and the wrong tool for placeholders: humans skim past mechanical detail, and a reviewer who checks 4,000 strings for bracket counts stops being a linguist and starts being a very expensive regex. Spreadsheet spot checks : export, filter, eyeball. Catches what you happen to look at, on the day you look.
40Custom scripts in CI : a repository of regexes that someone wrote in an afternoon, catching missing interpolations in one file format, in the languages the author thought of. Useful, unmaintained, and blind to everything cross key (consistency) and everything locale specific (the ¿, the nbsp, the noun capitalization). Style guides and glossaries as documents : correct terminology lives in a PDF that reviewers are supposed to remember while the actual corpus drifts. The pattern across all four: the mechanical layer is checked occasionally and partially , by people or scripts that were built for something else. The defects, meanwhile, enter continuously, with every new key, every machine translated batch and every quick fix typed directly into a file. What automated linguistic checks change An automated check runs the comparison a reviewer was never good at, on every value, in every language, every time it changes. The requirements that separate a useful implementation from a noise generator: 1. Locale awareness. Every check above has legitimate per language exceptions. A checker that flags German noun capitalization as a casing error, or French non breaking spaces as doubles, trains reviewers to ignore it within a week. 2. Corpus scope. Consistency defects are invisible at the level of a single value. The check has to compare across all keys of a language. 3. Continuous by default. A QA pass that someone has to remember to run is a spreadsheet with better UI. Checks belong on the save path and in the editor, with findings attached to the key, not in a report nobody reopens. 4. An escape hatch per finding. Sometimes the difference is intentional: the same source word does need t
40wo translations in two contexts. If ignoring a finding is not a one click, scoped action, teams disable the whole check instead. 5. A clear boundary to human judgment. Checks answer \"is this structurally consistent with its source and corpus?\". They do not answer \"is this a good translation?\". That remains review work, informed by glossaries and style guides, and for machine generated translations by quality estimation, which scores what checks cannot compare. How this works in Locize Locize runs this as a built in layer, on by default, no configuration required: Ten locale aware linguistic checks compare every translation against its source: terminal punctuation, first letter casing, numbers, bracket counts, unbalanced brackets, whitespace, repeated words, special characters, URL counts, and HTML or component tags, each with the per language exceptions described above built in. Consistency checks work corpus wide: they find the same source value translated differently across keys (with the disagreeing keys listed next to the finding), duplicated source values, glossary violations and i18n syntax inconsistencies. Dangerous markup detection reports script executing content in values, and by default blocks saving it, in the editor and through the API, so a compromised translator account cannot inject into your application through a translation. Findings surface inline in the editor on the key, aggregate in the project's translation statistics, and every finding can be ignored per key where the difference is intentional. You can also run all checks across the whole project in one action: Running all checks across a project in Locize The point of the default is the same as the point of this post: the mechanical layer is not where human attention should go. Let the checks hold that line, give reviewers the glossary, the style guide and the review workflow, and spend the humans on the part machines cannot judge. If you want to see what the checks find in your own content: create a project, import your existing translation files, and run the checks. The findings are usually not the ones you expected. Frequently asked questions What is translation QA? Translation QA (quality assurance) is the practice of checking translated content for defects before it reaches users. It covers the mechanical layer (placeholders, tags, numbers, punctuation, whitespace, consistency) and the judgment layer (meaning, tone, fluency). The mechanical layer can be automated; the judgment layer needs humans, supported by glossaries, style guides and review workflows. What are the most common errors in translations? Mechanical defects dominate: changed or dropped interpolation placeholders and HTML tags, numbers that differ from the source, missing terminal punctuation, whitespace damage around concatenated values, repeated words, and the same term translated inconsistently across keys. Can translation QA be automated? The mechanical layer can be checked deterministically on every save, in every language. The judgment layer cannot: machine translation output can be scored by quality estimation, and human review decides. Working setups combine both. What is the difference between QA checks and quality estimation (QE)? QA checks are deterministic comparisons against the source and the corpus; they find structural defects and always reproduce. QE is a model based score predicting the quality of a translation without a reference. QE prioritizes review attention for new machine translations; QA checks guard the whole corpus continuously. Do automated checks replace human review? No. They remove the mechanical noise so review time goes into meaning, terminology and tone. A reviewer freed from counting brackets is a better linguist, not an unemployed one."},{"slug":"many-projects-one-team","title":"Many Projects, One Team: Access and Billing When Localization Outgrows One App","description":"The second app is where translation management quietly breaks: the same people re-invited everywhere, offboarding by memory, one invoice per project, and no answer to \"who can change the German copy?\". What the account layer above your projects has to do, and how organizations in Locize do it.","date":"2026-08-09","category":"Guides","thumbnail":"\/img\/blog\/many-projects-one-team\/thumbnail.jpg","readTime":"7 min read","searchText":"title: 'Many Projects, One Team: Access and Billing When Localization Outgrows One App', description: 'The second app is where translation management quietly breaks: the same people re invited everywhere, offboarding by memory, one invoice per project, and no answer to \"who can change the German copy?\". What the account layer above your projects has to do, and how organizations in Locize do it.', date: '2026 08 09', thumbnail: '\/img\/blog\/many projects one team\/thumbnail.jpg', image: '\/img\/blog\/many projects one team\/title.jpg', category: 'Guides', tags: ['organizations', 'user management', 'permissions', 'access control', 'billing', 'governance', 'sso', 'audit log', 'localization', 'i18n'], faq: [ q: 'How do you manage translations for multiple products or teams?', a: 'Put an account layer above the projects and keep each product its own project. The team is invited once on the account and inherits into every project, so access is granted and revoked in one place, while each product keeps its own versions, release cadence, languages and plan. Exter
40nal translators are the exception: they get a permission on the single project they work on and never see the rest. In Locize this account layer is the organization.' , q: 'Should each app be its own localization project or one big project with namespaces?', a: 'Separate projects, once the apps ship on their own schedules or are worked on by different people. Namespaces split content inside one release cadence; they do not give you separate versions, separate publishing or different access per app. The cost of separate projects used to be duplicated user management and one invoice per project, which is exactly what an account layer removes.' , q: 'How do I revoke someone from every translation project at once?', a: 'Remove them from the account roster, not from each project. When permissions are inherited from one roster, removing the person there takes their access to every project of that account with it. Direct per project permissions (typically externals) still have to be removed on that project, which is the point: those are the ones you want to see individually.' , q: 'Can several projects share one invoice?', a: 'Yes, when they live in the same account. In Locize the first project that subscribes creates the organization\\'s subscription and every further project joins it, so everything lands on one invoice while each project keeps its own plan. Sharing an invoice is included on every plan. If a department needs its own invoice, it needs its own organization: one subscription, one payment method, one invoice per organization.' , q: 'What belongs on the account level and what stays on the project?', a: 'On the account: the team roster, billing and invoices, SAML SSO, enforced 2 factor authentication and the audit log, because each of those is a single fact about the company rather than about one app. On the project: the plan and add ons, languages, versions, publishing and any permission that must differ for that one app. The account decides where the bill and the people live; it does not change what a plan includes.' ] Most localization setups are born simple: one app, one project, three people who all know each other. Nothing in this post applies to that, and if that is where you are, the rest is premature. It changes with the second app. Then a mobile client, a marketing site, a customer portal, an internal admin tool. Every one of them is a legitimate project of its own: own release cadence, own languages, own plan. And at some point between the second and the fifth, the work stops being about translation and starts being about administration. Key facts What breaks at project two: the same people re invited per project, offboarding done from memory, one invoice per project, and no single answer to \"who can change this language?\" Why one big project is not the fix: namespaces split content, not release cadence, publishing or access. What actually fixes it: an account layer above the projects: one roster that inherits, one subscription, one place for SSO, enforced 2FA and the audit log. The rule that keeps it usable: your own team lives on the account, externals stay on the single project they work on. Separate invoice means separate account. One subscription, one payment method, one invoice per account. A second cost center is a second account, not a special case inside the first. What actually breaks when the second project appears The same invitations, again and again. Eight colleagues, five projects, forty invitations, and every new hire repeats the ritual. It is tedious rather than dangerous, which is precisely why nobody fixes it until something else goes wrong. Offboarding becomes a memory game. Someone leaves the company, or moves to a team that has nothing to do with the portal anymore. Now the question is which projects they were ever added to. If the answer lives only in each project's user list, revoking access means remembering every project that exists, and the cost of forgetting one is a person who still edits your production copy months later. This is the failure mode that turns an administrative annoyance into a security finding. The invoice fragments. Five projects, five subscriptions, five renewal dates, five receipts to reconcile. Finance asks why one company pays a localization vendor five times, and the honest answer is that the tool had no concept of a company. Exter
40nals get more access than intended. The freelance translator needs Italian on the marketing site. The path of least resistance grants them a role that reaches further than that, because narrowing it per project is work. Multiply by every contractor and agency contact over a couple of years. Nobody can answer \"who has access to what?\" Not because the data is missing, but because it is spread across N project user lists with no place that aggregates it. The first time somebody asks that question seriously, it is usually an auditor, a customer security questionnaire, or an incident. Why the usual workarounds do not hold One big project with namespaces. Tempting, because it collapses the administration problem instantly. It also collapses everything you separated the apps for: a namespace is a slice of content inside one project, so it shares that project's versions, its publishing, its plan and its access rules. Two products that ship on different days cannot share one release cadence, and \"the intern can edit the marketing copy but not the checkout flow\" is not expressible in a structure where both are namespaces of the same thing. A shared login. It solves the invitation problem by destroying the audit trail, makes 2 factor authentication meaningless, and turns every offboarding into a password rotation. It shows up more often than anyone admits. A spreadsheet of who has what. Correct on the day it is written. The moment access is granted somewhere without the spreadsheet being updated, it is worse than nothing, because it is now a document that confidently states something false. What the structure should look like The pattern that holds is an account layer that sits above the projects and owns the two things that are facts about the company rather than about an app: the people and the bill. Four properties make it work. One roster, inherited into every project. You invite a colleague once, at the account, with the role they should have across the company. They appear in every project of that account with that role. Grant in one place, revoke in one place. This is what makes offboarding a single action instead of a search. Two kinds of role, and only one of them is inherited blindly. Roles that run the account (administration and billing) belong to the account and reach everywhere by definition. The working roles (manage, publish, translate) inherit too, but a project has to be able to say \"not this person here\": narrow them to one language on this project, or block them from it entirely. Without that override, an inherited roster is too blunt to use, and teams go back to per project invitations. Externals stay on the project. The roster is for your own team. A freelance translator or an agency contact gets a permission on exactly the project they work on, and never sees that the rest of the account exists. This one rule is what keeps the inheritance safe: everything on the roster is deliberately company wide, so anything that must not be company wide is not on the roster. One account, one subscription, one invoice. Every project bills inside its account. When a department genuinely needs its own invoice, its own payment method or its own set of people, that department is a second account, not a special case inside the first. Trying to express two invoices inside one account is where these models usually turn into something nobody can reason about. On top of that, a handful of things only make sense at the account level: single sign on (an identity provider is a fact about the company, not about an app), enforced 2 factor authentication , and an audit log of who was granted and revoked what. Configuring those per project is both busywork and a way to end up with five different security postures in one company. How this works in Locize This is the shape of organizations in Locize, and the reason we built them. Your organization is the account layer. You get one automatically with your first project, named after your company, and you can rename it any time. Everything above is how it behaves: The roster lives on the organization page. Members are invited once and inherit into every project, with a \"via organization\" badge on each project's user list so you can always tell inherited access from a direct one. A direct project permission wins for the working roles, so you can narrow or block someone on a single project, and \"inherit\" hands them back to the organization's rule. Details in user management. Admin and accountant exist only on the organization. Project permissions top out at manager. That is
40what makes the offboarding story true: there is no way to accumulate company wide power project by project. Billing is the organization's. The first project that subscribes creates the subscription, and every further project joins it: one invoice, while each project keeps its own plan and limits. Sharing an invoice is included on every plan. A separate invoice is a separate organization. You can create one directly from the add project form, and move an existing project across with a one time handover code: the receiving admin sees which project arrives and from whom before confirming. Tenants and branches follow their parent project automatically (multi tenant). SSO is charged once per subscription , no matter how many projects use it. Enforced 2 factor authentication is set for the whole organization, and a project can strengthen it but never weaken it. Organization admins can download the audit log of member and invitation changes on plans that include it. If you were already using collective billing, none of this asked anything of you: your billing group became your organization, its admins became organization admins, everyone kept the projects they had, and the invoice stayed the same or got slightly cheaper, since SSO is now charged once per subscription instead of once per project. When you do not need any of this One app, one or two people, no external translators, no compliance questions: leave it alone. A single project with a couple of direct permissions is the correct structure, and adding an account layer on top of it buys nothing. The signals that it is time are concrete and you will recognize them: the third project, the first person who has to be removed from several projects at once, the first invoice question from finance, the first security questionnaire that asks how access is granted and revoked, or the first contractor you had to give more access than you wanted. The point of the account layer is not that it manages your translations. It is that it stops the administration around them from growing with every product you ship. If several of those signals sound familiar, the fastest way to see the shape is to look at your own setup: the organization page lists every project, who reaches it and what it costs this period. Start free with Locize, or read the organizations documentation first if you would rather see the model before the product."},{"slug":"i18n-without-translation-files","title":"i18n Without Translation Files? You Can Do That With i18next Today","description":"A new wave of i18n tools pitches \"your code is the source of truth, translation files are build artifacts\". The i18next ecosystem has supported exactly this workflow for years: natural-language keys, JSX serialization via Trans, saveMissing reporting, automatic AI translation, and CDN delivery with no locale files in your repo at all. The recipe, the honest trade-offs, and what \"no files\" does not solve.","date":"2026-07-08","category":"Guides","thumbnail":"\/img\/blog\/i18n-without-translation-files\/thumbnail.jpg","readTime":"5 min read","searchText":"title: 'i18n Without Translation Files? You Can Do That With i18next Today', description: 'A new wave of i18n tools pitches \"your code is the source of truth, translation files are build artifacts\". The i18next ecosystem has supported exactly this workflow for years: natural language keys, JSX serialization via Trans, saveMissing reporting, automatic AI translation, and CDN delivery with no locale files in your repo at all. The recipe, the honest trade offs, and what \"no files\" does not solve.', date: '2026 07 08', thumbnail: '\/img\/blog\/i18n without translation files\/thumbnail.jpg', image: '\/img\/blog\/i18n without translation files\/title.jpg', category: 'Guides', tags: ['i18next', 'react i18next', 'natural language keys', 'savemissing', 'translation files', 'cdn', 'ai', 'workflow'], faq: [ q: 'Can i18next work without translation keys?', a: 'Yes. Set keySeparator: false and nsSeparator: false and the English text itself becomes the key: t(\"Add to cart\") needs no en.json entry, because a missing translation falls back to the key, which is the source text. For rich text, the Trans component serializes its JSX children (with indexed tags like ) into the key, so markup stays in your code.' , q: 'How do new strings get translated if nobody maintains translation files?', a: 'Through saveMissing. With saveMissing enabled, i18next reports every string it renders for the first time to Locize, where automatic translation (your own OpenAI, Gemini, Mistral or DeepL key, or the built in service) fills all target languages and Quality Estimation scores each result. Prefer a pipeline over runtime reporting? i18next cli extracts the same strings statically in CI.' , q: 'What happens when I edit the source text?', a: 'The edited string is a new key, so it gets freshly translated, and the old key is removed on the next sync. Translation memory softens the cost: prior human reviewed translations of similar strings come back as high score matches instead of being retranslated from scratch. For copy that churns constantly, stable keys remain the better tool, and i18next lets you mix both styles in one project.' , q: 'Do I still need translation files for SSR or SSG?', a: 'Only as optional build time snapshots. Client side, i18next locize backend loads translations straight from the CDN, so the repo contains
40no locale files at all. For server side rendering or static builds, download a snapshot in CI (locize cli download or the locize\/translate GitHub Action) and treat it as a generated artifact, not something anyone edits by hand.' ] \"Translation files are the problem.\" It is a popular pitch in 2026: your components are the source of truth, so stop hand maintaining per locale JSON, let tooling generate translations, and treat locale files as build artifacts. A new wave of i18n tools is built on that argument. The diagnosis is partly right. Hand editing seventeen JSON files to add one sentence is nobody's favorite job. The part the pitch usually leaves out: the i18next ecosystem has supported exactly this workflow for years, with plain open source libraries, and it can go one step further, because with CDN delivery there are no translation files in your repo at all, not even generated ones. Here is the recipe, followed by the honest trade offs. Key facts Natural language keys: with ; the source text is the key, and a missing translation renders the source. No English file needed. Rich text stays in code: the component serializes JSX children into the key, indexed tags and all. New strings translate themselves: reports them; automatic translation (your own LLM key or built in) fills every target language; Quality Estimation scores each result. No files, or files as artifacts, your choice: CDN delivery at runtime means zero locale files in the repo; CI extraction ( ) produces them as generated artifacts if you prefer. What \"no files\" doesn't solve: terminology consistency, review, and \"who approved this?\". Files were never the real problem; ungoverned output is. Step 1: make the code the source of truth Two lines of configuration turn i18next into a natural language key system: Now the English text is the key: There is no entry behind this. When no translation exists, i18next falls back to the key, and the key is the source text, so the app renders correctly from the first second. Rich text works the same way through the Trans component, which serializes its JSX children, markup included, into the key: Translators see and reorder the markup freely per language; your components keep owning the actual tags. Plurals and context suffixes keep working on top of natural keys, because they are key decorations, not separate files. Step 2: let new strings report themselves This is the piece that replaces \"maintain the files\": saveMissing. With and i18next locize backend, every string your app renders for the first time is reported to Locize automatically, typically gated to development so production stays read only: On the Locize side, automatic translation picks up each new source string and fills all target languages, on your own OpenAI, Gemini, Mistral or DeepL key if you bring one, with your glossary and styleguide injected into every request. Quality Estimation scores each result from 0 to 1, so confident translations save directly and doubtful ones route to review. You write , reload the page, and the string exists in every language, scored, a few seconds later. Nobody opened a JSON file. Step 3: deliver without files (or with them, generated) At runtime, the same backend loads translations from the Locize CDN. Which means the strongest version of \"translation files are build artifacts\" is available here too, and then some: there are no locale files in your repository at all. A translation fix published in the editor is live without a commit, a build, or a redeploy. Prefer a static pipeline, or need files for SSR\/SSG? Take the CI path instead: i18next cli extracts the same strings statically (it understands scopes and serializes children exactly like react i18next does), and the free locize\/translate GitHub Action runs extract, sync, auto translate and download on every push. The downloaded files are generated artifacts: commit them, or gitignore them and download at build time. Starting from an app that is not instrumented yet? takes it from hardcoded strings to localized in one command, and prints the same flow as a runbook for your AI coding agent. The honest trade offs Natural language keys are a trade, not a free upgrade, and it is worth knowing what you pay. (For the full decision framework on key strategies, including when content as key is the right call and when it is not, see our guide to i18n key naming.) Editing copy re keys the string. Change \"Add to cart\" to \"Add to basket\" and it is a new key: freshly translated, while the old one is removed on the next sync. Translation memory softens this, prior reviewed translations come back as high score matches, but for copy that churns weekly, stable keys with are the better tool. i18next lets you mix both styles in the same project; many teams use natural keys for stable UI text and stable keys for marketing copy. Long text makes long keys. A three paragraph terms blurb as its own key is unpleasant in every tool that displays keys. Give those strings a stable key and a . Ambiguity needs context. English \"Open\" as a verb and as an adjective may need two different translations. i18next's context feature ( ) covers it, but you have to notice the ambiguity; a file first workflow does not save you from this either. What \"no files\" does not solve Removing file maintenance removes a chore. It does not remove the actual hard problems of localization, and this is where the \"your code is the source of truth\" pitch quietly ends: terminology that must not drift, formality that must not flip mid app, legal strings that need human eyes, and the question \"who approved this translation?\", which a pipeline of unreviewed bot output answers with a commit hash. We wrote up what actually breaks in AI only pipelines, and none of the failure modes involve file formats. That is the real difference between workflows, files or not: whether translated output lands in a governed layer, with glossary enforced consistency, quality scores, selective human review and an audit history, or lands directly in production. Keyless input plus ungoverned output is just faster drift. Try the whole loop in an afternoon Wire up natural language keys and in a branch, create a free Locize project, enable automatic translation, and watch new strings appear translated and scored as you click through your app. If you already run an AI in CI pipeline and wonder what state your locale files are in, the free i18n health check runs entirely in your browser and shows missing keys, duplicates and interpolation mismatches before you change anything. Translation files were never the point. Trusted translations in production are, whether the files exist or not."},{"slug":"i18n-formatting","title":"i18n Formatting: Dates, Numbers & Currency with Intl and i18next (2026 Guide)","description":"Hand-rolled \"$\" + toFixed(2) formatting is a bug in most locales: 1,234.56 is 1.234,56 in German and 1 234 567,89 in French, and yen has no decimal places. This guide covers Intl.NumberFormat, DateTimeFormat, RelativeTimeFormat, and how i18next wires them into translation strings with {{val, number}}, currency, datetime and custom formatters.","date":"2026-07-07","category":"Guides","thumbnail":"\/img\/blog\/i18n-formatting\/thumbnail.jpg","readTime":"5 min read","searchText":"hideCta: true, title: 'i18n Formatting: Dates, Numbers & Currency with Intl and i18next (2026 Guide)', description: 'Hand rolled \"$\" + toFixed(2) formatting is a bug in most locales: 1,234.56 is 1.234,56 in German and 1 234 567,89 in French, and yen has no decimal places. This guide covers Intl.NumberFormat, DateTimeFormat, RelativeTimeFormat, and how i18next wires them into translation strings with val, number , currency, datetime and custom formatters.', date: '2026 07 07', thumbnail: '\/img\/blog\/i18n formatting\/thumbnail.jpg', image: '\/img\/blog\/i18n formatting\/title.jpg', category: 'Guides', tags: ['i18next', 'i18n', 'guides', 'formatting'], faq: [ q: 'How do you format numbers and dates in i18next?', a: 'Since i18next v21.3 formatting is built in: write val, number , val, datetime , val, currency(USD) , val, relativetime or val, list directly in the translation string. i18next calls the matching Intl API (Intl.NumberFormat, Intl.DateTimeFormat, â¦) with the active language, so the output automatically follows the locale.' , q: 'How do I format currency in i18next?', a: 'Use val, currency(USD) in the translation string, or keep the string generic ( val, currency ) and pass the currency code at c
40all time via formatParams. The currency code should come from your transaction data, not from the UI language: a German user can pay in USD, which renders as 1.234,50 $ with German separators and the dollar sign.' , q: 'What is the Intl API?', a: 'Intl is the ECMAScript Internationalization API built into every modern browser and Node.js. It provides locale aware formatters backed by CLDR data: Intl.NumberFormat (numbers, currency, percent, units), Intl.DateTimeFormat (dates and times), Intl.RelativeTimeFormat (\"3 days ago\"), Intl.ListFormat (word lists) and Intl.PluralRules (plural categories). No extra library and no locale files to ship.' , q: 'Do I still need Moment.js, date fns or Numeral.js for i18n formatting?', a: 'For formatting output: usually no. Intl.DateTimeFormat and Intl.NumberFormat cover locale aware display without shipping locale bundles. Libraries like date fns or Day.js remain useful for date arithmetic and parsing, and Moment.js is in maintenance mode; its own documentation recommends Intl based alternatives.' , q: 'Why does my app show the wrong number or date format?', a: 'The most common cause is calling toLocaleString() or new Intl.NumberFormat() without a locale argument: that uses the locale of the runtime, not the language the user selected, which also causes server\/client hydration mismatches. The built in i18next formatters always pass the active language for you. Also check that the value is a real number or Date object, not a string.' , q: 'How do relative times like \"3 days ago\" work?', a: 'Intl.RelativeTimeFormat formats a numeric offset plus a unit: format( 3, \"day\") gives \"3 days ago\", format(2, \"hour\") gives \"in 2 hours\", and the numeric: \"auto\" option turns an offset of 1 day into \"yesterday\" or \"tomorrow\". In i18next you write val, relativetime and pass the offset; computing the offset from a timestamp stays in your code.' , q: 'Can I add my own custom format to i18next?', a: 'Yes. Register it with i18next.services.formatter.add(\"myformat\", (value, lng, options) = â¦) and use val, myformat in translation strings. For per locale setup work there is formatter.addCached, which builds the formatter once per language and reuses it, the same caching i18next applies to its built in Intl formats.' , q: 'Should translators change number or date formats?', a: 'No. Separators, symbol position and date order come from CLDR via Intl, per locale, so nobody has to type them. Translators only move placeholders like val, datetime to the right position in the sentence. A translation management system such as Locize keeps those placeholders visible and machine translates around them without breaking them.' ] Translation covers the words. Locale aware formatting covers everything numeric, and it is where hand rolled i18n quietly falls apart: is in German and in French, the same day is , or depending on the locale, and yen amounts have no decimal places at all. Concatenating is a bug in most of the world. The good news: every one of these rules already ships with the browser, and i18next exposes them directly inside your translation strings. This guide covers the APIs that do the work and the i18next wiring on top. Table of contents Why hand formatting breaks The Intl formatting toolbox Numbers, percent & compact notation Currency Dates, times & relative time Formatting inside i18next translations Custom formatters Common mistakes Managing formatted strings across languages Frequently asked questions Why hand formatting breaks Take one number, , and render it the way five real locales expect: Locale Rendering (English, US) (German) (French) (Swiss German) (English, India) The German rendering swaps the meaning of and relative to English. French groups with (narrow non breaking) spaces. India groups in lakhs and crores, so even the group sizes differ. Dates have the same problem ( vs vs ), and currencies add symbol position and per currency decimal rules on top. None of this is something to hand code per language. Like plural rules, it is all defined in the Unicode CLDR, and it is already in your runtime. The Intl formatting toolbox The ECMAScript Internationalization API ( ) ships with every modern browser and Node.js, CLDR data included, so there are no locale bundles to install: API What it formats i18next format name numbers, percent, units, compact notation, currency , dates and times \"3 days ago\", \"in 2 hours\" \"a, b, and c\" plural categories powers the \/ suffixes The first four are this article. The last one is its own topic, covered in the pluralization guide linked above. Numbers, percent & compact notation handles separators, percent, physical units and compact (\"social media\") notation, per locale: Note the details you would never hand code: German percent gets a (non breaking) space before , and the compact suffix is a locale specific word, not always a letter. Currency Currency formatting is number formatting plus three locale dependent decisions: which symbol, where it goes, and how many decimal places the currency uses. The yen line is the one that catches people: JPY has no minor units, so rounds to whole yen. would have printed , which does not exist. One rule to internalize: the currency comes from the transaction, the formatting comes from the user's locale. A German user buying in dollars sees dollars, formatted the German way: Never derive the currency code from the UI language. Dates, times & relative time covers the order, the separators, and the month\/weekday names. The \/ presets pick a sensible per locale layout: Formatting does not convert time zones for you; without an explicit option it renders in the runtime's zone. For \"3 days ago\" \/ \"in 2 hours\" strings, takes a signed offset plus a unit: And joins word lists with the right separators and conjunction per language: Formatting inside i18next translations Calling yourself works, but it splits a sentence into code formatted fragments and translated fragments. i18next solves this: since v21.3, the formatters are built into interpolation, so the placeholder carries its format: i18next passes the active language to the right API for you, and current versions cache the underlying formatter instances. The key shows how formatting composes with the \/ plural suffixes: selects the plural form and renders localized. And since this is plain interpolation, it works unchanged in react i18next, next i18next, and every other binding. Format options go either inline in the key, or per call via : Both the string and the formatting follow the active language; nothing in your component changes. Keep the resources as plain (format reference), and note this is interpolation level formatting: for how entire message formats compare (ICU, Fluent, gettext, â¦) see I18N in the Multiverse of Formats. Custom formatters Anything does not cover, you can register yourself and use like a built in: If the setup work is per locale (like constructing that ), newer i18next versions also provide , which builds the formatter once per language and reuses it. Projects started before i18next v21 may
40still configure the legacy function instead; it keeps working, but the built ins now cover most of what it was used for (typically Moment.js or Numeral.js wrappers). Common mistakes Concatenating symbols. gets the symbol, its position, the separators and the decimal count wrong (JPY has none). Use , always. No locale argument. or without a locale uses the runtime's locale, not your user's language, a classic source of server\/client hydration mismatches. The i18next built ins always pass the active language. Deriving currency from the UI language. Currency is transaction data. Format with German separators for a German user; do not silently switch them to . Typing formats into translations. If translators write style patterns into strings, every copy change risks a format bug. Keep the raw placeholder ( ) in the string and let CLDR do the rest. Confusing formatting with time zones. renders in the runtime's zone unless you pass . Formatting localizes the display , it does not move the clock. Missing ICU data on the server. Official Node.js builds ship full ICU since v13, but custom or builds silently fall back to English formats, a bug you only see server side. Managing formatted strings across languages The formatting itself is free, CLDR does the work. What breaks in practice is the placeholders. A translator who retypes as , or translates the word into French, breaks exactly one language in production, and no test written against the English strings will catch it. This is where a translation management system earns its place. Locize is built around the i18next message format: Placeholders like stay visible in the editor; translators move them into position instead of retyping them. Machine and AI translation is i18next format aware, so placeholders survive the round trip intact. Keys added via saveMissing arrive with their placeholders, ready to translate. Get the formatting from , keep the strings in JSON, and adding a locale becomes a translation task, not an engineering task, which is the whole goal of i18n. Frequently Asked Questions frontmatter.faq.map(( q, a ) = ( q a ))"},{"slug":"who-uses-i18next","title":"Who Uses i18next? 1,500+ of the World's Top Websites","description":"We scanned the top 100,000 websites to see how many run on i18next. At least 1,534 do, from X and GitLab to Deezer, Strava, DeepL and Microsoft Power BI. Here is the data, the method, and why it matters for open source.","date":"2026-07-06","category":"Open Source","thumbnail":"\/img\/blog\/who-uses-i18next\/thumbnail.jpg","readTime":"3 min read","searchText":"title: 'Who Uses i18next? 1,500+ of the World\\'s Top Websites', description: 'We scanned the top 100,000 websites to see how many run on i18next. At least 1,534 do, from X and GitLab to Deezer, Strava, DeepL and Microsoft Power BI. Here is the data, the method, and why it matters for open source.', date: '2026 07 06', thumbnail: '\/img\/blog\/who uses i18next\/thumbnail.jpg', image: '\/img\/blog\/who uses i18next\/title.jpg', category: 'Open Source', tags: ['i18next', 'open source', 'adoption', 'sustainability', 'locize'], faq: [ q: 'How many of the top websites use i18next?', a: 'In a July 2026 scan of the top 100,000 websites, at least 1,534 were detected using i18next (about 1.7% of reachable sites). That is a lower bound: sites that inline their translations or block automated requests are undercounted.' , q: 'Which well known sites use i18next?', a: 'Detected examples include X (Twitter), GitLab, Deezer, Strava, DeepL, Microsoft Power BI, Eventbrite, NBC News, Elsevier, CoinMarketCap, UEFA and the World Economic Forum, among many others.' , q: 'How was this measured?', a: 'Each site\\'s delivered HTML, first party JavaScript bundles and network requests were checked for i18next fingerprints: the i18next runtime, the react i18next\/next i18next bindings, the http backend load path, and the language detector cookie. It is automated public page analysis, so it can include the occasional false positive.' ] i18next turns 15 this year, with nearly 15 million weekly npm downloads . One question we get a lot is who actually uses it in production. So instead of guessing, we measured. We scanned the top 100,000 websites and checked each one for i18next fingerprints in its delivered HTML, its JavaScript bundles, and its network requests. At least 1,534 of them run on i18next. The \"at least\" matters: this is a lower bound (method below). The real number is higher. It's the top of the web, not the long tail i18next isn't fringe adoption. It's densest among the most visited sites and thins out as you go down the ranking: Most of what we found is react i18next and next i18next , which tracks with where the JavaScript ecosystem has gone. And 264 of these sites render i18next on the server (Next.js and friends), exactly the kind of usage a naive client only check misses entirely. You know a lot of them A sample of the sites detected using i18next, the open source library: How we measured this (and where it's fuzzy) It's only fair to show our work: What counts as a hit: the i18next runtime, a binding (react i18next \/
40next i18next \/ others), the http backend load path, or the language detector cookie, found in a site's HTML, its first party bundles, or its requests. It's a lower bound. Around 9% of the top 100k blocked automated requests or wouldn't respond, and sites that inline their translations with no runtime marker are invisible to this method. Those are undercounted, not counted. It's automated , so it can include the occasional false positive. The data is from July 2026 , based on the Majestic top 100k ranking. See something wrong about your site? Let us know and we'll correct it. Search the full list Every domain we detected, searchable: Why we're sharing this Here's the part that connects to an earlier post of ours: every one of these 1,534 sites, the household names included, runs on a library maintained by a small core team, funded by Locize. Most of them have no idea. That's fine, it's the nature of open source, but it's also why we occasionally write posts like this one. If i18next is in your stack, here's what actually helps keep it healthy: Try Locize. It's built by the i18next team, integrates deeply with the ecosystem, and there's a free plan. If it fits your workflow, it directly funds the library you're already using. Tell your team. If your company is one of the 1,534 (or one of the many we couldn't see), knowing that Locize funds i18next is useful information when you evaluate localization tooling. Mention it when it comes up. When someone asks about i18next in your community, it costs nothing to say how the library stays maintained. i18next stays free and MIT licensed. We just think it's worth knowing how much of the web quietly depends on it, and who keeps it running. â The i18next \/ Locize team"},{"slug":"i18n-pluralization","title":"i18n Pluralization: CLDR Plural Rules, i18next & ICU (2026 Guide)","description":"Pluralization in i18n is not \"singular vs plural\". English has 2 plural forms, Polish has 4, Arabic has 6, Japanese has 1. This guide covers CLDR plural categories, i18next v4 _one\/_other keys, ordinals, ICU, and the mistakes that quietly break plurals.","date":"2026-07-05","category":"Guides","thumbnail":"\/img\/blog\/i18n-pluralization\/thumbnail.jpg","readTime":"5 min read","searchText":"hideCta: true, title: 'i18n Pluralization: CLDR Plural Rules, i18next & ICU (2026 Guide)', description: 'Pluralization in i18n is not \"singular vs plural\". English has 2 plural forms, Polish has 4, Arabic has 6, Japanese has 1. This guide covers CLDR plural categories, i18next v4 one\/ other keys, ordinals, ICU, and the mistakes that quietly break plurals.', date: '2026 07 05', thumbnail: '\/img\/blog\/i18n pluralization\/thumbnail.jpg', image: '\/img\/blog\/i18n pluralization\/title.jpg', category: 'Guides', tags: ['i18next', 'i18n', 'guides', 'plurals'], faq: [ q: 'How does i18next handle plurals?', a: 'You call t(key, count ) and i18next appends a suffix based on the CLDR plural category of that count for the active language, using the browser native Intl.PluralRules. In English that means a one and an other key; in other languages it can be up to six keys ( zero, one, two, few, many, other). You never write count === 1 logic yourself.' , q: 'What are CLDR plural categories?', a: 'CLDR (the Unicode Common Locale Data Repository) defines up to six plural categories: zero, one, two, few, many, and other. Each language uses a subset. English uses one and other; Polish uses one, few, many, other; Arabic uses all six; Japanese and Chinese use only other. Intl.PluralRules returns the correct category for any number and locale.' , q: 'How many plural forms does a language have?', a: 'It varies from one to six. Japanese, Chinese and Korean have one (no grammatical plural). English, German, Spanish and most Western European languages have two. French has three. Slavic languages like Polish and Russian have four. Arabic and Welsh have six. This is why a boolean singular\/plural check fails outside English.' , q: 'What changed in i18next v4 pluralization?', a: 'i18next v4 switched from numeric suffixes (key 0, key 1, key 2) and key plural to the CLDR category names (key one, key two, key few, key many, key other), powered by Intl.PluralRules. This makes plural keys self documenting and consistent with the rest of the platform. Existing v3 projects can convert with the official migration tooling.' , q: 'Why is my i18next plural not working?', a: 'The usual causes: you passed count as a string instead of a number; the key is missing the correct CLDR suffix for the active language (for example only one and other while the language needs few and many); your JSON is still in the i18next v3 format while the runtime is v4
40(or vice versa); or the language resources have not finished loading. Turn on debug: true to see which key i18next resolved.' , q: 'Does i18next support ordinal plurals (1st, 2nd, 3rd)?', a: 'Yes. Pass ordinal: true to t() and provide ordinal keys (key ordinal one, key ordinal two, key ordinal few, key ordinal other). In English these map to 1st, 2nd, 3rd and 4th+. i18next uses Intl.PluralRules with type \"ordinal\" to pick the right form.' , q: 'Does i18next support ICU MessageFormat plurals?', a: 'Yes, via the i18next icu plugin. That lets you write ICU syntax like count, plural, one item other items inline in a single string instead of using suffixed keys. Both approaches use the same underlying CLDR rules; suffixed keys are the i18next default, ICU is opt in.' , q: 'How do you handle a \"zero\" \/ no items message?', a: 'For languages whose CLDR rules include a zero category (Arabic, Latvian, Welsh), define a zero key and it is used automatically for count 0. For languages without a zero category (like English, where 0 resolves to other), add an explicit zero key for a dedicated \"no items\" message, or branch on count === 0 before calling t().' ] Pluralization is one of the most underestimated parts of internationalization. In English it looks trivial, one item versus two items, so most codebases start with something like . That single line is a bug in most of the world's languages. This guide explains how plurals actually work across languages (via CLDR), how i18next implements them, and the handful of mistakes that quietly break plural output in production. Table of contents Why pluralization is hard CLDR plural categories How i18next handles plurals Interpolating the count i18next v3 vs v4 plurals Ordinal plurals (1st, 2nd, 3rd) ICU message format plurals Common mistakes Managing plurals across languages Frequently asked questions Why pluralization is hard English has two plural forms: singular ( ) and plural ( , , ). That two way split is the exception, not the rule. Japanese, Chinese, Korean: one form. Nouns do not change with quantity. French: singular covers 0 and 1, plural covers the rest, plus a separate form for large formatted numbers. Polish, Russian, Ukrainian: the form for 2, 3, 4 differs from the form for 5 21, which differs again from 22 24. Arabic: six distinct forms, including dedicated forms for 0, 1, and 2. You cannot express this with . The rules are per language, non obvious, and defined by linguists, not developers. That standard set of rules is CLDR. CLDR plural categories The Unicode CLDR defines up to six plural categories . Every language maps each number to exactly one of them: Category Meaning (varies by language) quantity 0 (only some languages) singular like quantity dual (only some languages) small quantity (language specific) large quantity (language specific) the catch all \/ general plural How many a language actually uses: Language Categories used Count Japanese, Chinese, Korean 1 English, German, Spanish, Italian , 2 French , , 3 Polish, Russian, Ukrainian , , , 4 Arabic, Welsh , , , , , 6 The good news: you do not need to memorize these. The browser ships them. returns the right category for any number and locale: How i18next handles plurals i18next v4 is built directly on . You add one JSON key per plural category the language needs, using the category name as a suffix: Then you call with a : i18next runs , gets the category ( , , â¦), and resolves . For a language that needs more forms, you simply provide more
40keys. Polish: You write the same call in your code; the correct form is chosen per active language. That is the whole point of i18n pluralization: the logic lives in data, not in your components. Interpolating the count doubles as an interpolation value, so renders the number inside the string: Formatting the number (thousands separators, etc.) is a separate, locale aware concern, handled with i18next's function or , covered in depth in the i18n formatting guide. Keep translation files as ; see the JSON translation files reference for structure conventions. i18next v3 vs v4 plurals If you are reading older tutorials or maintaining a legacy project, the plural format looks different. This is the single most common source of \"my plurals stopped working\": i18next v3 i18next v4 (current) Two form languages + + Multi form languages , , , ⦠, , , Rule source bundled JSON rules native v4 keys are self documenting (the suffix names the category) and no longer bundle a plural rules table, which keeps the runtime smaller. Migrating a v3 project is a mechanical rename; the official migration guide and i18next cli cover it. Ordinal plurals (1st, 2nd, 3rd) Cardinal plurals ( ) and ordinal plurals ( ) use different CLDR rules. i18next supports ordinals with the flag and keys: ICU message format plurals If you prefer a single inline string over suffixed keys, the i18next icu plugin adds ICU MessageFormat support: Both styles resolve to the same CLDR categories under the hood. Suffixed keys are the i18next default (simpler diffs, one string per form); ICU keeps everything in one string (denser, familiar to teams coming from FormatJS\/react intl). Pick one and stay consistent. ICU itself is being succeeded by MessageFormat 2 (MF2), the new Unicode standard (Final Candidate since 2025), which expresses plurals through explicit selectors and handles gender plus plural combinations more cleanly. Adoption is still very early, so it is not yet the pragmatic default. See MessageFormat 2 in i18next: state of the migration for whether to adopt it today. For how i18next's format compares to ICU, Fluent, Gettext and the rest of the JS ecosystem, see I18N in the Multiverse of Formats. Common mistakes Passing as a string. will not select correctly. needs a number. Missing categories. Providing only and for a language that needs and (Polish, Russian) silently falls back and reads wrong to native speakers. v3\/v4 format mismatch. JSON in the old \/ format against a v4 runtime (or the reverse) resolves to the base key or nothing. See v3 vs v4. Assuming English rules everywhere. is in English but in Arabic. Do not special case globally. Resources not loaded yet. If translations load asynchronously and you render before they arrive, you see raw keys, unrelated to plurals. See translations not loading. Turn on in your i18next config to log exactly which key was resolved for each call. Managing plurals across languages The hard part is not the code, it is keeping the right set of plural forms filled in for every language. When you add Arabic, six forms per pluralized key suddenly need translating; when you add Japanese, five of them are redundant. This is where a translation management system earns its place. Locize is built around the i18next plural model: The editor shows exactly the plural forms each language requires , no more and no less, so translators cannot miss for Polish or leave empty for Arabic. Plural aware validation flags keys where a required category is missing. New keys added via saveMissing arrive with the correct plural skeleton, ready for human or AI translation. Get the CLDR rules right once, and adding a language becomes a translation task, not an engineering task, which is the whole goal of i18n. Frequently Asked Questions frontmatter.faq.map(( q, a ) = ( q a ))"},{"slug":"phrase-lokalise-price-changes-2026","title":"Phrase and Lokalise Changed Their Pricing: What Happened and Your Options in 2026","description":"Phrase removed its $135\/mo Starter plan and now starts business plans at $1,245\/mo. Lokalise restructured to processed-word billing and gated its top tiers. What changed, why the market is moving upmarket, and what a small team can do about it.","date":"2026-07-02","category":"Guides","thumbnail":"\/img\/blog\/phrase-lokalise-price-changes-2026\/thumbn
40ail.jpg","readTime":"6 min read","searchText":"title: 'Phrase and Lokalise Changed Their Pricing: What Happened and Your Options in 2026', description: 'Phrase removed its $135\/mo Starter plan and now starts business plans at $1,245\/mo. Lokalise restructured to processed word billing and gated its top tiers. What changed, why the market is moving upmarket, and what a small team can do about it.', date: '2026 07 02', thumbnail: '\/img\/blog\/phrase lokalise price changes 2026\/thumbnail.jpg', image: '\/img\/blog\/phrase lokalise price changes 2026\/title.jpg', category: 'Guides', tags: ['tms', 'pricing', 'phrase', 'lokalise', 'localization', 'comparison'], faq: [ q: 'What happened to the Phrase Starter plan?', a: 'Phrase introduced single platform subscription pricing in February 2024 with Starter at $135\/month (billed annually) as the self serve entry for teams. Between August and October 2025 the Starter plan was removed from the public pricing page. As of July 2026 the entry business plan is Team at $1,245\/month billed annually behind a \"Get in touch\" CTA; self serve remains only for the Software UI\/UX developer plan ($525\/month) and the single seat Freelancer plan ($27\/month).' , q: 'How did Lokalise pricing change in 2025?', a: 'In November 2025 Lokalise replaced its Start ($120\/mo), Essential ($230\/mo) and Pro ($825\/mo) plans with Explorer ($144\/mo), Growth (listed at $499\/mo at launch, $375\/mo as of July 2026), Advanced ($999\/mo) and Enterprise. Billing switched from seats and keys to processed words, the free forever plan was withdrawn, and the top two tiers moved behind a demo call. The self serve ceiling dropped from $825\/mo to the $375 499 range.' , q: 'Why are TMS vendors moving upmarket?', a: 'Industry analysts describe a flat market with growth concentrated in enterprise platforms: Nimdzi projects the language industry growing under 1% per year, and enterprise buyers now expect large AI driven cost cuts. Meanwhile small teams increasingly cover simple cases with AI translation directly. Funded vendors are responding by concentrating on enterprise contracts (sales led pricing, governance features), which raises the entry price for everyone else.' , q: 'What are the alternatives if I am priced out?', a: 'Crowdin kept unchanged self serve pricing (Pro from $50\/month annual). Tolgee is open source and self hostable. i18nexus and SimpleLocalize are lightweight low cost options. Locize offers a free tier and plans from $7\/month with unlimited users, priced usage based in steps: each plan includes a generous volume and extra capacity comes in blocks, plus native i18next integration and CDN delivery. Migration is typically a JSON\/XLIFF export and re import; keep source keys in version control so the move is reversible.' ] If you searched for \"Phrase pricing\" or opened your Lokalise renewal and did a double take: no, you did not misremember the numbers. Both vendors restructured their pricing over the last year, in the same direction, and it is worth understanding what actually changed before deciding what to do about it. This is a factual walkthrough of both changes, the market shift behind them, and the realistic options for a team that no longer fits the new packaging. We publish a competing product (more on that at the end), so we will stick to checkable facts and link the sources. Key facts Phrase: the $135\/mo Starter plan (introduced Feb 2024) disappeared from the public pricing page between August and October 2025. The entry business plan is now Team at $1,245\/mo billed annually, behind \"Get in touch\". Self serve remains only for a $525\/mo developer plan and a $27\/mo single seat freelancer plan. Lokalise: November 2025 restructure. Start\/Essential\/Pro ($120\/$230\/$825) became Explorer\/Growth\/Advanced\/Enterprise ($144, $375 499, $999, custom). Billing moved to processed words, the free plan was withdrawn, and the top two tiers require a demo. The pattern: funded TMS vendors are concentrating on enterprise contracts. The self serve, sub $500\/mo slice of the market is being vacated, not fought over. What changed at Phrase Phrase, the platform formed from PhraseApp and Memsource, announced its move to single platform subscription pricing in January 2024, effective that February. The lineup at the time: Starter at $135\/month, Team at $1,045\/month, Business at $4,395\/month (all billed annually), Enterprise custom. Starter was the one plan a small team could buy with a credit card and no sales call. Then, step by step: By January 2025, the Business price left the public page (\"Custom\"). Between August and October 2025, Starter was removed entirely . The pricing page reorganized into Business plans, Developer & Designer plans, and Freelancer & LSP plans. By mid 2026, the entry business plan (Team) had risen to $1,245\/month billed annually , roughly $15,000\/year, behind a \"Get in touch\" CTA. What remains self serve as of July 2026 is the Software UI\/UX developer plan at $525\/month and the Freelancer plan at $27\/month (a single TMS
40seat aimed at individual translators). For a product team, the effective self serve entry moved from $135 to $525, and the \"talk to us\" business floor sits near $15k\/year. To be clear about the other side of this: Phrase is a strong enterprise product. Forrester named it a Leader in its first ever TMS Wave (Q3 2025). The pricing change is not decay; it is a deliberate choice of customer. If you run a multi vendor localization program with LSP workflows, Phrase's Business and Enterprise tiers may genuinely be the right shelf. The problem is only that everyone below that shelf now needs a different answer. What changed at Lokalise Lokalise ran its own restructure in November 2025, documented in its own help center. The long standing Start ($120\/mo), Essential ($230\/mo) and Pro ($825\/mo, billed annually) plans became: Explorer at $144\/month Growth , listed at $499\/month at launch and $375\/month as of July 2026 Advanced at $999\/month, behind \"Book a demo\" Enterprise , custom, behind \"Book a demo\" Three structural changes came with the new names. Billing switched from seats and hosted keys to processed words , so heavy machine translation usage now meters. The free forever plan , introduced only months earlier in 2025, was withdrawn (a 14 day trial remains). And AI translation, which had been a paid add on at roughly $0.05 per word, is now bundled into every plan. Net effect: entry pricing rose about 20%, the self serve ceiling dropped from $825 to the $375 499 range, and two of four tiers now require a sales conversation. If your renewal came in higher or a feature moved out of reach, that is the restructure, not your usage. Why this is happening Zoom out and the two changes stop looking like coincidence. The localization industry has stopped growing the way it used to. Nimdzi's 2026 industry report projects under 1% annual growth for the coming years and reports clients expecting AI driven cost cuts of up to 75%. CSA Research measured the industry's first outright revenue decline in 2023. Consolidation is running fast: Transifex was acquired by XTM International in January 2025, one of several roll ups. At the same time, the smallest projects increasingly skip a TMS entirely and run their strings through an LLM in CI. That pinches the low end of the market hardest: the segment that used to buy $100 500\/month plans is the one AI DIY absorbs first. Funded vendors are reading the same numbers and drawing the same conclusion: concentrate on enterprise contracts, where governance, compliance and workflow complexity still command budgets, and stop optimizing for the self serve long tail. Raising the entry price and gating tiers behind sales calls is exactly what that strategy looks like from the outside. Which means the sub $500\/month, buy it yourself slice of the market is not being fought over. It is being vacated. Not by everyone, though. Your options Stay and renegotiate. If the new packaging still fits how you work, staying is legitimate. Vendors mid restructure often have retention discretion, especially near renewal. Ask. Move to another managed, self serve TMS. Crowdin is the notable major that kept transparent self serve pricing (Pro from $50\/month annual, unchanged since early 2024, free for open source). Locize belongs in this category too: a fully managed TMS with review workflows, translation memory, glossary, in context editing and CDN delivery, with public pricing and no sales gate. Go open source. Tolgee is self hostable and free to run yourself; the trade off is that hosting, scaling, patching and delivery become your job. If what draws you to open source is \"free to start\" rather than running your own infrastructure, a managed free plan gets you there without the operational overhead: Locize is not open source, but its free tier and public pricing cover that same entry point. Go lightweight. i18nexus and SimpleLocalize are low cost, key based tools that fit small React\/Next.js projects well. Locize plays in the same lightweight range at the entry level: free tier, flat plans from $7\/month, and you only grow into the heavier features when you need them. Go developer first. Locize (that is us) is built by the maintainers of i18next: the i18next locize backend connects at runtime, captures new keys automatically, and a CDN publishes updates without a redeploy; other frameworks and 15+ formats work through the CLI\/API. Pricing is public, with a free tier and plans from $7\/month with unlimited users, usage based in steps rather than metered per unit, and SSO without an enterprise only sales call. We keep neutral, regularly updated field maps for both vendors: best Phrase alternatives and best Lokalise alternatives, plus step by step migration guides (from Phrase, from Lokalise). Whichever direction you take: export your keys and translations (JSON or XLIFF), keep them in ver
40sion control, and any of these moves stays reversible. For the wider field beyond those two vendors, see the best localization platforms for developer teams. If you want to check the numbers against your own usage, create a free Locize account and import an export of your current project; you will see what it costs before anything is committed. Vendor pricing facts in this post reflect the vendors' public pricing pages as of July 2026 and dated archive snapshots of those pages; industry sources are linked inline. If you spot something that has changed since, tell us and we will update the post."},{"slug":"when-ai-translations-break","title":"When AI Translations Break: What Actually Fails, and the Graduation Path","description":"LLM translation in CI works, until terminology drifts, a plural rule bites, or a native speaker calls the output insulting. What actually breaks in AI-only localization pipelines, why better prompts don't fix it, and how to add scoring, review and delivery without throwing your pipeline away.","date":"2026-07-01","category":"Guides","thumbnail":"\/img\/blog\/when-ai-translations-break\/thumbn
40ail.jpg","readTime":"7 min read","searchText":"title: 'When AI Translations Break: What Actually Fails, and the Graduation Path', description: 'LLM translation in CI works, until terminology drifts, a plural rule bites, or a native speaker calls the output insulting. What actually breaks in AI only localization pipelines, why better prompts don\\'t fix it, and how to add scoring, review and delivery without throwing your pipeline away.', date: '2026 07 01', updated: '2026 07 30', thumbnail: '\/img\/blog\/when ai translations break\/thumbnail.jpg', image: '\/img\/blog\/when ai translations break\/title.jpg', category: 'Guides', tags: ['ai', 'llm', 'machine translation', 'quality estimation', 'review', 'localization', 'i18n', 'governance', 'eu ai act', 'compliance'], faq: [ q: 'Why are my AI translations inconsistent?', a: 'Because each translation request is stateless. The model has no memory of how you translated a term last week, no glossary, and no brand voice definition, so \"Drive\" becomes three different words across your app, and formal\/informal address flips between screens. More prompting reduces this but cannot eliminate it: consistency is a data problem (a glossary and a translation memory), not a prompting problem.' , q: 'How do I add review to LLM translations without losing the automation?', a: 'Score first, review selectively. Quality Estimation rates every AI translation from 0 to 1; results above the threshold are saved directly, low confidence or issue flagged results are routed to a human review workflow. That keeps the pipeline fully automated for the majority of strings while a human sees exactly the ones that need eyes, in context on the running app, with an accept\/decline history.' , q: 'Do I still need a TMS if AI does the translating?', a: 'For a small project with few locales and no external users: honestly, often no. The management need appears with scale: multiple languages, non developer editors, terminology that must stay consistent, legal or compliance strings, and the question \"who approved this translation?\". At that point the TMS is not competing with the AI, it is managing it: same LLM, plus glossary context, quality scoring, review and CDN delivery.' , q: 'What is Quality Estimation for machine translation?', a: 'Quality Estimation (QE) is an automated score of how confident you can be in a machine or AI translation, without a human reading it first. Locize scores each AI translation from 0 to 1 and flags concrete issues; you set the threshold (0.7 by default) that decides what is saved directly versus routed to human review. It turns \"trust the model\" into a measurable, tunable gate.' , q: 'How do I prove my AI translations were human reviewed (EU AI Act Article 50)?', a: 'With a provenance record. Locize logs every accept\/decline decision with reviewer, timestamp, translation source (human, machine or AI) and the AI confidence score at decision time, and the provenance export packages this as a CSV + JSON report per version, language or namespace. Article 50 of the EU AI Act is in force as of August 2, 2026; text that went through human review with editorial responsibility is on the exemption path, and this export is the evidence you hand an auditor.' ] The honest ending of most \"should we buy a translation tool?\" debates in 2026 is: run the JSON through an LLM in CI and move on. It is fast, near free, and for a small app it produces something genuinely usable. We have said this ourselves, in public, on our why not just use AI page. This post is about what happens next, because there is a next. AI only translation pipelines do not fail loudly on day one. They fail quietly, months in, in a handful of specific and predictable ways. If you run one, this is a field guide to the failure modes, and to the graduation path that fixes them without throwing the pipeline away. Key facts What breaks: terminology drift, formality flips, plural\/ICU edge cases, legal strings shipped unreviewed, and no answer to \"who approved this?\" Why prompts don't fix it: consistency and accountability are data and workflow problems. A stateless model call has no glossary, no memory of last month's decisions, and no audit trail. The graduation path: keep your LLM (bring your own key), add glossary + styleguide context, score every translation (Quality Estimation), route only low confidence strings to human review, deliver over a CDN. When not to graduate: small project, few locales, no external users. AI only is a legitimate choice there. Compliance: Article 50 of the EU AI Act is in force as of August 2, 2026. A documented human review workflow is the exemption path for translated text, and the provenance export is its evidence. What actually breaks Terminology drift. Each model call is stateless. Nothing remembers that \"Drive\" is your product name, that \"Abo\" was the word you chose for subscription in German, or that your Spanish uses \"tú\" and n
40ot \"usted\". Across hundreds of strings and months of incremental translation runs, the same concept accumulates three or four renderings. Users notice before you do, because they see the screens side by side. Formality and voice flips. Related, but nastier: the register changes mid app. One screen addresses the user formally, the next casually. In languages where this distinction is grammatical (German, French, Japanese, Korean), an inconsistent register reads as broken, not as a style choice. Plurals and ICU edge cases. English has two plural forms; Polish and Arabic have more, with rules a model applies correctly in isolation and inconsistently in bulk. Interpolated variables inside ICU MessageFormat strings are easy to mangle in a batch run, and a broken placeholder is not a style problem, it is a runtime bug. Strings that carry risk. Legal notices, medical wording, pricing terms, accessibility labels. These are exactly the strings where \"the model is usually right\" is not an acceptable quality bar, and exactly the ones an unreviewed batch pipeline ships like any other string. No answer to \"who approved this?\" The first time a customer, a lawyer, or an auditor asks why the app said what it said in Italian, an AI only pipeline has one answer: a git commit by a bot. No reviewer, no decision trail, no quality score. For teams facing the EU AI Act's transparency obligations (Article 50, in force as of August 2, 2026), that question is no longer hypothetical; our Article 50 readiness check covers what machine translated content does and does not trigger. The public example of the whole pattern arrived in November 2025, when Mozilla moved its support content to AI first localization and its long standing Japanese volunteer community resigned in response. The most agreed criticism in that very long thread was not \"AI translated it\". It was that nothing enforced terminology and style guidelines, and native speakers found the result worse than nothing. That is the failure mode in one sentence: not translation quality on average, but ungoverned quality variance. Why better prompts don't fix it The instinctive fix is prompt engineering: paste the glossary into the prompt, add style instructions, re run. It helps, and it is also a treadmill: The context does not scale. Your glossary, style rules, and past decisions grow; context windows and attention do not keep up with \"here are 400 terminology decisions, apply all of them consistently across 3,000 strings\". There is no memory between runs. Last month's careful fixes are not training data for this month's batch. Fixed strings regress when a source string changes and gets re translated. There is still no gate. Even a perfect prompt produces output that ships unreviewed. The problem was never only translation quality; it is that nothing stands between the model and production. Consistency is a data problem (glossary, translation memory), quality is a measurement problem (scoring), and accountability is a workflow problem (review with history). None of the three is a prompting problem. The graduation path: keep the pipeline, add the layer Graduating from AI only does not mean hiring an agency or abandoning automation. Concretely, with Locize it looks like this; every piece is incremental: 1. Keep your model, give it context. Automatic translation runs on your own OpenAI, Gemini or Mistral key (or the built in service). Your glossary and styleguide are injected into every prompt, so the terminology and register decisions you have already made are enforced on every future string, automatically. 2. Score everything. Quality Estimation rates each AI translation from 0 to 1 and flags concrete issues. You choose the threshold (0.7 by default). 3. Review only what needs eyes. Confident translations save directly; low confidence ones route to the review workflow, where a reviewer sees them in context on the running app. Accept\/decline decisions are recorded with history, and the provenance export packages them as auditor ready CSV + JSON evidence. 4. Ship without redeploys. Approved translations publish over a global CDN. Your CI pipeline keeps running; the \"commit the JSON and redeploy for a typo\" step disappears. The net effect: the same LLM does the same work, but terminology stops drifting, risky strings get human eyes, and every translation in production has an answer to \"who approved this, and how confident were we?\". August 2, 2026: Article 50 is in force As of August 2, 2026, the EU AI Act's Article 50 transparency obligations apply â the Digital Omnibus postponed the high risk chapters, not these. The Commission's final guidelines (July 20, 2026) settled what that means for translation: faithful AI translations are exempt from machine readable marking, but AI translated text that informs the public on matters of public interest still needs a visible disclosure, and that duty falls away precisely when the content passed human review or editorial control with a person or company holding editorial responsibility. The guidelines' own example of the exemption is a human reviewed AI translation â which is to say, the graduation path above is not just quality hygiene: steps 2 and 3 are the exemption path. The Article 50 deep dive has the full legal picture. Proving it is the part most pipelines are missing. In Locize, the provenance export packages the evidence in one download: open the context menu of a version, language or namespace in the project overview and choose provenance to get a CSV + JSON report of who reviewed, approved or edited each translation and when, the translation source (human, machine or AI), the confidence score at decision time, and what is still pending review. \"This went through human review\" stops being a claim and becomes a document. The Article 50 workflow guide shows the end to end setup. When you should not graduate Honesty cuts both ways. If you run a side project, translate into two or three languages you can personally sanity check, and no revenue or compliance depends on the copy, an LLM in CI plus JSON in git is a perfectly sound setup, and cheaper than any tool. The graduation signals are concrete: a language nobody on the team reads, a translator or reviewer who is not a developer, a term that must never vary, a string a lawyer cares about, or a user facing quality complaint you could not trace. The week one of those appears is the week the management layer starts paying for itself. A zero commitment way to see where you stand: drop your locale files into the free i18n health check. It runs entirely in your browser (nothing is uploaded) and shows the missing keys, duplicate source values and interpolation mismatches your current pipeline has already produced. No locale files yet? Paste your public GitHub repository into the free i18n readiness check instead: it lists the strings that are still hardcoded and the one command that fixes them. If several of those signals sound familiar, start free with Locize, connect your existing pipeline (your key, your model), and turn on Quality Estimation for the next batch: you will see the score distribution of your current AI output before changing anything else. The why not just use AI page has the honest version of the whole trade off."},{"slug":"continuous-localization-deployment","title":"How Batch Translation Workflows Break Continuous Deployment","description":"A batch translation handoff is a release-blocking step hiding inside your pipeline. Here is exactly how it breaks continuous deployment, and what continuous localization wired into CI\/CD looks like instead.","date":"2026-06-25","category":"Engineering","thumbnail":"\/img\/blog\/continuous-localization-deployment\/thumbnail.jpg","readTime":"7 min read","searchText":"title: 'How Batch Translation Workflows Break Continuous Deployment', description: 'A batch translation handoff is a release blocking step hiding inside your pipeline. Here is exactly how it breaks continuous deployment, and what continuous localization wired into CI\/CD looks like instead.', date: '2026 06 25', thumbnail: '\/img\/blog\/continuous localization deployment\/thumbnail.jpg', image: '\/img\/blog\/continuous localization deployment\/title.jpg', category: 'Engineering', tags: ['localization', 'engineering', 'workflow', 'ci cd', 'continuous localization', 'i18next'], faq: [ q: 'What is continuous localization deployment?', a: 'Continuous localization deployment means translations flow into your product the same way code does: keys are created from the codebase as you write features, translated continuously (by AI, by your team, or both), and delivered to the running app without a code redeploy. There is no batch handoff where development pauses, source files are exported to an agency, and translated files are imported back weeks later. The translation pipeline runs in parallel with development and ships on its own cadence over a CDN.' , q: 'Why does batch translation break a CI\/CD pipeline?', a: 'A batch workflow inserts a manual, multi week, out of band step (export, send, wait, import, resolve conflicts) into a pipeline that is supposed to be automated and fast. Translations arrive after the feature already shipped, the reimport
40conflicts with code that moved on, and a one word copy fix forces a full redeploy. The result is either a localization backlog or a content freeze where you lock strings two to three months before launch. Both defeat the point of continuous deployment.' , q: 'How do you wire localization into CI\/CD without a batch handoff?', a: 'Three moving parts. First, new keys reach the translation management system from your code automatically (i18next saveMissing in development) instead of from a spreadsheet. Second, a CLI step in CI keeps the reference language and translations in sync and can fail the build on drift (locize sync). Third, you publish a pinned version at deploy time (locize publish version) so a release is atomic, while copy fixes between releases are delivered over the CDN with no redeploy. AI auto translation plus quality estimation fills the gap continuously, routing only low confidence strings to human review.' , q: 'How do I keep translation quality without a batch review gate?', a: 'You replace the agency batch gate with a continuous, automated one. Locize auto translates new keys (using your own OpenAI, Gemini, Mistral, DeepL or Lara key, or its built in AI), then scores each result with Quality Estimation on a 0 to 1 scale. Translations above the threshold (0.7 by default) are saved directly; anything below it, or flagged with a major issue, is routed into the human review workflow. Reviewers work in context inside the app rather than in exported files, so quality control happens per string, continuously, instead of in one big handoff.' ] Continuous deployment promises one thing above all: any change, from a one line bug fix to a new feature, can move from commit to production safely and on its own schedule. Most teams have spent years getting there. Then they add a second language, and a step quietly reappears in the middle of the pipeline that nobody automated: the batch translation handoff. It does not look like a deployment problem at first. It looks like a process: export the strings, send them to a translation vendor, wait, get files back, import them, resolve the conflicts, redeploy. But that round trip is a release blocking step wearing the costume of a workflow, and it breaks continuous deployment in specific, predictable ways. This is the engineer's version of why, and what the continuous alternative actually looks like when it is wired into CI\/CD. Key facts Batch translation: export to files, hand off to a vendor, wait, reimport, redeploy. A serialized, out of band step inside an otherwise automated pipeline. The break: translations land after the feature shipped, reimports conflict with code that moved on, and a one word fix needs a full redeploy. Teams compensate with a content freeze. Continuous localization: keys reach the TMS from your code, a CLI keeps things in sync in CI, and translations ship over a CDN without a redeploy. Quality, continuously: AI auto translation plus Quality Estimation handles the bulk; only low confidence strings are routed to human review. What continuous looks like, wired into the pipeline The fix is to treat translations the way you already treat code and config: they flow through the pipeline continuously, they have their own delivery channel, and they never block a release. Concretely, with i18next and Locize, there are three moving parts. 1. Keys reach the TMS from your code, not a spreadsheet When you write a new feature, the new translation keys should appear in the translation system the moment they exist in code. i18next's does this: any key that has no value yet is reported automatically. This runs in development, from the reference language only, so the source of truth for \"what needs translating\" is your actual code, not a manually maintained export. There is no batch to assemble because the list is always current. 2. A CLI step keeps things in sync inside CI In your pipeline, the locize CLI reconciles your local reference strings with the project and pulls translations back. It does a real diff (add, update, remove) rather than a blind overwrite, and you can make it conservative for automated runs: By default only inspects the reference language ( ) and backs up any segments it would remove before touching them. Run it with first to see the diff without writing. The point is that translation drift becomes a visible, scriptable step in CI instead of a manual merge after the fact. 3. Publish a pinned version at deploy time This is the part that actually makes a release atomic. Your app loads translations from a named version (think for the working copy, for what ships), and you publish that version at exactly the moment you deploy: Because the running app is pinned to a version rather than reading the live working copy, in progress edits never leak into production mid deploy. And because translations are delivered over a CDN, a copy fix published between releases reaches users without a redeploy. The i18next backend refetches on its own interval; you ship the German typo fix in seconds, not in a release. The release stays atomic and reversible. Copy changes between releases ride a separate, faster channel. Neither one blocks the other. For a deeper background on how this model evolved, see continuous localization and the original take on continuous development, integration and localization. Keeping quality without a batch review gate The honest objection to \"ship translations continuously\" is quality. The whole reason batches exist is the human review step. But you do not need a batch to get review; you need the review to be continuous and selective instead of all at once. When a new key arrives, Locize auto translates it. You can bring your own provider key (OpenAI, Gemini, Mistral, DeepL or Lara) or use the built in AI, and the result is then scored by Quality Estimation on a 0 to 1 scale. The routing is the important part: Translations above the threshold are saved and can auto publish. Translations below the threshold , or flagged with a major issue, are routed into the human review workflow . So instead of one person checking thousands of str
40ings in an exported file once a quarter, your reviewers see only the strings that actually need a human, in context, as they appear. A glossary and styleguide keep terminology and brand voice consistent across all of it. The review gate still exists; it just stopped being a batch. Roles (admin, manager, publisher, translator), per language and per namespace scopes, and an in context editor mean translators and reviewers work directly against the live project. There is no export to send out and no file to merge back. How to get off batch You do not have to rebuild everything at once. A pragmatic migration: 1. Pin your app to a version. Point production at a named version (for example ) instead of the live working copy. This alone makes deploys atomic. 2. Move the freeze to a publish. Replace the content freeze with publishing that version at deploy time. Strings stay editable up to the moment you ship. 3. Put in CI. Add the CLI sync step so reference language drift is caught automatically, starting with until you trust it. 4. Turn on auto translation plus QE. Let AI cover the volume and route only low confidence strings to humans, so the review queue is small and continuous. 5. Branch the risky changes. For a big rename or restructuring, use a branch project so the experiment never touches the production version until it is merged. Each step removes one piece of the batch handoff. By the end, translation is just another thing your pipeline does continuously, and \"wait for translations\" is no longer a line item in your release plan. Where Locize fits Continuous deployment broke the batch model for code a decade ago. The same logic applies to the strings: a serialized, manual, stateful handoff has no place in an automated pipeline. Locize is built around that idea, keys from your code, a CLI for CI, version pinned publishing, CDN delivery, and AI translation gated by Quality Estimation, so localization stops being the step that blocks the release. If your translation process still has a \"send the files out and wait\" phase, that is the part of your pipeline continuous deployment never reached. See how continuous localization works, or create a free Locize account and wire it into your next deploy."},{"slug":"browser-translates","title":"The browser can translate your app now. Here's what it can't do.","description":"Chrome 138 and Edge 148 ship a free, on-device Translator API that translates any page instantly, offline, and privately. It is genuinely useful, and it is not a translation management system. Here is the honest demo, the governance gap, and a recipe that uses the browser as a sanctioned fallback while your TMS stays the governed core.","date":"2026-06-17","category":"Guides","thumbnail":"\/img\/blog\/browser-translates\/thumbnail.jpg","readTime":"9 min read","searchText":"title: 'The browser can translate your app now. Here\\'s what it can\\'t do.', description: 'Chrome 138 and Edge 148 ship a free, on device Translator API that translates any page instantly, offline, and privately. It is genuinely useful, and it is not a translation management system. Here is the honest demo, the governance gap, and a recipe that uses the browser as a sanctioned fallback while your TMS stays the governed core.', date: '2026 06 17', thumbnail: '\/img\/blog\/browser translates\/thumbnail.jpg', image: '\/img\/blog\/browser translates\/title.jpg', category: 'Guides', tags: ['localization', 'i18n', 'ai', 'browser', 'translator api', 'chrome', 'edge', 'i18next', 'machine translation', 'tms'], faq: [ q: 'Can the browser translate my web app without a translation service?', a: 'Yes. Chrome 138+ and Microsoft Edge 148+ ship a built in Translator API that runs a translation model on the device. It is free, works offline after the model downloads, and never sends text to a server. But it works on desktop only (no mobile), translates the rendered text at display time rather than your source strings, and has no concept of keys, review state, terminology, quality scoring, or server side rendering. It is a great enhancement and not a replacement for a translation management system.' , q: 'Does the Chrome and Edge Translator API replace a TMS?', a: 'No. The Translator API translates text that is already on screen, in the visitor\\'s browser, after the page has rendered. It has no translation keys or file structure, no record of who reviewed or approved a translation, no terminology or brand voice control, no quality estimation, no plural or interpolation handling, and the translated DOM is invisible to search engine crawlers and to server side rendering. A TMS governs the translation; the browser only displays one. They solve different problems and work best together.' , q: 'Is the browser Translator API a cross browser web standard?', a: 'Not a settled one. The two Chromium browsers ship it (Chrome since version 138, Edge since version 148). Mozilla has filed a negative standards position on the Web Translation API, and WebKit has not taken a position. The API is incubating in the W3C Web Machine Learning Working Group, so the shape can still change. Treat it as progressive enhancement that some visitors get, not as a feature you can rely on everywhere.' , q: 'Can I use the browser Translator API as a fallback with i18next and Locize?', a: 'Yes, and that is the recommended pattern. Wire it into
40i18next\\'s missing key flow: when a key has no translation in the active language, render the source text immediately, translate it on device for visitors whose browser supports the API, and let i18next saveMissing report the key to Locize. On the next publish, a proper translation with quality estimation and human review replaces the on device guess. The browser covers the gap for free while the governed translation catches up.' ] In June 2026 the \"do I still need a translation tool?\" question got a new edge. On June 2, Microsoft announced that Microsoft Edge 148 ships a built in Translator API backed by on device models covering more than 145 languages , free and private. Google's Chrome has had the same API stable since Chrome 138 (June 2025), today covering 37 languages and language variants. Two of the most used browsers on the planet can now translate any page, locally, for nothing. So it is worth asking honestly: if the browser translates your app for free, do you still need a translation management system? The short answer: the browser translates, the TMS governs. They are not competing for the same job. This post is the honest version of why, with a working recipe that puts the browser to work as a
40sanctioned fallback while your translations stay governed. Key facts Chrome: Translator API and Language Detector API stable since Chrome 138 (June 2025), 37 languages and variants, desktop only Edge: Translator API available from Edge 148 (announced June 2, 2026), on device, 145+ languages How it works: a task specific model is downloaded on first use, then runs locally. Free, offline capable, nothing leaves the device Not a standard yet: only the two Chromium browsers ship it. Mozilla filed a negative standards position; WebKit has taken none What it is: a display time enhancement for rendered text. What it is not: keys, review state, terminology, quality scoring, SSR, SEO, or mobile coverage The governance gap A translation management system is not in the business of turning one string into another. It is in the business of making translation a controlled, reviewable, deliverable process across a team and over time. The browser API does none of that, by design, and it is worth being concrete rather than dismissive about exactly what is missing. No keys, no structure. The API translates a string you hand it. It has no idea that this string is , that it lives in the namespace, that it has a plural sibling, or that it already has an approved French translation you spent money on. It translates text, not your content model. Everything downstream of \"we have a structured catalog of keys\" simply does not exist here. No review state, no approval evidence. There is no record that a human looked at the German translation of your refund policy and signed off on it. That record is increasingly not optional: under the EU AI Act, the path that keeps machine translated public interest content out of the visible disclosure obligation runs through documented human review, and a translation produced fresh in the visitor's browser has, by definition, no such review attached (we wrote up that obligation and the review workflow exemption separately). Compliance review cannot happen client side after the fact. No terminology or brand voice control. Your product calls it a \"workspace,\" not an \"office,\" and your tone is informal \"du\" in German, not formal \"Sie.\" The browser model does not know your glossary or style guide, and there is no way to tell it: the Translator API is a sealed, task specific translation model, not an instructable LLM, so it has no prompt or system instruction channel to inject terminology, tone, or translation memory through. Every visitor can get a slightly different, off brand rendering of the same button. No quality estimation. When the model gets a translation wrong, nothing flags it. There is no confidence score, no routing of the doubtful cases to a human. Quality Estimation and a review workflow are exactly the safety net that on device translation removes. No format fidelity. Plurals, gendered forms, interpolation ( , ), nested components inside a sentence: these are i18n problems, not sentence translation problems. Hand a model a string with a placeholder in it and you are gambling on whether the placeholder survives in the right place. ICU plural rules are not something a display time translate call reasons about. No SSR, no SEO. This is the big one for a public site. The browser translates the DOM after it renders, in the visitor's browser. Search engine crawlers, link previews, and your own server side rendering see the original language only. A page translated by the browser is, to Google, an untranslated page. You cannot rank in a market whose language only ever exists client side. Mobile coverage gaps. Chrome's Translator and Language Detector APIs are documented as desktop only; they do not work on mobile devices. A large share of your users are on phones, where this entire mechanism is currently absent. Not a settled standard. Only the two Chromium browsers ship it. Mozilla has registered a negative position on the Web Translation API and is pursuing a counterproposal, and WebKit has not taken a position at all. The API is incubating in the W3C Web Machine Learning Working Group, which means its shape can still change. Building a core experience on it today is building on one engine family's preview, not on the web platform. None of this makes the browser API bad. It makes it a display technology. The mistake would be to treat a display technology as a content management te
40chnology. The architecture: the browser translates, the TMS governs Put the two where they belong and they stop competing: The governed core. Your real translations live in a TMS: structured by key and namespace, translated by AI and machine translation with your glossary and style guide as context, scored by quality estimation, reviewed by humans where it matters, versioned, and delivered to every browser and crawler and phone via CDN. This is the content you stand behind, the content that ranks, the content an auditor can trace. The sanctioned fallback. For the gaps, the languages you have not shipped yet, the brand new key that went live an hour ago, the long tail locale you will never staff, let the browser fill in. Instantly, for free, for the visitors whose browser can. It is a graceful degradation, not the product. The trick is to wire them together so the fallback is temporary and self healing: every time the browser has to translate something, that fact becomes a signal that flows back into the governed core and gets it properly translated for next time. The recipe: i18next missing key fallback, self healing into Locize Here is that loop, concretely, with i18next and Locize. The idea: 1. A key has no translation in the active language. i18next renders the source language text (its normal fallback) and fires . 2. reports the key to Locize, where automatic translation and quality estimation get to work and a human can review. 3. Meanwhile, for visitors on a supporting browser, the on device Translator API translates the fallback text right there, so they see their language immediately instead of English. 4. On the next publish, the proper, reviewed translation is in Locize and on the CDN. The key now exists in the target language, the fallback no longer triggers, and the governed translation has quietly replaced the on device guess. First, the i18next side. The Locize backend reports missing keys for you: Now the display time fallback. A small hook reads a key; if i18next had to fall back to another language, it asks the browser to translate the fallback text on device, and swaps it in when ready: And in a component, it reads like any other translation: A brand new that only exists in English will: render \"Pay now\" instantly for everyone, show \"Jetzt bezahlen\" a moment later for a visitor on desktop Chrome or Edge, and report itself to Locize so that within one publish cycle every visitor, on every browser and every phone and every crawler, gets a reviewed, quality scored German translation from the CDN. The fallback heals itself. Honest caveats Desktop Chrome 138+ and Edge 148+ only. Everyone else (Firefox, Safari, every phone) gets the fallback text, which is fine, that is the whole point of progressive enhancement. Do not let anything important depend on the on device path firing. Keep the write key out of the client. Reporting missing keys needs a write scoped credential. Run in development or staging, or proxy it through your own endpoint, rather than shipping an API key in a production bundle. The on device translation itself needs no key and is safe to ship. It is a stopgap, not the translation. The on device output is unreviewed, unscored, and off glossary. It buys you a better first impression while the governed translation is produced. Never treat it as final. First use downloads a model. The very first translation for a language pair triggers a one time model download, so the first visitor in a session may see the fallback text for a beat longer. The callback lets you surface progress if you want. One forward looking note, and only a note: this same missing key to fallback wiring is the natural seam where on demand translation features tend to grow, so it is a useful pattern to have in place regardless of where the browser APIs land. No promises, just a good place to stand. Where Locize fits The browser is a fine translator. It is not a place to manage translations, and it was never trying to be. Locize is the governed core the fallback heals back into: structured keys and namespaces, automatic AI translation with your glossary and style guide, Quality Estimation on every AI translation, a review workflow and full history for the translations you stand behind, and CDN delivery so the result reaches every browser, every phone, and every crawler, not just the visitors who happen to be on desktop Chromium. Use the browser for what it is genuinely good at, instant, free, private, display time translation, and keep the governance where it belongs. If you want the governed core under that fallback: create a free Locize account, turn on automatic translation and Quality Estimation, and wire to report your missing keys. The browser translates. Your TMS governs."},{"slug":"ai-act-article-50","title":"Is machine-translated content \"AI-generated\" under the EU AI Act?","description":"Article 50 of the EU AI Act applies from August 2, 2026, and was not delayed by the Digital Omnibus. The Commission's final guidelines (July 20, 2026) exempt faithful AI translations from machine-readable marking, and name human-reviewed AI translation as the worked example of the Article 50(4) exemption. What that means for translated websites and apps.","date":"2026-06-13","category":"Guides","thumbnail":"\/img\/blog\/ai-act-article-50\/thumbn
40ail.jpg","readTime":"11 min read","searchText":"title: 'Is machine translated content \"AI generated\" under the EU AI Act?', description: 'Article 50 of the EU AI Act applies from August 2, 2026, and was not delayed by the Digital Omnibus. The Commission\\'s final guidelines (July 20, 2026) exempt faithful AI translations from machine readable marking, and name human reviewed AI translation as the worked example of the Article 50(4) exemption. What that means for translated websites and apps.', date: '2026 06 13', updated: '2026 09 09', thumbnail: '\/img\/blog\/ai act article 50\/thumbnail.jpg', image: '\/img\/blog\/ai act article 50\/title.jpg', category: 'Guides', tags: ['localization', 'i18n', 'ai', 'machine translation', 'eu ai act', 'compliance', 'transparency', 'review', 'workflow'], faq: [ q: 'Is machine translated content considered AI generated under the EU AI Act?', a: 'For the machine readable marking obligation of Article 50(2): no, in the normal case. The European Commission\\'s final transparency guidelines (July 20, 2026) list \"AI generated translations of text\" among the standard editing examples that benefit from the Article 50(2) exception, provided the translation does not materially change the meaning, style or intent of the text. That reverses the May 2026 draft, which had listed translations among the semantic changes requiring marking; AI generated summaries and paraphrases stay marking required. The separate visible disclosure obligation for text in Article 50(4) can still apply: it covers text published with the purpose of informing the public on matters of public interest, and it falls away where the content has undergone human review or editorial control and a natural or legal person holds editorial responsibility. The final guidelines\\' own example of that exemption is an AI supported translation of a human written article whereby the translation has undergone human review.' , q: 'Did the EU delay the AI Act transparency rules for AI generated content?', a: 'No. The Digital Omnibus agreement of May 2026 postponed the high risk obligations (Annex III systems to December 2, 2027, Annex I systems to August 2, 2028), but the Article 50 transparency obligations still apply from August 2, 2026. The only softening is a grace period for generative AI systems already on the market before that date: they have until December 2, 2026 to meet the machine readable marking requirement of Article 50(2). Newly deployed systems must comply from August 2, 2026.' , q: 'Does the EU AI Act require a visible \"translated by AI\" label on websites or apps?', a: 'In most cases, no. The marking obligation in Article 50(2) sits with the provider of the AI system, is machine readable rather than a visible banner, and per the final guidelines does not cover faithful AI translations at all (standard editing exception). A visible disclosure under Article 50(4) is only required for AI generated or manipulated text that is published with the purpose of informing the public on matters of public interest, for example public health or safety information, and even then only if the content has not undergone substantive human review with someone holding editorial responsibility. Typical UI strings, product copy, and entertainment content fall outside that disclosure duty.' , q: 'How does the human review exemption in Article 50(4) work for translated content?', a: 'Two cumulative conditions must be met: the AI generated or manipulated text has undergone a process of human review or editorial control, and a natural or legal person holds editorial responsibility for the publication. The Commission\\'s final guidelines (July 20, 2026) construe this narrowly: human review means deliberate examination of the substance of the content by people with relevant knowledge and professional judgement, with fact checking as a minimum ingredient. Spell checking, grammar fixes, automated review processes, or cursory approval without substantive engagement do not qualify; AI edits made after editorial sign off void the exception; and the identity and contact details of the person holding editorial responsibility should be publicly findable. The guidelines\\' own example of text that qualifies is an AI supported translation of a human written article whereby the translation has undergone human review. In practice that means a documented review workflow that can show who reviewed and approved which translation.' ] From August 2, 2026 , Article 50 of the EU AI Act requires AI generated content to be identifiable as such. Whether a machine translation of human written text counts as \"AI generated\" is one of the questions the Act never answers explicitly, and for anyone running a localized website or app it is the question that decides whether these rules apply to them at all. Update, July 2026: when we first published this article, the Commission's draft guidance pointed to yes , and we flagged that the guidelines were draft and might shift. They did. The final guidelines of July 20, 2026 (C(2026) 5054) moved AI translations to the exempt side of the marking obligation, and made a human reviewed AI translation their worked example of the Article 50(4) exemption. This article has been updated throughout; the practical to do list at the end survived the reversal unchanged, which was the point of building it on the exemption rather than on the unsettled question. This is not legal advice. This article summarizes public legal texts and guidance for orientation. The guidelines cited here are final since July 20, 2026 but non binding; authoritative interpretation of the AI Act rests with the CJEU. For decisions about your own obligations, consult a qualified lawyer. Key facts In force: Art
40icle 50 transparency obligations apply from August 2, 2026. The Digital Omnibus did not delay them Only softening: generative AI systems already on the market before August 2, 2026 get until December 2, 2026 to implement machine readable marking Machine translation: the Commission's final guidelines (July 20, 2026) list \"AI generated translations of text\" among the standard editing examples exempt from Article 50(2) marking, reversing the May draft. AI summaries and paraphrases still require marking Visible disclosure (Article 50(4)) only applies to text published to inform the public on matters of public interest Exemption: no disclosure needed where the text has undergone human review or editorial control and a person holds editorial responsibility. The final guidelines' own example: an AI supported translation of a human written article whereby the translation has undergone human review Penalties: up to EUR 15 million or 3% of total worldwide annual turnover, whichever is higher July 20, 2026 The Commission adopts the final Article 50 guidelines (C(2026) 5054), replacing the May 8 draft. Non binding, but the reference for how authorities will read Article 50 July 31, 2026 Initial signatory list of the transparency Code of Practice published: 83 providers (including OpenAI, Google, Mistral, Anthropic) and 152 deployers August 2, 2026 Article 50 transparency obligations apply (Article 113 AI Act). Any AI system deployed from this date must comply in full December 2, 2026 End of the grace period for machine readable marking (Article 50(2)) for generative AI systems already on the market before August 2, 2026 December 2, 2027 Delayed deadline for Annex III high risk systems (biometrics, employment, credit, public services). Not about content transparency August 2, 2028 Delayed deadline for Annex I high risk systems (AI in regulated products). Not about content transparency The Omnibus changes are a provisional political agreement (May 2026) still awaiting formal adoption, as law firm briefings like Gibson Dunn's summary note. The August 2, 2026 date for Article 50 is not part of those changes: it stands in the Act as adopted. Non compliance can be fined with up to EUR 15 million or 3% of total worldwide annual turnover, whichever is higher. Is machine translation \"AI generated\"? Asked and, since July 20, answered Here is the genuinely interesting legal question. Machine translation does not create content from nothing: a human wrote the source text, the AI only moves it into another language. Is the result \"artificially generated or manipulated\" content? The case for \"no\" The strongest argument that machine translation falls outside Article 50(2) is the Act's own exception, quoted above: systems that \"do not substantially alter the input data provided by the deployer or the semantics thereof \" are exempt from marking. A faithful translation is, by definition, meaning preserving. If the semantics survive the language transfer intact, the argument goes, the output is the deployer's human authored content in a different surface form, not synthetic content. Translation tools also long predate generative AI, and nothing in the Act's recitals singles them out. The case for \"yes\" The counter argument: every sentence an MT system outputs is text the model generated. Word choice, register, sentence structure, terminology: all of it is model output, and all of it can be wrong in ways that change meaning. A translation is not an edit of the source text; it is new text in a language the source never existed in. This was the reading the Commission's draft guidelines of May 8, 2026 took: they listed \"AI generated translations and summaries of text\" as their very first example of semantic changes requiring marking. The final guidelines picked \"no\" for translations The final guidelines of July 20, 2026 resolve the question the other way. The consultation pushback on exactly this point (documented in briefings like Covington's 10 takeaways) landed: in the final examples of \"standard editing and minor alterations benefitting from the exception under Article 50(2) AI Act\", the Commission now lists \"Grammar correction and spellchecking, linguistic and minor stylistic polishing that do not change the substance, meaning, style or messaging of text, AI generated translations of text\" while the marking required list keeps \"AI generated summaries of text; paraphrasing or rewriting text that changes style, structure and meaning beyond mere grammatical and minor stylistic correction\" So a faithful AI translation is treated as standard editing of human authored content: no machine readable marking duty. A summary or a free rewrite is not. The boundary is the general test the guidelines state for the exception: the output must not change the content \"in a material way\" affecting its meaning, style or intent , assessed case by case. A translation that edits, condenses, or re angles the source on the way through can cross back into marking territory. Where that leaves you Three caveats keep this from being a free pass: The guidelines are final but non binding . They are the Commission's stated reading, the reference point for market surveillance authorities; the last word belongs to the CJEU. The marking duty in Article 50(2) sits with the AI system's provider anyway, not with the company using MT for its website. As a deployer your direct exposure is Article 50(4). The provider side is organizing accordingly: the initial signatory list of the Commission's transparency Code of Practice (July 31, 2026) counts 83 providers, including OpenAI, Google, Mistral, Anthropic, Microsoft and Meta. And Article 50(4) is narrow , but alive for translation. The disclosure duty only covers text \"published with the purpose of informing the public on matters of public interest\": think public health information, safety guidance, reporting on political or economic developments, investor information. The guidelines explicitly exclude fiction, entertainment, and ordinary advertising (unless it makes health, safety or sustainability claims). Most localized UI strings and product copy never enter its scope, but an AI translated help center article on product safety, a translated corporate report, or translated public service information can. A useful summary of the obligations is the Article 50 text and the practical guide on artificialintelligenceact.eu. For the content that does fall under Article 50(4), everything turns on the exemption. The exemption that matters: human review and editorial responsibility Article 50(4) does not apply, verbatim, \"where the AI generated content has undergone a process of human review or editorial control and where a natural or legal person holds editorial responsibility for the publication of the content.\" The final guidelines construe this narrowly, and the wording is worth reading closely. Human review means \"the deliberate examination of the substance of the content by one or more natural persons possessing relevant knowledge and professional judgement pertaining to the subject matter under scrutiny\" with fact checking the accuracy of the content named as \"a minimum requirement that should be part of that review\". And explicitly not: \"Superficial, solely formal or procedural checks (e.g. spell checking or grammatical correction), the mere existence of an editorial policy, automated review processes or cursory editorial approval without substantive engagement by the human reviewer or the editorial entity, cannot fulfil the conditions for human review or editorial control.\" Two further points are easy to miss. First, order matters: if AI modifies, supplements or reformulates the content after editorial sign off, the exception becomes void; review has to be the last substantive touch before publication. Second, the second condition, editorial responsibility, means a named natural or legal person holds ultimate responsibility for the publication, and the guidelines expect their identity and contact details to be publicly findable (a website's terms or legal notice is given as an example). And translation is not a hypothetical here: the guidelines' own list of examples that satisfy the exception includes, verbatim, \"AI supported translation of a human written article whereby the translation has undergone human review.\" That sentence is this article's whole subject, resolved
40in one example. What the guidelines effectively demand is not a feeling of having reviewed things, but a documented editorial workflow with identified responsible persons . If a regulator asks, \"this went through human review\" needs to be demonstrable: who reviewed it, what they could change, who approved publication. For deployers who want a formal vehicle on top, the Commission's Code of Practice on transparency of AI generated content was assessed as adequate under Article 50(7) precisely for demonstrating these conditions, and adherence is open to deployers (Section 2 of the Code). As of September 9, 2026, the signatory list names the large model and platform providers whose engines translation workflows commonly use, and one translation technology company under Section 1, but no other localization vendor by name; consistent with faithful translations sitting outside the marking duty, and a reminder that adherence is voluntary: staying off the list implies nothing about compliance. A documented review workflow is the evidence layer either way. How to be safe under either reading This is the practical part, and it is shorter than the legal part, because it was built to survive either answer to the MT question, and it did: 1. Route machine and AI translations through human review. Not necessarily all of them; review where it matters and where confidence is low (see below). 2. Make the review substantive. Reviewers need competence in the language and the subject matter, and the authority to approve, change, or reject the translation. A rubber stamp click does not meet the bar the draft guidelines set. 3. Record who reviewed and approved what, and when. The exemption is only worth something if you can show the process happened. 4. Name who holds editorial responsibility for published content, and make that publicly findable (legal notice, terms, colophon). 5. Ask your MT\/AI providers about machine readable marking. Under Article 50(2) that part is their obligation for generative output; per the final guidelines, faithful translation output is exempt from marking, while summaries and rewrites are not. The logic was deliberately either way, and the reversal proved it out: For translated text that falls under Article 50(4)'s public interest scope, your reviewed content sits squarely in the human review exemption, which the final guidelines illustrate with exactly this case. For everything else, you have lost nothing: the same workflow is simply how you catch the mistranslations that were going to embarrass you anyway. Compliance pressure and translation quality point at the same workflow. That is rare, and worth using. Where Locize fits Locize is built around exactly the workflow the exemption path needs: The review workflow turns translations into pending proposals that a human reviewer with the right permissions must accept or reject: deliberate, substantive engagement, per segment. Quality Estimation scores every AI translation with a confidence estimate, and the Review AI workflow routes low confidence translations into review automatically. Your reviewers' substantive attention goes where the AI is least sure, instead of being spread thin across everything. (Background in the Quality Estimation announcement.) The history of every segment records when and how each translation changed and who changed or approved it, so \"this went through human review\" is something you can show, not just assert. The provenance export packages this evidence in one action, per version, language or namespace: a report as CSV and JSON listing who reviewed or approved each translation and when, the AI confidence score at the moment of the decision, what is still pending review, and a summary header so the file stands on its own in front of an auditor. User management lets you give reviewers and approvers distinct roles, which maps cleanly onto \"identified responsible persons\". To be clear, and in the spirit of the disclaimer above: no tool makes you compliant with the AI Act, and Locize does not either. What it gives you is the documented, substantive, person attributable review process that the Article 50(4) exemption asks for, the process the final guidelines illustrate with a human reviewed AI translation. If you want your translation workflow on that footing: create a free Locize account and enable the review workflow and Quality Estimation for your languages. The step by step setup, including the provenance export and what each review status means for an auditor, is documented in Running an Article 50(4) compatible review workflow in Locize. The question in the title has an official answer now. Whether your workflow is on the right side of it is the part you control."},{"slug":"inlang-interop","title":"You don't have to choose: i18next and inlang, together","description":"i18next-cli init --inlang scaffolds an inlang project on your existing translation files: Sherlock, Fink and Paraglide work directly on your i18next JSON, Locize stays the hosted TMS on the same files, and nothing migrates.","date":"2026-06-12","category":"Product","thumbnail":"\/img\/blog\/inlang-interop\/thumbn
40ail.jpg","readTime":"5 min read","searchText":"title: \"You don't have to choose: i18next and inlang, together\", description: 'i18next cli init inlang scaffolds an inlang project on your existing translation files: Sherlock, Fink and Paraglide work directly on your i18next JSON, Locize stays the hosted TMS on the same files, and nothing migrates.', date: '2026 06 12', thumbnail: '\/img\/blog\/inlang interop\/thumbnail.jpg', image: '\/img\/blog\/inlang interop\/title.jpg', category: 'Product', tags: ['localization', 'i18n', 'i18next', 'inlang', 'paraglide', 'sherlock', 'interoperability', 'workflow', 'announcement'], faq: [ q: 'Can I use inlang tools like Sherlock, Fink, or Paraglide without migrating away from i18next?', a: 'Yes. Run npx i18next cli init inlang (i18next cli ⥠1.63) in your project and it scaffolds a project.inlang\/settings.json that points the inlang i18next plugin at your existing translation files. Locales and the file layout are derived from your i18next cli config, including namespaces. Your i18next JSON stays the single source of truth: Sherlock edits it inline in VS Code, Fink edits it in the browser, and Paraglide compiles from it. Nothing is converted, copied, or migrated.' , q: 'Does Paraglide replace i18next?', a: 'No. It is a different runtime model (compiled, tree shakable message functions) that can now share your i18next translation files through the inlang i18next plugin. That makes it an option you can adopt where it fits, say a new SvelteKit app next to an existing i18next product, while both read the same JSON and your translation workflow stays unchanged. Your existing i18next apps keep running exactly as before.' , q: 'Where does Locize fit if Fink also edits the files?', a: 'They are complementary, not competing. Fink is a lightweight git based editor working on the files in your repository. Locize is the hosted TMS on top of the same i18next JSON: ordered workflows for translators, review steps, AI auto translation with confidence scores, translation memory, glossary, versioning, and CDN delivery so fixes go live without redeploys. Teams typically sync the repo files with Locize via i18next cli locize sync and let translators work wherever they are most productive.' , q: 'How reliable is the i18next â inlang round trip really?', a: 'Verified, not assumed. We tested the full path (nested keys, namespaces, plurals, context both plain and combined with plurals, zero, ordinal keys, and count, number format options), found six interop bugs across the plugin, SDK, and compiler, and both sides fixed all of them within a couple of hours. The fixes shipped as @inlang\/plugin i18next 6.2.0, @inlang\/sdk 2.10.0, and @inlang\/paraglide js 2.19.0, and we re verified the complete matrix (15\/15) against the published packages. The scaffold pins the exact verified plugin version.' ] If you use i18next, the inlang ecosystem has probably been presented to you as a destination : migrate your setup, adopt a new format, switch your workflow. And so most i18next teams never touched tools like the Sherlock VS Code extension, the Fink web editor, or the Paraglide compiler, even when one of them would have been genuinely useful. That either\/or was never necessary. Your translation files are the interface: if inlang tools can read and write i18next JSON faithfully, you can use both ecosystems on the same project. As of this week, they can. Verified, fixed where it was broken, and one command away: What that unlocks Sherlock (VS Code): see and edit translations inline where the keys are used, on your real files. Fink (browser): hand a translator a link; edits land in the same JSON via git. Paraglide (compiler): compile the same files into tree shakable, fully typed message functions, for example for a new SvelteKit or SolidStart app sitting next to your existing i18next product: Plurals, context (plain and combined with plurals), , ordinal keys, namespaces, and formatting all behave the way i18next defines them. See below for why we can say that with a straight face. Why this works now: six bugs, fixed in a couple of hours \"Interop\" claims are cheap, so we tested the whole path end to end first: i18next v4 JSON through the inlang i18next plugin, SDK, and Paraglide compiler, plus the write back path, because editing tools like Sherlock and Fink must be able to save . The core held up well, and the rough edges were real. Six bugs across the plugin, SDK, and compiler: context keys silently resolving to the base variant, context projects that couldn't be saved at all, namespaced projects failing on write back, formatting silently dropped, never matching at , and ordinal keys misparsed as a context. What happened next is the part worth writing about: we filed all six with reproductions, and Samuel Stroschein and the inlang team turned their half around within a couple of hours , reviewed and merged our plugin fixes just as fast, and released everything: 6.2.0, 2.10.0, 2.19.0. The plugin is first class maintained on their side. That commitment, plus the speed, is what makes building a bridge on top of it a safe bet. We then re verified the complete test matrix against the published packages: 15\/15 green, with the plugin loaded from the CDN exactly as your project will load it. The inlang team published their own announcement of the integration. The pattern repeated once more while writing this post: taking the Sherlock screenshot above surfaced a seventh bug (Sherlock silently showed no annotations at all for i18next projects, and had for a long time). Reported with a one line fix, merged and released as plugin 6.2.1 within hours. The screenshot shows the fixed behavior. Where Locize fits The same files that Sherlock and Paraglide now read are the files Locize synchronizes as your hosted TMS: That means the division of labor stays clean. Developers work in the repo, with Sherlock inline or Paraglide compiled. Translators work where it suits them: Fink for quick git based edits, Locize for the full workflow with review steps, AI auto translation with confidence scores, translation memory, glossary, versioning, and CDN delivery so translation fixes go live without redeploying. One set of files, every tool reading and writing it in place. Honest details The plugin version is pinned on purpose. The scaffold writes , not a floating : jsDelivr serves range aliases from edge caches that can lag releases by days and differ between locations. We watched serve a two releases old plugin after 6.2.0 shipped. A pinned URL means every teammate and CI run gets the same, verified plugin. Bump the URL in deliberately when newer versions ship. Only is scaffolded, by design. is inlang's unpacked (git friendly) project form; inlang tools generate and manage its other files ( , , ) on first use, so expect a few new files there after opening the project with Sherlock or Paraglide. Namespaces are discovered at scaffold time. If you add a namespace later, add its line to the in ; a re run of deliberately won't touch an existing file. JSON resource files only. The inlang i18next plugin reads JSON; YAML\/JS resource layouts are skipped with a notice. Get started In a project with an i18next cli config (or let the wizard create one): Open the folder in VS Code and install the recommended Sherlock extension, send a translator the Fink link, or point Paraglide's compiler at . And keep syncing the very same files to Locize for the managed end of the workflow. The full option reference is in the i18next cli README, and the plugin lives on the inlang marketplace. Two ecosystems, one set of files. You really don't have to choose."},{"slug":"i18next-cli-localize","title":"One command from hardcoded strings to a localized app","description":"npx i18next-cli localize takes a mono-lingual app (often AI-generated) through instrumenting, key extraction, Locize setup, and AI auto-translation in a single run, ending with confidence-scored translations and CDN delivery.","date":"2026-06-11","category":"Product","thumbnail":"\/img\/blog\/i18next-cli-localize\/thumbnail.jpg","readTime":"4 min read","searchText":"title: 'One command from hardcoded strings to a localized app', description: 'npx i18next cli localize takes a mono lingual app (often AI generated) through instrumenting, key extraction, Locize setup, and AI auto translation in a single run, ending with confidence scored translations and CDN delivery.', date: '2026 06 11', thumbnail: '\/img\/blog\/i18next cli localize\/thumbnail.jpg', image: '\/img\/blog\/i18next cli localize\/title.jpg', category: 'Product', tags: ['localization', 'i18n', 'ai', 'cli', 'i18next', 'automation', 'workflow', 'announcement'], faq: [ q: 'How do I localize an AI generated app (v0, Lovable, Bolt, Cursor)?', a: 'Run npx i18next cli localize in the project root (i18next cli ⥠1.62). It detects your stack, wraps hardcoded strings in t() calls with your interactive review, extracts the keys into locale files, and connects to Locize (guided signup; your target languages are created automatically on the first sync). It then requests AI auto translation, which is enabled by default for new projects, and downloads the translated files once they arrive. React and Next.js are transformed natively; Vue and Svelte work via community plugins.' , q: 'Does i18next cli localize overwrite my code?', a: 'The instrument step rewrites source files, but with guardrails: it is interactive by default (you approve each change per string), a dirty git working tree triggers a confirmation prompt first, dry run previews every step without writing anything, and re runs are idempotent, so already wrapped strings are not re instrumented. Treat it as an assistant, not a compiler: review the diff before committing, especially for Next.js App Router server components.' , q: 'What does it cost and what do I need?', a: 'The CLI is free and open source (MIT). You need a Locize account;
40 signup is free and the command guides you through it. No manual language setup is needed, because your target languages are created automatically on the first sync. Auto translation and Quality Estimation are enabled by default for new projects; the AI translations run once the project is subscribed or you configure your own AI\/MT provider key (OpenAI, Gemini, Mistral, â¦).' , q: 'Can my AI coding agent run the localization for me?', a: 'Yes. npx i18next cli localize print agent prompt prints a copy paste prompt for Claude Code, Cursor, or any coding agent: step by step instructions using the individual CLI commands, version matched to your installed CLI so it never drifts from what the supercommand does. The agent detects, instruments, extracts, syncs, and verifies, and only asks you for the Locize credentials.' ] AI coding tools changed who ships software. An app built in an afternoon with v0, Lovable, Bolt, or Cursor looks finished, until someone asks for a second language and you realize every string is hardcoded. Internationalizing after the fact used to mean a weekend of wrapping strings, wiring up i18next, creating a project, adding languages, and shipping files around. It's now one command: The new supercommand in i18next cli 1.62 chains the whole journey (detect, instrument, extract, connect to Locize, AI translate, deliver) and ends with a localized, running app. What just happened 1. Detect : framework (React and Next.js natively), TypeScript, any existing i18next setup. 2. Configuration : uses your , or starts the interactive wizard if none exists. 3. Instrument : wraps hardcoded strings in calls and components, injecting where needed. Interactive by default: you approve each change. This is the instrument command, an assistant, not a compiler. 4. Extract : collects every key into your locale files. 5. Connect Locize : guided signup, and no manual language setup, because the languages from your config are created automatically on the first sync (locize cli ⥠12.3, which powers the Locize steps). 6. Translate & deliver : syncs with AI auto translation, which is enabled by default for new projects and uses your glossary and style guide as context. The command then watches the translations arrive, downloads them, and prints the i18next locize backend CDN snippet, so future translation fixes go live without redeploying your app. The Locize project after the run: all four languages at 100%, published automatically. And because Quality Estimation is also on by default for new projects, every AI translation arrives with a confidence score ; low confidence ones are flagged for review instead of shipping silently. Here it caught a real one in this very demo: Your AI coding agent can run this for you The apps this command is built for were often written by an agent, so the flow is also available as a prompt: This prints step by step instructions for Claude Code, Cursor, or any coding agent, using the individual CLI commands ( , , , â¦) instead of the interactive supercommand. The prompt is version matched to your installed CLI, so it never drifts from what itself does. Paste it into your agent, hand over the two Locize credentials when asked, and review the diff at the end. Honest limits Review the instrument diff. Instrumentation is heuristic and interactive for a reason: approve changes per string, and expect to adjust a few (brand names, dynamic labels). A dirty git tree triggers a confirmation prompt first, and previews everything without writing. Next.js App Router: injects , which is client only. Check server components in the diff and either add or switch them to a server side pattern. Non React stacks degrade gracefully. The transform covers React\/JSX out of the box; for Vue or Svelte, add a community plugin (i18next cli vue, i18next cli plugin svelte). Without one, the instrument step is skipped with guidance and the rest of the flow (extract â Locize â auto translate) still runs. AI translation runs once the project is subscribed or your own AI\/MT provider key is configured. The sync itself works either way, and re running later finishes the job: the command is idempotent, so completed steps are simply skipped. Get started In your project root: Or preview first with . The full option reference (CI mode, , namespaces, â¦) is in the i18next cli README, and the Locize side is covered in the CLI documentation. Want this to run on every push instead of locally? The same flow ships as a GitHub Action. See Free CI translation for i18next for the copy paste workflow, how \"free\" works, and an honest comparison to the lingo.dev Action and ai i18n. If you've been putting off localization because of the plumbing: the plumbing is gone. Create a free Locize account and run the command."},{"slug":"ai-translation-quality-estimation","title":"Quality Estimation: confidence scores for AI translations","description":"Locize now scores every AI translation with an AI confidence estimate, surfaces low-confidence segments in the editor, and can route them straight into your review workflow.","date":"2026-06-10","category":"Product","thumbnail":"\/img\/blog\/ai-translation-quality-estimation\/thumbn
40ail.jpg","readTime":"3 min read","searchText":"title: 'Quality Estimation: confidence scores for AI translations', description: 'Locize now scores every AI translation with an AI confidence estimate, surfaces low confidence segments in the editor, and can route them straight into your review workflow.', date: '2026 06 10', thumbnail: '\/img\/blog\/ai translation quality estimation\/thumbnail.jpg', image: '\/img\/blog\/ai translation quality estimation\/title.jpg', category: 'Product', tags: ['localization', 'i18n', 'ai', 'quality estimation', 'machine translation', 'review', 'workflow', 'announcement'], faq: [ q: 'What is quality estimation (QE) for machine translation?', a: 'Quality estimation predicts how good a translation is without a human written reference translation. In Locize, an AI evaluator rates every AI produced translation with a confidence score between 0 and 1 plus a short reason, judging accuracy, completeness, fluency, terminology, and the preservation of placeholders and tags. The score is stored with the translation and shown in the editor, so reviewers can focus on the segments that actually need attention instead of re reading everything.' , q: 'How do I enable quality estimation in Locize?', a: 'New projects have it enabled by default. For existing projects it is a setting: in the project settings under EDITOR, TM\/MT\/AI, ORDERING enable Quality Estimation (it requires enabled machine\/AI translation). From then on, new AI translations from the automatic translation workflow, AI bulk actions, and the AI assistant are scored automatically. Scoring uses the same AI provider that produced the translation: your own OpenAI, Gemini, or Mistral key, or the built in Locize AI (consuming AI tokens like any other Locize AI usage).' , q: 'Can Locize automatically send low confidence AI translations to human review?', a: 'Yes. The additional Review AI workflow setting routes low confidence AI translations into the existing review workflow as pending proposals instead of saving them silently, even in languages without the regular review workflow enabled. High confidence translations are saved directly. Each routed proposal carries the confidence score, a critique with issue categories (accuracy, fluency, terminology, style), and often a one click suggested revision.' , q: 'How is quality estimation different from the regular review workflow?', a: 'The regular review workflow in Locize reviews everything in the languages you select: every change becomes a proposal a reviewer must accept. Quality estimation with the Review AI workflow is selective: it only routes AI translations whose confidence falls below the threshold (0.7 by default), across all languages. The two combine cleanly: in languages with the regular review workflow enabled, everything still goes through review and quality estimation simply enriches the proposals with scores and critique.' , q: 'Is this MQM or AutoMQM?', a: 'No, and Locize does not claim MQM conformance. MQM (Multidimensional Quality Metrics) is the industry framework for analytic quality evaluation: annotating individual errors against a typology of dimensions with severities and computing a score from the annotations; AutoMQM uses LLMs to produce those annotations automatically. Locize Quality Estimation is reference free quality estimation: a confidence score plus a critique whose categories (accuracy, fluency, terminology, style) correspond to the top level MQM dimensions. The two compose well: use QE to route doubtful AI translations to human review at scale, and formal MQM evaluation where you need an auditable analytic score.' ] AI translation has become good. Good enough that most of its output ships untouched. The problem is the part that isn't: a flipped negation here, a wrong term there, hidden somewhere in thousands of perfectly fine segments. Until now, finding those meant re reading everything, which defeats the point of automating translation in the first place. Quality Estimation in Locize closes that gap: every AI translation now gets an AI judged confidence score , stored with the translation and surfaced exactly where you work. Route low confidence straight to humans Scoring is half the story. The optional Review AI workflow setting acts on it: Low confidence AI translations are not saved silently. They become pending proposals in the review workflow, even in languages that don't have the regular review workflow enabled. High confidence translations save directly, untouched. Each routed proposal carries a critique : issue categories (accuracy, fluency, terminology, style) with severity and a note. When the evaluator can clearly do better, it adds a suggested revision the reviewer applies with one click. This is deliberately different from the regular review workflow, which reviews everything in selected languages. The Review AI workflow reviews selectively, by confidence , so your reviewers spend their time exactly where the AI is unsure. A note on vocabulary, for teams that run formal quality programs: the critique's categories map onto the top level dimensions of MQM (Multidimensional Quality Metrics) , the industry's analytic evaluation framework, and its LLM driven variant AutoMQM . Locize Quality Estimation is reference free QE with a critique , not an MQM implementation, and we make no conformance claim; the honest pairing is QE for routing at scale, formal MQM evaluation for the samples where you need an auditable analytic score. The Quality Estimation docs spell out the relation. Getting started New projects have Quality Estimation enabled by default. For existing projects: 1. Open your project settings , then EDITOR, TM\/MT\/AI, ORDERING . 2. Enable Quality Estimation (requires enabled machine\/AI translation). 3. Optionally enable the Review AI workflow to auto route low confidence translations to review. Scoring reuses whatever AI provider produced the translation: your own OpenAI, Gemini, or Mistral key, or the built in Locize AI (metered as normal AI token usage). A styleguide and glossary sharpen the evaluator's judgement the same way they sharpen translations. Full details in the Quality Estimation documentation. Trust the AI where it earns it, and know immediately where it doesn't."},{"slug":"mcp-context-tools","title":"Context tools for AI translation: glossary, style guide, memory & screenshots","description":"New read-only Locize MCP tools give your AI agent the project glossary, style guide, translation memory, and screenshot context, so it can translate, review, and lint terminology right in y
40our IDE.","date":"2026-06-09","category":"Product","thumbnail":"\/img\/blog\/mcp-context-tools\/thumbnail.jpg","readTime":"3 min read","searchText":"title: 'Context tools for AI translation: glossary, style guide, memory & screenshots', description: 'New read only Locize MCP tools give your AI agent the project glossary, style guide, translation memory, and screenshot context, so it can translate, review, and lint terminology right in your IDE.', date: '2026 06 09', thumbnail: '\/img\/blog\/mcp context tools\/thumbnail.jpg', image: '\/img\/blog\/mcp context tools\/title.jpg', category: 'Product', tags: ['localization', 'i18n', 'ai', 'mcp', 'glossary', 'terminology', 'translation memory', 'workflow'], faq: [ q: 'How can an AI agent respect my terminology when translating?', a: 'With the Locize MCP server, an agent calls get glossary to fetch the project glossary (Lexica): the approved and forbidden terms per language. For each concept it returns a flattened shape per language, the single preferred term, other allowed variants, and the forbidden terms, so the agent uses the term you sanctioned and never a forbidden one. Combined with get styleguide (tone, formality, audience, usage rules) and search translation memory (prior translations of similar strings), the agent translates in your IDE with the same context a human translator has.' , q: 'Can an AI agent lint a pull request for terminology drift?', a: 'Yes, and it needs no translation step. Call get glossary with only the source language and the agent gets the forbidden terms for that language; it then flags any new or changed source string in the PR that uses a disallowed term and suggests the preferred one instead. This catches terminology drift at review time, before it ever reaches a translator or the published product.' , q: 'What are the Locize MCP context tools?', a: 'Four read only tools added to the Locize MCP server in June 2026: get glossary (approved\/forbidden terminology per language), get styleguide (tone, formality, target audience, usage and localization rules per language), search translation memory (exact and fuzzy matches against the project\\'s previously translated segments, including TMX linked projects), and get screenshot context (the screenshot and mapped region where a key appears, for visual disambiguation). They bring the project context an agent needs to translate, review, and QA directly into Claude, Cursor, VS Code, or any MCP client.' , q: 'Do the context tools cost extra or need special permissions?', a: 'No. They are included with the Locize MCP server on every plan, and each only requires the read PAT scope plus access to the project, the same as reading translations. Your project role and any language\/version\/namespace restrictions still apply on top.' ] Automation already handles the mechanical side of localization well: keys get reported via , the CLI instruments your code, CI publishes on deploy, and Automatic Translation fills the gaps. But when an AI coding agent translates or reviews a string itself, right there in your editor, it has been missing the context a human translator takes for granted: which term is the approved one, what tone the brand uses, how this string was translated last time, and where it even appears in the UI. Four new read only tools on the Locize MCP server close that gap. Translate with the glossary, style guide, and memory When you do let the agent translate or review, three tools give it the rest of the context: with returns the preferred target term per concept, so the agent emits the sanctioned terminology and avoids forbidden variants. returns the project's tone, formality, target audience, and usage rules per language, so the translation matches your brand voice instead of a generic default. finds previously translated segments similar to the new string (exact and fuzzy, across the project and any TMX linked projects), so the agent reuses an existing translation instead of inventing a new one. \"Translate the new checkout strings into German using the project's glossary, style guide, and translation memory.\" The result reads like the rest of your product, because it was produced with the same inputs your translators use, the same inputs Locize's own Automatic Translation already feeds to the AI\/MT providers. See the string before translating it Some strings are impossible to translate well without seeing them. A bare could be a button, a status, or a menu item, and the right translation, and the available space, depend on which. maps a translation key to the screenshot(s) where it appears, with the highlighted regi
40on and any OCR extracted text. The agent (or you) can fetch the image to disambiguate meaning and check for overflow before committing a translation. \"Show me the screenshot where the key appears.\" Setup Nothing new to install. If you've already connected the Locize MCP server, the four context tools are available now. They're read only and need only the PAT scope. If you haven't, setup takes about 60 seconds via OAuth or a Personal Access Token. The full tool reference is in the MCP documentation. To make your agent do this automatically, drop our ready made conventions ( , , ) into your repo â they're in the public locize agents repository. Why this matters The mechanical parts of localization are increasingly automated. What's left, and what actually determines quality, is context : terminology, voice, prior decisions, and visual placement. By exposing that context over MCP, Locize lets your AI agent translate, review, and lint to your project's standards, in the tools you already work in. Try it on your next PR: ask your assistant to lint the new strings against your glossary. It's the fastest way to feel the difference."},{"slug":"10-years-of-locize","title":"10 years of Locize","description":"A short note to mark ten years of running Locize. Where we started, what we built, who carried us, and a slice of pistachio cake from home.","date":"2026-05-27","category":"Company","thumbnail":"\/img\/blog\/10-years-of-locize\/thumbnail.jpg","readTime":"4 min read","searchText":"hideCta: true, title: '10 years of Locize', description: 'A short note to mark ten years of running Locize. Where we started, what we built, who carried us, and a slice of pistachio cake from home.', date: '2026 05 27', thumbnail: '\/img\/blog\/10 years of locize\/thumbnail.jpg', image: '\/img\/blog\/10 years of locize\/title.jpg', category: 'Company', tags: ['locize', 'company', 'anniversary'] Ten years. Around this time in 2016 we launched locize.com. At the time it was a small backend for i18next that did one thing: ship translations to running apps without a redeploy. Today it still does that, and quite a bit more. Where we started The story properly begins five years earlier, in 2011. We needed an i18n library that worked on both Node.js and in the browser, and nothing on offer fit cleanly. So i18next was written. It grew faster than we expected. A community formed around it, plugins appeared for every framework that mattered, and we kept refining the core. That was the easy part. The hard part turned out to be everything around the runtime: how translations actually get written, reviewed, versioned, delivered, edited in place, queued for AI\/MT assistance, audited, exported, re imported, kept in sync with code. The library could only do so much. The workflow was its own animal. By 2016 we had been on the receiving end of that workflow problem for long enough that we knew what we wanted. Continuous localization. CDN delivered translation. A real editor for translators. so developers never have to copy strings into a spreadsheet again. An in context editor that opens on top of the running app, so a translator can click a phrase and edit it where it lives. That became Locize. There's an earlier post on this blog from those first weeks if you want the original framing: Day zero, how all began. What we built Ten years on, the product is bigger than its first sketch, but the spine is the same. Translation management with the workflows real teams need (versions, history, permissions, segments, statuses). A CDN that serves published translations globally on both Standard (BunnyCDN) and Pro (AWS CloudFront) infrastructures. Native support for a long list of i18n formats, not just i18next JSON. AI translation that runs against your reference language, your terminology, and your context. Not a sidecar, a first class workflow. An in context editor that lives in the package and now plugs into vue i18n alongside i18next. A growing set of framework recipes: Next.js, React Router v7, Nuxt 4, Astro, and the older guides for React, Vue, Remix, and the rest. Swiss made, GDPR clean by default. Behind all of that, the deeper thing: a workflow where developers ship code and translators ship translations and neither side blocks the other. That was the goal in 2016 and it still is. What it actually feels like Running a small SaaS for ten years is not a straight line. Some weeks you ship a major release and a customer writes in to say it made their week. Other weeks you spend three days chasing a hydration bug that turned out to be a single missing capital N in a class name (true story, fixed in ). Some quarters churn drops on its own and you don't know
40why. Some quarters you ship the cleanest feature of the year and the metrics don't move. The laptop doesn't stay home on vacation. The phone is always within reach. You're always one step ahead of something, and one step behind something else. In return you get an unreasonable amount of flexibility. You decide what to build, when to build it, and which trade offs to accept. You answer to the customers, the code, and the people you work with, and not much else. For us that trade has been worth it for ten years running. A cake from home A small story to close. To mark the anniversary, a co founder's wife (who writes the food blog frangipani.food) baked a pistachio cake filled with mascarpone and elderflower chantilly. The recipe is on her side in German and Italian if you want to make it yourself. The elderflower has to sit in cream for 24 hours before you whip it with mascarpone, but the floral note that comes through afterwards is worth the planning. She also wrote a few lines on her side about what it's like to live with someone who runs a small business: the laptop that travels everywhere, the phone that doesn't stop, the freedom that comes with it anyway. Worth a read on the original post. Ten years like these aren't built by founders alone. The families who put up with the laptops and the late nights. The team. The i18next community. The customers who stuck with us through every iteration. The open source maintainers who built the ecosystem Locize sits on top of. All of you. Looking ahead There is no roadmap reveal in this post. The next ten years will go where they go. AI keeps rewriting the contract between what software and people each do, the JavaScript framework wars keep reshuffling, and i18next shaped problems will keep showing up in places we don't expect. We will keep meeting them where they land. If you've been using Locize for any stretch of that decade, thank you. If you're reading this for the first time, welcome. Same workflow. Same Swiss made platform. Same co founders. Ten more years to go. â The Locize team"},{"slug":"i18next-monorepo-typescript","title":"Type-Safe i18next in Monorepos: Introducing ResourceNamespaceMap","description":"In v26.3.0, i18next ships a new module-augmentation surface for monorepos: ResourceNamespaceMap. Each package can declare its own type-safe namespaces without colliding on CustomTypeOptions.resources.","date":"2026-05-26","category":"Guides","thumbnail":"\/img\/blog\/i18next-monorepo-typescript\/thumbnail.jpg","readTime":"4 min read","searchText":"hideCta: true, title: 'Type Safe i18next in Monorepos: Introducing ResourceNamespaceMap', description: 'In v26.3.0, i18next ships a new module augmentation surface for monorepos: ResourceNamespaceMap. Each package can declare its own type safe namespaces without colliding on CustomTypeOptions.resources.', date: '2026 05 26', thumbnail: '\/img\/blog\/i18next monorepo typescript\/thumbnail.jpg', image: '\/img\/blog\/i18next monorepo typescript\/title.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'typescript', 'monorepo'] If you've ever tried to add type safe translations to a monorepo with i18next, you've probably hit this wall: TypeScript refused to let two packages each declare their own namespaces. You either had to centralize every namespace into the leaf app's (including ones the app never used directly), or you reached for as a bandaid and gave up type safety on cross package namespaces. i18next v26.3.0 fixes this. Each package can now declare its own namespaces in its own , and TypeScript merges them automatically. No more collision, no more , no more central registry. Runtime was never the problem To be clear: at runtime, this always worked . You could happily call from any package and it would resolve. The pain was strictly at the type level. TypeScript's narrowing of keys depended on a single, global augmentation, so if you wanted typed keys and you had multiple packages, you were stuck. If you don't use type safe translations, you don't need to read further. But if you do, v26.3.0 is the upgrade you've been waiting for. Why a single field broke down The legacy pattern looked like this: is an interface, and TypeScript happily merges members across multiple blocks, as long as the property types match . But is a single property. If two packages each declared with different shapes, TypeScript bailed with TS2717: Subsequent property declarations must have the same type. That's the wall. You couldn't ship type declarations alongside each package. The leaf app had to know about every depen
40dency's namespaces and merge them into one block. The fix: is a separate interface, designed specifically for namespace contributions. Because each package adds distinct keys (their own namespace names), TypeScript's interface merging works exactly as intended. No property collision. In , the shared UI library declares only its own namespace: In , the leaf app declares only its own namespaces: When you consume the package as source (which is the default in monorepos like Turborepo), TypeScript merges the registry automatically. typechecks inside the UI package, works inside the app, and neither side has to import or know about the other's namespaces. Bonus: per package typed helpers Once each package owns its own namespaces, you can ship typed helper hooks alongside them. The trick is to extract just the namespaces that belong to this package from the merged registry. with a template literal type does it in one line: The package's components can call with no arguments and get a typed against the UI namespace. If the package grows and contributes , , etc. to the registry later, the helper picks them up automatically, with no hand maintained union to drift. Coexists with the legacy pattern If your project already uses , nothing changes for you . The legacy field continues to work, and both surfaces feed . You can introduce incrementally (for example, for a new shared package) without touching the rest of the augmentation. Things to know Same key conflicts are silently dropped. If two declarations contribute the same namespace with the same key but different literal types (say in one package, in another), that specific key is filtered out of the merged shape. Calling with it errors as unknown. Other keys in the namespace are unaffected. This is intentional: surfacing the conflict as a hard error would otherwise corrupt the entire namespace's typing. Scalar options stay on . is namespace types only. Options like , , , continue to live on and follow the existing single declaration rules. Since they're scalars, they rarely cause cross package conflicts in practice. Selector API works the same way. If you use , it walks the merged registry just like it walked the legacy . No additional setup needed. A thank you This feature shipped thanks to @sh3xu , who took the original idea from issue 2409 all the way through implementation, testing, and refining the type level merge logic to handle every edge case, including a particularly tricky one where same key conflicts silently collapsed the entire namespace. The conversation in PR 2434 is worth reading if you want the full type level story. Try it out Update to and you're ready to go. The full setup is documented in the TypeScript guide. If you haven't worked with type safe i18next before, our original TypeScript guide is the place to start, and the selector API post covers the other big Type
40Script improvement from the last year. Looking for a place to manage all those translation files? Locize maps cleanly onto this pattern: one Locize project, one namespace per monorepo package, type safe end to end."},{"slug":"astro-i18n","title":"How to internationalize an Astro site with Locize","description":"Step-by-step â
Astro 6 localization using built-in i18n routing + Locize as the translation backend: build-time JSON sync via locize-cli, the build-it-yourself t() recipe, and where framework islands fit when you need live updates or in-context editing.","date":"2026-05-21","category":"Tutorials","thumbnail":"\/img\/blog\/astro-i18n\/thumbnail.jpg","readTime":"8 min read","searchText":"title: 'How to internationalize an Astro site with Locize', description: 'Step by step â
Astro 6 localization using built in i18n routing + Locize as the translation backend: build time JSON sync via locize cli, the build it yourself t() recipe, and where framework islands fit when you need live updates or in context editing.', date: '2026 05 21', thumbnail: '\/img\/blog\/astro i18n\/thumbnail.jpg', image: '\/img\/blog\/astro i18n\/title.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'astro', 'how to'] Astro is the static first web framework for content driven sites: file based routing, zero JavaScript by default, \"islands\" for opt in interactivity, an SSR on demand mode for the parts that need it. Since v4.0 (late 2023, stable in v5+, current in v6.x), Astro ships built in i18n routing: URL prefixing ( , ), the helper, browser language detection, and automatic SEO tags. What Astro's built in i18n does not provide is a translation function ( ), pluralization, or message interpolation. Astro's official i18n recipe shows the canonical \"build it yourself\" pattern: import a per locale JSON file, write five lines of helper, done. That's exactly where Locize plugs in. downloads the latest published JSON from Locize into at build time, a tiny module assembles those into a flat lookup tree, and Astro's static build picks them up at compile time. This post walks the integration end to end. The complete code lives at github.com\/locize\/locize astro example. If you're on Nuxt instead, follow the Nuxt 4 walkthrough. If you're on React Router v7 (framework mode), see the React Router v7 walkthrough. Both cover richer integrations (in context editor, runtime saveMissing) that don't fit Astro's static by default model directly. TL;DR Configure Astro's built in i18n routing in : locale list + for uniform URLs. Use dynamic page routes with so every locale is statically pre rendered. Sync translations into the app at build time via 's command. No runtime CDN hop, no SSR considerations. Write a five line helper in . Astro deliberately doesn't ship a ; this is the canonical pattern from their own docs. Land new keys via , i18next cli static extraction, or the Locize web app, whichever fits your workflow. No runtime is possible from the static layer. Need runtime saveMissing, live CDN fetch, or the in context editor? Mount any React\/Vue\/Svelte island via and use + the package inside the island. Full working example: github.com\/locize\/locize astro example How the pieces fit Astro is static by default. Pages are pre rendered to HTML at build time and served as static files (or, in SSR mode, via an adapter on demand). Astro's built in i18n owns the routing layer â URL prefixing, locale aware redirects, hreflang tags, browser detection helpers â but it deliberately stays out of the message translation layer. That's why every Astro i18n tutorial ends with \"now write your own helper\": Astro's philosophy is to give you primitives, not opinions about translation. Locize is the translation management layer. The integration is bundle only at runtime : Build time: downloads the latest published JSON from the Locize CDN into . The committed JSON files are imported directly by at module load time and assembled into a flat lookup tree. is local TypeScript â five lines that handle locale fallback + style interpolation. No runtime library, no peer dep. Updates require a rebuild â same as any other Astro content change. Run and redeploy. That last point is the trade off. A \"translation published in Locize â end users see it\" round trip means re running the build. If you'd rather have live CDN backed fetch (publish â next page view picks it up, no redeploy), you mount a framework island and use inside it â the React Router v7 walkthrough covers that shape, and you can adopt the same pattern per island in Astro. We'll come back to this at the end. Let's get into it Prerequisites Node.js 22+ (Astro 6 requires it), npm\/pnpm\/yarn, and basic familiarity with Astro. The example below targets Astro 6.3. Project layout Scaffold a fresh Astro app, or the example: The relevant directory shape after we wire i18n + Locize: Install dependencies That's it. No translation runtime library, no framework integration package. Astro's built in i18n + locize cli + 50 lines of helpers cover the whole story. Configure Astro's built in i18n in Astro now owns: URL routing for every page under â , , , , etc. available in every page\/component for free. Browser language detection via and (SSR\/on demand routes only). Automatic tags when you opt in. With , every locale gets a URL prefix â uniform, SEO clean, and easy to handle with dynamic routes + . (If you'd rather have the default locale served at without a prefix, set it to and use file based pages instead of . The example uses the prefixed shape because it scales better.) Download translations from Locize at build time Add to
40: Run before (manually, in CI, or as a hook) so the bundled JSON is always fresh. Standard vs Pro CDN. Locize ships two CDN infrastructures (full comparison at CDN types: Standard vs. Pro): Standard at is BunnyCDN backed, free for generous monthly download volumes, public only (default for new projects); Pro at is CloudFront backed, paid, supports private downloads + custom cache control. Match on the cli flag to whatever your project is on. The message tree â Locize emits one JSON per namespace per language . Astro doesn't have a notion of i18n namespaces, so we assemble the on disk layout into a single flat lookup tree at module load time, with the namespace baked into each key as a prefix: The output looks like: is derived from the default locale tree, so TypeScript autocompletes the key in files and rejects typos at compile time. The helper â Five lines of logic. Fallback chain: requested key in the active locale, then the default locale, then the raw key string. Optional style interpolation passes values via the second argument. That's the whole runtime API. This pattern is the same one Astro's official i18n recipe shows â we've just layered Locize's namespaced on disk layout on top. Using in pages Dynamic routes + mean Astro pre renders one HTML file per locale at build time: The function maps each locale to a static path; arrives as a route param. Pure compile time work â no server side runtime, no hydration considerations. The language picker Astro's docs i18n recipe shows a simple picker that swaps the locale prefix on the current URL: Drop it into and it's available on every page. Three ways to land new keys in Locize Astro is static by default â pages are pre rendered, so a runtime push from production users isn't possible without an SSR adapter, and Astro discourages writes from the static layer anyway. There are three workable paths instead: 1. (wired in , drop the flag to actually push). reads your local and uploads any keys not yet in Locize. Manual or CI triggered, no write key in the browser. 2. Static extraction via or similar â scans your source for calls, writes new keys into the local JSON, then sync up as above. 3. The Locize web app â add keys directly in the editor and pull them down with before the next build. Pick whichever fits your workflow. None of them require shipping a write API key in your build artifact. What this shape intentionally doesn't include Three things you might expect from the Nuxt or React Router v7 walkthroughs are deliberately absent here: No runtime . See above â Astro static builds can't push, and an SSR Astro app would do this from inside an island, not from the static layer. No in context editor on static pages. The editor needs a DOM that re renders when the editor updates a string. Astro's static output doesn't have that hook. No live CDN fetch. Translations are bundled at build time. To serve a fresh translation, run and redeploy. This matches Astro's static first model and keeps the build artifact self contained. All three of these do work inside framework islands. Mount a React, Vue, Svelte, Solid, or Preact island via the matching integration, and inside that island use + the package directly. The Astro static layer handles the routing + the page chrome; the islands handle the parts that need a runtime. When to add a framework island The static only integration covers most content sites â blogs, marketing pages, docs, landing pages. Add a framework island when you need: Live translation updates without a redeploy. Use inside the island to fetch translations from the Locize CDN on each visit (or per route, if you cache). In context editing for translators. The package's overlay needs a runtime that re renders on string changes â only available inside a hydrated island. Runtime . Same constraint â a hydrated island can push new keys; static HTML can't. The pattern looks like this (for a React island): tells Astro to hydrate this component immediately on page load; you can use to defer hydration until the island enters the viewport. The exact configuration of is documented in the React Router v7 walkthrough â the same backend wiring works in any React\/Vue\/Svelte\/Solid context, including inside an Astro island. ð Congratulations A working Astro 6 + Locize setup gives you: Static first i18n with no flash of untranslated content (everything is pre rendered per locale) SEO clean URL prefixing via Astro's built in i18n routing Build time translation sync via â serverless friendly, no per request CDN hop Type safe with autocomplete on translation keys An escape hatch to dynamic islands
40when you need runtime updates or in context editing ð§âð» The complete code: github.com\/locize\/locize astro example. The founders of Locize are also the creators of i18next â by using Locize you directly support the future of i18next. See also How to internationalize a Nuxt 4 app with @nuxtjs\/i18n and Locize â Vue side counterpart with richer integration (vue i18n, in context editor, runtime saveMissing) How to internationalize a React Router v7 app with remix i18next â React side counterpart with live CDN fetch via Astro's built in i18n routing â the routing primitive this walkthrough builds on Astro i18n recipe â the build it yourself pattern Locize plugs into â the build time sync tool Locize platform docs"},{"slug":"nuxt-i18n","title":"How to internationalize a Nuxt 4 app with @nuxtjs\/i18n and Locize","description":"Step-by-step â
Nuxt 4 localization with @nuxtjs\/i18n, vue-i18n, and Locize, including build-time translation sync via locize-cli, optional client-side saveMissing, and the Locize InContext editor.","date":"2026-05-20","category":"Tutorials","thumbnail":"\/img\/blog\/nuxt-i18n\/thumbnail.jpg","readTime":"8 min read","searchText":"title: 'How to internationalize a Nuxt 4 app with @nuxtjs\/i18n and Locize', description: 'Step by step â
Nuxt 4 localization with @nuxtjs\/i18n, vue i18n, and Locize, including build time translation sync via locize cli, optional client side saveMissing, and the Locize InContext editor.', date: '2026 05 20', thumbnail: '\/img\/blog\/nuxt i18n\/thumbnail.jpg', image: '\/img\/blog\/nuxt i18n\/title.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'nuxt', 'vue', 'how to'] Nuxt is the dominant full stack framework for Vue, with file based routing, Nitro on the server, Vite under the hood, and an opinionated module ecosystem. For internationalization, the canonical pick is , which wraps vue i18n with Nuxt aware routing, SEO helpers, and locale detection middleware. This post walks through pairing that stack with Locize as a translation management backend: how to wire with the package's new vue i18n implementation (introduced in 4.1.0), use for build time sync, optionally push new keys to Locize at runtime via vue i18n's hook, and edit translations in place via the Locize InContext editor. If you're on React Router v7 (framework mode) instead, follow the React Router v7 walkthrough. If you're still on Remix v2 , see the Remix v2 post. If you'd rather use i18next directly on Vue (no , no vue i18n), see i18next vue for the alternative stack. TL;DR Use 10.x as your Nuxt i18n module. It owns routing, SEO, locale detection, and lazy loading; vue i18n underneath provides the API. Bundle translations into the app at build time via 's command. Both server (Nitro SSR) and client read the same JSON, with no runtime CDN hop, serverless friendly. Optionally push new keys back to Locize at runtime via vue i18n's hook ( ). Or skip it and use from CI, whichever fits your workflow. Edit in context with the package's helper (shipped in 4.1.0): append to any URL. Full working example: github.com\/locize\/locize nuxt example How the pieces fit Nuxt 4 runs the same Vue tree on the server (Nitro SSR) and on the client (
40after hydration). mounts vue i18n in both contexts and adds Nuxt aware features around it: typed routes, the composable, browser language detection, and so on. Locize is the translation management layer. The integration here is deliberately bundle only at runtime : Build time: downloads the latest published JSON from the Locize CDN into . The committed JSON files are read by 's lazy load on both server and client. Optional runtime push ( ): when a call references a key that isn't in the loaded JSON, a missing handler POSTs the key to Locize so translators see it appear without a manual extract step. Optional InContext editor ( ): opens the Locize editor as an iframe overlay; translators can edit any string they click in the page and save. A \"published a translation â users see it\" round trip therefore requires re running and redeploying. This is by design. It keeps Nitro serverless friendly (no per request CDN hop) and the client free of an extra translation fetch. If you'd rather have live CDN backed fetch (publish â next page view picks it up, no redeploy), the React Router v7 walkthrough covers that shape with . Let's get into it Prerequisites Node.js 20+, npm\/pnpm\/yarn, and basic familiarity with Vue 3 and Nuxt. The example below targets Nuxt 4.4. Project layout Scaffold a fresh Nuxt 4 app: The relevant directory shape after we wire i18n + Locize: A few things look unusual; the gotchas section below explains each. Install dependencies comes transitively with (currently 11.x). Configure in Per locale wrappers 's lazy load reads one file per locale. Locize emits one JSON per namespace per language , and preserves that layout, so for each locale, write a tiny wrapper that imports the per namespace JSON files and assembles them under their namespace key. This keeps the round trip clean and lets \/ resolve naturally: â¦and the same for . Why the wrapper? vue i18n doesn't have first class namespaces (unlike i18next). Messages are just a nested JSON tree, and is a deep key lookup. The wrapper layers the namespace structure on top so the round trip with Locize stays clean. Download translations from Locize at build time Add to : Run before (manually, in CI, or as a hook) so the bundled JSON is always fresh. Standard vs Pro CDN. Locize ships two CDN infrastructures (full comparison at CDN types: Standard vs. Pro): Standard at is BunnyCDN backed, free for generous monthly download volumes, public only (default for new projects); Pro at is CloudFront backed, paid, supports private downloads + custom cache control. Match on the cli flag to whatever your project is on. The vue i18n config in This file is loaded by at vue i18n init time and contributes the vue i18n options. We use it to register the and handlers, both written so they're safe to run during SSR (they no op on the server) and only kick in on the client when the plugin below populates the runtime flag: The runtime state bridge in The handlers above need access to runtime config (project id, api key, etc.) but doesn't have a Nuxt context. Bridge with a small shared mutable module: The Nuxt client plugin in This populates the runtime state from and starts the InContext editor when is set: Using in pages Standard vue i18n usage, with one twist: pages must call to share the same composer that has the and handlers on it. A plain creates a per component scoped composer that doesn't inherit those. Gotchas: what burned me building this A handful of non obvious things worth knowing. must live inside the directory 10.x resolves the vue i18n config file's path relative to (the directory), not the project root. A root level is silently not loaded. See in . Don't use the macro 's module post processes any file containing the macro identifier with a greedy regex ( ). With comments preserved by , a comment text match yanks the closing paren of unrelated \/ calls into the regex's capture group and corrupts the transformed output. Symptom: . Plain (no macro wrapper) works just as well, and calls the default export at init time. in pages vue i18n's creates a per component scoped composer by default in mode, and scoped composers do NOT inherit \/ from the global composer. If your pages call a plain , won't fire and the InContext editor won't see any segments. Use everywhere. Composing translations with literal text in templates This pattern works in JSX (React renders separate text nodes) but breaks in Vue: Vue's template compiler merges the literal and dynamic result into a single DOM text node , and the locize parser's check fails because the text now starts with instead of the marker. (locize 4.1.0 added a fallback case in the parser that recovers most of these, but the cleanest answer is also better i18n practice: put the arrow into the translation value so translators can reorder it for RTL.) slot interpolation passes an array of VNodes to vue i18n's component uses the path, which calls , but here is an array of Vue text VNodes (not raw strings), because vue i18n's internal
40converts every string segment to before the hook runs. A plain check skips this case entirely. The handler above covers both shapes: wrap the whole string, OR rebuild the first + last text VNodes via and . Hydration mismatch warnings under Subliminal wrapped text on the client doesn't match the unwrapped server output, so Vue logs for every translated string when is set. Vue's hydration is forgiving: it trusts the client, updates the DOM, and the editor's parser sees the wrapped strings. The warnings are noise, not failure, and they don't appear in normal (non ) page loads. If you want a clean console under , you'd need to wrap on the server pass too (requires per request SSR state for the runtime flag, outside the scope of this example). Three ways to land new keys in Locize The example wires up because it's the most discoverable: every time a developer references a key that doesn't exist, it appears in Locize automatically. But it's optional, and which path you pick depends on your workflow: 1. runtime push (the path the example shows by default). Convenient during dev. Requires shipping a dev only apiKey in the browser bundle. 2. (already wired in as , drop the flag). reads your local and uploads any keys not yet in Locize. Manual or CI triggered, no write key in the browser. 3. Static extraction via or similar â scans source, writes new keys into the local JSON, then sync up as above. To disable in this example, either delete the handler from or just leave empty so the handler no ops at runtime. InContext editing for translators The plugin (just + in the client plugin) gives translators an in context editor: open any page of your running app with appended and an iframe based editor opens that highlights every translated string and lets translators edit them in place. The editor saves land in your Locize project. To make those edits visible to end users you'll need to re run and redeploy (this example is bundle only at runtime â see TL;DR for the reasoning and the cross link to the live CDN fetch alternative). ð Congratulations A working Nuxt 4 + + Locize setup gives you: SSR friendly i18n with no flash of untranslated content Per request locale detection via 's middleware (cookie â URL â Accept Language â fallback) Build time translation sync via â serverless friendly, no per request CDN hops Optional to skip the manual key add step during dev InContext editing for non developers via the plugin A clean separation between bundled runtime translations and CMS side editing ð§âð» The complete code: github.com\/locize\/locize nuxt example. The founders of Locize are also the creators of i18next â by using Locize you directly support the future of i18next. If you want a bigger i18next overview, there's also an i18next crash course video: See also How to internationalize a React Router v7 app with remix i18next â same shape but with client side live CDN fetch via How to internationalize an Astro site with Locize â static first counterpart: routing only built in i18n + build time JSON sync, no runtime framework needed How to internationalize a Remix application (Part 1) and (Part 2) â Remix v2 walkthroughs Vue Localization with i18next vue â alternative Vue stack using i18next directly (no , no vue i18n) Give vue i18n more superpowers â the vanilla vue i18n + locizer integration story documentation Locize platform docs"},{"slug":"react-router-i18next","title":"How to internationalize a React Router v7 app with remix-i18next","description":"Step-by-step â
React Router v7 (framework mode) localization with i18next, remix-i18next 7.x, and Locize â including SSR-friendly language detection, in-context editing, and saveMissing.","date":"2026-05-19","category":"Tutorials","thumbnail":"\/img\/blog\/react-router-i18next\/thumbnail.jpg","readTime":"5 min read","searchText":"title: 'How to internationalize a React Router v7 app with remix i18next', description: 'Step by step â
React Router v7 (framework mode) localization with i18next, remix i18next 7.x, and Locize â including SSR friendly language detection, in context editing, and saveMissing.', date: '2026 05 19', thumbnail: '\/img\/blog\/react router i18next\/thumbnail.jpg', image: '\/img\/blog\/react router i18next\/title.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'i18next', 'react router', 'remix', 'how to'] In May 2024 the Remix team announced that Remix as a
40separate framework would merge into React Router v7 , with the Remix style developer experience becoming \"framework mode\" of React Router. The i18n library most Remix apps use, remix i18next, followed the move: starting with version 7.x it targets React Router v7 framework mode (and its 6.x line continues to support Remix v2). This post walks through the new shape: how to localize a React Router v7 app with i18next, remix i18next 7.x, and the Locize translation management platform â including the new React Router middleware pattern , server side rendering with bundled translations, and client side CDN backed lazy loading. If you're still on Remix v2 , follow the Remix v2 post instead and keep using remix i18next 6.x. If you're on React Router v7 in SPA mode (no SSR), use react i18next directly â this post focuses on framework mode + SSR. TL;DR Use remix i18next 7.x's middleware ( ) to detect locale per request and seed a per request i18next instance. Bundle translations server side via static JSON imports (no runtime CDN hits â serverless friendly). Use on the client to lazy load fresh translations from the Locize CDN â published updates appear without redeploying. Push missing keys back to Locize automatically with . Edit in context with the plugin (append to any URL). Full working example: github.com\/locize\/locize react router example What changed from Remix v2 Three pieces of the integration changed materially between remix i18next 6.x (Remix v2) and 7.x (React Router v7): Concern Remix v2 \/ remix i18next 6 React Router v7 \/ remix i18next 7 Locale detection wiring A class instantiated once at module load, called explicitly from loaders A route middleware ( ) declared in that runs per request and seeds context Loader side translation access \/ \/ from the middleware's return tuple Build system Remix classic compiler or Remix Vite plugin React Router Vite plugin ( ) â Vite is the only path forward The translation library plugins ( , , , ) are unchanged. Let's get into it Prerequisites Make sure you have Node.js 20+ and a recent version of npm\/pnpm\/yarn. You should be comfortable with React and have read the React Router v7 framework mode docs at least once. Project layout You can scaffold a fresh React Router v7 app with the official starter: For the rest of this post, the relevant pieces of the app layout are: Note: the JSON translation files live under (not ) because Vite refuses to bundle static imports from . This is the cleanest place for translations that need to be imported as ES modules server side. Install i18next + remix i18next + Locize Enable middleware in The middleware support is currently behind a future flag in React Router v7: Bundle the translations Export every language à namespace as one object so it can be passed to i18next on the server: The middleware â This is the heart of the new pattern. returns a 3 tuple: the middleware itself, plus accessor functions for the locale and the i18next instance: Hook the middleware in Server side rendering â returns the per request i18next instance the middleware seeded. Wrap the React tree in so resolves the right instance during SSR: Catch all + defensive fallback. Add a in so the middleware always runs (including for probes like Chrome DevTools fires). And wrap in a with a minimal fallback i18next instance if you want extra resilience against edge cases. The example repo shows both. Client side init â This is where Locize becomes the fresh translation source . On the client, fetches translations directly from the Locize CDN â so published updates appear on the next page view without a redeploy. The in context editor plugin lets translators open and edit inline. Using in routes Same as in any react i18next app: Locize CDN endpoint Locize ships two CDN infrastructures (full comparison at CDN types: Standard vs. Pro): Standard CDN at â BunnyCDN backed, free for generous monthly download volumes, 1 hour fixed cache, public only. Default for newly created Locize projects. Pro CDN at â CloudFront backed, paid, supports private downloads, custom cache control, namespace backups. Set or in the object above to match your project. Continuous localization with Locize Once the integration is wired, the workflow piece is what makes Locize worth its keep: Sync translations from Locize at build time Add scripts to that call the locize cli: Run before (locally, in CI, or as a hook) to ensure the server side bundled translations are fresh. saveMissing â keys flow from code â Locize automatically When is set client side and an apiKey is configured, every translation key your app references but the loaded JSON doesn't yet contain is pushed back to your Locize project . Translators see the new keys appear in the Locize UI without any manual extract step. In production, omit the apiKey (as in the snippet above) so write attempts become no ops â the CDN served read path still works for all translated keys. In context editing â The plugin (just in the init chain) gives translators an in context editor: open any page of your running app with appended and an iframe based editor opens that highlights every translated string and lets translators edit them in place. Last used reporting + automatic translation (dev only) tags every translation segment with its last access timestamp, so unused keys can be cleaned up later. Locize's UI offers one click automatic translation for missing keys via DeepL \/ OpenAI \/ Google Translate â so you can have a working German build minutes after adding English copy. ð Congratulations A working React Router v7 + remix i18next + Locize setup gives you: SSR friendly i18n with no flash of untranslated content Per request locale detection via middleware (cookie â URL â Accept Language â fallback) Fresh translations without redeploying via the Locize CDN to skip the extract step â new keys appear in Locize as developers reference them In context editing for non developers via the plugin CI friendly translation sync via ð§âð» The complete code: github.com\/locize\/locize react router example. The founders of Locize are also the creators of i18next â by using Locize you directly support the future of i18next. If you want a bigger i18next overview, there's also an i18next crash course video: See also How to internationalize a Remix application (Part 1) â Remix v2 walkthrough (still relevant if you're not yet on RR v7) How to internationalize a Remix application (Part 2) â continuous localization workflow with Locize on Remix v2 How to internationalize a Nuxt 4 app with @nuxtjs\/i18n and L
40ocize â Vue side counterpart with + vue i18n + Nitro SSR How to internationalize an Astro site with Locize â static first counterpart with Astro's built in i18n routing + build time JSON sync remix i18next â the library this post is built around (thank you Sergio XalambrÃ) React Router v7 framework mode docs Locize platform docs"},{"slug":"in-context-translation-editor-tools-comparison","title":"In-context translation editor: how it works and how the major TMS platforms compare","description":"An in-context translation editor (ICE) lets translators edit strings directly on a live website or app. Four architectural patterns exist: SDK \/ script injection, proxy-based, browser extension, and iframe embed. This guide compares how Locize, Lokalise, Crowdin, Phrase, SimpleLocalize, Tolgee, Localazy, and Transifex approach in-context editing, and which pattern fits which use case.","date":"2026-05-12","category":"Guides","thumbnail":"\/img\/blog\/in-context-translation-editor-tools-comparison\/thumbnail.jpg","readTime":"9 min read","searchText":"title: 'In context translation editor: how it works and how the major TMS platforms compare', description: 'An in context translation editor (ICE) lets translators edit strings directly on a live website or app. Four architectural patterns exist: SDK \/ script injection, proxy based, browser extension, and iframe embed. This guide compares how Locize, Lokalise, Crowdin, Phrase, SimpleLocalize, Tolgee, Localazy, and Transifex approach in context editing, and which pattern fits which use case.', date: '2026 05 12', thumbnail: '\/img\/blog\/in context translation editor tools comparison\/thumbn
40ail.jpg', image: '\/img\/blog\/in context translation editor tools comparison\/title.jpg', category: 'Guides', tags: ['in context editor', 'localization', 'tms', 'comparison', 'guides'], faq: [ q: 'What is an in context translation editor (ICE)?', a: 'An in context translation editor (ICE) is a tool that lets translators and reviewers edit text directly on a live website or application, with the user interface around the text visible at the same time. Instead of translating strings inside a separate translation interface (where the surrounding UI, layout, and meaning are not visible), translators see exactly where each string appears, how long it can be, and what neighbouring content surrounds it. The result: fewer translation errors caused by missing context, fewer layout breaking translations, and faster reviewer cycles. Major TMS platforms offer in context editors through one of four architectural patterns: SDK \/ script injection, a proxy that rewrites HTML, a browser extension, or an iframe embed inside the TMS UI.' , q: 'What are the best in context translation editor tools for software localization?', a: 'The right tool depends on which architecture pattern fits your stack. For developer first teams using i18next, React, Vue, or other JavaScript frameworks, SDK based tools (Locize, Crowdin, Tolgee, Localazy) integrate cleanly via a small script. For teams that want zero code changes and accept proxying production traffic, Phrase offers a proxy based In Context Editor. For translator side editing without app changes, Lokalise offers a browser extension approach. Most of these platforms also support an iframe embed mode where the website renders inside the TMS UI. The \"best\" tool is the one whose architecture matches your team\\'s constraints; there is no single winner across all use cases.' , q: 'How do Lokalise, Crowdin, Phrase, and Tolgee compare on in context editing?', a: 'Lokalise, Crowdin, and Tolgee all take SDK \/ script injection approaches at their core: you add a small JavaScript snippet to your website, and translators see an editor overlay when activated. Tolgee is particularly known for its \"ALT + click\" activation UX and is open source \/ self hostable. Crowdin\\'s In Context tool follows the same pattern with deep integration into Crowdin\\'s project structure. Phrase, by contrast, has historically offered a proxy based In Context Editor where translator traffic flows through a Phrase hosted proxy that rewrites HTML on the fly (no code changes required, but all proxied traffic goes through Phrase). Lokalise additionally offers a browser extension approach for translator side editing. All four are mature options; the architectural pattern is usually a bigger decision than feature parity.' , q: 'Does Locize have an in context translation editor?', a: 'Yes. Locize offers in context editing in two complementary modes. The recommended mode is a draggable, resizable editor popup that appears directly on your website when you append to the URL. The popup is rendered by the npm package, which uses i18next subliminal markers (invisible Unicode characters) to map each rendered string back to its translation key: the most reliable text matching strategy in the category. The alternative mode embeds your website inside the Locize UI via iframe, useful when translators want to stay inside the TMS. Both modes work with i18next, locizify, vanilla JavaScript, and frameworks that do not use i18next (MessageFormat, Fluent, others).' , q: 'Proxy based vs SDK based in context editing: which is better?', a: 'Neither is universally better; they are tradeoffs. Proxy based ICE (e.g. Phrase) requires zero code changes: the TMS proxies your site, rewrites HTML, and inserts the editor. The downside is that all traffic that uses the editor flows through a third party proxy, which has performance, SSO, CSP, and data residency implications. SDK based ICE (e.g. Locize, Crowdin, Tolgee) requires adding a small JavaScript snippet to your site, but your traffic stays direct: no proxy in the loop. SDK based is the better fit when you control the codebase and want to avoid proxying production traffic. Proxy based is the better fit when adding code is impossible (legacy systems, third party SaaS you do not own) or when you need to translate a site without engineering involvement.' , q: 'Can I use in context editing without changing my code?', a: 'Yes. Proxy based and browser extension approaches both let translators see and edit strings without touching the application code. Phrase\\'s proxy In Context Editor and Lokalise\\'s browser extension approach are the typical no code options. The tradeoff is that proxy based editors route traffic through a third party (with the performance and data residency implications that follow), and browser extension approaches are typically translator side only: you can\\'t share a \"live in context preview\" URL with non extension users. SDK based editors (Locize, Crowdin, Tolgee) require adding a small JavaScript snippet to the site but otherwise need no code changes; if you can add one tag or one npm dependency, you can have full in context editing.' ] TL;DR: An in context translation editor (ICE) lets translators edit strings on the live website or app, with the surrounding UI visible. Four architectural patterns exist: SDK \/ script injection (Locize, Crowdin, Tolgee, Localazy), proxy based (Phrase), browser extension (Lokalise), and iframe embed inside the TMS UI (most platforms offer this as a secondary mode). The right pick depends on whether you can add code, how strict your data residency requirements are, and whether translators need shareable preview URLs. Locize uses the SDK approach with i18next subliminal markers for reliable string to key matching. What is an in context translation editor? An in context translation editor (sometimes abbreviated as ICE , sometimes called
40in context localization or live editing ) is a tool that lets translators edit text strings directly on a running website or application, with the user interface around the string visible at the same time. This sounds simple. The problem it solves is not. In a traditional translation workflow, translators see a list of strings in the TMS (translation management system), often without surrounding context. A string like could mean \"submit a form\" or \"submit (yield) to authority\" ; the translation differs by language. \"Open\" could be a button or an adjective. Numeric formats, gendered text, and pluralisation behave differently per locale. Without seeing where the string appears, translators have to guess, and they guess wrong often enough that an entire industry of \"translation context tooling\" exists to compensate. In context editing solves the same problem the obvious way: let the translator see the string in its real surroundings while editing. Why context matters in translation Three concrete examples of the cost of missing context: Layout breaking translations. German is roughly 30% longer than English. A \"Save\" button labelled three characters in English becomes \"Speichern\" (9 characters), and the button breaks visually if the translator can't see the layout. In context editing surfaces this immediately. Wrong sense of a polysemous word. \"Bank\" (financial institution) and \"Bank\" (river bank, or German \"bench\") have different translations in many languages. Out of context, translators frequently pick the wrong one. Gender and pluralisation in the wrong context. A string like may need different grammar based on the user's gender in languages that distinguish (French, Spanish, Hebrew, Arabic, German nouns). Knowing whether refers to a customer, an admin, or a system role changes the right translation. The data on this is consistent across enterprise localization research: most translation defects that reach production are context defects, not vocabulary defects. The translator knew the words; they didn't know the situation. In context editing is the most direct mitigation. Instead of fixing context after translation (review cycles, screenshots, glossary notes), it puts the context in the translator's face at the moment of translation. The four architectural approaches to in context editing Different TMS platforms have arrived at four distinct architectures. Understanding which pattern a platform uses matters more than comparing features in isolation: the architecture determines what's possible, what's painful, and what's impossible. 1. SDK \/ script injection Your application loads a small JavaScript snippet from the TMS vendor. When in context mode is activated (usually by a URL parameter like or a keyboard shortcut), the SDK overlays an editor UI on top of your page. Translators click any string on the live site, see the editor, change the translation, and the change is saved back to the TMS. Used by: Locize, Crowdin (In Context), Tolgee, Localazy, and most modern developer first TMS platforms. Pros: No proxy traffic. Your site loads from your own infrastructure as usual. Works with any deployment platform. Translators can be sent a deep link to a specific page in your live environment. Cons: Requires adding a script tag or npm dependency to your site. If you cannot change the code (third party SaaS, locked legacy stack), this approach is unavailable. 2. Proxy based The TMS provides a proxy URL (e.g. ). When translators visit the proxy URL, the TMS fetches the original HTML from your real site, rewrites the strings on the fly, injects the editor UI, and serves the result. No code changes required on your end. Used by: Phrase has historically offered a proxy based In Context Editor. Smartling's Global Delivery Network (GDN) is a related architecture, though it operates at production scale rather than just for translator editing. Pros: Zero code changes. Works with sites you don't own or can't modify. Good fit for marketing pages, CMS backed sites, and legacy systems. Cons: All editor traffic flows through a third party proxy, with implications for performance, SSO authentication, CSP headers, data residency, and cost. The proxy has to keep parity with your real site (deployments, A\/B tests, dynamic content) which is a moving target. 3. Browser extension The translator installs a browser extension provided by the TMS. When the translator visits any page on your site, the extension overlays an editor UI without touching your application's code. Used by: Lokalise offers a browser extension approach for translator side editing. Pros: Zero code changes. The translator has full control. No proxy in the loop. Cons: Only the translator sees the editor; you cannot share a live in context preview URL with stakeholders who haven't installed the extension. Some sites (with strict CSP, iframe restrictions, or complex client side state) are harder for an extension to handle than a first party script. 4. Iframe embed inside the TMS UI The TMS UI renders your website inside an iframe in its own dashboard. Translators stay inside the TMS, see your site in the embed, and edit translations via the TMS's translation interface. Clicks on the website highlight the matching translation key in the sidebar. Used by: Most platforms offer this as a secondary mode. Locize provides it alongside the popup approach. Pros: Lives entirely inside the TMS, no separate window. Useful for translators who want a unified workspace. Cons: Iframe sandboxing limits some interactions (cross origin, certain authentication flows). The user experience is less natural than the on site popup. How the major TMS platforms compare This is the honest, architecture first comparison. Specific feature names change across releases; the underlying pattern is more stable. Platform Primary ICE pattern Notable detail Locize SDK \/ popup on your site (recommended) + iframe embed Uses i18next subliminal markers for string to key mapping: the most reliable matching strategy in the category. Works with i18next, locizify, vanilla JS, and frameworks that don't use i18next (MessageFormat, Fluent, etc.). Lokalise Browser extension + on site SDK Translator side extension is a Lokalise hallmark. Also offers a mobile app live edit SDK. Crowdin SDK \/ In Context script injection Deep integration with Crowdin's project structure; mature offering across its ecosystem. Phrase Proxy based In Context Editor Long standing proxy approach. Zero code changes; all editor traffic through Phrase's proxy. SimpleLocalize SDK \/ script injection Newer entrant in this category; SDK approach. Tolgee SDK \/ \"ALT + click\" activation Open source and self hostable. Polished activation UX is a distinguishing feature. Localazy SDK \/ visual localization SDK based, with a
40Live Translate feature for visual editing. Transifex Native SDK + Live editor (proxy style) Offers both approaches: Native for in app strings via SDK, Live editor proxy style for marketing pages. This table intentionally avoids feature by feature comparison (real time collaboration, screenshot support, dialect handling, etc.); those change quarterly and would be out of date in six months. The architecture pattern is the load bearing decision; everything else follows. How Locize's in context editor works Locize uses an SDK \/ script injection approach, with two complementary modes. The on site popup (recommended) Add the script to your page. When you append to the URL, a draggable, resizable editor popup appears on your live site. Translators can click any text element on the page; the editor highlights it and shows the matching translation key for editing. The Locize popup editor running on a live page The popup remembers its position and size across page reloads. It automatically detects URL changes in single page applications. You can exclude specific elements from being parsed by adding the attribute. The iframe embed in Locize Alternatively, you can embed your website in an iframe inside the Locize UI. Translators stay in Locize, see your site in the embed, and click any text to highlight the matching key in the sidebar. The Locize iframe view embedding the live website Set the URL(s) you want to embed in the project settings under \"Set InContext editor urls\". Multiple URLs (staging, production, locale specific) are supported. How text matching works under the hood The script needs to map text on your page back to translation keys in your Locize project. Three strategies are supported, in order of reliability: 1. Subliminal markers (default) : When using locizify or the i18next , every translated string on the page contains hidden metadata via i18next subliminal: invisible Unicode characters that encode the namespace and key. This means string to key matching is exact, even when the same English text appears in multiple places with different keys. This is the most reliable matching strategy in the category ; it is not based on text similarity or position guessing. 2. Data attributes : Annotate your HTML with and attributes to explicitly map elements to keys. Useful when you want explicit control. 3. Raw text lookup : As a fallback, the script sends raw text to the editor, which performs an exact search and returns a match if found. Getting started with Locize ICE: minimal example The shortest path to Locize in context editing, with i18next: That's it. Append to any URL on your site, log in with your Locize account, and you have in context editing on your real application. If you want the editor to always show (no URL parameter needed), use . If you're not using i18next, the package also exposes a standalone API ( , , ) that works with any i18n library that loads JSON messages, including MessageFormat, Fluent, and bespoke setups. Full integration documentation: Locize in context editor docs. When each architecture pattern fits A short decision guide: You control the codebase + you want translators to use deep linked preview URLs: SDK \/ script injection (Locize, Crowdin, Tolgee, Localazy). You cannot add code (third party SaaS, no engineering capacity): Proxy based (Phrase) or browser extension (Lokalise). You need to translate a site you don't own: Proxy based. You want translators to work entirely inside the TMS, no separate window: Iframe embed (most platforms support this as a secondary mode). You're already using i18next: Locize's SDK approach is the lowest friction integration: same team behind i18next, deepest framework integration, subliminal marker matching that competitors don't offer. A note on text matching reliability One detail that distinguishes ICE implementations is how they map text on the page back to translation keys. Approaches range from: Subliminal markers : invisible metadata embedded in rendered strings (Locize, via i18next subliminal). Exact mapping, robust to duplicate text. Data attributes : explicit attributes (supported by Locize, Crowdin, others). Robust but requires markup. Position \/ similarity matching : the editor guesses the key from the position of the text on the page and the visible text content. Brittle when the same English text appears multiple times with different keys. If your application has duplicate strings used in different c
40ontexts (a common case in larger apps, where \"Save\", \"Cancel\", \"Submit\" appear dozens of times), the matching strategy matters. Subliminal markers and data attributes both handle duplicates correctly. Position \/ similarity matching does not. Related reading i18next vs. Locize: when to use each, and how they work together Locize in context editor documentation: full setup guide Context information in Locize: beyond in context editing, per key context, screenshots, OCR Swiss made translation management system: Locize as a Swiss engineered TMS Compare Locize to alternatives: head to head comparisons with Lokalise, Crowdin, Phrase, Tolgee, and others"},{"slug":"messageformat-2-i18next","title":"MessageFormat 2 in i18next: state of the migration (May 2026)","description":"MessageFormat 2 (MF2) is the new Unicode standard for localized messages, final candidate since March 2025. But adoption is still early: the i18next-mf2 plugin gets 6 weekly npm downloads vs 355,000 for the underlying messageformat library. Here is what MF2 actually changes, why adoption is slow, and what to do today.","date":"2026-05-11","category":"Guides","thumbnail":"\/img\/blog\/messageformat-2-i18next\/thumbnail.jpg","readTime":"6 min read","searchText":"title: 'MessageFormat 2 in i18next: state of the migration (May 2026)', description: 'MessageFormat 2 (MF2) is the new Unicode standard for localized messages, final candidate since March 2025. But adoption is still early: the i18next mf2 plugin gets 6 weekly npm downloads vs 355,000 for the underlying messageformat library. Here is what MF2 actually changes, why adoption is slow, and what to do today.', date: '2026 05 11', thumbnail: '\/img\/blog\/messageformat 2 i18next\/thumbnail.jpg', image: '\/img\/blog\/messageformat 2 i18next\/title.jpg', category: 'Guides', tags: ['i18next', 'messageformat', 'icu', 'localization', 'guides'], faq: [ q: 'What is MessageFormat 2 (MF2)?', a: 'MessageFormat 2 (MF2) is the new Unicode standard for localized messages, formally under the Unicode CLDR Technical Committee. It reached Final Candidate status in March 2025 and was refined in LDML 47 and 48 (October 2025). MF2 is designed to replace the original ICU MessageFormat (sometimes retroactively called MF1) with cleaner syntax, explicit declarations for variables and selectors, and better handling of complex multilingual cases like gendered language and nested plurals.' , q: 'Is MessageFormat 2 ready for production in i18next?', a: 'Spec wise, yes: MF2 is stable. Ecosystem wise, not yet. The official i18next mf2 plugin is at v1.0.0 with 6 weekly npm downloads as of May 2026, while the i18next icu plugin (MF1) has grown from roughly 100k to 300k weekly downloads over the past year. No major framework (FormatJS \/ react intl, Lingui, etc.) has shipped MF2 as default. The TC39 Intl.MessageFormat proposal is stuck at Stage 2 pending production adoption signals. For most teams, ICU MessageFormat 1 remains the practical choice in 2026.' , q: 'What is the difference between MessageFormat 1 and MessageFormat 2?', a: 'MF1 (ICU MessageFormat) puts variables, selectors (plural \/ select \/ selectordinal) and formatters inline in one curly brace expression. MF2 separates variable declarations, selectors, and message variants into a cleaner structure with explicit , , blocks. For simple plurals or interpolation, the two formats are similar. For complex cases (nested selectors, multiple plurals per message, gender + plural combinations), MF2 is significantly more readable and easier to translate.' , q: 'Should I migrate my i18next project from ICU MessageFormat to MF2?', a: 'Most teams should not migrate yet. Until at least one of FormatJS, Lingui, or a major framework defaults to MF2 (or until TC39 Intl.MessageFormat advances to Stage 2.7 \/ Stage 3), staying on ICU MessageFormat is safer. The migration is reversible and can be done incrementally with i18next mf2 alongside i18next icu, so there is no urgency. If you are starting a brand new project with very multilingual edge cases (gender + plural combinations, complex selectors) and accept the early adopter risk, MF2 is a reasonable choice now.' , q: 'Does Locize support MessageFormat 2?', a: \"Yes. Locize stores translation messages as text: your message format (ICU MessageFormat 1, MessageFormat 2, plain interpolation, anything else) is preserved verbatim. The i18next mf2 plugin reads Locize served messages the same way i18next icu does. There is no vendor lock in to a specific message format: when MF2 adoption inflects and you want to migrate, you can update messages in place in Locize without changing your TMS.\" , q: 'When will MessageFormat 2 become widely adopted?', a: 'Hard to predict precisely. The signals to wat
40ch are: (1) TC39 Intl.MessageFormat advancing to Stage 2.7, which requires roughly a dozen organizations using MF2 in production; (2) FormatJS or Lingui shipping MF2 as default; (3) Major SaaS or e commerce platforms publicly documenting MF2 deployments. None of these have happened as of May 2026. Realistic expectation: meaningful adoption inflection in late 2026 or 2027, mainstream defaulting unlikely before 2028.' , q: 'Where can I learn the MessageFormat 2 syntax?', a: 'The Unicode CLDR working group maintains the specification at messageformat.unicode.org. The most accessible introduction for engineers is Igalia\\'s \"MessageFormat 2.0: a new standard for translatable messages\" blog post (May 2024). The ICU User Guide has a Java leaning syntax reference. For JavaScript \/ TypeScript specifically, the npm package is the reference implementation and its README plus tests are useful study material.' ] TL;DR (May 2026): MessageFormat 2 (MF2) is the new Unicode standard for localized messages, final candidate since March 2025, spec stable. But adoption is still early. The plugin gets 6 weekly npm downloads . The underlying library gets 355,051 . For most i18next users today, the answer to \"should I migrate?\" is \"not yet, but understand what's coming.\" What is MessageFormat 2? MessageFormat 2 (MF2, formally ) is the new Unicode standard for representing localized messages. It is maintained by the Unicode Common Locale Data Repository (CLDR) Technical Committee and reached Final Candidate status in March 2025 , with refinements in LDML 47 and 48 (October 2025). The specification is now stable. For a developer focused overview, Igalia's MessageFormat 2.0 introduction (May 2024) is the most accessible read. MF2 is the successor to ICU MessageFormat (sometimes called MF1 retroactively), the format the i18next ecosystem has used via the i18next icu plugin for over a decade. (For broader context on how JavaScript i18n formats compare, see our overview of JavaScript i18n formats.) Key facts (May 2026) Spec status: Final Candidate (March 2025), refined in LDML 47 \/ 48 (Oct 2025), syntax and semantics locked TC39 Intl.MessageFormat proposal: Stage 2, blocked at Stage 2.7 (needs 12 organizations using MF2 in production before advancing) i18next mf2 plugin: v1.0.0, 6 weekly npm downloads i18next icu plugin (MF1): growing from 100k â 300k weekly downloads over the past year, the active install base that would eventually migrate messageformat reference lib: 355,051 weekly npm downloads , but mostly used as a transitive dependency, not as the direct MF2 adoption signal FormatJS \/ react intl, Lingui, Tolgee: all still MF1 only; no public MF2 roadmaps Production case studies: none publicly documented as of May 2026 What MF2 actually changes: side by side The clearest way to see the difference is a real example. Consider a plural message with interpolation. ICU MessageFormat 1 The whole message is one curly brace expression. The variable, the selector, and the variants are all inline. MessageFormat 2 MF2 splits the message into three explicit parts: 1. declarations name and type the variables (here is an integer). 2. declares which variable drives selection. 3. Variants are listed under explicit selector values; is the fallback (replaces MF1's ). For simple cases the verbosity feels like overkill. For complex cases ( gender + plural + format combinations , multiple selectors per message, message reuse with declarations), MF2 becomes meaningfully cleaner. Full syntax reference lives in the ICU User Guide for MessageFormat 2. The npm download story A direct way to measure i18next side adoption: compare the official bridge, the underlying reference library, and the established plugin (which implements MF1). messageformat (lib) 355k weekly npm downloads, May 3 2026 i18next icu (MF1 plugin) 300k weekly, up from 100k a year ago, the active install base i18next mf2 (MF2 plugin) 10 weekly npm downloads, May 3 2026 Two things stand out: 1. has reach : but mostly as a transitive dependency or in non i18next ecosystems. Not a direct MF2 on i18next adoption signal. 2. (MF1) is growing , roughly tripled over the past year, from 100k to 300k weekly. The MF1 install base in the i18next ecosystem is healthy and expanding , not shrinking. That's the audience MF2 would eventually need to migrate from. 3. is at 10 weekly downloads. Functionally zero traffic so far, closer to \"spec curious developers\" than to \"production projects shipping.\" Read: the standard exists, the runtime exists, the i18next MF1 install base is healthy and growing, but the i18next side has not started migrating to MF2 yet. Why adoption is slow Three reinfor
40cing factors: 1. TC39 is stuck. Per issue 49 on the TC39 , the committee asked for roughly a dozen organizations to be using MF2 in production before advancing to Stage 2.7. That gating signal hasn't been met. 2. No major framework default has switched. FormatJS \/ react intl are still ICU MessageFormat 1. Lingui is MF1. Tolgee is MF1 in its ICU docs. i18next removed legacy in v26 but kept the built in Formatter, not a MF2 migration. 3. No competing TMS has shipped MF2 support. Crowdin's 2026 blog has zero MF2 mentions across 13 monthly recaps. Lokalise's MF1 guide ranks fine; no MF2 announcement found. Same for Phrase and Transifex. Net: the spec is stable but the gravitational pull toward adoption hasn't started. Should you migrate to MF2 today? Most teams: no, not yet. ICU MessageFormat 1 still works, has wide framework support, has documentation everywhere developers look, and has been battle tested for over a decade. Until at least one of FormatJS, Lingui, or a major framework defaults to MF2 (or until TC39 advances to Stage 2.7), migrating now means owning the rough edges yourself. Migrate now if you fit one of these: Brand new project. You're starting fresh and don't have an existing message library. Picking MF2 means future proofing without rewrite cost. Heavy use of complex selectors. Gender + plural combinations, nested selectors, multi variable matching: these are MF1's pain points and MF2's strengths. You want to be early. You have the engineering bandwidth to deal with sparse documentation and limited tooling, and the strategic interest in being ahead. For everyone else, the right move is: stay on ICU MessageFormat 1, watch the inflection signals, and be ready to migrate when the ecosystem moves. How Locize handles this today (and tomorrow) Three things matter for a TMS in this transition: 1. Format agnostic storage today. Locize stores translation messages as text. Whatever format you write (ICU MessageFormat 1, MessageFormat 2, plain interpolation, or anything else) is preserved verbatim through the editor, the CDN, and the API. See supported i18n formats, the pluralization reference, and the full file format support matrix. 2. No vendor lock in to a specific message format. The plugin reads Locize served messages the same way does. When MF2 adoption inflects and you want to migrate, you can update messages in place in Locize. No TMS change required. 3. First class MF2 editor support coming when MF2 is accepted. Internal work on a Locize side MF2 message handler is already underway. The plan: ship full first class MF2 support in the editor (syntax aware editing, variant tooling, type checked placeholders) when at least one of the inflection signals below triggers (TC39 advances, a major framework defaults to MF2, or a critical mass of i18next users start migrating). No date promised; the trigger is ecosystem readiness, not a calendar. In other words, picking Locize today doesn't lock you into MF1 or MF2 specifically. Both work now; first class MF2 support is on the runway when the ecosystem is ready. What to watch for in 2026â2027 The signals that meaningful adoption is starting: TC39 advances to Stage 2.7 or Stage 3. This is the clearest signal that production deployments have crossed the dozen orgs threshold. FormatJS or Lingui ships MF2 as a default (or first class) option. Either would represent a significant ecosystem signal. A major SaaS or e commerce platform publicly documents a MF2 deployment. \"We use MF2 in production at $company\", even a single one, would shift the conversation. i18next mf2 weekly downloads cross 1,000. Mechanical signal: the i18next side bridge moves from \"spec curious developers\" to \"real projects shipping.\" We'll publish a follow up post when any of these triggers. For now, this is where things stand."},{"slug":"what-is-locize","title":"What is Locize? Continuous Localization in One Page","description":"Locize is a continuous localization platform built by the creators of i18next: connect your app, translate with AI, route through review, deliver via CDN, no redeploys needed. This page covers the entire product in a single read.","date":"2026-05-08","category":"Guides","thumbnail":"\/img\/blog\/what-is-locize\/what-is-locize.webp","readTime":"9 min read","searchText":"hideCta: true, title: 'What is Locize? Continuous Localization in One Page', description: 'Locize is a continuous localization platform built by the creators of i18next: connect your app, translate with AI, route through review, deliver via CDN, no redeploys needed. This page covers the entire product in a single read.', date: '2026 05 08', thumbnail: '\/img\/blog\/what is locize\/what is locize.webp', image: '\/img\/blog\/what is locize\/what is locize.webp', category: 'Guides', tags: ['localization', 'locize', 'continuous localization', 'i18n'], faq: [ q: 'What is Locize?', a: 'Locize is a continuous localization platform for software teams. It collects new translation keys from your application, generates AI first drafts, routes them through a configurable review workflow, and delivers finished translations live via a global CDN, without redeploying your co
40de. Locize is built by the maintainers of i18next.' , q: 'Who is Locize built by?', a: 'Locize is built by the team behind i18next, one of the most widely used JavaScript internationalization frameworks. The company is registered in Switzerland and operates under GDPR compliant data processing.' , q: 'How is Locize different from a translation file workflow?', a: 'A traditional file workflow exports a JSON, YAML, or XLIFF file, sends it to a translator or AI, commits the result, and rebuilds the app (typically days end to end). Locize keeps that file workflow (you can still pull translations into your repo) but adds a URL: translations also stream live to your app via CDN. A typo fix or a new language ships in seconds without a redeploy. You choose the model per project and per version.' , q: 'Does Locize use AI for translation?', a: 'Yes. Automatic translation fires when a developer adds a new key, filling every target language with a context aware first draft. You can use the built in Locize AI service or your own API key for OpenAI, Gemini, Mistral, or DeepL. Project styleguide, glossary, and key level descriptions or screenshots are automatically injected into every AI prompt. AI output enters a configurable review workflow before publishing.' , q: 'Is Locize GDPR compliant?', a: 'Yes. Locize is operated by a Swiss company under EU and Swiss data protection rules. Enterprise plans add SAML SSO, project level MFA enforcement, and an audit log for user and permission events. A standard DPA is available; data residency stays in Europe.' , q: 'Can I use Locize without i18next?', a: 'Yes. While Locize integrates particularly cleanly with i18next (three lines of config and missing keys flow automatically), it works with any framework that consumes JSON based translations: React, Vue, Angular, Svelte, Next.js, mobile, server, or custom. The CLI, REST API, and GitHub Actions cover sync and download for any build pipeline. Locize also supports YAML, XLIFF, gettext, .strings, .xcstrings, RESX, and many more file formats for import and export.' , q: 'What does the review workflow do?', a: 'Review is enabled per language. When a translation is created or modified (by a translator, by AI, or by automatic translation), it enters a pending review state. A reviewer with the right role sees the proposed change and can accept or reject it. Multiple reviewers can weigh in. Only approved translations get published. Every change is tracked per key with prior values, editor identity, and timestamps for audit purposes.' , q: 'Is there a free plan?', a: 'Yes. Locize has a permanent free plan for small projects and a 14 day full feature trial of paid plans (no credit card required). Pricing is published openly: no sales calls, no quotes. Larger plans add capacity, SLAs, SAML SSO, and Enterprise features.' ] Locize is a continuous localization platform for software teams. You connect your application to Locize via a backend plugin, the API, or a CLI. Locize collects new translation keys, generates AI first drafts, routes them through a human review workflow, and ships finished translations live via a global CDN, all without redeploying your code. It is built by the team behind i18next , one of the most widely used JavaScript i18n frameworks, so it integrates cleanly with i18next, React, Vue, Angular, Next.js, Svelte, and any framework that consumes JSON based translations. This page covers the entire product in a single read. There is also a 12 minute video walkthrough embedded at the bottom for those who prefer watching. Table of contents Why a URL changes everything The four step workflow Built by the i18next team Connecting your app The translation editor AI translation, production grade Quality checks and review CDN delivery without redeploys Versions, branches, multi tenant Built for the whole team: your data stays yours Use Locize from your AI assistant (MCP) Get started, and watch the 12 min demo Frequently Asked Questions Why a URL changes everything Most translation tools give you a file. You export it, commit it, ship a build. Locize works that way too: y
40ou can pull translations into your repository as JSON or any of a dozen other formats. But Locize also gives you a URL . Translators update copy, the URL serves the new version, your app picks it up. No build, no deploy. That single architectural option changes the whole workflow: translation isn't a release blocking step anymore. It runs alongside your code, and updates ship in seconds instead of days . The choice between file based and URL based delivery is yours, per project and per version. Some teams stay on files for production critical strings and use the URL only for development. Others let everything stream live. Locize doesn't force the model. The four step workflow Locize fits into a familiar developer loop: 1. Connect : your app connects to Locize via a backend plugin, the API, or the CLI. When code references a translation key that doesn't exist yet (a button label, an error message), it's reported to Locize automatically. 2. Translate : AI or machine translation gives you a first draft. Translators review and refine in a dedicated CAT editor. Optionally, order professional human translation directly from inside Locize. 3. Review : translations enter a configurable review workflow. A reviewer with the right role accepts or rejects each change. Multiple reviewers can weigh in. Only approved translations get published. 4. Deliver : when you publish, the new translations go live via global CDN. Your app fetches them at runtime, so a typo fix or a new language is live without redeploying. Whether you start from existing JSON files or instrument a fresh app, the whole loop runs without anyone juggling files in pull requests. Built by the i18next team Locize is built by the maintainers of i18next , one of the most widely used i18n frameworks in JavaScript. We're a Swiss company, GDPR compliant, trusted by teams worldwide from solo developers to global brands. There are no sales reps, no procurement cycles, no MSAs. Pricing is fully laid out: no quotes. You sign up and you're inside the product within a minute, ready to create your first project. Connecting your app Setup is short. For i18next users, install the Locize backend plugin, add your project ID and API key, enable , and three lines of config later your app is live. Missing keys flow into Locize automatically; new translations stream back via CDN. Not on i18next? You have several integration paths: CLI : for sync, download, and migrations GitHub Action : automated sync on every push, plus a separate download action REST API : fine grained control for any pipeline i18next cli : instrument an existing JavaScript codebase to extract keys automatically Already have translation files? Drag and drop them into Locize from the project dashboard: JSON, YAML, XLIFF, gettext, .strings, .xcstrings, RESX, and many more. Or use the CLI to migrate the whole project in one command. The full integration walkthrough is on our YouTube channel. The translation editor Once keys are in Locize, your team works in the CAT (Computer Assisted Translation) editor . All target languages for a key sit side by side. Translators filter by language, state, tags, and full text search, and if you've added the plugin, also by keys that haven't been used in months. Gold for cleaning up dead translations before a release. The glossary highlights approved and forbidden terminology. Pair it with a project styleguide (tone, formality, brand voice), and every translator and every AI prompt sees the same rules. When the glossary spots an inconsistency, it flags it inline through the checks issues system. Each key can carry a context description , character limits , and screenshots showing where the string appears in the UI. The screenshot sits right next to the segment, exactly the context that's also injected into AI translation prompts. Machine translated strings are marked as needing review, with a one click confirm once a human has checked them. Beyond the editor, the InContext editor lets translators work in the actual running app via a popup overlay. They click the text in your live app and edit it directly. No copy paste, no context loss. AI translation, production grade If you're already using ChatGPT or Claude for translations, you've probably hit three walls: 1. Terminology drifts across languages. Without a glossary that AI can read, the same brand term gets translated three different ways across markets. 2. No review safety net for production copy. AI output goes straight to users, with all the brand and legal risk that implies. 3. Every typo fix means another build. The localization workflow is still tied to your CI\/CD pipeline. Locize is the layer between your AI and your users that solves all three. AI translates. Locize manages. When a developer adds a new translation key, automatic translation fires (using either the built in Locize AI service or your own API key for OpenAI, Gemini, Mistral, or DeepL) and fills in every target language with a context aware first draft. The styleguide, glossary, and key level descriptions and screenshots are automatically injected into every AI prompt. The same translation engine drives bulk actions across whole namespaces, single segment AI suggestions , and the in editor AI Assistant for rephrasing or shortening to fit a UI constraint. And when AI isn't enough (legal text, regulated copy, brand critical messaging), you can order professional human translation directly from inside Locize. We're integrated
40with Supertext, TextMaster, Blend, and translated. Quality checks and review AI gives you speed. Automated quality checks and the review workflow give you the safety net. Locize runs a set of consistency checks across every translation. The Bulk Actions panel runs them all: glossary consistency, translation memory consistency, i18n syntax (placeholders, nesting, interpolation patterns), exists in source, source changed after translation, max characters, length restrictions, invalid nesting, and array size. Run them per segment, across a namespace, or across the whole project. When a translator edits a key, source changed warnings cascade automatically across every target â your team sees exactly which translations need a second look after a wording change. Review goes one step further. Production translations should not ship until a second pair of eyes has signed off. So Locize gives you a configurable review workflow. Turn it on per language, like production facing German, and skip it for languages where it would just slow your team down. Once enabled, when a translation is created or modified (by a translator, by AI, or by automatic translation), it enters a \"pending review\" state. A reviewer with the right role sees the proposed change and can accept or reject it. Multiple reviewers can weigh in. Only approved translations get published. Every change is tracked per key: prior values, who edited them, when. Full history, ready for an audit. CDN delivery without redeploys Now back to the URL story. When you publish, translations are pushed to a global CDN . Your app fetches them at runtime, so a typo fix or a new language is live without redeploying. The publish modal shows per language and per namespace status: what's up to date, what's pending. Publish manually, or turn on auto publish per version . Pick the right CDN tier ( Standard , Pro , or private downloads for authenticated delivery) and set cache duration per version: continuous flow for development, deliberate control for production. For most projects, this is the most loved Locize feature. A typo in a button label that would normally take a release cycle to fix becomes a 10 second edit in the editor and a \"Publish\" click. Your users see the corrected copy on their next page load. Versions, branches, multi tenant Translation work follows the same patterns as your code. Versions are parallel translation sets. The default version is , where your team adds new keys and edits ongoing work. Production versions hold what's live for users. Branches go further. Spin one up alongside a feature branch in your repo. Edit translations in the branch: overrides only show up there, marked clearly so a translator knows what's branch specific. The parent project is unaffected. Branches inherit styleguide, glossary, and language settings from the parent. If you're building SaaS, multi tenant lets each of your customers override translations for their own brand or terminology, without you maintaining separate projects. Each tenant inherits everything from the parent and overrides only what's different. When a tenant overrides a source language value, downstream target language translations are flagged automatically so the tenant's translators see exactly which strings need re checking. As overrides accumulate, the bulk Run Issue Checks panel surfaces unnecessary ones (overrides where the tenant value matches the parent). One bulk action removes them and keeps your data clean. Built for the whole team: your data stays yours Different roles, same project. Developers get the CLI, REST API, GitHub Actions for sync and download, and native i18next plugins. Your codebase stays the source of truth. Translators get the editor, AI Assistant for rephrasing or shortening, translation memory, glossary, and quality checks, without ever touching a repository. They can also use Locize on its own; see using Locize as a translator. Engineering leaders and product managers get role based access scoped per language, namespace, or version, plus dashboards for translation coverage and word counts across versions. And your data is yours . Export every language and namespace as a zip from the editor, download via the CLI, or pull through the API. Automated backups with restore from snapshot are available on paid plans. There's no lock in. Take your translations with you whenever you want. Enterprise teams get SAML SSO, project level MFA enforcement, an audit log for user and permission events, and full GDPR compliant data processing from a Swiss jurisdiction. Use Locize from your AI assistant (MCP) If you use Claude, Cursor, or VS Code with Copilot, the Locize MCP server connects your AI assistant directly to your translation projects. Authenticated with a Personal Access Token, twenty two tools cover the full lifecycle: check coverage before a release, report new keys from a code review, publish a version, create a branch, manage languages, all from natural language inside your editor. This is what makes Locize infrastru
40cture for AI workflows , not a tool that competes with AI. Your assistant generates translations. Locize manages them. A dedicated MCP setup video walks through the install in detail. Background reading: the MCP server announcement post. Get started, and watch the 12 min demo That's Locize. Continuous localization, AI you can ship, and a workflow that grows with your team. Start free at locize.com. Fourteen day full feature trial, no credit card required. There's a permanent free plan for small projects, too. If you prefer watching, here's the same content as a 12 minute video walkthrough: Companion deep dives: MCP server setup saveMissing â CDN core flow InContext editor Frequently Asked Questions frontmatter.faq.map(( q, a ) = ( q a ))"},{"slug":"what-is-i18n","title":"What is i18n? (The 2026 Edition)","description":"Internationalization (i18n) is the architectural process of building software that can be adapted to different languages and regions without engineering changes. This 2026 guide covers modern i18n in the era of AI and server rendering.","date":"2026-05-05","category":"Guides","thumbnail":"\/img\/blog\/what-is-i18n\/i18n-translation-management-platforms.webp","readTime":"7 min read","searchText":"hideCta: true, title: 'What is i18n? (The 2026 Edition)', description: 'Internationalization (i18n) is the architectural process of building software that can be adapted to different languages and regions without engineering changes. This 2026 guide covers modern i18n in the era of AI and server rendering.', date: '2026 05 05', thumbnail: '\/img\/blog\/what is i18n\/i18n translation management platforms.webp', image: '\/img\/blog\/what is i18n\/i18n translation management platforms.webp', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'basics'], faq: [ q: 'What is the main purpose of i18n?', a: 'The main purpose is to remove technical barriers in code so that an application can support multiple languages and regions without requiring a rewrite of the source code. Done well, adding a new language becomes a translation task, not an engineering task.' , q: 'What does i18n stand for?', a: 'i18n is a numeronym for \"internationalization\": the word starts with i, ends with n, and has 18 letters in between. The same convention gives us l10n (localization, 10 letters between l and n) and g11n (globalization).' , q: 'How do you pronounce i18n?', a: 'It is usually spelled out as \"i eighteen n\" or pronounced \"internationalization\". Both are common in the industry; spelling it out is more typical in casual conversation, while the full word is used in formal contexts.' , q: 'Is i18n the same as translation?', a: 'No. i18n is the technical preparation of the code so it can support any language. Translation is the process of converting the actual text content, which happens during localization (l10n), after the code has been internationalized.' , q: 'What is the difference between i18n and l10n?', a: 'i18n (internationalization) is the engineering work: extracting strings, supporting Unicode and RTL, using locale aware formatting (Intl), handling plurals. l10n (localization) is the content work: translating strings, adapting date\/time\/currency formats, and tailoring images and tone to a specific market. i18n always comes first: you cannot localize software that has not been internationalized.' , q: 'What comes first: i18n or l10n?', a: 'i18n always comes first. You cannot localize (translate, adapt) an application that has not been internationalized (technically prepared) first. Trying to retrofit i18n after the fact is significantly more expensive than building it in from the start.' , q: 'What is i18next?', a: 'i18next is the most widely used JavaScript internationalization framework. It handles plurals, interpolation, context, fallback languages, namespaces, and pluggable backends (file, HTTP, CDN, AI, etc.). It works with React, Vue, Angular, Svelte, Next.js, and vanilla JavaScript, and is the foundation that Locize is built around.' , q: 'Do I need i18n if my app is only in English?', a: 'Often yes. Even monolingual apps benefit from i18n architecture: it isolates user facing str
40ings (making copy changes safer), enables locale aware date\/number\/currency formatting, and prepares the codebase to add a second language later without a rewrite. Even within English, en US (MM\/DD\/YYYY) and en GB (DD\/MM\/YYYY) differ enough to warrant locale aware formatting.' , q: 'What is an i18n key?', a: 'An i18n key (translation key) is the stable identifier a developer puts in the code in place of hardcoded text, for example t(\"checkout.payNow\"). At runtime the i18n framework looks the key up in the translation resources for the active language and renders the matching text. Keys decouple the code from the copy: the text can change, be translated, or be reviewed without touching the source code.' , q: 'What is an i18n file?', a: 'An i18n file (translation file, locale file, or resource file) stores the translations for one language, mapping translation keys to translated text. In the JavaScript world it is usually JSON (en.json, de.json, often split into namespaces); other ecosystems use gettext .po files, XLIFF, YAML, Java .properties, or ARB. In a modern setup these files are generated and synced by a translation management system rather than edited by hand.' , q: 'What is a fallback language?', a: 'A fallback language is the language an i18n framework uses when a translation is missing in the requested one. Fallbacks usually cascade: a missing key in de CH falls back to de, then to the configured default (often English), so users see meaningful text instead of a raw key. A fallback is a safety net, not a substitute for finishing the translation; a good workflow reports the missing key so it gets translated.' ] Internationalization (i18n) is the architectural process of designing software so it can be adapted to various languages and regions without engineering changes. However, the definition has shifted. In 2026, i18n is no longer just about extracting strings into JSON files. It is about building AI ready , context aware architectures. This guide covers the modern standard for internationalization, moving beyond basic definitions into the era of Generative AI and Server Components. Table of contents The 2026 Definition of i18n The Basics: Why \"18\"? Major Trends: AI & Server Components i18n vs. l10n: The Difference Common Misconceptions (Myths) The ROI of i18n: The Big Mac Effect Key Technical Challenges Code Example Core Vocabulary: Keys, Files, Fallbacks Step by Step Roadmap Future Proofing Frequently Asked Questions The 2026 Definition of i18n At its core, internationalization is about removing barriers. If you hardcode English text, use fixed date formats like , or assume a user reads from left to right, you create a barrier. Internationalization prepares your code to handle different character sets, pluralization rules, and cultural formatting before a single word is translated. In 2026, this also means preparing your code for automation . Your i18n structure must be readable not just by humans, but by Large Language Models (LLMs) to facilitate instant translation. The Basics: Why \"i18n\"? It is a numeronym. Developers shorten long words to type faster. The word âInternationalizationâ starts with an I , ends with an n , and has 18 letters in between. You will often see similar abbreviations in the tech stack: l10n: Localization (10 letters between L and n) g11n: Globalization k8s: Kubernetes How i18n is Changing in 2026 If you are following tutorials from 2023, you are likely using outdated patterns. Here is what matters for modern developers. AI and context awareness Traditional i18n relied on exact key matches. Modern i18n uses AI to understand intent . For example, the word âBookâ can be a noun (a physical book) or a verb (to book a flight). In 2026, i18n keys often include metadata or screenshots to help AI translators pick the right context automatically. Server side internationalization (RSC) With the rise of React Server Components (Next.js, Nuxt), i18n is moving to the server. This improves performance: the server renders the correct language before the HTML hits the browser. This eliminates the âflickerâ effect where a page loads in English before snapping to German. i18n vs. l10n: Whatâs the difference? While often used interchangeably, these are two distinct steps in the global expansion process. Think of i18n as the construction of a house, and l10n as the interior design for specific inhabitants. Feature Internationalization (i18n) Localization (l10n) Focus Code, Architecture & Engineering Content, Culture & Nuance Executed by Developers & DevOps Translators, Linguists & AI Timing During the development phase After development (or continuously via CI\/CD) Goal To make the application âlocalizableâ technical wise To adapt the application to a specific locale Example Enabling Unicode support, using keys instead of hardcoded text Translating âHelloâ to âGuten Tagâ, formatting dates (DD.MM.YYYY) i18n Myths That Are Still Alive in 2026 Even in modern development, myths persist that prevent teams from scaling globally. Letâs debunk the top 5. Myth 1: It is only for multinational giants False. In the digital age, a small startup can have users in Japan and Brazil on day one. Implementing i18n creates scalable infrastru
40cture, increasing your total addressable market immediately. Myth 2: âi18n is just translationâ Translation is replacing words. Internationalization is adapting the product experience . It includes adjusting UI layouts for longer text, supporting Right to Left (RTL) languages, and formatting data to local standards. Myth 3: It is too expensive Refactoring a finished app for i18n is expensive. Building it with i18n in mind from the start is negligible. With modern tools like Locize , the cost is automated away. The ROI of reaching a global audience far outweighs the initial setup time. Myth 4: Only relevant for e commerce Incorrect. From games to productivity tools, users trust software that speaks their language. Games, in particular, see massive engagement boosts when localized effectively. Myth 5: âWe only support Englishâ Even English varies. en US uses ; en GB uses . Without i18n, your app looks âforeignâ and untrustworthy to British or Australian users. The ROI of i18n: The Big Mac Effect Why go through this effort? Because generic pricing and messaging fail in a global market. The Big Mac Index Example The âBig Mac Indexâ perfectly illustrates why hardcoding prices or assumptions is fatal. A Big Mac is a standardized product, but its price varies wildly based on local purchasing power: Switzerland: $7.73 USA: $5.58 Euro Area: $5.82 If your software hardcodes for everyone, you are underpricing in Switzerland and overpricing in developing markets. i18n enables dynamic strategy: By implementing i18n technically, you can serve different price lists and currencies based on the user's locale. Itâs not just about language; itâs about market fit . Key Technical Challenges Extracting text is easy. The real complexity lies in the details. Pluralization: English has two forms (singular\/plural). Polish has four. Arabic has six. Your code must handle this logic dynamically. Variable interpolation: You cannot concatenate strings like . In Japanese, the name might come first. You must use placeholders: . Formatting: Prices, dates, and numbers vary wildly. Use the standard API in browsers to handle this without bloating your code. Code Example: i18n in Practice Here is how i18n looks in a modern JavaScript\/React environment using a library like i18next . The wrong way (hardcoded): The r
40ight way (internationalized): The translation lives in a separate JSON file or is loaded from a CDN: Core i18n Vocabulary: Keys, Files, and Fallback Languages Three terms come up in every i18n codebase, and getting them precise saves a lot of confusion. What is an i18n key? A translation key is the stable identifier that replaces hardcoded text in the code: instead of . At runtime the framework looks the key up in the translation resources for the active language. Keys are the contract between code and content: the copy can change, be translated, or be reviewed without touching the source. Naming them well matters more than it looks; we wrote a separate guide to i18n key naming covering nesting, namespaces, and naming conventions. What is an i18n file? A translation file (also called locale file or resource file) stores the translations of one language as a mapping from keys to text. In JavaScript that is usually JSON ( , , split into namespaces as the app grows); other stacks use gettext , XLIFF, YAML, , or ARB, and there are many formats across ecosystems. Two things about these files change how you should treat them: they are per language artifacts (one file per locale per namespace), and in a modern workflow they are generated and synced by a translation management system rather than edited by hand. What is a fallback language? The fallback language is what the framework renders when a translation is missing in the requested language. Fallbacks cascade: a key missing in falls back to , then to the configured default (usually English), so the user sees meaningful text instead of a raw key. Treat the fallback as a safety net, not a translation strategy: a good setup also reports the miss (i18next's ) so the gap gets translated instead of silently surviving on the fallback forever. Step by Step: Your i18n Implementation Roadmap Knowing the definition is one thing; executing it is another. Here is a proven process to get your software global ready: 1. Tech stack evaluation: Choose an i18n framework that scales. In the JavaScript ecosystem, i18next is the industry standard because it handles more than just translations: it manages plurals, context, and interpolation securely. 2. Preparation (the code): Audit your codebase. Remove hardcoded strings, standardize date\/time formats using , and ensure your UI can handle variable text lengths. 3. Tooling setup: Don't use spreadsheets. Connect your repo to a Translation Management System like Locize . This separates your development cycle from the translation cycle. 4. The âhuman in the loopâ strategy: While AI is fast, make use of local specialists in each of your target markets to review the final output. This ensures the most accurate user experience possible. 5. Compliance & privacy: Ensure your localized content meets regional legal requirements (GDPR in Europe, CCPA in California). 6. Testing (linguistic QA): Test your localization on real devices. Check for broken layouts (due to long text) and use pseudo localization during development. 7. Optimize & iterate: Analyze search engine performance (SEO) and App Store conversion rates for the new languages. Future Proofing your i18n Strategy Managing JSON files manually via email is a thing of the past. Keeping translations flowing alongside development is the job of a translation management system (also called a localization platform), run as a continuous localization workflow. Locize connects your code directly to your translation team (or AI). It offers: In context editing: click text in your live app to edit it Instant updates: publish translations without redeploying your code Glossary, style guide, and translation memory: keep terminology, tone, and brand voice consistent automatically, used as context by both human translators and AI AI translation with review: integrate OpenAI, Anthropic, Gemini, DeepL, or Google Translate, and route output through a human review workflow before publishing Version control: keep your translations in sync with your Git branches Don't build an i18n setup for yesterday. Build it for tomorrow. Automating i18next Translations with saveMissing Start your free trial with Locize Frequently Asked Questions frontmatter.faq.map(( q, a ) = ( q a ))"},{"slug":"translation-and-localization-companies","title":"Top Translation and Localization Companies (2026): How to Choose One","description":"A translation and localization company adapts your content for foreign markets: language, culture, legal context, currencies, and user experience. This 2026 guide ranks the top providers with real review data and explains how to choose one.","date":"2026-05-04","category":"Guides","thumbnail":"\/img\/blog\/translation-and-localization-companies\/good-localization-and-translation-companies.webp","readTime":"6 min read","searchText":"hideCta: true, title: 'Top Translation and Localization Companies (2026): How to Choose One', description: 'A translation and localization company adapts your content for foreign markets: language, culture, legal context, currencies, and user experience. This 2026 guide ranks the top providers with real review data and explains how to choose one.', date: '2026 05 04', thumbnail: '\/img\/blog\/translation and localization companies\/good localization and translation companies.webp', image: '\/img\/blog\/translation and localization companies\/good localization and translation companies.webp', category: 'Guides', tags: ['localization', 'guides'], faq: [ q: 'What is a translation and localization company?', a: 'A translation company converts text from one language to another. A localization company does more: it adapts the entire experience for a target market: language, cultural norms, legal requirements, measurements, currencies, tone of voice, user expectations, and visual elements. Translation makes text understandable; localization makes it feel native.' , q: 'What is the difference between translation and localization?', a: 'Translation converts words. Localization adapts the whole experience: text plus date and number formats, currency, address layouts, plurals, gendered language, images, legal references, and sometimes layout direction (RTL for Arabic and Hebrew). Translation is one part of localization; localization is what makes a product feel native rather than translated.' , q: 'How much do translation services cost?', a: 'Pricing typically ranges from about $0.07 to $0.24 per source word for human translation, depending on language pair, subject matter complexity, and turnaround time. Specialized content (legal, medical, marketing) is at the higher end; high volume web copy is at the lower end. Modern localization platforms like Locize use a software style subscription model that scales with project size rather than per word.' , q: 'How do I choose a translation agency?', a: 'Look at five things: (1) native linguists in your target languages, (2) domain expertise (medical, legal, software, marketing), (3) quality processes (ISO 17100 \/ 18587 certification, post editing review, native speaker review), (4) public reviews on Google and Trustpilot, and (5) transparent pricing. The cheapest option is rarely the best; the most expensive isn\\'t always either.' , q: 'Are AI translations replacing translation companies?', a: 'Not entirely. Modern AI (DeepL, ChatGPT, Gemini, NMT) handles general comprehension and first draft work well, but still falls short on idiomatic, legal, marketing quality, and culturally sensitive content. The current best practice is a hybrid model: AI for speed and scale, humans for nuance and review. Most professional translation companies have already integrated AI into their workflows for exactly this reason.' , q: 'What is the best translation company for software localization?', a: 'For software \/ SaaS, choose a provider that integrates with your i18n format (i18
40next JSON, XLIFF, gettext, .xcstrings) and supports continuous translation through APIs or CDN delivery, not just file handoff. Examples in this guide: Supertext, Translated, BLEND, plus modern translation management platforms like Locize that combine the workflow with AI\/MT and human review.' , q: 'What is ISO 17100 certification?', a: 'ISO 17100 is the international standard for translation services. It defines requirements for the people, processes, and quality control of professional translation work, including the requirement that every translation be reviewed by a second linguist (the \"four eyes principle\"). When evaluating a translation agency, ISO 17100 certification is a strong signal that they follow professional quality processes.' ] What Is a Translation and Localization Company? A translation and localization company is a service provider that adapts content from one language and market to another. A translation company converts text from one language to another. A localization company goes further: it adjusts cultural norms, legal requirements, measurements, units, dates, currencies, tone of voice, user expectations, and visual elements so the content feels native to the target market. Translation makes text understandable; localization makes it feel native, natural, and persuasive. The market is large and varied (there are roughly 18,000 translation and localization providers worldwide, ranging from boutique agencies to global enterprises) so choosing the right one materially affects your brand reputation, user experience, and ROI. Key facts What they do: translate and adapt content (language + culture + legal + UX) for foreign markets Pricing range: typically $0.07 â $0.24 per source word for human translation What to look for: native linguists, domain expertise, ISO 17100 \/ 18587 certification, transparent pricing, real reviews Translation vs. localization: translation = words; localization = full experience (formats, currency, images, tone, legal context) Modern best practice: hybrid AI + human, AI for speed, humans for nuance, review, and brand voice Number of providers worldwide: 18,000 translation and localization companies For many organizations, a 300% ROI after partnering with a professional localization provider is not unusual. But the market is full of translation agencies and quality varies enormously : anyone can call themselves a \"translation company\" without training, technology, or quality control. This guide explains: what should characterize a good translation company, how to find reputable translation agencies, and how to compare the best translation and localization companies worldwide. Key Takeaways Choosing the right translation & localization company directly affects your brand reputation, user experience, and ROI. Leading providers go beyond translation; they ensure cultural, legal, and technical accuracy for every market. A good localization and translation company is defined by native linguists, industry expertise, ISO certifications, transparent pricing, and strong reviews. This guide explains how to identify reputable agencies and how to compare good localization and translation companies worldwide using real translation agency services reviews . Modern localization blends human expertise + AI , enabling scalable, consistent, and high quality global content. Winners of This Yearâs Evaluation ð¥ 1. Supertext: Best Overall Quality & User Ratings Strongest combined rating across Google & Trustpilot Excellent quality consistency Ideal for SaaS, marketing, apps, and creative content ð¥ 2. BLEND: Best Global Scalability & Cultural Expertise Excellent cross platform reputation Large global translator network Strong cultural adaptation for B2C & enterprise brands Alternative Solution (11): Locize â Locize: The Modern Localization Platform If you prefer a simpler, more flexible solution than traditional agencies, Locize offers a smart alternative. Modern platform for managing localization projects Integrated translation services High reliability, transparent workflows, no agency overhead Built for tech companies, SaaS, and team
40s that need speed See our use case pages for website localization services and software localization service. The Worldâs Top Translation Agency Services with Reviews Did you know there are around 18,000 translation and localization companies worldwide? If youâre searching for good localization and translation companies, it can be difficult to keep an overview. To help businesses compare worldwide translation agency services based on real reviews, several consumer associations and independent market research firms regularly evaluate providers in this industry. Below, we have compiled the top translation and localization providers worldwide, along with additional recommended options. 1. Supertext 4.7 of 5 Stars on Google (43 reviews, 27.11.2025) 3.7 of 5 Stars on Trustpilot (1 review, 27.11.2025) Overall: Strongest reputation among all listed companies Top class localization solutions, Swiss made since 2005. Price: $0.16 â $0.24 per word. Over 3,000 professional translators and copywriters, ideal for app developers and SaaS companies. Local teams in Zurich, Berlin, and Los Angeles support projects every step of the way. 2. TextMaster 4.7 of 5 Stars on Google (37 reviews, 27.11.2025) 3.2 of 5 Stars on Trustpilot (7 reviews, 27.11.2025) Overall: Excellent Google score, moderate Trustpilot SaaS translation service suitable for simple web content to complex documents. Price: $0.066 â $0.132 per word. Offers specialized translations, including financial, technical, and legal. 3. BLEND 4.5 of 5 Stars on Google (37 reviews, 27.11.2025) 4.4 of 5 Stars on Trustpilot (105 reviews, 27.11.2025) Overall: Strong, consistent reviews across platforms End to end localization solutions focused on cultural nuances and consumer behavior. Price: $0.079 â $0.139 per word. A global community of over 25,000 translators and language experts. BLEND Express as a self service platform for personal and business projects. 4. Keywords Studios 3.5 of 5 Stars on Glassdoor (2233 reviews, 27.11.2025) Overall: Best rated global gaming localization provider Focused on gaming and multimedia localization. Offers a range of services: website, software, and app localization, content creation, voice over, and subtitling. Supports machine translation (MT) via the KantanMT platform. 5. LanguageLine Solutions 1.6 of 5 Stars on Trustpilot (42 reviews, 27.11.2025) 3.2 of 5 Stars on Indeed (1170 reviews, 27.11.2025) Overall: Mixed, strong performance in employment reviews, weaker customer reviews Leader in healthcare, covering over 160 languages. Provides specialized language services in digital and print formats. Continuously expanding into new sectors like gaming and media localization. 6. RWS 1.5 of 5 Stars on Trustpilot (27 reviews, 27.11.2025) 3.3 of 5 Stars on Indeed (113 reviews, 27.11.2025) Overall: Long established provider, mixed reputation Over 60 years of experience in translation and localization. Focused on advanced technology and a global team, especially in tech, pharma, and automotive industries. Over 3,000 employees and 35 offices worldwide. 7. Lionbridge Technologies LLC 1.9 of 5 Stars on Trustpilot (32 reviews, 27.11.2025) Overall: Low client ratings but high global presence Global language services for businesses and individuals. Services include technical writing, multimedia localization, and creative transcreation. Uses modern translation management systems based on AI and machine learning. 8. Translated 4.4 of 5 Stars on Trustpilot (1818 reviews, 27.11.2025) Professional language solutions with a mix of human expertise and AI. Pricing varies based on contract. Supports over 200 languages and serves various industries, including legal, marketing, and technical. 9. TransPerfect 1.5 of 5 Stars on Trustpilot (62 reviews, 27.11.2025) Overall: Lowest public rating despite huge global footprint Global company with over 5,000 experts and offices in more than 90 countries. Supports over 170 languages with specialized services such as website and software localization. Utilizes the Translation Management System and GlobalLink to improve quality and efficie
40ncy. 10. Tomedes 4.9 of 5 Stars on Trustpilot ( 600 reviews, 21.05.2026) 4.9 of 5 Stars on Google (92 reviews, 21.05.2026) Overall: Strong, consistent ratings across platforms Operating since 2007, covering 240+ languages. Combines professional human translators with AI workflows via MachineTranslation.com. ISO 17100, ISO 18587, and ISO 9001 certified. 1 Year Quality Guarantee, 24\/7 human support. Trusted by 120,000+ businesses worldwide. A good complementary partner to a TMS like Locize, when human translation quality is the priority. Why not simply use machine translation instead of booking translation services? There is no question that machine translation has improved dramatically in recent years, but it still falls far short of the nuances of human translators. For internal communication or initial drafts, machine translation can certainly be helpful. For customer oriented content, legal documents or marketing materials, there is no way around professional translation and localization companies. Good to know: Modern translation and localization companies optimally combine both approaches through post editing processes. 11. Locize: We offer a simpler solution. Just reach out to us We are a modern platform for managing localization projects with an integrated translation service, delivering the highest standards of professionalism and reliability. Sounds good? â¡ï¸ Register for our Translation Management System here. Frequently Asked Questions frontmatter.faq.map(( q, a ) = ( q a ))"},{"slug":"i18next-in-production","title":"i18next in Production: Managing Translations at Scale","description":"What changes when your i18next project grows from a prototype to a production app with 10 languages, multiple teams, and thousands of translation keys. Practical patterns for scaling.","date":"2026-04-13","category":"Guides","thumbnail":"\/img\/blog\/i18next-in-production\/thumbnail.jpg","readTime":"6 min read","searchText":"hideCta: true, title: 'i18next in Production: Managing Translations at Scale', description: 'What changes when your i18next project grows from a prototype to a production app with 10 languages, multiple teams, and thousands of translation keys. Practical patterns for scaling.', date: '2026 04 13', thumbnail: '\/img\/blog\/i18next in production\/thumbnail.jpg', image: '\/img\/blog\/i18next in production\/title.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'workflow', 'production'] i18next scales from a weekend project to a production app with millions of users, but the way you manage translations needs to evolve as your project grows. At prototype scale, a file in your repo is all you need. At production scale (10 languages, multiple teams, thousands of keys), manual file management becomes the bottleneck, not i18next itself. This post covers the practical problems that appear when managing translations at scale, and the i18next ecosystem patterns that solve them. Problem 2: Nobody knows which keys are missing At prototype scale, one developer manages all the keys. At production scale, different teams own different namespaces, and nobody has a complete picture of what's translated and what's not. Common symptoms: Users see untranslated keys in production (the incident) A new feature ships with 12 languages but only 8 have translations Nobody knows that the namespace hasn't been touched in 3 months Pattern: saveMissing + coverage tracking i18next's feature detects untranslated keys at runtime and reports them: When a missing key is encountered, it's automatically sent to your translation management system. No manual extraction step, no \"did someone add this key?\" questions. With Locize, missing keys appear in the dashboard immediately. Combined with automatic translation, new keys can be translated into all target languages without any manual intervention, using your configured AI or MT provider with styleguide and glossary context. For build time key extraction (SSG, SSR, or when saveMissing isn't suitable for your runtime), the i18next cli scans your source code and extracts all calls. Problem 3: Translation quality drifts over time At prototype scale, one person writes all translations and they're internally consistent. At production scale, different people translate different parts at different times. \"Cancel\" becomes \"Dismiss\" in one dialog and \"Abort\" in another. Your brand's name for a feature is translated three different ways. Pattern: Glossary + Translation Memory + Styleguide These three features work together to maintain consistency: Glossary: Define approved and forbidden terminology. \"Drive\" means cloud storage, not driving. \"Workspace\" is always \"Espace de travail\" in French, never \"Zone de travail.\" Translation Memory: When a translator works on a new key, they see how similar strings were translated before. Fuzzy matching surfaces past translations with character level diffs. Styleguide: Define tone, formality level, target audience, and usage rules once. Ap
40plied automatically to all AI translation providers. In Locize, all three are injected into AI translation prompts automatically, so even AI generated first drafts are consistent with your established terminology and brand voice. Problem 4: No review process for translations At prototype scale, translations go straight to production. At production scale, a wrong translation in a legal disclaimer or a payment screen is a business problem. Pattern: Review workflow Enable per language review so changes go through approval before going live: 1. A translator (or AI) creates or modifies a translation 2. The change is marked as \"pending review\" 3. A reviewer accepts or rejects the change 4. Only accepted translations are promoted to production quality In Locize, the review workflow is configurable per language. Enable it for customer facing languages (German, French, Japanese) while keeping it off for internal\/developer languages where speed matters more than perfection. Problem 5: No way to test translations before releasing At prototype scale, \"testing\" means refreshing the page. At production scale, you need to verify translations in a staging environment without affecting production users. Pattern: Branches and versions Translation branches work like code branches: Create a translation branch when you create a feature branch Translate new strings in isolation Test in staging against the branch translations Merge the translation branch when the feature ships In Locize, branches mirror your Git workflow. Each branch has its own CDN endpoint, so your staging environment can point to the branch translations while production serves from the main version. Problem 6: SaaS customers need different translations If you build a SaaS product, your customers may need to customize translations: different terminology, different tone, different branding. Managing a separate translation project per customer doesn't scale. Pattern: Multi tenant overrides Locize supports multi tenant localization: a parent project holds base translations, and each tenant gets a child project that inherits everything but can override specific keys. Each tenant has its own CDN endpoint. This means: Base translations are maintained once Each customer can customize only the strings they care about Overrides are served efficiently: only the diff, not the full translation set Tenant users have isolated access: they can't see other tenants or the parent Problem 7: Translation updates require a deploy This is the most common friction point at scale. A translator fixes a typo. The fix sits in the TMS waiting for a developer to download the file, commit it, open a PR, get it reviewed, merge it, and deploy. Days pass. The typo is live in production the whole time. Pattern: CDN delivery with instant publish When translations are served from a CDN instead of bundled in your build, updates go live without deploying: 1. Translator fixes the typo in the editor 2. Clicks \"Publish\" (or auto publish is enabled) 3. CDN cache is invalidated 4. Next time a user loads the app, they get the fixed translation In Locize, publishing takes seconds. For the standard CDN, translations propagate globally within minutes. No code change, no build, no deploy, no PR. The complete production setup Here's what a production grade i18next setup with Locize looks like: Each piece is optional: you can adopt them incrementally as your project grows. Start with CDN delivery and saveMissing. Add review workflows when quality matters. Add branches when you have staging environments. Add multi tenancy when your customers need it. Getting started If you're running i18next in production with local JSON files and want to move to a managed workflow: 1. Register for free : no credit card required 2. Migrate your project : the CLI imports your existing JSON files 3. Switch to i18next locize backend : one config change, same API 4. Enable saveMissing : new keys auto appear in Locize 5. Enable auto translate : AI translates new keys automatically The entire migration takes less than an hour for most projects. Further reading How to set up automatic translation i18next cli walkthrough saveMissing + AI automation Going to production guide Branches vs. versions MCP server for AI assistants"},{"slug":"next-intl-vs-next-i18next","title":"next-intl vs next-i18next: Choosing the Right i18n Library for Next.js","description":"A technical comparison of next-intl and next-i18next for Next.js internationalization. Architecture, features, message formats, and when to choose each.","date":"2026-04-10","category":"Guides","thumbnail":"\/img\/blog\/next-intl-vs-next-i18next\/thumbnail.jpg","readTime":"5 min read","searchText":"title: 'next intl vs next i18next: Choosing the Right i18n Library for Next.js', description: 'A technical comparison of next intl and next i18next for Next.js internationalization. Architecture, features, message formats, and when to choose each.', date: '2026 04 10', thumbnail: '\/img\/blog\/next intl vs next i18next\/thumbnail.jpg', image: '\/img\/blog\/next intl vs next i18next\/title.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'nextjs', 'comparison'] Next.js developers choosing an i18n solution will likely narrow it down to two libraries: next intl and next i18next. Both supp
40ort the App Router and Server Components. Both are actively maintained. But they take fundamentally different architectural approaches. This post compares them on the things that matter for a real project: how translations are loaded, how they integrate with your stack, and what workflows they enable. (Need the bigger picture beyond Next.js? Our JavaScript localization guide covers React, Vue, Angular, Svelte, and vanilla JS too.) Core Standalone library (built on ) Built on i18next (the most widely used JavaScript i18n framework) with react i18next Message format ICU MessageFormat i18next JSON format (the most common format in the JS ecosystem) App Router Supported Supported via \/ Pages Router Limited\/legacy Full support via Server Components Supported Supported Translation loading Custom async loader function (you build it) Backend plugin ecosystem (drop in packages for CDN, filesystem, Locize, chained caching) Bundle size Minimal runtime via ICU precompilation Flexible, tree shakeable, scales with features used Type safety Build time catalog extraction Full TypeScript support with selector API How translations are loaded This is the most important architectural difference. next intl: custom loader function next intl uses a request scoped configuration function ( ) where you define how to load messages: You can load from local files, a CDN, a CMS, or any async source. There is no plugin system; you write the loader yourself. This is flexible but means every integration is custom code. next i18next: backend plugin ecosystem next i18next inherits the full i18next backend plugin ecosystem: Available backends include: i18next http backend : load from any HTTP\/CDN endpoint i18next locize backend : direct Locize CDN integration with saveMissing i18next fs backend : load from filesystem (Node.js) i18next chained backend : chain multiple backends (e.g., localStorage cache + remote) This plugin architecture means integrations with TMS platforms, CDNs, and caching layers are available as drop in packages rather than custom code. Message format next intl: ICU MessageFormat ICU MessageFormat is an industry standard supported by many TMS platforms. next intl includes a precompilation step ( ) that reduces the runtime to under 1KB. next i18next: i18next format i18next uses its own JSON format with syntax and key based pluralization (suffix , , , etc.). This format is natively understood by Locize and other i18next compatible tools. It is also widely adopted: i18next is the most downloaded i18n library in the JavaScript ecosystem. Both formats handle plurals, interpolation, and nesting. The choice is largely about ecosystem compatibility. saveMissing: automatic key discovery next i18next supports i18next's feature. When your app encounters a translation key that doesn't exist yet, it can automatically report it to your TMS: With the Locize backend, missing keys are batched and sent automatically. Combined with automatic translation, this creates a fully automated pipeline: write code â keys appear in Locize â AI translates â live on CDN. next intl does not support saveMissing natively. Key management is manual; you add keys to your JSON files or TMS yourself. That said, if you want this workflow while staying on next intl: the locize next intl example implements the equivalent in 150 lines using the generic locizer client. In development, new reference language keys (with descriptions for translator context) are pushed to Locize automatically, mirroring saveMissing. Translation management integration next i18next integrates directly with Locize via the dedicated plugin. This provides: CDN delivery at runtime (translations update without redeploy) saveMissing (automatic key discovery) InContext editor (translate on your running app) Branches (translation CI\/CD) Multi tenancy (per tenant overrides) The Locize backend is maintained by the same team that wrote i18next and next i18next. next intl does not have a dedicated TMS plugin. You can integrate with any TMS by writing a custom loader in , but the integration is your responsibility. next intl's documentation mentions Crowdin as a compatible TMS. For Locize, that custom loader already exists: the locize next intl example pairs next intl with runtime CDN delivery, dev mode missing key capture, and in context editing, while next intl keeps doing the rendering. The next intl
40+ Locize guide walks through the setup. Routing and middleware Both libraries handle locale routing via Next.js middleware: next intl uses and : URL based routing with dynamic segments Domain based routing supported Built in locale detection (URL, cookies, Accept Language) next i18next (v16+) uses (Next.js 16+) or : Cookie based locale detection Mixed Router support (App Router + Pages Router coexisting) scoping for multi router setups Both approaches work well. The routing mechanism is rarely the deciding factor. When to choose next intl You prefer ICU MessageFormat and want it built into the framework You want a standalone, self contained library with no external dependencies You prefer to write custom loader functions for translation sources You are building a Next.js only project with no need to share i18n setup across other platforms When to choose next i18next You want access to the largest i18n plugin ecosystem : drop in backends for CDN, filesystem, caching, and managed services You want saveMissing : automatic key discovery from your running app, no manual extraction needed You want CDN delivery : translations that update without redeploying your app You want a managed translation backend with AI translation, review workflows, and a translator UI via Locize You need branches and multi tenancy for c
40omplex localization workflows You want to share the same i18n setup across React, Vue, Node.js, React Native, or other platforms in your stack You want the proven maturity of i18next: 15+ years, most downloaded i18n library in JavaScript Summary Both next intl and next i18next are production ready libraries for Next.js internationalization. The choice comes down to what you need beyond basic translation: next intl is a self contained solution with ICU message format. Good for Next.js only projects where you want to manage everything yourself. next i18next connects you to the i18next ecosystem: the most widely adopted i18n infrastructure in JavaScript. Backend plugins, saveMissing, CDN delivery, AI powered translation, and a managed backend via Locize are all available as drop in additions, not custom code you write and maintain. For teams that want their translations to work across multiple platforms, update without redeploying, and scale with managed infrastructure, next i18next with Locize is the most complete setup available. Further reading next i18next v16 guide: complete setup for App Router and Pages Router Next.js App Router i18n guide: detailed App Router tutorial next intl + Locize guide: runtime CDN delivery, missing key capture and in context editing on next intl locize next intl example: example repository for the next intl setup i18next vs alternatives: broader comparison Locize + next i18next integration: example repository"},{"slug":"automatic-translation-i18next-locize","title":"How to Set Up Automatic Translation with i18next and Locize","description":"Step-by-step guide to creating a fully automated translation pipeline: write code, keys appear in Locize, AI translates them, and updates go live via CDN, with no manual steps.","date":"2026-04-09","category":"Guides","thumbnail":"\/img\/blog\/automatic-translation-i18next-locize\/thumbnail.jpg","readTime":"4 min read","searchText":"title: 'How to Set Up Automatic Translation with i18next and Locize', description: 'Step by step guide to creating a fully automated translation pipeline: write code, keys appear in Locize, AI translates them, and updates go live via CDN, with no manual steps.', date: '2026 04 09', thumbnail: '\/img\/blog\/automatic translation i18next locize\/thumbnail.jpg', image: '\/img\/blog\/automatic translation i18next locize\/title.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'ai', 'workflow', 'automatic translation'] Most i18next setups require manual steps to manage translations: extract keys, send them for translation, download the results, commit the files, deploy. Each step is a context switch, and the longer the cycle, the more likely translations lag behind your code. This guide shows how to eliminate all of those manual steps using i18next's feature and Locize's automatic translation workflow. The result: you write code, and translations appear in all your target languages, live on the CDN, without a deploy. Step 1: Set up i18next with Locize backend Install the packages: For React, also add . For Next.js, add . The backend plugin works with any i18next setup. Configure i18next with the Locize backend and enabled: Important: should only run in development. In production, remove the and set . See the going to production guide for details. The option defaults to , so saveMissing only fires on localhost even if you forget to disable it. Step 2: Enable automatic translation in Locize In your Locize project: 1. Go to Project Settings EDITOR, TM\/MT\/AI, ORDERING 2. Enable Automatic Translation Workflow Choose which translation provider to use: Locize AI : built in, works on all paid plans, no external API key needed. Token based billing. Locize MT : built in machine translation, character based billing. BYOK (Bring Your Own Key) : use your own OpenAI, Gemini, Mistral, or DeepL key. Available on Growth ($49\/mo) and above. No markup: you pay the provider directly. All providers (where possible) automatically receive context from your project's styleguide, glossary. This is what makes Locize's automatic translations better than raw API calls: the AI knows your brand voice, approved terminology, and past translations. Step 3: Write code, translations happen automatically Use translation keys in your components: When your app runs
40in development: 1. i18next encounters for the first time 2. batches the key (5 second debounce) and sends it to Locize 3. Locize receives the key with its default value (\"Complete your order\") 4. Automatic translation kicks in: the key is translated into all target languages 5. Translations appear on the Locize CDN Next time the app loads, i18next fetches the translations from the CDN, including all the auto generated translations. Step 4: Improve translation quality with context Automatic translation works better with context. There are several ways to provide it: Styleguide Define your brand voice once in Project Settings Styleguide: Tone of voice (formal, casual, technical) Target audience Do's and don'ts Per language overrides The styleguide is automatically injected into every AI translation prompt. Glossary Add approved terminology in Project Settings Glossary. Terms can be marked as approved or forbidden, with target language equivalents. The glossary is injected into AI prompts as \"use these exact translations.\" Key level context When using saveMissing, you can include context descriptions: Or add context directly in the Locize editor for each key. This context appears in the AI prompt and is shown to human translators. Step 5: Optional human review For content where AI quality is sufficient (internal tools, developer facing UI, technical docs), you can skip review entirely. For brand critical content, AI or MT translations are marked as needing review. A translator checks them in the Locize editor and confirms or modifies them; a confirmed translation keeps its AI or MT origin on record, an edited one becomes human translated. Step 6: Deploy translations without redeploying Translations served via the Locize CDN update independently of your app deployment: Auto publish (if enabled for your version): translations go live on the CDN as soon as they're saved Manual publish : click \"Publish\" in the Locize UI, or call from the CLI or a GitHub Action Your app fetches translations from the CDN on each load. A copy fix, a new language, or a tone adjustment: all live without touching your codebase. The AI agent workflow (bonus) If you use an AI coding assistant (Claude, Cursor, VS Code), the Locize MCP server lets your assistant manage translations directly: \"Report these new keys to Locize\" : the AI agent equivalent of saveMissing. New keys on the reference language trigger automatic translation when enabled. \"What's the translation coverage for my project?\" : check if all languages are ready before publishing. \"Publish the latest version\" : push translations to CDN from your AI assistant. The MCP server exposes 22 tools covering the full translation lifecycle. Summary Step What happens Manual effort Write code with i18next detects missing key None saveMissing sends key to Locize Key appears in project None Automatic translation AI\/MT translates all languages None Human review (optional) Translator reviews in editor Optional CDN delivery Translations go live None (auto publish) or one click The entire pipeline from code to live translations can be fully automatic. The only manual step is human review, and that is optional. Further reading Automatic Translation documentation saveMissing + AI automation tutorial Styleguide documentation Going to production guide MCP server documentation Why not just use AI to translate?"},{"slug":"locize-alternatives-compared","title":"Locize Alternatives Compared: How We Stack Up","description":"An honest comparison of Locize with Crowdin, Lokalise, Phrase, Tolgee, SimpleLocalize, and Localazy. What each platform does well, where Locize is different, and how to choose.","date":"2026-04-08","category":"Product","thumbnail":"\/img\/blog\/locize-alternatives-compared\/thumbnail.jpg","readTime":"6 min read","searchText":"hideCta: true, title: 'Locize Alternatives Compared: How We Stack Up', description: 'An honest comparison of Locize with Crowdin, Lokalise, Phrase, Tolgee, SimpleLocalize, and Localazy. What each platform does well, where Locize is different, and how to choose.', date: '2026 04 08', thumbnail: '\/img\/blog\/locize alternatives compared\/thumbn
40ail.jpg', image: '\/img\/blog\/locize alternatives compared\/title.jpg', category: 'Product', tags: ['localization', 'i18n', 'comparison', 'guides'] Choosing a translation management system is a decision that stays with your project for years. This post compares Locize with the most common alternatives, focusing on what actually matters: how translations get into your app, what the workflow looks like, and what you pay. We are biased: Locize is our product. But we have tried to be factual. If something has changed since this was written, let us know. Based on publicly available documentation as of April 2026. Features change, so verify before purchasing. Locize vs. Crowdin Crowdin is a well established, file centric TMS. You upload translation files, translators work on them, and you download the results. For over the air delivery comparable to Locize's built in CDN, Crowdin offers a separate OTA SDK with MAU based pricing on top of the subscription. Key differences: Crowdin uses the same word counting model as Locize (source words multiplied by target languages), making them directly comparable on pricing Locize includes CDN delivery in every plan. A mid size project (50,000 hosted words) fits Locize's Growth plan at $49\/month including 5 million CDN downloads Locize publishes to CDN instantly: no file sync, no redeploy needed Crowdin has a larger ecosystem of file format integrations and a broader non JavaScript user base Best for: Teams that need a file management workflow across many platforms and formats. Locize is better if you need runtime CDN delivery and native i18next integration. Detailed comparison â Locize vs. Lokalise Lokalise is an enterprise focused TMS with a seat based pricing model. Features like SAML\/SSO are typically reserved for higher tier plans, and advanced capabilities require a sales conversation. Key differences: Lokalise uses seat based pricing. Locize offers unlimited users on Professional plans and above SSO is available on Locize without an enterprise sales call Locize starts at $7\/month (Starter) vs. significantly higher base costs at Lokalise Lokalise treats i18next as one of many file formats. Locize was built around i18next Lokalise has a broader set of platform integrations (Sketch, etc.) Best for: Large enterprises that need a full localization suite with design tool integrations. Locize is better for developer led teams that want i18next native infrastru
40cture without seat based pricing. Detailed comparison â Locize vs. Phrase Phrase offers a suite of localization products (Strings, TMS, Orchestrator) aimed at enterprise workflows. Advanced features require demo calls and annual contracts. Key differences: Phrase splits its offering across multiple products, which can add complexity AI translation is available via Phrase's enterprise suite. Locize offers BYOK AI (bring your own OpenAI, Gemini, or Mistral key) from the $49 Growth plan Locize is fully self service: create an account and go live in minutes For Phrase, i18next is one of dozens of supported formats. For Locize, i18next is the foundation Best for: Enterprise localization teams with complex workflows across many platforms. Locize is better for developer teams that want self service, transparent pricing, and i18next native tooling. Detailed comparison â Locize vs. Tolgee Tolgee is an open source TMS, offered as a hosted cloud with a self host option. Self hosting is free in license, but your team manages the infrastructure: database, backups, security patches, updates, and CDN distribution. Key differences: Tolgee offers open source and the option to self host (with the ops that brings). Locize is a managed service with CDN included on every plan Tolgee ships its own MIT licensed SDKs. Locize uses the i18next ecosystem (15+ years, widely adopted) Locize includes global CDN delivery, automated backups, and zero DevOps scaling Both offer AI translation with glossary context and BYOK. Locize adds a structured styleguide injected into every prompt and a built in Locize AI service that needs no API key Best for: Teams that want open source, or full infrastructure control via self hosting. Locize is better for teams that want an i18next native managed service without DevOps overhead. Detailed comparison â Locize vs. SimpleLocalize SimpleLocalize is a developer friendly TMS with source key based pricing (language agnostic). Key differences: SimpleLocalize uses generic (created by the Locize team members) , not a dedicated plugin. requires a custom implementation. Locize has a first party where works with just one config flag SimpleLocalize offers environments (latest, production, custom) but not git style branches with merge workflows. Locize supports branches that mirror your Git branching strategy SimpleLocalize has no native multi tenant concept. Locize supports per tenant translation overrides out of the box SimpleLocalize's source key pricing is cheaper for projects with many target languages Best for: Budget conscious projects with many target languages that don't need branches or multi tenancy. Locize is better for i18next native integration, branch workflows, and multi tenant SaaS products. Detailed comparison â Locize vs. Localazy Localazy is a TMS with source key based pricing and CDN delivery available as an add on. Key differences: Localazy uses source key pricing (language agnostic). Locize counts total words across all languages Localazy connects via generic file sync. Locize has a dedicated i18next backend plugin with native saveMissing Localazy has no built in support for i18next namespaces, branching, or versioning. Locize was designed around these concepts Localazy's CDN is an add on on top of the subscription. Locize includes CDN in all plans Locize supports first class multi tenant overrides. Localazy does not Best for: Projects with many target languages and few source keys where language agnostic pricing saves money. Locize is better for i18next native workflows with CDN delivery, branches, and multi tenancy included. Detailed comparison â Pricing at a glance Platform Model Small project (200 keys, 5 langs) Mid project (1K keys, 10 langs) Locize Words (all languages) Starter $7\/mo Growth $49\/mo SimpleLocalize Source keys Free $14\/mo $14\/mo Localazy Source keys Free $2\/mo $44\/mo Tolgee Source keys (self hosted free) Free $53\/mo Crowdin Hosted words Pro $59\/mo + CDN Pro $59\/mo + CDN Lokalise Seats + usage $154\/mo $154\/mo Phrase Tiered $145\/mo $145\/mo Prices from publicly available pricing pages, April 2026. Locize prices include CDN delivery. Add $10\/mo for platforms without built in CDN if you need runtime delivery. How to choose If you use i18next and want the deepest integration: Locize If you need the cheapest option with many languages: SimpleLocalize or Localazy If you want to self host : Tolgee If you need enterprise features across many platforms: Lokalise or Phrase If you need file based workflows with a large translator community: Crowdin The honest answer is that all of these tools work. The question is which w
40orkflow and pricing model fits your team. If you are building with i18next and want translations delivered via CDN without managing files, that is what Locize was built for. For a fuller field map, including what each platform is genuinely good at, see the best localization platforms for developer teams. Start your free trial â"},{"slug":"ai-quickstart-locize","title":"Localize Your App with AI in 5 Minutes","description":"A quickstart guide for developers using Cursor, Claude Code, or other AI coding assistants. Set up i18next with Locize and go from zero to deployed translations in one session.","date":"2026-04-07","category":"Guides","thumbnail":"\/img\/blog\/ai-quickstart-locize\/thumbnail.jpg","readTime":"3 min read","searchText":"title: 'Localize Your App with AI in 5 Minutes', description: 'A quickstart guide for developers using Cursor, Claude Code, or other AI coding assistants. Set up i18next with Locize and go from zero to deployed translations in one session.', date: '2026 04 07', thumbnail: '\/img\/blog\/ai quickstart locize\/thumbnail.jpg', image: '\/img\/blog\/ai quickstart locize\/title.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'ai', 'mcp', 'cursor', 'claude'] If you're building with an AI coding assistant (Cursor, Claude Code, GitHub Copilot, or similar), you can set up a complete localization workflow in minutes. This guide shows the shortest path from zero to live translations using i18next and Locize. The key insight: Locize is the backend your AI assistant writes translations to. Your AI generates the translations. Locize versions them, delivers them via CDN, and gives your team a UI to review and refine. Step 1: Connect your AI assistant to Locize (2 minutes) The Locize MCP server lets your AI assistant manage translations directly. Claude Code: Then run and complete the OAuth flow. Cursor \/ VS Code \/ Claude Desktop: Add as an MCP server in your client's settings and complete the OAuth flow. Once connected, your AI assistant can read translations, report new keys, publish versions, and manage branches, all from your development environment. Step 2: Ask your AI to set up i18next (1 minute) With the MCP server connected, prompt your AI assistant: \"Set up i18next with Locize for my React app. Use my Locize project [PROJECT ID]. Enable saveMissing so new keys are sent to Locize automatically.\" Your AI assistant will: 1. Install the packages ( , , ) 2. Configure i18next with your Locize project ID 3. Enable so new translation keys are reported automatically 4. Wrap your app with the i18next provider If you prefer to do this manually, here's the minimal setup: Step 3: Enable automatic translation in Locize (1 minute) In your Locize project: 1. Go to Project Settings EDITOR, TM\/MT\/AI, ORDERING 2. Enable Automatic Translation Workflow 3. Choose your translation provider (Locize AI works out of the box, or bring your own OpenAI\/Gemini\/Mistral key) Now every new key that arrives via will be auto translated into all your target languages. Step 4: Write code, translations happen automatically (1 minute) Use the hook in your components: When your app runs in development: 1. i18next detects the missing keys ( , ) 2. sends them to Locize with their default values 3. Locize auto translates them into all target languages 4. Your app fetches the translations from the Locize CDN No files to manage. No deploy needed for translation updates. Step 5: Use your AI assistant to manage translations With the MCP server connected, you can ask your AI assistant to: \"What's the translation coverage for my project?\" : checks completion across all languages \"Find all missing German translations in the common namespace\" : identifies gaps \"Report these new keys to Locize: [list of keys]\" : the AI agent equivalent of \"Publish the latest version\" : pushes translations to the CDN \"Create a translation branch for my feature auth branch\" : isolates translations for a feature This is the AI first workflow: your coding assistant manages the translation infrastructure while you focus on building features. What you get After these 5 minutes, you have: Automatic key discovery : new keys appear in Locize as you write code AI powered translation : every key is auto translated using your configured provider with glossary and styleguide context CDN delivery : translations are live in your app without deploying A review UI : translators can review and refine AI translations in the Locize editor AI assistant integration : manage translations from Cursor, Claude, or VS Code via MCP Next steps Add a styleguide to enforce tone, formality, and brand voice across all AI translations Set up the review workflow for languages where human review is important Configure branches to mirror your co
40de branching strategy Explore the InContext editor to let translators edit directly on your running app Why not just use AI directly? Your AI assistant is great at generating translations. But it can't version them, deliver them via CDN, coordinate reviewer feedback, manage branches, or keep your brand voice consistent across thousands of strings. Use AI for translation. Use Locize to manage it. Read more: Why not just use AI to translate? â"},{"slug":"i18next-support-notice","title":"Why We Added a Console Notice to i18next, and Why We Removed It","description":"An honest account of why we introduced a console.info support notice into i18next, what happened next, and what we learned from it.","date":"2026-03-28","category":"Open Source","thumbnail":"\/img\/blog\/i18next-support-notice\/thumbnail.jpg","readTime":"5 min read","searchText":"hideCta: true, title: 'Why We Added a Console Notice to i18next, and Why We Removed It', description: 'An honest account of why we introduced a console.info support notice into i18next, what happened next, and what we learned from it.', date: '2026 03 28', thumbnail: '\/img\/blog\/i18next support notice\/thumbnail.jpg', image: '\/img\/blog\/i18next support notice\/title.jpg', category: 'Open Source', tags: ['i18next', 'open source', 'sustainability', 'transparency', 'locize'] i18next turns 15 this year. It has almost 15 million weekly npm downloads , powers applications in every industry across the world, and is maintained by a small core team: the same people who founded Locize. This is the story of a decision we made, what it cost, and why we reversed it. The sustainability problem nobody talks about Open source maintainers are expected to deliver production grade software, respond to issues, fix security vulnerabilities, and keep pace with a fast moving ecosystem, for free. We've tried the standard approaches: GitHub Sponsors : the numbers were honest and we're grateful for every contributor, but they never came nearly close to funding even a minimal part of a single full time engineer. README badges and funding links : almost no one reads them. NPM funding metadata : same story. The reality is that i18next exists today because of Locize , our own managed localization product, built by the i18next core team to fund the library's continued development. Every security fix, every new feature, every improvement is made possible because Locize pays for the time to build it. The problem: most i18next users don't know this. They use the library, file issues, request features, and have no idea how it stays maintained. We're not complaining; that's the nature of open source. But it does create a real tension. What we decided to do In v25.8.0 , we introduced a single line that appeared when i18next initialized: The reasoning was straightforward. is a developer facing channel. It doesn't affect your end users, it doesn't break builds, it doesn't affect performance. And it reaches the one audience we actually wanted to reach: the developers who choose which tools their teams use. We provided an opt out via , and later added a kill switch for PaaS and third party dependency scenarios, and an (and later also a ) environment variable for CI\/CD pipelines. What happened next The developer community responded, loudly, and with legitimate concerns. The loudest complaints were about developer experience : the notice appearing multiple times in Next.js builds, flooding test logs, appearing inside design systems that consumers couldn't configure. We addressed most of these iteratively: improving the deduplication logic, adding the kill switch, documenting the suppression options properly. But the complaint that made us think hardest came from a PaaS provider who filed a detailed incident report. Their claim: the console notice may have caused Google Safe Browsing to block hundreds of customer sites . We investigated carefully. Our honest technical assessment is that output is not evaluated by Google Safe Browsing. GSB scans DOM content, not console output, and a link to in the console would have to affect our own platform and thousands of direct users if that were the mechanism. We still believe the actual cause was unrelated to the notice. But here's what we couldn't dismiss: the reporter had a real production incident, affecting real customers, and the only change they made (adding the kill switch at the infrastru
40cture level via a Cloudflare worker) correlated with the block being lifted. We can argue about causation. We cannot argue about the operational burden that placed on them. And we made a mistake in our response: we suggested a \"bad actor on a subdomain\" as the likely root cause. That was an assumption that didn't fit their specific setup (they don't host user generated content) and we shouldn't have made it. We apologized for that. What the data actually showed We tracked where new Locize registrations came from, based on an optional \"how did you hear about us?\" field at signup. Over approximately two months and 226 responses : Source Signups Share Google \/ Search 88 39% i18next ecosystem 46 20% Other \/ Noise 33 14.6% AI tools (ChatGPT, Gemini, etc.) 15 6.6% Console notice (explicit) 14 6.2% Word of mouth 11 4.8% GitHub \/ npm \/ docs 10 4.4% Blog posts 10 4.4% 14 people explicitly cited the console notice. The \"i18next ecosystem\" bucket likely includes more who saw it but described it differently. The notice drove some awareness. Not zero. Why we're removing it We're removing the notice in v26.0.0 . The sustainability argument hasn't changed: i18next exists because Locize exists, and that's still true. But the way we chose to communicate that created costs we didn't fully anticipate, and when we weighed those costs honestly, removing it was the right call. We're removing it because when we weigh the costs and benefits honestly, the math has changed: The production friction (PaaS providers, library authors, third party dependency scenarios) turned out to be more complex than we anticipated. The edge cases were real: CI pipelines, test logs, design systems, environments where suppression required infrastructure level intervention. The community cost (issues filed, trust eroded, developers who saw it as a betrayal of open source principles) was higher than we expected. The conversion impact was real, and we're not convinced it would grow faster than the community cost it was accumulating. v26.0.0 is a major release with several breaking changes and modernization work. Removing the notice cleanly (including the option, the mechanism, and the env var) fits naturally into that release. How you can actually support i18next If this post resonated with you, here's what actually helps: Try Locize. It's built by the i18next team, integrates deeply with the ecosystem, and there's also a free plan to get started. If it fits your workflow, it directly funds the library you're using. Tell your team or decision makers. If your company uses i18next in production, knowing that Locize funds its development is relevant information for anyone evaluating localization tooling. Mention it when it comes up. When someone asks about i18next in your community or on social media, it costs nothing to mention that Locize is how the library stays maintained. We're not going anywhere. i18next will keep improving. The team is the same, the commitment is the same, and the library remains fully free and MIT licensed. We just learned something about how to talk about that, and we're adjusting accordingly. â The i18next \/ Locize team"},{"slug":"mcp-server","title":"Locize MCP Server: Translate from Claude, Cursor & VS Code","description":"Connect Claude, Cursor, or VS Code to your Locize translations via MCP. Find missing keys, publish, manage branches, directly from AI chat.","date":"2026-03-25","category":"Product","thumbnail":"\/img\/blog\/mcp-server\/thumbnail.jpg","readTime":"4 min read","searchText":"title: 'Locize MCP Server: Translate from Claude, Cursor & VS Code', description: 'Connect Claude, Cursor, or VS Code to your Locize translations via MCP. Find missing keys, publish, manage branches, directly from AI chat.', date: '2026 03 25', thumbnail: '\/img\/blog\/mcp server\/thumbnail.jpg', image: '\/img\/blog\/mcp server\/title.jpg', category: 'Product', tags: ['localization', 'i18n', 'ai', 'mcp', 'claude', 'announcement', 'workflow'], faq: [ q: 'Which translation management systems offer an MCP server?', a: 'As of 2026, a small but growing set of TMS platforms expose Model Context Protocol (MCP) servers so AI assistants can read from and write to translation projects directly. Locize launched its MCP server in March 2026 at https:\/\/mcp.locize.app:
40it exposes 22 tools covering translation read\/write, publishing, branch management, and project structure. Smartling also offers an MCP server focused on enterprise localization workflows. Crowdin has announced MCP integration. Most other TMS platforms (Lokalise, Phrase, Transifex, Tolgee, SimpleLocalize) do not yet expose first party MCP servers. For developer focused workflows with i18next or any framework that benefits from agent driven translation management, Locize is the most developer native option in this set: built by the same Swiss team that created i18next, with OAuth and PAT auth, and a stateless HTTP transport.' , q: 'What is the Locize MCP server?', a: 'The Locize MCP server is an HTTP endpoint at https:\/\/mcp.locize.app that lets AI assistants (Claude Desktop, Claude Code, Cursor, VS Code, GitHub Copilot, and any other MCP compatible client) interact directly with Locize translation projects. It exposes 22 tools organized by workflow: Discovery (list projects, get project stats, list branches, list tenants), Content (get translations, find missing translations, report missing keys, update translations), Release (publish version, copy version, copy language, get job status), Branches (create branch, merge branch), and Structure (add language, remove language, add version, rename namespace, delete namespace, and more). Authentication is via OAuth 2.0 (automatic for Claude Desktop) or Personal Access Token (Bearer).' , q: 'How is the Locize MCP server different from Smartling\\'s MCP server or other translation MCP servers?', a: 'Locize\\'s MCP server is built around the i18next developer workflow: report missing keys is the MCP equivalent of i18next\\'s saveMissing. AI agents can push newly detected keys directly from a coding conversation, and if Automatic Translation is enabled, those keys are auto translated into every target language using the project\\'s configured AI\/MT provider with styleguide, glossary, and translation memory as context. Smartling\\'s MCP focuses more on enterprise localization tasks like text\/file translation through Smartling\\'s MT API. Crowdin\\'s MCP focuses on Crowdin specific project management. The Locize MCP also handles multi tenant and branch projects natively: find missing translations correctly accounts for tenant overrides and parent project fallbacks. For developer first teams already using or considering i18next, Locize\\'s MCP fits more naturally into the existing toolchain.' , q: 'Can I use the Locize MCP server with Claude Code, Cursor, or VS Code?', a: 'Yes. The setup is identical across MCP native clients: add https:\/\/mcp.locize.app as a custom connector (Claude Desktop) or via (Claude Code CLI). Cursor and VS Code use their standard MCP server settings. The first connection triggers OAuth 2.0 with Dynamic Client Registration: you sign in with your Locize account and a Personal Access Token is created automatically in your profile, which can be revoked at any time. For clients that only support stdio transport, the npm package mcp remote can bridge stdio to HTTP.' , q: 'Is the Locize MCP server free?', a: 'The MCP server itself is free to use and included for all Locize plans, including the 14 day full feature trial. There is no additional MCP specific licensing fee. Standard plan limits (downloads, words, languages, namespaces) apply to any traffic the MCP server generates against your project: for example, get published translations calls count against your CDN download quota the same way a direct CDN fetch would.' ] The Locize ecosystem already handles the mechanical parts of localization well. Keys get reported automatically via , the CLI instruments your codebase, and your CI pipeline publishes on deploy. That part is largely solved, if you're using those tools. For everyone building with AI coding agents, the Locize MCP server can do all of that for you too. Describe what you need in plain language and let the assistant handle it. And for both groups, there's a layer of conversational, exploratory work that no automation has addressed until now. Checking translation coverage before a release. Understanding which namespaces are lagging in which languages. Creating a branch for a feature, working through it, then merging it back. Renaming a namespace after a refactor. These tasks are quick to do but they pull you out of your current context (editor, terminal, or AI chat) and into a browser tab. The Locize MCP server brings that management layer into your AI assistant. Ask Claude to check coverage, publish a version, or create a branch. It handles it directly, without the tab switch. Connecting in 60 Seconds Claude Desktop \/ claude.ai 1. Go to Settings â Connectors â Add custom connector 2. Enter the URL: 3. Click Connect , your browser opens a Locize login screen 4. Sign in and grant the requested permissions That's it. A Personal Access Token is created automatically in your profile and can be revoked at any time. Claude Code (CLI) Then run in your session to complete the authorization. Cursor, VS Code, and other clients Add as a remote MCP server in your client's settings and follow the OAuth flow. What You Can Do Once connected, you talk to your translation projects in plain language. Here are some things that actually work today: Finding gaps before a release: \"Find all missing German translations in the checkout namespace of my main project.\" The assistant fetches the reference language and target language, compares them with full plural form awareness, and returns the exact keys that need attention, with their English values so you know
40what needs translating. Reporting new keys from a codebase conversation: \"I just added these three strings to the Settings page. Report them to Locize as missing keys in the latest version.\" The assistant calls , which only adds new keys and never overwrites existing translations, so it's safe to run at any point. Publishing as part of a deploy conversation: \"We're deploying v2.3 in 10 minutes. Publish the production version of my project.\" The assistant publishes the version and waits for the job to complete, reporting back when the CDN is updated. Branch workflows: \"Create a branch from the latest version for the checkout redesign feature, then merge it back when I'm done.\" Project management: \"Add Japanese to all versions of my project.\" \"Rename the 'payment' namespace to 'checkout' across all languages.\" \"What's the current translation coverage for each language in the production version?\" Available Tools The MCP server exposes 22 tools organized around the full translation workflow: Group Tools Discovery , , , Content , , , , Release , , , Branches , Structure , , , , , , Authentication and Access Control The MCP server supports two authentication methods. OAuth 2.0 is used automatically by Claude Desktop, Cursor, and other MCP native clients. When you connect, you log in with your existing Locize account and choose which permissions to grant. A Personal Access Token is created in your profile representing that authorization, and you can see exactly which client created it and revoke it with one click. Personal Access Tokens can also be used directly for CI\/CD pipelines, scripts, or any client that doesn't support OAuth. Create one in your profile under Personal Access Tokens and pass it as a Bearer token. PATs carry explicit scopes ( , , , ) so you can grant the minimum permissions needed for each use case. A Note on Multi tenant and Branch Projects The MCP server handles the full complexity of your Locize setup. For tenant and branch projects, translations are automatically merged with the parent project when reading, the same way the editor works. understands tenant overrides and correctly identifies what's genuinely missing versus what falls back to the parent. What's Next This is the first release. The 22 tools cover the workflows that matter most day to day. Based on usage we'll add more. Update (June 2026): we've since added four read only context tools , , , , and , so an agent can translate, review, and lint terminology right in your IDE. See Context tools: give your AI agent the glossary, style guide & memory. The full documentation is here, including alternative setup options and all tool descriptions. Try it. The setup really does take about 60 seconds."},{"slug":"next-i18next-v16","title":"next-i18next v16: App Router, Pages Router, and Everything In Between","description":"next-i18next v16 brings first-class App Router support with Server Components, Client Components, and edge-safe proxy, while keeping full Pages Router compatibility. One package, both routers, zero boilerplate.","date":"2026-03-23","category":"Tutorials","thumbnail":"\/img\/blog\/next-i18next-v16\/thumbnail.jpg","readTime":"8 min read","searchText":"title: 'next i18next v16: App Router, Pages Router, and Everything In Between', description: \"next i18next v16 brings first class App Router support with Server Components, Client Components, and edge safe proxy, while keeping full Pages Router compatibility. One package, both routers, zero boilerplate.\", date: '2026 03 23', thumbnail: '\/img\/blog\/next i18next v16\/thumbnail.jpg', image: '\/img\/blog\/next i18next v16\/title.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'i18next', 'nextjs'] When next i18next was first released, Next.js only had the Pages Router. The library became the go to way to add i18n to Next.js apps, wrapping with , calling in , and letting Next.js handle locale routing. (For the framework agnostic picture, see our JavaScript localization guide: same i18next core, different bindings.) Then Next.js introduced the App Router with Server Components, and our advice changed: \"You don't need next i18next anymore for App Router... just use i18next and react i18next directly.\" We even published a streamlined setup guide showing how to wire it all up manually. But honestly? That manual wiring was boilerplate. Every project needed the same middleware, the same helper, the same setup. And projects migrating from Pages Router to App Router, or running both routers side by side, had no clean path. next i18next v16 fixes all of that. What's New for Server Components: async, namespace aware, type safe for Client Components: reads language from URL params automatically for language detection and routing: edge safe, zero Node.js dependencies for client hydration: with lazy loading support for additional namespaces scoping: run both App Router and Pages Router in the same app No locale path mode : cookie based language without URL prefixes Internal locale mode (16.1+): clean URLs and static prerendering per locale, made for Cache Components Full Pages Router compatibility : and via Already using the manual i18next setup from our 2025 blog post? Migration is straightforward: replace your custom helpers with and , and your middleware with . App Router Setup 1. Install 2. Translation Files Place your translations in your project. The simplest approach uses a with dynamic imports: 3. Configuration Create : The uses dynamic imports to load translation files, they get bundled at build time and loaded on demand. If you prefer, you can also place files in and skip the (the default filesystem loader will pick them up). 4. Proxy (Language Detection & Routing) Create at your project root. Next.js 16 renamed the old convention to : The proxy handles: Language detection from cookie â Accept Language header â fallback Redirecting bare URLs to locale prefixed paths ( â ) Setting a custom header for Server Components to read the current language Still on Next.js 14 or 15? Use from in your : same API, just the old file convention. 5. Root Layout : A few things to note: stores the configuration, call it once at module scope serializes the loaded translations so the client can hydrate without re fetching creates a client side i18next instance hydrated with those resources 6. Server Components reads the language from the root param (Next.js 16.3+, next i18next 16.1+) or, as a fallback, from the proxy set header, loads the requested namespace if needed, and returns a namespace typed function plus the resolved . No prop drilling, no manual language passing. Reading a root param does not opt the route out of static prerendering, so is safe in prerendered routes; Route Handlers and Server Actions have no root params, so pass explicitly there. For : For the component in Server Components, use and pass both and : 7. Client Components reads the language from URL params ( or ) and keeps the i18next instance in sync. In no locale path mode (where there are no URL params), it uses the language set by . No Locale Path Mode Not every project wants and . Some prefer clean URLs with cookie based language: Routes live directly under (no segment). Language switching uses the hook: This sets the cookie, updates the i18next instance, and triggers a server re render, all in one call. Internal Locale Mode (Cache Components) Added in next i18next 16.1. No locale path mode has one catch: the language comes from \/ , and reading those makes a route dynamic. With Next.js Cache Components ( ) that is not just slower, it is an error outside a boundary. If you want clean URLs and static prerendering per locale, use : Routes stay under exactly like the default mode, so prerenders every locale. The proxy detects the language (cookie â Accept Language â fallback) and rewrites to internally: the public URL never shows a locale. Explicit locale paths like are served as is and never redirected (a redirect that sets the cookie would let prefetches flip the language), so keep your own links clean and switch languages with , just like in no locale path mode. The other half is how finds the language. Since 16.1 it reads the root param through (Next.js 16.3+) before falling back to the proxy header and cookie. A root param is part of the route key, so reading it does not opt the route out of prerendering: works as is in prerendered Server Components, with no threaded through every call site. One more thing for apps with many locales: the shared server instance preloads every supported language by default. Set to load each language on its first request instead, and pass to so the client only receives what it renders. Mixed Router: App Router + Pages Router Together This is where v16 really shines. Many real world projects have an existing Pages Router app and want to start building new features with the App Router, without rewriting everything. The option scopes the proxy to a specific URL prefix: The proxy only handles routes. Pages Router pages at continue using Next.js built in i18n routing with and from . Both routers share the same translation files from . Pages Router (Unchanged) If you're on the Pages Router and upgrading from v15, the only change is the import path: Everything else ( , , , custom backends) works exactly the same. Custom Backends next i18next supports any i18next backend plugin. When you provide a custom backend via the option, the default resource loader is skipped automatically. On the server side , custom backends work through the shared singleton instance, translations are fetched once and cached: On the client side , pass backends through . Since backend classes are functions (not serializable), import them in a component: This gives you server rendered translations at initial load, with client side lazy loading of additional namespaces through the chained backend. The i18next http backend example demonstrates this pattern with both App Router and Pages Router in a single project. Use next i18next 16.0.11 or later for this. is a Client Component, but the App Router also renders it on the server, once per request. Before 16.0.11 the backend was attached during that server pass as well, so every render built a throwaway Node side i18next instance. With a backend that refreshes on a timer that instance is never released: defaults to 1 hour whenever is undefined, so each render permanently added a background refresh and download volume grew steadily between deploys. From 16.0.11 backend plugins are applied only in the browser and the server pass renders from . A Note on Serverless Environments On the server, next i18next uses a module level singleton i18next instance. Translations are loaded once and reused across all subsequent requests within the same process: great for performance, and custom backends like or benef
40it from this since they don't re fetch on every request. However, in serverless environments (Vercel Serverless Functions, AWS Lambda, Google Cloud Functions, etc.), the module level cache only lives as long as the warm function instance. Each cold start re initializes the singleton and re fetches translations. For serverless deployments, we recommend one of these approaches: 1. Bundle translations at build time (recommended for most projects): Use with dynamic imports: translations are bundled into the deployment artifact at build time, so there's zero runtime fetching: 2. Download translations in CI\/CD: Download translations from your TMS before building (e.g., via locize cli or an API). This bundles them with your deployment and avoids runtime HTTP requests entirely. 3. Use HTTP backends with caching: If you must load translations at runtime, combine with and on the client side for fast subsequent loads. On the server side, the singleton cache will keep translations warm as long as the function instance is alive. Avoid relying on HTTP based backends as the sole translation source in serverless, each cold start adds latency and a potential point of failure. Bonus transform the localization process Connect to an awesome translation management system and manage your translations outside of your co
40de. Let's synchronize the translation files with Locize. This can be done on demand or on the CI server or before deploying the app. What to do to reach this step: 1. In Locize: signup at locize.app\/register and login 2. In Locize: create a new project 3. Install the locize cli ( ) or use the Locize commands built into i18next cli ( ) 4. In Locize: add all your additional languages (this can also be done via API or using the migrate command of the locize cli) Syncing translations With locize cli: Use to download the published Locize translations to your local repository before bundling your app. Or use to synchronize bidirectionally. With i18next cli: is a unified toolchain that goes beyond syncing: it also handles key extraction, type generation, locale synchronization, and linting. Its built in Locize integration wraps commands: If your Locize credentials are missing, it will guide you through an interactive setup. For projects that want to load translations directly from Locize at runtime, use i18next locize backend as a custom backend: On the server, the singleton instance caches translations, no re fetching per request. On the client, combine with and for offline first loading with automatic background refresh. Wrapping Up next i18next v16 is a single package that handles every Next.js i18n scenario: App Router with Server Components and Client Components Pages Router with the familiar \/ API Mixed setups where both routers coexist Custom backends for loading from CDN, API, or Locize Locale in path , no locale path and internal modes For the complete code, check out the examples on GitHub: App Router with locale in path App Router without locale in path Mixed App Router + Pages Router Pages Router With i18next http backend Happy coding!"},{"slug":"i18next-cli-instrument","title":"From Hardcoded Strings to Global-Ready: The Modern React i18n Journey","description":"Learn how to internationalize a modern React app in minutes using the new i18next-cli and Locize automation.","date":"2026-03-04","category":"Guides","thumbnail":"\/img\/blog\/i18next-cli-instrument\/thumbnail.jpg","readTime":"6 min read","searchText":"title: 'From Hardcoded Strings to Global Ready: The Modern React i18n Journey', description: 'Learn how to internationalize a modern React app in minutes using the new i18next cli and L
40ocize automation.', date: '2026 03 04', thumbnail: '\/img\/blog\/i18next cli instrument\/thumbnail.jpg', image: '\/img\/blog\/i18next cli instrument\/title.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'cli', 'workflow'] Internationalizing a React application used to mean a tedious weekend of hunting down every hardcoded string, manually wrapping each one in a call, injecting hooks into every component, and praying you didn't miss a corner case. The reality is that most apps ship without i18n simply because the upfront cost feels too high. The new command in changes that equation entirely. In this post, we'll take a React + Vite + TypeScript project ( Taskly ) from zero i18n to a cloud synced, multi language application in just a few steps. Update (June 2026): the steps below are now also available as a single command: chains instrument, extract, Locize setup, and AI auto translation in one run. See One command from hardcoded strings to a localized app. Step 1: Instrument: Let the CLI Do the Heavy Lifting Instead of manual search and replace, we run: If no exists, the CLI opens an interactive setup wizard first: Then the instrumentation begins. The tool performs a deep static analysis of your codebase and: Wraps hardcoded user facing strings in calls, generating a key from the content Injects hooks into React components that need them Adds where missing Falls back to with in non component files Generates a ready to use initialization file Automatically injects into your entry file ( ) Detects language switcher patterns and injects calls After the run you'll see a summary like: The generated is already wired up to load your translation files using lazy dynamic imports, and i.e. now imports it automatically: Step 2: The Human Touch: Manual Adjustments â ï¸ First Step Tool: The command uses heuristic based detection and is designed as a first pass to identify and suggest transformation candidates. It will not catch 100% of cases, and you should expect both false positives and false negatives. Always review the suggested transformations carefully before committing them to your codebase. Think of it as an intelligent code assistant, not an automated compiler. Static analysis is powerful, but some strings need a guiding hand. The CLI provides the comment to opt individual strings out of instrumentation. Brand names and UI chrome In for example, \"Taskly\" is a brand name that must never be translated: Dynamic labels mapped from data The navigation labels are stored in a array. The CLI instruments each literal independently, but the right approach is a single call keyed by . You can place comment hints to guide the CLI: The ignore comment keeps the literal in the array (needed at runtime as the fallback), while the comment hint registers the key for extraction. A quick manual edit connects the two. Language switcher: detected automatically The CLI detects patterns that change the application language and injects alongside them. In , the original only called : No manual change needed here. The CLI handled it. Step 3: Extract: Generate Your Translation Files With the code instrumented, now run: This parses every source file, collects all calls or component keys and their default values, and writes them into your locale files: Your now contains every key with its English default value: You now have a complete English baseline ready for the world. The other locale files have the same keys but empty values, ready to be translated. Bonus: TypeScript Definitions If you're using TypeScript, one extra command gives you fully typed translation keys, so typos in calls and components become compile errors: Run this after every and your editor will autocomplete translation keys and flag any that don't exist. Step 4: Migrate: Push to Locize At this point, you have a fully extracted English baseline. You could manually share these JSON files with translators, wait for them to finish, and try to merge their changes back into your codebase. But dealing with new keys, deleted keys, and merge conflicts quickly becomes a maintainability nightmare. Instead, it's time to streamline the process and move your localization workflow to the cloud. Add your Locize credentials to (you can also use environment variables or just follow the interactive prompt): Then push everything to Locize in one command: If necessary, the CLI prompts for your credentials on the first run, offers to
40save them securely, then migrates all locale files: ð¡ Automatic Translation: If you have Locize's Machine \/ AI Translation feature enabled, your target languages will be translated automatically after migration, asynchronously. Pro Tip: In case the translated files are not ready yet, wait a moment after migrating and run to pull those new translations back into your local project. Step 5: Iterate: Adding New Keys Development doesn't stop after the initial migration. When you add a new feature: Just run two commands: The new key appears in immediately after , and after all other languages will have it translated (instantly if Auto Translation is on, or pending your translators' review). Command reference Command When to use After every code change, keeps local JSON in sync with your source After , generates TypeScript definitions for type safe translation keys Once, for the initial bulk push of local resources to Locize Ongoing two way sync between local files and Locize Pull the latest translations from Locize without pushing changes Step 6: Going Further: Dynamic Translation Loading Bundling JSON files works well, but lets you decouple your translations entirely from your deployment cycle. Benefits: No re deploys for copy changes. Fix a typo in the Locize editor and it appears in your live app at the next page load. No build, no deploy. Smaller bundles. Only the user's language is fetched, on demand. Phased rollouts. Use Locize versioning to promote translations independently of code versions. Step 7: Power Features: and the InContext Editor : Zero friction key registration During development, enable to automatically push newly written keys to Locize the moment they appear in the running app. No step needed: This pairs beautifully with Locize AI: as soon as a new key arrives, Locize translates it into every configured language automatically. InContext Editor: Edit translations in place Add the Locize InContext Editor to your development build for a visual, in page translation workflow. Click any string, edit it directly in the browser, and save it back to Locize without ever leaving the app. also flags keys in your Locize dashboard that haven't been used recently, making it easy to clean up stale translations alongside your code. The Full Journey at a Glance We went from a standard React app with 100+ hardcoded strings to a fully instrumented, cloud synced, multi language application in minutes, not a weekend. Summary: The Workflow Phase Commands Setup â â Daily Dev â Live Updates Use for instant publishing By leveraging the , we've turned what used to be a grueling manual task into a streamlined, automated pipeline. Want to see if your project is ready? Run: It gives you an instant overview of your current i18n health. Example app: github.com\/locize\/taskly i18next cli: github.com\/i18next\/i18next cli Locize: locize.com Video: Youtube"},{"slug":"new-pricing-plans","title":"Predictable Growth: Introducing Fixed Pricing and a Free Plan","description":"Weâre evolving our pricing to give you the best of both worlds: the predictability of fixed monthly plans and the flexibility of usage-based scaling. Plus, a new way to start for free.","date":"2026-02-21","category":"Product","thumbnail":"\/img\/blog\/new-pricing-plans\/thumbnail.jpg","readTime":"3 min read","searchText":"title: 'Predictable Growth: Introducing Fixed Pricing and a Free Plan', description: 'Weâre evolving our pricing to give you the best of both worlds: the predictability of fixed monthly plans and the flexibility of usage based scaling. Plus, a new way to start for free.', date: '2026 02 21', thumbnail: '\/img\/blog\/new pricing plans\/thumbnail.jpg', image: '\/img\/blog\/new pricing plans\/title.jpg', category: 'Product', tags: ['pricing', 'localization', 'transparency', 'announcement'] Update: the Usage Based plan described below is no longer available for new subscriptions. Pricing is still usage based, just stepped: every plan includes a generous volume and extra capacity comes in blocks (10k words at a time, for example), with auto adapt to add them for you. Projects already on the Usage Based plan keep it. See the current pricing. Since our inception, Locize has been known for its radical \"pay as you go\" approach. While that model offers the ultimate flexibility, we heard one piece of feedback from growing teams: \"We need more predictability in our monthly billing.\" Today, we are introducing a major evolution to how you can use Locize. We are moving from a single \"one size fits all usage\" model to a choice between Fixed Plans and Usage Based Pricing . And for the first time ever, we are introducing a Free plan . Why the Change? Localization shouldn't be a budgeting guessing game. By offering the possibility of fixed plans, weâre providing: 1. Budget Predictability: Know exactly what your base cost is every month. 2. Simplified Features: No more wondering which \"add on\" you need; features are now bundled into logical tiers. 3. The Same Flexibility: We haven't abandoned our roots. If you exceed your plan limits, you don't get cut off: you simply scale into fair, graduated overages. And alternatively, you can still use the Usage Based plan. Meet the New Plans Weâve structured these tiers to match the lifecycle of a modern software project: Starter: Designed for small teams. Includes 15,000 words and 1,000,000 downloads . Growth: Our most popular choice for growing businesses. Includes 60,000 words and 5,000,000 downloads . Professional: Includes unlimited users , 100,000 words , and 7,000,000 downloads to keep your pipeline moving. Enterprise: For large scale operations requiring high volume limits ( 200k words\/15M downloads ), advanced security like SSO, and Audit Logs. New Locize Pricing Tiers Graduated Overages: No \"Cliffs\" One thing that makes Locize unique is how
40we handle growth. On our Fixed plans, if your project suddenly goes viral and your downloads spike, we don't force you onto a more expensive tier immediately. Instead, we use graduated overages . As your usage grows, the unit rate actually decreases , ensuring that scaling up remains cost effective rather than a punishment for success. Introducing: The Free Plan Until now, the only way to start with Locize was our 14 day trial. While that gave you time to explore, it wasn't ideal for hobbyists or developers just starting a small project. Our new Free Plan changes that. It's designed for small scale projects that need professional grade i18n without the immediate cost: 2,000 Words & 100,000 Downloads included. 1 User & 2 Languages . It's the perfect way to get your project translated and live without watching a trial countdown clock. Fixed vs. Usage Based: Which is for you? We know that every team works differently. That's why we're giving you the choice: Choose a Fixed Plan if: You prefer setting a budget ceiling up front. You need specific feature bundles included in a flat fee. You are a team looking for a predictable monthly invoice. Choose Usage Based if: Your usage varies significantly month to month (e.g., seasonal traffic). You want costs to automatically scale down during quiet development periods. You need unlimited languages or users from day one without jumping tiers. Plan Decision Helper Radical Trans
40parency (Still No Sales Reps) As we mentioned in our Back to Roots post, we believe technical tools should be easy to understand without a sales pitch. Our new pricing page let's you chose if you prefer a Fixed Plan or a Usage Based Plan. We don't have sales reps because we believe our product, and our pricing, should speak for itself. What happens to existing customers? If you are currently on our legacy usage based model, don't worry. You can continue your current plan, or switch to a new fixed plan at any time via your project settings to take advantage of the new bundled features. Explore the new pricing page and find the plan that fits your workflow."},{"slug":"building-robust-offline-first-apps-with-i18next","title":"Building Robust Offline-First Apps with i18next","description":"Learn how to ensure your application translations remain available even in tunnels, elevators, or restricted networks. This guide explores using i18next chained backend to combine the agility of the Locize CDN with the reliability of local caching and bundled fallbacks.","date":"2026-02-09","category":"Guides","thumbnail":"\/img\/blog\/building-robust-offline-first-apps-with-i18next\/thumbnail.jpg","readTime":"3 min read","searchText":"title: 'Building Robust Offline First Apps with i18next', description: 'Learn how to ensure your application translations remain available even in tunnels, elevators, or restricted networks. This guide explores using i18next chained backend to combine the agility of the Locize CDN with the reliability of local caching and bundled fallbacks.', date: '2026 02 09', thumbnail: '\/img\/blog\/building robust offline first apps with i18next\/thumbnail.jpg', image: '\/img\/blog\/building robust offline first apps with i18next\/title.jpg', category: 'Guides', tags: ['localization', 'i18n', 'tutorials', 'i18next', 'cdn'] In the modern web and mobile landscape, we often build applications under the assumption of perfect connectivity. We assume the API is always reachable, the assets will always load, and the user is always online. But the reality is different: trains go into tunnels, mobile signals drop in elevators, and corporate firewalls block \"non essential\" traffic. For a truly resilient user experience, adoption of an Offline First architecture is essential. This means your application should work as well (or as well as possible) without a network connection as it does with one. But how does this apply to internationalization (i18n)? If your translations are hosted on a CDN or own backend to allow for instant updates, what happens when the user loses connection? The Challenge: Dynamic vs. Static Using a CDN for translations is powerful. It allows you to fix typos, update content, or add new languages without redeploying your entire application. However, relying solely on a network request for text content introduces a single point of failure. If the CDN is unreachable, your users might see translation keys (e.g., ) instead of text. To solve this, we need a strategy that offers the best of both worlds: 1. Up to date translations from the CDN when online. 2. Guaranteed availability from a local cache or bundle when offline. The Solution: i18next Chained Backend If you are using i18next , the architecture for this is already solved via the plugin. This plugin allows you to define a \"waterfall\" of backends. i18next will attempt to load translations from the first backend; if that fails (or if the cache is missing), it falls back to the next one in the chain. Here is how to implement this pattern across different environments. 1. Browser: Caching with LocalStorage For web applications, is an excellent place to cache translation JSON files. This reduces network requests on subsequent visits and allows the app to load text immediately, even if the user is offline. You can combine (primary) with (cache). In this setup, i18next checks LocalStorage first. If the translations are found and valid (not expired), it uses them instantly. If not, it fetches them from Locize and updates the cache. 2. Mobile: React Native and AsyncStorage Mobile apps are the most frequent victims of fluctuating network conditions. For React Native, the logic is identical, but we swap the storage engine for . 3. The Ultimate Safety Net: Bundled Fallback What if the user opens the app for the very first time and they are already offline? The cache is empty, and the CDN is unreachable. To cover this \"Day 0\" offline scenario, you can bundle a snapshot of your translations directly into the application build using . This creates a robust three layer strategy: 1. Locize CDN : Checks for the absolute latest version. 2. Local Cache : Used if CDN is unreachable or for performance. 3. Bundled Resources : Used if everything else fails. A Note on \"Stale\" Data When using a chained backend strategy, be cautious with features like (which uploads missing keys to Locize) or . Since your app might be reading from an old cache or an outdated bundle, triggering updates based on this stale data can lead to inconsistencies. It is generally recommended to disable these features when using multiple backends. Summary You do not have to choose between the agility of a CDN and the reliability of local files. By using Locize as your source of truth and i18next's chained backend to handle caching and fallback, you ensure your application remains useful in highly regulated networks, tunnels, and flights. Ready to make your app offline capable? Check out the backend fallback documentation for deep dives into specific configurations for Node.js, Next.js, and more."},{"slug":"diy-localization-trap-ai-json","title":"The DIY Localization Trap: Why AI and JSON are Not a Strategy","description":"Thinking of building your own localization autopilot or self-hosting? Discover the hidden engineering costs of DIY localization and why AI-only workflows fail at scale.","date":"2026-01-26","category":"Engineering","thumbnail":"\/img\/blog\/diy-localization-trap-ai-json\/thumbn
40ail.jpg","readTime":"3 min read","searchText":"title: 'The DIY Localization Trap: Why AI and JSON are Not a Strategy', description: 'Thinking of building your own localization autopilot or self hosting? Discover the hidden engineering costs of DIY localization and why AI only workflows fail at scale.', date: '2026 01 26', thumbnail: '\/img\/blog\/diy localization trap ai json\/thumbnail.jpg', image: '\/img\/blog\/diy localization trap ai json\/title.jpg', category: 'Engineering', tags: ['localization', 'ai', 'i18n', 'devops', 'roi'] In the era of LLMs, itâs tempting to think that localization is a solved problem. The logic seems simple: âIâll just send my JSON files to an AI, script the merge, and Iâm done. Why do I need a platform?â We see teams try this every day. Some of them leave Locize to build their own \"autopilot\" or move to self hosted \"free\" tools. But there is a hidden cost to \"free\" and \"DIY\" that only reveals itself when your project actually starts to succeed. 1. The Maintenance Tax (Self Hosting) When you choose a self hosted tool like Tolgee, you aren't just choosing a tool; you are choosing a new job. Who manages the database scaling? Who ensures the CDN is globally redundant? Who handles the security patches and version updates? Self hosting is only \"free\" if your developersâ time is worth $0. Every hour a senior dev spends fixing a localization database is an hour they aren't building your product. Locize is a managed infrastructure we handle the \"boring stuff\" so you can stay in your IDE. 2. The Context Collapse (AI only) AI is a powerful translator, but a terrible librarian. If you send a raw JSON file to ChatGPT, it doesn't know if \"Drive\" is a verb (Drive the car), a noun (The hard drive), or a location (Memory drive). Without a TMS like Locize providing context, screenshots, and glossaries , your AI translations will eventually \"hallucinate\" or drift in tone. Locize provides the governance that AI lacks. We don't just translate; we try our best so the AI obeys your brand's rules. 3. The Deployment Friction Localization is a workflow problem, not a language problem. If your team is still committing translations to Git, you are slowing down your release cycle. Manual PRs: For every typo fix, a developer has to review a PR? Syncing Issues: What happens when two translators edit the same file simultaneously? Locize automates these workflows. In the last month alone, our average customer automated hundreds of engineering tasks that would have otherwise required a manual code commit and deployment. 4. The \"Finished Project\" Fallacy Many users think, \"My project is done, I don't need Locize anymore.\" Localization is never \"done.\" A month later, you add a \"Forgot Password\" link, and the cycle starts over. This is why we built the Pause Feature . Instead of deleting your history and breaking your workflow, you can hibernate your project with an 80% discount . Keep your your data safe, without paying for \"active\" management features you don't need right now. The Bottom Line \"DIY\" and \"AI only\" setups work for a weekend project. But for a professional product, they are technical debt waiting to happen. We built Locize to be the invisible infrastructure for i18next and modern web apps. We provide the stability, the audit trails, and the delivery network that a script simply cannot replicate."},{"slug":"back-to-roots-locize-website","title":"Back to Our Roots: The All-New locize.com","description":"Locize has a new look. Weâre going back to our roots with a faster, cleaner, and more transparent experience, built by developers, for developers.","date":"2026-01-19","category":"Product","thumbnail":"\/img\/blog\/back-to-roots-locize-website\/thumbnail.jpg","readTime":"2 min read","searchText":"title: 'Back to Our Roots: The All New locize.com', description: 'Locize has a new look. Weâre going back to our roots with a faster, cleaner, and more transparent experience, built by developers, for developers.', date: '2026 01 19', thumbnail: '\/img\/blog\/back to roots locize website\/thumbnail.jpg', image: '\/img\/blog\/back to roots locize website\/title.jpg', category: 'Product', tags: ['localization', 'product', 'cat tools'] Weâve been relatively quiet lately, but for a good reason. We werenât just redesigning a website; we were rethinking how we present the tool weâve built for you. We are launching the new locize.com website. If youâve been with us since the beginning, this update might feel familiar. Weâve stripped away the \"marketing fluff\" and returned to the core philosophy of our very first site: content first, developer focused, and radically transparent. Less Noise, More Clarity In the world of SaaS, itâs easy to get lost in buzzwords. We decided to go the other way. The new website is more elegant and significantly easier to read, focusing on the information you actually need to get your job done. But itâs not just a visual change. Weâve rebuilt the engine under the hood to make the entire experience faster and more intuitive. A World Class Documentation Experience Documentation is important for us. Weâve overhauled the Docs from the ground up: Lightning Fast Search: Find the exact API call or configuration setting instantly. Enhanced Readability: A cleaner layout that stays out of your way while you code. Better Blog Experience: Our blog and tutorials now feature a refined reading style and a powerful new search to help you find localization best practices in seconds. A Modern App for a Modern Workflow The new screenshots you see across the new site aren't just \"marketing assets\": they are a reflection of the major UI and UX improvements weâve made to the Locize App itself. Weâve updated the design of the platform to be more modern, faster, and easier to navigate. Whether you are managing complex multi namespace architectures or a single small project, the interface is now more responsive and streamlined. What you see on the website is what you get in the tool: Modernized UI: A cleaner, high contrast interface. Speed Improvements: Faster loading and save times. Refined UX: Fewer clicks to get to your most important tasks. New Power Features: We've integrated automated backups, simplified AI translation, advanced charts, and more user roles. Why We Changed We believe that a localization platform should be an invisible, high performance part of your tech stack. It shouldn't require a sales deck to understand. By going back to our roots, we are doubling down on what made Locize the industry standard for i18next and modern localization: technical excellence without the overhead. Reflecting on our journey, having created the foundation with i18next, it has been a long road to what Locize is today. We want this journey to continue with you. Explore the new site, search the docs, and log in to the app to feel the difference."},{"slug":"react-i18next","title":"React Localization - Internationalize with i18next","description":"The complete guide to React localization with react-i18next: setup, the useTranslation hook, the Trans component for JSX, plurals, lazy-loaded namespaces, and SSR.","date":"2025-12-23","category":"Tutorials","thumbnail":"\/img\/blog\/react-i18next\/react-localization.jpg","readTime":"10 min read","searchText":"title: 'React Localization Internationalize with i18next', description: 'The complete guide to React localization with react i18next: setup, the useTranslation hook, the Trans component for JSX, plurals, lazy loaded namespaces, and SSR.', date: '2025 12 23', thumbnail: '\/img\/blog\/react i18next\/react localization.jpg', image: '\/img\/blog\/react i18next\/react localization.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'i18next', 'react'] Overcoming the language barr
40ier for users who use your software is an important topic. English is no longer the universal language of the internet. As of March 2020, only 25.9% of internet users were English speakers. The chances are high that your users will skip past your website if non localized. Therefore, without a multilingual website you might miss out on a large share of potential users. In the JavaScript ecosystem, there are a lot of internationalization frameworks. Here you can find some details about some JavaScript internationalization frameworks. If you want to compare framework setups side by side, see our JavaScript localization guide. In this article, we will be using the i18next framework to internationalize a React app. This step by step guide is for you if you're looking for a way to create an internationalized React app (with or without Create React App). This post was originally published in 2021 and updated on December 23, 2025 to reflect changes in the i18next and React ecosystem. TOC So first of all: \"Why i18next?\" What's new (since 2021)? Let's get into it... Prerequisites Getting started Language Switcher How to get the current language? Interpolation and Pluralization Formatting Context Separate translations from code Multiple namespaces Better translation management For sure! How does this look like? save missing translations ð but there's more... ð¦ Let's prepare for production ð ð𥳠Congratulations ðð Streamline your i18next setup process with this step by step guide. Get your localization framework up and running in no time and ensure smooth language transitions for your users. Follow the instructions and avoid any setup complications for your next international project. So first of all: \"Why i18next?\" When it comes to React localization, one of the most popular is i18next with its react extension react i18next, and for good reasons: i18next was created in late 2011. It's older than most of the libraries you will use nowadays, including your main frontend technology (React, Angular, Vue, ...). â¡ï¸ sustainable Based on how long i18next already is available open source, there is no real i18n case that could not be solved with i18next. â¡ï¸ mature i18next can be used in any javascript (and a few non javascript .net, elm, iOS, android, ruby, ...) environment, with any UI framework, with any i18n format, ... the possibilities are endless. â¡ï¸ extensible There is a plenty of features and possibilities you'll get with i18next compared to other regular i18n frameworks. â¡ï¸ rich Here you can find more information about why i18next is special and how it works. What's new (since 2021)? In 2025, i18next introduced a powerful new feature: the typescript selector API. This brings typesafe access to your translations and enables strong autocomplete support. You can learn more about it in How to translate with i18next: typescript and Typesafe i18next with the new typescript selector API. In 2024, i18next introduced a new plugin to help you integrate i18next into Express apps: i18next http middleware. If you're working with React in an Express environment, this can be a useful addition. Need professional translation management? See How to translate with i18next: the CLI for a streamlined workflow. Interested in a continuous localization workflow? Check out continuous localization. Let's get into it (react i18next) ... Prerequisites Make sure you have Node.js and npm installed. It's best, if you have some experience with simple HTML, JavaScript and basic React.js, before jumping to react i18next the powerful React i18n framework. This react i18next localization example is not intended to be a React beginner tutorial. Getting started Take your own React project or create a new one, i.e. with create react app. learn react logo We are going to adapt the app to detect the language according to the userâs preference. And we will create a language switcher to make the content change between different languages. Let's install some i18next dependencies: i18next react i18next i18next browser languagedetector Let's prepare an file: Let's import that file somewhere in our file: For React = 18.0.0 use: For older React versions use: Now let's try to move some hard coded text out to the translations. We have used the Trans component for the first text and the useTranslation hook for the second text: There is some more effort necessary if you wish to use High Order Components (HOC). Another option in this situation is to use withTranslation HOC. The texts are now part of the translation resources: Language Switcher Now let's define a language switcher: And also add some translations for the new language: react language switcher 𥳠Awesome, you've just created your first language switcher! Thanks to i18next browser languagedetector now it tries to detect the browser language and automatically use that language if you've provided the translations for it. The manually selected language in the language switcher is persisted in the localStorage, next time you visit the page, that language is used as preferred language. How to get the current language? Since i18next v21 there is . It is set to the current resolved language and it can be used as primary used language, for example in a language switcher. If your detected language for example is and you provided translations only for (fallbackLng) instead will return . i18next.language vs. i18next.languages vs. i18next.resolvedLanguage Interpolation and Pluralization i18next goes beyond just providing the standard i18n features. But for sure it's able to handle plurals and interpolation. Let's count each time the language gets changed: ...and extending the translation resources: Based on the count value i18next will choose the correct plural form. Read more about pluralization and interpolation in the official i18next documentation. react pluralization ð¡ i18next is also able to handle languages with multiple plural forms, like arabic: Why are my plural keys not working? Are you seeing this warning in the development console ( )? i18next::pluralResolver: Your environment seems not to be Intl API compatible, use an Intl.PluralRules polyfill. Will fallback to the compatibilityJSON v3 format handling. With v21 i18next streamlined the suffix with the one used in the Intl API. In environments where the Intl.PluralRules API is not available (like older Android devices), you may
40need to polyfill the Intl.PluralRules API. In case it is not available it will fallback to the i18next JSON format v3 plural handling. And if your json is already using the new suffixes, your plural keys will probably not be shown. tldr; Formatting Starting with i18next v21.3.0, built in formatters are available for formatting numbers, dates, lists, and more using the Intl API. For details and advanced usage, see the official i18next formatting documentation. Now, letâs check out how we can use different date formats with the help of i18next and Luxon to handle date and time. You can pass options as a semicolon delimited list. JavaScript usage: You can override the language by passing or in the options: Adding custom format functions: Add your custom format function after the i18next.init() call. Built in formats: Number: Currency: DateTime: RelativeTime: List: See the i18next formatting documentation for more examples and options. Now, letâs check out how we can use different date formats with the help of i18next and Luxon to handle date and time. We like to have a footer displaying the current date: Now Luxon and define a format function (as documented in the formatting docs), then add the new translation key: ð Cool, now we have a language specific date formatting! English: react english German: react german Context What about a specific greeting message based on the current day time? i.e. morning, evening, etc. This is possible thanks to the context feature of i18next. Let's create a function and use the result as context information for our footer translation: And add some context specific translations keys: ð Yeah, It works! react translations Separate translations from code Having the translations in our file works, but is not that suitable to work with, for translators. Let's separate the translations from the code and pleace them in dedicated json files. Because this is a web application, i18next http backend will help us to do so. Move the translations to the public folder: public locales Adapt the file to use the : Now the translations are loaded asynchronously, so make sure you wrap your app with a Suspense component to prevent this error: Now your app looks still the same, but your translations are separated. If you want to support a new language, you just create a new folder and a new translation json file. This gives you the possibility to send the translations to some translators. Or if you're working with a translation management system you can just synchronize the files with a cli. ð§âð» The code of this first part can be found here. Multiple namespaces ð¡ btw: you can also have multiple translation files thanks to the namespaces feature of i18next One of the advantages of react i18next is based on i18next, it supports the separation of translations into multiple files which are called namespaces in i18next. In order to use multiple namespaces\/translation files, you need to specify it when calling : : or : Better translation management By sending the translations to some translators or translator agency you have more control and a direct contact with them. But this also means more work for you. This is a traditional way. But be aware sending files around creates always an overhead. Does a better option exist? For sure! i18next helps to get the application translated, and this is great but there is more to it. How do you integrate any translation services \/ agency? How do you keep track of new or removed content? How do you handle proper versioning? How do you deploy translation changes without deploying your complete application? and a lot more... Looking for something like thisâ Easy to integrate Continuous deployment? Continuous localization! Manage the translation files with ease Order professional translations Analytics & Statistics Profit from our content delivery network (CDN) Versioning of your translations Automatic and On Demand Machine Translation Riskfree: Take your data with you Transparent and fair pricing and a lot more... transform the localization process How does this look like? First you need to signup at Locize and login. Then create a new project in Locize and add your translations. You can add your translations either by using the cli or by importing the individual json files or via API. Done so, we're going to replace i18next http backend with i18next locize backend. After having imported the translations to Locize, delete the locales folder: public locales removed Adapt the file to use the and make sure you copy the project id and api key from within your Locize project: i18next locize backend offers a functionality to retrieve the available languages directly from Locize, let's use it: save missing translations Thanks to the use of the saveMissing functionality, new keys gets added to Locize automatically, while developing the app. Just pass in the i18next options: Each time you'll use a new key, it will be sent to Locize, i.e.: will result in Locize like this: missing key ð but there's more... Thanks to the locize lastused plugin, you'll be able to find and filter in Locize which keys are used or not used anymore. With the help of the Locize plugin, you'll be able to use your app within the Locize InContext Editor. Lastly, with the help of the auto machinetranslation workflow and the use of the saveMissing functionality, new keys not only gets added to Locize automatically, while developing the app, but are also automatically translated into the target languages using machine translation. Check out this video to see how the automatic machine translation workflow looks like! https:\/\/youtu.be\/VfxBpSXarlU use them in : Automatic machine translation: missing key auto Last used translations filter: i18next last used InContext Editor: i18next incontext ð¦ Let's prepare for production ð Now, we prepare the app for going to production. First in Locize, create a dedicated version for production. Do not enable auto publish for that version but publish manually or via API or via CLI. Lastly, enable Cache Control max ageâ for that production version. Let's making use of the environment feature of react scripts. Lets' create a default environment file and one for development and one for production: : : : Now let's adapt the file: Now, during development, you'll continue to save missing keys and to make use of lastused feature. = And in production environment, saveMissing and lastused are disabled, and also the api key is not exposed. = Caching: i18next caching Merging versions: overwrite version ð§âð» The complete code for this React example can be found here. And a TypeScript version here. Check also the code integration part in this YouTube video. There's also an i18next crash course video. There is also a Spanish translation of this blog post. ð𥳠Congratulations ðð I hope youâve learned a few new things about i18next, React.js localization and modern localization workflows. So if you want to take your i18n topic to the next level, it's worth trying the localization management platform Locize. The founders of Locize are also the creators of i18next. So by using Locize you directly support the future of i18next. ð"},{"slug":"tms","title":"What is a Translation Management System (TMS)?","description":"A Translation Management System (TMS) is software that centralizes translation work: managing files, terminology, translation memory, automation, and integrations. This guide covers what a TMS does, when you need one, and how to compare options.","date":"2025-12-16","category":"Guides","thumbnail":"\/img\/blog\/tms\/translation-management-system.webp","readTime":"9 min read","searchText":"hideCta: true, title: 'What is a Translation Management System (TMS)?', description: 'A Translation Management System (TMS) is software that centralizes translation work: managing files, terminology, translation memory, automation, and integrations. This guide covers what a TMS does, when you need one, and how to compare options.', date: '2025 12 16', thumbnail: '\/img\/blog\/tms\/translation management system.webp', image: '\/img\/blog\/tms\/translation management system.webp', category: 'Guides', tags: ['localization', 'guides', 'tms', 'basics'], faq: [ q: 'What is a translation management system (TMS)?', a: 'A translation management system (TMS) is software that centralizes the work of translating and localizing content. It handles file flows between source content and translators, stores translation memory and terminology, automates assignment and review, and integrates with developer tooling (CI\/CD, CMS, code repositories). The goal is to replace ad hoc spreadsheets and email driven handoffs with a continuous, repeatable process.' , q: 'What does a TMS do?', a: 'Core functions: (1) workflow management (defining what to translate, sending files, tracking progress, reviewing, delivering); (2) translation memory (reusing previously translated segments to save effort and keep wording consistent); (3) terminology management (enforcing glossaries and style guides); (4) reporting and metrics (visibility into progress, cost, and quality); (5) automation (machine translation, AI assistance, auto routing); (6) integrations (APIs, webhooks, CDN delivery, Git\/CI hooks).' , q: 'What is the difference between a TMS and a CAT tool?', a: 'A CAT (computer aided translation) tool is the editor a single translator uses; it shows source and target side by side, surfaces translation memory matches, runs QA checks. A TMS is the surrounding platform: it handles assignment, workflow, terminology across teams, integrations with developer tooling, and delivery. Modern TMS platforms (including Locize) bundle a CAT view with the workflow layer, so translators do not need a separate desktop tool.' , q: 'What is translation memory?', a: 'Translation memory (TM) is a database of previously translated source \/ target pairs. When a translator works on new content, the TMS searches the TM for matches (exact or fuzzy) and surfaces them as suggestions. This both speeds up translation (already translated segments reuse) and improves consistency (the same source text gets the same translation every time).' , q: 'When do I need a TMS?', a: 'A TMS becomes essential when spreadsheets and email handoffs no longer scale. Common triggers: (1) more than 2 3 target languages, (2) more than one translator working in parallel,
40(3) frequent product updates that require continuous translation rather than batch projects, (4) consistency requirements (brand voice, regulated terminology), or (5) integration into developer workflows (CI\/CD, GitHub, CMS).' , q: 'How do I compare translation management systems?', a: 'Beyond features, compare on five practical axes: (1) integration with your stack (does it support your i18n format and your build pipeline?), (2) pricing model (per seat, per word, per MAU, or usage based, since the model affects scaling cost more than the headline price), (3) translation delivery (CDN, API, file export), (4) workflow flexibility (review, branches, multi tenant), (5) data ownership and export (can you take your translations with you if you switch?).' , q: 'Do I have to use professional translators with a TMS?', a: 'No. Modern TMS platforms support multiple translation sources: machine translation (DeepL, Google, OpenAI, Anthropic), in house translators, freelance translators, professional agencies, or any combination. The TMS routes work to whichever source you configure, and a review workflow lets you mix automated first drafts with human review for accuracy and brand voice.' ] A Translation Management System (TMS) is software that centralizes the work of translating and localizing content: managing files, terminology, translation memory, automation, and integrations with developer tooling. It replaces ad hoc spreadsheets and email based handoffs with a continuous, repeatable workflow. A modern TMS handles assignment to translators, tracks progress, enforces glossaries and style guides, reuses previously translated content, integrates with CI\/CD and CMS systems, and delivers translations to production via CDN or API. For teams localizing into more than two or three languages, or shipping product updates frequently, a TMS is the difference between localization that keeps pace and localization that is permanently behind. Key facts What it is: software that centralizes translation work: files, workflow, memory, terminology, delivery Core functions: workflow management, translation memory, glossary \/ style guide, reporting, AI \/ MT, integrations (API, CDN, Git, CMS) vs CAT tool: CAT = single translator editor; TMS = team workflow + integrations + delivery (modern TMS bundles a CAT view) Translation memory: database of past source \/ target pairs, reused for new content via fuzzy and exact matching When you need one: 2 3+ languages, multiple translators, frequent product updates, or developer tool integration requirements What to compare: i18n format support, pricing model (per seat \/ per word \/ usage based), delivery (CDN\/API), workflow flexibility, data ownership In order to handle translations and make things simpler for translators, a TMS automates non essential activities and offers useful features. Learn how to use a TMS as an integral tool for a truly transformative experience in your business, and understand how development cycles accelerate and software quality grows to new heights. Table of contents What functions does a Translation Management System require? Benefits of using a TMS How translation management helped businesses scale What to consider while comparing various software solutions Why project managers and developers choose Locize as their TMS Transformative experience with continuous integration What functions does a Translation Management System require? A TMS is designed to manage translation and localization tasks centrally and continuously. While implementations differ, a modern translation management system should cover the following core functions. Managing translation workflows 1. Define what to translate 2. Send files to translators 3. Track translation progress 4. Review and approve changes 5. Deliver translations back to production A TMS reduces the amount of manual effort performed during each of these steps. Otherwise, it can be difficult for managers, translators, and reviewers to coordinate and promptly execute crucial project specifics, which frequently results in a longer time to market. A good TMS will trigger a review procedure each time a translation is modified. Until one of the translation suggestions is accepted, the actual value won't
40change. Managing terminology Terminology is the fundamental cornerstone of all translations. To describe objects and form sentences, people use words, phrases, and jargon. If your content generation is extended, certain criteria for managing material should be established for all parties involved. You should keep track of terms that should or shouldn't be translated via a glossary. It exists to facilitate use of the language your business prefers by human translators. Use the translation memory (TM) A TMS's translation memory feature is especially crucial since it greatly boosts the productivity of language localization. You can reuse words and phrases from previous work rather than coming up with new language every time. To assist human translators, sentences that have already been translated are stored in a database called a translation memory (TM). History, reporting, and metrics Every project management tool must provide the most crucial indicators about budget, progress, and other factors. The majority of the tasks are contained in one program by the TMS. As a result, reporting the numbers is a must. The data insights from the TMS help improve the administration of your localization projects. Additionally, keeping track of all previous translations is helpful. In the event of an inconvenience, it is possible to demonstrate at any moment who made what changes and when. Locize, our translation management system, offers an overview of the control center with the key figures for the ongoing project. The control center of our localization software displays all pertinent high level data: user management billing (customer details, billing history, budget limit, ...) project settings (Slack integration, webhook, integration metrics, ...) ordering (services, pending orders) branches project health and metrics Auto machine translation With this capability, the TMS attempts to automate parts of the translation process. Traditionally, an API is used to connect translated texts to an engine that handles the translation automatically. Because results from artificial intelligence are typically not 100% polished, a translator is frequently needed to evaluate the auto translation output. Read more in the AI in Localization article. For Locize, the entire automatic machine translation process occurs in the backend, which means you'll see the translated result after saving new keys in the reference language. Integration API API technology is used by excellent TMS solutions to connect to and interact with cloud based services. This enables it to automate and expand translation management in any content management system for all content kinds. There is thorough documentation for Locize on how to utilize an API to integrate any of your applications: https:\/\/www.locize.com\/docs\/integration\/api Benefits of using a TMS A TMS becomes essential when spreadsheets and manual processes no longer scale. Key benefits include: Centralized control over translations Faster release cycles Consistent terminology and tone Reduced administrative overhead Better collaboration between developers and translators Scalable localization across products and markets While a TMS may seem like an investment at first, it typically pays for itself by reducing delays, rework, and operational friction. How translation management helped businesses scale Organizations that adopt a TMS typically see improvements in: Productivity: Automation reduces manual coordination Quality: Consistent terminology and reuse of translations Scalability: Handling more languages and projects without linear cost increases Global reach: Faster entry into international markets Rather than isolated translation projects, localization becomes a continuous, repeatable process. Typical outcomes observed after adopting a TMS While results vary by organization, the following scenarios reflect common patterns seen when companies move from manual translation processes to a centralized TMS. More projects with the same team Organizations that previously managed translations manually often face long turnaround times and heavy coordination effort. After introducing a TMS and automating workflows, project durations can shrink from weeks to days. In a typical scenario, this allows teams to complete significantly more translation projects without increasing headcount, freeing up skilled employees to focus on higher value work. Lower operational costs Manual project management is resource intensive. By centralizing workflows, automating assignments, and reusing translations through translation memory, a TMS reduces administrative effort. Many organizations report noticeable cost reductions in project coordination, which can then be reinvested into product development, market expansion, or quality improvements. Revenue growth through scalability As demand increases, companies without a TMS often struggle to keep pace. A scalable translation management system enables team
40s to take on additional projects and languages without proportional increases in effort. This operational scalability frequently translates into revenue growth, as organizations can confidently accept more work while maintaining efficiency. Higher quality and recurring business Consistency is critical to client satisfaction. By enforcing terminology and reusing validated translations, a TMS helps ensure reliable quality across all projects. Improved consistency and quality often lead to stronger customer retention and more recurring business, as clients trust the results they receive over time. Expansion into global markets For companies initially focused on a domestic audience, a TMS lowers the barrier to entering new regions. By managing multiple languages efficiently, organizations can reach international users faster and more reliably. This capability often results in increased revenue from global markets, as products and content become accessible to a wider audience. What to consider while comparing various software solutions When you compare different translation management software, ask the following questions regarding your business: Who will be impacted and how quickly (stakeholders, customers, employees)? How will the TMS improve the end user experience? How much are we willing to spend on a TMS? Which infrastructure will the developed material be hosted on? Is it possible to automate any process? If you want to see how the current field answers those questions side by side, our editorial comparison of the best localization platforms for developer teams walks through the major platforms on exactly these axes, with what each one is genuinely good at. Why project managers and developers choose Locize as their TMS Locize is built for teams that ship software frequently and cannot afford translation bottlenecks. Instead of treating localization as a final step, Locize integrates translation directly into the development workflow. Additionally, Locize is the key piece to localize your software project, together with i18next. 1. Empowerment through simplicity Locize offers an intuitive interface that makes translation management straightforward without sacrificing precision. You can control exactly what each translator sees, track missing translations, and structure your application using multiple namespaces. The result: full visibility and control without unnecessary complexity. 2. End to delays in software delivery Say goodbye to the all too common translation delays that keep your software from shipping on time. With Locize, translators can begin their work from day one, thanks to our continuous localization process that keeps pace with your agile business needs. 3. Robust versioning support Every developer understands the significance of version control in software development. Locize excels here, ensuring that updates are managed without confusion, preserving your hard work, and enhancing team collaboration. 4. Escape service lock in Unlike other platforms, Locize champions your freedom. While fully integrated with i18next, Locize allows you to export your translations for use with any system you choose, reaffirming your control over your project's tools and data. 5. Expertise and support from i18next creators Locize is developed by the creators of i18next, one of the most widely used internationalization frameworks. This expertise is reflected in how the platform handles real world localization challenges. Best practices in internationalization are built into the product, not added as an afterthought. 6. Sophisticated handling of complex linguistic features Languages are more than strings. Locize correctly handles pluralization, context, and other linguistic edge cases across different languages. This ensures translations are not only accurate, but also contextually correct for global users. 7. Seamless integration with third party services Locize integrates smoothly with external translation services and workflows. Whether you work with freelancers, agencies, or machine translation providers, the platform adapts to your setup instead of forcing a rigid process. 8. Flexible translation delivery Translations can be delivered instantly via CDN without requiring a full redeploy (ideal for fast moving products). For environments with restricted internet access or special requirements, translations can also be bundled directly with the application. Watch our introduction video Create a new user account for free Check out how to add a new project Wondering if AI made the TMS obsolete? The honest assessment Frequently Asked Questions frontmatter.faq.map(( q, a ) = ( q a )) Transformative experience with continuous integration Picture a workflow where collaboration thrives, manual errors vanish, and efficie
40ncy soars. This is the promise of continuous integration: a path that beckons your development teams, project managers, and customers into a realm of software excellence. In this world, software quality reaches new heights, development cycles shrink to lightning speed, and every stakeholder enjoys a seamless experience. Your teams work in harmony, your customers rejoice, and your business thrives. The choice is clear: embark on the journey of continuous localization workflow and join the ranks of forward thinking businesses that reap its rewards. It's not just a workflow; it's a transformative experience."},{"slug":"bunny-cdn","title":"ð Announcing Locize Standard CDN: Fast, Simpler, and Generously Free!","description":"Locize introduces a new Standard CDN powered by BunnyCDN, now the default for new projects, faster global delivery, and 1,000,000 free downloads per month.","date":"2025-12-10","category":"Product","thumbnail":"\/img\/blog\/bunny-cdn\/bunnyCDN_locize.jpg","readTime":"3 min read","searchText":"hideCta: true, title: 'ð Announcing Locize Standard CDN: Fast, Simpler, and Generously Free!', description: 'Locize introduces a new Standard CDN powered by BunnyCDN, now the default for new projects, faster global delivery, and 1,000,000 free downloads per month.', date: '2025 12 10', thumbnail: '\/img\/blog\/bunny cdn\/bunnyCDN locize.jpg', image: '\/img\/blog\/bunny cdn\/bunnyCDN locize.jpg', category: 'Product', tags: ['localization', 'product', 'cdn', 'performance'] Christmas is approaching and we have a gift for you! We're thrilled to share some exciting news that will make your localization workflow even more efficient and cost effective: Locize is launching its new Standard CDN , powered by the ultra fast BunnyCDN! This new Content Delivery Network is now the default for all new Locize projects, bringing significant advantages, especially for public facing applications and open source initiatives. Why a New CDN? At Locize, we're constantly striving to optimize your experience, not just in managing translations but also in delivering them to your end users. While our robust Pro CDN (based on AWS CloudFront) is serving you well, we identified an opportunity to provide an even more accessible option for a wide range of projects. Enter the Standard CDN! Introducing the Standard CDN (Powered by BunnyCDN) Our new Standard CDN leverages the power of BunnyCDN , a leading provider known for its exceptional speed, global reach, and cost efficiency. This means your users get their translations delivered faster than ever before, wherever they are in the world. But that's not all! The Standard CDN comes with a fantastic benefit: your first 1,000,000 downloads per month are absolutely FREE! This makes it an incredibly attractive option for open source projects, smaller websites, single page applications (SPAs), and anyone looking to optimize their operational costs without compromising on speed. Key Benefits of the Standard CDN Blazing fast delivery: Powered by BunnyCDN's extensive global network, your translations reach your users with minimal latency. Generous free tier: Enjoy 1,000,000 free downloads every month. This significantly reduces costs for many projects. Simplicity by default: It's now the default for all new projects, meaning you get these benefits right out of the box. Ideal for public content: Perfect for websites, blogs, and applications where translation files are publicly accessible. What's the Difference Between Standard and Pro CDN? To ensure you choose the best fit for your project, we now offer two distinct CDN types: Feature Standard CDN (BunnyCDN) Pro CDN (AWS CloudFront) Infrastructure BunnyCDN AWS CloudFront Cost First 1M downloads FREE On Demand pricing Private downloads â No (Public only) â
Yes (via API Key) Published namespace history â No â
Yes Custom caching (TTL) â Fixed (1 hour) â
Customizable Best for Public websites, SPAs, Open Source Enterprise apps, Private content, Advanced caching How to Use the Standard CDN For new projects, the Standard CDN is already active by default. If you're an existing Locize user and wish to
40switch your project to the Standard CDN, you can easily do so in your project settings: And for developers, we've made sure our tools seamlessly integrate with the new option: : Use : Set in your backend options (requires or higher) \/ : Set in your script tag or in the init options We've updated our documentation to provide details on both CDN types, including pricing and integration guides. Get Started Today! The new Standard CDN represents our commitment to providing flexible, high performance, and cost effective localization solutions. We're confident it will empower even more projects to go global with ease. Ready to experience the difference? Start your free Locize trial today!"},{"slug":"offline-first-apps","title":"Offline-First Apps: Architecture, Frameworks & Real Examples","description":"Offline-first apps work without a network and sync when reconnected. See the architecture, frameworks (PouchDB, RxDB, WatermelonDB, Realm), and when to use this approach.","date":"2025-10-01","category":"Guides","thumbnail":"\/img\/blog\/offline-first-apps\/offline-first-app.webp","readTime":"13 min read","searchText":"title: 'Offline First Apps: Architecture, Frameworks & Real Examples', description: 'Offline first apps work without a network and sync when reconnected. See the architecture, frameworks (PouchDB, RxDB, WatermelonDB, Realm), and when to use this approach.', date: '2025 10 01', thumbnail: '\/img\/blog\/offline first apps\/offline first app.webp', image: '\/img\/blog\/offline first apps\/offline first app.webp', category: 'Guides', tags: ['localization', 'guides'], faq: [ q: 'What is an offline first app?', a: 'An offline first app is designed to work without an internet connection. Data is stored locally on the device, the app operates against that local copy, and changes are synchronized with the server in the background once a connection is available. This is the opposite of online first apps, which require the network for most operations.' , q: 'What is the difference between offline first and a Progressive Web App (PWA)?', a: 'A PWA is a delivery model: a web app that can be installed on the device with service worker support. Offline first is an architecture choice: designing the app so it works without a network. Many PWAs are offline first, but the two concepts are independent: a PWA can be online only, and a native mobile app can be offline first.' , q: 'Which frameworks help build offline first apps?', a: 'For local storage and sync, the most common choices are PouchDB (web\/Node, syncs with CouchDB), RxDB (real time, RxJS based), WatermelonDB (React Native, high performance), Realm (iOS\/Android), Couchbase Lite (mobile with built in sync), and SQLite (cross platform, embedded). For service worker caching and offline page delivery on the web, Workbox is the standard.' , q: 'How do offline first apps handle conflicts when two devices change the same data?', a: 'There are several strategies. The simplest is Last Write Wins, where the most recent change overwrites the older one. More sophisticated approaches use timestamped merge rules, application specific conflict resolvers, or Conflict free Replicated Data Types (CRDTs), which mathematically guarantee convergence across distributed replicas. The right choice depends on the data model and how often conflicts actually occur.' , q: 'When should I choose offline first?', a: 'Choose offline first when your users need to work in environments with unreliable or unavailable networks (field service, transit, healthcare, construction), when responsiveness is critical (every interaction must feel instant), or when you want to reduce server load and operational risk from network outages. Skip it when content must always be live (stock prices, live feeds, real time multiplayer) or when the engineering cost of sync and conflict resolution outweighs the user benefit.' , q: 'How much storage space does an offline first app require?', a: \"The storage requirements depend heavily on the app's functions and data volumes. A notes app often only needs a few megabytes, while business apps with extensive catalogs or documents can take up several hundred megabytes. Plan a storage and cleanup strategy from the start (what is cached, how long it is kept, and when it is evicted) and consider exposing usage to users so they can manage it.\" , q: 'How are updates handled in an offline first app?', a: 'Updates affect two levels: the application itself and the data. The app is updated as usual via app stores or browsers. The data receives updates as soon as an internet connection is reestablished. Modern synchronization mechanisms ensure that new content is loaded gradually without rebuilding the entire database, which saves time and bandwidth.' , q: 'How does AI translation work in an offline first app?', a: 'Multilingual content can be pre loaded and cached locally s
40o the app remains usable in any supported language without a network. Translation updates and new languages are synchronized when a connection is available. Tools like the i18next chained backend pair a remote translation source (e.g. the Locize CDN) with locally bundled JSON files as a fallback: the app loads live translations when online and gracefully falls back to bundled copies when offline.' ] An offline first app is an application designed to function reliably without an active internet connection. Data is stored locally on the device first, the app continues working when the network is unstable or absent, and changes are synchronized to the server in the background as soon as a connection is available. The architecture has become standard for productivity, messaging, and field service apps where availability matters more than always current data. Key facts What it is: an app that stores data locally first and syncs to the server when a connection is available vs online first: the network is optional, not required, for core functionality Where it shines: unreliable networks, mobile\/field work, productivity and messaging apps Key components: local storage, sync engine, conflict resolution, optimistic UI Example frameworks: PouchDB, RxDB, WatermelonDB, Realm, Couchbase Lite, SQLite Where it is overkill: pure read apps with stable connectivity, content that must always be live Why is this so important today? Studies clearly show why this approach is so important today. Mobile apps that freeze too often or take a long time to load are immensely frustrating for users. Many delete them after the first problem. Over 70% of mobile app users stop using an app if it responds too slowly, and 84% give up if it fails just twice. Example of an offline first app Navigation apps are a typical example. Users download map material in advance and can then navigate even in areas without mobile network coverage. The app continues to function smoothly. Routes are calculated, locations are displayed, and traffic data is reloaded the next time a connection is available. This same principle can be applied to many other applications, such as messaging apps. ,Definition,Examples) that first cache messages and then synchronize them later, or business tools that allow field staff to access customer data even without Internet access. Key features of an offline first app Data is stored on the device first, not on the server. Changes are automatically submitted as soon as the internet connection is restored. The app remains usable even when networks are unreliable or overloaded. Actions are made visible immediately, even if server confirmation follows later. Built in strategies ensure that conflicting data sets are merged consistently. There are no long loading times or interruptions, which increases satisfaction and loyalty. Systems and frameworks for offline first apps PouchDB Platforms: Web, Node.js Special features: JavaScript database, seamlessly synchronizes with CouchDB Typical areas of application: Web apps, PWAs RxDB Platforms: Web, React Native Special features: Real time database based on RxJS, replication to CouchDB Typical areas of application: Collaborative apps, sync heavy UIs Couchbase Lite Platforms: iOS, Android Special features: Mobile database with built in synchronization to Couchbase Typical areas of application: Enterprise apps, offline workflows WatermelonDB Platforms: React Native Special features: High performance DB for large amounts of data, synchronization via backend Typical areas of application: Mobile apps with extensive data Realm Platforms: iOS, Android Special features: Local database with server side synchronization function Typical areas of application: Consumer apps, rapid prototyping SQLite Platforms: Cross platform Special features: Classic relational DB, locally embedded, often standard on devices Typical areas of application: Universal mobile apps What are the advantages of offline first apps for businesses and users? In the classic online first model, an app's functionality depends directly on a stable internet connection. Functions such as data storage, synchronization, and transactions run almost exclusively via the server. The advantage? The data is always up to date and centrally managed. The disadvantage? As soon as the network is weak or unavailable, reliability declines. Users have to wait, lose data, or abandon the app in frustration. The offline first principle reverses this logic. Data is first processed and stored locally. The server only comes into play when there is a connection and synchronization is necessary. This ensures a continuous user experience, regardless of network quality or location. This results in very different but equally decisive advantages for companies and end users. Benefits for businesses For companies, the use of offline first apps primarily means reliability in customer contact. When an app always works, even under adverse network conditions, user loyalty increases significantly. Abortions and uninstallations, which often entail high costs, are reduced. In addition, local data processing noticeably reduces the load on the server infrastru
40cture with fewer queries, lower peak loads, and optimized resource utilization. Companies also benefit internally, especially in industries such as logistics, field service, or construction, where employees often work without a stable connection. An offline first architecture ensures that business processes continue seamlessly instead of having to wait for the network to return. This increases productivity and significantly shortens process chains. Another important factor is software localization. In global markets, applications must not only work offline, but also adapt to different languages, regions, and legal requirements. A combination of offline first architecture and effective localization ensures that users worldwide experience the same reliability and cultural fit. Last but not least, an offline first strategy strengthens the brand image. Companies position themselves as innovative, customer oriented, and technologically forward thinking. This can be a decisive factor, especially in highly competitive markets. Advantages for users For end users, the most important advantage of an offline first app is continuity of use. Whether on a plane, abroad with poor network coverage, or in a basement with no reception, the app remains reliable. Actions such as reading messages, creating notes, or editing documents are possible at any time. Added to this is speed. Because a lot of data is available directly on the device, there are no long loading times. Users experience the app as responsive and stable, which significantly increases satisfaction. Another plus point is transparency when connection problems arise. Well designed offline first apps clearly communicate when data is being synchronized and which actions are running in the background. This reduces frustration and gives users the feeling that they are in control at all times. Offline first architecture explained The offline first architecture describes the structure of the offline first app. The basic principle is very simple. All data is first stored directly in local storage on the device. The app works with the information provided to it, even if there is no connection to the server. As soon as the internet is available again, the application synchronizes the data with the central system in the background. You can think of it like a diary. Everything a user enters is immediately stored in their own book. When the opportunity arises later, the diary is compared with a larger collection and supplemented. This ensures that everything remains up to date and complete. At its core, an offline first architecture consists of three areas: First, local storage, where data is stored on the device. Second, synchronization, which exchanges new or changed data with the server. Third, a mechanism that decides which data to transfer in case of discrepancies. A typical process works like this: The user enters information into the app. This is stored directly and is immediately available. When the app later connects to the server, the data is automatically synchronized. If both sides match, everything remains as it is. If the data differs, a set of rules decides which version to keep or whether to merge both. What technical components make offline first apps possible? An offline first app works because several technical components interact seamlessly. Each part performs its own task and helps to ensure that the application remains stable even without an internet connection. On the technical side, the main focus is on storage, synchronization, conflict resolution, and the way the app handles data. 1. Local storage â¡ï¸ Data is stored directly on the device. ð§ Technologies: SQLite, IndexedDB, Realm, Couchbase Lite. ⨠Benefits: Data is available at all times, even without an internet connection. 2. Synchronization â¡ï¸ Data is synchronized between the device and the server. ð§ Technologies: PouchDB with CouchDB, RxDB, WorkManager. ⨠Benefits: Changes are automatically submitted as soon as a connection is established. 3. Caching â¡ï¸ Temporary storage of frequently used content. ð§ Technologies: Service Worker Cache, Workbox. ⨠Benefits: Fast access and reduced server load. Translation caching c
40an also be implemented using chained backends such as Locize, ensuring localized strings remain accessible offline. 4. Conflict resolution â¡ï¸ Handling different versions of the same data. ð§ Technologies: Last Write Wins, merge strategies, CRDTs. ⨠Benefits: Consistent data despite parallel processing. 5. Optimistic UI â¡ï¸ Immediate display of user actions, even if the server has not yet responded. ð§ Technologies: Custom logic, state management libraries. ⨠Benefits: Smooth user experience without waiting times. See also: What is Optimistic UI? 6. Background processes â¡ï¸ Automatic synchronization or backups in the background. ð§ Technologies: Android WorkManager, iOS Background Tasks. ⨠Benefits: Stable processes even without active user interaction. 7. Security mechanisms â¡ï¸ Protection of locally stored data. ð§ Technologies: Encryption, Keychain, Secure Storage. ⨠Benefits: Secure handling of sensitive information on the device. What are the limitations and challenges of offline first apps? The technology behind an offline first app is more complex than that of traditional online first applications. Every app needs a reliable strategy for storing, synchronizing, and securing data. Above all, it should always meet user expectations. Synchronization is a key issue. As soon as a device is reconnected to the internet, all data must be synchronized with the server. This can lead to conflicts if several people change the same information at the same time. Such situations require clear rules that automatically decide which version remains or how content is merged. Another issue concerns security. Data stored locally on the device is available at any time, but it must be reliably protected. Encryption, secure access rights, and careful handling of sensitive information are essential here. Another challenge is handling multilingual content offline. Here, translation software can play a key role by ensuring that text modules, labels, and dynamic content are available in multiple languages even without a constant internet connection. When the device reconnects, updates and refinements can be synchronized seamlessly. Even in an offline first architecture, translations must remain available and up to date. Many modern apps rely on cloud based translation delivery networks (CDNs) such as Locize to manage and update their i18n resources in real time. However, some environments (like corporate intranets, restricted networks, or offline business scenarios) can block external CDNs entirely. To address this, Locize offers an elegant hybrid approach: developers can use the i18next chained backend to define multiple data sources. The app primarily loads translations from the Locize CDN for instant updates and continuous localization and automatically falls back to locally bundled JSON files if the CDN cannot be reached. This setup combines the convenience of a live translation service with the reliability of offline first design. Benefits of this hybrid approach: Instant translation updates without redeployment Local fallback ensures usability in restricted or offline environments Support for secure private publishing with API keys Flexible hosting: developers can also download and bundle translations directly In practice, this means your app continues to display correct and localized content, even in the absence of network connectivity. Once the connection is restored, translation updates are synchronized automatically. This approach fits perfectly into an offline first architecture that values continuity, autonomy, and global user experience . Resource planning also poses questions for companies. Offline first architectures require additional development time, thorough testing, and an infrastructure that can map synchronization processes cleanly. This means higher costs at the outset, but these can be offset in the long term by better stability and lower abandonment rates. For users themselves, data consistency poses a challenge. When content is available locally and only synchronized later, there may be moments when information is not identical on all devices. This behavior is typical for offline first systems, but requires a clear design that provides users with understandable information. Possible considerations for overcoming these challenges: Plan conflict management from the outset Incorporate encryption and access control Design synchronization step by step Integrate user friendly status displays Conduct intensive testing in offline mode Pay attention to scalability 3 practical examples of offline first Practical example: messaging app A messaging app such as WhatsApp or Signal clearly illustrates how offline first architecture works. Users can compose messages even when there is no internet connection. The message is saved in local storage and automatically sent later as soon as the network is available again. For users, the experience is seamless; they don't have to wait or retype messages. For the provider, this means greater reliability and less frustration on the part of the community. Practical example: business app for field service Business applications also benefit from offline first. Field service employees who attend customer appointments or take orders often work in regions without a stable network. An offline first app allows them to view customer data, fill out forms, and save orders. As soon as a connection is reestablished, everything is synchronized and entered into the central system. This increases productivity, reduces media breaks, and ensures that business processes run smoothly. Practical example: notes app Notes apps such as Evernote or Apple Notes often rely on offline first features. Users can capture thoughts, sketches, or tasks at any time. Everything is initially stored locally and is immediately available again. As soon as a connection is available, the app synchronizes the content with the cloud and synchronizes it across all devices. This creates a smooth transition between smartphone, tablet, and computer. How can an offline first app be implemented step by step? A good offline first app does not happen by chance, but through a clear and structured development process. Each phase builds on the previous one and ultimately results in a stable application that remains reliable even under difficult conditions. Step 1: Prioritize requirements and usage scenarios The first step is to analyze which functions and data must be available at all times, even without a connection. It is worth running through typical usage situations and determining exactly which journeys are critical for users. Step 2: Define the domain model and data flow The next step is to create a clear model that describes how data is created, processed, and stored. Reading, writing, and synchronizing should be understood and planned as separate processes. Step 3: Set the âsource of truthâ on the device To ensure that the app runs smoothly at all times, local storage serves as the central data source. All information is first stored locally before being synchronized with the server later. Step 4: Select a storage system A suitable database is required for implementation. Whether SQLite, IndexedDB, Realm, or Couchbase Lite, the choice depends on which platform is to be supported, how large the data volumes are, and what functions the app requires. Step 5: Develop a synchronization strategy It is necessary to decide how the app will exch
40ange data. Some systems work with push, others with pull, and many combine both. Delta sync reduces the data load by transferring only changes. Step 6: Define conflict rules When different devices modify the same data set, discrepancies can arise. To ensure consistency, clear rules must be established, such as which version takes precedence or whether changes are merged. Step 7: Design a robust network layer The app should be able to handle different network situations. Queues for requests, retries with increasing intervals, and mechanisms that elegantly catch connection interruptions are suitable for this purpose. Step 8: Plan caching and preloading Frequently used content can be stored in advance. At the same time, rules are needed for when data is deleted or compressed so that storage is not overloaded. Step 9: Set up background processing Synchronization and other processes can be performed automatically in the background. On Android, tools such as WorkManager take care of this process, on iOS special background services, and on the web, Service Worker. Step 10: Ensure security All locally stored data should be encrypted. Keys belong in secure areas of the operating system. In addition, only as much data as is actually needed should be stored. Step 11: Design the user experience An offline first app must clearly display its current status. Users should be able to see immediately whether they are working offline, whether data is queued, or whether synchronization is in progress. Step 12: Set up telemetry and monitoring Metrics are needed to ensure quality. These include information about how long synchronization takes, how often conflicts occur, or how many requests fail. Step 13: Develop a testing strategy Before rollout, the app is tested under realistic conditions. These include slow networks, connection interruptions, airplane mode, and scenarios such as limited storage space. Step 14: Roll out gradually It is best to introduce the app in stages. Feature flags can be used to activate the new architecture for small user groups first. This allows problems to be identified and resolved early on. Step 15: Ensure operation and maintenance Even after release, the app requires continuous maintenance. This includes regular data synchronization, adjustments to new operating system versions, and clear procedures for dealing with conflicts or device replacement. Frequently Asked Questions frontmatter.faq.map(( q, a ) = ( q a )) Conclusion Offline first has moved from niche to mainstream. It is now the default architecture for any app where users work on the move, on unreliable networks, or in environments with no connectivity at all. The cost is higher upfront engineering work for sync, conflict resolution, and local storage management; the payoff is an app that stays responsive and reliable when the network does not. For apps with multilingual content, pair the offline first storage layer with i18next chained backend so translations stay available even when the CDN is unreachable."},{"slug":"i18next-savemissing-ai-automation","title":"Discover a Smarter Way: Automating i18next Translations with saveMissing and Locize AI","description":"Use i18next saveMissing with Locize and automatic AI translation to create and translate keys in real time as you build, reducing manual extraction and keeping translations in sync.","date":"2025-09-29","category":"Guides","thumbnail":"\/img\/blog\/i18next-savemissing-ai-automation\/hero-saveMissing.jpg","readTime":"4 min read","searchText":"hideCta: true, title: 'Discover a Smarter Way: Automating i18next Translations with saveMissing and Locize AI', description: 'Use i18next saveMissing with Locize and automatic AI translation to create and translate keys in real time as you build, reducing manual extraction and keeping translations in sync.', date: '2025 09 29', thumbnail: '\/img\/blog\/i18next savemissing ai automation\/hero saveMissing.jpg', image: '\/img\/blog\/i18next savemissing ai automation\/hero saveMissing.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'ai'] The i18next community has always championed flexibility in localization workflows. While tools like the new excel at extracting keys from your co
40debase, there's a powerful, alternative approach that can streamline your development and translation process even further: i18nextâs feature, supercharged by Locizeâs automatic machine translation. This method shifts your focus from manual key extraction to a dynamic, real time workflow where translation keys are created and automatically translated as you develop. It's about letting your application tell your translation management system what it needs, precisely when it needs it. The Challenge of Manual Key Management Traditionally, managing translation keys often involves a cycle of: 1. Writing new UI text in your application. 2. Manually creating a translation key (e.g., ). 3. Running an extraction tool ( , , ) to find these keys in your source code. 4. Pushing these extracted keys to your translation management system (TMS). 5. Waiting for human translators, or manually triggering machine translation, to fill in the missing values. While robust, this process can introduce friction, especially in fast paced development environments. It requires a distinct step for key extraction and often means translation files are out of sync with your live application. Introducing : Keys When You Need Them i18nextâs feature offers an elegant solution to this. When enabled in your i18next configuration, if your application attempts to translate a key that doesn't exist in your current language resources, won't just return the key itself. Instead, it will automatically inform a connected backend about this missing key. This means you can simply use in your code, and i18next, in conjunction with a compatible backend, will handle the rest. The key and its default value are sent to your translation service without any manual file creation or command line extraction. The Perfect Partner for For to work its magic, you need a backend that supports the function, and this is where Locize shines. By integrating into your project, any key your application requests that isn't yet present in Locize is automatically added. This creates a truly continuous localization workflow: 1. Develop: Write your code, adding new calls as needed. 2. Run application: As your application loads or users interact with new features, any missing translation keys are automatically detected and sent to your Locize project. 3. Real time updates: These keys appear in Locize almost instantly, ready for translation. This seamless integration ensures that your Locize project always reflects the current state of your application's translation needs, reducing the overhead of manual key synchronization. To learn more about how and other features handle the complexities of missing translations, check out our blog post on Missing Translations. The Power of AI Translation: From Missing to Translated in Seconds The real game changer comes when you combine with Locize's automatic machine and AI translation workflow . Locize allows you to configure your project to automatically translate any newly added keys into your target languages using advanced machine translation or generative AI. Hereâs how this powerful synergy works: 1. You introduce a new translation key in your code (e.g., ). 2. Your running application, configured with and , sends this new key and its default value to Locize. 3. Locize receives the key and, because you have the automatic translation workflow enabled, instantly translates âGood morning!â into all your configured target languages (e.g., German, French, Spanish) using AI. 4. These machine translated or AI translated texts are then available immediately via Locize's CDN, meaning your application can display the translated text almost as soon as you've typed the original. This workflow is incredibly efficient for initial translation drafts, allowing you to quickly internationalize your application's UI. Human translators can then refine these AI generated translations, focusing on nuance and quality rather than starting from scratch. We explored this hybrid approach further in our article, i18next, Locize, AI, and Human Translation: A Powerful Combo. vs. : Complementary, Not
40Conflicting While and other extraction tools perform a âpullâ operation (scanning your code for keys), with Locize performs a âpushâ operation (your app tells Locize what's missing). Both have their strengths and ideal use cases: : Ideal for ensuring all keys in your codebase are accounted for, especially during a build process, catching stale keys, and generating type safe translation files. It gives you a snapshot of your keys at a specific point in time. + Locize (dynamic push): Perfect for rapid development, reducing friction, and ensuring that new content is immediately available for translation. It's a continuous, real time approach. In many robust localization pipelines, these two approaches can even complement each other . You might use during development for instant feedback and then use (perhaps in a CI\/CD pipeline) as a final validation step to catch any edge cases or identify unused keys for cleanup. Get Started Today Embracing the feature with Locize's automatic translation workflow can dramatically accelerate your localization efforts and provide an unparalleled developer experience. It minimizes manual intervention, leverages the power of AI, and ensures your translations are always up to date. To see this in action and set up your own project, explore the comprehensive tutorial on YouTube:"},{"slug":"i18next-cli","title":"Supercharge Your i18next Workflow with the All-New i18next-cli","description":"Announcing i18next-cli: the official next-generation toolkit for extraction, syncing, linting, type generation, and translation status reporting, built for performance and modern JS\/TS patterns.","date":"2025-09-25","category":"Guides","thumbnail":"\/img\/blog\/i18next-cli\/i18next-cli-hero.jpg","readTime":"5 min read","searchText":"hideCta: true, title: 'Supercharge Your i18next Workflow with the All New i18next cli', description: 'Announcing i18next cli: the official next generation toolkit for extraction, syncing, linting, type generation, and translation status reporting, built for performance and modern JS\/TS patterns.', date: '2025 09 25', thumbnail: '\/img\/blog\/i18next cli\/i18next cli hero.jpg', image: '\/img\/blog\/i18next cli\/i18next cli hero.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'cli', 'workflow'] The i18next ecosystem has been at the heart of web localization for over a decade. It was born in a world of jQuery and has evolved alongside the community through the rise of modern frameworks like React, Vue, and Svelte. As our applications have grown in complexity, so have the challenges of managing translations. (New to the stack? Start with our JavaScript localization guide for the framework by framework setup.) For years, the community has relied on tools like for the critical task of extracting translation keys. These tools were pioneers and have served us well. But as codebases swelled into the hundreds of thousands of lines and modern JavaScript syntax became the norm, we began to feel the friction. Slow extraction times, struggles with TypeScript and JSX, and the need for a patchwork of different tools to create a complete workflow became common pain points. It was time for a change. Today, we're thrilled to introduce , the official, next generation, all in one toolkit for the i18next ecosystem. Itâs a complete reimagining of the developer toolchain, built with three core principles in mind: raw performance , deep code intelligence , and a unified developer experience . ð Want to try it without reading the complete announcement? ð We designed to provide immediate value. You can get an instant analysis of your project's translation status without any configuration . Just run this command in your repository's root: It heuristically detects your project structure and gives you a report in seconds. Update (June 2026): there's now also a one command path from hardcoded strings to a fully localized app: chains instrument, extract, Locize setup, and AI auto translation in a single run. See One command from hardcoded strings to a localized app. For those using , the transition is seamless. Our migration command automatically converts your legacy config file to the new format: Why This Matters: A Better Workflow Before diving into the features, let's talk about the impact. Blazing Fast, By Design Performance is not just a feature; itâs the foundation of a great developer experience. The single biggest bottleneck in older tools was the use of JavaScript based parsers. solves this by being built on SWC , a modern, Rust based compiler. By leveraging native code, we've unlocked dramatic speed improvements. Workflows that once took over a minute to scan a large project now complete in under five seconds. This isn't just an upgrade; it's a transformation of the development loop, making localization tasks feel instantaneous. One Tool to Rule Them All A complete localization workflow requires more than just extraction. is a true toolkit , unifying all essential functions into a single, cohesive CLI with one configuration file. : The core command to find and save keys with a powerful mode. : Keeps your language files synchronized, adding missing keys and removing unused ones. : Generates TypeScript definitions for ultimate type safety and autocompletion. : Finds hardcoded strings in your code that should be translated, with smart heuristics to reduce false positives. : Gives you a high level dashboard of your project's translation health, with detailed, per namespace reporting. It Just Works: Advanced Pattern Detection was built with a scope aware analyzer that creates a semantic understanding of your co
40de. This means it handles a wide range of modern patterns automatically, with no extra configuration needed. with : It understands that modifies the keys used by . component with complex children: Parsing the component is notoriously tricky. handles it, correctly serializing nested components and even extracting keys from props inside the component. The CLI correctly understands this and extracts two keys: 1. , with the default value: 2. from the nested prop. Aliased and destructured functions: Whether you rename or pull it from an array, the toolkit follows along. Key fallbacks and : It understands advanced i18next features, extracting all static keys from a fallback array and preserving nested objects when you need them. ð Try it Now Zero Config! We designed to provide immediate value. For most projects, you can get an instant analysis of your translation status without any configuration . It heuristically detects your project structure and gives you a report in seconds. Just run this command in your repository's root directory: Migration Made Easy For existing users of , we've made the transition seamless. The toolkit includes a migration command that automatically converts your legacy config file to the new format. Taking Your Workflow to the Cloud with Locize provides a best in class workflow for managing your local translation files in Git. As your project grows, however, managing translations across a team of developers, translators, and product managers can become a challenge. This is where Locize , our translation management platform, is the natural next step. We built to be the perfect bridge between local development and a professional, cloud based localization workflow. The CLI is fully integrated with Locize, allowing you to migrate your project and synchronize translations with simple commands ( , , ). It moves your translations out of JSON files and into a powerful platform built specifically for collaboration. Get Started Today We believe sets a new standard for localization tooling. Itâs a reflection of our commitment to the i18next community and our mission to create a truly seamless developer experience. Check out the full documentation, advanced configuration, and plugin system on the official GitHub repository . We can't wait to see how it speeds up your workflow."},{"slug":"guide-to-i18n-key-naming","title":"The Art of the Key: A Definitive Guide to i18n Key Naming for Longevity and Sanity","description":"A practical guide to i18n translation key naming: how to avoid i18n debt, choose a sustainable key strategy, handle reuse, and scale with namespaces and context.","date":"2025-09-22","category":"Guides","thumbnail":"\/img\/blog\/guide-to-i18n-key-naming\/the%20art%20of%20the%20i18n%20key.jpg","readTime":"9 min read","searchText":"title: 'The Art of the Key: A Definitive Guide to i18n Key Naming for Longevity and Sanity', description: 'A practical guide to i18n translation key naming: how to avoid i18n debt, choose a sustainable key strategy, handle reuse, and scale with namespaces and context.', date: '2025 09 22', thumbnail: '\/img\/blog\/guide to i18n key naming\/the%20art%20of%20the%20i18n%20key.jpg', image: '\/img\/blog\/guide to i18n key naming\/the%20art%20of%20the%20i18n%20key.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides'] Internationalization (i18n) is the blueprint for global software. At its heart lies a deceptively simple element: the translation key . Your team's approach to naming these keys isn't a minor detail: it's a foundational architectural decision. A poor strategy creates âi18n debt,â a silent tax on every future feature that slows development and inflates costs. A great one ensures longevity and streamlines collaboration for years to come. The Key is a Three Party Contract ð Think of an i18n key not as a variable, but as a stable, multi party contract between three stakeholders: 1. Developers: They need a predictable interface to retrieve text. The key should offer clues about a stringâs purpose, reducing the need to constantly jump between the codebase and translation files. 2. Translators: The key is often their first and most important piece of context. A key like is a beacon of clarity; is a black box that invites guesswork and errors. 3. Systems (TMS): A Translation Management System uses the key as a unique, immutable ID to manage a stringâs entire history, screenshots, comments, and glossary terms. If a key changes, that contract is broken, the history is lost, and the string must be re translated from scratch. A strategy that only serves one party will inevitably fail. What looks like a simple naming convention is actually a complex system design problem that must balance the needs of everyone involved. Why Key Naming is a Critical Architectural Decision ðï¸ Choosing your key strategy hastily is like building a house on a shaky foun
40dation. The i18n debt you incur manifests in several painful ways: Maintenance Brittleness: When keys are tied to file paths, refactoring UI code becomes a nightmare. Developers become afraid to make changes for fear of breaking translations in a dozen languages. Increased Bugs: Ambiguous or reused keys are a primary source of localization bugs. Using a single key for âReadâ can lead to grammatical errors when the context shifts from a verb (âRead moreâ) to a status (âMessage Readâ). Collaboration Friction: A chaotic system forces translators to constantly ask developers for clarification, pulling them away from feature development and slowing down the entire localization cycle. Reduced Scalability: As an application grows, a flat list of keys becomes unmanageable and kills performance. A scalable architecture requires a structured approach from day one to enable optimizations like code splitting translations. Investing time to establish a robust strategy is a down payment on future agility, enabling your team to build and scale a global product efficiently. The Three Philosophies of Key Naming Three dominant philosophies have emerged for naming keys. The choice between them is a fundamental decision about where to place the burden of complexity in your workflow. 1. Structured (Semantic) Keys: The Path of Order This is the most robust and widely recommended approach. It involves creating abstract but descriptive identifiers that are decoupled from the source language text. Example: , Pros: â
High Maintainability: The English source text can be changed without touching the code, preserving all existing translations. â
Provides Context: A key like tells translators its location and purpose. â
Avoids Collisions: A partial namespacing is built in, preventing ambiguity. But can also be improved with real namespaces. Cons: â Increased Upfront Effort: Itâs a âwrite it twiceâ workflow: create the key in code, then add its value in a JSON file. â Reduced In Code Readability: The code shows , not the actual text. However, this readability drawback is being solved by innovations in the i18next ecosystem. The new Selector API transforms the experience. Instead of a magic string, you use a type safe function: . This enables autocompletion, compile time checks, and seamless refactoring in TypeScript, turning a historic weakness into a major strength. 2. Natural Language (Content as Key): The Path of Convenience This philosophy prioritizes initial development speed by using the full source language string (typically English) as the key itself. Example: Pros: â
High In Code Readability: The code is self documenting, showing the exact default text. â
Low Initial Effort: Itâs the fastest way to start, as thereâs no need to invent a separate keying system. Cons: â Extremely Brittle: This is the deal breaker. Fixing a simple typo or rephrasing the text changes the key , breaking the link to all existing translations and forcing costly re translation. â Problematic for Complex Strings: Using paragraphs or strings with HTML as keys is unwieldy and error prone. â Inherent Ambiguity: It canât differentiate between two identical strings that need different translations based on context (e.g., âViewâ as a noun vs. a verb). 3. Content Agnostic (Generated) Keys: The Path of Ultimate Decoupling A less common approach that uses machine generated identifiers as keys. Example: Pros: â
Guaranteed Uniqueness and Stability: Eliminates human error in naming and ensures the key is never changed. â
Complete Decoupling: The key is independent of both content and code structure, offering maximum architectural flexibility. Cons: â Zero Human Readability: The keys are meaningless without a sophisticated layer of tooling. â Heavy Reliance on Tooling: This approach is only viable with mature tools like IDE extensions that display source text inline and a robust TMS that provides all context to translators. Ultimately, Structured (Semantic) keys represent the most balanced approach. They place a manageable burden on the developer during initial implementation to reduce systemic friction and cost for all stakeholders over the long term. The Great Debate: To Reuse or Not to Reuse? ð¤ Developers are trained on the âDonât Repeat Yourselfâ (DRY) principle, so creating a key seems efficie
40nt. However, this is a dangerous trap. âCreating new messages is cheaper than trying to manage shared messages.â The flaw is that textual identity is not semantic identity . While two strings may be identical in English, their correct translations can vary dramatically depending on context. The unbreakable rule is to adopt the linguistâs perspective: the fundamental unit of translation is the message in context . Dangers of Reuse: Grammatical Context: âReadâ (present tense verb) and âReadâ (past tense status) require different translations. A single key forces them to be the same. Domain Context: âCancelâ for a subscription is a significant action; âCancelâ for a dialog box is trivial. The translation should reflect this. Future Divergence: Two âBackâ buttons might be identical today, but next month a PM may want one of them to say âPrevious Step.â Changing the shared key breaks the other instance. Try to use this default policy: never reuse keys . Each string instance in the UI should have its own unique key. An approach that creates distinct keys like and is vastly superior because they are free to evolve independently. Building for Scale: Namespaces and Performance As an application grows, a flat list of keys collapses into chaos. A structured system is essential for scale and performance. Namespacing: Partition keys into logical groups. The most robust strategy is to namespace by feature or domain ( , ). This aligns your i18n structure with your application architecture and is resilient to UI refactoring. Nesting: Use a dot ( ) separator to create a hierarchy within namespaces. A nesting depth of 2â3 levels ( ) provides the best balance of organization and simplicity. Code Splitting: A key benefit of namespacing is performance. Instead of loading one giant translation file, modern libraries like can load namespaces on demand. When a user navigates to the checkout page, you only fetch the translations, dramatically improving your appâs initial load time. Beyond Plain Text: Mastering Complex Content Modern UIs are dynamic. Simply concatenating strings is the cardinal sin of i18n: it hardcodes English grammar into your app and is guaranteed to fail in other languages. ICU Message Format The industry standard is the ICU (International Components for Unicode) Message Format , which embeds logic directly into your translation string. Pluralization: Handle complex plural rules for different languages with a single key. But seems the simpler i18next format is preferred by most developers and offers interpolation, context, nesting, formatting, pluralization and much more... Rich Text and HTML Never embed raw HTML in translations and render it with . This is a major security risk. The correct solution is component interpolation . Libraries like use a component that lets you safely mix text and React components. This maintains a clean separation of concerns, allowing translators to reorder the sentence while you retain full control over the linkâs behavior in your code. Bridging the Context Gap: Empowering Translators for Success Even with a perfect key naming convention, the single greatest threat to translation quality remains the void of context . Professional translators are linguistic experts, not mind readers. A successful internationalization workflow is not just about extracting strings; it is about exporting context. The Tooling Revolution: From Guesswork to Certainty While good naming and comments are essential, the most comprehensive solution lies in a modern Translation Management System (TMS) . These platforms are purpose built to serve as a central hub for your entire localization workflow, with a primary focus on delivering rich context. Key features include in context editors, screenshot attachments, translation memory and term bases. Bringing Context Directly Into the Code The deepest integrations go a step further, closing the gap between the developerâs editor and the translatorâs tool. For example, the tight bond between and its creatorâs TMS, , enables a workflow that embeds context provision directly into the development process. Traditionally, a developer would add a key in the code, then add the default value in a JSON file, and then perhaps go to a separate system to add a comment for the translator. Modern integrations streamline this into a single, frictionless action right in the code: This elegant approach solves multiple problems at once. The developer provides crucial context at the moment of creation, when itâs top of mind. The âwrite it twiceâ friction of structured keys is dramatically reduced, and the translator receives a rich contextual package automatically (i.e. via the saveMissing feature). The debate is no longer solely about the keyâs name but about the entire localization context pipeline , which a modern toolchain can fully automate. A Unified Strategy: Your Teamâs Checklist â
Synthesizing these principles, here is a recommended framework for modern applications. It is a hybrid approach that champions structured keys as the default, backed by clear conventions and deep integration with your toolchain. 1. Default to Structured (Semantic) Keys. They offer the best balance of maintainability, scalability, and clarity. 2. Enforce a âDonât Reuseâ Policy. Create a unique key for every unique instance of a string. Make exceptions only for a strictly governed namespace (e.g., country names, months). 3. Mandate a Translation Management System (TMS). For any serious project, a TMS like is essential infrastru
40cture. It bridges the context gap with features like in context editors, screenshots, translation memory, and glossaries, making the structured key approach truly powerful. 4. Integrate Your Toolchain. Use modern library features like the i18next Selector API etc. Automate hygiene checks in your CI\/CD pipeline to find and remove unused keys. Use this checklist to define and document your teamâs strategy: Casing Convention: camelCase or snake case? (Be consistent). Namespace Strategy: By feature\/domain? Nesting Depth: Max 2â3 levels? Reuse Policy: Unique keys by default? Namespace Governance: What are the explicit, documented rules for adding new keys to it? Context Provisioning: How will you provide context to translators? Leverage tight integrations like the backend to allow developers to pass descriptions directly from their code using options like . Complex Content Handling: How will you handle plurals\/rich text? Maintenance Process: How will you audit orphaned keys? (find unused translations)."},{"slug":"focus-view-poll-with-vaultrice","title":"Building Locize Together: We Need Your Feedback on the Focus View","description":"We added an in-app poll to better understand how you use Focus View vs Global View. Vote inside Locize and help shape the future of the Focus View.","date":"2025-08-27","category":"Company","thumbnail":"\/img\/blog\/focus-view-poll-with-vaultrice\/locize-focus-view-poll.jpg","readTime":"2 min read","searchText":"title: 'Building Locize Together: We Need Your Feedback on the Focus View', description: 'We added an in app poll to better understand how you use Focus View vs Global View. Vote inside Locize and help shape the future of the Focus View.', date: '2025 08 27', thumbnail: '\/img\/blog\/focus view poll with vaultrice\/locize focus view poll.jpg', image: '\/img\/blog\/focus view poll with vaultrice\/locize focus view poll.jpg', category: 'Company', tags: ['localization', 'company'] At Locize, our mission is to provide the most efficient and developer friendly localization workflow possible. A core part of that mission is evolving the platform based on how you, our community, actually work. Your feedback is the most critical tool we have for making informed decisions about the future of the product. Today, weâre asking for your direct input on a specific and important feature: the Focus View . A Little History: The âWhyâ Behind the Focus View The Focus View was designed to provide a distraction free environment for translating longer content. By hiding the broader context of the Global View, it allows translators to concentrate solely on the segment at hand, which can be incredibly helpful for complex, descriptive texts. At the beginning, the Focus View had more features compared to the Global View. Over time, weâve received a wide range of anecdotal feedback. Some teams have integrated it deeply into their workflow and prefer it for its simplicity. Others find themselves exclusively using the power and context of the Global View. To move forward, we need to go beyond anecdotes and gather clear, quantitative data from everyone. Cast Your Vote: A New Poll Inside Locize To make this process easy and transparent, weâve added a new poll directly within the Locize UI. When you log in, you will be prompted to share your opinion on the Focus View. The poll includes several options. For those who are unfamiliar, the Focus View is the translation mode that presents one key at a time, as seen below: How Weâre Gathering Your Feedback in Real Time You might notice that the poll results update instantly after you vote. Weâre excited to be one of the first platforms to use a new, secure component from our friends at Vaultrice for this feature. Their library allows us to build and deploy engaging, real time features like this with confidence and security. It makes the process of gathering your feedback a live, transparent, and collaborative experience. Whatâs Next? This poll will run for the next few weeks. After it closes, we will analyze the data and share the results, along with our decision regarding the future of the Focus View, in a follow up blog post. Your participation is invaluable. Please take a moment the next time you log in to cast your vote and help us build a better Locize for everyone."},{"slug":"what-is-software-localization","title":"What is Software Localization?","description":"Software localization is the process of adapting a software product (language, UX, formats, and cultural expectations) for each target market. It is different from translation (which only converts words) and from internationalization (which prepares the code for any language). Here's how it works, and how to implement it.","date":"2025-08-26","category":"Guides","thumbnail":"\/img\/blog\/what-is-software-localization\/software-localization.webp","readTime":"8 min read","searchText":"hideCta: true, title: 'What is Software Localization?', description: \"Software localization is the process of adapting a software product (language, UX, formats, and cultural expectations) for each target market. It is different from translation (which only converts words) and from internationalization (which prepares the code for any language). Here's how it works, and how to implement it.\", date: '2025 08 26', thumbnail: '\/img\/blog\/what is software localization\/software localization.webp', image: '\/img\/blog\/what is software localization\/software localization.webp', category: 'Guides', tags: ['localization', 'guides', 'basics'], faq: [ q: 'What is software localization?', a: 'Software localization is the process of adapting a software product for a specific language and market. It goes beyond translating text: it adapts UI layout, date and number formats, currencies, images, gestures, and reading direction (LTR\/RTL) so the product feels native to its target audience. Localization is what comes after internationalization (i18n), which is the engineering work of preparing the code to supp
40ort any language.' , q: 'What is the difference between software localization and translation?', a: 'Translation converts text from one language to another. Software localization adapts the entire product: text plus formats (date, time, currency, number), images, colors, layout, RTL support, legal compliance, and cultural references. Translation makes the words understandable; localization makes the product feel native. Translation is one part of localization.' , q: 'What is the difference between software localization and internationalization (i18n)?', a: 'Internationalization (i18n) is the engineering work that prepares software so it can support any language: extracting strings into resource files, using locale aware formatting (Intl), supporting Unicode, handling pluralization, and accommodating RTL layouts. Localization (l10n) is the per market adaptation that follows: translating strings, adapting images and currencies, complying with local laws. i18n always comes first; l10n is impossible without it.' , q: 'What is the difference between software localization and website localization?', a: 'They overlap heavily. Website localization is software localization applied specifically to websites: content, layout, SEO, and regional metadata. Software localization is the broader category and includes desktop apps, mobile apps, SaaS products, video games, and embedded systems. Many websites are technically software (single page apps, SaaS dashboards), so the same i18n \/ TMS \/ CDN tooling applies to both.' , q: 'Why is software localization important?', a: 'CSA Research found that 40% of consumers will never buy from a website not in their native language, and 75% are more likely to repurchase if support is in their language. Localized software materially increases conversion, reduces support load, expands the addressable market, and builds trust. For most products targeting more than one country, localization is the difference between being usable and being irrelevant.' , q: 'How do I localize software?', a: 'A typical workflow: (1) prepare the codebase with internationalization (extract strings, use locale aware formatting, support Unicode and RTL); (2) choose target languages and markets; (3) translate, ideally using a translation management system (TMS) with translation memory and glossary; (4) adapt images, currencies, and cultural references; (5) test in every locale, including layout under longer translated text; (6) ship and maintain. Treat localization as a continuous process, not a one time release task.' , q: 'Do I need professional translators or is machine translation enough?', a: 'Machine translation (DeepL, Google Translate, modern AI) is good for general comprehension and first drafts but typically falls short on idiomatic, technical, marketing, and culturally sensitive content. The current best practice is hybrid: machine translation produces the first draft, human translators or post editors review for accuracy, tone, and brand voice. A translation management system makes this hybrid workflow practical at scale.' ] Software localization is the process of adapting a software product (text, UI, formats, and cultural expectations) for a specific language and market. It is broader than translation, which only converts words: localization also adapts date and currency formats, images and gestures, reading direction (LTR\/RTL), and legal compliance. It is also different from internationalization (i18n), which is the engineering work of preparing code to support any language. Localization is the market by market work that comes after i18n, and it is the difference between a product that is usable in a target market and one that feels foreign there. The global market for software localization generated $5.9 billion in revenue in 2022 and is projected to reach $15.6 billion by 2032, reflecting how essential it has become for any product targeting more than one country. Key facts What it is: adapting a software product (text + UI + formats + culture) for a target market vs translation: translation = words; localization = whole experience vs internationalization (i18n): i18n = engineering preparation; l10n = market by market adaptation. i18n always comes first What it covers: language, date\/time\/number\/currency formats, images, gestures, layout direction (LTR\/RTL), legal compliance Workflow types: waterfall (linear, batch) or continuous (parallel with development) Conversion impact: 40% of consumers never buy from a non native language site ( CSA Research ) Since the COVID 19 pandemic, as businesses shifted operations online and broadened their global reach, software localization has become even more important. It can be an expensive process, especially for small and medium sized businesses (SMEs) with tight budgets, and it takes time and resources to ensure high quality results. The rest of this guide explains how it works, what workflows exist, and how to implement it step by step. What is software localization? Software localization helps to adapt software to the language and circumstances of the target market while retaining its originality. That means itâs not only the text being adapted into the relevant language, but also the design and overall user experience (UX) being amended so it meets the needs of the target audience. While internationalization (i18n) is about developing a product to meet the demands of multiple cultures\/audiences, software localization is the deeper, market by market adaptation. For example, localizing software from English into Chinese isnât âjust translating wordingâ: the length of text and symbols can be entirely different, meaning the visual layout often needs to be adju
40sted to keep the UX consistent. Software localization also looks at: Resources and links Time and date formats Currency\/number formats Use of images or gestures (cultural appropriateness) Reading direction (LTR\/RTL) This makes the process complex and time consuming, but it can be a worthwhile investment. How does localization take place? Software can be localized in two core areas: internationalization first, then localization . Internationalization (design & development) The internationalization phase covers design and development, which means you should: Review your application framework to ensure it can support your requirements Plan your content (including how much space translated text will require) Incorporate localization needs into design, making localization more effective Code your strings to allow expansion when required Externalize any strings that have been prepared for localization Localization (translation + adaptation + testing) Once youâve successfully completed the internationalization phase, you begin the localization phase: Translate your content (ideally with a skilled translator) Review everything (accuracy, language quality, terminology) Copy translations into your software Test in every locale youâre targeting Once youâre confident the localized software works as designed and is free from bugs, it can be released. Waterfall vs continuous localization For localization of software there are different workflows. The traditional approach breaks down activities into linear sequential phases, the so called waterfall workflow. Continuous software localization combines software development and localization into one process so that developers work in parallel with the localization team from the very beginning: How does software localization differ from pure text translation? Pure text translation simply translates words from one language to another. Software localization takes a more comprehensive approach that includes cultural, regional, and functional adaptations to seamlessly integrate the product into the target market. This means that localization involves not only translating the text, but also adapting elements such as date formats, currencies, images, colors, and sometimes even the user interface. Cultural nuances are also taken into account, such as text length and reading direction. What are the risks of neglecting cultural adaptations during localization? Neglecting cultural adaptations can damage a brandâs image through unintended insults or misunderstandings and can lead to a loss of credibility and customer trust. Other dangers include legal problems due to non compliance with local regulations (like data protection laws), reduced user acceptance (higher abandonment rates, negative reviews), and an unsuccessful market entry. In extreme cases, massive reputation damage can occur if, for example, offensive gestures are published out of ignorance. What advantages does localization offer e commerce companies in particular? For e commerce companies, software localization facilitates access to new markets and increases conversion rates. Customers can shop in their native language and with culturally adapted content, which strengthens trust and increases willingness to buy. Software localization can also improve customer satisfaction through localized experiences (local payment methods, product descriptions), provide a competitive edge through better local SEO, and reduce returns. Do I need professional translators, or is machine translation enough? Whether you need a professional translator or whether machine translation tools (like Google Translate) are sufficient depends on the context. However, professional translators are usually essential for high quality software localization because they account for nuance, cultural context, and technical terminology. Machine translation is useful for quick, rough translations and scalability, but for complex content it can introduce tone issues, idiom mistakes, or cultural sensitivities. A common approach is using machine translation plus human post editing. Why localization of software is important Technology has connected the world: users can discover and use software globally. But understanding local expectations, language nuance, and cultural differences is crucial. Globalization gives software developers access to hundreds of millions of potential new customers , and to succeed, they need to offer a great user experience everywhere. Benefits include: Maximizing your sales: Success on an international scale becomes possible. Improving user experience: Users can clearly understand the product and get the most out of it. Staying ahead of competitors: Better experiences reduce churn and help attract more customers. Enhancing feedback: More engaged users means more feedback and more ideas. 9 steps to successfully implement software localization This guide walks through essential steps to implement software localization, whether youâre a startup or an enterprise. 1) Assessment and planning Choose the languages and markets you want to target. Check if your software is localization ready: Is your code dependable and bug free? Has y
40our main language UI been put into place? Is your text in the main language complete? Is your character encoding correct? 2) Translation Choose professional translators or translation software. Maintain context and accuracy. A professional translation management system can integrate translation services and improve delivery reliability while reducing manual errors. 3) Visual elements \/ graphic design Customize visuals to align with local preferences and respect cultural norms. Consider a style guide (branding, tone of voice, formality) to ensure consistency. 4) Compliance with legal and regulatory requirements Ensure compliance with local laws (data privacy, accessibility, industry regulations). Examples include GDPR and WCAG. 5) Testing Test localized software for functionality and display; fix issues. 6) Quality assurance (QA) Establish a QA process for localized versions and address found bugs. 7) Documentation and support Translate documentation and support materials; offer localized support. 8) Release and distribution Prepare localized versions for distribution; update marketing materials. 9) Maintenance and updates Regularly update localized versions while maintaining quality. Treat localization as an extension of software development. Instead of doing it only at the end, incorporate it throughout development. Use a localization platform Effective software localization is a large project. Using a localization management platform can simplify the process. Which one fits depends on your stack and workflow; we compare the main options in best localization platforms for developer teams. For example, React localization becomes much easier for developers when used with the i18next framework. You can use Locize to make the localization process easier across your company. Locize is a platform for localizing your website, mobile app, video game, or any other digital product. See how it applies to a software localization service or website localization services. Who needs software localization? If your software targets only one specific region, localization might not be required. But if you want to expand to new markets (now or later), localization is worth considering, and preparation during development helps. Software localization should be a major consideration for those working in e commerce, legal, or governmental sectors. Youâll definitely need it when: Your business plan targets multiple regions (or is region specific) Youâre developing your software right now (itâs easier to take care of localization at this stage) You have a many to many business model and are planning to grow exponentially These types of developers should take care of localization: Web developers Develop code for websites and web applications. SaaS or cloud developers Build cloud based applications for end users. Desktop application developers Write software applications that run natively on operating systems. Virtual reality application developers Create and test applications for VR\/metaverse. Mobile app developers Develop applications for smartphones and mobile devices. Video game developers Turn game concepts into playable reality. Blockchain developers Enable secure digital transactions by building blockchain systems. Integration developers Own the full life cycle of information systems. Connect your project directly to Locize and automatically send new ânon translatedâ parts of your application to Locize. You can use Locize CDN translations or translate within your web application directly. All newly generated keys in the reference language can also be automatically translated into target languages using machine translation. Frequently Asked Questions frontmatter.faq.map(( q, a ) = ( q a )) Now we want to turn it over to you: do you plan to invest in software localization? If you have questions, reach out at [email protected]. Register for a 14 day free trial: www.locize.app\/register"},{"slug":"i18next-typescript-selector-api","title":"The Game-Changer for i18next & TypeScript: Introducing the Selector API!","description":"Meet the i18next selector API: a new way to call t() with a function instead of a string key, unlocking autocomplete, go-to-definition, and better TypeScript performance on large translation sets.","date":"2025-08-20","category":"Guides","thumbnail":"\/img\/blog\/i18next-typescript-selector-api\/i18next-ts-selector-api.jpg","readTime":"3 min read","searchText":"hideCta: true, title: 'The Game Changer for i18next & TypeScript: Introducing the Selector API!', description: 'Meet the i18next selector API: a new way to call t() with a function instead of a string key, unlocking autocomplete, go to definition, and better TypeScript performance on large translation sets.', date: '2025 08 20', thumbnail: '\/img\/blog\/i18next typescript selector api\/i18next ts selector api.jpg', image: '\/img\/blog\/i18next typescript selector api\/i18next ts selector api.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'typescript'] A couple of years ago, we wrote about getting the most out of i18next with TypeScript. Today, that story gets a revolutionary new chapter. Weâre excited to announce a new feature that fundamentally improves the developer experience: the selector API . (New to the i18next stack? Start with our JavaScript localization guide for the React, Next.js, Vue, Angular, and Svelte quickstarts.) This feature, which closes a couple of long standing TypeScript issues, was born from a brilliant idea and a monumental effort by Andrew Jarrett . Itâs now available in the latest versions of i18next and react i18next, and itâs about to change the way you work with your translations. Why a Selector API? If youâve worked with a lot of translations with i18next and TypeScript, youâre maybe familiar with the challenges. String based keys like may lack autocompletion and can make navigating from your co
40de to the translation file tedious. The new selector API solves all of this. Instead of a string, you now pass a function to : This seemingly small change unlocks a massive suite of benefits. Unparalleled Developer Experience Autocompletion & discoverability: Your IDE now understands your translation structure. No more guessing keys or keeping a translation file open on a second monitor. âGo to definitionâ just works: Jump from a translationâs usage in code directly to its definition in your resource file. No more âdoom scrollingâ: Explore your translations one level at a time, making it effortless to find what you need, even in huge projects. Preserved JSDoc comments: Comments\/annotations youâve written for translations can show up right at the call site for immediate context. Type Level Performance (Finally) ð A major pain point for projects with large translation files was performance. The type level overhead could slow down IDEs to a crawl and even crash the TypeScript compiler. The selector API tackles this by changing how types are computed. With , you should see improved type level performance. For massive projects, is a game changer. This means i18next can handle arbitrarily large translation sets with snappy IDE performance and without build time type errors. How to Get Started Ready to upgrade? Hereâs what you need to know. 1. Enable the Feature In your TypeScript i18next configuration, add the option: 2. Migrate Your Code (The Easy Way) The best part: thereâs a codemod to automate the migration for you. Andrew Jarrett built to handle the syntax changes automatically. If your co
40debase is large, using the codemod is the smoothest way to transition. 3. Manual Migration Guide If you prefer to migrate manually, here are the key changes to be aware of. Namespaces: the namespace is now an explicit option. Default values: now lives in the options object. Key fallbacks: instead of passing an array of keys, provide fallbacks via by calling again. A Massive Thank You to the Community This feature wouldnât have been possible without the passion and dedication of several key individuals. First and foremost, a massive thank you to Andrew Jarrett . He not only proposed the initial idea but also implemented the entire feature, wrote the codemod for migration, and updated the documentation. A special thanks also goes to Marco Pasqualetti , who provided extensive feedback and thoroughly tested the new API. And finally, thank you to the entire i18next community for your continued support. Update to the latest versions of and to give it a try."},{"slug":"translation-memory","title":"Translation memory - what is it and what can it do?","description":"What a translation memory (TM) is, how matching and fuzzy matches work, why it matters for localization, how it differs from a glossary, what it does not solve, how translation memory works with AI translation and coding agents in 2026, and how the Locize translation memory helps you translate faster and more consistently.","date":"2025-05-27","category":"Guides","thumbnail":"\/img\/blog\/translation-memory\/thumbnail.jpg","readTime":"9 min read","searchText":"title: 'Translation memory what is it and what can it do?', description: 'What a translation memory (TM) is, how matching and fuzzy matches work, why it matters for localization, how it differs from a glossary, what it does not solve, how translation memory works with AI translation and coding agents in 2026, and how the Locize translation memory helps you translate faster and more consistently.', date: '2025 05 27', updated: '2026 09 09', thumbnail: '\/img\/blog\/translation memory\/thumbnail.jpg', image: '\/img\/blog\/translation memory\/title.jpg', category: 'Guides', tags: ['localization', 'guides', 'translation memory', 'basics', 'consistency', 'ai', 'translation management'], faq: [ q: 'What is a translation memory?', a: 'A translation memory (TM) is a database of previously translated segments, stored as pairs of source text and target text called translation units, that a translation tool searches while you translate so that identical or similar sentences can be reused instead of being translated again. It grows automatically with every confirmed translation and is the main reuse mechanism in professional translation.' , q: 'How does a translation memory work?', a: 'The text to be translated is split into segments, usually sentences or UI strings. Each segment is compared with the stored translation units. An exact match returns the stored translation directly; a fuzzy match returns a similar segment with a similarity score, for example 87%, and highlights the differences so only those need adapting. After the translator confirms the segment, the new pair is written back to the memory.' , q: 'What is the difference between a translation memory and a glossary?', a: 'A translation memory stores whole segments (sentences or strings) and is collected automatically as translation happens. A glossary (termbase) stores individual terms with their approved translation per language and is curated by people who decide how the product speaks. The memory answers \"have we translated this sentence before\"; the glossary answers \"which word do we use for this concept\". Consistent products use both.' , q: 'What is a fuzzy match in translation memory?', a: 'A fuzzy match is a stored segment that is similar but not identical to the one being translated, reported with a similarity percentage. A 100% match is identical; a 75% match shares most of its words with a different number, name or clause. Fuzzy matches are useful above roughly 70 to 75% similarity; below that, adapting the match usually costs more than translating from scratch.' , q: 'Does translation memory still matter with AI translation?', a: 'More, not less. A model request starts without memory, so a translation memory is what carries confirmed, reviewed translations into the next batch: exact matches are reused instead of re generated, fuzzy matches anchor the AI draft to wording that was already approved, and the same lookup is available to AI coding agents that draft translations inside code
40changes. The memory is the reuse layer; the model is the drafting layer.' , q: 'How do I keep a translation memory clean?', a: 'Only confirmed or reviewed translations should enter it, duplicates and obsolete segments should be removed or archived regularly, and a consistency check should flag segments that disagree with the memory. In a translation management system this happens where the translations live: reviewed values feed the memory, and a check surfaces the disagreements.' ] A translation memory (TM) is a database of previously translated segments, stored as pairs of source text and target text (translation units), that a translation tool searches while you translate so that identical or similar sentences can be reused instead of being translated again. Each stored pair is a finished, usually reviewed translation. For every new text, the system compares the segments with these units and immediately suggests identical or similar passages, which is how translators reuse proven wording, keep terminology consistent and shorten their processing time. In the following article, you can find out why the use of translation memory has many advantages, what exactly it is, how it differs from a glossary, what it does not solve, how it works together with AI translation and coding agents in 2026, and how translation memory management works in Locize. Key facts Unit of storage: a translation unit, one source segment paired with its target translation. Segments are sentences or, in software, individual UI strings. Two kinds of hit: an exact match (100%) returns the stored translation; a fuzzy match returns a similar segment with a similarity score and highlighted differences. Memory is not terminology: a TM stores sentences collected automatically; a glossary stores terms curated by people. Consistent products need both. With AI translation the memory matters more: every model request starts without memory, so the TM is what carries reviewed translations into the next batch, for human translators, automatic translation and coding agents alike. The importance of TM for localization Translation memory is at the heart of modern localization processes. Why? Because the database consistently exploits linguistic repetitions. Instead of translating sections from scratch again and again, TM reactivates existing solutions, an approach that increases quality, reduces costs, and helps meet deadlines. Software products repeat themselves more than most content: the same button labels, error messages and onboarding sentences recur across screens, releases and sister products, which is exactly where a memory pays off. How does translation memory work? When a document is opened, the translation software with translation memory breaks down the text into small units, usually individual sentences; in software localization the unit is typically a single UI string. Each new unit is automatically compared with the existing translation memory. Matched sentences: If a sentence matches a saved variant completely, the matching translation appears immediately. Similar sentences: If the sentence differs only slightly (for example by a different date or an additional word), translation memory points this out by indicating the similarity value, for example 87%. Deviations are highlighted in color so that only these passages need to be adapted. After confirmation, the new record pair is written directly to the memory. As a result, the database grows with each project and delivers even more hits in future, regardless of whether the source text comes from word processing files, websites, layout programs or application code. How much faster translators work with a memory depends on how repetitive the content is. On UI strings, release notes and documentation with many recurring sentences the reuse rate is high; on marketing copy written fresh every time it is low. Measure the match rate on your own content before promising a number. Translation memory and glossary: not the same thing A translation memory and a glossary are often mentioned in one breath, and a good editor shows both next to the segment, but they answer different questions. The memory stores segments , whole sentences or strings, collected automatically whenever a translation is saved; it answers \"have we translated this before, and how\". A glossary stores terms , single words or short phrases with their approved translation per language, curated by people who decide how the product speaks;
40 it answers \"which word do we use for this concept\". A memory full of reviewed sentences can still disagree on a term if the glossary is missing, and a perfect glossary does not save anyone from retranslating the same sentence. Consistent products use both, and a style guide on top for tone and formality. The advantages of translation memory Anyone who frequently translates similar content into several languages will benefit in particular from translation memory. The database turns previous translations into an immediately usable resource and thus provides several levers for efficiency and quality. Noticeably faster work: identical matches appear automatically, allowing translators to concentrate on genuinely new passages. Significantly lower costs: reused segments do not need to be translated or checked. This in turn reduces the cost of fees and proofreading. Seamless consistency: if every recurring sentence comes from the same source, terminology, style and tone remain consistent across all projects, even with multiple language service providers. Sustainable quality improvement: a curated TM only saves checked formulations, which reduces the error rate. Brand specifications can also be adhered to automatically. Centrally available knowledge base: everyone involved has access to the same database, regardless of whether it is marketing, legal or technology. This prevents data silos and duplication of work. Shorter time to market: less translation and post editing time speeds up releases, product launches and campaign launches. Consistent customer experience across products: when several products or tenants share a memory, the same sentence reads the same everywhere, which is what international customers notice. Focus on creativity: because routine passages are processed automatically, there is more capacity for stylistic subtleties, cultural adaptations and complex content. What a translation memory does not solve Terminology. A memory reuses sentences; it does not know that \"subscription\" must always be \"Abo\". That is the glossary's job, and a memory built before the glossary existed will happily suggest the old wording. Context. A 100% match for \"Open\" as a button is a wrong suggestion for \"Open\" as a status. Segment level reuse needs context, screenshots or key level information to be safe in UI work. Quality of what went in. A memory is only as good as the translations it was fed. Unreviewed machine output that enters the memory comes back as a confident 100% match next time; only confirmed translations should feed it. New content. Marketing copy, product names and anything written fresh has no match by definition. The memory speeds up the repetitive share of your content and leaves the creative share alone. Translation memory in 2026: AI translation and coding agents AI translation changed the economics of the first draft, and that made the memory more important rather than less. A model request starts without memory: it does not know how the same sentence was translated and reviewed last quarter. The translation memory is the reuse layer that carries those decisions forward. In practice the pieces stack: exact matches are reused instead of re generated, fuzzy matches anchor an AI draft to wording that was already approved, the glossary and style guide constrain terminology and tone, quality estimation scores what the model produced, and review confirms what enters the memory next. The same lookup now serves AI coding agents. An agent that drafts the German strings inside a code change can query the memory for similar source strings before inventing a translation, which is how the twelfth release stays consistent with the first. What breaks when agents skip that step, and the pattern that keeps them in the loop, is covered in when AI translations break. Translation memory: turbo for more speed, consistency and scope A professional translation memory turns every translated line into capital. It speeds up projects, reduces costs, keeps wording stable and shifts the focus away from routine copy and paste and towards stylistic and cultural fine tuning. Extra tip: establish clear rules for administration, organization and maintenance from the outset. For example, only include approved segments in TM, regularly clean up duplicates, and assign uniform metadata (topic, customer, version). This keeps the memory lean, reliable and valuable in the long term. How the intelligent translation memory from Locize works The Translation Memory (TM) from Locize is an intelligent translation support system that runs directly in the browser. As a result, it offers particularly high performance and fast results, as no requests need to be sent to the server for each lookup; the memory is loaded on startup and cached for 24 hours in the browser's IndexedDB. In contrast to traditional translation memories, the Locize solution allows multiple projects to be used as sources at the same time. This means that existing translations from different projects can be reused, which saves time and increases consistency across a product family. A special feature is that the search is not limited to exact language pairs. Similar language variants, such as British and American English ( \/ ), are also taken into account. Eac
40h hit in the TM is linked to the original project, which facilitates traceability and enables uniform translation across multiple projects. Configuration is very easy in the project settings under the \"EDITOR, TM\/MT\/AI, ORDERING\" tab in the \"Translation Memories\" section of the \"Cat settings\" card. There, users can specify which projects are to serve as the source for the translation memory. This service is activated by default in new projects, with the project itself selected as a source. When working with a segment, a corresponding tab appears on the right hand side of the editor where you can view and use the TM suggestions; a match is accepted with one click. Translation memory matches next to a segment in the Locize editor, alongside machine translation suggestions Two more pieces connect the memory to the rest of the workflow. The consistency check issue 220 flags a translation that disagrees with the memory, so drift is visible instead of silent. And the same memory is available to AI coding agents through the tool of the Locize MCP server, which returns exact and fuzzy matches for a source string so an agent reuses prior translations instead of inventing new ones. Learn more about our features and how to use it in our documentation. FAQ: Translation memory What is a translation memory? A database of previously translated segments, stored as source and target pairs called translation units, that a translation tool searches while you translate so identical or similar sentences are reused instead of translated again. It grows with every confirmed translation. How does a translation memory work? The text is split into segments (sentences or UI strings) and each is compared with the stored units. An exact match returns the stored translation; a fuzzy match returns a similar segment with a similarity score, for example 87%, and highlights the differences. Confirmed segments are written back to the memory. What is the difference between a translation memory and a glossary? The memory stores whole segments, collected automatically. The glossary stores individual terms with their approved translation per language, curated by people. The memory answers \"have we translated this sentence before\"; the glossary answers \"which word do we use for this concept\". Consistent products use both. What is a fuzzy match in translation memory? A stored segment that is similar but not identical to the one being translated, reported with a similarity percentage. Fuzzy matches are useful above roughly 70 to 75% similarity; below that, adapting the match usually costs more than translating from scratch. Does translation memory still matter with AI translation? More, not less. A model request starts without memory, so the TM carries reviewed translations into the next batch: exact matches are reused, fuzzy matches anchor the AI draft to approved wording, and coding agents can query the same memory before drafting. The memory is the reuse layer; the model is the drafting layer. How do I keep a translation memory clean? Let only confirmed or reviewed translations enter it, remove or archive duplicates and obsolete segments regularly, and run a consistency check that flags segments disagreeing with the memory. In a translation management system this happens where the translations live."},{"slug":"i18next-translations-not-loaded","title":"i18next Translations Not Loading? Fix 404s, CORS Issues & Misconfigurations Fast","description":"If your app shows raw i18next keys, this guide helps you quickly diagnose 404\/CORS issues, fix loadPath and server hosting, and optionally switch to the Locize backend.","date":"2025-05-05","category":"Guides","thumbnail":"\/img\/blog\/i18next-translations-not-loaded\/i18next-translations-not-loaded.jpg","readTime":"3 min read","searchText":"title: 'i18next Translations Not Loading? Fix 404s, CORS Issues & Misconfigurations Fast', description: 'If your app shows raw i18next keys, this guide helps you quickly diagnose 404\/CORS issues, fix loadPath and server hosting, and optionally switch to the Locize backend.', date: '2025 05 05', thumbnail: '\/img\/blog\/i18next translations not loaded\/i18next translations not loaded.jpg', image: '\/img\/blog\/i18next translations not loaded\/i18next translations not loaded.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'performance'] If your app is showing raw translation keys instead of real text, this guide will walk
40you through the most common reasons, and how to fix them quickly. Modern JavaScript applications rely heavily on internationalization (i18n) to reach a global audience. i18next, combined with the i18next http backend, makes it easy to load translation files over HTTP. Yet, one of the most common developer frustrations is watching their translation keys (like ) appear instead of the translated text. In this article, youâll learn: 1. Why translation files sometimes fail to load 2. How to diagnose file loading errors quickly 3. What you need to configure, step by step 4. An alternative backend that sidesteps these issues entirely Letâs dive in. Why translation files arenât loading No matter how carefully you write your translation JSON, if the browser canât fetch it, will return the raw key. Here are the top culprits. misconfiguration By default, tries to fetch . If your files live under or on a CDN, that path probably wonât exist, resulting in 404s. Server setup doesnât serve JSON Whether youâre on Next.js, Express, or static hosting, you must explicitly serve translation files from the correct directory. CORS & cross origin requests If translation files are hosted on another domain (a CDN or API), missing CORS headers will block the request. Wrong language or namespace Requesting a missing namespace or an unsupported language code will also 404. Diagnosing translation file errors Before guessing at solutions, inspect the network and enable debug logs: Browser DevTools â Network tab â filter â.jsonâ: look for failed requests (status 404, 403, or CORS errors). Console logs: youâll see messages like . Step by step: Fixing your configuration 1. Put your files in the correct public folder For example: Next.js: place and . Next.js auto serves . Express: Static hosts (Netlify, Vercel, S3): ensure your build output includes the directory with JSON files. 2. Configure to match 3. Handle CORS (if needed) If you host JSON on : 4. Verify your namespaces & languages JSON files must match both and . If you use multiple namespaces: Depending on your integration (e.g. react i18next), check calls like . Alternative: i18next locize backend If configuring static files or dealing with CORS feels brittle, consider using i18next locize backend. It integrates with Locize (our translation management system), and can help with file loading, versioning, and CDN delivery, so you worry less about 404s or stale JSON. Benefits: Versioning & CDN: Locize hosts your JSON and delivers it via a fast CDN. No server config required: add keys in Locize; your app can fetch them. Context & collaboration: manage revisions, review, and keep the app in sync. Check out this demo video: Or sign up and try the free trial. Conclusion By carefully configuring your , ensuring your server serves JSON correctly, and handling CORS, you can eliminate the âraw keyâ problem with . And if you prefer a managed approach, try : it sidesteps many of these issues and adds collaboration features."},{"slug":"ai-translation-changes-things","title":"How AI Translation Changes the Industry","description":"How AI translation evolved from rules to neural networks, where it wins, where it fails, and why the future is a hybrid of AI speed and human review.","date":"2025-04-22","category":"Guides","thumbnail":"\/img\/blog\/ai-translation-changes-things\/ai-translation.webp","readTime":"14 min read","searchText":"title: 'How AI Translation Changes the Industry', description: 'How AI translation evolved from rules to neural networks, where it wins, where it fails, and why the future is a hybrid of AI speed and human review.', date: '2025 04 22', thumbnail: '\/img\/blog\/ai translation changes things\/ai translation.webp', image: '\/img\/blog\/ai translation changes things\/ai translation.webp', category: 'Guides', tags: ['localization', 'guides', 'ai'] Human language is inherently complex. It follows intricate rules, is full of exceptions, and is shaped by subtle nuances and cultural context. For a long time, it seemed unimaginable that machines could understand and process language meaningfully. But with advances in natural language processing (especially in AI translation), this belief is being challenged. AI translation uses machine learning and neural networks to automatically convert text from one language to another. Unlike older machine translation systems that relied on rule based or statistical approaches, todayâs AI driven solutions can learn from large datasets and improve over time. This not only increases translation speed but also boosts accuracy, scalability, and affordability. What Does AI Translation Mean? AI translation refers to the use of artificial intelligence (particularly deep learning and neural networks) to perform translations. The systems are designed to improve c
40ontinuously by analyzing large sets of multilingual content and adapting based on human feedback. In practice, this means: Higher quality results over time More contextual translations Flexibility across use cases, from casual chats to technical documentation These systems are now part of a more advanced evolution of traditional machine translation. Tools like DeepL, Google Translate, and services integrated with Locize offer solutions that blend automation with real world usability. How AI Translation Works: From Rules to Neural Networks The history of AI translation is characterized by several technological development steps. In the 1950s, the first rule based systems were created, which were based on manually defined grammar structures and bilingual dictionaries. However, their performance remained limited: language is difficult to force into fixed rules, as it relies heavily on context and shades of meaning. In the 1990s, statistical machine translation (SMT) ushered in a new era. It used large quantities of bilingual texts to calculate probabilities for word and phrase combinations. This made it possible to generate translations based on frequently occurring patterns, a significant advance over rigid sets of rules. Nevertheless, SMT remained prone to errors, especially when dealing with idiomatic expressions, rare terms, or complex contexts. The transition to neural machine translation (NMT) from around 2015 marked a real turning point. Neural networks make it possible to analyze not just individual words, but entire sentences or paragraphs in context. This makes it possible to produce translations that appear much more natural and coherent. The systems take the context into account and are guided by patterns that they have learned from extensive training data. The key advantages of modern NMT systems include: Context related translation of entire sentences instead of isolated words Coherence in the text flow, even across sentence boundaries Adaptability through fine tuning, e.g. for specialist areas such as medicine, law, or technology Learning ability through real time feedback AI translation systems evolved through several phases: 1. Rule based MT (1950sâ1990s): Manual grammar rules and dictionaries 2. Statistical MT (1990sâ2015): Probabilistic models learned from bilingual corpora 3. Neural MT (2015âtoday): Deep learning with full sentence\/context understanding In particular, the Transformer model), introduced by Google in 2017, has significantly improved the quality of machine translations. It enables particularly effective context processing and has established itself as the basis for many of todayâs translation systems. Modern AI translation is also based on artificial neural networks. The systems first convert spoken or written language into sequences of numbers. This is a prerequisite for computers to be able to process language. The translation process often follows the principle of an encoderâdecoder architecture. First, the encoder takes on the task of converting a sentence in the source language (e.g. German) into a mathematical representation. This is then interpreted by the decoder and transferred into the target language (e.g. Spanish). A simple example to illustrate this: The sentence âI have a catâ is converted by the system into the number sequence 251, 2134, 953, 4. From this, the model calculates a new sequence of numbers (such as 4356, 7654, 76, 5325) which is then output by the decoder as âtengo un gatoâ. Input: âIch habe eine Katzeâ â encoded as numeric vector Output: âtengo un gatoâ â decoder reconstructs output from encoded meaning Despite all the progress, one limitation remains: even the most advanced AI does not âunderstandâ language in the human sense. It works purely on the basis of probabilities. The statistically most probable result is output. As a result, words may be omitted or new content may be âhallucinatedâ that is not even present in the original text. These technical limitations are relevant when it comes to evaluating translation quality in direct comparison with human specialist translators. AI doesnât understand language. It generates likely translations based on statistical probability, which may result in omissions, hallucinations, or misinterpretations. Why AI Translation Is a Game Changer The use of AI translation has a number of clear advantages over traditional, particularly purely human translation methods. These include significantly higher speed, lower costs, the ability to scale large volumes of text, and consistent quality, especially for standardized or recurring content. More about it in this blog post: What is translation? High speed and scalability AI systems process large volumes of text in a very short time, far faster than human translators would be able to. Within seconds, thousands of product descriptions, website content, or other text forms can be translated simultaneously into several languages. This reaction speed is invaluable, especially for time critical applications such as live communication via chat or email. Whatâs more, AI translation is available around the clock and is not subject to fatigue. Cost efficiency with high text volumes Once an AI translation system has been set up or licensed, additional translations can be implemented with minimal additional effort. In contrast to human translation, there are no ongoing personnel costs. Practical experience and studies show that the costs per word can be reduced significantly depending on the application, and AI translation creates economic leeway that would be almost impossible to achieve with conventional means, especially for large volumes of text or limited budgets. Uniformity and terminological consistency A decisive advantage lies in the consistent use of terminology. Once the AI translation has learned how to translate a specific term, it applies this translation consistently and without stylistic deviations or careless mistakes. The high degree of reliability is particularly important in sensitive areas such as technical documentation, which requires precise configuration, for example through company specific glossaries or targeted training within the translation software environment. If the system is set up accordingly, it guarantees consistent language use throughout, regardless of daily form or stress, which can play a role with human translators. Permanent availability and robust performance AI translation is ready for use at any time. Systems require no pauses, make no typing errors, and deliver results on demand, whether for individual sentences or millions of text modules. Even with massive amounts of data, the processing time remains stable and grows only minimally with the volume, making it possible to integrate translations seamlessly into workflows. Examples range from the automated translation of incoming customer queries in customer service to the ongoing localization of social media content. The use of modern software localization tools also makes it possible to efficie
40ntly adapt complex applications for international markets, including user interfaces, help content, and system messages. With Locize, you can integrate automatic translation directly into your CI\/CD process. New keys (via i18next , CLI, or API) are translated instantly and marked as needing review . You can learn more about it in this post. Where AI Translation Is Used Customer support: Automated replies and knowledge base localization E commerce: Product listings and reviews translated instantly Internal docs: Translating technical manuals or SOPs across offices Software & apps: Real time multilingual UI\/UX updates using tools like Locize Example: At Networkme , developers use Locize to manage six web applications. Marketing teams translate copy without waiting on code releases, thanks to AI assisted workflows and real time editing. AI translation is already transforming day to day operations across industries, especially where multilingual communication is essential. Customer Service and Support AI translation helps companies overcome language barriers in real time. Support queries via email or chat can be automatically translated for the support team and back to the user. With Locize, FAQs and helpdesk articles can be localized and updated continuously without waiting on developers. Example: Companies like Withlocals and Wuxus use Locize to translate support platforms and customer facing portals with ease, enhancing user experience across languages. E commerce and Website Localization Product descriptions, customer reviews, and even UI strings can be instantly translated using AI. For time sensitive content updates, AI delivers speed while human reviewers ensure tone and branding stay intact. Example: carVertical uses Locize to manage vehicle report content in over 30 languages, enabling rapid market expansion with consistent messaging. Internal Communication and Documentation Multinational teams benefit from AI powered translation of project updates, onboarding materials, and policy documents. Platforms like Microsoft Teams already integrate this, but you can go further by using Locize to manage documentation in a centralized, reviewable way. Example: ke chain.com and Logiscool translate technical documentation and learning content using Locizeâs developer friendly APIs. Legal, Medical, and Technical Drafts For sensitive or complex material, AI provides a quick first draft, perfect for time saving. Post editing by professionals ensures the final output meets quality and regulatory requirements. Example: Geoimpact and Shift Cryptosecurity use Locize to manage regulated and sensitive translations in a streamlined workflow. Everyday Use Cases Social media teams use AI to monitor global brand mentions. Locize allows fast translation of posts and replies. Video conferencing tools integrate AI to provide live captions and multilingual subtitles. Example: Tontine Trust and Nazata Bio rely on Locize to update public facing platforms quickly, across multiple languages and content types. The rule: the simpler the structure, the more reliable the AI. For nuanced or high stakes content, human review remains essential. Real World Workflow: AI Translation with Locize A typical developer friendly setup might look like this: 1. Define translation keys in your codebase (e.g., with i18next) 2. Push them to Locize using , CLI, or API 3. Enable automatic AI translation in Locize (e.g., using OpenAI, DeepL, Gemini) 4. Keys are marked as needing review and filtered in the editor 5. Reviewers validate or correct translations in the Locize editor 6. Fetch translations via CDN\/API or bundle into your app This AI assisted, human perfected approach delivers speed without sacrificing quality. Bonus: You can use tags like or enable Locizeâs Review Workflow for formal approval stages. Man vs. machine: who translates more reliably? Despite considerable progress, AI translation is not yet on a par with the work of professional translators. In many cases, systems achieve a high level of formal quality and impress with their grammar and fluency. Particularly in the case of factual, clearly structured texts, AI now delivers results that at first glance can hardly be distinguished from human translations, but content related weaknesses become apparent where context, cultural nuances, or ambiguities play a role. Although AI systems analyze the context of individual words, they do not always interpret it c
40orrectly. For example, the German word âBandâ (depending on the context, music group, book series, or strip of fabric) can be interpreted incorrectly. A practical example: the phrase âdrive on the rightâ was automatically interpreted as a political statement, which completely distorted the meaning. Stylistic subtleties are another challenge. AI translation does not recognize target groups or tonality and often translates texts in a factually neutral style, regardless of whether it is marketing content, internal communication, or emotional messages. Humor, irony, or wordplay are regularly lost or rendered inappropriately. AI translation also reaches its limits in the creative field. Emotions, vivid language, or persuasive effects are only partially successful. An automatically generated advertising slogan often remains pale, while a human copywriter controls the linguistic effect in a targeted manner. The situation is similar with specialist legal or medical texts: although AI systems use terminology consistently, they lack a deeper understanding of subtleties that may be essential in the respective specialist context. It is particularly problematic with less widely used languages. Here, there is often a lack of sufficient training material, which has a noticeable impact on quality. While AI translation delivers good results for common language pairs, the gap remains noticeable for minority languages. All of this shows that AI is ideal for quick, initial drafts. However, it can only achieve the final level of quality in combination with human expertise. In practice, a hybrid model is therefore gaining acceptance: AI translation takes care of the initial translation, while humans fine tune the language and content. This produces high quality translations faster and more cost effectively than purely manual work, while maintaining the same level of quality. Current tools for AI translation Specialized AI translation systems such as Google Translate and DeepL are among the best known tools on the market. Google Translate has been around since 2006, while DeepL was developed from the Linguee database in 2017. In July 2024, DeepL was further optimized to make translations sound more natural, an indication that, despite progress, machine translations are not yet at the level of human language. Generative AI models such as ChatGPT, Gemini, or Perplexity are suitable for creative processes, research, or idea generation, but they are not specialized AI translation tools. Their results typically lag behind those of professional translation tools, especially for specialist texts, less common languages, or stylistically demanding content. The market is dominated by large tech providers as well as specialized platforms and open source initiatives. Here is a compact overview of key AI translation tools currently available: DeepL â High quality translations for European languages, excellent style Google Translate â Wide language coverage, strong real time support Microsoft Translator â Office\/Teams integration, Azure ecosystem Amazon Translate â Built for scalable, secure enterprise use Metaâs NLLB 200 â Covers 200 languages, supports low resource regions Open source â Projects like Opus MT, Marian NMT for on premise deployments What about AI translation and the law? There is no question that the use of AI translation raises legal and ethical issues that companies cannot ignore. Data protection is a particular focus. If personal or confidential information is processed via free online translators such as Google Translate or DeepL Free, there is a risk that this data will be used to train the AI or stored on servers. This could potentially make sensitive content public. For business applications, providers such as DeepL or Microsoft therefore also offer Pro versions with contractually guaranteed data protection. Companies should always check whether an order processing contract is necessary and, if necessary, anonymize the content. Security aspects such as potential hacker attacks or data leaks must also be considered, and copyright is another challenge in AI translation. Translations are only considered protectable works if they are the result of a human, creative effort. AI generated translations usually do not meet this requirement. In addition, the legal situation surrounding the training of AI models with copyright protected content remains unclear. Companies should therefore always respect the rights to the original text when publishing machine translated texts. In terms of liability, the question arises as to who is responsible for damages resulting from incorrect translations. It is currently assumed that responsibility lies with the user. Companies that use AI must check the results before they are published, so machine translation should not be used as the final version for sensitive content such as contracts, operating instructions, or legal texts. Post editing by qualified specialist translators is recommended in order to minimize risks. Ethical aspects must not be ignored either. AI models reproduce potential distortions from their training data. For example, cases have been reported in which gender neutral terms were translated stereotypically. This can result in unintentional discrimination. There is also the question of how the use of AI translation will change the profession of translator in the long term. Although technology is increasingly taking over routine tasks, complex, creative, or culturally sensitive translations will remain in human hands. It is important to shape the change fairly, for example through further training and transparent communication with end users. Particularly in industries with high quality standards, it should be clearly recognizable whether a translation has been produced by a machine or by a human professional. As long as legal standards such as those provided for in the EU AI Act are not yet in place, it is up to companies to ensure that AI translation is handled responsibly. This includes binding guidelines, quality assurance processes, and a critical look at the limits of machine systems. Future Trends in AI Translation AI translation is evolving rapidly. New models and use cases continue to shape the landscape. Generative language models (LLMs) are beginning to rival traditional NMT systems, providing surprisingly strong results due to their deep contextual understanding. Translation is increasingly becoming a background feature in broader AI ecosystems, what some call âtranslation as a feature.â Real time and multimodal translation is gaining traction. Tools like Skype Translator and Zoomâs captioning system already support live, multilingual communication. In the future, AI will translate spoken language, text, and images simultaneously, e.g., street signs in AR glasses or subtitles in video calls. Metaâs SeamlessM4T is a promising step in that direction. Expanding language coverage is also a top priority. Projects like NLLB 200 and Googleâs 1,000 language initiative aim to supp
40ort minority and endangered languages. Techniques like zero shot translation help models handle new languages with minimal data. AI systems will also improve at maintaining context across long documents and referencing external world knowledge, such as proper names. Translation will run invisibly in the background of platforms like YouTube, Reddit, or content management systems, using APIs as simple to call as cloud storage. As usage grows, quality standards become more important. ISO norms like DIN ISO 5060 are emerging to define benchmarks. Labels indicating whether a translation was AI generated or human reviewed will become common. The most likely scenario is a hybrid future: AI will handle routine tasks, while humans ensure tone, nuance, and cultural fit. Creative content like ads and literature will remain human led. The key to success lies in using AI not as a replacement, but as a powerful tool. Here are the main trends to watch: Generative models (LLMs): Translation becomes part of large language models with strong contextual understanding Real time and multimodality: Translations in conversations, text, images, and speech simultaneously Expanded language coverage: Focus on minority languages and dialects through new training methods Context processing: Consistent translations across entire documents and thematic contexts Invisible integration: Translation as a background service in platforms, apps, and CMS systems Quality standards and norms: Certifications and objective evaluation procedures for AI translations Hybrid working model: Combination of AI efficiency and human control for the best possible quality"},{"slug":"i18next-locize-ai-human","title":"Supercharging Your Localization: Combining Your Framework (like i18next), Locize, AI, Automation, and Human Expertise","description":"A practical workflow to combine i18n, Locize, AI translation, automation, and human review to ship high-quality localization faster.","date":"2025-04-14","category":"Guides","thumbnail":"\/img\/blog\/i18next-locize-ai-human\/i18next-locize-ai-human.jpg","readTime":"7 min read","searchText":"title: 'Supercharging Your Localization: Combining Your Framework (like i18next), Locize, AI, Automation, and Human Expertise', description: 'A practical workflow to combine i18n, Locize, AI translation, automation, and human review to ship high quality localization faster.', date: '2025 04 14', thumbnail: '\/img\/blog\/i18next locize ai human\/i18next locize ai human.jpg', image: '\/img\/blog\/i18next locize ai human\/i18next locize ai human.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'ai'] Localization is crucial for reaching a global audience, but it often presents a challenge: how do you translate quickly and cost effectively without sacrificing quality? Manually translating everything takes time, while relying solely on raw machine translation can lead to awkward phrasing, inaccuracies, and a loss of brand voice. What if you could automate the initial steps and focus human effort where it matters most? This post outlines a powerful workflow that combines your chosen internationalization setup, the Locize localization management platform, the speed and automation of AI translation, and the essential oversight of human reviewers. Weâll show you how to: 1. Get your translation keys into Locize (optimally with i18next, but flexible for any setup). 2. Use Locizeâs AI features, including Automatic Machine Translation , to get initial translations quickly and continuously (learn more about AI features). 3. Leverage Locizeâs tools (like the needs review filter, tags, and review proposals) to efficiently review and refine those AI generated translations. This âAI assisted, human perfectedâ approach helps you accelerate localization while maintaining high standards. Prerequisites: Getting Your Keys into Locize Before diving into the AI and review parts, you need your translation keys (segments) available in your Locize project. How you get them there depends on your development setup. The optimal i18next experience: If your application uses the i18next framework, you get the most seamless developer experience. By using integration libraries like in combination with the option, new keys found during development can be automatically sent to your Locize project, and translations can be fetched directly. This is the setup shown in this starter project and detailed in our setup guide (How to easily add i18n to your software). Using other i18n frameworks or manual setups: You donât have to use i18next! Locize works effectively with any internationalization approach. The key requirement is simply to get your source language keys into your Locize project. If youâre not using a direct integration like , you can easily upload or sync your keys using: Locize CLI: The command line interface is perfect for integrating with build processes. Use commands like (to upload source files) or (to add only keys that donât exist in Locize yet). Locize API: For more custom integrations, you can directly use the Locize REST API, particularly the endpoint for adding missing translations. Manual upload: You can always upload translation files (like JSON, YAML, XLIFF, etc.) directly through the Locize user interface. Regardless of how your keys arrive, once they are in y
40our Locize project, youâre ready to leverage the AI translation and review workflows described below. You also need a Locize project set up. Step 1: Automate or Trigger Initial AI Translations Getting that first draft translation is where AI significantly speeds things up. Locize offers powerful options here. Option A: Continuous automatic translation (recommended for new keys) For truly seamless localization, enable Locizeâs Automatic Machine Translation workflow . How it works: Once configured, Locize automatically detects when new keys (segments) are added to your source language. It then sends these new keys to your chosen machine translation service and adds the translations to your specified target languages. Benefit: This âset and forgetâ approach ensures that new content gets an initial translation almost immediately, without manual intervention. Itâs ideal for projects with ongoing development. Learn more: Locize docs â Automatic Translation Workflow You can choose from several generative AI services, like OpenAI, Gemini, Mistral AI, Lara, etc. Simply bring your own API key for your desired service and youâre good to go. Optionally, you can define custom context, etc. Option B: Manually triggering AI translation If you prefer more control or need to translate existing keys in bulk, you can manually trigger the AI translation. 1. Navigate to Locize: Open your project in the Locize interface. 2. Select keys & languages: Identify the keys (segments) that need translation and the target languages (for example, use the âuntranslatedâ filter). 3. Trigger AI translation: Initiate the AI translation process for the selected keys and languages. Both methods provide an instant baseline translation generated by AI, saving significant time compared to translating from scratch. Often, teams use the Automatic Workflow for new keys and manual triggers for specific bulk updates. You can also translate individual keys (segments) if you donât want to use the bulk actions. Step 2: The Crucial Ingredient Human Review AI translation, whether triggered automatically or manually, is impressive but not perfect. It might miss crucial context, misuse brand specific terminology, sound unnatural, or contain subtle errors. This is where human expertise becomes essential. Reviewing AI generated translations is key to ensuring quality, accuracy, and brand consistency. Locize provides several mechanisms to streamline this review process. Reviewing AI Translations Efficiently in Locize Instead of manually checking every single translation, Locize helps you focus your review efforts. When using AI (either manually triggered or via the automatic workflow), you can configure Locize to help identify these translations for review. 1. Using the needs review mark AI generated translations (from both manual triggers and the automatic workflow) are automatically marked as needing review. The value is live, the mark tells a person to look at it. Translators or reviewers can then easily filter the Locize editor to show only marked segments. How: In Locize, use the needs review filter (sub entry marked ) to display only marked segments. Learn more: Locize docs: values marked as needing review Workflow: Review each marked translation. If itâs accurate, confirm it (the check mark at the end of the row, or confirm all in the bulk actions). If it needs correction, edit it directly in Locize and save (which clears the mark). 2. Leveraging tags Tags offer another flexible way to manage the review process. You could manually apply a specific tag (e.g., , , ) to segments you think need to be verified in detail. How: Apply tags and filter the Locize view by the specific tag(s) youâre using for review. Workflow: Filter by the relevant tag, review the translations, and once reviewed and approved, remove the tag or replace it with an tag, for instance. Learn more about tags: Locize docs â Tags 3. Employing the review workflow For a more structured and formal review process, especially involving multiple reviewers, Locizeâs built in Review Workflow is ideal. How: Enable the review workflow for specific languages. Workflow: Each time a human translator modifies a translation, that translation is suggested as pending review. After having collected a couple of reviews, the person responsible may accept a pending review and only then will the translation actually be accepted. Learn more: Locize docs â Review Workflow Which method to choose? Needs review mark: Simple, built in, set automatically for machine output and on source changes, great for straightforward reviews. Tags: Highly flexible, good for custom workflows or marking specific types of translations. Review Workflow: Best for formal processes, multiple reviewers, and clear status tracking. You can even combine these methods. The Complete Workflow Summarized 1. Develop: Write your co
40de using your chosen i18n approach, defining translation keys. 2. Sync: New keys are pushed to your Locize project (automatically via i18next integration, or via CLI, API, or UI upload). 3. (Automated) AI translate: The Locize Automatic Translation Workflow detects new keys and gets initial AI translations, marking them as needing review (or tagging them). Alternatively, manually trigger AI for batches of keys. 4. Human review: Translators\/reviewers use Locize filters (needs review mark, tags) or the Review Workflow to easily find and check the AI generated translations. 5. Refine & approve: Reviewers correct and approve the translations directly in Locize. 6. Publish\/fetch: Your application fetches the final, reviewed translations from Locize (or you download them for deployment). Conclusion: Smarter, Faster, Automated Localization By integrating your development process with Locize, leveraging automated AI translation workflows, and implementing targeted human review, you create a truly efficient localization powerhouse. You gain the speed and continuous delivery of AI while retaining the quality assurance that only human experts can provide. Locize acts as the central hub, seamlessly connecting your code, AI services, and your translation team with powerful features to manage the entire process, regardless of the specific i18n framework you use. Ready to give your localization process an AI and automation boost? Explore the AI Localization features and the Automatic Translation Workflow in Locize, and start building a smarter, faster workflow today."},{"slug":"i18n-next-app-router","title":"Simplifying i18next Setup in Next.js App Router","description":"A streamlined i18next setup for Next.js App Router: auto-detect the language from the URL on the client, pass it to server components via middleware headers, and access `t` without prop-drilling.","date":"2025-04-06","category":"Tutorials","thumbnail":"\/img\/blog\/i18n-next-app-router\/i18n-next-app-router.jpg","readTime":"4 min read","searchText":"title: 'Simplifying i18next Setup in Next.js App Router', description: \"A streamlined i18next setup for Next.js App Router: auto detect the language from the URL on the client, pass it to server components via middleware headers, and access without prop drilling.\", date: '2025 04 06', thumbnail: '\/img\/blog\/i18n next app router\/i18n next app router.jpg', image: '\/img\/blog\/i18n next app router\/i18n next app router.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'i18next', 'nextjs'] This post is an update to our earlier blog post on Next.js i18n with the App Directory. Here, weâll show you a streamlined way to set up i18next with Next.js that avoids the need to pass the locale or translation function ( ) around in every page. If youâre still picking a framework, see our JavaScript localization guide for side by side React, Next.js, Vue, Angular, and Svelte setups. â¹ï¸ Update (March 2026): If you'd rather not wire this up manually: next i18next v16 now provides exactly this developer experience out of the box for the App Router, with for Server Components, for Client Components, and built in middleware based locale detection. The manual setup below remains fully valid; it is essentially what v16 automates for you. Whatâs the Idea? The goal is to automatically detect the current language from the URL (whether youâre on a client or server page) so you donât have to manually pass down the language or translation function. We achieve this by: Extracting the language code from the URL using Next.js hooks for client pages. Using middleware on the server to set the language in a custom header. Relying on helper functions that provide the translation function ( ) on both client and server sides. For Client Pages We use the hook from Next.js to extract the language from the URL. For example: The language parameter is provided by our function: For Server Pages Since the hook isnât available on the server, we create a small workaround. We extend our middleware to extract the language from the URL and then store it in a custom header: Then, on the server side, we retrieve the language using: Letâs Walk Through the Setup File Breakdown 1. Settings ( ) This file contains the basic settings for i18next: 2. Middleware ( ) The middleware is responsible for detecting the language from cookies, the header, or directly from the URL. It also handles redirections if the language isnât in the URL and sets a custom header to pass the language info along to server side co
40de. 3. i18next Initialization ( ) This file sets up i18next with language detection, resource loading, and the React binding: 4. Server Side Helper ( ) This helper retrieves the translation function ( ) for server pages, reading the language from the custom header: 5. Client Side Helper ( ) On the client, this hook uses Next.jsâ to update the language based on the URL: 6. Page Examples Layout & Static Params Both server and client pages use a layout file to generate static parameters for each language: Server Side Page ( ) Hereâs how youâd use our server side helper: Client Side Page ( ) This is how youâd use the hook on a client rendered page: 7. Components: Footer and Link Footer Component Universal Base ( ) is unchanged, like in the previous blog post. Server Side ( ): Client Side ( ): Link Component Universal Base ( ): Server Side ( ): Client Side ( ): Bonus Connect to an awesome translation management system and manage your translations outside of your code. Letâs synchronize the translation files with Locize. This can be done on demand or on the CI server or before deploying the app. What to do to reach this step: 1. In Locize: signup at locize.app\/register and login 2. In Locize: create a new project 3. Install the locize cli ( ) 4. In Locize: add all your additional languages (this can also be done via API or using the migrate command of the locize cli) Use the locize cli Use the command to always download the published Locize translations to your local repository ( ) before bundling your app. example Alternatively, you can also use the command to synchronize your local repository ( ) with what is published on Locize. example Wrapping Up This streamlined setup makes working with multiple languages in Next.js easier than ever. By extracting the language directly from the URL and using custom headers and middleware, you no longer need to pass the locale or translation function manually. This keeps your code clean and DRY. For the complete code, check out the GitHub repository and if you prefer TypeScript, you can find the TypeScript version here. Happy coding!"},{"slug":"localization","title":"What Is Localization? Definition, Examples & How to Do It Right","description":"Localization (l10n) adapts products for target markets: language, culture, formats. Real examples from Airbnb, Netflix & McDonald's + a step-by-step playbook.","date":"2025-04-04","category":"Guides","thumbnail":"\/img\/blog\/localization\/localization.webp","readTime":"8 min read","searchText":"title: 'What Is Localization? Definition, Examples & How to Do It Right', description: \"Localization (l10n) adapts products for target markets: language, culture, formats. Real examples from Airbnb, Netflix & McDonald's + a step by step playbook.\", date: '2025 04 04', thumbnail: '\/img\/blog\/localization\/localization.webp', image: '\/img\/blog\/localization\/localization.webp', category: 'Guides', tags: ['localization', 'guides'], faq: [ q: 'What is localization?', a: 'Localization (l10n) is the process of adapting a product or service for a target market. It includes translating language, adapting cultural references, formatting numbers, dates and currencies, complying with local legal requirements, and adjusting the user interface (e.g. right to left layout for Arabic and Hebrew). The goal is for the product to feel native in the target market, not merely understandable.' , q: 'What is the difference between localization and translation?', a: 'Translation converts text from one language to another. Localization adapts the entire experience: text plus date and number formats, currency, address layouts, plurals, gendered language, images, layout direction, and legal references. Translation is one part of localization; localization is what makes a product feel native rather than translated.' , q: 'What is the difference between localization (l10n) and internationalization (i18n)?', a: 'Internationalization (i18n) is the engineering work that makes a product capable of being adapted (extracting strings, supporting multiple character sets, handling plurals, formatting dates per locale). Localization (l10n) is the per market adaptation work that uses the i18n foundation (actually translating the strings, providing cultural assets, complying with local regulations). i18n is done once; l10n is done per target market.' , q: 'What are the three types of localization?', a: \"Linguistic localization adapts language, idioms, and language specific elements like date and currency formats. Cultural localization adapts symbols, colors, references, and social norms to the target market's cultural expectations. Technical localization adapts to local technical requirements: character encodings, regulatory safety standards, power and unit conventions. Effective product localization usually requires all three.\" , q: 'When should I start thinking about localization?', a: 'Ideally during the product design phase. This is called
40internationalization (i18n): making your codebase capable of being adapted before you actually need to adapt it. Extracting all user facing strings, supporting multiple character sets, and handling plurals, dates, and currencies from the start makes later localization dramatically cheaper.' , q: 'Do I need localization even if I only ship in English?', a: 'Often yes. English speaking markets have meaningful differences: US, UK, and Australian English vary in spelling, vocabulary, and tone; date formats differ (12\/31\/2025 vs 31\/12\/2025); units differ (miles vs kilometers); idioms and cultural references rarely cross. For products targeting multiple English speaking regions, localization still applies; you are just localizing within a single language.' , q: 'Can localization actually increase revenue?', a: 'Yes. Research consistently shows that consumers prefer to buy in their own language: 40% will not purchase from a website not available in their language, and 75% are more likely to return when post sale support is in their language. For products in competitive markets, localization is often the difference between launching successfully and being ignored.' , q: 'What is an example of localization done well?', a: \"Airbnb localizes its platform for over 220 countries, adapting language, currency, content, and expectations per market. Netflix localizes its UI, subtitles, voice dubbing, and even original content per region. McDonald's adapts menus to local food preferences (vegetarian McAloo Tikki burgers in India, for example). The common thread is that the product feels designed for the local market, not translated into it.\" , q: 'What tools do teams use for localization?', a: 'Software teams typically combine an internationalization (i18n) library in the code (i18next, react i18next, vue i18n, or similar) with a translation management system (TMS), also called a localization platform, for the content side. The platform stores keys and translations centrally, gives translators an editor with translation memory, a glossary, and in context translation, adds machine and AI translation with human review, and delivers the current translations over a CDN so fixes go live without redeploying. Run continuously, this setup is called continuous localization.' , q: 'How do teams manage translation files and coordinate with translators without manual JSON editing?', a: 'That coordination layer is exactly what a translation management system provides. Instead of emailing JSON files around, developers keep writing code with translation keys, new and changed strings flow into the platform automatically, translators work in an editor with context and terminology support, reviewers approve what matters, and the application loads the results at runtime. Nobody edits translation files by hand, and the files in the repository (if you keep them there) are generated artifacts, not the workflow.' ] Localization (l10n) is the process of adapting a product or service for a target market: language, culture, formats, currencies, layout, and legal context. It goes beyond translation: translation converts the words; localization adapts the entire experience so the product feels native to the audience, not just understandable. For software and digital products, localization typically combines a translation management system, a glossary and style guide for terminology, and engineering work for date, number, and right to left formatting. Key facts What it is: adapting a product or service for a target market, going beyond translation vs translation: translation converts the words; localization adapts the entire experience vs i18n: i18n is the engineering preparation (make the app adaptable); l10n is the per market adaptation work What it covers: language, culture, currency, units, date formats, layout direction, legal compliance Who needs it: any business shipping to more than one market, language, or legal jurisdiction Business impact: 40% of consumers will not buy from a website not in their language; 75% prefer post sale support in their language What does localization mean? Adaptation includes, but goes beyond, translation. It ensures that every element of a product or service resonates naturally with the target culture. Key elements include: Language: Translating content with consideration for idioms, tone, and context. Content adaptation: Aligning imagery, colors, symbols, and references with cultural expectations. Regional preferences: Adjusting formats (date, currency, units, etc.) to local standards. UI\/UX adjustments: Modifying layout, reading direction (LTR vs. RTL), and screen structure. Legal compliance: Ensuring adherence to local laws, from GDPR to packaging regulations. Functional adaptation: Removing or adding features to suit market specific needs. Testing: Verifying linguistic accuracy and technical performance for every locale. Adapting content is important for both big companies and small businesses. This is especially true for startups and SMEs that want to grow internationally. According to research, 40% of consumers say they will never purchase from a website that isnât available in their native language. And 75% say theyâre more likely to return to a business if post sale support is in their own language. Real life examples of successful companies Business example: Airbnb As businesses become increasingly global, they're interacting with customers from all over the world. To succeed, they must adapt not just their language, but also their entire user experience to local markets. Localization is no longer optional; itâs a key part of any growth strategy. Airbnb is a great example of this. The company now operates in over 220 countries, and in each one, it adapts the platform to reflect local language, currency, content, and expectations. This makes users feel like the service was built just for them. Source: https:\/\/www.airbnb.com\/ Software example: Netflix Localization is also a vital strategy in the world of software development. Everything from user experience to overall design will need to be considered to ensure that customers are getting the very best experience. A good example of software localization is Netflix. The global streaming giant has become synonymous with efforts on both the translation side of things and on the developer side. The technology and processes that they utilize are translated and localized in every region, meaning the interface and apps change, as do the subtitles and voice dubbing of content. Even the films and TV shows they develop are localized for specific countries. Source: https:\/\/www.netflix.com\/ Check out our more real life examples on this page. What does localization mean in industry? Localization in industry refers to the adaptation of products, services or processes to the requirements and characteristics of a specific market or region. As with the answer to the general question âWhat is localization?â, the aim of localization in industry is to take into account aspects such as language, legal requirements, cultural differences and local standards in order to increase competitiveness and acceptance in the target market. Four examples of localization in industry: Product packaging: An international food manufacturer adapts the labels and packaging texts to the respective national language and legal labelling regulations of the target country. Safety standards: A packaging machine is adapted to the respective legal safety standards, such as the European CE marking or American OSHA regulations. Software customization: A machine manufacturer integrates various language settings and units of measurement into
40its control software so that operators from different countries can use the machines without any problems. Marketing campaigns: A car manufacturer develops different advertising campaigns for different markets, taking into account cultural characteristics as well as regional preferences and trends. What is an example of localization in business? When it comes to localization in business, the global fast food company McDonald's is a good example. McDonald's adapts its menus uncompromisingly to local tastes and eating habits in different countries. In India, for example, where many people do not eat beef for religious reasons, McDonald's offers special alternatives such as the âMcAloo Tikkiâ (a potato based vegetarian burger) or chicken burgers instead of the classic beef burger. In addition, advertising, packaging and even the design of the restaurants are geared towards the respective culture and the expectations of local customers. Localization allows the company to respond better to the needs of regional markets and be more successful. What are the three types of localization? Localization can basically be divided into three types. Linguistic localization refers to the adaptation of the language used for a product or service to the respective target language. In addition to dimensions and formats, this also includes currencies and other language specific elements. Only then will users perceive your offers as natural and understandable. With cultural localization , you adapt products, content or services to the cultural characteristics and expectations of a specific market. This includes, for example, taking symbolism, legal requirements and social norms into account. The aim is to ensure that your offer is accepted in the respective country or region. If we look at technical localization , we move within the framework of different standards, power voltages or climatic conditions or legal requirements in terms of safety and functionality. It is important to consider all three types of localization when developing products and services in order to increase user satisfaction in international markets. What are the goals? Effective adaptation is about more than access; itâs about building relationships . Here are the main goals: Enter new markets: Remove entry barriers and expand reach. Gain a competitive edge: Compete on equal footing with local businesses. Boost customer satisfaction: Offer a familiar, intuitive experience. Increase brand loyalty: Build trust through cultural relevance. Maximize profit: Tap into new audiences and increase conversion rates. How software teams handle localization today For a software product the interesting question is rarely \"should we localize\" but \"how do we keep localization running while we ship every week\". The pattern that has settled in looks like this: An i18n library in the code. A React team handling translations and multiple languages typically uses an internationalization framework such as i18next (with react i18next); Vue, Angular, and mobile stacks have their equivalents. The library replaces hardcoded text with translation keys and handles plurals, interpolation, and locale aware formatting. It solves the code side, not the content side. A translation management system for the content side. Managing translation files and coordinating with translators without manual JSON editing is the job of a translation management system (TMS), also called a localization platform. It stores keys and translations centrally, gives translators an editor with translation memory, a glossary, and in context translation (seeing the string in the live UI instead of a spreadsheet row), and tracks review state so you know which translations a human has actually checked. Continuous localization instead of batch handoffs. In a continuous localization workflow, new and changed strings flow from code to the platform automatically (through CLI extraction or runtime reporting), machine and AI translation produce the first draft, and human review focuses on the strings that matter. Translation runs in parallel with development instead of blocking the release. Delivery decoupled from deployment. Modern platforms double as a translation backend service with CDN delivery: the application loads its current translations at runtime, so a translation fix reaches users without redeploying code. This category of software localization tools goes by several names (translation management system, localization platform, translation automation platform) and the boundaries between them are blurry, but the job is the same: keep the text of a shipping product translated, reviewed, and consistent without turning localization into a manual coordination project. Related resources Language localization : adapting content for a specific language or region Localization strategy : defining how your business will localize across touchpoints Software localization : adapting UI, content, and backend for multi language support JavaScript localization : making web apps functional across languages and cultures Website localization : translating and adapting websites for global audiences Localization marketing : tailoring campaigns to cultural values and buying habits How to implement it â a step by step guide 1. Identify where it's needed: Not everything must be localized; start with high impact areas. 2. Research your target audience: Understand culture, language, habits, and legalities. 3. Bring in professionals: Work with native linguists, cultural consultants, or a localization partner. 4. Ensure quality assurance: Use local testers and conduct linguistic and functional QA. 5. Localize across content types: From websites to games, marketing materials to user manuals. ð¥ Watch our video to see how our software supports your localization workflow. Frequently Asked Questions frontmatter.faq.map(( q, a ) = ( q a )) Conclusion Localization is the difference between a product that works in a market and one that belongs there. Done well it pays for itself in trust, conversion, and customer loyalty; the brands that get it right do not localize as an afterthought, they treat it as part of the product. For software teams, that starts with internationalization (i18n) baked into the codebase and continues with a translation management system, glossaries, style guides, and a workflow that keeps translations in sync with product changes. If you are localizing a software product, Locize is a translation management system built by the team behind i18next, designed around AI\/MT for speed, CAT tool ergonomics for the editor, glossary and style guide for consistency, and human review for the final mile. Start a free trial or write to us at [email protected]."},{"slug":"react-intl-vs-react-i18next","title":"react-intl vs. react-i18next: The Ultimate Comparison for React Internationalization","description":"A side-by-side comparison of react-i18next and react-intl across syntax, pluralization, formatting, TypeScript support, performance, and ecosystem, plus how Locize can enhance both workflows.","date":"2025-04-02","category":"Guides","thumbnail":"\/img\/blog\/react-intl-vs-react-i18next\/react-intl-vs-react-i18next.jpg","readTime":"7 min read","searchText":"title: 'react intl vs. react i18next: The Ultimate Comparison for React Internationalization', description: 'A side by side comparison of react i18next and react intl across syntax, pluralization, formatting, TypeScript support, performance, and ecosystem, plus how Locize can enhance both workflows.', date: '2025 04 02', thumbnail: '\/img\/blog\/react intl vs react i18next\/react intl vs react i18next.jpg', image: '\/img\/blog\/react intl vs react i18next\/react intl vs react i18next.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'react', 'comparison'] In todayâs global market, delivering a user experience in multiple languages is essential. Whether youâre building a small application or an enterpriseâscale platform, robust internationalization (i18n) is a must. Two leading libraries in the React ecosystem, react i18next and react intl, offer powerful solutions for localization. (For the broader picture across frameworks beyond React, see our JavaScript localization guide.) In this article, we provide a detailed, sideâbyâside comparison of these libraries, covering aspects such as message formats, pluralization, interpolation, formatting capabilities, TypeScript integration, performance, community support, and maintenance. Finally, we discuss how modern translation management integrations can further enhance both libraries. Key insight: Regardless of whether you choose react i18next or react intl, integrating them with a modern translation management system streamlines your localization workflow and keeps your app up to date. 1. Why internationalization matters Over 60% of global users prefer content in their native language. A solid i18n strategy can: Boost engagement: Deliver content that resonates with users by using their language. Expand your market reach: Adapt your application easily for diverse regions. Improve ROI: Enhance user satisfaction and conversion rates by reducing localization friction. Internationalization isnât just about translation. Itâs about adapting your product to different cultural expectations, including dates, numbers, plural forms, and text direction. 2. Core philosophies react i18next: Flexibility, dynamism, and type safety react i18next is built on the mature i18next framework and follows the âlearn once, translate everywhereâ principle. Its ke
40y advantages include: Dynamic translation management: Supports dynamic language switching, lazy loading, and modular management via namespaces, so only the necessary translation files are loaded, optimizing performance for large scale applications. Rich plugin ecosystem: Offers plugins for language detection, caching, custom interpolation, and advanced pluralization (including interval pluralization). Its ecosystem is highly flexible, and you can extend its functionality with external translation management systems. Builtâin formatting using the Intl API: Recent i18next versions include builtâin formatting features that leverage the native ECMAScript Intl API. This allows you to pass formatting options directly in your translation strings (learn more in the i18next formatting documentation). Excellent TypeScript support: With robust type definitions and community tools to autoâgenerate types from your translation resources, react i18next helps catch errors at compile time and improves the development experience. Multiple integration patterns: Whether you prefer hooks, HigherâOrder Components (HOCs), render props, or the component, react i18next offers a flexible API to suit your coding style. react intl: Standardsâbased formatting and simplicity react intl is part of the FormatJS suite and is built around the ICU Message Format and ECMAScript Internationalization API. Its advantages include: Standardized message formatting: Uses ICU syntax for consistent formatting of dates, numbers, and plural forms, ideal for teams familiar with ICU based systems in other languages. Declarative localization components: Components like , , and allow you to embed localized content directly in your JSX, keeping your code clear and maintainable. Lean and focused: react intl focuses on robust formatting without the extra overhead for dynamic loading or language detection. Its static nature can be extended with external integrations if necessary. 3. Detailed comparison 3.1. Message format and syntax react intl Uses ICU Message Format by default: react i18next Supports simple JSON formats: And, if needed, ICU like formats (with i18next icu): Also the new Unicode MessageFormat 2 is supported (with i18next mf2): 3.2. Pluralization and interpolation react intl Employs ICU syntax for pluralization and interpolation, which is more verbose but highly standardized. react i18next Its flexible interpolation API supports nested values and interval pluralization in a concise JSON format, but also in ICU and MF2 format with additional plugins. 3.3. Formatting capabilities react intl Provides dedicated components that automatically format values: react i18next Includes builtâin formatting based on the Intl API. This lets you use in built formats or specify formatting options directly in your translation strings: 3.4. TypeScript integration react intl Provides builtâin TypeScript definitions. While effective, achieving full type safety in extensive projects might require additional tooling. react i18next Offers robust TypeScript support, including auto generated types from translation files. This helps catch errors at compile time and improves maintainability in large codebases. 3.5. Performance considerations Bundle size: react i18next (with i18next) and react intl both add roughly 18â19 KB gzipped. Rendering efficiency: Both libraries are optimized to minimize unnecessary reârenders: react i18next uses Reactâs hooks and context; react intl leverages its declarative component model. 3.6. Community, ecosystem, and maintenance react intl As part of the FormatJS suite, react intl is widely used in enterprise environments and maintained by a dedicated team, though its ecosystem isnât as expansive. react i18next Developed and maintained by the creators of i18next, it benefits from an extensive plugin ecosystem, active community support, and continuous updates. The creators of i18next are also the founders of Locize. 3.7. Flexibility and integration patterns react intl Uses a declarative approach with builtâin components, ensuring clean and readable code, albeit with less flexibility for dynamic scenarios. react i18next Provides multiple integration patterns (hooks, HOCs, render props, ) to adapt seamlessly to various codebase
40s. 4. Leveraging Locize to enhance your internationalization workflow Modern translation management systems can take your i18n strategy to the next level by automating translation updates and reducing manual overhead. Below, we illustrate how you can leverage such a system to extend both react intl and react i18next. 4.1. Enhancing react intl with Locize While react intl is inherently static, it can be enhanced using Locize to achieve dynamic translation loading and continuous localization: Dynamic translation fetching: Locize allows you to fetch translation files from a cloud based CDN, ensuring your application always uses the most current messages. Automatic key management: A Locize helper script can extend react intl components (like ) to check for missing keys or updated default messages and synchronize these changes with your translation catalog. Inâcontext editing: Translators can update texts directly on your live site by appending a query parameter (e.g., ), which activates an inâcontext editor. An example implementation can be found here. For Next.js App Router users on instead of , see the locize next intl example: same Locize integration, App Router shape. 4.2. Enhancing react i18next with Locize react i18next already supports dynamic translation loading and continuous updates. Integrating with a modern translation management system further streamlines your workflow: Lazy loading and namespaces: react i18next can load translation files on the fly, reducing initial bundle size by fetching only the necessary namespaces. Continuous localization: Locize integrations enable your translation updates to be pushed in real time, ensuring that your application always reflects the latest translations. TypeScript and plugin ecosystem: With its robust TypeScript support and extensive plugins, react i18next seamlessly integrates with external systems to provide an allâinâone localization solution. For more details, check out the react i18next integration guide and the How to Easily Add i18n to Your Software blog post. 5. Final recommendations: react i18next vs. react intl Feature react i18next react intl (enhanced with Locize) Dynamic translations â
Builtâin support via lazy loading & plugins â Achievable through Locize integration Lazy loading â
Yes â Not natively, but possible with Locize Message formatting â
Flexible (JSON or ICU or MessageFormat 2) â
Standardized (ICU MessageFormat) Namespaces â
Yes â Not by default (requires manual organization) TypeScript support â
Excellent; autoâgenerated types available â
Good; builtâin types Inâcontext editing â
Via Locize â
Via Locize When to choose react intl Standardized formatting: If you prefer using ICU MessageFormat for consistent formatting of dates, numbers, and plurals without relying on additional plugins. Lean and focused: Ideal for applications that require a lightweight solution focused primarily on formatting. Declarative approach: Its clear, declarative API is excellent for teams that value readability and simplicity. Extended capabilities via Locize: When enhanced with Locize, react intl can also support dynamic translation loading and continuous updates. When to choose react i18next Dynamic needs: Your application requires dynamic language switching, lazy loading, and granular control over translation files using namespaces. TypeScript and scalability: Its robust TypeScript support and modular architecture are ideal for large scale applications. Flexibility: The r
40ich plugin ecosystem and multiple integration patterns make it highly customizable. 6. Conclusion Internationalizing your React application is crucial for reaching a global audience. Both react i18next and react intl offer robust, featureârich solutions for managing translations and formatting content. react i18next excels with its dynamic translation management, rich plugin ecosystem, flexible API patterns, and excellent TypeScript support, making it ideal for modern, interactive applications. react intl provides a lean, standardsâbased approach with robust formatting via ICU MessageFormat. When extended with modern translation management integrations, it too can handle dynamic updates effectively. Our final recommendation: If your project demands a dynamic, flexible solution with advanced features like namespaces, lazy loading, and superior TypeScript support, react i18next is an excellent choice. Conversely, if you prefer a standardized, declarative solution focused on formatting and are comfortable enhancing its capabilities through external integrations, react intl is also a strong contender. Ultimately, the best choice depends on your projectâs specific requirements and development workflow. Both libraries can be enhanced with modern translation management systems to ensure a continuous, efficient localization process, delivering a truly internationalized user experience. Locize, built by the creators of i18next, works with both react intl and react i18next, and integrates with AI assistants via the MCP server. Happy coding, and hereâs to building a globally engaging application!"},{"slug":"you-will-need-to-pass-in-an-i18next-instance-by-using-initreacti18next","title":"Understanding and Fixing the âYou will need to pass in an i18next instance by using initReactI18nextâ Error","description":"Learn what this react-i18next error means, the most common causes (init\/config, Next.js, tests, multiple instances), and how to fix it reliably.","date":"2025-03-25","category":"Guides","thumbnail":"\/img\/blog\/you-will-need-to-pass-in-an-i18next-instance-by-using-initreacti18next\/initI18next.jpg","readTime":"4 min read","searchText":"title: 'Understanding and Fixing the âYou will need to pass in an i18next instance by using initReactI18nextâ Error', description: 'Learn what this react i18next error means, the most common causes (init\/config, Next.js, tests, multiple instances), and how to fix it reliably.', date: '2025 03 25', thumbnail: '\/img\/blog\/you will need to pass in an i18next instance by using initreacti18next\/initI18next.jpg', image: '\/img\/blog\/you will need to pass in an i18next instance by using initreacti18next\/initI18next.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'react'] When working with internationalization in React using and its React bindings ( ), you might encounter the following error message: react i18next:: You will need to pass in an i18next instance by using initReactI18next At first glance, this error may seem puzzling. It implies that the translation hook or component isnât receiving the necessary instance. In this post, weâll explore several common scenarios that trigger this error and discuss how to resolve them. What does the error mean? In essence, needs to have an instance that has been âenhancedâ with the React binding (via ). If this isnât set up correctly, hooks like or components like wonât work because they canât access the proper context. This is why the error instructs you to âpass in an i18next instance.â You can even see in the source code of âs hook that if no i18next instance is found (i.e. if it isnât provided via context or props), it warns: âuseTranslation: You will need to pass in an i18next instance by using initReactI18nextâ â react i18next\/src\/useTranslation.js at L41 Common scenarios and how to fix them 1. Missing or improper i18next initialization Problem: If you forget to import and initialize your i18n configuration at the root of your app, or you neglect to wrap your application in an , the i18next instance will not be available to your translation hooks. Solution: Make sure your i18n file calls: Then import this file in your topâlevel entry point (e.g. in your ). 2. Using the wrong hook Problem: In projects that use nextâi18next, you might be tempted to import the hook directly from . However, it is preferable to import the hook from instead. Why? wraps to provide additional serverâside rendering features. In some cases, the version of the hook might not correctly access the initialized instance. By using the hook from directly, you can bypass this issue and ensure that your components receive the proper context. Solution: Simply update your imports: 3. Issues in the testing environment Problem: When running unit tests (for example, with Jest), the instance may not be initialized before your component renders. This is especially common if you donât set up the provider in your test environment. Solution: Either import your i18n initialization file in your test setup (using Jestâs or ), or simply mock the translation hook. For example, add this to your Jest setup file: 4. Next.js and serverâside rendering issues Problem: In Next.js projects using , the error might appear if you use translation hooks inside components that are rendered outside the page level (for example, in layout components) without proper initialization (via ). Solution: Ensure that pages which use translations call in their or so that the i18next instance is populated with the correct namespaces. Also make sure you import from rather than directly from to prevent the issue described earlier. 5. Component library and multiple instances Problem: If youâre building a component library that uses and then importing that library into a host application, you might end up with multiple copies of or . This duplication can cause the context to be lost, and the hook wonât see the initialized instance. Solution: Use the I18nextProvider to supp
40ort multiple instances, like in this example. In your component library: Also a good idea is to propagate the event down to the instance of the component library: 6. Module system (ESM vs. CommonJS) issues Problem: Switching between ESM and CommonJS can sometimes cause subtle issues with module resolution, leading to a situation where your instance isnât correctly shared. Solution: Double check that your projectâs module settings (e.g. in package.json) and file extensions align with your bundlerâs expectations. In some cases, reverting to CommonJS or ensuring proper aliasing can resolve the issue. Conclusion The âYou will need to pass in an i18next instance by using initReactI18nextâ error usually indicates that your translation hook isnât receiving a properly initialized instance. Whether itâs due to missing providers, testing setup issues, bundler misconfiguration, or integration challenges in component libraries, the solution always involves ensuring that a single, correctly initialized instance is available in the React context. By following the fixes outlined above, you can diagnose your specific scenario and resolve the error, ensuring that your internationalization works smoothly across development, testing, and production environments. Happy coding, and happy translating! ð Do you want to unleash the full power of i18next? Check out this video."},{"slug":"how-to-use-i18next-t-outside-react-components","title":"How to Use i18next.t() Outside React Components (And Avoid Common Pitfalls)","description":"Learn why useTranslation() fails outside components, why i18next.t() can return keys before init, and the safest patterns to translate in services, utilities, and plain modules.","date":"2025-03-18","category":"Guides","thumbnail":"\/img\/blog\/how-to-use-i18next-t-outside-react-components\/i18next-t-function-outside.jpg","readTime":"2 min read","searchText":"title: 'How to Use i18next.t() Outside React Components (And Avoid Common Pitfalls)', description: 'Learn why useTranslation() fails outside components, why i18next.t() can return keys before init, and the safest patterns to translate in services, utilities, and plain modules.', date: '2025 03 18', thumbnail: '\/img\/blog\/how to use i18next t outside react components\/i18next t function outside.jpg', image: '\/img\/blog\/how to use i18next t outside react components\/i18next t function outside.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'react', 'how to'] âWhy Doesnât My Translation Work Outside of React?â Youâre building an internationalized React app, and everything works fine inside your components using the hook, like shown here, here or here. But then you need to translate text outside of React , maybe in a service, a utility function, or even inside an object. You try this: And then, boom. â âInvalid Hook Call.â Or maybe returns just the key string instead of the translation. So, whatâs going on? Letâs break it down and explore the right way to use outside React components. ð¥ The problem: React hooks canât be used outside components The hook is a React hook , which means it only works inside functional components. If you try to use it in a regular JavaScript module, youâll get an error. Thatâs because React hooks rely on Reactâs rendering cycle and canât function properly in plain JavaScript files. But what about this? This might work⦠or it might not. If i18next isnât fully initialized yet, could return the key itself instead of the translation. So how do we fix this? â
Solution 1: Ensure i18next is initialized before calling Since i18next may load translations asynchronously, you must ensure itâs ready before calling . One possible way to do this is to await the initialization promise : 1ï¸â£ Set up initialization in 2ï¸â£ Wait for initialization before using This ensures that translations will always work, even if theyâre requested before i18next is fully loaded. â
Solution 2: Pass as a function to non React code Another approach is to pass the function from a React component to the place where itâs needed. 1ï¸â£ Inside your React component 2ï¸â£ In your utility function By passing down from a React component, you avoid the issue of calling before initialization, keeping everything in sync with Reactâs lifecycle. â
Solution 3: Translating an object outside React What if you need to store translated values inside an object, like for error messages or API responses? You can update the object dynamically when the language changes. 1ï¸â£ Define a translatable object Now, whenever i18next loads or the language changes, the object updates automatically. ð Conclusion: The right solution depends on your use case If you need to use i18next outside of React, pick the right approach: â Ensure initialization before calling ( ). â Pass down from React if you want to keep it reactive. â Store translations in an object and update them when the language changes. No more returning keys instead of translations! ð Happy coding, and happy translating! ð Do you want to unleash the full power of i18next? Check out this video."},{"slug":"how-to-easily-add-i18n-to-your-software","title":"How to Easily Add Internationalization (i18n) to Your New Software Project","description":"A step-by-step guide to setting up i18next in a new React
40+ TypeScript project, with language detection, dynamic loading, and Locize for continuous localization.","date":"2025-03-03","category":"Guides","thumbnail":"\/img\/blog\/how-to-easily-add-i18n-to-your-software\/add-i18next.jpg","readTime":"11 min read","searchText":"title: 'How to Easily Add Internationalization (i18n) to Your New Software Project', description: 'A step by step guide to setting up i18next in a new React + TypeScript project, with language detection, dynamic loading, and Locize for continuous localization.', date: '2025 03 03', thumbnail: '\/img\/blog\/how to easily add i18n to your software\/add i18next.jpg', image: '\/img\/blog\/how to easily add i18n to your software\/add i18next.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'how to'] Starting a new software project? One crucial step that many developers overlook is internationalization (i18n). If you plan to support multiple languages, itâs best to integrate i18n from the beginning, because refactoring your code later can be time consuming and complex. In this guide, weâll walk you through a step by step setup for internationalization in a new project using i18next (one of the most popular i18n frameworks). By the end, youâll have a fully functional, scalable, and real time translation setup for your app. Table of contents 0. Why should you start internationalization early? 1. What is the best way to start with internationalization? Why choose i18next? 2. For which environment are you looking for an i18n solution? 3. Do you need a language detector for your environment? How to Detect a User's Language? When Is a Language Detector Not Necessary? 4. How do you want to load your translations? Do you want to bundle translations with your app? Do you want to load translations separately via HTTP? 5. Do you want to manage your translations with a Translation Management System? Why use a Translation Management System? How does Locize work? 6. Hands On: How to prepare the code? Step 0: Create a new React project Step 1: Install i18next and required packages Step 2: Set Up i18next Configuration Step 3: Create a new Locize project Step 4: Start to internationalize with i18next Step 5: Language switcher Step 6: Type safe translations Step 7: Add more languages Step 8: More fancy stuff ð𥳠Congratulations ðð 0. Why should you start internationalization early? Many developers delay i18n, thinking theyâll add it âlater.â However, starting early has key benefits: â
No need for major refactoring â Your code is ready for localization from day one. â
Easier testing â You can check how your app behaves in different languages early on. â
Better user experience â Serve global users with localized content right from launch. â
Powerful i18n features â Use automatic language detection, missing key handling, and more. Now, letâs dive into how to set up i18next to build a continuous localization workflow for your project. 1. What is the best way to start with internationalization? When adding internationalization to your project, the first decision is choosing the right i18n framework. A good i18n solution should be: â
Flexible â Works across different platforms and frameworks. â
Feature rich â Supports pluralization, interpolation, and context based translations. â
Scalable â Easy to manage as your app grows. Why choose i18next? For this guide, weâll use i18next , one of the most widely adopted i18n frameworks. Itâs a battle tested solution with: Support for multiple environments â Works in browsers, Node.js, React, React Native, and more. Powerful features â Provides automatic missing key handling, language detection, and async loading. Large ecosystem â Integrates seamlessly with localization tools like Locize for continuous translation updates. ð For a full list of supported platforms, check out the i18next documentation. ð Since i18next is a popular and flexible solution, weâll use it for our example setup. 2. For which environment are you looking for an i18n solution? Before setting up i18next, consider where youâre building your app. The setup may vary slightly depending on the platform: Web Apps (React, Vue, Angular, plain JavaScript) Mobile Apps (React Native, iOS, Android) Server Side (Node.js, Deno, serverless functions⦠In this article you can find some examples) ð To see i18nextâs supp
40orted frameworks, visit this page. Interested in server side web apps, like Next.js or Gatsby, etc? Then have a look at this article. ð For this guide, weâll focus on a React application using TypeScript. 3. Do you need a language detector for your environment? When implementing internationalization, your application needs a way to determine which language to use for each user. This can be done automatically based on various factors, such as browser settings, URL parameters, or stored user preferences. Using a language detector can help provide a better user experience by ensuring that users see the correct language without having to manually select it . How to Detect a User's Language? Different environments require different methods for detecting the userâs preferred language. i18next provides several plugins that handle language detection automatically: ð¹ For Web Browsers: Use i18next browser languageDetector Detects the language from the browser settings, URL query parameters, cookies, or localStorage. Ideal for React, Vue, Angular, and plain JavaScript web apps. ð¹ For HTTP Servers (Node.js, Express, Fastify, etc.): Use i18next http middleware Detects the language from request headers, cookies, or query parameters. Ideal for backend applications that serve localized content dynamically. ð¹ For Other Environments: React Native: Uses @os team\/i18next react native language detector. Electron Apps: The browser detector generally works well, but you can also use i18next electron language detector. Command line tools or scripts: In some cases, you might need to set the language based on system environment variables, like: i18next cli language detector For others have a look at: https:\/\/www.i18next.com\/overview\/plugins and utils language detector When Is a Language Detector Not Necessary? While language detection is useful, there are cases where you might not need it: â If your app only supports one language (no internationalization needed). â If the language is always determined by user settings (e.g., a user selects their preferred language in an account settings page). â If you're building a static site where translations are pre rendered based on different language versions. ð Since we are building a React application that runs in the browser, we will use i18next browser languageDetector to automatically detect and store the userâs language preferences. 4. How do you want to load your translations? After determining how to detect the userâs language, the next step is deciding how to provide translations to your app . There are multiple ways to do this, depending on your projectâs requirements. Do you want to bundle translations with your app? Bundling translations means including all language files inside your application, making them available immediately at runtime. There are different ways to handle this: ð¹ Adding translations on initialization â Load all translations inside your i18next configuration when initializing the library. (https:\/\/www.i18next.com\/how to\/add or load translations add on init) ð¹ Adding translations dynamically after initialization â Fetch translations when needed and add them at runtime. (https:\/\/www.i18next.com\/how to\/add or load translations add after init) ð¹ Lazy load in memory translations â Transform resources to an i18next backend. This means, you can also lazy load translations, for example when using webpack. (https:\/\/www.i18next.com\/how to\/add or load translations lazy load in memory translations) ð¹ Loading translations from the filesystem (server side apps) â Use local JSON files when running on a backend like Node.js or Deno. (https:\/\/github.com\/i18next\/i18next fs backend) This approach works well if your translations donât change often or if you need an offline capable application. However, it requires redeploying the app whenever translations are updated . Do you want to load translations separately via HTTP? Instead of bundling translations, you can load them dynamically from an external source using an HTTP backend. This allows for real time translation updates without redeploying your app. There are two main ways to serve translations over HTTP: 1. Load translations from your own server: Use i18next http backend to serve translation files from your backend or API. 2. Load translations from a professional CDN & TMS: Use i18next locize backend to manage translations in Locize, a powerful Translation Management System (TMS) that supports real time updates. ð¡ There are many other backend options available depending on your needs. You can find a full list of i18next backends (also non HTTP) here. ð For this tutorial, we will not bundle translations within the app. Instead, we will load them dynamically using i18next locize backend. This enables real time translation updates, making localization much more efficient. In the next section, weâll explore why using Locize is beneficial and how it simplifies the translation management process. 5. Do you want to manage your translations with a Translation Management System? Once your app is set up to load translations dynamically, the next step is deciding how to manage and update those translations efficie
40ntly . Instead of manually handling JSON files, a Translation Management System (TMS) can streamline the localization process. Why use a Translation Management System? Using a TMS like Locize provides several key benefits: â
No more redeployments â Update translations in real time without modifying your appâs code. â
Collaborate efficiently â Multiple translators can work on translations without needing access to the codebase. â
Automated translation workflows â Use machine translation or AI translation to speed up the process and manually refine translations where needed. â
Version control & rollback â Keep track of translation changes and restore previous versions if needed. â
Seamless integration with i18next â Since Locize was created by the same team as i18next, it offers native support for the framework. How does Locize work? Locize acts as a translation storage & delivery service . Instead of keeping translations inside your app, they are stored in Locize and fetched dynamically at runtime , if you want to. ð¹ Missing translations? Locize can automatically detect and store them, so you never forget to translate anything. ð¹ Need instant updates? Translations are fetched in real time without requiring a new deployment. ð¹ Multiple environments? Manage staging and production translations separately to avoid breaking changes. ð For this tutorial, we will: 1. Use Locize as our translation management system 2. Enable automatic detection of missing translations (so new keys are instantly added to Locize) 3. Use machine translation to generate initial translations automatically 4. Fetch translations dynamically using i18next locize backend 6. Hands On: How to prepare the code? Now that weâve decided on our internationalization strategy, itâs time to start coding! In this section, weâll set up a React project , configure i18next with Locize , and ensure that translations are loaded dynamically. Step 0: Create a new React project For this tutorial, weâll use Vite with TypeScript , as it provides a fast and modern development experience. Initialize the Project Run the following command to create a new React project using Vite: This sets up a React project with TypeScript. Step 1: Install i18next and required packages To integrate internationalization, we need to install the following packages: ð¹ i18next â The core internationalization framework. ð¹ react i18next â React bindings for i18next. ð¹ i18next browser languagedetector â Automatically detects the userâs preferred language. ð¹ i18next locize backend â Fetches translations from Locize in real time. ð¹ locize lastused â Updates last used timestamps on reference keys in Locize. (optional) ð¹ Locize â Handles integration with the In Context editor. (optional) ð¹ i18next resources for ts â Helps to transform resources for type safe i18next projects. (optional) ð¹ locize cli â Helps to download translations during dev for type safe translations. (optional) Install these dependencies: Step 2: Set Up i18next Configuration Now, letâs configure i18next to: â
Use Locize as the translation backend â
Automatically detect the userâs language â
Fallback to English if a translation is missing Create a new file: and add the following setup: In , import the configuration before rendering the app: Step 3: Create a new Locize project First you need to signup at Locize and login. Then create a new project in Locize and copy your project id and API key to your env files in your project. The API key is only used for the save missing and the last used functionality. The auto machine translation workflow is enabled by default for new projects; if you like, you can also configure a generative AI service. Step 4: Start to internationalize with i18next Import the useTranslation hook and try to use the resulting function to write some simple text: The first argument of the function is the i18n key, and the optional second argument can be some options or the default value. And use the Trans component for sections having some nested elements: By default i18next uses the translation namespace, but you can decide yourself how you want to structure the namespaces. On this page you can find more information about this topic. Now the translations will be loaded asynchronously, so make sure you wrap your app with a Suspense component to prevent this error: By visiting your appâs local host ( ), i18next will detect your new keys and send them to Locize: If the automatic machine translation workflow is enabled, the keys get automatically translated. But you can always manually translate the content. Step 5: Language switcher Currently, the i18next browser languageDetector plugin detects the browser language, but there is currently no nice way to manually switch the language. So create something like this: Or even better, fetch the available languages directly from Locize: Clicking one of these language buttons now calls the function of i18next and the new language code is stored in localStorage. So when you refresh the page it remembers the last used language: Step 6: Type safe translations Mastering i18next for type safe translations empowers TypeScript developers to unlock the full potential of their applications. By ensuring accurate localization, eliminating runtime errors, and leveraging the seamless integration between i18next and TypeScript, developers can create robust, localized applications that cater to diverse language preferences. At runtime we load the translation directly from the Locize CDN. So how do we get type safe translations during development? We create some npm scripts to help us: 1. Download the published translations (in reference language) to a temporary directory, e.g. 2. Create the appropriate interface definition file, e.g. 3. Final script: download, create interface and delete the temporary files, e.g. We now can just import that interface in our file: Thatâs it! The translations are separated from our code repository and at the same time we maintain type safety with the help of an interface. Step 7: Add more languages Since weâre fetching automatically all available languages directly from Locize, we can add new languages without having to adapt the code or redeploy our app. Just navigate to your Locize project and add a new language: Open the cat and translate everything with the bulk actions and click save: Now refresh your appâs page, and voilà : Step 8: More fancy stuff Thanks to the locize last used plugin, you'll be able to find and filter in Locize which keys are used or not used anymore. With the help of the Locize plugin, you'll be able to use your app within the Locize InContext Editor. Just add the query parameter in your appâs URL, then a popup will show up. Login to Locize and then: And thereâs a lot more you can do with Locize⦠For a sneak peek have a look at this video: ð§âð» The complete code for this React example can be found here. And feel free to have a look at this video that shows the whole hands on section. ð𥳠Congratulations ðð I hope youâve learned a few new things. So if you want to take your i18n topic to the next level, it's worth trying the localization management platform Locize. By using Locize, you directly support the future of i18next, as the founders of Locize are also the founders of i18next. ð"},{"slug":"localization-as-code","title":"Localization as Code: Integrating Translation Workflows into CI\/CD Pipelines","description":"Learn how to integrate localization into your CI\/CD pipeline by treating translation workflows and files like code, with practical examples and best practices.","date":"2025-02-26","category":"Guides","thumbnail":"\/img\/blog\/localization-as-code\/localization_as_code.webp","readTime":"4 min read","searchText":"title: 'Localization as Code: Integrating Translation Workflows into CI\/CD Pipelines', description: 'Learn how to integrate localization into your CI\/CD pipeline by treating translation workflows and files like code, with practical examples and best practices.', date: '2025 02 26', thumbnail: '\/img\/blog\/localization as code\/localization as code.webp', image: '\/img\/blog\/localization as code\/localization as code.webp', category: 'Guides', tags: ['localization', 'guides', 'workflow'] A Bundled Localization Approach: Integrating Translations into Your CI\/CD Pipeline Note: This approach is designed for customers who prefer to bundle and version their translation files as part of the build process, instead of using a fully âconnectedâ Locize approach (where translations are dynamically fetched from our CDN and can be updated without a redeploy). For a truly continuous localization experience, we recommend connecting your co
40de directly with the Locize CDN (see Modern Continuous Localization and Using the Locize CDN). However, if you have requirements such as hosting translations locally or concerns over confidential translation texts (see Confidentiality considerations), this CI\/CD integration approach is a very valid alternative. In todayâs global market, software teams must deliver applications that speak the language of every user, even as new features roll out continuously. Traditional localization methods, which treat translation as a post development add on, can slow down release cycles and create friction between development and translation teams. By integrating localization into your CI\/CD pipeline, you can treat translation files like any other piece of code, automating the extraction, review, and deployment of localized content. The evolution from manual to automated localization Historically, localization was handled in distinct phases: developers would freeze strings at the end of a sprint, export them, send them for translation, and then re import the updates. This âlocalization freezeâ led to delays and misaligned versions between code and translations. Todayâs agile teams are embracing âlocalization as code,â where translation workflows become an integral, automated part of the development process. Key insight: When translation is integrated with your CI\/CD pipeline, you can update or add translations as part of your regular build, ensuring that updates across multiple languages align with every new code commit. Integrating localization into your CI\/CD pipeline 1. Instrument your code for internationalization Begin by ensuring that your application is internationalized. For a connected Locize approach (where you fetch translations on the fly from our CDN), you might use the i18next locize backend, which enables dynamic updates and the âsave missingâ feature via our API. If you prefer to bundle translations with your app (hosting them locally), you can use alternatives such as i18next http backend or i18next resources to backend to load resource files directly from your local assets. For example, using : Note: The âsave missingâ feature (which automatically pushes new strings to Locize) is available only with or when you directly consume our API (Missing Translations API). 2. Automate string extraction & synchronization Modern TMS tools like Locize support automatic detection of missing strings. In development, you can use together with the âsave missingâ feature so that any new keys are automatically pushed to your translation dashboard. For production, you might opt to disable this dynamic feature and instead use (or another resource loading backend) to load pre downloaded, bundled translation files. Below is a code example that differentiates backend configuration by environment: Explanation: Development: Uses the Locize backend with âsave missingâ enabled to dynamically push new keys. Production: Uses the HTTP backend to load bundled translation files from a local path. 3. Integrate upload, sync, and download operations into CI\/CD Embedding localization commands directly into your CI\/CD workflow ensures that your app always packages the latest translation files. Depending on your preferred tooling, you have multiple options: GitHub Actions: Use our official GitHub Action for downloading translations (see Locize GitHub Action documentation). For example: CLI sync command: Alternatively, use the Locize CLI to synchronize translation files: This command downloads and synchronizes translations from Locize with your local repository (see the Locize CLI documentation for details). Best practices for implementation To ensure a smooth integration of localization into your CI\/CD pipeline, consider the following best practices: Use environment variables: Keep sensitive API keys secure by leveraging your CI\/CD systemâs secret management features. Automate localization testing: Integrate scripts into your pipeline that validate translation file formats and catch missing or inconsistent keys. Leverage built in versioning: L
40ocize natively manages multiple versions of your translations (Versioning documentation). Use this feature to maintain separate translation branches (e.g., âdevelopmentâ vs. âproductionâ) for more controlled deployments. Set up notifications: Configure Locizeâs notification options (Notifications documentation) so that your team stays up to date. This allows rapid iteration and quality control. Define automated workflows: Use your CI\/CD platform to trigger localization tasks only when needed (e.g., on pull requests to staging or production branches) to optimize resource usage and maintain stability. Conclusion Localization is no longer an afterthought: itâs an integral part of modern software development. By treating translation workflows as code and embedding them into your CI\/CD pipeline, you can achieve faster time to market, higher quality, and a seamless user experience for a global audience. While connecting your code directly with the Locize CDN is our recommended âconnectedâ approach for real continuous localization, this CI\/CD bundling strategy is ideal for customers who prefer to host translation files within their repository. This approach also addresses concerns like maintaining confidentiality of translation texts. Whether youâre a developer, tech lead, or head of software engineering, integrating localization into your development process is a strategic move that keeps you competitive in a multilingual world."},{"slug":"improve-i18next-usage","title":"8 Signs You Should Improve the Way You Use i18next (and How to Fix Them)","description":"Learn how to streamline your localization workflow by identifying and fixing common i18next challenges, from translation key management to resolving performance-degrading warnings.","date":"2025-01-08","category":"Guides","thumbnail":"\/img\/blog\/improve-i18next-usage\/title.jpg","readTime":"6 min read","searchText":"title: '8 Signs You Should Improve the Way You Use i18next (and How to Fix Them)', description: 'Learn how to streamline your localization workflow by identifying and fixing common i18next challenges, from translation key management to resolving performance degrading warnings.', date: '2025 01 08', thumbnail: '\/img\/blog\/improve i18next usage\/title.jpg', image: '\/img\/blog\/improve i18next usage\/title.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'how to'] Localization can make or break your software in global markets, and i18next is a fantastic tool to manage translations. However, inefficient workflows or mismanagement can lead to technical debt, release delays, and poor user experiences. Letâs explore 8 signs your i18next setup might need improvement and practical solutions for each issue. Sign 2: Ignoring i18next Warnings Problem : i18next logs provide vital information to catch potential issues, but many developers dismiss these warnings, assuming theyâre harmless. Ignoring these logs can lead to missing translations , runtime errors , and performance degradation . For example, attempting to access the function before translations are fully loaded results in broken or fallback texts. Examples of Common Warnings : Initialization issues : Loading and resource issues : Interpolation and pluralization errors : Solution : I) Read and address warnings : Each warning is a clue to an underlying issue. For instance: indicates improper initialization: ensure or completes before accessing the function. signals missing data for interpolation. II) Test initialization flow : Ensure i18next is initialized only once, translations are loaded, and the correct language is detected. III) Monitor warnings in production : Test your software and check for any i18next warnings before going to production. Use tools like Sentry or your logging framework to capture i18next warnings in live environments, so you can fix issues proactively. Properly addressing these warnings leads to better performance, accurate translations, and a smoother user experience. Sign 3: Your App Doesnât Feel Native to Users in Different Regions Problem : Even if your translations are technically accurate, your app may
40still feel awkward to users in different regions. This happens when regional differences in date formats , currencies , units of measurement , or even tone are ignored. Example : An app displays a U.S. date format ( ) for German users, where the expected format is . This subtle mismatch makes the app feel less intuitive and trustworthy. Solution : Leverage i18nextâs formatting options or Intl APIs to localize dates, numbers, and currencies. Follow guidelines and articles to incorporate regional nuances and implement a successful internationalization. Sign 4: Youâre Manually Handling Translation Files Problem : Manually managing translation files is not only time consuming but also error prone. Overwriting files, merging conflicts, or uploading the wrong version can easily cause inconsistencies or missing translations. Example : A developer manually copies translations from one environment to another, accidentally introducing outdated or incomplete strings. This results in discrepancies between environments, frustrating both the team and end users. Solution : Use a centralized translation management platform like Locize to automate file synchronization. Integrate real time updates during development, for example using the Locize backend (learn more). This eliminates manual errors and streamlines the localization process. Sign 5: Translators Keep Asking for Context Problem : When translators lack context, they may produce literal or incorrect translations. This is especially problematic with generic strings like or , which might apply to various parts of the app. Example : The key could refer to saving a document, user settings, or even a game state. Without additional information, translators may misinterpret its meaning, leading to incorrect translations. Solution : Provide optional default values and contextual descriptions using i18next: These descriptions clarify usage, ensuring accurate translations. Alternatively or additionally, manage context information, enable in context editing or use screenshots with tools like Locize (learn more). These context informations are also important for AI based translations, like used here. Sign 6: Youâre Struggling with Dynamic Content Problem : Dynamic content such as interpolated values ( ) or pluralization rules can lead to broken placeholders or poorly localized strings. Different languages often require varying grammatical structures, which adds complexity. Example : In English, we might display or . In Polish, however, plurals vary depending on specific numerical ranges, requiring distinct translations. Solution : Use i18nextâs interpolation and pluralization features to manage dynamic content effectively (guide). Tools like Locize detect syntax inconsistencies , such as issue 240, which warns about mismatched placeholders. And also automatically suggests the correct plural form key for target languages. This approach prevents runtime errors and ensures grammatically correct translations. Sign 7: Your Localization Workflow Slows Down Releases Problem : If your team relies on manual intervention for translation updates, release timelines suffer. Agile workflows demand continuous delivery, and waiting for complete translations can delay critical updates. Example : A new feature is ready for deployment, but itâs delayed because a handful of translations are incomplete. Solution : Use a translation management system like Locize, which enables non developers to update translations independently. Automate the translation delivery process through your CI\/CD pipeline (details). This decouples localization from development, accelerating release cycles. Sign 8: Testing Localized Versions Is a Nightmare Problem : Testing your app across multiple languages is labor intensive and prone to oversight. Issues like missing keys, layout distortions due to text expansion, or improper right to left (RTL) alignment often slip through the cracks. Example : German translations expand significantly compared to English, potentially breaking your UI. Similarly, Arabic translations may not render correctly in RTL layouts. Solution : Automate testing for translation accuracy using frameworks like Jest or Cypress. Automatically track new\/missing keys like described here. Regularly clean up unused translations to streamline testing (guide here). With automated testing and proper housekeeping, you can ensure smooth and error free localized releases. How to Start Improving Today Improving your i18next workflow doesnât require an overhaul. Address the most critical issues first and adopt best practices progressively. Tools like Locize simplify this process, making localization more efficient and reliable. Bonus tip If you want to explore tips and tricks on how to use i18next to handle internationalization and localization effectively, read this. [](\/blog\/i18next tips and tricks) Conclusion Optimizing your i18next workflow enhances your teamâs efficie
40ncy and improves the user experience. Start addressing these signs to create a truly global product. Ready to elevate your localization process? Implement these tips today!"},{"slug":"product-localization","title":"Product localization - selling globally","description":"Product localization is used to adapt products to the target market and address target groups in the respective country.","date":"2024-12-24","category":"Guides","thumbnail":"\/img\/blog\/product-localization\/product-localization.webp","readTime":"7 min read","searchText":"hideCta: true, title: 'Product localization selling globally', description: 'Product localization is used to adapt products to the target market and address target groups in the respective country.', date: '2024 12 24', thumbnail: '\/img\/blog\/product localization\/product localization.webp', image: '\/img\/blog\/product localization\/product localization.webp', category: 'Guides', tags: ['localization', 'guides', 'product'] In an increasingly globalized world, the number of new products conquering international markets is growing rapidly. In order to remain competitive in this dynamic environment, there is no way around well thought out product localization. Products have long been more than just physical goods they range from mobile apps and websites to digital services. Thanks to digital sales channels, companies can now reach customers worldwide with just one click. But to really tap into global markets, language and cultural barriers need to be overcome. The focus here is not only on translating texts, but also on comprehensively adapting them to the needs and expectations of different cultures and target groups. Product localization is therefore the key to making offers relevant and appealing for international markets. We have explained below exactly how it works, why localization is crucial for global success, how product localization differs from pure translation and what strategies are available to optimally position products. What is product localization? Product localization (also called localization) describes the targeted adaptation of content to the specific requirements of a new market. The process includes the translation of texts, the adaptation of formats such as date, time or currency and the consideration of cultural sensitivities and regional preferences. In the end, it must be ensured that local, cultural and functional needs are taken into account. In addition, it may be necessary to make technical changes to ensure that the product is compatible with local standards, regulations or infrastru
40cture. The goal of product localization is to optimize the product so that it feels natural and intuitive to users in a particular region and meets all local requirements. Why is product localization so important? Product localization helps companies to adapt their products to the needs and expectations of their target group. A central focus is on increasing acceptance and user friendliness. Why is this important? Quite clearly, people prefer products that speak their language and respect cultural characteristics. This not only strengthens trust, but also the connection to the brand. What else makes product localization so important? Language and culture as drivers of success In a globalized world, overcoming language and cultural barriers is crucial to the success of a product. Studies show that 66% of B2B and 34% of B2C customers are more likely to invest in an app if it delivers a locally adapted language experience. Given that only 25.9% of the world's population speaks English and 60% of websites are only available in English, a huge market often remains untapped. Early product localization during product development creates a clear competitive advantage and enables customers worldwide to interact seamlessly. Fast and effective market access An integrative approach, which parallelizes product development and product localization, significantly reduces time to market. Instead of developing features first and adapting them later, localization is integrated directly into the development process. This allows new markets to be opened up efficiently without having to rely on physical locations. Sustainable customer loyalty and growth Product localization not only ensures comprehensibility and cultural relevance for different target groups, but also strengthens trust in the brand. An adapted product experience promotes customer loyalty, increases return visits and supports long term sales through a growing, loyal customer base. In addition, product localization ensures that legal and regulatory requirements of the respective market are met. Technical adaptations ensure that the product is compatible with regional standards and infrastructures. What types of product localization are there? There are several different approaches or types of product localization. These should and may of course be combined with each other. Which variants are suitable always depends on the actual needs of the company. 1. Linguistic adaptation The translation of texts goes beyond pure word for word translation. Dialects, idiomatic expressions and regional linguistic characteristics are taken into account in order to make communication credible and natural. 2. Cultural sensitivity Colors, symbols, images and even humor are adapted to meet the cultural expectations of the target group. Holidays, traditions and local values are incorporated into the design to present products and messages in a culturally appropriate way. 3. Technical integration Digital products, software and interfaces are based on regional standards. This includes character sets, operating systems, network requirements and even loading speeds. 4. Legal compliance Product localization requires compliance with legal regulations such as data protection guidelines, product safety standards or packaging regulations. 5. Format and currency adaptation From date and time formats to units of measurement and currencies all relevant elements comply with the standards of the target market with product localization. 6. Visual optimization Layout, color schemes and design are specifically adapted to the aesthetic preferences of the target group. The visual adaptation creates a strong cultural reference and promotes acceptance of the product. 7. Functional alignment All specific needs of the target market are met by optimizing the products and services. Methods that add or remove individual functions or features are suitable for this purpose. 8. Marketing customization In the area of marketing, product localization aims to adapt campaigns, slogans and advertising materials to the linguistic and cultural preferences of the target group. This reduces misunderstandings and strengthens brand messages. 9. Product modification Physical products can be improved in terms of size, material or packaging. Operating instructions and technical details are also localized at the same time. 10. Customer service and support A localized support offering, including customized FAQs, service hours and language support, ensures that customers in every region receive the best possible service. Adapt to global markets How can product localization be implemented in practice? In order to successfully adapt a product for global markets, internationalization (i18n) is the crucial first step. The product is designed in such a way that it is flexible for different languages and cultural requirements right from the start. This process creates the basis for smooth localization. Only these preparatory measures ensure that the product can be easily adapted to the specific expectations and requirements of a target market. Subsequent localization requires a thoughtful approach to take into account cultural, linguistic and functional specifics to ensure an optimal user experience. 1. Market analysis and target group research To begin with, the specifics of the target market should be examined in detail. This includes analyzing the cultural and linguistic characteristics as well as the technical and legal requirements. It is also important to understand the expectations of the target group in terms of product functions, design and communication. 2. Creating a localization plan For comprehensive planning of product localization, goals are defined, priorities are set and tasks are structured. A schedule is also drawn up and the required budget is calculated. It is also important to clearly allocate resources and responsibilities in order to ensure efficient collaboration between different teams or service providers. 3. Linguistic adaptation Content must now be translated into the language of the target market in such a way that it sounds natural and authentic. This includes taking regional dialects, idiomatic expressions and the cultural context into account. Professional translators or localization agencies and a translation management system that are familiar with the language and culture ensure high quality. This is followed, as required, by cultural adaptation, technical localization, format and currency adaptation, legal and regulatory adaptation and design adaptation. 4. Testing and quality assurance After product localization, comprehensive tests must be carried out to ensure that all adaptations have been implemented correctly. Linguistic, te
40chnical and cultural aspects are checked to avoid errors. Beta tests help to identify functional and linguistic errors, while QA checks ensure compliance with regional regulations and technical standards. An iterative approach enables early adjustments to be made and potential problems to be rectified before they reach the end customer. Feedback from users helps to identify potential weaknesses and then revise the product localization. Collaboration with local experts or partners can also be beneficial. They provide valuable insights into the specifics of the market and can help to better take cultural nuances into account. 3 Examples of product localization Domino's Domino's has successfully conquered the Indian market with thoughtful localization. They adapted their menu to local tastes and integrated regional favorites such as paneer tikka, chicken keema and tandoori variations. This was complemented by a strategic price adjustment and the recruitment of experienced chefs and a specialist marketing manager. They also responded to the growing importance of digital food ordering with a localized website and app. The success speaks for itself: from 128 outlets in 2006, the franchise grew to an impressive 1,495 locations in India by 2021. Airbnb For Airbnb, whose concept is based on local experiences, product localization is a key success factor. The platform is now available in 62 languages, with plans for even broader coverage. According to Salvo Giammarresi, Head of Localization, Airbnb stands for products and services that are âculturally appropriate, locally relevant and globally consistentâ. This approach has helped Airbnb to optimally target users in different markets and promote the local experience on a global scale. Nintendo Nintendo also shows how crucial cultural product localization can be for international success. In order to reach American players in the 1980s, they localized their games not only in terms of language, but also in terms of content. Censorship, for example in depictions of violence or death, was implemented in order to meet cultural and legal requirements. This sensitivity to localization helped establish Nintendo as one of the world's leading gaming brands, with more than 100 million users annually. â¡ï¸ Register for our Translation Management System here."},{"slug":"ai-vs-mt-vs-tm","title":"Unlocking the Power of Translation: Machine Translation, Translation Memory, Generative AI, and More","description":"Explore the benefits of machine translation, translation memory, generative AI, and human translation, and discover how Locize lets you seamlessly combine them all.","date":"2024-12-20","category":"Guides","thumbnail":"\/img\/blog\/ai-vs-mt-vs-tm\/thumbnail.jpg","readTime":"3 min read","searchText":"hideCta: true, title: 'Unlocking the Power of Translation: Machine Translation, Translation Memory, Generative AI, and More', description: 'Explore the benefits of machine translation, translation memory, generative AI, and human translation, and discover how Locize lets you seamlessly combine them all.', date: '2024 12 20', thumbnail: '\/img\/blog\/ai vs mt vs tm\/thumbnail.jpg', image: '\/img\/blog\/ai vs mt vs tm\/title.jpg', category: 'Guides', tags: ['localization', 'guides', 'translation memory', 'machine translation', 'ai', 'comparison'] In todayâs interconnected world, breaking language barriers is more crucial than ever. Whether youâre a global SaaS platform, an e commerce site expanding to new markets, or a content creator aiming for international reach, the quality and efficiency of your translations matter. But with so many translation options (machine translation, translation memory, generative AI, and traditional human translation), how do you decide whatâs best for your needs? At Locize , we believe in empowering you to choose the tools that fit your unique workflow. In this blog, weâll compare the various translation options and highlight how Locize lets you seamlessly integrate them all, ensuring your content resonates globally. Translation Memory: Consistency at Its Best Translation memory (TM) systems are databases that store previously translated phrases, sentences, or paragraphs for future reuse. Locizeâs built in smart TM ensures that youâre not translating the same content twice. Pros: Consistency: Maintains uniform terminology across projects. Efficiency: Speeds up the translation process for repetitive content. Cost Savings: Reduces translation costs over time. Cons: Initial Investment: Building a robust translation memory takes time. But with Locize this comes automatically and at no cost for you. Limited Creativity: May not adapt well to highly creative or dynamic content. Generative AI Translations: The Future of Localized Creativity Generative AI, powered by technologies like OpenAI and MistralAI , is changing the game. Unlike traditional MT, generative AI can produce translations that are not just accurate but also creative, context aware, and nuanced. Pros: Contextual Understanding: Handles idiomatic expressions and cultural subtleties better than traditional MT. Creative Flexibility: Perfect for marketing, storytelling, and content heavy industries. Rapid Advancements: Constant improvements make it a future proof option. Cons: Cost: Generative AI can be more expensive compared to traditional MT. Training Time: May require customization or fine tuning for specific industries. Human Translation: The Gold Standard Despite technological advancements, human translation remains unmatched in its ability to capture tone, cultural context, and emotional nuances. Pros: Accuracy: Tailored to your brandâs voice and target audience. Cultural Relevance: Avoids embarrassing localization mistakes. Customizability: Ideal for complex or sensitive projects. Cons: Cost: Significantly more expensive than automated solutions. Time: Slower turnaround compared to machine or AI options. Why Choose One When You Can Have It All with Locize? Locize offers a flexible platform that puts you in the driverâs seat. Whether you prefer machine translation, translation memory, generative AI, or human translation, Locize integrates seamlessly with your choice. Multi Service Integration: Use DeepL, Google Translate, OpenAI, Mistral AI, or any other preferred service directly within Locize. In Bu
40ilt TM: Save and reuse translations for greater efficiency and consistency. Custom AI Options: Leverage the power of generative AI like OpenAI and MistralAI for creative and nuanced translations. Human Expertise: Combine automation with professional human translators when precision is paramount. With Locize, you donât have to compromise. Tailor your translation strategy to fit your project needs, budget, and timeline, all within one intuitive platform. Conclusion The world of translation is no longer about picking sides: itâs about finding balance. Machine translation offers speed, translation memory ensures consistency, generative AI unlocks creativity, and human translation delivers unparalleled precision. With Locize, you have the freedom to choose, mix, and match these tools to create a translation process that works for you. Ready to break language barriers with ease and flexibility? Try Locize today and discover how effortless global communication can be! Explore Locize now â¡ï¸ locize.com"},{"slug":"what-is-translation","title":"What Is Translation? Types, Modern Workflow & Quality","description":"Translation isn't word-for-word, and modern AI still misses nuance, tone, and culture. Covers types, machine vs. human, and how pro translation workflows actually work today.","date":"2024-11-28","category":"Guides","thumbnail":"\/img\/blog\/what-is-translation\/what-is-translation.webp","readTime":"8 min read","searchText":"title: 'What Is Translation? Types, Modern Workflow & Quality', description: \"Translation isn't word for word, and modern AI still misses nuance, tone, and culture. Covers types, machine vs. human, and how pro translation workflows actually work today.\", date: '2024 11 28', thumbnail: '\/img\/blog\/what is translation\/what is translation.webp', image: '\/img\/blog\/what is translation\/what is translation.webp', category: 'Guides', tags: ['localization', 'guides', 'basics'], faq: [ q: 'What is translation?', a: 'Translation is the process of conveying text or spoken content from one language into another while preserving the original meaning, tone, intent, and cultural context. It goes beyond word for word substitution: a good translation reads naturally to its target audience and adapts idioms, formality, and cultural references that do not carry across languages directly.' , q: 'What is the difference between translation and localization?', a: 'Translation converts the text. Localization adapts the entire experience for a target market: text plus date and number formats, currency, address layouts, plurals, gendered language, images, and sometimes layout direction (RTL for Arabic and Hebrew). Translation is one part of localization; localization is what makes a product feel native rather than translated.' , q: 'What are the main types of translation?', a: 'The most common categories are specialist (medicine, law, engineering), business and document, literary, legal, marketing and advertising, medical, e commerce, technical, and localization translation. Each type has its own quality requirements, terminology, and review process. For example, legal translation requires legal validity in both jurisdictions, while marketing translation often crosses into transcreation (creative adaptation).' , q: 'What is machine translation?', a: 'Machine translation (MT) is automatic translation produced by software, today almost always using neural machine translation (NMT) or large language models. Tools like Google Translate, DeepL, and OpenAI\/Anthropic models can translate large volumes of text in seconds. MT is reliable for general comprehension on major language pairs but typically requires human post editing for customer facing or specialized content.' , q: 'What is post editing in translation?', a: 'Post editing is the process of a human translator reviewing and refining machine translated output. It is faster than translating from scratch and produces higher quality than raw MT, making it the standard workflow for most professional translation today, especially in software localization, e commerce, and technical documentation.' , q: 'What is a CAT tool?', a: 'CAT (computer aided translation) tools are software that help human translators work faster and more consistently. Core features include translation memory (storing previously translated segments for reuse), glossaries (enforcing terminology), style guides (capturing tone and brand voice), and quality assurance checks. Modern translation management systems (TMS) like Locize bundle CAT features with workflow, review, and delivery (CDN\/API).' , q: 'How is professional translation done?', a: 'A typical modern workflow combines machine translation, translation memory, and human review. Source text is pre translated by an MT or AI engine, segments matching the translation memory are reused, and a human translator post edits the result against a project glossary and style guide. The finished translation is reviewed, approved, and delivered to the target system, often a website, app, or product through an API or CDN.' ] Translation is the process of conveying text or spoken content from one language into another while preserving meaning, tone, intent, and cultural context. It is more than word for word substitution: an effective translation reads naturally to its target audience and adapts idioms, formality, and cultural references that do not carry across languages directly. In modern workflows, translation is increasingly produced by a combination of machine translation (for speed and scale) and human translators (for nuance and quality), a hybrid approach known as post editing. Key facts What it is: convert
40ing text or speech between languages while preserving meaning, tone, and intent Main types: specialist, business, legal, medical, marketing, technical, literary, e commerce, localization Core tools: CAT tools, translation memory, glossaries, style guides, translation management systems (TMS) Modern workflow: machine translation + human post editing Beyond translation: localization adapts the whole experience (formats, currency, layout, cultural references); translation is one part of localization Translation should be seen as an integral part of a comprehensive localization strategy, not an isolated step. Why translations matter for international companies For global companies, localization translation is essential to overcome language barriers and reach customers in their own language. Professional translations build customer trust and market acceptance; inaccurate translations can damage reputation and cause costly misunderstandings. Through professional translations, companies present their products, services, and brand messages clearly across languages. A good translation also takes regional characteristics and cultural nuances into account, increasing credibility in each target market. In areas such as marketing, legal documents, and technical manuals, accurate and culturally appropriate translation is essential, both to avoid errors and to protect the international image of the company. What are the different types of localization translation? There are different types of translation, each tailored to specific needs and content. These include the following: Specialist translation Specialist translations are specialized in certain subject areas such as medicine, law, technology or business. They require a deep understanding of the specialist language and terminology to ensure accurate and error free translations. Business translation The term business translation covers the transfer of content between two languages that supports international business activities. This includes various documents, marketing materials and digital resources. Document translation Document translation involves the creation of business translations, business correspondence, internal communications, manuals, contracts, technical specifications and other important documents. The challenges here often lie in the large volume and fragmented structure of the documents, as well as the need to maintain consistent terminology throughout the text. Literary translation This is the translation of books, poems and other literary works. The aim is to preserve not only the meaning, but also the style, tone and cultural nuances of the original. Legal translation Whether contracts, deeds, patents or other legal documents, legal translations place high demands on the translator. As these are binding, they must be accurate and comply with the legal standards of both countries. Translations of court and legal documentation are another sub category of this specialty area. Arrest warrants, registrations, certificates, declarations, affidavits, patents, trademarks, proceedings, lawsuits, decrees, contracts and insurance policies are just a few examples of legal documents that need to be translated. Marketing and advertisement translation Marketing and advertisement translation often requires a creative translation that adapts the message to the cultural and emotional expectations of the target audience. The translation should achieve the same feeling and effect as the original. Learn more in our guide on localization marketing. Medical translation Medical translation is subject to strict requirements and includes clinical trial protocols, patient information, regulatory documents and other critical texts. Due to the potentially vital consequences, this type of translation requires specialized expertise, the utmost precision and special attention to detail. E commerce translation In global e commerce, multilingualism is important to appeal to customers in different markets. Landing pages, product descriptions, customer reviews and blog articles must be translated into the respective target market language. It is important to find a balance between precision and SEO optimization and to take cultural nuances into account. Technical translation This includes translations of technical documents such as manuals, instructions and technical specifications. Accurate, clear and comprehensible terminology is particularly important here to ensure that products are used correctly. Localization translation Localization involves the comprehensive adaptation of a product or service to the cultural and linguistic conditions of a target market. This form of translation is often used for software, websites or games and takes regional characteristics into account. What factors play a role in localization translation? Let's take a closer look at localization translation and take a closer look at this type of translation. Several important factors are required to ensure that the content is not only linguistically but also culturally adapted to the target market. Localization translation goes beyond mere translation and takes into account cultural characteristics such as regional holidays, country specific symbols, colors and images, which can have different meanings depending on the culture. The language is adapted to local dialects, language variants and idioms in order to sound authentic and understandable. This is particularly important in order to address the target group at eye level and create a personal connection. Content must be adapted to the legal requirements of the target market, especially for legal documents, product descriptions and data protection guidelines, to ensure compliance. Information such as currencies, units of measurement (e.g. inches instead of centimeters) and date formats (e.g. day, month, year) need to be converted to avoid misunderstandings and create a familiar user experience. The tone and style of the translation should be adapted to the expectations of the target audience. For example, a more formal approach may be preferred in some countries, while other markets may expect more casual, informal language. For software and websites, technical adaptations play a role, such as supporting different characters, text lengths and layout changes to ensure the application displays correctly on all devices and platforms in the target market. For digital content, it is important to adapt keywords to local search terms in order to remain visible in search engines. Localization therefore also includes optimization for the respective language and region. Images, symbols and graphics should be adapted to cultural expectations. An image that evokes positive associations in one region could be interpreted differently or even be perceived as inappropriate in another region. How can translations be implemented? Localization translations can be implemented through a combination of strategies and technologies that together ensure that the content is translated into the target languages in an accurate and culturally appropriate way. The first step is to find and select professional translators or specialized translation agencies who have the necessary expertise and understanding of the target culture. The experts then produce an initial translation. To increase eff
40iciency, modern translation tools such as translation management systems are usually used, which store previously translated segments and reuse them as required. This maintains consistency and speeds up the translation process considerably. Other core tools include CAT tools (computer aided translation), which help translators to translate content even more accurately through automation. Key functions of CAT tools include: Translation memory: saves previously translated segments and reuses them automatically, saving time and keeping wording consistent across projects. Glossaries: enforce specific terms (product names, technical vocabulary, legal terms) so translators do not paraphrase them differently each time. Style guides: capture tone, brand voice, and formatting rules, what your reviewers would otherwise have to teach every new translator from scratch. Quality assurance: automated checks detect typos, missing placeholders, inconsistent terminology, and segment length issues before review. localization translation process? A translation management system (TMS) extends these functions even further and usually includes additional project and workflow management. It therefore facilitates the coordination of complex projects and can be linked to CMS, CRM or e commerce platforms. In this way, TMS platforms support companies in efficiently integrating their translations into existing business processes and ensuring the quality of international communication. However, experienced localization experts or specialized tools are essential for localization, i.e. adapting to cultural peculiarities. They not only translate, but also adapt the content to the cultural and legal requirements of the target market. Speech to text and live translation are now mainstream in collaboration tools: Microsoft Teams, Zoom, and Google Meet all offer real time captioning and translation. For written content, the bottleneck has shifted from \"can a machine translate?\" to \"is the output accurate, consistent, and on brand?\", which is where TMS, glossaries, and style guides earn their keep. Machine translation vs. human translation: which is better? Machine translation and human translation each have their strengths and are suitable for different requirements. The choice between the two depends heavily on factors such as quality, speed, cost and the required understanding of cultural nuances. Machine translation is useful when large volumes of text need to be translated quickly and rough comprehensibility is sufficient. Modern machine translations, supported by artificial intelligence, offer high speed and are often more cost effective than human translations. They are well suited to simple or standardized texts, such as simple manuals or internal documents, where the risk of misunderstandings is low. However, machines often reach their limits with creative, emotional or culturally sensitive texts. Nuances, wordplay or contextual subtleties are difficult or even impossible to translate correctly. Human translation, on the other hand, is particularly superior for demanding, creative or culturally complex texts. Professional translators have a deep understanding of the subtleties and cultural context of a language, which is crucial for high quality, authentic and emotionally appealing translations. This enables them to accurately convey not only the meaning, but also the intention and style of the original. For marketing materials, literary texts and legal documents, these differences are simply indispensable. In many cases, however, a combination of the two is also useful: machine translations can be created as a first version and then checked and adapted by human translators. This approach, known as \"post editing\", utilizes the speed of the machine while ensuring quality through human sensitivity. For more depth, see How AI Translation Changes the Industry and Machine Translation, Translation Memory, Generative AI, and More. Frequently Asked Questions frontmatter.faq.map(( q, a ) = ( q a )) Conclusion Translation is a deceptively complex craft. The mechanics of converting words between languages have largely been solved by neural machine translation, but the quality bar (preserving meaning, tone, intent, and cultural fit) still requires human judgment, a project glossary, a style guide, and a translation memory that learns from every previous decision. The teams that get this right treat translation as part of their product workflow, not as a one off task they outsource at the end. If you are localizing a software product, Locize is a translation management system designed around this hybrid workflow: AI\/MT for speed, CAT for the editor, glossary and style guide for consistency, and human review for the final mile."},{"slug":"enterprise-translation-management-system","title":"Get to know Enterprise Translation Management System","description":"With Enterprise Translation Management Systems, you can optimize and automate your translation and localization processes.","date":"2024-09-24","category":"Guides","thumbnail":"\/img\/blog\/enterprise-translation-management-system\/enterprise-translation-management-system.webp","readTime":"4 min read","searchText":"hideCta: true, title: 'Get to know Enterprise Translation Management System', description: 'With Enterprise Translation Management Systems, you can optimize and automate your translation and localization processes.', date: '2024 09 24', thumbnail: '\/img\/blog\/enterprise translation management system\/enterprise translation management system.webp', image: '\/img\/blog\/enterprise translation management system\/enterprise translation management system.webp', category: 'Guides', tags: ['localization', 'guides', 'tms'] Enterprise Translation Management System An Enterprise Translation Management System automates translation processes for product information, eliminating tedious and repetitive manual tasks. An Enterprise Translation Management System provides you with a comprehensive way to manage your translation processes, ensuring closer collaboration within the team and significantly increasing efficiency. Additionally, the centralization of all linguistic resources ensures greater transparency across the entire translation chain, which is crucial for optimizing translation workflows within your company. Why the use of Enterprise Translation Management Systems is important, what advantages the softw
40are solution offers, and what it is, will be explained in the following article. What is an Enterprise Translation Management System? An Enterprise Translation Management System is a specialized software solution that helps your company efficiently manage and automate your translation and localization processes. The systems provide a central platform for: Organizing all translation projects Storing and managing texts Collaborating with translators and language service providers Managing terminology Integrating translation tools like Translation Memories and machine translation services An Enterprise Translation Management System allows a company to standardize all translation work, improve the quality and consistency of translations, save time and costs, and increase the efficiency of localization processes. It is particularly suitable for companies with large translation needs or complex multilingual projects. What is the difference between a Translation Management System for Enterprises and Translation Management Systems? A Translation Management System is designed to manage translation projects. It includes basic functions such as assigning translation tasks, tracking progress, managing Translation Memories and terminology databases, and integrating machine translation tools. A Translation Management System is typically intended for small to mid sized companies or translation agencies looking for a central platform to organize their translation work but with no need for extensive or complex features. A Translation Management System for Enterprises, on the other hand, is an enhanced version of a Translation Management System specifically aimed at large companies with complex multilingual translation requirements. It includes all the basic functions of a Translation Management System but is additionally tailored to the needs of large, globally operating companies. It comes with extended features such as integration with other enterprise systems (e.g., content management systems, e commerce platforms, product information management), enhanced security features, detailed reporting and analytics options, as well as the ability to manage large amounts of content and collaborate with numerous translators and teams worldwide. translation management systems for enterprises What are the advantages of a Translation Management System for Enterprises? If your company is one of those that needs an organizational tool for translation processes, using one comes with several notable advantages: Central platform where all translation projects can be organized and managed, facilitating coordination between different teams, translators, and service providers, as all parties have access to current documents and resources at any time. Through the automation of translation processes the time required to manage translation projects is significantly reduced. Localized products and services can be brought to market faster. An Enterprise Translation Management System helps companies save costs by utilizing Translation Memories. Translation Memories store already translated segments that can be reused for future projects, eliminating the need for repeated translations and reducing translation costs. Through the use of central terminology databases and style guides an Enterprise Translation Management System ensures that translations are consistent and of high quality. Detailed insights into the status and progress of translation projects ensure better control and planning. For companies operating in multiple markets and working with different languages, an Enterprise Translation Management System is especially advantageous. It can easily scale to meet growing demands, whether by supporting additional languages or integrating with other enterprise systems like content management systems or product information management tools. What does an Enterprise Translation Management System cost? The cost of an Enterprise Translation Management System can vary significantly and depends on several factors, including the range of functions, the number of users, integration options with other systems, and the type of implementation (cloud based or on premise). In general, you can expect the following costs for an Enterprise Translation Management System: License fees depending on the provider and chosen features, ranging from a few thousand to several tens of thousands of euros per year. Setup and implementation costs such as system configuration, integration with existing enterprise applications, workflow customization, and possibly the migration of existing data. Training and support to ensure uniform application across the team and quick access to support in case of problems. Additional modules and integrations if you need special integrations, extended reporting functions, additional security measures, or machine translation services. Cloud based vs. On premise where cloud based solutions often have lower setup fees and usage based billing, while on premise solutions require higher initial investments for hardware and IT infrastru
40cture but may have lower ongoing costs in the long run. â¡ï¸ Create a free account to explore our software for your business."},{"slug":"l10n","title":"L10n â What is it? | Locize","description":"Youâve heard of L10n and are unsure what it is and if you need it? We'll tell you everything you need to know about it.","date":"2024-09-19","category":"Guides","thumbnail":"\/img\/blog\/l10n\/l10n-definition.webp","readTime":"5 min read","searchText":"hideCta: true, title: 'L10n â What is it? Locize', description: 'Youâve heard of L10n and are unsure what it is and if you need it? We\\'ll tell you everything you need to know about it.', date: '2024 09 19', thumbnail: '\/img\/blog\/l10n\/l10n definition.webp', image: '\/img\/blog\/l10n\/l10n definition.webp', category: 'Guides', tags: ['localization', 'guides', 'basics'], faq: [ q: 'What does l10n stand for?', a: 'L10n is the abbreviation for \"localization\": the word starts with an l, ends with an n, and has 10 letters in between. It follows the same numeronym convention as i18n (internationalization) and g11n (globalization).' , q: 'What is the difference between l10n and i18n?', a: 'i18n (internationalization) is the engineering preparation: designing software so it can support any language and region without code changes. L10n (localization) is the execution: actually adapting the product for a specific market, including translation, formats, cultural adaptation, and legal requirements. Internationalization comes first; localization builds on it per target market.' , q: 'Is l10n the same as translation?', a: 'No. Translation converts text from one language to another and is one part of l10n. Localization additionally adapts date, time, and number formats, currencies, images, colors, symbols, layout direction, and legal content so the product feels native in the target market rather than merely translated.' , q: 'What tools are used for l10n?', a: 'The core tool is a translation management system (TMS), also called a localization platform: it stores translations centrally, provides translation memory and a glossary for consistency, supports in context translation and review workflows, and in modern setups delivers translations over a CDN. Teams combine it with an i18n library in the code (such as i18next for JavaScript) and, increasingly, machine and AI translation with human review, run as a continuous localization workflow.' ] L10n is the common abbreviation for localization : the process of adapting a product or service to the language, culture, and conventions of a specific target market. The \"10\" stands for the ten letters between the \"l\" and the \"n\" in \"localization\". L10n covers translation plus formats (dates, numbers, currencies), cultural adaptation, layout direction, and legal requirements, and it builds on internationalization (i18n), the engineering work that makes a product adaptable in the first place. L10n â What You Need to Know Maybe you've come across the terms L10n and i18n and are wondering what they mean. These abbreviations stand for Localization (L10n) and Internationalization (i18n) in the context of software development. They are crucial if you plan to offer your products or services in multiple countries, as they ensure that your offerings are linguistically and culturally adapted to the respective markets. They help you tailor your offerings to the cultural and linguistic requirements of your target markets, enabling you to successfully enter new markets. What is L10n? L10n is short for \"Localization,\" where the \"L\" stands for the first and the \"n\" for the last letter of the English word \"Localization,\" while the number \"10\" represents the number of letters between the two. Localization refers to adapting a product or service to meet the cultural, linguistic, and other local requirements of a specific market or region. Itâs not just about translating text but comprehensively adjusting to cultural norms, local laws, currency units, date and time formats, measurement units, and many other aspects to make your offerings accessible and relevant to your target audience. L10n, and thus localization, is an essential part of globalization as it enables you and your company to reach an international audience by maximizing the user experience. man works at l10n with Locize An Example With Localization L10n, you donât just translate all the content of your website for the UK market, but you also adjust graphics, colors, and symbols that may have different meanings in the UK than in other countries. Moreover, you add legal notices and privacy policies that comply with British laws. Another critical aspect of L10n is cultural sensitivity. This means designing your content to respect and reflect the values, beliefs, and practices of your target audience. For example, certain images or symbols considered polite in one culture might be viewed as rude or offensive in another. It may al
40so be necessary to change or remove specific topics or content that are acceptable in one culture but not in another. Advantages of L10n Now that you know what L10n is, let's briefly discuss the advantages of localization before we move on to i18n. Your benefits with L10n: You can enter new markets and expand the reach of your offerings. You ensure a better user experience and increase customer satisfaction. You gain a competitive edge as localized sites appear more professional and appealing to target audiences. Your market perception becomes more positive as you cater to the needs and preferences of your international customers. You build a foundation for better market positioning, increasing sales and revenue. You ensure compliance with all local legal and regulatory requirements, reducing the risk of penalties. What Is Needed for L10n? To successfully implement L10n, you'll first need a professional translator and linguist who not only perfectly understands the target marketâs language but also has an understanding of cultural nuances and local customs. Just as important Use appropriate tools and technologies that support the localization process. These include Translation Management Systems that store and reuse already translated texts and software that manages the entire terminology, ensuring consistent use of technical terms. Also necessary is a structured, internationalized codebase to adapt to different languages and regions without requiring extensive technical changes. To fully leverage the benefits of L10n, multiple departments need to collaborate, including developers, designers, product managers, and marketing experts. This ensures that all aspects of the product â from the user interface to technical functionality to marketing messages â are fully aligned with the needs of your target market. Finally, donât forget to establish quality assurance measures to ensure a local, accessible experience. How teams run L10n today In practice, modern l10n runs on a translation management system (TMS), sometimes called a localization platform or translation automation platform. Developers keep writing code with translation keys; new and changed strings flow into the platform automatically; machine and AI translation produce the first draft; translators and reviewers work in an editor with translation memory, a glossary, and in context preview; and the finished translations are delivered over a CDN so updates go live without redeploying the application. Run continuously alongside development, this is called continuous localization, and it replaces the old pattern of batch handoffs and manual file exchange. What is the Difference Between i18n and L10n? i18n and L10n are two related but different concepts in adapting products and services for various markets. i18n stands for \"Internationalization\" (from the English \"Internationalization\"), with the \"i\" and \"n\" representing the first and last letters of the word, and the number \"18\" indicating the number of letters between them. Internationalization refers to designing a product or service so that it can easily be adapted for different languages and regions without requiring significant code changes. This includes separating linguistic content from the program code, supporting multiple writing systems, and adapting functions to accommodate different cultural, legal, and technical requirements. L10n, or \"Localization,\" as previously defined, refers to the actual adaptation of the product or service to the specific linguistic, cultural, and legal requirements of a particular market. Frequently Asked Questions frontmatter.faq.map(( q, a ) = ( q a )) Additional Resources â¡ï¸ Create a free account to explore our software for your business. â¡ï¸ Learn more about the concept of Localization."},{"slug":"ai-in-localization","title":"AI in localization and its future role","description":"Explore AI in localization as we debunk ChatGPT's role, celebrate Machine Translation's efficiency in Translation Management Systems.","date":"2024-07-29","category":"Guides","thumbnail":"\/img\/blog\/ai-in-localization\/ai-in-localization.webp","readTime":"8 min read","searchText":"hideCta: true, title: 'AI in localization and its future role', description: \"Explore AI in localization as we debunk ChatGPT's role, celebrate Machine Translation's efficie
40ncy in Translation Management Systems.\", date: '2024 07 29', thumbnail: '\/img\/blog\/ai in localization\/ai in localization.webp', image: '\/img\/blog\/ai in localization\/ai in localization.webp', category: 'Guides', tags: ['localization', 'guides', 'ai'] AI in localization has a significant impact on brands worldwide by enabling the translation of just ten languages to reach 90% of the target market. This is particularly noteworthy, given that there are more than 7,000 languages globally. However, even localizing into five languages is a substantial undertaking that requires the adaptation of extensive content. The traditional manual process is time consuming and costly. AI and machine learning now offer a more efficient approach that is revolutionizing the localization process. As a result, the field of language localization is currently undergoing a significant transformation, driven by advancements in artificial intelligence (AI) and machine translation (MT), which eliminate misunderstandings and enhance efficiency. What Exactly Does Localization in AI Mean? AI in localization refers to the integration of artificial intelligence into the localization process to optimize translations and cultural adaptations of content, apps, software, and websites. The technology enhances the efficiency, accuracy, and impact of the entire localization workflow through machine learning and natural language processing (NLP) AI systems utilize translation memories, glossaries, and feedback loops not only to refine translation quality but also to accelerate review and project management tasks. Through the data driven approach of AI in localization, AI based systems can make context sensitive content adaptations on an unprecedented scale. The comprehensive localization process includes the adaptation of language, brand voices, visual elements, user interfaces, and date, time, measurement, and number formats to ensure cultural relevance and appropriateness. This also considers currencies and payment methods to guarantee a complete transformation of meaning that fosters understanding and acceptance in new regions or target audiences. The evolution of AI in localization To understand the current landscape of translation technology, it is important to trace its evolution. From the first rule based systems to the groundbreaking introduction of statistical machine translation (SMT) and the more recent neural machine translation (NMT), the field has made remarkable progress. All developments have enabled not only more efficient but also more accurate translation methods, laying the foundation for AI in localization. ChatGPT for Localization? Although ChatGPT has attracted a lot of attention for its ability to generate conversational like text, its role as AI in localization is overestimated. ChatGPT is primarily focused on generating human like text and is therefore particularly suitable for creative content and customer interactions. However, the limitations of this technology become apparent when precision, accuracy and domain specific expertise are required, as is typical for AI in localization. â¡ï¸ Create a new user account for free and start with AI localization immediately chatgpt What role does AI play in localization? AI driven tools are revolutionizing the management of localization projects by automating repetitive tasks, streamlining workflows and providing predictive analytics to improve decision making. AI in Localization increases the quality of deliverables, accelerates time to market and increases consistency across languages and platforms, making the process faster, more accurate and more cost effective. Within AI in Localization, there are three specific sub fields that are of particular importance in localization: Machine learning (ML) The algorithms, trained on extensive data sets, improve the accuracy of translations and automate quality assessments by translation management systems. Deep Learning (DL) An advanced form of machine learning, deep learning algorithms mimic the way the human brain works, enabling more accurate translations through neural machine translation (NMT). Natural language processing (NLP) NLP enables computers to understand and use human language, improving localization processes and the automated insertion of glossary terms. Advanced AI in localization brings significant benefits to the localization industry by not only simplifying workflows but also significantly improving the quality of localization results. In particular, machine learning and deep learning make it possible to analyze complex data and derive more precise linguistic patterns, which are essential for more effective translations. AI in Localization changes numerous localization projects: Increased efficie
40ncy: automation of routine tasks speeds up the process. Improved decision making: Using predictive analytics to optimize project management. Increased accuracy: ensuring consistency and quality across languages and platforms. In addition, natural language processing (NLP) enables deeper interaction with text by capturing nuanced aspects of language that are essential to human communication. What makes AI so interesting for companies besides AI in localization? The importance and impact of AI on companies is remarkable given the rapid pace of technological development. Numerous brands from a wide range of industries have the opportunity to use artificial intelligence to improve their operations, increase efficiency and promote growth. But what impact can the use of AI really have? Sales growth Companies using AI report high average revenue growth compared to companies without AI. This shows the positive correlation between AI usage and increased revenue. Profitability Companies implementing AI experience a greater average increase in profitability compared to those without AI, emphasizing the efficiency of AI in operations and decision making. Productivity AI users report a significant increase in productivity, compared to a much smaller increase for non AI users, highlighting the effectiveness of AI in optimizing business processes. All points illustrate how AI not only improves operational efficiency, but also creates financial and strategic benefits for organizations. AI localization vs. traditional localization: What are the differences? AI in Localization is currently overtaking traditional translation processes through the use of automated systems that perform routine tasks and conduct extensive data analysis to ensure consistency and recommend content. Unlike traditional methods, which rely heavily on the skills of individual translators, AI in Localization uses historical data and continuous learning to improve the quality and speed of translations. AI adapts to feedback and evolving language usage, complementing human skills and making the translation process more efficient. AI in Localization can also process large volumes of content quickly. This results in significant time and cost savings, as machine translation (MT) is significantly cheaper than human translation services. In addition, translation memory promotes consistency and further reduces costs by storing and reusing previously translated content. Scalability is another benefit of AI in localization, as AI driven systems can quickly adapt to new markets without the extensive manual work traditionally required. Localization in AI also enables greater personalization through technologies such as conversational AI chatbots that handle customer queries with personalized, human like responses. The human touch in localization Although AI is superior in localization in many aspects, quality remains an important consideration. Native translators and linguists are essential to capture linguistic and cultural nuances that AI can sometimes miss. Nevertheless, the quality and accuracy of AI based translations has improved significantly with advances in neural machine translation and is expected to continue to do so. A balanced approach to the use of AI that takes into account both human expertise and automated efficiency is therefore essential. AI in localization therefore requires a deep understanding of cultural nuances, linguistic subtleties and industry specific terminology. Human translators are essential for accurate and culturally appropriate translations as they can capture context and bring creativity. Direct communication with human translators minimizes the risk of missed project targets and reduces revisions. There is a common misconception that AI can completely replace human translators. In reality, AI complements the translation process by automating repetitive and time consuming tasks. This allows companies to manage their resources more efficiently, while human translators can focus on more complex and challenging tasks. The advantages of AI in localization Neural machine translation (NMT) in particular has played a significant role in enabling us to use AI in localization today. Unl
40ike ChatGPT, which is designed for general text generation, NMT systems offer specialized, scalable and cost effective translation solutions. The integration of NMT into translation management system significantly improves the efficiency and quality of the localization process. Best practices for AI in localization: Define goals Set clear objectives for localization projects to maximize the relevance and engagement of content and ensure it fits the business strategy. Select suitable tools Select the most suitable AI solutions based on accuracy, scalability and integration capabilities. Combine automation and human expertise Combine technological efficiency with human insight to capture cultural nuances and achieve the highest quality localized content. Continuous monitoring and optimization Regular evaluation and adjustment of AI in Localization to keep pace with linguistic and cultural developments and ensure the effectiveness of localization. Good to know: Translation and localization platforms seamlessly integrate NMT and support multiple languages, enabling real time collaboration and efficient project management. This integration ensures organized workflows, scalability and meets various translation requirements. A look into the future of AI in localization A look into the future already clearly shows that the competition between the AI giants Google and OpenAI will continue to intensify. While OpenAI's ChatGPT excels in language generation, Google and DeepL are characterized by continuous optimization of their translation models. The strengths of Google Translate and DeepL lie in their high translation quality and domain specific expertise. AI in Localization has created a completely new basis for the expansion of companies in international markets. Read more under market expansion strategy. Google, Microsoft and Amazon have already successfully integrated AI in Localization to improve user experience and expand global reach. For example, Google Translate uses AI algorithms for accurate translations in multiple languages, while Amazon Alexa uses AI to understand and respond to user commands in different languages. Translation management systems with machine translation are fit for the future It is clear that ChatGPT's strengths, despite its impressive capabilities, do not lie in its accuracy and scalability for translation tasks. If AI in localization is desired, the focus should be on machine translation (MT), especially when integrated with translation management systems (TMS). â¡ï¸ Create a new user account for free and start with AI localization immediately The combination of human expertise and AI driven MT is the foundation for realizing the full potential of AI in localization. AI in Localization represents a significant advance by offering scalability, efficiency and improved global reach. Implementing AI in localization processes enables companies to remain competitive and relevant in the global marketplace. By utilizing advanced AI tools and practices, businesses can successfully overcome the challenges of international expansion and achieve new levels of global engagement and customer satisfaction."},{"slug":"cat","title":"Say Hello to CAT (Computer-Assisted Translation): The Personal Translator in Your Pocket","description":"Learn how to ensure efficiency, accuracy, and overall quality in your translation work with cat tools for translation.","date":"2024-04-12","category":"Guides","thumbnail":"\/img\/blog\/cat\/title.jpg","readTime":"7 min read","searchText":"title: 'Say Hello to CAT (Computer Assisted Translation): The Personal Translator in Your Pocket', description: 'Learn how to ensure efficiency, accuracy, and overall quality in your translation work with cat tools for translation.', date: '2024 04 12', thumbnail: '\/img\/blog\/cat\/title.jpg', image: '\/img\/blog\/cat\/title.jpg', category: 'Guides', tags: ['localization', 'guides', 'cat tools'] Welcome to the world of CAT Tools, or Computer Assisted Translation Software! Table of contents What are CAT tools? What computer assisted translation tools can do? Benefits of using CAT tools for translation Locize CAT TMS and CAT tools, what is different? Choosing the right CAT tool: a buyer's guide Conclusion What are CAT tools? These handy little programs are like having a personal translator in your pocket (or on your computer, whichever you prefer). But what exactly is a CAT, you ask? Well, it's pretty much exactly what it sounds like. It's software that helps you translate text from one language to another. Think of it like having a bilingual friend who you can text whenever you come across a word or phrase you don't understand. Now, I know what you might be thinking: \"But wait, don't we already have Google Translate?\" And yes, you're right! Google Translate is a great tool for quick and easy translations. But CATs are a bit different. Unlike typical web translators, CAT tools are significantly more robust and tailored specifically to meet the needs of professional translators and businesses, ensuring enhanced efficie
40ncy, accuracy, and overall quality in translations. What computer assisted translation tools can do? Computer assisted translation tools offer a range of capabilities to streamline and enhance the translation process: Glossary Management One of the most important features of CATs is their ability to \"remember\" translations. So, if you're working on a big project and you keep coming across the same phrase over and over again, the CAT will remember how you translated it the first time and will automatically use the same translation for all future instances. This can save you a lot of time and make your translations much more consistent. Translation Memory Another great feature of CATs is their ability to work with \"translation memories\". These are databases of previously translated text, which can be used to help speed up the translation process and ensure consistency. So, if you're translating a document and you come across a sentence that's already been translated before, the CAT will pull up the previous translation and suggest it to you. Pretty cool, right? Machine Translation Among the most crucial capabilities of CATs is their adeptness at memorizing translations. Picture this: amidst a large scale project, encountering recurring phrases is inevitable. Here's where CAT tools shine. They diligently store these translations, committing them to memory. So, the next time you stumble upon that same phrase, fear not! Your trusty CAT tool will recall precisely how you translated it the first time. Seamlessly, it will apply the same translation across all subsequent instances, sparing you valuable time and ensuring impeccable consistency throughout your translations. Collaboration In the realm of CATs, the ability to collaborate seamlessly stands out as a cornerstone feature. Imagine this scenario: you're part of a dynamic translation team, dispersed across different locations, yet working towards a common goal. CAT tools serve as the virtual hub where translators, editors, and stakeholders converge in real time. Through robust collaboration tools, communication flows effortlessly, files are shared effortlessly, and version control is maintained meticulously. Whether you're providing feedback, making revisions, or simply brainstorming ideas, these tools ensure that every member of the team remains synchronized and empowered to contribute their expertise. As a result, collaboration becomes not just a process but a catalyst for achieving unparalleled translation outcomes. Locize CAT Within Locize there is a ready to go CAT tool comprising three distinct views. Global View The global view provides an overview of all segments. Read more in the global view docs. In Context View Your website, where the content is displayed, is always the best context. Therefore there is also an in context view. Benefits of using CAT tools for translation So, to sum it up, CATs are like having your own personal translator who never forgets anything and can access a vast library of translations. If you're a professional translator, they're an absolute must have tool. And if you're not, they can still be a handy tool to have around for those times when you need to translate something quickly and easily. However, what precisely are these amazing technologies capable of, and how might they help you? Let us examine the various benefits and features of computer assisted translation as we go deeper into this field. Efficiency There is an unmatched efficiency in the field of CAT tools. Imagine being able to move quickly through projects by reusing previously translated segments thanks to the power of translation memory. This simplified procedure not only expedites your work but also frees up valuable time to concentrate on polishing your translations to excellence. Accuracy CAT tools are known for their precision. Think about this: you have a vast array of automated recommendations at your disposal as you utilize the machine translation integration. However, the final translation is guided by your perceptive eye, making sure that every word conveys the intended meaning. Accuracy is not only an objective when you have CAT tools on your side; it is a standard that is steadfastly maintained. Time Savings CAT tools are a match for time, that elusive resource. Imagine this: you can translate words with
40never before seen speed as you take use of glossary management and translation memory. What used to take hours now only takes minutes, allowing you to spend more time refining your craft without worrying about running out of time. Cost Savings When it comes to CAT instruments, precision and efficiency work together to produce substantial cost savings. Think about this: more productive workflows reduce the need for time consuming manual translations. Every translation project becomes an accomplishment to the wise investment made in CAT tools as you maximize your resources and reduce the margin for mistake, opening you a world of unmatched value and affordability. TMS and CAT tools, what is different? TMS and CAT tools play distinct roles in translation workflows, with CAT often being a component of TMS. Translation management systems (TMS) oversee project logistics, while Computer Assisted Translation (CAT) tools provide specialized support to translators. CAT tools, commonly integrated within TMS platforms, offer features like translation memory and glossary management, enhancing efficiency and consistency in translation tasks. Choosing the right CAT tool: a buyer's guide When selecting a Computer Assisted Translation (CAT) tool, consider the following factors to ensure it aligns with your needs: Translation Needs Assess your translation requirements, including languages, file formats, and volume, to ensure the CAT tool can accommodate them. Why choose Locize: Locize supports multiple languages and file formats, ensuring compatibility with diverse translation needs and volumes. Features Look for essential features such as translation memory, glossary management, and integration with machine translation, as well as advanced capabilities like terminology extraction and quality assurance checks. Why choose Locize: Locize provides essential features such as translation memory and glossary management, ensuring consistency and efficiency in translations. Additionally, its advanced capabilities like in context editing and version control enhance collaboration and streamline the translation process. User Interface Evaluate the user interface for intuitiveness and ease of use, as a user friendly interface can enhance productivity and reduce learning curves. Why choose Locize: Locize boasts an intuitive and user friendly interface, making it easy for translators and project managers to navigate and utilize its features effectively. Compatibility Ensure compatibility with your existing systems and workflows, such as content management systems (CMS) or project management tools, to facilitate seamless integration. Why choose Locize: Locize seamlessly integrates with popular content management systems (CMS) and development frameworks, allowing for seamless integration into existing workflows. Support and Training Consider the level of customer support and training provided by the CAT tool vendor, including documentation, tutorials, and technical assistance, to ensure smooth implementation and ongoing usage. Why choose Locize: Locize provides comprehensive documentation, tutorials, and responsive customer support to assist users during implementation and ongoing usage. Scalability Choose a CAT tool that can scale with your business growth, accommodating increasing translation volumes and evolving requirements over time. Why choose Locize: Locize is designed to scale with your business, accommodating growing translation volumes and expanding requirements effortlessly. Security Prioritize security features such as data encryption, access controls, and compliance with industry standards (e.g., GDPR) to safeguard sensitive information. Why choose Locize: Locize prioritizes data security, employing robust encryption protocols and adhering to strict compliance standards to safeguard sensitive information. Cost and Licensing Evaluate the pricing structure and licensing options, including subscription based or perpetual licenses, to determine the most cost effective solution for your budget and usage needs. Why choose Locize: Locize offers flexible pricing plans tailored to fit different budgetary constraints and usage needs, ensuring cost effectiveness and value for money. Trial Period Take advantage of trial periods or demo versions offered by CAT tool vendors to assess the softw
40are firsthand and ensure it meets your expectations before making a commitment. Why choose Locize: Locize provides a free trial period, allowing users to experience the platform firsthand and assess its suitability before making a commitment. More than a CAT Tool Consider if the CAT tool integrates well with Translation Management Systems (TMS) if your workflow requires it. Why choose Locize: Locize offers seamless integration with TMS platforms, ensuring smooth collaboration and streamlined workflows for translation projects. Conclusion In conclusion, CATs are the perfect tool for professional translators and anyone who needs a helping hand with translations! So, don't be shy, give them a try!"},{"slug":"market-expansion","title":"Market Expansion Strategy: Types, Process & Examples","description":"A market expansion strategy is a plan for entering new markets or reaching new customer segments, through one of four moves (market penetration, product development, market development, or diversification). This guide covers the framework, the process, and what to do when it fails.","date":"2024-03-21","category":"Guides","thumbnail":"\/img\/blog\/market-expansion\/market-expansion-strategies.webp","readTime":"18 min read","searchText":"title: 'Market Expansion Strategy: Types, Process & Examples', description: 'A market expansion strategy is a plan for entering new markets or reaching new customer segments, through one of four moves (market penetration, product development, market development, or diversification). This guide covers the framework, the process, and what to do when it fails.', date: '2024 03 21', thumbnail: '\/img\/blog\/market expansion\/market expansion strategies.webp', image: '\/img\/blog\/market expansion\/market expansion strategies.webp', category: 'Guides', tags: ['localization', 'guides', 'strategy'], faq: [ q: 'What is a market expansion strategy?', a: 'A market expansion strategy is a strategic plan to grow a business into a new market or customer segment. It defines what to sell, where to sell it, how to enter, and how to measure success. The four classic models (market penetration, product development, market development, and diversification) come from the Ansoff matrix and differ by whether the product is new and whether the market is new.' , q: 'What are the four market expansion strategies?', a: 'The Ansoff matrix defines four: (1) market penetration, sell more of an existing product in an existing market; (2) product development, sell a new product to an existing market; (3) market development, sell an existing product to a new market or geography; (4) diversification, sell a new product to a new market. Risk and reward both increase as you move from (1) to (4).' , q: 'What is the Ansoff matrix?', a: 'The Ansoff matrix is a 2Ã2 grid (existing\/new product à existing\/new market) introduced by H. Igor Ansoff in his 1957 Harvard Business Review article \"Strategies for Diversification\". It produces the four classic growth strategies: market penetration, product development, market development, and diversification. It is still the standard framework taught in MBA strategy courses.' , q: 'What is the difference between market penetration and market development?', a: 'Market penetration grows revenue inside an existing market with an existing product (more customers, higher share, more usage). Market development takes that same existing product into a new market, usually a new geography, a new customer segment, or a new channel. Penetration is lower risk; development requires localization, new go to market work, and often regulatory navigation.' , q: 'What is the riskiest market expansion strategy?', a: 'Diversification (launching a new product into a new market) is the riskiest of the four because both unknowns compound. Both the product and the market lack proven traction. The reward, when it works, is the highest of the four; the failure rate is also the highest. Companies typically only diversify once they have strong cash flow from existing markets to absorb a long payback period.' , q: 'How do you develop a market expansion strategy?', a: 'A typical process: (1) set S
40MART goals, (2) conduct market research and competitive analysis, (3) define and rank target markets, (4) choose a market entry strategy (export, license, franchise, subsidiary, partnership, acquisition), (5) localize marketing and product, (6) plan operations and supply chain, (7) build a financial plan, (8) monitor and adjust. Localization (translating product, marketing, and support into the target language) is usually the difference between expansion that takes hold and expansion that stalls.' , q: 'How important is localization for market expansion?', a: 'Critical. CSA Research found that 40% of consumers will never purchase from a website not in their native language, and 75% are more likely to buy again if aftersales care is in their native language. Most expansion strategies fail at the language and cultural fit step, not at the product or market research step. A translation management system (TMS) and a localization strategy are practical prerequisites for any market development or diversification move.' ] A market expansion strategy is a strategic plan to grow a business into a new market or customer segment, defining what to sell, where, how to enter, and how to measure success. The four classic models come from the Ansoff matrix: market penetration (existing product, existing market), product development (new product, existing market), market development (existing product, new market), and diversification (new product, new market). Risk and reward both increase as you move from market penetration to diversification, and most successful expansions combine the strategy with a strong localization plan, because language and cultural fit are usually where expansions stall, not the product or the market analysis. Key facts What it is: a plan for entering a new market or reaching a new customer segment Framework: Ansoff matrix (1957), 4 strategies based on product à market combinations Four strategies: market penetration, product development, market development, diversification Risk order (low â high): penetration â product development â market development â diversification Common failure point: language and cultural fit, not product or market research Localization stat: 40% of consumers never buy from a site not in their native language ( CSA Research ) Expansion aims to penetrate a new market or address a new target group. Done well, it lays the foundation for sustainable growth and increased sales of your products or services. Done badly, without a real strategy, it produces expensive failures, abandoned launches, and stalled internationalization. This guide explains the framework, the process, and what to do when an expansion strategy fails. Table of contents What is a market expansion strategy? Why consider market expansion? What are the advantages of a market expansion strategy? What market expansion strategies are there? How to go about developing a market expansion strategy? What if the market expansion strategy fails? What is a market expansion strategy? A market expansion strategy is a strategic plan to expand your business into a new market. You are tapping into a customer segment that you have not previously addressed with your products or services. Overall, market expansion strategies are actually your maps that show you the way, be it geographically and\/or in relation to a target group, to growth, increased sales and market placement. Why consider market expansion? There are various reasons why a company decides to expand its market. One of the most frequently mentioned is increasing sales. Especially if your own market is saturated, it is worth thinking outside the box and expanding into a target market where demand and, as a result, sales potential are still high. Usually, a business starts in a specific region or offers everything in English. So basically, it starts with one language only. Now think about offering your content in other languages, starting with your website. Do you think this is not relevant? Ok, then consider this article. According to it, 40% of consumers say they will never purchase from a website not in their native language. While 75% say they are more likely to use a business again if aftersales care is in their native language. Effective localization ensures your product meets the needs of your demographics and helps you reach new audiences. With nearly five billion smartphone users globally, the localization of apps and websites ensures customers can enjoy your product wherever they are. You won't add or change any features. You simply offer what you have in a few more languages. Here are the top 10 most spoken languages in the world: 1. Chinese: 1.3 Billion Native Speakers 2. Spanish: 471 Million Native Speakers 3. English: 370 Million Native Speakers 4. Hindi: 342 Million Native Speakers 5. Arabic: 315 Million Native Speakers 6. Portuguese: 232 Million Native Speakers 7. Bengali: 229 Million Native Speakers 8. Russian: 154 Million Native Speakers 9. Japanese: 126 Million Native Speakers 10. Lahnda (Western Punjabi): 118 Million Native Speakers When we count the top 10 most spoken languages according to the total number of people who speak them (whether or not the language is their mother tongue), it looks slightly different: 1. English: 1.348 billion total speakers 2. Mandarin Chinese: 1.120 billion total speakers 3. Hindi: 600 million total speakers 4. Spanish: 543 million total speakers 5. Standard Arabic: 274 million total speakers 6. Bengali: 268 million total speakers 7. French: 267 million total speakers 8. Russian: 258 million total speakers 9. Portuguese: 258 million total speakers 10. Urdu: 230 million total speakers A little mind experiment: What if you offered your website and product in Chinese, Hindi, and Spanish, besides English? You would target an additional audience of 2.266 billion speakers. This makes a potential growth of 268%! With a market expansion strategy in hand, diversification always goes hand in hand. This gives you the significant advantage of spreading the risk that you have when you only depen
40d on one market. Even in the face of fluctuations in the economy, political events or the unforeseeable, your company remains much more robust. Also take advantage of the economy of scale. By spreading your expenses over a larger output, you can multiply your efficiency but reduce your costs in the long term. Being present in multiple markets inevitably leads to greater visibility and therefore greater brand awareness. This means that not only sales but also the market value increase. At the same time, you can keep up with your competitors or even set yourself apart from them. From an even different perspective, market expansion gives you access to new talent that can prevent a shortage of skilled workers. You may also discover new, advanced technologies and business practices in a new market that you were not aware of before, but that could significantly increase your productivity and competitiveness. What are the advantages of a market expansion strategy? A well planned market expansion strategy is, to put it bluntly, half the battle when it comes to your expansion. Above all, it helps you achieve your long term goals and ensure that your growth is continuous but controlled. Advantages of a Market Expansion Strategy are: 1. Risk reduction By carrying out market research and analysis and starting pilot projects in a market expansion strategy, you can avoid possible risks of market expansion. Proactively identify, take appropriate countermeasures and thus minimize them. With a strategic approach, you avoid having to pay expensive fees and at the same time increase the likelihood of a successful market entry. 2. Resource allocation Your resources, be it capital, staff or time, are limited. So that you can really use this effectively for your expansion, a market expansion strategy is essential. For example, you can identify the most attractive markets in advance, use the economies of scale and create synergies between different markets and your business areas. 3. Competitive advantage If your market expansion strategy is successful and you open up new markets, you will build sustainable competitive advantages. In other words, a market expansion strategy enables you to meaningfully differentiate your products and services from your competitors, to establish them strongly in the market and to build a loyal customer base. 4. Innovation and learning In addition to the advantages of risk minimization or resource distribution, a market expansion strategy always promotes internal company development, which you should not despise. Ultimately, a market expansion strategy requires new ideas, progressive business models and engagement with other cultures, target groups and competitors. Market expansion can also mean that you have to optimize your products or services for the new market or even be inspired to create completely new ones. Furthermore, the experience and knowledge that you will gain from the expansion will be available to you in the long term, which you can then transfer to other areas of your company. 5. Brand perception and the global image An equally notable advantage of a market expansion strategy is that you can use market expansion to build up your image and the perception of your brand in a controlled manner. Be it with an international market expansion strategy or global market expansion strategies. Once the foundation has been laid, you can strengthen the trust of customers, investors and business partners and manage the entire process yourself, which contributes significantly to ensuring a reasonable reputation. What market expansion strategies are there? A distinction is made between four market expansion strategies that you can use depending on your goals: Market penetration Product development Market development Diversification Fortunately, these are not just purely theoretical approaches, but rather market expansion strategies that you can immediately implement in practice. We'll tell you what this might look like in the next sections. Market penetration (existing product, existing market) With market penetration as your market expansion strategy, you focus on strengthening your existing products or services in your current market and increasing their sales. Ergo, you try to sell more of what you offer, be it to existing customers or new customers. The approach is often the first step that companies implement as part of their market expansion strategy. Importantly, market penetration only works effectively if the market is not yet saturated. However, your risk remains low because you neither venture into unknown territory nor have to spend a lot of money. What helps you with this market expansion strategy with the goals of increasing market share, competitiveness and profit maximization are pricing strategies, advertising campaigns, sales promotions or improving services such as customer service. However, the growth potential remains manageable with this approach. A classic example of market penetration is a company lowering its prices to attract more customers. A wireless carrier offers discounts or improved tariff plans to attract or persuade customers to
40switch from a competitor. Product development (new product, existing market) When developing products as part of your market expansion strategy, you optimize your existing products and services for your market, modify variants or introduce a completely new offering. The aim is to better penetrate your existing markets or open up new market segments. This can be achieved by focusing on increasing customer value for your product range. With this market expansion strategy, always make sure that you take customer wishes into account in all innovations and improvements in order to stand out from your competitors in the long term. Since you have to spend a little more money on product development, the risk also increases compared to market penetration. To avoid bad investments, you can pursue the virtual prototyping approach. You test your innovation BEFORE the actual development within a virtual environment under completely real conditions and marketing levels. This includes setting up a web presence. An example of product development is introducing a new smartphone model with improved features and performance to encourage existing fans to upgrade and attract new, tech savvy customers. An outstanding role model for such a market expansion strategy is undoubtedly Apple. Market development (existing product, new market) Do you have an excellent product and want to conquer a new sales market? Then market development is your market expansion strategy. In market development, you strive to take your existing products or services into new markets. This can mean both geographical expansion (domestic or international) as well as addressing new target groups or opening up additional sales channels. The main goal is to discover new sales potential and expand your customer base. One advantage of this market expansion strategy is that you don't have to spend any money on further developing your products. However, market developments require that you have a thorough knowledge of the new field, its players, opponents and spectators. Furthermore, it is essential to carry out very finely graded target group marketing, which takes the respective cultural characteristics into account. An example would be a food company that wants to sell its products internationally to reach new geographical markets. Diversification (new product, new market) Probably the most comprehensive, risky, but also, if successful, strongest market expansion strategy is diversification. This means you are introducing a new product to a new market. There are two main types of diversification: related and unrelated diversification. With related diversification, you expand your offerings into areas that are logically related to your current environments. With unrelated diversification, you enter completely new business areas that have no direct connection to your previous activities. Note that these market expansion strategies involve an investment of money and time. However, if the equation of the two unknowns works out, the effort will undoubtedly have been worth it due to the enormous increase in sales. An example of diversification would be a clothing manufacturer starting to produce and sell sports equipment (if this is related diversification) or entering the technology industry (if it is an unrelated diversification). If you can't decide between the four market expansion strategies or would like to benefit from the advantages of several strategies, there are intermediate solutions: Market expansion: strategy of selling established products within new geographical markets while maintaining target group consistency. Product Modification: approach to bridging the gap between market penetration and product development by making slight adjustments to existing products to reintroduce them into the current market. Limited diversification: adapting existing products to enter new geographical markets. Partial diversification: strategy that involves either distributing new products into geographically new markets or introducing modified products to new target groups. How to go about developing a market expansion strategy? Now you know
40what a market expansion strategy is, its advantages and its four common models. Now let's get to one of the most interesting parts: How do you develop such a strategy in practice? set the goals 1. Set the goals Before starting your market expansion, you should set clear, measurable and realistic goals. All goals should address different aspects of your expansion, including sales, market share, customer acquisition, and brand awareness. Use the SMART principle when setting goals. What are SMART goals? Specific : Define exactly what you want to achieve in each new market. For example, you could aim to achieve a certain level of sales or capture a certain percentage of market share within the first year of entering the market. Measurable : Make sure you can quantify your goals. This allows you to track progress over the long term and measure your successes. Examples of measurable goals could be: selling 10,000 units of your product in the first year or acquiring 500 new customers in the first six months. Attainable : Your goals should be challenging but realistic. To do this, consider your resources, competition and market conditions. Relevant : All of your goals should be closely tied to your company's overall business goals and overall strategy. They should help carry and support your companyâs long term vision and mission. Timely : Set clear deadlines for achieving your goals. Timelines help you stay motivated, plan and monitor progress. A complete example goal according to the SMART variant could be: âWe increase sales by 20% within one year of market entry by selling product X in the new target market Y.â This goal is specific (increase revenue by selling a specific product), measurable (20% increase in revenue), achievable (based on a realistic estimate), relevant (contributes to overall revenue growth), and time bound (within a year). By incorporating clearly defined goals into your market expansion strategy, you can better measure the success of your measures and ensure that all activities are aimed at achieving these goals, and, above all, remain so. 2. Market research and analysis Once your goals are clear, the Market Expansion Strategy involves creating a comprehensive analysis of potential new markets. Take a close look at demographics, economic indicators, cultural differences, legal frameworks and technological developments. Study the competitive landscape to understand your competitors' strengths and weaknesses and identify gaps in the market that you may be able to exploit. Use online resources such as Statista, MarketResearch.com or national statistical authorities to collect relevant market data. Conduct surveys or focus groups with potential customers to get direct feedback and understand customer segments. Analyze social media and customer reviews to gain insight into trends and preferences. 3. Define target market Based on your market research, you should now be able to select the most attractive markets for your market expansion strategy. Your decision will be based on factors such as market size, accessibility, growth potential and fit with your product or service offering. Always take your own company goals and resources into account. Create a ranking of your preferred markets based on quantitative and qualitative criteria. Consider market entry costs and operational costs in different markets. Conduct a SWOT (Strengths, Weaknesses, Opportunities, Threats) analysis for each potential market. 4. Develop market entry strategy Is your new target market located? We are entering the hot phase of the market expansion strategy. Decide now how you want to enter the market: through export, licensing, franchising, setting up a subsidiary, partnership or acquisition. Each of these options entails different investment requirements, risks and levels of control. So take your time and look at each of the options carefully. Consider establishing strategic partnerships or joint ventures with local companies to overcome potential barriers to entry. Evaluate the advantages and disadvantages of each market entry option in light of your business goals and resources. Consult local experts or advisors to be able to meet legal and regulatory requirements later. 5. Adjust marketing and sales strategy Of course, you want to reach your target group as quickly as possible after entering the market. This is achieved by designing marketing and sales strategies that are specifically tailored to the target market. Take cultural characteristics, language, local trends and target group behavior into account. Adjust your product offerings, pricing models, advertising messages and sales channels accordingly. Develop culture specific marketing materials and campaigns that resonate with the target market. Carefully select sales and distribution partners who have good knowledge of the local market. Use digital marketing and social media to effectively reach your target audience. Website and translation management Your market expansion strategy should prioritize the establishment of a comprehensive localization strategy. This involves the adoption of a sophisticated translation management system (TMS) and a well orchestrated approach to localization that ensures your website resonates with the target audience both linguistically and culturally. Invest in a robust translation management system that streamlines the localization process, ensuring efficiency and consistency across all digital content. A TMS can facilitate collaboration among translators, editors, and project managers, significantly reducing the time and effort required for large scale localization projects. Develop a localization strategy that extends beyond mere translation. Understand the cultural nuances, consumer behaviors, and market trends of your target region. This strategy should encompass local customs, values, and preferences, ensuring that your website, from content to visuals, al
40igns with the local culture. Collaboration with local experts or professional translators is crucial for achieving authentic and culturally relevant content. They can provide insights into local expressions, units of measurement, holidays, and other cultural specifics, enhancing the local appeal of your website. Emphasize the adaptation of your digital presence to mobile platforms, considering the predominant use of mobile internet in many target markets. A mobile optimized website is not just a preference but a necessity for reaching a wider audience. Incorporate local customer feedback and analytics into your strategy to continuously refine and optimize your localized content. This feedback loop can identify areas for improvement, helping you better cater to the local audience's needs and preferences. Engaging with a specialized agency can offer valuable expertise in both localization and the technical aspects required for a successful international web presence. Such partnerships provide access to specialized skills and knowledge, from professional translations to technical optimizations, ensuring that your localization strategy is effectively implemented and aligned with your business objectives. â¡ï¸ Create a free new user account for a transformative localization experience 6. Operations and supply chain management Every market expansion strategy also requires you to plan your logistics and the associated operational processes in detail. There are few things today that have a more negative impact on your success than an inefficient supply chain. Ultimately, it's about customer service. And they are now used to receiving everything without long delivery times or detours. Also take local specifics such as logistics, customs, taxes and labor into account. Establish robust supply chain processes and work with reliable, local suppliers and logistics partners. Comply with local regulations and standards regarding production, packaging and labeling. Implement effective inventory and warehousing management to avoid supply shortages. 7. Financial planning With a market expansion you are of course also aiming for an increase in sales. Accordingly, part of your market expansion strategy is to prepare detailed financial forecasts and set budgets. Take into account both one off costs (e.g. market entry costs) and ongoing operating costs. Also plan buffers for unexpected expenses and potential currency risks. Include financial models in your market expansion strategy to run through different scenarios and see how different market situations affect your finances. Secure sufficient financing and liquidity to support the expansion phase. Implement an effective cost control and monitoring system to keep track of your finances. 8. Monitoring and adjustment The basis for your long term success in a new market is continuous monitoring and evaluation of your activities. Within the Market Expansion Strategy, you should consider the progress of your set goals, both your market performance and performance, and customer feedback. It's important that you collect quantitative and qualitative data to get a complete picture of your expansion. Use CRM systems, analytics tools and financial reporting to track key performance indicators (KPIs) such as sales, market share, customer acquisition and customer satisfaction. Schedule regular sessions (e.g. monthly or quarterly) to assess and discuss progress. To do this, you put together a team from different areas to include different perspectives. Actively collect feedback from customers, partners and employees in the new market. Use surveys, customer interviews and market research to gain insights into market reaction and customer needs. But also be prepared to adjust your market expansion strategy based on the results. Be prepared for changes to products, marketing approaches or even the entire market entry strategy. What if the market expansion strategy fails? If your market expansion strategy fails, it is important not to lose heart or jump to conclusions. Failure is a natural part of entrepreneurship and holds valuable lessons that will help improve your future market expansion strategy. First, you should conduct a thorough analysis to identify the reasons for the failure of your market expansion strategy. Illuminate all aspects of your market expansion strategy, from market research and target group analysis to marketing and sales. Take a close look at which assumptions were wrong, which approaches didn't work, and whether external factors such as economic changes or unforeseen events played a role. Use this opportunity to learn from your mistakes and optimize your market expansion strategy. This might mean better understanding your audiences, adapting your products or services, or rethinking your marketing and sales efforts. Based on your analysis and the insights gained, you can then adjust your market expansion strategy accordingly. This means both minor optimizations and a comprehensive revision of your market expansion strategy plans. Be open to change and willing to try completely new things. After you've refocused your market expansion strategy, develop a new plan for entering the market or refocusing your operations. To do this, set yourself realistic goals and milestones and make sure that you have sufficient resources for implementation. It should be said again: failure is not a reason to give up. Many successful companies initially failed before they found their way to success. Maintain your resolve and stay committed to pursuing your business goals. What's important is that you learn from every failure and use this unique knowledge to improve your future endeavors. By remaining resilient and willing to adapt and learn, you can increase your chances of future success. Frequently Asked Questions frontmatter.faq.map(( q, a ) = ( q a ))"},{"slug":"localization-strategy","title":"Localization strategy insights for Tech Executives","description":"What a localization strategy is, why fast-growing tech companies need one, the challenges (speed versus quality, consistency, cost), the role of collaboration and a translation management system, a step-by-step plan, the benefits, a checklist, examples from WWF and Starbucks, and what changed in 2026 with AI translation, coding agents and the EU AI Act.","date":"2024-02-09","category":"Guides","thumbnail":"\/img\/blog\/localization-strategy\/thumbn
40ail.jpg","readTime":"12 min read","searchText":"hideCta: true, title: 'Localization strategy insights for Tech Executives', description: 'What a localization strategy is, why fast growing tech companies need one, the challenges (speed versus quality, consistency, cost), the role of collaboration and a translation management system, a step by step plan, the benefits, a checklist, examples from WWF and Starbucks, and what changed in 2026 with AI translation, coding agents and the EU AI Act.', date: '2024 02 09', updated: '2026 09 09', thumbnail: '\/img\/blog\/localization strategy\/thumbnail.jpg', image: '\/img\/blog\/localization strategy\/title.jpg', category: 'Guides', tags: ['localization', 'guides', 'strategy', 'localization strategy', 'translation management', 'ai', 'eu ai act'], faq: [ q: 'What is a localization strategy?', a: 'A localization strategy is the plan that decides which markets and languages a company serves, in what order, with which content, at what quality level and through which process, so that entering the next market is a repeatable operation instead of a project that starts from scratch. It covers product, marketing and support content, the tooling and automation used to translate it, who reviews it, and how success is measured.' , q: 'Why do tech companies need a localization strategy?', a: 'Because localization done as an afterthought produces exactly the problems that slow growth: releases blocked by translation handoffs, inconsistent terminology across screens, costly recalls of marketing material that missed a cultural or legal requirement, and no way to tell whether a market is working. A strategy decided once turns each of those into a process decision instead of a recurring emergency.' , q: 'What should a localization strategy include?', a: 'Market and language priorities, the content in scope (product UI, website, documentation, support, legal), the quality bar per content type, the translation process (human, machine, AI, and where human review is mandatory), terminology and style rules, the tooling that connects development and translation, ownership and roles, budget, and the metrics used to judge whether a market is worth the investment.' , q: 'How do you measure whether a localization strategy works?', a: 'With a small set of metrics tracked per market: time from a string being written to it being live in every language, translation coverage and the size of the review backlog, quality signals such as automated check findings and user reported errors, and the business outcomes the market was entered for: sign ups, conversion, retention and support volume in that language compared with the default language.' , q: 'How do AI translation and the EU AI Act change localization strategy in 2026?', a: 'AI translation makes the first draft nearly free, which moves the strategic decisions to terminology governance, review policy and provenance: which strings need a person regardless, who approves what, and how that is recorded. Since August 2, 2026, Article 50 of the EU AI Act applies; under the European Commission\\'s final guidelines a faithful AI translation is exempt from machine readable marking, and AI generated text that informs the public on matters of public interest needs a visible disclosure unless it has undergone documented human review under a person holding editorial responsibility. A strategy written in 2026 names that review step explicitly. This is not legal advice.' ] A localization strategy is the plan that decides which markets and languages a company serves, in what order, with which content, at what quality level and through which process, so that entering the next market is a repeatable operation instead of a project that starts from scratch each time. For a tech company it covers the product UI, the website, documentation and support, the tooling and automation that translate them, the people who review the result, and the numbers that tell you whether a market is working. Today, you're going to learn how to build a localization strategy that will help you grow your company quickly, with a method to increase your sales and make your customers happier. We provide you with a step by step plan of what you need to get to your localization strategy, and we show you examples of major brands and how they did it. Ke
40y facts A localization strategy is a set of decisions, not a translation order: markets and their order, content in scope, quality bar per content type, process, ownership, budget and metrics. The recurring trade off is speed against quality, and the way out is process, not heroics: localization integrated early in development, clear guidelines, automation for the mechanical work and human review where it matters. Collaboration needs a shared system: product, development and localization teams working in one translation management system with real time delivery, versioning, translation memory and history. 2026 changes the emphasis: AI translation makes the first draft nearly free, coding agents draft strings inside code changes, and Article 50 of the EU AI Act (in force since August 2, 2026) makes documented human review the exemption path for public interest content. What you can expect Introduction to Localization Strategy The Need for a Localization Strategy Challenges in Localization The Role of Collaboration in Localization Developing Your Localization Plan Benefits of localization Localization strategy in 2026: AI, agents and the EU AI Act Your Localization Checklist Success Stories: Localization in Action Conclusion and Summary Frequently asked questions Introduction to Localization Strategy A localization strategy tailors a company's market approach to accommodate the purchasing habits, customer behaviors, and cultural differences in each country it operates. As the CTO, manager or tech lead of a fast growing tech company, you're likely focused on maintaining a competitive edge and scaling your product to reach a global audience. However, localization can often be an afterthought in the software development process, and the lack of a clear localization strategy can lead to delays, inconsistencies, and increased costs. The Need for a Localization Strategy Developing local leadership and skills in new markets can be challenging, with unexpected obstacles such as compliance with local laws. Therefore, globalization should be a gradual strategy, considering the real costs, time, and opportunities new markets present. Harvard Business Review describes the capabilities successful global companies build before they expand. Successful global companies operate by: Ensuring they possess the required expertise and skills. Aligning international opportunities with the company's goals and capabilities. Adapting marketing policies and processes to the opportunity. Maintaining legal and ethical standards with international flexibility. Promoting a culture tolerant of financial uncertainty and market fluctuations. Preparing thoroughly and accepting the occurrence of mistakes, which is essential for effective localization strategy. â¡ï¸ Localization makes products fit better with local cultures and needs, helping to attract new customers more easily. This approach helps a company grow globally by being more relatable to different audiences. Challenges in Localization One of the key challenges in localization is striking the balance between speed and quality . On one hand, you want to get your product to market as quickly as possible, but on the other hand, you also want to ensure that your localized content is accurate, relevant, and culturally appropriate. To achieve this balance, it's essential to integrate localization early in the development process and to establish clear guidelines and processes for your localization team. Learn more in Localization should be fun. Another challenge is maintaining consistency and reducing costs as your product and localization team scale. To tackle this, you can implement automation, translation memory and a glossary that improve efficiency and reduce the need for manual translation, and route what still needs human eyes through a review workflow. The Role of Collaboration in Localization Involving all stakeholders, including product, development, and localization teams, in the localization process ensures consistent content and streamlines the process. A centralized translation management system (TMS) facilitates this by supporting real time translation delivery, version control, translation memory, and team collaboration tools. Locize serves as an effective solution for achieving these objectives: a user friendly localization platform offering real time translation delivery, collaborative features, advanced options such as versioning and translation memory, and an extensive variety of integrations compatible with existing tools and workflows. Developing Your Localization Strategies Prepare: Team Setup: Choose the right team and set achievable deadlines. Local Talent: Hire locals for insights and use a TMS for quick collaboration and feedback. Gather Inputs: Market Analysis: Study market potential and audience needs. Feature Selection: Decide on features and content for localization. Pricing Strategy: Understand pricing within legal and economic contexts. Competitive Landscape: Identify competitors and consumer trends. Use Technology: Adopt TMS and automation for smoother localization. Create Your Vision: Define Purpose: Craft distinct mission and vision statements. Local Insights: Work with or build local teams for market understanding. Brand Adaptation: Keep brand core consistent with local tweaks for relevance. Build the Plan: Adaptation Plan: Localize products, apps, and sites for language and culture. Business Strategy: Outline a global business plan with localized goals. Local Marketing: Use global brand principles with local marketing tactics. Learn about localization marketing in Localization marketing. Content Strategy: Plan messaging, graphics, and UX, ensuring consistency with TMS. Cultural Sensitivity: Navigate cultural nuances and respect local customs. E commerce Considerations: Adapt to local payment and tax requirements. Quality Policy: Decide per content type what machine or AI translation may ship after automated checks, and what needs a person to review regardless. Make Tests with Localized Content: Market Testing: Check responses to localized messages and adjust with TMS. Customer Experience: Align customer journeys with local expectations using TMS analytics. Put the Strategy into Practice: Enhance Collaboration: Improve global and local team feedback loops. Unified Approach: Ensure teamwork across departments for a cohesive strategy. Measure Success: Set and track KPIs. Workflow Management: Create scalable processes for multi language management. Benefits of localization 1. It helps to reduce immediate costs Lack of preparation can result in significant up front expenses like product or service recalls or the need to alter marketing tactics when entering a new market. If you use a thorough localization plan, the likelihood of the above happening and the added costs that result from it will be reduced. 2. It improves branding's trust It considers the branding colors and marketing messages that are suitable for the regional market. Every nation has a different idea of what is \"normal.\" The promotion of new goods and services is one of branding's most significant advantages. People who are loyal to a brand are inevitably interested in any new products the brand releases. This is essential for brands which are going global. 3. It opens revenue that a single language cannot reach Markets you do not speak to in their language are markets you mostly do not sell to. Industry surveys regularly report that c
40ompanies which localize grow faster in the markets they localize for; the size of the effect depends on the product and the market, so measure it per market rather than trusting an average. Utilizing the right translation management system in internationalization significantly boosts efficiency for project managers and translators, enhancing both revenue and return on investment. This approach streamlines content management and minimizes the need for manual coordination, maximizing resource use. 4. It reduces customer churn The number of consumers or subscribers who ceased using your product or service over a specific time period is referred to as your customer churn rate. The degree to which your product will satisfy customers and reduce customer turnover depends on a number of factors. Localization is helping to reduce overall churn in this situation. The most crucial factors, including language barriers, local customer habits, and cultural considerations, will be taken into account during localization of a business. Localization strategy in 2026: AI, agents and the EU AI Act Three things changed since this guide was first written, and each moves a strategic decision. The first draft is nearly free. AI translation with a glossary and style guide as context produces usable drafts for most UI and marketing copy in seconds. The strategic question is no longer \"can we afford to translate this\" but \"which strings need a person regardless of how confident the model is\": legal notices, pricing, safety and medical wording, accessibility labels. A quality policy per content type belongs in the plan, and quality estimation lets you route review attention by confidence instead of by chance. Coding agents draft translations inside code changes. The assistant that writes the feature now also writes the twelve language files, with more context than a translator usually gets and no memory of last month's terminology decisions. The strategy has to say where terminology, review and history live so that agents draft through that system instead of around it; the glossary and the review workflow are the two pieces agents cannot carry on their own. Compliance became date anchored. Since August 2, 2026, Article 50 of the EU AI Act applies. Under the European Commission's final guidelines of July 20, 2026, a faithful AI translation counts as standard editing and is exempt from the machine readable marking duty, while AI generated text published to inform the public on matters of public interest needs a visible disclosure unless it has undergone documented human review with a person holding editorial responsibility. The practical consequence for a localization strategy: name the review step, name who holds editorial responsibility, and keep the record. The Article 50 explainer covers the legal background and the workflow guide the setup; neither is legal advice. In the EU, the European Accessibility Act adds a second driver: accessible, correctly localized interfaces are a requirement for many digital products and services, not a nice to have. Your Localization Checklist If you have setup your localization strategy and successfully decided how you will structure the corporate website, then it's time to start localizing your content. The meaning of localization is adjusting your content to encourage customers in new markets to buy from you. Decide how to integrate localization in the development process Let your developer add new segments to translation management system Define terminology and style rules once, in a glossary and a style guide, so translators, machine translation and AI use the same ones Let your translators start the work, with AI drafts where your quality policy allows it Review the work of the translators, and record who approved what Deliver the content to the end users Check your progress with project metrics â¡ï¸ Especially with using a localization service, you can see the impact of your content and the strategy right away when entering new markets . You can also determine whether the strategy is working as intended. Success Stories: Localization in Action Localization has clearly become a competitive advantage. If your business wants to enter and thrive in new markets in this global economy, you must localize your experience for people all around the world. Best practices and real world examples of how successful tech companies have approached localization are many, like Netflix, Facebook, and Microsoft: they have built scalable localization strategies that enabled them to reach global audiences while maintaining a high level of quality and consistency. Here you find more popular brands which have implemented their own successful strategy for localization: 1) World Wide Fun
40d For Nature (WWF) WWF is doing a lot to engage prospective audiences throughout the world. wwf By emphasizing the information that is most important to readers, the WWF is able to create a more appealing experience with more engaging content that is always new and fresh. â
It is not only translating its website; it is providing the appropriate material to the appropriate viewers. 2) Starbucks Coffee Company The company's website has been localized, making it available in the local language and in accordance with local tastes. Starbucks Coffee Company They tailor the formulas and packaging to the market, emphasizing local ingredients and creative designs. â
Starbucks, for example, was localizing its brand and adapting to Indian culture in India. It presents various goods with an Indian flavor and emphasizes tea over coffee since Indians are more associated with tea. â
In the United Kingdom, Starbucks adapted to local tastes by including scones and bacon butties on select menus. Even more examples from our clients you will find in our blog post about website localization. Next step: Scalable localization strategy Implementing a scalable localization strategy is key for companies aiming for global growth and competitiveness. By understanding target customers and tailoring actions to their needs, localization promises significant ROI and stakeholder satisfaction. Using tools like automation, translation memory, and platforms like Locize can streamline the process, ensuring quality, reducing costs, and improving team collaboration. Now we want to turn it over to you: Do you plan to build up a localization strategy? Or maybe you have a question about something you read. Either way, we are happy to help at [email protected] right now. Start now Frequently asked questions What is a localization strategy? The plan that decides which markets and languages a company serves, in what order, with which content, at what quality level and through which process, so that entering the next market is a repeatable operation. It covers product, marketing and support content, tooling and automation, review, and the metrics that show whether a market works. Why do tech companies need a localization strategy? Because localization done as an afterthought produces the problems that slow growth: releases blocked by translation handoffs, inconsistent terminology, costly recalls of marketing material, and no way to tell whether a market is working. A strategy decided once turns each into a process decision. What should a localization strategy include? Market and language priorities, the content in scope, the quality bar per content type, the translation process (human, machine, AI, and where review is mandatory), terminology and style rules, the tooling connecting development and translation, ownership and roles, budget, and metrics. How do you measure whether a localization strategy works? Per market: time from a string being written to it being live in every language, coverage and review backlog, quality signals such as automated check findings and user reported errors, and the business outcomes the market was entered for, compared with the default language. How do AI translation and the EU AI Act change localization strategy in 2026? AI makes the first draft nearly free, so the decisions move to terminology governance, review policy and provenance. Since August 2, 2026, Article 50 of the EU AI Act applies: faithful AI translations are exempt from machine readable marking, and public interest text needs a visible disclosure unless it went through documented human review under a person holding editorial responsibility. A 2026 strategy names that review step. This is not legal advice."},{"slug":"i18next-in-react","title":"i18next for React: Exploring the Right Module for Your Project","description":"Explore the diverse world of i18next in React.js as we guide you through tailored approaches for standard React projects, Next.js, Remix, and Gatsby, empowering you to craft a truly globalized user experience.","date":"2024-02-07","category":"Guides","thumbnail":"\/img\/blog\/i18next-in-react\/react-i18next-approaches.jpg","readTime":"4 min read","searchText":"title: 'i18next for React: Exploring the Right Module for Your Project', description: 'Explore the diverse world of i18next in React.js as we guide you through tailored approaches for standard React projects, Next.js, Remix, and Gatsby, empowering you to craft a truly globalized user experience.', date: '2024 02 07', thumbnail: '\/img\/blog\/i18next in react\/react i18next approaches.jpg', image: '\/img\/blog\/i18next in react\/react i18next approaches.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'react'] In the dynamic realm of React.js based projects, the implementation of i18next for internationalization isn't a one size fits all endeavor. The versatile nature of React.js projects, coupled with diverse tech stacks and project types, gives rise to a spectrum of approaches for integrating i18next seamlessly. Understanding the nuances of these approaches is pivotal in crafting a tailored and efficie
40nt internationalization strategy for your specific project. As we delve into the expansive world of i18next in React.js, this guide aims to unravel the intricacies of different implementation methods. Whether you're working on a standard React project, leveraging the power of Next.js, embracing the App Router paradigm, exploring Remix, or navigating the intricacies of Gatsby, we'll walk through each approach step by step. From plain React.js applications to the more complex structures of Next.js, Remix, and Gatsby, we'll explore how i18next can be harnessed to its full potential. Join us on this journey as we navigate the landscape of React.js and i18next integration, discovering the ideal approach that aligns with your chosen tech stack and project requirements. Through comprehensive examples and insights, this guide aims to empower you to make informed decisions and implement i18n seamlessly in your React based projects. Let's embark on this exploration of internationalization possibilities, where the choice of approach becomes a key factor in delivering a truly global user experience. TOC Usual React.js (client side) Next.js Pages Router App Router Remix Gatsby Usual React.js (client side) stands as a powerful internationalization framework tailored for React and React Native applications. Leveraging the robust capabilities of , this library simplifies the implementation of (not only) client side internationalization, offering a streamlined approach for managing translations and delivering a seamless multilingual user experience. Learn more Check out this guide to learn more about . Example apps: react i18next example app and the TypeScript version react i18next example app ts. React Native examples: ReactNativeProject and ReactNativeLocizeProject. Next.js In the realm of Next.js, a framework for React, the integration of introduces additional considerations, as the approach to internationalization varies based on the chosen strategy within the Next.js ecosystem. Whether opting for the traditional Pages Router approach, embracing the App Router paradigm, or incorporating Server Side Generation (SSG), adapts to the intricacies of each, providing a flexible and efficient solution. Pages Router When opting for the Pages Router approach, the integration of often involves the use of , a companion library that streamlines the internationalization setup. This approach aligns seamlessly with the standard React page structure in Next.js, where each page is a React component. Learn more Check out this guide to learn more about . Examples: the upstream simple example and next i18next locize. SSG: see our Next.js i18n static guide and examples (next i18next SSG example, next language detector basic example). App Router For projects adopting the App Router paradigm in Next.js, the integration of offers a seamless solution for internationalization. In this approach, the App Router structure provides a centralized and efficient routing system, and adapts well to this architecture, so is typically not necessary anymore. Learn more Check out this guide to learn more about i18next for the App Router approach. Examples: next app dir i18next example and the TypeScript version next app dir i18next example ts. Remix For Remix projects, the integration of enhances the development process by simplifying the setup for internationalization. This specialized library aligns seamlessly with Remix's architecture, offering a straightforward solution for managing translations and creating dynamic, multilingual user experiences. Learn more Check out the Remix i18n guide (part 1) and Remix i18next guide (part 2). Examples: locize remix i18next example (local branch) and locize remix i18next example. Gatsby The integration of into Gatsby projects provides a powerful mechanism for building multilingual websites. By seamlessly integrating with Gatsby's capabilities and simplifying the setup, this plugin empowers developers to create dynamic and performant user experiences for audiences around the world. Learn more Check out this guide to learn more. Example: locize gatsby example. Conclusion As we wrap up this journey through the diverse landscape of i18next in React.js projects, it's clear that internationalization is not a one size fits all endeavor. The versatility of i18next, combined with the unique characteristics of React, Next.js, Remix, and Gatsby, allows developers to tailor their approach based on project requirements. Whether you've opted for the familiar territory of a standard React project, navigated the dynamic routes of Next.js, embraced the simplicity of Remix, or ventured into the world of Gatsby, your understanding of i18next's integration has undoubtedly expanded. By leveraging the power of , , , and , you've gained the tools to create truly globalized applications. The seamless integration of i18next across these frameworks empowers developers to transcend language barr
40iers and provide a consistent, multilingual user experience. As you embark on your future React projects, armed with the knowledge acquired here, consider the unique needs of your application and audience. Each approach comes with its own strengths, and by choosing the right module for your project, you pave the way for a more inclusive and accessible digital landscape. Thank you for joining us on this exploration of i18next in React. May your internationalization endeavors be smooth, your translations seamless, and your applications truly global. Happy coding!"},{"slug":"is-sdl-trados-still-relevant","title":"Is SDL Trados Still Relevant in Todayâs Localization Landscape?","description":"In this article we'll investigate if SDL Trados is still relevant in todayâs localization landscape.","date":"2023-11-01","category":"Guides","thumbnail":"\/img\/blog\/is-sdl-trados-still-relevant\/title.jpg","readTime":"4 min read","searchText":"title: 'Is SDL Trados Still Relevant in Todayâs Localization Landscape?', description: \"In this article we'll investigate if SDL Trados is still relevant in todayâs localization landscape.\", date: '2023 11 01', thumbnail: '\/img\/blog\/is sdl trados still relevant\/title.jpg', image: '\/img\/blog\/is sdl trados still relevant\/title.jpg', category: 'Guides', tags: ['localization', 'guides', 'trados'] In the field of translation and localization, there is one tool that has been dominant for decades: SDL Trados. This software has been a staple for translators and language service providers (LSPs) alike, offering a suite of features that streamline translation workflows and improve overall productivity. However, as the translation industry evolves and new technologies emerge, some are questioning whether SDL Trados is still relevant in today's localization landscape. In this article, we'll explore this question and take a closer look at SDL Trados, its advantages and disadvantages, and why some are turning to more modern translation management systems. What is SDL Trados? SDL Trados is a translation memory software developed by SDL, a company that specializes in language technology and services. The software is widely used by translators and LSPs to manage translation workflows and improve translation quality. SDL Trados offers a range of features, including translation memory, terminology management, and automated workflows, all designed to improve efficiency and productivity in the translation process. Advantages of SDL Trados Translation memory One of the key advantages of SDL Trados is its translation memory (TM) functionality. Translation memory is a database that stores previously translated content, allowing translators to reuse translations for repeated phrases and sentences. This can greatly reduce translation time and costs while improving consistency across translations. Terminology management Another advantage of SDL Trados is its terminology management feature. This allows users to create and manage glossaries of key terms specific to their industry or project, ensuring consistency and accuracy across translations. Automated workflows SDL Trados also offers automated workflows, which can save significant time and effort in the translation process. For example, the software can automatically detect file formats, segment content, and suggest translations based on the translation memory and terminology database. This can speed up the translation process and reduce the risk of errors. Disadvantages of SDL Trados Expensive licensing fees One of the main disadvantages of SDL Trados is its licensing fees. The software can be very expensive, especially for freelancers or small businesses. The licensing structure can also be c
40omplex, making it difficult for users to choose the right package for their needs. Complex interface SDL Trados can also be complex to use, especially for new users. The interface can be overwhelming, and it may take some time to learn how to use all of the features effectively. Not cloud based Finally, SDL Trados is not cloud based, meaning that users must install the software on their local machines. This can limit collaboration and accessibility, especially for teams working remotely. Alternatives to SDL Trados As the translation industry evolves, new technologies are emerging that offer alternatives to SDL Trados. One of the most popular alternatives is cloud based translation management systems, which offer greater collaboration and accessibility. One such system is Locize, which offers a range of features similar to SDL Trados but is entirely cloud based. Cloud based solutions Cloud based translation management systems, such as Locize, offer several advantages over traditional software like SDL Trados. For one, they can be accessed from anywhere, making them ideal for remote teams or teams working across different locations. They also offer greater collaboration features, such as real time translation memory updates and more streamlined communication among team members. Another special advantage of Locize is the way it can be directly integrated to your software or website, this way translators can modify translations without the need to ask the developers to adapt their code or to redeploy their software or website. In addition, cloud based systems often have lower upfront costs and are more scalable, allowing companies to pay only for what they need as they grow. Conclusion While SDL Trados has been a dominant force in the translation industry for many years, it may no longer be the best fit for all companies. As the industry evolves, it is important to consider newer, cloud based alternatives like Locize that offer greater collaboration, accessibility, and scalability. Features like cloud based translation memory and real time CDN delivery set modern platforms apart. See how Locize compares to traditional tools â Ultimately, the best translation management system will depend on the specific needs of your company, so it is important to carefully evaluate the options before making a decision."},{"slug":"websiteplanet-interview","title":"Interview with WebsitePlanet","description":"Explore how Locize is revolutionizing software localization and breaking language barriers in our in-depth interview with WebsitePlanet.","date":"2023-10-24","category":"Company","thumbnail":"\/img\/blog\/websiteplanet-interview\/title.jpg","readTime":"1 min read","searchText":"title: 'Interview with WebsitePlanet', description: 'Explore how Locize is revolutionizing software localization and breaking language barriers in our in depth interview with WebsitePlanet.', date: '2023 10 24', thumbnail: '\/img\/blog\/websiteplanet interview\/title.jpg', image: '\/img\/blog\/websiteplanet interview\/title.jpg', category: 'Company', tags: ['localization', 'company'] We're thrilled to share our recent interview with WebsitePlanet, where we delve into the fascinating story behind Locize, explore the diverse range of services we offer, unveil our mission to simplify global expansion, and understand what sets Locize apart from the rest. Join us as we take you on a journey through our history, showcase our comprehensive localization services, and illustrate why Locize is y
40our ultimate platform for achieving global reach. Read the full interview and gain insights into the future of localization here: Innovating Software Localization: A Conversation with the CTO of Locize. [](https:\/\/www.websiteplanet.com\/blog\/interview locize\/)"},{"slug":"future-of-translation","title":"A Look into the Future of Translation and Localization","description":"This article explores the latest technology and trend that are shaping the industry of translation and localization.","date":"2023-09-06","category":"Guides","thumbnail":"\/img\/blog\/future-of-translation\/title.jpg","readTime":"2 min read","searchText":"title: 'A Look into the Future of Translation and Localization', description: 'This article explores the latest technology and trend that are shaping the industry of translation and localization.', date: '2023 09 06', thumbnail: '\/img\/blog\/future of translation\/title.jpg', image: '\/img\/blog\/future of translation\/title.jpg', category: 'Guides', tags: ['localization', 'guides'] As technology continues to advance, the field of translation and localization is also seeing significant changes. In the coming years, we can expect to see a number of developments that will improve the accuracy and efficiency of language translation, making it easier for people and businesses to communicate across borders. One of the most exciting developments in the field of translation is the use of neural machine translation (NMT), like Google Translate. NMT is a form of artificial intelligence (AI) that is able to learn the intricacies of a particular language and apply that knowledge to translations. This has led to a significant improvement in the quality of translations, particularly for less common languages. Another area where we can expect to see advancements is in the use of natural language processing (NLP) to aid in localization. NLP is a field of AI that deals with the interaction between computers and human language. By using NLP techniques, like ChatGPT, software can be made to understand and respond to language in a more human like way. This will make localization more accurate and efficient, as software will be able to understand the nuances and idioms of different languages and cultures. With the increasing use of virtual and augmented reality technology, we can expect to see more demand for the translation of multimedia content. The ability to translate and localize video, audio and other multimedia content will become increasingly important as this technology becomes more prevalent. This also present new challenges and possibilities for localization, as translation engine will need to deal with idiomatic language, context, and tone. We can also expect to see an increase in the use of crowdsourcing for translation and localization. By leveraging the power of the crowd, companies will be able to quickly and cost effectively translate and localize their content into multiple languages. This has already been used in some companies, but will become more mainstream in the future as the approach improves and becomes more accessible. In conclusion, the field of translation and localization is constantly evolving, and we can expect to see a number of exciting advancements in the coming years. The use of neural machine translation, natural language processing, and multimedia localization will improve the accuracy and efficiency of language translation. Additionally, the use of crowdsourcing will make it more cost effective for businesses to communicate across borders. These developments will have far reaching implications for industries such as e commerce, education, entertainment, and many more, breaking down language barriers and making the world a more connected place."},{"slug":"supertext-partnership","title":"Uniting Swiss Excellence: Locize and Supertext Join Forces for Seamless Software Localization","description":"Swiss localization pioneers Locize and Supertext partner to integrate Supertext's expert translation services into the Locize platform.","date":"2023-08-25","category":"Company","thumbnail":"\/img\/blog\/supertext-partnership\/title.jpg","readTime":"4 min read","searchText":"title: 'Uniting Swiss Excellence: Locize and Supertext Join Forces for Seamless Software Localization', description: \"Swiss localization pioneers Locize and Supertext partner to integrate Supertext's expert translation services into the Locize platform.\", date: '2023 08 25', thumbnail: '\/img\/blog\/supertext partnership\/title.jpg', image: '\/img\/blog\/supertext partnership\/title.jpg', category: 'Company', tags: ['localization', 'company'] In a landmark collaboration that epitomizes Swiss innovation, Locize and Supertext have come together to revolutionize the realm of software localization. Both being Swiss made, the partnership results in a harmonious blend of precision, efficiency, and quality that promises to reshape the way companies expand their global reach while maintaining a consistent brand voice. The Powerhouses: Locize and Supertext Locize, a trailblazer in software localization, has earned its reputation as a go to platform for developers and companies looking to enter new international markets. With a focus on simplifying the complexities of translation and localization, Locize empowers teams to seamlessly adapt their software interfaces and digital content across languages and cultures. Having created the foundation with i18next (one of the leading open source internationalization frameworks) it is the perfect translation management fit with a focus on continuous localization. Supertext, on the other hand, has carved out its own niche as a leader in translation, copywriting, and proofreading services. With a carefully curated team of over 3,000 professional translators and copywriters, Supertext has remained steadfast in its mission to free the world from bad copy and ensure that brands' identities remain intact as they venture into new linguistic territories. A Natural Synergy: Why Locize and Supertext Are a Perfect Match The union between Locize and Supertext is akin to combining the precision of Swiss watchmaking with the artistry of Swiss chocolatiers. This synergy promises a holistic approach to
40software localization that preserves the essence of a brand while adapting it to resonate with diverse audiences. At its core, the integration empowers users to seamlessly order Supertext translations directly from within the Locize platform. Here's how the magic works: 1. Create a Supertext account and API token Getting started is easy. If you haven't already done so, start by creating a Supertext account, where you'll gain access to a world class team of linguists ready to transform your content. Create a new API token that acts as the bridge between Locize and Supertext. 1) First, sign in to your Supertext account with your email address and password. 2) Then click on \"Settings\" in your profile menu: 3) Scroll all the way down until you see the âAPI authentication tokensâ section. There, click on \"New API token\", then enter an appropriate label and click on the check mark: 4) Copy the generated API token (we will use it later in Locize) 2. Configuring Supertext in Locize This step ensures a secure and seamless connection between the platforms. 1) Navigate to your Locize project settings page: 2) Then select the \"ordering\" tab, where the Supertext configuration awaits: 3) Click on \"configure\": 4) Enter the email associated with your Supertext account and the API token you generated earlier: Optionally, set your default order type (translation or proofreading) and your industry. 3. Effortless Order Placement With the groundwork laid, the process of ordering Supertext translations becomes an effortless endeavor. 1) Navigate to the \"orders\" page: 2) Click on \"new order\": 3) Make your appropriate selections and click \"get a quote\": 4) Select the desired order type, delivery type and optional comment, then click \"confirm & order\": The Locize order will now appear on your \"orders\" page: And the ordered segments are marked as ordered: 5) Follow the progress on Supertext, each language generates a Supertext order: 6) When the translations are finished, they are automatically merged back into Locize: In the CAT (Translation Editor) view, in the history tab, you can see when the translations were merged back. 7) On Supertext, you can give feedback, etc.: A Shared Vision: Embracing the Future As this groundbreaking partnership unfolds, it's clear that both Locize and Supertext share a common vision to empower companies to overcome language barriers while preserving the essence of their communication. This collaboration not only simplifies the localization journey, but also demonstrates the potential that exists when two Swiss made companies with a commitment to excellence combine their strengths. At the heart of this alliance, the employees and customers of both Locize and Supertext have reason to celebrate. The journey ahead promises smoother workflows, greater efficiency, and an unwavering commitment to delivering unparalleled localization solutions. In conclusion, as Locize and Supertext embark on this exciting journey together, they invite the world to witness the birth of a new era in software localization. The combination of precision, innovation, and unwavering dedication is set to redefine how brands transcend borders, and with every successful localization, a piece of Switzerland's legacy travels the globe, connecting cultures and reshaping the future of communication."},{"slug":"how-to-choose-the-right-translation-management-system-with-i18next","title":"How to Choose the Best fitting Translation Management Solution","description":"This blog post explores the unique capabilities of Locize, a comprehensive translation management tool closely integrated with i18next, making it the perfect choice to streamline localization workflows and meet the specific needs of i18next-powered projects.","date":"2023-08-02","category":"Guides","thumbnail":"\/img\/blog\/how-to-choose-the-right-translation-management-system-with-i18next\/title.jpg","readTime":"14 min read","searchText":"hideCta: true, title: 'How to Choose the Best fitting Translation Management Solution', description: 'This blog post explores the unique capabilities of Locize, a comprehensive translation management tool closely integrated
40with i18next, making it the perfect choice to streamline localization workflows and meet the specific needs of i18next powered projects.', date: '2023 08 02', thumbnail: '\/img\/blog\/how to choose the right translation management system with i18next\/title.jpg', image: '\/img\/blog\/how to choose the right translation management system with i18next\/title.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'tms', 'how to'] Multilingual support has become a necessity for web and application development. Enter i18next, a powerful internationalization framework that has redefined language translations for developers since its inception in 2011. As we venture into the realm of i18next and its ideal companion, we explore a seamless integration that empowers projects to flourish on the global stage. TOC I. Introduction A. The Significance of i18next as an Extensible Internationalization Framework B. Introducing a Comprehensive Translation Management Tool C. The Purpose of this Blog Post II. Understanding i18next and the Need for an Effective TMS A. The Background and History of i18next B. The Maturity and Extensibility of i18next C. The Richness of i18next's Features III. Key Considerations for Choosing a TMS with i18next A. Compatibility and Integration B. Translation Workflow and Collaboration Features C. Support for Localization File Formats D. Customization and Flexibility IV. Practical Tips for Evaluating and Selecting a TMS with i18next A. Research and Evaluation B. Trial and Testing C. Collaboration and Feedback D. Support and Documentation E. Pricing and Scalability F. Integration with Developer Tools V. Introducing Locize: A Unique Translation Management Solution A. The Close Alignment with i18next Principles B. Unique Features Setting Locize Apart C. Locize: The Perfect TMS for i18next Powered Projects VI. Conclusion: Why Locize is the Perfect TMS to Choose I. Introduction A. The Significance of i18next as an Extensible Internationalization Framework In the ever expanding landscape of web and application development, catering to a global audience is no longer a choice but a necessity. Websites and software products must accommodate users from diverse linguistic backgrounds, making internationalization a crucial aspect of modern development practices. At the forefront of this domain stands i18next, a well established and highly extensible internationalization framework. Since its inception in late 2011, i18next has grown into one of the most favored open source solutions for enabling multilingual support in web and mobile applications. Its widespread adoption can be attributed to its maturity, versatility, and continuous evolution to meet the changing needs of the localization community. From handling simple key value translations to supporting complex pluralization and language detection, i18next has proven itself as a reliable and powerful tool. B. Introducing a Comprehensive Translation Management Tool As i18next's popularity surged, developers encountered a new challenge managing translations effectively across projects and keeping up with a growing user base. The demand for a seamless translation management solution became evident, leading to the birth of a new service, a comprehensive translation management system (TMS) and the official sponsor of i18next. What sets it apart from other TMS offerings is its deep integration with i18next, designed to cater to the specific needs of i18next powered projects. Instead of being just another localization as a service offering, it goes above and beyond to provide a robust ecosystem for internationalization. The creators of i18next, being the founders of a TMS, brought their expertise and experience to ensure that it seamlessly complements the i18next framework. C. The Purpose of this Blog Post In this blog post, we embark on a journey to explore the capabilities of a TMS and its integration with i18next, with a focus on how the system designed by the i18next founders stands out in particular as the perfect TMS for managing translations in i18next projects. We will delve into the unique features that set it apart from alternatives, understanding its role as an essential component in the localization workflow. Throughout this article, we will provide insights and practical tips for developers and localization teams looking to select the right TMS with seamless i18next integration. By the end, readers will have a clear understanding of several advantages, empowering them to make informed decisions when choosing a translation management solution that optimizes their i18next powered localization workflow. Join us as we unravel the strengths of i18next and the capabilities of a good translation management solution, offering a powerful combination for efficient and effective software localization in the globalized digital landscape. II. Understanding i18next and the Need for an Effective TMS A. The Backgroun
40d and History of i18next To comprehend the importance of an effective system for translation management, it's essential to grasp the foundation on which it is built i18next. Born in 2011, i18next emerged as a solution to a critical challenge faced by developers finding an internationalization library that could seamlessly run on both server side and client side single page applications. From its humble beginnings, i18next quickly gained momentum, becoming one of the most widely used frameworks for translating web and mobile applications. Its success was fueled by an extraordinary response from the community, which led to the establishment of a fast growing ecosystem around i18next. [](https:\/\/npmtrends.com\/i18next) V2 of i18next, released in 2015, marked a significant milestone. With this release, i18next was completely rebuilt to be highly extensible, ensuring smooth compatibility with previous versions. As a result, developers could effortlessly adopt newer releases without disrupting existing codebases. The robustness of the i18next API, which is still actively tested and supported, solidified its reputation as a dependable choice for internationalization. And nowadays, i18next also offers type safety for your translations. Whenever a developer employs a non existent or modified i18n key, the TypeScript compiler immediately raises an error, promptly alerting you to the issue before it gives rise to runtime complications. B. The Maturity and Extensibility of i18next Having withstood the test of time, i18next has garnered a reputation for being a mature and reliable framework. Its longevity in the open source community is a testament to its adaptability, with no i18n case deemed unsolvable by i18next. From small projects to enterprise grade applications, developers have found i18next to be an indispensable tool for multilingual support. The extensibility of i18next is another compelling aspect. This framework can be integrated into any JavaScript environment, making it compatible with various UI frameworks, i18n formats, and even non JavaScript platforms such as .NET, Elm, iOS, Android, Ruby, and more. The versatility and flexibility of i18next allow developers to tailor the internationalization process to fit specific project requirements and workflows, catering to the diverse needs of different teams and applications. C. The Richness of i18next's Features Beyond its core capabilities, i18next stands out for its rich feature set, which surpasses many traditional i18n frameworks. From basic interpolation and formatting to advanced functionalities such as translations from multiple sources, language detection, plural form resolutions, and caching, i18next provides a comprehensive suite of tools for developers to handle multilingual complexities effortlessly. The heart of i18next's success lies not just in its technical proficiency but also in the vibrant community that surrounds it. Users actively contribute feedback and improvements, enriching the ecosystem with valuable insights. As a result, i18next continues to evolve and adapt, remaining at the forefront of internationalization and setting the stage for a seamless integration with a translation management solution. With a solid understanding of i18next's significance and features, we can now delve deeper into the area of translation management solutions and which TMS is the perfect one to complement the power of i18next. III. Key Considerations for Choosing a TMS with i18next When it comes to selecting a translation management system (TMS) that seamlessly integrates with i18next, several key considerations are crucial to ensure a smooth and efficient localization workflow. Let's explore these essential factors to help you make an informed decision: A. Compatibility and Integration The first and foremost consideration is ensuring compatibility and seamless integration with i18next. A TMS, built with a focus on i18next, should effortlessly fit into your existing i18next powered projects without major disruptions. Look for features that allow you to link your i18next translations directly to the TMS, ensuring consistent synchronization between your codebase and localization files. B. Translation Workflow and Collaboration Features An effective TMS should simplify your translation workflow and facilitate seamless collaboration between developers, translators, and localization managers. Features like versioning, translation tagging, collaboration, and change tracking are vital to maintain a smooth and efficie
40nt localization process. With strong versioning support and integration with third party translation services, you gain the tools to streamline the translation workflow and optimize collaboration. C. Support for Localization File Formats Ensure that the TMS supports the localization file formats used by i18next. As i18next is compatible with various file formats, such as JSON, YAML, PO, and more, the TMS should seamlessly handle these formats to import and export translations effortlessly. A good TMS is designed with this compatibility in mind, ensuring that i18next developers can continue working with their preferred file formats. D. Customization and Flexibility Every project has unique requirements and workflows. A flexible TMS should offer customizable settings to adapt to your specific needs. This includes the ability to configure language settings, custom translation workflows, and permissions for team members. By providing customization options, a TMS empowers you to tailor the localization process to suit your project's exact requirements. By carefully considering these key factors, you can confidently select a TMS that aligns with i18next principles and enhances your localization workflow. Now, let's move on to the practical tips for evaluating and selecting the ideal TMS with seamless i18next integration. IV. Practical Tips for Evaluating and Selecting a TMS with i18next Now that we have explored the key considerations for choosing a TMS that seamlessly integrates with i18next, let's dive into practical tips to help you evaluate and select the ideal TMS for your localization needs: A. Research and Evaluation Start by conducting thorough research on various TMS options available in the market. Look for TMS solutions that specifically highlight their compatibility with i18next and offer features tailored to support its unique requirements. Read user reviews and testimonials to gain insights into the experiences of other developers and localization teams. B. Trial and Testing Many TMS providers offer free trials or demo versions. Take advantage of these opportunities to test the TMS with your existing i18next projects. This hands on experience will allow you to assess how well the TMS integrates with i18next and how user friendly it is for your team. C. Collaboration and Feedback Engage in conversations with your development team and localization managers. Gather their feedback and consider their input when evaluating TMS options. Understanding their specific pain points and requirements will help you make an informed decision that aligns with your team's preferences and workflow. D. Support and Documentation Reliable customer support is crucial when dealing with complex internationalization and localization tasks. Look for TMS providers that offer responsive customer support and comprehensive documentation not only for the TMS itself, but also for i18next. Having readily available resources and assistance will ensure that your team can resolve any issues quickly and efficiently. E. Pricing and Scalability Carefully evaluate the pricing models offered by different TMS providers. Consider the scalability of the TMS and how it aligns with your project's growth potential. Look for transparent pricing structures that suit your project's needs without hidden costs. Ask yourself: \"Do I pay too much just by scratching the border of the next bigger plan? Or does the costs scale with the project growth?\" F. Integration with Developer Tools Efficiency is vital in any development process. Check if the TMS integrates smoothly with other tools and platforms that your development team already uses. Seamless integration with code repositories, build systems, and deployment platforms will enhance your team's productivity. By following these practical tips, you can confidently assess and select a TMS, that ensures smooth integration with i18next and streamlines your localization workflow. V. Introducing Locize: A Unique Translation Management Solution A. The Close Alignment with i18next Principles As the official sponsor of i18next, Locize is more than just another translation management solution; it is a TMS designed to harmonize with the core principles and philosophy of i18next. Developed by the same creators as i18next, Locize benefits from a deep understanding of the needs and challenges faced by developers and localization teams. This close alignment ensures that Locize seamlessly integrates with i18next, offering a unified and optimized experience for managing translations. By leveraging i18next's extensible architecture, Locize empowers users to leverage the full potential of the framework while providing additional tools and features that go beyond traditional translation management. [](\/i18next how does i18next work) B. Unique Features Setting Locize Apart 1. Strong Support for Versioning and Software Development Process One of Locize's standout features is its robust support for versioning, a critical aspect of software development. Proper versioning ensures that changes to translations are managed efficie
40ntly, facilitating collaboration among developers and localization teams. With Locize, users can confidently make updates and track progress without the fear of losing previous translations or creating confusion. 2. Freedom from Service Lock In Unlike some other translation management services, Locize believes in giving users the freedom to choose. While Locize offers exceptional value as a TMS, it does not lock users into its platform. Instead, users can export their translations and use them with i18next or other preferred localization frameworks. This approach empowers users with full control over their translation data and enhances the flexibility of their localization workflow. 3. Exceptional Support from i18next Creators The backing of the i18next creators ensures that Locize users receive unparalleled support and expertise in internationalization and localization. The team behind Locize is intimately familiar with the intricacies of i18next, providing developers with valuable guidance and assistance in optimizing their localization workflow. 4. Support for Multiple Namespace\/Files and Proper Pluralization Locize goes beyond standard translation management offerings by providing support for multiple namespaces or files within a project. This allows developers to organize translations efficiently, ensuring clarity and simplicity in the localization process. Additionally, Locize understands the complexities of pluralization rules in different languages. By correctly calculating progress in various languages based on distinct pluralization rules, Locize ensures that translations are accurate and contextually appropriate, regardless of the language being translated. 5. Integration with Third Party Translation Services To cater to diverse user needs, Locize offers integration with third party translation services. This feature allows users to leverage additional capabilities provided by these services, such as project finalization, the option to work with preferred translators, approvals, and direct contact with translators. The integration with third party services streamlines the translation process and allows users to collaborate effectively with translation professionals. 6. Freedom to choose how to serve your translations While you get most comfort out of using the Locize CDN, your environment might demand you to bundle the translations with your product (eg. offline usage in areas with restricted internet access or with offline fallback). Using the CDN has three big advantages: You can deploy updates to translations without the need to redeploy\/rollout a new version of your application. During development, testing you can set your versions to auto publishing. Doing so your translation changes are reflected immediately in your application and results in a lot easier development process. You can easily set a version to publish in private mode, which means you will need an API key to download your translations. This enables you for example to use Locize as before but without leaking any information to the public. If your product demands to download the translations, because you need or prefer to host or bundle them yourself you can do so. Using our CDN is completely optional and get only billed if youâre using it. You can download\/export the translations using the API or the Locize UI or the CLI, also in various formats. C. Locize: The Perfect TMS for i18next Powered Projects With its deep integration with i18next, Locize emerges as the perfect translation management system for developers and localization teams working with i18next powered projects. Its unique features, built on a foundation of understanding and commitment to i18next principles, make it a standout choice in the realm of translation management. In the next section, we will explore key considerations for selecting a TMS with a focus on seamless i18next integration, ensuring that your localization workflow remains efficient, accurate, and hassle free. VI. Conclusion: Why Locize is the Perfect TMS to Choose Throughout this journey, we have delved into the significance of i18next as a mature and extensible internationalization framework, and the emergence of Locize as a unique translation management solution tailored to complement i18next. Now, let's reinforce why Locize stands as the perfect TMS for i18next powered projects: 1. Deep Integration with i18next Principles: As the official sponsor of i18next, Locize's creators have ensured seamless integration with the framework, offering a unified and optimized experience for managing translations. 2. Unique Features and Differentiators: Locize goes beyond traditional TMS offerings with features like strong versioning, freedom from service lock in, support for multiple namespaces\/files, and proper pluralization. These unique capabilities set Locize apart and enhance the i18next localization workflow. 3. Exceptional Support from i18next Creators: The team behind Locize shares the expertise of i18next's creators, providing unrivaled support and guidance in internationalization and localization tasks. 4. Compatibility and Flexibility: Locize is designed to be compatible with i18next and allows for customization to adapt to unique project requirements and workflows. 5. Seamless Collaboration: With its collaboration friendly features, Locize streamlines communication between developers and localization teams, enhancing the efficiency of the translation process. 6. Integration with Third Party Translation Services: Locize's integration with third party translation services expands its capabilities, providing access to additional features and supporting various translation workflows. 7. Efficient Translation Workflow: Locize's focu
40s on versioning, collaboration, and change tracking ensures a smooth and efficient translation workflow for i18next powered projects. Choosing the right TMS is paramount to the success of your localization efforts, and Locize emerges as the perfect choice to meet the specific needs of i18next projects. Its compatibility, unique features, and exceptional support make it an invaluable tool in the globalized digital landscape. As you embark on your internationalization journey with i18next, let Locize be your steadfast companion in managing translations efficiently and effectively. Embrace the power of this dynamic duo, and watch your projects flourish on the global stage. Try Locize today and see the difference it can make for your business."},{"slug":"i18next-typescript","title":"Supercharge Your TypeScript App: Mastering i18next for Type-Safe Translations","description":"Discover how to unleash the full potential of i18next in your TypeScript applications by mastering type-safe translations, ensuring accurate localization and eliminating runtime errors, with this guide. â
","date":"2023-06-22","category":"Guides","thumbnail":"\/img\/blog\/i18next-typescript\/title.jpg","readTime":"5 min read","searchText":"title: 'Supercharge Your TypeScript App: Mastering i18next for Type Safe Translations', description: \"Discover how to unleash the full potential of i18next in your TypeScript applications by mastering type safe translations, ensuring accurate localization and eliminating runtime errors, with this guide. â
\", date: '2023 06 22', thumbnail: '\/img\/blog\/i18next typescript\/title.jpg', image: '\/img\/blog\/i18next typescript\/title.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'typescript'] As our world becomes increasingly interconnected, the development of web applications that cater to a global audience takes precedence among developers. If you're a TypeScript developer, you're likely acquainted with the advantages of static typing and the assurance it provides in your codebase. When it comes to internationalization (i18n) and localization (l10n), maintaining the same level of type safety becomes crucial. This is precisely where i18next, an influential i18n framework, enters the picture. In the past, i18next already furnished TypeScript definitions for its API, enabling developers to benefit from type checking while utilizing the library. However, a significant limitation persisted, specifically the absence of type safety for translation keys. Consequently, if a translation resource was missing or underwent a name change, the TypeScript compiler failed to detect it, resulting in potential errors during runtime. Nevertheless, with the advent of the new iterations of i18next, that limitation has been overcome (thanks largely to Pedro Durek) . Now, i18n keys boast complete type safety. Whenever a developer employs a non existent or modified i18n key, the TypeScript compiler immediately raises an error, promptly alerting you to the issue before it gives rise to runtime complications. In addition, there is also an improved intellisense experience. Within this guide, we will delve into the art of leveraging the latest version of i18next to attain translations that are impervious to type related errors in your TypeScript applications. We will encompass everything from the fundamentals of i18next setup to advanced techniques. All the while, you will benefit from the added safety net of type checking for your translation keys. By the conclusion of this guide, you will possess a profound comprehension of how to harness the force of i18next's type safe translations within your TypeScript projects. You will be equipped to ensure that your translations are not only precise and adaptable but also consistently error free, courtesy of the seamless integration between i18next and TypeScript. Let us embark on this journey together and furnish you with the knowledge and tools necessary to create localized applications that effortlessly cater to diverse language preferences while maintaining the robustness of your co
40debase. In Memory translations For a simple i18next setup, you probably have something like this: You import the translation resources and you're adding them via i18next init function. To make the translation type safe, we create an file preferably in a folder and we import the translation resources of our reference language: That's already great! But: We Can Do Better. With the help of i18next resources for ts we can generate a single resource file that we can use. So install and execute the command, i.e. something like: So we can modify the file like this: ð§âð» A complete code example can be found here. Plurals btw: also plural keys works: Fallback Namespace And also fallback namespace handling works: Interpolation Unfortunately, automatic interpolation inference won't work if your translations are placed in JSON files, only in TS files using keyword or an interface in a file, as long as this TypeScript issue is not addressed. Interface To address this, let's make use of the command, i.e. something like: This way we can change the file like this: Now the interpolation inference works and fails if the passed variable name does not match: ð§âð» A complete code example can be found here. React.js A React.js based i18next setup with in memory translation resources could also look very similar to the above example, so let's raise the bar a little bit and see what a setup with lazy loading translations like with i18next http backend looks like: To make the translation type safe, we again create an file preferably in a folder like this: And again we make use of the command, i.e. something like: This way, the translations are loaded at runtime, but the translations are type checked during development. With the new react i18next version, when loading multiple namespaces, function will infer and accept the keys for the first namespace. So this pattern is now accepted: Trans component And also the component is type safe: ð§âð» A complete code example can be found here. No app bundled\/provided translations There is also a way to keep the translations completely separate from your code repository while maintaining type safety. Let's take the React.js project used in this awesome guide... The final i18next setup in this example looks like this: So at runtime we load the translation directly from the Locize CDN. So how do we get type safe translations during development? We create some npm scripts to help us: 1. Download the published translations (in reference language) to a temporary directory, i.e.: : 2. Create the appropriate interface definition file, i.e.: : 3. Final script: download, create interface and delete the temporary files, i.e.: : Like in the previous example, we now can just import that interface in our file: That's it! The translations are separated from our code repository and at the same time we maintain type safety with the help of an interface. ð§âð» A complete code example can be found here. There's also a video about this topic. ð𥳠Congratulations ðð In conclusion, mastering i18next for type safe translations empowers TypeScript developers to unlock the full potential of their applications. By ensuring accurate localization, eliminating runtime errors, and leveraging the seamless integration between i18next and TypeScript, developers can create robust, localized applications that cater to diverse language preferences. With the knowledge and tools provided in this guide, you are equipped to supercharge your TypeScript app and deliver exceptional user experiences on a global scale. Happy coding! So if you want to take your i18n topic to the next level, it's worth trying the localization management platform Locize. The founders of Locize are also the creators of i18next. So by using Locize you directly support the future of i18next. ð"},{"slug":"missing-translations","title":"Missing Translations in i18next: Fallbacks, Detection & Fixes","description":"When i18next can't find a translation, users see raw keys. Learn fallback languages, debug-mode detection, saveMissing, and how to keep UX clean while translators catch up.","date":"2023-06-06","category":"Guides","thumbnail":"\/img\/blog\/missing-translations\/title.jpg","readTime":"7 min read","searchText":"title: 'Missing Translations in i18next: Fallbacks, Detection & Fixes', description: \"When i18next can't find a translation, users see raw keys. Learn fallback languages, debug mode detection, saveMissing, and how to keep UX clean while translators catch up.\", date: '2023 06 06', thumbnail: '\/img\/blog\/missing translations\/title.jpg', image: '\/img\/blog\/missing translations\/title.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next', 'how to'], faq: [ q: 'What does it mean when i18next shows raw translation keys?', a: 'It means i18next could not find a translation for that key, usually because the key is not in any of the loaded translation files, the namespace failed to load, or the file path is wrong. By default i18next returns the key itself as a fallback. Fix the underlying cause (extract the key, fix the loadPath, add the namespace) or c
40onfigure a fallbackLng so users see a translated default instead of a raw key.' , q: 'How do I detect missing translations in i18next?', a: 'At build time, run i18next cli status to get a completeness report across locales and namespaces, or status hide translated to see only the gaps. At runtime, enable debug: true to log warnings to the console when a key is missing, or set saveMissing: true to capture missing keys via a missingKeyHandler (or send them to a managed backend like Locize for translators to fill in).' , q: 'How do I prevent missing translations in CI\/CD?', a: 'Wire i18next cli extract ci or i18next cli status into your CI pipeline. extract ci exits non zero if there are new keys in code that are not yet in your translation files. status exits non zero if any locale has missing entries. Either gate blocks merges that would ship missing translations to production.' , q: 'What is saveMissing in i18next?', a: 'saveMissing: true tells i18next to call a missingKeyHandler whenever it encounters a key with no translation. The handler can log the key, write it to a file, or POST it to a backend. With Locize, missing keys are automatically captured into the project so translators can fill them in, closing the loop between code and translation without manual key entry.' , q: 'What is the difference between fallbackLng and a default value?', a: \"fallbackLng tells i18next which language to fall back to when a key is missing in the user's current language, e.g. show English text when the German translation is not ready yet. A default value is passed inline in the t() call and is shown when the key is missing in the active language. Default values are more granular; fallback languages are the project wide safety net.\" , q: 'Does TypeScript catch missing i18next keys?', a: 'Yes, when you generate types with i18next cli types. The command reads your translation files and produces TypeScript definitions, so referencing a key that does not exist becomes a compile error. Combined with a strict tsconfig, CI catches misspelled keys before they ship.' , q: 'How do Locize and i18next handle missing translations together?', a: 'i18next captures missing keys at runtime via saveMissing and sends them to Locize. Locize stores them as untranslated entries, optionally pre fills them with AI translation, and notifies translators. Once translations are added, they are served via the Locize CDN to your app with no redeploy needed. Missing keys flow from code to translators and back to the app automatically.' , q: 'Should I commit translation files generated by i18next cli?', a: 'Yes, treat them like any other source artifact. Commit the JSON files produced by extract so your repo is the source of truth and CI can verify completeness with status or extract ci. If you use Locize, you can also configure locize download to pull production translations as part of your build, but committing the extracted keys keeps the team in sync about what needs translating.' ] Missing translations in i18next are translation keys that exist in your source code but have no entry in your translation files, so users see raw keys like instead of real text. The modern fix is two layered: catch them at build time with i18next cli ( + ) so they never reach production, and configure i18next at runtime (fallback languages, default values, ) so the few that slip through degrade gracefully. Key facts What is missing: a key used in code but absent from one or more translation files Symptom: users see the raw key (welcome.title) instead of translated text Build time fix: i18next cli extract adds keys automatically; status ci fails CI when locales are incomplete Runtime safeguards: fallbackLng, default values, saveMissing, custom missingKeyHandler Type safety: i18next cli types generates TS definitions so mistyped keys fail to compile TMS workflow: saveMissing + Locize captures missing keys in production for translators to fill in Why missing translations happen In a typical i18next setup, translations are stored as JSON files (one per language and namespace), each containing key\/value pairs. The function in your code looks up a key, finds the value for the active language, and renders it. A translation is \"missing\" when: The key is referenced in code but does not exist in any loaded translation file The key exists in your primary language file but not in a secondary language The namespace containing the key fails to load (404, CORS, wrong path) The key is misspelled in code or in the translation file The default i18next behavior is to return the key itself as the rendered string. Users see instead of \"Welcome\". This breaks the multilingual experience and damages trust, especially when it ships to production unnoticed. The fix is layered: prevent missing keys at build time with static analysis (so they never reach production), and configure i18next's runtime fallbacks (so anything that slips through still renders something reasonable). Catch missing translations at build time with i18next cli The most effective place to catch missing translations is before code ever runs. i18next cli is the official static analysis toolchain for the i18next ecosystem. It walks y
40our source code, identifies every call, and keeps your translation files and types in sync. For a full walkthrough of the toolchain, see Supercharge Your i18next Workflow with the All New i18next cli; here we focus on the missing translation parts. Extract every key from your code parses your source files ( , , , , and more via plugins), finds every call, and adds any missing keys to your JSON translation files automatically. Run it during development with for instant feedback as you write new components: This alone prevents the most common cause of missing translations: a developer adding a new to code but forgetting to add the key to the translation files. Gate CI on translation completeness In CI\/CD, exits with a non zero status code if extraction would change any translation file, meaning there is a new key in code that has not been added to the JSON. This blocks merges of code that would produce missing translations in production. For a full health check report: reports each locale's translation completeness, exiting non zero when any locale is incomplete. Add to see only the gaps: Both commands can run side by side in your pipeline: catches \"new keys not yet in files\", catches \"files exist but values are blank\". Catch misspelled keys with TypeScript reads your translation files and generates TypeScript definitions for every key. With strict mode enabled, calling becomes a compile error: typos are caught before code is even committed. Pair with to keep types and translations in lockstep. Sync secondary languages aligns secondary language files against your primary language: adds missing keys, removes orphans. This catches the case where the English file (primary) is still missing a key that was added directly in the German file, or where deleted code left stale keys behind. Detect and handle missing translations at runtime Even with build time gates, missing translations can still occur in production: a server side rendering edge case, a dynamic key that was not statically analyzable, a translation file that fails to load over the network. i18next provides several runtime mechanisms to detect and handle these gracefully. Enable debug mode in development Set in your i18next config to log warnings to the browser console whenever a key is missing: This is the simplest first line detection mechanism. Review the console during local development and integration testing to surface keys you have missed. Fall back to another language Use fallback languages to display the primary language when a translation is missing in the user's locale: Instead of seeing , the user sees \"Welcome\": recognizable English text rather than a raw key. Provide inline default values Pass a default value directly in the call: The default value is shown when the key is missing in the active language. This is more granular than , useful when a specific call needs a custom fallback regardless of the project wide setting. Capture missing keys at runtime with saveMissing Set and provide a to capture missing keys as they happen: When paired with a translation backend like Locize, missing keys are automatically POST'd to the project. Translators fill them in (or Automatic Translation pre fills them with AI) and the new translations are served via CDN with no redeploy. See Automating i18next Translations with and Locize AI for the full setup. This is how Locize closes the loop between code and translation: Customize the missing key behavior i18next provides additional configuration options for missing key handling: for transforming the rendered output, for diagnostics, and event handlers like for richer instrumentation. Best practices for the i18next localization workflow A handful of practices keep missing translations from compounding over time: 1. Establish a clear translation process. Define when keys are added, who translates them, and how updates are reviewed. See our guide on keeping track of new translations. 2. Maintain a glossary and style guide. Translators need consistent terminology, especially for product names and technical vocabulary. Locize integrates a glossary directly into the translation workflow. 3. Use consistent formatting and placeholders. Follow consistent formatting conventions and use placeholders effectively so translators know what is interpolated. 4. Version your translations. Use versioning and history so you can revert if a translation regresses and track changes over time. Improve user experience when translations are missing How you handle the missing case affects how users perceive the app: Communicate clearly. If a translation is not available, an informative placeholder is better than a raw key. Use or default values to render something readable. Provide context and use variables properly. Translators do better work with context, and consistent variable usage prevents bugs where a placeholder is translated as literal text. Watch text length. Translated text is often longer than the source: German is typically 30% longer than English. Test your layout with realistic translations to avoid truncation or overflow. Optimize i18next performance As your translation footprint grows, performance considerations come into play: 1. Cache translations. Caching translations locally or via CDN reduces network requests on subsequent loads. 2. Bundle or split language files. Minify and bundle for smaller payloads, or use lazy loading to defer translations until they are needed. 3. Lazy load namespaces. Load translations dynamically so the initial bundle stays small. Frequently Asked Questions frontmatter.faq.map(( q, a ) = ( q a )) Conclusion Missing translations are an inevitable part of multilingual development: keys get added, languages lag behind, files fail to load. What makes the difference is having both layers in place: build time prevention with i18next cli so missing keys never reach production, and runtime safeguards ( , default values, ) so anything that slips through still renders something reasonable. Combine that with a translation management system like Locize, which captures payloads, lets translators fill them in, and serves the result via CDN without a redeploy, and you have a workflow where missing translations get closed automatically. For codebase
40s that do not yet have i18next instrumentation in place, see From Hardcoded Strings to Global Ready: The Modern React i18n Journey: the upstream version of \"missing translations\" is \"missing calls entirely\", and can help."},{"slug":"translation-distraction","title":"Don't let translation topics distract you!","description":"In this article, we'll explore why translation topics can distract you as a developer and how you can manage this distraction.","date":"2023-05-08","category":"Guides","thumbnail":"\/img\/blog\/translation-distraction\/title.jpg","readTime":"5 min read","searchText":"title: \"Don't let translation topics distract you!\", description: \"In this article, we'll explore why translation topics can distract you as a developer and how you can manage this distraction.\", date: '2023 05 08', thumbnail: '\/img\/blog\/translation distraction\/title.jpg', image: '\/img\/blog\/translation distraction\/title.jpg', category: 'Guides', tags: ['localization', 'guides'] You may find yourself in a situation where you need to create a multilingual website or application. When that happens, you'll inevitably encounter the issue of translation. While translation is essential, it can also be distracting, especially when you're working on a project with many moving parts. As a developer, you're no stranger to the challenges of creating software that is accessible to a global audience. Internationalization, or i18n, can be a daunting task that involves creating software that can easily adapt to different languages and cultures. But while it's important to prioritize i18n in your development process, it's also important not to let translation issues distract you from your primary goal. TOC Introduction Why translation topics can distract you as a developer The impact of distraction on your productivity How to manage translation related distractions Simplify the translation process Delegate translation tasks to others Use machine translation The importance of staying focused on your core tasks Conclusion Introduction As a developer, your primary focus is on writing clean, functional code that delivers the desired features and functionality to your end users. However, when it comes to multilingual projects, you may find yourself distracted by translation issues. This is because translation requires a significant amount of attention, planning, and resources, which can pull you away from your core responsibilities. In this article, we'll explore why translation issues can be a distraction, how that distraction affects your productivity, and how to manage it effectively. Why translation topics can distract you as a developer Translation topics can be a distraction because they require a considerable amount of attention and planning. When you're working on a multilingual project, you have to consider things like language specific formatting, text expansion, the possibility of mistranslation and a lot more. Additionally, the translation process involves collaborating with different stakeholders, such as translators, editors, and proofreaders, which can consume a lot of your time and energy. This can cause you to lose focus on your primary tasks, leading to delays in your project's delivery. One of the primary reasons that especially internationalization (i18n) can be frustrating for developers is its complexity. Internationalization is a multi faceted process that involves everything from designing flexible user interfaces to handling different date and time formats. For large and complex software systems, this can be a time consuming and challenging task. This can be summarized with the question: \"Is your software ready for localization?\" Incomplete or inaccurate translations can lead to a poor user experience for non native speakers, and ongoing maintenance to keep translations up to date can be resource intensive. In addition, a lack of testing for i18n can make it difficult to identify and fix bugs that occur when the software runs in different languages or cultures. Localization Tip Read about what software localization is. The impact of distraction on your productivity Distractions can have a serious impact on your productivity. When you're not focused, you tend to make more mistakes and your work takes longer to complete. This can lead to missed deadlines and frustrated stakeholders. In addition, distractions can affect your creativity, making it harder for you to come up with innovative solutions to problems. This can limit your ability to deliver a quality product that meets the needs of your users. How to manage translation related distractions Managing translation related distractions is essential to ensuring that you stay focused on your core tasks. Here are some strategies you can use: Simplify the translation process One way to deal with translation related distractions is to simplify the translation process. You can do this by using translation tools that automate certain aspects of the process, such as translation memory and glossaries. Delegate translation tasks to others Another way to manage translation distractions is to delegate translation tasks to others. You can hire professional translators, editors, and proofreaders to handle the translation process while you focus on your core business. Or better yet, use a modern translation management system like Locize that takes the pain out of the translation process. No more delays in shipping your software due to missing translations. Translators can keep up with changes from day one. The continuous localization process keeps pace with your demanding business. A TMS like Locize bridges the gap between localization and development. This makes you faster, more efficient and saves you money overall. Use machine translation Using machine translation is another way to manage translation related distractions. While machine translation is not always accurate, it can be useful for translating simple text or getting a rough idea of the content. The on demand machine translation or automatic machine translation options are a good example of how machine translation can be used. Machine translation would be the most cost effective approach because it is virtually free. However, if no one checks the translated information, there will undoubtedly be a lack of quality. But modern TMS like Locize can help you with this. Read more about it here. The importance of staying focused on your core tasks As a developer, your primary focus should be on writing clean, functional code that delivers the desired features and functionality to your end users. It's important to remember that internationalization is an essential aspect of software development. By making your software accessible to a global audience, you can reach new markets and make your product more widely used. But it's also important to stay focused on your main goals and not let translation issues distract you from delivering a quality product. To ensure that internationalization doesn't distract you from your primary goals, it's important to prioritize it in your development process. By making i18n a fundamental part of your software design, you can create a product that is easier to adapt to different languages and cultures. This can include everything from using a localization platform like Locize to conducting thorough testing and working closely with translation teams. Conclusion Translation issues can be a significant distraction, but it's important to manage these distractions so you can focus on your core tasks. By
40simplifying the translation process, delegating tasks to others, and using smart tools, you can free up more time and energy to focus on writing clean, functional code that delivers the desired features and functionality to your end users. Remember to stay focused on your core responsibilities to ensure that you deliver a quality product that meets the needs of your users."},{"slug":"localization-context","title":"The Importance of Context in Localization: Best Practices for Accurate Translations","description":"In this article, we will explore the importance of context in localization and how some context features can help improve translation accuracy.","date":"2023-04-11","category":"Guides","thumbnail":"\/img\/blog\/localization-context\/title.jpg","readTime":"4 min read","searchText":"title: 'The Importance of Context in Localization: Best Practices for Accurate Translations', description: 'In this article, we will explore the importance of context in localization and how some context features can help improve translation accuracy.', date: '2023 04 11', thumbnail: '\/img\/blog\/localization context\/title.jpg', image: '\/img\/blog\/localization context\/title.jpg', category: 'Guides', tags: ['localization', 'guides'] As businesses expand their reach to global audiences, localization becomes crucial to ensure their message reaches the target market accurately. However, translating content accurately can be challenging, especially when context is not considered. In this article, we will explore the importance of context in localization and how some context features can help improve translation accuracy. Understanding Context in Localization Context plays a crucial role in accurately translating content. It refers to the circumstances, conditions, or background surrounding a word or phrase that contributes to its meaning. Without proper context, translators may misunderstand the intended message, leading to an inaccurate translation. Some situations where context is particularly important include idiomatic expressions, cultural references, and technical terms. Examples Inaccurate translations: Without context, translators may misinterpret the meaning of a phrase, resulting in a less accurate translation. For example, if a software application has a button with the label \"ship\" a translator without context might translate it to German as \"Schiff\" (large boat for transporting people) instead of \"versenden\" (send \/ transport) leading to confusion for the user. Cultural insensitivity: Without context, translations may be culturally insensitive or even offensive. For example, a literal translation of a phrase or idiom in one language may not make sense or be considered offensive in another language. Inconsistent terminology: Without context, translators may use inconsistent terminology, resulting in confusion for users. For example, if a software application uses different terms to refer to the same feature in different parts of the application, users may have difficulty understanding how to use it. Technical errors: Without context, translators may not have the technical knowledge necessary to accurately translate technical terms or phrases. For example, a translator may not understand the technical meaning of a term like \"cache\" and translate it as \"hidden storage\" leading to confusion for the user. Best Practices for Using Locize's Context Features Locize offers several powerful features to help improve translation accuracy: specific context information per segment, InContext view, terminology glossary, and screenshot feature. Specific context information allows users to add notes, links, and descriptions to provide additional context for each individual key\/segment. The InContext view enables users to connect content from their website directly with their content on their localization project on Locize. The glossary is a lexica that contains terminology to be used or not be used in the translations. It's here to aid translators to use the terms preferred by your organisation. Using the screenshot feature, users can assign text parts of a screenshot to a specific translation key. To use the context features effectively, users should provide as much context as possible. This can include providing background information on the product or service, identifying the intended audie
40nce, and giving clear instructions to the translation team. Users should also include screenshots or links where necessary, which can provide additional context that is not immediately apparent from the text. It is also important to involve the translation team in the context gathering process, as they may have valuable insights into the nuances of the language and culture. Real World Examples of Improved Translation Accuracy with Locize's Context Features Locize's context features have helped many businesses and organizations improve translation accuracy. For example, a healthcare company used Locize's context features to provide additional context for medical terms, resulting in more accurate translations. By providing definitions and explanations of medical terms, translators were able to better understand the intended meaning of the text. A globally leading technology firm used Locize's screenshot feature to assign text parts of a screenshot to a specific translation key, resulting in more accurate translations for their website. This allowed translators to see the text in context, which helped them understand the intended meaning. A fintech company used Locize's InContext view to connect content from their app with their localization project on Locize, resulting in more accurate translations for their service. This helped translators understand how the text would appear in the final product, which allowed them to provide more accurate translations. Bonus Tip Check out our Customer Testimonials for more examples of our clients. Conclusion Context is critical for accurate translations, and Locize's context features offer powerful tools to improve translation accuracy. By using specific context information, InContext view, terminology glossary, and screenshot feature, businesses and organizations can provide translators with the context they need to produce more accurate translations. To get the most out of Locize's context features, it's essential to provide as much context as possible, involve the translation team in the context gathering process, and try out different context gathering methods to find what works best for your content. If you like to see how Locize looks like, check out this video and try the free trial."},{"slug":"localization-marketing","title":"Marketing localization in your business (2026 guide)","description":"With this ultimate guide, you will transform your global marketing efforts and discover the significance of marketing localization.","date":"2023-03-23","category":"Guides","thumbnail":"\/img\/blog\/localization-marketing\/localization-marketing-thumbnail.webp","readTime":"9 min read","searchText":"title: 'Marketing localization in your business (2026 guide)', description: 'With this ultimate guide, you will transform your global marketing efforts and discover the significance of marketing localization.', date: '2023 03 23', updated: '2026 09 03', thumbnail: '\/img\/blog\/localization marketing\/localization marketing thumbnail.webp', image: '\/img\/blog\/localization marketing\/marketing localization illustration.webp', category: 'Guides', tags: ['localization', 'guides', 'marketing'] Technology has accelerated globalization, allowing organizations to connect with customers across the world with ease. However, it can be tough to know where to start when it comes to implementing a localization marketing strategy. An older example, but still valid as it shows the importance of marketing localization, was that of Nokia. The company faced a major setback when introducing its Lumia phone in Spanish speaking regions due to the product's name being colloquially associated with the term \"prostitute\" in Spanish. Today you are going to learn exactly how to avoid marketing localization mistakes and how to implement a localization procedure in your business. Update, September 2026: this guide first appeared in 2023, before AI translation became the default first draft. The principles held up; the workflow did not. We refreshed the steps for an AI first process (AI drafts, humans review), added the one mistake that did not exist in 2023 (shipping raw AI output), and replaced sources that have since gone offline. Table of contents What is localization in marketing? Why is localization in global marketing important? How to implement marketing localization in your business Potential mistakes to avoid in global marketing localization Exploring successful global marketing campaigns: Examples from known brands How to measure global marketing efforts 7 steps for marketers and project managers to effectively localize their marketing content What is localization in marketing? Simply put, localization in marketing is the process of adapting your marketing material to ensure that it meets the interests and needs of your various target markets. Working across a global market means you will be interacting with different cultures and customer expectations. Being able to understand their needs will allow you to effectively translate your material and maximize your chances of converting leads into long term customers. Why is localization in global marketing important? Did you know that 50% of online shoppers purchase something from a company that is outside their home country? While globalization is a wonderful way to increase your business, competition is also incredibly tough. Localization will help to give your brand the edge by ensuring you are reaching customers in their native language. Localization is much more than just translation, though. It is about using the cultural idioms, p
40hrases, and symbolism, helping to increase trust and overall satisfaction. Process Purpose What is adapted Marketing Translation Create marketing messages that resonate in other markets Message (copy, text) Marketing Localization Create experiences that resonate in other markets Message, visuals, UX elements Localization Marketing Leverage localization for growth through a digital marketing strategy Systems and processes (to support the strategy) How to implement marketing localization in your business Now we have answered the question, âwhat is localization in marketing?â it is time to look at how you can begin to implement it into your business. This can seem a daunting process, but there are several steps to remember: 1. Hire the experts, to review rather than to type In 2026 the first draft comes from AI. Professionals still matter, but their job has moved: they know your demographics, the language of your target audience, its culture and the nuances that make you sound local, and they apply that judgement to what the AI produced instead of translating from scratch. The cost per market drops; the need for a native reviewer does not. 2. Localize your website Alongside your marketing materials, you should also localize your website. According to CSA Research, 76% of online shoppers prefer to buy products with information in their own language, and 40% will never buy from websites in other languages. Failing to localize your website for non English speakers therefore restricts your reach and your sales directly. 3. Humanize your brand Another vital aspect of your localization marketing strategy should be humanizing your brand. When potential customers see your brand engaging in their language, using cultural elements, popular slang and words in their products and services, they are far more likely to complete their purchase. 4. Use local partners Influencers now play a major role in marketing campaigns for businesses across almost every industry. However, when it comes to localizing your marketing plan, you should look at the partners you are operating with and adapt accordingly to influencers in the local market. Potential mistakes to avoid in global marketing localization Despite its importance, there are many common mistakes that organizations make in their localization strategy, including: Focusing on a universal approach One of the most common mistakes is adopting a universal approach. Effective localization is not a one size fits all and requires careful tailoring to ensure your brand is reaching the most effective touch points of your target market. Not localizing every aspect Another common mistake is only localizing certain aspects, such as print advertising. Neglecting certain areas, such as your socials or website, can lead to customers heading elsewhere. Poor translation Poor translation is another common mistake when it comes to marketing localization. Working with a professional localization partner will ensure that you are not using any embarrassing or incorrect phrasing. Shipping raw AI output The 2026 version of the same mistake. AI translation is a good first draft and a poor final one: it does not know that \"drive\" means storage in your product, it reverts the tone a reviewer already fixed, and it drifts from your glossary across thousands of strings. Route every AI draft through a review step with a glossary and translation memory behind it, and keep a record of what was machine generated. In the EU that record now matters legally, see is machine translated content \"AI generated\" under the EU AI Act? and when AI translations break. Easily Create Prototypes for Multilingual Interfaces Exploring successful global marketing campaigns: Examples from known brands Transcreation is a term used in the advertising and marketing industry to refer to the process of adapting a message from one language and culture to another while maintaining the intended emotion, tone, and context of the original message. It goes beyond just translation as it involves the creative process of rewriting and adapting the message to fit the cultural and linguistic nuances of the target audience, while still conveying the same meaning and impact as the original message. Transcreation is especially important for global marketing campaigns, where the same message needs to be conveyed across different languages and cultures. It allows companies to effectively communicate their brand message and values to a global audience, while also respecting the unique cultural differences and nuances of each region. When done effectively, a global marketing campaign can transform a business and propel them onto success. Some great examples include: Red Bull One of the leading brands in the world, Red Bull can often feel like a local company. Their support of local sporting events, from F1 to Soapbox races, ensures they are continuously being placed in front of their relevant audience. Airbnb Since its launch in 2008, Airbnb has grown from its San Francisco base to become one of the most recognized businesses in the world. Its âMade Possible By Hostsâ campaign brought the company into the homes of potential customers across the globe. McDonaldâs The iconic golden arches of McDonaldâs are recognized across the globe, and its marketing efforts are one of the best examples of localization. While the colors and themes remain similar, the fast food chain focuses on using region specific menus; for instance, the use of flatbreads in the Middle East or Macaroons in France. How to measure global marketing efforts While there can be no denying the benefits that come from marketing localization, it is vital that you are effectively measuring your results. In order to determine your performance, you should first set yourself some clear goals of what you want to achieve and by when. This will act as your benchmark and will allow you to track whether you are on course to achieve them. Of course, one of the biggest factors to consider is your ROI. In this \"what is Marketing ROI guide\" you will find more information about how to measure it. This is a very effective method of understanding the efficiency of your global marketing efforts as there is a clear correlation between your activities and sales. You should also regularly assess your results. global marketing key performance indicators Source: 20 Marketing KPIs You Need to Be Monitoring Progress and effectiveness in achieving
40key business objectives can be measured with the help of Key Performance Indicators (KPIs). Low level KPIs focus on processes within departments such as marketing, sales, and HR. The following global marketing KPIs can be used to assess marketing effectiveness and plan strategies and budgets for upcoming periods: KPI Purpose Sales Growth Measures the effectiveness of marketing strategies by looking at how much of the total revenue was influenced by marketing efforts. Lifetime Value of a Customer Tracks the revenue a business can expect from one customer over a lifespan. Cost of Customer Acquisition (CAC) Measures the cost of acquiring a new customer. Customer Retention Measures how many customers continue to use the company's product or service. Net Promoter Score (NPS) Measures customer loyalty and satisfaction. Digital Marketing ROI Assesses monthly and annual performance to help plan strategies and budgets for upcoming periods. Leads Indicates the number of sales opportunities and a better chance of sales growth. Website Traffic to Website Lead Ratio Measures how many website visitors are converted into leads and indicates the quality of website traffic. Website Lead to Marketing Qualified Lead (MQL) Ratio Indicates the number of total leads generated by the website that are promoted to Marketing Qualified Lead. Click Through Rate (CTR) Measures the number of clicks on a link compared to the number of impressions. Organic Search Traffic Measures the number of people finding the company's website through organic search results. 7 steps for marketers and project managers to effectively localize their marketing content 1. Select your target market: Before starting the process of marketing localization, you need to identify the specific market you want to target. This involves understanding the cultural, linguistic, and other unique factors of the new market. 2. Analyze and adapt your message: Once you have identified your target market, you need to analyze and adapt your message to fit the new market. This may involve changing the tone, language, and even the content of your message to be more relevant and engaging for your new audience. 3. Combine AI drafts with local reviewers: Let AI produce the first version, then have native reviewers who know the market check accuracy, tone and cultural fit before anything ships. The reviewers should be well versed in the nuances of the language and culture; the AI should be given your glossary and brand voice so that the drafts start close to right. 4. Hire a localization expert or project manager: To oversee the entire process of marketing localization, you should hire a localization expert or project manager. This person will be responsible for ensuring that the localization process is executed efficiently and effectively, and that the end result is of high quality. 5. Use a modern localization platform: To streamline your marketing localization efforts, you should use a modern and lightweight translation management system. This platform can help automate routine tasks and provide a single source of truth for all things localization, which allows for efficient collaboration, management, and review of translations. 6. Customize the workflow: By customizing the workflow, you can build a process that works for your team and use a dashboard to maintain it. This can help you achieve consistency in tone of voice and messaging through an updated glossary and translation memory. 7. Take advantage of platform features: To eliminate idle waiting time and streamline your marketing localization efforts, you should take advantage of platform features such as version control, automated quality checks on AI output, review workflows per language, and insights into bottlenecks. This can help you stay on top of your localization project and ensure that it is completed on time and to a high standard. If you want the AI first workflow above without building it yourself, create a free Locize account: AI drafts, review per language, glossary and translation memory, and translations that go live without a deployment."},{"slug":"i18n-serverless","title":"The Role of i18next and Translation Management Systems in Serverless Architectures","description":"The article discusses the role of i18next and Translation Management Systems in serverless architecture for efficient and cost-effective localization.","date":"2023-03-07","category":"Engineering","thumbnail":"\/img\/blog\/i18n-serverless\/title.jpg","readTime":"6 min read","searchText":"title: 'The Role of i18next and Translation Management Systems in Serverless Architectures', description: 'The article discusses the role of i18next and Translation Management Systems in serverless architecture for efficient and cost effective localization.', date: '2023 03 07', thumbnail: '\/img\/blog\/i18n serverless\/title.jpg', image: '\/img\/blog\/i18n serverless\/title.jpg', category: 'Engineering', tags: ['localization', 'i18n', 'engineering', 'i18next', 'tms', 'serverless'] In today's globalized world, localization has become a vital factor in ensuring business success. Customers prefer to interact with products and services in their native language, and businesses need to adapt to this demand. With the emergence of Serverless Architectures, it has become easier for developers to build and deploy applications without worrying about infrastru
40cture management. But how can businesses ensure that their serverless applications are multilingual? In this article, we'll explore the role of i18next and TMS in serverless architectures and how they can help businesses build and deploy multilingual serverless applications. What is Serverless Architecture? Serverless architecture is a cloud computing model where the cloud provider manages the infrastructure and automatically allocates resources as needed. It's a pay per use model, where businesses only pay for the actual usage of the application. Developers can focus on writing code and building applications without worrying about infrastructure management, scalability, and availability. What is i18next? i18next is an open source internationalization framework for JavaScript that provides a complete solution for managing translations in web applications. It's lightweight and easy to integrate into serverless applications. i18next allows developers to organize translations into files, use interpolation, pluralization, and format translations based on the user's locale. i18next also has support for popular frontend frameworks such as React, Angular and Vue, etc. The Challenges of Multilingual Serverless Applications One of the biggest challenges of building multilingual serverless applications is managing translations. Applications that are built for a global audience require content to be translated into multiple languages. Manually managing translations can be a daunting task, as it involves managing multiple translation files, keeping track of translations, and ensuring consistency across languages. Additionally, deploying multiple versions of the application for each language can be a logistical nightmare, especially if you have to manage multiple tiny parts like AWS Lambda functions. For classic web applications, you usually have 2 parts where internationalization tasks occur: The client side (usually some modern single page app) and the server side. The translation resources are usually stored in the same place, so that the client and the server can read them. In case of i18next, the client can access them using i18next http backend and the server can access them using i18next fs backend. Here is an example of what this might look like on the client side. Here for an example of how this could look on the server side. But for serverless environments, you may have multiple clients, and you may have multiple small serverless functions that respond to a request in the appropriate language, or send some emails in the user's preferred language, and so on. Serverless E Mails Let's think about a serverless function that generates and sends some emails. For example we want to send an invitation to someone. We need the email address, the recipient's preferred language, an email template and some translations. To achieve this goal, you usually need to transform some raw data into html content (or text) to be displayed in the user's preferred language. In this example we will use pug (formerly known as \"Jade\", and also originally created by TJ Holowaychuk) to define some templates that should be filled with the data needed in the email, and mjml to actually design the email content. Let's create a new file, which we can use, to accomplish this. The could look like this: Now let's define some translations... ...and use them in an file: So finally, all the above can be used like that: This is how the resulting html could look like: mail preview ð§âð» A code example can be found here. Translation Management Systems in Serverless Architecture Ok, i18next seems to be able to handle these i18n tasks. But what about managing of all those translation files in these different serverless functions and also in the different clients? There's no central location anymore it's all distributed. We need a solution for that! We need a Translation Management System. A Translation Management System (TMS) is a software platform that enables businesses to manage their translation workflow. It provides a central repository for storing translations and enables collaboration between translators. When integrated
40with i18next, TMS such as Locize can streamline the localization process in a serverless architecture. Here are some of the benefits of using a TMS integrated with i18next in a serverless architecture: Automatic updates of translations When using a TMS, translations can be automatically updated whenever a new language is added or an existing translation is changed. This eliminates the need to manually update the translations in the codebase, which can be a time consuming task. Improved scalability A TMS can handle translation requests from multiple applications and languages, making it easy to scale the localization process. By integrating a TMS with i18next, businesses can easily manage translations for multiple applications without worrying about the scalability of the translation process. Reduced costs By using a TMS, businesses can reduce the cost of managing translations. A TMS provides a central repository for storing translations, eliminating the need to manage translations in multiple codebases. This reduces the time and effort required to manage translations, resulting in lower costs. Improved security A TMS provides a secure environment for storing translations, making it easy to manage translations without worrying about security concerns. By using a TMS integrated with i18next, businesses can ensure that their translations are stored securely and are only accessible by authorized personnel. Implementing Possible Approaches for TMS with i18next Client side For the client side it's that we can go full steam ahead. We can live download the translations on demand directly from the Locize CDN. This way we can change translations or add new languages directly in Locize without having to modify or redeploy the client app. In addition, we can unleash a lot of extra features to speed up the localization process. For example: We can use the saveMissing feature to add new keys and automatically translate them with machine translation. We can find and filter in Locize which keys are used or not used anymore, thanks to the last used plugin. We can find and edit translations directly in the In Context editor. Have a look at this tutorial or this video to just see just a few of these cool things. Server(less) side For the serverless side we could trigger a new serverless deployment every time a new translation version is published. Using webhook events or triggering a GitHub Action via GitHub Repository Dispatch Event. Or download the latest translations each time a serverless function is built and deployed using the locize cli or with the GitHub Action. Conclusion In summary, i18next and a translation management system like Locize are powerful tools for managing translations in a serverless architecture. By integrating i18next with a TMS, businesses can streamline the localization process and reduce the cost of managing translations. The integration also provides improved scalability and security. Enterprises and developers can easily implement a TMS integrated with i18next in their serverless architecture by following the steps outlined above. If you're already using i18next and want to unleash its full potential, have a look at this. If you're new to i18next, have a look at this guide and check out the free crash course. If you want to see a nice overview of the different i18n formats, have a look at this. If you like to see how Locize looks like, check out this video and try the free trial."},{"slug":"i18next-migrate","title":"Fastest way to unleash the full power of i18next (in 3 steps)","description":"Learn the fastest way to unleash the full power of i18next with Locize and get the most out of your internationalization efforts.","date":"2023-02-14","category":"Tutorials","thumbnail":"\/img\/blog\/i18next-migrate\/title.jpg","readTime":"2 min read","searchText":"hideCta: true, title: 'Fastest way to unleash the full power of i18next (in 3 steps)', description: 'Learn the fastest way to unleash the full power of i18next with Locize and get the most out of your internationalization efforts.', date: '2023 02 14', thumbnail: '\/img\/blog\/i18next migrate\/title.jpg', image: '\/img\/blog\/i18next migrate\/title.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'i18next', 'performance'] Internationalization (i18n) and localization (l10n) are crucial for businesses that want to expand globally and reach a wider audience. To do this, you need a robust solution that can handle different languages and cultural nuances, and this is where i18next and Locize come in. These two elements have been designed to help you get the most out of your i18n efforts, and when used together, they are a powerhouse combination that can help you achieve your goals faster and more efficiently. In this article, we'll explore the fastest way to unleash the full power of i18next in 3 steps. Precondition We assume you know i18next and already use it. If you don't know i18next, we suggest you read this. In this article, we also assume you're loading your translation resources via i18next http backend plugin, but that's not really mandatory. Step 1 Create a Locize project Sign up and create a new Locize project for free, like described here. Define your source language and if needed change the i18n format. Then, add all your target languages, as de
40scribed here Step 2 Migrate your translations Execute the Locize cli migrate command. Copy paste the project id and the api key from your Locize project settings page, and use it as arguments for your command. Also, make sure to pass the path of your current translation files. Step 3 i18next locize backend Install the i18next locize backend plugin and replace your current backend plugin. Copy the project id and pass it via i18next backend options. Done! Yes, the important part is already done. Now the translations are directly coming from Locize. This means you can also delete your old locales directory. If you change a translation text in Locize, you can see the updated texts in your UI. This is already awesome, but we can do more. Extra Step 4 InContext editor By installing the Locize module and passing it to i18next, we can work directly within the InContext view of Locize. Extra Step 5 Save missing keys Enabling the saveMissing option of i18next and passing the api key via backend options, will automatically add newly defined keys to Locize. Additionally, if you enable the automatic machine translation option in Locize, the passed default value of your new keys is automatically translated into your target languages. That's just a first sneak peek on how you can power up i18next. Locize offers a lot more. Try it for free and send us your feedback."},{"slug":"what-is-mobile-app-localization","title":"Why does app localization matter for growth?","description":"Learn how localization can help you growth your app. This guide will explain what â
app localization is and how to use it.","date":"2023-02-09","category":"Guides","thumbnail":"\/img\/blog\/what-is-mobile-app-localization\/what-is-mobile-app-localization.webp","readTime":"10 min read","searchText":"title: 'Why does app localization matter for growth?', description: 'Learn how localization can help you growth your app. This guide will explain what â
app localization is and how to use it.', date: '2023 02 09', thumbnail: '\/img\/blog\/what is mobile app localization\/what is mobile app localization.webp', image: '\/img\/blog\/what is mobile app localization\/what is mobile app localization.webp', category: 'Guides', tags: ['localization', 'guides', 'basics'] Today you're going to learn what app localization is and how to use it to greatly simplify your app's content management. Table of contents What is mobile app localization? Make your app scalable with localization What is the difference between localization and internationalization? What is the process of localization? App store optimization for localization How to find translators? App localization tips: How to localize your app How it worked for others Conclusion In fact, these tips have helped three clients of us to manage multiple languages and significantly grow their potential user base. Effective localization will ensure that your product is not only meeting the requirements of your chosen demographics, but also helping you to reach new audiences. Therefore, you'll appreciate this article if you wish to increase the number of registrations for your mobile application. Let's begin by having an understanding of the purpose of app localization. What is mobile app localization? In this highly connected digital world, globalization is an essential part of any business. Being able to effectively reach and engage with customers around the world is crucial, especially for mobile app developers. With the rise of smartphones, apps have become a core part of our daily lives. From ordering food to watching films, research has shown that over 230 billion mobile apps were downloaded in 2021 alone. This extensive use means localization of an app is crucial in ensuring your products can reach consumers anywhere in the world. What is this localization, though, and how can it help? Make your app scalable with localization Mobile app localization is a highly beneficial aspect of any business. This is a unique process that requires you to adapt your app so that it can be used by consumers in a wide range of localities. This could require adapting the wording so that it is in the right language, or even changing the layout to suit the target market. With nearly five billion smartphone users in the world, the localization of apps ensures that your product can be enjoyed by customers no matter where they might be located. five billion smartphone users What is the difference between localization and internationalization? Localization and internationalization are two vital strategies for any business, but many people often confuse the two. While they are two similar methods and both rely on each other, they do have tw
40o very different approaches. Internationalization is the process of adapting your mobile app code so that it can be easily modified and adapted into the required language. On the other hand, localization is the process of actually customizing the content so that it meets the expectations of the chosen destination. This means that internationalization needs to happen first, ensuring that mobile app coding is ready to meet the adaptations of localization. Find out more about internationalization in our guide on what is i18n. You can't wait to see how others did it. Please read through some success stories. mobile app What is the process of localization? While there can be no denying the many benefits that come from localization, it is a comprehensive and time consuming task. To help you, we have taken a closer look at the process: 1) Planning The first stage of any localization strategy is to ensure that you focus on your planning. This process should cover: Deciding which countries and regions to target with your app localization efforts. The research into the languages you are looking to focus on, how you will do this, and what requirements are needed to successfully meet the demands of your target audience. 2) Execution Once you have comprehensively planned your localization strategy for the app, the next step is to execute the changes. This should be taken with the utmost care and attention, carefully working through every aspect and feature of the app to ensure that they are meeting the requirements. Here are some examples: Translate your app's title, description, and keywords into the target language to improve visibility and search ranking in local app stores. Adapt your app's screenshots and videos to better fit the cultural preferences and expectations of local users. The coming chapter gives you the full list of potential optimizations for a mobile app. 3) Testing With the translations made, you need to ensure that you are conducting a comprehensive testing strategy to ensure that it meets the exact requirements of your target audience. A beta test is the most effective way of doing this. Beta testing is the process of having the app reviewed by native speakers of your target demographics, having them review the copy and design. This should not be rushed, and you should be methodical with your beta testing to guarantee the very best result. Test your app with real users in your area, and ask them to give you feedback on the localization as they use it. Verify text and character encoding to ensure that everything is accurately encoded and shown on all devices. Verify linguistic and cultural consistency: Make sure that all app components, including text, graphics, and sounds, are suitable from a culture standpoint and adhere to regional norms. Test the language switching capability of the app to ensure that users can quickly and simply switch between languages. Including an in app feedback feature can be very beneficial, with research showing that it can increase feedback by up to 750%. 4) Publish your updates Once your beta tests have been completed, it is time to publish your updates. This is the final step to getting your mobile app out there and being used by consumers. 5) Bonus tip â read customer reviews and check analytics data Of course, there is no better way to ensure that your app is the very best it can be than by reading customer reviews. This is your chance to see exactly what customers are thinking, allowing you to adapt the app accordingly. Your app analytics are an excellent location to look for potential growth directions. Determine where the majority of your consumers or loyal users originate from. process of localization App store optimization in terms of localization 1. Translate app metadata: To improve visibility and search ranking in local app stores, translate your app's title, description, and keywords into the target language. 2. Target local keywords: Conduct keyword research to identify relevant local keywords and include them in the metadata of your app. 3. Localize app visual assets: Tailor your app's screenshots and videos to the cultural preferences and expectations of your target audience. 4. Provide local payment options: To increase conversion rates among local users, provide local payment options such as local currency and popular payment methods. 5. Engage with local communities, such as online forums and s
40ocial media groups, to raise awareness and promote your app to potential users. 6. Provide local customer support: To provide a better experience for local users, provide local customer support, such as a local language helpline or chat service. 7. Customize in app content: Tailor in app content like promotions and notifications to the local culture and language. 8. Localize in app purchases: To improve conversion rates and user experience, localize in app purchases such as pricing and product descriptions. 9. Monitor your app's ranking in local app stores and make any necessary adjustments to your ASO strategy based on the results. How to find translators? Comprehensive translation is essential to any localization process, but finding the right translator can be tough. There are several tips to remember when finding a translator, including: 1) Background The first thing to do is to review their background. You want to ensure that your chosen translator has a proven history in your target language, either being a native speaker or has spent considerable time in that country. 2) Be clear When engaging with a translator, you should make sure that you are as clear and straightforward as possible. The more thorough you are with your instructions, the better your translator will be able to understand your requirements. 3) Ask for examples Another top tip when it comes to finding the very best translator possible is to ask for examples. Any professional translator will be happy to showcase their past work, allowing you to review their results. In our ecosystem, there is a way we make this much easier for you. Learn here how to find a translator. find a translator find a translator How to choose the right localization technology Technology has transformed the world around us, helping to make things more efficient and easier. This is true when it comes to mobile app localization, and there are some fantastic options out there to help you make the process as quick and as easy as possible. However, it is essential that you are utilizing the right technology. Not having the right localization tools can lead to poor results, so when it comes to finding the right localization technology, there are certain things you should look for: A collaborative process that allows copywriters, designers, managers, and more, to work together. A solution that lets you reuse app strings and content, helping to save you time and money. A built in glossary of mobile app terms to ensure consistency. Automation tools for tasks such as string extractions, performance monitoring, workflow management, and screenshot generation. Integration with other essential apps such as Slack and Jira. Ability to support multiple file types and file format. You can improve the user experience of your global app and attract more customers by implementing a proper translating app process for your content. This is why every app business should use localization services. Learn more App localization tips: How to localize your app When it comes to app localization, there are several top tips to remember. The first is to ensure that you are being as comprehensive as possible in your beta testing. This will give you the knowledge and insight on what is working and what areas still need to be improved. You should also ensure that you are being as flexible as possible when it comes to adapting your mobile app into different languages. You also want to ensure that your app is able to support languages that read right to left and left to right, guaranteeing that it flows for readers no matter where in the world that they might be based. The support of numerous languages will also have a favorable impact on the app store listing . Another helpful tip is to transfer strings from code to resource files. Because storing strings in resource files before deploying code allows the team to access those files for translation later without having to change the code. The team may access those files for translation without having to update the code itself. Check out our localization software; it's exactly what we can help you with, and it only takes a few steps to get started. How it worked for others We offer a simple and scalable translation management system that has assisted many of our customers in attaining their development with mobile applications. 1) naki Naki was able to manage and keep up their products in more than six languages. Locize is for them, they claimed: As a product company which releases mobile applications throughout Europe, we were looking for a tool that allows us to easily involve who translate and keep the maintenance of the copywriting seamless. nakipower 2) retraced.com Retraced, a blockchain based platform for supply chain transparency that focuses on the end user, uses Locize for its app localization. We utilise Locize throughout our infrastru
40cture in two mobile applications. Locize is a very reliable service and scales beautifully with the business. retraced 3) barntools.com BarnTools, a digital biosecurity platform created by producers for producers, used Locize to quickly and easily localize its mobile application. It enables our global team perform the translation work anywhere and anytime. We also get to maintain the translations in realtime. barntools Conclusion It is now up to you to make a decision. The process of adjusting a mobile app's functionality and user experience for users in various target markets is known as localization. Start to plan your target regions and languages. A highly scalable solution will ensure that your iOS, Android, or other app meets your customers' needs and that you can execute the project efficiently. Because how you handle the app translation process will determine your mobile application's success and ability to reach a worldwide audience. You may discover how to use Locize in your development and how your team can work with it by clicking the link below. In the end, localizing your apps will increase your revenue and enhance user experience. For your team Now we'd like to invite you to share this with any developer, project manager, or business that could benefit from it."},{"slug":"google-translate-accuracy","title":"How Accurate Is Google Translate? A 2026 Guide","description":"How accurate is Google Translate? It's reliable for general comprehension between major language pairs, less reliable for idiomatic, technical, or low-resource content. Here's how it works, where it falls short, and how to use it well.","date":"2023-02-07","category":"Guides","thumbnail":"\/img\/blog\/google-translate-accuracy\/title.jpg","readTime":"6 min read","searchText":"title: 'How Accurate Is Google Translate? A 2026 Guide', description: \"How accurate is Google Translate? It's reliable for general comprehension between major language pairs, less reliable for idiomatic, technical, or low resource content. Here's how it works, where it falls short, and how to use it well.\", date: '2023 02 07', thumbnail: '\/img\/blog\/google translate accuracy\/title.jpg', image: '\/img\/blog\/google translate accuracy\/title.jpg', category: 'Guides', tags: ['localization', 'guides', 'machine translation', 'google translate'], faq: [ q: 'Is Google Translate accurate?', a: 'It is accurate enough for general comprehension between major language pairs, but quality drops for idiomatic phrases, technical terminology, low resource languages, and culturally specific content. It is not suitable as a final draft for legal, medical, or marketing quality translation without human review.' , q: 'What is the most accurate translation tool?', a: 'It depends on the language pair and content. DeepL is widely considered to produce more fluent output than Google Translate for major European language pairs. For software localization, specialized AI translation inside a translation management system like Locize, paired with a project glossary, style guide, translation memory, and human review, produces better results than any single tool used in isolation.' , q: 'Is Google Translate good for professional translation?', a: 'Not on its own. It is useful as a fast first draft, especially when paired with human post editing. Professional translators typically use CAT tools and translation management systems (TMS), like Locize, that combine machine output with translation memory, glossaries, style guides, and review workflows.' , q: 'What languages does Google Translate work best for?', a: 'Major European language pairs (English â Spanish, French, German, Italian, Portuguese, Dutch) typically produce the most fluent output, because they have the largest training corpora. Low resource and culturally distant language pairs can be less reliable, particularly for nuanced or idiomatic content.' , q: 'Is Google Translate free?', a: 'Yes, the consumer Google Translate at translate.google.com is free. The Google Cloud Translation API (the developer service) is paid, with a free tier for low volume usage and per character pricing above that.' , q: 'Does Google Translate save my data?', a: 'Free Google Translate sends your text to Google\\'s servers as part of normal product operation. For sensitive content (contracts, medical records, internal documents), use a paid translation service with a data processing agreement, or a self hosted alternative.' , q: 'Can I use Google Translate for software localization?', a: 'It works as a starting point, but raw Google Translate does not preserve i18next interpolation syntax ( ), plural suffixes, or your project\\'s glossary. Tools like translate.i18next.com and translation management systems like Locize handle these correctly, and let you route AI output through human review before publishing.' ] Google Translate is a free machine translation service launched by Google in 2006 that converts text, speech, and images between 130+ languages. Since 2016 it has been powered by neural machine translation (NMT), which produces noticeably more fluent output than the older statistical approach. Accuracy depends heavily on the language pair and the type of content: it's reliable for general comprehension across major language pairs, weaker for low resource languages and idiomatic, te
40chnical, or culturally specific content, and not suitable as a final draft for legal, medical, or marketing copy without human review. Key facts Launched: 2006 Technology: neural machine translation (since 2016) Languages supported: 130+ Best for: gist and general comprehension across major language pairs Not for: legal, medical, or marketing quality work without human review How Google Translate Works Google Translate launched in 2006 using statistical machine translation (SMT), a system that learned word and phrase probabilities from large parallel corpora (texts available in multiple languages, like UN and EU proceedings). SMT produced understandable but often stilted output. In 2016, Google rolled out Google Neural Machine Translation (GNMT), replacing the SMT system with a deep learning model that translates whole sentences in context rather than piece by piece. The 2017 introduction of the Transformer architecture), also from Google Research, pushed quality further by letting the model attend to long range dependencies across a sentence. Google Translate is continually updated as new training data becomes available and as the model is fine tuned for specific language pairs. Users can also submit feedback on individual translations, which contributes to ongoing improvement. The Limitations of Google Translate Google Translate is a highly capable system, but it is still bounded by its data and its lack of true language understanding. The main limitations: Lack of context : NMT translates a sentence at a time. It does not always know what came before or after, which matters for pronoun resolution, polite\/informal register, and disambiguating words with multiple meanings. The phrase \"I'm falling for you\" can be translated as something closer to \"I am physically falling onto you\" in Spanish, missing the romantic sense. Ambiguity : Words often have multiple meanings, and Google Translate has to pick one based on probability. The English word \"bass\" can mean a fish or a low frequency sound: both meanings have different translations in other languages, and the model can pick the wrong one when context is thin. Cultural differences : Idioms and cultural references rarely have direct equivalents. \"Beating around the bush\" rarely translates word for word into a culturally equivalent idiom. Syntax awareness for software : Text used in software localization (internationalization) often contains framework specific syntax: interpolation placeholders like , plural suffixes ( , ), and tags specific to your i18n format. Raw Google Translate often does not respect these. More specific tools such as translate.i18next.com or the CAT view in Locize are designed for this. Hallucinations and omissions : Like all neural language models, Google Translate works on probability, not understanding. It can occasionally drop words, repeat phrases, or generate output that is not in the source, especially for long, technical, or low resource content. Factors That Affect Google Translate's Accuracy Several factors materially impact output quality: Quality of input text : Poorly written source (typos, run on sentences, missing punctuation) degrades accuracy quickly. NMT depends on well formed input to extract meaning. Language pair : Major European pairs (English â Spanish, French, German, Italian, Portuguese, Dutch) produce the most fluent output because they have the largest training corpora. Low resource pairs (Welsh, Yoruba, Pashto, Burmese) and culturally distant pairs can be noticeably less reliable. Domain specific terminology : Technical terms in medicine, law, finance, or engineering are often translated literally rather than with the correct field specific term. A glossary or translation memory is essential for these domains. Sentence length and structure : Short, well formed sentences translate better than long, nested ones. Google Translate's quality drops as sentences grow longer and more clauses are added. Effective and Efficient Usage of Google Translate Used well, Google Translate is a fast and useful tool. Used badly (or for the wrong content) it produces work that is more expensive to fix than to translate from scratch. Some practical tips: 1. Write clean source text : Before translating, fix typos, simplify long sentences, and resolve ambiguous pronouns. Output quality follows input quality. 2. Translate directly between language pairs : Don't pivot through a third language unless you have to. English â German is more accurate than English â French â German. 3. Provide context where possible : Translating a phrase in isolation produces worse results than translating the surrounding paragraph. 4. Check for cultural references and idioms : Before publishing, scan output for phrases that might not carry across cultures. 5. Use it for first drafts, not final copy : Google Translate is excellent for understanding the gist of a text in a foreign language. For anything customer facing, route the output through a translator or reviewer. 6. For software localization, use a specialized tool : A TMS like Locize lets you machine translate against your project's glossary, style guide, and translation memory, then route results through a human review workflow before publishing. Ethical and Privacy Concerns of Machine Translation Services Machine translation raise
40s a few concerns worth thinking about: 1. Data privacy : Free services collect and may store the text you translate. Anything sensitive (contracts, medical records, internal documents, customer PII) should not be pasted into a free public translator. 2. Bias and discrimination : Models reflect biases present in their training data. Gendered and culturally loaded language can be translated stereotypically. 3. Intellectual property : Translating copyrighted text through a third party service raises questions about who can use the resulting translation. The legal status of training data and output remains an active area of regulation, including the EU AI Act. 4. Confidentiality in business use : For business workflows, paid services with a data processing agreement (DPA) and clear data retention terms are the safer choice. Self hosted alternatives are also an option for sensitive content. Alternatives and Competitors Google Translate is the most widely used machine translation service, but it is far from the only option. Each tool has strengths in different language pairs and use cases: DeepL: high quality NMT with a strong reputation for fluent output on European language pairs; offers DeepL Pro with a DPA for business use Microsoft Translator: wide language coverage, deep integration with Office and Teams Amazon Translate: built for AWS based scale, with custom terminology support Meta NLLB 200: open source model covering 200 languages, with a focus on low resource pairs OpenAI ChatGPT, Anthropic Claude, Google Gemini: generative LLMs that translate well in context but are not specialized translation tools; quality depends heavily on prompt design and the language pair Reverso, Systran: translation services with their own NMT engines and additional features like example sentences and document translation When choosing a tool, consider the language pair, the content type, the volume, and your data privacy requirements. For a deeper comparison, see AI Translation: How AI Translation Changes the Industry and Machine Translation, Translation Memory, Generative AI, and More. Frequently Asked Questions frontmatter.faq.map(( q, a ) = ( q a )) Conclusion Google Translate is a powerful, free, and continually improving machine translation service. For general comprehension across major language pairs, it is a remarkable tool. For professional, customer facing, or technically specialized content, it is best used as a fast first draft, paired with a human reviewer, a project glossary, a style guide, and (for software) a tool that respects your i18n format. For higher stakes content, a human translation service like Supertext is a better fit. And for software projects using i18next, Locize AI integrates AI\/MT, glossary, style guide, translation memory, and human review directly in your translation workflow, without switching tools."},{"slug":"maintaining-open-source","title":"The joy, the pride and the burden of maintaining open source","description":"The joy and burden of maintaining an open-source project involves the influx of issues and pull requests, constant improvement, dealing with demanding users, and the importance of providing a minimal reproducible example to reduce time and effort for both maintainers and users, but despite the challenges, it is a rewarding experience that fosters a sense of community and collaboration.","date":"2023-02-01","category":"Open Source","thumbnail":"\/img\/blog\/maintaining-open-source\/opensource-title.jpg","readTime":"6 min read","searchText":"title: 'The joy, the pride and the burden of maintaining open source', description: 'The joy and burden of maintaining an open source project involves the influx of issues and pull requests, constant improvement, dealing with demanding users, and the importance of providing a minimal reproducible example to reduce time and effort for both maintainers and users, but despite the challenges, it is a rewarding experience that fosters a sense of community and collaboration.', date: '2023 02 01', thumbnail: '\/img\/blog\/maintaining open source\/opensource title.jpg', image: '\/img\/blog\/maintaining open source\/opensource title.jpg', category: 'Open Source', tags: ['localization', 'engineering'] As a maintainer of i18next, an open source localization library, I can attest that there is nothing quite like the feeling of joy and pride that c
40omes from contributing to the open source community. Seeing others use and appreciate your work is a feeling like no other. But with great power comes great responsibility, and maintaining an open source project can sometimes be a heavy burden at times. Let me paint you a picture: It's a sunny Sunday afternoon, and you're ready to relax and enjoy the weekend. But then, your phone starts buzzing. It's a notification from GitHub, alerting you to a new issue or pull request. You try to ignore it, but the nagging sense of responsibility sets in. You can't help but wonder, \"What if this is a critical bug that needs to be fixed ASAP?\" And so, you reluctantly open your laptop, ready to tackle the problem at hand. That, my friends, is the joy and the burden of maintaining open source. But it's not just the constant influx of issues and pull requests that can be overwhelming. It's also the pressure to constantly improve and update the project to keep up with the ever changing technology landscape. With i18next, for example, we need to stay on top of new localization trends and technologies, as well as ensure compatibility with the latest versions of popular frameworks and libraries . It can be a lot to keep up with, especially when you're also trying to balance a full time job, family, and other commitments. Despite the challenges, maintaining an open source project is a rewarding experience that I wouldn't trade for anything. The sense of community and collaboration is truly special, and it's an honor to be a part of something that helps so many people. Plus, there's nothing quite like the feeling of satisfaction when you finally fix that tricky bug or implement a new feature that makes the project even better. Another aspect of maintaining an open source project that can be challenging is dealing with demanding users . While most users understand and appreciate the hard work that goes into maintaining a project, some can be quite demanding, even threatening to stop using the library if their special request isn't implemented. It can be difficult to navigate these situations, as you want to keep your users happy, but you also need to consider the overall direction and goals of the project. It's important to remember that, as the maintainer, you have the final say over what gets added to the project, and what doesn't. It's also important to communicate with your users, and explain your reasoning behind certain decisions. When maintaining an open source project, remember that no one is forcing anyone to use it . While it's important to listen to feedback and try to meet your users' needs, it's also important to remember that the project is open source and free to use. This means that users have the freedom to use the project or not, and they also have the ability to contribute to it, or even fork it if they want to make significant changes. As maintainers, we should always be open to feedback and suggestions, but we must also be confident in our decisions and the direction of the project. We should also remember that most of us are volunteering, and that for most of us, this is a hobby, passion, or side project, not a paid job. We should not burn ourselves out trying to please every user. When users start insisting on free and ongoing support , that's not good. A common challenge in maintaining an open source project is dealing with users who report GitHub issues without enough information to reproduce and investigate the problem. Unfortunately, it's not uncommon for users to simply say \"there's a bug\" or \"it doesn't work\" without providing any additional details or context. This can make it extremely difficult for maintainers to understand and fix the problem. This is where the concept of a minimal reproducible example comes in. A minimal reproducible example is a small, self contained snippet of code that demonstrates the problem. It should include all the information necessary for the maintainer to reproduce the problem, including the version of the library, the environment, and any relevant configuration. Providing a minimal reproducible example can greatly reduce the time and effort required to investigate and fix a problem. Without it, the maintainer may have to spend hours trying to understand and reproduce the problem, which can be frustrating for both the maintainer and the user. It's important to educate users about the importance of providing a minimal reproducible example, and to communicate this clearly in your project's documentation. Some maintainers even have a template for issues and\/or pull requests that requires the user to provide such an example. It's also important to be patient and understanding when dealing with users who may not be familiar with the concept of a minimal reproducible example. Maintaining an open source project is a community effort, and it's important to work together to make the project better. Also, a pull request that includes a negative test case is very valuable. Sometimes it is useful to write a larger guide or blog post that users can go through to avoid basic problems. For example, for using i18next in a React application, we wrote this blog post that covers all the initial issues and hurdles. Remember that as a user of an open source library, you have the power to contribute to its development and make it even better. Don't be afraid to jump in and make a contribution, no matter how small. Every little bit helps, and it's a great way to give back to the community . Even if you are not a developer, you can contribute in other ways, such as writing documentation, or helping answer other users' questions. In fact, the best way to get a bug in an open source library fixed is to fix it yourself and submit a pull request . It's not only a great way to give back to the community, but it also helps you learn new skills and understand the codebase better and learn new skills. So don't hesitate to roll up your sleeves and get involved. In conclusion, maintaining an open source project is a challenging but rewarding experience. It takes dedication, hard work, and a lot of patience to keep an open source project running smoothly. But the sense of community and collaboration that comes with open source makes it all worthwhile. As a maintainer, it's important to remember that you're not alone in this journey, and that there are always other maintainers and contributors willing to help. As a user, remember that you have the power to contribute and make a difference. Open source is a community effort, and everyone plays a role in its success. Maintainers, contributors, and users all have a responsibility to work together to improve the project. Maintainers should be open to feedback and suggestions, and users should provide clear, detailed information about their problems and, if possible, suggest solutions or provide minimal reproducible examples. In short, maintaining an open source project is a challenging but rewarding experience that brings people together to work toward a common goal. It's important for everyone to work together. So let's continue to supp
40ort and contribute to open source projects and make the world a better place, one line of code at a time. Finally, I would like to thank Locize for giving us the opportunity to support our i18next community and allowing us to invest in open source activities. Without this support, i18next would not be where it is today."},{"slug":"website-localization","title":"What is Website Localization? Process, Examples & Checklist","description":"Website localization adapts a website (language, formats, currencies, images, layout, SEO, and legal compliance) for a specific market. This guide covers what it is, when to do it, the step-by-step process, and a working checklist with real-world examples.","date":"2023-01-31","category":"Guides","thumbnail":"\/img\/blog\/website-localization\/website-localization.webp","readTime":"10 min read","searchText":"title: 'What is Website Localization? Process, Examples & Checklist', description: 'Website localization adapts a website (language, formats, currencies, images, layout, SEO, and legal compliance) for a specific market. This guide covers what it is, when to do it, the step by step process, and a working checklist with real world examples.', date: '2023 01 31', thumbnail: '\/img\/blog\/website localization\/website localization.webp', image: '\/img\/blog\/website localization\/website localization.webp', category: 'Guides', tags: ['localization', 'guides', 'basics'], faq: [ q: 'What is website localization?', a: 'Website localization is the process of adapting a website (language, content, formats like date, time, currency, address, images, layout, SEO, and legal compliance) for a specific target market. It goes beyond translation: a localized website feels native to its target audience, not just translated into their language.' , q: 'What is the difference between website translation and website localization?', a: 'Translation converts the words. Localization adapts the whole experience: text plus date and number formats, currency, address layouts, plurals, gendered language, images, regional payment methods, legal references, and sometimes layout direction (RTL for Arabic and Hebrew). Translation makes a website understandable; localization makes it feel native.' , q: 'When should I localize my website?', a: 'Common triggers: launching a new product internationally, expanding into new markets, opening a new branch in another country, following a franchise or global platform model, or noticing materially lower conversion in some regions. The earlier in the development cycle you internationalize, the cheaper localization becomes: retrofitting i18n later is significantly more expensive than building it in.' , q: 'How do I localize a website?', a: 'A typical process: (1) define your strategy and target markets, (2) internationalize the codebase (extract strings, locale aware formatting, RTL support), (3) translate content using a translation management system with translation memory and glossary, (4) adapt images, currencies, payment methods, and legal references per market, (5) localize SEO (URL structure, hreflang, regional metadata), (6) test in every locale for layout, broken links, and form behavior, (7) ship and maintain: treat localization as continuous, not a one off project.' , q: 'What elements of a website need to be localized?', a: 'Beyond text: date and time formats, currencies, units of measurement, address formats, phone number formats, payment methods, holidays and seasonal references, images and gestures (cultural appropriateness), reading direction (LTR \/ RTL), plurals, gender specific words, privacy policy, and SEO metadata (URL slugs, hreflang tags, regional keywords).' , q: 'How does website localization affect SEO?', a: 'Localization is critical for international SEO. Each language version needs proper hreflang tags so Google serves the right version to the right user, locale targeted URLs (subdirectory, subdomain, or ccTLD), translated and locale relevant keywords (not literal translations of English keywords), and translated metadata (title, description, og:locale). Done right, localization multiplies organic traffic; done wrong, it creates duplicate content penalties.' , q: 'What tools or platforms are used for website localization?', a: 'Translation management systems (TMS), like Locize, Phrase, Crowdin, Lokalise, coordinate translators, store translation memory and glossary, and integrate with your build pipeline. Modern TMS platforms deliver translations via CDN so updates ship without redeploying code. For technical implementation, JavaScript projects use frameworks like i18next; PHP uses gettext or Laravel translation files; Ruby on Rails uses YAML translation files.' ] Website localization is the process of adapting a website (language, formats, currencies, images, layout, SEO, and legal compliance) for a specific target market. It goes beyond translation: a localized website feels native to its target audience, not just translated into their language. A typical localization project covers 12+ elements (date and time formats, units of measurement, currencies, payment methods, address formats, holidays, plurals, gendered language, images and gestures, reading direction, privacy policies, regional SEO metadata) plus the underlying engineering work (i18n) that makes the codebase support any language at all. Done well, website localization materially expands a company's addressable market and builds trust with international users; done poorly, it creates a translated looking site that converts worse than the original. Key facts What it is: adapting a website (language + culture + formats + SEO + legal) for a target market vs translation: translation = words; localization = whole experience vs internationalization (i18n): i18n = engineering preparation; localization = market by market adaptation What it covers: language, dates, currencies, payment methods, addresses, images, RTL layout, legal compliance, regional SEO SEO impact: hreflang tags, locale targeted URLs, translated metadata. Done right, multiplies organic traffic Common triggers: international launch, new market entry, franchise model, lower conversion in some regions This is a comprehensive guide to website localization. It covers what it is, when to do it, how to prepare, the step by step process, real world examples, and how to choose the right platform. For more general information about softw
40are localization beyond websites, check out our blog post about software localization. Table of contents What is website localization? Why should you be interested in a positive outcome? When is it appropriate to localize your website? Prepare the localization of your website A step by step process for web localization Examples: Popular and from our clients How to measure the quality Choose the right platform Conclusion What is website localization? It is part of internationalization and localization and entails much more than just simple text translation; it must take into account all language and cultural variables. If you are selling a decent product in your home market, it is possible that you are also doing so in other countries. If you wish to sell in Spain, for example, your information must be translated into an adapted message in their original language. You understand what website localization is? Now, let's find out why it's important: Why should you be interested in a positive outcome? A good website localization may help multinational businesses establish significant brand awareness outside of their home country. People on the internet clearly desire to buy from websites in their own language , as evidenced by several studies. Many firms utilize landing pages for a specific area to provide basic corporate information. This is not the strategy to take since the target audience may perceive a lack of enthusiasm for their location and requirements. Local customers anticipate a website that is identical to the one in your primary market. fifty two percent The localization of a website can increase the revenue of your company. It appears to be an administrative concern in most circumstances, but it is an investment in yourself and your organization. When is it appropriate to localize your website? You're wondering when to start localizing a site. This varies from firm to company, and a variety of factors can influence when the ideal time is reached. However, there are a few scenarios to bring you to start thinking about it: Your business is launching a new product. You must adhere to market standards. Your company is expanding internationally. Your company establishes a new branch in another country. Your business follows the franchising model. Your business figures are lower in some areas than in others. Your company acts as a global platform. Your company's global branding strategy is shifting. Prepare the localization of your website Look for a good preparation of your localization strategy, because it will end up in more than just translate some sentence. This process should be part of your overall business strategy, because there are many non technical aspects to consider when going into new markets: A step by step checklist for the business questions â¡ï¸ Examine the market is there a possible audience? â¡ï¸ Determine the local compliance needs â¡ï¸ Determine the best technology for localization â¡ï¸ Determine how we will market in the new place â¡ï¸ Decide who is part of the team (lead project manager, marketing expert, developer, etc.) â¡ï¸ Construct a list of quality assurance criteria If you come up with a strong plan and take into account all of the above checkpoints. Then it's time to go more into the webpage's details. A step by step process for web localization 1. Define the strategy of your website localisation 2. Design the content of all pages with internationalization in mind 3. Execute i18n on your website 4. Arrange your team the right way 5. Translate your webpages 6. Measure the quality and strategy 7. Keep up localization with the right software Keep the following techniques in mind for a successful implementation: Place the language selector correctly Change the formatting design a sentence in some languages can be substantially longer The currency should be according to customer need Think about the update of graphic and videos Ensure a proper information architecture Make it easy to update content Think about SEO Localization SEO should be done parallel to development (industry standard) Allow website integrations Verify the translations and results Elements to consider on website This list gives you an overview about what you need to keep an eye on when internationalize your website: the text the date and time formats the unit of measurement the holiday seasons the local currency the methods consumer can pay the way an address is written the local letters, symbols, grammar, etc. the plurals the phone numbers the privacy policy the images the videos All information must be given in a genuine manner to other locals so that they feel it is tailored to them. Also, the website's n
40avigation may vary as visitors from different regions engage differently with your website. Gender specific words can also be another possibility, which we do not discuss in detail here, but take that in mind. Understanding the language is frequently insufficient, because people will not buy from a webpage in English if it is not their first language. The material must reflect all of their familiar conditions, not just the language. Best practices â¡ï¸ More about the topic? Check the website internationalization best practices The article highlights effective practices for companies entering foreign markets and requiring website translation. There is a significant distinction between translation and localization. With these ideas, you may save a lot of money and time when your website becomes internationally. Furthermore, the best practices article provides a system for translating content and managing these translations. Create considerable brand awareness Examples There are well known examples all across the world of companies that have effectively implemented multilingual websites as part of their overall business strategy. www.tesla.com was one of the most well known examples we checked out. They offer a large number of regions from which to choose. They also adjust things like privacy policies and graphics to meet the needs of different locations. They do an excellent job of localizing their website, but it isn't perfect, and there are certain areas where they could improve. The following improvements are some general areas that, in the author's view, may be improved by not deeply analyzing their situation. First finding In the author's opinion, the language selector is difficult to discover and therefore not well situated for a good website experience. It's great that the website displays it based on IP address in advance. Second finding In the author's opinion, although switching languages is possible, the user does not receive sufficient tailored info for his intended location. The available Tesla Store Locations are hidden in a bottom menu and are difficult to find. It may help to direct the user's attention to these Locations, allowing the consumer to feel more home. Third finding In the author's opinion, some product description information is tailored to a larger geographic area, such as Europe. It isn't particular to different areas of Europe; they used the same data across many countries. However, this may be wanted from them, because the efforts would be excessive in comparison to the results they would get. \"The product speaks for itself\". The author is unable to conduct a thorough analysis of the technical localization aspects as part of this article. Locize examples We, at Locize localization management platform, have assisted many customers in achieving their goals with website localization . The following examples can assist you: 1) globalfinreg.com Globalfinreg has been able to efficiently localize their two websites thanks to Locize. They said Locize is for them: An easy to use interface for managing translations. It is possible to regulate exactly what each translator sees, and they enjoy doing so. The UI also allows you to easily check which translations are needed and divi
40de your application into separate namespaces. globalfinreg 2) www.redcross.ch Thanks to the generous support and the features of Locize, the headless websites of the Swiss Red Cross can be translated into different languages within a short time! swiss red cross Quality ensurance The quality check is essential for the team to get a measurement of where the project is standing in order to provide the correct website experience. As a result of this, improving any project milestones or refining website content will be beneficial. This should also contain a check to see if the translators did a good job. In some circumstances, contemporary technology such as machine translation will automate the procedure. As a result, human monitoring can assure not only the quality of the language on the website, but also its functionality and site experience. We have the following two areas of testing for localization in the web: Language Testing Is the language properly tested, and are all words correct and understood? Ensure consistency since success and failure can be determined by trust. This list might be useful for testing local language: Wrong use of language Spelling mistakes Restricted words in a culture Non readable sentence Language Errors Localization Testing Testing the localization ensures that your various language site versions work properly. Distribute your testers by newly targeted markets. Check the operation of all web forms and checkout functionality. Also if there is any broken design to fix. A short list you can find below: Check for non translated strings Long website loading times Wrong date and time format discovered Check for broken strings Check hardware compatibility Ensure Hyperlinks operate Form and Checkout features must be tested Choose the right platform A multilingual website is typically a large undertaking, and using a well established localization management solution will assist you in completing it more quickly. When choosing a platform, make sure it was created specifically for your needs. You will be able to provide greater user experience and add appropriate tools as a result of this. â¡ï¸ Watch our introduction video â¡ï¸ Create a new user account for free â¡ï¸ Check out how to add a new project With Locize, a modern and economical localization management platform, you can bridge the gap between translation and development. It makes your site, app, game, or whatever project you're working on more global, dynamic, and engaging, particularly when you use the continuous localization features. While we hope you enjoy our services, we will not lock you into a contract. We believe in the added value of our services, so you can export your translations and utilize them with i18next. If you are a developer, this could be a possibility for you, or you can look at our step by step guide for JavaScript localization Locize Frequently Asked Questions frontmatter.faq.map(( q, a ) = ( q a )) Conclusion Consumers have a clear requirement for a website that is tailored to customized and localized content. As a result, the localization of a site is the tech part for any company looking to expand into new areas or market segment. As we have built it up for you, it must comprise a good business strategy, which is the starting point for a solid technological implementation. Global brands do it As you can see from our real world examples, the most well known organizations in any industry have used website localization. As a result, you should address it as soon as possible in your company's internationalization process . It is significant due to the commitment your organization would make to potential clients in the newly targeted area. Users will appreciate it Your target audience will thank you by buying your product or service. In this market, your company's brand awareness will grow as well, which is essential for internet business success. Use this guide The \"How to Locize your website?\" is easy to answer, select the right platform for your needs and plan all steps needed for the language localization in advance. Keep it organized The localization management platform can assist you in remaining organized and adaptable during your continuous localization. Why Locize should be your choice Our team has considerable experience to assist you with your project or development needs, thanks to many customers that we assisted with the localization of their website. We've also supplied the most valuable pricing of our website localization services because of our many years of expertise with these consumers, and we don't require you to sign long term contracts."},{"slug":"translation-project-management","title":"7 steps to master translation project management (2023)","description":"A step-by-step tutorial providing advice on how to master translation project management. Further tips on being more efficient.","date":"2023-01-20","category":"Guides","thumbnail":"\/img\/blog\/translation-project-management\/translation-project-management.webp","readTime":"6 min read","searchText":"hideCta: true, title: '7 steps to master translation project management (2023)', description: 'A step by step tutorial providing advice on how to master translation project management. Further tips on being more efficient.', date: '2023 01 20', thumbnail: '\/img\/blog\/translation project management\/translation project management.webp', image: '\/img\/blog\/translation project management\/translation project management.webp', category: 'Guides', tags: ['localization', 'guides', 'project management'] Are you looking to improve the efficiency and success of your translation projects? Look no further! In this guide, we will walk
40you through 7 proven steps to master translation project management. So, let's get started and unlock the secrets to a successful language translation management. Table of contents How to plan project management for translation Streamline your translation project with a tool This guide will provide you with the project management tools and information you need to take your translation projects to the next level. This includes defining the project's scope and needs, as well as selecting the best team and tools to deliver high quality translations on time and on budget. Whether you're a seasoned pro or just starting out in the world of translation project management, these steps will help you streamline your workflow, increase collaboration, and ultimately deliver better results for your clients. How to plan project management for translation The first step in any translation project is to assess the client's needs. This includes determining the target languages, the type of content that needs to be translated, and any specific requirements or constraints that need to be taken into account. Once these details have been established, the project manager can create a project plan outlining the steps that need to be taken to complete the project on time and within budget. 1. Budget allocation for the project 2. Define the scope and requirements 3. Team and responsibilities 4. Find the translators 5. Define the project plan 6. Review the work 7. Translation delivery 1. Budget allocation for translation projects The translation project's budget should be established early in the planning phase. This will help to ensure that adequate resources are given for the project and that possible cost overruns are detected and handled before they occur. Generally, the costs of a translation process can be as follows: Cost of required tools and software (licenses) project managers' and translators' fees Continuing costs for tasks such as translation, editing, proofreading, and formatting, as well as quality assurance, testing, and localization. The cost of any required equipment, technology, additional services, and travel charges. Costs for any required software integration, third party vendor services, training, and legal and regulatory needs. 2. What is required in the project Defining the scope and requirements of a translation project is crucial for ensuring that all stakeholders have a clear understanding of the project's expectations. This includes determining: The types of content that will be translated, whether it is text from a website, a document or any other file. The target languages for the project and taking into consideration the unique characteristics of each language. The expertise of the translators needed for the project, such as subject matter experts, depending on the content's industry. 3. Define who is responsible for which tasks in the project A project team should be assembled, with clear roles and responsibilities assigned to each team member. This includes identifying a project manager or coordinator who will oversee the project, as well as translators, editors, and any other team members who will be involved in the project. 4. Find the translators One of the most important aspects of translation management is selecting the right translators for the job. The project manager will need to assess the translators' qualifications, experience, and expertise to ensure that they have the right skills to handle the content that needs to be translated. These professionals will also need to coordinate with the translators to ensure that they are aware of the project's timelines and deliverables. 5. Define the project plan Another key aspect of translation project management is managing the timeline and budget of the project. This includes setting deadlines for each stage of the project, such as translation, editing, and proofreading, and ensuring that these deadlines are met. The project manager will also need to monitor the progress of the project and take any necessary steps to keep it on track. 6. Review the work Quality assurance is also a critical part of project management in translation. The professionals will need to ensure that the final translated content meets the client's expectations and is of high quality. This may involve conducting a review of the translated content, or working with a team of editors and proofreaders to ensure that the content is error free and accurate. 7. Translation delivery The final translated content should be delivered to the client in the appropriate format and in a timely manner. Any necessary final adjustments should be made at this time, and the project should be closed out according to the project plan. Streamline your translation project with a tool For a translation project, the management can be essentially improved with following features: Translation management Allows customers to post and manage their content under a single dashboard, as well as collaborate with and assess translators' work. In context editing This feature enables users to modify translations directly within the context of their website or application, which can assist verify that translations are accurate and suitable. Machine translation This technology uses machine learning algorithms to automatically translate text, saving time and effort. Translation memory Remembers previous translations and offers them when comparable information is encountered, so ensuring consistency and reducing the need for retranslation. Versioning Allows users to keep track of changes to translations over time and, if necessary, roll back to previous versions. Analytics Provides information on how translations are used and how people interact with them, which can aid in the localization process. Locize, the management system for translations and localization, is designed to interact with a wide number of platforms and tools, including website builders, content management systems, and software development kits. Locize: What is it Locize is a cloud based translation management system that enables team
40s to cooperate on website and app localization. To help with the localization process, it includes capabilities like machine translation, translation memory, and terminology management. It also has an API and integration possibilities for a variety of development frameworks and platforms. Locize is also a localization software that provides a variety of features for managing and translating website and application content. Now we'd like to hand it on to you: Do you have a plan for your translation workflow or project? We can handle the project more efficiently if we work together. If you are already experienced with integrating our solution into your technology stack, we are now offering a 14 day free trial period. Simply join our platform below to get started! register ' ' Learn more Conclusion To summarize, translation project management is a difficult process that necessitates precise organization and attention to detail. Coordination with translators, management of timetables and budgets, and ensuring that the final result fulfills the client's expectations are all part of the job. Translation project managers may help guarantee that localization projects are finished on time and under budget, while also ensuring that the end result is of high quality by following the best practices and utilizing the appropriate tools. To increase the accuracy and efficiency of the translation process, the translation industry is facing rule based automation and artificial intelligence."},{"slug":"i18next-tips-and-tricks","title":"Unleashing the Full Potential of i18next: Tips and Tricks","description":"In this article, we explore tips and tricks on how to use i18next, a powerful JavaScript library, to handle internationalization and localization effectively by utilizing features such as namespaces, pluralization, interpolation, fallbacks, context feature and integration with Locize to deliver a better user experience.","date":"2023-01-17","category":"Guides","thumbnail":"\/img\/blog\/i18next-tips-and-tricks\/title.jpg","readTime":"4 min read","searchText":"title: 'Unleashing the Full Potential of i18next: Tips and Tricks', description: 'In this article, we explore tips and tricks on how to use i18next, a powerful JavaScript library, to handle internationalization and localization effectively by utilizing features such as namespaces, pluralization, interpolation, fallbacks, context feature and integration with Locize to deliver a better user experience.', date: '2023 01 17', thumbnail: '\/img\/blog\/i18next tips and tricks\/title.jpg', image: '\/img\/blog\/i18next tips and tricks\/title.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'i18next'] Internationalization (i18n) and localization (l10n) are important aspects of any web or mobile application. i18next is a powerful JavaScript library that makes it easy to handle i18n and l10n in your application. In this post, we'll explore some tips and tricks for using i18next to its full potential. Unlock the secrets of successful translations with i18next. Explore advanced tips and techniques to handle complex translation scenarios. From pluralization to context based translations, this guide will empower you to deliver accurate and culturally appropriate content. 1. Use the namespace feature: One of the most powerful features of i18next is the ability to use namespaces. Namespaces allow you to separate your translations into different groups, making it easier to organize and manage your translations. For example, you can create a namespace for each feature or module in your application, making it easier to update and maintain translations for that specific feature. Check out this section in the video crash course! 2. Utilize pluralization: i18next also has built in support for pluralization, making it easy to handle different plural forms of a word in different languages. To use this feature, simply specify the different plural forms of a word in your translation file and i18next will automatically use the correct form based on the current language and count. Check out this section in the video crash course! 3. Take advantage of interpolation: i18next supports interpolation, that allows you to insert dynamic values into your translations. This can be useful for displaying user specific information, such as a username or a date. To use interpolation, simply include placeholders in your translation string, and pass an object c
40ontaining the values to i18next. Check out this section in the video crash course! 4. Handle fallbacks: i18next provides several fallback options to handle missing translations. Language fallback: you can specify a fallback language in case the current language is not available. Namespace fallback: you can specify a fallback namespace in case the current namespace is not available. Key fallback: you can specify a fallback key in case the current key is not available. 5. Use a language detector: i18next browser languagedetector is a plugin that detects the user's preferred language based on their browser settings. This can be very useful for providing a better user experience by automatically displaying the website in the user's preferred language. 6. Leverage i18next backend plugins: i18next offers several backend plugins that allow you to load translations from various sources, such as a JSON file, a remote server, or a database. This can be useful for loading translations on demand or for providing an offline mode for your application. Some examples of i18next backend plugins include i18next http backend and i18next fs backend. With the help of i18next chained backend you could also combine different backends to create fallbacks or caching concepts. 7. Use the context feature: i18next provides a context feature which allows you to provide additional context information for a translation in order to disambiguate between different translations of the same key. This can be useful when a word or phrase can have multiple meanings and the context helps to disambiguate the intended meaning. For example, providing gender specific translations, like \"he\" and \"she\" for a specific phrase. 8. Use different i18n formats: i18next supports different i18n formats such as ICU message format which is widely used in Java and C++. This allows you to use the same translations across different platforms and technologies. To use different i18n formats, you can use i18next plugins such as i18next icu. 9. Integrate with Locize: Locize is a cloud based translation management system (TMS) that integrates seamlessly with i18next. By using Locize, you can easily manage your translations and collaborate with translators and editors. Locize also provides a powerful editor and a translation memory, making it easy to reuse translations and ensure consistency across your application. To integrate Locize with i18next, you can for example use the i18next locize backend plugin. This plugin allows you to load translations from the Locize CDN and automatically syncs them with your application. Here you can see what this could look like. Check out this section in the video crash course! Conclusion: In this post, we've explored some tips and tricks for using i18next to its full potential. By using namespaces, pluralization, interpolation, fallbacks, i18next browser languagedetector, leveraging i18next backend plugins and context feature, you can provide a better user experience for your users. Integrating it with Locize allows you to easily manage your translations and collaborate with translators and editors. With i18next, you have all the tools you need to make your application truly international. If you're new to i18next, you might check out the complete free i18next crash course video:"},{"slug":"next-app-dir-i18n","title":"i18n with Next.js 13\/14\/15\/16 and app directory \/ App Router (an i18next guide)","description":"Looking for a way to internationalize your Next.js 13\/14 project with the new app directory \/ App Router paradigm? Then this guide is for you!","date":"2023-01-02","category":"Tutorials","thumbnail":"\/img\/blog\/next-app-dir-i18n\/next-app-dir-i18n.jpg","readTime":"5 min read","searchText":"title: 'i18n with Next.js 13\/14\/15\/16 and app directory \/ App Router (an i18next guide)', description: \"Looking for a way to internationalize your Next.js 13\/14 project with the new app directory \/ App Router paradigm? Then this guide is for you!\", date: '2023 01 02', thumbnail: '\/img\/blog\/next app dir i18n\/next app dir i18n.jpg', image: '\/img\/blog\/next app dir i18n\/next app dir i18n.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'i18next', 'nextjs'] â ï¸ Updated note (March 2026): Two things changed since this guide was written. The synchronous destructuring pattern used here breaks in Next.js 15+ (params is now a Promise). And next i18next v16 now ships first class App Router support ( for Server Components, for Client Components, built in locale routing), so the underlined statement below that you \"don't need next i18next anymore\" is historical. The manual approach in this guide still works if you prefer zero extra dependencies. At Next.js Conf, the Vercel team announced Next.js 13 which introduced the new app directory \/ App Router paradigm. This article is also valid for newer Next.js versions like Next.js 14. It includes support for Layouts, Server Components, Streaming and Support for Data Fetching. Awesome! Next.js 13 has been released! It seems pretty fast and it lays the foundations to be dynamic without limits. Afterthoughts... This sounds good, but looking more into the app directory \/ App Router paradigm, it looks like this is a completely new Next.js setup... not really comparable to the old one... What does this mean regarding i18n? Lo
40oking at the docs it seems our old approaches will not work anymore. Nice features provided by next i18next (and other Next.js related i18n modules) , like described here and here were not suited to this new app directory setup back then. So you didn't need next i18next anymore! Update (March 2026): this is no longer true. next i18next v16 supports the App Router first class. A new approach In this section, you'll see how we can internationalize the new app directory with the use of i18next, react i18next and i18next resources to backend. 1. Folder structure 2. Language detection 3. i18n instrumentation 4. Language switcher 5. Client side 6. Bonus 1. Folder structure Let's start by creating a new folder structure that uses the language as url parameter. A so called dynamic segment: The file could look like this: And the file could look like this: Last the file could look like this: 2. Language detection Now navigating to or should show something, and also the links to the second page and back should work, but navigating to will return a 404 error. To fix that we'll create a Next.js middleware and refactor a bit of code: Let's first create a new file : Then adapt the file: And finally create a file: Navigating to the root path will now check if there's already a cookie with the last chosen language, as fallback it will check the header and the last fallback is the defined fallback language. The detected language will be used to redirect to the appropriate page. 3. i18n instrumentation Let's prepare i18next in the file: We're not using the i18next singleton here but creating a new instance on each call, because during compilation everything seems to be executed in parallel. Having a separate instance will keep the translations consistent. In the file we'll add the i18next options: Let's prepare some translation files: : : : : Now we're ready to use that in our pages... Server pages can by this way we can await the response. : : 4. Language switcher Now let's define a language switcher in a Footer component: : You see we can also use the react i18next Trans component. A new namespace: : : And add that Footer component to the pages: : : 𥳠Awesome, you've just created your first language switcher! 5. Client side So far we've created server side pages only. So what do client side pages look like? Since client side react components can't we need to do some adjustments. Let's introduce the file: On client side the normal i18next singleton is ok. It will be initialized just once. And we can make use of the \"normal\" useTranslation hook. We just wrap it to have the possibility to pass in the language. To align with the server side language detection we make use of i18next browser languagedetector and configure it accordingly. We also need to create 2 versions of the Footer component. : The server side part continuous to use the version, : The client side part will use the new version, : A client side page could look like this : With some translation resources: : : And a link in our initial page : ...with translation resources: : : ð𥳠Congratulations ðð The result should look like this: ð§âð» The complete code of an example app can be found here. And a TypeScript version here. 6. Bonus transform the localization process Connect to an awesome translation management system and manage your translations outside of your co
40de. Let's synchronize the translation files with Locize. This can be done on demand or on the CI Server or before deploying the app. What to do to reach this step: 1. in Locize: signup at locize.app\/register and login 2. in Locize: create a new project 3. install the locize cli ( ) 4. in Locize: add all your additional languages (this can also be done via API or with using the migrate command of the locize cli) Use the locize cli Use the command to always download the published Locize translations to your local repository ( ) before bundling your app. example Alternatively, you can also use the command to synchronize your local repository ( ) with what is published on Locize. example ð𥳠Congratulations ðð I hope youâve learned a few new things about i18n in the new app directory setup, Next.js, i18next, react i18next, react i18next, i18next resources to backend and modern localization workflows. So if you want to take your i18n topic to the next level, it's worth trying the localization management platform Locize. The founders of Locize are also the creators of i18next. So by using Locize you directly support the future of i18next. ð"},{"slug":"networkme-locize","title":"Localization at Networkme (by Marcelo Manteigas)","description":"This is a guest blog post written by Marcelo Manteigas describing the experience with Locize.","date":"2022-12-29","category":"Company","thumbnail":"\/img\/blog\/networkme-locize\/title.jpg","readTime":"3 min read","searchText":"title: 'Localization at Networkme (by Marcelo Manteigas)', description: 'This is a guest blog post written by Marcelo Manteigas describing the experience with Locize.', date: '2022 12 29', thumbnail: '\/img\/blog\/networkme locize\/title.jpg', image: '\/img\/blog\/networkme locize\/title.jpg', category: 'Company', tags: ['localization', 'company'] Networkme is a career discovery and development platform that helps students find the best job for them to start their careers. We are often recognized as the âLinkedin for studentsâ because we provide an ecosystem for companies to interact directly with their future talent through a platform that is better suited for this particular use case. The Problem From the get go we implemented our platform in 3 languages, Portuguese, English and Spanish to cover all the Iberian market and hopefully to capture some international user and companies looking to hire\/work in this region. Our initial approach was to have a local JSON file inside the application to manage the different copies in the platform. However, as we grew in size and to currently 6 different web applications, it became almost impossible to manage everything effectively. In fact, at some point any request to change copy in any of the platform was taking 2 days to fulfill and changes would only reflect in the production environment according to the deploy schedule which could take a week. This obviously generated a lot of frustration for both the technical team because they were spending a lot of time fulfilling these requests instead of progressing in the roadmap, and the business team felt like we were not moving at the speed they needed. We found Locize as a solution to give autonomy to business teams to make changes in the application copy and relive the technical team from this burden. Also, by using the Locize features to better encapsulate the different projects we were able to implement governance features and drastically reduce the complexity to manage application with more than 10 thousand words. Favorite Features The best thing about using Locize that really changed our game was the ability to have an in context editor that allows non technical collaborator to easily interface with our application copy creating an abstraction between the technical implementation in a JSON format. That is very powerful to help them navigate with agility and drastically reduced the risk of breaking anything in the application since they were changing directly in the application. The ability to create different projects and having RBAS implemented was especially important to implement the necessary governance to avoid conflicting work or worst having users accidently committing mistakes Final Thoughts Locize really changed positively our dynamic inside Networkme between business and technical teams by reducing the amount of time managing copy in the web applications and empowering the copywriters with the autonomy to move at the speed they expect. The development team became at least 20% more productive , since the only thing they needed to do was to create the keys through the development process and all the copy management afterwards was outside the set of their responsibilities. If you're new to Locize, watch the demo video to learn more about it:"},{"slug":"multi-tenant","title":"Multi tenant architecture","description":"What is Multi-Tenant Architecture? And how we increase the value of the client by improving our software with it.","date":"2022-12-10","category":"Engineering","thumbnail":"\/img\/blog\/multi-tenant\/multi-tenant-application.webp","readTime":"5 min read","searchText":"hideCta: true, title: 'Multi tenant architecture', description: 'What is Multi Tenant Architecture? And how we increase the value of the client by improving our software with it.', date: '2022 12 10', thumbnail: '\/img\/blog\/multi tenant\/multi tenant application.webp', image: '\/img\/blog\/multi tenant\/multi tenant application.webp', category: 'Engineering', tags: ['localization', 'engineering', 'multi tenancy', 'saas', 'architecture'] You're going to learn about a subject today that is more popular than ever. We now offer our consumers this unique functionality. Without the client having to pay more, this will contribute to raising the value of our localization software. Let's start by reviewing basic definitional information concerning multi tenant as well as the benefits of such an architecture. Definition: Multi tenant A software that is multi tenant may serve several customers with a single application instance. A single instance of a software program (and its underlying database and technology) supports several tenants in multi tenant software architecture, also known as software multi tenancy (or user accounts). Each tenant can customize the program by changing some basic parameters. This might involve the look and feel of the user interface, user administration, or adding custom code to the program. In this situation, instead of a dedicated server, the space for each tenant or client is shared. The multi tenant nature of SaaS systems necessitates a greater emphasis on ensuring that all efforts are taken to isolate tenant resources. There are three main types of multi tenant architecture: 1) Shared database A multi tenancy architecture with a multi tenant database is a single, shared database structure. Because shared resources are used, this is the simplest of the three kinds and has a relatively low cost to tenants. To host tenants and store data, this design employs a single application and database instance. Using a single, common database schema provides for faster scaling, but can result in greater total running expenses. 2) Single database with several schemas A single database with several schemas is another approach to multi tenancy. This approach has a single application instance and separate databases for each tenant. Because of this design, each individual database incurs more expenses and requires more administrative effort. It is useful when data from various clients must be processed differently, such as when they are located in different c
40ountries with different legislation. 3) Several databases Data is stored in numerous databases in the third type of multi tenant architecture. This approach is very difficult in terms of administration and maintenance, however renters may be distinguished from one another using a predefined criterion. source: diegosucaria.info The advantages of multi tenant applications The huge advantage for shared resources is that it will make the entry cost very low and the scalability easier and faster. These are the main other advantages of multi tenant architecture: Lower costs: When compare to other hosting architectures, itâs costs less than a single infrastructure is used for multiple tenants No maintenance at all: Always up to date code as the host is taking care of maintenance. New features are implemented without the customer's involvement and just once. Highly scalable: The architecture is easily scalable on demand, new users access to the same instance Easy customization: Itâs highly flexible, allowing each tenant client to modify the application to their individual business needs without incurring the expense, time, and risk of having an own development. High productivity: There is an improvement in productivity for the tenant because there is no need to manage the infrastructure. Multi tenant vs. single tenant The main difference is the access to source code. In single tenant architectures, a tenant will have a singular instance of an application dedicated to them. The key distinction is the availability of source code. A tenant in a single tenant architecture will have a single instance of an application devoted to them. Example Assume that each client has a separate residence that is completely cut off from any nearby structures. In a multi tenant cloud architecture, tenants reside in several apartments inside the same structure. The same security system and communal utilities link them all. However, each tenant's privacy is protected within their apartment since they each have a key. But it's more probable that their neighbors' behavior will affect how comfortable they are in the flat. How Locize introduce multi tenant in translation management For Locize the multi tenant approach is less of the classical infrastrucutre topic, but it still makes perfect sense for the translation management system since it functions as a fully independent application\/project that is integrated into your own application or website. This means that our customers (you) can in turn integrate the own customers or other projects into the account without opening another account. Uniqueness The concept of multi tenancy is absolutely new and exclusive to the localization industry. Use the most up to date software for this purpose, Locize With the multi tentant function to happen: With limited access, you can assign your own clients a dedicated project without spending money on new infrastructure. Advanced user management enhances workflow flexibility in general. The localization software will increase in scale from its current level. Testimonials Check out our customer success stories for more examples of who is using our service. â¡ï¸ Read more: Here you will find the instructions how to add a multi tenant project for Locize. locize multi tenant Your primary project's material serves as the foundation for the projects developed under \"Tenants.\" The tenant project has a complete list of all current and upcoming translations. Now, tenants have the option of maintaining translations exactly as you gave them or changing values as necessary. You can choose to pay such expenses by letting the consumer pay with his own credit card or by subscribing to those tenant projects using your main subscription. Additional links â¡ï¸ Create a free new user account for multi tenant experience â¡ï¸ Find out more about what a translation management system is â¡ï¸ Find out more about localization"},{"slug":"hidden-localization-costs","title":"The hidden localization costs","de
40scription":"There are a lot of hidden costs when you're investigating your software localization process.","date":"2022-12-02","category":"Guides","thumbnail":"\/img\/blog\/hidden-localization-costs\/title.jpg","readTime":"2 min read","searchText":"title: 'The hidden localization costs', description: \"There are a lot of hidden costs when you're investigating your software localization process.\", date: '2022 12 02', thumbnail: '\/img\/blog\/hidden localization costs\/title.jpg', image: '\/img\/blog\/hidden localization costs\/title.jpg', category: 'Guides', tags: ['localization', 'guides'] Big companies that reach hundreds of countries can spend millions on translation costs alone and still not reach all their audience. There are revealing facts about the business growth for high quality localized content to engage new audiences, grow brand recognition and loyalty and boost revenue. Localized content is important to enhance top of funnel efforts. Everyone can estimate the cost of content localization by obtaining bids from language service providers. But companies often forget the actual translation work cost is just a minimal part of the complete localization costs. What many may not consider when calculating the budget are the hidden costs of localization, for example: extract source files from your software project copy pasting, exporting, importing, etc... from your resource files to various file formats for translation and back again order translations, sending emails to translators to check how much they have translated, proofreading... converting files to different formats, getting charged by translation agencies for converting your files to formats used by the translators import\/sync translated resources back to your software project, resolve conflicts because in the meantime new features or software changes have been made, etc... release new version of software because of translation issue, new roundtrip for a better alignement, a dedicated resource for technical writer\/translator\/coordinator development team \\ translation team alignments managing the localization process with tools and workflows that haven't changed for a lot of years delayed rollout because of delayed translations, alternatively lock down content changes 2 to 3 months ahead of the launch date to carry out localization ... In terms of your investment, the above hidden costs tend to be higher than the actual cost of translation. How to get rid of these hidden costs? â¡ï¸ Good processes and modern tools that are focused on you with your development team and not only the translation service provider. By improving workflow processes and using a modern translation management system like Locize, the content is translated faster and your software is released more efficiently. Moreover, you will reach your target audiences faster, trying to get ahead of your competition."},{"slug":"immersive-locize","title":"Localization at Immersive Communities (by Mario Stopfer)","description":"This is a guest blog post written by Mario Stopfer describing the experience with Locize.","date":"2022-11-08","category":"Company","thumbnail":"\/img\/blog\/immersive-locize\/title.jpg","readTime":"3 min read","searchText":"title: 'Localization at Immersive Communities (by Mario Stopfer)', description: 'This is a guest blog post written by Mario Stopfer describing the experience with Locize.', date: '2022 11 08', thumbnail: '\/img\/blog\/immersive locize\/title.jpg', image: '\/img\/blog\/immersive locize\/title.jpg', category: 'Company', tags: ['localization', 'company'] Immersive Communities is a social media platform for content creators. It allows users to create their community and have mambers write articles on any topic they care about. As a solo developer, I've worked for just over 4 years to deliver the platform to a global audience. Since my goal was to have a global reach from day one, it goes without saying that localization was something I took seriously. I've decided to have the platform fully localized in 10 languages at launch. This, would certainly take a lot of time and effor, so I started looking for possible SaaS solutions to his problem. My first search result was Locize and it looked promising so I gave it a go. Needless to say, I wasn't disappoined and I neded up using Locize to fully localize my platform. Favorite Features The best thing about Locize that I found useful was the ability to create multiple projects. Inside each project you can have multiple documents (namespaces), which came useful to me, since I would have at least 2 different website types. One would be the main website and the other, the other would represent all the other community websites where users can write articles on. Now I had the ability to load only the namespaces and translations I wanted, based on which website layout I was loading. The other invaluable feature was the ability to automatically translate all your phrases using Google Translate, but Locize took it one step further by being compliant with i18next standards and also adding appropriate singular and plural translations. This would not be possible for me to do by myself since I would have to have inshight into the grammar rules of each language I wanted localized. Corner Cases handled with Ease Aside from plurals, I also had to handle time and counts of items. Luckily, using interpolation, Locize understood my request and properly formatted the time which I used to show how long ago each article was written. Also, the count of items, for example comments each article gets, was formatted properly. But this was not the biggest hurdle I had to jump over. My real challenge was to localize my Landing Page. The challenge came in the form of not only translating the text, but also adding the appropriate styling. Since different languages have different grammar rules, I couldn't just reuse a word which I translated previously, style it and add it to the phrase list. This means that I had to use regular white font with my titles, but also had to apply a CSS color gradient on some words, to indicate important part of each title. I had to add styling for each title at a different place and then have them translated and displayed to the user. The best part is that this was not just any text, but actually Markdown , which was then passed through a Markdown processor, which actually then generated styled HTML . The end result is that titles on the landing page have multiple styles applied to them. Final Thoughts I found Locize to be invaluable to my localization effort. I will continue using it for other projects and the ability to pause your project and pay less for your monthly subscription when you're not using it is an added bonus! In this article you can read a lot more about how I built this social network in 4 years as a solo developer. If you're new to Locize, watch the demo video to learn more about it:"},{"slug":"help-tech-leads","title":"Smart help for tech leaders and engineering managers","description":"This article will help the work of tech\/team leaders and engineering managers with a smart advice for the localization to
40pic.","date":"2022-09-06","category":"Guides","thumbnail":"\/img\/blog\/help-tech-leads\/title.jpg","readTime":"5 min read","searchText":"title: 'Smart help for tech leaders and engineering managers', description: 'This article will help the work of tech\/team leaders and engineering managers with a smart advice for the localization topic.', date: '2022 09 06', thumbnail: '\/img\/blog\/help tech leads\/title.jpg', image: '\/img\/blog\/help tech leads\/title.jpg', category: 'Guides', tags: ['localization', 'guides'] Tech leaders and engineering managers have probably one of the most schizophrenic and ambitious role. If you are in such a position, you may know why... Let's start by telling what some tasks and responsibilities this roles entail. What is a tech team leader \/ engineering manager doing? If there was just one word to describe it, I would call them \"foreman\" . Because they basically set the direction for the team and making sure everyone understands and follows major technical and non technical decisions. This may sound simple, but it isn't. On your engineering team you need to establish psychological safety, with mentoring your team members by inspiring and guiding them. You need to take ownership of your decisions. The motivation of the team members needs always to be fed also by providing an environment that encourages (personal) development. This may basically create a strong team culture. Manage and resolve difficult conversations with the team members, by setting clear goals and expectations. This will give your team more clarity. Also hiring the right talent is crucial. And since remote working \/ home office is becoming more and more common, you also need to handle knowledge transfer and promote efficient coding with distributed workforces. One of the imortant virtues is your and your team's adaptability. Balancing speed and quality and maintaining productivity and velocity. At the same time improving the team performance by defining it and aligning it to the business. Oh yes, the business... Such a person needs to become an expert not only in communicating with its technical team, but also with the nontechnical business stakeholders. For sure resolving customer issues is also important. The delicate balancing what engineers like to do versus what needs to be done. Somehow manage the too often existing mentality that one group works on \"the business\" and the other works on the \"code\" or the \"release\", by trying to \"connect\" the work that the engineers do to the business. How may a tech team leader \/ engineering manager feel? Often feeling disconnected from the actual coding work. They no longer have peers who can trade notes with, problem solve, and empathize with... feeling alone. In the eyes of your team theyâre \"the business\" and in the eyes of the executives \"those coders\". Directly in the middle of the tension between the business sides and the technical side of the company. Some situations Your team is insisting that something needs to be refactored first â long overdue tech debt that is piling up and your superior is on you to ship something by an unreasonable date. The financial department is saying the headcount is limited, and promoting your overperforming engineer is no longer possible, because not in the budget anymore. The head of business management obligates you to finish a feature that just doesnât work. The sales manager is indirectly expressing negative feelings by questioning why your team is working on a specific feature and not what they heard about from sales news. The program manager is asking you for a list of every engineer working on a specific project. The localization manager is telling you, your team should have submitted the source language texts 3 month ago. And you try to explain that 3 month ago, the complete feature was not required and not specified at all. And your team is soberingly trying to convince you that they can't do a feature freeze since they're developing with the agile methodology. So you're trying to manage also the tension between the development team and translation team. ... Do you start to recognize what I mean? And to put the cherry on top, you can't go to the head of sales to say the program manager is on your case and that your team is refusing to develop a feature. You can't tell the customer, the next release will c
40ome with unverified texts and no translations, because the localization team and product development team work with different process methodologies. Tech team leaders \/ engineering managers are alone! Is there something that we could do to help? While this may seem a bit of a caricature of the challenges of the competitive engineering lead roles, I'm sure that certain situations are familiar to you in one form or another. Of course, I don't have an all encompassing solution to improve this, but I do have a specific suggestion for resolving a particular center of tension. Imagine this: 1. The developers work as usual on their features and create strings on the fly. Those new texts get's automatically pushed as missing strings to the translation management system (TMS). 2. The translators work on new translations and can instantaneously validate the translations. 3. Since translations are \"connected\" directly to your software product, they can be released at any time. This way you can also fix translations of your previously released product, without having to redeploy it. If you do so, you have to make sure you can have more than one version of your translations; at least one for the current released version and one for the current development branch. That way your technical writers and translators can take care of the translations from the first day and keep up with changes with ease. By doing this, it is even possible to change or add translations without shipping a new release of your software! You may also want to have some reviewing workflow, a history, integrated ordering of external translations, context information, etc... Cool this will for sure calm down some tensions, but isn't this a little over the top... an extra tooling and deployment, does not all this just add more complexity and effort? You donât have to build this yourself!!! There is Locize! Locize removes the pain in the translation process. No more delays in shipping your software because of missing translations. Translators can keep up with changes from day one. The continuous localization process keeps up with your demanding business. By using Locize, tech team leader \/ engineering manager enables collaboration to bridge the gap between localization and development. This makes you faster, more efficient and saves you money overall. Just start with the free trial. There's no harm... Try everything, set up your Locize project, compare it with your existing process and validate it with your team members. Watch the demo video to learn more about it: btw: If you're already using the open source internationalization (i18n) framework i18next, then you are already using Locize's best partner. Because Locize was created by the maintainers of i18next. Integrating i18next with Locize is even easier."},{"slug":"language-localization","title":"Language Localization: What It Is, Examples & Best Practices","description":"Language localization is the process of adapting a product, service, or content for the language and cultural expectations of a specific market. This guide explains what it is, why it matters, examples (spelling, cultural references, visuals, grammar, tone), and how it differs from translation.","date":"2022-08-24","category":"Guides","thumbnail":"\/img\/blog\/language-localization\/language-localization.webp","readTime":"6 min read","searchText":"title: 'Language Localization: What It Is, Examples & Best Practices', description: 'Language localization is the process of adapting a product, service, or content for the language and cultural expectations of a specific market. This guide explains what it is, why it matters, examples (spelling, cultural references, visuals, grammar, tone), and how it differs from translation.', date: '2022 08 24', thumbnail: '\/img\/blog\/language localization\/language localization.webp', image: '\/img\/blog\/language localization\/language localization.webp', category: 'Guides', tags: ['localization', 'guides'], faq: [ q: 'What is language localization?', a: 'Language localization is the process of adapting a product, service, or content for the language and cultural expectations of a specific market. It goes beyond translation: it adapts spelling (British vs American English), cultural references and idioms, visuals and colors, grammar, tone of voice, and reading direction (LTR vs RTL) so that the content feels native to the target audience rather than translated into it.' , q: 'What is the difference between language localization and translation?', a: 'Translation converts text from one language to another: the meaning is carried over, but cultural context, idioms, and conventions may not be. Language localization adapts the entire experience: spelling differences (en US vs en GB), local idioms (\"put the cart before the horse\" vs the French equivalent using a bull), visuals, colors, grammar nuances, and tone. Translation is one part of localization; localization is what makes content feel native.' , q: 'Why is language localization important?', a: 'Customers engage more with brands that speak their language and reflect their culture. Localized content increases conversion, builds trust, and reduces support load. CSA Research found that 40% of consumers will not buy from a website not in their native language and 7
405% are more likely to repurchase if support is in their language. For any business operating across borders, language localization is the difference between being usable and being preferred.' , q: 'What languages should I prioritize for localization?', a: 'Just over half of the world\\'s population speaks one of about 23 languages. The most widely spoken include English ( 16.5%), Mandarin Chinese ( 12.3%), Hindi ( 8.3%), Spanish ( 7%), and French ( 3.6%). The right priority for your business depends on where your existing customers are, where your target market is, and which languages your competitors have already localized for. You do not need to localize into all 7,150 living languages: you need the ones that match your target geographies.' , q: 'What does language localization cover?', a: 'The most important elements: spelling and dialect differences (en US \/ en GB \/ es ES \/ es MX), cultural references and idioms, visual layout and reading direction (LTR \/ RTL), color symbolism, grammar rules (gender, plurals, declensions), date and number formats, currency, units of measurement, and tone of voice (formal \/ informal, regional register). For software and websites, also: payment methods, address formats, phone number formats, and regional legal compliance.' , q: 'How do I do language localization in practice?', a: 'A typical workflow: (1) define target markets and languages, (2) prepare your content or codebase by separating text from logic (internationalization \/ i18n), (3) translate using a translation management system with translation memory and glossary, (4) adapt visuals, colors, and cultural references per market, (5) review with native speakers, (6) test in every locale, (7) monitor and update: language and culture change, so localization is continuous, not one off.' , q: 'Do I need a professional localizer or is machine translation enough?', a: 'Machine translation (DeepL, Google Translate, modern AI) handles general comprehension and first drafts well but typically falls short on idiomatic phrases, cultural references, marketing tone, and brand voice. The current best practice is hybrid: AI for speed and scale, professional localizers (or at minimum native speaker reviewers) for nuance and brand fit. Use AI for the first 80%, humans for the final 20% that determines whether content feels native or merely translated.' ] Language localization is the process of adapting a product, service, or content for the language and cultural expectations of a specific market. It is broader than translation: localization adapts spelling differences (British vs American English), cultural references and idioms, visuals and colors, grammar nuances, tone of voice, and reading direction (LTR vs RTL), so the result feels native to its target audience rather than translated into it. For any business operating globally, language localization is what turns a foreign feeling site into one that reads like it was written for the local market, and it materially affects conversion, trust, and customer experience across every region you serve. Key facts What it is: adapting language + cultural context for a specific market vs translation: translation = words; localization = whole experience including idioms, tone, visuals, grammar What it covers: spelling, dialect, idioms, visuals, colors, grammar, tone, RTL layout, formats Most spoken languages: English (16.5%), Mandarin (12.3%), Hindi (8.3%), Spanish (7%), French (3.6%) Conversion impact: 40% of consumers don\\'t buy from non native language sites ( CSA Research ) Modern best practice: hybrid: AI \/ MT for first draft, native speakers for nuance and review We live in a truly connected world. Technology is allowing organizations to work and operate with businesses and consumers across the globe with ease. However, while this ability to engage with an audience anywhere is allowing companies to expand and grow, it is also placing significant importance on language and effective communication. Language localization is an essential requirement for any business operating globally, helping them to connect and build stronger relationships with their clients. The rest of this guide explains what it is in detail, why it matters, the most common examples, and how it differs from translation. What is language localization? Many people believe that language localization and translation are interchangeable terms; however, they are two very different things. Localization is the strategy of adapting your brandâs services or products so that they are targeting the audience in a specific geographical region or international market. For example, while English might be spoken by one in four people across the globe, there are very distinctive differences between British and American English. Understanding these nuances is essential in building a strong relationship with your customers. Equally, perhaps y
40ou are looking to transfer your Spanish language video game to a wider audience in another language. While translating the voiceovers is essential, there are also various cultural references and idioms that will need to be adapted. Why is language localization important? For any business or organization looking to work globally, language localization is essential in helping them to break into new markets. In the highly competitive world that we live in, it is vital that you are able to effectively communicate with your target audience in terms of language and cultural norms. Language localization will help to ensure that your brand feels completely natural to your audience. When consumers feel like they are working with a brand that understands them and is talking to them directly, they are far more likely to engage with them and utilize their services. In turn, this will help you to increase your reach and boost your sales. Of course, it is not only about increasing your reach. When customers are able to identify with your brand more closely, then you are more likely to generate much greater goodwill. It also helps you to create a stronger customer experience, ensuring you are reaching all of the required touchpoints that leave them feeling confident in your brand. What languages are most popular for localization? Thankfully, when it comes to language localization, you do not need to translate your content into all 7,150 languages currently in use worldwide. Instead, you just need to ensure that you are transposing your website, brochures, and content into the language of your target destination. Over half of the worldâs population currently speaks one of 23 languages, and some of the most popular and widely used of these include: English (spoken by 16.5% of the world) Mandarin Chinese (12.3% of the world) Hindi (8.3% of the world) Spanish (7% of the world) French (3.6% of the world) languages Examples of language localization Language localization is an all encompassing term, and businesses will need to review everything from their website and marketing materials to contracts and manuals. There are a lot of things to consider when conducting localization, but some of the most important include: Spelling Spelling is one of the most important factors when it comes to localization, particularly when translating between British and American English. For example, the former uses âiseâ whereas the latter uses âizeâ. Cultural references Cultural nuances and phrases are another important consideration. For example, in English, the phrase âput the cart before the horseâ is a common quote; however, in France, they use the term Bulls instead of a horse. Visuals and colors Localization is much more than just the text. You will also need to ensure that your text is visually laid out correctly for your target audience (do they read left to right or right to left?), and you will also need to ensure you are using the right colors and themes that they will relate to. Grammar High quality language localization should also factor in the grammatical rules of your chosen language. One small mistake in your written text can be the difference between your project being a success or a failure, so comprehensive proofreading is essential. Tone Another major factor to consider when undertaking language localization is the tone of the content. Different cultures and countries will have different expectations of the tone your documents should come in. That is why you need to ensure that you are using the correct dialect and nuances of your target audience. Translation vs. language localization While translation and localization follow similar practices, there are distinct differences between the two. Translation involves simply transposing content from its original language into your chosen language. While this can be effective in helping readers understand the original context of the document or file, certain phrases and terms will not translate with the same meaning. For quick communication, this might not be such a problem. However, for professional documents such as contracts, manuals, research papers, and more, this could result in a major miscommunication. Localization, on the other hand, covers everything from meaning and grammar to the cultural, ethical, and societal guidelines of the destination language. This ensures that readers are able to get the exact same meaning from the content, no matter the language that they are reading it in. This often requires the work of a specialist who will be able to tailor and adjust the wording and structure accordingly so that it meets the expectations of the local audience. Frequently Asked Questions frontmatter.faq.map(( q, a ) = ( q a )) Conclusion For any business looking to branch out into new countries or markets, then language localization is an essential requirement. In order to stand out above your competitors and showcase everything that makes your brand special to consumers, you need to ensure that you are communicating with them in their own language. This goes much further than simply translating your existing content into the new destination language and requires a comprehensive understanding of the minor nuances of your new market. This is where it is essential that you are working with a professional localization software that will not only be able to accurately transform your content but also stay up to date with the latest cultural trends to ensure you are always engaging with your audience correctly. In our ecosystem you will find all the services needed to accurately translate your website, documents, and content into the correct language, as well as ensure that the structure, flow, and meaning remain the same. So if you are planning on growing your business, speak to us today. Making a comprehensive localization strategy for your business, along with a step by step plan and KPIs to achieve, can be helpful for you. Start right now with our guide on localization strategy, we help you to start your way in localize your business."},{"slug":"gatsby-i18n","title":"Best internationalization for Gatsby (an i18next based guide)","description":"Gatsby Localization made easy with this â
step-by-step guide using i18next.","date":"2022-08-09","category":"Tutorials","thumbnail":"\/img\/blog\/gatsby-i18n\/gatsby-i18next.jpg","readTime":"8 min read","searchText":"title: 'Best internationalization for Gatsby (an i18next based guide)', description: 'Gatsby Localization made easy with this â
step by step guide using i18next.', date: '2022 08 09', thumbnail: '\/img\/blog\/gatsby i18n\/gatsby i18next.jpg', image: '\/img\/blog\/gatsby i18n\/gatsby i18next.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'i18next', 'gatsby'] You know Gatsby, right? If not, stop reading this article and make something else. Yes, Gatsby an open source framework that combines functionality from React, GraphQL and Webpack into a single tool for building static websites and apps. But what does internationalization (i18n) look like in Gatsby? There are some plugins\/libraries that may help instrumenting the Gatsby code for internationalization. In this article we will use a plugin based on the famous i18n framework i18next, respectively its great extension for React.js react i18next. The Gatsby plugin we're using is gatsby plugin react i18next created by Dmitriy Nevzorov. TOC So first of all: \"Why i18next?\" Let's get into it... Prerequisites Getting started Language Switcher Internationalized links Interpolation and Pluralization Formatting Context Key extraction For sure! How does this look like? ð but there's more... (InContext Editor) ð𥳠Congratulations ðð So first of all: \"Why i18next?\" When it comes to React localization, one of the most popular i18n framework is i18next with its react extension react i18next, and for good reasons: i18next was created in late 2011. It's older than most of the libraries you will use nowadays, including your main frontend technology (React, Angular, Vue, ...). â¡ï¸ sustainable Based on how long i18next already is available open source, there is no real i18n case that c
40ould not be solved with i18next. â¡ï¸ mature i18next can be used in any javascript (and a few non javascript .net, elm, iOS, android, ruby, ...) environment, with any UI framework, with any i18n format, ... the possibilities are endless. â¡ï¸ extensible There is a plenty of features and possibilities you'll get with i18next compared to other regular i18n frameworks. â¡ï¸ rich Here you can find more information about why i18next is special and how it works. Let's get into it... Prerequisites Make sure you have Node.js and npm installed. It's best, if you have some experience with simple HTML, JavaScript, React.js and basic Gatsby, before jumping to gatsby plugin react i18next. This Gatsby localization example is not intended to be a Gatsby or React beginner tutorial. Getting started Take your own Gatsby project or create a new one, i.e. with the gatsby cli. We will create a language switcher to make the content change between different languages. Let's install some i18next dependencies: gatsby plugin react i18next i18next react i18next Create a directory and add a subfolder for your default\/reference language (i.e. for English). There we will then add our namespace files, like: Let's add a file: Import the file in the file and configure some plugins: Now let's start to instrument our first internationalized text. Since gatsby plugin react i18next is exporting all methods and components of react i18next, we can do this: In a page file: Now also define an namespace file, like this: And maybe also another one for German? : Language Switcher To be able to switch between different languages, we need a language switcher: You should now see something like this: gatsby language switcher By default, on the first load, gatsby plugin react i18next will fallback to the if the browser's detected language is not included in the array of . If you want to fallback to a different language in the array, you can set the option. Now switching to (German) should also work: gatsby language switcher 𥳠Awesome, you've just created your first language switcher! Internationalized links Let's create a second page... A new namespace: ...and link to that page from the first one: A new translation key for : : The component exported from automatically links to the correct language. The component is identical to Gatsby Link component except that you can provide an additional language prop to create a link to a page with a different language. Interpolation and Pluralization i18next goes beyond just providing the standard i18n features. But for sure it's able to handle plurals and interpolation. Let's count each time a button gets clicked: ...and extending the translation resources: Based on the count value i18next will choose the correct plural form. i18next provides also the ability to have a special translation for , so that a more natural language can be used. If the is , and a entry is present, then it will be used instead of the regular language plural suffix ( ). Read more about pluralization and interpolation in the official i18next documentation. gatsby pluralization ð¡ i18next is also able to handle languages with multiple plural forms, like arabic: Why are my plural keys not working? Are you seeing this warning in the development console ( )? i18next::pluralResolver: Your environment seems not to be Intl API compatible, use an Intl.PluralRules polyfill. Will fallback to the compatibilityJSON v3 format handling. With v21 i18next streamlined the suffix with the one used in the Intl API. In environments where the Intl.PluralRules API is not available (like older Android devices), you may need to polyfill the Intl.PluralRules API. In case it is not available it will fall back to the i18next JSON format v3 plural handling. And if your json is already using the new suffixes, your plural keys will probably not be shown. tldr; Formatting Now, letâs check out how we can use different date formats with the help of i18next and Luxon to handle date and time. We like to have a footer displaying the current date: Import luxon and define a format function, like documented in the documentation and add the new translation key: ð Cool, now we have a language specific date formatting! English: gatsby english German: gatsby german Context What about a specific greeting message based on the current daytime? i.e. morning, evening, etc. This is possible thanks to the context feature of i18next. Let's create a function and use the result as context information for our footer translation: And add some context specific translations keys: ð Yeah, It works! gatsby translations Key extraction Thanks to the babel plugin i18next extract you can automatically extract translations inside the function and component from your pages and save them in the namespace files. It works like this: First, install the required dependencies: Create or update the file (do NOT name it , or it will be used by gatsby): Add a script to your : If you want to extract translations per page for a specific namespace, you can add a special comment at the beginning of the page: fyi: There are also other comment hints you can use. Prepared all your pages? Nice, so let's try that: Running will now add that new key to the namespace file: Extra power This is all already great, but we can do even more! It would be nice, to have an overview showing which translations are missing and which files are completely translated... And think about when having extracted new keys, they would automatically be translated? To make this true we need a translation management... By sending the translations to some translators or translator agency you have more control and a direct contact with them. But this also means more work for you. This is the traditional way. But be aware, sending files around creates always an overhead. Does a better option exist? For sure! i18next helps to get the application translated, and this is great but there is more to it. How do you integrate any translation services \/ agency? How do you keep track of new or removed content? How do you handle proper versioning? and a lot more... Looking for something like thisâ Easy to integrate Continuous deployment? Continuous localization! Manage the translation files with ease Order professional translations Analytics & Statistics Versioning of your translations Automatic and On Demand Machine Translation Riskfree: Take your data with you Trans
40parent and fair pricing and a lot more... transform the localization process How does this look like? First you need to signup at Locize and login. Then create a new project in Locize and add all required languages. And finally you can add your translations either by using the cli or by importing the individual json files or via API. Now let's install the locize cli: We'll prepare a new script that will synchronize our local changes with Locize. And also an optional second script that will just download the newest translations from Locize. Make sure you use your project id and api key: Use the script to synchronize your local repository with what is published on Locize. Alternatively, you can also use the script to always download the published Locize translations to your local repository before bundling your app. If we now add a new translation key, like this: and run and then , we get this: : : new key Thanks to the automatic machine translation workflow (enabled by default for new projects), new keys not only gets added to Locize, while developing the app, but are also automatically translated into the target languages using machine translation. gatsby translations ð but there's more... (InContext Editor) With the help of the Locize plugin, you'll be able to use your app within the Locize InContext Editor. Want to see what this look like? Ok, first install the Locize dependency: Then in the code (we choose our file) add this: And in the add some new react options: Then go to your Locize project and define your in context editor urls, like described here. The result will look like this: i18next incontext Isn't this great? ð§âð» The complete code can be found here. If you want to learn more basics about i18next, there's also an i18next crash course video. ð𥳠Congratulations ðð I hope youâve learned a few new things about gatsby plugin react i18next, i18next, React.js localization and modern localization workflows. So if you want to take your i18n topic to the next level, it's worth trying the localization management platform Locize. The founders of Locize are also the creators of i18next. So by using Locize you directly support the future of i18next. ð"},{"slug":"i18next-vue","title":"Vue Localization - Internationalize with i18next","description":"Vue Localization made easy with this â
step-by-step guide using i18next.","date":"2022-05-16","category":"Tutorials","thumbnail":"\/img\/blog\/i18next-vue\/vue-localization.jpg","readTime":"8 min read","searchText":"title: 'Vue Localization Internationalize with i18next', description: 'Vue Localization made easy with this â
step by step guide using i18next.', date: '2022 05 16', thumbnail: '\/img\/blog\/i18next vue\/vue localization.jpg', image: '\/img\/blog\/i18next vue\/vue localization.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'i18next', 'vue'] Since Vue.js is an approachable, performant and versatile framework for building web user interfaces, it also needs a best in class internationalization solution. You may know vue i18n, but for those who already know i18next a Vue.js adapted version of i18next would be more appropriate. In this tutorial, we'll make use of the i18next vue module. (Comparing JS frameworks? See our JavaScript localization guide for the Vue setup alongside React, Next.js, Angular, and Svelte.) On Nuxt 4? This post covers plain Vue with i18next directly. For the Nuxt specific stack ( + vue i18n + SSR + lazy loaded locales), see How to internationalize a Nuxt 4 app with @nuxtjs\/i18n and Locize instead. TOC So first of all: \"Why i18next?\" Let's get into it... Prerequisites Getting started Language Switcher How to get the current language? Interpolation and Pluralization Formatting Context Separate translations from code Better translation management For sure! How does this look like? save missing translations ð but there's more... ð¦ Let's prepare for production ð ð𥳠Congratulations ðð So first of all: \"Why i18next?\" When it comes to Vue localization, one of the most popular is i18next with its Vue extension i18next vue, and for good reasons: i18next was created in late 2011. It's older than most of the libraries you will use nowadays, including your main frontend technology (React, Angular, Vue, ...). â¡ï¸ sustainable Based on how long i18next already is available open source, there is no real i18n case that c
40ould not be solved with i18next. â¡ï¸ mature i18next can be used in any javascript (and a few non javascript .net, elm, iOS, android, ruby, ...) environment, with any UI framework, with any i18n format, ... the possibilities are endless. â¡ï¸ extensible There is a plenty of features and possibilities you'll get with i18next compared to other regular i18n frameworks. â¡ï¸ rich Here you can find more information about why i18next is special and how it works. Let's get into it... Prerequisites Make sure you have Node.js and npm installed. It's best, if you have some experience with simple HTML, JavaScript and basic Vue.js, before jumping to i18next vue. Getting started Take your own Vue project or create a new one, i.e. with the vue create cli command. learn vue logo We are going to adapt the app to detect the language according to the userâs preference. And we will create a language switcher to make the content change between different languages. Let's install some i18next dependencies: i18next i18next vue i18next browser languagedetector Let's prepare an file: Let's import that file in our file: Now let's try to move some hard coded text out to the translations. For the first text, we just use a simple key to directly invoke the function. The is more or less the same as . For the second text, we will use the directive to directly output real HTML. Security Warning Dynamically rendering arbitrary HTML on your website can be very dangerous because it can easily lead to XSS vulnerabilities. Only use on trusted content and never on user provided content. The texts are now part of the translation resources: Language Switcher Now let's define a language switcher: And also add some translations for the new language: vue language switcher 𥳠Awesome, you've just created your first language switcher! Thanks to i18next browser languagedetector now it tries to detect the browser language and automatically use that language if you've provided the translations for it. The manually selected language in the language switcher is persisted in the localStorage, next time you visit the page, that language is used as the preferred language. How to get the current language? Since i18next v21 there is . It is set to the current resolved language and it can be used as the primary used language, for example in a language switcher. If your detected language for example is and you provided translations only for (fallbackLng) instead will return . i18next.language vs. i18next.languages vs. i18next.resolvedLanguage Interpolation and Pluralization i18next goes beyond just providing the standard i18n features. But for sure it's able to handle plurals and interpolation. If you like to see how this works, have a look at this section in that other blog post. Formatting Also, formatting can be done. If you like to see how this works, have a look at this section in that other blog post. Context What about a specific greeting message based on the current daytime? i.e. morning, evening, etc. This is possible thanks to the context feature of i18next. If you like to see how this works, have a look at this section in that other blog post. Separate translations from code Having the translations in our file works, but is not that suitable to work with, for translators. Let's separate the translations from the code and place them in dedicated json files. Because this is a web application, i18next http backend will help us to do so. Move the translations to the public folder: public locales Adapt the file to use the : Now the translations are loaded asynchronously. If you have slow network connectivity, you may notice until the translations are loaded only the i18n keys are shown. To prevent this, we make use of the new Suspense functionality of Vue.js. First, let's adapt the file, by exporting the i18next init promise: ...and use that promise in the : Let's create a new file: i.e. : And use that in your file: Now, as long as your translations get loaded you'll see the fallback template: Now your app looks still the same, but your translations are separated. If you want to supp
40ort a new language, you just create a new folder and a new translation json file. This gives you the possibility to send the translations to some translators. Or if you're working with a translation management system you can just synchronize the files with a cli. Better translation management By sending the translations to some translators or translator agencies you have more control and a direct contact with them. But this also means more work for you. This is a traditional way. But be aware sending files around creates always an overhead. Does a better option exist? For sure! i18next helps to get the application translated, and this is great but there is more to it. How do you integrate any translation services \/ agency? How do you keep track of new or removed content? How do you handle proper versioning? How do you deploy translation changes without deploying your complete application? and a lot more... Looking for something like thisâ Easy to integrate Continuous deployment? Continuous localization! Manage the translation files with ease Order professional translations Analytics & Statistics Profit from our content delivery network (CDN) Versioning of your translations Merging versions: Riskfree: Take your data with you Transparent and fair pricing and a lot more... transform the localization process What does this look like? First, you need to signup at Locize and login. Then create a new project in Locize and add your translations. You can add your translations either by using the cli or by importing the individual json files or via API. Done so, we're going to replace i18next http backend with i18next locize backend. After having imported the translations to Locize, delete the locales folder. Adapt the file to use the and make sure you copy the project id and api key from within your Locize project: i18next locize backend offers functionality to retrieve the available languages directly from Locize, let's use it: save missing translations Thanks to the use of the saveMissing functionality, new keys get added to Locize automatically, while developing the app. Just pass in the i18next options: Each time you'll use a new key, it will be sent to Locize, i.e.: will result in Locize like this: missing key ð but there's more... Thanks to the locize lastused plugin, you'll be able to find and filter in Locize which keys are used or not used anymore. With the help of the Locize plugin, you'll be able to use your app within the Locize InContext Editor. Lastly, with the help of the auto machinetranslation workflow and the use of the saveMissing functionality, new keys not only gets added to Locize automatically, while developing the app, but are also automatically translated into the target languages using machine translation. Check out this video to see what the automatic machine translation workflow looks like! https:\/\/www.youtube.com\/watch?v=VfxBpSXarlU use them in : Automatic machine translation: missing key auto Last used translations filter: i18next last used InContext Editor: i18next incontext ð¦ Let's prepare for production ð Now, we prepare the app for going to production. First, in Locize, create a dedicated version for production. Do not enable auto publish for that version but publish manually or via API or via CLI. Lastly, enable Cache Control max ageâ for that production version. Let's make use of the environment feature... Lets' create a default environment file and one for development and one for production: : : : Now let's adapt the file: Now, during development, you'll continue to save missing keys and make use of feature. = And in the production environment, and are disabled, and also the API key is not exposed. = Caching: i18next caching Merging versions: overwrite version ð§âð» The complete code can be found here. Check also the code integration part in this YouTube video. There's also an i18next crash course video. ð𥳠Congratulations ðð I hope youâve learned a few new things about i18next, Vue.js localization and modern localization workflows. So if you want to take your i18n topic to the next level, it's worth trying the localization management platform Locize. The founders of Locize are also the creators of i18next. So by using Locize you directly support the future of i18next. ð"},{"slug":"svelte-i18n","title":"A svelte-i18n guide for internationalization","description":"Simple Svelte localization made easy with this â
step-by-step guide using svelte-i18n.","date":"2022-04-05","category":"Tutorials","thumbnail":"\/img\/blog\/svelte-i18n\/svelte-i18n.jpg","readTime":"3 min read","searchText":"title: 'A svelte i18n guide for internationalization', description: 'Simple Svelte localization made easy with this â
step by step guide using svelte i18n.', date: '2022 04 05', thumbnail: '\/img\/blog\/svelte i18n\/svelte i18n.jpg', image: '\/img\/blog\/svelte i18n\/svelte i18n.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'svelte'] â ï¸ Updated note (March 2026): This post covers Svelte 3\/4 with the legacy mount API. For SvelteKit and Svelte 5, the integration approach differs. Itâs joyful to work with Svelte. The design is elegant and the robust first party additions which can be coupled with, make building browser apps a pleasure. The most famous i18n plugin for the progressive JavaScript framework Svelte is probably svelte i18n. Christian Kaisermann, thank you for this great i18n plugin! In this tutorial, we will add additional superpowers to svelte i18n ð If you're picking between i18n libraries for Svelte vs other frameworks, our JavaScript localization guide compares setups side by side. TOC So how does a basic svelte i18n setup look like? Let's get into it... Is it possible to make a svelte 18n setup even better? Prerequisites Getting started Language Switcher Where are the additional superpowers? How does this look like? save missing translations in context editing ð but there's more... ð𥳠Congratulations ðð So how does a basic svelte i18n setup look like? Let's get into it... Prerequisites Make sure you have Node.js and npm installed. It's best, if you have some experience with simple HTML, JavaScript and basic Svelte, before jumping to svelte i18n. Getting started Take your own Svelte project or create a new one. Let's install the svelte i18n depen
40dency: Create a file: Import the file, in your file: Now let's try to use our first internationalized text. In your template import from and use it like this: Nice! Now let's add another text element... And the corresponding translations: Now, depending on your browser language you should see something like this: Language Switcher Now we will create a language switcher to make the content change between different languages. And we will store the current chosen language in the localStorage: 𥳠Awesome, you've just created your first language switcher! Where are the additional superpowers? Let's meet locizer... locizer is a lightweight module to access data from your Locize project and use that inside your application. What is Locize? How does this look like? First you need to signup at Locize and login. Then create a new project in Locize and add your translations. You can add your translations either by importing the individual json files or via API or by using the CLI. Having the translations in your code file works, but is not that suitable to work with, for translators. Using Locize separates the translations from the code. Having imported all translations should look like this: Done so, we're going to install locizer. Let's adapt the file: Since the translations are now loaded asynchronous, we may also want to show a loading message until the translations are ready: Now your translations are fetched directly from Locize CDN. ð This means you can fix translations without having to change your code or redeploy your app. 𤩠save missing translations I wish newly added keys in the code, would automatically be saved to Locize. Your wish is my command! Extend the file with the Locize api key and the function: Now, if you add a new key in your templates, : It gets automatically saved to Locize: Lastly, with the help of the auto machinetranslation workflow, new keys not only gets added to Locize automatically, while developing the app, but are also automatically translated into the target languages using machine translation: Check out this video to see how the automatic machine translation workflow looks like! https:\/\/www.youtube.com\/watch?v=VfxBpSXarlU in context editing There's another cool think we can do... Let's install Locize: Now open the Locize InContext Editor and be amazed: i18n incontext editor ð but there's more... Caching Merging versions ð§âð» The code can be found here. ð𥳠Congratulations ðð I hope youâve learned a few new things about Svelte localization and modern localization workflows. So if you want to take your i18n topic to the next level, it's worth to try Locize. ð"},{"slug":"next-i18next","title":"Optimize Next.js translations (next-i18next guide)","description":"Optimize your Next.js app to best work with translations on server side and on client side with next-i18next.","date":"2022-04-03","category":"Tutorials","thumbnail":"\/img\/blog\/next-i18next\/next-i18next.jpg","readTime":"6 min read","searchText":"title: 'Optimize Next.js translations (next i18next guide)', description: 'Optimize your Next.js app to best work with translations on server side and on client side with next i18next.', date: '2022 04 03', thumbnail: '\/img\/blog\/next i18next\/next i18next.jpg', image: '\/img\/blog\/next i18next\/next i18next.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'i18next', 'nextjs'] â ï¸ Updated note (March 2026): This post covers next i18next with the Pages Router. For App Router projects, see next i18next v16 which supports both routers, or the standalone App Router guide. Writing Next.js code blurs the lines between client side and server side. The code is written once and depending on your needs it is then executed as SSG (static site generation), SSR (server side rendering) or CSR (client side rendering), etc. So also the internationalization, right? How to optimize Next.js apps to best work with translations on server side and on client side with next i18next? If you're using Next.js 13 with app directory, have a look at this blog post. Let's take the example of next i18next. While next i18next uses i18next and react i18next under the hood, users of next i18next simply need to include their translation content as JSON files and don't have to worry about much else. By default, there is one next i18next configuration that loads the translations from the local directory structure and renders the pages on server side. This is ok, it works and is optimized for SEO etc. but there is more we could do. What if we could power up the seo optimized website with always up to date translations without the need to redeploy your app? We will discuss 2 different setups: One with an active backend and another one completely statically generated. The basic target is always the same: We want everything to be SEO optimized in all languages and serve always the newest translations to our users. Example with a backend server Having a backend server does not mean you are forced to run your own server. It can also be a PaaS or serverless solution, like Vercel or Netlify, etc. Ok, let's start with the default: You followed the normal next i18next setup guide and n
40ow your translations are organized more or less as such: Now let's connect to an awesome translation management system and manage your translations outside of your code. Let's synchronize the translation files with Locize. This can be done on demand or on the CI Server or before deploying the app. What to do to reach this step: 1. in Locize: signup at locize.app\/register and login 2. in Locize: create a new project 3. in Locize: add all your additional languages (this can also be done via API) 4. install the locize cli ( ) Use the locize cli Use the command to synchronize your local repository ( ) with what is published on Locize. Alternatively, you can also use the command to always download the published Locize translations to your local repository ( ) before bundling your app. But you were talking about having always up to date translations without the need to redeploy your app? Yes, let's adapt for that: We will use the i18next locize backend plugin, but only on client side. Together with some other i18next dependencies: i18next locize backend i18next chained backend i18next localstorage backend And we adapt the file: Removing the to or (depending on your case) in the page level components would work, but would not correctly render the server side html. But the client side would be fine. This can be optimized by keeping the or function and making use of the functionality of i18next. This way the ready check is also not necessary, because the translations served directly by the server are used. And as soon the translations are reloaded, new translations are shown. That's it! Let's check the result: The HTML returned from the server looks correctly translated. So this is well optimized for search engines. And on client side, the up to date translations are directly fetched from the Locize CDN. ð This means you can fix translations without having to change your code or redeploy your app. 𤩠ð§âð» The code can be found here. Additional hint: If you've configured caching for your Locize version, you may not need the i18next localstorage backend and i18next chained backend plugin. Static Website example With this example, we just need a static webserver, like GitHub Pages or similar. It's pretty much the same as with above example, but there are some little things we need to additionally consider. To work with static site generation (SSG) we need to use the command, but... Error: i18n support is not compatible with next export. See here for more info on deploying: https:\/\/nextjs.org\/docs\/deployment This happens if you're using the internationalized routing feature and are trying to generate a static HTML export by executing . Well, this features requires a Node.js server, or dynamic logic that cannot be computed during the build process, that's why it is unsupported. There is a dedicated article with a solution to that Next.js problem. Follow that guide first! [](\/blog\/next i18n static\/) Done so? Then let's continue here: It's the same config like in the previous example: Extend the function with options ( ): ...and use it accordingly: That's it! Let's check the result: The generated static HTML looks correctly translated. So this is well optimized for search engines. And on client side, the up to date translations are directly fetched from the Locize CDN. ð This means you can fix translations without having to change your code or redeploy your app. And without owning an active server. 𤩠ð§âð» The code can be found here. Continuous Localization Since we're now \"connected\" to a smart translation management system, we can try to make use of its full potential. save missing translations I wish newly added keys in the code, would automatically be saved to Locize. Your wish is my command! Extend the next i18next config with the Locize api key and set : Each time you'll use a new key, it will be sent to Locize, i.e.: will result in Locize like this: missing key ð but there's more... Thanks to the locize lastused plugin, you'll be able to find and filter in Locize which keys are used or not used anymore. With the help of the Locize plugin, you'll be able to use your app within the Locize InContext Editor. Lastly, with the help of the auto machinetranslation workflow and the use of the saveMissing functionality, new keys not only gets added to Locize automatically, while developing the app, but are also automatically translated into the target languages using machine translation. Check out this video to see how the automatic machine translation workflow looks like! https:\/\/www.youtube.com\/watch?v=VfxBpSXarlU use them like this: Automatic machine translation: missing key auto Last used translations filter: i18next last used InContext Editor: i18next incontext ð¦ Let's prepare for production ð Now, we prepare the app for going to production. First in Locize, create a dedicated version for production. Do not enable auto publish for that version but publish manually or via API or via CLI. Lastly, enable Cache Control max ageâ for that production version. Let's adapt the file once again: Now, during development, you'll continue to save missing keys and to make use of lastused feature. = And in production environment, saveMissing and lastused are disabled. = Caching: i18next caching Merging versions: overwrite version ð§âð» The complete code can be found here. Check also the code integration part in this YouTube video. There's also an i18next crash course video. ð𥳠Congratulations ðð Awesome! Thanks to next i18next, i18next, react i18next and Locize your continuous localization workflow is ready to go. So if you want to take your i18n topic to the next level, it's worth trying the localization management platform Locize. The founders of Locize are also the creators of i18next. So by using Locize you directly support the future of i18next. ð"},{"slug":"remix-i18next","title":"How to internationalize a Remix application with remix-i18next (Part 2)","description":"A continuous localization workflow for your Remix app with i18next, Locize, and remix-i18next.","date":"2022-03-10","category":"Tutorials","thumbnail":"\/img\/blog\/remix-i18next\/remix-localization.jpg","readTime":"2 min read","searchText":"title: 'How to internationalize a Remix application with remix i18next (Part 2)', description: 'A continuous localization workflow for your Remix app with i18next, Locize, and remix i18next.', date: '2022 03 10', thumbnail: '\/img\/blog\/remix i18next\/remix localization.jpg', image: '\/img\/blog\/remix i18next\/remix localization.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'i18next', 'remix', 'how to'] This is the second part of our blog series about internationalizing a Remix application. If you haven't read the first part yet, start here: How to internationalize a Remix application (Part 1) Already on React Router v7? This post targets Remix v2 + 6.x. If you're on React Router v7 framework mode with 7.x, the modern setup is covered in How to internationalize a React Router v7 app with remix i18next. In this part we focus on a continuous localization workflow with Locize, including: keeping translations in sync (CI \/ on demand) handling missing keys in context editing caching & last used reporting TL;DR Use remix i18next for SSR friendly language detection and route namespace loading. Use Locize + locize cli for a modern, automated localization workflow. Continuous localization Once your Remix app is internationalized, the real challenge is keeping translations up to date while the product evolves. missing key With Locize you can: automatically collect missing keys optionally auto translate missing keys (machine translation) allow editors to translate via UI missing key auto mt Syncing translations You can synchronize translations via the CLI: (uploads new keys, downloads published translations) (downloads published translations) This is ideal for CI setups. In context editing Locize supports in context editing in y
40our running application. in context Caching Using an i18next backend with caching reduces calls and speeds up rendering. caching Overwrite versions Locize can keep different published versions so you can roll forward\/back safely. overwrite version Last used reporting Track which keys are actually used in production. last used i18next crash course Next steps Re read Part 1 if you want to start from scratch. If you want a bigger i18next overview, also check the general i18next resources on Locize."},{"slug":"remix-i18n","title":"How to internationalize a Remix application (Part 1)","description":"Simple Remix localization made easy with this â
step-by-step guide using i18next.","date":"2022-03-02","category":"Tutorials","thumbnail":"\/img\/blog\/remix-i18n\/remix-localization.jpg","readTime":"4 min read","searchText":"title: 'How to internationalize a Remix application (Part 1)', description: 'Simple Remix localization made easy with this â
step by step guide using i18next.', date: '2022 03 02', thumbnail: '\/img\/blog\/remix i18n\/remix localization.jpg', image: '\/img\/blog\/remix i18n\/remix localization.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'remix', 'how to'] Let's talk about internationalization (i18n) for Remix... When it comes to JavaScript localization, one of the most popular frameworks is i18next and one of the most famous Remix module for i18next is remix i18next. It was created in October 2021 by Sergio XalambrÃ. There is also a second part of this blog post, that focuses more on a continuous localization workflow. Already on React Router v7? This series targets Remix v2 + 6.x. If you're on React Router v7 framework mode with 7.x, see the React Router v7 walkthrough instead. TOC So first of all: \"Why i18next?\" Let's get into it... Prerequisites Getting started Language Switcher The voluntary part ð𥳠Congratulations ðð Part 2 So first of all: \"Why i18next?\" i18next was created in late 2011. It's older than most of the libraries you will use nowadays, including your main frontend technology (React, Angular, Vue, ...). â¡ï¸ sustainable Based on how long i18next already is available open source, there is no real i18n case that could not be solved with i18next. â¡ï¸ mature i18next can be used in any javascript (and a few non javascript .net, elm, iOS, android, ruby, ...) environment, with any UI framework, with any i18n format, ... the possibilities are endless. â¡ï¸ extensible There is a plenty of features and possibilities you'll get with i18next compared to other regular i18n frameworks. â¡ï¸ rich Here you can find more information about why i18next is special and how it works. Let's get into it... Prerequisites Make sure you have Node.js and npm installed. It's best, if you have some experience with simple HTML, JavaScript and basic React and Remix, before jumping to remix i18next. Getting started Take your own Remix project or use this example app here. We are going to adapt the app to detect the language according to the userâs preference. And we will create a language switcher to make the content change between different languages. Let's install some i18next dependencies: remix i18next i18next react i18next i18next browser languagedetector i18next fs backend i18next http backend Create a file and add the following code: And a file and add the following code: Prepare some folders like this: Now in your adapt the code like this: And in your adapt the code like this: The last important piece is the file: We're ready to start to use the function. In your pages files, you can now use react i18next to access the function: Add the keys to your translations, i.e. : You can do this for all your pages and components: This looks like the normal react i18next usage. Due to we're not using here, just make sure you check the flag before calling the function. The translations will get lazy loaded as soon as you navigate on client side to another page. We can also translate stuff like the page title. Since remix i18next can translate text inside loaders or actions, we can do this for example in our : Add the keys to your translations, i.e. : Language Switcher remix i18next by default will detect the current language in this order: the lng search parameter a cookie (if you pass one) the session (if you pass the sessionStorage) the Accept Language header the fallback language you configured We additionally like to offer the possibility to change the language via some sort of language switcher. So let's add a section in our file: To persist the current locale, we will save it in a cookie. Just create a new file: And use it like this in : and also in : So this means we're using the lng search parameter to change the language. And persist the current detected language in the cookie. app app de 𥳠Awesome, the app is internationalized and we've just created our first language switcher! ð§âð» The complete code can be found here. The voluntary part transform the localization process Connect to an awesome translation management system and manage your translations outside of your co
40de. Let's synchronize the translation files with Locize. This can be done on demand or on the CI Server or before deploying the app. What to do to reach this step: 1. in Locize: signup at locize.app\/register and login 2. in Locize: create a new project 3. in Locize: add all your additional languages (this can also be done via API) 4. install the locize cli ( ) Use the locize cli Use the command to synchronize your local repository ( ) with what is published on Locize. Alternatively, you can also use the command to always download the published Locize translations to your local repository ( ) before bundling your app. ð𥳠Congratulations ðð I hope youâve learned a few new things about i18n in Remix, remix i18next, i18next and modern localization workflows. So if you want to take your i18n topic to the next level, it's worth trying the localization management platform Locize. The founders of Locize are also the creators of i18next. So by using Locize you directly support the future of i18next. There's also an i18next crash course video. ð If you like to know how to unleash the full power of i18next, check out \"Part 2\" !"},{"slug":"i18n-formats-javascript","title":"I18N in the Multiverse of Formats","description":"A nice overview of the existing i18n formats for JavaScript.","date":"2022-02-18","category":"Guides","thumbnail":"\/img\/blog\/i18n-formats-javascript\/i18n_in_the_multiverse_of_madness.jpg","readTime":"6 min read","searchText":"title: 'I18N in the Multiverse of Formats', description: 'A nice overview of the existing i18n formats for JavaScript.', date: '2022 02 18', thumbnail: '\/img\/blog\/i18n formats javascript\/i18n in the multiverse of madness.jpg', image: '\/img\/blog\/i18n formats javascript\/i18n in the multiverse of madness.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides', 'javascript'] Every night... I dream the same dream. And then... the nightmare begins. I do what I have to do... to protect i18n. With this blog post I open a doorway between universes, and I don't know who or what will walk through it... What do you know about the i18n format multiverse? Some folks have their theories... they believe it is dangerous. I think they are right... but I want you at least to know that other parallel universes exist and what they look like. Clarification There are far more i18n formats than the ones I am listing here. In order not to get lost in the madness of the infinite i18n format universes, I limit myself here to the first eight formats used in the JavaScript ecosystem that I was able to find. To define some sort of sorting, the formats are listed based on their weekly downloads: i18next ICU Message Format vue i18n i18n js Polyglot.js Gettext FBT Fluent i18next One of the most popular i18n format is the one used by the i18n framework i18next. It is usually a JSON based format with ability to do plurals (also for languages with multiple plural forms), context, interpolation, formatting, nesting and more. For a focused deep dive on pluralization specifically â CLDR plural categories, the i18next v3 vs v4 format, ordinals, ICU, and the mistakes that quietly break plural output â see i18n Pluralization: CLDR Plural Rules, i18next & ICU. Let's imagine, we would like to show these text based on how many of which dessert I would like to eat: I would like to eat a cake. I would like to eat 3 muffins. I would like to eat something. So we can choose to eat what and how much to eat. With this format it would look like this: And the instrumented code may look like this (may differ, based on your chosen technology) : You see the translation key remains the same for each invocation, and the and option differs. btw: for a languages with multiple plural forms, the instrumented code keeps as is, but the translation json would be different. This is an \"englishified\" example for Arabic plural rules (so most people can read it) : The plural rule for arabic is like this: plural form example count zero 0 one 1 two 2 few 3 10, 103 110, 1003, ⦠many 11 26, 111, 1011, ⦠other 100 102, 200 202, 300 302, 400 402, 500 502, 600, 1000, 10000, 100000, 1000000, ⦠With nesting we can also reduce the repetitions: But it may be that the translators like this nesting substitution less. ICU Message Format The second format is the ICU Message Format. There are multiple JavaScript modules implementing the ICU message syntax. One of the most used is intl messageformat by Format.js. It is used behind the scenes also in react intl, and in next intl, the rising App Router native i18n library for Next.js. Both pair cleanly with Locize via the generic locizer client: see locize react intl example and locize next intl example. It is also a key\/value based format that could be stored in a JSON or however you like: It also offers plural and select, and the instrumented code may look like this (may differ, based on your chosen technology) : Compared to the previous format, this one uses only 1 key to generate all variations. So the value may look a bit more complex. Also here the translation key remains the same for each invocation, and the context and count option differs. vue i18n The next found format, while exploring the multiverse, is the vue i18n format. It is used practically only in the vue i18n framework itself. It is also able to do some interpolation with formatting, pluralization and more. But a context feature is missing. This is how our example would look like: And the corresponding invocation: Compared the the previous formats, this one needs to change the translation key to accomplish a context like feature. i18n js The origin of this format start Ruby. The i18n js format is a direct export of translations defined by Ruby on Rails. To export the translations, a Ruby gem can be used, that's completely disconnected from Rails and that can be used for the solely purpose of exporting the translations, even if your project is
40written in a different language. For JavaScript there's a companion JavaScript package. It comes bundled with all base translations made available by rails i18n. Base translations allow formatting date, numbers, and sentence connectors, among other things. The used JSON based format will look like this: The pluralization keys are organized nested under the normal translation key. And the corresponding invocation: Also this format needs to change the translation key to accomplish a context like feature. Polyglot.js This older format provides a solution for interpolation and pluralization, based off of Airbnbâs experience. Polyglot.js adds basic i18n functionality to Airbnb's Backbone.js and Node.js apps. This format uses only 3 keys, but... The plural forms are merged in a single value separated by the delimiter (4 vertical pipe characters) . And the corresponding invocation: Also this format needs to change the translation key to accomplish a context like feature. Gettext Gettext is a very old translation standard. There are implementations of Gettext in a lot of programming languages. Jed is one of the most used gettext implementations for JavaScript. Jed doesn't include a Gettext file parser, but several third party parsers exist that can have their output adapted for Jed. So an original Gettext po format... ...would look like this when used in Jed: Not very intuitive, but it works. This format offers, pluralization, interpolation and a context feature, but a strange API in my opinion. FBT Of all the formats encountered in the i18n multiverse, this format is arguably the most distant universe, or should I say: most distant \"metaverse\" ; ) FBT is invented, used and maintained by Facebook. It is... special. It comes with text extraction and at the center are not the translations but your code. So first you need to instrument your code: Run some scripts, and then you can use the prepared translation files: Each instrumented code part is mapped with a hash to the translations. Like said... it's really different than all other formats. Fluent The last format in this multiverse trip is Fluent a Mozilla project. The Fluent format shares a lot of philosophy that drove the design of ICU Message Format. It's also a key\/value based format: Like ICU Message Format it uses only 1 key to generate all variations. So the value may look a bit more complex, like a language on its own. Coming back home We looked through the portals of the i18n multiverse and got a few small first impressions about the various formats. Some are very similar and some others are really different. In the end it's a matter of taste. Which format do you feel comfortable with? The most important thing is that all team members are comfortable with it, and that all tools in the localization process supports that format. So choose your translation management system (TMS) carefully. Looking at the history of the currently most used i18n format, we can see the the creators of i18next are also the founders of a great translation management system. So with choosing Locize you directly support the future of i18next. â¡ï¸ i18next + Locize = true continuous localization Watch the demo video to learn more:"},{"slug":"jquery-i18next","title":"The progressive guide to jQuery internationalization (i18n) using i18next","description":"How to properly internationalize a jQuery website using i18next.","date":"2022-02-02","category":"Tutorials","thumbnail":"\/img\/blog\/jquery-i18next\/jquery-localization.jpg","readTime":"8 min read","searchText":"title: 'The progressive guide to jQuery internationalization (i18n) using i18next', description: 'How to properly internationalize a jQuery website using i18next.', date: '2022 02 02', thumbnail: '\/img\/blog\/jquery i18next\/jquery localization.jpg', image: '\/img\/blog\/jquery i18next\/jquery localization.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'i18next', 'jquery'] Every web developer may have met the perennial Methuselah jQuery. Created back in January 2006 at BarCamp NYC by John Resig and currently maintained by a team of developers led by Timmy Willison. You may think: Why a blog post about the venerable but aged JavaScript library, that made things like HTML document traversal and manipulation, etc. easier? Because with a combination of versatility and extensibility, jQuery has changed the way that millions of people write JavaScript! And you can see this by the huge usage of jQuery: Based on w3Techs web technology surveys, jQuery is used by 95.4% of all the websites whose JavaScript library they know. And 78.3% of all websites. Checking the npm download trends of the jquery module it is approaching the 5 million downloads per week. So you see, jQuery is not only still relevant, it takes up the majority of all websites. Therefore, in this article, we will be using the i18next framework to internationalize a jQuery website. TOC So first of all: \"Why i18next?\" Let's get into it... Prerequisites Getting started Language Switcher Translate head information Interpolation and Pluralization Formatting Context Separate translations from code Better translation management For sure! How does this look like? save missing translations ð but there's more... ð𥳠Congratulations ðð So first of all: \"Why i18next?\" When it comes to jQuery localization, one of the most popular is i18next with it's jQuery extension jquery i18next, and for good reasons: i18next was created in late 2011. It's older than most of the libraries you will use nowadays, including your main frontend technology (React, Angular, Vue, ...). Only jQuery is older ð â¡ï¸ sustainable Based on how long i18next already is available open source, there is no real i18n case that c
40ould not be solved with i18next. â¡ï¸ mature i18next can be used in any javascript (and a few non javascript .net, elm, iOS, android, ruby, ...) environment, with any UI framework, with any i18n format, ... the possibilities are endless. â¡ï¸ extensible There is a plenty of features and possibilities you'll get with i18next compared to other regular i18n frameworks. â¡ï¸ rich Here you can find more information about why i18next is special and how it works. Let's get into it... Prerequisites Make sure you have a jQuery based website or web app. It's best, if you have some experience with simple HTML, JavaScript and basic jQuery, before jumping to jquery i18next. This jQuery i18n example is not intended to be a jQuery beginner tutorial. Getting started Take your own jQuery project or create a new one. I have here an awesome landing page ð We are going to adapt the website to detect the language according to the userâs preference. And we will create a language switcher to make the content change between different languages. Let's install some i18next dependencies: i18next jquery i18next i18next browser languagedetector Let's prepare an file: Let's load that file: Now let's try to move some hard coded text out to the translations. Since the texts will be part of our translation resources, they could also be removed: The texts are now part of the translation resources: Language Switcher Now let's define a language switcher: And also add some translations for the new language: jquery language switcher 𥳠Awesome, you've just created your first language switcher! Thanks to i18next browser languagedetector now it tries to detect the browser language and automatically use that language if you've provided the translations for it. The manually selected language in the language switcher is persisted in the localStorage, next time you visit the page, that language is used as preferred language. Translate head information Let's translate also the title and description of the website. We do this by extending our function, and adding the additional translation resources: So you see, this can be also done with the helper function. Let's check the DOM: Nice ð Interpolation and Pluralization i18next goes beyond just providing the standard i18n features. But for sure it's able to handle plurals and interpolation. Let's count each time the language gets changed: Let's remember the count in the variable and increment it on each language change. ...and extending the translation resources: Based on the count value i18next will choose the correct plural form. Read more about pluralization and interpolation in the official i18next documentation. jQuery pluralization ð¡ i18next is also able to handle languages with multiple plural forms, like arabic: Formatting Now, letâs check out how we can use different date formats with the help of i18next and moment.js to handle date and time. We like to have the footer displaying the current date: Define a format function, like documented in the documentation and add the new translation key: ð Cool, now we have a language specific date formatting! English: German: Context What about a specific greeting message based on the current day time? i.e. morning, evening, etc. This is possible thanks to the context feature of i18next. Let's create a function and use the result as context information for our footer translation. And add some context specific translations keys: ð Yeah, It works! Separate translations from code Having the translations in our file works, but is not that suitable to work with, for translators. Let's separate the translations from the code and pleace them in dedicated json files. Because this is a web application, i18next http backend will help us to do so. Create a folder and move the translations there: public locales Adapt the file to use the : Now the translations are loaded asynchronously, so it may be the UI will refresh a bit later, as soon as the translations are loaded. To optimize this behaviour, you can show some sort of loading indicator until the i18next is initialized. Something like: Now your app looks still the same, but your translations are separated. If you want to supp
40ort a new language, you just create a new folder and a new translation json file. This gives you the possibility to send the translations to some translators. Or if you're working with a translation management system you can just synchronize the files with a cli. Better translation management By sending the translations to some translators or translator agency you have more control and a direct contact with them. But this also means more work for you. This is a traditional way. But be aware sending files around creates always an overhead. Does a better option exist? For sure! i18next helps to get the application translated, and this is great but there is more to it. How do you integrate any translation services \/ agency? How do you keep track of new or removed content? How do you handle proper versioning? How do you deploy translation changes without deploying your complete application? and a lot more... Looking for something like thisâ Easy to integrate Continuous deployment? Continuous localization! Manage the translation files with ease Order professional translations Analytics & Statistics Profit from our content delivery network (CDN) Versioning of your translations Automatic and On Demand Machine Translation Riskfree: Take your data with you Transparent and fair pricing and a lot more... transform the localization process How does this look like? First you need to signup at Locize and login. Then create a new project in Locize and add your translations. You can add your translations either by using the cli or by importing the individual json files or via API. Done so, we're going to replace i18next http backend with i18next locize backend. After having imported the translations to Locize, delete the folder and adapt the file to use the i18next locize backend and make sure you copy the project id and api key from within your Locize project: i18next locize backend offers a functionality to retrieve the available languages directly from Locize, let's use it: Now the translations are served directly from the Locize CDN. The jQuery i18n has now CDN superpower ð. save missing translations Thanks to the use of the saveMissing functionality, new keys gets added to Locize automatically, while developing the app. Just pass in the i18next options: Each time you'll use a new key, it will be sent to Locize, i.e.: will result in Locize like this: missing key ð but there's more... Thanks to the locize lastused plugin, you'll be able to find and filter in Locize which keys are used or not used anymore. With the help of the Locize plugin, you'll be able to use your app within the Locize InContext Editor. Lastly, with the help of the auto machinetranslation workflow and the use of the saveMissing functionality, new keys not only gets added to Locize automatically, while developing the app, but are also automatically translated into the target languages using machine translation. Check out this video to see how the automatic machine translation workflow looks like! https:\/\/www.youtube.com\/watch?v=VfxBpSXarlU use them in : Automatic machine translation: missing key auto Last used translations filter: i18next last used InContext Editor: i18next incontext Now, during development, you'll continue to save missing keys and to make use of feature. And in production environment, you should disable or remove the and functionality, and also the api key should not exposed. Caching: i18next caching Merging versions: overwrite version ð§âð» The complete code can be found here. Check also the code integration part in this YouTube video. There's also an i18next crash course video. ð𥳠Congratulations ðð I hope youâve learned a few new things about i18next, jQuery localization and modern localization workflows. So if you want to take your i18n topic to the next level, it's worth trying the localization management platform Locize. The founders of Locize are also the creators of i18next. So by using Locize you directly support the future of i18next. ð"},{"slug":"i18n-for-deno-with-i18next","title":"Internationalization (i18n) for Deno with i18next","description":"How does internationalization (i18n) for Deno look like? CLI, webserver, server side rendered sites, etc...","date":"2022-01-28","category":"Tutorials","thumbnail":"\/img\/blog\/i18n-for-deno-with-i18next\/deno_i18next.jpg","readTime":"3 min read","searchText":"title: 'Internationalization (i18n) for Deno with i18next', description: 'How does internationalization (i18n) for Deno look like? CLI, webserver, server side rendered sites, etc...', date: '2022 01 28', thumbnail: '\/img\/blog\/i18n for deno with i18next\/deno i18next.jpg', image: '\/img\/blog\/i18n for deno with i18next\/deno i18next.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'i18next', 'deno'] You may already know how to properly internationalize a client side application, like described
40in this React based tutorial, this Angular based tutorial or this Vue based tutorial. In this blog post we will shed light on Deno. Why do I need to handle i18n in Deno? Think of all user faced content not directly rendered in your browser... For example you're building a command line interface (CLI)? You're using server side rendering (SSR)? Or you're sending some emails? etc. Let's check that out... We will show some examples that uses i18next as i18n framework. If you're curious to know why we suggest i18next, have a look at this page. Command line interface (CLI) Let's start with something simple: a verry small CLI app. We are defining a command with optional language and name parameters that should respond with a salutation in the appropriate language. Ok, now let's create a new file and setup i18next accordingly: And also our translation resources: Now we can use the export like that: Ok, what's the result? Easy, isn't it? You can also i.e. use the i18next fs backend to dynamically load your translations, for example like this: ð§âð» A code example can be found here. A possible next step... A possible next step could be to professionalize the translation management. This means the translations would be \"managed\" (add new languages, new translations etc...) in a translation management system (TMS), like Locize and synchronized with your code. To see how this could look like, check out Step 1 in this tutorial. Server Side Rendering (SSR) For this example we will use the http framework abc (created by æ¨æ, but any other framework will also work. This time we will use a different i18next module, i18next http middleware. It can be used for all Deno web frameworks, like abc or ServestJS, but also for Node.js web frameworks, like express or Fastify. As already said, here we will use abc. Let's again start with the file: And our translation resources... A simple ejs template: Our \"main\" file : Now start the app and check what language you're seeing... dejs abc If you check the console output you'll also see something like this: Yes, if you like, you can also internationalize your log statements ð ð§âð» A code example can be found here. A possible next step... Do you wish to manage your translations in a translation management system (TMS), like Locize? Just use this cli to synchronize the translations with your code. To see how this could look like check out Step 1 in this tutorial. Alternatively, use i18next locize backend instead of the i18next fs backend. If you're running your code in a serverless environment, make sure you read this advice first! There's also an i18next crash course video. ð𥳠Conclusion ðð As you see i18n is also important for Deno. I hope youâve learned a few new things about Deno server side internationalization and modern localization workflows. So if you want to take your i18n topic to the next level, it's worth to try i18next and also Locize. ð"},{"slug":"next-i18n-static","title":"Next.js i18n-Compatible Static HTML Export","description":"Learn how to optimize Next.js static HTML export for internationalization (i18n) with step-by-step instructions and helpful tips.","date":"2021-12-07","category":"Tutorials","thumbnail":"\/img\/blog\/next-i18n-static\/title.jpg","readTime":"4 min read","searchText":"title: 'Next.js i18n Compatible Static HTML Export', description: 'Learn how to optimize Next.js static HTML export for internationalization (i18n) with step by step instructions and helpful tips.', date: '2021 12 07', thumbnail: '\/img\/blog\/next i18n static\/title.jpg', image: '\/img\/blog\/next i18n static\/title.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'nextjs'] â ï¸ Updated note (March 2026): This post covers the Next.js Pages Router with static export, an approach that has changed significantly. For the current recommended approach, see Next.js i18n with App Router or next i18next v16. You know Next.js, right? If not, stop reading this article and make something else. If you're using Next.js 13 with app directory, have a look at this blog post. Next.js is awesome! It gives you the best developer experience with all the features you need... TOC BUT, you may have heard about this So what can we do now? The recipe The outcome The voluntary part ð𥳠Congratulations ðð BUT , you may have heard about this: Error: i18n support is not compatible with next export. See here for more info on deploying: https:\/\/nextjs.org\/docs\/deployment This happens if you're using the internationalized rout
40ing feature and are trying to generate a static HTML export by executing . Well, this feature requires a Node.js server, or dynamic logic that cannot be computed during the build process, that's why it is unsupported. This is the case if you're using next i18next for example. So what can we do now? An obvious option is, to renounce to the static HTML export and use a Node.js server or Vercel as deployment environment. But sometimes, due to company or architectural guidelines it is mandatory to use a static web server. Ok then renounce to i18n? Not really, if we are here, it seems like to be a requirement. So then do it without Next.js? But this usually means to rewrite the whole project. Executing when not using i18n seems to work. What if we do not try to use the internationalized routing feature and do the i18n routing on our own? The recipe To \"cook\" this recipe you will need the following ingredients: use the dynamic route segments feature willingness to change the structure of your project files willingness to adapt a bit of code a logic to detect the user language and redirect accordingly Sounds feasible. Let's start! 1. Remove the i18n options from . 2. Create a folder inside your pages directory. a) Move all your pages files to that folder (not or etc..) . b) Adapt your imports, if needed. 3. Create a file and place it for example in a directory. 4. Use and in your pages, like this: 5. Install next language detector. 6. Create a file and place it for example in the directory. 7. Create a file and place it for example in the directory. 8. For each of your pages files in your directory, but especially for the file, create a file with the same name with this content: 9. Create a component and place it for example in the directory. 10. Replace all imports with the appropriate import: 11. Add or modify your file to set the correct html attribute: 12. In case you have a language switcher, create or adapt it: The outcome If you now start your project ( ) you should see, more or less, the same behaviour as before. So what's the benefit? Try: You should see something like this at the end: Yeah no error anymore!!! Congratulations! Now you can \"deploy\" the content of your directory to any static web server. ð§âð» The complete code can be found here. The voluntary part transform the localization process Connect to an awesome translation management system and manage your translations outside of your co
40de. Let's synchronize the translation files with Locize. This can be done on demand or on the CI Server or before deploying the app. What to do to reach this step: 1. in Locize: signup at locize.app\/register and login 2. in Locize: create a new project 3. in Locize: add all your additional languages (this can also be done via API) 4. install the locize cli ( ) Use the locize cli Use the command to synchronize your local repository ( ) with what is published on Locize. Alternatively, you can also use the command to always download the published Locize translations to your local repository ( ) before bundling your app. ð𥳠Congratulations ðð I hope youâve learned a few new things about static site generation (SSG), Next.js, next i18next, i18next and modern localization workflows. So if you want to take your i18n topic to the next level, it's worth trying the localization management platform Locize. The founders of Locize are also the creators of i18next. So by using Locize you directly support the future of i18next. ð Looking for an optimized Next.js translations setup? next i18next Here you'll find a blog post on how to best use next i18next with client side translation download and SEO optimization."},{"slug":"globalization-vs-localization","title":"Globalization vs. Localization - What is the difference","description":"What is the difference between globalization and localization, what does each include and what are pros and cons.","date":"2021-09-15","category":"Guides","thumbnail":"\/img\/blog\/globalization-vs-localization\/globalization-vs-localization.webp","readTime":"6 min read","searchText":"title: 'Globalization vs. Localization What is the difference', description: 'What is the difference between globalization and localization, what does each include and what are pros and cons.', date: '2021 09 15', thumbnail: '\/img\/blog\/globalization vs localization\/globalization vs localization.webp', image: '\/img\/blog\/globalization vs localization\/globalization vs localization.webp', category: 'Guides', tags: ['localization', 'guides', 'basics', 'comparison'] Do you know what is meant by globalization versus localization? From the outside, these two terms could appear like complete opposites of each other. However, that is not quite the case, and they actually go hand in hand, which is often where the confusion arises. To help you understand the differences between globalization versus localization, we were thinking we could take a closer look at what they mean and why they are important. What is globalization? Before looking at the differences between the two, it is essential to understand what each term means. Globalization is often the process that needs to happen before content can be localized, although the process does not stop once localization begins. Globalization is the process of adapting resources to ensure that they are able to meet the demands of various cultures. This ensures that the content is able to be easily accessed and used worldwide, and this can be done through multiple methods: Language One of the core aspects of globalization is ensuring that the language is suitable to meet multiple markets. While this is also an important aspect of localization, it requires a different approach. Globalization requires translating existing content to ensure that it can be read and accessed to multiple audiences in new localities. Content Alongside ensuring the language is suitable for multiple viewers, globalization also examines the content being used. This requires thinking about every aspect of the design and style, ensuring that it is as appealing as possible to your target audience, no matter where they are based. This can be a challenge; for example, while users read from left to right in the West, in East Asia and the Middle East, they tend to read from right to left. This often requires unique coding that allows websites to be more flexible, allowing content to be adapted and ensuring the pages can support time, date, and number formats most commonly used in the readerâs location. Globalization is all about thinking of the bigger picture and how customers around the world will be able to interact and engage with your content. Also watch this interesting video from Financial Times: Video: Globalisation to Localisation What is localization? When it comes to understanding globalization versus localization, knowing the differences between the two is crucial. While globalization is the process of ensuring the content can meet multiple markets, localization is the process of guaranteeing your resources are focused on the requirements of one specific audie
40nce. Effective localization requires multiple factors, including: Translations Just like globalization, one of the most important factors of localization is the language and translations you are using. For example, do you know the difference between localisation and localization? The former is how people in the United Kingdom would spell it, while the latter is how people across the Atlantic would. While this might seem like a minor difference, it is these small nuances that can transform a customerâs perception of your brand. Of course, when it comes to translation, sometimes a literal interpretation might not always make sense. That is why you need to ensure that when converting content into a new language, you make sure the meaning remains the same. Utilize the right formats Another important aspect of localization is ensuring that you are using the right format for things such as: Date and time Measurements Currency Telephone number formats Keyboard formats Punctuations and symbols Consider the design The design and style are also a very important part of the localization process. This requires ensuring that the visuals match with the requirements of your target audience. This includes everything from the photography and layout of the site to the colors and tone of the writing. More detailed information wanted? Read this article about what is localization. Globalization versus localization, what comes first? When it comes to understanding what is meant by globalization versus localization, you should now have a clearer idea of what both terms mean. However, which one should you focus on first? While both options can help you to create a more inclusive and engaging piece of content, no matter whether it is a website, manual, or marketing material. Deciding which stage to focus on first will depend on who your target audience is. If you are solely looking to focus on one specific region, then opting just for localization can be the better option. However, typically, globalization is the first process to undertake as this will give you a clear and strong base to work from when you begin the localization process. When it comes to looking at the differences between the two, there are three key factors to remember: 1. Localization is the process of focusing on a specific culture, location, or audience . Globalization is the process of looking at multiple cultures, locations, or audiences. 2. Localization is a part of the wider globalization process , whereas globalization forms part of your overall business strategy. 3. Globalization is often part of a larger long term business strategy (see: strategy), while localization is often used for more short term actions. The pros and cons of globalization versus localization Both globalization and localization strategy can be a complex process, but they are an essential part of any customer service strategy for your business. Both options are able to provide companies with a wide range of benefits, but they do also have some drawbacks. Pros and cons of globalization Globalization is able to provide businesses with a wide range of benefits, helping them to reach a far greater audience. Not only can this help to increase revenue by expanding your customer base, but it is also able to significantly enhance your overall brand reputation and global image. This, in turn, can help to decrease dependence on a single market, ensuring your business is more resilient in the face of economic challenges. However, globalization can be a very time consuming process and does require additional resources alongside the many challenges of a market expansion. Pros and cons of localization If you are looking to enter specific new markets, then localization is essential in helping to facilitate this. It can help to create significant brand loyalty from customers, improving their overall experience with your company. By building loyal customers, you will be able to increase revenue and secure a more competitive advantage in that market. Of course, just like globalization, localization does require significant investment in terms of time and resources. If not done correctly, it can also have a negative impact on your brand image, so it is always re
40commended you work with a professional partner who can help you. So which is right for you? When it comes to globalization versus localization, both strategies can help you to transform your business. While they might sound like two completely different methods, globalization and localization can work in tandem to help you successfully branch out into new markets and increase your revenue. Knowing which option will be right for you will depend on the overall strategy and the audience you are looking to reach. Whichever you choose, partnering with a professional translation and localization team from a translation management platform will help ensure that it is completed to the highest standards alongside reducing the time and resource investment that you need to make. Further to read (examples) If you want to read about real world i18n localization examples from our client cases, check out our recent blog post on website localization. Read more about how software is affected by globalization and localization and what potential localization of software has in the \"what is software localization\" blog post."},{"slug":"what-is-video-game-localization","title":"What is video game localization","description":"Learn how video game translation works and how you can utilize it to boost your company's revenue.","date":"2021-09-15","category":"Guides","thumbnail":"\/img\/blog\/what-is-video-game-localization\/what-is-video-game-localization.webp","readTime":"6 min read","searchText":"hideCta: true, title: 'What is video game localization', description: \"Learn how video game translation works and how you can utilize it to boost your company's revenue.\", date: '2021 09 15', thumbnail: '\/img\/blog\/what is video game localization\/what is video game localization.webp', image: '\/img\/blog\/what is video game localization\/what is video game localization.webp', category: 'Guides', tags: ['localization', 'guides', 'basics'] Video games are one of the biggest recreational pastimes in the world, with recent estimates suggesting that there are currently nearly 2.7 billion gamers across the globe. The incredible demand in recent years has seen growth skyrocket, and estimates suggest that by 2025 the industry will be worth an astounding $268 billion, up from the $159.3 billion in 2020. While there can be no denying the popularity of the video game market, effective localization is essential for every video game producer. What is localization in video games, though? How does it work? To help you, we thought we would take a closer look at what video game localization is and how it benefits not only game producers but players, too. gamers What is localization in video games? While the very first video games such as tennis or Tetris might have been simple storylines, modern video games are a truly holistic experience more akin to a feature movie. Games such as Red Dead Redemption, Grand Theft Auto, and Call of Duty are truly an in depth story that takes gaming to completely new levels. Increasingly becoming more like a Hollywood blockbuster, modern games are highly sophisticated pieces of software. However, the cinematic gameplay, complex dialogue, and real time interaction mean the game needs to be able to work across multiple markets, languages, and countries. This is where video game localization is vital, helping to ensure that players around the world are able to enjoy the same experience. Localization makes it feel like the game was made for every region it has been launched in, improving the overall player experience. How does video game localization work? While it might seem like a simple enough concept, the actual process of localization is incredibly complex. When it comes to answering the question, âwhat is localization in video games?â there are many different factors that need to combine to ensure a seamless playing experience for every gamer. The three most important areas for video game localization are: 1) The in game story Video games are becoming a far more complex story that has many interwoven narratives that combine as players work their way through. This helps to keep them engaged, but in order for every gamer to have the same experience, the script and story need to be localized to specific regions. This means that everything from character names, weapons, and locations should be adapted for the target audience. For example, if the game was set in Russia, then it would not make sense to have a local bar with an English name. Game developers should be working to ensure the script and gameplay are as realistic as possible; otherwise, they risk discouraging players from continuing with the game. Equally, it is important to remember that names change around the world. For example, while Kim might be a feminine name in America, it is a popular male name in places such as Norway. This might seem like a minor difference against the overall gameplay, but these little nuances are essential in ensuring that the game is able to capture the attention of players. 2) Technical elements Of course, while the overall gameplay experience is essential, game developers also need to ensure that they are focusing on localizing the many various technical aspects of the game too. One of the biggest areas most commonly overlooked is how dates and times are written, or the units of measurements are displayed. These are critical components in creating a truly immersive experience for every player. It is also important to consider the space for text and the symbols being used. For example, in Europe, many languages use quite short words apart from German, which traditionally has quite lengthy words. This is something that will need to be considered when adding in subtitles or written wording. 3) Marketing campaigns When it comes to understanding âwhat is localization in video games?â it is important to remember that it is not just limited to the actual game itself. In the highly competitive world of modern gaming, marketing campaigns are one of the most important steps to success and begin months, if not years, in advance of the launch. marketing campaign However, to truly maximize the commercial appeal of the game, developers need to ensure that they are localizing their marketing campaign. Without doing so, they risk alienating certain audie
40nces and losing a vital opportunity to maximize pre launch interest in the game. Localizing your marketing content requires a comprehensive review of all materials. From the images and graphics being used to the language and wording, you want to ensure you are targeting the gaming habits of those players in each region you are launching in. This is also important in other areas of localization like webapps, for this check out this guide on react localization. Why is video game localization important When it comes to understanding âWhat is localization in video games?â it is important to understand the many benefits that it can provide. 1) Boost sales Focusing on localization and culturalization ensures that gamers are more invested in your game and company. This helps you to launch the game in more regions, significantly boosting the number of players and maximizing your sales. While video game localization does require time and resource investment, it is a worthwhile process as it ensures you can reach a far greater audience. 2) Increase customer satisfaction Localization is also a great way to boost customer satisfaction by making them feel important. When they can see that the developer has gone the extra mile to create a seamless experience that feels like it has been specifically developed for them, they become far more invested in the game. The higher the satisfaction of your players, the more likely they are to share their experience with friends and remain customers for any future games you might release. 3) Stay competitive As the market continues to grow, it is becoming increasingly more challenging for game developers to stand out from the crowd. This means localization is going to become increasingly more important to remain competitive. This strategic approach will allow you to branch out into more markets, helping you to become more resilient in the process. Localizing your video game What is localization in video games? Well, as the market continues to grow, it is set to become an essential aspect of any game development. While it might not be the first thing that developers think of, focusing on localizing the game from the start can help to make the process far more efficient and effective. Localization can be a complex process, though, so working with a professional partner can help to ensure that you are able to create the most immersive and engaging experience possible. To make the process more streamlined, you should take the time to plan your project, create a localization kit, and creating quality assurance checks will ensure that your various localization partners know exactly what is required. The more detailed your localization is, the greater the experience that each player has and the more gamers that will want to engage with your game. With some 2.7 billion players in the world, open your game up to a wider audience today. Try Locize to make your game incredible The localization software of Locize helps game companies to easily translate their software components through an easy interface and while split the development process from the marketing work. Game localization should keep up with the development of the game. Continuous localization allows you to join several markets practically simultaneously, resulting in shorter translation turnaround times and much needed velocity. game localization logo"},{"slug":"website-internationalization-best-practices","title":"These are the website internationalization best practices","description":"What are the best practices for website internationalization?","date":"2021-08-16","category":"Guides","thumbnail":"\/img\/blog\/website-internationalization-best-practices\/website-internationalization-best-practices.webp","readTime":"5 min read","searchText":"hideCta: true, title: 'These are the website internationalization best practices', description: 'What are the best practices for website internationalization?', date: '2021 08 16', thumbnail: '\/img\/blog\/website internationalization best practices\/website internationalization best practices.webp', image: '\/img\/blog\/website internationalization best practices\/website internationalization best practices.webp', category: 'Guides', tags: ['localization', 'i18n', 'guides'] When it comes to internationalizing your website, this article should assist you in determining your best practices. This could be as a result of a strategic shift or if you want to start an international company or project this is for you. The process when your web app becomes international should not be a difficult task. Another article about website localization shows you the process of planning, and if you read further in this article we try to help you to avoid any mistake. If you're not sure what internatationalization is, check out our guide what is i18n . Make website internationalization easy with these couple of best practices : Best practices summary 1. Use as little text as possible in your pictures 2. Separate code from translating 3. Consider different ways of pluralizing words 4. Check to see if the layout can support longer or shorter text 5. Make it easy to find strings 6. Set character encoding to UTF 8 7.
40Consider the also the colors 8. Choose the right localization translation service Best practices in detail 1. Use as little text as possible in your pictures Because you will end up uploading several images for the same piece or web content, as it has to be translated during the localization process. If you don't have any text in your image, there's no need to modify anything when it comes to localizing your website. Another possibility is to separate the text from the image. You may create a layer that will be placed on top of the image. Alternatively, make picture files easily accessible. Sometimes even if there is no legible text you may want to adapt the art asset (i.e. an image) because of cultural reasons. There are some libraries that can help with this issue i.e. Fragment replacement for links and images. 2. Separate code from translating It seems logical to keep the code separate from the translation process. During the project, the developer may work freely without being interrupted by any colleagues. This way, you won't lose sight of the project and guarantee that no mistakes occur. This way you gather new content automatically and smoothly, posting it for translation, getting translations, and integrating them back into the product. A good localization management solution can really help here. All team members can collaboratively work in parallel. In this way, you can get to your objective in a faster way. When using Locize as a localization management platform , this feature will be offered. 3. Consider different ways of pluralizing words Various languages have different grammatical rules for dealing with plural nouns and units. Ensure to offer a separate translation for each plural form in the language when localizing formatted strings that include variable quantities. In Polish, for example, imagine you have a singular and then a plural depending on whether the number of objects ends with 2, 3, 4, or any other digit. And each collection of things more than 20 requires a separate plural in Romanian. Locize recognizes and accurately estimates your progress in the various languages by taking into account the various pluralization laws. plurals 4. Check to see if the layout can support longer or shorter text The fact is that translations can take longer than the original text and will break the layout. So check in advance that your translation approach can support different sizes of translations. Particularly in Europe, where various languages might have many more terms for the same statement. In this blog post , you will find a comparison of European languages with a table showing a very nice overview \"how the languages are different\". You may use the Locize review workflow to guarantee that changes to translations are accepted before they are published. Until one of the translation proposals is approved, the real value will remain unchanged. 5. Make it easy to find strings Strings should definitly not be directly in the code. Make it simple for developers to externalize their strings and include them in resource files from the beginning. This implies that any hard coded string will appear in their original language, regardless of the user's language. You will never face such problems again if you use a translation management software such as Locize. With the integrated search feature, translators may discover any string in seconds. 6. Set character encoding to UTF 8 Select an encoding that is compatible with all target languages. If you are unsure, simply select UTF 8. If you're wondering why UTF 8 is the greatest encoding, read on this FAQ about UTF 8 . To distinguish assets meant for a certain region, utilize ISO 693 1 & 3166 1 language and country codes to mark assets by locale. 7. Consider the also the colors In terms of user experience, the culture of your target consumer may make a significant difference. When creating your web design, consider which markets you want to target. You want to leave a favorable impression on your target clients, not something that will remind them of a terrible incident, political issue, or something similar. As a result, make it simple for your website to swap colors based on target country or region. 8. Choose the right localization translation service When choosing a localization translation service , there are two major topics: one that focuses on professional and long term software localization, and the other that focuses on a rapid and transparent translation work. Topic 1: Use Locize as localization platform There are numerous ways to use Locize for your localization translation service, such as managing all of your translations during a specific project such as a website, app, or video game. Planing and managing your localization project cuntinuously translating, while your project's development team adds new features. Allow in house translators to manage translation without interfer
40ing with the development process. You may request a translation from a third party using the Locize interface. Overall, Locize is a very versatile solution for your company's or software's localization needs. Topic 2: Use a translation service provider Beside having the possibility to directly use a translation service provider from withing Locize, you can use it also for sophisticated papers, product brochures, as well as for financial, legal, and technological topics. Conclusion If you follow the best practices, you may create a seamless procedure and save money in the long run. In general, it is advisable to get assistance from an adviser who has extensive experience. Please do not hesitate to contact us if you have any questions. We're offering a free 14 day trial, so you may have a nice opportunity to try all features anyhow. Register today for a free trial period and begin your finest experience. You are a developer So here you can find more information about how to integrate Locize, like our complete JavaScript localization guide covering React, Next.js, Vue, Angular, Svelte, and vanilla JS \/ Node.js. There are also some dedicated articles about React localization."},{"slug":"how-does-server-side-internationalization-look-like","title":"How does server side internationalization (i18n) look like?","description":"How does server side internationalization (i18n) look like? CLI, webserver, mail generation, server side rendered sites, Next.js, etc...","date":"2021-06-28","category":"Guides","thumbnail":"\/img\/blog\/how-does-server-side-internationalization-look-like\/server_side_backend.jpg","readTime":"5 min read","searchText":"title: 'How does server side internationalization (i18n) look like?', description: 'How does server side internationalization (i18n) look like? CLI, webserver, mail generation, server side rendered sites, Next.js, etc...', date: '2021 06 28', thumbnail: '\/img\/blog\/how does server side internationalization look like\/server side backend.jpg', image: '\/img\/blog\/how does server side internationalization look like\/server side backend.jpg', category: 'Guides', tags: ['localization', 'i18n', 'guides'] You may already know how to properly internationalize a client side application, like described in this React based tutorial, this Angular based tutorial or this Vue based tutorial. In this blog post we will shed light on the server side. Why do I need to handle i18n in my application's backend? Think of all user faced content not directly rendered in your browser... For example you're building a command line interface (CLI)? You're sending some emails? Or you're using server side rendering (SSR)? etc. Let's check that out... We will show some examples that uses i18next as i18n framework. If you're curious to know why we suggest i18next, have a look at this page. Command line interface (CLI) Let's start with something simple: a very small CLI app. For this example let's use commander, originally created by TJ Holowaychuk. We are defining a command with optional language and name parameters that should respond with a salutation in the appropriate language. Ok, now let's create a new file and setup i18next accordingly: And also our translation resources: Now we can use the export like that: Ok, what's the result? Easy, isn't it? If you don't bundle your CLI app in a single executable, for example by using pkg, you can also i.e. use the i18next fs backend to dynamically load your translations, for example like this: ð§âð» A code example can be found here. A possible next step... A possible next step could be to professionalize the translation management. This means the translations would be \"managed\" (add new languages, new translations etc...) in a translation management system (TMS), like Locize and synchronized with your code. To see how this could look like, check out Step 1 in this tutorial. Generate Emails Another typical server side use case that requires internationalization is the generation of emails. To achieve this goal, you usually need to transform some raw data to html content (or text) to be shown in the user's preferred language. In this example we will use pug (formerly known as \"Jade\", and also originally created by TJ Holowaychuk) to define some templates that should be filled with the data needed in the email, and mjml to actually design the email content. Let's create a new file, which we can use, to accomplish this. The could look like this: Now let's define some translations... ...and use them in an file: So finally, all the above can be used like that: This is how the resulting html could look like: mail preview ð§âð» A code example can be found here. Server Side Rendering (SSR) We will try 2 different SSR examples, a classic one using Fastify with pug and a more trendy one using Next.js. Fastify with Pug example For this example we will use my favorite http framework Fastify (created by Matteo Collina and Tomas Della Vedova), but any other framework will also work. This time we will use a different i18next module, i18next http middleware. It can be used for all Node.js web frameworks, like express or Fastify, but also for Deno web frameworks, like abc or ServestJS. As already said, here we will use Fastify, my favorite ð. Let's again start with the file: And our translation resources... A simple pug template: Our \"main\" file : Now start the app and check what language you're seeing... pug fastify If you check the console output you'll also see something like this: Yes, if you like, you can also internationalize your log statements ð ð§âð» A code example can be found here. Next.js example Now it's time for Next.js... When it comes to internationalization of Next.js apps one of the most popular choices is next i18next. It is based on react i18next and users of next i18next by default simply need to include their translation content as JSON files and don't have to worry about much else. Here you'll find a simple example. You just need a file that provides the configuration for and wrapping your app with the function, which allows to use the (translate) function in your components via hooks. By default, expects your translations to be organized as such: A demo of how such an app looks like when it is deployed, can be found here. next i18next demo This looks really simple, right? Manage the translations outside of the code To best manage the translations there are 3 different approaches: POSSIBILITY 1: live translation download When using Locize, you can configure your next i18next project to load the translations from the CDN (on server and client side). Such a configuration could look like this: Here you'll find more information and an example on how this looks like. There is also the possibility to cache the translations locally thanks to i18next chained backend. Here you can find more information about this option. If you're deploying your Next.js app in a serverless environment, consider to use the second possibility... More information about the reason for this can be found here. POSSIBILITY 2: bundle translations and keep in sync If you're not sure, choose this way. This option will not change the configuration of your \"normal\" next i18next project: Just download or sync your local translations before \"deploying\" your app. Here you'll find more information and an example on how this looks like. You can, for example, run an npm script (or similar), which will use the cli to download the translations from Locize into the appropriate folder next i18next is looking in to (i.e. ). This way the translations are bundled in your app and you will not generate any CDN downloads during runtime. i.e. Best approach: optimized for server and client side next i18next Here you'll find a blog post on how to best use next i18next with client side translation download and SEO optimization. There's also an i18next crash course video. ð𥳠Conclusion ðð As you see i18n is also important on server side. I hope youâve learned a few new things about server side internationalization and modern localization workflows. So if you want to take your i18n topic to the next level, it's worth to try i18next and also Locize. ð"},{"slug":"angular-i18next","title":"Angular Localization - Unleash the full power of i18next","description":"A step-by-step guide how to implement angular-i18next into your application.","date":"2021-06-14","category":"Tutorials","thumbnail":"\/img\/blog\/angular-i18next\/title.jpg","readTime":"4 min read","searchText":"title: 'Angular Localization Unleash the full power of i18next', description: 'A step by step guide how to implement angular i18next into your application.', date: '2021 06 14', thumbnail: '\/img\/blog\/angular i18next\/title.jpg', image: '\/img\/blog\/angular i18next\/title.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'i18next', 'angular'] â ï¸ Updated note (March 2026): This post was written for Angular with NgModule (Angular v12 era). Angular has changed significantly through v13âv19. Core concepts still apply but setup details may differ. Check the angular i18next repository for the latest examples. Let's talk about internationalization (i18n) for Angular (not AngularJS, not Angular 2, just Angular ð). When it comes to JavaScript localization, one of the most popular frameworks is i18next. One of the most famous Angular extension for i18next is angular i18next. It was created back in April 2017 by Sergey Romanchuk. TOC So first of all: \"Why i18next?\" Let's get into it... Prerequisites ð𥳠Congratulations ðð So first of all: \"Why i18next?\" i18next was created in late 2011. It's older than most of the libraries you will use nowadays, including your main frontend technology (React, Angular, Vue, ...). â¡ï¸ sustainable Based on how long i18next already is available open source, there is no real i18n case that c
40ould not be solved with i18next. â¡ï¸ mature i18next can be used in any javascript (and a few non javascript .net, elm, iOS, android, ruby, ...) environment, with any UI framework, with any i18n format, ... the possibilities are endless. â¡ï¸ extensible There is a plenty of features and possibilities you'll get with i18next compared to other regular i18n frameworks. â¡ï¸ rich Here you can find more information about why i18next is special and how it works. Let's get into it... Prerequisites Make sure you have Node.js and npm installed. It's best, if you have some experience with simple HTML, JavaScript and basic Angular, before jumping to angular i18next. Getting started Take your own Angular project or create a new one, i.e. with the Angular cli. To simplify let's remove the \"generated\" content of the angular cli: angular cli We are going to adapt the app to detect the language according to the userâs preference. And we will create a language switcher to make the content change between different languages. Let's install some i18next dependencies: i18next angular i18next i18next browser languagedetector Let's modify our to integrate and initialize the i18next config: Ok, now let's update the : You should now see something like this: app 1 Nice! So let's add an additional text, with an interpolated unescaped value: Do not forget to add the new key also to the resources: Does it work? Of course! app 2 And thanks to the language detector, you can also try to switch the language with the query parameter : language detector Language Switcher We like to offer the possibility to change the language via some sort of language switcher. So let's add a footer section in our file: And we need also to update the file: app 4 𥳠Awesome, you've just created your first language switcher! Thanks to i18next browser languagedetector now it tries to detect the browser language and automatically use that language if you've provided the translations for it. The manually selected language in the language switcher is persisted in the localStorage, next time you visit the page, that language is used as preferred language. Separate translations from code Having the translations in our code works, but is not that suitable to work with, for translators. Let's separate the translations from the code and pleace them in dedicated json files. i18next locize backend will help us to do so. What is Locize? How does this look like? First you need to signup at Locize and login. Then create a new project in Locize and add your translations. You can add your translations either by importing the individual json files or via API or by using the CLI. Adapt the file to use the i18next locize backend and make sure you copy the project id from within your Locize project: The app looks still the same, but the translations are now completely separated from the app and can be managed and released separately. save missing translations Thanks to the use of the saveMissing functionality, new keys gets added to Locize automatically, while developing the app. Just pass in the i18next options and make sure you copy the api key from within your Locize project: Each time you'll use a new key, it will be sent to Locize, i.e.: will result in Locize like this: missing key ð but there's more... Thanks to the locize lastused plugin, you'll be able to find and filter in Locize which keys are used or not used anymore. With the help of the Locize plugin, you'll be able to use your app within the Locize InContext Editor. Lastly, with the help of the auto machinetranslation workflow, new keys not only gets added to Locize automatically, while developing the app, but are also automatically translated into the target languages using machine translation: Locize autotranslate use them in : Automatic machine translation: Locize autotranslate Last used translations filter: react localization InContext Editor: in context Caching: react localization caching Merging versions: overwrite version ð§âð» The complete code can be found here. There's also an i18next crash course video. https:\/\/youtu.be\/SA 9i4TtxLQ ð𥳠Congratulations ðð I hope youâve learned a few new things about i18next, angular i18next and modern localization workflows. So if you want to take your i18n topic to the next level, it's worth to try Locize. The founders of Locize are also the creators of i18next. So by using Locize you directly support the future of i18next. ð"},{"slug":"give-vue-i18n-more-superpowers","title":"Give vue-i18n more superpowersâ","description":"Supercharge vue-i18n with locizer + Locize: async loading, language detection, saveMissing, and automated translation workflows.","date":"2021-06-08","category":"Tutorials","thumbnail":"\/img\/blog\/give-vue-i18n-more-superpowers\/title.jpg","readTime":"3 min read","searchText":"title: 'Give vue i18n more superpowersâ', description: 'Supercharge vue i18n with locizer + Locize: async loading, language detection, saveMissing, and automated translation workflows.', date: '2021 06 08', thumbnail: '\/img\/blog\/give vue i18n more superpowers\/title.jpg', image: '\/img\/blog\/give vue i18n more superpowers\/title.jpg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'vue'] Itâs joyful to work with Vue.js. The design is elegant and the robust first party additions which can be coupled with, make building browser apps a pleasure. The most famous i18n plugin for the progressive JavaScript framework Vue.js is probably Vue I18n. Kazuya, thank you for this great i18n plugin! TOC New versions So how does a basic vue i18n setup look like? Let's get into it... Is it possible to make a vue 18n setup even better? Prerequisites Getting started Language Switcher Component interpolation and directive Where are the additional superpowers? How does this look like? save missing translations ð but there's more... ð𥳠Congratulations ðð New versions Beside templates, directives, data binding, event handling, etc... with v3 Vue.js is now introducing also Composition API, Teleport, Fragments... and Suspense. The appropriate version to Vue.js v3 for Vue I18n is v9. So how does a basic vue i18n setup look like? Let's get into it... Prerequisites Make sure you have Node.js and npm installed. It's best, if you have some experience with simple HTML, JavaScript and basic Vue.js, before jumping to vue i18n. Getting started Take your own Vue.js project or create a new one, i.e. with the vue create cli command. Let's install the vue i18n depen
40dency: Let's prepare the file: Now let's create a first component : ...and use that component in : You should now see something like this: Language Switcher Now we will create a language switcher to make the content change between different languages. 𥳠Awesome, you've just created your first language switcher! Component interpolation and directive Now let's try component interpolation and the translation directive: ...and add the new keys to your translations: This should be the result: Where are the additional superpowers? Let's meet locizer... locizer is a lightweight module to access data from your Locize project and use that inside your application. What is Locize? How does this look like? First you need to signup at Locize and login. Then create a new project in Locize and add your translations. You can add your translations either by importing the individual json files or via API or by using the CLI. Having the translations in your code file works, but is not that suitable to work with, for translators. Using Locize separates the translations from the code. Having imported all translations should look like this: Done so, we're going to install locizer. Let's create a dedicated file: The translations are now loaded asynchronously, that's why we export the and use it in your : Additionally, we make use of the new Suspense functionality of Vue.js. Let's create a new file: i.e. : And use that in your file: Now, as long your translations gets loaded you'll see the fallback template: If your browser is configured with german language, you may now have seen the language automatically was set to german by default. This is because of the language detection feature of locizer. You can configure the language detection with other options By default the language detection also is looking for the query parameter lng, so you can also type this url to test this: http:\/\/localhost:8080\/?lng=de save missing translations I wish newly added keys in the code, would automatically be saved to Locize. Your wish is my command! Extend the file with the Locize api key and the handleMissing function: And use it in the component: Now, if you add a new key in your templates, : It gets automatically saved to Locize: Lastly, with the help of the auto machinetranslation workflow, new keys not only gets added to Locize automatically, while developing the app, but are also automatically translated into the target languages using machine translation: ð but there's more... Caching: Merging versions: ð§âð» The code can be found here. ð𥳠Congratulations ðð I hope youâve learned a few new things about Vue.js localization and modern localization workflows. So if you want to take your i18n topic to the next level, it's worth to try Locize. ð"},{"slug":"new-locize","title":"What's new in Locize","description":"A rundown of the modernized UI and key new CAT features in the updated Locize app.","date":"2020-12-02","category":"Product","thumbnail":"\/img\/blog\/new-locize\/title.jpg","readTime":"2 min read","searchText":"title: \"What's new in Locize\", description: 'A rundown of the modernized UI and key new CAT features in the updated Locize app.', date: '2020 12 02', thumbnail: '\/img\/blog\/new locize\/title.jpg', image: '\/img\/blog\/new locize\/title.jpg', category: 'Product', tags: ['localization', 'product'] A lot of work may be virtual now, but that doesnât mean weâve slowed down! In fact, we spent the last months working on a new Locize version with a bunch of fabulous updates. Here's a run down of some of the most important tweaks that make a huge difference. Modernized UI First of all, you will notice Locize looks different. The layout is a little less angular and a little more rounded. There are more icons and more charts. This makes it look friendlier, simpler, and tidier. The layout is composed by different cards. Each card has optional additional functionality in the top right corder. Different parts The application was rewritten from the ground up and now splits into two major parts. Project pages The project pages consists of details and actions about your versions, languages, namespaces, etc. There's also an optional card about your orders and another card about your branched projects (crowdbased) We moved everything related to the development to a dedicated page, containing development settings, api keys and relevant metrics. There's also the possibility to configure a webhook or integrate slack. CAT pages The other major part is the new computer aided translation tool â short CAT. The new CAT tool comes with three separate views, for: Global overview With global imports and exports, add, copy or delete keys, search and filter. Translation Focus on translating, assisted by machine translation (MT), smart translation memory (TM), consistency checks, and more. InContext editing The InContext Editor just needs a little script (Locize or locizify) added to your site, so it can exchange information (clicked text, saved changes, etc.). Find more information in the documentation New features The new Locize app does not only come with a new fresh look â but also brings
40you a ton of new awesome features, like the review workflow or the key history. Review You can enable the review workflow for specific languages. This way each time someone changes a translation, it will start a review workflow. The actual value will not be changed until someone will accept one of the translation proposals. History The last translation changes are audited per key. Summary To make it short â every aspect of the old experience was analyzed and improved to give you an even better experience. The only thing we did not change was the price. You get all the new features without any increase of costs. If you got any questions, feedback or suggestions â we would love to hear from you at [email protected]."},{"slug":"a-tale-of-the-last-10-years-in-web-development","title":"A tale of the last 10 years in web development","description":"A fictional journey through jQuery, Angular, React, Vue, and how i18next carries across them all.","date":"2018-08-28","category":"Engineering","thumbnail":"\/img\/blog\/a-tale-of-the-last-10-years-in-web-development\/title.png","readTime":"5 min read","searchText":"title: 'A tale of the last 10 years in web development', description: 'A fictional journey through jQuery, Angular, React, Vue, and how i18next carries across them all.', date: '2018 08 28', thumbnail: '\/img\/blog\/a tale of the last 10 years in web development\/title.png', image: '\/img\/blog\/a tale of the last 10 years in web development\/title.png', category: 'Engineering', tags: ['localization', 'engineering'] This is a work of fiction. Names, characters, businesses, places, events, locales, and incidents depicted in this story are either the products of my imagination or used in a fictitious manner. Any resemblance to actual persons, living or dead, or actual events is purely coincidental. An Introduction This story is based on a true story of each of us. Over the past 10 years, many web developers have experienced such a journey. Starting from jQuery, passing through Angular, using React and streak Vue. When reading, âdarker areasâ of the beginnings of single page applications (SPA) are undergone. This can cause unwanted nervous muscle twitches from the past. For risks and side effects read the package leaflet (there is none) and consult your doctor or pharmacist (I donât know if they could understand) . Once upon a time, in spring 2008 in a small company in Sheffield, there was a software developer called Dorian. He was working on a desktop application built with Microsoft .NET. Not far from there, in Rotherham, Shaun worked in a similar company as web developer. Both companies were very similar and sometimes even had the same customers. So it happened that the top management of both companies met and they merged. Patty, who had been promoted to development manager, had the task to assemble a new web development team. After she had already inducted Shaun into her team, she also found Dorian and noticed a possible team change. She beat him an offer and Dorian joined straight the team in Rotherham. For Dorian, professional development with Javascript was something new. Heâd learned Javascript during his studies, but heâd used it rather than animate a website. Shaun, on the other hand, even showed him how to handle node.js and linux and mac. Dorian had always only worked with Windows so far. And from Javascript in the backend he was quite astonished and surprised. Patty saw the first weeks relaxed and felt that she was uniting these two, the right thing. Soon it was time to productively implement a new web application. Together, they decided to try to use node.js in the backend and jQuery in the frontend. They did choose jQuery because the support of the community was great, it made DOM manipulation painless, played well with AJAX, made basic animation a piece of cake, had a lot of plug ins, etc⦠Since the web application was not only for English speaking users, they used jquery i18next as an internationalization (i18n) library. To see how this could look like click here . After about 3 to 4 years, the first signs of weakness of the web application began. There were overusing big\/clever plugins, had big\/complex files and polluted the global namespace. The heavy use of long chains of selectors ( âul leftnav li p a.currentâ ) made the code brittle. They started to lose track of whatâs where because of the neat idea to use .data() to attach data to the DOM elements, to track the page state. Everything started being slow⦠Patty had new major features in the pipeline. But the team, which had problems to grow, recommended a refactoring phase. Quickly the team got support from 2 freelancers, Serge and Martina. Patty introduced the new ones as âthe expertsâ. Serge and Martina had Angular know how and persuaded everyone to replace the jQuery solution with Angular. Their arguments sounded promising: Instead of unobtrusive Javascript with selectors, now declarative templates. From semantic HTML, to semantic models. Instead of classic separation of concerns (HTML, CSS, JS), the usage of MVC pattern. No plug ins but directives. $scope instead of closure. Instead of manual DOM manipulation and binding, modern data binding. Less âspaghettiâ code and more dependency injection. From unorganized, to modular service architecture. Because i18next was not only built for jQuery, they could use ng i18next and at least keep the same configuration and use the same localization files as before! To see how this could look like click here . During the next 3 to 4 years, Patty added more freelancers and contractors to the team. Shaun and Dorian started to recognize that making the simplest features work seems a struggle. There were more and more performance and complexity issues. Directives, services and filters theoretically were available, but ultimately, everything was built around controllers and their two way bound $scope . Angular seemed to be fine for the beginning, when it was a simple application, but as the frontend application grew in complexity, this led to the scope soup problem amongst other issues. Additionally, the fear of Angular 2âs release was on the horizon. By trying some samples, Shaun s
40aid: âIs this still Angular?â In the meantime, the backend had turned into a solid foundation based on DDD, CQRS and event sourcing. During a late night beer, Dorian told Shaun about React and Redux. He said that when he read about React, Redux and FLUX he immediately felt that this was a natural fit to the existing backend. Finally, they convinced Patty to rewrite the whole frontend with these arguments: react Angular was a framework vs. React was a library the more flexible state management with Redux virtual DOM, one way data flow, PropTypes and a well defined component lifecycle the obvious natural fit with their backend single source of truth JSX, a natural evolution of Javascript React has faster learning curve. It feels like learning faster. As with the last technology change, this time there was an i18next option. Just used the new react i18next library and still the same localization files! To see how this could look like click here . Around the year 2018, many freelancers and contractors were no longer in the team. Instead of them now younger developers started to ask for something new⦠â React is ok, but whatâs about Vue ?â Shaun and Dorian organized a little technical session and they explained that React and Vue had more similarities than differences: both were fast and lightweight both had a component based architecture both used a virtual DOM both could be dropped into a single HTML file or be a module in a more sophisticated webpack setup both had separate router and state management libraries Long talk short, the session ended with the following sentence by Shaun: âOk, letâs try to write our web app in Vue and create a PoCâ¦â Whether theyâve really switched to Vue, we do not know, but what we know is that if thatâs the case, then theyâre sure to use vue i18next or a similar library. To see how this could look like click here . i18next was right: âlearn once â translate everywhereâ! Technologies and libraries come and go, but i18next remains! Post credits scene There are voices who say that they have also replaced their i18next xhr backend with that of Locize. To see how this could look like look at this video ."},{"slug":"unleash-the-hidden-superpowers-of-react-intl","title":"Unleash the hidden superpowers of react-intl","description":"Make react-intl JSX cleaner with babel macros, and connect it to Locize for continuous localization.","date":"2018-08-21","category":"Tutorials","thumbnail":"\/img\/blog\/unleash-the-hidden-superpowers-of-react-intl\/title.png","readTime":"4 min read","searchText":"hideCta: true, title: 'Unleash the hidden superpowers of react intl', description: 'Make react intl JSX cleaner with babel macros, and connect it to Locize for continuous localization.', date: '2018 08 21', thumbnail: '\/img\/blog\/unleash the hidden superpowers of react intl\/title.png', image: '\/img\/blog\/unleash the hidden superpowers of react intl\/title.png', category: 'Tutorials', tags: ['localization', 'tutorials', 'react'] Let images speak to see what you will get: We do not like this clutter: While react intl works awesome having those FormattedMessage everywhere does not really help keeping your code nice and readable. Wouldnât it be nicer you just could write: babel macros to the rescue You could easily write a babel plugin to transform the above simplified markup to the needed react intl FormattedMessage. But there is a better way using Kent C. Dodds babel macros (https:\/\/github.com\/kentcdodds\/babel plugin macros). There comes a big advantage with using macros (beside they are super simple to create) you can use those with applications created with create react app without ejecting (on time of writing needs an alpha build v2.x.x). A babel macro is basically just a function that gets a reference of the nodes using the macro: We wonât go through all the details of the macro used to transform the simpler markup, but you can checkout the code here: https:\/\/github.com\/locize\/locize react intl example\/blob\/master\/src\/intl.macro.js You can use the macro like: The macro will transform it to the react intl FormattedMessage: Plurals and Select We could add some more macro magic to also simpler plurals and selects: For more options (like nesting components) have a look at the sample usages: https:\/\/github.com\/locize\/locize react intl example\/blob\/master\/src\/ComponentUsingMacro.js Now after adopting all the features of the demo project you will be able to:
40split translations into multiple files using an in context editor loading translations from CDN detecting the user language automatically add new missing strings to your translation project updating changed strings in reference language submitting the description to translation context setting last used information so you can safely remove keys not used any longer From internationalization to localization While the first part focused on helping developers writing nicer jsx markup we now will focus on helping your translators by making their work easier. One of the most important things in our fast paced times is implementing a fast feedback loop, which is also recommended by all the common âAgileâ methodologies. So letâs go a step further: From internationalization to continuous localization We like to innovate the localization process by breaking the old slow loop of exporting extracted translations, passing them to translators and importing them back again. This old process does not fit into a modern development environment using continuous development and agile methods. What we want: New content in your application should be immediately available in your translation management tool for your translators and newly finished translations should be passed down to the application without a developer needing to add a file to the repository or accepting a PR from the translation management. Connecting your application to your translation management In this sample we will use https:\/\/www.locize.com as our translation management tool, as it exposes all the needed functionality to bring localization to the level of continuous localization. There is the locizer script available to connect your application with the translation project: https:\/\/github.com\/locize\/locizer With it you can load translation files, save or update translation segments. Step 1: We need a way to extend react intl components during development This should be rather easy: Now letâs learn what the supportLocize() is: Step 2: Let the component send new content to the translation service In our code we have FormattedMessages like in regular react intl projects but we consume our overridden component during development: Our extended component will take those props and create new translation segments on Locize using the id and defaultMessage Based on the defaultMessage already exists in the translations catalog or not, or the defaultMessage has changed we use the locizer functions to create or update the translation segment in the source language. Awesome, now every time we add a new or change a those values get added or changed in your translation project immediately. Step 3: Directly load translations By overriding the we could use the locizer script to directly load the translations that get published to the localization CDN provided by Locize. What the component basically does is taking a prop namespace to load the translation file and the needed intl locale data: The full code is very simple you can find the demo repository here: https:\/\/github.com\/locize\/locize react intl example\/blob\/master\/src\/locize\/index.js L32 So this not only enables us to load one translation catalog, but by using that IntlProvider we could load multiple files and making translation a lot easier by splitting them into multiple smaller files. Step 4: Enable translations inside the context of your application The integration of the Locize editor is very simple: Now you can open your website appending the querystring param and you will see the in context editor. Summary You see internationalization is done rather easily and localization hasnât to be harder. With the right tools you can not only keep your development to translation cycle short but you can also improve the quality, save time and money. You can find the full sample here: https:\/\/github.com\/locize\/locize react intl example If you're on Next.js App Router with rather than , the equivalent sample is locize next intl example: same Locize wiring (locizer + saveMissing + InContext editor), Next.js shape. Take the chance and try it yourself locize.com comes with a 14 day free trial."},{"slug":"vue-js-from-internationalization-i18n-to-localization-l10n-and-back-again","title":"vue.js - from i18n to localization (l10n)","de
40scription":"Explore how Vue.js supports global reach with i18n and adapts to local nuances through l10n.","date":"2018-07-05","category":"Tutorials","thumbnail":"\/img\/blog\/vue-js-from-internationalization-i18n-to-localization-l10n-and-back-again\/title.jpeg","readTime":"4 min read","searchText":"hideCta: true, title: 'vue.js from i18n to localization (l10n)', description: 'Explore how Vue.js supports global reach with i18n and adapts to local nuances through l10n.', date: '2018 07 05', thumbnail: '\/img\/blog\/vue js from internationalization i18n to localization l10n and back again\/title.jpeg', image: '\/img\/blog\/vue js from internationalization i18n to localization l10n and back again\/title.jpeg', category: 'Tutorials', tags: ['localization', 'i18n', 'tutorials', 'vue'] What is internationalization?!? Internationalization is the designing of a product in such a way that it will meet the needs of users in many countries or can be easily adapted to do so. Internationalization might mean designing a website so that when it is translated from English to Spanish the layout still works, since many words in Spanish have more characters and therefore take up more space on the page in Spanish than in English. quote by: https:\/\/www.investopedia.com\/terms\/i\/internationalization.asp Open Source to the rescue Thanks to the restless open source community you wonât have to reinvent an i18n solution. Just to give you an idea letâs mention two mature solutions to translate your vue.js app here: vue i18n by kazuya kawaguchi (@kazupon on github) Made by @kazupon a core contributor of vue.js Easy to get started with powerful enough for most use cases (lacks some features like proper pluralization for languages having multiple pluralforms or possibility for gender specific translations) learn more reading the documentation vue i18next by Claudio Romano (@panter on github) based on i18next: learn once, translate everywhere extendable, powerful i18n features plugins for language detection, loading, caching, ⦠learn more reading the documentation and the i18next documentation for translation functionalities like plural, context, ⦠From internationalization to localization As you can see in the getting started guide of vue i18n making your vue.js application fit for translation is not as daunting as it seemed first. Honestly itâs rather easy. Now let us show you how easy the next step could be doing the same for localization. After enabling the developers itâs time to enable your localization team to translate your product. Step 1: Creating a fast translation loop, continuous localization Our goal is to extend vue i18n to use its existing missing function to directly send new texts to the translation managment tool and to directly load translations from there. This enables the localization team \/ translators to start with translations immediately plus keeps a fast feedback loop by having the translations in development without having to export and copy those files from the translation management to the codebase. To make this magic happen we will use locize.com as our weapon of choice: Locize is a new online service that offers true continuous localization. quote by: https:\/\/alternativeto.net\/software\/locize\/ Itâs time for some code, show me your code First we will need to add the provided locizer script to our page to connect the Locize translation management with our code: Now letâs use the new script to automatically detect the user language and to load the translations from Locize: So now weâre already loading the translations from the Locize CDN directly from our project. To switch language only append to your url (for more options have a look detection options). Our translators could easily add new languages, translate the content or change existing content. Time to have new paths sent to Locize automatically Just use the existing missing function of vue i18n and pipe that call to the locizer script: Awesome. Now we have our code connected with our translation management. Developers could create new content that is automatically passed to the translation management. Translators could do their job without having to beg for latest source files and do not need to send latest translations to development and wait for those files to be integrated into the latest build. The power of true continuous localization Step 2: Enable translations to be in high quality Localization is hard. Even harder if you have to guess the context during translations. So lets improve this by enabling translations directly inside your vue.js app. To add the incontext editor we will need to add an additional script first: A little configuration: Now open your website with and you will see the incontext editor. While turned on you can click on any text element on your page to directly jump to it and make the initial translation or the changes needed. Summary You see internationalization is done rather easily and localization hasnât to be harder. With the right tools you can not only keep your development to translation cycle short but you can also improve the quality, save time and money. You can find the full sample here: https:\/\/github.com\/locize\/locize vue i18n example Take the chance and try it yourself locize.com comes with a 14 day free trial. Prefer using vue i18next? Doing the same is easier by just using the i18next plugin system. Simply add https:\/\/github.com\/locize\/i18next locize backend and the editor https:\/\/github.com\/locize\/locize editor to i18next. DONE."},{"slug":"locize-double-win-2018-for-translation-software","title":"Locize - Translation Software Distinguished by Platform for SaaS Reviews as a Great User Experience and Rising Star for 2018","description":"FinancesOnline recognized Locize with the Great User Experience and Rising Star awards for 2018.","date":"2018-04-30","category":"Company","thumbnail":"\/img\/blog\/locize-double-win-2018-for-translation-software\/title.png","readTime":"2 min read","searchText":"title: 'Locize Translation Software Distinguished by Platform for SaaS Reviews as a Great User Experience and Rising Star for 2018', description: 'FinancesOnline recognized Locize with the Great User Experience and Rising Star awards for 2018.', date: '2018 04 30', thumbnail: '\/img\/blog\/locize double win 2018 for translation software\/title.png', image: '\/img\/blog\/locize double win 2018 for translation software\/title.png', category: 'Company', tags: ['localization', 'company'] Efficient localization need not to be expensive, disorganized, and time consuming for development and localization teams. We designed Locize with this core ideas in mind, and a popular software review platform has recently recognized our efforts and affirmed that we have succeeded in our endeavor. FinancesOnline recently distinguished Locize with the Great User Experience and Rising Star awards for 2018 due to our localization and internationalization softwareâs capability to satisfy the large demands of global businesses. user experience 2018 Locize earned FinancesOnlineâs Great User Experience award under their best translation software for our offering an incredibly pleasing to use software for continuously localizing all kinds of languages and s
40oftware. Project versioning for easy tracking of file changes, multiple file management and project progress tracking through the dashboard, and third party integrations are some of the factors that contributed to this award. Their experts also praised our platformâs flexibility and responsiveness reflecting all translations on oneâs website by simply embedding a single line of code, a feature that makes Locize among the best translation software competitors. This also negates the need for manual inputting of all translations. rising star 2018 The FinancesOnline review team also regarded Locize as a Rising Star for 2018 due to our highly positive traction with clients. It isnât a surprise to see our software receive this distinction after FinancesOnline wrote positive remarks in their Locize review such as âcost effectiveâ , âalways safeâ content thanks to our two factor authentication, and accelerated and streamlined localization processes."},{"slug":"is-your-software-ready-for-localization","title":"Is your software ready for localization?","description":"Verify if your software is ready for localization with the software localization monopoly.","date":"2018-02-23","category":"Guides","thumbnail":"\/img\/blog\/is-your-software-ready-for-localization\/title.png","readTime":"5 min read","searchText":"title: 'Is your software ready for localization?', description: 'Verify if your software is ready for localization with the software localization monopoly.', date: '2018 02 23', thumbnail: '\/img\/blog\/is your software ready for localization\/title.png', image: '\/img\/blog\/is your software ready for localization\/title.png', category: 'Guides', tags: ['localization', 'guides'] So you want people from all around the world to use and understand your software... ...but how to achieve that? Which format should I use? Think about the workflow of exporting strings of the software, having them translated and then importing them back into your software. This will give you many ideas on how to structure your strings. Sometimes the used library already pretends a format. For web projects for example this can be: JSON (i.e. used by i18next) ICU Message syntax (i.e. used by formatjs) ...and more, see the JavaScript localization guide â¡ï¸ Looking for the bigger picture? See our software localization service page. For mobile projects for example this can be: Localizable.strings (i.e. used by iOS) XML String Resource (i.e. used by Android) ... For system apps for example this can be: Java properties files (i.e. used by Java) ResX files (i.e. used by .Net) ... Do you hardcode text strings in the source code? Resource files should store all text used in the software; do not leave text strings hardcoded! Just don't! Can the order of variables in localized strings be changed? Implement a token system to ensure nouns, verbs, etc. can be placed in unique order by language. Different languages needs to know more information about the context. For example for pluralization or gender. The Italian language for example relies on gender. The words in the sentence change depending on whether you're talking about a man or a woman. Polish suppose you have a singular and then you have a different plural depending on whether the number of things ends with 2, 3 and 4 or some other digit. And Romanian need a different plural for any group of objects greater than 20. Does the interface allow for long translations? What about long translations in areas with single line text? Are there areas with multi line text in your software? Sentences that take five syllables in English actually take a whole two paragraph description in some other language. Do you use unique string IDs? Unique string IDs help keep development, translation and QA teams on the same page. Another reason for this is: if you have for example a text in English that is visible in 2 different places on your UI, but is potentially translated differently in other languages (because it fits better). What about fonts? Who selects their types and sizes in the software? Both localization and development teams should select fonts as a cooperative effort. And how do you decide on the proportion of fonts? While fonts for North American and European languages should be \"Proportional\", \"Monospace\" is the right type for Asian languages. Are the fonts compatible with special characters for all languages? Different languages, different needs: for special characters, word order, even numbers. How are date, time, currency, and numbers dis
40played? Allow date, time, currency, and numbers to be displayed with differing figures and number separators by language or even region. Make sure the date format is right because Americans do month\/day\/year Brit day\/month\/year and by the way in America the week starts on a Sunday and in Britain the week starts on Monday. Europe wants 24 hour clocks and America wants 12 hour clocks. Regarding numbers, here a little list: numbers source What encoding do you use for your text assets? Choose an encoding that supports all target languages. If you don't know, just choose UTF 8. If you want to know Why UTF 8 is the best encoding? read this article. By the way, to tell apart assets intended for a particular locale use ISO 693 1 & 3166 1 language and country codes to mark assets by locale. Do the art assets of your software UI have text? Be ready to swap art assets if they contain legible text. Sometimes even if there is no legible text you may want to adapt the art asset (i.e. an image) because of cultural reasons. There are some libraries that can help with this issue i.e. Fragment replacement for links and images Did you put the original text through a spelling, grammar, and style check? Prevent back and forth rechecking that may stall the whole process. As an alternative you should be thinking of making some sort of Continuous Localization. With Continuous Localization you can take care of the translations from the first day and keep up with changes with ease. The process of translation and development are separated. Do you use a tracking system? Tracking every change on localizable content can be important to ensure that no content will be left behind when distributing your software. For certain projects or industries it's important to know which translator has done what change for auditing reasons. Some translation management systems offer a dedicated history feature. This empowers you to prove anytime when a content fragment was changed. What file formats are you sending for translation work? JSON, XML (or a derivative format i.e. XLIFF) is preferred over plain text or Excel files. Even better are localization management systems that offers a completely integrated approach. Where are the localization assets? Store localization assets in an easy to access location, for swift access, import and export. With a proper Continuous Localization solution translations can be updated without the need to release an update of your app. For example: translations deployed to a CDN and consumed from your application. Do you intend to have the texts translated into more than one language? Process resource files into separate language ones so all translators can work in parallel. A good localization management solution can really help here. All team members can collaboratively work in parallel. In this way, you can get to your objective in a faster way. How do you track which language is fully translated? To say it in one sentence: \"Start thinking about the localization process early!\" The biggest mistake one can do is looking on localization as itâs only based on instrumenting your code and extract texts into resource files so you can translate them later. You should keep full overview about what is translated and what not, especially if you order translations from the translation providers, where you also should keep track of your open orders. What do you say now? Are you ready to \"play\" software localization monopoly? Don't worry, Locize can help! Watch the demo video to learn more: Demo video Locize removes the pain in the translation process. No more delays in shipping your software because of missing translations. Translators can keep up with changes from day one. The continuous localization process keeps up with your demanding business."},{"slug":"8-signs-you-should-improve-your-localization-process","title":"8 signs you should improve your localization process","description":"Eight warning signs that your localization workflow is slowing you down, and how to fix it with continuous localization.","date":"2017-08-15","category":"Guides","thumbnail":"\/img\/blog\/8-signs-you-should-improve-your-localization-process\/title.png","readTime":"4 min read","searchText":"title: '8 signs you should improve your localization process', description: 'Eight warning signs that your localization workflow is slowing you down, and how to fix it with continuous localization.', date: '2017 08 15', thumbnail: '\/img\/blog\/8 signs you should improve your localization process\/title.png', image: '\/img\/blog\/8 signs you should improve your localization process\/title.png', category: 'Guides', tags: ['localization', 'guides', 'workflow'] Very often, when you're engrossed in the everyday work, you do not realize how easily your localization process could be improved. For this reason, it is important to me to show you the following 8 warning signs you should look out for: 1. Waste of time Are you mailing translation files around the world? Always struggling with this translation files? waste Other people ask for the resource files to be translated and you hand them out and deep in your mind you know there will be some last minute changes the day before release and even more changes after release. Some time later (days or weeks) some translated files lands in your inbox and you copy them to your repository... But there are already a lot of changes... Some terms are not used anymore others are new and not yet translated and others are modified by the developers in the meanwhile. 2. Waterfall process Are you trying to switch the development process to a more agile approach but the localization process does not fit? Is there no time to translate during the development iteration or sprint? process By implementing more SaaS (Software as a Service) products today's organizations start to introduce CI\/CD pipelines (Continuous Integration \/ Continuous Deployment). Developers focu
40ses on instrumenting the code with the help of some i18n libraries and extract texts into resource files so someone can translate them later. Normally during a development iteration or sprint there is no time to translate the resources. Thatâs why some organizations opt to add an extra step to the process after which no text resource may be added, edited, or deleted. This âfreezeâ period gives technical writers and translators the necessary time to work. The more text needs to be handled the longer this period while take. This process slows down the release of the software in all languages quite a bit and will result in not really doing a continuous deployment process anymore. 3. Missing context Are the translated texts too long? Do you feel the translator did not understand what the product is? context By handing over the resource files to the translators, it is very difficult for them to imagine the translated texts in the real product. That's why very often the translated texts feels wrong when imported back to the product. Doing proper translations needs more information by providing the context or even better by being done incontext. 4. Hard translation management Are translation texts suddenly deleted while translating? Is the format of the text corrupt after translating? translation Translators and technical editors are humans too. Not only the lack of technical know how (html or markdown formatting, etc...) but also the power of their tooling is important and crucial. The worse the tooling the greater the danger of getting corrupt texts. 5. Poor integration Do you wish using the same localization process for your product and other systems simultaneously, like your marketing website? integration Mostly the product development and the marketing department are split in multiple teams. In that way the localization process evolves in different ways. Not having a central team being responsible for offering internationalization libraries, apis and localization guidelines makes it difficult to find synergies across different products and teams. 6. Locked in Do you have troubles in finding open internationalization libraries compatible with your existing resource files or vice versa find a localization solution compatible with your internationalization library? locked Very often the localization process enforces to develop very customized tools and helper scripts if not standardized or at least based on open specifications, formats and protocols. 7. Unclear project progress Are your resource files all fully translated? What is missing? What is the expected effort to complete? progress Not having a centralized collaborative translation management system that is actively used by developers and translation editors makes it very difficult to forecast when a translation is fully translated and to plan its release. 8. Expensive Are your translation orders too expensive? Do you have multiple dedicated personal resources? costs There is not only the employee salary, but also the wasted time \"waiting\", proofreading and correcting the translated resources. And finally, each delay of your time to market costs a lot of money. Advice infographic As we learned, localizing software releases is a nightmare and no translation tool really supports product managers, developers and translators well in software translations with continuous changes and additions. Someone started to work on locize.com to bridge the gap between translation and development. Watch the introduction video to learn more. Introduction video Locize removes the pain in the translation process. No more delays in shipping your software because of missing translations. Translator could keep up with changes from day one. The continuous localization process keeps up with your demanding business. Stop waiting start localizing."},{"slug":"how-locize-leverages-serverless","title":"How Locize leverages serverless","description":"Why Locize chose a serverless architecture on AWS, and how we structure our Lambda functions and tooling.","date":"2017-06-22","category":"Engineering","thumbnail":"\/img\/blog\/how-locize-leverages-serverless\/title.png","readTime":"4 min read","searchText":"title: 'How Locize leverages serverless', description: 'Why Locize chose a serverless architecture on AWS, and how we structure our Lambda functions and tooling.', date: '2017 06 22', thumbnail: '\/img\/blog\/how locize leverages serverless\/title.png', image: '\/img\/blog\/how locize leverages serverless\/title.png', category: 'Engineering', tags: ['localization', 'engineering', 'serverless']
40slides Why we choose serverless? why When we started with Locize we did not know how fast it would scale⦠serverless means we didnât need to make that choice. The serverless architecture scales with our business model. The next argument is, we hate maintaining and operating infrastructure. We believe in NoOps. Here serverless saves not only computing power but human resources too. Finally you may ask: Why not a PaaS solution? = We are working with PaaS solutions since early 2011 and we always had the dream to have a platform where you really pay only when something is used (i.e. call of a function, query of a table, etcâ¦) so you can fully concentrate to the business code. And last but not least: serverless is really cool! Why we choose AWS? why aws We think AWS is the only production ready FaaS provider (and more) that works out of the box and scales like you expected. Itâs designed with an API first approach, so everything can be automated. We think AWS has in mind a possible future where you can also run functions directly on the edge (directly on hardware). Additionally AWS has not only lambda but completes the serverless offering with: API Gateway DynamoDB Simple Storage Service (S3) CloudFront Simple Email Service (SES) and a lot more... The basic setup setup When Developers\/Translation Editors\/Managers, etc⦠goes to www.locize.app, the locize app client (which is hosted on S3 and exposed by CloudFront) is served. The client then accesses our lambda backend through the API Gateway also exposed by CloudFront. Our main working storage (DynamoDB) is then accessed by our lambda functions. Each time someone publishes (or auto publishes) a translation resource a lambda function will save that resource to S3. When published, the endusers of your product can access them via CDN edge locations offered and exposed by CloudFront too. Full Stack JavaScript full js Locize is a single language solution! Everything is JavaScript! The complete application backend, the api, the cli and other tools runs on node.js⦠and the locize app client is a modern SPA based on React and Redux. Lambda functions types Locize uses 3 different base lambda types. These are not real âAWS definedâ lambda types but we've defined these types ourself. Express express The first type is the express type. It defines RESTful APIs using the normal express framework. You see the app.js file looks like a normal express based project. But at the end of the file you see that if this file is executed directly (like ) it will start to listen on port 3000 and can be used to test locally. But if required by another file it exports the configured express app. For this scenario there is an additional file (lambda.js) that uses the help of the npm module âaws serverless expressâ to proxy and map the lambda function calls to http requests and responses. Async async The second type is the async type. This lambda function is triggered by other lambda functions to compute non blocking tasks. i.e. calculation of current words in project, or publishing translation resources to S3, etc⦠The key element here is that a lambda function is able to call another lambda function by simply using the official aws sdk npm module. With the help of AWS policies you can define exactly which function can be invoked. S3 event s3 The last type is the S3 event type. This lambda function is i.e. triggered by a new CloudFront log file that was saved to s3 (this feature can be enabled on CloudFront). We use this to i.e. calculate the amount of downloads or to generate statistics. Our tooling claudia js Because we have a pure JavaScript landscape weâve chosen claudia.js It automatically installs and configures a lot on AWS. From API Gateway to Lambda versioning. Claudia.js does not abstract away AWS services. Itâs really transparent and easy to understand. Thatâs why our advice is: if you want to build simple services and run them with AWS lambda, and you're looking for something low overhead, easy to get started with, and you only want to use the node.js runtime, Claudia is a good choice."},{"slug":"locizify-v2-improvements","title":"locizify v2 - improvements","description":"Whatâs new in locizify v2: unpkg CDN delivery, better key generation, merging support, fragment replacement, and more.","date":"2017-02-21","category":"Product","thumbnail":"\/img\/locize_color.svg","readTime":"2 min read","searchText":"title: 'locizify v2 improvements', description: 'Whatâs new in locizify v2: unpkg CDN delivery, better key generation, merging support, fragment replacement, and more.', date: '2017 02 21', thumbnail: '\/img\/locize color.svg', image: '\/img\/locize color.svg', category: 'Product', tags: ['localization', 'product'] Note (2026): this post is from 2017 and describes locizify v2. Current locizify is v10; if you set up locizify today, load the browser bundle of the latest major explicitly, e.g. , and check the locizify readme for current usage. We use the unpkg CDN In the past we deployed the locizify script to our own C
40DN space. While this was ok migrating over to https:\/\/unpkg.com allows us to provide you an improved usage. In the past your code was bound to the latest deployed script on our CDN. As we strongly respect semver we just were able to update the script with non breaking updates. Now as you could use the source from unpkg you're able to fix the version in your code like: full sample: New Features merging Sometimes you want to keep innerHTML of an element together to make it easier to translate. Before: Using merge: While you can set the attribute on every element you like to have this behaviour. You can also specify this globally on init: cleanup for keys With v2 we improved the key generation from content by removing unused whitespaces: Before: Using cleanup (default enabled in v2): All the unnecessary whitespaces get removed making translation more easy. You can manually toggle this off or ignore it for certain tags: Fragment replacement for links and images You will find and to be a key in your translations it's value can be replaced to eg. a de.png for german (all other languages will fallback to a.png) Translate other then default attributes on elements eg: for validation error messages Just add to the Array on init: You can define rules like: Migration from v1 To make v2 having the same behaviour as v1 you could change the init options like: This way you assert keys get not cleaned of whitespaces so they match the counterpart of v1."},{"slug":"localization-should-be-fun","title":"Localization should be fun","description":"Learn from our experience using Locize in our own web application, and how it made localization faster, safer, and more enjoyable.","date":"2016-11-16","category":"Engineering","thumbnail":"\/img\/blog\/localization-should-be-fun\/thumb.png","readTime":"4 min read","searchText":"title: 'Localization should be fun', description: 'Learn from our experience using Locize in our own web application, and how it made localization faster, safer, and more enjoyable.', date: '2016 11 16', thumbnail: '\/img\/blog\/localization should be fun\/thumb.png', image: '\/img\/blog\/localization should be fun\/thumb.png', category: 'Engineering', tags: ['localization', 'engineering'] Learn from our experience we made during using the Locize service on our own new webapplication. In an early stage of drafting out our plan to completely rewrite our Locize webclient we decided to use our own service to manage the content on it. There was no plan on providing it in another language then english but we strongly believed even not having the demand of translating we could profit of separating the content from the application logic. This way we could go full speed during development while working on final terminology later. As a plus we could change all the texts in production without having to deploy a new client. Another reason was we wanted to get a better feeling on how the experience is creating a new project using our service. Our goal was to get a workflow that is faster, less error prone and more fun for everyone being part of the localization process. Our past workflow To have a comparison with the updated workflow we like to describe how things got done before using Locize. If you like to direcly see how things worked with Locize just skip this section . Developers path Create a new component, page and get functionality to work Replace all texts with instrumented code (calls to translation function) Add all the new keys to the correct json file (manually resolving the nesting) Restart server to load and serve the new translations files See the json has an error fix it Restart again See that some keys are still missing add Restart again Technical editor \/ Translator path Ask developer for latest resource files Getting them a few days later start changing texts to match terminology Save the file and pass it back to development Ask for new texts getting only a file having all texts going crazy as having no idea which stuff is new...start to compare with last file Pass new texts to development ... Poor guys path tries to merge files coming from development and technical editor Goes crazy and starts searching for a new job ;) Doing agile \/ continuous localization could be hard...you can improve this by doing the steps in waterfall manner: development technical editor translations. But not only takes this a lot longer but also the problems come back as soon as development starts work on next version having semi finished texts from the technical editor. Things need to get better so lets have a look on how our experience was using Locize: Having Locize in the flow early Developing new components \/ pages we directly instrumented the code. In the early stage we still started with having the texts in code and instrument after being functional working. With getting more used to the new workflow we just removed that step and directly used to call the translation function. instrumented code Using webpacks hot module reload feature we just needed to save the file and the webapplication did it's reload magic: save missing was triggered This triggered the save missing feature which was enabled during development. So all the untranslated texts were passed automatically to our Locize project. Time to reload the new data on our Locize project using the new filter \"was created by missing\" to only show newly submitted texts: edit content Just fill the newly added keys with the content it should have press save and done. Reload the application and all the new texts are there: content loaded from Locize From here the technical editor \/ translators could change texts as needed and verify those in the test environment c
40ompletely independent of the development. Never ask for resource files again Never wait for the new texts \/ translations to be merged and deployed No need to beg your developers to change a text not even in production What happened to the poor guy ? He was not needed any longer and lost his job before having the chance to search for a new one just kidding ;) Separating development and content editing made both sides work more efficient, with less errors and a lot faster. Developers, technical editor and translators could work hand in hand without disturbing each others work."},{"slug":"continuous-development-integration-and-localization","title":"Continuous Development, Integration and Localization","description":"Discover the evolution from traditional to agile development with continuous integration and localization.","date":"2016-10-05","category":"Engineering","thumbnail":"\/img\/blog\/continuous-development-integration-and-localization-cd\/hands_world.jpg","readTime":"3 min read","searchText":"hideCta: true, title: 'Continuous Development, Integration and Localization', description: 'Discover the evolution from traditional to agile development with continuous integration and localization.', date: '2016 10 05', thumbnail: '\/img\/blog\/continuous development integration and localization cd\/hands world.jpg', image: '\/img\/blog\/continuous development integration and localization cd\/hands world.jpg', category: 'Engineering', tags: ['localization', 'engineering', 'workflow'] Past times In the past most organizations that have to write some software planned, developed and released their product in one year or even multiple year cycles. = Typical waterfall process. Every time the developer team had finished implementing the features, the product manager could start to organize and initiate the translation process. So the only thing the developers had to guarantee, was to be able to export and import text resources. That way the texts could be translated all together, by sending them to different agencies or regional market organizations, etc⦠When translations were done (after days, weeks or even months), theyâd be sent back to the product manager who forwarded them to the developers. They then had taken the translations, imported and merged them into the product, and (re )released. Status Quo Most of todayâs organizations are trying to switch the development process to a more agile approach. By implementing more SaaS (Software as a Service) products todayâs organizations start to introduce CI\/CD pipelines (Continuous Integration \/ Continuous Deployment). Developers focu
40ses on instrumenting the code with the help of some i18n libraries like: http:\/\/i18next.com\/ http:\/\/formatjs.io\/ http:\/\/airbnb.io\/polyglot.js\/ and extract texts into resource files so someone can translate them later. Normally during a development iteration or sprint there is no time to translate the resources, and not just because most people have this sort of attitude: « We are not interested in the translation process itself. » Thatâs why some organizations opt to add an extra step to the process after which no text resource may be added, edited, or deleted. This âfreezeâ period gives technical writers and translators the necessary time to work on. The more text needs to be handled the longer is this period. This process slows down the release of the software in all languages quite a bit and will result in not really doing a continuous deployment. True Continuous Deployment with Continuous Localization Because software development never stops when the first version of a product is released (bug fixes, minor updates and at some point major new versions and releases), continuously. Your localization and translation process should follow the same pattern as your software development. You should be able to deploy your translation files separated from your software so you can update and manage them independently. And if you do so, you have to make sure you can have more then one version of your translations; at least one for the current released version and one for the current development branch. That way your technical writers and translators can take care of the translations from the first day and keep up with changes with ease. By doing this it is even possible to change or add translations without shipping a new release of your software! Cool, but isnât this a little over the top⦠an extra tooling and deployment, doesnât all this just add more complexity and effort? You donât have to build this yourself!!! There is Locize ...give it a try: Register! Read more: How Locize delivers continuous localization today: the full four stage workflow (capture â translate â publish â deliver), the continuous vs traditional comparison, and the technical stack (CDN, saveMissing, AI translation, review workflow, branches\/versioning) that makes \"continuous\" actually continuous."},{"slug":"the-freedom-of-choice-i18next-polyglot-or-formatjs","title":"The freedom of choice... i18next, polyglot or formatJS","description":"How Locize works not only with i18next, but also with Polyglot and FormatJS (ICU messageformat), plus runnable example repos.","date":"2016-08-18","category":"Engineering","thumbnail":"\/img\/blog\/the-freedom-of-choice\/idea.jpg","readTime":"3 min read","searchText":"title: 'The freedom of choice... i18next, polyglot or formatJS', description: 'How Locize works not only with i18next, but also with Polyglot and FormatJS (ICU messageformat), plus runnable example repos.', date: '2016 08 18', thumbnail: '\/img\/blog\/the freedom of choice\/idea.jpg', image: '\/img\/blog\/the freedom of choice\/idea.jpg', category: 'Engineering', tags: ['localization', 'i18n', 'engineering', 'i18next'] When we started work on locize.com our localization as a service platform we basically had in mind to solve the translation process for developers using our i18n framework i18next.com. Translation Management Systems are a great help. But still there is a gap between development and translation process. Files need to be exported \/ imported \/ merged and all while new content get added to be translated. The chaos is inevitable. locize.com comes to the rescue. Itâs like a translation service on steroid directly connected to your i18next instrumented webproject. A few weeks after the successful beta launch and adding a lot of third party services to order translations directly out of your Locize project, we started wondering if we could also bring the awesomeness to other frontend internationalization frameworks like airbnbâs polyglot or yahooâs formatJS? polyglot + locize.com Our first look at polyglot revealed that the implementation is rather similar to the i18next json format only the plurals are stored in a single key and separated by . We decided to do a short spike using a node.js express server loading the resources from locize.com using its API and return a demo page using pol
40yglot to translate it. Using request to load the translations: The JSON we load from the Locize project looks like: https:\/\/api.locize.app\/897381a6 125c 40b8 9b28 2f80ae9a3612\/latest\/en\/translation We return a html file injecting the loaded json when requesting the root: In the html we basically use polyglot as described on itâs website: You can checkout this example on github: https:\/\/github.com\/locize\/locize polyglot example. While it is a very basic sample the main focus stays on proving just that you can profit from using locize.com using polyglot. Adapt the sample to your backend language or just use xhr directly to load the data inside your client. You directly benefit from the same benefits just i18next developers had until now using locize.com. formatJS + locize.com formatJS is well known for using the intl API to parse dates and numbers plus uses the ICU message format for translations. The format is rather different from what was used in i18next, but still itâs just keybased json. So we started from what we did with polyglot. For the backend there was no change needed, so just scroll up to the polyglot sample where we use request o load the translations. The JSON we load from the Locize project looks like: In the html we use the IntlMessageFormat module and created a little helper function You can see the full example on github: https:\/\/github.com\/locize\/locize formatjs example. The sample can easily be adapted to react intl, ember intl, handlebars intl, dust intl or any other framework using icu messageformat like eg. https:\/\/github.com\/messageformat\/messageformat.js. Working examples we maintain: locize react intl example and locize next intl example. Conclusion While initially focused on i18next json format when building locize.com we found out that you can profit from the locize.com service using polyglot or any libary using messageformat (formatJS and others) too. We love flexibility so weâre looking forward to our first customer creating a project using airbnbâs or yahooâs i18n framework."},{"slug":"eat-our-own-dogfood","title":"How we eat our own dogfood","description":"How we used locizify to translate our own landing page: versions, language switching, and avoiding initial flicker.","date":"2016-06-11","category":"Engineering","thumbnail":"\/img\/blog\/eat-our-own-dogfood\/result.png","readTime":"2 min read","searchText":"title: 'How we eat our own dogfood', description: 'How we used locizify to translate our own landing page: versions, language switching, and avoiding initial flicker.', date: '2016 06 11', thumbnail: '\/img\/blog\/eat our own dogfood\/result.png', image: '\/img\/blog\/eat our own dogfood\/result.png', category: 'Engineering', tags: ['localization', 'engineering'] A small relaunch, and a simple goal After relaunching our website with new templates for our documentation and blog posts (plus a new landing page), we decided to translate at least the landing page. Because we use Hexo to generate static content, it was a natural fit to use our locizify script so we didnât have to instrument the page ourselves. A fixed namespace for the landing page Since we might translate other areas later, we chose a fixed namespace (filename) for the landing page. We used the advanced option to initialize locizify as described here. We ended up with the following snippet: After reloading the page, the source content (English) appeared inside our Locize project. We translated it to German and Italian in no time using our editor. Translate to German Since the latest version gets auto published, reloading the page with the additional query string parameter (or switching the browser language) was enough to test the translation. Using versions for safe releases Next, we created a production version (Project settings â Versions) so we could change or prepare new content during development without affecting the currently released page version. Create and use versions Avoid flickering on the initial load After that, we wanted to avoid the flicker on initial load where the page first gets displayed in the source language until locizify loads and applies the translations. To optimize this, we just needed to add to the body (more info): Let users switch language Finally, we needed a
40solution to let the user change the language on our page. We started with a simple list of links: â¦but decided a element would fit better with our layout. We needed to bind to the i18next languageChanged event to select the current language and handle the select event. We also use to read the available languages from our project so we donât have to touch code when we add new languages. The select element: The script: Thatâs it: our landing page was translated in no time, including a custom language selector: Translated landing page Weâre very pleased with the outcome of eating our own dogfood. Next step: ordering professional translations for the languages we canât translate ourselves."},{"slug":"technology-stack","title":"Technology stack - Locize is serverless","description":"A quick overview of the AWS services that power Locize, built with a serverless mindset so we can focus on product, not servers.","date":"2016-04-07","category":"Engineering","thumbnail":"\/img\/blog\/technology-stack\/nodejs-new-pantone-black.png","readTime":"2 min read","searchText":"title: 'Technology stack Locize is serverless', description: 'A quick overview of the AWS services that power Locize, built with a serverless mindset so we can focus on product, not servers.', date: '2016 04 07', thumbnail: '\/img\/blog\/technology stack\/nodejs new pantone black.png', image: '\/img\/blog\/technology stack\/nodejs new pantone black.png', category: 'Engineering', tags: ['localization', 'engineering', 'serverless'] No servers? We believe the best DevOps is NoOps . Nothing against DevOps (or DevOps people): quite the opposite. We just think we can do things differently. Instead of spending time setting up and maintaining virtual machines, we build on managed services, leaving us more time to work on product features. Building Locize gave us the opportunity to explore a more âserverlessâ path for long lasting components. At a high level, we use these AWS building blocks: AWS DynamoDB AWS CloudFront CDN AWS Simple Storage Service S3 And in particular: AWS API Gateway AWS Lambda AWS Lambda AWS Lambda is a compute service where you upload code and AWS runs it for you. No servers to manage, no containers to operate, no infrastructure to babysit. For Locize, Lambda integrates especially well with: Amazon S3: where we serve localized files Amazon DynamoDB: our main storage for work in progress data That means we donât have to worry (as much) about capacity planning, scaling, or multi server coordination. We use the Node.js runtime for our Lambda functions. Amazon API Gateway AWS API Gateway lets you create a RESTful API to expose selected back end features. The back end can be another AWS service, such as AWS Lambda or AWS DynamoDB, or it can be an existing web application. How Locize uses these services AWS architecture overview for Locize What about the client side? In another blog post."},{"slug":"day-zero-how-all-began","title":"Day zero - How all began","description":"How i18next started in 2011, and why we built Locize to solve the translation workflow problem.","date":"2016-02-27","category":"Company","thumbnail":"\/img\/locize_color.svg","readTime":"1 min read","searchText":"title: 'Day zero How all began', description: 'How i18next started in 2011, and why we built Locize to solve the translation workflow problem.', date: '2016 02 27', thumbnail: '\/img\/locize color.svg', image: '\/img\/locize color.svg', category: 'Company', tags: ['localization', 'company'] Back in 2011 It all started back in 2011 when we were searching for an internationalization library that met our needs: something that could run both on server side Node.js and in our client side single page applications. i18next was born and quickly grew into one of the most used frameworks for translating web applications and Node.js services. The community response was amazing, and a fast growing ecosystem established itself around i18next. Internationalization is not enough Our community gave us great feedback. From that response (and our own experiences) we learned that providing the tooling for internationalization is not enough on its own. Helping developers internationalize their applications is great⦠but thereâs more to it: How do you integrate any translation service \/ agency? How do you keep track of new or removed content? How do you handle proper versioning? How do you deploy translation changes without deploying your complete application? Locize to the rescue With i18next as the foundation, it was a long journey toward localization as a service . But the journey ends this year with Locize : E
40asy to integrate Order professional translations Analytics & statistics Benefit from our content delivery network Versioning of your translations Risk free: take your data with you Transparent and fair pricing"}]}}</script>
40 41
41<script id="vike_globalContext" type="application/json">{}</script>
41 42
42<script src="/assets/entries/entry-client-routing.CPZ_q5N1.js" type="module" async></script>
42 43 <link rel="modulepreload" href="/assets/entries/pages_blog_index.DpzrXWZP.js" as="script" type="text/javascript"> 44 <link rel="modulepreload" href="/assets/chunks/chunk-ClQpuiDQ.js" as="script" type="text/javascript"> 45 <link rel="modulepreload" href="/assets/chunks/chunk-3QDP62Df.js" as="script" type="text/javascript"> 46 <link rel="modulepreload" href="/assets/chunks/chunk-DOUT0IPv.js" as="script" type="text/javascript"> 47 <link rel="modulepreload" href="/assets/chunks/chunk-DtL_YJCz.js" as="script" type="text/javascript"> 48 <link rel="modulepreload" href="/assets/chunks/chunk-Bg25ZRhZ.js" as="script" type="text/javascript"> 49 <link rel="modulepreload" href="/assets/chunks/chunk-C124y03_.js" as="script" type="text/javascript"> 50 <link rel="modulepreload" href="/assets/chunks/chunk-DjF0vTT6.js" as="script" type="text/javascript"> 51 <link rel="modulepreload" href="/assets/chunks/chunk-G_R8sG3e.js" as="script" type="text/javascript"> 52
52<script type="module" src="https://static.cloudflareinsights.com/beacon.min.js/v31edd6df95cf4e85bb4c19e7a9bdbcba1788362987495" integrity="sha512-iIg7k2xntmwu6/uSb5tpc/hySgZc4eoL31yB29W6tJFo2akwjPWcEqnCEdJvGexCL0KEQwVYv5BlowfhVz26hg==" data-cf-beacon='{"version":"2024.11.0","token":"1fef88d1c4f043df9412bb811cf6e82d","r":1,"spa":2}' crossorigin="anonymous"></script>
52 53</body> 54 </html>
Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.