Spamhaus に登録されていないか自動で定期的にチェックする方法

メールサーバーを自前で運用しています。その IP アドレスがときどき Spamhaus のリストに載ってしまうことがあります。もちろんこの自前サーバーは Spam 発信源ではありません。

Spamhaus の Blocklist Removal Center にアクセスして確認できます。どうやら自分の IP アドレスを含む xxx.xxx.xxx.xxx/15 が一網打尽にされてしまったようでした。リストから削除してもらうには、そのページから所定の手続きを踏みます。

が、はじめにリストに載ってしまったかどうか気づくのが難しいのです。メールを出しているつもりが相手に届かないという状況はなかなか気づけません(電話をかけて、自分の耳元では「プルルル…」と鳴っているのに実はどこにも繋がっていない状況を想像してみてください。ふつうは、単に相手が出ないとか相手の機器に問題があるとか、とにかく受け手に何か問題があるのだと思い、まさか呼び出してさえいないとは思わないでしょう)。相手先のサーバーからエラーメッセージでも返ってくればまだましなのですが、黙って無視するだけという場合もよくあります。今回はメール以外でもよく連絡をとっている相手に、たまたま別の手段で連絡をとった際に発覚しました。

広範囲のリスト掲載の巻き添えを食らうのは 10年ほどのあいだに2,3回という頻度なので、まさに忘れた頃にやってくるという感じです。上述の Blocklist Removal Center にアクセスして確認すればいいのですが、そうしょっちゅうもやっていられません。

自動的・定期的にチェックする方法はないかと探してみたら、FAQ に How do I check my DNS server results? というのがありました。

自分の IP アドレスがたとえば 203.0.113.50 だとしたら、それを逆さまにして .zen.spamhaus.org を付け足したものを DNS で検索します。

dig +short 50.113.0.203.zen.spamhaus.org

何も返事がなければ、リストに載っていません。

もし 127.0.*.* の返事があれば、リストに載っています(その意味は FAQ の What do the 127.*.*.* Return Codes mean? を参照のこと)。

というわけで、この1行を cron で定期的に実行して様子を見ることにしました。

『サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブル』

事前にレビューする機会を与えられた書籍『サイトの拡張性を飛躍的に高める WordPressプラグイン開発のバイブル』が発売されました。

タイトルのとおり「プラグイン開発」に焦点を当てたもので、これまでの WordPress 関連書籍と一線を画しています。

まえがきに「開発者をターゲットとした WordPress の専門書」とあり、WordPress 固有のプラグインの仕組みの解説はもちろん、WordPress プラグイン開発に適した環境の構築から、コーディング規約、テスト方法まで、懇切丁寧に書かれています。これらをまとめて一瞥できるのは大変ありがたいことです。

WordPress の特徴としての GPL についてもひとつの章を充ててじっくりと説明されています。その上でのビジネスモデルにも言及されており、一読の価値があります。

そして開発したプラグインを公式ディレクトリで公開する方法も紹介されています。評者はこの本の出る少し前に初めて公開を前提としてプラグインを書き、公式ディレクトリに登録してみました。まったく大したものではありませんが、「公開」を念頭に置くと適当なことはできないので、ウェブであちこち検索して回ってできるだけきれいに、間違いのないようにとあらためて勉強することになりました。そのときにこの本があればかなり近道ができたはずです。

さて発売前のレビューの際に、細かな用字の指摘のほかにもやや大きな修正や加筆を必要とするようなコメントを著者に返しました。前者はともかく後者については、たぶん時間的にも分量的にも制約が大きかったのでしょう、残念ながら反映してもらうことができなかったものがありました。

そのひとつが、第8章「管理画面」の特に8-3節「管理画面を使って独自の設定を保存する」についてです。著者たちがあまりにプラグイン開発の経験に富んでいて、ずっと以前から WordPress に精通しているためか、旧来の手法による記述になっています。古いプラグインを読んで理解するにはいいかもしれませんが、これから新たに開発する場合にはこの箇所の記述のようにする必要はありません。WordPress の現在のバージョンには、より簡便で安全な手法 (Setteings API) が用意されています。せっかくこの年になって出版される日本語で初めて(たぶん)のプラグイン開発の解説書ですから、ぜひ Settings API に触れてほしかった—というか現状の8-3節と差し替えてもいいくらいでは—と思います。

