다음을 통해 공유


앱을 지역화 가능으로 만들기

지역화된 앱은 앱의 기능적 결함을 발견하지 않고 다른 시장, 언어 또는 지역에 대해 지역화할 수 있는 앱입니다. 지역화 가능한 앱의 가장 중요한 속성은 실행 코드가 지역화 가능한 리소스와 완전히 분리되었다는 것입니다. 따라서 지역화해야 하는 앱 리소스를 결정해야 합니다. 앱을 다른 시장에 맞게 지역화해야 하는 경우 변경해야 하는 사항을 스스로에게 물어보십시오.

또한 우리는 당신이 세계화에 대한 지침을 숙지하는 것을 권장합니다.

리소스 파일에 문자열 넣기(.resw)

명령적 코드, XAML 태그 또는 앱 패키지 매니페스트에서 문자열 리터럴을 하드 코드하지 마세요. 대신 앱의 컴파일된 이진 파일과 독립적으로, 다른 지역 시장에 맞춰 조정할 수 있도록 문자열을 리소스 파일(.resw)에 넣으세요. 자세한 내용은 UI 및 앱 패키지 매니페스트 문자열 지역화참조하세요.

이 항목에서는 기본 리소스 파일(.resw)에 메모를 추가하는 방법도 보여 줍니다. 예를 들어 비공식적인 음성 또는 톤을 채택하는 경우 주석에서 설명해야 합니다. 또한 비용을 최소화하려면 번역해야 하는 문자열만 번역기에게 제공되는지 확인합니다.

앱 패키지 매니페스트 원본 파일(파일)에서 앱의 기본 언어를 Package.appxmanifest 적절하게 설정합니다. 기본 언어는 사용자의 기본 설정 언어가 앱의 지원되는 언어와 일치하지 않을 때 사용되는 언어를 결정합니다. 시스템에서 각 리소스가 어떤 언어로 되어 있는지, 또 특정 상황에서 어떻게 사용되는지를 알 수 있도록, 모든 리소스를 언어별로 표시하세요. 이는 기본 언어로 된 리소스를 포함하여(예: \Assets\en-us\Logo.png) 가능합니다.

언어에 맞게 이미지 및 기타 파일 리소스 조정

이상적으로 이미지를 세계화할 수 있습니다. 즉, 이미지를 문화권 독립적으로 만들 수 있습니다. 가능하지 않은 이미지 및 기타 파일 리소스의 경우 필요한 만큼 다양한 변형을 만들고 해당 파일 또는 폴더 이름에 적절한 언어 한정자를 넣습니다. 자세한 내용은 언어, 크기 조정, 고대비 및 기타 한정자맞게 리소스 조정을 참조하세요.

지역화 비용을 최소화하려면 텍스트나 문화적으로 민감한 자료를 이미지에 넣지 마세요. 자신의 문화에 적합한 이미지는 다른 문화권에서 불쾌하거나 잘못 해석될 수 있습니다. 전 세계에서 일반적이지 않은 사서함과 같은 문화권별 이미지를 사용하지 않도록 합니다. 종교적 상징, 동물, 정치적 또는 성별별 이미지를 피하십시오. 살, 신체 부위 또는 손 제스처의 표시는 민감한 주제일 수도 있습니다. 이러한 모든 것을 방지할 수 없는 경우 이미지를 신중하게 지역화해야 합니다. 자신과 다른 읽기 방향의 언어로 지역화하는 경우 대칭 이미지와 효과를 사용하면 미러링을 더 쉽게 지원할 수 있습니다.

또한 이미지의 텍스트와 오디오/비디오 파일의 음성을 사용하지 마세요.

앱에서 색 사용

색을 사용할 때는 주의해야 합니다. 국기 또는 정치 운동과 관련된 색 조합을 사용하는 것은 문제가 될 수 있습니다. 문화 전문가가 색 선택을 검토해야 할 수도 있습니다. 색 사용과 관련된 접근성 문제도 있습니다. 색을 사용하여 의미를 전달하는 경우 크기, 도형 또는 레이블과 같은 다른 수단을 통해 동일한 정보를 전달해야 합니다.

문자열을 문장으로 팩터링하는 것이 좋습니다.

적절한 크기의 문자열을 사용합니다. 짧은 문자열은 번역하기 쉽고 번역 재활용을 가능하게 합니다(동일한 문자열이 지역화기에 두 번 이상 전송되지 않으므로 비용을 절감). 또한 매우 긴 문자열은 지역화 도구에서 지원되지 않을 수 있습니다.

