월드 와이드 웹을 위한 언어 태그와 로케일 식별자

1. 소개

언어 태그와 로캘은 웹의 국제화 (i18n)를 구성하는 기본적인 요소 중 일부입니다. 이 문서에서는 이러한 국제화 측면과 관련된 많은 기본 용어의 정의를 확인할 수 있습니다.

이 문서는 또한 문서 형식이나 프로토콜에서 자연어 값을 식별하기 위해 명세 작성자들이 필요로 하는 용어와 모범 사례를 제공하며, 이는 국제화(I18N) 작업 그룹에서 권장합니다. 이러한(및 기타 많은) 모범 사례와 관련 자료 링크는 Internationalization Best Practices for Spec Developers [INTERNATIONAL-SPECS]에서도 확인할 수 있습니다. 이곳에 수록된 모범 사례 외에도, 웹상의 언어 메타데이터와 관련된 추가 모범 사례는 [STRING-META]에서 찾을 수 있습니다.

2. 언어와 언어 태그

콘텐츠의 자연어 또는 사용자의 국제화 기본 설정을 식별하기 위한 태그는 웹의 기본적인 구성 요소 중 하나입니다. 웹 및 인터넷 형식과 프로토콜에서 사용되는 언어 태그는 [BCP47]에 정의되어 있습니다. 언어 태그를 일관되게 사용하면 애플리케이션에서 언어별 서식 지정 또는 처리를 수행할 수 있습니다. 예를 들어 사용자 에이전트는 언어를 사용하여 텍스트를 표시하는 데 적절한 글꼴을 선택할 수 있고, 웹 페이지 디자이너는 한 언어의 텍스트를 다른 언어와 다르게 스타일링할 수 있습니다.

웹의 많은 핵심 표준은 언어 태그를 지원합니다. 여기에는 [XML10]의 xml:lang 속성, [HTML]의 lang 및 hreflang 속성, [XSL10]의 language 속성, CSS [CSS3-SELECTORS]의 :lang 의사 클래스, 그리고 SVG, TTML, SSML 등을 포함한 많은 항목이 있습니다.

자연어(또는 이 문서에서는 간단히 언어). 사람이 사용하는 말하기, 쓰기 또는 수어를 통한 의사소통입니다.

언어를 식별하는 방법은 다양하며, 소프트웨어가 웹 콘텐츠의 언어를 식별해야 하는 이유도 다양합니다. 웹의 문서 형식과 프로토콜은 일반적으로 인터넷의 다른 대부분 영역에서 사용하는 식별자, 즉 [BCP47]에 정의된 언어 태그를 사용합니다. "BCP"라는 명칭은 "현재의 모범 사례"를 구성하는 현행 IETF RFC 집합을 의미합니다.

언어 태그. 언어의 식별자로 사용되는 문자열입니다. 이 문서에서 언어 태그라는 용어는 항상 명시적으로 [BCP47] 언어 태그를 의미합니다. 이러한 언어 태그는 하나 이상의 서브태그로 구성됩니다.

​언어 식별이 필요한 웹 명세는 반드시 [BCP47]을 참조해야 합니다.

​명세는 가급적 [BCP47]의 특정 구성 요소 RFC를 참조하지 않아야 합니다.

[BCP47]은 이 문서가 발행될 당시 두 개의 개별 RFC로 구성된 다부분 문서입니다. 첫 번째 부분인 언어 식별용 태그 [RFC5646]은 언어 태그의 문법, 형식 및 용어를 정의합니다. 두 번째 부분인 언어 태그의 일치 [RFC4647]은 언어 태그를 사용하여 콘텐츠를 일치시키고, 비교하고 선택하는 여러 방식을 설명하며, 언어 기본 설정과 태그가 지정된 콘텐츠를 비교하는 것과 관련된 유용한 용어를 포함합니다.

​"RFC 5646 또는 그 후속 문서"와 같은 표현은 사용할 수 있지만, 특정 문서 버전이 필요한 경우에만 사용해야 합니다.

이러한 참조 방식은 한때 널리 사용되었지만, BCP 참조를 사용하는 것이 더 정확합니다. 언어 태그의 문법은 [RFC4646] 이후로 고정되어 있으므로, BCP를 참조해도 대부분의 구현에 추가적인 적합성 위험이 발생하지 않습니다.

​명세는 [BCP47]의 폐기된 버전, 예를 들어 [RFC1766] 또는 [RFC3066]을 참조해서는 안 됩니다.

