Jump to content

説明文書/スタイル ガイド

From mediawiki.org
This page is a translated version of the page Documentation/Style guide and the translation is 33% complete.

概要

このスタイル ガイドは、MediaWiki やその他の技術系の空間での技術文書の執筆と編集についての指針を提供します。 明確で簡潔な技術文書を、平易な言葉で書くためのヒントが提供されています。一般的な技術文書の執筆と編集に関する追加のリソースへのリンクも提供されています。

いい技術文書は、人々がウィキメディアのプロジェクト群に貢献することを容易にします。 技術文書の作成や編集において、貢献者や読者のスキルや経験が異なる場合には、明確な標準やスタイルガイドに従うことが重要です。 自分自身を執筆者と考えるかどうかにかかわらず、あなたの貢献は必要であり、評価されています。

英語版ウィキペディアのスタイル マニュアル

日本語版ウィキペディアのスタイル マニュアルは、一般的な執筆トピック (句読点など) を詳しく説明し、他のスタイル ガイドの要点をまとめています。 ローカル ウィキにより具体的なガイドラインがない場合、ウィキメディアのプロジェクト群全体で英語の技術文書を書いたり編集する人々にとって有用な参考資料になるでしょう。

このページでは、技術文書の執筆に入門するための基本的なガイドラインとヒントが提供されています。ウィキペディアのスタイル マニュアルではカバーされていない技術文書に特化した情報も含まれています。

読者とコンテンツ

Writing for technical audiences

執筆する前に、対象読者を考慮します:

  • 誰がこの技術文書を読むのか?
  • どこから来ているのか?
  • あなたが提示する概念についてどの程度知っているのか?
  • 理解するために必要なことは何か?

読者について理解が深まれば、何を伝える必要があるかをより良く把握できるようになります。

  • 読者が高度な技術的知識を持ち、説明するプロセスについてよく知っている場合、基本的な概念を説明する必要はありません
  • 読者が学習中または不慣れの場合は、説明に基本的な概念の説明を含めて、追加情報へのリンクを提供してください。

目的を持って書く

あなたの技術文書が果たす目的は何でしょう?文書を書く理由は数多くあります。 始める前に「なぜ」書くのか、そして何がゴールなのか知ることが役に立ちます。

  • 誰か、新規参加者などに、プロセスやコンセプトを教えるためですか?
  • 誰かにプロセスに従う方法を示すためですか?
  • コンセプトやプロセスについて背景や文脈を提示することを意図していますか?
  • 情報を提供することを目的とした参考文献ですか?

文脈の中で書く

When deciding what to write and how to frame it for your reader, it can help to define a context or occasion for your writing. Your communication takes place in the context of a bigger situation. The context may be bounded by the era you are writing in, the type of technology available, your geographical location and culture, or the current culture and communication styles of your readers. The occasion may be personal and arise from the situation that motivated you to create or improve a piece of documentation.

For example, if you are writing technical documentation for Wikimedia projects, consider the culture created by the individuals who participate in those projects. How could you best position your writing within the context of this community and its culture to create the most meaningful and useful technical documentation?

ユーザーテストとフィードバック

Create technical documentation to communicate ideas and concepts to a real audience of users. Naturally, this audience should play a critical role in how the documentation is shaped and reshaped. Think about ways you can gather information about your users' experiences. Take some time to answer the following questions:

  • Does your documentation include a mechanism for feedback?
  • Can you engage in timely conversations with the audience to make improvements?
  • Can you use forums like Stack Overflow or mailing lists to check if your document answers the most common questions people have about your specific topic?

明瞭さと一貫性

Clarity and consistency makes it easier to access, read, and create technical documentation across MediaWiki/Wikimedia projects. Technical documentation is written for a wide audience and edited by a variety of contributors.

Voice, tone, grammar usage, style, and format should be consistent across technical documentation and similar content collections. This helps readers learn how to navigate information and makes it easier for contributors to understand how to edit and add new information.

文書の種類を決める


Identify your main audience, purpose, and context first to decide on the type of document you will create.

Example Audience 目的[1] Potential Document Types
Newcomer interested in learning how to become a Toolforge user To learn Tutorial, FAQ, Getting Started guide Cloud VPS and Toolforge FAQ
Experienced technical contributor trying to work through a known problem To achieve a goal Walk-through, How-To guide My First Flask OAuth Tool
Individual trying to understand the history of ORES and how it evolved To understand Explanatory article, blog post, "overview" Artificial intelligence service “ORES” gives Wikipedians X-ray specs to see through bad edits
A person looking for a definition of SSH keys To inform Reference guide, glossary 用語集

