はじめに

国際化で私がよく目にする代表的なミスの1つが、単純な三項演算子を 複数の翻訳呼び出しに分けてしまうことです。 多くの場合、次のようになります。

const gt = useGT()

return (
  <>
    <span>
      <T> Dark Mode: </T>
    </span>
    <Button>{enabled ? gt('On') : gt('Off')}</Button>
  </>
)

ほとんどの場合、これは意図どおりに機能します。i18n を実装する前のコードは、おそらく { enabled ? 'On' : 'Off' } のようなものだったでしょう。 i18n のために gt() 関数を追加するのも、既存のコード構造を自然に拡張しただけだったはずです。

これを見るたびに、私はいつも少しゾッとします。これは、ライブラリが本来想定している使い方とはまったく異なります。 これが間違いである理由は 2 つあり、特に機械翻訳を使う場合は重要です。(1) コンテキスト と (2) 柔軟性です。

コンテキスト

意味は単語そのものだけでなく、それがどのように表示されるかにも宿ります。 たとえば、戻る矢印の上にある "back" は、カイロプラクターの履歴書に書かれた "back" とはおそらくまったく違う意味です。 さらに、より広いコンテキストがなければ、翻訳者 (人間であっても) でもその単語を正しく訳すのは難しい場合があります。 有名な話として、WhatsApp の i18n 部門が画像編集ツールの "crop" を、ドイツ語で農業の "crop" の意味に訳してしまったことがあります。

このコンテキストの問題を避けるために、<T> と <Branch> コンポーネントを使って、コンテンツの表示方法に関する情報を渡せます。 この例では、これによって「翻訳者」は "on" と "off" の意味をより広い文脈で把握できるようになります。

<T>
  <span>Dark Mode:</span>
  <Button>
    <Branch branch={enabled.toString()} true="On" false="Off" />
  </Button>
</T>

柔軟性

コンテキスト に加えて、LLM 翻訳を活用するもう 1 つの優れた方法は、コードを理解できる点です。 言語によってコンポーネントの順序が変わる場合の例を見てみましょう:

<T>
  I eat lunch at <Branch branch={atHome.toString()} true="home" false="work" />.
</T>

つまり、あり得る文は 2 つあります。

• "私は家で昼食を食べます"
• "私は職場で昼食を食べます"

中国語 (標準語) では次のようになります。

• "我在家吃午餐"
• "我在公司吃午餐"

<T> コンポーネントは、この場合には語順を変える必要があることを認識し、 それに合わせて子要素を並べ替えます。これは、文字列の翻訳に三項演算子を使う場合には 簡単には実現できないことです。

<T>
  我在
  <Branch branch={atHome.toString()} true="家" false="公司" />
  吃午餐。
</T>

結論

この記事から一つでも持ち帰ってほしい点があるとすれば、コードでは常にコンテキストと柔軟性を活かす方法を意識すべきだということです。 その最も簡単な方法の一つが、<Branch /> コンポーネントを使うことです。

詳しくは、<Branch /> コンポーネントのドキュメントを参照してください。