国際化、英語化†
- ページ: BugTrack
- 投稿者: [[]]
- 優先順位: 重要
- 状態: 着手
- カテゴリー: その他
- 投稿日: 2005-01-18 (火) 21:31:36
- バージョン:
メッセージ†
ちょっと英語化トライしてみようかと思ったのですが、一体どこまで終わっているのかさっぱりわかりません。
一体英語化はどこまでいっていて、どれが最新文書で、どこが大本のまとめページなのですか？
英語化・国際化に関するホットスポット／ポータルはどこ?†
英語化関連のページをあげてみます。
ページ名的には dev:開発談義/Doc英語化 が本筋かと思ったら全然書いていないし、dev::CategoryDev/Document もどれが終わったのかさっぱりで、むしろ dev:PukiWiki/1.4/添付文書のほうが見やすいです。
orgサイトとdevサイトの違い その1†
また、pukiwiki.org で一覧を見ると完成されているかのようなページがちらほらとあります。しかも内容がdev::CategoryDev/Documentにあるのと違ったりします。とりあえず少しだけ。
- たとえば dev::CategoryDev/Document/FormatRule とofficial:FormatRule はどちらが本筋の文書ですか？ -- [[]]
- 位置付け的にはorgにあるものは公開文書で、devにあるものは作業用の文書(のはずのもの)で、CVSリポジトリの wiki.en に収められているものこそが本物の作業対象です。 -- henoheno
- 誤解していただきたくないのですが、orgにある「標準添付のドキュメント」は基本的に「その時のorgに設置されているPukiWikiのもの」が置かれています。orgサイトの性格上PukiWiki全般の話題もありますが(凍結していないものには、たまにどなたかの修正も入ってますが)、「そのWikiに対するマニュアル」を提供しているという点は普通のPukiWikiサイトと変わりません。 -- henoheno
wiki.en の位置付けについて (確認)†
ついでに、wiki.en フォルダの利用が微妙です。pukiwiki.ini.php で LANG を en にしただけではだめで、DATA_DIR も wiki.en に変更しなければいけません。どうせ LANG を en にした時点で日本語は文字化けするのですから、同時に wiki.en に変えてしまってもいいのではないでしょうか？と思ったら wiki.en の中にも内容が日本語のファイルがあって wiki.en は何がしたいんだ。といったかんじです。
- wiki.en についてですが、まだ日本語の文書が混ざっています。とりあえず置いてから訳すのか、訳してから置くのかは結果さえ上がればどちらでも良いですしどちらの方法も前進していることに違いはないのですが、前者の状態のドキュメントが[[]]さんの目にしたものです。 -- henoheno
- 設定(例えばLANG)を ja から en にした途端に wiki.en の方を見に行く様にする、というのは危ないのでできません。diff, attach, backup, cacheなどのファイルが(設定を変える・変えてしまう度に)壊されあうじゃないですか (^^; また、日本語ベースのコンテンツで行くのか、英語ベースのコンテンツで行くのか決めたあとは、使わない方は不要ですよね。両方ともデータを展開させておく必要はありません。そういうわけで、最近のパッケージでは wiki.en はデフォルトで圧縮された状態で同梱されています。 -- henoheno
- 複数言語に対応していけば、やがてenが標準wikiになり、jpがwiki.jpになるのかなぁ。とか思ったり。そしていずれはxoopsのようなインストーラかなぁ。。。。いえ、単なる妄想です。。 --インストーラなんて飾りです！えらい人にはそれがわからんのです！部門より -- yas_
CVS版のpukiwiki.ini.php†
さらに、最新の pukiwiki.ini.php ではコメントが英語だけの部分があったり日本語だけだったり両方併記されていたりと入り乱れて逆に最悪な状態になっています。pukiwiki.ini.php も日本語、英語でわける必要があるのかもしれません。コメントでしかありませんが。
- 最新のpukiwiki.ini.php とはCVS版のことですね? それで止まるわけないじゃないですか (^^; CVS版のある一瞬の更新というのは全て過程でしかありません。pukiwiki.ini.phpも[[]]さんが気にされている国際化や英語化の範疇に入っています。ここもきっちり仕上げないと、安心してRedHatやらDebianやらFreeBSD用のパッケージ作ってfreshmeatなんかに告知出せないじゃないですか (^^; そういうことです。 -- henoheno
- 他のとこでも書きましたが、日本語化された pukiwiki.ini.php があってはいけないということではありませんのであしからず :) -- henoheno
- つまり、日本語化されたpukiwiki.ini.phpやプラグインなどがあってもいいが、それよりも英語化された pukiwiki.ini.phpやプラグインなどをデフォルトパッケージで優先するということですか？*1 そこまでコメント英語Ver.への上書きを推し進めるメリットは何なのでしょうか。間違いなく新規利用者などの敷居があがってしまうのでは。
また、英語化するにしても、それはCVS.enとかいう名前で新たなCVSレポジトリを作成してそこで行った方が、英語化されてしまったコメントを和訳(^^;し直す手間が省けると思うのですが。 -- sagen
- 書き込んでから気付きましたが、CVS.en（仮）は更新の手間が増えるので微妙ですね。手間を考えると、pukiwiki.ini.phpやプラグインなどに関しては、いっそのこと日本語と英語のコメントを併記してしまうというのが一番良いような気がしてきました。英語化する際に日本語コメントを削除するのではなく、英語コメントを追記するという形で。これなら手間はそれほど変わらないのではないでしょうか。ネックはファイルサイズの増加ですね。 -- sagen
- 製作時はコメントを各国語分併記し、各国語用パッケージを作成する段階で必要外のコメントをフィルタアウトする。という感じが良いのではないでしょうか。 -- Mizar
- そもそも、pukiwiki.ini.php をアプリで作成するようにして、直接編集しなくてもいいようにするとか ;) 別の話になっちゃいますけどね (^^; -- teanan
- 現在は「国際化」と「PukiWikiのオーバーホール」の両方を明らかに優先しています。その手段としてターゲット(設定ファイル含む)を英語に絞ることで、「プロダクトの配布におけるデメリット(ロス)を徐々に減らす」事と、「日々の作業の手間(ロス)を減らす」効果を得ています。 -- henoheno
- 一回作ったパッケージが、そのまま日本でも韓国でもドイツでもその他の国にでも流通させられる状態になるとしたら、それは大きな利点(時間の節約)になります。そうするためには、デフォルトのデータが英語になるか、そのようなパッケージが簡単に作成できる様になる必要があります。(※wikiディレクトリなどを入れ替えた日本語版「も」一発で作れる様であってよいのですよ) -- henoheno
- また、今までの (日本語混じりの) pukiwiki.ini.php は海外のユーザーにとって「しきいが比較にならないほど高い」のですが、平素から英語であることでにより「(彼らにとって)わけわからん文字化け」が無くなり、ある程度意味が取れる様になります。(※「日本語による解説」がどこかにあっても良いですよね。「日本語版」を維持するのは下記に挙げる様に、とても大変だと思うのでお薦めしません。その逆も。) -- henoheno
- さらに、各国のユーザーが何か(ある機能とか設定とか)について意見交換する際の指標(ギョーカイ用語も)を提供することができる様になります。場を維持するために重要なことです。 -- henoheno
- 日々の作業を英語に絞るメリットは、そのようなスタンスを維持しながら、同時にPukiWikiをもっとメンテナンス可能な状態にする作業を進める過程がより短くなるということです。pukiwiki.ini.php ひとつとっても、その中にある設定の位置関係などが今まで全く見直されていません。すぐに動かし始めるための設定がどこにあって(集まっていて or バラバラで)、どれが大事ではないのか、全然わかりません。そのようなごく基本的なレベルから叩き直さければならないのですが、海外に提供できる状況を保ちながら最小限の労力で叩き直すには、英語のまま進展して行くのが最もシンプルです。 -- henoheno
- 英語と日本語のコメントを併記するのは作業スピードが落ちるのと、整合性がどうせ合わなくなるのと、ソースがゴチャゴチャして見通しが悪くなるのと、収集が付かなくなるので勘弁して下さい (^^; -- henoheno
- pukiwiki.ini.php は少なくとも英語だ日本語だと言えるレベルではないと思うけどなぁー -- henoheno
- この件は(teananさんの言っている様な切り口もあるかもしれませんが)そもそも副読本程度があればほとんど事足りる話題であると思います。ApacheやPHPや過去に各自が触ってきたCGIのように :) -- henoheno
- ちなみにsagenさんはどんなユーザー層を新規ユーザーとして想定しているのでしょうか。私の認識はこうです。「PukiWikiは、今までCGIを自力で設置したことのある人にとっては超簡単です」 -- henoheno
- 開発日記/2005-01-23にも添付してありますが、ウチのサイトにpukiwiki.ini.phpの日本語版置いてます*2。 -- okkez
- では可読性その他により日英併記は没にしても、せめて pukiwiki.ini.php については 日本語Ver.も拡張子変えるなり圧縮するなりしてパッケージに同梱しませんか。PukiWikiだけをテーマにした書籍も確かまだありませんし。 :) とりあえずokkezさんの pukiwiki.ini.php v.1.108 日本語版をベースに v.1.109 英語版に合わせました。英語のままだった所をもう少し日本語にしてます。
pukiwiki.ini.php *3
ちなみに私が新規ユーザとして想定してるのは、「最近PukiWiki使ったサイトを目にするから自分も試してみようかな」*4といった英語があまり得意でない日本人ですね。そういう人は pukiwiki.ini.php を見て英語ばかりだと面食らうかなと思った次第です。……立場も国内外どっち見てるかの視点も違って不毛な気がするので、想定新規ユーザについては措いておきましょう。(^^; -- sagen
- お疲れ様です :) それぞれのスタンスが明確になっているのですから、不毛ということはありません。しかしsagenさんの着眼点は、開発チームの労力的な問題とは無関係ではないかと思います。カジュアルな利用を希望する(けど自分で設置はしたくない)ユーザーの方に対しては、丁寧な日本語のドキュメントが含まれることの実現を目指すのではなく、WikiRoomやAAA!CAFEのようなホスティングサービスで、セットアップ済みのPukiWikiを利用されることをまず勧めるべきではないでしょうか。また、日本語の書籍やドキュメントなどの「頼りになるもの」があれば良いというのであれば、それがリリースパッケージの中に毎回含まれている必然性はありませんから、同様に手段が違いますよね。 -- henoheno
- すでにpukiwiki.ini.php(CVSリポジトリの方)を改変しているのですが、それに合わせて日本語の方も書き換えて瀬戸際にテストするということは、体力が許しませんのでもう行いませんよ (^^; (そもそも、それはリリース後でもできることですよね) -- henoheno
- (何に関する話題か一瞬わかりませんでしたが (^^; ASAPは as soon as possible の意味で使っていますねー -- henoheno
- これからは、PukiWiki(英)が主流で各国語は派生版？ --
- 日本語パッケージ欲しいな。en無いの。pukiwiki.ini.phpも日本語で。 --
- 上の日本語化済み設定ファイルって「バックアップの世代を区切る文字列」がdefineじゃなくて変数のままになってますね。(無精してそのまま流用したあげく、しばらくそれに気がつかなくてバックアップファイルいくつかおかしくしたなんて言えやしない) --
- ＞また、日本語の書籍やドキュメントなどの「頼りになるもの」があれば良いというのであれば、
いえ、たとえそういった書籍があったとしても、日本語版pukiwiki.ini.phpはあるべきだと思います。*5
＞「バックアップの世代を区切る文字列」がdefineじゃなくて変数のまま
うわ、すみません。(^^; 過去のを流用したまま変わってるのに気づかず見落としてました。pukiwiki.ini.php.2*6 一応修正しましたが、使われる場合は自己責任でどうぞ。……というか、英語版を書いた人に日英両版の整合性をチェックして欲しいのですが。お時間があればお願いします。＞henohenoさん
で、チェック後に、official:PukiWiki/Dounload/1.4.5に添付しておけば、日本語需要には応えられるかなと思いますがどうでしょうか？ -- sagen
- 今の状況で求められているのは「きちんと動くもの」だと思うのですが、英語でコメントを書いた人に コメント以外の整合性確認を依頼する のは変ですね。それとも、まずはコメントだけチェックしろと仰るのでしょうか。*7 -- henoheno
- コメントの内容をざっと見て考えたのですが、これは作成手順がうまくありません。PukiWiki 1.4.4 の ファイルをベースにするのではなく、pukiwiki.ini.phpの英語化を始める直前のファイルをベースにしなければなりません。そうでないためにMD5などの日本語のコメントも古くなっていますし、上で挙げられているような、コメント以外の部分の不一致も生じているようです。 -- henoheno
- もしもそのようなものが存在していたら、SF.jpのファイルリリースあたりに掲載するのはどうだろうと思っていたのですが、これは無理です (^^; -- henoheno
- ＞それとも、まずはコメントだけチェックしろと仰るのでしょうか。
はい、コメントのチェックをして欲しいという意味で書きました。MD5の算出法の説明はわざと過去のを流用してました。あれは書いてあった方が質問箱にMD5について訊ねる初心者が来るのを止められるかなと。まあ、片方にだけあるのは拙いので、あの説明はReadMeの末尾かどこかにでも入れるというのはどうでしょうか。
CVSを眺めてみましたが、英語化直前というとRevision 1.104 あたりですか。時間ができたら照らし合わせてみます。
実働はこれ使ってローカルで試してますが、今のところ問題ないです。*8 -- sagen
- さて、あれから少々時間が経ってしまいましたが、PukiWiki 1.4.5_1 のほぼ英語版 pukiwiki.ini.php (1.111) からスタートして、完全逆日本語訳、従来の日本語訳の盛り込みおよび再検討、PukiWiki Plus! で盛り上がった日本語参考訳などを考慮した日本語版 pukiwiki.ini.php (1.111.2.5) を用意しました。diffによる検証を可能とするため、PukiWiki Plus! 版で行われている「順番の再検討」は盛り込んでいません。 -- henoheno
PukiWiki収録コード内の日本語†
- (BugTrack2/64からの移動 ここから)
- あわせてタイトルを変更してもらった方が良いかもしれません:)。ただまぁ「日本語が沢山ある」というコメントは気になりますが...(既にあるコード内の日本語コメントはそのままでも良いように思うのですが、何か問題が?...この話題はどこにあったかな?） -- jjyun
- BugTrack/783 あたりだったとおもいます。 -- teanan
- 中途半端なコメントにリファレンスをありがとうございます、確認しました。
ただBugTrack/783は設置ファイル系の話ですよね。英語難民な私が気になったのは、pluginファイルにおいて、henoheno さんが気にされている部分が、HowTo の部分が国際化されていないという部分なのか、plugin内のコードのコメントも全て english にすべきと考えているのかを伺ってみたかったんです... (^^;*9 -- jjyun
- (BugTrack2/64からの移動 ここまで)
- こんにちは :) まず、「そもそもコメントが無くても、そこに書いてあるPHP言語(関数の引数の順番や名称、関数や変数の名称、コードブロックのまとめ方、ステートメントの書き方など)に意図が書いてあって伝わる」というのが基本の状態だと考えています。*10。 -- henoheno
- 次に、日本語を使っている部分の場合、それがけして悪いと言うのでは無いのですが「あいまいな言い回し」や「コードに書いてあることと同じ事を書いている」部分が多くなりがちです。これは日本語の性質上ある程度仕方ありませんが、メンテナンスの上では冗長なものとして整理対象とすべきだと考えています。 -- henoheno
- そして、今後海外に紹介して行くにあたっては、英語のコードを自力で提供する事が必須と考えています。(自力の範囲は「リリースもErrataも何もかも一揃い」です) -- henoheno
- ということで、本体に収録したプログラムコード「のコメント」は、日本語か英語化に関係なく、見かけ次第、すべからく (1) 不要な状態(無くてもわかる状態)にするか、 (2) その意味を明確にしながら「より具体的な言い回しの」英語表現に直す様にしています。pukiwiki.ini.php日本語版のように、さらにそれを踏まえて「より具体的な言い回しの」日本語を書く事もありますよ。英語は物事を具体的にしようと思わないとうまく表現できない性質がありますから、今までの不明確な部分を露にするためにも便利に使って?います。 -- henoheno
- コードの意味合いを「解説」するのは何か別のドキュメントか、Wikiのどこかが行う役目だと思いますので、コードの中に何もかも入れる事は考えておりません。*11 -- henoheno
- こんなんで答えになっていますでしょうか。 -- henoheno
- とりあえず http://opensourcecms.com/ には登録の条件として「少なくとも英語にしろ」と明記してありますが、それに対して私は「ドキュメントだけ英訳すりゃいいやー」などとは思いません :) -- henoheno
- 冗長なコメントはない方がいいということはわかりますし、そのためのアプローチもわかりました。コードをまずは書いてみた時に書くコメントと、コードをメンテナンスしていく時のアプローチの仕方も違いますよね。
ただ、私も英語でコメントを書こうと試みたこともありましたが、母国語でない表記を使ってコメントを書くことに疑問を感じ（余計に何を言わんとしているのかわからなくなるコメントならば日本語でもいいのではないかと最近思っていたので)質問させていただきました。*12 -- jjyun
コメント†
- 国際化の道のりはそもそも遠いものですが、[[]]さんが目にしたものは、過去の努力の跡ですね。途中までで終わっているものも結構あります。 -- henoheno
- 過去のしがらみも含めて、一番詳しいまとめページはここです :) -- henoheno
- 僕がどこが大本のページ（まとめページ）かときいたのは、過去のしがらみに関してではなく、英訳ファイルに関してです。英訳者にとっては過去のしがらみはどうでもよく、どのファイルを訳せばいいか。どういうルールで記述すればいいのか。ということがわかればよいのです。さらに、dev にあるファイルよりも org にあるファイルのほうが内容がよさそうだったりするために、結局どうすればいいの？ということだったわけです。org の文書は１PukiWikiサイトの文書だといっていますが、その文書のほうがいいのであればそれを利用すべきですよね。いい文書なのですから。とはいえ、dev の文書をまるまる消しちゃう勇気は新参者にはないわけです。それに関する回答が得られていないのですが、とりあえず英訳者にとってのまとめサイトはdev:PukiWiki/1.4/添付文書でいいのですよね。 --
- 以前少し英訳の方お手伝いしましたが私もどこから手をつけていいものか困りました。英訳されなくてはいけない場所を小さく分けてbugtrack のエントリーみたいなものとして追っていくのはどうでしょうか？提案ー＞着手ー＞完成ー＞レビューー＞既存のコードへのマージ及びCVS への登録ー＞終了みたいなフローで。これだと集中管理できるので新しく入られる方も気軽に翻訳に参加できるのでは？ -- た
- orgのサーバーに余裕があるならもう一個翻訳用のPukiWikiを用意して、そこでやるとRSSとかで更新状況も追いやすくなりそうですね。 -- okkez
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
