Trados 패키지는 SDL 사용자에게는 반쪽짜리 해결책이고, 다른 사람들에게는 골칫거리입니다. 하지만 이를 통해 Smartcat 프로젝트를 생성할 수 있습니다.
Trados 패키지란 무엇인가요?
예를 들어, 여러분이 번역 대행사의 프로젝트 매니저라고 가정해 보겠습니다. 단골 고객이 주문을 보냅니다. 문제는: 모든 문서와 리소스(번역 메모리, 용어 데이터베이스 등)를 번역가에게 어떻게 전달할 것인가?
Smartcat이 여러분의 첫 CAT 도구였다면, 이 문제를 이해하기 어려울 것입니다. 여기서는 단순히 고객사 이름을 포함한 프로젝트를 생성하기만 하면 됩니다. 플랫폼이 해당 프로젝트에 필요한 모든 고객사별 리소스를 자동으로 활성화합니다. 번역가에게 작업을 할당하면, 번역가는 필요한 모든 데이터를 즉시 받게 됩니다. 따라서 추가 시간 소모 없이 바로 번역을 시작할 수 있습니다.
따라서 그들은 시간 여유 없이 즉시 번역을 시작할 수 있습니다.
하지만 데스크톱 CAT 시스템을 사용하는 사람에게는 이는 상당한 도전 과제입니다. 번역 메모리와 용어 데이터베이스는 시간이 지남에 따라 방대해집니다. 프로젝트는 종종 클라이언트가 여러 언어로 원하는 다수의 문서로 구성됩니다. 이상적으로는 마감일과 단어 수와 같은 프로젝트 세부 사항도 자동화된 방식으로 보고하고 싶을 것입니다. 이러한 모든 파일을 개별적으로(또는 단순한 압축 파일로) 보내는 것은 번거로울 수 있습니다. 게다가 보낼 파일을 선택하고 결합할 때 인적 오류가 발생할 가능성도 있습니다.
바로 이때 패키지가 "구원"이 됩니다. 예를 들어 Trados 패키지에는 다음과 같은 정보가 포함됩니다:
이중 언어 프로젝트 파일
번역 메모리
용어 데이터베이스
단어 수, 마감일, 주석
기타 Trados 전용 프로젝트 설정
기존 프로젝트에서 몇 가지 간단한 단계로 Trados 패키지를 생성할 수 있습니다:
이렇게 하면 번역가에게 보낼 수 있는 완전한 단위를 얻을 수 있습니다. 번역가가 Trados를 설치한 경우, 자신의 컴퓨터에서 파일을 열고 작업을 시작할 수 있습니다. 작업을 완료한 후에는 귀하에게 다시 보낼 "반환 패키지"를 준비해야 합니다.
Trados 패키지가 왜 문제가 되는가?
패키지는 Trados에서 작업하는 프로젝트 관리자의 업무를 다소 간소화합니다. 해당 업무를 수행 중이라면 언젠가는 패키지로 전환하고 싶을 것입니다. 그리고 모든 번역가들도 동일하게 하길 원하게 될 것입니다. 하지만 모든 번역가가 Trados를 사용하거나 사용하기를 원하는 것은 아닙니다. 단순히 SDLXLIFF 파일을 발송했을 때는 번역가들이 원하는 다른 CAT 도구로 파일을 가져올 수 있는 선택권이 있었습니다. 이제 이 선택권은 사라집니다. 번역가 풀을 제한하거나, 예전 방식으로 되돌아가야 할 것입니다.
프리랜서이거나 트라도스 사용을 원치 않는 회사인 경우에도 마찬가지입니다. CAT 도구 라이선스에 막대한 비용을 지출할 수 있거나 그럴 의사가 없는 사람이라면, 어쩔 수 없이 그 일을 그런 조건을 갖춘 사람에게 넘겨야 할 것입니다.
결국 패키지 자체는 반쪽짜리 해결책에 불과합니다. 본질적으로 프로젝트 관련 파일 전체를 포함하는 ZIP 아카이브의 이름만 바꾼 것에 지나지 않습니다. 어떤 면에서는 근본적으로 더 나은 점을 도입하지 않은 채 복잡성만 한 단계 더 추가하는 셈입니다.
왜 모두가 Trados 패키지를 지원하지 못할까?
이제 여러분은 이렇게 물을 수 있습니다. 왜 모든 CAT 도구가 Trados 패키지를 지원하지 못하는 걸까요? 이미 SDLXLIFF 파일을 가져올 수 있으니, 몇 가지 수정만 하면 되지 않을까요? 게다가 앞서 말했듯이 Trados 패키지는 단순한 ZIP 압축 파일에 불과한데 말입니다.
그렇습니다. 그런 아카이브는 다음과 같습니다:
먼저, 내부 파일 중 프로젝트 설명 XML이나 TM 테이블 같은 일부 파일에는 명시된 규격이 없습니다. (그 이유가 무엇인지는 별개의 문제이며, 후술하겠습니다.) Smartcat에서는 이들의 구조를 분석하고 이해하는 데 거의 백 시간을 투자했습니다.
둘째, 패키지 내 모든 파일을 읽어 시스템으로 가져와 번역을 완료했다고 가정해 보겠습니다. 이 모든 작업은 Trados가 출력으로 기대하는 "반환 패키지"로 다시 변환하지 못한다면 헛수고가 될 것입니다. 결국 고객이 기다리는 것은 Trados 패키지이기 때문입니다.
결국, 리턴 패키지를 생성했다 하더라도 Trados가 이를 읽을 것이라는 보장은 전혀 없습니다. 따라서 통합을 테스트하고 제대로 작동하도록 만드는 데 정말, 정말 많은 시행착오가 필요합니다.
Smartcat은 Trados 패키지를 정확히 어떻게 지원하나요?
우리는 새로운 기능이 기존 사용자 경험과 원활하게 통합되도록 많은 노력을 기울입니다. Trados 패키지도 마찬가지입니다. 사용자는 패키지를 업로드할 때 특별한 점을 전혀 눈치채지 못할 수도 있습니다. Smartcat은 패키지를 자동으로 구성 요소로 분할하고, 다른 프로젝트와 마찬가지로 파일 및 번역 메모리 목록을 표시합니다:
한 가지 차이점은 프로젝트 내 파일 집합을 변경할 수 없다는 점입니다(당연히). 마법사를 통해 개별 파일의 기본 설정을 사용자 지정할 수도 있습니다. 예를 들어, Smartcat이 파일을 어떻게 분할해야 하는지 지시할 수 있습니다:
기존 번역물 처리:
그리고 교차하는 태그와 자리 표시자를 처리합니다:
두 번째 화면에서는 패키지에서 가져온 마감일과 코멘트를 확인하고 수정할 수 있습니다. 또한 언어 쌍을 볼 수 있지만(수정할 수는 없습니다):
물론, Smartcat에서 익숙하게 사용하던 다른 모든 설정도 구성할 수 있습니다. 결국에는 일반적인 Smartcat 프로젝트와 거의 다를 바 없는 프로젝트를 얻게 됩니다:
프로젝트 설정
문서
번역 메모리
고객은 그 차이를 전혀 눈치채지 못할 것입니다. (물론 구식 도구를 아예 사용하지 않도록 설득하는 것이 모두에게 최선이지만요.)
