＜深夜テレビ＞温暖化対策で自粛促す ― ネットは？

ここのニュース
＜深夜テレビ＞温暖化対策で自粛促す意見相次ぐ　自民党
http://headlines.yahoo.co.jp/hl?a=20080304-00000069-mai-pol
によると（以下斜体は上記サイトより引用）


　自民党が４日開いた総務会で、地球環境問題や原油高騰を理由に深夜のテレビ放送の自粛を促す意見が相次いだ。


　たしか、オイルショックのころって、そんな感じだった気が・・

　でも、そのころと、おーきく違うことは

　深夜放送を中止しても、みんなネットに流れるだけだよねー（－＿－；）

　ネットは・・・規制できないよねえ・・
　（まさか、夜間になったら、帯域狭くするとかは。。。問題になりそうだし）
　深夜のネットが規制できない以上、期待するほど効果ないかも・・？

mixiに記事をアップしたら、mixiが日記を勝手に出版しても、文句言えなくなるらしい

ここのスラッシュドットニュース
mixiが規約変更予定、日記の無断出版が可能に
http://slashdot.jp/articles/08/03/04/0153234.shtml
によると(以下斜体は上記サイトより引用）


「mixi」が4月1日付で規約を変更するらしいのだが、その18条がこういうふうになるらしい。


第18条　日記等の情報の使用許諾等
本サービスを利用して、ユーザーが日記等の情報を投稿する場合には、ユーザーは弊社に対して、当該日記等の情報を日本の国内外において無償かつ非独占的に使用する権利(複製、上映、公衆送信、展示、頒布、翻訳、改変等を行うこと)を許諾するものとします。
ユーザーは、弊社に対して 著作者人格権を行使しないものとします。


ということは・・・


つまり、mixiに記事をアップした段階で、mixi側がユーザーの日記を勝手に出版しても、一切文句は言えない


かつ・・


2 本利用規約の施行前にユーザーによって行われた行為についても本利用規約が適用されます。


ひえー、じゃあ、mixiから流出した、あんな写真や、mixiに今アップされている、こーんな写真も、「mixi写真集」とかいって、出版できちゃったりする・・・って、すごくない！！

ほかのSNSやブログも、これに見習ってやるのかなあ・・？
まあ、ブログは公開前提だから、あんまり、問題ないかもしれないけど、SNSだと、問題ありそうな気がする。。（友達同士どころか、非公開のものを公開してもOKってことでしょ　＠＿＠！）

---

ま、mixiはやってないので、関係ないのですが、

もし、gooが同じことをやって、このブログから、

「BREW自動化完全攻略？」とか、
「Excelを使ってXBRL」とか、
「開発の最初から最後まで」とか

の本を出したとして・・・

まあ、そのお金が入ってこないのはいいんだけど、

なんか、困ったことがおこったときに、
そーいうときだけ、

「いや、このウィリアムのいたずらが書いたんですぜ、だんな！」

とか言われるのは困るよなあ・・・

---

そーかんがえると・・・ちょっとまて！、これ、

　・mixiが、非公開の日記を公開して、本にする
　・それが名誉毀損で訴えられた

場合、告訴されるのは、mixiなの？書いた本人なの？
本人は「非公開」にしているのに？？

P.S
　なお、もし、gooの規約がかわって、ここのブログを本にする場合は、
　とくにBREWは、KDDI監修のもと、チェックするのが賢明です。

　言っちゃいけないことかいてるかもしれないし。。。

　それ以外にも、
　すでに、自動生成Excelシートのmakebrewにバグがあるのではないの？
　という指摘はメールでいただいてます
　（そのメールをくれた人、ごめんなさい。今、brew環境が手元になく、
　　確認できないんです。メールは、見ました）
　　

翻訳機を使って、ローカライゼーションする場合の手順をまとめてみる－その１。

　Eclipse 3.3 日本語化言語パックβ版の話を書いたところ（ここ）で頭の体操で、こーいう翻訳ツールを使った場合の日本語化の手順って考えてみようかなって書いた話。

　コミュニティの翻訳にはかかわったことないけど、商用のローカライゼーションはやったことがあって、そのときの失敗から、こーすれば、いいんじゃね？という考え＋OSCで話があった、いままでEclipseの開発をIBMがやっていたときの話を、自分の経験と比較し、やっぱこうだよね！という考えをまとめてみる（ということで、失敗したところは隠し（＾＾；）こーやればよかったと思うことを書いているので、実際やってない部分がある）。

---

■たぶん、開発に限って言うと、大きく３つの部分に分かれる。

　ローカライゼーションの場合、開発と、マニュアルが、新規製品と大きく違うところだと思う。
　で、今回は、開発に限った話をします。

　たぶん、開発に限って言うと、大きく３つの部分に分かれると思います。

　　　（１）国際化対応プログラムになっているか確認
　　　　　　　→ある国固有の状況になっていないか
　　　　　　　　（文字コードを数値で埋め込みとか）
　　　　　　　　確認および修正

　　　（２）翻訳＆前のバージョンのものを入れる

　　　（３）翻訳したものを戻し、稼動するか確認
　　　　　　　→文字長すぎとか、動かなくなった（＞＿＜！）とか
　　　　　　　　問題あれば修正

　で、以下、その内容を書きます。

---

■（１）国際化対応プログラムになっているか確認

　ここの部分は、Eclipseに関して言えば、IBMがマニュアルを作って、確認してくれているそうですが、普段だと、チェックポイントを作って、自動、あるいは手動でチェックすることになります。

　ただ、これ、めんどっちかったら、（２）でやる、ID用のものをつくると、簡単にチェックできます。

　問題があれば、修正してもらいます。
　これで、
　　　　・各国共通のソース部分
　　　　・翻訳必要な、文字列のあつまり（＝メッセージカタログみたいなやつ）
　にわかれます。

　なお、もともと、ソースに文字列が埋め込まれている場合は、チェックをやる前に、「翻訳必要な、文字列のあつまり」を自動的に切り出すこともあります。（ダブルクウォート内の文字列を別ファイルに書き出し、IDをふり、そのIDを元のプログラムにも書き込む）

---

■（２）翻訳

●翻訳をするとき、以下のコトが要求されます

　　　・頻出の訳語が統一されている
　　　・全バージョンの訳語が、無意味に変更されていない
　　　・意味が通じる訳になっていて、マニュアル・ヘルプと矛盾がない
　　　　　→画面ではこうなっているが、ヘルプでは違う訳ということがない

●そして、以下の点に注意が必要である

　　　・同じ言葉が、同じ訳になるとは限らない
　　　　　例：日本語から、英語にするとする（普通の逆）
　　　　　　　表とあったとき、
　　　　　　　　　　　table（ひょう）と訳すべきか、
　　　　　　　　　　　front(おもて）と訳すべきか？

　　　・画面に入れてみないと、訳がわからない
　　　　　例１：訳語のほうが、長くなってしまうことがある。
　　　　　　　　そのとき、画面がびろーんとなって、困ってしまうこともある。
　　　　　　　　そういう場合は訳語を直す
　　　　　例２：文字数の数え方が間違って配列をとっている
　　　　　　　　（日本語は必ず２文字：UTF-8がきたあ・・（＞＿＜！））
　　　　　　　　こんなとき、英語ではOKなのに、日本語だと落ちるということがある。

この条件を満たすように、手順をくむ。

●手順を組む前に、ここに出てくる用語（成果物・中間物）の説明

・訳語統一辞書：１バージョン１つできる。訳語統一したための辞書
・翻訳元ファイル：「翻訳必要な、文字列のあつまり」を集めたファイルやデータベース
　　　　　　　　　　poファイル（＝メッセージカタログ）とかが相当するが、
　　　　　　　　　　共同作業の場合、このデータをDBにいれ、最終的にできたところで
　　　　　　　　　　poファイルのようなフォーマットにするので、必ずしもファイルでは
　　　　　　　　　　ない（が便宜上、ファイルとよぶ）
　　　　　　　　　　メッセージIDと、メッセージからなる

・ステータスファイル：現在の状況をファイル化したもの
　　　　　　　　　　　メッセージIDとステータスからなり、poファイルなどの、
　　　　　　　　　　　メッセージカタログと同じフォーマットになる
　　　　　　　　　　　（メッセージに、メッセージID　ステータスを入れたものが入る）
　　　　　　　　　　　DBの場合は、ステータス項目が、メッセージテーブルに追加される
　　　　　　　　　　　だけなのだが、翻訳元ファイルでpoファイルが作れたように、
　　　　　　　　　　　DBから、上記ステータスファイルが作れると、実は便利である。

・翻訳後ファイル　　：翻訳したpoファイル（これはファイル）
　　　　　　　　　　　DBにある場合でも、翻訳した結果をファイルにしたものを
　　　　　　　　　　　ここではさす。

・ソースファイル　　：翻訳の必要のない部分

　　　　　　　　　　　

---

ぎゃー、手順を書こうとしたら、もう、こんなに書いてしまった。

ということで、手順は、また今度、書きますね。