NSLocalizedString()에서 "실제"키를 사용하는 것이 안전합니까? 대체 언어가 보장 되나요?

Question

저는 많은 개발자가 다음과 같이 이것을 알고 있습니다. 그들은 영어로 앱을 개발하기 시작하며 @"Tap this to do that!" 대신 NSLoclaizedString(@"Tap this to do that!", @"Telling what to do...")을 넣습니다.

그런 다음 genstrings을 실행하면 모든 문자열을 추출하여 Localizable.strings 파일을 만듭니다. 지저분한 부분 : 코드에서 사용 된 긴 텍스트가 핵심이됩니다. 그것은 작동합니다. 어느 날 빨리 코드에 들어가서 영어 문자열을 변경하고 현지화를 잊어 버리고 모든 Localizable.strings 파일의 핵심 역할을 수행 할 때까지

그래서 문자열과 섞이지 않는 "실제"키를 사용하는 경향이 있습니다. 빠른 테스트를 위해 영어와 프랑스어로 현지화 된 프로젝트를 만들었습니다. 그런 다음 시뮬레이터 언어를 독일어로 설정했습니다. 사용자가 TTTDT과 같은 키를 보게된다면 몹시 괴로워 할 것입니다.

그래서 영어와 독일어만으로 데모 앱을 시작했습니다. 그리고 내가 가진 것은 English Localizable.strings 파일의 영어 텍스트였습니다.

결론 : OSL 언어가 앱에서 다룰 수없는 경우 NSLocalizedString이 영어 파일로 되돌아가는 것으로 보입니다.

Quesion : 항상 Localizable.strings (English) 파일이 있고 적절하게 형식이 지정된 값과 함께 파일에 ARE 키가 있다고 가정합니다. NSLocalizedString이 실패하고 키를 직접 표시하는 상황이 있습니까?

Answer 1

질문에 답변 : 예, 걱정할만한 문제가 발생했습니다. 즉, localizable.strings 파일이 있었고 키 이름에 대한 항목이 포함되어 있어도 키 이름이 표시되었습니다. 이것은 프로젝트에 두 개 이상의 localizable.strings 파일이있을 때 발생합니다. 자신의 localizable.strings (예 : ShareKit)이있는 오픈 소스 프로젝트의 파일 집합을 프로젝트에 드롭하면 쉽게 발생할 수 있습니다.

Here is a related question이이 문제를 설명합니다.

적어도 ID 스타일 키 이름을 사용하면 모든 언어로 앱을 테스트 할 때 이러한 문제가 발생합니다. 영어 (또는 기본 언어) 문자열을 키로 사용했다면 현지화 된 버전을 테스트하기 전까지는이 교활한 문제가 보이지 않을 것이며 더 쉽게 눈에 띄지 않게 될 것입니다.

텍스트를 교정 할 때 키를 (모든 언어로) 업데이트하는 것을 잊지 말고 영어 텍스트를 키로 사용할 때 잠재적으로 버그를 숨기는 문제가 있습니다 (영어는 괜찮아 보이지만 지역화되어 있음). 버전은 그렇지 않다). 따라서 실제 텍스트보다는 "실제"키 이름을 사용하는 것이 더 실용적입니다. 어떤 이유로 든 키 이름이 표시 될 수 있다고 여전히 걱정하는 경우 이해할 수있을 정도로 설명이 적어도있는 키를 선택하십시오.

Answer 2

"실제"키를 사용하는 경향이 있지만 대개 영어 텍스트 (또는 약식)이므로 끝에 "키"를 추가하십시오. 그렇게하면 분명합니다.

Answer 3

실제로 응용 프로그램의 모든 키가 모든 localizable.string 파일에 표시되는지 확인하는 사용자 정의 코드를 작성했습니다. 이 프로세스에는 두 단계가 있습니다. genstrings을 사용하여 현재 소스에서 참조 된 모든 키가 포함 된 새 지역화 가능 문자열 파일을 생성합니다. 그런 다음 기존의 localizable.strings 파일에 일부 객관적인 C API를로드하고 새로 생성 된 것과 완전히 똑같은 키 세트 (더 이상 또는 전혀 아님)를 비교했습니다.