지역화 가능한 매니페스트 개발

또 다른 고려사항은 명세가 사용하는 언어 협상 전략입니다. 매니페스트가 잘 알려진 URL에 캐시되는 것이 아니라 요청 시 생성될 수 있다면, 지역화는 요청별로 적용될 수 있습니다. 이는 축약 매니페스트 스타일에 더 가깝습니다. 어떤 구현은 협상할 수 있지만 다른 구현은 그렇지 못한 경우에는, 명세가 서로 다른 전략의 사용을 허용하는 것이 중요할 수 있습니다.

현대 운영 환경은 사용할 수 있는 매우 광범위한 로케일 집합을 지원하며, 애플리케이션 소유자는 하나의 지역화된 애플리케이션 또는 문서로 다양한 사용자를 만족시키고자 하는 경우가 많다는 점을 염두에 두어야 합니다. 명세의 예는 필연적으로 세 개나 네 개 정도의 로케일로 제한되지만, 실제 애플리케이션에서 50개 이상의 특정 로케일을 사용하는 것은 드문 일이 아닙니다.

매니페스트는 사용자의 언어 환경설정을 사용 가능한 지역화 리소스와 일치시켜야 합니다. 사용자의 로케일 환경설정은 기본 언어 하위 태그 이상의 내용을 포함할 수 있습니다. 예를 들어 zh-Hans 같은 태그의 스크립트(“간체 한자 스크립트로 쓰인 중국어”를 의미)나, fr-CA 같은 태그의 지역(“캐나다에서 사용되는 프랑스어”를 의미), 또는 둘 다를 포함할 수 있습니다. 일부 시스템은 달력, 숫자 모양, 정렬 등과 같은 맞춤 정보를 포함하는 [BCP47]의 확장인 유니코드 로케일 식별자를 지원합니다. 자세한 내용은 [LTLI]를 참조하세요.

"localized-resource": {
	"en":     {"value": "This is English"},
	"en-GB":  {"value": "This is UK English"},
	"en-US":  {"value": "This is US English"}
}

en-GB-oxendict  // 일치 없음
en-GB           // en-GB와 일치
en              // en-GB가 없으면 en과 일치
(default)       // 일치 없음, 기본값 사용

비언어적 필드(즉, 인간 언어가 아닌 데이터를 포함하는 문자열)의 경우, 언어 또는 방향 메타데이터는 값과 연결되어서는 안 됩니다. 여기에는 애플리케이션 내부 데이터 값 [INTERNATIONAL-SPECS]도 포함된다는 점에 유의하세요.

소비자가 데이터에 언어 태그를 할당해야 하는 경우, 값 zxx(비언어적)를 사용해야 합니다. 소비자가 데이터에 기본 방향을 할당해야 하는 경우, 값 auto를 사용해야 합니다.

단일 언어로 나타나는 지역화 가능 텍스트 필드의 경우, 값을 나타내기 위해 데이터 구조를 사용하세요. 권장 표현은 세 개의 필드를 가진 객체입니다. value 필드는 실제 문자열을 포함합니다. lang 필드는 유효한 [BCP47] 언어 태그를 포함합니다. dir 필드는 문자열의 기본 방향(값 ltr, rtl, 또는 auto 중 하나)을 포함합니다.

[STRING-META]의 지역화 가능 WebIDL 딕셔너리를 참조하세요.

단일 언어 지역화 가능 텍스트 필드는 주어진 문서에 자연어 문자열이 몇 개만 있을 때 가장 효과적입니다. 매니페스트와 같은 문서가 많은 자연어 문자열을 포함하면 이는 비효율적이 됩니다. 이러한 문자열을 인코딩하는 복잡성을 줄이기 위한 한 가지 우회 방법은 언어와 기본 방향에 대한 문서 수준 기본값을 설정하는 것입니다. 언어가 방향을 함의하지 않으므로 이들은 별도의 값입니다. 위에서 설명한 단일 언어 지역화 가능 텍스트 필드 표현을 사용하여, 주어진 문자열 값에서 어느 값이든 재정의할 수 있는 기능은 여전히 있어야 합니다.

[JSON-LD] @context 메커니즘을 사용할 수 있는 명세의 경우, 문서 수준 기본값을 제공하기 위해 @language 및 @direction 필드를 사용하세요.

명세가 자체 문서 수준 기본값을 정의한다면, 두 개의 선택적 필드를 제공하세요.

• 문서의 기본 언어 필드는 language라고 불러야 하며, 유효한 [BCP47] 언어 태그를 포함하도록 명시해야 합니다. 명세는 구현이 [BCP47] 언어 태그가 올바른 형식인지 확인하기만 하면 된다고 명시해야 합니다.
• 문서의 기본 기본 방향 필드는 direction이라고 불러야 하며, ltr, rtl, 또는 auto 값을 지원해야 합니다.

