その点で、注意することがあれば教えていただきたいです。
データーベースの文字コードやマルチラングウェッジ仕様にする上でのアドバイスやクレジットカード決済のモジュールを組み込んでもらう時の注意点等
知っておいた方がいいことがありましたら、アドバイスいただきたいです。
よろしくお願いします。
>こちらでUTF-8等に指定した方がいいのでしょうか?
指定したほうがよいです。
現在では、UTF-8でこまるものはないので指定したほうが絶対によいです。
表示の日本語化とかは日本側でするとしても、
入力とかの文字テストで、日本語が通ることをしてもらっていたほうがよいですね。
クレジットカードのモジュールも、日本でも使える有料のものをこちらで選定して
相手に使ってもらうほうが絶対によいです。
無料でも有料もモジュールを使う場合は、日本語化が可能かどうかが重要となりますから
使うモジュールを事前にわかるのなら相手に提示してもらって、こちらで検討したほうがよいですね。
どのようなWebアプリなのか分からないのですが、思いつく日本ローカルなモジュールを列挙します。
海外での展開も考えているので文字コードは、こちらでUTF-8等に指定した方がいいのでしょうか?データーベースの文字コードとか?
また、海外のクレジットモジュールと日本のクレジットカードモジュールって大きく違って、日本で独自にプログラムを組み直さないと
難しいのでしょうか?
通常、大手デベロッパーの場合、プログラムソースと文字リテラルの入っているリソースファイルを分離することで、開発と翻訳を分離できるようにして開発プロジェクトを進めます。また、翻訳は問題なくてもレイアウト上の都合で文字数を削除したり修正を入れる必要もでてきますので、ビルドは日本側で行うようにすることが肝心です。
文字リテラルがプログラム内にハードコーデッドされている場合は、翻訳は非常に困難となりますので注意が必要です。
リソースファイルが別ファイルになっていれば、外部の翻訳業者に出して一括翻訳させることが可能ですし、機械翻訳を通した後で、マニュアルで校正をかけることで翻訳工数を抑えることができます。
また、リソースファイルが分離されている場合はマルチリンガルの対応も容易です。
内部の漢字コードはプログラミング言語に依存している部分も多いため、技術的制約はあまりありません。出力する際にコード変換をかければいいだけです。ただし、欧米圏の1バイトキャラクターセットの場合は、そもそもコード変換を行う必要がありませんので、事前に画面出力系にコード変換ルーチンをかますことができるように開発業者とネゴシエーションしておく必要もあります。
クレジットカード決算は決算業者をかますのか、代理店の権限をもっていて独自に決済を行うかによって処理が異なってきます。ただ、クレジットカード決済云々は翻訳工程にはあまり関係はないかと思います。
お返事ありがとうございます。
わかりました。参考にさせていただきます。
ありがとうございます。
>こちらでUTF-8等に指定した方がいいのでしょうか?
指定したほうがよいです。
現在では、UTF-8でこまるものはないので指定したほうが絶対によいです。
表示の日本語化とかは日本側でするとしても、
入力とかの文字テストで、日本語が通ることをしてもらっていたほうがよいですね。
クレジットカードのモジュールも、日本でも使える有料のものをこちらで選定して
相手に使ってもらうほうが絶対によいです。
無料でも有料もモジュールを使う場合は、日本語化が可能かどうかが重要となりますから
使うモジュールを事前にわかるのなら相手に提示してもらって、こちらで検討したほうがよいですね。
お返事ありがとうございます。
無料で使えるモジュールってあるんでしょうか?
契約するクレジット決済代行会社によって、違うのかもしれませんが・・・?
お返事ありがとうございます。
無料で使えるモジュールってあるんでしょうか?
契約するクレジット決済代行会社によって、違うのかもしれませんが・・・?