大雑把な手順は以下の通り。（ちなみに訳等の作業はWindowsマシンで行っています）

1. wp-weather-en_US.poをwp-weather-ja.poにコピーし、作業マシンに引っ張ってきます。
2. POEdit（作者さんのサイト）でこのファイルを開き、対訳を変更していきます。
3. 対訳の変更が終わったら、カタログを作成します。（wp-weather-ja.moができあがります）
4. wp-weather-ja.moファイルをlocalizationディレクトリにコピーします。

上記の方法で固定文字列が日本語化されます。しかし、私は欲張って日付の書式を日本式にしたり、動的に変わるお天気なども日本語化したくなり・・・「はまりました・・・orz 」

このプラグインの流れは、「更新→weather.comに問い合わせ→wordpress DBのデータ更新→データ表示」となるわけです。当方は、「DBはUTF-8だし、wordpressやプラグインで使用する文字列もUTF-8なので問題ないだろう」と高をくくり、がしがしと動的に変わる文字列をpoファイルに登録・対訳し、ソースを変更していきました。そして、更新～。

「・・・、対訳が出てこねぇ～ 」

ソース文字列をHexコードでチェックして見るも、特に変なコードが入っているわけでもなし。「う～ん、う～ん」と呻きながら小一時間。phpの文字列操作関数群を眺めながら、「おやっ、mb_～()？、もしやマルチバイト・・・」。
ここまで足突っ込んじゃっているし、とりあえずマルチバイト系文字列に変換してみるか～とゴソゴソソースを修正＆更新～。
「うぉ、対訳出てきやがった 」
う～ん、文字列はかなり癖あるなぁ～と。（当方の知識不足は棚上げしておきます、ぉぃ）

DBのデータを一旦マルチバイト文字列に変換し、その文字列を変換用検索文字列として渡します。
変更例は以下のよう感じ。

$htmlstring .= '<br />'.__(mb_substr($xml->cc->t, 0, mb_strlen($xml->cc->t) ,'UTF-8'), 'wp-weather').'<br/>';

また、日付を海外書式（Monday, May 23）から日本書式（5月23日 月曜日）へ変換したい場合の例はこんな感じ。

$htmlstring .= date_i18n('n月j日 l', strtotime($day_forecast->lsup));

上記の例の基のデータ（$day_forecast->lsup）はデータベースを覗くと[ 5/23/11 2:13 PM Local Time ]な感じなんですが、date_i18n()とstrtotime()関数の組み合わせは結構融通が利くみたい。例えば[ May 24 ]をstrtotime()に通した後、date_i18n()に通すと思い通りの書式で出力してくれる。もし、ソースを見る機会があったら覗いて見ようかと。ここまで融通が利くと結構バグがあるかもしれんしね。（ぉぃ、疑う前に知識身につけろ・・・ごもっとも）
注：date_i18n()関数はwordpress固有の関数ですのでご注意を。

さて最後に
「まだ日本語化終わっていません、ｷﾘｯ」

と言うのも、お天気の種類がいくつあるのか分からないので、出たとこ勝負で訳しています。
作者に聞いてみようと思うので、進捗があったら更新します。
それと、この変更はまだ作者に了解を取って行っているわけではないのでファイルは公開できません。上記の問い合わせとあわせて聞いてみますので、これも進捗があったら更新します、あしからず。