2012-01-04 60 views
1

私の会社では、私たちが5年以上開発してきたWebアプリケーションがあります。私たちはまだPHP4を含んだコードベースを持っていて、PHP5の負荷で拡張されています。 LOCはかなり大きく、約471kです。フレームワーク、ORMなどに基づいていません。レガシーソフトウェアを複数の言語に翻訳する最も良い方法は?

このプロジェクトを開始した開発者は、i18nと翻訳を無視しました。すべての言語テキストは、ソフトウェアでハードコードされています。はい、私はこれが大きな時間を吸うことを知っています。 ソフトウェアが書かれている言語でしか販売していないので、現時点では問題ありませんが、海外への展開も検討しています。

私は、翻訳を扱う際の最善のアプローチに苦労しています。 あなたはどうやってこれにアプローチしますか?フレームワークを使用して書き直すほうがよいでしょう。これはおそらくコードベースを改善し、堅実な構造を提供するからです。または、現在のソフトウェアを使用して、言語テキストをフィルタリングするだけですか?

このトピックに関するヒントやヒントは高く評価されています。

+0

私はすべての答えが次に何をするかを決めるのに役立つと思います。それでも私は答えを受け入れる必要がありますか? – tomvo

答えて

0

翻訳プロジェクト以上のものがあるようです。海外に持ち帰りたい場合は、にはがあり、少なくともシステムの一部を再設計します。

あなたの予算がそれを可能にし、利益がそれを正当化するなら、あなたは戻って全体のデザインを見てみたいと思うでしょう。できるだけ早く、大切な部分を取り除き、再設計し、交換し、アップグレードすることを恐れないでください。

これまでの5年間で多くの変更がありました。今後数年間販売を計画しているアプリケーションの場合は、再設計に投資する価値があります。

+0

真。私はdevdRewからのビジネスプランのコメントも考慮に入れると思います。また、現代のフレームワークを代わりに使用する場合、5年のレガシー製品の書き換えの影響/時間を予見するのはかなり難しいです。 – tomvo

+0

モジュールを分割し、それぞれを評価します。彼らはおそらくすべて書き直す必要はありません。モジュールの書き換えによるコスト/労力の影響の判断は、システム全体で行うより簡単です。 –

0

これは、何をすべきかに関する優先事項が何であるかによって異なります。

主な関心事が言語翻訳の場合は、ハードコードされた文字列を取り出すだけで、国際化することができます。

異なるデータベースを簡単にサポートしたいなどのニーズがある場合は、より良いアプローチがあるかどうかを判断するのに役立ちます。

2

私は両方の変形が可能だと思います。コードを残すか、書き直すことができます。しかし、あなたが書き直しが長いプロセスであることを知っているように、その事実にもかかわらず、あなたは5年以上それを書いています。

まだ安定していて、うまく動作し、PHP4やその他の「おいしいもの」が不要な場合は、すべてのハードコーディングされたテキストを残しておきましょう。 i18nヘルパーは非常に簡単です。あなたは、より多くの何もしないことがあります。

  • テキストと翻訳
  • キャッシュ機構を格納する適切な方法を選択し、すでにロードされた翻訳のため
  • 国際化操作のクラスとヘルパーを。

コードを書き換えようと思えば、ビジネスプランをよく分析してください。

+0

これはまたすべての回答のコメントです。私は自分の問題の一部が、開発者の世界であなたの周りに新しい素晴らしいものがたくさん現れるのを見ても、レガシーを扱うことの不満です。それはすべてを投げ捨てて最初から始めたいと思うようにします。 – tomvo

+0

私たちはすべてそれに直面しますが、あなたはビジネスパートナーの帽子をかけて、「ビジネスには何が最高ですか」と言わなければなりません。開発は、私たちが利用できるすべての光沢のある新しいおもちゃを使用することにほとんど焦点を当てていません。効果的で費用対効果の高い方法で仕事を終わらせることです。 –

1

まだ回答がありません。ほとんど同じ文字列を翻訳するのは非常にコストがかかる。言語の数とそれを掛け合わせると、同じ文字列や多分書式を共有して良い国際化が本当に効率的です。

テンプレート部分の最初の書き換えは、おそらく意味があります。最初に手で、次にあなたが書いた自動変換ツールを使用します。それはI18Nを準備すべきです。

+0

PHPコードの約50%がHTMLを生成し、テンプレートがないと言ったらどうしますか? – tomvo

+0

私はあなたの気持ちを知っています。従来のコードでの多くの経験しかし、少なくともHTMLを国際化するのに便利なコンポーネント(例えば、 '

1

私の経験では、2つの大きな目標を持つ1つのプロジェクトを持つことはうまくいかず、特にその目標がビジネスの観点からはほとんど無関係である場合はそうです。私はローカリゼーションを担当する1つのプロジェクトチームを持っています(翻訳だけでなく、異なる国には異なる法的要件、通貨、支払いプロバイダなどがあります)、そして「コードベースを改善する」チームが1つあります。

ローカライゼーションチームは、「できるだけ簡単なこと」のための大まかな計画(およびコスト)を用意することから始めます。現時点でサイトにローカライズ機能を組み込むことができます。そのコストがビジネス上の観点から受け入れられない限り、私はそのルートを下ります。

リファクタリングのビジネスケースが作成されていない場合は、ローカリゼーションプロジェクトに靴をかけるつもりはありません。これまで同様のことが起こっているのを見て、すべての開発者がクールリファクタリング、さまざまなフレームワークの相対的なメリット、そしてどのソースコード管理システムを使用するかについて話をする一方で、ビジネスが気にしていたことは未来に押し進められました。最終的に、事業主はプロジェクトへの関心を失い、それをキャンセルしました。

リファクタリングの手間がなくても現実的な方法でローカリゼーションを行うことができない場合は、2つの別々のチームで実行します。ローカリゼーションチームは、リファクタリングチームの主要な要件所有者になることができ、一緒に作業する必要がありますが、2つのプロジェクトを独立して実行することで、リファクタリングの90%を実行するリスクを回避できます。ローカリゼーション

関連する問題