日本語化

NT Committee2
石坂忠広
MVP for Visual Developer C#




http://www.isisaka.com/
NT-Committee2会員
PASS-Jスタッフ
Microsoft MVP for Visual Developer C#





なぜ国際化なのか
従来の国際化(日本語化)
World Ready
ローカライズ
文化・カルチャ？


企業の多国籍化
オフショア
 日本語がネイティブでない環境での開発
 コア部分開発とUI部分の分業

国内市場の行き詰まり
 日本以外のマーケットを開拓する

すべてが日本語化されるべきと期待される今
の特権的地位はいつまで続くだろうか

いずれかの言語でアプリケーションを開発す
る
 たいていは英語で開発する。

それを各国語に翻訳する。
 リソースDLLは分かれているか？
 バイナリリソースエディタでテキストを置き換える
 ソースコード内のテキスト文字の翻訳
 sed s/hoge/ほげ/でうまくいくのか

バイナリリソースエディタ
 そもそもオリジナルの作成者が国際化を前提に、
リソースを外部DLL化してくれていないといけな
い。
 確かにテキストの置き換えは簡単にできる。
 エリアからはみ出す文字、余りすぎるテキスト
ボックス。文字が途中でとぎれるボタン。
 エディタでリサイズ・チェック、リサイズ・
チェック
 ああ「能」の字が化けてる。orz

ソースの変更
 ああここも直ってない。。
 一千も二千もあるソースリソースからテキストを見
つけ出さなくちゃいけない。
 エラーメッセージが英語だよ。
 そ、それは、英語ランタイムが出すメッセージだか
ら直せないんだよ。。。
 やっぱり「能」の字が化けるよ。orz
 バックスペースしたら、漢字が半分無くなったよ。



日本語ランタイムと英語ランタイムの違いが
あり、日本語を正常に扱うには日本語の開発
環境でビルドが必要。
でも、どことは言わないけど日本語ランタイ
ムには英語にないバグがっ
そもそも開発元が日本語環境でのビルドを許
してくれない。(ソースを渡してくれない)


まだこの状態で苦しんでおられる方が多いと
思います。
根本的解決策は、なんとしてもソースコード
を入手すること、翻訳後のソースは向こうで
管理させることです。
 もしくは、根本的に作り替えるこ
と！


言語を問わずシングルバイナリを目指して開
発すること
Windowsのもつ国際化対応機能を柔軟に使用
し、それらの支援を受けながらアプリケー
ションの仕様決定、開発を行う。
 開発を二つに分ける
 Core CodeのGlobalization化
 リソースDLLによるLocalize








Unicodeに完全対応したアプリケーションを記述す
る
コード内で数値、金銭、日付等のフォーマッティン
グを直接行わない
テキスト入力の言語、入力方法の違いを考慮する
特定のフォントに依存させない
テキスト中の複数言語混在に対応させる(m17n)
MUIに対応させる
UIのローカリゼーション容易性への配慮
右から始まる言語への配慮(UIのミラーリング)


UNICODE自体の説明は省きます。
以下の点はまず注意してください
 Windowsのバージョンによって、対応している
UNICODEのバージョンが違います。
 その他、Java, VB, VC++(CRT)のそれぞれのバージョ
ンが持つランタイムでも対応しているUNICODEの
バージョンが違います
 これで何がまずいか？
 使える文字と使えない文字が出て
きます

Windows 2000
 UNICODEに完全対応した最初のバージョン
 UNICODE 2.0
 UCS-2エンコード

Windows XP / 2003
 UNICODE 3.0
 UTF-16LE以下同様

.NET Framework
 UNICODE 3.2
 いわゆるJIS2004の文字を含む

Windows Vista / 2008
 UNICODE 5.0

SQL Server(7.0以降)
 UCS2 + サロゲートペアに対応
 一応UNICODE 3.0以降の文字もnchar, nvarchar
フィールドには格納できる。
 ただ、いろいろ問題が。。
 詳しくはPASSJアフタースクールへ(宣伝)

Officeは？Exchangeは？？？？


アプリケーションをUNICODE対応とするには
ネイティブコード
 あんまり詳しくやりません(終わらなくなる)
 #define UNICODE
 Visual StudioではWizardの中でチェックをする/しない
 文字列
 LPTSTRマクロを使う(UNICODEがDefineされていれば
自動的にLPWSTRに変えてくれる)
 文字列定数の前には大文字のLをつける
 LPTSTR str = L”僕の名前は石坂忠広です。”;
 MFCが使えるならCStringクラスを使う
 COMはVT_BSTRで
 これらは相互変換のマクロ、クラスメソッドがある

