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チームが作りました。 無料ツール一覧