소프트웨어 국제화를 지원하기 위해 많은 프로그래밍 언어 및 플랫폼이 사용자에게 표시되는 UI에서 사용할 현지화 된 리소스 (예 : Java의 java.util.ResourceBundle 클래스)를 얻는 방법을 지원합니다. 종종 사용자가 선호하는 로케일에 대한 리소스를 사용할 수없는 경우 사용 가능한 리소스 세트에서 가장 가까운 리소스를 찾으려는 대체 메커니즘 또는 로캘 분석 프로세스가 있습니다. 예를 들어 en-US의 리소스를 사용할 수없는 경우 일반적으로 시스템에서 en의 리소스를 찾으려고 시도합니다.로캘 확인을위한 표준 알고리즘이 있습니까?
로캘 확인 프로세스는 많은 언어 및 플랫폼의 리소스 번들 솔루션에서 거의 동일하게 보입니다. 표준 로케일 분석 알고리즘을 따르고 있습니까? 그렇지 않은 경우 이러한 표준이 있습니까?
본인은 표준 자체를 알지 못합니다.
그러나 사용되는 알고리즘은 로캘이 계층 적이라는 사실로 인해 드뭅니다. 이름이없는 (개념상의) 루트 로켈이 있습니다. 그 아래에는 언어 전용 로케일 (en, fr 등)이 있습니다. 그 아래에는 국가 로캘 (en_GB, en_US 등)이 있습니다. 그 아래에는 선택적으로 변형 로케일 (en_GB_Yorkshire, en_GB_cockney 등 - 실제적인 예는 노르웨이 참조)이 있습니다.
적절한 자원을 찾는 자연스러운 방법은 할 수있는 가장 낮은, 가장 구체적인 로케일로 시작하여 뭔가를 찾을 때까지 나무 위로 올라가는 것입니다. 따라서 en_US_TX로 시작하여 en_US, en, 그리고 루트로 이동합니다.
대부분의 경우 응용 프로그램 작성자가 계층 구조를 제공하도록 리소스를 제공하지만 응용 프로그램이 'de'(기본값) 및 ' en-GB'. 사용자의 로케일이'en-US'이면 엄밀히 말하면 계층적인 해상도는'de'가됩니다. 이 경우 계층 구조에서 옆으로 움직이는 것이 더 바람직 할 것입니다. 또한 한 언어에 대한 리소스를 사용할 수없는 경우 가장 가까운 항목이 유사한 언어 여야합니다 (예 : 우크라이나어 리소스가 기본 영어 리소스가 아닌 러시아 리소스를 반환 할 수 없음). –
이 경우, 엄격하게 계층 적으로 해석하면 아무 것도 발견되지 않습니다. en_GB가 en_US와 일치하지 않습니다. 당신이 제안한 옆으로 움직이는 두 가지 모두 나에게 나쁜 생각처럼 보입니다. 당신은 로케일을 적절히 지원해야하거나 전혀 지원해서는 안됩니다. 따라서 사용자가 자신의 지역을 선택할 수 있도록하는 것이 중요합니다. 우크라이나 인은 러시아어를 선택할 수 있지만 러시아어를 가장 적합하다고 생각할 수 있습니다. –
문제의 로케일과 몇 개의 기존 알려진 로케일에 대해 JDK 7의 로케일 해결 코드를 재사용하는 방법은 무엇입니까? – curious1
사용자가 선호하는 언어 목록을 지정하는 "언어 범위"의 구문과 비교 및 일치를위한 "필터링"및 "조회"메커니즘을 설명하는 RFC 4647의 언어 태그 일치가 분명히 있습니다. 언어 범위는 RFC 4646 언어 태그로 제한됩니다. 조회가 하나의 언어 태그를 생산하는 반면,
필터링 언어 태그의 (잠재적 빈) 세트를 생성 : RFC 4647는 이러한 메커니즘을 설명합니다.
CLDR - Unicode Common Locale Data Repository에는 language distance을 기반으로 제안 된 알고리즘 (2015 년 기준)이 있습니다. 거리 데이터가 없으면 이것은 해결책이 아니지만 향후 솔루션을 볼 가치가 있습니다.
이러한 기능을 설계하는 전문가 (i18n 전문가)는 모범 사례를 따릅니다. 영토 (~ 국가)와 언어에 대해 알고있을 때 모범 사례가 어느 정도 명백해질 것입니다. Tom이 설명하는 쉬운 fall back 메커니즘은 Java 6의 일부였습니다. 이제 Java 7 및 BCP 47은 더욱 복잡합니다. 예를 들어 중국어를 참조하십시오 (zh-SG & zh-CN => zh-Hans, TW, zh-HK, zh-MO => zh-Hant). BTW. 언어 태그를 사용하고 있음을 주목하십시오 ... –