LOCALIZEZONE KNOWLEDGE

Hướng dẫn XLIFF cho lập trình viên và quản lý bản địa hóa

Rà soát nguồn: 4 tháng 10 năm 2026

Trả lời nhanh

Xem XLIFF là hợp đồng trao đổi có quy ước, không chỉ tệp XML đính kèm. Thống nhất phiên bản, mã, ghi chú, mã bảo vệ và trạng thái trước khi xuất. Dịch văn bản nhưng giữ dữ liệu để dựng lại tài nguyên. Kiểm cấu trúc, giữ thông tin và hành vi ứng dụng riêng. Tệp qua schema vẫn có thể dịch sai hoặc bị công cụ bỏ thông tin.

Điểm cần nhớ

  • Nêu phiên bản và profile cụ thể.
  • Giữ mã gắn với tài nguyên nguồn.
  • Ghi chú giải thích hành động, trạng thái, giới hạn.
  • Bảo vệ nội tuyến nhưng cho phép câu tự nhiên.
  • Nêu ai được đổi trạng thái duyệt.
  • Ghép và thử tài nguyên trước phát hành.
Các dòng mã trên màn hình máy tính

Hợp đồng trao đổi cần xác định gì?

Nêu thông tin phải giữ qua từng lần bàn giao và cách trả bản dịch về sản phẩm. Gồm công cụ trích xuất, phiên bản nguồn, ngôn ngữ, phiên bản XLIFF và quy trình nhập. Phần mở rộng chưa chứng minh tương thích.

OASIS định nghĩa XLIFF 2.1 để chuyển dữ liệu qua công đoạn bản địa hóa.[1] Bài dùng bản này cho mẫu chính, không khẳng định mọi công cụ nhận hay giữ đủ tính năng tùy chọn.

Thử tập đại diện trước xuất lớn: nút, lỗi, biến, ghi chú, nguồn đã đổi và định dạng có ý nghĩa. Nhờ bên nhận chỉnh rồi trả lại; so thông tin quy trình dựa vào.

Thành phầnQuyết định cần lưuBằng chứng sau nhập
Phiên bản, profileTài liệu, tính năng được nhậnXuất đúng profile
NguồnTrích từ bản tài nguyên nàoNhập gắn đúng bản đó
Ánh xạUnit trở về tài nguyên nàoĐúng khóa nhận bản dịch
Ngữ cảnhGhi chú, tham chiếu cần thiếtNgười duyệt thấy đủ
Nội dung bảo vệMã nào phải giữDựng lại được dữ liệu gốc
Trạng tháiKhi nào được phát hànhChính sách duyệt còn hiệu lực
MetadataTrường, module cần dùngTrường cần còn tồn tại
Ghép lạiAi build và thửHành vi sản phẩm được kiểm

Giữ quy ước cùng hồ sơ bàn giao. Khi đổi exporter hoặc công cụ có thể ảnh hưởng trường cần dùng, kiểm tương thích lại. Không dựa vào kết quả của phiên bản cũ.

Unit, segment và ID liên quan thế nào?

Tách danh tính thông điệp với đoạn dùng để dịch. Trong mẫu 2.1, unit có segment chứa nguồn và đích.[1] Giữ ánh xạ tài nguyên ngoài cách editor trình bày.

quote.received có thể dùng ánh xạ trích xuất ổn định. Thuộc tính name trong mẫu ghi tên tài nguyên cho người đọc; ID định danh file, unit, segment. Đây là quy ước mẫu, không phải cách mọi exporter bắt buộc dùng.

Không lấy câu dịch làm khóa dựng lại duy nhất. Câu đổi hoặc trùng có thể gây mơ hồ. Giữ ánh xạ hay cấu trúc nguồn mà importer cần, xác định cách xử lý thay đổi phân đoạn.

Phân đoạn không chỉ là hình thức. Khi công cụ tách câu, người duyệt vẫn cần hiểu hướng dẫn hoàn chỉnh. Không tự gộp, tách unit chỉ để editor dễ nhìn nếu chưa có quy tắc ghép lại.

Mẫu biến được bảo vệ trông như thế nào?

Có thể dùng mã nội tuyến để bảo vệ dữ liệu nguồn khỏi dịch. Mẫu tự xây dựng dưới lưu token ứng dụng riêng và tham chiếu bằng placeholder. Đích đổi câu nhưng giữ tham chiếu.

<xliff xmlns="urn:oasis:names:tc:xliff:document:2.0"
       version="2.1" srcLang="en" trgLang="vi">
  <file id="f1" original="messages.json">
    <unit id="u1" name="quote.received">
      <notes>
        <note category="description">Shown after a request is accepted. Preserve the request identifier.</note>
      </notes>
      <originalData>
        <data id="d1">{{requestId}}</data>
      </originalData>
      <segment id="s1" state="translated">
        <source>We received request <ph id="p1" dataRef="d1"/>.</source>
        <target>Đã nhận yêu cầu <ph id="p1" dataRef="d1"/>.</target>
      </segment>
    </unit>
  </file>