そういった点はあるにしても、全体にこの本から受けることのできる恩恵は大きなものがあります。

評者は WordPress の単なるユーザーとなってから数年の時間が経過していますが、実際にプラグインを作ってみること、それも公開しても恥ずかしくないように書いてみることをやってみてはじめて、それまで適当にしか理解していなかったことについてもきちんと知る必要が出てきて、学ぶことが非常に多くありました。その経験をとおして WordPress そのものについての理解、ほかの人たちが作った便利なプラグインについての理解がかなり深まりました。

そういった意味で、この本が「ターゲットはプラグイン開発者」と謳っていても、一般のユーザーも手にとって読んでみるといいと思います。そして簡単なものでもいいので(最終的には公式ディレクトリに登録はしないにしても)「正しい」作法でプラグインを書いてみると、 WordPress をより理解し活用することにつながるでしょう。

MediaWiki のスパム対策

ほとんど放置気味の Wiki に、適当なアカウントが登録されては長文(ドイツ語)のページが作られる、というのがここ数日続いていました。見にくる人はほとんどいないし、その作られたページはさらにどこからもリンクされていないし、まったく誰にも何の得もない所業だと思うのですが、放っておくわけにもいかず、ちまちまと削除していました。

この Wiki は MediaWiki で運用しています。最近の MediaWiki には最初から ConfirmEdit という拡張機能が同梱されています。この機能の SimpleCaptcha というものを以前から有効化していました。これは、アカウント作成時や新規ページ作成時に、簡単な数式(足し算や引き算)の答を入力させるというものでした。にも関わらず変なアカウントやページを作られていたわけですから、スパムボット(いやまさか人力ではあるまい)はこれに対応したものだったようです。

数日続いたのでだんだん嫌になり、同じ ConfirmEdit の QuestyCaptcha を使うように、設定を変更しました。

LocalSettings.php の記述は

require_once( "$IP/extensions/ConfirmEdit/ConfirmEdit.php" );
require_once( "$IP/extensions/ConfirmEdit/QuestyCaptcha.php");
$wgCaptchaClass = 'QuestyCaptcha';
$wordarr = array (
        "日本語で質問に答えてください。質問1" => "答え1",
        "日本語で質問に答えてください。質問2" => "答え2",
        "日本語で質問に答えてください。質問3" => "答え3",
        "日本語で質問に答えてください。質問4" => "答え4",
        "日本語で質問に答えてください。質問5" => "答え5",
);
foreach ( $wordarr as $key => $value ) {
        $wgCaptchaQuestions[] = array( 'question' => $key, 'answer' => $value );
}

$wgCaptchaTriggers['edit']          = true; 
$wgCaptchaTriggers['create']        = true; 
$wgCaptchaTriggers['addurl']        = true; 
$wgCaptchaTriggers['createaccount'] = true;
$wgCaptchaTriggers['badlogin']      = true;

のようにします。質問はランダムに表示されます。質問と答を日本語とすることにより、日本語話者かどうかの判定も兼ねるようにしました。

しかしこの設定は、管理者の負担を善意のユーザーに転嫁するものでもあります。そのようなユーザーには CAPTCHA を求めないように、

$wgCaptchaWhitelistIP = array('192.168.0.0/24'); // 安全な接続元を IP アドレスで指定
$ceAllowConfirmedEmail = true; // メールアドレスを確認済みのユーザーは安全とみなす

も設定しておくことにします。

これでしばらく様子を見ることにします。

PDF の校正作業

出版前の本のレビューの依頼を受けるという機会に恵まれました。

著者からは PDF で原稿を受け取りました。作業の参考にしたのはテクニカルコミュニケーター協会が公開している「PDF 電子校正ガイドライン 第3版」 (PDF) です。端的に言うと、Adobe Acrobat Pro または Adobe Reader の「注釈」機能を使って、テキストの修正やコメントを付けていきます。

