XLIFF 변환 없이 DITA 파일을 번역하는 방법

수동으로 XLIFF를 변환해야 하는 번거로움 없이 DITA 파일을 번역할 방법을 찾고 계신가요? 그렇다면 올바른 위치에 있습니다. DITA (Darwin Information Typing Architecture) 는 이미 효율성과 콘텐츠 재사용의 표준으로 자리 잡았지만, 많은 기술 콘텐츠 팀은 여전히 좌절감을 안고 있습니다. 바로 XLIFF 변환 루프입니다.

현재 번역 워크플로우에 DITA 파일을 XLIFF로 내보내고 해당 파일을 에이전시에 보낸 다음 수동으로 다시 시스템으로 가져오는 작업이 포함되는 경우 시간만 낭비하는 것이 아닙니다. 힘들게 만든 문서의 무결성 자체를 위험에 빠뜨릴 수도 있습니다.

이 기사에서는 수동 변환의 기술적 문제, 델타 관리에 드는 숨겨진 비용, 기본 DITA 지원이 현대 문서 팀의 판도를 바꾸는 이유에 대해 설명합니다. 이 문서를 모두 읽고 나면 DITA 번역 워크플로를 최적화하여 더 빠르고 안정적이며 훨씬 더 비용 효율적인 프로세스로 이동할 준비가 된 것입니다. 그럼 바로 본론으로 들어가 볼까요!

기술 문서에 대한 XLIFF 세금

XLIFF (XML 로컬라이제이션 교환 파일 형식) 는 여러 측면에서 훌륭한 표준이지만 DITA 사용자에게는 단순화하기보다 복잡하게 만드는 중개자 역할을 하는 경우가 많습니다. 이를 종종 XLIFF 세금이라고 합니다. 형식이 제대로 작동하는 데 필요한 시간, 비용 및 육체 노동의 숨겨진 비용입니다. 이러한 수동 전환 프로세스가 생각보다 팀에 더 많은 비용을 초래할 수 있는 이유는 다음과 같습니다.

1. 콘텐츠 재사용 분석: 컨퍼런스 및 Keyrefs

DITA의 진정한 장점은 여러 주제의 콘텐츠를 참조할 수 있다는 것입니다. DITA 파일을 XLIFF로 변환할 때 이러한 복잡한 관계가 평면화되거나 완전히 깨지는 경우가 많습니다. 표준 XLIFF 파일에서 내용 참조 (conref) 는 단순히 정적 텍스트 문자열로 나타날 수 있습니다.

이로 인해 심각한 재정 문제가 발생합니다. 변환 도구에서 동일한 경고 노트 또는 안전 절차를 재사용 가능한 단일 개체로 인식하지 못해 비용을 여러 번 지불해야 할 수도 있습니다. 설상가상으로, 해당 텍스트를 다시 가져오면 하드 코딩된 텍스트가 글로벌 콘텐츠 참조를 덮어쓰게 되어 모듈식 아키텍처가 사실상 파괴되고 향후 업데이트에 문제가 생길 수 있습니다.

2.태그 손상 및 검증 오류

DITA 파일은 엄격한 DTD (문서 유형 정의) 또는 XML 스키마에 의해 관리됩니다. 콘텐츠가.dita 형식에서.xliff 형식으로 이동하고 다시 그 반대로 이동할 때마다 우리가 태그 수프라고 부르는 것을 만들 위험이 있습니다.

DITA 구조에 익숙하지 않은 번역자 한 명만 있으면 실수로 필수 속성을 삭제하거나 닫는 태그를 잘못 배치할 수 있습니다. 왕복 중에 누락된 괄호 하나나 잘못된 속성이 있으면 전체 DITA-OT 빌드가 손상될 수 있습니다. 우리 모두 경험해 본 적이 있습니다. 금요일 오후인데 릴리스를 푸시하려고 하는데 지원 엔지니어가 수천 줄의 코드를 샅샅이 뒤져 단일 검증 오류를 찾아내고 있습니다.

3. 델타 매니지먼트 나이트메어

