Multi-Language User Interface and Events

[rashfael]

Current Situation

Each event in venueless has a single UI language, set by the event organizers.
Venueless ships with german and english translations for the UI and allows for organizers to override any translation they want (this is sometimes used to customize texts, which doesn't count as "translating").

Categories of things that have language

Users interacting with venueless encounter different kinds of texts:

1. Labels, tooltips and other UI texts (pretty static and are shipped with code or are set globally by organizers)
2. dynamic structures configured by organizers (room names, profile field labels, user badges)
3. content provided by organizers (static pages, livestreams, subtitles, iframes, polls, chat messages, announcements, exhibitions, talk schedule)
4. content generated by users (chat messages, questions in the Q&A module, video chat rooms, profile field content)

How do multilingual events work and how could they work with venueless

To make category 1 multilingual for a single event is pretty straight forward, technically and organizationally. Localizations do already exist, we would only need to enable users to choose the UI language for themselves. We have, however, given this a fairly low priority in the past, because, for one, categories 2 and 3 are harder to solve technically and make the UI more complex (mainly for organizers), and, more importantly, category 4 seems to have no easy solution and boils down to the following question:

Does it make sense to have separate user-to-user communication for different languages (for example, chat channels separated by language) or should all users communicate with each other on a single channel and let the "spoken" language be decided by convention or organizer decree.

Having a "default" spoken language for stage chats with perhaps channels dedicated to specific languages would make sense to me.

Problems with localizing category 2 and 3

When communicating to attendees or attendees communicating with each other, talking about things that are differently labelled might be problematic. Some examples are:

• user guides explaining features or procedures of a specific event.
• troubleshooting or explaining things directly to an attendee.
• attendees coordinating amongst themselves or talking about the schedule or other content.

Does anybody have experience with for example translated talk titles? I have not encountered translation in that depth that I can remember.

Is implementing only category 1 alone an improvement or does a multilanguage event only make sense with all categories implemented/answered? What do you think?

What are your views on that topic as an organizer or an attendee?

[peterbenmeyer]

Category 1 seems useful, and we would like to try it experimentally for English+Spanish. We will have to see how it feels. -- Peter from WikiConference North America

[rashfael]

We added a setting in preferences for users to choose their interface language, which can be controlled by the locales config. This user setting just controls our existing localization (category 1).

[tthePB]

This is a hard one. Let me begin with your Category 4:
I think, that if there are different livestreams/channels with a specific language, than the chat and questions should simply be in that language. If it is however one livestream/channel, that is simultaneously translated and broadcast with multiple audio tracks, than I think a unified chat is needed and attendees/organizers have to find conventions on how to deal with that. My worry with seperate chats for each translation is that it basically splits the discourse. I think I can explain better with an example of an event we did:

• It was a conference with 80-90% German speaking attendees and the main conference language was German as well.
• In order to cater for the (important) 10-20% non-German speakering attendees, the organizer opted to simultaneous translations for the main stage. For this stage I think there should only be one chat, question and poll tool.
• There were however channels for discussions and workshops and there the organizer pre-defined the language by saying: This will only be in German and that will only be in English. Chat, questions, etc should reflect that, I think.

Category 2:
Nice to have. Yes, it adds complexity to the organizer-view, but changing simple things, like profile labels, etc is genuinely useful. I don't think it is the most important bit, but it would definitely make the multi-language-experience much more convenient.

Category 3:
Having multi-language fields for static pages, exhibitions, etc would simply be amazing. In the example mentioned above it would have made a huge difference. As hinted in my comments to category 4 I personally wouldn't go as far as providing different chats for livestreams that have alternative audio tracks – but chat labels and instructions should still be shown in the user language.

In general:
Purely from an event organizers' point of view, I think in order to make the added complexity more managable, it would be amazing to have a setting saying: "Is this a multi-language-event?" – and once you switch that on, all the translation fields for labels, room names, pages, etc PLUS the language switch for users appear. If you don't turn that on, it is a simpler, cleaner interface and won't bother people, who only have one language at their events.

I hope this is helpful. Let me know in case you need me to clarify^^

[rashfael]

Thanks for the feedback!
Yes, I also think for category 4 having separate chats is probably not what attendees expect and might just frustrate. We can rely on attendees being able to handle group communications in multiple languages organically.

Your idea for a opt-in multi-language setting is great! Not only does it add complexity only when needed for organizers, it's also something we can use to not bother existing organizers much when we're rolling out multi-language features. That's something we'll probably implement!

Great to hear your interest in category 2 and 3, would you be interested in trying out functionality related to that as soon as we have something to test?

[tthePB]

We'd definitely be interested in trying new features out as soon as they are available. Just ping me, I'm ready :)