Độ giãn văn bản tiếng Việt khi bản địa hóa phần mềm

Ngày rà soát: 4 tháng 10 năm 2026

Trả lời nhanh

Không có một tỷ lệ giãn cố định đáng tin cậy cho mọi bản dịch tiếng Việt. Nhãn có thể ngắn hơn, dài hơn hoặc bằng nguồn; số ký tự không quyết định chính xác chiều rộng hiển thị. Đo chuỗi đã duyệt theo vai trò rồi thử phông, khung, thiết bị và trạng thái thực tế. Mẫu nhỏ dưới đây minh họa phương pháp, không phải chuẩn đo cho toàn ngôn ngữ hoặc ứng dụng.

Điểm cần nhớ

• Đo bản dịch của sản phẩm thay vì mượn tỷ lệ chung.
• Phân biệt số cụm ký tự, dung lượng và kích thước hiển thị.
• Tách nhóm nút, nhãn, thông báo và nội dung dài.
• Thử giá trị biến đã chèn, không chỉ chuỗi mẫu.
• Cho nội dung xuống dòng hợp lý trước khi bỏ thông tin.
• Ghi môi trường và đo lại khi câu hoặc phông đổi.

Vì sao một tỷ lệ cố định không đáng tin cậy?

Một hệ số che mất khác biệt giữa loại chuỗi và nghĩa. “Save” có thể thành “Lưu”, còn “Next” thành “Tiếp theo”. Hai cặp không dự báo cách một đoạn lỗi hiển thị. Các phương án dịch hợp lệ trong ngữ cảnh riêng cũng có độ dài khác. Duyệt nghĩa trước để không coi bản dịch sai nhưng ngắn là giải pháp tốt.

W3C phân tích kích thước văn bản dịch và khuyến nghị bố cục linh hoạt, chú ý chuỗi ngắn trong vùng hẹp [1]. Các ví dụ đó không phải chuẩn đo sản phẩm tiếng Việt. Không lấy bảng lịch sử cho nhóm ngôn ngữ khác rồi ghi thành mức giãn đã kiểm chứng cho tiếng Việt.

Nguồn cũng ảnh hưởng: chữ viết tắt có thể cần cụm giải thích, còn nhãn đầy đủ có thể dịch gọn. Với đoạn văn, số dòng tăng làm thẻ cao hơn và đẩy nút bên cạnh dù mỗi dòng vẫn vừa chiều ngang.

Nhóm sản phẩm cần đo những gì?

Chọn chỉ số đúng câu hỏi. Unicode có hướng dẫn phân đoạn cụm ký tự gần với đơn vị người dùng cảm nhận [2]. Chỉ số này hữu ích khi so chuỗi, nhưng không đo chiều rộng phông hoặc byte cơ sở dữ liệu.

• Cụm ký tự: so độ dài, nêu rõ có tính khoảng trắng không.
• Chiều rộng và cao hiển thị: đo sau tải phông và bố trí thành phần.
• Số dòng, tràn và cắt chữ: kiểm tra nội dung có bị che hoặc đè nút.
• Dung lượng lưu: đo byte hoặc đơn vị trường dữ liệu riêng.
• Hậu quả: xem phần bị cắt có mất điều kiện hoặc phân biệt hành động.

Mỗi cặp ghi số nguồn và đích. Tỷ số là đích chia nguồn; chênh lệch là đích trừ nguồn. Lớn hơn một chỉ nói chỉ số này tăng, không chứng minh cần tăng pixel tương ứng. Xử lý nguồn rỗng riêng để tránh chia cho không.

Mẫu minh họa cho thấy điều gì?

Mười hai cặp tự soạn được đo ngày 4 tháng 10 năm 2026 bằng Node.js v24.18.0, ICU 78.3, dữ liệu Unicode 17.0. Chỉ số là cụm ký tự grapheme sau chuẩn hóa NFC, tính khoảng trắng và dấu câu. Tỷ số làm tròn hai chữ số. Không đo chiều rộng trình duyệt hoặc tỷ lệ lỗi sản phẩm.

Mẫu có trường hợp tăng, giảm và bằng nhau, được chọn để minh họa chứ không đại diện thống kê. Không lấy trung bình làm ngân sách toàn ngôn ngữ. “Next” cho thấy mẫu số nhỏ làm tỷ số lớn dù chênh lệch chỉ năm cụm ký tự.

Chạy lại phép đo thế nào?

Dùng cùng cặp, chuẩn hóa, quy tắc phân đoạn và ghi phiên bản chạy. Ví dụ sử dụng Intl.Segmenter trong ECMA-402 [3], đã chạy ở môi trường nêu trên và tạo số trong bảng. Áp dụng cho chuỗi xuất từ sản phẩm sau khi duyệt bản dịch.

const segmenter = new Intl.Segmenter('vi', {
  granularity: 'grapheme'
});
const count = text =>
  [...segmenter.segment(text.normalize('NFC'))].length;

function compare(source, target) {
  const sourceCount = count(source);
  const targetCount = count(target);
  return {
    sourceCount,
    targetCount,
    change: targetCount - sourceCount,
    ratio: sourceCount === 0 ? null :
      Number((targetCount / sourceCount).toFixed(2))
  };
}

console.log(compare('Next', 'Tiếp theo'));
// sourceCount: 4; targetCount: 9; change: 5; ratio: 2.25

Không thay bằng độ dài chuỗi JavaScript thông thường rồi gọi là số grapheme. Giữ định nghĩa đếm giống nhau giữa các lần xuất. Chính sách chuẩn hóa cũng cần phù hợp lưu dữ liệu; phép đo minh họa không cho phép sửa phá hủy dữ liệu khách.

