정적 사이트의 국제화 및 현지화

국제화 및 현지화는 단순히 콘텐츠를 여러 언어로 작성하는 것 이상입니다. 보낼 현지화를 결정하는 전략과 이를 수행하는 코드가 필요합니다. 다른 언어뿐만 아니라 동일한 언어로 다른 지역을 지원할 수 있어야 합니다. UI는 화면 크기뿐만 아니라 다양한 언어와 쓰기 모드에 반응해야 합니다. 귀하의 콘텐츠는 UI의 마이크로카피와 날짜 형식에 이르기까지 구조화되어 어떤 언어에도 적용할 수 있어야 합니다. Eleventy와 같은 정적 사이트 생성기로 이 모든 작업을 수행하면 데이터베이스가 없지만 서버가 없을 수 있기 때문에 훨씬 더 어려워질 수 있습니다. 모든 것이 가능하지만 계획이 필요합니다.

chromeOS.dev를 빌드할 때 전 세계 사용자가 사용할 수 있도록 해야 한다는 것을 알고 있었습니다. 우리의 코드베이스가 각각을 사용자 정의 코딩할 필요 없이 여러 로케일(언어, 지역 또는 둘의 조합)을 지원할 수 있는지 확인하면서 가능한 한 해당 시스템의 지식으로 번역이 수행되도록 하는 것이 중요합니다. 이런 일이 일어납니다. 우리의 콘텐츠 제작자는 콘텐츠 제작에 집중할 수 있어야 했고 번역가는 콘텐츠 번역에 집중할 수 있어야 했습니다. 코드베이스를 국제화하고 사이트를 현지화하는 데 필요한 핵심은 때때로 상충되는 요구 사항을 바로 잡는 것입니다.

국제화(i18n)와 현지화(l10n)는 동전의 양면입니다. 국제화는 우리의 경우 엔지니어링 변경 없이 여러 언어 및 지역에 맞게 조정할 수 있도록 소프트웨어를 설계하는 방법에 관한 것입니다. 반면에 로컬라이제이션은 실제로 해당 언어와 지역에 맞게 소프트웨어를 조정하는 것입니다. 국제화는 전체 웹 사이트 스택에서 발생할 수 있습니다. HTML, CSS 및 JS에서 설계 고려 사항 및 시스템 구축에 이르기까지 현지화는 주로 콘텐츠 생성(긴 형식 복사 및 마이크로카피 모두) 및 관리에서 발생합니다.

참고 : 궁금한 분들을 위해 i18n과 l10n은 숫자로 알려진 약어 유형입니다. 접근성에 대한 A11y는 웹 개발에서 또 다른 일반적인 숫자입니다.

국제화(i18n)

국제화를 알아낼 때 일반적으로 고려해야 할 세 가지 항목이 있습니다. 사용자가 원하는 언어 및/또는 지역을 파악하는 방법, 선호하는 현지화로 콘텐츠를 얻는 방법, 적응하도록 사이트를 조정하는 방법 그 차이점. 구현 세부 사항은 동적 사이트(사용자가 요청할 때 페이지를 렌더링함)와 정적 사이트(배포되기 전에 페이지가 빌드됨)에 대해 변경될 수 있지만 핵심 개념은 동일하게 유지되어야 합니다.

사용자의 언어 및 지역 확인

국제화를 결정할 때 가장 먼저 고려해야 할 사항은 사용자가 현지화된 콘텐츠에 액세스하는 방법을 결정하는 것입니다. 이 결정은 다른 시스템을 설정하는 방법의 기초가 되므로 조기에 결정하고 사용자에게 절충안이 잘 작동하도록 하는 것이 중요합니다.

일반적으로 사용자에게 제공할 현지화를 결정하는 세 가지 높은 수준의 방법이 있습니다.

1. IP 주소의 위치
2. Accept-Language 헤더 또는 navigator.languages ​​;
3. URL의 식별자입니다.

