Website and App Localization Checklist (with Vietnamese as a Worked Example)

Translating the words is the visible part of localization, and usually the smaller part. Before and after translation there’s a long list of things that decide whether the localized product feels native or feels like an afterthought: number formats, fonts, tone of address, layout, search engines, payments and testing.

This checklist works for any language. To make it concrete, each section includes the specific details for Vietnamese — a language that’s increasingly common as a target for apps and online shops, and that exposes several classic localization bugs.

1. Make the code ready before anyone translates

Localization problems found after translation are expensive. Fix these first.

• All user-facing text is externalized into resource files (JSON, YAML, .strings, .po), not hard-coded in components, templates or the database.
• No string concatenation. "Hello " + name + ", welcome" can’t be reordered. Use a single message with placeholders.
• Plurals use your i18n library’s plural support instead of count === 1 ? "item" : "items".
• Dates, numbers and currencies are formatted by locale using Intl (JavaScript), ICU, or your framework’s equivalent — never assembled by hand.
• Each string has a stable key and, where ambiguous, a context note for the translator.
• Pseudo-localization runs in development to reveal hard-coded text and overflow before real translations arrive.

Our guide to localizing JSON i18n files safely covers placeholders, plural rules and automated checks in depth.

Vietnamese note: Vietnamese has no grammatical plural inflection, and its CLDR plural rules have only the other category. That makes plurals easy in Vietnamese itself, but it’s a reason not to hard-code English’s one/other logic — the same code will be wrong for Polish, Russian or Arabic later.

2. Formats: numbers, currency, dates, names

• Number separators follow the locale.
• Currency shows the right symbol, position and decimals.
• Dates and times use the local order and, where relevant, the local time zone.
• Names and addresses don’t assume a “first name / last name” Western structure.
• Phone numbers accept the local format and country code.

Vietnamese specifics:

Item	Typical Vietnamese format
Thousands / decimal separators	1.234.567,89 (dot for thousands, comma for decimals)
Currency	Vietnamese đồng, code VND, symbol ₫, usually shown after the amount: 1.250.000 ₫. Prices are normally whole numbers.
Short date	20/10/2026 (day/month/year)
Long date	Thứ Ba, 20 tháng 10, 2026
Country calling code	+84
Locale code	vi or vi-VN

You don’t have to memorize these — Intl produces them for you:

new Intl.NumberFormat("vi-VN", { style: "currency", currency: "VND" }).format(1250000);
// "1.250.000 ₫"

new Intl.DateTimeFormat("vi-VN").format(new Date(2026, 9, 20));
// "20/10/2026"

Names: Vietnamese full names are written family name first — for example Nguyễn Văn An, where Nguyễn is the family name and An is the given name. People are usually addressed by the given name. If your app greets users as “Hi, {lastName}” or sorts by “last name”, it will get this wrong. A single “full name” field plus an optional “what should we call you?” field avoids the problem in any culture.

3. Fonts, scripts and text rendering

• Your fonts include every character the language needs. Check bold and italic weights too.
• Line height leaves room for accents above and below the letters.
• Text is normalized consistently (Unicode NFC is the usual choice) before storing, comparing or searching.
• Right-to-left languages (Arabic, Hebrew, Persian) get mirrored layouts with dir="rtl" and logical CSS properties.

Vietnamese specifics: Vietnamese is written in the Latin alphabet with many diacritics, and some letters stack two marks — ệ, ở, ẫ. Many web fonts that claim “Latin” support don’t include them, and the browser then substitutes a fallback font for just those letters, producing a patchy, unprofessional look. When using Google Fonts, check that the family offers the Vietnamese subset. Tight line-height values can clip stacked diacritics in headings, so test real Vietnamese text, not placeholder text.

Vietnamese text can also arrive in decomposed Unicode form (a base letter followed by combining marks) — for example when pasted from some sources. "ệ" is one code point in NFC and three in NFD. If you don’t normalize, search, de-duplication and length checks fail in confusing ways:

const clean = input.normalize("NFC");

4. Layout and text length

• UI tolerates longer text — buttons, tabs, table headers, navigation.
• No text baked into images, or a plan to localize those images.
• Truncation is deliberate, with the full text available (tooltip or wrapping).

Vietnamese is written with spaces between syllables rather than between words, and it often runs longer than the English source. Check navigation bars and buttons at narrow mobile widths in particular.

5. Tone, terminology and content

• A style guide for the target language defines formality, pronouns and key terms.
• A glossary fixes product terms, feature names and anything legal.
• Examples, images and references make sense for the audience.
• Legal pages (terms, privacy, refunds) are reviewed by someone qualified for that market.

Vietnamese specifics: Vietnamese has no single neutral “you”. Pronouns depend on the relative age and relationship of the speakers. Product copy commonly uses bạn as a friendly, neutral “you”, while customer-service and commercial contexts often use the more respectful Quý khách. Decide which your brand uses and apply it everywhere — mixing them reads as careless. This is exactly the kind of decision machine translation makes inconsistently, so put it in the style guide and check it in review.

6. SEO for the localized site

• Each language has its own URL (/vi/, a subdomain, or a separate domain) — not a language switch that changes content at the same URL.
• <html lang="vi"> (or the right code) on every localized page.
• hreflang annotations link each page to its equivalents, including an x-default.
• Titles, meta descriptions and URL slugs are translated, not just the body.
• Keyword research is done in the target language. People don’t search with literal translations of English keywords.
• The sitemap includes the localized URLs.

7. Commerce and local expectations

• Payment methods match the market. In Vietnam, alongside cards, many shoppers expect bank transfer via QR codes and e-wallets such as MoMo or ZaloPay; cash on delivery remains common for e-commerce.
• Shipping, tax and invoicing information is correct for the country.
• Support is available in the language, or the limits are stated clearly.

8. Translate the files, then review

When the code is ready, translation is mostly a file workflow: export resource files, documents and subtitles; translate; import. Keep formats intact so nothing has to be re-entered by hand. That’s what 2Translate is being built for — JSON/YAML resource files with keys and placeholders preserved, plus DOCX, PDF, PPTX, Markdown and subtitle files with their structure intact.

Whatever produces the translation, decide on the right level of human review using the machine vs human translation framework: UI strings and help content can often use machine translation plus review, while legal pages and marketing need a professional.

9. Test in the real product

• Automated checks for missing keys and mismatched placeholders run in CI.
• Screenshots of every key screen in the new language, at mobile and desktop widths.
• A native speaker uses the product end to end: sign-up, checkout, emails, error messages, notifications.
• Emails, PDFs and push notifications are localized too — they’re easy to forget.
• Search, sorting and input work with the language’s characters (try searching with and without diacritics).
• A feedback channel exists for users to report translation problems.

The short version

Localization goes well when the code is ready first, formats come from the platform rather than from translators, fonts and layout are tested with real text, tone is decided up front, and a native speaker checks the result in context. Get those right and the translation itself becomes the easy part.