推奨単語リスト

ドキュメントの一貫性を保つために、テクニカルライティングチームは以下の単語の選択を推奨します。加えて

このページにない指針については、これらのスタイルガイドに従うものとします：

&

ラテン語の略語は使わないでください。&を使用する UI 要素を文書化する場合を除き、代わりにandを使用してください。

@mention

@mentionを避けるようにしてください。代わりに mention と**言い **、mentions トピックへのリンクを考えてください。バックティックは使わないでください。

2FA、二要素認証

two-factor authentication（二要素認証）は、 最初の使用とトピックのタイトルでは文 字 大文字で、それ以降は 2FA と綴ります。文の最初の単語の場合は、factor またはauthentication を大文字にしないでください。例

  • 二要素認証 (2FA) はアカウントのセキュリティに役立ちます。初回ログイン時に2FAを設定してください。

上記

ドキュメントのページで例や表を参照するときは、aboveを使わないようにしてください。必要であれば、代わりにpreviousを使用してください。例えば

  • 前の例では、犬はノミを持っていました。

製品のバージョンに言及する場合は、上記を使用しないでください。使用方法 代わりにを使用してください。

使用方法。

  • GitLab 14.4以降では…

の代わりに

  • GitLab 14.4以上で…
  • GitLab 14.4 以降では…
  • GitLab 14.4以降では…

アクセスレベル

アクセスレベルはロールや 権限とは異なります。ユーザを作成するときに、アクセス・レベルを選択します：一般」、「監査役」、または「管理者」です。

UIを参照するときは、これらの単語を大文字にします。それ以外は小文字を使用してください。

アクティブボイス

受動態ではなく能動態を使いましょう。

使用方法。

  • 投稿者がドキュメントを作成します。

の代わりに

  • ドキュメントは貢献者によって書かれています。
note
by zombies “というフレーズを付け加えることができれば、その構文は受動態になります。例えば、The button is selected by zombies は受動態です。Zombies select the button は能動態です。

管理者エリア

Admin Areaにはタイトルケースを使います。UIのこのエリアはページの上部とメニューにAdmin Areaと表示されます。

管理者

ユーザーのアクセスレベルについて話すときは、adminの代わりにadministratorアクセスを使ってください。

admin access level

管理者はロールでも 権限でもありません。

使用方法。

  • この操作を行うには、管理者である必要があります。
  • この操作を行うには、管理者権限が必要です。

の代わりに

  • この操作を行うには、管理者ロールが必要です。

GitLabインスタンス全体で、より高速で効率的な検索を参照するには、高度な検索には小文字を使います。

エージェント

Kubernetes用のGitLabエージェントを指す場合は小文字を使います。例えば

  • クラスターをGitLabに接続するには、Kubernetes用のGitLabエージェントを使用します。
  • エージェントをクラスターにインストールします。
  • リストからエージェントを選択します。

GitLab Agentや GitLab Agent for Kubernetesではタイトルケースを使用しないでください。

エージェントアクセストークン

Kubernetes用のエージェントを作成する際に生成されるトークンです。エージェントアクセストークンを使用します：

  • 登録トークン
  • シークレットトークン
  • 認証トークン

AI、人工知能

AIを使ってください。人工知能と綴らないでください。

エアギャップ

インターネットへのアクセスを防止または制限する物理的な障壁またはセキュリティポリシーがあるインストールを説明するには、オフライン環境を使用します。エアギャップ、エアギャップ、エアギャップは使用しないでください。例えば

  • オフライン環境のファイアウォールポリシーは、コンピュータがインターネットにアクセスすることを防ぎます。

許可、有効

セキュリティ関連の機能についての話でない限り、allowと enableは避けるようにしてください。

使用方法。

  • リポジトリにファイルを追加できます。

の代わりに

  • この機能により、リポジトリにファイルを追加することができます。
  • この機能により、ユーザーはリポジトリにファイルを追加できます。

この表現は、機能を実装した人ではなく、ユーザーの視点に立った、よりアクティブな表現です。詳細については、マイクロソフトのスタイルガイドを参照してください。

分析

貢献分析やイシュー分析のようなアナリティクスとそのバリエーションには小文字を使用してください。ただし、UIで大文字と小文字が異なる場合は、ドキュメントをUIに合わせてください。

使用例：

  • プロジェクトのマージリクエスト分析を表示できます。これらはマージリクエスト分析ダッシュボードに表示されます。

および/または

and/orの代わりにorを使い、両方の選択肢を表す文に書き換えます。

というように

などは使わないでください。代わりに、より具体的に記述してください。詳しくはマイクロソフトのスタイルガイドを参照してください。

領域

使用 セクションを使います。唯一の例外は管理者エリアです。

として

because の意味でasを使わないでください。

使用方法。

  • どのエンドポイントもIDを返さないため…

の代わりに

  • どのエンドポイントもIDを返さないので…

と同様に

as well asの代わりにandを使います。

アソシエイト

イシューをエピックに追加したり、ユーザーをイシュー、マージリクエスト、エピックに追加したりする場合には、associateを使用しないでください。

代わりにassign を使用してください。例えば

  • イシューをエピックに割り当てます。
  • イシューにユーザーを割り当てます。

認証済みユーザー

サインイン・ユーザーや ログイン・ユーザーのような他のバリエーションではなく、authenticated userを使用してください。

以下

ドキュメント・ページで例や表を参照する場合は、undergroundを避けるようにしてください。必要であれば、代わりにfollowingを使用してください。例えば

  • 次の例では、犬はノミを持っています。

ベータ版

ベータは大文字で表記してください。例えばこの ベータリリースはテストする準備ができています。

また、ベータ版の機能について書くときは、ハンドブックのこのセクションにリンクするとよいでしょう。

ブラックリスト

ブラックリストは使用しないでください。別のオプションとしてdenylistがあります。(Valerule:InclusionCultural.yml)

ボード

ボード、イシューボード、エピックボードには小文字を使用します。

ボックス

UIフィールドを参照するにはテキストボックスを使用します。fieldや boxは使用しないでください。例えば

  • 変数名テキストボックスに、値を入力します。

