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

1. 소개

언어 태그와 로케일은 웹 국제화(internationalization (i18n))의 기본 구성 요소 중 일부입니다. 이 문서에서는 이와 관련된 많은 기본 용어들의 정의를 제공합니다.

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

2. 언어와 언어 태그

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

웹의 많은 핵심 표준은 언어 태그를 지원합니다; 여기에는 [XML10]의 xml:lang 속성, [HTML]의 lang 및 hreflang 속성, [XSL10]의 language 속성, CSS의 :lang 의사 클래스([CSS3-SELECTORS]) 등과 SVG, TTML, SSML 등 많은 다른 곳이 포함됩니다.

Natural Language (이 문서에서는 단순히 language라고도 함). 인간이 사용하는 음성, 문자 또는 수화 의사소통을 말합니다.

언어를 식별하는 방법은 여러 가지가 있으며, 소프트웨어가 웹의 콘텐츠 언어를 식별해야 하는 이유도 다양합니다. 웹의 문서 형식과 프로토콜은 일반적으로 인터넷의 다른 많은 부분에서 사용되는 식별자를 사용하며, 이는 [BCP47]에 정의된 언어 태그로 구성됩니다. "BCP" 명명법은 "best current practice"를 구성하는 IETF RFC들의 집합을 가리킵니다.

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

​언어 식별을 요구하는 웹 명세는 반드시(MUST) [BCP47]를 참조해야 합니다.

​명세는 [BCP47]의 특정 구성 RFC들을 참조하지 않는 것이 권장됩니다(SHOULD NOT).

[BCP47]는 이 문서가 발표된 시점에 두 개의 별도 RFC로 구성된 다부문 문서입니다. 첫 번째 부분인 Tags for Identifying Languages [RFC5646]은 언어 태그의 문법, 형식 및 용어를 정의합니다. 두 번째 부분인 Matching of Language Tags [RFC4647]은 언어 태그를 사용하여 매칭, 비교 및 콘텐츠 선택을 위한 여러 방식을 설명하며, 언어 선호도와 태그된 콘텐츠 비교와 관련된 유용한 용어들을 포함합니다.

​"RFC 5646 또는 그 후속 문서"와 같은 표현은 문서 버전이 명확히 필요한 경우에만 사용될 수 있으며, 이러한 표현은 허용(MAY)됩니다.

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

​명세는 [BCP47]의 구식 버전을 참조해서는 안됩니다(MUST NOT), 예: [RFC1766] 또는 [RFC3066].

​구식 버전과의 호환성을 유지해야 하는 명세는 [BCP47]의 생성물인 obs-language-tag 생산 규칙을 참조해야 하며, 이는 반드시(MUST)입니다.

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

​URI에 언어 정보를 포함하는 애플리케이션(예: RDF 영역)은 [BCP47]을 사용하는 것이 권장됩니다(SHOULD).

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

Subtag. 하이픈 문자로 구분된 ASCII 문자 또는 숫자의 연속으로, 전체 언어 태그 내에서 특정 의미 요소를 식별합니다. [BCP47]에서 서브태그는 대소문자 ASCII 문자(대소문자 구분 없음) 또는 ASCII 숫자로 구성될 수 있으며, 서브태그 길이는 최대 8자(특정 서브태그 용도에 따라 추가 길이 제한이 적용될 수 있음)로 제한됩니다.

언어 태그에 기반하여 콘텐츠나 동작을 선택하려면 [BCP47] (그리고 [RFC4647])에서 정의하는 몇 가지 추가 개념이 필요합니다. 이 문서에서는 다음과 같이 BCP47에서 직접 채택한 용어를 사용합니다.

IANA Language Subtag Registry. IANA를 통해 제공되는 기계 판독 가능한 텍스트 파일로, 언어 태그에서 유효한 모든 서브태그의 포괄적 목록을 포함합니다. (링크: Registry)

​명세는 [BCP47]의 기여 표준들(예: ISO639, ISO15924, ISO3066, UN M.49)을 직접 참조해서는 안됩니다(권장되지 않음(SHOULD NOT)).

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

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

