Switch language without restart

[jp8]

For supporting users, it would be very useful if I could quickly switch my Jamulus client to the language of the user.

Right now it can be done, but it requires restarting Jamulus. Ideally I would be able to do it seamlessly while holding a conversation with the user.

If that's not possible, perhaps the Jamulus client could, on language change:

1. save the current connection to the config file
2. restart
3. restore the connection

[gilgongo]

Sounds like a good idea. If a restart is needed, it's a little unconventional to trigger that on changing a drop-down (particualry since no other controls in the settings would need that). So in the name of usability, perhaps showing a "restart" button once a different language has been set?

[jp8]

Eclipse sometimes does a 'surprise' restart, for example when you change workspace.

But ideally the Jamulus UI could switch language seamlessly without needing a restart.

[gilgongo]

Eclipse sometimes does a 'surprise' restart

If the definition of "usability" is "things acting as you expect", then a surprise would seem not to be good usability. But yes, ideally without a restart.

[jp8]

Yes I completely agree - it always panics me when Eclipse does that.

[trebmuh]

... the Jamulus UI could switch language seamlessly without needing a restart.

👍

[hoffie]

I've had a quick go at this:

• Jamulus already uses the necessary translation infrastructure.
• It can be re-worked to be called during runtime again.
• The UI can be re-translated on-the-fly. Huge limitation: This only applies to the static parts which come from the .ui files. In practice this means that static labels are re-translated, while menus and list items are not.
• Fixing the latter would probably require splitting all tr() calls out into their own methods which could be called in response to language changes. This sounds like a lot of detail work.

Nut sure what would be a good path forward though...

1. Keep as-is?
2. Keep as-is but simplify restarting (e.g. convert the dialog into a "Do you want to restart now?" question)?
3. Use my half-done attempt (I guess we shouldn't...)?
4. Try to work on the required tr() call splitting? (I guess Pareto applies: It would probably be sufficient to touch the "main" places (e.g. constructors) to cover 80%)

Background: https://wiki.qt.io/How_to_create_a_multi_language_application

The PoC is here: master...hoffie:runtime-language-switching

[ann0see]

I‘d go with 2. it’s quick and simple.

[jp8]

I really like option 4. The scenario for this is one Jamulus user trying to help another, and they are not using the same language, making it difficult to give clear instructions of what to click on.

Being able to switch languages would really help, if it requires a quick restart it might be ok. But if it requires restarting and then finding each other on a server again, it's not ideal - especially when you consider that the server might be near capacity and you might not get the chance to re-connect.

[ghost]

Maybe it would be best to start another instance of Jamulus where you have changed the language, but don't connect to anything (audio and sockets). That way you can compare the languages in both instances of Jamulus.
OR just use 2 computers.

[jp8]

You're right David that's a really good workflow for that scenario

[gilgongo]

What's the scenario exactly?

[jp8]

The scenario was supporting another user during an online event when the user's Jamulus is on a different language. I wanted to be able to change languages instantly, which would allow me to instruct the user with the exact UI wording that the user sees.

David pointed out that I can accomplish it by running a second jamulus instance.