MUI 기본 개념 설명

• MUI에 대한 필수 구성 요소
• 언어별 리소스에서 소스 코드 분리
  • 초기: 코드와 리소스가 함께 사용됨
  • 논리적으로 코드 및 지역화 가능한 리소스 분리
  • 코드 및 리소스를 물리적으로 분리
• 언어별 리소스 동적 로드
• MUI 애플리케이션 빌드

MUI에 대한 필수 구성 요소

Windows Vista 이상용 MUI 규격 애플리케이션을 빌드하기 위한 기본 필수 구성 요소는 Windows 세계화 지침에 따라 애플리케이션을 디자인하는 것입니다.

언어별 리소스에서 소스 코드 분리

MUI 기술의 기본 전제 중 하나는 애플리케이션 소스 코드를 언어별 리소스와 분리하여 애플리케이션에서 다국어 시나리오를 보다 효율적으로 사용하도록 설정하는 것입니다. 코드와 리소스의 분리는 다음 섹션에 설명된 대로 시간이 지남에 따라 다양한 메커니즘과 다양한 각도로 수행되었습니다. 각 메서드는 애플리케이션을 빌드, 배포 및 서비스할 때 다양한 수준의 유연성을 제공했습니다.

MUI 규격 애플리케이션에 권장되는 솔루션은 여기에 설명된 마지막 방법, 즉 애플리케이션 소스 코드와 리소스의 물리적 분리이며, 리소스 자체는 빌드, 배포 및 서비스의 유연성을 극대화하기 위해 지원되는 언어당 하나의 파일로 더 세분화됩니다.

초기: 코드와 리소스가 함께 사용됨

처음에는 소스 코드를 편집하고 코드 자체에서 리소스(일반적으로 문자열)를 변경하고 애플리케이션을 다시 컴파일하여 지역화된 애플리케이션을 만들었습니다. 즉, 지역화된 버전을 생성하려면 원본 소스 코드를 복사하고, 소스 코드 내에서 텍스트(리소스) 요소를 번역하고, 코드를 다시 컴파일해야 했습니다. 다음 이미지는 지역화해야 하는 텍스트가 있는 애플리케이션 코드를 보여줍니다.

이 방법을 사용하면 지역화된 애플리케이션을 만들 수 있지만 다음과 같은 중요한 단점이 있습니다.

• 원본 언어에 대해 하나 이상, 각 대상 언어에 대해 하나씩 여러 버전의 소스 코드가 필요합니다. 이렇게 하면 애플리케이션의 다양한 언어 릴리스를 동기화하는 데 중요한 문제가 발생합니다. 특히 코드에서 결함을 수정해야 하는 경우 소스 코드의 모든 복사본(언어당 하나씩)에서 결함을 수정해야 합니다.
• 또한 개발자가 아닌 지역화자가 소스 코드를 수정해야 하므로 오류가 발생하기 쉽기 때문에 코드 무결성 측면에서 상당한 위험이 발생합니다.

이러한 단점의 조합은 이것을 매우 비효율적인 제안으로 만들고 더 나은 모델이 필요했습니다.

논리적으로 코드 및 지역화 가능한 리소스 분리

이전 모델에 비해 크게 개선된 점은 애플리케이션에 대한 코드와 지역화 가능한 리소스를 논리적으로 분리하는 것입니다. 이렇게 하면 리소스에서 코드가 격리되고 지역화에 의해 리소스가 변경될 때 코드가 그대로 유지됩니다. 구현 관점에서 문자열 및 기타 사용자 인터페이스 요소는 비교적 쉽게 번역할 수 있고 코드 섹션과 논리적으로 구분되는 리소스 파일에 저장됩니다.

지정된 언어에 대한 지원을 추가하는 것은 코드를 수정할 필요 없이 지역화 가능한 리소스를 이 새 언어로 변환하고 이러한 번역된 리소스를 사용하여 새 지역화된 버전의 애플리케이션을 만드는 것만큼 간단할 수 있습니다. 다음 이미지는 애플리케이션 내에서 코드와 지역화 가능한 리소스를 논리적으로 구분하는 방법을 보여 줍니다.

이 모델을 사용하면 지역화된 버전의 애플리케이션을 더 쉽게 만들 수 있으며 이전 모델에 비해 크게 향상되었습니다. 리소스 관리 도구를 사용하여 구현된 이 모델은 수년에 걸쳐 매우 성공적이었으며 오늘날에도 많은 애플리케이션에서 일반적으로 사용됩니다. 그러나 다음과 같은 중요한 단점이 있습니다.