Well-formed language tag. [BCP47]에 정의된 문법을 따르는 언어 태그입니다. 즉, 규정된 길이의 ASCII 문자와 숫자 서브태그로 구성되고, 하이픈으로 구분되어 구조적으로 올바른 태그입니다.

Valid language tag. well-formed하며, 또한 [BCP47]의 추가 적합성 요구사항(특히 각 서브태그가 IANA Language Subtag Registry에 등재되어야 한다는 요구사항)을 만족하는 언어 태그입니다.

​언어 태그가 well-formed하도록 하는 것은 명세에서 권장(SHOULD)됩니다.

​명세는 언어 태그가 valid하도록 요구할 수 있습니다(선택 가능(MAY)).

​명세는 콘텐츠 작성자가 valid language tags를 사용하도록 요구하는 것이 권장(SHOULD)됩니다.

이는 구현체에 대해 권장되는 것보다 더 엄격한 요구사항입니다.

​콘텐츠 검증 도구는 가능한 경우 콘텐츠가 valid language tags를 사용했는지 검증하는 것이 권장(SHOULD)됩니다.

태그가 valid한지 확인하려면 레지스트리에 대한 접근 또는 복사본과 추가 런타임 로직이 필요합니다. 콘텐츠 작성자는 유효한 값만 선택·생성·교환하도록 권고되지만, 언어 태그 매칭 및 일반적인 언어 태그 연산은 유효성 검사가 없어도 동작하도록 설계되어 있습니다. 서브태그의 구체적 의미를 이해해야 하는 기능이나 동작이 있을 경우, 해당 명세는 프로토콜 또는 문서 형식의 일부로서 valid 태그를 규범적으로 요구할 수 있습니다.

Language tag extension 또는 extension. IANA에 등록된 단일 문자 또는 숫자 서브태그로 도입된 추가 [BCP47] 서브태그 체계로, 추가적인 유형의 언어 식별을 허용합니다.

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

특히 [RFC6067]는 BCP 47 Extension U("Unicode Locales"라고도 함)를 정의합니다. 이 확장은 특정 로케일 변형을 선택하기 위한 추가 서브태그 시퀀스를 제공합니다.

​명세는 언어 태그 길이를 제한하거나 확장(extension)의 제거를 허용하거나 권장해서는 안 됩니다(권장되지 않음(SHOULD NOT)).

Language range. 언어 태그와 유사한 구조의 문자열로, 특정 속성을 공유하는 언어 태그 집합을 식별하는 데 사용됩니다.

Language priority list. 하나 이상의 language ranges로 구성된 모음으로, 매칭에 사용되는 사용자의 언어 선호를 식별합니다. 이름에서 알 수 있듯이 이러한 목록은 일반적으로 사용자 선호도에 따라 정렬되거나 가중치가 부여됩니다. 앞서 언급한 HTTP의 Accept-Language 헤더([RFC2616], [RFC3282])는 언어 우선 목록의 한 예입니다.

Basic language range. 하이픈으로 구분된 서브태그 시퀀스로 구성된 language range로, 즉 언어 태그와 동일한 형태를 가집니다.

Extended language range. 하이픈으로 구분된 서브태그 시퀀스로 구성된 language range입니다. 확장된 언어 범위에서는 서브태그가 유효한 서브태그이거나 와일드카드 서브태그 *일 수 있으며, 이는 모든 값을 매칭합니다.

일부 언어 우선 목록은 앞서 언급한 Accept-Language 헤더와 같이 목록에 나타난 값에 대해 "가중치"를 제공합니다. 이러한 가중치는 목록의 정렬 목적 외에는 의존해서는 안 됩니다.

​언어 태그 매칭이나 언어 협상(language negotiation)을 정의하는 명세는 사용되는 언어 범위가 기본 언어 범위(basic)인지 또는 확장 언어 범위(extended)인지 명시해야 합니다(반드시(MUST)).

