Posted by mh35 on February 25, 2017 at 12:48pm
ユーザーガイドの日本語化を開始したいとおもいます。その際、以下のような手順が必要となります。
- 日本語チーム内においてユーザーガイド翻訳のマネージャーを1名以上選ぶ
- 1のマネージャーを主催者としたユーザーガイド翻訳用のユーザーグループを組織する
以上の内容はDutch translationから持ってきたものです。
つきましては、マネージャーを募集しますが、マネージャーになれる人はいらっしゃいますでしょうか？
よろしくお願い申し上げます。
Comments
Re:ユーザーガイドの日本語化について
はじめまして、kabetaniと申します。
ユーザーガイドの日本語化( https://www.drupal.org/project/user_guide )について興味があって調べ始めたところ、こちらの投稿を見つけました。
https://www.drupal.org/docs/user_guide_guidelines/pm-guide.html#pm-guide...
によると通常は既存のソフトウェア翻訳チーム( https://localize.drupal.org/translate/languages/ja )からメンバーを選ぶべきだろうみたいな記述をみかけたので、現在アクティブに翻訳活動をされている方か翻訳チームの管理者がマネージャーになると良いのではないかと思いました。
もしチームが構成されるのであれば、私もメンバーとして参加したいです。
(ただ作業単位ごとにissueを登録して作業するみたいなので中々大変そうですね。)
https://groups.drupal.org/node/515678
でs-jackさんも質問されていましたが、l.d.o/jaが翻訳作業の上位組織に位置づけられているようなので、現在のl.d.o/jaの状態をどなたか教えて頂けないでしょうか?
以上、宜しくお願い致します。
こんにちは。長年Drupalコミュニティを外から見ている者
こんにちは。長年Drupalコミュニティを外から見ている者として、管理者から返答が無いのを見かねて現状をお伝えします。
このJapan User Groupのオーガナイザーの方達や、localize.drupal.orgのマネージャーとして名を連ねてる人たちは、残念ながらこのようなオンライン上のDrupalに対する貢献活動はしていないのが実情です。その証拠に、このような権利が絡むスレッドには管理権限をもつ彼らが返信することはありません。
localize.drupal.orgの体制も全く不透明で、翻訳が承認される状況を見るとManager以外のメンバーも権限を持ってるいるようですが、誰が権限を持っていて、どこで議論されているかなんてどこにも書かれていません。完全にクローズドです。
日本のDrupalコミュニティは過去に権限や利権の絡みで様々ないざこざを起こしていて、それから健全ではない状態が十年以上も続いています。今の管理者達はいがみ合った人達から権限を奪取し、その後は放置しているだけの状態です。本当に残念ですが、Drupalコミュニティではあなた達のような有志がオンラインで活動していける体制や、議論できる場所が整っていないと言うのが答えです。
これは私情ですが、管理者が過去のいざこざで疲弊しているのもわかります。この体制が日本国内のDrupalの成長を妨げていることは明白なので、管理者の方達が責任をもって議論に参加するか、それができないのであれば、このようなオンラインで活動されたい方達に権限をバトンタッチされることを切に願います。
ご返信ありがとうございます
私は空き時間になにか貢献出来たら良いかという程度ですので、バトンタッチされるのは困ります。
管理体制の話しはさておき、現在の自分の関心事は「ユーザーガイドの日本語化について」なので、自分なりに解釈した大雑把な作業フローを共有させて頂きます。
(あまり細かく確認していないので間違いがあったらご指摘下さい。)
参考URL
https://groups.drupal.org/node/515698
3.1.5. Setting up for translations
この作業フローの2.の部分でdrupal coreの翻訳率が低すぎるからまずその部分を解決してから申請しろだとか、core翻訳チームメンバーの了解は得ているかなどの指摘が入り、申請が却下される事があるようです。
現状の問題点はcore翻訳チームメンバーの了解を得ているか突っ込まれる事なので、その点を解決出来ればとりあえずの障害はなさそうです。
(core翻訳チームの管理者の方がユーザーガイド翻訳の申請を行ってリーダーになって頂けるのが最も望ましいですが)
今更ユーザーガイドを翻訳する事に意味はないのかも知れないですが、ドキュメントワーキンググループがワークフローを確立する為に試験的にユーザーガイドで作業をしている側面もありそうなので、drupal.org内の日本語ドキュメントを充実させる為にも参加した方がよいプロジェクトなのではないかと思いました。
(かなり面倒そうな作業なので現実的に作業して頂ける方がいらっしゃるかどうかは不明ですが)
以上、長文失礼致しました。
賛同します
東京での何回か前のMeetupでもこの話題が出てましたが、私もユーザーガイドの翻訳プロジェクトは気になっていました。
日本語版もあったほうがよいと思いますので、賛同します。
私もkabetaniさんと同じで、空き時間に少しづつでも貢献したいです。
google翻訳
この投稿のひとつ前、昨年１２月のs-jack氏の投稿「翻訳ファイルの共有について 」の話も考慮すると良いのではないでしょうか。確かにgoogleの機械翻訳は強力です。
従来の段取りによる翻訳が進展することが最優先だと思いますが、日本のdrupalコミュニティーのマンパワーには限りがあります。人力翻訳の手が回りそうにないドキュメントを、英語が苦手な人たちの手で機械翻訳して、コミュニティーで共有できるのであれば、ありがたいです。
・本家がどう考えるか、
・APIで自動化できないか、
・Googleの有料サービスでどのような位置づけになるのか、
などなど考えるべきことが多すぎるのですが、とりあえず現段階で何ができるか、整理できるとよいと思います。
ご紹介いただき恐縮です（笑）みなさまこんにちは。私も議論
ご紹介いただき恐縮です（笑）
みなさまこんにちは。私も議論に参加させていただきます。
私はプログラマーではないのですが、翻訳くらいなら参加できると思い、昔ドキュメント整備の声をあげてみました。
Drupalは.orgに集約されている良い面もありますが、これが難しくしている部分もあろうと思います。
かなり昔にg.d.oの機能上でマニュアル整備をしようと、何人かの賛同を得てdocumentation-japaneseというグループを作ってみましたが、g.d.oの機能自体使い方が難しく、またD7のグループ機能（Organic Groupモジュールを使ってると思う）もイマイチで、頓挫しました。
sourceforge.netにもdrupal7をインストールして、.orgのドキュメント模倣を作ろう試しましたが、設定が難しく頓挫しました。
その後仕事が忙しくdrupalから離れていました。
.orgの翻訳チームで整備していくのは一番正統なんでしょうけど、なかなか承認など人員の交通整理のハードルが高いように思いますがいかがでしょうか。
別のサーバーを借りて（たしかKDDIさんがスポンサーしても良いよ）みたいなお話も当時チラリとあったので、別に作るのはいかがでしょう？
Confluenceのオープンソースコミュニティ向けプランを利用する手もあります、Saasでオープンソースプランがあるか調べてみないとわかりませんが。
drupalをインストールしてbookモジュールなどで公式マニュアルを模倣するよりも、wikiみたいな感じが良いかなと思っています。多言語対応しているD8だったらwikiでなくてもやりやすいのかもしれません。
仕事プライベート問わずある部分を翻訳した時に、ちょこっとだけでもシェアするくらいの気軽さで共同翻訳ができるのが良いのではないでしょうか？
.org上で正式にやるとなると結構本格的になっちゃうかなと、逆に本格的にやろうとしないから実現しないということもあるかもしれませんが（笑）。
機械翻訳であればAPIで自動化はgoogle translateやmicrosoft translateでできるかもしれませんが、オープンソースコミュニティの場合に費用がかからない仕組みがあるのかはまだ調べてないのでわかりません。
wikiで皆でちょこちょこ翻訳改変するのが良いと思いますがいかがでしょう？
それと私がプログラマーではないので、グループでは質問ばかりで技術的なフィードバックできないので歯がゆく生意気なことは言えませんが、ちょっとg.d.oやl.d.oはレスポンス悪いと思っています。
slackも立ち上がったようですが、どっちでコミュニケーションとって良いか結構迷います。
余談ですが、私はXOOPSというCMSのユーザーとして参加してましたが、コード中心の技術的ノリの中に入れず、クレクレ質問はお断りされた苦い経験があります。
オープンソースはコードだけでない部分の参加、マニュアル等もできるのとは思っていましたが、なんらかの情報をオンラインで共有する機能自体を作るにもやはりコードが中心なので、なかなか敷居が高かったです。
プログラマではない私が、プログラマーのある方に協力してもらい、当時は文字コードがEUC-JPだったのをUTF-8していただいた良き思い出があります。
話が脱線しましたが、マニュアルはコード技術者とは別に動けるくらいの軽い感覚が良いと思います。
APIマニュアルや技術的な箇所はコードの知識がなければやはり良い翻訳はできないですが、コード技術者も多数いますからそれは任せて、まったくの初心者でも参加できるくらいが良いかなと。
今はXOOPS時代よりもフリーの環境がかなり揃っているので、マニュアル翻訳くらい共同作業できる環境はいい加減作れるのではないかと思っています。
みなさんでどこかに方法を見つけ着地することを願っています。
追記です
アトラシアン - オープンソース プロジェクト ライセンス申請でクラウド製品も使わせてもらえそうですね、JIRA,Confluenceなど詳しい方いらっしゃいませんか、どうでしょう？
license violationに気をつけましょう
ne-yoといいます。
ほとんどのmachine translationのEULAはCC-BY-SA incompatibleです。
安易な流用はlicense violationになります。
今年Ubuntu方面を端緒に大規模なrevertを要する事態が起きました。
参考:
https://www65.atwiki.jp/shiga_keiichi/
Software Design 2017年6月号 Ubuntu Monthly Report【86】Ubuntuの方針転換とWeb翻訳混入事件
@ne-yoさん、貴重なリソースありがとうございます。 機
@ne-yoさん、貴重なリソースありがとうございます。
機械翻訳自体のEULAが、DrupalのドキュメントコンテンツのCC-BY-SAを許さないということであってますでしょうか？
Drupalは TMGMTやLingotekのモジュールもあり、機械翻訳もできます。
DrupalのUI、コンテンツその他の翻訳対応リソースの、翻訳ができます。
どういうケースで問題となるのか、一度整理しないといけないですね。
知識がありましたらぜひよろしくお願いします。
問題となり得る場合
machine translationのEULAは、そのoutputは私的利用に限っているのが普通と思います。
例えば『後で少しずつ直していくために、とりあえずmachine translationのoutputを貼って公開状態におく』等は私的利用の範囲を超えEULA違反となるでしょう。
アクセス者が実行主体となるwebsite translationなら各アクセス者の私的利用ですが、そこで表示される訳文の利用範囲はEULAの制約を受けます。
また、machine translationの著作者がoutputの著作権を持つ可能性があります(原文とcorpusからの二次的著作物として)。その場合EULA内でCC-BY-SA compatibleが明示されない限り著作権的にもNGとなります。
ただしこの著作権については否定的な見解も多く、現状灰色と思います。
Wikipediaでは記事更新履歴の途中に著作権侵害が発覚すると、著作権侵害以降の版を全削除という対応でした。以降の版は全部著作権侵害版の二次的著作物と見なされるためです。
灰色はあらかじめ排除しておかないと、将来問題となるかもしれません。
wikipediaの事例も含めありがとうございます。まだ
wikipediaの事例も含めありがとうございます。
まだ整理できていませんがなんとなくわかってきました。
wikipediaで著作県侵害があって該当する版を削除というのは、「翻訳」に関するものなんでしょうか？
ご存知でしたら教えてください。
翻訳でない新規記事の更新での著作権違反とは分けて考える必要があると思っています。
著作権の中でも「翻訳」での著作権がちょっとややこしいですね。
そして機械翻訳については、Lingotek含め翻訳フローを調べて理解していることは、
1)まず機械翻訳が利用できますよ！（1から人力翻訳するよりもとても便利です）
2)そして精度を上げると人力翻訳を数ステップいかがですか？
というワークフローになってしっかり提案されています。
機械翻訳をしない従来型の人力翻訳であれば、機械翻訳が登場する以前の著作権の取り扱いでシンプルですが、
機械翻訳・人力翻訳ミックスの場合、理屈っぽいけどややこしいなと思っています。
機械翻訳のEULAをじっくり読んだことないので、読んでみないとダメですねw
元の著作物がCC-BY-SA compatibleなら、機械翻訳してもCC-BY-SA compatibleであれば万事OKなんですが。。。
翻訳成果物がCC-BY-SA compatible明示されればOKということを前提とすると、機械翻訳ではCC-BY-SA compatibleの成果物は作成できませんよということにもなります。
機械翻訳自体を利用する規約EULAと、利用してできる成果物の権利や決まりは別物のような気もしますが、機械翻訳が翻訳者という扱いであれば、翻訳に関する権利も機械（機械翻訳を提供しているプロバイダ）に発生しているのかもしれません。
なかなか良いテーマですが、難しいw
https://ja.wikipedia.org/wiki
https://ja.wikipedia.org/wiki/Wikipedia:井戸端/subj/Google翻訳者ツールキットについて
に議論されていたのでシェアします。
だいぶ日が経ってますがその後の進展はまだわかりません。
著作権は難しい・・・
ne-yoさん
ご指摘、ありがとうございます。ライセンスの問題は難しいですね。
drupal.orgが機械翻訳を取り入れれば（例えばgoogle ウェブサイト翻訳ツール を組み込めば）、一気に１００か国語以上の機械翻訳を表示することが可能になるわけで・・・・・ご本家が何もしないのにはそれなりの理由があるのでしょう。今はグレーゾーンに立ち入らないほうがよいのですね。
ただ、進化して利用価値が上がったツールを使はないのはもったいない話です。
いつかは機械翻訳に関するルールが整備されて、積極的に利用されるのが当たり前の時代が来ると思います。いつになりますかね・・・
皆様いろいろなご意見ありがとうございます
To: ken_taguchiさん
ご賛同ありがとうございます。かなり無理そうなプロジェクトで、提案を取り下げようかと思っていたので勇気づけられました。
To: musashi.hamuraさん
機械翻訳を使うかどうかは、実際に翻訳作業を行う事になった段階でまた議論するという事にしませんか?
To: s-jackさん
個人的な意見ですが、翻訳の途中過程で別サイトで使うのは問題ないと思いますが、以下の理由から最終的にはdrupal.orgにコミットする方が良いのではないかと思っております。
issueに作業開始を申請してから2週間以内に作業を終えなければいけないですとか、その他drupal.orgの既存ルールに従うことによって新たな作業手順を作成する手間が省ける(不自由な面もあるので、欠点にもなりえますが)。
誰かが作業出来なくなってもdrupal.orgが存在している限り別の人が作業を継続できる。
翻訳した結果が個人の貢献としてプロフィールのコミット履歴に残るので、作業する人のモチベーションアップにつながる。
翻訳を登録していくだけで最終的にhtml,pdf,epubで出力される既存の仕組みが利用できる。
ちなみに信用の蓄積に関連しますが、マネージャー(コーディネーター)の名前は最終的な出力結果であるユーザーガイドのpdf,epubに出力されますので、ユーザーガイドがダウンロードされて多くの人の目に触れる事を考えると、マネージャーにとってかなりメリットのあるプロジェクトなのではないかと思います。
「l.d.oでxxxx件の翻訳実績のあるxxxxです」と説明して申請した方が申請の許可がスムーズにいくようなので、どなたかl.d.oで翻訳活動をしている方でマネージャーになって頂ける方はいらっしゃらないでしょうか?
@kabetaniさん、なるほどです。 drupal.or
@kabetaniさん、なるほどです。
drupal.orgに管理してもらうのが、今までの経緯から一番良さそうですね。
それが基本ですし、きちんと動き出せれば別サイトや管理する必要はそもそもないわけでw
まずはそこをトライしてみましょうか。。。
コードのissueとかbugの上げ方も詳しくわからないのですが、ドキュメントやその翻訳も同じスキームでということでよいのでしょうか？
コードのissueとかbugの上げ方から要約して教えていただけると助かるのですが。
（これできる人結構少ないと思いますし、これできるとドキュメントに限らずコードについてもリクエストする人増えそうです）
まずはそのへんのドキュメントを翻訳しろってことですかねw
別サイトの魅力
少し書き忘れたので別サイトの魅力についてちょっとだけ考えていたことを書いてみます。
大きく分けて２つにマニュアルを分けます。
＊ .orgドキュメントの翻訳を忠実に目指すもの
＊ ユーザー自身（これも共同編集可）のオリジナルなドキュメント
後者の方は、肉付けしたり、別の視点で説明したりといったものをまとめます。
qiitaみたいなものでしょうか、自分で調べたオリジナルなマニュアルだよとか、非公式だけど捕捉するよとかです。
翻訳の厄介なところは、
.orgのドキュメントの翻訳をするということは、
翻訳元ドキュメントが不完全なとき、その元自体を作ってからでないと翻訳ができないことです。
つまり、.orgの英語のドキュメントの作成に参加しなければならない、もしくは完成を待たなければならないということになるでしょう。
英語のドキュメントを見回す限り、D8もやっと固まってきてるところですが、コントリビュートモジュールもまだリリースされていないものもたくさんあり、Out of Dateやincompleteのマニュアルも結構見受けられます。
なので、忠実を目指す部分と、独自に作っちゃえ部分が２つあって、相互にバランスすると良いかなと思いました。
了解です
上でgoogle翻訳ファイルの共有の件を引っ張り出したものです。レスが遅れました。
Googleの機能でいろいろなことができるようですね。そのような訳で、この話は後回しでよいと思います。
issueやbugの上げ方
ユーザーガイドはドキュメントなのですが、現状はモジュールと同様にissueを使って既存ファイルにパッチを当てる形で変更管理をしているようです。
パッチの作成方法についてはGotoさんが作成してくださった "Git を使った Drupal パッチの作成 日本語訳" の記事がとても参考になります(勝手に引用してすみません)。
私自身モジュールのコミット経験はあるもののissueの使い方は素人なので色々試行錯誤になると思いますが、実際に作業を進める事になりましたら作業手順をどこかにまとめたいと思います。
別サイトを作成するのは簡単なのですが、長年に渡り維持管理していく事が困難なので出来れば既存の仕組みの中でやりくりしたいです。
drupal.orgの新しいドキュメントシステムはマルチリンガルに対応していますし、そう遠くない内にdrupa.orgで気軽に日本語ドキュメントを作成したりドキュメントの翻訳を出来るようになる気がするので、ひとまずはs-jackさんが管理者となっていらっしゃる https://groups.drupal.org/documentation-japanese で作業の情報共有をするというのはどうでしょうか?
【追記】ちょっと分かりづらかったので補足させて頂きます。
新しいdrupal.orgのドキュメントシステムは、新規にドキュメントを作成する際に言語を選択出来ます。ですので、マルチリンガルの表示設定がきちんとされれば、将来的には最初から日本語ドキュメントを追加する事が許される可能性もあるという事をお伝えしたかったです。
色々とご教示どもです。 別サイトを作成するのは簡単なのです
色々とご教示どもです。
documentation-japaneseを作ったときに、そう遠くない内にドキュメント作成と翻訳ができると思っていたけど、今日に至りますw
翻訳対応したみたいですが、Wappalyzerで調べるとD7ですね。そろそろドキュメント系はD8西t毛売れると良いのですが。
documentation-japaneseで作業の情報共有まったく問題ないですが、使いにくいですよ！（グループ機能を熟知してない私だけかなw）
kabetaniさんメンバーになっていただいてますね、管理者権限振るので、グループ自体の使い方自体いじってみてください。
むむむ、新規のドキュメントも日本語からコミットしていくということですか、正当論法で！
それが出来ると良いんですが、l.d.o等他の活躍者を管理者する云々とかにならないと良いのですが。
既存のものを翻訳するのと、新規に日本語ドキュメントを作成するのはかなり世界が異なりそうと想像します。
新規に作成すると、日本語以外の方は新規の日本語ドキュメントを元に翻訳していくように思います。
最初の言語のマニュアルが日本語のとき、その日本語自体の内容を精査され、修正するときには日本語でまず完成させなければなりません。
まだないドキュメントを新規でつくるときは、かならず英語を作ってから！という雰囲気にならないか心配です。
いずれにしても.org上で行うということは、翻訳もそうですが、ドキュメントの新規作成も.org的に公式になりますね。
色々と試してどんどん変えていきましょう。
documentation-japanese
そうだったんですね。じゃあまだまだ遠い道のりかも。。
documentation-japaneseの管理者の設定ありがとうございます。
もしユーザーガイド翻訳の作業を開始する事になったら色々試してみます。
誰かが説得力のある根拠を元に要望を出さないと、普通にそのような運用になる気がします。
Doc/WG ではCommunity Documentation だけをターゲットにしているようで、モジュールやテーマの
ドキュメントの運用についてはどこで議論しているかちょっとわかりませんでした。
もしどこかで見つけたら報告させて頂きます。
ユーザーガイド日本語翻訳の開始を申請をしました
ユーザーガイド日本語翻訳の開始を以下の通り申請しました。
Set Up JA translation
ドキュメント翻訳作業についてはこちらのグループより
https://groups.drupal.org/documentation-japanese
のグループの方が活動趣旨が近いと思いますので、今後の進捗状況はそちらで報告させて頂きます。
管理者になって頂ける方、翻訳作業のお手伝いをして頂ける方を絶賛募集中ですので、もしご興味のある方は、ぜひ https://groups.drupal.org/documentation-japanese にグループ登録をお願いします。
@kabetaniさん、ご苦労様です。 さっそくGoogl
@kabetaniさん、ご苦労様です。
さっそくGoogle translateで申請内容を翻訳してみますw
それにしても英語力すごいですね。
申請内容を翻訳して読んでみましたが、内容がさっぱり理解でき
申請内容を翻訳して読んでみましたが、内容がさっぱり理解できません（私に技術的な知識が欠乏しているため）
申請結果が得られ、お手すきの時間で構わないので、documentation-japaneseにスレッドを立てていただきどういうスキームか説明していただけると助かります。
お手数ですがよろしくお願いします。
ご協力ありがとうございます
いえ、ほとんどテンプレですし、自分で書いた所は後からみたら文法が間違っているし、メチャクチャです。
英文を読むこと位は頑張れば出来ますが、ライティングもスピーキングも全く駄目なので英語に堪能な方のご参加をお待ちしております。
はい、その内記載します。
s-jackさん及びdocumentation-japaneseの管理人の皆様へ
真に勝手ながら
https://groups.drupal.org/documentation-japanese
の構成をガッツリ変更してしまいました。
旧コンテンツは非表示にしただけで1件も削除は行っていないので、必要であれば元の状態にいつでも戻せます。
もしまずい点がありましたら適当に変更して下さるようお願い致します。
以上、宜しくお願い致します。
@kabetaniさん 以前dokumoriさんから古いコ
@kabetaniさん
以前dokumoriさんから古いコンテンツはユーザーの混乱を招くため非表示にするよう提案されておりベストな行動だと思います、了解です。
なお、documentation-japaneseグループのディスカッションカテゴリを適宜ご活用いただけると嬉しいです。
以後宜しくお願いいたします。
ディスカッションカテゴリ
はい、承知しました。
s-jackさんも適宜カテゴリを追加/編集して下さい。
こちらのスレッドはもう長くなりすぎていますので、追加の議論は
documentation-japaneseグループのディスカッションでお願いします。
その後の進捗ですが、無事JA Translationの申請が認められてdev版にjaディレクトリが追加されました。
以下のファイルをダウンロードすると確認出来ます。
https://ftp.drupal.org/files/projects/user_guide-8.x-3.x-dev.tar.gz
翻訳の開始までにまだいくつかの下準備が必要なのですが、ちょっと時間がとれないので、申し訳ありませんが気長にお待ち下さい。