앱을 다국어로 만들기 (재작성 없이)

Source: Dev.to

번역할 텍스트를 제공해 주시면 한국어로 번역해 드리겠습니다.

Find the Middle Ground

There’s a pragmatic middle ground between “English only” and “fully localized in 40 languages.” Most teams never find it because the discussion jumps straight from “we need Spanish” to “okay, let’s implement i18n across the entire codebase.” That’s a months‑long project. There are faster ways to start.

중간 지점 찾기

**“English only”**와 “fully localized in 40 languages.” 사이에는 실용적인 중간 지점이 있습니다. 대부분의 팀은 토론이 *“we need Spanish”*에서 *“okay, let’s implement i18n across the entire codebase.”*로 바로 넘어가기 때문에 이를 찾지 못합니다. 이는 몇 달이 걸리는 프로젝트입니다. 시작할 수 있는 더 빠른 방법이 있습니다.

사용자 중심 콘텐츠부터 시작하기

언어가 실제로 사용자 경험에 영향을 미치는 애플리케이션의 부분에 집중하세요:

• 제품 설명
• 도움말 기사
• 이메일 알림
• 오류 메시지
• 온보딩 흐름

이곳은 비영어 사용자가 장벽에 부딪히는 부분입니다. 영어 네비게이션 바는 어느 정도 견딜 수 있을지 모릅니다—버튼 레이블은 여러 언어에서 인식되는 경우가 많지만—하지만 중요한 기능을 설명하는 도움말 기사나 무엇이 잘못됐는지 알려주는 오류 메시지는 반드시 사용자의 언어로 제공되어야 합니다.

콘텐츠 번역은 전체 UI 프레임워크를 국제화하는 것보다 훨씬 작고 제한된 프로젝트이며, 사용자 가치의 대부분을 제공합니다.

기계 번역 vs. 인간 번역

MT의 진화

Five years ago, machine translation (MT) was a punchline. Google Translate could turn a French restaurant menu into surrealist poetry, and professional human translators were the only serious option.

That’s changed. Modern MT handles most European and major Asian languages well. It’s not perfect—it struggles with idioms, cultural references, and highly technical jargon—but for straightforward content (product descriptions, support articles, transactional emails) the quality is genuinely usable.

MT가 잘 작동하는 경우 (그리고 잘 작동하지 않는 경우)

• 첫 번째 카테고리: MT는 80‑90 % 정도의 품질을 제공합니다.
• 두 번째 카테고리: 여전히 인간 번역가가 필요하지만, 그 양은 훨씬 적습니다.

Detecting the Right Language

번역을 시작하기 전에 사용자가 실제로 원하는 언어를 파악해야 합니다. 잘못 추측하는 것은 번역을 전혀 하지 않는 것보다 더 나쁩니다. 다음과 같은 신호들이 도움이 될 수 있습니다:

1. 브라우저 언어 헤더 – 가장 신뢰할 수 있는 자동 신호입니다. 모든 HTTP 요청에는 사용자가 선호하는 언어 목록을 담은 Accept-Language 헤더가 포함됩니다.
   예시: es-MX,es;q=0.9,en;q=0.8 → 멕시코 스페인어 > 일반 스페인어 > 영어.

2. 계정 설정 – 최상의 기준입니다. 사용자가 프로필에서 직접 언어를 선택합니다. 설정을 한 로그인 사용자에게만 적용됩니다.

3. 콘텐츠 언어 감지 – 사용자 생성 입력(지원 티켓, 양식 제출 등)에 유용합니다. 제출된 텍스트의 언어를 감지하고 그에 맞춰 응답합니다.

4. 지리적 신호 – 대략적인 대체 지표(예: 일본에 있는 사용자는 일본어를 선호할 가능성이 높음). 해외 거주자, 여행자, 다언어 국가(스위스, 인도)에서는 부정확할 수 있습니다. 기본값으로만 사용하고 사용자가 직접 재설정할 수 있게 해야 합니다.

Pragmatic layering

• Primary: 계정 설정(가능한 경우)
• Secondary: 브라우저 Accept-Language 헤더
• Tertiary: 사용자 생성 콘텐츠의 언어 감지

번역 우선순위 정하기

1. 온보딩 흐름 – 가장 높은 우선순위. 사용자가 가입 절차를 이해하지 못하면 절대 사용자가 되지 못합니다.
2. 거래 이메일 – 주문 확인, 비밀번호 재설정, 청구 알림. 사용자는 서비스를 이용하려면 이를 이해해야 합니다.
3. 오류 메시지 – 결제 실패 오류가 영어로만 제공되면 스페인어 사용자는 쓸모가 없습니다. 오류를 번역하면 지원 티켓이 크게 감소합니다.
4. 도움말 문서 및 지원 기사 – 셀프 서비스가 가능해지고 다국어 지원 직원을 고용하는 것보다 더 효율적으로 확장됩니다.
5. 마케팅 페이지 – 우선순위는 가장 낮지만 가시성은 가장 높습니다. 영어를 읽지 못하는 잠재 고객은 현지화된 검색 결과를 통해 귀사를 찾았을 가능성이 높으므로 현지화된 랜딩 페이지가 필수적입니다.

프로그래밍 방식으로 콘텐츠 번역하기

// Example: calling a translation API
const response = await fetch('https://api.apiverve.com/v1/translator', {
  method: 'POST',
  headers: {
    'x-api-key': 'YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    text: 'Your payment was processed successfully.',
    target: 'es'               // target language code
    // source: 'en'            // optional; omitted → auto‑detect
  })
});