​언어 태그 매칭을 정의하는 명세는 매칭 연산의 결과가 단일 결과(lookup, [RFC4647]에서 정의됨)인지, 또는 (0개 이상의) 여러 결과의 집합(filtering, [RFC4647]에서 정의됨)인지 명시해야 합니다(반드시(MUST)).

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

예를 들어 JavaScript 국제화([ECMA-402])와 [CLDR]는 구현자가 조정할 수 있는 "best fit" 알고리즘을 제공합니다.

3. 로케일과 국제화

이 섹션은 국제화 및 지역화와 관련된 기본 용어를 정의합니다.

다양한 언어를 사용하거나 다양한 문화적 배경을 가진 사용자들은 보통 자신들의 모국어, 문자 체계, 측정 단위, 달력, 기타 언어적 규칙 및 문화적 관습에 맞게 정보가 올바르게 처리되는 소프트웨어와 서비스를 필요로 합니다.

언어 태그는 특정 콘텐츠나 사용자와 연결된 국제적 선호도 식별하는 데 사용할 수 있습니다. 이러한 선호는 최종 사용자의 자연어, 지역 연관성 또는 문화와 관련되어 있습니다. 이러한 선호는 숫자, 날짜, 시간의 표시, 리스트의 언어적 정렬, 달력이나 측정 단위와 같은 항목의 기본값 제공, 12시간/24시간 표시 선택 등 다양한 작업에 적용되며, 사용자가 직접 설정하기 번거로운 많은 세부 사항에서도 활용됩니다. 이러한 선호에 대한 식별자는 보통 로케일이라고 부릅니다. [BCP47]의 확장으로 정의된 유니코드 로케일(Unicode locales) [CLDR]은 웹의 국제화 API의 기반이 되며, 특히 JavaScript 언어 [ECMASCRIPT]은 유니코드 로케일을 [ECMA-402]에서 제공하는 API의 기반으로 사용합니다.

국제적 선호(International Preferences) 사용자의 언어, 서식, 관련 문화적 관습에 관한 선호 집합입니다. 소프트웨어는 이러한 선호를 사용하여 사용자와 교환하는 정보를 올바르게 처리하거나 표시할 수 있습니다.

웹에서는 다양한 국제적 선호 옵션을 제공함으로써 콘텐츠나 서비스가 세계 여러 사용자에게 적합하고 사용 가능하게 합니다. 이런 선호에는 다음과 같은 항목들이 포함될 수 있습니다:

• 텍스트 처리(분석, 맞춤법 검사, 문법 검사 등)를 위한 자연 언어;
• 사용자 인터페이스 언어(이미지, 색상, 소리, 형식, 탐색 요소, 그리고 화면에 보이는 텍스트 등 포함);
• 날짜, 시간, 숫자, 리스트 등 값의 표현(사람 친화적 포맷팅);
• 내용(예: 전화번호부나 사전)의 분류, 정렬, 조직화;
• 달력 및 시간(휴일, 근무 규칙, 평일/주말 구분, 월의 수 및 구성, 연도의 번호 체계 등 포함);
• 세금 또는 규제 체계;
• 통화

국제화(Internationalization) 서로 다른 문화, 지역, 언어를 대상으로 할 수 있도록 제품을 설계·개발하는 것. "Internationalization"은 영어 단어에서 "I"와 "N" 사이에 18글자가 있으므로 종종 i18n으로 약칭됩니다.

지역화(Localization) 특정 타겟시장이나 그룹의 개별 문화적 기대에 맞게 시스템을 맞추는 것. 지역화에는 주로 사용자에게 보여지는 텍스트와 메시지의 번역을 포함하지만, 이에 제한되지 않습니다. "Localization"은 "L"과 "N" 사이에 10글자가 있으므로 때때로 l10n으로 약칭합니다. 국제적 선호에 해당하는 특정 콘텐츠와 선호세트가 실제로 제공될 때 시스템이 지역화됨(localized)이라고 합니다.

