So sánh XLIFF, JSON, PO và ARB trong bản địa hóa

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

Trả lời nhanh

Chọn định dạng ứng dụng và quy trình dịch hỗ trợ tin cậy. JSON là dữ liệu với quy ước theo thư viện; PO thuộc gettext; ARB có tài nguyên và thuộc tính trên nền JSON; XLIFF phục vụ trao đổi bản địa hóa. Có thể dùng một định dạng runtime và một định dạng trao đổi. Thử xuất rồi nhập lại trước khi giả định khóa, biến, ngữ cảnh, trạng thái và số nhiều được giữ.

Điểm cần nhớ

Bắt đầu từ runtime và quy trình trích xuất.
Nêu phiên bản, không chỉ phần mở rộng.
Giữ mã, biến và metadata có ý nghĩa.
Xem nhu cầu kỹ thuật và người dịch cùng nhau.
Thử một tập đại diện trước khi làm lớn.
Lưu nguồn và hồ sơ thay đổi.

Runtime khác định dạng trao đổi ở đâu?

Tài nguyên runtime được ứng dụng hoặc build sử dụng. Tệp trao đổi chuyển thông tin giữa công đoạn và công cụ. Hai vai trò có thể giao nhau nhưng cần nêu riêng trong yêu cầu dự án.

Sản phẩm có thể lưu JSON trong kho mã, xuất để dịch và nhập về đúng cấu trúc. Sản phẩm khác cần bước trao đổi có ghi chú, mã nội tuyến bảo vệ hoặc trạng thái duyệt. Cuối cùng vẫn phải có tài nguyên dùng được trong ứng dụng.

Chuyển đổi không chỉ là thao tác hành chính. Xuất mỗi chữ hiển thị có thể mất ngữ cảnh; nhập bỏ trạng thái có thể đưa nội dung chưa duyệt vào build. Quy trình cần giữ thông tin mà nghiệm thu thực sự sử dụng.

Mỗi định dạng cung cấp gì?

Xác định vai trò trước khi so sự tiện lợi. Bảng là tóm tắt lập kế hoạch; tương thích thực tế phụ thuộc công cụ và phiên bản được chọn.

Định dạng	Cấu trúc chính	Ngữ cảnh	Hành vi thông điệp	Câu hỏi tương thích
XLIFF	XML trao đổi bản địa hóa	Ghi chú, cấu trúc, module hỗ trợ	Nội tuyến bảo vệ, thông tin quy trình	Phiên bản và module nào còn sau nhập, xuất?
JSON	Dữ liệu có cấu trúc	Yêu cầu riêng hoặc quy ước dự án	Do thư viện quyết định	Công cụ hiểu khóa và token của dự án không?
PO	Danh mục gettext	Comment, tham chiếu, ngữ cảnh thông điệp	Dạng số nhiều, quy ước định dạng	Trích xuất, merge, biên dịch có thống nhất không?
ARB	JSON tài nguyên và thuộc tính	Metadata, mô tả	Theo framework tiêu thụ	Generator nhận cú pháp và schema biến không?

XLIFF 2.1 của OASIS mô tả trao đổi dữ liệu giữa bước bản địa hóa.[1] RFC 8259 định nghĩa JSON, không phải quy trình dịch.[2] GNU mô tả cặp nguồn, đích cùng comment và flag trong PO.[3] Đặc tả ARB gắn mục tài nguyên với mục thuộc tính tùy chọn.[4]

Không có định dạng thắng mọi trường hợp. Danh mục đơn giản với ngữ cảnh ngoài tốt có thể hiệu quả. Định dạng giàu thông tin vẫn thất bại nếu importer bỏ trường cần dùng. Xác định thông tin thiết yếu rồi chứng minh được giữ.

Khi nào JSON phù hợp?

JSON hợp khi ứng dụng đã có schema tài nguyên rõ và nhóm kiểm tra được schema đó. Khóa, giá trị dễ xem trong kho mã. Sự đơn giản cũng khiến nhiều quy tắc bản địa hóa phải được định nghĩa ngoài định dạng.

Nêu cấu trúc phẳng hay lồng, dấu phân cách, giá trị dịch được và cách biến hoạt động. Công cụ nhận JSON chưa chắc hiểu hậu tố số nhiều hoặc cú pháp thông điệp của thư viện. Gửi tệp đại diện thay vì dựa vào dấu hỗ trợ định dạng.

Giữ đường dẫn ổn định, cung cấp ngữ cảnh ngoài vì JSON thông thường không có comment. Nếu thêm đối tượng metadata, xác nhận runtime và công cụ dịch xử lý đúng. Người dịch không nên phải đoán số nào là cấu hình, số nào thuộc nội dung.

