이 페이지는 AI로 자동 번역되었으며 부정확한 내용이 포함될 수 있습니다. 번역 오류를 신고하려면 페이지 오른쪽 목차 아래에 있는 피드백 기능을 사용하세요.
다국어 번역 관리 접근 방식 비교
현지화된 문구가 저장, 업데이트, 미리보기 및 전송되는 방식을 평가하여 QA 워크플로, 채널 구성, 업데이트 빈도에 맞는 현지화 접근 방식을 선택할 수 있습니다.
이 예시 소개
가상의 주방용품 소매업체인 Kitchenerie는 이메일, 푸시, 인앱 메시지를 영어, 프랑스어, 독일어로 보냅니다. 마케팅 팀과 엔지니어링 팀은 여러 Campaigns에서 번역을 반복적이고 확장 가능한 방식으로 관리할 방법이 필요합니다.
Braze는 다음과 같은 여러 현지화 방식을 지원합니다.
- 수동 조건부 Liquid: 메시지 본문에 언어별로 직접 입력한 문구
- Content Blocks: 재사용 가능한 블록(다국어 번역 태그 사용 여부와 관계없음)
- 카탈로그: 로캘을 키로 사용하는 구조화된 번역 행
- 다국어 메시지: 번역 태그, CSV 업로드, 번역 API(얼리 액세스)
- 번역 파트너: Smartling, Phrase, Lokalise 등
- 연결된 콘텐츠: 발송 시점에 CMS 또는 API에서 가져오는 현지화된 문자열
이 예시는 각 방식의 장단점을 비교하여 QA 워크플로, 채널 구성, 업데이트 빈도, 팀 리소스에 맞는 방식을 선택할 수 있도록 도와줍니다. 특정 방식의 단계별 설정 가이드를 대신하지는 않습니다. 기능별 안내는 현지화 및 다국어 메시지부터 확인하세요.
고려 사항
- 패턴을 선택하기 전에 대시보드 미리보기 및 QA, 전문 번역 워크플로, 잦은 콘텐츠 업데이트, 또는 CMS 기반의 실시간 문구 중 어떤 것이 필요한지 결정하세요.
- 다국어 메시지는 이메일, 푸시, 배너, 인앱 메시지, Content Blocks를 지원합니다. SMS와 WhatsApp은 다른 현지화 패턴을 사용한다는 점에 유의하세요. 수동 Liquid, Content Blocks, 카탈로그, 파트너, 연결된 콘텐츠는 해당 기능이 지원되는 채널 전반에 적용할 수 있습니다.
- Braze는 번역을 생성하지 않습니다. 대시보드, CSV, API, 카탈로그 가져오기, 파트너 워크플로 또는 외부 CMS를 통해 문구를 직접 제공해야 합니다.
- 조건문이 포함된 수동 Liquid와 Content Blocks는 언어가 늘어날수록 명명 규칙과 검토 프로세스가 필요합니다. 다국어 및 파트너 워크플로는 업데이트를 한곳에서 관리할 수 있지만 CSV 또는 API 유지 관리가 필요할 수 있습니다.
- 연결된 콘텐츠와 일부 파트너 흐름은 외부 시스템에 의존합니다. 전송 시점에 API 또는 CMS를 사용할 수 없으면 현지화된 콘텐츠가 로드되지 않을 수 있습니다.
- 여러 패턴을 함께 사용하는 경우가 많습니다. 예를 들어, 한 프로그램에서 이메일 본문에는 다국어 태그를, 공통 푸터에는 Content Blocks를, 제품 문구에는 카탈로그를 사용할 수 있습니다.
설정
1단계: 현지화 요구 사항 파악
| 요구 사항 | 확인할 질문 |
|---|---|
| 미리보기 및 QA | 마케터가 발송 전에 Braze 작성기에서 각 로캘을 미리 확인해야 하나요? |
| 규모 | 몇 개 언어를 지원하며, 문구는 얼마나 자주 변경되나요? |
| 워크플로 | 번역가 검토, 수정, 승인 절차가 필요한가요? |
| 데이터 형태 | 문구가 자유 형식의 마케팅 텍스트인가요, 아니면 구조화된 제품 필드(이름, 가격, URL)인가요? |
| 자동화 | CMS가 변경되면 번역도 자동으로 업데이트되어야 하나요? |
| 팀 역량 | 팀에서 Liquid, CSV 업로드, API 또는 파트너 통합을 유지 관리할 수 있나요? |
2단계: 접근 방식 비교
| 차원 | 수동 Liquid | Content Blocks | 카탈로그 | 다국어 메시지 | 번역 파트너 | 연결된 콘텐츠 |
|---|---|---|---|---|---|---|
| 대시보드 미리보기 / QA | 예 | 예 | 예 | 예 | 파트너마다 다름 | 제한적—가져온 콘텐츠는 미리보기가 어려움 |
| 기본 제공(통합 불필요) | 예 | 예 | 부분적—카탈로그 설정 필요 | 예 | 아니요—공급업체 설정 필요 | 아니요—API 또는 CMS 필요 |
| 채널 지원 범위 | 지원되는 모든 채널 | 지원되는 모든 채널 | 지원되는 모든 채널 | 이메일, 푸시, 배너, 인앱 메시지, Content Blocks | 파트너마다 다름 | 지원되는 모든 채널 |
| 구현 난이도 | 낮음 | 낮음~중간 | 중간 | 낮음 | 높음(파트너에 따라 다름) | 중간 |
| 지속적인(BAU) 작업량 | 높음—메시지별 편집 | 중간—블록 유지 관리 | 중간—CSV 또는 API 업데이트 | 중간—CSV 업로드 | 중간—플랫폼에서 관리 | 낮음—발송 시점에 가져옴 |
| 잦은 업데이트 | 아니요 | 부분적 | 아니요 | 부분적 | 예 | 예 |
| 전문 번역 워크플로 | 아니요 | 아니요 | 아니요 | 아니요 | 예 | 아니요 |
| 구조화된 데이터 / 제품 데이터 | 제한적 | 제한적 | 예—키 기반 문구에 이상적 | 제한적 | 다름 | 예—외부 소스를 통해 |
| 외부 의존성 위험 | 없음 | 없음 | 없음 | 없음 | 중간 | 중간—소스가 다운되면 발송 실패 |
| 적합한 경우 | 언어 수가 적고 업데이트가 드문 경우 | 여러 메시지에서 공유하는 구성 요소 | 구조화된 문자열을 여러 로캘로 관리 | 복사·붙여넣기 작업을 줄이면서 여러 언어 지원 | 승인 절차가 있는 엔터프라이즈 번역 | CMS 기반의 동적 현지화 |
3단계: Kitchenerie 스타일 시나리오에 맞는 접근 방식 선택
| Kitchenerie 시나리오 | 권장 시작점 |
|---|---|
| 3개 언어, 월별 Campaign 수가 적고 마케팅 팀 규모가 작은 경우 | 수동 조건부 Liquid 또는 Liquid를 사용한 Content Blocks |
| 이메일과 인앱 메시지 전반에서 공유하는 헤더, 푸터, 법무 블록 | Content Blocks—로캘이 늘어나면 블록에 다국어 번역 저장 |
| 로캘별 키로 관리하는 제품명, 프로모션 문구, 이미지 URL | 카탈로그 |
| 작성기 미리보기가 필요한 8개 이상 로캘의 이메일 및 푸시 | 다국어 메시지 |
| 번역가 워크플로와 승인 절차를 갖춘 중앙 TMS | 현지화 파트너(예: Smartling 또는 Phrase) |
| 매일 업데이트되는 CMS에서 관리하는 문구 | 연결된 콘텐츠 |
4단계: 선택한 접근 방식 구현
- 수동 조건부 Liquid: 프로필의
language또는 로캘 속성과if/elsif/elseLiquid를 함께 사용합니다. 대체 접근 방식 및 조건 로직을 참조하세요. - Content Blocks: 재사용 가능한 블록을 만들고, 필요하면 조건부 Liquid를 블록 안에 숨깁니다. Content Blocks 및 번역된 메시지 보내기의 Content Blocks 탭을 참조하세요.
- 카탈로그: 번역 행(예:
id,context,language,body)을 가져온 다음 Liquidcatalog_items로 참조합니다. 번역된 메시지 보내기의 카탈로그 탭을 참조하세요. - 다국어 메시지: 로캘을 추가하고 문구를 번역 태그로 감싼 다음 CSV를 업로드합니다. 번역 엔드포인트에 대한 얼리 액세스 권한이 있다면 API로 번역을 업데이트할 수도 있습니다. 작성기에서 다국어 사용자로 미리 확인하세요.
- 번역 파트너: 워크스페이스 로캘을 구성한 다음 사용 중인 파트너 통합 안내를 따릅니다(예: Smartling 또는 Phrase).
- 연결된 콘텐츠: 발송 시점에 CMS 또는 번역 API를 호출합니다. 미리보기에는 실시간 API 응답이 반영되지 않을 수 있으므로 충분히 테스트하세요. 연결된 콘텐츠를 참조하세요.
지역별 Canvas 및 Campaign 오케스트레이션(하나의 여정으로 운영할지, 국가별로 여정을 하나씩 운영할지)에 대해서는 현지화 페이지의 번역 관리를 참조하세요.
관련 문서
New Stuff!