Multilanguage là thứ hiếm khi được làm ngay từ đầu, nhưng gần như dự án nào cũng sẽ phải thêm sau. Multilanguage là thứ hiếm khi được làm ngay từ đầu, nhưng gần như dự án nào cũng sẽ phải thêm sau. Trong thực tế, vấn đề không nằm ở việc dùng thư viện gì, mà nằm ở cách tư duy khi setup. Nếu làm sai từ đầu, càng về sau chi phí sửa càng lớn, thậm chí phải refactor cả UI.
1. Đừng để text sống trong component
Sai lầm phổ biến nhất là để text nằm trực tiếp trong JSX. Ở giai đoạn đầu, cách này rất tiện. Tuy nhiên, khi thêm ngôn ngữ thứ hai, bạn sẽ phải lần từng component để sửa, vừa tốn thời gian vừa dễ sót.
Về bản chất, text không nên là trách nhiệm của component. Thay vào đó, component chỉ nên nhận key, còn nội dung hiển thị cần được quyết định bởi hệ thống ngôn ngữ.
Ngay từ đầu, hãy chấp nhận một việc hơi “phiền”: mọi text đều phải đi qua hệ thống i18n, kể cả những câu rất ngắn. Chính sự phiền này giúp bạn tránh được nợ kỹ thuật về sau.
2. Thiết kế cấu trúc file dịch trước khi viết code
Nhiều người bắt đầu bằng việc tạo một file JSON rồi thêm key dần dần. Ban đầu, cách làm này có vẻ ổn. Tuy nhiên, khi dự án lớn lên, file dịch rất dễ trở thành một mớ hỗn độn.
Những sai lầm thường gặp bao gồm:
- Đặt key theo UI nhỏ lẻ
- Thêm key theo cảm tính
- Không có quy ước rõ ràng
Để tránh tình trạng đó, cách tiếp cận bền vững hơn là nhóm translation theo feature hoặc domain nghiệp vụ. Mỗi feature nên có một namespace riêng. Khi feature bị xoá hoặc thay đổi, việc xử lý translation cũng gọn hơn rất nhiều.
Cách làm này giúp:
- Việc maintain trở nên đơn giản hơn.
- Key được tổ chức rõ ràng nên rất dễ tìm.
- Nhờ cấu trúc thống nhất, việc chia việc cho nhiều người cũng thuận tiện hơn.
- Ngoài ra, cách tổ chức này còn giúp lazy load khi cần optimize.
Vì vậy, đừng đợi đến khi dự án lớn mới nghĩ về cấu trúc, bởi lúc đó việc sửa sẽ rất mệt.
3. Không assume rằng mọi ngôn ngữ đều giống tiếng Việt
Một lỗi tư duy khá phổ biến là coi mọi ngôn ngữ chỉ khác nhau về câu chữ. Thực tế, mỗi locale có cách hiển thị khác nhau về số, ngày tháng, tiền tệ và cả ngữ pháp.
Nếu bạn chỉ dịch string mà không quan tâm đến format, rất sớm bạn sẽ gặp các vấn đề như:
- Số hiển thị không đúng chuẩn
- Ngày tháng khó đọc
- Câu văn sai ngữ pháp vì không xử lý số nhiều
Do đó, ngay từ đầu cần tách rõ:
- Text thuần
- Format ngày, số, tiền
- Logic plural
Cách tách này giúp hệ thống ngôn ngữ không phụ thuộc vào UI, đồng thời tránh phải sửa lại khi thêm locale mới.
4. Đừng để đổi ngôn ngữ làm re-render toàn bộ ứng dụng
Rất nhiều setup i18n sử dụng Context theo cách đơn giản: đổi language là đổi context value, từ đó kéo theo toàn bộ app re-render. Với app nhỏ, điều này không quá vấn đề. Nhưng với app lớn, hiện tượng lag sẽ thấy rất rõ.
Vấn đề nằm ở chỗ nhiều người coi việc đổi ngôn ngữ là sự kiện toàn cục cần cập nhật mọi thứ. Trong khi đó, thực tế chỉ những component đang hiển thị text mới cần re-render.
Tư duy đúng nên là:
- Chia translation theo namespace
- Chỉ load những phần thực sự cần thiết
- Hạn chế context lan quá rộng
Multilanguage không nên đánh đổi performance. Nếu đổi language mà user cảm thấy app chậm đi, setup đó rõ ràng cần xem lại.
5. Chuẩn bị sẵn cho việc thêm ngôn ngữ mới mà không sửa code
Một setup i18n được coi là ổn khi bạn có thể thêm ngôn ngữ mới mà không cần đụng vào component hay logic hiện có.
Ngược lại, nếu mỗi lần thêm language bạn phải:
- Sửa JSX
- Thêm điều kiện if-else
- Thay đổi cấu trúc component
Thì đó là dấu hiệu hệ thống đang phụ thuộc vào ngôn ngữ, thay vì ngược lại.
Vì thế, hãy đặt mục tiêu rõ ràng: thêm ngôn ngữ chỉ là thêm dữ liệu, không phải thay đổi hành vi của ứng dụng.
6. Kiểm tra i18n như một phần của review code
Multilanguage không nên là việc “làm cho có”. Trong quá trình review code, i18n cần được coi là một tiêu chí bắt buộc.
Một vài câu hỏi nên được đặt ra:
- Text mới có đi qua hệ thống dịch không?
- Key đặt có đúng theo quy ước không?
- Layout có chịu được text dài hơn không?
- Feature mới có tách namespace rõ ràng không?
Nếu không kiểm tra từ sớm, lỗi i18n sẽ tích tụ rất nhanh và cực kỳ khó dọn về sau.
Kết luận
Setup đa ngôn ngữ không khó về mặt kỹ thuật, nhưng lại rất dễ sai về mặt tư duy. Phần lớn vấn đề không đến từ thư viện, mà đến từ việc coi i18n là thứ phụ, chỉ làm khi bị yêu cầu.
Khi làm đúng ngay từ đầu, multilanguage không phải là gánh nặng mà trở thành một phần tự nhiên của hệ thống. Ngược lại, nếu làm sai, nó sẽ là thứ khiến cả đội ngại động vào code.
Cuối cùng, front-end tốt không phải là viết nhanh, mà là viết để không phải quay lại sửa cùng một vấn đề nhiều lần.
