Angular i18n: 빌드 타임 대 런타임 설명

Angular의 국제화는 빌드 시점 또는 런타임 시점이라는 두 가지 모델을 따를 수 있습니다. 공식적인 접근 방식은 @angular/localize, 이는 각 언어별로 별도의 빌드를 생성합니다. 이 구성은 실행 시 안정적이고 빠르지만, 여러 번의 배포를 미리 계획해야 하며 앱 내에서 언어를 전환할 수는 없습니다.

이를 구현하려면 템플릿과 TypeScript에서 텍스트를 지정하고, 번역 내용을 별도의 파일로 추출한 다음, 로케일별로 앱의 버전을 하나씩 빌드합니다. 각 언어는 별도의 URL을 통해 제공되므로, 사용자는 앱 내부의 토글 버튼이 아닌 탐색 기능을 통해 언어를 전환합니다.

재로드 없이 동적으로 전환해야 하는 경우, 런타임 라이브러리가 이를 처리해 줍니다. 널리 사용되는 옵션으로는 ngx-translate와 angular-i18next가 있습니다. 이 라이브러리들은 필요에 따라 번역 내용을 불러오고 UI를 즉시 업데이트하며, 설정, 성능, SSR 지원 측면에서 각기 다른 장단점을 가지고 있습니다.

이 글에서는 Angular의 내장 국제화(i18n) 워크플로가 어떻게 작동하는지, 이를 배포하는 방법, 그리고 런타임 라이브러리가 더 적합한 경우는 언제인지에 대해 설명합니다.

어떻게 @angular/localize 작품

Angular의 내장 국제화 기능은 빌드 시점 워크플로를 사용합니다. 배포 전에 번역 내용을 미리 준비한 다음, 언어별로 앱의 컴파일된 버전을 하나씩 배포합니다.

실행 시 언어 전환 기능이 없으므로, 설정은 주로 추출 및 빌드 구성에 중점을 둡니다.

전체 워크플로를 한 번 살펴보겠습니다:

1. 템플릿과 TypeScript에서 번역할 텍스트를 지정합니다. HTML 콘텐츠 및 속성의 경우 i18n 속성을 사용하고, $localize TypeScript에서는 문자열도 동일한 추출 과정에 포함됩니다.
2. Angular CLI를 사용하여 메시지를 번역 파일로 추출합니다. 이 과정에서는 기본적으로 XLIFF 파일이 생성되며, 설정에 따라 다른 형식을 선택할 수도 있습니다. 이 파일에는 메시지 ID와 원문이 포함됩니다.
3. 추출된 파일을 번역하고 식별자는 일관되게 유지하십시오. 원문 텍스트가 업데이트되어도 기존 번역에 문제가 생기거나 눈에 띄지 않는 불일치가 발생하지 않도록, 필요한 곳에 사용자 정의 ID를 추가하십시오.
4. 로케일별로 앱의 단일 버전을 빌드하고 배포합니다. angular.json에서 로케일을 설정한 다음, 별도의 경로나 도메인을 통해 제공되는 언어별 번들을 생성합니다.

복수형 변환에는 ICU 표현식이 사용됩니다. 다음과 같은 경우를 정의할 수 있습니다. =0, =1, 또는 기타, 그리고 Angular는 현재 설정된 로케일에 따라 올바른 양식을 선택합니다. 언어마다 필요한 양식의 수가 다르므로, 메시지 구조를 미리 계획해 두어야 합니다.

중첩된 ICU 표현식은 동일한 패턴을 따르지만 복잡성이 높아지므로, 가독성을 유지하고 다양한 로케일에서 테스트해야 합니다.

다중 로케일 Angular 앱 구축 및 배포

Angular의 빌드 시점 i18n을 사용하면 배포는 angular.json의 구성 방식과 직접적으로 연동됩니다. 소스 로케일과 일련의 대상 로케일을 정의하고, 각 로케일을 번역 파일에 매핑합니다.

빌드 과정에서 Angular는 앱을 한 번 컴파일한 다음, 후처리 단계에서 현지화된 내용을 대체합니다. 즉, 언어별로 전체 빌드를 실행하는 것은 아니지만, 결과적으로는 각 로케일별로 별도의 출력 번들이 생성됩니다.

각 지역별 버전은 해당 지역의 앱 버전을 생성하며, 대개 하위 경로나 도메인을 통해 제공됩니다. 일반적인 설정에서는 다음과 같은 경로를 사용합니다. /en/ 그리고 /fr/, 각각은 해당 빌드 결과물을 가리킵니다. 번역된 콘텐츠가 파일에 직접 포함되기 때문에, 언어를 변경하려면 다른 빌드를 불러와야 하므로 이러한 구조가 필요합니다.

서버 구성은 i18n 설정의 일부가 됩니다. 들어오는 요청을 올바른 로케일 버전에 매핑하는 라우팅 규칙이 필요합니다.

