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

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

그런 상황은 앱 국제화의 실제 시작점입니다. 앱 국제화i18n으로 줄여서 국제화라고 부르는 경우, 제품을 언어, 지역, 글꼴 시스템, 문화적 관행을 추가할 수 있는 제품을 준비합니다. 그런 다음 지역화는 준비된 제품을 특정 시장에 맞게 적응합니다.

2026년 730,024개의 iOS 앱 스토어 앱 중에서 한 개의 언어만을 지원합니다., 68.6% 한 개의 언어로만 배달합니다. 매월 10,000 달러 이상을 벌어들이는 앱은 $10,000 이상의 월간 수입을 벌어들이는 앱은 5개 언어를 지원하는 앱의 평균 수입은 5개 언어 이상을 지원하는 앱은, 그리고 50.7% 상위 수입 계층 중 5개 이상 언어를 지원하는 앱은 5개 이상 언어를 지원합니다. 이 통계는 지역화만으로 수입을 창출한다는 것을 증명하지는 않지만, 더 광범위한 상업적 목표를 가진 앱은 다국어 지원이 훨씬 더 일반적이라는 것을 보여줍니다.

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

애플리케이션 국제화 소개 및 그 중요성
앱 국제화 소개 및 왜 지금 중요합니까?
- 앱 국제화가 무엇을 의미합니까?
- 위험을 줄이는 이유
국제화된 앱이 필요한 핵심 패턴
Platform Specific Considerations for Mobile Web Capacitor and Electron
확장 가능한 도구 라이브러리 및 번역 워크플로
- pipeline의 중요성
- 최신 릴리스 엔지니어링을 위한 실시간 업데이트
글로벌 앱을 위한 QA 성능 및 보안 테스트
- 호스트일 콘텐츠 시작
- 지역화 매트릭스 자동화
Code 예시 및 마이그레이션 체크리스트와 함께 모든 것을 함께합니다.

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

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

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

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

번역은 글로벌 준비의 단순한 부분이다. A 번역된 문장이 여전히 레이아웃을 깨는 길이를 accommodate 할 수 없는 레이아웃을 깨는 길이를 가질 수 있습니다. 정확한 번역된 통화가 여전히 저장된 값이 형식화된 텍스트로 저장된 경우 사용자에게 오해를 주는 경우가 있습니다. 언어 선택기가 웹层와 네이티브层이 다른 지역을 감지할 때 불일치한 동작을 생산할 수 있습니다.

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

앞으로의 길이는 다음과 같습니다:

기반을 준비하십시오: 사용자에게 보이는 리소스를 애플리케이션 로직과 분리하고 모델 지역에 민감한 값을 올바르게 처리하십시오.
언어 동작을 처리하십시오: 복수 규칙, 텍스트 확장, 쓰기 방향, 형식화, 그리고 접근 가능한 언어 변경을 지원하십시오.
각 플랫폼을 적응하십시오: iOS, Android, 브라우저, Capacitor WebView, 그리고 Electron 패키징을 고려하십시오.
릴리스를 유지하십시오: 추출, 번역, 리뷰, 테스트, 그리고 배포를 연결하여 새로운 문자열이 늦은 프로젝트 단계를 기다리지 않도록 하십시오.
인터페이스를 확인하십시오: 국제화는 앱의 언어와 지역을 지원하는 데 필요한 설계와 개발 작업입니다.

앱 국제화는 제품의 후속 변경 사항을 지역화 가능하게 유지하고, 팀이 언어 문제를 수정하기 위해 적절한 배포 경로를 사용할 수 있도록 해 주며, 지역별 개인 정보 보호 작업을 포함합니다. GDPR 준수 체크리스트.

앱 국제화의 실제 의미는 무엇입니까?

집 analogy로 시작하세요. 국제화는 방을 꾸미기 전에 집에 설치하는 유연한 전선과 수도관입니다. 지역화는 특정 지역을 위해 집을 꾸미고 장식하는 것입니다.

번역은 레이블, 설명서, 표지의 언어를 변경하는 것입니다.