​[BCP47]의 폐기된 버전과의 호환성을 유지해야 하는 명세는 반드시 [BCP47]의 obs-language-tag 생성 규칙을 참조해야 합니다.

[RFC4646]부터 [BCP47]은 언어 태그를 위한 더 복잡하고 기계 판독 가능한 구문을 정의했습니다. 이 구문은 안정적이며 가까운 미래에 변경될 것으로 예상되지 않습니다. 일부 명세는 이전 버전의 BCP47(구체적으로 [RFC1766] 및 [RFC3066])에서 사용된 이전 언어 태그 문법과의 호환성을 원하거나 요구할 수 있습니다. 이 문법은 더 허용적이었으며 [BCP47]에서 ABNF 생성 규칙 obs-language-tag로 설명됩니다. 현재의 언어 태그 문법을 도입한 [RFC4646]은 현재 [BCP47]의 일부로 [RFC5646]에 의해 대체되었습니다.

​URI의 일부로 언어 정보를 제공하는 애플리케이션(예: RDF 영역)은 가급적 [BCP47]을 사용해야 합니다.

현재 언어 정보를 표현하는 URI는 ISO 639의 일부 값을 사용하는 경우가 많습니다. 이로 인해 적절한 값이 무엇인지 모호한 상황이 발생합니다. 예를 들어 독일어의 경우 ISO 639-1의 de 또는 ISO 639-2의 ger 중 무엇을 사용해야 하는지 모호할 수 있습니다. BCP 47과 그 언어 서브태그 레지스트리를 사용하면 이러한 모호성을 피할 수 있습니다. 예를 들어 독일어의 경우 레지스트리에는 de만 포함되어 있습니다.

서브태그. 하이픈-마이너스 문자로 다른 서브태그와 구분되며 전체 언어 태그 내의 특정 의미 요소를 식별하는 ASCII 문자 또는 숫자의 시퀀스입니다. [BCP47]에서 서브태그는 대문자 또는 소문자 ASCII 문자(대소문자는 구별되지 않음)나 ASCII 숫자로 구성될 수 있습니다. 서브태그는 최대 8자로 제한됩니다(단, 서브태그의 구체적인 용도에 따라 추가적인 길이 제한이 적용됩니다).

언어 태그를 기반으로 콘텐츠 또는 동작을 선택하려면 [BCP47]([RFC4647]에서)에 정의된 몇 가지 추가 개념이 필요합니다. 이 문서에서는 [BCP47]에서 직접 가져온 다음 용어를 사용합니다:

IANA 언어 서브태그 레지스트리. 언어 태그에서 유효한 모든 서브태그의 포괄적인 목록을 포함하며 IANA를 통해 제공되는 기계 판독 가능한 텍스트 파일입니다. (링크: 레지스트리)

​명세는 ISO639, ISO15924, ISO3066 또는 UN M.49와 같이 IANA 언어 서브태그 레지스트리에 기여하는 [BCP47]의 기반 표준을 가급적 참조하지 않아야 합니다.

일부 표준은 [BCP47]에 기여하는 표준 중 하나를 직접 사용할 수 있으며, 이 경우에는 참조하는 것이 전적으로 적절합니다. 그러나 대부분의 경우 참조의 목적은 유효한 코드 목록과 그 의미를 지정하는 것입니다. [BCP47]의 서브태그 레지스트리는 안정화되어 있고 여러 유용한 방식으로 모호성을 해소하므로 이러한 유형의 참조에 선호되는 출처여야 합니다.

[BCP47]은 두 가지 서로 다른 적합성 수준을 정의합니다. 자세한 내용은 [BCP47]의 적합성 클래스를 참조하십시오. 언어 태그의 경우 적합성 수준은 구현이 언어 태그 값에 적용하는 검사 유형에 해당합니다.

올바른 형식의 언어 태그. [BCP47]에 정의된 문법을 따르는 언어 태그입니다. 즉, 구조적으로 올바르며, 지정된 길이의 ASCII 문자 및 숫자로 이루어진 서브태그가 하이픈으로 구분되어 구성됩니다.

유효한 언어 태그. 올바른 형식이며, [BCP47]의 추가 적합성 요구사항도 충족하는 언어 태그입니다. 특히 각 서브태그가 IANA 언어 서브태그 레지스트리에 나타나야 합니다.

