5.5 국제화와 현지화

개요와 동기

국제화(i18n)는 코드를 바꾸지 않고도 소프트웨어를 어떤 언어, 지역, 문화에도 적응시킬 수 있게 만드는 엔지니어링 작업입니다. 현지화(l10n)는 이어지는 작업으로, 텍스트를 번역하고, 날짜와 숫자를 형식화하고, 레이아웃을 조정하고, 문화적 기대를 반영해 특정 로케일에 제품을 실제로 적응시키는 것입니다. 둘은 구별됩니다. 국제화는 아키텍처에서 한 번 합니다. 현지화는 콘텐츠에서 여러 번 합니다. 아키텍처를 처음에 맞게 하면 모든 현지화가 쌉니다. 틀리면 각각이 고통스럽고 오류가 생기기 쉬운 사후 보강이 됩니다.

큰 팀에게 i18n은 기초적인 아키텍처 결정입니다. 모든 계층, 곧 데이터 저장, 문자열 처리, 레이아웃, 콘텐츠 파이프라인에 닿습니다. 이를 일찍 확립하고 공유 라이브러리와 린트 규칙으로 시행하지 않으면, 팀들은 영어 문자열을 하드코딩하고, 번역된 조각을 이어 붙이고, 라틴 문자를 가정합니다. 그 부채는 제품이 어떤 새 시장에 들어가기 전에 풀려야 합니다. 공유 i18n 프레임워크와 현지화 워크플로가 수십 개 팀이 각자 배관을 다시 발명하지 않고도 제품을 여러 언어로 출하하게 해 줍니다.

기업과 정부와의 관련은 직접적입니다. 다국적 기업은 여러 나라, 언어, 규제 체계에 걸쳐 고객과 직원을 섬겨야 합니다. 정부는 언어적으로 다양한 인구를 섬겨야 합니다. 많은 나라가 공식적으로 다국어이고, 많은 나라가 오른쪽에서 왼쪽 문자와 토착어 또는 소수 언어를 포함해 여러 언어로 서비스를 제공할 법적 의무가 있습니다. 공공 서비스에서 언어 접근은 형평성과 법적 문제입니다. 유일하게 제공되는 언어를 읽을 수 없는 시민은 사실상 서비스를 거부당합니다.

핵심 원칙

아키텍처는 한 번 국제화하고, 콘텐츠는 여러 번 현지화하십시오.
사용자 대면 텍스트를 절대 하드코딩하지 마십시오. 모든 문자열을 관리되는 리소스로 외부화하십시오.
어디서나 유니코드(UTF-8)를 쓰십시오. 텍스트가 어떤 문자든 될 수 있다고 가정하십시오.
번역된 조각을 이어 붙이지 마십시오. 문법과 어순은 언어마다 다릅니다.
텍스트 확장, 오른쪽에서 왼쪽 문자, 복잡한 복수형과 성 규칙에 대비하십시오.
날짜, 숫자, 통화, 이름을 코드가 아니라 로케일에 따라 형식화하십시오.
번역 가능한 콘텐츠를 코드에서 분리해 번역가가 소스를 건드리지 않게 하십시오.
현지화는 언어적일 뿐 아니라 문화적입니다. 색, 이미지, 예시가 중요합니다.

권장 사항

건전한 국제화 아키텍처를 구축한다

모든 텍스트를 데이터베이스, API, UI에 걸쳐 끝에서 끝까지 유니코드(UTF-8)로 저장하고 처리해 어떤 문자든 표현 가능하게 하십시오. 모든 사용자 대면 문자열을 코드나 마크업에 내장하지 말고 식별자로 키가 지정된 리소스 파일이나 메시지 카탈로그로 외부화하십시오. 예컨대 한 언어의 국가 간 변이를 구별할 수 있도록 로케일을 언어 더하기 지역(그리고 필요한 곳에는 문자)으로 표현하십시오. 날짜, 숫자, 통화 형식화를 손으로 만드는 대신 잘 테스트된 국제화 라이브러리에 형식화 로직을 두십시오. 데이터를 중립적이고 모호하지 않은 형태(UTC 타임스탬프, ISO 국가 및 통화 코드, 기본 단위)로 저장하고 표현 계층에서만 형식화하십시오.