弾丸

順序付きリストや順序なしリストの個々の項目を箇条書きとして参照しないでください。代わりにlist itemを使ってください。曖昧さをなくしたい場合は

  • 順序付きリストの項目には、順序付きリスト項目。
  • 順序なしリストの項目。

ボタン

buttonと一緒に記述子を使用しないでください。

使用方法。

  • パイプラインの実行を選択します。

の代わりに

  • パイプラインの実行]ボタンを選択します。

できない、できない

can not の代わりにcannotを使います。

短縮形も参照してください。

チャット, GitLab Duoチャット

ChatまたはGitLab Duo Chatには大文字のc 。

チェックボックス

checkboxは1語にしてください。チェックボックスは使用しないでください。

チェックボックスの選択（チェックや 有効化ではない）とクリア（選択解除や 無効化ではない）。例えば

  • 環境の保護チェックボックスを選択します。
  • 環境の保護] チェックボックスをオフにします。

チェックボックスを参照する必要がある場合は、「選択されている」または「クリアされている」と言うことができます。例えば

  • 環境の保護] チェックボックスがオフになっていることを確認します。
  • 環境の保護] チェックボックスが選択されていることを確認します。

(deselect の場合、Valeルール:SubstitutionWarning.yml)

チェックアウト

check outを動詞として使います。Gitコマンドの場合は、checkout。

  • ブランチを内部でチェックアウトするには、git checkout を使います。
  • 編集したいファイルをチェックアウトします。

CI/CD

CI/CDは常に大文字です。初回使用時にスペルアウトする必要はありません。

CI/CD議事録

CI/CD議事録は使用しないでください。この用語は 計算分.

クリック

クリックは使用しないでください。代わりに、ボタン、リンク、メニューアイテム、リストにはselectを使用してください。selectはより多くのデバイスに適用されますが、clickはよりマウスに特化しています。

クラウドネイティブ

Kubernetesクラスターを使ってGitLabをホストするというのは、クラウドネイティブバージョンのGitLabのことです。このバージョンは、GitLabをデプロイするために使われる、より大きく、よりモノリシックなLinuxパッケージとは異なります。

cloud-nativeのGitLabを略して使うこともできます。ハイフンで小文字にします。

コードに関する提案

コードサジェスチョンにはタイトルケースを使用します。

崩壊

UIでセクションの拡張や折りたたみについて話すときは、closeの代わりにcollapseを使います。

コマンドライン

コマンドを紹介するには、From the command lineを使用します。

形容詞として使用する場合はハイフンを入れます。例えば、コマンドラインツール。

計算

RunnerがCI/CDジョブを実行するために使用するリソースにはcomputeを使用します。

関連用語

  • 計算分数:コンピュート使用量の計算方法。例えば、400 compute minutes。
  • コンピュートクォータ:名前空間が毎月使用できる計算分数の上限。
  • コンピュート使用量：ネームスペースが月間割り当てから使用した計算分数。

計算分数

これらの（または類似の）用語の代わりにcompute minutesを使用してください：

  • CI/CD分
  • CI分
  • パイプライン分
  • CIパイプライン分
  • パイプライン分

詳しくはエピック2150をご覧ください。

確認ダイアログ

確認ダイアログは、アクションの確認を求めるダイアログを表します。例えば

  • 確認ダイアログで、「OK」を選択します。

確認ボックスや 確認ダイアログボックスは使用しないでください。参照 ダイアログ.

コンテナレジストリ

GitLabコンテナレジストリにはタイトルケースを使用します。

現在

製品やその機能について話すときには、currentlyを使わないでください。ドキュメントでは、現在の製品について説明しています。(Valerule:CurrentStatus.yml)

データ

dataは単数名詞として使用します。

使用方法。

  • データ収集
  • データはパフォーマンスの向上を示しています。

の代わりに

  • データを収集します。
  • データはパフォーマンスの向上を示しています。

デフォルトブランチ

デフォルトブランチを使用すると、リポジトリ内のプライマリブランチを一般的に参照できます。ユーザーは UI 設定でデフォルトブランチを設定できます。

デフォルトブランチを使用する例では、masterの代わりにmain を使用してください。

削除

オブジェクトを完全に削除する場合はdeleteを使います。deleteは createの反対です。

オブジェクトが存在し続ける場合は を使います。を使います。例えば、エピックからイシューを削除しても、そのイシューはまだ存在します。

依存関係プロキシ

GitLab 依存プロキシにはタイトルケースを使用します。

デプロイボード

デプロイボードには小文字を使用してください。

開発者

開発者のロールについて書く場合：

  • 大文字のDを使用してください。
  • 太字は使用しないでください。
  • もしあなたが開発者なら、開発者ロールを割り当てられた人という意味で使わないでください。代わりに、それを書き出してください。たとえば、あなたが開発者ロールを割り当てられている場合。
  • 開発者ロールが最低限必要とされる状況を表すには：
    • 使用法: 少なくとも開発者ロール
    • 代わりに: 開発者ロール以上

Developer 権限は使わないでください。Developer ロールを割り当てられたユーザーには、関連する一連の権限があります。

ダイアログ

これらの選択肢ではなく、dialogを使用してください：

  • ダイアログボックス
  • モーダル
  • モーダルダイアログ
  • モーダルウィンドウ
  • ポップアップ
  • ポップアップウィンドウ
  • ウィンドウ

参照 確認ダイアログ.詳細については、Microsoftスタイルガイドを参照してください。

ダイアログがアクションの場所である場合、前置詞としてonを使用します。例えば

  • 権限の付与ダイアログで、グループを選択します。

参照 を参照してください。.

無効

disable についてはマイクロソフトのスタイルガイドを参照してください。代わりにinactiveまたはoffを使用してください。(ベールルール:InclusionAbleism.yml)

不許可

disallow の代わりにpreventを使ってください。(Valerule:Substitutions.yml)

Docker-in-Docker、dind

Docker-in-Dockerは、Docker Executorを使用してDockerコンテナを実行することを説明する場合に使用します。