• 논리적으로 구분되지만 코드 및 지역화된 리소스는 여전히 하나의 실행 파일에서 물리적으로 조인됩니다. 특히 동일한 코드 결함(모든 언어 버전에서 동일)에 언어당 패치가 필요하므로 서비스 효율성은 여전히 문제가 됩니다. 따라서 애플리케이션을 20개 언어로 배송하는 경우 코드가 한 번만 수정되더라도 서비스 패치를 20번(각 언어마다 하나씩) 발급해야 합니다.
• 다국어 애플리케이션의 배포 및 사용은 이 모델에서 적절하게 지원되지 않습니다. 이는 OEM 및 엔터프라이즈 시나리오에서 중요한 문제가 될 수 있습니다. instance 경우 서로 다른 언어를 사용하는 두 사용자 간에 컴퓨터를 공유하려면 애플리케이션을 이 모델과 함께 두 번 설치해야 하며, 두 설치를 번갈아 가려면 일부 메커니즘을 사용하도록 설정해야 합니다. 이 경우 이 시나리오도 구현되지 않도록 하는 추가 종속성이 없다고 가정합니다. 다음 이미지는 두 개의 패치가 필요한 단일 코드 결함의 예를 보여 줍니다.

이 모델은 일부 시나리오에서 잘 작동하지만 다국어 애플리케이션 및 배포에 대한 제한 사항은 매우 문제가 될 수 있습니다.

다국어 애플리케이션 문제 중 일부를 완화하는 이 모델의 변형은 지역화 가능한 리소스에 다양한 언어 리소스 집합이 포함된 모델입니다. 이 모델에는 동일한 애플리케이션의 여러 언어에 대한 공통 코드 베이스와 여러 리소스가 있습니다. 예를 들어 애플리케이션은 동일한 패키지에서 영어, 독일어, 프랑스어, 스페인어, 네덜란드어 및 이탈리아어와 함께 제공 될 수 있습니다. 다음 이미지는 여러 언어 리소스를 포함하는 애플리케이션을 보여 줍니다.

이 모델을 사용하면 코드 결함을 수정해야 하는 경우(개선된) 애플리케이션을 더 쉽게 서비스할 수 있지만, 추가 언어 지원과 관련하여 이전 모델보다 개선되지는 않습니다. 이 경우 새 버전의 애플리케이션을 릴리스해야 합니다(모든 언어 리소스가 동일한 배포 내에서 동기화되도록 해야 하므로 해당 릴리스가 잠재적으로 복잡할 수 있음).

코드 및 리소스를 물리적으로 분리

다음 진화 단계는 코드와 리소스를 물리적으로 분리하는 것입니다. 이 모델에서 리소스는 코드에서 추상화되고 다른 구현 파일에서 물리적으로 구분됩니다. 특히 이는 코드가 진정한 언어 독립적이 될 수 있음을 의미합니다. 동일한 물리적 코드는 실제로 모든 지역화된 애플리케이션 버전에 대해 제공됩니다. 다음 이미지는 코드와 지역화 가능한 리소스를 물리적으로 분리해야 한다는 것을 보여 줍니다.

이 방법은 이전 방법보다 몇 가지 이점이 있습니다.

• 다국어 솔루션의 배포는 매우 간소화됩니다. 지정된 언어에 대한 지원을 추가하려면 이 특정 언어에 대한 새 언어 리소스 집합만 전달하고 설치해야 합니다. 이는 언어 리소스를 모두 동시에 사용할 수 없는 경우에 특히 중요합니다. 이 모델을 사용하면 실제 코드를 수정하거나 다시 배포하지 않고도 애플리케이션을 핵심 언어 집합으로 배포하고 시간이 지남에 따라 지원되는 언어 수를 늘릴 수 있습니다. 이러한 이점은 이 기본 설정 언어에서 찾을 수 없는 리소스가 사용자가 이해하는 다른 언어로 "대체"되도록 하여 지정된 언어로 애플리케이션 및 시스템 구성 요소의 부분 지역화를 허용하는 대체 메커니즘에 의해 더욱 확장됩니다. 전반적으로 이 모델은 훨씬 더 효과적인 방식으로 단일 이미지 배포를 가능하게 하므로 글로벌 기업이 여러 언어로 애플리케이션을 배포할 때 직면하는 상당한 부담을 완화하는 데 도움이 됩니다.
• 서비스 효율성이 향상되었습니다. 코드는 완전히 지역화와 독립적이므로 코드 결함을 한 번만 수정하고 배포하면 됩니다. 이 모델을 사용하면 변경 내용이 UI와 관련이 없는 경우 코드 결함에 대한 수정을 실행하는 것이 이전 모델보다 훨씬 간단하고 비용 효율적입니다.

