breaks	false

ガイドライン

日々の作業において、Stride ユーザーは、あなたの書いた記事を読んで Stride Game Engine について学習することになるでしょう。誰にでもわかりやすく、利用しやすいページを書くことを心がけてください。あなたの探求をお手伝いし、ドキュメントを統一し使いやすいものにするために、以下のガイドラインに沿って執筆してくださるようお願いします。

執筆スタイル
ページの構成
ページとファイルの構造
書式

注意：以下に述べる方向性はただのガイドラインであり、規則ではありません。特定の状況に適さない場合は、無視して構いません。

執筆スタイル

会話のトーン

適切

ドキュメントは会話調にしたいと思っています。私たちのチュートリアルや解説を読んでいると、著者と会話をしているような感覚になることでしょう。読者として、形式張らず、くだけた、有益な体験をして、筆者が説明してくれるのを聞いているような感覚になるはずです。

不適切

会話調の文体と、技術的な話題に対する学術的な扱いの文体が混在しています。とても役に立つ情報ですが、それらの記事は私たちのドキュメントとは全く異なるスタイルで書かれています。学術雑誌を読むときのような、非常に異なるトーンとスタイルで書かれているのを目にします。非常に乾いた話題の、乾いた説明を読んでいるような気がします。

上段は、私たちの推奨する会話スタイルです。下段は、より学術的なスタイルです。すぐに違いがわかります。

一方で、口語的になりすぎないように注意が必要です。 "You gonna see", "We'll see", "We've" などの表現は避けるべきです。

二人称

適切

あなたは、記事を読者に直接話しかけているかのように書くべきです。あなたは、二人称を頻繁に使うべきです。（この2つの文章で私が使ったように）二人称は必ずしも「あなた」という言葉を使うわけではありません。読者に直接向かって書きなさい。命令文を書きなさい。読者に何を学んでほしいかを伝えなさい。

不適切

著者が、三人称で書くことを選択するかもしれません。その場合、彼は、読者を表す代名詞や名詞を見つけなければなりません。読者は、この三人称スタイルが好ましくなく、読んでいて楽しくないと思うかもしれません。

上段は、私たちの推奨するスタイルです。下段では三人称を使用しています。二人称で書いてください。あなたもその方が読みやすいと思ったのではないでしょうか。

能動態

能動態で記事を書きましょう。能動態とは、文の主語がその文の動作（動詞）を行うことを意味します。これは、主語が従わせられるように記述される受動態とは対照的です。次の2つの例を比べてみてください。

適切

コンパイラは、ソースコードを実行ファイルに変換しました。

不適切

ソースコードは、コンパイラによって実行ファイルに変換されました。

最初の文は、能動態を使っています。2つ目の文は、受動態で書かれています。（この2つの文も、それぞれのスタイルの例になっていますね。）

能動態の方が読みやすいのでおすすめです。受動態は読みにくくなることがあります。

簡単な言葉

記事を書くときは、Stride のユーザーは全員が英語を母国語としているわけではないことを覚えておいてください。あなたの記事を読む人はさまざまであり、あなたが知っている語彙を知らない可能性もあります。

一般的に、「5年生の読解力」を目処に書いてみてください。

ページの構成

Stride のドキュメントは、さまざまな種類のページで構成されます。期待される内容とページレイアウトは、その種類に強く依存します。記事を書く前にまずどんな種類のページにするのかを決め、それから、次に示す、内容とレイアウトのテンプレートに従ってください。

ページの種類に基づく内容とレイアウトのガイドラインに加えて、このセクションの最後に、内容に関する一般的な推奨事項をいくつか挙げておきます。

「はじめに(Getting Started)」ページ

「はじめに」の記事は、Stride の新規ユーザーの最初の一歩を導くことを目的としています。このページでは、基本的で本質的な話題のみをカバーし、その概念を深く説明する必要はありません。 1ページに1つのテーマだけを取り上げてください。

