アカウント名:
パスワード:
> l10n よりも i18n の流れが進んだのでしょう。
揚げ足取りですが、用法が間違ってるような。
i18n は言語や地域を外部設定できる(ソースの変更やリコンパイルなしで変更できる)機能で、l10n は i18n 対応したものに特定の言語や地域用の設定を行うことだと思います。(両者は二者択一のモノではありません)
今回のトピックにあわせていうなら、UTF-8だけで足りるようになったから i18n とか l10n は過去のモノになりつつあるという感じでしょうか？
>揚げ足取りですが、用法が間違ってるような。>i18n は言語や地域を外部設定できる(ソースの変更やリコンパイルなしで変更できる)機能で、>l10n は i18n 対応したものに特定の言語や地域用の設定を行うことだと思います。(両者は二者択一のモノではありません)
i18n:国際化対応されていない l10n:現地言語化実装というのもありうるのです。古くはnemacsとかUTF-8非対応の頃のNKFとかはそうですね
やっぱり、>揚げ足取りですが、用法が間違ってるようですね。
i18n(国際化)で実現しようが他の手法で実現しようがl10n対応には変わりません。
> i18n:国際化対応されていない l10n:現地言語化実装というのもありうるのです。それは多言語化などの手法でl10n化を行っているだけですよね。
i18nと対立させるならm17n(多言語化)とかであって、l10nじゃないのでは。
＃ p17nはマイナーギャルゲーだったのでAC
Prismaticallization ですね。# それだけなのでAC
メールの場合、(1)基本的にサービスはコンテントのconduitである (サービス提供側は、ヘッダさえ理解できれば中身はopaqueとして扱って構わない、大雑把に言えば。)、(2)コンテントは一対一か特定集団内でやりとりされる、つまりその特定集団内でコンテントフォーマットについて合意が取れていれば問題は起きない、という特質があるためじゃないでしょうか。
Webサービスであっても同じような特徴を備えていればutf-8にこだわる必要はないと思うのですが、普通に作ると送り手も受け手も不特定になっちゃうので、そうしたらなるべく広い範囲を一律にカバーできるコードがいいや、ということになってるんじゃないかと。
7bitしか通さない環境と言えば、メールはIP reachableな範囲より広い範囲までuucp/BITNETの昔から転送されてきましたので、IP reachableな世界を全世界とみなして、その外にゲートウェイを通じてつながっている世界を切り捨てる覚悟が必要になるのかもしれません。
MIME以前の環境なら、7ビットしか通さないとかいう議論もあったでしょうが、今の今時、文字エンコーディングが指定されていないメールなんて、実用的にはないに等しいはず。
ならば、ゲートウェイだって、そのエンコーディング指定（Content-Type: ヘッダーフィールドのcharsetパラメーター）を読み取って、適切に変換すればいいわけではないかと。
よし、IPv6 reachableな環境を全世界とみなして、それ以外を切り捨てよう!
もうUTF-8は解禁だと思うんですけどね。多国語なメールは実質UTF-8しかないですし。ただ個人的には、メールのファイルはそのまま人間が読めるテキストファイルであって欲しい。ファイラーで中身を見たりすることもあるし、いろんなテキスト処理を行うこともあるし。UTF-8だとbase64変換がかかってしまいそのままでは読めないので面倒。
そういう意味では、UTF-8なんて最近の話で、メールは8ビットクリーンじゃないということを未だに引きずっている点を何とかしてほしい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
グローバルなサービスが増えたから (スコア:1)
例えば Twitter を UTF-8 以外で提供することは考えにくいです。
各種の Wiki や、blog なども多言語に対応させるため UTF-8 がほとんどだと思います。
l10n よりも i18n の流れが進んだのでしょう。
# 私の場合、テキストエディタのデフォルトが UTF-8 だし、最近はほとんどのテキストデータで UTF-8 です。
# UTF-8 以外を使うのは、メールぐらいですかね。
Re: (スコア:0)
> l10n よりも i18n の流れが進んだのでしょう。
揚げ足取りですが、用法が間違ってるような。
i18n は言語や地域を外部設定できる(ソースの変更やリコンパイルなしで変更できる)機能で、l10n は i18n 対応したものに特定の言語や地域用の設定を行うことだと思います。(両者は二者択一のモノではありません)
今回のトピックにあわせていうなら、UTF-8だけで足りるようになったから i18n とか l10n は過去のモノになりつつあるという感じでしょうか？
Re: (スコア:0)
>揚げ足取りですが、用法が間違ってるような。
>i18n は言語や地域を外部設定できる(ソースの変更やリコンパイルなしで変更できる)機能で、
>l10n は i18n 対応したものに特定の言語や地域用の設定を行うことだと思います。(両者は二者択一のモノではありません)
i18n:国際化対応されていない l10n:現地言語化実装というのもありうるのです。
古くはnemacsとかUTF-8非対応の頃のNKFとかはそうですね
Re: (スコア:0)
やっぱり、
>揚げ足取りですが、用法が間違ってる
ようですね。
i18n(国際化)で実現しようが他の手法で実現しようがl10n対応には変わりません。
> i18n:国際化対応されていない l10n:現地言語化実装というのもありうるのです。
それは多言語化などの手法でl10n化を行っているだけですよね。
i18nと対立させるならm17n(多言語化)とかであって、l10nじゃないのでは。
＃ p17nはマイナーギャルゲーだったのでAC
Re: (スコア:0)
Prismaticallization ですね。
# それだけなのでAC
Re: (スコア:0)
Re: (スコア:0)
メールの場合、(1)基本的にサービスはコンテントのconduitである (サービス提供側は、ヘッダさえ理解できれば中身はopaqueとして扱って構わない、大雑把に言えば。)、(2)コンテントは一対一か特定集団内でやりとりされる、つまりその特定集団内でコンテントフォーマットについて合意が取れていれば問題は起きない、という特質があるためじゃないでしょうか。
Webサービスであっても同じような特徴を備えていればutf-8にこだわる必要はないと思うのですが、普通に作ると送り手も受け手も不特定になっちゃうので、そうしたらなるべく広い範囲を一律にカバーできるコードがいいや、ということになってるんじゃないかと。
Re: (スコア:0)
# UTF-8 を読めない相手なんざ知らんてな殿様商売してるアクセンチュアみたいな業者はどうか知らんですが
Re:グローバルなサービスが増えたから (スコア:1)
7bitしか通さない環境と言えば、メールはIP reachableな範囲より広い範囲までuucp/BITNETの昔から転送されてきましたので、IP reachableな世界を全世界とみなして、その外にゲートウェイを通じてつながっている世界を切り捨てる覚悟が必要になるのかもしれません。
Re:グローバルなサービスが増えたから (スコア:1)
MIME以前の環境なら、7ビットしか通さないとかいう議論もあったでしょうが、今の今時、文字エンコーディングが指定されていないメールなんて、実用的にはないに等しいはず。
ならば、ゲートウェイだって、そのエンコーディング指定（Content-Type: ヘッダーフィールドのcharsetパラメーター）を読み取って、適切に変換すればいいわけではないかと。
Re: (スコア:0)
よし、IPv6 reachableな環境を全世界とみなして、それ以外を切り捨てよう!
Re: (スコア:0)
中国語等々って8bit系じゃなかったかな? あれってEUC系?
Re: (スコア:0)
もうUTF-8は解禁だと思うんですけどね。多国語なメールは実質UTF-8しかないですし。
ただ個人的には、メールのファイルはそのまま人間が読めるテキストファイルであって欲しい。
ファイラーで中身を見たりすることもあるし、いろんなテキスト処理を行うこともあるし。
UTF-8だとbase64変換がかかってしまいそのままでは読めないので面倒。
そういう意味では、UTF-8なんて最近の話で、メールは8ビットクリーンじゃないということを
未だに引きずっている点を何とかしてほしい。
Re: (スコア:0)
日本製のもの以外で、多言語対応なメーラだと何も設定変えなければ UTF-8 が当たり前になってません？
シンプルなメーラだったら、送信は UTF-8 以外未対応なんてのも多いです。
プロプラな物でも、オープンソースなものでも、このへんに差があるようには見えません。