지역화

  • 아티클

이 가이드에서는 국제화 및 지역화에 대한 개념과 이러한 개념을 사용하여 Xamarin 모바일 애플리케이션을 생성하는 방법에 대한 지침에 대한 링크를 소개합니다.

Xamarin 앱 지역화의 기술 세부 정보로 바로 건너뛰려면 다음 플랫폼별 방법 문서 중 하나로 시작합니다.

i18n 및 L10n

국제화 는 코드가 다른 언어를 표시하고 다른 로캘(예: 숫자 및 날짜 서식 지정)에 맞게 표시를 조정할 수 있도록 하는 프로세스입니다. 이를 세계화라고도 합니다.

지역화 는 각 언어에 대한 리소스(예: 문자열 및 이미지)를 만들고 국제화 앱으로 묶는 단계입니다.

국제화는 종종 i18n으로 단축됩니다 - "i"와 "n"사이의 18 글자 약어입니다. 지역화는 마찬가지로 L10n으로 단축됩니다. "L"과 "n" 사이의 문자는 10자입니다.

개요

이 문서에서는 국제화 및 지역화와 관련된 개념과 모바일 애플리케이션 개발에 일반적으로 적용되는 방법을 소개합니다. 애플리케이션을 디자인하고 빌드할 때 이전에 하드 코딩되었지만 지역화를 위해 매개 변수화해야 하는 항목은 다음과 같습니다.

  • 화면 레이아웃 및 텍스트,
  • 아이콘, 그래픽 및 색,
  • 비디오 및 사운드 파일,
  • 동적 텍스트 및 텍스트 서식(예: 숫자, 통화 및 날짜)
  • RTL(오른쪽에서 왼쪽) 언어에 대한 레이아웃 변경 및
  • 데이터 정렬.

앱이 이러한 팁을 대상으로 하는 모바일 플랫폼에 관계없이 고품질의 지역화된 앱을 빌드하는 데 도움이 됩니다.

디자인 고려 사항

콘텐츠를 지역화할 수 있도록 애플리케이션을 설계하는 것을 국제화라고 합니다. 국제화를 올바르게 수행하는 것은 런타임에 다른 언어 문자열을 로드하는 것 이상입니다. 잘 설계된 앱은 언어 및 로캘(이미지, 소리 및 비디오 포함)에 따라 모든 리소스를 변경할 수 있도록 허용해야 하며 다양한 크기의 문자열에 대처하기 위해 서식 및 레이아웃을 조정할 수 있습니다.

이 섹션에서는 국제화된 애플리케이션을 빌드할 때 고려해야 할 몇 가지 디자인 고려 사항에 대해 설명합니다.

레이아웃 및 문자열 길이

중국어 및 일본어 문자열은 매우 짧을 수 있습니다. 때로는 입력 필드 레이블에 대해 한두 문자가 충분히 의미가 있을 수 있습니다.

독일어 문자열(예:)은 매우 길 수 있습니다. 때로는 영어로 된 비교적 짧은 단어가 다른 언어에서 매우 길어질 수 있습니다. 잘리거나 레이아웃이 예기치 않게 재배치됩니다.

iOS 홈 화면의 몇 가지 항목에 대한 문자열 길이를 영어, 독일어 및 일본어로 비교합니다.

German vs Japanese string length

영어(8자)로 설정 독일어 번역에는 13자, 일본어로는 2자만 필요합니다.

레이블 길이가 크게 다를 수 있는 경우 표시 레이블과 입력 필드가 나란히 표시되는 레이아웃은 작업하기가 어렵습니다. 종종 레이블이 필드 위에 표시되는 레이아웃은 화면의 전체 너비를 레이블과 입력 모두에 사용할 수 있기 때문에 지역화하기 쉽습니다.

일반적으로 고정 레이아웃(특히 나란히 요소)을 빌드하는 경우 레이블 및 텍스트에 필요한 영어 문자열보다 너비가 50% 이상 더 많습니다. 이렇게 하면 모든 문제가 해결되지는 않지만 많은 경우에 작동하는 버퍼를 제공합니다.

입력 유효성 검사

