モンサント、不当なロイヤルティの徴収に対する違法判決下る!

モンサントはアルゼンチンの経済混乱につけ込んで入り込み、ブラジルやパラグアイなど遺伝子組み換えを認めていない国にも強引に入り込んで、わずか数年のうちに南米を遺伝子組み換えの国にしてしまった(モンサント、ブラジルの遺伝子組み換え大豆「開国」の手口 日刊ベリタ参照)

圧倒的多数の市民が反対しているにも関わらず、民主的プロセスを経ることなく、遺伝子組み換えは強引に合法化されたのだった。合法化以降はモンサントや他の遺伝子組み換え企業は政府に圧力をかけ、よりいっそうの遺伝子組み換え種の承認を計っている。この間にブラジルは世界一位の農薬使用国になってしまった。

モンサントのビジネスモデルは種子の供給を独占し、非遺伝子組み換え種子を可能な限り排除し、種子と農薬をセットで売りつけ、農業生産を支配し、独占的な利益を得るというものだ。モンサントの開発した種子から出た花粉で汚染された有機農家が被害を受けたにも関わらず、勝手にモンサントの種子を盗んだとして訴えられ、莫大な訴訟費用の前に廃業に追い込まれるケースが報告されているが、モンサントはその開発した種子の特許、知的所有権を武器に広大な地域に影響力を急速に及ぼすようになった(もっともその影響を与えている地域は世界全体で見るとわずか1割程度であり、南北米大陸にそれは集中している)。

しかし、そのビジネスモデルを正面から否定する判決が南米の遺伝子組み換え王国のブラジルで下った。

モンサントの遺伝子組み換え大豆のロイヤルティ、技術料、補償金の徴収を違法として、その徴収を禁止するというものだ。さらに本格的に(非合法下に)耕作が始まった2003年からの課金の返却までをも命じるものであり、モンサントのビジネスモデルを揺るがす内容を持っている。

ブラジルでは2003年以来、左派の労働者党政権が成立したが、農村地域においては大土地所有者の政治力は依然として強く、ルラ政権は大土地所有者への譲歩を続けた。世界的にも土地所有に極端な不平等のあるブラジルでは農地改革は長く社会の大きな課題であった。しかし、モンサントの登場と共に逆農地改革ともいうべき、土地を貧しい農民に分配するのではなく、大土地所有者への土地のさらなる集中が起きた。

多国籍アグリビジネスとブラジルの大土地所有者との連携の下、遺伝子組み換え大豆の生産は飛躍的に伸びた。しかし、同時に大豆生産農家とモンサントの間に不協和音も聞こえるようになってきた。今回の訴訟はその不協和音が確定的なまでに大きなものになっていることを物語っているように思える。

モンサントの政治力は未だに健在と思われる。この判決はすぐに覆される可能性は高いだろう。しかし、この遺伝子組み換え王国、米国につぐモンサント王国と思われたブラジルにこのような判決が出たことの意味は決して消すことはできないと思われる。

