戻る

gt-next@6.13.0

Ernest McCarter avatarErnest McCarter
gt-nextgt-i18nv6.13.0msgstring-registrationarraysi18n

概要

msg() は配列を引数として受け取れるようになりました。

以前は、関連する文字列のリストを登録するには、それぞれを個別にラップする必要がありました。

const confirmations = [
  msg("Yes"),
  msg("Yup"),
  msg("Right"),
  msg("Absolutely"),
  msg("Exactly"),
];

ここには 2 つの問題があります。1 つ目は、各行ごとに msg() の呼び出しが必要になることです。2 つ目は、関連する文字列がしばしば同じメタデータ($context$id など)を必要とし、そのメタデータはビルド時に CLI(コマンドラインインターフェイス)が解決するため、インラインで指定しなければならないことです。「Right」や「Exactly」のように、それ単体では意味があいまいな文字列では、各エントリごとに $context を繰り返し書くことになってしまいます。

const confirmations = [
  msg("Yes"),
  msg("Yup"),
  msg("Right", { $context: "As in a confirmation" }),
  msg("Absolutely", { $context: "As in a confirmation" }),
  msg("Exactly", { $context: "As in a confirmation" }),
];

代わりに、次のようにできます。

const confirmations = msg([
  "Yes",
  "Yup",
  "Right",
  "Absolutely",
  "Exactly",
], { $context: "Confirmation responses" });

設計

ID の生成

$id が指定されている場合、配列内の各アイテムには、${id}.0${id}.1 などのインデックスに基づく ID が割り当てられます。

const greetings = msg([
  "Hi",
  "Hello",
  "Howdy",
], { $id: "greeting" });
// "Hi"    → id: "greeting.0"
// "Hello" → id: "greeting.1"
// "Howdy" → id: "greeting.2"

なぜオブジェクトではないのか?

これをオブジェクトにも拡張したい気持ちはありましたが、最終的には見送ることにしました。オブジェクトは、多くの場合、翻訳すべきフィールドと翻訳すべきでないフィールドが混在しているためです。

{
  id: 'planning.v1',           // 翻訳しない
  message: 'Not yet enabled',  // 翻訳する
}

どのフィールドを登録対象にすべきかを、これ以上構文を増やさずに表現するスマートな方法はありません。配列にはこの問題がありません。すべての要素が翻訳対象の文字列だからです。

今後の予定

gt() に対する配列サポートは、自然な次のステップです。gt()msg() はどちらも登録用の関数なので、両者で機能を揃えるのが理にかなっています。これは m() にも当てはまります。msg()m() は一緒に使われることが多いため、m() が配列を受け付けるようになれば、msg() の出力を m() に渡しても問題が起きないことが保証されます。