글로벌 앱을 위한 애플리케이션 국제화 가이드

당신의 앱은 다음 시장에 준비되어 있습니다. 제품 팀은 번역된 텍스트를 승인했으며, 마케팅 팀은 출시를 준비했으며, 고객 지원 팀은 스크립트를 업데이트했습니다. 그런 다음 테스트 결과 체크아웃 버튼이 영어로 고정되어 있음을 발견하고, 날짜가 올바른 순서로 나타나지 않으며, 통화가 익숙하지 않은 구분 기호를 사용하고, 더 긴 번역이 주요 액션을 화면 밖으로 밀어내고 있습니다. 출시가 번역 품질만으로 막히는 것은 아닙니다. 그것은 코드베이스에서 몇 달 전으로 결정된 사항 때문입니다.

그런 상황은 국제화의 실용적인 시작점입니다. 국제화국제화는 일반적으로 i18n으로 줄여서, 언어, 지역, 글꼴 시스템 및 문화적 관행이 추가될 수 있는 제품을 준비하는 것을 의미합니다. 그러한 제품은 재작성된 비즈니스 논리를 요구하지 않습니다. 그 다음 지역화는 준비된 제품을 특정 시장에 맞게 적응합니다.

사업적인 사례는 앱 경제에서 볼 수 있습니다. 730,024개의 iOS App Store 앱 중 2026년의 스냅샷에서, 중간 앱은 정확히 한 개의 언어를 지원하며 68.6% 단일 언어로 출시됩니다. 매월 $10,000 이상의 앱 은 5개 언어를 지원합니다.그리고 50.7% 그것의 상위 수익 계층 중 다섯 개 이상의 언어로 배포되는 경우가 많습니다. 이러한 통계는 지역화만으로 수익을 창출한다는 것을 증명하지는 않지만, 더 광범위한 상업적 목표를 가진 앱은 다언어 지원이 훨씬 더 일반적이라는 것을 보여줍니다.

이 안내서는 정신 모델에서 엔지니어링 패턴, 플랫폼 차이, 워크플로 자동화, 테스트, 마이그레이션에 이르기까지 다양한 주제를 다룹니다. 이 안내서는 네이티브 모바일 제품, 웹 애플리케이션, Capacitor 하이브리드 앱, Electron 데스크톱 소프트웨어에 모두 적용됩니다. 개인 정보 보호 및 지역 규정 준수도 출시 계획에 포함되어야 하므로, 규제 요구 사항을 처리하는 팀은 이 안내서와 함께 GDPR 준수 체크리스트를 pair할 수 있습니다. GDPR 준수 체크리스트.

애플리케이션 국제화 소개 및 왜 지금 중요합니까?
애플리케이션 국제화의 실제 의미
- 세 가지 용어, 세 가지 책임
- 기반 구조가 위험을 줄이는 이유
국제화된 앱에 필요한 핵심 패턴
모바일 웹 Capacitor 및 Electron에 대한 플랫폼별 고려 사항
확장 가능한 도구 라이브러리 및 번역 워크플로
- pipeline의 중요성
- 릴리스 엔지니어링으로 라이브 업데이트
글로벌 앱을 위한 테스트 QA 성능 및 보안
- 호스트일 콘텐츠로 시작
- 로케일 매트릭스 자동화
Code 예시와 이주 체크리스트를 통한 모든 것을 하나로

국제화 소개와 왜 지금 중요합니까?

시장 출시 일주일 전, 팀이 국제화를 발견한다. 제품은 언어 선택기를 요청하고, 디자인은 여러 화면을 조정하고, 엔지니어는 사용자 인터페이스 텍스트가 컴포넌트, 유효성 검사 규칙, 알림, 분석 레이블, 네이티브 구성 파일에 분산되어 있는 것을 발견한다. 날짜와 숫자도 같은 문제를 만든다. 표시 텍스트로 저장된 날짜는 안전하게 재배치할 수 없으며, 다른 지역에서 다른 순서로 구성된 가격은 필요할 수 있다.

이런 늦은 발견은 세 가지 비용이 있는 선택을 남긴다: 출시를 지연시키거나, 눈에 띄는 결함을 수용하거나, code를 변경한다. i18n을 아키텍처적 기능으로 다루면 워크플로가 바뀐다. 시장 확장은 자원, 표현, 테스트, 릴리즈 구성과 관련된 제어된 작업이 된다.

