部分网站文本无论我们如何修改，都会以原始形式显示。目前我们仅在消息或通知中观察到这种情况。
例如在以下消息中：
rate_limiter.by_type.create_like:
您已达到点赞数量上限。请等待 %{time_left} 后再试。
如果您需要更多项目，请告诉我 
1 个赞
当我尝试自定义网站上的 rate_limiter.by_type.create_like 文本时，当用户超过“每日最大点赞数”设置时，会显示自定义文本。您的网站使用的是哪个版本的 Discourse？您的网站的默认语言环境是什么？您的网站是否启用了“允许用户语言环境”设置？
1 个赞
您的站点使用的是哪个版本的 Discourse？
我们使用的是 2.6.0.beta2 版本
您的站点的默认语言环境是什么？
在站点设置中：fa_IR
在 app.yml 中：（未设置）
您的站点是否启用了“允许用户设置语言环境”选项？
否，已禁用
同样的问题也出现在以下文本中：
js.topic.deleted_by_author.other
（主题由作者撤回，除非被标记，否则将在 %{count} 小时后自动删除）
2 个赞
我在某些文本自定义方面遇到了完全相同的奇怪问题。
用户本地设置已禁用。
我几小时前使用最新版本的 Discourse 重新构建并更新了它。
我的默认语言是匈牙利语。
我只能通过编辑英文版本来更改这些文本。所以这可能与英文有关。如果我编辑英文，匈牙利语也会被重写。
该问题将通过此 PR 修复：
这是另一个问题。这可能是一个回归错误。我正在调查。
@nildarar 和 @Don：你们是否考虑过在 https://translate.discourse.org/ 贡献翻译，而不是在管理面板中自定义未翻译的字符串？这样其他用户也能从你们的努力中受益。
5 个赞
我无法复现该问题。我将测试论坛切换为波斯语（فارسی），自定义了 js.topic.deleted_by_author.other，删除主题后，自定义文本成功显示。
您所说的“同样的问题”，是指当您自定义该字符串时看到的是英文文本吗？这是因为该字符串尚未翻译成波斯语。您可以在 Crowdin 上进行翻译——这是该字符串的 直接链接。
1 个赞
我刚刚用各种俚语定制了文本，让语言和论坛更具个性化。这就是为什么我还没有以官方方式进行翻译。但我觉得现在是加入 Crowdin 进行翻译的时候了。感谢 Gerhard！
1 个赞
感谢 @gerhard 关注此问题。
是的，我非常希望能提供帮助。但在这方面我有两个问题：
-
由于词汇量庞大，在 Discourse 环境之外进行翻译是一项艰巨的任务，在许多情况下需要测试和预览。这正是当前翻译存在的问题：某些词语并未在正确的位置被翻译。我希望有一种方法能让我们直接从 Discourse 向社区提交翻译，这将避免许多问题。
-
我们在社区中使用自己的术语，并为不同功能赋予了特定名称。也就是说，在我们的论坛中，像“主题（Topic）”、“回复（Replay）”、“楼主（OP）”、“点赞（Like）”等词汇并没有对应的标准翻译。此外，为了更贴近用户，我们将文本和消息翻译成了口语化的表达。因此，我们必须在本地进行这些个性化设置。
是的，正是如此。当用户删除一个主题时，会显示该消息的英文文本，尽管我们已经在站点设置中修改了这段文字。
我曾多次尝试参与翻译工作，但由于看不到文本在正确的位置，我无法理解其真实含义，因此无法提供高质量的翻译。我不确定这种翻译方式是否正确。很希望能听听您在这方面的意见。
1 个赞
很抱歉，我无法复现该问题。在我的测试中，即使自定义时不存在对应的翻译，客户端也会显示自定义后的文本。
这已在我们的开发路线图之中。我希望能在今后的 6 到 12 个月内完成这项工作。
在这种情况下，使用“自定义文本（Customize Text）”功能是正确的选择。这正是我们开发该功能的原因。
我通常的做法是：每当看到未翻译的字符串时，我会前往 Crowdin，搜索该字符串并贡献我的翻译。我知道直接浏览 Crowdin 上所有未翻译的字符串列表可能会让人望而却步，尤其是当你不知道这些字符串具体用在哪里时。因此，我推荐采用相反的方式进行。
2 个赞
谢谢，那我再去检查一下，或许能提供更多详细信息。
这太令人兴奋了 
这个功能太棒了 
谢谢你的好建议，真希望我们能有一种方式手动更新来自 Crowdin 的已批准 Discourse 翻译。这样我们就可以在 Crowdin 中记录通用变更，并每周更新翻译。修改翻译后等待月度更新确实有点麻烦。
抱歉用我的想法打扰你。
1 个赞
我们最近开始每周更新翻译（每周二）。也许这会有所帮助……
2 个赞