유효성 검사 규칙을 작성할 때는 가정을 조심하세요. 한 글자가 거의 의미가 없으므로 텍스트 필드 입력이 영어로 3자 이상을 "요구"하도록 요구하는 것이 유효해 보일 수 있습니다. 그러나 중국어와 일본어에서는 단일 문자가 유효한 입력일 수 있으며 해당 언어에는 "3자 이상 필요"라는 유효성 검사 메시지가 적합하지 않습니다.

문자가 ASCII 하위 집합으로 제한되지 않으므로 전자 메일 주소 또는 웹 사이트 URL의 유효성 검사와 같은 다른 간단한 작업이 더 복잡해집니다.

국제화를 염두에 두고 유효성 검사 규칙을 작성합니다. 가장 제한적인 규칙을 선택하거나 각 언어에 대해 다르게 작동하도록 논리를 작성합니다.

이미지 및 색

모든 이미지가 사용자의 언어 선택에 따라 변경되어야 하는 것은 아닙니다. 많은 아이콘 또는 사진은 어떤 언어를 사용하는지에 관계없이 모든 사용자에게 적합합니다. 일부 리소스는 다음과 같이 지역화하는 것이 좋습니다.

  • 사용자 또는 특정 위치를 보여 주는 이미지 - 앱이 로컬 사용자/위치를 표시하는 경우 사용자와 더 관련성이 있다고 느낄 수 있습니다.
  • 아이콘 – 일부 도상학은 문화권에 따라 다를 수 있으며 로컬 이해를 반영하도록 이미지를 지역화하여 앱을 더 쉽게 사용할 수 있습니다.
  • 색 – 일부 문화권에서는 색을 다르게 이해합니다. 빨간색은 한 지역에서 경고를 의미할 수 있지만 다른 지역에서는 행운을 빕니다. 앱을 디자인할 때 네이티브 스피커를 확인하여 색을 지역화하는 메커니즘을 빌드해야 하는지 여부를 확인합니다.

비디오 및 소리

비디오와 소리는 애플리케이션을 지역화할 때 특별한 과제를 제시합니다. 문자열을 번역하기는 비교적 쉽지만 여러 음성 변환 트랙 또는 비디오 클립을 녹음하는 것은 비용이 많이 들고 어려울 수 있기 때문입니다.

비디오 및 사운드 파일의 여러 복사본도 애플리케이션의 크기를 크게 늘릴 수 있습니다(특히 많은 언어로 지역화하거나 미디어 파일이 많은 경우). 사용자가 앱을 설치한 후 필요한 언어 자산만 다운로드하는 것을 고려할 수 있지만 이로 인해 네트워크 속도가 느려질 수도 있습니다.

지역화 문제를 해결하는 방법에는 여러 가지가 있습니다. 가장 중요한 것은 이를 미리 고려하고 애플리케이션이 이를 처리하도록 설계되었는지 확인하는 것입니다.

날짜, 시간, 숫자 및 통화

.NET 서식 함수를 사용하는 경우 소수 구분 기호가 올바르게 구문 분석되도록 문화권을 지정해야 합니다(변환 예외가 throw되지 않도록). 예를 들어 1.99와 1,99는 모두 로캘에 따라 유효한 소수점 표현입니다.

알려진 소스(즉, 사용자가 제어하는 웹 서비스)에서 데이터를 가져올 때 표준 영어 서식 지정에 사용할 InvariantCulture와 같은 서식과 일치하는 문화권 식별자를 하드 코딩할 수 있습니다.

double.Parse("1,999.99", CultureInfo.InvariantCulture);

앱 사용자가 데이터를 입력하는 경우 해당 로캘을 반영하는 CultureInfo 인스턴스를 사용하여 구문 분석합니다.

double.Parse("1 999,99", CultureInfo.CreateSpecificCulture("fr-FR"));

자세한 내용은 숫자 문자열 구문 분석 및 구문 분석 날짜 및 시간 문자열 MSDN 문서를 참조하세요.

RTL(오른쪽에서 왼쪽) 언어

