Dynamic Localization of Instrument Names
Current Behavior:
When a score is created, instrument names are written in the score according to the localization of the software instance in which the score was created in.
If the same score is opened in another software instance with a different localization, the instrument names displayed in the score according to the localization of the software instance in which the score was created in.
Desired Behavior:
When a score is created, instrument names are written in the score according to the localization of the software instance in which the score was created in.
If the same score is opened in another software instance with a different localization, the instrument name is transformed according to the localization of the software instance in which the score was created in.
This transformation can done using the proposed tag - https://musescore.org/en/node/296471
Comments
I disagree in principle. I put the program into Italian to get Italian names for my instruments in my score and I expect them to stay in Italian when I switch back to English. Your proposal would undermine this option and ruin years worth of scores. I do this with other languages as well, but Italian is an example.
If your proposal does not ruin this, then I would have no problem with it. It might would be useful in the correct situation. For example, I don't have a Cyrillic keyboard (which means I can't type a name in my translator) so I sometimes have difficulty reading Russian scores' instruments I'm not familiar with.
In reply to I disagree in principle. I… by mike320
Let me walk through the use case, which might help clarify.
A user in Tokyo creates a new piece for Concert Band using the Japanese localization of the Musescore software. All instrument names are written in Japanese.
He posts this score to Musescore.com.
A user in Texas sees his score, downloads it, and opens it in the Musescore software. When he opens the file, rather than instrument names in the score being written in Japanese, they will be transformed to English as he has opened the score in the US English localized version of the Musescore software.
Regardless of what localization the files were originally created in, they are always transformed to the localization of the user, making scores far more useable on a local level.
In addition, this solution could enable the ability to dynamically generate localized versions of scores for localized versions of Musescore.com and the Musescore mobile app.
In reply to Let me walk through the use… by Daniel
Due to the different lengths of the instrument names in different languages this will screw up the layout
In reply to Due to the different lengths… by Jojo-Schmitz
This challenge can be addressed with improved templates and improved algorithmic layout.
Also, this is an issue strictly confined to positioning of notation elements on paper, rather than devices.
While paper is currently a primary use case, I believe this will begin to sharply decline over next 2-3 years.
Digital creation for digital consumption is where the world is headed.
In reply to This challenge can be… by Daniel
I don't see how templates would help.
And I very much doubt paper scores would die out anytime soon, in my choir I'm still the only one using a tablet, 9 years and...
And even there I use PDFs
In reply to I don't see how templates… by Jojo-Schmitz
Yet everyone has a mobile phone.
Once there is a tipping point on how to create a compelling mobile experience that is much better than paper for reading music notation, there will be a shift.
We are there on device distribution.
We are there on device capability.
We are there on network availability.
We are not quite there on user experience and workflows.
In reply to Yet everyone has a mobile… by Daniel
Not even that, there are at least 2 choir members without mobile phone.
In reply to This challenge can be… by Daniel
As a user of those digital devices, I don't fully agree on the layout changes relevant to this.
Having page turns (even digital ones) at the correct place is very important.
I get where the question comes from; but also be aware that often instrument names are customized (for example for band scores, the name of the singer or "backing vocal 1/2" instead of "voice". Those aren't quite meant to become "translated" in any case.
In reply to As a user of those digital… by jeetee
If the concept of page goes away, there are no page turns.
Check out Practice Mode in the Musescore mobile app.
The point is that regardless of the name that was entered into the text of the instrument name, it should be reverted/reset to default in the localized version if opening the score in another instance of the software.
In reply to If the concept of page goes… by Daniel
While practice mode can be "usable" for practicing; I know I'll never be using it as the continuous scrolling makes reading a score and occasionally looking away to your fingers a concentration hell.
Aside from that, no live performance for an orchestra (unless on a click-track) has use for such a mode.
Seeing a part of a score (whether or not you wish to call it a "page" or not) on which you're able to read ahead and decide for yourself when the next part should appear isn't going away. And in those cases a "page/window" optimized layout (including sensible page turns) is essential.
I could get automatic translation for non-customized instrument names; but stating a customized instrument name must revert is simply a no go. Offering a command/option for the one opening it to show it in their language/default is fine.
But priding yourself and your goals as MuseScore into (aspiring to be/) being a top-notch notation editor and then removing one of the layout tools is not done. If you plan on reverting instrument names into default names every time someone opens a score (so also their own scores) renders to option to change those instrument names (both long and short) useless.
Again I have no objection to offer localisation, but it has to be a conscious decision for the user that has opened/loaded the score (be it in the desktop software or mobile) and not a forced on default.
In reply to While practice mode can be … by jeetee
Device synchronization or "Ensemble Mode" is a next important step.
Something to consider...
The actual Musescore user base is VERY young - 67% under the age of 24. These are digital natives that do not interact the same way others do, and have different habits, and expectations.
As Musescore continues to grow, I see this age bracket also growing even more.
These demographics and the sheer scale of users are dramatically different than other software vendors on the market and could guide Musescore down a very different path than others.
In reply to Device synchronization or … by Daniel
Again, I'm not against catering to the young and new users. MuseScore being free is a major advantage and selling point (pun intended). Making it usable is adamant for that first adoption.
However, the 2nd selling point (at least to me back then) is the ever ongoing effort to make it the best typesetting program there is. Part of that imo is the opportunity to lock down a layout for a given purpose. Behaving and displaying something as the composer/transcriber intends it should never be considered a bad thing. It's on par with a user wanting to ignore that layout and viewing the score as (s)he wishes to consume it.
Both scenarios are valid, and while I get finding a middle ground for some features, I don't get crippling an existing and actively used feature for it.
I'm also curious into how the user base statistics are built. Looking around my environment I see indeed a large group of students and 20somethings using MuseScore. But I see an almost equally large group of 60+ musicians transcribing (either for themselves or their choirs) and digitizing huge collections of composers.
Of course the young group will become the bigger user group in time (or at least influx of it); people age and the older you get, the higher the chance you'll die of natural causes. This is not specific to MuseScore at all, it's simply nature and life.
Again, I agree that there is a use for this feature, and likely more so on the mobile players/rehearsal apps than on the desktop notation software. But I can't agree with crippling an existing and useful feature for it instead.
In reply to Again, I'm not against… by jeetee
100% agree
In reply to 100% agree by Jojo-Schmitz
Here here!
In reply to Again, I'm not against… by jeetee
I guess my main point is that I think that unless this is their profession or passion, humans are generally bad at engraving. There is quite a lot of knowledge required in order to do this correctly.
As a result, more and more tasks of engraving should be delegated to the software, and less to the user.
I consider it like this...
Most modern airplanes are flown almost entirely by automated systems. They can be flown manually if needed, but that is the exceptional use case.
With regards to engraving, I believe notation software should be the same. Composers should be able to just compose and have the result not only be as correct as possible with very little need for decision making on the part of the user, but should also be adaptive to the various form factors and formats it may be published to.
Further, what makes Musescore truly unique is that it is paired with an ecosystem in which files are shared and "remixed" for lack of a better word. The functionality of the software should support the unique capabilities afforded by this ecosystem and the very different use cases that result.
This is the root for the need for localization to be described in the headers and the ability to override and replace with user's own localization if they deem this appropriate to their needs and workflow.
In reply to I guess my main point is… by Daniel
Transcribers have different needs though, it is about reproducing existing scores and their layout.
Composers get a good layout by default already.
In reply to Transcribers have different… by Jojo-Schmitz
I ask the question again.... why?
If the original publisher wrote it very poorly, why recreate a poor edition? :)
In reply to I ask the question again… by Daniel
Because it is very unlikely that the original publisher/layouter did a bad job.
Because the conductor may work on the original, the ensemble members from.the MuseScore version, same system and page breaks needed.
Because MuseScore creating bad layout will contribute to publishers to create bad layout. Some bad layout out there is caused by Finale and Sibelius shortcomings
In reply to I ask the question again… by Daniel
Some people (me and many others) want to reproduce historically accurate scores. Taking away this ability is no improvement to the program but imposing your standards on the world.
In reply to I guess my main point is… by Daniel
Your analogy (though it falls apart quickly, as analogies so often do) nicely allows me to demonstrate the part of the proposal I'm contending.
Most modern airplanes are flown almost entirely by automated systems. They can be flown manually if needed, but that is the exceptional use case.
Exactly, but when a pilot overrides the automatic system (in our analogy, changes the default instrument names shown) it is an absolute no go for the automated plane systems to ignore that override!
So I indeed would vote for this auto-translating to be a preference where default names are affected when enabled. And as proposed elsewhere in the thread I could see value in a command forcing translation (again with an option to include non-default instrument names). For the command, I also see value in "any language", but default to user language.
It could give mike his Italian names using that command, without the need to change translation of the full software package.
Note that one of the scenarios to use custom instrument names is to define new/currently not supported instruments. In this scenario, it again makes no sense whatsoever to "translate" the name as it would result in the incorrect instrument name being shown.
Further, what makes Musescore truly unique is that it is paired with an ecosystem in which files are shared and "remixed" for lack of a better word.
I agree that this is an added value; though I myself don't use the online sharing platform that much. I also agree that the software should support the unique use cases this enables (not only of yours, but other digital ecosystems as well); but I also find that this shouldn't come at the cost and loss of functionality for the part of the userbase that doesn't use that ecosystem.
In reply to Let me walk through the use… by Daniel
You did not address my main concern. I use Italian settings to make Italian instrument names in my scores and I don't want MuseScore to go behind my back and change them when I change back to my native Texan. If it does this, then localization is a deal breaker in my opinion.
In reply to You did not address my main… by mike320
Musescore would not change these settings for YOU, but if you send this score to me... it would make these changes for ME. You can use your localized or custom names, but I could reset them in my instance to my default localized names.
This is about dynamic interpretation and presentation of scores that are published digitally.
In reply to Musescore would not change… by Daniel
It is better to have a menu option that will do this.
Thus, the user can use this command to translate into their local language.
If no action is taken, the original version of the work will be preserved.
In reply to It is better to have a menu… by Ziya Mete Demircan
Yes, an option to translate instrument names is OK. Not sure whether a score option, or a preference setting, if the former it needs to be off by default.
In reply to Yes, an option to translate… by Jojo-Schmitz
And why just to local language? I might want to translate into German, French, Italian, Russian, US English.