.NET Frameworkでの開発
 .NET FxはUNICODEに完全に対応
 内部では文字列はUTF-16でエンコードされる。
 char型は2バイト
 ただし、テキスト入出力とXMLのデフォルトエン
コーディングはUTF-8なので注意。
 基本的にIEが使用できる文字コード(ShiftJIS/EUC.jp)にはファイル入出力の時点で変換する
ことが出来る。同様にコードページを指定したエ
ンコード、デコードも可能。

WEB Page
 基本的にはW3Cの標準通り。
 現状はUTF-8を推奨

Java
 内部はUTF-8

コマンドプロンプト
 基本的にUNICODEには対応していない
 ただし、表示できる範囲ではUNICODEとの相互
変換が自動的に実行される

Locale(ロケール)
 本来は英語の意味通り地域(ローカル)を表す。
 かつてC言語標準化の中で、ローカル変数の
「ローカル」と紛らわしいとされ、訳語が「ロ
ケール」に統一されたと聞いています
 Windowsでは特定の国や地域の言語と文化上の慣
例を反映させた Windows 設定のコレクションの
意味です。

System Locale
 UNICODE以外での言語環境を特定します。
 DOS, OS/2, Win16でのCode Pageに該当します。
 いわゆるANSI APIが使用された場合、この設定に
より実際の言語・文字コード(CP)が特定されます。

User Locale
 User毎に設定するLocale。
 設定は小林さんスライド参照。
 名前と違い実際には非ログオンのサービスアカウ
ントにも影響

Thread Locale
 実行単位毎に持つLocale。何もしなければUser Locale
を継承する。
 つまりUser Localeと違うロケールをスレッド毎に持
つことも可能

Input Locale
 文字入力のLocale。
 言語ツールバーで設定する。
 インプットメソッドの切り替え

User Locale以降のLocale操作、状態の取得、機
能の使用にはNLS APIを使用する。


WindowsおよびWindows上に実装されたアプ
リケーションで複数地域・複数言語に対応す
るためのAPIセット
NLS APIが持っている機能





現在のLocale設定の取得
動的なThread Localeの変更
数値、日付等のフォーマット
ロケールに合わせた並び替えの支援
Input Method系のAPI




NLSの各設定（書式とか）はLCIDで管理されている
NLS APIに何か仕事をさせたい場合にはLCIDでロ
ケールを指定して、仕事をさる。
LCIDはロケール毎に一意に32ビットの整数値で番号
を持つ。
Windows Vista以降で追加されたAPIではLocale
Name(Exp. Ja-Jp)で指定できる場合がある。
 Locale Name:
mshelp://MS.MSDNQTR.v80.ja/MS.MSDN.v80/MS.WIN32CO
M.v10.en/intl/nls_Locale_Name.htm

LCID自体は16ビットのLanguage IDと4ビットのSort IDからなる。
 mshelp://MS.MSDNQTR.v80.ja/MS.MSDN.v80/MS.WINCE.v50.en/wceinter
national5/html/wce50conSpecifyingLocaleswithNLS.htm

Language IDは言語とその文字集合を表す数値
 mshelp://MS.MSDNQTR.v80.ja/MS.MSDN.v80/MS.WIN32COM.v10.en/msa
gent/pacontrol_4w2y.htm

Sort IDは照合順序(Collation)を表す数値
Language ID
Reserve
Sort ID
Sub Language
Primary Language
12bit
4bit
6bit
10bit
Locale ID


.net FxではCultureInfoクラスでLCIDを管理す
る。
カルチャの名前、書記体系、使用される暦、
日付の書式設定と文字列の並べ替え方法など、
特定のカルチャに関する情報を提供する。
全ロケールの取得とカレントロケールの取得


日付の書式
通常どちらかの書式を使用する
 Long Format(長い形式)
 英語(US)：Saturday , October 27, 2007
 日本語：2007年10月27日
 Short Format(短い形式)
 英語(US)：10/27/07
 日本語：07/10/27

日本の年号への対応、ヘブライ歴等の西暦以外
への変換


テキストフォーマッティングの書式で日付書
式文字の”d”(Short Format)や”D”(Long
Format)等を使用する。
逆に”YYYY/mm/dd hh:mm”のような固定書式
にしてはいけない。
 このように記述してしまったコードはもはや
Globalization対応とは言えない

http://msdn2.microsoft.com/jajp/library/az4se3k1(VS.80).aspx
日付のフォーマッティング

12時間か24時間か
 時刻の書式文字で区別
 hまたはhh:12時間計、HまたはHH:24時間計


