로컬화 가능성

사용자에게 나타나는 모든 오류 메시지와 텍스트는 'STR#' 리소스 또는 'STRf' 리소스에서 제공되어야 합니다. 첫 번째 타입에는 모든 로컬화 가능 텍스트가 포함되어야 합니다. 두 번째 타입은 로컬화 불가능 메시지에 사용될 수 있습니다.

또한 디버깅 오류 메시지를 최종 버전에서 사용자가 보는 일반 오류 메시지와 분리하는 것도 중요합니다. ('Error 28'은 사용자에게 별로 의미가 없을 것) 디버깅 옵션은 일반적으로 DEBUVERS 컴파일러 스위치에 의해 표시됩니다. (디버그 버전을 컴파일할 때 make 환경에서도 이를 정의할 수 있다) 모든 디버깅 메시지를 RFIX 폴더의 gec 파일에 넣어야 합니다. 이것은 이 문자열들이 로컬화할 필요가 없음을 표시합니다. 또한 이 메시지들을 #ifdef DEBUVERS - #endif 내에 bracket으로 감싸서 릴리즈 버전에 들어가지 않도록 할 수 있습니다. (Attribute_ManagerFix.grc 파일의 'GALR' #32600 리소스 참조)

(라이브러리 파트 파라미터의 이름과 같이) 다른 로컬화 불가능 문자열도 마찬가지입니다. RFIX 폴더의 파일에도 들어가야 합니다.

멀티바이트 시스템(일본어, 한국어 등)도 알아야 합니다. ); Development Kit의 문자열 관리자를 사용하여 이러한 문제를 방지하십시오. 문제가 발생할 수 있는 전형적인 장소는 다음과 같습니다: 정적 텍스트 및 Edit 텍스트 항목, 숫자 입력 필드. (예. degree 심볼)

계명:

올바른 인터페이스 만들기: 실수를 하면(그래픽적으로 부정확하고, 나쁘고, 부정확하고, 혼란스러운 표현 등), 이러한 실수는 20개의 로컬화된 버전으로 들어갈 수 있습니다. 어쨌든 이것들은 수정되어야 하고, 20개의 버전으로 해야 한다면 시간과 돈에 많은 차이를 만들어냅니다.
English 텍스트의 매우 좋은 품질은 필수입니다: 소프트웨어의 사용성에 있어서 중요한 포인트입니다. (Localizer에게도 그러합니다) 언어 교정기와 인터페이스 디자이너의 지원에 의존하십시오. 속어나 불쾌한 표현을 절대 사용하지 마십시오. (문화적 차이를 알아두십시오) 그리고 새로운 용어를 발명하지 마십시오. 사용자는 혼란스러워할 것입니다.
불필요한 변경은 하지 마십시오: 수정이나 사소한 이익 때문에 릴리즈된 애드온의 리소스를 수정하지 마십시오. 이러한 수정은 20개의 다른 언어 버전을 통해 수행되어야 합니다.
코딩을 완료했을 때 당신은 준비가 되지 않았습니다: 최소한 도움말과 문서를 추가해야 합니다. 이것은 프로그래머와 Specificator의 작업입니다.

언어 문제:

연결을 피하십시오: 연결된 문자열로 문장을 만들지 마십시오. English로 작동한다고 해도 다른 언어(단어 순서 등)로는 결코 작동하지 않을 것입니다. 하나의 문장이나 표현식은 하나의 항목/리소스이어야 합니다.
매우 짧은 English 표현식을 사용하십시오: English로 컴팩트한 형태로 표현할 수 있는 표현은 다른 언어에서 동일한 형태로 표현될 수 없습니다. 인터페이스는 더 긴 로컬화된 문자열을 위해 자리를 남겨야 합니다. (이렇게 하면 Localizer가 전체 다이얼로그를 재배열하지 않아도 됩니다)
로컬화 가능 리로스 뒤에 comments를 두십시오: 이렇게 하면 Localizer가 문자열이 무엇을 의미하는지, 그 문자열의 최대 길이가 무엇인지 쉽게 알 수 있습니다.
다른 의미를 갖는 것에 대해 동일한 문자열을 사용하지 마십시오: 이것은 Localizer에게 혼란을 일으킬 수 있습니다; 게다가 로컬화된 표현이 외국어에서는 다른 문맥에서 다른 뜻이 될 가능성이 높습니다.
약어를 사용하거나 단어를 가지고 놀지 마십시오.
관련 정보: 리소스에 나란히 저장해야 합니다. 만약 그렇지 않으면 관계성을 표시하기 위해 comments를 두십시오.
메뉴 및 버튼 변경: 리소스로부터 문자열이 메뉴나 버튼으로 들어간다는 것을 표시하는 comments를 두십시오.

컬러, 아이콘:

색상 및 아이콘 사용에 주의하십시오. -- 이것은 인터페이스 디자이너의 일입니다. 일반적으로 당신은 텍스트 항목에 대한 대체물로 아이콘을 사용해야 합니다. (아이콘은 로컬화를 덜 요구함)
꼭 필요한 경우가 아니면 비트맵, 사진, 또는 아이콘에 텍스트를 넣지 마십시오.

글꼴:

