doc: improve news for 12.0.8 #1425
Conversation
|
Could you review this? |
doc/locale/ja/LC_MESSAGES/news.po
Outdated
| msgid "We changed specification of the ``escalate()`` function as below." | ||
| msgstr "``escalate()`` の仕様を以下の通り変更しました。" | ||
| msgid "Changed specification of the ``escalate()`` function (Experimental)." | ||
| msgstr "``escalate()`` 関数の仕様を変更しました。(実験的)" |
There was a problem hiding this comment.
ユーザーが使いやすいように関数の仕様を変更したので、「使いやすくなったよ！」というのをアピールしたほうが良いと思います。
例えば、以下のようにするのはどうでしょうか？
``escalate()`` 関数(実験的)を使いやすく改良しました。
あと、内容ですが、前回の仕様との比較をして、どのあたりを使いやすくしたのかを書くといいと思います。
例えば、以下のように書くとか。
前回の仕様が〇〇で、今回のリリースで☓☓と変更しました。
前回の仕様では、 ``escalate()`` の条件の前の実行された条件でどのくらい絞り込まれるかをユーザーが推測して最初のしきい値を決めなければならず不便でした。
今回のリリースから``escalate()`` の条件の前の実行された条件でどのくらい絞り込まれるかを気にしなくてよくなったので、しきい値の設定をしやすくなっています。
There was a problem hiding this comment.
頂いた内容を元に説明を追加しました。
| @@ -108,6 +111,15 @@ msgstr "" | |||
| "これは、検索する値について、値を受け取った後と、トークナイズした後の二回ノー" | |||
| "マライズしていたことが原因です。" | |||
There was a problem hiding this comment.
以下のような説明を追加するとよりわかりやすくなると思います。
Groongaはレコードを追加する時に、インデックス用のテーブルに設定したトークナイザーとノーマライザーを使って、登録するデータをトークナイズしてからノーマライズしています。
検索キーワードもデータ登録時に使用したトークナイザーとノーマライザーを使って、検索キーワードをトークナイズしてノーマライズしてから、検索キーワードとインデックスを照合します。
データ登録時に使ったトークナイザーとノーマライザーを検索キーワードにも使うので、インデックスに登録したデータと同じ検索キーワードであれば、インデックスに格納されている状態と同じ状態になります。
ただ、いままでGroongaは検索キーワードだけを余分にノーマライズしていました。
ビルトインのノーマライザーは何度ノーマライズしても結果は変化しないので、影響ありませんがNormalizerTableのように自分でノーマライズのルールを設定できるノーマライザーの場合、ノーマライズを２回実行すると結果が変わるようなルールを指定できます。
ノーマライズを２回実行すると結果が変わるようなルールがある場合、検索キーワードだけ余分にノーマライズされるのでインデックスに登録したデータと検索キーワードが不一致になるケースがあります。
このようなケースでは、ヒットするはずのデータがヒットしなくなります。
There was a problem hiding this comment.
ありがとうございます。
頂いた内容をもとに説明を追加しました。
（少々表現を変更したり削ったりしています。）
|
@HashidaTKS Could you confirm my comments? |
|
Thank you! I have addressed your comments. |
doc/locale/ja/LC_MESSAGES/news.po
Outdated
| msgid "" | ||
| "Changed specification of the ``escalate()`` function (Experimental) to make " | ||
| "it easier to use." | ||
| msgstr "" |
doc/locale/ja/LC_MESSAGES/news.po
Outdated
| "前回の仕様では、ユーザーはどのくらいの結果が ``escalate()`` に渡されるのか推" | ||
| "測して最初のしきい値を決める必要があり、不便でした。今回のリリースから、ユー" | ||
| "ザーがどのくらいの結果が ``escalate()`` に渡されるのか推測する必要がなくなり" | ||
| "使いやすくなりました。" |
There was a problem hiding this comment.
前回の構文と今回の構文を具体的に載せた方がわかりやすいと思うので、以下のようにするのはどうでしょうか？
今までの仕様では、以下のように number_column > 10 の結果がTHRESHOLD_1以下ならCONDITION_1を実行するという挙動でしたが、これでは、ユーザーが number_column > 10 の結果を推測してTHRESHOLD_1の値を決める必要があり不便でした。
number_column > 10 && escalate(THRESHOLD_1, CONDITION_1,
...,
THRESHOLD_N, CONDITION_N)
今回のリリースからは、number_column > 10の結果を参照しないようになりました。
これにより、ユーザーはnumber_column > 10の結果を気にしなくて良くなり、以前より escalate()のしきい値を設定しやすくなりました。
この変更にともない、 escalate() の構文は以下のように変わります。
THRESHOLD_1が無くなった点が変更点です。
変更前)
escalate(THRESHOLD_1, CONDITION_1,THRESHOLD_2, CONDITION_2, ..., THRESHOLD_N, CONDITION_N)
変更後)
escalate(CONDITION_1, THRESHOLD_2, CONDITION_2, ..., THRESHOLD_N, CONDITION_N)
|
@HashidaTKS Could you confirm my comments? |
|
指摘事項に対応しました。確認をお願いいたします。 |
No description provided.