언어의 복잡성을 올바르게 다룬다

텍스트 길이를 가정하지 마십시오. 번역이 영어보다 훨씬 길어지는 경우가 흔하므로 넉넉한 여지를 두고, 잘라내거나 겹치는 대신 다시 흐르는 레이아웃을 설계하십시오. 물리적이 아니라 논리적 레이아웃 속성을 쓰고 적절한 곳에서 인터페이스를 미러링해 양방향(오른쪽에서 왼쪽) 문자를 지원하십시오. 단순한 단수/복수 로직 대신 i18n 라이브러리를 통해 로케일의 복수형 규칙을 쓰십시오(언어마다 복수형이 하나에서 여섯 개까지 있습니다). 언어가 요구하는 곳에서는 성과 문법적 일치를 처리하십시오. 문장을 이어 붙여 만들지 마십시오. 번역가가 어순을 통제하도록 완전하고 매개변수화된 메시지 템플릿을 쓰십시오.

현지화 워크플로와 번역 관리를 확립한다

현지화를 출시 전 배치가 아니라 지속적 파이프라인으로 다루십시오. 문자열을 자동으로 추출해 번역 관리 시스템에 밀어 넣고 완료된 번역을 되가져오며, 이상적으로는 CI와 통합해 새 문자열이 표시되고 현지화된 버전이 동기화를 유지하게 하십시오. 번역가에게 맥락을 주십시오. 스크린샷, 설명, 글자 수 제한, 용어와 어조를 일관되게 유지하는 언어별 용어집과 스타일 가이드입니다. 번역 메모리로 이전 작업을 재사용해 비용을 줄이십시오. 기계 번역이 허용되는 곳(위험이 낮고 양이 많은 콘텐츠)과 사람의 번역과 리뷰가 필요한 곳(법적, 의료, 안전, 브랜드 핵심)을 의도적으로 결정하십시오. 실제 번역이 시작되기 전에 하드코딩된 문자열, 잘림, 인코딩 버그를 잡도록 문자열을 길어지고 악센트가 붙은 자리 표시자로 바꾸는 의사 현지화를 일찍 하십시오.

단어만이 아니라 형식, 문화, 콘텐츠를 현지화한다

날짜, 시간, 숫자, 통화, 주소, 전화번호, 이름을 로케일별로 형식화하고 현지 관례(날짜 순서, 소수점과 묶음 구분자, 통화 위치, 이름 순서)를 존중하십시오. 상징과 색이 문화마다 다른 함의를 지니므로 이미지, 아이콘, 색, 예시, 은유를 현지의 문화적 의미에 맞추십시오. 현지의 법적, 규제적 콘텐츠 차이를 반영하십시오. 전역 일관성(브랜드, 핵심 기능)과 지역 적응(콘텐츠, 예시, 컴플라이언스)을 구별하고, 어느 요소가 고정되고 어느 것이 유연한지 명시적으로 결정하십시오.

i18n을 공유 인프라로 다스린다

팀이 실수로 텍스트를 하드코딩할 수 없도록 공유 i18n 라이브러리, 문자열 외부화 린트 규칙, 표준 로케일 해석 메커니즘을 제공하십시오. 현지화 파이프라인과 용어집의 소유권을 확립하십시오. 회귀가 자동으로 잡히도록 오른쪽에서 왼쪽 로케일과 긴 텍스트 의사 로케일을 포함해 CI에서 여러 로케일로 테스트하십시오.

장단점

