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 curtidas
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 curtida
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 curtida
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 curtidas
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 curtida
@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 curtida
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 curtidas
@tophee Peço desculpas por reativar um tĂłpico antigo, mas tenho trabalhado bastante em suporte multilĂngue recentemente, entĂŁo estou curioso para entender um pouco mais sobre o que vocĂȘ estĂĄ falando aqui.
Confesso que estou um pouco confuso sobre por que sua solução proposta seria uma melhor experiĂȘncia para o usuĂĄrio do que simplesmente traduzir o texto personalizado para os diferentes idiomas dos seus usuĂĄrios.
Acho que seria uma experiĂȘncia estranha para um usuĂĄrio de um fĂłrum multilĂngue ter algumas mensagens automatizadas no idioma padrĂŁo do fĂłrum e outras no idioma deles. Mas talvez eu esteja entendendo mal seu ponto.
De qualquer forma, agora vocĂȘ pode restringir o nĂșmero de idiomas de interface disponĂveis usando Multilingual Plugin đ.
8 curtidas
Uau, isso parece fantĂĄstico. Vou dar uma olhada mais de perto o mais rĂĄpido possĂvel.
Em um mundo perfeito, sem restriçÔes de recursos, seria, claro, melhor traduzir tudo. Mas o problema que se tentava resolver Ă© que vocĂȘ basicamente tem que traduzir todo texto personalizado para todos os idiomas (porque nĂŁo Ă© possĂvel restringir quais idiomas estĂŁo disponĂveis para os usuĂĄrios. Se o seu plugin agora resolve isso, seria um grande avanço, como mencionado anteriormente:
Para esclarecer o que quero dizer com âefeitos colaterais negativosâ: se o Discourse foi traduzido para 30 (?) idiomas, isso Ă© Ăłtimo para os falantes desses idiomas, entĂŁo nĂŁo permitir que esses usuĂĄrios escolham a maioria desses idiomas Ă© uma desvantagem. Dito de outra forma: para permitir um idioma, preciso ser capaz de traduzir meus textos personalizados para esse idioma.
Daà minha sugestão de fazer com que, se um texto foi personalizado no idioma padrão, todos os outros idiomas recuem para o idioma padrão sempre que exibirem esse texto (a menos que também tenham uma cópia personalizada desse texto).
1 curtida
Sim, entendo o que vocĂȘ estĂĄ dizendo.
No entanto, fico me perguntando se vocĂȘ nĂŁo estĂĄ dando muita ĂȘnfase Ă necessidade de traduzir o texto personalizado para todas as lĂnguas, em vez de simplesmente focar nas lĂnguas mais comuns dos seus usuĂĄrios?
Vamos simular isso. Acho mais fĂĄcil discutir o assunto por meio de exemplos.
Digamos que vocĂȘ tenha um fĂłrum baseado na BĂ©lgica sobre ciclismo 
. 95% dos seus usuĂĄrios falam holandĂȘs 
(40%), francĂȘs 
(30%), alemĂŁo 
(15%) ou inglĂȘs 
(10% - turistas). Os outros 5% falam uma mistura de outras lĂnguas. A lĂngua padrĂŁo do fĂłrum Ă© o holandĂȘs.
Agora, digamos que personalizemos apenas o texto do bot narrativo em holandĂȘs, que a funcionalidade de âfallbackâ (reserva) seja utilizada e que a personalização em holandĂȘs seja exibida para todos os usuĂĄrios do fĂłrum. Tecnicamente, todos veriam o mesmo texto, mas 60% dos usuĂĄrios do fĂłrum podem nĂŁo entendĂȘ-lo, ou apenas parcialmente (alĂ©m disso, os falantes de francĂȘs e alemĂŁo podem sentir que Ă© um fĂłrum âflamengoâ).
Por outro lado, digamos que vocĂȘ (com a ajuda de alguns moderadores ou usuĂĄrios experientes que sĂŁo falantes nativos) tambĂ©m traduza o texto de boas-vindas personalizado para francĂȘs, alemĂŁo e inglĂȘs, e que a funcionalidade de âfallbackâ nĂŁo estivesse presente. Agora, 95% dos usuĂĄrios do fĂłrum veriam o texto personalizado em uma lĂngua que compreendem totalmente (e com a qual se identificam), e apenas 5% dos usuĂĄrios veriam um texto diferente.
Nesse tipo de cenĂĄrio, a funcionalidade de fallback pode ser Ăștil para esses 5% dos casos, mas parece que o problema maior Ă© traduzir o texto personalizado para o punhado de lĂnguas mais comumente usadas, em vez de se preocupar com o fato de que uma pequena minoria de usuĂĄrios verĂĄ um texto diferente.
4 curtidas