Một tệp JSON có thể mở được bằng trình soạn thảo và trông chỉ như một danh sách câu ngắn. Nhưng nếu dịch nhầm khóa, làm mất biến hoặc thay cấu trúc, câu chữ đã dịch có thể không xuất hiện đúng trên website và ứng dụng. Hướng dẫn này dành cho người phụ trách nội dung, quản lý sản phẩm và đội phát triển cần chuẩn bị, giao dịch và kiểm tra tệp trước khi phát hành.
Dịch vụ liên quan: Dịch website, phần mềm và appHiệu đính bản dịchDịch thuật chuyên ngành
Dịch JSON khác dịch một tài liệu văn bản ở điểm nào?
Trong một tài liệu văn bản, bạn thường đọc được thứ tự đoạn và ngữ cảnh xung quanh. Trong JSON, một câu có thể nằm xa các câu sẽ xuất hiện bên cạnh nó trên giao diện. Cụm “Tiếp tục” có thể là nút chuyển bước, còn một từ như “Trạng thái” có thể là nhãn hoặc tiêu đề cột. Người dịch cần hiểu vai trò thực để chọn câu đúng và giữ nhất quán trong trải nghiệm người dùng.
Tệp còn chứa phần chương trình dùng để tra cứu nội dung. Nếu phần này bị thay mà mã không thay theo, ứng dụng có thể tìm sai chuỗi, hiện tên khóa hoặc quay về ngôn ngữ dự phòng. Vì vậy, công việc cần tách rõ phần được dịch và phần phải giữ. Không nên gửi cả tệp rồi chỉ ghi dịch toàn bộ, đặc biệt khi trong đó có mã, đường dẫn, cờ cấu hình hoặc các giá trị không dành cho người đọc.
Đầu ra cũng cần được chốt: trả cùng định dạng, một bảng song ngữ để duyệt hay cả tệp đã nhập lại. Nếu dùng công cụ quản lý bản dịch, cần thống nhất cách xuất và nhập. Một bản Excel có nội dung đúng chưa thay thế được tệp JSON cần để triển khai nếu chưa có người chịu trách nhiệm chuyển về định dạng cuối và kiểm tra kết quả.
Khóa, giá trị và cấu trúc: thống nhất ranh giới được sửa
Trong ví dụ đơn giản, một khóa có thể là tên tra cứu như checkout.confirm, còn giá trị là câu người dùng nhìn thấy. Dấu chấm có thể nằm trong tên khóa hoặc đại diện cách tổ chức do dự án quy định; không nên suy từ cách trình bày để tự sắp lại tệp. Hãy yêu cầu đội phát triển chỉ rõ phần được dịch, cách tổ chức và những trường hợp ngoại lệ trước khi bắt đầu.
Không phải mọi giá trị kiểu văn bản đều là nội dung hiển thị. Có thể có URL, mã sản phẩm, tên lớp hoặc giá trị phục vụ tích hợp. Những trường này cần đánh dấu hoặc tách khỏi phạm vi. Nếu muốn thay đường dẫn cho thị trường khác, đó phải là yêu cầu được xác nhận, không phải quyết định tự động của người dịch khi nhìn thấy một đoạn có chữ.
Các dấu ngoặc, dấu phân cách, chuỗi lồng nhau và kiểu dữ liệu cần được bảo toàn theo định dạng được dùng. Người dịch không nên tự đổi một giá trị số thành chữ hoặc chuyển một danh sách thành đoạn văn. Khi có yêu cầu thay cấu trúc để phù hợp ngôn ngữ, cần ghi thành đề nghị cho đội phát triển kiểm tra, thay vì âm thầm sửa tệp rồi kỳ vọng hệ thống vẫn đọc đúng.
Placeholder là gì và tại sao phải giữ chính xác?
Placeholder là vị trí hệ thống sẽ chèn dữ liệu khi hiển thị, chẳng hạn tên người, số lượng hoặc ngày. Cú pháp thay đổi theo thư viện và cấu hình. Một dự án có thể dùng ngoặc kép, dấu phần trăm hoặc ký hiệu riêng; không được áp quy tắc của dự án trước cho mọi tệp. Hãy xin danh sách quy ước và ví dụ dữ liệu thực tế đã được làm phù hợp để chia sẻ.
Phần tên biến thường phải giữ nguyên, nhưng vị trí trong câu có thể cần thay để ngôn ngữ đích tự nhiên. Ví dụ, lời chào có tên người có thể dùng thứ tự khác giữa hai ngôn ngữ. Trước khi chuyển vị trí, phải hiểu biến chứa gì và hệ thống có hỗ trợ cách dùng đó không. Đừng đổi tên biến sang tiếng Việt vì cho rằng nó là một từ cần dịch.
Một lỗi thường gặp là xóa mất ký hiệu khi sửa câu hoặc thêm khoảng trắng vào trong tên biến. Kết quả có thể hiện nguyên ký hiệu hoặc mất dữ liệu. Nên có bước đối chiếu tập placeholder giữa nguồn và đích. Người viết kiểm ý nghĩa của câu; đội kỹ thuật kiểm cách thay dữ liệu. Hai việc bổ sung nhau, vì tệp đúng cú pháp vẫn có thể dùng biến ở vị trí gây hiểu nhầm.
Ngữ cảnh cần gửi kèm mỗi nhóm chuỗi
Với nút, cần biết thao tác sau khi bấm. Với thông báo lỗi, cần biết điều kiện phát sinh và người dùng nên làm gì tiếp. Với nhãn trường, cần biết loại dữ liệu nhập và ví dụ định dạng. Thay vì gửi một ảnh chụp chung của cả sản phẩm, hãy gắn thông tin với khóa hoặc nhóm màn hình để người dịch có thể tra đúng lúc cần.
Nếu có giới hạn độ dài, ghi rõ giới hạn đó là số ký tự, số dòng hay không gian hiển thị. Ba cách mô tả không tương đương. Một từ ngắn có thể vẫn rộng trên màn hình, trong khi câu dài có thể xuống dòng hợp lý. Người dịch cần biết giới hạn để đề xuất lựa chọn, còn kết quả phải được xem trên giao diện thật trước khi chốt.
Những câu giống nhau trên nguồn chưa chắc được dùng cùng nghĩa. Từ “mở” có thể là động từ, trạng thái hoặc một lựa chọn. Đừng gộp khóa chỉ vì văn bản trùng mà chưa kiểm vai trò. Ngược lại, những chuỗi cùng một hành động nên có lựa chọn nhất quán. Bảng ngữ cảnh giúp phân biệt lúc nào dùng chung và lúc nào cần giữ riêng.
Chuẩn bị gói nguồn để người dịch không phải đoán
Gói nguồn nên có tệp cuối theo từng ngôn ngữ hoặc phạm vi, danh sách ngôn ngữ đích, quy tắc không sửa, ảnh màn hình và bảng thuật ngữ. Ghi rõ phiên bản hoặc ngày chốt. Nếu có các namespace hoặc nhóm chức năng, giữ cách tổ chức để người dịch hiểu mối liên hệ. Không trộn tệp đang dùng với tệp thử nghiệm mà không đánh dấu, vì có thể dịch nhầm chuỗi chưa cần phát hành.
Tách những phần không nằm trong yêu cầu, hoặc có cột trạng thái rõ nếu không thể tách. Nếu chỉ cần dịch chuỗi mới, phải xác định nguồn so sánh và xử lý chuỗi đã sửa. Một câu được giữ cùng khóa nhưng đổi nội dung vẫn có thể cần dịch lại. Chỉ lọc khóa mới có thể bỏ sót nhóm này và tạo giao diện trong đó ngôn ngữ nguồn đã đổi còn bản đích vẫn nói theo nghĩa cũ.
Đối với dữ liệu mẫu, dùng nội dung được phép chia sẻ và đủ đại diện. Không gửi thông tin khách thật chỉ để minh họa tên người trong lời chào. Có thể thay bằng dữ liệu giả định nhưng giữ đặc điểm cần kiểm, như tên dài hoặc ngày có định dạng cụ thể. Việc chọn dữ liệu tốt giúp kiểm giao diện mà không mở rộng việc chia sẻ thông tin không cần thiết.
Thống nhất thuật ngữ của sản phẩm trước khi dịch nhiều chuỗi
Một ứng dụng có thể dùng cùng khái niệm ở menu, thông báo, tài liệu trợ giúp và email. Nếu mỗi nơi được dịch khác, người dùng khó biết chúng có liên quan. Hãy lập bảng các khái niệm chính: tài khoản, đơn, dự án, bản nháp, lưu, gửi hoặc hoàn tất theo sản phẩm. Mỗi mục nên có định nghĩa ngắn và ví dụ, không chỉ một cặp từ không ngữ cảnh.
Với tên thương mại, tên tính năng hoặc các từ cần giữ nguyên, nêu quy tắc rõ. Có khi tên tính năng được giữ nhưng phần mô tả cần dịch; có khi một thuật ngữ cần dạng ngắn trên nút và dạng đầy đủ trong hướng dẫn. Người phụ trách nên duyệt các lựa chọn đại diện trước khi dịch cả bộ. Một vòng duyệt mẫu có thể giảm việc đổi thuật ngữ trên hàng trăm chuỗi cuối dự án.
Đừng dùng bảng thuật ngữ như lệnh thay từ hàng loạt. Một từ nguồn có thể có nhiều nghĩa trong các màn hình khác nhau. Người dịch cần đọc câu và vai trò, còn người duyệt cần phản hồi với căn cứ sản phẩm. Nếu quyết định đổi một thuật ngữ, xác định các nhóm chuỗi bị ảnh hưởng và kiểm trong ngữ cảnh, thay vì chỉ tìm rồi thay mọi chữ giống nhau.
Số nhiều, dữ liệu động và câu ghép cần được kiểm riêng
Cách xử lý số nhiều phụ thuộc ngôn ngữ và hệ thống đang dùng. Có dự án dùng các khóa riêng hoặc cú pháp thông điệp để chọn câu theo số. Không tự bỏ một dạng chỉ vì hai dạng tiếng Việt đang trông giống nhau, và cũng không tự thêm dạng theo kinh nghiệm thư viện khác. Đội phát triển cần xác nhận định dạng, phiên bản và cách hệ thống yêu cầu dữ liệu.
Với câu ghép từ nhiều mảnh, người dịch có thể không tạo được câu tự nhiên chỉ bằng việc sửa mỗi phần. Ví dụ, tên hành động, số lượng và đối tượng được nối ở mã có thể cần thứ tự khác trong ngôn ngữ đích. Khi phát hiện vấn đề, ghi đề nghị đổi cách tổ chức chuỗi để đội sản phẩm và kỹ thuật xem xét. Đừng giải quyết bằng khoảng trắng hoặc dấu câu ngẫu nhiên rồi làm hỏng trường hợp khác.
Nên kiểm các giá trị đại diện như không có dữ liệu, một mục, nhiều mục và dữ liệu dài. Đây là cách tìm lỗi hiển thị và nghĩa trong tình huống thật, không phải chỉ xem tệp dịch đã có đủ dòng. Các trường hợp cần thử phải phù hợp thiết kế của sản phẩm. Người dịch không nên tự quyết quy tắc nghiệp vụ chỉ từ câu chữ trong tài nguyên ngôn ngữ.
Ví dụ: lời chào đúng nhưng thông báo đơn hàng lại khó hiểu
Giả sử tệp có lời chào chứa tên và thông báo số đơn đang chờ. Lời chào có thể dễ dịch khi biết biến là tên người. Nhưng thông báo đơn hàng cần biết đang chờ ai xử lý và người đọc có quyền làm gì. Nếu chỉ thấy câu ngắn, người dịch có thể dùng một cách hiểu đúng ngữ pháp nhưng sai luồng công việc. Đây là lý do cần ảnh hoặc mô tả trạng thái đi kèm.
Trước tiên, đối chiếu các khóa và biến của hai câu. Sau đó hỏi nội dung động được truyền vào là số, tên hay cả cụm. Nếu biến đã chứa đơn vị hoặc một phần câu, thêm đơn vị lần nữa có thể làm lặp. Nếu biến chỉ là số, bỏ nhãn có thể khiến thông báo mất nghĩa. Không thể quyết định bằng việc nhìn một ký hiệu mà chưa biết dữ liệu của nó.
Khi có bản dịch, kiểm thử trên màn hình bằng dữ liệu ngắn và dài. Nhìn xem lời chào có xuống dòng bất thường không, thông báo có thể hiện đúng trạng thái không và nút bên cạnh có khớp việc cần làm không. Nếu sửa, ghi đúng khóa và ảnh minh họa màn hình để đội phát triển cập nhật vào tệp. Đừng chỉ gửi một câu mới mà không nói thay chuỗi nào.
Kiểm cú pháp và kiểm ngôn ngữ phải là hai lượt khác nhau
Lượt kiểm cú pháp xác định tệp có được hệ thống đọc và có giữ cấu trúc yêu cầu không. Lượt kiểm ngôn ngữ xem nghĩa, thuật ngữ, giọng và hướng dẫn thao tác. Tệp qua bộ kiểm định không chứng minh câu đúng; ngược lại, câu rất hay chưa đủ nếu tệp không đọc được. Nghiệm thu cần có cả hai, với người chịu trách nhiệm phù hợp và cách phản hồi rõ.
Các mục kỹ thuật có thể đối chiếu gồm tập khóa theo phạm vi, kiểu dữ liệu và placeholder. Không phải mọi khác biệt giữa hai ngôn ngữ đều là lỗi, vì thiết kế tài nguyên có thể cho phép khác theo quy tắc đã thống nhất. Điều quan trọng là kiểm theo hợp đồng định dạng của dự án, không áp một phép so đơn giản rồi xóa mọi phần khác biệt mà chưa hiểu lý do.
Với ngôn ngữ, kiểm các nhóm có rủi ro hiểu sai: phủ định, điều kiện, số lượng, trạng thái, hành động không thể hoàn tác và hướng dẫn nhập liệu. Một lỗi ở thông báo xác nhận có thể ảnh hưởng quyết định người dùng nhiều hơn lỗi văn phong ở một đoạn giới thiệu. Ưu tiên kiểm theo tác động thực tế giúp vòng rà soát hiệu quả mà không bỏ qua phần còn lại.
Kiểm thử giao diện sau khi nhập lại tệp
Sau nhập, mở các màn hình trong phạm vi và kiểm ở kích thước thường dùng. Tìm chữ bị cắt, nút quá dài, chuỗi thiếu hoặc còn ngôn ngữ nguồn. Nếu ngôn ngữ dự phòng xuất hiện, cần xác định đó là thiết kế hay thiếu tài nguyên. Không chỉ sửa bằng cách rút ngắn mọi câu, vì có thể bỏ thông tin cần để người dùng hiểu thao tác.
Chụp lỗi kèm đường tới màn hình, khóa nếu xác định được, dữ liệu thử và kết quả mong muốn. Một phản hồi như chữ tràn trên trang thanh toán sẽ khó xử lý hơn thông tin chỉ rõ trường, trạng thái và ảnh. Khi có nhiều lỗi, phân loại ngôn ngữ, bố cục, nguồn hoặc tích hợp. Điều đó giúp giao đúng người xử lý thay vì mọi vấn đề đều quay lại người dịch.
Sau sửa, kiểm lại màn hình có liên quan. Một thuật ngữ được đổi ở nút có thể cần đổi ở trợ giúp và thông báo; một câu ngắn hơn có thể vẫn lỗi khi dữ liệu động dài. Nên có danh sách trạng thái để biết lỗi nào đã xác nhận xử lý. Đừng chỉ đóng việc dựa trên việc tệp đã được gửi lại mà chưa xem phiên bản mới trong môi trường kiểm thử.
Bàn giao theo phiên bản và xử lý cập nhật tiếp theo
Bộ bàn giao nên có tệp cuối, phạm vi đã xử lý, danh sách vấn đề còn chờ và quy ước phiên bản. Nếu có chuỗi giữ nguyên theo yêu cầu, ghi lý do ở tài liệu công việc. Không trộn ghi chú vào nội dung hiển thị nếu hệ thống không có trường dành cho việc đó. Người nhận cần biết tệp nào đưa vào sản phẩm và tệp nào chỉ để theo dõi phản hồi.
Khi sản phẩm cập nhật, dùng bản nguồn mới đã xác định và ghi các chuỗi mới, sửa hoặc bỏ. Một khóa bị xóa ở nguồn có thể vẫn xuất hiện trong bản đích nếu quy trình không kiểm phạm vi; một khóa giữ tên nhưng đổi nghĩa có thể cần dịch lại. Cần cách theo dõi thay đổi thay vì chỉ gửi toàn bộ tệp rồi yêu cầu làm như lần trước mà không biết phần nào thực sự khác.
Lưu bảng thuật ngữ và lựa chọn đã duyệt để lần sau có cơ sở, nhưng vẫn kiểm theo ngữ cảnh mới. Khi người duyệt thay đổi, tài liệu bàn giao giúp họ hiểu quyết định trước. Nếu một chuỗi cũ không còn phù hợp, hãy sửa có phạm vi và kiểm các điểm dùng chung. Tính nhất quán cần được duy trì có chủ đích, không đồng nghĩa giữ mọi lựa chọn cũ bất kể sản phẩm đã thay.
Gửi yêu cầu dịch JSON cho Tân Việt cần chuẩn bị gì?
Bạn nên gửi tệp được phép chia sẻ, số ngôn ngữ, nguồn cuối, mục đích và thời hạn. Bổ sung ảnh màn hình hoặc mô tả cho các nhóm khó hiểu, quy ước placeholder và giới hạn hiển thị. Nếu chưa có cách xuất tệp, trao đổi với đội phát triển để xác định định dạng bàn giao phù hợp. Người dịch cần được cung cấp dữ liệu để chuyển nghĩa; đội kỹ thuật vẫn chịu trách nhiệm tích hợp và kiểm chức năng.
Dịch vụ dịch website và nội dung đa ngôn ngữ hoặc dịch ứng dụng nên được chọn theo phần việc cần xử lý. Nếu chỉ có chuỗi mới, nói rõ phạm vi; nếu cần rà soát bộ đã dịch, gửi cả nguồn và đích. Khi đã có yêu cầu cụ thể, dùng trang báo giá nhanh để gửi tài liệu và thông tin cần kiểm tra.
Bạn có thể đọc thêm kinh nghiệm dịch website tự nhiên và dễ dùng và lưu ý về thuật ngữ tài liệu phần mềm khi chuẩn bị. Mục tiêu cuối không chỉ là đủ câu đã dịch, mà là tệp có thể nhập lại, câu phù hợp màn hình và kết quả được kiểm trên đúng phiên bản sẽ phát hành.
Câu hỏi thường gặp
Có phải dịch toàn bộ chữ trong file JSON không?
Không nên mặc định. Cần phân biệt khóa, giá trị hiển thị và dữ liệu phục vụ kỹ thuật như mã hoặc đường dẫn. Đội phát triển nên xác nhận phạm vi được sửa và những trường phải giữ trước khi giao dịch.
Người dịch có được đổi tên biến trong câu không?
Thông thường cần giữ đúng tên và cú pháp đã được dự án quy định. Vị trí có thể cần xem theo ngôn ngữ đích và khả năng hệ thống, nhưng không tự đổi tên biến thành từ đã dịch. Cần kiểm với dữ liệu đại diện sau nhập.
Tệp đọc được rồi có cần kiểm trên giao diện không?
Có. Tệp đúng cú pháp vẫn có thể thiếu ngữ cảnh, tràn chữ hoặc dùng sai trạng thái. Nên kiểm màn hình thực và các trường hợp có dữ liệu động, đồng thời phân biệt lỗi ngôn ngữ với lỗi tích hợp.
Có thể gửi bảng Excel thay JSON cho người dịch không?
Có thể nếu quy trình xuất nhập được thống nhất và giữ đủ khóa, ngữ cảnh, biến. Cần có người chịu trách nhiệm chuyển lại định dạng cuối và kiểm tra, tránh nhập thủ công từ một bảng không còn đủ thông tin.
Cùng một câu nguồn có cần dùng chung một khóa không?
Không nhất thiết. Cần xem vai trò và nghĩa trên từng màn hình. Những câu giống chữ nhưng khác ngữ cảnh có thể cần tách. Quyết định về cách tổ chức tài nguyên nên được đội sản phẩm và kỹ thuật xác nhận.
Có cần cung cấp dữ liệu khách thật để kiểm biến không?
Thường có thể dùng dữ liệu thử đại diện thay cho thông tin khách thật. Chọn mẫu đủ kiểm tên dài, số và ngày theo phạm vi cho phép. Không mở rộng chia sẻ dữ liệu chỉ vì cần ví dụ cho một placeholder.
Cập nhật vài chuỗi có phải dịch lại cả bộ không?
Cần kiểm phần mới, sửa và những chỗ bị ảnh hưởng về thuật ngữ hoặc ngữ cảnh. Không nhất thiết làm lại mọi câu, nhưng chỉ lọc khóa mới cũng có thể bỏ sót khóa cũ đã đổi nghĩa.
Dịch JSON có bao gồm sửa mã ứng dụng không?
Phải thống nhất phạm vi. Chuyển ngữ tài nguyên, hiệu đính và kiểm ngôn ngữ khác với sửa mã hoặc tích hợp. Nếu phát hiện cấu trúc không phù hợp, cần ghi vấn đề để đội kỹ thuật xử lý theo yêu cầu được duyệt.
