Cách dịch file DITA mà không cần chuyển đổi sang XLIFF

Bạn đang tìm kiếm một cách để dịch các tệp DITA của mình mà không phải đau đầu liên tục khi chuyển đổi XLIFF thủ công? Nếu đúng như vậy, bạn đang ở đúng nơi. DITA (Darwin Information Typing Architecture) đã là tiêu chuẩn vàng về hiệu quả và tái sử dụng nội dung, tuy nhiên nhiều nhóm nội dung kỹ thuật vẫn thấy mình bị mắc kẹt trong một chu kỳ khó chịu: Vòng lặp chuyển đổi XLIFF.

Nếu quy trình dịch thuật hiện tại của bạn liên quan đến việc xuất các tệp DITA sang XLIFF, gửi các tệp đó đến một đại lý và sau đó nhập lại thủ công chúng trở lại hệ thống của bạn, bạn có thể sẽ mất nhiều hơn là thời gian. Bạn có thể đang mạo hiểm với tính toàn vẹn của tài liệu mà bạn đã làm việc rất chăm chỉ để xây dựng.

Trong bài viết này, chúng ta sẽ nói về những cạm bẫy kỹ thuật của chuyển đổi thủ công, chi phí ẩn của việc quản lý delta và lý do tại sao hỗ trợ DITA gốc là một yếu tố thay đổi cuộc chơi cho các nhóm tài liệu hiện đại. Khi bạn đọc xong bài viết này, bạn sẽ sẵn sàng để bắt đầu tối ưu hóa quy trình dịch DITA của mình và chuyển sang một quy trình nhanh hơn, đáng tin cậy hơn và tiết kiệm chi phí hơn đáng kể. Chúng ta cùng bắt đầu ngay thôi!

Thuế XLIFF đối với tài liệu kỹ thuật

XLIFF (XML Localization Interchange File Format) là một tiêu chuẩn tuyệt vời cho nhiều thứ, nhưng đối với người dùng DITA, nó thường hoạt động như một trung gian làm phức tạp hơn là đơn giản hóa. Chúng ta thường gọi đây là Thuế XLIFF: chi phí tiềm ẩn của thời gian, tiền bạc và lao động chân tay cần thiết để làm cho định dạng hoạt động. Đây là lý do tại sao quá trình chuyển đổi thủ công này có thể khiến nhóm của bạn tốn kém hơn bạn nhận ra.

1. Phân tích tái sử dụng nội dung: Conrefs và Keyrefs

Thiên tài thực sự của DITA nằm ở khả năng tham khảo nội dung trên nhiều chủ đề. Khi bạn chuyển đổi tệp DITA sang XLIFF, các mối quan hệ phức tạp này thường bị làm phẳng hoặc bị phá vỡ hoàn toàn. Trong tệp XLIFF tiêu chuẩn, tham chiếu nội dung (conref) có thể chỉ xuất hiện dưới dạng một chuỗi văn bản tĩnh.

Điều này tạo ra một vấn đề tài chính đáng kể: cuối cùng bạn có thể phải trả tiền để dịch cùng một ghi chú Cảnh báo hoặc Quy trình An toàn nhiều lần vì công cụ chuyển đổi không nhận ra nó là một thực thể có thể tái sử dụng duy nhất. Tệ hơn nữa, khi bạn nhập lại văn bản đó, bạn có thể thấy rằng các tham chiếu nội dung toàn cầu của bạn đã bị ghi đè bởi văn bản được mã hóa cứng, điều này phá hủy kiến trúc mô-đun của bạn một cách hiệu quả và khiến các bản cập nhật trong tương lai trở thành cơn ác mộng.

2. Thẻ tham nhũng và lỗi xác thực

Các tệp DITA được điều chỉnh bởi các DTD nghiêm ngặt (Định nghĩa loại tài liệu) hoặc Lược đồ XML. Mỗi khi nội dung của bạn chuyển từ định dạng.dita sang .xliff và quay lại một lần nữa, bạn có nguy cơ tạo ra thứ mà chúng ta gọi là súp thẻ.

Chỉ cần một người dịch không quen thuộc với cấu trúc DITA để vô tình xóa thuộc tính bắt buộc hoặc đặt sai thẻ đóng. Một dấu ngoặc đơn bị thiếu hoặc một thuộc tính bị đặt sai trong chuyến đi khứ hồi đó có thể phá vỡ toàn bộ bản dựng DITA-OT của bạn. Tất cả chúng ta đều đã ở đó: đó là một buổi chiều thứ Sáu, và bạn đang cố gắng đẩy một bản phát hành, nhưng thay vào đó, các kỹ sư hỗ trợ của bạn đang săn lùng hàng ngàn dòng mã để tìm ra một lỗi xác thực duy nhất.

