世界中で利用可能なアプリケーションを作る、というのは、口で言うのは簡単ですが、実装するのはかなり大変です。
我々は日本人なので、海外アプリケーションがマルチバイト言語に対応していないことについて不満に思うことが多々あります。
それと同じ不満を、アラビア語圏やヘブライ語圏の人が「RTLへの対応」という点で抱いていると知らされたのはつい最近です。
コア作者・モジュール作者・テーマ作者にとって、何が問題になるか、というと、HTML/CSS内における 'right' とか 'left' の表記です。
style="float:left;"
<td align="left">
は、RTL圏だと
style="float:right;"
<td align="right">
にならないと他とのバランスがとれなくなります。
つまり、HTMLやCSSにleftやrightを直書きするのもタブーってことです。
このあたり、ImpressCMSは進んでいて、すべての言語ファイルに _ADM_USE_RTL という定数を用意してRTLの有無を振り分けてます。
モジュール作者が実際にコーディングする場合は、こんな感じで利用します。
// for RTL users
@define( '_GLOBAL_LEFT' , @_ADM_USE_RTL == 1 ? 'right' : 'left' ) ;
@define( '_GLOBAL_RIGHT' , @_ADM_USE_RTL == 1 ? 'left' : 'right' ) ;
やたらと@が多いのは、コアによって、どこまで対応しているかがまったく違うからです。
もちろん、テーマやテンプレートでの記述はこうなります。
float:left
float:<{$smarty.const._GLOBAL_LEFT}>
これ、ぜひともXCL本体でも採用して欲しいですね。
そこまでやってはじめて、国際プロジェクトと言えるでしょうから。
そして、その定数名はぜひともImpressCMSと統一してください
引用:
GIJOEさんは書きました:
それと同じ不満を、アラビア語圏やヘブライ語圏の人が「RTLへの対応」という点で抱いていると知らされたのはつい最近です。
コア作者・モジュール作者・テーマ作者にとって、何が問題になるか、というと、HTML/CSS内における 'right' とか 'left' の表記です。
お、おお〜、知りませんでした! RTL は、right-to-left なんですね。
引用:
float:left
float:<{$smarty.const._GLOBAL_LEFT}>
やっぱり CSS もスクリプトに近くなっていくんですね。
が、RTL圏の人とLTR圏の人が同じサイトを見ることは少なそうなので、キャッシュに入ってもいいたぐいのものなのかもしれませんね。
勉強になりました!
興味深い話題ですね。
言語の習慣にどこまであわせられるかというのが、グローバル対応の根幹になると思いますが、RTL以外にもいろいろと問題があるものです。
・複数形
日本語には数の概念がないので、忘れられがちです。
英語のように、-sをつければいいような言語ばかりでなく、
英語では"n result(s)"とお茶を濁せても、ほかの言語ではおかしな文になってしまうことがあります。
チェコ語には単数(1)・複数(3以上)以外に「双数(2)」という概念もありますが、それに関連してgettextに専用の関数があるのを見つけました。
http://jp.php.net/ngettext・日付
同じ暦を使っている言語圏でも、表記の仕方が異なっているのは有名です。
(米)October 10, 2002
(英)10 October, 2002
日付の問題は、XOOPSでは関数 formatTimestamp() を積極的に使うことである程度解決できると思います。
Smartyなら、<{$time_stamp|xoops_formattimestamp:"m"}> といった感じです。
全くの余談ですが、CSS3ではtext-alignプロパティの値にstartとendが指定できるようになるようです。startは文字通り行の先頭から(LTRは左、RTLは右)、endはその逆です。
これが普及してくれれば楽なのですけどね…
http://www.w3.org/TR/css3-text/#text-align
Hansyouさん、こんにちは。
引用:
全くの余談ですが、CSS3ではtext-alignプロパティの値にstartとendが指定できるようになるようです。startは文字通り行の先頭から(LTRは左、RTLは右)、endはその逆です。
おお、参考になります。
startとendなら、確かに余計なことを考えなくて済みますね。
この場合 float はどうなるんでしょう?
float: start;
float: end;
はともかく、
は、いかにも既存属性名とバッティングしそうですが。
おおっ、国際言語専門家の召還に成功しましたね

