こかぜ
(トーク投稿記録)
原文： ◉骰子（六面）占卜法 ＊使用六面骰时，仅投掷三次无法确保以均等概率得出结果。 ①投掷三次骰子，并记录结果。 如果，第一次投掷时， 掷出5或6的话 需重掷至结果为1～4为止。 例：〔第一次〕6因此重掷得2， 〔第二次〕5，〔第三次〕1 ②代入以下公式计算。 （第一次结果×36）-（第二次结果×6）+ 第三次结果-42 例：（2 × 36）+（5 × 6）+ 1 - 42 = 61 ③所得数字对应的神签即代表您的运势。 注意，约有11%概率出现129及以上数值。 此时请重新占卜。
其中②应为（第一次结果×36）+（第二次结果×6）+ 第三次结果-42
中日对照同样
抱b大师〈The Unidentified Fantastic Flying Girl〉
(トーク投稿記録)
众所周知 {{黑幕|1|2}} 可以产生一个 title（鼠标悬停在黑框上产生的文字框内的文字？）为 2、内容为 1 的黑框文字 1，2 如果不填则默认为“你知道的太多了” 1
但是，如果 1 是一个形如 [[3|4]] 的链接那么 title 就不会是 2，原因未知
例如：{{黑幕|[[生与死的境界#登场|乱丢垃圾 2.0]]}}：乱丢垃圾 2.0 这里的 title 是“生与死的境界”。
挺离谱的。
抱b大师〈The Unidentified Fantastic Flying Girl〉
(トーク投稿記録)
离谱的是用 html 代替黑幕
<span class="inside" title="test114514"> [[生与死的境界#登场|乱丢垃圾 2.0]] </span>
这个 test114514 都会被覆盖。
原因貌似是因为里层链接被展开成了 <a href="/%E7%94%9F%E4%B8%8E%E6%AD%BB%E7%9A%84%E5%A2%83%E7%95%8C" title="生与死的境界">乱丢垃圾 2.0</a> 然后里层 title 覆盖了外层的
但是这个 wiki 又不能直接用 a href 所以挺头疼的（
晋欢97604〈The Highest of Native Gods〉
(トーク投稿記録)
[[1|2]]确实会被优先解析，HTML的特性如此。
不过还是得提一嘴，Wiki原则上不建议在没有必要的地方滥用黑幕模板。
进击的小人族〈Descendant of the Inchlings〉
(トーク投稿記録)
简而言之就是搜索功能能否继续完善升级之类的，之前遇到过很多次由于搜索功能不支持导致的部分麻烦。
之前本来想在群里说的，结果每次都忘记其实只是单纯的想用用讨论版的功能而已，也不知道有没有人看
问题：
比如说搜索含有“博丽灵梦”的词条，出来一大堆。
但自己只想找含有灵梦的官方作品或者是同人作品，有时想找灵梦的符卡。
或者是含有 博丽灵梦 的同人作品方便角色厨找同人，结果就是巨麻烦。
建议；
完善搜索结果分类筛选。
利用THBwiki已有的分类在搜索页面对于各词条进行分类筛选
例如在搜索页面搜索栏下方设置“筛选：符卡，官方作品，同人作品，同人展会等”
其实这个对于体验感影响并不大，可有可以，但有了总比没有好
问题：
有些萌新或者是不会懒得要死的东方狗有时候不能完整正确的打出名称。结果出来个“本wiki上没有此词条”就很难受了
比如说刚刚入车万的萌新，搜索一个“东方红魔馆”，或者是“红美玲”，结果啥都没有找到。
或者是老车万苟，偷懒直接打“YYZ”想找幽幽子，结果天花板很不给面子啥都没有找到，乖乖的打“幽幽子”就很尴尬了。
建议：
添加模糊搜索，并开放编辑模糊内容。
比如说：搜索东方红魔馆，类似于现在这种显示一个“本页面用于显示xxx而不是xxx”。或者是“你是否在寻找‘东方红魔乡’”
因为咱目前还没有学习到高级的wiki编辑，不清楚这些建议完成的难度如何。就直接说了~反正也不是重要的事情~看看就可以了~单纯的想试试讨论版
Dsp2杂化〈The Little Dowser General〉
(トーク投稿記録)
yyz草生www
模糊搜索这个功能我也超级想要的，特别是搜一些同人作品的时候，忘记了社团和作者名字，只记得一部分非假名的作品名字或者一种译名（其实天花板根本就没几个词条写了译名...）的时候，模糊判断就显得非常有用了，非常希望能有，和你观点相反，我觉得这个比你提到的第一点重要多了话说这个是mediawiki能做到的拓展功能么？
关于你举的第一个问题，我觉得关于想找灵梦的官方作品/符卡这个部分，完全没有难度，这种光是在灵梦的角色页面（及其子页面）就能轻松找到，关于同人相关的部分，那就是善用相关分类及语义搜索（使用教程可以参考这里）功能去搜了（当然要找曲子相关的同人就找灵梦那几首角色曲呗直接用cd站就能搜）
但是严峻的事实是，就算不考虑现在收录的同人志词条有限，有收录的词条中，填写了登场人物一栏的也少之又少，而同人志有关角色的自动分类的判断是对于封面角色和登场角色两栏判断的...所以，你懂的吧，就有点尴尬...现在基本就靠封面角色去搜来判断是不是灵梦的同人...嘛，反正如果只是这种程度的话，用语义搜索同时搜博丽灵梦和同人志的分类就行了，很方便，还可以自定义显示一下首发展会之类的数据方便按年份找本子看（其实把，我记得还有一个归纳了所有角色名字的页面，可以点开直接查找封面含对应角色的作品，比较可视化...但是太久没用了我忘记是哪个页面了...等人补充把）
其实把，要是这些七七八八的搜东西用的页面（还有一些一般用户组也可以用的实用的功能性页面）能开一个页面放一起让人选用就好了，经常忘记自己之前用的页面叫啥，一个个收藏过去收藏夹会很乱的...
Gzz〈小石头帽子〉
(トーク投稿記録)
挖个坟，只针对限定分类搜索这一点，其实 thb 用的搜索引擎本身就有一些高级搜索功能，如果你想在 分类:符卡 内搜索，只需要在搜索词里加上 incategory:符卡 就行了
我在用户页里写了简单的介绍，更详细的可以看 Wikipedia:Help:Searching 和 mw:Help:CirrusSearch
当然直接敲代码不是很方便，萌百有人写了个脚本可以有一个图形化界面 [1]，想的话也可以借鉴过来，但是可能也没几个人需要用（）
或者本来也有一个配套的扩展 mw:Extension:AdvancedSearch，Wikipedia 就在用，不知道 thb 以后会不会装
Parunari
(トーク投稿記録)
页面目前记载的出处为《【寓梦寻迹 正片】第一期：囧仙访谈》 然而，“东方寓梦粹”社团创立于2018年4月5日，《【寓梦寻迹 正片】第一期：囧仙访谈》是同年12月公开的。 而“ao=好”的用法，最初的来源是S触，且最迟在2017年初就被银饼相关、部分涉猎较广的东方众以及音系恶俗群体大范围使用。无论是传播还是出处都必定不是出自“寓梦寻迹” 考虑到多方原因，直接在wiki提到这个的详细出处可能不合适，但放错误信息也不太合适 如果这个话题也不适合在讨论版讨论请帮忙移除这个话题
不拘一嗝降人才〈Counterattacking Amanojaku〉
(トーク投稿記録)
在如今的东方社群中，东方众使用ao一般就是源于囧仙访谈那个ao。当然，音mader的ao乐器很可能是源于更早的传统，音mad对于这个梗的扩散也有很大作用，但是这毕竟属于间接性来源，因此不说得很详细的话就可以略过（包括下面三年动画衍生的梗也是往较简略地写）。这些确实是考虑到详细出处不适合提，所以做出的折中处理。
NicoNicoNii〈Simple Dowser〉
(トーク投稿記録)
THBWiki 使用 TableMapping 扩展管理原作音乐名称的日、中、英映射方案，所有映射表均在音乐名模板目录列出，并且提供 API，对东方原作音乐的相关数据查询工具十分有益。其中 !COR 是一个特殊字段，内容为一条目名称，音乐映射表对于哪部原作，就设置为这部原作的主条目名。例如，映射表特殊:管理映射方案/红魔乡音乐名/日文的 !COR 字段内容为“东方红魔乡“，特殊:管理映射方案/大空魔术音乐名/日文的 !COR 字段内容为“大空魔术”。
我在编程时发现，!COR 字段存在多个问题，影响 API 的实用性：
目前 !COR 字段有时在三个映射表同时存在，有时只出现在两个映射表，有时只出现在一个映射表。!COR 字段的使用应该统一。
燕石博物志音乐名, 旧约酒馆音乐名, 天空璋音乐名, 凭依华音乐名, 噩梦日记音乐名, 虹龙洞音乐名, 刚欲异闻音乐名, 虹色的北斗七星音乐名, 兽王园音乐名, 七夕坂梦幻能音乐名, 锦上京音乐名
鬼形兽音乐名
红魔乡音乐名, 花映塚音乐名, 莲台野夜行音乐名, 蓬莱人形音乐名, 辉针城音乐名, 风神录音乐名, 鸟船遗迹音乐名, 黄昏酒场音乐名, 灵异传音乐名, 神魔讨绮传音乐名, 秋霜玉音乐名, 稀翁玉音乐名, 幺乐团4音乐名, 幺乐团5音乐名, 幻想乡音乐名, 幻想怀古曲音乐名, 幻想的音乐音乐名, 幻想麻雀音乐名, 心绮楼音乐名, 怪绮谈音乐名, 文花帖DS音乐名, 文花帖音乐名, 星莲船音乐名, 梦时空音乐名, 梦违科学世纪音乐名, 永夜抄音乐名, Cradle音乐名, TLM音乐名, 卯酉东海道音乐名, 地灵殿音乐名, 大战争音乐名, 妖妖梦音乐名, 封魔录音乐名, 幺乐团1音乐名, 幺乐团2音乐名, 幺乐团3音乐名, 绯想天音乐名, 萃梦想音乐名, 非想天则音乐名, 神灵庙音乐名, 伊奘诺物质音乐名, 大空魔术音乐名, 天邪鬼音乐名, 幡紫龙音乐名, 深秘录音乐名, 绀珠传音乐名, 8MPF音乐名
受影响的映射表包括：
是否应该将这些映射表的 !COR 字段修改，更改为某个条目名称，例如将“东方三月精E CD“更改为 ”东方三月精 ～ Eastern and Little Nature Deity.“或“东方三月精 ～ Eastern and Little Nature Deity./附属CD“？或者反过来，创建一个名为东方三月精E CD的重定向条目？
以下映射表的任何版本都没有 !COR 字段：
两者的 !COR 应该分别设置为“东方外来韦编”、“东方音焰火”。
尽管几乎所有音乐映射表都存在 !COR 字段，但帮助:管理映射方案的文档并没有描述该字段的作用，无论是管理员还是普通用户均不知道本字段的功能。如可能，请补充文档。
请劳烦管理员研究一下以上问题，谢谢。
Gzz〈小石头帽子〉
(トーク投稿記録)
我也不清楚 COR 是什么作用，而且因为已经问不到这个扩展的作者了，要搞清楚可能也比较麻烦
不过能看出来的是这些都是 标准名称模板 的名字，是里面的专辑、书籍、游戏名模板（除了未知之花，因为我之前给模板改名过，但是不知道映射方案里写了这些东西）
话说如果这个东西帮助里没写，很多表里也没写的话，是未实现的功能也说不定（）
Gzz〈小石头帽子〉
(トーク投稿記録)
有管理员去查了扩展的源码，里面没用到过 !COR 这个东西，所以就是没用的（）
其实感觉上也没有哪里会需要用这个，因为现在这些作品名模板都是直接写在音乐名模板里的，作为原曲来源模板的第一个参数，比如 模板:GoM音乐名 第 4 行
| 3 = {{原曲来源|{{GoM CD}}|{{#getmap:GoM音乐名/日文|{{{2}}}}}}}
所以估计是废弃功能了
NicoNicoNii〈Simple Dowser〉
(トーク投稿記録)
我觉得这个字段现在的意义在于，可以自动从模板 API 本身获得专辑/游戏的条目名称，所以还是有用的。例如“三月精E音乐名” -> 东方三月精E CD -> 展开标准名称模板 -> 东方三月精 ～ Eastern and Little Nature Deity. 附属CD，然后可以根据目标条目判断作品为游戏、CD 还是专辑，然后直接转到“Music Room”或者“附带故事”获取更多信息。如果没有这个字段，就需要做繁琐的手工处理了。
已创建，加群没通过是因为被过滤了，之后通过了（）
感謝管理的認可, 我會繼續努力.
Smalllqiang〈Youkai Who Comes and Goes〉
(トーク投稿記録)
想跳過驗證碼, 以及使用IPE等, 請求管理給予權限;
如未達到授予權限組要求, 也懇請說明努力方向.
SunCL〈Legend of Aokigahara〉
(トーク投稿記録)
感谢您为THBWiki做出的贡献，不过我个人觉得您的编辑广泛度以及对MediaWiki系统的熟悉程度还不够，主要还是集中在官作相关页面，缺少二次同人作品、活动的尤其是新建页面的编辑。
不过为了您方便编辑Wiki，在此授予一个月的继续努力少女权限，希望能起到激励的作用，鼓励您去更多地涉及之前未尝试过的部分。
一个月后我会重新评估是授予正式的继续努力少女还是延长观察期。
结论：API 的重定向功能不可靠，只能跟随人工创建的重定向条目，而无法处理英文大小写、简繁体中文和日文汉字、片假名平假名和罗马字、对应的全角与半角字符所产生的自动重定向。要获取重定向后的页面名称，需利用expandtemplates API 以手工展开模板{{#redirect:条目名}}。至于该具体条目的个例问题，已通过人工创建重定向页面解决。
NicoNicoNii〈Simple Dowser〉
(トーク投稿記録)
用搜索框访问神魔讨绮传 ～ Magus in Mystic Geometries，被重定向至：神魔討綺伝_～_Magus_in_Mystic_Geometries.
在搜索框访问神魔讨绮传 ～ Magus in Mystic Geometries.（多一个句号），是特殊:管理映射方案/神魔讨绮传音乐名/日文的模板{{神魔讨绮传}}的解析结果，会被被重定向至：神魔讨绮传 ～ Magus in Mystic Geometries.（消歧义），而且目标只有一个选项。而这个消歧义页面本身也不存在，疑似是自动生成的。
更奇怪的是，直接访问原始条目的维基链接或者 URL 则不受这个消歧义影响，可以正常自动重定向。比这还要奇怪的是，通过 API 获取条目，则会提示条目不存在，没有任何重定向信息：
Nozawayu
Youmeimingl{'batchcomplete': True,
'limits': {'categories': 500},
'query': {'pages': [{'missing': True,
'ns': 0,
'title': '神魔讨绮传 ～ Magus in Mystic Geometries.'}]}}
在系统内部，这个页面究竟是以什么方式表示的？这个消歧义页是某种软件“特性”，还是单纯为历史遗留的无用页面？如果是无用页面，建议直接重定向至神魔討綺伝_～_Magus_in_Mystic_Geometries.。不过我怀疑这可能是动态的专辑名检索逻辑和静态的条目名检索逻辑发生了一些奇怪的相互作用……
VincentDirac〈Someone Thinking of Nothing〉
(トーク投稿記録)
这是因为本wiki对于搜索和链接采用了对大小写等不敏感的模式。本wiki对于大小写字母、简繁体中文和日文汉字、片假名平假名和罗马字、对应的全角与半角字符等均设置了自动重定向，并且会模糊处理空格（额词条名不允许全角空格，那么只有半角空格了）。可能与管理碰撞的插件有关。会自动识别这些可能引起消歧义的页面。但是SMW等对于大小写等是严格的，除非进行重定向，否则不能认为是一致的，在链入页面里也实际上查不到。这个问题确实比较纠结。上一次升级MW版本之后，印象中消除了一些旧的问题，但是也让其他一些地方变得看起来奇怪了（）
那个模板啊，就是这个：https://touhou.review/-/35o 确实感觉应该设置一个这个的重定向页面。这个消歧义可能是神魔讨绮传～Magus in Mystic Geometries.这个重定向导致的）
Gzz〈小石头帽子〉
(トーク投稿記録)
我没有重复出来你说的那个（消歧义）页面，如果在 wiki 里直接点链接 神魔讨绮传 ～ Magus in Mystic Geometries. 那当然是会到达目标词条的
你肯定是进入了 特殊:消歧义/神魔讨绮传 ～ Magus in Mystic Geometries.，这个是特殊页面，不是实际存在的词条，不过我不清楚你是怎么到那去的……
api 的话，确实即使是加了 redirects=1 也不会自动进行这种繁简重定向，必须要是实际存在一个重定向页面才能找到目标页面，如果你想要和浏览 wiki 时一样的自动重定向功能的话可以用扩展提供的函数 #redirect，展开一下 {{#redirect:...}}，我一直是这样做的（）
话说我知道 mw 原生支持首字母大小写的自动重定向，我刚试了下 Wikipedia 的 api 即使是不加 redirects=1 也能自动进行这种重定向，而 thb 就算加了 redirects=1 也不会重定向首字母大小写，确实很奇怪，还是可惜现在已经找不到作者来问了（）
NicoNicoNii〈Simple Dowser〉
(トーク投稿記録)
直接点是会正常到达的，直接输入链接也是会正常到达的，看起来仿佛条目就是存在的。但神奇的是，如果你在搜索框中输入文本，就会进入这个薛定谔的重定向页面。
话说我知道 mw 原生支持首字母大小写的自动重定向，我刚试了下 Wikipedia 的 api 即使是不加 redirects=1 也能自动进行这种重定向，而 thb 就算加了 redirects=1 也不会重定向首字母大小写，确实很奇怪，还是可惜现在已经找不到作者来问了
真是奇怪了。看来这 THBwiki 本身也和其中记载的内容一样，都不受常识束缚。
多谢{{#redirect:...}}的解决方案。
NicoNicoNii〈Simple Dowser〉
(トーク投稿記録)
问题已解决，多谢解答。结论：API 的重定向功能不可靠，需要按以上方法手动展开重定向。此外，作为记录，这个薛定谔的消歧义页面可以使用这个链接重现，这是在搜索框输入文本后访问的链接（手工创建重定向页面后已失效）：https://touhou.review/index.php?search=%E7%A5%9E%E9%AD%94%E8%AE%A8%E7%BB%AE%E4%BC%A0+%EF%BD%9E+Magus+in+Mystic+Geometries.
Gzz〈小石头帽子〉
(トーク投稿記録)
还真是，搜索框里直接回车就会进消歧义页面
其实我不怎么在搜索框里直接回车的，因为经常不能进想去的页面，有时会明明页面存在但是却进到搜索里（）
不过就这个问题而言，肯定还是新建一个重定向比较好，不带点的和波浪线两边不带空格的重定向都有了，怎么既带点又带空格的反而没（）所以我刚才建了
NicoNicoNii〈Simple Dowser〉
(トーク投稿記録)
明白了，神魔讨绮传 ～ Magus in Mystic Geometries是一个真实的手工重定向，API 能获取重定向页面并执行重定向，但神魔讨绮传 ～ Magus in Mystic Geometries.恰好符合繁简不敏感规则，自动重定向到了同名的繁体标题，没有对应的重定向页面，API 的action="query", titles="条目名称", redirects=1 也无法执行重定向（MediaWiki 甚至不知道发生了重定向，页面没有“重定向至”提示）。那么问题来了，是否有 API 可以查询这种重定向的目标？目前想到的临时解决方法是（正道不走，又开始用歪门邪道了……），用 action=parse, text="条目"， contentmodel="wikitext"渲染为 HTML，然后抽出其中的"title"字段……
更新：方法是展开{{#redirect:...}}。
RIGC