Kiểm hành vi sau nhập lại. JSON parse được vẫn có thể thiếu khóa, đổi token hoặc trả sai kiểu. Thử lookup và dựng trong ứng dụng ngoài kiểm cú pháp.

Khi nào dùng PO?

PO phù hợp quy trình gettext có trích xuất, cập nhật dịch và biên dịch tài nguyên. Giữ danh tính thông điệp và ngữ cảnh khớp mã nguồn. Danh mục biên tập không chỉ là bảng các câu dịch.

GNU phân biệt msgid nguồn với msgstr dịch, mô tả comment trích xuất, tham chiếu mã và flag.[3] Chúng giúp biết nơi dùng và cách kiểm. Không bỏ chỉ để tệp nhỏ hơn.

Xem cách merge nguồn đã sửa vào danh mục. Thay câu nguồn có thể đổi danh tính hoặc cần duyệt lại. Có chính sách cho nội dung thiếu, chưa duyệt và không còn dùng; giá trị dịch khác rỗng chưa đủ để phát hành.

Kiểm cả chuỗi gettext: dấu trích xuất, ngữ cảnh, đối số định dạng, header ngôn ngữ và biên dịch. Xác nhận ứng dụng tải đúng. Xuất từ công cụ dịch thành công chưa chứng minh danh mục được build hay dùng.

Khi nào ARB phù hợp?

Dùng ARB khi nền tảng hoặc generator yêu cầu và thuộc tính cần thiết được giữ. Hướng dẫn Flutter mô tả thông điệp ARB, metadata biến và API bản địa hóa được sinh.[5] Theo cấu hình generator thật của dự án.

Mã thông điệp và metadata liên quan làm việc cùng nhau. Mô tả giải thích nút, trạng thái hoặc hướng dẫn. Định nghĩa biến cho biết đầu vào phương thức sẽ cần. Không dịch mã như chữ khách thấy.

Biểu thức plural, select cần kiểm ở lớp thông điệp, không chỉ JSON. Chuỗi JSON hợp lệ vẫn có thể bị generator từ chối. Xem kiểu biến, nhánh bắt buộc và escape theo cú pháp framework.

ARB không thay thế mọi danh mục JSON. Bộ chuyển chỉ giữ chuỗi có thể mất mô tả và định nghĩa biến. Ghi metadata nào cần để sinh mã, metadata nào cần để dịch, rồi kiểm cả hai sau chuyển.

Khi nào cần cấu trúc XLIFF?

XLIFF hữu ích khi trao đổi cần nguồn, đích rõ, ghi chú, nội tuyến bảo vệ hoặc thông tin quy trình. Thống nhất phiên bản và profile. Chỉ ghi “hỗ trợ XLIFF” chưa đủ chứng minh tệp cụ thể đi qua an toàn.

OASIS quy định phần lõi và module bổ sung của XLIFF 2.1.[1] Bài dùng đặc tả được nêu tên, không khẳng định là phiên bản mới nhất mọi công cụ hỗ trợ. Thử đúng bản xuất dự định dùng.

Liệt kê mã, ghi chú, trạng thái, nội tuyến và metadata bên nhận phải giữ. Với extension, kiểm công cụ có bỏ âm thầm không. Quy ước cần rõ để người duyệt sau tái hiện được.

Giữ tài nguyên nguồn và ánh xạ chuyển đổi. XLIFF không nhất thiết chứa mọi thứ để dựng lại tài nguyên ứng dụng. Ghép lại cần trả bản dịch đúng mã, giữ nội dung bảo vệ và theo trạng thái đã duyệt.

Nhu cầu kỹ thuật và người dịch khác nhau thế nào?

Kỹ thuật cần build và hành vi ổn định; người dịch cần ngữ cảnh; người duyệt cần dấu vết và bằng chứng. Quyết định thực tế phục vụ cả ba thay vì chỉ tối ưu hình thức tệp.

Nhu cầu dự án	Phương án xem trước	Điều phải chứng minh
Runtime JSON hiện có	Quy ước JSON đang dùng	Khóa, token hợp lệ sau dịch
Ứng dụng gettext	Trích xuất và merge PO	Danh tính, kiểm định dạng được giữ
Sinh thông điệp Flutter	Cấu hình ARB	Metadata, biểu thức qua generator
Trao đổi giàu thông tin	Profile XLIFF thống nhất	Ghi chú, mã, trạng thái còn nguyên
Nguồn đổi thường xuyên	Định dạng cùng quy trình cập nhật	Chuỗi mới, sửa được rà soát
Nhiều nhà cung cấp	Hợp đồng trao đổi rõ	Mỗi bên thử tập đại diện
Rà kho mã chặt	Serialization nhất quán	Diff không che mất dữ liệu
Rich text, thông điệp động	Cú pháp native của runtime	Nội dung bảo vệ, nhánh hoạt động

