Data accurate as of August 2026 based on market research
This guide reflects current Microsoft, Apple, Google, W3C, and Unicode documentation.
Truth Box
| Key Point | Insight |
|---|---|
| Pronouns are product decisions | Choose address terms by audience, relationship, channel, and action. Keep the product voice consistent. |
| A style guide and glossary do different jobs | The style guide controls voice and rules. The glossary controls approved terms and definitions. |
| Context belongs in the workflow | Reviewers need screen names, screenshots, actions, placeholders, and limits. |
| Locale behavior belongs in code | Use locale-aware libraries for dates, numbers, currency, units, and sorting, then test them. |
| AI still needs an approval owner | Configured tools can attempt documented rules. Automated checks and a Vietnamese reviewer should verify compliance. |
Contents
- Introduction
- What a Vietnamese localization style guide should control
- Make the Vietnamese language decisions explicit
- Build a glossary that supports the guide
- Connect the guide to product context and locale behavior
- Use the guide in an AI-assisted workflow
- Style guide, glossary, translation memory, and LQA
- Current platform and standards context
- Common misconceptions
- FAQ
- Conclusion
Introduction
A Vietnamese localization style guide records decisions for translators, reviewers, product teams, and configured AI tools. It defines audience, tone, pronouns, terminology, UI conventions, protected content, locale handling, and approval.
The guide keeps the product voice consistent. Address terms, feature names, and formality should not change without a reason.
The goal is controlled consistency. Set defaults and let the reviewer document justified exceptions.
What a Vietnamese localization style guide should control
Start with recurring decisions. Expand the guide when review issues reveal a missing rule.
| Section | Decision to record | Owner or evidence |
|---|---|---|
| Audience | Reader, task, and product relationship | Product brief |
| Voice and tone | Defaults for UI, help, marketing, email, support, and policy content | Brand owner and Vietnamese reviewer |
| Address terms | Use of “bạn,” “quý khách,” role names, first person, or omitted subjects | Approved screen examples |
| Terminology | Preferred terms, rejected forms, product names, acronyms, and English terms | Reviewed glossary |
| UI writing | Buttons, errors, confirmations, punctuation, labels, and space limits | Design system and build |
| Locale behavior | Dates, time, numbers, currency, units, sorting, and language selection | Engineering tests |
| Quality approval | Language review, implementation fixes, and release approval | LQA issue log |
Keep global brand and Vietnamese rules separate. Use approved language examples.
Make the Vietnamese language decisions explicit
Choose address terms by relationship
Vietnamese address terms carry relationship and formality. Choose a default from the audience and brand posture, then record situations that need another form. Compact UI labels may work without an explicit pronoun.
Define tone with examples, not adjectives alone
Define tone with approved and rejected examples for errors, notices, welcome messages, and calls to action.
Write for the user action
Translate the function of a product string rather than copying English grammar. Buttons should predict actions. Errors should explain the problem and next step. Review the result inside the interface.
Microsoft’s language resources cover style, terminology, UI strings, and regional formats. Each product still needs its own brand and audience decisions.
A project might record examples like these. They are decisions to approve, not universal substitutions.
| Decision | Approved pattern | Avoid |
|---|---|---|
| Address terms | Use “bạn” for an approved direct voice, or “quý khách” where the channel calls for it | Switching forms without a rule |
| Error copy | “Không kết nối được. Hãy thử lại.” when retry is the next step | A literal, noun-heavy error with no next step |
| File terminology | Choose “tệp” or “tập tin” for the product, then stay consistent | Alternating terms without context |
| Capitalization | Use sentence case for normal UI labels | Capitalizing every Vietnamese word |
| Product names | Keep approved trademarks and product names unchanged | Translating names ad hoc |
Build a glossary that supports the guide
The glossary controls frequent, important, ambiguous, or inconsistent terms.
| Glossary field | What to record |
|---|---|
| Source term | The exact English term, including capitalization where it matters |
| Preferred Vietnamese | The approved translation or an instruction to keep the source term |
| Definition | What the term means in this product |
| Context | Feature, screen, audience, subject area, or sample sentence |
| Rejected alternatives | Forms that should not appear and the reason where useful |
| Owner and status | Who approved the entry and whether it is proposed, approved, or retired |
Google Cloud describes a glossary as a custom dictionary for consistent domain-specific terminology. Its glossary documentation also shows how approved terms can guide automated translation. That is useful for enforcement, but the human-readable definition and context still matter to reviewers.
Connect the guide to product context and locale behavior
Attach the guide to production materials. Include string keys, screen names, screenshots, limits, user actions, variables, and notes for ambiguous strings. Mark content that must not be translated.
Apple’s localization export guidance supports adding screenshots and notes to give localizers context. Its broader localization guidance also recommends native-speaker testing when machine translation is used.
The Unicode Common Locale Data Repository supplies locale data used across operating systems, browsers, and programming platforms. Use locale-aware APIs instead of copied format tables, then test Vietnamese data in the product.
For the wider release process, pair the guide with a Vietnamese software localization checklist.
Use the guide in an AI-assisted workflow
Where tooling supports instructions, provide the style guide, glossary, screen notes, protected tokens, and examples. Require uncertainty to be flagged and verify the result.
- Prepare source text, context, glossary entries, and acceptance criteria.
- Generate or import the first Vietnamese draft through the chosen translation workflow.
- Run automated checks for terminology, missing tokens, tags, numbers, and formatting.
- Have a Vietnamese reviewer edit meaning, tone, address terms, natural phrasing, and channel fit.
- Review the approved language inside the product or page.
- Record accepted new terms and exceptions for the next release.
The guide helps AI follow decisions, but a person owns release approval. For focused review, use the Vietnamese localization QA checklist for AI translation.
Style guide, glossary, translation memory, and LQA
| Asset or process | Main job | What it cannot prove alone |
|---|---|---|
| Style guide | Defines voice, language rules, examples, and approval boundaries | That every term is approved or every screen works |
| Glossary | Controls terminology and non-translatable items | That sentences sound natural in context |
| Translation memory | Reuses previously translated segments | That an old segment still fits the current screen or meaning |
| LQA | Finds linguistic, contextual, visual, and consistency issues | That engineering or product owners fixed and retested them |
Current platform and standards context
The W3C distinguishes localization from translation because localization also covers cultural and locale requirements. Its Internationalization Tag Set covers translatable content, protected content, terminology, and localization notes. Google’s global writing guidance recommends clear source sentences and consistent terminology.
My operational synthesis is to keep source clarity, context, terminology, locale-aware implementation, and review in one maintained guide.
Common misconceptions
Myth: A brand guide is enough
A brand guide may describe voice and visuals. It rarely explains Vietnamese address terms, UI patterns, terminology choices, protected tokens, or localization approval.
Myth: The glossary is the style guide
A glossary controls terms. It does not explain channel tone, sentence patterns, punctuation, user relationship, or how to handle exceptions.
Myth: AI makes the guide unnecessary
The style guide gives models, translators, and reviewers rules they can apply and check.
FAQ
What should a Vietnamese localization style guide include?
Include audience, tone, pronouns, terminology, UI rules, protected content, locale responsibilities, examples, and approval ownership.
Should Vietnamese product copy always address users as “bạn”?
No universal choice fits every product or channel. Decide from the audience, brand relationship, action, and context, then document the default and exceptions.
What is the difference between a style guide and a glossary?
The style guide controls how the product speaks. The glossary controls how specific terms are translated, defined, or kept unchanged.
Can an AI translation tool enforce the style guide?
Some configured tools can attempt explicit rules. Deterministic checks and a Vietnamese reviewer should verify compliance and the integrated result.
Who should own the Vietnamese localization style guide?
Product or localization operations should maintain it with a Vietnamese language reviewer and the relevant brand, support, engineering, and legal owners.
Conclusion
Create the first version from real product decisions, not a generic template alone. Add approved Vietnamese examples, connect the guide to the glossary and screen context, and update it when LQA reveals a recurring choice.
If you need help building an English to Vietnamese localization, MTPE, or LQA workflow around your product, visit Nguyen LNP or email [email protected].
Recent Comments