실용적인 규칙: 앱을 빌드하여 새로운 지역이 자원과 표현을 변경하는 대신, 비즈니스 규칙을 변경하지 않는다.

번역은 전 세계 준비의 하나뿐이다. 번역된 문장이 여전히 레이아웃을 깨는 경우가 있다. 올바르게 번역된 통화가 여전히 사용자에게 오해를 주는 경우도 있다. 언어 선택기가 웹层와 네이티브层에서 다른 지역을 감지하는 경우에도 불일치하는 동작을 발생시킬 수 있다.

late i18n 발견은 운영 비용을 높인다. 엔지니어들은 이전 컴포넌트를 따라서 문자열을 추적해야 하며, 번역가들은 불완전한 context를 받고, 리뷰어들은 급하게 변경한 것을 테스트하고, 릴리스 팀은 여러 플랫폼 패키지에서 고치는 것을 조정해야 한다. Capacitor와 Electron 팀에게는, Live Update 워크플로우는 새로운 스토어 리뷰를 기다리지 않고, 플랫폼과 릴리스 정책이 허용하는 경우에 승인된 지역화 리소스와 표시 수정을 전달하여 이 루프를 단축할 수 있다. 중요한 shift는 지역화 변경을 관리 릴리스 아티팩트로 다루는 것, 완전한 번역 전달이 아닌 것이다.

앞으로의 길은 다음과 같다:

기반을 준비하라: 사용자 인터페이스 리소스를 애플리케이션 로직과 분리하고, 모델 지역화-sensitive 값을 올바르게 처리하라.
언어 동작을 처리하라: 복수 규칙, 텍스트 확장, 쓰기 방향, 형식, 그리고 접근 가능한 언어 변경을 지원하라.
각 플랫폼을 적응하라: iOS, Android, 브라우저, Capacitor WebViews, 그리고 Electron 패키징을 고려하라.
릴리스를 유지하라: 추출, 번역, 리뷰, 테스트, 그리고 배포를 연결하여 새로운 문자열이 늦은 프로젝트 단계를 기다리지 않도록 하라.
인터페이스를 확인하라: 긴 텍스트, 오른쪽에서 왼쪽으로의 레이아웃, 지역 combination, fallback 동작, 성능, 그리고 업데이트 안전성을 테스트하라.

애플리케이션 국제화는 릴리스 엔지니어링 분야입니다. 제품의 후속 변경 사항을 지역화할 수 있도록 유지하고, 적절한 배포 경로를 통해 언어 문제를 수정하는 팀을 허용하며, 지역별 개인 정보 보호 작업을 포함합니다. GDPR 준수 체크리스트.

애플리케이션 국제화의 실제 의미

집 analogy로 시작하세요. 국제화는 장식하기 전에 집의 유연한 전선과 수도꼭지를 설치하는 것입니다. 지역화는 특정 지역을 위해 집을 장식하고 가구를 설치하는 것입니다. 번역은 레이블, 설명서, 표지의 언어를 변경하는 것입니다.

순서는 중요합니다. 벽에 하나의 기기를 위한 설계된 전선이 내장되어 있다면 새로운 기기를 추가하는 것은 비용이 많이 들 것입니다. 소프트웨어에서 고정된 문자열, 고정 너비의 컨트롤, 연결된 문장, 지역별 사업 논리 등은 동일한 제약 조건을 생성합니다.

세 가지 용어, 세 가지 책임

국제화, 또는 i18n 애플리케이션의 언어와 지역을 지원할 수 있도록 core behavior를 변경하지 않고 애플리케이션을 지원하는 설계 및 개발 작업입니다. 리소스 로딩, 지역 선택, 형식, 텍스트 방향, 글꼴 지원, 유연한 레이아웃이 포함됩니다.

지역화, 또는 l10n 준비된 애플리케이션을 특정 지역에 적응시키는 것입니다. 번역된 인터페이스 복사본, 지역별 형식, 지역 용어, 문화적으로 적절한 이미지, 시장별 기본값이 포함됩니다.