​명세는 언어 태그가 올바른 형식이어야 한다고 요구하는 것이 좋습니다.

​명세는 언어 태그가 유효해야 한다고 요구할 수 있습니다.

​명세는 콘텐츠 작성자가 유효한 언어 태그를 사용하도록 요구하는 것이 좋습니다.

이는 구현에 권장되는 것보다 더 엄격하다는 점에 유의하십시오.

​콘텐츠 유효성 검사기는 가능한 경우 콘텐츠가 유효한 언어 태그를 사용하는지 검사하는 것이 좋습니다.

태그가 유효한지 검사하려면 레지스트리에 접근하거나 그 복사본을 보유하고 추가적인 런타임 로직을 사용해야 합니다. 콘텐츠 작성자는 유효한 값만 선택하고 생성하고 교환하도록 권고되지만, 언어 태그 일치 및 기타 일반적인 언어 태그 연산은 유효성 검사가 필요하지 않도록 설계되어 있습니다. 서브태그의 구체적인 의미적 내용을 이해해야 하는 기능이나 함수는 명세가 프로토콜이나 문서 형식의 일부로 유효한 태그를 규범적으로 요구하는 주된 이유입니다.

언어 태그 확장 또는 확장. IANA에 등록된 단일 문자 또는 숫자 서브태그로 시작하며 추가적인 유형의 언어 식별을 허용하는 추가 [BCP47] 서브태그 체계입니다.

​명세는 필요에 따라 [BCP47]에 등록된 확장을 참조할 수 있습니다.

특히 [RFC6067]은 "Unicode 로캘"이라고도 알려진 BCP 47 확장 U를 정의합니다. [BCP47]의 이 확장은 특정 로캘 변형을 선택하기 위한 추가 서브태그 시퀀스를 제공합니다.

​명세는 언어 태그의 길이를 제한하거나 확장 제거를 허용 또는 권장해서는 가급적 안 됩니다.

언어 범위. "특정 속성을 공유하는 언어 태그 집합을 식별"하는 데 사용되며 구조가 언어 태그와 유사한 문자열입니다.

언어 우선순위 목록. 일치에 사용할 사용자의 언어 기본 설정을 식별하는 하나 이상의 언어 범위 모음입니다. 이름에서 알 수 있듯이 이러한 목록은 일반적으로 사용자의 기본 설정에 따라 순서가 지정되거나 가중치가 부여됩니다. HTTP [RFC2616] Accept-Language [RFC3282] 헤더는 언어 우선순위 목록의 한 종류에 대한 예입니다.

기본 언어 범위. 하이픈으로 구분된 서브태그 시퀀스로 구성된 언어 범위입니다. 즉, 외형상 언어 태그와 동일합니다.

확장 언어 범위. 하이픈으로 구분된 서브태그 시퀀스로 구성된 언어 범위입니다. 확장 언어 범위에서 서브태그는 유효한 서브태그이거나 모든 값과 일치하는 와일드카드 서브태그 *일 수 있습니다.

앞에서 언급한 Accept-Language [RFC3282] 헤더와 같은 일부 언어 우선순위 목록은 목록에 나타나는 값에 "가중치"를 제공합니다. 이러한 가중치는 목록의 순서를 정하는 것 외의 용도로는 의존할 수 없습니다.

​언어 태그 일치 또는 언어 협상을 정의하는 명세는 사용되는 언어 범위가 기본 언어 범위인지 확장 언어 범위인지 반드시 명시해야 합니다.

​언어 태그 일치를 정의하는 명세는 일치 연산의 결과가 단일 결과([RFC4647]에 정의된 조회)인지, 또는 비어 있을 수도 있는(0개 이상의) 결과 집합([RFC4647]에 정의된 필터링)인지 반드시 명시해야 합니다.

​언어 태그 일치를 정의하는 명세는 사용 가능한 일치 알고리즘과 선택 메커니즘을 반드시 명시해야 합니다.

예를 들어 JavaScript 국제화 [ECMA-402] 및 [CLDR]은 구현자가 조정할 수 있는 "최적 일치" 알고리즘을 제공합니다.

3. 로케일과 국제화

이 절에서는 국제화 및 지역화와 관련된 기본 용어를 정의합니다.

서로 다른 언어를 사용하거나 서로 다른 문화적 배경을 가진 사용자는 일반적으로 자신의 모국어, 문자 체계, 측정 체계, 달력 및 기타 언어 규칙과 문화적 관습을 사용하여 정보를 올바르게 처리할 수 있도록 조정된 소프트웨어와 서비스를 필요로 합니다.