Cho các bên dùng cùng tập thử: nút ngắn, lỗi dài, biến, số nhiều, ghi chú và câu nguồn đã đổi. Xem kết quả nhập về, không chỉ màn hình biên tập của người dịch.

Kiểm tra tương tác công cụ như thế nào?

Thử xuất, chỉnh, nhập và build một tập nhỏ bằng đúng công cụ dự định. Giữ bản gốc để xem mọi khác biệt trước khi dịch toàn sản phẩm.

So mã ổn định, nguồn, đích, token, ghi chú, trạng thái và nhánh số nhiều. Tách biến đổi có chủ đích như thứ tự serialization khỏi mất ý nghĩa. Nếu mất khóa hoặc định nghĩa biến, sửa hợp đồng trước khi mở rộng.

Dùng ba lớp: hợp lệ tệp, giữ thông tin và hành vi sản phẩm. Parse XML hoặc JSON là lớp đầu; so trường trước sau là lớp hai; tải, dựng và thao tác ứng dụng là lớp ba.

Không gọi tương thích hoàn toàn chỉ vì một tệp mở được. Thử biên của sản phẩm với phiên bản công cụ chính xác. Ghi tính năng chưa hỗ trợ và quyết định đổi profile, đổi công cụ hoặc giữ ngữ cảnh bổ sung bên ngoài.

Quản lý phiên bản và bảo trì ra sao?

Giữ thay đổi dễ rà, tách cập nhật không liên quan. Thống nhất cách ghi và nhóm tệp để diff có ý nghĩa. Không đổi hàng loạt khóa trong lần dịch nếu chưa có di chuyển được kiểm tra.

Lưu phiên bản nguồn, ngôn ngữ và profile công cụ khi bàn giao. Nêu cách nhận biết câu đổi, trạng thái nào được đưa vào phát hành. Duyệt rõ fallback và bản dịch thiếu. Quy trình quan trọng hơn việc tệp nhìn gọn ban đầu.

Khi hỏi bản địa hóa phần mềm, gửi tệp mẫu, thông tin trích xuất hoặc sinh mã. Nêu công cụ, ngôn ngữ và lớp rà soát trong yêu cầu báo giá. Phạm vi có thể tính cả chuyển đổi và QA cần thiết.

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

Định dạng nào tốt nhất mọi dự án?

Không có lựa chọn chung. Theo runtime, thông tin cần giữ và quy trình hỗ trợ, rồi thử chuyển qua lại và hành vi ứng dụng.

JSON có thông điệp số nhiều được không?

Có, theo schema hoặc cú pháp thư viện. JSON lưu dữ liệu, không có một cơ chế chọn số nhiều chung.

ARB thay JSON bất kỳ được không?

Không. Nó dựa trên JSON nhưng gắn thuộc tính tài nguyên.[4] Framework có thể cần metadata mà importer chung bỏ mất.

Hỗ trợ XLIFF bảo đảm giữ metadata không?

Không. Kiểm phiên bản, module, extension và bên nhận. Đưa trường cần dùng vào thử xuất, nhập thật.

Mở được PO đủ duyệt chưa?

Chưa. Xem ngữ cảnh, bản dịch, kiểm định dạng và xác minh biên dịch, tải trong quy trình ứng dụng.

Nên gửi gì cho nhà cung cấp trước?

Gửi tài nguyên đại diện, ngữ cảnh, phiên bản nguồn, runtime và đầu ra. Thử tập nhỏ trước giao số lượng lớn.

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

Đối chiếu tài liệu OASIS, IETF, GNU, ARB và Flutter ngày 4 tháng 10 năm 2026. Tài liệu PO công khai được đọc từ bản lưu tại máy khi trình duyệt hết thời gian lấy nguồn. Các bảng là khung lập kế hoạch tự xây dựng; không có benchmark, thử chuyển đổi giữa nhà cung cấp hay build ứng dụng cho bài này.

Tài liệu tham khảo

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

[2] IETF / RFC Editor. RFC 8259: The JavaScript Object Notation Data Interchange Format.

[3] GNU gettext manual. What an entry looks like.

[4] Google app-resource-bundle project. Application Resource Bundle Specification.

[5] Flutter documentation. Internationalizing Flutter apps.