标题是否都应该被翻译？目前并不统一
我曾将其与一个旧得多的版本进行了比较。其中也没有提到“膝盖骨的矛盾”
有人有什么好主意来缩短这个话题投票插件的文本吗？
目前，“Stimme”（投票）是唯一不至于太长的词。但我觉得很难看出它是一个活动。特别是当一个人投票后，我总是读到“1 Stimme”。对我来说，“Abstimmen”（投票）作为替代方案也还算合适。
对于“Geschlossen”（关闭），可以使用“Beendet”（结束）。
但是对于“Abgestimmt”（已投票），我还没有想到什么。
有人有什么想法吗？
这里是怎么回事，你觉得？在“批量奖励”徽章页面。我的笔记本电脑设置为德语区域设置，但我的 Discourse 设置为英语（美国）。除了语言混合问题（我认为我们应该尝试解决），我们还能对这个 UI 做些什么来让它更好地支持德语等长单词语言？
选择文件 会显示，因为它是由浏览器提供的 UI 元素。浏览器使用系统语言。
1 个赞
“Gewählt”怎么样？
或者“Votiert”？很少使用，但在Duden词典里有…… 
1 个赞
我注意到“主题”或“主题组件”下的“关于”链接被翻译成了“关于我们”，就像与 /about 页面相关的文本一样。
admin_js.admin.customize.theme.about_theme
但在这里，它不是关于“我们”，而是关于主题（组件）的更多信息。我觉得只用“关于”很奇怪。
然后我考虑使用“文档”。如果这是指文档，那么原文也可以是“Documentation”。所以这也不太合适。
ChatGPT 建议了“信息”、“概述”、“详细信息”和“了解更多”。“了解更多”（Learn more）在很多其他地方也被使用。例如，在插件列表中，有类似的链接。但是，前面总会有一点文字。
与“来源”和“许可证”并列，我也觉得“信息”很好。
有什么其他想法吗？
1 个赞
也会建议“Details”。这样即使不翻译，也更合适。
1 个赞
好主意。我认为这里的答案是为主题组件提供不同的“关于”文本，而不是为链接到关于页面的“关于”重复使用相同的文本。我会记下来。
这是一个不同的字符串
但翻译是相同的。我认为 Crowdin 会自动翻译相同的文本。所以你需要有人手动检查上下文
2 个赞
哦，谢谢告知。有意思。所以它只是被错误地翻译成了德语。 
你能否在 Crowdin 上提供一个修复建议？我认为在这种情况下，“Details”作为“About”的德语翻译也未尝不可。
1 个赞
完成
我还尝试为聊天记录（js.chat.retention_reminders.indefinitely_short）建议“unbegrenzt”，因为对我来说，“unbestimmt”听起来像是“未定义”。
但我无法建议“unbegrenzt”，因为它之前已经被建议过了。
3 个赞
这似乎是更好的选择。
2 个赞
我刚看到风格指南选择了“主题摘要”。
那么我建议两者都用“概述”。
4 个赞
您好，我注意到 Discourse 在所有地方都使用了性别中立的语言，即使用了泛指的阳性。我想坐下来把这些词语变成性别中立的。例如，“Benutzer”（用户）将变成“Benutzer:in”。您对此有什么看法？有什么更好的想法吗？
1 个赞
是的，这确实是这样。
几周前，我们刚刚收到翻译机构的询问，是否应该接受他们提出的性别中立翻译，我当时很不情愿地否定了。
我认为翻译人员不应接受这些更改，原因有多种：
- 这将在各种地方破坏用户界面。Discourse 已经难以处理德语长单词，在某些地方，“Benutzer”（用户）已经很难适应用户界面。将其扩展到“Benutzer:innen”或“der/die Benutzer:in”将是一个挑战。
- 有多种书写性别中立的方式。例如，“user”可以翻译为：
- Benutzer:in
- Benutzer*in
- BenutzerIn
- der/die Benutzer/in
- Benutzer und Benutzerin
- Nutzende
我可以向你保证，一旦我们开始使用其中一种风格，人们就会抱怨我们使用了错误的风格。他们还会抱怨我们首先使用性别中立语言，但这又是另一回事了。
我们曾就正式/非正式语言（Sie / du）的使用进行过类似的讨论。别误会我的意思。我真的很希望在 Discourse 中支持性别中立的德语。正式语言也是如此。但这应该由管理员决定他们想使用什么，而不是我们。
而且，将当前类型的翻译保留为默认设置，同时允许用户在非正式/正式和性别中立或非性别中立之间进行选择，还有一个好处是，我们不会立即破坏所有人的用户界面。这将为我们提供调整用户界面以适应长单词不适合的地方的时间。
然而，要实现这一点，我们需要在 Discourse 中支持语言变体。几年前，我创建了一个概念验证插件 (https://github.com/gschlager/discourse-german-formal-locale)。将其集成到核心应该很容易。但我们的 Crowdin 集成（翻译机器人）需要进行更改才能同步语言变体。我估计这大约需要 3-5 天的工作量。
我目前还不知道何时——遗憾的是时间很有限——但我已决定在今年内对 Discourse 和我们与 Crowdin 的集成进行必要的更改，以便我们最终能够提供语言变体（对于德语，即 du/Sie 以及至少一种性别中立的形式）。
3 个赞
在此处简短地打断一下：据我理解，语言变体是全局设置的吗？或者用户是否也有可能单独选择一种变体？
全局或，如果管理员允许，也可以由任何用户。因此，现有的语言选择系统不会改变。只会增加额外的变体。
1 个赞
当 Set locale from accept language header 启用时，它将如何工作？如果启用，它是否总是显示德语，而不是德语（正式）或德语（中性）？如果我未登录，我是否也可以看到此论坛的德语（中性）版本？
管理员是否需要决定是让所有人都看到德语（正式）版本，还是让未登录的德语合作伙伴看到德语（中性）版本，而其他具有不同语言偏好的合作伙伴则看到他们偏好的语言版本？
也许将关于性别划分的问题和进一步的讨论移到另一个主题会更有意义。这并不是翻译错误。
3 个赞
在英文版中，管理侧边栏中的关键词是用 & 连接的。而在德文版中，我们有时用 u.，有时用 &，有时用 und。我曾在夏天指出过，侧边栏的空间本来就很有限，所以我无法理解为什么会使用 und 而不是 & 符号。可惜我再也找不到 Crowdin 上的评论了，因为英文的写法后来被更改了。我当时应 @mcwumbly 的要求创建的主题仍然存在。当时，und 被改成了 u.（“und Authentifizierung” 的缩写）。但后来在其他关键词上并没有继续这样做。
我刚才看到 @gerhard 提议了“Server & Protokolle”，在校对后，新版本可能会是“Server und Protokolle”。是否测试过这个版本不会太长？看起来它刚好能放下。
尽管如此，我还是不太明白为什么我们不能像英文原版那样使用
& 符号，或者至少在空间已经存在问题的情况下，坚持使用 u.。
4 个赞