以下はブラジルでの記事の抄訳である。(Justiça condena Monsanto por cobrança indevida de royalties 裁判所、モンサントの不当なロイヤルティの請求に有罪判決

モンサント、遺伝子組み換え種子の特許料の徴収に違法判決下る!

ポルトアレグレ ポルトアレグレ地区第15民事法廷のジョバンニ・コンチ判事はモンサントによる遺伝子組み換え大豆へのロイヤルティを課すことを違法として、即刻停止することを命じた。この決定はパッソ・フンド地方組合、セルトン地方組合、サンチアゴ地方組合、ジルア地方組合、アーボレジンニャ地方組合、リオグランジドスル州農業労働者連合(FETAG)によるブラジル・モンサント社およびモンサント・テクノロジー社に対する集団訴訟に応じるものである。

4月4日に発表されたその決定において、小、中、大規模の大豆農家が2012年9月1日からロイヤルティ、技術料を払ったり、補償金を払うことなく、遺伝子組み換え大豆を保存し、再び畑に植え、その収穫物を食料として、あるいは原料として売る権利があることを判事は認めた。コンチはまた2010年9月1日から遺伝子組み換えを育てる生産者が他の小農民たちに保存してある種を譲ったり、交換したりする権利を認めた。

それだけでなく、2003年/2004年収穫から遺伝子組み換え大豆の売買に対してロイヤルティ、技術料、補償金をモンサントが課すことを禁止した。また判事は2003年/2004年収穫から遺伝子組み換え大豆生産へのモンサントによる課金を市場総合物価指数で補正し、月1%の利子を加えた上に返還するよう命令した。

ジョバンニ・コンチは日ごとに100万レアルの罰金支払いを条件に、ロイヤルティ、技術料、補償金請求の即刻禁止の差し止めを認めた。また両社は50万レアルの訴訟費用の全額の支払いを命じられた。

ブラジルの森林、 先住民族と日本

A SEED Japan グリーン主流化セミナー ブラジルの森林とわたしたちの生活 で現在のブラジルが抱える問題と日本の関わりについて話をさせていただいた。

身近な次元で何が可能かということまで落とし込んで、話題を提供すべきだったのだけど、ブラジルの問題を包括的にまとめ出すとその現実の厳しさに引きずられてしまって、現実を語ることに終始してしまったと反省している。

もちろん、身近な次元でできることはあるし、それを討論していくためにはさらに1時間くらい必要だったのかもしれない。

たとえば遺伝子組み換えの問題。
南米を浸食している遺伝子組み換え大豆は、社会を蝕み、環境を蝕み、人の健康を蝕んでいる。これをブラジル人社会の側だけで変えようと思っても非常に困難。買い手がいっぱいいる以上、さらなる拡大を防ぐことは難しい。その遺伝子組み換えは北での家畜の餌やバイオ燃料になっている。日本の商社もどんどん輸入を拡大している。

遺伝子組み換え大豆で育った家畜の肉は実際に危険であると思う。カナダで遺伝子組み換えの飼料で育った肉を食べた妊娠中の女性93%の血液からBt 毒物(Cry1Ab)という遺伝子組み換え作物が作り出す殺虫性の毒が検出されたという研究が昨年発表されている。この場合はBt遺伝子組み換えトウモロコシのケース(Bt toxin found in human blood is not harmless)。

害虫には毒となるタンパクを作るように組み替えられたものなのだが、人間の腸では破壊されてしまい、体外に排出されるから安全と説明されていた。遺伝子組み換え大豆の場合にも残留除草剤の影響に関する懸念は高まっている。そうした肉を食べることは食べる側の健康被害の可能性を拡大し、さらに南北米大陸での遺伝子組み換え穀物の生産を支えることになる。

どうせ肉を食べるなら安全な飼料を使っている肉にすべきだし、遺伝子組み換え飼料の市場にブレーキをかけない限り、遺伝子組み換え作物の耕作の拡大を止めることは難しい。だから十分に意味のある試みになる。

そうしたことをやっていくことも森林を守る取り組みの1つだと思う。

さらにブラジル現地に行けば、魅力のある運動をやっている人たちに直接会うことができる。そうした人たちとつながっていくことで個々ばらばらであれば不可能な新しい社会を作る道が見つかるだろうと信じている。

Rio+20の機会を活用して、そうした可能性をぜひ見つけてきてほしい。

行けない人(自分も含め)にもどんな可能性があるか、これから模索していきたいと思う。

オープンソースのアクセス解析Piwik

これまでプライバシー・ポリシーとは団体・組織が取り扱う個人情報をどう会員や顧客に不利益を与えない形で処理するかを定めておけばよかったかもしれない。その対象は送られてくる質問、メールや電話、FAX、注文データなどの取り扱いをしっかりしておくということ。厳密に言えば当然Webのアクセス記録やメールのやりとりを記録したサーバーログもそこに入るが、しっかりと運用していれば外部に漏れることはないものだった。

しかし、インターネット上の急激な認証化の動き(具体的にはFacebookやGoogleなどが実名での登録を要求し、その登録規模がかつてないほどの大きなものになったこと)に伴って、その対応も変えざるをえなくなってきている。

たとえば、Webアクセス解析はGoogle Analyticsなどのサービスを使っていれば、誰がどのページを見ている、という情報は自社内で管理はできずに、Google上で把握されてしまう。本来、誰が見ているという情報の部分は追わないというのがあるべきプライバシー・ポリシーであったはずだが、GoogleアカウントやFacebookアカウントと結びつけられることで把握されてしまう可能性は飛躍的に高まっている。

それ以上にFacebookなどとWebサイトを結びつけると逆にこのサイトを支持する、という形で自らを晒していく動きが大きくなっている。これは自分の意志でやっていくわけであり、積極的にこうした人たちと結びついていくことで、その組織の存在が身近に感じられるという効果もあり、今後の大きなトレンドになっていくだろう。正の側面が語られることが多いが、負の側面がないかどうか、今後の議論には十分注目する必要があるだろう。

一方、Google Analyticsなどによって、本人が知らない間に閲覧記録が取られてしまうという問題は検討すべき課題として大きくなっている。

Google Analyticsは無料で提供され、その機能も高く、さまざまなガイドブックも売られているので、トレーニングの負荷も低く、多くの団体で使われている。ユーザーの側でGoogleにアクセス記録を取られないように防御する方法がないわけではないが、基本的にほぼすべての人のアクセス記録はGoogleのデータとして保存される。

これに関してはオープンソースのアクセス解析を使うことで解決することは可能だ。オープンソースのアクセス解析のPiwikは直感的にわかりやすいインターフェースで完成度も高い。しかも、訪問者のオプトアウトも確保しているなど、プライバシーに関する配慮も高い。

問題としてはGoogle Analyticsは日々システムが更新され、新しくなっていくのに対して、オープンソースのシステムは管理者がアップデートしない限り、更新されないこと。またGoogleと基本は同じなので、知っている人にとってはトレーニング不要だけど初心者向けのマニュアルがあるわけではないこと。しかし、後者の問題はPiwikのインターフェースが直感的に理解可能で、Googleのものとほぼ同様に使えるという点で、大きな問題ではない。

プライバシー概念が大きく変わっている中、あるべきプライバシー・ポリシーを確定することは容易ではない。
しかし、楽だからという理由だけでGoogleを使い続けることが許されるか一度考える必要があるだろう。

Piwikをインストールしてみたが、完成度はかなり高く感じた。アクセスがあった地域の情報は国単位ではなく、やはりもっと細かい行政単位で情報が必要だろうが、それはGeoIPのエクステンションをインストールすることで可能(なお、パフォーマンスが要求される環境ではGeoIPのApacheのモジュールをインストールすることが望ましいようだ。今回は省略。詳しくはMod_GeoIP)。

サーバーに1つインストールすれば複数の異なるサイトを解析できて、しかもユーザー権限も個別に設定できるなど、便利である。使い込んでみるともっと別の評価が出てくるかもしれないけれども。

MediaWiki or MindTouch。簡単に使えるWiki的なものないか

TwitterやFacebookのように時系列にデータが並ぶメディアだと大事な情報が過去に流れてしまうので時系列ではない情報の受け皿としてMediawiki(Wikipediaのエンジンのオープンソース版)でやろうと考えた。

しかし、Wikiの文法はくせがある。それをうまく意識しなくて使えるようにしてくれるオンラインエディター(WYSWYGエディター)、FCKeditorを組み合わせればかなり使いやすくなる。

ところがもうこのFCKeditor(CKeditor)のextensionはメンテナンスされておらず、古いextensionは現在のバージョンのMediaWikiでは使えないことがわかった。PHP 5.3へのアップデートあたりの問題が絡んでいるのだろうか。FCKeditorなしのWikiだと使ってもらうのはかなり難しいと思う。

他にもオンラインエディターはあるのだけど、どうも使い物にならない感触。この状況ではMediawiki自身のオルタナティブを考えないといけないかもしれない。でもあのやさしくはないWikiで作れたWikipedia、よくみんな書いていると関心してしまう。

Wikiにこだわらず、WordPressなどのstaticページを使うのも手かもしれないし、その他に使えるものとかあるだろうか?

結局、FacebookとかTwitterしか使ったことのない人に使ってもらえるものと考えるとMediaWikiはきつい。情報オタクにはいいかもしれないけれども。
MindTouchは使いやすそう。ただ、気になるのはオープンソースとして提供されてはいるものの、企業の展開に左右されそう。将来にもオープンソースとして使い続けることができる確実性はMediaWikiの方が上か。

正直言って困っている。何かいいアイデアあったら教えてください。

被災地復興に参加型予算の実現を!

震災地の復興を国がやる、県がやる、というが、しかし、そもそも災害対策をここまで怠ってきた行政にそれができるのか?

国による大規模予算は被災者を置き去りに利権、焼け太りの業者だけを生み出すのではないか?

その不信は今や日本全国に行き渡っている。

それではどうするのか?

被災者自身が予算を決定する参加型予算の大幅な実現だ。

参加型予算はブラジルで特定の政治家が自分の支持を引き替えに特定住民に利益を与えるという癒着をやぶり、コミュニティが必要なものをコミュニティが参加し、自身が決定することで、政治家による買収を不可能にして、必要な政策を実現させる上で大きな役割を果たしてきた。

被災地の人びとのニーズとかけ離れた施設の建設や利権のために金を流すようなことを防ぐためにこれ以上ふさわしいものはないだろう。

被災者に力を。それを政策的に実現する。そのためにも参加型予算の思い切った実現を求めたい。

サーバーのバックアップ

サーバーのバックアップは悩むところだ。公共性の高い、保存価値の高いWebサイトの管理をしていて、もしそのデータが失われてしまったら、とてもまずい。

以前であれば異なる場所にあるサーバー間で重要なファイルを相互にバックアップさせておけばどれかのサーバーがクラッシュしても、重要なデータは失わない、という形でとりあえず十分と思っていたけれども、たとえば自分が急病や事故で動けない状態になった時にアウトになってしまう。不正侵入を防ぐために特定のIPアドレス以外からはサーバーにはログインできないように防御しているので、逆にそれが仇になってデータが取り出せなくなる危惧がある。

高価なバックアップ装置を買ったとしても火事でサーバーごと焼けたらおしまい。またバックアップできていると思って確認したらこわれていて取れていなかった、というケースも結構ある。

そのような場合、またクラウド企業の出番になってしまうのだけど他に解がないので、またもやDropboxを使う。

DropboxはLinuxサーバー上でも使えるのでLinuxサーバーにインストールする手もあるが、常に常駐させておくとメモリー使用量も大きいし、バックアップを毎時やるのでなければ常駐させておくのはエネルギー効率が悪い。

アップデートする時だけ常駐させ、アップデート終了したら終了させるシェルスクリプトを書けばいいかと思っていたら、こんなのがあった。Dropbox Uploader …curlさえ入っていれば動くBashスクリプト。Dropboxをインストールする必要すらない。

まずはバックアップの準備。

#!/bin/sh
tar -C / -czf /バックアップディレクトリ/wwwdata.tar var/www/(backuptarget)
mysqldump -u ユーザーID -pパスワード -x データベース名 | gzip >
/(backupdir)/db.mysql.dump.gz

これでバックアップ対象のHTMLファイルとデータベースがバックアップディレクトリに2つのファイルに保存される。

#!/bin/sh
TODAY=`date '+%d'`
cp /(backupdir)/wwwdata.tar /(backupdir_history)/wwwdata.$TODAY.tar
cp /(backupdir)/db.mysql.dump.gz /(backupdir_history)/db.msql.dump.$TODAY.gz

これでバックアップディレクトリ履歴のディレクトリに www.日付け.tarなどの形式で保存される。以前の状態のデータも1月は保存される(ディスクに容量がなければこの部分は省いてもいいかもしれない)。これはローカルのディスク上でだけ保存して、Dropboxには入れない(容量制限を考えて)。Dropboxには最新ファイルだけ入れる(これだと最新ファイルが壊れていたりすれば終わりなのでもう少し工夫した方がいいかもしれないが)。

#!/bin/sh
echo パスワード | gpg --passphrase-fd 0 --batch -c
/(backupdir)/db.mysql.dump.gz
echo パスワード | gpg --passphrase-fd 0 --batch -c
/(backupdir)/wwwdata.tar
mv /(backupdir)/*.gpg /Dropboxに同期させるディレクトリ

これで設定したパスワードでgpgを使って暗号化される。gpgはLinux版だけでなく、Mac版やWindows版もあるので、どんな環境でもパスワードさえわかれば元のファイルに戻すことが可能。暗号化も不要という場合はこのプロセスも省略可能。

あとは、Dropboxのアカウントを作っておき、curlが入っていればdropbox_uploader.shをコピーして実行する。

シェル上で、./dropbox_uploader.sh と打つと、

This is the first time you run this script.
 Please open this URL from your Browser, and access using your account:

 -> https://www2.dropbox.com/developers/apps

 If you haven't already done, click "Create an App" and fill in the
 form with the following data:

  App name: MyUploader2*********
  Description: What do you want...
  Access level: Full Dropbox

 Now, click on the "Create" button.

 When your new App is successfully created, please insert the
 App Key and App Secret:

 # App key: 

と聞いてくる。シェルを離れて、ブラウザで https://www2.dropbox.com/developers/apps にアクセスし、”I agree with the Dropbox Developer terms and conditions.” をチェックして、Submitボタンを押すと、App name: を聞いてくるので上記のMyUploader2***….をコピーして入れて、Descriptionには自分のサーバーのバックアップだということがわかる文章を入れ、Access levelの選択をFull Dropboxの選択をする。そうすると、App key と App secretを表示するので、それをシェルに戻り、入力する。そうするとシェルの方で、
https://www2.dropbox.com/1/oauth/authorize?oauth_token=********
にアクセスしてAppをDropbox側で承認するように求められるので、ブラウザ上でこのURIを開く。承認ボタンを押せば、設定終了。

あとはとっても簡単

sh dropbox_uploader.sh upload ./Dropbox/*

これでDropboxに保存される。

上記のスクリプトを適当に作って、crontabに登録し、毎朝3時とかサーバー負荷が低いと思われる時に自動実行するように設定しておけばいい。

この方法の助かることはバックアップが無事行われているかオンラインであればどこでもチェックができる(サーバーに装着されたバックアップ装置のチェックよりもはるかに楽)。

もっともバックアップされたファイルの内容が想定している状態になっているかはファイルをダウンロードして確認することは必要だろうけれども。

あとは自分以外でサーバー管理できる人とパスワード情報を共有する必要がある。問題は共有してもサーバーを復元することのできる人がそういないことかもしれない。ただ、できる人が見つかればサイトは復元できるはず。

Piwigoのカスタマイズ

写真のオンラインギャラリーを実現するオープンソースのサーバーアプリケーション、多数あるけれども、ざっと調べてみて、Piwigo (http://piwigo.org/)が柔軟性も高く、しかもコミュニティの活発さもあって、よさそうだということでインストールしてみた。

MySQL5とPHP5が使えればインストールはきわめて簡単。
写真のアップロードは複数ファイルをまとめてWebインターフェースを通じてすることもできるし、Windows、Mac、Linux対応の専用ソフトpLoaderを使って透かし(watermark)を入れつつアップロードという芸当もできる。

写真の分類は1つの写真を複数のアルバムに入れることができ、しかもアルバムは階層構造、つまり入れ子にできるため、極めて柔軟にフォトライブラリーを構築することができる。

ユーザーごとに権限を指定できる(ただし、顧客によって個別の高解像度を提供したりしなかったり、というような高度な制御は標準機能では無理そう)。

Extensionが多く開発されていて、Facebook、Twitter、Google+などのお馴染みのものはもちろん、たとえばアップした写真をWordPressで表示するとか、ページを完全に多言語対応にするものや、PayPalでの支払いを実現するExtensionもある(PaypalやWordPressのケースはどこまで使えるかはまだ未確認)。

デザインはテーマとしてすでに開発されているものをダウンロードして利用することができる。CSSでのカスタマイズもLocalFiles EditorというExtensionを使うと、ブラウザー上で簡単に書き換えられる。簡単に静止ページを作るExtensionであるAdditional Pagesも便利。

3つの異なる用途にさっそくインストールしてみたが、異なる用途に対応する柔軟さがある。

特にExtended Descriptionは多言語化を可能にするExtensionで、多言語化が不可欠な人には非常に魅力なので、少しメモしておく。

多言語化対応にするExtended Description

Piwigoのメニューは多言語対応している(45言語![追記]Piwigo 2.3.3でエスペラントが加わり46言語になった)ので、Language SwitchというExtensionを有効化すれば、メニューはすぐに多言語対応になる。

写真のデータやアルバムの表記は基本的に1つしか入力項目がない(データベースの入力項目が1つずつしか存在していない)が、このデータを[lang=defalut]デフォルト言語用[/lang][lang=en]英語用[/lang][lang=ja]日本語[/lang]などという書式で書くことで多言語化するのがこのExtension。

ブラウザーのデフォルト言語の表記が表示され、またLanguage Switchのアイコンで切り替えることでブラウザの設定にはない言語に変更することもできる。

データの入力スペースは言語別に書く欄が分かれておらず、1つの欄に複数の言語のデータをタグと共に入力しなければならないので、入力の手間は大きくなり、管理画面からデータの視認性も少し落ちるが、多言語で組みたいという場合は大きな威力を発揮するだろう。

こうしたすぐれたシステムを見てしまうと、それを使って何か作ってみたくなる。それくらいおもしろい。

その他、いくつか、使う際にカスタマイズする必要を感じるので、そのやり方を記録しておく。

日本語の言語設定のアイコンが日の丸になってしまうことを修正

多国語切り替え(Language Switch)を有効化すると、日の丸が日本語表示のマークになる。
こりゃいやなので、
Piwigoインストールしたディレクトリ/language/ja_JP/ja_JP.jpgを書き換える。

アルバムの領域がクリックできるようにする

トップのページからアルバムをクリックする際、アルバムの文字やサムネイルの写真はクリックできるが、その他の部分はそうではない。アルバムが表示される領域はマウスでポインターを持って行く(hover)で色が変わるので、あたかもその領域をクリックすればそのアルバムが表示されるようになっているように思える。しかし何も変わらないため、人によってはそこから先に行けないと思ってしまうかもしれない。

そこで、文字・サムネイル画像以外のアルバムの領域をクリックしても当該アルバムに飛ぶようにjQueryを使って改造する。

Piwigoのインストールディレクトリ/themes/default/template/header.tpl
{get_combined_scripts load=’header’}
の下に以下を書き加える。

{combine_script id='jquery' path='themes/default/js/jquery.min.js'}
{literal}
<script type="text/javascript">
$(function(){
$(".thumbnailCategory").click(function(){
window.location=$(this).find("a").attr("href");
return false;
});
});
</script>
{/literal}

これでアルバムをクリックすれば飛んでくれるはず。

高解像度の写真はダウンロードのアイコンクリックに限るように改造

高解像度が許可されたユーザーに対してはWebページの写真(サムネールよりも大きな個別の写真ページで表示される写真)をクリックすると高解像度の写真が出るようになっている。

しかし、この方法だと高解像度の写真をダウンロードした人が把握できなくなる。高解像度の写真をダウンロードした人をアクセス解析(History追跡機能)で把握したい、しかし、管理者だけは写真クリックで高解像度の写真を表示できるようにという団体のニーズに合わせるため、ソースに手を加えた(管理者には可能にしたのは高解像度の写真のURLが管理者にはすぐにわかるようにするため)。

インストールディレクトリ/themes/default/template/picture_content.tpl
のファイルを書き換える。下記で
{if isset($U_ADMIN)}
{/if}

でくくったところがそれ。

{if isset($high)}
{combine_script id=’core.scripts’ load=’async’
path=’themes/default/js/scripts.js’}
{if isset($U_ADMIN)}
<a href=”javascript:phpWGOpenWindow(‘{$high.U_HIGH}’,'{$high.UUID}’,’scrollbars=yes,toolbar=no,status=no,resizable=yes’)”>
{/if}
{/if}
<img src=”{$SRC_IMG}”
style=”width:{$WIDTH_IMG}px;height:{$HEIGHT_IMG}px;” alt=”{$ALT_IMG}”
id=”theMainImage”
{if isset($COMMENT_IMG)}
title=”{$COMMENT_IMG|@strip_tags:false|@replace:'”‘:’
‘}” {else} title=”{$current.TITLE|@replace:'”‘:’ ‘} – {$ALT_IMG}”
{/if}>
{if isset($high) }
{if isset($U_ADMIN)}
</a>
<p>{‘Click on the photo to see it in high definition’|@translate}</p>
{/if}
{/if}

日本語に対応していないExtensionを使う場合

Piwigoインストールしたディレクトリ/plugins/プラグインの名前/language
の下に ja_JP というディレクトリを作り、たぶん存在しているだろうen_USかen_UKのディレクトリーの中味をコピーした上で、plugin.lang.phpなどというファイル名のファイルを翻訳していく。
書式は
$lang[‘Top’] = ‘Top’;
のようになっているので、
$lang[‘Top’] = ‘トップ’;
としてやればいい。

オープンソースの精神に立てば、使う以上、日本語対応させた時はそのプラグイン(Extension)の作者に日本語の翻訳ファイルを送って貢献すべきだろう。しかしものによっては大量の翻訳になるので、全部やろうと思うと大変になることもある。

Extension download_multiの翻訳を修正する

アルバムごとや個々の写真をまとめてダウンロードできるExtension、Download_Multi、便利なプラグインだが、管理画面が英語を選択しても、フランス語のまま。これも上記の方法で、ja_JPディレクトリーを作成して、そこで翻訳すればいい。実はen_UKの翻訳セットは準備されているのだけど、管理画面のところはフランス語のままになっているので、言語設定を変えても管理画面は変わらない。

download_multi/language/ja_JP

download_multi/language/en_UK
の内容をコピーして、フランス語になっているものを日本語にしてやればいい。なお、グループは複数選ばなくても、Ctrlを押して指定してやらないと、選択したことにならず、エラーが出て、いつまでたっても設定できないことになってしまうので注意が必要。

翻訳の足りない部分、おかしい部分

バッチ・マネージャーで下記の翻訳が足りないのでlanguage/ja_JP/admin.lang.php に追加。
$lang[‘The whole page’] = ‘このページすべて’;
$lang[‘The whole set’] = ‘すべての写真’;
$lang[‘Who can see this photo?’] = ‘この写真の閲覧許可対象’;

同ファイルで
s/アックション/アクション/ ←アックションと書かれた部分3カ所一括置換
s/アドミニ/管理ページ/

日本語で問題になるかも=メール文字コード

コンタクトフォーム用のExtensionはあるが、日本語用のメールのExtensionは存在していないので、メールの文字コードはUTF-8になる。今時、ほとんどのメールクライアントはUTF-8は読めると見なせれば問題ないが、そうでない場合、文字化けする。

気になる人はExtension作るしかない。

使用しなかったExtension

LMT
著作権を選択して表示する。よくできているが、単に著作権の種類を表示するだけでなく、カメラマンの写真を預かるような場合、著作権者の名前を保存しなければならない場合、Piwigoのauthorとは別にデータを保存することになってしまい、煩雑になるので、利用をあきらめた。写真によってCreative Commonsの異なるレベルやCopyright (CopyLeft) を使い分けるという時は威力を発揮するかもしれない。
Extended_authorとCopyrights

著作権者をプルダウンで選択できると思ったのだけど、うまくいかなかった。あらかじめ著者情報を入れておけばよかったのだろう。今後使ってみようと思うが、個人的なメモとして残しておく。

いずれにしても、写真を効果的に共有したいという場合にはひじょうに使えるシステムであると思う。今後の発展にも期待したい。

追記: タイトルバナーにHomeへのリンクを追加

タイトルバナーにHomeへの戻りのリンクがないのは使いにくい、ということで

themes/default/template/header.tpl に下記のリンクを追加。こうすると管理画面で書き込むPage bannerの文章にまで同じリンクがかかってしまう(Page bannerで書き込む文章を</a>で始め、その続きの文章のどこかにリンクを設定して最後の</a>を省けば、ちょうどうまく行くんだが…)。またリンク文字の色はテーマによって決めさせた方がいいからここでstyleで書くのは御法度だろうが、何と書けば正解なのか今わからないので暫定的に。

<div id=”theHeader”><a href=”/photos/” style=”text-decoration:none;color:white”>{$PAGE_BANNER}</a></div>

Piwigoに関する情報

:
Piwigo Website: http://piwigo.org/
Twitter: @Piwigo