Localizable.stringsチェッカー
.strings ファイルを2つ以上置くと、何が足りず、何が重複し、実は一度も訳されていないものはどれか、そしてどの行が解析できないかが分かります。アップロードはしません。たいていは本番のファイルであり、このページの中に留まります。
重複した値のルール
同じ英語の値を持つキーが2つある、というのは何度でも戻ってくるバグです。翻訳者は同じ文を2回見て2回訳し、結果が2通りに分かれます。もっと悪いのは、その2つの文脈で別の語を要する言語に、両方とも同じ語が当てられてしまう場合で、母語話者から苦情が来るまで誰も気づきません。この検査は大文字小文字と末尾の句読点を無視します。"Done" と "Done." は帽子をかぶっただけの同じ問題だからです。
同一であることと未翻訳であることは別
基準ファイルと同じ値は、たいてい誰もそこまで手が回っていないという意味です。正しい場合もあります。ブランド名、単位、どの言語でもそのままにする略語などです。ツールは印を付けるだけで判断はあなたに委ねます。そうしないと、本当の抜けを見落とすか、OK が出てくるたびに小言を言うかのどちらかになるからです。
壊れた行は握りつぶさず報告する
.strings の文法は小さいのに、際どい場面は現実にあります。ブロックコメント、値の中でエスケープされた引用符、抜けたセミコロン、表計算ソフトから貼り付けられた曲がった引用符。読めなかったものを黙って飛ばすパーサーは、キーがひとつ静かに消えていても「このファイルは問題ありません」と言ってきます。ですから解析できなかった行はすべて行番号付きで一覧にし、見に行けるようにしています。
UTF-16も
Xcodeは長年 .strings を UTF-16 で書いてきており、いまも多くのリポジトリにそうしたファイルが残っています。そこで、まずバイト順マークを調べてそれに応じてデコードします。UTF-16のファイルがヌルバイトの壁と百件の解析エラーになって届かないようにするためです。
よくある質問
.xcstrings には対応していますか?
まだです。ストリングカタログは形の違うJSONで、中途半端に動く変換層ではなく、専用の扱いを与えるべきものです。
どのファイルを基準にすべき?
権威のあるもの、たいていは開発言語です。すべてがそれと比較されるので、基準にはなくてほかにあるキーは「不足」ではなく「余分」として報告されます。
何を問題として数えている?
キーの不足、値の重複、基準と同一の値、そして解析できない行です。カウントはこれらを全ファイル分について合計します。
ファイルはアップロードされますか?
いいえ。ブラウザのファイルリーダーで読み込み、比較もここで行います。これらは実際の製品ファイルなので、この点はほかのツール以上に重要です。
これに何度もぶつかってきたGO AIチームが作りました。 無料ツール一覧