문자열 리소스가 일반적으로 코드 외부가 아닌 코드 외부에 유지되는 이유는 무엇입니까?

일반적으로 많은 플랫폼에서 문자열 리소스를 .resx 또는 .xml 파일에 쓰고 플랫폼 의존적 접근 방식을 사용하고 있습니다.

즉, iOS에서는을 통해 Android에서 NSBundle.MainBundle사용 Context.Resources하고 있습니다.

이 방법의 장점은 무엇이며 코드에서 직접 액세스 할 수없는 이유는 다음과 같습니다.

1. 크로스 플랫폼 프로젝트에서 모든 플랫폼은 통합없이 직접 액세스 할 수 있습니다.

2. 리소스가 제대로 구축되었는지 여부에 대해 구축하는 동안 걱정할 필요가 없습니다.

3. 코더는 다국어 처리와 같은 기능을 사용할 수 있습니다

간단히 말해 : 문자열 리소스가 그렇게 구성되는 이유는 무엇입니까?

[편집하다]

내 파일이 다른 프로젝트간에 공유되는 "핵심"프로젝트의 일부라고 가정 해 봅시다. (PCL, 크로스 플랫폼 프로젝트 파일 구조에 대해 생각하십시오.)

그리고 내 파일이 .resx / .xml 파일과 완전히 유사하다고 가정합니다 (xml의 전문가는 아닙니다, 죄송합니다!) : Parameters Paramètres

따라서 이것은 기본적으로 사용자 정의 XML이며 적절한 문자열을 얻기 위해 키 / 언어를 가리 킵니다.

파일은 앱 내에 액세스 가능한 파일을 추가하고 PCL을 사용하여 코딩 된 문자열 리소스에 액세스하는 시스템을 추가하는 것처럼 애플리케이션의 일부입니다. 애플리케이션에 오버 헤드가 추가됩니까?

현지화 및 국제화,

문자열을 외부에 유지하면 다시 컴파일하지 않고도 변경 (읽기 : 번역) 할 수 있습니다 (최대로 다시 연결하고 새 폴더를 넣는 것이 가장 좋습니다).

문자열 리소스 만 포함 된 파일이 있으면 리소스 파일을 번역 대행사 또는 이와 유사한 것으로주고 번역 할 수 있습니다. 평신도에게 많은 코드 파일을 제공하여 번역을하기 위해 (어떤 사람에게 코드를주고 싶지 않은 경우) 얼마나 많은 어려움을 겪을 지 상상할 수 있습니다.

국제화 / 현지화 외에도 텍스트 문자열을 이와 같이 분리하면 교정자가 messages.${LOCALE}실제 소스 코드 파일을 건드리지 않고도 고립 된 철자 / 문법 / 구두법에 대한 수정 사항을 제출할 수 있습니다. 코드 변경에 대한 정전이있을 수 있지만 이러한 텍스트 수정은 허용됩니다. 코드와 메시지 모두에 대한 동시 변경을 수락하는 경우 코드 변경을 통해 교정자가 체크 아웃 할 때 존재했던 메시지를 재정의하지 않으면 패치를 쉽게 병합 할 수 있습니다.messages.en_US .

또한 구현 방법에 따라 응용 프로그램을 다시 연결하지 않아도 될 수도 있습니다. 코드는 단순히 messages.${LOCALE}특정 메시지에 대한 라인 (138)을 잡고 , 라인 번호는 런타임에 결정된다.

이것은 언어 / 플랫폼이 문자열 현지화를 구현하기로 결정한 방식입니다. 현지화에 대한 모든 접근 방식은 번역을 가져 오기 위해 일종의 외부 리소스 파일이 필요합니다. 주요 문제점은 이러한 리소스를 유지 관리하는 방법입니다.

이러한 리소스 파일을 수동으로 유지 관리해야하는 것처럼 보이 므로 상당한 부담이 될 수 있습니다. 또한 반복되는 문자열을 공유하는 것이 복잡합니다. 현재 하나의 언어 만 배송 할 때이 작업을 수행해야하는 것은 훨씬 더 큰 부담입니다.

일반적인 대안은 소스 코드에서 번역 가능한 문자열을 표시하고 이러한 문자열을 표준 PO 파일로 자동 추출하여 플랫폼 간 및 언어간에 잘 작동 하는 GNU Gettext 방식입니다. 개발자의 관점에서 볼 때 XML 리소스 파일의 수동 유지 관리보다 훨씬 낫습니다.