파일을 프로젝트에 업로드할 때, 모든 새로운 리소스가 해당 파일에서 추출되어 프로젝트에 저장됩니다. 업로드된 파일의 형식은 프로젝트를 위해 설정된 초기 형식일 필요는 없습니다. 리소스를 그룹화하기 위해 태그가 제공되면, 새로운 키에 해당 태그가 적용됩니다.
Gettext와 같은 일부 형식은 주석, 설명 또는 복수형에 대한 정보와 같은 추가적인 귀중한 메타 정보를 제공합니다. 이 정보는 가능한 경우 언제든지 추출되어 할당된 리소스와 함께 저장되며, 로컬라이제이션 파일에 제공된 모든 귀중한 정보를 향후 사용을 위해 저장할 수 있습니다.
파일을 업로드하는 방법은 여러 가지가 있습니다:
-
기본적으로, 새로운 콘텐츠만 추출되며 로컬라이제이션 프로젝트의 기존 키는 삭제되거나 업데이트되지 않습니다; 파일을 업로드하여 데이터가 손실될 수 없습니다. 기존 데이터를 덮어쓰는 것이 필요한 경우, 옵션을 선택하여 로컬라이제이션 파일의 콘텐츠로 프로젝트 리소스를 교체하십시오. 기존 번역은 업로드된 로컬라이제이션 파일의 콘텐츠로 덮어씌워집니다.
이 옵션은 API에서도 사용할 수 있습니다.
참고
데이터 손실을 방지하기 위해, 변경하기 전에 Phrase에서 로컬라이제이션 파일로 최신 변경 사항을 다운로드하고 옵션으로 다시 업로드하십시오.
-
업로드된 번역 키 이름 앞에 추가할 고유 식별자(예: 파일 경로)를 입력하십시오. 키 이름을 정리하기 위해 프로젝트나 파일과 관련된 의미 있는 접두사를 사용하십시오.
예를 들어, 접두사
project_가 있는 가져온 키hello_world는 키project_hello_world로 결과를 낳습니다.번역 키 접두사는 키가 서로 다른 프로젝트나 파일 간의 충돌을 피하기 위해 기존 키와 일치하도록 보장합니다.
이 옵션은 API 및 CLI 인터페이스에서도 사용할 수 있습니다.
-
새 키를 추가하고 업로드된 파일의 내용으로 기존 키를 덮어씁니다.
-
업로드된 다국어 파일의 소스 텍스트와 기존 소스 텍스트가 일치하는 경우에만 대상 번역을 업데이트합니다.
-
업로드된 파일의 키에 대한 모든 설명을 업데이트해야 하는 경우 이 옵션을 선택하십시오. 빈 설명은 기존 설명을 덮어씁니다. 설명에는 번역가를 위한 추가 정보가 포함될 수 있으며 편집자에서 개별 키를 식별하는 데 도움이 됩니다.
-
번역을 정리하기 위해 의미 있는 레이블로 키에 여러 태그를 추가하십시오. 이 옵션을 선택하면 새 키가 자동으로 업로드 태그로 태그되는 것을 방지합니다.
-
이 옵션을 선택하면 업로드 시 새 키와 업데이트된 번역이 있는 키에 자동으로 태그가 추가됩니다. 이것은 새, 업데이트된 및 오래된 번역 문자열을 구분하는 데 도움이 되며, 관련 키만 추가로 처리되도록 보장합니다.
이 옵션은 API에서도 사용할 수 있습니다.
-
파일의 인코딩(예: UTF-8)을 지정하거나 자동으로 선택되도록 하십시오(자동 선택된 인코딩은 잘못된 인코딩을 초래할 수 있으며 업로드를 실행 취소하여 롤백할 수 있습니다).
-
-
는 번역을 업데이트할 때 비주요 언어 번역을 다시 검증할 필요성을 방지합니다.
-
는 모든 업로드된 번역을 검토된 것으로 간주합니다. 이 옵션은 고급 검토 워크플로가 활성화되었을 때 사용할 수 있습니다. 키가 프로덕션으로 전송될 준비가 되었음을 나타냅니다.
-
은 모든 업로드된 번역을 검증된 것으로 간주합니다.
-
Strings에 파일을 업로드하려면 다음 단계를 따르십시오:
-
업로드 전에 파일이 형식에 따라 올바르게 포맷되었는지 확인하십시오.
-
프로젝트에서 업로드 파일을 메뉴에서 선택하십시오.
페이지가 열립니다.
-
파일 선택을 클릭하고 디렉토리에서 파일을 선택하십시오.
선택한 파일이 필드에 추가됩니다.
-
파일에 대한 을 선택하십시오.
제안된 형식은 파일 유형에 따라 먼저 표시됩니다.
-
드롭다운 목록에서 파일 콘텐츠에 대한 언어를 선택하십시오.
이 정보가 파일 자체에 없으면 콘텐츠에 대한 새 언어를 생성하거나 기존 언어를 사용하십시오.
-
선택적으로 새 키와 기타 옵션에 할당할 태그를 제공하십시오.
-
저장을 클릭합니다.
콘텐츠가 가져와져 키로 변환됩니다.
-
업로드 실패
파일을 제대로 처리할 수 없는 경우 오류 세부정보가 제공되어 오류를 완화하는 데 도움이 됩니다.
-
업로드 성공
번역 파일이 성공적으로 처리된 후, 업로드 개요와 다음 단계로 연결되는 버튼이 있는 요약 페이지가 표시됩니다. 업로드 태그를 클릭하여 편집기에서 파일을 엽니다.
-
키 제거 중
로컬라이제이션 파일에서 키를 제거하고 다시 업로드할 때 우발적인 키 삭제를 방지하기 위해, 해당 키는 자동으로 삭제되지 않습니다.
이 키를 제거하려면 다음 단계를 따르십시오:
언급되지 않은 키는 현재 업로드에 포함되지 않았지만 프로젝트에 여전히 존재하는 키입니다. 이들을 삭제하면 업로드된 파일에 포함되지 않은 모든 키와 관련된 번역이 프로젝트에서 제거됩니다.
-
업로드 취소
모든 업로드는 여러 작업을 트리거하며 프로젝트 내의 많은 데이터를 수정할 수 있으며 업로드를 철회하는 것은 불가능합니다.
업로드된 파일에 의해 (잘못) 도입된 키를 제거하려면 다음 단계를 따르세요:
해당 업로드에 의해 생성된 모든 키와 관련된 번역이 제거됩니다. 업로드 이전에 존재했던 키의 번역은 제거되지 않습니다. 개별 번역을 제거하려면 각 번역의 버전 기록을 사용하세요.
언어 파일은 프로젝트에서 언제든지 지원되는 형식으로 다운로드할 수 있습니다.
파일은 애플리케이션에서 API를 통해 또는 CLI를 통해 다운로드할 수 있습니다.
파일은 프로젝트의 탭에서 선택한 후 다운로드 (여러 파일) 또는 언어의 더 많은 옵션 /다운로드 버튼을 클릭하여 다운로드할 수 있습니다.
다운로드 옵션은 창에서 , 및 탭으로 파일을 다운로드할 때 제공됩니다.
다른 을 선택하면 다른 옵션이 제공됩니다. 자세한 내용은 특정 파일 형식에 대한 관련 기사를 참조하십시오.
기본적으로 번역 가능한 리소스는 원본 파일 구조를 유지하는 대신 키와 값으로 저장됩니다. 이것은 하나의 형식에 고정되지 않고 교환 가능한 형식을 허용하며 태그를 사용하여 유연한 그룹화를 가능하게 합니다.
일부 프레임워크나 설정은 추가 구성이 필요한 여러 소스 파일을 요구합니다.
별도의 파일 유지
일반적으로 각 언어에 대한 모든 번역을 하나의 파일에 보관하십시오. 이것은 리소스 다운로드를 더 빠르고 견고하게 만듭니다. 번역은 프로젝트에서 정리되어 유지되므로 별도의 작은 파일이 필요하지 않습니다.
로컬라이제이션 파일이 별도의 파일로 유지되어야 하는 경우, 키를 업로드할 때 태그를 붙이고 번역된 키를 원래 파일로 다시 다운로드할 때 태그를 참조하여 파일 기반 워크플로를 사용할 수 있습니다. 키는 여러 개의 태그를 가질 수 있으며 여러 파일에 포함되어 재사용성과 일관성을 보장합니다. 태그 기반 워크플로는 유연하며 번역 리소스를 프로젝트에 업로드하지 않고도 재구성할 수 있습니다.
원활한 워크플로를 보장하기 위해 모든 파일에서 키에 고유한 이름을 부여하십시오. 키-값 기반 접근 방식에서는 키가 모든 컨텍스트에서 동일한 값이 할당되어야 합니다. 일부 프레임워크는 여러 파일에서 비고유 키의 사용을 허용합니다. Symfony와 같은 일부 형식은 메시지 도메인을 지원합니다. 이 도메인은 파일 이름에 의해 감지됩니다. 키는 파일 이름 기반 도메인에 의해 자동으로 범위가 지정되지 않지만, 파일 내의 키에 대해 고유한 도메인 접두사를 사용하여 이를 해결할 수 있습니다.
예제 CLI 구성
CLI로 작업하거나 프로젝트를 리포지토리(예: GitHub, GitLab 또는 Bitbucket)와 연결하는 경우, 업로드 및 다운로드를 관리하기 위해 구성 파일을 설정하십시오.
예를 들어, 프로젝트에는 소스 로캘에 대한 여러 의미론적으로 명명된 번역 파일이 있습니다. 예: accounts.en.yml, emails.en.yml 등. 이러한 의미론적 이름은 태그를 통해 관리됩니다.
파일 경로에 태그 자리 표시자를 포함하여 로컬라이제이션 프로젝트의 파일 구성을 반영하고 Strings 프로젝트의 태그에 연결하도록 .phrase.yml을 구성하십시오:
phrase:
access_token: "3d7e6598d955bfcab104c45c40af1b9459df5692ac4c28a17793"
project_id: "23485c9c5dfb15d85b32d9c5f3d2hl54"
file_format: yml
push:
sources:
- file: ./path/to/locales/<tag>.en.yml
params:
locale_id: "abcd1234cdef1234abcd1234cdef1234"
pull:
targets:
# 계정
- 파일: ./path/to/locales/accounts.<locale_name>.yml
params:
태그: 계정
# 이메일
- file: ./path/to/locales/emails.<locale_name>.yml
params:
태그: 이메일
파라미터 태그는 <tag> 자리 표시자를 사용하는 대신 푸시 섹션에서도 사용할 수 있습니다.
구성은 푸시를 실행하거나 리포지토리에서 동기화를 트리거할 때 파일에서 가져온 태그를 기반으로 키를 생성합니다. 풀을 실행하거나 리포지토리로 내보내기를 트리거할 때 태그를 기반으로 파일에 키를 그룹화합니다.
제품, 웹사이트 또는 앱은 여러 언어로 번역되지만, 경우에 따라 현지화는 선택된 언어뿐만 아니라 하나의 언어 내에서의 다양한 버전이기도 합니다.
다음과 같은 경우 추가적인 구분이 필요합니다:
-
제품이 동일한 언어가 사용되는 지역에서 다른 브랜드를 가지고 있는 경우.
-
제품이 화이트 라벨 솔루션을 사용하고자 하는 다양한 클라이언트에 의해 사용되는 경우.
-
단순, 공식 또는 비공식과 같은 언어 변형이 필요한 경우.
정적 제품 현지화
제품이 완전히 개발되고 거의 업데이트되지 않는 경우, 프로젝트 내에 제품의 별도 버전이 존재할 수 있습니다.
지속적인 업데이트로 프로젝트 현지화하기
제품이 새로운 컨텐츠(키)로 지속적으로 업데이트되는 경우, 여러 프로젝트에 이러한 업데이트를 적용하고 동기화 상태를 유지하는 것은 어렵습니다. 프로젝트 내에서 전용 언어를 사용하여 유지 관리하십시오.
ISO 표준(예: en-US)을 따르는 언어 코드는 고유할 필요가 없으므로 동일한 언어의 여러 버전을 프로젝트 내에서 생성할 수 있습니다. 고유한 언어 이름을 사용하여 지역, 클라이언트 또는 청중을 구분하십시오.
설정 시, 기본 로캘에 새로 도입된 키는 다른 언어에서 번역되지 않은 것으로 표시되고 그에 따라 현지화됩니다. 클라이언트와 그들의 번역가와 작업할 때, 그들의 사용자 프로필 또는 프로젝트 사용자 관리에서 언어 액세스를 업데이트하여 그들이 자신의 언어 버전만 편집할 수 있도록 특별히 할당하십시오.
동일한 프로젝트 내에서 작업 및 검토 워크플로우와 함께 병렬 현지화 프로세스를 설정하십시오. 이 유연성은 API를 통해 언어 파일을 업로드하고 다운로드하거나 자동화된 프로세스에도 확장됩니다.