번역 한 언어에서 다른 언어로 내용을 변환하는 것을 의미합니다. 의미와 문장에 주로 초점을 맞추지만 좋은 번역 워크플로우도 컨텍스트, 스크린샷, 문자 제한, 각 문자열이 어디에 나타나는지에 대한 정보가 필요합니다.

어플리케이션 국제화, 지역화, 번역의 개념을 설명하는 다이어그램입니다.

국제화 리소스 구현 경계는 유용한 구분선입니다. 대신에 (Translated to keep the word count within ±3 words of the source) Payment failed component에서 직접적으로 요청하는 키는 semantic key입니다. payment.error위험을 줄이는 이유

The same separation applies beyond strings. Store monetary values as values, not as strings with symbols attached. Store timestamps as timestamps, not as already-formatted dates. Pass locale information to formatters instead of embedding separators or month names in business code.

번역

어플리케이션 국제화, 지역화, 번역의 개념을 설명하는 다이어그램입니다.

국제화는 소유권을 분리하는 데에도 도움이 됩니다. 디자이너들은 확장 가능한 컴포넌트를 정의할 수 있고, 번역가들은 컨텍스트를 검토할 수 있고, 제품 매니저들은 어떤 시장에 지원할지 결정할 수 있고, 엔지니어들은 누락된 키와 기본 규칙을 강제할 수 있습니다. 각 분야는 워크플로우에서 명확한 위치를 가집니다.

i18n을 생략하는 팀은 새로운 지역을 특별한 예외로 다루는 경향이 있습니다. i18n을 설계하는 팀은 지역을 입력으로 다루는 경향이 있습니다. 단일의shift는 글로벌 지원을 더 쉽게 이해할 수 있게 만듭니다.

국제화된 앱에 필요한 핵심 패턴

좋은 i18n은 작은 반복 가능한 패턴을 통해 구체화됩니다. 컴포넌트, 데이터, 및 릴리스层에서 적용하는 대신 단일 지역 코드베이스 위에 언어 switcher를 추가하는 대신.

국제화 앱의 네 개의 핵심 패턴을 보여주는 피라미드 다이어그램.

문자열을 리소스로 추출하십시오

이 변환은 첫 번째 실용적인 단계입니다:

showToast("Your profile was saved");

이후:

showToast(t("profile.saved"));

리소스 파일:

{
  "profile": {
    "saved": "Your profile was saved"
  }
}

의미를 설명하는 키를 사용하십시오. profile.saved 원래 문구가 변경되더라도 유용하게 남아있는 반면, 원래 문구에 기반한 키는 오해를 불러일으킬 수 있습니다. 동일한 단어의 의미가 다를 수 있는 경우, 예를 들어 '현재'가 버튼 액션인지 상태인지에 대한 컨텍스트를 포함하십시오.

국제화된 앱은 사용자 인터페이스 문자열, 날짜, 숫자, 통화 및 기호를 모두 지역 자원 또는 형식자에 외부화합니다. 이 모바일 국제화의 엔지니어링 blue print 이 엔지니어링 blue print는 팀이 비즈니스 로직을 변경하지 않고 언어를 추가할 수 있도록 하는 분리된 이유를 설명합니다.

메시지 형식을 사용하여 문법을 사용하십시오.

이것은 안전하지 않습니다:

`${count} items`

하드 코딩된 패턴은 모든 지역이 동일한 복수 동사 행동과 단어 순서를 사용한다고 가정합니다. 유니코드 CLDR는 날짜, 시간, 시간대, 숫자, 통화 및 복수 범주에 대한 일반적인 지역화 데이터 레이어를 제공합니다. CLDR에서 설명하는 지역화 최적화 가이드 라인에 따르면, 복수 규칙은 지역에 따라 다르기 때문에 앱은 지역에 의존하는 선택을 사용해야 하며, 고정된 패턴을 사용해서는 안 됩니다.

ICU 스타일의 메시지는 다음과 같이 보일 수 있습니다:

{count, plural,
  =0 {No items}
  one {# item}
  other {# items}
}

형식자는 올바른 branch를 선택합니다. 번역가가 번호와 명사를 재배치할 때 문법이 요구하는 경우 전체 메시지를 유지하십시오.

지역에 의존하는 API를 사용하여 값 형식을 지정하십시오.

날짜를 수동으로 조립하지 마십시오:

`${day}/${month}/${year}`

형식자를 사용하십시오:

new Intl.DateTimeFormat(locale, {
  dateStyle: "medium"
}).format(date)

이 원칙은 숫자 및 통화에 동일하게 적용됩니다:

new Intl.NumberFormat(locale, {
  style: "currency",
  currency: currencyCode
}).format(amount)

IntlICU, CLDR, 및 라이브러리는 지역에 따라 달라지는 관습을 처리합니다. 또한 표시 로직은 표시层에서 가깝게 유지합니다.

방향과 확장에 대한 디자인

텍스트는 언어에 따라 예측할 수 없는 확장성을 가집니다. 버튼은 유연한 너비를 필요로하고 카드는 adaptable 높이를 필요로하며 라벨은 한 줄에 의존하지 않아야합니다. 콘텐츠가 성장할 수 있는 레이아웃 시스템을 사용하고, 번역자가 최종 검토를 시작하기 전에 긴 가짜 번역으로 컨트롤을 테스트하세요.

오른쪽에서 왼쪽으로 지원은 단순히 텍스트 정렬만 뒤집는 것이 아닙니다. 아이콘, 탐색 순서, 패딩, 애니메이션, 방향성 제스처도 반전이 필요합니다. 지원하는 플랫폼에서 논리적 속성을 사용하는 대신 margin-inline-start 를 사용하세요. 이미지, 글꼴, 임베디드 텍스트도 검토가 필요합니다. 한 스크립트를 잘 렌더링하는 글꼴은 다른 스크립트를 지원하지 않을 수 있고, 영어 단어를 포함하는 이미지는 번역된-overlay 대신 지역화된 자산이 필요할 수 있습니다.

인터페이스에 대한 구체적인 지침을 찾으려면 Capacitor를 사용하는 팀은 또한 이 를 참조할 수 있습니다..

Platform Specific Considerations for Mobile Web Capacitor and Electron

모바일 웹 __CAPGO_KEEP_0__ 및 Electron에 대한 플랫폼별 고려 사항

Platform	플랫폼별 고려 사항은 지역 설정을 감지하는 방법입니다.	국제화 방법	Key Gotcha
iOS	앱의 언어 설정과 지원되는 경우 앱 내에서 언어 설정	Foundation formatters와 JavaScript `Intl` 웹 콘텐츠	네이티브 화면과 WebView 화면은 별도의 지역 상태를 사용하는 경우에만 드리프트가 발생할 수 있습니다.
Android	앱의 언어 설정과 구현에 따라	Android 지역 API와 JavaScript `Intl` 웹 콘텐츠	리소스 퀄리파이어와 WebView 리소스는 의도적인 fallback 전략이 필요합니다.
웹	브라우저 언어 설정, 사용자 선택, 또는 URL 및 계정 설정	JavaScript `Intl`, ICU 백업 라이브러리 및 서버 측 지역 처리	서버와 클라이언트 지역 결정이 일치해야 하며 불일치하는 렌더링을 피해야 합니다.
Capacitor	자연어 선호도 및 WebView 상태	자연어 형식, JavaScript `Intl`, 및 공유 리소스 번들	실시간 JavaScript 업데이트 없이 원본 리소스를 변경하지 않고 지역화된 콘텐츠를 변경할 수 있습니다.
Electron	운영 체제 지역 설정, 앱 선호도 또는 계정 설정	JavaScript `Intl`, 노드 사이드 로직 및 렌더러 리소스	제작 시 패키지된 지역화 자산이 포함되고 올바르게 로드되어야 합니다.

자연어 모바일 애플리케이션

iOS와 Android 각기 자체의 원시 지역화 시스템을 제공하지만 많은 팀이 또한 자바스크립트를 통해 상당한 UI를 렌더링합니다. 자바스크립트 layer와 원시 layer가 지역 코드, 번역 키, 기본 규칙을 공유할지 결정하십시오. 사용자가 선택한 언어가 다음 런칭 시 기기 설정으로 대체되지 않도록 지역 선택을 명확하게 유지하십시오.

스토어 메타데이터는 별도의 주의가 필요합니다. 지역화된 앱이 여전히 한 언어로 제목, 부제, 설명을 남겨두면 발견 가능성이 떨어집니다. 2023년 미국 앱이 외국 시장에 진입한 분석 분석 결과 60% iOS의 경우 제목을 90% 제목을 10 중 6 제목을 지역화했습니다. Android의 경우, 70% 국제화된 제목과 89% 국제화된 설명입니다. 이들은 런타임 UI 결정이 아닌 스토어 프론트의 결정이므로, 엔지니어링 번들을 통해 처리하는 대신 런치 체크리스트에 할당합니다.

웹 애플리케이션

URL, 서버 렌더링, 브라우저 선호도 및 계정 선호도 간의 안정적인 관계가 웹 애플리케이션에 필요합니다. 서버가 영어를 렌더링하는 동안 브라우저가 즉시 독일어로switch하는 경우 사용자는 플래시 또는 수화 불일치가 발생할 수 있습니다. 우선 순위를 선택하고 사용자의 선택을 영구적으로 저장하고, 기본 로케일이 결정적이도록 하세요.

대량으로 번역된 콘텐츠가 있는 애플리케이션이 있는 경우 로케일 번들 Lazy-load를 사용하세요. 기본 경험은 빠르지만, 오프라인 또는 failed-fetch 경로가 안전한 기본값을 렌더링할 수 있도록 하세요.

Capacitor와 Electron

Capacitor 앱은 iOS, Android, 및 브라우저 간에 공유된 웹 코드베이스를 사용합니다. 이로 인해 공유된 리소스가 효율적이지만, 네이티브 플러그인은 여전히 플랫폼별로 로케일 동작을 노출할 수 있습니다. WebView는 브라우저 및 장치 설정에서 independantly 추측하는 대신, 하나의 권위 있는 출처에서 정규화된 로케일을 받을 수 있어야 합니다. 그런 경계를 평가하는 팀은 Capacitor가 플랫폼 차이점을 다루는 방식을 검토할 수 있습니다..

Electron은 패키징에 대한 걱정 요소를 추가합니다. 렌더러는 개발 중에 다른 환경에서 로케일 파일을 로드할 수 있으므로 프로덕션 빌드는 리소스가 존재하고 접근 가능하며 함께 업데이트되는지 확인해야 합니다. 자바스크립트 번들을 라이브 업데이트가 가능하다면, 로케일 파일이 같은 서명된 번들에 포함되어 있는지 정의하고 업데이트가 실패하면 롤백하는 방법을 정의해야 합니다.

국제화가 가능하도록 확장하는 도구 라이브러리 및 대규모 번역 워크플로

국제화 라이브러리는 자체로 지역화 워크플로를 생성하지 않습니다. 팀은 i18next, FormatJS, 또는 native를 사용할 수 있습니다. Intl APIs and still miss a release if key ownership, context, review, delivery, and rollback are unclear. Treat every new string like a software artifact that moves through the same controls as code.

개발자는 의미 있는 키를 추가합니다.

키에 대한 context, 스크린샷, 변수, 문자 제한이 필요한 곳에 적용합니다. 자동화는 키를 추출하거나 유효성을 검사하고 번역 관리 시스템으로 전송합니다.
번역가와 리뷰어는 동일한 소스 파일을 사용하며 빌드는 플레이스 홀더와 필요한 로케일을 확인합니다. CI는 승인된 리소스를 가져옵니다.
CI는 승인된 리소스를 가져옵니다. CI는 승인된 리소스를 가져옵니다.
CI는 승인된 리소스를 가져옵니다. 그리고 애플리케이션과 함께 패키징하거나 승인된 업데이트 채널을 통해 전송합니다.
QA가 변경된 지역을 확인합니다. 언어 리뷰를 처음부터 반복하지 않아도 됩니다.
릴리스 제어는 노출을 관리합니다.내부, 베타, 또는 대상 사용자부터 더 광범위한 롤아웃 전에 시작합니다.

소프트웨어 국제화, 번역 관리 및 지속적인 지역화 워크플로의 4단계 확장 가능한 프로세스를 minh họa하는 다이어그램입니다.

Why pipeline이 중요합니까?

대부분의 경우 승인된 콘텐츠를 기다리는 것이 아니라 code을 작성하는 것이 bottleneck입니다. A 2026년 개발자 조사에서 i18n 워크플로에 대한 조사 결과 respondents의 64% 번역 워크플로의 효율성을 가장 큰 문제로 지적했습니다. 78% 번역을 기다리는 것이 출시를 지연한다고 말했습니다. 52% 시스템적인 번역 QA 검사를 위한 자동화된 검사가 없었다. 같은 출처는 또한 41% 2026년까지 오버 더 에어 시스템을 채택하고 28% 이러한 발견은 지역화와 릴리즈를 연결시키며, 이를 별도의 콘텐츠 사이클로 다루는 것과 다르다.

CI는 패키징 전에 예측 가능한 실패를 잡아야 한다.

미등록 키: 소스 키가 대체 키가 없을 때 실패하거나 경고하라.
플레이스 홀더 드리프트: 변수들인 {count} 모든 번역 메시지에 존재하는지 확인하라.
미등록 키: 어플리케이션에 더 이상 나타나지 않는 리소스를 표시하라.
유효하지 않은 문법: JSON, ICU 메시지, 또는 리소스 파일을 거부합니다.
지역화 범위: 지원하는 지역의 변경 사항을 보고, 아직 검토해야 하는 지역을 보고합니다.

CI 통합 패턴에 대한 자세한 내용은 개발자 경험 도구 개요를 참조하세요. 개발자 경험 도구 개요.

릴리즈 엔지니어링을 위한 Live Update

For Capacitor and Electron teams, a localization fix can travel inside a signed JavaScript, CSS, copy, configuration, and asset bundle. A live-update platform such as Capgo 글로벌 앱을 위한 테스트, QA, 성능 및 보안

지역화 테스트는 사용자가 먼저 실패를 노출하는 가정에 대해 노출해야 합니다. 단일 번역된 스크린샷은 충분하지 않습니다. 실패는 지역, 데이터 길이, 화면 크기, 쓰기 방향, 및 플랫폼의 특정 Combination에 의존하기 때문입니다.

CI 통합 패턴에 대한 자세한 내용은 개발자 경험 도구 개요를 참조하세요.

개발자 경험 도구 개요

세계적인 소프트웨어 애플리케이션의 QA 성능 및 보안 테스트를 위한 네 가지 단계의 체크리스트입니다.

호스트일 수 있는 콘텐츠로 시작합니다.

가짜 지역화는 일반적인 문자열을 테스트 문자열로 대체하여 의도적으로 더 긴, 어근이 있는, 또는 마커로 둘러싸인 문자열로 대체합니다. 이는 고정된 문자열, 잘려나간 레이블, 고정된 카드 높이, 영어에서만 작동하는 컨트롤, 빈 상태와 채워진 상태를 테스트하여 고정된 문자열, 잘려나간 레이블, 고정된 카드 높이, 영어에서만 작동하는 컨트롤을 드러내는 데 도움이 됩니다. 또한 복수 메시지와 유효성 검사 오류는 종종 레이아웃 경로가 다르기 때문에 빈 상태와 채워진 상태를 모두 테스트해야 합니다.

RTL 테스트는 완전한 탐색 패스를 필요로 합니다. 텍스트 정렬, 뒤로 가기 버튼, 아이콘, 차트, 스와이프 제스처, 양식 필드, 혼합 방향 콘텐츠(예: 아랍어 문장에 제품 code가 포함된 경우)를 확인해야 합니다. 모든 아이콘을 자동으로 반전시키지 마세요. 방향 아이콘은 반전이 필요할 수 있지만 브랜드 마크와 일부 객체 아이콘은 그대로 유지해야 합니다.

지역화 매트릭스를 자동화하세요.

지원하는 언어 및 지역 Combination에 대한 테스트 매트릭스를 구축하세요. 언어 이름만으로는 충분하지 않습니다. 언어는 지역에 따라 날짜, 숫자, 통화, 캘린더, 시간대와 같은 규칙이 다를 수 있습니다.

기능적 검사: 지역 설정, 지속성, 대체, 복수 branch, 오류 메시지의 확인을 위해 지역 설정을 확인하세요.
시각적 검사: 긴 문자열, RTL이 활성화된, 좁은 너비의 키 스크린을 캡처하세요.
언어적 검사: 리뷰어에게 컨텍스트, 스크린샷, 변수, 의도된 액션을 제공하세요.
Regression 확인: 업데이트 설치 테스트, 중단된 다운로드, 오프라인 시작, 롤백 동작.

성능은 지역 리소스가 증가할 때도 discipline이 필요합니다. 지역 또는 기능에 따라 큰 번들을 분할하고, 불필요한 언어를 지연 로드하고, 검증된 리소스를 캐시합니다. 느린 번역 요청에 의존하는 첫 번째 화면을 만들지 않는 것이 좋습니다. 애플리케이션이 신뢰할 수 있는 대체를 가지고 있다면.

보안은 동일한 검토에 속합니다. 지역 식별자와 사용자 제공된 번역된 콘텐츠를 입력으로 처리하고, 리소스 구조를 검증하고, 번역 관리 자격 증명을 보호하고, 원격으로 전달된 번들을 검증합니다. Live Update 워크플로는 서명된 아티팩트, 제어된 채널, 버전 호환성 검사, 관찰 가능한 실패, 테스트된 롤백 경로를 사용해야 합니다. 배포 제어를 설계하는 팀은 이 안내서를 검토하여 다중 지역 배포.

모든 것을 함께하는 Code 예시 및 마이그레이션 체크리스트

체크아웃 화면은 마이그레이션 순서가 중요함을 보여줍니다. code 사용자가 가장 많이 터치하는 화면부터 시작하고, 각 가정에 지역에 의존하는 경계를 대체합니다. 고정된 레이아웃, 날짜, 통화, 복수 메시지, 고정 너비 레이아웃은 별도의 마이그레이션 작업으로 처리해야 하며, 대체 지역이 없는 리소스가 빈 컨트롤을 남기지 않도록 하기 위해 fallback 지역을 사용합니다.

예를 들어, 기존 컴포넌트의 통화 연결을 대체합니다.

Before:

price.textContent = currencySymbol + amount;

After:

price.textContent = new Intl.NumberFormat(locale, {
  style: "currency",
  currency: currencyCode
}).format(amount);

Keep amount 숫자 값을 raw 값으로 사용합니다. 형식 지정자는 기호의 배치, 구분자, 소수점 표기법 및 기타 지역 정보를 결정합니다. 이 방식은 체크아웃 로직에 지역 규칙을 퍼뜨리지 않도록 합니다.

실용적인 마이그레이션 체크리스트:

인벤토리: 사용자 인터페이스 문자열, 형식화된 값, 텍스트가 포함된 이미지 및 지역 가정 찾기.
외부화: semantic 키와 번역자 컨텍스트가 있는 리소스 파일로 복사 이동.
지역 설정 정규화: 탐지, 사용자 오버라이드, 영구성 및 기본값 동작 정의.
수동 형식화 대체: 플랫폼 또는 JavaScript 지역 정보에 의한 형식화 사용.
레이아웃 강화: 확장, 자르기, 양방향 텍스트, 글꼴 및 RTL 반사 테스트.
자동화 검증: CI에서 미리 설치된 키, 플레이스 홀더, 리소스 구문 및 변경된 지역을 확인하십시오.
안전한 릴리즈: 스토어 프로세스 또는 제어된 라이브 업데이트 채널을 통해 서명, 단계별 노출, 모니터링 및 롤백을 사용하여 호환성 있는 지역화 변경을 배포하십시오.

첫 번째 패스는 온보딩 또는 체크아웃과 같은 높은 트래픽 흐름 중 하나를 선택하십시오. 리소스 경계와 검증 PIPELINE이 작동하는 경우, 앱 전체에 동일한 규칙을 적용하는 것이 아니라 무제한으로 다시 작성하는 대신, 같은 규칙을 적용하십시오.

CapacitorJS 및 Electron 팀을 위한 Capgo는 호환되는 자바스크립트, CSS, 복사본, 구성 및 자산 변경에 서명된 라이브 업데이트된 패키지를 지원합니다. 채널, 차등 배포, 관찰성 및 롤백 보호를 사용하여 지역화 수정을 기존 CI/CD 워크플로와 연결할 수 있습니다. 이는 매 호환되는 수정에 대해 스토어 리뷰에 의존하지 않도록 하는 데 도움이 됩니다. 릴리스 경로를 배포 제어와 비교하여 평가한 후 다른 지역으로 확장하십시오.

글로벌 앱을 위한 앱 국제화 가이드

목차