</xliff>

Namespace lõi 2.x vẫn dùng định danh 2.0 dù phiên bản khai báo là 2.1. Không tự đổi namespace theo tên tệp; xem đặc tả và bộ kiểm của profile.[1]

Cách bảo vệ token là quyết định trích xuất minh họa. Quy trình khác có thể giữ biến trong chữ hoặc dùng mã khác. Chọn cách exporter, importer hỗ trợ và kiểm ghép lại trả đúng token ứng dụng cần.

Ghi chú và metadata giúp người dịch ra sao?

Viết ngữ cảnh ngắn có ảnh hưởng lựa chọn dịch: màn hình, hành động, biến và ràng buộc. “Dịch chính xác” không giải quyết từ mơ hồ.

Với nút, nêu điều xảy ra khi bấm. Với lỗi, nêu nguyên nhân và cách khách xử lý. Với trạng thái, nêu sự kiện hệ thống đã xác nhận. Nhận yêu cầu trong mẫu không đồng nghĩa nhận hợp đồng hay hoàn thành dự án.

Tách ngữ cảnh cần thiết khỏi trao đổi nội bộ. Không đưa dữ liệu cá nhân hoặc bí mật không liên quan vào ghi chú. Nếu có màn hình và tham chiếu ngoài, dùng mã nhất quán với danh sách thông điệp.

OASIS quy định notes và module, gồm metadata.[1] Chọn tính năng hỗ trợ thực sự dùng. Không thêm trường tùy ý không có namespace rồi nghĩ công cụ hiểu. Kiểm thông tin cần thiết sau xuất và nhập.

Bảo vệ mã nội tuyến như thế nào?

Giữ danh tính mã và quan hệ dữ liệu gốc khi dịch chữ quanh nó. OASIS có placeholder, mã cặp và ràng buộc.[1] Rà vị trí ngôn ngữ cùng khả năng dựng lại kỹ thuật.

Cho phép đổi vị trí tự nhiên khi hợp đồng nguồn cho phép. Tiếng Việt có thể đặt biến khác vị trí; nhưng định dạng cặp hoặc thành phần liên kết có giới hạn. Giải thích thay vì ép mọi ký tự giữ vị trí bất kể nghĩa.

Tìm mã thiếu, lặp hoặc không khớp. Nguồn và đích phải tham chiếu đúng dữ liệu cần, không chỉ một ID bất kỳ có tồn tại. Công cụ giúp cấu trúc; ý nghĩa vẫn cần người duyệt.

Thử tài nguyên ghép lại với giá trị đại diện. Mã yêu cầu dài hoặc dữ liệu có dấu câu có thể lộ lỗi bố cục mà editor placeholder không cho thấy. Tách thử sản phẩm với thử tệp trao đổi.

Trạng thái segment liên quan nghiệm thu ra sao?

Ánh xạ trạng thái với trách nhiệm và chính sách phát hành. XLIFF 2.1 có initial, translated, reviewed, final.[1] Nhãn cần ghi công việc thật, không làm nội dung chưa xong trông đã duyệt.

Trạng tháiCâu hỏi dự ánBằng chứng quy trình
initialViệc nào còn chờ?Nguồn, ngữ cảnh sẵn sàng giao
translatedAi hoàn thành đích?Dịch theo bản nguồn xác định
reviewedĐã rà soát loại nào?Người duyệt, phát hiện được lưu
finalĐiều gì cho phép sử dụng?Tiêu chí phát hành đã đạt

Hai cột phải là đề xuất quản trị của bài, không thêm nghĩa bắt buộc vào tiêu chuẩn. Reviewed có thể chỉ là rà ngôn ngữ, chưa kiểm giao diện. Ghi rõ để không nhầm đoạn đã dịch với ứng dụng đã thử.

Giữ quy trình khi nhập. Nếu công cụ đặt lại trạng thái hoặc importer bỏ qua, cần thực thi duyệt ở chỗ khác. Đổi hàng loạt thành final trong editor không thay bằng chứng kiểm tra.

Khác biệt 1.2 và 2.x ảnh hưởng gì?

Xem đổi phiên bản là chuyển đổi cần ánh xạ đã thử. 1.2 có trans-unit; mẫu 2.1 dùng unit và segment.[2][1] Đổi tên một phần tử không đủ.

