@c -*- coding: utf-8; mode: texinfo; documentlanguage: ja -*-
@ignore
- Translation of GIT committish: 499a511d4166feaada31114e097f86b5e0c56421
+ Translation of GIT committish: 42ae342ba877dc8f26cabb5cc3937a6d3cdb4066
When revising a translation, copy the HEAD committish of the
- version that you are working on. See TRANSLATION for details.
+ version that you are working on. For details, see the Contributors'
+ Guide, node Updating translation committishes..
@end ignore
-@c \version "2.12.0"
+@c \version "2.14.0"
@c Translators: Yoshiki Sawada
@c Translation status: post-GDP
@menu
+* 何故構文は変更されるのか？::
* convert-ly を呼び出す::
* convert-ly のコマンド ライン オプション::
* convert-ly の問題点::
+* 手動変換::
@end menu
+@node 何故構文は変更されるのか？
+@section 何故構文は変更されるのか？
+@translationof Why does the syntax change?
+
+@cindex convert-ly
+@cindex updating old input files (古い入力ファイルを更新する)
+
+LilyPond の入力構文はしばしば変更されます。@c
+LilyPond 自体が改良されるため、構文 (入力言語) もそれに合わせて変更されます。@c
+変更の目的は、入力ファイルを読みやすく、書きやすくするためであったり、@c
+LilyPond に新しい機能を持たせるためであったりします。
+
+例えば、@code{\paper} と @code{\layout} のプロパティ名は
+@code{first-second-third} という形式で記述することになっています。@c
+しかしながら、バージョン 2.11.60 で @code{printallheaders} プロパティが@c
+この規則に従っていないことが判明しました。@c
+放置すべきでしょうか？
+(新しいユーザはつじつまの合わない入力形式で混乱するでしょう。)
+それとも、変更すべきでしょうか？
+(既存の楽譜を持つユーザには煩わしいことです。)
+このケースでは、プロパティ名を @code{print-all-headers} に変更することを@c
+決断しました。@c
+幸運なことに、@c
+この変更は @command{convert-ly} ツールで自動的に変換することができます。
+
+不幸なことに、@c
+@command{convert-ly} はすべての変更を処理できるわけではありません。@c
+例えば、バージョン 2.4 以前の LilyPond では、@c
+アクセント文字と非英語文字を LaTeX を用いて入力していました
+-- Christmas のフランス語は @code{No\"el} のように入力されていました。@c
+しかしながら、バージョン 2.6 以降の LilyPond では、@c
+特殊文字 @code{ë} を UTF-8 文字として直接 LilyPond ファイルに@c
+入力することになりました。@c
+@command{convert-ly} はすべての LaTeX の特殊文字を UTF-8 文字に変換する@c
+ことはできません。@c
+手動で古い LilyPond 入力ファイルを更新する必要があります。
+
+
@node convert-ly を呼び出す
@section @command{convert-ly} を呼び出す
@translationof Invoking convert-ly
@command{convert-ly} は古いバージョン番号を検出するために@c
入力ファイルの @code{version} ステートメントを使用します。@c
-たいていの場合、あなたの入力ファイルをアップグレードするには、@c
+たいていの場合、あなたの入力ファイルを更新するには、@c
そのファイルを保持しているディレクトリで以下を実行することで十分です:
@example
@end example
@noindent
-これにより、@code{myfile.ly} はアップグレードされ、@c
+これにより、@code{myfile.ly} は更新され、@c
オリジナル ファイルは @code{myfile.ly~} に保存されます。
+@warning{@command{convert-ly} のバージョンは、@c
+それが扱う最新の構文変更に合わせて変更されます。@c
+このため、入力ファイルの @code{\version} 番号はたいてい@c
+@command{convert-ly} のバージョンよりも低いことになります。}
+
ディレクトリの中にある入力ファイルをすべて変換するには、@c
以下のようにします:
convert-ly -e *.ly
@end example
-オリジナル ファイルをアップグレードされたファイルで置き換える代わりに、@c
-アップグレードされたファイルに異なるファイル名を指定して、@c
-オリジナル ファイルをそのまま残しておくには、@c
-以下のようにします:
+オリジナル ファイルをそのまま残しておき、
+更新されたファイルに新しいファイル名を指定するには以下のようにします:
@example
convert-ly myfile.ly > mynewfile.ly
@end example
-@command{convert-ly} は常にそれが扱っている最新の構文変更に変換します。@c
-このことは、通常、ファイルの中にある @code{version} 番号は
-@command{convert-ly} 自体のバージョンよりも低いということを意味します。
-
このプログラムは変換元のバージョン番号をリストアップします。
バージョン番号がリストアップされない場合、@c
そのファイルは最新であるということになります。
-MacOS@tie{}X ユーザはこのコマンドをメニュー エントリ
+MacOS@tie{}X ユーザはこのコマンドをメニュー エントリ
(@code{Compile > Update syntax}) 下で実行することになるかもしれません。
Windows ユーザはこれらのコマンドを @q{コマンド プロンプト} ウィンドウから@c
@item -f,--from=@var{from-patchlevel}
変換元のバージョンをセットします。@c
これがセットされていない場合、@c
-@command{convert-ly} は入力ファイルの中にある
+@command{convert-ly} は入力ファイルの中にある
@code{version} 文字列を基に推測します。@c
例: @code{--from=2.10.25}
使用方法についてのヘルプを表示します。
@end table
-texinfo ファイルの中にある LilyPond 断片をアップグレードするには@c
+texinfo ファイルの中にある LilyPond 断片を更新するには@c
以下を使用してください:
@example
@command{convert-ly} コマンドをループさせてやります。@c
以下の例は UNIX 用であり、@c
カレント ディレクトリの中にあるすべての @code{.ly} ファイルを@c
-アップグレードします:
+更新します:
@example
for f in *.ly; do convert-ly -e $f; done;
言語の変更がすべて処理されるわけではありません。@c
指定できる出力オプションは 1 つだけです。@c
-自動的に Scheme と更新することと
+自動的に Scheme と更新することと
LilyPond の Scheme インタフェイスを更新することはまったく異なります。@c
Scheme コードの調整は手動で行う覚悟でいてください。
-convert-ly が処理できないことがいくつかあります。@c
-ここに、LilyPond コミュニティがそのことについて訴えたリストを挙げます。
-convert-ly は必要とされるすべての変更を@c
-スムーズに実装できるような構造にはなっていないため、@c
-このようなバグ レポートがあります。@c
-以下は対応して欲しいという望みのリストであり、@c
-参照のためにここに置かれています。
+@node 手動変換
+@section 手動変換
+@translationof Manual conversions
+
+@c not yet
+理論的には、@c
+@command{convert-ly} のようなプログラムはすべての構文変更を処理できます。
+After all, a computer program interprets the old
+version and the new version, so another computer program can
+translate one file into another@footnote{At least, this is
+possible in any LilyPond file which does not contain scheme. If
+there is scheme in the file, then the LilyPond file contains a
+Turing-complete language, and we run into problems with the famous
+@qq{Halting Problem} in computer science.}.
+
+しかしながら、LilyPond プロジェクトの資源には限りがあり、@c
+すべての変換を自動化することはできません。@c
+以下は既知の問題のリストです。
@verbatim
1.6->2.0:
projects / lilypond.git / blobdiff