한 단어가 문맥에 따라 접수, 검토, 승인, 완료를 뜻할 수 있습니다. 번역자가 화면 문구만 보면 서로 다른 단계를 같은 표현으로 옮길 수 있고, 이용자는 요청이 받아들여진 것인지 최종 허가된 것인지 혼동합니다. 번역 전에 상태 체계를 설명해야 하는 이유입니다.
먼저 원문에 쓰인 상태를 실제 업무 순서대로 배열합니다. 각 상태가 시작되는 조건, 담당자의 행동, 이용자가 할 수 있는 다음 일을 적습니다. 표현이 같은데 의미가 다른 곳이 있다면 원문부터 구분하는 것이 좋습니다.
번역자에게 단어 목록만 전달하지 말고 화면 맥락과 앞뒤 상태를 함께 제공합니다. ‘submitted’가 단순 제출인지 정상 접수까지 포함하는지, ‘approved’가 최종 결정인지 다음 검토로 이동한 것인지 설명합니다. 번역어는 이 정의에 따라 일관되게 선택합니다.
짧은 버튼과 긴 안내문의 용어도 연결해야 합니다. 버튼에는 공간 때문에 짧은 말을 쓰더라도 도움말에서 의미가 달라져서는 안 됩니다. 알림 메시지, 이메일, 관리자 화면에서 같은 상태를 서로 다른 말로 번역하지 않는지 대조합니다.
가상의 신청 흐름으로 역검증하면 오류를 찾기 쉽습니다. 번역문만 본 검수자가 현재 단계와 다음 행동을 말할 수 있는지 확인합니다. 접수 상태를 승인으로 이해한다면 단어를 고치거나 짧은 설명을 덧붙입니다.
최종 결과물은 단순 대역표가 아니라 상태 사전입니다. 원어, 번역어, 정의, 진입 조건, 다음 상태, 사용 화면을 묶어 관리합니다. 새 문구가 생길 때 이 사전을 먼저 확인하면 업무 단계의 차이가 언어 변환 과정에서 사라지는 일을 줄일 수 있습니다.
한 번에 모든 항목을 바꾸기보다 독자의 판단을 가장 크게 막는 한 지점부터 고칩니다. 수정 전에는 번역문에서 비슷해 보이는 업무 상태를 어떻게 정확히 나눌까의 답을 찾지 못한 이유를 기록하고 수정 후 같은 경로를 다시 시험합니다. 이 전후 기록은 원어 하나의 직역보다 업무 단계와 다음 행동을 설명해 상태 용어가 합쳐지는 오류를 막습가 단순한 문장 교체가 아니라 실제 정보 이용을 개선했는지 보여줍니다.