세 가지 용어, 세 가지 책임

세 가지 용어, 세 가지 책임 국제화, 또는 i18n

앱이 언어와 지역을 지원하는 데 필요한 설계와 개발 작업입니다. 리소스 로딩, 지역 선택, 형식 지정, 텍스트 방향, 글꼴 지원, 유연한 레이아웃 등이 포함됩니다. 어떤 지역의 언어와 문화에 맞게 준비된 앱을 특정 지역으로 적응시킨다. 그것은 번역된 인터페이스 텍스트, 지역에 따라 달라지는 형식, 지역 용어, 문화적으로 적절한 이미지를 포함할 수 있다.

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

어플리케이션 국제화, 지역화, 번역의 개념을 설명하는 다이어그램. 집 metaphor를 사용한다.

국가 자원으로 구분하는 구현 경계가 유용합니다. 대신 국가 자원을 (Translation shortened by 1 word to fit the ±3 word limit) 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.

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

언어를 추가할 때 구매 계산, 인증 흐름, 데이터 모델을 변경할 필요가 없습니다. 엔지니어는 리소스 번들을 업데이트하고, 번역가들은 번역 관리 시스템에서 작업하고, QA 팀은 결과 인터페이스를 테스트할 수 있습니다. 이 분리 또한 소유권을 개선합니다.

디자이너는 확장 안전한 컴포넌트를 정의하고, 번역가들은 컨텍스트를 검토하고, 제품 매니저들은 지원할 시장에 대해 결정하고, 엔지니어는 누락된 키와 기본 규칙을 강제할 수 있습니다. 각 분야는 워크플로에 명확한 위치를 가집니다.

i18n을 생략하는 팀은 새로운 지역을 특별한 예외로 다루지만, i18n을 설계하는 팀은 지역을 입력으로 다룹니다. 이 단순한 shift는 글로벌 지원을 더 쉽게 이해할 수 있도록 합니다.

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

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

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

문자열을 리소스로 추출하세요

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

showToast("Your profile was saved");

이후:

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

리소스 파일:

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

키가 의미를 설명하는 대신 영어 문장을 사용하지 마세요. profile.saved 원어의 문구가 변경되더라도 영어 문구가 유용하다. 원래 문장에 기반한 키는 오해를 불러일으킬 수 있지만. 번역자에게 문맥을 제공하여 같은 단어가 다른 의미를 가질 수 있는 경우를 포함한다. 예를 들어 “현재”는 버튼 액션인지 상태인지 구분해야 한다.

A properly internationalized app은 사용자 인터페이스에 대한 모든 문자열, 날짜, 숫자, 통화, 기호를 지역화 리소스 또는 형식으로 외부화한다. 이것은 모바일 i18n의 엔지니어링 blue print 이 분리가 팀이 언어를 추가할 수 있도록 비즈니스 로직을 변경하지 않고도 언어를 추가할 수 있음을 설명한다.

문자열 형식을 사용하여 문법을 사용하라

이것은 안전하지 않다:

`${count} items`

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

ICU-style 메시지는 다음과 같이 보일 수 있다:

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

형식자는 올바른 branch를 선택한다. 번역자가 문법이 번호와 명사를 재배치할 수 있도록 전체 메시지를 유지하라.

지역화-aware API를 사용하여 값 형식을 지정하라

일자를 수동으로 조립하지 마라:

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

형식자를 사용하라:

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

숫자와 통화에 적용되는 동일한 원칙이 적용됩니다:

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

IntlICU, CLDR-backed 라이브러리와 같은 도구는 지역에 따라 달라지는 관습을 처리하고 표시 로직을 프레젠테이션层에서 가까운 곳에 유지합니다.

방향과 확장에 대한 디자인

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