언어 태그는 주어진 콘텐츠 또는 사용자와 관련된 국제화 기본 설정을 식별하는 데에도 사용할 수 있습니다. 이러한 기본 설정은 최종 사용자의 자연어, 지역적 연관성 또는 문화와 연결되어 있기 때문입니다. 이러한 기본 설정은 숫자, 날짜 또는 시간을 표시하는 작업, 언어적으로 목록을 정렬하는 작업, 달력 표시나 일반적인 측정 단위와 같은 항목의 기본값을 제공하는 작업, 12시간제와 24시간제 표시 중 하나를 선택하는 작업 및 사용자가 개별적으로 설정하기에는 너무 번거롭다고 느낄 수 있는 많은 다른 세부 사항에 적용됩니다. 이러한 기본 설정을 위한 식별자를 통틀어 일반적으로 로캘이라고 합니다. Unicode 로캘을 정의하는 [BCP47]의 확장은 [CLDR] 웹의 국제화 API의 기반을 제공합니다. 특히 JavaScript 언어 [ECMASCRIPT]는 [ECMA-402]에 있는 API의 기반으로 Unicode 로캘을 사용합니다.

국제화 기본 설정. 사용자의 특정 언어 및 서식 지정 기본 설정과 이와 관련된 문화적 관습의 집합입니다. 소프트웨어는 이러한 기본 설정을 사용하여 해당 사용자와 교환되는 정보를 올바르게 처리하거나 표시할 수 있습니다.

콘텐츠 또는 서비스가 전 세계 사용자에게 사용 가능하고 수용 가능한 것으로 간주되도록 하기 위해 웹에서는 다양한 종류의 국제화 기본 설정을 제공할 수 있습니다. 이러한 기본 설정에는 다음이 포함될 수 있습니다:

• 구문 분석, 맞춤법 검사 및 문법 검사와 같은 텍스트 처리를 위한 자연어;
• 표시되는 텍스트 문자열뿐만 아니라 이미지, 색상, 소리, 형식 및 탐색 요소와 같은 항목을 포함할 수 있는 사용자 인터페이스 언어;
• 날짜, 시간, 숫자, 목록 및 기타 값의 표시(사람을 위한 서식 지정);
• 콘텐츠의 대조, 정렬 및 구성(예: 전화번호부 또는 사전);
• 공휴일, 근무 규칙, 평일/주말 구분, 월의 수와 구성, 연도 번호 지정 등을 포함할 수 있는 대체 시간 체계 및 달력;
• 세금 또는 규제 체계;
• 통화

국제화. 문화, 지역 또는 언어가 서로 다른 대상 사용자를 지원할 수 있도록 제품을 설계하고 개발하는 것입니다. 국제화는 영어 단어에서 "I"와 "N" 사이에 열여덟 개의 글자가 있기 때문에 때때로 i18n으로 축약됩니다.

지역화. 특정 대상 시장 또는 개인 집단의 개별적인 문화적 기대에 맞게 시스템을 조정하는 것입니다. 지역화에는 사용자에게 표시되는 텍스트와 메시지의 번역이 포함되지만 이에 한정되지는 않습니다. 지역화는 영어 단어에서 "L"과 "N" 사이에 열 개의 글자가 있기 때문에 때때로 l10n으로 축약됩니다. 특정 국제화 기본 설정 집합에 해당하는 특정 콘텐츠 및 기본 설정 집합을 실제로 사용할 수 있는 경우, 해당 시스템을 지역화되었다고 합니다.

로캘. 국제화 기본 설정 집합을 위한 식별자(예: 언어 태그)입니다. 일반적으로 이 식별자는 사용자가 선호하는 언어를 나타내며, 지리적 지역(예: 국가)과 같은 다른 정보를 포함할 수도 있습니다. 로캘은 시스템 또는 프로세스 내에서 문화의 영향을 받는 동작을 얻기 위해 API에 전달되거나 운영 환경에서 설정됩니다.

로캘 인식(또는 활성화됨). 로캘의 변경에 문화 및 언어별 동작이나 콘텐츠로 대응할 수 있는 시스템입니다. 일반적으로 국제화된 시스템은 다양한 종류의 사용자의 국제화 기본 설정을 충족하기 위해 광범위한 로캘을 지원할 수 있습니다.