많은 시스템은 어떤 현지화를 제공할지 결정할 때 하나, 둘 또는 세 가지 모두를 결합하게 됩니다. 하지만 조사하는 동안 IP 주소 및 Accept-Language 헤더 사용과 관련하여 고려 대상에서 제외할 만큼 충분히 중요하다고 생각되는 문제를 발견했습니다.

• 사용자가 선호하는 언어는 IP 주소가 제공하는 물리적 위치와 관련이 없는 경우가 많습니다. 예를 들어 누군가가 물리적으로 미국에 있다고 해서 영어 콘텐츠를 선호한다는 의미는 아닙니다.
• IP 주소의 위치 분석은 어렵고 일반적으로 신뢰할 수 없으며 검색 엔진에서 사이트를 크롤링하지 못할 수 있습니다.
• Accept-Language 헤더는 명시적으로 설정되지 않는 경우가 많으며 지역이 아닌 언어에 대한 정보만 제공합니다. 제한 사항으로 인해 언어에 대한 초기 추측을 설정하는 데 도움이 될 수 있지만 반드시 신뢰할 수 있는 것은 아닙니다.

이러한 이유로 우리는 사용자가 우리 사이트에 방문하기 전에 언어나 지역을 유추하지 않고 URL에 강력한 표시를 하는 것이 더 낫다고 결정했습니다. 강력한 지표를 사용하면 액세스 URL만으로도 원하는 언어로 사이트를 얻고 있다고 가정할 수 있고 리디렉션에 대한 걱정 없이 직접 현지화된 콘텐츠를 쉽게 공유할 수 있으며 깨끗한 방법을 제공합니다. 사용자가 선호하는 언어를 전환합니다.

식별자를 URL에 구축하기 위한 세 가지 일반적인 패턴이 있습니다.

1. 다른 도메인(일반적으로 다른 지역 및 언어에 대한 TLD 또는 하위 도메인(예: example.com 및 example.de , en.example.org 및 de.example.org ))을 제공합니다.
2. 콘텐츠에 대한 지역화된 하위 디렉터리가 있어야 합니다(예: example.com/en 및 example.com/de ).
3. URL 매개변수를 기반으로 현지화된 콘텐츠를 제공합니다(예: example.com?loc=en 및 example.com?loc=de ).

일반적으로 사용되는 URL 매개변수는 사용자가 현지화를 인식하기 어렵기 때문에 일반적으로 권장되지 않습니다(많은 분석 및 관리 문제와 함께). 우리는 또한 다른 도메인이 우리에게 좋은 솔루션이 아니라고 결정했습니다. 당사 사이트는 프로그레시브 웹 앱이며 TLD 및 하위 도메인을 포함한 모든 도메인은 다른 출처로 간주되어 각 현지화에 대해 별도의 PWA가 사실상 필요합니다.

필요에 따라 언어만( example.com/en ) 또는 언어 및 지역( example.com/en-US 및 example.com/en-GB )으로 현지화할 수 있는 보너스를 제공하는 하위 디렉토리를 사용하기로 결정했습니다. 단일 PWA 유지. 우리는 또한 사이트의 모든 현지화가 하위 디렉토리에 위치하여 한 언어가 다른 언어보다 높은 수준으로 올라가지 않도록 하고 하위 디렉토리를 제외한 모든 URL이 제작 언어를 기반으로 현지화 간에 동일하여 사용자가 쉽게 변경할 수 있도록 하기로 결정했습니다. URL을 번역할 필요 없이 현지화할 수 있습니다.

현지화된 콘텐츠 제공

