-
Notifications
You must be signed in to change notification settings - Fork 85
JPUG DOCの翻訳活動への参加方法(初めての方向け)
JPUGの翻訳は、SGMLなどを利用しているために若干癖があります。 こちらで翻訳の手順の理解の一役になればと思います。 こちらの解説は、unix系及びmacをベースに説明させて頂いています。
PostgreSQL 文書・書籍関連分科会への参加登録
参加方法:文書・書籍関連分科会のメーリングリストに登録してください。メーリングリストに登録することによって、 文書・書籍関連分科会、および分科会の各種活動に参加登録することができます。
以下のURLよりjpug-docのMLに参加してください、翻訳に関する多くの議論はこちらのML上で行われています。
・github(https://github.com/ )に自分のアカウントを作成します。
・jpugのpgsql-jp github (https://github.com/pgsql-jp/jpug-doc )をforkします
・自分のレポジトリに https://github.com/{user_name}/jpug-doc ができているのでこちらをcloneします
[local]
git clone git@github.com:{user_name}/jpug-doc.git
とすると、コマンドを実行したディレクトリに、jpug-docのフォルダができます。
git clone git@github.com:{user_name}/jpug-doc.git {folder_name}
とすれば指定のフォルダに格納できます。
・ 15予約表
https://github.com/pgsql-jp/jpug-doc/wiki/ドキュメント翻訳担当リスト15.0
githubのアカウント取得をお願いします。
翻訳リスト(sgmlリスト)は最初の方が一覧を書いてくれます。
その横に、名前、ステータス(予約(名前しか書いてない状態)、着手、対応済み、前のバージョンから変更無し(翻訳不要)、マージ済み) を記載して、翻訳を行うsgmlのファイルを予約してください。
ローカルの開発環境に上記で宣言したファイルのブランチを作成します。ローカルブランチ名は好きに作成して頂いて大丈夫ですが、sgmlのファイル名等で作成するとわかりやすいです。
ブランチを作成して、作成したブランチに移動
$ :git checkout -b {ローカルブランチ名}
$ :~/jpug-doc (doc_ja_15)$ git branch
doc_ja_15
* doc_ja_15_work1
翻訳の注意事項は別途記載します。 commitは、随時行って頂いて大丈夫です。
$ :~/jpug-doc (doc_ja_15_work1)$ git commit -a
一式開発が終了した段階で、コンパイルができるか確認します。 現在はgithub側でCIが自動的にコンパイルが通るかのチェックをしてくれるため、 PRを出した後にこれを確認する方法でも問題ありません。
ドキュメントビルド手順
ドキュメントビルド手順(Mac版)
を参考に、sgmlからhtmlを生成します。
doc_ja_15(トピックブランチ) にコミットをマージします。 squash オプション付きでマージする流れにすると、開発中に安心して随時コミットができ、不要なコミットログを残さなくてすみます。
git checkout -b doc_ja_15_work1
修正作業...
git commit -a -m "commit message"
git commit -a -m "commit message2"
git checkout doc_ja_15
git merge --squash doc_ja_15_work1
git commit -a -m "xxxx.sgmlのファイルを翻訳" // doc_ja_15のブランチです。
自分のgithubにpushします。
git push origin doc_ja_15
githubのサイトから、pgsql-jp/jpug-docにpull requestをおこないます。
あるいは、ローカルではdoc_ja_15(トピックブランチ)にマージせず、作業用ブランチを自分のgithubにpushして
git push origin doc_ja_15_work1
それをgithubのサイトから、pgsql-jp/jpug-docにpull requestをおこなうという順でもよいでしょう。 修正部分について他の人の作業とのマージが不要ならこちらが簡単です。
この後、MLの方にプルリクしたファイルと査読依頼のメールをだします。査読の調整はML上でおこないます。
査読にて修正点がある婆は、上記の作業を繰り返して、修正していきます。
同時にwikiの予約表の方も更新していってください。
都度都度、pgsql-jpのほうから、他の方の修正を取り込んでおいてください。
cd jpug-doc
$:git remote add jpug git@github.com:pgsql-jp/jpug-doc.git // pgsql-jpのremoteを追加。
$:~/jpug-doc (doc_ja_15)$ git remote -v
jpug git@github.com:pgsql-jp/jpug-doc.git (fetch)
jpug git@github.com:pgsql-jp/jpug-doc.git (push)
origin git@github.com:user_name/jpug-doc.git (fetch)
origin git@github.com:user_name/jpug-doc.git (push)
$:git pull jpug {branch_name}
$:git commit -a -m 'merge'
$:git push origin {branch_name}
・コメント行は開始終了タグで1行とり、元の英文をコメント化して、その下に翻訳を記載します。本文の翻訳は通例的に余計な空白は削除して左寄せにします。原則として、句点「。」で改行し、句点以外では改行しないものとします。
・元の英文の中のタグは尊重してそのまま利用しましょう。
・句読点、記号「」()などは、全角で記載します。ただし英語を囲んでいる場合などはそのまま、半角を利用します。(PL/pgSQL)
・英文をコメントアウトしますが、その英文本文に「--」があるとコンパイルエラーになります。
その場合、コメントアウトした英文の引き算記号を「
--
」にしてください。
・英文の、WAL data 等の翻訳は、「WALデータ」 と空白をいれずに一つの単語とします。
例
<!--
In this section we will sketch how <acronym>SQL</acronym> can be
embedded into a host language (e.g., <literal>C</literal>).
There are two main reasons why we want to use <acronym>SQL</acronym>
from a host language:
-->
本節では、ホスト言語(例えば <literal>C</literal>)に<acronym>SQL</acronym>を埋め込む方法の概略を解説します。
ホスト言語から<acronym>SQL</acronym>を使用したい理由としては主に2つのものがあります。
・翻訳あるいは確認が必要な箇所は自動生成された「マッチ度」あるいは「機械翻訳」のマークが付いています(両方付いていることもあります)。これをベースに翻訳を作成し、元の自動生成された部分は削除します。
・翻訳が必要でも、「マッチ度」あるいは「機械翻訳」のマークが付いていない箇所があります。こうした箇所は目視で捜すか、git diffを使って、原文の一つ前の翻訳バージョンと現在のバージョンの差分を取って確認します。たとえば、PostgreSQL 17.0の翻訳であれば、以下のようにします。
git diff REL_16_4 REL_17_0 filename
CDATA[]内でコメント化してもhtmlに変換した時に原文がそのまま表示されてしまいます。 以下のよう、一旦閉じて再度コメント化します。
"<![CDATA["
としていたようです。
]]>
<!--
/* by reference, variable length */
-->
<![CDATA[
]]>
・ ドキュメントの文字コードはなぜEUC-JPなのですか
歴史的事情により(主にSGMLのコンパイルが通るか)EUC-JPにしておくと文字化け等をふくめ環境構築がしやすかったためにそうなっています。現在UTF-8に切り替える準備をおこなっておりますので、もうすこしEUC-JPでお願いします。
※(2015.04.30 追記) 9.4.1の翻訳分から、UTF-8にGITのレポジトリは切り替わっておりますのでこの部分の情報は過去のお話となります。
・ 翻訳で困った場合
MLに質問をなげてください。
・ コンパイルが通らない場合
閉じられていないタグがないか、不必要なTABがないか確認する。
・ 単語訳等に困った場合
過去のバージョンのファイルに該当の単語で検索をかけて、その時の訳をさがしてみてください
$: grep -r 'transaction' ./
・ 新しい単語で過去に例がない
MLで相談してください。基本的にはなにかしら翻訳をする方向性で、良い訳がないばあいそのまま読みのカタカナ表記でいく事が多いです。
・ バックパッチは行わないの?
運営上、「バックパッチは行わない」という明示的なきまりはなく、作業量てきに手が回らない及び、検索エンジンが適切なバージョンのページを指示してくれない(現在は同一の別ページがあればそちらへのリンクも表示してくれるので少し緩和しています)などの理由から、最新版のみを追っかける状況となっています。
・ エラーメッセージの翻訳がされてないところがあると思うのですが
エラーメッセージなど原文が掲載されている方が検索にヒットする事を考えて英文をそのまま掲載している所もあります。