Share via

앱을 현지화 가능하게 만들기

  • 아티클

지역화된 앱은 앱의 기능적 결함을 노출하지 않고 다른 시장, 언어 또는 지역에 맞게 지역화할 수 있습니다. 지역화 가능한 앱의 가장 중요한 속성은 실행 가능한 코드가 지역화 가능한 리소스와 완전히 분리되었다는 것입니다. 따라서 앱 리소스 중 어떤 부분을 지역화해야 하는지 결정해야 합니다. 앱을 다른 시장용으로 지역화할 경우 무엇을 변경해야 하는지 자문해 보세요.

또한 세계화 지침을 숙지하는 것이 좋습니다.

문자열을 리소스 파일(.resw)에 배치

문자열 리터럴을 명령 코드, XAML 마크업 또는 앱 패키지 매니페스트에서 하드코딩하지 마세요. 대신 앱이 작성된 이진 코드와 독립적으로 다른 현지 시장에 적용될 수 있도록 문자열을 리소스 파일(.resw)에 배치하세요. 자세한 내용은 UI와 앱 패키지 매니페스트에 문자열 지역화를 참조하세요.

이 항목에는 기본 리소스 파일(.resw)에 주석을 추가하는 방법도 나와 있습니다. 예를 들어 비공식 음성 또는 어조를 채택하는 경우 이를 주석에 기술해야 합니다. 또한 비용을 최소화할 수 있도록 번역해야 하는 문자열만 번역자에게 제공합니다.

앱 패키지 매니페스트 원본 파일(Package.appxmanifest 파일)에서 앱의 기본 언어를 적절하게 설정합니다. 기본 언어에 따라 사용자의 기본 설정 언어가 앱에서 지원되는 언어와 일치하지 않을 때 사용되는 언어가 결정됩니다. 리소스의 언어와 특정 상황에서 리소스가 사용되는 방법을 시스템이 알 수 있도록, 모든 리소스를 해당 언어로 표시합니다(리소스가 기본 언어로 작성된 경우에도 마찬가지. 예: \Assets\en-us\Logo.png).

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

이미지를 세계화할 수 있습니다. 즉, 문화권의 영향을 받지 않는 이미지를 만듭니다. 이것이 불가능한 이미지 및 기타 파일 리소스의 경우 필요에 따라 다양한 다른 변수를 만들고 파일 또는 폴더 이름에 적절한 언어 한정자를 넣습니다. 자세한 내용은 언어, 배율, 고대비 및 기타 한정자에 맞게 리소스 조정을 참조하세요.

지역화 비용을 최소화하려면 텍스트와 문화적으로 민감한 자료를 이미지에 넣지 마세요. 개발자의 문화권에는 아무 문제 없는 이미지가 다른 문화권에서는 불쾌감이나 오해를 유발할 수 있습니다. 사서함처럼 특정 문화권에만 있는 이미지를 사용하지 마세요. 사서함은 전 세계적으로 일반적이지 않습니다. 종교적 기호, 동물, 정치 또는 젠더와 관련된 이미지를 사용하지 마세요. 피부, 신체 또는 손짓 제스처도 민감한 주제일 수 있습니다. 이 모든 것을 피하는 것이 불가능하다면 이미지를 신중하게 지역화해야 합니다. 읽기 방향이 다른 언어로 지역화하는 경우에는 대칭 이미지와 효과를 사용하면 미러링 지원이 더 쉽습니다.

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

앱에서 색상 사용

색상을 사용할 때 주의해야 합니다. 국기 또는 정치적 운동과 연관된 색상 조합을 사용하면 문제가 될 수 있습니다. 색상 조합은 문화권 전문가의 검토를 받아야 할 수 있습니다. 색상 사용과 관련하여 접근성 문제도 있습니다. 색상을 사용하여 의미를 전달하는 경우 크기, 모양 또는 레이블과 같은 다른 의미로 동일한 정보를 전달할 수 있습니다.

