👋 들어가기 전
현재 진행중인 프로젝트는 글로벌 서비스를 노리고 있어 Localization이라는
중요한 임무를 맡게 되었다.
이전 프로젝트에서는 Strings File을 이용하여 Localization을 진행했는데 Xcode 15부터
더 쉽게 도와주는 String Catalog라는 파일을 사용해보려고 한다.
✊ String Catalog란?
먼저 우리가 사용할 String Catalog이 무엇인지 알아보자.
공식문서에서 String Catalog를 다음과 같이 소개하고 있다.
Use a string catalog to translate text, handle plurals, and vary the text your app displays on specific devices.
현지화를 위한 도구인데 라는 걸 길게 말하고 있다 😂 (써본 결과 미치긴했다.. 여기서 복수화가 진짜 사기인 듯)
다음은 단계별로 어떻게 진행해야하는 지 살펴보자.
☝️ 지원할 언어 선택
먼저 사진과 같이 Project -> Info -> Localizations 탭에서 지원할 언어를 다양화한다.
✌️String Catalog 추가
다음은 프로젝트에 String Catalog를 추가한다.
생성 직후는 위에서 설정한 언어를 기준으로 탭이 다음과 같이 만들어져있다.
이후 새로운 언어를 선택하고 삭제해봤는데 알아서 추가되고 삭제되어 굉장히 관리가 편해졌다. 😀
여기서 정말 놀라운 기능이 하나 있는데 "바로 자동 문자열 추출 기능" 이다.
프로젝트 빌드 세팅의 위 옵션을 켜준 후 빌드하면
다음과 같이 앱 내에 존재하는 당야한 string 정보를 알아서 긁어온다.
wow ... 지금은 앱 내에 string이 많기 때문에 따로 Sample 프로젝트를 파서 하나씩 알아보자.
👍 추출 기준
String catalog는 내가 원하는 모든 문자열을 알아서 추출할까 ?? 사실 그렇지 않다.
그렇다면 잘못된 번역이나 휴먼에러가 발생할 가능성이 있으므로 어떤 기준으로 추출할까??
앱 내에서 자동으로 추출되기 위해 간단한 예를 통해 원리를 이해해보자.
단순 String과 Text 뷰
struct ContentView: View {
var text: String = "Lello"
var body: some View {
Text("Hello")
.padding()
}
}
먼저 단순 String 값인 "Lello"와 Text 뷰에 넣어진 "Hello"는 Catalog에서 인식할까??
결과는 단순 String인 Lello는 추출 X, Text 안의 String은 추출 O
이유가 뭘까??
Text 구조체안에 LocalizedStringKey라는 의심가는 속성이 있다.
이번에 "Lello"를 추출할 수 있게 조금의 코드 수정을 해보자.
truct ContentView: View {
var place: LocalizedStringKey = "Lello"
@State var text: String = ""
var body: some View {
VStack {
Text("Hello")
.padding()
TextField(place, text: $text)
}
}
}
TextField안에도 역시 LocalizedStringKey라는 녀석을 통해 만드니깐 자동으로 "Lello" 역시 추가되었다.
그러면 우리는 LocalizedStringKey를 이용하면 자동으로 추출할 수 있게 할 수 있다고 생각할 수 있다.
그렇다면 활용해보자.
Enum에 적용
변수에 LocalizedStringKey를 적용하니 잘 추적한다.
enum Country: String {
case kr
case us
var title: LocalizedStringKey {
switch self {
case .kr: return "South Korea"
case .us: return "United States"
}
}
}
🔎 LocalizedStringResource
조금만 더 알아보자. 일단 지금까지 내용은 LocalizedStringKey 있는것을 빌드 시점에 찾아서
카탈로그에 추가된다는 것이다.
그런데여기서 LocalizedStringKey의 친구가 하나 있다. LocalizedStringResource 이다.
둘의 차이는 뭘까??
1. LocalizedStringKey
- 주로 SwiftUI에서 텍스트를 로컬라이즈할 때 사용
- 키를 기반으로 로컬라이즈된 문자열을 탐색
- tableName 파라미터를 통해 저장될 strings 파일을 지정할 수 있음
- UIKit에서 사용 ❌
- 런타임에 처리하므로 타입 안정성이 떨어짐
2. LocalizedStringResource
- 새로운 로컬라이제이션 API로, SwiftUI와 UIKit 양쪽에서 사용할 수 있음.
- SwiftUI 5.9+ 또는 최신 환경에서 도입
- 컴파일 타임에 키의 유효성 검사가 가능해, 타입 안정성이 높음
LocalizedStringKey | LocalizedStringResource | |
도입시기 | SwiftUI 초기 | Swift5.9 이상 최신버전 |
타입 안전성 | 낮음 | 높음 |
프레임워크 | SwiftUI | SwiftUI, UIKit |
유효성 검사 | 런타임 | 컴파일 타임 |
복잡한 데이터처리 | 제한적 | 더 많은 지원 |
😂 String init (24.12.29 추가)
찾아보니 String Extension에 쉽게 사용하라고 생성자가 있어서 여기에 key를 추가해도 자동으로
카탈로그에 추가된다.
extension String {
public init(localized resource: LocalizedStringResource)
public init(localized resource: LocalizedStringResource, options: String.LocalizationOptions)
}
✅ State와 복수형 지원
String catalog는 다양한 State와 복수형을 지원하는데 하나씩 알아보자.
State
총 4가지 State를 지원한다
State | Description |
STALE | 해당 문자열을 코드에서 찾을 수 없음 Menually 관리되는 키들은 Xcode 빌드 시 업데이트 되지 않아 이 때 많이 발생할 수 있는 상태 |
NEW | 아직 번역되지 않은 상태 |
NEEDS REVIEW | 값이 변경될 수 있는 문자열이므로 번역가의 주의가 필요한 키 Indicator에서 Mark as Review로 표시할 수 있음 (위 사진참고) |
Translated | 번역 체크 완료 |
Pluralization
두번 째 도전은 복수화다.
다음과 같이 우리는 앞의 수량이 나타날 때 뒤에 오는 문자열이 종속적인 경우가 많다.
이 때 이전의 stringdict 파일을 이용하면 다음과 같이 굉장히 번거로운 작업을 했어야 했다.
string catalog는 다음과 같이 powerful 한 기능을 제공한다
조금 더 복잡한 경우를 살펴보자
다음과 같이 2가지 변수에 대해 birds와 backyards는 복수 또는 단수가되는 경우의 수가 총 4가지가 있다.
이 때 우리는 오른쪽 같이 정리하면 알아서 변수의 상태를 파악해 종속된 문자열 복수 또는 단수로 바꿔준다.
😀 소감 및 마무리
간단하게 쓰는 법만 살펴보려 했는데 WWDC23년 내용까지 다시봤다.
작년 애플 개발자 아카데미에서 WWDC를 새벽에 같이 볼 때 Vision OS에 시선을 너무 뺏겨
String Catalog 내용이 기억이 나지 않다.
물론 Localization 경험이 없어서 더 그런 듯 ?? .. ]
시간 날 떄 23, 24 꺼 다시 살펴보자 ㅜ
출처
'iOS' 카테고리의 다른 글
패키지 만들기 (0) | 2025.01.07 |
---|---|
FirebaseCrashlytics 적용하기 with SPM (3) | 2024.12.26 |
[ 부스트 캠프 ] 채팅 기능을 위한 웹소켓 만들기 (1) | 2024.11.30 |
[부스트 캠프] 우리만의 네트워크 만들기 (0) | 2024.11.27 |