const { data } = await response.json();
// data.translatedText → "Su pago fue procesado exitosamente."
// data.sourceLang    → "en"

• Note: source 매개변수는 선택 사항입니다. 생략하면 API가 원본 언어를 자동 감지합니다. 이는 원본 언어를 알 수 없는 사용자 생성 콘텐츠를 처리할 때 유용합니다.

번역된 문자열은 어디에 저장되나요?

이는 귀하의 아키텍처에 따라 다릅니다. 일반적인 패턴은 다음과 같습니다:

• 로케일당 별도의 JSON/YAML 파일 (예: en.json, es.json).
• 동적 콘텐츠용 데이터베이스 테이블 (제품 설명, 도움말 기사 등).
• CMS‑기반 현지화로, 편집자가 콘텐츠 관리 시스템에서 직접 번역을 관리합니다.

콘텐츠를 저장하고 제공하는 방식에 맞는 접근 방식을 선택하세요.

국제화 전략

번역을 저장할 위치

• Database – 제품 설명이 데이터베이스에 있다면 locale 컬럼을 추가하고 번역된 버전을 별도의 행으로 저장합니다.
  동일한 콘텐츠 ID, 다른 로케일.

• Translation files – UI 문자열에 적합합니다. 로케일별(en.json, es.json, fr.json)로 키가 지정된 JSON 파일은 표준 i18n 접근 방식이며 대부분의 프론트엔드 프레임워크가 이 패턴을 기본 지원합니다.

  // en.json
  {
    "welcome": "Welcome",
    "login": "Log in"
  }
  
  // es.json
  {
    "welcome": "Bienvenido",
    "login": "Iniciar sesión"
  }

• Generated on the fly – 자주 변경되거나 번역이 완벽할 필요가 없는 콘텐츠에 적합합니다.
  예시: 실시간 지원 채팅 메시지 번역. 사용자는 번역이 즉시 표시되지만 손질되지 않았을 수도 있습니다.

• Cached after first translation – 비용과 최신성을 균형 있게 유지합니다. 특정 언어로 처음 요청될 때 번역하고 결과를 캐시한 뒤 이후에는 캐시에서 제공하여 API 호출을 줄이고 번역을 지속적으로 사용할 수 있게 합니다.

올바른 접근 방식은 종종 이러한 방법을 조합합니다:

• 번역 파일에 정적 UI 문자열 저장.
• 데이터베이스에 로케일 컬럼을 사용한 콘텐츠 저장.
• 채팅 및 사용자 생성 콘텐츠에 대한 실시간 번역.

먼저 추가할 언어 선택

언어 선택은 비즈니스 결정이며 순수 기술적인 판단만으로는 결정되지 않습니다.

1. 분석 데이터 확인 – 현재 사용자는 어디에 있나요?

   • 트래픽의 15 %가 스페인어 사용 국가에서 온다면 스페인어가 가장 명확한 첫 번째 언어입니다.
   • 브라질에서 트래픽이 증가하고 있다면 포르투갈어를 높은 우선순위에 두어야 합니다.

2. 시장 전략 고려 – 특정 지역으로 확장하려는가? 해당 지역에 진출하기 전에 그 지역 언어를 번역하고, 진출 후에 번역하지 마세요.

3. 언어 도달 범위 생각 –

   • Spanish – 20개 이상의 국가.
   • French – 유럽, 아프리카, 아메리카.
   • Mandarin – 세계에서 가장 많은 인구.
   • Arabic – 넓은 지리적 영역.

   이러한 고도달 언어들은 번역 투자 대비 가장 큰 수익을 제공합니다.

4. 언어 유사성 – 이미 스페인어로 번역했다면 포르투갈어는 추가 노력이 적습니다. 두 언어는 어휘와 구조가 크게 유사하기 때문에 두 번째 단계가 첫 번째보다 실제로 더 쉬운 경우가 드뭅니다.

번역 품질을 지속적으로 개선하기

• 기계 번역은 시작점일 뿐, 최종 상태가 아닙니다. 시간이 지나면서 피드백을 활용해 번역을 개선하세요.

• 사용자 생성 교정 – “더 나은 번역 제안” 링크를 작게 추가해 이중 언어 사용자가 기여할 수 있게 합니다. 크라우드소싱 교정은 품질을 자연스럽게 향상시킵니다.

• 고트래픽 페이지에 대한 인간 검토 – 홈페이지, 가격 페이지, 결제 흐름은 전문 번역이 필요합니다. 비용은 적당하고 전환율에 미치는 영향은 측정 가능합니다.

• 지원 티켓 분석 – 언어별 티켓을 추적합니다. 스페인어 사용자가 특정 기능에 대해 지속적으로 지원을 요청한다면 해당 기능에 대한 번역 문서가 개선이 필요할 가능성이 높습니다.

• 번역 품질은 스펙트럼임을 받아들인다 – 오늘 80 % 수준의 번역을 제공하는 것이 6개월 뒤에 완벽한 번역을 제공하는 것보다 낫습니다. 그 6개월 동안 잃게 될 사용자는 돌아오지 않을 가능성이 높습니다.

실용적인 API 사용법

• Translate content – Translation API를 사용합니다.
• Detect source language – Language Detection API를 사용합니다.

이 서비스들을 활용하면 처음부터 모든 것을 구축하지 않아도 전 세계 사용자에게 다가갈 수 있습니다.

원본은 APIVerve Blog에 게시되었습니다.