아랍어, 히브리어 및 우르두어(예: )와 같은 일부 언어는 오른쪽에서 왼쪽으로 읽습니다. 이러한 언어를 지원하는 애플리케이션은 오른쪽에서 왼쪽 읽기 프로그램에 맞게 조정되는 화면 디자인을 사용해야 합니다. 예를 들면 다음과 같습니다.

  • 텍스트는 오른쪽 맞춤이어야 합니다.
  • 레이블은 입력 필드의 오른쪽에 표시됩니다.
  • 기본 단추 배치는 일반적으로 반대로 바뀝니다.
  • 컨텍스트에 방향을 사용하는 계층적 탐색 살짝 밀기 및 애니메이션(및 기타 탐색 은유 및 애니메이션)도 반전해야 합니다.

iOS와 Android는 모두 위에서 조정하는 데 도움이 되는 기본 제공 기능을 사용하여 오른쪽에서 왼쪽으로 레이아웃과 글꼴 렌더링을 지원합니다. Xamarin.Forms는 현재 RTL 렌더링을 자동으로 지원하지 않습니다.

정렬

다른 언어는 동일한 문자 집합을 사용하는 경우에도 알파벳의 정렬 순서를 다르게 정의합니다.

언어(CultureInfo)가 정렬 순서에 영향을 주는 예제는 .NET Framework의 문자열 사용에 대한 모범 사례의 문자열 비교 세부 정보를 참조하세요.

모바일 플랫폼의 기본 제공 데이터베이스 기능이 언어별 정렬 순서를 지원할 가능성은 낮으므로 비즈니스 논리에서 추가 코드를 구현해야 할 수 있습니다.

텍스트 검색

여러 언어를 염두에 두고 검색 알고리즘을 작성하고 테스트해야 합니다. 고려해야 할 사항은 다음과 같습니다.

  • 자동 완성 – 자동 완성 함수를 빌드한 경우 사용자의 언어와 관련된 제안을 소스로 지정해야 합니다.
  • 쿼리를 데이터에 일치 - 특정 언어로 입력한 검색 쿼리가 해당 언어로 작성된 콘텐츠 또는 앱의 모든 콘텐츠에 대해 실행되나요?
  • 형태소 분석 – 유사한 단어, 단어 루트 및 기타 검색 최적화를 검색하도록 검색이 빌드된 경우 지원되는 모든 언어에 맞게 최적화가 빌드된가요?
  • 정렬 – 결과가 올바르게 정렬되었는지 확인합니다(위 참조).

외부 원본의 데이터

많은 애플리케이션은 Twitter 및 RSS 피드에서 날씨, 뉴스 또는 주가에 이르기까지 외부 원본에서 데이터를 다운로드합니다. 사용자에게 표시할 때 관련이 없거나 읽을 수 없는 정보의 화면을 표시할 가능성을 고려해야 합니다.

앱이 사용자와 관련된 데이터를 표시하도록 하는 데 사용할 수 있는 몇 가지 전략은 다음과 같습니다.

  • 다른 원본 – 애플리케이션은 사용자의 언어 또는 로캘에 따라 다른 원본에서 데이터를 다운로드할 수 있습니다. 로캘 뉴스, 날씨 및 주가가 북아메리카n 피드에서 다운로드한 것보다 더 합리적일 수 있습니다.
  • 지역화된 디스플레이 – Twitter 또는 사진 피드를 표시하는 경우 콘텐츠 자체가 원래 언어로 다시 기본 경우에도 메타데이터(예: 소요된 시간)를 자신의 언어로 표시해야 합니다.
  • 번역 – 앱에 번역 옵션을 빌드하여 들어오는 데이터의 기계 번역을 수행할 수 있습니다. 이는 자동 또는 사용자의 재량에 따라 가능할 수 있습니다. 기계 번역이 완벽하지 않으므로 이 작업이 진행되는 경우 사용자에게 알리기만 하면 됩니다.

이는 오디오 트랙 또는 비디오에 대한 외부 링크에도 영향을 줄 수 있습니다. 애플리케이션을 디자인할 때 번역된 콘텐츠를 소싱하거나 콘텐츠가 해당 언어로 표시되지 않을 때 사용자에게 적절한 정보를 제공하도록 미리 계획해야 합니다.

과도하게 번역하지 마세요.

