2000년 12월 15일
용어 관리는 번역 도구의 문제가 아닙니다. 이는 세계화 기반 시설의 일부이며, 올바르게 만드는 것이 가장 저렴하고 개조하는 데 가장 비용이 많이 듭니다.
텀베이스 프로젝트를 망치는 방법은 첫날부터 제품 설명서의 모든 단어를 수집하고 중간에 지쳐서 포기하는 것입니다. 효과적인 순서는 잘못 번역하는 비용에 따라 결정됩니다. 제품 이름, 안전 용어, 기능 이름 및 규정 표현은 잘못된 번역으로 인해 실제 피해가 발생하는 범주이므로 먼저 그렇게 하세요. 일반적인 설명 어휘는 기다리거나 완전히 건너뛸 수 있습니다.
첫 번째 텀베이스는 클 필요가 없습니다. 수백 개의 항목이면 충분합니다. 중요한 것은 번역 프로세스, 리뷰 체크리스트, 제품 문서 등에서 실제로 사용된다는 것입니다. 모두가 따르는 200개 항목의 텀베이스는 아무도 읽지 않는 2000개 항목의 텀베이스보다 훨씬 더 가치가 있습니다.
순위는 단어 빈도가 아니라 비즈니스 영향을 따릅니다. 하루에 10번 등장하는 보통명사보다 오역으로 인해 안전사고가 발생하는 희귀한 용어가 등장한다.
텀베이스가 존재한 후 가장 일반적인 문제는 그것이 공유 드라이브에 있고 번역가가 이에 대해 모르거나 알고도 참조하지 않는다는 것입니다. 그러면 도구가 아닌 문서가 됩니다. 효과적인 접근 방식은 이를 CAT 도구와 MTPE 프로세스에 연결하여 번역자가 작업 인터페이스에서 승인된 용어를 볼 수 있도록 하는 것입니다.
프로세스가 진행되면 용어 확인을 자동화할 수 있습니다. 대부분의 CAT 도구 및 QA 도구는 용어 일관성 검사를 지원하며 번역에서 비표준 렌더링을 사용하는 경우 플래그를 지정할 수 있습니다. 이 단일 단계는 용어 준수를 좋은 의도에서 확인된 프로세스로 이동시킵니다.
또 다른 계층인 온보딩(onboarding)이 간과되는 경우가 많습니다. 번역가가 프로젝트를 처음 접할 때 텀베이스는 가능한 가장 좋은 브리핑입니다. 즉, 제품 이름, 기능 이름 지정 방법, 즉석에서 만들어서는 안되는 단어를 알려줍니다. 첫 번째 할당 전에 텀베이스를 살펴보는 것은 나중에 수정하는 것보다 더 많은 비용을 절약합니다.
텀베이스는 구축을 완료한 자산이 아닙니다. 유지 관리가 필요하고 유지 관리에는 소유자가 필요합니다. 누군가(한 사람 또는 소그룹)가 용어 변경 시기, 승인자, 변경 사항이 영향을 받는 모든 사람에게 전달되는 방법을 결정합니다. 그러한 배열이 없으면 텀베이스가 쇠퇴합니다. 번역가는 추측으로 돌아가고 내용은 조용히 낡아집니다.
일반적인 구조는 용어 소유자와 제품, 마케팅 및 번역에서 가져온 검토 패널로 구성됩니다. 새로운 용어나 변경 사항은 제출, 검토, 승인, 기본 입력, 통지 등 고정된 경로를 따릅니다. 경로는 정교할 필요는 없지만 반드시 존재하고 기록되어야 합니다.
용어 변경에 대한 버전 기록도 같은 이유로 중요합니다. 용어는 고정되어 있지 않습니다. 제품은 진화하고 시장은 움직이며 작년의 표준 렌더링이 올해 더 이상 정확하지 않을 수 있지만 변경 사항은 추적 가능해야 합니다. 문제는 조직적입니다. 제품을 변경하는 팀과 문서를 관리하는 팀이 동일한 사람이 아닌 경우가 많습니다. 변경 사항이 자동으로 전파되려면 일부 메커니즘이 필요합니다. 수동으로 감시하는 것은 유지되지 않습니다.
가장 많이 사용되는 용어를 분기별로 검토하고 더 이상 적용되지 않는 항목을 폐기합니다. 단종된 모델의 이름, 이름이 변경된 기능, 규제 변경으로 인해 더 이상 사용되지 않는 공식 등 이 모든 것이 기본에서 나와야 합니다. 번역가가 그것이 여전히 유효하다고 가정하기 때문에 이를 남겨두면 편의성이 절약되는 것보다 더 많은 비용이 듭니다.
리뷰에는 숨겨진 두 번째 이점이 있습니다. 용어 시스템의 공백이 표면화되는 순간입니다. 아무도 사용하지 않는 항목은 해당 기능이 번역되지 않거나 번역자가 해당 용어가 존재하는지 모른다는 의미일 수 있습니다. 이러한 신호는 주기적으로 데이터를 보면 나옵니다.
용어 관리는 도구가 아닌 인프라에 달려 있습니다. 기초를 제대로 갖추면 모든 추가 언어는 양의 문제입니다. 이를 건너뛰면 모든 추가 언어에서 드리프트가 다시 누적됩니다. FangService 용어 관리를 다국어 프로젝트의 프런트엔드 단계로 간주합니다. 즉, 제품 자료를 가져오고 첫 번째 용어 배치부터 시작합니다.
한 고객은 해외 인증 중에 동일한 구성 요소가 3세대 제품 설명서에 걸쳐 3가지 이름(초기에는 방열판, 이후에는 냉각 모듈, 최신 버전에서는 열 관리 장치)이 있다는 사실을 발견했습니다. 인증 기관은 이것이 세 가지 다른 부분일 수 있다고 결론을 내리고 설명을 요청했는데, 이 과정에는 한 달이 걸렸습니다. 초기 용어집이 단순히 유지되었다면 그러한 설명은 결코 필요하지 않았을 것입니다. 용어 관리로 절약되는 것은 번역 비용이 아닌 경우입니다. 재작업, 설명 및 인증 지연입니다.
용어집을 유지 관리하는 현실적인 접근 방식은 세 단계로 구성됩니다. 먼저 제품 정의, 매개변수 이름, 인증 용어, 브랜드 이름 등 필수 항목만 수집하세요. 둘째, 두 가지 실패 모드를 포착합니다. 여러 번역이 포함된 용어 하나와 여러 소스 용어가 포함된 번역 하나는 불만 사항과 재작업을 생성하기 때문입니다. 셋째, 소유자와 검토 주기를 지정하여 제품 세대 변경으로 인해 용어 검토가 시작되도록 합니다. FangService 금지된 번역 및 적용 가능한 컨텍스트에 대해 주석이 달린 각 항목으로 이중 언어 용어 기반을 구축하고, 용어집을 프로젝트 버전에 연결하고, 모델 번호 및 브랜드 이름과 같은 번역할 수 없는 항목을 건너뛰도록 번역 파이프라인을 구성하여 기계 번역으로 다시 작성되지 않도록 합니다.
용어 관리는 시스템 프로젝트로 쉽게 설명되므로 결코 시작되지 않습니다. 실제로 처음 3개월 동안 세 가지 조치를 취하면 결과를 확인할 수 있습니다. 제품 정의 및 매개변수 이름을 제품 라인별로 강제 적용합니다. 이미 불만 사항이나 재작업을 야기한 렌더링을 표시하는 번역 금지 목록을 작성합니다. 번역 파이프라인에 용어 사전 확인을 추가하여 발송 전에 빈도가 높은 용어를 선별합니다.
세 가지 중 어느 것도 큰 투자가 필요하지 않으며 여러 이름을 가진 하나의 제품으로 인해 발생하는 설명 및 재작업과 이미 잘못된 것으로 알려진 렌더링이 다시 나타나는 두 가지 유형의 문제를 즉시 줄입니다. 다른 곳에서 복사한 일반적인 목록이 아니라 실제 제품을 반영한다면 30개의 용어로 시작하는 용어집이 완벽하게 적합합니다.
FangService 제품 자체에서 클라이언트 용어 기반을 구축합니다. 빈도가 높은 필수 용어를 먼저 만들고, 컨텍스트 및 금지된 렌더링으로 주석을 달고, 프로젝트 버전에 바인딩하고, 번역 파이프라인에서 사전 확인으로 실행합니다. 용어 관리는 효과가 나타나기 시작한 후에만 시스템이라고 부를 수 있는 권리를 얻습니다.