ところが、こちらの環境は Linux です。Linux には Adobe Acrobat Pro は存在しません。Adobe Reader も Mac/Win ではバージョンが XI (11) なのに、Linux 版は 9 のままであり、それ以降のバージョンは計画もない状況です。Linux 版の Adobe Reader 9 の注釈機能は、既に付けてある注釈を見ることはできても、あらたに注釈を付ける機能はなく、まったく話になりません。

Okular というソフトが注釈を扱えるようですが、その注釈は Okular でしか読めないらしいのです。なぜ Linux での環境がこれほど貧弱なことになってしまっているのか、愕然としました。

結局、このためだけに Windows XP を起動し、そこで Adobe Reader XI を使って作業したのでした。残念無念。

こうして作業して、注釈だけを別に保存します。はじめに受け取った原稿の PDF が 数十MB だったのに対して注釈はたったの 100KB ほどで、メールに添付してもたいしたことはありません。元の原稿は著者の手元には当然あるので、送る必要はありません。著者のほうでは送られてきた注釈ファイルを Acrobat 上で元の原稿に取り込んで確認できるというわけです。

受け取ったのは組版されて割付が終わっている段階です。著者校正の段階に相当し、それを第三者の目で内容的に誤りがないかを確認するということを求められているのかなと判断しました。プロの校正者ではないので、その人たちのようなチェックはできないはずなのですが、自分の性格からかつい細かな用字や読点に目がいってしまって、どっちつかずの「レビュー」になってしまいました。

そんなこんなが、いくらかでも役に立っていればうれしいのですが。

WordPress プラグインやテーマの翻訳でうまく手を抜く(いい意味で)

WordCamp Kansai 2014 に行ってきました。2日め“コントリビューターデイ”、プラグイン・テーマ翻訳の世話役だったのですが、可搬 PC は持っていないし、子連れだし、遠方まで帰るために途中で抜けなければならないし、さらに、「Mac/Win で Poedit というアプリケーションを使う」というのが最も一般的と思われるのに自分では使っていないため[1]に操作方法を即答できない……、という幾重もの役立たずぶりですみませんでした。こどもの相手やら何やら、こちらのほうがお世話になりっぱなしで、ありがとうございました。

そういう中で質問を受けたことを、今さらながらここに書いておこうと思います。

翻訳作業のステップ

WordPress のプラグインやテーマの翻訳をやってみようという記事はあちこちにたくさんあります。ここでは細かく書きませんので、それらを参照してみてください。「POT ファイルとは何か」「PO ファイルとは何か」「それらはどこにあるか」などは既に知っているという前提で進めます。

おさらいです。WordPress のプラグインやテーマの翻訳作業のステップは

  1. プラグインやテーマのプログラムの中の翻訳されるべきメッセージに __() や _e() などのマークを付ける
  2. マークされた文字列を抽出して POT ファイルと呼ばれる、翻訳者にとって原本となるものを作成する
  3. POT ファイルを元に、メッセージをそれぞれの言語に翻訳した PO ファイル を準備する
  4. PO ファイルを編集する (これがほんとうの翻訳作業)

です。作業のスタート地点が後ろに近いほど、とっかかりやすいです[2]

最も始めやすい状態: ステップ4から

たくさんある記事のひとつ、Nao さんの「2014年版: WordPress プラグイン・テーマの翻訳を始めてみよう」を見てみます。

その記事にありますように、最も手軽に始められるのが、既に全部または一部翻訳がなされているものに対して、誤訳を修正するとか、別の訳語にするとか、訳の抜けている部分を補う、というものです。これなら最初のハードルがぐっと低く、ともかく「やってみよう」という気になれます。

Poedit なら、書き換えたい PO ファイルを開き、当該箇所を修正・加筆するだけです。

その次に楽な状態: ステップ3から

プラグインやテーマそのものは翻訳可能 (POT ファイルが用意されている) だが日本語訳 (name-ja.po) がない状態というのが、その次にとっつきやすい状態です。

公式ディレクトリに登録されているプラグインテーマなら「translation-ready」というタグが付けられているでしょう。ここでいうステップ1や2の処理が既にされているという意味です。