그러나 이 지침의 긴장감은 다른 컨텍스트에서 문자열을 다시 사용할 위험이 있습니다. 컨텍스트에 따라 "on" 및 "off"와 같은 간단한 단어도 다르게 번역될 수 있습니다. 영어에서는 플라이트 모드, Bluetooth 및 디바이스의 토글에 "켜기" 및 "끄기"를 사용할 수 있습니다. 그러나 이탈리아어에서 번역은 켜지고 꺼지는 것의 맥락에 따라 달라집니다. 각 컨텍스트에 대한 문자열 쌍을 만들어야 합니다. 두 컨텍스트가 동일한 경우 문자열을 다시 사용할 수 있습니다. 예를 들어 사운드 효과 볼륨과 음악 볼륨 모두에 "Volume" 문자열을 다시 사용할 수 있습니다. 둘 다 소리의 강도를 참조하기 때문입니다. 컨텍스트와 의미가 다르고 단어가 다르게 번역될 수 있으므로 하드 디스크 볼륨을 참조할 때 동일한 문자열을 다시 사용하면 안 됩니다.

또한 "text" 또는 "fax"와 같은 문자열을 영어의 동사와 명사로 사용할 수 있으므로 번역 프로세스가 혼동될 수 있습니다. 대신 동사와 명사 형식 모두에 대해 별도의 문자열을 만듭니다. 컨텍스트가 동일한지 확실하지 않은 경우, 안전한 쪽으로 실수하고 별도의 문자열을 사용하세요.

간단히 말해서 문자열을 모든 상황에서 작동할 수 있는 부분으로 나누세요. 문자열이 전체 문장이어야 하는 경우가 있습니다.

다음 문자열을 고려합니다. " {0} 동기화할 수 없습니다."

"약속", "작업" 또는 "문서"와 같은 다양한 단어를 바꿀 {0}수 있습니다. 이 예제는 영어에서 작동하지만 해당 문장(예: 독일어)의 모든 경우에 작동하지는 않습니다. 다음 독일어 문장에서는 템플릿 문자열("Der", "Die", "Das")의 일부 단어가 매개 변수가 있는 단어와 일치해야 합니다.

영어 독일어
약속을 동기화할 수 없습니다. Der Termin konnte nicht synchronisiert werden.
작업을 동기화할 수 없습니다. Die Aufgabe konnte nicht synchronisiert werden.
문서를 동기화할 수 없습니다. Das Dokument konnte nicht synchronisiert werden.

또 다른 예로 "{0} 분 안에 미리 알림"이라는 문장을 고려해 보세요. "minute(s)" 사용은 영어에 대해 작동하지만 다른 언어는 다른 용어를 사용할 수 있습니다. 예를 들어 폴란드어 언어는 컨텍스트에 따라 "minuta", "minuty" 또는 "minut"를 사용합니다.

이 문제를 해결하려면 한 단어가 아닌 전체 문장을 지역화합니다. 이렇게 하면 추가 작업과 우아하지 않은 솔루션처럼 보일 수 있지만 다음과 같은 이유로 최상의 솔루션입니다.

  • 모든 언어에 대해 문법적으로 올바른 메시지가 표시됩니다.
  • 번역기에서는 문자열이 대체될 항목에 대해 물어볼 필요가 없습니다.
  • 앱이 완료된 후 이와 같은 문제가 발생하는 경우 비용이 많이 드는 코드 수정을 구현할 필요가 없습니다.

문자열에 대한 기타 고려 사항

기본 언어로 작성하는 문자열에서 구어체와 은유를 사용하지 마세요. 문화 및 연령과 같은 인구 통계 그룹과 관련된 언어는 해당 인구 집단의 사용자만 해당 언어를 사용하기 때문에 이해하거나 번역하기 어려울 수 있습니다. 마찬가지로, 은유는 한 사람에게 의미가 있지만 다른 사람에게는 아무 의미가 없습니다. 예를 들어 "bluebird"는 스키 문화의 일부인 사람들에게 특별한 의미가 있지만, 그 문화에 속하지 않는 사람들은 그 의미를 이해하지 못합니다.

