Commit: 8205167ce2561424b6c962b1438ac42c8c5eee04 - sh_doc_ja (git)

source-highlight

Commit MetaInfo

• Revision: 8205167ce2561424b6c962b1438ac42c8c5eee04 (tree)
• Time: 2011-04-05 20:23:23
• Author: akngw <akngw@user...>
• Commiter: akngw

Log Message

いろいろ修正。

Change Summary

• modified: source-highlight.texinfo

Incremental Difference

--- a/source-highlight.texinfo
+++ b/source-highlight.texinfo
@@ -63,14 +63,14 @@ Software Foundation raise funds for GNU development.''
 @contents
 
 @ifnottex
-@node Top, 導入, (dir), (dir)
+@node Top, Introduction, (dir), (dir)
 @top GNU Source-highlight
 
-GNU Source-highlightは、入力したソースファイルからシンタックスを強調したドキュメントを生成する。
+GNU Source-highlightは、入力したソースファイルから、シンタックスを強調したドキュメントを生成します。
 
-このドキュメントは、Source-highlightマニュアルの@value{EDITION}エディションである。
+このドキュメントは、Source-highlightマニュアルの@value{EDITION}エディションです。
 
-このファイルは、GNU Source-highlightバージョン@value{VERSION}について記述している。
+このファイルは、GNU Source-highlightバージョン@value{VERSION}について記述しています。
 
 @insertcopying
 @end ifnottex
@@ -82,275 +82,295 @@ GNU Source-highlightは、入力したソースファイルからシンタック
 @c All the menus can be updated with the EMACS command
 @c texinfo-all-menus-update, which is normally bound to C-c C-u C-a.
 @menu
-* 導入::                        目的
-* インストール::                ダウンロードとインストール
-* Copying::                     ライセンスについて
-* 簡単な使い方::                非常に基本的な使い方
-* 設定ファイル::                実行に必要なファイル
-* source-highlightの起動::      @command{source-highlight}の実行方法
-* 言語の定義::                  入力言語の定義方法
-* 出力言語の定義::              出力フォーマットの定義方法
-* リファレンスの生成::          アンカーとクロスリファレンス
-* 例::                          出力例
-* バグ報告::                        バグ報告
-* メーリングリスト::               
+* Introduction::                What's it for?
+* Installation::                Download and installation           
+* Copying::                     Licence issues
+* Simple Usage::                Very basic usage
+* Configuration files::         Files needed for execution
+* Invoking source-highlight::   How to run @command{source-highlight}.
+* Language Definitions::        How to define an input language
+* Output Language Definitions::  How to define an output format
+* Generating References::       Anchors and cross references
+* Examples::                    Some output examples
+* Problems::                    Reporting bugs.
+* Mailing Lists::               
 * Concept Index::               Index of concepts.
 @end menu
 
-@node 導入, インストール, Top, Top
-@chapter 導入
 
+@node Introduction, Installation, Top, Top
+@chapter 導入
 @cindex introduction
 @cindex features
 
-GNU Source-highlightは、入力したソースファイルからシンタックスが強調されたドキュメントを生成する。
-色やスタイルについては、設定ファイルを使ったり、コマンドラインで指定する何らかのオプションを使うことで指定することができる（ボールド、イタリック、下線）。
+GNU Source-highlightは、入力したソースファイルから、シンタックスが強調されたドキュメントを生成します。
+設定ファイルを使ったり、コマンドラインで何らかのオプションを指定することで、色やスタイルを指定することができます（ボールド・イタリック・下線）。
 
-このプログラムはすでに多数の言語（たとえば、C++、Java、Perlなど）と多数のファイルフォーマット（たとえば、ログファイル、ChangeLogなど）、そして、複数の出力フォーマット（たとえば、HTML、ANSIカラーエスケープシーケンス、@LaTeX{}など）を認識している。
-バージョン2.0からは、後でこのマニュアルで説明する簡単なシンタックスを使って自分自身で入力ソースとなる言語を記述することができる(@ref{言語の定義})。
-バージョン2.1からは、後でこのマニュアルで説明する簡単なシンタックスを使って自分自身で出力フォーマットの言語を記述することができる(@ref{出力言語の定義})。
-バージョン2.2からは、@emph{ctags}プログラム(@url{http://ctags.sourceforge.net})に頼る形ではあるが、クロスリファレンス（たとえば、変数名やフィールド名になどに対するもの）を生成することができるようになった(@ref{リファレンスの生成})。
+このプログラムは、多数の言語（例えば、C++、Java、Perlなど）、多数のファイルフォーマット（例えば、ログファイル、ChangeLogなど）、複数の出力フォーマット（例えば、HTML、ANSIカラーエスケープシーケンス、@LaTeX{}など）を既に認識できます。
+バージョン2.0からは、このマニュアルで後で説明する簡単なシンタックスを使って、入力ソースとなる言語を独自に記述することができます（@pxref{Language Definitions}）。
+バージョン2.1からは、このマニュアルで後で説明する簡単なシンタックスを使って、出力フォーマットの言語を独自に記述することができます（@pxref{Output Language Definitions}）。
+バージョン2.2からは、@emph{ctags}プログラム（@url{http://ctags.sourceforge.net}）に頼る形ではありますが、クロスリファレンス（例えば、変数名やフィールド名などに対するもの）を生成することができるようになりました（@pxref{Generating References}）。
 
 @cindex library
-バージョン3.0からは、GNU Source-highlightがC++ライブラリも提供するようになった。
-これは、C++プログラマが自分のプログラムにハイライトの機能を追加できるようにするためのものだ。
-@inforef{導入,,source-highlight-info}
+バージョン3.0からは、GNU Source-highlightがC++ライブラリも提供するようになりました。
+これは、C++プログラマが、自分のプログラムにハイライトの機能を追加できるようにするためのものです。
+@inforef{Introduction,,source-highlight-info}.
 
 @menu
-* サポートしている言語::         
-* source-highlight-settingsプログラム::  
-* いくつかの言語についての注意::     
-* 簡単なフォーマッタとしてのsource-highlightの使用::  
-* 関連するソフトウェアとリンク::  
+* Supported languages::         
+* The program source-highlight-settings::  
+* Notes on some languages::     
+* Using source-highlight as a simple formatter::  
+* Related Software and Links::  
 @end menu
 
-@node サポートしている言語, source-highlight-settingsプログラム, 導入, 導入
+
+@node Supported languages, The program source-highlight-settings, Introduction, Introduction
 @section サポートしている言語
 
-Source-highlight（@value{VERSION}）で本来サポートされている言語（要するにファイルの拡張子）の完全なリストは、@code{--lang-list}で報告されるものと同じであるが、以下のものである。
+Source-highlight（@value{VERSION}）で本来サポートしている言語（要するにファイルの拡張子）の完全なリストは、@code{--lang-list}で報告されるものと同じです。
+以下に示します。
 
 @example
 @include lang-list.texinfo
 @end example
 
-Source-highlight（@value{VERSION}）で本来サポートされている出力フォーマットの完全なリストは、@code{--outlang-list}で報告されるものと同じであるが、以下のものである。
+Source-highlight（@value{VERSION}）で本来サポートしている出力フォーマットの完全なリストは、@code{--outlang-list}で報告されるものと同じです。
+以下に示します。
 
 @example
 @include outlang-list.texinfo
 @end example
 
 @noindent
-@code{-css}と後ろに付いているものについては、@ref{出力言語マップ}で説明する@footnote{バージョン2.9までは、@code{-doc}や@code{-css-doc}という接尾辞もあったのだが、この仕組みがかなり混乱を招く複雑なものだった。うまくいけば、この新しいもののほうが良いはずだ}。
+@code{-css}という接尾辞については別の節で説明します（@pxref{Output Language map}）@footnote{バージョン2.9までは、@code{-doc}や@code{-css-doc}という接尾辞もありました。
+この仕組みがかなり混乱を招く複雑なものでした。
+上手く行くならば、こちらの新しいもののほうが良いはずです。}。
+
+私は、個人的には、こういった言語の定義を全てテストしているわけではありませんので、留意してください。
+実際、定義ファイルが文法的に正しいことは、コマンドラインオプションの@code{--check-lang}と@code{--check-outlang}を使ってチェックしています（@pxref{Invoking source-highlight}）。
+しかし、定義が、その言語のシンタックスを本当に遵守しているかどうかは確かめてはいません（例えば、インターネットで情報を探して、言語の定義を作り上げたものがありますが、その言語でプログラムを書いた経験はなかったりします）。
+ですから、的確ではない言語の定義があったならば教えてください。
+そして、また、@file{test}ディレクトリに入っていない言語のプログラム例を持っている場合は、テストスイートに入れられるように、それを私に送ってください。
 
-留意しおいてほしいのだが、私は、個人的には、こういった言語の定義を全てテストしているわけではない。
-実のところ、定義ファイルが文法的に正しいことは（コマンドラインオプションの@code{--check-lang}と@code{--check-outlang}を使って @ref{source-highlightの起動}）チェックしているが、それらの定義がその言語のシンタックスを本当に遵守しているかは確かめてはいない（たとえば、インターネットで情報を探して言語の定義を作り上げたものがあるが、私がその言語でプログラムを書いた経験はなかったりする）。
-なので、的確ではない言語の定義があったならば教えてほしい。
-そしてまた、@file{test}ディレクトリに入っていない言語のプログラム例を持っている場合は、それを私に送ってほしい。
-そうすれば、そのテストスイートに入れることができる。
 
-@node source-highlight-settingsプログラム, いくつかの言語についての注意, サポートしている言語, 導入
+@node The program source-highlight-settings, Notes on some languages, Supported languages, Introduction
 @section @code{source-highlight-settings}プログラム
 
 @cindex source-highlight-settings
-バージョン3.0から、GNU Source-highlightには、@code{source-highlight-settings}というプログラムも入っている。
-これは、source-highlightがその言語の定義ファイルやその他の設定ファイルが見つけられるかどうかをチェックして、念の為、ユーザのホームディレクトリの中の設定ファイルに正しい設定を格納するのに使われる。
+バージョン3.0からは、GNU Source-highlightには、@code{source-highlight-settings}というプログラムも入っています。
+このプログラムは、言語の定義ファイルやその他の設定ファイルをsource-highlightが見つけられるかどうかをチェックし、念の為、ユーザのホームディレクトリの設定ファイルに正しい設定を格納するのに使われます。
 
 @cindex source-highlight.conf
-特に、この格納された設定ファイルは@file{source-highlight.conf}というもので、@file{$HOME/.source-highlight/}の中に収められる。
+具体的には、この格納設定ファイルは@file{source-highlight.conf}という名前で、@file{$HOME/.source-highlight/}の中に収められます。
 
 @cindex @code{--data-dir}
-差し当たり、このファイルには@code{--data-dir}のためのデフォルト値が格納される。
+差し当たり、このファイルには、@code{--data-dir}のデフォルト値が格納されます。
 
-ユーザは、
 @cindex @code{SOURCE_HIGHLIGHT_DATADIR}
-@code{SOURCE_HIGHLIGHT_DATADIR}環境変数を使って、いつでもこの設定ファイルの内容と、ハードコードされているデフォルト値をオーバーライドしてよい。
+@code{SOURCE_HIGHLIGHT_DATADIR}環境変数を使って、この設定ファイルの内容とハードコードされているデフォルト値をいつでもオーバーライドして構いません。
 
-@node いくつかの言語についての注意, 簡単なフォーマッタとしてのsource-highlightの使用, source-highlight-settingsプログラム, 導入
+
+@node Notes on some languages, Using source-highlight as a simple formatter, The program source-highlight-settings, Introduction
 @section いくつかの言語についての注意
 
-このセクションでは、特定の言語のハイライティングについて細部に触れるつもりだ。
-これらのノートは、ハイライティングされる言語が、コマンドラインでのさらなる指定が必要な「方言」を持つような場合に役に立つかもしれない（たとえば、特定の方言を選択するためなど）。
+このセクションでは、特定の言語のハイライティングについて詳細に触れます。
+ハイライティングされる言語が、コマンドラインでさらに指定が必要な「方言」を持つような場合、ここでの記述が役に立つかもしれません（例えば、特定の方言を選択するためなど）。
 
 @menu
 * Fortran::                     
 * Perl::                        
 @end menu
 
-@node Fortran, Perl, いくつかの言語についての注意, いくつかの言語についての注意
+
+@node Fortran, Perl, Notes on some languages, Notes on some languages
 @subsection Fortran
 
 @cindex Fortran
-Toby Whiteが私に説明したように、Fortranは別々の「フレイバー」に分かれた状態になっている。
-ソースファイル内でのカラムの位置によって意味が変わってしまう文字がある固定フォーマットと、そういうことの無いフリーフォーマットである。
-たとえば、前者は、@code{*}と@code{c}によってコマンドライン（訳注：コメント行の間違い？）が開始されるが、それはその文字が最初のカラムで指定されたときだけだ（一方、フリーフォーマットではこういうことは無い）。
+Toby Whiteが私に説明してくれましたが、Fortran言語は、異なる「フレイバー」に分かれた状態になっています。
+固定フォーマットとフリーフォーマットです。
+固定フォーマットは、ソースファイル内のカラム位置によって意味が変わってしまう文字があります。
+フリーフォーマットではそういうことがありません。
+例えば、前者は、@code{*}と@code{c}によってコマンドライン@footnote{訳注：コメント行の間違いか。}が開始されますが、これは、その文字が最初のカラムで指定された時だけです。
+一方、フリーフォーマットではこういうことはありません。
+
+デフォルトでは、Fortranファイルについてフリーフォーマットを想定しています。
+固定フォーマットが使いたい場合には、@code{--src-lang}というコマンドラインオプションで@code{fortran-fixed}を指定する必要があります。
 
-デフォルトでは、Fortranファイルはフリーフォマットを想定している。
-固定フォーマットが使いたい場合には、@code{--src-lang}というコマンドラインオプションで@code{fortran-fixed}を指定する必要がある。
 
-@node Perl,  , Fortran, いくつかの言語についての注意
+@node Perl,  , Fortran, Notes on some languages
 @subsection Perl
 
 @cindex Perl
-Perlの文法形式、特にその正規表現の仕様は、かなり悪夢だ;-)
-@file{perl.lang}の中で可能な限り記述してみたが、特定の正規表現で正しくハイライトされないものがあるかもしれない。
-実は私はPerlでプログラムを書いたことがないので、あなたのPerlプログラムで正しくハイライトされていない部分があるのならば、Perlのハイライトを改善できるように私に連絡するのを躊躇わないでほしい。
+Perlの文法形式、特に、正規表現の仕様はかなりの悪夢です（;-)）。
+@file{perl.lang}の中で可能な限り記述しましたが、特定の正規表現において正しくハイライトされないことがあるかもしれません。
+実は、私は、Perlでプログラムを書いたことがありません。
+Perlプログラムで正しくハイライトされていない部分があれば、Perlのハイライトを改善できるように、遠慮無く私に連絡してください。
 
 @cindex @code{--infer-lang}
-そしてまた、Perlファイルの標準的な拡張子は@code{.pl}だけれども、Prologの言語定義がsource-highlightに実装されたのがPerlよりも早かったために、デフォルトでは、この拡張子はPrologファイルに割り当てられている。
-しかし、@code{--infer-lang}というコマンドラインオプションを使えば、source-highlightに、入力ファイルの最初の行を調べて言語を検出させるようにすることができる（@ref{入力言語の検出方法}）。
-Perlのハイライティングであることを明示的に指定するのに、@code{--src-lang=perl}というコマンドライン指定を使ってもよい。
+また、Perlファイルの拡張子は@code{.pl}が標準的です。
+けれども、Prologの言語定義がsource-highlightに実装されたのがPerlよりも早かったため、デフォルトでは、Prologファイルにこの拡張子が割り当てられています。
+@code{--infer-lang}というコマンドラインオプションを使えば、入力ファイルの最初の行をsource-highlightに調べさせて、言語を検出させるようにすることができます（@pxref{How the input language is discovered}）。
+Perlのハイライティングであることを明示するのに、@code{--src-lang=perl}というコマンドライン指定を使うこともできます。
 
-@node 簡単なフォーマッタとしてのsource-highlightの使用, 関連するソフトウェアとリンク, いくつかの言語についての注意, 導入
+
+@node Using source-highlight as a simple formatter, Related Software and Links, Notes on some languages, Introduction
 @section 簡単なフォーマッタとしてのsource-highlightの使用
 
-source-highlightを入力ファイルの簡単なフォーマッタとして使うこともできる。
-すなわち、ハイライティングをさせずに使うこともできる@footnote{これは以前のバージョンで可能だったかもしれないが、バージョン2.5から公式にサポートされている機能だ}。
+入力ファイルの簡単なフォーマッタとしてsource-highlightを使うこともできます。
+つまり、ハイライティングをさせずにsource-highlightを使うこともできます@footnote{以前のバージョンでも可能だったかもしれませんが、バージョン2.5から公式にサポートされている機能です。}。
 
 @cindex nohilite.lang
-これを実現するには、コマンドラインオプションの@code{--lang-def}を使って、入力ソースに対する言語定義ファイルとして、@file{nohilite.lang}を指定する（@ref{source-highlightの起動}）。
-その言語定義は空なので、ハイライティングは実行されない。
-だが、source-highlightは入力ファイルを指定された出力フォーマットに変換する。
-@ref{サポートしている言語}にある入力言語の関連付けにおいて、@file{nohilite.lang}がtxtファイルと関連付けられていることに注意してほしい。
+これを行うには、コマンドラインオプションの@code{--lang-def}を使って、入力ソースに対する言語定義ファイルとして@file{nohilite.lang}を指定します（@pxref{Invoking source-highlight}）。
+この言語定義は空なので、ハイライティングは実行されません。
+しかし、入力ファイルは、指定された出力フォーマットに変換されます。
+別の節で示す入力言語の関連付けにおいて、@file{nohilite.lang}がtxtファイルと関連付けられていることに注意してください（@pxref{Supported languages}）。
 
-たとえば、これによって、テキストファイルをHTMLや@LaTeX{}に変換したいような場合にsource-highlightが使えるようになる。
-出力の際、事実、source-highlightは、出力フォーマットにおいて特別な意味を持つ文字があっても正しくそれらの文字を生成するだろう。
+例えば、これを使えば、テキストファイルをHTMLや@LaTeX{}に変換したいような場合にsource-highlightが使えるようになります。
+事実、出力の際、出力フォーマットにおいて特別な意味を持つ文字があったとしても、それらの文字は正しく生成されます。
 
 @include txt2texinfo.txt
 
-これが上のセンテンスのTexinfoソースだ:
+上のセンテンスのTexinfoソースが以下です。
 
 @include txt2texinfo.txt.texinfo
 
 @noindent
-これは、source-highlightによってハイライト無しの単純なテキストファイルとして処理されたものだ。
-しかし、Texinfoでフォーマットされていたので、必要なエスケープ処理が自動的に実行された。
-このように、コードとその結果を同じドキュメントの中に簡単に挿入できる（ここでの例のように）。
+これは、ハイライト無しの単純なテキストファイルとしてsource-highlightによって処理されたものです。
+Texinfoでフォーマットされていましたので、必要なエスケープ処理が自動的に実行されました。
+このようにすれば、同じドキュメントの中に、コードとその結果を挿入するのが簡単になります。
 
-これは実際にsource-highlightが実行したフォーマットだ。
-コメントを除いて、これが、手作業でやる場合に基本的に自分で書かなければならないことである:
+source-highlightがフォーマットを実際に実行したのが以下です。
+コメントを除いて、これが、手作業でやる場合に、基本的に自分で書かなければならないことです。
 
 @include txt2texinfo.txt.texinfo.texinfo
 
 @cindex failsafe
-特定の入力言語をsource-highlightが処理しない場合に、さらに@code{--failsafe}オプションを使うことができ(@ref{source-highlightの起動})、そしてその場合はハイライトは実行されないが、source-highlightは入力ファイルを出力フォーマットに変換する。
+特定の入力言語をsource-highlightが処理しない場合、さらに、@code{--failsafe}オプションを使うことができます（@pxref{Invoking source-highlight}）。
+その場合、ハイライトは実行されませんが、入力ファイルは出力フォーマットに変換されます。
 
 @cindex default.lang
-だが、入力言語が確認できなかった場合には、@file{default.lang}が使われる。
-これは空の言語定義ファイルだが、これをカスタマイズしたいと考えることもあるかもしれない。
+しかしながら、入力言語が確認できなかった場合には、@file{default.lang}が使われますので注意してください。
+これは、空の言語定義ファイルです。
+このファイルをカスタマイズしたい場合もあるでしょう。
+
 
-@node 関連するソフトウェアとリンク,  , 簡単なフォーマッタとしてのsource-highlightの使用, 導入
+@node Related Software and Links,  , Using source-highlight as a simple formatter, Introduction
 @section 関連するソフトウェアとリンク
 
-ここに、バックエンドとして使ったり（つまりsource-highlightへのインターフェイスを用意している）、その特徴の一部を使ったり（たとえば、定義ファイル）という意味において、source-highlightと関連しているソフトウェアを挙げていく:
+ここで、バックエンドとして使ったり（source-highlightへのインターフェイスを用意していたり）、あるいは、その特徴（例えば、定義ファイル）の一部を使ったりという意味においてsource-highlightと関連しているソフトウェアを挙げていきます。
 
 @itemize
-
 @item
 @cindex Source-Highlight-Qt
 @cindex Qt
-Source-highlight-qtは、GNU Source-Highlightライブラリに依存して、Qtドキュメントの中でシンタックスのハイライティングを実行するためのライブラリである。
-このライブラリは、qtの抽象クラスのQSyntaxHighlighterの実装を提供していて、Qt3とQt4の両方に対応している。
+Source-highlight-qtは、Qtドキュメントの中でシンタックスのハイライティングを実行するためのライブラリです。
+GNU Source-Highlightライブラリに依存しています。
+qtの抽象クラスであるQSyntaxHighlighterの実装を提供していて、Qt3とQt4の両方に対応しています。
 
 @uref{http://srchiliteqt.sourceforge.net}.
 
 @item
 @cindex QSource-Highlight
 @cindex Qt
-QSource-Highlightは、GNU Source-HighlightのQt4フロントエンドだ（Source-Highlight-Qtライブラリに依存している）。
-コードをオンザフライでハイライトすることができ、source-highlightがサポートしている全てのフォーマットでハイライトされた出力を得ることができる（たとえば、HTML、LaTeX、Texinfoなど）。
-それから、フォーマットされた出力をコピーし、それをペーストできる（たとえば、ブログなどに）。
-またファイルに保存することもできる。
-いくつかの出力フォーマット（たとえば、HTML、XHTMLなど）については、ハイライトされた出力のプレビューを見ることができる。
+QSource-Highlightは、GNU Source-HighlightのQt4フロントエンドです（Source-Highlight-Qtライブラリに依存しています）。
+オンザフライ@footnote{訳注：中間ファイルを作成しないことか。}でコードをハイライトすることができます。
+また、source-highlightがサポートしている全フォーマット（例えば、HTML、LaTeX、Texinfoなど）について、ハイライトされた出力を得ることができます。
+それから、フォーマットされた出力をコピーし、例えば、ブログなどにペーストすることができます。
+あるいは、ファイルに保存することもできます。
+出力フォーマット（例えば、HTML、XHTMLなど）によっては、ハイライトされた出力のプレビューを見ることができます。
 
 @uref{http://qsrchilite.sourceforge.net}.
 
 @item
 @cindex SourceHighlightIDE
 @cindex KDE
-SourceHighlightIDEは、新たなsource-highlight用の言語定義を開発したりデバッグしたりするために私が書いた小さなIDE（KDE用）だ。
+SourceHighlightIDEは、新たなsource-highlight用の言語定義を開発したり、デバッグしたりするために私が書いた小さなIDE（KDE用）です。
 
 @uref{http://srchighliteide.sourceforge.net}.
 
 @item 
 @cindex Ksrc2highlight
 @cindex KDE
-Martin Gebertがsource-highlightプログラムのKDEインターフェイスを実装した（彼は素晴しい仕事をしてくれた）。
-@emph{Ksrc2highlight}というものだ。
-試してみたい場合は以下:
+Martin Gebertは、source-highlightプログラムのKDEインターフェイスを実装しました（彼は、素晴しい仕事をしました）。
+@emph{Ksrc2highlight}と呼ばれます。
+試してみたい場合は以下を見てください。
 
 @uref{http://www.mgebert.de/Ksrc2highlight}.
 
 @item
 @cindex java2html
-java2htmlのJavaバージョンもある。
-以下のところにある。
+Java版のjava2htmlというのもあります。
+以下のところにあります。
 
 @uref{http://www.generationjava.com/projects/Java2Html.shtml}.
 
 @item
-このウェブサイトはオンラインでハイライティングをするためのsource-highlightのインターフェイスを提供している。
+次のウェブサイトは、オンラインでハイライティングをするためのsource-highlightのインターフェイスを提供しています。
 
-@uref{http://www.alaide.com/outils_colorsyntaxe.php}
+@uref{http://www.alaide.com/outils_colorsyntaxe.php}.
 
 @item
 @cindex SHJS
-SHJSは、HTMLドキュメントの中でソースコード片をハイライトするJavaScriptプログラムだ。
-SHJSを使ったドキュメントはウェブブラウザによってクライアントサイドでハイライトされる。
-SHJSはSource-highlightの言語定義を使用している。
+SHJSは、HTMLドキュメントの中でソースコード片をハイライトするJavaScriptプログラムです。
+SHJSを使ったドキュメントは、ウェブブラウザによってクライアントサイドでハイライトされます。
+SHJSはSource-highlightの言語定義を使用しています。
 
-@uref{http://shjs.sourceforge.net}
+@uref{http://shjs.sourceforge.net}.
 
 @item
 @cindex code2blog
-Code2blogは、source-highlightのpyGTKフロントエンドで、ソースコードをHTMLへ簡単に変換するためのものだ。
+Code2blogは、source-highlightのpyGTKフロントエンドです。
+ソースコードをHTMLへ簡単に変換するためのものです。
 
-@uref{http://code.google.com/p/code2blog}
+@uref{http://code.google.com/p/code2blog}.
 
 @item
 @cindex Apache
-Andy Buckleyは、source-highlightのラッパを書いた。
-これは、ウェブページの中でソースコードをオンザフライにハイライティングするApacheフィルタとして使うことができる。 
+Andy Buckleyは、source-highlightのラッパを書きました。
+ウェブページで、ソースコードをオンザフライにハイライティングするApacheフィルタとして使うことができます。
 
-@uref{http://www.insectnation.org/projects/filter-src-highlight}
+@uref{http://www.insectnation.org/projects/filter-src-highlight}.
 
 @item
 @cindex RapidWeaver
-Roger Nilssonは、RapidWeaverというOSX用のポピュラーなウェブデザインアプリケーションで使えるsource-highlightのフロントエンドを書いた。
-このフロントエンドはHigh-Lightと言うもので、RapidWeaverの内部で、ユーザが簡単にシンタックスが色付けされたコードを追加することができるようにするものだ。
+Roger Nilssonは、RapidWeaverというOSX用のポピュラーなウェブデザインアプリケーションで使えるsource-highlightのフロントエンドを書きました。
+このフロントエンドはHigh-Lightと言うものです。
+RapidWeaverの内部で、シンタックスが色付けされたコードをユーザが簡単に追加することができるようにするものです。
 
-@uref{http://nilrogsplace.se/webdesign/rapidweaver/plugins/high-light/index_en.html}
+@uref{http://nilrogsplace.se/webdesign/rapidweaver/plugins/high-light/index_en.html}.
 
 @item
 @cindex Firefox
-Mauricio Zepedaは、自動的にファイルをハイライトしてFirefoxでそれを表示するスクリプトについて、彼のブログに記事を書いた。 
+Mauricio Zepedaは、自動的にファイルをハイライトし、Firefoxでそれを表示するスクリプトについてブログに記事を書きました。
 
-@uref{http://chillorb.com/?p=122}
+@uref{http://chillorb.com/?p=122}.
 
 @item
 @cindex Wiki
 @cindex Ikiwiki
-Jason Blevinsは、ソースコード片やファイル全体のシンタックスハイライティングを有効にするIkiwiki用のプラグインを作成した。
+Jason Blevinsは、Ikiwiki用のプラグインを作成しました。
+このプラグインは、source-highlightを使って、ソースコード片やファイル全体のシンタックスハイライティングを有効にするものです。
 
-@uref{http://jblevins.org/projects/ikiwiki/code}
+@uref{http://jblevins.org/projects/ikiwiki/code}.
 
 @item
 @cindex Wiki
 @cindex Php
-Pascal Bleserは、プロセスを生成したり、source-highlightのCGIを使うのではなく、PHPから直接GNU source-highlightライブラリを使うPHP拡張を作成した。
-
-@uref{http://code.google.com/p/php-source-highlight/}
-
+Pascal Bleserは、PHPから直接GNU source-highlightライブラリを使うPHP拡張を作成しました。
+プロセスを生成したり、source-highlightのCGIを使うものではありません。
 
+@uref{http://code.google.com/p/php-source-highlight/}.
 @end itemize
 
 
-@node インストール, Copying, 導入, Top
+@node Installation, Copying, Introduction, Top
 @chapter インストール
 @cindex インストール
 
-ビルドやインストールの詳細については@file{INSTALL}を見てほしい。
-そもそも、ソースで入手したLinuxソフトウェアをコンパイルするのに慣れているのであれば、いつもの手順を単に辿ればよい。
-すなわち、ディレクトリにダウンロードしたファイルをuntarして、それから以下のようにする:
+構築やインストールの詳細については@file{INSTALL}を見てください。
+そもそも、ソースで入手したLinuxソフトウェアをコンパイルするのに慣れているのであれば、いつもの手順を単に辿れば良いです。
+つまり、ディレクトリにダウンロードしたファイルをuntarして、それから、次のようにします。
 
 @example
 cd <source code main directory>
@@ -359,253 +379,273 @@ make
 make install
 @end example
 
-しかし、これを実行する前には、source-highlightをビルドするのに必要なものが全てそろっているかチェックしてほしい。
-@ref{source-highlightのビルドに必要なもの}
+これを実行する前には、source-highlightを構築するのに必要なものが全て揃っているかチェックするようにしてください。
+@xref{What you need to build source-highlight}.
 
-注意：./configureの@code{--prefix}オプションで違うインストールディレクトリを指定した（たとえば、@code{./configure --prefix=<your home>}）のでない限り、@code{make install}の実行にはrootになっている必要がある。
+注意：./configureの@code{--prefix}オプションで別のインストールディレクトリを指定した（例えば、@code{./configure --prefix=<your home>}）のでなければ、@code{make install}の実行にはrootになっている必要があります。
 
-configureスクリプトに渡すことのできるオプションが全て見るのには、@code{./configure --help}を実行してほしい。
+configureスクリプトに渡せるオプションを全て見る場合には、@code{./configure --help}を実行してください。
 
 @cindex directories
-
-各ファイルは以下のディレクトリへインストールされる:
+各ファイルは、以下のディレクトリへインストールされます。
 
 @table @code
 @item 実行ファイル
         @code{prefix/bin}
+
 @item ドキュメントと出力例
         @code{prefix/share/doc/source-highlight}
+
 @item ライブラリの例
         @code{prefix/share/doc/source-highlight/examples}
-@item ライブラリAPIのドキュメンテーション
+
+@item ライブラリAPIのドキュメント
         @code{prefix/share/doc/source-highlight/api}
+
 @item 設定ファイル
         @code{prefix/share/source-highlight}
 @end table
 
-prefixのデフォルト値は@code{/usr/local}だが、configureの@code{--prefix}オプションで変更してもよい。
-@code{configure}のオプションについてさらに詳しくは、@code{configure --help}を実行してほしい。
+prefixのデフォルト値は@code{/usr/local}です。
+configureの@code{--prefix}オプションで変更できます。
+@code{configure}のオプションについて詳しくは、@code{configure --help}を実行してください。
 
 @cindex bash completion
-Tiziano Mullerは、source-highlight用のbashの補完用の設定ファイルを書いた。
-これは@code{sysconfdir/bash_completion.d}というディレクトリにデフォルトでインストールされる。
-@code{sysconfdir}はデフォルトで@code{prefix/etc}になっている。
-しかし通常、bashの補完スクリプトが設定ファイルを探すディレクトリは、@code{/etc/bash_completion.d}だ。
-なので、configureスクリプトのコマンドラインオプションの@code{--with-bash-completion}を使うことで、このディレクトリを明示的に指定することをお勧めする。
+Tiziano Mullerは、source-highlight用のbash補完設定ファイルを書きました。
+@code{sysconfdir/bash_completion.d}というディレクトリにデフォルトでインストールされます。
+@code{sysconfdir}はデフォルトでは@code{prefix/etc}です。
+しかし、通常、bashの補完スクリプトが設定ファイルを探すディレクトリは@code{/etc/bash_completion.d}です。
+ですから、configureスクリプトのコマンドラインオプション@code{--with-bash-completion}を使って、このディレクトリを明示することを推奨します。
 
 @cindex library
 @cindex @code{--with-doxygen}
 @cindex doxygen
-Source-highlightライブラリのAPIドキュメンテーションをビルドしてインストールしたい場合には、@code{--with-doxygen}というオプションを付けて@code{configure}を実行する必要があるが、このドキュメンテーションをビルドするのに@emph{Doxygen} @url{http://www.doxygen.org}というプログラムが必要となる。
-ドキュメンテーションは次のディレクトリにインストールされる。
+Source-highlightライブラリのAPIドキュメントを構築し、インストールしたい場合には、@code{--with-doxygen}オプションを付けて@code{configure}を実行する必要があります。
+このドキュメントを構築するには、@emph{Doxygen} @url{http://www.doxygen.org}というプログラムが必要です。
+ドキュメントは、次のディレクトリにインストールされます。
 
 @table @code
-@item ライブラリAPIドキュメンテーション
+@item ライブラリAPIドキュメント
         @code{prefix/share/doc/source-highlight/api}
 @end table
 
 
 @cindex java2html
 @cindex cpp2html
-注意：もともとは、Source-highlightではなく、@emph{GNU java2html}と@emph{GNU cpp2html}という名前の、二つの別個のプログラムであった。
-移行を容易にするために、Source-highlightと一緒に同名のシェルスクリプトが二つインストールされる（しかし、それを使うのはお勧めしない。deprecatedだ）。
+注意：もともとは、Source-highlightではなく、@emph{GNU java2html}と@emph{GNU cpp2html}という名前の二つの別個のプログラムでした。
+移行を容易にするために、同名の二つのシェルスクリプトがSource-highlightと一緒にインストールされます。
+ただし、使用するのは推奨しません。
+deprecatedです。
 
 @menu
-* qmakeでのビルド::         
-* ダウンロード::                    
-* Gitの匿名チェックアウト::      
-* source-highlightのビルドに必要なもの::  
-* Boost Regexライブラリのインストールに関するTips::  
-* 前のバージョンからのパッチ::  
-* lessでのsource-highlightの使用::  
-* source-highlightのCGIとして使用::  
-* .rpmのビルド::               
+* Building with qmake::         
+* Download::                    
+* Anonymous Git Checkout::      
+* What you need to build source-highlight::  
+* Tips on installing Boost Regex library::  
+* Patching from a previous version::  
+* Using source-highlight with less::  
+* Using source-highlight as a CGI::  
+* Building .rpm::               
 @end menu
 
-@node qmakeでのビルド, ダウンロード, インストール, インストール
-@section qmakeでのビルド
+
+@node Building with qmake, Download, Installation, Installation
+@section qmakeでの構築
 @cindex qmake
 
-バージョン3.1.2からは、Qtライブラリ（@uref{http://qt.nokia.com}）のビルドツールである@code{qmake}を使っても@value{srchilite}をビルドすることができるようになった。
-これにより、Unixシェルを持たないWindowsベースのシステム上でも@value{srchilite}をビルドできるようになり、特に、
+バージョン3.1.2からは、Qtライブラリ（@uref{http://qt.nokia.com}）の構築ツールである@code{qmake}を使っても@value{srchilite}を構築することができるようになりました。
+これにより、Unixシェルを持たないWindowsベースのシステム上でも@value{srchilite}を構築できるようになりました。
 @cindex MSVC
-Microsoft MSVCコンパイラでも@value{srchilite}がビルドできるようになった。
-このやり方はUnixシェルが無かったり、あるいは、MSVCコンパイラを本当に使う必要がある場合にだけ使うべきだ（たとえば、MSVCベースのプログラムで使うのに@value{srchilitelib}をビルドしたい場合）。（訳注：原文に閉じカッコが見当たらないのでここに入れてみた）
+特に、Microsoft MSVCコンパイラでも@value{srchilite}が構築できるようになりました。
+この方法は、Unixシェルが無かったり、あるいは、MSVCコンパイラを本当に使う必要がある場合（例えば、MSVCベースのプログラムで使うのに@value{srchilitelib}を構築したい場合）@footnote{訳注：原文に閉じカッコが見当たらないのでここに入れてみました。}にだけ使用すべきです。
 @cindex boost
-さらにboost regexライブラリも必要で、MSVCを使う場合は、このライブラリのインストールパッケージが@url{http://www.boostpro.com}で手に入る。
+さらに、boost regexライブラリも必要です。
+MSVCを使う場合は、このライブラリのインストールパッケージが@url{http://www.boostpro.com}で入手できます。
 
-このビルドメカニズムはまだ実験的なもので、MSVCを使うときには、@value{srchilitelib}の静的バージョンだけをビルドできる（.dllではない）。
+この構築メカニズムはまだ実験的なものです。
+MSVCを使う時には、@value{srchilitelib}の静的バージョンだけが構築できます（.dllではありません）。
 @cindex MinGW
-また、MinGWコンパイラ(@uref{http://www.mingw.org})があって（たとえば、QtのWindowsディストリビューションと一緒に来るものがある）、
 @cindex msys
-Msys(@uref{http://www.mingw.org/wiki/MSYS})が無いような場合には、この方法を使うこともできる。
-そうなければ、やはり@code{configure}ベースのメカニズムを使うべきだ。
+また、MinGWコンパイラ（@uref{http://www.mingw.org}）があって（例えば、QtのWindowsディストリビューションと一緒に来るものがあります）、Msys（@uref{http://www.mingw.org/wiki/MSYS}）が無いような場合には、この方法を使うこともできます。
+それ以外の場合は、やはり、@code{configure}ベースのメカニズムを使うべきでしょう。
 
-@code{qmake}を使うとき、ビルドの際に指定できるオプション（おまけにqmakeを使うときには普通使うもの）が少しあって、これらのオプションは環境変数を使ってだけ指定することができる:
+@code{qmake}を使う時、構築の際に指定できるオプション（その上、qmakeを使う時には普通使うもの）が以下のように少しだけあります。
+これらのオプションは、環境変数を使ってだけ指定することができます。
 
 @table @code
 @item BOOST_REGEX
-デフォルトでは、@code{boost_regex}がboostライブラリをリンクするのに使われる（つまり@code{-lboost_regex})）。
-boost regexライブラリが違う名前になっている場合は、この環境変数を使って名前を指定しなければならない。
-たとえば、@code{libboost_regex-mt.lib}や@code{boost_regex-mt.dll}という名前のライブラリファイルの場合は、この変数を@code{boost_regex-mt}にセットしなければならない。
+デフォルトでは、boostライブラリをリンクするのに@code{boost_regex}が使われます（つまり、@code{-lboost_regex}）。
+boost regexライブラリが違う名前になっている場合は、この環境変数を使って名前を指定しなければなりません。
+例えば、@code{libboost_regex-mt.lib}や@code{boost_regex-mt.dll}という名前のライブラリファイルの場合は、この変数を@code{boost_regex-mt}にセットしなければなりません。
+
 @item INCPATH
-boostヘッダファイルのパスを指定する。
+boostヘッダファイルのパスを指定します。
+
 @item LIBS
-boost libファイルのパスを指定する。
+boost libファイルのパスを指定します。
 @end table
 
-boostライブラリのインクルードパスとライブラリパスの指定は、システムパスディクレトリにそれらが無いのであれば、完全にあなたが@code{INCPATH}と@code{LIBS}を使って決めることだいうことを考慮に入れておいてほしい。
+boostライブラリのインクルードパスとライブラリパスの指定は、システムパスのディクレトリにライブラリバスが無いのであれば、@code{INCPATH}と@code{LIBS}を使ってユーザが完全に決めるということを考慮に入れておいてください。
+
+また、qmakeを実行する時には、@code{-recursive}というオプションを必ず使うということを覚えていてください。
 
-また、qmakeを実行するときには、@code{-recursive}というオプションを常に使うということを覚えていてほしい。
+次に、@code{make install}を実行したい場合には、@code{INSTALL_ROOT}変数を使って、インストールするパスのプリフィックスを指定することができます。
+そうしない場合、そのパスはルートディレクトリです。
 
-次に、@code{make install}を実行したい場合には、@code{INSTALL_ROOT}変数を使って、インストールするパスのプリフィックスを指定することができる。
-そうしない場合はパスはルートディレクトリである。
 
-@node ダウンロード, Gitの匿名チェックアウト, qmakeでのビルド, インストール
+@node Download, Anonymous Git Checkout, Building with qmake, Installation
 @section ダウンロード
 @cindex download
 
-GNUのftpサイト:@uref{ftp://ftp.gnu.org/gnu/src-highlite}や、そのミラーサイト（@uref{http://www.gnu.org/prep/ftp.html}を見よ）のいずれかからダウンロードすることができる。
+GNUのftpサイト@uref{ftp://ftp.gnu.org/gnu/src-highlite}やミラーサイト（@uref{http://www.gnu.org/prep/ftp.html}を見よ）のいずれかからダウンロードができます。
 
-私はWindowsバイナリをもう配布しない。
-@uref{http://www.cygwin.com}から入手できるCygnus C/C++コンパイラでビルドが可能だからだ。
-しかし、そういったコンパイラをダウンロードしたくなかったり、Boost Regexライブラリについて問題を感じているような場合には（@ref{Boost Regexライブラリのインストールに関するTips}を参照のこと。留意してほしいのだが、これらのライブラリがインストールされていなくて、使用しているC/C++コンパイラのディストリビューションにビルド済みのパッケージが用意されていなければ、ソースからBoostライブラリをビルドするのにいくらか時間がかかるかもしれない。数時間かかることも考えられる）、メールで直接そういったバイナリを私にリクエストしてもよい（メールアドレスは私のホームページを見てほしい）。
-喜んでお送りするつもりだ。
-Source-highlightのMS-Windowsポートの一つが@uref{http://gnuwin32.sourceforge.net}から入手できる。
-しかし、私はそれらのバイナリを個人的にメンテナンスしていないし、古くなっているかもしれない。
+Windowsバイナリはもう配布しません。
+@uref{http://www.cygwin.com}から入手できるCygnus C/C++コンパイラで構築が可能だからです。
+しかし、そういったコンパイラをダウンロードしたくなかったり、Boost Regexライブラリ（see also @ref{Tips on installing Boost Regex library}.
+留意しておいてほしいですが、これらのライブラリがインストールされていなくて、使用しているC/C++コンパイラのディストリビューションに構築済みのパッケージが用意されていなければ、ソースからBoostライブラリを構築するのにいくらか時間がかかるかもしれません。数時間かかることも考えられます）について問題を感じているような場合には、そういったバイナリをメールで直接私にリクエストしても構いません（メールアドレスについては私のホームページで探してください）。
+喜んでバイナリを送ります。
+Source-highlightのMS-Windowsポートの一つは、@uref{http://gnuwin32.sourceforge.net}から入手できます。
+しかし、私は、このバイナリを個人的にメンテナンスしていませんし、古くなっていることもあるかもしれません。
 
-アーカイブはGNU gpg(@uref{http://www.gnupg.org})を使って私がデジタル署名している。
-私のGPGのパブリックキーは私のホームページ（@value{myhomepage}）で見つけられる。
+アーカイブには、GNU gpg（@uref{http://www.gnupg.org}）を使って私がデジタル署名しています。
+GPGのパブリックキーは私のホームページ（@value{myhomepage}）で見つけられます。
 
-個別のリリースのもが利用可能であれば、パッチも入手できる（以前のバージョンからのパッチについては後述）。
+個別のリリースに対するパッチが利用できる場合、パッチも入手できます（以前のバージョンからのパッチについては後述します）。
 
-@node Gitの匿名チェックアウト, source-highlightのビルドに必要なもの, ダウンロード, インストール
-@section Anonymous Git Checkout
+
+@node Anonymous Git Checkout, What you need to build source-highlight, Download, Installation
+@section Gitの匿名チェックアウト
 
 @cindex Git
-このプロジェクトのgitリポジトリは、以下のクローン化の手順を通してチェックアウトすることができる@footnote{Source-highlightのバージョン3.1.2から、Git(@uref{http://git-scm.com/})を採用することでCVSリポジトリは使わなくなった}:
+このプロジェクトのgitリポジトリは、以下のクローン化の手順を行ってチェックアウトすることができます@footnote{Source-highlightのバージョン3.1.2から、Git（@uref{http://git-scm.com/}）を採用しましたので、CVSリポジトリは使わなくなりました}。
 
 @example
 git clone git://git.savannah.gnu.org/src-highlite.git
 @end example
 
-詳しい手順については次のアドレスで見つけられる:
+詳しい手順については次のアドレスで見つけられます。
 
 @uref{http://savannah.gnu.org/projects/src-highlite}.
 
-そして、gitリポジトリは次のアドレスでオンラインで見ることもできる:
+また、gitリポジトリは、次のアドレスからオンラインで見ることができます。
 
 @uref{http://git.savannah.gnu.org/cgit/src-highlite.git}.
 
-このように、Source-highlightの最新の開発ソースを手に入れられるが、それは不安定なものかもしれないことに注意してほしい。
-このプログラムを修正したり拡張したりする場合には、この方法がベストである。
-パッチを私に送るのに、そのパッチは、Gitリポジトリの最新のソースに対するものであるべきだ。
+以上のようにすれば、Source-highlightの最新の開発ソースを手に入れられます。
+ただし、不安定なものかもしれないので注意してください。
+このプログラムを修正したり拡張したりする場合には、この方法がベストです。
+パッチを私に送る場合、パッチは、Gitリポジトリの最新のソースに対するものにしてください。
 
-反対に、指定したリリースのソースをgitを通して入手したい場合、たとえばバージョンX.Y.Zならば、rel_X_Y_Zというタグを指定しなければならない。
+反対に、指定したリリースのソースをgit経由で入手したい場合、例えば、バージョンX.Y.Zならば、rel_X_Y_Zというタグを指定しなければなりません。
 
-Gitリポジトリから手に入れたソースをコンパイルするとき、@code{configure}や@code{make}コマンドを初めて実行する前に次のコマンドを実行しなければならない:
+Gitリポジトリから入手したソースをコンパイルする場合、@code{configure}や@code{make}コマンドを最初に実行する前に次のコマンドを実行しなければなりません。
 
 @example
 autoreconf -i
 @end example
 
 @noindent
-これによってautotoolsのコマンドが正しい順番に実行され、ひょっとしたら欠けているかもしれないファイルもコピーしてくれるだろう。
-これを成功させるためには、
+これによって、autotoolsのコマンドが正しい順番に実行されます。
+ひょっとしたら欠けているかもしれないファイルもコピーしてくれるでしょう。
 @cindex automake
 @cindex autoconf
 @cindex libtool
-@code{automake}と@code{autoconf}、@code{libtool}の最近のバージョンがインストールされていたほうがよい。
+これを成功させるには、@code{automake}、@code{autoconf}、@code{libtool}の最近のバージョンがインストールされていたほうがよいでしょう。
+
 
-@node source-highlightのビルドに必要なもの, Boost Regexライブラリのインストールに関するTips, Gitの匿名チェックアウト, インストール
-@section source-highlightのビルドに必要なもの
+@node What you need to build source-highlight, Tips on installing Boost Regex library, Anonymous Git Checkout, Installation
+@section source-highlightの構築に必要なもの
 
 @cindex compilation requirements
 @cindex building requirements
 
 @cindex boost
-バージョン2.0から、Source-highlightは、boost (@uref{http://www.boost.org})が提供している正規表現に依存しているので、最低でもboostのregexライブラリをインストールする必要がある。
+バージョン2.0からは、Source-highlightは、boost（@uref{http://www.boost.org}）が提供する正規表現に依存しています。
+そのため、boostのregexライブラリを最低でもインストールする必要があります。
 
-ほとんどのGNU/Linuxディストリビューションでは、コンパイルされた状態ですでにこのライブラリが用意されている。
-使用しているディストリビューションのパッケージを使うならば、boostライブラリの開発パッケージも必ずインストールしてほしい。
+ほとんどのGNU/Linuxディストリビューションでは、コンパイルされた状態でこのライブラリが既に用意されています。
+使用ディストリビューションのパッケージを使う場合、boostライブラリの開発パッケージも必ずインストールしてください。
 
-Boost Regexライブラリのインストールに問題がある場合や、このライブラリのためにsource-highlightのコンパイルに問題がある場合には、@ref{Boost Regexライブラリのインストールに関するTips}を見てほしい。
+Boost Regexライブラリのインストールに問題がある場合、あるいは、このライブラリのためにsource-highlightのコンパイルに問題がある場合には、次節を見てください（@pxref{Tips on installing Boost Regex library}）。
 
-（たくさん違うバージョンを使っているため）特定のバージョンのBoost regexライブラリを使いたい場合には、configureの@code{--with-boost-regex}オプションを使って特定のサフィックスを指定することができる。
-たとえば次のようになる。
+多数のバージョンを使っているなどの理由で、特定のバージョンのBoost regexライブラリを使いたい場合には、configureの@code{--with-boost-regex}オプションを使って、特定のサフィックスを指定することができます。
+例えば、次のようになります。
 
 @example
 ./configure --with-boost-regex=boost_regex-gcc-1_31
 @end example
 
-Source-highlightはGNU/Linuxのもとで、gcc (C++)とbison (yacc)、flex (lex)を利用して開発され、@uref{http://www.cygwin.com}から入手できるCygwin C/C++コンパイラでWin32に移植された。
+Source-highlightはGNU/Linux上で開発されました。
+gcc（C++）、bison（yacc）、flex（lex）を利用しています。
+また、@uref{http://www.cygwin.com}から入手できるCygwin C/C++コンパイラを使ってWin32に移植しました。
 
-私は
 @cindex automake
 @cindex autoconf
 @cindex libtool
-GNU Autoconf@footnote{@uref{http://www.gnu.org/software/autoconf}}とGNU Automake@footnote{@uref{http://www.gnu.org/software/automake}}、そしてGNU Libtool@footnote{@uref{http://www.gnu.org/software/libtool}}という素晴しいソフトウェアを使っている。
+私は、GNU Autoconf@footnote{@uref{http://www.gnu.org/software/autoconf}}、GNU Automake@footnote{@uref{http://www.gnu.org/software/automake}}、GNU Libtool@footnote{@uref{http://www.gnu.org/software/libtool}}という素晴しいソフトウェアを使っています。
 @cindex gnulib
-バージョン2.6から、Gnulib - GNU Portablility Library@footnote{@uref{http://www.gnu.org/software/gnulib}}も使い初めた。
-これは「GNUのパッケージ間で共有するための、GNUの共通コードの中心の位置」だ（例を挙げると、@code{getopt_long}関数の存在と正しさのチェックをするのにGnulibに頼っている）。
+バージョン2.6から、Gnulib - GNU Portablility Library@footnote{@uref{http://www.gnu.org/software/gnulib}}も使い始めました。
+これは、「GNUパッケージの間で共有するGNUの共通コードの中心」です（例を挙げると、@code{getopt_long}関数が存在しているか、そして、正しいかをチェックをするのにGnulibに頼っています）。
+
+最後ですが、コマンドラインの解析には@emph{GNU gengetopt}（@uref{http://www.gnu.org/software/gengetopt}）を使いました。
 
-最後に、私はコマンドラインの解析のため、@emph{GNU gengetopt}(@uref{http://www.gnu.org/software/gengetopt})を使った。
+また、動的オーバーロードを許す@emph{doublecpp}（@uref{http://doublecpp.sourceforge.net}）も使い始めました。
 
-動的オーバーロードを許す@emph{doublecpp}(@uref{http://doublecpp.sourceforge.net})も使い始めた。
+実際、boost regexライブラリは別にすると、source-highlightの開発をしたいと思わないかぎり、source-highlightを構築するのに上に挙げたその他のツールは必要ではありません（実際のところ、前述したツールを使って生成した出力ソースが提供されています）。
 
-実際、boost regexライブラリは別にすると、source-highlightの開発をしたいと思わないかぎり、source-highlightをビルドするのに上に挙げたその他のツールは必要ではない（確かに私は前述したツールを使って生成した出力ソースを提供している）。
+しかし、Gitからソースを取得した場合、必要となる他のツールもあります。
+@xref{Anonymous Git Checkout}.
 
-しかし、Gitからソースを取得したのならば、他のツールがいくつか必要となる。
-@ref{Gitの匿名チェックアウト}を参照してほしい。
 
-@node Boost Regexライブラリのインストールに関するTips, 前のバージョンからのパッチ, source-highlightのビルドに必要なもの, インストール
+@node Tips on installing Boost Regex library, Patching from a previous version, What you need to build source-highlight, Installation
 @section Boost Regexライブラリのインストールに関するTips
 
 @cindex Boost regex
 
-source-highlightのコンパイルに何の問題もなければ、幸運にもこのセクションは飛ばしてかまわない@footnote{バージョン2.11からは、boost regexライブラリがコンパイラのデフォルトパスにあれば、@code{configure}スクリプトが正しく見つけてくれるはずだ}。:-)
+source-highlightのコンパイルに何の問題も無ければ、幸運にも、このセクションは飛ばすことができます@footnote{バージョン2.11からは、boost regexライブラリがコンパイラのデフォルトパスにあれば、@code{configure}スクリプトが正しく見つけてくれるはずです}。:-)
 
-このセクションを書いたのは、Boost Regexライブラリをソースからインストールした後の問題を報告してくるユーザが多数いるからだ。
-このライブラリが既に正しくインストールされている場合ですら、source-highlightのコンパイルで問題が起きるユーザも他にいる（特にcygwinを使っているwindowsユーザ）。
-Boost Regexライブラリのインストールや使用に対して、このセクションがいくらかの光を照らしてくれることを期待している。
-このセクションは、Boostライブラリのコンパイルの仕方を説明するものではないことに注意してほしい（@uref{http://www.boost.org}で見つけられるドキュメンテーションはよく出来ている）。
-このセクションは、Boostライブラリのインストールが成功した後でさえ、source-highlightのコンパイルに問題が発生する場合に、事態をどのように調整するかを説明する。
+このセクションを書いたのは、Boost Regexライブラリをソースからインストールした後の問題を報告してくるユーザが多数いるからです。
+このライブラリが既に正しくインストールされている場合ですら、source-highlightのコンパイルで問題が起きるユーザも他にいます（特に、cygwinを使っているwindowsユーザです）。
+Boost Regexライブラリのインストールや使用について、このセクションがいくらかの光を照らしてくれることを期待しています。
+このセクションは、Boostライブラリのコンパイルの仕方を説明するものではないことに注意してください（@uref{http://www.boost.org}にあるドキュメントではきちんと説明されています）。
+このセクションは、Boostライブラリのインストールが成功した後でも、source-highlightのコンパイルに問題が発生する場合に、事態をどのように調整するかを説明します。
 
-まず最初、使用しているディストリビューションがBoost regexライブラリのパッケージを用意している場合、boostライブラリの開発パッケージも必ずインストールしてほしい。
-つまり、それらのパッケージが、ライブラリを使ってプログラムをコンパイルするのに必要なヘッダファイルも提供しているからだ。
-たとえば、私のDebianシステムの場合、@code{libboost-regex}パッケージのほかに、@code{libboost-regex-dev}パッケージをインストールしなければならなかった。
+まず最初に、使用しているディストリビューションがBoost regexライブラリのパッケージを用意している場合には、boostライブラリの開発パッケージも必ずインストールしてください。
+つまり、開発パッケージは、ライブラリを使ってプログラムをコンパイルするのに必要なヘッダファイルも提供しています。
+例えば、Debianシステムの場合、@code{libboost-regex}パッケージのほかに、@code{libboost-regex-dev}パッケージをインストールしなければなりませんでした。
 
-使用しているディストリビューションがこういったパッケージを提供していない場合、そのときは、@uref{http://www.boost.org}からBoostライブラリのソースをダウンロードして、コンパイルとインストールの手順を辿らなければならない。
-しかし、（C++コンパイラのインクルードパスに@file{/usr/local/include}が既に含まれていなければ）インストールのプリフィックスを、デフォルトのプリフィックス@file{/usr/local}に頼るのではなく、@file{/usr}に指定しておくことをお勧めする。
-これによって、source-highlightをコンパイルするのが簡単になるからだ。
-@file{/usr/include}は普通、コンパイル時にC++がヘッダファイルを探索する場所になっているのでこれをお勧めする。
+使用ディストリビューションがこういったパッケージを提供していない場合には、@uref{http://www.boost.org}からBoostライブラリのソースをダウンロードして、コンパイルとインストールの手順を辿らなければなりません。
+しかし、（C++コンパイラのインクルードパスに@file{/usr/local/include}が既に含まれているのでなければ、）インストールのプリフィックスを、デフォルトのプリフィックス@file{/usr/local}に頼るのではなく、@file{/usr}に指定しておくことをお勧めします。
+これによって、source-highlightをコンパイルするのが簡単になるからです。
+また、普通、@file{/usr/include}は、C++のコンパイル時に、ヘッダファイルを探索する場所になっていますので、これをお勧めします。
 
-Boost Regexライブラリをコンパイルしてインストールするのに成功したり、あるいはディストリビューションのパッケージをインストールても、まだsource-highlightのコンパイルに問題が起きる場合には、次に説明する事柄を簡単に調整する必要がある。
+Boost Regexライブラリをコンパイルしてインストールするのに成功したり、あるいは、ディストリビューションのパッケージをインストールしても、source-highlightのコンパイルに問題がまだ起きる場合には、次に説明する事柄を調整しなければなりません。
 
-まず、source-highlightの@code{./configure}コマンドが次のように報告する場合だ:
+まず、source-highlightの@code{./configure}コマンドが次のようにエラーを報告する場合です。
 
 @example
 ERROR! Boost::regex library not installed.
 @end example
 
 @noindent
-このとき、コンパイラがこのライブラリのヘッダファイルを見つけられないでいる。
-こういう場合は、@file{/usr/include/boost}ディレクトリが実際に存在するかどうかを確認してほしい。
-もし無ければ、インストールしたライブラリのバージョンに応じて、恐らく似たような名前のディレクトリが見つかるだろう（たとえば@file{/usr/include/boost-1_33/boost）。
-そのときは、次のようにシンボリックリンクを作成するだけでよい:
+この時、コンパイラは、ライブラリのヘッダファイルを見つけられないでいます。
+こういう場合は、@file{/usr/include/boost}ディレクトリが実際に存在するかどうかを確認してください。
+ディレクトリが無ければ、インストールしたライブラリのバージョンに応じて、恐らく、似たような名前のディレクトリがあるでしょう（例えば、@file{/usr/include/boost-1_33/boostなどです）。
+その時は、シンボリックリンクを次のように作成するだけで良いです。
 
 @example
 ln -s /usr/include/boost-1_33/boost /usr/include/boost
 @end example
 
 @noindent
-代わりに、source-highlightのconfigureを次のように実行してもよい:
+代わりに、source-highlightのconfigureを次のように実行しても構いません:
 
 @example
 ./configure CXXFLAGS=-I/usr/include/boost-1_33/
 @end example
 
-さらに、source-highlightの@code{./configure}が次のような別のエラーを出す場合だ:
+次に、source-highlightの@code{./configure}が、次のような別のエラーを出す場合です。
 
 @example
 ERROR! Boost::regex library is installed, but you
@@ -614,16 +654,16 @@ for instance, --with-boost-regex=boost_regex-gcc-1_31
 @end example
 
 @noindent
-このとき、修正しなければならないことが他にまだある。
-インストールしたBoost Regexライブラリの正確なファイル名を調べなければならない。
-これは次のコマンドを使えばよい:
+この時、修正しなければならないことが他にもあります。
+インストールしたBoost Regexライブラリの正確なファイル名を調べなければなりません。
+これは、次のコマンドを使えば分かります。
 
 @example
 $ ls -l /usr/lib/libboost_regex*
 @end example
 
 @noindent
-例えば、私のcygwinをインストールした環境の一つでは次のように報告される:
+例えば、cygwinをインストールした環境の一つでは次のように報告されます。
 
 @example
 -rwxr-x---+ Nov  9 23:29 /usr/lib/libboost_regex-gcc-mt-s-1_33.a
@@ -633,87 +673,93 @@ $ ls -l /usr/lib/libboost_regex*
 @end example
 
 @noindent
-これで、source-highlightの次のようにconfigureコマンドを正しく実行する情報が揃った:
+これで、source-highlightのconfigureコマンドを正しく実行する情報が揃いました。
+コマンドは次のようになります。
 
 @example
 ./configure --with-boost-regex=boost_regex-gcc-mt-s-1_33
 @end example
 
 @noindent
-あるいは、1番目の問題を2番目の方法@footnote{長過ぎるコマンドラインは、@code{\}によって、インデントされた複数行に分割されている。もちろんどうしてもというなら一行で書いてもよい}で解決した場合には次のようになる:
+あるいは、1番目の問題を2番目の方法で解決した場合には次のようになります@footnote{コマンドラインが長過ぎる場合、@code{\}によって、インデントされた複数行に分割されます。もちろん、どうしてもというなら、一行で書いても構いません。}。
 
 @example
 ./configure CXXFLAGS=-I/usr/include/boost-1_33/ \
             --with-boost-regex=boost_regex-gcc-mt-s-1_33
 @end example
 
-もちろん、ファイルをインストールしたBoost Regexライブラリの名前に応じてこのコマンドを修正しなければならない。
+もちろん、ファイルをインストールしたBoost Regexライブラリの名前に応じてこのコマンドは修正しなければなりません。
 
-問題が起きていた多数のユーザが、この手順でsource-highlightをなんとかコンパイルできるようになった。
-依然問題を抱えているならば私にメールを送ってほしい。
+問題が起きていた多数のユーザが、この手順により、source-highlightをなんとかコンパイルできるようになりました。
+依然問題を抱えているならば、メールを送ってください。
 
-@node 前のバージョンからのパッチ, lessでのsource-highlightの使用, Boost Regexライブラリのインストールに関するTips, インストール
+
+@node Patching from a previous version, Using source-highlight with less, Tips on installing Boost Regex library, Installation
 @section 前のバージョンからのパッチ
 @cindex patching
 
-パッチを一つ、たとえば@file{source-highlight-1.3-1.3.1-patch.gz}（すなわち、バージョン1.3からバージョン1.3.1へのパッチ）をダウンロードした場合、前のバージョン（source-highlight-1.3）のソースのディレクトリへcdして、次のようにタイプする:
+パッチをダウンロードした場合を考えます。
+例えば、@file{source-highlight-1.3-1.3.1-patch.gz}（すなわち、バージョン1.3からバージョン1.3.1へのパッチ）をダウンロードしたとします。
+前のバージョン（source-highlight-1.3）のソースディレクトリへcdして、次のようにタイプしてください。
 
 @example
 gunzip -cd ../source-highlight-1.3-1.3.1.patch.gz | patch -p1 
 @end example
 
-そして、コンパイルの手順をリスタートする（既にconfigureを実行しているならば、ただmakeをすればいいはずだ）。
+そして、コンパイル手順を再開します（configureを既に実行しているならば、makeをただ実行すればいいはずです）。
+
 
-@node lessでのsource-highlightの使用, source-highlightのCGIとして使用, 前のバージョンからのパッチ, インストール
+@node Using source-highlight with less, Using source-highlight as a CGI, Patching from a previous version, Installation
 @section lessでのsource-highlightの使用
 
-これはKonstantine Serebrianyが提案したことだ。
-@file{src-hilite-lesspipe.sh}というスクリプトがsource-highlightと一緒にインストールされるだろう。
-次に挙げる環境変数を使うことができる。
+これは、Konstantine Serebrianyが提案しました。
+@file{src-hilite-lesspipe.sh}というスクリプトがsource-highlightと一緒にインストールされます。
+以下の環境変数を利用できます。
 
 @example 
 export LESSOPEN="| /path/to/src-hilite-lesspipe.sh %s"
 export LESS=' -R '
 @end example
 
-このようにすれば、ファイルをlessを使ってブラウズするとき、それがsource-highlightによって処理されるソースファイルであれば、自動的にハイライトされる。
+このようにすれば、lessを使ってファイルを閲覧する時、source-highlightによって処理されるソースファイルであれば、自動的にハイライトされるようになります。
+
 
-@node source-highlightのCGIとして使用, .rpmのビルド, lessでのsource-highlightの使用, インストール
+@node Using source-highlight as a CGI, Building .rpm, Using source-highlight with less, Installation
 @section source-highlightのCGIとして使用
 
 @cindex CGI
-Robert WetzelのおかげでCGIサポートが可能になった。
-私は個人的にはこれをテストしていない。
-source-highlightをCGIプログラムのように使いたい場合には、source-highlight-cgiという実行ファイルを使わなければならない。
-このような実行ファイルは次のコマンドを実行すればビルドできる。
+Robert Wetzelのおかげで、CGIのサポートが可能になりました。
+私は、個人的にはこれをテストしていません。
+source-highlightをCGIプログラムのように使いたい場合には、source-highlight-cgiという実行ファイルを使わなければなりません。
+このような実行ファイルは、次のコマンドを実行して構築できます。
 
 @example
 make source-highlight-cgi
 @end example
 
 @noindent
-これは@file{src}ディレクトリで実行する。
+このコマンドは、@file{src}ディレクトリで実行します。
 
 
-@node .rpmのビルド,  , source-highlightのCGIとして使用, インストール
-@section .rpmのビルド
+@node Building .rpm,  , Using source-highlight as a CGI, Installation
+@section .rpmの構築
 @cindex rpm
 
-Christian W. Zuckschwerdtが.rpmと.rpm.srcをビルドするサポートを追加した。
-バイナリの入った.rpmをビルドするには次のコマンドを実行すればよい:
+Christian W. Zuckschwerdtは、.rpmと.rpm.srcを構築するサポートを追加しました。
+バイナリの入った.rpmを構築するには、次のコマンドを実行します。
 
 @example 
 rpmbuild -tb source-highlight-@value{VERSION}.tar.gz
 @end example
 
-そしてソースの入った.rpm.srcをビルドするには次のようにする:
+そして、ソースの入った.rpm.srcを構築するには、次のようにします。
 
 @example
 rpmbuild -ts source-highlight-@value{VERSION}.tar.gz
 @end example
 
 
-@node Copying, 簡単な使い方, インストール, Top
+@node Copying, Simple Usage, Installation, Top
 @chapter Copying Conditions
 @cindex Copying conditions
 
@@ -724,15 +770,17 @@ under the terms of the GNU General Public License that accompanies this software
 GNU @command{source-highlight} was written and
 maintained by Lorenzo Bettini @value{myhomepage}.
 
-@node 簡単な使い方, 設定ファイル, Copying, Top
+
+@node Simple Usage, Configuration files, Copying, Top
 @chapter 簡単な使い方
 @cindex sample
 
-ここで、@command{source-highlight}実行する実際的な例を示す@footnote{長過ぎるコマンドラインは、@code{\}によって、インデントされた複数行に分割されている。もちろんどうしてもというなら一行で書いてもよい}。
+ここで、@command{source-highlight}を実行する実際的な例を示します@footnote{コマンドラインが長過ぎる場合、@code{\}によって、インデントされた複数行に分割されます。もちろん、どうしてもというなら、一行で書いても構いません。}。
 
-Source-highlightは、ソースコードの字面だけを解析するので、そのプログラムソースが正しく書かれていることが前提となっている。
+Source-highlightは、ソースコードの字面だけを解析します。
+そのため、プログラムソースが正しく書かれていることが前提となっています。
 
-source-highlightの実行方法を示す（この例ではC/C++の入力ファイルを使うが、それ以外のsource-highlightの入力言語に対しても有効である）:
+source-highlightの実行方法を示します（この例では、C/C++の入力ファイルを使いますが、これは、source-highlightのその他の入力言語に対しても有効です）。
 
 @example
 source-highlight --src-lang cpp --out-format html \
@@ -742,13 +790,14 @@ source-highlight --src-lang cpp --out-format html \
     @var{options}
 @end example
 
-入力ファイルについては、@code{-i (--input)}オプションと標準入力のリダイレクトとは別に、単にコマンドラインに複数のファイルを指定することができ、正規表現を使ってもよい（たとえば、@file{*.java}）。
-この場合には、出力ファイルの名前は、ソースファイルの名前に.<ext>を追加して作られる。
-この<ext>の部分は、指定された出力フォーマットに応じて選択される拡張しだ（この例では.htmlになる）。
-style file（@ref{出力フォーマットスタイル}）には、指定言語の各部のフォーマット方法についての情報を入れる（キーワードを青のボールドで、など）。
+入力ファイルについては、@code{-i}（@code{--input}）オプションと標準入力のリダイレクトとは別に、コマンドラインに複数のファイルを単に指定することができます。
+正規表現を使うこともできます（例えば、@file{*.java}）。
+この場合には、出力ファイルの名前は、ソースファイルの名前に.<ext>を追加して作られます。
+この<ext>の部分は、指定された出力フォーマットに応じて選択される拡張子です（この例では.htmlになります）。
+style file（@pxref{Output format style}）には、指定言語の各部のフォーマット方法についての情報を入れます（キーワードを青のボールドで、など）。
 
-重要：上述の二つの起動モード、@code{-i (--input)}と@code{-o (--output)}を使う（標準入出力のリダイレクトに置き換えることも可能）か、あるいは@code{-i (--input)}を使わずに一つ以上のファイル名を指定するか、どちらか一つを選ばなければならない。
-これらを混ぜて使うとエラーとなるだろう:
+重要：上述の二つの起動モード、@code{-i}（@code{--input}）と@code{-o}（@code{--output}）を使う（標準入出力のリダイレクトに置き換えることも可能）か、あるいは、@code{-i}（@code{--input}）を使わずに、一つ以上のファイル名を指定するか、どちらか一つを選ばなければなりません。
+これらを混用するとエラーとなります。
 
 @example
 source-highlight -o main.html main.cpp
@@ -757,134 +806,146 @@ source-highlight [OPTIONS]... -i input_file -o output_file
 source-highlight [OPTIONS]... [FILES]...
 @end example
 
-@code{STDOUT}という文字列が@code{-o (--output)}オプションとして渡された場合、出力は標準出力に強制される。
+@code{STDOUT}という文字列が@code{-o}（@code{--output}）オプションとして渡された場合、出力は標準出力に強制されます。
 
-@code{-s (--src-lang)}が指定されていなければ、ソース言語は、入力ファイルの拡張子もしくはファイル名自体から推定される（小文字のバージョンを使うかもしれない（訳注：えーと？後でも出てくるが、どういう意味だろう。ファイル名を小文字にした名前の言語定義ファイルを使うこともあるとか...そういう意味かな？））。
-これは、もちろん、標準入力のリダイレクトでは働かない。
-詳細については、@ref{入力言語の検出方法}を参照してほしい。
+@code{-s}（@code{--src-lang}）オプションが指定されていなければ、ソース言語は、入力ファイルの拡張子、もしくは、ファイル名自体から推定されます（小文字のバージョンを使うかもしれません）。
+これは、もちろん、標準入力のリダイレクトでは働きません。
+詳細については、別の節を参照してください（@pxref{How the input language is discovered}）。
 
-@code{-f (--out-format)}が指定されていない場合、出力はHTMLで生成される。
+@code{-f}（@code{--out-format}）が指定されていない場合、出力はHTMLで生成される。
 
-@code{--style-file}が指定されていなければ、配布物に含まれている@file{default.style}が使われる（詳細は@ref{出力フォーマットスタイル}を参照していほしい）。
+@code{--style-file}が指定されていなければ、配布物に含まれている@file{default.style}が使われます。
+詳細は、別の節を参照してください（@pxref{Output format style}。
 
 @menu
-* HTMLの出力とXHTMLの出力::
-* LaTeXの出力::                
-* Texinfoの出力::              
-* DocBookの出力::              
-* ANSIカラーエスケープシーケンス::  
+* HTML and XHTML output::       
+* LaTeX output::                
+* Texinfo output::              
+* DocBook output::              
+* ANSI color escape sequences::  
 @end menu
 
-@node HTMLの出力とXHTMLの出力, LaTeXの出力, 簡単な使い方, 簡単な使い方
+
+@node HTML and XHTML output, LaTeX output, Simple Usage, Simple Usage
 @section HTMLの出力とXHTMLの出力
 @cindex HTML
 @cindex XHTML
 
-HTMLとXHTMLのデフォルトの出力フォーマットでは、フォーマットされた出力全部が@code{<tt>}と@code{</tt>}の間に挟まれて、等幅フォントが使われるようになる。
-なので、たとえば、等幅あるいは非等幅の指定（@ref{出力フォーマットスタイル}を参照）というのは効果が無い。
-文字は全て等幅になる。
-このデフォルトの動作が相応わしくなくて、デフォルトで等幅フォントにしたくない場合には（そのままということ。たとえば@LaTeX{}出力）、コマンドラインの引数@code{--outlang-def}で、@file{html_notfixed.outlang}というファイルを使うことができる。
-XHTMLの出力については、それに対応して、@file{xhtml_notfixed.outlang}というファイルがある。
+HTMLとXHTMLのデフォルトの出力フォーマットでは、フォーマットされた出力全部が@code{<tt>}と@code{</tt>}の間に挟まれて、等幅フォントが使われるようになります。
+ですから、例えば、等幅・非等幅の指定というのは効果がありません（@pxref{Output format style}）。
+文字は全て等幅になります。
+このデフォルトの動作が好ましくなくて、（例えば、@LaTeX{}出力を使う場合など、）デフォルトで等幅フォントにしたくない場合、コマンドライン引数@code{--outlang-def}を使って、@file{html_notfixed.outlang}というファイルを使うことができます。
+XHTMLの出力の場合、対応するファイルは、@file{xhtml_notfixed.outlang}というファイルです。
 
-さらに、@file{htmltable.outlang}というファイルが、HTMLテーブルに括られたHTMLを出力するのに使われる（スタイルファイルで指定すれば背景色も使用する）。
-@file{xhtmltable.outlang}というファイルがXHTMLの出力に対して同じことをするものだ。
+さらに、@file{htmltable.outlang}というファイルは、HTMLテーブルに括られたHTMLを出力するのに使われます（スタイルファイルで指定すれば背景色も使用します）。
+XHTMLの出力に対して同じことを行うファイルは@file{xhtmltable.outlang}です。
 
-@node LaTeXの出力, Texinfoの出力, HTMLの出力とXHTMLの出力, 簡単な使い方
+
+@node LaTeX output, Texinfo output, HTML and XHTML output, Simple Usage
 @section @LaTeX{}の出力
 @cindex @LaTeX{}
 
-@LaTeX{}の出力フォーマットを使うときには、単色の出力（@code{-f latex}を使う）と色付きの出力（@code{-f latexcolor}を使う）とを選択することができる。
-色付きの出力の場合には、@{color}パッケージが必要だ（さらに、使用しているシステムになければならない）。
-もちろん、自分自身の@LaTeX{}出力フォーマットを自由に定義できる。
-@ref{出力言語の定義}を参照してほしい。
+@LaTeX{}の出力フォーマットを使う場合、単色の出力（@code{-f latex}を使う）と色付きの出力（@code{-f latexcolor}を使う）とを選択することができます。
+色付きの出力の場合、@{color}パッケージが必要です（さらに、使用しているシステムにこれが無ければなりません）。
+もちろん、独自の@LaTeX{}出力フォーマットを自由に定義できます。
+@xref{Output Language Definitions}.
+
 
-@node Texinfoの出力, DocBookの出力, Texinfoの出力, 簡単な使い方
+@node Texinfo output, DocBook output, LaTeX output, Simple Usage
 @section Texinfoの出力
 @cindex Texinfo
 
-Texinfoの出力フォーマットを使うときには、@code{--style-file}オプションを使って、source-highlightの配布物に入って献呈されているスタイルファイル、@file{texinfo.style}を使ってもよい。
-たとえば、@ref{例}にある例はこのスタイルファイルでフォーマットされている。
+Texinfoの出力フォーマットを使う場合、@code{--style-file}オプションを使って、専用のスタイルファイル@file{texinfo.style}を使用して構いません。
+このスタイルファイルは、source-highlightの配布物に入っています。
+例えば、別の節にある例は、このスタイルファイルでフォーマットされています（@pxref{Examples}）。
 
-@node DocBookの出力, ANSIカラーエスケープシーケンス, Texinfoの出力, 簡単な使い方
+
+@node DocBook output, ANSI color escape sequences, Texinfo output, Simple Usage
 @section DocBookの出力
 @cindex DocBook
 
-DocBookの出力は@code{<programlisting>}タグを使って生成される。
-もし、@code{--doc}というコマンドラインオプションが指定されれば、@code{<article>}ドキュメントが生成される。
+DocBookの出力は、@code{<programlisting>}タグを使って生成されます。
+もし、@code{--doc}というコマンドラインオプションが指定されれば、@code{<article>}ドキュメントが生成されます。
+
 
-@node ANSIカラーエスケープシーケンス,  , DocBookの出力, 簡単な使い方
+@node ANSI color escape sequences,  , DocBook output, Simple Usage
 @section ANSIカラーエスケープシーケンス
 @cindex ANSI color
 
-この出力フォーマットを、たとえば、@code{less}と一緒に使っているならば（@ref{lessでのsource-highlightの使用}）、@code{--style-file}オプションで、source-highlightの配布物に入れられている@file{esc.style}を使ってもよい。
-これにより、楽しい色付きの出力が得られる。
+この出力フォーマットを、例えば、@code{less}と一緒に使っているならば、@code{--style-file}オプションを使って、source-highlightの配布物に入れられている@file{esc.style}を使っても構いません（@pxref{Using source-highlight with less}）。
+これにより、楽しい色付きの出力が得られます。
+
 
-@node 設定ファイル, source-highlightの起動, 簡単な使い方, Top
+@node Configuration files, Invoking source-highlight, Simple Usage, Top
 @chapter 設定ファイル
 @cindex configuration files
 
-実行の際、source-highlightはいくつかのファイルを必要としていて、そのようなファイルで、ソース言語を認識する方法（@code{--src-lang}や@code{--lang-def}で明示的に指定されていない場合）、あるいは、使用する出力フォーマットをどれにするか（@code{--out-format}や@code{--outlang-def}で明示的に指定されていない場合）、ソースの各要素をフォーマットする方法（たとえば、キーワードとかコメントとか）、そして、ソース言語の定義や出力言語の定義といったことの指示を見つけることになる。
-これらのファイルについては次のセクションで説明する。
+実行の際、source-highlightはファイルをいくつか必要とします。
+ソース言語を認識する方法に関するディレクティブ（@code{--src-lang}や@code{--lang-def}で明示されていない場合）、あるいは、使用する出力フォーマットに関するディレクティブ（@code{--out-format}や@code{--outlang-def}で明示されていない場合）、ソースの各要素をフォーマットする方法に関するディレクティブ（例えば、キーワードとかコメントとか）、ソース言語の定義や出力言語の定義を、source-highlightは、そのようなファイルから探します。
+これらのファイルについては次のセクションで説明します。
 
 @cindex @code{--data-dir}
-もし、そういったファイルのディレクトリが@code{--data-dir}というコマンドラインオプションで明示されていなければ、次の順でこれらのファイルを探す:
+そういったファイルのディレクトリが、@code{--data-dir}というコマンドラインオプションで明示されていなければ、これらのファイルを次の順に探します:
 
 @itemize
 @item 
 カレントディレクトリ
+
 @item
-設定ファイルのインストールディレクトリ。
-@ref{インストール}を参照（このディレクトリは、コンパイル時にsource-highlightにハードコードされていることを覚えていてほしい）。
+設定ファイルのインストールディレクトリ（@pxref{Installation}）（このディレクトリは、コンパイル時に、source-highlightにハードコードされていることを覚えていてください）
+
 @item
-source-highlightコマンドが明示的なパス名を付けて指定された場合、インストールディレクトリが依然使用されるが、その明示したパス名に対して相対的である（訳注：イマイチ理解していない）。
+source-highlightコマンドが明示的なパス名を付けて指定された場合、インストールディレクトリ名が依然使用されますが、その明示したパス名に対して相対的となります。
 @end itemize
 
-とくに、ユーザは、環境変数
 @cindex @code{SOURCE_HIGHLIGHT_DATADIR}
-@code{SOURCE_HIGHLIGHT_DATADIR}でも値をセットすることができる（@ref{source-highlight-settingsプログラム}も参照）。
+特に、ユーザは、環境変数@code{SOURCE_HIGHLIGHT_DATADIR}を使って、その値をセットすることもできます（see also @ref{The program source-highlight-settings}）。
 
-実行の際にどのファイルが使われているかを確認したいときは、@code{--verbose}オプションを使うことができる。
+実行の際、どのファイルが使われるかを確認したい時は、@code{--verbose}オプションを使ってください。
 
 @menu
-* 出力フォーマットスタイル::         
-* CSSを使用した出力フォーマットスタイル::  
-* デフォルトのスタイル::              
-* 言語マップ::                
-* 言語の定義ファイル::   
-* 出力言語マップ::         
-* 出力言語の定義ファイル::  
-* 独自定義ファイルの開発::  
+* Output format style::         
+* Output format style using CSS::  
+* Default Styles::              
+* Language map::                
+* Language definition files::   
+* Output Language map::         
+* Output Language definition files::  
+* Developing your own definition files::  
 @end menu
 
-@node 出力フォーマットスタイル, CSSを使用した出力フォーマットスタイル, 設定ファイル, 設定ファイル
+
+@node Output format style, Output format style using CSS, Configuration files, Configuration files
 @section 出力フォーマットスタイル
 @cindex output style
 @cindex default.style
 
-@file{default.style}というファイルにシンタックスハイライティングのオプションを指定しなければならない@footnote{バージョン2.1より前には、このファイルは@file{tags.j2h}という非常に曖昧な名前で呼ばれていた。今度の名前付けの規則が良いものになっていることを信じている:-)}。
-言語定義のファイルで定義された各要素について、フォーマッティングのオプションを指定することができる（その要素のリストは、
+@file{default.style}というファイルには、シンタックスハイライティングのユーザオプションを指定しなければなりません@footnote{バージョン2.1より前には、このファイルは@file{tags.j2h}という非常に曖昧な名前で呼ばれていました。
+今度の名前付けの規則が良いものになっていることを信じています:-)}。
 @cindex @code{--show-lang-elements}
-@code{--show-lang-elements}を使うと得られる）。
-@ref{言語エレメントの一覧}を参照してほしい。
+言語定義のファイルで定義された各要素について、フォーマッティングのオプションを指定することができます（その要素のリストは、@code{--show-lang-elements}を使うと得られます）。
+@xref{Listing Language Elements}.
 
 @cindex @code{bgcolor}
 @cindex background color
-バージョン2.6から、出力ドキュメントの背景色も指定できる。
-これには@code{bgcolor}というキーワードを使う（@code{--doc}というコマンドラインオプションが使われたときだけ目にできるかもしれない）。
+バージョン2.6から、出力ドキュメントの背景色も指定できます。
+これには、@code{bgcolor}というキーワードを使います（@code{--doc}というコマンドラインオプションが使われた時だけ目にできるかもしれません）。
 
-多数のエレメントが、同じフォーマッティングオプションを共有している場合、同じ行に、これらのエレメントをカンマで分割して指定することができる@footnote{バージョン2.6から}。
+多数のエレメントが、同じフォーマッティングオプションを共有している場合、これらのエレメントをカンマで分割して、同じ行に指定することができます@footnote{バージョン2.6からです。}。
 
-ここに、この配布物と一緒に入っている@file{default.style}がある（これは、@ref{言語定義のチュートリアル}で示されている@file{style.lang}を使ってフォーマットされている）:
+以下は、この配布物と一緒に入っている@file{default.style}です。
+別の節で示されている@file{style.lang}を使ってフォーマットされています（@pxref{Tutorials on Language Definitions}）。
 
 @include default.style.texinfo
 
-このファイルは、Source-highlightの配布物に一緒に入っている言語定義で定義されているほとんどのエレメントについてスタイル定義を試みている。
+このファイルは、Source-highlightの配布物に同梱の言語定義で定義されている大半のエレメントについて、スタイル定義を試みています。
 
 @cindex @code{--style-file}
-コマンドラインオプションの@code{--style-file}で、独自のファイルを指定することもできる（@file{default.style}という名前である必要はない）@footnote{バージョン2.1より前では、このコマンドラインオプションは@code{--tags-file}という非常に曖昧な名前で呼ばれていた。今度の名前付けの規則が良いものになっていると信じている :-)}。
-@ref{source-highlightの起動}を参照してほしい。
+コマンドラインオプションの@code{--style-file}を使うと、独自ファイルを指定することもできます（@file{default.style}という名前である必要はありません）@footnote{バージョン2.1以前では、このコマンドラインオプションは、@code{--tags-file}という非常に曖昧な名前で呼ばれていました。
+今度の名前付けの規則が良いものになっていると信じています :-)}。
+@xref{Invoking source-highlight}.
 
-次の行を追加するとノーマルテキストの色を指定することもできる。
+次の行を追加すると、ノーマルテキストの色を指定することもできる。
 
 @example
 normal darkblue ;
@@ -892,20 +953,20 @@ normal darkblue ;
 
 @cindex color
 @cindex background color
-ご覧のように、このファイルのシンタックスはかなり素直だ。
-エレメント（あるいはカンマで区切られた複数のエレメント）の後に色を指定できる。
-@code{bg:}というプリフィックスを使えば背景色@footnote{バージョン2.6から}も指定できる（一例として、前述の@file{default.style}では@code{todo}エレメントに背景色が指定されている）。
+ご覧のように、このファイルのシンタックスはかなり素直です。
+エレメント（あるいは、カンマ区切りの複数エレメント）の後に色を指定できます。
+@code{bg:}というプリフィックスを使えば、背景色も指定できます@footnote{バージョン2.6から}（一例として、前述の@file{default.style}では@code{todo}エレメントに背景色が指定されています）。
 
-背景色は出力フォーマットの全てで利用できるわけではないことに注意してほしい。
-XHTMLや@LaTeX{}では利用できるが、HTML@footnote{もちろん、HTMLと外部のCSSファイルを使えば同じ結果は得られる}ではそうではない。
+背景色は、出力フォーマットの全てで利用できるわけではないことに注意してください。
+XHTMLや@LaTeX{}では利用できますが、HTMLでは利用できません@footnote{もちろん、HTMLと外部のCSSファイルを使えば同じ結果は得られます}。
 
 @cindex bold
 @cindex italics
 @cindex underline
 @cindex fixed
 @cindex notfixed
-それから、ボールドやイタリックなどのような、それ以上のフォーマティングオプションを指定することができる。
-以下が使用できるキーワードだ:
+それから、ボールドやイタリックなどのように、フォーマティングオプションをさらに指定することができます。
+以下は、使用できるキーワードです。
 
 @example
 b = bold
@@ -917,30 +978,30 @@ noref = no reference information is generated for these elements
 @end example
 
 @cindex color
-バージョン2.2からは、色の指定が不要になった。
-たとえば、@file{texinfo.style}を次に示す（Texinfoの出力に対して色を使っていない）:
+バージョン2.2からは色の指定が不要になりました。
+例えば、@file{texinfo.style}を次に示します（Texinfoの出力に色を使っていません）:
 
 @include texinfo.style.texinfo
 
 これらのオプションはカンマ区切りで複数指定してもよい。
-たとえば次のようになる。
+例えば、次のようになる。
 
 @example
 keyword blue u, b ;
 @end example
 
 @noindent
-覚えていてほしいのだが、この場合では、指定されたオプションの順序は、その出力が生成されるときにも保持される。
-たとえば、指定された出力フォーマットによって、@code{u, b}いう並びと、@code{b, u}という並びとでは、異なった結果をもたらすかもしれないということだ。
-とくに、1番目に指定されたスタイルは、その後に指定されたスタイルの後に使われる。
-たとえば、HTMLの場合、@code{u, b}という並びは、@code{<u><b>...</b></u>}というフォーマット結果を生む。
+覚えていてほしいのですが、この場合、指定されたオプションの順序は、その出力が生成される時にも保持されます。
+例えば、指定された出力フォーマットによって、@code{u, b}いう並びと、@code{b, u}という並びとでは、異なった結果をもたらすかもしれないということです。
+特に、1番目に指定されたスタイルは、その後に指定されたスタイルの後に使われます。
+例えば、HTMLの場合、@code{u, b}という並びだと、@code{<u><b>...</b></u>}というフォーマット結果を生じます。
 
 @cindex noref
-@code{noref}オプションは、このエレメントについて、リファレンス情報が生成されないというとを指定する（@ref{リファレンスの生成}を参照）。
-たとえば、これは@code{comment}エレメントに対して使われる。
-コメント内のエレメントについてクロスリファレンスを探索したいとは思わないからだ。
+@code{noref}オプションは、このエレメントについてリファレンス情報が生成されないというとを指定します（@pxref{Generating References}）。
+例えば、これは、@code{comment}エレメントに対して使われます。
+コメント内のエレメントについて、クロスリファレンスを探索したいとは思わないからです。
 
-以下は、source-highlightが処理可能な色の論理名である@footnote{これらのHTMLでの色は、@file{colors.html}というファイルで見ることができる}:
+以下は、source-highlightが処理可能な色の論理名です@footnote{HTMLでのこれらの色は、@file{colors.html}というファイルで見ることができます。}。
 
 @example
 black 
@@ -964,151 +1025,166 @@ white
 @end example
 
 @cindex direct color scheme
-二重引用符を用いれば、指定した出力フォーマットのカラースキームを直接使うこともできる。
-たとえばHTMLにおける@code{"#00FF00"}@footnote{バージョン2.2からは、二重引用符を使う必要がある}、あるいは、@code{"lightblue"}のように、二重引用符で括られた文字列の色名すら使うことができる@footnote{バージョン2.6から}。
-もちろん、生成の際、二重引用符は取り除かれる。
+二重引用符を用いれば、指定した出力フォーマットのカラースキームを直接使うこともできます。
+例えば、HTMLにおける@code{"#00FF00"}@footnote{バージョン2.2からは、二重引用符を使う必要があります。}、あるいは、@code{"lightblue"}のように、二重引用符で括られた文字列の色名も使えます@footnote{バージョン2.6からです}。
+もちろん、生成の際、二重引用符は取り除かれます。
 
-たとえば、次のものは@file{tests}ディレクトリで使われている@file{syslog.style}である。
-これは、カラースキームを直接使用している。
+例えば、次のものは@file{tests}ディレクトリで使われる@file{syslog.style}です。
+これは、カラースキームを直接使用しています。
 
 @include syslog.style.texinfo
 
-カラースキームを直接使用する場合には、source-highlightは変換を何も実行せず、指定されたカラースキームをそのまま出力することに注意してほしい。
-たとえば、@code{"brown"}という指定は、@code{brown}とは違う。
-前者はそのまま出力されるだろうが、後者は、出力フォーマットの対応する色へと変換される（HTMLについては見た目の結果は同じになりそうだ）。
+カラースキームを直接使用する場合には、source-highlightは変換を何も実行せず、指定されたカラースキームをそのまま出力することに注意してください。
+例えば、@code{"brown"}という指定は、@code{brown}とは異なります。
+前者は、そのまま出力されます。
+後者は、出力フォーマットの対応する色へと変換されます（HTMLについては見た目の結果は同じになりそうです）。
 
-指定された出力フォーマットによって処理されるカラースキームの文字列の指定はあなた次第である。
-ゆえに、別々の出力フォーマットの間では、直接カラースキームを指定することはポータブルではないかもしれない。
-たとえば、@code{"#00FF00"}はHTMLでは有効だが、@LaTeX{}ではそうではない。
+指定出力フォーマットによって処理されるカラースキームの文字列指定はユーザに任されています。
+ゆえに、別々の出力フォーマットの間では、カラースキームを直接指定すると可搬性に関わるかもしれません。
+例えば、@code{"#00FF00"}はHTMLでは有効ですが、@LaTeX{}ではそうではありません。
 
-@node CSSを使用した出力フォーマットスタイル, デフォルトのスタイル, 出力フォーマットスタイル, 設定ファイル
+
+@node Output format style using CSS, Default Styles, Output format style, Configuration files
 @section CSSを使用した出力フォーマットスタイル
 
 @cindex CSS
-バージョン2.6からは、制限されたCSSのシンタックスを使って出力フォーマットスタイルを指定できるようになった。
-これは、@code{--css}オプションを使ってsource-highlightが生成する出力とは無関係であることに注意してほしい。
+バージョン2.6からは、制限付きのCSSシンタックスを使って出力フォーマットスタイルを指定できるようになりました。
+これは、@code{--css}オプションを使ってsource-highlightが生成する出力とは無関係であることに注意してください。
 
 @cindex @code{--style-css-file}
-CSSファイルをスタイルファイルとして使うことで（すなわち、@code{--style-css-file}というコマンドラインオプションをへ渡すことで）、CSSと同じシンタックスを使って出力フォーマットスタイルだけを指定する。
-これはつまり、実際の出力とは関係無く出力フォーマットスタイルに対してCSSのシンタックスを使えるということだ（これが出力フォーマットスタイルの目的）。
-なので、@LaTeX{}の場合についても出力フォーマットスタイルとしてCSSファイルを使うことができる（ちょうどsource-highlightの出力フォーマットスタイルで行なうように。@ref{出力フォーマットスタイル}）。
+CSSファイルをスタイルファイルとして使うことで（すなわち、@code{--style-css-file}というコマンドラインオプションをへ渡すことで）、CSSと同じシンタックスを使って出力フォーマットスタイルだけを指定します。
+これは、実際の出力とは関係無く、出力フォーマットスタイルに対して、CSSのシンタックスが使えるということです（これが、出力フォーマットスタイルの目的）。
+ですから、@LaTeX{}の場合についても、出力フォーマットスタイルとしてCSSファイルを使うことができます。
+ちょうど、source-highlightの出力フォーマットスタイルで行うようにです。
+@xref{Output format style}.
 
-この機能は基本的にコードの再利用のために用意されている。
-CSSファイルを使って出力フォーマットスタイルを指定してから、同じCSSファイルを他のHTMLページの実際のスタイルシートとして使うことができる（あるいは、@code{-css}オプションを指定してsource-highlightで生成した出力ファイルでさえも使える）。
+この機能は、コードの再利用のために基本的に用意されています。
+CSSファイルを使って出力フォーマットスタイルを指定してから、他のHTMLページの実際のスタイルシートとして同じCSSファイルを使うことができます（あるいは、@code{-css}オプションを指定してsource-highlightで生成した出力ファイルも使えます）。
 
-この機能はかなり原始的なものなので、CSSのシンタックスを制限したサブセットしか認識しない。
-とくに、セレクタは常にCSSのクラスセレクタとして扱うので、必ずドットから始めなければならない。
-@code{/* */}のコメントは処理される。
-source-highlightが処理しないプロパティ（と、その値）は単に（そして静かに）取り除かれる。
+この機能はかなり原始的なものですので、CSSのシンタックスを制限したサブセットしか認識しません。
+特に、セレクタは、CSSのクラスセレクタとして常に扱いますので、ドットから必ず始めなければなりません。
+@code{/* */}のコメントは処理されます。
+source-highlightが処理しないプロパティ（および、その値）は、単に（そして、黙って）取り除かれます。
 
-次のものは、スタイルフォーマットの指定としてsource-highlightが正しく処理するCSSの指定の例である:
+次のものは、スタイルフォーマットの指定としてsource-highlightが正しく処理するCSS指定の例です。
 
 @include css_example.css.texinfo
 
-最後に、次のものが、@ref{出力フォーマットスタイル}で提示された@file{default.style}に対応する@file{default.css}である:
+最後に、以下は、別の節で提示された@file{default.style}に対応する@file{default.css}です（@pxref{Output format style}）。
 
 @include default.css.texinfo
 
-このファイルを@code{--style-css-file}というコマンドラインオプションに渡して、出力ファイルを生成すれば、@file{default.style}を使った場合と同じ結果が得られるだろう。
+このファイルを、@code{--style-css-file}というコマンドラインオプションに渡して、出力ファイルを生成すれば、@file{default.style}を使った場合と同じ結果が得られるでしょう。
+
+HTMLドキュメントの標準的なCSSファイルとしても、あるいは、@code{--style-css-file}へ渡すスタイルファイルとしても使える沢山のCSSファイルがsource-highlightには付属しています。
+ドキュメントのインストールディレクトリ（@pxref{Installation}）の中に@file{style_examples.html}というファイルがあります。
+これは、多くの出力例を示すもので、それぞれ別々のCSSスタイルを使ったものです。
 
-source-highlightには、HTMLドキュメントの標準的なCSSファイルとしても、あるいは、@code{--style-css-file}へ渡すスタイルファイルとしても使える沢山のCSSファイルが付属している。
-ドキュメンテーションのインストールディレクトリの中に@file{style_examples.html}というファイルがある。
-これは多数の出力例を示すもので、それぞれ別々のCSSスタイルを使ったものだ。
 
-@node デフォルトのスタイル, 言語マップ, CSSを使用した出力フォーマットスタイル, 設定ファイル
+@node Default Styles, Language map, Output format style using CSS, Configuration files
 @section デフォルトのスタイル
 
-次のファイル@footnote{バージョン2.9から}（デフォルトファイルは@file{style.defaults}）は、スタイルファイルの中で、出力スタイルが指定されていない言語エレメントのデフォルトスタイルのリストだ。
-特に次の行を見てほしい（コメント行は@code{#}で始まる）:
+次に挙げるファイル@footnote{バージョン2.9から。}（デフォルトファイルは@file{style.defaults}）は、スタイルファイルの中で、出力スタイルが指定されていない言語エレメントのデフォルトスタイルのリストです。
+特に、次のような行があります（コメント行は@code{#}で始まります）。
 
 @example
 elem1 = elem2
 @end example
 
 @noindent
-この行は、エレメント、ここではelem1に対するスタイルが、スタイルファイルで指定されていない場合、elem1がelem2と同じスタイルを持つということを示している。
+こういう行は、elem1というエレメントに対するスタイルがスタイルファイルで指定されていない場合、elem1はelem2と同じスタイルを持つということを示しています。
 
 @cindex style.defaults
-たとえば、次のものはsource-highlightに付いている@file{style.defaults}だ:
+例えば、以下は、source-highlightに付いている@file{style.defaults}です。
 
 @include style.defaults.texinfo
 
 @noindent
-この場合、@code{preproc}エレメントのスタイルが@code{keyword}エレメントのスタイルをデフォルトとする。
+この場合においては、@code{preproc}エレメントのスタイルが@code{keyword}エレメントのスタイルをデフォルトとしています。
+
+独自のスタイルファイルを作成し、そのスタイルの中で、同じ出力スタイルを持つエレメントのスタイルを全て指定したくないような場合にこのファイルは便利です（例えば、デフォルトのスタイルでは、@code{preproc}エレメントはkeywordとは違うフォーマットがされます。
+独自スタイルを使えば、スタイルを指定しない場合、@code{preproc}エレメントは、@code{keyword}と同じようにフォーマットされます）。
 
-このファイルは、独自のスタイルファイルを作成して、そのスタイルの中で、同じ出力スタイルを持つエレメントのスタイルを全て指定したくないような場合に便利だ（たとえば、デフォルトのスタイルでは、@code{preproc}エレメントはkeywordとは違うフォーマットがされるが、独自にスタイルを指定するのに、そのスタイルを指定していなければ、@code{preproc}エレメントは@code{keyword}と同じようにフォーマットされる）。
 
-@node 言語マップ, 言語の定義ファイル, デフォルトのスタイル, 設定ファイル
+@node Language map, Language definition files, Default Styles, Configuration files
 @section 言語マップ
 @cindex language map
 
-この設定ファイルは、特定の言語定義ファイルに拡張子を関連付けている。
-そのようなファイルの拡張子を使って、@code{--src-lang}オプションを指定することもできる（@ref{簡単な使い方}を参照)。
-source-highlightは、@file{lang.map}と呼ばれる、そういったファイルが付属している。
+言語マップの設定ファイルは、特定の言語定義ファイルに拡張子を関連付けるものです。
+ファイルの拡張子を使って、@code{--src-lang}オプションを指定することもできます（@pxref{Simple Usage})。
+source-highlightにはそういったファイルが付属しています。
+@file{lang.map}と言うファイルです。
 
-もちろん、このファイルの設定は、独自の言語マップファイルを書いて、コマンドラインオプションの@code{--lang-map}でそのファイルを指定すれば、オーバーライドすることもできる。
-さらに、上で説明したように、カレントディレクトリに@file{lang.map}が存在すれば、そのバージョンが使用される。
-そのファイルのフォーマットは極めてシンプルだ（コメント行は@code{#}で始まる）:
+もちろん、このファイルの設定をオーバーライドすることもできます。
+独自の言語マップファイルを書いて、コマンドラインオプションの@code{--lang-map}でそのファイルを指定してください。
+さらに、上で説明したように、カレントディレクトリに@file{lang.map}が存在すれば、そのファイルが使用されます。
+ファイルのフォーマットは極めてシンプルです（コメント行は@code{#}で始まります）。
 
 @example
 extension = language definition file
 @end example
 
-デフォルトの言語定義ファイルは@ref{導入}の中で示されている。
+デフォルトの言語定義ファイルは別の節の中で示されています（@pxref{Introduction}）。
 
-@node 言語の定義ファイル, 出力言語マップ, 言語マップ, 設定ファイル
+
+@node Language definition files, Output Language map, Language map, Configuration files
 @section 言語の定義ファイル
 
-これらのファイルは、ソースのハイライトされるべきエレメントを指定するものなので、source-highlightにとって極めて重要なものだ。
-これらのファイルはまた、source-highlightが扱わない言語を処理するために独自の言語定義ファイルを指定できるようにもする@footnote{これがバージョン2.0で取り入れられた、前のバージョンとの主な違いである}。
-これらのファイルのシンタックスは@ref{言語の定義}で説明されている。
+言語の定義ファイルは、ハイライトされるべきソースエレメントを指定するもので、source-highlightにとって極めて重要なものです。
+また、source-highlightが扱っていない言語を処理するために独自の言語定義ファイルを指定できるようにもなります@footnote{これが、バージョン2.0で取り入れられた、前のバージョンとの主な違いです。}。
+これらのファイルのシンタックスは別の節で説明しています（@pxref{Language Definitions}）。
+
 
-@node  出力言語マップ, 出力言語の定義ファイル, 言語の定義ファイル, 設定ファイル
+@node  Output Language map, Output Language definition files, Language definition files, Configuration files
 @section 出力言語マップ
 @cindex output language map
 
-この設定ファイルは出力フォーマットを特定の出力言語の定義ファイルと関連付けるものだ。
-出力フォーマットの名前を使って、@code{--out-format}オプションを指定することができる（@ref{簡単な使い方}を参照）。
-Source-highlightには、そのような@file{outlang.map}と呼ばれるファイルが付属している。
+出力言語マップの設定ファイルは、出力フォーマットを、特定の出力言語の定義ファイルと関連付けるものです。
+@code{--out-format}オプションを使って、出力フォーマットの名前を指定することができます（@pxref{Simple Usage}）。
+Source-highlightには、そのような@file{outlang.map}と呼ばれるファイルが付属しています。
 
-もちろん、このファイルの設定は、独自の言語マップを書いて、そういったファイルをコマンドラインオプションの@code{--outlang-map}で指定すれば、オーバーライドすることができる。
-さらに、上で述べたように、@file{outlang.map}というファイルがカレントディレクトリに存在すれば、そのバージョンが使われる。
-そういったファイルのフォーマットは極めてシンプルだ:
+もちろん、このファイルの設定はオーバーライドすることができます。
+独自の言語マップを書いて、そのファイルを、コマンドラインオプションの@code{--outlang-map}で指定してください。
+さらに、上で述べたように、@file{outlang.map}というファイルがカレントディレクトリに存在すれば、そのファイルが使われます。
+ファイルのフォーマットは極めてシンプルです。
 
 @example
 output format name = language definition file
 @end example
 
-デフォルトの言語定義ファイルは@ref{導入}で示されている。
+デフォルトの言語定義ファイルは別の節で示しています（@pxref{Introduction}）。
 
-とくに、出力言語マップの出力フォーマットの名前には、付け方がある。
-@code{-css}サフィックスが付いているものは、@code{--css}というコマンドラインオプションが指定されたときに使われるものだ。
+特に、出力言語マップの出力フォーマットの名前には付け方があります。
+@code{-css}サフィックスが付いているものは、@code{--css}というコマンドラインオプションが指定される時に使われるものです。
 
-@node 出力言語の定義ファイル, 独自定義ファイルの開発, 出力言語マップ, 設定ファイル
+
+@node Output Language definition files, Developing your own definition files, Output Language map, Configuration files
 @section 出力言語の定義ファイル
 
-これらのファイルは、ソースのエレメントがどのようにハイライトされるかを指定するものなので、source-highlightにとって極めて重要だ。
-これらのファイルはまた、source-highlightが扱わない出力フォーマットを処理するための独自の出力フォーマットの定義を指定することもできるようにする@footnote{これがバージョン2.1で取り入れられた、前のバージョンとの主な違いである}。
-こういったファイルのシンタックスは@ref{出力言語の定義}で説明されている。
+出力言語の定義ファイルは、ソースエレメントがどのようにハイライトされるかを指定するもので、source-highlightにとって極めて重要なものです。
+また、source-highlightが扱っていない出力フォーマットを処理するための独自の出力フォーマットの定義を指定できるようにもなります@footnote{これが、バージョン2.1で取り入れられた、前のバージョンとの主な違いです。}。
+ファイルのシンタックスは別の節で説明しています（@pxref{Output Language Definitions}）。
 
-これらのファイルはsource-highlightの配布物の一部であるが、次の場所から自由にダウンロードすることもできる:
+これらのファイルはsource-highlightの配布物の一部ですが、次の場所から自由にダウンロードすることができます。
 
 @value{outlangfilesurl}
 
-@node  独自定義ファイルの開発,  , 出力言語の定義ファイル, 設定ファイル
+
+@node  Developing your own definition files,  , Output Language definition files, Configuration files
 @section 独自定義ファイルの開発
 
-新しい言語定義を書いたり、既存の言語定義を訂正修正して、それを私に送ってくれるようにお勧めしたい。
-そうすれば、source-highlightの配布物にそれらを追加することができる。
+新しい言語定義を書いたり、既存の言語定義を訂正・修正した場合、私に送ってくださるようにお願いします。
+そうすれば、source-highlightの配布物にそれらを追加することができます。
 
-これらのファイルにはさらなる説明が必要なので（しかし、source-highlightの通常の使用には必要ではない）、複数のパート@ref{言語の定義}と@ref{出力言語の定義}で丁寧に説明する。
+これらのファイルにはさらなる説明が必要です（しかし、source-highlightの通常の使用には必要でははありません）。
+複数のパート（@pxref{Language Definitions}, and @ref{Output Language Definitions}）で丁寧に説明することにします。
 
-これらのファイルはsource-highlightの配布物の一部であるが、次の場所から自由にダウンロードすることもできる:
+これらのファイルはsource-highlightの配布物の一部ですが、次の場所から自由にダウンロードすることができます。
 
 @value{langfilesurl}
 
 
-@node source-highlightの起動, 言語の定義, 設定ファイル, Top
+@node Invoking source-highlight, Language Definitions, Configuration files, Top
 @chapter @command{source-highlight}の起動
 @cindex invoking
 @cindex version
@@ -1117,19 +1193,20 @@ output format name = language definition file
 @cindex help
 @cindex getting help
 
-@command{source-highlight}プログラムを実行する形式は次のようになる:
+@command{source-highlight}プログラムの実行書式は次のようになります。
 
 @example
 source-highlight @var{option} @dots{}
 @end example
 
-@code{source-highlight}は、@code{source-highlight --detailed-help}の出力で表示されるが、次のようなオプションをサポートしている:
+@code{source-highlight}は次のようなオプションをサポートしています。
+これらのオプションは、@code{source-highlight --detailed-help}の出力で表示されます。
 
 @smallexample
 @include help-output.texinfo
 @end smallexample
 
-いくつかのオプションについて詳細に説明しよう（@code{--help}の出力自体から明らかなはずなものや、@ref{簡単な使い方}で既に説明済みのものは除く）。
+いくつかのオプションについて詳細に説明します（@code{--help}の出力自体から分かるものや、別の節（@pxref{Simple Usage}）で説明済みのものは除きます）。
 
 @c Formatting copied from the Texinfo 4.0 manual.
 @table @code
@@ -1137,61 +1214,72 @@ source-highlight @var{option} @dots{}
 @item --data-dir
 @cindex @code{--data-dir}
 
-Source-highlightは、その実行の際、いくつかのファイル、たとえば、言語定義ファイル、出力フォーマットの定義ファイルなどを必要とする。
-これらのファイルは@code{prefix/share/source-highlight}にインストールされる（@code{prefix}はコンパイル時に選択される。@xref{インストール}参照）。
-なので、source-highlightは必要とするファイルを全て自由に見つけられるはずだ。
-しかし、この設定をオーバーライドしたい、たとえば、独自の言語定義ファイルがあるとか、単に、コンパイル時に使用したディレクトリとは違う場所に、使うsource-highlightのバイナリがあるなどの場合、コマンドラインオプションの@code{--data-dir}を使うことができる。
+Source-highlightは、実行の際、ファイルを必要とします。
+例えば、言語定義ファイル、出力フォーマットの定義ファイルなどです。
+これらのファイルは、@code{prefix/share/source-highlight}にインストールされます。
+@code{prefix}はコンパイル時に選択されます（@pxref{Installation}）。
+ですから、source-highlightは、必要とするファイルを全て自由に見つけられるはずです。
+しかし、この設定をオーバーライドしたい場合があります。
+例えば、独自の言語定義ファイルがあるとか、単に、コンパイル時に使用したディレクトリとは違う場所にsource-highlightのバイナリがあるなどの場合です。
+そういった場合に、コマンドラインオプションの@code{--data-dir}を使うことができます。
 
 @item --doc
 @itemx -d
 
-スタンドアロンの出力ドキュメント（すなわち、他のドキュメントにインクルードされるとは考えられていない出力ドキュメント）が欲しい場合には、このオプションを指定する（そうでない場合には、他のドキュメントにペーストできるテキストが得られるだけだ）。
-このオプションを選択して、@code{--title}を指定しない場合には、タイトルとしてソースファイル名が使用される。
+スタンドアロンの出力ドキュメント（すなわち、他のドキュメントにインクルードされるとは考えられていない出力ドキュメント）が欲しい場合には、このオプションを指定します（そうでない場合には、他のドキュメントにペーストできるテキストが得られるだけです）。
+このオプションを選択して、かつ、@code{--title}を指定しない場合には、タイトルとしてソースファイル名を使用します。
 
 @item --no-doc
-前述の@code{--doc}オプションは、実際には他のコマンドラインオプション（たとえば@code{--css}）で暗黙のうちに指定される。
-これをしたくない場合には（たとえば、グローバルなスタイルシートを持っている既存のドキュメントに出力をインクルードしたいなどの場合）、@code{--no-doc}を使うことでこれを無効にできる。
+前述の@code{--doc}オプションは、実際には、他のコマンドラインオプション（例えば、@code{--css}）で暗黙のうちに指定されるものです。
+これを行わせたくない場合（例えば、グローバルなスタイルシートを持っている既存のドキュメントに出力をインクルードしたいなどの場合）、@code{--no-doc}を使うことで無効にできます。
 
 @item --css
 @itemx -c
-出力ドキュメントに対してスタイルシートファイルを指定する（たとえばHTMLに対する@file{.css}@footnote{前に述べたように、もともとsource-highlightはHTMLの出力を生成するのが中心だと考えられていた。これが@emph{css}がスタイルシートに対して使われる理由だ}）。
-source-highlightはこのファイルは使わないことに注意してほしい。
-出力ファイルが生成されるときにこのファイルの名前を単に使って、出力ファイルがこのファイルをスタイルシートとして使うということを指定する（たとえば、生成されたHTMLがCSSファイルとしてこのファイルに依存する場合）。
+出力ドキュメントに対してスタイルシートファイルを指定します（例えば、HTMLに対する@file{.css}です@footnote{前に述べたように、source-highlightは、HTMLの出力を生成するのが中心だともともと考えられていました。これが、スタイルシートに対して@emph{css}が使われる理由です。}）。
+source-highlightはこのファイルを使わないことに注意してください。
+出力ファイルが生成される時、このファイルの名前を単に使って、出力ファイルがこのファイルをスタイルシートとして使うということを指定します（例えば、生成されたHTMLがCSSファイルとしてこのファイルに依存する場合）。
 
 @item --tab
 @itemx -t
-このオプションを使えば、タブ文字が指定された数の空白文字に変換される（タブ位置は保存される）。
-このオプションは、行番号を生成するときには自動的に選択される。
+このオプションを使えば、タブ文字が、指定された数の空白文字に変換されます（タブ位置は保存されます）。
+このオプションは、行番号を生成する時には自動的に選択される。
 
 @item --style-file
 @itemx --style-css-file
-source-highlightが出力を生成する（たとえば、フォーマットする）のに使用するファイルを指定する（たとえば、言語の各エレメントの色やスタイル）。
-これらのファイルの形式については@ref{出力フォーマットスタイル}と@ref{CSSを使用した出力フォーマットスタイル}にそれぞれ詳しく述べられている。
+source-highlightが出力を生成する（例えば、フォーマットする）のに使用するファイルを指定します（例えば、言語の各エレメントの色やスタイルです）。
+これらのファイルの形式については別の節にそれぞれ詳しく述べています。
+@xref{Output format style}, and @ref{Output format style using CSS}.
 
 @item --style-defaults
-スタイルファイルにスタイルの指定が無いエレメントのデフォルトのスタイルが入ったファイルを指定する（さらに詳しくは@ref{デフォルトのスタイル}を参照）。
+スタイルファイルにスタイルの指定が無いエレメントのデフォルトのスタイルが入ったファイルを指定します。
+さらに詳しくは別の節を参照してください。
+@xref{Default Styles}.
 
 @item --output-dir
-source-highlightには複数の入力ファイルを渡すことができる（@ref{簡単な使い方}を参照）。
-この場合出力ファイルの名前は指定できない。
-そういう場合には、コマンドを起動したディレクトリの中に出力ファイルが自動的に生成される。
-異なるディレクトリに出力ファイルを生成したい場合に、このオプションを使うことができる。
+source-highlightには複数の入力ファイルを渡すことができます（@pxref{Simple Usage}）。
+この場合、出力ファイルの名前は指定できません。
+そういう場合には、コマンドを起動したディレクトリの中に出力ファイルが自動的に生成されます。
+異なるディレクトリに出力ファイルを生成したい場合には、このオプションを利用できます。
 
 @item --infer-lang
 @cindex language inference
 @cindex @code{--infer-lang}
-入力言語を検出する推定メカニズムを強制する。
-これは@ref{入力言語の検出方法}に詳述する。
+入力言語を検出する推定メカニズムを強制します。
+これは、別の節で詳述します。
+@xref{How the input language is discovered}.
 
 @item --line-number
-指定されたパディング文字を使って（オプショナル）、出力に行番号を生成する@footnote{パディング文字はバージョン2.8から指定できる}（デフォルトのパディング文字は@code{0}）。
+指定されたパディング文字を使って（オプショナル）、出力に行番号を生成します@footnote{パディング文字はバージョン2.8から指定できるようになりました。}。
+デフォルトのパディング文字は@code{0}です。
 
 @item --line-number-ref
-@code{--line-number}と同様このオプションは出力行全てに番号を振り、それに加えて各行にアンカーを生成する。
-アンカーは指定されたプリフィックス（デフォルトは@code{line}）と行番号からなる（たとえば@code{line25}）。
-例えば、多数のファイルを処理する場合、プリフィックスとしてファイル名を使ってもよい。
-出力言語によってはこの機能がサポートされないものもあることに注意してほしい（たとえば@code{esc}だ。そういう場合には意味を成さない）。
-指定された出力言語でアンカーをどのように生成するかを定義することについては@ref{アンカーとリファレンス}を参照してほしい。
+@code{--line-number}と同様、このオプションは出力行全てに番号を振ります。
+それに加えて、各行にアンカーを生成します。
+アンカーは、指定されたプリフィックス（デフォルトは@code{line}）と行番号から構成されます（例えば、@code{line25}のようになります）。
+例えば、多数のファイルを処理する場合、プリフィックスとしてファイル名を使っても構いません。
+出力言語によってはこの機能がサポートされないものがありますので注意してください（例えば、@code{esc}です。そういう場合には意味を成しません）。
+指定出力言語でアンカーを生成する方法の定義については別の節を参照してください。
+@xref{Anchors and References}.
 
 @cindex line ranges
 @cindex range context
@@ -1199,95 +1287,102 @@ source-highlightには複数の入力ファイルを渡すことができる（@
 @item --line-range
 @itemx --range-context
 @itemx --range-separator
-バージョン2.11から、複数行の範囲を指定できるようになった。
-ソースのうち、この範囲に収まる行だけが出力される。
-たとえば、次のように指定された場合だ。
+バージョン2.11からは、複数行の範囲を指定できるようになりました。
+ソースのうち、この範囲に収まる行だけが出力されます。
+例えば、次のように指定された場合を考えます。
 
 @example
 --line-range="-5","10","20-25","50-"
 @end example
 
-この場合は、最初の5行、10行目、20行目から25行目まで、50行目から入力の最後まで、の各行が出力される（@ref{行による範囲指定}にある例も見てほしい）。
+この場合は、最初の5行、10行目、20行目から25行目まで、50行目から入力の最後までの各行が出力されます。
+別節の例も見てください。
+@xref{Line ranges}.
 
-@code{--line-range}とともに、@code{--range-context}も指定できる。
-これは、範囲に入っている行の前後に追加して表示される行数である（すなわち挟んでいる``context''）。
-これらの行はハイライトされず、@code{context}のスタイルに応じて表示される。
-例として、前の例を広げる。
+@code{--line-range}には、@code{--range-context}も一緒に指定できます。
+これは、範囲に入る行の前後に追加して表示される行数です（すなわち、範囲を囲む「context」です）。
+これらの行はハイライトされず、@code{context}のスタイルに応じて表示されます。
+例として、前の例を発展させます。
 
 @example
 --line-range="-5","10","20-25","50-" --range-context=1
 @end example
 
-これによって、6行目、9行目、11行目、19行目、26行目、49行目の各行も出力される（@ref{行による範囲指定（コンテキスト付き）}の例も参照）。
+これによって、6行目、9行目、11行目、19行目、26行目、49行目の各行も出力されるようになります。
+別節の例も参照してください。
+@xref{Line ranges (with context)}.
 
-最後に、@code{--range-separator}を使って、範囲と範囲の間に表示される、範囲セパレータ行の文字列を指定することができる（@ref{行による範囲指定（コンテキスト付き）}の例も参照）。
-セパレータの文字列は自動的に実行されるので、たとえば、texinfo出力における@{ @}のような特殊な出力文字をエスケープする必要はない。
+最後に、@code{--range-separator}を使えば、範囲と範囲の間に表示される範囲セパレータ行の文字列を指定することができます。
+別節の例も参照してください（@pxref{Line ranges (with context)}）。
+セパレータの文字列は自動的に実行されますので、例えば、texinfo出力における@{ @}のような特殊な出力文字をエスケープする必要はありません。
 
 @cindex regex ranges
 @item --regex-range
+範囲は、正規表現を使って表わすこともできます。
+コマンドラインオプション@code{--regex-range}を使います。
+この場合、範囲の開始は、指定正規表現とマッチする文字列を（任意の位置で）含む行で検出されます。
+範囲の終了は、その範囲を開始したのと同じ正規表現にマッチする文字列を含む行で検出されます。
+この機能は、例えば、まさにこのマニュアルのように、アドホックなやり方で（例えば、特定のコメントのパターンを使って）、ソースコードの中で範囲を区切られた場所だけを見せるようにして、コードをドキュメントにしたい場合に非常に便利です。
+@xref{Regex ranges}.
 
-範囲は、正規表現を使って表わすこともできる。
-これにはコマンドラインオプション@code{--regex-range}を使う。
-この場合、範囲の開始は、指定された正規表現とマッチする文字列（任意の位置で）含む行で検出される。
-範囲の終了は、その範囲を開始したのと同じ正規表現のマッチする文字列を含む行で検出される。
-この機能は、（たとえば、まさにこのマニュアルのように）ソースコードの中でアドホックなやり方で（たとえば、コメントのパターンを指定する）、範囲を区切られた指定した場所だけを見せるようにして、コードをドキュメントにしたい場合に非常に便利だ
-@xref{正規表現による範囲指定}
-。
-指定された文字列（このオプションは複数回指定してもよい）は、有効な正規表現でなければならい（なので、特殊な文字はそれなりにエスケープしなければならない）。
-そうでなければ、エラーとなる。
+指定文字列（このオプションは複数回指定可能）は、有効な正規表現でなければなりません（ですから、特殊な文字はそれなりにエスケープしなければなりません）。
+そうでなければ、エラーとなります。
 
-また、@code{--line-range}と@code{--regex-range}は同じコマンドラインに共存することはできない。
+また、@code{--line-range}と@code{--regex-range}は同じコマンドラインに共存することはできません。
 
 @item --failsafe
 @cindex failsafe
-言語の指定が見つからない場合、エラーが表示されプログラムは終了する。
-このオプションを使えば、その代わりに、そういう状況では、入力が出力フォーマットに単にフォーマットされる。
-これは、@command{source-highlight}が多数の入力ファイルでもって使われるときに便利である。
-また、@file{src-hilite-lesspipe.sh}スクリプトでも使用される。
-実のところ、このオプションを常には使うべきではないということに対する良い理由を私は見つけられなかった。
-なので、source-highlightを実行するときにはいつもこれを使うことをお勧めする（そして確かに、将来このオプションはデフォルトになるかもしれない）。
-@ref{lessでのsource-highlightの使用}と@ref{簡単なフォーマッタとしてのsource-highlightの使用}も見てほしい。
+言語の指定が見つからない場合、エラーが表示され、プログラムは終了します。
+このオプションを使えば、その代わりに、そういう状況になると、入力が、出力フォーマットに単にフォーマットされるようになります。
+これは、多数のファイルを入力して@command{source-highlight}を使う場合に便利です。
+また、@file{src-hilite-lesspipe.sh}スクリプトでも使用されます。
+実のところ、このオプションを常には使うべきではないということに対する良い理由を私は見つけられませんでした。
+ですから、source-highlightを実行する時にはこれを常用することを推奨します。
+実際、将来、このオプションはデフォルトになるかもしれません。
+@xref{Using source-highlight with less}, and @ref{Using source-highlight as a simple formatter}.
 
 @cindex default.lang
-@code{--failsafe}を使うとき、入力言語がはっきりしない場合には、source-highlightは@file{default.lang}という入力言語の定義ファイルを使う。
-これは空のファイルである。
-そういったファイルはカスタマイズしてもかまわない。
+@code{--failsafe}を使う時、入力言語がはっきりしない場合には、source-highlightは、@file{default.lang}という入力言語の定義ファイルを使います。
+これは空のファイルです。
+このファイルはカスタマイズしても構いません。
 
 @item --debug-lang
 @item --show-regex
-言語定義ファイルをデバッグできるようにする。
-@ref{デバッギング}
-
+言語定義ファイルをデバッグできるようにします。
+@xref{Debugging}.
 @end table
 
-リファレンスを処理するコマンドラインオプションは、@ref{リファレンスの生成}の中でさらに詳しく説明されている。
+リファレンスを処理するコマンドラインオプションは、別の節でさらに詳しく説明しています。
+@xref{Generating References}.
 
 @menu
-* 入力言語の検出方法::  
+* How the input language is discovered::  
 @end menu
 
-@node 入力言語の検出方法,  , source-highlightの起動, source-highlightの起動
+
+@node How the input language is discovered,  , Invoking source-highlight, Invoking source-highlight
 @section 入力言語の検出方法
 
-既に述べたように（@ref{簡単な使い方}）、source-highlightは、@code{--src-lang}オプションや@code{--lang-def}オプションで指定された言語に応じて、あるいは入力ファイルの拡張子を使うことによって、言語定義ファイルを使用する。
+既に述べたように（@pxref{Simple Usage}）、source-highlightは、@code{--src-lang}オプションや@code{--lang-def}オプションで指定された言語に応じて、あるいは、入力ファイルの拡張子を使うことによって言語定義ファイルを使用します。
 
-バージョン2.5からは、source-highlightは、入力言語を推定するための推定メカニズムを使うことができる。
-今のところ、``sha-bang''メカニズムに基づくスクリプト言語の検出ができる。
-すなわち、スクリプトの最初の行に、たとえば次のような行を含んでいる場合だ。
+バージョン2.5からは、source-highlightは、入力言語を推定するための推定メカニズムを使うことができます。
+今のところ、「sha-bang」メカニズムに基づくスクリプト言語の検出が可能です。
+つまり、スクリプトの最初の行に、例えば、次のような行を含んでいる場合です。
 
 @example
 #!/bin/sh
 @end example
 
-@code{env}プログラムを使って指定されたスクリプト言語を検出する@footnote{バージョン2.7から}:
+@code{env}プログラムを使って指定されたスクリプト言語も検出します@footnote{バージョン2.7からです。}。
 
 @example
 #!/usr/bin/env perl
 @end example
 
-@code{-*- lang -*-}という形式を使ったEmacsのメジャーモードの宣言する、Emacsの慣習を認識する。
+Emacsにおける慣習も認識します。
+@code{-*- lang -*-}という形式を使ったEmacsのメジャーモードの宣言です。
 
-また一例として、以下のように始まるスクリプトの場合だ:
+また、一例として、以下のように始まるスクリプトの場合があります。
 
 @example
 #!/bin/bash
@@ -1295,131 +1390,143 @@ source-highlightには複数の入力ファイルを渡すことができる（@
 @end example
 
 @noindent
-この場合は、bashスクリプトではなく、Tclスクリプトとして解釈される。
+この場合は、bashスクリプトではなく、Tclスクリプトとして解釈されます。
 
-最後に、@code{<?}という記述（たとえば、@code{<?php}や@code{<?xml}）と@code{<!doctype}（この場合xmlファイルだと推定される）を認識する@footnote{バージョン3.1.2から}。
+最後に、@code{<?}という記述（例えば、@code{<?php}や@code{<?xml}）と@code{<!doctype}（この場合、xmlファイルと推定）を認識します@footnote{バージョン3.1.2からです。}。
 
-この推定メカニズムは、デフォルトで、入力言語が明示的に指定されていないか、あるいは、入力ファイルの拡張子やファイル名そのもの（小文字の場合もあるかもしれない）を使って言語マップで見つけられない場合に実行される（入力ファイルが拡張子を全く持たない場合もあるかもしれないが、たとえば、@file{ChangeLog}という入力ファイルは@file{changelog.lang}を使ってハイライトされる）。
+この推定メカニズムは、入力言語が明示的に指定されていないか、あるいは、入力ファイルの拡張子やファイル名そのもの（小文字の場合もあるかもしれません）を使って言語マップで見つけられない場合にデフォルトで実行されます。
+入力ファイルが拡張子を全く持たない場合もあるかもしれませんが、例えば、@file{ChangeLog}という入力ファイルは@file{changelog.lang}を使ってハイライトされます。
 
 @cindex @code{--infer-lang}
-加えて、このメカニズムは、@code{--infer-lang}というコマンドラインオプションで優先されるようになる。
-たとえば、source-hiliteを実行するときに、PerlスクリプトをPrologスクリプトとしてフォーマットするという問題を避けるために（@file{.pl}という拡張子が言語マップファイルでPrologプログラムに関連付けられているため）、@file{src-hilite-lesspipe.sh}スクリプトで使われている。
+加えて、このメカニズムは、@code{--infer-lang}というコマンドラインオプションで優先されるようになります。
+例えば、source-hiliteを実行する時に、PerlスクリプトをPrologスクリプトとしてフォーマットしてしまう問題@footnote{@file{.pl}という拡張子が言語マップファイルでPrologプログラムに関連付けられているためです。@xref{Perl}.}を避けるために、@file{src-hilite-lesspipe.sh}スクリプトで使われています。
+@xref{Using source-highlight with less}.
+
 
-@node 言語の定義, 出力言語の定義, source-highlightの起動, Top
+@node Language Definitions, Output Language Definitions, Invoking source-highlight, Top
 @chapter 言語の定義
 @cindex language definition
 
-バージョン2.0から、source-highlightはソース言語のエレメント（たとえば、キーワード、文字列、コメントなど）を指定するのに固有のシンタックスを使用する。
-バージョン2.0以前では、言語のエレメントはFlexを通してスキャンされていた。
-このため、新たな言語を処理するのに新しくflexファイルを書かなければならないことが障害となっていた。
-さらに悪いことに、新しい言語は「動的」に追加することができず、source-highlightプログラム全部を再度コンパイルしなければならなかった。
-
-今はそれに代わり、言語のエレメントは（願わくば）簡単なシンタックスを使って、ファイルに記述され、動的にロードされる。
-そして、これらの定義は、内部的には、エレメントをハイライトするのに使うための正規表現をオンザフライに生成するのに使われる（@ref{source-highlightの仕組み}も参照してほしい）。
-詳しく言うと、使用している正規表現は、Boostライブラリが提供しているものだ（@ref{インストール}を見よ）。
-なので、言語の定義ファイルを書く場合には、正規表現を確実に使う必要がある。
-しかし、怖がる必要はない。
-言語のほとんどでは、難しい正規表現を扱う必要は決して無いだろうし、言語のキーワード（たとえば、``if''とか``while''など。@ref{簡単な定義}）を指定することもできる。
-さらに、区切られた言語エレメントの場合、デリミタを除いて正規表現を書く必要は無いだろう（@ref{delim定義}）。
-しかし、もっとややこしい正規表現を多用する必要のある言語の定義もあるかもしれない（たとえば一つ挙げるとPerlである）。
-
-もちろん、Boost regexライブラリの正規表現を使う。
-そのシンタックスについてはBoostのドキュメンテーション（@uref{http://www.boost.org/libs/regex/doc/syntax.html}）を参照するが、@ref{正規表現に関する注意}の中で、正規表現を扱ったことの無い人にとって助けとなるかもしれない、正規表現に関する注意を用意した。
-デフォルトでは、Boost regexライブラリはPerlの正規表現シンタックスを使う。
-現状、これがsource-highlightのサポートしている唯一のシンタックスである。
-
-ここで、そのシンタックスを多くの例に依りながら詳細に見ていく。
-これにより、既存の言語定義を簡単に修正して、新しいものを作ることができるようになる。
-これらのファイルは通常@file{.lang}という拡張子を持つ。
-
-各定義は基本的に、一つの正規表現を一つの言語エレメントに関連付け、その言語エレメントに対して名前を定義している。
-その名前は、そのエレメントをハイライトするときに、特定のスタイル（ボールド、色など）と関連付けるのに使われる。
-言語定義のシンタックスで使われているキーワードと同じ名前を使うことはできない（たとえば、後で出てくる@code{start}は、予約語である）。
-
-@code{#}を使ってコメントを書くこともできる。
-その行のその文字以降の部分はコメントとして解釈される。
-
-Source-highlightは、入力ファイルの各行を別々にスキャンする。
-なので、new line文字にマッチしようとする正規表現は失敗する運命にある。
-しかし、言語定義のシンタックスは、複数行を処理するための手段を用意している（@ref{delim定義}と@ref{state/environment定義}を見よ）。
+バージョン2.0からは、ソース言語のエレメント（例えば、キーワード、文字列、コメントなど）を指定するのに固有のシンタックスを使用します。
+バージョン2.0以前では、言語のエレメントはFlexを通してスキャンされていました。
+このため、新たな言語を処理する場合、新しくflexファイルを書かなければならないことが障害となっていました。
+さらに悪いことに、新しい言語を「動的」に追加することができません。
+そのため、source-highlightプログラム全部を再度コンパイルしなければなりませんでした。
+
+今は違います。
+言語のエレメントは、（願わくば）簡単なシンタックスを使って、ファイルに記述され、動的にロードされます。
+これらの定義は、内部的には、エレメントをハイライトするのに使うための正規表現をオンザフライに生成するのに使われています（@pxref{How source-highlight works}）。
+詳しく言うと、使用している正規表現は、Boostライブラリが提供しているものです（@pxref{Installation}）。
+ですから、言語の定義ファイルを書く場合には、正規表現を確実に使う必要があります。
+しかし、恐れる必要はありません。
+言語の大半においては、難しい正規表現を扱う必要は決して無いでしょうし、言語のキーワード@footnote{例えば、ifとかwhileなどです。
+@xref{Simple definitions}.
+}を指定することもできます。
+さらに、区切られた言語エレメントの場合、区切り子を除いて、正規表現を書く必要は無いでしょう（@pxref{Delimited definitions}）。
+しかし、もっとややこしい正規表現を多用する必要のある言語の定義もあるかもしれません（例えば、一つ挙げるととしたら、Perlです）。
+
+もちろん、Boost regexライブラリの正規表現を使います。
+そのシンタックスについてはBoostのドキュメント（@uref{http://www.boost.org/libs/regex/doc/syntax.html}）を参照することにします。
+しかし、正規表現を扱ったことの無い人にとって助けとなるかもしれませんので、正規表現に関する注意を別節に用意しました（@pxref{Notes on regular expressions}）。
+デフォルトでは、Boost regexライブラリはPerlの正規表現シンタックスを使います。
+現状、これが、source-highlightのサポートしている唯一のシンタックスである。
+
+ここで、そのシンタックスを多くの例に依りながら詳細に見ていくことにします。
+これを使うと、既存の言語定義を簡単に修正し、新しいものを作ることができるようになります。
+これらのファイルは、通常、@file{.lang}という拡張子を持ちます。
+
+基本的に、各定義は、一つの正規表現を一つの言語エレメントに関連付け、その言語エレメントに対して名前を定義しています。
+その名前は、そのエレメントをハイライトする時に、特定のスタイル（ボールド、色など）と関連付けるのに使われます。
+言語定義のシンタックスで使われているキーワードと同じ名前を使うことはできません（例えば、後で出てくる@code{start}は予約語です）。
+
+@code{#}を使ってコメントを書くこともできます。
+その行のその文字以降の部分はコメントとして解釈されます。
+
+Source-highlightは、入力ファイルの各行を別々にスキャンします。
+ですから、改行文字にマッチしようとすると、正規表現は失敗することになります。
+しかし、言語定義のシンタックスでは、複数行を処理するための手段を用意しています。
+@xref{Delimited definitions}, and @ref{State/Environment Definitions}.
 
 @menu
-* 正規表現の指定方法::  
-* 簡単な定義::          
-* ラインワイド定義::       
-* 定義の順序::        
-* delim定義::       
-* 変数定義::        
-* 動的後方参照::      
-* ファイルのインクルード::              Include the contents of another file
-* state/environment定義::  
-* 名前を使った明示的な部分表現::  
-* 再定義と置換::  
-* source-highlightの仕組み::  
-* 正規表現に関する注意::  
-* check-regexpプログラム::    
-* 言語エレメントの一覧::   
-* まとめの所見::          
-* デバッギング::                   Debug a language definition file
-* 言語定義のチュートリアル::  
+* Ways of specifying regular expressions::  
+* Simple definitions::          
+* Line wide definitions::       
+* Order of definitions::        
+* Delimited definitions::       
+* Variable definitions::        
+* Dynamic Backreferences::      
+* File inclusion::              Include the contents of another file
+* State/Environment Definitions::  
+* Explicit subexpressions with names::  
+* Redefinitions and Substitutions::  
+* How source-highlight works::  
+* Notes on regular expressions::  
+* The program check-regexp::    
+* Listing Language Elements::   
+* Concluding Remarks::          
+* Debugging::                   Debug a language definition file
+* Tutorials on Language Definitions::  
 @end menu
 
-@node 正規表現の指定方法, 簡単な定義, 言語の定義, 言語の定義
+
+@node Ways of specifying regular expressions, Simple definitions, Language Definitions, Language Definitions
 @section 正規表現の指定方法
 
-言語定義のシンタックスの詳細に入る前に、正規表現の文字列を指定する三つの方法について説明することは極めて大切なことだ。
-この三つの方法は、基本的に正規表現の特殊文字を扱う方法の違いである。
-たとえばカッコとかがそうである。
-このため、一つの仕組みが他のものよりもパワフルな場合があるのだが、これについてはもう少し注意も必要だろう。
-加えて、他のものが要求されるゴールへ至ることができないために、一つの仕組みだけしか使えないような状況も起こりうる。
+言語定義のシンタックスの詳細に入る前に、正規表現文字列を指定する三つの方法について説明することは極めて重要なことです。
+この三つの方法は、基本的に、正規表現の特殊文字を扱う方法の違いによるものです。
+例えば、カッコなどがそれに相当します。
+このため、方法によっては、他のものよりもパワフルな場合がありますが、これについては少し注意も必要となることがあるでしょう。
+また、他の方法では要求されるゴールへ達することができず、一つの方法だけしか使えないような状況も起こり得ます。
 
 @table @code
 @cindex @code{"expression"}
 @item "expression"
 
-二重引用符（@code{"}である。@code{``}でも@code{''}でもないことに注意）を使って正規表現を指定する場合、基本的に、オルターネーションシンボルつまりパイプシンボル@code{|}以外の全ての文字がそのまま字面通り解釈されので、自動的にエスケープされる（たとえば、ドット@code{.}は、正規表現のワイルドカードではなく、文字@code{.}として解釈される）。
-例として次のように指定した場合を考える。
+二重引用符@footnote{@code{"}です。@code{``}でも@code{''}でもないことに注意してください。}を使って正規表現を指定する場合、基本的に、オルターネーションシンボル、つまり、パイプシンボル@code{|}以外の全ての文字がそのまま字面通り解釈されます。
+そのため、自動的にエスケープされことになります（例えば、ドット@code{.}は、正規表現のワイルドカードではなく、文字@code{.}として解釈されます）。
+例として、次のように指定した場合を考えます。
 
 @example
 "my(regular)ex.pre$$ion@{*@}"
 @end example
 
 @noindent
-この場合、source-highlightは自動的に次のように変換する。
+この場合、自動的に次のように変換します。
 
 @example
 my\(regular\)ex\.pre\$\$ion\@{\*\@}
 @end example
 
-
-二つの選択肢を分けるという意味を持たせない限り、@code{|}という特殊文字は、@code{\}文字でエスケープしなければならない。
-たとえば、@code{\|}のようになる。
-また、文字@code{\}も文字通りの意味を持たせるためには、@code{\\}のようにエスケープしなければならない。
+二つの選択肢を分けるという意味を持たせないのであれば、@code{|}という特殊文字は、@code{\}文字でエスケープしなければなりません（@pxref{Simple definitions}）。
+例えば、@code{\|}のようにします。
+また、文字@code{\}も文字通りの意味を持たせるためには、@code{\\}のようにエスケープしなければなりません。
 
 @cindex @code{'expression'}
 @item 'expression'
 
-正規表現のフルパワーを享受したいのならば、二重引用符の代わりに、一重引用符（@code{'}）の文字列を使う必要がある。
-これを使えば、特殊な文字を、その特殊な意味として指定することができるようになる。
+正規表現のフルパワーを享受したいならば、二重引用符ではなく、単引用符（@code{'}）の文字列を使う必要があります。
+単引用符を使えば、特殊な文字を、その特殊な意味として指定することができるようになります。
 
-しかし、マークされた部分表現は、自動的にマークされていない部分表現に変換される。
-すなわち、まとまりの@code{(...)}という表現の部分は、@code{(?:...)}というように変形される（@ref{正規表現に関する注意}で説明しているように、@code{(?:...)}は、正規表現の一部をその字面通りにグループ化する。
-その際、マークされた部分表現は生成されない）。（訳注:いわゆる正規表現メモリのことを言っているのだと思う）
+しかし、マークされた部分表現は、マークされていない部分表現に自動的に変換されます。
+つまり、@code{(...)}という形式の表現は、@code{(?:...)}というように変形されます。
+別節で説明しているように、@code{(?:...)}は、正規表現の一部をその字面通りにグループ化します（@pxref{Notes on regular expressions}）。
+その際、マークされた部分表現は生成されません@footnote{訳注:いわゆる正規表現メモリのことを言っているのだと思います。}。
 
-なので、例えば、次のように指定した場合を考える:
+ですから、例えば、次のように指定した場合を考えます。
 
 @example
 'my(regular)ex.pre$ion*'
 @end example
 
 @noindent
-この場合、source-highlightは自動的にこれを次のように変形する:
+この場合、自動的にこれを次のように変形します。
 
 @example
 my(?:regular)ex.pre$ion*
 @end example
 
-マークされた部分表現はこのシンタックスでは指定することができないので、@emph{後方参照}は許されていない（@ref{正規表現に関する注意}を参照）。
+マークされた部分表現はこのシンタックスでは指定することができませんので、@emph{後方参照}は許されていません。
+@xref{Notes on regular expressions}.
 
 @cindex @code{`expression`}
 @item `expression`
@@ -1427,14 +1534,18 @@ my(?:regular)ex.pre$ion*
 @cindex marked subexpressions
 @cindex backreference
 @cindex backtick
-正規表現を指定するための、このシンタックス@footnote{バージョン2.7から}（このシンタックスではバッククォート@code{`}を使っている。前のシンタックスは@code{'}を使っている。その違いに注意）は、他の二つのシンタックスの制限を克服するために導入された。
-このシンタックスを使うと、マークされた部分表現は変形されないので、@emph{後方参照}や@emph{条件}のような、マークされた部分表現に依存した正規表現の仕組みを利用することができる（@ref{正規表現に関する注意}を参照）。
+正規表現を指定するこのシンタックス@footnote{バージョン2.7から}は、他の二つのシンタックスの制限を克服するために導入されました（前のシンタッックスが@code{'}を使っているのに対し、バッククォート@code{`}を使っていますので注意してください）。
+このシンタックスを使うと、マークされた部分表現は変形されません。
+そのため、@emph{後方参照}や@emph{条件}のような、マークされた部分表現に依存した正規表現の仕組みを利用することがでます。
+@xref{Notes on regular expressions}.
 
-このシンタックスは、例えば、Perlの正規表現のように、あるプログラミング言語の特定のプログラム部分をハイライトすることに対しても極めて重要だ。
-Perlの正規表現は、（たとえば、置換の式において）多くの形式で表現されうる。
-具体的に言うと、置換される部分と置換する部分を分ける、英数字以外の任意の文字が可能なセパレータである@footnote{Perlの正規表現のシンタックスに関連するこの問題はElias Pippingによって提起され、また、このことは、たとえば、後方参照の利用を許すようなこのさらにパワフルなシンタックスを処理するように、私を駆り立てた。
-Perlのシンタックスを完璧にハイライトするには程遠いけれども（@ref{Perl}）、この問題に関する貴重な情報をもたらしてくれたEliasに間違い無く私は感謝せねばなるまい :-)}。
-例を挙げる:
+このシンタックスは、例えば、Perlの正規表現のように、あるプログラミング言語の特定のプログラム部分をハイライトすることに対しても極めて重要です。
+Perlの正規表現は、（例えば、置換の式において）多くの形式で表現されることがあります。
+具体的に言うと、置換される部分と置換する部分を分けるセパレータです@footnote{Perlの正規表現のシンタックスに関連するこの問題はElias Pippingによって提起されました。
+また、このことによって、例えば、後方参照の利用を許すようなさらにパワフルなこのシンタックスを処理できるように私は駆り立てられることになりました。
+Perlのシンタックスを完璧にハイライトするには程遠いですが（@pxref{Perl}）、この問題に関する貴重な情報をもたらしてくれたEliasに間違い無く私は感謝しなければなりません。:-)}。
+英数字以外の任意の文字が使えます。
+例を挙げます。
 
 @example
 s/foo/bar/g
@@ -1443,7 +1554,8 @@ s#foo#bar#g
 s@@foo@@bar@@g
 @end example
 
-このシンタックスと後方参照を使うと、一つの言語エレメントを定義して、これらの複数の表現を処理することが簡単にできるようになる（可能性のある非英数字を全て列挙することはない）:
+このシンタックスと後方参照を使うと、これらの複数の表現を処理することができる一つの言語エレメントを簡単に定義できるようになります。
+可能性のある非英数字の場合を全て列挙するようなことはありません。
 
 @example
 regexp = `s([^[:alnum:][:blank:]]).*\1.*\1[ixsmogce]*`
@@ -1451,30 +1563,30 @@ regexp = `s([^[:alnum:][:blank:]]).*\1.*\1[ixsmogce]*`
 
 @end table
 
-バージョン2.11からは、正規表現の指定全てで、改行文字を入れられるようになった。
-改行は単に無視される。
-なので、たとえば、次のファイルを見てほしい:
+バージョン2.11からは、あらゆる正規表現の指定において改行文字を入れられるようになりました。
+改行は単に無視されます。
+ですから、例えば、次のファイルを見てください。
 
 @include test_newlines.lang.texinfo
 
 @noindent
-このファイルは次のファイルと同等だ。
-and the file:
+このファイルは次のファイルと同等です。
 
 @include test_nonewlines.lang.texinfo
 
 @noindent
-しかし、前者が間違い無く読み易い。
+しかし、前者が間違い無く読み易いです。
 
-だが注意してほしいのだが、正規表現中の空白文字は無視されない。
+注意してほしいですが、正規表現中の空白文字は無視されません。
 
-@node 簡単な定義, ラインワイド定義, 正規表現の指定方法, 言語の定義
+
+@node Simple definitions, Line wide definitions, Ways of specifying regular expressions, Language Definitions
 @section 簡単な定義
 @cindex simple language definition
 
-言語のエレメントを記述する最も簡単な方法は、可能性のあるものをリストにすることだ。
-たとえば、これはキーワードの場合だ。
-例を挙げると、@file{java.lang}は次のようになっている:
+言語のエレメントを記述する最も簡単な方法は、可能性のあるものをリストにすることです。
+例えば、キーワードの場合です。
+例を挙げると、@file{java.lang}は次のようになっています。
 
 @example
 keyword = "abstract|assert|break|case|catch|class|const",
@@ -1486,45 +1598,49 @@ keyword = "native|new|null|private|protected|public|return",
 @end example
 
 
-引用された定義はカンマで分けることができる。
-代わりに、引用された定義の内部では、選択肢はパイプシンボル@code{|}で分けられる。
-上の定義は、keywordという言語エレメントを定義するものだ。
-ソースファイルの中でエレメントが一つ見つかるごとに、そのエレメントは、出力フォーマットスタイルファイルにある同名の、そのエレメントに対するスタイルでハイライトされる（例で示されているエレメントは全て、source-highlightedと一緒に配布されている言語定義ファイルから取られたもので、その各エレメントにはスタイルが存在していることに注意してほしい）。
-出力フォーマットスタイルファイルで、そのようなエレメントが指定されていない場合には、単にハイライトされない（実際は、@code{normal}というスタイルでハイライトされる。@ref{設定ファイル}を参照）（なのでタイポには注意を払ってほしい :-)）。
+引用された定義はカンマで分けることができます。
+また、引用された定義の内部では、パイプシンボル@code{|}で選択肢が分けられます。
+上の定義は、keywordという言語エレメントを定義するものです。
+ソースファイルの中でエレメントが一つ見つかるごとに、そのエレメントは、出力フォーマットスタイルファイルのそのエレメントに対する同名のスタイルでハイライトされます@footnote{例で示されているエレメントは、全て、source-highlightと一緒に配布されている言語定義ファイルから取られたものです。
+各エレメントにスタイルが存在していることに注意してください。
+@xref{Configuration files}.}。
+出力フォーマットスタイルファイルでそのようなエレメントが指定されていない場合には、単にハイライトされません@footnote{実際は、@code{normal}というスタイルでハイライトされます。
+@xref{Configuration files}.}（ですから、タイポには注意してください:-)）。
 
-上の例から、言語の定義が累積的であることにお気付きかもしれない。
-つまり、2番目の@code{keyword}の定義は最初のものを置き換えるものではない。
-（実際には、場合によって、言語のエレメントを再定義したいと思うこともあるだろう。
-これは@ref{再定義と置換}で説明するように可能だ。）
+上の例から、言語の定義が累積的であることに気付いたかもしれません。
+つまり、2番目の@code{keyword}の定義は最初のものを置き換えるものではありません@footnote{実際には、場合によって、言語のエレメントを再定義したいと思うこともあります。
+別の節で説明するようにこれは可能です。
+@xref{Redefinitions and Substitutions}.}。
 
-二重引用符に括られて指定されたワードは、ソースファイルにおいて正確にマッチしなければならず、また独立して存在しなければならない（空白以外のもので挟まれていてはいけない）。
-なので、たとえば@code{class}という文字列は、キーワードとしてマッチするが、@code{my_class}の部分文字列@code{class}にはキーワードとしてはマッチしない。
-正規表現の点から言うと、二重引用符に括られた単純な定義における@code{class}というような文字列は、@code{\<(class)\>}というようなものを意図している。
+二重引用符に括られて指定されたワードは、ソースファイルにおいて正確にマッチしなければなりません。
+また、独立して存在しなければなりません（空白以外のもので挟まれていてはいけません）。
+ですから、例えば、@code{class}という文字列はキーワードとしてはマッチしますが、@code{my_class}の部分文字列の@code{class}にはキーワードとしてはマッチしません。
+正規表現の点から言うと、二重引用符に括られた単純な定義における@code{class}というような文字列は、@code{\<(class)\>}を意図したものです。
 
-特殊な文字は@code{\}という文字でエスケープしなければならない。
-なので例えば、@code{|}という文字を指定したい場合、これは通常、二重引用符で括られた文字列の中で選択肢を分割するものとして使われるのだが、これは@code{\|}というように指定しなければならない。
+特殊な文字は、@code{\}という文字でエスケープしなければなりません。
+ですから、例えば、@code{|}という文字は、通常、二重引用符で括られた文字列の中で選択肢を分割するものとして使われますが、この文字@code{|}を指定したい場合、@code{\|}のように指定しなければなりません。
 
-@ref{正規表現の指定方法}で述べているように、二重引用符で括られた定義は、字面のまま解釈される（ゆえに、たとえばドット@code{.}は、正規表現におけるワイルドカードとしてではなく、文字@code{.}として解釈される）。
-言語のあるオルタナティブを記述するのに（訳注：to specify a language alternative）正規表現のフルパワーを享受したい場合には、二重引用符の文字列の代わりに、一重引用符（@code{'}）の文字列か、あるいはバッククォート（@code{`}）で括られた文字列を使わなければならない。
+別の節（@pxref{Ways of specifying regular expressions}）で述べているように、二重引用符で括られた定義は字面のまま解釈されます（ゆえに、例えば、ドット@code{.}は、正規表現におけるワイルドカードとしてではなく、文字@code{.}として解釈されます）。
+言語のある選択肢を記述する時に、正規表現のフルパワーを享受したい場合には、二重引用符の文字列の代わりに、単引用符（@code{'}）の文字列か、あるいは、バッククォート（@code{`}）で括られた文字列を使わなければなりません。
 
-たとえば、次のものは、C/C++におけるプリプロセッサの定義だ:
+例えば、次のものは、C/C++におけるプリプロセッサの定義です。
 
 @example
 preproc = '^[[:blank:]]*#([[:blank:]]*[[:word:]]*)'
 @end example
 
-上で説明されているように、@code{'class'}という定義は、@code{"class"}とは違うということに注意してほしい。
-なので、たとえば、@code{'class'}は、@code{my_class}の中の@code{class}という部分表現にもマッチする。
+上で説明したように、@code{'class'}という定義は、@code{"class"}とは違うということに注意してください。
+ですから、例えば、@code{'class'}の場合、@code{my_class}の中の@code{class}という部分表現にもマッチします。
 
-加えて、二重引用符の文字列と一重引用符の文字列を同じリストに記述することは許されていない。
-そういうリストの定義は分割する必要がある。
-ゆえに、たとえば、以下の定義は間違いだ:
+加えて、二重引用符の文字列と単引用符の文字列を同じリストに記述することは許されていません。
+そういうリストを定義する場合、分割する必要があります。
+ゆえに、例えば、以下の定義は間違いとなります。
 
 @example
 preproc = "#define",'^[[:blank:]]*#([[:blank:]]*[[:word:]]*)'
 @end example
 
-一方で、次のものは正しい:
+一方で、次のものは正しいものです。
 
 @example
 preproc = "#define"
@@ -1532,10 +1648,10 @@ preproc = '^[[:blank:]]*#([[:blank:]]*[[:word:]]*)'
 @end example
 
 @cindex nonsensitive
-最後に、定義のリストの最後において、@code{nonsensitive}というキーワードを記述してもよい。
-その場合、記述された文字列は大文字小文字を区別しないものとして解釈される。
-たとえば、この機能はPascal言語の定義で使用している。
-@file{pascal.lang}では、キーワードは大文字小文字を区別せずに解析される:
+最後に、定義のリストの最後において、@code{nonsensitive}というキーワードを記述することができます。
+その場合、記述された文字列は大文字小文字を区別しないものとして解釈されます。
+例えば、Pascal言語の定義でこの機能を使用しています。
+@file{pascal.lang}では、キーワードは大文字小文字を区別せずに解析されます。
 
 @example
 keyword = "alfa|and|array|begin|case|const|div",
@@ -1546,50 +1662,53 @@ keyword = "alfa|and|array|begin|case|const|div",
   nonsensitive
 @end example
 
-@node ラインワイド定義, 定義の順序, 簡単な定義, 言語の定義
+
+@node Line wide definitions, Order of definitions, Simple definitions, Language Definitions
 @section ラインワイド定義
 @cindex lines
 
-行末に至るまで残りの文字全てに影響する言語のエレメントを定義するのは、大変便利だ。
-そういう定義には、@code{=}の代わりに、@code{start}というキーワードを使わなければならない。
-たとえば、次のものは、C++における一行コメントの定義である:
+行末に至るまで残りの文字全てに影響する言語エレメントを定義できると大変便利です。
+そういう定義をする場合、@code{=}ではなく、@code{start}というキーワードを使わなければなりません。
+例えば、次のものは、C++における一行コメントの定義です。
 
 @example
 comment start "//"
 @end example
 
-これは、ソースファイルの中で二つの文字@code{//}に遭遇すると、これらの文字から行末までの全てが@code{comment}というスタイルによってハイライトされるということを意味している。
+これは、ソースファイルの中で二つの文字@code{//}に遭遇すると、これらの文字から行末までの全てが、@code{comment}というスタイルによってハイライトされるということを意味しています。
 
-@node 定義の順序, delim定義, ラインワイド定義, 言語の定義
+
+@node Order of definitions, Delimited definitions, Line wide definitions, Language Definitions
 @section 定義の順序
 @cindex definition order
 
-言語の定義の順序が重要であるということを知るのは重要だ。
-その順序が正規表現のマッチングの間に使用されるからだ（このことは@ref{source-highlightの仕組み}に詳述するつもりだ）。
-それから、同じ文字で始まる定義があるならば、最も長い式をまずそのファイルの中で記述しなければならないということを確認しなければならない。
-たとえば、次のように書いたとする:
+言語の定義の順序が重要であるということを知っておくことは重要なことです。
+正規表現のマッチング際、その順序が使用されるからです（このことは別の節（@pxref{How source-highlight works}）に詳述するつもりです）。
+それから、同じ文字で始まる定義があるならば、最も長い式を、そのファイルの中にまず記述しなければならないということを確認しなければなりません。
+例えば、次のように書いたとします。
 
 @example
 symbol = "/"
 comment start "//"
 @end example
 
-最初の式は、常に最初にマッチさせられる。
-そして2番目の式は決してマッチしない。
-正しい順序は次のようになる:
+最初の式が常に最初にマッチします。
+そして、2番目の式は決してマッチすることはありません。
+正しい順序は次のようになります。
 
 @example
 comment start "//"
 symbol = "/"
 @end example
 
-@node delim定義, 変数定義, 定義の順序, 言語の定義
+
+@node Delimited definitions, Variable definitions, Order of definitions, Language Definitions
 @section delim定義
 @cindex delimited definitions
 
-多くのエレメントは特定の文字の並びで区切られている。
-たとえば文字列や複数行のコメントである。
-こういうエレメントの定義のシンタックスは次のようになる:
+多くのエレメントは、特定の文字の並びで区切られています。
+例えば、文字列や複数行コメントです。
+こういうエレメントの定義シンタックスは次のようになります。
 
 @example
 <name> delim <left delimited> <right delimiter> \
@@ -1597,33 +1716,36 @@ symbol = "/"
         @{multiline@} @{nested@}
 @end example
 
-@code{escape}ステートメントは、そのエレメントの内部にある区切り子の一つに前置させるエスケープ用の文字を指定するものだ。
-これはオプショナルである。
+@code{escape}ステートメントは、そのエレメントの内部にある区切り子の前に置いてエスケープする時に使用する文字を指定するものです。
+これは省略可能です。
 
-たとえば、Cライクな文字列の定義は次のようになる:
+例えば、Cライクな文字列の定義は次のようになります。
 
 @example
 string delim "\"" "\"" escape "\\"
 @end example
 
-@code{\}は定義における特殊文字なので、エスケープしなければならないことに注意してほしい。
-@code{escape}の指定が省略されると、Cの文字列@code{"write \"hello\" string"}は間違ってハイライトされてしまっていただろう（@code{"write \"}という文字列と、通常の文字並びの@code{hello\}、そして文字列の@code{" string"}というようにハイライトされてしまっていた）。
+@code{\}は定義における特殊文字なので、エスケープしなければなりませんので注意してください。
+@code{escape}の指定が省略された場合、Cの文字列@code{"write \"hello\" string"}は間違ってハイライトされてしまうでしょう（文字列の@code{"write \"}、通常の文字並びの@code{hello\}、文字列の@code{" string"}というようにハイライトされてしまいます）。
 
-@code{multiline}というオプションは、そのエレメントが複数行に渡ることがあるというとを記述するものだ。
-たとえば、PHPの文字列の定義は次のようになる:
+@code{multiline}というオプションは、そのエレメントが複数行に渡ることがあるというとを記述するものです。
+例えば、PHPの文字列の定義は次のようになります。
 
 @example
 string delim "\"" "\"" escape "\\" multiline
 @end example
 
-@code{nested}というオプションは、区切りの文字が複数あった可能性をカウントして、（スタックを使って）対応する複数の（区切り文字の）出現をマッチさせるように指示するものだ。
-たとえば、ネストしているCライクな複数行コメントをハイライトしたいのならば（Ed Kellyが正しく指摘したように、Cスタイルのコメントはネストしない。数年間C++とJavaを使っていて、コメントというのはネストするとずっと思っていたことを遺憾に思う :-) そういう理由で、source-highlightの前のバージョンの配布物では、Cスタイルのコメントは（間違って）ネストされるように定義されていた。フィードバックをくれたEdに感謝する）、次のような定義が使えるだろう。
+@code{nested}というオプションは、区切り文字が複数あった場合をカウントして、対応する複数の区切り文字の出現にマッチするように指示するものです（スタックを使います）。
+例えば、ネストしているCライクな複数行コメントをハイライトしたい場合@footnote{Ed Kellyが正しく指摘したように、Cスタイルのコメントはネストしません。
+数年間C++とJavaを使っていて、コメントというのはネストするとずっと思っていたことを遺憾に思います。:-)
+そういうわけで、source-highlightの前のバージョンの配布物では、Cスタイルのコメントは（間違って）ネストされるように定義されていました。
+フィードバックをくれたEdに感謝します。}、次のような定義が使えます。
 
 @example
 comment delim "/*" "*/" multiline nested 
 @end example
 
-@code{nested}が使われなかったとしたら、以下に示すネストされたコメントの閉じる@code{*/}がこのコメントを終了させてしまうだろう（そして2番目の@code{*}はコメントとしてはハイライトされないだろう）:
+@code{nested}が使われなかったとしたら、以下に示すネストされたコメントの閉じる@code{*/}によって、このコメントは終了してしまうでしょう（そして、2番目の@code{*}はコメントとしてはハイライトされません）。
 
 @example
 /*
@@ -1631,67 +1753,73 @@ comment delim "/*" "*/" multiline nested
 */
 @end example
 
-区切り子で区切られた言語のエレメントがネストできるようにするには、その開始と終了のエレメントが異なっていなければならない。
-なので、例えば以下の定義は正しくない:
+区切り子で区切られた言語のエレメントがネストできるようにするには、その開始・終了のエレメントが異なっていなければなりません。
+ですから、例えば、以下の定義は正しくありません。
 
 @example
 string delim "\"" "\"" nested # WRONG!
 @end example
 
-上で述べたように、定義は累積的であり、そして文法的に異なった形式を使ったときですら累積的だ。
-従って、例えば、C++スタイルのコメントの完全な定義は次のようになる（実際、Cスタイルのコメントの定義はもっとややこしい。@file{c_comment.lang}というファイルを見てほしい）:
+上で述べたように、定義は累積的です。
+文法的に異なった形式を使った時ですら累積的です。
+従って、例えば、C++スタイルのコメントの完全な定義は次のようになります@footnote{実際、Cスタイルのコメントの定義はもっとややこしいものです。
+@file{c_comment.lang}というファイルを見てください。}。
 
 @example
 comment start "//"
 comment delim "/*" "*/" multiline
 @end example
 
-@node 変数定義, 動的後方参照, delim定義, 言語の定義
+
+@node Variable definitions, Dynamic Backreferences, Delimited definitions, Language Definitions
 @section 変数定義
 @cindex variables
 
-言語定義ファイルの中の多くの場所で再利用されるように変数を定義することが可能だ。
-変数は次のように定義される。
+変数を定義すれば、言語定義ファイル中のあちこちの場所で再利用することが可能となります。
+変数は次のように定義します。
 
 @code{vardef} <name of the variable> @code{=} <list of definitions>
 
-一度定義すると、その変数名の前に@code{$}というシンボルを付けることで使うことができる。
-例えば次のようになる。
+一度定義すると、その変数名の前に@code{$}というシンボルを付けることで使うことができます。
+例えば、次のようになります。
 
 @example
 vardef FUNCTION = '(?:[[:alpha:]]|_)[[:word:]]*(?=[[:blank:]]*\()'
 function = $FUNCTION
 @end example
 
-大文字にしたのは単に読み易さの為だけだ。
+大文字にしたのは単に読み易さの為だけです。
 
-変数と式を連結することも可能で、さらなる変数の定義の内部で変数を再利用することもできる:
+変数と式を連結することも可能で、さらに別の変数定義の内部で変数を再利用することもできます。
 
 @example
 vardef basic_time = '[[:digit:]]@{2@}:[[:digit:]]@{2@}:[[:digit:]]@{2@}'
 vardef time = '\<' + $basic_time + '\>'
 @end example
 
-@node 動的後方参照, ファイルのインクルード, 変数定義, 言語の定義
+
+@node Dynamic Backreferences, File inclusion, Variable definitions, Language Definitions
 @section 動的後方参照
 @cindex dynamic backreference
 
-@emph{動的後方参照}を使うと、@code{delim}指定の最初のエレメントの正規表現によってマッチした文字列を参照することができる（バージョン2.8から）。
-私はこの後方参照のことを、正規表現シンタックスの後方参照によってそれらを区別するために、ダイナミックと呼んだ（@ref{正規表現の指定方法}を参照）。
-右側のデリミタ（区切り子）が左側のデリミタによってマッチした部分表現に依存しているような場合にこれは極めて重要である。
-たとえば、Luaのコメントは@code{--[[ comment ]]}や@code{--[=[ comment ]=]}の形になるが、@code{--[=[ comment ]]}や@code{--[[ comment ]=]}のどちらでもない（さらに言えば、ネストしてもよい）@footnote{Luaのコメントに関するこの問題を挙げてくれたJurgen Hotzelに感謝している。このことで私は動的後方参照を導入することにした}。
-従って、右側のエレメントの正規表現は、左側のエレメントのものに依存している。
+@emph{動的後方参照}を使うと、@code{delim}指定の最初のエレメントの正規表現によってマッチした文字列を参照することができます@footnote{バージョン2.8からです。}。
+この後方参照のことを、正規表現シンタックスの後方参照によって区別するために、動的(dynamic)と呼びました（@pxref{Ways of specifying regular expressions}）。
+右側の区切り子が、左側の区切り子によってマッチした部分表現に依存しているような場合にこれは極めて重要です。
+例えば、Luaのコメントは、@code{--[[ comment ]]}や@code{--[=[ comment ]=]}の形になります。
+@code{--[=[ comment ]]}や@code{--[[ comment ]=]}のどちらでもありません（さらに言えば、ネストも可能です）@footnote{Luaのコメントに関するこの問題を挙げてくれたJurgen Hotzelに感謝します。
+このことがあったので動的後方参照を導入することにしました。}。
+従って、右側のエレメントの正規表現は、左側のエレメントに依存しています。
 
-動的後方参照は変数に似ている（@ref{変数定義}）が、宣言は無く、次のような形をしている。
+動的後方参照は変数に似ています（@pxref{Variable definitions}）が、宣言は無く、次のような形をしています。
 
 @example
 @@@{number@}
 @end example
 
 @noindent
-ここで、@code{number}は左側のデリミタにおけるマークされた部分表現の番号だ（source-highlightは、そういったマークされた部分表現が左側のデリミタに存在することを実際に確認する）。
+@code{number}は、左側の区切り子におけるマークされた部分表現の番号です（source-highlightは、そういったマークされた部分表現が左側の区切り子に存在することを実際に確認します）。
 
-たとえば、これがLuaのコメントの定義だ（@file{lua.lang}も見よ）:
+例えば、これがLuaのコメントの定義です（@file{lua.lang}も見てください）。
 
 @example
 environment comment delim `--\[(=*)\[` "]" + @@@{1@} + "]" 
@@ -1702,23 +1830,24 @@ end
 @end example
 
 @noindent
-左側のデリミタが、マークされた部分表現としてオプショナルな@code{=}とどのようにマッチして、右側のデリミタが@@@{1@}によってそれをどのように参照するかを注意してほしい。
+左側の区切り子が、マークされた部分表現としてオプショナルな@code{=}とどのようにマッチするか、また、右側の区切り子が@@@{1@}によってどのように参照するかに注意してください。
 
-source-highlightは、動的後方参照の置き換えの際に、起こりうる特殊文字のエスケープの面倒を見る。
-たとえば、次に示すようなdelimエレメントで、@code{[^[:alnum:]]}という部分表現が@code{|}とマッチしたために、@@@{1@}を@code{|}に置き換えなければならないとしよう:
+source-highlightは、動的後方参照の置き換えの際に、特殊文字のエスケープの面倒を見ます。
+例えば、次に示すようなdelimエレメントの場合を考えます。
+@code{[^[:alnum:]]}という部分表現が@code{|}とマッチしたために、@@@{1@}を@code{|}に置き換えなければならないとします。
 
 @example
 comment delim `([^[:alnum:]])` @@@{1@} 
 @end example
 
 @noindent
-@code{|}は正規表現のシンタックスにおいて特別な文字なので、source-highlightは、@code{@@@{1@}}を実際には@code{\|}と置き換える。
+@code{|}は正規表現のシンタックスにおいて特別な文字ですので、source-highlightは、@code{@@@{1@}}を実際には@code{\|}と置き換えます。
 
-重要：右側のデリミタは、その左側のデリミタの部分表現を参照できるだけである。
-そのため、ネストされたdelimエレメントの定義の場合（たとえばstateやenvironmentで。@ref{state/environment定義}を参照）、左側のデリミタはバインダとして振舞い、外側のdelimエレメントで定義されている起こりうる部分表現を隠す。
+重要：右側の区切り子は、その左側の区切り子の部分表現を参照できるだけです。
+そのため、ネストされたdelimエレメントの定義の場合（例えば、stateやenvironmentにおいてです。@pxref{State/Environment Definitions}）、左側の区切り子はバインダとして振舞い、外側のdelimエレメントで定義されている部分表現を隠します。
 
-後方参照でネストしている区切り子で区切られたエレメントに正しくマッチすることは大変重要なことだ。
-source-highlightはこのLuaのネストした（そして文法上は正しい）コメントを正しく認識する:
+ネストしている区切り子で区切られたエレメントに後方参照で正しくマッチすることは大変重要なことです。
+source-highlightは、Luaのネストした（そして、文法上は正しい）コメントを正しく認識します。
 
 @example
 --[[
@@ -1732,16 +1861,17 @@ source-highlightはこのLuaのネストした（そして文法上は正しい
 ]]
 @end example
 
-@node ファイルのインクルード, state/environment定義, 動的後方参照, 言語の定義
+
+@node File inclusion, State/Environment Definitions, Dynamic Backreferences, Language Definitions
 @section ファイルのインクルード
 @cindex file inclusion
 
-言語定義ファイルを、別のファイルにインクルードすることができる。
-これは、インクルードが起きたちょうどその場所で、解析中の現在のファイルの中にインクルードされるファイルの内容を実際に物理的にインクルードする（ちょうどC/C++における@code{#include}のようなもの）。
-これは、多数のファイルで定義を再利用するのに役に立つ。
-たとえば、c++のコメントの定義は@file{c_comment.lang}というファイルで記述されていて、このファイルはJavaやC++の定義ファイルでインクルードされている。
-同じことは、numberやfunctionでも行われている。
-例を挙げると、@file{java.lang}ファイルには以下に示すincludeの指示が含まれている:
+言語定義ファイルは別のファイルにインクルードすることができます。
+インクルードが起きたちょうどその場所で、解析中の現在のファイルの中に、インクルードされるファイルの内容を実際に物理的にインクルードします（ちょうどC/C++における@code{#include}のようなものです）。
+これは、多数のファイルで定義を再利用する場合に有用です。
+例えば、c++のコメントの定義は@file{c_comment.lang}というファイルで記述されていますが、このファイルは、JavaやC++の定義ファイルでインクルードされています。
+同じことは、numberやfunctionでも行われています。
+例を挙げると、@file{java.lang}ファイルには以下に示すincludeの指示が含まれています。
 
 @example
 include "c_comment.lang"
@@ -1753,16 +1883,18 @@ keywords ...
 include "function.lang"
 @end example
 
-定義の順序が重要であるので、インクルードの順序が重要であることに注意してほしい。
-たとえば、キーワードの定義よりも前に関数の定義がインクルードされると、@code{if (exp)}というセンテンスは関数呼び出しとしてハイライトされるだろう（@ref{定義の順序}と@ref{source-highlightの仕組み}を参照）。
+定義の順序が重要ですので、インクルードの順序が重要であることに注意してください。
+例えば、キーワードの定義よりも前に関数の定義がインクルードされると、@code{if (exp)}というセンテンスが関数呼び出しとしてハイライトされてしまいます。
+@xref{Order of definitions}, and @ref{How source-highlight works}.
 
-@node state/environment定義, 名前を使った明示的な部分表現, ファイルのインクルード, 言語の定義
+
+@node State/Environment Definitions, Explicit subexpressions with names, File inclusion, Language Definitions
 @section state/environment定義
 @cindex states
 @cindex environments
 
-他のエレメントに挟まれている場合にだけ、あるソースエレメントをハイライトしたいということが時折ある。
-source-highlightedの言語定義では、この機能も用意している。
+他のエレメントに挟まれている場合にだけ、あるソースエレメントをハイライトしたいという場合があります。
+source-highlightの言語定義には、この機能も用意しています。
 
 @example
 state|environment <standard definition> begin
@@ -1770,12 +1902,13 @@ state|environment <standard definition> begin
 end
 @end example
 
-この構造は再帰的だ（なので、state/environmentの定義は別のstate/environmentの内部で使うことができる）。
-state/environmentの意味は、state/environmentを定義している定義がマッチした場合にだけ、@code{begin ... end}の内部の定義がマッチするということである。
-しかし、state/environmentに入ったとき、そのstate/environmentの外側で指定されている定義はマッチしない。
-@code{state}と@code{environment}の違いは、後者においては、ソース言語の通常の部分（つまり、どの定義にもマッチしない部分）は、そのenvironmentを定義している定義のスタイルに応じてハイライトされるということだ。
+この構造は再帰的なものです（ですから、state/environmentの定義は別のstate/environmentの内部で使うことができます）。
+state/environmentの意味は、state/environmentを定義している定義がマッチした場合にだけ、@code{begin ... end}の内部の定義がマッチするということです。
+しかし、state/environmentに入った時、そのstate/environmentの外側で指定されている定義はマッチしません。
+@code{state}と@code{environment}の違いは、後者においては、ソース言語の通常の部分（つまり、どの定義にもマッチしない部分）が、そのenvironmentを定義している定義のスタイルに応じてハイライトされるということにあります。
 
-例として次に示すのは、複数行のネスト可能なCのコメントで、コメントの内側にURLやメールアドレスが表われたときだけ、それらをハイライトする（ファイルのインクルードを使っているので注意してほしい）:
+例として次に示すのは、複数行のネストが可能なCのコメントです。
+コメントの内側にURLやメールアドレスが表われた時だけ、それらをハイライトします（ファイルのインクルードを使っていることに注意してください）。
 
 @example
 environment comment delim "/*" "*/" multiline nested begin
@@ -1783,11 +1916,12 @@ environment comment delim "/*" "*/" multiline nested begin
 end
 @end example
 
-コメントの内側の他の部分は全部commentのスタイルでフォーマットされなければならないため@code{environment}を使用しているので留意してほしい。
+コメント内の他の部分は全部commentのスタイルでフォーマットされなければなりません。
+そのため、@code{environment}を使用していることに注意してください。
 
-プログラミング言語の定義については、state/environmentを避けられるが（コメント内のURLとか、Javasocのコメント内のドキュメンテーションタグのように、特定の環境の内部だけでその一部分をハイライトできるようになるが）、ログやChangeLogファイルのようなファイルをハイライトするのにはかなり重要である。
-エレメントが特定の位置に表われたときにハイライトしなければならないからだ。
-たとえば、ChangeLogの場合（@file{changelog.lang}を参照）、日付や名前、メール、URL（@file{url.lang}から取った）をハイライトするのにstateを使っている:
+プログラミング言語の定義については、state/environmentを避けられます（コメント内のURLとか、Javasocのコメント内のドキュメントタグのように、特定の環境の内部だけ、一部分をハイライトできるようになりますけれども）。
+一方、ログやChangeLogファイルのようなファイルをハイライトする場合には、エレメントが特定の位置に表われた時にハイライトしなければならないため、state/environmentはかなり重要になります。
+例えば、ChangeLogの場合（@file{changelog.lang}を参照）、日付、名前、メール、URL（@file{url.lang}から取った）をハイライトするのにstateを使っています。
 
 @example
 state date start '[[:digit:]]@{2,4@}-?[[:digit:]]@{2@}-?[[:digit:]]@{2@}' begin
@@ -1796,16 +1930,15 @@ state date start '[[:digit:]]@{2,4@}-?[[:digit:]]@{2@}-?[[:digit:]]@{2@}' begin
 end
 @end example
 
-（訳注：ぐだぐだです）
-state/environmentの内部に現われる定義は、その環境で定義される式と同じスコープを持つ。
-これによって、@code{start}と@code{delim}の定義にとっては意味がある一方で、簡単な定義にとっては合理的でないかもしれない（つまり、取り得る式を単にリストするものなど）。
-事実、こういう場合そのような式はスコープを定義しない。
-そのような定義にとって、state/environmentの意味は、その選択肢の一つとマッチングしたあとにstate/environmentが開始するということだ。
-そしてそれはどこで終わるのだろうか。
-この場合環境を明示的に終了しなければならない。
-たとえば、state/environmentの内部にいる場合、ある言語定義がキーワード@code{exit}にぶつかったときにも、その環境を抜け出す（脱出するstateの数を指定することもできる）。
-@code{exitall}を使えば環境を全部抜けることもできる。
-たとえば、以下に示す定義は、ウェブメソッドが後に続く空でない文字列をハイライトにする:
+state/environmentの内部に現われる定義は、その環境で定義される式と同じスコープを持つことに注意してください。
+これは、@code{start}と@code{delim}の定義にとっては意味がありますが、他方、簡単な定義（つまり、取り得る式を単にリストするものなど）にとってはあまり意味が無いかもしれません。
+事実、この場合、そのような式はスコープを定義しません。
+そのような定義にとって、state/environmentの意味は、その選択肢の一つとマッチングしたあとにstate/environmentが開始するということです。
+そして、それはどこで終わるのでしょうか。
+この場合、環境を明示的に終了しなければなりません。
+例えば、state/environmentの内部にいる場合、ある言語定義がキーワード@code{exit}にぶつかった時にも、その環境を脱出します（脱出するstateの数を指定することもできます）。
+@code{exitall}を使えば、環境を全部抜けることもできます。
+例えば、以下に示す定義は、ウェブメソッドの後に続く空でない文字列をハイライトにします。
 
 @example
 vardef non_empty = '[^[:blank:]]+'
@@ -1816,22 +1949,24 @@ state webmethod = "OPTIONS|GET|HEAD|POST|PUT|DELETE",
 end
 @end example
 
-このような進んだ機能が必要な場合にはいつでも、いくつかのログファイル（アクセスログ、Apacheのログなど）のハイライトを定義している@file{log.lang}定義ファイルを見てもらったらよい。
-さらに、明示的な名前付きの部分式で十分なような場合、上述の例がその一つなのだが、そういう場合があるかもしれない。
+このような高度な機能が必要な場合には、いつでも、ログファイル（アクセスログ、Apacheのログなど）のハイライトを定義している@file{log.lang}定義ファイルを参照すれば良いでしょう。
+さらに、明示的な名前付きの部分式で十分間に合うような場合もあるかもしれません。
+上述の例がその一つです。
+@xref{Explicit subexpressions with names}.
 
-このセクションを面白い例で締め括ろう。
-M4ファイルにおけるコメントは、@code{dnl}というキーワードで始まる（行末まで）。
-たとえば、次のようになる。
+このセクションを面白い例で締め括ります。
+M4ファイルにおけるコメントは、@code{dnl}というキーワードで始まります（行末までがコメンドです）。
+例えば、次のようになります。
 
 @example
 dnl @@synopsis AC_CTAGS_FLAGS
 @end example
 
-さて、@code{dnl}をキーワードとしてハイライトし、残りの部分をコメントとしてハイライトしたい場合、environmentに簡単に頼ることはできない。
-その行全体を同じスタイルでハイライトしてしまうからだ。
-加えて、@code{@@}で始まるエレメントを違うようにハイライトしたいので、実はstateが必要となる（これは前述の例にあるC++のコメントの場合のようにコメントの内部でURLをハイライトすることもできる）。
-なので、stateでenvironmentをシミュレートする必要がある。
-M4の例の場合次のようにする（@file{m4.lang}ファイルを見よ）。
+さて、@code{dnl}をキーワードとしてハイライトし、残りの部分をコメントとしてハイライトしたい場合、environmentに簡単に頼ることはできません。
+その行全体を同じスタイルでハイライトしてしまうからです。
+加えて、@code{@@}で始まるエレメントを別にハイライトしたいので、stateが実は必要となります（stateは、前述の例にあるC++のコメントの場合のように、コメントの内部でURLをハイライトすることもできます）。
+ですから、stateでenvironmentをシミュレートする必要があります。
+M4の例の場合、次のようにします（@file{m4.lang}ファイルを参照してください）。
 
 @example
 state keyword start "dnl" begin
@@ -1845,10 +1980,10 @@ state keyword start "dnl" begin
 end
 @end example
 
-一度このstateに入ると、単独の空白文字が全てコメントとしてハイライトされる。
-次に、URLと@@エレメントに対するルールがあって、それから、他の全てがコメントとしてハイライトされる（@code{.+} ）。
+このstateに一度入ると、単独の空白文字は、全てコメントとしてハイライトされます。
+次に、URLと@@エレメントに対するルールがあって、それから、他の全てがコメントとしてハイライトされます（@code{.+}）。
 
-単に次に示す定義をするのが、よりスマートな方法ではないかと考える人もいるかもしれない(after all, why bothering highlighting spaces as comments)。
+単に、次に示す定義の方が、よりスマートな方法ではないかと考える人もいるかもしれません（結局のところ、コメントとして空白をハイライトする必要があるのでしょうか）。
 
 @example
 state keyword start "dnl" begin
@@ -1859,40 +1994,44 @@ state keyword start "dnl" begin
 end
 @end example
 
-さて、この定義によって、マッチしたURLや@@エレメントの前にある空白は、プリフィックスであると考えられて、normalとしてハイライトされるだろう。
-これは、source-highlightがマッチするルールを探す方法に原因がある。
-詳細については、@ref{source-highlightの仕組み}を参照する。
+さて、この定義によって、マッチしたURLや@@エレメントの前にある空白は、プリフィックスであると考えられて、normalとしてハイライトされます。
+これは、source-highlightがマッチするルールを探す方法に原因があります。
+詳細については別節を参照してください。
+@xref{How source-highlight works}.
+
 
-@node 名前を使った明示的な部分表現, 再定義と置換, state/environment定義, 言語の定義
+@node Explicit subexpressions with names, Redefinitions and Substitutions, State/Environment Definitions, Language Definitions
 @section 名前を使った明示的な部分表現
 
-よく、同じ正規表現の中でプログラムの二つのエレメントを記述する必要がある。
-それらが密接な関係があるからだが、それらを違うようにハイライトする必要がある場合もある。
+プログラムの二つのエレメントのことを、同じ正規表現の中で記述しなければならないことがよくあります。
+それらが密接な関係があるからなのですが、それらを別々にハイライトする必要がある場合もあります。
 
-たとえば、クラス（あるいはインターフェイス）の定義中のクラス名（あるいはインターフェイス名）をハイライトしたいことがあるかもしれない（たとえばJavaなど）。
-従って、@code{class}キーワードが前置きされて、識別子がその後に続くことを利用することができる。
+例えば、（Javaなど場合）クラス定義（あるいは、インターフェイス定義）の中にあるクラス名（あるいは、インターフェイス名）をハイライトしたいことがあるかもしれません。
+それゆえ、前置きされる@code{class}キーワードを利用することができます。
+このキーワードには識別子が続きます。
 
-一つ定義を示す。
+一つ定義を示します。
 
 @example
 keyword = '(\<(?:class|interface))([[:blank:]]+)([$[:alnum:]]+)'
 @end example
 
 @noindent
-このような定義は、良い結果をもたらさない。
-というのも、クラスの名前がキーワードとしてハイライトされてしまうからだ。
-これは望んでいたことではないかもしれない。
-たとえば、クラス名は@code{type}としてハイライトされるべきなど。
+このような定義だと、良い結果とはなりません。
+というのも、クラスの名前がキーワードとしてハイライトされてしまうからです。
+例えば、クラス名は@code{type}としてハイライトされるべきだったりなどのため、これは、希望することではないかもしれません。
 
-バージョン2.6までは、これを行なう方法はstateかenvironmentを使うことだけだった（@ref{state/environment定義}）が、これを書くのはかなり難しくなりがちである。
+バージョン2.6までは、これを行なう方法は、stateかenvironmentを使うことだけでした（@pxref{State/Environment Definitions}）が、記述がかなり難しくなる傾向にありました。
 
-バージョン2.7から、マークされた部分表現を使って正規表現を記述し、それらをそれぞれ特定の言語エレメントにバインドすることができるようになった（正規表現は@code{`}で括られる必要がある。@ref{正規表現の指定方法}を参照）。
+バージョン2.7からは、マークされた部分表現を使って正規表現を記述し、それらをそれぞれ特定の言語エレメントにバインドすることができるようになりました。
+この場合、正規表現は@code{`}で括られる必要があります。
+@xref{Ways of specifying regular expressions}.
 
 @example
 (elem1,...,elemn) = `(subexp1)(...)(subexpn)`
 @end example
 
-さあ、このシンタックスを使えば、前出のゴールに辿り着ける。
+さあ、このシンタックスを使えば、前出のゴールに辿り着けます。
 
 @example
 (keyword,normal,type) = 
@@ -1900,21 +2039,21 @@ keyword = '(\<(?:class|interface))([[:blank:]]+)([$[:alnum:]]+)'
 @end example
 
 @noindent
-このようにすれば、@code{class}（あるいは@code{interface}）はキーワードとしてハイライトされ、間を分けるブランクの文字は@code{normal}としてフォーマットされ、そして、クラス名は@code{type}としてフォーマットされる。
+このようにすれば、@code{class}（あるいは@code{interface}）はキーワードとしてハイライトされ、間を分けるブランクの文字は@code{normal}としてフォーマットされ、そして、クラス名は@code{type}としてフォーマットされます。
 
-エレメントの名前の数は、正規表現中の部分表現の数と等しくなければならない。
-さらに、少なくとも現在のバージョンでは、その正規表現の中にはマークされた部分表現だけしか入れられず（部分表現の外には文字が無い）、部分表現をネストすることもできない。
+エレメント名の数は、正規表現中の部分表現の数と等しくなければなりませんので注意してください。
+さらに、少なくとも現在のバージョンでは、その正規表現の中には、マークされた部分表現だけしか入れられず（部分表現の外には文字が入れられません）、部分表現をネストすることもできません。
 
-従って次のような記述は正しくない。
+従って、次のような記述は間違いです。
 
 @example
-(keyword,symbol) = `(...)(...)(...)` # number of elements doesn't match
-(keyword,symbol) = `(...(...)...)(...)` # contains nested subexpressions
-(keyword,symbol) = `...(...)...(...)` # outside characters
+(keyword,symbol) = `(...)(...)(...)` # エレメント数の不一致
+(keyword,symbol) = `(...(...)...)(...)` # 部分表現のネスト
+(keyword,symbol) = `...(...)...(...)` # 部分表現外の文字
 @end example
 
-このメカニズムでは、ある状況において、正規表現をもっとコンパクトに、そして恐らくもっと読み易いやり方で表記することを許している。
-たとえば、次に示すようなChangeLogの各部をハイライトする場合を考える（オプショナルな@code{*}はシンボルとして、オプショナルなファイル名とカッコ内に記述されたエレメントは@code{file}エレメントとして、そして残りの部分は@code{normal}でハイライトする）。
+このメカニズムを使うと、ある状況において、正規表現をもっとコンパクトに、そして、恐らくもっと読み易いやり方で表記することが許されます。
+例えば、次に示すようなChangeLogの各部をハイライトする場合を考えます（省略可能な@code{*}はシンボルとして、省略可能なファイル名とカッコ内に指定されたエレメントは@code{file}エレメントとして、そして、残りの部分は@code{normal}としてハイライトします）。
 
 @example
   * src/Makefile.am (source_highlight_SOURCES): correctly include
@@ -1924,7 +2063,7 @@ keyword = '(\<(?:class|interface))([[:blank:]]+)([$[:alnum:]]+)'
 @end example
 
 @noindent
-バージョン2.6以前は、次の二つの言語定義を使っていた。
+バージョン2.6以前は、次の二つの言語定義を使っていました。
 
 @example
 state symbol start '^(?:[[:blank:]]+)\*[[:blank:]]+' begin
@@ -1941,8 +2080,8 @@ end
 @end example
 
 @noindent
-これを書いてしまった後に読むのは大変だ。
-さて今は、もっと簡単に書くことができる（@file{changelog.lang}を見よ）。
+これは、書いてしまった後に読むのは大変です。
+今は、もっと簡単に書くことができます（@file{changelog.lang}を見てください）。
 
 @example
 (normal,symbol,normal,file)= 
@@ -1950,21 +2089,23 @@ end
 (normal,file)= `(^[[:blank:]]+)((?:[^:]+\:)?)` 
 @end example
 
-名前の付きの明示的な部分表現を使った言語エレメントの定義は複数のエレメントからできていて、それゆえ複数のフォーマットスタイルから成っているので、environmentを開始するのに使うことはできない（デフォルトのエレメントは何なのだろう？）。
-一方、上で見たように、stateを開始するのには使うことができる。
+名前付きの明示的な部分表現を使った言語エレメントの定義は、複数のエレメントからできています。
+それゆえ、複数のフォーマットスタイルから構成されますので、environmentを開始するのに使うことはできません（デフォルトのエレメントは何になるのでしょうか）。
+一方、上で見たように、stateを開始するのには使うことができます。
 
-@node 再定義と置換, source-highlightの仕組み, 名前を使った明示的な部分表現, 言語の定義
+
+@node Redefinitions and Substitutions, How source-highlight works, Explicit subexpressions with names, Language Definitions
 @section 再定義と置換
 
-この二つの機能は、既存の言語定義にいくらかの変更加えて再利用することによって言語を定義したい場合に便利だ。
-通常だと、他の言語定義ファイルを@code{include}して、いくつかの要素について再定義と置き換えを行なう。
+この二つの機能は、既存の言語定義に何らかの変更加えて再利用することによって言語を定義したい場合に便利です。
+通常は、他の言語定義ファイルを@code{include}して、いくつかの要素について再定義と置き換えを行うことになります。
 
 @cindex redef
-@code{redef}を使うと、その言語エレメントの元の定義を新しい定義で消してしまう。
-その新しい言語定義は、まさにその定義の位置に配置される。
-たとえば、@code{caml}言語の定義を再利用することで@code{sml}言語を定義するようなときにこの機能を使う。
-この二つの言語はキーワードだけが違う@footnote{少なくとも私の知る限り:-)}。
-事実、@file{sml.lang}の中身は次のように要約できる。
+@code{redef}を使うと、その言語エレメントの元の定義を新しい定義で消すことになります。
+その新しい言語定義は、まさにその新しい定義の位置に配置されます。
+例えば、@code{caml}言語の定義を再利用して、@code{sml}言語を定義するような時にこの機能を使います。
+この二つの言語は、キーワードだけが違います@footnote{少なくとも私の知る限り:-)}。
+実際、@file{sml.lang}の中身は次のように要約できます。
 
 @example
 include "caml.lang"
@@ -1974,9 +2115,11 @@ redef keyword = "abstraction|abstype|and|andalso..."
 redef type = "int|byte|boolean|char|long|float|double|short|void"
 @end example
 
-この新しい言語エレメントの定義は、再定義されたちょうどその位置に現われるので、そのような正規表現は、それよりも前のもの（インクルードされるファイルにあるもの）がマッチしなかったときだけマッチするということを意味している。
-これによって、望まない結果が生じるケースもある（@code{sml}のケースは違うけれども）。
-言い換えてみよう。次のコードを見てほしい。
+この新しい言語エレメントの定義は、再定義されたちょうどその位置に現われます。
+そのため、その正規表現は、それ以前の正規表現（インクルードされるファイルにあるもの）がマッチしなかった時だけマッチするということを意味しています。
+これによって、望まない結果が生じるケースもあります（@code{sml}のケースは違いますけれども）。
+言い換えてみます。
+次のコードを見てください。
 
 @example
 keyword = "foo"
@@ -1986,7 +2129,7 @@ redef keyword = "myfoo"
 @end example
 
 @noindent
-このコードはさらに次のコードと等価である。
+このコードは、次のコードと等価です。
 
 @example
 type = "int"
@@ -1994,9 +2137,10 @@ keyword = "myfoo"
 @end example
 
 @cindex subst
-これが必要なものではないのなら、@code{subst}を使うことができる。
-これは@code{redef}と似ているが、言語エレメントの前の最初の定義を、その最初の定義のちょうどその位置で置き換えてしまうということが異なる（他の可能な限りの定義は単に消去される）。
-次のコードを見てほしい。
+これが所望でなければ、@code{subst}を使うことができます。
+これは、@code{redef}と似ています。
+ただし、その言語エレメントの最初の定義を、その最初の定義のちょうどその位置で置き換えてしまいます（他の定義があった場合は単に消去されます）。
+次のコードを見てください。
 
 @example
 keyword = "foo"
@@ -2006,15 +2150,16 @@ subst keyword = "myfoo"
 @end example
 
 @noindent
-これはすなわち、さらに次のコードと等価である。
+これは、次のコードと等価です。
 
 @example
 keyword = "myfoo"
 type = "int"
 @end example
 
-要求にぴったりと合うのがどちらなのかを決めるのはあなた次第だ。
-この機能で、@code{java}を元にして@code{javascript}を定義してもよい。
+要求にぴったりと合うのがどちらなのかを判断するのはユーザです。
+この機能を使って、@code{java}の用語を元にして@code{javascript}を定義することもできるでしょう。
+例えば、次のようになります。
 
 @example
 include "java.lang"
@@ -2023,125 +2168,128 @@ subst keyword = "abstract|break|case|catch|class|if..."
 @end example
 
 @noindent
-ここで、@code{redef}は、@code{if (exp)}が関数呼び出しとしてハイライトされてしまうという望まない振舞いをしてしまう。
-これはfunctionエレメントの定義が@code{if}をキーワードとして再定義するものより先に来て（そして先にマッチして）しまうからだ。
-もう一つ別の例を挙げると、C/C++の言語定義を再利用したC#の言語定義である（@ref{C/C++とC#のハイライティング}）。
+@code{redef}を使うと、@code{if (exp)}が関数呼び出しとしてハイライトされてしまうという望まない振舞いをしてしまいます。
+これは、functionエレメントの定義が、@code{if}をキーワードとして再定義するものより先に来て（そして、先にマッチして）しまうためです。
+もう一つ別の例を挙げますと、C/C++の言語定義を再利用したC#の言語定義です。
+@xref{Highlighting C/C++ and C#}.
+
 
-@node source-highlightの仕組み, 正規表現に関する注意, 再定義と置換, 言語の定義
+@node How source-highlight works, Notes on regular expressions, Redefinitions and Substitutions, Language Definitions
 @section source-highlightの仕組み
 
-@ref{言語の定義}の冒頭で少し書いたように、source-highlightは言語の定義ファイルにある定義を使って、入力ファイルのトークンをハイライトするのに使う正規表現を内部的にオンザフライに生成する。
-ここで、言語定義ファイルを正しく書く方法を理解するのに重要となる内部の詳細について述べる@footnote{source-highlightによる正規表現のマッチングに関する戦略はバージョン2.11から変わった（そしてバージョン2.10においては、使用している戦略が完全に概念的に正しいものではなく、オーバーヘッドが多くあった）}。
+別の節（@pxref{Language Definitions}）の冒頭で少し書いたように、source-highlightは、言語定義ファイルにある定義を使って、入力ファイルのトークンをハイライトするのに使う正規表現を内部的にオンザフライに生成します。
+ここでは、言語定義ファイルを正しく書く方法を理解するのに重要となる内部の詳細について説明します@footnote{source-highlightによる正規表現のマッチングに関する戦略はバージョン2.11から変わりました。
+バージョン2.10においては、使用している戦略が完全に概念的に正しいものではなく、オーバーヘッドが多くありました。}。
 
-まず、各エレメントの定義ごとに、source-highlightがハイライトのためのルールを作る（同じ言語エレメントに該当するものでもそのようにする）。
-従って、各言語エレメントのファイルはハイライトのためのルールのリストに対応する。
-source-highlightは、入力ファイルの各行について、その行全体を（もっと正しく言うと、その行のまだハイライトされていない部分を）これらのルール全てに対してマッチしてみる。
-ハイライトのためのルールが一つマッチしたらすぐに止めるわけではない。
-「ベター」にマッチする別のルールがあるかもしれないからだ。
-ここで、全てというのは基本的に@emph{ベターマッチ}という意味に帰着する。
+まず、source-highlightは、各エレメントの定義ごとに、ハイライトのためのルールを作ります（同じ言語エレメントに該当するものでもそのようにします）。
+従って、各言語エレメントのファイルは、ハイライトのためのルールのリストに対応することになります。
+source-highlightは、入力ファイルの各行について、その行全体（もっと、正しく言うと、その行のまだハイライトされていない部分）を、これらのルール全てに対してマッチしてみます。
+ハイライトのためのルールが一つマッチしたらすぐにマッチを止めるわけではありません。
+「ベター」にマッチする別のルールがあるかもしれないからです。
+ここで、全てのものが、基本的に、@emph{ベターマッチ}という意味に帰着します。
 
 @cindex matching strategy
-source-highlightが使う戦略は、次の状態の最初にマッチしたルールを選択するということだ。
+source-highlightが使う戦略は、次の状態のうち、最初にマッチしたルールを選択するということです。
 
 @itemize
-
 @item
-空のプリフィックス（あるいは空白の文字、すなわちスペースやタブだけを含むプリフィックス）を伴う
+空のプリフィックス（あるいは、空白文字だけ、すなわち、スペースやタブだけを含むプリフィックス）とマッチする。
 
 @item
-最小のプリフィックスを伴う
-
+最小のプリフィックスとマッチする。
 @end itemize
 
 @cindex prefix
-ここでマッチしたルールにおける@emph{プリフィックス}というのは、検査済みの文字列の、マッチしなかった部分である@footnote{正規表現の用語よれば}。
-従って、たとえば、次の文字列に対して@code{=}という簡単な正規表現をマッチさせてみる。
+ここで、マッチしたルールにおける@emph{プリフィックス}というのは、調査済みの文字列のマッチしなかった部分のことです@footnote{正規表現の用語よれば。}。
+従って、例えば、次の文字列に対して、@code{=}という簡単な正規表現をマッチさせてみます。
 
 @example
 i = 10;
 @end example
 
 @cindex suffix
-このとき、プリフィックスはスペースを含んだ@code{i }となる。
-正規表現の用語に従えば、残りのマッチしなかった部分、すなわち@code{ 10;}は@emph{サフィックス}という。
-source-highlightが、上で述べた戦略でマッチするルールを見つけると、マッチされた部分をフォーマットし（プリフィックスは@code{normal}でフォーマットし）、サフィックスの部分からマッチするルールの探索を再開する。
-そしてこれがその行全体を処理するまで続く。
+この時、プリフィックスは、スペースを含んだ@code{i }となります。
+正規表現の用語に従えば、残りのマッチしなかった部分、すなわち@code{ 10;}は@emph{サフィックス}と言います。
+source-highlightが、上で述べた戦略でマッチするルールを見つけた場合、マッチした部分をフォーマットし（プリフィックスは@code{normal}でフォーマットし）、サフィックスの部分から、マッチするルールの探索を再開します。
+そして、これが、その行全体を処理するまで続きます。
 
-例を用いて、もう少し詳しくこの戦略を説明したい。
-次に示す言語定義ファイルを考えてみよう。
+例を用いて、もう少し詳しくこの戦略を説明します。
+次に示す言語定義ファイルを考えてみてください。
 
 @include strategy_example.lang.texinfo
 
 @noindent
-そして、次の行をハイライトさせる。
+そして、次の行をハイライトさせます。
 
 @example
 int i = null
 @end example
 
-source-highlightは以下のステップを実行する。
+source-highlightは以下のステップを実行します。
 
 @enumerate
 
 @item
-最初のマッチするルールは@code{type}のためのものだ。
-空のプリフィックスなのでこれ以上見る必要はない。
-@code{int}は@code{type}としてハイライトされる。
-処理すべき残りの部分は@code{ i = null}となっている。
+最初のマッチするルールは、@code{type}に対するものです。
+空のプリフィックスなので、これ以上見る必要はありません。
+@code{int}は、@code{type}としてハイライトされます。
+処理すべき残りの部分は@code{ i = null}となります。
 
 @item
-最初にマッチするルールは@code{keyword}に対するものだ。
-プリフィックスは@code{ i = }である。
-このプリフィックスは空でない（あるいはスペースだけを含むわけではない）ので他のルールを検査する。
+最初にマッチするルールは、@code{keyword}に対するものです。
+プリフィックスは@code{ i = }です。
+このプリフィックスは空でありません（あるいは、スペースだけを含むわけではありません）。
+ですから、他のルールを検査します。
 
 @item
-次にマッチするルールは@code{symbol}に対するものだ。
-プリフィックスは@code{ i }である。
-このプリフィックスは@code{keyword}のときよりも小さい。
-他にもうマッチするルールはないので、@code{symbol}に対するものがベターだ。
-@code{=}がsymbolとしてハイライトされる。
-処理すべき残りの部分は@code{ null}となっている。
+次にマッチするルールは、@code{symbol}に対するものです。
+プリフィックスは@code{ i }です。
+このプリフィックスは、@code{keyword}に対するものよりも小さいものです。
+マッチするルールは他にもうありませんので、@code{symbol}に対するものがベターです。
+@code{=}がsymbolとしてハイライトされます。
+処理すべき残りの部分は@code{ null}となります。
 
 @item
-最初にマッチするルールは@code{keyword}に対するものだ。
-プリフィックスは空白だけなので、これ以上見る必要はない。
-@code{null}が@code{keyword}としてハイライトされる。
-
+最初にマッチするルールは、@code{keyword}に対するものです。
+プリフィックスは空白だけですので、これ以上見る必要はありません。
+@code{null}が@code{keyword}としてハイライトされます。
 @end enumerate
 
-以下の言語定義を示してこのセクションを終える。
-この言語定義は、ハイライトの戦略について述べたことをまとめたものだ。
+以下の言語定義を示してこのセクションを終えることにします。
+この言語定義は、ハイライトの戦略について述べたことをまとめたものです。
 
 @include test_string_stop.lang.texinfo
 
 
-@node 正規表現に関する注意, check-regexpプログラム, source-highlightの仕組み, 言語の定義
+@node Notes on regular expressions, The program check-regexp, How source-highlight works, Language Definitions
 @section 正規表現に関する注意
 @cindex regular expressions
 
-Boostのシンタックスを知るのにはBoostのドキュメンテーション（@uref{http://www.boost.org/libs/regex/doc/syntax.html}）を見るわけですが、ここで、あまり知られていないかもしれないが言語の定義に非常に便利な正規表現の形式についていくらか説明をしようと思う。
+Boostのシンタックスを知るにはBoostのドキュメント（@uref{http://www.boost.org/libs/regex/doc/syntax.html}）を参照します。
+けれども、ここでは、あまり知られていないかもしれませんが、言語の定義に非常に便利な正規表現の形式についていくらか説明をしようと思います。
 
 @cindex non-marking parenthesis
-カッコを使って正規表現の一部をグループ化する必要はあるが、マークされた部分表現を余分に吐き出させたくないようなときは、通常、@emph{マークしないカッコ}@code{(?:expression)}を使うことができる。
-これは、言語定義のシンタックスには必要ではない。
-たとえ普通のカッコを使ったとしても、source-highlightはマークしないカッコへそれを変形してしまう。
+通常、カッコを使って正規表現の一部をグループ化する必要があるが、マークされた部分表現を余分に吐き出させたくないような時は、@emph{マークしないカッコ}@code{(?:expression)}を使うことができます。
+これは、言語定義のシンタックスに必須のものではありません。
+たとえ普通のカッコを使ったとしても、source-highlightは、マークしないカッコへそれを変形してしまいます。
 
 @cindex marked subexpressions
-source-highlightは、@emph{マークされた部分表現}、すなわち@code{(}と@code{)}に括られたものを、マークしない部分表現（つまり上で説明したもの）に変換する。
-バージョン2.7から、@code{`}の内側に正規表現を書いた場合には、そのマークされた部分表現はそのまま残される（@ref{正規表現の指定方法}も参照してほしい）。
-これは、@emph{後方参照}や@emph{条件}のときに便利だ。
+source-highlightは、@emph{マークされた部分表現}、すなわち、@code{(}と@code{)}に括られたものをマークしない部分表現（つまり上で説明したもの）に変換します。
+バージョン2.7から、@code{`}の内側に正規表現を書いた場合には、マークされた部分表現はそのまま残されます（@pxref{Ways of specifying regular expressions}）。
+これは、@emph{後方参照}や@emph{条件}の時に便利です。
 
 @cindex backreference
-エスケープ文字の後ろに1から9の範囲の数字nが付いたものは@emph{後方参照}で、n番目の部分表現にマッチしたのと同じ文字列にマッチするものだ。
-たとえば、@code{^(a*).*\1$}という表記は、@code{aaabbaaa}という文字列にはマッチするが、@code{aaabba}にはマッチしない。
-後方参照は、Perlの置換指示子のような場合に、コンパクトな言語エレメントを書くのに役立つ。
-なので、次のような場合を考える。
+エスケープ文字の後ろに1から9の範囲の数字nが付いたものは@emph{後方参照}です。
+n番目の部分表現にマッチしたのと同じ文字列にマッチします。
+例えば、@code{^(a*).*\1$}という表記は、@code{aaabbaaa}という文字列にはマッチしますが、@code{aaabba}にはマッチしません。
+後方参照は、Perlの置換指示子のような場合に、コンパクトな言語エレメントを書くのに役立ちます。
+次のような場合を考えます。
 
 @example
 regexp = `s([^[:alnum:][:blank:]]).*\1.*\1[ixsmogce]*`
 @end example
 
-これは次の形式の全てにマッチする。
+これは、次の形式の全てにマッチします。
 
 @example
 s/foo/bar/g
@@ -2151,30 +2299,34 @@ s@@foo@@bar@@g
 @end example
 
 @cindex lookahead asserts
-正規表現の形式で便利なのが、@emph{前方先読み表明（Forward Lookahead Asserts）}だ。
-これには二つの形式があって、一つは肯定的先読み表明そしてもう一つが否定的先読み表明である。
+正規表現の形式で便利なのが、@emph{前方先読み表明（Forward Lookahead Asserts）}です。
+前方先読み表明には二つの形式があります。
+一つは、肯定的先読み表明、そして、もう一つが、否定的先読み表明です。
 
 @table @code
 @item (?=abc) 
-``abc''という表現が後に続く場合にだけゼロ文字にマッチする。（訳注：ゼロ文字にマッチするというのは、要するに、この表現自体何らかの個別の文字にマッチしたり文字を捕捉したりすることはなく、ゼロの幅であるということです）
+``abc''という表現が後に続く場合にだけ、ゼロ文字にマッチします@footnote{訳注：ゼロ文字にマッチするというのは、要するに、この表現自体何らかの個別の文字にマッチしたり文字を捕捉したりすることはなく、ゼロの幅であるということです。}。
+
 @item (?!abc) 
-``abc''という表現が後に続かない場合にだけゼロ文字にマッチする。
+``abc''という表現が後に続かない場合にだけ、ゼロ文字にマッチします。
 @end table
 
-たとえば、関数の定義（@file{function.lang}）において、次のような正規表現を使う。
+例えば、関数の定義（@file{function.lang}）において、次のような正規表現を使います。
 
 @example
 ([[:alpha:]]|_)[[:word:]]*(?=[[:blank:]]*\()
 @end example
 
 @noindent
-これによって、@code{(?=\()}という正規表現で、関数名の後開きカッコ@code{(}がマッチするかどうかをテストする。
-しかし、それがマッチすることがあって、入力にその部分を残したままにしておく。
-そうすると、そのカッコが関数名と同じようにフォーマットされることは無い（この言語定義の理解を深めるには@ref{source-highlightの仕組み}も参照してほしい）。
+これによって、@code{(?=\()}という正規表現で、関数名の後に、開きカッコ@code{(}がマッチするかどうかをテストします。
+しかし、それがマッチ可能な場合には、その部分を入力に残したままにしておきます。
+そうすると、そのカッコは、関数名と同じようにフォーマットされることはありません。
+この言語定義の理解を深めるには、別節も参照してください。
+@xref{How source-highlight works}.
 
-このような正規表現の形式を使う場合には注意してほしい。
-入力の一部が実際には取り除かれないので、正規表現をきちんと書かなければ、いつも同じ入力部分をスキャンしてしまうことになるかもしれない（要するにループしている）。
-たとえば、次のような言語定義を考えてみよ。
+このような正規表現の形式を使う場合には注意してください。
+入力の一部が実際に取り除かれませんので、正規表現をきちんと書かなければ、いつも同じ入力部分をスキャンしてしまうことになるかもしれません（要するにループしています）。
+例えば、次のような言語定義を考えてみてください。
 
 @example
 state foo = '(?=foo)' begin
@@ -2183,7 +2335,7 @@ end
 @end example
 
 @noindent
-そして次のものが入力ファイルである。
+以下が入力ファイルです。
 
 @example
 hello
@@ -2192,10 +2344,10 @@ bar
 @end example
 
 @noindent
-@code{foo}をマッチしたら、すぐ、それを入力においたまま、stateに入る。
-stateでは、入力に残したままの@code{foo}というワードのマッチを試みる。
-ご想像の通りかもしれないが、これによって、source-highlightは永久にループしてしまう。
-恐らく、次のような言語定義が書きたかったのではないだろうか。
+@code{foo}にマッチしたら、それを入力に残したまま、すぐ、stateに入ります。
+stateでは、入力に残したままの@code{foo}というワードのマッチを試みます。
+ご想像の通りかもしれませんが、これによって、source-highlightは永久にループしてしまいます。
+恐らく、次のような言語定義が書きたかったのではないでしょうか。
 
 @example
 state foo = '(?=foo)' begin
@@ -2204,31 +2356,33 @@ end
 @end example
 
 @noindent
-しかし、カット・アンド・ペースト・エラーというのは勝手なものだった ;-)
+しかし、カット・アンド・ペーストのエラーというのは勝手なものでした。 ;-)
 
 @cindex lookbehind asserts
-@emph{戻り読み表明}というものも使うことができる。
+@emph{戻り読み表明}も使うことができます。
 
 @table @code
 @item (?<=pattern)
-  現在の場所よりも前の文字に対してpatternがマッチするときだけゼロ文字消費する（patternは固定幅でなければならない）。
+  現在の場所よりも前の文字に対してpatternがマッチする時だけゼロ文字消費します（patternは固定幅でなければなりません）。
 @item (?<!pattern) 
-  現在の場所よりも前の文字に対してpatternがマッチしないときだけゼロ文字消費する（patternは固定幅でなければならない）。
+  現在の場所よりも前の文字に対してpatternがマッチしない時だけゼロ文字消費します（patternは固定幅でなければなりません）。
 @end table
 
 @cindex conditional expressions
-もう一つ、進んだ正規表現のメカニズムなのが@emph{条件式}の一つである。
+もう一つ、進んだ正規表現のメカニズムなのが@emph{条件式}の一つです。
 
 @table @code
 @item (?(condition)yes-pattern|no-pattern) 
-conditionが真であればyes-patternのマッチを試み、そうでなければno-patternのマッチを試みる。
+conditionが真であればyes-patternのマッチを試みます。
+そうでなければno-patternのマッチを試みます。
 @item (?(condition)yes-pattern) 
-conditionが真であればyes-patternのマッチを試み、そうでなければ失敗する。
+conditionが真であればyes-patternのマッチを試みます。
+そうでなければ失敗します。
 @end table
 
-conditionは先読み表明か、あるいはマークされた部分表現のインデックス@footnote{エスケープ文字は使わず、インデックスだけ}である（この部分表現がマッチすればconditionは真になる）。
-たとえば、次に示す式@footnote{この式は、boostのリスト（訳注：メーリングリスト？）に私がポストした問題の解決策として、Boost regexライブラリの作者であるJohn Maddockが出したものだ。@uref{http://thread.gmane.org/gmane.comp.lib.boost.devel/158237/focus=158276}}を見てほしい。
-これは、読み易くなるようにすべくより多くの行を使って書いたものだ。
+conditionは先読み表明か、あるいは、マークされた部分表現のインデックス@footnote{インデックスだけです。エスケープ文字は使いません。}です（この部分表現がマッチすればconditionは真になります）。
+例えば、次に示す式@footnote{この式は、boostのリストに私がポストした問題の解決策として、Boost regexライブラリの作者であるJohn Maddockが出したものです。@uref{http://thread.gmane.org/gmane.comp.lib.boost.devel/158237/focus=158276}}を見てください。
+これは、読み易くなるように、より行を使って書いたものです。
 
 @example
 (?:
@@ -2246,23 +2400,25 @@ conditionは先読み表明か、あるいはマークされた部分表現の
 )))))
 @end example
 
-この式は、@code{(foo)}と@code{[foo]}、@code{@{foo@}}にマッチするが、@code{(foo]}や@code{@{foo]}、@code{@{foo)}にはマッチしない。
+この式は、@code{(foo)}、@code{[foo]}、@code{@{foo@}}にはマッチしますが、@code{(foo]}、@code{@{foo]}、@code{@{foo)}にはマッチしません。
+
 
-@node check-regexpプログラム, 言語エレメントの一覧, 正規表現に関する注意, 言語の定義
+@node The program check-regexp, Listing Language Elements, Notes on regular expressions, Language Definitions
 @section The program @command{check-regexp}
 
 @cindex @command{check-regexp}
-バージョン2.7から、source-highlightのパッケージには、@command{check-regexp}という小さな追加プログラムが含まれている。
-このプログラムは、コマンドラインで正規表現をテストできるようにするものだ。
+バージョン2.7から、source-highlightのパッケージには、@command{check-regexp}という小さな追加プログラムが含まれています。
+このプログラムは、コマンドラインで正規表現をテストできるようにするものです。
 
-単に、コマンドラインの1番目の引数として正規表現を書き、次にマッチしたい文字列を書いて渡す（実際にこのプログラムは指定された正規表現で文字列を探索するので、文字列全体にマッチする必要はない）。
-シェルによる置換を避けるために、正規表現と文字列の両方を一重引用符で括ることは大事なことだ。
+単に、コマンドラインの1番目の引数として正規表現を書き、次に、マッチしたい文字列を書いて渡します（実際に、このプログラムは、指定された正規表現で文字列を探索しますので、文字列全体にマッチする必要はありません）。
+シェルによる置換を避けるために、正規表現と文字列の両方を一重引用符で括ることが大事なことです。
 
-プログラムは（成功裏するかもしれないマッチング）に関する情報を出力する。
-@code{what[0]}の部分は、マッチ全体を表わしていて、@code{what[i]}の部分はマッチしたi番目のマークされた部分表現を表わしている。
-このプログラムは、プリフィックスとサフィックスについても出力する。
+プログラムは、（成功するマッチング）@footnote{何故かカッコ書き。}に関する情報を出力します。
+@code{what[0]}の部分は、マッチ全体を表わしています。
+@code{what[i]}の部分は、マッチした部分のうち、マークされた部分表現のi番目を表わしています。
+このプログラムは、プリフィックスとサフィックスについても出力します。
 
-このプログラムの出力例である。
+以下は、このプログラムの出力例です。
 
 @example
 check-regexp '(a+)(.*)\1' 'aabcdaa' 'babbbacc'
@@ -2288,7 +2444,7 @@ suffix: cc
 total number of matches: 1
 @end example
 
-そして、次は、@ref{正規表現に関する注意}で見た、カッコをマッチングする例である。
+そして、次は、別の節（@pxref{Notes on regular expressions}）で見た、カッコをマッチングする例です。
 
 @smallexample
 check-regexp \
@@ -2314,43 +2470,44 @@ what[0]: [hithere]
 total number of matches: 1
 @end smallexample
 
-@node 言語エレメントの一覧, まとめの所見, check-regexpプログラム, 言語の定義
+
+@node Listing Language Elements, Concluding Remarks, The program check-regexp, Language Definitions
 @section 言語エレメントの一覧
 
-言語の定義を本当に役立つものとするためには、フォーマットするスタイルと正しく組み合わせて使わなければならい（@ref{出力フォーマットスタイル}を参照せよ）。
-しかし、別々のこのファイルが同じ人物によって開発されるわけでないかもしれない。
-あるいは、ただ単に、誰かがいずれかのファイルをカスタマイズしたいと考えるかもしれない。
-出力フォーマットスタイルファイルをうまく定義するには、言語定義ファイルに定義されている各言語エレメントのことを知っておくべきだ。
-言語定義ファイル自体の中身を見なければならない（そして再帰的にインクルードされているファイルをそれぞれ見なければならない）代わりに、コマンドラインオプションの
+言語の定義を本当に役立つものとするためには、フォーマットするスタイルと正しく組み合わせて使わなければなりません（@pxref{Output format style}）。
+しかし、この別々のファイルが、同じ人物によって開発されるわけでないかもしれません。
+あるいは、ただ単に、いずれかのファイルをカスタマイズしようと考える人がいるかもしれません。
+出力フォーマットスタイルファイルをうまく定義するには、言語定義ファイルに定義されている各言語エレメントのことを知っておく必要があります。
 @cindex @code{--show-lang-elements}
-@code{--show-lang-elements}を使ってもよい@footnote{バージョン2.4から}。
-これは、指定された言語定義ファイルでハイラトされる言語エレメントを全て標準出力へ単に出力するものだ。
+言語定義ファイル自体の中身を見なければならない（そして、再帰的にインクルードされているファイルをそれぞれ見なければならない）代わりに、コマンドラインオプションの@code{--show-lang-elements}を使うことができます@footnote{バージョン2.4からです。}。
+これは、指定された言語定義ファイルでハイライトされる言語エレメントを標準出力へ単に全て出力します。
 
-たとえば、@code{cpp.lang}の場合次のようなものが得られる。
+例えば、@code{cpp.lang}の場合、次のようなものが出力されます。
 
 @example
 @include cpp.langelems.texinfo
 @end example
 
-また、@code{log.lang}の場合ならば次のようなものが得られる。
+また、@code{log.lang}の場合ならば、次のようなものが出力されます。
 
 @example
 @include log.langelems.texinfo
 @end example
 
-@node まとめの所見, デバッギング, 言語エレメントの一覧, 言語の定義
+
+@node Concluding Remarks, Debugging, Listing Language Elements, Language Definitions
 @section まとめの所見
 
-こういった機能を全て組み合わせることで、想像を膨らませ、わずかな行のコードを書いて既存のものを再利用しながら、
-FlexやBisonのような複雑な言語のハイライティングを定義することができる。
-たとえば、FlexやBisonは、それ独自のシンタックスを持ち、そのソース言語の特定部分にC/C++のコードを書くことができる。
-たとえば、次の例の中で、一番外側のブラケットの間にあるコードは、C++のコードで、C++言語の定義に従ってハイライトされるべきものだ（@code{$}が前に付いている変数は別にして）。
+こういった機能を全て組み合わせることで、想像を膨らませ、わずかな行のコードを書いて既存のものを再利用しながら、FlexやBisonのような複雑な言語のハイライティングを定義することができます。
+例えば、FlexやBisonは独自のシンタックスを持ち、ソース言語の特定部分に、C/C++のコードを書くことができます。
+例えば、次の例の中で、一番外側のブラケットの間にあるコードはC++のコードです。
+C++言語の定義に従ってハイライトされるべきものです（@code{$}が前に付いている変数は除きます）。
 
 @example
 globaltags : options @{ if (...) @{ setTags( $1 ); @} @}
 @end example
 
-これを行なうのは簡単だ（@file{flex.lang}から取ったもの）。
+これを行なうのは簡単です（@file{flex.lang}から持って来たものです）。
 
 @example
 state cbracket delim "@{" "@}" multiline nested begin
@@ -2359,25 +2516,26 @@ state cbracket delim "@{" "@}" multiline nested begin
 end
 @end example
 
-@code{nested}を使っているので、最後の閉じカッコ@code{@}}がマッチしたならばC++言語の定義はもうそれ以上は考慮されないということが確認できる。
+@code{nested}を使っているので、最後の閉じカッコ@code{@}}がマッチしたならば、C++言語の定義はそれ以上はもう考慮されません。
+
 
-@node デバッギング, 言語定義のチュートリアル, まとめの所見, 言語の定義
+@node Debugging, Tutorials on Language Definitions, Concluding Remarks, Language Definitions
 @section デバッギング
 @cindex debug
 
-言語の定義ファイルを書くとき、デバッグできるとかなり便利だ（複雑な正規表現を使用することで、思いもよらない振舞に悩むかもしれない）。
-バージョン2.1からは、@code{--debug-lang}というコマンドラインオプションが利用できる。
-このオプションを使えば、追加的な情報が標準出力へ出力される。
+言語の定義ファイルを書く時、デバッグができるとかなり便利です（複雑な正規表現を使用することで、思いもよらない振る舞いに悩むかもしれません）。
+バージョン2.1からは、@code{--debug-lang}というコマンドラインオプションが利用できます。
+このオプションを使えば、追加的な情報が標準出力へ出力されます。
 
-バージョン2.5からこのオプションは、下位の指定を受け付けるようになった（@ref{source-highlightの起動}を見よ）。
-@code{dump}（デフォルト）を使うと、後で説明する追加的な情報が全て、ユーザとやり取りすることなくダンプされる。
-@code{interactive}を使うと、フォーマットされた文字列それぞれ毎に、ユーザからの指示を待ってプログラムが停止する。
-この非常に原始的な対話的デバッグにおいては、ユーザは、@code{ENTER}を押して、次のフォーマットされた文字列に至るまでプログラムを継続させることだけすればよい。
-このようにして、入力ファイルの各部分でステップする機会が持てる。
-加えて、デバッグが有効の場合、プログラムがバッファリングを実行しなくなり、そのためフォーマットされたエレメントはすぐに出力されることになる。
-たとえば、@command{tail -f}というコマンドを使って、出力ファイルに対する変更をオンザフライに見ることができる。
+バージョン2.5から、このオプションは、補助的な指定を受け付けるようになりました（@pxref{Invoking source-highlight}）。
+@code{dump}（デフォルト）を使うと、後で説明する追加的な情報全てが、ユーザとやり取りすることなくダンプされます。
+@code{interactive}を使うと、フォーマットされた文字列それぞれごとに、ユーザからの指示を待つためプログラムが停止します。
+非常に原始的なこの対話的デバッグにおいては、ユーザは、@code{ENTER}を押して、フォーマットされた次の文字列に至るまでプログラムを継続させるだけです。
+このようにして、入力ファイルの各部分でステップする機会が得られます。
+加えて、デバッグが有効の場合、プログラムがバッファリングを実行しなくなり、そのため、フォーマットされたエレメントがすぐに出力されることになります。
+例えば、@command{tail -f}というコマンドを使えば、出力ファイルに対する変更をオンザフライに見ることができます。
 
-このコマンドラインオプションを使用したときに生成される追加的な情報というのは次のフォーマットになっている。
+このコマンドラインオプションを使用した時に生成される追加的な情報というのは次のフォーマットになっています。
 
 @example
 <.lang filename>:<line number>
@@ -2387,16 +2545,19 @@ entering: <next state's id>
 exiting state, level: <number of states> 
 @end example
 
-@code{entering}と@code{exiting}、@code{exitingall}で始まる行は、新たなstate/environmentに入ったり、state/environmentから一つあるいは全部抜け出したりすることに関連している（@code{current state}がもし表示されるのならば、@code{entering}の後に来て、その同じstateの正規表現を動的後方参照の置換を行なった後出力する。@ref{動的後方参照}）。
-The first line shows a link to the @file{.lang} definition file and the line number, i.e., and the sub-expression that matched and the line starting with @code{formatting} shows the source file string that matched with that expression.
-@code{formatting}で始まる行の前に部分表現へのリンクを持った行が無ければ、何の正規表現もマッチせず、@code{normal}のスタイルがその文字列をフォーマットするのに使われるということを意味している。
+@code{entering}、@code{exiting}、@code{exitingall}で始まる行は、新たなstate/environmentに入ったり、state/environmentから一つ抜け出したり、あるいは、全部抜け出したりすることに関連しています（@code{current state}が表示される場合、@code{entering}の後に表示されます。
+そして、動的後方参照の置換を行なった後、同じstateの正規表現を出力します。
+@pxref{Dynamic Backreferences}）。
+最初の行は、すなわち、@file{.lang}定義ファイルや行番号へのリンクを示します。
+そして、マッチした部分表現が示され、@code{formatting}で始まる行が、その部分表現でマッチしたソースファイルの文字列を示しています。
+@code{formatting}で始まる行の前に部分表現へのリンクを持った行が無ければ、何の正規表現もマッチせず、@code{normal}のスタイルがその文字列をフォーマットするのに使われるということを意味しています。
 
-次に示す（簡単化された）Javaのソースファイルを考えてみる。
+次に示す（簡単化された）Javaのソースファイルを考えてみてください。
 
 @include debug.java.texinfo
 
-さて、@code{--debug-lang}コマンドラインオプションを使って、@file{java.lang}をデバッグすることができる。
-そしてその出力は次のようになる。
+ここで、@code{--debug-lang}コマンドラインオプションを使って、@file{java.lang}をデバッグすることができます。
+出力は次のようになります。
 
 @example
 c_comment.lang:24
@@ -2432,190 +2593,209 @@ exiting state, level: 1
 ... omissis ...
 @end example
 
-これで、正規表現がどのように使用され、state/environmentにどのように入って抜けたかといったような情報が十分供給されているはずだ。
-出力されている部分表現が、@file{.lang}ファイルで記述されている元々のものと異なっているかもしれないことに注意してほしい。
-これは、source-highlightが前処理を実行するためだ。
-さらに、@file{.lang}ファイルでは全く定義されていない部分表現もある。
-たとえば、ラインワイド定義、すなわち、@code{start}キーワードの付いた定義の場合である（@ref{ラインワイド定義}）。
-上述の最後の数行、@code{expression: "\z"}と表示しているところだが、これは行末にマッチしたということを示している。
+これは、正規表現がどのように使用され、state/environmentにどのように入って抜けたかといったような情報を十分提供しています。
+出力されている部分表現が、@file{.lang}ファイルで記述されている元々のものと異なっているかもしれませんので注意してください。
+これは、source-highlightが前処理を実行するためです。
+さらに、@file{.lang}ファイルでは全く定義されていない部分表現もあります。
+例えば、ラインワイド定義、すなわち、@code{start}キーワードの付いた定義の場合です（@pxref{Line wide definitions}）。
+上述の最後の数行、@code{expression: "\z"}と表示しているところですが、これは、行末にマッチしたということを示しています。
 
-デバッグに便利なもう一つの機能が、@code{--show-regex}オプションである。
-これは、source-highlightが作成した正規表現オートマトンを標準出力に出力するものだ。
+デバッグに便利なもう一つの機能が、@code{--show-regex}オプションです。
+これは、source-highlightが作成した正規表現オートマトンを標準出力に出力するものです。
 
-例として次の言語定義（@file{comment-show.lang}）を考えてみよう。
+例として、次の言語定義（@file{comment-show.lang}）を考えてみてください。
 
 @include comment-show.lang.texinfo
 
 @noindent
-ここで次のコマンドを実行したとする。
+ここで、次のコマンドを実行したとします。
 
 @example
 source-highlight --show-regex=comment-show.lang
 @end example
 
 @noindent
-標準出力に次のような出力が得られる@footnote{バージョン2.9までは、@code{--show-regex}の出力は読むには少し複雑だった。今の出力がベターになっていることを望んでいる}。
+標準出力には、次のような出力が得られます@footnote{バージョン2.9までは、@code{--show-regex}の出力は読むのが少し難しいものでした。
+今の出力が良くなっていれば嬉しいです。}。
 
 @smallexample
 @include comment-show.show.texinfo
+@c
 @end smallexample
 
 @noindent
-これは、stateと、source-highlightが作成した入力ソースのフォーマットに使われる正規表現オートマトンのハイライトルールを示している。
+これは、source-highlightが作成し、入力ソースのフォーマットに使われる正規表現オートマトンのハイライトルールとstateを示しています。
 
-各stateは、識別のためのユニークな番号が付けられている。
-さらに、そのstateのデフォルトのエレメントが表示される（つまり、stateのルールが何もマッチしなかったならば、その部分はデフォルトのエレメントスタイルでハイライトされる）。
-たとえば、最初のstateはデフォルトのスタイルがnormalだ。
-それから、各state毎にそのstateのルールを表示する。
-各ルールでは、そのルールに対応するエレメントやルールの正規表現、その他の情報を表示する。
-それらは以下で説明する。
+各stateは、識別のためのユニークな番号が付けられています。
+さらに、そのstateのデフォルトのエレメントが表示されます（つまり、stateのルールが何もマッチしなかった場合、その部分は、デフォルトのエレメントスタイルでハイライトされます）。
+例えば、最初のstateはデフォルトのスタイルがnormalです。
+それから、各state毎にそのstateのルールを表示します。
+各ルールでは、そのルールに対応するエレメントやルールの正規表現、その他の情報を表示します。
+以下で説明します。
 
-@code{/**}（特殊文字をエスケープした文字列@code{/\*\*}として表示される）とマッチする場合、新しいstateに入る。
-この場合はstate 2（@code{next: 2}）。
-これは、新たなenvironmentを定義する区切られたエレメントに相当する（@ref{state/environment定義}）。
-実際それがenvironmentであってstate（このstateの概念はオートマトンのstateの概念とは違うことに注意）でないということは、デフォルトのエレメントがenvironmentそれ自身と同じであるということでわかる。
-@code{*/}とマッチすれば、すなわち、区切られたエレメントの最後になれば、一段階抜ける。
-つまりstate 1に戻る。
-次に、@code{cbracket}についてのstateがある。
-これはenvironmentではない。
-実際そのデフォルトのエレメントはnormalだ。
-このstateの2番目のルール@code{\\.}は、stateの定義の@code{escape}文字列を表わしている。
-区切られたエレメントは、ネストするように定義されるので、3番目の@code{@{}という@code{nested}という情報のついたルールを使う。
-なので、これにマッチすれば、単にstate 3自身の新たなインスタンスに入る。
+@code{/**}（特殊文字をエスケープした文字列@code{/\*\*}として表示されます）とマッチする場合、新しいstateに入ります。
+この場合はstate 2（@code{next: 2}）です。
+これは、新たなenvironmentを定義する区切られたエレメントに相当します（@pxref{State/Environment Definitions}）。
+それが実際はenvironmentであって、state（このstateの概念は、オートマトンのstateの概念とは違うことに注意）でないということは、デフォルトのエレメントがenvironment自体と同じであるということから分かります。
+@code{*/}とマッチした場合、つまり、区切られたエレメントの最後になった場合、一段階抜けます。
+すなわち、state 1に戻ります。
+次に、@code{cbracket}についてのstateがあります。
+これはenvironmentではありません。
+実際、デフォルトのエレメントはnormalです。
+このstateの2番目のルール@code{\\.}は、stateの定義の@code{escape}文字列を表わしています。
+区切られたエレメントは、ネストするように定義されますので、3番目の@code{@{}という@code{nested}情報のついたルールを使います。
+ですから、これにマッチすれば、state 3自身の新たなインスタンスに単に入ります。
 
-@code{string}と@code{string2}は、@code{multiline}オプションによって、暗黙のうちに示される違いというのもを表わしている。
-source-highlightは入力行を別々に処理するために、最初のdelimを使った定義は一つの正規表現で処理できるが、複数行のバージョンはそれができない。
+@code{string}と@code{string2}は、@code{multiline}オプションによって暗黙のうちに示される違いを表わしています。
+source-highlightは入力行を別々に処理するために、最初のdelimを使った定義は一つの正規表現で処理できますが、複数行のバージョンはそれができません。
 
-state/environmentは、外側と内側の状態を理解するのが簡単になるようにするためのものだということに留意してほしい。
+state/environmentは、外側と内側の状態を理解するのが簡単になるようにするためのものということに留意してください。
 
-さて、前の例のバリエーションを考えてみよう。
+さて、前の例のバリエーションを考えてみましょう。
 
 @include comment-show2.lang.texinfo
 
-@code{--show-regex}の出力を見る。
+@code{--show-regex}の出力を見ます。
 
 @smallexample
 @include comment-show2.show.texinfo
+@c
 @end smallexample
 
-@code{regexp}というルールで、@code{`}の正規表現（@ref{正規表現の指定方法}）を使ったので、後方参照を正しく動作させるために部分表現は変換されない。
+@code{regexp}というルールで、@code{`}の正規表現（@pxref{Ways of specifying regular expressions}）を使いました。
+そのため、後方参照を正しく動作させるため、部分表現は変換されません。
 
-最後のルールは、名前付きの明示的な部分表現を使っている（@ref{名前を使った明示的な部分表現}）。
-この式は、違うエレメントから構成されているけれども、全体としてマッチする。
+最後のルールは、名前付きの明示的な部分表現を使っています（@pxref{Explicit subexpressions with names}）。
+この式は違うエレメントから構成されていますが、全体としてマッチします。
 
-@node 言語定義のチュートリアル,  , デバッギング, 言語の定義
+
+@node Tutorials on Language Definitions,  , Debugging, Language Definitions
 @section 言語定義のチュートリアル
 
-ここで、言語定義の例をいくつか提供する。
-前のセクションで既にコード片をいくつか紹介したが、ここでは、言語定義の完全な例を提供する。
-これはsource-highlightの配布物自体に含まれているものだ。
+ここで、言語定義の例をいくつか提供します。
+前のセクションでコード片をいくつか既に紹介しました。
+ここでは、言語定義の完全な例を示します。
+これは、source-highlightの配布物自体に含まれているものです。
 
-特に、言語定義のシンタックス自体の言語定義をまず示す（@file{langdef.lang}）。
-これは、このセクションで示す言語定義の例をハイライトするのに使うものである（このマニュアルを@code{info}コマンドで見ているならばハイライトされているのはわからない）。
-もちろん、この例はそれ自体ハイライトされている。
+特に、言語定義のシンタックス自体の言語定義をまず示します（@file{langdef.lang}）。
+これは、このセクションで示す言語定義の例をハイライトするのに使うものです（このマニュアルを@code{info}コマンドで見ている場合は、ハイライトされていることはわかりません）。
+もちろん、この例は、それ自体ハイライトされています。
 
 @include langdef.lang.texinfo
 
-これらの例をTexinfoでハイライトするスタイルは、@ref{出力フォーマットスタイル}で示されている@file{texinfo.style}だ。
-このスタイルのシンタックスに対する言語定義（@file{style.lang}ファイル）はさらにシンプルだ。
+これらの例をTexinfoでハイライトするスタイルは、別節（@pxref{Output format style}）で示している@file{texinfo.style}です。
+このスタイルのシンタックスに対する言語定義（@file{style.lang}ファイル）はさらにシンプルです。
 
 @include style.lang.texinfo
 
-この定義は、言語定義のシンタックスがシンプルなので、かなりシンプルになっているということに注意していほしい。
-次の例では、さらに複雑な機能を使って、もっと複雑な言語のシンタックスをハイライトする方法を見ていく。
+言語定義のシンタックスがシンプルですので、この定義がかなりシンプルになっていることに注意してください。
+次の例では、さらに複雑な機能を使って、もっと複雑な言語のシンタックスをハイライトする方法を見ていきます。
 
 @menu
-* C/C++とC#のハイライティング::   
-* Diffファイルのハイライティング::     
-* 擬似的な意味解析::    
+* Highlighting C/C++ and C#::   
+* Highlighting Diff files::     
+* Pseudo semantic analysis::    
 @end menu
 
-@node C/C++とC#のハイライティング, Diffファイルのハイライティング, 言語定義のチュートリアル, 言語定義のチュートリアル
+
+@node Highlighting C/C++ and C#, Highlighting Diff files, Tutorials on Language Definitions, Tutorials on Language Definitions
 @subsection C/C++とC#のハイライティング
 
-これは、Cの言語定義である。
-@file{c.lang}というファイルでインクルードされている。
+これは、C言語の言語定義です。
+@file{c.lang}というファイルでインクルードされます。
 
 @include c.lang.texinfo
 
 @noindent
-たくさんの@code{include}を利用していることに注目してほしい。
-これらの部分で、他の言語定義を再利用している（例えば、JavaはC/C++と共通の部分が多数あるので、そういった部分は別のファイルとして書かれている）。
-とくに、コメントの定義の部分である。
+たくさんの@code{include}を利用していることに注目してください。
+これらの部分は、他の言語定義を再利用されます（例えば、JavaはC/C++と共通の部分が多数ありますので、そういった部分は別のファイルとして書かれています）。
+特に、コメントの定義の部分です。
 
 @include c_comment.lang.texinfo
 
 @noindent
-さて、ラインワイドコメント（@code{//}）に対する定義と、URLアドレスとメールアドレスもハイライトする複数行コメントに対する定義がある（ここには示されていない@file{url.lang}ファイルで定義されている）。
-さらに、自動的にドキュメンテーションを生成するツール（DoxygenやJavadocのようなもの）で使われるコメント、つまり、@code{/**}や@code{///}で始まるものについてもHTMLのシンタックス（ここでは示されていない@file{html.lang}ファイルで定義されている）を完全にハイライトする。
+ここに、ラインワイドコメント（@code{//}）に対する定義と、URLアドレスとメールアドレスもハイライトする複数行コメントに対する定義があります（@file{url.lang}ファイルで定義されていますが、ここには示していません）。
+さらに、ドキュメントを自動生成するツール（DoxygenやJavadocのようなもの）で使われるコメント、つまり、@code{/**}や@code{///}で始まるものについてもHTMLのシンタックス（@file{html.lang}ファイルで定義されていますが、ここには示されていません）を完全にハイライトします。
 
-@file{c.lang}に戻って、構造体名をハイライトするのに名前付きの部分表現（@ref{名前を使った明示的な部分表現}を見よ）を使っている（@code{struct}が前に付いているときにキーワードとしてハイライトされる）。
+@file{c.lang}に戻って、構造体名をハイライトするのに名前付きの部分表現（@pxref{Explicit subexpressions with names}）を使っています（@code{struct}が前に付いている時にキーワードとしてハイライトします）。
 
-プリプロセッサディレクティブの@code{#include}については、この場合、@code{<file>}というシンタックスでインクルードされるファイルが、文字列としてフォーマットされなければならない（そして、このコンテキストにおいてだけ、@code{<>}を文字列として考え、その他の場所ではすべてオペレータとして考える）ので、state定義を使っている。
-stateは、そのstateの外側の定義を消してしまうので、このコンテキストにおいてもコメントをハイライトするために、@file{c_comment.lang}をもう一度インクルードしなければならない@footnote{将来の拡張として、オーバーライドするのではなく、外側のコンテキストを拡張するstate/environmentを定義するのに、言語定義のシンタックスの中に、一つ何か方法を用意することを考えるかもしれない}。
-そして次に、その他のプリプロセッサディレクティブを全て捕捉する@code{preproc}の定義がある。
+プリプロセッサディレクティブの@code{#include}については、この場合、@code{<file>}というシンタックスでインクルードされるファイルが、文字列としてフォーマットされなければなりません（そして、このコンテキストにおいてだけ、@code{<>}を文字列として考え、その他の場所ではすべてオペレータとして考えます）ので、state定義を使っています。
+stateは、そのstateの外側の定義を消してしまいます。
+このコンテキストにおいてもコメントをハイライトするためには、@file{c_comment.lang}をもう一度インクルードしなければなりません@footnote{将来の拡張として、オーバーライドするのではなく、外側のコンテキストを拡張するstate/environmentを定義するできるように、言語定義のシンタックス中に、何か一つ方法を用意することを考えるかもしれません}。
+次に、その他のプリプロセッサディレクティブを全て捕捉する@code{preproc}の定義があります。
 
-インクルードされている@file{number.lang}というファイルは、数値定数をキャッチするための正規表現を定義していて（ここには示されない）、次に、文字列を定義する@file{c_string.lang}ファイルをインクルードする（また、Javaで共有される）。
+インクルードされている@file{number.lang}というファイルは、数値定数をキャッチするための正規表現を定義しています（ここには示していません）。
+次に、文字列を定義する@file{c_string.lang}ファイルをインクルードします（また、Javaで共有されます）。
 
 @include c_string.lang.texinfo
 
 @noindent
-文字列の内部では、特殊な文字（たとえば、@code{\n}や@code{\t}などのような）や、通常のエスケープされた文字を別の方法でハイライトしたい。
-これらは、`@code{\\.}'という正規表現でマッチされる、
+文字列の内部では、特殊な文字（例えば、@code{\n}や@code{\t}などのような文字）や、通常のエスケープされた文字を別の方法でハイライトしようと考えます。
+こういった文字は、`@code{\\.}'という正規表現でマッチできます。
 
-インクルードされている@file{symbols.lang}というファイルでは、シンボルが全て定義されている（他の言語でも共有している）。
+インクルードされている@file{symbols.lang}というファイルは、シンボルを全て定義しています（他の言語でも共有しています）。
 
 @include symbols.lang.texinfo
 
 @noindent
-ここでは、@code{\}や@code{|}という文字をエスケープしなければならいということがわかる以外に面白いことは無い。
+ここでは、@code{\}や@code{|}という文字をエスケープしなければならいということがわかる以外に面白いことはありません。
 
-インクルードされている@file{function.lang}というファイルでは、関数定義や関数呼び出しにマッチするための正規表現を定義している。
+インクルードされている@file{function.lang}というファイルは、関数定義や関数呼び出しにマッチする次のような正規表現を定義しています。
 
 @include function.lang.texinfo
 
 @noindent
-これは、開きカッコに対する前方先読み表明の例を示している（@ref{正規表現に関する注意}を参照）。
-@ref{ファイルのインクルード}で記したように、キーワードの定義の後にこのファイルをインクルードするのは非常に大事なことだ。
+これは、開きカッコに対する前方先読み表明の例を示しています（@pxref{Notes on regular expressions}）。
+別の節（@pxref{File inclusion}）で記したように、キーワードの定義の後にこのファイルをインクルードするのが非常に重要なこととなります。
 
-最後に、@file{c.lang}は@file{clike_vardeclaration.lang}というファイルをインクルードする。
+最後に、@file{c.lang}は、以下の@file{clike_vardeclaration.lang}というファイルをインクルードします。
 
 @include clike_vardeclaration.lang.texinfo
 
-この定義は、名前付きの部分表現を使って（@ref{名前を使った明示的な部分表現}を参照）、関数パラメータや変数宣言にあるユーザ型（たとえば構造体名）のマッチを試みる@footnote{広範囲のテストは行なっていないので、正しい状態のものを全て捕捉することはできないかもしれない}。
-基本的に型の識別子のマッチを試み、それからテンプレートの記述のマッチを試みる@footnote{OK、Cにテンプレートは無くて、C++にだけテンプレートがある。しかし、Cファイルをハイライトするのに不都合は無いはずだと考えている}。
-そして、完全な先読み表明がある。
-これは、@code{&}や@code{*}といった参照やポインタの記述が付く可能性のある変数の識別子のマッチを試みるもので、その後には、アサインメントの@code{=}や@code{;}が続いたり、もっと広く、@code{[:punct:]}や@code{[]}（配列の記述）が続いたりする。
-これは、以下のように（@code{usertype}をわざとイタリックで強調している）、正しいコンテキストでユーザ型をキャッチするはずだ。
+この定義は、名前付きの部分表現を使って（@pxref{Explicit subexpressions with names}）、関数パラメータや変数宣言にあるユーザ型（例えば、構造体名）のマッチを試みます@footnote{広範囲のテストは行なっていませんので、正しい状態のものを全て捕捉することはできないかもしれません}。
+基本的に、型の識別子のマッチを試み、それから、テンプレート記述のマッチを試みます@footnote{分かっています。
+Cにテンプレートはありません。
+C++にだけテンプレートがあります。
+しかし、Cファイルをハイライトするのに、これで不都合は無いはずだと考えています。}。
+そして、完全な先読み表明がある（@pxref{Notes on regular expressions}）。
+これは、@code{&}や@code{*}といった参照やポインタの記述が付く可能性のある変数の識別子のマッチを試みるものです。
+その後には、アサインメントの@code{=}や@code{;}が続いたり、もっと広く言うと、@code{[:punct:]}や@code{[]}（配列の記述）が続いたりします。
+これは、以下のように（@code{usertype}をわざとイタリックで強調しています）、正しいコンテキストでユーザ型を捕捉するはずです。
 
 @include test_vardecl.cc.texinfo
 
-注意してほしいが、3番目のグループに先読み表面を使っているので、マッチしたものは実際にフォーマットはされず、別のルールでフォーマットできるように入力ストリームに戻してしまう（たとえば、@code{*}や@code{=}に対する@code{symbol}）。
+3番目のグループに先読み表面を使っています。
+そのため、マッチしたものは実際にフォーマットはされず、別のルールでフォーマットできるように入力ストリームに戻してしまいますので注意してください（例えば、@code{*}や@code{=}に対する@code{symbol}）。
 
-少くともシンタックスの上ではC++はCの拡張であるので、C++に対する言語定義は、@file{cpp.lang}ファイル内でインクルードすることで、@file{c.lang}に依存している@footnote{バージョン2.9以前では、CとC++の両方に使われる@file{cpp.lang}だけが存在した。しかし、このようにすれば、C++のキーワードを変数名として使っているCプログラムがあった場合、もちろんそういったことはCでは正しいのであるが、そういった変数は実際にはキーワードとしてハイライトされてしまうことになり、そういう状況は正しくはなかった}。
+少くともシンタックスの上ではC++はCの拡張ですので、@file{cpp.lang}ファイルでインクルードされるC++に対する言語定義は、@file{c.lang}に依存しています@footnote{バージョン2.9以前では、CとC++の両方に使われる@file{cpp.lang}だけが存在していました。
+しかし、このようにすれば、C++のキーワードを変数名として使っているCプログラムがあった場合に問題となります。
+もちろん、Cでは正しいことなのですが、そういった変数があると、実際には、キーワードとしてハイライトされてしまうことになり、正しい状況ではありませんでした。}。
 
 @include cpp.lang.texinfo
 
-具体的には、キーワードのセットを拡張する。
-さらに、クラス（あるいは構造体）の名前をハイライトするのに名前付きの部分表現（@ref{名前を使った明示的な部分表現}）を使っていることに注意してほしい（@code{class}や@code{struct}、あるいは@code{typename}が前に付いているときに、キーワードとしてハイライトされる）。
+具体的には、キーワードのセットを拡張します。
+さらに、クラス名（あるいは、構造体名）をハイライトするのに名前付きの部分表現（@pxref{Explicit subexpressions with names}）を使っていることに注意してください（@code{class}、@code{struct}、あるいは、@code{typename}が前に付いている時に、キーワードとしてハイライトします）。
 
-さてこれで、C/C++に対する言語定義を書いたので、C#用のものを書くのは容易だ。
-プリプロセッサのエレメントとして@code{using}キーワードを追加し、キーワードと型を再定義する（よりベターに言えば、「置き換える」。@ref{再定義と置換}）必要があるだけだからである。
+さて、これで、C/C++に対する言語定義は記述できました。
+C#用のものを書くのは簡単です。
+プリプロセッサのエレメントとして@code{using}キーワードを追加し、キーワードと型を再定義する@footnote{よりベターに言うならば、「置き換える」です。
+@xref{Redefinitions and Substitutions}.}だけです。
 
 @include csharp.lang.texinfo
 
-@node Diffファイルのハイライティング, 擬似的な意味解析, C/C++とC#のハイライティング, 言語定義のチュートリアル
+
+@node Highlighting Diff files, Pseudo semantic analysis, Highlighting C/C++ and C#, Tutorials on Language Definitions
 @subsection Diffファイルのハイライティング
 
-さてここで、@code{diff}（普通はパッチを作成するのに使われる）が生成したファイルをハイライトしたい。
-このプログラムは三つの異なったフォーマットで出力を生成することができる（少なくとも私の知る限り）。
+さて、ここで、@code{diff}@footnote{普通はパッチを作成するのに使われます。}が生成したファイルをハイライトしようと思います。
+diffプログラムは、少なくとも私の知る限り、三つの異なったフォーマットで出力を生成することができます。
 
-@code{-u|--unified}というオプションを使えば、ファイル間の差が同じコンテキストで表示される。
-たとえば次のようになる（ここで示すdiffファイルの例は、ページの幅にフィットするように手で修正してある）。
+@code{-u|--unified}というオプションを使えば、ファイル間の差が同じコンテキストで表示されます。
+例えば、次のようになります（ここで示すdiffファイルの例は、ページの幅にフィットするように手で修正してあります）。
 
 @include example-u.diff.texinfo
 
-オプション@code{-c|--context}と使えば、差分は二つの別々の部分に示される。
+オプション@code{-c|--context}を指定すれば、差分は、二つの別々の部分に分けて示されます。
 
 @include example-c.diff.texinfo
 
@@ -2623,169 +2803,180 @@ stateは、そのstateの外側の定義を消してしまうので、このコ
 
 @include example-n.diff.texinfo
 
-まとめると、これら三つの異なったシンタックスを全て処理できるようにしたい。
-最初のフォーマットと2番目のフォーマットでは、衝突する部分がある。
-最初のものは@code{---}をファイルの新しいバージョンを示すのに使っている一方、2番目のフォーマットでは、それをファイルの古いバージョンを示すのに使っている。
-古い部分と新しい部分は別々にハイライトしたいので（強力なフォーマット機能が欠けているため、Texinfoのハイライティングでは見ることができないが、HTMLの出力例では二つの違う色を使っているのが目にできる）、この動作によって少し難しさが加わる。
-もちろん、diffのそれぞれの出力フォーマットに対応する三つの別々の言語定義を定義することもできた。
-しかし、同一ファイルでそれら全てを処理したかったのだ！
+まとめると、これら三つの異なったシンタックスを全て処理できるようにしたいということです。
+最初のフォーマットと2番目のフォーマットには、衝突する部分があります。
+最初のものは@code{---}をファイルの新しいバージョンを示すのに使っています。
+一方、2番目のフォーマットでは、同じものを、ファイルの古いバージョンを示すのに使っています。
+古い部分と新しい部分は異なったハイライトを行いたいので@footnote{強力なフォーマット機能が欠けているため、Texinfoのハイライティングでは見ることができませんが、HTMLの出力例では二つの違う色を使っているのが目にできます。}、この動作によって少し難しさが加わります。
+もちろん、diffのそれぞれの出力フォーマットに対応する三つの別々の言語定義を定義することもできました。
+しかし、全ての処理を同一ファイルで実現したかったのです。
 
-これがdiffファイルに対する言語定義である。
+これが、diffファイルに対する言語定義です。
 
 @include diff.lang.texinfo
 
-diffファイルを処理するときには、同じdiffのコマンドラインスイッチを使って生成した情報だけが含まれていると安全に仮定することができるので、diffの三つの出力フォーマットに対応する三つの別々のstateを定義する。
-これらのstateには簡単な定義で入るということに注意してほしい。
-@ref{state/environment定義}に記されているように、これは、自動的に抜け出す手段が用意されていないことを意味している。
-明示的に抜ける条件が指定されないので、つまり、stateの一つに一度入ると、決して終了しないということである。
-このことは我々の目的に適っている。
-もちろん、stateに入るための式は正しく定義されなければならないし、また、具体的に言うと、@code{---}が、@code{-u|--unified}オプションによる最初の差分の記述として使われるために、この最初の@code{---}という並びをまず探索するので、これが、処理しようとしているdiffフォーマットを推定する目印となっている。
-
-別の面白いこととして、処理しているファイルフォーマットを知りたいだけなので、開きカッコに対して前方先読み表明を使っていることがある。
-一旦正しいstateに入ったならば、特定のdiffファイルフォーマットのエレメントに対する正規表現を書くことができる。
-
-@code{-c|--context}オプションで作成したファイルに対しては、内側にenvironmentを二つ定義している。
-新しいファイルの部分に対するものと古いファイルの部分に対するものだ（これらは@code{---}や@code{***}、そして行番号情報で区切られている）。
-これらはenvironmentなので、どの式にもマッチしないものは、そのenvironmentを定義しているエレメントのスタイルに応じてフォーマットされることに注意してほしい。
-なので、normalとしてフォーマットされなければならないテキストに対する式も用意している。
-diffファイルについて言うと、これは空白で始まる行や@code{diff}で始まる行に相当する（上の例を見てみてほしい）。
-とくに、後者の場合は新しいファイルの部分の間でだけ起こる。
-このenvironmentではともに、抜け出す条件を定義しなければならない。
-両者の場合とも、これは互いに補完する部分の開始位置に一致する。
-この場合においても、前方先読み表明を使用している。
-それは、environmentから抜け出すためだけに使用している。
-外側の@code{oldfile}と@code{newfile}についての定義はソースファイルの情報の行をマッチするのに使われる。
-
-3番目のstateは、diffの通常の出力フォーマットに対応するもので、今となればもうわかりやすいはずだ。
-
-@node 擬似的な意味解析,  , Diffファイルのハイライティング, 言語定義のチュートリアル
+diffファイルを処理する時には、同じdiffのコマンドラインスイッチを使って生成した情報だけが含まれていると仮定しても差し支えありませんので、diffの三つの出力フォーマットに対応する三つの別々のstateを定義することにします。
+これらのstateには簡単な定義を使って入るということに注意してください。
+別の節に説明しているように、これは、自動的に抜け出す手段が用意されていないことを意味しています（@pxref{State/Environment Definitions}）。
+明示的に抜ける条件が指定されませんので、つまり、stateの一つに一度入ると、決して終了しないということです。
+このことは我々の目的に適っています。
+もちろん、stateに入るための式は正しく定義されなければなりません。
+また、具体的に言うと、@code{---}が、@code{-u|--unified}オプションによる最初の差分の記述として使われるために、この最初の@code{---}という並びをまず探索しますので、これが、処理しようとしているdiffフォーマットを推定する目印となっています。
+
+別の面白いこととして、処理しているファイルフォーマットを知りたいだけのために、開きカッコに対して前方先読み表明を使っていることがあります（@pxref{Notes on regular expressions}）。
+正しいstateに一度入ったならば、特定のdiffファイルフォーマットのエレメントに対する正規表現を書くことができます。
+
+@code{-c|--context}オプションで作成したファイルに対しては、内側にenvironmentを二つ定義しています。
+新しいファイル部分に対するものと古いファイル部分に対するものです（これらは、@code{---}、@code{***}、行番号情報で区切られています）。
+これらはenvironmentです。
+そのため、どの式にもマッチしないものは、environmentを定義しているエレメントのスタイルに応じてフォーマットされますので注意してください。
+ですから、normalとしてフォーマットしなければならないテキストに対する式も用意しています。
+diffファイルについて言うと、これは、空白で始まる行や@code{diff}で始まる行に相当します（上の例を見てください）。
+特に、後者の場合は新しいファイルの部分の間でだけ起こります。
+このenvironmentでは、抜け出す条件をともに定義しなければなりません。
+両者の場合とも、これは互いに補完する部分の開始位置に一致します。
+この場合においても、前方先読み表明を使用しています。
+environmentから抜け出すためだけに使用しています。
+外側の@code{oldfile}と@code{newfile}についての定義は、ソースファイルの情報の行をマッチするのに使われます。
+
+3番目のstateは、diffの通常の出力フォーマットに対応するもので、今となればもう分かりやすいはずです。
+
+
+@node Pseudo semantic analysis,  , Highlighting Diff files, Tutorials on Language Definitions
 @subsection 擬似的な意味解析
 
-source-highlightは、正規表現を用いて、入力ソースをレキシカルに解析することができるだけである。
-とくに、入力ソースが、その入力言語の点から文法的に正しいということを前提としている。
-しかし、言語定義のシンタックスを使い、また正しい正規表現を書くことで、入力ソースのある種の意味的な解析をシミュレートすることも可能だ。
+source-highlightは、正規表現を用いて、入力ソースをレキシカルに解析することができるだけです。
+特に、入力ソースが、その入力言語の点から文法的に正しいということを前提としています。
+しかし、言語定義のシンタックスを使い、また、正しい正規表現を書くことで、入力ソースのある種の意味的な解析をシミュレートすることも可能です。
 
-例として、以下のC（あるいはC++）のソースファイルを考えてほしい。
+例として、以下のC（あるいはC++）のソースファイルを考えてみてください。
 
 @include test_extreme_comment.cpp.texinfo
 
 @noindent
-@code{#if 0}と@code{#else}にあるコードが決して実行されない（実際コンパイルすらされない）ことを検証するのは簡単だ。
-なので、これをコメントとしてフォーマットしたくなるかもしれない。
+@code{#if 0}と@code{#else}にあるコードは決して実行されないことを検証するのは簡単です（実際、コンパイルすらされません）。
+ですから、これをコメントとしてフォーマットしたくなるかもしれません。
 
-従って、@file{cpp.lang}ファイルを基にして、別の言語定義を書く。
+従って、@file{cpp.lang}ファイルを基にして、別の言語定義を記述します。
 
 @include extreme_comment.lang.texinfo
 
 @noindent
-この最初のバージョンには故意に誤りを入れてある。
-environmentを開始するのに@code{start}エレメントを使ったが、そのエレメントは一つの行のスコープを持つので、期待した動作にならない。
+最初のこのバージョンには故意に誤りを入れてあります。
+environmentを開始するのに@code{start}エレメントを使いましたが、そのエレメントは一つの行のスコープを持ちます。
+そのため、期待した動作になりません。
 
 @include test_extreme_comment_wrong.texinfo
 
-ベターな解決方法は次のようなものだ。
+ベターな解決方法は次のようなものです。
 
 @include extreme_comment2.lang.texinfo
 
 @noindent
-ここでは、@code{comment} environmentに、区切られたエレメントを使わず、単に@code{#ifdef 0}にマッチする正規表現によって入っている
-そして、@code{#else}にマッチするか、@code{#endif}にマッチするときのどちらかに、そのenvironmentを抜け出す。
-これは動作するように思える。
+ここでは、区切られたエレメントを使わず、単に、@code{#ifdef 0}にマッチする正規表現によって@code{comment} environmentに入っています。
+そして、@code{#else}にマッチするか、@code{#endif}にマッチする時のどちらかに、そのenvironmentを抜け出します。
+これは動作するように思えます。
 
 @include test_extreme_comment_1.texinfo
 
-しかしながら、@code{#if...#else}がネストすることを考えた場合うまく動作しない。
-例として次のコードを考える。
-前述の言語定義でフォーマットされている。
+しかしながら、@code{#if...#else}がネストすることを考えた場合うまく動作しません。
+例として、次のコードを考えます。
+前述の言語定義でフォーマットされています。
 
 @include test_extreme_comment_wrong2.texinfo
 
 @noindent
-問題は、前述の言語定義が@code{#if}のネストを考慮していないために、@code{#else}か@code{#endif}にマッチする最初のタイミングで@code{comment} environmentから抜け出していることである。
+問題は、前述の言語定義が@code{#if}のネストを考慮していないために、@code{#else}か@code{#endif}にマッチする最初のタイミングで@code{comment} environmentから抜け出していることにあります。
 
-ネストが起きることに配慮しなければならない。
-これを実現するには、@code{nested}オプションを付けて区切られたエレメントを使用する（@ref{delim定義}）。
+ネストが起きることに配慮しなければなりません。
+これを実現するには、@code{nested}オプションを付けて区切られたエレメントを使用します。
+@xref{Delimited definitions}.
 
 @include extreme_comment3.lang.texinfo
 
 @noindent
-今度は、コードの期待通りのブロックがコメントとして正しくフォーマットされている。
+今度は、期待通りのコードブロックがコメントとして正しくフォーマットされています。
 
 @include test_extreme_comment_2.texinfo
 
-（@code{#endif}だけでなく）@code{#else}にマッチするときにもenvironmentを脱出することが大事であることに注意してほしい。
-このようにすれば、別の@code{#ifdef 0}に再度マッチすることができる。
-例えば、次のようなコードを考えてみてほしい。
+（@code{#endif}だけでなく）@code{#else}にマッチする時にも、environmentを脱出することが大事であることに注意してください。
+このようにすれば、別の@code{#ifdef 0}に再度マッチすることができます。
+例えば、次のようなコードを考えてみてください。
 
 @include test_extreme_comment_3.texinfo
 
-@node  出力言語の定義, リファレンスの生成, 言語の定義, Top
+
+@node  Output Language Definitions, Generating References, Language Definitions, Top
 @chapter 出力言語の定義
 @cindex output language definition
 
-バージョン2.1からsource-highlightは、固有のシンタックスを使って出力フォーマットを記述する（たとえば、HTMLや@LaTeX{}などでフォーマットする方法）。
-バージョン2.1以前では、新たな出力フォーマットを追加するのに、C++のクラスをたくさん書かなければならなかった。
-これは、新たな出力フォーマットを「動的に」追加するのに障害となっていた。
-source-highlightプログラムを丸ごと再コンパイルしなければならなかったからだ。
+バージョン2.1から、source-highlightは、固有のシンタックスを使って出力フォーマットを記述します（例えば、HTMLや@LaTeX{}などでフォーマットする方法など）。
+バージョン2.1以前では、新たな出力フォーマットを追加するのに、C++のクラスをたくさん書かなければなりませんでした。
+これは、新たな出力フォーマットを「動的に」追加するのに障害となっていました。
+source-highlightプログラムを丸ごと再コンパイルしなければならなかったからです。
 
-それに代わって、現在では、出力フォーマットは（願わくは）簡単なシンタックスでファイルで記述し、動的にロードされる。
-そして、これらの定義がテキストフォーマッタをオンザフライに生成するために内部で使用される。
+それに代わって、現在では、（願わくは）簡単なシンタックスで出力フォーマットをファイルに記述します。
+そして、出力フォーマットは動的にロードされます。
+これらの定義は、テキストフォーマッタをオンザフライに生成するために内部で使用されます。
 
-ここでは、多数の例に頼りながら、そのシンタックスを詳細に見ていく。
-これによって、ユーザが既存の出力フォーマットを修正したり、新しいものを作成するのが簡単にできる。
-こういったファイルは通常@file{.outlang}という拡張子を付ける。
+ここでは、多数の例に頼りながら、そのシンタックスを詳細に見ていきます。
+これによって、ユーザが既存の出力フォーマットを修正したり、新しいものを作成するのが簡単にできるようになります。
+こういったファイルには、通常、@file{.outlang}という拡張子を付けます。
 
-各定義は基本的に、テキストスタイル（たとえばボールド、イタリック、色などのようなもの）を、出力フォーマットへ入れこまれるそのスタイルの表記（たとえば@code{<b>$text</b>}のようなもの）と結び付けるものだ。
-その表記は@code{"}で指定され、その定義内では、伝統的なエスケープ文字の@code{\}を使って、@code{"}を使うことができる。
-ある文字に対してASCIIコードを指定したい場合には、@code{\x}を前に置いた16進表記の数値コードを記述することができる。
-例としては@ref{スタイルテンプレート}を参照してほしい。
+各定義は、基本的に、テキストスタイル（例えば、ボールド、イタリック、色などのようなもの）を、出力フォーマットへ入れ込まれるスタイルの表記（例えば、@code{<b>$text</b>}のようなもの）と結び付けるものです。
+その表記は@code{"}で指定されます。
+定義内では、伝統的なエスケープ文字の@code{\}を使って、@code{"}を使うことができます。
+ある文字に対してASCIIコードを指定したい場合には、@code{\x}を前に置いた16進表記の数値コードを記述することができます。
+例としては、別節を参照してください（@pxref{Style template}）。
 
-特定のスタイル、たとえばボールドなどに定義が与えられていない場合には、フォーマット中にそのスタイルが要求されると、そのテキストはそのままフォーマットされる。
-つまり、定義の無いスタイルは単に無視される。
+特定のスタイル、例えば、ボールドなどに定義が与えられていない場合には、フォーマット中にそのスタイルが要求されると、テキストはそのままフォーマットされます。
+つまり、定義の無いスタイルは単に無視されます。
 
-コメントは@code{#}を使って書くことができる。
-その行のそれ以降の部分はコメントとして扱われる。
+@code{#}を使ってコメントを記述できます。
+その行のそれ以降の部分はコメントとして処理されます。
 
-ファイルは言語定義の場合と同様の方法でインクルードすることができる。
-@ref{ファイルのインクルード}
+ファイルは言語定義の場合と同様の方法でインクルードすることができます。
+@xref{File inclusion}.
 
-どのような場合でも、スタイルに対する定義が複数回与えられた場合は、最後の定義が、その他の定義全てを置き換えてしまう。
+どのような場合でも、スタイルに対する定義が複数回与えられた場合は、最後の定義が、その他の定義全てを置き換えてしまいます。
 
 @menu
-* ファイルの拡張子::              Specify the output file extension
-* テキストのスタイル::                 Bold, Italics, Underline, etc.
-* 色::                      Style and definitions for colors
-* アンカーとリファレンス::      
-* ワンスタイル::                   
-* スタイルテンプレート::              
-* 行プリフィックス::                 
-* 文字列変換::          
-* ドキュメントテンプレート::           
-* HTML出力の生成::      
+* File extension::              Specify the output file extension
+* Text styles::                 Bold, Italics, Underline, etc.
+* Colors::                      Style and definitions for colors
+* Anchors and References::      
+* One style::                   
+* Style template::              
+* Line prefix::                 
+* String translation::          
+* Document template::           
+* Generating HTML output::      
 @end menu
 
-@node ファイルの拡張子, テキストのスタイル, 出力言語の定義, 出力言語の定義
+
+@node File extension, Text styles, Output Language Definitions, Output Language Definitions
 @section ファイルの拡張子
 
-次の行を見てほしい。
+次の行を見てください。
 
 @example
 extension "<file extension>"
 @end example
 
 @noindent
-この行によって、デフォルトのファイル拡張子（@code{.}無し）を定義する。
-これは、この出力フォーマットに応じてフォーマットされるファイルを生成するのに使う、
-ファイル名が指定されていないときに使われる。
-@code{.outlang}にインクルードされていないファイル拡張子が定義されていなくて（訳注：イマイチ意味不明）、出力ファイル名が指定されていない場合には、エラーが発生する。
+この行によって、デフォルトのファイル拡張子（@code{.}無し）を定義します。
+これは、出力フォーマットに応じてフォーマットされるファイルを生成する際に使用します。
+ファイル名が指定されていない時に使われます。
+@code{.outlang}にインクルードされていないファイル拡張子が定義されていなくて、出力ファイル名が指定されていない場合には、エラーが発生します。
 
-たとえば、次のものは@file{html_common.outlang}の中で使用されている。
+例えば、以下は、@file{html_common.outlang}の中で使用されています。
 
 @example
 extension "html"
 @end example
 
-@node テキストのスタイル, 色, ファイルの拡張子, 出力言語の定義
+
+@node Text styles, Colors, File extension, Output Language Definitions
 @section テキストのスタイル
 @cindex bold
 @cindex italics
@@ -2793,7 +2984,7 @@ extension "html"
 @cindex fixed
 @cindex notfixed
 
-次に挙げるものが定義可能なテキストスタイルである。
+次に挙げるものは、定義可能なテキストスタイルです。
 
 @example
 bold
@@ -2804,10 +2995,10 @@ fixed
 @end example
 
 @noindent
-もちろん、これらは、出力フォーマットのスタイルを指定するのに使われるものに対応している。
-@ref{出力フォーマットスタイル}
+もちろん、これらは、出力フォーマットのスタイルを指定するのに使われるものに対応しています。
+@xref{Output format style}.
 
-たとえば、次の定義はHTMLフォーマットの定義のものである。
+例えば、次の定義は、HTMLフォーマットの定義のものである。
 
 @example
 bold "<b>$text</b>"
@@ -2817,18 +3008,19 @@ underline "<u>$text</u>"
 
 @cindex $text
 @noindent
-定義内では、@code{$text}という特殊な変数を使って、フォーマットされる実際のテキストが挿入される場所を指定する。
-たとえば、上の@code{bold}の定義は、@code{class}というキーワードをHTMLにおいてboldでフォーマットすることが必要になった場合に、@code{<b>class</b>}というテキストが生成されるということを言っている。
-この変数は、一つ以上のスタイルを再帰的に組み合わせるときにも使われる。
-具体的に言うと、ボールドとイタリックでフォーマットしたい場合（すなわち、まずボールドそれからイタリック、言い替えると、出力フォーマットスタイルファイルの中で使われる@code{i, b}という並び。@ref{出力フォーマットスタイル}を参照してほしい）、まず@code{class}というテキストを@code{<b>$text</b>}に@code{$text}として代入し、次に、@code{<b>class</b>}というテキストを@code{<i>$text</i>}に@code{$text}として代入する。
-そうして、@code{<i><b>class</b></i>}が得られる。
+定義内では、@code{$text}という特殊な変数を使って、フォーマットされる実際のテキストが挿入される場所を指定します。
+例えば、上の@code{bold}の定義は、@code{class}というキーワードをHTMLにおいてboldでフォーマットする必要がある場合に、@code{<b>class</b>}というテキストが生成されるということを述べています。
+この変数は、一つ以上のスタイルを再帰的に組み合わせる時にも使われます。
+具体的に言うと、ボールドとイタリックでフォーマットしたい場合（すなわち、まずボールド、それから、イタリックというフォーマットをしたい場合、言い替えると、出力フォーマットスタイルファイルの中で使われる@code{i, b}という並びの場合です。@pxref{Output format style}）、まず、@code{class}というテキストを@code{<b>$text</b>}に@code{$text}として代入し、次に、@code{<b>class</b>}というテキストを@code{<i>$text</i>}に@code{$text}として代入します。
+そうして、@code{<i><b>class</b></i>}が得られます。
 
-@node  色, アンカーとリファレンス, テキストのスタイル, 出力言語の定義
+
+@node  Colors, Anchors and References, Text styles, Output Language Definitions
 @section 色
 @cindex colors
 @cindex $style
 
-フォーマッティングの際に色を使うための定義には、次の@code{color}スタイルの定義が必要である。
+フォーマッティングの際に色を使うための定義には、次の@code{color}スタイルの定義が必要です。
 
 @example
 color "..."
@@ -2836,39 +3028,39 @@ color "..."
 
 @cindex background color
 @noindent
-また、次の@code{bgcolor}スタイルの定義が必要である@footnote{バージョン2.6から}。
+また、次の@code{bgcolor}スタイルの定義が必要です@footnote{バージョン2.6からです。}。
 
 @example
 bgcolor "..."
 @end example
 
-この定義は、特定のハイライトされるエレメントの背景色だけに関わりがある。
-つまり、スタイルファイルの中で@code{bg:}というプリフィックスを付けて記述される色や（@ref{出力フォーマットスタイル}を参照）、あるいは@code{--style-css-file}へ渡されるCSSファイルで記述される@code{background-color}というプロパティである（@ref{CSSを使用した出力フォーマットスタイル}を参照）。
-なので、出力全体の背景色（すなわちスタイルファイルで@code{bgcolor}を使って記述したものや、あるいは、CSSファイルにおける@code{body}セレクタの@code{background-color}プロパティ）と混同してはいけない
-ドキュメント全体の背景色については@ref{ドキュメントテンプレート}で説明する。
+この定義は、ハイライトされる特定のエレメントの背景色だけに関わりがあります。
+つまり、スタイルファイルの中で@code{bg:}というプリフィックスを付けて記述される色や（@pxref{Output format style}）、あるいは、@code{--style-css-file}へ渡されるCSSファイルで記述される@code{background-color}というプロパティのことです（@pxref{Output format style using CSS}）。
+ですから、出力全体の背景色（すなわち、スタイルファイルで@code{bgcolor}を使って記述したものや、あるいは、CSSファイルにおける@code{body}セレクタの@code{background-color}プロパティ）と混同してはいけません。
+ドキュメント全体の背景色については別節で説明します（@pxref{Document template}）。
 
-背景色は出力フォーマットの全てで利用できるわけではないことに注意してほしい。
-たとえば、HTMLについては次のようなものがある。
+背景色は、出力フォーマットの全てで利用できるわけではないので注意してください。
+例えば、HTMLについては次のようなものがあります。
 
 @example
 color "<font color=\"$style\">$text</font>"
 @end example
 
 @noindent
-他方XHTMLでは次のようなものがある。
+他方、XHTMLでは次のようなものがあります。
 
 @example
 color "<span style=\"color: $style\">$text</span>"
 bgcolor "<span style=\"background-color: $style\">$text</span>"
 @end example
 
-既に見た@code{$text}の他に、@code{$style}という変数もある。
-これは、実際の色を置き換えるものだ。
+既に見た@code{$text}の他に、@code{$style}という変数もあります。
+これは、実際の色を置き換えるものです。
 
-source-highlightは色に関する定数を多数認識する。
-@ref{出力フォーマットスタイル}を参照してほしい。
+source-highlightは色に関する定数を多数認識します。
+@xref{Output format style}.
 
-出力フォーマットの中では、@code{colormap}の定義を使って、色の定数とその色の定義を関連付けなければならない。
+出力フォーマットの中では、@code{colormap}の定義を使って、色の定数とその色の定義を関連付けなければなりません。
 
 @example
 colormap
@@ -2879,9 +3071,9 @@ default "default color representation"
 end
 @end example
 
-@code{default}の行（@code{"}が無いことに注意）は、フォーマティングの際に色定数が使われたが、出力フォーマットには定義されていない場合に使われる色を定義するものだ。
+@code{default}の行（@code{"}が無いことに注意）は、フォーマティングの際に色定数が使われたが、出力フォーマットには定義されていない場合に使われる色を定義するものです。
 
-例として、HTMLについては次のようになっている。
+例として、HTMLについては次のようになっています。
 
 @example
 colormap
@@ -2906,33 +3098,35 @@ default "#000000"
 end
 @end example
 
-出力フォーマットが色を取り扱わないのであれば、@code{color}と@code{colormap}の定義をただ単に避ければよい。
-そうすれば、source-highlightは色をただ単に無視する。
+出力フォーマットが色を取り扱わないのであれば、単に、@code{color}と@code{colormap}の定義をせずに済ますことができます。
+そうすれば、source-highlightは色をただ単に無視します。
 
-色は、他のスタイル、たとえばボールドやイタリックなどが適用された後に適用される。
+色は、他のスタイル、例えば、ボールドやイタリックなどが適用された後に適用されます。
 
-なので、前のセクションの例を続けて、keywordに関して以下の出力スタイルを定義したとしよう。
+ですから、前のセクションの例を続けて、keywordに関して以下の出力スタイルを定義したとしましょう。
 
 @example
 keyword blue i, b;
 @end example
 
 @noindent
-そうすると、色の定義@code{<font color="$style">$text</font>}の内部で、@code{$text}変数が@code{class}というテキストに置き換わり、@code{$style}が@code{$0000FF}という値に置き換わる。
-それから、そうして得られる@code{<font color="#0000FF">class</font>}が@code{<b>$text</b>}の@code{$text}を置き換え、イタリックについてもいろいろ行われ、最終的に次のものが得られる。
+そうすると、色の定義@code{<font color="$style">$text</font>}の内部で、@code{$text}変数が@code{class}というテキストに置き換わります。
+@code{$style}は@code{$0000FF}という値に置き換わります。
+それから、そうして得られる@code{<font color="#0000FF">class</font>}は@code{<b>$text</b>}の@code{$text}を置き換え、イタリックについてもいろいろ行われ、最終的に次のものが得られます。
 
 @code{<i><b><font color="#0000FF">class</font></b></i>}
 
-@node   アンカーとリファレンス, ワンスタイル, 色, 出力言語の定義
+
+@node   Anchors and References, One style, Colors, Output Language Definitions
 @section アンカーとリファレンス
 @cindex $linenum
 
-コマンドラインオプションの@code{--line-number-ref}（@ref{source-highlightの起動}）を使うと、出力ファイルの中に、それぞれの行番号についてアンカーが生成される。
-アンカーのスタイルは、@code{anchor}の定義によって定義される。
-これが定義されていない場合には、@code{--line-number-ref}は効果を持たない。
-@code{$linenum}という変数が行番号に置き換えられ、@code{$text}変数が実際のテキストと置き換えられる。
+コマンドラインオプションの@code{--line-number-ref}（@pxref{Invoking source-highlight}）を使うと、出力ファイルの中に、それぞれの行番号についてアンカーが生成されます。
+アンカーのスタイルは、@code{anchor}の定義によって定義されます。
+これが定義されていない場合には、@code{--line-number-ref}は効果を持ちません。
+@code{$linenum}という変数が行番号に置き換えられ、@code{$text}変数が実際のテキストと置き換えられます。
 
-たとえば、HTMLでは次のようになっている。
+例えば、HTMLでは次のようになっています。
 
 @example
 anchor "<a name=\"$linenum\">$text</a>"
@@ -2941,22 +3135,23 @@ anchor "<a name=\"$linenum\">$text</a>"
 @cindex $infile
 @cindex $infilename
 @cindex $outfile
-バージョン2.2からは、source-highlightは複数のエレメント（たとえば、変数やクラス定義など）に対してリファレンスを生成できるようにもなった（@ref{リファレンスの生成}）。
-この場合にも@code{anchor}の定義が使用される。
-それに加えて、@code{reference}の定義が必要だ。
-@code{anchor}と@code{reference}の定義では、@code{$linenum}変数の他に、@code{$infile}（元の入力ファイル名）と@code{$infilename}（パス無しの元の入力ファイル名）という変数も使える。
-また、@code{reference}の定義では、@code{$outfile}（そのアンカーが存在するファイルの名前）という変数も使える。
-これら二つの変数を使ってアンカーとリファレンスを定義する方法を決めることができる。
-たとえば、HTMLについては次のようになっている。
+バージョン2.2からは、source-highlightは、複数のエレメント（例えば、変数やクラス定義など）に対してリファレンスを生成できるようにもなりました（@pxref{Generating References}）。
+この場合にも、@code{anchor}の定義が使用されます。
+それに加えて、@code{reference}の定義が必要です。
+@code{anchor}と@code{reference}の定義では、@code{$linenum}変数の他に、@code{$infile}（元の入力ファイル名）と@code{$infilename}（パス無しの元の入力ファイル名）という変数も使えます。
+また、@code{reference}の定義では、@code{$outfile}（そのアンカーが存在するファイルの名前）という変数も使えます。
+これら二つの変数を使って、アンカーとリファレンスを定義する方法を決めることができます。
+例えば、HTMLについては次のようになっています。
 
 @example
 reference "<a href=\"$outfile#$linenum\">$text</a>"
 @end example
 
 @noindent
-この場合、別の出力ファイル（あるいは同じ出力ファイルかもしれない）へのリンクを生成するので@code{$outfile}を使っていることに注意してほしい。
+この場合、別の出力ファイル（あるいは、同じ出力ファイルかもしれない）へのリンクを生成しますので、@code{$outfile}を使っていることに注意してください。
 
-一方、@LaTeX{}の場合では、「クリッカブル」なリファレンスを生成しないので、元の入力ファイル名を参照している（@code{anchor}と@code{reference}の定義でともに、@code{$infilename}と@code{$linenum}の両方を使用している）。
+一方、@LaTeX{}の場合では「クリッカブル」なリファレンスを生成しません。
+そのため、元の入力ファイル名を参照しています（@code{anchor}と@code{reference}の定義で、ともに、@code{$infilename}と@code{$linenum}の両方を使用しています）。
 
 @example
 anchor "\label@{$infilename:$linenum@}$text"
@@ -2965,13 +3160,14 @@ reference "@{\hfill $text $\rightarrow$ $infile:$linenum, \
 @end example
 
 @noindent
-とくに、@code{\label}を生成するのに@code{$infile}ではなく、@code{$infilename}を使っている。
-これは、パスのシンボルが@LaTeX{}の「邪魔をする」からだ（その一方で、リファレンスのテキスト情報ではファイルの完全なパスを使用している）。
+特に、@code{\label}を生成するのに、@code{$infile}ではなく、@code{$infilename}を使っています。
+これは、パスのシンボルが、@LaTeX{}の「邪魔をする」からです（その一方で、リファレンスのテキスト情報ではファイルの完全なパスを使用しています）。
 
-これによって正しく割り当てられたリファレンスを生成する。
-@LaTeX{}でリファレンスを生成するときには、インラインリファレンスの生成は無意味なので（少なくとも格好いいものを生成する方法を私は知らない :-)）、@code{--gen-references=postline}ではなく、@code{--gen-references=postline}か、あるいは@code{--gen-references=postdoc}を使うことを想定していることに留意してほしい。
+これによって、正しく割り当てられたリファレンスを生成します。
+@LaTeX{}でリファレンスを生成する時には、インラインリファレンスの生成は無意味ですので@footnote{少なくとも、格好いいものを生成する方法を私は知りません。 :-)}、@code{--gen-references=postline}ではなく、@code{--gen-references=postline}か、あるいは、@code{--gen-references=postdoc}を使うことを想定していることに留意してください。
+@xref{Generating References}.
 
-さらに、Texinfoについては次のようになる。
+さらに、Texinfoについては次のようになります。
 
 @example
 anchor "@@anchor@{$infilename:$linenum@}$text"
@@ -2981,20 +3177,20 @@ reference "@@flushright
 @end example
 
 @noindent
-@code{anchor}の定義中で、@code{$infilename}と、そして@code{$linenum}も使うことで、なんとかしてアンカーが重複しないようにしている。
-これは@LaTeX{}やTexinfoに対して行なわれることで、HTMLに対しては行なわれない。
-というのは、このマニュアルで行なわれているように、生成される@file{.tex}と@file{.texinfo}ファイルがマスターファイルに直接インクルードされることが想定されているからだ（一方HTMLでは、各ソース毎に別々のHTMLファイルが生成され、分割されたまなになることが想定されている）。
-これがそぐわない場合には、@code{anchor}と@code{reference}の定義を、ピッタリ合うように変更して構わない。
-Texinfoにおけるリファレンスの付いた出力例は@ref{例}に示されている。
+@code{anchor}の定義中で、@code{$infilename}と、そして、@code{$linenum}も使うことで、なんとかしてアンカーが重複しないようにしています。
+これは、@LaTeX{}やTexinfoに対して行なわれることで、HTMLに対しては行なわれません。
+というのは、このマニュアルで行なわれているように、生成される@file{.tex}と@file{.texinfo}ファイルがマスターファイルに直接インクルードされることが想定されているからです（一方、HTMLでは、別々のHTMLファイルが各ソースごとに生成され、分割されたまなになることが想定されています）。
+これがそぐわない場合には、@code{anchor}と@code{reference}の定義を、ピッタリ合うように変更して構いません。
+Texinfoにおけるリファレンスの付いた出力例は別の節に示します（@pxref{Examples}）。
 
 @cindex inline_reference
 @cindex postline_reference
 @cindex postdoc_reference
-実は、@code{--gen-references}コマンドラインオプションに渡せる三つの引数に対応する@code{reference}に関する定義をさらに三つ使うことができる。
-@code{inline_reference}と@code{postline_reference}、そして@code{postdoc_reference}である。
-この一つが定義されていなければ、@code{reference}の定義と同じものが使われる。
-違う定義を記述できるというのは、たとえば、HTMLの場合に便利である。
-postlineリファレンスやpostdocリファレンスも使われるとき、インラインリファレンスについて同じスタイルであるのはかなり不恰好なことである。
+実は、@code{--gen-references}コマンドラインオプション（@pxref{Generating References}）に渡すことのできる三つの引数に対応する@code{reference}に関する定義をさらに三つ使うことができます。
+@code{inline_reference}、@code{postline_reference}、@code{postdoc_reference}の三つです。
+定義されていないものがあれば、@code{reference}の定義と同じものが使われます。
+違う定義を記述できるのは、例えば、HTMLの場合に便利です。
+postlineリファレンスやpostdocリファレンスも使われる場合、インラインリファレンスについて同じスタイルだと、かなり不恰好です。
 
 @smallexample
 postline_reference "<a href=\"$outfile#$linenum\">$text -> $infile:$linenum</a>"
@@ -3002,50 +3198,51 @@ postdoc_reference "<a href=\"$outfile#$linenum\">$text -> $infile:$linenum</a>"
 reference "<a href=\"$outfile#$linenum\">$text</a>"
 @end smallexample
 
-@node ワンスタイル, スタイルテンプレート, アンカーとリファレンス, 出力言語の定義
+
+@node One style, Style template, Anchors and References, Output Language Definitions
 @section ワンスタイル
 @cindex one style
 
-あなたが定義している出力フォーマットがボールドやイタリック、そして色などに特定のスタイルを持たない場合には、単に@code{onestyle}という定義を使うことができる。
-この定義では、@code{$style}と@code{$text}を両方使うことができる。
-また、どのようなスタイルに対しても使える（実際、ボールド、イタリック、色のなどのような他のあらゆる定義は無視される）。
-実は、この場合、それぞれのソースエレメントのスタイルは、その独自のシンタックスを使ってファイル内に定義される。
-すなわち、source-highlightが定義するシンタックスではない。
-（たとえば、CSSスタイルシートを使うHTMLがその例である。）
-さらに、出力フォーマットスタイルが使われないので、フォーマッティングの際、@code{$style}変数は、ハイライトするエレメントの名前に置き換えられる（たとえば、@code{keyword}、@code{comment}など）。
+定義している出力フォーマットがボールド、イタリック、そして、色などについて特定のスタイルを持たない場合には、単に@code{onestyle}という定義を使うことができます。
+この定義では、@code{$style}と@code{$text}を両方使うことができます。
+また、どのようなスタイルに対しても使えます（実際、ボールド、イタリック、色のなどのような他のあらゆる定義は無視されます）。
+実は、この場合、それぞれのソースエレメントのスタイルは、独自のシンタックスを使ってファイル内に定義されます。
+すなわち、source-highlightが定義するシンタックスではありません（例えば、CSSスタイルシートを使うHTMLがその例です）。
+さらに、出力フォーマットスタイルが使われませんので、フォーマッティングの際、@code{$style}変数は、ハイライトするエレメントの名前に置き換えられます（例えば、@code{keyword}、@code{comment}など）。
 
-たとえば、HTML CSSでは単純に次のようになる。
+例えば、HTML CSSでは単純に次のようになります。
 
 @example
 onestyle "<span class=\"$style\">$text</span>"
 @end example
 
 @noindent
-事実、HTML CSSは、別のファイル（要するに@file{.css}ファイル）で用意されるスタイル定義に依存する。
-なので、@code{keyword}の、たとえば@code{abstract}をフォーマットする場合には、次のようになる。
+実際、HTML CSSは、別のファイル（要するに@file{.css}ファイル）で用意されるスタイル定義に依存します。
+ですから、@code{keyword}、例えば、@code{abstract}をフォーマットする場合には、次のようになります。
 
 @example
 <span class="keyword">abstract</span>
 @end example
 
 @noindent
-もちろん、@code{keyword}に対するスタイルが@file{.css}ファイルで定義されていなくはならない。
+もちろん、@code{keyword}に対するスタイルが@file{.css}ファイルで定義されていなくはなりません。
+
 
-@node スタイルテンプレート, 行プリフィックス, ワンスタイル, 出力言語の定義
+@node Style template, Line prefix, One style, Output Language Definitions
 @section スタイルテンプレート
 @cindex style template
 @cindex style separator
 
-出力フォーマットによっては、独自のテンプレートに基づくものもある。
-そのテンプレートで他のスタイルが組み立てられる。
-組み立ての際、スタイルは指定のセパレータでセパレートされる。
+出力フォーマットによっては、独自のテンプレートに基づくものもあります。
+そのテンプレートで他のスタイルが組み立てられます。
+組み立ての際、スタイルは、指定のセパレータでセパレートされます。
 
 @example
 styletemplate "..."
 styleseparator "..."
 @end example
 
-たとえば、これは、ANSIカラーエスケープシーケンスの出力フォーマット（@file{esc.outlang}）で使われる。
+例えば、以下は、ANSIカラーエスケープシーケンスの出力フォーマット（@file{esc.outlang}）で使われるものです。
 
 @example
 styletemplate "\x1b[$stylem$text\x1b[m"
@@ -3058,31 +3255,36 @@ color "$style"
 @end example
 
 @noindent
-複数のスタイルをスタイルテンプレートに混ぜて入れてもよいので、@code{bold}、@code{underline}、…は@code{$style}変数を明示的に使用している。
+複数のスタイルをスタイルテンプレートに混ぜて入れてもよいので、@code{bold}、@code{underline}、@dots{}は@code{$style}変数を明示的に使用しています。
 
-@node 行プリフィックス, 文字列変換, スタイルテンプレート, 出力言語の定義
+
+@node Line prefix, String translation, Style template, Output Language Definitions
 @section 行プリフィックス
 
-この機能を使えば、入力行に対応して生成される各行のプリフィックスとして文字列を生成することができる（つまり、このプリフィックスは生成された他の出力エレメント、たとえば、ヘッダやフッタなどの行に対して生成されるものではない）。
+この機能を使えば、入力行に対応して生成される各行のプリフィックスとして文字列を生成することができます（つまり、このプリフィックスは生成された他の出力エレメント、例えば、ヘッダやフッタなどの行に対して生成されるものではありません）。
 
-この機能は@LaTeX{}出力で使っている（@ref{LaTeXの出力}）。
+この機能は@LaTeX{}出力で使っています。
+@xref{LaTeX output}.
 
 @example
 lineprefix "\mbox@{@}"
 @end example
 
 @noindent
-このようにすれば、@LaTeX{}出力の行はそれぞれ、@code{\mbox@{@}}がプリフィックスとして付けられる@footnote{これは、tabular環境を使わずに行頭にスペースを挿入するトリックの一つだ。@code{\mbox@{@}}が前に無いと、スペースが無視されてしまう。これを実現するのに私が知っている唯一の方法だが、他に方法があるならお前ら教えてください}。
+このようにすれば、@LaTeX{}出力の行は、@code{\mbox@{@}}がプリフィックスとしてそれぞれ付けられます@footnote{これは、tabular環境を使わずに行頭にスペースを挿入するトリックの一つです。
+@code{\mbox@{@}}が前に無いと、スペースが無視されてしまいます。
+これを実現するのに私が知っている唯一の方法ですが、他に方法があるならお前ら教えてください}。
+
+もう一つ興味深い例として、@code{lineprefix}を使うjavadocの出力があります。
+@xref{Generating HTML output}.
 
-@code{lineprefix}を使う別の興味深い例がjavadocの出力である。
-@ref{HTML出力の生成}を見てほしい。
 
-@node 文字列変換, ドキュメントテンプレート, 行プリフィックス, 出力言語の定義
+@node String translation, Document template, Line prefix, Output Language Definitions
 @section 文字列変換
 
-ソースファイルにある文字の並びが出力フォーマットでは特別な意味を持つことがある。
-なので、そういったものは前処理が必要となる（たとえば、エスケープする）。
-その変換テーブルを次のように記述することができる。
+ソースファイルにある文字の並びが出力フォーマットでは特別な意味を持つことがあります。
+ですから、そういったものは前処理が必要となります（例えば、エスケープします）。
+変換テーブルは、次のように記述できます。
 
 @example
 translations
@@ -3093,10 +3295,12 @@ end
 @end example
 
 @noindent
-@code{"original sequence"}と@code{'regex'}の違いは、前者が、@code{\}（挿入する必要がある場合にはエスケープされていなければならない）や、@code{\n}（改行）、@code{\t}（タブ文字）のような特殊な文字は別にして、字面そのままにマッチする文字の並び記述するものである。
-それに対し、後者を使えば、正規表現を記述することができる（これは、言語定義における@code{"}と@code{'}の違いと基本的に同じである）。
+@code{"original sequence"}と@code{'regex'}の違いは、前者が、@code{\}（挿入する必要がある場合にはエスケープされていなければならない）や、@code{\n}（改行）、@code{\t}（タブ文字）のような特殊な文字は別にして、字面そのままにマッチする文字の並び記述するものです。
+それに対し、後者を使えば、正規表現を記述することができます。
+これは、言語定義における@code{"}と@code{'}の違いと基本的に同じです。
+@xref{Simple definitions}.
 
-たとえば、HTMLについて言うと、次のような変換テーブルがある。
+例えば、HTMLについて言うと、次のような変換テーブルがあります。
 
 @example
 translations
@@ -3106,9 +3310,9 @@ translations
 end
 @end example
 
-@LaTeX{}の場合だと変換テーブルは少しだけ大きい。
-ここでは少しだけ示す。
-これは、特殊文字をエスケープする方法（たとえば@code{\}など）、改行やタブ文字を変換する方法を示している。
+@LaTeX{}の場合だと変換テーブルは少しだけ大きくなります。
+ここでは少しだけ示します。
+これは、特殊文字をエスケープする方法（例えば、@code{\}など）、改行やタブ文字を変換する方法を示しています。
 
 @example
 translations
@@ -3123,12 +3327,15 @@ end
 @end example
 
 @noindent
-注意してほしいのだが、改行（訳注：「new character」となっているが「new line character」の間違いかな？）は、@LaTeX{}では@code{\\}に変換されなければならないので、二つの@code{\}をエスケープしなければならない（すなわち、@code{\\\\}）。
-そしてその時、出力ファイルに改行@code{\n}を実際に挿入したい。
+注意してほしいのですが、改行@footnote{訳注：「new character」となっていますが,「new line character」の間違いか。}は、@LaTeX{}では@code{\\}に変換する必要がありますので、二つの@code{\}をエスケープしなければなりません（すなわち、@code{\\\\}）。
+そして、その時、出力ファイルに改行@code{\n}を実際に挿入したいのです。
+
+For HTML with not fixed font by default, @file{html_notfixed.outlang},
+we need two translate two space sequence, and we also need to translate a space starting a new line in the source; thus we have:
 
-デフォルトでは等幅フォントではないHTML、@file{html_notfixed.outlang}については、二つの空白の並び（つまり、隣合った空白。HTMLでは連続する空白が一つの空白だけとしてレンダリングされる@footnote{@code{<tt>...</tt>}の内部に無い限り}のに反して、それらの空白をそのままにしておきたい）を変換する必要がある。
-そして、ソース中における、改行に続く空白も変換する必要がある（なので、@code{'}で括った正規表現@code{^ }を使っている）。
-したがって、次のようになる。
+デフォルトでは等幅フォントではないHTMLに対する@file{html_notfixed.outlang}（@pxref{HTML and XHTML output}）ですが、二つの空白の並び（つまり、隣り合った空白のことですが、それらの空白をそのままにしておきたい一方で、HTMLでは、連続する空白は一つの空白としてレンダリングされてしまいます@footnote{@code{<tt>...</tt>}の中で無ければです。}ので、この空白）を変換する必要があります。
+そして、ソース中における、改行に続く空白も変換する必要があります（ですから、@code{'}で括った正規表現@code{^ }を使います）。
+従って、次のようになります。
 
 @example
 translations
@@ -3139,10 +3346,11 @@ translations
 end
 @end example
 
-@node ドキュメントテンプレート, HTML出力の生成, 文字列変換, 出力言語の定義
+
+@node Document template, Generating HTML output, String translation, Output Language Definitions
 @section ドキュメントテンプレート
 
-出力ファイルの始めと終わりを次のように定義することができる。
+出力ファイルの始めと終わりは次のように定義できます。
 
 @cindex doctemplate
 @example
@@ -3160,10 +3368,12 @@ nodoctemplate
 end
 @end example
 
-最初のものは、@code{--doc}というコマンドラインオプションが指定される時に使われる。
-一方、2番目のものは、その他のケースで使われる@footnote{バージョン2.9までは@code{doctemplate}だけだった。そして@code{--doc}については、@code{.outlang}ファイルが別にあった。私は現在のソリューションのほうが良くて、ファイルの数も減らせると考えている}。
+最初のものは、コマンドラインオプション@code{--doc}が指定される時に使われます。
+他方、2番目のものは、その他のケースで使われます@footnote{バージョン2.9までは@code{doctemplate}だけでした。
+そして、@code{--doc}については、@code{.outlang}ファイルが別にありました。
+私は、現在のソリューションのほうが良くて、ファイルの数も減らせると考えています。}。
 
-例として、HTMLでは次のようになる。
+例として、HTMLでは次のようになります。
 
 @example
 nodoctemplate
@@ -3175,27 +3385,34 @@ end
 @end example
 
 @noindent
-終わりに対する部分には明示的な改行があることに注意してほしい。
+終わりの部分に明示的な改行があることに注意してください。
 
-@code{doctemplate}と@code{nodoctemplate}の定義では、次の変数が使用でき、出力が生成される際に置き換えられる。
+@code{doctemplate}と@code{nodoctemplate}の定義では、次の変数が使用できます。
+出力が生成される際に置き換えられます。
 
 @table @code
 @item $title
-出力ファイルのタイトルの値（たとえば、@code{--title}というコマンドラインオプションで渡されたもの）
+出力ファイルのタイトルの値（例えば、@code{--title}というコマンドラインオプションで渡されたもの）です。
+
 @item $header
-コマンドラインオプション@code{--header}で指定されたファイルの内容
+コマンドラインオプション@code{--header}で指定されたファイルの内容です。
+
 @item $footer
-コマンドラインオプション@code{--footer}で指定されたファイルの内容
+コマンドラインオプション@code{--footer}で指定されたファイルの内容です。
+
 @item $css
-コマンドラインオプション@code{--css}で渡された値
+コマンドラインオプション@code{--css}で渡された値です。
+
 @item $additional
-その他の追加的な情報。source-highlightはこれをその名前とそのバージョンで置き換える。
+その他の追加的な情報です。
+source-highlightは、名前とバージョンでこれを置き換えます。
+
 @item $docbgcolor@footnote{バージョン2.6から}
-出力ドキュメントの背景色。
-source-highlightはこれを、@file{.style}ファイルの@code{bgcolor}で記述されている値（@ref{出力フォーマットスタイル}を見よ）か、あるいは、@code{--style-css-file}で渡されるCSSファイルの@code{body}セレクタで記述されている値（@ref{CSSを使用した出力フォーマットスタイル}）に置き換える。
+出力ドキュメントの背景色です。
+source-highlightは、これを、@file{.style}ファイルの@code{bgcolor}で記述された値（@pxref{Output format style}）か、あるいは、@code{--style-css-file}で渡されるCSSファイルの@code{body}セレクタで記述された値（@pxref{Output format style using CSS}）に置き換えます。
 @end table
 
-例えば、cssを使ったHTMLドキュメント（@file{htmlcss.outlang}ファイル）の場合は次のようになる。
+例えば、cssを使ったHTMLドキュメント（@file{htmlcss.outlang}ファイル）の場合は、次のようになります。
 
 @example
 doctemplate
@@ -3218,7 +3435,8 @@ $footer</body>
 end
 @end example
 
-ヘッダとフッタの付いたHTMLドキュメント（@file{html.outlnag}）の場合は次のようになる（@code{$docbgcolor}の使用に注意）。
+ヘッダとフッタの付いたHTMLドキュメント（@file{html.outlnag}）の場合は次のようになります。
+@code{$docbgcolor}の使用に注意してください。
 
 @example
 doctemplate
@@ -3238,7 +3456,7 @@ $footer</body>
 end
 @end example
 
-そしてHTMLテーブルの出力に対するものである（@file{htmltable.outlang}ファイル）。
+そして、HTMLテーブルの出力に対するものです（@file{htmltable.outlang}ファイル）。
 
 @example
 doctemplate
@@ -3254,22 +3472,23 @@ doctemplate
 end
 @end example 
 
-@node HTML出力の生成,  , ドキュメントテンプレート, 出力言語の定義
+
+@node Generating HTML output,  , Document template, Output Language Definitions
 @section HTML出力の生成
 
-完全な例として、@file{html_common.outlang}というファイルを示す。
-これには、様々なHTML出力フォーマット（@file{html.outlang}、@file{htmltable.outlang}など）についての共通の定義が含まれている。
+完全な例として、@file{html_common.outlang}というファイルを示します。
+これには、様々なHTML出力フォーマット（@file{html.outlang}、@file{htmltable.outlang}など）に対する共通定義が含まれています。
 
 @include html_common.outlang.texinfo
 
-さらに、このファイルは、javadocの出力を生成するのにも使われる。
+さらに、このファイルは、javadocの出力を生成するのにも使われます。
 
 @include javadoc.outlang.texinfo
 
-javadocの出力フォーマットは、コード片を、別のJavaファイルのjavadocコメントの内部に含めなければならないときに役立つ@footnote{テストしていないのだけれども、Doxygenのコメントでもうまく働くと思う}。
-生成されるHTMLドキュメンテーションにおいてナイスにフォーマットされることとは別に、コード片に含まれる特殊文字（すなわち、@code{&}と@code{<}、@code{>}）をエスケープする作業からプログラマを解放してくれる。
-また、@code{*/}という文字並びも、（javadocの）コメントの終了として解釈される。@code{*/}という文字並びも回避することに注意してほしい。
-たとえば、次のコードを書いたとする。
+javadocの出力フォーマットは、コード片を、別のJavaファイルのjavadocコメントの内部に含めなければならない時に有用です@footnote{テストしてませんが、Doxygenのコメントでもうまく働くと思います。}。
+生成されるHTMLドキュメントにおいてナイスにフォーマットされることとは別に、コード片に含まれる特殊文字（すなわち、@code{&}、@code{<}、@code{>}）をエスケープする作業からプログラマを解放します。
+また、@code{*/}という文字並びも、（javadocの）コメントの終了として解釈されないように、回避しますので注意してください。
+例えば、次のコードを書いたとします。
 
 @example
 /**
@@ -3282,125 +3501,138 @@ javadocの出力フォーマットは、コード片を、別のJavaファイル
 @end example
 
 @noindent
-結果のJavaコードはシンタックスエラーを含んでいる。
-source-highlightを使って、javadocコメントに挿入するコードをフォーマットするならば、これらの問題は回避されるだろう。
+結果のJavaコードはシンタックスエラーがあります。
+source-highlightを使って、javadocコメントに挿入するコードをフォーマットするならば、これらの問題は回避されるでしょう。
+
+source-highlightによってフォーマットされたコード片を含む、javadocが生成したHTMLページの例は、ドキュメントディレクトリの@file{SimpleClass-doc.html}というファイルで見つけられます。
 
-source-highlightによってフォーマットされたコード片を含む、javadocが生成したHTMLページの例はドキュメンテーションディレクトリの@file{SimpleClass-doc.html}というファイルで見つけられる。
 
-@node リファレンスの生成, 例, 出力言語の定義, Top
+@node Generating References, Examples, Output Language Definitions, Top
 @chapter リファレンスの生成
 @cindex reference
 @cindex anchor
 @cindex ctags
 
-バージョン2.2から、source-highlightはフィールドや変数などに対するリファレンスも生成する。
-これを行なうために、@emph{Exuberant Ctags}というプログラムに依存している。
-このプログラムはDarren Hiebertによるもので、@url{http://ctags.sourceforge.net}から入手可能だ。
-ゆえに、source-highlightでこの機能を使う場合には、そのプログラムをインストールしなければならない。
+バージョン2.2から、source-highlightは、フィールドや変数などに対するリファレンスも生成します。
+これを行なうために、@emph{Exuberant Ctags}というプログラムに依存しています。
+このプログラムはDarren Hiebertによるもので、@url{http://ctags.sourceforge.net}から入手可能です。
+ゆえに、source-highlightでこの機能を使う場合には、このプログラムをインストールしなければなりません。
 
-@code{ctags}プログラムは、ファイル中に見つかる言語の様々なオブジェクトについて、インデックスファイル（あるいは「タグ」ファイル）を生成する。
-こうすることで、テキストエディタやその他のユーティリティ（ここでのsource-highlightのようなもの）によって、それらのアイテムの位置を素早く簡単に特定できるようになる。
-「タグ」は、インデックスエントリが利用可能な言語のオブジェクト（あるいは、そのオブジェクトに対して生成されたインデックスエントリ）を表わすものである@footnote{この説明はctagsのmanページから持って来たものだ}。
+@code{ctags}プログラムは、ファイル中に見つかる言語の様々なオブジェクトについてインデックスファイル（あるいは、「タグ」ファイル）を生成します。
+こうすることで、テキストエディタやその他のユーティリティ（ここでのsource-highlightのようなもの）によって、それらのアイテムの位置を素早く簡単に特定できるようになります。
+「タグ」は、インデックスエントリが利用可能な言語のオブジェクト（あるいは、そのオブジェクトに対して生成されたインデックスエントリ）を表わすものです@footnote{この説明はctagsのmanページから持って来たものです}。
 
-これは、@code{ctags}が特定のソース言語を処理できる場合にだけ、source-highlightがその言語のリファレンスを生成できることを意味している。
-ファイルの拡張子とサポートされている言語の関連を知るには、@code{ctags}のコマンドラインオプション@code{--list-maps}と@code{--list-languages}を参照する。
+これは、特定のソース言語を@code{ctags}が処理できる場合にだけ、source-highlightが、その言語のリファレンスを生成できることを意味しています。
+ファイルの拡張子とサポート言語の関連を知るには、@code{ctags}のコマンドラインオプション@code{--list-maps}と@code{--list-languages}を参照します。
 
-リファレンスの生成は、コマンドラインオプションの@code{--gen-references}を使って有効にする（@ref{source-highlightの起動}）。
-このオプションは、リファレンスの生成方法を決める引数を一つ取る。
+リファレンスの生成は、コマンドラインオプションの@code{--gen-references}を使って有効にします（@pxref{Invoking source-highlight}）。
+このオプションは、リファレンスの生成方法を決める以下のような引数を一つ取ります。
 
 @table @code
 @item inline
-リファレンスポインタをそのエレメントとちょうど同じ場所に生成する。
-これは、HTMLのようにもともとリンクをサポートしているような出力フォーマットで役に立つ。
-一方、@LaTeX{}のようなインラインリンクをサポートしない出力フォーマットでは役に立たない。
+リファレンスポインタを、そのエレメントとちょうど同じ場所に生成します。
+これは、HTMLのようにもともとリンクをサポートしているような出力フォーマットで役に立ちます。
+一方、@LaTeX{}のようなインラインリンクをサポートしない出力フォーマットでは役に立ちません。
+
 @item postline
-入力ソースのある行が、リファレンスのあるエレメントを含む場合、リファレンスのリストがその行の直後に生成される（@ref{例}を参照してほしい）。
+入力ソースのある行が、リファレンスのあるエレメントを含む場合、リファレンスのリストがその行の直後に生成されます。
+@xref{Examples}.
+
 @item postdoc
-入力ファイル全体が生成された後、リファレンスが全て生成される。
+入力ファイル全体が生成された後、リファレンスが全て生成されます。
 @end table
 
-例外がある。
-エレメントが複数のリファレンスを持つとき（変数が複数のソースで定義されたり、メソッドがオーバーロードされたり）、@code{inline}が指定されていれば、その発生についてリファレンスの生成が@code{postline}に切り替わる。
+例外があります。
+（変数が複数のソースで定義されたり、メソッドがオーバーロードされたりするため）エレメントが複数のリファレンスを持つ場合、@code{inline}が指定されていれば、その箇所について、リファレンスの生成が@code{postline}に切り替わります。
 
-@code{--gen-references}が指定されている場合、source-highlightはまず@code{ctags}を実行する。
-ユーザ（訳注：useになってるけどuserと解釈）は、この呼び出しを@code{--ctags}というコマンドラインオプションでカスタマイズすることができる（@ref{source-highlightの起動}）。
-とくに、source-highlightによって@code{ctags}を実行したくない場合（たとえば、タグファイルが既に生成されているためだったり）、@code{--ctags}には空文字列@code{""}を渡さなければならない。
-こういう場合や、あるいは、@code{ctags}のコマンドラインで指定することによって別の出力タグファイルが生成されるようなときは、@code{--ctags-file}コマンドラインオプションを使って正確なタグファイルを指定しなければならない。
+@code{--gen-references}が指定されている場合、source-highlightは、まず@code{ctags}を実行します。
+ユーザ@footnote{訳注：useになってますが、userと解釈しました。}は、この呼び出しを@code{--ctags}というコマンドラインオプションでカスタマイズできます（@pxref{Invoking source-highlight}）。
+特に、（例えば、タグファイルが既に生成されているため、）source-highlightによって@code{ctags}を実行したくない場合、@code{--ctags}には空文字列@code{""}を渡さなければなりません。
+こういう場合や、あるいは、@code{ctags}のコマンドラインで指定することによって別の出力タグファイルが生成されるような時は、@code{--ctags-file}コマンドラインオプションを使って正確なタグファイルを指定しなければなりません。
 
-一度タグファイルが生成されると、source-highlightは、@code{ctags}配布物に用意されていて、source-highlightのソースに含まれている@file{readtags}ライブラリに頼ることになる。
+タグファイルが一度生成されると、source-highlightは、@code{ctags}配布物に用意されていて、また、source-highlightのソースに含まれる@file{readtags}ライブラリを当てにします。
 
-プログラムエレメントが、@code{noref}というオプションを持つスタイルに応じてフォーマットされる場合（@ref{出力フォーマットスタイル}を参照）、このエレメントはタグとは見做されず、リファレンスは生成されない。
-たとえば、@code{comment}エレメント、すなわち、@code{comment}スタイルで生成される各文字列については、@code{noref}オプションで宣言されるので、タグとは見做されない（@ref{例}を参照）。
+プログラムエレメントが、@code{noref}というオプションを持つスタイルに応じてフォーマットされる場合（@pxref{Output format style}）、このエレメントはタグとは見做されず、リファレンスは生成されません。
+例えば、@code{comment}エレメント、すなわち、@code{comment}スタイルで生成される各文字列については、@code{noref}オプションで宣言されますので、タグとは見做されません。
+@xref{Examples}.
 
-@node  例, バグ報告, リファレンスの生成, Top
+
+@node  Examples, Problems, Generating References, Top
 @chapter 例
 
-ここでは、@code{-f texinfo}というコマンドラインオプションを付けてsource-highlightでフォーマットされたソースの例をいくつか示す。
-Infoファイルではハイライティングは見えないが、印刷されたマニュアルやHTML出力でだけは見えるということを覚えていてほしい（えーと、少なくとも行番号はどこでも見える:-)）。
+ここでは、@code{-f texinfo}というコマンドラインオプションを付けてsource-highlightでフォーマットされたソースの例をいくつか示します。
+Infoファイルではハイライティングは見えません。
+印刷マニュアルやHTML出力でだけ見えるということを覚えていてください（えーと、少なくとも行番号はどこでも見えます:-)）。
 
 @menu
-* 簡単な例::              
-* リファレンス::                  
-* 行による範囲指定::                 
-* 行による範囲指定（コンテキスト付き）::  
-* 正規表現による範囲指定::                
+* Simple example::              
+* References::                  
+* Line ranges::                 
+* Line ranges (with context)::  
+* Regex ranges::                
 @end menu
 
-@node 簡単な例, リファレンス, 例, 例
+
+@node Simple example, References, Examples, Examples
 @section 簡単な例
 
-最初の例は、次のコマンドを使って生成されたものだ。
+最初の例は、次のコマンドを使って生成されたものです。
 
 @example
 source-highlight -f texinfo -i test.java -o test.java.texinfo -n
 @end example
 
-そして、これが結果。
+そして、これが結果です。
 
 @include test.java.texinfo
 
-@node リファレンス, 行による範囲指定, 簡単な例, 例
+
+@node References, Line ranges, Simple example, Examples
 @section リファレンス
 
-この例は、@code{--gen-references}機能の利用について示すものだ。
-具体的には、次のコマンドで以下のような出力が生成される。
+この例は、@code{--gen-references}機能の使い方を示すものです。
+具体的には、次のコマンドで以下のような出力が生成されます。
 
 @example
 source-highlight -f texinfo -i test.h -o test_ref.h.texinfo -n \
      --gen-references=postline
 @end example
 
-そしてこれが結果である（@code{mysum}という文字列を含むコメント行がどんな風にリファレンスを含まないのかに注意してほしい。それが@code{comment}エレメントであって、そしてこのエレメントが@file{texinfo.style}の中で@code{noref}オプションを持っているからである。
-@ref{出力フォーマットスタイル}を参照せよ。
-同じことが、最後のコメント行の@code{_TEXTGEN_H}というコメントにも当てはまる）。
+そして、以下が結果です。
+@code{mysum}という文字列を含むコメント行がどのようににリファレンスを含まないのかに注意してください。
+それが、@code{comment}エレメントであって、そして、このエレメントが@file{texinfo.style}の中で@code{noref}オプションを持っているからです。
+@xref{Output format style}.
+同じことが、最後のコメント行の@code{_TEXTGEN_H}というコメントにも当て嵌ります。
 
 @include test_ref.h.texinfo
 
-@node 行による範囲指定, 行による範囲指定（コンテキスト付き）, リファレンス, 例
+
+@node Line ranges, Line ranges (with context), References, Examples
 @section 行による範囲指定
 
 @cindex line ranges
-これは、@xref{簡単な例}にある入力ファイルについて、@code{--line-range}というコマンドラインオプションを使った例である。
+これは、別の節（@pxref{Simple example}）にある入力ファイルについて、コマンドラインオプション@code{--line-range}を使った例です。
 
 @example
 source-highlight -f texinfo -i test.java -n \
      --line-range="12-18","29-34"
 @end example
 
-これによって以下の出力が生成される。
+これによって以下の出力が生成されます。
 
 @include test_lineranges1.java.texinfo
 
-指定された行の範囲は、コメント環境まで及んでいるが、ハイライティングは配慮されている。
-コメントの開始は表示されていないが、コメントの残りの部分は正しくコメントとしてハイライトされている。
+指定された行の範囲はコメント環境まで及んでいますが、ハイライティングは配慮されています。
+コメントの開始は表示されていませんが、コメントの残りの部分は正しくコメントとしてハイライトされています。
+
 
-@node 行による範囲指定（コンテキスト付き）, 正規表現による範囲指定, 行による範囲指定, 例
+@node Line ranges (with context), Regex ranges, Line ranges, Examples
 @section 行による範囲指定（コンテキスト付き）
 
 @cindex line ranges
 @cindex range context
 @cindex range separator
-これは、@code{--line-range}オプションと一緒に@code{--range-context}と@code{--range-separator}を使った例である。
+これは、@code{--line-range}オプションと一緒に@code{--range-context}と@code{--range-separator}を使った例です。
 
 @example
 source-highlight -f texinfo -i test.java -n \
@@ -3409,49 +3641,52 @@ source-highlight -f texinfo -i test.java -n \
      --range-separator="@{... not in range ...@}"
 @end example
 
-これによって以下の出力が得られる。
+これによって以下の出力が得られます。
 
 @include test_lineranges2.java.texinfo
 
-指定範囲の前後に余分な2行が追加されていることに注意してほしい（@ref{行による範囲指定}にある出力と比較せよ）。
-また、コンテキストとして示されている行（のエレメント）はハイライトされていないことにも注意せよ。
-さらに、指定範囲と指定範囲の間に、@code{"@{... not in range ...@}"}という範囲を区切る行が出力されている（セパレータの文字列は自動的に実行されるので、たとえば、texinfo出力における@{ @}のような特殊な出力文字をエスケープする必要ない）。
+指定範囲の前後に余分な2行が追加されているので注意が必要です。
+別節にある出力と比較してください（@pxref{Line ranges}）。
+また、コンテキストとして示されている行（のエレメント）はハイライトされていないことにも注意してください。
+さらに、指定範囲と指定範囲の間に、@code{"@{... not in range ...@}"}という範囲を区切る行が出力されています。
+セパレータの文字列は自動的に実行されますので、例えば、texinfo出力における@{ @}のような特殊な出力文字をエスケープする必要ありません。
+
 
-@node 正規表現による範囲指定,  , 行による範囲指定（コンテキスト付き）, 例
+@node Regex ranges,  , Line ranges (with context), Examples
 @section 正規表現による範囲指定
 
 @cindex regex ranges
-範囲の指定は、正規表現を使って表記することもできる。
-これには、@code{--regex-range}というコマンドラインオプションを使う。
-この場合、指定範囲の開始は、指定された正規表現にマッチする文字列を（任意の位置で）含む行によって検出される。
-また、範囲の終了は、範囲を開始する正規表現と同じものにマッチする文字列を含む行によって検出される。
-この機能は、ソースコードにおいてアドホックに区切られた（たとえば、特定のコメントのパターンなどで）特定の部分だけを示すようにして、コードをドキュメントにしたい（たとえば、ちょうどこのマニュアルでやっているように）ときに非常に役に立つ。
+範囲の指定は、正規表現を使って表記できます。
+これには、コマンドラインオプション@code{--regex-range}を使います。
+この場合、指定範囲の開始は、指定された正規表現にマッチする文字列を（任意の位置で）含む行によって検出されます。
+また、範囲の終了は、範囲を開始する正規表現と同じものにマッチする文字列を含む行によって検出されます。
+この機能は、（例えば、特定のコメントのパターンなどで、）ソースコードにおいてアドホックに区切られた特定の部分だけを示すようにして、（例えば、ちょうどこのマニュアルでやっているように、）コードをドキュメントにしたい時に非常に役に立ちます。
 
-例として、次の指定をすることで、@xref{簡単な例}に示されているソースから、下の出力が生成された。
+例として、次の指定をすることで、別節（@pxref{Simple example}）に示されているソースから、下の出力が生成されました。
 
 @example
 --regex-range="/// [[:alpha:]]+"
 @end example
 
 @noindent
-@code{/// class}という文字列を含む行は、範囲を指定するものだが、出力の中には示されない。
+@code{/// class}という文字列を含む行は範囲を指定するものですが、出力の中には示されません。
 
 @include test_regexrange1.java.texinfo
 
-それに加えて、行番号は元のファイルの行と一致している。
+それに加えて、行番号は、元のファイルの行と一致しています。
 
-@code{/* main */}の間にインクルードされているものだけを出力したい場合には、次のように指定する（@code{*}という特殊な正規表現の文字はエスケープしなければならないので注意）。
+@code{/* main */}の間にインクルードされているものだけを出力したい場合には、次のように指定します（@code{*}という正規表現の特殊文字はエスケープしなければならないので注意してください）。
 
 @example
 --regex-range="/\* main \*/"
 @end example
 
 @noindent
-そして次のものが得られる。
+そして次のものが得られます。
 
 @include test_regexrange_main.java.texinfo
 
-このソースファイルの中の、メソッド名を含むコメント行によって区切られたメソッドだけを出力したい場合には、次のように指定することができる。
+このソースファイル中、メソッド名を含むコメント行によって区切られたメソッドだけを出力したい場合には、次のように指定することができます。
 
 @example
 --regex-range="/\* [[:alpha:]]+ \*/"
@@ -3459,59 +3694,61 @@ source-highlight -f texinfo -i test.java -n \
 
 @include test_regexrange_methods.java.texinfo
 
-この場合は、次のようにも指定できる。
+この場合は、次のようにも指定できます。
 
 @example
 --regex-range="/\* main \*/","/\* mymethod \*/"
 @end example
 
 @noindent
-@code{--regex-range}は複数の正規表現を受け付けるからだ。
+@code{--regex-range}は、複数の正規表現を受け付けるからです。
 
-重要：コマンドラインで指定された正規表現は、その指定された順序でテストされるので非常に重要だ。
+重要：コマンドラインで指定された正規表現は、その指定された順序でテストされますので非常に重要です。
 
-@node バグ報告, メーリングリスト, 例, Top
+
+@node Problems, Mailing Lists, Examples, Top
 @chapter バグ報告
 @cindex bugs
 @cindex problems
 
-@command{source-highlight}にバグを見つけた場合には、次のアドレスにメールを送ってほしい。
+@command{source-highlight}にバグを見つけた場合には、次のアドレスにメールを送ってください。
 
 @code{bug-source-highlight at gnu dot org}
 
-バージョンナンバーを含めてほしい。
-@w{@samp{source-highlight --version}}を実行すればバージョンナンバーが判る。
-またプログラムの出力と期待する出力もメッセージに含めてほしい。@refill
-Include the version
+バージョン番号を入れてください。
+@w{@samp{source-highlight --version}}を実行すればバージョン番号が分かります。
+また、プログラムの出力と期待する出力もメッセージに入れてください。@refill
+
+@command{source-highlight}についてのその他の質問、コメント、提案がある場合には、メールで作者に連絡してください（メールアドレスは@value{myhomepage}で分かります）。
+作者は、その問題を解決する時間が無いかもしれませんが、ユーザを支援するつもりはあります。
 
-その他の@command{source-highlight}についての質問、コメント、提案がある場合には、メールで作者に連絡してほしい（メールアドレスは@value{myhomepage}で見つけられる）。
-作者は、その問題を解決する時間が無いかもしれないけれども、あなたを助けようとはするつもりだ。
 
-@node メーリングリスト, Concept Index, バグ報告, Top
+@node Mailing Lists, Concept Index, Problems, Top
 @chapter メーリングリスト
 @cindex mailing list
 
-以下の複数のメーリングリストが利用可能だ。
+以下のように、複数のメーリングリストが利用できます。
 
 @code{help-source-highlight at gnu dot org}
 
-これは、このプログラムについての一般的な議論や、助けを頼む場合のメーリングリストである（オープンなメーリングリスト）。
+これは、このプログラムについての一般的な議論をする場合や、支援を頼む場合のメーリングリストです（オープンなメーリングリスト）。
 @uref{http://mail.gnu.org/mailman/listinfo/help-source-highlight}
  
 @code{info-source-highlight at gnu dot org}
 
-これは、新規リリースや新機能に関する情報を受け取るためのメーリングリストだ（リードオンリーのメーリングリスト）。
+これは、新規リリースや新機能に関する情報を受け取るためのメーリングリストです（リードオンリーのメーリングリスト）。
 @uref{http://mail.gnu.org/mailman/listinfo/info-source-highlight}.
  
-メーリングリストを購読したい場合には、示したURLへ行って、指示に従ってほしい。
-もしくは私にメールを送ってもらえば、登録して差し上げる。
+メーリングリストを購読したい場合には、示したURLへ行って、指示に従ってください。
+もしくは、メールを私に送ってもらえば、登録して差し上げます。
 
-新規リリースにおける新機能については私のブログでも説明するつもりだ。
-ブログのURLは次の通り。
+新規リリースにおける新機能については私のブログでも説明するつもりです。
+ブログのURLは次の通りです。
 
 @uref{http://tronprog.blogspot.com/search/label/source-highlight}
 
-@node Concept Index,  , メーリングリスト, Top
+
+@node Concept Index,  , Mailing Lists, Top
 @unnumbered Concept Index
 
 @cindex tail recursion