앱의 일부 문자열은 번역이 필요하지 않거나 최소한 번역기에서 특별한 주의가 필요할 수 있습니다. 예를 들면 다음과 같습니다.

  • URL – URL을 나열하는 경우 언어별로 조정할 수도 있고 그렇지 않을 수도 있습니다. 예를 들어 facebook.com 번역이 필요하지 않으므로 기본 사이트에서 언어를 자동으로 검색합니다. 다른 사이트에는 로캘별 콘텐츠가 있으며 yahoo.com yahoo.fr 또는 yahoo.it 같은 다른 URL을 제공할 수 있습니다.
  • 전화 번호 - 특히 특정 언어를 사용하는 발신자의 국가 코드 또는 번호가 다른 전화 번호입니다.
  • 연락처 세부 정보 – 주소 및 기타 정보는 언어 또는 로캘에 따라 달라질 수 있습니다.
  • 상표 및 제품 이름 – 일부 문자열은 항상 동일한 언어로 작성되므로 번역할 필요가 없습니다.

마지막으로, 특정 문자열에 특별한 처리가 필요한 경우 번역기를 위한 자세한 지침을 포함해야 합니다.

서식 있는 텍스트

일반적으로 문자열의 서식이 다양하지 않으므로 모바일 앱에는 문제가 되지 않습니다. 그러나 앱에서 서식 있는 텍스트(예: 굵게 또는 기울임꼴 서식 지정)가 필요한 경우 번역기에서 서식을 입력하는 방법을 알고 있으면 문자열 파일은 서식을 올바르게 저장하고 사용자에게 표시되기 전에 제대로 서식이 지정됩니다(즉, 실수로 서식 코드 자체를 사용자에게 표시하지 않도록 함).

번역 팁

애플리케이션에서 사용하는 문자열 변환은 지역화 프로세스의 일부로 간주됩니다. 일반적으로 이 작업은 번역 서비스에 아웃소싱되고 응용 프로그램 또는 비즈니스를 모르는 다국어 직원이 수행합니다.

다음 팁은 정확하게 번역하기 쉬운 문자열을 생성하여 지역화된 앱의 품질을 향상시키는 데 도움이 됩니다.

단어가 아닌 전체 문자열 지역화

개발자는 애플리케이션 전체에서 다시 사용할 수 있도록 단일 단어 또는 문장 '코드 조각'을 지정하는 방법을 사용하는 경우가 있습니다. 예를 들어 "메시지가 5개 있습니다."라는 텍스트의 경우 번역을 위해 다음 문자열을 지정할 수 있습니다.

잘못됨:

"You have"
"no"
"message"
"messages"

그런 다음 문자열 연결을 사용하여 코드에서 즉시 올바른 구를 만들려고 합니다.

잘못됨:

"You have" + " " + numMsgs + " " + "messages"
"You have" + " no " + "messages"

이는 모든 언어에서 반드시 작동하지 않으며 번역기가 각 짧은 세그먼트의 컨텍스트를 이해하기 어렵기 때문에 권장되지 않습니다. 또한 번역된 문자열을 다시 사용하게 되므로 나중에 다른 컨텍스트에서 사용되는 경우 문제가 발생할 수 있습니다(업데이트).

매개 변수 다시 정렬 허용

일부 프로그래밍 언어는 문자열의 매개 변수 순서를 지정하기 위해 추가 구문이 필요하지만 .NET은 이미 번호가 매겨진 자리 표시자의 개념을 지원하므로

양호:

"a {0} b {1} cde {3}"

는 다음으로 변환될 수 있습니다(자리 표시자의 위치와 순서가 변경되는 위치).

"{2} {3} f g h {0}"

및 토큰은 변환기에서 의도한 대로 정렬됩니다. 문자열을 번역기로 보낼 때 각 자리 표시자에 포함된 내용에 대한 설명을 포함해야 합니다.

카드진수성을 위해 여러 문자열 사용

더 나은 사용자 환경을 제공하기 위해 각 상태에 특정 문자열을 사용하는 것과 같은 "You have {0} message/s." 문자열을 사용하지 않도록 합니다.

양호:

"You have no messages."
"You have 1 message."
"You have 2 messages."
"You have {0} messages."

표시되는 숫자를 평가하고 적절한 문자열을 선택하려면 앱에서 코드를 작성해야 합니다. 일부 플랫폼(iOS 및 Android 포함)에는 현재 언어/로캘에 대한 기본 설정에 따라 최상의 복수 문자열을 자동으로 선택하는 기본 제공 기능이 있습니다.

성별 허용

라틴어 기반 언어는 때때로 주제의 성별에 따라 다른 단어를 사용합니다. 앱이 성별에 대해 알고 있는 경우 번역된 문자열이 이를 반영하도록 허용해야 합니다.

또한 문자열이 앱의 특정 사용자 또는 사용자를 참조하는 영어에서도 더 명백한 경우가 있습니다. 예를 들어 일부 사이트는 다음과 같은 "Bob commented on his post" 메시지를 표시하므로 남성, 여성 및 비이진 또는 알 수 없는 성별에 대한 문자열이 필요합니다.

양호:

"{0} commented on his post"
"{0} commented on her post"
"{0} commented on their post"

문자열을 다시 사용하지 마세요.

또는 더 정확하게는 문자열 자체가 다른 목적이나 의미를 갖는 경우 유사하기 때문에 문자열을 다시 사용하지 마세요.

예를 들어 앱에 켜기/끄기 스위치가 있고 스위치 컨트롤에 'on' 및 'off'에 대한 텍스트가 지역화되어야 한다고 상상해 보세요. 또한 텍스트 레이블에 앱의 다른 위치에 해당 설정의 값을 표시합니다. 스위치 표시와 스위치의 상태(기본 언어에서 동일한 문자열인 경우에도)에 다른 문자열을 사용해야 합니다. 예를 들면 다음과 같습니다.

  • "켜기" – 스위치 자체에 표시됨
  • "끄기" – 스위치 자체에 표시됨
  • "On" – 레이블에 표시됨
  • "Off" – 레이블에 표시됨

이렇게 하면 번역기에서 최대한의 유연성을 제공합니다.

  • 디자인상의 이유로 스위치 자체는 소문자 "on" 및 "off"를 사용하지만 표시 레이블은 대문자 "켜기" 및 "끄기"를 사용합니다.
  • 일부 언어는 사용자 인터페이스 컨트롤에 맞게 스위치 값을 축약해야 하는 반면 전체(번역된) 단어는 레이블에 표시될 수 있습니다.
  • 또는 일부 언어의 경우 스위치 렌더링에서 문화적 친숙함을 위해 "I" 및 "O"를 사용할 수 있지만 레이블이 "On" 또는 "Off"를 읽도록 할 수도 있습니다.

Translation Services

기계 번역

앱에 번역 기능을 빌드하려면 Azure 번역기 Text API를 고려합니다.

테스트를 위해 개발 중에 많은 온라인 번역 도구 중 하나를 사용하여 앱에 지역화된 텍스트를 포함할 수 있습니다.

사용할 수 있는 다른 많은 항목이 있습니다. 기계 번역의 품질은 일반적으로 전문 번역가 또는 원어민이 먼저 검토하고 테스트하지 않고 애플리케이션을 릴리스하기에 충분하지 않은 것으로 간주됩니다.

전문 번역

또한 문자열을 가져와서 자신의 번역가에게 배포하여 유료로 완성된 번역을 제공하는 전문 번역 서비스도 있습니다.

가장 잘 알려진 서비스 중 하나는 LionBridge입니다. 대부분의 전문 서비스는 문자열, XML, RESX 및 POT/PO를 비롯한 모든 일반적인 파일 형식을 지원합니다.

요약

이 문서에서는 앱을 국제화한 다음 리소스를 지역화하기 전에 알아야 할 몇 가지 개념을 소개하고 각 플랫폼에 대한 언어 기본 설정을 변경하는 방법을 설명했습니다.

이러한 개념은 Xamarin에서 사용할 수 있는 다양한 플랫폼별 및 플랫폼 간 국제화 기술에 적용할 수 있습니다.

관심 있는 플랫폼에 대한 기술 세부 정보를 계속 읽습니다.