결정	장점	단점
첫날부터 국제화	나중의 싼 시장 진입. 사후 보강 없음	두 번째 로케일이 필요하기도 전의 선행 비용
i18n을 나중에 사후 보강	전역 필요가 불확실하면 비용을 미룸	하드코딩된 가정을 풀기가 매우 비싸고 위험
사람의 번역	높은 품질. 문화적으로 정확	더 느리고 비쌈
기계 번역	빠르고 싸고 막대한 양으로 확장	품질과 정확성 위험. 고위험 콘텐츠에 부적합
지속적 현지화 파이프라인	로케일이 동기화를 유지. 출시 몰아치기 없음	도구와 프로세스 투자
지역별 깊은 문화적 적응	더 나은 현지 적합과 신뢰	만들고 유지할 콘텐츠 변형이 더 많음

핵심 트레이드오프는 언제 국제화에 투자하느냐입니다. 하드코딩되고, 이어 붙이고, 라틴 문자를 가정한 코드로 가득한 제품에 i18n을 사후 보강하는 것은 갚기에 가장 비싼 기술 부채의 하나입니다. 국제적이거나 다국어의 야망이 그럴듯한 모든 조직, 곧 본질적으로 모든 대기업과 다국어 정부에서는 수익이 미뤄지더라도 아키텍처를 일찍 국제화하는 것이 사후 보강보다 훨씬 쌉니다.

팀과 논의할 질문