3. Cơn ác mộng quản lý Delta

Quy trình làm việc XLIFF thủ công thường buộc người viết ngừng trở thành người sáng tạo và bắt đầu trở thành người quản lý tệp. Để tiết kiệm chi phí dịch thuật, người viết thường cố gắng xác định thủ công các delta (chỉ các tệp đã thay đổi kể từ bản cập nhật cuối cùng). Quá trình này nổi tiếng là khó khăn vì ba lý do:

• Nó dễ bị lỗi: Chỉ thiếu một chủ đề cập nhật có thể dẫn đến tài liệu không đồng bộ khiến khách hàng của bạn bối rối.
• Về mặt kỹ thuật, nhóm của bạn phải dành hàng giờ để so sánh các phiên bản thay vì viết nội dung mới, hữu ích.
• Nó thiếu ngữ cảnh: Nếu một thay đổi nhỏ trong một chủ đề ảnh hưởng đến ý nghĩa của một chủ đề liên quan, lựa chọn delta thủ công có thể sẽ bỏ lỡ nó.

Ngoài thẻ: Tầm quan trọng của bảo vệ thuộc tính

Một trong những khía cạnh bị bỏ qua nhiều nhất của cuộc đấu tranh giữa DITA và XLIFF là quản lý các thuộc tính XML. DITA phụ thuộc rất nhiều vào các thuộc tính để lập hồ sơ và lọc, chẳng hạn như sản phẩm, nền tảng và đối tượng. Đây là những công cụ cho phép bạn xuất bản các phiên bản khác nhau của hướng dẫn sử dụng từ cùng một nguồn.

Khi bạn sử dụng quy trình làm việc DITA gốc, các thuộc tính này được bảo vệ theo mặc định. Tại MotaWord, hệ thống của chúng tôi nhận ra rằng thuộc tính sản phẩm là một phần siêu dữ liệu không bao giờ nên được dịch. Trong chuyển đổi XLIFF tiêu chuẩn, các thuộc tính này thường bị loại bỏ (phá vỡ việc xuất bản có điều kiện của bạn) hoặc hiển thị cho trình dịch. Nếu một dịch giả nhìn thấy pro_version và dịch nó sang tiếng Tây Ban Nha là version_profesional, logic xử lý có điều kiện của bạn sẽ không còn hoạt động nữa.

Tại sao Translate=No is a Lifesaver

Thuộc tính translate="no” là một công cụ quan trọng cho các nhà văn kỹ thuật, những người cần giữ cho đoạn mã, hướng dẫn dòng lệnh hoặc tên thương hiệu cụ thể nhất quán trên tất cả các ngôn ngữ. Trình phân tích cú pháp DITA gốc tôn trọng thuộc tính này ở cấp độ động cơ. Trong các chuyển đổi XLIFF thủ công, các hướng dẫn này thường bị bỏ qua bởi các bộ lọc được sử dụng để tạo tệp XLIFF, dẫn đến các chu kỳ hậu chỉnh sửa tốn kém và khó chịu để khắc phục nội dung được dịch quá mức.

Khoảng cách bối cảnh: Tại sao các dịch giả phải vật lộn với XLIFF

Dịch thuật không chỉ đơn thuần là trao đổi từ ngữ: nó là về việc hiểu ngữ cảnh. Khi một chủ đề DITA được chuyển đổi thành một tệp XLIFF phẳng, người dịch thường thấy một danh sách các chuỗi bị cô lập. Họ mất chế độ xem Bản đồ cung cấp cho dự án cấu trúc của nó. Họ không thể thấy rằng một tiêu đề cụ thể thuộc về một phần cụ thể trong một nhiệm vụ lớn hơn.

Bằng cách sử dụng Bản dịch DITA gốc, người dịch làm việc trong một hệ thống thực sự hiểu hệ thống phân cấp DITA. Điều này cung cấp một số lợi ích cho chất lượng tài liệu của bạn:

• Nó cung cấp sự rõ ràng hơn: Người dịch biết liệu một từ là một bước, một kết quả hay một điều kiện tiên quyết.
• Nó đảm bảo thuật ngữ nhất quán: Hệ thống đảm bảo rằng một thuật ngữ được sử dụng trong shortdesc khớp với cùng một thuật ngữ trong nội dung của chủ đề.
• Nó duy trì tính toàn vẹn hình ảnh: Luồng thông tin logic vẫn còn nguyên vẹn, điều này đặc biệt quan trọng khi bạn đang sản xuất các hướng dẫn kỹ thuật phức tạp cho phần cứng hoặc phần mềm.

