What exactly are the effects of "allow user locale"

feature
,
#22

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.

#23

My reply was actually based on my understanding of the code when I last changed it. I guess it was a while back :wink: 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 :+1:t2: your suggestion.

4 Likes
#24

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.

#25

Untrue, you can customize in both cases. Just not to your satisfaction.

Simply customize all affected locales, this already works.

#26

Since you cannot exclude any locales, that would be “all locales”, which brings us back to

#27

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.

#28

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?

#29

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.

#30

Unless you have set locale from accept language header turned on :wink:
Or if users choose to respond to the bot after they have customized their locale (though that would not concern the welcome message)

1 Like
#31

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 Like
#32

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?

#33

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 Likes
Multilingual sites: ask for preferred language at registration
Make a multi-language forum
Changing forum locale via URL param
#34

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 Like
#35

@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

#36

The solution is here:

But I don’t think it has been implemented yet.

1 Like
#37

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 Likes
#38

@tophee Apologies for reviving an old topic, but I’ve been working alot on multilingual support recently, so I’m curious to understand a bit more about what you’re talking about here.

I confess, I’m a little confused as to why your proposed solution is a better user experience than just translating the customised text into the different languages of your users?

I feel it would be a strange experience for a user on a multilingual forum to have some automated messages in your forum’s default language and some in their own language. But maybe I’m misunderstanding your point.

In any event, you can now restrict the number of available interface languages using the Multilingual Plugin 🌐.

8 Likes
#39

Wow, that looks fantastic. Will take a closer look asap.

In a perfect world with no resource constraints, it would of course be better to translate everything. But the problem that was trying to solve is that you basically have to translate everything customized text into every language (because it isn’t possible to restrict which languages are available to users. If your plugin now solves that, it would be a huge advancement, as mentioned earlier:

To clarify what I mean by “negative side effects”: if discourse has been translated into 30 (?) languages that is great for speakers of those languages, so not allowing these users to choose most of those languages is a disadvantage. Putting it differently: in order to allow a language, I must be able to translate my custom texts into that language.

Hence my suggestion to make it so that if a text has been customized in the default language, all other languages will fall back on the default language whenever displaying that text (unless they also have a custom copy of that text).

1 Like
#40

Yes, I see what you’re saying.

However, I wonder whether you’re putting too much emphasis on the need to translate the customised text into every language, as opposed to just targeting the most common languages of your users?

Let’s game this out. I think it’s easier to talk about this through examples.

Say you have a forum based in Belgium about cycling :bike:. 95% of your users speak either dutch :netherlands: (40%), french :fr: (30%), german :de: (15%) or english :uk: (10% - tourists). The other 5% speak a mixture of other languages. The default language of the forum is dutch.

Now let’s say we just customise the narrative bot text in dutch, the “fallback” feature is relied on, and the dutch customisation is shown to every user of the forum. Everyone would technically see the same text, but 60% of the forum’s users may not understand it, or only partially (moreover, the french and german speakers may feel it’s a ‘flemish’ forum).

Conversely, let’s say you (with the help of a few mods or power users who are native speakers), also translated the customised welcome text into french, german and english and the ‘fallback’ feature wasn’t present. Now 95% of your forum’s users would see the customised text in a language they understand fully (and relate to), and 5% of your users would see different text.

In this kind of scenario, the fallback feature may be useful for that 5% of cases, but it seems the bigger issue is translating the customised text into the handful of most commonly used languages, rather than that a small minority of users will see different text.

4 Likes
#41

I see what you mean but part of your argument stands and falls with how you construct your example. I would construct it somewhat differently (without claiming that yours is invalid): I would say close to 100 percent of the users understand English, at least to the extent that they can understand the site navigation and other non-content text. For this reason, my site language would be English. But when it comes to the translation of posts, an unknown percentage of users would appreciate having those translated into their native language (using the translator plugin), but for this to be available, they need to change their locale. So this is my main motivation for allowing multiple (ideally: all available) locales.

To explain this motivation a bit more: it is not easy to cultivate a truly multi-lingual forum, especially in this kind of context where English kinda seems to work and thus becomes the norm. I would argue that a major benefit of the translator plugin is that the experience of being able to translate posts from other languages into your own increases the acceptance of posts in a non-English language and hence also users’ willingness to write in their own language whenever they feel uncomfortable with English.

Having said all that, I guess we’re also coming from two different directions (or trying to solve two different problems). You’re trying to find the solution within the status quo so that most users can understand what they see. I’m trying to find a way to ensure that all users see the same information.

My problem is not primarily that of translation but rather a consequence of translation being done, but incorrectly, if I may say so.

Putting it differently still, I’m trying to stay in control of what my website says and currently there is a trade off between being in control and being heard. If I turn off locales, I’m in full control of what my site says, but some users may not understand it. If I turn on locales (even if only a few), I am no longer in control of customized text (unless I translate them into each locale, of course).