Chuyển đến nội dung
Employees engage in a lively discussion in a contemporary office setting.

Cách xử lý biến, placeholder, HTML và code khi dịch phần mềm

Dịch phần mềm không chỉ là chuyển ngữ câu chữ. Biến, placeholder, thẻ HTML và code cần được nhận diện, giữ nguyên hoặc xử lý theo quy tắc để giao diện hoạt động ổn định.

Cách xử lý biến, placeholder, HTML và code khi dịch phần mềm là một phần quan trọng của quy trình bản địa hóa. Chỉ một ký tự bị xóa, đổi vị trí sai hoặc dịch nhầm trong chuỗi kỹ thuật cũng có thể khiến giao diện hiển thị lỗi, thông báo thiếu dữ liệu hoặc chức năng không hoạt động như dự kiến.

Người dịch cần phân biệt rõ đâu là nội dung hiển thị cho người dùng và đâu là thành phần kỹ thuật cần được bảo toàn. Mục tiêu không phải là giữ nguyên mọi thứ một cách máy móc, mà là tạo câu dịch tự nhiên trong khi vẫn duy trì cấu trúc, cú pháp và dữ liệu động của phần mềm.

Nhận diện thành phần không nên dịch trong chuỗi phần mềm

Một chuỗi phần mềm thường gồm phần văn bản có thể dịch và các thành phần kỹ thuật cần giữ nguyên. Trước khi dịch, hãy đọc toàn bộ chuỗi để xác định ranh giới giữa hai phần này. Không nên chỉ dịch theo từng từ vì nhiều biến hoặc ký hiệu có thể nằm xen trong câu.

Các thành phần thường gặp

  • Biến động: tên người dùng, ngày tháng, số lượng, mã đơn hàng hoặc dữ liệu được hệ thống chèn khi chạy.
  • Placeholder: ký hiệu thay thế vị trí dữ liệu, chẳng hạn %s, %d, {name}, {{count}} hoặc ${value}.
  • Thẻ HTML: ví dụ <strong>, <em>, <br>, <a> và thuộc tính đi kèm.
  • Code và cú pháp: biểu thức, khóa cấu hình, tên hàm, đường dẫn, lệnh, định dạng ngày giờ hay chuỗi định danh.
  • Ký tự điều khiển: xuống dòng \n, tab \t, dấu gạch chéo ngược, dấu nháy kép hoặc chuỗi escape.

Nếu chưa chắc một đoạn có phải mã kỹ thuật hay không, nên giữ nguyên và hỏi người phụ trách dự án. Việc đoán nghĩa rồi sửa cấu trúc thường rủi ro hơn việc tạm thời không can thiệp.

Nhân viên trao đổi sôi nổi trong không gian văn phòng hiện đại.

Xử lý biến và placeholder khi dịch phần mềm

Biến và placeholder phải được giữ đúng ký tự, đúng tên và đúng số lần xuất hiện, trừ khi tài liệu dự án nêu quy tắc khác. Chúng cung cấp dữ liệu khi phần mềm vận hành; vì vậy, dịch hoặc làm mất biến có thể tạo ra thông báo thiếu thông tin.

Ví dụ, với chuỗi Hello, {name}!, phần có thể dịch là lời chào, còn {name} phải được giữ nguyên. Một phương án phù hợp là Xin chào, {name}!. Tương tự, câu You have %d new messages có thể được dịch thành Bạn có %d tin nhắn mới.

Cho phép đổi vị trí, không được làm đổi cú pháp

Trật tự từ trong tiếng Việt có thể khác ngôn ngữ nguồn. Khi cần viết câu tự nhiên hơn, placeholder có thể chuyển vị trí nếu hệ thống và định dạng hỗ trợ. Chẳng hạn, {count} files deleted có thể thành Đã xóa {count} tệp. Dù ở vị trí nào, biến vẫn phải xuất hiện đầy đủ.

Cần đặc biệt cẩn thận với placeholder có đánh số hoặc có kiểu dữ liệu. Các dạng như {0}, {1}, %1$s hoặc %2$d có thể được dùng để kiểm soát thứ tự chèn dữ liệu. Không tự bỏ số thứ tự, đổi chữ cái chỉ kiểu dữ liệu, hoặc thay dấu ngoặc.

Kiểm tra trước khi bàn giao

  1. Đếm số biến ở câu nguồn và câu đích.
  2. So sánh chính xác tên biến, dấu ngoặc, ký hiệu phần trăm và chỉ số.
  3. Kiểm tra biến có bị dính vào từ tiếng Việt gây khó đọc hay không.
  4. Đọc lại câu với dữ liệu giả định để đánh giá ngữ pháp, số ít/số nhiều và ngữ cảnh hiển thị.