Cách tốt hơn: Bản dịch DITA bản địa với MotaWord

Chúng tôi tin rằng các nhà văn kỹ thuật nên có thể tập trung vào nội dung, không phải chiến đấu với các định dạng tệp. Đó là lý do tại sao chúng tôi đã làm việc để loại bỏ người trung gian XLIFF thông qua cách tiếp cận gốc.

So sánh quy trình làm việc

Quy trình làm việc XLIFF thủ công

• Yêu cầu hàng giờ xuất và lọc tệp.
• Có nguy cơ làm phẳng các tham chiếu nội dung cao.
• Thường dẫn đến siêu dữ liệu bị hỏng hoặc vô tình được dịch.
• Yêu cầu QA thủ công mở rộng sau khi các tệp được nhập.
• Phát sinh chi phí ẩn thông qua lao động thủ công và chuỗi trùng lặp.

Quy trình làm việc DITA gốc với MotaWord

• Mất vài phút thông qua việc tải lên trực tiếp các tệp của bạn.
• Giữ tính toàn vẹn của tài khoản của bạn được bảo vệ 100%.
• Tự động khóa hoặc bỏ qua siêu dữ liệu để nó luôn an toàn.
• Cung cấp các tệp đã sẵn sàng xây dựng ngay khi bạn tải chúng xuống.
• Sử dụng Bộ nhớ dịch để đảm bảo bạn chỉ trả tiền cho nội dung mới.

Tải lên các tệp.dita và .ditamap thô của bạn

Thay vì xuất khẩu phức tạp, bạn chỉ cần tải lên các tệp DITA thô hoặc toàn bộ dự án Ditamap của bạn. Nền tảng của chúng tôi được xây dựng để phân tích cấu trúc DITA một cách nguyên bản. Nó hiểu sự khác biệt giữa tiêu đề, nội dung và shortdesc, đảm bảo siêu dữ liệu của bạn vẫn không bị ảnh hưởng và cấu trúc của bạn vẫn ổn định.

Tự động hóa thay vì khuếch tán thủ công

Bởi vì MotaWord sử dụng Bộ nhớ dịch tích hợp, bạn không còn cần phải dành thời gian tìm ra tệp nào đã thay đổi. Bạn có thể tải lên toàn bộ dự án và để hệ thống thực hiện công việc nặng nề:

• Hệ thống của chúng tôi so sánh toàn bộ Ditamap của bạn với các bản dịch trước đó của bạn.
• Nó xác định các chuỗi mới hoặc sửa đổi trong vài giây.
• Bạn chỉ trả tiền cho các từ mới, mang lại cho bạn những lợi ích chi phí của delta mà không phải đau đầu bằng tay.

Kinh tế của tài liệu sẵn sàng xây dựng

Chi phí ẩn thực sự của chuyển đổi XLIFF được tìm thấy trong chu kỳ xuất bản cuối cùng. Trong quy trình làm việc thủ công, việc nhận các tệp đã dịch chỉ là điểm nửa chừng. Bạn vẫn phải nhập lại mọi thứ vào CCMS (Hệ thống quản lý nội dung thành phần), chạy thử nghiệm bằng DITA Open Toolkit và gỡ lỗi XML không thể tránh khỏi.

Giai đoạn QA bản địa hóa này có thể mất nhiều ngày hoặc thậm chí vài tuần thời gian của nhà văn. Hỗ trợ DITA gốc đảm bảo rằng các tệp bạn tải xuống đã sẵn sàng để sử dụng. Bởi vì cấu trúc không bao giờ được tháo rời để phù hợp với thùng chứa XLIFF, nó không cần phải được xây dựng lại. Bạn có thể chuyển từ bản dịch đã hoàn thành sang trang web PDF hoặc HTML đã xuất bản chỉ trong vài cú nhấp chuột.

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

1. Làm thế nào để dịch các tệp DITA mà không phá vỡ conrefs?

Các nền tảng dịch DITA gốc như MotaWord xử lý các tệp trong cấu trúc XML ban đầu của chúng. Bằng cách tránh chuyển đổi sang XLIFF, hệ thống duy trì các con trỏ đến tham chiếu nội dung của bạn (conrefs) và tham chiếu chính (keyrefs). Điều này đảm bảo rằng các đối tượng có thể tái sử dụng được xử lý một cách chính xác mà không được mã hóa cứng vào văn bản dịch.