린트 규칙으로 문자열 외부화를 시행하며, 실제 번역 전에 CI에서 의사 현지화가 돌아갑니까? 국제화를 비싸게 만드는 부채(하드코딩된 영어 문자열, 이어 붙인 문장 조각, 라틴 문자 가정)는 도구가 커밋 시점에 막지 않으면 조용히 쌓입니다. 하드코딩된 사용자 텍스트를 표시하는 린트 규칙과 CI에서 도는 긴 텍스트 악센트 의사 로케일이 잘림, 겹침, 인코딩 버그를 고치기 쌀 때 잡습니다. 이것이 수십 개 팀이 각자 배관을 다시 발명하거나 마감 아래서 가정을 풀지 않고도 하나의 제품을 여러 언어로 출하하게 해 줍니다. 하드코딩된 문자열 검색을 가져와 어느 팀이든 오늘 실수로 하나를 출하할 수 있는지 물으십시오. 파이프라인의 어떤 것도 그것을 잡지 못한다면 그것이 먼저 닫을 간극입니다.
정규 데이터는 어디에 저장하며, 형식화는 표현 계층에 한정됩니까? 타임스탬프를 UTC로, 국가와 통화를 ISO 코드로, 금액을 기본 단위로 저장하면 어떤 로케일이든 가장자리에서 올바르게 형식화할 수 있는 반면, 데이터 계층에 구워진 형식화 로직은 풀기 고통스러운 버그를 낳습니다. 날짜, 숫자, 통화, 주소, 이름이 손으로 만든 코드가 아니라 잘 테스트된 라이브러리를 통해 표현 시점에만 형식화된다는 데 합의하십시오. 시민이 자기 관례의 올바른 날짜 순서, 소수점 구분자, 이름 순서를 봐야 하는 다국적 기업과 다국어 정부에서 이것이 중요합니다. 시스템이 이미 형식화된 채 저장하는 값의 예를 가져와 새 로케일이 다르게 필요로 할 때 무엇이 깨지는지 따라가 보십시오. 데이터와 표현이 얽혀 있다면 로케일을 추가하기 전에 어떻게 푸는지 결정하십시오.
기계 번역은 정확히 어디서 허용되며, 현지화 파이프라인은 어떻게 배치가 아니라 지속적으로 유지됩니까? 기계 번역은 위험이 낮고 양이 많은 콘텐츠에는 빠르고 싸지만, 오역이 실제 해를 일으키는 법적, 의료, 안전, 브랜드 핵심 텍스트에는 부적합하므로, 경계는 팀별 짐작이 아니라 명시적 정책이어야 합니다. 마찬가지로 현지화를 출시 전 배치로 다루면 번역 몰아치기가 보장되는 반면, 문자열을 자동 추출하고 번역 관리 시스템을 통해 동기화하면 모든 로케일이 최신으로 유지됩니다. 누가 파이프라인, 용어집, 고위험 문자열의 사람 리뷰 관문을 소유하는지 결정하십시오. 최근 릴리스를 가져와 새 문자열이 모든 언어에 나타나기까지 얼마나 걸렸는지 물으십시오. 릴리스 사이에 로케일이 동기화에서 벗어난다면 파이프라인은 위장한 배치입니다.
오른쪽에서 왼쪽 로케일과 긴 텍스트 의사 로케일을 자동으로 테스트합니까, 아니면 조용히 라틴 문자와 영어 길이 레이아웃을 가정하고 있습니까? 양방향(오른쪽에서 왼쪽) 지원과 텍스트 확장은 새 시장에서 가장 눈에 띄게 깨지는 가정입니다. 미러링되지 않은 미러링되어야 할 인터페이스, 독일어나 핀란드어가 영어보다 40퍼센트 길어지면 잘리는 버튼입니다. 경쟁하는 끌림은 속도입니다. 물리적이 아닌 논리적 레이아웃 속성 위에 만들고 악센트 의사 로케일을 지속적 통합(CI)에 연결하는 데는 실제 고객이 필요로 하기도 전에 노력이 듭니다. 가장 바쁜 화면을 오른쪽에서 왼쪽 로케일과 길어진 의사 로케일로 렌더링한 스크린샷을 가져와 겹침, 잘린 라벨, 멈춘 화살표를 세어 보십시오. 다국적 기업이나 오른쪽에서 왼쪽 또는 소수 언어를 섬길 법적 의무가 있는 정부에게, 미러링할 수 없는 레이아웃은 외관상의 결함이 아니라 재구축 없이는 충족할 수 없는 시장이나 법정 의무입니다.
제품의 어느 부분이 전역에서 고정되고 어느 부분이 지역별로 유연하며, 누가 결정할 권한이 있습니까? 현지화는 단지 언어적이 아니라 문화적이므로 색, 이미지, 예시, 경칭, 심지어 제공되는 기능도 시장마다 다를 수 있지만, 허용하는 모든 지역 변형은 영원히 만들고, 번역하고, 리뷰하고, 유지할 또 하나의 산출물입니다. 긴장은 신뢰와 전환을 쌓는 지역 적합과 브랜드를 일관되게 하고 유지보수 부담을 한정하는 일관성 사이에 있습니다. 제안된 새 로케일이 번역된 문자열을 넘어 바꿀 것의 구체적 목록을 가져와 각 변형의 첫 구축만이 아니라 지속적 유지 비용을 가격 매기십시오. 대기업에서는 지역 팀이 임시방편으로 제품을 포크하지 못하도록 이 결정에 지명된 소유자가 필요하고, 정부에서는 관할마다 다르고 선택이 아닌 법적, 접근성 콘텐츠 규칙을 존중해야 합니다.
실제로 어떤 로케일을 약속하며, 그 사이에 용어를 어떻게 일관되게 유지하고, 어떤 증거가 그 목록을 이끕니까? 언어를 추가하는 것은 약속하기 쉽고 지속하기 비쌉니다. 각각이 용어집, 스타일 가이드, 고위험 문자열의 사람 리뷰, 단순한 단수-복수 로직이 대부분의 언어에서 틀리는 올바른 복수형과 성 처리를 필요로 하기 때문입니다. 경쟁하는 고려는 도달 대 비용입니다. 나쁘게 섬긴 시장이나 인구는 전혀 섬기지 않은 것보다 나쁠 수 있습니다. 각 후보 로케일 뒤의 인구나 매출, 라이브러리가 그것에 제공하는 복수형 규칙과 형식화 커버리지, 누가 용어집을 소유하는지 가져오십시오. 다국적 기업에서 동인은 접근 가능 시장과 언어당 지원 비용이고, 정부에서는 그 언어로만 거래할 수 있는 주민의 수로 정량화되는 법적 언어 접근 의무와 형평성입니다.

분야별 관점