Poedit なら、「ファイル」-「POT ファイルを元に新しいカタログを作成…」で、「言語」に ja を指定して適切な名前 (name-ja.po の形) で保存します。

コマンドラインを使えるなら Poedit を使わずに、

msginit -i name.pot -o name-ja.po -l ja 

です。意味はなんとなくわかりますね。

この時点で、翻訳率0% の日本語翻訳ファイル name-ja.po ができます。

ステップ3をステップ4に

「0%」……嫌な響きですね。これだけでやる気が削がれてしまいます。なので、過去の資産から使えるものは少しでも流用します。

たとえばテーマの翻訳をしようとしているとします。その最初に、既存の、たとえばデフォルトテーマの twentyfourteen の翻訳を取り込んでしまおうというのです。

もしステップ3をコマンドラインでできたようなら、これまたコマンドラインで

msgmerge -o name-ja.po -C wordpress/wp-content/languages/themes/twentyfourteen-ja.po name-ja.po name.pot

のように、msgmerge を使います。-C で参考とする PO ファイルを指定します。-C はひとつのコマンドラインの中に何度でも指定できるので、WordPress 本体の ja.po や admin-ja.po も追加するといいかもしれません。

Poedit ではこれに相当する操作が簡単にできないようです。そこでステップ3の代わりに、次のようにします。name-ja.po がまだ存在しない状態で、参考とする PO ファイル (たとえば twentyfourteen-ja.po) を name-ja.po という名前でコピーします。これを Poedit で開き、「カタログ」-「POTファイルでカタログを更新…」します。

すると、英文が合致する分の翻訳がそのまま取り込まれます[3]。プラグインでは参考にする似たものを見つけてくることが難しいかもしれませんが、テーマの場合は、デフォルトのテーマを参考にしてうまくいけば80%ほども翻訳済みにしてしまうことができます。

これで、スタート地点をステップ3からではなく、ステップ4からにすることができます。

翻訳メモリ

Poedit には翻訳メモリという機能があります。データベースに登録しておけば、それを自動的に参照して、英文が合致する分を埋めてくれます。まずは WordPress 本体の ja.mo や admin-ja.mo それにデフォルトのテーマの twentyfourteen-ja.mo を登録しておきましょう。

これによってもスタート地点をステップ3からではなく、ステップ4からにすることができます。

前節の方法と翻訳メモリの方法は同時に使うこともできますので、積極的に翻訳メモリを使うのがいいでしょう。

といっても私自身が Poedit 自体(ということは翻訳メモリも)使っていませんので詳しく書けません。かなり古い記事ですが Tai さんの「poEditの翻訳メモリ機能を使う」や Miyoshi さんの「poEdit で翻訳ファイルを作る 」の「翻訳メモリを活用する」の節などを参考にしてください。

手抜きの効果

「手抜き」というと負のイメージの言葉ですが、ここではまったくそういうことはありません。むしろ用語の統一という点でも、積極的にここに書いた方法をとるべきだと思います。

そこで、最初掲げたステップを修正して、

  1. プラグインやテーマのプログラムの中の翻訳されるべきメッセージに __() や _e() などのマークを付けておく
  2. マークされた文字列を抽出して POT ファイルと呼ばれる、翻訳者にとって原本となるものを作成
  3. POT ファイルを元に、メッセージをそれぞれの言語に翻訳した PO ファイル を作る
    1. 過去の資産を参照して自動的に、できるだけ翻訳を埋める
  4. PO ファイルを編集する (これがほんとうの翻訳作業)

の赤い字の項目を必ず実行するように意識することを強くお奨めします。

ざっと検索してみた Poedit の使い方、WordPress の翻訳や WordPress 翻訳祭りのような WordBench などでの解説でも「POT ファイルから PO ファイルを作りましょう。空っぽの ja.po ができましたね。さあ翻訳を始めましょう」と、このあいだのステップが飛ばされているように思います。

いまからやろうとしている翻訳は、単語レベルでは既に誰かがやっているかもしれません。WordCamp Kansai 2014 のキーワードは「Share 分かちあい」でしたね。share できるものは share して、抜ける手はなるべく抜いて、その余力は別のところで活かしましょう。

