Admin edit: This conversation has now evolved to a proposal that can be read here.
One of the things that put me off with the original forum is the apparent confusion between categories and languages, e.g. looking up exchanges about hiking node networks and finding that they are in German or Dutch. It would be great if we could come up with an architecture that is self explanatory with this regard.
Unlike the original forum, Discourse has great support for tags. These seem like a good way to represent topics – especially because they are non-exclusive.
So I would be inclined to use tags for topics (e.g. “cycling”, “rendering”, “overpass-turbo”) and categories for communities (language communities, regional communities, organized communities such as local chapters).
Also note that we have the option to evolve from having one category with multiple-tags, to split those topics into their own sub-category if needed in the future, avoiding creating new (low traffic) categories or subcategories unless there is enough volume.
the one I made in another thread, to have one server per language
your proposal above
one where we somehow use Discourse to create a clear hierarchy of categories, and create a top-level category for each language.
one where an editorial committee decides which topics must be in English
My main concern is that I don’t want to be involuntarily exposed to a huge unstructured list of categories whose messages I cannot read anyway. Given how the Discourse app works on my iPhone, having one server per language would be easy: I would connect only to the fr and en servers, and would get only categories I can read.
Also, we need to take in consideration that some themes are more popular in some languages and non-existent in others. Here is where I suspect tags can help alleviate the category-creation-need and opt for a more organic growth, where only when there is a significant volume of topics around the same theme that become distracting for other topics in the same category, we create a new subcategory for that.
How to make decisions about this? I guess we’ll have to rely on language-communities to self-organize and decide what’s most effective for them, rather than a global policy?
I’ve taught UX design, so I can see what you’re trying to do Unfortunately, on this topic my imagination as a user is too limited to produce anything vaguely credible. If I resort to magic though, I can perhaps try something.
Imagine a magic technology that translates texts from any language to any language. Then, my ideal solution would be a unified forum with a set of meaningful categories and tags that I would choose according to my interests, including some for world regions. And all messages would be presented to me in my native language.
Alternatively, comparing to my experiences as a computer programmer, another ‘ideal’ world would be one where everybody speaks English. Once again, a unified forum with categories for world regions but the forum would be 100% in English.
In the real world now… let’s see if clever ideas emerge. I liked the idea of one server per language because it would be easy to select your favorite languages (just connect to the corresponding servers) , but I’m sure there are various drawbacks to that. And it probably does not help much with local tag-cultures.
This has been discussed on OSMUS slack channel #discourse-community-rollout:
The point of contention seems to be who will pay for the translation (I nominate HOT because they have a ton of money and have a mission dedicated to community development) I personally don’t believe we should create any language specific forums on this site until we try out that plug-in. I see it being a huge missed opportunity if we continue to fragment the community around language when there are other options to test out.
I think there’s at least a chance we get sponsored, it’s a worthy pursuit. But if not just a sliiiiiice of this budget would suffice, I think. Especially when HOT are so vocal about the importance of localization I don’t see why they wouldn’t support this.
Perhaps the biggest barrier is the (all-volunteer?) operations team whether or not they have the time to implement the translator and test it. Who here is on the dev side of this? Is it feasiable to implement? @nukeador?