アカウント名:
パスワード:
自分の使いたい言語でメニューや警告文を表示させたければこのオープンな部分に リソースを追加するだけでいいからです。 見た目のカスタマイズの許可もここを使って
ありがとうございます。こーゆー説明が聞きたかったんですよ。
興味はあるけど、いかんせんMacユーザーじゃない#517106のAC。
文字コードじゃなくて、Mac OSの多言語対応フレームワーク [osaka-gaidai.ac.jp]の話じゃないかと思うんですが。このあたりって、OS Xで劇的に変わったって印象は無いんですけど。
# 昔みたいにLanguage Kit買わなくても良くなったのかな?
#517106のACです。
あなたの#517096での
>OS9時代から有るアプリでそのままcarbon化されてOSX対応した >ものって、その仕組みじゃないものも結構あったりして、
という部分は「OS9時代のアプリを単純に移植しただけでは、OS Xの新機能を生かせない」という風に読めたんですが。それに対して、MacOSの多言語フレームワークってOS9よりもっと前からあったんじゃないの?OS Xで何か変わったの?と言っただけで。
OS本体の
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
Mac OS Xは80言語以上対応している? (スコア:1)
対応しているようです。
マルチランゲージ対応 [apple.co.jp]...対応言語リストがないですね(^^;
Windowsではこれからってことは、Longhornで
OSとアプリ双方での対応が必要 (スコア:3, 参考になる)
ものすごい数の言語がずらーっと並びます、
けれどもアプリケーション側もちゃんとローカライズした文字列を用意しておかないと、
そのアプリつかってるときだけ英語表示になっちゃいます。
つまり、OSが用意している文章の表示と、文字入力はその言語になるけど
アプリの警告文とかプルダウンメニューは相変わらず英語のまま、
ということになってしまいます。また、テキストエディタの類など、
テキストの文字コードの扱いをアプリ側できちんとやってくれないと、
その言語で文字入力できても保存したりメールで送ったり
Re:OSとアプリ双方での対応が必要 (スコア:1)
アプリケーションのコアな部分とオープンにしておく部分を切り分けている
OS X のアプリケーションバンドルの仕組みはよくできていると思います。
自分の使いたい言語でメニューや警告文を表示させたければこのオープンな部分に
リソースを追加するだけでいいからです。
見た目のカスタマイズの許可もここを使って
現実 (スコア:1)
OS9時代から有るアプリでそのままcarbon化されてOSX対応した
ものって、その仕組みじゃないものも結構あったりして、
思想としては良くできているんだけど、実際の利用状況は、というと
ちょいと難ありな感じもします。とくに大規模なアプリは。
また、独自に言語部分だけ別ファイルにしているPhotoshopのような
例も有ります。(tw10428.datというファイルに一括してローカライズ
された部分が入っている様子。テキストエディタで開けると見られます)
Re:現実 (スコア:0)
MacOS Xで大きく変わったこと (スコア:2, 参考になる)
1.メッセージやメニューの多国語化
言語毎に複数のメッセージを用意しておき、稼働環境に応じて適切な言語を選択して表示する。
2.文字列処理の多国語化
ワードブレイクやワードラップなど、言語に応じて処理を変える必要がある。アプリケーションによっては、1バイトコード前提で作られているものもあるので、そうしたものでは文字列処理を根底的に作り直さないといけない場合もある。
1については、Classic MacOSではOSの支援はありませんでした。メッセージやメニュー、ダイアログなどのテキストはリソースで持ちますが、Classic MacOSの実行ファイル形式では、リソースは標準では一つしか持つことはできません。もし多国語化を行おうと思ったら、OSの支援によらずに、アプリケーション側で独自に複数のリソースを持ち、切り替えなくてはなりませんでした。
MacOS Xでは、バンドルという仕組み(元はNeXTにあった機能)が導入され、言語毎に複数のリソースを持てるようになりました。アプリケーション側で特に意識してプログラムを書かなくても、OSの稼働言語に応じてリソースが切り替わります。(実は、バンドルはMacOS 9でも利用できます。しかし、本格的にバンドルを活用するようになったのは、MacOS X以降です)
2については、Classic MacOSではOSの提供するScript Managerを利用して実現していました。Script Managerは、言語に依存するテキスト処理サービスを提供するライブラリです。しかし、プログラムを作成する立場からいうと、Script Managerは、お世辞にも使いやすいとはいえないものでした。また、後期のClassic MacOSでは、ユニコードのサポートが導入されました。しかしこれも実態は、ユニコードと他のエンコーディングのテキストとの間の単なるコンバータであり、とても使いにくいものでした。
MacOS Xでは、Core Foundationによってユニコード・ベースのテキスト処理ライブラリが提供されています。これは汎用性も高く、Script Managerよりもはるかに使いやすいものです。
エンドユーザの視点では、MacOS Xで大きな変化はないように思われるかもしれません。でも、プログラムを作成する立場からすると、とても大きな変化がありました。MacOS Xでは、以前よりもずっと多国語アプリケーションが作りやすくなっています。
参考になる:+1 (スコア:0)
ありがとうございます。こーゆー説明が聞きたかったんですよ。
興味はあるけど、いかんせんMacユーザーじゃない#517106のAC。
Re:現実 (スコア:1)
リソースフォークを言語ごとに用意して切り替えられるみたいな感じ。
>WorldScriptだっけ?
いや文字コードとかのことじゃなくて、おのおの用の
文章そのものを用意するやりかたのことです。
具体的には、「File」=「ファイル」、「Open」=「開く」、「Edit」=「編集」
のように置き換えるローカライズのことのほうです。
World Script (スコア:1)
文字コードじゃなくて、Mac OSの多言語対応フレームワーク [osaka-gaidai.ac.jp]の話じゃないかと思うんですが。このあたりって、OS Xで劇的に変わったって印象は無いんですけど。
# 昔みたいにLanguage Kit買わなくても良くなったのかな?
話題の中心がずれているような (スコア:1)
OSXの売りはまさにそこだと思いますが…「劇的に変わった」とはまず誰も言っておりません
「初めから入っている」
「簡単に切り替えて使える」
が売りだと思います。そしてそれはOSX10.0のころから宣伝文句として言われてきたことだったはずです。
スレ立て主のnInfo氏も「80言語以上既に対応しているようです。」と、たくさんの言語に対応していることを
称賛したのであって、構造が劇的に変わった云々とは言っていませんし。
私の話は、80カ国対応するために、80通りの「翻訳語」を、用意するのは“人力”作業であり、
OSのフレームワークが自動的にやってくれる作業ではなく、並大抵の努力では済まない、という事です。
WorldScriptという単語が出た時点で(話しがズレてるな)という予感があったので、
わたしの探りの入れ方も意味が分からなくなっていますが、そういうことですんで。
Re:話題の中心がずれているような (スコア:0)
#517106のACです。
あなたの#517096での
>OS9時代から有るアプリでそのままcarbon化されてOSX対応した
>ものって、その仕組みじゃないものも結構あったりして、
という部分は「OS9時代のアプリを単純に移植しただけでは、OS Xの新機能を生かせない」という風に読めたんですが。それに対して、MacOSの多言語フレームワークってOS9よりもっと前からあったんじゃないの?OS Xで何か変わったの?と言っただけで。
OS本体の