これくらいの下調べは前もってやっておくべきでした。すみません。今後の各地のイベントや、あるいは個人で、翻訳やってみようかなというときには、前に書いた「WordPress 翻訳祭り—今さら注意してもらえない「日本語」について 」と併せて参考にしてもらえればと思います。

  1. ふだんは Debian 上の Emacs の po-mode で作業しています。
  2. このあと、それを開発者に送るとか、開発者の側では送られてきたものを最新版に合わせてからパッケージに同梱するとかの作業もありますが、ここでは省略します。それらとステップ2については以前「プラグインやテーマの国際化を少し楽に」に書きました。
  3. 合致しなかった部分を掃除するには Poedit では「カタログ」-「Purge Deleted Translations」です。

Mew のサマリに表示される本文の部分が変わった

Web のフォームによって送られる次のような書式のメールをしょっちゅう受け取ります。冒頭から

[氏名] ...
[よみかな] ...
[郵便番号] ...
[住所] ...
     ... 

のように、 [ ] ではじまる行があります(「氏名」や「住所」というのはあくまで例です)。

メールリーダーには Mew を使っているのですが、そのサマリ表示に上記の部分がばっさりカットされて、どうでもいいところからの本文の一部が現れるようになりました。

さて検索してみると、“[” ではじまる行を引用部分とみなし無視する、という変更が行われたようです。自分の手元でこのような変化がつい最近起こったのは Debian のパッケージの更新の時期によるものでしょう。

この部分(mew-scan.el の mew-regex-ignore-scan-body-list 定義部分)を元に戻しながら、~/.mew.el に setq

(setq mew-regex-ignore-scan-body-list
  '("^[ \t]*$"
    "^[ \t]*[-a-zA-Z0-9]+: "
;;    "^[ \t]*[[>:|#;/_}]" ;; https://github.com/kazu-yamamoto/Mew/commit/98d4fd7be3216792824e2c737006921b3b49b4b0 で加えられた変更
    "^[ \t]*[>:|#;/_}]" ;; を戻す。すなわち、"[" で始まる行を引用とはみなさない
    "^[ \t]*\\w+\\(['._-]+\\w+\\)*>"
    "^[ \t]*[[</(.-]+ *\\(snip\\|\\.\\.\\)"
    "^   "
    "^--"
    "^- --"
    "^=2D"
    "^.\\{1,100\\}\\(:\\|;\\|/\\)[ \t]*$"
    "^.\\{1,100\\}\\(wrote\\|writes?\\|said\\|says?\\)[^.!\n]?[ \t]*$"
    "^[ \t]*\\(On\\|At\\) .*[^.! \t\n][ \t]*$"
    "^[ \t]*In \\(message\\|article\\|mail\\|news\\|<\\|\"\\|\\[\\|(\\)"))

と書くことで、以前の状態にすることができました。

トイレの明かりが消えない……えっ?

スイッチを OFF にしてもトイレの照明が消えない。ON にすると正常に点灯し、OFF にすると0.5秒間隔ほどで点滅する。以前のことを思い出し、ありゃまたLED電球がおかしくなってしまったか、案外寿命は短いな、買いに行かなけりゃなどと考えながら部屋に戻った。

が、しばらくして、「はて、よく考えるとスイッチが OFF なのだから、電球が壊れたとしてもそもそも点滅するのは変なのでは?」と思い至る。だとすると、スイッチが壊れたのか。もう一度トイレに戻って何度かパチパチしてみても状況は変わらない。うーむ。

この家の配線はほとんどむき出しなので線を追える。スイッチの上方、トイレの扉の上に黒くて丸いジョイントボックス(明工社 ジョイントボックス 小 20A 300V MJ2420こんなやつ)がある。

ふとその蓋をくるくると外してみると……なんとムカデが!! とうぜん感電死していたのだが、絶妙のポジションでブレーカーを落とすことなくスイッチをショートカットしていたのか。

2,3日前は寝床の真上の天井にさかさまに張り付いているムカデを発見したし、その数日前には、向こうの部屋で何やら猫が暴れてるなと思って見に行ったらヘビと戦っているし。これだから田舎の家は……。