Gắn mã thành phần vào mỗi hàng, chia nút, điều hướng, nhãn, tooltip, lỗi và nội dung dài. Xem chênh lệch tuyệt đối cùng tỷ số rồi tìm vùng thật sự bị giới hạn. Tỷ số lớn trong đoạn rộng có thể ít khẩn cấp hơn tăng nhỏ ở tiêu đề bảng hẹp.

Tính giá trị biến vào phép đo ra sao?

Đo thông báo đã chèn giá trị, không chỉ dấu ngoặc trong mẫu. Tên tệp, tổ chức, số lượng và ngày có thể đổi số dòng, chiều cao. Chuẩn bị giá trị rỗng, bình thường, dài nhất được hỗ trợ và sát giới hạn. Dùng dữ liệu thử không nhạy cảm.

Giữ mã biến khi dịch. Nếu hệ thống cho phép, dịch cả câu thay vì nối mảnh rời. Kiểm tra biến có thể chuyển vị trí tự nhiên trong tiếng Việt. Báo cáo chỉ đo chuỗi mẫu phải ghi rõ chưa tính giá trị thực.

Nên thử sửa bố cục nào trước?

Bắt đầu bằng thành phần linh hoạt và nội dung dịch thật. Xem chiều rộng tối thiểu, tối đa, xuống dòng, khoảng cách, căn chỉnh và nút lân cận. Cho nút hoặc thẻ lớn hơn khi thiết kế hỗ trợ. Kiểm tra hàng cao thêm có che thao tác khác không, thay vì chỉ xem chữ còn trong viền.

Không tự động giảm cỡ chữ khi tràn. Nguyên nhân có thể là khung cứng hoặc nguồn dài không cần thiết. Rút bản dịch sau rà soát vẫn phải giữ hành động và điều kiện. Câu ngắn không tốt hơn nếu làm hủy giống xóa hoặc bỏ mã tiền tệ.

Đây là ma trận đề xuất, không khẳng định sản phẩm cụ thể đã đạt. Thống nhất môi trường và điều kiện đạt với thiết kế, kỹ thuật trước khi thử.

Chuyển phát hiện thành quyết định phát hành thế nào?

Ghi mã chuỗi, bản dịch, thành phần, môi trường, ảnh chụp và lỗi. Phân biệt vấn đề ngôn ngữ với phông, khung hoặc biến. Giao người phụ trách, ghi màn hình bị ảnh hưởng và thử lại sau sửa, gồm thông báo hoặc nội dung xuất liên quan.

Báo cáo nên phân loại thành phần và mức hậu quả, không chỉ một số trung bình. Nêu chuỗi nào đã đo, đã thử trên giao diện hoặc chưa thử. Nếu tổng hợp tập lớn, ghi tập dữ liệu, cách nhóm và phép tính để người khác chạy lại. Cập nhật khi câu dịch, phông hoặc kích thước hỗ trợ đổi.

Đề xuất của LocalizeZone

Khi hỏi dịch vụ bản địa hóa phần mềm, gửi tệp chuỗi, giới hạn thành phần và màn hình chính. Duyệt thuật ngữ trước khi đo, rồi rà soát vùng hẹp với kỹ thuật. Tách phạm vi dịch, rà soát bố cục bằng ngôn ngữ và sửa triển khai để có danh sách rủi ro cụ thể.

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

Tiếng Việt luôn dài hơn tiếng Anh?

Không. Mẫu có chuỗi ngắn hơn và bằng nguồn. Kết quả tùy cách viết và ngữ cảnh.

Tỷ số grapheme dự báo được chiều rộng nút?

Không. Cần thử phông, cỡ chữ và thành phần thực tế.

Dùng 12 hàng mẫu làm ngân sách thiết kế được không?

Không. Chúng minh họa phương pháp, không đại diện ứng dụng hoặc toàn tiếng Việt.

Độ dài chuỗi JavaScript có đủ không?

Chỉ đủ cho đúng chỉ số nó biểu diễn, không phải số grapheme trong bài.

Người dịch phải rút mọi chuỗi tràn?

Xem nghĩa và bố cục cùng nhau. Có trường hợp cần sửa thành phần thay vì câu.

Khi nào đo lại?

Khi câu đã duyệt, biến, phông, giới hạn thành phần hoặc môi trường hỗ trợ thay đổi.

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

Nguồn chính thức được kiểm tra ngày 4 tháng 10 năm 2026. Mười hai cặp tự soạn được đo tại máy với phiên bản và quy tắc đã nêu. Khuyến nghị bố cục, ma trận là quy trình đề xuất. Bài không công bố phép đo pixel, chuẩn thống kê tiếng Việt, nghiên cứu khách hàng hoặc hiệu quả kinh doanh đã đo.

Tài liệu tham khảo

[1] W3C Internationalization. Text size in translation.

[2] Unicode Consortium. Unicode Standard Annex #29: Unicode Text Segmentation.

[3] Ecma International / TC39. ECMA-402: Segmenter Objects.

Bài viết liên quan

• Hướng dẫn UX Writing tiếng Việt cho nút bấm, biểu mẫu và thông báo lỗi
• Kiểu chữ, Unicode và dấu câu tiếng Việt trong sản phẩm số
• Checklist 50 mục kiểm tra trước khi ra mắt website tại Việt Nam
• Cẩm nang bản địa hóa tiếng Việt cho phần mềm và SaaS
• Hướng dẫn định dạng ngày giờ, số và tiền tệ trong tiếng Việt
• Định dạng địa chỉ Việt Nam cho biểu mẫu, thương mại điện tử và cơ sở dữ liệu