Ngày rà soát: 04/10/2026
Trả lời nhanh
Style guide bản địa hóa tiếng Việt là bộ quyết định về ngôn ngữ và giao diện dành cho một sản phẩm, một nhóm người dùng cụ thể. Tài liệu này giúp người viết, người dịch và người rà soát thống nhất cách dùng thuật ngữ, xưng hô, nút bấm, biểu mẫu, định dạng và ngoại lệ. Một danh sách từ dịch sẵn chưa đủ: cần bổ sung ngữ cảnh, ví dụ đã duyệt và cách xử lý khi chức năng thay đổi.
Những điểm cần nhớ
- Xác định đối tượng sử dụng trước khi chọn giọng điệu và cách xưng hô.
- Dịch đúng thao tác mà nút bấm thực hiện, không chỉ dịch từ tiếng Anh.
- Thống nhất thuật ngữ theo từng nghĩa, không ép một bản dịch cho mọi tình huống.
- Giữ nguyên biến kỹ thuật và kiểm tra thông báo sau khi chèn dữ liệu.
- Phân biệt khuyến nghị biên tập với yêu cầu kỹ thuật của hệ thống.
- Rà soát nội dung trong giao diện thực tế, bao gồm màn hình nhỏ và trạng thái lỗi.
Nên quyết định điều gì trước khi viết style guide?
Bắt đầu từ sản phẩm, người dùng và nhiệm vụ của họ. Bảng điều khiển mua hàng, ứng dụng tiêu dùng và công cụ dành cho lập trình viên có thể dùng tiếng Việt đúng nhưng chọn cách diễn đạt khác nhau. Theo cách phân biệt của W3C, bản địa hóa điều chỉnh sản phẩm theo thị trường hoặc locale; quốc tế hóa chuẩn bị thiết kế và triển khai để việc điều chỉnh đó khả thi [1]. Các quy tắc ngôn ngữ dưới đây là đề xuất thực hành, không phải chuẩn bắt buộc cho mọi doanh nghiệp.
Viết hoa và xưng hô thế nào cho nhất quán?
Chọn một mặc định biên tập rồi ghi rõ ngoại lệ. Với nhiều giao diện doanh nghiệp, LocalizeZone đề xuất kiểu viết hoa đầu câu: “Quản lý tài khoản” thay vì viết hoa từng từ. Tên sản phẩm, thương hiệu và chữ viết tắt đã duyệt cần được giữ đúng. Đây là lựa chọn phong cách, không phải quy định kỹ thuật áp dụng cho mọi phần mềm tiếng Việt.
Cách xưng hô phụ thuộc vào mối quan hệ giữa sản phẩm và người dùng. “Bạn” có thể phù hợp với giao diện phổ thông; “anh/chị” có thể phù hợp khi tư vấn trực tiếp; một số bảng điều khiển có thể bỏ đại từ. Không cần lặp “quý khách” trong mọi thông báo nếu câu chỉ cần mô tả trạng thái. Hãy đọc thử cả luồng sử dụng để đánh giá cảm giác nhất quán.
Những ví dụ giao diện nào có thể dùng làm điểm khởi đầu?
Bảng dưới đây đề xuất cách diễn đạt theo ngữ cảnh được nêu. Đây không phải bảng thuật ngữ duy nhất đúng. Cột “Tránh” chỉ nói về cách dùng không phù hợp với nghĩa cụ thể của dòng đó; từ ấy vẫn có thể đúng ở chức năng khác.
| Từ nguồn và ngữ cảnh | Nên dùng | Tránh trong ngữ cảnh này | Giải thích hoặc ví dụ |
|---|---|---|---|
| Sign in, tài khoản đã có | Đăng nhập | Đăng ký | Bắt đầu phiên sử dụng tài khoản |
| Sign up, người dùng mới | Tạo tài khoản | Đăng nhập | Tạo tài khoản mới |
| Save, thay đổi bản nháp | Lưu | Gửi | Lưu chưa chắc đã gửi xử lý |
| Submit, gửi yêu cầu | Gửi yêu cầu | Lưu | Chuyển yêu cầu tới hệ thống |
| Cancel, dừng thao tác | Hủy | Xóa tài khoản | Chỉ hủy thao tác hiện tại |
| Delete, xóa một mục | Xóa | Hủy đăng ký | Có thể ghi rõ mục bị xóa |
| Remove, gỡ thành viên | Gỡ thành viên | Xóa người dùng | Không mặc định xóa tài khoản toàn hệ thống |
| Continue, bước tiếp theo | Tiếp tục | Hoàn tất | Luồng còn các bước sau |
| Finish, kết thúc thiết lập | Hoàn tất | Tiếp tục | Đã tới bước cuối |
| Apply, áp dụng bộ lọc | Áp dụng | Đăng ký | Thực thi bộ lọc đã chọn |
| Reset, về bộ lọc mặc định | Đặt lại bộ lọc | Khởi động lại | Không phải khởi động thiết bị |
| Retry, yêu cầu bị lỗi | Thử lại | Tải lại tất cả | Thực hiện lại thao tác liên quan |
| Download, nhận tệp | Tải xuống | Tải lên | Đúng chiều truyền dữ liệu |
| Upload, gửi tệp | Tải lên | Tải xuống | Đúng chiều truyền dữ liệu |
| Settings, tùy chỉnh sản phẩm | Cài đặt | Thiết lập lần đầu | Có thể được dùng nhiều lần |
| Billing, quản lý khoản thu | Thanh toán | Hóa đơn | Có thể gồm nhiều chức năng |
| Invoice, chứng từ đã phát hành | Hóa đơn | Báo giá | Hai loại tài liệu khác nhau |
| Quote, giá đề xuất | Báo giá | Hóa đơn | Chưa hàm ý giao dịch hoàn tất |
| Required, yêu cầu nhập | Bắt buộc | Quan trọng | Nêu điều kiện của biểu mẫu |
| Optional, được bỏ trống | Không bắt buộc | Bắt buộc nếu có | Cho biết có thể không nhập |
| Pending, đang đợi xét duyệt | Chờ xét duyệt | Đã duyệt | Nêu rõ công việc còn chờ |
| Approved, đã có quyết định | Đã duyệt | Đã hoàn thành | Duyệt chưa chắc là giao xong |
| Search, tìm bản ghi | Tìm kiếm | Khám phá | Phù hợp thao tác tra cứu |
| Archive, rời danh sách đang dùng | Lưu trữ | Xóa vĩnh viễn | Giải thích khả năng khôi phục nếu cần |
Nút bấm, menu và biểu mẫu nên được viết ra sao?
Nút bấm cần cho biết thao tác có thể dự đoán. Trong hộp xác nhận xóa, “Xóa dự án” thường rõ hơn “Có”. Menu nên chỉ nơi người dùng sẽ đến, còn nút hành động nên chỉ việc sẽ xảy ra. Nếu dùng cùng một cách gọi cho cả hai, người dùng có thể hiểu nhầm rằng mở trang đồng nghĩa với thực hiện thao tác.
Nhãn trường nhập liệu cần được hiển thị và liên kết với trường tương ứng. Hướng dẫn W3C phân biệt nhãn với placeholder; chữ gợi ý bên trong ô không thay thế đầy đủ cho nhãn được gắn đúng cách [2]. Trong style guide, tách riêng nhãn, hướng dẫn định dạng và thông báo xác thực để người rà soát biết nội dung nào còn nhìn thấy sau khi bắt đầu nhập.
Ví dụ, nếu mã đơn hàng được phép bỏ trống, có thể viết “Mã đơn hàng (không bắt buộc)”. Quy tắc kiểm tra trong trình duyệt và máy chủ phải cùng cho phép bỏ trống. Chỉnh bản dịch không giải quyết được mâu thuẫn giữa nhãn và chức năng. Tương tự, ví dụ ngày tháng cần phù hợp với định dạng mà hệ thống thực sự chấp nhận.
Thông báo lỗi thế nào mới giúp người dùng xử lý được?
Thông báo hữu ích cần nêu vấn đề và một bước xử lý khả thi. W3C khuyến nghị phản hồi rõ về kết quả gửi biểu mẫu và hướng dẫn dễ hiểu để sửa lỗi [3]. Một cấu trúc thực hành là: tình trạng, mục liên quan, thao tác tiếp theo. Chỉ đề xuất thao tác mà giao diện thực sự hỗ trợ.
Thay vì “Thông tin không hợp lệ”, có thể viết “Email chưa đúng định dạng. Kiểm tra lại địa chỉ email.” Nếu tệp vượt giới hạn đã xác định, nêu đúng giới hạn và đơn vị mà sản phẩm sử dụng. “Tổng dung lượng vượt 25 MB” khác với “Một tệp vượt 25 MB”. Người dịch không nên tự điều chỉnh ngưỡng hoặc chuyển giới hạn tổng thành giới hạn từng tệp.
Xử lý ngày giờ, số, tiền tệ và địa chỉ như thế nào?
Dùng bộ định dạng có hỗ trợ locale cho dữ liệu động và ghi rõ locale sản phẩm lựa chọn. Unicode CLDR cung cấp dữ liệu tiếng Việt về định dạng ngày và số [4]. Đây là nguồn tham khảo kỹ thuật; sản phẩm vẫn cần quyết định độ chính xác, loại tiền, múi giờ và ý nghĩa nghiệp vụ của từng trường.
Giao diện tiếng Việt vẫn có thể hiển thị giao dịch USD. Ngôn ngữ và đơn vị tiền tệ là hai quyết định riêng. Khi cần tránh nhầm lẫn, hiển thị rõ mã tiền; với lịch hẹn, nêu múi giờ phù hợp. Không dùng chuỗi đã định dạng để thay thế dữ liệu gốc trong lưu trữ. Ví dụ trong tài liệu nên được kiểm tra với môi trường chạy thực tế.
Tên người và định dạng nhập liệu không nên bị ép theo giả định phương Tây [5]. Việc chuẩn hóa Unicode cần tuân theo luồng dữ liệu của hệ thống [6].
Bảo toàn biến, dấu câu và bố cục bằng cách nào?
Giữ nguyên token kỹ thuật nếu hệ thống không cho phép thay đổi. Trong “Xin chào, {name}”, tên biến là phần giao tiếp với ứng dụng, không phải từ cần dịch. Có thể chuyển vị trí biến để câu tự nhiên hơn, nhưng không được tự đổi tên, bỏ biến bắt buộc hoặc thêm biến chưa được hỗ trợ.
Ghi rõ định dạng thông báo trước khi đưa ví dụ. {name}, {{name}} và %s không phải các cách viết thay thế tùy ý. Với số nhiều hoặc lựa chọn theo điều kiện, người rà soát cần biết nhánh xử lý, dữ liệu mẫu và cách hiển thị. Kiểm tra tự động nên đối chiếu biến rồi dựng thông báo bằng giá trị thực tế.
Độ dài phải được kiểm tra trong giao diện. W3C lưu ý kích thước văn bản có thể thay đổi sau khi dịch và khuyến nghị bố cục linh hoạt [7]. Không lấy một tỷ lệ giãn duy nhất áp cho mọi chuỗi tiếng Việt. Kiểm tra giá trị dài, màn hình hẹp, phóng to, chiều cao dòng và tooltip, nhất là những vị trí có thể cắt dấu.
Quy trình rà soát nào có thể lặp lại qua nhiều lần phát hành?
Chọn một bộ màn hình đại diện trước khi mở rộng tài liệu. Bộ này nên có đăng nhập, thanh toán, thao tác xóa, thông báo lỗi, trạng thái trống và bảng nhiều dữ liệu. Với từng chuỗi, cung cấp ảnh, ý nghĩa thao tác và kết quả mong đợi. Phê duyệt trong giao diện thực tế thay vì chỉ đọc bảng tính.
| Bước rà soát | Bằng chứng cần có | Điều kiện đạt | Người tham gia |
|---|---|---|---|
| Ý nghĩa | Ngữ cảnh và hành động thực tế | Câu tiếng Việt mô tả đúng chức năng | Phụ trách sản phẩm |
| Thuật ngữ | Nghĩa và thuật ngữ đã duyệt | Không đổi từ tùy tiện trong cùng một nghĩa | Người duyệt ngôn ngữ |
| Biến kỹ thuật | Danh sách biến, thông báo sau khi dựng | Biến và dữ liệu được bảo toàn | Lập trình viên |
| Bố cục | Ảnh màn hình hẹp và phóng to | Đọc rõ, thao tác được | Thiết kế hoặc QA |
| Khôi phục lỗi | Cách gây lỗi và thử bước tiếp theo | Người dùng thực hiện được hướng dẫn | QA và sản phẩm |
| Quản lý quyết định | Lý do chọn và ngoại lệ | Người khác hiểu lại được quyết định | Phụ trách nội dung |
Khuyến nghị thực hành của LocalizeZone
Bắt đầu bằng style guide gọn, glossary có ngữ cảnh và bộ màn hình đã rà soát. Bổ sung khi xuất hiện vấn đề thực tế. Một quy tắc ngắn có ví dụ đã duyệt thường dễ áp dụng hơn một đoạn định hướng chung không có trường hợp cụ thể.
Khi bàn giao dự án, chuẩn bị tệp nguồn, locale đích, đối tượng, ảnh màn hình, quy tắc biến, người duyệt và lịch phát hành. Có thể trao đổi với LocalizeZone về bản địa hóa phần mềm để xác định phạm vi ngôn ngữ và đầu vào cần thiết. Công việc kỹ thuật hoặc kiểm thử chức năng cần được thỏa thuận rõ, không mặc định nằm trong dịch vụ dịch văn bản.
Câu hỏi thường gặp
Mỗi thuật ngữ giao diện chỉ có một cách dịch đúng không?
Không. Có thể có nhiều cách đúng. Lựa chọn cần mô tả đúng thao tác, phù hợp người dùng và nhất quán với nghĩa đã quy định trong sản phẩm.
Ứng dụng doanh nghiệp luôn phải xưng hô “anh/chị” không?
Không. Đây là quyết định về đối tượng và giọng điệu. Cần kiểm tra tính nhất quán giữa nhãn, thông báo, hỗ trợ và lỗi.
Có thể rút ngắn bản dịch cho vừa nút bấm không?
Có thể đề xuất cách viết ngắn hơn nhưng không được mất ý nghĩa. Nếu phải viết tắt khó hiểu, nên xem lại bố cục hoặc thành phần giao diện.
Có dịch tên placeholder không?
Thông thường phải giữ đúng tên biến mà ứng dụng yêu cầu. Chỉ dịch phần văn bản xung quanh và kiểm tra kết quả sau khi chèn dữ liệu.
Giao diện tiếng Việt có bắt buộc thanh toán bằng VND không?
Không. Ngôn ngữ giao diện, định dạng locale và tiền giao dịch là các lựa chọn riêng. Hiển thị đúng loại tiền đã thống nhất cho giao dịch.
Bao lâu cần cập nhật style guide?
Rà soát khi chức năng, thuật ngữ, người dùng hoặc công nghệ thông báo thay đổi. Quản lý phiên bản giúp xác định bộ quy tắc áp dụng cho từng lần phát hành.
Nguồn và phương pháp
Các tài liệu bên dưới được kiểm tra ngày 04/10/2026. Chúng hỗ trợ những nhận định đánh số về quốc tế hóa, biểu mẫu dễ tiếp cận, dữ liệu locale, tên người, chuẩn hóa và bố cục. Cách dịch tiếng Việt, các bảng và quy trình rà soát là đề xuất thực hành do bài viết tổng hợp, không phải kết quả nghiên cứu được gán cho những tài liệu đó. Ví dụ mang tính minh họa, không phải câu chuyện khách hàng hay số liệu cải thiện chuyển đổi.
Tài liệu tham khảo
- W3C Internationalization — Localization vs. Internationalization — World Wide Web Consortium.
- W3C WAI — Labeling Controls, Forms Tutorial — World Wide Web Consortium.
- W3C WAI — User Notification, Forms Tutorial — World Wide Web Consortium.
- Unicode CLDR — Locale Data Summary for Vietnamese, phiên bản bảng 48 được truy cập khi rà soát — Unicode Consortium.
- W3C Internationalization — Personal names around the world — World Wide Web Consortium.
- Unicode Standard Annex #15 — Unicode Normalization Forms — Unicode Consortium.
- W3C Internationalization — Text size in translation — World Wide Web Consortium.
Bài viết liên quan
- Hướng dẫn định dạng ngày giờ, số và tiền tệ trong tiếng Việt
- 100 thuật ngữ giao diện Anh–Việt thường gặp trong SaaS và ứng dụng
- Hướng dẫn UX Writing tiếng Việt cho nút bấm, biểu mẫu và thông báo lỗi
- Định dạng địa chỉ Việt Nam cho biểu mẫu, thương mại điện tử và cơ sở dữ liệu
- Tên người Việt: Hướng dẫn cho biểu mẫu, cơ sở dữ liệu và giao diện
- Định dạng số điện thoại Việt Nam cho website và ứng dụng