세계는 단일 언어만 사용하지 않습니다. 하나의 언어만 포함하는 문서를 가진다는 것은 매니페스트를 지역화하기 위해 언어마다 하나씩 여러 반복본을 제공해야 함을 의미합니다. 이는 매니페스트를 요청할 때 언어 협상을 필요로 할 수도 있습니다.

이를 해결하는 한 가지 방법은 매니페스트 문서 안의 각 지역화 가능 텍스트 필드에 다국어 값을 허용하는 것입니다.

언어 선택은 단순히 언어 태그 문자열 값을 사용자가 선호하는 로케일과 정확히 일치시키는 것만은 아닙니다. 객체 표현으로 된 일반적인 지역화 가능 텍스트 필드는 값과 연결된 언어 태그를 알아내기 위해 객체를 역직렬화해야 합니다. 주어진 매니페스트 파일에 값이 많을 때 이는 비효율적일 수 있습니다. 이러한 경우에는 언어 맵을 사용하여 지역화 가능 텍스트 값을 구성하는 것이 모범 사례입니다. 이러한 맵은 선택을 목적으로 언어 태그를 노출하지만, 값 쪽에서는 여전히 객체 표현을 사용합니다. 주어진 문자열 값에 대해 언어와 방향을 모두 재정의해야 할 수 있기 때문입니다.

단일 매니페스트 접근법은 언어 값의 배열을 사용하여 지역화 가능 필드를 정의함으로써 지역화를 제공합니다.

단일 매니페스트의 장점은 다음과 같습니다.

1. 매니페스트가 하나의 파일이므로 다운로드가 쉽습니다.
2. 모든 언어에서 올바른 버전의 리소스가 사용되고 있는지 확인하기가 더 쉽습니다.
3. 언어 기본값 적용을 더 쉽게 관리할 수 있습니다.

이 접근법에는 다음과 같은 단점도 있습니다.

1. 매니페스트가 많은 언어로 렌더링되면 파일 크기가 불균형적으로 커질 수 있습니다.
2. 지역화 프로세스는 일반적으로 원본의 복사본을 만들고, 언어를 포함하는 자료만 교체하는 방식에 최적화되어 있습니다. 고도로 다국어화된 파일에서 지역화를 만들고, 관리하고, 동기화하는 것은 언어별로 별도의 파일을 사용하는 것보다 더 복잡할 수 있습니다. 스크립트나 도구를 통해 매니페스트를 생성하는 것은 이러한 복잡성을 관리하기 위한 한 가지 접근법입니다.

단일 매니페스트는 지역화 가능 콘텐츠 필드의 수가 제한되어 있거나 언어 수가 제한되어 있는 더 작은 소스 파일에서 가장 잘 작동합니다. 대부분의 단일 매니페스트는 실제 선택을 수행하기 위해 ([JSON-LD]에서 볼 수 있는 것과 같은) 일종의 “언어 색인” 체계를 정의합니다.

로케일별 매니페스트는 지원되는 각 언어 또는 로케일마다 별도의 파일을 만듭니다. 일반적으로 명세는 매니페스트 파일을 할당하고 찾기 위해 path 또는 filename에 기반한 구성 체계 중 하나를 선택합니다.

로케일별 매니페스트의 장점은 다음과 같습니다.

1. 로케일을 만들거나 추가하는 관리가 일반적으로 더 쉽습니다. 지역화 프로세스는 일반적으로 주어진 소스 파일의 “지역화된 복사본 만들기”에 최적화되어 있습니다.

단점은 다음과 같습니다.

1. 단순한 로케일 폴백 체인조차도 클라이언트가 여러 파일을 검색하거나 가져오도록 요구할 수 있습니다.
2. 파일이 분리되어 있으므로 콘텐츠의 버전 관리를 엄격하게 제어해야 합니다.
3. 올바른 동작을 보장하기 위해 훨씬 더 많은 변형을 테스트해야 할 수 있습니다.

일반적인 절충안은 지역화할 수 없는 콘텐츠의 대부분 또는 전부를 포함하는 중앙 매니페스트 파일을 두고, 지역화 가능 콘텐츠를 포함하는 별도의 파일을 결합하는 것입니다. 어떤 경우에는 중앙 매니페스트 파일이 지역화 가능 콘텐츠의 기본값을 포함합니다. 중앙 매니페스트는 사용 가능한 로케일의 디렉터리나 목록 (또는 언어별 매니페스트의 URL)을 포함할 수도 있어, 클라이언트가 실제로 사용 가능한 지역화 파일만 가져오려고 시도하면 되게 할 수 있습니다.