로케일(Locale) 언어 태그와 같은, 한 세트의 국제적 선호를 식별하는 식별자입니다. 통상적으로 이 식별자는 사용자의 기본 언어를 나타내며, 때로는 지리적 영역(국가 등) 정보도 포함합니다. 로케일은 API에서 전달되거나 운영 환경에 설정되어 시스템이나 프로세스에서 문화적 영향을 받는 동작을 제공합니다.

로케일 인식(Locale-aware) (또는 Enabled), 로케일 변경에 문화 및 언어 특화된 동작이나 콘텐츠로 응답할 수 있는 시스템을 의미합니다. 일반적으로 국제화(Internationalization)된 시스템은 다양한 로케일을 지원하여 여러 유형 사용자의 국제적 선호를 충족시킵니다.

언어 태그는 서브태그를 사용해 언어, 문자, 지역, 특별 등록된 다양한 변형 정보 등을 제공할 수 있습니다. 하지만 때로는 이런 항목들과 직접 연관되지 않는 국제적 선호가 있습니다. 예를 들어, 많은 문화에서는 콘텐츠 정렬 방식을 여러 가지로 제공하며, 적합한 정렬 순서를 언어 태그만으로는 항상 유추할 수 없습니다. 따라서 독일어 사용자는 사전용 정렬과 전화번호부 정렬 중 하나를 선택하고 싶을 수 있습니다.

전통적으로 로케일은 사용자의 프로그래밍 언어나 운영 환경과 연관되어 있었습니다. 이러한 애플리케이션별 식별자는 종종 언어 태그에서 유추되거나 변환될 수 있었습니다. 자바의 java.util.Locale, POSIX(de_CH@utf8 같은 식별자), 오라클 데이터베이스(AMERICAN_AMERICA.AL32UTF8), 마이크로소프트의 LCID(예: 0x0409)와 같은 다양한 로케일 모델이 있습니다. 이들 모델, ISO639·ISO3166 등의 표준, 그리고 [RFC1766] 등 초창기 언어 태그 사이의 관계는 의도적이었습니다. 구현체들은 기존 프로토콜(예: HTTP의 Accept-Language 헤더)로부터 언어 태그를 자체 또는 플랫폼별 로케일 모델로 변환하거나 연결하곤 했습니다.

현행 [BCP47] 식별자 문법이 채택된 이후, 여러 로케일 모델은 BCP47을 직접 채택하거나 자체 모델과 언어 태그 간 변환을 제공하고 있습니다. 특히 오픈소스 로케일 데이터 저장소인 [CLDR]의 등장과 도입은 언어 태그를 로케일 식별자로 더 널리 사용하게 만들었습니다.

공통 로케일 데이터 저장소(Common Locale Data Repository) (또는 [CLDR])는 유니코드 컨소시엄이 주관하는 프로젝트로, 시스템이나 운영 환경에서 로케일을 지원하는 데 필요한 데이터 세트의 정의·수집·관리를 담당합니다. CLDR 데이터와 로케일 모델은 특히 브라우저에서 널리 채택되고 있습니다.

유니코드 로케일 식별자(Unicode Locale Identifier) 또는 유니코드 로케일. UTR#35 [LDML]에서 정의한 서브태그 선택의 추가 규칙 및 제한을 따르는 언어 태그입니다. 유효한 유니코드 로케일 식별자는 모두 유효(valid)한 [BCP47] 언어 태그이지만, 일부 유효한 언어 태그는 유니코드 로케일 식별자에 포함되지 않을 수 있습니다.

정규화 유니코드 로케일 식별자(Canonical Unicode locale identifier), [LDML]의 정규화 규칙을 적용한 유니코드 로케일 식별자의 well-formed language tag 버전입니다. 해당 과정에서는 유효한 [BCP47] 언어 태그를 모두 유효한 유니코드 로케일 식별자로 변환합니다. 예) 폐지된 서브태그나 비정형 grandfathered 태그는 IANA 언어 서브태그 레지스트리의 권장값으로 대체됩니다.

