Was language resource update disabled in current version MuseScore?
Reported version
3.0
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
by design
Regression
Yes
Workaround
No
Project
Some Japanese users found several mistranslations in MuseScore 3.0.x.
I have the authority to modify the resources on Transifex, so I corrected it on Transifex about 7 days ago.
But they are not yet reflected to desktop app.
[Update] button for Japanese in [Languages] tab in [Resource Manager] still gray out.
Is this any trouble?
Or new specification for MuseScore 3?
In MuseScore 2, it was reflected immediately.
It was very usuful for correct and refine of translated contents.
Following thread by Shoichi may also related.
"Instrument index" https://musescore.org/en/node/286698
Comments
Translations have been switched to the next release, so there are only updates for the development builds currently
In reply to Translatuons have been… by Jojo-Schmitz
Please tell us more detail.
Does that mean that the mechanism to get the latest content from Transifex is dead?
No, but the translations are for the next release, those for 3.0.5 (or older) are frozen.
Using a development build, and you can get the updated translations
> No
???
> [Update] button for Japanese in [Languages] tab in [Resource Manager] still gray out.
This mecanism is not work, so I am asking.
It seems it is dead in Ver. 3.
In Ver. 2, it works.
In reply to No, but the translations are… by Jojo-Schmitz
The mechanism is a good one thought by the MuseScore development team before being acquired by UG.
The translation contents is "independent" from MuseScore build(release package) itself, so they could be updated, modify and refine at any time.
It is very useful.
We think it is necessary and esseicial.
If you(perhaps UG, not MuseScore dev. team) decide to make this good mechanism to kill, it is a "stupid" decision.
The mechanism hasn't changed in ages, not since the move to Transifex several years ago. Nothing to do with UG.
[Update] button for Japanese in [Languages] tab in [Resource Manager] still gray out.
This got to be a different issue then.
But even if it worked, you wouldn't get the latest translations, as those are frozen for 3.0.5 in preparation of 3.1.
In reply to [Update] button for Japanese… by Jojo-Schmitz
I can not understand the situation.
Is this a Japanese-specific problem?
Is it working in other languages?
I can't tell, my computer is out of reach.
So fa it is just you reporting this, can you update other languages?
Os is it simply telling you that you're up to date? If the latter, there is no issue, as explained the translations are frozen for 3.0 5
In reply to [Update] button for Japanese… by Jojo-Schmitz
> even if it worked, you wouldn't get the latest translations
Why?
In the past, that was possible.
Not after a string freeze, when switching translations to the next version, never.
In reply to Not after a string freeze,… by Jojo-Schmitz
In the past, there was no need to freeze it.
Is it that the specification has changed?
Thia happened every single time before a new release, ever since and since ages.
Only in the past, before 2.2, those updates were not as frequent as they are now.
No worries, your translations are not lost, they will show in 3.1 and do show already in the current development builds.
Does anyone know about this mechanism(feature)?
He(Jojo-Schmitz) seems to not know this.
Excuse me? I know the mechanism and just explaines it to you in great detail and repeatedly. The freeze has even been anounced on Transifex IIRC.
In reply to Excuse me? I know the… by Jojo-Schmitz
@Jojo,
> Excuse me?
I'm sorry.
In the past,
The translation contents is(was?) "independent" from MuseScore build(release package) itself.
The user could get the latest contents from Transifex by pressing [Update] button for any language in [Languages] tab in [Resource Manager].
If resources was changed on Transifex, user can get the latest contents immediately from Transifex by simply clicking [Update] button.
Do you know?
(EDIT: inserted the word "immediately")
Again: they never were after a switch to a new release.
In reply to Again: they never were after… by Jojo-Schmitz
> they never were after a switch to a new release.
Sorry, by my poor english ability, I can not understand you saying.
Please help me, lasconic.
You know about this feature.
Why is this mecanism(feature) dead?
from when?
In reply to Translatuons have been… by Jojo-Schmitz
> Translations have been switched to the next release, so there are only updates for the development builds currently
Ah, I see, I may be understand, finally.
Ver. 2.x.x : not works, anymore.
Ver. 2.3.2 : not works, anymore.
Ver. 3.0.0 - 3.0.4 : not works, anymore.
Ver. 3.0.5 : not works, anymore.
the development builds(Nightly builds) : it works.
Is this my understanding correct?
If so,
> Ver. 2.3.2 : not works, anymore.
> Ver. 3.0.5 : not works, anymore.
Why these?
These are the current latest version.
So I did not understand your saying.
I(perhaps almost users) can not imagine the reason
because it is very inconvenience and it is no need to freezing for these.
I think that You "should" keep it working at least in
the current latest version and
the latest version of Ver. 2 series.
The title has been changed by me.
This is language independent problem, not Japanese-Specific.
And the answer to that is yes.
Every release can update its translations up to the point where its translations got frozen to make room for the translations of the next version, typically a few weeks before the next release gets put out. In that "interims phase" you can test your new translations by using a current development build.
Clear as mud now?
In reply to And the answer to that is… by Jojo-Schmitz
I see, thanks. I could understand its explanation.
But I have the things that still could not understand a little.
Why need to freeze for current version to prepare next release?
I think that resource update feature can be keep working independently from development and release preparation of next release.
> typically a few weeks before the next release
I think that the almost users will feel it like "it is too long".
I can not understand need for freezing.
But If it is essential, I think it should be up to a few days.
There is only one active translation on Transifex.
And the translators need some time to do their work.
And currently we seem to be some 3 weeks vehind schedule, for the planned 3.1 beta.
The explanation of @Jojo-Schmitz is correct. We always had the strings up on transifex for one particular release. Most of the times this was the latest stable release. But when a new release was upcoming, we switched to the nightly/alpha/beta release and disabled translations for the latest stable release.
What @NOIKE is feeling is the consequence of a faster release cycle. Perhaps some tweaking can be done to the UI of the resource manager to be more explanatory so it reduces confusion.
In reply to The explanation of @Jojo… by Thomas
Why activated only one?
Why can not activated more than one at the same time?
I think this limitation is the root of the this issue.
Please tell us the reason for that limitation.
I can not understand that strange limitation from a engineer's point of view.
Is it just because the current implementation for resource update is such as?
It is strange situation that resource freezing for already released current stable version is required to prepare next release.
It is no need in essentially.
I think it is technically possible to support multiple branches.
@Thomas,
I feel that UI tweaking is just a workaround to avoid solving essential problem.
I think that improving the implementation for resource updating to support multiple branches is the essential problem solving for this strange situation.
Because there is only one Transifex and because we don't want translators wasting their time translating for old releases.
> Because there is only one Transifex
Even if there is only one Transifex, it is possible. I think that there is nothing difficult to do so in technically.
> because we don't want translators wasting their time translating for old releases.
That's not what I meant.
Ver. 2.3.2 : it works (just keep)
Ver. 3.0.5 : it works (just keep)
the development builds(Nightly builds) : it works. (just add)
It is just to keep it like above.
There is no need to stop and to focus on only one. It is possible and not hard to so.
Umm...
OK..., I give up to improve this "not good" development way(development style).
Perhaps, MuseScore development team just don't know how.
It is just because the current implementation is like that.
I guessed it from your statement "Because there is only one Transifex".
I can not be convinced, but I could understood the situation.
I gave up.
Jojo and Thomas, Thank you very much for the explanation of the situation.
We(Japanese users around me) waiting for next release.
The current localisation infrastructure is indeed not capable of supporting the translation of more than one version. To make this happen we would have to migrate to for instance Weblate and setup the hosting infrastructure ourselves which requires developer resources. So it's a trade-off to make. Is the ability of translating multiple versions of musescore worth it?
We might get away with just keeping the resources rather than switching before each release and not use the -noobsolete, so keep outdated strings (used in e.g. 3.0.5 but no longer in master).
> Is the ability of translating multiple versions of musescore worth it?
It is because the mistranslations remain and it is used continuously.
I feel that untranslation is not a problem, but mistranslation is a problem.
Also, there is an advantage that it can be corrected and refined continuously with the cooperation of general users not developper.
Additionary, the translation cycle(period) itself may not be necessary.
In Ver. 3.0.x, some mistranslations are found.
In these, there are serious mistranslations although not fatal.
And, the same mistranslation was found in Ver. 2.3.2.
As you know, every version of 3.0.0 to 3.0.5 has many bug and its works is unstable, so some users even avoid minor version upgrades.
Also, there are quite a few users who keep using Ver. 2, because the Ver. 3 is changed features dramatically and its works unstable.
Even if a new version 3.1.x is released, some(many?) users will not migrate to it at least as soon.
In thus situation, I thought that it is a not good situation that the translation content can not be updated except a particular release.
But, as I wrote in previous post, I gave up.
Thanks.
(EDIT: add "Additionary, the translation cycle(period) itself may not be necessary.")
There is not a single reason not to upgrade to 3.0.5, I'm not aware of any regresion vs. any previous 3.0.x version.
Wrong translations are an issue indeed, but the translators had some 5 months now to get them right for MuseScore 3
> There is not a single reason not to upgrade to 3.0.5, I'm not aware of any regresion vs. any previous 3.0.x version.
Yes, I know and believe so. So I always use the latest version.
But I do not know about others thinking so or not.
There are quite a few users who keep using Ver. 2.
I think that this situation is due to MuseScore development team's recent release style.
From 3.0.0 to 3.0.5, the release quality is low. There was many serious bug as crushing at startup.
So some users even avoid minor version upgrades.
> the translators had some 5 months now to get them right for MuseScore 3
That is not my works.
I just only corrected mistranslations of other's work, because I also have the authority to modify the resource on Transifex.
In essencially, the language resource is "independent" from MuseScore binary build.
Independent from the release schedule, I think it is natural and important to be able to correct, modify and refine it "anytime".
[Update] button in [Languages] tab in [Resource Manager] is for doing that.
In essencially, the translation cycle(period) itself is not necessary.
According to you and @Thomas explanation, it is not so in currently.
So I gave up to improve thus situation.
Thanks
Confirmation.
Please tell me.
After 3.1Beta released, which is the state of the language resource updater?
In my understanding, the state is "Status C".
"X" mark means "can not update".
"O" mark means "can update".
Current Status:
Ver. 2.3.2 : X
Ver. 3.0.5 : X
the development builds(MuseScoreNightly) : O
Status A:
Ver. 2.3.2 : O
Ver. 3.0.5 : O
Ver. 3.1Beta: O
the development builds(MuseScoreNightly) : O
Status B:
Ver. 2.3.2 : O
Ver. 3.0.5 : X
Ver. 3.1Beta: O
the development builds(MuseScoreNightly) : O
Status C:
Ver. 2.3.2 : X
Ver. 3.0.5 : X
Ver. 3.1Beta: O
the development builds(MuseScoreNightly) : O
Other:
Ver. 2.3.2 : (please write your own)
Ver. 3.0.5 : (please write your own)
Ver. 3.1Beta: (please write your own)
the development builds(MuseScoreNightly) : (please write your own)
We're in status C already.
But every version can update, to their lastet translation, the version just before the freeze and switch to next vesion. To verify: revert to factory settings, then try to update translations. It just won't match the current status of Transifex, for that you need a development build currently, which you can get from the download page
> We're in status C already.
Thanks.
I was able to confirm that I understand that situation correctly.
("Status C" is equivalent to "Current Status", but general users can not know the existence of 3.1Beta in current, so I described it.
I wanted to know if there are any changes of status after 3.1Beta was released.)
> To verify: revert to factory settings, then try to update translations. It just won't match the current status of Transifex
Yes, we are trying it already.
As a result, it was not match the current status of Transifex, so I made this issue.
The date I corrected some mistranslations is "Mar 21, 2019".
Perhaps, that day was already in the freezing period(in the translation cycle to prepare next release).
Our hope is that we are able to correct, modify and refine them in anytime, any released version.
However, there is the existance of a limitation in actually, and we learned it.
It is inconvenience and I can not be convinced, but I gave up improve the situation.
Instead, we will use the development build for that work during the translation cycle.
Thank you for your explanation, in patiently.
And, I apologize for the a little bad wording.