문장의 문자열도 고려해야 합니다.

적절한 크기의 문자열을 사용합니다. 짧은 문자열은 번역하기 쉽고 번역을 재사용할 수도 있습니다(동일만 문자열은 두 번 이상 로컬라이저로 전송되지 않으므로 비용이 절약됨). 지나치게 긴 문자열은 지역화 도구에서 지원되지 않을 수 있습니다.

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

또한 영어에서는 "text" 또는 "fax" 같은 문자열을 동사와 명사로 모두 사용할 수 있으므로 번역 프로세스에 혼동이 갈 수 있습니다. 대신 동사와 명사 형식 모두에 대해 각기 다른 문자열을 만듭니다. 컨텍스트가 동일한지 확실하지 않은 경우에는 보수적으로 선택하고 고유 문자열을 사용합니다.

즉, 모든 컨텍스트에서 활용될 수 있도록 문자열을 작은 단위로 분리합니다. 문자열이 전체 문장이어야 하는 경우도 있습니다.

"The {0} could not be synchronized"라는 문자열을 예로 들겠습니다.

{0} 자리에 "appointment", "task", "document" 등의 다양한 단어가 올 수 있습니다. 이 예가 영어에는 잘 맞지만 독일어에서는 잘 맞지 않는 경우가 있습니다. 다음 독일어 문장에서는 템플릿 문자열("Der", "Die", "Das")의 일부 단어가 매개 변수화된 단어와 일치해야 합니다.

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

또 다른 예로 "Remind me in {0} minute(s)"라는 문장을 살펴보겠습니다. 영어에서는 "minute(s)"을 사용할 수 있지만 다른 언어에서는 다른 용어를 사용해야 할 수도 있습니다. 예를 들어, 폴란드어 언어에서는 컨텍스트에 따라 "minuta", "minuty" 또는 "minut"를 사용합니다.

이 문제를 해결하려면, 한 단어가 아닌 전체 문장을 지역화합니다. 이렇게 하면 추가 작업과 세련되지 않은 솔루션처럼 보여도 다음과 같은 이유에서 최상의 솔루션입니다.

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

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

기본 언어로 작성한 문자열에 구어체와 비유를 사용하지 마세요. 문화, 연령 등 특정 인구 그룹에서 사용하는 언어는 해당 그룹의 사람들만 사용하므로 이해하거나 번역하기가 어렵습니다. 마찬가지로, 메타포는 한 사람에게 의미가 있지만 다른 사람에게는 의미가 없을 수 있습니다. 예를 들어 "블루버드"는 스키를 즐기는 사람들에게는 특별한 의미가 있지만, 그렇지 않은 사람들은 이해하지 못합니다.

기술 전문 용어, 약어 또는 두문자어를 사용하지 마세요. 기술 언어는 비기술적 대상 그룹이나 다른 문화권이나 지역의 사람들이 이해할 가능성이 적고 번역하기가 어렵습니다. 사람들은 일상적인 대화에서 이런 종류의 단어를 사용하지 않습니다. 하드웨어와 소프트웨어 문제를 식별하기 위해 오류 메시지에 종종 기술적인 언어가 사용되지만 사용자에게 그 정도 수준의 정보가 필요한 경우 및 조치를 취하거나 조치를 취할 누군가를 찾는 경우에만 문자열이 기술적이어야 합니다.

문자열에 구어체를 사용하는 것은 유효한 방법입니다. 기본 리소스 파일(.resw)에 주석을 사용하여 해당 의도를 나타낼 수 있습니다.

의사 지역화

앱을 의사 지역화하여 지역화 문제를 알아냅니다. 의사 지역화는 지역화의 한 종류로 예행 연습 또는 비공개 테스트와 같은 것입니다. 실제로는 번역되지 않지만 번역된 것처럼 보이는 리소스 세트를 만듭니다. 문자열이 기본 언어로 약 40% 더 길게 표시됩니다. 예를 들어, 문자열에 구분 기호가 있어 UI가 잘렸는지 여부를 한눈에 알아볼 수 있습니다.

