starred/mumble-mumble-voip

Fork 0

mirror of https://github.com/mumble-voip/mumble.git synced 2026-03-03 00:46:56 -05:00

New languages need matching Qt base translation #330

New issue

Open

opened 2026-02-20 19:21:59 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-20 19:21:59 -05:00

Owner

Originally created by @hacst on GitHub (Aug 17, 2014).

Originally assigned to: @hacst on GitHub.

For our existing languages we were able to re-use translations done for the virtualbox project (qt_XX.ts). Now that transifex allows many new languages to be translated we will have to think of a way to get matching Qt translations as well otherwise we won't be able to ship those languages on release.

Ideally we would figure out the set of Qt strings we need and put them on transifex just like we do for our own strings but the "figuring out" part might be tricky.

Originally created by @hacst on GitHub (Aug 17, 2014). Originally assigned to: @hacst on GitHub. For our existing languages we were able to re-use translations done for the virtualbox project (qt_XX.ts). Now that transifex allows many new languages to be translated we will have to think of a way to get matching Qt translations as well otherwise we won't be able to ship those languages on release. Ideally we would figure out the set of Qt strings we need and put them on transifex just like we do for our own strings but the "figuring out" part might be tricky.

deekerman added the

priority/P3 - Somewhat important

release-management

labels

2026-02-20 19:21:59 -05:00

deekerman commented

2026-02-20 19:22:02 -05:00

Author

Owner

@thomasbonte commented on GitHub (Mar 13, 2015):

We hit the same issue with the MuseScore project https://github.com/MuseScore

Here is the issue in particular - http://musescore.org/en/node/30266#comment-133361

In there I explain I found this unofficial qtbase translation project: https://www.transifex.com/projects/p/qtbase/

Currently we still have no definitive solution.

@thomasbonte commented on GitHub (Mar 13, 2015): We hit the same issue with the MuseScore project https://github.com/MuseScore Here is the issue in particular - http://musescore.org/en/node/30266#comment-133361 In there I explain I found this unofficial qtbase translation project: https://www.transifex.com/projects/p/qtbase/ Currently we still have no definitive solution.

deekerman commented

2026-02-20 19:22:03 -05:00

Author

Owner

@hacst commented on GitHub (Mar 14, 2015):

@thomasbonte : Thanks for chiming up in here. I'll definitely keep an eye on how that issue progresses on your end end.

It's tricky. If there was an easy way to get only the set of strings we use in Qt we would add them to our source translation files and be done with it. But all of Qt is a bit much to just dump on our translators. qtbase has almost as many strings as Mumble itself. I guess a workaround would be to just offer it on transifex and keep a list of strings that we know have to be translated (or manually strip the qtbase string set and readd strings as needed). That's bound to show on the users end though.

We got it, nl and tr translations from virtualbox and they do have more (https://www.virtualbox.org/ticket/2018) we can use. It definitely doesn't cover everything either though, some languages aren't complete and I don't think it's tracking Qt closely in any way shape or form.

The project you linked seems to be very incomplete at this point. I think if something like this is to succeed multiple projects have to get on board and ideally the Qt project would make it an official user driven thing. Ideally it would use a web platform like transifex. Maybe trying to get there is the route we will have to take. It would definitely cut down on future duplication of work if it panned out.

@hacst commented on GitHub (Mar 14, 2015): @thomasbonte : Thanks for chiming up in here. I'll definitely keep an eye on how that issue progresses on your end end. It's tricky. If there was an easy way to get only the set of strings we use in Qt we would add them to our source translation files and be done with it. But all of Qt is a bit much to just dump on our translators. qtbase has almost as many strings as Mumble itself. I guess a workaround would be to just offer it on transifex and keep a list of strings that we know have to be translated (or manually strip the qtbase string set and readd strings as needed). That's bound to show on the users end though. We got it, nl and tr translations from virtualbox and they do have more (https://www.virtualbox.org/ticket/2018) we can use. It definitely doesn't cover everything either though, some languages aren't complete and I don't think it's tracking Qt closely in any way shape or form. The project you linked seems to be very incomplete at this point. I think if something like this is to succeed multiple projects have to get on board and ideally the Qt project would make it an official user driven thing. Ideally it would use a web platform like transifex. Maybe trying to get there is the route we will have to take. It would definitely cut down on future duplication of work if it panned out.

deekerman commented

2026-02-20 19:22:03 -05:00

Author

Owner

@mkrautz commented on GitHub (Nov 28, 2015):

How many strings do we really use from qtbase? Is it not mostly "Cancel", "Apply", "OK", "About Qt"?

Maybe the "solution" is to simply use the terms oursevles and mark them translatable...

...At least if the list of strings is not too big.

@mkrautz commented on GitHub (Nov 28, 2015): How many strings do we _really_ use from qtbase? Is it not mostly "Cancel", "Apply", "OK", "About Qt"? Maybe the "solution" is to simply use the terms oursevles and mark them translatable... ...At least if the list of strings is not too big.

deekerman commented

2026-02-20 19:22:03 -05:00

Author

Owner

@hacst commented on GitHub (Nov 28, 2015):

Will they get picked up if we simply trick Qt into adding them to our translation file? We should be able to collect the most important ones quite easily (stick out like a sore thumb in the UI). What I'm a bit concerned about is us picking up translations that do not match what the translations actually ought to be.

We should definitely annotate the strings to ensure the translators are aware of us translating standard ui components there (unfortunately while transifex does display those annotations as "developer notes" they aren't especially visible). Also those strings might actually be platform dependent...

@hacst commented on GitHub (Nov 28, 2015): Will they get picked up if we simply trick Qt into adding them to our translation file? We should be able to collect the most important ones quite easily (stick out like a sore thumb in the UI). What I'm a bit concerned about is us picking up translations that do not match what the translations actually ought to be. We should definitely annotate the strings to ensure the translators are aware of us translating standard ui components there (unfortunately while transifex does display those annotations as "developer notes" they aren't especially visible). Also those strings might actually be platform dependent...

deekerman commented

2026-02-20 19:22:03 -05:00

Author

Owner

@mkrautz commented on GitHub (Nov 29, 2015):

The easiest way to "trick" Qt is to simply use the strings ourselves: instead of using a system OK button, use a QButton tr("OK"), and so on.

I have not yet investigated how many strings we'd have to "trick" in this way.

@mkrautz commented on GitHub (Nov 29, 2015): The easiest way to "trick" Qt is to simply use the strings ourselves: instead of using a system OK button, use a QButton tr("OK"), and so on. I have not yet investigated how many strings we'd have to "trick" in this way.

deekerman commented

2026-02-20 19:22:03 -05:00

Author

Owner

@hacst commented on GitHub (Nov 29, 2015):

Not very fond of that idea. Ripping all the "native" stuff out of our UI will be quite fiddly and we'll have to recreate all the "for platform X button Y is left of button Z" craziness ourselves. Also I think we might loose some default wiring and configuration.

@hacst commented on GitHub (Nov 29, 2015): Not very fond of that idea. Ripping all the "native" stuff out of our UI will be quite fiddly and we'll have to recreate all the "for platform X button Y is left of button Z" craziness ourselves. Also I think we might loose some default wiring and configuration.