"... lame ..." -> "... LAME ...", "Midi ..." -> "MIDI ..." and "Omr Panel"-> "OMR ...", as they are acronyms
Same for FLAC, PNG, SVG, SFZ. Opposite for Ogg
consider this done
And feel free to find and report more ;-)
Another issue is inconsistent use of an upper/lower case letter at the start of certain strings.
Yet another are string with CamelCase spelling, some may not need to get translated at all, others may need to get down-shifted in the middle, and some may need a space added
Very hard to tell them apart.
E.g. "BarLine", "NumOfFrets", "TextLine", "TopStaff", BottomStaff"
For the CamelCase strings, most of them are in the elementNames array. They need to stay in the code and not be modified. They are used, untranslated of course, to save elements in the MSCX files.
The translated version is only used as a separator in the context menu.
For the translation, we can
1/ use another array of user names, with space and not CamelCase. It's a pain, it will need to be sync with this array.
2/ Increase this array to store a struct ( name, username)
3/ Add a comment to let translators know they can translate these strings without CamelCase. The en locale will have a ugly
I would favor 2/. Any opinion?
NumOfStrings is not one of these and can be fixed independently.
It's also always bugged me that Chordname was plural in Style / General, but singular in Style / Text. I guess that's consistent with most other items in General and Text, but chordnames may have been the only elements to appear in both?
Note that Style / Chordnames is probably going away as a menu item - the window it brought up will probably be accessed by a button within Style / General / Chord symbol(s), which should probably be labeled something like "Edit...".
Marc: could you locate and 'translate' this (and possibly others) in the US-English translation on Transifex?
I'll grab them there and merge them into a PR
Lasocnic: OK, I'll change all "chordname" and "chord name" into "chord symbol" (already done in the 'translation)
I'm happy to do whatever makes sense for me to do. But I've never used Transifex and have stayed out of all that, so there will be presumably be a pretty big learning curve. Maybe it would be better for someone who already has all that workflow going to do whatever it is you are asking me to do (just understanding the question would be part of my learning curve :-)
But if it does make sense for me to do this, if someone can explain better what I need to do, I'll get on it.
It's pretty easy to use, no worries. But if you prefer not to, that's fine too. If you can just tell which strings should get changed and into what, I guess I can manage...
I think getting to the point where I understand the system well enough to be able to tell you what strings need to be changed probably covers 80% of the learning curve. Right now I don't know where the list of strings even is. So once I get that far, I might as well just do the job.
I successfully created an account. Not sure what to do next. I tried clicking the English link on the MuseScore page, then the Join Team button on that page. This asked for confirmation, I said yes, and I got a "bad link" error.
Thanks. I thought it was the source we were changing. Just to be clear, then: we're leaving the source alone, errors and all, and providing English US translations of strings that should be different from what they are in the source?
I am now in a window in my browser that lists thousands of strings on the left and has two subwindows on the right. I typed "chordname" into the search box and now it shows only strings containing that term. Doesn't give me any context that I can see to understand where this string is used - or is there a way to get that? Anyhow, I see what you reported - you've already done this. Same if I type "chord name" into the search box.
So I'm still not quite sure I understand what you're asking me to do?
The soure is what gets change via a pull request in github.
Your concern was about plural vs. singular, right?
There is some context, but by far not as much as one would wish for... but this isn't any different from the old translation server (hidden under 'more detail'), it is just than what Qt calls context is different from what mere mortals understand it to be :-)
If you select "all unreviewed" you see what I'll put into the next pull request. Once that got merged, these strings disappear from transifex, so a good way to check whether something got forgotten.
You can also leave comments and propose alternatives.
Ah, you were specifically commenting on my singular/plural observation? I hadn't understood that at first - I thought maybe you were talking about the dialog that may be moving, or something more general.
As for context - I wasn't seeing that at first either, but finally found it under "More details". It's semi-useful to me - seems to refer to the actual object names as defined in QtCreator and/or used in the source.
Unfortunately, that's still not helping in this case. I think I am seeing entry 225 is "Chordnames" from Style / General, but I can't find the entry corresponding to "Chordname" in Style / Text.
I'm also not sure what the right answer is here. Most of the general style labels are plural (with several exceptions), most of the text labels are singular (with a couple of exceptions). So the discrepancy between Style / General / Chord Symbols versus Style / Text / Chord Symbol makes sense when looked at that way. Seems there could be some sort of guideline to follow here, but I would also agree that somehow, some of the styles make intuitive sense to list as singular (eg, Page) while others make sense to list as plural (eg, Accidentals). So if there are to be some sort of naming convention guidelines, they probably need to be flexible.
While I do care about details like this, I think I don't care enough to undertake proposing a full set of naming convention guidelines if they don't exist already. There are probably lots of other similar little nits that could be picked and maybe should be some day, but probably by someone who makes it a priority to really clean this up program-wide.
"Chordname" is string #2678, "Chord name" is #650, #1723, #2678. And I can't tell from context which is which ;-(
But yes, some kind of guidelines are needed for consistency with regards to singular/plural and uppercase/lowercase (and maybe CamelCase).
After all this is the basis for getting correct and consistent translations, esp. in the light of the rather poor context, where the main thing you can really lean on is the original string, even it that seems pretty nit-picky at first glance.
@lasconic: I guess I'd need help on getting that elementName array (and probably some others too) converted into a struct, to resolve many of the CamelCase issues
I said it to Jojo privately, so I will tell it again here. I think it's bad idea to use the en_US translation on transifex to report 'bad' strings in the code. @Jojo if you want to use it your own notekeeping, it's all fine but I would not require anyone else, especially people with git knowledge to use Transifex.
If context is not good enough, it can be changed in the code. If you have Git knowledge, go ahead, add more information. UI files have a special field for translator comments. In the code, Qt provides translation comments and disambiguation http://qt-project.org/doc/qt-5.0/qtdoc/i18n-source-translation.html#tra…
Quite a bunch fixed now, but there are still some issues left.
"InstrumentLong", "InstrumentShort", "InstrumentExcerpt", as per lasconic should not get changed in the source, as used verbatim in XML, so may need to get placed in a struct, similar to the elementName Array
A lot of strings in libmscore/sym.cpp SymbolNames Array.
Still a few (some 10) "chord name" ->"chord symbol" left, as well as one "Fret Diagram" -> "Fretboard Diagram"
One palette is called 'Articulations' while the counterpart in the master palette is called "Articulations & Ornaments", I think they should be named the same.
Same issue for 'Frames' vs. 'Frames & Measures'
And the workspace files 'basic' and 'advanced' on GitHub need to get updated to match the latest strings from the source files
Most issues fixed now, but there are still a few issues left.
"InstrumentLong", "InstrumentShort", "InstrumentExcerpt", as per lasconic should not get changed in the source, as used verbatim in XML, so may need to get placed in a struct, similar to the elementName Array
A lot of strings in libmscore/sym.cpp SymbolNames Array, may also need a a struct?
As far as I know "Excerpt" is not used in the UI. It's used only in the code to describe what the UI calls a Part (like in File -> Part, not like in dynamic range -> part). So I guess "Instrument Excerpt" could be "Instrument name in part"? it appears close at the top of each part.
Same for InstrumentsLong/InstrumentsShort. They both refer to the instrument name in front of the staff. These names are refered as "Long instrument name" and "Short instrument name" in the staff properties dialog.
Seems all problems are solved now, with the latest commit.
...
Hah, found some more:
What about some of the terms with context "articulation", like 'verylongfermata', shouldn't those be proper words like "very long fermata"?
more examples: upbow, downmordent
Now that Chordname has been changed to Chord Symbol throughout, 1.3 scores that set the Chordname text style no longer work properly. Either we need to keep Chordname as the internal style name or else we need to add code in read114.cpp to translate. I guess similar issues might exist for other renamed styles?
Are the changes in 3dfacd1 the culprit?
I think it is...
If so, in addition to "Chordname" the settings for "Lyrics odd lines", "Lyrics even lines", "InstrumentsLong", "InstrumentsShort", "InstrumentsExcerpt", "Technik", "Tuplets" and "TextLine" should be affected too.
Yes, that seems to be it. I'm just not sure what the best strategy is here - revert to the old style names internally for use in the actual score file, or make the conversion from old to new in read114. Presumably an easy enough fix either way, but it seems like a policy decision that lasconic or Werner should make.
My vote, FWIW, is to keep the new text style names and do the conversion in read114. There's a spot at line 330 where the old "Poet" is changed to "Lyricist", this is where we'd hook in for further conversions.
Having an extra parameter to the TextStyles() method, e.g. _prettyname, taking the new TR() stuff and the existing _name taking the old style names, maybe?
Just reverting would make it look ugly in US English, while it can get translated nicely into any other language.
Hmm, as there seem to be some conversion already, that seems the right spot for more IMHO.
Code starts here: https://github.com/musescore/MuseScore/blob/master/libmscore/read114.cp…
Still some unresolved issues, mentioned in #37
:
What about some of the terms with context "articulation", like 'verylongfermata', shouldn't those be proper words like "very long fermata"? More examples: upbow, downmordent
And some more: I'm not sure (anymore) whether it is a good idea to have the directory names (for scores, images, templates. etc. in the preferences) translated. Might cause strange issues when switching between languages?
Translating the directory names should be fine. These directories will be created with the name translated in the system language on first run. Then these directory names will be saved in the preferences and so the other translations should not be used even if the user changes the language.
Does it make sense?
Problem is that on 1st start MuseScore uses the system language, while that is a good default, there are users that want a different language, but now are left with the system language directory names. Could possibly get solved by a dialog at install time, or at 1st start, asking for the preferred language (and possibly also for the preferred paper format and maybe some other settings)? Not really the scope of this issue though, should I submit an extra one for this?
But what about the issues from #44, verylongfermata and friends
@Magnus: the ones you quote me on (the CamelCase ones) are fixed since quite a while.
And not by translating them, that actually broke things in .mscx files, a code change was needed to make them part of a struct.
And with 'hard to tell apart' I meant the ones that should or should not start with a capital letter, where without knowing much more about their context than the translations provide it is hard to make the decision.
Other than that my rule for dealing with upper/lower case was simply to use uppercase for all nouns (as that's the rule in German) Have the first letter follow the original string and have the first letter of every word follow the original text too, i.e. hav it upper case if the original had it uppercase and lowercase if the original had it that way. So only difference (in case) is the German spelling of nouns.
"plus stop" seems to have a double meaning, 'stopped' for brass and 'pizzicato left hand' for strings. Should we mention this in the original string or only in the translations, or not at all?
"Top Staff" and "Bottom Staff" in the contexts "ArticulationProperties", "InspectorArticulation" and "Ms\:\:EditStyle" seem to really mean "Above Staff" and "Below Staff" or "Top Of Staff" and "Bottom Of Staff" respectively. Which makes the choice of the names in enum ArticulationAnchor (libmscore/articulation.h) being somewhat confusing...
With the 3rd option in those dialogs, "Chord", apparently meaning "Auto Chord" i.e. depend on chord direction, away from stem, which begs the the question why there is no "Above Chord" or "Below Chord"?
Or am I misunderstanding these dialogs altogether?
I believe you are correct about top / bottom really being above / below and should be fixed in the original. As for Chord, my impression is that this setting causes the default position of the articulation to depend on the chord it is being attached to. So it appears above or below the staff according to stem direction - they attach to the notehead side of the chord. So below if stem up, above if stem down. And they seem to be allowed to cross into the staff, such as when attached to a single note on the middle line.
I think there should also be corresponding stem side setting option, although I guess it probably wouldn't be used anywhere by default.
EDIT: oops, missed your edit, I see you already figured out the stem direction thing.
If you right click a chord symbol, the popup menu is labeled "Harmony". That should probably be renamed "Chord Symbol".
I guess there may be a few other places where the term "Harmony" is used, and if so, they should be renamed as well. Note that I'm about to remove the old Harmony Properties dialog. I see the dialog had already been renamed, but I wouldn't be surprised if there still some strings associated with it that hadn't been updated.
BTW, I'm removing all the code associated with this dialog. Not sure if I should delete the files themselves or if we keep them for source history purposes. And either way, if there is anything special I would need to do to make sure the list of strings to be translated gets updated to no longer includes strings associated with that dialog.
Yep, there's indeed one "Harmony" left, in libmscore/element.cpp. This should be the one and only though, unless there are some that are not marked for translation. The term is used all over the place, that's probably why I missed the tree in the forrest ;-), but as mentioned, none of them shows up on transifex. So if they show up in MuseScore, we're looking at a different problem: strings not marked for translation.
The translatable string from libmscore/style.cpp show up on Transifex, bit don't show translated in MuseScore's Text Style dialog or Inspector's pupup menu for Text Styles, both show the original untranslated values. Probably taken 'as is' from the active score?
I personally have a preference for the single word in *all* of these cases, including "notehead". Certainly for "handbook", which is an ordinary English word. Looking around, it does seem "drum set", "bar line", "note head" are more commonly used as two words in the literature, but Elaine Gould uses "barline" and "notehead" and that's good enough for me. Gould also uses "drumkit" rather than "drumset", but same difference as far as I am concerned.
Hold on: you wanted to get 'note head" changed to "notehead" and not the other way round? So the exact opposite of my PR?
There are 6 of those (plus the 2 I just changed)
However, it seems the tables of capitalization rules are missing from this document. So I am not sure what the rules to follow are. But it does seem the majority of current strings for capitalize the first word only (eg, field labels within dialogs), where Title Capitalization is used for menu items, button labels, and titles of dialog boxes, tabs, and panes. So I'll use that as my baseline. There are a few element types that occur only in one specific context and I'm not going to worry about those (eg, the articulation names and Anchor buttons in Style / General / Articulations). There does seem to be a trend in some dialogs to not capitalizing labels for radio buttons at all, but I think this is probably a mistake.
Here are some strings I see out of character with what I take the rules to be. I am listing them by dialog because it's not always apparent to me where the source string actually is (sometimes it's in the ui file but otherwise set explicitly in a cpp file), also so people can see the context to decide if I'm right or wrong about any of these.
Warning: there are a *lot* of these. Most are field labels currently in Title Case that should be First word only. Also, I intended these to be grouped by dialog witht he actual strings indented underneath the dialog names. But the indenting doesn't show. Just realize, the first line of each group is the dialog name, and these are correct.
Style / General:
Capo Fret Position
semitones offset
cents offset
Style / Text:
size follows Space unit [ here, keeping Space capitalized probably makes sense ]
Style / Staff Type:
Show Clef
Show Time Sign. [ and this should not be abbreviated ]
Show Barlines
Ledger Lines
Key Signature
On Lines
Above Lines
Note Symbols
Vert. Offset [ probably don't abbreviate this either ]
Layout / Page Settings:
Two Sided
First page no. [ abbreviation ]
Notes / Tuplets / Other:
number
relation
nothing
auto bracket
bracket
nothing
Notes / Transpose:
By Key
By Interval
Transpose Diatonically
View / Synthesizer:
Master Tuning
Edit / Preferences:
start empty
continue last session
start with new score
start with score
show splash screen
Scores Directory
Styles Directory
Templates Directory
Plugins Directory
Soundfonts Folders
SFZ Files Folders
Images Directory
[ Show Play Panel et al I think are OK, since those are names of windows ]
Default Duration
MIDI Remote Control
[ all of the the individual buttons underneat that - I'm getting lazy ]
Instrument List1
Instrument List2
Style for Part
Character set used when importing binary files [ should be Title Case ]
Shortest Note
Sample Rate
File / Parts:
Part Title
File / Info:
[ not sure about this; these may reference to case-sensitive metadata fields ]
File / Album:
Album Name
Inspector / Time Signature:
Show Courtesy
Inspector / Clef:
Show Courtesy
Inspector / Key Signature:
Show Courtesy
Show Naturals
Inspector / Tempo Marking
Follow Text
Inspector / Line:
Allow Diagonal
Line Color
Line Width
Line Style
Inspector Slur/Tie:
Line Type
Inspector / Articulation:
Time Stretch
Inspector / Ottava:
numbers only
Inspector / Marker:
Marker Type
Miscellaneous properties and other dialogs:
Style / Staff Types:
Part Name
Long Instrument Name
Short Instrument Name
Play Transposition
Edit string data
Select Instrument (from Staff Properties / Change Instrument):
Current Instrument
Time Signature Properties:
Global Value
Actual Value
I take it you are referring to Transifex? I thought the point of this issue was that we should fix the sources themselves?
I'm not too familiar with Transifex, and couldn't figure out how to get a list of recent changes. Asking for a list of updates after 1/10 came up blank, but I can see there were changes, so obviously I'm not getting something.
Yes and no, just download the latest translation for en_US via MuseScore's resource manager (menu -> Help -> Resource Manager), restart MuseScore for the updates to take effect, then revisit all the menus to check.
Once I get the OK, I'll change it in the sources and submit a PR
You get the changes by looking at all non-reviewed itmes: https://www.transifex.com/projects/p/musescore/viewstrings/#en_US/muses…
Once the PR got merged, these will automagically disappear
Ah, that makes sense, thanks. And thanks for taking on all this work! I know it's not glamorous, but obviously it does matter to some of us.
BTW, in the process of firing up the Resource Manager, I found another right in the main menu: "Help / Report a bug". Also, just noticed yet another: "Notes / Respell pitches".
No doubt I've missed others - especially in the context-specific items like Properties dialogs and the Inspector, some of which I probably failed to visit in my search the other day.
On checking your work, it looks great overall. I'm surprised at how much of a difference it makes to see these fixed. But you did miss a couple, and I found a couple I missed the first time :-).
In the following, lines beginning with ":" are ones from my original list that seem to have been missed (wondering if maybe same strings were changed in another context?). Lines beginning with "+" are new ones I've found.
Style / Staff Types
+ Line Distance
Notes / Tuplets / Other
: bracket
: auto bracket
Notes / Transpose
+ Transpose Chromatically
Edit / Preferences
+ Draw Antialiased
+ JACK Audio Server [ unless that really is the name of the program? ]
Inspector / Key Signatures
: Show Natural [ capitalization but also pluralization - should be "Show naturals" ]
Staff Properties
+ Up
+ Down
Line Properties:
+ x
+ y
There are three more I'm hedging on. In Staff Properties, there is "+octave". I suppose that could be left lower case because the label doesn't technically *begin* with the word "octave". But it would look odd next to "Up" and "Down" once those are fixed. On similar principle, Style / Text Style, "% horizontal" and "% vertical" should probably be capitalized too.
Reg. "+octave", "% horizontal": how about "+ Octave:" and "Horizontal %:" (both were lacking a : too)? This and your proposals from #66 and #67 plus a couple more are in the translations now, I made it "Top/Left", etc.
Is it "multi measure", "multi-measure" or "multimeasure"?
Edit / Preferences / Shortcuts, hit Define; this brings up "Enter shortcut sequence" dialog, title should be capitalized. Also, the exclamation point in "Press up to 4 keys to enter shortcut sequence" seems gratuitous, and "4" should probably be spelled out (not sure).
1. Open attached score (produced in 1.3).
2. Right-click the (system) text.
Expected result: The menu name is 'System Text', whilst a menu item and its window title say 'System Text Properties…'.
Actual result: They say 'Stave Text' and 'Stave Text Properties…' respectfully.
Using MuseScore 2.0 Nightly Build (d65c722) - Mac 10.7.5.
For the record, system text is actually the same as staff text internally - the only difference is the text style applied. So it may be unavoidable - or harder to avoid than is worthwhile, anyhow - to have the same menu & dialog titles for both. Not saying this doesn't have the potential to be confusing and couldn't be worth looking at, but it's not just a matter of fixing a spelling somewhere.
Similar issues arise with other element types that are actually subtypes of other elements. For example, an "ottava" is a special case of "line" and hence its context menu & dialog refer to the latter, etc. But in most of those cases, the hierarchy is probably clearer.
If there isn't a separate dialog for systems and start text, this would be out of the scope if this issue and getting that fixed would requite a separate one. Esp. As this one here is way to long already, so I'm inclined to mark it fixed again, agreed?
$ grep -i "system text" */* 2>nul
mscore/actions.cpp: QT_TRANSLATE_NOOP("action","System Text"),
mscore/actions.cpp: QT_TRANSLATE_NOOP("action","Add system text")
mscore/exportly.cpp: -- become clear on the difference between system text and staff
mscore/menus.cpp: sp->append(st, tr("System Text"));
This confirms that there is no separate properties for System- and Staff text, hence nothing in the translation (or rather pre-translation) to correct. Please open a new issue for getting the separation.
Here's a little tip (if you don't know) if you wanted to edit the issue: For the Git commit, go to 'About MuseScore' and click on the 'Copy to clipboard' button and replace what exists in the brackets.
Comments
I would add to this report:
"Switch one ore more voices to a specified channel"
inside mscore\stafftext.ui
Ciao,
ABL
consider this done
And feel free to find and report more ;-)
Another issue is inconsistent use of an upper/lower case letter at the start of certain strings.
Yet another are string with CamelCase spelling, some may not need to get translated at all, others may need to get down-shifted in the middle, and some may need a space added
Very hard to tell them apart.
E.g. "BarLine", "NumOfFrets", "TextLine", "TopStaff", BottomStaff"
What about 'Chord name' vs.' harmony'?
And "...timesig" vs. "...time sig."?
Harmony should not appear in the UI if possible.
Timesig and time sig. are equally wrong. It should be Time signature.
Fixed in 4743f20081
PR: https://github.com/musescore/MuseScore/pull/523
Probably more to follow, but Need some questions answered first...
Fixes for Harmony and timesig to follow in the next batch then...
What about "(F.B./Harm.)", leave as is?
What about all those CamelCase strings?
For the CamelCase strings, most of them are in the elementNames array. They need to stay in the code and not be modified. They are used, untranslated of course, to save elements in the MSCX files.
The translated version is only used as a separator in the context menu.
For the translation, we can
1/ use another array of user names, with space and not CamelCase. It's a pain, it will need to be sync with this array.
2/ Increase this array to store a struct ( name, username)
3/ Add a comment to let translators know they can translate these strings without CamelCase. The en locale will have a ugly
I would favor 2/. Any opinion?
NumOfStrings is not one of these and can be fixed independently.
2/ Sound good to me
PR https://github.com/musescore/MuseScore/pull/525
Fixes NumOfFrets, timesig and Harmony.
Fixed in 0712881919
Reopen to sort out the other issues.
Also "Chord name" should be change to "Chord symbol"
It's also always bugged me that Chordname was plural in Style / General, but singular in Style / Text. I guess that's consistent with most other items in General and Text, but chordnames may have been the only elements to appear in both?
Note that Style / Chordnames is probably going away as a menu item - the window it brought up will probably be accessed by a button within Style / General / Chord symbol(s), which should probably be labeled something like "Edit...".
Marc: could you locate and 'translate' this (and possibly others) in the US-English translation on Transifex?
I'll grab them there and merge them into a PR
Lasocnic: OK, I'll change all "chordname" and "chord name" into "chord symbol" (already done in the 'translation)
I'm happy to do whatever makes sense for me to do. But I've never used Transifex and have stayed out of all that, so there will be presumably be a pretty big learning curve. Maybe it would be better for someone who already has all that workflow going to do whatever it is you are asking me to do (just understanding the question would be part of my learning curve :-)
But if it does make sense for me to do this, if someone can explain better what I need to do, I'll get on it.
It's pretty easy to use, no worries. But if you prefer not to, that's fine too. If you can just tell which strings should get changed and into what, I guess I can manage...
I think getting to the point where I understand the system well enough to be able to tell you what strings need to be changed probably covers 80% of the learning curve. Right now I don't know where the list of strings even is. So once I get that far, I might as well just do the job.
(anyone wanting to help via IRC, give me a buzz)
I successfully created an account. Not sure what to do next. I tried clicking the English link on the MuseScore page, then the Join Team button on that page. This asked for confirmation, I said yes, and I got a "bad link" error.
Go down to the "English (US)" translation, you can't translate the source language (and the ability to selectd that, is a bug on Transifex IMHO)
Thanks. I thought it was the source we were changing. Just to be clear, then: we're leaving the source alone, errors and all, and providing English US translations of strings that should be different from what they are in the source?
I am now in a window in my browser that lists thousands of strings on the left and has two subwindows on the right. I typed "chordname" into the search box and now it shows only strings containing that term. Doesn't give me any context that I can see to understand where this string is used - or is there a way to get that? Anyhow, I see what you reported - you've already done this. Same if I type "chord name" into the search box.
So I'm still not quite sure I understand what you're asking me to do?
The soure is what gets change via a pull request in github.
Your concern was about plural vs. singular, right?
There is some context, but by far not as much as one would wish for... but this isn't any different from the old translation server (hidden under 'more detail'), it is just than what Qt calls context is different from what mere mortals understand it to be :-)
If you select "all unreviewed" you see what I'll put into the next pull request. Once that got merged, these strings disappear from transifex, so a good way to check whether something got forgotten.
You can also leave comments and propose alternatives.
Ah, you were specifically commenting on my singular/plural observation? I hadn't understood that at first - I thought maybe you were talking about the dialog that may be moving, or something more general.
As for context - I wasn't seeing that at first either, but finally found it under "More details". It's semi-useful to me - seems to refer to the actual object names as defined in QtCreator and/or used in the source.
Unfortunately, that's still not helping in this case. I think I am seeing entry 225 is "Chordnames" from Style / General, but I can't find the entry corresponding to "Chordname" in Style / Text.
I'm also not sure what the right answer is here. Most of the general style labels are plural (with several exceptions), most of the text labels are singular (with a couple of exceptions). So the discrepancy between Style / General / Chord Symbols versus Style / Text / Chord Symbol makes sense when looked at that way. Seems there could be some sort of guideline to follow here, but I would also agree that somehow, some of the styles make intuitive sense to list as singular (eg, Page) while others make sense to list as plural (eg, Accidentals). So if there are to be some sort of naming convention guidelines, they probably need to be flexible.
While I do care about details like this, I think I don't care enough to undertake proposing a full set of naming convention guidelines if they don't exist already. There are probably lots of other similar little nits that could be picked and maybe should be some day, but probably by someone who makes it a priority to really clean this up program-wide.
"Chordname" is string #2678, "Chord name" is #650, #1723, #2678. And I can't tell from context which is which ;-(
But yes, some kind of guidelines are needed for consistency with regards to singular/plural and uppercase/lowercase (and maybe CamelCase).
After all this is the basis for getting correct and consistent translations, esp. in the light of the rather poor context, where the main thing you can really lean on is the original string, even it that seems pretty nit-picky at first glance.
PR https://github.com/musescore/MuseScore/pull/526
@lasconic: I guess I'd need help on getting that elementName array (and probably some others too) converted into a struct, to resolve many of the CamelCase issues
I said it to Jojo privately, so I will tell it again here. I think it's bad idea to use the en_US translation on transifex to report 'bad' strings in the code. @Jojo if you want to use it your own notekeeping, it's all fine but I would not require anyone else, especially people with git knowledge to use Transifex.
Guidelines regarding plural, capitalization etc... See http://musescore.org/en/developers-handbook/design/user-interface-text-… and feel free to discuss, contribute (in a new forum topic).
If context is not good enough, it can be changed in the code. If you have Git knowledge, go ahead, add more information. UI files have a special field for translator comments. In the code, Qt provides translation comments and disambiguation http://qt-project.org/doc/qt-5.0/qtdoc/i18n-source-translation.html#tra…
I will do the struct.
I'm unclear about "TremoloBar Properties" and "TextLine", any hints?
Quite a bunch fixed now, but there are still some issues left.
"InstrumentLong", "InstrumentShort", "InstrumentExcerpt", as per lasconic should not get changed in the source, as used verbatim in XML, so may need to get placed in a struct, similar to the elementName Array
A lot of strings in libmscore/sym.cpp SymbolNames Array.
Still a few (some 10) "chord name" ->"chord symbol" left, as well as one "Fret Diagram" -> "Fretboard Diagram"
One palette is called 'Articulations' while the counterpart in the master palette is called "Articulations & Ornaments", I think they should be named the same.
Same issue for 'Frames' vs. 'Frames & Measures'
And the workspace files 'basic' and 'advanced' on GitHub need to get updated to match the latest strings from the source files
Here's a list of things that I think need to get fixed:
https://www.transifex.com/projects/p/musescore/viewstrings/#en_US/muses…
https://github.com/musescore/MuseScore/pull/534
Fixed in a9afd48d2a
Most issues fixed now, but there are still a few issues left.
"InstrumentLong", "InstrumentShort", "InstrumentExcerpt", as per lasconic should not get changed in the source, as used verbatim in XML, so may need to get placed in a struct, similar to the elementName Array
A lot of strings in libmscore/sym.cpp SymbolNames Array, may also need a a struct?
Some can be viewed here:
https://www.transifex.com/projects/p/musescore/viewstrings/#en_US/muses…
Without some help and guidance I won't be able to provide a PR for these...
Symbols can wait and will change a lot in the next weeks.
I will take a look to the styles.
Any suggestion to replace "InstrumentLong", "InstrumentShort", "InstrumentExcerpt" ?
"Instrument Long", "Instrument Short", "Instrument Excerpt" ?
As far as I know "Excerpt" is not used in the UI. It's used only in the code to describe what the UI calls a Part (like in File -> Part, not like in dynamic range -> part). So I guess "Instrument Excerpt" could be "Instrument name in part"? it appears close at the top of each part.
Same for InstrumentsLong/InstrumentsShort. They both refer to the instrument name in front of the staff. These names are refered as "Long instrument name" and "Short instrument name" in the staff properties dialog.
so let's take those terms, "Long instrument name", "Short instrument name", "Instrument name in part"
BTW: there is one "Chordname" left, in the same context as the above 3 terms, should be "Chord symbol" I guess
Seems all problems are solved now, with the latest commit.
...
Hah, found some more:
What about some of the terms with context "articulation", like 'verylongfermata', shouldn't those be proper words like "very long fermata"?
more examples: upbow, downmordent
Now that Chordname has been changed to Chord Symbol throughout, 1.3 scores that set the Chordname text style no longer work properly. Either we need to keep Chordname as the internal style name or else we need to add code in read114.cpp to translate. I guess similar issues might exist for other renamed styles?
Maybe the same solutions as for elementNames, i.e. make it a struct?
Are the changes in 3dfacd1 the culprit?
I think it is...
If so, in addition to "Chordname" the settings for "Lyrics odd lines", "Lyrics even lines", "InstrumentsLong", "InstrumentsShort", "InstrumentsExcerpt", "Technik", "Tuplets" and "TextLine" should be affected too.
Yes, that seems to be it. I'm just not sure what the best strategy is here - revert to the old style names internally for use in the actual score file, or make the conversion from old to new in read114. Presumably an easy enough fix either way, but it seems like a policy decision that lasconic or Werner should make.
My vote, FWIW, is to keep the new text style names and do the conversion in read114. There's a spot at line 330 where the old "Poet" is changed to "Lyricist", this is where we'd hook in for further conversions.
Having an extra parameter to the TextStyles() method, e.g. _prettyname, taking the new TR() stuff and the existing _name taking the old style names, maybe?
Just reverting would make it look ugly in US English, while it can get translated nicely into any other language.
Hmm, as there seem to be some conversion already, that seems the right spot for more IMHO.
Code starts here: https://github.com/musescore/MuseScore/blob/master/libmscore/read114.cp…
(a short while later)
See PR https://github.com/musescore/MuseScore/pull/555
or PR https://github.com/musescore/MuseScore/pull/556
Fixed in b61fa98a6b
Still some unresolved issues, mentioned in #37 :
What about some of the terms with context "articulation", like 'verylongfermata', shouldn't those be proper words like "very long fermata"? More examples: upbow, downmordent
And some more: I'm not sure (anymore) whether it is a good idea to have the directory names (for scores, images, templates. etc. in the preferences) translated. Might cause strange issues when switching between languages?
Translating the directory names should be fine. These directories will be created with the name translated in the system language on first run. Then these directory names will be saved in the preferences and so the other translations should not be used even if the user changes the language.
Does it make sense?
Problem is that on 1st start MuseScore uses the system language, while that is a good default, there are users that want a different language, but now are left with the system language directory names. Could possibly get solved by a dialog at install time, or at 1st start, asking for the preferred language (and possibly also for the preferred paper format and maybe some other settings)? Not really the scope of this issue though, should I submit an extra one for this?
But what about the issues from #44, verylongfermata and friends
See PR #772
Jojo: "and some may need a space added[.] Very hard to tell them apart."
Shouldn't spaces be added in the German translation only?
@Magnus: the ones you quote me on (the CamelCase ones) are fixed since quite a while.
And not by translating them, that actually broke things in .mscx files, a code change was needed to make them part of a struct.
And with 'hard to tell apart' I meant the ones that should or should not start with a capital letter, where without knowing much more about their context than the translations provide it is hard to make the decision.
Other than that my rule for dealing with upper/lower case was simply to use uppercase for all nouns (as that's the rule in German) Have the first letter follow the original string and have the first letter of every word follow the original text too, i.e. hav it upper case if the original had it uppercase and lowercase if the original had it that way. So only difference (in case) is the German spelling of nouns.
Fixed in 3e10ca00e3
Some more issues:
"plus stop" seems to have a double meaning, 'stopped' for brass and 'pizzicato left hand' for strings. Should we mention this in the original string or only in the translations, or not at all?
"Top Staff" and "Bottom Staff" in the contexts "ArticulationProperties", "InspectorArticulation" and "Ms\:\:EditStyle" seem to really mean "Above Staff" and "Below Staff" or "Top Of Staff" and "Bottom Of Staff" respectively. Which makes the choice of the names in enum ArticulationAnchor (libmscore/articulation.h) being somewhat confusing...
With the 3rd option in those dialogs, "Chord", apparently meaning "Auto Chord" i.e. depend on chord direction, away from stem, which begs the the question why there is no "Above Chord" or "Below Chord"?
Or am I misunderstanding these dialogs altogether?
I believe you are correct about top / bottom really being above / below and should be fixed in the original. As for Chord, my impression is that this setting causes the default position of the articulation to depend on the chord it is being attached to. So it appears above or below the staff according to stem direction - they attach to the notehead side of the chord. So below if stem up, above if stem down. And they seem to be allowed to cross into the staff, such as when attached to a single note on the middle line.
I think there should also be corresponding stem side setting option, although I guess it probably wouldn't be used anywhere by default.
EDIT: oops, missed your edit, I see you already figured out the stem direction thing.
Tried to fix both the plusstop and the Top/Bottom issue in separate commits of https://github.com/musescore/MuseScore/pull/582
Found another issue in the edit style dialog for articulations (they were not translated there), and hopefully fixed it in a 3rd commit to that PR
If you right click a chord symbol, the popup menu is labeled "Harmony". That should probably be renamed "Chord Symbol".
I guess there may be a few other places where the term "Harmony" is used, and if so, they should be renamed as well. Note that I'm about to remove the old Harmony Properties dialog. I see the dialog had already been renamed, but I wouldn't be surprised if there still some strings associated with it that hadn't been updated.
BTW, I'm removing all the code associated with this dialog. Not sure if I should delete the files themselves or if we keep them for source history purposes. And either way, if there is anything special I would need to do to make sure the list of strings to be translated gets updated to no longer includes strings associated with that dialog.
Fixed in ed6323110a
Yep, there's indeed one "Harmony" left, in libmscore/element.cpp. This should be the one and only though, unless there are some that are not marked for translation. The term is used all over the place, that's probably why I missed the tree in the forrest ;-), but as mentioned, none of them shows up on transifex. So if they show up in MuseScore, we're looking at a different problem: strings not marked for translation.
https://github.com/musescore/MuseScore/pull/584
Edit: merged now.
The translatable string from libmscore/style.cpp show up on Transifex, bit don't show translated in MuseScore's Text Style dialog or Inspector's pupup menu for Text Styles, both show the original untranslated values. Probably taken 'as is' from the active score?
Probably worth a separate issue though...
"notehead" vs. "note head", occurs twice.
https://github.com/musescore/MuseScore/pull/634
What about 'drumset', 'barline' and 'handbook'? I think they don't need to get changed into 2 words, do they?
I personally have a preference for the single word in *all* of these cases, including "notehead". Certainly for "handbook", which is an ordinary English word. Looking around, it does seem "drum set", "bar line", "note head" are more commonly used as two words in the literature, but Elaine Gould uses "barline" and "notehead" and that's good enough for me. Gould also uses "drumkit" rather than "drumset", but same difference as far as I am concerned.
Hold on: you wanted to get 'note head" changed to "notehead" and not the other way round? So the exact opposite of my PR?
There are 6 of those (plus the 2 I just changed)
Yes :-). But I care more about consistency than which way it goes.
For general style issues, lasconic above writes that we are to use the OpenOffice.org guidelines:
http://www.openoffice.org/specs/collaterals/guides/text-style-guide.html
However, it seems the tables of capitalization rules are missing from this document. So I am not sure what the rules to follow are. But it does seem the majority of current strings for capitalize the first word only (eg, field labels within dialogs), where Title Capitalization is used for menu items, button labels, and titles of dialog boxes, tabs, and panes. So I'll use that as my baseline. There are a few element types that occur only in one specific context and I'm not going to worry about those (eg, the articulation names and Anchor buttons in Style / General / Articulations). There does seem to be a trend in some dialogs to not capitalizing labels for radio buttons at all, but I think this is probably a mistake.
Here are some strings I see out of character with what I take the rules to be. I am listing them by dialog because it's not always apparent to me where the source string actually is (sometimes it's in the ui file but otherwise set explicitly in a cpp file), also so people can see the context to decide if I'm right or wrong about any of these.
Warning: there are a *lot* of these. Most are field labels currently in Title Case that should be First word only. Also, I intended these to be grouped by dialog witht he actual strings indented underneath the dialog names. But the indenting doesn't show. Just realize, the first line of each group is the dialog name, and these are correct.
Style / General:
Capo Fret Position
semitones offset
cents offset
Style / Text:
size follows Space unit [ here, keeping Space capitalized probably makes sense ]
Style / Staff Type:
Show Clef
Show Time Sign. [ and this should not be abbreviated ]
Show Barlines
Ledger Lines
Key Signature
On Lines
Above Lines
Note Symbols
Vert. Offset [ probably don't abbreviate this either ]
Layout / Page Settings:
Two Sided
First page no. [ abbreviation ]
Notes / Tuplets / Other:
number
relation
nothing
auto bracket
bracket
nothing
Notes / Transpose:
By Key
By Interval
Transpose Diatonically
View / Synthesizer:
Master Tuning
Edit / Preferences:
start empty
continue last session
start with new score
start with score
show splash screen
Scores Directory
Styles Directory
Templates Directory
Plugins Directory
Soundfonts Folders
SFZ Files Folders
Images Directory
[ Show Play Panel et al I think are OK, since those are names of windows ]
Default Duration
MIDI Remote Control
[ all of the the individual buttons underneat that - I'm getting lazy ]
Instrument List1
Instrument List2
Style for Part
Character set used when importing binary files [ should be Title Case ]
Shortest Note
Sample Rate
File / Parts:
Part Title
File / Info:
[ not sure about this; these may reference to case-sensitive metadata fields ]
File / Album:
Album Name
Inspector / Time Signature:
Show Courtesy
Inspector / Clef:
Show Courtesy
Inspector / Key Signature:
Show Courtesy
Show Naturals
Inspector / Tempo Marking
Follow Text
Inspector / Line:
Allow Diagonal
Line Color
Line Width
Line Style
Inspector Slur/Tie:
Line Type
Inspector / Articulation:
Time Stretch
Inspector / Ottava:
numbers only
Inspector / Marker:
Marker Type
Miscellaneous properties and other dialogs:
Style / Staff Types:
Part Name
Long Instrument Name
Short Instrument Name
Play Transposition
Edit string data
Select Instrument (from Staff Properties / Change Instrument):
Current Instrument
Time Signature Properties:
Global Value
Actual Value
Line Properties:
place
Symb. [ abbreviation ]
Volta Properties:
Repeat List
Please check the latest en_US translation whether that fits your bill.
The stuff under File / Info is not translatable and I don't think it should be
I take it you are referring to Transifex? I thought the point of this issue was that we should fix the sources themselves?
I'm not too familiar with Transifex, and couldn't figure out how to get a list of recent changes. Asking for a list of updates after 1/10 came up blank, but I can see there were changes, so obviously I'm not getting something.
Yes and no, just download the latest translation for en_US via MuseScore's resource manager (menu -> Help -> Resource Manager), restart MuseScore for the updates to take effect, then revisit all the menus to check.
Once I get the OK, I'll change it in the sources and submit a PR
You get the changes by looking at all non-reviewed itmes: https://www.transifex.com/projects/p/musescore/viewstrings/#en_US/muses…
Once the PR got merged, these will automagically disappear
Ah, that makes sense, thanks. And thanks for taking on all this work! I know it's not glamorous, but obviously it does matter to some of us.
BTW, in the process of firing up the Resource Manager, I found another right in the main menu: "Help / Report a bug". Also, just noticed yet another: "Notes / Respell pitches".
No doubt I've missed others - especially in the context-specific items like Properties dialogs and the Inspector, some of which I probably failed to visit in my search the other day.
On checking your work, it looks great overall. I'm surprised at how much of a difference it makes to see these fixed. But you did miss a couple, and I found a couple I missed the first time :-).
In the following, lines beginning with ":" are ones from my original list that seem to have been missed (wondering if maybe same strings were changed in another context?). Lines beginning with "+" are new ones I've found.
Style / Staff Types
+ Line Distance
Notes / Tuplets / Other
: bracket
: auto bracket
Notes / Transpose
+ Transpose Chromatically
Edit / Preferences
+ Draw Antialiased
+ JACK Audio Server [ unless that really is the name of the program? ]
Inspector / Key Signatures
: Show Natural [ capitalization but also pluralization - should be "Show naturals" ]
Staff Properties
+ Up
+ Down
Line Properties:
+ x
+ y
There are three more I'm hedging on. In Staff Properties, there is "+octave". I suppose that could be left lower case because the label doesn't technically *begin* with the word "octave". But it would look odd next to "Up" and "Down" once those are fixed. On similar principle, Style / Text Style, "% horizontal" and "% vertical" should probably be capitalized too.
A few more dialogs I didn't think about the other day:
Text Properties
+ [ same issue with % vertical and % horizontal as Text Style ]
Frame Properties
+ top/left [ hmm, should this be Top/left or Top/Left? ]
+ bottom/right [ similar ]
+ left
+ right
+ top
+ bottom
+ width
+ height
Measure Properties
+ nominal
+ actual
+ break multimeasure rest
+ Measure Number Mode
+ Add to Measure Number
+ Layout Stretch
+ Repeat Count
Split Staff
+ Split Point
Edit Drumset
+ Note Head [ capitalization at least ]
+ Staff Line
+ Stem Direction
+ Default Voice
View / Play Panel
+ bpm [ should probably be BPM ]
+ Tmp. [ should be Tempo ]
+ Vol. [ should be Volume ]
Reg. "+octave", "% horizontal": how about "+ Octave:" and "Horizontal %:" (both were lacking a : too)? This and your proposals from #66 and #67 plus a couple more are in the translations now, I made it "Top/Left", etc.
Is it "multi measure", "multi-measure" or "multimeasure"?
Fixed in 9b2b9b6bf5
This was the notename vs note name issue
Regarding colons, I'm afraid to say those too are very inconsistent.
I don't have a preference on multimeasure versus alternatives, but I think we mostly use it as one word, and that's fine by me.
https://github.com/musescore/MuseScore/pull/637
Fixed in 1c315db2e4
Still some leftovers: https://github.com/musescore/MuseScore/pull/639
Typo: not sure if this a normal translated string or not, but in Synthesizer / Master Effects, "Ouput" (should be "Output", of course).
I can't find it anywhere in the source nor the translations. Seems to be the image of some text?
Fixed in 4ad440c822
Found another omission: https://github.com/musescore/MuseScore/pull/641
The "Ouput" string is indeed inside an image:
MuseScore/effects/zita1/mixsect.png.
I've submitted a new issie for this: #24289: Typo in effects/zita1/mixsect.png
Fixed in d77cacee63
Edit / Preferences / Shortcuts, hit Define; this brings up "Enter shortcut sequence" dialog, title should be capitalized. Also, the exclamation point in "Press up to 4 keys to enter shortcut sequence" seems gratuitous, and "4" should probably be spelled out (not sure).
https://github.com/musescore/MuseScore/pull/648
Style / Staff Types
+ Create new standard type
+ Create new percussion type
+ Create new tablature type
All three should be title case.
Also, same dialog:
+ Upside Down
+ Show Rests
Should be initial cap only
Added to https://github.com/musescore/MuseScore/pull/648
Here's another, then :-)
String Data
+ Number of Frets
added (as "Number of frets")
Fixed in cc9f69d708
How about this?
1. Open attached score (produced in 1.3).
2. Right-click the (system) text.
Expected result: The menu name is 'System Text', whilst a menu item and its window title say 'System Text Properties…'.
Actual result: They say 'Stave Text' and 'Stave Text Properties…' respectfully.
Using MuseScore 2.0 Nightly Build (d65c722) - Mac 10.7.5.
For the record, system text is actually the same as staff text internally - the only difference is the text style applied. So it may be unavoidable - or harder to avoid than is worthwhile, anyhow - to have the same menu & dialog titles for both. Not saying this doesn't have the potential to be confusing and couldn't be worth looking at, but it's not just a matter of fixing a spelling somewhere.
Similar issues arise with other element types that are actually subtypes of other elements. For example, an "ottava" is a special case of "line" and hence its context menu & dialog refer to the latter, etc. But in most of those cases, the hierarchy is probably clearer.
If there isn't a separate dialog for systems and start text, this would be out of the scope if this issue and getting that fixed would requite a separate one. Esp. As this one here is way to long already, so I'm inclined to mark it fixed again, agreed?
Thanks for explaining, Marc.
Just to be absolutely certain though, could we let Werner answer before marking as 'fixed'?
$ grep -I staff text" */* 2>nul
libmscore/element.cpp: ElementName("StaffText", QT_TRANSLATE_NOOP("elementName", "Staff Text")),
mscore/actions.cpp: QT_TRANSLATE_NOOP("action","Staff Text"),
mscore/actions.cpp: QT_TRANSLATE_NOOP("action","Add staff text")
mscore/menus.cpp: sp->append(st, tr("Staff Text"));
mscore/propertymenu.cpp: popup->addAction(tr("Staff Text Properties..."))->setData("st-props");
mscore/stafftext.ui: MuseScore: Staff Text Properties
$ grep -i "system text" */* 2>nul
mscore/actions.cpp: QT_TRANSLATE_NOOP("action","System Text"),
mscore/actions.cpp: QT_TRANSLATE_NOOP("action","Add system text")
mscore/exportly.cpp: -- become clear on the difference between system text and staff
mscore/menus.cpp: sp->append(st, tr("System Text"));
This confirms that there is no separate properties for System- and Staff text, hence nothing in the translation (or rather pre-translation) to correct. Please open a new issue for getting the separation.
Since you know the code stuff, would you mind creating an issue?
Done: #24426: No separate properties dialog for System- and Staff Text
Thanks Jojo!
Here's a little tip (if you don't know) if you wanted to edit the issue: For the Git commit, go to 'About MuseScore' and click on the 'Copy to clipboard' button and replace what exists in the brackets.
oops, Yes, I know that trick, but I also know how to construct these manually, but do make typos sometimes ;-)
One thing we could do to the existing text is changing it to "Staff/System Text Properties". Opinions?
I think it's better to separate them :).
1. Open score.
2. 'Style'>'General…'.
Result: In the 'Score' section, the dropdown box for 'Musical symbols font' features the entry 'Goneville' - it should spell 'Gonville'.
Using MuseScore 2.0 Nightly Build (fbe6fc5) - Mac 10.7.5.
This isn't a translatable string and so not really the score of this issue, but anyway:
https://github.com/musescore/MuseScore/pull/678
Fixed in 47eeb5d2d5
Automatically closed -- issue fixed for 2 weeks with no activity.