기술 전문 용어, 줄임말 또는 약어를 사용하지 마세요. 기술 언어는 비기술적 대상 그룹이나 다른 문화권이나 지역의 사람들이 이해할 가능성이 적으며 번역하기가 어렵습니다. 사람들은 일상적인 대화에서 이러한 종류의 단어를 사용하지 않습니다. 하드웨어 및 소프트웨어 문제를 식별하기 위해 오류 메시지에 기술 언어가 표시되는 경우가 많지만, 사용자가 해당 수준의 정보를 필요로 하고 작업을 수행하거나수 있는 사람을 찾을 수 있는 경우에만 기술 문자열이어야 합니다.

문자열에서 비공식적인 음성 또는 톤을 사용하는 것은 유효한 선택입니다. 기본 리소스 파일(.resw)의 주석을 사용하여 해당 의도를 나타낼 수 있습니다.

의사 지역화

지역화 가능성 문제를 발견하기 위해 앱을 의사 지역화합니다. 의사 지역화는 일종의 지역화 사전 테스트 또는 공개 테스트입니다. 실제로 번역되지 않은 리소스 집합을 생성합니다. 그들은 단지 번역된 것처럼 보일 뿐입니다. 예를 들어, 귀하의 문자열은 기본 언어보다 약 40% 더 길며, UI에서 문자열이 잘렸는지 여부를 쉽게 확인할 수 있도록 구분 기호가 포함되어 있습니다.

배포 고려 사항

지역화된 언어 데이터가 포함된 앱을 설치할 때 여러 언어에 대한 리소스를 처음 포함하더라도 앱에 기본 언어만 사용할 수 있음을 확인할 수 있습니다. 설치 프로세스가 디바이스의 현재 언어 및 문화권과 일치하는 언어 리소스만 설치하도록 최적화되었기 때문입니다. 따라서 디바이스가 en-US대해 구성된 경우 en-US 언어 리소스만 앱에 설치됩니다.

비고

초기 설치 후에는 앱에 대한 추가 언어 지원을 설치할 수 없습니다. 앱을 설치한 후 기본 언어를 변경하는 경우 앱은 원래 언어 리소스만 계속 사용합니다.

설치 후 모든 언어 리소스를 사용할 수 있도록 하려면 설치 중에 특정 리소스(언어 리소스 포함)가 필요하도록 지정하는 앱 패키지에 대한 구성 파일을 만듭니다. 이 최적화된 설치 기능은 패키징 중에 애플리케이션의 .appxbundle이 생성될 때 자동으로 사용하도록 설정됩니다. 자세한 내용은 디바이스의 필요 여부에 관계없이 디바이스에 리소스가 설치되어 있는지 확인하십시오.

필요에 따라 하위 집합이 아닌 모든 리소스가 설치되도록 하려면 앱을 패키지할 때 .appxbundle 생성을 사용하지 않도록 설정할 수 있습니다. 그러나 앱의 설치 시간을 늘릴 수 있으므로 권장되지 않습니다.

"앱 번들 생성" 특성을 "never"로 설정하여 .appxbundle의 자동 생성을 사용하지 않도록 설정합니다.

  1. Visual Studio에서 프로젝트 이름을 마우스 오른쪽 단추로 클릭합니다.
  2. 스토어 선택 - 앱 패키지>만들기...
  3. 패키지 만들기 대화 상자에서 새 앱 이름 사용하여 Microsoft Store에 업로드할 패키지를 만들 선택한 다음클릭합니다.
  4. 앱 이름 선택 대화 상자에서 패키지의 앱 이름을 선택/만듭니다.
  5. 패키지 선택 및 구성 대화 상자에서 앱 번들 생성절대 안 함으로 설정합니다.

지정학적 인식

지도에서 또는 지역을 참조할 때 정치적 범죄를 피하십시오. 지도에는 논란의 여지가 있는 지역 또는 국경이 포함될 수 있으며, 정치적 범죄의 빈번한 원인입니다. 국가를 선택하는 데 사용하는 UI가 "국가/지역"으로 표시되도록 주의하세요. 주소 양식과 같이 "국가"라는 레이블이 지정된 목록에 분쟁 지역을 나열하면 일부 사용자에게 불쾌감을 줄 수 있습니다.

언어 및 지역 변경 이벤트

시스템의 언어 및 지역 설정이 변경될 때 발생하는 이벤트를 구독합니다. 적절한 경우 리소스를 다시 로드할 수 있도록 이 작업을 수행합니다. 자세한 내용은 한정자 값 변경 이벤트 대한 응답으로 문자열을 업데이트하고한정자 값 변경 이벤트에 대한 응답으로 이미지를 업데이트하는 참조하세요.

