JPUG DOCの翻訳活動への参加方法(初めての方向け) - pgsql-jp/jpug-doc GitHub Wiki

JPUGの翻訳は、SGMLなどを利用しているために若干癖があります。 こちらで翻訳の手順の理解の一役になればと思います。 こちらの解説は、unix系及びmacをベースに説明させて頂いています。

文書・書籍関連分科会への参加の仕方

MLに加入する

PostgreSQL 文書・書籍関連分科会への参加登録

参加方法:文書・書籍関連分科会のメーリングリストに登録してください。メーリングリストに登録することによって、 文書・書籍関連分科会、および分科会の各種活動に参加登録することができます。

以下のURLよりjpug-docのMLに参加してください、翻訳に関する多くの議論はこちらのML上で行われています。

翻訳作業のながれ

githubの基本的な利用手順

・github(https://github.com/ )に自分のアカウントを作成します。

・jpugのpgsql-jp github (https://github.com/pgsql-jp/jpug-doc )をforkします

・自分のレポジトリに https://github.com/{user_name}/jpug-doc ができているのでこちらをcloneします

自分のマシンへ、git clone。

[local]

git clone [email protected]:{user_name}/jpug-doc.git

とすると、コマンドを実行したディレクトリに、jpug-docのフォルダができます。

git clone [email protected]:{user_name}/jpug-doc.git {folder_name}

とすれば指定のフォルダに格納できます。

翻訳分科会のwiki(余力があればML)に作業を行うファイルを宣言します。

・ 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を出した後にこれを確認する方法でも問題ありません。

ドキュメントビルド手順

https://github.com/pgsql-jp/jpug-doc/wiki/%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%88%E3%83%93%E3%83%AB%E3%83%89%E6%89%8B%E9%A0%86

ドキュメントビルド手順(Mac版)

https://github.com/pgsql-jp/jpug-doc/wiki/%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%88%E3%83%93%E3%83%AB%E3%83%89%E6%89%8B%E9%A0%86%28Mac%E7%89%88%29-%E8%AA%BF%E6%95%B4%E4%B8%AD

を参考に、sgmlからhtmlを生成します。

githubでpull request

方法その1

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をおこないます。

方法その2

あるいは、ローカルでは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 [email protected]:pgsql-jp/jpug-doc.git  // pgsql-jpのremoteを追加。
$:~/jpug-doc (doc_ja_15)$ git remote -v
 jpug	[email protected]:pgsql-jp/jpug-doc.git (fetch)
 jpug	[email protected]:pgsql-jp/jpug-doc.git (push)
 origin	[email protected]:user_name/jpug-doc.git (fetch)
 origin	[email protected]: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つのものがあります。

CDATAの翻訳での注意

CDATA[]内でコメント化してもhtmlに変換した時に原文がそのまま表示されてしまいます。 以下のよう、一旦閉じて再度コメント化します。

"<![CDATA["
としていたようです。
]]>
<!--
/* by reference, variable length */
-->
<![CDATA[

]]>

Q&A

・ ドキュメントの文字コードはなぜEUC-JPなのですか

歴史的事情により(主にSGMLのコンパイルが通るか)EUC-JPにしておくと文字化け等をふくめ環境構築がしやすかったためにそうなっています。現在UTF-8に切り替える準備をおこなっておりますので、もうすこしEUC-JPでお願いします。

※(2015.04.30 追記) 9.4.1の翻訳分から、UTF-8にGITのレポジトリは切り替わっておりますのでこの部分の情報は過去のお話となります。

・ 翻訳で困った場合

MLに質問をなげてください。

・ コンパイルが通らない場合

閉じられていないタグがないか、不必要なTABがないか確認する。

・ 単語訳等に困った場合

過去のバージョンのファイルに該当の単語で検索をかけて、その時の訳をさがしてみてください

$: grep -r 'transaction' ./

・ 新しい単語で過去に例がない

MLで相談してください。基本的にはなにかしら翻訳をする方向性で、良い訳がないばあいそのまま読みのカタカナ表記でいく事が多いです。

・ バックパッチは行わないの?

運営上、「バックパッチは行わない」という明示的なきまりはなく、作業量てきに手が回らない及び、検索エンジンが適切なバージョンのページを指示してくれない(現在は同一の別ページがあればそちらへのリンクも表示してくれるので少し緩和しています)などの理由から、最新版のみを追っかける状況となっています。

・ エラーメッセージの翻訳がされてないところがあると思うのですが

エラーメッセージなど原文が掲載されている方が検索にヒットする事を考えて英文をそのまま掲載している所もあります。

⚠️ **GitHub.com Fallback** ⚠️