言語


This section briefly mentions some topics worth exploring elsewhere in more detail. Always check your words and expressions against these criteria on Wiktionary: Wiktionary entries cover hundreds of languages, explicitly state the grammatical and lexical features of words and their declensions, provide detailed context labels (including about jargon, UK vs. USA English) and expose how translatable terms are in hundreds of other languages.

平易な英語

Please remember: many visitors to these pages are not native English speakers.

For documentation written in English, Plain English (also called plain language) works best. Clear writing is the most understandable by diverse audiences, and is also easiest to translate. There are a number of good tools for checking your writing, at Tech News' Writing Guidelines on Meta-Wiki.

  • Avoid ambiguity, jargon, and vague or complex wording.
  • Use words your audience will understand, and enough words to convey your message.
  • Define terms that may not be obvious to individuals who are new to the subject matter you are writing about.
  • Keep paragraphs and sentences short and concise.
  • Use contractions or don't. Be consistent.

Voice and tone

MediaWiki is a place where anyone can edit. Thus, it can be difficult to maintain a consistent voice and tone in the documentation.

Consider using these elements in your writing:

Voice and tone What this means Instead of this Try This
Friendly Technical documentation does not need to sound academic or dry. Write to your audience as if they are there in person. Before beginning, the user must create an account. Start by creating an account.
Professional Technical documentation can be friendly, but should remain professional. Use 包括的言語 . Don't make a bazillion changes. Try to make minimum changes.
Positive Avoid using negative sentence constructions. Explain things in terms of what to do. It is harder to mentally parse a complex negative sentence! N won't happen, if you don't XYZ. To make N happen, do XYZ.
Active Try to use active voice, except when diplomacy calls for passive voice. The extension must be registered. You must register the extension.
Non-gendered Adopt gender-inclusive language. Assume your audience comprises all gender identities. When he clicks Save When the user clicks Save
Inclusive Use alternatives to common words or phrases that may unintentionally reinforce inappropriate stereotypes. This UI is crazy. This UI could be improved.
Free of frustration Avoid terms like "easy" and "simple" which can be frustrating for less tech-savvy users. Simply create a user account. Create a user account.
Free of colloquialisms It can be confusing to use colloquialisms, jokes, puns, or turns of phrase that non-native English speakers or individuals from other regions might not easily understand. Creating a user account is a piece of cake. Creating a user account requires two steps.
This is not meant to be an exhaustive list or a strict set of rules.

観点

The following guidance overrides the general Wikipedia style guidelines for pronouns, but only for technical documentation.
  • Use second person ("You" or assumed "You") when addressing your audience.
  • Avoid first person ("I" or "we"), unless you are writing a FAQ with questions asked from the first person perspective.
  • Use an imperative mood for most documentation focused on goals or process.

