en to ja translation catalogue (2879 entries)

en: Synopsis
    --------
ja: 概要
    --------

en: YARD is a documentation generation tool for the Ruby programming language.
    It enables the user to generate consistent, usable documentation that can be
    exported to a number of formats very easily, and also supports extending for
    custom Ruby constructs such as custom class level definitions. Below is a
    summary of some of YARD's notable features.
ja: YARDはプログミング言語Rubyのドキュメント生成ツールである。
    ユーザーが一貫性のあるドキュメント作成を可能にし、
    いくつかの書式へ簡単にエキスポートできる。
    又、カスタム定義によってRubyのカスタム構文用に
    拡張することをサポートもする。
    下はYARDの著名な機能の要約となる。

en: Feature List
    ------------
ja: 機能リスト
    ------------

en: **1. RDoc/SimpleMarkup Formatting Compatibility**: YARD is made to be compatible
    with RDoc formatting. In fact, YARD does no processing on RDoc documentation
    strings, and leaves this up to the output generation tool to decide how to
    render the documentation.
ja: ** 1. RDoc/SimpleMarkup書式との両立**: YARDはRDocの書式と両立する。
    実際には、YARDはRDocドキュメント文字列の処理を行わない。
    それは、後でドキュメント作成を表示する方法を選択する為、
    その文字列を残している。

en: **2. Yardoc Meta-tag Formatting Like Python, Java, Objective-C and other languages**:
    YARD uses a '@tag' style definition syntax for meta tags alongside  regular code
    documentation. These tags should be able to happily sit side by side RDoc formatted
    documentation, but provide a much more consistent and usable way to describe
    important information about objects, such as what parameters they take and what types
    they are expected to be, what type a method should return, what exceptions it can
    raise, if it is deprecated, etc.. It also allows information to be better (and more
    consistently) organized during the output generation phase. You can find a list
    of tags in the {file:docs/Tags.md#taglist Tags.md} file.
ja: ** 2. Python, Java, Objective-Cや他の言語のようなYardocのメタタグフォーマット **:
    YARDは通常のコードのドキュメントの側にメタタグ用の'@tag'スタイルの定義構文を使う
    これらのタグは幸いなことにRDoc形式にフォーマットされたドキュメントと並んで配置する事ができる
    しかしオブジェクトについて重要な情報を提供する為に更に一貫して便利な方法を提供する。
    それらの何らかのパラメーターとそれらの何らかの期待される型を取得するには、
    どの型のメソッドを返さなければならないか、
    どの例外を上げることができるか、
    もしそれが重複した場合は,, etc..
    それは出力生成段階の間によりよく(そして一貫して)整理された情報を受け入れる
    {file:docs/Tags.md#taglist Tags.md} ファイルでタグのリストについて紹介している。

en: YARD also supports an optional "types" declarations for certain tags.
    This allows the developer to document type signatures for ruby methods and
    parameters in a non intrusive but helpful and consistent manner. Instead of
    describing this data in the body of the description, a developer may formally
    declare the parameter or return type(s) in a single line. Consider the
    following method documented with YARD formatting:
ja: YARDは特定のタグを用い省略可能な"型"の宣言をサポートもする。
    これにより開発者はRubyメソッド用や、
    煩わしくなく、しかし役に立つパラメータや、
    一貫性のある形式を型の用法として記述可能になる。
    説明の中にこのデータを記述する代わりに、
    開発者は、1つの行の中でパラメータやリターンタイプを形式的に宣言できる。
    YARDの書式を使用した次のメソッドの記述を考えてみる。

en:      # Reverses the contents of a String or IO object.
         #
         # @param [String, #read] contents the contents to reverse
         # @return [String] the contents reversed lexically
         def reverse(contents)
           contents = contents.read if respond_to? :read
           contents.reverse
         end
ja:      # 文字列やIOオブジェクトの内容を逆にする
         #
         # @param [String, #read] 逆にするためのコンテンツを入れる
         # @return [String] 逆になった単語のコンテンツ
         def reverse(contents)
           contents = contents.read if respond_to? :read
           contents.reverse
         end

en: With the above @param tag, we learn that the contents parameter can either be
    a String or any object that responds to the 'read' method, which is more
    powerful than the textual description, which says it should be an IO object.
    This also informs the developer that they should expect to receive a String
    object returned by the method, and although this may be obvious for a
    'reverse' method, it becomes very useful when the method name may not be as
    descriptive.
ja: 上記の@paramタグによって、contentsのパラメータが
    Stringまたは何らかのオブジェクトのいずれかを
    'read'メソッドに返すことが分かる。
    それは原文の説明よりももっと強力な
    IOオブジェクトになると言える。
    これは開発者達がメソッドによって返された、
    Stringオブジェクトを受け取ることを期待することや、
    この場合は"reverse"メソッドの目的が明らかとはいえ、
    メソッド名が説明を含んでいない時にとても便利という事を
    意味している。

en: **3. Custom Constructs and Extensibility of YARD**: YARD is designed to be
    extended and customized by plugins. Take for instance the scenario where you
    need to document the following code:
ja: ** 3. YARDのカスタムコンストラクタと拡張性 **: YARDは
    プラグインによって拡張やカスタマイズする為に設計されている。
    例えばあなたが次のコードのドキュメントの場所を必要とするシナリオを考える。

en:     class List
          # Sets the publisher name for the list.
          cattr_accessor :publisher
        end
ja:     class List
          # リスト用の発行者名を設定する
          cattr_accessor :publisher
        end

en: This custom declaration provides dynamically generated code that is hard for a
    documentation tool to properly document without help from the developer. To
    ease the pains of manually documenting the procedure, YARD can be extended by
    the developer to handle the `cattr_accessor` construct and automatically create
    an attribute on the class with the associated documentation. This makes
    documenting external API's, especially dynamic ones, a lot more consistent for
    consumption by the users.
ja: このカスタム宣言は動的に生成されるコードを提供する。
    それは開発者からの助けなしで正確なドキュメントを
    ドキュメント作成ツールで作るのが困難な為である。
    手書きでドキュメント作成する苦労が楽になるように、
    YARDは `cattr_accessor` コンストラクタを操作する。
    又、関連するドキュメントとクラスの属性を自動的に生成するように、
    開発者によって拡張できる。
    この拡張によって、ユーザーによって使用する多くの一貫性のある動的な
    ドキュメント作成の外部のAPIを作れる。

en: YARD is also designed for extensibility everywhere else, allowing you to add
    support for new programming languages, new data structures and even where/how
    data is stored.
ja: YARDはどこでも拡張できるように設計されている。
    新しいプログラム言語や新しいデータ構造や
    どこにどのようにデータを格納するかといったサポートを追加できる。

en: **4. Raw Data Output**: YARD also outputs documented objects as raw data (the
    dumped Namespace) which can be reloaded to do generation at a later date, or
    even auditing on code. This means that any developer can use the raw data to
    perform output generation for any custom format, such as YAML, for instance.
    While YARD plans to support XHTML style documentation output as well as
    command line (text based) and possibly XML, this may still be useful for those
    who would like to reap the benefits of YARD's processing in other forms, such
    as throwing all the documentation into a database. Another useful way of
    exploiting this raw data format would be to write tools that can auto generate
    test cases, for example, or show possible unhandled exceptions in code.
ja: **4. 未加工データの出力**: YARDはオブジェクトのドキュメントを未加工のままデータ(ダンプした名前空間)出力する。後で生成する時や、コードを等しく調査する時は再ロードされる。
    つまり、開発者の誰もが何らかのカスタム書式のように出力生成を実行する為に、未加工データを使う。例えば、YAMLのように。
    YARDはXHTMLスタイルドキュメント出力もコマンドライン(テキストベース)も
    (もしかしたらXMLも)サポートを計画しているので、
    全てのドキュメントをデータベースへ投げておけば、
    将来、他の型でもYARDの処理の恩恵を受けようと考えている人にとっては、
    役立つかもしれない。
    この未加工データの書式を利用する他の有用な方法として、
    自動生成テストケースができるツールを書く為や、
    コードの未処理例外を明らかにすること、などがある。

en: **5. Local Documentation Server**: YARD can serve documentation for projects
    or installed gems (similar to `gem server`) with the added benefit of dynamic
    searching, as well as live reloading. Using the live reload feature, you can
    document your code and immediately preview the results by refreshing the page;
    YARD will do all the work in re-generating the HTML. This makes writing
    documentation a much faster process.
ja: **5. ローカルドキュメントサーバー**:
    YARDは動的な検索も再ロードの利点も用い
    プロジェクトやインストール済みのgem( `gem server` と同様)用のドキュメント作成を提供する。
    live reload機能によって,あなたのコードを記述したり
    ページをリフレーシュする事によって結果をすぐにプレビューできる
    YARDはHTML再生成の全ての仕事をする
    これによりドキュメントの作成をより高速のプロセスで行える。

en: ## Installing
ja: ## インストール

en: To install YARD, use the following command:
ja: YARDをインストールする為に次のコマンドを使う。

en: (Add `sudo` if you're installing under a POSIX system as root)
ja: (もしPOSIXシステムのルート下でインストールしている場合、sudoを追加する)

en: Alternatively, if you've checked the source out directly, you can call
    `rake install` from the root project directory.
ja: 上のコマンドの代わりに、もしソースを直接チェックアウトしたならば、
    あなたはプロジェクトのルートディレクトリから `rake install` を行う事ができる

en: **Important Note for Debian/Ubuntu users:** there's a possible chance your Ruby
    install lacks RDoc, which is occasionally used by YARD to convert markup to HTML.
    If running `which rdoc` turns up empty, install RDoc by issuing:
ja: **Debian/Ubuntuユーザーへの重要な注意:**
    RubyがRDocなしでinstallされる可能性がある。
    RDocはYARDによってマークアップをHTMLに変換する為に時々使われるので、
    もし `which rdoc` コマンドでパスが存在しない場合は、次のコマンドでRDocをインストールする。

en: ## Usage
ja: ## 使用法

en: There are a couple of ways to use YARD. The first is via command-line, and the
    second is the Rake task.
ja: それらYARDを使うにはいくつかの方法がある。
    最初はコマンドライン経由で、もうひとつはRake taskという方法がある。

en: **1. yard Command-line Tool**
ja: **1. yardのコマンドラインツール**

en: YARD comes packaged with a executable named `yard` which can control the many
    functions of YARD, including generating documentation, graphs running the
    YARD server, and so on. To view a list of available YARD commands, type:
ja: YARDは実行可能な `yard` という名前と一緒にパッケージが入っている。
    ドキュメントの生成や、グラフ、YARDサーバーを起動などを含み
    たくさんの機能を制御できる。
    利用可能なYARDのコマンドの一覧を表示するには、以下をタイプする。

en: Plugins can also add commands to the `yard` executable to provide extra
    functionality.
ja: プラグインは追加の機能を提供する為に実行可能な `yard` コマンドを追加できる。

en: ### Generating Documentation
ja: ### ドキュメントを生成する

en: The most common command you will probably use is `yard doc`, or `yardoc`. You
    can type `yardoc --help` to see the options that YARD provides, but the
    easiest way to generate docs for your code is to simply type `yardoc` in your
    project root. This will assume your files are
    located in the `lib/` directory. If they are located elsewhere, you can specify
    paths and globs from the commandline via:
ja: 恐らく最も使用される一般的なコマンドは `yard doc` 、または `yardoc` となるだろう。
    YARDが提供するオプションを見るには `yardoc --help` をタイプする事で表示できる。
    でも、ドキュメントを生成するのに最も簡単な方法は、
    あなたのプロジェクトのルートで `yardoc` をタイプする方法である。
    これはあなたのファイルが `lib/` ディレクトリの中で示されるとみなす。
    もし他の場所にあるなら、次のようにコマンドラインからパスとglobを指定する:

en: The tool will generate a `.yardoc` file which will store the cached database
    of your source code and documentation. If you want to re-generate your docs
    with another template you can simply use the `--use-cache` (or -c)
    option to speed up the generation process by skipping source parsing.
ja: このツールは `.yardoc` ファイルを生成する。それは
    あなたのソースコードとドキュメントをキャッシュしたデータベースを格納する。
    もしあなたが他のテンプレートと共にドキュメントを再生成したいなら、
    単に `--use-cache` (or -c) オプションを使えばよい。
    ソースの解析をスキップする事によって生成プロセスをスピードアップする。

en: YARD will by default only document code in your public visibility. You can
    document your protected and private code by adding `--protected` or
    `--private` to the option switches. In addition, you can add `--no-private`
    to also ignore any object that has the `@private` meta-tag. This is similar
    to RDoc's ":nodoc:" behaviour, though the distinction is important. RDoc
    implies that the object with :nodoc: would not be documented, whereas
    YARD still recommends documenting private objects for the private API (for
    maintainer/developer consumption).
ja: YARDはデフォルトでpublicな可視性の中のコードだけを記述する。
    `--protected` や `--private` オプション引数の追加によって
    protectedとprivateなコードを記録できる。
    さらに、 `--no-private` の追加によって、
    `@private` メタタグを持った何らかのオブジェクトの無視もできる。
    区別は重要であるものの、これはRDocの":nodoc:"の挙動と似ている。
    RDocはオブジェクトと共に:nodoc:は記録されないことを暗示する。
    ところが、YARDは今もなおprivate APIの為に
    privateなオブジェクトのドキュメント作成を
    推奨する。(メンテナーや開発者が利用する為に)

en: You can also add extra informative files (README, LICENSE) by separating
    the globs and the filenames with '-'.
ja: globとファイル名と共に'-'で区切ることによって、
    追加の情報ファイル(README, LICENSE)を追加もできる。

en: If no globs precede the '-' argument, the default glob (`lib/**/*.rb`) is
    used:
ja: もしglob無しで、'-'引数が先行する場合、デフォルトのglobは( `lib/**/*.rb` )を使う。

en: Note that the README file can be specified with its own `--readme` switch.
ja: 次の事に留意する。READMEファイルは自身の`--readme`引数と共に指定される。

en: You can also add a `.yardopts` file to your project directory which lists
    the switches separated by whitespace (newlines or space) to pass to yardoc
    whenever it is run. A full overview of the `.yardopts` file can be found in
    {YARD::CLI::Yardoc}.
ja: あなたはあなたのプロジェクトディレクトリに `.yardopts` を追加することもできる。
    これは起動する時に毎回、スペースによって区切られた引数のリストをyardocに渡す。
     `.yardopts` ファイルの全ての概要は、 {YARD::CLI::Yardoc} で見つけることができる。

en: ### Queries
ja: ### クエリー

en: The `yardoc` tool also supports a `--query` argument to only include objects
    that match a certain data or meta-data query. The query syntax is Ruby, though
    a few shortcuts are available. For instance, to document only objects that have
    an "@api" tag with the value "public", all of the following syntaxes would give
    the same result:
ja: `yardoc` ツールは、 `--query` 引数をサポートもする。
    これはマッチするいくらかのデータやメタデータクエリーのオブジェクトだけ含んでいる。
    クエリーの構文はRubyで、いくつかのショートカットが利用可能。
    例えば、"@api"タグと"public"な値を持つオブジェクトだけを記述するには、
    次のようになる。(全て同じ結果となる。)

en: Note that the "@tag" syntax returns the first tag named "tag" on the object.
    To return the array of all tags named "tag", use "@@tag".
ja: 次の事に留意する。
    "@tag"構文は、オブジェクトの最初に"tag"と名付けられたタグを返す。
    全ての"tag"と名付けたタグの配列を返すには、"@@tag"を使う。

en: Multiple `--query` arguments are allowed in the command line parameters. The
    following two lines both check for the existence of a return and param tag:
ja: 複数の`--query`引数はコマンドライン引数の中で許可される。
    次の2行は両方とも実際の返り値とparamタグをチェックする。

en: For more information about the query syntax, see the {YARD::Verifier} class.
ja: さらなるquery構文の情報については、 {YARD::Verifier} クラスを参照する。

en: The second most obvious is to generate docs via a Rake task. You can do this by
    adding the following to your `Rakefile`:
ja: もう一つの方法として、Rakeのタスクを介してドキュメントを生成する。
    あなたの `Rakefile` に次の内容を追加することによって作成できる:

en: both the `files` and `options` settings are optional. `files` will default to
    `lib/**/*.rb` and `options` will represents any options you might want
    to add. Again, a full list of options is available by typing `yardoc --help`
    in a shell. You can also override the options at the Rake command-line with the
    OPTS environment variable:
ja: `files` も `options` の設定も、省略可能。
    `files` は `lib/**/*.rb` にデフォルトで設定される、
    そして `options` は追加したいオプションを表している。
    さらに、オプションの全てのリストは、
    シェルで `yardoc --help` を
    タイプすることによって利用可能。又、
    RakeコマンドラインとOPTS環境変数でoptionsを上書きできる。

en: **3. `yri` RI Implementation**
ja: **3. `yri` RIの実装**

en: The yri binary will use the cached .yardoc database to give you quick ri-style
    access to your documentation. It's way faster than ri but currently does not
    work with the stdlib or core Ruby libraries, only the active project. Example:
ja: yriコマンドはドキュメントをri-styleで速くアクセスする為に、
    キャッシュした.yardocデータベースを使うだろう。
    これはriよりも速い方法だが、しかし、今の所、
    stdlibかコアRubyライブラリ、アクティブプロジェクトだけでしか
    動かない。
    使用例:

en: Note that class methods must not be referred to with the "::" namespace
    separator. Only modules, classes and constants should use "::".
ja: 次の事に留意する。
    クラスメソッドは、"::"ネームスペース区切りとともに参照されるべきではない。
    モジュールだけクラスと定数は"::"を使うべきである。

en: You can also do lookups on any installed gems. Just make sure to build the
    .yardoc databases for installed gems with:
ja: あなたはインストール済みの任意のgemを検索できる。
    以下はインストール済みのgemとともに.yardocデータベースをビルドする。

en: If you don't have sudo access, it will write these files to your `~/.yard`
    directory. `yri` will also cache lookups there.
ja: sudo権限をもっていない場合は、あなたの `~/.yard` ディレクトリにこれらを記述する。
     `yri` はそれらをcache検索する。

en: **4. `yard server` Documentation Server**
ja: **4. `yard server` ドキュメント作成サーバー**

en: The `yard server` command serves documentation for a local project or all installed
    RubyGems. To serve documentation for a project you are working on, simply run:
ja: `yard server` コマンドは、
    ローカルプロジェクトやインストール済みのRubyGems用の
    ドキュメント作成を提供する。
    ドキュメント作成を提供するには、
    あなたが取り組んでいるプロジェクト上で次のコマンドを単に実行する。

en: And the project inside the current directory will be parsed (if the source has
    not yet been scanned by YARD) and served at [http://localhost:8808](http://localhost:8808).
ja: 上のコマンドによってプロジェクトの現在のディレクトリ内部は解析される。
    (YARDによってスキャンされたにもかかわらずソースがなかった場合)
    そして [http://localhost:8808](http://localhost:8808) で提供される。

en: If you want to serve documentation on a project while you document it so that
    you can preview the results, simply pass `--reload` (`-r`) to the above command
    and YARD will reload any changed files on each request. This will allow you to
    change any documentation in the source and refresh to see the new contents.
ja: 結果をプレビューできるようにドキュメント化しながら、
    プロジェクトのドキュメント作成を提供したいなら、
    上のコマンドに単純に `--reload` (`-r`)を渡す。
    YARDはそれぞれのリクエストのどれかの変更があったファイルを再ロードする。
    これはあなたがソースの中のドキュメントの変更や
    新しいコンテンツを見るのにリフレッシュを可能にする。

en: To serve documentation for all installed gems, call:
ja: 全てのインストール済みのgemのドキュメント作成を提供するには、
    次のコマンドを入力する。

en: This will also automatically build documentation for any gems that have not
    been previously scanned. Note that in this case there will be a slight delay
    between the first request of a newly parsed gem.
ja: これは自動的に以前にスキャンされていないあらゆるgemのドキュメントをビルドする。
    次の事に留意する。
    この場合、新たに解析されたgemの最初の要求の間にわずかな遅延が発生する。

en: **5. `yard graph` Graphviz Generator**
ja: **5. `yard graph` はGraphvizのジェネレーター**

en: You can use `yard graph` to generate dot graphs of your code. This, of course,
    requires [Graphviz](http://www.graphviz.org) and the `dot` binary. By default
    this will generate a graph of the classes and modules in the best UML2 notation
    that Graphviz can support, but without any methods listed. With the `--full`
    option, methods and attributes will be listed. There is also a `--dependencies`
    option to show mixin inclusions. You can output to stdout or a file, or pipe directly
    to `dot`. The same public, protected and private visibility rules apply to `yard graph`.
    More options can be seen by typing `yard graph --help`, but here is an example:
ja: あなたのコードの図を生成する為に `yard graph` を利用できる。
    これにはもちろん、[Graphviz](http://www.graphviz.org)と `dot` が必要となる。
    デフォルトでこれは、Graphvizのサポートできる最高のURL2表記で
    クラスやモジュールの図を生成する。しかし、記載されたメソッドは生成しない。
    `-- full` オプションを用いメソッドと属性が記述される。
    mixinで含んでいるものを一覧する為に `--dependencies` オプションもある。
    標準出力やファイルに出力したり、また `dot` に直接パイプできる。
    同じpublic,protectedとprivateの可視性規則は、 `yard-graph` に適用される。
    詳細なオプションは、 `yard-graph --help` とタイプすることによって見ることができる。
    次に例がある:

en: ## Contributors
ja: ## 貢献者へ

en: Special thanks to all contributors for submitting patches. A full list of
    contributors including their patches can be found at:
ja: パッチの申請をした全ての貢献者へ本当に感謝する。
    これらのパッチを投げた全ての貢献者のリストは次で見れる:

en: CodeObjects Architecture
ja: コードオブジェクト構造

en: # CodeObjects Architecture
ja: # コードオブジェクト構造

en: Code objects are Ruby objects that describe the code being documented. For instance,
    all classes, modules, methods, etc. are all extracted from the Ruby source as code
    objects. All of these code objects extend from the {YARD::CodeObjects::Base} class, which
    provides basic attributes like source location, source code, name and path.
ja: コードオブジェクトは記述されているコードの用途を説明するRubyオブジェクトとなる。
    例えば、全てのクラス,モジュール,メソッド等は、
    コードオブジェクトのようにRubyのソースから全て抽出される。
    これらコードオブジェクトの全ては、{YARD::CodeObjects::Base}クラスから拡張する。
    そして、ソースの位置や,ソースコードや,名前や,パスのように基本属性を提供する。

en: ## CodeObjects Organization
ja: ## コードオブジェクト機構

en: Code objects are divided into two basic types. {YARD::CodeObjects::NamespaceObject NamespaceObjects}
    and non-namespace objects. A namespace object refers to any object in Ruby that can have
    other objects defined inside of it. In the context of Ruby, this specifically means
    modules and classes (both of which are subclasses of `NamespaceObject`). These objects
    act like tree structures, maintaining a list of all of their direct children. All non
    namespace objects are simply subclasses of the Base class. The {YARD::CodeObjects::RootObject RootObject}
    is a special kind of `NamespaceObject` which refers to the top level namespace in Ruby.
    Methods that accept a namespace object as a parameter should also accept the symbol
    `:root` as a shortcut for the root object.
ja: コードオブジェクトは二つの基本的な方に分割される。
    それは{YARD::CodeObjects::NamespaceObject NamespaceObjects}とnamespaceではないオブジェクトである。
    namespace オブジェクトは
    その内部で定義された他のオブジェクトを持つ事ができる任意のRubyのオブジェクトを参照する。
    これは特にモジュールとクラスを意味する。
    ( `NamespaceObject` のサブクラスのどちらとも)
    これらのオブジェクトはツリー構造のように振る舞い、これらの直接の子全てのリストを維持している。
    namespaceではない全てのオブジェクトは単純にベースクラスのサブクラスである。
    {YARD::CodeObjects::RootObject RootObject} は
    特別な `NamespaceObject` ともいえ、Rubyの中のトップレベルnamespaceを参照する。
    パラメータとして namespace オブジェクトを受け入れるメソッドは、
    root オブジェクト用のショートカットとして `:root` シンボルも受け入れる。

en: The following is an overview of the classes within the `CodeObjects` namespace:
ja: 以下は `CodeObjects` のnamespaceの中で用いられるクラスの概要となる。

en: ## Unique Path Representation
ja: ## ユニークパス表現
    ## Unique Path Representation

en: All CodeObjects are uniquely defined by their implementation of {YARD::CodeObjects::Base#path}.
    This path is used to locate or store a code object in the {YARD::Registry}. It is therefore
    essential that any Base subclass return a unique String value for #path so that the
    object may co-exist with other objects in the Registry.
ja: 全てのコードオブジェクトは
    これらの{YARD::CodeObjects::Base#path}の実装によって個別に定義される。
    このパスは場所を示すためや {YARD::Registry} の中でコードオブジェクトを登録するため利用される
    それ故、任意の基本サブクラスが個別の#pathメソッド用の文字列値を返す必要がある。
    オブジェクトはレジストリーの中で他のオブジェクトと一緒に共存する事になる。

en: In practice, a path is simply the conventional Ruby representation of a class,
    module, constant, class variable or method. For example, the following objects
    would have the following respective paths:
ja: 実際のパスは、単純に慣習的なRubyの
    クラス,モジュール,定数,クラス変数,メソッドの表現となる。
    例えば、次のオブジェクトは、後に続く個別のパスを持っている。

en: * Class `Klass` inside module `Mod`: `Mod::Klass`
    * Instance method `bar` inside class `Foo`: `Foo#bar`
    * Class method `bar` inside class `Foo`: `Foo.bar`
    * Constant `VERSION` inside class `YARD`: `YARD::VERSION`
    * Class variable `@@abc` inside class `A`: `A::@@abc`
ja: * `Mod` モジュールの内部の `Klass` クラス: `Mod::Klass`
    * `Foo` クラスの内部の `bar` インスタンスメソッド: `Foo#bar`
    * `Foo` クラスの内部の `bar` クラスメソッド: `Foo.bar`
    * `YARD` クラス内部の `VARSION` 定数: `YARD::VERSION`
    * `A` クラス内部の `@@abc` クラス変数: `A::@@abc`

en: ## Registry
ja: ## レジストリー

en: CodeObjects classes are coupled with the {YARD::Registry} class which keeps track of
    all instantiated code objects. This is an explicit design choice to allow objects
    to be fetched, cached, imported and exported from a centralized location. As mentioned
    above, this coupling is a result of the fact that each object is uniquely identified by
    its path, which is used to implement lookups. You can read more about the registry
    in the {YARD::Registry} class.
ja: コードオブジェクトクラスは {YARD::Registry} クラスを用い組み合わされ、
    そしてインスタンス化されたコードオブジェクトのトラックを保持する。
    これは集中化される場所から、
    フェッチ,キャッシュ,インポート,エクスポートされるオブジェクトを許可するための
    選択を明確に設計する。
    上で言われた、
    この組み合わせは個々のオブジェクトの要素の結果がそのパスによって独自に識別され,
    検索を実装するために利用される。
    レジストリーの詳細については、 {YARD::Registry} クラスの中で読むことができる。

en: Code objects are instantiated using an identity-map like implementation that guarantees
    only one unique Ruby object exists for an object described by a specific path. This
    allows developers to create a code object without checking if it already exists in
    the {YARD::Registry}. The following example will only create one object:
ja: コードオブジェクトはidentity-mapによってインスタンス化される。
    これは、特定のパスによって説明されるオブジェクトが
    固有のRubyオブジェクトだと保証する実装のようなものである。
    既に{YARD::Registry}の中に存在する場合
    確認無しでコードオブジェクトを作成する為に開発者達を受け入れる
    次の例は一つのオブジェクトだけ作成する。

en: ## Proxy Objects
ja: ## プロキシ オブジェクト

en: In addition to providing access to existing objects, a {YARD::CodeObjects::Proxy}
    class exists which can represent an object at a path that may or may not have been
    created. This is necessary to represent a reference to an object in code that is
    never defined in the same body of source code, or perhaps defined later. If any
    attributes of a proxy are accessed, it will immediately be resolved to the object
    at its declared path. In the case where such an object exists, it will act as
    a delegate to the object. However, if the object does not exist, a warning will
    be raised. Whenever arbitrary code objects are used, care should be taken in
    order to make sure attributes are not accessed on unresolvable proxies. An
    unresolvable proxy will return a class name of `Proxy` and #type of `:proxy`,
    for example:
ja: さらに現在のオブジェクトにアクセスを提供するには、
    {YARD::CodeObjects::Proxy} クラスがある。
    それは作成されるかどうかはわからないがパスでオブジェクトを表せる。
    これは同じソースコード内で定義されないコードでオブジェクトへの参照を表す為や、
    ことによると後で定義される時に必要となる。
    任意プロキシの属性がアクセスされる場合、
    すぐに宣言されたパスでオブジェクトの為に解決される。
    オブジェクトが存在する場合、オブジェクトに委譲するように振る舞う。
    しかしながら、オブジェクトが存在しなかった場合は、警告が出るだろう。
    任意のコードオブジェクトが利用される時はいつでも、
    属性が未解決のプロキシ上でアクセスしないか確認する為に
    順番にされるので注意しなければならない。
    未解決のプロキシは `Proxy` のクラス名と `:proxy` の#typeメソッドを返す。
    例えば以下のように:

en: ## Adding Data to Code Objects
ja: ## コードオブジェクトにデータを追加する。

en: Code objects act as hash-like structures that allow any arbitrary value to be set.
    This allows easy extending of existing objects without creating custom subclasses.
    For instance, to add a timestamp to a method object (when it was modified, maybe),
    it is possible to simply do:
ja: コードオブジェクトは設定される為の任意の値を受け入れるハッシュ構造のように振る舞う。
    これは、カスタムサブクラスを作成すること無しで、既存のオブジェクトの簡単な拡張を受け入れる。
    例えば、メソッドオブジェクトにtimestampを追加する為には、
    以下の様に単純にする事が可能。

en: This value can now be retrieved on this object both by the hash `[]` syntax as
    well as like any other method:
ja: この値はハッシュのような `[]` 構文でも以下のような
    メソッド呼び出しでも取り出す事が出来る。

en: ## Creating a Custom CodeObject
ja: ## カスタムコードオブジェクトを作成する

en: It should first be mentioned that creating a custom code object should not be
    necessary in most cases, except when functionality that cannot be represented
    by classical Ruby objects is added. A good example *might* be a test class,
    which although is technically a Ruby class, has a significantly different purpose
    in documentation and needs a different set of metadata, as well as its own
    representation in documentation.
ja: カスタムコードオブジェクトを作成する前に、最初に言及すべきこととして、
    大抵の場合、カスタムコードオブジェクトを作成する事は必須ではないはずである。
    この項は標準的なRubyオブジェクトの追加によって表現できない機能がある時の事を予期する。
    いい例は、testクラスかもしれない、
    それは、形の上ではRubyのクラスだけれども、
    中のドキュメントやメタデータの入った異なる設定を必要とし
    かなり異なる目的をもっている。
    それ自身もドキュメントの中を表している。

en: The {YARD::CodeObjects::Base#path} implementation is the most important part of the
    code object architecture. The first thing any custom code object must guarantee is
    that its path value is unique among all other objects. The recommended way to do this
    with custom objects is to add a descriptive prefix to the path. For example, the
    following is an implementation of the path for a hypothetical `FooObject`:
ja: {YARD::CodeObjects::Base#path}の実装がコードオブジェクト構造の最も重要な部分である。
    どのカスタムコードオブジェクトでも最初に保証されなければならない事は、
    パスの値が他の全てのオブジェクトとの間で固有でなければならない。
    これを行うのに推奨される方法は、
    カスタムオブジェクトがパスに説明のプレフィックス(接頭語)を
    追加する方法である。
    例えば、次は仮の `FooObject` 用のパスの実装となる。

en: Note that if our FooObject is a `NamespaceObject`, meaning if it can have child
    FooObjects defined inside of it, you may need to verify that the prefix is only
    applied once.
ja: 次の事に留意する。
    もし例のFooObjectが、 `NamespaceObject` の場合、
    FooObjectがそれの内部で定義される子を持てるかどうか意味している。
    一度だけ適用されるプレフィックスを確認する為に必要な場合がある。

en: Getting Started Guide
ja: 導入の案内

en: # Getting Started with YARD
ja: # YARDを使い始めるには

en: There are a few ways which YARD can be of use to you or your project. This
    document will cover the most common ways to use YARD:
ja: YARDにはプロジェクトの助けとなるいくつかの使用方法があるが、
    このドキュメントでは以下の目次で一般的なYARDの使い方について説明する。

en: * [Documenting Code with YARD](#docing)
    * [Using YARD to Generate Documentation](#using)
    * [Configuring YARD](#config)
    * [Extending YARD](#extending)
    * [Templating YARD](#templating)
    * [Plugin Support](#plugins)
ja: * [YARDで文書を作る](#docing)
    * [ドキュメントを生成するYARDの使い方](#using)
    * [YARDの構成する](#config)
    * [YARDの拡張する](#extending)
    * [YARDのテンプレートを作成する](#templating)
    * [プラグインサポート](#plugins)

en: ## Documenting Code with YARD
ja: ## YARDで文書を作る

en: By default, YARD is compatible with the same RDoc syntax most Ruby developers
    are already familiar with. However, one of the biggest advantages of YARD is
    the extended meta-data syntax, commonly known as "tags", that you can use
    to express small bits of information in a structured and formal manner. While
    RDoc syntax expects you to describe your method in a completely free-form
    manner, YARD recommends declaring your parameters, return types, etc. with
    the `@tag` syntax, which makes outputting the documentation more consistent
    and easier to read. Consider the RDoc documentation for a method to_format:
ja: デフォルトで、YARDは多くのRuby開発者たちがすでによく知っている
    RDoc構文と両立できる。
    しかしながら、
    YARDの最も大きな利点の一つは、拡張できるメタデータ構文となる。
    それは、一般的に知られる"タグ"のように、
    小さくて構造化された情報の中を明確にする為や
    形式的な方法で記述する為に利用できる。
    さらに、RDoc構文はメソッドを説明する為に全てフリーフォームマナーで要求するが、
    YARDは宣言しているパラメータ、リターンタイプなどを `@tag` 構文を用いて、
    一貫した表現で簡単に読む為のドキュメント作りを推奨する。
    RDocのドキュメントのto_formatメソッドについて考えてみる。

en:     # Converts the object into textual markup given a specific `format`
        # (defaults to `:html`)
        #
        # == Parameters:
        # format::
        #   A Symbol declaring the format to convert the object to. This
        #   can be `:text` or `:html`.
        #
        # == Returns:
        # A string representing the object in a specified
        # format.
        #
        def to_format(format = :html)
          # format the object
        end
ja:     # 原文のマークアップの与えられた特定の `format` へオブジェクトを変換する
        # (defaults to `:html`)
        #
        # == Parameters:
        # format::
        #   A Symbol declaring the format to convert the object to. This
        #   can be `:text` or `:html`.
        #
        # == Returns:
        # A string representing the object in a specified
        # format.
        #
        def to_format(format = :html)
          # format the object
        end

en: While this may seem easy enough to read and understand, it's hard for a machine
    to properly pull this data back out of our documentation. Also we've tied our
    markup to our content, and now our documentation becomes hard to maintain if
    we decide later to change our markup style (maybe we don't want the ":" suffix
    on our headers anymore).
ja: これは読んだり理解するには簡単と思われるかもしれないが、
    機械にとっては例のドキュメントを取消しデータを適切に再配置
    するのは大変である。(フリーフォームなので)
    内容と紐付いたマークアップになっているので、
    マークアップスタイルを変更するのが後で決まった場合、
    例のドキュメントはすぐに維持するのが大変になる
    (恐らく、私達は例の見出しのサフィックス":"を望んでいない。)

en: In YARD, we would simply define our method as:
ja: YARDの中で、私達は例のメソッドを単純に定義する。

en:     # Converts the object into textual markup given a specific format.
        #
        # @param [Symbol] format the format type, `:text` or `:html`
        # @return [String] the object converted into the expected format.
        def to_format(format = :html)
          # format the object
        end
ja:     # 原文のマークアップの与えられた特定のフォーマットへオブジェクトを変換する
        #
        # @param [Symbol] format the format type, `:text` or `:html`
        # @return [String] the object converted into the expected format.
        def to_format(format = :html)
          # format the object
        end

en: Using tags we can add semantic metadata to our code without worrying about
    presentation. YARD will handle presentation for us when we decide to generate
    documentation later.
ja: タグを用いることによって、
    私達は(フリーフォームでの)見栄えを気にすることなく
    意味のあるメタデータを追加することができる。
    そしてYARDは後でドキュメントを生成すると決めた時、
    見栄えを処理できる。

en: ## Which Markup Format?
ja: ## どのマークアップフォーマット?

en: YARD does not impose a specific markup. The above example uses standard RDoc
    markup formatting, but YARD also supports textile and markdown via the
    command-line switch or `.yardopts` file (see below). This means that you are
    free to use whatever formatting you like. This guide is actually written
    using markdown. YARD, however, does add a few important syntaxes that are
    processed no matter which markup formatting you use, such as tag support
    and inter-document linking. These syntaxes are discussed below.
ja: YARDは特定のマークアップを強要しない。
    上の例は標準のRDocマークアップ書式を例として使ったが、
    それだけではなく、
    コマンドラインや `.yardopts` ファイル経由でtexttileとmarkdownもサポートする(以下参照)
    これが意味することは、
    あなたが好きなどんな書式を使おうとも自由である。
    このガイドは実際にmarkdownを使って書かれている。
    ともあれYARDにはいくつかの重要な構文を追加された。
    それは、
     1. あなた使うマークアップ書式で問題なく処理される
     2. タグの様なサポート
     3. ドキュメント内部のリンク
    である。
    これらの構文は以降で説明される。

en: ## Adding Tags to Documentation
ja: ## ドキュメントにつけられているタグ

en: The tag syntax that YARD uses is the same @tag-style syntax you may have seen
    if you've ever coded in Java, Python, PHP, Objective-C or a myriad of other
    languages. The following tag adds an author tag to your class:
ja: YARDが使うタグ構文は,もしあなたが今まで
    Java, Python, PHP, Objective-Cや無数の他の言語をプログラミングした事があれば
    既にあなたが見たことがある@tagスタイルと同じ構文である
    次のタグはauthorタグをあなたのクラスに追加する:

en: To allow for large amounts of text, the @tag syntax will recognize any indented
    lines following a tag as part of the tag data. For example:
ja: 大量のテキストを受け入れる為に、
    タグ構文は続くインデントされた行をタグデータの一部として認識するだろう。
    例えば以下の様になる。

en: ### List of Tags
ja: ### タグのリスト

en: A list of tags can be found in {file:docs/Tags.md#taglist}
ja: タグのリストは {file:docs/Tags.md#taglist} で見つけられる。

en: ### Reference Tags
ja: ### 参照タグ

en: To reduce the amount of duplication in writing documentation for repetitive
    code, YARD introduces "reference tags", which are not quite tags, but not
    quite docstrings either. In a sense, they are tag (and docstring) modifiers.
    Basically, any docstring (or tag) that begins with "(see OTHEROBJECT)" will
    implicitly link the docstring or tag to the "OTHEROBJECT", copying any data
    from that docstring/tag into your current object. Consider the example:
ja: 繰り返しの多いドキュメント中の重複の総量を減少させるために、
    YARDはタグでもdocstringsでもない"参照タグ"を導入する。
    ある意味で、それらのタグ(とdocstring)の修飾となる。
    基本的には、"(see OTHEROBJECT)"から始まるdocstring(又はタグ)は
    "OTHEROBJECT"に暗黙的にリンクされる。これによって
    何らかのデータをdocstringやタグからあなたの作業オブジェクトの中へコピーすることができる。
    例を考えてみる。

en:     class MyWebServer
          # Handles a request
          # @param [Request] request the request object
          # @return [String] the resulting webpage
          def get(request) "hello" end
ja:     class MyWebServer
          # リクエストを操作する
          # @param [Request] request the request object
          # @return [String] the resulting webpage
          def get(request) "hello" end

en: The above `#post` method takes the docstring and all tags (`param` and `return`)
    of the `#get` method. When you generate HTML documentation, you will see this
    duplication automatically, so you don't have to manually type it out. We can
    also add our own custom docstring information below the "see" reference, and
    whatever we write will be appended to the docstring:
ja: 上の `#post` メソッドは `#get` メソッドのdocstrigと
    全てのタグ( `param` 及び `return` )を取得する。
    HTMLドキュメントを生成する時には、
    `#get` メソッドのタグの内容が自動的に複製されるので、
    あなたが手でタイプする必要は無い。
    また"see"の参照の下に、自分でカスタマイズしたdocstring情報を追加できる。
    そして、以下の例の様に、
    私達が書くものがどんなものでも、docstringに追加される。

en:     # (see #get)
        # @note This method may modify our application state!
        def post(request) self.state += 1; "hello" end
ja:     # (see #get)
        # @note このメソッドはアプリケーションの状態が変更されるかもしれない
        def post(request) self.state += 1; "hello" end

en: Here we added another tag, but we could have also added plain text. The
    text must be appended *after* the `(see ...)` statement, preferably on
    a separate line.
ja: ここでは他のタグ(@note)を追加したが、他に簡単なテキストを持つこともできる。
    その時はできればテキストを、`(see ...)`ステートメントの次の行に追加すべきである。

en: Note that we don't have to "refer" the whole docstring. We can also link
    individual tags instead. Since "get" and "post" actually have different
    descriptions, a more accurate example would be to only refer our parameter
    and return tags:
ja: 次の事に留意する。
    必ずしもdocstring全体を"参照"する必要はなく、
    代わりに個々のタグをリンクすることができる。
    実際に異なる説明を持っている"get"と"post"から、
    より正確な例はパラメータやリターンタグ参照だけになる。

en:     class MyWebServer
          # Handles a GET request
          # @param [Request] request the request object
          # @return [String] the resulting webpage
          def get(request) "hello" end
ja:     class MyWebServer
          # GETリクエストを操作する
          # @param [Request] request the request object
          # @return [String] the resulting webpage
          def get(request) "hello" end

en:       # Handles a POST request
          # @note This method may modify our application state!
          # @param (see #get)
          # @return (see #get)
          def post(request) self.state += 1; "hello" end
        end
ja:       # POSTリクエストを操作する
          # @note This method may modify our application state!
          # @param (see #get)
          # @return (see #get)
          def post(request) self.state += 1; "hello" end
        end

en: The above copies all of the param and return tags from `#get`. Note that you
    cannot copy individual tags of a specific type with this syntax.
ja: 上の構文は、 `#get` から@paramタグと@returnタグの全ての情報をコピーする。
    次の事に留意する。
    この構文を用いても特定の型の個々のタグをコピーできない。

en: ## Declaring Types
ja: ## 型を宣言する

en: Some tags also have an optional "types" field which let us declare a list of
    types associated with the tag. For instance, a return tag can be declared
    with or without a types field.
ja: いくつかのタグは省略可能な"型"フィールドも持つ。
    それは関連する型のリストを宣言する場所となる。
    例えば、@returnタグは、
    型フィールドがあってもなくても宣言できる。

en:     # @return [String, nil] the contents of our object or nil
        #   if the object has not been filled with data.
        def validate; end
ja:     # @return [String, nil] オブジェクトやnilとなる。
        #   nilはデータと共に内容が入っていない場合になる。(ここまでreturnのコメント)
        def validate; end

en:     # We don't care about the "type" here:
        # @return the object
        def to_obj; end
ja:     # 以下の様に"型"を気にする必要はない
        # @return the object
        def to_obj; end

en: The list of types is in the form `[type1, type2, ...]` and is mostly free-form,
    so we can also specify duck-types or constant values. For example:
ja: この型のリストは `[type1, type2, ...]` の形式である。
    そして大部分はフリーフォームとなる。
    したがってダックタイプ、又は、定数を指定する。
    例えば、

en: Note the latter example can be replaced by the meta-type "Boolean".
    Another meta-type is "void", which stands for "no meaningful value"
    and is used for return values. These meta-types are by convention
    only, but are recommended.
ja: 次の事に留意する。
    後の例は、メタタイプの"Boolean"によって置換される。
    他のメタタイプは"void"で"意味のない値"用であり、戻り値用に利用される。
    これらのメタタイプは慣習で利用されるだけだが推奨される。

en: List types can be specified in the form `CollectionClass<ElementType, ...>`.
    For instance, consider the following Array that holds a set of Strings and
    Symbols:
ja: 型のリストは、`CollectionClass<ElementType, ...>`形式の中で指定されることができる。
    例として、以下のArrayはStringそしてSymbolのセットをもっていると考える。

en: We mentioned that these type fields are "mostly" free-form. In truth, they
    are defined "by convention". To view samples of common type specifications
    and recommended conventions for writing type specifications, see
    [http://yardoc.org/types.html](http://yardoc.org/types.html). Note that these
    conventions may change every now and then, although we are working on a more
    "formal" type specification proposal.
ja: 我々が述べてきたこれらのフィールドの型は殆どがフリーフォームである。
    実のところ,それらは慣習によって定義される。
    型の指定用に一般的な型指定の例や推奨される慣習を調べるには、
    [http://yardoc.org/types.html](http://yardoc.org/types.html)を参照
    これらの慣習はいつの日か変更されるかもしれない、
    けれども我々はより正式な型指定の提案に取りかかっている。

en: ## Documenting DSL Methods
ja: ## DSLメソッドを記述する

en: Application code in Ruby often makes use of DSL style metaprogrammed methods.
    The most common is the `attr_accessor` method, which of course has built-in
    support in YARD. However, frameworks and libraries often expose custom
    methods that perform similar metaprogramming tasks, and it is often useful
    to document their functionality in your application. Consider the `property`
    method in a project like [DataMapper](http://datamapper.org), which creates
    a typed attribute for a database model. The code might look like:
ja: Rubyの中のアプリケーションコードは、
    DSLスタイルのメタプログラミングしたメソッドをよく利用する。
    最も一般的なのは、 `attr_accessor` メソッドで、
    もちろんYARDの中でビルトインサポートされている。
    とはいうものの、フレームワークやライブラリでは、
    大抵似たようなメタプログラミング作業を実行するカスタムメソッドを目にする。
    そして、それはアプリケーションの中にある機能を記述する為に便利である。
    [DataMapper](http://datamapper.org)のようにプロジェクトの中の `property` メソッドを考え、
    そして、データベースモデル用の属性の型を作成すると
    コー​​ドは次のようになる。

en: As of version 0.7.0, YARD will automatically pick up on these basic methods if
    you document them with a docstring. Therefore, simply adding some comments to
    the code will cause it to generate documentation:
ja: 0.7.0版の時点で、もしあなたが今まで紹介した例のdocstringを記述した場合、
    YARDは組み込みの基本メソッドによって自動的に取得するだろう。
    したがって、簡単にドキュメントを生成しいくつかのコメントを追加するには、
    以下の様に記述できる。

en: Note that YARD uses the first argument in the method call to determine the
    method name. In some cases, this would not be the method name, and you would
    need to declare it manually. You can do so with the `@!method` directive:
ja: 次の事に留意する。
    YARDはメソッド名を決定するのに、メソッド呼び出しの最初に引数を使う。
    もし、これがメソッド名でない場合、手動で宣言する必要がある。
    下の`@method`タグで宣言を行うことができる。

en: The @!method directive can also accept a full method signature with parameters:
ja: @!method 命令は
    完全なメソッドのシグネチャ受け入れる事もできる。

en: You can also set visibility and scope, or modify the method signature with
    extra tags. The following adds documentation for a private class method:
ja: あなたは可視性やスコープも設定できたり、
    追加のタグを用いメソッド用法を変更できる。
    以下は、privateクラスメソッドに対してドキュメントに追加する。

en: Finally, you can tag a method as an attribute by replacing the @!method
    tag with @!attribute. The @!attribute directive allows for the flags [r], [w],
    or [rw] to declare a readonly, writeonly, or readwrite attribute, respectively.
ja: 最終的に、@!attributeタグを用い@!methodタグを
    置換する事によって属性の様にメソッドのタグが出来る。
    読み込み専用,書込み専用,読み書きOK,個々に指定を宣言する為に
    @!attribute指令は[r], [w], [rw]フラグ用に受け入れる

en: (Note that if the name can be automatically detected, you do not need to
    specify it in the @!method or @!attribute directives)
ja: (次のことに留意する。
    名前が自動で認められる場合、@!methodや@!attributeタグの記入を
    必要としないことに注意する。)

en: However, you will notice a few drawbacks with this basic support:
ja: とはいうものの、あなたはこの基本サポートの備えるいくつかの欠点に気づくだろう。

en: 1. There is a fair bit of duplication in such documentation. Specifically, we
       repeat the term String and title twice in the property example.
    2. We must write a code comment for this property to show up in the documentation.
       If we do not write a comment, it is ignored.
ja: 1. このようなドキュメントでは重複を少し整形する。
       具体的には、繰り返しのString用語やproperty例の中の2度目のタイトル
    2. 私達はドキュメントに表示する為、propertyでコードのコメントを書かなければならない。
       コメントを書かない場合、それは無視される。

en: ### Macros
ja: ### マクロ

en: Fortunately YARD 0.7.0 also adds macros, a powerful way to add support for
    these DSL methods on the fly without writing extra plugins. Macros allow
    you to interpolate arguments from the method call inside the docstring,
    reducing duplication. If we re-wrote the `property` example from above
    using a macro, it might look like:
ja: 幸運にも、YARD 0.7.0はマクロも追加する。
    これらのDSLメソッドは余計なプラグインを記述することなく
    オンザフライでサポートを追加する為の強力な方法となる。
    マクロは重複を減らしたり、docstring内部のメソッド
    呼び出しから引数を挿入することを可能にする。
    もし私達が、例の`property`をマクロを用いて書き直した場合は、
    次のようになる。

en: (Note that $0 represents the method call, in this case `property`. The rest
    are arguments in the method call.)
ja: (次の事に留意する。
    $0はメソッド呼び出しを表す、この場合は`property`となる。
    残りはメソッド呼び出しの引数となる。)

en: The above example is equivalent to the first version shown in the previous
    section. There is also some extra benefit to using this macro, in that we
    can re-apply it to any other property in our class by simply calling on
    the macro. The following:
ja: 上の例は、前項の中の最初の訳文と等しい。
    このマクロを使うことによっていくつかの特別な恩恵もある。
    それは、マクロを簡単に呼び出すことによって、
    例のクラスの中の他のpropertyに最適用できる。
    以下の例は、

en: Would be equivalent to:
ja: 下と同等になる。

en: Finally, macros can be "attached" to method calls, allowing them to be implicitly
    activated every time the method call is seen in the source code of the class,
    or an inheriting class. By simply adding the `[attach]` flag, the macro
    becomes implicit on future calls. All of the properties below get documented
    by using this snippet:
ja: 最終的に、メソッド呼び出しの為に"追加"されるマクロは、
    クラスや継承クラスのソースコードの中で見られるメソッド呼び出しを
    いつでも起動できる様に実装される。
    単に `[attach]` フラグを追加することで、
    そのマクロは将来の呼び出しで暗黙的に呼び出される。
    下記のすべてのpropertyは、このスニペットを使用してドキュメントになる。

en: You can read more about macros in the {file:docs/Tags.md Tags Overview} document.
ja: もっとマクロについて知りたい場合は
    {file:docs/Tags.md Tags Overview}ドキュメントの中で読むことができる。

en: ## Customized YARD Markup
ja: ## YARDマークアップのカスタマイズ

en: YARD supports a special syntax to link to other code objects, URLs, files,
    or embed docstrings between documents. This syntax has the general form
    of `{Name OptionalTitle}` (where `OptionalTitle` can have spaces, but `Name`
    cannot).
ja: YARDは他のコードオブジェクト、URL、ファイル、
    ドキュメントの間で組み込むdocstringへのリンクの特別な構文をサポートする。
    この構文は、`{Name OptionalTitle}`の一般的な型を持っている。
    (`OptionalTitle`内でスペースを入れることはできるが、
     `Name`は入れることができない)

en: ### Linking Objects `{...}`
ja: ### オブジェクトのリンク `{...}`

en: To link another "object" (class, method, module, etc.), use the format:
ja: 他の"オブジェクト"(クラス、メソッド、モジュール、 etc.)へのリンクには、
    以下の書式を使う:

en: Without an explicit title, YARD will use the relative path to the object as
    the link name. Note that you can also use relative paths inside the object
    path to refer to an object inside the same namespace as your current docstring.
ja: 明確なタイトルが無い時、YARDはオブジェクトのリンク名に相対パスを使う。
    次の事に留意する。
    現在のdocstringのように同じnamespace内にあるオブジェクトを参照する為に、
    そのオブジェクトパス内で相対パスを使える。

en: Note that the `@see` tag automatically links its data. You should not use
    the link syntax in this tag:
ja: 次の事に留意する。`@see`タグは自動リンクとなるので、
    このタグのなかでリンク構文を使うべきではない。

en:     # @see #methodname   <- Correct.
        # @see {#methodname} <- Incorrect.
ja:     # @see #methodname   <- 正.
        # @see {#methodname} <- 誤.

en: If you want to use a Hash, prefix the first { with "!":
ja: もしあなたがハッシュを使う為にプレフィックスに、
    最初の{がほしい場合"!"を一緒につける。

en: ### Linking URLs `{http://...}`
ja: ### URLのリンク `{http://...}`

en: URLs are also linked using this `{...}` syntax:
ja: URLはこの`{...}`構文を用いリンクされる。

en: ### Linking Files `{file:...}`
ja: ### ファイルのリンク `{file:...}`

en: Files can also be linked using this same syntax but by adding the `file:`
    prefix to the object name. Files refer to extra readme files you added
    via the command-line. Consider the following examples:
ja: ファイルも同じ構文を使ってリンクされる、
    しかし、オブジェクト名のプレフィックスに`file:`が追加される。
    ファイルはあなたがコマンドライン経由で追加した特別なreadmeファイルを参照する。
    次の例を考えてみる。

en: As shown, you can also add an optional `#anchor` if the page is an HTML link.
ja: 上のように、
    そのページがHTMLリンク可能な場合は省略可能な`#anchor`を追加できる。

en: ### Embedding Docstrings `{include:...}`
ja: ### Docstringの組み込み `{include:...}`

en: We saw the `(see ...)` syntax above, which allowed us to link an entire docstring
    with another. Sometimes, however, we just want to copy docstring text without
    tags. Using the same `{...}` syntax, but using the `include:` prefix, we can
    embed a docstring (minus tags) at a specific point in the text.
ja: 私達は上の`{see ...}`構文を見たが、
    それは他と一緒にdocstring丸ごとリンクすることを可能にした。
    とはいうものの、タグなしでdocstringのテキストコピーのみ欲しい場合がある。
    そこで、同じ`{...}`構文と`include:`プレフィックスを用いると、
    テキストの特定の場所で、タグなしのdocstringを組み込むことができる。

en: The docstring for Bar becomes:
ja: docstringは次のようになる。

en: ### Embedding Files `{include:file:...}`
ja: ### ファイルの埋め込み `{include:file:...}`

en: You can embed the contents of files using `{include:file:path/to/file}`,
    similar to the `{include:OBJECT}` tag above. If the file uses a specific markup
    type, it will be applied and embedded as marked up text. The following
    shows how the tag can be used inside of comments:
ja: `{include:file:path/to/file}`は上の`{include:OBJECT}`タグと同様に
    使う事によってファイルの内容を埋め込む事ができる。
    ファイルが特定のマークアップの型を使う場合は,
    マークアップテキストとして埋め込まれ適用される。
    次はコメントの内部で利用されるタグにどのようなものがあるか一覧する。

en:     # Here is an example of a highlighted Ruby file:
        #
        # {include:file:examples/test.rb}
ja:     # これはハイライトされたRubyのファイルの例である
        #
        # {include:file:examples/test.rb}

en: ### Rendering Objects `{render:...}`
ja: ### オブジェクトのレンダリング `{render:...}`

en: Entire objects can also be rendered in place in documentation. This can be
    used for guide-style documentation which does not document the entire source
    tree, but instead selectively renders important classes or methods. Consider
    the following documentation inside of a README file:
ja: 全てのオブジェクトはドキュメントの適当な位置に表示される。
    {render:...}はガイドスタイルドキュメント用に使われるが
    それは全てのソースツリーを記述しない。
    しかし、代わりに重要なクラスやメソッドを選択的に表示する。
    以下のREADMEファイルの内部のドキュメントを考えてみる。

en:     This library adds pig latin methods to the string class, allowing you
        to transform sentences into pig latin.
ja:     このライブラリはstring classの為にpig latinメソッドを追加する。
        pig latinへ文を変換する事を可能にする。

en:     You can also un-pig-latin-ify a word or sentence:
ja:     あなたは単語や文を以下の様にpig-latinにしないこともできる。

en: The above would render the methods in place inside the README document,
    allowing you to summarize a small library in a single file.
ja: 上のように書くと、READMEドキュメント内部の{}の中のメソッドを表示する。
    これによって、一つのファイルの中にライブラリの説明を要約できる。

en: ## Using YARD to Generate Documentation
ja: ## ドキュメントを生成するYARDの使い方

en: ### `yard` Executable
ja: ### 実行可能な`yard`コマンド

en: YARD ships with a single executable aptly named `yard`. In addition to
    generating standard documentation for your project, you would use this tool
    if you wanted to:
ja: YARDは単一で適切に実行可能な'yard'コマンドとして送り出す。
    あなたのプロジェクトの為の標準のドキュメントを生成することに加え、
    次のツールも使える。

en: * Document all installed gems
    * Run a local documentation server
    * Generate UML diagrams using [Graphviz][graphviz]
    * View `ri`-style documentation
    * Diff your documentation
    * Analyze documentation statistics.
ja: * 全てのインストール済のジェムを記述する
    * ローカルドキュメントサーバーを起動する
    * [Graphviz][graphviz]によってUML図を生成する
    * `ri`スタイルドキュメントを一覧する
    * あなたのドキュメントの差分を見る
    * ドキュメントの統計を解析する

en: The following commands are available in YARD 0.6.x (see `yard help` for a
    full list):
ja: 以下のコマンドは、YARD 0.6.xで利用できる。
    (`yard help`コマンドで全てのリストが見れる)

en:     Usage: yard <command> [options]
ja:     !!!plain
        Usage: yard <コマンド> [オプション...]

en:     Commands:
        config   Views or edits current global configuration
        diff     Returns the object diff of two gems or .yardoc files
        doc      Generates documentation
        gems     Builds YARD index for gems
        graph    Graphs class diagram using Graphviz
        help     Retrieves help for a command
        ri       A tool to view documentation in the console like `ri`
        server   Runs a local documentation server
        stats    Prints documentation statistics on a set of files
ja:     Commands:
        config   設定を見るか、現在の全体的な構成を編集する
        diff     2つのgemsまたは、'.yardoc'ファイルのオブジェクトの差分を返す
        doc      ドキュメントを生成する
        gems     gemsにYARDのインデックスを組み込む
        graph    Graphvizを用いてクラス図を図示する
        help     ヘルプコマンド
        ri       `ri`のようにコンソールの中でドキュメントを作成する
        server   ローカルなドキュメント作成サーバーを起動する
        stats    設定したファイルのドキュメントのステータスを出力する

en: Note that `yardoc` is an alias for `yard doc`, and `yri` is an alias for
    `yard ri`. These commands are maintained for backwards compatibility.
ja: 次の事に留意する。
    `yardoc`は、`yard doc`コマンドのエイリアスで,
    `yri`は`yard ri`コマンドのエイリアスとなる。
    これらのコマンドは、後方互換が維持されている。

en: ### `.yardopts` Options File
ja: ### `.yardopts` 設定ファイル

en: Unless your documentation is very small, you'll end up needing to run `yardoc`
    with many options.  The `yardoc` tool will use the options found in this file.
    It is recommended to check this in to your repository and distribute it with
    your source. This file is placed at the root of your project (in the directory
    you run `yardoc` from) and contains all of arguments you would otherwise pass
    to the command-line tool. For instance, if you often type:
ja: ドキュメントが小さくない限り、
    結局`yardoc`コマンドと一緒にたくさんの設定を必要としているだろう。
    `yardoc`コマンドは.yardoptsファイルの中で見つけた設定を使う。
    その為、あなたのリポジトリに入れてソースと一緒に配布することを推奨する。
    このファイルはあなたのプロジェクトのルートに位置する。
    (あなたが`yardoc`を起動するディレクトリの中からの)
    そして、全ての引数を含んでなければコマンドラインではパスしないだろう。
    例えば、以下をよくタイプするならば、

en: You can place the following into your `.yardopts`:
ja: 下の内容を`.yardopts`の中へ書くことで設定できる。

en: This way, you only need to type:
ja: この方法を用いると、以下をタイプするだけでよい。

en: Any extra switches passed to the command-line now will be appended to your
    `.yardopts` options.
ja: あなたの`.yardopts`設定にコマンドラインに渡された引数は追加される。

en: Note that options for `yardoc` are discussed in the {file:README.md README},
    and a full overview of the `.yardopts` file can be found in {YARD::CLI::Yardoc}.
ja: 次の事に留意する。
    `yardoc`用のオプションは {file:README.md README} の中で説明される。
    全ての`.yardopts`ファイルの概要は {YARD::CLI::Yardoc} の中で見つけられる。

en: ### Documenting Extra Files
ja: ### 追加のファイルを記述する

en: "Extra files" are extra guide style documents that help to give a brief overview
    of how to use your library/framework, as well as any extra information that
    might be vital for your users. The most common "extra file" is the README,
    which is automatically detected by YARD if found in the root of your project
    (any file starting with `README*`). You can specify extra files on the command
    line (or in the `.yardopts` file) by listing them after the '-' separator:
ja: "Extra files"はライブラリやフレームワークで使うのにも、
    ユーザーにとっての何らかの特別な情報にも、
    簡単な概要を提供することを助ける
    追加のガイドスタイルドキュメントとなる。
    最も一般的な"extra file"はREADMEで、
    それは、もしあなたのプロジェクトのルートの中で見つけた場合、YARDによって自動で検出する。
    (`README*`で始まる何らかのファイル)
    以下の用に、追加のファイルの前に'-'セパレータを記述することによって
    コマンドライン上で(又は,`.yardopts`ファイル内で)指定できる。

en: Note that the README will automatically be picked up, so you do not need to
    specify it. If you don't want to modify the default file globs, you can ignore
    the first set of arguments:
ja: 次の事に留意する。
    READMEは、自動で選択される。
    従って、それを指定する必要はない。
    もしデフォルトのファイルglobを変更しないなら
    最初に設定する引数は無視できる。

en: Below you can read about how to customize the look of these extra files, both
    with markup and pretty titles.
ja: 以降は追加のファイルをカスタマイズする方法について読むことができる。
    これによってマークアップやいいタイトル両方を使用できる。

en: #### Adding Meta-Data to Extra Files
ja: #### 追加のファイルにメタデータを追加する

en: You can add YARD-style `@tag` metadata to the top of any extra file if prefixed
    by a `#` hash comment. YARD allows for arbitrary meta-data, but pays special
    attention to the tags `@markup`, `@encoding`, and `@title`. Note that there
    cannot be any whitespace before the tags. Here is an example of some tag data
    in a README:
ja: `#`のハッシュコメントによってプレフィックスした場合、
    任意の追加のファイルのトップにYARDスタイルの`@tag`メタデータを追加できる。
    YARDは任意のメタデータを受け入れる。
    しかし`@markup`,`@encoding`,`@title`タグには特別な注意を払わなければならない。
    次の事に留意する。
    タグの前に空白があってはならない。
    これはREADMEの中のいくつかのタグデータの例:

en:     This is the best library you will ever meet. Lipsum ...
ja:     これはあなたが出会う最高のライブラリとなる。以下略...

en: The `@markup` tag allows you to specify a markup format to use for the file,
    including "markdown", "textile", "rdoc", "ruby", "text", "html", or "none"
    (no markup). This can be used when the markup cannot be auto-detected using
    the extension of the filename, if the file has no extension, or if you want
    to override the auto-detection.
ja: `@markup`タグは、"markdown", "textile", "rdoc", "ruby", 
    "text", "html", "none"(no markup)を含んでいるファイルを扱えるよう、
    マークアップ書式の指定を可能にする。
    このマークアップはファイル名の拡張子を自動検出できなかった時や、
    ファイル名の拡張子がない時や、
    あなたが(拡張子の)自動検出を上書きしたい時に使われる。

en: By using `@encoding` you can specify a non-standard encoding. Note that
    `yardoc --charset` sets the global encoding (for all comments / files),
    so if you are using unicode across all your files, you can specify it there.
    Using the `@encoding` tag might be used to override the default global
    charset, say, if you had a localized `README.jp` file with SJIS data.
    Also note that this only affects Ruby 1.9.x, as Ruby 1.8 is not properly
    encoding aware.
ja: `@encoding`を使用することによって、
    あなたは非標準のエンコーディングを指定できる。
    次の事に留意する。
    `yardoc --charset`は全体のエンコーディングを設定する(全てのコメント/ファイル)、
    なので、もしあなたが全てのファイルでユニコードを使っているならこれを指定できる。
    例えば、ローカライズした`README.jp`ファイルとSJISデータをもっていたら
    `@encoding`タグを使うことによって、default global charsetを上書きする為に
    使うことができる。
    又、これはRuby1.9.xにだけ作用する、
    Ruby1.8については適切なエンコーディングになっていない。

en: The `@title` tag allows you to specify a full title name for the document.
    By default, YARD uses the filename as the title of the document and lists
    it in the file list in the index and file menu. In some cases, the file name
    might not be descriptive enough, so YARD allows you to specify a full title:
ja: `@title`タグはそのドキュメントでフルタイトル名による指定を許可する。
    デフォルトでは、YARDはドキュメントのタイトルにファイル名を使う。
    そして、ファイルリストの中のインデックスやファイルメニューを列挙する。
    一部の例では、ファイル名は十分に説明できないかもしれない、
    その為、YARDはあなたがフルタイトルを指定することを認めている。

en: Currently all other meta-data is hidden from view, though accessible
    programmatically using the {YARD::CodeObjects::ExtraFileObject} class.
ja: 現在の全ての他のメタデータは一覧から隠される。そうはいうものの、
    {YARD::CodeObjects::ExtraFileObject}クラスによってプログラムにアクセス可能である。

en: ## Configuring YARD
ja: ## YARDを構成する

en: YARD (0.6.2+) supports a global configuration file stored in `~/.yard/config`.
    This file is stored as a YAML file and can contain arbitrary keys and values
    that can be used by YARD at run-time. YARD defines specific keys that are used
    to control various features, and they are listed in {YARD::Config::DEFAULT_CONFIG_OPTIONS}.
    A sample configuration file might look like:
ja: YARD (0.6.2)以降は`~/.yard/config`の中に格納した全体構成ファイルをサポートする。
    このファイルはYAMLファイルのように格納され、
    任意のキーと実行時にYARDによって利用できる値を含むことができる。
    YARDは様々な機能を制御する為に使われるので特定のキーを定義する。
    それは{YARD::Config::DEFAULT_CONFIG_OPTIONS}の中で列挙される。
    サンプルの設定ファイルは次のようになる。

en: You can also view and edit these configuration options from the commandline
    using the `yard config` command. To list your configuration, use `yard config --list`.
    To view a key, use `yard config ITEM`, and to set it, use `yard config ITEM VALUE`.
ja: `yard config`コマンドを使って調べたり、構成設定を編集することもできる。
    構成をリストするには、`yard config --list`を使う。
    キーを調べるには、`yard config ITEM`, や、その値を設定する為に`yard config ITEM VALUE`を使う。

en: ## Extending YARD
ja: ## YARDを拡張する

en: There are many ways to extend YARD to support non-standard Ruby syntax (DSLs),
    add new meta-data tags or programmatically access the intermediate metadata
    and documentation from code. An overview of YARD's full architecture can be
    found in the {file:docs/Overview.md} document.
ja: 非標準のRuby構文(DSL)をサポートするのにYARDを拡張するための沢山の方法がある。
    新しいメタデータタグの追加や
    プログラム的に中間のメタデータにアクセスする方法、
    コードから記述する方法など。
    YARDの全体構造の概要は、
    {file:docs/Overview.md}ドキュメントの中で見つけられる。

en: For information on adding support for Ruby DSLs, see the {file:docs/Handlers.md}
    and {file:docs/Parser.md} architecture documents.
ja: RubyDSLサポートを追加する方法については、
    {file:docs/Handlers.md}や{file:docs/Parser.md}構造のドキュメントを参照。

en: For information on adding extra tags, see {file:docs/Tags.md}.
ja: 特別なタグを追加する方法は{file:docs/Tags.md}を参照。

en: For information on accessing the data YARD stores about your documentation,
    look at the {file:docs/CodeObjects.md} architecture document.
ja: あなたのドキュメントについて格納したYARDのデータがアクセスする方法は、
    {file:docs/CodeObjects.md}構造ドキュメント参照。

en: ## Templating YARD
ja: ## YARDのテンプレートを作る

en: In many cases you may want to change the style of YARD's templates or add extra
    information after extending it. The {file:docs/Templates.md} architecture
    document covers the basics of how YARD's templating system works.
ja: 多くの場合、あなたがYARDテンプレートのスタイルを変える為や
    特別な情報を後で拡張し追加する為に必要だろう。
    {file:docs/Templates.md}構造ドキュメントは、
    YARDテンプレートシステム作業の基本をカバーする。

en: ## Plugin Support
ja: ## プラグインサポート

en: As of 0.4, YARD will automatically load any gem named with the prefix of
    `yard-` or `yard_`. You can use this to load a custom plugin that
    [extend](#extending) YARD's functionality. A good example of this
    is the [yard-rspec][yard-rspec] plugin, which adds [RSpec][rspec] specifications
    to your documentation (`yardoc` and `yri`). You can try it out by installing
    the gem or cloning the project and trying the example:
ja: 0.4以降、YARDは`yard-`や `yard_`から始まる名前のgemを
    自動でロードするだろう。あなたはカスタムプラグインをロードする為に
    YARDの機能の[extend](#extending)を使える。
    これの良い例は[yard-rspec][yard-rspec] プラグインで、
    ドキュメント(`yardoc` and `yri`)に[RSpec][rspec]の仕様を追加する。
    gemをインストールすることによって、
    またはプロジェクトをクローンすることで試すことができる。
    例を以下に示す。

en: YARD also provides a way to temporarily disable plugins on a per-user basis.
    To disable a plugin create the file `~/.yard/ignored_plugins` with a list
    of plugin names separated by newlines. Note that the `.yard` directory might
    not exist, so you may need to create it.
ja: YARDはユーザーごとの基本のプラグインを
    一時的に無効にする方法も提供する。
    プラグインを無効にする為には、
    `~/.yard/ignored_plugins`ファイルを作り
    改行によって区切られた、プラグイン名をリストする。
    次の事に留意する。
    `.yard`ディレクトリは存在しない場合、
    作成する必要がある。

en: Handlers Architecture
ja: ハンドラー構造

en: # Handlers Architecture
ja: # ハンドラー構造

en: Handlers allow the processing of parsed source code. Handling is done after
    parsing to abstract away the implementation details of lexical and semantic
    analysis on source and to only deal with the logic regarding recognizing
    source statements as {file:docs/CodeObjects.md code objects}.
ja: ハンドラーは、ソースコードを解析した処理を受け入れる。
    これの処理は、実行する単語の詳細の抽象化を解析の後で行う。
    そして、意味のあるソースの分析や、
    ロジックに関しては{file:docs/CodeObjects.md code objects}のような
    ソースステートメントの受け入れだけで扱う。

en: ## The Pipeline
ja: ## パイプライン

en: After the {file:docs/Parser.md parser component} finishes analyzing the
    source, it is handed off for post-processing to the {YARD::Handlers::Processor}
    class, which is responsible for traversing the set of statements given by
    the parser and delegating them to matching handlers. Handlers match when the
    {YARD::Handlers::Base.handles?} method returns true for a given statement.
    The handler can then perform any action after being invoked by the `process`
    method.
ja: {file:docs/Parser.md parser component}がソースを解析すると、
    後処理する為に{YARD::Handlers::Processor} クラスに渡す。
    そしてパーサーによって与えるステートメントの設定を辿ったり、
    ハンドラーがマッチしているステートメントを委譲する責任がある。
    {YARD::Handlers::Base.handles?}メソッドがtrueを返す時、
    ハンドラーがマッチしているステートメントを与える。
    ハンドラーは`process`メソッドによって呼び出した後で任意の処理を実行できる。

en: ## The Processor Class
ja: ## プロセッサークラス

en: The main purpose of the processor, as mentioned above, is to traverse through
    the list of statements given to it by the parser. The processor also keeps
    state about what is being processed. For instance, the processor is what keeps
    track of the current namespace (the module or class an object is being defined
    in), scope (class or instance), file and owner. The owner refers to the object
    that is most directly responsible for the source statement being processed. This
    is most often the same as the namespace, except when parsing the body of a method,
    where the namespace would be the class/module the method is defined in and the
    owner would be the method object itself.
ja: 主なプロセッサーの目的は、上で述べたように、
    パーサーによって与えるステートメントのリストを通じて辿ることである。
    プロセッサーは処理されている状態について管理する。
    例えば、プロセッサーは現在の
    ネームスペース(モジュールやオブジェクトのクラスが定義される)、
    スコープ(クラスやインスタンス)、ファイルとオーナー
    を追跡する。
    オーナーは、オブジェクトを参照する。
    そのオブジェクトは処理されるソースステートメントに最も直接的な責任を持つ。
    これは(参照するオブジェクトの対象は)、多くの場合ネームスペースと同じで、
    メソッドの本体を解析した時を除き、
    そのネームスペースでは、クラスやモジュール,メソッドが定義される。
    そしてオーナーはメソッドオブジェクト自体となる。

en: ## Implementing a Handler
ja: ## ハンドラーを実装する

en: This section covers the basics of implementing a *new-style* Ruby handler. For
    details on implementing a legacy handler, see the "API Differences" section below.
ja: このセクションは *新しいスタイル* Rubyハンドラー処理の基本をカバーする。
    レガシーなハンドラーの詳細は、"API Differences" セクション以下を参照。

en: a Ruby handler can be implemented simply by subclassing the {YARD::Handlers::Ruby::Base}
    class and declaring what node types or source to process with the {YARD::Handlers::Base.handles handles}
    class method. A very simple handler that handles a module definition would be:
ja: Rubyハンドラーは処理の為に、
    {YARD::Handlers::Base.handles handles}クラスメソッドを用い、
    {YARD::Handlers::Ruby::Base}サブクラスや、
    ノードタイプやソースを宣言することによって実行される。
    モジュール定義の処理は次のような非常に簡単なハンドラーである。

en: For details on what nodes are, and what node types are, see the
    {file:docs/Parser.md parser architecture document}.
ja: ノードやノードの型の詳細については、
    {file:docs/Parser.md パーサー構造のドキュメント}を参照。

en: In this case the node type being handled is the `:module` type. More than one
    node type or `handles` declarations may describe a single handler, for instance,
    a handler that handles class definitions should handle the `:class` and `:sclass`
    node types respectively (the latter refers to classes defined as `class << Something`).
    The {YARD::Handlers::Base#statement statement} attribute refers to the current
    node (or statement) that is being handled by the handler.
ja: このケースの場合、処理されるノードタイプは `:module` タイプである。
    複数のノードタイプや `handles` 宣言は一つのハンドラーを記述する。
    例えば、ハンドラーはhandlesクラス定義が `:class` や
    `:sclass` ノードタイプそれぞれを処理する。
    (後者の:sclassは `class << Something` のようにクラス定義を参照する。)
    {YARD::Handlers::Base#statement statement}属性は、
    ハンドラーによって処理される現在のノード(やステートメントを)参照する。

en: ### Handling a Method Call
ja: ### メソッド呼び出しの処理

en: In some cases, a developer might need to handle a method call. The parser can
    express a method call in many AST forms, so to simplify this process, a method
    call can be handled by declaring the following in a `handles` statement:
ja: 場合によって開発者は、メソッド呼び出し操作を必要とするかもしれない。
    パーサーは多くのAST型(Abstract Syntax Tree)の中で、
    メソッド呼び出しを表現できる。そして、この処理を簡素化する為に、
    メソッド呼び出しは、次のような`handles`ステートメントの中で宣言される事によって処理される。

en:       def process
            # Process the method call
          end
        end
ja:       def process
            # メソッド呼び出しを処理する
          end
        end

en: In this case we handle any of the method calls to method name `describe` with
    the following syntaxes:
ja: このケースでは、私達はメソッド名`describe`メソッドの呼び出しを
    次の構文のように処理できる。

en: ### Creating a new Code Object
ja: ### 新しいコードオブジェクトを作成する

en: Usually (but not always) handling is performed to create new code objects to add
    to the registry (for information about code objects, see {file:docs/CodeObjects.md this document}).
    Code objects should simply be created and added to the existing `namespace`. This
    will be enough to add them to the registry. There is also a convenience
    {YARD::Handlers::Base#register register} method which quickly sets standard attributed
    on the newly created object, such as the file, line, source and docstring of the
    object. This method will be seen in the next example.
ja: 通常(しかし、いつもではない)の処理は、
    レジストリーを追加する新しいコードオブジェクトの作成する為に実行される。
    (コードオブジェクトについては{file:docs/CodeObjects.md このドキュメント}を参照)
    コードオブジェクトは単純に既存の `namespace` に作成され追加される。
    これは、レジストリにそれらを追加するために十分である。
    便利な{YARD::Handlers::Base#register register}メソッドがあり、
    これは新たに作成されるオブジェクト、ファイル、行、
    ソースやオブジェクトのdocstringのような標準属性を素早く設定する。
    このメソッドは次の例の中で見られるだろう。

en: ### Handling an Inner Block
ja: ### 内部のブロックの操作

en: By default, the parser gives the processor class a list of all the top level
    statements and the processor parses only those top level statements. If an inner
    block of a module, class, method declaration or even a block passed to a method call
    needs to be handled, the {YARD::Handlers::Base#parse_block parse_block} method must be called on the list of statements
    to parse. This will send the list to the processor to continue processing on that
    statement list. The source tree can be selectively parsed in this manner by parsing
    only the inner blocks that are relevant to documentation.
ja: デフォルトでパーサーは全てのトップレベルステートメントから、
    プロセッサークラスのリストを与える。
    そして、プロセッサーは、トップレベルステートメントだけ解析する。
    モジュール、クラス、メソッド内でブロックが宣言される場合や、
    ブロックが処理されるメソッド呼び出しを解析した場合でさえ、
    {YARD::Handlers::Base#parse_block parse_block}メソッドは、
    解析の為にステートメントのリストを呼び出さなければならない。
    これはステートメントのリストの処理を継続するプロセッサーにリストを送信する。
    ソースツリーは、ドキュメント作成に関連したブロック内だけ解析することによって、
    この形式の中で選択され抜粋される。

en: For example, the module handler parses the inner body of a module by performing
    the following commands:
ja: 例えばモジュールハンドラーは、
    以下のコマンドを実行することによってモジュールから内部の本体を解析する。

en: In this case `statement[1]` refers to a list of extra statements, the block we
    wish to parse. Note here that when parsing objects like modules and classes,
    we set the namespace for the duration of the block parsing by setting options
    on the `parse_block` method.
ja: この場合`statement[1]`は追加のステートメントで、
    私達が解析するブロックのリストを参照する。
    ここにあるように、
    モジュールやクラスのようにオブジェクトを解析する時、
    私達は`parse_block`メソッドのオプションが設定されることによって
    解析しているブロックの範囲をネームスペースに設定する。

en: ### API Differences for Legacy Handler
ja: ### Legacy Handler用のAPIの相違点

en: Because the legacy handler uses the legacy parser and therefore a different kind
    of AST, there are subtle differences in the handler API. Most importantly, the
    `handles` method usually deals with either lexical tokens or source code as a string
    or RegExp object. The statement object, similarly, is made up of lexical tokens instead
    of semantically parsed nodes (this is described in the {file:docs/Parser.md parser document}).
ja: レガシーハンドラーはレガシーパーサーを使い,
    それに伴い異る種類のASTがあるのでハンドラーAPIに微妙な違いがある。
    最も重要なことだが、 `handles` メソッドは通常、
    単語のトークンやソースコード、文字列やRegExpオブジェクトと共に処理する。
    ステートメントのオブジェクトと同様、意味のある解析されるノードの代わりに、
    単語のトークンから構成される。
    (これは{file:docs/Parser.md パーサーのドキュメント}の中で記述される)

en: The module example above can be rewritten as a legacy handler as follows:
ja: 上記のモジュール例は、次のようなレガシーハンドラーによって再書込みされる。

en: A few notes on the differences:
ja: 標準のハンドラーとの違いに関するいくつかの注意。

en:   * We inherit from `Legacy::Base` instead of the standard Ruby Base handler class.
      * We exchange node type `:module` for `TkMODULE`, which represents the
        first token in the statement.
      * We perform direct string manipulation to get the module name.
      * `parse_block` does not take a list of statements. In the old parser API,
        each statement has a `block` attribute which defines the list of
        statements within that statement, if any. Therefore, `parse_block` will
        always parse the `statement.block` if it exists.
ja:   * 標準のRubyBaseハンドラークラスの代わりに `Legacy::Base` から継承する。
      * ノードタイプ `:module` を `TkMODULE` へ交換する、
        それは、ステートメントの中の最初のトークンを表す。
      * モジュール名を取得する為に直接文字列操作を実行する。
      * `parse_block`はステートメントのリストを取得しない。
        古いパーサーの中のAPIで、
        それぞれのステートメントは `block` 属性を持っていたら
        ステートメントの中にステートメントのリストを定義する、
        従って、 `parse_block` は、 `statement.block` が存在すれば解析する。

en: Architecture Overview
ja: 基本設計概念の概要

en: # Architecture Overview
ja: # 基本設計概念の概要

en: YARD is separated in three major components, each of which allows YARD to be
    extended for a separate purpose. The split also emphasizes YARD's design choice
    to explicitly separate data gathering from HTML document generation, something
    that tools like RDoc do not do. These components are:
ja: YARDは主な構成として三つに分けられる。
    いずれも、目的毎に拡張される為にYARDに受け入れられる。
    これは、HTMLドキュメント生成から集めるデータを明確に分ける為に
    YARD設計上の選択を重視する。

en: This separation is a major goal of the project, and means that YARD is not *just*
    a tool to generate HTML output. The expectation is that any subset of YARD's
    major components may be used, extended or modified independently. YARD may be
    used just as a data gathering tool (to parse and audit code), just as a data
    source (a webserver containing raw unformatted data about code), or just as a
    conventional HTML documentation generation tool (like RDoc).
ja: この区分は、プロジェクトの主要な目的であり、
    YARDがHTMLの出力を生成するただの道具では無い事を意味している。
    期待することはYARDのメジャーな構成のサブセットが独自に利用,拡張,変更される事である。
    YARDはデータ収集ツール(コードを解析,検査),
    データの元(ウェブサーバーはコードについてフォーマットされて無い生のデータを含んでいる),
    便利なHTMLドキュメント作成ツール(RDocのような)として利用される。

en: The important classes and dependencies of these components are shown in the
    following class diagram:
ja: 重要なクラスやこれらの構成の依存関係は、次のクラス図の中で表示される。

en: ## Code Parsing & Processing Component
ja: ## コードの解析と処理の構成

en: This component is made up of four sub-components, each of which have separate
    tasks during the data gathering process (*note: the tag architecture is not*
    *shown in the class diagram*). These sub-components are:
ja: この構成は、4つの下位構成を作り上げる、
    いずれも、
    データ収集処理の間,別々のタスクを持つ。
    (*注意: タグ構造はクラス図)
    下位構成は以下のようになる。

en: The parser component reads source files and converts it into a set of statements
    which the handlers then process, creating code objects which in turn create tags
    (meta-data) attached to the objects. These objects are all added to the {YARD::Registry},
    the data store component.
ja: パーサーの構成は、ソースファイルを読み込み、
    ステートメントのグループの中へそれを変換する
    コードオブジェクトを作成し,
    順番にオブジェクトを追加されたタグ(メタデータ)を作成する。
    これらのオブジェクトは {YARD::Registry} に全て追加される。
    データは構成を記録する。

en: ## Data Storage Component
ja: ## データの記録内容

en: This component is currently implemented as a simple Ruby marshalled flat namespace
    of object. The implementation is found in the single class {YARD::Registry}, which
    is the centralized repository for all data being parsed, stored and accessed. There
    are future plans to improve this storage mechanism to be backend agnostic and allow
    for more robust storage.
ja: この内容は現在の所、
    単純にRubyの整理されたフラットなオブジェクトのnamespaceのように実装されている。
    実装はシングルクラスの{YARD::Registry}の中で見つけられる。
    始めに解析し,記憶,アクセスされる全てのデータ用に集中化されたリポジトリとなる。
    寛容なバックエンドにこのストレージのメカニズムを修正し、
    そして更なる堅牢なストレージを受け入れる為の将来の計画がある。

en: ## Post Processing & Templating System
ja: ## 後処理とテンプレートシステム

en: This component handles processing of objects from the registry through a templating
    engine that allows output to a variety of formats. Practically speaking, this is
    where templates can be implemented to change the design, output or structure of
    the data. See {file:docs/Templates.md Templates Architecture} for a complete overview.
ja: この構成は
    レジストリーから多様な書式を出力可能なテンプレートエンジンまで
    オブジェクトの処理を操作する。
    実際の話をすると、これは、設計や出力やデータの構造を変更する為に
    テンプレートが実装される場所となる。
    テンプレートの詳細な説明は
    {file:docs/Templates.md Templates Architecture}参照。

en: Parser Architecture
ja: パーサー構造

en: # Parser Architecture
ja: # パーサー構造

en: The parser component of YARD is the first component in the data processing pipeline
    that runs before any handling is done on the source. The parser is meant to translate
    the source into a set of statements that can be understood by the {file:docs/Handlers.md Handlers}
    that run immediately afterwards.
ja: YARDのパーサーの構成要素は、
    何らかの処理がソース上で行われる前に実行され
    パイプラインのデータ処理の中の最初の構成要素となる。
    パーサーはソースを、
    後ですぐ実行する{file:docs/Handlers.md Handlers}によって理解され
    ステートメントのグループの中へ変換するよう意図されている。

en: The important classes are described in the class diagram of the entire parser
    system below:
ja: 重要なクラスは、以下のパーサーの全体のシステムのクラス図表の中で記述する。

en: (Note: the RubyToken classes are omitted from the diagram)
ja: (注意: RubyTokenクラスは、図表から省略されます。)

en: ## SourceParser
ja: ## ソースパーサー

en: The main class {YARD::Parser::SourceParser} acts as a factory class, instantiating
    the correct parser class, an implementation of {YARD::Parser::Base}. The selected parser
    is chosen based on either the file extension or by selecting it explicitly (as an argument
    to parsing methods). YARD supports Ruby and C source files, but custom parsers can
    be implemented and registered for various other languages by subclassing `Parser::Base`
    and registering the parser with {YARD::Parser::SourceParser.register_parser_type}.
ja: 主なクラス{YARD::Parser::SourceParser}は、ファクトリークラスのように振る舞う。
    そして正確なパーサークラスをインスタンス化する。これは{YARD::Parser::Base}から実装する。
    選ばれるパーサーは、
    ファイル拡張子かパーサータイプを明確に指定する事によってベースが選ばれる。
    (メソッドの解析の為の引数のように)
    YARDはRubyやCのソースファイルをサポートするが。
    カスタムパーサーが
    `Parser::Base`をサブクラス化し
    {YARD::Parser::SourceParser.register_parser_type}を用い登録する事によって
    様々な他の言語用に実装され、登録される。

en: This factory class should always be used when parsing source files rather than
    the individual parser classes since it initiates the pipeline that runs the
    handlers on the parsed source. The parser used must also match the handlers,
    and this is coordinated by the `SourceParser` class as well.
ja: このファクトリークラスは、個々のパーサークラスを解析する時より
    ソースファイルを解析する時に毎回利用される。
    なので解析されたソース上でハンドラーを起動するパイプラインを開始する。
    利用されるパーサーはハンドラーにマッチしなければならない、
    これは `SourceParser` クラスによって同様にコーディネートされる。

en: ## Using the SourceParser Class
ja: ## ソースパーサークラスを使うには

en: The `SourceParser` class API is optimized for parsing globs of files. As such,
    the main method to use the class is the `parse` class method, which takes an
    array of file globs or a single file glob.
ja: `SourceParser` クラスAPIは、ファイルのglobを解析する為に最適化される。
    クラスを使う為の主なメソッドは、 `parse` クラスメソッドとなる。
    そして、ファイルの配列や単一のファイルglobを取る。

en: This is equivalent to the convenience method {YARD.parse}:
ja: これは以下の便宜的なメソッド{YARD.parse}と同等である。

en: In some cases (ie. for testing), it may be more helpful to parse a string of input
    directly. In such a case, the method {YARD::Parser::SourceParser.parse_string} should be
    used:
ja: 場合によっては(つまりテストの為)、
    それは直接入力の文字列を解析するのにとても役立つだろう。
    このような場合には、
    以下の{YARD::Parser::SourceParser.parse_string}メソッドが使われる。

en: You can also provide the parser type explicitly as the second argument:
ja: あなたは、パーサーの型を第2引数のように提供できる。

en:     # Parses a string of C
        YARD::Parser::SourceParser.parse_string("int main() { }", :c)
ja:     # C言語の文字列を解析する
        YARD::Parser::SourceParser.parse_string("int main() { }", :c)

en: Note that these two methods are aliased as {YARD.parse} and {YARD.parse_string} for
    convenience.
ja: 以下の事に留意する。
    これらの二つのメソッドは、便利に使う為の
    {YARD.parse}や{YARD.parse_string}のような別名となる。

en: ## Implementing and Registering a Custom Parser
ja: ## カスタムパーサーを実装及び登録する

en: To implement a custom parser, subclass {YARD::Parser::Base}. Documentation on which
    abstract methods should be implemented are documented in that class. After the class
    is implemented, it is registered with the {YARD::Parser::SourceParser} factory class
    to be called when a file of the right extension needs to be parsed, or when a user
    selects that parser type explicitly. To register your new parser class, call the
    method {YARD::Parser::SourceParser.register_parser_type}:
ja: カスタムパーサーを実装するには、{YARD::Parser::Base}をサブクラス化する。
    抽象的なメソッドのドキュメントはクラスの中で記述され実装される。
    クラスが実装されたあとで、
    正しい拡張子のファイルが解析される為に必要となる時や
    ユーザーが明示的にパーサーのタイプを選択する時に
    呼び出される為に{YARD::Parser::SourceParser}ファクトリークラスを用い記録される。
    あなたの新しいパーサークラスを登録するには、
    以下の様に{YARD::Parser::SourceParser.register_parser_type}メソッドを呼び出す。

en: The last argument can be a single extension, a list of extensions (Array), a single Regexp, or a
    list of Regexps. Do not include the '.' in the extension.
ja: 最後の引数は、単一の拡張か、拡張のリストか、単独の正規表現か、正規表現のリストになる。
    拡張する中に'.'を含めることはできない。

en: ## The Two Ruby Parser Types
ja: ## 2つのRubyパーサーの型

en: When parsing Ruby, the SourceParser can either instantiate the new {YARD::Parser::Ruby::RubyParser}
    class or the {YARD::Parser::Ruby::Legacy::StatementList} class. The first of the
    two, although faster, more robust and more efficient, is only available for
    Ruby 1.9. The legacy parser parser is available in both 1.8.x and 1.9, if
    compatibility is required. The choice of parser will affect which handlers
    ultimately get used, since new handlers can only use the new parser and the
    same requirement applies to the legacy parser & handlers.
ja: Rubyを処理している時、
    SourceParserは、{YARD::Parser::Ruby::RubyParser}クラスまたは、
    {YARD::Parser::Ruby::Legacy::StatementList}クラスをインスタンス化する。
    2つの内の最初の、{YARD::Parser::Ruby::RubyParser}は、
    高速で、最も堅牢で最も効率的だが、Ruby 1.9のみ利用可能。
    もし互換性が必要な場合、2番目のlegacy parserパーサーなら、
    1.8.xと1.9の両方で利用可能。
    パーサーの選択は、ハンドラーが最終的に取得する所で影響する。
    だから、新しいハンドラーは新しいパーサーだけを使える。
    その条件はレガシーパーサーとハンドラーも同様である。

en: ## Switching to Legacy Parser
ja: ## レガシーパーサーに切替える

en: By default, running YARD under Ruby 1.9 will automatically select the new parser
    and new handlers by extension. Although YARD supports both handler styles, plugins
    may choose to only implement one of the two (though this is not recommended). If
    only the legacy handlers are implemented, the `SourceParser` class should force
    the use of the legacy parser by setting the `parser_type` attribute as such:
ja: デフォルトで、稼動中のRuby1.9以下のバージョンで使われるYARDは、
    拡張によって新しいパーサーと新しいハンドラーを自動で選択する。
    YARDがどちらのハンドラースタイルもサポートするけれども、
    プラグインは2つの内一つだけを実装する事を選択する事もできる。
    (このような考えは推奨されない)
    もし、レガシーハンドラーのみ実装する場合、
    `SourceParser`クラスはレガシーパーサーの使用を
    強制すべきである。
    例として、以下の様に`parser_type`属性を設定する。

en: The default value is `:ruby`. Note that this cannot be forced the other way around,
    a parser type of `:ruby` cannot be set under Ruby 1.8.x as the new parser is not
    supported under 1.8.
ja: デフォルトの値は、`:ruby`となる。
    次の事に留意する。`:ruby`にしても強制されるわけではない。
    何故なら`:ruby`のパーサーの型はRipperライブラリが未定義の場合、
    新しいパーサーが1.8.以下をサポートしない様にするので、
    Ruby 1.8.x以下には設定されないからである。

en: ## RubyParser (the New Parser)
ja: ## Rubyパーサー(新しいパーサー)

en: The new Ruby parser uses the Ripper library that is packaged as part of stdlib
    in Ruby 1.9. Because of this, it can generate an AST from a string of Ruby input
    that is similar to the style of other sexp libraries (such as ParseTree). Each
    node generated in the tree is of the base type {YARD::Parser::Ruby::AstNode},
    which has some subclasses for common node types.
ja: 新しいRubyパーサーはRuby1.9の中のRipperライブラリを使用する。
    これは標準ライブラリの一部としてパッケージされる。
    そんな訳で、Rubyの入力文字列からのASTを生成することが出来る。
    これは、他のS式ライブラリのスタイルと同様である。
    ツリーの中のそれぞれの生成したノードは、
    基準の型{YARD::Parser::Ruby::AstNode}となる。
    そして、一般的なノードの型用のいくつかのサブクラスを
    持っている。

en: ### AstNode Basics
ja: ### AstNodeの基本

en: The `AstNode` class behaves like a standard Array class in which all of its data
    make up the list of elements in the array. Unlike other sexp style libraries, however,
    the node type is not the first element of the list. Instead, the node type is defined
    by the `#type` method. The following examples show some of the basic uses of `AstNode`:
ja: AstNodeクラスは、全てのデータが配列の中の要素のリストを
    作り上げる所で標準の配列クラスのように振る舞う。
    他のS式スタイルのライブラリとは異なっている。しかしながら、
    ノードタイプは、リストの最初の要素では無い。
    むしろ、ノードタイプは`#type`メソッドによって定義される。
    以下の例は、いくつかの`AstNode`の基本的な使用法を表す。

en:     # The sexp defines the statement `hello if 1`
        node = s(:if_mod, s(:int, "1"), s(:var_ref, s(:ident, "hello")))
        node.type  #=> :if_mod
        node[0]    #=> s(:int, "1")
        node[0][0] #=> "1"
ja:     # S式は `hello if 1` ステートメントを定義する
        node = s(:if_mod, s(:int, "1"), s(:var_ref, s(:ident, "hello")))
        node.type  #=> :if_mod
        node[0]    #=> s(:int, "1")
        node[0][0] #=> "1"

en: (Note the `s()` syntax is shorthand for `AstNode.new(...)`. `s()` with no type
    is shorthand for a node of type `:list`)
ja: (注意 `s()`構文は`AstNode.new(...)`用の縮めた表記となる。
    型がない`s()`は`:list`型のノード用の縮めた表記となる。)

en: As shown, not all of the elements are AstNodes in themselves, some are String
    objects containing values. A list of only the AstNodes within a node can be
    accessed via the {YARD::Parser::Ruby::AstNode#children #children} method. Using
    the sexp declared above, we can do:
ja: 示されたように、要素の全てがそれら自身の中のAstNodeでは無く、
    いくつかは、値を含んでいるStringオブジェクトとなる。
    ノード内部AstNodeだけのリストは、
    {YARD::Parser::Ruby::AstNode#children #children}メソッド経由でアクセスされる。
    上で宣言されたS式によって以下のようにできる。

en: Every node defines the `#source` method which returns the source code that the
    node represents. One of the most common things to do with a node is to grab its
    source. The following example shows how this can be done:
ja: 全てのノードは`#source`メソッドを定義する。
    そして、ノードが意味するソースコードを返す。
    ノードを用いた最も一般的な事は、ソースを取得する事となる。
    以下の例は、これがどのように実行されるかを表す。

en: Note that this only works on source parsed from the RubyParser, not sexps
    declared using the `s()` syntax. This is because no source code is generated
    or stored by nodes. Instead, only the character ranges are stored, which are
    then looked up in the original full source string object. For example:
ja: 次の事に留意する。
    RubyParserから解析されるソース上だけで働き、
    S式が`s()`構文によって宣言される時は働かない。
    これは何故かというとノードによってソースコードは生成や格納されないからである。
    代わりに、文字列の範囲だけ格納され、
    元の全てのソースのcharacterオブジェクトの中で検索される。
    以下の様になる。

en:     # Following the code snippet above
        ast[0].then_block.source_range #=> 17..31
ja:     # 上のコードは次のようになる。(raise Exception部分のレンジ)
        ast[0].then_block.source_range #=> 17..31

en: We can also get the line and line ranges in a similar fashion:
ja: 私達は以下の方法の様に、行や行の範囲を取得できる。

en:     ast[0].type       #=> :if
        ast[0].line       #=> 1
        ast[0].line_range #=> 1..3 (note the newlines in the source)
ja:     ast[0].type       #=> :if
        ast[0].line       #=> 1
        ast[0].line_range #=> 1..3 (ソース中の改行に注意)

en: Often the AST will be such that the node we care about might be buried arbitrarily
    deep in a node's hierarchy. The {YARD::Parser::Ruby::AstNode#jump} method exists
    to quickly get at a node of a specific type in such a situation:
ja: 多くの場合AST処理の中でノードに対し私達が気を付ける事は、
    任意でノードの階層の中深くに埋められるかもしれないという事である。
    {YARD::Parser::Ruby::AstNode#jump}メソッドは、以下の状況において特定の型の
    ノードに素早く到達する為に存在する。

en: Multiple types can be searched for at once. If none are found, the original root
    node is returned so that it may be chained.
ja: 複数のタイプは、すぐに検索される。
    もし、見つからなかった場合、オリジナルのルートノードは、連鎖されるように返される。

en: ## The Legacy Parser
ja: ## レガシーパーサー

en: The goal of the legacy parser is much the same as the new parser, but it is far
    more simplistic. Instead of a full-blown AST, the legacy parser simply groups
    together lists of "statements" called a {YARD::Parser::Ruby::Legacy::StatementList}.
    These statement lists are made up of {YARD::Parser::Ruby::Legacy::Statement} objects.
    A statement is any method call condition, loop, or declaration. Each statement
    may or may not have a block. In the case of a condition or loop, the block is
    the inner list of statements; in the case of a method call, the block is a do
    block (if provided). The statements themselves are made up of tokens, so instead
    of being semantic in nature like the new parser, statements are tied directly
    to the lexical tokens that make them up. To convert a statement into source, you
    simply join all the tokens together (this is done through the use of `#to_s`).
ja: レガシーパーサーの目的は、新しいパーサーと殆んど同様であるが、
    しかし、それははるかに単純である。
    完璧なASTの代わりに、
    レガシーパーサーは、単純に
    {YARD::Parser::Ruby::Legacy::StatementList}で呼び出される"ステートメント"のリストの
    グループを作る。
    これらのステートメントのリストは、{YARD::Parser::Ruby::Legacy::Statement}
    オブジェクトで構成されている。
    ステートメントは任意のメソッドで条件,ループ,宣言を呼び出す。
    それぞれのステートメントはブロックを持っているかわからない。
    条件やループの場合、ブロックはステートメントの内部のリストになる。
    メソッド呼び出しの場合、ブロックはブロックを実行する。(もし提供されるなら)
    ステートメントそれ自体は、トークンで構成されている。
    その為、新しいパーサーのように自然な意味になる代わりに、
    ステートメントはそれらを作り上げる単語のトークンに直接紐付けられる。
    ステートメントをソースに変換する為には、
    全てのトークンと共に単純に加えればいい。
    (これは`#to_s`メソッドを使用し行われる。)

en: Note that because there is little semantic parsing, the legacy parser is less
    able to deal with certain Ruby syntaxes. Specifically, the `:if_mod` syntax
    seen above ("hello if 1") would be considered two statements with the new parser,
    but using the legacy parser it is only one statement:
ja: 次の事に留意する。
    意味のある解析がほとんどないので、
    レガシーパーサーは、特定のRuby構文と共に扱う事ができない。
    具体的にいうと、
    上の("hello if 1")で見た`:if_mod`構文は、
    新しいパーサーを用いた二つのステートメントと考えられる。
    しかし、レガシーパーサーを使うと以下の一つのステートメントだけになる。

en: In addition, this means that most handling still needs to be done via string
    manipulation and regular expression matching, making it considerably more
    difficult to use in edge case scenarios.
ja: さらに、ほとんどの処理は文字列操作や正規表現マッチ経由で行う
    必要がある事を意味している。
    それに合わせて作るには、極端なシナリオで利用する場合、大幅に難しくなる。

en: Tags Overview
ja: タグの概要

en: # Tags Overview
ja: # タグの概要

en: Tags represent meta-data as well as behavioural data that can be added to
    documentation through the `@tag` style syntax. As mentioned, there are two
    basic types of tags in YARD, "meta-data tags" and "behavioural tags", the
    latter is more often known as "directives". These two tag types can be
    visually identified by their prefix. Meta-data tags have a `@` prefix,
    while directives have a prefix of `@!` to indicate that the directive
    performs some potentially mutable action on or with the docstring. The
    two tag types would be used in the following way, respectively:
ja: タグは`@tag`スタイルの構文からドキュメントを
    作成するために追加されるデータの行動(behavioural)としてメタデータを表す。
    上で述べた、
    YARDの中でタグには基本的な2つの方があり、
    "メタデータタグ"と"行動(behavioural)タグ"がある。
    後者は、"ディレクティブ"としてよく知られている。
    これらの2つのタグの型は
    これらのプレフィックス(接頭辞)によって視覚的に指定される。
    ディレクティブがdocstringと一緒に
    幾つかの潜在的に変更可能なアクションを実行する指示をする為に
    `@!`のプレフィックスを持つ間、
    メタデータタグは`@`プレフィックスを持つ。
    2つのタグの型はそれぞれ次の方法で利用される:

en: This document describes how tags can be specified, how they affect your
    documentation, and how to use specific built-in tags in YARD, as well
    as how to define custom tags.
ja: このドキュメントはタグについて
    どのように指定されるか、
    あなたのドキュメントにどれほど影響するか、
    YARDの指定の組み込みタグをどのように使うのか、
    どのようにカスタムタグを定義するのかを説明する

en: ## Meta-Data Tags
ja: ## メタデータタグ

en: Meta-data tags are useful to add arbitrary meta-data about a documented
    object. These tags simply add data to objects that can be looked up later,
    either programmatically, or displayed in templates. The benefit to describing
    objects using meta-data tags is that your documentation can be organized
    semantically. Rather than having a huge listing of text with no distinction
    of what each paragraph is discussing, tags allow you to focus in on specific
    elements of your documentation.
ja: メタデータタグは記述されたオブジェクトについて
    任意のメタデータを追加するのに便利である。
    これらのタグは
    簡単に後で検索でき、全てプログラムでき、テンプレートで表示できるように
    オブジェクトにデータを追加する。
    メタデータタグを使う事によるオブジェクトの説明の利点は、
    あなたのドキュメントが意味を持って整理されることである。
    個々の段落がどこで議論されるか
    区別しないで巨大なテキストでの記述するより、
    タグはあなたがあなたのドキュメントの特定の属性に集中するのを
    考慮している。

en: For example, describing parameters of a method can often be important to your
    documentation, but should not be mixed up with the documentation that describes
    what the method itself does. In this case, separating the parameter documentation
    into {tag:param} tags can yield much better organized documentation, both in
    source and in your output, without having to manually format the data using
    standard markup.
ja: 例えば、
    メソッドのパラメータの説明は
    あなたのドキュメントでしばしば必要になるが、
    そのメソッド自体が何をするのか説明する
    ドキュメントと一緒にごちゃ混ぜにすべきではない。
    この場合は{tag:param}タグへドキュメントのパラメータを区切る事で
    よりよく整理されたドキュメントにyieldでき、
    ソースとあなたの出力両方で,
    手動でなくても標準のマークアップでデータをフォーマットする。

en: All of this meta-data can be easily parsed by tools and used both in your templates
    as well as in code checker tools. An example of how you can leverage tags
    programmatically is shown in the {tag:todo} tag, which lists a small snippet of
    Ruby code that can list all of your TODO items, if they are properly tagged.
ja: このメタデータの全ては
    ツールによって簡単に解析され、
    それはあなたのテンプレートとコードチェッカーツールの両方で利用される。
    プログラムでどのタグを利用できるかの例は{tag:todo}タグで一覧でき、
    これらが適切にタグ付けられれば、
    あなたの全てのTODOの項目をリストされ小さいRubyのコードのスニペットを記述する。

en: Custom meta-data tags can be added either programmatically or via the YARD
    command-line. This is discussed in the "[Adding Custom Tags](#Adding_Custom_Tags)"
    section.
ja: カスタムメタデータタグはプログラムかYARDのコマンドラインで追加される。
    これは"[カスタムタグの追加](#Adding_Custom_Tags)"の項の中で議論される。

en: A list of built-in meta-data tags are found below in the [Tag List](#Tag_List).
ja: 組み込みのメタデータタグのリストは下の [タグリスト](#Tag_List) で見つけられる。

en: ## Directives
ja: ## ディレクティブ

en: Directives are similar to meta-data tags in the way they are specified, but they
    do not add meta-data to the object directly. Instead, they affect the parsing
    context and objects themselves, allowing a developer to create objects
    (like methods) outright, rather than simply add text to an existing object.
    Directives have a `@!` prefix to differentiate these tags from meta-data tags,
    as well as to indicate that the tag may modify or create new objects when
    it is called.
ja: ディレクティブはメタデータタグが指定される方法と似ているが、
    これは直接オブジェクトにメタデータを追加しない。
    代わりに、
    これらは解析のコンテキストとそれ自身のオブジェクトに影響し、
    既存のオブジェクトにテキストを単純に追加するより、
    完全なオブジェクト(メソッドのような)を作成する開発者を受け入れる。
    ディレクティブは、メタデータタグからこれらのタグを識別するためや
    タグが変更される示すためや
    呼び出される時に新しいオブジェクトを作成するに
    `@!`プレフィックスを持つ。

en: A list of built-in directives are found below in the [Directive List](#Directive_List).
ja: 組み込みのディレクティブのリストは
    以下の [ディレクティブリスト](#Directive_List) メソッドの中で定義される。

en: ## Tag Syntax
ja: ## タグ構文

en: Tags begin with the `@` or `@!` prefix at the start of a comment line, followed
    immediately by the tag name, and then optional tag data (if the tag requires it).
    Unless otherwise specified by documentation for the tag, all "description" text
    is considered free-form data and can include any arbitrary textual data.
ja: タグはコメント行の始めで`@`や`@!`のプレフィックスと共に始まり、
    すぐ次にタグ名、そして任意のタグデータ(もしタグにそれが必要なら)
    別に必要ない場合は
    タグ用のドキュメントを指定し、
    全ての"説明"のテキストはフリーフォームのデータと見なされ、
    任意の原文のデータを含む事ができる。

en: ### Multi-line Tags
ja: ### 複数行のタグ

en: Tags can span multiple lines if the subsequent lines are indented by more than
    one space. The typical convention is to indent subsequent lines by 2 spaces.
    In the following example, `@tagname` will have the text *"This is indented tag data"*:
ja: タグは後続の行が一つ以上のスペースでインデントされる場合、複数の行に渡る事もできる。
    一般的な慣習は2つのスペースによって続く行をする。
    次の例の`@tagname`は *"This is indented tag data"* のテキストを持つ:

en: For most tags, newlines and indented data are not significant and do not impact
    the result of the tag. In other words, you can decide to span a tag onto multiple
    lines at any point by creating an indented block. However, some tags like
    {tag:example}, {tag:overload}, {tag:!macro}, {tag:!method}, and {tag:!attribute}
    rely on the first line for special information about the tag, and you cannot
    split this first line up. For instance, the {tag:example} tag uses the first line
    to indicate the example's title.
ja: 殆どのタグで、改行とインデントされたデータは
    重要でないしタグの結果に影響しない。
    つまり、あなたは
    インデントされたブロックを作成する事によって全てのポイントで
    複数行の上のタグに渡すのを決定できる。
    しかしながら、
    {tag:example}, {tag:overload}, {tag:!macro}, {tag:!method}, {tag:!attribute}のような、
    いくつかのタグはタグについて特別な情報用に最初の行を頼り、
    あなたはこの最初の行を分割できない。
    例えば、{tag:example} タグは例のタイトルを指示するために最初の行を使う。

en: ### Common Tag Syntaxes
ja: ### 一般的なタグ構文

en: Although custom tags can be parsed in any way, the built-in tags follow a few
    common syntax structures by convention in order to simplify the syntax. The
    following syntaxes are available:
ja: カスタムタグはどの方法でも解析され、
    ビルトインタグは、構文を簡単にする為に定められた
    いくつかの共通する構文構造に従う。
    次の構文が用意されている。

en: 1. **Freeform data** &mdash; In this case, any amount of textual data is allowed,
      including no data. In some cases, no data is necessary for the tag.
    2. **Freeform data with a types specifier list** &mdash; Mostly freeform data
      beginning with an *optional* types specifier list surrounded in `[brackets]`.
      Note that for extensibility, other bracket types are allowed, such as `<>`,
      `()` and `{}`. The contents of the list are discussed in detail below.
    3. **Freeform data with a name and types specifier list** &mdash; freeform
      data beginning with an *optional* types list, as well as a name key. The
      name key is *required*. Note that for extensibility, the name can be placed
      *before* the types list, like: `name [Types] description`. In this case,
      a separating space is not required between the name and types, and you
      can still use any of the other brackets that the type specifier list allows.
    4. **Freeform data with title** &mdash; freeform data where the first line cannot
      be split into multiple lines. The first line must also always refer to the
      "title" portion, and therefore, if there is no title, the first line must
      be blank. The "title" might occasionally be listed by another name in tag
      documentation, however, you can identify this syntax by the existence of
      a multi-line signature with "Indented block" on the second line.
ja: 1. **フリーフォームデータ** &mdash; この場合は全ての単語のデータの総量は許可され、
    データを含まない。場合によってはデータ無しではタグを必要としない。
    2. **型指定のリストを用いたフリーフォームデータ** &mdash; 大抵のフリーフォームデータは
    *optional(任意の)* の`[brackets(括弧)]`で囲まれた型指定のリストを用いて始まっている。
    拡張用に留意する事として、
    `<>`、`()`、`{}`などとして他のブラケットの型は許可される。
    リストの内容は下の詳細で議論される。    
    3. **名前と型指定のリストを用いたフリーフォームデータ** &mdash; フリーフォームデータは
    *optional(任意の)*型のリストもキーの名前も用い始まるデータ。
    キーの名前は *必須* である。
    拡張性について次のことに留意する。
    名前は型のリストの前に置く事ができる:`name [Types] description`。
    この場合は、区切りのスペースはnameとtypesの間に必要ではない。
    そしてあなた型指定のリストの許可の他のbracket(括弧)の何かを使う事ができる。
    4. **タイトルを用いたフリーフォームデータ** &mdash; 最初の行のところのフリーフォームデータは
    複数の行へ分割できない。
    最初の行は常に"title"の場所とそれ自身を参照しなければならない。
    タイトル無しの場合は、
    最初の行はブランクにしなければならない。
    "title"は時々、タグのドキュメントの中で他の名前によって記述される。
    しかしながら、あなたは2番目の行の"インデントされたブロック"を用い
    複数行のシグネチャの存在によってこの構文を認証できる

en: In the tag list below, the term "description" implies freeform data, `[Types]`
    implies a types specifier list, "name" implies a name key, and "title" implies
    the first line is a newline significant field that cannot be split into multiple
    lines.
ja: 下のタグのリストでは、
    "description"の用語はフリーフォームデータを意味し、
    `[Types]`は型指定のリストを意味する。
    "name"はキーの名前を意味し、
    最初の行を意味する"title"は改行で複数行へ分割できない特殊なフィールドである

en: ### Types Specifier List
ja: ### 型指定のリスト

en: In some cases, a tag will allow for a "types specifier list"; this will be evident
    from the use of the `[Types]` syntax in the tag signature. A types specifier list
    is a comma separated list of types, most often classes or modules, but occasionally
    literals. For example, the following {tag:return} tag lists a set of types returned
    by a method:
ja: 幾つかの場合、タグは"型指定のリスト"用に許可する。
    これはタグのシグネチャの中の`Types`の構文の利用から明らかである。
    型指定のリストはコンマで区切られた型のリストである。
    ほとんどはクラスやモジュールで、時々、リテラルである。
    例えば、次の{tag:return}タグのリストはメソッドによって返された型のグループを記述する:

en:     # Finds an object or list of objects in the db using a query
        # @return [String, Array<String>, nil] the object or objects to
        #   find in the database. Can be nil.
        def find(query) finder_code_here end
ja:     # queryによってdbの中のオブジェクトやオブジェクトのリストを見つける
        # @return [String, Array<String>, nil] the object or objects to
        #   find in the database. Can be nil.
        def find(query) finder_code_here end

en: A list of conventions for type names is specified below. Typically, however,
    any Ruby literal or class/module is allowed here. Duck-types (method names
    prefixed with "#") are also allowed.
ja: 型の名前用の慣習的なリストは下で指定される。
    しかしながら一般的にRubyのリテラルやクラス/モジュールはここで許可される。
    ダックタイピング(プレフィックスされたメソッド名を用いた"#")も許可される。

en: Note that the type specifier list is always an optional field and can be omitted
    when present in a tag signature. This is the reason why it is surrounded by
    brackets. It is also a freeform list, and can contain any list of values, though
    a set of conventions for how to list types is described below.
ja: 留意する事として次の事がある。
    型指定のリストは常に任意のフィールドとなり
    タグのシグネチャを示す時にタグ構文の中で残される。
    これがbracket(括弧)によってとりかこまれる理由である。
    フリーフォームのリストも、任意のリストの値を含む事ができる。
    どんな型をリストにするかの慣習のグループは下で説明される。

en: ### Type List Conventions
ja: ### 型のリストの慣習

en: Typically, a type list contains a list of classes or modules that are associated
    with the tag. In some cases, however, certain special values are allowed or required
    to be listed. This section discusses the syntax for specifying Ruby types inside of
    type specifier lists, as well as the other non-Ruby types that are accepted by
    convention in these lists.
ja: 一般的に、型のリストはタグに関連付けられるクラスやモジュールのリストを含んでいる。
    しかしながら、幾つかの特別な値は記述される為に許可され,受入られる。
    このセクションは型の指定のリストの内部のRubyの型の指定用の構文も、
    これらのリストの中の慣例によって認められる他のRubyではない型も議論する。

en: It's important to realize that the conventions listed here may not always adequately
    describe every type signature, and is not meant to be a complete syntax. This is
    why the types specifier list is freeform and can contain any set of values. The
    conventions defined here are only conventions, and if they do not work for your
    type specifications, you can define your own appropriate conventions.
ja: ここで慣例で記述されたものは常に
    全ての型のシグネチャを説明しないのと
    完璧な構文であるというのは意味しないという事を
    理解するのが重要である。
    型の指定のリストがフリーフォームなのは任意の値のグループを含むことができるからである。
    ここで定義された慣例はここだけの慣例で、これはあなたの型の指定用には動作しない。
    あなたは自身の適切な慣例を定義できる。

en: Note that a types specifier list might also be used for non-Type values. In this
    case, the tag documentation will describe what values are allowed within the
    type specifier list.
ja: 次の事に留意する。
    型の指定のリストは型ではない値にも使われるかもしれない。
    この場合は,タグのドキュメントは
    どの値が型の指定のリストの中で許可されるのかを説明する。

en: #### Class or Module Types
ja: #### クラスやモジュールの型

en: Any Ruby type is allowed as a class or module type. Such a type is simply the name
    of the class or module.
ja: Rubyの型はクラスやモジュールを受け入れる。
    タイプなどは単純にクラスやモジュールの名前である。

en: Note that one extra type that is accepted by convention is the `Boolean` type,
    which represents both the `TrueClass` and `FalseClass` types. This type does not
    exist in Ruby, however.
ja: 次の事に留意する。
    `Boolean`の型は慣例によって受入れられる追加の型で
    `TrueClass`と`FalseClass`の型の両方を表す。
    この型はRubyの中に存在しない。

en: #### Parametrized Types
ja: #### パラメータ化された型

en: In addition to basic types (like String or Array), YARD conventions allow for
    a "generics" like syntax to specify container objects or other parametrized types.
    The syntax is `Type<SubType, OtherSubType, ...>`. For instance, an Array might
    contain only String objects, in which case the type specification would be
    `Array<String>`. Multiple parametrized types can be listed, separated by commas.
ja: 基本の型(StringやArrayのような)に更に、YARDの慣例は
    コンテナオブジェクトや他のパラメータ化された型を指定するための構文のような
    "generics(総称的な)"の為に許可する。
    構文は`Type<SubType, OtherSubType, ...>`となる
    例えば、配列は文字列オブジェクトだけを含んでいるかもしれない。
    その場合の型の指定は`Array<String>`になる。
    複数のパラメータ化された型はカンマによって区切られ記述される。

en: Note that parametrized types are typically not order-dependent, in other words,
    a list of parametrized types can occur in any order inside of a type. An array
    specified as `Array<String, Fixnum>` can contain any amount of Strings or Fixnums,
    in any order. When the order matters, use "order-dependent lists", described below.
ja: 次のことに留意する。
    パラメータ化された型は一般的に順番に依存せず、
    いいかえれば、パラメータ化された型のリストは
    型の内部で好きなの順番におく事ができる。
    `Array<String, Fixnum>` などとして指定された配列はStringやFixnumの総量を
    任意の順番で含む事ができる。
    順番が問題になる時は、
    下で説明される"order-dependent lists(順番依存のリスト)"を使う:

en: #### Duck-Types
ja: #### ダックタイピング

en: Duck-types are allowed in type specifier lists, and are identified by method
    names beginning with the "#" prefix. Typically, duck-types are recommended
    for {tag:param} tags only, though they can be used in other tags if needed.
    The following example shows a method that takes a parameter of any type
    that responds to the "read" method:
ja: ダックタイピングは型指定のリストを受入れ、
    "#"プレフィックス(接頭辞)を用いた最初のメソッド名によってインデントされる。
    一般的にダックタイピングは {tag:param} タグだけに推奨されているが、
    必要なら他のタグで利用する事もできる。
    次の例は"read"メソッドに返事をする任意の型のパラメータを
    取得するメソッドを一覧できる:

en:     # Reads from any I/O object.
        # @param [#read] io the input object to read from
        def read(io) io.read end
ja:     # 任意のI/O オブジェクトから読み込む
        # @param [#read] io the input object to read from
        def read(io) io.read end

en: #### Hashes
ja: #### ハッシュ

en: Hashes can be specified either via the parametrized type discussed above,
    in the form `Hash<KeyType, ValueType>`, or using the hash specific syntax:
    `Hash{KeyTypes=>ValueTypes}`. In the latter case, KeyTypes or ValueTypes can
    also be a list of types separated by commas.
ja: ハッシュは上で議論されたパラメータ化された型、
    `Hash<KeyType, ValueType>` 形式経由か
    もしくは次の指定のハッシュ構文を使う:
    `Hash{KeyTypes=>ValueTypes}` 
    後者の場合、KeyTypesやValueTypesはカンマで区切られた型のリストにもできる。

en: #### Order-Dependent Lists
ja: #### Order-Dependent Lists(順番依存のリスト)

en: An order dependent list is a set of types surrounded by "()" and separated by
    commas. This list must contain exactly those types in exactly the order specified.
    For instance, an Array containing a String, Fixnum and Hash in that order (and
    having exactly those 3 elements) would be listed as: `Array<(String, Fixnum, Hash)>`.
ja: 順番依存のリストは"()"によって囲われた型のグループであり、
    カンマによって区切られる。
    このリストは正確に順番の指定された中で正確にそれらの型を含まなければならない。
    例えばString,Fixnum,Hashの順番の(それは3つの属性をもっている)配列は、
    `Array<(String, Fixnum, Hash)>` として記述される。

en: #### Literals
ja: #### リテラル

en: Some literals are accepted by virtue of being Ruby literals, but also by YARD
    conventions. Here is a non-exhaustive list of certain accepted literal values:
ja: 幾つかのリテラルはRubyのリテラルにある利点を受け入れるが、
    YARDによる慣例もある。
    ここで紹介するのは明確に受入れられたリテラルの網羅的なリストではない。

en: * `true`, `false`, `nil` &mdash; used when a method returns these explicit literal
      values. Note that if your method returns both `true` or `false`, you should use
      the `Boolean` conventional type instead.
    * `self` &mdash; has the same meaning as Ruby's "self" keyword in the context of
      parameters or return types. Recommended mostly for {tag:return} tags that are
      chainable.
    * `void` &mdash; indicates that the type for this tag is explicitly undefined.
      Mostly used to specify {tag:return} tags that do not care about their return
      value. Using a `void` return tag is recommended over no type, because it makes
      the documentation more explicit about what the user should expect. YARD will
      also add a note for the user if they have undefined return types, making things
      clear that they should not use the return value of such a method.
ja: * `true`, `false`, `nil` &mdash; メソッドがこれらの明確なリテラル値を返す時に
      利用される。次の事に留意する。
      あなたのメソッドが `true` や `false` 両方を返す場合、
      代わりにあなたは `Boolean` の慣例の型を使わなければならない。
    * `self` &mdash; パラメータや戻りの型のコンテキストでRubyの"self"キーワードのように
      同じ意味を持つ。
      大体はチェーン可能な {tag:return} タグが推奨される。
    * `void` &mdash; このタグが明確に未定義とされる型を指示する。
      一般的にそれらの戻り値について気にしない {tag:return} タグに利用される。
      `void` return タグを使う事によって、型がない事を知らせ、
      ユーザーが期待する事についての明確な情報のドキュメントを作れる。
      未定義の戻りの型を持つ場合、YARDはユーザーの為に注釈も追加し、
      それらのメソッドなどの戻り値を使わないものを明らかにする。

en: If a tag's data begins with `(see OBJECT)` it is considered a "reference tag".
    A reference tag literally copies the tag data by the given tag name from the
    specified OBJECT. For instance, a method may copy all {tag:param} tags from
    a given object using the reference tag syntax:
ja: `(see OBJECT)` を用い始まるタグデータの場合"参照タグ"と見なす。
    参照タグは文字通り指定されたオブジェクトから与えられたタグ名によって
    タグデータをコピーする。
    例えばメソッドは次の参照タグ構文によって
    与えられたオブジェクトから全ての {tag:param} タグをコピーする。

en: Custom tags can be added to YARD either via the command-line or programmatically.
    The programmatic method is not discussed in this document, but rather in the
    {file:docs/TagsArch.md} document.
ja: カスタムタグはコマンドラインかプログラム経由でYARDに追加される。
    プログラム的なメソッドはこのドキュメントの中で議論しないが、
    {file:docs/TagsArch.md} のドキュメントで参照できる。

en: To add a custom tag via the command-line or .yardopts file, you can use the
    `--*-tag` options. A few different options are available for the common tag
    syntaxes described above. For example, to add a basic freeform tag, use:
ja: コマンドラインや.yardoptsファイル経由でカスタムタグを追加するには、
    `--*-tag` オプションを使う事ができる。
    少数の異なるオプションは上で議論された一般的なタグ構文用に利用可能である。
    例えば、基本のフリーフォームタグに追加するには次のようになる:

en: This will register the `@rest_url` tag for use in your documentation and display
    this tag in HTML output wherever it is used with the heading "REST URL".
    Note that the tag title should follow the tag name with a colon (`:`). Other
    tag syntaxes exist, such as the type specifier list freeform tag
    (`--type-tag`), or a named key tag with types (`--type-name-tag`).
ja: これはあなたのドキュメントで利用するため `@rest_url` タグが追加され、
    "REST URL"の表題と一緒にHTML出力でこのタグを表示する。
    次の事に留意する。
    タグタイトルは次のコロンを用いた(`:`)タグ名にしなければならない。
    他のタグ構文は型指定のリストのフリーフォームタグの(`--type-tag`)や
    (`--type-name-tag`)の型を用いるキー名のタグなどが存在する。

en: If you want to create a tag but not display it in output (it is only for
    programmatic use), add `--hide-tag tagname` after the definition:
ja: あなたがタグを作成する為にほしい場合
    しかしその出力で表示しない場合(プログラム的にだけ利用する)
    定義の後で `--hide-tag tagname` を追加する:

en: Note that you might not need a tag title if you are hiding it. The title
    part can be omitted.
ja: 次の事に留意する。
    あなたはタグタイトル隠す場合は必要としないかもしれない。
    タイトルの一部は除外できる。

en: Tags Architecture
ja: タグ構造

en: # Tags Architecture
ja: # タグ構造

en: ## Programmatic API
ja: ## プログラムのAPI

en: ### Accessing Tag Information
ja: ### タグの情報を使う

en: Tag metadata is added when a {YARD::Docstring} is added to a {file:docs/CodeObjects.md code object}
    using the {YARD::CodeObjects::Base#docstring=} attribute. In addition to adding
    conventional comments, tags are parsed and associated with the object. The easiest
    way to access tags on an object is to use the {YARD::CodeObjects::Base#tag} and `#tags`
    methods, for example:
ja: タグのメタデータは{YARD::Docstring}が
    {YARD::CodeObjects::Base#docstring=} 属性を用い
    {file:docs/CodeObjects.md コードオブジェクト} の為に追加される時、追加される。
    通常型のコメントをつけることに加えて、タグは解析され、オブジェクトと関係付けられる。
    オブジェクトのタグにアクセスするのに最も簡単な方法は、
    {YARD::CodeObjects::Base#tag} や `#tags` メソッドを利用することである。
    例えば:

en:     # Using the Foo class object from above
        obj.tags(:tagname).first.text #=> "some data"
ja:     # 上からFooクラスオブジェクトを使う
        obj.tags(:tagname).first.text #=> "some data"

en: Because multiple tags can be stored with the same name, they are stored as a list
    of tags. The `#tag` method is an alias for the first item in the list of tags.
    Also note that the `#tag`, `#tags` and `#has_tag?` methods are all convenience
    methods that delegate to the {YARD::Docstring} object described above.
ja: 同じ名前の複数のタグが格納されることもあるので、
    それらはタグのリストとなっている。
    `#tag` メソッドはタグのリストにおける最初のアイテムのエイリアスである。
    また、the `#tag`についても述べておく。
    `#tags` と `#has_tag?` のメソッドは上で記述された{YARD::Docstring}
    オブジェクトを委譲する便利なメソッドである。

en: ### Adding Custom Tags
ja: ### カスタムタグを付ける

en: The `@tagname` tag used in the above examples is clearly not part of the tags
    that come with YARD. If such a tag would actually be part of documentation under
    a default install, YARD would raise a warning that the tag does not exist. It is,
    however, trivial to add this tag to be recognized by YARD.
ja: 前記の例などで使われている@tagnemeタグは明らかにYARDに存在するタグの一部ではない。
    もしそのようなタグがデフォルトでインストールされたドキュメントの一部であれば、
    YARDはそのようなタグは存在していないという警告を出すだろう。
    つまり、YARDによって認識されるためのタグを付けることは、
    重要ではない。

en: All tags in YARD are added to the {YARD::Tags::Library tag library} which makes
    use of a tag factory class to parse the data inside the tags. To simply add a
    tag that stores simple text like our `@tagname` tag above, use:
ja: YARDのすべてのタグは{YARD::Tags::Library tag library}に追加される。
    {YARD::Tags::Library tag library}はタグの中のデータを解析する為に、
    タグファクトリークラスを利用している。
    @tagnameタグのように単純なテキストを収納したタグを追加するなら、
    次のようになる:

en: This will now allow YARD to add the metadata from `@tagname` to the docstring.
ja: docstringに`@tagname`からメタデータをつけることをYARDに許可する。

en: ## Tag Factory Architecture
ja: ## タグファクトリー構造

en: Recognizing a tag is one part of the process. Parsing the tag contents is the
    second step. YARD has a tag architecture that allows developers to add or completely
    change the way tags contents can be parsed.
ja: タグを認識することはプロセスの一部である。
    タグの中身を解析するのは第二段階となる。
    YARDはタグの構造を持っている。
    タグの構造によって、
    開発者は中身が解析可能なタグを加えたり変更したりすることができる。

en: The separation of registration and tag creation can be seen in the following
    class diagram:
ja: 登録の分離やタグ作成は次の表の通り。

en: ### DefaultFactory
ja: ### デフォルトファクトリー

en: By default, YARD has a few standard syntaxes that can be parsed for tags. These
    are all implemented by the {YARD::Tags::DefaultFactory} class. These syntaxes
    are:
ja: デフォルトで、YARDはタグを解析するいくつかの標準の構文を持っている。
    それらはすべて {YARD::Tags::DefaultFactory}クラスで実装されている。
    これらの構文は以下のとおり。

en:   * Standard text: no parsing is done, but text is stripped of newlines and
        multiple spaces.
ja:   * Standard text: 解析されていない。
        しかしテキストは新しい行や多重のスペースが取り除かれている。

en:   * Raw text: does no parsing at all, no stripping of newlines or spaces. This
        is best used for code snippets.
ja:   * Raw text: まったく解析していない、新しい行やスペースは取り除かれていない。
        これはコードスニペットによく使われる。

en:   * Raw text with title: does no parsing on the text but extracts the first line
        of the metadata as the "title", useful for tags such as `@example`:
ja:   * Raw text with title: テキストの上では解析していないが、
        メタデータの最初の行を"title"として抽出する。以下の `@example` のようなタグで便利である:

en:   * Text with types: parses a list of types at the beginning of the text. Types
        are optional. The standard syntax is in the form `[type1, type2, ...]`,
        for example:
ja:   * Text with types: テキストの最初の部分で型のリストを解析する。型は任意で指定できる。
    標準的な構文は`[type1, type2, ...]`という型をしている。例えば:

en:   * Text with types and a name: parses a list of types at the beginning of text
        followed by a name and extra descriptive text. For example:
ja:   * Text with types and a name: 名前や説明文が続くテキストの最初の部分で
    型のリストを解析する。例えば:

en: As mentioned above, this syntax is implemented by the `DefaultFactory` which can
    be swapped out for any factory. In some cases, a developer may want to change
    the type declaration syntax to be in the form:
ja: 上述のように、この構文はDefaultFactoryで実装されている。
    DefaultFactoryは任意のfactoryに交換されることができる。
    時には、開発者はfactory構造の型宣言構文を変えることができる。

en:     # @tagname name <Types, here> description
ja:     # @tagname 名前 <型..., here> 説明

en: This can be done by simply implementing a new factory that parses the data in
    this form.
ja: このフォームの中でデータを解析する新しいファクトリーを実装するだけでよい。

en: ### Implementing a Factory
ja: ### ファクトリー実装する

en: Factories should implement the method `parse_tag` as well as any `parse_tag_SUFFIX`
    method where SUFFIX refers to the suffix added when declaring the tag. For example,
    a tag can also be declared as follows:
ja: ファクトリーはタグが宣言される時に、 `parse_tag_SUFFIX` メソッドのように
    `parse_tag` メソッドが実装される。例えば、次のようにタグを定義できる。

en: In such a case, the factory will be called with method `parse_tag_with_types`. In
    all cases, the method should return a new {YARD::Tags::Tag} object. Generally,
    the `parse_tag` methods take 2 or 3 parameters. A simple tag can be implemented
    as:
ja: 上のようなケースでは、ファクトリーは `parse_tag_with_types` とともに呼び出される。
    メソッドは新しい{YARD::Tags::Tag}オブジェクトを必ず返さなければならない。
    一般に、 `parse_tag` メソッドは2つか3つの引数を取得する。
    単純なタグは次のように実装することができる。

en: The text parameter contains pre-parsed text with extra spaces and newlines removed.
    If required, the method could also be declared with a third parameter containing
    unmodified raw text:
ja: テキストパラメータは、
    余分な空白と改行を削除するよう事前解析したテキストが含まれている。
    もし必要なら以下のように、
    3つ目の引数を用いて修正されていない生テキストを含めて宣言できる。

en: Note that this method would be invoked for a tag declared with the `:with_raw_text`
    suffix.
ja: 次の事に留意する。
    このメソッドはwith_raw_text suffixとともに宣言されたタグのために呼び出される。

en: ### Changing the Factory
ja: ### ファクトリーを変更する

en: To change the factory, set the {YARD::Tags::Library.default_factory} attribute:
ja: ファクトリーを変更する為には、
    以下の様に{YARD::Tags::Library.default_factory}属性を設定する。

en: This must be done before any parsing is done, or the factory will not be used.
ja: これは解析が完了する前にしなければならない、でなければfactoryは使えない。

en: Templates Architecture
ja: テンプレート構造

en: # Templates Architecture
ja: # テンプレート構造

en: Templates are the main component in the output rendering process of YARD,
    which is invoked when conventional HTML/text output needs to be rendered
    for a set of code objects.
ja: テンプレートは、YARDの処理を表示出力するのが主な内容となる。
    そして、コードオブジェクトの集まりを表示する為に
    従来のHTML/text出力が必要な時呼び出される。

en: ## Design Goals
ja: ## 設計目標

en: The general design attempts to be as abstracted from actual content and templates
    as possible. Unlike RDoc which uses one file to describe the entire template,
    YARD splits up the rendering of code objects into small components, allowing
    template modification for smaller subsets of a full template without having to
    duplicate the entire template itself. This is necessary because of YARD's support
    for plugins. YARD is designed for extensibility by external plugins, and because
    of this, no one plugin can be responsible for the entire template because no
    one plugin knows about the other plugins being used. For instance, if an RSpec
    plugin was added to support and document specifications in class templates,
    this information would need to be transparently added to the template to work
    in conjunction with any other plugin that performed similar template modifications.
    The design goals can be summarized as follows:
ja: おおまかな設計目標は
    テンプレートで、できるかぎり実際の内容から抽象化するのを試みる事である。
    RDocとは違って、
    YARDは、全てのテンプレートを説明する為に一つのファイルを利用し、
    コードオブジェクトの表示を分割し小さい構成とする。
    そして、テンプレートは
    全てのテンプレートが重複無しに
    最小のテンプレートの部分毎の修正を受け入れる
    これは、プラグインのYARDのサポートの為に
    必須となります。
    YARDは、外部のプラグインによる拡張性を考え設計されている。
    そんなわけで、プラグイン無しで全てのテンプレートを実行することが出来る。
    何故なら、プラグインが無い場合は、
    他のプラグインが利用される事について
    識別するからである。
    例えば、RSpecプラグインの場合、
    サポートが追加されたり、
    クラステンプレートの中の仕様が記述される。
    同様のテンプレートの改良を施した
    他のどんなプラグインを用いても、
    連携するできるよう、テンプレートが
    透過的に追加されることを必要とする。
    設計目標は、以下の様に要約される。

en:   1. Output should be able to be rendered for any arbitrary format with little
         modification to YARD's source code. The addition of extra templates should
         be sufficient.
      2. The output rendered for an object should independently rendered data
         from arbitrary sources. These independent components are called "sections".
      3. Sections should be able to be inserted into any object without affecting
         any existing sections in the document. This allows for easy modification
         of templates by plugins.
ja:   1. 出力はYARDのソースコードへの少ない変更で
         全て任意のフォーマット用に表示可能にすべきである。
         テンプレートの追加は充分なものにすべきである。
    
      2. オブジェクト用に表示される出力は、任意のソースから独自にデータを
         表示するべきである。
         これらの独自構成は"sections"を呼び出す。
    
      3. セクションはドキュメントの中の任意の存在するセクションへの影響無しで
         任意のオブジェクトに挿入される事を可能にするべきである。
         これはプラグインによるテンプレートの簡単な変更を受け入れる。

en: ## Templates
ja: ## テンプレート

en: Template modules are the objects used to orchestrate the design goals listed
    above. Specifically, they organize the sections and render the template contents
    depending on the format.
ja: テンプレートモジュールは上で記述した設計目標を実現する為に利用されるオブジェクトとなる。
    具体的にいうと、セクションを組織化したり、
    フォーマットに依存するテンプレートの内容を表示する。

en: ## Engine
ja: ## エンジン

en: The Engine class orchestrates the creation and rendering of Template modules and
    handles serialization or specific rendering scenarios (like HTML). To create
    a template, use the {YARD::Templates::Engine.template template} method. The two most
    common methods used to initiate output are the {YARD::Templates::Engine.render render}
    and {YARD::Templates::Engine.generate generate} methods which generate and
    optionally serialize output to a file. The latter, `#generate`, is used
    specially to generate HTML documentation and copy over assets that may be
    needed. For instance, an object may be rendered with:
ja: エンジンクラスは、
    作成とテンプレートモジュールの表示やシリアライズ処理や
    特定の表示(HTMLのような)を統合する。
    テンプレートを作成する為には、
    {YARD::Templates::Engine.template template}メソッドを使用する。
    出力を開始するために使われる二つの一般的なメソッドは
    {YARD::Templates::Engine.render render} と
    {YARD::Templates::Engine.generate generate} メソッドで
    生成しファイルに任意で出力をシリアライズする。
    その後で、 `#generate` メソッドは、
    HTMLドキュメントを生成するための特別に使用され,
    必要とされる資産をコピーする。
    例えば,オブジェクトが次の例を用い表示される場合:

en: A set of objects may be rendered into HTML documentation by using:
ja: オブジェクトの設定は、以下の記法を用いる事によってHTMLドキュメントで表示される。

en:     # all_objects is an array of module and class objects
        # options includes a :serializer key to copy output to the file system
        YARD::Templates::Engine.generate(all_objects, options)
ja:     # all_objects はモジュールの配列やクラスオブジェクトとなる
        # options はファイルシステムにコピー出力するの為に:serializerキーを含んでいる。
        YARD::Templates::Engine.generate(all_objects, options)

en: Note that these methods should not be called directly. The {YARD::CodeObjects::Base}
    class has a {YARD::CodeObjects::Base#format #format} helper method to render an
    object. For instance, the above render example is equivalent to the simple
    call `myobject.format`. The `generate` method is a special kind of render
    and is called from the {YARD::CLI::Yardoc} command line utility.
ja: 次の事に留意する。
    これらのメソッドは、直接呼び出されるべきではない。
    {YARD::CodeObjects::Base}クラスは
    オブジェクトを表示する為の
    {YARD::CodeObjects::Base#format #format} helper メソッドを
    持っている。
    例えば、上の表示の例は、
    単純な`myobject.format`呼び出しと同等である。
    `generate`メソッドは、特別な表示をし、
    そしてそれは、{YARD::CLI::Yardoc}コマンドラインから呼び出せる。

en: ## Template Options
ja: ## テンプレートオプション

en: A template keeps state when it is rendering output. This state is kept in
    an options hash which is initially passed to it during instantiation. Some
    default options set the template style (`:template`), the output format (`:format`),
    and the serializer to use (`:serializer`). This options hash is modifiable
    from all methods seen above. For example, initializing a template to output as
    HTML instead of text can be done as follows:
ja: テンプレートはそれが出力表示の時に状態を保持する。
    この状態はハッシュのオプションの中で保持される。
    そしは最初にインスタンス化される間に渡される。
    幾つかのデフォルトのオプションはテンプレートスタイル(`:template`)
    と出力フォーマット(`:format`)と(`:serializer`)を使うためのシリアライザーを設定する。
    このハッシュのオプションは上で見られた全てのメソッドから変更可能
    例えばテキストの代わりにHTMLとして出力するためにテンプレートを初期するには、次の様にできる。

en: ## Serializer
ja: ## シリアライザー

en: This class abstracts the logic involved in deciding how to serialize data to
    the expected endpoint. For instance, there is both a {YARD::Serializers::StdoutSerializer StdoutSerializer}
    and {YARD::Serializers::FileSystemSerializer FileSystemSerializer} class for
    outputting to console or to a file respectively. When endpoints with locations
    are used (like files or URLs), the serializer implements the {YARD::Serializers::Base#serialized_path #serialized_path}
    method. This allows the translation from a code object to its path at the endpoint,
    which enables inter-document linking.
ja: このクラスは期待された出力先へ
    データをシリアライズする為に、
    決定方法,関連するロジックを抽象化する。
    例えば、コンソールや個々のファイルの為の出力用の
    {YARD::Serializers::StdoutSerializer StdoutSerializer}と、
    {YARD::Serializers::FileSystemSerializer FileSystemSerializer} クラスがある。
    出力先が指定される時(ファイルやURLのような)、
    シリアライザーは、{YARD::Serializers::Base#serialized_path #serialized_path}メソッドを実装する。
    これは、コードオブジェクトから出力先のパスまでの翻訳を受け入れ、
    そして、内部のドキュメントのリンクを可能にする。

en: Rendered objects are automatically serialized using the object if present,
    otherwise the rendered object is returned as a string to its parent. Nested
    Templates automatically set the serializer to nil so that they return
    as a String to their parent.
ja: 表示されるオブジェクトが存在する場合は,
    オブジェクトによって自動的にシリアライズされる。
    それ以外の場合,表示されるオブジェクトはその親に文字列として返される。
    ネストされたテンプレートはnilに自動的にシリアライザーを設定する。
    なのでこれはそれらの親に文字列として返される。

en: ## Creating a Template
ja: ## テンプレート作成

en: Templates are represented by a directory inside the {YARD::Templates::Engine.template_paths}
    on disk. A standard template directory looks like the following tree:
ja: テンプレートは
    ディスク上の{YARD::Templates::Engine.template_paths}の中のディレクトリによって表される。
    標準的なテンプレートは次の木構造のようになる。

en: The path `default` refers to the template style (:template key in options hash)
    and the directories at the next level (such as `class`) refer to template
    `:type` (options hash key) for a template. The next directory refers to the
    output format being used defined by the `:format` template option.
ja: パスの `default` はテンプレートスタイル(:template key in options hash)を参照し
    次の階層でディレクトリは(例えば `class` など)
    テンプレート用のテンプレートの `:type` (ハッシュのオプションキー)を参照する。
    次のディレクトリは
    `:format` テンプレートオプションによって定義され、
    利用される出力フォーマットを参照する。

en: As we saw in the above example, the format option can be set to `:html`, which
    would use the `html/` directory instead of `text/`. Finally, the individual .erb
    files are the sections that make up the template.
ja: だれもが上の例で見た通り、
    フォーマットオプションは `:html` に設定でき、
    `text/` の代わりに `html/` ディレクトリを利用する。
    最終的に個々の.erbファイルは、テンプレートを作り上げるセクションである。

en: Note that the subdirectory `html/` is also its own "template" that inherits
    from the parent directory. We will see more on this later.
ja: 次の事に留意する。
    `html/` サブディレクトリは
    それ自身が親ディレクトリから継承する"テンプレート"でもある。
    この後の項で詳細がされる。

en: Every template should have at least one `setup.rb` file that defines the
    {YARD::Templates::Template#init #init} method to set the
    {YARD::Templates::Template#sections #sections} used by the template. If
    a setup.rb is not defined in the template itself, there should be a template
    that is inherited (via parent directory or explcitly) that sets the sections
    on a newly created template.
ja: 常にテンプレートは少なくとも
    テンプレートによって利用した{YARD::Templates::Template#sections #sections}を設定するために
    {YARD::Templates::Template#init #init}メソッドを定義する
    `setup.rb` ファイルを持つ。
    setup.rbがテンプレートの中で未定義の場合は、
    新規に作成されたテンプレート上のセクションを設定し、
    継承される(親のディレクトリや明示的に)テンプレートになるべきである。

en: A standard setup.rb file looks like:
ja: 標準的なsetup.rbファイルは以下のように見える。

en: ## Sections
ja: ## セクション

en: Sections are smaller components that correlate to template
    fragments. Practically speaking, a section can either be a template fragment
    (a conventional .erb file or other supported templating language), a method
    (which returns a String) or another {YARD::Templates::Template} (which in turn has its own
    list of sections).
ja: セクションはテンプレートフラグに関連するより小さい構成要素である。
    事実上、セクションはいづれかの
    テンプレートの
    フラグ(慣習で.erbファイルや他にサポートされたテンプレート言語),
    メソッド(文字列を返す)やそれ以外{YARD::Templates::Template}にできる
    (言い換えればセクションの自身のリストを持つ)

en: ## Nested Sections
ja: ## ネストしたセクション

en: Sections often require the ability to encapsulate a set of sub-sections in markup
    (HTML, for instance). Rather than use heavier Template subclass objects, a more
    lightweight solution is to nest a set of sub-sections as a list that follows
    a section, for example:
ja: セクションは時々マークアップで
    サブセクションのグループを要約するのに能力を必要とする。(例えばHTML)
    サブクラスオブジェクトのより重いテンプレートを使うより、
    より軽い答えが
    次のセクションのリストとしてサブセクションのグループをネストする事である。
    例えば:

en: The above example nests `section_a` and `section_b` within the `header` section.
    Practically speaking, these sections can be placed in the result by `yield`ing
    to them. A sample header.erb template might contain:
ja: 上の例は、 `header` セクションの中に
    `section_a` と `section_b` をネストする。
    具体的には、これらのセクションは、
    `yield` する事によってその結果の中に置かれる。
    例のheader.erbテンプレートは以下を含んでいる

en: This template code would place the output of `section_a` and `section_b` within
    the above div element. Using `yieldall`, we can also change the object that is being
    rendered. For example, we may want to yield the first method of the class.
    We can do this like so:
ja: このテンプレートのコードは、
    上のdiv属性の中で `section_a` と `section_b` の
    出力ををセットする。
    `yieldall` によって私達は、
    表示されるオブジェクトを変更もできる。
    例えばクラスの最初のメソッドをyieldの為にしたいとすると、
    以下のようにできる。

en: This would run the nested sections for the method object instead of the class.
ja: これは、クラスの代わりにメソッドオブジェクト用のネストされたセクションを起動する。

en: Note that `yieldall` yields to all subsections, whereas `yield` will yield
    to each individually (in order) until there are no more left to yield to.
    In the vast majority of cases, you'd want to use `yieldall`, since `yield`
    makes it hard for users to override your template.
ja: 次の事に留意する。
    `yieldall` は全ての下位セクションをyieldするのに対して、
    `yield` は、要素が無くなるまで個々に(順番に)yieldする。
    多くの場合あなたは `yieldall` を使いたいと思っただろう。
    `yield` はユーザーがあなたのテンプレートを上書きする為に
    確実に実行するからである。

en: ## Inheriting Templates
ja: ## 継承するテンプレート

en: Parent directory templates are automatically inherited (or mixed in, to be
    more accurate) by the current template. This means that the 'default/class/html'
    template automatically inherits from 'default/class'. This also means that anything
    defined in 'default/class/setup.rb' can be overridden by 'default/class/html/setup.rb'.
ja: 親のディレクトリのテンプレートは
    現在のテンプレートによって自動的に継承される。
    (または、正確にはmix-inされる)
    つまり 'default/class/html' テンプレートは、
    'default/class'から自動的に継承する。
    そして 'default/class/setup.rb' の中に定義されるもの全ては、
    'default/class/html/setup.rb' によって上書きされることも意味する。
    (yard/lib以下の話ではなくyard/templates以下の話)

en: Since the Template module is a module, and not a class, they can be mixed in
    explicitly (via include/extend) from other templates, which allows templates
    to share erb files or helper logic. The 'default/class' template explicitly
    mixes in the 'default/module' template, since it uses much of the same sections.
    This is done with the helper {YARD::Templates::Template::ClassMethods#T T} method, which
    is simply a shorthand for {YARD::Templates::Engine.template Engine.template}.
    It can then override (using standard inheritance) the sections from the module
    template and insert sections pertaining to classes. This is one of the design
    goals described above.
ja: Templateモジュールはモジュールであり,クラスではない。
    他のテンプレートから(include/extend経由)明示的に混ぜられ、
    erbファイルやヘルパーロジックを共有するためにテンプレートを受け入れる。
    'default/class'テンプレートは明示的に'default/module'テンプレートの中で混ぜられ、
    同じセクションを使う。
    これはヘルパーメソッドの {YARD::Templates::Template::ClassMethods#T T} を用い完了し、
    それは単純に{YARD::Templates::Engine.template Engine.template}用の略記法で、
    その時モジュールのテンプレートからセクションを上書き(標準の継承を使う事によって)できる
    そしてクラスに付随するセクションを挿入する。
    これは上で説明された設計目標の一つである。

en: For instance, the first line in `default/class/html/setup.rb` is:
ja: 例えば `default/class/html/setup.rb` の中の最初の行は以下のように:

en: This includes the 'default/module/html', which means it also includes 'default/module'
    by extension. This allows class to make use of any of module's erb files.
ja: この'default/module/html'のincludeは、
    拡張によって'default/module'を含める意味となる。
    この拡張は任意でerbモジュールのファイルから利用するクラスを受け入れる。

en: ## Inserting and Traversing Sections
ja: ## 挿入とトラバース(辿る)セクション

en: The ability to insert sections was mentioned above. The class template, for
    instance, will modify the #init method to insert class specific sections:
ja: 挿入セクションの機能は上で述べた。
    テンプレートクラス、例えば、
    以下のクラスの特定のセクションを挿入する為に#initメソッドを変更する:

en: Observe how sections has been modified after the super method was called (the
    super method would have been defined in `default/module/setup.rb`). The
    `sections` object is of the {YARD::Templates::Section} class and allows sections to be inserted
    before or after another section using {Array#place} by it's given name rather
    than index. This allows the overriding of templates in a way that does not
    depend on where the section is located (since it may have been overridden by
    another module).
ja: superメソッドが呼び出された後でセクションが変更されたか確認する。
    (superメソッドは `default/module/setup.rb` で定義されている)
    `sections`オブジェクトは{YARD::Templates::Section}クラスのであり、
    インデックスより与えられた名前によって
    {Array#place}を使う事によって
    他のセクションの前後で挿入されるセクションを受け入れる
    これはセクションが示されるところに依存しない方法で
    テンプレートの上書きを受け入れる。
    (なので他のモジュールによって上書きされるかもしれない)

en: You can also use `sections[:name]` to find the first child section named `:name`.
    For instance, with the following sections declaration:
ja: あなたは、 `:name` と名付けられた最初の子のセクション名を探す為に
    `sections[:name]` を利用できる。
    例えば、次のようなセクション宣言を用いる。

en: You can get to the :d section with:
ja: 次のようにすると、:dセクションを取得できる。

en: You can use this to insert a section inside a nested set without using indexed
    access. The following command would result in `[:a, [:b, :c, [:d, :e]]]`:
ja: アクセスを索引しないで、
    ネストした集合の内部の
    セクションを挿入する為に
    これを利用できる。<
    次のコマンドは `[:a, [:b, :c, [:d, :e]]]` の様な結果になる。

en: There are also two methods, {Insertion#before_any} and {Insertion#after_any},
    which allow you to insert sections before or after the first matching section name
    recursively. The above example could simply be rewritten as:
ja: 二つのメソッド、{Insertion#before_any}と{Insertion#after_any}がある。
    これは、再帰的に最初にマッチするセクション名の前後のセクションへの挿入を可能にする。
    上の例は、単純に次のように書き換えできた。

en: ## Overriding Templates by Registering a Template Path
ja: ## テンプレートパスを記録しテンプレートを上書き

en: Inheriting templates explicitly is useful when creating a customized template
    that wants to take advantage of code re-use. However, most users who want
    to customize YARD templates will want to override existing behaviour without
    creating a template from scratch.
ja: 明示的に継承するテンプレートは、
    再利用したいコードのテンプレートを
    カスタマイズし作成する時に便利である。
    しかしながら、一般的なYARDテンプレートをカスタマイズしたいユーザーは、
    下書きからテンプレートの作成無しで既存の挙動を上書きしたいだろう。

en: YARD solves this problem by allowing other template paths to be registered.
    Because template modules are represented by a relative path such as 'default/class',
    they can be found within any of the registered template paths. A new template
    path is registered as:
ja: YARDは記録される他のテンプレートパスを
    受け入れる事によってこの問題を解決する。
    何故なら、テンプレートモジュールは、
    'default/class'のような、相対パスによって表される。
    それは、テンプレートパスの記録される全ての中で見られる
    新しいテンプレートは、次のように記録される。

en: At this point, any time the 'default/class' template is loaded, the template
    will first be looked for inside the newly registered template path. If found,
    it will be used as the template module, with the modules from the other
    template paths implicitly mixed in.
ja: この場所で、毎回、'default/class'テンプレートは、ロードされる。
    テンプレートは
    新しく記録したテンプレートパス内部に最初に固定される。
    もし見つかった場合、
    暗黙の内にmix-inされる他のテンプレートパスからモジュールと共に、
    テンプレートモジュールのように利用される。

en: Therefore, by using the same directory structure as a builtin YARD template,
    a user can customize or override individual templates as if the old ones were
    inherited. A real world example would further modify the 'default/class' template
    seen above by creating such a path in our '/path/to/mytemplates' custom template
    path:
ja: 従って組み込みのYARDのテンプレートとして同じディレクトリ構造体を
    使うことによってユーザーはカスタマイズできたり、
    古いものが継承される場合など個々のテンプレートを上書きできる。
    実際の例は、
    更に例の'/path/to/mytemplates'のカスタムテンプレートパスの中のパスなど作成することによって
    上で見た'default/class'テンプレートを変更する。

en: The `setup.rb` file would look like:
ja: `setup.rb` ファイルは次の様になる。

en: Now, when a class object is formatted as HTML, our customsection.erb will be
    appended to the rendered data.
ja: クラスオブジェクトがHTMLとしてフォーマットされる時は、
    例のcustomsection.erbは表示されるデータに適用される。

en: ### Overriding Stylesheets and Javascripts
ja: ### スタイルシートとJavascriptsを上書きする。

en: Template authors can override existing stylesheets and javascripts by creating
    a file with the same name as existing files within the `fulldoc` template. The
    documentation output will utilize the new replacement file.
ja: テンプレートの著者は
    `fulldoc` テンプレートの中で既存のファイルのような同じ名前を用い、
    ファイルを作成する事によって
    既存のスタイルシートとjavascriptを
    上書きできる。
    ドキュメント出力は新しく置換するファイルを利用する。

en: YARD's `fulldoc` template defines three stylesheets:
ja: YARDの `fulldoc` テンプレートはツリーのスタイルシートを定義する。

en: The `style.css` is the primary stylesheet for the HTML output.
ja: `style.css` は、HTML出力用の主要なスタイルシートとなる。

en: The `full_list.css` is an additional stylesheet loaded specifically for the
    search field menus (i.e. class list, method list, and file list).
ja: 追加のスタイルシートの `full_list.css` は、厳密にいえば検索フィールドメニューの為にロードされる。
    (すなわち、クラスリスト、メソッドリスト、ファイルリスト)

en: The `common.css` is an empty css file that an template author can easily override
    to provide custom styles for their plugin. However, if a user installs multiple
    plugins that utilize this same file to deliver styles, it is possible that they
    will be overridden.
ja: `common.css` は、
    テンプレートの著者がプラグイン用の
    カスタムスタイルを提供する為に
    簡単に上書きする空のcssファイルとなる。
    しかしながらユーザーがスタイルを実行するのに、
    同じファイルを利用する複数のプラグインをインストールした場合、
    上書きされる事が問題になる。

en: YARD's `fulldoc` template defines three javascript files:
ja: YARDの `fulldoc` テンプレートは次の様にツリー上のjavascriptファイルを定義する。

en: The `app.js` is the primary javascript file for the HTML output.
ja: `app.js` はHTML出力用の主要なjavascriptファイルとなる。

en: The `full_list.js` defines additional javascript loaded specifically for the
    search field menus (i.e. class list, method list, and file list).
ja: 追加のjavascriptを定義する `full_list.js` は、
    厳密にいえば検索フィールドメニュー用にロードされる。
    (すなわち、クラスリスト、メソッドリスト、ファイルリスト)

en: The `jquery.js` is copy of the jquery javascript library.
ja: `jquery.js` はjquery javascriptライブラリをコピーする。

en: ### Adding a Custom Stylesheet or Javascript
ja: ### カスタムスタイルシートとJavascritpを追加する

en: To load additional stylesheets and javascripts with every page (except the search
    field menus) generated from the base `layout` template:
ja: 基本の `layout` テンプレートから生成した
    全てのページと共に、
    追加のスタイルシートとjavascriptをロードするには
    (但し、検索フィールドメニューを除く):

en:   1. Define your own custom stylesheet and/or javascript file
         (default/ is the default template name inside of the /template root directory):
ja:   1. 自分のカスタムスタイルシートやjavascriptファイルを定義する。
         (デフォルトのディレクトリは/templateルートディレクトリの内部のデフォルトのテンプレート名である):

en:         /template/default/:
            |-- fulldoc
            |   |-- html
            |   |   |-- css
            |   |   |   |-- custom.css
            |   |   |-- js
            |   |   |   |-- custom.js
ja:           /template/default/:
              |-- fulldoc
              |   |-- html
              |   |   |-- css
              |   |   |   |-- custom.css
              |   |   |-- js
              |   |   |   |-- custom.js

en:   2. Create a `setup.rb` in the `layout` template directory and override the methods
         `stylesheets` and `javascripts`. The path to the template would be:
ja:   2. `layout` テンプレートディレクトリの中の `setup.rb` を作成して
         `javascripts` と `stylesheets` メソッドを上書きする。
         テンプレートのパスは次の様になる:

en:         /template/default/:
            |-- layout
            |   |-- html
            |   |   |-- setup.rb
ja:           /template/default/:
              |-- layout
              |   |-- html
              |   |   |-- setup.rb

en:       And the code would look like:
ja:       そしてコードは次のようになる。

en:         def stylesheets
              # Load the existing stylesheets while appending the custom one
              super + %w(css/custom.css)
            end
ja:           def stylesheets
                # カスタムのcssが追加される間、存在するスタイルシートをロードする
                super + %w(css/custom.css)
              end

en:         def javascripts
              # Load the existing javascripts while appending the custom one
              super + %w(js/custom.js)
            end
ja:           def javascripts
                # カスタムのjavascriptが追加される間、存在するスタイルシートをロードする
                super + %w(js/custom.js)
              end

en: To load additional stylesheets and javascripts for the search menus loaded from
    the `fulldoc` template:
ja: `fulldoc` テンプレートからロードされた検索メニュー用の
    追加のスタイルシートとjavascriptをロードするには:

en:   1. Define your own custom stylesheet and/or javascript file.
ja:   1. 自分のカスタムスタイルシートとjavascriptファイルを定義する。

en:         /path/to/mytemplates/:
            |-- fulldoc
            |   |-- html
            |   |   |-- css
            |   |   |   |-- custom_full_menu.css
            |   |   |-- js
            |   |   |   |-- custom_full_menu.js
ja:           /path/to/mytemplates/:
              |-- fulldoc
              |   |-- html
              |   |   |-- css
              |   |   |   |-- custom_full_menu.css
              |   |   |-- js
              |   |   |   |-- custom_full_menu.js

en:   3. Override the methods `stylesheets_full_list` and `javascripts_full_list`
         in the `setup.rb` file inside fulldoc/html.
ja:   3. fulldoc/html内の `setup.rb` ファイルの中の
      `stylesheets_full_list` と `javascripts_full_list` メソッドを上書きする。

en:         def stylesheets_full_list
              # Load the existing stylesheets while appending the custom one
              super + %w(css/custom.css)
            end
ja:         def stylesheets_full_list
              # カスタムのcssが追加される間、存在するスタイルシートをロードする
              super + %w(css/custom.css)
            end

en:         def javascripts_full_list
              # Load the existing javascripts while appending the custom one
              super + %w(js/custom.js)
            end
ja:         def javascripts_full_list
              # カスタムのjavascriptが追加される間、存在するスタイルシートをロードする
              # Load the existing javascripts while appending the custom one
              super + %w(js/custom.js)
            end

en: ### Overriding Search Menus
ja: ### 検索メニューを上書きする。

en: By default YARD's `fulldoc` template generates three search fields:
ja: デフォルトでYARDの `fulldoc` テンプレートは次のような検索フィールドのツリーを生成する。

en: Their contents are rendered in methods within the `fulldoc` template:
ja: その内容は、 `fulldoc` テンプレートの中でメソッドの中を表示する。

en: To override these lists you will need to:
ja: これらのリスト上書きするには:

en:   1. Create a `setup.rb` in the `fulldoc` template directory and override the
         particular method.
ja:   1. `fulldoc` テンプレートディレクトリの中の `setup.rb` を作成し、
      メソッドの詳細を上書きする。

en:            # Here we changed the functionality to reverse the order of displayed methods
               @items = @items.sort_by {|m| m.name.to_s }.reverse
               @list_title = "Method List"
               @list_type = "methods"
               asset('method_list.html', erb(:full_list))
             end
ja:          # ここでメソッドを表示する順番を逆にする為の機能を変更する
               @items = @items.sort_by {|m| m.name.to_s }.reverse
               @list_title = "Method List"
               @list_type = "methods"
               asset('method_list.html', erb(:full_list))
             end

en: ### Adding Additional Search Menus
ja: ### 追加の検索メニューを追加する。

en: These are defined in the `layout` template method `menu_lists` and pulled into
    the `fulldoc` template through a similarly named method.
ja: これらは `layout` テンプレートメソッドの中の `menu_lists` を定義される。
    そして同様に名付けられたメソッドを通じて `fulldoc` テンプレートに置かれる。

en: To load an additional menu item:
ja: 追加のメニュー項目をロードするには次のようになる:

en:   1. Create a `setup.rb` in the `layout` template directory and override the methods
       `menu_lists`. The `type` informs the search field the name of the file.
        The `title` is the name that appears above the section when viewed in frames.
        The `search_title` is the name that appears in the search field tab on the page.
ja:   1. `layout` テンプレートディレクトリの中で `setup.rb` を作成し `menu_lists` メソッドを上書きする。
       `type` はファイルの検索フィールド名通知する。
       `title` はフレームのなかで表示された時に上のセクションに登場する名前である。
       `search_title` はページの検索フィールドタブの中で登場する名前である。

en:         def menu_lists
              # Load the existing menus
              super + [ { :type => 'feature', :title => 'Features', :search_title => 'Feature List' } ]
            end
ja:         def menu_lists
              # 既存のメニューをロードする
              super + [ { :type => 'feature', :title => 'Features', :search_title => 'Feature List' } ]
            end

en:   2. Create a `setup.rb` in the `fulldoc` template directory and create a method
         to generate a menu for the specified `type`.
         The method `generate_assets` will look for a function with a signature prefixed
         with `generate`, the type value specified, and the suffix `list`. Within that
         method you can configure and load the specific objects you wish to display.
ja:   2. `fulldoc` のテンプレートディレクトリの中で `setup.rb` を作成し、
         指定された `type` 用にメニューを生成するためのメソッドを作成する
         `generate_assets` メソッドは、 `generate` で始まり,間に固有の値,末尾が `list` のシグネチャを探す。
         メソッドの中をあなたが構成でき、表示するためにあなたが望む特定のオブジェクトをロードする。

en:            # load all the features from the Registry
               @items = Registry.all(:feature)
               @list_title = "Feature List"
               @list_type = "feature"
ja:            # レジストリーから全ての機能をロードす
               @items = Registry.all(:feature)
               @list_title = "Feature List"
               @list_type = "feature"

en:            # Generate the full list html file with named feature_list.html
               # @note this file must be match the name of the type
               asset('feature_list.html', erb(:full_list))
             end
ja:            # feature_list.htmlの名前と共に完全なHTMLファイルのリストを作成する
               # @note this file must be match the name of the type
               asset('feature_list.html', erb(:full_list))
             end

en: 1. **Directives (new behavioural tag syntax)** (0.8.0)
    2. **Added `--embed-mixin(s)` to embed mixins into class docs** (0.8.0)
    3. **Internationalization (I18n) support for translating docs** (0.8.0)
    4. **New C parser / handlers architecture** (0.8.0)
    5. **YARD will now warn if `@param` name not in method params** (0.8.0)
    6. **Added support for `module_function` calls in Ruby code** (0.8.0)
    7. **Greatly improved tag documentation using custom template** (0.8.0)
    8. **Tags can now contain '.' for namespacing** (0.8.0)
    9. **Added "frames" links for non-framed pages for better nav** (0.8.0)
    10. **Added Gemfile support to YARD server for local gem sets** (0.8.0)
    11. **Server now displays README on index route like static docs** (0.8.0)
    12. **Added line numbers to `yard stats --list-undoc --compact`** (0.8.0)
    13. **Single object db now default (multi-object db unsupported)** (0.8.0)
    14. **Added `--api` tag to generate documentation for API sets** (0.8.1)
ja: 1. **ディレクティブ (タグ構文の新しい行動)** (0.8.0)
    2. **クラスのドキュメントの中にmixinを埋め込むのに `--embed-mixin(s)` が追加された** (0.8.0)
    3. **翻訳ドキュメント用の国際化 (I18n) サポート** (0.8.0)
    4. **新しい C パーサー / ハンドラー アーキテクチャ** (0.8.0)
    5. **YARDはメソッドのパラメータの中に`@param`名が無い場合、警告を出すようになった。
    6. **`module_function` がRubyのコードを呼び出すサポートが追加された** (0.8.0)
    7. **カスタムテンプレートによって大きくタグドキュメントが修正された** (0.8.0)
    8. **タグがネームスペース用の '.' を含むようになった** (0.8.0)
    9. **より良いナビをするのにフレームでないページ用に"フレーム"のリンクが追加された** (0.8.0)
    10. **ローカルのgemのグループ用にYARDサーバーにGemfileのサポートが追加された** (0.8.0)
    11. **サーバーは静的なドキュメントのようにルートのインデックス上のREADMEを表示するようになった** (0.8.0)
    12. **`yard stats --list-undoc --compact`に行数が追加された** (0.8.0)
    13. **単一のオブジェクトdbがデフォルトになった (マルチオブジェクトdbは未サポート)** (0.8.0)
    14. **API用のグループのドキュメントを生成するのに `--api` タグが追加された** (0.8.1)

en: ## Directives (new behavioural tag syntax) (0.8.0)
ja: ## ディレクティブ (タグ構文の新しい行動) (0.8.0)

en: YARD 0.8.0 adds a new tag syntax called "directives" using the `@!`
    prefix. These directive tags can be used to modify parser state while
    processing objects, or even create new objects on the fly. A plugin
    API is available similar to tags, and directives should be registered
    in the {YARD::Tags::Library} class using {YARD::Tags::Library.define_directive}.
ja: YARD 0.8.0で追加された新しいタグ構文は
    `@!` プレフィックス(接頭辞)によって"directives(ディレクティブ)"を呼び出す。
    これらのディレクティブタグは、
    オブジェクトを処理している間やオンザフライで新しくオブジェクトを作成する時でさえ、
    パーサーの状態を変更するのに利用できる。
    プラグインAPIはタグ同様に可能で、
    ディレクティブは {YARD::Tags::Library.define_directive} によって
    {YARD::Tags::Library} クラスのなかに登録される。

en: To use a directive, simply call it the same way as any tag. Tag syntax
    is documented in {file:docs/Tags.md}.
ja: ディレクティブを使うには、単純にタグなどと同じ方法で呼び出す。
    タグ構文は {file:docs/Tags.md} で記述される。

en: ### Notable features of directives
ja: ### 著名なディレクティブの機能

en: #### Directives do not need to be attached to object docstrings
ja: #### ディレクティブはオブジェクトのdocstringに追加するのに必要ない

en: Unlike meta-data tags which apply to created objects, directives
    do not need to be attached to an object in order to be used. This
    means you can have free-standing comments with directives, such as:
ja: メタデータタグとは違って作成されたオブジェクトに追加され、
    ディレクティブは利用される順番で追加される必要はない。
    これは次のようなディレクティブを用い自由な位置にコメントできる事を意味する:

en:     # Using the macro:
        # @macro mymacro
        def mymethod; end
ja:     # 上のマクロを呼び出す:
        # @macro mymacro
        def mymethod; end

en: You can do the same to define methods and attributes, as discussed
    below.
ja: 下の項で議論されるように
    あなたはメソッドと属性を定義するのを同じようにできる。

en: #### `@!method` and `@!attribute` directives improved
ja: #### 改良された `@!method` と `@!attribute` ディレクティブ

en: The method and attribute directives can now be used to create multiple
    objects in a single docstring. Previously a `@method` or `@attribute`
    tag would only create one method per docstring. In 0.8.0, you could
    attach multiple methods to the same block of Ruby source, such as:
ja: メソッドと属性(attribute)のディレクティブは
    単一のdocstringで複数のオブジェクトを作成するのに利用できるようになった。
    以前は `@method` や `@attribute` タグは
    メソッド一つで個々のdocstringだけ作成していた。
    0.8.0ではRubyのソースの同じブロックに複数のメソッドを追加できる。
    次のようになる:

en:     # @!method foo(a, b, c)
        # @!method bar(x, y, z)
        # Docstring for code
        some_ruby_source
ja:     # @!method foo(a, b, c)
        # @!method bar(x, y, z)
        # コード用のdocstring
        some_ruby_source

en: The above creates #foo and #bar and the source listing for both will
    be `some_ruby_source` with "Docstring for code" as the docstring.
ja: 上の例は
    両方がdocstringとして"コード用のdocstring"と一緒に
    `some_ruby_source` の説明になるように、
    #fooメソッドと#barメソッドとソースのリストを作成する。

en: The attribute directive can take advantage of this functionality as well.
    Note that these directives also do not need to be attached to a line of
    code to be recognized; they can be in free-standing comments if the
    methods are defined dynamically and not associated with any code.
ja: 属性のディレクティブはさらにこの機能の平均を取得できる。
    次の事に留意する。
    これらのディレクティブは認識されるのにコードの行に追加される必要もない。
    つまり、これはメソッドが動的に定義される場合
    自由な場所にコメントでき、任意のコードと一緒に関連づけられない。

en: #### New `@!parse` directive to parse Ruby code
ja: #### Rubyのコードを解析する為の新しい `@!parse` ディレクティブ

en: A new {tag:!parse} directive was added that allows a developer to have
    YARD parse code that might not necessarily be parsable in its original
    form. This is useful when using `instance_eval` and other dynamic
    meta-programming techniques to define methods or perform functionality.
    For instance, a common case of the "self.included" callback in module
    to extend a module on a class might be in the form:
ja: 新しい {tag:!parse} ディレクティブは
    YARDが元の形式で解析する必要はないコードの解析を開発者に
    許可するのに追加された。
    これはメソッドを定義する時や機能を実行する時に
     `instance_eval` と他の動的なメタプログラミングのテクニックを使う時に便利である。
    例えば、次の形式でクラス上でモジュールを拡張するのに
    モジュールの中の"self.included"コールバックの一般的なケース:

en: Unfortunately, this does not get picked up by YARD, but on the original
    class, we can add:
ja: あいにく、これはYARDによって取得できないが、
    元のクラス上で次のように追加できる:

en: YARD will then parse the code `extend TheDynamicModule` as if
    it were in the source file.
ja: それがソースファイルの中だった場合など
    YARDが `extend TheDynamicModule` のコードを解析する時

en: You can also use this technique to register regular methods as
    attributes, if you did not define them with `attr_*` methods:
ja: これらの `attr_*` メソッドを用いて定義しなかった場合、
    あなたは属性として標準のメソッドを登録するのにこのテクニックを使う事ができる。

en:     # Register them as methods:
        # @!parse attr_accessor :foo
ja:     # メソッドとしてそれらを登録する
        # @!parse attr_accessor :foo

en: ### Backward incompatible changes to `@!macro` directive
ja: ### 後方互換性のない `@!macro` ディレクティブに変更する

en: Unfortunately, in order to create the new directives architecture,
    some previously supported syntax in `@macro` tags are no longer supported.
    Specifically, macros can no longer expand text on an entire docstring.
    Instead, macros only expand the data that is indented inside of the tag
    text.
ja: あいにく、新しいディレクティブアーキテクチャを作成する為の順番、
    `@macro` タグの中でいくつか前にサポートされた構文は、もうサポートされない。
    すなわち、マクロは全てのdocstring上のテキストを展開することはできない。
    代わりに、マクロはタグのテキストの内部のインデントされたデータだけ展開する。

en: In 0.7.0 to 0.7.5, the above would have created a method with the docstring
    "Expanding text a b c". This will not work in 0.8.0. Instead, you must
    indent all the macro expansion data so that it is part of the `@macro`
    tag as follows:
ja: 0.7.0 ~ 0.7.5で、
    上はの例はdocstring "Expanding text a b c"と一緒に作成されたメソッドを持つ。
    これは、0.8.0では動かない。
    代わりに、あなたは全てのマクロ展開のデータをインデントしなければならない。
    つまり `@macro` タグの一部を次のようにする:

en: Note that we also use the recommended `@!macro` syntax, though `@macro`
    is still supported.
ja: 次の事に留意する。
    我々は推奨された `@!macro` 構文を使うけれども、
    `@macro` はまだサポートされている。

en: ## Added `--embed-mixin(s)` to embed mixins into class docs (0.8.0)
ja: ## クラスのドキュメントにmixinを埋め込むのに `--embed-mixin(s)` が追加された (0.8.0)

en: Methods from mixins can now be embedded directly into the documentation
    output for a class by using `--embed-mixin ModuleName`, or `--embed-mixins`
    for all mixins. This enables a documentation writer to refactor methods
    into modules without worrying about them showing up in separate files
    in generated documentation. When mixin methods are embedded, they
    show up in both the original module page and the pages of the classes
    they are mixed into. A note is added to the method signature telling the
    user where the method comes from.
ja: mixinからのメソッドは
    全てのmixin用に `--embed-mixin ModuleName` や `--embed-mixins` 用の
    ドキュメント出力の中へ直接埋め込まれるようになった。
    これは生成されたドキュメントの中の分割されたファイルのなかの
    その時の一覧について警告無しでモジュールの中の
    メソッドをリファクタリングする為にドキュメントを書ける。
    mixinメソッドが埋め込まれた時、
    これは元のモジュールのページとこれらの混じったクラスのページの両方を一覧する。
    noteはメソッドのシグネチャがメソッドがどこからくるかユーザーに知らせるのに追加された。

en: The `--embed-mixin` command-line option can also take wildcard values
    in order to match specific namespaces. For instance, you can embed
    only mixins inside of a "Foo::Bar" namespace by doing:
ja: `--embed-mixin` コマンドラインオプションは、
    指定のネームスペースにマッチするのにワイルドカードの値も取得できる。
    例えば、次の様にする事によって
    "Foo::Bar"ネームスペースの内部にmixinだけ埋め込むことができる。

en: ## Internationalization (I18n) support for translating docs
ja: ## 翻訳ドキュメント用の国際化(I18n)サポート

en: YARD now ships with the beginnings of internationalization support
    for translating documentation into multiple languages. The
    `yard i18n` command now allows you to generate ".pot" and ultimately
    ".po" files for translation with [gettext](http://www.gnu.org/software/gettext).
ja: YARDは複数の言語に翻訳したドキュメント用に国際化サポートを送りだすことになった。
    `yard i18n` コマンドは
    あなたが[gettext](http://www.gnu.org/software/gettext)を用いた翻訳用の
    ".pot"と最後に".po"ファイルを生成するのを許可するようになった。

en: Note that this tool is a small step in the larger transition for
    proper I18n support in YARD. We still have to add proper gettext
    support to our templates for proper generation in multiple languages,
    but this tool allows you to get started in translating your
    documents. Improved I18n support will come throughout the 0.8.x series.
ja: 次の事に留意する。
    このツールはYARDの正当なI18nサポートの小さな一歩である。
    我々はまだ複数の言語の適切な生成の為に、
    例のテンプレートに適切なgettextサポートを追加する仕事が残っている。
    だがこのツールはあなたが翻訳ドキュメントを始めるのを受け入れる。
    改良されたI18nサポートは0.8.xシリーズに至る中で登場するだろう。

en: ## New C parser / handlers architecture (0.8.0)
ja: ## 新しい Cパーサー / ハンドラー構造 (0.8.0)

en: The C parser was completely rewritten to take advantage of YARD's
    parser and handler architecture. This means more YARD will be more robust
    when parsing failures occur, tags and directives will now work consistently
    across Ruby and CRuby files ({tag:!group} will now work, for instance),
    and developers can now write custom handlers that target CRuby source files.
ja: YARDパーサーの平均とハンドラーアーキテクチャを取得するのに
    C パーサーは完全に書き直された。
    これはYARDが解析異常が起きた時にさらに堅牢になる事を意味し
    タグとディレクティブはRubyとCRubyのファイル(例えば {tag:!group} が動くようになった)
    全域で堅実に動く様になった。
    そして、開発者はCRubyのソースファイルを目的にするカスタムハンドラーを書ける様になった。

en: ## YARD will now warn if `@param` name not in method params (0.8.0)
ja: ## YARDはメソッドパラメーターの中に`@param`名がない場合、警告を出すようになった(0.8.0)

en: YARD will now give you a warning if you use a `@param` tag in your
    source but give an invalid parameter name. This should catch a lot of
    common documentation errors and help keep your documentation consistent.
ja: YARDはあなたのソースの中の `@param` タグを使う場合、あなたが警告を出せるようになった。
    しかし有効なパラメータ名を与える。
    これは沢山の一般的なドキュメントエラーをキャッチし、
    あなたの一貫したドキュメントの保守を助ける。

en: ## Added support for `module_function` calls in Ruby code (0.8.0)
ja: ## `module_function` がRubyのコードの中で呼び出されるサポートが追加された (0.8.0)

en: The `module_function` command in Ruby is now supported in Ruby files.
    It defines two separate methods, one class and one instance method,
    both having the exact same docstring, and marks the instance method
    as private.
ja: Rubyの `module_function` コマンドは
    Rubyのファイルでサポートされるようになった。
    それは"区切られたメソッド"と
    "一つのクラスと一つのインスタンスメソッド"二つを定義し、
    正確な同じdocstring両方、
    privateとしてインスタンスメソッドをマークする。

en: ## Greatly improved tag documentation using custom template (0.8.0)
ja: ## カスタムテンプレートによって大きく改良されたタグのドキュメント (0.8.0)

en: We have completely revamped the {docs/Tags.md} to include documentation
    for each meta-data tag and directive with at least one useful example
    for each one. This was done using template customization and extension
    available within YARD.
ja: 我々は個々のメタデータタグとディレクティブ用の
    ドキュメントを含めるのに {docs/Tags.md} を
    少なくとも各々一つ便利な例を用い完全に刷新しました。
    これはYARDの中でテンプレートのカスタマイズと拡張が可能になる事によって
    行なわれた。

en: ## Tags can now contain '.' for namespacing (0.8.0)
ja: ## タグはネームスペース用の '.' を含める事できるようになった (0.8.0)

en: Prior to 0.8.0, tags could only contain alphanumeric characters and
    underscore. YARD now allows the '.' character in tag names, and it
    is now recommended for namespacing project-specific custom tags.
    YARD has its own set of custom tags that are namespaced in this
    way (using the "yard.tagname" namespace). The namespace recommendation
    is to use "projectname.tagname", or "projectname.component.tagname".
ja: 0.8.0以前のタグはアルファベット文字列とアンダースコアだけ含める事ができた。
    YARDはタグ名で '.' の文字を受け入れるようになり、
    プロジェクトの指定のカスタムタグのネームスペース用に推奨する。
    YARDは自身のカスタム
    この方法でネームスペース(名前付け)されるタグのグループを持つ。
    おすすめのネームスペースは
    "projectname.tagname" や "projectname.component.tagname"を使う

en: ## Added "frames" links for non-framed pages for better nav (0.8.0)
ja: ## ナビの改良の為フレームのないページ用にフレームのリンクが追加された (0.8.0)

en: Frames navigation has always had a "(no frames)" link to get rid
    of the frameset. YARD 0.8.0 introduces a "(frames)" link on non-framed
    pages to reverse this, allowing you to navigate between framed and
    frameless pages seamlessly.
ja: フレームのナビゲーションは
    フレームセットを取り除くのを取得するのに常に"(no frames)"のリンクを持っていた。
    YARD 0.8.0はこれを置き換えるのにフレームの無いページで
    "(frames)"のリンクを導入する
    フレームとフレーム無しのページ間を
    シームレスにナビゲートするのに許可される。

en: ## Added Gemfile support to YARD server for local gem sets (0.8.0)
ja: ## ローカルgemのグループ用にYARDサーバーにGemfileのサポートが追加された (0.8.0)

en: The `yard server` command now supports `--gemfile` to serve gems
    from a Gemfile.lock, instead of all system-wide gems.
ja: 全てのシステム側のgemの代わりにGemfile.lockからgemを提供するのに、
    `yard server` コマンドは、`--gemfile` をサポートするようになった。

en: ## Server now displays README on index route like static docs (0.8.0)
ja: ## サーバーは静的なドキュメントのようなルートのインデックス上でREADMEを表示する(0.8.0)

en: The `yard server` command will now behave like static docs regarding
    the index action for a project, listing the README file if present
    before displaying the alphabetic index. Note that the route for
    the alphabetic index page has now moved to the explicit '/index' action.
ja: `yard server` コマンドは
    プロジェクト用のインデックスの動作について
    静的なドキュメントのような挙動になり、
    アルファベットのインデックスを表示する前に与える場合、
    READMEファイルを記述する。
    次の事に留意する。
    アルファベット順のインデックスページ用のルートは
    明示的な '/index' の動作に移るようになった。

en: ## Added line numbers to `yard stats --list-undoc --compact` (0.8.0)
ja: ## `yard stats --list-undoc --compact` に行数が追加された (0.8.0)

en: Line numbers are now listed in the compact listing of undocumented objects
    so that they can be more easily located in the files.
ja: 行数はコンパクトなアンドキュメントなオブジェクトのリストで記述されるようになった。
    なのでこれらはさらに簡単にファイルの中を示す事ができる。

en: 1. **Macro support and detection of DSL methods** (0.7.0)
    2. **Inherited attributes now show in HTML output** (0.7.0)
    3. **The 'app' directory is now parsed by default** (0.7.0)
    4. **Added support for metadata (@title, @markup) in extra files/readmes** (0.7.0)
    5. **Added `yard list` command (alias for `yardoc --list`)** (0.7.0)
    6. **Added Git support in `yard diff`** (0.7.0)
    7. **Added `{include:file:FILENAME}` syntax** (0.7.0)
    8. **Added `{render:OBJECT}` syntax to embed object docs in extra files** (0.7.0)
    9. **Added improved templates API for custom CSS/JS/menus** (0.7.0)
    10. **Added Ruby markup type (`-m ruby`)** (0.7.0)
    11. **Added state tracking variables to Parser/Handler architecture** (0.7.0)
    12. **Added before/after callbacks to SourceParser** (0.7.0)
    13. **Can now use `--yardopts FILE` to specify a custom yardopts file** (0.7.0)
    14. **Added new `-t guide` template for guide based docs** (0.7.0)
    15. **Github Flavoured Markdown now works out-of-box** (0.7.4)
    16. **Added `-m textile_strict` and `-m pre` markup types** (0.7.4)
    17. **Reorganized markup types 'text' and 'none'** (0.7.4)
    18. **Add support for `rb_define_alias`** (0.7.4)
ja: 1. **マクロのサポートとDSLメソッドの検知** (0.7.0)
    2. **継承された属性はすぐHTML出力で一覧できる** (0.7.0)
    3. **'app'ディレクトリは、すぐデフォルトで解析される** (0.7.0)
    4. **追加のファイル/readmesでメタデータ用(@title,@markup)のサポートが追加された** (0.7.0)
    5. **`yard list`コマンドが追加された(`yardoc --list`用のエイリアス)** (0.7.0)
    6. **`yard diff`でGitサポートが追加された** (0.7.0)
    7. **`{include:file:FILENAME}`構文** (0.7.0)
    8. **追加のファイルでオブジェクトのdocsを組み込む為の`{render:OBJECT}`構文が追加された** (0.7.0)
    9. **カスタムCSS/JS/メニュー用の改良されたテンプレートAPIが追加された** (0.7.0)
    10. **Rubyのマークアップの型(`-m ruby`)が追加された** (0.7.0)
    11. **パーサー/ハンドラーのアーキテクチャにトラッキングの状態変数が追加された** (0.7.0)
    12. **SourceParserにbefore/afterのコールバックが追加された** (0.7.0)
    13. **カスタムyardoptsファイルを指定するのに、`--yardopts FILE`ですぐに、使う事が出来る** (0.7.0)
    14. **基底となるdocstringをガイドするのに、`-t guide`テンプレートを新しく追加する** (0.7.0)<
    15. **Github風のMarkdownが常識破りの仕事をするようになった** (0.7.4)
    16. **`-m textile_strict`と`-m pre`マークアップの型が追加された** (0.7.4)
    17. **'text'と'none'のマークアップ型が再編成された** (0.7.4)
    18. **`rb_define_alias`用のサポートが追加された** (0.7.4)

en: ## Macro support and detection of DSL methods (0.7.0)
ja: ## マクロのサポートとDSLメソッドの検知 (0.7.0)

en: YARD will now automatically detect class level method calls, similar to the
    way it knows what an `attr_accessor` is. By simply adding documentation to
    your class level declarations, YARD can automatically detect them as methods
    or attributes in your class. Consider DataMapper's "property" declaration:
ja: YARDは自動でクラスレベルメソッドの呼び出しを検知するようになった。
    'attr_accessor'何なのか知るのと似ている。
    簡単にあなたのクラスレベル宣言にドキュメントを追加する。
    DataMapperの"property"宣言を考慮する。

en: The above declaration would be created as the `Post#title`. The optional
    `@attribute` tag tells YARD that the property is an "attribute", and not just
    a regular method.
ja: 上の宣言は、`Post#title`メソッドとして作成されるだろう。
    任意の`@attribute`タグがYARDの"property"に伝えるのは、"attribute"であり、
    それは正規のメソッドではない。

en: In addition to basic DSL method detection, YARD also supports macros to create
    docstrings that can be copies to other objects; these macros can also be
    "attached" to class level methods to create implicit documentation for macros.
ja: 更に基本のDSLメソッド検知に加えて、
    YARDは他のオブジェクトにコピーできるdocstringを作成するマクロもサポートする。
    これらのマクロはマクロ用に暗黙のドキュメントを作成するために
    クラスレベルメソッドに"追加"(attached)もできる。

en: Macros and DSL method detection are discussed in much more detail in the
    {file:docs/GettingStarted.md}, so you should read about them there if you're
    interested in this feature.
ja: マクロとDSLメソッド宣言の詳細は{file:docs/GettingStarted.md}で説明されるので、
    あなたがこの機能に興味がある場合、そこで読む事ができる。

en: ## Inherited attributes now show in HTML output (0.7.0)
ja: ## 継承された属性をHTML出力ですぐに調べられるようになった (0.7.0)

en: Inherited attributes will now show up in HTML documentation using the default
    template in the same manner that inherited methods do.
ja: 継承された属性は、
    継承されたメソッドと同じ形式で
    デフォルトのテンプレートによって
    HTMLドキュメントですぐに現れるだろう。

en: ## The 'app' directory is now parsed by default (0.7.0)
ja: ## デフォルトで'app'ディレクトリはすぐに解析される (0.7.0)

en: YARD tries to follow the "It Just Works" attitude in writing developer tools,
    and therefore has added `app/**/*.rb` to the default list of globs that it
    searches for code in. You no longer need to create a `.yardopts` just to
    list your app directory when documenting your code on rubydoc.info.
    We should have done this a while ago! And don't worry, YARD still checks
    lib and ext by default, too.
ja: YARDは開発者のツールで書かれている\"ちゃんと動く\"姿勢をフォローしようとする、
    従って、それがコード用に検索するglobのデフォルトのリストに
    追加された`app/**/*.rb`を持つ
    あなたはもはやrubydoc.infoであなたのコードを記述する時に
    あなたのアプリのディレクトリ記述するのに`.yardopts`を作成する必要はない。
    ちょっと前にこれが完成したが、心配しないで、
    YARDはまだデフォルトでlibとextもチェックする。

en: ## Added support for metadata (@title, @markup) in extra files/readmes (0.7.0)
ja: ## 追加のファイルとREADMEの中でメタデータ(@title,@markup)用のサポートが追加された(0.7.0)

en: Extra files (READMEs, ChangeLogs, LICENSE files, and other guides) now support
    metadata tags, just like docstrings in code comments. By adding @tag values
    to the top of a file (no whitespace preceding it) inside of a `# comment` line,
    YARD will detect and parse these tags and store it for later usage.
ja: 追加のファイル(README,ChangeLogs,LICENSEファイルや他のガイド)は、
    すぐに、メタデータタグをサポートする(コードのコメント中のdocstringのように)。
    `# comment`行の中のファイルの最初に@tagの値を追加する事で、
    YARDは、このタグを検知,解析し、最新の方法でそれを記録するだろう。

en: Tags can contain arbitrary data as well as arbitrary tag names, however the
    tag names @title and @markup are reserved to specify the document title and
    markup format respectively. The title will be used in the file list menu,
    index page, as well as any linking of the file via the `{file:Filename}`
    syntax. An example of a document with metadata would be:
ja: タグは任意のデータも任意のタグ名も含める事ができる、
    しかしながら、タグ名の@titleと@markupは、
    ドキュメントのタイトルとマークアップフォーマットを個別に指定する為に用意される。
    タイトルはファイルリストメニューや
    index pageも`{file:Filename}`構文経由の任意のファイルへのリンクでも利用される。
    次はメタデータを用いたドキュメントの例:

en: Note that previous versions of YARD recommended specifying the markup of an
    extra file with the `#!markup` shebang, but the `@markup` metadata tag is now
    the "best practice" for specifying the markup format of an extra file.
ja: 次の事に留意する。
    YARDの前のバージョンは、
    `#!markup`のshebangを用いた追加のファイルのマークアップの指定が
    推奨された。
    しかし、今は`@markup`メタデータタグが、
    追加のファイルのマークアップフォーマットを指定するのに最善の方法である。

en: ## Added `yard list` command (alias for `yardoc --list`) (0.7.0)
ja: ## `yard list`コマンドを追加する。(`yardoc --list`用のエイリアス) (0.7.0)

en: The `yardoc --list` command is used to list objects that are parsed from
    a codebase. This can be used to grep methods/classes in a codebase from the
    command line. `yard list` now calls `yardoc --list` as a convenience command.
ja: `yardoc --list`コマンドはソースコードから解析されるリストオブジェクトの為に利用される。
    これは、ソースコードの中でメソッド/クラスをgrepする為に利用できる。
    `yard list`は、便利なメソッドとして`yardoc --list`を呼び出すようになった。

en: Note that the `yardoc --list` command may eventually be replaced by a more
    feature-filled `yard list` command, so `yard list` should be used instead of
    `yardoc --list` when possible.
ja: 次の事に留意する。`yardoc --list`コマンドは、
    将来、より多くの機能で満たされた`yard list`コマンドに切り替わるだろう。
    なので可能であれば`yardoc --list`の代わりに、`yard list`を利用する方がよい。

en: ## Added Git support in `yard diff` (0.7.0)
ja: ## `yard diff`でGitのサポートが追加された (0.7.0)

en: The `yard diff` command can now perform object diffing on git repositories.
    Provide the `--git` switch to `yard diff` with 2 commit/branches like so:
ja: `yard diff`コマンドは、すぐに、gitリポジトリ上でオブジェクトのdiffを実行する。
    `yard diff`に切り替える`--git`を提供する。
    次のように、2つのcommitとbrancheを切り替える。

en: ## Added `{include:file:FILENAME}` syntax (0.7.0)
ja: ## `{include:file:FILENAME}`構文 (0.7.0)

en: You can now use the `{include:file:FILENAME}` syntax to embed the contents
    of an extra file marked up in its markup format. This syntax supports embedding
    Ruby source files and performing syntax highlighting on the code.
ja: あなたはすぐに、
    マークアップされた追加のファイルの内容を埋め込む為の
    `{include:file:FILENAME}`構文を利用できる。
    この構文は、Rubyのソースファイルの埋め込みと構文のコードハイライトの実行をサポートする。

en: ## Added `{render:OBJECT}` syntax to embed object docs in extra files (0.7.0)
ja: ## 追加のファイルでdocsオブジェクトを埋め込む為に`{render:OBJECT}`構文を追加した (0.7.0)

en: You can now use the `{render:Object}` syntax to embed the documentation
    rendering of an entire object (method, class, module) inside of an extra file.
    This is useful when writing non-API based guides that might require listing
    a few helper methods or classes. The {file:docs/GettingStarted.md} discussed
    this syntax in more detail (with example usage).
ja: あなたは、追加のファイルの中の全てのオブジェクト(メソッド,クラス,モジュール)のドキュメント表示を
    埋め込む為に`{render:Object}`構文を利用できる。
    これはいくつかのヘルパーメソッドや
    クラスを記述する必要があるAPIベースではないガイドを書く時に便利である。
    この構文の更なる詳細(例や使用法)は、
    {file:docs/GettingStarted.md}で説明される。

en: ## Added improved templates API for custom CSS/JS/menus (0.7.0)
ja: ## CSS/JS/メニュー用に改良されたテンプレートAPIが追加された (0.7.0)

en: Plugin & template developers can now more easily insert custom stylesheet
    or JavaScript files in their customized templates, thanks to an abstraction
    of the template API. This is documented in the {docs/Templates.md} document.
    In addition to custom CSS/JS, developers can also create custom menu tabs
    in both the framed and non framed version of the default theme.
ja: プラグインとテンプレートの開発者は、
    template APIの抽象化のおかげで、
    カスタマイズされたテンプレートで
    スタイルシートやJavaScriptのファイルを挿入できるようになった。
    これは、{docs/Templates.md}ドキュメントの中で記述される。
    さらに、カスタムCSS/JSで、開発者は、
    フレーム有とデフォルトテーマのフレーム無しの両方のカスタムメニュータブを
    作成する事もできる。

en: ## Added Ruby markup type (`-m ruby`) (0.7.0)
ja: ## Rubyマークアップ型(`-m ruby`)が追加された (0.7.0)

en: The Ruby markup type (`-m ruby`) will now use syntax highlighting for all
    formatting. This is probably not useful as a global switch, but can be used
    on individual extra files using the metadata markup specification discussed
    above.
ja: Rubyマークアップ型の(`-m ruby`)は、すぐに、
    全てのフォーマット用に構文のハイライトを利用する。
    これは全体の切り替えとしては、恐らく便利ではないが、
    上で説明されたメタデータマークアップの指定によって
    個々の追加のファイル上で利用できる。

en: ## Added state tracking variables to Parser/Handler architecture (0.7.0)
ja: ## Parser/Handlerアーキテクチャにトラッキング変数の状態が追加された (0.7.0)

en: The parser and handler architecture now contain state variables
    {YARD::Handlers::Base#extra_state} and {YARD::Handlers::Processor#globals}
    to share data across handlers and the entire processing phase. `#extra_state`
    provided a place to store per-file data, while `#globals` gives the developer
    access to inter-file state when parsing multiple files at once.
ja: パーサーとハンドラーのアーキテクチャは、
    ハンドラーと全ての処理段階に渡って共有する為に
    {YARD::Handlers::Base#extra_state} と {YARD::Handlers::Processor#globals}の
    変数の状態を含むようになった。
    `#extra_state`メソッドは、ファイル毎にデータを記録する為の場所を提供し、
    `#globals`メソッドは、一気に複数のファイルを解析する時に内部のファイルの状態に
    開発者がアクセスする事を許可する。

en: ## Added before/after callbacks to SourceParser (0.7.0)
ja: ## SourceParserにbeforeとafterのコールバックが追加された (0.7.0)

en: The {YARD::Parser::SourceParser} class can now register callbacks to execute
    code before and after parsing of file globs, as well as before and after
    parsing of individual files. This allows plugin developers to perform
    setup/teardown (and set global state or update the {YARD::Registry}).
ja: {YARD::Parser::SourceParser}クラスは、
    ファイルグロブの解析の前後のコードも個々のファイルの解析の前後も
    実行する為にすぐにコールバックを記録できる。
    これは、セットアップ/開発(全体の状態や{YARD::Registry}の更新)を実行する為、
    開発者のプラグインを受入れる。

en: See the documentation for the following methods:
ja: 次のメソッド用のドキュメントを参照:

en: ## Can now use `--yardopts FILE` to specify a custom yardopts file (0.7.0)
ja: ## カスタムyardoptsファイルを指定するのに、`--yardopts FILE`を利用できるようになった (0.7.0)

en: The `yardoc` command now supports `--yardopts FILE` to specify custom .yardopts
    options files. This is useful if you have multiple documentation sets, such
    as a guide documentation set and an API documentation set.
ja: `yardoc`コマンドは、すぐに
    カスタム.yardopts設定ファイルを指定するのに、
    `--yardopts FILE`をサポートする。
    これは、ガイドキュメントやAPIドキュメントのような
    複数のドキュメントのグループを持っている場合、便利である。

en: ## Added new `-t guide` template for guide based docs (0.7.0)
ja: ## docstringベースのガイド用に`-t guide`テンプレートが新しく追加された (0.7.0)

en: You can now write guide style documentation using a new 'guide' template that
    only generates documentation for extra files. You would use it in the form:
ja: あなたは、追加のファイル用のドキュメントだけ生成する
    新しく追加された'guide'テンプレートによって
    すぐにガイドスタイルドキュメントを書く事ができる。
    あなたは、次のような形式で利用できる。

en: This creates the sections for the readme, a getting started, frequently asked
    questions, trouble shooting and license page.
ja: これは、README,GettingStarted,FAQ,トラブルシューティング,ライセンスページ用のセクションを生成する。

en: If you need to refer to class / method documentation, you can embed API documentation
    using the `{render:Object}` tag discussed above.
ja: クラスとメソッドドキュメントに参照する必要がある場合、
    APIドキュメントを上で説明された`{render:Object}`タグによって埋め込む事が出来る。

en: ## Add support for `rb_define_alias` (0.7.4)
ja: ## `rb_define_alias`用のサポートが追加された (0.7.4)

en: 1. **Local documentation server for RubyGems or projects (`yard server`)** (0.6.0)
    2. **Groups support for method listing** (0.6.0)
    3. **Single file template (`--one-file`) support** (0.6.0)
    4. **`yard` CLI executable with pluggable commands** (0.6.0)
    5. **`yard diff` command to object-diff two versions of a project** (0.6.0)
    6. **Added `--asset` option to `yardoc`** (0.6.0)
    7. **New template API** (0.6.0)
    8. **HTML template now adds inline Table of Contents for extra files pages** (0.6.0)
    9. **Removed `--incremental` in favour of `--use-cache`** (0.6.0)
    10. **Ad-hoc tag registration via `yardoc` CLI (`--tag`, etc.)** (0.6.0)
    11. **Added `--transitive-tags` to register transitive tags** (0.6.0)
    12. **`yardoc` now displays RDoc-like statistics (`--no-stats` to hide)** (0.6.0)
    13. **`yri` now works on constants** (0.6.0)
    14. **Plugins are no longer auto-loaded (added `--plugin` switch)** (0.6.2)
    15. **Added `YARD::Config` API and `~/.yard/config` configuration file** (0.6.2)
    16. **Added `yard config` command to view/edit configuration** (0.6.2)
    17. **Added `yard server -t` template path switch** (0.6.2)
    18. **Added `YARD::Server.register_static_path` for static server assets** (0.6.2)
    19. **YARD::Registry is now thread local** (0.6.5)
    20. **Support for ripper gem in Ruby 1.8.7** (0.6.5)
ja: 1. **RubyGemsやプロジェクト用のローカルドキュメントサーバー(`yard server`)** (0.6.0)
    2. **メソッド記述用のサポートをグループ化する** (0.6.0)
    3. **単一のファイルのテンプレートのサポート(`--one-file`)** (0.6.0)
    4. **`yard` のコマンドは、プラグインコマンドを用い実行可能となる** (0.6.0)
    5. **プロジェクトの二つのバージョンのオブジェクトのdiffを見る為の`yard diff`コマンド** (0.6.0)
    6. **`yardoc`に`--asset`オプションが追加された** (0.6.0)
    7. **新しいテンプレートAPI** (0.6.0)
    8. **HTMLテンプレートは追加のファイルのページの内容のインラインテーブルを追加する** (0.6.0)
    9. **`--use-cache`のおかげで`--incremental`は削除された** (0.6.0)
    10. **`yardoc`CLI経由で臨時のタグの記録(`--tag`, etc.)** (0.6.0)
    11. **過渡的なタグを記録する為に、`--transitive-tags`が追加された** (0.6.0)
    12. **`yardoc`がRDocのように統計値を表示するようになった(隠すには、`--no-stats`)**
    13. **`yri`定数で働くようになった** (0.6.0)
    14. **プラグインは、自動ロードされなくなった(`--plugin`引数が追加された)** (0.6.2)
    15. **`YARD::Config`APIと`~/.yard/config`設定ファイルが追加された** (0.6.2)
    16. **設定の調査/編集の為の`yard config`コマンドが追加された** (0.6.2)
    17. **`yard server -t`テンプレートのパスの引数が追加された** (0.6.2)
    18. **静的なサーバー資源用に`YARD::Server.register_static_path`が追加された** (0.6.2)
    19. **YARD::Registryがスレッドローカルになった** (0.6.5)
    20. **Ruby 1.8.7でgemのripper用のサポート** (0.6.5)

en: ## Local documentation server for RubyGems or projects (`yard server`) (0.6.0)
ja: ## RubyGems又はプロジェクト用のローカルドキュメントサーバー(`yard server`) (0.6.0)

en: The new `yard server` command spawns a documentation server that can serve
    either documentation for a local project or installed RubyGems. The server
    will host (by default) on http://localhost:8808.
ja: 新しい`yard server`コマンドは
    ローカルプロジェクトや既存のRubyGems用の全てのドキュメントを提供できる
    ドキュメントサーバーを生みだす。
    サーバーはhttp://localhost:8808のホスト(デフォルトで)になる。

en: To serve documentation for the active project (in the current directory):
ja: アーカイブのプロジェクト用にドキュメントを提供するには、(現在のディレクトリの中の)

en: The server can also run in "incremental" mode for local projects. In this
    situation, any modified sources will immediately be updated at each request,
    ensuring that the server always serve the code exactly as it is on disk.
    Documenting your code in this fashion essentially gives you an efficient a
    live preview without running a separate command everytime you make a change.
    To serve documentation for the active project in incremental mode:
ja: サーバーはローカルプロジェクト用の "incremental" モードでも起動できる。
    この場合、任意の変更されるソースは個々のリクエストですぐに更新され、
    サーバーが常にディスク上で確実にコードを提供することを保証する。
    基本的にこのやり方であなたののコードのドキュメントは
    毎回あなたが変更するたびに
    区切られたコマンド無しで効率的に動いたままプレビューできる。
    インクリメンタルモードで
    アクティブなプロジェクトのためにドキュメントを提供するには:

en: The documentation server can also serve documentation for all installed gems
    on your system, similar to `gem server`, but using YARD's functionality and
    templates. To serve documentation for installed gems:
ja: ドキュメントサーバーはあなたのシステムで
    `gem server`と同様にYARDの機能とテンプレートを使う事によって
    既存の全てのgem用のドキュメントも提供できる
    既存のgem用にドキュメントを提供するには:

en: ## Groups support for method listing (0.6.0)
ja: ## メソッドの記述用のサポートをグループ化する (0.6.0)

en: You can now organize methods in a class/module into logical separated groups.
    These groups apply lexically and are listed in the order they are defined.
    For instance, to define a group:
ja: あなたは論理的に分けられたグループへ
    class/moduleの中のメソッドをまとめられるようになった。
    これらのグループは単語的に適用され、
    これらの命令が定義される中で記述される。
    例えばグループを定義するには:

en: In the above example, "Rendering an Object" will be listed with "foo" and
    "bar" above "Another Group", even though "aaa" comes before the two other
    methods, alphabetically. To end a group, use `@endgroup`. It is not necessary
    to end a group to start a new one, only if there is an object following the
    group that should not belong in any group.
ja: 上の例で "表示されるオブジェクトは"
    "Another Group" の上の "foo" と "bar"の
    二つの他のメソッドが前にあるけれども
    実際にはアルファベット順で"aaa"が来て記述される。
    グループを終りには`@endgroup`を使う。
    これは新しくグループを作るのにグループを終了する必要はない。
    任意のグループの中に所属すべきではないグループに続くオブジェクトがある場合だけである。

en: ## Single file template (`--one-file`) support (0.6.0)
ja: ## 単一のファイルのテンプレート (`--one-file`)のサポート (0.6.0)

en: `yardoc` now has the `--one-file` option to generate a single-file template
    for small scripts and libraries. In this case, any comments at the top of
    the script file will be recognized as a README.
ja: `yardoc`は、小さいスクリプトやライブラリ用の
    単一のファイルのテンプレートを生成する`--one-file`オプションが追加された。
    この場合、任意の内容の
    スクリプトファイルのトップでの任意のコメントは、READMEとして認識される。

en: ## `yard` CLI executable with pluggable commands (0.6.0)
ja: ## `yard` CLI がプラグイン可能なコマンドとして実行可能になる (0.6.0)

en: YARD now has a `yard` executable which combines all pre-existing and new
    commands into a single pluggable command that is both easier to remember and
    access. To get a list of commands, type `yard --help`.
ja: YARDは既存のものと新たなコマンドを一体化し、
    思い出しとアクセスすることを簡単に両立する単一の付け外し自由な
    `yard`コマンドを持つようになった。
    コマンドのリストを取得するには`yard --help`とタイプする。

en: If you are a plugin developer, you can create your own `yard` command by first
    subclassing the {YARD::CLI::Command} class and then registering this class
    with the {YARD::CLI::CommandParser.commands} list. For instance:
ja: あなたがプラグイン開発者なら、
    先に {YARD::CLI::Command} クラスをサブクラス化する事によって`yard`コマンドを
    あなた自身の手によって作成できる。
    その時 {YARD::CLI::CommandParser.commands} のリストを用いこのクラスを登録する。
    例えば:

en: The above line will enable the user to execute `yard my_command [options]`.
ja: 上の行で、ユーザーが`yard my_command [options]`を実行する事が可能となる。

en: ## `yard diff` command to object-diff two versions of a project (0.6.0)
ja: ## プロジェクトの二つのバージョンをオブジェクトのdiffするコマンド、`yard diff` (0.6.0)

en: One of the built-in commands that comes with the new `yard` executable is the
    ability to do object-oriented diffing across multiple versions of the same
    project, either by 2 versions of a gem, or 2 working copies. Just like
    regular diffing tells you which lines have been added/removed in a file,
    object diffing allows you to see what classes/methods/modules have been
    added/removed between versions of a codebase.
ja: 新しく実行可能な`yard`は、
    gemの二つのバージョンや、2つの作業中のコピーのような、
    同じプロジェクトの複数のバージョンに渡ってオブジェクト思考のdiffをする機能で、
    組み込みコマンドの一つである。
    普通のdiffのように、
    ファイルで追加/削除された行が表示される。
    diffのオブジェクトは、
    コードのバージョン間で追加/削除されたクラス/メソッド/モジュールの参照を受け入れる。

en: ## `yard stats` to display statistics and undocumented objects (0.6.0)
ja: ## 統計値を表示する`yard stats`とそれを表示しないオブジェクトが追加された (0.6.0)

en: YARD now outputs the following statistics when `yard stats` is run:
ja: YARDは、`yard stats`が起動する時に続く統計値を出力する。(次のように)

en: Note that these statistics are based on what you have set to show in your
    documentation. If you use `@private` tags and/or do not display
    private/protected methods in your documentation, these will not show up as
    undocumented. Therefore this metric is contextual.
ja: 次の事に留意する。
    これらの統計はあなたのドキュメントの中を調べられた設定が基準となる。
    `@private`タグを使う場合やあなたのドキュメントのなかでprivate/protectedメソッドを
    表示しない場合は、undocumentとしてこれらは表示しない。
    従ってこの計測はコンテキスト次第である。

en: You can also specifically list all undocumented objects (and their file
    locations) with the `--list-undoc` option.
ja: あなたは`--list-undoc`オプションを用い
    全ての未記載のオブジェクト(とそのファイルの場所)を明示的に記述できる。

en: ## Added `--asset` option to `yardoc` (0.6.0)
ja: ## `yardoc`に`--asset`オプションが追加された(0.6.0)

en: The `yardoc` command can now take the `--asset` option to copy over
    files/directories (recursively) to the output path after generating
    documentation. The format of the argument is "from:to" where from is the
    source path and to is the destination. For instance, YARD uses the following
    syntax in the `.yardopts` file to copy over image assets from the
    'docs/images' directory into the 'images' directory after generating HTML:
ja: `yardoc`コマンドは、
    ドキュメント生成の後で出力するパスに
    files/directories(再帰的に)全域をコピーするための
    `--asset`オプションが追加された。
    引数のフォーマットは
    fromがソースパスでtoが目的になる場所、
    形式は"from:to"となる。
    例えば、HTML生成の後で、
    'images'ディレクトリの中へ
    'docs/images'ディレクトリからイメージの資産全部をコピーするために
    `.yardopts`ファイルの中に次の構文を使う:

en: ## New template API (0.6.0)
ja: ## 新しくなったテンプレートAPI (0.6.0)

en: The new template API allows for easier insertion of sections within an
    inherited template. You should no longer need to insert by index, an
    error-prone process that could break when a template is updated. Instead of:
ja: 新たなテンプレートAPIは
    継承されたテンプレートの中のセクションの簡単な挿入用に許可する。
    あなたはもはやindexで挿入する必要はない、
    エラー傾向は
    テンプレートが更新される時に中断され処理する。
    代わりに:

en: You can see more in the {file:docs/Templates.md#Inserting_and_Traversing_Sections}
    document.
ja: あなたは{file:docs/Templates.md#Inserting_and_Traversing_Sections}ドキュメントで、
    更に詳細を見る事が出来る。

en: ## HTML template now adds inline Table of Contents for extra files pages (0.6.0)
ja: ## HTML テンプレートは追加のファイルのページ用に、
    その内容のインラインテーブルが追加された(0.6.0)

en: A table of contents is now generated dynamically using JavaScript for extra
    file pages (such as README's, or this document). It is generated based off the
    headers (h1,h2,... tags) used in the document, and can be floated to the
    right or listed inline on the page.
ja: コンテンツのテーブルは追加のファイルのページ用に、
    JavaScriptによって動的に生成されるようになった(READMEやこのドキュメントのように)。
    これは、ドキュメントで利用されたヘッダー(h1,h2,... tags)がのぞかれた
    ベースを生成し右側に添えられるか、又は、ページ上でインラインが記述される。

en: ## Ad-hoc tag registration via `yardoc` CLI (`--tag`, etc.) (0.6.0)
ja: ## `yardoc`CLI(`--tag`, etc.)経由での臨時のタグの記録 (0.6.0)

en: Simple meta-data tags can now be added at the command-line and registered to
    display in templates in a number of pre-defined ways. For instance, to create
    a freeform text tag, use the following:
ja: 単純なメタデータタグは
    コマンドラインで追加され、事前に定義されたいくつか方法で
    テンプレートの中で表示されるために登録されるようになった。
    例えばフリーフォームテキストのタグを作成するには、次のようになる:

en: You can also create a "typed" tag (similar to `@return`), a typed named tag
    (similar to `@param`) as well as various combinations. The full list of
    options are listed in `yardoc --help` under the "Tag Options" section.
ja: あなたは"型"のタグ(`@return`と同様に)も
    型のタグ名(`@param`と同様に)も様々な組み合わせもを作成する事もできる。
    オプションの完全なリストは
    `yardoc --help`の "Tag Options" のセクションよりで記述される。

en: If you wish to create a tag to store data but do not wish to show this data
    in the templates, use the `--hide-tag` option to hide it from generated output:
ja: あなたがデータを登録するためにタグを作成することを望むが、
    テンプレートの中のこのデータを一覧したくない場合、
    生成された出力からそれを隠すには`--hide-tag`オプションを使う。

en: ## Added `--transitive-tags` to register transitive tags (0.6.0)
ja: ## 過渡的なタグを記録するのに、`--transitive-tags`を追加された (0.6.0)

en: Transitive tags are tags that apply to all descendants of a namespace (class
    or module) when documented on that namespace. For instance, the `@since` tag
    is a transitive tag. Applying `@since` to a class will automatically apply
    `@since` to all methods in the class. Creating a `@since` tag directly on a
    method will override the inherited value.
ja: transitiveタグは、namespace上(クラス又はモジュール)で記述された時、
    全てのnamespaceの子孫に適用するタグである。
    例えば、`@since`タグはTransitiveタグである。
    クラスに`@since`タグを適用すると、
    クラスの中の全てのメソッドに自動的に`@since`が適用される
    メソッドで直接`@since`タグを作成すると継承された値をオーバーライドする。

en: You can specify transitive tags on the command-line by using this option. Note
    that the tags must already exist (built-in or created with the `--tag` option)
    to be specified as transitive. If you wish to do this programmatically, see
    the {YARD::Tags::Library.transitive_tags} attribute.
ja: このオプションによって
    コマンドラインのタグを過渡的に指定できる
    transitiveとして指定される
    タグは既に存在しなければならない。
    (組み込みや`--tag`オプションによって作成された)
    あなたがこのプログラムを実行したいなら、 {YARD::Tags::Library.transitive_tags} 属性を参照する。

en: ## `yardoc` now displays RDoc-like statistics (`--no-stats` to hide) (0.6.0)
ja: ## `yardoc`は、RDocのような統計値の表示するようになった。(`--no-stats`で隠す) (0.6.0)

en: As seen in the `yard stats` feature overview, `yardoc` displays RDoc-like
    statistics when it is run. The output is equivalent to typing `yard stats`.
    To hide this output when yardoc is run, use `--no-stats`.
ja: 上記のように`yard stats`機能の概要は
    `yardoc`が起動する時にRDocのように統計を表示する
    出力は`yard stats`をタイプするのと同様である。
    yardocが起動する時にこの出力を隠すには、
    `--no-stats`を使う

en: ## `yri` now works on constants (0.6.0)
ja: ## `yri`定数の処理をできるようになった (0.6.0)

en: Templates have now been added for text view of constants, which displays any
    documentation and the constant value.
ja: テンプレートは定数の一覧を作成するため追加されるようになった。
    これは任意のドキュメントと定数を表示する。

en: ## Plugins are no longer auto-loaded (added `--plugin` switch) (0.6.2)
ja: ## プラグインは自動でロードされなくなった。(`--plugin`引数で追加できる) (0.6.2)

en: This is a backwards-incompatible change that disables plugins from automatically
    loading when YARD starts up. From now on, you should manually declare which
    plugins your project is using by adding `--plugin PLUGINNAME` to a `.yardopts`
    file in the root of your project. You can also re-enable autoloaded plugins
    by setting `load_plugins` to true in your configuration file (`yard config load_plugins true`,
    see next item). You can also set `autoload_plugins` to a list of plugins
    to be automatically loaded on start.
ja: これはYARDのスタートアップする時の自動的なロードから
    プラグインを無効化する非後方互換な変更である。
    今後はあなたは手動で宣言しなければならない、
    それはあなたのプロジェクトのプラグインが
    あなたのプロジェクトのrootで`.yardopts`ファイルに
    `--plugin PLUGINNAME`を追加することによって利用される。
    あなたの設定ファイルの中で`load_plugins`をtrueに設定する事によって
    自動でロードされるプラグインを再度有効にできる。
    (`yard config load_plugins true`, 事項参照)
    あなたは、起動時に自動的にロードする為にプラグインのリストに
    `autoload_plugins`に設定する事も出来る。

en: If you are a YARD plugin author, please make sure to inform your users of these
    changes.
ja: あなたがYARDプラグインの作者の場合、
    これらの変更をあなたのユーザーに通知するか確認してください。

en: Note that `--plugin` switches passed on the commandline (not via `.yardopts`)
    are parsed before commands are loaded, and therefore can add in new CLI commands.
ja: 次のことに留意する。
    コマンドライン(`.yardopts`経由ではない)で渡された--pulugin引数はコマンドがロードされる前に解析され、
    その結果、新しいCLIコマンドの中で追加できる。

en: ## Added `YARD::Config` API and `~/.yard/config` configuration file (0.6.2)
ja: ## `YARD::Config` APIと`~/.yard/config`設定ファイルが追加された。 (0.6.2)

en: There is a new global configuration API that can be accessed programmatically
    and set via the `~/.yard/config` file. The file is encoded as a YAML file,
    and looks like:
ja: これらは、プログラムにアクセスできる新しいグローバル設定APIとなり、
    `~/.yard/config`ファイル経由で設定される。
    ファイルはYAMLファイルとしてエンコードされる、次のようになる

en: You can also set configuration options via the command-line (see next item).
ja: あなたは、コマンドライン経由で設定オプションを設定できる。(次項参照)

en: ## Added `yard config` command to view/edit configuration (0.6.2)
ja: ## 設定を一覧/編集する為に`yard config` コマンドが追加された (0.6.2)

en: A new `yard config` command was created to view or edit the configuration
    file via the commandline.
ja: 新しい`yard config`コマンドが、
    コマンドライン経由で設定ファイルを一覧・編集する為に作成された。

en: * To view the current configuration use `yard config --list`.
    * To view a specific item use `yard config ITEMNAME`
    * To modify an item value use `yard config ITEMNAME VALUE`
ja: * 現在の設定を一覧するには、`yard config --list`を使う
    * 特定の項目(item)を一覧するには、`yard config ITEMNAME`を使う
    * 項目の値を変更するには、`yard config ITEMNAME VALUE`を使う

en: ## Added `yard server -t` template path switch (0.6.2)
ja: ## `yard server -t`テンプレートパス引数が追加された (0.6.2)

en: The `yard server` command now accepts `-t` or `--template-path` to register
    a new template path for template customization.
ja: `yard server` コマンドは、
    テンプレートをカスタマイズする為に新しいテンプレートパスを記録する為、
    `-t`、又は、`--template-path`を受け入れる。

en: ## Added `YARD::Server.register_static_path` for static server assets (0.6.2)
ja: ## 静的なサーバー資源用に`YARD::Sever.register_static_path`が追加された。 (0.6.2)

en: The server now supports a command to register static asset paths. If you are
    extending the YARD::Server modules, make sure to register your asset paths
    through this method.
ja: サーバーは静的な資源のパスを記録する為のコマンドをサポートするようになった。
    あなたが、YARD::Serverモジュールを拡張する場合は、
    このメソッドを通してあなたの資源のパスを記録するか確認してください。

en: ## YARD::Registry is now thread local (0.6.5)
ja: ## YARD::Registryはスレッドローカルとなった (0.6.5)

en: Creating a new thread will now implicitly load a new Registry that can be used
    to parse and process new code objects independently of the other threads. Note
    that this means you can no longer use the Registry across threads; you must
    either access the threadlocal object directly, or synchronize threads to do
    the processing in the initial registry's thread.
ja: 新しいスレッドの作成は暗黙の内に、
    解析する為に利用できる新しいレジストリーをロードするだろう。
    そして、他のスレッドとは独自に新しいコードオブジェクトを処理する。
    次の事に留意する。
    これはあなたがもう、スレッドを渡ってレジストリーを利用する必要はないことを意味する。
    あなたは、スレッドのローカルオブジェクトに直接アクセスするか、又は、
    スレッドのレジストリーの初期化の処理をする為にスレッドを同期しなければならない。

en: ## Support for ripper gem in Ruby 1.8.7 (0.6.5)
ja: ## Ruby 1.8.7 でのripper gemのサポート (0.6.5)

en: YARD now supports the Ruby 1.8.7 port of the `ripper` gem to improve parsing
    of source, both in terms of performance and functionality. When the `ripper`
    gem is available, YARD will use the "new-style" handlers. You can take advantage
    of this functionality by performing a `gem install ripper`.
ja: パフォーマンスと機能性の両面で、
    YARDはソースの解析を向上する為に`ripper`gemのRuby1.8.7の一部をサポートするようになった。
    `ripper`gemが実行可能な時、YARDは"new-style"のハンドラーを利用する。
    `gem install ripper`を実行する事で、この機能の恩恵を受ける事ができる。

en: 1. **Support for documenting native Ruby C code** (0.5.0)
    2. **Incremental parsing and output generation with `yardoc -c`** (0.5.0, 0.5.3)
    2. **Improved `yri` support to perform lookups on installed Gems** (0.5.0)
    3. **Added `yardoc --default-return` and `yardoc --hide-void-return`** (0.5.0)
    4. **Multiple syntax highlighting language support** (0.5.0)
    5. **New .yardoc format** (0.5.0)
    6. **Support for yard-doc-* gem packages as hosted .yardoc dbs** (0.5.1)
    7. **Support for extra search paths in `yri`** (0.5.1)
    8. **Generating HTML docs now adds frames view** (0.5.3)
    9. **Tree view for class list** (0.5.3)
    10. **Ability to specify markup format of extra files** (0.5.3)
    11. **Keyboard shortcuts for default HTML template** (0.5.4)
ja: 1. **RubyとCのコードのドキュメント化をサポートする** (0.5.0)
    2. **`yaradoc -c`を用いたインクリメンタルな解析と出力生成ができるようになった** (0.5.0, 0.5.3)
    3. **`yardoc --default-return`と`yardoc --hide-void-return`が追加された** (0.5.0)
    4. **複数の構文のハイライトする言語をサポート** (0.5.0)
    5. **新しい.yardocフォーマット** (0.5.0)
    6. **ホストされた.yardoc dbsとしてyard-doc-* gem パッケージをサポートする** (0.5.1)
    7. **`yri`で追加の検索パスをサポートする** (0.5.1)
    8. **HTMLドキュメントの生成はフレーム一覧が追加されるようになった** (0.5.3)
    9. **クラスリスト用のツリービュー** (0.5.3)
    10. **追加のファイルのマークアップフォーマットを指定する機能** (0.5.3)
    11. **デフォルトのHTMLテンプレート用のキーボードショートカット** (0.5.4)

en: Support for documenting native Ruby C code (0.5.0)
    --------------------------------------------------
ja: RubyとCのコードのドキュメント生成のサポート (0.5.0)
    --------------------------------------------------

en: It is now possible to document native Ruby extensions with YARD with a new
    C parser mostly borrowed from RDoc. This enables the ability to document
    Ruby's core and stdlibs which will be hosted on http://yardoc.org/docs. In
    addition, the .yardoc dump for the Ruby-core classes will become available
    as an installable gem for yri support (see #3).
ja: 大部分をRDocから取り入れた新しいCパーサーと共にYARDを用い
    Rubyの拡張ドキュメントを実行可能になった。
    これは、Rubyのコアと標準ライブラリを記述する事を可能にする。
    そして、http://yardoc.org/docs でホスト(アクセスできる)されるだろう。
    さらに、Rubyコアクラス用の.yardocのダンプは、
    yriのサポートに用いるインストール可能なgemとして利用可能になるだろう。(#3 参照)

en: Incremental parsing and output generation with `yardoc -c` (0.5.0, 0.5.3)
    -------------------------------------------------------------------------
ja: `yaradoc -c`を用いたインクリメンタルな解析と出力生成 (0.5.0, 0.5.3)
    -------------------------------------------------------------------------

en: YARD now compares file checksums before parsing when using `yardoc -c`
    (aka `yardoc --use-cache`) to do incremental parsing of only the files that
    have changed. HTML (or other output format) generation will also only be
    done on the objects that were parsed from changed files (\*). This makes doing
    a documentation development cycle much faster for quick HTML previews. Just
    remember that when using incremental output generation, the index will not
    be rebuilt and inter-file links might not hook up right, so it is best to
    perform a full rebuild at the end of such previews.
ja: YARDはインクリメンタルに変更されたファイルだけ解析をする為に、
    `yardoc -c`(別名 `yardoc --use-cache`)を使う時、解析前のファイルを比較する。
    HTML(又は、他の出力フォーマット)生成は、
    変更されたファイル(\*)から解析されるオブジェクト上で実行されるだけである。
    これにより迅速なHTMLプレビューの為に、より速い開発サイクルを作りあげる事ができる。
    ただインクリメンタルな出力生成によって覚えておいてほしいことは、
    インデックスが再構築されない事とファイル間のリンクが正しく接続されないかもしれない、
    なので、このようなプレビューの終了時に完全な再構築を実行することをお勧めします。

en: (\*) Only for versions prior to 0.5.3. For 0.5.3+, use `--incremental` for
    incremental HTML output.
ja: (\*) 0.5.3より前のバージョンのみ、0.5.3以上の場合は、
    インクリメンタルHTML出力用の`--incremental`を使う。

en: Improved `yri` support to perform lookups on installed Gems (0.5.0)
    -------------------------------------------------------------------
ja: インストールされたgemを検索する為の`yri`のサポートが改良された。(0.5.0)
    -------------------------------------------------------------------

en: The `yri` executable can now perform lookups on gems that have been parsed
    by yard. Therefore, to use this command you must first parse all gems with
    YARD. To parse all gems, use the following command:
ja: 実行可能な`yri`コマンドは、YARDで解析されていたgemの検索を実行できるようになった。
    したがって、このコマンドを使う為には、
    あなたは、最初に全てのgemをYARDで解析しなければならない。
    全てのgemを解析する為には、次のコマンドを利用する:

en: The above command builds a .yardoc file for all installed gems in the
    respective gem directory. If you do not have write access to the gem path,
    YARD will write the yardoc file to `~/.yard/gem_index/NAME-VERSION.yardoc`.
ja: 上のコマンドは、gemディレクトリに関係する全てのインストール済みのgem用に.yardocファイルをビルドする。
    あなたが、gemのパスへのアクセスを書き込んでいない場合、
    YARDは`~/.yard/gem_index/NAME-VERSION.yardoc`にyardocファイルを書き込むだろう。

en: Note: you can also use `--re-build-gems` to force re-parsing of all gems.
ja: 注意:あなたは、全てのgemめ強制的に再解析するのに、`--re-build-gems`を使うこともできる。

en: You can now do lookups with yri:
ja: あなたは、下のようにyriで検索できるようになった

en: All lookups are cached to `~/.yard/yri_cache` for quicker lookups the second
    time onward.
ja: 全ての検索は、２度目の検索をより早くする為に、
    `~/.yard/yri_cache`にキャッシュされる。

en: Added `yardoc --default-return` and `yardoc --hide-void-return` (0.5.0)
    -----------------------------------------------------------------------
ja: `yardoc --default-return`と`yardoc --hide-void-return`が追加された (0.5.0)
    -----------------------------------------------------------------------

en: YARD defaults to displaying (Object) as the default return type of any
    method that has not declared a @return tag. To customize the default
    return type, you can specify:
ja: YARDは@returnタグで宣言されなかった、
    任意のデフォルトのメソッドの型を返し表示する事をデフォルトにする。
    デフォルトの返す型をカスタマイズするには、以下のように指定する:

en: You can also use the empty string to list no return type.
ja: あなたは、返す型が無いのを記述するのに、空の文字列を利用できる。

en: In addition, you can use --hide-void-return to ignore any method that
    defines itself as a void type by: `@return [void]`
ja: さらに、あなたは、`@return [void]`でそれ自身をvoidの型として定義する
    任意のメソッドに--hide-void-returnを利用できる。

en: Multiple syntax highlighting language support (0.5.0)
    -----------------------------------------------------
ja: 複数の構文ハイライト用の言語サポート (0.5.0)
    -----------------------------------------------------

en: YARD now supports the ability to specify a language type for code blocks in
    docstrings. Although no actual highlighting support is added for any language
    but Ruby, you can add your own support by writing your own helper method:
ja: YARDはdocstringの中のコードブロック用に、
    言語の型を指定する機能をサポートするようになった。
    実際のハイライトサポートは、全ての言語に追加されているわけではないが
    Rubyは、あなた自身がhelperメソッドを書くことによってサポートを追加する事ができる。

en:     # Where LANGNAME is the language:
        def html_syntax_highlight_LANGNAME(source)
          # return highlighted HTML
        end
ja:     # LANGNAMEがlanguageの場所:
        def html_syntax_highlight_LANGNAME(source)
          # ハイライトされたHTMLを返す
        end

en: To use this language in code blocks, prefix the block with `!!!LANGNAME`:
ja: コードブロックでこの言語を利用するには、次のように`!!!LANGNAME`を用い前に置く。

en: By the same token. you can now use `!!!plain` to ignore highlighting for
    a specific code block.
ja: 同じトークンで、
    あなたは特定のコードブロック用のハイライトを無視する為に`!!!plain`が利用できるようになった。

en: New .yardoc format (0.5.0)
    --------------------------
ja: 新しい.yardocフォーマット (0.5.0)
    --------------------------

en: To make the above yri support possible, the .yardoc format was redesigned
    to be a directory instead of a file. YARD can still load old .yardoc files,
    but they will be automatically upgraded if re-saved. The new .yardoc format
    does have a larger memory footprint, but this will hopefully be optimized
    downward.
ja: 上のyriサポートを可能にする為に、
    .yardocフォーマットはファイルの代わりにディレクトリに記録される事になった。
    YARDは尚、古い.yardocファイルをロードできるが、
    しかし、それは、再セーブした場合、自動的に上書きされるだろう。
    新しい.yaradocフォーマットは、より大きいメモリ足跡をもっているが
    しかしこれは、恐らく下方修正されるだろう。

en: Support for yard-doc-* gem packages as hosted .yardoc dbs (0.5.1)
    -----------------------------------------------------------------
ja: .yardoc dbs でホストされたyard-doc-* gem パッケージ用のサポート
    -----------------------------------------------------------------

en: You can now install special YARD plugin gems titled yard-doc-NAME to get
    packaged a .yardoc database. This will enable yri lookups or building docs
    for the gem without the code.
ja: あなたは、パッケージされた.yardocデータベースを取得する為に
    yard-doc-NAMEと名付けられた特殊なYARDプラグインのgemをインストールできるようになった。
    これは、コード無しでgem用のdocstringをyriで検索、又は、ビルドを可能にするだろう。

en: One main use for this is the `yard-doc-core` package, which enabled yri
    support for Ruby core classes (stdlib coming soon as `yard-doc-stdlib`).
    To install it, simply:
ja: これの主なものとしては、`yard-doc-core`パッケージである。
    これはRubyのコアクラス用のyriサポートを有効化する
    (標準ライブラリは`yard-doc-stdlib`として近日登場予定)
    簡単にインストールするには:

en:     $ sudo gem install yard-doc-core
        # now you can use:
        $ yri String
ja:     $ sudo gem install yard-doc-core
        # あなたは次のコマンドを使えるようになった:
        $ yri String

en: This will by default install the 1.9.1 core library. To install a library
    for a specific version of Ruby, use the `--version` switch on gem:
ja: これは、1.9.1のコアライブラリをデフォルトでインストールする。
    Rubyの固有のバージョンのライブラリをインストールするには、
    次のように、gemで`--version`引数を利用する:

en: Support for extra search paths in `yri` (0.5.1)
    -----------------------------------------------
ja: `yri`で追加の検索パスをサポートされた (0.5.1)
    -----------------------------------------------

en: You can now add custom paths to non-gem .yardoc files
    by adding them as newline separated paths in `~/.yard/yri_search_paths`.
ja: あなたは`~/.yard/yri_search_paths`の中に
    改行に区切られたパスとして追加する事によって
    gem無しの.yardocファイルに
    カスタムパスを追加できるようになった。

en: Generating HTML docs now adds frames view (0.5.3)
    -------------------------------------------------
ja: HTMLのdocstringを生成するとフレームの一覧が追加されるようになった (0.5.3)
    -------------------------------------------------

en: `yardoc` will now create a `frames.html` file when generating HTML documents
    which allows the user to view documentation inside frames, for those users who
    still find frames beneficial.
ja: `yardoc`はHTMLドキュメントを生成する時、
    `frames.html`ファイルを作成できるようになった。
    これは、フレームで探すのが便利だとするユーザーの為に、
    フレーム内のドキュメントを一覧する為にユーザーを受け入れる。

en: Tree view for class list (0.5.3)
    --------------------------------
ja: クラスリスト用のツリー 一覧 (0.5.3)
    --------------------------------

en: The class list now displays as an expandable tree view to better organized an
    otherwise cluttered namespace. If you properly namespace your less important
    classes (like Rails timezone classes), they will not take up space in the
    class list unless the user looks for them.
ja: クラスリストは別の乱雑なnamespaceをより体型化する為に
    拡張可能なツリー 一覧を表示できるようになった。
    あなたが重要でないクラスをnamespaceにした場合、
    (Railsのtimezome classのような)
    それら(重要でないクラス)は、ユーザーが検索しなければ、
    クラスリストのスペースを専有しない。

en: Ability to specify markup format of extra files (0.5.3)
    -------------------------------------------------------
ja: 追加のファイルのマークアップフォーマットを指定する為の機能 (0.5.3)
    -------------------------------------------------------

en: You can now specify the markup format of an extra file (like README) at the
    top of the file with a shebang-like line:
ja: あなたは、次のshebangのような行を用いファイルのトップで
    追加のファイルの(READMEのような)固有のマークアップフォーマットを指定できるようになった。

en: The above file contents will be rendered with a textile markup engine
    (eg. RedCloth).
ja: 上のファイルの内容は、textileマークアップエンジンで表示される(つまりRedCloth)。

en: You can now access the "Class List", "Method List" and "File List" with the
    'c', 'm' and 'f' keyboard shortcuts in the default HTML template, allowing
    for keyboard-only navigation around YARD documentation.
ja: あなたは、
    デフォルトのHTMLテンプレートで'c', 'm', 'f'のキーボードショートカットを用い、
    "Class List","Method List","File List"にアクセスできるようになった。
    これは、YARDドキュメントの周りのキーボードだけのナビゲーションを受入れる。

en: API for registering custom parsers (0.5.6)
    ------------------------------------------
ja: カスタムパーサーの記録用API (0.5.6)
    ------------------------------------------

en: You can now register parsers for custom source languages by calling the
    following method:
ja: あなたは、次のメソッドの様に呼び出される事で、
    カスタムソース言語用のパーサーを記録できるようになった。

en: The parser class MyJavaParser should be a subclass of {YARD::Parser::Base},
    and the last argument is a set of extensions (string, array or regexp). You
    can read more about registering parsers at the {YARD::Parser::SourceParser}
    class documentation.
ja: パーサークラスMyJavaParserは、{YARD::Parser::Base}のサブクラスになり、
    最後の引数は、拡張のグループ(string, array or regexp)になる。
    {YARD::Parser::SourceParser} クラスのドキュメントでパーサーを記録する方法について、
    詳細を見る事が出来る。

en: 1. **New templating engine and templates**
    2. **yardoc `--query` argument**
    3. **Greatly expanded API documentation**
    4. **New plugin support**
    5. **New tags (@abstract, @private)**
    6. **Default rake task is now `rake yard`**
ja: 1. **新しいテンプレートエンジンとテンプレート**
    2. **yardoc `--query` 引数**
    3. **Greatly expanded API ドキュメント**
    4. **新しいプラグインのサポート**
    5. **新しいタグ(@abstract, @private)**
    6. **デフォルトのrake taskは`rake yard`コマンドになった**

en: New templating engine and templates
    -----------------------------------
ja: 新しいテンプレートエンジンとテンプレート
    -----------------------------------

en: The templates were redesigned, most notably removing the ugly frameset, adding
    search to the class/method lists, simplifying the layout and making things
    generally prettier. You should also notice that more tags are now visible in
    the templates such as @todo, the new @abstract and @note tags and some others
    that existed but were previously omitted from the generated documentation.
ja: テンプレートは再設計された特に汚いフレームセットを削除しなければならない、
    クラス/メソッドのリストに検索を追加する。
    レイアウトを簡単にしてほとんどの場合きれいに作成するようになった。
    あなたがさらにタグで注意することは、
    @todo,新しい@abstract,@noteタグそしていくつか存在する他のタグなどのように
    テンプレートの中の可視性になった事である。
    しかし既に生成されたドキュメントからは除外される。

en: There is also a new templating engine (based on the tadpole templating library)
    to allow for much more user customization. You can read about it in
    {file:docs/Templates.md}.
ja: これは更なるユーザーのカスタマイズを受け入れる為の
    新しいテンプレートエンジンでもある(tadpoleテンプレートライブラリベースの)
    これらのについては{file:docs/Templates.md}の中で読む事ができる。

en: yardoc `--query` argument
    -------------------------
ja: yardoc `--query` 引数
    -------------------------

en: The yardoc command-line tool now supports queries to select which classes,
    modules or methods to include in documentation based on their data or meta-data.
    For instance, you can now generate documentation for your "public" API only by
    adding "@api public" to each of your public API methods/classes and using
    the following argument:
ja: yardocのコマンドラインツールは、
    データやメタデータの基のドキュメントを組み込む為に、
    そのクラス,モジュールやメソッドで選択するクエリーをサポートするようになった。
    例えば、あなたは、個々のpublic API メソッド/クラスに
    "@api public"を追加するだけで、自分の"public"API用にドキュメントを生成できるようになった。
    次の様に、引数を用いる:

en: More information on queries is in the {file:README.md}.
ja: クエリーの詳細な情報は{file:README.md}で

en: Greatly expanded API documentation
    ----------------------------------
ja: 非常に拡張されたAPIドキュメント
    ----------------------------------

en: Last release focused on many how-to and architecture documents to explain
    the design of YARD, but many of the actual API classes/methods were still
    left undocumented. This release marks a focus on getting YARD's own documentation
    up to par so that it can serve as an official reference on the recommended
    conventions to use when documenting code.
ja: 最後のリリースは沢山の操作手順とYARDのデザインを詳細に説明する為の
    アーキテクチャドキュメントに焦点を合わせた。
    しかし、実際のAPIクラス/メソッドの大部分は、いまだ記述されていない。
    このリリースは、標準的なYARD独自のドキュメントの取得に焦点を当てている。
    なのでこれは、コードを書く時に利用する推奨された公式のリファレンスとして提供できる。

en: New plugin support
    ------------------
ja: 新しいプラグインサポート
    ------------------

en: YARD now supports loading of plugins via RubyGems. Any gem named `yard-*` or
    `yard_*` will now be loaded when YARD starts up. Note that the '-' separator
    is the recommended naming scheme.
ja: YARDは、RubyGems経由でプラグインのロードをサポートできるようになった。
    `yard-*`や`yard_*`で名付けられた任意のgemは、YARDが起動する時にロードされるだろう。
    次の事に留意する。'-'区切りは、推奨された命名スキームである。

en: To ignore plugins, add the gem names to `~/.yard/ignored_plugins` on separate
    lines (or separated by whitespace).
ja: プラグインを無視するには、
    `~/.yard/ignored_plugins`ファイルで行区切り(又は、スペース区切りで)
    でgem名を追加する。

en: New tags (@abstract, @private)
    ------------------------------
ja: 新しいタグ(@abstract, @private)
    ------------------------------

en: Two new tags were added to the list of builtin meta-tags in YARD. `@abstract`
    marks a class/module/method as abstract while `@private` marks an object
    as "private". The latter tag is used in situations where an object is public
    due to Ruby's own visibility limitations (constants, classes and modules
    can never be private) but not actually part of your public API. You should
    use this tag sparingly, as it is not meant to be an equivalent to RDoc's
    `:nodoc:` tag. Remember, YARD recommends documenting private objects too.
    This tag exists so that you can create a query (`--query !@private`) to
    ignore all of these private objects in your documentation. You can also
    use the new `--no-private` switch, which is a shortcut to the aforementioned
    query. You can read more about the new tags in the {file:docs/GettingStarted.md}
    guide.
ja: 二つの新しいタグが、YARDの中の組み込みのメタタグのリストに追加された。
    `@abstract`は、概要(abstract)として、class/module/methodをマークする。
    さらに、`@private`は、"private"として、オブジェクトをマークする。
    後者のタグは、
    後のタグはオブジェクトがRuby自身の可視性の制約の為に
    実際のあなたのpublic APIの一部ではないにしてもpublic相当の場所で利用される
    (定数は、クラス、モジュールはプライベートにはできない)
    あなたは、慎重にこのタグを利用すべきである。
    RDocが`:nodoc:`タグと同様であるという意味ではない。
    YARDはprivate オブジェクトの記述も推奨する事を覚えておいてほしい。
    このタグは、あなたが、自分のドキュメントでこれらのprivateオブジェクトの全てを無視する為に
    クエリー(`--query !@private`)を作成できるように存在する。
    あなたは新しい`--no-private`引数を利用する事もできる。
    これは前述のクエリーへのショートカットである。
    さらに新しいタグについて知りたい場合は、 {file:docs/GettingStarted.md} のガイドで読むことができる。

en: Default rake task is now `rake yard`
    ------------------------------------
ja: デフォルトのrake taskは、`rake yard`となった
    ------------------------------------

en: Not a big change, but anyone using the default "rake yardoc" task should
    update their scripts:
ja: 大きな変更ではないが、誰もが使うデフォルトの"rake yardoc" taskは、
    次のスクリプトに変更された。

en: 1. **Full Ruby 1.9 support**
    2. **New parser code and handler API for 1.9**
    3. **A new `@overload` tag**
    4. **Better documentation**
    5. **Template changes and bug fixes**
ja: 1. **完全なRuby 1.9でのサポート**
    2. **1.9用の新しいパーサーのコードとハンドラーAPI**
    3. **新しい `@overload` タグ**
    4. **より良いドキュメント**
    5. **テンプレートの変更とバグの修正**

en: Full Ruby 1.9 support
    ---------------------
ja: 完全なRuby1.9のサポート
    ---------------------

en: YARD's development actually focuses primarily on 1.9 from the get-go, so it is
    not an afterthought. All features are first implemented for compatibility with
    1.9, but of course all functionality is also tested in 1.8.x. YARD 0.2.2 was
    mostly compatible with 1.9, but the new release improves and extends in certain
    areas where compatibility was lacking. The new release should be fully functional
    in Ruby 1.9.
ja: YARDの開発の実際の焦点は最初から1.9上が主で、結果として1.9になった訳ではない。
    全ての機能は、始めに1.9互換で実装されるが、もちろん1.8.xでもテストされている。
    YARD 0.2.2は、大部分が1.9を用い互換性があるが、
    新リリースは、互換性が欠けていた所を範囲を拡張する。
    新しいリリースは、Ruby 1.9で完全に機能するはずである。

en: New parser code and handler API for 1.9
    ---------------------------------------
ja: 1.9用の新しいパーサーコードとハンドラーAPI
    ---------------------------------------

en: Using Ruby 1.9 also gives YARD the advantage of using the new `ripper` library
    which was added to stdlib. The ripper parser is Ruby's official answer to
    projects like ParseTree and ruby2ruby. Ripper allows access to the AST as it
    is parsed by the Ruby compiler. This has some large benefits over alternative
    projects:
ja: Ruby1.9の使用で、YARDの標準ライブラリに追加された
    新しい`ripper`ライブラリの利点が与えられる。
    ripperパーサーは、
    ParseTreeとruby2rubyのように動かす為の
    Rubyの公式な回答である。
    Ripperは、Rubyコンパイラによって解析されるASTとしてアクセスを受入れる。
    これは、別のプロジェクトにくらべていくつかの大きな恩恵がある。

en:   1. It is officially supported and maintained by the Ruby core team.
      2. The AST is generated directly from the exact same code that drives the
         compiler, meaning anything that compiles is guaranteed to generate the
         equivalent AST.
      3. It needs no hacks, gems or extra libs and works out of the box in 1.9.
      4. It's *fast*.
ja:   1. 公式にRubyのコアチームによってサポートとメンテナンスされている。
      2. ASTはコンパイラを起動する同じコードから直接生成され、  
         コンパイルがASTと同様に生成する為に保証されるどんなものでも意味がある。
      3. 道具を必要としない。gemや、追加のライブラリ、1.9の箱の外の仕事を
      4. 速い

en: Having the AST means that developers looking to extend YARD have much better
    access to the parsed code than in previous versions. The only caveat is that
    this library is not back-compatible to 1.8.x. Because of this, there are
    subtle changes to the handler extension API that developers use to extend YARD.
    Namely, there is now a standard API for 1.9 and a "legacy" API that can run in
    both 1.8.x and 1.9 if needed. A developer can still use the legacy API to write
    handlers that are compatible for both 1.8.x and 1.9 in one shot, or decide to
    implement the handler using both APIs. Realize that the benefit of using the new
    API means 1.9 users will get a 2.5x parsing speed increase over running the legacy
    handlers (this is *in addition to* the ~1.8x speed increase of using YARV over MRI).
ja: ASTを持つ事は、開発者が拡張されたYARDがより多くの
    (前のバージョンより解析されたコードから)アクセスを持つので探す事を意味する。
    
    誤解を生まないよう注意するが、
    このライブラリは、1.8.xの後方互換ではない。
    これは何故かというと、
    開発者がYARDを拡張する為に利用する
    ハンドラーの拡張APIに難解な変更があるからである。
    即ち、必要なら、1.8.xと1.9両方で起動できる1.9用の標準APIと"legacy"APIになった。
    開発者は、1.8.xと1.9の両方のハンドラーを一回で書くのに、legacyAPIを利用できる。
    又、両方のAPIによってハンドラーを実装する事を決めた。
    1.9ユーザーの新しいAPIの手法を使う事によっての恩恵は、
    レガシーハンドラーの起動より解析するスピードが2.5x倍増大すると理解する。
    (これで、 *さらに*  ~1.8xのスピードがMRIでYARVを使う事によって増大する)

en: A new `@overload` tag
    ---------------------
ja: 新しい`@overload`タグ
    ---------------------

en: The new `@overload` tag enables users to document methods that take multiple
    parameters depending on context. This is basically equivalent to RDoc's call-seq,
    but with a name that is more akin to the OOP concept of method overloading
    that is actually being employed. Here's an example:
ja: 新しい`@overload`タグは、ユーザーが
    文脈の中で依存する複数のパラメータを取得するメソッドを記述する事を可能にする。
    これは、基本的に、RDocのcall-seqと同様であるが、
    オブジェクト指向の実際に用いられるオーバーロードのメソッドの概念により類似している。
    次のような例になる:

en: As you can see each overload takes its own nested tags (including a docstring)
    as if it were its own method. This allows "virtual" overloading behaviour at
    the API level to make Ruby look like overload-aware languages without caring
    about the implementation details required to add the behaviour.
ja: 上のオーバーロードは、それが独自のメソッドのように
    入れ子になった自身のタグを取得する(docstringを含んでいる)。
    これは、振舞いを追加するのに必要とされる詳細の実装について気にすることなく、
    Rubyをオーバーロードに考慮した言語のように構成する為に、
    APIレベルで"仮の"オーバーロードの挙動も受入れる。

en: It is still recommended practice, however, to stay away from overloading when
    possible and document the types of each method's real parameters. This allows
    toolkits making use of YARD to get accurate type information for your methods,
    for instance, allowing IDE autocompletion. There are, of course, situations
    where overload just makes more sense.
ja: これはまだ推奨案だが、
    可能な時はオーバーロードを使わないで、実際の引数の個々のメソッドの型を記述する。
    これで、貴方のメソッド用に正確な型情報を取得する為にYARDのツールキットの使用が受入れられる。
    例えば、IDEの自動補完をがある。
    これは勿論、オーバーロードでより多くの意味を成す場合もある。

en: Better documentation
    --------------------
ja: より良いドキュメント
    --------------------

en: The first few iterations of YARD were very much a proof of concept. Few people
    were paying attention and it was really just pieced together to see what was
    feasible. Now that YARD is gaining interest, there are many developers that
    want to take advantage of its extensibility support to do some really cool stuff.
    Considerable time was spent for this release documenting, at a high level, what
    YARD can do and how it can be done. Expect this documentation to be extended and
    improved in future releases.
ja: 最初のいくつかのYARDのイテレータはよくできた概念の証明である。
    いくらかの人は、注意を払ったり、それが本当に可能なのか見る為に一緒に試したりしただろう。
    現在のYARDは関心を集めているので、
    いくつかの本当にイカした拡張サポートがほしい沢山の開発者がいる。
    かなりの時間、このリリースで、
    YARDで何ができるのかとどのような方法が出来るのかハイレベルで記述するのに費やされた。
    このドキュメントが拡張され、機能のリリースで改良されるよう事を期待する。

en: Template changes and bug fixes
    ------------------------------
ja: テンプレートの変更とバグ修正
    ------------------------------

en: Of course no new release would be complete without fixing the old broken code.
    Some tags existed but were not present in generated documentation. The templates
    were mostly fixed to add the major omitted tags. In addition to template adjustments,
    many parsing bugs were ironed out to make YARD much more stable with existing projects
    (Rails, HAML, Sinatra, Ramaze, etc.).
ja: 勿論、新しいリリースで、古い壊れたコードを修正無しで仕上げられるだろう。
    いくつか存在したタグが、生成されるドキュメントで存在しなくなった。
    テンプレートは、メジャーだが抜かされたタグを追加する為に大部分が修正された。
    テンプレートの調整に加えて、
    既存のプロジェクトを用い(Rails, HAML, Sinatra, Ramaze, etc.)より安定したYARDを作る為に、
    多くの解析のバグは無視された。

en: The root path for YARD source libraries
ja: YARDソースライブラリ用のルートパス

en: The root path for YARD builtin templates
ja: YARDビルトインテンプレート用のルートパス

en: An alias to {Parser::SourceParser}'s parsing method
ja: 解析用の{Parser::SourceParser}メソッドへのエイリアス

en: tag|example|Parse a glob of files
ja: ファイルのglobを解析する。

en: tag|example|Parse a string of input
ja: tag|example|入力の文字列を解析する

en: Loads gems that match the name 'yard-*' (recommended) or 'yard_*' except
    those listed in +~/.yard/ignored_plugins+. This is called immediately
    after YARD is loaded to allow plugin support.
ja: 'yard-*'(推奨される)や'yard_*'の名前にマッチするgemをロードする。
    これを除外するには、 +~/.yard/ignored_plugins+ の中に対象の名前を記述する。
    これは、YARDがプラグインサポートをロードした後すぐに呼び出される。

en: Namespace for command-line interface components
ja: コマンドラインインタフェースコンポーネント用のNamespace

en: A "code object" is defined as any entity in the Ruby language.
    Classes, modules, methods, class variables and constants are the
    major objects, but DSL languages can create their own by inheriting
    from {CodeObjects::Base}.
ja: "code object"は、Ruby言語の中の任意の構成要素が定義される。
    クラスや、モジュール、メソッド、クラス変数、定数は重要なオブジェクトとなる。\n
    そして、DSL言語は、{CodeObjects::Base}からの継承によって
    DSL言語自身を作成できる。

en: Handlers are called during the data processing part of YARD's
    parsing phase. This allows YARD as well as any custom extension to
    analyze source and generate {CodeObjects} to be stored for later use.
ja: ハンドラーは、YARDの解析段階でデータの処理の間に呼び出される。
    これは、ソースの解析や後で使う為に記録される{CodeObjects}を生成する為に
    YARD本体も任意のカスタム拡張も受け入れる。

en: CRuby Handlers
ja: CRuby ハンドラー

en: All Ruby handlers
ja: 全てのRubyハンドラー

en: Handlers for old Ruby 1.8 parser
ja: 古いRuby1.8パーサー用のハンドラー

en: Namespace for internationalization (i18n)
ja: 国際化用のNamespace (i18n)

en: The parser namespace holds all parsing engines used by YARD.
    Currently only Ruby and C (Ruby) parsers are implemented.
ja: ParserのnamespaceはYARDによって利用される全てのパーサーエンジンをサポートする。
    今の所、RubyとC(Ruby)パーサーだけ実装されている。

en: CRuby Parsing components
ja: CRubyのパーサーの構成

en: Ruby parsing components.
ja: Rubyのパーサーの構成

en: Handles Ruby parsing in Ruby 1.8.
ja: Ruby1.8で利用されるパーサー処理

en: Holds Rake tasks used by YARD
ja: YARDによって利用されるRake taskを持つ

en: Namespace for components that serialize to various endpoints
ja: 様々な出力でシリアライズする構成用のNamespace

en: Namespace for classes and modules that handle serving documentation over HTTP
ja: HTTP経由でドキュメント作成の提供するクラスやモジュールの為のNamespace

en: == Implementing a Custom Server
    To customize the YARD server, see the {Adapter} and {Router} classes.
ja: == カスタムサーバーの実装
    YARDサーバーをカスタマイズするには、{Adapter}や{Router}クラス参照。

en: == Rack Middleware
    If you want to use the YARD server as a Rack middleware, see the documentation
    in {RackMiddleware}.
ja: == Rack Middleware
    あなたがRack MiddlewareのようにYARDサーバーを使いたい場合、
    {RackMiddleware}ドキュメントを参照。

en: Commands implement specific kinds of server responses which are routed
    to by the {Router} class. To implement a custom command, subclass {Commands::Base}.
ja: コマンドは特定のサーバーの応答のような実装。
    そして、{Router}クラスによって送られる。
    カスタムコマンドを実装する為には、{Commands::Base}サブクラス参照。

en: Namespace for Tag components
ja: タグの構成の為のNamespace

en: Namespace for templating system
ja: テンプレートシステム用のNamespace

en: Namespace for template helpers
ja: テンプレートへルパー用のNamespace

en: Namespace for markup providers
ja: マークアップを提供する為のNamespace

en: Abstract base class for CLI utilities. Provides some helper methods for
    the option parser
ja: CLIユーティリティ用の抽象的なベースクラス。
    オプションパーサー用のいくつかのヘルパーメソッドを提供する。

en: Helper method to run the utility on an instance.
ja: インスタンス上のユーティリティを起動する為のヘルパーメソッド。

en: Adds a set of common options to the tail of the OptionParser
ja: OptionParserの末尾に一般的なオプションのグループを追加する。

en: the option parser object
ja: パーサーオブジェクトのオプション

en: Parses the option and gracefully handles invalid switches
ja: オプションを解析し、無効な引数を処理する。

en: the arguments passed from input. This
    array will be modified.
ja: 引数は入力から解析される。
    この配列は、変更されるだろう。

en: Loads a Ruby script. If <tt>Config.options[:safe_mode]</tt> is enabled,
    this method will do nothing.
ja: Rubyスクリプトをロードする。 <tt>Config.options[:safe_mode]</tt> が有効の場合、
    このメソッドは、何もしないだろう。

en: the path to the script to load
ja: ロードするスクリプトの為のパス

en: This class parses a command name out of the +yard+ CLI command and calls
    that command in the form:
ja: このクラスは、 +yard+ CLIコマンド出力のコマンド名を解析する。
    以下の形式のコマンド呼び出しとなる。

en: If no command or arguments are specified, or if the arguments immediately
    begin with a +--opt+ (not +--help+), the {default_command} will be used
    (which itself defaults to +:doc+).
ja: コマンドが無い場合や、引数が指定される場合、
    又は、引数が直後に +--opt+ ( +--help+ ではない)で始まる場合、
    {default_command}が利用される。(そして自身の +:doc+ をデフォルトにする)

en: == Adding a Command
ja: == コマンドを追加する

en: To add a custom command via plugin, create a mapping in {commands} from
    the Symbolic command name to the {Command} class that implements the
    command. To implement a command, see the documentation for the {Command}
    class.
ja: プラグイン経由でカスタムコマンドを追加するには、
    そのコマンド名の象徴から
    コマンドを実装する{Command}クラスに
    {commands}のマッピングを作成する。
    コマンドを実装するには、{Command}クラス用のドキュメントを参照。

en: the mapping of command names to
    command classes to parse the user command.
ja: ユーザーコマンドを解析するコマンドクラスの為のコマンド名のマッピング

en: the default command name to use when no options
    are specified or
ja: オプションが指定されない時に利用するデフォルトのコマンド名

en: Convenience method to create a new CommandParser and call {#run}
ja: 新しいCommandParserを作成し、{#run}メソッドを呼び出す為の便利メソッド。

en: a new instance of CommandParser
ja: CommandParserの新しいインスタンス

en: Runs the {Command} object matching the command name of the first
    argument.
ja: 最初の引数のコマンド名にマッチする{Command}オブジェクトを起動する。

en: CLI command to view or edit configuration options
ja: CLIコマンドを調べる。
    又は、設定オプションを編集する。

en: the key to view/edit, if any
ja: 調べたり、編集する為のkey

en: the list of values to set (or single value), if modifying
ja: 変更する場合、セットする値のリストを返す(又は、単一の値)

en: whether to reset the {#key}
ja: {#key}をリセットするかどうか

en: whether the value being set should be inside a list
ja: 設定される値がリストの内部になるかどうか

en: whether to append values to existing key
ja: 既存のkeyに値を追加するかどうか

en: a new instance of Config
ja: Configの新しいインスタンス

en: CLI command to return the objects that were added/removed from 2 versions
    of a project (library, gem, working copy).
ja: プロジェクトの2つのバージョンから追加や削除された所のオブジェクトを返す為のCLIコマンド。
    (library, gem, working copy)

en: a new instance of Diff
ja: Diffの新しいインスタンス

en: a new instance of Gems
ja: Gemsの新しいインスタンス

en: Runs the commandline utility, parsing arguments and generating
    YARD indexes for gems.
ja: コマンドラインユーティリティを起動し、引数を解析し、gem用のYARDインデックスを生成する。

en: the list of arguments
ja: 引数のリスト

en: Builds .yardoc files for all non-existing gems
ja: 存在しないgem用に.yardocファイルをビルドする。

en: Parses options
ja: オプションを解析する。

en: Options to pass to the {Graph} CLI.
ja: {Graph} CLIに渡す為のオプション

en: the default output format
ja: デフォルトの出力フォーマット

en: whether to list the full class diagram
ja: 全てのクラス図をリストするかどうか

en: whether to show the object dependencies
ja: オブジェクトの依存関係を調べるかどうか

en: any contents to pass to the digraph
ja: 図に渡す内容

en: A command-line utility to generate Graphviz graphs from
    a set of objects
ja: オブジェクトのグループからGraphvizのグラフを生成する為のコマンドラインユーティリティ

en: The options parsed out of the commandline.
    Default options are:
      :format => :dot
ja: optionsはコマンドラインの出力を解析する。
    optionsのデフォルトは:
      :format => dot

en: The set of objects to include in the graph.
ja: graphでインクルードする為のオブジェクトのグループ

en: Creates a new instance of the command-line utility
ja: コマンドラインユーティリティの新しいインスタンスを作成する。

en: a new instance of Graph
ja: Graphの新しいインスタンス

en: Runs the command-line utility.
ja: コマンドラインユーティリティを起動する。

en: each tokenized argument
ja: 個々にトークナイズされた引数

en: Parses commandline options.
ja: コマンドラインオプションを解析する。

en: Handles help for commands
ja: コマンド用のヘルプを操作する。

en: a new instance of I18n
ja: I18nの新しいインスタンス

en: Lists all constant and method names in the codebase. Uses {Yardoc} --list.
ja: 全ての定数とコードベースの中のメソッド名を記述する。{yardoc} --list で利用する。

en: Runs the commandline utility, parsing arguments and displaying a
    list of objects
ja: コマンドラインユーティリティを起動し、引数を解析する。
    そして、オブジェクトのリストを表示する。

en: the list of arguments.
ja: 引数のリスト

en: A local documentation server
ja: ローカルドキュメントサーバー

en: a list of options to pass to the doc server
ja: ドキュメントサーバーに渡す為のオプションのリスト

en: a list of options to pass to the web server
ja: webサーバーに渡す為のオプションのリスト

en: a list of library names and yardoc files to serve
ja: ライブラリ名のリストと提供する為のyardocファイル

en: the adapter to use for loading the web server
ja: ロードするwebサーバー用に利用されるアダプタ

en: a list of scripts to load
ja: ロードする為のスクリプトのリスト

en: a list of template paths to register
ja: 登録するテンプレートのパスのリスト

en: Creates a new instance of the Server command line utility
ja: サーバーコマンドラインユーティリティの新しいインスタンスを作成する。

en: a new instance of Server
ja: サーバーの新しいインスタンス

en: Maintains the order in which +stats_for_+ statistics methods should be
    printed.
ja: オーダーを継続する。そして統計用の +stats_for_+ メソッドは、プリントされるべきである。

en: whether to parse and load registry
ja: 解析するかレジストリーをロードするかどうか

en: a new instance of Stats
ja: Statsの新しいインスタンス

en: whether to parse and load registry (see {#parse})
ja: 解析するかレジストリーがロードされるかどうか(see {#parse})

en: Runs the commandline utility, parsing arguments and generating
    output if set.
ja: コマンドラインユーティリティを起動し、引数を解析する。
    そしてグループの場合、出力を生成する。

en: Prints statistics for different object types
ja: 色々なオブジェクト型用に統計値をプリントする。

en: To add statistics for a specific type, add a method +#stats_for_TYPE+
    to this class that calls {#output}.
ja: 特定の型用に統計値を追加するには、
    {#output}メソッドに呼び出されるこのクラスに +#stats_for_TYPE+ メソッドを追加する。

en: Prints list of undocumented objects
ja: 記述されなかったオブジェクトのリストをプリントする。

en: all the parsed objects in the registry,
    removing any objects that are not visible (private, protected) depending
    on the arguments passed to the command.
ja: レジストリーの中の全ての解析されたオブジェクト,
    コマンドに渡された引数に応じて不可視(private,protected)のオブジェクトを削除している。

en: Statistics for files
ja: ファイル用の統計値

en: Statistics for modules
ja: モジュール用の統計値

en: Statistics for classes
ja: クラス用の統計値

en: Statistics for constants
ja: 定数用の統計値

en: Statistics for methods
ja: メソッド用の統計値

en: Prints a statistic to standard out. This method is optimized for
    getting Integer values, though it allows any data to be printed.
ja: 標準出力に統計値をプリントする。このメソッドは、
    Integerの値の取得用に最適化され、プリントされる為に任意のデータを受入れる。

en: number of undocumented objects for the type
ja: 型によって記述されなかったオブジェクトの数

en: the numeric (or any) data representing
    the statistic. If +data+ is an Integer, it should represent the
    total objects of a type.
ja: 数(又は何か)のデータを表す統計値。
    +data+ がIntegerの場合、型の全体のオブジェクトを表すはずである。

en: the statistic name
ja: 統計値の名前

en: the list of extra files rendered along with objects
ja: オブジェクトと一緒に表示される追加のファイルのリスト

en: the default output format (:html).
ja: デフォルト出力フォーマット (:html)

en: the list of code objects to render
    the templates with.
ja: リストと共にテンプレートを表示する為のコードオブジェクトのリスト

en: Yardoc is the default YARD CLI command (+yard doc+ and historic +yardoc+
    executable) used to generate and output (mainly) HTML documentation given
    a set of source files.
ja: Yardocは、デフォルトのYARD CLIコマンドとなり( +yard doc+ と省略表記の +yardoc+ が実行可能)、
    生成し、与えられたソースファイルのグループのHTMLドキュメントの出力(主な機能)の為に利用される。

en: == Usage
ja: == 使用法

en: Main usage for this command is:
ja: このコマンドの主な使用法は次のようになる:

en: See +yardoc --help+ for details on valid options.
ja: 有効なオプションの詳細は +yardoc --help+ で参照できる。

en: == Options File (+.yardopts+)
ja: == オプションファイル (+.yardopts+)

en: If a +.yardopts+ file is found in the source directory being processed,
    YARD will use the contents of the file as arguments to the command,
    treating newlines as spaces. You can use shell-style quotations to
    group space delimited arguments, just like on the command line.
ja: +.yardopts+ ファイルが、処理されるソースディレクトリで見つかった場合、
    YARDは、コマンドに引数としてファイルの内容を利用し、改行をスペースとして処理する。
    あなたはスペースで区切られた引数のグループに、
    コマンドラインのようなシェルスタイルの引用を利用できる。

en: A valid +.yardopts+ file might look like:
ja: 有効な +.yardopts+ ファイルは、次のようになる。

en: Note that Yardoc also supports the legacy RDoc style +.document+ file,
    though this file can only specify source globs to parse, not options.
ja: 次の事に留意する。Yardocは、レガシーなRDocスタイルの +.document+ ファイルもサポートするけれども、
    このファイルは、オプションはなしで、解析の為にソースのglobだけ指定できる。

en: == Queries (+--query+)
ja: == クエリー (+--query+)

en: Yardoc supports queries to select specific code objects for which to
    generate documentation. For example, you might want to generate
    documentation only for your public API. If you've documented your public
    methods with +@api public+, you can use the following query to select
    all of these objects:
ja: Yardocは、ドキュメントを生成する時に、
    特定のコードオブジェクトを選択する為にクエリーをサポートする。
    例えば、あなたが、
    自分のpublic APIの為だけにドキュメント生成したいかもしれない。
    あなたが、 +@api public+ を用いて記述されたpublicメソッドを持っていた場合、
    これらのオブジェクトの全てを選択する為に、次の様なクエリーを利用できる:

en: Note that the syntax for queries is mostly Ruby with a few syntactic
    simplifications for meta-data tags. See the {Verifier} class for an
    overview of this syntax.
ja: 次の事に留意する。クエリー用の構文は、
    主にRuby構文で、メタデータタグ用のいくつかの構文の簡単にしたものも用いている。
    この構文の概要は、{Verifier}クラス参照。

en: == Adding Custom Ad-Hoc Meta-data Tags (+--tag+)
ja: == カスタムした特別なメタデータタグ(+--tag+)を追加する

en: YARD allows specification of {file:docs/Tags.md meta-data tags}
    programmatically via the {YARD::Tags::Library} class, but often this is not
    practical for users writing documentation. To make adding custom tags
    easier, Yardoc has a few command-line switches for creating basic tags
    and displaying them in generated HTML output.
ja: YARDは、{YARD::Tags::Library}クラス経由でプラグラムされた{file:docs/Tags.md meta-data tags}の仕様を受入れるが、時々これは、ユーザーが書いているドキュメントとはそぐわない場合がある。
    簡単なカスタムタグを作成するには、
    Yardocが基本的なタグ作成用にいくつかのコマンドライン引数を持っており、
    それをHTML出力し表示できる。

en: To specify a custom tag to be displayed in output, use any of the
    following:
ja: 出力に表示されるカスタムタグを指定するには、次のように利用できる。

en: "TAG:TITLE" is of the form: name:"Display Title", for example:
ja: 以下のように"TAG:TITLE" は、 形式: 名前:"表示されるタイトル" とする。

en: See +yardoc --help+ for a description of the various options.
ja: 様々なオプションの説明は +yardoc --help+ 参照。

en: Tags added in this way are automatically displayed in output. To add
    a meta-data tag that does not show up in output, use +--hide-tag TAG+.
    Note that you can also use this option on existing tags to hide
    builtin tags, for instance.
ja: この方法で追加したタグは、自動的に出力で表示される。
    出力に表示しないでメタデータタグを追加するには、 +--hide-tag TAG+ を使う。
    次の事に留意する。あなたは、
    組み込みタグを隠す為に既存のタグ上でこのオプションも利用できる。

en: == Processed Data Storage (+.yardoc+ directory)
ja: == 処理されたデータストレージ (+.yardoc+ ディレクトリ)

en: When Yardoc parses a source directory, it creates a +.yardoc+ directory
    (by default, override with +-b+) at the root of the project. This directory
    contains marshal dumps for all raw object data in the source, so that
    you can access it later for various commands (+stats+, +graph+, etc.).
    This directory is also used as a cache for any future calls to +yardoc+
    so as to process only the files which have changed since the last call.
ja: Yardocがソースディレクトリを解析する時、プロジェクトのルートで +.yardoc+ ディレクトリを作成する。
    (デフォルトで、 +-b+ と共に上書きする)
    このディレクトリは、
    全てのソースの生のオブジェクトデータ用に整理されたダンプを含んでいるので、
    後で様々なコマンド用(+stats+, +graph+ 等)にアクセスできる。
    このディレクトリは、いつか +yardoc+ を呼び出す為にもキャッシュとして利用する。
    最後の呼び出しから変更した所のファイルだけ処理する為に。

en: When Yardoc uses the cache in subsequent calls to +yardoc+, methods
    or classes that have been deleted from source since the last parsing
    will not be erased from the cache (YARD never deletes objects). In such
    a case, you should wipe the cache and do a clean parsing of the source tree.
    You can do this by deleting the +.yardoc+ directory manually, or running
    Yardoc without +--use-cache+ (+-c+).
ja: Yardocが +yardoc+ 呼び出しに続くキャッシュを使う時、
    最後に解析しているのでソースから削除されているメソッドやクラスは、
    キャッシュから削除されない。(YARDはオブジェクトを決して削除しない)
    このような場合、あなたは、キャッシュを一掃し、クリーンなソースツリーの解析にするべきである。
    +.yardoc+ ディレクトリを手動で削除する事に上記の事ができる。
    又は、yardoc の +--use-cache+ (+-c+)無しで起動する。

en: The configuration filename to load extra options from
ja: 追加のオプションをロードする設定ファイル名

en: the hash of options passed to the template.
ja: テンプレートに解析された、optionsのハッシュ

en: list of Ruby source files to process
ja: 処理する為のRubyソースファイルのリスト

en: list of excluded paths (regexp matches)
ja: 除外されたパス(正規表現にマッチする)のリスト

en: whether to use the existing yardoc db if the
    .yardoc already exists. Also makes use of file checksums to
    parse only changed files.
ja: .yardocが既に存在する場合、既存のyardoc dbを利用するかどうか。
    従って、変更されたファイルだけ解析する為にファイルチェックサムを活用する。

en: whether to parse options from .yardopts
ja: .yardoptsから、オプションを解析するかどうか

en: whether to parse options from .document
ja: .documentからオプションを解析するかどうか

en: whether objects should be serialized to .yardoc db
ja: オブジェクトが.yardoc dbにシリアライズされるかどうか

en: whether to generate output
ja: 出力を生成するかどうか

en: whether to print a list of objects
ja: オブジェクトのリストをプリントするかどうか

en: The options file name (defaults to {DEFAULT_YARDOPTS_FILE})
ja: ファイル名のオプション(デフォルトでは{DEFAULT_YARDOPTS_FILE}になる)

en: the filename to load extra options from
ja: 追加のオプションをロードする為のファイル名

en: Keep track of which visibilities are to be shown
ja: visibilitiesで示されるその中で手順を維持する。

en: a list of visibilities
ja: visibilitiesのリスト

en: Keep track of which APIs are to be shown
ja: そのAPIが表示される経過を追う

en: a list of APIs
ja: APIのリスト

en: a list of tags to hide from templates
ja: テンプレートから隠すタグのリスト

en: whether to print statistics after parsing
ja: 解析の後で統計値をプリントするかどうか

en: a list of assets to copy after generation
ja: 生成の後でコピーする資産のリスト

en: whether markup option was specified
ja: マークアップオプションが指定されたかどうか

en: Creates a new instance of the commandline utility
ja: コマンドラインユーティリティの新しいインスタンスを作成する。

en: a new instance of Yardoc
ja: Yardocの新しいインスタンス

en: the list of arguments. If the list only
    contains a single nil value, skip calling of {#parse_arguments}
ja: 引数のリスト。リストがnilだけの場合、
    {#parse_arguments}メソッドを呼び出しスキップする。

en: Parses commandline arguments
ja: コマンドライン引数を解析する

en: whether or not arguments are valid
ja: 引数が有効かどうか

en: The list of all objects to process. Override this method to change
    which objects YARD should generate documentation for.
ja: 処理する上での全てのオブジェクトのリスト。
    変更するたびに、このメソッドは上書きするので、
    YARDのオブジェクトは、ドキュメントを生成するべきである。

en: To hide methods use the +@private+ tag instead.
ja: メソッドを隠すには、代わりに、 +@private+ タグを使う

en: a list of code objects to process
ja: 処理する為のコードオブジェクトのリスト

en: Parses the .yardopts file for default yard options
ja: デフォルトのyardオプション用に.yardoptsファイルを解析する。

en: an array of options parsed from .yardopts
ja: .yardoptsから解析されたオプションの配列

en: Generates output for objects
ja: オブジェクト用の出力を生成する

en: if supplied, a list of checksums for files.
ja: 提供する場合は、ファイルの為のチェックサムのリスト

en: Verifies that the markup options are valid before parsing any code.
    Failing early is better than failing late.
ja: 任意のコードを解析する前に、有効なマークアップオプションを認証する。
    (早期に失敗が分かるほうが、後で失敗するよりいいので)

en: Copies any assets to the output directory
ja: 出力ディレクトリに任意の資産をコピーする。

en: Prints a list of all objects
ja: 全てのオブジェクトのリストをプリントする

en: Parses out the yardopts/document options
ja: yardopts/documentオプションの出力を解析する

en: Reads a .document file in the directory to get source file globs
ja: ソースファイルのglobを取得する為にディレクトリの中の.documentファイルをロードする

en: an array of files parsed from .document
ja: .documentから解析されたファイルの配列

en: Adds a set of extra documentation files to be processed
ja: 処理される追加のドキュメントファイルのグループを追加する

en: the set of documentation files
ja: ドキュメントファイルのグループ

en: Parses the file arguments into Ruby files and extra files, which are
    separated by a '-' element.
ja: Rubyのファイルと追加のファイルをfilesの引数として解析する。
    それは、'-'要素によって区切られる。

en: tag|example|Parses a set of Ruby files with a separator and extra files
ja: Rubyのファイルと区切りを用いた追加のファイルのグループを解析する

en: tag|example|Parses a set of Ruby source files
ja: Rubyソースファイルのグループを解析する

en: the list of files to parse
ja: 解析するファイルのリスト

en: Adds verifier rule for visibilities
ja: visibilities用に認証ルールを追加する

en: Adds verifier rule for APIs
ja: API用に認証ルールを追加する

en: Runs a list of objects against the {Verifier} object passed into the
    template and returns the subset of verified objects.
ja: テンプレートへ渡された{Verifier}オブジェクトに対してオブジェクトのリストを起動する。
    そして、認証されたオブジェクトのサブセットを返す。

en: Adds general options
ja: 全体的なオプションを追加する。

en: Adds output options
ja: オプションの出力を追加する。

en: Adds tag options
ja: タグのオプションを追加する。

en: A tool to view documentation in the console like `ri`
ja: `ri`のようなコンソールでドキュメントを調べる為のツール

en: The location in {YARD::CONFIG_DIR} where the YRI cache file is loaded
    from.
ja: YRIキャッシュファイルがロードされる、{YARD::CONFIG_DIR}の中の場所

en: A file containing all paths, delimited by newlines, to search for
    yardoc databases.
ja: ファイルは、改行によって区切られたyardocデータベース用の検索する為の
    全てのパスを含んでいる。

en: Default search paths that should be loaded dynamically into YRI. These paths
    take precedence over all other paths ({SEARCH_PATHS_FILE} and RubyGems
    paths). To add a path, call:
ja: デフォルトでは、YRIへ動的にロードされるべきパスを検索する。
    これらのパスは、他のパス全てより優先して取得する({SEARCH_PATHS_FILE}とRubyGemsパス)。
    パスを追加するには、次のように呼び出す。

en: a list of extra search paths
ja: 追加の検索パスのリスト

en: a new instance of YRI
ja: YRIの新しいインスタンス

en: Prints the command usage
ja: コマンドの使用法をプリントする。

en: Caches the .yardoc file where an object can be found in the {CACHE_FILE}
ja: オブジェクトが{CACHE_FILE}の中を見つけられる場合、
    .yardocファイルをキャッシュする。

en: the formatted output for an object.
ja: オブジェクト用にフォーマットされた出力

en: the object to print.
ja: プリントする為のオブジェクト

en: Locates an object by name starting in the cached paths and then
    searching through any search paths.
ja: キャッシュされたパスで始まる名前のオブジェクトを示し、
    その時、任意の検索パスを通して検索する。

en: an object if found
ja: 見つかった場合は、オブジェクト

en: if no object is found
ja: オブジェクトが見つからない場合

en: the full name of the object
ja: オブジェクトのフルネーム

en: the object path
ja: オブジェクトパス

en: Loads {CACHE_FILE}
ja: {CACHE_FILE}をロードする

en: Adds all RubyGems yardoc files to search paths
ja: パスを検索する為に全てのRubyGemsyardocファイルを追加する

en: Adds paths in {SEARCH_PATHS_FILE}
ja: {SEARCH_PATHS_FILE}の中のパスを追加する。

en: A list of code objects. This array acts like a set (no unique items)
    but also disallows any {Proxy} objects from being added.
ja: コードオブジェクトのリスト、この配列はグループ(固有の物ではない)のように振る舞う。
    しかしながら、追加される任意の{Proxy}オブジェクトを拒否する。

en: Creates a new object list associated with a namespace
ja: namespaceに関連付けられた新しいオブジェクトのリストを作成する。

en: the namespace the list should be associated with
ja: リストで関連付けられるべき、namespace

en: Adds a new value to the list
ja: リストに新しく値を追加する

en: a code object to add
ja: 追加するコードオブジェクト

en: Namespace separator
ja: Namespace separator(ネームスペース区切り)

en: Regex-quoted namespace separator
ja: Regex-quoted namespace separator(クオートされた正規表現ネームスペース区切り)

en: Instance method separator
ja: Instance method separator(インスタンスメソッドの区切り)

en: Regex-quoted instance method separator
ja: Regex-quoted instance method separator(正規表現でクオートされたインスタンスメソッド区切り)

en: Class method separator
ja: Class method separator(クラスメソッド区切り)

en: Regex-quoted class method separator
ja: Regex-quoted class method separator(正規表現でクオートされたクラスメソッド区切り)

en: Regular expression to match constant name
ja: Regular expression to match constant name(定数名にマッチする正規表現)

en: Regular expression to match namespaces (const A or complex path A::B)
ja: namespaceにマッチする正規表現(const A or complex path A::B)

en: Regular expression to match a method name
ja: メソッド名にマッチする正規表現

en: Regular expression to match a fully qualified method def (self.foo, Class.foo).
ja: 全てに有効なメソッド定義(self.foo Class.fooなど)にマッチする正規表現

en: All builtin Ruby exception classes for inheritance tree.
ja: 継承ツリー用の全ての組み込みRuby例外クラス

en: All builtin Ruby classes for inheritance tree.
ja: 継承ツリー用の全てのRubyクラス

en: MatchingData is a 1.8.x legacy class
ja: マッチデータが1.8以降のレガシーケースの場合

en: All builtin Ruby modules for mixin handling.
ja: mixin操作用の全てのRuby組み込みモジュール

en: All builtin Ruby classes and modules.
ja: 全ての組み込みRubyクラスやモジュール

en: Hash of {BUILTIN_EXCEPTIONS} as keys and true as value (for O(1) lookups)
ja: {BUILTIN_EXCEPTIONS}のキーと,値がtrueのハッシュ,(for O(1) lookups)

en: +Base+ is the superclass of all code objects recognized by YARD. A code
    object is any entity in the Ruby language (class, method, module). A
    DSL might subclass +Base+ to create a new custom object representing
    a new entity type.
ja: +Base+ は、YARDによって表される全てのコードオブジェクトのスーパークラスとなる。
    コードオブジェクトは、Ruby言語の中の何らかの(class,method,module)構成要素となる。
    DSLは新しい構成要素の型で表されるカスタムオブジェクトを作成する為に、
    +Base+ をサブクラスとするかもしれない。

en: == Registry Integration
    Any created object associated with a namespace is immediately registered
    with the registry. This allows the Registry to act as an identity map
    to ensure that no object is represented by more than one Ruby object
    in memory. A unique {#path} is essential for this identity map to work
    correctly.
ja: == レジストリーの統合
    namespaceと共に関連付けられ作成される任意のオブジェクトは、レジストリーと共に直ぐに記録される。
    これは、メモリの中で一つ以上のRubyオブジェクトによって表される事を保証し、
    レジストリーが独自のマップの様に振る舞う事を受け入れる。
    固有の{#path}メソッドは、この独自のマップを正常に機能させる為に必須のものである。

en: == Namespaces
    There is a special type of object called a "namespace". These are subclasses
    of the {NamespaceObject} and represent Ruby entities that can have
    objects defined within them. Classically these are modules and classes,
    though a DSL might create a custom {NamespaceObject} to describe a
    specific set of objects.
ja: == Namespaces
    "namespace"に呼び出されるオブジェクトの特別な型がある。
    これらは{NamespaceObject}をサブクラス化し、
    それらの中で定義されるオブジェクトが持つ事が出来るRubyの構成要素を表す。
    オーソドックスなこれらのモジュールやクラスは、
    DSLが特定のオブジェクトのグループを説明する為に、
    カスタム{NamespaceObject}を作成するかもしれない。

en: This class should not be used directly. Instead, create a
    subclass that implements {#path}, {#sep} or {#type}.
ja: このクラスは、直接利用するべきではない。
    代わりに、{#path}, {#sep} , {#type}メソッドを実装するサブクラスを作成する。

en: The files the object was defined in. To add a file, use {#add_file}.
ja: 中で定義されたオブジェクトから成るファイル、
    ファイルを追加するには、{#add_file}メソッドを使う。

en: a list of files
ja: ファイルのリスト

en: The namespace the object is defined in. If the object is in the
    top level namespace, this is {Registry.root}
ja: 中で定義されるオブジェクトから成るnamespace,オブジェクトがtop level namespaceの場合、
    これは、{Registry.root}になる。

en: the namespace object
ja: namespaceオブジェクト

en: The source code associated with the object
ja: オブジェクトに関連付けられたソースコード

en: source, if present, or nil
ja: 存在する場合はソース,そうでなけば、nil

en: Language of the source code associated with the object. Defaults to
    +:ruby+.
ja: オブジェクトと共に関連付けられたソースコードの言語。
    デフォルトは +:ruby+ 。

en: the language type
ja: 言語の型

en: The one line signature representing an object. For a method, this will
    be of the form "def meth(arguments...)". This is usually the first
    source line.
ja: オブジェクトを一行の用法で表している。メソッド用、
    これは、"def meth(arguments...)"のような形式になるだろう。
    普通は、最初のソースの最初の行となる。

en: a line of source
ja: ソースの行

en: The documentation string associated with the object
ja: オブジェクトに関連付けられたドキュメント文字列

en: the documentation string
ja: ドキュメント文字列(docstring)

en: Marks whether or not the method is conditionally defined at runtime
ja: メソッドが実行時に定義された条件となるか、マークする。

en: true if the method is conditionally defined at runtime
ja: メソッドが実行時に定義された条件となる場合、true

en: the group this object is associated with
ja: このオブジェクトに関連付けられたグループ

en: Is the object defined conditionally at runtime?
ja: オブジェクトが実行時に条件が定義されたか?

en: the visibility of an object (:public, :private, :protected)
ja: オブジェクトの可視性(:public, :private, :protected)

en: Allocates a new code object
ja: 新しいコードオブジェクトを割り当てる。

en: Compares the class with subclasses
ja: サブクラスとクラスを比較する

en: the other object to compare classes with
ja: クラスと比較する他のオブジェクト

en: true if other is a subclass of self
ja: otherが自身のサブクラスの場合、true

en: Creates a new code object
ja: 新しいコードオブジェクトを作成する。

en: a block to perform any extra initialization on the object
ja: オブジェクト上で任意の追加のイニシャライズを実行するblock

en: tag|example|Create a method in the root namespace
ja: root namespaceの中にメソッドを作成する

en: tag|example|Create class Z inside namespace X::Y
ja: namespace X::Yの中にZクラスを作成する。

en: tag|param|namespace
ja: namespace

en: tag|yieldparam|self
ja: self

en: the name (or complex path) of the object.
ja: オブジェクトの名前(又は、complex path)

en: the namespace the object belongs in,
    {Registry.root} or :root should be provided if it is associated with
    the top level namespace.
ja: その中でオブジェクトの属するnamespace,
    top level namespaceと共に、
    {Registry.root} と :rootは、提供されるべきである。

en: the newly created object
ja: 新たに作成されたオブジェクト

en: the newly initialized code object
ja: 新たにinitializeされるコードオジェクト

en: the object to copy data to
ja: オブジェクトにデータをコピーする為のオブジェクト

en: the other object
ja: 他のオブジェクト

en: The name of the object
ja: オブジェクトの名前

en: if prefix is false, the symbolized name
ja: prefixがfalseの場合、シンボル化される名前

en: if prefix is true, prefix + the name as a String.
    This must be implemented by the subclass.
ja: prefixがtrueの場合、prefix + 名前の文字列となる。
    これは、サブクラスによって実装されなければならない。

en: tag|param|prefix
ja: prefix

en: whether to show a prefix. Implement
    this in a subclass to define how the prefix is showed.
ja: prefixを見せるかどうか。
    prefixがどのようにみせられるか定義する為に、
    このサブクラスの中で実装する。

en: Associates a file with a code object, optionally adding the line where it was defined.
    By convention, '<stdin>' should be used to associate code that comes form standard input.
ja: コードオブジェクトと共に、ファイルを関連付け、
    定義された場所で任意で行を追加する。
    慣習で、'<stdin>'は、標準入力形式で入って来るコードに関連付けて利用されるべきである。

en: tag|param|has_comments
ja: has_comments

en: tag|param|line
ja: param|line

en: the filename ('<stdin>' for standard input)
ja: ファイル名('<stdin>' は標準入力用)

en: the line number where the object lies in the file
ja: ファイルの中でオブジェクトが位置する,行数

en: whether or not the definition has comments associated. This
    will allow {#file} to return the definition where the comments were made instead
    of any empty definitions that might have been parsed before (module namespaces for instance).
ja: 定義が関連付けられたコメントを持っているかどうか。
    これは、解析される前に(例えば、module namespace)、空の定義の代わりに任意の作られたコメントで、
    定義を返す為に、{#file}メソッドを受け入れる。

en: Returns the filename the object was first parsed at, taking
    definitions with docstrings first.
ja: オブジェクトが、最初に解析された所で、
    最初のdocstringと共に、定義を取ってくるファイル名を返す

en: a filename
ja: ファイル名

en: Returns the line the object was first parsed at (or nil)
ja: オブジェクトが、最初に解析された所(又は、nil)の行を返す

en: if there is no line associated with the object
ja: オブジェクトと共に関連付けられた行がない場合

en: the line where the object was first defined.
ja: オブジェクトが最初に定義された所の行

en: Tests if another object is equal to this, including a proxy
ja: 他のオブジェクトがBaseとイコールかProxyを含んでいるかテストする。

en: if other is a {Proxy}, tests if
    the paths are equal
ja: pathがイコールの場合、
    otherが{Proxy}か、テストする。

en: whether or not the objects are considered the same
ja: オブジェクトが同じものかどうか判断する

en: the object's hash value (for equality checking)
ja: オブジェクトのハッシュ値(イコールかチェック用)

en: this object does not turn into an array
ja: このオブジェクトは配列にはできない

en: Accesses a custom attribute on the object
ja: オブジェクト上のカスタム属性にアクセスする

en: tag|param|key
ja: key

en: the custom attribute or nil if not found.
ja: カスタム属性や見つからなかった場合はnilを返す

en: the name of the custom attribute
ja: カスタム属性の名前

en: Sets a custom attribute on the object
ja: オブジェクトにカスタム属性を設定する

en: the value to associate
ja: 関連する値

en: tag|overload|dynamic_attr_name
ja: dynamic_attr_name

en: tag|overload|dynamic_attr_name=
ja: dynamic_attr_name=

en: Attaches source code to a code object with an optional file location
ja: 任意のファイルの場所と共にコードオブジェクトの為にソースコードを追加する。

en: tag|param|statement
ja: statement

en: the +Parser::Statement+ holding the source code or the raw source
    as a +String+ for the definition of the code object only (not the block)
ja: +Parser::Statement+ はソースコードや
    コードオブジェクトだけの定義用に(blockではない)
     +String+ のような未加工のソースを保持する。

en: Attaches a docstring to a code object by parsing the comments attached to the statement
    and filling the {#tags} and {#docstring} methods with the parsed information.
ja: ステートメントに添付されたコメントを解析する事によって、
    コードオブジェクトにdocstringを追加する。
    そして、解析された情報と共に、{#tags}や{#docstring}メソッドを埋め込む。

en: tag|param|comments
ja: comments

en: the comments attached to the code object to be parsed
    into a docstring and meta tags.
ja: docstringとメタタグの中を解析する為に、コードオブジェクトに追加される,コメント

en: Default type is the lowercase class name without the "Object" suffix.
    Override this method to provide a custom object type
ja: デフォルトの型は"Object"サフィックスなしの小文字のクラス名となる。
    このメソッドを上書きする為にカスタムオブジェクト型を提供する。

en: the type of code object this represents
ja: これを表すコードオブジェクトの型

en: Represents the unique path of the object. The default implementation
    joins the path of {#namespace} with {#name} via the value of {#sep}.
    Custom code objects should ensure that the path is unique to the code
    object by either overriding {#sep} or this method.
ja: オブジェクトの固有のパスを表す。
    デフォルトの実装は、{#sep}の値を挟んで{#namespace} と {#name}のパスを加えた、
    実装となる。
    カスタムコードオブジェクトは、{#sep}メソッドやこのメソッドによって
    固有のパスが確保されるべきである。

en: tag|example|The path of an instance method
ja: インスタンスメソッドのパス

en: the unique path of the object
ja: オブジェクトの固有のパス

en: another code object (or object path)
ja: 他のコードオブジェクト(又は、オブジェクトのパス)

en: the shortest relative path from this object to +other+
ja: このオブジェクトから +other+ への最短の相対パス

en: Renders the object using the {Templates::Engine templating system}.
ja: {Templates::Engine templating system}によってオブジェクトを表示する。

en: a set of options to pass to the template
ja: テンプレートに渡すoptionのグループ

en: tag|example|Formats a class in plaintext
ja: プレーンテキストでクラスを書式化する

en: tag|example|Formats a method in html with rdoc markup
ja: rdocマークアップと共に、htmlで、メソッドを書式化する

en: the rendered template
ja: テンプレートを表示する。

en: Inspects the object, returning the type and path
ja: オブジェクトを検査し、型とパスを返す。

en: a string describing the object
ja: オブジェクトを説明する文字列

en: Sets the namespace the object is defined in.
ja: 中で定義されるオブジェクトのnamespaceを設定する。

en: tag|param|obj
ja: obj

en: the new namespace (:root
    for {Registry.root}). If obj is nil, the object is unregistered
    from the Registry.
ja: 新しいnamespace({Registry.root}用の:root)
    objがnilの場合、記録されたオブジェクトはレジストリから戻される。

en: Gets a tag from the {#docstring}
ja: {#docstring}メソッドから、取得する。

en: Gets a list of tags from the {#docstring}
ja: {#docstring}メソッドから、タグのリストを取得する。

en: Tests if the {#docstring} has a tag
ja: {#docstring}メソッドがタグを持つ場合、テストする。

en: whether or not this object is a RootObject
ja: このオブジェクトがRootObjectかどうか

en: Override this method with a custom component separator. For instance,
    {MethodObject} implements sep as '#' or '.' (depending on if the
    method is instance or class respectively). {#path} depends on this
    value to generate the full path in the form: namespace.path + sep + name
ja: このメソッドは、区切りのカスタム構成を上書きする。
    例えば、{MethodObject}は'#'や'.'のような区切りを実装する。
    (メソッドのインスタンスやクラスの関係に依存している)
    {#path}メソッドは namespace.path + sep + name の形式で、
    フルパスを生成する為、この値に依存している。

en: the component that separates the namespace path
    and the name (default is {NSEP})
ja: namespace path と name で区切る構成となる。(デフォルトは{NSEP})

en: Formats source code by removing leading indentation
ja: インデントを読み込み削除する事によってソースコードを書式化する

en: formatted source
ja: 書式化されたソース

en: tag|param|source
ja: source

en: the source code to format
ja: 書式化するソースコード

en: A ClassObject represents a Ruby class in source code. It is a {ModuleObject}
    with extra inheritance semantics through the superclass.
ja: クラスオブジェクトはソースコードの中のRubyクラスを意味する。
    それは、スーパークラスを介した特別な継承の意味を持つ {ModuleObject} となる。

en: The {ClassObject} that this class object inherits from in Ruby source.
ja: このクラスオブジェクトがRubyのソースから継承する{ClassObject}

en: a class object that is the superclass of this one
ja: このクラスオブジェクトのスーパークラスとなるクラスオブジェクトを返す

en: Creates a new class object in +namespace+ with +name+
ja: +name+ と共に +namespace+ の中で新しいクラスオブジェクトを作成する。

en: a new instance of ClassObject
ja: クラスオブジェクトの新しいインスタンス

en: Whether or not the class is a Ruby Exception
ja: Ruby Exceptionクラスかどうか

en: whether the object represents a Ruby exception
ja: Ruby exceptionクラスを表すオブジェクトかどうか

en: Returns the inheritance tree of the object including self.
ja: 自身を含んでいるオブジェクトの継承ツリーを返す

en: tag|param|include_mods
ja: include_mods

en: the list of code objects that make up
    the inheritance tree.
ja: 継承ツリーを作り上げるコードオブジェクトのリスト

en: whether or not to include mixins in the
    inheritance tree.
ja: 継承ツリーの中でmixinを含んでいるかどうか

en: Returns the list of methods matching the options hash. Returns
    all methods if hash is empty.
ja: ハッシュのオプションにマッチするメソッドのリストを返す。
    (ハッシュが空の場合は、全てのメソッド)

en: tag|option|opts
ja: opts

en: the list of methods that matched
ja: マッチしたメソッドのリスト

en: the options hash to match
ja: マッチするハッシュのオプション

en: Returns only the methods that were inherited.
ja: 継承したメソッドだけを返す

en: the list of inherited method objects
ja: メソッドオブジェクトを継承したリスト

en: Returns the list of constants matching the options hash.
ja: ハッシュのオプションにマッチする定数のリストを返す

en: the list of constant that matched
ja: マッチした定数のリスト

en: Returns only the constants that were inherited.
ja: 継承された定数だけ返す

en: the list of inherited constant objects
ja: 定数オブジェクトを継承したリスト

en: Sets the superclass of the object
ja: オブジェクトのスーパークラスをグループ化する。

en: the superclass value
ja: スーパークラスの値

en: Represents a class variable inside a namespace. The path is expressed
    in the form "A::B::@@classvariable"
ja: namespaceの内部でクラス変数を表す。
    パスは、"A::B::@@クラス変数"形式で表される。

en: the class variable's value
ja: クラス変数の値

en: A +ConstantObject+ represents a Ruby constant (not a module or class).
    To access the constant's (source code) value, use {#value}.
ja: +ConstantObject+ は、Ruby定数を表す。(モジュールやクラスではない)
    定数(ソースコード)の値にアクセスする為には、{#value}メソッドを利用する。

en: The source code representing the constant's value
ja: 定数の値を表しているソースコード

en: the value the constant is set to
ja: 定数を設定される値

en: Represents an instance method of a module that was mixed into the class
    scope of another namespace.
ja: 他のnamespaceのクラススコープの中へ混ぜられたモジュールのインスタンスメソッドを表す。

en: always +:class+
ja: 常に +:class+

en: Sets up a delegate for {MethodObject} obj.
ja: {MethodObject}オブジェクト用に委譲をセットアップする

en: a new instance of ExtendedMethodObject
ja: ExtendedMethodObjectの新しいインスタンス

en: the instance method to treat as a mixed in
    class method on another namespace.
ja: 別のnamespace上でクラスメソッドを混ぜたような処理をする,インスタンスメソッド

en: Sends all methods to the {MethodObject} assigned in {#initialize}
ja: {MethodObject}が{#initialize}メソッドを割り当てる事によって、
    全てのメソッドを__send__する。

en: An ExtraFileObject represents an extra documentation file (README or other
    file). It is not strictly a CodeObject (does not inherit from `Base`) although
    it implements `path`, `name` and `type`, and therefore should be structurally
    compatible with most CodeObject interfaces.
ja: ExtraFileObjectは、追加のドキュメントファイル(README や 他のファイル)を表すけれど、
    コードオブジェクトに限らず(`Base`から継承はできない)`path`, `name` , `type`を実装できる。
    従って、殆どのCodeObjectインターフェースと互換性があり、構造上両立されるべきである。

en: the value to set the attribute filename to.
ja: filename属性を設定する値

en: Returns the value of attribute filename
ja: filename属性の値を返す

en: Sets the attribute filename
ja: filename属性を設定する

en: the value to set the attribute attributes to.
ja: attributesの属性を設定する値

en: Returns the value of attribute attributes
ja: attributes属性の値を返す

en: Sets the attribute attributes
ja: attributes属性を設定する

en: the value to set the attribute name to.
ja: name属性を設定する値

en: Returns the value of attribute name
ja: name属性の値を返す

en: Sets the attribute name
ja: name属性を設定する

en: the value to set the attribute contents to.
ja: 値に属性の内容を設定するための値

en: Returns the value of attribute contents
ja: 属性の内容の値を返す

en: Sets the attribute contents
ja: 属性の内容を設定する

en: Creates a new extra file object.
ja: 新しく追加のファイルオブジェクトを作成する

en: a new instance of ExtraFileObject
ja: ExtraFileObjectの新しいインスタンス

en: tag|param|contents
ja: contents

en: tag|param|filename
ja: filename

en: the file contents. If not set, the contents
    will be read from disk using the +filename+.
ja: ファイルの内容となる。設定しない場合、
    contentsは、 +filename+ によってディスクから読み込まれるだろう。

en: the location on disk of the file
ja: ファイルのディスク上の場所

en: the file contents
ja: ファイルの内容

en: A MacroObject represents a docstring defined through +@!macro NAME+ and can be
    reused by specifying the tag +@!macro NAME+. You can also provide the
    +attached+ type flag to the macro definition to have it attached to the
    specific DSL method so it will be implicitly reused.
ja: マクロオブジェクトは、+@!macro NAME+ を通じて定義した docstring を表し、
    +@!macro NAME+ タグを指定する事によって、再利用できる。
    あなたは、固有のDSLメソッドに加えるマクロ定義の為に
    +attached+ 型フラグを提供もできる。
    なので、暗黙の内に再利用される。

en: Macros are fully described in the {file:docs/Tags.md#macro Tags Overview}
    document.
ja: マクロは、{file:docs/Tags.md#macros Tags Overview}ドキュメントで詳細に説明されている。

en: tag|example|Creating a basic named macro
ja: 一般的なマクロを作成

en: tag|example|Creating a macro that is attached to the method call
ja: メソッド呼び出しの為に加えられるマクロを作成する。

en: Creates a new macro and fills in the relevant properties.
ja: 関連したプロパティのファイルと新しいマクロを作成する。

en: an object to attach this
    macro to. If supplied, {#attached?} will be true
ja: このマクロに加えるオブジェクト。もし提供された場合、
    {#attached?}はtrueになる。

en: tag|param|macro_name
ja: macro_name

en: tag|param|method_object
ja: method_object

en: the data the macro should expand when re-used
ja: 再利用された時、マクロが展開するであろうデータ

en: the name of the macro, must be unique.
ja: マクロの名前、固有のものにしなければならない

en: Finds a macro using +macro_name+
ja: +macro_name+ のマクロを見つける

en: if a macro is found
ja: マクロが見つかった場合

en: if there is no registered macro by that name
ja: マクロの名前が記録されない場合

en: the name of the macro
ja: マクロの名前

en: Parses a given docstring and determines if the macro is "new" or
    not. If the macro has $variable names or if it has a @!macro tag
    with the [new] or [attached] flag, it is considered new.
ja: 与えらたdocstringを解析しマクロが新しく作成されるものかどうか決める。
    もしマクロが$variable名を持っていた場合や
    [new]や[attached]フラグと一緒に@!macroタグを持っていた場合、
    新規に作成されるものとみなされる。

en: If a new macro is found, the macro is created and registered. Otherwise
    the macro name is searched and returned. If a macro is not found,
    nil is returned.
ja: 新しいマクロが見つかった場合、作成され記録される。
    その他の場合、マクロ名が検索され返される。
    マクロが見つからなかった場合は、nilが返される。

en: an optional method to attach
    the macro to. Only used if the macro is being created, otherwise
    this argument is ignored.
ja: マクロを加える為の任意のメソッド
    マクロが作成される場合、利用されるだけである。
    さもなければ、この引数は無視される。

en: if the +data+ has no macro tag or if the macro is
    not new and no macro by the macro name is found.
ja: +data+ がマクロタグを持っていないか、
    マクロが、"new"でなかったり、
    macro name is foundによって、マクロ自体が無い場合、nilを返す。

en: the newly created or existing macro, depending
    on whether the @!macro tag was a new tag or not.
ja: 新たに作成された、又は、既存のマクロを返す。
    @!macroタグはnewタグかそうでないかに依存する。

en: Expands +macro_data+ using the interpolation parameters.
ja: 補完の引数によって、 +macro_data+ を展開する。

en: Interpolation rules:
    * $0, $1, $2, ... = the Nth parameter in +call_params+
    * $* = the full statement source (excluding block)
    * Also supports $!{N-M} ranges, as well as negative indexes on N or M
    * Use \$ to escape the variable name in a macro.
ja: 補完のルール:
    * $0, $1, $2, ... = +call_params+ の中のN番目の引数
    * $* = 完全なステートメントのソース(blockを除外する)
    * $!{N-M}の範囲もサポートし,マイナスのインデックスも利用できる
    * マクロの中の変数名のエスケープには\$を使う

en: tag|param|macro_data
ja: マクロデータ

en: the macro data to expand (taken from {#macro_data})
ja: 拡張する為のマクロデータ({#macro_data}メソッドから取得する)

en: Applies a macro on a docstring by creating any macro data inside of
    the docstring first. Equivalent to calling {find_or_create} and {apply_macro}
    on the new macro object.
ja: 最初にdocstringの内部の何らかのマクロデータを作成する事によって
    docstring上のマクロを適用する。
    {find_or_create}と、
    新しいマクロオブジェクト上で{apply_macro}を呼び出すのは同様である。

en: tag|param|docstring
ja: docstring

en: the docstring to create a macro out of
ja: マクロの出力を作成する為のdocstrng

en: Applies a macro to a docstring, interpolating the macro's data on the
    docstring and appending any extra local docstring data that was in
    the original +docstring+ object.
ja: docstringにmacroが適用され、
    docstring上のマクロデータを補完する。
    そして、元の +docstring+ オブジェクトの中の
    任意で加えられるローカルなdocstringのデータを適用する。

en: tag|param|macro
ja: macro

en: the macro object
ja: マクロオブジェクト

en: the macro data stored on the object
ja: マクロ上で記録されるデータ

en: the method object that this macro is
    attached to.
ja: このマクロが追加されるメソッドオブジェクト

en: whether this macro is attached to a method
ja: このマクロがメソッドに加えられるかどうか

en: Expands the macro using
ja: マクロによって展開される

en: a list of tokens that are passed
    to the method call
ja: メソッド呼び出しに渡されるトークンのリスト

en: tag|example|Expanding a Macro
ja: マクロを展開する

en: tag|param|block_source
ja: block_source

en: tag|param|call_params
ja: call_params

en: tag|param|full_source
ja: full_source

en: the full method call (not including the block)
ja: 全てのメソッド呼び出し(blockを含んでいない)

en: the source passed in the block of the method
    call, if there is a block.
ja: ブロックがある場合、メソッド呼び出しのブロックの中で解析されたソース。

en: Represents a Ruby method in source
ja: ソースの中のRubyメソッドを表す。

en: The scope of the method (+:class+ or +:instance+)
ja: メソッドのスコープ( +:class+ や +:instance+ )

en: the scope
ja: スコープ

en: Whether the object is explicitly defined in source or whether it was
    inferred by a handler. For instance, attribute methods are generally
    inferred and therefore not explicitly defined in source.
ja: オブジェクトがソースの中で明確に定義されるかどうかや、
    それがハンドラーによって推察されたかどうか。
    例えば、大抵メソッドの属性は推察されるが、
    ソースの中で明確に定義されない場合、マーカーはどこも示せない。

en: whether the object is explicitly defined in source.
ja: オブジェクトがソースの中で明確に定義されたかどうか

en: Returns the list of parameters parsed out of the method signature
    with their default values.
ja: メソッドの用法のデフォルトの値と共に、その出力の解析された引数のリストを返す。

en: a list of parameter names followed
    by their default values (or nil)
ja: 引数名のデフォルトの値をフォローする(又は、nil)

en: Creates a new method object in +namespace+ with +name+ and an instance
    or class +scope+
ja: +name+ とインスタンスや +scope+ クラスと共に、
    +namespace+の中で新しいメソッドオブジェクトを作成する。

en: +:instance+, +:class+, or +:module+
ja: +:instance+ や +:class+ や +:module+

en: a new instance of MethodObject
ja: メソッドオブジェクトの新しいインスタンス

en: the method name
ja: メソッド名

en: the namespace
ja: namespace

en: Changes the scope of an object from :instance or :class
ja: :instanceや:classからオブジェクトのスコープを変更する。

en: tag|param|v
ja: v

en: the new scope
ja: 新しいスコープ

en: whether or not the method is the #initialize constructor method
ja: メソッドが#initialize,コンストラクタメソッドかどうか

en: whether or not this method was created as a module
    function
ja: このメソッドがモジュール関数として作成されたかどうか

en: Returns the read/writer info for the attribute if it is one
ja: 属性がひとつだけの場合、読み/書きする為の情報を返す。

en: if the method is not an attribute
ja: メソッドが属性で無い場合

en: if there is information about the attribute
ja: 属性についての情報がある場合

en: whether the method is a writer attribute
ja: メソッドがwriter属性かどうか

en: whether the method is a reader attribute
ja: メソッドがreader属性かどうか

en: Tests if the object is defined as an attribute in the namespace
ja: オブジェクトがnamespaceの中でその属性を定義される場合、テストする。

en: whether the object is an attribute
ja: オブジェクトが属性かどうか

en: Tests if the object is defined as an alias of another method
ja: オブジェクトが別のメソッドがそのエイリアスに定義される場合、テストする。

en: whether the object is an alias
ja: オブジェクトがエイリアスかどうか

en: Tests boolean {#explicit} value.
ja: ブールの{#explicit}メソッドの値をテストする。

en: whether the method is explicitly defined in source
ja: メソッドがソースの中で明確に定義されるかどうか

en: if it does not override a method
ja: メソッドが上書きされない場合

en: the object that this method overrides
ja: このメソッドが上書きするオブジェクト

en: Returns all alias names of the object
ja: オブジェクトの全てのエイリアスの名前を返す

en: the alias names
ja: エイリアスの名前

en: Override path handling for instance methods in the root namespace
    (they should still have a separator as a prefix).
ja: root namespaseの中のインスタンスメソッド用に操作するパスを上書きする。
    (root namespaseはプレフィックスとして区切りが必要である)

en: the path of a method
ja: メソッドのパス

en: Returns the name of the object.
ja: オブジェクトの名前を返す

en: returns {#sep} + +name+ for an instance method if
    prefix is true
ja: プレフィックスがtrueの場合、インスタンスメソッド用に{#sep} + +name+ を返す

en: tag|example|The name of a class method (with prefix)
ja: クラスメソッドの名前(プレフィックスを用いる)

en: tag|example|The name of an instance method (with prefix)
ja: インスタンスメソッドの名前(プレフィックスを用いる)

en: the name without {#sep} if prefix is set to false
ja: プレフィックスにfalseを設定する場合、{#sep}メソッド無しの名前となる。

en: whether or not to show the prefix
ja: プレフィックスを見せるかどうか

en: Override separator to differentiate between class and instance
    methods.
ja: インスタンスメソッドとクラスの間で区別する為に区切りを上書きする。

en: "#" for an instance method, "." for class
ja: インスタンスメソッド用の"#"、クラス用の"."。

en: Represents a Ruby module.
ja: Rubyモジュールを表す。

en: Returns the inheritance tree of mixins.
ja: mixinの継承ツリーを返す

en: a list of namespace objects
ja: オブジェクトのnamespaceのリスト

en: if true, will include mixed in
    modules (which is likely what is wanted).
ja: trueの場合、mixinされるモジュールを含んでいる(それが何ができそうであるか)

en: A "namespace" is any object that can store other objects within itself.
    The two main Ruby objects that can act as namespaces are modules
    ({ModuleObject}) and classes ({ClassObject}).
ja: namespaceはそれ自身の中で他のオブジェクトを記録できる任意のオブジェクトとなる。
    namespaceがモジュール({ModuleObject})とクラス({ClassObject})のように振る舞えるオブジェクトとなる。

en: the value to set the attribute child to.
ja: child属性を設定する値

en: the value to set the attribute constants to.
ja: 属性の定数を設定する値

en: the value to set the attribute cvars to.
ja: cvars(クラス変数)の属性を設定する値

en: the value to set the attribute meths to.
ja: meths(メソッド)属性を設定する値

en: the value to set the attribute mixins to.
ja: mixinの属性を設定する値

en: Sets the attribute child
ja: child属性を設定する

en: Sets the attribute constants
ja: 定数の属性を設定する

en: Sets the attribute cvars
ja: cvarsの属性を設定する

en: Sets the attribute meths
ja: meths属性を設定する

en: Sets the attribute mixins
ja: mixinの属性を設定する

en: the value to set the attribute class_attributes to.
ja: class_attributes属性を設定する値

en: the value to set the attribute instance_attributes to.
ja: instance_attributes属性を設定する値

en: Sets the attribute class_attributes
ja: class_attributes属性を設定する

en: Sets the attribute instance_attributes
ja: instance_attributes属性を設定する

en: the value to set the attribute included_constants to.
ja: included_constants属性を設定する値

en: the value to set the attribute included_meths to.
ja: included_meths属性を設定する値

en: Sets the attribute included_constants
ja: included_constants属性を設定する

en: Sets the attribute included_meths
ja: included_meths属性を設定する

en: a list of ordered group names inside the namespace
ja: namespace内部の名前のグループへの命令の入ったリスト

en: The list of objects defined in this namespace
ja: このnamespaceの中で定義されたオブジェクトのリスト

en: a list of objects
ja: オブジェクトのリスト

en: A hash containing two keys, class and instance, each containing
    the attribute name with a { :read, :write } hash for the read and
    write objects respectively.
ja: ハッシュはクラスとインスタンスの二つのキーを含んでいる,
    読み書きオブジェクトそれぞれ{:read, :write}ハッシュと共に
    属性の名前をそれぞれ含んでいる。

en: a list of methods
ja: メソッドのリスト

en: tag|example|The attributes of an object
ja: オブジェクトの属性

en: A hash containing two keys, :class and :instance, each containing
    a hash of objects and their alias names.
ja: 二つのキーを含んでいるハッシュで,クラスとインスタンスはそれぞれ、
    オブジェクトのハッシュと、そのエイリアスの名前を含んでいる。

en: Class mixins
ja: mixinのクラス

en: a list of mixins
ja: mixinのリスト

en: Instance mixins
ja: mixinのインスタンス

en: Creates a new namespace object inside +namespace+ with +name+.
ja: +name+ と共に、 +namespace+ の内部で新しいnamespaceオブジェクトを作成する。

en: a new instance of NamespaceObject
ja: NamespaceObjectの新しいインスタンス

en: Only the class attributes
ja: クラス属性だけ

en: a list of method names and their read/write objects
ja: メソッド名のリストとそれを読み/書きするオブジェクト

en: Only the instance attributes
ja: インスタンス属性だけ

en: Looks for a child that matches the attributes specified by +opts+.
ja: +opts+に指定された属性にマッチする子を検索する

en: tag|example|Finds a child by name and scope
ja: 名前とスコープの子を検索する

en: the first matched child object, or nil
ja: 最初にマッチした子のオブジェクト、又はnil

en: Returns all methods that match the attributes specified by +opts+. If
    no options are provided, returns all methods.
ja: +opts+に指定された属性にマッチする全てのメソッドを返す。
    optionが提供されない場合は、全てのメソッドを返す。

en: a customizable set of options
ja: カスタマイズ可能なオプションのグループ

en: a list of method objects
ja: オブジェクトのメソッドのリスト

en: tag|example|Finds all private and protected class methods
ja: 全てのprivateとクラスメソッドのprotectedを検索する

en: Returns methods included from any mixins that match the attributes
    specified by +opts+. If no options are specified, returns all included
    methods.
ja: +opts+で指定された属性にマッチする任意のmixinから含んでいるメソッドを返す
    オプションが指定されない場合、全ての含んでいるメソッドを返すmethods.

en: Returns all constants in the namespace
ja: namespaceの中の全ての定数を返す

en: a list of constant objects
ja: 定数オブジェクトのリスト

en: Returns constants included from any mixins
ja: 任意のmixinから、含んでいる定数を返す

en: Returns class variables defined in this namespace.
ja: このnamespaseの中で定義されたクラス変数を返す

en: a list of class variable objects
ja: オブジェクトのクラス変数のリスト

en: Returns for specific scopes. If no scopes are provided, returns all mixins.
ja: 固有のスコープを返す。スコープが提供されない場合、全てのmixinを返す

en: a list of scopes (:class, :instance) to
    return mixins for. If this is empty, all scopes will be returned.
ja: mixinを返す為のスコープのリスト(:class, :instance).
    これが空の場合、全てのスコープが、返されるだろう。

en: tag|param|scopes
ja: scopes

en: A special type of +NoMethodError+ when raised from a {Proxy}
ja: {Proxy}から、例外が上げられる時の、+NoMethodError+の特別な型

en: The Proxy class is a way to lazily resolve code objects in
    cases where the object may not yet exist. A proxy simply stores
    an unresolved path until a method is called on the object, at which
    point it does a lookup using {Registry.resolve}. If the object is
    not found, a warning is raised and {ProxyMethodError} might be raised.
ja: Proxyクラスは、オブジェクトがまだ存在しないかもしれないケースで、
    コードオブジェクトを簡単に解決する為の方法である。
    単純にproxyは、メソッドが解決されなかったパスを記録し、
    オブジェクト上で呼び出され{Registry.resolve}によって検索する。
    オブジェクトが見つからない場合、警告がでたり、{ProxyMethodError}が出るかもしれない。

en: tag|example|Creates a Proxy to the String class from a module
ja: モジュールからStringクラスの為のProxyを作成する

en: Returns the value of attribute namespace
ja: namespaxe属性の値を返す

en: Creates a new Proxy
ja: 新しいProxyを返す

en: if namespace is not a NamespaceObject
ja: namespaceがNamespaceObjectでない場合

en: Returns a text representation of the Proxy
ja: Proxyのテキスト表現を返す

en: the object's #inspect method or P(OBJECTPATH)
ja: #inspectメソッドやP(OBJECTPATH)のオブジェクト

en: If the proxy resolves to an object, returns its path, otherwise
    guesses at the correct path using the original namespace and name.
ja: proxyがオブジェクトを解決する場合、パスを返す。
    他の場合、
    元のnamespaceとnameによって正しいパスを推測する

en: the assumed path of the proxy (or the real path
    of the resolved object)
ja: proxyのパスを装う(又は、解決したオブジェクトの実際のパス)

en: Returns the class name of the object the proxy is mimicking, if
    resolved. Otherwise returns +Proxy+.
ja: 解決した場合、proxyが模倣するオブジェクトのクラス名を返す。
    他の場合、+Proxy+を返す。

en: the resolved object's class or +Proxy+
ja: 解決したオブジェクトのクラスや +Proxy+

en: Returns the type of the proxy. If it cannot be resolved at the
    time of the call, it will either return the inferred proxy type
    (see {#type=}) or +:proxy+
ja: proxyの型を返す。呼び出される時間で解決できない場合、
    予想されるproxyの型(see {#type=})や +:proxy+ を返す。

en: the Proxy's type
ja: Proxyの型

en: Allows a parser to infer the type of the proxy by its path.
ja: パスによってproxyの型を推測する為に、パーサーを受け入れる。

en: tag|param|type
ja: type

en: the proxy's inferred type
ja: 推察されたproxyの型

en: Dispatches the method to the resolved object.
ja: 解決したオブジェクトにメソッドを送る

en: if the proxy cannot find the real object
ja: proxyが実際のオブジェクトを見つけられない場合

en: This class is never a root object
ja: このクラスrootオブジェクトにはならない

en: this method fixes a bug in 1.9.2: http://gist.github.com/437136
ja: このメソッドはバグを修正する。
    (in 1.9.2: http://gist.github.com/4371369)

en: Attempts to find the object that this unresolved object
    references by checking if any objects by this name are
    registered all the way up the namespace tree.
ja: この名前によって任意のオブジェクトが
    namespaceツリーの変更を記録する場合、
    これがチェックするオブジェクトの参照が
    未解決だったオブジェクトを見つける為に試みる。

en: the registered code object or nil
ja: 記録されるコードオブジェクト、又は、nil

en: Represents the root namespace object (the invisible Ruby module that
    holds all top level modules, class and other objects).
ja: root namespaceオブジェクトを表す(全てのtop levelのモジュール,クラス,他のオブジェクトを把握する隠れたRubyモジュール)

en: This class maintains all system-wide configuration for YARD and handles
    the loading of plugins. To access options call {options}, and to load
    a plugin use {load_plugin}. All other public methods are used by YARD
    during load time.
ja: このクラスは
    YARDとプラグインのロードを操作するシステム全体の設定を維持する。
    設定を呼び出す{options}にアクセスする為や、
    プラグインを使う{load_plugin}をロードする事を目的に、
    全ての他のpublicなメソッドが、
    ロード中にYARDによって利用される。

en: == User Configuration Files
ja: == ユーザー設定ファイル

en: Persistent user configuration files can be stored in the file
    +~/.yard/config+, which is read when YARD first loads. The file should
    be formatted as YAML, and should contain a map of keys and values.
ja: persistent(長く使った)ユーザーの設定ファイルは、+~/.yard/config+ ファイルの中に記録される。
    そして、YARDが最初にロードする時に、読み出される。
    このファイルはYAMLのように書式化される、
    そして、キーや値のマップを含んでいるはずである。

en: Although you can specify any key-value mapping in the configuration file,
    YARD defines special keys specified in {DEFAULT_CONFIG_OPTIONS}.
ja: あなたは、設定ファイルの中に任意のキーや値のマッピングを指定できるけれども、
    YARDは{DEFAULT_CONFIG_OPTIONS}の中の規定の特別なキーを定義する。

en: An example of a configuration file is listed below:
ja: 設定ファイルの例は次のよう記述される。

en: == Automatic Loading of Plugins
ja: == プラグインの自動ロード

en: YARD 0.6.2 will no longer automatically load all plugins by default. This
    option can be reset by setting 'load_plugins' to true in the configuration
    file. In addition, you can specify a set of specific plugins to load on
    load through the 'autoload_plugins' list setting. This setting is
    independent of the 'load_plugins' value and will always be processed.
ja: YARD 0.6.2からは、デフォルトで全てのプラグインを自動ロードしない。
    この設定は、設定ファイルの中の'load_plugins'をtrueに設定する事によってリセットできる。
    さらに、あなたは、
    'autoload_plugins'リストのセッティングを通して、
    ロード毎に特定のプラグインの設定を指定できる。
    特定のプラグインのグループを指定できる。
    この設定は、'load_plugins'の独自の値となり、そして常に処理されるだろう。

en: == Ignored Plugins File
ja: == プラグインファイルを無視する

en: YARD 0.5 and below used a +~/.yard/ignored_plugins+ file to specify
    plugins to be ignored at load time. Ignored plugins in 0.6.2 and above
    should now be specified in the main configuration file, though YARD
    will support the +ignored_plugins+ file until 0.7.x.
ja: YARD 0.5やそれ以下では、
    ロード時間で無視されるプラグインを指定する為に
    +~/.yard/ignored_plugins+ ファイルを利用した。
    0.6.2以上で無視されるプラグインは、
    現在、主に設定ファイルの中で規定されるはずである。
    とはいえ,YARDは +ignored_pluginis+ ファイルを0.7.xまで、サポートする。

en: == Safe Mode
ja: == セーフモード

en: YARD supports running in safe-mode. By doing this, it will avoid executing
    any user code such as require files or queries. Plugins will still be
    loaded with safe mode on, because plugins are properly namespaced with
    a 'yard-' prefix, must be installed as a gem, and therefore cannot be
    touched by the user. To specify safe mode, use the +safe_mode+ key.
ja: YARDはセーフモードでの起動をサポートする。
    これを行うことにより、requireファイルやクエリーのような
    任意のユーザーコードの実行を無効にする。
    しかし、プラグインはセーフモードの実行と共にロードされる。
    何故なら、プラグインは、'yard-'プレフィックスと共に、
    適切にnamespaceが設定され,
    gemのようにインストールされるはずである,
    そして、これ自身の設定はユーザーによって変更できない。
    セーフモードを指定するには、 +safe_mode+ キーを利用する。

en: == Plugin Specific Configuration
ja: == プラグインの詳細な設定

en: Additional settings can be defined within the configuration file
    specifically to provide configuration for a plugin. A plugin that utilizes
    the YARD configuration is strongly encouraged to utilize namespacing of
    their configuration content.
ja: 追加の設定は
    プラグイン用の設定を提供する為に、
    明確に設定ファイルの中で
    定義される。
    YARDの設定を利用するプラグインは、
    その設定内容のnamespaceを利用する為に
    強力に後押しされる。

en: As the configuration is available system wide, it can be
    accessed within the plugin code.
ja: この設定はシステム全体に及び、
    プラグインのコードの中で、アクセスできる。

en: When accessing the configuration, be aware that this file is user managed
    so configuration keys and values may not be present. Make no assumptions and
    instead ensure that you check for the existence of keys before proceeding to
    retrieve values.
ja: 設定にアクセスする時、
    このファイルはユーザーが扱う事に注意する。
    なので、キーや値の設定は見つからないかもしれない。
    勝手に作成しない代わりに、
    あなたが値を取り出す手続きをする前にキーの存在の管理する事を保証する。

en: The system-wide configuration options for YARD
ja: YARD用のシステム全体の設定オプション

en: a map a key-value pair settings.
ja: キー,値のペア設定のマップ

en: The location where YARD stores user-specific settings
ja: YARDがユーザー固有の設定を記録する場所

en: The main configuration YAML file.
ja: YAMLファイルの主な設定

en: File listing all ignored plugins
ja: ファイルに記述する、無視されるプラグイン

en: Set `ignored_plugins` in the {CONFIG_FILE} instead.
ja: {CONFIG_FILE}の代わりに、`ignored_plugins`を設定する。

en: Default configuration options
ja: デフォルトの設定オプション

en: The prefix used for YARD plugins. Name your gem with this prefix
    to allow it to be used as a plugin.
ja: プレフィックスは、YARDプラグイン用に利用される。
    あなたのgemがプラグインの様に利用される為に、
    このプレフィックスと共に名付ける。

en: Loads settings from {CONFIG_FILE}. This method is called by YARD at
    load time and should not be called by the user.
ja: {CONFIG_FILE}からの設定をロードする。
    これメソッドは、ロード時間でYARDによって呼び出される。
    そして、ユーザーによって呼び出されないはずである。

en: Saves settings to {CONFIG_FILE}.
ja: {CONFIG_FILE}の為の設定を保存する。

en: true if all plugins loaded successfully, false otherwise.
ja: 全てのプラグインが正しくロードした場合、true、そうでなければ、false

en: Loads an individual plugin by name. It is not necessary to include the
    +yard-+ plugin prefix here.
ja: 名前によって、個々のプラグインをロードする。
    ここで +yard-+ プラグインのプレフィックスを含む必要は無い。

en: the name of the plugin (with or without +yard-+ prefix)
ja: プラグインの名前( +yard-+ プレフィックスの有無にかかわらず)

en: whether the plugin was successfully loaded
ja: プラグインがロードに成功したかどうか

en: Load gem plugins if :load_plugins is true
ja: :load_pluginsがtrueの場合、gemプラグインをロードする

en: Load plugins set in :autoload_plugins
ja: :autoload_pluginsの中のグループのプラグインをロードする。

en: Load plugins from {#arguments}
ja: (#arguments)メソッドからプラグインをロードする。

en: Print a warning if the plugin failed to load
ja: ロードに失敗したプラグインの場合、警告をプリントする。

en: Legacy support for {IGNORED_PLUGINS}
ja: {IGNORED_PLUGINS}用のレガシーサポート

en: Translates plugin names to add yard- prefix.
ja: yard-プレフィックスを追加する為にプラグイン名を翻訳する。

en: Loads the YAML configuration file into memory
ja: メモリの中にYAML設定ファイルをロードする。

en: the contents of the YAML file from disk
ja: ディスクからのYAMLファイルの内容

en: Sanitizes and normalizes a plugin name to include the 'yard-' prefix.
ja: 'yard-'プレフィックスを含んでいるプラグイン名を正規化する。

en: the plugin name
ja: プラグイン名

en: the sanitized and normalized plugin name.
ja: 正規化されるプラグイン名

en: Temporarily loads .yardopts file into @yardopts
ja: @yardoptsの中に、.yardoptsファイルを一時的にロードする。

en: arguments from commandline and yardopts file
ja: コマンドラインやyardoptsファイルからの引数

en: Places values before or after another object (by value) in
    an array. This is used in tandem with the before and after
    methods of the {Insertion} class.
ja: 配列の前後に他のオブジェクト(値として)の値を置く
    これは、前後に{Insertion}クラスのメソッドを用いている。

en: an insertion object to
ja: 挿入されたオブジェクト

en: tag|example|Places an item after another
ja: 後ろに別の要素を置く

en: tag|example|Places an item before another
ja: 前に別の要素を置く

en: tag|param|values
ja: values

en: value to insert
ja: 挿入する値

en: Turns a path +to+ into a relative path from starting
    point +from+. The argument +from+ is assumed to be
    a filename. To treat it as a directory, make sure it
    ends in +File::SEPARATOR+ ('/' on UNIX filesystems).
ja: +from+ で始まる場所から、相対パスの情報へパスを変える。
    +from+ の引数は、ファイル名になるように処理される。
    ディレクトリとして取得するには、 +File::SEPARATOR+ で終わる必要がある。
    (UNIX上のファイルシステムなら、'/')

en: Manipulating Paths
ja: パスを操作する

en: tag|param|from
ja: from

en: tag|param|to
ja: to

en: the final path that should be made relative.
ja: 対応して作られる最後のパス

en: the relative path from +from+ to +to+.
ja: +from+ から +to+ への相対パス

en: the starting filename
    (or directory with +from_isdir+ set to +true+).
ja: ファイル名(又は +from_isdir+ を +true+ を設定した場合はディレクトリ)の文字列

en: Cleans a path by removing extraneous '..', '.' and '/' characters
ja: 無関係の '..', '.', '/' 文字を削除し、パスをきれいにする。

en: tag|example|Clean a path
ja: pathをきれいにする

en: tag|param|path
ja: path

en: the path to clean
ja: きれいにするパス

en: the sanitized path
ja: きれいにされたパス

en: Forces opening a file (for writing) by first creating the file's directory
ja: 最初にファイルのディレクトリを作成する事によって、開くファイル(書込み用)を強制する。

en: Reading Files
ja: ファイルを読み込む

en: the filename to open
ja: 展開するファイル名

en: Reads a file with binary encoding
ja: バイナリコードにしてファイルを読み込む

en: the ascii-8bit encoded data
ja: ascii-8bitにエンコードされたデータ

en: The Insertion class inserts a value before or after another
    value in a list.
ja: Insertionクラスはリストの中の前後に他の値を挿入する。

en: Creates an insertion object on a list with a value to be
    inserted. To finalize the insertion, call {#before} or
    {#after} on the object.
ja: 挿入される値と共にリスト上のinsertionオブジェクトを作成する。
    最終的にinsertionは、オブジェクト上の{#before}や{#after}メソッドを呼び出す。

en: a new instance of Insertion
ja: Insertionの新しいインスタンス

en: tag|param|list
ja: list

en: the list to perform the insertion on
ja: insertionで実行するリスト

en: the value to insert
ja: 挿入する値

en: Inserts the value before +val+
ja: +val+ の前に値を挿入する

en: look inside sublists
ja: ネストした配列の内部をみるかどうか

en: tag|param|recursive
ja: recursive

en: tag|param|val
ja: val

en: the object the value will be inserted before
ja: 値が前に挿入される,オブジェクト

en: Inserts the value after +val+.
ja: +val+ の前に値を挿入する

en: tag|example|If subsections are ignored
ja: ネストした配列が無視される場合

en: the object the value will be inserted after
ja: 値が前に挿入される,オブジェクト

en: Alias for {#before} with +recursive+ set to true
ja: +recursive+ にtrueを設定する{#before}メソッド用のエイリアス

en: Alias for {#after} with +recursive+ set to true
ja: +recursive+ にtrueを設定する{#after}メソッド用のエイリアス

en: This method performs the actual insertion
ja: このメソッドが、実際にinsertionを実行する。

en: tag|param|rel
ja: rel

en: the list to place objects into
ja: オブジェクトの情報を置く為のリスト

en: the relative index (0 or 1) of where the object
    should be placed
ja: オブジェクトが置かれる所の相対インデックス(0又は1)

en: Returns the class name of a full module namespace path
ja: モジュールの完全なnamespaceパスのクラス名を返す

en: the last part of a module path
ja: モジュールパスの最後の部分

en: the namespace minus the class/module name
ja: クラス/モジュール名を引いたnamespace

en: Splits text into tokens the way a shell would, handling quoted
    text as a single token. Use '\"' and "\'" to escape quotes and
    '\\' to escape a backslash.
ja: シェルの場合テキスト情報のトークンを分割し、
    単一のトークンとしてクオートされたテキストを操作する。
    エスケープをクオートするには、'\"'と"\'"、
    バックスラッシュをエスケープするには'\\'を使う。

en: an array representing the tokens
ja: トークンを表す配列

en: A subclass of Hash where all keys are converted into Symbols, and
    optionally, all String values are converted into Symbols.
ja: 全てのキーがSymbolsに変換される所のハッシュのサブクラス、
    自由に全てのStringの値をSymblosに変換できる。

en: Creates a new SymbolHash object
ja: 新しいSymbolHashオブジェクトを作成する

en: a new instance of SymbolHash
ja: SymbolHashの新しいインスタンス

en: converts any String values into Symbols
    if this is set to +true+.
ja: この設定がtrueの場合、
    全てのStringの値をSymbolへ変換する。

en: tag|param|symbolize_value
ja: symbolize_value

en: Assigns a value to a symbolized key
ja: シンボル化されたキーに値を割り当てる

en: the key
ja: キー

en: the value to be assigned. If this is a String and
    values are set to be symbolized, it will be converted into a Symbol.
ja: 割り当てられる値。
    これが、文字列の場合には、値がシンボル化される為に設定され、
    シンボルへ変換されるだろう。

en: Accessed a symbolized key
ja: シンボル化されるキーにアクセスされる

en: the key to access
ja: アクセスする為のキー

en: the value associated with the key
ja: キーに関連付けられた値

en: Deleted a key and value associated with it
ja: 関連付けられたキーと値が削除される

en: the key to delete
ja: 削除するキー

en: Tests if a symbolized key exists
ja: シンボル化されたキーがあるかテストする

en: the key to test
ja: テストするキー

en: whether the key exists
ja: キーが存在するかどうか

en: Updates the object with the contents of another Hash object.
    This method modifies the original SymbolHash object
ja: 他のハッシュオブジェクトの内容と共にオブジェクトを更新する。
    このメソッドは元のSymbolHashオブジェクトを変更する。

en: the hash object to copy the values from
ja: ハッシュオブジェクトから値をコピーする,ハッシュ

en: Merges the contents of another hash into a new SymbolHash object
ja: 新しいSymbolHashオブジェクトへ他のハッシュの内容をマージする。

en: a new SymbolHash containing the merged data
ja: マージされたデータを含んでいる新しいSymbolHash

en: the hash of objects to copy
ja: コピーするオブジェクトのハッシュ

en: A documentation string, or "docstring" for short, encapsulates the
    comments and metadata, or "tags", of an object. Meta-data is expressed
    in the form +@tag VALUE+, where VALUE can span over multiple lines as
    long as they are indented. The following +@example+ tag shows how tags
    can be indented:
ja: documentation stringを略して"docstring"は、
    コメントやメタデータ,オブジェクトのタグをカプセル化する。
    メタデータは +@tag VALUE+ から
    VALUEがインデントされる間の複数行に渡って表される。
    次の +@example+ タグは
    タグがどのようにインデントされるか表す。

en: Tags can be nested in a documentation string, though the {Tags::Tag}
    itself is responsible for parsing the inner tags.
ja: タグはドキュメント文字列の中でネストされ、{Tags::Tag}自身は、
    中のタグを解析する責任がある。

en: the parser object used to parse a
    docstring.
ja: docstringを解析する為に利用したパーサーオブジェクト。

en: the list of reference tags
ja: 参照タグのリスト

en: the object that owns the docstring.
ja: docstring自身のオブジェクト

en: line range in the {#object}'s file where the docstring was parsed from
ja: 解析されるdocstringの{#object}ファイルの中のline range

en: the raw documentation (including raw tag text)
ja: 未加工のドキュメント(未加工のタグテキストを含んでいる)

en: whether the docstring was started with "##"
ja: docstringが"##"と共に記録される

en: Matches a tag at the start of a comment line
ja: コメント行の始まりでタグにマッチする。

en: Creating a Docstring Object
ja: Docstringオブジェクトを作成する

en: the list of tag objects in the docstring
ja: docstringの中のタグオブジェクトのリスト

en: the object associated with the
    docstring. May be nil.
ja: docstringと共に関連したオブジェクト, nilになるかもしれない。

en: the textual portion of the docstring
ja: docstringの原文の一部

en: Creates a new docstring with the raw contents attached to an optional
    object. Parsing will be done by the {DocstringParser} class.
ja: 任意のオブジェクトに追加された未加工のコンテンツを用い新しいdocstringを作成する。
    解析は {DocstringParser} クラスによって完了する。

en: a new instance of Docstring
ja: Docstringの新しいインスタンス

en: an object to associate the docstring
    with.
ja: docstringと関連するオブジェクト

en: tag|param|content
ja: 内容

en: the raw comments to be parsed into a docstring
    and associated meta-data.
ja: docstring,関連するメタデータの中で解析される未加工の内容,

en: Adds another {Docstring}, copying over tags.
ja: 別の{Docstring}を追加し、タグをコピーする。

en: a new docstring with both docstrings combines
ja: docstring化し,一体化(別のdocstringと)した、新しいdocstring

en: the other docstring (or string) to
    add.
ja: 他の追加するdocstring(やstring)

en: Replaces the docstring with new raw content. Called by {#all=}.
ja: {#all=}メソッドが呼ばれる事によって、新しい整形前の内容にdocstringを置換する。

en: the raw comments to be parsed
ja: 解析される未加工のコメント

en: Deep-copies a docstring
ja: docstringを深い階層までコピーする。

en: This method creates a new docstring with new tag lists, but does
    not create new individual tags. Modifying the tag objects will still
    affect the original tags.
ja: このメソッドは新しいタグリストと共に新しいdocstringを作成する。
    しかし、新しい個々のタグは作成できない。
    タグオブジェクトを変更すると、元のタグに影響するだろう。

en: a new copied docstring
ja: 新しくコピーされたdocstring

en: if there is no associated {#line_range}
ja: {#line_range}メソッドに関係ない場合

en: the first line of the {#line_range}
ja: {#line_range}メソッドの最初の行

en: Gets the first line of a docstring to the period or the first paragraph.
ja: ピリオドや最初の段落の為に、
    docstringの最初の行を取得する。

en: The first line or paragraph of the docstring; always ends with a period.
ja: docstringの最初の行や段落、そして常にperiodと共に終わる。

en: Reformats and returns a raw representation of the tag data using the
    current tag and docstring data, not the original text.
ja: 再書式化し返す、
    現在のタグやdocstringデータによって
    未加工のタグデータで表される。
    しかし元のテキストではない。

en: Add Tags::Tag#to_raw and refactor
ja: Tags::Tag#to_rawメソッドや再編集を追加する

en: the updated raw formatted docstring data
ja: 更新され書式化される未加工のdocstringのデータ

en: Adds a tag or reftag object to the tag list. If you want to parse
    tag data based on the {Tags::DefaultFactory} tag factory, use
    {DocstringParser} instead.
ja: タグのリストにタグや参照タグオブジェクトを追加する。
    あなたが、 {Tags::DefaultFactory} タグファクトリーを元にしたタグデータを解析したい場合
    代わりに {DocstringParser} を使う。

en: Creating and Accessing Meta-data
ja: メタデータを作成しアクセスする。

en: list of tag objects to add
ja: 追加のタグオブジェクトのリスト

en: Convenience method to return the first tag
    object in the list of tag objects of that name
ja: タグオブジェクトのリストのような名前の中の、
    最初のタグオブジェクトを返す為の便利なメソッド。

en: the first tag in the list of {#tags}
ja: {#tags}メソッドのリストの中の、最初のタグ

en: the tag name to return data for
ja: データを返す為のタグ名

en: Returns a list of tags specified by +name+ or all tags if +name+ is not specified.
ja: +name+ が指定されない場合、
    +name+ やallタグによって指定されたタグのリストを返す

en: the list of tags by the specified tag name
ja: 指定されたタグ名によってタグのリストとなる。

en: the tag name to return data for, or nil for all tags
ja: データからタグ名を返す、又は、nilの場合、全てのタグ。

en: Returns true if at least one tag by the name +name+ was declared
ja: 宣言されるnameのタグ名が1つでもあれば、trueを返す。

en: the tag name to search for
ja: 検索の為のタグ名

en: whether or not the tag +name+ was declared
ja: タグ +name+が宣言されるかどうか

en: Delete all tags with +name+
ja: 全てのタグ +name+ を用いた削除する。

en: the tag name
ja: タグ名

en: Deletes all tags where the block returns true
ja: ブロックがtrueを返す所で全てのタグを削除する。

en: tag|yieldparam|tag
ja: tag

en: the tag that is being tested
ja: 試されるタグ

en: true if the tag should be deleted
ja: タグが削除される場合、true

en: Returns true if the docstring has no content that is visible to a template.
ja: docstringがテンプレートの為、明確な内容を持たない場合、trueを返す。

en: tag|param|only_visible_tags
ja: only_visible_tags

en: whether only {Tags::Library.visible_tags}
    should be checked, or if all tags should be considered.
ja: {Tags::Library.visible_tags}が、チェックされるかどうか、
    又は、全てのタグが考慮される場合

en: whether or not the docstring has content
ja: docstringが内容を持っているかどうか

en: Maps valid reference tags
ja: 有効な参照タグをマップする

en: the list of valid reference tags
ja: 有効な参照タグのリストを返す

en: Parses out comments split by newlines into a new code object
ja: 新しいコードオブジェクトの中の改行によって分割されるコメントを解析する

en: the newline delimited array of comments. If the comments
    are passed as a String, they will be split by newlines.
ja: コメントの配列を改行で区切る。
    コメントが文字列の様に解析される場合、改行によって分割される。

en: the non-metadata portion of the comments to
    be used as a docstring
ja: docstringのように利用される為のコメントのメタデータではない部分

en: tag|example|Creating a Custom DocstringParser
ja: tag|example|カスタムDocstringParserを作成する

en: tag|example|Creating a Docstring with a DocstringParser
ja: tag|example|DocstringParserを用いDocstringを作成する

en: the parsed text portion of the docstring,
    with tags removed.
ja: 解析されたdocstringのテキストの一部,  削除されたタグと一緒

en: the complete input string to the parser.
ja: パーサーの為の完全な入力文字列

en: the list of meta-data tags identified
    by the parser
ja: パーサーに認証されたメタデータタグのリスト

en: The regular expression to match the tag syntax
ja: タグ構文にマッチする為の正規表現

en: Creates a new parser to parse docstring data
ja: docstringのデータを解析する為の新しいパーサーを作成する

en: Creation and Conversion Methods
ja: 作成、変換メソッド

en: a new instance of DocstringParser
ja: DocstringParserの新しいインスタンス

en: translates parsed text into
    a Docstring object.
ja: Docstringオブジェクトへ解析されたテキストを変換する

en: Parsing Methods
ja: 解析メソッド

en: the docstring text to parse
ja: 解析の為のdocstringのテキスト

en: Parses a given block of text.
ja: テキストの与えられたブロックを解析する

en: Subclasses can override this method to perform custom
    parsing of content data.
ja: サブクラスは内容のデータのカスタム解析を実行する為に
    このメソッドを上書きできる

en: the content to parse
ja: 解析する為の内容

en: Creates a tag from the {Tags::DefaultFactory tag factory}.
ja: {Tags::DefaultFactory tag factory}から、タグを作成する。

en: To add an already created tag object, append it to {#tags}.
ja: 既に作成されたタグオブジェクトを追加するには、{#tags}メソッドを追加する。

en: Tag Manipulation Methods
ja: タグ操作メソッド

en: a tag
ja: タグ

en: tag|param|tag_buf
ja: tag_buf

en: tag|param|tag_name
ja: tag_name

en: the text attached to the tag with newlines removed.
ja: 空白文字が削除されたタグを追加したテキスト

en: Creates a {Tags::RefTag}
ja: {Tags::RefTag}を作成する

en: Creates a new directive using the registered {#library}
ja: 記録された{#library}メソッドを使って新しい命令を作成する

en: the directive object that is created
ja: 作成される命令オブジェクト

en: Parser Callback Methods
ja: パーサーコールバックメソッド

en: a block to be called after a docstring is parsed
ja: docstringが解析された後で呼び出されるためのブロック

en: tag|yieldparam|parser
ja: parser

en: Global Convenience Methods
ja: グローバルな便利メソッド

en: Raised during processing phase when a handler needs to perform
    an operation on an object's namespace but the namespace could
    not be resolved.
ja: ハンドラーがnamespaceオブジェクトの演算を実行する必要がある時、
    処理している間に例外を上げる。しかし、namespaceは解決されない。

en: The object the error occurred on
ja: エラーが生じたコードオブジェクトを返す。

en: a code object
ja: コードオブジェクト

en: a new instance of NamespaceMissingError
ja: NamespaceMissingErrorの新しいインスタンス

en: Handlers are pluggable semantic parsers for YARD's code generation
    phase. They allow developers to control what information gets
    generated by YARD, giving them the ability to, for instance, document
    any Ruby DSLs that a customized framework may use. A good example
    of this would be the ability to document and generate meta data for
    the 'describe' declaration of the RSpec testing framework by simply
    adding a handler for such a keyword. Similarly, any Ruby API that
    takes advantage of class level declarations could add these to the
    documentation in a very explicit format by treating them as first-
    class objects in any outputted documentation.
ja: ハンドラーは、YARDがコード生成段階で、
    プラグイン可能という意味のパーサーである。
    ハンドラーは、YARDによって生成される情報や、
    その情報に機能を与える為や、
    例えば、利用するかもしれない
    カスタマイズされたフレームワークの何らかのRuby DSLを記述すること等を
    制御する為に開発者を受け入れる。
    いい例は、キーワードのような単純なハンドラーの追加によって、
    RSpec testing フレームワークの'describe'宣言のように、
    ドキュメント作成やメタデータを生成する機能である。
    同様に、クラスレベル宣言から利用する何らかのRubyAPIは、
    出力されたドキュメントで、
    最初のクラスオブジェクトとしてそれらを処理することによって、
    明確な書式でドキュメントにこれらを追加できた。

en: == Overview of a Typical Handler Scenario
ja: == 標準的なハンドラーの処理概要

en: Generally, a handler class will declare a set of statements which
    it will handle using the {handles} class declaration. It will then
    implement the {#process} method to do the work. The processing would
    usually involve the manipulation of the {#namespace}, {#owner}
    {CodeObjects::Base code objects} or the creation of new ones, in
    which case they should be registered by {#register}, a method that
    sets some basic attributes for the new objects.
ja: 一般的に、ハンドラークラスはステートメントのグループを宣言する。
    そして、それは {handles} クラス宣言によって処理する。
    それは、処理の為に {#process} メソッドを実装する。
    処理中は、通常 {#namespace} , {#owner} , {CodeObjects::Base code objects} や
    新規作成を含む場合に、それらは、 {#register} によって登録されるべき、
    メソッドは新しいオブジェクト用にいくつかの基本的属性を設定する。

en: Handlers are usually simple and take up to a page of code to process
    and register a new object or add new attributes to the current +namespace+.
ja: ハンドラーは一般的にシンプルで、処理の為にコードのページを取り上げ、
    新しいオブジェクトを登録し、現在の +namespace+ に新しい属性を追加する。

en: == Setting up a Handler for Use
ja: == ハンドラーを使う為の設定

en: A Handler is automatically registered when it is subclassed from the
    base class. The only other thing that needs to be done is to specify
    which statement the handler will process. This is done with the +handles+
    declaration, taking either a {Parser::Ruby::Legacy::RubyToken}, {String} or `Regexp`.
    Here is a simple example which processes module statements.
ja: ハンドラーはベースクラスからサブクラス化される時に、
    自動的に登録される。
    必要なその他のこととしては、
    ハンドラーがどのステートメントを処理するかを指定する。
    これは、 +handles+ の宣言と共に、
    {Parser::Ruby::Legacy::RubyToken} か {String} や `Regexp`が取得される。
    これは、モジュールステートメントの処理の簡単な例です。

en: == Processing Handler Data
ja: == ハンドラーデータ処理

en: The goal of a specific handler is really up to the developer, and as
    such there is no real guideline on how to process the data. However,
    it is important to know where the data is coming from to be able to use
    it.
ja: 具体的なハンドラーの使い方は、開発者次第となる。
    データ処理の方法のガイドラインは何もない。
    しかしながら、データを扱う為には、
    そのデータがどこから来るか知る事が重要となる。

en: === +statement+ Attribute
ja: === +statement+ 属性

en: The +statement+ attribute pertains to the {Parser::Ruby::Legacy::Statement} object
    containing a set of tokens parsed in by the parser. This is the main set
    of data to be analyzed and processed. The comments attached to the statement
    can be accessed by the {Parser::Ruby::Legacy::Statement#comments} method, but generally
    the data to be processed will live in the +tokens+ attribute. This list
    can be converted to a +String+ using +#to_s+ to parse the data with
    regular expressions (or other text processing mechanisms), if needed.
ja: パーサーによって解析されたトークンの設定を
    {Parser::Ruby::Legacy::Statement} オブジェクトが含んでいる為、
    +statement+ 属性は関係がある。
    これは解析や処理される為のデータの主な設定となる。
    コメントはstatementが {Parser::Ruby::Legacy::Statement#comments} メソッドによってアクセスされる為に付加される、
    しかし、処理される一般的なデータは +tokens+ 属性の中に存在する。
    必要であれば、このリストは、正規表現(又は、他のテキストが処理しているメカニズム)を用い、データを解析する為に+#to_s+メソッドによって +String+ に変換される。

en: === +namespace+ Attribute
ja: === +namespace+ 属性

en: The +namespace+ attribute is a {CodeObjects::NamespaceObject namespace object}
    which represents the current namespace that the parser is in. For instance:
ja: +namespace+ 属性は {CodeObjects::NamespaceObject namespace object} となる。
    それは、そのパーサーの中では現在のnamespaceを表す。
    例えば:

en: If a handler was to parse the 'class MyClass' statement, it would
    be necessary to know that it belonged inside the SomeModule module.
    This is the value that +namespace+ would return when processing such
    a statement. If the class was then entered and another handler was
    called on the method, the +namespace+ would be set to the 'MyClass'
    code object.
ja: ハンドラー処理が'class MyClass'ステートメントを解析する場合、
    class My ClassがSomeModuleモジュールの内部に
    属していることを知ることが必須になる。
    ステートメントのような処理(class MyClassを解析)をしている時、
    SomeModuleが +namespace+ 値となり返されるだろう。
    もしMyClassがエントリーされたり、
    他のハンドラーがメソッド上で呼び出された場合、
    'MyClass'コードオブジェクトが +namespace+ に設定される。

en: === +owner+ Attribute
ja: === +owner+ 属性

en: The +owner+ attribute is similar to the +namespace+ attribute in that
    it also follows the scope of the code during parsing. However, a namespace
    object is loosely defined as a module or class and YARD has the ability
    to parse beyond module and class blocks (inside methods, for instance),
    so the +owner+ attribute would not be limited to modules and classes.
ja: +owner+ 属性は +namespace+ 属性と似ているが、
    解析中のコードのスコープをフォローもする。
    しかしながら、namespace オブジェクトは
    モジュールやクラスのように曖昧に定義される。
    その為、YARDはモジュールやクラスブロック(例えば、内部メソッド)を
    越えて解析する為の機能を持つ。
    なので、この +owner+ 属性は、モジュールやクラスに制限されない。

en: To put this into context, the example from above will be used. If a method
    handler was added to the mix and decided to parse inside the method body,
    the +owner+ would be set to the method object but the namespace would remain
    set to the class. This would allow the developer to process any method
    definitions set inside a method (def x; def y; 2 end end) by adding them
    to the correct namespace (the class, not the method).
ja: この文脈の中では、上の例が使われる。
    ハンドラーのメソッドは、組み合わせる為に追加されたり、
    メソッド本体の内部を解析する場合、
    +owner+ はメソッドオブジェクトを設定する。
    しかし、namespaceはクラスに設定されたままとなる。
    これは開発者に以下のことを可能とする。全てのメソッド定義は、
    正しいnamespaceを追加する事によって(クラスの,メソッドでは無い)、
    メソッドの内部(def x; def y; 2 end end)のグループを処理する。

en: In summary, the distinction between +namespace+ and +owner+ can be thought
    of as the difference between first-class Ruby objects (namespaces) and
    second-class Ruby objects (methods).
ja: 要約すると、+namespace+ と +owner+ の違いは、
    ネストするクラスで考えると、:ownerは
    最初のクラスのRubyオブジェクトでは(namespace)となるが、
    次のネストしたクラスのRubyオブジェクトでは前のクラスのnamespaceとなる。

en: === +visibility+ and +scope+ Attributes
ja: === +visibility+ と +scope+ 属性

en: Mainly needed for parsing methods, the +visibility+ and +scope+ attributes
    refer to the public/protected/private and class/instance values (respectively)
    of the current parsing position.
ja: 大抵は解析されるメソッドの為に必要とされる、
    +visibility+ と +scope+ 属性は現在の解析している場所の
    public/protected/privateとclass/instanceの値(それぞれについて)を
    参照する。

en: == Parsing Blocks in Statements
ja: == ステートメントの中のブロックを解析する

en: In addition to parsing a statement and creating new objects, some
    handlers may wish to continue parsing the code inside the statement's
    block (if there is one). In this context, a block means the inside
    of any statement, be it class definition, module definition, if
    statement or classic 'Ruby block'.
ja: ステートメントの解析や新しくオブジェクトを作成する事に加えて、
    いくつかのハンドラーはステートメントのブロック(が一つでもある場合)の
    内部コードの解析処理を継続するかもしれない。
    このコンテキストでブロックとは、何らかのステートメントの内部を意味する。
    それはステートメントやRubyで使われるblockの場合、クラス定義、モジュール定義になる。

en: For example, a class statement would be "class MyClass" and the block
    would be a list of statements including the method definitions inside
    the class. For a class handler, the programmer would execute the
    {#parse_block} method to continue parsing code inside the block, with
    the +namespace+ now pointing to the class object the handler created.
ja: 例えば、ステートメントのクラスが"class MyClass"になるかもしれない
    そして、ブロックはクラスの内部でメソッドの定義を
    含んでいるステートメントのリストになるかもしれない。
    ハンドラーのクラス用に、
    プログラマーは、{#parse_block} メソッドを実行する。
    ブロックの内部のコード解析を継続する為に、
    +namespace+ は、現在、ハンドラーが作成したクラスオブジェクトを指定する。

en: YARD has the ability to continue into any block: class, module, method,
    even if statements. For this reason, the block parsing method must be
    invoked explicitly out of efficiency sake.
ja: YARDは何らかのブロックの中へ(クラス,モジュール,メソッド,ステートメントでさえ)
    継続する特性がある。
    従って、メソッドを解析するブロックは、
    効率良く処理する為、明示的に呼び出されるべきである。

en: Subclass this class to provide a handler for YARD to use
    during the processing phase.
ja: YARDが処理段階で使用するハンドラーを提供する為に、
    このクラスをサブクラス化する。

en: Clear all registered subclasses. Testing purposes only
ja: 全ての登録されたサブクラスを消去する。テスト用

en: Returns all registered handler subclasses.
ja: 全ての登録されたサブクラスのハンドラーを返す。

en: a list of handlers
ja: ハンドラーのリスト

en: Declares the statement type which will be processed
    by this handler.
ja: このハンドラーによって処理されるステートメントの型を宣言する。

en: A match need not be unique to a handler. Multiple
    handlers can process the same statement. However,
    in this case, care should be taken to make sure that
    {#parse_block} would only be executed by one of
    the handlers, otherwise the same code will be parsed
    multiple times and slow YARD down.
ja: ハンドラーでマッチするものは、一つでなくてもよい。
    複数のハンドラーは同じステートメントを処理できる。
    しかしながら、このケースの場合は、
    {#parse_block}がハンドラーの一つによって実行されるだけで、
    他の同じコードが複数回解析されYARDが遅くなる事に注意しなければならない。

en: statements that match the declaration will be
    processed by this handler. A {String} match is
    equivalent to a +/\Astring/+ regular expression
    (match from the beginning of the line), and all
    token matches match only the first token of the
    statement.
ja: このハンドラーによって処理される宣言がマッチするステートメント。
    A {String} のマッチは +/\Astring/+ の正規表現と同様となる。
    (行の最初からマッチ)、
    そして全てのトークンのマッチは、ステートメントの最初のトークンにだけマッチする。

en: This class is implemented by {Ruby::Base} and {Ruby::Legacy::Base}.
    To implement a base handler class for another language, implement
    this method to return true if the handler should process the given
    statement object. Use {handlers} to enumerate the matchers declared
    for the handler class.
ja: このクラスは、 {Ruby::Base} や {Ruby::Legacy::Base} によって実装される。
    他の言語用のbase handlerクラスを実装する為には、
    ハンドラーが与えられたステートメントオブジェクトを処理する場合、
    trueを返す為にこのメソッドを実装する。
    ハンドラークラス用のマッチする宣言を列挙するには、{handlers} を使用する。

en: a statement object or node (depends on language type)
ja: オブジェクトやノードのステートメント(言語タイプに左右される)

en: whether or not this handler object should process
    the given statement
ja: いずれにせよ、このハンドラーオブジェクトは指定されたステートメントを処理するべき

en: a list of matchers for the handler object.
ja: ハンドラーオブジェクト用の照合されるリスト

en: Declares that the handler should only be called when inside a
    {CodeObjects::NamespaceObject}, not a method body.
ja: ハンドラーが {CodeObjects::NamespaceObject} 内部の時だけ
    呼び出される事を宣言する、このメソッドは本体ではない。

en: whether the handler should only be processed inside
    a namespace.
ja: このハンドラがnamespace内だけで処理されるかどうか

en: Declares that a handler should only be called when inside a filename
    by its basename or a regex match for the full path.
ja: ハンドラーがフルパス用のベースネームや正規表現マッチによって、
    ファイルネーム内部の時だけ呼び出される事を宣言する。

en: a matching filename or regex
ja: マッチするファイルネームや正規表現

en: whether the filename matches the declared file
    match for a handler. If no file match is specified, returns true.
ja: ファイル名が宣言されたハンドラー用のファイルとマッチするかどうか、
    ファイルがマッチしない場合は、trueを返す。

en: Generates a +process+ method, equivalent to +def process; ... end+.
    Blocks defined with this syntax will be wrapped inside an anonymous
    module so that the handler class can be extended with mixins that
    override the +process+ method without alias chaining.
ja: +process+ メソッドを生成する、 +def process; ...end+ と同等となる。
    この構文を用いた定義されるブロックは、無名モジュールの内部でラップされる。
    理由としては、ハンドラークラスが +procecc+ メソッドの上書きを
    エイリアスチェーン無しでmixinを用い拡張できるようにする為である。

en: a new instance of Base
ja: ベースの新しいインスタンス

en: The main handler method called by the parser on a statement
    that matches the {handles} declaration.
ja: 主なハンドラーのメソッドは {handles} の宣言で
    マッチするstatementのパーサーによって呼び出される。

en: Subclasses should override this method to provide the handling
    functionality for the class.
ja: サブクラスはクラス用の処理機能を提供する為に、
    このメソッドを上書きする。

en: If this method returns a code object (or a list of them),
    they are passed to the +#register+ method which adds basic
    attributes. It is not necessary to return any objects and in
    some cases you may want to explicitly avoid the returning of
    any objects for post-processing by the register method.
ja: このメソッドがコードオブジェクト(やそれらのリスト)を返す場合、
    それらは、+#register+ メソッドに解析され、基本属性が追加される。
    何らかのオブジェクトを返すのは必須ではなく、
    場合によっては、
    あなたはregisterメソッドによって後処理用の
    何らかのオブジェクトを返すことを明確に無視できる。

en: Parses the semantic "block" contained in the statement node.
ja: ステートメントノードに含まれている意味のある"block"を解析する。

en: Subclasses should call {Processor#process parser.process}
ja: {Processor#process parser.process} を呼び出しサブクラス化する。

en: the processor object that manages all global state
    during handling.
ja: 全てのグローバルな状態の処理の間に扱うプロセッサーオブジェクト

en: the statement object currently being processed. Usually
    refers to one semantic language statement, though the strict definition
    depends on the parser used.
ja: 現在の処理されるステートメントオブジェクト。
    厳格な定義は使われるパーサー次第とはいえ、
    一般的には、一つの意味のある言語を参照する。

en: the value to set the attribute owner to.
ja: owner属性を設定する為の値

en: Returns the value of attribute owner
ja: owner属性の値を返す

en: Sets the attribute owner
ja: owner属性を設定する

en: the value to set the attribute namespace to.
ja: 値にnamespace属性を設定するための値

en: Sets the attribute namespace
ja: namespace属性を設定する

en: the value to set the attribute visibility to.
ja: 値にvisibility属性を設定するための値

en: Returns the value of attribute visibility
ja: visibility属性の値を返す

en: Sets the attribute visibility
ja: visibility属性を設定する。

en: the value to set the attribute scope to.
ja: 値にスコープ属性を設定するための値

en: Returns the value of attribute scope
ja: スコープ属性の値を返す

en: Sets the attribute scope
ja: スコープ属性を設定する

en: Returns the value of attribute globals
ja: globals(全体)属性の値を返す

en: Returns the value of attribute extra_state
ja: extra_state属性の値を返す

en: Executes a given block with specific state values for {#owner},
    {#namespace} and {#scope}.
ja: {#owner}, {#namespace} , {#scope}メソッド用の特定の状態値と
    一緒に与えられたブロックを実行する。

en: a block to execute with the given state values.
ja: 状態を指定すると共に実行するブロック。

en: the block to execute with specific state
ja: 与えられた値の状態と共に実行するブロック。

en: Do some post processing on a list of code objects.
    Adds basic attributes to the list of objects like
    the filename, line number, {CodeObjects::Base#dynamic},
    source code and {CodeObjects::Base#docstring},
    but only if they don't exist.
ja: コードオブジェクトのリストのいくつかの後処理をする。
    ファイル名、行数、{CodeObjects::Base#dynamic} 、ソースコード、
    {CodeObjects::Base#docstring}のようなオブジェクトのリストに、
    基本属性を追加する。
    しかし、それらが存在しない場合だけである。

en: returns whatever is passed in, for chainability.
ja: メソッドチェーンの為、解析されるものを返す

en: the list of objects to post-process.
ja: 後処理の為のオブジェクトのリスト

en: the object to register
ja: 記録するオブジェクト

en: Registers the file/line of the declaration with the object
ja: オブジェクトを用い宣言のファイル/行を登録する

en: Registers any docstring found for the object and expands macros
ja: オブジェクト用に見つかった任意のdocstringを登録し、マクロを拡張する

en: Registers the object as being inside a specific group
ja: 特定のグループ内部のものとしてオブジェクトを登録する

en: Registers any transitive tags from the namespace on the object
ja: オブジェクト上のnamespaceから全てのtransitiveタグを登録する

en: the visibility to set on the object
ja: オブジェクトを設定するためのvisibility

en: Ensures that a specific +object+ has been parsed and loaded into the
    registry. This is necessary when adding data to a namespace, for instance,
    since the namespace may not have been processed yet (it can be located
    in a file that has not been handled).
ja: 特定の +object+ は解析されて、レジストリの中へロードされる事を保証する。
    例えば、namespaceは、まだ処理されないかもしれないので
    (処理されないファイルの中にそれはある可能性がある。)
    これはnamespaceにデータを追加する時に必要である。

en: Calling this method defers the handler until all other files have been
    processed. If the object gets resolved, the rest of the handler continues,
    otherwise an exception is raised.
ja: このメソッドの呼び出しは
    他の全てのファイルが処理されるまでハンドラーを延期する。
    もしオブジェクトが解決された場合、ハンドラーの残りが続き、
    さもなければ、例外を上げる。

en: if the object is not resolved within
    +max_retries+ attempts, this exception is raised and the handler
    finishes processing.
ja: オブジェクトが +max_retries+ を試みても解決されない場合、
    この例外を上げ、ハンドラーが処理を終了させる。

en: tag|example|Adding a mixin to the String class programmatically
ja: Stringクラスのプログラムにmixinを追加する

en: the number of times to defer the handler
    before raising a +NamespaceMissingError+.
ja: +NamespaceMissingError+ を上げる前にハンドラーがリトライする回数

en: the object to resolve.
ja: 解決したいオブジェクト

en: Implement this method to return the parameters in a method call
    statement. It should return an empty list if the statement is not a
    method call.
ja: メソッド呼び出しステートメントの中のパラメータを返す為にこのメソッドを実装する。
    ステートメントがメソッド呼び出しでない場合は空のリストを返すべき。

en: Macro Support
ja: マクロのサポート

en: a list of argument names
ja: 引数の名前のリスト

en: Implement this method to return the method being called in
    a method call. It should return nil if the statement is not a method
    call.
ja: メソッド呼び出しの中で呼び出されるメソッドが返す為に
    このメソッドが実装する。
    ステートメントがメソッド呼び出しでない場合はnilを返すべき。

en: if the statement is not a method call
ja: ステートメントがメソッド呼び出しでない場合

en: the method name being called
ja: 呼び出されるメソッド名

en: whether the handler handles this statement
ja: ハンドラーがこのステートメントを操作するかどうか

en: Registering objects
ja: オブジェクトを登録する

en: Parsing an Inner Block
ja: 内部のブロックを解析する

en: Processing other files
ja: 他のファイルを処理する

en: Handles the Init_Libname() method
ja: Init_Libname()メソッドを操作する

en: Parses comments
ja: コメントを解析する

en: Iterates over all statements in a file and delegates them to the
    {Handlers::Base} objects that are registered to handle the statement.
ja: ファイルの中の全てのステートメントにまたがり繰り返し、
    ステートメントを操作する為に記録される{Handlers::Base}オブジェクトに委譲する。

en: This class is passed to each handler and keeps overall processing state.
    For example, if the {#visibility} is set in a handler, all following
    statements will have access to this state. This allows "public",
    "protected" and "private" statements to be handled in classes and modules.
    In addition, the {#namespace} can be set during parsing to control
    where objects are being created from. You can also access extra stateful
    properties that any handler can set during the duration of the post
    processing of a file from {#extra_state}. If you need to access state
    across different files, look at {#globals}.
ja: このクラスはそれぞれのハンドラーが渡される。
    そして、総合的な処理の状態を維持する。
    例えば、{#visibility}はハンドラーの中で設定される。
    全ての次のステートメントは、この状態にアクセス可能である。
    これは、クラスやモジュールの中で操作される
    "public","protected","private"ステートメントを受け入れる。
    さらに、{#namespace}メソッドは、
    オブジェクトが作成される場所で、制御の為に解析している間に設定される。
    あなたは、追加の処理状態を把握する属性にアクセスも出来る。
    任意のハンドラーが
    {#extra_state}メソッドからファイルの後処理をしている間に
    設定できる。
    あなたが複数のファイルに渡って状態にアクセスする必要がある場合、
    {#globals}メソッドで調べられる。

en: Registers a new namespace for handlers of the given type.
ja: 与える型の入ったハンドラー用の記録する。

en: a list of registered parser type extensions
ja: parser type extensionsが,記録されるリスト

en: the filename
ja: ファイル名

en: the current namespace
ja: 現在のnamespace

en: the current visibility (public, private, protected)
ja: 現在の可視性(public,private,protected)

en: the current scope (class, instance)
ja: 現在のスコープ(クラス,インスタンス)

en: unlike the namespace, the owner
    is a non-namespace object that should be stored between statements.
    For instance, when parsing a method body, the {CodeObjects::MethodObject}
    is set as the owner, in case any extra method information is processed.
ja: namespaceとは異なり、ownerは、
    ステートメントの間に記録されるnamespaceオブジェクトを持たない。
    例えば、メソッド本体を解析する時、{CodeObjects::MethodObject}は、
    このownerのように設定される。この場合、何らかの追加のメソッド情報が処理される。

en: the parser type (:ruby, :ruby18, :c)
ja: パーサー型(:ruby, :ruby18, :c)

en: Handlers can share state for the entire post processing stage through
    this attribute. Note that post processing stage spans multiple files.
    To share state only within a single file, use {#extra_state}
ja: ハンドラーはこの属性を通して全体の後処理環境用の状態を共有できる。
    以下の事に留意する。
    後処理の状態は、複数ファイルに渡す。
    単一のファイルの中でだけ状態を共有するには、 {#extra_state} を使用する。

en: global shared state for post-processing stage
ja: 後処理環境用に状態を共有される,global

en: tag|example|Sharing state among two handlers
ja: 2つのハンドラーの間で状態を共有する

en: Share state across different handlers inside of a file.
    This attribute is similar to {#visibility}, {#scope}, {#namespace}
    and {#owner}, in that they all maintain state across all handlers
    for the entire source file. Use this attribute to store any data
    your handler might need to save during the parsing of a file. If
    you need to save state across files, see {#globals}.
ja: ファイルの内部の別のハンドラーの行き来の状態を共有する。
    それらは全体のソースファイルの為に全てのハンドラーの行き来の状態を
    全て維持するという点で {#visibility}, {#scope}, {#namespace}, {#owner}属性と似ている。
    この属性を使って、あなたのハンドラーが必要とするかもしれないデータを格納し
    ファイルの解析中に保存する。
    ファイル全体の状態の保存が必要な場合、 {#globals} を参照。

en: an open structure that can store arbitrary data
ja: 任意のデータを記録できる簡単な構造体

en: Creates a new Processor for a +file+.
ja: +file+用の新しいProcessorを作成する

en: a new instance of Processor
ja: プロセッサーの新しいインスタンス

en: the parser used to initialize the processor
ja: プロセッサを初期化するために使ったパーサー

en: Processes a list of statements by finding handlers to process each
    one.
ja: 処理の各自の処理ハンドラーが見つけることによって
    処理ステートメントのリスト

en: a list of statements
ja: ステートメントのリスト

en: tag|param|statements
ja: statements

en: Searches for all handlers in {Base.subclasses} that match the +statement+
ja: +statement+ にマッチする{Base.sublasses}の中の全てのハンドラー用に検索する。

en: a list of handlers to process the statement with.
ja: ステートメントと共に処理する為のハンドラーのリスト

en: the statement object to match.
ja: オブジェクトにマッチするステートメント

en: Returns the handler base class
ja: ハンドラーのbaseクラスを返す

en: The module holding the handlers to be loaded
ja: ロードされるハンドラーを保持する,モジュール

en: the module containing the handlers depending on
    {#parser_type}.
ja: {#parser_type}メソッドに依存しているハンドラーを含んでいる,モジュール

en: Loads handlers from {#handler_base_namespace}. This ensures that
    Ruby1.9 handlers are never loaded into 1.8; also lowers the amount
    of modules that are loaded
ja: {#handler_base_namespace}から、ハンドラーをロードする。
    これはロードされるモジュールの量を減少させると共に
    Ruby1.9ハンドラーが1.8でロードされない事を保証する。

en: Handles alias and alias_method calls
ja: aliasを操作し、alias_methodを呼び出す。

en: Handles +attr_*+ statements in modules/classes
ja: モジュール/クラスの中の +attr_+ ステートメントを操作する。

en: Strips out any non-essential arguments from the attr statement.
ja: attrステートメントから、任意の重要ではない引数を取り除く

en: a list of the parameters
    in the attr call.
ja: attrの中で呼ばれる引数のリスト

en: if the arguments are not valid.
ja: 引数が有効でない場合

en: tag|param|params
ja: params

en: the validated attribute names
ja: 有効化された属性名

en: To implement a custom handler matcher, subclass this class and implement
    {#matches?} to return whether a node matches the handler.
ja: カスタムハンドラーのマッチャーを実装するには、このクラスをサブクラス化する。
    そして、ノードがハンドラーにマッチするかどうかを返す為に{#matches?}メソッドを実装する。

en: # Implements a handler that checks for a specific string
    # in the node's source.
    class MyExtension < HandlesExtension
      def matches?(node) node.source.include?(name) end
    end
    
    # This handler will handle any node where the source includes 'foo'
    class MyHandler < Handlers::Ruby::Base
      handles MyExtension.new('foo')
    end
ja: # 特定の文字列をチェックするハンドラーを実装する
    # ノードのソースの中で
    class MyExtension < HandlesExtension
      def matches?(node) node.source.include?(name) end
    end
    
    # このハンドラーは'foo'を含んでいるソースの所で任意のノードを操作する。
    class MyHandler < Handlers::Ruby::Base
      handles MyExtension.new('foo')
    end

en: tag|example|A Custom Handler Matcher Extension
ja: カスタムハンドラーのマッチャーの拡張

en: Creates a new extension with a specific matcher value +name+
ja: 特定のマッチャーの値の +name+ と共に、新たな拡張を作成する

en: a new instance of HandlesExtension
ja: HandlesExtensionの新しいインスタンス

en: the matcher value to check against {#matches?}
ja: {#matches?}メソッドに備えて確認する,マッチャーの値

en: Tests if the node matches the handler
ja: ノードがハンドラーにマッチする場合、テストする。

en: a Ruby node
ja: Rubyのノード

en: tag|param|node
ja: node

en: whether the +node+ matches the handler
ja: +node+ がハンドラーにマッチするかどうか

en: the extension matcher value
ja: 拡張のマッチャーの値

en: This is the base handler class for the new-style (1.9) Ruby parser.
    All handlers that subclass this base class will be used when the
    new-style parser is used. For implementing legacy handlers, see
    {Legacy::Base}.
ja: これは、新しい(1.9用)Rubyパーサー用の基本ハンドラークラスとなる。
    この基本クラスからサブクラス化する全てのハンドラーは、
    新しいスタイルのパーサーを使う時に利用される。
    レガシーハンドラーの実装には、{Legacy::Base}を参照。

en: See {Handlers::Base} for subclassing information.
ja: サブクラス化用の情報には、{Handlers::Base}を参照

en: Matcher for handling any type of method call. Method calls can
    be expressed by many {AstNode} types depending on the syntax
    with which it is called, so YARD allows you to use this matcher
    to simplify matching a method call.
ja: 任意のメソッド呼び出しの型を操作する為のマッチャー
    メソッド呼び出しは、
    構文から多くの{AstNode}型となって表され
    呼び出す事ができる。
    なので、YARDは
    あなたがメソッド呼び出しのマッチを簡単にする為に
    このマッチャーを使う事を許可する。

en: Statement Matcher Extensions
ja: ステートメントマッチャーの拡張

en: matches the method call of this name
ja: この名前のメソッド呼び出しのマッチャー

en: tag|example|Match the "describe" method call
ja: "describe"メソッド呼び出しにマッチする

en: Matcher for handling a node with a specific meta-type. An {AstNode}
    has a {AstNode#type} to define its type but can also be associated
    with a set of types. For instance, +:if+ and +:unless+ are both
    of the meta-type +:condition+.
ja: 特定のメタタイプと共にノードを処理する為のマッチャー。
    {AstNode}はAstNodeの型を定義する為に
    {AstNode#type}メソッドを持っている。
    しかし、型のグループと共に関連付ける事もできる。
    例えば、 +:if+ と +:unless+ は、両方とも +:condition+ のメタタイプとなる。

en: A meta-type is any method on the {AstNode} class ending in "?",
    though you should not include the "?" suffix in your declaration.
    Some examples are: "condition", "call", "literal", "kw", "token",
    "ref".
ja: メタタイプは、"?"で終わる{AstNode}クラスの任意のメソッドである。
    なので、あなたは、自身の宣言の中で"?"サフィックスを含むべきではない。
    いくつかの例を上げると、"condition", "call", "literal", "kw", "token","ref" となる。

en: tag|example|Handling any conditional statement (if, unless)
ja: 任意の条件文(if, unless)を操作する

en: the meta-type to match. A meta-type can be
    any method name + "?" that {AstNode} responds to.
ja: マッチするメタタイプ。
    メタタイプは、{AstNode}に対応する任意のメソッド名 + "?" でできる。

en: Testing for a Handler
ja: ハンドラー用にテストする。

en: whether or not an {AstNode} object should be
    handled by this handler
ja: {AstNode}オブジェクトはこのハンドラーによって処理されるかどうか

en: Macro Handling
ja: マクロを処理する

en: Matches if/unless conditions inside classes and attempts to process only
    one branch (by evaluating the condition if possible).
ja: クラス内部のif/unless条件にマッチし、一つのブランチだけを処理する。(条件を評価し可能ならば)

en: class Foo
      if 0
        # This method is ignored
        def xyz; end
      end
    end
ja: class Foo
      if 0
        # このメソッドは無視される
        def xyz; end
      end
    end

en: tag|example|A simple class conditional
ja: シンプルな条件のクラス

en: Parses the condition part of the if/unless statement
ja: if/unlessステートメントの部分の条件を解析する。

en: true if the condition can be definitely
    parsed to true, false if not, and nil if the condition cannot be
    parsed with certainty (it's dynamic)
ja: 条件が間違いなく解析できる場合、true
    そうでない場合、falseや、
    条件が完璧に解析できない場合、nilとなる。
    (it's dynamic)

en: Handles class declarations
ja: クラスの宣言を操作する

en: Extract the parameters from the Struct.new AST node, returning them as a list
    of strings
ja: パラメータをStrct.new Astノードから抽出し、文字列のリストとしてAstノードを返す。

en: tag|param|superclass
ja: superclass

en: the AST node for the Struct.new call
ja: Struct.new呼び出し用のASTノード

en: the member names to generate methods for
ja: member名にメソッドを生成する,member名

en: Handles a class variable (@@variable)
ja: クラス変数を操作する(@@変数)

en: Handles any lone comment statement in a Ruby file
ja: Rubyのファイルの中の任意の単一のコメントステートメントを操作する

en: Handles any constant assignment
ja: 任意の定数割り当てを操作する

en: Handles automatic detection of dsl-style methods
ja: DSLスタイルのメソッドの自動宣言を操作する

en: Handles 'raise' calls inside methods
ja: メソッドの内部で呼び出す'raise'を操作する

en: Handles 'extend' call to include modules into the class scope of another
ja: 他のクラススコープの中へモジュールを含める為に、'extend'呼び出しを操作する。

en: This is the base handler for the legacy parser. To implement a legacy
    handler, subclass this class.
ja: これは、legacy parser用のbase handlerとなる。
    legacy handlerの実装には、このクラスをサブクラスにする。

en: whether or not a {Parser::Ruby::Legacy::Statement} object should be handled
    by this handler.
ja: {Parser::Ruby::Legacy::Statement}オブジェクトが、
    このハンドラーによって操作されるかどうか

en: Parses a statement's block with a set of state values. If the
    statement has no block, nothing happens. A description of state
    values can be found at {Handlers::Base#push_state}
ja: 値の状態のグループと共に、ブロックのステートメントを解析する。
    ステートメントがブロックを持たない場合、何も起こらない。
    値の状態の説明は、{Handlers::Base#push_state}で見つけられる。

en: State options
ja: オプションの状態

en: The string value of a token. For example, the return value for the symbol :sym
    would be :sym. The return value for a string +"foo #{ bar}"+ would be the literal
    +"foo #{ bar}"+ without any interpolation. The return value of the identifier
    'test' would be the same value: 'test'. Here is a list of common types and
    their return values:
ja: トークンの文字列の値。例えば、シンボル:sym用に返す値は、:symになる。
    文字列 +"foo #{ bar}"+ 用に返す値は、補完を含まない +"foo #{ bar}"+ リテラルになる。
    'test'識別子の返す値は、'test'と同じ値になるだろう。
    ここでは、一般的な型のリストやそれらの値を返す。

en: The allowed token types that this token can be. Defaults to [{TkVal}].
    A list of types would be, for example, [+TkSTRING+, +TkSYMBOL+], to return
    the token's value if it is either of those types. If +TkVal+ is accepted,
    +TkNode+ is also accepted.
    
    Certain symbol keys are allowed to specify multiple types in one fell swoop.
    These symbols are:
      :string       => +TkSTRING+, +TkDSTRING+, +TkDXSTRING+ and +TkXSTRING+
      :attr         => +TkSYMBOL+ and +TkSTRING+
      :identifier   => +TkIDENTIFIER, +TkFID+ and +TkGVAR+.
      :number       => +TkFLOAT+, +TkINTEGER+
ja: トークンにできる受け入れられるトークンの型となる。
    デフォルトでは、[{TkVal}]になる。
    型のリストになる、
    
    例えば、[+TkSTRING+, +TkSYMBOL+]は、
    どちらかがこれらの型の場合、トークンの値を返す。
    +TkVal+が受け入れられる場合、+TkNode+も受け入れられる。
    
    特定のシンボルキーは、一つで複数の型を一気に指定する為に受け入れられる。
    このようなシンボルとなる:
      :string       => +TkSTRING+, +TkDSTRING+, +TkDXSTRING+ and +TkXSTRING+
      :attr         => +TkSYMBOL+ and +TkSTRING+
      :identifier   => +TkIDENTIFIER, +TkFID+ and +TkGVAR+.
      :number       => +TkFLOAT+, +TkINTEGER+

en: The token of the class
ja: クラスのトークン

en: if the token is not any of the specified accepted types
ja: トークンが指定され受け入れられる型のどれでもない場合、

en: if the token is one of the accepted types, in its real value form.
    It should be noted that identifiers and constants are kept in String form.
ja: トークンが受け入れられる型の一つの場合、その中は、実際の値の形式になる。
    そして、識別子と定数がString形式で注釈される。

en: tag|param|accepted_types
ja: accepted_types

en: tag|param|token
ja: token

en: Returns a list of symbols or string values from a statement.
    The list must be a valid comma delimited list, and values
    will only be returned to the end of the list only.
ja: ステートメントから、シンボル,又は,文字列の値のリストを返す。
    リストは、有効なカンマで区切られたリストでなければならない、
    そして、値はリストで返されるだけにしなければならない。

en: The tokval list of a {Parser::Ruby::Legacy::TokenList} of the above
    code would be the {#tokval} value of :a, 'b',
    :c and :d.
ja: 上のコード{Parser::Ruby::Legacy::TokenList}のtokvalのリストは、
    :a, 'b', :c, :d の入った{#tokval}の値になる。

en: It should also be noted that this function stops immediately at
    any ruby keyword encountered:
      "attr_accessor :a, :b, :c if x == 5"  => ['a', 'b', 'c']
ja: それは、この機能が任意のrubyキーワードが出会った所で、
    直後に止めて注釈される。
      "attr_accessor :a, :b, :c if x == 5"  => ['a', 'b', 'c']

en: The list of tokens to process.
ja: 処理されるトークンのリスト

en: if there are no symbols or Strings in the list
ja: シンボルやリストの文字列がない場合

en: passed to {#tokval}
ja: {#tokval}に渡される

en: tag|param|tokenlist
ja: tokenlist

en: the list of tokvalues in the list.
ja: リストの中のtokvaluesのリスト

en: Extracts the parameter list from the Struct.new declaration and returns it
    formatted as a list of member names. Expects the user will have used symbols
    to define the struct member names
ja: Struct.new宣言から、引数のリストを抽出し、
    それをメンバー名のリストとして、書式化して返す
    ユーザーは、structメンバー名を定義する為に、シンボルを
    利用する事を要求するだろう。

en: a list of member names
ja: メンバー名のリスト

en: tag|param|superstring
ja: superstring

en: the string declaring the superclass
ja: 文字列で宣言しているsuperclass

en: Handles a method definition
ja: メソッドの定義を操作する

en: Handles the 'include' statement to mixin a module in the instance scope
ja: インスタンススコープのモジュールをmixinする為に、'include'ステートメントを操作する。

en: Handles the declaration of a module
ja: モジュールの宣言を操作する

en: Sets visibility of a constant (class, module, const)
ja: 定数の可視性を設定する(クラス,モジュール,定数)

en: Handles 'private', 'protected', and 'public' calls.
ja: 'private', 'protected', 'public' 呼び出しを操作する。

en: Handles 'yield' calls
ja: 'yield'を呼び出し操作する

en: Handles a conditional inside a method
ja: メソッドの内部の条件を操作する

en: Helper methods to parse @attr_* tags on a class.
ja: クラスの@attr_* タグを解析する為のHelperメソッド

en: Extracts the user's defined @member tag for a given class and its member. Returns
    nil if the user did not define a @member tag for this struct entry.
ja: 与えられたクラスとそのメンバー用に
    ユーザーの定義した@memberタグを抽出する。
    この構造体の登録用の@memberタグが未定義だった場合、nilを返す。

en: reader method, or writer method?
ja: readerメソッドかwriterメソッドか?

en: tag|param|klass
ja: klass

en: tag|param|member
ja: member

en: the class whose tags we're searching
ja: 検索しているタグのクラス

en: the name of the struct member we need
ja: 必要とする構造体memberの名前

en: the tag matching the request, or nil if not found
ja: マッチしているタグのリクエスト、見つからない場合は、nil

en: Retrieves all members defined in @attr* tags
ja: @attr* タグの中で定義した全てのメンバーを回収する

en: the class with the attributes
ja: 属性と一緒のクラス

en: the list of members defined as attributes on the class
ja: クラス上の属性として、定義したメンバーのリスト

en: Determines whether to create an attribute method based on the class's
    tags.
ja: クラス上で、基底のメソッド属性を作成するかどうか、確定する。

en: (:read) reader method, or writer method?
ja: (:read) readerメソッドか、writerメソッドか?

en: should the attribute be created?
ja: 属性が作成されるかどうか?

en: Gets the return type for the member in a nicely formatted string. Used
    to be injected into auto-generated docstrings.
ja: より良く書式化された文字列でmember用に返す型を取得する。
    自動生成されたdocstrigの中へ入れる為に利用される

en: the tag object to check for types
ja: 型をチェックする為のタグオブジェクト

en: the user-declared type of the struct member, or [Object] if
    the user did not define a type for this member.
ja: 構造体memberの宣言されたユーザーの型、\n
    又はこのmember用にuserが、型を定義しなかった場合 [Object] となる。

en: Creates the auto-generated docstring for the getter method of a struct's
    member. This is used so the generated documentation will look just like that
    of an attribute defined using attr_accessor.
ja: 構造体memberのgetterメソッド用に自動生成されるdocstringを作成する。
    これを用いて生成されるドキュメントは、attr_accessorによって定義された属性のように見える。

en: a docstring to be attached to the getter method for this member
ja: このmember用にgetterメソッドに加えられるdocstring

en: the class whose members we're working with
ja: 操作するmemberクラスに用いるクラス

en: the name of the member we're generating documentation for
ja: 生成されるドキュメントのmemberの名前

en: Creates the auto-generated docstring for the setter method of a struct's
    member. This is used so the generated documentation will look just like that
    of an attribute defined using attr_accessor.
ja: 構造体のメンバーのsetterメソッド用に、自動生成されたdocstringを作成する。
    これは、生成されたドキュメントが、
    attr_accessorによって定義された属性のように見えるように利用される。

en: a docstring to be attached to the setter method for this member
ja: このメンバー用にsetterメソッドに加えられるdocstring

en: Creates and registers a class object with the given name and superclass name.
    Returns it for further use.
ja: 与えられたクラス名、スーパークラス名と共に、
    クラスオブジェクトを作成,記録する。
    更に利用する為に返す。

en: tag|param|classname
ja: classname

en: the class object for further processing/method attaching
ja: 処理/メソッドを加える為のクラスオブジェクト

en: the name of the class
ja: クラスの名前

en: the name of the superclass
ja: スーパークラスの名前

en: Creates the setter (writer) method and attaches it to the class as an attribute.
    Also sets up the docstring to prettify the documentation output.
ja: setter(writer)メソッドを作成し、属性としてクラスに追加する。
    それに加え、ドキュメント出力を装飾する為にdocstringをセットアップする。

en: the class to attach the method to
ja: クラスにメソッドを追加するクラス

en: the name of the member we're generating a method for
ja: 私達がメソッド用に生成するメンバーの名前

en: Creates the getter (reader) method and attaches it to the class as an attribute.
    Also sets up the docstring to prettify the documentation output.
ja: getter(reader)メソッドを作成し、属性として、クラスに追加する。
    さらに、ドキュメント出力を装飾する為に、docstringをセットアップする。

en: Creates the given member methods and attaches them to the given ClassObject.
ja: 与えられたメンバーメソッドを作成し、与えられたClassObjectにそれらを加える。

en: tag|param|members
ja: members

en: the class to generate attributes for
ja: 属性を生成するクラス用のクラス

en: Creates a locale for +name+ locale.
ja: +name+ の言語別にlocaleを作成する

en: a new instance of Locale
ja: Localeの新しいインスタンス

en: the locale name.
ja: 言語名(地域名)

en: Loads translation messages from +locale_directory+/{#name}.po.
ja: +locale_directory+/{#name}.po.から翻訳メッセージをロードする

en: +true+ if PO file exists, +false+ otherwise.
ja: POファイルが存在すればtrue、そうでなければ、false

en: the translation target message.
ja: 翻訳目標のメッセージ

en: the message ID of the translation target message.
ja: 翻訳目標のメッセージのメッセージID

en: path and line number where the message is appered.
ja: メッセージが現れるところのパスと行数

en: the set of comments for the messages.
ja: メッセージ用のコメントのグループ

en: Creates a translate target message for message ID +id+.
ja: メッセージID +id+ 用の翻訳目標のメッセージを作成する

en: a new instance of Message
ja: メッセージの新しいインスタンス

en: the message ID of the translate target message.
ja: 翻訳目標のメッセージのメッセージID

en: Adds location information for the message.
ja: メッセージ用の地域情報を追加する

en: the line number where the message appears.
ja: メッセージが見えるところの行数

en: the path where the message appears.
ja: メッセージが見えるところのパス

en: Adds a comment for the message.
ja: メッセージ用のコメントを追加する

en: the comment for the message to be added.
ja: 追加されるメッセージ用のコメント

en: checks whether this message is equal to another.
ja: このメッセージが他と同じかどうか

en: the +Message+ to be compared.
ja: 比較される為の +message+

en: Creates a new container.
ja: 新しいコンテナを作成する

en: a new instance of Messages
ja: メッセージの新しいインスタンス

en: the next message object in
    the enumeration.
ja: 配列の中の次のメッセージオブジェクト

en: the ID of the message to be registered.
ja: 記録されるメッセージのID

en: the registered +Message+.
ja: 記録された +Message+

en: the container to compare.
ja: 比較するためのコンテナ

en: the set of message objects
ja: メッセージオブジェクトのグループ

en: tag|example|Generate a .pot file
ja: tag|example|.popファイルを生成する

en: a new instance of PotGenerator
ja: PotGeneratorの新しいインスタンス

en: Parses {CodeObjects::Base} objects and stores extracted msgids
    into {#messages}
ja: {CodeObjects::Base}オブジェクトを解析し、
    {#messages}メソッドの中へ抽出されたmsgidを登録する

en: a list of
    {CodeObjects::Base} to be parsed.
ja: 解析される {CodeObjects::Base} のリスト

en: Parses {CodeObjects::ExtraFileObject} objects and stores
    extracted msgids into {#messages}.
ja: {CodeObjects::ExtraFileObject} オブジェクトを解析し、
    抽出されたmsgidを{#messages}の中へ登録する。

en: a list
    of {CodeObjects::ExtraFileObject} objects to be parsed.
ja: 解析される {CodeObjects::ExtraFileObject} オブジェクトのリスト

en: a new instance of Text
ja: Textの新しいインスタンス

en: a text to be translated.
ja: 翻訳されるテキスト

en: the defined line number of extracted
    attribute.
ja: 抽出された属性の定義された行数

en: the name of extracted attribute.
ja: 抽出された属性の名前

en: the start line number of
    extracted paragraph.
ja: 抽出された段落の最初の行数

en: the text of extracted paragraph.
ja: 抽出された段落のテキスト

en: the value of extracted attribute.
ja: 抽出された属性の値

en: the translation target locale.
ja: 翻訳目標の地域

en: translated text.
ja: 翻訳されたテキスト

en: Handles console logging for info, warnings and errors.
    Uses the stdlib Logger class in Ruby for all the backend logic.
ja: コンソールがinfoや,警告や,エラー用にロギングし操作する。
    全てのバックエンドの処理の為にRuby標準ライブラリのloggerクラスを使う。

en: the IO object being logged to
ja: IOオブジェクトに記録されるIOオブジェクト

en: the value to set the attribute show_backtraces to.
ja: show_backtraces属性を設定する値

en: Sets the attribute show_backtraces
ja: show_backtraces属性を設定する

en: the value to set the attribute show_progress to.
ja: 値にshow_progress属性を設定する為の値

en: Sets the attribute show_progress
ja: show_progress属性を設定する

en: The logger instance
ja: loggerインスタンス

en: the logger instance
ja: loggerインスタンス

en: Creates a new logger
ja: 新しいloggerを作成する

en: a new instance of Logger
ja: Loggerの新しいインスタンス

en: Changes the debug level to DEBUG if $DEBUG is set
    and writes a debugging message.
ja: $DEBUGが設定された場合、debug levelをDEBUGに変更し、
    デバッグメッセージを書き込む。

en: a block of arbitrary code to benchmark
ja: ベンチマークの為の任意のコードの入ったブロック

en: the message to display
ja: 表示するメッセージ

en: the message to log
ja: 記録するメッセージ

en: Prints the backtrace +exc+ to the logger as error data.
ja: +exc+ のバックトレースをエラーデータとしてloggerにプリントする。

en: tag|param|exc
ja: exc

en: the backtrace list
ja: バックトレースのリスト

en: the level to log backtrace at
ja: バックトレースを記録する階層

en: Warns that the Ruby environment does not support continuations. Applies
    to JRuby, Rubinius and MacRuby. This warning will only display once
    per Ruby process.
ja: Rubyの環境がcontinuationをサポートしない警告を出す。
    JRuby,Rubinius,MacRubyに適用される。
    この警告は、Rubyの処理毎に一度だけ表示されるだろう

en: Sets the logger level for the duration of the block
ja: ブロックの継続するlogger levelを設定する。

en: tag|param|new_level
ja: new_level

en: the block with the logger temporarily set to +new_level+
ja: loggerが一時的に+new_level+を設定するブロック

en: the logger level for the duration of the block.
    values can be found in Ruby's Logger class.
ja: ブロックの継続するlogger level.
    値はRuby loggerクラスで見つける事が出来る。

en: Log format (from Logger implementation). Used by Logger internally
ja: ログ書式(loggerの実装から)。Loggerによって内部で利用される。

en: tag|example|Defining an Options class with custom option keys
ja: カスタムオプションのkeyを用いたオプションクラス定義

en: tag|example|Deprecating an option while still supporting it
ja: まだサポートしているけれど廃止するオプション

en: tag|example|Initializing default option values
ja: tag|example|初期化されたデフォルトのオプション値

en: tag|example|Using +default_attr+ to create default attributes
ja: tag|example|デフォルト属性を作成するための +default_attr+ を用いる

en: tag|example|Defining a default option key
ja: tag|example|デフォルトのオプションキーの定義

en: the option key name
ja: オプションキー名

en: tag|example|Calling on an option key with Hash syntax
ja: tag|example|ハッシュ構文を用いたオプションキーを呼び出す

en: the option name to access
ja: アクセスするためのオプション名

en: the value of the option named +key+
ja: +key+ と名付けられたオプションの値

en: tag|example|Setting an option with Hash syntax
ja: tag|example|ハッシュ構文を用いたオプションの設定

en: the option to set
ja: 設定するためのオプション

en: the value being set
ja: 設定される値

en: the value to set for the option
ja: オプション用に設定するための値

en: tag|example|Updating a set of options on an Options object
ja: tag|example|オプションオブジェクトでオプションのグループの更新

en: the newly created options object
ja: 新たに作成されたオプションオブジェクト

en: the option key
ja: オプションのキー

en: the option value
ja: オプションの値

en: Inspects the object
ja: オブジェクトを解析する

en: Resets all values to their defaults.
ja: それらのデフォルトの全ての値をリセットする

en: the key to delete a value for
ja: キー用に値を削除する為のキー

en: the value that was deleted
ja: 削除された値

en: Represents the abstract base parser class that parses source code in
    a specific way. A parser should implement {#parse}, {#tokenize} and
    {#enumerator}.
ja: 独自の方法でソースコードを解析する抽象的なベースパーサークラスを表す。
    パーサーは{#parse}や,{#tokenize}や{#enumerator}メソッドを実装しなくてはならない。

en: == Registering a Custom Parser
    To register a parser, see {SourceParser.register_parser_type}
ja: == カスタムパーサーを記録する
    パーサーを記録する為には、{SourceParser.register_parser_type}を参照。

en: Convenience method to create a new parser and {#parse}
ja: 新しいパーサーや(#parse)メソッドを作成する為の便利なメソッド

en: This default constructor does nothing. The subclass is responsible for
    storing the source contents and filename if they are required.
ja: このデフォルトのコンストラクターは何もしない。
    サブクラスがソースの内容やファイル名が必要とされる場合、それらを記憶する責任がある。

en: the name of the file if from disk
ja: ディスクからの場合、ファイルの名前

en: the source contents
ja: ソースの内容

en: This method should be implemented to parse the source and return itself.
ja: このメソッドはソースの解析やそれ自身を返す為に
    実装されなくてはならない。

en: this method should return itself
ja: このメソッドはそれ自身を返さなくてはならない。

en: This method should be implemented to tokenize given source
ja: このメソッドは与えられたソースを
    トークナイズする為に実装されなければならない。

en: a list/tree of lexical tokens
ja: 単語のトークンの入ったリストやツリー

en: This method should be implemented to return a list of semantic tokens
    representing the source code to be post-processed. Otherwise the method
    should return nil.
ja: 後処理される為にソースコードを表している意味のあるトークンのリストを返す為に
    このメソッドは実装されなければならない。
    そうでなければこのメソッドは、nilを返さなければならない。

en: a list of semantic tokens representing the source code
    to be post-processed
ja: 後処理される為のソースコードを表す意味のあるトークンのリスト

en: if no post-processing should be done
ja: 後処理がない場合、nilを返さなければならない。

en: a new instance of CParser
ja: Cパーサーの新しいインスタンス

en: the value to set the attribute source to.
ja: ソースの属性を設定する,値

en: Returns the value of attribute source
ja: source属性の入った値を返す。

en: Sets the attribute source
ja: ソース属性を設定する。

en: the value to set the attribute line to.
ja: 値に行属性を設定するための値

en: Returns the value of attribute line
ja: 行属性の値を返す

en: Sets the attribute line
ja: 行属性を設定

en: the value to set the attribute file to.
ja: ファイル属性を設定する,値

en: Returns the value of attribute file
ja: file属性の値を返す。

en: Sets the attribute file
ja: ファイル属性を設定する。

en: the value to set the attribute comments_hash_flag to.
ja: comments_hash_flag属性を設定する。

en: Returns the value of attribute comments_hash_flag
ja: comments_hash_flag属性を返す。

en: Sets the attribute comments_hash_flag
ja: comments_hash_flag属性を設定する。

en: a new instance of Statement
ja: ステートメントの新しいインスタンス

en: the value to set the attribute comments to.
ja: 値にコメント属性を設定するための値

en: Returns the value of attribute comments
ja: コメント属性の値を返す。

en: Sets the attribute comments
ja: コメント属性を設定する

en: the value to set the attribute block to.
ja: 値にblock属性を設定するための値

en: Returns the value of attribute block
ja: ブロック属性の値を返す。

en: Sets the attribute block
ja: block属性を設定する。

en: the value to set the attribute declaration to.
ja: 値に宣言属性を設定するための値

en: Returns the value of attribute declaration
ja: 宣言属性の値を返す

en: Sets the attribute declaration
ja: 宣言属性を設定する

en: the value to set the attribute type to.
ja: 値に型属性を設定するための値

en: Returns the value of attribute type
ja: 型属性の値を返す

en: Sets the attribute type
ja: 型属性を設定する

en: the value to set the attribute overrides to.
ja: 値にオーバーライド属性を設定するための値

en: Returns the value of attribute overrides
ja: オーバーライド属性の値を返す

en: Sets the attribute overrides
ja: オーバーライド属性を設定する

en: the value to set the attribute statement to.
ja: 値にステートメント属性を設定するための値

en: Returns the value of attribute statement
ja: ステートメント属性の値を返す

en: Sets the attribute statement
ja: ステートメント属性を設定する

en: a new instance of Comment
ja: コメントの新しいインスタンス

en: Builds and s-expression by creating {AstNode} objects with
    the type provided by the first argument.
ja: 最初の引数によって提供された型を用い{AstNode}オブジェクトを作成する事によって
    ビルドされS式にされる。

en: tag|example|A method call
ja: メソッド呼び出し

en: tag|example|An implicit list of keywords
ja: キーワードの暗黙のリスト

en: An AST node is characterized by a type and a list of children. It
    is most easily represented by the s-expression {#s} such as:
      # AST for "if true; 5 end":
      s(s(:if, s(:var_ref, s(:kw, "true")), s(s(:int, "5")), nil))
ja: ASTノードは型や子のリストによって特徴付けられる。
    それは最も簡単にS式 {#s}メソッドによって表される。
    以下の通り。
      # AST for "if true; 5 end":
      s(s(:if, s(:var_ref, s(:kw, "true")), s(s(:int, "5")), nil))

en: The node type is not considered part of the list, only its children.
    So +ast[0]+ does not refer to the type, but rather the first child
    (or object). Items that are not +AstNode+ objects can be part of the
    list, like Strings or Symbols representing names. To return only
    the AstNode children of the node, use {#children}.
ja: ノードの型は、リストの一部とは考えられていない。
    その為,そのリストは子だけとなる。
    そして +ast[0]+ は型を参照しない、
    しかし、最初の子(やオブジェクト)が選ばれる。
    +AstNode+ オブジェクトではない事項は、リストの一部にでき、
    文字列やシンボルのように、名前を表現している。
    ノードからAstNodeの子だけ返すには、{#children}メソッドを使用する。

en: the value to set the attribute docstring_hash_flag to.
ja: docstring_hash_flag属性を設定する,値

en: Returns the value of attribute docstring_hash_flag
ja: docstring_hash_flag属性の値を返す。

en: Sets the attribute docstring_hash_flag
ja: docstring_hash_flag属性を設定する。

en: the parse of {#full_source} that the node represents
ja: ノードを表す{#full_source}の入った,parse

en: the value to set the attribute docstring to.
ja: docstring属性を設定する,値

en: the value to set the attribute docstring_range to.
ja: docstring_range属性を設定する,値

en: Returns the value of attribute docstring
ja: docstring属性の入った値を返す。

en: Returns the value of attribute docstring_range
ja: docstring_range属性の入った値を返す。

en: Sets the attribute docstring
ja: docstring属性を設定する。

en: Sets the attribute docstring_range
ja: docstring_range属性を設定する。

en: the value to set the attribute full_source to.
ja: full_source属性を設定する,値

en: the value to set the attribute line_range to.
ja: line_range属性を設定する,値

en: the value to set the attribute source_range to.
ja: source_range属性を設定する,値

en: Sets the attribute full_source
ja: full_source属性を設定する。

en: Sets the attribute line_range
ja: line_range属性を設定する。

en: Sets the attribute source_range
ja: source_range属性を設定する。

en: the node's unique symbolic type
ja: 独自のsymbolic型のノード群。

en: the node's parent or nil if it is a root node.
ja: 親ノード群(ルートノードの場合,nilとなる。)

en: the character range in {#full_source} represented
    by the node
ja: ノードによって表される{#full_source}メソッドの中の固有の範囲。

en: the line range in {#full_source} represented
    by the node
ja: ノードによって表される{#full_source}メソッドの中の行の範囲。

en: the filename the node was parsed from
ja: ノードを解析した,ファイル名

en: the full source that the node was parsed from
ja: ノードから解析されたソースの全て。

en: List of all known keywords
ja: 著名なキーワードのリスト。

en: Finds the node subclass that should be instantiated for a specific
    node type
ja: 特定のノード型用の
    インスタンス化されるべきサブクラスのノードを見つける。

en: Creating an AstNode
ja: AstNodeを作成する。

en: a subclass of AstNode to instantiate the node with.
ja: nodeをインスタンス化するAstNodeのサブクラス

en: the node type to find a subclass for
ja: ノードの型用のサブクラスを見つける,型

en: Creates a new AST node
ja: 新しいASTノードを作成する。

en: a new instance of AstNode
ja: AstNodeの新しいインスタンス

en: any extra line options
ja: 行の為の追加の設定

en: the child nodes
ja: 子のノード

en: the type of node being created
ja: 作成されるノードのタイプ

en: whether the node is equal to another by checking
    the list and type
ja: ノードがリストか型かチェックすることによって他と等しくなるかどうか

en: Searches through the node and all descendants and returns the
    first node with a type matching any of +node_types+, otherwise
    returns the original node (self).
ja: ノードや,全ての子孫の中を検索する。
    +node_types+ の入った型マッチと共に
    最初のノードを返す。
    さもなければ、(自身の)オリジナルノードを返す。

en: Traversing a Node
ja: ノードを辿る。

en: a set of node types to match
ja: マッチするノードの型の設定。

en: if no node was found
ja: ノードが見つからなかった場合

en: tag|example|If the node types are not present in the AST
ja: ノードの型がASTの中に渡さない場合

en: tag|example|Returns first 'def' or 'class' statement
ja: 最初の'def'や'class'ステートメントを返す。

en: tag|example|Returns the first method definition in a block of code
ja: コードのブロックの中の最初のメソッド定義を返す。

en: the matching node, if one was found
ja: マッチするノード(一つ見つかった場合)

en: the {AstNode} children inside the node
ja: ノード内部の{AstNode}の子。

en: Traverses the object and yields each node (including descendants) in order.
ja: オブジェクトを辿り、
    順番にそれぞれのノード(子孫を含んでいる)を
    yieldする。

en: each descendant node in order
ja: 整理されたそれぞれの子孫のノード。

en: or a child/descendant node
ja: 自身や子や子孫のノード。

en: whether the node is a token
ja: ノードがトークンかどうか

en: whether the node is a reference (variable,
    constant name)
ja: ノードが参照するかどうか(変数,定数名)

en: whether the node is a literal value
ja: ノードがリテラル値かどうか

en: whether the node is a keyword
ja: ノードがキーワードかどうか

en: whether the node is a method call
ja: ノードがメソッド呼び出しかどうか

en: whether the node is a method definition
ja: ノードがメソッド定義かどうか

en: whether the node is a if/elsif/else condition
ja: ノードがifやelsifやelseの条件かどうか

en: whether the node is a loop
ja: ノードがループかどうか

en: whether the node has a block
ja: ノードがblockかどうか

en: Getting Line Information
ja: 行の情報を取得する。

en: whether the node has a {#line_range} set
ja: ノードが{#line_range}設定を持っているかどうか

en: the starting line number of the node
ja: ノードの文字列の行数

en: the first line of source represented by the node.
ja: ノードによって表されるソースの最初の行

en: Printing a Node
ja: ノードをプリントする。

en: the first line of source the node represents
ja: ノードを表すソースの最初の行

en: pretty prints the node
ja: ノードの出力

en: inspects the object
ja: 解析するオブジェクト

en: Managing node state
ja: ノードの状態の管理

en: Resets node state in tree
ja: ツリーの中でノードの状態をリセットする

en: Resets line information
ja: 行情報をリセットする。

en: Represents a lone comment block in source
ja: ソースの中の単一のコメントブロックを表す

en: Represents a token in the Ruby lexer
ja: Ruby lexerの中のトークンを表す

en: the line number in the file/stream the token is
    located.
ja: トークンが位置する,ファイルやストリームの中の行の数

en: the character number in the file/stream the token
    is located.
ja: トークンが位置する,ファイルやストリームの中のcharacterの数

en: the token text value
ja: トークンのテキストの値

en: the lexical state at the token
ja: トークンにおける単語の状態

en: Creates a new Token object
ja: 新しいトークンオブジェクトを作成する

en: a new instance of Token
ja: トークンの新しいインスタンス

en: the char number to initialize the token to
ja: char numberをトークンにイニシャライズする, char number

en: the line number to initialize the token to
ja: 行数をトークンにイニシャライズする。行数

en: Chainable way to sets the text attribute
ja: テキスト属性を設定する為の方法を紐付ける。

en: the new text
ja: 新しいテキスト

en: this token object
ja: このトークンオブジェクト

en: Represents a block
ja: ブロックを表す

en: Represents an end statement
ja: ステートメントの終りを表す。

en: Returns the value of attribute node
ja: node属性の値を返す。

en: Represents whitespace
ja: 空白を表す

en: Represents a Ruby identifier
ja: RubyのIDを表す。

en: a new instance of TkId
ja: TkIdの新しいインスタンス

en: Represents a Ruby keyword
ja: Rubyキーワードを表す。

en: Represents a Ruby value
ja: Rubyの値を表す。

en: a new instance of TkVal
ja: TkValの新しいインスタンス

en: a new instance of TkOPASGN
ja: TkOPASGNの新しいインスタンス

en: Returns the value of attribute op
ja: op属性の値を返す。

en: a new instance of TkUnknownChar
ja: TkUnknownCharの新しいインスタンス

en: Lexical analyzer for Ruby source
ja: Rubyソース用の単語解析

en: Read an input stream character by character. We allow for unlimited
    ungetting of characters just read.
ja: character毎にストリームの入力を読み込む。
    そこで読まれたcharacterの書き戻しを無制限に許可する。

en: We simplify the implementation greatly by reading the entire input
    into a buffer initially, and then simply traversing it using
    pointers.
ja: 最初にバッファの中へ全ての入力を読み込む事によって
    実装する事を非常に簡潔にする。
    そして、それはポインターを利用する事によって簡単に辿ることができる。

en: We also have to allow for the <i>here document diversion</i>. This
    little gem comes about when the lexer encounters a here
    document. At this point we effectively need to split the input
    stream into two parts: one to read the body of the here document,
    the other to read the rest of the input line where the here
    document was initially encountered. For example, we might have
ja: 私達は <i>複数のヒアドキュメント</i> も考慮しなければならない。
    この複数のヒアドキュメントは、字句解析器がヒアドキュメントに出会う時に起こる。
    この時点で私達は、事実上2つの部分に入力ストリームを分割する必要がある。
    一つはヒアドキュメントの本体を読み込む部分、
    もう一つは、それ以外の
    ヒアドキュメントが最初に出会った所から、
    入力行の残りを読み込む為の部分。
    例えば、

en: When the lexer encounters the <<A, it reads until the end of the
    line, and keeps it around for later. It then reads the body of the
    here document.  Once complete, it needs to read the rest of the
    original line, but then skip the here document body.
ja: この字句解析器が<<Aと出会った時、行の終りまで読み込まれその内容を保持する。
    そして、その後ヒアドキュメントの本体を読み込む。
    一度Aの部分で解析が完了させ、字句解析器は元の行の残りを読み込む必要がある。
    しかし、その時ヒアドキュメントの本体はスキップする。

en: Returns the value of attribute line_num
ja: line_num属性の値を返す。

en: a new instance of BufferedReader
ja: BufferedReaderの新しいインスタンス

en: Returns the value of attribute continue
ja: continue属性の値を返す。

en: Returns the value of attribute lex_state
ja: lex_state属性の値を返す。

en: a new instance of RubyLex
ja: RubyLexの新しいインスタンス

en: the value to set the attribute skip_space to.
ja: skip_space属性を設定する,値

en: Returns the value of attribute skip_space
ja: skip_space属性を返す。

en: Sets the attribute skip_space
ja: skip_space属性を設定する。

en: the value to set the attribute read_auto_clean_up to.
ja: read_auto_clean_up属性を設定する,値

en: Returns the value of attribute read_auto_clean_up
ja: read_auto_clean_up属性の値を返す。

en: Sets the attribute read_auto_clean_up
ja: read_auto_clean_up属性を設定する。

en: the value to set the attribute exception_on_syntax_error to.
ja: exception_on_syntax_error属性を設定する,値

en: Returns the value of attribute exception_on_syntax_error
ja: exception_on_syntax_error属性の値を返す。

en: Sets the attribute exception_on_syntax_error
ja: exception_on_syntax_error属性を設定する。

en: Returns the value of attribute indent
ja: indent属性の値を返す。

en: io functions
ja: 入出力の機能

en: Legacy Ruby parser
ja: レガシーRubyパーサー

en: a new instance of RubyParser
ja: Rubyパーサーの新しいインスタンス

en: Returns the value of attribute tokens
ja: tokens属性の値を返す。

en: the value to set the attribute comments_range to.
ja: comments_range属性を設定する,値

en: Returns the value of attribute comments_range
ja: comments_range属性を返す。

en: Sets the attribute comments_range
ja: comments_range属性を設定する。

en: the first line of Ruby source
ja: Rubyのソースの入った最初の行

en: the first to last lines of Ruby source
ja: Rubyのソースの入った,最初から最後までの行

en: the value to set the attribute encoding_line to.
ja: encoding_line属性を設定する,値

en: the value to set the attribute shebang_line to.
ja: shebang_line属性を設定する,値

en: Returns the value of attribute encoding_line
ja: encoding_line属性を返す。

en: Returns the value of attribute shebang_line
ja: shebang_line属性の値を返す。

en: Sets the attribute encoding_line
ja: encoding_line属性を設定する。

en: Sets the attribute shebang_line
ja: shebang_line属性を設定する。

en: The following list of tokens will require a block to be opened
    if used at the beginning of a statement.
ja: 続くトークンのリストは、
    ステートメントの最初で使う場合、ブロックを必要とする。

en: Creates a new statement list
ja: 新しいステートメントのリストを作成する。

en: a new instance of StatementList
ja: StatementListの新しいインスタンス

en: the tokens to create the list from
ja: トークンのリストを作成する,トークン

en: Returns the next statement in the token stream
ja: 処理するトークンの中の次の文を返す。

en: the next statement
ja: 次のステートメント

en: Processes a single token
ja: 単一のトークンを処理する。

en: the token to process
ja: 処理の為のトークン

en: Processes a token in a block
ja: ブロックの中のトークンを処理する。

en: Processes a comment token that comes before a statement
ja: statement処理の前にトークンのコメントを処理する。

en: whether or not +tk+ was processed as an initial comment
ja: +tk+ がこの#process_initial_commentメソッドが正常に処理されたかどうか。

en: Processes a simple block-opening token;
    that is, a block opener such as +begin+ or +do+
    that isn't followed by an expression
ja: 後に式がない +begin+ や +do+ 等のような単純なトークンの
    blockを開く処理をする。

en: Processes a complex block-opening token;
    that is, a block opener such as +while+ or +for+
    that is followed by an expression
ja: 後に式が来る +while+ や +for+ 等のようなトークンの
    複雑なblockを開く処理をする。

en: Processes a token that closes a statement
ja: ステートメントを閉じるトークンを処理する。

en: Handles the balancing of parentheses and blocks
ja: 丸括弧とブロックの両立の為の処理する。

en: whether or not the current statement's parentheses and blocks
    are balanced after +tk+
ja: 現在のステートメントの丸括弧とブロックが +tk+ の後で両立するかどうか。

en: Adds a token to the current statement,
    unless it's a newline, semicolon, or comment
ja: 現在のステートメントの為にトークンを追加する。
    ただし改行や、セミコロンや、コメントの場合を除く。

en: Returns the next token in the stream that's not a space
ja: スペースの無いストリームの中の次のトークンを返す。

en: the next non-space token
ja: スペースの無い次のトークン

en: a new instance of TokenList
ja: TokenListの新しいインスタンス

en: A list of tokens. If the token is a string, it
    is parsed with {RubyLex}.
ja: トークンのリスト。トークンが文字列の場合、{RubyLex}と共に解析される。

en: Returns the value of attribute ast
ja: ast属性の値を返す。

en: Returns the value of attribute charno
ja: charno属性の値を返す。

en: a new instance of RipperParser
ja: RipperParserの新しいインスタンス

en: Raised when an object is recognized but cannot be documented. This
    generally occurs when the Ruby syntax used to declare an object is
    too dynamic in nature.
ja: オブジェクトが認識される時に例外を上げる。
    しかし、記述される事はない。
    これは通常オブジェクトを宣言する為に
    使われたRuby構文が動的すぎる時に起る。

en: Raised when the parser sees a Ruby syntax error
ja: パーサーがRubyの構文のエラーを発見した時、例外を上げる。

en: the list of remaining files to parse
ja: 解析のための残りのファイルのリスト

en: a new instance of OrderedParser
ja: OrderedParserの新しいインスタンス

en: a structure containing all global
    state during parsing
ja: 解析中の全ての全体の状態を含んでいる構造体

en: Parses the remainder of the {#files} list.
ja: {#files} のリストの残りを解析する

en: Responsible for parsing a source file into the namespace. Parsing
    also invokes handlers to process the parsed statements and generate
    any code objects that may be recognized.
ja: namespaceの中のソースファイルを解析する為の責任がある。
    そして解析する事は、解析されるステートメントや
    認識されるかもしれないコードオブジェクトを生成する
    処理の為にハンドラーも起動する。

en: == Custom Parsers
    SourceParser allows custom parsers to be registered and called when
    a certain filetype is recognized. To register a parser and hook it
    up to a set of file extensions, call {register_parser_type}
ja: == カスタムパーサー
    ソースパーサーによってカスタムパーサーは
    明確にファイルタイプが認識される時に
    記録され呼び出される。
    パーサーを記録しファイル拡張子の設定をつなぐには、
    {register_parser_type}を呼び出す。

en: Byte order marks for various encodings
ja: 様々なエンコーディング用のバイトオーダーマーク

en: the default parser type (defaults to :ruby)
ja: デフォルトのパーサータイプ(デフォルト :ruby)

en: Parses a path or set of paths
ja: パスやパスの設定を解析する。

en: a list of excluded path matchers
ja: パスの照合を除外されるリスト。

en: a path, glob, or list of paths to
    parse
ja: パス,glob,解析の為のパスのリスト

en: tag|param|excluded
ja: excluded

en: tag|param|level
ja: level

en: tag|param|paths
ja: paths

en: the logger level to use during parsing. See
    {YARD::Logger}
ja: 解析される間、使用する為のloggerレベル。
    {YARD::Logger}参照。

en: Parses a string +content+
ja: +content+ の文字列を解析する。
    Parses a string +content+

en: tag|param|ptype
ja: ptype

en: the block of code to parse
ja: 解析する為のコードの入ったブロック。

en: the parser object that was used to parse +content+
ja: +content+ を解析する為に利用されるパーサーオブジェクト。

en: the parser type to use. See {parser_type}.
ja: 利用するパーサーの型。{parser_type}参照。

en: Tokenizes but does not parse the block of code
ja: トークナイズする。しかしコードの入ったブロックは解析しない。

en: a list of tokens
ja: トークンの入ったリスト。

en: the block of code to tokenize
ja: トークナイズする為のコードの入ったブロック。

en: Registers a new parser type.
ja: 新しいパーサーの型を記録する。

en: a class that implements parsing and tokenization
ja: 解析やトークナイズを実装するクラス。

en: a list of extensions or a
    regex to match against the file extension
ja: 拡張子のリストやファイル拡張子に対しマッチする正規表現。

en: a symbolic name for the parser type
ja: パーサー型用のシンボリック名。

en: tag|example|Registering a parser for "java" files
ja: "java"ファイル用にパーサーを記録する

en: tag|param|extensions
ja: extensions

en: tag|param|parser_klass
ja: parser_klass

en: a list of registered parser types
ja: パーサーの型が記録されるリスト。

en: Finds a parser type that is registered for the extension. If no
    type is found, the default Ruby type is returned.
ja: 拡張用の記録されるパーサーの型を見つける。
    型が見つからない無い場合、デフォルトのRuby型が返される。

en: the parser type to be used for the extension
ja: 拡張用に利用されるパーサーの型。

en: Returns the validated parser type. Basically, enforces that :ruby
    type is never set if the Ripper library is not available
ja: 有効なパーサー型を返す。
    基本的に、Ripperライブラリが利用不可の場合、
    :ruby型が設定されないよう実行される。

en: the parser type to set
ja: 設定するパーサーの型。

en: the validated parser type
ja: 有効なパーサーの型。

en: Registers a callback to be called before a list of files is parsed
    via {parse}. The block passed to this method will be called on
    subsequent parse calls.
ja: {parse} 経由でファイルのリストが解析される前に呼び出されるコールバックを記録する
    このメソッドに渡されるブロックはそれに続く、parse呼び出し上で呼び出される。

en: Parser Callbacks
ja: パーサーのコールバック

en: a global structure to store arbitrary
    state for post processing (see {Handlers::Processor#globals})
ja: 後処理用の任意の状態を格納する、globalなデータ(see {Handlers::Processor#globals})

en: if the block returns +false+, parsing is
    cancelled.
ja: ブロックが +false+ を返す場合、解析処理はキャンセルされる。

en: tag|example|Installing a simple callback
ja: 簡単なコールバックを実装する

en: tag|example|Setting global state
ja: globalの状態を設定する

en: tag|example|Using a global callback to cancel parsing
ja: 解析するのをキャンセルする為にコールバックにglobalを使う

en: tag|yieldparam|files
ja: files

en: tag|yieldparam|globals
ja: globals

en: the list of files that will be parsed.
ja: 解析されるファイルのリスト。

en: the yielded block
ja: yieldされるブロック。

en: the yielded block is called once before
    parsing all files
ja: yieldされたブロックは
    全てのファイルを解析する前に一度だけ呼び出される。

en: Registers a callback to be called after a list of files is parsed
    via {parse}. The block passed to this method will be called on
    subsequent parse calls.
ja: ファイルのリストが {parse} 経由で解析された後で呼び出される為にコールバックを記録する。
    このメソッドの為に渡されるブロックはその後のparse呼び出し上で呼び出される。

en: tag|example|Printing results after parsing occurs
ja: 解析が終わった後で、結果をプリントする。

en: the return value for the block is ignored.
ja: ブロックが無視される為の戻り値

en: Registers a callback to be called before an individual file is parsed.
    The block passed to this method will be called on subsequent parse
    calls.
ja: 個々のファイルが解析される前に呼び出されるコールバックを記録する
    blockはこのメソッドが続くparse呼び出しで呼び出されるために解析される。

en: To register a callback that is called before the entire list of files
    is processed, see {before_parse_list}.
ja: 全てのファイルのリストが処理される前に呼び出される
    コールバックを記録する為には、{before_parse_list}参照。

en: if the block returns +false+, parsing for
    the file is cancelled.
ja: ブロックが +false+ を返す場合、
    ファイルがキャンセルされる為に解析する。

en: tag|example|Cancel parsing of any test_*.rb files
ja: 全てのtest_*.rbファイルの解析をキャンセルする

en: the parser object that will {#parse}
    the file.
ja: ファイルを{#parse}メソッドで解析するパーサーオブジェクト。

en: the yielded block is called once before each
    file that is parsed. This might happen many times for a single
    codebase.
ja: yieldされるブロックは、それぞれのファイルが解析される前に一度呼び出される。
    これは、単一のコードベースでは何回も起きる可能性がある。

en: Registers a callback to be called after an individual file is parsed.
    The block passed to this method will be called on subsequent parse
    calls.
ja: 個々のファイルが解析された後で呼び出されるコールバックを登録する。
    このメソッドに渡されたブロックは次のparseメソッドの呼び出しで呼び出される。

en: To register a callback that is called after the entire list of files
    is processed, see {after_parse_list}.
ja: ファイルリストが全て処理された後で呼び出される。
    コールバックを記録するには、{after_parse_list}参照。

en: tag|example|Printing the length of each file after it is parsed
ja: tag|example|解析された後でそれぞれのファイルのサイズをプリントする

en: the parser object that parsed
    the file.
ja: ファイルを解析した、パーサーオブジェクト。

en: the yielded block is called once after each file
    that is parsed. This might happen many times for a single codebase.
ja: yieldされたブロックは解析される個々のファイルの後で一度呼び出される。
    これは単一のコードベースの為に何回も起る可能性がある。

en: the list of callbacks to be called before
    parsing a list of files. Should only be used for testing.
ja: ファイルのリストを解析する前に呼び出されるコールバックのリスト。
    検査用にだけ利用されるべきである。

en: the list of callbacks to be called after
    parsing a list of files. Should only be used for testing.
ja: ファイルのリストを解析する前に呼び出される為のコールバックのリスト。
    検査用にだけ利用されるべきである。

en: the list of callbacks to be called before
    parsing a file. Should only be used for testing.
ja: ファイルが解析する前に呼び出される為のコールバックのリスト。
    検査用にだけ利用されるべきである。

en: the list of callbacks to be called after
    parsing a file. Should only be used for testing.
ja: ファイルが解析する前に呼び出される為のコールバックのリスト。
    検査用にだけ利用されるべきである。

en: Parses a list of files in a queue.
ja: キューのなかのファイルのリストを解析する

en: a list of files to queue for parsing
ja: 解析用のキューの為のファイルのリスト。

en: the filename being parsed by the parser.
ja: パーサーによって解析されているファイル名。

en: the parser type associated with the parser instance.
    This should be set by the {#initialize constructor}.
ja: パーサーのインスタンスと共に関連付られるパーサーの型。
    これは、{#initialize constructor}メソッドによって設定されるべきである。

en: an open struct containing arbitrary global state
    shared between files and handlers.
ja: ファイルとハンドラーとの間で共有される
    任意のグローバルな状態を含んでいるOpenStruct

en: the contents of the file to be parsed
ja: 解析されるファイルの内容。

en: a new instance of SourceParser
ja: ソースパーサーの新しいインスタンス。

en: The main parser method. This should not be called directly. Instead,
    use the class methods {parse} and {parse_string}.
ja: 主なパーサーメソッド。これは直接呼ばれるべきではない。
    代わりに、{parse}や{parse_string}クラスメソッドを利用する。

en: the parser object used to parse the source
ja: ソースを解析する為に利用されるパーサーオブジェクト。

en: the source file to parse
ja: 解析の為のソースファイル。

en: Tokenizes but does not parse the block of code using the current {#parser_type}
ja: トークナイズする。しかし、
    現在の{#parser_type}メソッドを使用して、コードの入ったブロックは解析しない。

en: Searches for encoding line and forces encoding
ja: エンコーディング行を検索し、エンコーディングを強制する。

en: Runs a {Handlers::Processor} object to post process the parsed statements.
ja: 解析したステートメントの後処理の為に、{Handlers::Processor}オブジェクトを起動する。

en: Guesses the parser type to use depending on the file extension.
ja: ファイル拡張子に応じて使用するパーサーの型を推測する。

en: a parser type that matches the filename
ja: ファイル名の拡張子に応じたパーサータイプ。

en: the filename to use to guess the parser type
ja: パーサー型を推測する為に利用するファイル名。

en: The rake task to run {CLI::Yardoc} and generate documentation.
ja: {CLI::Yardoc}を起動する為のrake taskとなり、ドキュメントを生成する。

en: The name of the task
ja: taskの名前

en: the task name
ja: task名

en: Options to pass to {CLI::Yardoc}
ja: {CLI::Yardoc}の為のパスの設定

en: the options passed to the commandline utility
ja: コマンドライン用途の為に渡される設定

en: The Ruby source files (and any extra documentation files separated by '-')
    to process.
ja: 処理の為のRubyソースファイル(と'-'によって分割された、任意の特別なドキュメントファイル)

en: tag|example|Task files assignment
ja: Taskのファイルを代入する

en: Runs a +Proc+ before the task
ja: taskの前に +Proc+ を起動する。

en: a proc to call before running the task
ja: task を起動する前に、呼び出される,proc

en: Runs a +Proc+ after the task
ja: taskの後で起動する +Proc+

en: a proc to call after running the task
ja: taskを起動した後で呼び出される,proc

en: an optional {Verifier} to run against all objects
    being generated. Any object that the verifier returns false for will be
    excluded from documentation. This attribute can also be a lambda.
ja: 全てのオブジェクトに対して起動するための任意の {Verifier}(認証者)
    verifierがドキュメントから除外される為のfalseを返す任意のオブジェクト
    この属性はlmbdaにもできる。

en: Creates a new task with name +name+.
ja: +name+ 名を用いる新しいタスクを作成する

en: a block to allow any options to be modified on the task
ja: task上で変更される為に任意のオプションを受け入れる,block

en: a new instance of YardocTask
ja: YardocTaskの新しいインスタンス

en: the name of the rake task
ja: rake taskの名前

en: the task object to allow any parameters
    to be changed.
ja: 変更される任意のパラメータを受け入れるtask オブジェクト

en: Defines the rake task
ja: rake taskを定義する。

en: The +Registry+ is the centralized data store for all {CodeObjects} created
    during parsing. The storage is a key value store with the object's path
    (see {CodeObjects::Base#path}) as the key and the object itself as the value.
    Object paths must be unique to be stored in the Registry. All lookups for
    objects are done on the singleton Registry instance using the {Registry.at}
    or {Registry.resolve} methods.
ja: +Registry+ は解析している間に、
    全ての{CodeObjects}が作成される為の
    集中データストアとなる。
    ストレージは、
    キーのようなオブジェクトパス(see {CodeObjects::Base#path})と
    値のようなオブジェクトを用い、key valueストアとなる。
    オブジェクトパスは、Registryの中で記録される為に固有でなければならない。
    オブジェクト用の全ての検索は、
    {Registry.at} や {Registry.resolve}メソッドによって
    シングルトンレジストリインスタンスの上で行われる。

en: == Saving / Loading a Registry
    The registry is saved to a "yardoc file" (actually a directory), which can
    be loaded back to perform any lookups. See {Registry.load!} and
    {Registry.save} for information on saving and loading of a yardoc file.
ja: == レジストリーをセーブ/ロードする
    レジストリーは"yardoc file"(実際はディレクトリ)にセーブされ、
    任意の検索を実行する為に、ロードできる。
    yardocファイルのセーブやロードの情報は、
    {Registry.load!} , {Registry.save}を参照。

en: == Threading Notes
    The registry class is a singleton class that is accessed directly in many
    places across YARD. To mitigate threading issues, YARD (0.6.5+) makes
    the Registry thread local. This means all access to a registry for a specific
    object set must occur in the originating thread.
ja: == スレッドの注意
    レジストリークラスは、YARD全体で直接アクセスされるシングルトンクラスとなる。
    スレッドの問題を緩和するには、YARD(0.6.5+)でthread localなレジストリーを作る。
    これはスレッドの中で固有のオブジェクトのグループが生成される、
    レジストリーにアクセスする全てのものを意味する。

en: tag|example|Getting an object by a specific path
ja: tag|example|パスによってオブジェクトを取得する

en: tag|example|Loading the Registry
ja: tag|example|レジストリーをロードする

en: tag|example|Performing a lookup on a method anywhere in the inheritance tree
ja: tag|example|継承ツリーのどこでもメソッドで検索を実行する

en: Returns the .yardoc file associated with a gem.
ja: gemと共に関連した.yardocファイルを返す。

en: Getting .yardoc File Locations
ja: .yardocファイルの場所を取得する。

en: an optional Gem version requirement
ja: 任意のGemのバージョン要求

en: if +for_writing+ is set to +true+, returns the best
    location suitable to write the .yardoc file. Otherwise, the first
    existing location associated with the gem's .yardoc file.
ja: +for_writing+ にtrueをセットした場合、
    .yardocファイルを書き込む為に最適な場所を返す。
    若しくは、.yardocファイルに関連づけられた
    既存の場所になる。

en: if +for_writing+ is set to false and no yardoc file
    is found, returns nil.
ja: +for_writing+ がfalseを設定する場合と、
    yardocファイルが見つからない場合は、nilを返す。

en: the name of the gem to search for
ja: 検索するgemの名前

en: whether or not the method should search
    for writable locations
ja: メソッドが書き込み可能な場所を検索するかどうか

en: Gets/sets the yardoc filename
ja: yardocのファイル名を取得/設定する。

en: the yardoc filename
ja: yardocのファイル名

en: Loads the registry and/or parses a list of files
ja: レジストリのロードやファイルのリストを解析する

en: Loading Data from Disk
ja: ディスクから、データをロードする

en: if +files+ is an Array, it should represent
    a list of files that YARD should parse into the registry. If reload is
    set to false and the yardoc file already exists, these files are skipped.
    If files is a String, it should represent the yardoc file to load
    into the registry.
ja: +files+が配列の場合、YARDがレジストリーの中を解析するべきファイルのリストを表す。
    reloadがfalseを設定された場合や、yardocファイルが既に存在する場合、
    これらのファイルは、スキップされる。
    ファイルがStringの場合、
    レジストリーの中へロードするyardocファイルを表す。

en: if files is not a String or Array
ja: ファイルがStringやArrayでない場合

en: if reparse is false and a yardoc file already
    exists, any files passed in will be ignored.
ja: reparseがfalseの場合や、yardocファイルが既に存在する場合、
    オプションの解析されるファイルは、無視される。

en: tag|example|Loads the yardoc file or parses files 'a', 'b' and 'c' (but not both)
ja: yardocファイルをロードする。又は、'a','b','c'のファイルを解析する。(どちらかだけ行う)

en: tag|example|Reparses files 'a' and 'b' regardless of whether yardoc file exists
ja: yardocファイルが存在するかどうかにかかわらず、ファイル'a'と'b'を再解析する。

en: the registry object (for chaining)
ja: レジストリオブジェクト(チェーン用)

en: Loads a yardoc file directly
ja: 直接yardocファイルをロードする

en: the yardoc file to load.
ja: ロードするyardocファイル

en: Loads a yardoc file and forces all objects cached on disk into
    memory. Equivalent to calling {load_yardoc} followed by {load_all}
ja: yardocファイルをロードし、
    メモリの中へディスク上の全てのキャッシュされるオブジェクトを強制する。
    {load_all}に続いて呼び出す{load_yardoc}と同等である。

en: the yardoc file to load
ja: ロードするyardocファイル

en: Forces all objects cached on disk into memory
ja: メモリの中へディスク上のキャッシュされる全てのオブジェクトを強制する

en: tag|example|Loads all objects from disk
ja: ディスクから全てのオブジェクトをロードする

en: Saves the registry to +file+
ja: +file+ をレジストリーにセーブする

en: Saving and Deleting Data from Disk
ja: ディスクからデータをセーブ/削除する。

en: the yardoc file to save to
ja: セーブされるyardocファイル

en: true if the file was saved
ja: ファイルがセーブされた場合、trueを返す

en: Deletes the yardoc file from disk
ja: ディスクからyardocファイルを削除する

en: Registers a new object with the registry
ja: リジストリを用い新しいオブジェクトを記録する

en: Adding and Deleting Objects from the Registry
ja: レジストリから、オブジェクトを追加,削除する。

en: the registered object
ja: 記録されたオブジェクト

en: Deletes an object from the registry
ja: レジストリーから、オブジェクトを削除する

en: the object to remove
ja: 削除するオブジェクト

en: Clears the registry
ja: レジストリーを空にする

en: Accessing Objects in the Registry
ja: レジストリーの中でオブジェクトにアクセスする

en: Iterates over {all} with no arguments
ja: 引数無しで{all}を繰り返す。

en: Returns all objects in the registry that match one of the types provided
    in the +types+ list (if +types+ is provided).
ja: +types+ リスト(タイプが供給される場合 )
    供給される型の一つにマッチするレジストリーの中でオブジェクトの全てを返す

en: an optional list of types to narrow the
    objects down by. Equivalent to performing a select:
      +Registry.all.select {|o| types.include(o.type) }+
ja: 任意の型のリストを絞り込む。次の選択と同様である。
      +Registry.all.select {|o| types.include(o.type) }+

en: tag|example|Returns all classes and modules
ja: 全てのクラスとモジュールを返す

en: tag|example|Returns all objects
ja: 全てのオブジェクトを返す

en: the list of objects found
ja: オブジェクトのリストをみつける

en: Returns the paths of all of the objects in the registry.
ja: レジストリーの中の全てのオブジェクトのパスを返す

en: all of the paths in the registry.
ja: レジストリーの中のパスの全て

en: whether to load entire database
ja: データベース全体をロードするかどうか

en: Returns the object at a specific path.
ja: 固有のパスでオブジェクトを返す

en: the object at path
ja: パスのオブジェクト

en: the pathname to look for. If +path+ is +root+,
    returns the {root} object.
ja: 検索の為のパス名、 +path+ が +root+ の場合
    {root}を返す。

en: The root namespace object.
ja: rootは名前空間オブジェクトとなる

en: the root object in the namespace
ja: namespaceの中のrootオブジェクト

en: Attempts to find an object by name starting at +namespace+, performing
    a lookup similar to Ruby's method of resolving a constant in a namespace.
ja: +namespace+ でnameで始まるオブジェクトが見つかるか試みる
    namespaceの中で定数を解決するのに、Rubyメソッドと同様に検索を実行する。

en: Follows inheritance chain (mixins, superclass)
    when performing name resolution if set to +true+.
ja: +true+が設定された時、名前解決を実行する、継承のチェーン(mixin,superクラス)

en: If +true+, returns a proxy representing
    the unresolved path (namespace + name) if no object is found.
ja: +true+の場合やオブジェクトが見つからなかった場合、
    未解決のパス(namespace + name)を表すproxyを返す。

en: a Proxy representing the object if
    +proxy_fallback+ is +true+.
ja: +proxy_fallback+ が +true+の場合、オブジェクトを表すproxyとなる。

en: if +proxy_fallback+ is +false+ and no object was found.
ja: +proxy_fallback+ が +false+ 又は、オブジェクトが見つからなかった場合

en: tag|example|Looks for a class method respecting the inheritance tree
ja: 関連する継承ツリーのクラスメソッドを探す

en: tag|example|Looks for a complex path from a namespace
ja: namespaceから複雑なパスを検索する

en: tag|example|Looks for a constant but returns a proxy if not found
ja: 定数を探すが、見つからない場合は、proxyを返す。

en: tag|example|Looks for a constant in the root namespace
ja: root namespaseの中の定数をを探す

en: tag|example|Looks for instance method #reverse starting from A::B::C
ja: A::B::Cで始まる、インスタンスメソッド#reverseを探す

en: tag|param|inheritance
ja: 継承

en: the name (or complex path) to look for from
    +namespace+.
ja: +namespace+ から検索する名前(や複雑なパス)

en: the object if it is found
ja: 見つかったオブジェクト

en: the starting namespace
    (module or class). If +nil+ or +:root+, starts from the {root} object.
ja: 始まりのnamespace(モジュールやクラス)。
    +nil+ や +:root+ の場合、{root}オブジェクトから始まる。

en: Managing Source File Checksums
ja: ソースファイルチェックサムを管理する

en: a set of checksums for files
ja: ファイル用のチェックサムのグループ

en: data to checksum
ja: チェックサムするデータ

en: the SHA1 checksum for data
ja: データのSHA1チェックサム

en: Whether or not the Registry storage should load everything into a
    single object database (for disk efficiency), or spread them out
    (for load time efficiency).
ja: レジストリーストレージは単一のオブジェクトのデータベースの中へ
    毎回ロードするか、(ディスク効率の為)
    又は、データベースを展開する。(ロード時間効率の為)

en: Managing Internal State (Advanced / Testing Only)
ja: 内部の状態を管理する(Advanced / Testing Only)

en: Setting this attribute to nil will offload the decision to
    the {RegistryStore storage adapter}.
ja: この属性にnilを設定すると、{RegistryStore storage adapter}の決定をunloadする。

en: if this value is set to nil, the storage
    adapter will decide how to store the data.
ja: この値にnilを設定した場合、
    ストレージアダプターがデータを記録する方法を決める。

en: The assumed types of a list of paths. This method is used by CodeObjects::Base
ja: パスのリストの想定される型。このメソッドはCodeObjects::Baseによって利用される。

en: a set of unresolved paths and their assumed type
ja: 未解決のパスのグループやその想定される型

en: The registry singleton instance.
ja: レジストリーのシングルトンインスタンス

en: returns the registry instance
ja: レジストリーインスタンスを返す

en: use Registry.methodname directly.
ja: 直接Registry.methodnameを使う

en: Attempts to resolve a name in a namespace
ja: namespaceの中で名前の解決を試みる

en: the name to look for
ja: 検索するname

en: the starting namespace
ja: 始まりのnamespace

en: Retrieving yardoc File Locations
ja: yardocファイルの場所を取り出す

en: Threading support
ja: スレッドをサポート

en: The data store for the {Registry}.
ja: {Registry}用のデータストア

en: The registry no longer tracks proxy types
ja: レジストリはプロキシタイプの追跡をしない

en: Returns the value of attribute checksums
ja: checksums属性の値を返す

en: a new instance of RegistryStore
ja: RegistryStoreの新しいインスタンス

en: Gets a {CodeObjects::Base} from the store
ja: 記録から{CodeObjects::Base}を取得する

en: a code object or nil if none is found
ja: コードオブジェクトか見つからない場合はnilを返す

en: the path name of the object to look for.
    If it is empty or :root, returns the {#root} object.
ja: 検索の為のオブジェクトのパス名。
    空か:rootの場合、{#root}オブジェクトを返す。

en: Associates an object with a path
ja: パスと一緒にオブジェクトを関連付ける。

en: returns +value+
ja: +value+ を返す

en: the object to store
ja: 記録するオブジェクト

en: the path name (:root or '' for root object)
ja: パス名(:rootやrootオブジェクト用の'')

en: Deletes an object at a given path
ja: 与えられたパスでオブジェクトを削除する

en: Gets all path names from the store. Loads the entire database
    if +reload+ is +true+
ja: 記録から全てのパス名を取得する。
    +reload+ が +true+ の場合、全体のデータベースをロードする。

en: if false, does not load the entire database
    before a lookup.
ja: falseの場合、検索の前に全体のデータベースをロードしない

en: the path names of all the code objects
ja: 全てのコードオブジェクトのパス名

en: Gets all code objects from the store. Loads the entire database
    if +reload+ is +true+
ja: 記録から全てのパス名を取得する。
    +reload+ が +true+ の場合、全体のデータベースをロードする。

en: all the code objects
ja: 全てのコードオブジェクト

en: the type to look for
ja: 型用に検索する型

en: the root object
ja: rootオブジェクト

en: the name of the yardoc db to load
ja: ロードするyardoc dbの名前

en: whether the database was loaded
ja: データベースがロードされたかどうか

en: Loads the .yardoc file and loads all cached objects into memory
    automatically.
ja: .yardocファイルをロードしたり、
    全てのキャッシュされたオブジェクトを自動的にメモリの中へロードする。

en: Loads all cached objects into memory
ja: メモリの中へ全てのキャッシュされたオブジェクトをロードする

en: Saves the database to disk
ja: ディスクにデータベースをセーブする

en: if supplied, the name of the file to save to
ja: 指定された場合、セーブするファイルの名前となる

en: if true, merges the data in memory with the
    data on disk, otherwise the data on disk is deleted.
ja: trueの場合、ディスク上のデータと共にメモリの中のデータをマージする。
    そうでなければ、ディスク上のデータは削除される。

en: whether the database was saved
ja: データベースがセーブされるかどうか

en: Deletes the .yardoc database on disk
ja: ディスク上のデータベースの.yardocの削除

en: if force is not set to true, the file/directory
    will only be removed if it ends with .yardoc. This helps with
    cases where the directory might have been named incorrectly.
ja: forceにtrueが設定されず、そのファイルの末尾に.yardocが付く場合、
    ファイル/ディレクトリは削除される。
    これは、ディレクトリが間違って名付けられた場合、役立つだろう。

en: true if the .yardoc database was deleted, false
    otherwise.
ja: .yardocデータベースが削除された場合、true。
    それ以外はfalse。

en: The abstract base serializer. Serializers allow templates to be
    rendered to various endpoints. For instance, a {FileSystemSerializer}
    would allow template contents to be written to the filesystem
ja: これは抽象的なベースのシリアライザとなる。
    シリアライザは、様々なエンドポイントで表示される
    テンプレートを受け入れる。
    例えば、{FileSystemSerializer}は、
    ファイルシステムに書かれる内容のテンプレートを受け入れる。

en: To implement a custom serializer, override the following methods:
    * {#serialize}
    * {#serialized_path}
ja: カスタムシリアライザを実装するには、次のメソッドを上書きする。:
    * {#serialize}
    * {#serialized_path}

en: Optionally, a serializer can implement before and after filters:
    * {#before_serialize}
    * {#after_serialize}
ja: 任意で、シリアライザはフィルターの前後に実装できる。:
    * {#before_serialize}
    * {#after_serialize}

en: Override this class to implement a custom serializer.
ja: カスタムシリアライザを実装する為に、このクラスを上書きする。

en: All serializer options are saved so they can be passed to other serializers.
ja: 全てのシリアライザのオプションはセーブされるので、他のシリアライザに渡す事が出来る。

en: the serializer options
ja: シリアライザのオプション

en: Creates a new serializer with options
ja: オプションと共に新しいシリアライザを作成する。

en: Creating a New Serializer
ja: 新しいシリアライザを作成する。

en: the options to assign to {#options}
ja: {#options}メソッドに割り当てるオプション

en: Serializes an object.
ja: シリアライズするオブジェクト

en: Serializing an Object
ja: シリアライズするオブジェクト

en: This method should implement the logic that serializes
    +data+ to the respective endpoint. This method should also call
    the before and after callbacks {#before_serialize} and {#after_serialize}
ja: このメソッドはそれぞれのエンドポイントに +data+ をシリアライズするロジックを
    実装するべきである。
    また、このメソッドは前後に{#before_serialize} と {#after_serialize}の
    コールバックも呼び出すべきである。

en: the contents that should be serialized
ja: シリアライズされるべき内容

en: the object to serialize the
    data for. The object can also be a string (for non-object serialization)
ja: オブジェクトのデータをシリアライズするオブジェクト、
    このオブジェクトは文字列にもできる。(非オブジェクトをシリアライズする場合)

en: The serialized path of an object
ja: シリアライズされるオブジェクトのパス

en: This method should return the path of the object on the
    endpoint. For instance, for a file serializer, this should return
    the filename that represents the object on disk.
ja: このメソッドは、エンドポイント上のオブジェクトのパスを返す。
    例えば、ファイルシリアライザは、ディスクの中のそのオブジェクトを表すファイル名を返す。

en: the object to return a path for
ja: パスを返す為のオブジェクト

en: the serialized path of an object
ja: シリアライズされたオブジェクトのパス

en: Returns whether an object has been serialized
ja: シリアライズされたオブジェクトかどうかを返す

en: This method should return whether the endpoint already exists.
    For instance, a file system serializer would check if the file exists
    on disk. You will most likely use +#basepath+ and {#serialized_path} to
    get the endpoint's location.
ja: このメソッドは既にエンドポイントが存在するかどうかを返す。
    例えば、ファイルがディスク上に存在する場合、
    ファイルシステムシリアライザは、このチェックを行うだろう。
    あなたは、恐らくエンドポイントの場所を取得する為に、
    +#basepath+ や {#serialized_path} メソッドを使うだろう。

en: the object to check existence of
ja: 存在するかチェックするオブジェクト

en: whether the endpoint exists.
ja: エンドポイントが存在するかどうか

en: Called before serialization.
ja: シリアライズする前に呼び出される

en: Should run code before serialization. Should return false
    if serialization should not occur.
ja: シリアライズする前にコードを起動する。
    シリアライズしても何も存在しない場合、falseを返す。

en: whether or not serialization should occur
ja: シリアライズが存在するかどうか

en: Called after serialization.
ja: 後で呼び出されるシリアライズ

en: Should run code after serialization.
ja: 後でシリアライズのコードを起動する

en: the data that was serialized.
ja: シリアライズされたデータ

en: Implements a serializer that reads from and writes to the filesystem.
ja: ファイルシステムに読み書き込みするシリアライザを実装する。

en: The base path to write data to.
ja: データに書き込む為のベースパス

en: a base path
ja: ベースパス

en: The extension of the filename (defaults to +html+)
ja: ファイル名の拡張子(デフォルトは +html+ )

en: the extension of the file. Empty string for no extension.
ja: ファイルの拡張子。拡張子無しは空文字

en: Creates a new FileSystemSerializer with options
ja: オプションと共に、新しいFileSystemSerializerを作成する。

en: a new instance of FileSystemSerializer
ja: FileSystemSerializerの新しいインスタンス

en: Serializes object with data to its serialized path (prefixed by the +#basepath+).
ja: パス(+#basepath+ がプレフィックスされる)をシリアライズする為、
    データと共に、オブジェクトをシリアライズする。

en: the written data (for chaining)
ja: 書き込まれるデータ(チェーン用)

en: Implements the serialized path of a code object.
ja: コードオブジェクトのシリアライズされるパスを実装する。

en: if object is a String, returns
    object, otherwise the path on disk (without the basepath).
ja: オブジェクトがStringの場合、オブジェクトを返し、
    それ以外は、ディスク上のパスを返す。(basepathを含まない)

en: the object to get a path for. The path of a string is the string itself.
ja: パスを取得する為のオブジェクト。文字列のパスはその文字列自身を返す。

en: Checks the disk for an object and returns whether it was serialized.
ja: オブジェクト用にディスクをチェックしたり、シリアライズされたかどうか返す。

en: the object to check
ja: チェックするオブジェクト

en: whether an object has been serialized to disk
ja: オブジェクトが既にディスクにシリアライズされているかどうか

en: Serializes an object to a process (like less)
ja: 処理の為のオブジェクトをシリアライズする。(lessのような)

en: tag|example|Serializing to a pager (less)
ja: ページャーをシリアライズする(less)

en: Creates a new ProcessSerializer for the shell command +cmd+
ja: シェルコマンド +cmd+ 用に新しいProcessSerializerを作成する。

en: a new instance of ProcessSerializer
ja: ProcessSerializerの新しいインスタンス

en: the command that will accept data on stdin
ja: 標準入力上でデータを受け入れるコマンド

en: Overrides serialize behaviour and writes data to standard input
    of the associated command
ja: シリアライズの挙動を上書きし、
    関連付けられたコマンドの標準入力にデータを書き込む。

en: A serializer that writes data to standard output.
ja: 標準出力にデータを書くシリアライザ

en: Creates a serializer to print text to stdout
ja: 標準出力にテキストをプリントするシリアライザを作成する。

en: a new instance of StdoutSerializer
ja: StdoutSerializerの新しいインスタンス

en: if wrap is a number, wraps text to +wrap+
    columns, otherwise no wrapping is done.
ja: wrapが数字の場合、+wrap+ カラムにテキストをラップする。
    それ以外では、ラップは行わない。

en: Overrides serialize behaviour to write data to standard output
ja: 標準出力にデータを書き込む為にシリアライズの挙動を上書きする。

en: Wraps text to a specific column length
ja: 特定のカラムの長さにテキストをラップする。

en: the column length to wrap to
ja: ラップの為のカラムの長さ

en: the text to wrap
ja: ラップされるテキスト

en: the wrapped text
ja: ラップされたテキスト

en: Stubs marshal dumps and acts a delegate class for an object by path
ja: 引抜き、選別し、出力する。オブジェクトがパスによって委譲クラスのように振る舞う

en: a new instance of StubProxy
ja: StubProxyの新しいインスタンス

en: a new instance of YardocSerializer
ja: YardocSerializerの新しいインスタンス

en: Registers a static path to be used in static asset lookup.
ja: 静的な資源の検索の中で利用される静的パスを記録する。

en: the pathname to register
ja: 記録する為のパス名

en: Short circuits a request by raising an error. This exception is caught
    by {Commands::Base#call} to immediately end a request and return a response.
ja: エラーを上げることによってリクエストを省く。
    この例外はすぐに、リクエストの終了とレスポンスを返す為に
    {Commands::Base#call} によってキャッチされる。

en: Raises an error if a resource is not found. This exception is caught by
    {Commands::Base#call} to immediately end a request and return a 404 response
    code. If a message is provided, the body is set to the exception message.
ja: リソースが見つからない場合、エラーを上げる。
    この例外は、すぐにリクエストの終りと404レスポンスコードを返す為に
    {Commands::Base#call}によってキャッチされる。
    メッセージが提供される場合、本体に、例外メッサージが設定される。

en: This class implements the bridge between the {Router} and the server
    backend for a specific server type. YARD implements concrete adapters
    for WEBrick and Rack respectively, though other adapters can be made
    for other server architectures.
ja: このクラスは {Router} と固有のサーバータイプ用にサーバーバックエンドの間の
    ブリッジを実装する。
    YARDはWEBrickとRackそれぞれに
    具体的なアダプターを実装するけれども、
    他のアダプターを、他のサーバーアーキテクチャ用に作る事も出来る。

en: == Subclassing Notes
    To create a concrete adapter class, implement the {#start} method to
    initiate the server backend.
ja: == サブクラス化する注意
    具体的なアダプタークラスを作成するには、
    サーバーバックエンドを開始する為に{#start}メソッドを実装する。

en: the location where static files are located, if any.
    To set this field on initialization, pass +:DocumentRoot+ to the
    +server_opts+ argument in {#initialize}
ja: 任意で、スタティックファイルが示される場所。
    初期にこのフィールドを設定するには、
    {#initialize}メソッドの中の +server_opts+ 引数に
    +:DocumentRoot+ を渡す。

en: a map of libraries.
ja: ライブラリのマップ

en: options passed and processed by adapters. The actual
    options mostly depend on the adapters themselves.
ja: アダプターによって渡され、処理されたoptions。
    実際のoptionsの大抵は、アダプター自身に依存する。

en: a set of options to pass to the server backend. Note
    that +:DocumentRoot+ also sets the {#document_root}.
ja: サーバーのバックエンドに渡す為のoptionsのグループ
    次の事に留意する。 +:DocumentRoot+ は {#document_root} にも設定する。

en: the router object used to route URLs to commands
ja: コマンドにURLを送る為に利用された、routerオブジェクト

en: Performs any global initialization for the adapter.
ja: アダプター用に任意で全体の初期化を実行する。

en: If you subclass this method, make sure to call +super+.
ja: あなたがこのメソッドをサブクラス化する場合、
    +super+ を呼び出すか確認する事。

en: Performs any global shutdown procedures for the adapter.
ja: 任意で全体的なアダプター用の手続きのシャットダウンを実行する。

en: Creates a new adapter object
ja: 新しいアダプターオブジェクトを作成する。

en: a list of libraries,
    see {#libraries} for formulating this list.
ja: ライブラリのリスト、
    このリストを公式化する為には、{#librathries}を参照。

en: a new instance of Adapter
ja: アダプターの新しいインスタンス

en: extra options to pass to the adapter
ja: アダプターに渡す為の追加のoptions

en: Adds a library to the {#libraries} mapping for a given library object.
ja: 与えられたライブラリオブジェクト用の{#libraries}マッピングにライブラリを追加する。

en: a library to add
ja: 追加する為のライブラリ

en: tag|example|Adding a new library to an adapter
ja: アダプターに新しいライブラリを追加する。

en: Implement this method to connect your adapter to your server.
ja: あなたのサーバーにあなたのアダプターを接続する為に、このメソッドを実装する。

en: This is the base command class used to implement custom commands for
    a server. A command will be routed to by the {Router} class and return
    a Rack-style response.
ja: これは、サーバー用にカスタムコマンドを実装する為に、
    利用されるベースコマンドクラスである。
    コマンドは、{Router}クラスによって送られ、Rackスタイルのレスポンスを返す。

en: == Attribute Initializers
    All attributes can be initialized via options passed into the {#initialize}
    method. When creating a custom command, the {Adapter#options} will
    automatically be mapped to attributes by the same name on your class.
ja: == 初期化子の属性
    全ての属性は、{#initialize}メソッドへ渡されたoptions経由でイニシャライズされる。
    カスタムメソッドが作成される時、{Adapter#options}メソッドは、
    あなたのクラスの属性と同じ名前で自動的にマッピングされるだろう。

en: == Subclassing Notes
    To implement a custom command, override the {#run} method, not {#call}.
    In your implementation, you should set the body and status for requests.
    See details in the +#run+ method documentation.
ja: == サブクラス化する時の注意
    カスタムコマンドを実装するには、{#run}メソッドを上書きする({#call}メソッドではない)。
    あなたの実装で、あなたがボディと、リクエスト用のステータスを設定するべきである。
    詳細は +#run+ メソッドのドキュメントを参照。

en: Note that if your command deals directly with libraries, you should
    consider subclassing the more specific {LibraryCommand} class instead.
ja: 次の事に留意する。あなたのコマンドが
    直接ライブラリを用い処理する場合、代わりに、
    サブクラス化する{LibraryCommand}クラスの詳細を考慮するべきである。

en: Basic Command and Adapter Options
ja: 基本的なコマンドとアダプターオプション

en: the options passed to the command's constructor
ja: コマンドのコンストラクタに渡されたoptions

en: the server adapter
ja: サーバーアダプター

en: whether to cache
ja: キャッシュするかどうか

en: Attributes Set Per Request
ja: リクエスト毎のグループを属性化する。

en: request object
ja: オブジェクトのリクエスト

en: the path after the command base URI
ja: コマンドのベースURIの後で返す、パス

en: response headers
ja: ヘッダーのレスポンス

en: status code. Defaults to 200 per request
ja: コードの状態。デフォルトで200リクエスト毎。

en: the response body. Defaults to empty string.
ja: ボディのレスポンス。デフォルトでは空の文字列になる。

en: Creates a new command object, setting attributes named by keys
    in the options hash. After initialization, the options hash
    is saved in {#command_options} for further inspection.
ja: 新しいコマンドオブジェクトを作成し、
    ハッシュオプションのキーによって、名付けられた属性をセッティングする。
    イニシャライズの後でハッシュのオプションは、
    調査を進める為に{#command_options}メソッドの中でセーブされる。

en: Instance Method Summary
ja: インスタンスメソッドの概要

en: tag|example|Creating a Command
ja: コマンドを作成する

en: the options hash, saved to {#command_options}
    after initialization.
ja: ハッシュのオプション、イニシャライズされた後で、
    {#command_options}にセーブされる。

en: The main method called by a router with a request object.
ja: 主なメソッドは、requestオブジェクトを用い
    routerによって呼び出される。

en: This command should not be overridden by subclasses. Implement
    the callback method {#run} instead.
ja: このコマンドは、サブクラスによって上書きされるべきではない、
    代わりにコールバックの{#run}メソッドを実装する。

en: a Rack-style response
    of status, headers, and body wrapped in an array.
ja: 配列でラップされた
    Rackスタイルのステータス、ヘッダー、ボディのレスポンス

en: the request object
ja: リクエストするオブジェクト

en: Subclass this method to implement a custom command. This method
    should set the {#status} and {#body}, and optionally modify the
    {#headers}. Note that +#status+ defaults to 200.
ja: カスタムコマンドを実装する為にこのメソッドをサブクラス化する。
    このメソッドは、{#status}と{#body}を設定するべきで、
    任意で、{#headers}を変更する。
    留意する事として、 +#status+ はデフォルトで200になる。

en: Abstract Methods
ja: 抽象メソッド

en: tag|example|A custom command
ja: カスタムコマンド

en: Renders a specific object if provided, or a regular template rendering
    if object is not provided.
ja: 提供された場合、特定のオブジェクトを表示するか、
    オブジェクトが提供されない場合、規定のテンプレートが表示される。

en: Helper Methods
ja: ヘルパーメソッド

en: This method is dependent on +#options+, it should be in {LibraryCommand}.
ja: このメソッドは、 +#options+ メソッドに依存している。
    +#options+ メソッドは {LibraryCommand} にするべきである。

en: calls {CodeObjects::Base#format} if
    an object is provided, or {Templates::Engine.render} if object is nil. Both
    receive +#options+ as an argument.
ja: オブジェクトが提供される場合、
    {CodeObjects::Base#format}を呼び出す、
    又は、オブジェクトがnilの場合
    {Templates::Engine.render}を呼び出す。
    両者は、引数として +#options+ メソッドを受け取る。

en: the resulting output to display
ja: 表示する出力結果

en: Override this method to implement custom caching mechanisms for
ja: カスタムキャッシュメカニズムを実装する為にこのメソッドを上書きする。

en: tag|example|Caching to memory
ja: メモリーにキャッシュする

en: the data to cache
ja: キャッシュするデータ

en: the same cached data (for chaining)
ja: 同じキャッシュされたデータ(メソッドチェーン用)

en: Sets the body and headers (but not status) for a 404 response. Does
    nothing if the body is already set.
ja: 404レスポンス用にボディとヘッダー(しかしステータスはない)を設定する。
    ボディが既に設定されている場合は何もしない。

en: Sets the headers and status code for a redirection to a given URL
ja: 与えられたURLへのリダイレクト用にヘッダーとステータスコードを設定する。

en: causes the request to terminate.
ja: 打ち切る為にリクエストする。

en: the URL to redirect to
ja: リダイレクトするURL

en: Displays a README or extra file.
ja: README 又は、追加のファイルを表示する。

en: Implement better support for detecting binary (image) filetypes
ja: バイナリ(画像)ファイルタイプを見つける為のより良いサポートを実装する。

en: Displays documentation for a specific object identified by the path
ja: パスによって識別された固有のオブジェクト用にドキュメントを表示する。

en: Displays an object wrapped in frames
ja: フレームの中のラップされたオブジェクトを表示する。

en: This is the base command for all commands that deal directly with libraries.
    Some commands do not, but most (like {DisplayObjectCommand}) do. If your
    command deals with libraries directly, subclass this class instead.
    See {Base} for notes on how to subclass a command.
ja: これは、ライブラリを用い直接処理する全てのコマンドの為のベースコマンド。
    いくつかのコマンドには、用いないが({DisplayObjectCommand}のように)大抵の事は行う。
    あなたのコマンドが直接ライブラリを用い処理する場合、代わりにこのクラスをサブクラス化する。
    コマンドをサブクラス化する為の方法については{Base}を参照。

en: the object containing library information
ja: ライブラリの情報含んでいるオブジェクト

en: default options for the library
ja: ライブラリ用のデフォルトのoptions

en: the serializer used to perform file linking
ja: ファイルリンクを実行する為に利用されるシリアライザ

en: whether router should route for multiple libraries
ja: routerが複数のライブラリ用に送るべきかどうか

en: whether to reparse data
ja: データを再解析するかどうか

en: Needed to synchronize threads in {#setup_yardopts}
ja: {#setup_yardopts}メソッドの中で、スレッドを同期する為の必要とされる

en: a new instance of LibraryCommand
ja: LibraryCommandの新しいインスタンス

en: Returns the index of libraries served by the server.
ja: サーバーによって提供されたライブラリのインデックスを返す

en: Returns a list of objects of a specific type
ja: 特定の型のオブジェクトのリストを返す

en: Performs a search over the objects inside of a library and returns
    the results as HTML or plaintext
ja: ライブラリの内部オブジェクトの検索を実行し、
    HTMLやプレーンテキストとして結果を返す。

en: Serves static content when no other router matches a request
ja: リクエストにマッチする他のrouterが無い時、静的な内容を提供する。

en: Defines the paths used to search for static assets. To define an
    extra path, use {YARD::Server.register_static_path} rather than
    modifying this constant directly. Also note that files in the
    document root will always take precedence over these paths.
ja: 静的な資産用に検索に利用されるパスを定義する。
    追加のパスを定義するには、直接この定数を変更するよりも
    {YARD::Server.register_static_path}を利用する。
    尚、ドキュメントのrootのファイルは常時これらのパスより優先する。

en: Return an empty favicon.ico if it does not exist so that
    browsers don't complain.
ja: favicon.icoが存在しない場合、空のfavicon.icoを返す。
    その為、ブラウザに問題は発生しない。

en: A module that is mixed into {Templates::Template} in order to customize
    certain template methods.
ja: テンプレートメソッドをカスタマイズする為に、
    {Templates::Template}へmixinされるモジュール。

en: Modifies {Templates::Helpers::HtmlHelper#url_for} to return a URL instead
    of a disk location.
ja: ディスクの上の場所の代わりにURLを返す{Templates::Helpers::HtmlHelper#url_for}を変更する。

en: Modifies {Templates::Helpers::HtmlHelper#url_for_file} to return a URL instead
    of a disk location.
ja: ディスク上の場所の代わりにURLを返す{Templates::Helpers::HtmlHelper#url_for_file}を変更する。

en: Modifies {Templates::Helpers::HtmlHelper#url_for_list} to return a URL
    based on the list prefix instead of a HTML filename.
ja: HTMLファイル名の代わりにリストのプレフィックス基準のURLを返すには、
    {Templates::Helpers::HtmlHelper#url_for_list} を変更する

en: Returns the frames URL for the page
ja: ページ用のフレームのURLを返す

en: Returns the main URL, first checking a readme and then linking to the index
ja: メインのURLを返し、最初にreadmeをチェックしその時インデックスにリンクする。

en: Returns the URL for the alphabetic index page
ja: アルファベット順のインデックスのページ用にURLを返す

en: tag|example|The base path for a library 'foo'
ja: 'foo'ライブラリ用のベースパス

en: the base URI for a library with an extra +path+ prefix
ja: 追加の +path+ のプレフィックスを用いたライブラリ用のベースURI

en: the path prefix for a base path URI
ja: URIベースパス用のパスのプレフィックス

en: convenience method for accessing the router
ja: routerにアクセスする為の便利メソッド

en: A custom {Serializers::Base serializer} which returns resource URLs instead of
    static relative paths to files on disk.
ja: カスタム{Serializers::Base serializer}。
    ディスク上のファイルの為に静的な相対パスの代わりに、URLリソースを返す。

en: a new instance of DocServerSerializer
ja: DocServerSerializerの新しいインスタンス

en: This exception is raised when {LibraryVersion#prepare!} fails, or discovers
    that the library is not "prepared" to be served by
ja: この例外は、{LibraryVersion#prepare!}が失敗した時や、
    ライブラリが提供される為に"prepared"されない事をかぎつけた場合、上げられる。

en: A library version encapsulates a library's documentation at a specific version.
    Although the version is optional, this allows for creating multiple documentation
    points for a specific library, each representing a unique version. The term
    "library" used in other parts of the YARD::Server documentation refers to
    objects of this class unless otherwise noted.
ja: ライブラリバージョンは、特定のバージョンでライブラリドキュメントをカプセル化する。
    バージョンは任意だけれども、
    これは、複数のドキュメントの特定のライブラリ用にポイントを作成する為に受入れ、
    それぞれ固有のバージョンを表す。
    "library"の表現は、YARD::Serverドキュメントの他の部分で利用され、
    他の方法で注意されなかった場合、このクラスのオブジェクトを参照する。

en: A library points to a location where a {#yardoc_file} is located so that
    its documentation may be loaded and served. Optionally, a {#source_path} is
    given to point to a location where any extra files (and {YARD::CLI::Yardoc .yardopts})
    should be loaded from. Both of these methods may not be known immediately,
    since the yardoc file may not be built until later. Resolving the yardoc
    file and source path are dependent on the specific library "source type" used.
    Source types (known as "library source") are discussed in detail below.
ja: ライブラリの{#yardoc_file}メソッドの指す場所は、
    そのドキュメントがロードされセーブされる場所を示される。
    任意で、{#source_path}メソッドは、
    追加のファイル(と{YARD::CLI::Yardoc .yardopts})が、
    ロードされるべき場所のポイントを与えられる。
    これらのメソッドの両方は、直ぐに理解できないかもしれない、
    なぜなら、yardocファイルが最新でない場合、ビルドされないかもしれないからである。
    yardocファイルとソースパスを解決するには、"source type"に利用される固有のライブラリに依存する。
    ソースの型("library source"として知られる)は、下の詳細の中で検討される。

en: == Using with Adapters
    A list of libraries need to be passed into adapters upon creation. In
    most cases, you will never do this manually, but if you use a {RackMiddleware},
    you will need to pass in this list yourself. To build this list of libraries,
    you should create a hash of library names mapped to an *Array* of LibraryVersion
    objects. For example:
ja: == アダプタと一緒に使用する
    ライブラリのリストは、
    作成する上でアダプターへ渡される必要がある。
    大抵の場合、これを手動で行う事はしないだろう、
    だが、あなたが {RackMiddleware}を利用する場合、
    あなた自身が配列でこの中へ渡す必要があるだろう。
    このライブラリの配列をビルドするには、
    次のように、オブジェクトのLibraryVersionの*配列*に、
    マップされ名付けられたライブラリのハッシュを作成すべきである。

en: Note that you can also use {Adapter#add_library} for convenience.
ja: 次の事に留意する。あなたは、
    便利な{Adapter#add_library}メソッドを
    使う事もできる。

en: The "array" part is required, even for just one library version.
ja: "配列"の部分は、たった一つのライブラリのバージョンでも必要とされる。

en: == Library Sources
    The {#source} method represents the library source type, ie. where the
    library "comes from". It might come from "disk", or it might come from a
    "gem" (technically the disk, but a separate type nonetheless). In these
    two cases, the yardoc file sits somewhere on your filesystem, though
    it may also be built dynamically if it does not yet exist. This behaviour
    is controlled through the {#prepare!} method, which prepares the yardoc file
    given a specific library source. We will see how this works in detail in
    the following section.
ja: == ライブラリのソース
    {#source}メソッドはライブラリのソースのタイプを表す、
    つまり、ライブラリの場所である。
    それは、"disk"からくるかもしれない、
    又は、"gem"からくるかもしれない。
    (実際にはどちらもディスク上だが、型は別れる)
    この二つのケースの場合、
    yardocのファイルは、あなたのファイルシステムの何処かに置いてあり、
    まだ見つかっていない場合、動的にビルドされるかもしれない。
    この挙動は、{#prepare!}メソッドを通じて制御され、
    与えられた固有のライブラリのソースのyardocファイルを用意する。
    私達は、続くセクションの中でこの仕組みを理解するだろう。

en: == Implementing a Custom Library Source
    YARD can be extended to support custom library sources in order to
    build or retrieve a yardoc file at runtime from many different locations.
ja: ==　カスタムライブラリのソースを実装する
    YARDはカスタムライブラリのソースをビルドするのをサポートする為、拡張され、
    多くのの異なる場所から実行時にyardocファイルを読み出す。

en: To implement this behaviour, two methods must be added to the +LibraryVersion+
    class, +#load_yardoc_from_SOURCE+ and +#source_path_for_SOURCE+. In both
    cases, "SOURCE" represents the source type used in {#source} when creating
    the library object. The +#source_path_for_SOURCE+ method is called upon
    creation and should return the location where the source code for the library
    lives. The load method is called from {#prepare!} if there is no yardoc file
    and should set {#yardoc_file}. Below is a full example for
    implementing a custom library source, +:http+, which reads packaged .yardoc
    databases from zipped archives off of an HTTP server.
ja: この挙動を実装するには、
    +LibraryVersion+クラスの +#load_yardoc_from_SOURCE+ メソッドと +#source_path_for_SOURCE+ メソッドの
    2つのメソッドが大抵追加される。
    どちらの場合も、ライブラリのオブジェクトが作成される時の、
    "SOURCE"は{#source}メソッドで利用されたsource typeを表す。
    +#source_path_for_SOURCE+ メソッドは、作成される所で呼び出され、
    存在するライブラリのソースコードの場所を返すべきである。
    loadメソッドは、yardocファイルが無い場合、{#prepare!}メソッドから呼び出される。
    そして、{#yardoc_file}を設定すべきである。
    下は、カスタムライブラリのソースと +:http+ を実装する為の、完全な例であり、
    これは、HTTPサーバー経由でzipされたアーカイブからパーケージされた.yardocデータベースを読み出す。

en: # Adds the source type "http" for .yardoc files zipped on HTTP servers
    class LibraryVersion
      def load_yardoc_from_http
        return if yardoc_file # we have the library
    
        # otherwise download it in a thread and return immediately
        Thread.new do
          # zip/unzip method implementations are not shown
          download_zip_file("http://mysite.com/yardocs/#{self}.zip")
          unzip_file_to("/path/to/yardocs/#{self}")
          self.yardoc_file = "/path/to/yardocs/#{self}/.yardoc"
          self.source_path = self.yardoc_file
        end
    
        # tell the server it's not ready yet (but it might be next time)
        raise LibraryNotPreparedError
      end
    
      # we set this later
      def source_path_for_http; nil end
    end
    
    # Creating a library of this source type:
    LibraryVersion.new('name', '1.0', nil, :http)
ja: # HTTPサーバー上でzipされた.yardocファイル用にソースの型"http"を追加する。
    class LibraryVersion
      def load_yardoc_from_http
        return if yardoc_file #ライブラリを持っている場合
    
        # その他の場合、そのスレッドの中でダウンロードし直ぐに返す
        Thread.new do
          # zip/unzip メソッドの実装は示さない
          download_zip_file("http://mysite.com/yardocs/#{self}.zip")
          unzip_file_to("/path/to/yardocs/#{self}")
          self.yardoc_file = "/path/to/yardocs/#{self}/.yardoc"
          self.source_path = self.yardoc_file
        end
    
        # サーバーを呼び出す準備がまだできていない場合(でも次回になるかもしれない)
        raise LibraryNotPreparedError
      end
    
      # 最新のものを設定する
      def source_path_for_http; nil end
    end
    
    #次の様に、このソースの型を指定して、ライブラリを作成する。
    LibraryVersion.new('name', '1.0', nil, :http)

en: tag|example|Implementing a Custom Library Source
ja: カスタムライブラリのソースを実装する

en: the name of the library
ja: ライブラリの名前

en: the version of the specific library
ja: 固有のライブラリのバージョン

en: if no yardoc file exists yet. In this case, {#prepare!} will
    be called on this library to build the yardoc file.
ja: yardocファイルがまだ存在しない場合、
    yardocファイルをビルドする為に、
    {#prepare!}がこのライブラリ上で呼び出されるだろう。

en: the location of the yardoc file used to load the object
    information from.
ja: オブジェクトの情報をロードするのに利用されるyardocファイルの場所

en: the source type representing where the yardoc should be
    loaded from. Defaults are +:disk+ and +:gem+, though custom sources
    may be implemented. This value is used to inform {#prepare!} about how
    to load the necessary data in order to display documentation for an object.
ja: ソースは、yardocがロードされるべき場所を表す。
    デフォルトは +:disk+ と +:gem+ となるが、カスタムソースの実装もできる。
    この値は、オブジェクト用のドキュメントを表示する為に
    必要なデータをロードする方法について、{#prepare!}メソッドに通知する為に利用される。

en: if there is no source code
ja: これらがソースコードでない場合

en: the location of the source code for a library. This
    value is filled by calling +#source_path_for_SOURCE+ on this class.
ja: ライブラリの為のソースコードの場所。
    この値は、このクラスで +#source_path_for_SOURCE+ を呼び出して埋められる。

en: a new instance of LibraryVersion
ja: LibraryVersionの新しいインスタンス

en: the location of the files used to build the yardoc.
    Builtin source types are +:disk+ or +:gem+.
ja: yardocをビルドする為に利用されるファイルの場所。
    組み込みのソースの型は +:disk+ 又は +:gem+ 。

en: the location of the yardoc file, or nil if it is
    generated later
ja: yardocの場所、又は、最新のものが生成される場合は、nil

en: the specific (usually, but not always, numeric) library
    version
ja: 固有(普通は数字で表されるが、しかし常にではない)のライブラリのバージョン

en: if true, returns the string in a URI-compatible
    format (for appending to a URL). Otherwise, it is given in a more human
    readable format.
ja: trueの場合、URI-compatibleフォーマット(URL追加用)で文字列を返し、
    それ以外の場合、人間が読めるフォーマットが与えられる。

en: the string representation of the library.
ja: ライブラリの文字列表現

en: used for Hash mapping.
ja: ハッシュのマッピング用に利用される

en: whether another LibraryVersion is equal to this one
ja: LibraryVersionが条件と一致するかどうか

en: Prepares a library to be displayed by the server. This callback is
    performed before each request on a library to ensure that it is loaded
    and ready to be viewed. If any steps need to be performed prior to loading,
    they are performed through this method (though they should be implemented
    through the +load_yardoc_from_SOURCE+ method).
ja: サーバーで表示されるライブラリを準備する。
    このコールバックは、ロードされその一覧を準備する事を
    保証する為にライブラリ上で、個々のリクエストの前に実行される。
    任意のステップが、ロードの為に先に実行する必要がある場合、
    このメソッドを通じて実行される。
    (けれどもこれは +load_yardoc_from_SOURCE+ メソッドを通じて実装されるべきである。)

en: You should not directly override this method. Instead, implement
    +load_yardoc_from_SOURCENAME+ when implementing loading for a specific
    source type. See the {LibraryVersion} documentation for "Implementing
    a Custom Library Source"
ja: あなたは、このメソッドを直接上書きすべきではない。
    固有のソースの型用にロードを実装する時は、
    代わりに、 +load_yardoc_form_SOURCENAME+ を実装する。
    "カスタムライブラリのソースの実装"には、{LibraryVersion}ドキュメントを参照。

en: if the library is not ready to be
    displayed. Usually when raising this error, you would simultaneously
    begin preparing the library for subsequent requests, although this
    is not necessary.
ja: ライブラリが表示する為の準備ができていない場合、
    通常このエラーを上げる時は、
    次のリクエストの為のライブラリの準備が一斉に始まる。
    なので、これは、必須ではない。

en: a gemspec object for a given library. Used
    for :gem source types.
ja: 与えられたライブラリ用のgemspecオブジェクト。
    :gemのソースの型用に利用される。

en: if there is no installed gem for the library
ja: これらが、ライブラリ用のgemをインストールされない場合

en: Called when a library of source type "disk" is to be prepared. In this
    case, the {#yardoc_file} should already be set, so nothing needs to be
    done.
ja: ソースの型が"disk"のライブラリの時呼び出され、準備する。
    この場合、{#yardoc_file}は、既に設定されるべきであり、
    何も必要としない。

en: Called when a library of source type "gem" is to be prepared. In this
    case, the {#yardoc_file} needs to point to the correct location for
    the installed gem. The yardoc file is built if it has not been done.
ja: ソースの型が"gem"のライブラリの時呼び出され、準備する。
    この場合、{#yardoc_file}は
    インストールされたgemの正規の場所を必要とする。
    yardocファイルを持っていない場合は、ビルドされる。

en: if the gem does not have an existing
    yardoc file.
ja: gemがyardocファイルに存在しない場合

en: the source path for a disk source
ja: ディスクのソース用のソースのパス

en: the source path for a gem source
ja: gemのソース用のソースのパス

en: This class wraps the {RackAdapter} into a Rack-compatible middleware.
    See {#initialize} for a list of options to pass via Rack's +#use+ method.
ja: このクラスは、Rackと互換性のあるミドルウェアの{RackAdapter}をラップする。
    Rack の +#use+ メソッド経由で渡す為のoptionsのリストは、{#initialize}メソッドを参照。

en: You must pass a +:libraries+ option to the RackMiddleware via +#use+. To
    read about how to return a list of libraries, see {LibraryVersion} or look
    at the example below.
ja: あなたは +#use+ メソッド経由でRackWiddlewareに +:libraries+ のオプションを渡さなければならない。
    librariesのリストを返す為の方法について読むには、{LibraryVersion}又は、下の例を参照。

en: tag|example|Using the RackMiddleware in a Rack application
ja: RackアプリケーションでRackミドルウェアを使用する。

en: Creates a new Rack-based middleware for serving YARD documentation.
ja: YARDドキュメントに提供する為に、
    新しくRackが基本となるミドルウェアを作成する。

en: a new instance of RackMiddleware
ja: Rackミドルウェアの新しいインスタンス

en: the next Rack middleware in the stack
ja: スタックの中の次のRackミドルウェア

en: A server adapter to respond to requests using the Rack server infrastructure.
ja: Rackサーバーのインフラによって、リクエストに答える為のサーバーアダプター。

en: Responds to Rack requests and builds a response with the {Router}.
ja: Rackのリクエストにレスポンスし、{Router}を用いレスポンスをビルドする。

en: the Rack-style response
ja: Rackスタイルのレスポンス

en: Starts the +Rack::Server+. This method will pass control to the server and
    block.
ja: +Rack::Server+ をスタートする。
    このメソッドは、サーバーとブロックに制御を渡すだろう。

en: A router class implements the logic used to recognize a request for a specific
    URL and run specific {Commands::Base commands}.
ja: routerクラスは、特定のURL用のリクエストを認識する為に利用されたロジックを実装し、
    特定の{Commands::Base commands}を起動する。

en: == Subclassing Notes
    To create a custom router, subclass this class and pass it into the adapter
    options through {Adapter#initialize} or by directly modifying {Adapter#router}.
ja: == サブクラス化する時の注意
    カスタムrouterを作成するには、
    このクラスをサブクラス化し、
    {Adapter#initialize}を通じてアダプタオプションへ渡すか、
    直接{Adapter#router}を変更する。

en: The most general customization is to change the URL prefixes recognized by
    routing, which can be done by overriding {#docs_prefix}, {#list_prefix}
    and {#search_prefix}.
ja: 多くの場合、カスタマイズは、
    routerで認識されるURLのプレフィックスを変更する為である。
    {#docs_prefix}、{#list_prefix}、{#search_prefix}メソッドを上書きする事で、
    実現できる。

en: == Implementing Custom Caching
    By default, the Router class performs static disk-based caching on all
    requests through the +#check_static_cache+. To override this behaviour,
    or create your own caching mechanism, mixin your own custom module with
    this method implemented as per {StaticCaching#check_static_cache}.
ja: == カスタムキャッシュを実装する
    デフォルトで、Routerクラスは、
    +#check_static_cache+ を通じて
    全てのリクエストで静的なディスクベースのキャッシュを実行する。
    この挙動を上書きしたり、あなた自身でキャッシュのメカニズムを作成するには、
    {StaticCaching#check_static_cache}メソッドとして実装されたこのメソッドを用いて
    あなた自身のカスタムモジュールをmixinする。

en: tag|example|Creating a subclassed router
ja: サブクラス化されたrouterを作成する

en: the request data coming in with the routing
ja: routerを用いやってくるデータのリクエスト

en: the adapter used by the router
ja: routerによって利用されたアダプタ

en: Creates a new router for a specific adapter
ja: 特定のアダプタ用に新しいrouterを作成する

en: a new instance of Router
ja: Routerの新しいインスタンス

en: the adapter to route requests to
ja: リクエストを送る為のアダプタ

en: Perform routing on a specific request, serving the request as a static
    file through {Commands::StaticFileCommand} if no route is found.
ja: 特定のリクエストでrouterを実行し、
    routeが見つからない場合、
    {Commands::StaticFileCommand}を通じて、
    静的なファイルとしてリクエストを提供する。

en: the Rack-style server response data
ja: Rackスタイルサーバーが返すデータ

en: Route Prefixes
ja: プレフィックスを送る

en: the URI prefix for all object documentation requests
ja: 全てのオブジェクトのドキュメントのリクエスト用のURIのプレフィックス

en: the URI prefix for all class/method/file list requests
ja: 全てのクラス/メソッド/ファイルのリストのリクエスト用のURIのプレフィックス

en: the URI prefix for all search requests
ja: 全ての検索リクエスト用のURIプレフィックス

en: Routing Methods
ja: メソッドを送る

en: the library followed
    by the rest of the path components in the request path. LibraryVersion
    will be nil if no matching library was found.
ja: ライブラリは、リクエストのパスの中で
    そのパスの構成の残りによってフォローされる。
    見つかったライブラリが一致しなかった場合、
    LibraryVersionは、nilになるだろう。

en: Performs routing algorithm to find which prefix is called, first
    parsing out library name/version information.
ja: プレフィックスを検索する為のrouterアルゴリズムを実行する。
    ライブラリのname/version情報の出力を最初に解析する。

en: if no route is matched
ja: route処理がマッチしない場合

en: Routes requests from {#docs_prefix} and calls the appropriate command
ja: {#docs_prefix}からリクエストを送り、適当なコマンドを呼び出す。

en: path components (split by '/')
ja: パスの構成('/'区切り)

en: the library to route for
ja: routeする為のライブラリ

en: Routes for the index of a library / multiple libraries
ja: 単一のライブラリ/複数のライブラリのインデックス用に送る

en: Routes requests from {#list_prefix} and calls the appropriate command
ja: {#list_prefix}メソッドからリクエストを送り、適切なコマンドを呼び出す

en: Routes requests from {#search_prefix} and calls the appropriate command
ja: {#search_prefix}メソッドからリクエストを送り、適切なコマンドを呼び出す

en: Adds extra :library/:path option keys to the adapter options.
    Use this method when passing options to a command.
ja: アダプタオプションに追加の:library/:pathオプションのキーを追加する。
    このメソッドは、コマンドがオプションを解析する時に利用する。

en: Utility Methods
ja: ユーティリティメソッド

en: finalized options
ja: 終わらせるオプション

en: Implements static caching for requests.
ja: リクエスト用の静的なキャッシュを実装する

en: Called by a router to return the cached object. By default, this
    method performs disk-based caching. To perform other forms of caching,
    implement your own +#check_static_cache+ method and mix the module into
    the Router class.
ja: キャッシュされたオブジェクトを返す為にrouterによって呼び出される。
    デフォルトで、このメソッドは、ディスクベースのキャッシュを実行する。
    キャッシュの他の形式を実行するには、
    あなた自身が +#check_static_cache+ メソッドを実装し、
    Routerクラスへモジュールをmixinする。

en: Note that caching does not occur here. This method simply checks for
    the existence of cached data. To actually cache a response, see
    {Commands::Base#cache}.
ja: 次の事に留意する。キャッシュは、ここでは発生しない。
    このメソッドは、単純にキャッシュデータの存在をチェックする。
    実際にレスポンスをキャッシュするには、{Commands::Base#cache}を参照する。

en: if no cache is available and routing should continue
ja: キャッシュが利用できない場合、nilを返す。
    routerは継続すべきである。

en: tag|example|Implementing In-Memory Cache Checking
ja: メモリ内のキャッシュのチェックを実装する

en: The main adapter to initialize a WEBrick server.
ja: WEBrickサーバーをイニシャライズする為の主なアダプタ

en: Initializes a WEBrick server. If {Adapter#server_options} contains a
    +:daemonize+ key set to true, the server will be daemonized.
ja: WEBrickサーバーをイニシャライズする。
    {Adapter#server_options}の内容の
    +:daemonize+ キーにtrueが設定された場合、
    サーバーは、デーモンで起動される。

en: The main WEBrick servlet implementation, accepting only GET requests.
ja: 主にWEBrickサーブレットの実装、取得するリクエストだけ受入れる。
    (servlet:サーバー側で動くプログラムの事)

en: a new instance of WebrickServlet
ja: WebrickServletの新しいインスタンス

en: Parses tag text and creates a new tag with descriptive text
ja: タグテキストを解析し、説明文と共に新しいタグを作成する。

en: a tag object with the tag_name and text values filled
ja: タグ名やテキストの入ったタグオブジェクト

en: the name of the tag to parse
ja: 解析の為のタグの名前

en: the raw tag text
ja: 元のタグテキスト

en: Parses tag text and creates a new tag with a key name and descriptive text
ja: タグテキストを解析し、キー名と説明文と共に新しいタグを作成する。

en: a tag object with the tag_name, name and text values filled
ja: タグ名,キー名,テキストの入ったタグオブジェクト

en: Parses tag text and creates a new tag with formally declared types and
    descriptive text
ja: タグテキストを解析し、形式的に宣言される型と説明文と共に新しいタグを作成する。

en: a tag object with the tag_name, types and text values filled
ja: タグ名,型,テキストを含んだタグオブジェクト

en: Parses tag text and creates a new tag with formally declared types, a key
    name and descriptive text
ja: タグタキストを解析し,形式的に宣言された型と共に新しいタグを作成する,
    キー名と説明文。

en: a tag object with the tag_name, name, types and text values filled
ja: タグ名,キー名,型,テキストの入ったタグオブジェクト

en: Parses tag text and creates a new tag with formally declared types, a title
    on the first line and descriptive text
ja: タグテキストを解析し、新しいタグを作成する。
    形式的に宣言された型、最初の行のタイトル、説明文を用いる。

en: Extracts the name from raw tag text returning the name and remaining value
ja: 元のタグテキストの返す名前から名前を抽出する。又、残りの値は残す。

en: an array holding the name as the first element and the
    value as the second element
ja: 最初の要素は名前を含み、次の要素は残りの値を含んだ配列

en: Parses a [], <>, {} or () block at the beginning of a line of text
    into a list of comma delimited values.
ja: テキスト行の先頭で[],<>,{},()ブロックのカンマで区切られた値の配列の中を解析する

en: the text before the type
    list (or nil), followed by the type list parsed into an array of
    strings, followed by the text following the type list.
ja: 型の配列の前のテキスト(又はnil)、
    続いて、文字列の配列の中を解析されることによって処理される,型のリスト,
    続いて、型のリストをフォローする事によって処理される,テキストを含んだ配列

en: Returns the value of attribute defaults
ja: デフォルトの属性の値を返す

en: a new instance of DefaultTag
ja: DefaultTagクラスの新しいインスタンス

en: the object the parent docstring is
    attached to. May be nil.
ja: オブジェクトを返す、親のdocstringがオブジェクトに追加される。
    nilになるかもしれない。

en: a new instance of Directive
ja: ディレクティブの新しいインスタンス

en: the docstring parser object
ja: docstringのパーサーオブジェクト

en: the meta-data tag containing all input to the docstring
ja: メタデータタグ、docstringに全て入力するデータを含んでいる

en: Parser callbacks
ja: パーサーのコールバック

en: implement this method to perform all data processing for
    the directive.
ja: ディレクディブ用に全てのデータ処理を実行する為にこのメソッドを実装する

en: == Defining a Macro
ja: == マクロを定義する

en: == Using a Macro
ja: == マクロを使う

en: == Attaching a Macro to a DSL Method
ja: == DSL（Class）メソッドにマクロを追加する

en: === Ranges
ja: === 範囲

en: Ranges are also acceptable with the syntax <tt>${N-M}</tt>. Negative values
    on either N or M are valid, and refer to indexes from the end of the list.
    Consider a DSL method that creates a method using the first argument with
    argument names following, ending with the return type of the method. This
    could be documented as:
ja: 範囲は <tt>${N-M}</tt> の構文で指定できる。
    NやMには負の値を指定可能で、
    その場合リストの最後からのインデックスを参照する。
    最初の引数でそれに続く引数名とともに使われて、
    メソッドのリターンタイプとともに終了するメソッドを作るDSLメソッドを考えよう。
    これは次のように記述できる。

en: As described, the method is using the signature <tt>foo(a, b, c)</tt> and the return
    type from the last argument, +String+. When using ranges, tokens are joined
    with commas. Note that this includes using $0:
ja: 上記の通り、メソッドは <tt>foo(a, b, c)</tt> の用法と最後の引数、
    `String`からのリターンタイプを使っている。
    範囲を使うときは、トークンはコンマでつながれている。
    $0を使った場合を記述する。

en: If you want to separate them with spaces, use <tt>$1 $2 $3 $4 ...</tt>. Note that
    if the token cannot be expanded, it will return the empty string (not an error),
    so it would be safe to list <tt>$1 $2 ... $10</tt>, for example.
ja: それらをスペースを用い区切りたい場合は、<tt>$1 $2 $3 $4 ...</tt> を使う
    留意する事としてトークンが拡張できない場合は
    空の文字列を返すだろう。(エラーではない)
    なので例えば
    <tt>$1 $2 ... $10</tt> のように記述すると安全だろう。

en: === Escaping Interpolation
ja: === 補間をエスケープする

en: Interpolation can be escaped by prefixing the +$+ with +\+, like so:
ja: 補間文字をエスケープするには、下の様に +$+ の前に +\+ 置く事でエスケープする。

en: tag|example|Attaching a macro directly to a DSL method
ja: tag|example|DSLメソッドに直接マクロを追加する

en: tag|example|Attaching a macro to a class method (for DSL usage)
ja: tag|example|クラスメソッドにマクロを追加する(DSL使用)

en: tag|example|Defining a simple macro
ja: tag|example|簡単なマクロ定義

en: tag|example|Using a simple macro in multiple docstrings
ja: tag|example|複数のdocstringの中の単純名マクロを使う

en: tag|example|Attaching multiple methods to the same source
ja: tag|example|同じソースに複数のメソッドを追加する

en: tag|example|Defining a simple method
ja: tag|example|簡単なメソッドを定義する

en: tag|example|Defining a simple readonly attribute
ja: tag|example|readonly属性を簡単に定義する

en: tag|example|Defining a simple readwrite attribute
ja: tag|example|readwrite属性を簡単に定義する

en: tag|example|Declaring a method as an attribute
ja: tag|example|属性としてメソッドを宣言する

en: tag|example|Documenting dynamic module inclusion
ja: tag|example|動的にモジュール含有するドキュメントを作成する

en: tag|example|Parsing C code
ja: tag|example|Cのコードを解析する

en: tag|example|Modifying the scope of a DSL method
ja: tag|example|DSLメソッドのスコープを変更する

en: tag|example|Modifying the scope of a set of methods
ja: tag|example|メソッドのグループのスコープを変更する

en: tag|example|Modifying the visibility of a DSL method
ja: tag|example|DSLメソッドの可視性を変更する

en: tag|example|Modifying the visibility of a set of methods
ja: tag|example|メソッドのグループの可視性を変更する

en: == Defining Custom Meta-Data Tags
ja: == カスタムメタデータタグを定義する

en: == Namespaced Tags
ja: == Namespaceタグ

en: If you have specialized tag parsing needs you can substitute the {#factory}
    object with your own by setting {Library.default_factory= Library.default_factory}
    to a new class with its own parsing methods before running YARD. This is useful
    if you want to change the syntax of existing tags (@see, @since, etc.)
ja: == 追加や変更のタグ構文
    あなたが、専用のタグ解析が必要な場合、
    自分で{Library.default_factory= Library.default_factory}を
    YARDが起動する前に自身を解析するメソッドを用い
    新しいクラスに設定する事によって
    {#factory} オブジェクトを代替できる
    これは、既に存在するタグ(@see,@since等)構文を変更したい場合、便利である。

en: tag|example|Defining a custom directive
ja: tag|example|カスタムディレクティブを定義する

en: tag|example|Defining a custom tag
ja: tag|example|カスタムタグを定義する

en: the main Library instance object.
ja: メインライブライリのインスタンスオブジェクト

en: Replace the factory object responsible for parsing tags by setting
    this to an object (or class) that responds to +parse_TAGNAME+ methods
    where +TAGNAME+ is the name of the tag.
ja: +TAGNAME+ がタグの名前となる処理の所で、
    +parse_TAGNAME+ メソッドに関連するオブジェクト(又は,クラス)の為に、
    これを設定する事によってタグを解析するベースであるfactoryオブジェクトを変更する。

en: You should set this value before performing any source parsing with
    YARD, otherwise your factory class will not be used.
ja: あなたはYARDによって何らかのソースの解析を実行する前に、この値を設定しなければならない。
    設定しない場合、あなたのfactoryクラスは利用できない。

en: the factory that parses all tags
ja: 全てのタグを解析するファクトリー

en: Returns the factory method used to parse the tag text for a specific tag
ja: 特定のタグ用のタグテキストを解析するのに、利用されるファクトリーメソッドを返す。

en: if the tag is freeform text
ja: タグがフリーフォームテキストの場合

en: the Tag class to use to parse the tag
    or the method to call on the factory class
ja: ファクトリークラスで呼び出すタグやメソッドを解析し利用する為のタグクラス

en: the factory method name for the tag
ja: タグの為のfactoryメソッド名

en: Returns the factory method used to parse the tag text for a specific
    directive
ja: 特定のディレクティブ用に
    タグテキストを解析する為に利用されたファクトリーメソッドを返す

en: the Tag class to use to parse the tag or
    the methods to call on the factory class
ja: ファクトリークラスで呼び出す為に
    タグやメソッドを解析し利用する為のタグクラス

en: the directive name
ja: ディレクティブ名

en: Sets the list of tags to display when rendering templates. The order of
    tags in the list is also significant, as it represents the order that
    tags are displayed in templates.
ja: テンプレートをレンダリングする時、
    表示する為にタグのリストをセットする。
    リストの中のタグの順番は重要である。
    これは、タグがテンプレートの中で表示される順番を表す。

en: You can use the {Array#place} to insert new tags to be displayed in
    the templates at specific positions:
ja: 特定の場所でテンプレートの中で、
    表示される新しいタグを挿入する為に{Array#place}メソッドを利用できる。

en: a list of ordered tags
ja: 命令されるタグのリスト

en: Sets the list of tags that should apply to any children inside the
    namespace they are defined in. For instance, a "@since" tag should
    apply to all methods inside a module it is defined in. Transitive
    tags can be overridden by directly defining a tag on the child object.
ja: 定義されるnamespaceの内部で任意の子を適用しタグのリストをグループ化すべきである。
    例えば、"@since"タグは、モジュールの内部で定義される全てのメソッドが適用される。
    過渡的なタグは、子のオブジェクトの上(親)のタグを直接定義する事によって上書きできる。

en: a list of transitive tags
ja: 過渡的なタグのリスト

en: Sorts the labels lexically by their label name, often used when displaying
    the tags.
ja: ラベルをそのラベル名によってソートする。
    タグを表示する時に、よく利用される。

en: the sorted labels as an array of the tag name and label
ja: ソートされるタグ名やラベルの配列

en: Convenience method to define a new tag using one of {Tag}'s factory methods, or the
    regular {DefaultFactory#parse_tag} factory method if none is supplied.
ja: {Tag}factoryメソッドの一つによって新しいタグを定義する便利なメソッド、
    又、提供されない場合、正規の{DefaultFactory#parse_tag}メソッド

en: the tag name to create
ja: 作成するタグ名

en: the {Tag} factory method to call when
    creating the tag or the name of the class to directly create a tag for
ja: タグや直接タグを作成するクラスの名前を作成する時、呼び出すfactoryメソッドの{Tag}

en: A factory class to handle parsing of tags, defaults to {default_factory}
ja: タグの解析を操作するfactoryクラス、デフォルトは{default_factory}となる。

en: a new instance of Library
ja: ライブラリの新しいインスタンス

en: the name of the tag to look for
ja: 検索する為のタグの名前

en: Creates a new {Tag} object with a given tag name and data
ja: 与えられたタグ名とデータを用い新しい {Tag} オブジェクトを作成する。

en: the newly created tag object
ja: 新たに作成されたオブジェクト

en: Creates a new directive with tag information and a docstring parser
    object.
ja: タグ情報とdocstringパーサーオブジェクトを用い新しいディレクティブを作成する

en: the name of the tag
ja: タグの名前

en: the newly created directive
ja: 新たに作成されたディレクティブ

en: the parser object parsing the docstring
ja: パーサーオブジェクト、docstringを解析する

en: the tag data
ja: タグデータ

en: Marks a class/module/method as abstract with optional
    implementor information.
ja: 任意の実装情報をと一緒に用い概要としてclass/module/methodをマークする

en: The special name +@api private+ does display a notice in
    documentation if it is listed, letting users know that the
    method is not to be used by external components.
ja: 特別な名前の +@api private+ は
    それが記述された場合ドキュメントの中で通知を表示するようになり
    ユーザーにメソッドが外部の構成要素によって使えないことを知らせる。

en: Declares the API that the object belongs to. Does not display in
    output, but useful for performing queries (+yardoc --query+). Any text is
    allowable in this tag, and there are no predefined values.
ja: オブジェクトが属するAPIを宣言する。
    出力を表示できないが、クエリーの実行用に便利である(+yardoc --query+)。
    任意のテキストは
    このタグを受入可能であり、事前定義された値はない。

en: Attribute
ja: 属性

en: Attribute Getter
ja: Getter属性

en: Attribute Setter
ja: Setter属性

en: List the author or authors of a class, module, or method.
ja: 著者やクラス,モジュール,メソッドの著者を記述する

en: tag|example|Deprecate a method with a replacement API
ja: tag|example|置換APIを用いメソッドをメソッドを廃止する

en: tag|example|Deprecate a method with no replacement
ja: tag|example|置換APIを用いないでメソッドを廃止する

en: Show an example snippet of code for an object. The first line
    is an optional title.
ja: オブジェクト用にコード片の例を表示する。最初の行は任意のタイトル。

en: Options Hash
ja: ハッシュのオプション

en: Describe an options hash in a method. The tag takes the
    name of the options parameter first, followed by optional types,
    the option key name, a default value for the key and a
    description of the option. The default value should be placed within
    parentheses and is optional (can be omitted).
ja: メソッドの中のハッシュのオプションを説明する。
    タグは最初にoptionsのパラメータの名前(name)を取得し、
    続いて任意で型(types)、オプションのキー名、
    キー用のデフォルトの値、オプションの説明となる。
    デフォルト値は任意で(入れなくてもよい)
    括弧の中に置なければならない。

en: Describe that your method can be used in various
    contexts with various parameters or return types. The first
    line should declare the new method signature, and the following
    indented tag data will be a new documentation string with its
    own tags adding metadata for such an overload.
ja: あなたのメソッドが様々なパラメータや戻りの型と一緒に
    様々なコンテキストで利用される説明をする。
    最初に行は新しいメソッドのシグネチャで宣言しなければならない、
    そして続くインデントされたタグデータは
    オーバーロードの様に自身の追加するメタデータタグを用い
    新しいドキュメント文字列になる。

en: tag|example|A method returns an Array or a single object
ja: tag|example|メソッドは配列や単一のオブジェクトを返す

en: tag|example|A regular return value
ja: tag|example|慣習的な戻り値の例

en: "See Also" references for an object. Accepts URLs or
    other code objects with an optional description at the end.
    Note that the URL or object will be automatically linked by
    YARD and does not need to be formatted with markup.
ja: "See Also(参照)"はオブジェクトに参照される。
    URLや最後で任意の説明を用いた他のコードオブジェクトを受入れる。
    留意する事としてURLやオブジェクトは
    YARDによって自動的にリンクされ、
    マークアップを用いフォーマットされる必要はない。

en: Lists the version that the object was first added.
ja: オブジェクトが最初に追加されたバージョンを記述する

en: ParseDirective
ja: パーサーディレクティブ

en: Sets the scope of a DSL method. Only applicable to DSL method
    calls. Acceptable values are 'class' or 'instance'
ja: DSLメソッドのスコープに設定する。DSLメソッド呼び出しにだけ適用できる。
    受け入れる値は'class'または'instance'である。

en: Sets the visibility of a DSL method. Only applicable to
    DSL method calls. Acceptable values are public, protected, or private.
ja: DSLメソッドの可視性を設定する。
    DSLメソッド呼び出しに適用できる。
    受け入れる値はpublic,protected,privateとなる

en: the value to set the attribute pair to.
ja: pair属性に設定する値

en: Returns the value of attribute pair
ja: pair属性の値を返す

en: Sets the attribute pair
ja: pair属性を設定する

en: a new instance of OptionTag
ja: オプションタグの新しいインスタンス

en: Returns the value of attribute parameters
ja: parameters属性の値を返す

en: Returns the value of attribute signature
ja: signature属性の値を返す

en: a new instance of OverloadTag
ja: OverloadTagの新しいインスタンス

en: the value to set the attribute tag_name to.
ja: tag_name属性を設定する値

en: Returns the value of attribute tag_name
ja: tag_name属性の値を返す

en: Sets the attribute tag_name
ja: tag_name属性を設定する

en: a new instance of RefTagList
ja: RefTagListの新しいインスタンス

en: Represents a metadata tag value (+@tag+). Tags can have any combination of
    {#types}, {#name} and {#text}, or none of the above.
ja: タグはメタデータタグの値(+@tag+)を表し
    任意の{#types},{#name},{#text},又は,
    前述のどれでもないメソッドの組み合わせを持つ事が出来る。

en: # The following docstring syntax:
    #   @param [String, nil] arg an argument
    #
    # is equivalent to:
    Tag.new(:param, 'an argument', ['String', 'nil'], 'arg')
ja: # 次のdocstring構文は:
    #   @param [String, nil] arg an argument
    #
    # 以下と同様になる。
    Tag.new(:param, 'an argument', ['String', 'nil'], 'arg')

en: tag|example|Programmatic tag creation
ja: タグを作成するプログラム例

en: if no tag text is supplied
ja: タグテキストが指定されない場合

en: the tag text associated with the tag
ja: タグと一緒に関連付けられるタグテキスト

en: a list of types associated with the tag
ja: タグと一緒に関連付けられる型のリスト

en: if no types are associated with the tag
ja: 型がタグと一緒に関連付けられない場合

en: a name associated with the tag
ja: タグと共に関連づけられる,名前

en: the associated object
ja: 関連するオブジェクト

en: Creates a new tag object with a tag name and text. Optionally, formally declared types
    and a key name can be specified.
ja: タグ名とテキストと共に新しいタグオブジェクトを作成する。
    任意で、形式的に宣言される型やキー名を指定する事が出来る。

en: Types are mainly for meta tags that rely on type information, such as +param+, +return+, etc.
ja: 型は主に、+param+, +return+等の様な型情報を頼るメタタグ用である。

en: Key names are for tags that declare meta data for a specific key or name, such as +param+,
    +raise+, etc.
ja: キー名(name)は +param+ , +raise+ 等のような
    特定のキーや名前用のメタデータを宣言するタグの為にある。

en: a new instance of Tag
ja: タグの新しいインスタンス

en: optional key name which the tag refers to
ja: タグが参照する,任意のキー名

en: optional type list of formally declared types
    for the tag
ja: タグ用に形式的に宣言された型の入った,任意の型配列

en: the descriptive text for this tag
ja: このタグの為の説明文

en: the tag name to create the tag for
ja: タグを作成する為のタグ名

en: Convenience method to access the first type specified. This should mainly
    be used for tags that only specify one type.
ja: 最初の指定される型にアクセスする為の便利なメソッド,
    これは、主に型が一つだけのタグを指定する時に利用されるべきである。

en: the first of the list of specified types
ja: 指定される型のリストの最初の部分

en: This module manages all creation, handling and rendering of {Template}
    objects.
ja: このモジュールは、全ての作成を管理し,操作する。そして、{Template}オブジェクトから表示する。

en: * To create a template object at a path, use {template}.
    * To render a template, call {render}.
    * To register a template path in the lookup paths, call {register_template_path}.
ja: * パスでテンプレートオブジェクトを作成するには、{template}を使う
    * テンプレートを表示するには、{render}を呼び出す
    * 検索するパスでテンプレートパスを記録するには、{register_template_path}を呼び出す。

en: the list of registered template paths
ja: 渡されたテンプレートパスのリスト

en: Registers a new template path in {template_paths}
ja: {template_paths}の中で、新しいテンプレートパスを記録する

en: a new template path
ja: 新しいテンプレートパス

en: Creates a template module representing the path. Searches on disk
    for the first directory named +path+ (joined by '/') within the
    template paths and builds a template module for. All other matching
    directories in other template paths will be included in the
    generated module as mixins (for overriding).
ja: パスを表すテンプレートモジュールを作成する。
    テンプレートパスの内部で、
    +path+ と名付けられた最初のディレクトリ('/'区切り)用に、
    ディスク上をサーチする。
    そして、テンプレートモジュール用にビルドする。
    他にマッチするテンプレートパスの中のディレクトリ全ては、mixinとして(オーバーライド用に)、
    生成されたモジュールが含まれる。

en: a list of path components
ja: 構成要素のパスのリスト

en: if the path does not exist within one of the
    {template_paths} on disk.
ja: ディスク上に{template_paths}が一つも存在しない場合、例外を上げる。

en: the module representing the template
ja: モジュールの表しているテンプレート

en: Forces creation of a template at +path+ within a +full_path+.
ja: +fullpath+ 内部の
    +path+ で、テンプレートの作成を強制する。

en: the full path on disk of the template
ja: テンプレートのディスク上のフルパス

en: the path name of the template
ja: テンプレートのパス名

en: the template module representing the +path+
ja: テンプレートモジュールは、+path+ を表している。

en: Renders a template on a {CodeObjects::Base code object} using
    a set of default (overridable) options. Either the +:object+
    or +:type+ keys must be provided.
ja: デフォルトのオプション(上書き可能)のグループによって、
    {Codeobject::base code object}のテンプレートを表示する。
    +:object+ か +:type+ キーが提供されければならない。

en: If a +:serializer+ key is provided and +:serialize+ is not set to
    false, the rendered contents will be serialized through the {Serializers::Base}
    object. See {with_serializer}.
ja: +:serializer+ キーが提供されるか、 +:serialize+ にfalseを設定しない場合、
    表示される内容は、{Serializers::Base}オブジェクトを通して、シリアライズされるだろう。
    {with_serializer}参照。

en: tag|example|Renders an object with html formatting
ja: htmlフォーマットと共にオブジェクトを表示する

en: tag|example|Renders without an object
ja: オブジェクト無しの表示

en: the options hash
ja: ハッシュのオプション

en: Passes a set of objects to the +:fulldoc+ template for full documentation generation.
    This is called by {CLI::Yardoc} to most commonly perform HTML
    documentation generation.
ja: 完璧なドキュメント生成用に、+:fulldoc+ テンプレートに
    オブジェクトのグループが渡される。
    これは、{CLI::Yardoc}によって呼び出される
    一般的にhtmlドキュメント生成を実行しなければならない。

en: a list of {CodeObjects::Base}
    objects to pass to the template
ja: テンプレートに渡す為の
    {CodeObjects::Base} オブジェクトのリスト

en: Serializes the results of a block with a +serializer+ object.
ja: +serializer+ オブジェクトを用いブロックの結果をシリアライズする。

en: a block whose result will be serialize
ja: 結果がシリアライズされるブロック

en: tag|param|serializer
ja: serializer

en: the code object to serialize
ja: シリアライズする為のコードオブジェクト

en: the contents to serialize
ja: シリアライズする為の内容

en: the serializer object
ja: シリアライザーオブジェクト

en: Sets default options on the options hash
ja: ハッシュのオプションのデフォルトのオプションを設定する。

en: Searches through the registered {template_paths} and returns
    all full directories that have the +path+ within them on disk.
ja: 記録される{template_paths}を通して、検索され、
    ディスク上に +path+ を持つ全てのディレクトリを返す。

en: a list of full paths that are existing
    candidates for a template module
ja: テンプレートモジュール用の候補が存在するフルパスのリスト

en: if provided, allows a relative
    path to be specified from this template's full path.
ja: 提供された場合、
    このテンプレートのフルパスから指定される相対パスを受入れる。

en: tag|param|from_template
ja: from_template

en: the path component to search for in the
    {template_paths}
ja: {template_paths}用に検索する為のパスの構成

en: The name of the module that represents a +path+
ja: +path+ を表すモジュール名

en: the module name
ja: モジュール名

en: the path to generate a module name for
ja: パス用のモジュール名を生成する為のパス

en: The base helper module included in all templates.
ja: ベースへルパーモジュールは、全てのテンプレートを含んでいる。

en: the value to set the attribute object to.
ja: オブジェクトの属性を設定する値

en: the value to set the attribute serializer to.
ja: シリアライザーの属性を設定する値

en: Returns the value of attribute object
ja: オブジェクトの属性の値を返す

en: Returns the value of attribute serializer
ja: シリアライザーの属性の値を返す

en: Sets the attribute object
ja: オブジェクトの属性を設定する。

en: Sets the attribute serializer
ja: シリアライザーの属性を設定する。

en: An object that keeps track of global state throughout the entire template
    rendering process (including any sub-templates).
ja: 全体のテンプレートの表示処理を通じて、globalの状態の軌跡を保持するオブジェクト。
    (任意のサブテンプレートを含んでいる)

en: Managing Global Template State
ja: グローバルなテンプレートの状態を管理する。

en: a struct object that stores state
ja: 状態を記憶する構造体オブジェクト

en: Running the Verifier
ja: Verifierを起動する。

en: a list of code objects
ja: コードオブジェクトのリスト

en: a list of code objects that match
    the verifier. If no verifier is supplied, all objects are returned.
ja: verifierにマッチするコードオブジェクトのリスト
    verifierが提供されない場合、全てのオブジェクトが、返される。

en: Escapes text. This is used a lot by the HtmlHelper and there should
    be some helper to "clean up" text for whatever, this is it.
ja: テキストをエスケープする。これは、HtmlHelperに多く利用され、
    どんなテキストでも仕上げる為にいくつかのhelperメソッドになる。

en: Escaping Text
ja: テキストをエスケープする。

en: Links objects or URLs. This method will delegate to the correct +link_+
    method depending on the arguments passed in.
ja: オブジェクトやURLをリンクする。このメソッドは、
    渡された引数に応じて、妥当な +link_+ メソッドに委譲するだろう。

en: Linking Objects and URLs
ja: オブジェクトとURLにリンクする。

en: tag|example|Including docstring contents of an object
ja: インクルードしているdocstringは、オブジェクトの内容となる。

en: tag|example|Linking a URL
ja: URLにリンクする。

en: tag|example|Linking an object by path
ja: パスによってオブジェクトにリンクする

en: tag|example|Linking to an extra file
ja: extraファイル(追加のファイル)にリンクする。

en: Includes an object's docstring into output.
ja: 出力へ、オブジェクトのdocstringを含める

en: the object to include
ja: 含めるオブジェクト

en: the object's docstring (no tags)
ja: docstringオブジェクト(タグ無し)

en: Include a file as a docstring in output
ja: 出力でdocstringとして、ファイルを含める

en: the file's contents
ja: ファイルの内容

en: the filename to include
ja: 含めるファイル名

en: Links to an object with an optional title
ja: 任意のタイトルと共にオブジェクトにリンクする

en: tag|param|title
ja: title

en: the linked object
ja: リンクしたオブジェクト

en: the object to link to
ja: リンクするオブジェクト

en: the title to use for the link
ja: リンク用に利用するタイトル

en: Links to a URL
ja: URLにリンクする

en: optional parameters for the link
ja: リンク用の任意のパラメーター

en: the URL to link to
ja: リンクするURL

en: the linked URL
ja: リンクしたURL

en: the optional title to display the link as
ja: 任意のタイトルとして、リンクに表示する

en: Links to an extra file
ja: extraファイルにリンクする

en: optional anchor
ja: 任意のアンカー

en: tag|param|anchor
ja: anchor

en: the filename to link to
ja: リンクするファイル名

en: the link to the file
ja: ファイルへのリンク

en: the title of the link
ja: リンクのタイトル

en: Formats a list of return types for output and links each type.
ja: 出力用に戻りの型のリストをフォーマットし、それぞれの型にリンクする。

en: Formatting Object Attributes
ja: オブジェクトの属性をフォーマットする

en: a list of types
ja: 型のリスト

en: tag|example|Formatting types
ja: 型をフォーマットする

en: tag|example|Formatting types without surrounding brackets
ja: 周りをブラケット(括弧)無しの型へフォーマットする

en: tag|param|brackets
ja: brackets

en: the formatted list of Ruby types
ja: フォーマットされたRubyの型のリスト

en: whether to surround the types in brackets
ja: ブラケット(括弧)の型で囲むかどうか

en: tag|example|Formatted type of a method
ja: メソッドの入ったフォーマットされた型

en: tag|example|Formatted type of an exception class
ja: exceptionクラスのフォーマットされた型

en: the human-readable formatted {CodeObjects::Base#type #type}
    for the object
ja: 人が読みやすくフォーマットされたオブジェクト用の{CodeObjects::Base#type #type}メソッド

en: the object to retrieve the type for
ja: 型を回収するオブジェクト

en: the object to retrieve a title for
ja: タイトルを回収するオブジェクト

en: the page title name for a given object
ja: 与えられたオブジェクト用のページのタイトル名

en: Indents and formats source code
ja: インデントし、ソースコードをフォーマットする

en: formatted source code
ja: フォーマットされたソースコード

en: the input source code
ja: 入力のソースコード

en: Helpers for various object types
ja: 様々なオブジェクト型用のHelperメソッド

en: whether an object is a method
ja: オブジェクトがメソッドかどうか

en: whether an object is a namespace
ja: オブジェクトがnamespaceかどうか

en: whether an object is a class
ja: オブジェクトがクラスかどうか

en: whether an object is a module
ja: オブジェクトがモジュールかどうか

en: The helper module for HTML templates.
ja: HTMLテンプレート用のhelperモジュール。

en: Escapes HTML entities
ja: HTMLの構成要素をエスケープする。

en: Escaping Template Data
ja: テンプレートのデータをエスケープする。

en: the HTML with escaped entities
ja: エスケープされたものと一緒のHTML

en: the text to escape
ja: エスケープするテキスト

en: Escapes a URL
ja: URLをエスケープする

en: the URL
ja: URL

en: the escaped URL
ja: エスケープされたURL

en: Turns text into HTML using +markup+ style formatting.
ja: +markup+ スタイルフォーマットにする事によって、HTMLへテキストを切り替える。

en: Converting Markup to HTML
ja: HTMLへMarkupを変換する。

en: examples are +:markdown+, +:textile+, +:rdoc+.
    To add a custom markup type, see {MarkupHelper}
ja: 例えば、 +:markdown+ , +:textile+ , +:rdoc+ がある。
    カスタムマークアップの型を追加するには、 {MarkupHelper}参照。

en: tag|param|markup
ja: markup

en: the HTML
ja: HTML

en: the text to format
ja: フォーマットするテキスト

en: Converts Markdown to HTML
ja: HTMLへMarkdownを変換する。

en: input Markdown text
ja: Markdownテキストを入力する

en: output HTML
ja: HTMLを出力する

en: Converts Textile to HTML
ja: HTMLへTextileを変換する。

en: the input Textile text
ja: 入力するTextileテキスト

en: Converts plaintext to strict Textile (hard breaks)
ja: 厳格なTextileにプレーンテキストを変換する。(hard breaks)

en: the input textile data
ja: 入力するTextileのデータ

en: the output HTML
ja: 出力HTML

en: Converts RDoc formatting (SimpleMarkup) to HTML
ja: RDocフォーマット(SimpleMarkup)をHTMLへ変換する。

en: the input RDoc formatted text
ja: RDocでフォーマットされたテキストの入力

en: Converts plaintext to pre-formatted HTML
ja: 事前にフォーマットされたHTMLにプレーンテキストを変換する。

en: the input text
ja: 入力テキスト

en: Converts plaintext to regular HTML
ja: 通常のHTMLにプレーンテキストを変換する。

en: the same text with no markup
ja: markupの無い、同じテキスト

en: Converts HTML to HTML
ja: HTMLからHTMLへ変換する

en: input html
ja: htmlを入力する

en: Highlights Ruby source. Similar to {#html_syntax_highlight}, but
    this method is meant to be called from {#htmlify} when markup is
    set to "ruby".
ja: Rubyのソースをハイライトする。
    {#html_syntax_highlight}メソッドと同様である。
    しかし、このメソッドはmarkupが"ruby"を設定する時に、
    {#htmlify}メソッドから呼び出される事を意味している。

en: the Ruby source
ja: Rubyのソース

en: the highlighted HTML
ja: ハイライトされたHTML

en: HTMLified text as a single line (paragraphs removed)
ja: 単一の行として、HTML化された(パラグラフが削除された)テキスト

en: Syntax highlights +source+ in language +type+.
ja: 構文は、+type+ の言語で +source+ をハイライトする。

en: Syntax Highlighting Source Code
ja: ソースコードをハイライトする構文

en: To support a specific language +type+, implement the method
    +html_syntax_highlight_TYPE+ in this class.
ja: 特定の +type+ の言語をサポートするには、
    このクラスの中の、+html_syntax_highlight_TYPE+メソッドを実装する。

en: the highlighted source
ja: ハイライトされたソース

en: the language type (:ruby, :plain, etc). Use
    :plain for no syntax highlighting.
ja: 言語の型(:ruby, :plain, etc.)。
    ハイライト無しの構文には、 :plain を使う

en: the source code to highlight
ja: ハイライトするソースコード

en: unhighlighted source
ja: ハイライトを戻されたソース

en: Resolves any text in the form of +{Name}+ to the object specified by
    Name. Also supports link titles in the form +{Name title}+.
ja: Nameによって指定されたオブジェクトに +{Name}+ の形式で
    任意のテキストを解決する。
    さらに、 +{Name title}+ 形式のタイトルのリンクもサポートする。

en: HTML with linkified references
ja: リンクされた参照を用いたHTML

en: tag|example|Linking to a class with a title
ja: タイトルと共にクラスにリンクする

en: tag|example|Linking to an instance method
ja: インスタンスメソッドにリンクする

en: the text to resolve links in
ja: リンクを解決する為のテキスト

en: the anchor for a specific object
ja: 固有のオブジェクト用のアンカー

en: the object to get an anchor for
ja: アンカーを取得するオブジェクト

en: Returns the URL for an object.
ja: オブジェクト用にURLを返す

en: tag|param|relative
ja: relative

en: the URL location of the object
ja: オブジェクトのURLの場所

en: the anchor to link to
ja: リンクするアンカー

en: the object (or object path) to link to
ja: リンクするオブジェクト(又は、オブジェクトパス)

en: use a relative or absolute link
ja: 相対or絶対リンクを使うかどうか(trueで相対リンク)

en: Returns the URL for a specific file
ja: 固有のファイル用のURLを返す

en: the URL pointing to the file
ja: ファイルの場所を指し示す、URL

en: Returns the URL for a list type
ja: リストのタイプ用にURLを返す

en: the URL pointing to the list
ja: リストの為の場所を示すURL

en: the list type to generate a URL for
ja: リストの型用のURLを生成するためのリストの型

en: Returns the URL for the frameset page
ja: フレームセットページ用のURLを返す

en: the URL pointing to the frames page
ja: フレームページのURLのポイント

en: the URL pointing to the first main page the
    user should see.
ja: ユーザーが調べる最初のメインページの為のURLのポイント

en: Formats a list of objects and links them
ja: オブジェクトのリストをフォーマットし、それをリンクする。

en: Formatting Objects and Attributes
ja: オブジェクトと属性をフォーマットする。

en: a formatted list of objects
ja: フォーマットされたオブジェクトのリストを返す

en: Formats a list of types from a tag.
ja: タグから型のリストをフォーマットする。

en: omits the surrounding
    brackets if +brackets+ is set to +false+.
ja: +brackets+ に +false+ が設定された場合、
    周りのブラケット(括弧)を除外する。

en: tag|param|typelist
ja: typelist

en: the list of types formatted
    as [Type1, Type2, ...] with the types linked
    to their respective descriptions.
ja: それらの関連する説明にリンクした型と共に、
    [Type1, Type2, ...]としてフォーマットされた型のリスト

en: the list of types to be formatted.
ja: フォーマットされる型のリスト

en: Get the return types for a method signature.
ja: メソッドのシグネチャ用に、返す型を取得する。

en: tag|param|link
ja: link

en: the method object
ja: メソッドのオブジェクト

en: the signature types
ja: シグネチャの型

en: whether to link the types
ja: 型をリンクするかどうか

en: Formats the signature of method +meth+.
ja: +meth+ メソッドのシグネチャをフォーマットする

en: tag|param|full_attr_name
ja: full_attr_name

en: tag|param|show_extras
ja: show_extras

en: the formatted method signature
ja: フォーマットされたメソッドのシグネチャ

en: the method object to list
    the signature of
ja: シグネチャを記述するメソッドオブジェクト

en: whether to link the method signature to the details view
ja: 詳細の一覧にメソッドのシグネチャをリンクするかどうか

en: whether to show extra meta-data (visibility, attribute info)
ja: 追加のメタデータを見せるかどうか(可視性、infoの属性)

en: whether to show the full attribute name
    ("name=" instead of "name")
ja: 完全なnameの属性を見せるかどうか("name=" instead of "name")

en: Returns the current character set. The default value can be overridden
    by setting the +LANG+ environment variable or by overriding this
    method. In Ruby 1.9 you can also modify this value by setting
    +Encoding.default_external+.
ja: 現在の文字集合を返す。
    デフォルトの値は、 +LANG+ 環境変数を設定したり、このメソッドを上書きする事によって
    上書きできる。
    又、Ruby1.9では +Encoding.default_external+ を設定する事によって、
    この値を変更できる。

en: Getting the Character Encoding
ja: Character Encodingを取得する

en: the current character set
ja: 現在の文字集合

en: Converts a set of hash options into HTML attributes for a tag
ja: タグ用にHTML属性へハッシュのオプションのグループを変換する。

en: the tag attributes of an HTML tag
ja: HTMLタグのタグ属性

en: the tag options
ja: そのタグのオプション

en: Converts a {CodeObjects::MethodObject} into an overload object
ja: 上書きするオブジェクトへ{CodeObjects::MethodObject}を変換する

en: the source code whose language to determine
ja: どの言語か決める為のソースコード

en: highlighted html
ja: ハイライトされたHTML

en: the html to search for code in
ja: HTMLの中のコード用に検索するためのHTML

en: Helper methods for syntax highlighting.
ja: 構文ハイライト用のHelperメソッド

en: Highlights Ruby source
ja: Rubyのソースをハイライトする

en: the Ruby source code
ja: Rubyのソースコード

en: the highlighted Ruby source
ja: ハイライトされたRubyのソース

en: the value to set the attribute from_path to.
ja: from_path属性を設定する値

en: Returns the value of attribute from_path
ja: from_path属性の値を返す

en: Sets the attribute from_path
ja: from_path属性を設定する

en: a new instance of RDocMarkup
ja: RDocMarkupの新しいインスタンス

en: Fixes RDoc behaviour with ++ only supporting alphanumeric text.
ja: RDocの振舞いを修正する(アルファベットと数字を組み合わせたテキストのサポートだけ追加)

en: Refactor into own SimpleMarkup subclass
ja: 自身をSimpleMarkupサブクラスへリファクタリング予定

en: Don't allow -- to turn into &#8212; element. The chances of this being
    some --option is far more likely than the typographical meaning.
ja: --を&#8212へ変換する事は許可していない。
    表示している意味よりも、いくつかの--optionになる可能性が高い。

en: Disable auto-link of URLs
ja: URLの自動リンクを無効にする

en: Helper methods for loading and managing markup types.
ja: 読み込みと,型のmarkupの管理用のHelperメソッド

en: Clears the markup provider cache information. Mainly used for testing.
ja: マークアッププロバイダーのキャッシュ情報を初期化する。
    主にtest用に利用される。

en: the cached markup providers
ja: キャッシュされたマークアッププロバイダー

en: The default list of markup providers for each markup type
ja: それぞれのマークアップの型用の
    マークアッププロバイダーのデフォルトのリスト。

en: Returns a list of extensions for various markup types. To register
    extensions for a type, add them to the array of extensions for the
    type.
ja: 様々なmarkupの型の為に拡張のリストを返す。
    型用に拡張を記録するには、型用の拡張の配列に拡張を追加する。

en: Contains the Regexp object that matches the shebang line of extra
    files to detect the markup type.
ja: markup型を認識する為に、
    追加のファイルのshebang行にマッチする
    Regexpオブジェクトを含んでいる。

en: Attempts to load the first valid markup provider in {MARKUP_PROVIDERS}.
    If a provider is specified, immediately try to load it.
ja: {MARKUP_PROVIDERS}で最初の有効なマークアップロバイダーを読み込む。
    プロバイダーが指定される場合、直ぐにロードするか試す。

en: On success this sets `@markup_provider` and `@markup_class` to
    the provider name and library constant class/module respectively for
    the loaded provider.
ja: これは成功した場合、プロバイダー名に
    `@markup_provider`と`@markup_class`を設定し、
    ロードされたプロバイダーの為に、
    それぞれライブラリ,定数,クラス/モジュールとなる。

en: On failure this method will inform the user that no provider could be
    found and exit the program.
ja: 失敗した場合、このメソッドは、
    プロバイダーが見つける事ができないユーザーを知らせて、プラグラムを脱出するだろう。

en: whether the markup provider was successfully loaded.
ja: マークアップのプロバイダーが正常に読み込まれたかどうか

en: Checks for a shebang or looks at the file extension to determine
    the markup type for the file contents. File extensions are registered
    for a markup type in {MARKUP_EXTENSIONS}.
ja: shebangをチェックし、
    ファイルの内容の為にマークアップの型を決めるファイル拡張子を探す。
    ファイル拡張子は、{MARKUP_EXTENSIONS}のマークアップの型が記録される。

en: A shebang should be on the first line of a file and be in the form:
ja: shebangは、ファイルの最初の行になり、次のような形式となる。

en: Standard markup types are text, html, rdoc, markdown, textile
ja: 標準のマークアップは、text,htmlcrdoc,markdown,textileとなる。

en: Unused. Was necessary prior to 0.7.0.
    Newer versions of YARD use {CodeObjects::ExtraFileObject#contents}
ja: 利用されない。0.7.0.より前では、必須だった。
    YARDの最新バージョンでは、{CodeObjects::ExtraFileObject#contents}を用いる。

en: the markup type recognized for the file
ja: ファイルに認識されたマークアップタイプ

en: Strips any shebang lines on the file contents that pertain to
    markup or preprocessing data.
ja: マークアップや処理するデータに関係があるファイルの内容の
    任意のshebang行をStripする。

en: Use {CodeObjects::ExtraFileObject#contents} instead
ja: 替わりに{CodeObjects::ExtraFileObject#contents}を使う

en: the file contents minus any preprocessing tags
ja: ファイルの内容が任意のtagを表す

en: Gets the markup provider class/module constant for a markup type
    Call {#load_markup_provider} before using this method.
ja: マークアップ型がこのメソッドを使う前に{#load_markup_provider}を呼び出すマークアッププロバイダーのクラス/モジュールの定数を取得する。

en: the markup class
ja: マークアップのクラス

en: the markup type (:rdoc, :markdown, etc.)
ja: マークアップの型(:rdoc, :markdown, etc.)

en: Gets the markup provider name for a markup type
    Call {#load_markup_provider} before using this method.
ja: マークアップ型がこのメソッド使う前に{#load_markup_provider}を呼び出すマークアッププロバイダー名を取得する。

en: the markup provider name (usually the gem name of the library)
ja: マークアッププロバイダー名(慣習では、ライブラリのgem名)

en: Helper methods for method objects.
ja: メソッドオブジェクト用のHelperメソッド

en: formatted arguments for a method
ja: メソッド用にフォーマットされた引数

en: formatted and linked return types for a method
ja: メソッド用にフォーマットとリンクされた型を返す

en: formatted block if one exists
ja: 何か渡された場合、フォーマットされたブロックを返す

en: formats line numbers for source code of an object
ja: オブジェクトのソースコード用に行数をフォーマットする

en: formats source of an object
ja: オブジェクトのソースをフォーマットする

en: formats source code of a constant value
ja: 定数の値の入ったソースコードをフォーマットする

en: Helper methods for managing module objects.
ja: モジュールオブジェクトを管理用のHelperメソッド

en: Prunes the method listing by running the verifier and removing attributes/aliases
ja: verifierを起動する事によって、メソッドのリストを切り詰め、属性/エイリアスを削除する。

en: a pruned list of methods
ja: 切り詰められたメソッドのリスト

en: tag|param|hide_attributes
ja: hide_attributes

en: whether to prune attribute methods from the list
ja: リストからメソッドの属性を切り詰めるかどうか

en: Helper methods for text template formats.
ja: テキストテンプレートフォーマット用のHelperメソッド

en: escapes text
ja: テキストをエスケープする

en: wraps text at +col+ columns.
ja: +col+ 列でテキストをラップする。

en: indents +text+ by +len+ characters.
ja: +len+ 文字で +text+ をインデントする

en: aligns a title to the right
ja: 右にタイトルを並べる

en: aligns text to the right
ja: 右にテキストを並べる

en: returns a horizontal rule for output
ja: 出力用に横方向の罫線を返す

en: the formatted signature for a method
ja: メソッド用にフォーマットされたシグネチャ

en: Helpers for UML template format
ja: UMLテンプレートフォーマット用のHelperメソッド

en: Official UML visibility prefix syntax for an object given its visibility
ja: オブジェクト用に与えられた可視性の為の公式のUMLプレフィックス構文

en: the UML visibility prefix
ja: UML可視性のプレフィックス

en: the object to retrieve visibility for
ja: 可視性を回収するオブジェクト

en: Formats the path of an object for Graphviz syntax
ja: Graphviz構文用にオブジェクトのパスをフォーマットする。

en: an object to format the path of
ja: パスをフォーマットするオブジェクト

en: the encoded path
ja: エンコードされたパス

en: Encodes text in escaped Graphviz syntax
ja: Graphviz構文用にエスケープされたテキストをエンコードする

en: text to encode
ja: エンコードするテキスト

en: the encoded text
ja: エンコードされたテキスト

en: Tidies data by formatting and indenting text
ja: フォーマットによってデータを整える、テキストをインデントする。

en: pre-formatted text
ja: フォーマットされる前のテキスト

en: tidied text.
ja: 整えられたテキスト

en: Abstracts the structure for a section and its subsections into an ordered
    list of sections and subsections.
ja: セクションに構造体を抽象化し、セクションとサブセクションのオーダーされたリストをサブサクションにする。

en: a new instance of Section
ja: セクションの新しいインスタンス

en: the value to set the attribute class to.
ja: class属性を設定する値

en: the value to set the attribute section to.
ja: section属性を設定する値

en: Returns the value of attribute class
ja: class属性の値を返す

en: Returns the value of attribute section
ja: section属性の値を返す

en: Sets the attribute class
ja: classの属性を設定する

en: Sets the attribute section
ja: section属性を設定する

en: Returns the value of attribute options
ja: options属性の値を返す

en: a list of modules to be automatically included
    into any new template module
ja: 任意の新しいテンプレートモジュールへ自動でインクルードされるモジュールのリスト

en: tag|example|Adding in extra mixins to include on a template
ja: tag|example|テンプレート上でincludeするために追加のmixinを追加する

en: the options hash containing all template information
ja: ハッシュのオプションは全てのテンプレート情報を含んでいる

en: the template object to mixin the extra includes.
ja: 追加のincludeをmixinする為のテンプレートオブジェクト

en: the value to set the attribute full_path to.
ja: full_path属性を設定する値

en: the value to set the attribute path to.
ja: path属性を設定する値

en: Returns the value of attribute full_path
ja: full_path属性の値を返す

en: Returns the value of attribute path
ja: path属性の値を返す

en: Sets the attribute full_path
ja: full_path属性を設定する

en: Sets the attribute path
ja: path属性を設定する

en: a new instance of ClassMethods
ja: ClassMethodsの新しいインスタンス

en: Searches for a file identified by +basename+ in the template's
    path as well as any mixed in template paths. Equivalent to calling
    {ClassMethods#find_nth_file} with index of 1.
ja: テンプレートパスも
    任意の混ぜられたテンプレートパスも +basename+ でファイルが一致する為に検索する。
    {ClassMethods#find_nth_file}メソッドを index 1 で呼び出すのと同様である。

en: tag|param|basename
ja: basename

en: tag|see|find_nth_file
ja: find_nth_file

en: the filename to search for
ja: 検索するファイル名

en: the full path of a file on disk with filename
    +basename+ in one of the template's paths.
ja: テンプレートパスの一つである +basename+ の入ったディスク上のファイルのフルパスを返す

en: Searches for the nth file (where n = +index+) identified
    by basename in the template's path and any mixed in template paths.
ja: n番目のファイルがテンプレートパスか任意の混ぜられたテンプレートパスのbasenameによって
    一致するかサーチする。

en: tag|param|index
ja: index

en: the full path of the nth file on disk with
    filename +basename+ in one of the template paths
ja: テンプレートパスの一つの +basename+ を用いたディスク上のn番目のファイルフルパス

en: the nth existing file to return
ja: n番目に存在するファイルを戻すindex

en: Creates a new template object to be rendered with {Template#run}
ja: {Template#run}と共に表示される新しいテンプレートオブジェクトを作成する

en: Alias for creating a {Section} with arguments
ja: 引数と共に{Section}の作成用のエイリアス

en: tag|see|Section#initialize
ja: Section#initialize

en: a new instance of Template
ja: テンプレートの新しいインスタンス

en: Loads a template specified by path. If +:template+ or +:format+ is
    specified in the {#options} hash, they are prepended and appended
    to the path respectively.
ja: pathによって指定されたテンプレートをロードする。
    +:template+ や +:format+ が{#options}ハッシュメソッドで指定される場合、
    #optionsメソッドに関係するパスが前後に加えられる。

en: the loaded template module
ja: ロードされたテンプレートモジュール

en: the path of the template
ja: テンプレートのパス

en: Sets the sections (and subsections) to be rendered for the template
ja: テンプレート用に表示されるセクション(とサブサクション)を設定する。

en: sections :header, [:name, :children]
    # the above will call header.erb and only renders the subsections
    # if they are yielded by the template (see #yieldall)
ja: sections :header, [:name, :children]
    # 上は、header.erbが呼び出され、subsectionをが表示する。
    # テンプレートでyieldしたい場合は (see #yieldall) 参照

en: tag|example|Sections with subsections
ja: subsectionsを用いたsection

en: tag|example|Sets a set of erb sections
ja: erb sectionのグループを設置する

en: tag|example|Sets a set of method and erb sections
ja: メソッドのグループとercセクションを設定する

en: the sections
    to use to render the template. For symbols and strings, the
    section will be executed as a method (if one exists), or rendered
    from the file "name.erb" where name is the section name. For
    templates, they will have {Template::ClassMethods#run} called on them.
    Any subsections can be yielded to using yield or {#yieldall}
ja: テンプレートを表示する為に利用するセクション。
    symbolとstringでセクションは、メソッドとして実行される。(存在する場合)
    又、nameがsection名の所で"name.erb"ファイルから表示される
    テンプレート用に、呼び出された{Template::ClassMethods#run}を持つだろう。
    任意のsubsectionは、yieldや{#yieldall}メソッドによってyieldされる。

en: Initialization called on the template. Override this in a 'setup.rb'
    file in the template's path to implement a template
ja: テンプレート上で呼び出される初期化処理。
    テンプレートを実装するテンプレートのパスで'setup.rb'ファイルを上書きする。

en: tag|example|A default set of sections
ja: セクションのデフォルトのグループ

en: Runs a template on +sects+ using extra options. This method should
    not be called directly. Instead, call the class method {ClassMethods#run}
ja: 追加のオプションによって、+sects+上でテンプレートを起動する。
    このメソッドは、直接呼び出されないだろう。
    代わりに、{ClassMethods#run}クラスメソッドを呼び出す。

en: a section list of sections to render
ja: 表示する為のsectionのリスト

en: any extra options to apply to sections
ja: sectionsに適用する任意の追加のオプション

en: any extra options to yield
ja: yieldする任意の追加のオプション

en: calls for the subsections to be rendered
ja: 表示されるサブセクション用に呼び出される

en: if true, renders only the first section
ja: trueなら、最初のセクションだけ表示される

en: tag|param|break_first
ja:  break_first

en: tag|param|sects
ja: sects

en: tag|param|start_at
ja: start_at

en: the index in the section list to start from
ja: セクションのリストの最初のindex

en: the rendered sections joined together
ja: 一緒に加えられた,表示されたsection

en: Yields all subsections with any extra options
ja: 任意の追加のオプションと共に全てのサブセクションをyieldする。

en: extra options to be applied to subsections
ja: サブセクションに適用される追加のオプション

en: calls subsections to be rendered
ja: 表示されるサブセクションを呼び出す

en: tag|param|section
ja: section

en: the contents of the ERB rendered section
ja: セクションに表示されるERBの内容

en: the section name
ja: セクション名

en: Returns the contents of a file. If +allow_inherited+ is set to +true+,
    use +{{{__super__}}}+ inside the file contents to insert the contents
    of the file from an inherited template. For instance, if +templates/b+
    inherits from +templates/a+ and file "test.css" exists in both directories,
    both file contents can be retrieved by having +templates/b/test.css+ look
    like:
ja: ファイルの内容を返す。
    +allow_inherited+ が +true+ に設定される場合、
    継承されたテンプレートから
    ファイルの入った内容を挿入する為、
    ファイルの内容の内部で
    +{{{__super__}}}+ を使う。
    例えば、 +templates/b+ が +templates/a+ から継承され、 "test.css"ファイルが存在する
    ディレクトリの中で両方とも存在している場合、
    両方ファイルの内容は、以下の用に
    +templates/b/test.css+ を持つ事によって回収できる。

en: tag|param|allow_inherited
ja: allow_inherited

en: the contents of a file identified by +basename+. All
    template paths (including any mixed in templates) are searched for
    the file
ja: +basename+ によって指定されたファイルの内容。
    全てのテンプレートパスは(任意の混ぜられたテンプレートを含んでいる)、
    ファイル用に検索される。

en: the name of the file
ja: ファイルの名前

en: whether inherited templates can
    be inserted with +{{{__super__}}}+
ja: 継承されたテンプレートが +{{{__super__}}}+ を用いて継承されるかどうか

en: Calls the ERB file from the last inherited template with {#section}.erb
ja: {#section}.erbと共に継承されたテンプレートの最後からERBファイルを呼び出す。

en: if provided, uses a specific section name
ja: 提供された場合、固有のセクション名を使う

en: the rendered ERB file in any of the inherited template
    paths.
ja: 継承されたテンプレートパスの任意で表示されるERBファイル

en: the template output format
ja: テンプレート出力のフォーマット

en: the template name used to render output
ja: 出力を表示するため利用されたテンプレート名

en: the markup format to use when parsing docstrings
ja: docstringを解析する時に使うためのマークアップフォーマット

en: the default return type for a method with no return tags
ja: returnタグを用いないメソッド用のデフォルトの戻りの型

en: whether code blocks should be syntax highlighted
ja: コードブロックが構文ハイライトされるかどうか

en: the markup provider class for the markup format
ja: マークアップフォーマット用のマークアッププロバイダークラス

en: an open struct containing any global state across all
    generated objects in a template.
ja: テンプレートの中で生成された全てのオブジェクトに渡って
    全てのglobalの状態を含んでいるopen struct

en: the main object being generated in the template
ja: テンプレートの中で生成されるメインオブジェクト

en: the owner of the generated object
ja: 生成されたオブジェクトのオーナー

en: the template type used to generate output
ja: 出力を生成するために使ったテンプレートタイプ

en: whether serialization should be performed
ja: シリアライズが実行されるかどうか

en: whether highlighting should be ignored
ja: ハイライトが無視されるかどうか

en: the title of a given page
ja: 与えられたページのタイトル

en: if the mixin is not a module object
ja: mixinがモジュールオブジェクトでない場合

en: whether a mixin matches the embed_mixins list
ja: mixinがembed_mixinsのリストにマッチするかどうか

en: the verifier object
ja: verifier(認証)オブジェクト

en: Similar to a Proc, but runs a set of Ruby expressions using a small
    DSL to make tag lookups easier.
ja: Procと同様であるが、検索しやすいタグを作る為に、
    ちょっとしたDSLによって、Rubyの式のグループを起動する。

en: The syntax is as follows:
    * All syntax is Ruby compatible
    * +object+ (+o+ for short) exist to access the object being verified
    * +@TAGNAME+ is translated into +object.tag('TAGNAME')+
    * +@@TAGNAME+ is translated into +object.tags('TAGNAME')+
    * +object+ can be omitted as target for method calls (it is implied)
ja: 次の様な構文となる:
    * 全ての構文は、Rubyと互換性がある。
    * +object+ (略字は +o+)は検証されるオブジェクトにアクセスする為に存在する。
    * +@TAGNAME+ は +object.tag('TAGNAME')+ の中で変換される
    * +@@TAGNAME+ は +object.tags('TAGNAME')+ の中で変換される
    * +object+ は、メソッド呼び出し用の対象として省略できる。(ほのめかす)

en: Verifier.new('@@param.empty?')
    # Equivalent to:
    Verifier.new('object.tags(:param).empty?')
ja: Verifier.new('@@param.empty?')
    # 下は上と同様
    Verifier.new('object.tags(:param).empty?')

en: Verifier.new('@return', '@param', '@yield')
    # Equivalent to:
    Verifier.new('@return && @param && @yield')
ja: Verifier.new('@return', '@param', '@yield')
    # 以下は上と同様
    Verifier.new('@return && @param && @yield')

en: Verifier.new('@return.text.empty?')
    # Equivalent to:
    Verifier.new('object.tag(:return).text.empty?')
ja: Verifier.new('@return.text.empty?')
    # 下は上と同様
    Verifier.new('object.tag(:return).text.empty?')

en: Verifier.new('object.docstring == "hello world"')
    # Equivalent to:
    Verifier.new('o.docstring == "hello world"')
ja: Verifier.new('object.docstring == "hello world"')
    # 下は上と同様
    Verifier.new('o.docstring == "hello world"')

en: tag|example|Check if there are any @param tags
ja: @paramタグがあるかチェックする

en: tag|example|Create a verifier to check for objects that don't have @private tags
ja: @privateタグを持たないオブジェクト用にチェックする検証器を作成する。

en: tag|example|Create a verifier to find any return tag with an empty description
ja: 空の説明と共に、任意のreturnタグを見つける検証器を作成する。

en: tag|example|Specifying multiple expressions
ja: 複数の表現を指定する

en: tag|example|Using +object+ or +o+ to look up object attributes directly
ja: 直接オブジェクト属性を検索するには、+object+ や +o+を使う

en: tag|example|Without using +object+ or +o+
ja: +object+ と +o+ を使わない例

en: a list of all expressions the verifier checks for
ja: チェックする検証器用の全ての式のリスト

en: Creates a verifier from a set of expressions
ja: 式のグループから検証器を作成する。

en: a list of Ruby expressions to
    parse.
ja: 解析するRubyの式のリスト

en: a new instance of Verifier
ja: 検証器の新しいインスタンス

en: tag|param|expressions
ja: 式

en: Adds a set of expressions and recompiles the verifier
ja: 式のグループを追加し、検証器を再編集する。

en: a list of expressions
ja: 式のリスト

en: Passes any method calls to the object from the {#call}
ja: {#call}メソッドからオブジェクトに任意のメソッド呼び出しを解析する

en: Tests the expressions on the object.
ja: オブジェクト上の式をテストする

en: If the object is a {CodeObjects::Proxy} the result will always be true.
ja: オブジェクトが{CodeObjects::Proxy}なら、評価結果は,常にtrueになる。

en: the object to verify
ja: 検証するオブジェクト

en: the result of the expressions
ja: 式の結果

en: Runs a list of objects against the verifier and returns the subset
    of verified objects.
ja: オブジェクトに対する検証器のリストを起動し、検証されるオブジェクトの下位集合を返す

en: a list of code objects that match
    the verifier.
ja: 検証器にマッチするコードオブジェクトのリスト

en: the current object being tested
ja: テストされる現在のオブジェクト

en: Modifies nil to not throw NoMethodErrors. This allows
    syntax like object.tag(:return).text to work if the #tag
    call returns nil, which means users don't need to perform
    stringent nil checking
ja: NoMethodErrorsにthrowせずnil classに変更する。
    #tagメソッド呼び出しがnilを返す場合、
    これはobject.tag(:return).textのような構文を受け入れる。
    ユーザーが厳密なnilのチェックする為に必要としない事を意味する。

en: Returns the state of NilClass back to normal
ja: NilClassの状態を元に戻す

en: Creates the +__execute+ method by evaluating the expressions
    as Ruby code
ja: Rubyのコードのような式を評価する事によって +__execute+ メソッドを作成する。

en: Parses a single expression, handling some of the DSL syntax.
ja: 単独の式を解析し、いくつかのDSL構文を操作する。

en: The syntax "@tag" should be turned into object.tag(:tag),
    and "@@tag" should be turned into object.tags(:tag)
ja: "@tag"構文は、object.tag(:tag)へ渡され、
    "@tags"構文は、object.tags(:tag)へ渡される。

en: the parsed expression
ja: 解析された式