コンテナ名を記述する場合は、dind をバックスティックで使用します:docker:dind。それ以外の場合は、スペルで記述します。

ダウングレード

より明るく正確に言うなら、downgradeは使いません。代わりに、ユーザーが取っているアクションに焦点を当てます。

  • GitLabの以前のバージョンに変更するには ロールバック.
  • より低いGitLabティアに変更するには、サブスクリプションティアの変更を使用します。

UI要素を参照するにはドロップダウンリストを使用します。dropdownの後にlistをつけないでください。drop-down（ハイフン）、dropdown menu、またはその他の亜種は使用しないでください。

使用例：

  • 表示] ドロップダウン リストで [公開] を選択します。

先に

バージョン番号について話すときは、earlierを使います。

使用方法。

  • GitLab 14.1以前で。

の代わりに

  • GitLab 14.1以下では。
  • GitLab 14.1以前の場合。

簡単に

簡単に使ってはいけません。ユーザーがプロセスを簡単に見つけられなければ、信頼を失います。

例

ラテン語の略語は使わないでください。代わりに、for example、such as、for instance、likeを使ってください。(ヴェイルのルール:LatinTerms.yml)

省略記号

UIテキストを文書化する際、UIに省略記号が含まれている場合は、その省略記号を文書に含めないでください。詳しくは、Microsoftスタイルガイドを参照してください。

使用方法。

  • 新規作成

の代わりに

  • 新規作成…

メール

emailにハイフンは使用しないでください。複数形の場合は、emailsまたはemail messages を使用します。(Valerule:SubstitutionSuggestions.yml)

絵文字

絵文字の複数形を指す場合はemojiを使用します。

可能にする

enable については、マイクロソフトのスタイルガイドを参照してください。代わりにactiveまたはonを使用してください。(ベールルール:InclusionAbleism.yml)

入力

ほとんどの場合、typeではなく enterを使います。

  • Enterには、音声入力やキーボード入力など、さまざまな入力方法があります。
  • Enterは、ユーザーがフィールドに値を入力し、カーソルをフィールドの外に移動する（またはEnterを押す）ことを想定しています。Enterには、コンテンツの入力とコンテンツを検証するアクションの両方が含まれます。

使用例：

  • 変数名テキストボックスに、値を入力します。
  • 変数名テキスト ボックスに、my text と入力します。

キーボードのキーを参照するためにEnterを使用する場合は、HTML<kbd> タグを使用します：

  • 結果のリストを表示するには、Enterを押します。

参照 タイプ.

エピック

エピックには小文字を使います。

associateも参照してください。

エピックボード

エピックボードには小文字を使用します。

その他

などを避けるようにしてください。できるだけ具体的に。を使わないでください。 などをなどは使わないでください。

使用方法。

  • マージリクエストやイシューなどのオブジェクトを更新できます。

の代わりに

  • マージリクエストやイシューなどのオブジェクトを更新できます。

拡張

UIでセクションの拡張や折りたたみについて話しているときは、openの代わりにexpandを使ってください。

エクスペリメント

Experiment には大文字を使います。例えばXYZ feature is an Experiment.またはThis Experiment is ready to test.

また、エクスペリメントの機能について書くときは、ハンドブックのこのセクションにリンクするとよいでしょう。

FAQ

私たちはユーザーに素早く情報を見つけてもらいたいと考えており、FAQという言葉で検索することはほとんどありません。FAQの情報は、検索しやすいトピックタイトルの下に、他の類似した情報と一緒に属します。

フィールド

フィールドや ボックスの代わりにテキストボックスを使用します。

使用方法。

  • 変数名テキスト ボックスに、my text と入力します。

の代わりに

  • 変数名フィールドには、my textと入力します。

ただし、タスクを書いていて、すべてのフィールドを一度に参照する必要がある場合は例外です。例えば

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. Settings > CI/CDを選択します。
  3. 一般的なパイプラインを拡大する。
  4. 各項目を入力してください。

複数のフィールドを一度に文書化する方法については、こちらをご覧ください。

フィルタ

イシューやマージリクエストのようなアイテムのリストを表示しているとき、利用可能な属性によってリストをフィルタリングします。例えば、担当者やレビュアーでフィルタをかけることができます。

フィルタリングは検索とは異なります。

フー

製品のドキュメントではfooを使用しないでください。APIやコントリビューターのドキュメントで使用することはできますが、より明確で意味のある例を使用するようにしてください。

フォーク

フォークとは、フォークプロセスを使用してアップストリームプロジェクトから作成されたプロジェクトのことです。

アップストリームプロジェクト（ソースプロジェクトとも呼ばれる）とフォークは フォーク関係にあり、リンクされています。

フォーク関係が解除されると、フォークは アップストリームプロジェクトからリンク解除されます。

未来形

可能であれば、未来形ではなく現在形を使いましょう。例えば、after you execute this command, GitLab displays the resultの代わりに、after you execute this command, GitLab will display the resultを使います。(Valerule:FutureTense.yml)

GB、ギガバイト

GBと MBについては、Microsoftのガイダンスに従ってください。

Geo

Geoにはタイトルケースを使用します。

GitLab

GitLabを所有格（GitLab’s）にしないでください。このガイダンスはGitLab商標ガイドラインに従っています。

GitLab 専用版

Dedicatedを単独で使用しないでください。必ずGitLab Dedicatedを使用してください。

GitLab Duo

Duoを単独で使用しないでください。必ずGitLab Duo を使用してください。

GitLabフレーバーMarkdown

可能な限り GitLabフレーバーMarkdown.(ベールルール:GLFM.yml)

どうしても省略したい場合は、GFMは使わないでください。代わりにGLFMを使用してください。

GitLab Helmチャート, GitLabチャート

GitLabのクラウドネイティブバージョンをデプロイするには、以下を使用します：

  • GitLab Helmチャート(ロングバージョン)
  • GitLabチャート（ショートバージョン）

gitlab チャート、 GitLab チャート、 クラウドネイティブチャートは使わないでください。

