GitLab コンテンツスタイルガイド
GitLab コンテンツスタイルガイドは、GitLab を代表してコンテンツを作成するすべての人のためのものです。これは、私たちの書き方（声、トーン、語彙、文法、句読点、フォーマット）を定め、すべてのコンテンツにわたって一貫性を確保します。
ブランドボイス
GitLab のブランドボイスは、ブランドとしての私たちが何者であるかを表し、表現するものです。これは私たちのブランドアイデンティティの中核を成すものであり、ブランドバリューに基づいています。私たちのブランドボイスは、すべてのコミュニケーションにおいて明確かつ一貫した形で伝わる必要があります。
一貫したブランドボイスを維持することは、以下に役立ちます。
- ブランドへの認知度、認識、信頼を高める
- 独自の価値を伝える
- 競合他社と差別化する
- パーソナリティを表現する
私たちのブランドボイスは、以下のパーソナリティ特性で構成されています。
1. ビジョナリー（Visionary）
私たちは、自信に満ちた洗練された技術エキスパートでありカテゴリー創造者です。最大のインパクトをもたらす焦点を絞ったイノベーションとインテリジェントなソリューションを通じて、お客様とコミュニティを支援し力を与えることに尽力しています。私たちは率先垂範し、誰もが貢献できお客様が目標を達成できるとき、最も成功すると感じています。
例: 私たちはカテゴリーを創造しました。
2. エンパセティック（Empathetic）
私たちは単なるベンダー以上の存在です。思慮深く、協調的で、配慮のあるパートナーです。グローバル規模で親しみやすく包括的であり、チームとお客様の多様なニーズを理解しサポートすることに専念しています。お客様と肩を並べて、成功に役立つソリューションを作り上げます。
例: GitLab コミュニティ。私たちのミッションは、誰もが私たちの世界を支えるソフトウェアに貢献し共創できるようにすることです。
3. インテンショナル（Intentional）
私たちは目的意識があり、率直で透明性があります。お客様にとって信頼できる体験を生み出すために、明快さと焦点をもってコミュニケーションを取ります。優先順位に対して規律を持ち、コミットメントを一貫して果たします。
例: 月次リリース投稿
ブランドボイスを形にする
これらのガイドラインは、GitLab のブランドボイスをあなたの執筆に組み込みつつ、個性と創造性を発揮できるようにするのに役立ちます。
ビジョナリー
| 私たちは… | しかし、私たちは…ではない |
|---|---|
| ✅ インスピレーションを与える | ❌ センセーショナルな |
| ✅ 技術エキスパート | ❌ 近寄りがたい |
| ✅ 洗練されている | ❌ 傲慢な |
| ✅ 革新的 | ❌ 非実用的 |
ビジョナリー なコンテンツを作成するヒント:
- 価値をもたらす形で専門知識を共有しましょう。
- 明確な例を示し、可能な場合はデータを提供しましょう。
- 推奨内容が正確で証明可能であり、対象読者にとって役立つことを確認しましょう。
例:
エンパセティック
| 私たちは… | しかし、私たちは…ではない |
|---|---|
| ✅ 協調的 | ❌ 卑屈な |
| ✅ 親しみやすい | ❌ 過度に熱心な |
| ✅ 包括的 | ❌ 見下した態度の |
| ✅ 思慮深い | ❌ 無神経な |
エンパセティック なコンテンツを作成するヒント:
- 読者がいる場所で出会いましょう — 取り上げる技術やトピックを読者が知っていると思い込まないでください。
- 説明はしますが、見下した態度は取らないでください。
- 執筆では 包括的 であってください。
例:
- ブログ: Quickstart guide for GitLab Workspaces
- ブログ: The ultimate guide to SBoMs
- ハンドブック: CEO ハンドブックページ
- ハンドブック: コミュニケーションハンドブックページ
- ハンドブック: バリューハンドブックページ
インテンショナル
| 私たちは… | しかし、私たちは…ではない |
|---|---|
| ✅ 明確 | ❌ 押しつけがましい |
| ✅ 焦点が絞られている | ❌ 柔軟性がない |
| ✅ 信頼できる | ❌ 硬直的 |
| ✅ 透明性がある | ❌ 無謀な |
インテンショナル なコンテンツを作成するヒント:
- 読者が必要とする情報を提供しましょう。
- 読者がフィードバックを提供できる機会を提供しましょう。
- 平易な言葉を使い、限界を共有することを意味するとしても誠実であってください。
例:
スタイルとフォーマット
以下で直接扱われていないスタイルの質問については、Associated Press Stylebook を参照してください。以下のガイダンスが AP スタイルと矛盾する場合は、以下のガイダンスを優先します。特定の用語の使い方については、ドキュメントの推奨用語リスト を参照してください。
スタイル
略語と頭字語
略語または頭字語 を使用する際は、最初の言及で完全な用語を使用し、その直後に括弧内に短縮形を含めるようにしてください。それ以降は、頭字語または略語を代わりに使用できます。
コンテンツ内で頭字語または略語を 1 回しか使用しない場合は、おそらく必要なく、完全な用語をそのまま使用できます。
頭字語または略語を構成する単語は、固有名詞の場合のみ大文字にしてください。
✅ Dynamic application security testing (DAST) examines applications for vulnerabilities like these in deployed environments.
✅ GitLab Dynamic Application Security Testing (DAST) includes the following analyzers.
短縮形
より人間味があり、堅苦しくない響きにするために、短縮形（can’t, didn’t, it’s, we’re）を使用します。
リスト
番号付きまたは箇条書きリストが連続した文として読める場合は、各項目の最初の文字を大文字にせず、各項目の末尾に句読点を含めません。
✅ GitLab Duo is unique because we:
- do not use your content to train models
- are transparent about all AI models used by GitLab Duo
- use the right AI model for each task, ensuring you always stay ahead of the curve
リストの各項目がそれ自体で完結した文として読める場合は、独立した文と同じように大文字化と句読点を使用します。
✅ Here are three reasons GitLab Duo is unique:
- GitLab Duo features do not use your content to train models.
- Our publicly available documentation describes all AI models used by GitLab Duo.
- We use the right AI model for each task, ensuring you always stay ahead of the curve.
代名詞
特定の人物を指している場合を除き、性別中立的な代名詞（they, them）を使用します。
✅ With GitLab, a developer can integrate security into their workflow.
❌ With GitLab, a developer can integrate security into his/her workflow.
引用符
直接引用には二重引用符（" “）を、引用内の引用には一重引用符（’ ‘）を使用します。
ピリオドとカンマは終わりの引用符の内側に含めます。
引用の一部である句読点は引用符の内側に含める必要があります。引用の一部ではない句読点（上記のピリオドとカンマを除く）は引用符の外側にあるべきです。
✅ Recently, an article was published stating, “Software is eating the world.”
✅ What do you think of the claim, “Software is eating the world”?
✅ “Do you agree that software is eating the world?” wrote the author.
ブログ投稿でインタビュー対象者からの直接引用を含める場合、says や explains などの動詞には現在形を使用します。
✅ “Ruby was optimized for the developer, not for running it in production,” says Sid.
例外は、明らかに過去のイベントから引用する場合です。その場合は、読者が混乱したり誤解したりしないように過去形を使用します。
スペル
GitLab ブログとマーケティングサイトでは、デフォルトでアメリカ英語を使用します。スペルの違いリスト を参照してください。特定の地域向けに作成されたコンテンツでは、その地域に最も適した英語のバリアントを使用してください。
態
一般的に、可能な限り 能動態 を使用してください。能動態を使用することで、文に明確な主語と動詞が含まれることが保証されます。
✅ The GitLab community submitted 1 million merge requests in March 2019
❌ One million merge requests were submitted in March 2019.
受動態の方が良い場合も限定的にあります。それぞれのケースで最善の判断をし、受動態を使用することに決めた場合は、なぜその選択をしているのかを意識するようにしてください。
大文字表記
ブランド名と出版物名
ブランド名は会社のブランドガイドラインに従ってスタイル化されていることを確認してください。
✅ WiFi Tribe, DigitalOcean
「the」がブランドや出版物の名前の一部を形成する場合は、それを大文字にします。文が不自然になる場合は The を省略します。
✅ We spoke to a reporter from The Wall Street Journal.
✅ We spoke to a Wall Street Journal reporter.
GitLab 機能名
一般的に、GitLab の機能名は小文字ですが、例外もあります。確信が持てない場合は ドキュメントの推奨用語リスト を参照してください。
GitLab の機能、部門、チーム
要素の名前は大文字にしますが、その後の単語（team, department など）は大文字にしません。
✅ Engineering team, Security department
❌ Engineering Team, security department
役職
文中の役職は、人物の名前の前後どちらに表示される場合でも、小文字を使用します。
✅ John Smith, director of engineering, led the project.
❌ John Smith, Director of Engineering, led the project.
人物の名前と役職が独立して表示される場合（動画の下三分の一、ネームタグ、引用への帰属など）は、役職を大文字にします。
✅ John Smith, Director of Engineering, XYZ Corporation
❌ John Smith, director of engineering, XYZ Corporation
タイトルとヘッダー
一般的に、すべての見出し、タイトル、サブヘッドにはセンテンスケース（最初の単語と固有名詞のみを大文字にする）を使用します。デザインの観点からタイトルケースが好まれる例外もあります。
✅ Remediating vulnerabilities with GitLab’s security insights and AI
❌ Remediating Vulnerabilities with GitLab’s Security Insights and AI
日付と時刻
日付の書式
外部向けコンテンツでは、月をスペルアウトし、年の前にカンマを使用します。文が年の後に続く場合は、年の後にもカンマを含めます。月と年だけを述べる場合は、月の後にカンマは必要ありません。
✅ Release date: November 16, 2023
✅ On November 16, 2023, we released GitLab 16.6.
✅ We released GitLab 16.6 in November 2023.
社内向けコンテンツでは、ISO 形式（2023-11-16）を使用します。特定の地域向けのコンテンツでは、その地域で好まれる形式を使用します。
日付が月とは独立して表示される場合（See you on the 16th）を除き、日付の後に rd/st/th を使用しないでください。
時刻の書式
ante meridiem と post meridiem を a.m. と p.m.（小文字、文字間にピリオド、時刻と区別するためにその前にスペース：6:00 a.m.）で略記します。
デフォルトは 12 時間制（9:00 p.m.）です。ただし、特定の地域向けのコンテンツでは、その地域で使用される形式を使用します。
物理的なイベントについて書く場合は、イベントが開催されているタイムゾーンを使用します。タイムゾーンを略記しないでください。バーチャルイベントの場合は、UTC を使用します。
句読点と記号
アンパサンド
会社の名前、出版物のタイトル、または公式名称の一部である場合にのみアンパサンドを使用します。
本文中の and の代わりにアンパサンドを使用しないでください。
ディスプレイ広告の見出しなど、文字数が非常に厳しい場合は、アンパサンドを控えめに使用できます。
コロン
コロンが完全な文（質問を含む）を導入するために使用される場合、コロンの後の最初の単語を大文字にします。
✅ AI isn’t just another fad: It’s seeing real adoption among practitioners.
❌ AI isn’t just another fad: it’s seeing real adoption among practitioners.
✅ We aimed to explore several topics: Where are things improving, and where are teams still running into roadblocks?
❌ We aimed to explore several topics: where are things improving, and where are teams still running into roadblocks?
✅ One thing stood out in the survey responses: the importance of security.
❌ One thing stood out in the survey responses: The importance of security.
タイトルでは、完全な文でない場合でも、コロンの後の最初の単語を常に大文字にします。
カンマ
デフォルトでは、シリアル（オックスフォード）カンマを使用します。特定の地域向けのコンテンツでは、その地域で最も一般的なものを自由に使用してください。
✅ AI can help DevSecOps teams write code, resolve security vulnerabilities, accelerate code review, and improve collaboration.
❌ AI can help DevSecOps teams write code, resolve security vulnerabilities, accelerate code review and improve collaboration.
ダッシュ
文中の独立した思考を区切るには、2 本のダッシュ（–）の代わりに em ダッシュ（—）を使用します。em ダッシュの両側にスペースを 1 つ置きます。
from や between の単語が前にない数値範囲を伝える場合は、en ダッシュ（–）を使用します（Join us October 20–25 in San Francisco）。en ダッシュの両側にスペースを含めないでください。
省略記号
省略記号（ … ）の前後にスペースを 1 つ含めます。
ハイフン
別の単語を共同で修飾する 2 つ以上の単語をつなぐためにハイフンを使用します（built-in security）。
副詞 very または -ly で終わる副詞をハイフンでつながないでください（fully integrated platform）。
一般的に、semi, pre, non, un, sub や multi などの接頭辞をハイフンでつながないでください（multitenant, subtask）。例外は、接頭辞の最後の文字が語幹の最初の文字と同じ場合です（sub-bucket）。
接頭辞の後に固有名詞が続く場合、および接頭辞 all-, mid-, ex-（「元」を意味する）、self- で始まる単語にはハイフンを使用してください（mid-July, self-managed）。
特定の単語のハイフンの使い方については、推奨用語リスト を参照してください。
スペース
ピリオドの後にはスペースを 1 つだけ（2 つではなく）使用します。
数字と測定単位の間にスペースを使用します（128 GB）。
数字
小さな数字
一般的に、0 から 9 までの数字をスペルアウトします。例外は以下のとおりです。
- パーセンテージ: 一般的に、文の先頭でない限り、パーセンテージには数字とパーセント記号（%）を使用します。
- コールアウトボックスと統計のリスト: ケーススタディの上部にある統計コールアウトや統計の箇条書きリストなど、文字数が制限されている場合や数字を強調したい場合は、10 未満の数字に数字を使用します。
文の先頭でない限り、10 以上の数字には数字を使用します。
見出しの先頭に数字を置く場合は、常に数字を使用します（5 ways AI can help developers）。
大きな数字
4 桁以上の数字にはカンマを含める必要があります（2,000; 100,000）。これが混乱を招く可能性のある特定の文脈で書いている場合（小数点の代わりにカンマを使用する地域など）は、対象読者にとって最も理にかなったことを行ってください。
一般的に、k（「千」を意味する）や M または mil など、大きな数字の略語を避けてください。これらの略語は、文字数の制限が厳しいコールアウトボックスなど、スペースが非常に限られている場合にのみ使用します。
通貨
通貨が言及される文脈では、ISO 4217 規格 のコードを使用して、
パーセンテージ
数字がスペルアウトされている場合を除き、percent の代わりに常に % を使用します。スペルアウトされている場合は percent もスペルアウトします。
