Thông báo đẩy, email giao dịch (xác nhận đơn, đặt lại mật khẩu, hoá đơn) và tin nhắn SMS là phần chữ của ứng dụng mà người dùng đọc ở ngoài ứng dụng: trên màn hình khoá, trong hộp thư lẫn với hàng chục thư khác, trong danh sách tin nhắn. Họ đọc lướt vài chữ đầu rồi quyết định mở hay bỏ qua. Vì vậy dịch nhóm này cần ưu tiên khác giao diện: thông tin quan trọng nhất phải nằm ở đầu, độ dài phải tính theo chỗ hiển thị thật, và giọng phải đủ rõ để người nhận phân biệt được tin thật với tin giả mạo.
Nhóm tin này cũng hay bị bỏ sót nhất trong dự án bản địa hoá, vì chúng nằm ở máy chủ, trong công cụ gửi thư hoặc hệ thống tin nhắn, không trong tệp chuỗi của ứng dụng. Bài này đi qua từng loại: thông báo đẩy, email giao dịch, mã xác thực và tin nhắn trong ứng dụng, kèm những bẫy về độ dài, mã hoá ký tự và thời điểm gửi.
Vì sao tin nhắn hệ thống khó dịch hơn giao diện
Trong giao diện, chữ có bối cảnh: người dùng biết mình đang ở màn hình nào, vừa bấm gì. Tin nhắn hệ thống thì đến bất ngờ, chen giữa tin nhắn của bạn bè và thư quảng cáo. Câu "Your order has shipped" dịch thành "Đơn hàng của bạn đã được giao cho đơn vị vận chuyển" là đúng nghĩa, nhưng trên màn hình khoá chỉ hiện được nửa đầu, và nửa đó không cho biết đơn nào, của ứng dụng nào. Người dịch phải nghĩ như người viết tiêu đề báo: thông tin gì người nhận cần ngay, sắp lên trước.
Thứ hai, tin nhắn hệ thống gần như luôn có biến: tên người dùng, mã đơn, số tiền, thời hạn. Độ dài của biến thay đổi theo từng người nhận, nên một bản dịch vừa vặn với tên ngắn có thể bị cắt với tên dài. Thứ ba, nhóm tin này đi qua những hệ thống có quy tắc riêng: bộ lọc thư rác đọc tiêu đề email, nhà mạng tính phí SMS theo số ký tự, hệ điều hành cắt thông báo theo kích thước màn hình. Bản dịch phải sống được qua tất cả các tầng đó.
Cuối cùng là chuyện lòng tin. Kẻ lừa đảo bắt chước đúng các tin nhắn này — thông báo giao hàng, mã xác thực, cảnh báo đăng nhập. Một ứng dụng có giọng nhất quán, câu chữ chuẩn mực, không bao giờ yêu cầu điều bất thường trong tin nhắn sẽ giúp người dùng nhận ra tin giả dễ hơn. Bản dịch cẩu thả, lúc thế này lúc thế khác, làm người dùng quen với việc tin thật cũng trông lạ.
Thông báo đẩy: từng chữ đầu đều quý
Đưa thông tin chính lên đầu. "Đơn #1024 đang trên đường giao" tốt hơn "Xin trân trọng thông báo đơn hàng của bạn…". Phần mở đầu lịch sự kiểu thư tay chiếm chỗ mà không mang thông tin.
Tiêu đề và nội dung chia việc. Tiêu đề nói chuyện gì (Giao hàng, Thanh toán thành công, Tin nhắn mới), nội dung nói chi tiết. Đừng lặp tiêu đề trong nội dung.
Tính độ dài theo màn hình khoá. Hệ điều hành hiển thị vài dòng rồi cắt, số ký tự hiện được tuỳ thiết bị, cỡ chữ và cách nhóm thông báo. Hãy kiểm trên một máy màn hình nhỏ với cỡ chữ lớn, và viết sao cho phần hiện ra đầu tiên đã đủ ý.
Cẩn thận với biến tên người. Câu chào bằng tên người dùng ở đầu thông báo tiêu tốn chỗ và có thể rất dài. Nếu muốn cá nhân hoá, đặt tên ở cuối hoặc chỉ dùng trong nội dung, không trong tiêu đề.
Biểu tượng cảm xúc theo văn hoá. Một biểu tượng thân thiện ở thị trường này có thể bị hiểu khác ở thị trường khác, hoặc bị coi là thiếu nghiêm túc với thông báo về tiền. Người dịch nên được quyền bỏ hoặc đổi.
Không viết hoa toàn bộ, không dấu chấm than dồn dập. Đó là dấu hiệu của tin rác ở hầu hết ngôn ngữ, và làm người dùng tắt quyền thông báo của ứng dụng.
Email giao dịch: những phần cần dịch
Email giao dịch có nhiều phần hơn người ta tưởng. Bảng dưới liệt kê những phần thường bị quên khi dịch và hậu quả nếu bỏ sót:
| Phần | Ghi chú khi dịch | Nếu bỏ sót |
|---|---|---|
| Tên người gửi | Tên ứng dụng hoặc thương hiệu, có thể kèm bộ phận ("… Hỗ trợ") | Thư hiện tên tiếng gốc, người nhận không nhận ra |
| Tiêu đề | Thông tin chính lên đầu, có mã đơn hoặc mã xác thực nếu cần, tránh chữ dễ bị lọc thư rác | Thư bị bỏ qua hoặc vào thư rác |
| Đoạn xem trước | Dòng ẩn hiện sau tiêu đề trong hộp thư; dịch như một câu bổ sung cho tiêu đề | Hộp thư tự lấy chữ đầu thân thư, thường là chữ thừa |
| Thân thư và nút | Nút ghi hành động cụ thể ("Xác nhận email", "Xem đơn hàng") | Người nhận không biết bấm vào đâu |
| Bản chữ thuần | Phiên bản không định dạng gửi kèm cho trình đọc thư đơn giản | Một số hộp thư hiện bản tiếng gốc hoặc bản trống |
| Chân thư | Thông tin pháp nhân, lý do nhận thư, cách huỷ nhận với thư không bắt buộc | Thiếu thông tin theo yêu cầu của luật ở một số thị trường |
| Ảnh có chữ | Biểu ngữ, nút dạng ảnh | Phần chữ quan trọng nhất của thư vẫn tiếng gốc |
Mẫu email thường nằm trong công cụ gửi thư hoặc trong mã máy chủ, mỗi ngôn ngữ một bản. Khi bản gốc sửa, các bản dịch không tự cập nhật. Cần một danh sách mẫu thư theo ngôn ngữ, có ngày sửa gần nhất, để biết bản nào đã lỗi thời.
Mã xác thực và tin nhắn SMS
Tin nhắn chứa mã xác thực (OTP) là loại tin ngắn nhất mà quan trọng nhất. Quy ước tốt cho mọi ngôn ngữ: mã đứng ở đầu hoặc ngay sau tên ứng dụng, câu cảnh báo "không chia sẻ mã này cho bất kỳ ai, kể cả nhân viên" đi kèm, nói rõ mã dùng để làm gì và hết hạn khi nào. Không chèn đường dẫn trong tin nhắn chứa mã — đó là đúng hình mẫu mà tin lừa đảo bắt chước. Khi dịch, giữ cấu trúc này nguyên vẹn ở mọi ngôn ngữ, không "làm mềm" câu cảnh báo cho dễ đọc.
SMS có một bẫy kỹ thuật ảnh hưởng trực tiếp tới tiếng Việt. Tin nhắn chỉ dùng bảng ký tự cơ bản được mã hoá theo chuẩn GSM, cho phép khoảng 160 ký tự mỗi tin. Chỉ cần một ký tự ngoài bảng đó — như chữ có dấu tiếng Việt — cả tin chuyển sang mã hoá UCS-2, mỗi tin còn khoảng 70 ký tự. Một tin tiếng Việt có dấu dài 150 ký tự sẽ bị tách làm ba phần và tính phí như ba tin. Đây là lý do nhiều tin nhắn thương hiệu tại Việt Nam được gửi không dấu.
Quyết định có dấu hay không dấu là quyết định của sản phẩm, cân giữa chi phí và độ rõ. Tin không dấu dễ đọc nhầm ("ban da dang ky" có thể đọc nhiều cách), nên nếu chọn không dấu, câu phải được viết lại cho ít nhập nhằng, không chỉ bỏ dấu máy móc từ bản có dấu. Tiếng Thái, tiếng Hàn, tiếng Nhật, tiếng Ả Rập luôn rơi vào mã hoá UCS-2, nên độ dài tối đa của tin cần tính lại cho từng ngôn ngữ ngay từ khi viết bản gốc.
Thời điểm, múi giờ và định dạng
Một thông báo dịch hoàn hảo gửi lúc hai giờ sáng theo giờ người nhận là một thông báo tồi. Khi mở thị trường mới, các chiến dịch thông báo và email lên lịch theo giờ Việt Nam phải được đổi sang giờ địa phương của người nhận, và tránh các dịp nghỉ lễ lớn của thị trường đó nếu nội dung không liên quan.
Bên trong nội dung, các mốc thời gian cần cẩn trọng. "Ưu đãi kết thúc hôm nay" hay "hết hạn lúc 23:59" là theo múi giờ nào? Người nhận ở Úc và người nhận ở Đức đọc cùng một thư vào hai thời điểm khác nhau. Cách an toàn là ghi rõ ngày giờ có múi giờ, hoặc để máy chủ tính theo múi giờ của từng người nhận. Định dạng ngày phải theo quy ước vùng: người Việt đọc 03/04 là ngày 3 tháng 4, người Mỹ đọc là ngày 4 tháng 3 — với thời hạn thanh toán, nhầm lẫn này gây hậu quả thật.
Số tiền cũng vậy: ký hiệu tiền tệ đặt trước hay sau số, dấu phân cách hàng nghìn là dấu chấm hay dấu phẩy. Với đồng Việt Nam, cách viết quen thuộc là ký hiệu hoặc chữ "đ" đặt sau số, dấu chấm ngăn hàng nghìn. Những định dạng này nên do thư viện định dạng theo vùng sinh ra, người dịch chỉ cần kiểm kết quả, không gõ tay vào mẫu.
Tin nhắn trong ứng dụng và màn hình hướng dẫn
Ngoài tin gửi ra bên ngoài, ứng dụng còn nhiều loại chữ "trôi nổi": hộp thoại giới thiệu tính năng mới, gợi ý nhỏ chỉ vào một nút, màn hình hướng dẫn mấy bước đầu, biểu ngữ khuyến mãi trong ứng dụng, khảo sát hài lòng. Phần lớn được đội vận hành soạn trong hệ quản trị nội dung hoặc công cụ gửi tin nhắn trong ứng dụng, có khi hằng tuần, nên không đi qua quy trình dịch của bản phát hành.
Hậu quả quen thuộc là người dùng ở thị trường mới thấy giao diện tiếng của họ nhưng thông báo khuyến mãi vẫn tiếng Anh, hoặc tệ hơn, nhận một khảo sát tiếng Việt. Cách xử lý là đặt quy tắc ngay trong công cụ: tin không có bản dịch cho ngôn ngữ của người dùng thì không gửi cho nhóm đó, thay vì tự rơi về ngôn ngữ mặc định. Đội vận hành cũng cần đường dịch nhanh — vài giờ hoặc một ngày — cho nội dung ngắn, vì nhịp của nhóm nội dung này nhanh hơn nhịp phát hành.
Màn hình hướng dẫn ban đầu đáng được dịch kỹ nhất trong nhóm này: đó là vài giây đầu tiên người dùng mới tiếp xúc với sản phẩm. Câu ngắn, mỗi màn hình một ý, động từ hành động cụ thể, và ảnh minh hoạ dùng giao diện đã dịch.
Danh mục kiểm trước khi bật gửi cho thị trường mới
Chạy qua danh mục này một lần trước khi mở thông báo, email và tin nhắn cho người dùng một ngôn ngữ mới:
- Liệt kê đủ mọi loại tin hệ thống gửi đi, gồm cả tin hiếm như cảnh báo đăng nhập lạ, thông báo xoá tài khoản, thư nhắc gia hạn.
- Kiểm từng mẫu đã có bản dịch, bản chữ thuần của email cũng đã dịch.
- Gửi thử tới thiết bị và hộp thư thật, xem tiêu đề bị cắt ở đâu, đoạn xem trước hiển thị gì.
- Thử với biến dài nhất có thể: tên người dài, mã đơn dài, số tiền lớn.
- Kiểm định dạng ngày, giờ, tiền theo vùng và múi giờ gửi.
- Với SMS, đếm độ dài theo mã hoá thật và quyết định có dấu hay không dấu.
- Đặt quy tắc không gửi khi thiếu bản dịch cho tin do đội vận hành soạn.
Dịch Hay dịch trọn bộ tin nhắn hệ thống cùng với giao diện, có kiểm độ dài theo màn hình khoá và theo mã hoá SMS cho từng ngôn ngữ. Bạn có thể gửi danh sách mẫu thư và mẫu tin nhắn hiện có trong mẫu đăng ký để được xem trước khối lượng.
Câu hỏi thường gặp
Có nên dịch tên người gửi email sang tiếng địa phương không?
Nên giữ tên thương hiệu nguyên dạng để người nhận nhận ra, phần mô tả bộ phận như "Hỗ trợ" hay "Hoá đơn" thì dịch. Đổi tên người gửi giữa các thư làm người nhận khó phân biệt thư thật với thư giả mạo, nên chốt một dạng cho mỗi ngôn ngữ và dùng thống nhất.
Tiêu đề email dịch dài hơn bản gốc nhiều thì xử lý sao?
Viết lại, không chỉ rút gọn từng chữ. Xác định thông tin người nhận cần nhất để mở thư, đặt nó lên đầu, phần còn lại đưa vào đoạn xem trước. Hộp thư trên điện thoại hiển thị tiêu đề ngắn hơn trên máy tính, nên kiểm trên điện thoại trước.
Tin nhắn mã xác thực có cần bản dịch riêng cho từng ngôn ngữ không?
Có, và nên dựa trên ngôn ngữ người dùng chọn trong ứng dụng hoặc vùng của số điện thoại. Tin mã xác thực bằng ngôn ngữ người nhận không đọc được khiến họ không hiểu câu cảnh báo, đúng chỗ kẻ lừa đảo lợi dụng. Cấu trúc tin và câu cảnh báo nên giữ thống nhất ở mọi ngôn ngữ.
Biểu tượng cảm xúc trong thông báo có cần dịch không?
Không dịch, nhưng nên được người bản xứ xem lại. Một số biểu tượng mang nghĩa khác nhau giữa các nền văn hoá, và mức độ dùng biểu tượng phù hợp cũng khác. Thông báo về tiền, bảo mật hay sự cố nên tránh biểu tượng ở mọi ngôn ngữ.
Có nên gửi thông báo bằng ngôn ngữ của thiết bị hay ngôn ngữ người dùng chọn trong ứng dụng?
Ưu tiên ngôn ngữ người dùng chọn trong ứng dụng nếu có, vì đó là lựa chọn chủ động. Nếu không có, dùng ngôn ngữ của thiết bị. Máy chủ cần lưu lựa chọn này cho từng người để thông báo và email gửi từ máy chủ dùng đúng ngôn ngữ, không mặc định theo vùng của máy chủ.
Thư huỷ nhận và phần chân thư có quy định riêng theo nước không?
Có, nhiều nước có luật về thư thương mại và bảo vệ dữ liệu quy định nội dung phải có, như thông tin bên gửi hay cách từ chối nhận. Bản dịch cần giữ đủ các nội dung đó, và nên nhờ người hiểu luật nước đích kiểm. Thư giao dịch thuần tuý thường có yêu cầu khác thư quảng cáo.