우리는 현재 우리 제품 세트를 세계의 다른 지역으로 운송하고 있습니다. 우리는 사용자 인터페이스의 모든 문자열과 날짜 형식 등이 대상 국가의 언어와 문화를 반영하도록 보장 할 것입니다.로깅은 국제화의 영향을 받아야합니까?
로그 파일과 오류보고도 이와 같이 변경해야합니까? 고객이 로그 파일에 잠길 수 있거나 해당 국가의 지원 팀이있을 수 있다는 점을 감안할 때 문제의 문제 해결 및보고는 관련 보고서가 해당 언어로 된 경우보다 쉬울 것입니다. 그러나 개발자가 모두 영어로 말하면서, 지원 팀이 문제를 해결할 수없는 경우 보고서와 로그 파일이 끝나고 번역이 필요할 수 있습니다. 사용자에게 제공
감사
모든 메시지는 현지 언어에 있어야합니다.
로그 파일이 응용 프로그램의 필수적인 부분이 아닌 한, 나는 그들을 영어로 남겨두고 싶습니다. 현지 지원 팀은 합리적인 영어 실력을 갖추고 있어야합니다.
메시지를 번역해야하는 경우 오류 번호와 현지 언어로 된 메시지를 기록하지 마십시오. 그런 다음 오류 번호를 찾아 코드 기반에서 영어 텍스트를 가져올 수 있습니다. 추가 번역이 필요하지 않습니다.
사용자가 볼 수있는 오류 메시지는 번역해야합니다. 이해하기 어려운 언어의 오류 메시지는 매우 짜증나게합니다.
지원 팀이 일반적으로 영어로 말하면 번역되지 않은 문제 해결에 사용되는 로그 파일을 남겨 두었습니다. 모든 번역은 돈/시간을 소비하므로 사용자에게는 보이지 않는 메시지에 대해서는 지출하지 않습니다.
로그 메시지의 일부는 오류 메시지에 errno을 포함하고, strerrno의 출력과 함께 현지화 독립적 인 로그 메시지 식별자 일 수 있습니다.
예를 들어 vim에 :Q<enter>을 입력하면 E492: Not an editor command: Q이됩니다.
E492은 쉽게 검색 할 수 있으며 (:help E492) 번역사는 의미있는 현지 번역을 쉽게 제공 할 수 있습니다.
로그 파일은 개발자/디버거 용입니다. 영어로 개발 언어를 이해할 수 있다면 확실히 디버깅 로그를 이해해야합니다. 통나무를 국제화하는 것은 제 의견으로는 지나치게 길 것입니다.
두 번째 및 세 번째 줄 지원 담당자가 영어를 이해하는 한 로그 메시지를 번역하지 않아도됩니다. 그렇지 않으면 인시던트와 문제 관리에 혼란이 생길 것입니다.
그러나 번역 된 언어 (영어 버전은 물론)로 최종 사용자에게 표시되는 모든 로깅은 첫 번째 줄 지원이 두 번째 줄 지원에 정보를 제공하는 것을 돕기 위해 좋습니다.
실화 : 서버가 다른 지역 출신의 동시 사용자를 지원하면 사용자가 본 오류 텍스트를 보여주는 로그 파일을 읽는 것이 쉽지 않은 것으로 나타났습니다. 아무리 다국어를 사용하지 않는 한. –