문자열 서식을 지정할 때 올바른 매개 변수 순서 확인

모든 언어가 동일한 순서로 매개 변수를 표현한다고 가정하지 마세요. 예를 들어 이 형식을 고려해 보세요.

    string.Format("Every {0} {1}", monthName, dayNumber); // For example, "Every April 1".

이 예제의 형식 문자열은 영어(미국)에서 작동합니다. 그러나 일 및 월이 역순으로 표시되는 독일(독일)에는 적합하지 않습니다. 번역기에서 각 매개 변수의 의도를 알고 있으므로 대상 언어에 적합한 형식 문자열(예: "{1}{0}")의 형식 항목 순서를 되돌릴 수 있는지 확인합니다.

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

번역가에게만 자연어를 제출합니다. 프로그래밍 언어나 태그가 아닙니다. <link> 태그는 자연어가 아닙니다. 이러한 예제를 고려해 보세요.

지역화하지 마세요. 이것을 현지화하십시오
<링크>사용< 약관/링크> 사용 약관
<링크>개인 정보 취급 방침</link> 개인 정보 취급 방침

<link> 리소스 파일(.resw)에 태그를 포함하면 태그도 번역될 가능성이 높습니다. 그러면 태그가 유효하지 않습니다. 컨텍스트를 유지하고 순서 지정을 보장하기 위해 태그를 포함해야 하는 긴 문자열이 있는 경우 주석에서 번역하지 않을 내용을 명확히 합니다.

적절한 번역 방법 선택

문자열을 리소스 파일로 구분한 후에는 변환할 수 있습니다. 문자열을 번역하는 이상적인 시기는 프로젝트의 문자열이 완료된 후이며, 일반적으로 프로젝트가 끝날 때 발생합니다. 여러 가지 방법으로 번역 프로세스에 접근할 수 있습니다. 번역할 문자열의 양, 번역할 언어 수 및 번역이 수행되는 방법(예: 사내 및 외부 공급업체 고용)에 따라 달라질 수 있습니다.

이러한 옵션을 고려합니다.

  • 리소스 파일은 프로젝트에서 직접 열어 변환할 수 있습니다. 이 방법은 두 개 또는 세 개의 언어로 번역해야 하는 작은 양의 문자열이 있는 프로젝트에 적합합니다. 개발자가 둘 이상의 언어를 사용하고 번역 프로세스를 처리하려는 시나리오에 적합할 수 있습니다. 이 방법은 빠른 작업으로 이점을 활용하고, 도구가 필요하지 않으며, 잘못된 번역의 위험을 최소화합니다. 그러나 확장할 수 없습니다. 특히, 다른 언어의 리소스는 쉽게 동기화에서 벗어날 수 있으며, 이로 인해 사용자 환경이 나빠지고 유지 관리 골칫거리가 발생할 수 있습니다.
  • 문자열 리소스 파일은 XML 또는 ResJSON 텍스트 형식이므로 텍스트 편집기를 사용하여 번역을 위해 전달될 수 있습니다. 그러면 번역된 파일이 프로젝트에 다시 복사됩니다. 이 방법은 번역자가 실수로 XML 태그를 편집할 위험이 있지만 Microsoft Visual Studio 프로젝트 외부에서 번역 작업을 수행할 수 있습니다. 이 방법은 적은 수의 언어로 번역해야 하는 프로젝트에 적합할 수 있습니다. XLIFF 형식은 지역화에 사용하도록 특별히 설계된 XML 형식이며 일부 지역화 공급업체 또는 지역화 도구에서 잘 지원되어야 합니다. 다국어 앱 도구 키트를 사용하여 .resw 또는 .resjson과 같은 다른 리소스 파일에서 XLIFF 파일을 생성할 수 있습니다.

비고

이미지 및 오디오 파일을 비롯한 다른 자산에도 지역화가 필요할 수 있습니다.