고정 글꼴 이름을 소스 코드에 넣지 마십시오: 글꼴 이름을 리소스로 넣어두면 로컬화할 수 있습니다. 또한 더 큰 글꼴을 위해 다이얼로그 안에 여유로운 공간을 두십시오. (Mac vs Windows, Roman vs Japanese 등) 만약 당신이 글꼴 이름을 저장하면 더 긴 글꼴 이름을 위해 여유로운 공간을 두십시오. ('Arial'에 대한 체크섬을 만들지 마십시오)

구획 문자(Delimiters), 측정 단위:

고정 소수점 및 천-자리 구문자 또는 측정 단위를 소스 코드 안에 넣지 마십시오: 이것들은 모두 언어/글꼴/플랫폼에 의존적입니다. 2-바이트 버전 또한 다룰 수 있도록 준비하십시오. (예. degree 심볼)

다이얼로그에 관하여:

오프셋을 사용하지 마십시오: DG는 Offset을 이용해 수많은 다이얼로그 항목들을 동시에 이동시킬 수 있는 기능을 제공합니다. 이것은 설계 단계에서만 사용하십시오; 릴리즈 버전에서는 제거하십시오.
DY: 다이얼로그에서 각 항목 타입에 대해 동일한 높이를 사용하십시오. 예를 들면, LargePlain 정적/Edit 텍스트, 라디오 버튼은 16이어야 합니다. LargePlain 체크박스는 18픽셀 높이여야 합니다. 이 값들을 모든 다이얼로그에 적용하십시오! 권장하는 값은 다이얼로그 관리자의 문서 안에서 찾을 수 있습니다.
겹치는/숨겨진 항목들: 20-30개의 다이얼로그 항목들을 위치 (0, 0)에 두지 마십시오. 그렇게 되면 소스 코드로부터 그것들을 분산시키게 됩니다. 최소한 그룹별로 탭 페이지들에 그것들을 두십시오. 그러면 Localizer가 다이얼로그에서 어떤 항목들이 같이 나타날지 알 수 있습니다.
텍스트 항목들을 위한 충분한 공간을 두십시오: 컴팩트한 English 용어들을 더 긴 독일어나 일본어 용어로 바꾸는 것은 Localizer에게 매우 어려운 일입니다. 이것은 다이얼로그를 더 '가볍게' 만들뿐만 아니라 Localizer가 불필요한 약어를 만들거나 다이얼로그를 완전히 재구성하게 만들기 때문에 디자이너의 본래 의도를 해치게 됩니다.
각 리소스에 이름과 ID 번호를 부여하십시오: 적어도 리소스 사용에 대한 정보를 comments에 두십시오. (리소스 타입 이후에!) 또한 다이얼로그의 프로그래머를 적어도 이니셜로 표시하십시오. (이렇게 하면 Localizer가 누구와 연락할지 알 수 있습니다)

리소스 작성하기에 대한 일반 규칙:

특정 포맷을 고수하십시오: API 예제에서 볼 수 있듯이. 예를 들면 다이얼로그의 경우: 항목 인덱스를 comments 사이 라인의 시작 부분에 두십시오. (예. "/* 23 */") 그리고 나머지 comments는 라인 끝에 두십시오. -- Graphisoft가 내부적으로 사용하는 로컬화 도구 일부는 이것에 의존합니다.
가능하다면 텍스트 항목의 길이를 제한하지 마십시오: 그러나 꼭 제한해야 한다면 comment로 이것을 표시하십시오. (예. "/* max 32 chars */") 그래서 Localizer가 이것도 배울 수 있게 해주어야 합니다. 셀 수 없는 한계(예. 1024)를 지정하는 것은 완전히 불필요합니다...
봄 청소: 가끔씩 1번씩만 하십시오. 사용하지 않는 다이얼로그, 문자열 리소스는 반드시 지워야 합니다.

Make 환경:

로컬화(Localization)에 공급되는 make 환경은 양 플랫폼에서 모두 작동해야 합니다. 환경에 의해 제공되는 가능성들을 고려하십시오: (언어 지정 내용을 정의하는 EmuLocal.h와 같은) 공용 파일을 사용하십시오. 소스 코드에 애드온의 언어를 고정시키지 마십시오. (예. 일본어와 영어 버전 간에 소스 코드에서 구별하기 위한 #define JAPANESE를 사용하지 마십시오) Localizer들은 소스 코드 만지는 것을 싫어합니다; 그들은 리소스로 작업합니다.
리소스 파일에서 INT_APP을 정의하지 마십시오. 코드 페이지는 language_version_APP 정의 값에 따라 달라질 수 있습니다. (만약 당신의 한국어 애드온에서 인터네셔널 코드 페이지를 정말로 보고 싶지 않다면 :))
만약 가능하다면 다른 디렉토리로부터 헤더 파일들을 grc 파일에 포함시키지 마십시오. (예. #include "..\Src\Mydefs.h") GRC 컴파일러는 1개의 추가 접근 경로만 지원하며 보통 RFIX\Images 폴더를 위해 예약되어 있습니다. make 환경에서 RESCONVFLAGS 변수를 변경하여 이것을 조정할 수 있습니다.

그 외:

기술 변화를 심각하게 고려하십시오: 새로운 기술을 도입하는 것은 로컬화에도 심각한 영향을 미칠 수 있습니다.
사용 중인 기술이 여러 시스템 버전/플랫폼에서 사용 가능하고 로컬화되어 있는지 확인하십시오.