That would require that admins can limit which locale their users can choose. That would also be a solution, but it would prevent communities from benefiting from the increasing number of translations that discourse provides out of the box.
You are fixating on problems specific to you, that is, you believe that customizing text in one language should somehow magically customize the same text in every available human language. I do not share this belief and I feel, very strongly, that you should bear the burden of your own choices with regards to text customization. If you want to customize text in every language, you take responsibility for that work, not us.
Furthermore, I also fail to share your belief that non-customized text is some kind of disaster of epic proportions. Default text is harmless.
My reply was actually based on my understanding of the code when I last changed it. I guess it was a while back 
I very much prefer that we are now consistent across all UI text even though it means more work on admins when they customize some text. I also 
your suggestion.
4 个赞
No, this is a misunderstanding. I am merely looking for a way to allow users to use existing locales while still allowing site admins to customize texts, especially the discobot welcome message. Currently, you have the choice of either allowing user locales or customizing.
I have said nothing to convey such a belief. However, default text can be a problem under certain circumstances, for example when you have customized the welcome message to provide certain site specific information to new users but then some users nevertheless receive the default welcome message.
Untrue, you can customize in both cases. Just not to your satisfaction.
Simply customize all affected locales, this already works.
Since you cannot exclude any locales, that would be “all locales”, which brings us back to
Why not just customize it in the ~4 most common languages after English? Surely you’re not going to have users speaking American Cherokee Indian anytime soon.
Yes, as I said, limiting the locales that users can choose would also solve the problem, albeit in an unnecessarily limiting way.
What do you think about @tgxworld’s proposal above?
I don’t know about this. A new user wouldn’t have had the chance to select her/his preferred locale before the welcome message is sent out. I’m pretty sure they are most likely going to get your customised message in the default locale of the site.
Unless you have set locale from accept language header turned on
Or if users choose to respond to the bot after they have customized their locale (though that would not concern the welcome message)
1 个赞
If you’re knees deep into customisations, wouldn’t it be better to just turn off set locale from accept language header ? Even with my proposed fix for your use case, they are going to end up getting the welcome message in the default locale of your site. I don’t feel very strongly about this and like @codinghorror said, customising the welcome message for the 4 next common languages would be good enough.
1 个赞
Yes, I did that, of course, when I realized the consequences. But I think it’s a really great setting for multi-lingual sites because it immediately sends a message to new users when they first visit the site. In fact, even on mono-lingual sites, people who are not native speakers of the site language might be attracted by having the UI in another language.
Yes, unless their browser locale is in one of the languages for which I customized the message. But that, I think, is fine because on the plus side, what users get is the whole UI in their language. You can’t have it all. And you might even speculate that if that UI brings more people from that language community to my forum, chances are that eventually someone helps translate the welcome message (or whatever else is missing).
Since this would also require a new feature (limiting which locales are available on a site) I guess it’s a matter of cost/benefit calculation. The benefit of limiting user locales would be tangible but rather limited and with negative side effects (but still a viable solution). The benefit of your suggestion would be great and would increase in time as more discourse locales become available. So, in my mind, it is clearly the better solution in terms of benefit and openness for future development.
I have no clue about the cost dimension. Could you add it to the equation?
SInce this topic has been somewhat inconclusive I’d like to return to what I think was an excellent suggestion:
This would be immensely helpful and as far as I can tell (which is not very far) it’s probably a rather easy thing to accomplish. Any chance that this could get implemented?
Just to reiterate why this is useful, since the discussion above is somewhat complex: basically, it solves the problem that once you customize any text element in your site’s default language, you can no longer allow users to choose their own locale (let alone enable set locale from accept language header) because they will be seeing the default texts in their respective language and those will no longer correspond to the texts in the site’s main language.
I should add one important detail to the proposed solution:
if you customize a translation of the default site locale, all the other locales should treat its corresponding translation text as missing unless the translation text has also been customized
In other words: if my site is in English and I customized a specific text in English but also in French, all locales will fall back to the default locale for that specific text except for the French locale, (because it has also been customized so that a correspondence between the translations can be assumed).
5 个赞
Any news on this? I’d love to know if this is planned in any way:
If it’s not planned, could someone give an indication of what kind of work would be required to implement this?
To me it looks like what is needed is an routine that is activated whenever a page is served in a language other than the site’s default language. That routine would check if any of the text elements on that page have been modified in the default locale. If not, exit. If yes, it checks if they have also been modified in the current language. If yes, exit. If no, serve the text in the default language.
Alternatively, instead of checking things every time a “foreign” page is served, all current procedures could be left unchanged and instead changes are made whenever default texts are customized. For example, whenever a default text is modified in the default language, all default copies of all other languages are deleted so that the default text will be served (or will it?)
That latter option has quite some pitfalls though, because you need to make sure that only default copies are deleted, not modified ones. And what happens if the default translation is updated on transifex? That should not lead to the copy magically reappearing when the discourse instance is upgraded.
So the first option is probably the better one, but I have no idea how much extra resource use it would imply for serving pages in a foreign language…
1 个赞
@tophee Did you find a solution to this? I’m currently looking at how to restrict the locale list. If there is no solution yet, I will look to implement on… Thanks in advance for your feedback
The solution is here:
But I don’t think it has been implemented yet.
1 个赞
I suppose @tgxworld’s fix is low priority? Or is it on the roadmap at all?
I don’t think I’m able to implement this myself but I’m thinking of maybe trying a kind of brute-force solution by simply deleting (or making unaccessible) all locales that I don’t want to customize (and hence want to prevent people from using).
Could someone give me a hint as to how to gi about tbis? I’m guessing that I need a rather simple plugin that “breaks” the unwanted locales?
3 个赞
@tophee 抱歉挖出旧帖，但我最近一直在大量处理多语言支持的问题，所以想进一步了解您在这里提到的内容。
我承认，我有点困惑：为什么您提出的方案比将自定义文本翻译成用户各自的语言能提供更好的用户体验？
我觉得，在多语言论坛上，用户看到一些自动消息是论坛默认语言，而另一些则是他们自己的语言，这会是一种奇怪的体验。不过，也许我误解了您的观点。
无论如何，您现在可以通过 Multilingual Plugin 🌐 来限制可用的界面语言数量。
8 个赞
哇，这看起来太棒了。我会尽快仔细查看。
在一个没有资源限制的理想世界中，当然最好是将所有内容都进行翻译。但我们要解决的问题是，您基本上必须将所有的自定义文本翻译成每一种语言（因为无法限制用户可使用的语言。如果您的插件现在能解决这个问题，那将是一个巨大的进步，正如之前提到的：
为了澄清我所说的“负面影响”：如果 Discourse 已被翻译成 30 种（？）语言，这对这些语言的使用者来说是一件好事，因此不允许这些用户选择其中大多数语言是一种劣势。换句话说：为了允许某种语言，我必须能够将我的自定义文本翻译成该语言。
因此，我建议实现这样的功能：如果某段文本已在默认语言中进行了自定义，那么在显示该文本时，所有其他语言都将回退到默认语言（除非它们也有该文本的自定义版本）。
1 个赞
是的，我明白您的意思。
不过，我想知道您是否过于强调需要将自定义文本翻译成每一种语言，而不是仅针对用户最常用的语言？
让我们通过一个假设场景来探讨这个问题。我认为通过具体例子来讨论会更清晰。
假设您运营一个位于比利时的自行车论坛 
。95% 的用户使用以下语言：荷兰语 
(40%)、法语 
(30%)、德语 
(15%) 或英语 
(10% - 游客)。其余 5% 的用户使用其他多种语言。论坛的默认语言是荷兰语。
现在，假设我们仅将叙事机器人的文本自定义为荷兰语，并依赖“回退”（fallback）功能，那么所有论坛用户看到的都是同一套荷兰语自定义文本。虽然从技术上讲所有人看到的文本相同，但 60% 的用户可能无法理解，或只能部分理解（此外，法语和德语用户可能会觉得这是一个“佛兰德”论坛）。
相反，假设您（在几位母语为当地语言的版主或核心用户的协助下）还将自定义欢迎文本翻译成了法语、德语和英语，并且没有启用“回退”功能。这样一来，95% 的论坛用户都能看到他们完全理解且能产生共鸣的自定义文本，而只有 5% 的用户会看到不同的文本。
在这种场景下，“回退”功能或许对那 5% 的情况有所帮助，但更大的问题似乎在于：与其担心少数用户看到不同的文本，不如将自定义文本翻译成 handful（少数几种）最常用的语言。
4 个赞