2. Quy trình dịch thuật DITA tốt nhất cho các nhóm nhỏ là gì?

Quy trình làm việc hiệu quả nhất cho các nhóm nhỏ là cách tiếp cận Direct to DITA. Thay vì đầu tư vào phần mềm trung gian đắt tiền hoặc dành hàng giờ cho việc xuất XLIFF thủ công, các nhóm nhỏ nên sử dụng một nền tảng chấp nhận trực tiếp các tệp.dita và .ditamap. Điều này làm giảm chi phí kỹ thuật và loại bỏ nhu cầu về một kỹ sư bản địa hóa chuyên dụng.

3. MotaWord có hỗ trợ DTD DITA chuyên dụng không?

Đúng. Vì DITA cho phép chuyên môn hóa (tạo các loại phần tử tùy chỉnh), bộ phân tích cú pháp gốc của chúng tôi được thiết kế để tôn trọng lược đồ XML cơ bản. Các thẻ và thuộc tính tùy chỉnh của bạn được bảo vệ và loại trừ khỏi số từ trừ khi chúng chứa nội dung có thể dịch được.

4. DITA vs XLIFF để dịch: cái nào tốt hơn?

Trong khi XLIFF là một định dạng trao đổi tuyệt vời cho các chuỗi phần mềm nói chung, DITA vượt trội hơn đối với tài liệu có cấu trúc vì nó chứa nhiều ngữ cảnh liên quan đến việc tái sử dụng nội dung. Dịch DITA một cách nguyên bản hầu như luôn tốt hơn vì nó ngăn chặn các lỗi khứ hồi phổ biến khi chuyển đổi giữa hai định dạng tệp khác nhau.

5. Tôi có thể sử dụng bản dịch DITA gốc với CCMS hiện có của mình không?

Tuyệt đối. Hầu hết các Hệ thống quản lý nội dung thành phần, như IXIASOFT, Heretto hoặc Oxygen Content Fusion, cho phép bạn xuất các gói DITA thô. Bạn có thể tải các gói này trực tiếp lên MotaWord và sau đó tải lại kết quả đã dịch trở lại CCMS của bạn mà không cần bất kỳ bước chuyển đổi trung gian nào.

6. Làm thế nào để giảm chi phí dịch thuật DITA bằng Bộ nhớ dịch?

Bằng cách tải toàn bộ Ditamap của bạn lên một nền tảng gốc, hệ thống sử dụng Bộ nhớ dịch (TM) để xác định các kết quả phù hợp chính xác từ các dự án trước đây của bạn. Bạn chỉ được tính phí cho văn bản mới hoặc sửa đổi, điều này giúp giảm đáng kể chi phí cho các dự án tài liệu kỹ thuật dài hạn.

7. Làm thế nào để xử lý bản địa hóa hình ảnh DITA và hrefs?

Khi bạn tải lên dự án DITA của mình một cách nguyên bản, hệ thống sẽ nhận ra các thẻ hình ảnh và liên kết. Bạn có thể chỉ định xem bạn muốn các đường dẫn đến những hình ảnh này được cập nhật thành các thư mục bản địa hóa (ví dụ: thay đổi đường dẫn từ /images/en/ sang /images/es/) hoặc giữ nguyên chính xác như chúng. Điều này đảm bảo các liên kết của bạn không bao giờ bị hỏng trong phiên bản dịch.

Dừng chuyển đổi và bắt đầu đồng bộ hóa với MotaWord

Nếu quy trình dịch thuật hiện tại của bạn giống như một rào cản thủ công ngăn chặn đà của bạn, có thể đã đến lúc chuyển đổi XLIFF sang quy trình làm việc DITA gốc. Bằng cách loại bỏ các bước thủ công đó, bạn giảm nguy cơ lỗi tài liệu và tăng tốc đáng kể chu kỳ phát hành toàn cầu của bạn.

Chuyên môn của bạn nên được dành cho việc tạo nội dung tuyệt vời, không quản lý xuất tệp. Bạn đã sẵn sàng để xem bạn có thể tiết kiệm bao nhiêu thời gian và công sức cho dự án tiếp theo của mình? Bạn có thể nhận báo giá ngay tại MotaWord bằng cách tải lên các tệp.dita của bạn ngay hôm nay.

OYTUN TEZ - Giám đốc Công nghệ (CTO) tại MotaWord

Học giả ngành dịch thuật với luận án về dịch máy -- một chuyên gia công nghệ toàn diện và say mê các quy trình dịch thuật thông minh, liền mạch.