소프트웨어 현지화에는 다음과 같은 단계가 포함됩니다:
- 번역을 위한 코드 준비
- 소프트웨어 문자열 내보내기
- 구문 분석 및 세분화 전략 세부 조정
- 주요 용어 목록 (용어집) 개발
- 소프트웨어 번역 프로젝트 생성
- 번역자 할당
- 리뷰어에게 할당
- 쿼리 관리
- 자동 품질 점검
- 번역된 문자열 재가져오기
- 스테이징 환경에서의 QA 체크 또는 스크린샷의 QA 체크
- 테스트
이 문서에서는 이러한 다양한 구성 요소와 전체 지역화 프로세스에 대한 영향을 탐색할 것입니다.
번역을 위한 코드 준비
일부 소프트웨어는 번역을 고려하여 작성되지만, 번역은 종종 소프트웨어가 이미 성숙한 상태일 때 요구 사항으로 나타납니다. 번역을 위해 코드를 준비하기 위해서는 변수, 날짜 및 번역 가능한 콘텐츠와 코드의 전체 아키텍처에 대해 자세히 살펴봐야 합니다. 날짜, 통화 및 기타 요소는 지역에 따라 형식이 변경됩니다. 하드 코딩된 경우 국제 문화적 유연성을 위해 동적 개체로 다시 코드화해야 합니다. 코드가 작성된 방식에 따라 코드를 번역 가능한 텍스트로부터 분리하는 것이 매우 쉬울 수도 있고 어려울 수도 있습니다. 이것은 문자열 내보내기의 다음 단계에 영향을 미칠 것이지만, 아마도 소프트웨어 현지화의 가장 간과되고 과소평가된 측면일 것입니다. 코드가 작성된 방식에 따라 코드를 번역 가능한 텍스트로부터 분리하는 것이 매우 쉬울 수도 있고 어려울 수도 있습니다. 이는 문자열을 내보내는 다음 단계에 영향을 미칠 것이지만, 아마도 소프트웨어 지역화의 가장 간과되고 과소평가된 측면일 것입니다. 코드 대 텍스트의 단순성에 대한 각각의 작은 변화는 전체 지역화 과정에 영향을 미칠 수 있는 무수한 파급 효과를 초래할 것입니다. 이는 코드의 무결성을 보존하거나 번역가들이 쉽게 작업할 수 있도록 만드는 것이 어려운 상황을 초래할 수 있습니다. 이로 인해 코드의 무결성을 보존하거나 번역가들이 사용하기 쉽게 만드는 것이 어려운 상황이 발생할 수 있습니다. 확실하게, 일부 도전 과제를 구문 분석 및 세분화 전략을 통해 극복할 수 있지만, 코드의 간섭 없이 번역 가능한 콘텐츠를 깔끔하게 내보낼수록 소프트웨어 현지화 프로세스는 더욱 효율적이고 확장 가능해질 것입니다.
소프트웨어 문자열 내보내기
문자열 내보내기는 간단한 과정이어야 합니다. 하지만 그렇지 않습니다. 일부 형식은 기본적으로 사용되지만 다른 형식은 피해야 합니다. 사용하기 좋은 형식의 예시: XML, YAML, JSON. go-to 형식의 예시: XML, YAML, JSON. 이들은 구조화되어 있으며 예측 가능하며 쉽게 구문 분석할 수 있으며 코드 내에서 패턴을 찾기 쉽기 때문에 다른 언어로 번역하는 데 문제가 줄어듭니다. 피해야 할 형식의 예시: TXT, CSV, 혼합 코드. TXT, CSV, 혼합 코드. 예를 들어 CSV 내보내기는 악몽이 될 수 있습니다. 세미콜론과 같은 구분 문자는 언어 도구로서 필요합니다. 코드 중단을 의미하는 세미콜론과 언어 도구로서의 세미콜론을 알고리즘적으로 구별하는 것은 사실상 불가능합니다. 구분 문자(예: 세미콜론)는 언어 도구로서 필요합니다. 코드 중단을 의미하는 세미콜론과 언어 도구로서의 세미콜론을 알고리즘적으로 구분하는 것은 거의 불가능합니다. 이로 인해 수백 개의 잘못된 양성 결과가 발생하며, 품질 보증 과정에서 확인해야 할 문제와 코드 재가져오기 중에 발생하는 문제 등이 있습니다. 예를 들어 XML에 JSON이 포함된 혼합 코드를 언급할 때, 구문 분석 및 분할 과정의 복잡성이 증가합니다. 예를 들어 XML에 JSON이 포함된 혼합 코드를 언급할 때, 구문 분석 및 분할 과정의 복잡성이 증가합니다. 인코딩도 주요한 고통 요소입니다:
- HTML 인코딩
- URL 인코딩
- Unicode 인코딩
- Base64 인코딩
- Hex 인코딩
- ASCII 인코딩
이러한 인코딩 프레임워크는 지역화 프로세스에 영향을 미칠 수 있으며, 포함된 언어에 따라 문자 호환성이 달라질 수 있습니다.
파싱 및 세분화 전략을 세밀하게 조정
위에서 제시한 모범 사례를 따랐다면, 파싱 및 세분화 전략은 프로세스 최적화 도구가 될 것입니다. 만약 그렇지 않다면, 파싱 및 세분화는 프로세스 활성화 도구가 될 것입니다. 프로세스 최적화 도구로서, 세밀하게 조정된 세분화 전략은 번역 관리 시스템에서 번역가와 리뷰어들이 친숙하게 콘텐츠를 수용할 수 있도록 보장합니다. 여기서 변수가 보호되고, 남아있는 코드가 보호되며, 텍스트가 번역 프로세스에 맞게 분할되는지 확인할 수 있습니다. 만약 당신이 숙제를 하지 않았다면, 여기서 일이 엉망이 될 수 있습니다. 코드와 변수를 보호하기에 충분한 파싱을 만들 수 없거나, 소프트웨어를 더 번역 친화적으로 만들기 위해 충분한 정규 표현식을 작성하는 것이 미친 듯한 노력을 필요로 하는 경우에도 마찬가지입니다. 어떤 경우에도, 이것은 중요한 단계입니다. 시간이 지남에 따라 파싱 및 세분화 전략을 변경하면 번역 메모리 활용에 손실이 발생하여 추가 비용과 프로세스 복잡성이 발생할 수 있습니다. 당신의 얼굴에 터지기 전까지는 큰 문제처럼 보이지 않을 수도 있습니다. 예를 들어 소프트웨어 전체가 100,000 단어이고 10 개의 언어로 번역하며 단어당 평균 비용이 $0.15라고 가정해 봅시다. 소프트웨어를 번역했다고 가정하고 이제 파싱 전략을 반복하는데, 이로 인해 10%의 레버리징 손실이 발생할 것입니다 (파싱의 작은 변경으로 예상되는 결과일 수 있음). 이는 게이트에서 바로 15,000달러의 손실을 의미하며, 추가적으로 필요한 시간과 다른 영향도 고려해야 합니다. 키 용어 목록 (용어집)을 개발하는 것은 누구나 할 수 있습니다. 하지만 아주 소수의 사람들만이 훌륭한 용어집을 개발할 수 있습니다. 일부 사람들은 통계적인 방법을 택하고 가장 반복되는 키워드를 콘텐츠 데이터베이스에서 추출합니다. 이 방법은 작업을 빠르게 처리하고 빈도에 따라 중요한 용어를 포착하지만, 몇 가지 핵심 용어는 그렇게 자주 사용되지 않을 수도 있습니다. 일부 사람들은 질적인 접근을 취하고 번역가들이 다량의 콘텐츠를 검토하고 관련 용어를 수동으로 식별하도록 합니다. 다른 사람들은 AI를 사용하여 언어 패턴을 찾고 빈도에만 근거하는 것이 아닌 전반적인 의미적 관련성을 가진 개체와 용어를 식별합니다. 접근 방식에 관계없이, 용어집에 있어서는 적게 하는 것이 좋습니다. 핵심 용어를 포착했는지 확인하려면, 너무 많은 용어를 용어집 용어로 표시하면 적절한 적용을 보장하기가 거의 불가능합니다. 너무 많은 잘못된 양성 결과와 경고는 번역가와 리뷰어가 용어 제안을 관리하고 자동화된 QA 체커를 실행하는 것을 어렵게 만듭니다. 또 다른 팁은 용어 사전에서 특정 유형의 번역이 필요한 용어뿐만 아니라 번역되지 말아야 할 용어도 지정하는 것이 중요합니다.
소프트웨어 번역 프로젝트 생성
이 단계는 사용 중인 번역 관리 시스템의 프레임워크에 크게 의존합니다. 일부 시스템은 동일한 환경과 프로젝트 내에서 전체 프로젝트 수명주기를 관리할 수 있지만 다른 플랫폼은 문자열 또는 파일 기반의 다른 접근 방식이 필요할 수 있습니다. 실제 번역 프로젝트를 설정하는 것은 형식상인 것처럼 보일 수 있지만, 주요 체크포인트가 있습니다:
- 파일이 완전히 수용되었는지 확인
- 언어 쌍이 로케일 수준까지 올바른지 확인
- 날짜가 올바른지 확인
- 필요한 작업 단계를 확인하는 것
- 번역가에게 할당하기
이 단계에서는 이미 언어 쌍별로 사전에 검증된 번역팀을 사용할 수 있다고 가정합니다. 다음과 같은 번역가와 함께 작업하는 것이 중요합니다:
번 번역가에 할당하기
.avif){kind=spacer}
.avif)
.avif)
%2520(1).avif)
