Bản địa hoá ứng dụng di động khác dịch website ở chỗ mọi thứ đều chật hơn, ngắn hơn và đến tay người dùng trong lúc họ đang bận việc khác. Một thông báo đẩy chỉ hiện vài giây trên màn hình khoá, một nút bấm chỉ đủ chỗ cho hai ba tiếng, một hộp thoại xin quyền truy cập vị trí quyết định người dùng có bấm đồng ý hay không.
Bài này dành cho người dịch nhận việc ứng dụng điện thoại và cho nhóm phát triển nhỏ muốn ra bản tiếng Việt. Nội dung đi theo đúng hành trình người dùng: thấy ứng dụng trên kho, tải về, mở lần đầu, được hỏi quyền, nhận thông báo, dùng hằng ngày. Ở mỗi chặng có những loại chuỗi riêng và cách dùng AI hỗ trợ phù hợp.
Vì sao ứng dụng điện thoại khó bản địa hoá hơn bạn nghĩ
Màn hình điện thoại hẹp và người dùng lại có thể tăng cỡ chữ trong cài đặt máy. Một chuỗi vừa khít ở cỡ chữ mặc định sẽ bị cắt, xuống dòng hoặc đè lên biểu tượng khi người lớn tuổi phóng to chữ. Tiếng Việt có dấu chồng phía trên và phía dưới, nên dòng chữ cần chiều cao lớn hơn chữ Latin không dấu; nếu nhóm thiết kế đặt chiều cao dòng sát theo tiếng Anh, phần dấu của những chữ như "Ổn", "Hủy", "Độ" dễ bị xén.
Ứng dụng cũng thường cập nhật liên tục, mỗi đợt thêm vài chục chuỗi rời rạc. Người dịch nhận từng lô nhỏ không kèm ngữ cảnh, dễ dịch lệch với những gì đã có. Đây là lý do bảng thuật ngữ và bộ nhớ dịch quan trọng với ứng dụng hơn với tài liệu một lần.
Cuối cùng, một phần nội dung không nằm trong ứng dụng mà nằm ở hệ điều hành và kho ứng dụng: tên hiển thị dưới biểu tượng, câu giải thích khi xin quyền, trang giới thiệu, ghi chú phiên bản. Những phần này thường do người khác trong nhóm quản lý, nên bị bỏ sót khỏi đợt dịch. Người dịch nên hỏi thẳng ngay từ đầu: ngoài tệp chuỗi, còn những văn bản nào người dùng Việt sẽ đọc.
Các loại chuỗi theo hành trình người dùng
Bảng dưới gom các loại chuỗi theo thứ tự người dùng gặp, kèm điều cần chú ý khi dịch sang tiếng Việt.
| Chặng | Loại chuỗi | Điều cần chú ý |
|---|---|---|
| Trên kho ứng dụng | Tên ứng dụng, câu mô tả ngắn, mô tả dài, chữ trên ảnh chụp giới thiệu, ghi chú phiên bản | Giới hạn ký tự của từng kho, từ khoá người Việt hay tìm, không hứa hẹn quá mức |
| Mở lần đầu | Màn hình chào, các bước giới thiệu tính năng | Câu ngắn, mỗi màn một ý, xưng hô nhất quán từ đầu |
| Xin quyền | Lý do cần quyền vị trí, máy ảnh, danh bạ, thông báo | Nói rõ để làm gì, không mơ hồ, không doạ |
| Dùng hằng ngày | Nút, nhãn, tiêu đề, thông báo lỗi, trạng thái trống | Động từ ngắn, thống nhất, thông báo lỗi chỉ cách sửa |
| Thông báo đẩy | Tiêu đề và nội dung hiện ngoài ứng dụng | Ý chính trong vài chữ đầu, tránh giật tít |
| Thanh toán, tài khoản | Gói dịch vụ, gia hạn, huỷ, xoá tài khoản | Rõ ràng tuyệt đối, đối chiếu với điều khoản đã dịch |
Chữ trên ảnh chụp giới thiệu là phần hay bị quên nhất. Nhóm thiết kế làm ảnh bằng phần mềm đồ hoạ, chữ nằm trong ảnh nên không đi qua tệp chuỗi. Nếu không dịch, trang tiếng Việt trên kho sẽ có mô tả tiếng Việt nhưng ảnh toàn tiếng Anh, trông như làm dở.
Câu xin quyền truy cập: ngắn mà phải thật
Nói rõ ứng dụng dùng quyền đó để làm gì. Hệ điều hành cho phép ứng dụng ghi một câu giải thích khi xin quyền. Câu tiếng Anh gốc đôi khi rất chung chung. Bản tiếng Việt nên cụ thể hơn nếu được khách cho phép, ví dụ giả định: "Cho phép dùng vị trí để tìm cửa hàng gần bạn và tính phí giao hàng".
Không thêm điều bản gốc không cam kết. Người dịch đôi khi muốn viết cho thuyết phục, thêm câu như "dữ liệu của bạn luôn an toàn tuyệt đối". Nếu bản gốc và chính sách dữ liệu không nói vậy, bạn đang tạo ra một lời hứa mà khách phải chịu trách nhiệm. Chỉ dịch đúng những gì được cam kết.
Giọng nhẹ nhàng, không ép. Tránh những câu kiểu "Bạn phải cho phép để tiếp tục" khi thực tế ứng dụng vẫn dùng được không cần quyền đó. Người dùng Việt ngày càng để ý chuyện quyền riêng tư; câu ép buộc làm họ từ chối nhiều hơn.
Đối chiếu với chính sách quyền riêng tư bản tiếng Việt. Tên loại dữ liệu trong câu xin quyền nên trùng với cách gọi trong chính sách. Nếu chính sách gọi là "dữ liệu vị trí chính xác" thì câu xin quyền không nên gọi là "toạ độ" hay "định vị", để người đọc thấy đó là cùng một thứ.
Thông báo đẩy: viết cho màn hình khoá
Thông báo đẩy thường bị cắt sau một hai dòng và hiện chung với hàng chục thông báo khác. Một số nguyên tắc khi dịch hoặc viết lại:
- Đưa thông tin chính lên đầu: "Đơn hàng đang giao, dự kiến 15 phút" tốt hơn "Tin vui cho bạn: đơn hàng của bạn đã được người giao hàng nhận và đang trên đường giao".
- Giữ biến số nguyên vẹn, kiểm chỗ đặt biến để tên món hàng hay tên người không bị đẩy ra ngoài phần hiển thị.
- Không dịch theo lối giật tít quảng cáo nếu bản gốc không có ý đó; người dùng tắt thông báo khi thấy bị làm phiền.
- Thông báo về tiền, bảo mật, đăng nhập lạ phải trung tính, rõ, không dùng biểu tượng cảm xúc.
- Với thông báo tiếp thị theo dịp lễ, kiểm xem ngày đó có ý nghĩa ở Việt Nam không; một khuyến mãi theo ngày lễ nước ngoài có thể cần đổi sang dịp khác do bộ phận tiếp thị quyết.
- Thống nhất cách gọi người dùng giữa thông báo đẩy và trong ứng dụng.
AI làm khá tốt việc rút gọn thông báo khi bạn đưa đủ ràng buộc. Câu lệnh mẫu: "Rút gọn thông báo sau còn tối đa 60 ký tự, giữ nguyên biến {order_id}, đưa thông tin trạng thái lên đầu, xưng bạn, không dùng biểu tượng cảm xúc. Đưa ba phương án." Bạn chọn một và tự đọc lại trên điện thoại thật.
Trang giới thiệu trên kho ứng dụng: dịch hay viết lại
Trang giới thiệu là văn bản tiếp thị, nên nhiều khi viết lại cho người Việt hiệu quả hơn dịch sát. Người dùng trong nước tìm ứng dụng bằng những cụm từ đời thường, ví dụ "ứng dụng ghi chi tiêu", "học từ vựng mỗi ngày", chứ ít khi gõ đúng tên tính năng tiếng Anh. Nếu khách đồng ý, bạn có thể đề xuất một phiên bản mô tả viết theo cách người Việt tìm kiếm, kèm bản dịch sát để khách so sánh.
Câu mô tả ngắn đầu trang là phần quan trọng nhất vì nhiều người chỉ đọc đến đó. Nó nên nói ứng dụng giúp ai làm việc gì, không nên là một khẩu hiệu mơ hồ. Mô tả dài nên chia đoạn ngắn, mỗi đoạn một tính năng, viết bằng lợi ích người dùng nhận được. Tránh những từ so sánh tuyệt đối như "tốt nhất", "số một" khi không có căn cứ, vì vừa thiếu thuyết phục vừa có thể vi phạm quy định quảng cáo.
Ghi chú phiên bản thường bị dịch qua loa, nhưng người dùng hay đọc để biết lỗi mình gặp đã được sửa chưa. Hãy dịch cụ thể, tránh câu chung chung kiểu "sửa lỗi và cải thiện hiệu năng" lặp lại mọi phiên bản khi bản gốc có nội dung rõ hơn. Giới hạn ký tự từng phần của mỗi kho khác nhau và có thể thay đổi, nên hỏi khách hoặc kiểm hướng dẫn hiện hành của kho trước khi viết.
Thử bản tiếng Việt trên máy thật
Bản dịch ứng dụng chưa xem trên điện thoại thì chưa xong. Nếu khách cho bạn bản thử, đây là vòng kiểm nhanh khoảng một hai giờ:
- Đặt ngôn ngữ máy sang tiếng Việt, vùng Việt Nam, rồi mở ứng dụng từ đầu như người dùng mới.
- Đi hết các màn hình chính, chụp lại chỗ chữ bị cắt, bị xuống dòng xấu, dấu bị xén.
- Tăng cỡ chữ của máy lên mức lớn, đi lại những màn hình đó lần nữa.
- Thử các trạng thái đặc biệt: chưa có dữ liệu, mất mạng, nhập sai, hết hạn gói.
- Kiểm ngày, giờ, số, tiền hiển thị đúng kiểu Việt Nam.
- Kích hoạt một vài thông báo đẩy nếu được, xem trên màn hình khoá.
- Ghi lỗi vào bảng gồm vị trí màn hình, ảnh chụp, chuỗi hiện tại, đề xuất sửa.
Nếu có cả máy màn hình nhỏ và máy màn hình lớn, thử cả hai. Lỗi tràn chữ thường chỉ xuất hiện trên máy nhỏ, mà người dùng máy nhỏ ở Việt Nam không ít. Ảnh chụp màn hình bản thử có thể chứa dữ liệu thử nghiệm của khách; đừng dán chúng vào chatbot công cộng khi chưa che.
Bảo mật khi dịch ứng dụng chưa ra mắt
Ứng dụng đang phát triển là tài sản nhạy cảm: tên tính năng, giá gói, kế hoạch ra mắt đều có thể là bí mật kinh doanh. Nhiều khách yêu cầu người dịch ký thoả thuận bảo mật trước khi gửi tệp. Kể cả khi không có thoả thuận, bạn vẫn nên xử lý như có.
Với AI, nguyên tắc là chỉ đưa vào công cụ mà khách đồng ý, bằng tài khoản có tuỳ chọn không dùng dữ liệu để huấn luyện nếu có, và che những gì không cần cho việc dịch như tên sản phẩm chưa công bố, tên đối tác, con số kinh doanh. Thay chúng bằng ký hiệu chung, dịch xong mới điền lại. Tài khoản đăng nhập bản thử, nếu khách cấp, chỉ dùng cho việc kiểm, không chia sẻ cho người khác trong nhóm khi chưa hỏi.
Khi dự án kết thúc, hỏi khách muốn bạn xử lý tệp thế nào: xoá hết, hay giữ bộ nhớ dịch để phục vụ các bản cập nhật. Ghi lại câu trả lời, vì một năm sau khi khách quay lại, bạn sẽ cần biết mình còn giữ gì.
Câu hỏi thường gặp
Tên ứng dụng có nên dịch sang tiếng Việt không?
Thường giữ nguyên tên thương hiệu, nhưng nhiều kho cho phép thêm một phần mô tả ngắn sau tên. Phần đó có thể viết tiếng Việt để người dùng hiểu ứng dụng làm gì. Quyết định cuối cùng thuộc về khách, người dịch chỉ đề xuất.
Làm sao biết chuỗi có bị tràn trên điện thoại khi không có bản thử?
Hỏi khách giới hạn ký tự cho từng loại chuỗi, so độ dài bản dịch với bản gốc, đánh dấu những chuỗi dài hơn đáng kể. Ghi rõ trong bàn giao rằng chưa kiểm trên giao diện, đề nghị khách gửi ảnh chụp bản thử để rà vòng hai.
Có nên viết thông báo đẩy vui nhộn như ứng dụng nước ngoài không?
Tuỳ thương hiệu và đối tượng. Giọng vui có thể hợp ứng dụng giải trí cho người trẻ nhưng không hợp ứng dụng ngân hàng hay y tế. Khi chưa có hướng dẫn văn phong, chọn giọng trung tính và hỏi khách trước khi thêm sự dí dỏm.
Câu giải thích xin quyền có thể dịch thoáng không?
Có thể diễn đạt tự nhiên hơn, nhưng không được thêm cam kết mà bản gốc và chính sách quyền riêng tư không có. Câu này liên quan tới dữ liệu cá nhân, nên mọi thay đổi về nội dung cần khách duyệt.
AI có viết được mô tả ứng dụng cho người Việt không?
AI viết được bản nháp khá trôi, đặc biệt khi bạn đưa đủ thông tin về tính năng và người dùng mục tiêu. Nhưng bạn cần kiểm từng tính năng có thật không, bỏ các lời hứa phóng đại, và đối chiếu giới hạn ký tự hiện hành của kho.
Ứng dụng cập nhật hằng tuần thì người dịch nên làm thế nào?
Thống nhất với khách một nhịp gửi chuỗi cố định, dùng bộ nhớ dịch và bảng thuật ngữ để giữ nhất quán, và yêu cầu mỗi lô kèm ghi chú màn hình. Chuỗi gấp ngoài nhịp nên được đánh dấu để rà lại trong lô kế tiếp.