스타트업. 첫날 싼 아키텍처 선택을 하고 거기서 멈추십시오. 끝에서 끝까지 UTF-8, 모든 사용자 대면 문자열을 메시지 카탈로그에, 날짜, 숫자, 통화를 로케일 인식 라이브러리로 형식화하는 것입니다. 한 언어로 출하하는 동안 비용이 거의 들지 않고, 첫 큰 고객이 두 번째 언어를 원할 때 재작성을 아낍니다. 아직 아무도 값을 치르지 않는 로케일을 지원하거나 번역 파이프라인을 세우지 마십시오. 집 전체를 가구로 채우지 말고 문을 열어 두십시오.

소기업. 국제화 전문가도 빠듯한 예산도 없으니 파이프라인을 직접 만드는 대신 프레임워크에 이미 있는 i18n 기능과 호스팅 번역 관리 서비스에 기대십시오. 위험이 낮고 양이 많은 콘텐츠에는 기계 번역을 쓰고, 법적, 안전, 청구 텍스트처럼 실수가 고객을 잃거나 규칙을 어길 수 있는 곳에서만 사람의 번역에 값을 치르십시오. 특정 시장이 지속적인 번역과 리뷰 비용을 분명히 정당화할 때만 로케일을 약속하십시오.

대기업. 문제는 많은 팀에 걸친 거버넌스입니다. 공유 i18n 라이브러리, 하드코딩된 문자열을 거부하는 린트 규칙, 번역 메모리와 언어별 용어집이 있는 지속적 현지화 파이프라인, 오른쪽에서 왼쪽과 긴 텍스트 의사 로케일을 포함한 다중 로케일 CI입니다. 그룹들이 배관을 다시 발명하거나 동기화에서 벗어나지 않도록 분명한 소유자와 함께 현지화를 공유 인프라로 운영하십시오. 언어 커버리지, 현지화 품질, 새 로케일 출시 시간을 측정하고, 시장을 임시방편으로 출시하는 대신 그 숫자에 맞춰 로케일 포트폴리오를 관리하십시오.

정부. 언어 접근은 흔히 법적 의무로, 공식 언어, 오른쪽에서 왼쪽 문자, 토착어 및 소수 언어를 덮으므로 투명성과 형평성이 모든 선택을 형성합니다. 기관 전반에 쓰이는 공유 i18n 프레임워크와 번역 워크플로를 구축하고, 법적, 안전 용어에는 사람의 리뷰를 요구하고, 서비스 사이에서 용어가 일관되게 유지되도록 용어집을 공개하십시오. 조달은 계약에서 로케일, 오른쪽에서 왼쪽, 접근성 지원을 요구해야 하며, 각 언어로 섬기는 인구가 대중에게 지출을 정당화하는 지표입니다.

사례

스타트업. 영어로만 출하하는 한 작은 스타트업은 그래도 첫날 몇 가지 싼 아키텍처 선택을 했습니다. 어디서나 UTF-8, 모든 사용자 대면 문자열을 하드코딩하는 대신 메시지 카탈로그로 뽑기, 날짜와 통화를 로케일 인식 라이브러리로 형식화하기입니다. 한 언어일 때는 거의 비용이 들지 않았습니다. 1년 뒤 가장 큰 가망 고객이 프랑스어와 독일어 버전을 요청했을 때, 그 로케일을 추가하는 것은 재작성이 아니라 대부분 계약자에게 넘긴 번역 작업이어서, 엔지니어링 한 분기를 미루는 대신 몇 주 만에 계약을 따냈습니다.

대기업. 한 글로벌 전자상거래 회사가 플랫폼을 일찍 국제화했습니다. 어디서나 UTF-8, 외부화된 문자열, 로케일 인식 형식화 라이브러리, 번역 메모리와 언어별 용어집이 있는 지속적 현지화 파이프라인입니다. 새 시장 진입은 엔지니어링 프로젝트가 아니라 대부분 콘텐츠 작업(번역, 리뷰, 이미지 조정)이 되어, 회사가 새 로케일에 몇 주 안에 출시할 수 있었습니다. 논리적 레이아웃 속성 위에 만든 오른쪽에서 왼쪽 지원 덕에 아랍어와 히브리어 시장에 새 UI 작업이 거의 필요 없었습니다.

