Bạn nhận được một tệp XLF từ đội phát triển và được nhờ tìm người dịch trước ngày ra mắt sản phẩm. Mở tệp ra, câu chữ nằm xen giữa các phần đánh dấu khó đọc. Việc cần làm đầu tiên không phải sao chép mọi câu sang Word, mà là xác định cách đưa bản dịch quay lại đúng hệ thống. Bài viết này giúp người đặt dịch tổ chức công việc từ lúc nhận tệp đến khi kiểm bản hoàn chỉnh, với trọng tâm là phối hợp và tránh mất thông tin.
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
XLIFF là tệp trao đổi bản dịch, không phải bản xem cuối
XLIFF dùng cấu trúc để trao đổi nội dung nguồn và đích giữa những công cụ trong quy trình bản địa hóa. Tệp có thể chứa mã định danh, ghi chú và thẻ nội tuyến ngoài câu chữ. Các phiên bản định dạng có khác biệt, vì vậy cần xác nhận phiên bản mà công cụ xuất và công cụ nhận hỗ trợ. Không nên đổi phiên bản chỉ bằng cách sửa một con số trong tệp.
Ở góc độ người đặt dịch, điều quan trọng là tệp không cho thấy toàn bộ trải nghiệm đọc. Một đoạn có thể xuất hiện trên trang trợ giúp, một đoạn khác nằm trong cửa sổ xác nhận. Người dịch cần thông tin về nơi sử dụng để viết đúng giọng và mức giải thích. Tệp đúng định dạng vẫn cần được đọc trên đầu ra mà khách hàng hoặc nhân viên thực sự sử dụng.
Nếu dự án gồm website, app và tài liệu hướng dẫn, hãy chỉ rõ mỗi tệp thuộc phần nào. Đừng gom tất cả dưới tên “nội dung hệ thống” rồi để người dịch tự phân loại qua những câu rời. Mục tiêu không phải thêm thủ tục, mà là giúp một câu hỏi được gửi đến đúng người có thể trả lời. Người hiểu sản phẩm và người hiểu công cụ đôi khi là hai đầu mối khác nhau.
Làm một lần thử xuất, dịch và nhập trước khi giao cả bộ
Bước thử nên dùng một mẫu đủ đại diện. Chọn đoạn có chữ đậm hoặc liên kết, câu chứa biến, phần ngắn trên nút và đoạn dài trong bài hướng dẫn. Dịch mẫu rồi nhập lại bằng đúng quy trình dự kiến sử dụng cho bản cuối. Nếu chỉ thử một câu thuần văn bản, bạn chưa kiểm được các trường hợp có nhiều khả năng phát sinh vấn đề khi làm toàn bộ.
Trong lần thử, đội phát triển kiểm nội dung có về đúng vị trí không, các phần đánh dấu có còn hoạt động không và tệp có đi qua công cụ nhận bình thường không. Người phụ trách nội dung xem câu trên đầu ra và phản hồi về thuật ngữ. Mỗi bên cần ghi kết quả mình đã kiểm, tránh một lời xác nhận chung khiến mọi người tưởng cả kỹ thuật lẫn ngôn ngữ đều đã được duyệt.
Nếu mẫu không nhập được, lưu tệp trước và sau xử lý cùng thông báo lỗi. Đừng sửa trực tiếp nhiều lần rồi làm mất dấu thay đổi. Một lỗi tái hiện được trên mẫu nhỏ thường dễ trao đổi hơn lỗi chỉ xuất hiện trong bộ hàng nghìn câu. Sau khi quy trình mẫu ổn, dùng cùng quy ước cho các tệp tiếp theo và báo lại khi có thay đổi công cụ hoặc thiết lập.
Chốt nguồn bằng danh mục có phiên bản và phạm vi
Một danh mục nguồn hữu ích gồm tên tệp, ngôn ngữ nguồn, ngôn ngữ đích, phần sản phẩm, phiên bản và đầu mối phụ trách. Thêm cột phạm vi nếu không dịch toàn bộ. Với bộ xuất từ nhiều khu vực quản trị, cần biết tệp nào thay thế tệp nào và có mục trùng giữa các lần xuất không. Số lượng tệp không nói được đầy đủ khối lượng khi nội dung có sự lặp và thay đổi.
Trước khi gửi, mở thử để bảo đảm đó là bộ đã được chốt cho đợt làm việc. Các tên như mới nhất hoặc bản cuối thường chỉ có ý nghĩa ở thời điểm người đặt tên nhớ rõ. Nếu nguồn còn thay đổi, đừng giấu điều đó; chia phần ổn định và phần đang chờ duyệt, thống nhất thời điểm khóa nguồn. Người dịch cần biết câu nào có thể làm trước và câu nào chưa nên chốt.
Những tệp dùng để tham khảo phải được đặt riêng và có mô tả. Bản dịch cũ có thể giúp giữ tên tính năng, nhưng không tự trở thành nguồn chuẩn nếu sản phẩm đã đổi chức năng. Một hình ảnh cũ có thể cho thấy bố cục nhưng chứa nhãn không còn dùng. Ghi đúng vai trò của tài liệu giúp người dịch sử dụng thông tin có chọn lọc thay vì sao chép những điểm đã hết hiệu lực.
Thẻ nội tuyến: giữ cấu trúc, nhưng vẫn phải đọc câu hoàn chỉnh
Những phần đánh dấu nằm trong câu có thể gắn với định dạng, liên kết hoặc thành phần do công cụ quản lý. Người dịch cần được hướng dẫn cách bảo toàn theo quy trình của dự án. Không nên xóa một phần vì nó làm câu khó đọc trong cửa sổ biên tập. Nếu chưa rõ tác dụng, ghi câu hỏi kèm mã đoạn và ảnh đầu ra để người phụ trách xác nhận trước khi sửa.
Tuy nhiên, bảo toàn không có nghĩa đọc từng mảnh chữ riêng lẻ. Tiếng Việt cần thứ tự và nhịp câu tự nhiên; nếu đánh dấu chia câu thành nhiều phần, người dịch vẫn phải hiểu quan hệ giữa các phần ấy. Khi vị trí nhấn mạnh hoặc liên kết cần thay để hợp ngôn ngữ, nên nêu phương án và kiểm trên đầu ra. Mục tiêu là giữ chức năng đồng thời bảo đảm người đọc hiểu đúng.
Ví dụ giả định, một câu hướng dẫn có tên nút được đặt đậm. Nếu người dịch sửa tên đó ở câu hướng dẫn nhưng giao diện vẫn dùng tên cũ, tài liệu sẽ gây khó tìm dù mọi thẻ đều còn đủ. Vì vậy, bảng kiểm phải có cả cấu trúc và quan hệ nội dung. Kiểm thẻ không thay được kiểm tên thao tác; kiểm chính tả cũng không chứng minh liên kết đang trỏ đúng mục.
Cung cấp ngữ cảnh theo nhóm màn hình và mục đích đọc
Người dịch thường cần biết nội dung dành cho khách mới, người đã sử dụng hay nhân viên quản trị. Một lời nhắc cho người có kinh nghiệm có thể ngắn; hướng dẫn lần đầu cần đủ bước để không bị hiểu nhầm. Trong brief, nêu đối tượng và hành động mong muốn. Chỉ viết “giọng chuyên nghiệp” chưa giúp lựa chọn mức cụ thể, bởi một thông báo lỗi và một bài giới thiệu không nên dùng cùng cách nói.
Ảnh màn hình nên có mã tham chiếu khớp với tệp hoặc danh sách câu hỏi. Nếu được cung cấp môi trường thử, cần biết những màn hình nào có thể truy cập và dữ liệu nào dùng để đi tới đó. Không cần chia sẻ thông tin khách thật để cung cấp ngữ cảnh. Một tài khoản thử với dữ liệu mô phỏng đủ dùng thường thuận tiện cho việc trao đổi và kiểm lại nhiều lần.
Bạn có thể nhóm câu theo hành trình đăng ký, quản lý tài khoản, mua hàng và hỗ trợ. Khi xem một nhóm đầy đủ, người dịch dễ phát hiện câu trước gọi “yêu cầu” nhưng câu sau lại gọi “đơn hàng”. Đơn vị dịch app cần bối cảnh sản phẩm tương tự khi xử lý chuỗi rời; khác định dạng tệp không làm mất đi nhu cầu hiểu người dùng đang làm việc gì.
Quản lý thuật ngữ từ những từ người dùng thực sự nhìn thấy
Không nên bắt đầu bằng một danh sách quá dài lấy từ nhiều tài liệu cũ mà không rõ nguồn duyệt. Hãy ưu tiên tên sản phẩm, tên tính năng, trạng thái và thao tác xuất hiện nhiều. Mỗi mục cần có cách dùng được chấp thuận và ví dụ ngắn. Nếu một từ có hai nghĩa, thêm ghi chú phân biệt thay vì ép tất cả xuất hiện thành một bản dịch chỉ để báo cáo nhất quán.
Người có quyền chốt thuật ngữ cần được xác định. Bộ phận marketing có thể chốt tên công bố, đội sản phẩm xác nhận chức năng, người dịch đề xuất cách nói phù hợp tiếng Việt. Khi có bất đồng, ghi lý do lựa chọn, đặc biệt với từ sẽ xuất hiện trong nhiều tài liệu. Sau một thời gian, danh sách quyết định ấy có giá trị hơn các cuộc trao đổi rời mà không ai nhớ ai đã duyệt.
Với dự án nhiều người dịch, nên duyệt một nhóm mẫu trước rồi mới triển khai rộng. Mẫu giúp thống nhất cách gọi, cách xưng hô và độ dài câu. Người rà soát vẫn cần đọc xuyên các phần, bởi bảng thuật ngữ không tự bảo đảm mọi câu đều tự nhiên. Một đoạn dùng đúng từng thuật ngữ nhưng nối quá sát cấu trúc nguồn vẫn có thể khiến người đọc phải đọc lại nhiều lần.
Tình huống: đổi nguồn giữa chừng nhưng vẫn muốn giữ ngày giao
Giả sử bộ ban đầu đã được dịch một nửa thì đội sản phẩm gửi tệp mới. Yêu cầu chỉ ghi “có sửa ít, dùng bản này”. Nếu tiếp tục mà không đối chiếu, người dịch có thể bỏ mất câu vừa thêm hoặc giữ câu đã đổi nghĩa. Việc cần làm là ghi nhận nguồn mới, so phạm vi thay đổi và xác định phần bản dịch trước còn dùng được trước khi cam kết lại tiến độ.
Người điều phối nên hỏi ngày giao đang gắn với mốc nào: cần bản để duyệt hay bản đã kiểm để phát hành. Nếu thời gian không đổi, có thể phải ưu tiên một nhóm màn hình hoặc bố trí thời điểm phản hồi chặt hơn. Không nên âm thầm bỏ bước rà soát rồi vẫn gọi đầu ra là hoàn chỉnh. Phương án cuối phải cho biết phần nào được làm và kiểm trong thời hạn ấy.
Các thay đổi cần được lưu thành một gói, không rải qua nhiều tin nhắn. Gói gồm tệp nguồn mới, danh mục phần thay đổi, lý do nếu ảnh hưởng nghiệp vụ và người xác nhận. Sau khi cập nhật bản dịch, kiểm lại cả những câu lân cận bị ảnh hưởng bởi tên gọi mới. Một tính năng đổi tên thường tác động đến hướng dẫn, email và thông báo, không chỉ một dòng trong tệp giao diện.
Duyệt ngôn ngữ khác với xác nhận chức năng
Người dịch có thể đánh giá câu rõ nghĩa, tự nhiên và khớp nguồn, nhưng không thể tự biết hệ thống có thực hiện đúng mọi điều câu nói hay không. Ví dụ, câu cho biết dữ liệu đã được lưu cần được người hiểu chức năng xác nhận khi nào nó xuất hiện. Nếu thông báo thực tế chỉ xuất hiện sau bước kiểm tra đầu vào, cách diễn đạt có thể cần thay. Đó là vấn đề cần trao đổi giữa nội dung và sản phẩm.
Trong danh sách phản hồi, nên tách lỗi ngôn ngữ, câu hỏi nghiệp vụ và lỗi hiển thị. Cùng một ảnh tràn chữ có thể liên quan nhiều bên, nhưng vẫn cần một người điều phối quyết định hướng xử lý. Người dịch đề xuất câu gọn mà không mất nghĩa; đội phát triển xem bố cục; chủ sản phẩm chốt điều kiện phải thể hiện. Phân loại giúp vấn đề đi đúng người thay vì chuyển lòng vòng.
Nếu khách hàng muốn hiệu đính bản dịch đã có, hãy nêu rõ đang cần kiểm mức nào: đối chiếu nguồn, làm tự nhiên câu chữ hay kiểm trên đầu ra. Ba việc có liên quan nhưng không đồng nhất. Một phạm vi minh bạch giúp đánh giá kết quả đúng tiêu chí và không bỏ sót bước mà mỗi bên tưởng đã được người khác thực hiện.
Nghiệm thu nên có kịch bản và bằng chứng cụ thể
Đừng chỉ mở một trang đầu rồi kết luận bản dịch đã hiển thị tốt. Chọn các hành trình chính, các màn hình có nhiều biến và các trạng thái lỗi. Ghi thiết bị hoặc kích thước hiển thị được kiểm nếu bố cục có thay đổi. Với nội dung có liên kết, thử đi đến trang đích và đọc tên gọi ở đó để xem câu hướng dẫn có còn khớp với trải nghiệm thực.
Một biên bản kiểm đơn giản có thể gồm kịch bản, bản đang kiểm, kết quả và lỗi còn mở. Kịch bản cần đủ cụ thể để người khác làm lại: nhập dữ liệu thiếu trường nào, bấm nút nào, mong thấy thông báo gì. Việc ghi rõ giúp giảm tranh luận rằng lỗi “không xuất hiện trên máy tôi”, đồng thời giúp xác nhận bản sửa sau đã giải quyết đúng vấn đề đã báo.
Khi thấy thiếu nội dung, đối chiếu từ tệp nguồn, tệp bàn giao đến đầu ra để xác định vị trí bị mất. Nếu câu không có trong nguồn đã giao, đây có thể là thiếu phạm vi xuất tệp. Nếu có trong bản dịch nhưng không lên giao diện, cần kiểm bước nhập. Không nên quy mọi lỗi hiển thị thành lỗi dịch hoặc mặc định tệp có chữ nghĩa là website đã nhận đúng nội dung.
Tổ chức phản hồi để người sửa không phải đọc lại toàn bộ cuộc trò chuyện
Phản hồi tốt nêu vị trí, câu hiện tại, vấn đề và đề nghị hoặc câu hỏi. Nếu người duyệt chỉ nói “đoạn này không ổn”, người dịch phải hỏi lại trước khi sửa. Nếu người duyệt đề nghị một cách nói nhưng chưa rõ chức năng, hãy ghi đó là đề xuất chờ xác nhận. Danh sách cần phân biệt quyết định cuối với các phương án đang được thảo luận.
Mỗi vòng duyệt nên có một người tổng hợp. Khi phòng kinh doanh và kỹ thuật đưa ra hai cách gọi, người tổng hợp cần tìm điểm khác nhau về nghĩa trước khi chuyển yêu cầu sửa. Người dịch có thể giải thích sắc thái ngôn ngữ, nhưng doanh nghiệp phải chốt thông tin thuộc sản phẩm của mình. Quy trình này tránh việc một câu bị đổi liên tục chỉ vì các bên chưa trao đổi với nhau.
Sau khi sửa, nên báo những mục đã xử lý và những mục cần kiểm lại trên hệ thống. Không nhất thiết gửi email dài, nhưng cần một dấu vết đủ để lần sau đọc được. Một danh sách mã vấn đề đã đóng giúp người duyệt kiểm đúng chỗ. Nếu một đề nghị không được áp dụng, giải thích ngắn lý do để người nhận không tưởng bị bỏ quên rồi gửi lại cùng phản hồi ở vòng sau.
Bộ bàn giao cuối: tệp dùng được và lịch sử đủ rõ
Bộ cuối nên có tệp đúng phiên bản được thống nhất, danh mục nội dung, quy ước thuật ngữ cập nhật và kết quả kiểm trong phạm vi đã giao. Nếu có phần chưa được kiểm trên sản phẩm, ghi rõ cho người phụ trách dự án trong hồ sơ bàn giao. Đây là thông tin quản lý công việc, không phải lý do để đính kèm một ghi chú dài làm người sử dụng cuối khó đọc.
Tên tệp nên giúp nhận ra dự án, ngôn ngữ và bản nguồn tương ứng. Lưu riêng bản đã duyệt, đừng để mọi người tiếp tục sửa trên bản ấy mà không tạo dấu vết. Khi có đợt tiếp theo, đối chiếu với bộ này để xác định phần thay đổi. Bản lưu không chỉ phục vụ tranh luận khi có lỗi; nó giúp triển khai cập nhật gọn hơn và không bỏ lỡ những quyết định đã mất công thống nhất.
Có thể tham khảo cách giữ thuật ngữ trong tài liệu phần mềm và kinh nghiệm chuyển ngữ website tự nhiên trước khi viết brief. Nếu đã có tệp mẫu, gửi qua báo giá nhanh cùng mục đích, ngôn ngữ và hạn cần nhận. Càng rõ đầu ra, hai bên càng dễ thống nhất phần dịch, phần rà soát và phần phối hợp kỹ thuật mà không hứa một phạm vi chưa được kiểm tra.
Câu hỏi thường gặp
Đuôi XLF và XLIFF có phải hai công việc khác nhau không?
Không nên chỉ nhìn đuôi để kết luận phạm vi. Cần xem định dạng, phiên bản, công cụ xuất và cách nhập lại. Gửi tệp mẫu cho người xử lý kiểm trước sẽ hữu ích hơn tự đổi tên. Phạm vi dịch vẫn phụ thuộc nội dung, ngữ cảnh và đầu ra cần nhận.
Có thể copy chữ sang Excel để duyệt không?
Có thể dùng bảng để duyệt nếu giữ được mã tham chiếu và cách đưa thay đổi về tệp chính. Bảng không thay thế việc kiểm tệp cuối. Hãy thống nhất ai nhập lại, cách tránh sửa nhầm đoạn và thời điểm đối chiếu sau nhập để không có hai bản cùng được coi là cuối.
Người dịch có phải sửa mã chương trình không?
Không mặc định. Dịch tài nguyên và kiểm ngôn ngữ khác với phát triển hoặc tích hợp. Nếu cấu trúc hiện tại làm câu không thể diễn đạt đúng, người dịch nên nêu vấn đề và đề xuất; đội phát triển quyết định giải pháp phù hợp rồi cùng kiểm lại kết quả.
Có cần giữ từng ngắt dòng giống nguồn không?
Cần xem ngắt dòng có vai trò kỹ thuật hay chỉ cách hiển thị trong công cụ. Không nên tự loại bỏ hoặc thêm hàng loạt. Người dịch và đội phát triển cần chốt quy ước dựa trên đầu ra thực. Mục tiêu là câu đọc được và chức năng không bị ảnh hưởng.
Chỉ sửa vài đoạn có cần kiểm lại mọi màn hình không?
Cần kiểm các vị trí bị ảnh hưởng và hành trình liên quan. Nếu thay một thuật ngữ dùng rộng, phạm vi kiểm có thể lớn hơn số đoạn sửa. Nếu thay riêng một câu trong tài liệu độc lập, có thể thu hẹp. Quyết định dựa vào tác động thực, không chỉ số từ thay đổi.
Có thể chia tệp cho nhiều người dịch để kịp hạn không?
Có thể nếu có bảng thuật ngữ, mẫu duyệt và người rà soát thống nhất. Cần phân phần có ngữ cảnh hợp lý và dành thời gian đọc xuyên các phần. Việc thêm người không loại bỏ nhu cầu tổng hợp phản hồi, kiểm cấu trúc và nghiệm thu trên đúng bản sản phẩm.
Nguồn có lỗi thì nên dịch theo hay sửa luôn?
Hãy ghi lỗi và đề nghị cách hiểu để người có trách nhiệm xác nhận. Lỗi chính tả rõ và lỗi làm thay nghĩa cần được xử lý theo quy ước khác nhau. Không tự sửa thông tin nghiệp vụ hoặc thêm cam kết chỉ vì câu đích sẽ nghe hợp lý hơn.
Điều gì cho thấy một đợt dịch đã thực sự hoàn thành?
Phải dựa vào tiêu chí đã chốt: tệp đã giao, phản hồi đã xử lý, đầu ra đã kiểm trong phạm vi và người phụ trách đã xác nhận. Số mục có bản dịch chỉ là một chỉ báo tiến độ. Những câu hỏi còn mở cần có người nhận trách nhiệm và mốc xử lý rõ.