언어 태그는 서브태그를 사용하여 언어, 문자 체계, 지역 및 특별히 등록된 다양한 변형에 관한 정보를 제공할 수 있습니다. 그러나 때로는 이러한 항목 중 어느 것과도 직접적으로 연관되지 않는 국제화 기본 설정이 있습니다. 예를 들어 많은 문화권에는 콘텐츠 항목을 정렬하는 방법이 둘 이상 있으므로 적절한 정렬 순서를 항상 언어 태그만으로 추론할 수는 없습니다. 따라서 독일어 사용자는 사전에서 사용하는 정렬 순서와 전화번호부에서 사용하는 정렬 순서 중에서 선택하고 싶을 수 있습니다.

역사적으로 로캘은 사용자의 프로그래밍 언어 또는 운영 환경과 연관되어 있었으며 이에 특화되어 있었습니다. 이러한 애플리케이션별 식별자는 언어 태그에서 추론하거나 언어 태그로 변환할 수 있는 경우가 많았습니다. 로캘 모델의 몇 가지 예로는 Java의 java.util.Locale, POSIX(de_CH@utf8과 같은 식별자), Oracle 데이터베이스(AMERICAN_AMERICA.AL32UTF8) 또는 Microsoft의 LCID(0x0409와 같은 숫자 코드를 사용)가 있습니다. 이러한 여러 모델과 ISO639 또는 ISO3166과 같은 기반 표준 및 초기 언어 태그(예: [RFC1766]) 사이의 관계는 전적으로 의도된 것이었습니다. 구현은 HTTP의 Accept-Language 헤더와 같은 기존 프로토콜의 언어 태그를 독점적 또는 플랫폼별 로캘 모델에 매핑하는 경우가 많았으며 현재도 그렇게 하고 있습니다.

현재의 [BCP47] 식별자 구문이 채택된 이후 여러 로캘 모델이 BCP47을 직접 채택하거나 독점 모델과 언어 태그 사이의 변환 또는 매핑을 제공했습니다. 특히 [CLDR]로 알려진 로캘 데이터의 오픈 소스 저장소가 개발되고 채택되면서 언어 태그가 로캘 식별자로 더욱 널리 채택되었습니다.

공통 로캘 데이터 저장소(또는 [CLDR]). 공통 로캘 데이터 저장소는 시스템 또는 운영 환경에서 로캘을 활성화하는 데 필요한 데이터 집합을 정의하고 수집하며 관리하는 Unicode Consortium 프로젝트입니다. CLDR 데이터와 해당 로캘 모델은 특히 브라우저에서 널리 채택되고 있습니다.

Unicode 로캘 식별자 또는 Unicode 로캘. UTR#35 [LDML]에 정의된 서브태그 선택에 대한 추가 규칙과 제한을 따르는 언어 태그입니다. 모든 유효한 Unicode 로캘 식별자는 유효한 [BCP47] 언어 태그이기도 하지만, 일부 유효한 언어 태그는 유효한 Unicode 로캘 식별자가 아닙니다.

정규 Unicode 로캘 식별자. [LDML]에 있는 Unicode 로캘 식별자 정규화 규칙(3절 참조)을 적용하여 얻은 올바른 형식의 언어 태그입니다. 이 과정은 모든 유효한 [BCP47] 언어 태그를 유효한 Unicode 로캘 식별자로 변환합니다. 예를 들어 폐기된 서브태그 또는 비정규 grandfathered 태그는 IANA 언어 서브태그 레지스트리에 있는 선호 값으로 대체됩니다.

[CLDR]은 Unicode 로캘 식별자와 관련된 두 개의 언어 태그 확장([RFC6067] 및 [RFC6497])을 정의하고 유지 관리합니다. 이러한 확장을 통해 언어 태그는 언어적 또는 지역적 변형을 넘어서는 일부 국제화 기본 설정 변형을 표현하거나, 주어진 로캘 내에 여러 옵션 또는 사용자 기본 설정이 있는 경우 서식 지정 동작 또는 콘텐츠를 선택할 수 있습니다. Unicode 로캘 식별자에는 이러한 확장을 포함할 필요가 없습니다. 식별되는 로캘에 이러한 확장 중 하나가 제공하는 추가 조정이 필요한 경우에만 사용됩니다. [CLDR]은 또한 특정 서브태그가 로캘 식별자로 사용될 때 특정한 해석을 적용합니다. 자세한 내용은 [LDML]의 3.2절을 참조하십시오.

