User Experience
Build bilingual interfaces beyond translating labels
A bilingual product needs consistent business meaning, formatting, recovery messages, and language switching. Review complete English and Vietnamese workflows rather than approving translated labels in a spreadsheet alone.
Translating navigation labels does not create a complete bilingual service. A customer may start in Vietnamese, receive an English error, and download a report with unexplained abbreviations. Decide what the language choice covers before estimating the work. Include the full journey from first entry through confirmation, support, and any generated documents.
Agree the business vocabulary first
Create a small glossary for important statuses, actions, and document names. Distinguish concepts that sound similar but behave differently, such as saving a draft and submitting a request. Ask business reviewers to approve the meaning in both languages before the team repeats those terms across screens.
Do not translate user-entered company names or identifiers automatically. Keep original values separate from translated interface text. Where the product supports translated descriptions, explain who owns those versions and which version applies when information is missing.
Make language a product behavior
WAI explains that identifying the page language helps screen readers use the correct pronunciation rules.[4] Include the programmatically identified language in acceptance checks, not just visible labels. A language selector that changes words while leaving the page language incorrect is incomplete.
Specify whether switching languages preserves unsaved fields, filters, and the current record. Define number, currency, and date presentation separately from the stored business value. For ambiguous dates, prefer an explicitly explained format. Test long Vietnamese labels and English terms at narrow widths rather than assuming equal text length.
Hypothetical example: a maintenance request
A hypothetical property manager creates a Vietnamese maintenance request, then switches to English to discuss it with a colleague. The request identifier, entered description, and attachments remain unchanged. Interface instructions change language, while the product clearly identifies user-authored text that has not been translated.
A reviewer then rejects the request because a required location is missing. The error, correction guidance, notification, and final confirmation all follow the selected interface language. The team also checks the exported request because a translated screen alone does not prove that generated documents match the agreed language scope.
Build a bilingual release checklist
Assign a reviewer who understands the business in each language. Compare actual task outcomes rather than counting translated strings. A shorter label can still misrepresent an action, and a fluent paragraph can still omit a restriction that matters.
Complete bilingual coverage costs more to maintain, especially when policy text changes often. Define a clear fallback for unavailable translations and prevent unfinished wording from appearing as an approved promise.
- Approve paired terms for statuses and irreversible actions.
- Test errors, confirmations, help, and exports in both languages.
- Preserve entered values and task context during language switching.
- Check page language identification with the rendered interface.
- Verify formatting and long labels with realistic business records.