時分秒の区切りに文字を使うのか
タイムゾーンと現在時刻
 NLSのロケールで現在時刻を求めないので注意
 TimeZone設定でUTCから現地時間の算出を行う
 そのときには夏時間の設定がそのタイムゾーンに
あればそれを考慮して現地時間を算出する
Vistaでは世界地図が無くなって寂しい

時刻書式の詳細は書式文字列を使って行う
 カスタムの書式
http://msdn2.microsoft.com/jajp/library/8kb3ddd4(VS.80).aspx

TimeZone
 TimeZoneに関する操作はSystem.TimeZoneクラ
スを使用します。
 http://msdn2.microsoft.com/jajp/library/system.timezone.aspx
時刻書式とTimeZoneの処理

金銭の単位
 日本：\
 アメリカ：$


マイナス値の表示方法
小数点
 日本・アメリカ：「.」
 欧州：「,」

桁区切り
 日本・アメリカ：「,」
 欧州：「.」


テキストフォーマッティングの書式で金銭書
式文字の”c/C”や十進数書式”D”等を使用する。
日付の場合と同様固定書式にしてはいけない。
 このように記述してしまったコードはもはや
Globalization対応とは言えない
 標準の数値書式指定文字列
http://msdn2.microsoft.com/jajp/library/dwhawy9k(VS.80).aspx



ロケール毎に文字列の並び替えに使用するため
の文字毎の重み付けと何と何を同じ文字として
扱うかという設定がある。
これをSQL Serverでは参照順序(Collation)と呼
ぶ
ロケール毎に複数の参照順序を持つ場合がある
 現在のWindows Vistaの場合Ja-JPの場合XJIS(デフォ
ルト)と部首・画数の二種類がコントロールパネルか
ら選択可能
 日本語関連 CompareInfo と、部首画数での並べ替え
＠河端善博ブログ / SQL Server / PASSJ
 http://blogs.sqlpassj.org/yoshihirokawabata/archive/2007/
07/27/23864.aspx


.net FxのString.Compare()メソッドやArrayク
ラスのSortメソッド等ではスレッドのカル
チャが持つソート順序を使用して処理を行う
並び替えの設定によっては単純なコード順並
び替えや比較ではないので注意する




ロケールの管理、各種機能はNLS APIにより
提供される
Locale, CultureはLCIDで管理される
日時、金銭、数字のフォーマットは自分で
コードに細かく記述せず、NLSに任せる
テキスト比較はソート順序の設定が使用され、
その設定が目的通りに設定され英無いと予想
外の結果になる



Input Language
Complex Script
Font

Text Service Framework(TSF)
 Windows XP以降Input Method
Manager(IMM/AIMM)がText Service
Framework(TSF)に拡張されていく中で、ただの
アジア言語(日本語)入力機能から、複数言語入力
の切り替え、キーボードマップの動的な変更、音
声入力、手書き入力等への拡張がなされた。
 .net FxではInputMethodクラスで制御を行う



複数言語を同一データ内で同時に入力、表示、
保存させること
UniscribeといわれるUnicode Script
Processor(USP10.DLL)がComplex Scriptの実行
エンジンになっている
Applicationは直接
Uniscribeを呼び出すこと
も出来るし、GDIを通し
Aplication
LPK.DLLにパーシングさ
せることで間接的に使用
LPK.DLL
することも出来る
User/GDI
Uniscribe

Standard Edit Control
 Complex Scriptに関して標準的に対応されている。
 実装例：
 メモ帳(Notepad.exe)

Rich Edit Control
 Text Object Model(TOM)のインターフェイス
 Uよりリッチな多言語環境、マルチフォント環境の提供
 実装例：
 ワードパッド

アプリケーション開発においては、これらのコント
ロールを使用するのが現実的

.net Framework
 .NET Fx 2.0以降ではGDI+のComplex Script対応機能
を使用し、Windows Formのすべてのコントロールで
同レベルのサポートを実現している
 Application.SetUseCompatibleTextRenderingDefault
メソッドをプロセスでFormを最初に作るときに呼び
出すことで、個別コントロールでの設定をなくすこと
が出来る

Complex Scriptに関するMSDN Magazineの記事
 http://msdn.microsoft.com/msdnmag/issues/06/03/Text
Rendering/


最終的に文字を表示できるかどうかはFontで決まる。
Globalizationに対応したFontを使用する
 UIにはシステムフォントを使う
 Windows XP / 2003 / VistaはTahomeを標準に
 はねのないゴシックのLattain-1、ヘブライ語用フォント
 フォントリンクもしくはFallbackでそのほかの言語用フォント