배포 고려 사항

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

참고 항목

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

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

필요에 따라 하위 세트뿐 아니라 모든 리소스를 설치하려면 앱을 패키징할 때 .appxbundle 생성을 해제하면 됩니다. 하지만 이렇게 하면 앱의 설치 시간이 길어질 수 있으므로 권장하지 않습니다.

"Generate App Bundle" 특성을 "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>terms of use</link> 사용 약관
<link>privacy policy</link> 개인 정보 취급 방침

리소스 파일(.resw)에 <link> 태그를 포함해도 번역할 가능성이 높습니다. 태그가 올바르지 않게 렌더링됩니다. 긴 문자열에서 컨텍스트 및 순서를 올바르게 유지하기 위해 마크업을 포함해야 하는 경우 번역하지 말아야 할 사항을 주석에 명확히 기록합니다.

적절한 번역 방법을 선택합니다.

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

다음 옵션을 고려합니다.

  • 프로젝트에서 리소스 파일은 직접 열어 변역할 수 있습니다. 이 방식은 문자열의 양이 적고 2~3개 언어로 번역해야 하는 프로젝트에 적합합니다. 이 방식은 개발자가 둘 이상의 언어를 사용하고 번역 프로세스를 처리할 의향이 있는 시나리오에 적합할 수 있습니다. 이 방법은 빠르고 도구가 필요 없으며 오역 위험이 최소화된다는 이점이 있습니다. 그러나 확장할 수 없습니다. 특히 서로 다른 언어의 리소스는 동기화에서 쉽게 벗어나 부정적인 사용자 환경과 유지 관리 문제를 일으킬 수 있습니다.
  • 문자열 리소스 파일은 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라는 순서로 주로 정렬되었습니다. 아쉽게도 이 정렬 순서는 음성이 아니기 때문에 인간에게 그다지 유용하지 않습니다.

후리가나는 사용자 또는 생성자가 사용 중인 문자에 대한 발음을 지정하도록 허용하여 이 문제를 해결합니다. 아래 절차에 따라 앱 이름에 후리가나를 추가하면 후리가나가 앱 목록의 적절한 위치에 정렬됩니다. 앱 이름에 간지 문자가 포함되어 있고 사용자의 UI 언어 또는 정렬 순서가 일본어로 설정되어 있을 때 후리가나가 제공되지 않는 경우 Windows에서 적절한 발음을 생성합니다. 그러나 희귀하거나 고유한 판독값을 포함하는 앱 이름이 더 일반적인 판독으로 분류될 가능성이 있습니다. 그러므로 일본어 애플리케이션(특히 이름에 간지 문자를 포함하는 애플리케이션)을 위한 모범 사례는 앱 이름의 후리가나 버전을 일본어 지역화 프로세스의 일부로 제공하는 것입니다.

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

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

    strings\
    en-us\
    ja-jp\
        Resources.altform-msft-phonetic.resw
        Resources.resw

  3. 일반 ja-JP에 대한 Resources.resw: Appname "希蒼"에 대한 문자열 리소스 추가

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

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

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

  • 일본어 사용자 로캘 아래에
    • 후리가나가 사용하도록 설정되어 있는 경우 "希蒼"이 "の" 아래에 정렬됩니다.
    • 후리가나가 없는 경우 "希蒼"이 "ま" 아래에 정렬됩니다.
  • 일본어가 아닌 사용자 로캘 아래에
    • 후리가나가 사용하도록 설정되어 있는 경우 "希蒼"이 "の" 아래에 정렬됩니다.
    • 후리가나가 없는 경우 "希蒼"이 "漢字" 아래에 정렬됩니다.

샘플