加藤です。
gitを知らない人用の導入方法や、gitを?導入した場合の作業イメージっていうのを、
先にドキュメント化したほうがいいんじゃないんですかね。
イメージが共有できてないから、混乱する気がするんですけど？
僕の心配は、gitにすることで参入障壁あがったらやだなぁってくらいですが。
ちなみに、ちょっとずれますが、僕の理想的な翻訳作業は、オリジナル用のリポジトリを持っておいて、
バージョンごとにタグをうつ。翻訳用のリポジトリを持っておく(オリジナルのリポジトリを持っておくのは、patch作るためです)。
trunkは常に最新バージョンを翻訳。翻訳が完了したらバージョンごとにタグをうつ。っていう感じです。
それだけで、十分じゃないかなと思ってます。
んで、また、誤解っぽいところを指摘しておきます。
> ■現状
> sourceforgeで管理
> なのでCVS
プロジェクト開始当初、CVSが主流で、sourceforgeは、CVSしか使えませんでした。
7年くらい前の話です。今は、Sourceforgeでも、git/svn 使えます。
http://sourceforge.jp/docs/Gitの使い方
Webから修正する機能はなさそうですけどね。
> 修正は、誰かが手動でperldoc.jpにアップロードしている
> なので反映が遅い
perldoc.jp は1時間に1回(だったと思う) cronでリポジトリの内容を反映しているだけです。
CVSリポジトリの修正を、「誰か」がやってます。
誤訳等の報告を受けた時の話なら、gitだろうが、なんだろうが、
反映が遅くなるのは、一緒だと思うんですけども?
このプロジェクトで、反映が遅い原因を言うならば、
誤字/誤訳等は気づいた人が勝手にcommitすればいい話なんだけど、
あんまり、そういう雰囲気にはならなかった。
そのため、メインの翻訳者が修正していたので、対応が遅れたり、
放置されるってことがあった、ていうただそれだけな気がします。
完全に人の問題であって、リポジトリ云々は関係ないと思ってます。
Webから修正できればっていう話はツールの問題で、そこは参入障壁の問題でしょう。
現状、sourceforge.jpに登録して、commit 権限をもらって、cvsをcheckoutして、修正。
後は、翻訳物のフッタとかに、連絡先があったりなかったりという現状なので、
連絡先がわからないという、その辺の問題もあるでしょう。
今、現在の誤訳報告の流れって
perldoc.jpの翻訳物 -> perldoc.jpトップ -> perldocjp.sourceforge.jp -> FAQ -> ML/BTS
って、流れだと思うので、遠い。
--
Kato Atsushi (Ktat)
mailto:ktat.is@…
読み込み中...
