Wiki/Glossary

動作

表示ページの全文に対して、予め別ページで定義されている単語のツールチップ説明文を付与する。
例: きーわーど

書式

Glossaryのページに以下を列記する

:定義語|説明文

仕様

• 定義語の長さ
  3byte以上の文字列。つまり半角3文字以上か、全角2文字あるいは全角1文字+半角1文字以上。それより短い文字列は登録しても無視される。
• 説明文の長さ
  最大は未確認。1,000Byteくらいは表示できることを確認。
• 定義数
  ページの最大行数
• 定義語の総量
  定義語の総文字列長に制限がある。
  32,000Byte程度。32byte*1000件とか程度。
  それ以上は動作しなくなるか、ページ保存時に異常を来す。Autolinkと似た問題と思われる。
  この制約に説明文の長さは影響しない。
• 反映タイミング
  ページの読み込みのたびに、定義語の辞書とマッチングをやり直す。自身のCache機能はない。ただしecacheプラグインは有効。
• Autolinkとの競合
  例えば"助け合い掲示板"というページがあったとき。
  Glossaryに"掲示板"とキーワードを定義すると、"助け合い掲示板"は部分的なGlossaryが優先されAutolinkが掛かりません。
  また:config/AutoLinkで除外文字を設定しても機能しません。
  この状況で"助け合い掲示板"をリンクしたいときは、明示的に[[助け合い掲示板]]と書く必要があります。
  一方Glossaryが部分的ではなくページ名と完全に一致する場合は、AutolinkとGlossaryが同時に機能するようです。

用途

• 複数ページに渡り頻出する単語
  特定のページにしか存在しない単語はtooltipや((脚注))などを使用。
• ページ遷移することなく、マウスオーバーで素早く説明したいとき
• 1ページ起こすほどではないが、説明や補足が必要な単語
  略語、スラングなど
• 定義が複雑な単語
  一見で覚えられない、毎回検索で探すなど

類似の機能

ツールチップ
Autolink
AutoAliasName
include(別ページ参照読み込み機能として)

Glossary運用検討

目的

Glossary運用がどの程度耐えられるのか実験的に確認する。

結論

Glossaryは1600件一杯に定義しても基本的に問題ない。
ただし、Glossaryはinclude系と同じくページを呼び出すたびに動作が入る。ページ内に多量にヒットするときはecacheを有効にすること。(1万件とかServer処理時間が1000ms以上とか)
例えばGlossaryを1600行定義して、ちょうど1600件x1回ずつヒットしたとしても100～200ms程度の処理時間である。時間は定義語の長さと表示ページの文量と定義語に対する説明文の長さによる。
実際的な文章ページなら1ページでGlosary1600件すべての単語が使われることはないだろうし、頻出語で1定義が複数ヒットしたとしても1万ヒットとはならないだろう。

実験条件

Glossaryのページを2パータン用意。

• 1～1500まで数列1500行
  以下のような1500行を登録した場合。

  :1|-1
  ~
  :1500|-1500

• 20桁の乱数を1600行
  以下のような1600行を登録した場合。
  定義語は20桁の乱数、説明文は80桁の乱数。これを1600行。

  :84773437128932729896|34139054487238165214028532997174296836454045235236176077347323983515456142972940
  ~
  :40358017107093870822|97518279908697516036719240965617162874931290810470869703825290275431281039259761

  なお予備実験で、Glossaryのページに登録できる定義語の文字列長には限界があることがわかっている。
  定義語の総文字量で約半角32,000以上になると正常に動作しなくなる。
  32,000を大きく上回る場合は保存後Glossary機能が止まる。ただGlossayが機能しないだけで他の問題はない。ただし32,000をギリギリ上回るくらいだと保存時Serverが応答しなくなりGlossaryページが更新できなくなる。
  説明文のほうは長さの制約はない。

• 表示側のページ
  Glossaryが掛かる側のページを以下のように準備。日本語と書かれてないものは全て半角1byte文字。
  • 1～500までの数列を500行列記
    [1-1500]Glossaryに対して、各行が完全にヒットする。練習用。
  • 1～1500までの数列を1500行列記
    [1-1500]Glossaryに対して、各行が完全にヒットする。練習用。
  • 1534行の適当な日本語のページ
    wikiのpulugin機能を含む
  • 100桁の乱数1500行
    [1-1500]Glossaryに対して、全150,000文字ほぼすべてのがなんらかのGlosaryにヒットする。負荷が高い。
  • 100乱字1500行 英字の小文字大文字52種
    Glossaryはすべて数列なので、このページの全150,000文字は一文字もGlossaryがヒットしない。
  • 100文字のランダムな英小文字と数字1500行
    小文字26と数字10種の混合。
  • 100桁の乱数1600行
    各行の先頭20桁はGlossaryの20桁の乱数を1600行と1対1で対応してる。つまり全1600行の先頭20桁がGlossaryにヒットする。

• Autolink
  サイト全体はAutolinkも有効 576ページ(単純文字列量14,324Byte)

まとめ

• Glossaryは半角3文字以上から有効
• Glossaryはページを読みだすたびに辞書の読み直しが入る
  includeと同じ。
• ecacheはGlossaryに対して有効。
  つまりcacheが有効なら辞書の再読出やServerのhtml再生成が発生しない。
• ページ内容にGlossayの定義語が含まれなければ大した負荷にはならない。
  たとえ1500語の定義があって、ページが100x1500行あったとしても。つまり、マッチングの複雑さの影響は少なく、ヒット数が多いと負荷がかかる。実験4実験5
• 1ページにGlossay1500件程度のヒットでは負荷にならない。
  実験2
• ページ更新で2回目の方が処理時間がかかる
  理由はよくわからない。1回目の表示は何も考えずに頭からhtml生成をするが、2回目はなにか内容を確認してから同じ処理をやり直してるか?
• Glossaryの上限
  Glossaryには容量制限がある。定義語は約半角32,000文字まで。これ以上になるとGlossaryは機能しなくなる。またこの値ギリギリ超えるくらいの文字を登録するとページがはまる。大幅に超える場合ははまりはしないが機能が停止する。

実験結果