日付

  • Always use the full, four-digit year.
  • Use absolute dates ("in May 2037") instead of relative dates ("next year in May").
  • Avoid adding dates that will require regular manual updates. Example: Write {{#time: Y }} instead of 2024 when referring to the current year, no matter what year it is currently.

ページの構成

概要

All pages should include an overview section (also called the Lead section) that explains:

  1. ページの目的
  2. Audience of the page
  3. Prerequisites the reader will need to know before proceeding (Ex. a working knowledge of Python)
  4. Software or tools the reader will need to complete the processes or tasks outlined on the page (Ex. Java installed)
  5. Use case, case study, a practical understanding of the product, service or tool in action. (optional)

目次

  • 情報に容易にアクセスできるように、各ページは目次を含むべきです。

タイトルと見出し

情報の流れ

Technical documentation pages should follow a consistent pattern across content collections.

An ideal pattern for each page might be:

  • ページ名
  • 導入/概要
  • 見出し
    • コンテンツ
      • 必要なら小見出し
        • コンテンツ

テキスト整形

メインのページ: Help:Formatting

整形コード例とその他の技術的要素

Formatting distinguishes code and other technical elements from regular text.

目的 ウィキ・マークアップ 結果 状況
Code ‎<code>code‎</code> code ウィキテキストのマークアップを含む、コードの短い文字列に対して使う。

Within ‎<code>...‎</code>, use ''italics'' to indicate variables and sample names so users know what to replace.

Syntax highlight
<syntaxhighlight lang="css">
.citation {
    margin: 0;
}
</syntaxhighlight>

Text before <syntaxhighlight lang="css" inline>.foo {margin: 0;}</syntaxhighlight> text after.

.citation {
    margin: 0;
}

Text before .foo {margin: 0;} text after.

Use the ‎<syntaxhighlight lang="...">...‎</syntaxhighlight> tag to document a few lines of code, and preserve whitespace and linebreaks. The inline attribute allows using it within an existing paragraph.

Note you cannot use italic in the middle of a <syntaxhighlight lang="foo">...</syntaxhighlight> block, so you have to fall back to YOURPASSWORD or The_page_title to indicate variables.

See Extension:SyntaxHighlight for more details.

Preformatted ‎<pre>preformatted text
      with indent‎</pre>
preformatted text
      with indent
Same as above (preserve whitespace and linebreaks), but without coloring.
Keyboard input ‎<kbd>keyboard 123‎</kbd> (vs keyboard 123) keyboard 123 (vs keyboard 123) Use ‎<kbd>...‎</kbd> for actual keyboard input - the text a user types into an input field or at a terminal command line. It displays in plain monospace.
Variables ‎<var>variable‎</var>
''italics''
variable

italics

Use italics for variables like message-key-name and sample names like My page title.

Do not use punctuation such as <YOURPASSWORD>, because readers don't know the angle brackets are noise and will type them.

Bold
'''bold'''
bold Generally only used for the first instance of the page-title, and for rare emphasis of keywords to enable easier skimming of lists or paragraphs.
Sometimes bold is overused for emphasis. You may consider using a template instead, e.g. {{Caution }}, {{Note }}, or {{Warning/core }}.
Quotations "quotation marks"

Text before

‎<blockquote>blockquote‎</blockquote>

Text after

"quotation marks" Text before

blockquote

Text after
Use quotation marks for brief pieces of content quoted from other sources.

Use blockquote for longer pieces of content.

Abbreviations JavaScript (JS)

<abbr title="JavaScript">JS</abbr>

JavaScript (JS)

JS

You should define abbreviations the first time they are used. Use either plain text and parentheses, or the HTML abbr tag.
Keypress {{Key press }} Ctrl+⇧ Shift+I Showing specific keyboard presses or combinations. Extensive examples in ビジュアルエディター/ポータル/キーボードショートカット .

Note: This template might not exist on other wikis.

Button {{Button }} プレビューを表示 Showing UI buttons that need to be clicked on.

Note: This template might not exist on other wikis.


リンク

メインのページ: Help:Links
種類 目的 実施方法
ローカル 他の MediaWiki ページへリンクする
  • [[Foo]]
  • [[Foo|Bar]]
MediaWiki
翻訳対象 他の翻訳された MediaWiki ページへリンクする [[Special:MyLanguage/Foo|Foo]] 貢献する方法
インターウィキ 別のウィキメディアプロジェクトに属するページへリンクする
  • [[phab:T2001]] タスクとプロジェクトタグについて
  • [[mail:wikitech-l]] メーリングリストについて
  • [[w:en:foobar]] 英語版ウィキペディアの記事へ
  • [[wikitech:foobar]] for details about the WMF cluster
  • [[gerrit:604435]] for change requests in Gerrit
Documentation page on Wikipedia
外部 外部ページへリンクする [https://www.example.org Example.org] Example

テンプレート


Templates are often used on MediaWiki.org pages. Templates can help to maintain consistency and can make it easier to translate information.

Below are some common templates.

ページ整形用のテンプレート

MediaWiki コアおよび Git ソース用のテンプレート

Phabricator用のテンプレート

  • {{Ptag }} - for the top-right-of-page Phabricator project tag
  • {{Tracked }} - for the related Phabricator task

その他の有用なテンプレート

  • {{irc|wikimedia-tech}} - for IRC link
  • {{Key press }} - for, e.g. Ctrl+⇧ Shift+I, and {{Button }} for, e.g. プレビューを表示
  • {{ApiEx }} - for api.php request URLs
  • {{Api help }} - to transclude generated API documentation
  • {{Wg }} - for global variables
  • {{Tag }} - for a quick way to mention an XML-style tag in a preformatted way

翻訳

All pages on mediawiki.org are candidates for translation into multiple languages. MediaWiki.org is a multilingual wiki, it uses the Translate extension to present alternative translations and manage the translation of pages.

  • If a page has been translated, then click 'Edit source' to edit the entire page.
Wrongly placed translation tag markers around section headings can confuse section editing, and as of July 2015 VisualEditor does not understand the following tags: ‎<languages>, ‎<translate>, ‎<tvar>
  • Do not copy and paste existing markup.
If in doubt, focus on writing a good text and let someone else handle the Translate markup.

関連項目

脚注