あらゆるタイプの読者を対象にしたページは、「はじめに」ページのルートページの直下に挿入してください。特定の読者をターゲットにするページは、読者を特定したページの下に挿入してください。 Stride の新規ユーザーをフォローできるように、「はじめに」ページの順序を決めてください。

「はじめに」ページは、次のような内容で構成されます。

ページタイトル（そのページで扱っているテーマ）。
その内容が重要である理由と、機能やツールの目的の簡単な説明。
このページで読者が具体的に何をするかを説明する短い段落。
学習内容を説明する画像または動画（可能であれば）。
サブタイトルとページの内容。

例：

# Stride でシーンを設計する

シーンはゲームに欠かせない要素です。
シーンを使うと、ゲームの内容を複数の段階やモジュールに分割することができます。
ここでは、Stride のエディターを使って、シーンを作る方法について学びます。

[シーンイメージ](media/scene.png)

## シーンに要素をドラッグ＆ドロップする

...

チュートリアルの目的は、ユーザーによるゲームコンポーネントの作成に付き添うことです。各チュートリアルは、初期の状態（ほとんどの場合、空っぽのゲーム）から始まって、最終の状態（ミニゲームやゲームコンポーネントの完成）まで続きます。最終的に実現するまでの、主要なステップごとにページを作成してください。ページは時系列に並べて、次のページが前のページで終わったところから始まるようにします。チュートリアル用のフォルダを1つ作成してください。

チュートリアルのヘッダーページは、次のような内容にで構成されます。

ページタイトル（チュートリアルの名前）。
チュートリアルで実現することと、学べることに関する説明。
チュートリアルの完了に必要となる知識（あれば）。
最終イメージの画像（可能であれば）。
チュートリアルのサブページへのリンクを持った目次（順序付きリスト）。

例：

# 2Dゲームのチュートリアル

このチュートリアルでは、簡単な2Dゲームをゼロから作成します。
シーンの作成方法、要素間のコリジョン判定の方法、そしてゲームに UI を追加する方法について学びます。
このチュートリアルは、Stride で新しいプロジェクトを作成する方法と、アセットをインポートする方法を知っていることを前提としています。

[2Dゲームイメージ](media/my2dGame.png)

1. [アセットをインポートする](ImportAsset.md)
2. [レベルを作成する](CreateLevel.md)
3. [コリジョンを追加する](AddCollisions.md)
4. [UI を追加する](AddUI.md)

チュートリアルページは、次のような内容で構成されます。

ページタイトル（ページで実現すること）
前後のページへのリンク
このページで実現することと学ぶことの説明。
ページで実現することを示した画像（可能であれば）。
ページのサブステップとその内容。
チュートリアルの次のページへのリンクを持った紹介文。

例：

# ゲームに UI を追加する

前のページ [物理コリジョンを使う](UsePhysicsCollision.md) | 次のページ [ゲームを配布する](DeployYourGame.md)

このページでは、ゲームに簡単なUIを追加していきます。
Stride のデフォルトのデザインを使って UI を作成し、ゲームプレイと連動させる方法について学びます。

[ゲームのUIのイメージ](media/MyGameUI.png)

