Posted by xbro on June 12, 2010 at 7:00am
ざっと、いろいろ今週ページ構成を進めていきましたが、何か問題点や提案があればご指摘よろしくお願いします。もちろん他のアドミンの開発や翻訳でのご賛同もご期待しています。
一応現時点、どんどんdrupal.org/handbookをこのグループのwikiにhtmlごと取り込んでそこからグループメンバーが日本語版の翻訳を同じwikiから始められるような感じでイメージしてます。
その中で今挙がってる方法は：
-
drupal.org/handbookをこのグループのwikiにhtmlごと取り込むのはこのdoc-jpグループのアドミンを中心に、アドミンで共同管理する予定のdoc-jp@drupal.orgを中心（統一性と個人色をwikiから消すため独占的にという手もあります？検討中？）に、一連の各自グループwikiへのリンクで繋がってるdrupal.org/handbook（英）wiki版ミラーみたいなアーカイブをグループ内で作成していく。
-
最初は上記の1.が先行してほとんどのページが英語内容であるが、メンバーがwikiに立ちより、それぞれ自分のエディタや3rdPartyツールなどを使用して翻訳作業を実行していき、いずれ日本語中心のdrupal.org/handbookコンテンツがこのグループで掲載されるようになる。
という感じで考えていますが、これで宜しいでしょうか？
まだまだ brainStormの段階なのでガラッと変わっても良いですし、今あるページは私が思いついたやり方に過ぎませんが、これ以外の方法があるかというと今のところ私は思い付きません。
Feedbackをお待ちしています。
スコット
p.s. 他に話す事があればどんどんディスカッションを作成するべきだと思います。
Comments
すみません、再びHOMEを３カラム案にしてみました。 ・デ
すみません、再びHOMEを３カラム案にしてみました。
・デザインについて
drupal.org/handbookのページ構成ですが、
左１ Getting Started
左２ Quick links
左３ Handbook license
右１ ハンドブック本文
右２ 前のページ、次のページ等ナビゲーション
完璧にはできるかわからないけど、なるべく模倣するほうが分かりやすいと思いまして。
・wikiページのタイトル名について
wikiは[[]]タグでページタイトルでのリンク付けできる機能が特徴と思います。
handbookのページ名は、このwikiでどんどん作っていけるように、ページ名を合わせることで編集ページに進めます。
よって、グループ共通アカウントでひと通りハンドブックを作っていくことは、管理に手間がかかり、やはり反対です。
このwikiの機能によって各ユーザーが手軽にページを作成できること、これが多くの参加ユーザーが手軽にページを作っていける最大の特徴ではないかと思います。
・共通アカウントの管理について
共通アカウントでのwiki作成の検討で、アカウントの作成と管理について、fujiさんに音頭取りをお願いしましたが、
管理の煩わしさで私は反対です。その理由は、共通アカウントに登録されたメールアドレスで連絡貰いましたので、返信をしていますので確認してみてください。
ハンドブックのページをだーっとつくっちゃおうということですが、その後この作業を担いたいと手をあげられる方が表れた場合、共通アカウントをどのように管理されますか？
このグループもメンバー７人になっています。
現メンバーにおいても共通アカウントをどうやって共有しますか？
この辺がfujiさんでも煩わしいと思うのであれば、使用を止め、各ユーザでページをどんどん作ることをお勧めしたいと思います。
私はテンプレート的表組みで印象を避けられると思っていますので、共通アカウントの管理は引き継ぎたくありません。
誰にあげて誰にあげないとか管理したくないです。
多くのページを作った方が、アバター表示されるのは仕方がないと思っています。
re: feedback
3コラム：私は普段画面の小さいラブトップを使用してるので3コラムだとかなり無理出ますが、大きい画面だと現時点のコンテンツで正常に見えるのですか？私は前回のフォーマットを好みます、理由は翻訳作業の実りである翻訳wikiがメインコンテンツであるからです（一応意見を言っときますが、検討していきましょう）。
”・wikiページのタイトル名について、wikiは[[]]タグでページタイトルでのリンク付けできる機能が特徴と思います。”
これについては知りませんでしたが便利ですね。
確かに共通アカウントから翻訳のwikiを一通り作るのは手間がかかります。
共通アカウント管理に関しては登録されたアカウントのメールをチェックしましたが、通常とメールが変わらないように見えあまり不便に感じませんが、連絡が来たというのはちょっと確認出来ないのですが？確かに来たら返事するのは面倒だとは思います、あまり確認する予定もないので。
共通アカウントは基本的にアドミンのみという対象で考えていますが、故に誰にあげて誰にあげないという意味ではアドミンになるならないとさほど変わりないです。
私の考えは作業をしていく後変わるかもしれませんが、今のところ自分のアバターをガイドブックのコンテンツに表示されるのは抵抗あります。理由はガイドブックが読む側からして他のメンバー個人のアイデンティティーなどどうでも良いぐらい一般的な情報であり、そうであるべきだからと考えています。こういうgeneralな情報にsignatureを入れるのに抵抗があるのです、みんなのコンテンツであり、元もそうなので。そうでない人達は遠慮なく自分のアカウントから作成しても結構だと思います、オープンソース的な考え方としては。
よって、私はdoc-jp@drupal.orgでコンテンツを作成し、他に共有したいアドミンがいれば共有していくという形で良いですか（よって今は私一人で管理して、共有要請をアドミンから待つ）？自分のアカウントからwikiを作成するのもありで両方ありで公平ではないでしょうか？でも、一応述べますが、いずれwikiをdoc-jp＠drupal.orgで統一する時が来たようであれば、それを提案するかもしれません（そんな時が来たときは喜ぶべき将来なのでしょうが）、逆もあるかもしれません。
3コラム：私は普段画面の小さいラブトップを使用してるので3
おっしゃるとおり、小さい画面でご利用の方は、厳しいですね。
私は２４インチワイドで利用していますので、そこまで気がつきませんでした。３カラムは見づらいですね、同感です。
ここの管理者、オーガナイザーといいいますね、複数人なれますし、抜けることも容易ですので、メールアカウントの管理はちょっと違うと思っています。
しかし、
了解です、fujiさんは主に共通アカウントをどんどん利用してください。またどなたにあげてもＯＫです。
（以前あったdokumori,aiwataさんへは私はまだ教えていませんので、共通アカウントをご希望の場合はfujiさんへ連絡してみてください、他の方もfujiさんへご連絡をお願いします）
私は自アカウントでやってみます。
統一する時があれば、その時に協力させていただきます。
・デザインについて 翻訳記事がグループホームで表示されるの
・デザインについて
翻訳記事がグループホームで表示されるのに抵抗があるのは僕だけでしょうか・・・
僕自身、d.o本家でもほとんどAPIしか見ないのですが、それでも膨大な量になると思いますし、
そうなると、翻訳後も翻訳中もナビゲーションがかなり重要になると思いますので、
どこかに、ドキュメントツリーを表示しておくのが良いのでは？と思います。
管理者の方がメニューをいじれるのならメニューで、いじれないならwikiでも良いかと思います。
stackedのパネルなら、上にポリシーやライセンス
左カラムに、ドキュメントツリー
右カラムにディスカッションや活発な翻訳ページなど。。
というのがすっきりして見やすいかと思います。
・wikiページのタイトル名について
wikiの機能ってかなり便利だと思うんですが、
もし、d.o本家で多言語がサポートされたとき、移行作業がかなり面倒な事にならないでしょうか？
アンカーはいじらないか、どうしてもリンクを生かせたい場合は、どこか別にサイトを立ち上げた方が楽なのではないかと思います
・共通アカウントの管理について
とりあえず、すいません。自分の関心のあるところを訳しているもので、
FieldAPIを訳しているのですが、アップしてもいいのでしょうか・・・・・
・デザインについて 翻訳記事がグループホームで表示されるの
ナビゲーションの作り方に今困っています。
APIを弄っているということで、kykさんは結構詳しそうなので、管理者権限振っておきますので、良い案をお願いします。
そしてアップしていただいてＯＫです。
ちょっと私の理解ミスなのかもしれませんが、
[[]]リンクで飛ぶ・新たに作成される（できる）のは、これも日本語マニュアルタイトルがついたページなので、
お互いに原マニュアル、日本語訳マニュアル、ブック階層が一緒ならば、
d.oが多言語になっても問題なさそうだと思いますがどうでしょう。
全階層の翻訳ページにd.o/handbookの参照先を貼っておけば良いと思います。
ナビゲーションの作り方に今困っています。 APIを弄ってい
やや＾＾；
でも、それらしい（管理系の）リンクが見あたらないのですが、こういう物なのでしょうか。。
仰る通りです
思えば多言語サイト作った経験がないもので、その辺の仕組みをあまり理解していませんでした。
仮にサイトに言語切替機能つけた場合、ノード間のリンクはどういうふうになるんでしょう？・・・
わかりました
pagesというのが、管理パネルの部分でしたか。
これってviewsの設定までは出来ないかと思われます
APIなど別カテゴリのコンテンツ：
handbookのコンテンツがメインなのに違和感があるというのは興味深い意見に感じます。
APIなど他に翻訳できる、handbookとは別カテゴリのdocumentationってdrupal.orgにいくつかあるのですね。
参考にまでhandbook以外の別カテゴリでdrupal.orgでリンク集としてのdocumentationをご存知であればここにリストアップお願いできますか。
API以外に複数あるようであれば、これらをコンテンツ・ナビ・リンクとしてホームページで管理して、リンク先から翻訳（ホームページがhandbook直結ではなく）を検討しても良いと思います。（そうであればリンク集の幅はさほどではないので3コラムも実現できると思います）
とりあえず今挙がってるdocumentationは：
1. handbook
2. API
他にありますか？
宜しくお願いします。
p.s. (他にいっぱいdocumentationがあるようであれば、一カテゴリにつき一ホームページタブを作るのは避けるべきかもしれません)
d.oを色々と眺めて思っていることですが、 drupalっ
d.oを色々と眺めて思っていることですが、
drupalって、基本nodeになっていて、bookモジュールってどのコンテンツタイプにも階層を提供する。
そしてURLエイリアスで適当なアドレスを振ることができる。
つまり、どんなマニュアルであれ、１つのノードの集まりで、
kykさんが翻訳を目指しているfieldAPIは、d.o/handbookを入り口としても紹介Writing your own code＞API Referenceしているが、api.d.oというサブドメインを振っているにすぎない
私が翻訳を目指しているintarnationalizatioanは、多分i18nモジュールのハンドブックだけど、d.o/handbookのCreating a site＞Structure Guideに分類されていて、URLエイリアスはとくに振ってなく、単にノードのhttp://drupal.org/node/133977アドレスでアクセスできる
d.o/handbookのtopページ自体も１つのnodeでエイリアスを振っているにすぎない。
多言語された場合はちょっと異なるとは思います、異なる日本語nodeと英語nodeをひも付けするのではなく（そういうモジュールもありますね）、1つのnodeの中に日本語fieldと英語fieldを所持するような仕組みになる。
d.oがいまのところ多言語化しない以上、どんな言語であろうとも、ほぼすべて単独のnodeだと想像できます。
book階層、リンクであっても、この単独nodeにエイリアスを振る振らないの違いで、関連付けて記載しているにすぎないと思います。
bookモジュールがなくたって、内部リンク付けでどうになできる（モジュールはこのナビゲーションを自動化するにすぎない）。
よって、
極力似たような内部リンクを貼るwikiを作っていって、これは先頭から作る必要はなく、FieldAPIやinternationalizationなどを完結したら、これをまた整理しているハンドブックも似たように作り内部リンクで紐付けする、というふうに、どこから作っていっても関連付けられるのが、nodeとwikiの良さなのかもしれません。
追記：
多分この辺（エイリアスありなし、サブドメインに配置していたり）を色々と整理しようということで、doc.d.oにという発想がうまれているのではないかなあ？
そうか、特殊なのってAPIだけなんですね。 APIのドキュ
そうか、特殊なのってAPIだけなんですね。
APIのドキュメントってたしかソースコードから自動生成しているので、
他のドキュメントとは、切り離して考える必要があるようです。
（ツリーというよりも、ページ間リンクが以上に多いので）
出来ればもとのパスに、/jaを含めたリンクにするのが理想かなと思ってますが、
g.d.oでは無理なので、wikiシンタックスを使ってあとから正規表現で変換出来るようなものにするとかはどうでしょうか
フィールドAPI/api/group/field/7
みたいな。
意外にもそのままリンクがとおるようです。
表記 [[フィールドAPI/api/group/field/7]]