Localizable.strings 검사기
.strings 파일을 두 개 이상 놓으면 무엇이 빠졌는지, 무엇이 겹치는지, 사실 한 번도 번역되지 않은 것은 무엇인지, 어떤 줄이 해석되지 않는지 보입니다. 업로드하지 않습니다. 보통 실제 제품 파일이고, 이 페이지 안에 머무릅니다.
중복 값 규칙
영어 값이 같은 키가 둘 있다는 건 자꾸만 돌아오는 버그입니다. 번역하는 사람은 같은 문장을 두 번 보고 두 번 번역해 서로 다른 결과를 내놓습니다. 더 나쁜 경우는 두 맥락에 다른 낱말이 필요한 언어가 양쪽에 같은 낱말을 받는 것이고, 원어민이 불평하기 전까지 아무도 알아채지 못합니다. 이 검사는 대소문자와 끝의 문장부호를 무시합니다. "Done"과 "Done."은 모자만 쓴 같은 문제니까요.
동일하다는 것과 번역이 안 됐다는 것은 다르다
기준 파일과 같은 값은 대개 아무도 손을 대지 못했다는 뜻입니다. 맞는 경우도 있습니다. 브랜드 이름, 단위, 어떤 언어에서도 그대로 두는 약어 같은 것들이죠. 도구는 표시만 하고 판단은 당신에게 맡깁니다. 그러지 않으면 진짜 구멍을 놓치거나 OK가 나올 때마다 잔소리를 하게 되니까요.
잘못된 줄은 삼키지 않고 보고합니다
.strings 문법은 작지만 가장자리 사례는 실재합니다. 블록 주석, 값 안에 이스케이프된 따옴표, 빠진 세미콜론, 스프레드시트에서 붙여 넣은 둥근 따옴표 같은 것들이죠. 읽지 못한 것을 조용히 건너뛰는 파서는 키 하나가 소리 없이 사라진 상태에서도 파일이 멀쩡하다고 말합니다. 그래서 해석되지 않는 줄은 모두 줄 번호와 함께 나열해, 직접 가서 볼 수 있게 했습니다.
UTF-16도
Xcode는 오랫동안 .strings 파일을 UTF-16으로 써 왔고, 많은 저장소에 여전히 그런 파일이 남아 있습니다. 그래서 파일을 먼저 바이트 순서 표시로 확인해 그에 맞게 디코딩합니다. UTF-16 파일이 널 바이트 벽과 수백 개의 해석 오류로 도착하지 않도록요.
자주 묻는 질문
.xcstrings도 처리하나요?
아직입니다. 스트링 카탈로그는 형태가 다른 JSON이고, 어설프게 작동하는 변환 계층 대신 제 나름의 처리를 받아야 마땅합니다.
어느 파일을 기준으로 삼아야 하나요?
기준이 되는 것 — 보통은 개발 언어입니다. 모든 것이 그것과 비교되므로, 기준 파일에 없고 다른 곳에만 있는 키는 빠진 것이 아니라 남는 것으로 보고됩니다.
무엇을 문제로 세나요?
빠진 키, 중복된 값, 기준과 동일한 값, 해석되지 않는 줄입니다. 집계는 모든 파일에 걸쳐 이것들을 더합니다.
제 파일이 업로드되나요?
아닙니다. 브라우저의 파일 리더로 읽고 비교도 여기서 합니다. 이 도구에서는 그 점이 평소보다 더 중요합니다. 실제 제품 파일이니까요.
이 문제에 거듭 부딪혀 온 GO AI 팀이 만들었습니다. 무료 도구 전체