오른쪽에서 왼쪽으로 지원하려면 단순히 텍스트 정렬만 뒤집는 것이 아닙니다. 아이콘, 탐색 순서, 패딩, 애니메이션 및 방향성 제스처도 반전이 필요합니다. 지원하는 플랫폼에서 가능한 경우 논리적 속성을 사용하십시오. 이미지, 글꼴 및 임베디드 텍스트도 검토가 필요합니다. 글꼴이 한 스크립트를 잘 렌더링하는 경우 다른 스크립트를 처리하지 못할 수 있고 영어 단어를 포함하는 이미지에는 지역화된 자산이 필요할 수 있습니다. margin-inline-start 인터페이스에 대한 구체적인 지침을 위해 __CAPGO_KEEP_0__를 사용하는 팀은 또한 이

For interface-specific guidance, teams using Capacitor can also consult these UI 및 UX 관행을 참조하세요..

Capacitor

기본 규칙은 동일하지만 각 런타임은 다른 지역 신호와 패키징 제약 조건을 제공합니다. 네이티브 앱은 플랫폼 API를 통해 장치 설정을 읽을 수 있습니다. 브라우저는 언어 설정을 브라우저 설정과 JavaScript API를 통해 노출합니다. 하이브리드 앱은 WebView와 네이티브 셸을 모두 가지고 있으므로 팀은 지역 설정의 진실이 어디에 있는지 결정해야 합니다.

플랫폼	지역 식별	형식화 방법	중요한 함정
iOS	장치 또는 앱 언어 설정, 지원되는 경우 앱별 동작	Foundation 형식화기와 JavaScript `Intl` 웹 콘텐츠를위한	네이티브 화면과 WebView 화면은 별도의 지역 상태를 사용하는 경우에만 분리될 수 있습니다.
안드로이드	장치 및 앱 언어 설정, 구현에 따라	안드로이드 지역 API 및 JavaScript `Intl` 웹 콘텐츠 내	리소스 정의자 및 WebView 리소스는 의도적인 fallback 전략이 필요합니다
웹	브라우저 언어 선호도, 사용자 선택, 또는 URL 및 계정 설정	JavaScript `Intl`, ICU 백업 라이브러리 및 서버 측 지역 처리	서버 및 클라이언트 지역 결정은 일관된 렌더링을 피하기 위해 동의해야 합니다
Capacitor	네이티브 선호도 플러스 WebView 상태	네이티브 형식, JavaScript `Intl`, 및 공유 리소스 번들	실시간 자바스크립트 업데이트 기능은 지역화된 콘텐츠를 변경할 수 있지만 원본 자원은 변경하지 않습니다.
Electron	국제화된 콘텐츠는 네이티브 리소스를 변경하지 않고도 라이브 자바스크립트 업데이트로 변경될 수 있습니다	Electron `Intl`운영 체제 로케일, 앱 선호도 또는 계정 설정	자바스크립트

, Node-side logic, and renderer resources

배포 빌드에서 패키지된 로케일 자산이 포함되고 올바르게 로드되어야 합니다

네이티브 모바일 애플리케이션 2023년 미국 주요 앱의 해외 시장 진출 분석 찾아보니 60% iOS 타이틀을 지역화했습니다. 90% 국제화된 제품 설명을 작성하고, 10명 중 6명이 국제화된 서브 타이틀을 작성했습니다. 안드로이드에서 70% 국제화된 제목과 89% 국제화된 설명을 작성했습니다. 이들은 스토어 프론트의 결정이며, 런타임 UI의 결정이 아니므로, 엔지니어링 패키지가 그들을 처리하는 것으로 가정하기보다는 런칭 체크리스트에 할당하는 것이 좋습니다.

웹 애플리케이션

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

어플리케이션이 충분한 번역된 콘텐츠를 가지고 있을 때, 로케일 번들에 대한 느린 로드를 사용하세요. 기본 경험은 빠르게 유지하세요, 그러나 오프라인 또는 실패한-fetch 경로가 안전한 기본값을 렌더링할 수 있도록 하세요.

Capacitor과 Electron