がリンクされており、体裁はともかくとにかく表示はしてくれ
る
 Arial Unicodeの問題
 Unicode 2.0「の」文字はすべて表示可能
 それゆえに表示できない文字がある

Fallback
 Uniscribeが現状フォントで表示できない文字列がある
と判断した場合に、その文字が表示可能なFontを割り
当てる。
 GDI+のテキストレンダリングエンジンが使用する
 そのときにどのフォントを割り当てるか重み付けがあ
るらしく、どうもそれがVistaで変更されようだ。
 かつて漢字が表示できない場合にはMSPゴシックが選択
されたが、VistaではMingLiuが選択される確率が高いよ
うに思える。MingLiuはセリフフォントなので、見た目
が変わりすぎるので困るのだ

Font Linking
 システムフォントが文字列を表示できなかった場
合にどのフォントで代用するかを指定した設定
 レジストリの
HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\FontLink\SystemLinkにその設
定がある
 Font LinkはGDIのレンダリング、GDI+でFall Back
がうまくいかなかったときに使用される


アプリケーションのMUI
MUIの戦略
 言語毎の実行ファイル。各言語リソースは、コー
ドと一緒に一つのバイナリに
 一つの言語ニュートラルな実行ファイルと複数言
語のリソースを含んだ1つのリソースDLL
 一つの言語ニュートラルな実行ファイルと格言午
後とのリソースDLL
 今のWindowsそのものを含む一般的なMUIの戦略

作成手順
 何かの言語で実行ファイルとリソースをビルドす
る。(この時の言語がデフォルトリソースとなる)
 追加リソースのDLLを作成する。

実行時のリソースの選択順序
 まずデフォルトリソースで起動される。
 現在システムのMUIで設定されているロケールと
同じリソースDLLがあればそれをロードする。
 システムのMUI設定にかかわらずUIのロケールを
User Localeにあわせて変更するにはカレントス
レッドのCurrentUICultureプロパティをコンポー
ネントの初期化前に変更する。

＠IT .NET Tips Windowsフォームを多言語対
応にするには？
 http://www.atmarkit.co.jp/fdotnet/dotnettips/314win
multilang/winmultilang.html
 一番簡単で、有用なチュートリアル
 作業が増えるだけで、これ以上でも以下でもない
WinFormでのMUIアプリケーションの作成
UIをUser Localeにあわせて変更する。

ローカライズ対象となるリソースの分離
 文字列だけでなく、図、ビットマップ、ダイアログ
ボックスも必要に応じてCoreのバイナリから分離する。
 .net Fxにおける詳細
 MSDN:リソースのパッケージ化と配置
 http://msdn2.microsoft.com/jajp/library/sb6a8618(VS.80).aspx
 MSDN:固有カルチャのリソースの検索と使用
 http://msdn2.microsoft.com/jajp/library/s9ckwb4b(VS.80).aspx
 MSDN: Windows フォームリソースのローカライズ
 http://msdn2.microsoft.com/jajp/library/yys3e2fd(VS.80).aspx

アラビア語のような右から書き始める言語に
合わせ、諸々のUIを右から書き始めるように
する。
 ツリービュー、グリッドコントロールの開始位置
が右など
 標準コントロールや.net FxのWinFormのコント
ロールでは、各コントロールの右から書き始めを
示すプロパティをセットする。
 .NET Fx ではRightToLeftプロパティが一般的
http://msdn2.microsoft.com/ja-jp/library/aa350685(VS.80).aspx
NLSで対応できない文化的な違いをどうするのか



日本人は感覚的に理解できない
毎時処理等では、夏時間の開始時と終了時に
は1日の時間が24時間ではないので注意が必
要(特別な処理がたいていに場合には必要)
可能な限り時刻をキーとしたデータ管理では、
時刻データとしてはUTCを使用する。
 時差があってもデータの比較を行いやすくする
 夏時間の影響を排除する




国や地域によって、住所のルールが違う
特に日本は住所から位置の推定が全く出来な
い。600番地の隣が865番地なんて欧米では
ほぼあり得ない
基本は可変長テキストで保存
特定の位置情報が必要であれば、ジオメトリ
のデータを使用する。(経度緯度情報など)

米と欧・日での用紙サイズの違い
 米国はLetter, Legalが標準的な用紙サイズ
 欧・日その他多くの地域はISO(JIS)のA4, A3等の用紙
サイズ
 特定の用紙を前提とした印字処理をしない

プリンタの問題
 欧米：ビジネス用途ならHP-PLかPost Script何れか
 日本：メーカー毎のページ記述言語。。
 WindowsのAPI経由ではあまり大きな問題にならない