구현 방식은 환경에 따라 크게 달라집니다. Nginx의 경우 원시 재작성 규칙을 사용하는 반면, Firebase Hosting에서는 몇 줄의 선언적 코드만으로도 충분하지만, 목표는 동일합니다. 요청은 URL 구조나 리디렉션 로직에 따라 올바른 현지화 번들로 처리되어야 합니다.

Angular는 서버 측 렌더링을 사용할 때 자동 언어 감지 기능도 지원합니다. 서버는 브라우저의 Accept-Language 헤더를 설정한 다음, 사용자를 해당 로케일 경로로 리디렉션합니다. 이렇게 하면 첫 방문 시 사용자 경험이 개선되지만, 나중에 언어를 변경할 때는 여전히 전체 페이지가 다시 로드됩니다.

개발 단계에서 Angular 개발 서버는 하위 경로를 사용하여 여러 로케일을 제공할 수 있습니다. 이는 테스트에 도움이 되지만, 각 로케일은 별도의 빌드 출력물이기 때문에 언어를 전환할 때마다 페이지를 새로 고쳐야 합니다.

이 모델은 인프라 측면에서 분명한 시사점을 제공합니다. 여러 빌드 아티팩트를 관리하고, 각 로케일에 대한 라우팅을 구성하며, 서버 수준에서 리디렉션을 처리해야 합니다. CI 파이프라인은 번역 업데이트를 반영해야 하며, 콘텐츠가 변경될 경우 현지화된 출력을 다시 빌드해야 합니다.

이러한 복잡성을 피할 수 있는 또 다른 방법이 있습니다. Weglot같은 리버스 프록시 모델은 서버와 브라우저 사이에 위치합니다. 이 모델은 콘텐츠를 실시간으로 번역하며, 단일 배포 환경에서 모든 언어 버전을 제공합니다. 이를 통해 여러 번의 빌드 과정과 라우팅 규칙이 필요 없어집니다. Weglot 대해서는 Weglot 더 자세히 다루겠습니다!

런타임 라이브러리 비교: ngx-translate, Transloco, angular-i18next

런타임 라이브러리는 Angular의 내장 i18n과는 다른 문제를 해결합니다. 번역 내용을 앱에 컴파일하는 대신, 런타임에 이를 불러와 전체 재로딩 없이 UI를 업데이트합니다.

따라서 사용자가 앱 내에서 언어를 전환해야 하거나 콘텐츠가 자주 변경될 때 이 방식이 더 적합합니다.

ngx-translate 가장 널리 사용되는 옵션입니다. 이 옵션은 다음을 통해 즉각적인 언어 전환을 지원합니다. trans.use(), JSON 파일이나 API에서 번역을 불러옵니다. 소규모 앱에서는 잘 작동하며, 여기에서 유일하게 검증된 이온성 호환성. SSR은 다음과 함께 사용할 수 있습니다. 상태전환 그리고 사용자 정의 로더도 지원하지만, 설정이 필요합니다. 최근 버전에서는 독립형 컴포넌트와 더 잘 어울리는 프로바이더 기반 API가 추가되었습니다.

트랜스로코 구조와 확장성에 중점을 둡니다. 내장된 SSR 지원을 제공하며, `ng add`를 통해 더 깔끔하게 설정할 수 있습니다. 또한 범위 지정 번역 기능을 지원하여, 기능별로 언어 파일을 지연 로드할 수 있습니다. 이를 통해 번들 크기를 줄이고 대규모 앱의 유지보수성을 높일 수 있습니다. 언어 전환은 setActiveLang() 그리고 UI를 즉시 업데이트합니다.

angular-i18next는 i18next 생태계를 감싸는 라이브러리입니다. 팀에서 이미 다른 프레임워크에서 i18next를 사용하고 있으며 프로젝트 전반에 걸쳐 일관성을 유지하고 싶은 경우 유용합니다. 이 라이브러리는 ICU 처리를 포함하여 i18next 코어의 플러그인을 지원합니다. 언어 전환 시 일반적으로 페이지를 다시 불러와야 하므로, 즉각적인 업데이트가 필요한 앱에서는 사용이 제한될 수 있습니다.

좀 더 직접적인 비교를 해보자면:

선택은 앱이 언어 변경 및 확장성을 어떻게 처리하는지에 따라 달라집니다:

• 간단한 설정이나 Ionic 지원이 필요하다면 ngx-translate를 사용하세요.
• 모듈식 번역 기능이 필요한 SSR 또는 대규모 앱의 경우 Transloco를 사용하세요.
• 여러 플랫폼에서 i18next와 호환성을 유지하려면 angular-i18next를 사용하세요.