정부. 오른쪽에서 왼쪽 문자와 소수 언어를 포함한 여러 공식 언어로 서비스를 제공할 법적 의무가 있는 한 국가 정부가 기관 전반에 쓰이는 공유 i18n 프레임워크와 번역 워크플로를 구축했습니다. CI의 의사 현지화가 출시 전에 하드코딩된 문자열과 잘림을 잡았고, 공유 용어집이 서비스와 언어 전반에서 법률 용어를 일관되게 유지했습니다. 시민은 자기 언어로 올바른 날짜, 숫자, 이름 형식으로 세금, 건강, 급여 거래를 완료할 수 있어, 언어 접근법을 충족하고 다수 언어가 아닌 사용자의 형평성을 개선했습니다.

비즈니스 사례: 동기, ROI, TCO

국제화의 ROI는 시장 접근과 속도입니다. 잘 국제화된 제품은 새 나라와 언어 시장에 빠르고 싸게 진입할 수 있어, 각 새 로케일이 큰 프로젝트가 아니라 증분적 매출이나 시민 도달이 됩니다. 현지화 품질은 각 시장의 전환, 신뢰, 지원 비용을 이끕니다. 제품이 그들의 언어를 올바르게 말하고 관례를 존중할 때 사용자는 더 많이 거래하고 지원에 덜 연락합니다.

TCO에서 도입 비용은 국제화를 위한 선행 엔지니어링과 지속적인 번역 및 파이프라인 비용입니다. 도입하지 않는 비용은 비싼 사후 보강입니다. 시장이나 법적 요건이 이끄는 마감 아래서 코드베이스 전체의 하드코딩된 문자열, 이어 붙이기, 인코딩 버그, 레이아웃 가정을 푸는 것입니다. 나쁜 현지화에도 숨은 비용이 있습니다. 나쁘게 섬긴 시장의 잃은 판매, 혼란스러운 형식이 낳는 지원 부담, 오역된 고위험 콘텐츠의 법적, 평판 손상입니다. 지속적 현지화는 비싼 출시 전 번역 몰아치기를 피합니다.

리더십을 설득하려면 국제화를 미래 시장에 대한 옵션으로 구성하십시오. 모든 미래 시장 진입의 비용과 시간을 극적으로 낮추는 소소한 선행 투자입니다. 정부에서는 동인이 법적 언어 접근 의무와 형평성이며, 각 언어로 섬기는 인구로 정량화됩니다.

안티패턴과 함정

하드코딩된 문자열: 코드에 구워진 사용자 텍스트로, 로케일마다 코드 변경을 강제.
문자열 이어 붙이기: 조각으로 문장을 만들어 문법과 어순을 깨뜨리는 것.
비유니코드 가정: 인코딩 버그, 모지바케(불일치한 문자 인코딩으로 깨진 텍스트), 문자를 표현할 수 없음.
영어 텍스트 길이 가정: 번역되면 잘리거나 겹치는 레이아웃.
오른쪽에서 왼쪽 무시: 미러링할 수 없는 물리적 좌우 레이아웃을 쓰는 것.
순진한 복수형 처리: 대부분의 언어에서 틀린 단수/복수 로직.
로케일에 눈먼 형식화: 하드코딩된 날짜, 숫자, 통화 형식.
맥락 없는 번역: 번역가가 의미를 짐작해 오류를 낳는 것.
배치식 막판 현지화: 지속적 파이프라인 대신 출시 전 몰아치기.
문화적 무감각: 현지에서 불쾌하거나 혼란스러운 이미지, 색, 예시.

성숙도 모델

1단계: 시작. 단일 언어, 하드코딩된 문자열, 비유니코드 가정, 이어 붙여 만든 텍스트. 국제화는 반응적입니다. 새 로케일은 코드를 바꾼다는 뜻이고, 인코딩과 레이아웃 버그는 프로덕션에서 우연히 발견됩니다.