Giữ nguyên cấu trúc HTML nhưng dịch nội dung hiển thị

Khi chuỗi chứa HTML, thẻ và thuộc tính kỹ thuật thường phải được giữ nguyên. Nội dung văn bản nằm giữa thẻ mới là phần chính cần dịch. Ví dụ, với <strong>Warning:</strong> Delete this file?, có thể dịch thành <strong>Cảnh báo:</strong> Bạn có muốn xóa tệp này không?.

Điểm cần bảo toàn gồm thẻ mở, thẻ đóng, thứ tự lồng nhau, dấu nháy trong thuộc tính và các giá trị phục vụ chức năng. Nếu nguồn có <a href=”…”>, không nên sửa giá trị href khi không có yêu cầu cụ thể. Tương tự, các thuộc tính như id, class, data-*, aria-* hoặc giá trị định danh có thể liên quan đến giao diện và lập trình.

Những lỗi HTML dễ gây hỏng hiển thị

  • Xóa thẻ đóng hoặc đóng sai thứ tự, chẳng hạn mở <strong> nhưng không đóng.
  • Dịch tên thẻ hay tên thuộc tính kỹ thuật.
  • Làm thay đổi dấu nháy, dấu ngoặc nhọn hoặc ký tự escape trong thuộc tính.
  • Đưa thẻ HTML vào vị trí khiến câu khó đọc hoặc tạo khoảng trắng không cần thiết.
  • Thêm thẻ mới chỉ để làm đẹp câu dịch khi chưa biết hệ thống có cho phép hay không.

Với thẻ dùng để nhấn mạnh, có thể điều chỉnh vị trí phần được bọc thẻ để phù hợp ngữ pháp tiếng Việt, miễn là cấu trúc HTML vẫn hợp lệ và ý nhấn mạnh không thay đổi. Tuy nhiên, cần tránh tách một biến hoặc một thực thể kỹ thuật thành nhiều phần bằng thẻ định dạng.

Phân biệt code, chuỗi kỹ thuật và văn bản cần bản địa hóa

Không phải mọi nội dung trông giống tiếng Anh đều cần dịch. Tên hàm, khóa JSON, mã lỗi, tên tệp, phần mở rộng tệp, lệnh dòng lệnh, địa chỉ nội bộ và giá trị cấu hình thường phải giữ nguyên để bảo đảm tính tương thích.

Loại nội dung Cách xử lý phổ biến
Nội dung giao diện hiển thị Dịch theo ngữ cảnh, giọng điệu và giới hạn không gian.
Tên biến, hàm, khóa cấu hình Giữ nguyên chính tả và kiểu chữ.
Mã lỗi hoặc mã định danh Giữ nguyên; chỉ dịch phần mô tả đi kèm nếu có.
Đoạn lệnh hoặc cú pháp Không dịch, không tự sửa định dạng.
Chú thích dành cho người dùng Dịch nếu được xuất bản hoặc hiển thị trong sản phẩm.

Chẳng hạn, trong câu Run npm install before starting the app, phần lệnh npm install cần giữ nguyên. Câu dịch có thể là Hãy chạy npm install trước khi khởi động ứng dụng. Nếu câu có tên nút, menu hoặc trường nhập liệu, nên áp dụng nhất quán thuật ngữ đã có trong sản phẩm thay vì dịch tách rời.

Cũng cần lưu ý các chuỗi có định dạng đặc biệt như URL, địa chỉ email, đường dẫn tệp, biểu thức chính quy, mã Markdown hoặc chuỗi JSON. Việc thêm dấu cách, thay dấu gạch chéo, chuẩn hóa dấu nháy hoặc Việt hóa tên khóa có thể làm hỏng cú pháp.

Quy trình dịch an toàn cho chuỗi có yếu tố kỹ thuật