Unicode 로캘 언어 태그 확장 [RFC6067]은 -u- 서브태그를 사용하며, 서로 다른 로캘 기반 형식과 동작을 선택하기 위한 서브태그를 제공합니다. 자세한 내용은 [LDML]의 3.6절을 참조하십시오.

변환된 콘텐츠 언어 태그 확장 [RFC6497]은 -t- 서브태그를 사용하며, 문자 체계 간 음역과 같은 텍스트 변환을 위한 서브태그를 제공합니다. 자세한 내용은 [LDML]의 3.7절을 참조하십시오.

Unicode 로캘은 점점 더 웹의 국제화를 위한 기반이 되고 있으며, 특히 JavaScript [ECMASCRIPT]의 Intl 로캘 프레임워크 [ECMA-402]의 일부로 사용됩니다.

​콘텐츠 작성자는 정규 Unicode 로캘 식별자인 언어 태그를 가급적 선택해야 합니다.

[LDML]의 3절에 있는 추가적인 콘텐츠 제한 및 정규화 단계는 [BCP47] 자체에서 제공하는 것보다 더 나은 상호 운용성과 일관성을 제공합니다.

​구현은 정규 Unicode 로캘 식별자인 언어 태그만 가급적 내보내야 하며, 소비하는 언어 태그를 정규 태그 생성 규칙을 사용하여 가급적 정규화해야 합니다.

위와 마찬가지로 [LDML]의 3절에 있는 추가적인 콘텐츠 제한 및 정규화 단계는 [BCP47] 자체에서 제공하는 것보다 더 나은 상호 운용성과 일관성을 제공합니다. 이 모범 사례를 구현이 [CLDR]의 두 확장 중 하나를 지원하거나, 생성하거나, 처리하거나, 이해해야 한다는 의미로 해석해서는 안 됩니다.

​콘텐츠 작성자는 특정 애플리케이션에서 추가 조정이 필요하지 않는 한 언어 태그 확장을 언어 태그에 가급적 포함하지 않아야 합니다.

모든 Unicode 로캘 식별자가 또한 올바른 형식의 [BCP47] 언어 태그라는 점을 기억하는 것이 중요합니다. Unicode 로캘 식별자는 [CLDR]의 언어 태그 확장 중 어느 것도 사용할 필요가 없습니다.

비언어 필드. 자연어 텍스트 데이터를 저장하거나 교환하기 위한 것이 아닌 데이터 구조의 모든 요소입니다. 여기에는 불리언, 숫자, 날짜 등과 같은 문자열이 아닌 데이터 유형이 포함됩니다. 또한 프로그램 또는 프로토콜의 내부 식별자와 같은 문자열도 포함됩니다. 이 문서에서는 이 개념의 약칭으로 필드라는 용어를 사용합니다.

문서 형식 또는 프로토콜에 관한 명세는 일반적으로 다양한 데이터 값 또는 데이터 구조의 교환, 처리 또는 표시를 정의합니다. 웹은 주로 데이터의 직렬화와 교환에 텍스트 파일을 사용합니다. 원시 바이트조차 일반적으로 base64와 같은 문자열 직렬화를 사용하여 전송됩니다. 따라서 웹의 비언어 필드도 일반적으로 문자열로 구성됩니다. 여기서 중요한 차이점은 비언어 필드는 일반적으로 사용자가 아니라 기반 애플리케이션이 해석하거나 소비하도록 의도된다는 것입니다.

로캘 중립. 비언어 필드가 특정 언어, 로캘 또는 문화에 특별히 적합하지 않은 형식으로 저장되거나 교환되고, 로캘 인식 방식으로 표시하기 위해 모호함 없이 해석할 수 있는 경우 이를 로캘 중립이라고 합니다.

많은 명세는 [XMLSCHEMA11-2] 또는 [JSON-LD]에서 제공하는 것과 같은 직렬화 방식을 사용하여 문서 형식 또는 프로토콜에서 비언어 필드의 로캘 중립 인코딩을 제공합니다.

로캘 중립 표현 자체가 특정 문화적 기본 설정과 연결될 수도 있지만, 이러한 연결은 최소화해야 합니다. 예를 들어 ISO8601 날짜/시간 값 직렬화의 상당수는 그레고리력과 연결되어 있지만, 형식, 필드 순서, 구분 기호 및 시각적 표현은 특정 로캘에 특별히 적합하지 않습니다(기계 판독을 목적으로 함). 또한 위의 예시에서 보여 준 것처럼 이 값은 어떤 달력이나 로캘로도 변환하여 표시할 수 있습니다.

