[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re:www.NetBSD.orgの日本語訳のwww.jp.NetBSD.orgでの公開について



こんにちは。
小野寺です。

From: Hiroki Sato <hrs@allbsd.org>, Date: Fri, 19 Aug 2011 04:24:16 +0900 (JST)

>  いえ、
> 
>   1. XML が UTF-8 で書かれていること
> 
>   2. XSLT が UTF-8 で書かれていること
> 
>   3. 出力される HTML が UTF-8 になること
> 
>  は、すべて独立しています。それぞれ個別に決めないといけなくて、
>  何も指定しないと、すべてのデフォルトが UTF-8 になる、というのが処理の実際です。
>  また、これら全部が指定されていても、entity reference (&xxx;) は
>  別の理由でエンコーディングに関する注意が必要になります。
> 
>  &xxx;が化けるのは、XML ソースファイルが iso-2022-jp で書かれているのに、
>  &xxx; を UTF-8 の固定ビットパターンに置き換えるという、誤った定義ファイルが
>  使われているからです (定義全体は textproc/iso8879 などに入ってます)。
> 
>  非 iso-8859-1 圏の言語を処理する場合、
>  この定義ファイルを出力エンコーディングに合ったものにするか、
>  文字列の entity は展開せず、&xxx; のままで処理させるか、が典型的な
>  方法ですが、HTML にする場合は後者が無難なので、後者にすることが多いです。
> 
>   # 最近のウェブブラウザは優秀なので、文字コードの扱いとして HTML 4.01 だと
>   # SGML, XHTML では XML の流儀を使ってくるので、非常にめんどうなのです...
> 
>  SGML や XML まわりの文字コードの扱いは厳格なルールがありますので、
>  慣れないと良く分からない → UTF-8 に統一すれば簡単じゃん、という
>  流れで UTF-8 を使いましょう、にたどり着くのは、確かにそうなので
>  悪い考え方だとは思わないのですが、
>  そうするのであれば、最終成果物を XHTML にして、入力・出力データを
>  すべて UTF-8 にするという徹底した方法をとらないと、また同じ問題が
>  生じると思います。

難しい話を避けるつもりはないのですが、ご説明いただいた内容について、
今のところ良く分かりません。

ただ、気になるのは、以下のことです。

>  小難しい話はどうでも良いから、単に &copy;, &reg;, &nbsp; の〓を
>  なくしたいというのであれば、
> 
>   <!ENTITY copy "(C)">
>   <!ENTITY reg "(R)">
>   <!ENTITY nbsp " ">
> 
>  という行を DTD に突っ込んで rebuild すれば達成できると思います。

これは、docbook-websiteのDTDを変更するということでしょうか?
あるいは、xslt10.dtdかxslt10-netbsd.dtdを変更するので
しょうか?
いずれにしても、www.jp.NetBSD.orgのための特製のDTDを使ってしまうのは、
xmlファイルをUTF-8にする以上に面倒を生むと思います。
www.NetBSD.orgと同じDTDを参照しているように見えながら、
違うDTDを参照しているというのは、問題と思います。

netbsd-webpage-ja.xslでどうにかすることはできないでしょうか?
私は(C)は&copy;にできたのですが、(R)とかはどうにも
できませんでした。
netbsd-webpage-ja.xslでどうにかできれば、私がUTF-8にこだわる
理由はなくなります。

>  サイト全体としてのポリシがなくて、文字コードが違ってても
>  誰も気にしないのであれば、それで良いのではないでしょうか。
> 
>  佐藤は、XML ベースのソースから生成される HTML ファイル群の
>  エンコーディングを、既存のものと合わせる操作が、
>  そんなに大変なことだと考えていなくて、
>  わざわざ別のエンコーディングを選択する理由はあるのかな、という点に
>  疑問を持っていました。
> 
>  同じウェブサイトなら一貫性があったほうが良さそうだ、というのは、
>  その延長上にある、多分に感覚的な意見です。
> 
>  問題が良く分かってないのですが、&xxx; の文字が化けるという以外に
>  エンコーディングの問題はあるのでしょうか?  「たくさんあって UTF-8 にしないと
>  解決できない」というのであれば、UTF-8 を選ぶのに躊躇する必要はないと思います。

私が認識している問題は、(C)とかが文字化けする以外にはありません。
むしろ、日本語訳がhtmlで公開されていない現状に問題を感じています。

>> From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
>> > これは本家でも同じですし、これぞという解決策があるわけでもないので、
>> > ja ローカルで懸念していても意味がないような気がします。
> 
>  公開するサーバ側で定期的に自動 build することで解決になると思うのですが、
>  それでは解決になりませんか?
> 
>  それが不可能だというのであれば、HTML ファイルを commit することに
>  異論はありません。両方が可能だとしたら、HTML ファイルを commit することは
>  不利な点がたくさんあるので、止めたほうが良いと考えています。
> 
>  単なる typo の修正を commit しても、XML のツールを全部インストールしている
>  マシンで rebuild して HTML ファイルを commit しないと
>  反映させることができない、というのは、すごく不都合な側面だと思っています。

typoのような些細な修正であれば、例えばwww@jpのような人に連絡してほかの
commitと一緒に処理してもらうことも可能だと思います。
それに、htmlをcommitしないにしても、やっぱりプレビューしてからcommit
してほしいですし。
# 特に私を含め頭の中にdocbook-websiteが入っていない人ほどそうした方が良い
# と思います。些細と思ってもそんなことがないこともあるでしょうし。

>  いずれにしても、build に必要なファイル群を commit しなければならないことには
>  変わりはないと思いますので、これと思う変更を加えながら考えるのは
>  いかがでしょう?

これまた理解できていないからなのかもしれませんが、xslファイルも
xmlファイルと同じ文字コードが良いと思います。
技術的には違っても良いのでしょうが、これこそ合わせておかないと
面倒だと思います。
TNFのhtdocs/share/に追加しないといけないファイルは
そんなに多くないので、文字コードを決めてからで良いと思います。

--
Ryo ONODERA // ryo_on@yk.rim.or.jp
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3