Translate complete journeys
Begin with one real task: a customer selects a product, signs in, pays, receives an order update and asks for help. List every message encountered, including validation errors, emails, empty states and administrative replies. A translated homepage cannot complete that journey by itself. Assign an owner to the vocabulary used across these surfaces, especially words such as pending, confirmed, delivered and refunded. Those terms should describe the same states wherever a customer encounters them, even when different teams maintain the screens.
Design direction and meaning together
Arabic needs deliberate treatment of direction, not just translated strings. Declare page language and text direction separately, and use logical spacing so the layout can follow the document direction. Then review actual content: a sentence may include a Latin product name, an email address and a transaction identifier. Check that these remain readable and copy correctly. Test long German labels, French punctuation and Arabic line height in the same components, using realistic content rather than short placeholder translations.
Keep data meaning stable
Decide which values are identifiers and which are presentation. A translated payment label should not alter a network identifier or receiving address. Dates need a clear time-zone convention, while prices need an explicit currency; a local-looking number alone does not explain either. Define how amounts, plural forms and dates are presented in each locale, and test them in invoices, tables and exports. Keep the stored business state independent of its translated label so changing language cannot change the underlying transaction.
Preserve context when language changes
A language switch should take the customer to the corresponding page with useful context intact. Consider a filtered product list, an open support request or a checkout return link. Decide which parameters remain meaningful and which require a translated equivalent. Avoid silently sending every switch back to the homepage. Review page titles, descriptions, navigation and internal links together, and make missing translations an editorial decision. Publishing a fallback should be intentional, with a clear path to completing the localized version.
Treat localization as release work
Create a review checklist around tasks, not just a spreadsheet of strings. Ask a reviewer to complete registration, recover access, inspect an order and submit a ticket in each supported language on a narrow screen. Include keyboard use, screen-reader labels and mixed-direction identifiers. Record problems alongside functional defects so they receive an owner and a release decision. When a feature changes, its messages, help content and notifications should change together. Language support remains useful only when the full experience continues to evolve with the product.