또한 다음을 고려해야 합니다.

  • 지역화 도구 다양한 지역화 도구를 사용하여 리소스 파일을 구문 분석하고 번역 가능한 문자열만 번역자가 편집할 수 있습니다. 이 방법을 사용하면 번역기에서 실수로 XML 태그를 편집할 위험이 줄어듭니다. 그러나 지역화 프로세스에 새 도구 및 프로세스를 도입하는 단점이 있습니다. 지역화 도구는 많은 양의 문자열이 있지만 언어가 적은 프로젝트에 적합합니다. 자세한 내용은 다국어 앱 도구 키트를 사용하는 방법을 참조하세요.
  • 지역화 공급업체 애플리케이션에 많은 수의 언어로 번역해야 하는 광범위한 문자열이 포함된 경우 지역화 공급업체를 사용하는 것이 좋습니다. 지역화 공급업체는 리소스 파일을 번역할 뿐만 아니라 도구 및 프로세스에 대한 조언을 제공할 수 있습니다. 이는 이상적인 솔루션이지만 가장 비용이 많이 드는 옵션이기도 하며 번역된 콘텐츠의 소요 시간을 늘릴 수 있습니다.

액세스 키 및 레이블 일관성 유지

두 문자열 리소스가 별도의 두 섹션으로 분류되므로 접근성에 사용되는 액세스 키를 지역화된 액세스 키 표시와 "동기화"하는 것은 어려운 일입니다. 레이블 문자열에 대한 주석(예: Make sure that the emphasized shortcut key is synchronized with the access key.)을 제공해야 합니다.

정렬 가능한 일본어 문자열에 대한 후리가나 지원

일본어 간지 문자는 사용되는 단어에 따라 둘 이상의 읽기(발음)를 갖는 속성을 가집니다. 이렇게 하면 애플리케이션 이름, 파일, 노래 등과 같은 일본어 명명된 개체를 정렬하려고 할 때 문제가 발생합니다. 일본의 간지는 과거에 일반적으로 XJIS라는 기계 이해할 수있는 순서로 정렬되었습니다. 불행히도, 이 정렬 순서는 발음 순서가 아니어서 사람들에게는 크게 유용하지 않습니다.

후리가나는 사용자 또는 작성자가 사용하는 문자에 대해 발음을 지정할 수 있도록 하여 이 문제를 해결합니다. 다음 절차를 사용하여 앱 이름에 furigana를 추가하는 경우 앱 목록의 적절한 위치에 정렬되어 있는지 확인할 수 있습니다. 사용자의 UI 언어 또는 정렬 순서가 일본어로 설정된 경우 앱 이름에 간지 문자가 포함되어 있고 후리가나가 제공되지 않는 경우 Windows는 적절한 발음을 생성하기 위해 최선을 다하고 있습니다. 그러나 희귀하거나 고유한 읽기 방식을 가진 앱 이름이 더 일반적인 읽기 방식으로 정렬될 가능성이 있습니다. 따라서 일본어 애플리케이션(특히 이름에 간지 문자가 포함된 애플리케이션)의 모범 사례는 일본어 지역화 프로세스의 일부로 앱 이름의 후리가나 버전을 제공하는 것입니다.

  1. 패키지 표시 이름 및 애플리케이션 표시 이름으로 "ms-resource:Appname"을 추가합니다.

  2. 문자열 아래에 ja-JP 폴더를 만들고 다음과 같이 두 개의 리소스 파일을 추가합니다.

    strings\
        en-us\
        ja-jp\
            Resources.altform-msft-phonetic.resw
            Resources.resw
    
  3. Resources.resw 파일의 일반 ja-JP에 대해 Appname "希蒼"의 문자열 리소스를 추가하세요.

  4. 일본어 후리가나 리소스에 대한 Resources.altform-msft-phonetic.resw에서: AppName "のあ"에 후리가나 값 추가

사용자는 후리가나 값 "のあ"(noa)와 발음 값(IME(입력 방법 편집기)의 GetPhonetic 함수 사용) "まれあお"(mare-ao)을 모두 사용하여 앱 이름 "希蒼"을 검색할 수 있습니다.

정렬은 국가별 제어판 형식을 따릅니다.

  • 일본어 사용자 지역 설정에서
    • 후리가나를 사용하도록 설정하면 "希蒼"이 "の" 아래에 정렬됩니다.
    • 후리가나가 없으면 "希蒼"이 "ま"로 분류됩니다.
  • 일본어가 아닌 사용자 로캘에서
    • 후리가나를 사용하도록 설정하면 "希蒼"이 "の" 아래에 정렬됩니다.
    • 후리가나가 없으면 "希蒼"이 "漢字" 아래에 정렬됩니다.

샘플