수동 XLIFF 워크플로는 작성자가 크리에이터를 그만두고 파일 관리자로 나서도록 강요하는 경우가 많습니다. 번역 비용을 절약하기 위해 작성자는 종종 델타 (마지막 업데이트 이후 변경된 파일만) 를 수동으로 식별하려고 합니다. 이 과정은 다음과 같은 세 가지 이유로 매우 어려운 것으로 악명이 높습니다.

• 오류가 발생하기 쉽습니다. 업데이트된 주제 하나만 누락하면 문서가 동기화되지 않아 고객에게 혼란을 줄 수 있습니다.
• 엄밀히 따지자면 팀원들이 새롭고 유용한 콘텐츠를 작성하는 대신 버전을 비교하는 데 몇 시간을 소비하게 됩니다.
• 컨텍스트가 부족합니다. 한 주제의 작은 변경이 관련 주제의 의미에 영향을 미치는 경우 수동 델타 선택으로는 이를 놓칠 수 있습니다.

태그를 넘어서: 속성 보호의 중요성

DITA와 XLIFF 간의 문제에서 가장 간과되는 부분 중 하나는 XML 속성 관리입니다. DITA는 프로파일링 및 필터링을 위해 제품, 플랫폼, 대상 등의 속성에 크게 의존합니다. 이러한 도구를 사용하면 동일한 출처에서 다양한 버전의 설명서를 게시할 수 있습니다.

기본 DITA 워크플로를 사용하는 경우 이러한 속성은 기본적으로 보호됩니다. MotaWord에서 우리 시스템은 제품 속성이 절대 번역되어서는 안 되는 메타데이터라는 것을 인식합니다. 표준 XLIFF 변환에서는 이러한 속성이 제거되거나 (이로 인해 조건부 게시가 중단됨) 번역자에게 노출되는 경우가 많습니다. 번역자가 pro_version을 보고 이를 스페인어로 version_professional로 번역하면 조건부 처리 로직이 더 이상 작동하지 않습니다.

번역=아니오가 생명의 은인인 이유

translate="no” 속성은 코드 스니펫, 명령줄 지침 또는 특정 브랜드 이름을 모든 언어에서 일관되게 유지해야 하는 기술 문서 작성자에게 필수적인 도구입니다. 네이티브 DITA 파서는 엔진 레벨에서 이 속성을 준수합니다. 수동 XLIFF 변환에서는 XLIFF 파일을 만드는 데 사용되는 필터가 이러한 지침을 무시하는 경우가 많기 때문에 과다 번역된 내용을 수정하기 위해 비용이 많이 들고 번거로운 사후 편집 주기가 필요합니다.

문맥의 차이: 번역가들이 XLIFF에 어려움을 겪는 이유

번역은 단순히 단어를 바꾸는 것이 아니라 문맥을 이해하는 것에 관한 것입니다. DITA 주제를 플랫 XLIFF 파일로 변환할 때 변환기는 종종 분리된 문자열 목록을 보게 됩니다. 프로젝트에 구조를 제공하는 맵 뷰가 손실됩니다. 사용자는 특정 제목이 더 큰 작업의 특정 섹션에 속한다는 것을 알 수 없습니다.

네이티브 DITA 번역을 사용하면 번역자는 DITA 계층 구조를 실제로 이해하는 시스템 내에서 작업합니다. 이는 문서 품질에 여러 가지 이점을 제공합니다.

• 더 명확합니다. 번역가는 단어가 단계인지, 결과인지, 전제 조건인지 알 수 있습니다.
• 일관된 용어를 보장합니다. 시스템은 짧은 설명에 사용된 용어가 주제 본문의 동일한 용어와 일치하는지 확인합니다.
• 시각적 무결성을 유지합니다. 정보의 논리적 흐름은 그대로 유지되며, 이는 하드웨어 또는 소프트웨어에 대한 복잡한 기술 매뉴얼을 작성할 때 특히 중요합니다.

더 좋은 방법: 모타워드를 사용한 네이티브 DITA 번역