사용자의 언어와 지역을 결정하기 위한 전략이 결정되면 올바른 콘텐츠를 안정적으로 제공할 방법이 필요합니다. 최소한 쿠키, 일부 로컬 저장소 또는 앱의 사용자 지정 논리의 일부에 저장된 정보의 일부 형태가 필요합니다. 사용자의 현지화 기본 설정을 유지할 수 있다는 것은 i18n 사용자 경험의 중요한 부분입니다. 사용자가 독일어로 된 콘텐츠를 원한다고 확인하고 영어 콘텐츠로 이동하는 경우 선호하는 언어를 식별하고 적절하게 리디렉션할 수 있어야 합니다. 이것은 서버에서 수행할 수 있지만 chromeOS.dev에 대해 사용한 솔루션은 호스팅 및 서버 설정에 구애받지 않습니다. 우리는 서비스 워커를 사용했습니다. 사용자의 여정은 다음과 같습니다.

• 사용자가 처음으로 당사 사이트를 방문합니다. 서비스 워커가 설치되지 않았습니다.
• 그들이 어떤 현지화를 시작하든 우리는 IndexedDB에서 선호하는 언어로 설정합니다. 이를 위해 우리는 그들이 소셜, 추천 또는 검색과 같은 어떤 수단을 통해 우리가 가지고 있지 않은 다른 현지화 컨텍스트를 기반으로 그들을 안내하는 어떤 수단을 통해 그곳에 도착했다고 가정합니다. 사용자가 현지화 설정 없이 방문하면 사이트의 기본 언어인 영어로 설정합니다. 또한 사용자가 언어를 변경할 수 있도록 바닥글에 언어 전환기가 있습니다. 이 시점에서 서비스 워커를 설치해야 합니다.
• 서비스 워커가 설치된 후 사이트 탐색을 위한 모든 URL 요청을 가로챕니다. 현지화는 하위 디렉토리를 기반으로 하기 때문에 어떤 현지화를 요청하는지 쉽게 식별할 수 있습니다. 식별되면 요청된 페이지가 현지화된 하위 디렉토리에 있는지 확인하고 현지화된 하위 디렉토리가 지원되는 현지화 목록에 있는지 확인하고 현지화된 하위 디렉토리가 IndexedDB에 저장된 기본 설정과 일치하는지 확인합니다. 현지화된 하위 디렉토리에 없거나 현지화된 하위 디렉토리가 기본 설정과 일치하는 경우 페이지를 제공합니다. 그렇지 않으면 올바른 현지화를 위해 서비스 작업자로부터 302 리디렉션을 수행합니다.

솔루션을 Workbox 플러그인인 Service Worker Internationalization Redirect에 번들로 묶었습니다. 기본 설정 하위 모듈과 함께 플러그인을 결합하여 Workbox의 registerRoute 메서드 및 request.mode === 'navigate' 에 대한 필터링 요청과 결합할 때 사용자의 언어 기본 설정을 설정 및 가져오고 리디렉션을 관리할 수 있습니다.

완전한 최소한의 예는 다음과 같습니다.

