목차
모바일 앱 현지화: iOS와 Android 모범 사례
핵심 내용
- iOS는
.strings및.stringsdict파일을 사용하고, Android는res/values-{locale}/디렉토리의strings.xml을 사용합니다 - App Store Optimization (ASO)에는 각 시장에 맞는 현지화된 메타데이터(제목, 설명, 키워드, 스크린샷)가 필요합니다
- RTL 레이아웃 지원은 커스텀 뷰와 애니메이션을 포함한 모든 화면에서 테스트해야 합니다
- Over-the-Air (OTA) 번역 업데이트를 통해 새 앱 버전을 제출하지 않고도 번역을 수정할 수 있습니다
플랫폼별 현지화
iOS 현지화
iOS는 각 로케일에 .lproj 디렉토리를 사용합니다:
en.lproj/ Localizable.strings Localizable.stringsdict InfoPlist.strings de.lproj/ Localizable.strings Localizable.stringsdict InfoPlist.strings
주요 파일:
- Localizable.strings — UI 텍스트용 키-값 쌍
- Localizable.stringsdict — 복수형 규칙 (복잡한 복수형이 있는 언어에 필수)
- InfoPlist.strings — 앱 이름 및 권한 설명
Android 현지화
Android는 로케일 한정자가 포함된 리소스 디렉토리를 사용합니다:
res/ values/strings.xml (기본/영어) values-de/strings.xml (독일어) values-ja/strings.xml (일본어) values-ar/strings.xml (아랍어)
Android 리소스 시스템은 디바이스 로케일을 기반으로 올바른 파일을 자동으로 선택합니다. 복수형에는 plurals 리소스를, 목록에는 string-array를 사용합니다.
현지화된 앱의 App Store Optimization (ASO)
각 타겟 시장에 맞게 다음 요소를 현지화합니다:
| 요소 | iOS App Store | Google Play |
|---|---|---|
| 앱 이름 | 30자 | 30자 |
| 부제목 | 30자 | 80자 (짧은 설명) |
| 설명 | 4,000자 | 4,000자 |
| 키워드 | 100자 | 설명에 포함 |
| 스크린샷 | 최대 10개 | 최대 8개 |
| 미리보기 동영상 | 선택 사항 | 선택 사항 |
시장별로 키워드를 조사합니다 — 영어 키워드를 직접 번역하지 마세요.
RTL 언어 지원
아랍어, 히브리어 및 기타 RTL 언어의 경우:
left/right대신leading/trailing제약 조건을 사용합니다 (iOS)- 레이아웃에서
left/right대신start/end를 사용합니다 (Android) - 내비게이션 아이콘을 미러링합니다 (뒤로 가기 화살표, 목록 들여쓰기)
- 양방향 텍스트를 테스트합니다 (RTL과 LTR 혼합 콘텐츠)
- 커스텀 뷰가 레이아웃 방향을 준수하는지 확인합니다
Over-the-Air 번역 업데이트
OTA 시스템을 통해 전체 앱 릴리스 없이 번역을 업데이트할 수 있습니다:
- 번역 오류를 즉시 수정합니다
- 코드 변경 없이 새 언어를 추가합니다
- 전환율 최적화를 위해 번역 A/B 테스트를 진행합니다
- 사용자의 앱 업데이트 피로도를 줄입니다
모바일 앱 번역 서비스: 접근 방식 비교
적합한 모바일 앱 번역 서비스 선택은 팀 규모, 예산, 품질 요구 사항에 따라 다릅니다. 세 가지 주요 접근 방식에 대한 분석입니다.
수동 번역
수동 번역은 전문 번역가나 에이전시를 고용하여 앱 문자열을 한 번에 하나의 언어씩 번역하는 방식입니다. 이 접근 방식은 특히 마케팅 카피와 사용자 대면 콘텐츠에서 높은 언어 품질을 제공하지만 느리고 비용이 많이 듭니다. 처리 시간은 며칠 또는 몇 주 단위로 측정되며, 여러 언어에 걸쳐 여러 번역가를 조율하면 프로젝트 관리 오버헤드가 발생합니다.
자동화된 기계 번역
독립형 기계 번역 서비스(Google Translate API, DeepL API, Azure Translator)는 속도와 저렴한 비용을 제공합니다. UI 문자열과 문서의 초안을 생성하는 데 적합하지만, 출력에는 제품 컨텍스트가 부족합니다. "Set"과 같은 버튼 레이블은 UI에서 문자열이 어디에 나타나는지 인식 없이 동사(설정하다)가 아닌 명사(컬렉션)로 번역될 수 있습니다. 자동화된 MT는 프로덕션에 배포하기 전에 사람의 사후 편집이 필요합니다.
플랫폼 기반 앱 번역 서비스
플랫폼 기반 앱 번역 서비스는 자동화와 워크플로우 관리를 결합합니다. 번역가와 MT 엔진을 별도로 관리하는 대신, 플랫폼이 전체 파이프라인을 처리합니다: 문자열 추출, 기계 번역, 사람 검토 라우팅, 번역 메모리, 코드베이스로의 납품.
Better i18n은 이 모델을 위해 구축되었습니다. React Native 앱을 위한 Expo SDK(@better-i18n/expo)를 제공하여 App Store나 Google Play를 통한 재배포 없이 OTA 번역 업데이트를 가능하게 합니다. 플랫폼의 AI 번역 엔진은 제품 용어집과 UI 컨텍스트를 이해하여 앱에서 각 문자열이 어디에 나타나는지 인식하는 번역을 생성합니다. 번역은 300개 이상의 엣지 위치와 50ms 미만의 로드 시간을 가진 CDN을 통해 제공되므로 사용자는 업데이트된 번역을 즉시 확인할 수 있습니다.
앱 번역 서비스를 평가하는 팀에게 핵심 질문은 일회성 번역 공급업체가 필요한지, 아니면 릴리스 주기에 맞춰 진행할 수 있는 지속적인 번역 파이프라인이 필요한지입니다. 앱이 정기적으로 새 기능을 출시하는 경우, 플랫폼 접근 방식은 수동 및 독립형 MT 워크플로우를 느리게 하는 조율 오버헤드를 제거합니다.
일반적인 모바일 현지화 실수
- 리소스 파일 대신 코드의 하드코딩된 문자열
- 더 긴 번역으로 인해 깨지는 고정 너비 UI 요소
- 복수형 무시 — 많은 언어에는 단수/복수 이상의 형태가 있습니다
- 앱 스토어 목록의 번역되지 않은 스크린샷
- 아랍어 및 히브리어 시장을 위한 RTL 테스트 누락
FAQ
몇 가지 언어로 출시해야 합니까? 수익 또는 사용자 기반으로 상위 5~10개 시장부터 시작합니다. 일반적인 첫 번째 타겟: 영어, 스페인어, 프랑스어, 독일어, 일본어, 중국어, 한국어, 포르투갈어.
앱 문자열에 기계 번역을 사용해야 합니까? 기계 번역은 초안을 제공할 수 있지만, UI 문자열은 컨텍스트 정확도를 위해 사람의 검토가 필요합니다. 컨텍스트가 없는 짧은 문자열은 MT에게 특히 어렵습니다.
동적 콘텐츠 현지화는 어떻게 처리합니까? 동적 콘텐츠(푸시 알림, 인앱 메시지)에는 서버 사이드 현지화를 사용합니다. 클라이언트 사이드 현지화는 정적 UI를 처리합니다. TMS는 두 워크플로우를 모두 관리할 수 있습니다.
날짜, 시간 및 숫자 형식은 어떻게 합니까?
디바이스 로케일과 함께 플랫폼 포맷터(iOS의 DateFormatter, Android의 DateFormat)를 사용합니다. 날짜나 숫자를 수동으로 형식화하지 마세요.