Kubernetes クラスターにクラウドネイティブな GitLab** を** デプロイするには 、GitLab Helm チャートを使用します。

異なるインストール方法を説明する文脈で使う場合は、Helm chart (Kubernetes) 。

GitLab Pages

一貫性とブランディングのために、Pagesではなく GitLab Pagesを使ってください。

しかし、ページやUIで最初にGitLab Pagesを使う場合、それ以降はPagesを使うことができます。

GitLab Runner

GitLab Runnerにはタイトルケースを使用します。これはインストールする製品です。この使い方の決定については、イシューを参照してください。

こちらも参照してください。

GitLab SaaS

GitLab SaaSとは、GitLab.comへのアクセスを提供する製品ライセンスを指します。GitLab自身が管理するGitLabインスタンスを指すものではありません。

GitLab 自己管理

GitLab self-managedは、顧客自身が管理するGitLabインスタンス用の製品ライセンスを指す場合に使用します。

GitLab.com

GitLab.comとは、GitLab自身が管理するGitLabインスタンスのことです。

ガイド

私たちはユーザーに直接語りかけたいと考えています。docs.gitlab.comでは、ページタイトルの一部にguideを使用しないでください。例えば、除雪ガイド。代わりに、機能そのものとその使い方について話してください。例えば、Use Snowplow to do xyz.

ゲスト

ゲストのロールについて書く場合：

  • 大文字のGを使用してください。
  • 書き出してください：
    • 使用：ゲストのロールが割り当てられている場合
    • の代わりに: ゲストである場合
  • ゲストロールが最低限必要なロールである場合：
    • 使用：少なくともゲストロール
    • 代わりに：ゲストロール以上

太字は使用しないでください。

Guest権限を使用しないでください。Guestロールが割り当てられているユーザーには、関連する一連の権限があります。

便利な

handyは使わないでください。ユーザーがその機能やプロセスを便利だと感じなければ、信頼を失います。(ヴェイルのルール:Simplicity.yml)

高可用性、HA

高可用性や HAは使わないでください。その代わりに、より多くのユーザーを扱うためのGitLabの設定については、GitLabリファレンスアーキテクチャを参照してください。

より高い

バージョン番号について話すときは、higherを使わないでください。

使用方法。

  • GitLab 14.4以降では…

の代わりに

  • GitLab 14.4 以降では…
  • GitLab 14.4以上で…

ヒット

押すという意味でhitを使わないでください。

使用方法。

  • ENTERを押します。

の代わりに

  • ENTERボタンを押してください。

I

一人称単数は使用しないでください。youを使うか、フレーズを書き換えてください。

すなわち

ラテン語の略語は使わないでください。代わりにthat isを使ってください。(ヴェイルのルール:LatinTerms.yml)

には

in order to は使用しないでください。代わりにtoを使ってください。(Valerule:Wordy.yml)

インデックス

indexの複数形はindexesを使います。

しかし、ElasticSearchでは インデックス.

ソースからのインストール

セルフコンパイルしたコードを使ったインストール方法を指す場合は、セルフコンパイルと表記してください。

使用方法。

  • 自己コンパイルインストール用…

の代わりに

  • ソースからのインストールの場合…

詳しくは、さまざまなインストール方法をご覧ください。

-単語

可能な限り、-ing語は削除してください。訳すのが難しい場合もありますし、より正確な用語があるのが普通です。例えば

  • The files using storage are deleted の代わりに、The files that use storage are deleted を使ってください。
  • ファイルを削除するには、[編集] ボタンを使用します。
  • サーバーの複製が必要です の代わりに、サーバーの複製が必要です を使用します。

イシュー

イシューには小文字を使用してください。

イシューボード

イシューボードには小文字を使用してください。

イシューウェイト

イシュー・ウェイトには小文字を使用してください。

それ

itという単語を使うときは、それが指す単語が明白であることを確認してください。明らかでない場合は、itを使うのではなく、その単語を繰り返してください。

使用方法。

  • このフィールドは接続を返します。このフィールドは4つの引数を受け付けます。

の代わりに

  • このフィールドは接続を返します。4つの引数を受け付けます。

this, these, that, thoseも参照してください。

ジョブ

ビルドを ジョブと同義に使わないでください。ジョブは.gitlab-ci.yml ファイルで定義され、パイプラインの一部として実行されます。

CIを jobという単語と一緒に使いたい場合は、CI jobではなく CI/CD jobを使ってください。

Kubernetes executor

GitLab RunnerはKubernetesクラスター上でジョブを実行することができます。これを行うために、GitLab RunnerはKubernetes executorを使用します。

この機能を参照するときは

  • GitLab RunnerのKubernetes Executor。
  • Kubernetes executor

を使用しないでください：

  • GitLab Runner Kubernetes Executorは、Kubernetesの商標を侵害する可能性があるため、使用しないでください。

後に

バージョン番号について話すときはlaterを使います。

使用方法。

  • GitLab 14.1以降では…

の代わりに

  • GitLab 14.1以降では…
  • GitLab 14.1以上で…
  • GitLab 14.1以降では…

リスト

を参照するときは、listを使用しないでください。 ドロップダウンリスト.代わりに完全なフレーズdropdown listを使用してください。

ライセンス

ライセンスについて書く場合

  • クラウドライセンス、オフラインライセンス、レガシーライセンスなどのバリエーションは使用しないでください。
  • サブスクリプションと同じ意味で使用しないでください：
    • ライセンスは、ユーザーが購入したサブスクリプションへのアクセスを許可し、購入したシート数やサブスクリプションの日付などの情報が含まれています。
    • サブスクリプションは、ユーザーが購入するサブスクリプションの階層です。

使用方法。

  • インスタンスにライセンスを追加します。
  • サブスクリプションを購入します。

の代わりに

  • ライセンスを購入してください。
  • ライセンスを購入

制限事項

制限事項は使用しないでください。代わりに既知のイシューを使用してください。

ログイン、ログオン

log inや log onは使用しないでください。代わりにsign inを使用してください。ユーザー・インターフェースにLog inがある場合は、それを使用できます。

