파일 하나로 다섯 가지 형식 출력: WordPress 번역의 미래를 보장하는 방법
WordPress 테마를 스페인어로 번역하는 데 3주가 걸렸습니다. .po 파일은 완벽합니다. 모든 문자열이 검토되었고, 모든 변수가 그대로 유지되었으며, 모든 복수형이 올바릅니다. 그런데 갑자기 고객이 기존 PHP 테마에서 프런트엔드에 React를 사용하는 헤드리스 설정으로 마이그레이션하기로 결정합니다.
그러자 .po 파일이 쓸모없게 됩니다. React 앱에는 .json이 필요합니다. 레거시 PHP 위젯에는 여전히 .mo가 필요합니다. 모바일 앱을 담당하는 프리랜서는 .xliff를 원합니다. 그리고 4,000개의 문자열을 세 가지 다른 형식으로 다시 번역할 시간은 없습니다.
이것은 드문 경우가 아닙니다. 테마가 PHP와 JavaScript 구성 요소와 함께 제공되고, 플러그인이 Gettext와 i18next를 혼합하여 사용하고, 고객이 암호를 바꾸는 것보다 더 자주 아키텍처에 대한 마음을 바꾸는 현대 WordPress 개발의 현실입니다.
번역 파일 형식이 그 어느 때보다 중요한 이유
5년 전에는 WordPress 번역이 간단했습니다. .po 파일(사람이 읽을 수 있는 소스)과 .mo 파일(컴파일된 바이너리)이 있었습니다. 그게 전부였습니다. 모든 테마, 모든 플러그인, 모든 번역 도구가 같은 언어를 사용했습니다.
오늘날 WordPress 생태계는 프로덕션 환경에서 최소 5가지 번역 파일 형식을 사용합니다.
알아야 할 5가지 형식
.po (Portable Object) — GNU Gettext에서 사용하는 사람이 읽을 수 있는 소스 형식입니다. 원본 문자열(msgid)과 해당 번역(msgstr)을 포함합니다. 번역가가 편집하는 파일입니다.
msgid "Add to Cart"
msgstr "Anadir al carrito"
msgid "Your order has been shipped to %s"
msgstr "Su pedido ha sido enviado a %s"
.mo (Machine Object) — .po 파일의 컴파일된 바이너리 버전입니다. WordPress는 런타임에 load_textdomain()을 사용하여 .mo 파일을 읽습니다. 런타임에 .po를 구문 분석하는 것보다 빠르지만 사람이 편집할 수는 없습니다.
.json (JavaScript Object Notation) — Gutenberg 블록, React 구성 요소 및 최신 테마에서 JavaScript 기반 번역을 위해 wp_set_script_translations()에서 사용됩니다. WordPress는 locale_data 키가 있는 특정 JSON 구조를 예상합니다.
{
"locale_data": {
"flavor-starter": {
"Add to Cart": ["Anadir al carrito"],
"Your order has been shipped to %s": ["Su pedido ha sido enviado a %s"]
}
}
}
.php (PHP 배열) — Laravel 스타일의 번역 로딩을 사용하는 테마 및 플러그인에 점점 더 많이 사용되는 형식입니다. 일부 최신 WordPress 테마는 Gettext를 완전히 우회하고 성능을 위해 PHP 배열에서 번역을 로드합니다.
<?php
return [
'Add to Cart' => 'Anadir al carrito',
'Your order has been shipped to %s' => 'Su pedido ha sido enviado a %s',
];
.xliff (XML Localization Interchange File Format) — 다양한 도구와 플랫폼 간의 번역 교환을 위한 업계 표준입니다. memoQ, Trados 및 Memsource와 같은 CAT(Computer-Assisted Translation) 도구에서 사용됩니다. 전문 번역가와 협력할 때 필수적입니다.
<trans-unit id="1">
<source>Add to Cart</source>
<target>Anadir al carrito</target>
</trans-unit>
문제점: 형식 종속
대부분의 번역 도구는 하나의 출력 형식만 생성합니다. Poedit은 .po 및 .mo를 제공합니다. WPML은 번역을 데이터베이스에 저장합니다(파일에는 저장하지 않음). Weglot은 번역을 자체 서버에 독점 형식으로 보관합니다. Crowdin 및 Lokalise와 같은 TMS 플랫폼조차도 각 프로젝트에 대해 내보내기 형식을 수동으로 구성해야 합니다.
이것은 형식 종속을 만듭니다. 즉, 현재 도구가 생성하는 형식에 번역이 갇히게 됩니다. 요구 사항이 변경되면 두 가지 옵션에 직면하게 됩니다.
- 새 형식으로 모든 것을 다시 번역합니다(비용이 많이 들고 시간이 오래 걸리며 수동 수정 사항이 손실됨).
- 사용자 정의 변환 스크립트를 작성합니다(오류가 발생하기 쉽고, 특히 복잡한 복수형 및 변수의 경우).
어느 옵션도 좋지 않습니다. 둘 다 시간과 돈을 낭비합니다. 둘 다 위험을 초래합니다.
형식 종속이 문제가 되는 실제 시나리오
시나리오 1: 테마 현대화. 고객의 테마가 Gutenberg 블록으로 재구축되고 있습니다. 이전 PHP 템플릿은 .mo 파일을 사용했습니다. 새 블록에는 wp_set_script_translations()에 .json이 필요합니다. 전환 중에 3,000개의 번역된 문자열이 두 형식으로 모두 존재해야 합니다.
시나리오 2: 에이전시 워크플로. 20개의 고객 사이트를 관리합니다. 일부는 클래식 테마(.mo)를 사용합니다. 일부는 헤드리스 설정(.json)을 사용합니다. 하나는 PHP 배열을 읽는 사용자 정의 프레임워크를 사용합니다. 서로 다른 고객을 위해 동일한 번역이 다른 형식으로 필요합니다.
시나리오 3: 전문 검토. AI 번역은 95% 정확하지만 원어민이 나머지 5%를 검토하기를 원합니다. 전문 번역가는 .xliff를 가져오는 CAT 도구를 사용합니다. 번역을 .xliff로 내보내고 검토를 위해 보내고 수정 사항을 다시 병합해야 합니다.
시나리오 4: 플랫폼 마이그레이션. 고객이 WordPress에서 사용자 정의 Node.js 애플리케이션으로 이동하고 있습니다. 새 앱은 i18next를 사용하고 .json 파일이 필요합니다. .po 형식의 5,000개의 번역된 문자열을 단일 변수 또는 복수형을 잃지 않고 변환해야 합니다.
솔루션: 한 번 번역하고 모든 형식 얻기
SimplePoTranslate는 다른 접근 방식을 취합니다. .po, .pot, .json 또는 .xliff 파일을 업로드하고 번역을 실행하면 다섯 가지 형식 모두가 포함된 ZIP 파일을 다시 받습니다.
translations-es_ES.zip
├── flavor-starter-es_ES.po
├── flavor-starter-es_ES.mo
├── flavor-starter-es_ES.json
├── flavor-starter-es_ES.php
└── flavor-starter-es_ES.xliff
이것은 엔터프라이즈 티어에 잠겨 있는 "프리미엄 기능"이 아닙니다. 모든 유료 플랜(Pro(월 $19) 및 Lifetime(일회성 $399))에는 모든 번역 작업에 다섯 가지 출력 형식이 모두 포함됩니다.
미래 보장에 중요한 이유
처음부터 다섯 가지 형식을 모두 가지고 있으면 다시 번역할 필요가 없습니다. 번역은 모든 기술 요구 사항에 적응하는 자산입니다.
- 고객이 클래식에서 Gutenberg로 마이그레이션합니까?
.json파일을 배포합니다. - 새로운 개발자가 PHP 배열을 선호합니까?
.php파일을 전달합니다. - 전문 번역가가 검토하기를 원합니까?
.xliff파일을 보냅니다. - 다른 CMS로 이동하시나요?
.json및.xliff파일은 플랫폼에 구애받지 않습니다.
한 번 번역하면 필요할 때 형식을 사용할 수 있습니다.
WordPress에서 각 형식이 작동하는 방식
어떤 파일을 어디에 배치해야 하는지 아는 것은 깔끔한 배포에 필수적입니다.
.mo 파일 배포(클래식 PHP 테마 및 플러그인)
wp-content/languages/plugins/woocommerce-es_ES.mo
wp-content/languages/themes/flavor-starter-es_ES.mo
WordPress는 사이트 언어가 일치하면 자동으로 로드합니다. 플러그인이 필요하지 않습니다. 데이터베이스 오버헤드가 없습니다. 이것은 최고의 성능을 제공하는 접근 방식입니다.
.json 파일 배포(Gutenberg 블록 및 JS 구성 요소)
wp-content/languages/plugins/woocommerce-es_ES-{handle}-{md5}.json
파일 이름에는 스크립트 핸들과 MD5 해시가 포함됩니다. WordPress는 플러그인 또는 테마에서 wp_set_script_translations()를 호출할 때 이러한 항목과 일치시킵니다. Gutenberg 블록을 빌드하는 경우 번역된 블록 레이블과 설명이 올바르게 표시되도록 하는 파일입니다.
.xliff 파일 사용(전문 검토 워크플로)
.xliff 파일은 WordPress에 배포되지 않습니다. 전문 검토자에게 번역을 보내거나 CAT 도구로 가져와야 할 때 교환 형식으로 사용됩니다. 워크플로는 다음과 같습니다.
.po를 SimplePoTranslate에 업로드하고 ZIP에서.xliff를 가져옵니다..xliff를 번역가 또는 검토자에게 보냅니다.- 수정된
.xliff를 다시 받습니다. - 수정된
.xliff를 SimplePoTranslate에 업로드하고 업데이트된.mo및.json을 가져옵니다.
SimplePoTranslate의 구문 잠금이 모든 단계에서 변수와 복수형을 보호하기 때문에 이 왕복 워크플로는 모든 변수와 복수형을 보존합니다.
공급업체 종속 테스트
다음은 현재 번역 워크플로에 종속 문제가 있는지 여부를 확인하는 간단한 테스트입니다.
- 지금 당장 번역을 표준
.po파일로 내보낼 수 있습니까? - 오늘 번역 도구 구독을 취소하면 번역된 모든 문자열을 유지합니까?
- 다시 번역하지 않고 완전히 다른 도구 또는 플랫폼으로 번역을 가져올 수 있습니까?
이러한 질문 중 하나라도 "아니요"라고 답하면 종속됩니다. Weglot 및 GTranslate와 같은 서비스는 세 가지 질문 모두에 실패합니다. 구독을 취소하면 번역이 사라집니다. WPML은 번역을 데이터베이스에 저장하여 내보내기가 가능하지만 어렵습니다. Poedit과 같은 데스크톱 도구조차도 문서상으로는 테스트를 통과하지만 .po 및 .mo로만 제한됩니다.
SimplePoTranslate를 사용하면 세 가지 질문 모두에 대해 "예"라고 답할 수 있습니다. 다섯 가지 형식으로 표준 파일을 다운로드합니다. 그것들은 당신의 것입니다. 내일 계정을 삭제해도 지금까지 만든 모든 번역이 여전히 작동합니다.
형식에 구애받지 않는 번역 라이브러리 구축
여러 프로젝트를 관리하는 에이전시 및 개발자의 경우 가장 현명한 접근 방식은 번역 라이브러리를 구축하는 것입니다. 즉, 모든 고객 프로젝트에 대해 번역된 파일을 저장하는 Git 리포지토리 또는 공유 폴더입니다.
translations/
├── client-acme/
│ ├── es_ES/
│ │ ├── flavor-starter-es_ES.po
│ │ ├── flavor-starter-es_ES.mo
│ │ ├── flavor-starter-es_ES.json
│ │ ├── flavor-starter-es_ES.php
│ │ └── flavor-starter-es_ES.xliff
│ └── de_DE/
│ └── ...
├── client-globex/
│ └── ...
고객에게 새로운 형식이 필요한 경우 이미 가지고 있습니다. 고객이 플랫폼을 변경하는 경우 번역이 아무런 노력 없이 마이그레이션됩니다. 새로운 개발자가 팀에 합류하면 어떤 형식이 번역되었는지 정확히 확인할 수 있습니다.
이것이 "미래 보장"이 실제로 의미하는 바입니다. 즉, 고객이 내년에 어떤 기술을 사용할지 예측하는 것이 아니라 고객이 선택하는 모든 기술에서 번역이 작동하는지 확인하는 것입니다.
파일 형식에 대한 걱정을 멈출 준비가 되셨습니까? SimplePoTranslate를 무료로 사용해 보세요. 파일 하나를 업로드하면 다섯 가지 형식을 다시 받을 수 있습니다. 변환 스크립트, 재번역, 종속이 없습니다.