클라이언트 코드

 import { preferences } from 'service-worker-i18n-redirect/preferences'; window.addEventListener('DOMContentLoaded', async () => { const language = await preferences.get('lang'); if (language === undefined) { preferences.set('lang', lang.value); // Language determined from localization user landed on } });

서비스 워커 코드

 import { StaleWhileRevalidate } from 'workbox-strategies'; import { CacheableResponsePlugin } from 'workbox-cacheable-response'; import { i18nHandler } from 'service-worker-i18n-redirect'; import { preferences } from 'service-worker-i18n-redirect/preferences'; import { registerRoute } from 'workbox-routing'; // Create a caching strategy const htmlCachingStrategy = new StaleWhileRevalidate({ cacheName: 'pages-cache', plugins: [ new CacheableResponsePlugin({ statuses: [200], }), ], }); // Array of supported localizations const languages = ['en', 'es', 'fr', 'de', 'ko']; // Use it for navigations registerRoute( ({ request }) => request.mode === 'navigate', i18nHandler(languages, preferences, htmlCachingStrategy), );

클라이언트 측 코드와 서비스 작업자 코드의 조합을 사용하면 사용자가 사이트를 처음 방문할 때 선호하는 현지화가 자동으로 설정되고 선호하는 현지화에 없는 URL로 이동하는 경우 리디렉션되었습니다.

사이트 사용자 인터페이스 조정

사용자 인터페이스를 적절하게 조정하는 데 필요한 것이 많기 때문에 여기에서 모든 것을 다루지는 않겠지만 프로그래밍 방식으로 관리할 수 있고 관리해야 하는 몇 가지 미묘한 사항이 있습니다.

인용구 인용문

일반적인 디자인 패턴은 큰따옴표를 따옴표로 묶는 것입니다. 그러나 현지화에 따라 이러한 따옴표에 사용되는 것이 다르다는 것을 알고 계셨습니까? 하드 코딩하는 대신 open-quote 과 close-quote 을 사용하여 올바른 언어에 올바른 인용문이 사용되었는지 확인하십시오.

날짜 및 숫자 형식

날짜와 숫자 모두 현지화(언어 및/또는 지역)에 따라 형식을 지정할 수 있는 .toLocaleString 메서드가 있습니다. 이를 지원하는 브라우저는 모든 현지화를 사용할 수 있으므로 쉽게 사용할 수 있지만 Node.js는 그렇지 않습니다. 다행히 Node용 full-icu 모듈을 사용하면 사용 가능한 모든 현지화 데이터를 사용할 수 있습니다. 이렇게 하려면 모듈을 설치한 후 NODE_ICU_DATA 환경 변수를 모듈 경로로 설정하여 코드를 실행하십시오(예: NODE_ICU_DATA=node_modules/full-icu ).

HTML 메타 정보

HTML 태그와 헤더에는 현지화마다 업데이트해야 하는 세 가지 영역이 있습니다.

• 페이지의 언어,
• 쓰기 방향,
• 페이지에서 사용할 수 있는 대체 언어입니다.

각각 dir 및 lang 속성이 있는 html 요소에서 첫 번째로 이동합니다(예: 미국 영어의 경우 <html lang="en" dir-"ltr"> ). 이를 적절하게 설정하면 콘텐츠가 올바른 방향으로 흐르고 브라우저가 페이지의 언어를 이해할 수 있으므로 콘텐츠 번역과 같은 추가 기능을 사용할 수 있습니다. 또한 검색 엔진에 페이지가 완전히 번역되었음을 알리기 위해 rel="alternate" 링크를 포함해야 하므로 영어 방문 페이지에 <link href="/es" rel="alternate" hreflang="es"> 를 포함하면 검색 엔진에 이것이 조심해야 할 번역이 있음을 알리십시오.

본질적인 디자인

콘텐츠를 현지화하면 다양한 번역이 페이지에서 다양한 공간을 차지하므로 디자인 문제가 발생할 수 있습니다. 독일어와 같은 일부 언어에는 더 긴 수평 공간이 필요하거나 텍스트 줄 바꿈이 더 많이 필요한 긴 단어가 있습니다. 아랍어와 같은 다른 언어는 세로 공간이 더 필요한 키가 큰 서체를 사용합니다. 다행히도 간격과 레이아웃을 표시 영역 크기뿐만 아니라 콘텐츠에도 반응하도록 만드는 여러 CSS 도구가 있으므로 여러 언어에 더 잘 적응할 수 있습니다.

콘텐츠 작업을 위해 특별히 설계된 여러 CSS 단위가 있습니다. 계산된 글꼴 크기와 루트 글꼴 크기를 각각 나타내는 em 및 rem 단위가 있습니다. 이러한 단위의 고정 크기 px 값을 바꾸면 사이트가 콘텐츠에 더 잘 반응하도록 만들 수 있습니다. 그런 다음 글꼴에서 0(영) 글리프의 인라인 크기를 나타내는 ch 단위가 있습니다. 이를 통해 width 와 같은 것을 포함하는 콘텐츠에 직접 연결할 수 있습니다.

그런 다음 이러한 단위를 레이아웃을 위한 기존의 강력한 CSS 도구, 특히 flexbox 및 grid와 결합하여 크기에 맞게 구성 요소를 조정하고 레이아웃을 콘텐츠에 맞게 조정할 수 있습니다. 물리적 물리적 속성 대신 테두리, 여백 및 패딩에 대한 논리적 속성을 가진 항목을 강화하면 해당 레이아웃과 구성 요소도 쓰기 모드에 자동으로 적응합니다. 본질적인 웹 디자인의 힘(Jen Simmons가 만든 콘텐츠 인식 장치 및 논리적 속성을 통해 인터페이스를 설계 및 구축할 수 있으므로 화면 크기뿐 아니라 모든 언어에 적용할 수 있습니다.

현지화(l10n)

현지화에서 가장 분명한 형태는 콘텐츠를 한 언어에서 다른 언어로 번역하는 것입니다. 보다 미묘한 형태의 번역은 언어뿐만 아니라 지역별로 발생합니다. 예를 들어 미국에서 사용되는 영어와 영국, 남아프리카 또는 호주에서 사용되는 영어와 같이 사용됩니다. 여기에서 성공하려면 번역할 내용과 번역을 위해 콘텐츠를 구성하는 방법을 이해하는 것이 성공에 매우 중요합니다.

콘텐츠 전략

소프트웨어 프로젝트에는 현지화에 중요한 부분이 있고 그렇지 않은 부분이 있습니다. CSS 클래스 이름, JavaScript 변수 및 구조적이지만 사용자에게 표시되지 않는 코드베이스의 기타 위치는 아마도 현지화할 필요가 없을 것입니다. 현지화해야 할 사항과 구조화 방법을 파악하는 것은 콘텐츠 전략으로 귀결됩니다.

콘텐츠 전략은 많은 정의가 있지만 여기서는 콘텐츠의 구조, 마이크로카피(특정 콘텐츠에 얽매이지 않고 프로젝트 전반에 걸쳐 사용되는 단어 및 구문) 및 이들의 연결을 의미합니다. 콘텐츠 전략에 대한 자세한 내용은 Karen McGrane의 Content Strategy for Mobile과 Carrie Hane과 Mike Atherton의 Designing Connected Content를 추천합니다.

chromeOS.dev의 경우 콘텐츠 구조를 설명하는 콘텐츠 모델을 코딩했습니다. 콘텐츠 모델은 기사 형식의 긴 콘텐츠만을 위한 것이 아닙니다. 콘텐츠 모델은 작성자, 문서 또는 재사용 가능한 미디어 자산과 같이 사용자가 특별히 원하는 모든 엔터티에 대해 존재해야 합니다. 좋은 콘텐츠 모델에는 개별적으로 주소 지정이 가능한 조각 또는 더 큰 개념 조각의 청크가 포함되지만 접선적으로 관련되거나 다른 콘텐츠 모델에서 참조할 수 있는 청크는 제외됩니다. 예를 들어 블로그 게시물의 콘텐츠 모델에는 제목, 태그 배열, 작성자에 대한 참조, 게시 날짜 및 게시물 본문이 포함될 수 있지만 이동 경로에 대한 문자열은 포함되어서는 안 됩니다. 저자의 이름과 사진은 고유한 콘텐츠 모델이어야 합니다. 콘텐츠 모델은 현지화에서 현지화로 변경되지 않습니다. 그들은 사이트 구조입니다. 콘텐츠 모델의 인스턴스는 현지화에 연결되며 해당 인스턴스는 현지화될 수 있습니다.

하지만 콘텐츠 모델은 현지화해야 하는 부분만 다룹니다. "자세히 보기" 버튼, "메뉴" 제목, 면책 조항 텍스트 등 나머지는 모두 마이크로카피입니다. 현미경도 구조가 필요합니다. 특히 템플릿 기반 사이트의 경우 콘텐츠 모델을 만드는 것이 자연스럽게 느껴질 수 있지만 마이크로카피 모델은 덜 명확하고 템플릿에 직접 필요한 것을 작성하여 실수로 간과하는 경우가 많습니다.

콘텐츠 및 마이크로카피 모델을 구축하고 콘텐츠 관리 시스템, 린트 또는 검토를 통해 적용함으로써 로컬라이제이션이 로컬라이제이션에 집중할 수 있도록 할 수 있습니다.

키가 아닌 값 현지화

콘텐츠 및 마이크로카피 모델은 일반적으로 코드베이스의 객체와 유사한 구조를 생성합니다. 데이터베이스 항목, JSON 개체, YAML 또는 Front Matter가 될 수 있습니다. 개체 키를 현지화하지 마십시오! 검색 텍스트 마이크로카피가 microcopy.search.text 의 마이크로카피 개체에 있는 경우 microcopy 의 microcopie.chercher.texte microcopie 개체에 넣지 마세요. 모듈의 키는 재사용 가능한 템플릿에서 안정적으로 사용되고 코드베이스 전체에서 신뢰할 수 있도록 현지화에 구애받지 않는 식별자로 처리되어야 합니다. 이것은 또한 개체 키가 최종 사용자에게 콘텐츠나 마이크로카피로 표시되어서는 안 된다는 것을 의미합니다.

정적 사이트 설정

chromeOS.dev의 경우 Nunjucks와 함께 Eleventy(11ty)를 정적 사이트 생성기로 사용했지만 정적 사이트 생성기를 설정하기 위한 이러한 권장 사항은 대부분의 정적 사이트 생성기에 적용할 수 있습니다. 특정 항목이 있는 경우 해당 항목이 호출됩니다.

폴더 구조

폴더 구조를 기반으로 컴파일하는 정적 사이트 생성기는 하위 디렉토리 i18n 방법을 지원하는 데 특히 좋습니다. 11ty는 글로벌 데이터가 포함된 데이터 캐스케이드와 페이지 매김을 통해 데이터에서 페이지를 생성하는 수단도 지원하므로 이 세 가지 개념을 결합하면 다음과 같은 기본 폴더 구조가 생성됩니다.

 . └── pages ├── _data ├── _generated └── {{locale-code}} ├── {{locale-code}}.11tydata.js ├── _data └── [...content]

최상위 수준에는 pages 라고 하는 사이트의 페이지를 보관하는 디렉토리가 있습니다. 내부에는 전역 데이터 파일이 포함된 _data 폴더가 있습니다. 이 폴더는 다음에 도우미에 대해 이야기할 때 중요합니다. 그런 다음 _generated 폴더가 있습니다. 자체 콘텐츠 대신 기존 콘텐츠, 소량의 마이크로카피 또는 이 둘의 조합에서 생성된 여러 페이지가 있습니다. 홈 페이지, 검색 페이지 또는 블로그 섹션의 방문 페이지를 생각해 보십시오. 이러한 페이지는 고도로 템플릿화되어 있으므로 각각에 대해 개별 HTML 또는 Markdown 파일을 사용하는 대신 _generated 폴더에 템플릿을 저장하고 거기에서 빌드합니다. 이러한 폴더는 바로 아래에 페이지를 출력하지 않고 다른 곳에서 페이지를 생성하는 데 사용됨을 나타내기 위해 밑줄이 접두사로 붙습니다.

다음은 l10n 하위 디렉토리입니다! 각 디렉토리는 포함된 현지화에 대한 BCP47 언어 태그(일반적으로 로케일 코드)에 따라 이름을 지정해야 합니다. 예를 들어 영어는 en , 미국 영어는 en-US 입니다. chromeOS.dev 코드베이스에서 우리는 이것을 종종 locales 라고 부릅니다. 이러한 폴더는 현지화 하위 디렉토리가 되어 컨텐츠를 현지화로 분할합니다. 11ty의 데이터 캐스케이드를 사용하면 파일이 디렉토리의 루트에 있고 디렉토리와 이름이 같은 경우(디렉토리 데이터 파일이라고 함) 디렉토리의 모든 파일과 그 하위 파일에서 데이터를 사용할 수 있습니다. 11ty는 이 파일에서 반환된 개체 또는 개체를 반환하는 함수를 사용하여 템플릿에 사용할 수 있는 변수에 삽입하므로 해당 지역화의 모든 내용에 대한 데이터에 액세스할 수 있습니다.

이러한 파일의 유지 관리를 돕기 위해 정적 사이트 스캐폴딩의 일부인 l10n-data 라는 도우미를 작성했습니다. 이 도우미는 이 폴더 구조를 활용하여 지역화된 데이터의 캐스케이드를 구축하여 데이터를 부분적으로 지역화할 수 있습니다. 로케일별 데이터 디렉토리, _data 디렉토리에 데이터를 저장하여 이를 수행합니다(디렉토리 데이터 파일로 로드됨). 예를 들어, 영어 로케일 데이터 디렉토리를 보면 언어 코드와 쓰기 방향을 정의하는 locale.json 과 같은 마이크로 newsletter.yml 모델을 볼 수 있습니다. 이 모델은 HTML로 렌더링됩니다. 뉴스레터 가입, 그리고 보다 구체적인 파일에 맞지 않는 사이트 전체의 여러 위치에서 사용되는 일반 마이크로카피를 포함하는 microcopy.yml 파일. 이 마이크로카피가 사용되는 모든 곳에서 우리는 사용할 템플릿에 데이터 변수를 110개 삽입하여 사용할 수 있는 이 데이터에서 가져옵니다.

Microcopy는 관리하기 가장 어려운 경향이 있는 반면 나머지 콘텐츠는 대부분 간단합니다. 콘텐츠(종종 마크다운 파일 또는 HTML)를 현지화된 하위 폴더에 넣습니다. 폴더 구조에서 작동하는 정적 사이트 생성기의 경우 콘텐츠의 파일 이름과 폴더 구조는 일반적으로 해당 콘텐츠의 최종 URL에 1:1로 매핑되므로 en/web/pwas.md 의 Markdown 파일은 URL로 출력됩니다. en/web/pwa . 지역화의 "값이 아니라 값" 원칙에 따라 콘텐츠 파일 이름(및 따라서 경로)을 지역화하지 않기로 결정하여 로케일 전반에 걸쳐 동일한 파일의 지역화 상태를 추적하고 사용자가 알 수 있습니다. 그들은 서로 다른 로케일 사이의 올바른 페이지에 있습니다.

I18n 도우미

콘텐츠와 마이크로카피 외에도 우리는 현지화된 콘텐츠로 더 쉽게 작업할 수 있도록 여러 도우미 모듈을 작성해야 한다는 것을 알게 되었습니다. 11ty에는 콘텐츠가 렌더링되기 전에 수정할 수 있도록 하는 필터라는 개념이 있습니다. 우리는 i18n 템플릿을 돕기 위해 그 중 4개를 구축했습니다.

첫 번째는 날짜 필터입니다. 우리는 대부분 YAML로 작성하고 전체 UTC 타임스탬프로 템플릿에서 사용할 수 있기 때문에 콘텐츠의 모든 날짜를 YAML 날짜 값으로 작성하도록 표준화했습니다. full-icu 모듈 및 구성을 사용할 때 날짜 문자열(변경되는 내용)은 렌더링되는 내용의 로케일 코드와 함께 Date.toLocaleString (선택적 형식 지정 옵션 포함)으로 직접 전달되어 현지화된 날짜를 렌더링할 수 있습니다. Date.toLocaleDateString 은 전체 지역화된 날짜 및 시간 대신에 형식 지정 옵션이 전달되지 않을 때 날짜 부분만 원하는 경우 선택적으로 대신 사용할 수 있습니다.

두 번째 필터는 우리가 localURL 이라고 부르는 것입니다. 이것은 로컬 URL(변경되는 내용)과 URL이 있어야 하는 로케일을 가져와서 교환합니다. 예를 들어 /en/linux 를 /es/linux 로 변경합니다.

마지막 두 필터는 로케일 코드에서만 현지화된 정보를 검색하는 것입니다. 세 번째는 iso-639-10 모듈을 활용하여 로케일 코드를 모국어의 언어 이름으로 변환합니다. 이것은 주로 언어 선택기에 사용합니다. 네 번째는 iso-i18n-countries 모듈을 사용하여 해당 언어로 된 국가 목록을 검색합니다. 이것은 주로 국가 목록이 있는 양식을 작성하는 데 사용합니다.

필터 외에도 11ty에는 콘텐츠를 그룹화하는 컬렉션이라는 개념이 있습니다. 11ty는 기본적으로 여러 컬렉션을 사용할 수 있도록 하며 태그로 컬렉션을 만들 수도 있습니다. 다국어 사이트에서 우리는 사용자 지정 컬렉션을 만들고 싶다는 것을 알았습니다. 우리는 현지화를 기반으로 컬렉션을 구축하기 위해 여러 도우미 함수를 구축했습니다. 이를 통해 사이트의 모든 콘텐츠에 대해 템플릿을 필터링할 필요 없이 위치별 태그 컬렉션 또는 사이트 섹션 컬렉션을 갖는 것과 같은 작업을 수행할 수 있습니다.

우리의 마지막이자 가장 중요한 도우미는 사이트 글로벌 데이터였습니다. 로케일 코드 기반 하위 디렉토리 구조에 의존하는 이 기능은 사이트가 지원하는 현지화를 동적으로 결정합니다. {{locale-code}}.11tydata.js 의 모든 마이크로카피 및 현지화 관련 콘텐츠를 포함하는 l10n 속성을 포함하는 전역 변수 site 를 빌드합니다. 또한 사용 가능한 모든 로케일을 배열로 나열하는 languages 속성도 포함합니다. 마지막으로 이 함수는 사이트에서 지원하는 언어를 자세히 설명하는 JavaScript 파일과 {{locale-code}}.11tydata.js 각 항목에 대한 개별 파일을 출력합니다. 이 파일은 모두 당사 브라우저 스크립트에서 가져오도록 설계되었습니다. 이 파일의 무거운 짐은 우리가 이미 필요로 하는 현지화 정보인 단일 소스를 사용하여 정적 사이트를 프론트 엔드 JavaScript에 연결합니다. 또한 site.l10n 을 반복하여 현지화를 기반으로 페이지를 프로그래밍 방식으로 생성할 수 있습니다. 이를 현지화별 컬렉션과 결합하여 11ty의 페이지 매김을 사용하여 각각에 대해 별도의 HTML 페이지를 유지 관리하지 않고도 현지화된 홈 및 뉴스 방문 페이지를 만들 수 있습니다.

결론

국제화 및 현지화를 올바르게 수행하는 것은 어려울 수 있습니다. 다양한 전략이 복잡성에 미치는 영향을 이해하는 것이 더 쉽게 만드는 데 중요합니다. 정적 사이트, 하위 디렉토리에 자연스럽게 맞는 i18n 전략을 선택한 다음 생성 중인 콘텐츠에서 i18n 및 i10n의 일부를 자동화하는 도구를 구축하십시오. 강력한 콘텐츠 및 마이크로카피 모델을 구축합니다. 서버에 구애받지 않는 현지화를 위해 서비스 작업자를 활용합니다. 화면 크기뿐만 아니라 콘텐츠에도 반응하는 디자인으로 모든 것을 하나로 묶으십시오. 결국 모든 로케일의 사용자가 좋아할 사이트를 갖게 되며 작성자와 번역가는 마치 단순한 단일 로케일 사이트인 것처럼 유지 관리할 수 있습니다.