我不喜欢承认自己错了，但这次我确实错了，所以我会承认。
在看到 @riking 的帖子后，我回去重新阅读了代码（我完全承认我本该更早这样做），而我的测试方式仍然会触发限流。这也解释了为什么有些人在 NaNo 论坛上认为自己应该获得“出于爱”徽章，却没有得到。
9 个赞
那么，我很乐意撤回我修改它的请求！不过，文档中能有一些说明就太好了。我会在徽章上添加一些内容。
3 个赞
我愿意澄清任何可以澄清的内容，只是不确定该在哪里进行？有什么建议吗？
2 个赞
也许可以在个人资料页添加一个重置倒计时时钟？
3 个赞
你可以做一个主题组件，倒计时到 UTC 00:00，没问题……
6 个赞
我认为问题本身出在速率限制上，这导致了误解。当他们触达限制时，会误以为自己的点赞次数已用尽，但根据这个帖子的讨论，事实并非如此。
我们能否优化那里的错误提示信息，以帮助用户理解发生这种情况的原因？
4 个赞
你能截屏当前消息吗？
3 个赞
我会看看能找到什么。我自己还没见过，但我会做一些调查（除非 @ClawdiaWolf 有具体的文本，因为他们比我经历过更多。）
3 个赞
这真是那种“早该早点检查”的情况，因为该字符串是 rate_limiter.by_type.create_like 文本字符串。如果我在自定义部分搜索过，早就看到了，只是从未想到要去那里找。
这是我测试时最近的一张截图：
1 个赞
好的，但这是每日限制。还有其他错误吗？
2 个赞
这是我个人看到的唯一一条消息，也是我在 NaNo 论坛上看到其他人报告的唯一一条消息。
3 个赞
好的，你能在这里通过快速按按钮来触发它吗？还是说有其他问题？我非常困惑。
1 个赞
作为去年11月NaNo的参与者，我确实看到过这种情况。NaNo的帖子通常很受欢迎，大家也乐于点赞：slight_smile
但从实际体验来看，如果提示“请等待1小时”，一小时后我通常还能再点赞一两次，随后就会弹出新的等待时间提示，比如4小时。这是否是触发了防垃圾机制，而非点赞次数限制呢？
我在其他Discourse站点上也见过类似的行为模式…
5 个赞
我对这个主题目前的内容感到_极其_困惑。非常困惑。
3 个赞
我一直在某个我活跃的论坛上不断触及限制（为了追求“Higher Love”徽章），但提示达到每日点赞上限的警告与提示达到点赞垃圾频率限制的警告几乎无法区分。以下是我收到的消息（时间为 UTC+8）：
14:40，我收到了这条消息：
22:41，我又收到了一条消息：
22:50，还收到了一条消息：
我推测第一条消息是因为触发了频率限制，而第三条则是由于达到每日上限。如果我没有收到中间那条消息，我想我根本无法分辨这两者的区别。另外我也很困惑，因为如果点赞数在 UTC 00:00（即 UTC+8 的 08:00）重置，那么第三条消息似乎就不合理了（难道点赞垃圾频率限制器的超时时间这么长吗？）。顺便提一下，我当时是信任等级 1，如果这有帮助的话。
6 个赞
我认为该话题的核心在于，我们的错误信息在涉及使用限额时变得极其令人困惑，以至于没人完全清楚究竟发生了什么。
3 个赞
我……强烈不同意这“极其令人困惑”。
您已达到点赞次数上限。请等待 14 小时后再试。
还有什么其他英文单词可以用在这里让意思更清楚？在我看来，这已经非常明确了。
感谢分享这份喜爱！您今天仅剩少量点赞次数。
上述信息是一条附加提示，一种便利措施，一个提前预警，
它表明您今天的点赞次数即将用完，所以也许该优先考虑剩下的那些，而不是像吃糖果一样把它们一下子全用光？
我能想到的情况只有：
- 您用完了 50 次（或根据信任等级不同而变化的其他上限）点赞次数；
- 您等待了 1 小时，直到 UTC 00:00 每日点赞限制重置；
- 显然，这会根据您的时区以及您何时用完所有点赞次数而有所不同。您可能在 UTC 00:00 前 23 小时就用完了所有点赞，也可能在 UTC 00:00 前 1 小时才用完；
- 随后您在 1 小时内再次用完了 50 次点赞，此时您需要等待下一个 UTC 00:00 的到来，系统才会再次重置。
1 个赞
我只是一个旁观者，一生中从未遇到过“点赞上限”的问题。但这里更大的问题似乎是“设置上限”这一概念本身令人困惑——用户收到矛盾的信息似乎合情合理：点赞是一个良好且有用的机制，应该使用，但……又不能太多？！
据我所见，有些用户从不使用点赞功能，而另一些用户则尽可能多地点赞。既然用户在使用“点赞”功能时几乎不可能保持一致，那么允许用户随心所欲地点赞究竟会带来什么负面后果？如果是出于服务器限制或实际的垃圾信息指标问题，也许可以通过调整提示信息，简单说明为何存在上限，从而让用户感觉不那么随意。
1 个赞
消息导语中隐含了他们如何操纵信任等级。我预计那些非常活跃的点赞者本应达到 TL3 级，该等级的每日点赞上限会大幅提升 2 倍。详见：https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/。
因此，从某种意义上说，这是他们自作自受。
2 个赞
我读过那篇帖子很多次，但从未想到每日限制修饰符的呈现方式是平衡的，请不要随意改动它们。
既然这些限制已被改动，并产生了一条与其他错误信息形状相似的错误提示（考虑到触发这些信息的活动，我们都不指望用户会仔细阅读提示信息），那么解决方案似乎是：针对该实例，修改这些错误信息，使其更清晰地解释他们社区的情况。该社区规模极其庞大，并且拥有独特的互动文化。
@ClawdiaWolf 和 @Heather_Dudley，我建议策略性地使用一些奇怪的 emoji。
3 个赞