ログイン・ユーザー, ログイン・ユーザー

logged-in userまたはlogged in userの代わりにauthenticated userを使用してください。

より低い

バージョン番号について話すときはlowerを使わないでください。

使用方法。

  • GitLab 14.1以前で。

の代わりに

  • GitLab 14.1以下では。
  • GitLab 14.1以前の場合。

メンテナー

メンテナーのロールについて書く場合：

  • 大文字のMを使いましょう。
  • 書き出してください。
    • 用途：あなたがメンテナーのロールを割り当てられている場合
    • の代わりに: もしあなたがメンテナーなら
  • メンテナーのロールが最低限必要なロールである場合：
    • 使用: 少なくともメンテナーのロール
    • 代わりに：メンテナー以上のロール

太字は使用しないでください。

メンテナー権限を使用しないでください。メンテナーのロールが割り当てられているユーザーには、関連する一連の権限があります。

人

mankindは使わないでください。代わりにpeopleか humanityを使ってください。(Valerule:InclusionGender.yml)

マンパワー

manpowerは使わないでください。workforceや GitLab team membersのような単語を使ってください。(Valerule:InclusionGender.yml)

マスター

master は使わないでください。デフォルトブランチ名のサンプルが必要な場合はmain を使用してください。(Valeルール:InclusionCultural.yml)

may, might

Mightは、何かが起こる可能性があるという意味です。Mightはトラブルシューティングの文書でよく使われます。

Mayは何かをする権限を与えます。mayの代わりにcanを考えてください。

これらの用語を使用しているフレーズを言い換えることを検討してください。これらの用語は可能性や疑念を示すことが多く、テクニカルライティングは正確であるよう努めます。

You canも参照してください。

使用方法。

  • committed_date とauthored_date フィールドは異なるソースから生成されたものであり、同一ではないかもしれません。
  • 典型的なパイプラインは4つのステージで構成され、以下の順序で実行されます：

の代わりに

  • committed_date とauthored_date フィールドは異なるソースから生成されたものであり、同一ではない可能性があります。
  • 典型的なパイプラインは、以下の順序で実行される4つのステージで構成されています。

MB、メガバイト

MBと GBについては、マイクロソフトのガイダンスに従ってください。

メンバー

ユーザーアカウントをグループやプロジェクトに追加すると、そのユーザーアカウントはメンバーになります。

マージリクエスト

マージリクエストには小文字を使用してください。MRを頭文字として使用する場合、最初に使用するときはスペルアウトしてください。

マイルストーン

マイルストーンには小文字を使用します。

最小限のアクセス

Minimal Accessロールについて書く場合：

  • 大文字のMと Aを使用してください。
  • 書き出してください：
    • 使用: Minimal Accessロールが割り当てられている場合
    • 代わりに: Minimal Accessユーザーの場合
  • Minimal Accessロールが最低限必要なロールである場合：
    • 使用：最低限必要なロール
    • 代わりに: Minimal Accessロール以上

太字は使用しないでください。

Minimal Access権限を使用しないでください。Minimal Accessロールが割り当てられているユーザーには、一連の関連権限があります。

n/a、N/A、該当なし

可能であれば、not applicableを使用してください。スペルアウトすることで、英語を母国語としないユーザーにもわかりやすく、大文字と小文字の不一致を避けることができます。

navigateは使用しないでください。代わりにgoを使ってください。例えば

  • このウェブページに移動します。
  • ターミナルを開き、runner ディレクトリに移動します。

(ベイルール:SubstitutionSuggestions.yml)

必要

need toは語弊があるので避けましょう。

例えば、変数が必須である場合、You need to set the variableの代わりに、You need to set the variableを使います：

  • 変数を設定します。
  • 変数を設定する必要があります。

変数が推奨されている場合：

  • 変数を設定する必要があります。

変数がオプションの場合：

  • 変数を設定することができます。

新しい

バージョン番号について話すときは、newerを使わないでください。

使用方法。

  • GitLab 14.4以降では…

の代わりに

  • GitLab 14.4 以降では…
  • GitLab 14.4以上で…
  • GitLab 14.4以降では…

normal, 通常

normalを「いつもの」「典型的な」「標準的な」という意味で使わないでください。代わりにこれらの用語を使いましょう。

使用方法。

  • 通常、証明書を指定します。
  • 通常、証明書を指定します。
  • Git の標準的なワークフローに従ってください。

の代わりに

  • 通常、証明書を指定します。
  • 通常の Git のワークフローに従ってください。

(ベイルール:Normal.yml)

注

語弊があるので、note thatは使わないでください。

使用方法。

  • 設定を変更することができます。

の代わりに

  • 設定を変更できることに注意してください。

古い

バージョン番号について話すときはolderを使わないでください。

使用方法。

  • GitLab 14.1以前で。

の代わりに

  • GitLab 14.1以下では。
  • GitLab 14.1以前の場合。

Omnibus GitLab

Linuxパッケージを使用するインストール方法を指す場合は、Linuxパッケージと表記してください。

使用方法。

  • Linuxパッケージを使用するインストールでは…

の代わりに

  • Omnibus GitLab…を使用するインストールの場合。

詳しくは、さまざまなインストール方法をご覧ください。

について

高レベルのUI要素を文書化する場合、onを前置詞として使用します。例えば

  • 左サイドバーで、Settings > CI/CDを選択します。
  • 権限の付与ダイアログで、グループを選択します。

fromやin は使用しないでください。詳細については、マイクロソフト スタイル ガイドを参照してください。

一度

onceは 1回という意味です。afterや whenの意味には使わないでください。

使用方法。

  • プロセスが完了したら…

の代わりに

  • プロセスが完了したら…

ただ

onlyを修飾する単語の隣に置きます。

  • 非公開プロジェクトのみ作成できます。

この例では、onlyはprojects という名詞を修飾しています。この文は、あなたが作成できるプロジェクトは1種類–非公開プロジェクト–であることを意味しています。

  • あなたが作成できるのは非公開プロジェクトだけです。