Capacitor 앱은 종종 iOS, 안드로이드, 브라우저 간에 공유된 웹 코드베이스를 사용합니다. 이게 공유된 리소스가 효율적이지만, 네이티브 플러그인이 여전히 플랫폼별로 로케일 동작을 노출할 수 있습니다. WebView는 하나의 권위 있는 출처에서 정규화된 로케일을 받을 수 있도록 하세요. 그 경계를 평가하는 팀은 Capacitor이 플랫폼 차이점을 어떻게 처리하는지 검토할 수 있습니다..

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

도구 라이브러리 및 확장 가능한 번역 워크플로

번역 라이브러리는 지역화 워크플로를 생성하지 않습니다. 팀은 i18next, FormatJS, 또는 native API를 사용하여도 중요한 소유권, context, 리뷰, 배포, 롤백이 명확하지 않으면 릴리스를 놓치게 됩니다. 새로운 문자열을 소프트웨어 아티팩트처럼 다루어야 합니다. 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.

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

키에 대한 컨텍스트, 스크린샷, 변수, 문자 제한이 필요한 곳에. 자동화는 키를 추출하거나 유효성을 검사하고 번역 관리 시스템으로 전송합니다.
번역가와 리뷰어는 동일한 소스 파일을 사용하며 빌드는 플레이스 홀더와 필요한 지역을 확인합니다. CI는 승인된 리소스를 가져옵니다.
A scalable workflow follows a clear chain: A developer adds a semantic key
with context, screenshots, variables, and character limits where they matter. 그리고 애플리케이션과 함께 패키징하거나 승인된 업데이트 채널을 통해 전송합니다.
QA가 변경된 지역을 확인합니다. 언어 리뷰를 처음부터 반복하지 않도록 합니다.
릴리스 제어는 노출을 관리합니다.내부, 베타, 또는 목표 사용자부터 더 광범위한 롤아웃 전까지 시작합니다.

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

pipeline의 중요성

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

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 는 채널을 대상으로, 변경된 파일만 포함하는 차별 업데이트 전송, 채택 및 실패 메트릭 노출, 자동 롤백 보호를 제공합니다. 이로 인해 mistranslated 레이블 또는 레이아웃 규칙을 수정하는 릴리즈 엔지니어링 경로를 정의하는 팀이 정의한 업데이트 정책, 검토 프로세스, 서명 규칙, 및 네이티브 호환성 경계를 기다리지 않고 수정할 수 있습니다.

스토어 릴리스를 대체하는 것은 아닙니다. 네이티브 문자열, 권한, 플랫폼 API, 및 설치된 네이티브 런타임을 초과하는 변경은 적절한 배포 경로를 통해 전달해야 합니다. Live Update는 호환성 지역화 변경에 대한 빠른 경로를 제공하며, 작은 콘텐츠 수정이 다음 애플리케이션 릴리스를 기다릴 수 있는 경우에만 사용됩니다.

글로벌 앱을 위한 테스트 QA 성능 및 보안

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

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

호스트일 콘텐츠로 시작하세요.

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

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

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

지원하는 언어 및 지역 Combination에 대한 테스트 매트릭스를 구축하세요. 언어 이름만으로는 충분하지 않습니다. 언어는 지역 간에 다른 관습을 가지고 있으며, 특히 날짜, 숫자, 통화, 캘린더 및 시간대와 관련하여 그렇습니다.

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

성능은 지역 리소스가 증가할 때도 discipline이 필요합니다. 큰 번들을 지역 또는 기능별로 나누거나, 불필요한 언어를 지연 로드하고, 유효한 리소스를 캐시하세요. 첫 번째 화면이 느린 번역 요청에 의존하지 않도록 하려면, 애플리케이션이 신뢰할 수 있는 대체를 가지고 있어야 합니다.

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

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

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

예를 들어, 기존 컴포넌트의 통화 연결을 대체하세요.

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 워크플로우와 연결할 수 있습니다. 이는 매 호환되는 수정에 대해 스토어 리뷰에 의존하지 않도록 하는 데 도움이 됩니다. 이 릴리즈 경로를 배포 제어와 비교한 후, 다른 지역에 확장하기 전에 평가하십시오.

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

목차