로컬라이제이션 파일은 메모장이나 텍스트 편집기와 같은 텍스트 편집기 또는 프로그래머가 사용하는 다양한 향상된 텍스트 편집 도구에서 열고 편집할 수 있는 텍스트 파일입니다. 이 파일들은 일반적으로 키-값 원칙을 따릅니다. 즉, 고유한 ID(키)와 연결된 텍스트 조각(문자열)의 목록을 포함합니다. 따라서 각 문자열은 키의 값입니다 (이 간단한 예는 Java 프로그래밍에서 사용되는 로컬라이제이션 파일의 형식입니다.):
-
key1 = value1
-
key2 = value2
-
...
-
keyN = valueN
로컬라이제이션 파일의 생성
로컬라이제이션 파일은 간단한 구조를 가진 일반 텍스트 파일입니다. 수동으로 생성할 수 있지만, 일반적으로 다양한 개발 환경에서 사용할 수 있는 국제화 유틸리티나 스크립트에 의해 자동으로 생성됩니다. 로컬라이제이션 파일의 자동 생성은 파일 구조가 유효하도록 보장합니다.
로컬라이제이션 파일을 생성하기 위해서는 모든 표시 가능한 텍스트 조각이 코드 파일에서 고유한 ID로 대체됩니다. 그런 다음 텍스트 문자열이 해당 ID와 함께 로컬라이제이션 파일에 추가됩니다.
로컬라이제이션 파일의 사용
실제 텍스트 문자열 대신, 코드는 이제 오직 키만 포함합니다. 소프트웨어가 사용자에게 뷰를 생성할 때, 이러한 키는 로컬라이제이션 파일에서 관련 문자열을 조회하는 데 사용됩니다.
응용 프로그램이 영어와 스페인어로 사용되도록 설정된 경우, 모든 영어 텍스트는 English.txt라는 파일에 보관되며 기본 텍스트 위치입니다. 사용자가 언어를 선택하지 않으면, 모든 텍스트는 이 파일에서 가져와서 어떤 표시를 생성합니다. 사용자가 스페인어를 선택하면, 소프트웨어는 Spanish.txt로 리디렉션됩니다. 이러한 시스템에서는 많은 언어를 사용할 수 있습니다.
장점은 디스플레이 언어의 선택이 코드에 영향을 미치지 않는다는 것입니다. 소프트웨어가 로그인 버튼을 표시해야 하는 경우, login_button 키와 관련된 문자열이 필요할 수 있으며, 주어진 언어에 적합한 문자열을 검색하기 위해 어떤 파일을 찾아야 하는지만 알면 됩니다.
문자열 관리
키 기반 번역 플랫폼인 Phrase는 다양한 리소스 파일 유형을 지원합니다. 파일이 업로드된 후, 키와 그에 연결된 문자열 값이 추출됩니다. 키와 문자열은 표준화된 형식으로 번역가에게 제공됩니다. 번역가는 현지화 파일의 정확한 형식에 대해 걱정할 필요 없이 자신의 과업에 집중할 수 있습니다. 그들은 키를 검사할 수 있습니다. 키 자체가 중요한 맥락을 제공하고 올바른 단어 선택으로 안내할 수 있기 때문입니다.
모든 문자열이 번역되면 파일이 다운로드됩니다. 이 과정에서 원본 소스 파일과 일치하는 필요한 현지화 파일 형식이 생성됩니다.
리소스 파일 형식
네 가지 광범위한 유형의 리소스가 지원되며, 모두 본질적으로 텍스트 기반이며 텍스트 편집기에서 열고 검사할 수 있습니다.
스프레드시트
.XLSX 및 .CSV 파일이 지원됩니다. 이 형식은 현지화 목적에 대해 동등하며 키-값 쌍의 행을 포함합니다. 키는 한 행에 있으며, 해당 값은 인접한 행에 있습니다. 어떤 정확한 열이 어떤 목적으로 사용되는지는 애플리케이션에 따라 다르며, 현지화자는 Phrase가 열을 올바르게 해석하도록 구성해야 합니다. ZenDesk .CSV 파일은 고정 구조를 가지고 있어 이 파일 유형은 추가 조정이 필요하지 않습니다:
"제목","기본 언어","기본 텍스트","영어 텍스트","변형 상태" "simple_key","German","Einfacher Schlüssel.","Simple key.","Current"
XML
XML은 메타 정보를 <tags> 형식으로 제공하는 형식입니다. 태그 구조는 키와 해당 값이 어디에 있는지를 결정하는 데 사용되며, 여기 Android XML 파일에서 보여줍니다:
<string name="simple_key">메시지가 있는 간단한 키입니다.</string>
두 가지 표준 XML 번역 형식은 .TMX와 .XLIFF입니다. 이들은 하나의 언어에서 키와 값을 보유할 뿐만 아니라 소스 언어의 값 쌍을 대상 언어의 해당 값과 연결합니다. 이러한 파일은 일반적으로 이중 언어로 되어 있으며, 이는 Symfony Xliff 파일의 번역 단위에서 보여줍니다:
<trans-unit id="simple_key" resname="simple_key"> <source xml:lang="de-DE">단순한 키와 간단한 메시지입니다.</source <target xml:lang="en-GB">간단한 키와 간단한 메시지입니다.</target> </trans-unit>
QT 프로그램은 이러한 표준화된 형식과 매우 유사한 구조를 가진 리소스 파일을 사용하지만, 역사적 이유로 다른 레이아웃을 가지고 있습니다.
일반 키-값 목록
키와 값의 간단한 목록만 포함된 리소스 파일이 있으며, 이는 Ruby on Rails YAML의 이 스니펫에서 보여줍니다:
simple_key: 간단한 키와 간단한 메시지입니다.
많은 다양한 프로그래밍 언어 또는 플랫폼이 약간의 레이아웃 차이로 이러한 형식을 사용합니다.
이들은 단일 언어 파일이므로, 로컬라이제이션 프로그램은 소스 언어용과 대상 언어용의 병렬 버전을 유지해야 합니다.
Gettext는 설명 주석이나 복수 변형과 같은 추가 정보를 포함하는 키-값 파일을 생성합니다:
# 이 키에 대한 놀라운 설명입니다! msgid "key_with_description" msgid_plural "" msgstr[0] "확인해 보세요! 이 키에는 설명이 있습니다! (최소 일부 형식으로)" msgstr[1] "확인해 보세요! 이 키에는 %s 설명이 있습니다! (최소 일부 형식으로)"
유사한 기능과 레이아웃을 가진 경쟁 형식이 있으며, 상대적으로 사소한 방식으로 다릅니다.
연관 배열
다른 형식은 이를 읽기 위해 사용자 지정 코드(파서)를 요구하는 반면, 일부 형식은 개발자와 지역화 담당자에게 더 쉽습니다. .JSON(JavaScript) 및 .PHP 배열을 기반으로 한 형식은 일반 코드 구조(배열)로 직접 읽고 매핑할 수 있어 조작하기 쉽습니다. 배열은 복잡할 수 있으며, 서로 다른 애플리케이션이 사용자 지정 배열 구조를 생성합니다.
예를 들어, go-i18n JSON은 키를 id:로 참조합니다.
{
"id": "simple_key",
"번역": "간단한 키, 간단한 메시지, 아주 간단합니다."
},
Angular는 배열의 키로 키 자체를 사용합니다:
"simple_key": "저는 간단한 키로 간단한 메시지를 가지고 있습니다.".
이러한 사소하지만 중요한 차이가 있기 때문에 널리 사용되는 .JSON 및 .PHP 배열 구조가 지원됩니다.