12

私は、自分が作成するアプリケーションで使用されるすべての文字列（およびその他の定数）を外部化しようとします。これは、おそらくほとんどのスタックオーバーフラワーに次ぐ性質であるためですが、必要なのは、任意のアプリケーションのスペルチェックを自動化する機能です。ユーザーに表示される文字列。これにはいくつかの問題があります。

  • すべての文字列がユーザーに表示されるわけではありません。文字列を槍で突き刺し、その分離を維持することは簡単ではありません（ただし、可能です） 。
  • すべてではないにしても、私が使用した文字列の外部化方法のほとんどは、aspell / ispellなどのスペルチェッカーを通過しない重要なテキストを含みます（例：theStrName = "somestring。"とコメント）
  • 多くのスペルチェッカー（もう一度、aspell / ispell）は、箱から出してすぐに多くの単語を処理しません（通常、技術用語、適切な名詞、またはメタデータなどの「新しい」用語）。

このようなものをビルド手順/テストスイートにどのように組み込みますか？アプリケーション内のすべての文字列が変更されるたびに、誰かが手動でスペルチェックを行うことは不可能です。また、最初にすべての文字列が正しくスペルされる可能性はありません。

4

6 に答える 6

1

テスト中にエラーが検出されない場合は、手動で行います。エラーは、QAチームによって、または翻訳者によるローカリゼーション中に、またはローカリゼーションQA中に検出されます。次に、バグを提出します。

私たちの開発者のほとんどは英語を母国語としないので、それは私たちにとって珍しい問題ではありません。亀裂をすり抜ける数は非常に少ないので、これは私たちにとって満足のいく解決策です。

数百行を超えるもので100％バグがないものはありません（まあ...おそらく埋め込みコードの奇妙な部分です）。スペルミスをバグと考えて、あまり時間を無駄にしないでください。

アプリケーションが成熟するとすぐに、文字列の90％以上がリリース間で変更されません。リソースの2つのバージョンを比較し、何が新しくなったのか（最初に確認してください）、何が変更/更新されたのかを理解するのは、かなり簡単な作業です。 （次をチェック）そして何が変わっていないか（これらをチェックする必要はありません）

したがって、最初にこれらすべてを手動でチェックする必要があるように考えてください。次回は、そのうちの10％をチェックするだけで済みます。次に、スペルチェックを本当に自動化する必要があるかどうかを自問してください。

于 2008-09-30T08:18:53.710 に答える
1

Javaを使用していて、ローカライズされた文字列をリソースバンドルに格納している場合は、Bundle.propertiesファイルをチェックして、バンドル文字列を検証できます。プロセッサがエントリをスキップする必要があるかどうかを判断するために使用できる特別なコメント注釈を追加することもできます。

このメソッドを使用すると、ロケールに関するヒントを提供し、1つのビルドプロセス内で複数の言語をチェックする方法を提供できます。

実際のスペルチェック自体をどのように実行するかについては答えられませんが、私が提示したものは、スペルチェックを実行する方法についてあなたを導くと思います。

于 2009-09-10T06:33:07.827 に答える
1

これに半自動的にアプローチするには、次の 2 つの方法が考えられます。

UI で使用される文字列と他の場所で使用される文字列を区別するために、コンパイラを使用します。目的に応じて文字列データ型のさまざまなバリアントをオーバーロードし、出力メソッドをオーバーロードしてその型のみを受け入れるようにします。これにより、UI 文字列を出力するだけの偽の UI を作成し、それに対してスペル チェックを実行できます。

もちろん、これが実行可能かどうかは、プラットフォームとアプリケーションの全体的なアーキテクチャによって異なります。

もう 1 つの方法は、コードに表示されるすべての文字列 (コメント、xpath、テーブル名など) でスペル チェッカー データベースを単純に更新し、それらを完全に複雑なものと見なすことです。もちろん、これによりスペルチェックの精度が低下します。

于 2009-09-09T13:13:09.950 に答える
0

aspellを使用します。これはプログラムであり、unixoidsとcygwinで利用でき、さまざまな種類のソースコードで実行できます。これを使って。

于 2008-09-30T08:23:33.370 に答える
-1

最初のポイントは、ビルド プロセスに入れないようにしてください。新しい機能をデバッグまたは構築しようとするたびに、サイト上のすべてのコンテンツをスペルチェックする必要があるとしたら、私は復讐に燃えるコーダーになります。この種の操作は単体テストに属しているとは思いません（コンピューター化されたものではなく、ヒューマンインターフェイスをテストしています）。

2 番目のポイントは、スクリプトを作成しないことです。非常に多くの誤検出が見過ごされ、人々がレポートを読むのをやめてしまい、開始時よりも良い状況にはなりません。

3 番目のポイントは、これはおそらく人間に任せることで最も簡単に解決できることです。QA チーム、コピー ライター、ベータ テスター、翻訳者などです。コピーライターはそれを翻訳サービス/代理店に送信し、永続化レイヤーに入れ、展開しました。テスター (QA、開発者、PM、デザイナーなど) は、スペルや文法の間違いを見つけて、バグ レポートを提出します。多くのスペリング/文法エラーをすり抜けるには、あまりにも多くの官僚主義と目があります.

4 つ目のポイントは、ページにはつづりや文法の間違いが常にあるということです。主要な新聞の Web サイトでさえ、この問題を回避できておらず、オフィス ビル全体が編集者でいっぱいです。

于 2009-09-09T04:22:51.640 に答える