언어 협상. 사용자의 국제화 기본 설정을 사용 가능한 로캘, 지역화된 리소스, 콘텐츠 또는 처리와 일치시키는 과정입니다.

로캘 폴백. 결정론적 패턴에 따라 보다 구체적인 리소스에서 보다 일반적인 리소스로 "폴백"하면서 번역된 콘텐츠, 로캘 데이터 또는 기타 리소스를 검색하는 과정입니다.

사용자의 기본 설정은 일반적으로 로캘 또는 우선순위가 지정된 로캘 목록으로 표현됩니다. 언어를 협상할 때 시스템은 사용 가능한 리소스에서 가장 잘 일치하는 콘텐츠 또는 기능을 얻기 위해 어떤 형태의 알고리즘을 따릅니다. 많은 경우 언어 협상 알고리즘은 로캘 폴백을 사용합니다.

​문서 형식에서 필드를 표시하는 명세는 데이터가 주변 콘텐츠의 언어에 따라 서식 지정되도록 가급적 요구해야 합니다.

비언어 필드가 문서 또는 애플리케이션의 일부로 사용자에게 표시될 때, 문서 또는 애플리케이션은 데이터가 표시되는 "컨텍스트"를 형성합니다. 콘텐츠 작성자 또는 애플리케이션 개발자는 필드가 경험의 자연스러운 일부처럼 보이도록 할 방법과 표시를 제어할 방법이 필요합니다. 이는 콘텐츠가 나타나는 컨텍스트의 언어 태그로 표시됩니다. 일반적으로 활성화된 구현은 이를 달성하기 위해 해당 태그를 로캘로 해석합니다. 비언어 필드를 표시하기 위한 로캘로 사용자 에이전트의 런타임 로캘 또는 지역화를 사용하는 것은 최후의 수단이어야 합니다.

​문서 형식 또는 애플리케이션에서 폼을 표시하거나 비언어 필드의 입력을 받는 명세는 값이 바로 주변의 콘텐츠 또는 마크업 언어 형식에 맞게 지역화되어 사용자에게 표시되도록 가급적 요구해야 합니다.

​비언어 필드를 표시하거나 교환하거나 입력할 수 있도록 하는 명세는 저장 및 교환에 로캘 중립 형식을 반드시 사용해야 합니다.

​구현은 문서 형식 또는 애플리케이션의 비언어 필드를 주변 콘텐츠의 언어와 일관된 형식을 사용하여 가급적 표시해야 하며, 입력 또는 편집을 위해 동일한 로캘로 지역화된 컨트롤을 제공하는 것이 권장됩니다.

사용자는 폼 필드 및 기타 데이터 입력에서 비언어 필드가 값이 나타나는 문서 또는 애플리케이션과 일관된 방식으로 표시되기를 기대합니다. 사용자는 일반적으로 자신의 입력이 사용자 에이전트 또는 운영 환경이 아니라 문서의 컨텍스트와 일치하기를 기대하며, 입력 유효성 검사, 안내 메시지 또는 컨트롤도 그에 따라 콘텐츠와 일관되기를 기대합니다. 이를 통해 콘텐츠 작성자는 완전히 지역화된 사용자 경험을 만들 수 있으며, 이는 일반적으로 사용자의 기대에 부합합니다.

4. 추가 읽을거리

국제화 작업 그룹은 추가적인 모범 사례와 참고 자료(예: 언어 태그 선택 관련 기사 등)를 제공합니다. 여기에는 다음이 포함됩니다:

• 웹의 문자열: 언어 및 방향성 메타데이터 [STRING-META]
• 언어 태그 선택하기
• HTML과 XML의 언어 태그
• 언어가 없는 텍스트 태깅하기
• 로컬라이제이션 vs 국제화

B. 감사의 글

국제화 작업 그룹은 본 명세에 기여한 다음의 분들께 감사를 표합니다:

• Felix Sasaki - 본 문서 편집 및 2006 WD 발행
• Mark Davis, Y.Umaoka, 및 기타 BCP47 확장 관련 기여자
• WS-I18N 기여자: 본 문서는 [WS-I18N-REQ]의 요구사항 R005를 충족시키기 위해 작성되었습니다.