언어별 리소스 동적 로드

소스 코드를 언어별 리소스와 물리적으로 분리하고 애플리케이션에 대한 언어 중립적 코어 이진 파일을 빌드하는 MUI 기본 개념은 기본적으로 사용자 및 시스템 언어 설정에 따라 언어별 리소스의 동적 로드를 구현하는 데 도움이 되는 아키텍처를 설정합니다.

언어 중립적 코어 이진 파일에 번들로 제공되는 애플리케이션 소스 코드는 Windows 플랫폼의 MUI API를 활용하여 지정된 컨텍스트에 적합한 표시 사용자 인터페이스 언어의 선택을 추상화할 수 있습니다. MUI는 다음을 통해 이를 지원합니다.

• 시스템, 사용자 및 애플리케이션 수준, 사용자 수준 및 시스템 수준 설정에 따라 우선 순위가 지정된 표시 사용자 인터페이스 언어 목록을 생성합니다.
• 지역화된 리소스의 가용성에 따라 이 우선 순위가 지정된 언어 목록에서 적절한 후보를 선택하는 대체 메커니즘을 구현합니다.

우선 순위가 지정된 대체를 사용하여 사용자 인터페이스 리소스를 동적으로 로드하면 다음과 같은 이점이 있습니다.

• 이 기본 설정 언어에서 찾을 수 없는 리소스가 자동으로 우선 순위가 지정된 목록의 다음 언어로 대체되므로 지정된 언어로 애플리케이션 및 시스템 구성 요소를 부분적으로 지역화할 수 있습니다.
• 한 언어에서 다른 언어로 동적으로 전환하는 등의 시나리오를 사용할 수 있습니다.
• OEM 및 엔터프라이즈용 언어 집합을 포함하는 지역 또는 전 세계 단일 배포 이미지를 만들 수 있습니다.

MUI 애플리케이션 빌드

이전 섹션에서는 언어별 리소스에서 소스 코드를 분리하는 옵션과 핵심 Windows 플랫폼 API를 활용하여 지역화된 리소스를 동적으로 로드할 수 있다는 이점을 설명했습니다. 이러한 지침은 지침이지만 Windows 플랫폼용 MUI 애플리케이션을 개발하는 구체적인 규범적 방법이 없다는 점도 지적해야 합니다.

애플리케이션 개발자는 다양한 사용자 인터페이스 언어 설정, 리소스 만들기 옵션 및 리소스 로드 방법을 처리하는 방법을 선택할 수 있습니다. 개발자는 이 문서에 제공된 지침을 평가하고 요구 사항 및 개발 환경에 맞는 조합을 선택할 수 있습니다.

다음 표에는 Windows 플랫폼용 MUI 애플리케이션을 만들려는 애플리케이션 개발자가 사용할 수 있는 다양한 디자인 옵션이 요약되어 있습니다.

사용자 인터페이스 언어 설정	리소스 만들기	리소스 로드
운영 체제에서 UI 언어 설정 팔로우${REMOVE}$	분할 리소스 이진 파일의 단일 언어(MUI 리소스 기술) 또는 분할이 아닌 리소스 이진 파일의 여러 언어	애플리케이션은 표준 리소스 로드 함수를 호출합니다. 리소스는 운영 체제 설정과 일치하는 언어로 반환됩니다.
	애플리케이션별 리소스 메커니즘	애플리케이션은 MUI API를 호출하여 운영 체제에서 스레드 기본 설정 UI 언어 또는 프로세스 기본 설정 UI 언어를 검색하고 이러한 설정을 사용하여 자체 리소스를 로드합니다.
애플리케이션별 UI 언어 설정${REMOVE}$	분할 리소스 이진 파일의 단일 언어 또는 분할이 아닌 리소스 이진 파일의 여러 언어	애플리케이션은 MUI API를 호출하여 애플리케이션별 UI 언어 또는 프로세스 기본 설정 UI 언어를 설정한 다음 표준 리소스 로드 함수를 호출합니다. 리소스는 애플리케이션 또는 시스템 언어에서 설정한 언어로 반환됩니다. 또는 애플리케이션은 특정 언어로 리소스를 검색하고 검색된 이진 데이터에서 자체 리소스 추출을 처리합니다.
	애플리케이션별 리소스 메커니즘	애플리케이션은 자체 리소스 로드를 관리합니다.