引用:
・複数形
日本語には数の概念がないので、忘れられがちです。
英語のように、-sをつければいいような言語ばかりでなく、
英語では"n result(s)"とお茶を濁せても、ほかの言語ではおかしな文になってしまうことがあります。
これは確かに悩みますね。gettextが一般的でない以上、
「_RESULT」
「_RESULTS」
と2パターンを用意する、というのがありきたりですが、最終結論という気はします。
引用:
おお、面白い!
こういう話題、大好きです。
余談ですが、男性名詞・女性名詞がからんでくる状況ってのはありませんかね?
引用:
日付の問題は、XOOPSでは関数 formatTimestamp() を積極的に使うことである程度解決できると思います。
Smartyなら、<{$time_stamp|xoops_formattimestamp:"m"}> といった感じです。
xoops_formattimestamp というプラグインは、XCLにしか存在しませんね。
つまり、XOOPSのモジュール作者がデフォルトテンプレートに記述はできません。
どうせ、Smartyがsecure modeで動くことは無いんですから、素直に、
<{$time_stamp|formatTimestamp:"m"}>
で良いと思います。これなら、全部のXOOPSで動きます。
個人的に、日時がらみの慣習で一番嫌らしいのは、DSTだと思ってます。
piCalで散々酷い目に遭いましたから。
・複数形、双数形
引用:
これは確かに悩みますね。gettextが一般的でない以上、
「_RESULT」
「_RESULTS」
と2パターンを用意する、というのがありきたりですが、最終結論という気はします。
いろいろ考えてみましたが、やっぱりパタンを何通りか用意しておくしかなさそうですね。
多くても、0, 1, 2, 3以上の4つのパタンで間に合いそうですし。
引用:
余談ですが、男性名詞・女性名詞がからんでくる状況ってのはありませんかね?
おっしゃるとおり、ロシア語やドイツ語には男性・女性・中性の属性をもった名詞群がありますね。言語によっては男性・女性の区別が無くなってるものあります;両性(共性、通性)と言われる。
性のある言語はドイツ語しかやったことがないんで、浅い知識で答えることになって済みませんが、名詞の性は冠詞と呼応するので、文章を単語から生成するような処理を作らない限り、性はあまり問題とならないと思います。
ドイツ語の簡単な例ですが(語彙力がなくて済みません^^;)、ドイツ語では「父」が男性名詞、「母」が女性名詞、「子供」が中性名詞です。
男性 Der Vater (The father; 父が)
女性 Die Mutter (The mother; 母が)
中性 Das Kind (The child; 子供が)
もし仮に、主語を動的に変えた「○○は家にいます」という文を出力するケースがあると仮定します。そうしても、多くのプログラマは次のようなコードを想定するはずです。
$someone = "Der Vatar"; // 「父」
printf("%s ist zu Haus.", $someone); // 「%sは家にいる。」
その場合でも、冠詞と名詞を別々に代入することは考えにくいです。なので、名詞の性はほとんど考えなくて済むと思います。
日本語にない名詞の性で考えるからややこしいのですが、日本語でも十分に似たようなケースは想定可能です。
日本語には、無生物と有生物の名詞の区別があります。
「父が家にいます。」
「本が家にあります。」
「父」は有生物なので「いる」と呼応し、「本」は無生物なので「ある」と呼応します。
printf("%sは家にいます。", $someone);
printf("%sは家にあります。", $something);
ドイツ語と同じように文を生成する処理を想定してみますが、このような実装自体、まれなケースだと思いますので、ほとんど無視してもかまわないと思います。
それに、こういったものは言い換えが可能なので、問題になることはほとんどなさそうです。
printf("%sが存在しています。", $anything);
引用:
どうせ、Smartyがsecure modeで動くことは無いんですから、素直に、
<{$time_stamp|formatTimestamp:"m"}>
で良いと思います。これなら、全部のXOOPSで動きます。
鋭いご指摘ありがとうございます。確かに、formatTimestampで良さそうですね。処理的にもxoops_formattimestampと変わらなかったと記憶しています。