アカウント名:
パスワード:
というのは、 internationalization と localization を、「翻訳」としてしか考えていないようなのですが、 もし、font じゃなくて fontset 系を使わないといけない、 というような知識をソフトウェア開発者の側が持っていないといけないとしたら、 それについての記述があるべきです。もしそうじゃなくて、 GNOM
Gtk+2.0のAPI [gnome.org]をそのまま使っていれば、 プログラマに特別な知識がなくても漢字やハングルなど欧米圏以外の 文字表示/入力は問題なくできます。
しかし、GNOME 2.0への移行が進められている gnumeric [gnome.org]は現状に於いて セルでの表示ができません。Ver 1.1.6ではセルの描画にgtkではなく GDK [gnome.org]の gdk_font系関数を使っています。 このように自前で新しいWidgetを実装する場合はやはり国際化/ 多言語化への知識や配慮は必要になるようです。
ただgnumericに関しては開発者側もこの問題を認識しているらしい (BSD Magazineで読んだ気がする)ので、早く修正されればいいな と思います(我ながら無責任な発言だなぁ)。また、 APIドキュメント [gnome.org]によると gdk_font系関数 [gnome.org] 、 gdk_fontset系関数 [gnome.org]共にdeprecatedとされており、 代わりにpango [pango.org]やGtkTextTagを使うのが 一般的な手法のようです。
ショートカットキーの問題ですが、im-anthyを使った日本語入力で、Ctrl-oで 変換対象の文節を伸ばそうとすると、ファイルを開くダイアログが 現れるといった問題を確認しています。変換確定前の文字列がある場合は アプリケーション側にキー入力が流れないようにGtk+を修正する (gtkimmodule辺り?)必要があります。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
i18n/l10n (スコア:4, 興味深い)
というのは、 internationalization と localization を、「翻訳」としてしか考えていないようなのですが、 もし、font じゃなくて fontset 系を使わないといけない、 というような知識をソフトウェア開発者の側が持っていないといけないとしたら、 それについての記述があるべきです。もしそうじゃなくて、 GNOM
Re:i18n/l10n (スコア:2, 参考になる)
Gtk+2.0のAPI [gnome.org]をそのまま使っていれば、 プログラマに特別な知識がなくても漢字やハングルなど欧米圏以外の 文字表示/入力は問題なくできます。
しかし、GNOME 2.0への移行が進められている gnumeric [gnome.org]は現状に於いて セルでの表示ができません。Ver 1.1.6ではセルの描画にgtkではなく GDK [gnome.org]の gdk_font系関数を使っています。 このように自前で新しいWidgetを実装する場合はやはり国際化/ 多言語化への知識や配慮は必要になるようです。
ただgnumericに関しては開発者側もこの問題を認識しているらしい (BSD Magazineで読んだ気がする)ので、早く修正されればいいな と思います(我ながら無責任な発言だなぁ)。また、 APIドキュメント [gnome.org]によると gdk_font系関数 [gnome.org] 、 gdk_fontset系関数 [gnome.org]共にdeprecatedとされており、 代わりにpango [pango.org]やGtkTextTagを使うのが 一般的な手法のようです。
ショートカットキーの問題ですが、im-anthyを使った日本語入力で、Ctrl-oで 変換対象の文節を伸ばそうとすると、ファイルを開くダイアログが 現れるといった問題を確認しています。変換確定前の文字列がある場合は アプリケーション側にキー入力が流れないようにGtk+を修正する (gtkimmodule辺り?)必要があります。
gnumericはpangoに移行 (スコア:1)