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개(?) 언어로 번역되었다면 해당 언어 사용자에게는 좋은 일입니다. 따라서 이러한 사용자들이 대부분의 언어를 선택하지 못하게 하는 것은 불리합니다. 다르게 말하자면, 특정 언어를 허용하려면 해당 언어로 제 사용자 정의 텍스트를 번역할 수 있어야 합니다.
그래서 제 제안은 다음과 같습니다: 기본 언어로 텍스트가 사용자 정의된 경우, 해당 텍스트를 표시할 때 다른 모든 언어는 (해당 텍스트에 대한 사용자 정의 사본이 있는 경우를 제외하고) 기본 언어로 폴백(fallback)하도록 만드는 것입니다.
1개의 좋아요
네, 말씀하시는 내용을 이해합니다.
다만, 사용자들의 가장 흔한 언어에 초점을 맞추는 것보다, 사용자 정의 텍스트를 모든 언어로 번역해야 한다는 필요성에 너무 많은 비중을 두고 있는 것은 아닌지 궁금합니다.
이 주제를 예시를 통해 이야기하는 것이 더 쉬울 것 같습니다. 상황을 가정해 보겠습니다.
벨기에에 기반을 둔 사이클링 
포럼이 있다고 해 보겠습니다. 사용자의 95%는 네덜란드어 
(40%), 프랑스어 
(30%), 독일어 
(15%) 또는 영어 
(10% - 관광객)를 사용합니다. 나머지 5%는 기타 언어의 혼합을 사용합니다. 포럼의 기본 언어는 네덜란드어입니다.
이제, 네덜란드어로만 내러티브 봇 텍스트를 사용자 정의하고, “폴백(fallback)” 기능이 의존되며, 네덜란드어 사용자 정의가 포럼의 모든 사용자에게 표시된다고 가정해 보겠습니다. 기술적으로는 모든 사용자가 동일한 텍스트를 보게 되지만, 포럼 사용자의 60%는 이를 이해하지 못하거나 부분적으로만 이해할 수 있습니다(게다가 프랑스어와 독일어 사용자는 이것이 ‘플랑드르’ 포럼이라고 느낄 수 있습니다).
반대로, 몇 명의 모더레이터나 파워 유저(원어민)의 도움으로 사용자 정의 환영 텍스트를 프랑스어, 독일어, 영어로도 번역하고 ‘폴백’ 기능이 없다면, 이제 포럼 사용자의 95%는 완전히 이해하고 공감할 수 있는 언어로 사용자 정의 텍스트를 보게 되고, 5%의 사용자는 다른 텍스트를 보게 됩니다.
이러한 시나리오에서, 폴백 기능은 해당 5%의 경우에 유용할 수 있지만, 더 큰 문제는 소수의 사용자가 다른 텍스트를 보는 것이 아니라, 사용자 정의 텍스트를 가장 일반적으로 사용되는 소수의 언어로 번역하는 것인 것 같습니다.
4개의 좋아요