2단계: 발전. 일부 문자열이 외부화되고 곳곳에서 유니코드가 쓰이지만 실천은 팀마다 일관되지 않습니다. 현지화는 수동의 배치식 출시 전 노력이며, 형식화, 복수형 처리, 오른쪽에서 왼쪽 지원이 팀마다 다르게(또는 전혀) 처리됩니다.

3단계: 표준화. 공유 i18n 아키텍처와 로케일 인식 형식화 라이브러리가 조직 전체에서 시행되는 문서화된 표준입니다. 문자열 외부화는 린트 규칙으로 검사되고, 번역 관리 시스템과 지속적 파이프라인이 용어집 및 번역 메모리와 함께 갖춰져 있으며, 의사 현지화와 다중 로케일 테스트(오른쪽에서 왼쪽과 긴 텍스트 로케일 포함)가 CI에서 돕니다.

4단계: 관리. 현지화 프로그램이 기준선에 대해 측정되고 통제됩니다. 팀은 언어 커버리지, 현지화 품질과 결함률, 커밋에서 번역된 릴리스까지의 문자열 동기화 지연, 릴리스당 잡힌 잘림 및 오른쪽에서 왼쪽 렌더링 결함, 로케일당 번역 비용, 새 로케일 출시 시간을 추적하며, 이 지표가 릴리스를 관문 통제하고 사람의 리뷰 대 기계 번역에 투자할 곳을 이끕니다.

5단계: 오케스트레이션. 국제화와 현지화가 조직 전체에서 지속적으로 개선되고 통합됩니다. 현지화가 지속적이고, 기계 번역과 사람의 번역이 콘텐츠 부류마다 의도적으로 선택되며, 문화적 적응이 체계적입니다. 조직은 시장과 형평성 증거에 따라 로케일을 추가하고, 퇴역시키고, 범위를 다시 정하며, 새 로케일이 사후 보강 없이 높은 품질로 빠르게 출시됩니다.

논의를 위한 아이디어

국제적 수요가 불확실하다면 제품은 얼마나 일찍 국제화해야 합니까?
기계 번역이 허용되는 곳은 어디이며, 사람이 리뷰해야 하는 곳은 어디입니까?
많은 언어와 팀에 걸쳐 용어를 어떻게 일관되게 유지합니까?
추가되는 변형 유지보수에 견주어 지역 문화적 적응은 얼마나 가치가 있습니까?
오른쪽에서 왼쪽과 소수 언어 지원은 어떻게 우선순위를 정하고 테스트해야 합니까?
파이프라인을 늦추지 않고 번역가에게 충분한 맥락을 어떻게 줍니까?

핵심 요점

아키텍처는 한 번 국제화하고 콘텐츠는 여러 번 현지화하십시오.
어디서나 유니코드를 쓰고, 모든 문자열을 외부화하고, 번역을 이어 붙이지 마십시오.
텍스트 확장, 오른쪽에서 왼쪽 문자, 로케일별 복수형과 형식화 규칙에 대비하십시오.
번역 메모리, 용어집, 맥락이 있는 지속적 현지화 파이프라인을 운영하십시오.
실제 번역 전에 i18n 버그를 잡도록 CI에서 의사 현지화를 일찍 하십시오.
현지화는 언어적일 뿐 아니라 문화적입니다.
일찍 국제화하는 것이 사후 보강보다 훨씬 쌉니다. 정부에게는 법적 형평성 요건입니다.

참고 문헌과 더 읽을거리

The Unicode Consortium, The Unicode Standard and Common Locale Data Repository (CLDR)
W3C Internationalisation (i18n) Activity, techniques and best practices
Richard Ishida, W3C internationalisation articles and tutorials
Bert Esselink, A Practical Guide to Localisation
John Yunker, Beyond Borders: Web Globalisation Strategies
Unicode Technical Standard #35 (locale data markup) and ICU library documentation
IETF BCP 47 language tags
Government multilingual service and language-access guidance
Nielsen Norman Group and W3C articles on RTL, text expansion, and localisation UX