Kiểm kê ghi chú, mã, phân đoạn, trạng thái nguồn. Xác định bên nhận biểu diễn mỗi mục cần giữ thế nào và thông tin nào cần trường khác hoặc hồ sơ ngoài. Nút export chưa chứng minh ý nghĩa được giữ qua phiên bản.

Dùng nguồn thật trong thử nhỏ, so tài nguyên ứng dụng sau ghép. Hệ thống cũ yêu cầu 1.2 cần được ghi rõ; không gửi tài liệu 2.x chỉ vì phần mở rộng quen.

Không gọi phiên bản nào tốt hơn mọi trường hợp. Chọn profile dùng được với sản phẩm và các bên. Nếu di chuyển, đưa chi phí và yêu cầu giữ dữ liệu vào phạm vi.

Hai đồng nghiệp cùng rà soát mã trên màn hình

Cần kiểm gì trước phát hành?

Tách cấu trúc XML, yêu cầu XLIFF, giữ thông tin và hành vi ghép lại. W3C phân biệt XML well-formed với valid.[3] Cả hai chưa chứng minh câu dịch đúng nhiệm vụ khách.

Kiểm traThử thực tếBằng chứng đạt
XMLParse tệp xuấtKhông lỗi cấu trúc
ProfileDùng bộ kiểm thích hợpĐạt quy tắc hoặc xử lý ngoại lệ
Danh tínhSo file, unit, tài nguyênĐúng khóa nhận bản dịch
Ngôn ngữXem khai báo và chữKhớp dự án
MãSo tham chiếu bảo vệKhông mất, lặp trái phép
Ngữ cảnhXuất, nhập notes cầnNgười duyệt vẫn đủ thông tin
Quy trìnhXem trạng thái qua bàn giaoChính sách phát hành thực thi được
Sản phẩmBuild và thao tác thông điệpNghĩa, dữ liệu, giao diện đúng

Lưu tập thử, kết quả và phiên bản công cụ. Thêm tình huống khi sản phẩm có kiểu thông điệp mới; không dùng mãi bộ chỉ có nút đơn giản cho mọi tính năng.

Quản lý bàn giao như thế nào?

Mỗi lần giao có bản nguồn, người phụ trách và ranh giới nghiệm thu. Tách dịch, rà ngôn ngữ, kiểm chuyển đổi, thử ứng dụng khi người làm khác nhau. Hồ sơ nêu công việc thực sự đã xong.

Gửi mẫu XLIFF, định dạng gốc và importer trong yêu cầu bản địa hóa phần mềm. Nêu màn hình và tính năng chưa hỗ trợ qua trang báo giá. Xác định có QA tệp hay thử sản phẩm chạy được không.

Thống nhất cách xử lý câu hỏi. Người dịch hỏi hành động hay trạng thái cần câu trả lời lưu dùng lại. Kỹ thuật tìm mã thiếu cần unit và ánh xạ. Gắn cả hai vào cùng danh tính tài nguyên.

Câu hỏi thường gặp

XLIFF thay tài nguyên ứng dụng luôn không?

Không tự động. Có thể chỉ là bước trao đổi; importer phải dựng cấu trúc ứng dụng dùng.

Có đổi ID lúc dịch được không?

Không đổi mã bảo vệ nếu chưa thống nhất di chuyển. Chúng có thể cần để đưa bản dịch đúng thông điệp.

Mọi đoạn đã dịch đều final không?

Không. Theo chính sách duyệt và bằng chứng. Nhãn final không thay kiểm còn thiếu.

Parse XML kiểm mọi yêu cầu XLIFF chưa?

Chưa. Dùng schema và quy tắc thích hợp, rồi rà dữ liệu, hành vi riêng.

Đổi tên trans-unit đủ chuyển 1.2 không?

Không. So cấu trúc, mã, ngữ cảnh và quy trình; thử chuyển và dựng lại với tệp đại diện.

Cần gì để báo giá?

Gửi mẫu, phiên bản, profile, nguồn, màn hình và quy trình nhập. Nêu lớp rà soát, tiêu chí phát hành cần.

Nguồn và phương pháp

Đối chiếu OASIS 2.1, 1.2 và W3C ngày 4 tháng 10 năm 2026. Mẫu biến, bảng hợp đồng và quy trình là ví dụ biên tập. Kiểm mẫu nhỏ tại máy hẹp hơn đáp ứng toàn bộ tiêu chuẩn hoặc tương tác nhà cung cấp; không có thử chuyển giữa công cụ, build sản phẩm hay rà ngôn ngữ sản xuất cho bài này.

Tài liệu tham khảo

[1] OASIS. XLIFF Version 2.1, OASIS Standard, 13 February 2018.

[2] OASIS. XLIFF Version 1.2, OASIS Standard, 1 February 2008.

[3] W3C. Extensible Markup Language 1.0, Fifth Edition.

Bài viết liên quan