💡 런타임 전환이 필요하지 않고 클라이언트 측 로직을 최소화하고 싶다면, Angular의 내장 i18n 기능이 여전히 더 나은 선택입니다.

코드 변경 없이 Angular 앱 번역하기

Angular의 내장 i18n 및 런타임 라이브러리 외에도 세 번째 옵션이 있는데, 바로 외부 웹사이트 번역 도구입니다. 이러한 도구는 Angular 앱 외부에서 작동하며, 코드베이스 내의 문자열이 아닌 렌더링된 출력을 번역합니다.

앞서 언급했듯이, Weglot 리버스 프록시 모델을 Weglot . Weglot은 서버와 브라우저 사이에 위치하여 HTML 응답을 감지한 후, 방문자에게 번역된 버전을 제공합니다. 즉, 문자열에 i18n 태그를 지정하거나 JSON 번역 파일을 관리할 필요가 없으며, 각 로케일에 맞춰 앱을 다시 빌드할 필요도 없습니다. 번역 계층이 Angular 외부에서 처리되므로 설정 과정이 더 빠릅니다.

이러한 접근 방식은 번역 작업이 이루어지는 방식도 변화시킵니다. 번역가들은 프로젝트 내 파일을 편집하는 대신 시각적인 대시보드를 사용합니다. 이를 통해 템플릿이나 TypeScript를 직접 건드리지 않고도 페이지를 검토하고 용어집 규칙을 적용할 수 있습니다. 콘텐츠가 많은 마케팅 사이트의 경우, 이를 통해 개발자의 개입을 줄일 수 있습니다.

언어 전환도 더욱 매끄럽게 느껴질 수 있습니다. Weglot Angular를 완전히 재빌드할 필요 없이 표시되는 언어를 업데이트하는 JavaScript 기반 전환 기능을 Weglot . 덕분에 다국어 콘텐츠를 더 빠르게 출시할 수 있습니다.

대가는 제어권입니다. 번역은 Angular가 페이지를 렌더링한 후에 이루어지기 때문에, 이 모델은 TypeScript 내에서 언어에 의존하는 앱 로직을 처리하지 못합니다. 또한 콘텐츠가 프록시 뒤가 아닌 애플리케이션 자체 내에 존재해야 하는 Ionic 앱이나 오프라인 우선(offline-first) 앱의 경우, 이 모델은 이상적인 선택이 아닙니다.

SEO는 설정 방식에 따라 달라지기도 합니다. 리버스 프록시 변환을 사용하면 색인 생성 가능한 번역 페이지를 지원할 수 있지만, 단순한 자바스크립트 snippet SEO에 적합한 현지화된 URL을 생성할 수 없습니다. 이는 자연 검색 트래픽 확보가 목표 중 하나라면 특히 중요한 사항입니다.

이 모델은 애플리케이션 코드를 변경하지 않고 다국어 페이지를 구현하고자 하는 팀에 가장 적합합니다. 언어가 라우팅이나 비즈니스 로직에 영향을 미치는 경우에는 적합하지 않습니다. 또한 번역된 콘텐츠가 서비스에 계속 연동되어 있으므로, 활성 구독이 필요합니다.

적절한 Angular i18n 접근 방식 선택하기

Angular의 국제화를 위한 올바른 접근 방식은 앱이 실제로 언어를 어떻게 처리하는지에 따라 달라집니다.

빌드 시점의 i18n은 성능과 안정성을 최우선으로 하는 반면, 런타임 라이브러리는 UI 내부의 유연성에 중점을 둡니다. 외부 도구를 사용하면 구현 작업의 대부분을 덜 수 있지만, 제어권이 코드베이스 외부로 넘어가게 됩니다.

선택하세요 @angular/localize 실행 시 성능이 매우 중요하고, 팀이 CI 환경에서 별도의 현지화 빌드를 관리하는 데 익숙한 경우입니다. 앱 내부보다는 탐색을 통해 언어 전환이 이루어질 때 가장 적합합니다.

사용자가 페이지를 새로 고치지 않고도 언어를 전환할 수 있어야 하고, 널리 사용되는 런타임 옵션을 원한다면 ngx-translate를 선택하세요. Ionic 프로젝트와 소규모 Angular 앱에 가장 적합한 선택입니다.

대규모 앱에 런타임 전환 기능과 더 견고한 구조가 필요할 때는 Transloco를 선택하세요. SSR 환경에 적합할 뿐만 아니라, 범위 지정 및 지연 로딩이 가능한 번역 파일을 원하는 팀에게도 이상적인 선택입니다.

Angular 코드베이스에 번역 로직을 추가하지 않고 다국어 웹사이트를 구축하려는 Weglot 선택하세요. Weglot은 콘텐츠 제공 및 신속한 배포에 가장 적합하며, 언어에 따라 TypeScript 동작을 변경해야 하는 앱에는 적합하지 않습니다.

{{demo-banner}}