技術用語、大文字・小文字の使い分け、翻訳ラベルを校正する方法

なぜ1つの大文字ルールだけで全用語を統一できないのか？

スタイルガイドは有用なデフォルトの基準を提供しますが、製品や専門領域によっては異なる扱いが必要な固有の名称が存在する場合があります。Googleの開発者向けガイドでは、見出し、リスト、表において標準的なアメリカ英語の大文字表記およびセンテンスケースを推奨しつつ、公式の製品名やコード形式を保持することを求めています。Microsoftのガイドもセンテンススタイルの大文字表記を支持していますが、自社のブランド、製品、サービスなどの固有名詞に対しては明示的に大文字表記を規定しています。両者に共通するデフォルトの規則はあくまで出発点であり、特定の技術用語が一般名詞であることを証明するものではありません。[Googleの大文字表記ガイダンス](https://developers.google.com/style/capitalization) [Microsoftの大文字表記ガイダンス](https://learn.microsoft.com/en-us/style-guide/capitalization)

用語リスト（word list）は、一般的な大文字表記の解説ページとは異なる問いに答えてくれます。それは、特定のエディトリアルガイドが個々の用語に対してどの表記や用法を推奨しているか、という点です。たとえばGoogleの用語リストでは、リストでカバーされていない語句について推奨する辞書を案内しており、スタイルの指針と、信頼できる公式ドキュメントで技術的な定義を確認することとを区別しています。この分離は有益です。エディトリアルな一貫性と技術的な正確性には、それぞれの課題に適した情報源からの根拠が必要だからです。[Googleの用語リスト](https://developers.google.com/style/word-list)

校正用用語テーブルには何を含めるべきか？

表記揺れが起きたり誤訳されたりするリスクがある用語ごとに、行を作成します。以下の架空の例は、フィールドと決定ロジックを示したものです。「Sync token」およびその訳語は説明のための例であり、実在する製品や承認された用語に関するものではありません。

このテーブルの役割は、決定事項とその適用範囲を保持することです。許容された小文字の形式が勝手に第2の製品名になってしまってはならず、識別子が地の文に合わせて「修正」されてもいけません。また、未解決の翻訳は未解決であることが一目でわかるようにしておく必要があります。公式の情報源とローカルの用語集が矛盾している場合は、説明のないままリストに統合するのではなく、その矛盾と最終決定の情報源を記録してください。

表示用の表記や大文字・小文字はどのように決定するか？

まず、その用語が何を指しているかを特定します。一般的な概念なのか、ブランド名や製品名なのか、UIラベルなのか、あるいはリテラルな識別子なのかを把握します。公式な形式については、該当する製品ドキュメントや用語集を確認してください。その後、対象となる出版物のスタイルルールを一般的な文章、見出し、ラベルに適用し、名称や識別子として記録されている例外事項はそのまま保持します。Googleは不要な大文字表記を避けるよう助言し、意味を区別するためだけに大文字・小文字の違いを利用することに注意を促しています。Microsoftも同様に、センテンススタイルのアプローチにおいて文頭と固有名詞を除き小文字を使用するよう規定しています。[Googleの大文字表記ガイダンス](https://developers.google.com/style/capitalization) [Microsoftの大文字表記ガイダンス](https://learn.microsoft.com/en-us/style-guide/capitalization)

次に、必要に応じて対象組織の用語リストや辞書と照合します。他の編集者がその選択の経緯を追跡できるよう、情報源とそのバージョンや確認日を記録しておきます。見た目が整っているように思える大文字表記、検索結果、あるいは英語の用語に似ている翻訳だからといって、それだけで公式なステータスであると推測してはなりません。情報源の間で矛盾がある場合や形式が明確に定められていない場合は、推測を確定事項として扱うのではなく、決定が必要な項目としてその行にフラグを立てます。

翻訳とUIラベルはどのように確認すべきか？

翻訳は機械的な大文字・小文字の変換ではなく、意味と文脈の決定事項として扱います。ラベルは、インターフェースの制約、確立されたローカライズ版の製品用語、あるいは対象言語における文法形式の違いによる影響を受けることがあります。候補となる訳語を、承認済みのローカライズ資材や、読者が実際に目にする文脈と照らし合わせて確認してください。信頼できるローカライズ版の形式がない場合は、翻訳を未解決としてマークし、適切な用語決定を要請してください。勝手に公式とされる訳語をでっち上げてはなりません。

用語の決定後、実際の文脈に配置されたラベルを校正します。大文字・小文字の使い分けが対象言語の規則、および適用される製品や社内のスタイルガイドに従っているかを確認します。将来の編集で一時的な暫定翻訳が承認済みのものと誤認されないよう、用語レコードには情報源やステータスとともに元のラベルを表示させておきます。そのラベルが説明文の中でも言及されている場合は、文中の表記が画面上の文言と完全に一致していることを検証します。

コードやAPI識別子はどのように保護するか？

大文字・小文字を変更する前に、リテラル文字列を編集用テキストから分離します。識別子を、関連するAPIリファレンス、スキーマ、コード、またはインターフェースと一文字ずつ照合します。情報源で定義されているアンダースコア、大文字・小文字、スペース、句読点はそのまま保持してください。スタイルの統一は周囲の解説文で行うべきものであり、リテラル値そのものを変更してはなりません。Googleのガイドでは、公式の名称や、それらを使用するコードに言及する場合において、すべて大文字の形式やキャメルケースの維持を明確に認めています。[Googleの大文字表記ガイダンス](https://developers.google.com/style/capitalization)

実践的なレビューでは、保護対象の識別子を用語テーブルに記録した上で、その基準と照らし合わせて出現箇所をすべて確認します。地の文でコード形式の用語が一般名詞として使われている場合は、読者にわかりやすい表現で説明しつつ、リテラル識別子自体はコード書式としてそのまま残すかどうかを判断します。公式な定義自体が不明確な場合は、その曖昧さを記録しておきます。スタイルガイドによってAPIの動作や正式なフィールド名を定めることはできないからです。

信頼性の高い校正手順とは？

この手順は校正を支援するためのものであり、自動翻訳や万能の大文字・小文字規則ではありません。その真価は、どの形式が選ばれ、どこに由来し、どこに適用され、何がまだ未決定であるかといった、個々のエディトリアルな決定を検証可能にする点にあります。短い文書であれば簡潔なテーブルで十分ですし、大規模な用語セットの場合は、チームで確立された用語集ワークフロー内で同じフィールドを維持して運用します。

このテーマをさらに見る