メールの詳細（トピック表示）
加藤です
このMLの参加承認がおりない状態らしいです。
MLオーナーは川合さんのようですが、見てらっしゃいますかね...?
新規参加者が、参加できない状態はまずいので、
見てらっしゃったら、反応お願いします。
必要なら、オーナーの変更とか、アシスタントの追加とか
したほうが良いんでは無いかと思います。
よろしくお願いします。
--
Kato Atsushi (Ktat)
mailto:ktat.is@…
読み込み中...-
MLNo.1068
canadaさん
（0） 2009/12/06 23:21 [メール表示する]
2009年12月6日23:08 IWAI, Masaharu
>> docs/modules/IO-All-0.31/All.pod
>>
>> これです。
>
> あれ? リポジトリにあるものはEUC-JPみたいですよ？
あれ、だとすると僕が勝手にutf8にしたのかも知れません。早とちりでした
申し訳ありません。
> このファイルがhttp://perldoc.jpとかどこかで不具合起こしちゃってます？
このファイルがどうだったかは忘れましたが、いわゆる新ポータル暫定版 http://kaede.to:8000/ を作る際に、
Encode::*が色々やらかしてくれたのでファイルをいじったり文字コードを変えたりは
ありました。文字コードを変えたのはおそらくEUC-JPな文書をEncodeがsjisに勘違いした
からだと思います。sjisをリポジトリから撲滅できればそういったことはなくなるので、
utf8/EUC-JPの2択、というルールは私にとってはかなり重要なものです。
ともあれお手数をかけさせてしまってすみませんでした。
--
Canada, Masakatz -
MLNo.1069
iwaimさん
（1） 2009/12/06 23:23 [メール表示する]
岩井です。
2009年12月6日23:07 Canada Masakatz
>> Canadaさんが仰っているのはたぶんRedmineなどの、BTS (ITS) をも備えた
>> プロジェクト管理ツールって話なんですか?
>
> ですね。BTSそのものだけあってもしかたないですし。Redmineは当初視野に入れていましたし。
《BTSそのものだけあってもしかたない》というのはまったく同意しませんが、
今までのメールで金田さんが「BTS」と言っていたものは「プロジェクト管理ツール」だったということは
了解しました。
ややこしいので、今後は使い分けてください。お願いします。
>> 分散を想定していないのに分散型を推す理由がわかんないです。そこを教えてください。
>
> いやいや、最終的に１つのリポジトリにまとめるってだけの話で分散は視野に入れてますよ。
> 例えばCatalystなんかは専門の翻訳チームが必要な気がしますし、そういうった場合にGitは
> 非常に強力なツールとなりうるでしょう。その辺はIRCで色々議論したと思いますのでログも併せて読んでください。
専門の翻訳チームを作ったとしても、CVSではダメでGitならOKという理由が私には理解できていません。
そこを教えてください。
ちなみに、私自身は別にGitになってもまったく問題ないのですが、
現在積極的に翻訳してくださっている白方さんが、Gitに変わることに賛同を示していないので、
現状のCVSからGitに変更するならば、それなりの理由が必要だと思っていろいろ伺っています。
最悪なのは、Gitに変更したにも関わらず、誰も(新たに|再び)積極的に翻訳する人がでてこず、
しかも、白方さんのモチベーションも低下してしまったという状況になることです。
> それとは別に、githubが翻訳ポータルとしても充分な機能を備えているので、バックエンドが
> gitかどうかに関わらずそれを是非使いたい、というのがあります。
私、githubについてはあまり知らないのですが、githubのどのあたりが翻訳ポータルとして
十分な機能を持つんでしょうか？教えてください。
今のところは「PODをそれなりにHTML化してくれる」ぐらいしかわかってないです。
> githubの使用については、「なぜgithubなのか分からない」以外の反対意見は今のところ特に出ていませんよね？（確認）
そもそも「何故Gitなのか解らない」と私は言っています。実際にどこのサービスを使うのかは
Gitに決まってからだと思っています。
もちろん、githubが素晴らしすぎて、そこを使えるだけでGit化するメリットがあるということであれば、
Git化することは問題ないと思います。
>> とすれば今と変わらないというご意見ですね。
>
> いえ、Shift_JISとか混じってますよ現状。今、リポジトリに完全にutf8とEUC-JPしか存在しないのなら
> こんなに騒いでないです。
混じっているものは見つけ次第教えてくださいよー。
混在していたらたぶんそれは不具合です。修正する必要があります。
>> =encodingについてのルール決めをどうするのかというところでしょうか。
>
> =encodingは入れる、でいいんじゃないでしょうか。でも私が作るシステムがその行を信用するかどうかは
> また別です。あえて信用して文字化けしないように=encodingを正確さを強要するか、あえて=encodingを無視して、
> 間違っていても確実に表示される方を選ぶかの2択なので。
一つ伺いたいんですが、金田さんは翻訳者の立場から話しているんですか？
それとも、perldocjpの成果物などを使って利用者向けポータルを使う立場から？
--
いわい -
MLNo.1070
iwaimさん
（1） 2009/12/06 23:30 [メール表示する]
岩井です。
2009年12月6日23:21 Canada Masakatz
> あれ、だとすると僕が勝手にutf8にしたのかも知れません。早とちりでした
> 申し訳ありません。
このファイルに関しては了解です。
>> このファイルがhttp://perldoc.jpとかどこかで不具合起こしちゃってます？
>
> このファイルがどうだったかは忘れましたが、いわゆる新ポータル暫定版 http://kaede.to:8000/ を作る際に、
> Encode::*が色々やらかしてくれたのでファイルをいじったり文字コードを変えたりは
> ありました。文字コードを変えたのはおそらくEUC-JPな文書をEncodeがsjisに勘違いした
> からだと思います。
なるほど。それは了解しました。
で、Encodeにバグがあるということでしたら、それは我々にとっては大問題なので、
Encodeのバグが確認できるファイルを是非思い出していただければ。
今のperldocjpのリポジトリのデータをもう一回、当時の金田さんのシステムに突っ込んだら
再現すると思うので、お時間を作って是非やっていただけないでしょうか。
或いは、金田さんの過去のウェブアプリケーションはgithubのリポジトリから持ってこれるので、
ハードウェアのアーキテクチャやOS、Perlのバージョン、Encodeのバージョンなど諸々の情報を
いただければ、私の方で時間をとって試してみます。
> sjisをリポジトリから撲滅できればそういったことはなくなるので、
> utf8/EUC-JPの2択、というルールは私にとってはかなり重要なものです。
いや、ですから、今でもそうなっている*はず*なんです。基本EUC-JPで訳してたし。
Shift_JISなものが混じっていたら修正しちゃっていいはずです。
> ともあれお手数をかけさせてしまってすみませんでした。
いえ、それはまったく問題ないです。エディタで開いたりして確認するだけだったので。
--
いわい -
MLNo.1071
canadaさん
（0） 2009/12/06 23:46 [メール表示する]
かなだです。
2009年12月6日23:23 IWAI, Masaharu
> ややこしいので、今後は使い分けてください。お願いします。
了解です。
> 専門の翻訳チームを作ったとしても、CVSではダメでGitならOKという理由が私には理解できていません。
> そこを教えてください。
Gitならクローンを作成して、そこにCatalystのブランチを切って、各々そこからクローンしてCatalystの
翻訳に特化するプロジェクトが簡単にできます。CVSしか使わない場合、プロジェクトが立っても作業がCVSリポジトリから
切り離せないので非常に便が悪いです。
> ちなみに、私自身は別にGitになってもまったく問題ないのですが、
> 現在積極的に翻訳してくださっている白方さんが、Gitに変わることに賛同を示していないので、
> 現状のCVSからGitに変更するならば、それなりの理由が必要だと思っていろいろ伺っています。
白方さんがCVSリポジトリにコミットを続け、それをgitにマージする作業は厭いません。
私が代わってその作業をやります。現在積極的に翻訳をなさっている方が白方さんだけだと聞き、
現在のところは白方さんの意向はなるべく尊重したいと考えています。
> 最悪なのは、Gitに変更したにも関わらず、誰も(新たに|再び)積極的に翻訳する人がでてこず、
> しかも、白方さんのモチベーションも低下してしまったという状況になることです。
同意です。ただ表明しますが、私は今後翻訳に参加します（下手ですが）。
> 私、githubについてはあまり知らないのですが、githubのどのあたりが翻訳ポータルとして
> 十分な機能を持つんでしょうか？教えてください。
> 今のところは「PODをそれなりにHTML化してくれる」ぐらいしかわかってないです。
バージョン管理が利用できること、PODが表示できること、つまりPODの文法チェックが視覚的にできること、
Wiki的にその場でドキュメントの編集ができること、文字コードが自然に統一されること、
などなどです。大前さんが主張されていた機能がほとんど備わっているというのもあります。
今まで選定していたBTSやWikiにこれだけの条件を満たすものはありませんでした。
> 混じっているものは見つけ次第教えてくださいよー。
> 混在していたらたぶんそれは不具合です。修正する必要があります。
そうですね、すみません。手が空いた時に探してみますね。
> 一つ伺いたいんですが、金田さんは翻訳者の立場から話しているんですか？
> それとも、perldocjpの成果物などを使って利用者向けポータルを使う立場から？
現在は翻訳はしていませんが、両方だと受け取ってください。
--
Canada, Masakatz -
MLNo.1072
canadaさん
（0） 2009/12/06 23:52 [メール表示する]
金田です。
2009年12月6日23:30 IWAI, Masaharu
> で、Encodeにバグがあるということでしたら、それは我々にとっては大問題なので、
> Encodeのバグが確認できるファイルを是非思い出していただければ。
ご存知かも知れませんが、半角カナを許容したsjisとEUC-JPは、場合によっては
ほとんど見分けが付きませんから（特にEUC-JPは半角カナだらけのsjis文書に見える）、
バグというよりは誤認識ですね。仕方のないことだと思います。
例えば「デスクトップ（半角カナで）」とか半角カナのsjisとも取れますし、漢字4文字のEUC-JPとも取れます（なのでデスクトップは化けるわけです）。
形態素で推測する以外、機械には正確にどっちかは分かりません。
> 今のperldocjpのリポジトリのデータをもう一回、当時の金田さんのシステムに突っ込んだら
> 再現すると思うので、お時間を作って是非やっていただけないでしょうか。
そういったわけで、sjisが混じっているという前提だと当然起こりうる現象なので、再現する必要は
ないかと。ただsjisのファイルは困るので探した方がよさそうですね。
>> sjisをリポジトリから撲滅できればそういったことはなくなるので、
>> utf8/EUC-JPの2択、というルールは私にとってはかなり重要なものです。
>
> いや、ですから、今でもそうなっている*はず*なんです。基本EUC-JPで訳してたし。
> Shift_JISなものが混じっていたら修正しちゃっていいはずです。
了解しました。
--
Canada, Masakatz -
MLNo.1073
iwaimさん
（1） 2009/12/06 23:59 [メール表示する]
岩井です。
2009年12月6日23:46 Canada Masakatz
>> 専門の翻訳チームを作ったとしても、CVSではダメでGitならOKという理由が私には理解できていません。
>> そこを教えてください。
>
> Gitならクローンを作成して、そこにCatalystのブランチを切って、各々そこからクローンしてCatalystの
> 翻訳に特化するプロジェクトが簡単にできます。CVSしか使わない場合、プロジェクトが立っても作業がCVSリポジトリから
> 切り離せないので非常に便が悪いです。
切り離せないことによるデメリットが私には理解できてないです。
まあ、気分的に切り離した方がすっきりするという感覚をもつ人がいることは理解できるし、
そういう感覚は大事だというのも理解できる。
でも、実際にそういうプロジェクトが走るという動きがない現状では絵に描いた餅だろうな、とも思う。
> 白方さんがCVSリポジトリにコミットを続け、それをgitにマージする作業は厭いません。
> 私が代わってその作業をやります。
まあ、それはそういうことになったら金田さんや私や他の誰かがやるんでしょうけどね。
というか、そもそも既にCodeReposとかそっちにも翻訳の成果物はあるはずなので、
ポータルやるならいろんなリポジトリから持ってこないとダメそうですよね。
だとしたら、新規にGitリポジトリ作るなら作って、後はポータル側でなんとかしてもらうと
いいだけじゃないかという気はしてきました。
>> 最悪なのは、Gitに変更したにも関わらず、誰も(新たに|再び)積極的に翻訳する人がでてこず、
>> しかも、白方さんのモチベーションも低下してしまったという状況になることです。
>
> 同意です。ただ表明しますが、私は今後翻訳に参加します（下手ですが）。
期待してます！よろしくお願いします。
>> 私、githubについてはあまり知らないのですが、githubのどのあたりが翻訳ポータルとして
>> 十分な機能を持つんでしょうか？教えてください。
>> 今のところは「PODをそれなりにHTML化してくれる」ぐらいしかわかってないです。
>
> バージョン管理が利用できること、PODが表示できること、つまりPODの文法チェックが視覚的にできること、
> Wiki的にその場でドキュメントの編集ができること、文字コードが自然に統一されること、
> などなどです。大前さんが主張されていた機能がほとんど備わっているというのもあります。
> 今まで選定していたBTSやWikiにこれだけの条件を満たすものはありませんでした。
検索が必要だと思うんだけど。あと、
http://github.com/canada/perlpod/blob/master/docs/modules/IO-All-0.31/All.pod
などをみれば判ると思うんですが、ファーストビューの大半がいらん情報になりますよね。
翻訳物を皆に見てもらうという立場からは
http://perldoc.jp/docs/modules/IO-All-0.31/All.pod
よりも大きな後退であると、ウェブ屋な私は判断しています。
あと
>> ややこしいので、今後は使い分けてください。お願いします。
>
> 了解です。
はよろしくお願いします。
>> 混じっているものは見つけ次第教えてくださいよー。
>> 混在していたらたぶんそれは不具合です。修正する必要があります。
>
> そうですね、すみません。手が空いた時に探してみますね。
よろしくお願いします！
>> 一つ伺いたいんですが、金田さんは翻訳者の立場から話しているんですか？
>> それとも、perldocjpの成果物などを使って利用者向けポータルを使う立場から？
>
> 現在は翻訳はしていませんが、両方だと受け取ってください。
了解しました。
--
いわい -
MLNo.1074
iwaimさん
（1） 2009/12/07 00:09 [メール表示する]
岩井です。
2009年12月6日23:52 Canada Masakatz
>> で、Encodeにバグがあるということでしたら、それは我々にとっては大問題なので、
>> Encodeのバグが確認できるファイルを是非思い出していただければ。
>
> ご存知かも知れませんが、半角カナを許容したsjisとEUC-JPは、場合によっては
> ほとんど見分けが付きませんから（特にEUC-JPは半角カナだらけのsjis文書に見える）、
> バグというよりは誤認識ですね。仕方のないことだと思います。
誤認識だから諦めるかどうかという判断は我々が下してしまうのではなくて、
Encodeのメンテナに委ねるべきです。
> 例えば「デスクトップ（半角カナで）」とか半角カナのsjisとも取れますし、漢字4文字のEUC-JPとも取れます（なのでデスクトップは化けるわけです）。
> 形態素で推測する以外、機械には正確にどっちかは分かりません。
PODみたいに十分な量のデータがあれば、かなり正確に判断が付くはずだということはいえますよね？
で、Encodeがそこまでやるべきかというのは別の話ですが、形態素解析などを使ってより正確に
判別できる可能性があるということはいえるじゃないですか。
ま、さっき書いたように「誤認識だと諦めるか否かはEncodeメンテナに委ねるべき」と思います。
>> 今のperldocjpのリポジトリのデータをもう一回、当時の金田さんのシステムに突っ込んだら
>> 再現すると思うので、お時間を作って是非やっていただけないでしょうか。
>
> そういったわけで、sjisが混じっているという前提だと当然起こりうる現象なので、再現する必要は
> ないかと。ただsjisのファイルは困るので探した方がよさそうですね。
これを言ったら絶対に気を悪くすると思うんだけど言いますね。
先のmodules/IO-All-0.31/All.podの件といい、「BTS」の示す意味の話といい、
なんか結構軽率に発言なさっているんじゃないかなー、と思ってます。
できれば、もうちょっと丁寧に考えていただいた方がいいと思います。
--
いわい -
MLNo.1076
Ktatさん
（0） 2009/12/07 00:57 [メール表示する]
加藤です。
別スレッドで報告済みですが、見つけておきましたので、変換して、commitしました。
On Sun, 6 Dec 2009 23:52:36 +0900 (JST)
Canada Masakatz
(略)
> 例えば「デスクトップ（半角カナで）」とか半角カナのsjisとも取れますし、漢字4文字のEUC-JPとも取れます（なのでデスクトップは化けるわけです）。
> 形態素で推測する以外、機械には正確にどっちかは分かりません。
さすがにそんな短い文章(というか単語)ではアウトでしょうが、Encode::Guess でも、
pod 全体を読ませてやれば、そんなに精度悪くないと思いますよ？
# なお、Encode::Guess ですが、「出来れば使わない、使うときは、できるだけ長い文章で」
# と、以前、弾さんに聞きました。
今回の方法で、少なくとも、sjis と判断されたものが、euc-jpだったっていうのは、ありませんでした。
--
Kato Atsushi (Ktat)
mailto:ktat.is@… -
MLNo.1077
canadaさん
（0） 2009/12/07 06:23 [メール表示する]
金田です。おはようございます。
ちょっとソースを見てみないと分からないのですが、一部しか読み込ませていない可能性があります。
速度と負荷に影響があるからです。
あと、精度は悪くなくてもドキュメントの量が多いと１％の間違いでも致命的になります。
あと、僕もsjisがeucjpだった記憶はなく、その逆の現象（eucjpがsjis）が起こるんでやたらと困った記憶があります。
2009年12月7日0:57 ktat
> 加藤です。
>
> 別スレッドで報告済みですが、見つけておきましたので、変換して、commitしました。
>
> On Sun, 6 Dec 2009 23:52:36 +0900 (JST)
> Canada Masakatz
> (略)
>> 例えば「デスクトップ（半角カナで）」とか半角カナのsjisとも取れますし、漢字4文字のEUC-JPとも取れます（なのでデスクトップは化けるわけです）。
>> 形態素で推測する以外、機械には正確にどっちかは分かりません。
>
> さすがにそんな短い文章(というか単語)ではアウトでしょうが、Encode::Guess でも、
> pod 全体を読ませてやれば、そんなに精度悪くないと思いますよ？
>
> # なお、Encode::Guess ですが、「出来れば使わない、使うときは、できるだけ長い文章で」
> # と、以前、弾さんに聞きました。
>
> 今回の方法で、少なくとも、sjis と判断されたものが、euc-jpだったっていうのは、ありませんでした。
>
> --
> Kato Atsushi (Ktat)
> mailto:ktat.is@…
>
>
> 【MLコミュホームページ】http://www.freeml.com/perldocjp
>
> --[PR]------------------------------------------------------------------
> ◇◆◇◆ 憧れの４ＬＤＫや共用施設充実マンション ◇◆◇◆
> ◆◇◆◇賃貸じゃ難しい?理想の住まい探しは早めの資料請求で先手!◆◇◆◇
> ◇◆◇◆ これから販売予定のおNewなマンション、即チェック ◇◆◇◆
> http://ad.freeml.com/cgi-bin/sa.cgi?id=ePMUJ
> ------------------------------------------------------------------[PR]--
> ■GMO INTERNET GROUP■ GMO INTERNET www.gmo.jp
>
>
--
Canada, Masakatz -
MLNo.1106
Ktatさん
（0） 2009/12/08 03:48 [メール表示する]
加藤です。
On Mon, 7 Dec 2009 06:23:40 +0900 (JST)
Canada Masakatz
(snip)
> あと、精度は悪くなくてもドキュメントの量が多いと１％の間違いでも致命的になります。
>
> あと、僕もsjisがeucjpだった記憶はなく、その逆の現象（eucjpがsjis）が起こるんでやたらと困った記憶があります。
一応、eucと判定されたものを先頭から400byte程度抜き出した奴(\w\sは削除)をつなげて、
ざーって見てみたんですけど。化けてないように思います。
以下に、おいてます(euc-jpで表示してください)。
http://www.rwds.net/perldoc.jp.txt
--
Kato Atsushi (Ktat)
mailto:ktat.is@…