1. [UI コンポーネントを追加する](# Add a UI component)
2. [UI を設定する](# Set the UI)
3. [UI をゲームに関連付ける](# Make UI interact with your game)

## UI コンポーネントを追加する

...

次のセクションでは、[ゲームを配布する方法](DeployYourGame.md)について学びましょう。

注意：それぞれの指示は、可能な限り、指示の前後の状態を示す2つの画像で囲みましょう。最初の指示の前に置いた画像が初期状態で、最後に置いた画像が最終の状態に対応します。

セクションヘッダーページ

セクションヘッダーは、ドキュメントフォルダに置かれるトップページです。ヘッダーページの目的は、セクションの話題を紹介し、エンジンの最適な機能を公開し、セクションの概要を提供することです。

ヘッダーページの内容は次の通りです。

タイトルとしてのセクション名
セクションの内容を説明する画像（サブフォルダの場合、この画像を省略できます）
このセクションで紹介する内容を示す短い導入文。
その話題における、エンジンの主な機能や最適な機能について公開する段落。
このセクションを読解することで学べることついて説明する短い段落。
話題に関するすべての視点を与えるセクションの概要（目的、課題、基本概念）。

注意: サブフォルダのヘッダの場合、セクションのヘッダページは概要やメインテーマへのリンクだけで十分な場合があります。

例：

# 物理演算

![物理演算セクションのイメージ](media/PhysicSection.png)

物理演算を使って、ゲーム内で物理シミュレーションを行うことができます。

Stride は、Game Studio に完全に統合された物理演算システムを持っています。
専用の物理エディタを使って、オブジェクトの物理形状を直接編集したり、モデルから自動的に生成したりすることができます。

このセクションでは、オブジェクト間の衝突のシミュレーション、トリガー領域の追加、オブジェクトへの物理法則の適用などについて学びます。

## 概要

物理エンジンの目標は、ゲーム要素のアクションを生成して自動化する方法を提供し、それらが物理法則に従っているように見せることです。
正確な物理シミュレーションは非常にコストがかかるので、物理的な振る舞いはすべて近似的に計算されます。

# 物理形状

![物理形状のイメージ](media/PhysicShapes.png)
...

# 物理オブジェクトの種類
...

参考ページ

参考ページでは、特定のコンセプトや機能、要素について、深い説明を行います。

参考ページの内容は次の通りです。

ページタイトル（コンセプトの名前）。
コンセプトの定義と説明。
コンセプトの標準的な使い方と、なぜその話題が重要なのかの説明。
コンセプトを示す画像（可能であれば）。
コンセプトのサブトピック（機能性、使用例など）。

例：

# マテリアル

マテリアルとは、要素をどのようにレンダリングするかを定義するルールのセットです。

モデル、パーティクル、スプライトに対してマテリアルを適用することで、要素の色、ライティング、シャドウイングを定義することができます。

![マテリアルのイメージ](media/Material.png)

1. オブジェクトジオメトリ

...

2. オブジェクトシェーディング
...

HOWTO ページ

HOWTO ページの目的は、何かを実現するための明確な手順を提供することです。各 HOWTO ページは、他の HOWTO ページから独立していて、読者を一つの目標に導くものでなければなりません。コンセプトを定義したり、説明したりすることは避けましょう。

HOWTO ページの内容は次の通りです。

ページタイトル（ねらいを表す動詞で終わるフレーズ）
説明を理解するために必要な知識。
ページの目的と、何について学ぶか
最終イメージの画像（可能であれば）
主な手順とその説明、そして副題（副題には手順番号を付けましょう）

例：

# UI にパーティクルを追加する

前提条件：このページでは、パーティクルや UI の一般的な使い方を知っていることを前提とします。

このページでは、UI にパーティクルを割り当てる方法について説明します。

![UIに割り当てられたパーティクルのイメージ](media/ParticlesInUI.png)

## 1. パーティクルエフェクトを作成する
...

## 2. UI を作成する
...

## 3. UI リンクコンポーネントを追加する
...

長い説明は避けよう

説明が長いと、読者は消化不良になってしまいます。ほとんどの場合、読者はそれらを無視してしまうか、あるいは説明の本質的なポイントを押さえることができなくなります。

そのため、1つの段落では2つ以上のことを説明しないようにしましょう。説明は短くシンプルにして、可能であれば、説明文の横に、概念を示す画像や図を追加するようにしましょう。

このことは、「はじめに」ページ、チュートリアルページ、HOWTO ページではさらに重要です。これらのページでは、コンセプトを数行で説明するか、あるいは説明するかわりにコンセプト専用のページを参照するようにしてください。

長い文章は避けよう

8～10 画面よりも長い記事は避けるようにしましょう。記事が長いと、読者は読み始めることすら難しくなり、読者の学習を妨げてしまいます。記事の内容がこの画面数に収まらない場合は、記事を複数の記事に分割しましょう。

画像とビデオを使おう

可能な限り、説明には画像やビデオを追加しましょう。読者は大変助かります。

また、理にかなっている場合は、画像ではなく小さなビデオを使うことをお勧めします。ビデオは重いからといって、たくさんの矢印が描かれた図を使わなければならなかった時代は終わったと考えています。現在ではインターネットと圧縮技術のおかげで短いビデオならドキュメントに含めることができ、わかりやすさをさらに向上することができます。

ビデオのエンコード方法

いろんなブラウザやデバイスで再生できるように、ビデオのフォーマット要件は低くしましょう。 H.264 baseline プロファイルなどを使います（ほぼどこでも再生できます）。

ビデオをこのフォーマットに変換するには、ffmpeg を使用します。

ffmpeg をダウンロードします。
ff-prompt.bat を実行します。
ff-prompt.bat のコマンドラインで、変換したいビデオがあるフォルダを指定します。
次のコマンドを実行します。myvideo_original.mp4 は変換したいビデオのファイル名に、myvideo.mp4 は変換後に出力されるファイル名に、それぞれ置き換えてください。

ffmpeg -i myvideo_original.mp4 -profile:v baseline -level 3.0 -an myvideo.mp4

続けて、モバイルユーザーがビデオをダウンロードする前にプレビューできるように、静的なサムネイルを生成します。これを行うには、次のコマンドを実行します。

ffmpeg -i myvideo.mp4 -vframes 1 -f image2 -y myvideo.jpg

ビデオを埋め込む

次のコードを .md ファイルに記入します。ディレクトリ名とファイル名は、使用したいファイルに置き換えてください。

<p>
    <video autoplay loop class="responsive-video" poster="folder/myvideo.jpg">
       <source src="folder/myvideo.mp4" type="video/mp4">
    </video>
</p>

ページとファイルの構造

ドキュメントページの階層は目次ファイル manual/toc.md に記載し、このリポジトリのファイル階層から独立させます。一つの記事をドキュメントの異なる場所に必要に応じていくつも追加することもできますが、分かりやすいように、ドキュメントのページとリポジトリのファイルは同じ階層を保つようにしてください。

ドキュメントに新しいページを追加するには、toc ファイルの適切な場所に新しいエントリを追加してください。

ページの階層

原則としては、ナビゲーションのしやすさを考えて、階層を深くすることは避けたいところです。可能な限り、深さは4段階までに収めることをお勧めします。

はじめに

共通事項

想定する読者

トピック

チュートリアル

2D ゲーム

3D ゲーム

エンジン

トピック

サブカテゴリ

サブトピック

HOWTO

何かをする

ページの命名規則：

HOWTO フォルダの中にあるページの名前は動詞で終わり、目的（「ゲームでポストエフェクトを有効にする」など）を記述するようにしてください。

ページの順序

ページは、アルファベット順に並べる必要はありません。

原則として、新しいページは次のように並べてください。

時系列に従うものはその順番に（「はじめに」/チュートリアル)。
重要なものから順番に（概要ページ→参考文献ページ→HOWTOs）。
重要度が同じであれば、アルファベット順に。

ファイルの階層

記事ファイルは、フォルダを使って整理してください。可能な限りドキュメントと同じ階層にする、ということを尊重しましょう。セクションヘッダーに対応するファイルは、セクション名と同じ名前のフォルダの先頭に置いて、'index.md' という名前にしてください。フォルダ名とファイル名は小文字のみで構成し、単語はダッシュで区切ってください。

記事内で参照されているメディアファイル（画像やビデオ）は 'media' という名前の専用フォルダに入れて、その専用フォルダは、参照している記事と同じフォルダの中に置くようにしてください。

記事内で参照されているコードサンプルファイル（C#、スクリプトなど）は 'code' という名前の専用フォルダに入れて、その専用フォルダは、参照している記事と同じフォルダの中に置くようにしてください。

階層の例：

graphic

index.md

overview.md

media

overview-image1.png

overview-image2.png

overview-video2.mp4

post-effects

index.md

media

post-effect-image1.png

code

post-effect-code.cs

ファイルの名前

ファイル名には、小文字と単語を区切るためのダッシュだけを使用するようにしてください。また、ファイルには可能な限り明示的で分かりやすい名前をつけて、ページ名の末尾には動詞か名詞をつけてください（現在分詞（動詞-ing形）は避けてください）。

私たちの推奨事項は次の通りです。

セクションヘッダーファイルは、常に'index.md' という名前にします。
記事ファイルは、ページのメインタイトルを使った名前にします（空白は除きます）。
メディアファイルは、ファイルの内容に沿ったシンプルな名前にします。

例：

適切
index.md
point-light.md
point-light-diagram.png

不適切
graphics-index.md
PointLightFile1.md
Img20150902.png

書式

テキストスタイル

ドキュメントを読みやすくするために、太字と斜体を適切に使用することが重要です。

重要な単語や手順は、太字で表示します。

UI 要素やウィンドウ名は、斜体で表示します。

用語の定義

記事を書くときに気をつけなければならないのは、ユーザーが知らない用語をきちんと定義することです。基本的には、次の3種類の用語を区別するようにします。

Stride 用語

アセット、ライブスクリプティング、グラフィックコンポジターなどの Stride 特有の用語は、必ず定義する必要があります。用語ごとに専用のページを作る必要はありません。簡単に説明できるのであれば、親ページの中で用語を定義しても構いません。エディタでの記述が終わったら、TODO タグに続けて virgile を追加してください。そして、記事の中で単語が最初に出てくる箇所にそれをリンクしてください。さらに、短い定義をページのメタデータとして追加します。これは後で定義のツールチップを作成するために使用されます。

例：

TODO @virgile: update this

ビデオゲーム用語

ビデオゲーム用語は、ゲームおよびグラフィック業界に特有の用語です。これらの用語は、Stride のドキュメントでは一文で簡潔に定義されていなければなりません。用語が Stride にとって重要なものである場合（例：フォワードレンダリングなど）は、その内容について詳しく説明します。重要でない場合には、外部サイト（wikipedia　など）にリンクすることも可能です。簡潔な定義は、ドキュメントや Game Studio でツールチップを作る際に使われます。ページで最初に出現した箇所にのみ、リンクを貼ってください。

例：

TODO @virgile

Stride では、@forward-rendering か @defferd-rendering のいずれかを選択することができます。（←専用ページへのリンク）

レンダリングモデルにより、[シェーダー](http://wikipedia/shaders)は完全に異なります。（←外部リンク）

より複雑なシェーダーは云々（←2回目にはリンクを貼らない）

注意：想定する読者が「中級者」や「上級者」である場合には、基本的な用語の定義は不要です。

作業固有の用語

作業固有の用語は、開発プロセスにおける役割に特有のものです。これらの用語を定義する必要があるのは、期待される読者が特定の仕事だけでなくより広い範囲に及んでいる場合や、Stride API で用語が使用される場合のみです。ほとんどの場合、外部ページへのリンクを使用してツールチップの定義を追加することで定義します。ページの最初の出現箇所のみ定義する必要があります。

ページの参照

読者を簡単にナビゲーションできるように、できるだけ他のドキュメントページへのクロスリファレンスを追加することをお勧めします。

クロスリファレンスを追加する手順は、次の通りです。

定義しているファイルの先頭に、uid を追加します。
ページにリンクしたい箇所で、@uid ショートカットを使って参照します。

例：

material.md:
---
uid: material
---

# マテリアル
...

sprite.md:
スプライトカラーに関する詳細については、@material を参照してください。

注意：詳細については、DocFX のドキュメントを参照してください。

API リファレンス

API クラス、インターフェース、関数などについて言及する際には、API リファレンスへのリンクを追加しましょう。同じリンクを何度も追加するのを避けるために、関数名を動作動詞に置き換えることができます。

API リファレンスへのリンクは、次のように行います。

@'MyNamespace.MyClass.MyFunction'

例：

サウンドを再生するには、@'Stride.Audio.SoundEffectInstance.Play' 関数を使用します。
再生中の音を再び再生しても効果はありません。停止中の音を再生すると、初めから再生を再開します。

コードリファレンス

サンプルコードを記事に含める際には、可能な限り小さくし、コメントを十分につけて、適切なフォーマットにしてください。記事にコードを挿入するには2つの方法があります。コード内容を適切な書式で記事内に直接追加する方法と、既存のコードファイルへの参照を追加する方法です。お勧めは直接追加する方法ですが、サンプルコードが複数の場所で何度も使用される場合には、コードファイルへの参照を使うことをお勧めします。メンテナンスという意味ではかなり効率的になります。

例：

コードを記事に直接含める場合

```cs
Asset.Unload(asset);
```

外部のコードファイルを参照する場合
[!code-csharp[Main](index.cs?start=5&end=9)] // index.cs ファイルの 5～9 行目が追加されます。

プレースホルダー

分かりやすいように、プレースホルダーはすべて 'My' で始まるようにしてください。

例：

Content.Load("MyFolder/MyAsset");

ラベル

ラベルとは、対象読者のレベルを表すオプション情報です。ラベルは、読者が素早く理解できるように、ページの上部に表示します。

トップレベルのタイトルの直後に配置してください。

ラベルにはいくつかの種類があります。

レベル（初級、中級、上級）を表す label-doc-level
役割（アーティスト、プログラマー、デザイナー）を表す label-doc-audience
プラットフォーム（iOS, Android など）を表す label-doc-platform
その機能が導入されたバージョン（Stride 2.1 など）を表す label-doc-version

例：

# Title

<span class="label label-doc-level">初級</span>
<span class="label label-doc-audience">アーティスト</span>

## 概要

……略……

備考

理解するために必要なくても応用上非常に有用な説明がある場合には、読者が読み飛ばすことができる余分な情報であることがわかるように、備考として追加してください。どのような情報であるかのヒントとして、注意、警告、ヒントなどのいくつかのタイプの備考を使用します。

次の構文を使って、注意、Tips、警告を追加することができます。

> [!NOTE]
> 何らかの役立つ情報

利用可能なタイプは次の通りです。

NOTE
TIP
WARNING

書式は今後も改善されていきますのでご注意ください。

プラットフォーム固有の補足

特定のプラットフォームに固有の説明や備考がある場合には、次のような書式を使って読者に示してください。

次のスタイルクラスのいずれかを追加するだけです。

<div class="doc-android">Android に固有の情報</div>
<div class="doc-iOS">iOS に固有の情報</div>
<div class="doc-Windows">Windows に固有の情報</div>
<div class="doc-Linux">Linux に固有の情報</div>

通知事項

重要な情報が欠けていたり、古くなっていたりする場合には、ページの上部に通知を追加して、読者に知らせるようにしましょう。

ページの上部に、次のタグのいずれかを追加するだけです。

<div class="doc-incomplete"/>  → 現在のページは不完全です。
<div class="doc-outofdate"/> → 現在のページは古くなっています。

これを記述すると、ページタイトルに自動的に 🔧 という文字が追加され、ユーザーに警告が表示されます。

メディア

次の構文を使って、記事にメディアを追加することができます。

![グラフィックコンポーザーダイアグラム](media/graphics-compositor.png)

「グラフィックコンポーザーダイアグラム」は、画像ファイルが見つからなかった場合にフォールバックとして表示されるメッセージです。 'media/graphics-compositor.png'は、ファイルの相対パスです。

メディアファイルを追加する際には、メディアファイルを作成する際に使用した「ソース」ファイルを、必ず一緒に含めるようにしてください。これにより、エンジン側で変更があった場合でも、画像、ダイアグラム、ビデオを迅速に更新することができます。ソースファイルとは、Photoshop ファイル、Visio ファイル、Adobe Premiere ファイルなどを指します。私たちが使うメディアを作成する際には、できるだけ無料または主流のツールを使用するようにしてください。

メディアの作成時には、ソースデータのサイズを変更しないようにしましょう。画面に合わせて縮小する必要がある場合でも、縮小されたメディアを自分で作成することは避けましょう。代わりに、画像は元の解像度のままにしておき、ドキュメントシステムが自動的にユーザーのために適応させるようにしてください。私たちがこれをお願いしているのは、ある時点でドキュメントの幅を変更したり、画像をズームインする方法を提供することになるかもしれないからです。唯一の例外は、重たいビデオです。ページの読み込みを高速化するために、軽くされた動画を作成していただきたいと思います。

ビデオ

できる限り、MP4 形式と H.265 で暗号化された動画をご利用ください。

動画の編集におすすめのソフトは、Adobe After Effect です。

画像

負荷の高い高解像度画像は JPEG 形式で、それ以外の画像（おそらくほとんどの画像がそうでしょう）は PNG 形式でお願いします。

ソースファイルは、Photoshop, GIMP, Paint.NET の形式が望ましいです。

ダイアグラム

ダイアグラム（図）は、PNG 形式、またはベクター画像で描画してください。ドキュメントシステムは画像のサイズを自動的に調整しますので、サイズが調整されても図に含まれるテキストが読み取れるようにしてください。図が大きすぎて縮小できない場合は、読者がクリックしたときにフルサイズで表示するようにしてください。

次の構文を使用して、図をクリック可能にすることができます。 TODO virgile

図は、Visio などの標準的な画像編集ツールで作成してください。

表（テーブル）

Markdown の構文に従って、ドキュメントに表（テーブル）を追加することができます。表は情報を見やすくすることができますが、時には適切に表示されないことがあります。そのため、ページを投稿する前に、スマートフォンのような小さな解像度の画面で試してみてください。

箇条書き（リスト）

可能な限り、リストの項目には全文よりも短いフレーズを使用してください。そうすることで読みやすくなり、読む速度がスピードアップします。各項目は、大文字で始めてください。

ステップ・バイ・ステップのプロセスを示すとき、または順序が重要なときは、箇条書きリストではなく順序付きのリストを使用してください。

例：

適切

リストの使い方：

それぞれの最初の文字を大文字にする

短いフレーズで書く

不適切

リストの正しくない使い方：

各項目の最初の文字を大文字にする必要があります。

箇条書きを使うメリットを減らすような長文を書いてはいけません。

ヘッダー

ヘッダの作成には、Markdown の '#' 記号を使用します。ページのトップタイトルのみ、h1 スタイルにしてください。他のすべてのタイトルはサブタイトルであり、h2～に整形してください。

可能な限り、ヘッダー文は短くシンプルなものにしてください。また、可能な限り、ヘッダーの末尾には動詞や名詞を使用してください。現在分詞（動詞-ing形）は避けてください。

例：

# トップタイトル：ヘッダーを書く方法
___
## サブタイトルを書く
### サブサブフォルダを書く
### サブサブフォルダを書く
## サブフォルダを書く

大文字表記

タイトルが完全な文章に近い場合には、最初の単語の最初の文字だけを大文字にしてください。タイトルがいくつかの単語（1～5 個）で構成されている場合には、それぞれの単語の数文字を大文字にしてください。

ある事実を強く主張したいとき以外は、文中の単語をすべて大文字にしてはいけません。一般的に使われる単語は次の通りです。
ONLY, DO NOT, YES, NO, MAKE SURE TO, BE CAREFUL (TO/OF)

FilesExpand file tree

GUIDELINES.jp.md

Latest commit

History

GUIDELINES.jp.md

File metadata and controls

ガイドライン

ビデオのエンコード方法

ビデオを埋め込む