Dịch file PO không chỉ là điền câu tiếng Việt vào những dòng còn trống. Một bản dịch có thể đọc rất ổn khi mở tệp nhưng trở nên khó hiểu khi xuất hiện trên nút bấm, thông báo hoặc màn hình cài đặt. Điều cần chuẩn bị là một cách phối hợp: người dịch biết câu đang làm nhiệm vụ gì, người phát triển biết phần nào đã được duyệt, còn người đặt dịch kiểm tra được kết quả trên đúng phiên bản website.
Dịch vụ liên quan: Dịch thuật chuyên ngànhDịch thuật công chứngHiệu đính bản dịch
Trước khi gửi file PO, hãy xác định kết quả mình cần nhận
Có doanh nghiệp cần chuyển toàn bộ giao diện sang tiếng Việt, có đội chỉ cần rà soát phần thanh toán trước khi mở bán. Hai công việc ấy không nên được mô tả bằng cùng một câu “dịch file này”. Hãy ghi tên sản phẩm, phiên bản và nhóm màn hình nằm trong đợt triển khai. Nếu chỉ dịch một phần, cần chỉ được phần đó bằng bộ lọc, danh sách hoặc mã chuỗi để người nhận không phải đoán.
Tiếp theo là định dạng bàn giao. Bạn cần tệp để nhập vào hệ thống, bản song ngữ để đội nội bộ đọc hay cả hai? Người chịu trách nhiệm nhập bản dịch là ai? Mốc được gọi là hoàn thành là lúc gửi tệp hay lúc kiểm xong trên môi trường thử? Những câu hỏi này cần được chốt từ đầu bởi chúng ảnh hưởng đến thời gian duyệt, công kiểm tra và cách ghi nhận lỗi.
Một brief đủ dùng có thể viết như sau: dịch phần tài khoản và đặt hàng của bản phát hành tháng tới; giữ tên sản phẩm theo danh mục đã duyệt; trả tệp PO cùng danh sách câu hỏi còn mở; đội phát triển nhập vào môi trường thử; bộ phận nội dung duyệt trong hai ngày làm việc đã thống nhất. Brief không cần dài, nhưng phải cho biết ai làm gì và bằng chứng nào xác nhận đã xong.
Nhận diện phần nội dung và phần cấu trúc trước khi sửa
Trong PO, msgid thể hiện chuỗi nguồn, còn msgstr chứa bản dịch. Ngữ cảnh có thể được phân biệt bằng msgctxt; các mục số nhiều có cấu trúc riêng. Cờ fuzzy báo một mục cần được xem lại trong quy trình dịch. Đây là những thông tin nên để người xử lý tệp hiểu rõ trước khi chỉnh sửa, thay vì coi toàn bộ chữ nhìn thấy là nội dung được quyền thay.
Về cách tổ chức công việc, nên giao một tệp mẫu nhỏ trước. Chọn mẫu có câu đơn, câu có biến, thông báo dài và một trường hợp mơ hồ. Đội kỹ thuật kiểm tra việc nhập lại, người phụ trách nội dung xem cách thể hiện tiếng Việt. Nếu mẫu đã gặp vấn đề, sửa quy ước khi phạm vi còn nhỏ sẽ nhẹ hơn so với xử lý cả tệp sau khi người dịch đã hoàn thành.
Người đặt dịch không cần tự học mọi chi tiết định dạng, nhưng cần biết đầu mối chịu trách nhiệm giải quyết lỗi kỹ thuật. Nếu một công cụ cảnh báo tệp không hợp lệ, đừng chỉ yêu cầu người dịch gửi lại dưới tên khác. Hãy lưu thông báo, ghi bước gây lỗi và kiểm tra bằng đúng quy trình nhập của dự án. Đổi đuôi tệp hoặc sao chép sang một tài liệu Word không giải quyết được nguyên nhân.
Ngữ cảnh tốt thường bắt đầu từ một ảnh màn hình đúng chỗ
Một từ ngắn có thể mất nhiều thời gian hơn một đoạn giới thiệu sản phẩm. Chẳng hạn, “Open” ở một nơi là thao tác mở tài liệu, ở nơi khác là trạng thái của yêu cầu hỗ trợ. Nếu người dịch chỉ thấy danh sách từ, họ có thể chọn một cách dùng hợp lý về ngôn ngữ nhưng sai chức năng. Ảnh màn hình và mô tả trạng thái giúp giải quyết sự mơ hồ ấy.
Không cần chụp mọi màn hình khi số chuỗi lớn. Hãy ưu tiên nhóm rủi ro: nút quyết định, tên trạng thái, thông báo lỗi, câu có từ viết tắt và những mục người dùng nhìn thấy trước khi xác nhận hành động. Mỗi ảnh nên đi cùng mã tham chiếu đủ để tìm câu trong tệp. Một thư mục ảnh không có liên hệ với chuỗi khiến người dịch lại phải hỏi câu nào nằm ở đâu.
Mô tả ngữ cảnh nên trả lời ba câu: ai đọc, họ vừa làm gì và sau câu này họ cần làm gì. Ví dụ, khách đã nhập email nhưng chưa xác minh, thông báo xuất hiện sau lần gửi liên kết thứ hai, hành động tiếp theo là kiểm tra hộp thư hoặc đổi địa chỉ. Với mô tả đó, người dịch có thể chọn câu rõ ràng hơn nhiều so với chỉ nhận một ghi chú “thông báo hệ thống”.
Giữ tên thao tác nhất quán mà vẫn đúng từng màn hình
Một website thường có các thao tác lưu, gửi, xác nhận, tiếp tục và hoàn tất. Nếu tất cả đều được chuyển thành “Xác nhận”, người dùng khó biết nút có tác dụng gì. Ngược lại, nếu cùng một thao tác được gọi ba cách, họ có thể tưởng có sự khác biệt về chức năng. Bảng quy ước nên xuất phát từ hành động thực, không chỉ từ một danh sách từ nguồn.
Bạn có thể lập bảng gồm tên thao tác, điều kiện xuất hiện, kết quả sau khi bấm và cách gọi được duyệt. “Lưu thay đổi” phù hợp khi dữ liệu được ghi lại nhưng người dùng vẫn ở trang hiện tại. “Gửi yêu cầu” phù hợp khi thông tin được chuyển đi để xử lý. Các lựa chọn cuối cùng cần được người hiểu sản phẩm xác nhận; người dịch không nên tự cam kết hệ thống làm một việc mà nó chưa thực hiện.
Khi trao đổi với đơn vị dịch website, hãy gửi cả những cách gọi doanh nghiệp đã dùng ở email hoặc trang trợ giúp. Nếu tên trên giao diện thay đổi, nội dung hướng dẫn liên quan cũng cần được rà soát. Người đọc không nên phải tự suy ra rằng “Hồ sơ”, “Tài khoản” và “Thông tin cá nhân” đang cùng chỉ một mục chỉ vì các phần được dịch ở ba thời điểm khác nhau.
Biến, tên riêng và dữ liệu động cần một bảng kiểm riêng
Các câu có tên khách, số đơn hàng hoặc thời điểm giao dự kiến phải được kiểm bằng dữ liệu đại diện. Một câu trôi chảy khi đọc với ví dụ ngắn có thể bị tràn khi tên dài hơn. Một khoảng trống trong chuỗi không có nghĩa hệ thống sẽ tự thêm dấu cách đúng vị trí. Vì thế, cần xem cả câu hoàn chỉnh sau khi dữ liệu được điền vào, thay vì chỉ đọc phần văn bản cố định.
Trong brief, ghi rõ phần nào phải bảo toàn theo quy ước của đội phát triển. Khi người dịch thấy biến không phù hợp thứ tự câu tiếng Việt, họ nên nêu câu hỏi cùng đề xuất diễn đạt. Người phát triển kiểm tra hệ thống có cho phép thay vị trí hay cần điều chỉnh cách tạo câu. Không tự đổi tên biến chỉ để dễ đọc trong tệp, bởi tên ấy có thể đang liên kết với dữ liệu được chương trình cung cấp.
Dữ liệu thử nên có trường hợp bình thường và trường hợp khó: tên ngắn, tên dài, không có tên hiển thị, mã đơn dài và giá trị bằng không nếu màn hình có tình huống đó. Không cần dùng thông tin thật của khách hàng để chứng minh câu hoạt động. Điều cần là một bộ mẫu có chủ đích và kết quả mong đợi được ghi rõ, để người kiểm biết lỗi nằm ở câu chữ hay cách hệ thống đưa dữ liệu vào.
Đừng xem mọi mục đã có bản dịch là đã được duyệt
Khi cập nhật nguồn, một số câu cũ có thể còn bản dịch nhưng cần đọc lại vì nghĩa hoặc ngữ cảnh đã đổi. Người quản lý nên tách tối thiểu ba nhóm công việc: chưa dịch, cần xem lại và đã duyệt cho bản phát hành. Cách đặt nhãn cụ thể tùy công cụ, nhưng ý nghĩa phải thống nhất giữa người dịch và người nhận. Nếu chỉ đếm số ô có chữ, báo cáo tiến độ dễ tạo cảm giác hoàn tất quá sớm.
Một câu nguồn chỉ thay một từ vẫn có thể đổi quyết định của người dùng. Ví dụ, từ cho phép trở thành không cho phép, từ lưu tạm thành gửi chính thức, hoặc từ ngày dự kiến thành ngày đã xác nhận. Người rà soát cần đọc cả phần thay đổi và màn hình liên quan. Không nên tự động giữ bản dịch cũ chỉ vì tỷ lệ giống nhau cao hoặc vì câu nhìn ngắn.
Hãy quy định ai có quyền chuyển trạng thái sang đã duyệt. Với nội dung nghiệp vụ, người dịch có thể hoàn tất ngôn ngữ nhưng vẫn cần chủ sản phẩm xác nhận chức năng. Với tên thương hiệu, bộ phận phụ trách thương hiệu cần chốt cách dùng. Việc phân vai giúp tránh tình huống tất cả đều nghĩ người khác đã đọc, đến lúc phát hành mới phát hiện một câu đang mô tả sai thao tác quan trọng.
Tình huống: bản dịch đúng nghĩa nhưng khách vẫn không biết phải làm gì
Giả sử một website bán hàng có thông báo nguồn ngắn với ý “Không thể hoàn tất”. Bản dịch tiếng Việt giữ đúng nghĩa nhưng không cho khách biết thông tin đã lưu chưa, họ có bị trừ tiền không hay nên thử lại ở đâu. Người dịch cần báo đây là điểm thiếu thông tin trong nguồn, không nên tự thêm lời khẳng định về thanh toán. Đội sản phẩm phải xác nhận tình trạng trước khi duyệt câu cuối.
Một cách xử lý thực tế là ghi câu hỏi theo cấu trúc: màn hình nào, hành động trước đó, điều chưa rõ và thông tin cần xác nhận. Sau khi được trả lời rằng yêu cầu chưa gửi và người dùng có thể sửa địa chỉ, bản dịch mới có cơ sở hướng dẫn thao tác tiếp. Người dịch cải thiện cách nói trong giới hạn đã xác nhận; không dùng sự tự nhiên của câu để che đi một khoảng trống về nghiệp vụ.
Tình huống này cũng cho thấy kiểm ngôn ngữ cần một đầu mối phản hồi nhanh. Nếu mọi câu hỏi đều phải chuyển qua nhiều người mà không ai chốt, tiến độ sẽ chậm dù số chữ ít. Doanh nghiệp nên gom câu hỏi theo nhóm màn hình, ưu tiên vấn đề chặn sử dụng và thống nhất giờ nhận phản hồi. Cách làm ấy thường hiệu quả hơn gửi hàng chục tin nhắn rời với các ảnh không được đánh số.
Nghiệm thu trên giao diện theo hành trình, không chỉ theo danh sách chuỗi
Đọc tệp theo thứ tự là bước cần thiết nhưng chưa đủ. Khi kiểm trên website, hãy đi theo những hành trình người dùng thực hiện: tạo tài khoản, xác minh, đổi thông tin, đặt hàng hoặc gửi yêu cầu hỗ trợ. Trong một hành trình, tên gọi cần khớp từ đầu đến cuối. Một câu có thể tốt khi đứng riêng nhưng trở nên lặp, mâu thuẫn hoặc thiếu chủ thể khi đặt cạnh phần còn lại.
Mỗi lỗi nên được ghi bằng phiên bản đang kiểm, ngôn ngữ, màn hình, thao tác tái hiện, câu hiện tại và đề nghị sửa. Nếu có ảnh, đánh dấu đúng vị trí. Tránh phản hồi kiểu “dịch chưa hay” vì người xử lý không biết bạn đang nói về nghĩa, giọng văn hay bố cục. Một đề nghị cụ thể giúp người dịch giải thích lựa chọn, đồng thời giúp đội phát triển phân biệt lỗi nội dung với lỗi hiển thị.
Ưu tiên sửa các lỗi làm người dùng hiểu sai hành động, không hoàn thành được việc hoặc đưa ra quyết định trên thông tin sai. Sau đó mới xử lý khác biệt nhỏ về văn phong. Nếu phải phát hành theo đợt, ghi rõ phần đã kiểm và phần chưa nằm trong phạm vi. Một email nói “đã kiểm website” dễ bị hiểu quá rộng; danh sách hành trình cùng kết quả là bằng chứng rõ hơn.
Phản hồi hiệu quả: một vấn đề, một quyết định được lưu lại
Khi nhiều phòng ban cùng duyệt, họ có thể dùng các thuật ngữ khác nhau cho cùng một chức năng. Người tổng hợp cần làm rõ lý do của từng đề nghị, không chỉ chuyển nguyên mọi câu sửa cho người dịch. Ý kiến dựa trên chức năng thực nên được ưu tiên xác minh; lựa chọn sở thích cần được chốt theo quy ước chung. Nếu không, một câu sẽ bị đổi qua lại mà chất lượng không tăng.
Nên có một danh sách phản hồi chính thức. Mỗi dòng chứa mã vấn đề, nội dung, người chốt và trạng thái. Các trao đổi bên ngoài danh sách cần được đưa trở lại trước lần sửa cuối. Điều này đặc biệt hữu ích khi một người góp ý bằng email, người khác bình luận trên ảnh và người thứ ba sửa trực tiếp tệp. Chỉ một nguồn phản hồi cuối mới giúp kiểm tra rằng mọi quyết định đã được áp dụng.
Với câu đang còn tranh luận, đừng đánh dấu hoàn tất để báo cáo đẹp. Ghi rõ đang chờ ai xác nhận và ảnh hưởng đến màn hình nào. Nếu nhóm quyết định tạm dùng một phương án, lưu lý do và thời điểm xem lại. Một bản dịch được quản lý tốt không cần mọi người nhớ từng cuộc trò chuyện; người mới tiếp nhận dự án vẫn đọc được vì sao lựa chọn cuối đã được chấp thuận.
Bàn giao để lần cập nhật sau không phải bắt đầu lại
Bộ bàn giao nên gọn nhưng đủ dùng: tệp cuối theo quy ước, danh mục những gì đã kiểm, bảng thuật ngữ có thay đổi và danh sách vấn đề còn mở nếu có. Tên tệp cần phân biệt ngôn ngữ, phiên bản nguồn và ngày bàn giao. Không dùng nhiều tệp cùng tên “final” rồi trông chờ người nhận tự biết tệp nào mới nhất qua thời gian tải xuống.
Nên lưu cả bản nguồn tương ứng với lần bàn giao. Khi website bổ sung tính năng, đội triển khai cần so được nguồn mới với bộ đã dịch, thay vì đoán dựa trên trí nhớ. Một yêu cầu sửa câu cũ do thay nghiệp vụ khác với hiệu đính cách diễn đạt chưa ổn. Phân biệt hai loại thay đổi giúp ước tính đúng công việc và bảo đảm những phần bị ảnh hưởng được kiểm lại.
Nếu doanh nghiệp đổi người phụ trách, bảng quy ước và hồ sơ quyết định sẽ giảm khoảng trống bàn giao. Người mới biết thuật ngữ nào đã được duyệt, nhóm màn hình nào còn chờ và những trường hợp nào từng gây nhầm. Với nhu cầu tương tự trong ứng dụng, có thể trao đổi cùng dịch vụ dịch nội dung app để giữ cách gọi nhất quán giữa website và sản phẩm trên điện thoại.
Câu hỏi thường gặp khi đặt dịch PO
Khách hàng thường hỏi giá dựa trên số dòng hay số từ. Một tệp có nhiều câu lặp nhưng ít ngữ cảnh có thể mất công hỏi và kiểm hơn dự kiến; một bộ đã có bảng thuật ngữ và ảnh màn hình thường thuận lợi hơn. Vì vậy, nên gửi mẫu nguồn và mô tả đầu ra để được xem phạm vi, thay vì chỉ thông báo tổng số mục. Phần kiểm giao diện cũng cần được trao đổi riêng nếu muốn đưa vào công việc.
Nếu website cần chạy sớm, hãy chọn một nhóm hành trình hoàn chỉnh để ưu tiên. Dịch ngẫu nhiên những câu ngắn trước có thể tạo ra các màn hình nửa tiếng Việt nửa ngôn ngữ khác. Nhóm ưu tiên nên bao gồm nhãn, nút, lỗi và thông báo kết quả của cùng một việc. Sau khi nhóm đó được kiểm, mở rộng sang nhóm tiếp theo sẽ dễ giữ chất lượng hơn.
Bạn có thể tham khảo thêm cách dịch website sang tiếng Việt tự nhiên và quản lý thuật ngữ tài liệu phần mềm khi chuẩn bị brief. Khi đã có tệp và phạm vi, gửi qua trang báo giá nhanh để trao đổi phần dịch, rà soát và đầu ra. Một yêu cầu rõ giúp cuộc trao đổi đi thẳng vào việc cần làm, thay vì mất nhiều lượt chỉ để tìm đúng phiên bản nguồn.
Câu hỏi thường gặp
Chỉ có file PO, chưa có ảnh màn hình thì có dịch được không?
Có thể bắt đầu với những câu đủ rõ, nhưng nên tách các mục cần ngữ cảnh thành danh sách câu hỏi. Cung cấp thêm môi trường thử hoặc ảnh cho nút, trạng thái và lỗi sẽ giúp giảm sửa lại. Không nên duyệt toàn bộ tệp chỉ dựa trên việc các dòng đã được điền đầy đủ.
Có cần dịch tên sản phẩm trong tệp không?
Cần theo quy ước thương hiệu của doanh nghiệp. Tên có thể giữ nguyên trong khi phần mô tả xung quanh được dịch. Nếu chưa có quy ước, gửi danh mục tên và người có quyền chốt; tránh để nhiều người dịch tự chọn mỗi người một cách.
Người nội bộ sửa trực tiếp bản dịch có được không?
Được nếu người sửa hiểu phạm vi và quy trình kiểm lại. Nên lưu phản hồi cùng lý do để kiểm tra tác động đến câu tương tự. Một chỉnh sửa nhỏ có thể làm khác thuật ngữ hoặc làm mất biến, vì vậy vẫn cần bước rà soát trước khi đưa lên bản phát hành.
Một câu xuất hiện ở nhiều nơi nên dịch giống nhau hoàn toàn không?
Cần xem chức năng và ngữ cảnh thực. Cùng một nghĩa và hành động nên giữ nhất quán; cùng chữ nguồn nhưng khác vai trò có thể cần cách diễn đạt khác. Hãy để đội phát triển xác nhận cách tổ chức tài nguyên nếu hai vị trí đang dùng chung một mục.
Làm sao biết bản dịch bị cắt do nội dung hay do thiết kế?
Ghi ảnh, kích thước màn hình và câu đầy đủ mong muốn, rồi kiểm với đội phát triển. Có thể cần diễn đạt gọn hơn, nhưng cũng có thể vùng hiển thị không cho xuống dòng phù hợp. Không nên cắt mất điều kiện quan trọng chỉ để vừa một ô mà chưa xem giải pháp bố cục.
Có thể dùng bản dịch máy để làm bản đầu không?
Có thể đưa vào quy trình nếu được thống nhất, nhưng phải rà soát nghĩa, ngữ cảnh, biến và thuật ngữ. Nội dung có sẵn trong ô dịch không chứng minh đã được duyệt. Những câu ảnh hưởng thao tác và thông tin nghiệp vụ cần người có trách nhiệm kiểm lại trước phát hành.
Sau khi website cập nhật có phải dịch lại mọi thứ không?
Không nhất thiết. Cần xác định phần mới, phần sửa và những mục bị ảnh hưởng bởi thay đổi tên gọi hoặc chức năng. Lưu nguồn tương ứng với bản dịch trước giúp đối chiếu chính xác hơn. Phần kiểm lại nên theo các hành trình liên quan, không chỉ theo số chuỗi mới.
Tệp bàn giao đã đúng rồi mà website còn hiện nguồn thì xử lý thế nào?
Trước tiên ghi phiên bản, màn hình và chuỗi đang thấy; xác nhận đội triển khai đã nhập đúng tệp và đúng ngôn ngữ. Người dịch hỗ trợ đối chiếu nội dung đã giao, còn đội kỹ thuật kiểm quy trình tích hợp. Tránh sửa đi sửa lại bản dịch khi chưa xác định website thực sự đang sử dụng bản nào.