この例では、onlyはcreate という動詞を修飾しています。この文は、非公開プロジェクトの削除やユーザーの追加など、他のアクションを実行できないことを意味します。

オーバーライド

一時的な置き換えを示すにはoverrideを使用します。

例えば、ジョブの実行時に値がオーバーライドされる場合があります。元の値は変更されません。

上書き

永続的な置き換えを示すには上書きを使用します。

例えば、ログファイルは同じ名前のログファイルを上書きするかもしれません。

オーナー

オーナーのロールについて書く場合：

  • 大文字のOを使用してください。
  • 書き出してください。
    • 用途：オーナーロールを割り当てられた場合
    • の代わりに: オーナーである場合

太字は使用しないでください。

オーナー権限を使用しないでください。オーナー・ロールが割り当てられたユーザーには、関連する一連の権限があります。オーナーはユーザーが持つことができる最高のロールです。

パッケージ・レジストリ

GitLabパッケージレジストリにはタイトルケースを使用します。

Pages

イシューのページで」というようなフレーズを書く場合、そのページへの行き方を近くに書いてください。そうしないと、人々はイシューのページが何なのか分からないかもしれません。

ページ名はページ上部のUIに表示されるべきです。そうでない場合は、パンくずから名前を取得できるはずです。

docsはUIの大文字と小文字を一致させ、ページ名は太字にすべきです。例えば

  • テストケースのページでは、…

権限

を使用しないでください。 ロールと権限を同じ意味で使用しないでください。各ユーザーにはロールが割り当てられます。各ロールには権限のセットが含まれます。

権限は アクセス・レベル.

パーソナルアクセストークン

個人アクセストークンには小文字を使用してください。

お願い

製品ドキュメントではpleaseを使用しないでください。

UIテキストでは、ユーザーに迷惑をかけたときにpleaseを使ってください。詳しくは、マイクロソフトのスタイルガイドをご覧ください。

Premium

サブスクリプション レベルには、大文字のPremium を使用します。 他のサブスクリプション層の文脈でPremiumを参照する場合は、サブスクリプション層のガイダンスに従ってください。

前提条件

タスクの前のステップを文書化するときは、前提条件を使用します。要件は使用しないでください。

詳細については、タスク トピックの種類を参照してください。

プレス

キーボードのキーについて話すときはpressを使います。例えば

  • コマンドを停止するには、Control+Cを押します。

冒涜

冒涜的な言葉は使わないでください。他のユーザーや貢献者に悪影響を与える可能性があり、GitLabの価値観である「多様性」「包摂」「帰属」に反します。

規定

クラウド・インフラストラクチャのプロビジョニングには、プロビジョニングという用語を使用します。インフラストラクチャをプロビジョニングし、そこにアプリケーションをデプロイします。

たとえば、次のように書きます：

  • AWS EKSクラスターをプロビジョニングし、アプリケーションをデプロイします。

プッシュルール

プッシュ・ルールには小文字を使用します。

をお勧めします。