が、プリンタドライバ、それの英語版があるか無いか
はかなり問題が起こるポイント
 正直なところ世の中のプリンタメーカはHPだけでい
いです






正直NLS APIで面倒見てくれないかと思う
EUが妥協して、イギリスはメートル法とヤー
ド・ポンド制を併用してよくなった(Fack)
アプリケーションで何とかするしかない
基本はSI単位(SI条約)を使用する
国内では非SI単位の使用は原則システム提供側
が計量法違反
商慣習上必要な場合、法適用外あるいはお目こ
ぼしされる
 真珠の匁（もんめ）
 印刷でのヤード・ポンド制使用

パッケージやアプリケーション内で人物写真
を使う場合何か注意がいるのか？
 多分日本人（多分韓国人、中国人も）には感覚的
に理解できない
 多くの国で、人種、性差に対しての配慮が必要
 子供の取り扱いもかなり微妙



基本的に女性の写真を使うのはNG
イスラム的正しさが必要
ほかのアラブ諸国ではここまで厳しくない

会議を表す図か写真をアプリケーションで使
いたい場合
 あきらめてこれらの図の
ように人物を入れないか、
人としかわからない図に
する



NLSのCultureはあくまでもビジネスの世界か
ら見た地域文化やルールのわずかな一側面に
対応するだけ
UIを翻訳すればLocalizeなんだろうか？
Localizeとは結局その地域の文化にアプリ
ケーションを対応させること
 Excelのふりがな

基本は英語版OS, 英語版Visual Studio
 今でも原則はen-US版アプリケーションを作成し、そ
れを別言語にする

多言語化ターゲットの試験環境
 仮装化環境で用意するのが便利
 パフォーマンス試験が基本言語環境以外でも必要か設
計時に見積もる


MSDN サブスクリプションサービスの購入が必
須
Vistaは本当にシングルバイナリで、多言語開発
環境として英語版以外でもそれが可能なのか？

バージョン管理システムのスケール、柔軟性につい
て考慮が必要
 インターネット環境ではVSSは使い物にならない
 国際イントラネットがある場合には何とかなることもある
 TFSは多国籍間の開発に耐えられるか？
 国をまたがる開発環境での調査、試験は未実施
 Subversion推奨
 TatoiseSVNがある
 Visual Studioのアドインもあるけど使っていません
 ディレクトリ構造にはVS管理のリソース以外のドキュメン
ト等についても多言語であることを留意して標準化を

コメント
 開発チームが複数にまたがる場合、コメントに日
本語やその他のローカル言語を許容するのか決め
る必要がある

訳語の統一
 少なくともプロジェクト内ではExcelでもいいから
訳語のデータベースを作って訳語の統一を図る
 マイクロソフトの取り組みが参考に
 前者および翻訳プロバイダまで含めた訳語データ
ベースの作成による訳語の管理



欧米人には漢字は絵にしか見えない。(文字
として認識することにまず訓練がいる)
欧州人開発者における国際化とは
ISO-8859(Latin-1)の中で各国語とそれ用の
キーボードに対応することであり、DBCS環
境への対応ではない
とにかく最初は理解されることは期待できな
いので、粘り強く交渉

Developing International
Software, Second Edition
 著者 Dr. International
 ISBN 0-7356-1583-7

CJKV日中韓越情報処理
 著者 Ken Lunde
 ISBN 4-87311-108-0

文字コード超研究
 著者深沢千尋
 ISBN 978-4899770510

JIS X 0213:2004 / Unicode 実装ガイド
 http://download.microsoft.com/download/e/3/c/e3c
1a451-1882-49fe-86a8e25680f6c46c/JIS_Unicode_guide.pdf

Microsoft SQL Server 2005 のインターナ
ショナル機能
 http://www.microsoft.com/japan/msdn/sqlserver/sq
l2005/bb330962.aspx

Microsoft Global Development and
Computing Portal
 http://www.microsoft.com/globaldev/default.mspx

Sorting It All Out (Michael Kaplan's)
 http://blogs.msdn.com/michkap/default.aspx

Windows XP Professional の多言語機能
 http://www.microsoft.com/japan/technet/prodtechn
ol/winxppro/plan/multilingual.mspx

NyaruruさんによるTFS解説
 http://d.hatena.ne.jp/NyaRuRu/20070308/p1
 http://d.hatena.ne.jp/NyaRuRu/20070309/p1
 http://d.hatena.ne.jp/NyaRuRu/20070310/p1


Creative Commons AttributionNoncommercial-Share Alike 2.1 Japan
http://creativecommons.org/licenses/by-ncsa/2.1/jp/

Download Report