Một quy trình rõ ràng giúp giảm lỗi lặp lại, đặc biệt khi dự án có nhiều chuỗi ngắn và thiếu ngữ cảnh. Thay vì dịch trực tiếp ngay từ đầu, hãy dành bước đầu để phân tích thành phần cần khóa.

  1. Đọc ngữ cảnh: xác định đây là nút bấm, thông báo lỗi, mô tả cài đặt, email hệ thống hay hướng dẫn thao tác.
  2. Đánh dấu phần bất khả dịch: nhận diện biến, thẻ, code, giá trị cấu hình và ký tự điều khiển.
  3. Dịch phần văn bản: ưu tiên câu ngắn, rõ hành động và nhất quán với thuật ngữ giao diện.
  4. Đối chiếu cấu trúc: kiểm tra lại mọi ký hiệu kỹ thuật với câu nguồn trước khi xác nhận.
  5. Rà soát trong ngữ cảnh: nếu có bản xem trước hoặc thông tin vị trí hiển thị, kiểm tra độ dài, xuống dòng và ý nghĩa thực tế.

Với các thông báo có số lượng hoặc dữ liệu thay đổi, nên chú ý cách viết để câu vẫn tự nhiên ở nhiều giá trị. Không nên giả định dữ liệu luôn là một, nhiều, nam hay nữ nếu biến không cung cấp thông tin đó. Có thể dùng cấu trúc trung tính như Đã xử lý {count} mục khi phù hợp.

Nguyên tắc thực hành: chỉ dịch những gì người dùng cần đọc; giữ nguyên những gì hệ thống cần hiểu.

Kiểm soát chất lượng và phối hợp với nhóm kỹ thuật

Kiểm tra ngôn ngữ thôi chưa đủ đối với bản dịch phần mềm. Cần kiểm soát đồng thời tính đúng đắn của câu dịch và tính toàn vẹn kỹ thuật của chuỗi. Khi có thể, nên thực hiện bước kiểm tra tự động để phát hiện placeholder thiếu, thẻ không cân bằng hoặc ký tự đặc biệt bị thay đổi.

Danh sách rà soát cuối

  • Tất cả biến, placeholder và ký tự escape có còn đủ không?
  • Thẻ HTML có mở, đóng và lồng đúng cấu trúc không?
  • Tên lệnh, khóa, mã lỗi, đường dẫn và định danh có bị dịch hoặc sửa kiểu chữ không?
  • Dấu câu có nằm đúng phía trong hoặc ngoài thẻ định dạng theo cấu trúc nguồn không?
  • Câu dịch có rõ ý khi dữ liệu động được chèn vào không?
  • Thuật ngữ của nút, menu và thao tác có nhất quán với các chuỗi liên quan không?

Nếu chuỗi mơ hồ, hãy ghi nhận câu hỏi cụ thể thay vì tự suy đoán: vị trí xuất hiện ở đâu, biến trả về kiểu dữ liệu gì, giới hạn ký tự là bao nhiêu, thẻ có được phép thay đổi vị trí không, và đoạn code có hiển thị cho người dùng hay chỉ phục vụ nội bộ. Trao đổi sớm với người quản lý bản địa hóa, kiểm thử viên hoặc lập trình viên giúp hạn chế việc phải sửa hàng loạt sau khi tích hợp.

Cuối cùng, nên duy trì bảng thuật ngữ và quy ước dự án cho các mẫu lặp lại, chẳng hạn cách đặt khoảng trắng quanh biến, cách dịch tên nút và cách xử lý nội dung trong thẻ. Sự nhất quán này giúp nhiều người cùng dịch mà vẫn bảo đảm trải nghiệm giao diện đồng bộ.

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

Có được dịch tên biến như {name} hoặc {{user}} không?

Không. Thông thường cần giữ nguyên toàn bộ tên biến, dấu ngoặc và ký tự đi kèm; chỉ dịch phần văn bản xung quanh.

Placeholder có thể đổi vị trí trong câu tiếng Việt không?

Có thể nếu định dạng placeholder hỗ trợ và biến vẫn được giữ nguyên đầy đủ. Cần kiểm tra kỹ với dạng có số thứ tự hoặc kiểu dữ liệu.

Có nên dịch nội dung trong thẻ HTML không?

Nên dịch văn bản hiển thị giữa các thẻ, nhưng giữ nguyên tên thẻ, cấu trúc mở/đóng và các thuộc tính kỹ thuật.

Tên lệnh như npm install có cần Việt hóa không?

Không. Tên lệnh, đoạn code, khóa cấu hình và cú pháp kỹ thuật thường phải giữ nguyên để người dùng có thể thực hiện đúng.

Lỗi nào cần kiểm tra đầu tiên trước khi bàn giao bản dịch phần mềm?

Hãy kiểm tra biến và placeholder có đủ, thẻ HTML có cân bằng, và code hoặc ký tự đặc biệt có bị thay đổi hay không.

Dịch vụ liên quan

← Trở về Blog Sen VàngTrao đổi về tài liệu của bạn ↗