we recommend の代わりにyou should を使ってください。私たちは、ユーザーに同僚と話すように話しかけ、we とthemを区別しないようにしたいのです。

  • 変数を設定すべきです。(推奨します）。
  • 変数を設定してください。(必須)
  • 変数を設定できます。(オプションです)

レジスタ

アカウントの作成については、sign upの代わりにregisterを使用してください。

削除

removeはオブジェクトが存在し続ける場合に使用します。例えば、エピックからイシューを削除しても、そのイシューはまだ存在します。

オブジェクトが完全に削除された場合は 代わりに deleteを使用してください。

レポーター

レポーターのロールについて書く場合：

  • 大文字のRを使用してください。
  • 書き出してください。
    • 用途：レポーターロールを割り当てられた場合
    • の代わりに：レポーターの場合
  • レポーターロールが最低限必要なロールである場合：
    • 使用: 少なくともレポーターロール
    • 代わりに：レポーターロール以上

太字は使用しないでください。

レポーター権限を使用しないでください。レポーターのロールが割り当てられたユーザーには、関連する一連の権限があります。

リポジトリのミラーリング

リポジトリミラーリングのタイトルケースを使用します。

要件

タスクの前のステップを文書化するときは、前提条件を使用します。要件は使用しないでください。

詳細については、タスク トピックの種類を参照してください。

それぞれ

それぞれを避け、より正確に。

使用方法。

  • ユーザーを作成するには、「ユーザーを作成」を選択します。既存のユーザーの場合は、[変更を保存] を選択します。

の代わりに

  • 新しいユーザーを作成する場合は「Create user」、既存のユーザーを編集する場合は「Save changes」を選択します。

レビューアプリ

レビューアプリは小文字を使用してください。

ロール

ロールとパーミッションは使用しないでください。 権限を同じ意味で使わないでください。各ユーザーにはロールが割り当てられます。各ロールには権限のセットが含まれます。

ロールは アクセス・レベル.

ロールバック

GitLabのバージョンを以前のものに変更するにはロールバックを使用します。

ライセンスやサブスクリプションにはロールバックを使用しないでください。代わりにサブスクリプションティアの変更を使用してください。

ランナー、ランナー

Runner には小文字を使います。これらは CI/CD ジョブを実行するエージェントです。GitLab Runnerと このイシューも参照してください。

ランナーについて言及するとき、ランナーが顧客の GitLab インスタンスにインストールされていることを指定しなければならない場合は、self-hosted ではなくself-managedを使ってください。

ランナーマネージャー、ランナーマネージャー

ランナーマネージャーには小文字を使用します。これらは自動スケーリングのために複数のランナーを作成できるランナーの一種です。GitLab Runnerも参照してください。

ランナーワーカー、ランナーワーカー

Runner workers は小文字を使用してください。これは、ジョブを実行するためにホストコンピューティングプラットフォーム上でRunnerによって作成されるプロセスです。GitLab Runnerも参照してください。

ランナー認証トークン

ランナートークン、認証トークン、トークンといったバリエーションではなく、ランナートークンを使ってください。ランナーは作成時にランナー認証トークンが割り当てられ、ジョブを実行するときに GitLab との認証に使用します。

(s)

(s)を使って単語を複数形にしないでください。理解が遅くなります。例えば

使用方法。

  • ご希望のジョブを選択してください。

の代わりに

  • ご希望のジョブを選択してください。

複数選択できる場合は、複数形にしてください。

サニティチェック

サニティチェックは使用しないでください。代わりに完全性チェックを使ってください。(Valerule:InclusionAbleism.yml)

スケーラビリティ

追加ユーザーのためにGitLabのパフォーマンスを向上させることについて話すときには、スケーラビリティを使わないでください。scaleやscalingという言葉を使ってもよい場合もありますが、GitLabのパフォーマンスをユーザー数に応じて向上させることについては、GitLabのリファレンスアーキテクチャのページを参照するようにしてください。

検索するときは、左サイドバーの検索ボックスに文字列を入力します。検索結果は検索ページに表示されます。

検索はフィルタリングとは異なります。

座席

サブスクリプション課金モデルに言及する場合：

  • GitLab SaaSの場合、シートを使用します。顧客はシートを購入します。一部の例外を除き、ユーザーはグループに招待されるとシートを占有します。
  • GitLabセルフマネージドでは、ユーザーを使います。カスタマーは指定したユーザー数のサブスクリプションを購入します。

セクション

ページ上の領域を表すにはセクションを使います。例えば、ページにUIを分割する線がある場合、これらの領域をセクションと呼びます。

拡張/折りたたみ可能な領域をセクションと考えることもよくあります。セクションの拡張や折りたたみについて言及するときは、セクションという単語を含めないでください。

使用方法。

  • Auto DevOpsを展開します。

の代わりに

  • To-Dops セクションを展開します：Auto DevOpsセクションを展開します。

選択

ボタン、リンク、メニュー項目、リストにはselectを使います。selectはより多くのデバイスに適用され、clickはよりマウスに特化しています。

自己管理

お客様がインストールしたGitLabを指す場合は、self-managedを使用してください。self-hosted は使わないでください。

サービスデスク

サービスデスクには大文字と小文字を使用します。

セットアップ

setupは名詞として、set upは動詞として使います。例えば

  • リモートオフィスのセットアップは素晴らしいですね。
  • リモートオフィスを正しく設定するには、作業エリアの人間工学を考慮しましょう。

サインイン

サインインするアクションを表す動詞としてsign inまたはsign in toを使います。

sign onや sign into、log on、log in、log intoは使わないでください。

ユーザー・インターフェースに別の言葉がある場合は、そちらを使用してください。

サインインを名詞または形容詞として使うことができます。例えば、サインインページや サインイン制限などです。

シングルサインオンを使用できます。

サインアップ

アカウントの作成については、sign upの代わりにregisterを使用してください。

サインインユーザー, サインインユーザー

サインイン・ユーザーや サインイン・ユーザーの代わりに、認証済みユーザーを使用してください。

単純に、シンプルに

simplyや simpleは使わないでください。ユーザーがプロセスをシンプルだと感じなければ、信頼を失います。(ヴェイルのルール:Simplicity.yml)

というわけで

sinceは時間枠を表します。例えば、Since 1984, Bon Jovi has exist.sinceをbecauseの意味で使わないでください。

使用方法。

  • あなたは開発者ロールを持っているので、ウィジェットを削除できます。

の代わりに

  • 開発者ロールを持っているので、ウィジェットを削除できます。

スラッシュ

and/orの代わりにorを使い、文章を書き直します。このルールはfollow/unfollowのような他のスラッシュにも適用されます。一部の例外（CI/CDなど）は認められます。

スレーブ

スレーブは使用しないでください。別のオプションはsecondary です。(Valerule:InclusionCultural.yml)

ストレージ

という文脈で：

  • Gitalyでは、ストレージは物理的なものであり、ストレージと呼ばなければなりません。
  • Gitalyクラスタ、ストレージはどちらでもかまいません：
    • 仮想ストレージ
    • 物理ストレージ（PhysicalStorage）。

Gitaly ストレージには物理パスがあり、仮想ストレージには仮想パスがあります。

サブグループ

サブグループの代わりにサブグループ（ハイフンなし）を使用してください。(ヴェイルルール:SubstitutionSuggestions.yml)

サブスクリプション・ティア

サブスクリプションや サブスクリプション・ティアと以下のものを混同しないでください。 ライセンス.ユーザーはサブスクリプションを購入します。そのサブスクリプションにはティアがあります。

ティアの説明

の代わりに使用
無料ティア以上すべてのティアで
無料ティア以上すべてのティアで
Premium以上PremiumおよびUltimateティアの場合
Premium以上PremiumおよびUltimateティアの場合
Premium以下のティアの方無料およびPremiumレベル

その

名詞を説明するときにthatを使用しないでください。例えば

使用方法。

  • 保存するファイル…

の代わりに

  • 保存するファイル…

this, these, that, thoseも参照してください。

ターミナル

ターミナルには小文字を使用します。例えば

  • ターミナルを開きます。
  • ターミナルからdocker login コマンドを実行します。

Terraform モジュールのレジストリ

GitLab Terraform Module Registryではタイトルケースを使いますが、特定のモジュール以外については小文字のm 。例えば

  • TerraformモジュールをプロジェクトのTerraformモジュールレジストリに公開することができます。

テキストボックス

UI要素を参照するときは、fieldや boxの代わりにtext boxを使用してください。

あります、あります

there isやthere are は避けるようにしましょう。これらのフレーズは主語を隠します。

使用方法。

  • バケツには穴が開いています。

の代わりに

  • バケツに穴が開いています。

彼ら

特定の人物を指す場合を除き、性別を特定する代名詞の使用は避けましょう。性別を特定しない代名詞として、単数形のtheyを使用してください。

this, these, that, those

これらの単語の後には必ず名詞をつけます。例えば

  • 使用：この設定はパフォーマンスを向上させます。

  • の代わりに使用します：パフォーマンスが向上します。

  • 使用：このパンツは最高です。

  • の代わりに：これが一番です。

  • 使用法：そのドロイドはあなたが探しているものです。

  • の代わりにそのドロイドはあなたが探しているものです。

  • 使用法：その設定は構成する必要があります。(あるいは、Configure those settings.）
  • の代わりに設定が必要です。

to which, of which

to whichやof which を避け、前置詞を文末にぶら下げるようにしましょう。例文は前置詞を参照してください。

To-Do 項目

To-Doitem には小文字とハイフンを使用します。(Valerule:ToDo.yml)

To-Doリスト

To-Do リストにはタイトルケースを使用します。(Valerule:ToDo.yml)

トグル

トグルをオンまたはオフにします。例えば

  • blahトグルをオンにします。

TFA、二要素認証

代わりに2FAと 二要素認証を使用してください。

タイプ

タイプは、カーソルが入力中の場所にある場合に使用します。例えば、検索ボックスでは、入力を始めると検索結果が表示されます。検索ボックスの外をクリックすることはありません。

使用例：

  • Alex という名前のユーザーをすべて表示するには、Alと入力します。
  • ドキュメンテーションチームのすべてのラベルを表示するには、docと入力してください。
  • クイックアクションのリストは、/と入力してください。

また 入力.

究極

サブスクリプション・ティアには、大文字のUltimateを使用します。他のサブスクリプション層の文脈でUltimateを参照する場合は、サブスクリプション層のガイダンスに従ってください。

測定単位

数値と測定単位の間にはスペースを入れてください。例：128GB。(ベールルール:Units.yml)

詳細については、マイクロソフトのスタイルガイドを参照してください。

更新

ソフトウェアの新しいパッチバージョンをインストールする場合にのみ、updateを使用します。例えば

  • GitLabを14.9から14.9.1にアップデートします。

それ以外の場合はupdateを使わないでください。代わりにupgrade を使ってください。

アップグレード

アップグレードを使用します：

  • より高いサブスクリプション層（PremiumまたはUltimate）を選択します。
  • GitLabの新しいメジャーバージョン（13.0）またはマイナーバージョン（13.2）をインストールすること。

使用例：

  • GitLab Ultimateにアップグレードします。
  • GitLabを14.0から14.1にアップグレード。
  • GitLabを14.0から15.0にアップグレード。

他のテキストを伴わないUpgrade GitLabというフレーズには注意してください。製品バージョンについて話しているのか、サブスクリプション層について話しているのかを、周囲のテキストで明確にするようにしてください。

ダウングレードと ロールバックも参照してください。

左上、右上

UIの方向性を示すには、左上隅と 右上隅を使用します。UI要素が隅にない場合は、左上と 右上を使用します。

左上と 右上は使用しないでください。

詳しくはマイクロソフトのスタイルガイドをご覧ください。

便利

usefulは使わないでください。ユーザーがそのプロセスを便利だと感じなければ、信頼を失います。(Valerule:Simplicity.yml)

ユーザーアカウント

ユーザーアカウントを作成します。ユーザーアカウントにはアクセスレベルがあります。ユーザーアカウントをグループまたはプロジェクトに追加すると、そのユーザーアカウントはメンバーになります。

利用

utilize は使用しないでください。代わりにuseを使ってください。その方が簡潔で、英語を母国語としない人にも理解しやすいからです。(Valerule:SubstitutionSuggestions.yml)

経由

ラテン語の略語は使用しないでください。代わりにwith、through、byを使ってください。(ヴェイルのルール:LatinTerms.yml)

私たち

weを避け、代わりにユーザーがGitLabでどのように何かを達成できるかに焦点を当てるようにしましょう。

使用方法。

  • ウィジェットは、整理したい仕事があるときに使います。

の代わりに

  • ウィジェットを追加する機能を作りました。

(ベイルール:SubstitutionSuggestions.yml)

但し

whileは、時間内に起こることだけを指すときに使います。例えば、プロセスが実行されている間、Windows を開いたままにしておきます。

whileは比較には使用しないでください。例えば

  • ジョブ1は素早く実行できます。しかし、ジョブ2の方が正確です。

の代わりに

  • ジョブ1は素早く実行できますが、ジョブ2はより正確です。

詳しくはマイクロソフトのスタイルガイドをご覧ください。

一方

whilstは使わないでください。代わりにwhileを使ってください。whileの方が簡潔で、英語を母国語としない人にも理解しやすいでしょう。

ホワイトリスト

whitelistは使用しないでください。別のオプションとしてallowlist があります。(ヴェイルルール:InclusionCultural.yml)

まだ

製品やその機能について話すときには、yetを使わないでください。ドキュメントでは、現在の製品について説明しています。

タスクを書くときにyetを使う必要があるかもしれません。yet を使用する場合は、周囲のフレーズが現在形、能動態で書かれていることを確認してください。

今後の特集の書き方についてのガイダンスをご覧ください。(Valerule:CurrentStatus.yml)

あなた、あなたの、あなたの

ユーザー、管理者、顧客の代わりにyouを使いましょう。製品をインストールするユーザーであれ、設定するユーザーであれ、管理するユーザーであれ、使用するユーザーであれ、ドキュメンテーションはユーザーに直接語りかけるものでなければなりません。

使用方法。

  • パイプラインを設定できます。
  • ユーザーのパスワードをリセットできます。(管理者向けコンテンツ)

の代わりに

  • ユーザーはパイプラインを設定できます。
  • 管理者はユーザーのパスワードをリセットできます。

あなたは

可能であれば、you canの代わりに能動態で文を始めましょう。例えば

  • コードレビューアナリティクスを使ってマージリクエストデータを見てください。
  • チームのタスクを整理するボードを作成します。
  • リポジトリへのプッシュを制限する変数の設定。
  • SkypeやTwitterなどの外部アカウントへのリンクを追加します。

オプションのアクションに使用できます。例えば

  • コードレビュー分析を使用して、マージリクエストごとのメトリクスを表示します。API を使用することもできます。
  • 名前と値のペアを入力します。ストリーミング先ごとに最大20組まで追加できます。