[CLDR]는 유니코드 로케일 식별자와 관련된 두 가지 언어 태그 확장(language tag extensions)을 정의하고 유지합니다([RFC6067] 및 [RFC6497]). 이 확장들은 언어 태그를 활용해 언어·지역 외의 국제적 선호 변형, 특정 포맷/콘텐츠 선택을 표현할 수 있게 해줍니다. 유니코드 로케일 식별자는 반드시 이 확장을 포함할 필요는 없으며, 특정 로케일에서 추가 맞춤화가 필요할 때에만 사용됩니다. CLDR은 로케일 식별자로 사용할 특정 서브태그 해석 규칙도 적용합니다. 자세한 내용은 [LDML]의 Section 3.2 를 참조하세요.

유니코드 로케일 언어 태그 확장 [RFC6067]은 -u- 서브태그를 사용하며, 다양한 로케일 기반 서식 및 동작 선택을 위한 서브태그를 제공합니다. 자세한 내용은 [LDML]의 Section 3.6을 참조하세요.

변환된 콘텐츠 언어 태그 확장 [RFC6497], -t- 서브태그를 사용하며, 스크립트 간 음역 등 텍스트 변환을 위한 서브태그를 제공합니다. 자세한 내용은 [LDML]의 Section 3.7을 참조하세요.

유니코드 로케일은 점차적으로 웹 국제화(internationalization)의 기반이 되고 있으며, 특히 JavaScript의 Intl 로케일 프레임워크인 [ECMA-402] 및 [ECMASCRIPT]에서도 마찬가지입니다.

​콘텐츠 작성자는 정규화 유니코드 로케일 식별자로 언어 태그를 선택하는 것이 권장(SHOULD)됩니다.

[LDML]의 Section 3에 명시된 추가 콘텐츠 제한과 정규화 단계는 [BCP47]만 사용하는 것보다 더 나은 상호운용성과 일관성을 제공합니다.

​구현체는 정규화 유니코드 로케일 식별자인 언어 태그만을 출력하고 소비하는 언어 태그도 정규화 규칙을 이용해 정규화 처리하는 것이 권장(SHOULD)됩니다.

위와 같이, Section 3의 추가 콘텐츠 제한과 정규화 단계는 [BCP47]만 사용하는 것보다 더 나은 상호운용성과 일관성을 제공합니다. 이 모범 사례는 구현체가 반드시 CLDR의 확장 중 하나를 지원, 생성, 처리, 이해해야 함을 의미하는 것은 아닙니다.

​콘텐츠 작성자는 특정 애플리케이션에서 추가 맞춤화가 요구되는 경우를 제외하고는 언어 태그 확장(language tag extensions)을 언어 태그에 포함해서는 안 됩니다(SHOULD NOT).

모든 유니코드 로케일 식별자가 동시에 [BCP47]의 well-formed 언어 태그임을 기억하세요. 유니코드 로케일 식별자에는 반드시 CLDR의 언어 태그 확장이 필요하지 않습니다.

비언어적 필드(Non-linguistic Field) 자연어 텍스트 데이터를 저장 또는 교환하는 용도가 아닌 데이터 구조의 요소입니다. 여기에는 부울, 숫자, 날짜 등 비문자열 타입뿐 아니라, 프로그램이나 프로토콜 내부 식별자와 같이 문자열이지만 텍스트 데이터가 아닌 항목도 포함합니다. 이 문서에서 필드(field)는 이 개념의 약어로 씁니다.

문서 형식이나 프로토콜 명세에서는 여러 데이터 값이나 데이터 구조의 교환, 처리, 표시 방식을 정의합니다. 웹은 데이터 직렬화와 교환을 주로 텍스트 파일로 처리하므로, 원시 바이트도 거의 항상 base64같은 문자열 직렬화로 전달됩니다. 따라서 웹의 비언어적 필드도 일반적으로 문자열로 구성됩니다. 여기서 중요한 구분은 비언어적 필드가 일반적으로 사용자보다는 내부 애플리케이션이 해석/처리함을 의미한다는 점입니다.

