2025. 6. 25. 00:25ㆍDeveloper Basis/Xcode
Localizing and varying text with a string catalog | Apple Developer Documentation
Use a string catalog to translate text, handle plurals, and vary the text your app displays on specific devices.
developer.apple.com
Code-along: Explore localization with Xcode - WWDC25 - Videos - Apple Developer
Learn how to localize your app into additional languages using Xcode. We'll walk step-by-step through the process of creating a String...
developer.apple.com
String Catlog란 무엇인지요?
쉽게 말하면 앱에 들어가는 모든 글자 (String, 문자열)를 모아두는 정리함이라고 생각하면 됩니다.
한 프로젝트에서 사용하는 텍스트를 이렇게 한 곳에 모아 관리하는 이유는 주로 "앱의 다국어 지원"을 위함이 가장 크죠.
예를 들어 미국과 한국 모두 지원가능한 앱을 만들고자 할 때,
탭바 아이템에 사용되는 타이틀 값이 미국에서는 영어로 / 한국에서는 한글로 (국가가 아니더라도 앱의 시스템 언어 설정 값을 따르도록) 표출하도록 하는 기능을 이 String Catalog를 통해 비교적 깔끔하게 구현할 수 있습니다.
하지만 다국어 지원이 아니더라도 String Catalog를 사용할 수 있는 상황이 더 있습니다.
바로 파라미터에 들어오는 값에 따라 "복수형을 처리"한다던지 (1 book, 2 books와 같은). "Device에 따라" 다른 문자를 표출한다던지 (iOS - Tap Button, macOS - Click Button과 같은) 등의 처리를 할 때도 활용할 수 있다고 합니다!
사용은 아주 간단합니다.
기존 프로젝트 코드에 String Catalog 파일을 프로젝트에 추가하기만 해주면, 기존 String이 모두 해당 String Catalog 파일에 저장되어 개발자가 관리할 수 있는 방식이죠!
더 자세하게, 프로젝트에 파일을 추가하는 것부터 관리하는 과정을 지금부터 설명해보도록 하겠습니다. 따라오시죠💨
Xcode에서 String Catalog 파일 세팅하기
🤔 String Catalog 파일은 어떻게 추가할까요?
String Catalog는 프로젝트 파일을 추가하는 방식과 동일합니다.
Resource 부분에 있는 "String Catalog" 파일을 추가해주면 되죠.
기본적으로 "Localizable.xcstrings"라는 이름 그대로 생성하는 편이지만 / 분리되어 있는 모듈 구조에 따라 "모듈이름.xcstrings"로 생성하는 경우도 있습니다.
.xcstrings 파일이 생성되면, 기본적으로 비어있는 화면 (Empty String Catalog)이 나타납니다.
하지만 프로젝트를 한 번이라도 빌드해준 이후에는 localizable (현지화 가능한) String을 탐색한 뒤,
생성된 String Catalog 파일에 자동으로 String이 추가되는 것을 확인할 수 있습니다.
*여기서 Xcode가 localizable String을 탐색한다는 것의 의미 : 기본적으로 사용하는 View (Text나 Button 등)에 사용된 String / 그리고 개발자가 수동으로 입력한 `String(localized:)`코드를 포함하는 내용입니다.
🤔 String Catalog 파일에 추가되어있는 String이 어느 코드에서 사용되는지 알 수는 없나요?
String Catalog 파일 우측 상단을 통해 Editor Control 메뉴에 들어가 -> "Assistant" 버튼을 누르게 되면,
우측에 펼쳐지는 Assistant 화면을 통해 해당 String이 프로젝트 파일 중 어디 코드에서 사용되고 있는지 확인할 수 있도록 도와줍니다.
🤔 새로운 언어는 어떻게 추가하나요? (Localization 방법)
위에서 언급한 것처럼 String Catalog를 사용하는 가장 주된 이유는 "앱의 다국어 지원"을 위함이었습니다.
처음 String Catalog 파일에는 좌측에 하나의 기본 언어만 세팅되어 있을 텐데요. 언어를 추가하는 방법에 대해 알아보도록 하겠습니다.
.xcstrings 파일 좌측 하단에 위치한 + 버튼을 누르면 추가할 수 있는 언어가 많습니다.
지원하고자 하는 언어를 선택해서 추가해줍시다!
방금 추가한 언어를 클릭해 String Catalog 테이블을 들어가보면,
기본 언어 (Default Localization) 열 오른쪽에 / 방금 추가한 언어의 항목을 타이틀 (Korean (ko))로 갖는 열이 새롭게 추가된 것을 확인할 수 있습니다.
해당 열에 번역 텍스트를 써주기만 하면 끝입니다!
네. 이렇게 번역 텍스트를 써주면 되는데.....사실 하나의 언어만 더 추가한다고 하더라도 모든 String에 대해 일일이 하나씩 입력한다고 하면 너무 비효율적이라는 생각이 들지 않나요...?
이게 말이 쉬워서 언어 하나를 추가하는거지.
만약 한국어, 영어, 일본어, 중국어를 다 지원한다고 하면 언제 다 입력할 것이며 / 이 모든 언어를 개발자들이 번역을 일일이 할 수 있는 노릇도 아닌데... 참 문제가 있죠!
그래서 Apple은 이 전체 텍스트 파일을 내보내서 (Export) 번역하고, 번역이 끝나면 다시 가져오는 (Import) 기능을 추가하게 됩니다.
번역 서비스에서 쉽게 업계 표준으로 사용하고 있는 XLIFF 파일의 형태로 사용할 수 있다고 합니다. (뭔지는 잘 모르지만)
아무튼 개발자 딴에서는 해당 텍스트 모음집인 .xcloc 파일을 그대로 번역가에게 전달해서 요청하기만 하면 되는 흐름인거죠!
사용은 매우 간단합니다.
상단바 Product를 클릭하면 파일 추출하는 "Export Localization" / 파일을 적용하는 "Import Localization"을 각각 클릭해주기만 하면 됩니다.
이렇게 적용한 Localization이 잘 적용되었는지 Simulator에서 확인하는 방법까지 알아보겠습니다.
상단에 있는 Schema Editor (시뮬레이터를 할 때 클릭하는 버튼 왼쪽. 앱 아이콘과 앱 이름 부분)를 눌러서 -> Edit Schema -> Run -> Options -> App Language에서 확인하고 싶은 언어를 지정할 수 있습니다.
이 상태에서 Run을 하면 지정한 언어로 앱이 동작합니다! 참 간단하군요 ^__^
Translation context : 번역이 필요한 텍스트에 맥락 (comment)을 포함하는 방법
위와 이어지는 내용입니다.
Export Localization으로 추출된 XLIFF 파일을 받게 된 번역가들은 파일 내에 단순하게 써있는 문자열만 보고 번역을 할 수밖에 없을 겁니다.
다른 코드나 앱이 어떻게 실행되는지 맥락을 보면서 번역할 수 있는 환경이 아니죠.
💡 그렇기 때문에 개발자들은 번역가들에게 localization에 필요한 앱의 추가적인 맥락 (context)을 제공할 필요가 있습니다.
여기서 필요한 좋은 코멘트 (comment)는 아래와 같은 맥락이 포함되어 있는 것들을 의미할 거예요!
- 해당 문자열이 앱의 어떤 인터페이스 요소 (버튼, 타이틀 등)에 사용되는지 설명한 것. (Interface element)
- 혹은 주변에 있는 인터페이스 요소 (예를 들어, 사이드바에서 표출되는 / 탭바에 있는)를 설명하는 것. (Surrounding UI)
- 플레이스홀더 (예를 들어, %@로 표시되는 자리에는 어떤 값이 위치한다는 등)에는 어떤 종류의 컨텐츠가 나타날 수 있는지 설명한 것 (Placeholder content)
String Catalog는 두 가지 방법으로 텍스트에 포함된 맥락을 제공할 수 있습니다.
코드에 직접 comment:라는 파라미터로 추가하는 방식과, Localizable.xcstrings 파일에 있는 Comment 열에 추가하는 방식이 그것이죠.
하지만 이 역시도 "언제 번역과 더불어 일일이 쓰고 있겠어..."라는 생각이 들 수 있을 텐데요..!
그래서 놀랍게도 Xcode 26부터는 "Automatic comment generation"이라는 "자동 주석 생성 기능"을 지원하게 되었다는 사실!
String Catalog 파일을 보면 알겠지만, 기본적으로는 모든 String Key에 대해 Comment가 생성되지는 않습니다. (왜인지는 모름..)
아무튼 그래서 Comment가 달려있지 않은 String에 대해 추가적인 맥락을 자동으로 작성하게끔 만들 수 있답니다!
Context Menu를 열고 -> Generate Comment 버튼을 누르게 되면 Xcode는 해당 String이 사용된 위치를 기반으로 자동으로 Commnent를 추가해주는 간단한 방식이죠.
또한 물론으로 이렇게 자동으로 생성된 Comment에 대해서 직접 접근해 수정하는 것도 가능하도록 열려있습니다.
그리고 모든 String에 대해 자동으로 Comment를 추가하도록 Xcode의 default Setting 값을 수정할 수도 있습니다.
방식은 상단 Xcode 메뉴바의 Setting으로 진입한 뒤,
Editing -> Localized Strings -> Automatically generate string catalog comments 토글을 켜주면 됩니다.
이렇게 설정값을 바꾸는 경우 / 번역가에게 전달되는 XLIFF 파일에는 <note from="auto-genetated">라는 주석이 붙어 "해당 커멘트가 자동으로 생성된 내용이다"라는 것을 인지할 수 있도록 도와준다고 합니다.
Generated Symbols : String Catalog를 String을 더 잘 관리하기 위해 사용해보자!
그리고 마지막으로 WWDC25에서 새로운 String Catalog의 기능으로 소개된 내용을 정리해 보겠습니다.
위의 내용까지 들어봤을 때 이전 String Catalog는 코드에서 -> String을 자동으로 뽑아주고, 그것을 활용하는 흐름이었다면.
이번에는 String의 모음집을 직접 어찌저찌 만들면 -> 코드에서 조금 더 쉽게 사용할 수 있게 한다는 내용입니다.
내용을 어렵게 말해서 그렇지.. 쉽게 말하면 직접 enum으로 StringLiterals 파일을 만들지 않아도 된다는 의미입니다!
보통은 프로젝트에서 사용하는 String을 별도의 StringLiterals라는 enum으로 관리해서 사용했습니다.
반복되는 String을 한 번에 관리할 수 있고 / String을 이곳저곳에서 작성할 때 발생할 수 있는 오타를 사전에 방지하기가 용이하기 때문이었죠.
하지만 이제는 String Catalog를 사용하면 위의 enum 스타일 코드를 작성한 것처럼 활용할 수 있습니다.
좌측 상단 + 키를 통해 추가하고 싶은 String을 만드는 것이 기본 기능입니다.
이후에는 카테고리 / 키로 접근하면 해당 String에 접근할 수 있도록 만들 수 있고 (직접 Key값도 지정할 수 있습니다),
오른쪽 Inspector 화면에서는 해당 String을 예시로 어떻게 사용할 수 있는지 (Example Usages)도 보여줍니다. 되게 친절하네요.
추가적인 기능으로는,
플레이스홀더 (Placeholder)를 어떤 양식으로 써야할지도 걱정하지 않아도 된다는 점. -> %를 입력하면, format specifie로 사용할 수 있는 것들을 Xcode가 지원해서 뽑아주기 때문!
플레이스홀더의 파라미터 내용도 보기 좋게 커스텀할 수도 있다는 점.
이때 실제 사용하는 코드 부분은 지정한 Key값을 기반으로 자동으로 Swift Coding Style에 맞춰 접근할 수 있게 이름까지 만들어줍니다.
기존 방식처럼 String Catalog가 코드에서 자동으로 추출된 값으로 구성되었더라도 Symbol을 만드는 것 또한 가능합니다.
Symbol을 만들어 활용하기를 원하는 String 값을 선택한 다음에 Refactor -> Convert Strings to Symbols를 클릭해주면 끝입니다.
자동으로 위에서 봤던 ".카테고리.키이름"의 형태로 이제 접근할 수 있게 될 거에요!
표출되는 Symbol 값을 변경하거나, Key 값도 의미가 명시적으로 드러나도록 수정하면 더 사용하기가 유용할 것 같습니다!
그렇다면, 앞으로 String Catalog는 어떻게 활용해야하는 것일까?
시작은 기존 방식대로 문자열 추출 (Extraction from code) 방식을 권장한다고 말합니다.
UI 코드와 함께 써있는 String이 코드를 더 빨리 읽고 이해하는데 도움을 준다는 이유 때문이죠! + WWDC25에서 처음 소개된 Commnet Generation 기능도 함께 활용할 수 있다는 이유도 여기서 포함합니다!
-> 소규모 프로젝트는 StringLiterals의 사용과 같은 안정성보다 / 코드에 명시적으로 드러나는 직관성과 가독성을 중요시한다는 의미!
단, 프로젝트의 규모가 커질수록 + Srting을 더 효율적으로 제어하고 싶을 때, 그때 새로운 심볼 생성 (Generated Symbols) 방식을 사용하라고 소개합니다.
이번 기능은 Apple이 계속 이어오고 있는 Xcode 업데이트 흐름에 이어진다고 생각이 들더군요!
Color, Asset도 별도의 커스텀 타입없이 기본 Xcode의 내장 메서드로 접근할 수 있게 된 것처럼. String 역시 별도의 커스텀 타입이 필요 없어진 것이니까요. (앞으로 커스텀 폰트도 기대해봐도 될까나..? 보여주나?)
우선 토스터부터 String 관리를 String Catalog 방식으로 리팩토링해봐야겠습니다.
다국어 지원도 생각해봐야 할 때인 것 같고요. 오늘 글은 여기까지 ✌🏻
'Developer Basis > Xcode' 카테고리의 다른 글
| [Xcode] Group vs Folder 차이점 한 눈에 비교하기 (feat. Xcode 16) (1) | 2025.01.24 |
|---|---|
| [Xcode] Xcode에서 Python 알고리즘 환경 구축하는 방법 (feat. Xcode 15.4 버전) (2) | 2024.09.06 |
| [Xcode] Xcode 커스텀하는 두 가지 방법 (Code Theme, App Icon) (1) | 2023.12.03 |
| [Xcode] iOS 프로젝트에 별도의 폰트 파일을 추가해서 사용하고 싶을 때 (3) | 2022.01.02 |
| [Xcode] Xcode에서 quick help를 사용해보자 (0) | 2021.12.20 |