「Erlang実験室：EDocで日本語を使う方法」で紹介した、1,2行のパッチを当てる方法、おおむねうまくいきます。しかし残念ながら、完全ではありませんでした。状況により文字化けします。
EDocよ、おまえもか -- 非ASCII圏の我々からみると「なんちゅうおバカな作りなんじゃ!?」とため息が出るようなハナシ。
8ビットスルーなのはいいけれど…
Erlangにとって、文字とは「0以上255以下の整数」に過ぎません。文字列は、そのような“文字”のリストです。128以上の“文字”に対しても特に何もしないでそのまま扱うので、「文字＝バイト」という原則ですね。
「文字＝バイト」であるため、バイト（8ビット）をコード単位とするUTF-8に適合させることは比較的簡単だと思われています。しかし、Erlangの仕様や処理系がUTF-8を意識しているわけでは全くありません！ おそらく、ISO 8859-1 (Latin-1)のような、128以上も文字に割り当てる1バイト系文字システムを前提にしているのでしょう。
UTF-8は、127以下の番号ではASCIIエンコーディングと互換ですが、128以上の番号は2バイトにエンコードされます。それに対して、ISO 8859-1やJIS X0201では128以上の番号もそのまま1バイトで1文字に対応しています。つまりこれは、UTF-8は、「文字＝バイト」を前提としたネイティブな（あるいはローカルな）文字システムと全然違うし、どうやっても整合しないことを意味します。
そういう事実を、EDocの作成者はまったく考慮してませんでした。ISO 8859などを暗黙の前提にしていたにしても、結局ASCIIしか使えないよ、コレ。
もっと具体的に言うと
EDocのアットマーク・タグには、プレーンテキストを内容（contet）とするものと、XHTMLフラグメントを内容とするものがあります。@authorタグはプレーンテキスト内容、@docは、そして@docだけがXHTMLフラグメントを内容とします。
EDocはどうやら、Erlangパーザーを使って構文解析木を作って、コメント内を調べて@docの内容を切り出し、それをXMLパーザーxmerlに渡しているようです（推測）。その他のアットマーク・タグ、例えば@authorの内容は何もしないで出力に渡します。これって、トンデモナイですよねぇ。
同じファイル内で、@authorに続く部分は例えばISO 8859-1のように解釈され、@docに続く部分はUTF-8として解釈され、出力ではそれらの処理結果がゴチャ混ぜにされます。僕のパッチでは、127より大きな文字番号をUTF-8エンコーディングに変換しますから、128から255も変換対象です。しかし、@authorなどから来た128から255はもともとがUTF-8エンコーディングの一部（文字番号ではなくて生々のバイト）だったかもしれないのです。ウギャー。
出力前のデータ構造の上で、丁寧にエンコーディングを揃える作業をしないとダメそう。グムーッ。
[追記]「Erlang EDoc、やんなっちゃう」も参照。[/追記]
