多言語化が面倒かはウインドウやコントロール類のアイテムを動かさずに済むかどうかで大きく違うと思うんだけど、単に文字列の入れ替えで済むなら簡単。
言語によって文字の長さが変わってくるのでそれが隣のコントロールに重なったり近付き過ぎるようなら別の表現を探るかコントロールの位置をずらさなきゃならないから、UIの見た目のデザインバランスも含めて落とし所を決めていくわけだけど、Appleのように見た目や表現に拘る企業なら単に言語の入れ替えで済まなかった場合に時間がかかるのは仕方ないと思うよ。
ちなみにOSによって同じようなサイズのフォントでもフォントデザインの違いなどもあってサイズが変わってくるから、例えばOS X では言語ファイルの入れ替えで済んだけどWindows用の場合はコントロールの位置も含めて検討する必要が出て来たとしても不思議じゃあない。それもあって製品によってはフォントも同じモノを付属させていたりしているし。
国際化対応アプリケーション (スコア:4, 興味深い)
Mac OS Xはアプリケーション自体がマルチリンガル仕様になっているので、1つのバイナリで複数の言語に対応できるのですが、Windows はそうなっていないため、言語ごとにバイナリを用意しなければなりません。
iTunesだけの事を言っているのか、それとも各OSでのアプリケーション一般のことを言っているのかちょっと掴めなかったのですが、
Windows上でマルチランゲージアプリケーションを作成するには
- 言語ごとにバイナリを用意する
- バイナリ内に複数の言語用リソースを持っておく
- 言語依存なリソースをバイナリ外部のファイル(DLL)等に分離し、アプリケーションから動的に切り替える
等の方法があります。iTunesは言語毎のバイナリですね。最後の動的切り替えを行う場合、事実上、ApplicationがUnicodeEnableになっていないとチト辛いです。この仕掛けを使っているのがWindows MUIPackageです。
また、上3つは「各国語で別々のHelpFileやUIを用意」する場合の話で、UIが英語のままで良いのならば、今の英語版iTunesは日本語Windowsで問題なく使用可能です。
何れにせよ、Windows・MacOS云々というよりはApplication側の国際化対応への気合い・スキルの問題ではと思います。
おまけ Microsoft GlobalDev [microsoft.com]
Re:国際化対応アプリケーション (スコア:2, 参考になる)
いくつかのアプリで、日本語/中国語/英語の各言語OSで起動時にアプリの使用言語を切り替えるように開発しました。(3つ目の方法ですね)
WindowsとMacの両方で開発してみればわかりますが、Windowsの各言語対応は「気合い・スキル」が非常に必要だと思います。(簡単な方法があれば知りたいです)
Macは気合いもスキルもいりません...(言語のスキルは必要か...)
P.S. アップルもうちに頼んでくれれば1週間でローカライズしてあげたのに...
Re:国際化対応アプリケーション (スコア:0)
Windows での多国語化に気合やスキルが必要になる箇所がさっぱり思いつきません。
VC++5 (4 は触ったことない)の世代でも、 多国語化するためのリソース管理についてIDEにもサポートがありました。
大変なのは、そ
Re:国際化対応アプリケーション (スコア:1, 参考になる)
VCってそこまで簡単にできたっけ。
Re:国際化対応アプリケーション (スコア:1)
VCで作る課程でも単語そのものはダイアログ等とは別リソース扱いにして文字列をテキストに落としておいてそこから拾ってくる小さいclassを作って LoadString を使う代わりにソレを利用すればよいだけ。
別のコメントにある「複数から成っているけど一つに見える」というのも特別難しい事をしなくても実装は可能。
例えば C:\WINDOWS\Tasks の中はコマンドプロンプト経由でファイルをコピーしてもそれがExplorerで表示される事はないんだけど、このように実体と見かけが異なるようにするというのはあるルールに則ったコンポーネントを作っておけば好きなように見せる事が出来る。
勿論それを開いて言語ファイルの変更が可能という部分も含めて。
他にも専用のアーカイブフォーマットを作って、実際に一つにまとめた上でそれをアクセスするコンポーネントを用意するという方法でも可能だし。
これをデフォルトで用意したAppleがえらいかと言うと、見え方を変更する仕組みについては、これを悪用してSpywareが自身の隠れ場所に利用したりしている(単にExplorerから見えないというだけなんだけど)のもあるから個人的には姿勢は評価します...という程度です。
それ以外の仕組みも別段手間でも何でもない程度の事なので単に設計方針次第という事でしかない。
逆に簡単に文字列を変更できてしまうのを嫌う方針の会社である場合もあるし、万が一言語ファイルが壊れたときに壊れた事を検出方法や動作はどうするか考える必要が出てくる場合もある。
多言語化が面倒かはウインドウやコントロール類のアイテムを動かさずに済むかどうかで大きく違うと思うんだけど、単に文字列の入れ替えで済むなら簡単。
言語によって文字の長さが変わってくるのでそれが隣のコントロールに重なったり近付き過ぎるようなら別の表現を探るかコントロールの位置をずらさなきゃならないから、UIの見た目のデザインバランスも含めて落とし所を決めていくわけだけど、Appleのように見た目や表現に拘る企業なら単に言語の入れ替えで済まなかった場合に時間がかかるのは仕方ないと思うよ。
ちなみにOSによって同じようなサイズのフォントでもフォントデザインの違いなどもあってサイズが変わってくるから、例えばOS X では言語ファイルの入れ替えで済んだけどWindows用の場合はコントロールの位置も含めて検討する必要が出て来たとしても不思議じゃあない。それもあって製品によってはフォントも同じモノを付属させていたりしているし。
Re:国際化対応アプリケーション (スコア:0)
おそらく実際に問題になっているのは、私(やあなた)から見れば全く問題にならない部分でしょう。すなわち、Windows版の方はプログラマを必要とするのに対し、MacOS版の方は必要としないことです。プログラマが一人も居ない下請け(の会社や部門)--そういうところにはVisual Studioすらない--に発
Re:国際化対応アプリケーション (スコア:2)
Windowsでも単一バイナリで複数言語に対応できるとのことですので、上記部分は削除しました。御指摘に感謝します。
Re:国際化対応アプリケーション (スコア:1)
それでも、複数言語に対応させるのは Mac OS X ほど簡単でなさそうで、残念ですね。
Re:国際化対応アプリケーション (スコア:0)
Windowsの場合は、その部分をDLLの形で別ファイルにしちゃうのが一般的。Macはバイナリ埋め込みなの?別ファイルの方が
Re:国際化対応アプリケーション (スコア:2, 参考になる)
OSXのアプリケーションの実態は拡張子".app"が付加されたフォルダになってて、
その中に実行バイナリと画像や各国語リソースなどが格納されてます。
OSX版Mozillaもダウンロードすると1つのファイルになってます。
iMoveともなると1つのアプリケーションファイルに見えるのですが、
100MBぐらいのサイズになってます。
これらの仕掛けでユーザーから見ると、どんな巨大アプリでも1つのファイルなので、
シンプルで使いやすくなってます。
このページ [msyk.net]にその辺の仕組みと実態が解説されてます。
Re:国際化対応アプリケーション (スコア:0)
言語別に別ファイルで保存してるんだけどね。ただそれがユーザからは一つのファイルに見えるだけ。
そういうわけで、残念なのはあなたのの知識ではないかと。
Re:国際化対応アプリケーション (スコア:0)
それもほんとに「見かけだけ」で右クリックで中開いて見られたりするんですよね。
で開いた中身をXCodeで開いて関西弁に書き直したり。
#昔MacOSのメッセージ類を全部関西弁にしてしまうパッチがあったなあ。
Re:国際化対応アプリケーション (スコア:0)
ここはスラドですよ。