테크니컬 라이터는 파일 형식을 다루지 않고 콘텐츠에 집중할 수 있어야 한다고 생각합니다. 이것이 바로 우리가 네이티브 접근 방식을 통해 XLIFF 중개인을 제거하기 위해 노력한 이유입니다.

워크플로우 비교

매뉴얼 XLIFF 워크플로우

• 파일을 내보내고 필터링하는 데 몇 시간이 걸립니다.
• 컨텐트 참조를 병합할 위험이 높습니다.
• 메타데이터가 손상되거나 실수로 번역되는 경우가 종종 있습니다.
• 파일을 가져온 후에는 광범위한 수동 QA가 필요합니다.
• 수작업 및 중복 문자열로 인해 숨겨진 비용이 발생했습니다.

모타워드를 사용한 네이티브 DITA 워크플로우

• 파일을 직접 업로드하는 데 몇 분이 걸립니다.
• conref 무결성을 100% 보호합니다.
• 메타데이터를 자동으로 잠그거나 무시하므로 안전하게 유지됩니다.
• 다운로드와 동시에 바로 빌드할 수 있는 파일을 제공합니다.
• 번역 메모리를 사용하여 새 콘텐츠에 대해서만 비용을 지불하도록 합니다.

원시 .dita 및.ditamap 파일 업로드

복잡한 내보내기 대신 원시 DITA 파일이나 전체 Ditamap 프로젝트를 간단히 업로드할 수 있습니다. 저희 플랫폼은 기본적으로 DITA 구조를 파싱하도록 만들어졌습니다. 제목, 본문, 짧은 설명 간의 차이를 이해하므로 메타데이터는 그대로 유지하고 구조는 탄탄하게 유지됩니다.

수동 비교 대신 자동화

MotaWord는 통합 번역 메모리를 사용하기 때문에 더 이상 어떤 파일이 변경되었는지 알아내는 데 시간을 허비할 필요가 없습니다. 전체 프로젝트를 업로드하고 시스템에서 무거운 작업을 수행하도록 할 수 있습니다.

• 저희 시스템은 전체 Ditamap을 이전 번역과 비교합니다.
• 새 문자열이나 수정된 문자열을 몇 초 만에 식별합니다.
• 새 단어에 대해서만 비용을 지불하면 되므로 번거로운 수작업 없이 델타항공의 비용 혜택을 누릴 수 있습니다.

바로 빌드할 수 있는 문서의 경제성

XLIFF 변환의 실제 숨겨진 비용은 최종 게시 주기에서 찾을 수 있습니다. 수동 워크플로우에서는 번역된 파일을 받는 것이 중간 단계에 불과합니다. 여전히 모든 것을 CCMS (컴포넌트 컨텐트 관리 시스템) 로 다시 가져오고, DITA Open Toolkit을 사용하여 테스트 빌드를 실행하고, 불가피한 XML 오류를 디버깅해야 합니다.

이 로컬라이제이션 QA 단계는 작성자의 시간이 며칠 또는 몇 주가 걸릴 수 있습니다. 기본 DITA 지원을 통해 다운로드한 파일을 바로 사용할 수 있습니다. XLIFF 컨테이너에 맞도록 구조물을 분해한 적이 없기 때문에 다시 만들 필요가 없습니다. 단 몇 번의 클릭만으로 완료된 번역에서 게시된 PDF 또는 HTML 사이트로 이동할 수 있습니다.

자주 묻는 질문

1. Conref를 깨지 않고 DITA 파일을 번역하는 방법은 무엇입니까?

MotaWord와 같은 네이티브 DITA 번역 플랫폼은 파일을 원본 XML 구조로 처리합니다. XLIFF로의 변환을 방지함으로써 시스템은 내용 참조 (conrefs) 및 키 참조 (keyrefs) 에 대한 포인터를 유지합니다. 이렇게 하면 번역된 텍스트에 하드코딩하지 않고도 재사용 가능한 객체를 올바르게 처리할 수 있습니다.

