Dịch tài liệu công nghệ thông tin là dịch những văn bản mô tả hệ thống: đặc tả yêu cầu, tài liệu kiến trúc và thiết kế, tài liệu API cho lập trình viên, hướng dẫn quản trị và vận hành, chính sách an toàn thông tin cùng hồ sơ phục vụ đánh giá, và hồ sơ thầu CNTT. Khác với dịch giao diện phần mềm (thuộc mảng bản địa hoá), ở đây người đọc là kỹ sư, quản trị hệ thống, kiểm toán viên và bộ phận mua sắm.
Hai câu hỏi lớn nhất khi dịch tài liệu CNTT sang tiếng Việt là chữ nào giữ nguyên, chữ nào dịch, và làm sao để bản dịch không phá cấu trúc kỹ thuật của tệp gốc (mã nguồn, biến, định dạng Markdown, tệp cấu hình). Bài này đưa ra nguyên tắc cho cả hai, cùng những lỗi dịch làm thay đổi yêu cầu kỹ thuật hoặc phạm vi hợp đồng.
Loại tài liệu và trọng tâm khi dịch
Mỗi loại tài liệu CNTT có rủi ro dịch khác nhau. Xác định đúng loại giúp chọn đúng người dịch và người duyệt.
| Loại tài liệu | Người đọc | Trọng tâm khi dịch |
|---|---|---|
| Đặc tả yêu cầu, tài liệu nghiệp vụ | Chủ đầu tư, đội phát triển, kiểm thử | Mức bắt buộc của từng yêu cầu, điều kiện chấp nhận, không làm rộng hay hẹp phạm vi |
| Tài liệu kiến trúc, thiết kế | Kiến trúc sư giải pháp, kỹ sư | Thuật ngữ kiến trúc nhất quán, giữ nguyên tên thành phần, sơ đồ có chú thích |
| Tài liệu API, tài liệu cho lập trình viên | Lập trình viên tích hợp | Không đụng mã, tên hàm, tham số, giá trị mẫu; chỉ dịch phần mô tả |
| Hướng dẫn quản trị, vận hành | Quản trị hệ thống | Thứ tự bước, lệnh giữ nguyên, cảnh báo về mất dữ liệu |
| Chính sách và quy trình an toàn thông tin | Nhân viên, kiểm toán viên, tổ chức đánh giá | Mức nghĩa vụ, vai trò trách nhiệm, thống nhất với thuật ngữ tiêu chuẩn đang áp dụng |
| Hồ sơ mời thầu, hồ sơ dự thầu CNTT | Tổ chuyên gia, bên mời thầu | Yêu cầu kỹ thuật bắt buộc, tiêu chí đánh giá, cam kết mức dịch vụ |
Điểm chung: người dịch cần đọc được tài liệu như một kỹ sư, biết đâu là tên riêng kỹ thuật (tên dịch vụ, tên lớp, tên trường dữ liệu) để không dịch nhầm thành từ thường.
Giữ nguyên hay dịch: nguyên tắc cho từng loại chữ
Mã nguồn, lệnh, tên tệp, đường dẫn: giữ nguyên. Mọi thứ nằm trong khối mã hoặc định dạng mã trong dòng là đối tượng máy đọc. Dịch một tên tham số hay một khoá cấu hình làm ví dụ không chạy được. Chú thích trong mã có thể dịch nếu khách hàng yêu cầu, nhưng phải giữ cú pháp chú thích của ngôn ngữ lập trình đó.
Chuỗi giao diện được nhắc tới: theo giao diện thật. Khi tài liệu viết "nhấn Save", nếu sản phẩm có giao diện tiếng Việt, bản dịch dùng đúng chuỗi đang hiện trên giao diện ("Lưu"); nếu giao diện chỉ có tiếng Anh, giữ "Save" và có thể kèm nghĩa ở lần đầu. Không tự đặt tên nút mới mà người dùng không tìm thấy trên màn hình.
Thuật ngữ kỹ thuật: chọn một chính sách và giữ. Tiếng Việt CNTT dùng song song từ Việt hoá và từ gốc: "máy chủ" và "server", "cơ sở dữ liệu" và "database", "triển khai" và "deploy". Không có đáp án đúng tuyệt đối; điều quan trọng là doanh nghiệp chọn một chính sách (Việt hoá tối đa, giữ từ gốc, hay Việt hoá kèm từ gốc trong ngoặc ở lần đầu) và áp dụng nhất quán. Với tài liệu nộp cơ quan nhà nước, nên ưu tiên thuật ngữ trong văn bản pháp luật và tiêu chuẩn quốc gia về CNTT.
Biến giữ chỗ và định dạng: không đụng. Chuỗi như {user_name}, %s, {{count}} là biến giữ chỗ; dịch hay đổi thứ tự sai cú pháp làm hỏng hiển thị. Định dạng Markdown, thẻ trong tệp tài liệu, khoá trong phần khai báo đầu tệp phải giữ nguyên để hệ thống dựng tài liệu chạy được.
Mức bắt buộc trong đặc tả: MUST, SHOULD, MAY
Đặc tả kỹ thuật và tài liệu giao thức thường dùng các từ khoá theo quy ước của RFC 2119 (Bradner, 1997): MUST và MUST NOT là bắt buộc tuyệt đối, SHOULD là khuyến nghị mạnh nhưng có thể có lý do chính đáng để không theo, MAY là tuỳ chọn. Đặc tả yêu cầu phần mềm theo các chuẩn kỹ thuật hệ thống cũng hay dùng "shall" cho yêu cầu bắt buộc. Khi viết in hoa, các từ này mang nghĩa quy ước, không phải nghĩa thông thường.
Bản dịch phải giữ được tầng nghĩa này. Cách làm phổ biến là dịch "MUST" thành "PHẢI", "SHOULD" thành "NÊN", "MAY" thành "CÓ THỂ" (theo nghĩa được phép), giữ in hoa như bản gốc, và thêm một đoạn ở đầu tài liệu giải thích quy ước. Dịch "SHOULD" thành "phải" biến khuyến nghị thành nghĩa vụ hợp đồng; dịch "MUST" thành "nên" làm mất một yêu cầu nghiệm thu. Trong hồ sơ thầu, sai lệch này có thể đổi kết quả đánh giá hồ sơ dự thầu.
Tương tự, các cụm định lượng trong yêu cầu phi chức năng ("at least 99.9% availability per calendar month", "response time under 200 ms for 95% of requests") phải giữ đúng từng điều kiện: mốc tính, phân vị, khoảng thời gian. Bỏ cụm "for 95% of requests" làm yêu cầu trở nên khắt khe hơn hẳn.
Lỗi hay gặp trong bản dịch tài liệu CNTT
Các lỗi sau thường không lộ khi đọc lướt bản tiếng Việt, nhưng lộ ra ngay khi kỹ sư làm theo.
| Lỗi | Ví dụ | Cách tránh |
|---|---|---|
| Dịch tên riêng kỹ thuật thành từ thường | Tên dịch vụ "Gateway" dịch thành "cổng" ở đoạn này, "cửa ngõ" ở đoạn khác | Lập danh sách tên thành phần hệ thống, giữ nguyên trong mọi tài liệu |
| Đổi định dạng số, ngày giờ trong ví dụ mã | Đổi 3.5 thành 3,5 trong một đoạn JSON mẫu | Không đổi gì trong khối mã; chỉ đổi định dạng số trong câu văn |
| Dịch thông báo lỗi trong tài liệu | Thông báo "Connection refused" dịch sang tiếng Việt | Giữ nguyên thông báo hệ thống để người đọc tìm kiếm được; giải thích nghĩa bên cạnh |
| Nhầm thuật ngữ an toàn thông tin | Dịch lẫn "authentication" và "authorization" | Xác thực (bạn là ai) và phân quyền (bạn được làm gì) là hai khái niệm khác nhau |
| Gộp hoặc tách bước lệnh | Gộp hai lệnh trên hai dòng thành một câu mô tả | Giữ đúng số bước và thứ tự lệnh như bản gốc |
Nhóm lỗi thuật ngữ an toàn thông tin đáng chú ý riêng: "vulnerability" (lỗ hổng), "threat" (mối đe doạ), "risk" (rủi ro), "incident" (sự cố), "event" (sự kiện) mỗi từ có định nghĩa riêng trong bộ tiêu chuẩn về an toàn thông tin. Dùng lẫn làm chính sách mâu thuẫn với tiêu chuẩn mà doanh nghiệp đang áp dụng.
Chính sách an toàn thông tin và hồ sơ đánh giá
Doanh nghiệp áp dụng hệ thống quản lý an toàn thông tin theo ISO/IEC 27001, hoặc phục vụ khách hàng nước ngoài yêu cầu bằng chứng tuân thủ, thường phải có chính sách và quy trình song ngữ. Bản tiếng Việt dành cho nhân viên thực hiện, bản tiếng Anh cho khách hàng và tổ chức đánh giá. Hai bản phải nói cùng một điều: cùng vai trò, cùng tần suất rà soát, cùng thời hạn lưu trữ nhật ký. Khi hai bản lệch nhau, đánh giá viên có thể ghi nhận điểm không phù hợp vì nhân viên làm theo bản khác với bản được trình.
Cách làm bền là chọn một bản làm bản chuẩn (thường là bản soạn đầu tiên), mọi thay đổi sửa trên bản chuẩn trước rồi dịch phần thay đổi sang bản còn lại, và ghi số phiên bản giống nhau trên cả hai. Thuật ngữ nên theo bản tiếng Việt của tiêu chuẩn tương ứng nếu đã có TCVN chấp nhận, để khớp với cách tổ chức đánh giá trong nước sử dụng.
Hướng dẫn quản trị và vận hành: dịch cho người đang gõ lệnh
Hướng dẫn cài đặt, nâng cấp, sao lưu và khôi phục được đọc khi quản trị viên đang thao tác trên hệ thống thật, thường ngoài giờ, có khi trong lúc xử lý sự cố. Câu dịch phải theo đúng nhịp của bản gốc: mỗi bước một hành động, lệnh nằm riêng một dòng, kết quả mong đợi ghi ngay sau lệnh. Những câu điều kiện như "if the service is still running, stop it before continuing" phải giữ được trật tự điều kiện trước, hành động sau; đảo trật tự trong câu tiếng Việt dễ khiến người đọc làm trước rồi mới đọc tới điều kiện.
Các cảnh báo về mất dữ liệu, gián đoạn dịch vụ, thao tác không hoàn tác được cần được giữ nguyên mức nhấn mạnh và vị trí, tức là đứng trước bước nguy hiểm chứ không dồn xuống cuối mục. Phiên bản phần mềm mà hướng dẫn áp dụng ghi rõ ở đầu bản dịch; nếu khách hàng đang chạy phiên bản khác, người dịch không tự sửa lệnh cho "hợp" mà ghi chú để đội kỹ thuật kiểm. Bảng tham số cấu hình giữ nguyên tên tham số, giá trị mặc định và kiểu dữ liệu, chỉ dịch cột mô tả.
Bảo mật khi gửi tài liệu kỹ thuật đi dịch
Tài liệu kiến trúc, sơ đồ mạng, cấu hình máy chủ, tài liệu API nội bộ là thông tin nhạy cảm: lộ ra có thể giúp kẻ tấn công hiểu hệ thống. Trước khi gửi đi dịch, doanh nghiệp nên loại bỏ thông tin không cần cho việc dịch: địa chỉ IP thật, tên miền nội bộ, khoá truy cập, mật khẩu mẫu còn hiệu lực, dữ liệu khách hàng trong ví dụ. Thay bằng giá trị giả định không ảnh hưởng đến bản dịch.
Nên ký thoả thuận bảo mật với bên dịch, hỏi rõ tài liệu có được đưa qua công cụ dịch máy trực tuyến hay không, ai được tiếp cận, lưu ở đâu và xoá khi nào. Với mã nguồn, chỉ gửi phần tài liệu cần dịch, không gửi cả kho mã. Dịch Việt nhận dịch tài liệu CNTT theo tệp nguồn (Markdown, tệp tài liệu, bảng tính) để giữ cấu trúc, với người dịch có nền kỹ thuật phần mềm và thoả thuận bảo mật; bạn có thể gửi yêu cầu qua mẫu đăng ký trên trang kèm loại tài liệu và định dạng tệp.
Câu hỏi thường gặp
Nên Việt hoá thuật ngữ CNTT hay giữ tiếng Anh?
Không có câu trả lời chung. Tài liệu cho kỹ sư thường giữ nhiều thuật ngữ gốc vì đó là cách họ trao đổi hằng ngày; tài liệu nộp cơ quan nhà nước nên ưu tiên thuật ngữ trong văn bản pháp luật và tiêu chuẩn quốc gia. Điều quan trọng là chọn một chính sách và áp dụng nhất quán.
Dịch tài liệu API có cần người biết lập trình không?
Rất nên. Người dịch cần nhận ra đâu là tên tham số, đâu là giá trị mẫu, đâu là đoạn mô tả, và hiểu ý nghĩa của mã trạng thái, kiểu dữ liệu. Người không biết lập trình dễ dịch nhầm tên riêng kỹ thuật thành từ thường.
Tài liệu viết bằng Markdown có dịch trực tiếp được không?
Được và nên dịch trực tiếp trên tệp nguồn để giữ cấu trúc, liên kết nội bộ và khối mã. Bên dịch cần giữ nguyên cú pháp Markdown và phần khai báo đầu tệp, chỉ dịch phần văn bản hiển thị.
Hồ sơ thầu CNTT dịch sai mức bắt buộc thì hậu quả là gì?
Yêu cầu bắt buộc bị dịch thành khuyến nghị có thể khiến nhà thầu chào thiếu, còn khuyến nghị bị dịch thành bắt buộc có thể loại nhầm hồ sơ hoặc đội chi phí. Vì vậy cần ghi rõ bản ngôn ngữ nào có giá trị ưu tiên và rà riêng các từ chỉ mức nghĩa vụ.
Có cần dịch nội dung trong ảnh chụp màn hình không?
Nếu giao diện đã có bản tiếng Việt, nên chụp lại màn hình từ giao diện tiếng Việt thay vì sửa ảnh. Nếu không, giữ ảnh gốc và dịch phần chú thích ảnh, nhắc tên nút theo đúng chữ hiện trên ảnh.
