DichHay.comDịch Hay
Dịch phần mềm và ứng dụng

Dịch thông báo đẩy, email và tin nhắn của ứng dụng: ngắn, đúng giờ, đúng giọng

Thông báo đẩy bị cắt trên màn hình khoá, email giao dịch vào thư rác, tin nhắn có dấu tốn gấp đôi. Cách dịch tin nhắn hệ thống của ứng dụng cho người nhận ở nước khác.

Close-up of a phone lying face up on a bedside table at dawn, its dark blank screen catching soft window light, a ceramic cup beside it, muted teal and rose tones

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ầnGhi chú khi dịchNếu bỏ sót
Tên người gửiTê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ácThư bị bỏ qua hoặc vào thư rác
Đoạn xem trướcDò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útNú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ầnPhiên bản không định dạng gửi kèm cho trình đọc thư đơn giảnMộ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ộcThiế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 ảnhPhầ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:

  1. 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.
  2. Kiểm từng mẫu đã có bản dịch, bản chữ thuần của email cũng đã dịch.
  3. 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ì.
  4. 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.
  5. Kiểm định dạng ngày, giờ, tiền theo vùng và múi giờ gửi.
  6. Với SMS, đếm độ dài theo mã hoá thật và quyết định có dấu hay không dấu.
  7. Đặ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.

Cần tư vấn cụ thể cho trường hợp của bạn?

Chúng tôi sẽ liên hệ trong vòng 24 giờ.

Đăng ký tư vấn ngay

Bài viết liên quan

Gửi yêu cầu dịch

Cho biết loại dịch vụ, ngôn ngữ và nơi bản dịch sẽ dùng. Chúng tôi xem yêu cầu, liên hệ lại để nhận tệp mẫu hoặc chương trình sự kiện và báo phương án phù hợp.

Thông tin chỉ dùng để liên hệ về yêu cầu dịch của bạn. Đừng dán tài liệu mật vào ô ghi chú — chúng tôi sẽ hướng dẫn cách gửi tệp an toàn khi liên hệ lại.