2. 소규모 팀에 가장 적합한 DITA 번역 워크플로우는 무엇인가요?

소규모 팀을 위한 가장 효율적인 워크플로는 Direct to DITA 접근 방식입니다. 소규모 팀은 값비싼 미들웨어에 투자하거나 수동 XLIFF 내보내기에 시간을 소비하는 대신, .dita 및 .ditamap 파일을 직접 받아들이는 플랫폼을 사용해야 합니다. 따라서 기술 오버헤드가 줄어들고 전담 로컬라이제이션 엔지니어가 필요하지 않습니다.

3.모타워드는 특수 DITA DTD를 지원하나요?

예. DITA는 특수화 (사용자 정의 요소 유형 생성) 를 허용하므로 기본 파서는 기본 XML 스키마를 존중하도록 설계되었습니다. 사용자 지정 태그와 속성은 보호되며 번역 가능한 콘텐츠를 포함하지 않는 한 단어 수에서 제외됩니다.

4.번역에 대한 DITA와 XLIFF: 어느 것이 더 낫습니까?

XLIFF는 일반 소프트웨어 문자열을 위한 훌륭한 교환 형식이지만, DITA는 콘텐츠 재사용에 관한 더 많은 컨텍스트를 포함하므로 구조화된 문서에 적합합니다. DITA를 기본적으로 번역하면 서로 다른 두 파일 형식 간에 변환할 때 흔히 발생하는 왕복 오류를 방지할 수 있으므로 거의 항상 더 좋습니다.

5.기존 CCMS에 네이티브 DITA 번역을 사용할 수 있나요?

전적으로. IXIASOFT, Heretto 또는 Oxygen Content Fusion과 같은 대부분의 구성 요소 콘텐츠 관리 시스템에서는 원시 DITA 패키지를 내보낼 수 있습니다. 이러한 패키지를 MotaWord에 직접 업로드한 다음 중간 변환 단계 없이 번역된 결과를 CCMS에 다시 업로드할 수 있습니다.

6. 번역 메모리를 사용하여 DITA 번역 비용을 줄이는 방법은 무엇입니까?

전체 Ditamap을 네이티브 플랫폼에 업로드하면 시스템에서 번역 메모리 (TM) 를 사용하여 이전 프로젝트와 정확히 일치하는 항목을 식별합니다. 새 텍스트나 수정된 텍스트에 대해서만 요금이 청구되므로 장기 기술 문서 프로젝트의 비용이 크게 절감됩니다.

7. DITA 이미지 로컬라이제이션 및 href를 처리하는 방법은 무엇입니까?

기본적으로 DITA 프로젝트를 업로드하면 시스템에서 이미지 및 링크 태그를 인식합니다. 이러한 이미지의 경로를 현지화된 폴더로 업데이트할지 (예: 경로를 /images/en/에서 /images/es/로 변경) 아니면 그대로 유지할지 지정할 수 있습니다. 이렇게 하면 번역된 버전에서 링크가 깨지지 않습니다.

변환 중지 및 MotaWord와 동기화 시작

현재 번역 워크플로가 추진력을 멈추는 수동 장애물처럼 느껴진다면 XLIFF 변환에서 벗어나 네이티브 DITA 워크플로로 전환해야 할 때입니다. 이러한 수동 단계를 제거하면 문서 오류의 위험을 줄이고 글로벌 릴리스 주기를 크게 단축할 수 있습니다.

전문 지식은 파일 내보내기를 관리하는 것이 아니라 훌륭한 콘텐츠를 만드는 데 투자해야 합니다. 다음 프로젝트에서 얼마나 많은 시간과 노력을 절약할 수 있는지 확인해 볼 준비가 되셨나요? 오늘.dita 파일을 업로드하면 MotaWord에서 즉시 견적을 받을 수 있습니다.

오이툰 테즈 - 모타워드 최고기술책임자(CTO)

기계 번역에 관한 논문을 쓴 번역학 전공자이자, 전반적으로 기술에 관심이 많으며 스마트하고 매끄러운 번역 흐름에 몰두하고 있습니다.