번역 검토, 언어별로 하나씩
translation-check는 모든 키에 올바른 플레이스홀더가 존재함을 증명합니다. 이 스킬은 실제 단어를 읽습니다.
1. 범위 및 맥락
- 검토할 텍스트: 변경 사항이 추가하거나 편집한 키(기준 브랜치와 로케일 파일을 diff) 또는 요청 시 전체 네임스페이스나 파일. 참조 값과 각 언어의 값을 나란히 가져옵니다.
- 텍스트가 나타나는 위치: 코드에서 각 키의 사용처를 찾습니다(
git grep "<key>"). 버튼인가요, 제목인가요, 이메일인가요, 오류인가요, 툴팁인가요? 얼마나 많은 공간이 있나요? 다른 키와 함께 문장에 나타나나요, 아니면{{count}}, 이름, 날짜를 받나요? - 프로젝트 규칙:
AGENTS.md와.claude/translations.json에 있는 금칙어, 번역하지 않고 유지할 제품 및 요금제 이름, 격식, 그리고 독자가 누구인지(고객, 딜러, 관리자). - 기존 용어집: 같은 용어가 해당 언어 파일에서 이미 어떻게 번역되었는지. 해당 로케일 폴더에서
git grep으로 용어를 검색하세요. 일관성이 개인의 선호보다 우선합니다.
2. 각 언어를 개별적으로 검토
모든 언어에 대해 각 텍스트를 다음 항목별로 확인합니다:
- 의미: 참조와 동일한 내용을 말합니다. 추가되거나 누락된 내용이 없고, 오해의 소지가 있는 표현(false friends)이 없어야 합니다. 플레이스홀더는 올바른 문법적 역할로 사용됩니다.
- 자연스러움: 해당 언어의 자체 제품 카피처럼 읽혀야 하며, 단어 그대로의 영어 번역이 아니어야 합니다. 어순, 관사 및 대문자 사용(독일어 명사는 대문자로; 다른 언어에서는 영어 제목 대문자 사용 금지)을 주의하세요.
- 용어: 같은 대상을 모든 곳에서 동일한 이름으로 부릅니다(report, order, credit, VIN, plan names) 그리고 1단계의 용어집과 일치해야 합니다.
- 격식: 제품 전반에 걸쳐 하나의 호칭등급을 사용합니다. 예: 독일어 Sie 또는 du, 우크라이나어 ви, 프랑스어 vous, 체코어 Vy, 폴란드어 Pan/Pani 또는 중립형. 혼용하지 마세요.
- 변수가 있는 문법: 실제 숫자에 맞는 복수형(uk, pl, cs에서 1, 2, 5, 21, 22, 25); 전치사 뒤의 격; 플레이스홀더가 명사인 경우 성별 일치.
- 길이: 버튼, 탭, 배지는 참조와 거의 비슷한 길이로 유지됩니다. 좁은 공간에서 약 40% 이상 길어지면 표시하세요.
- 현지 관습: 단위(uk/bg에서 км, кВт, к.с.), 소수점 쉼표, 날짜 순서, 통화 위치, 인용 부호(de에서 „…“, fr에서 « … », uk에서 «…»).
- 프로젝트 규칙: 금칙어, 브랜드 철자, 요금제 이름.
3. 보고
언어별로 그룹화하고 각 발견 사항에 키, 현재 텍스트, 문제점 및 제안 텍스트를 제시합니다:
uk — 2건 발견
- reportPage:upgrade.cta — "Оновити до Complete звіту" — 어순이 영어처럼 보임; Complete는 요금제 이름 → "Перейти на звіт Complete"
- ...
de — 발견 사항 없음
- 자신 있게 판단할 수 있는 언어를 명시하세요. 판단할 수 없는 언어에 대해서는 추측하지 말고 그렇게 말한 후 원어민 검토를 제안하세요.
- 수정 요청을 받은 경우: 로케일 파일에 제안 사항을 적용하고,
i18n:translation-check를 다시 실행한 후, 변경 사항과 함께 커밋하세요. - PR 검토에서 의미가 잘못되었거나 금칙어가 나타난 경우가 아니라면 이를 Nits(사소한 의견)으로 게시하고, 그렇지 않으면 Important(중요)로 게시하세요.