로케일 중립(Locale-neutral) 비언어적 필드가 특정 언어, 로케일, 문화에 특화된 저장 또는 교환 형식을 사용하지 않고, 언제든지 로케일 인식 방식으로 명확히 표시할 수 있도록 저장/교환되는 경우를 의미합니다.

많은 명세는 [XMLSCHEMA11-2] 또는 [JSON-LD]과 같이 비언어적 필드의 로케일 중립적 부호화 방식을 제공합니다.

로케일 중립적 표현도 특정 문화적 선호와 연결될 수 있으나, 이런 연결은 최소화해야 합니다. 예를 들어 ISO8601 날짜/시간 직렬화는 그레고리오 달력에 연결되어 있지만, 형식·필드 순서·구분자·시각적 모습 등은 모든 로케일에 적합하지 않고(기계 판독 목적임), 앞의 예시처럼 어떤 달력이나 로케일로 변환해 표시할 수 있습니다.

언어 협상(Language negotiation) 사용자의 국제적 선호와 사용 가능한 로케일, 지역화 리소스, 콘텐츠, 처리 방식 간의 매칭 과정입니다.

로케일 폴백(Locale fallback) 번역된 콘텐츠, 로케일 데이터 또는 기타 리소스를 보다 구체적인 리소스에서 보다 일반적인 리소스로 "폴백(falling back)"하여 결정적 패턴을 따라 검색하는 과정입니다.

사용자 선호는 보통 로케일 또는 로케일 우선순위 목록으로 표현됩니다. 언어 협상시 시스템은 사용 가능한 리소스 중 최적의 콘텐츠나 기능을 제공하기 위해 일종의 알고리즘을 따릅니다. 많은 경우 언어 협상 알고리즘은 로케일 폴백을 이용합니다.

​문서 형식에서 필드를 표시하는 명세는 해당 데이터가 주변 콘텐츠 언어에 맞게 서식화되도록 권장(SHOULD)해야 합니다.

사용자에게 비언어적 필드가 문서나 애플리케이션의 일부로 표현될 때, 문서나 애플리케이션이 데이터를 보는 "컨텍스트"가 됩니다. 콘텐츠 작성자나 애플리케이션 개발자는 필드가 자연스러운 사용 경험을 제공하며, 표시 방법을 제어할 수 있어야 합니다. 이는 콘텐츠가 나타나는 컨텍스트의 언어 태그로 결정되며, 보통 로케일 인식된 구현체는 해당 태그를 로케일로 해석하여 이를 달성합니다. 런타임 로케일이나 사용자 에이전트의 지역화를 비언어적 필드 표시의 로케일로 사용하는 것은 최후의 수단이어야 합니다.

​문서 형식이나 애플리케이션에서 비언어적 필드 입력/폼을 제공하는 명세는 그 값이 사용자가 보는 콘텐츠 또는 즉각 주변 마크업의 언어에 맞게 지역화(localized)되어야 함을 권장(SHOULD)해야 합니다.

​문서 형식이나 애플리케이션에서 비언어적 필드의 입력·교환·제공 시에는 로케일 중립 포맷을 반드시(MUST) 사용해야 합니다.

​구현체는 비언어적 필드를 문서 형식 또는 애플리케이션에서 주변 콘텐츠 언어에 맞는 포맷으로 권장(SHOULD) 표시해야 하며, 입력·편집 시 같은 로케일에 맞춰 지역화된 컨트롤도 제공하는 것이 좋습니다.

사용자는 문서나 애플리케이션에서 값이 나타나는 컨텍스트(문서 등)에 맞는 비언어적 필드의 표시를 기대합니다. 사용자는 입력값이 사용자 에이전트·운영체제 환경이 아닌 문서의 컨텍스트와 일치하기를 기대하며, 입력 검증·프롬프트·컨트롤 역시 콘텐츠와 일치합니다. 이렇게 하면 콘텐츠 작성자는 완전히 지역화된 사용자 경험을 설계할 수 있고 이는 일반적 사용자 기대에 부합합니다.

4. 추가 읽을거리

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

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

B. 감사의 글

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

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