German translation: inconsistent (and wrong) octave numbering

[mmeyn]

Issue type

UI bug

Bug description

The numbering of octaves in german translation is inconsistent: The octaves themselves are numbered/named correctly (with the exception of “Oktave 0”) but the pitches are not:

The pitches should be named

D9 = d⁶
D8 = d⁵
D7 = d⁴
D6 = d³
D5 = d²
D4 = d¹
D3 = d
D2 = D
D1 = D₁
D0 = D₂
D-1 = D₃

Alternatively, sometimes apostrophes and commas are used (d⁴ = d’’’’ and D₂ = D,,) but I’d prefer numbers for better legibility.

Also, the “Oktave 0” should be “Subkontra-Oktave”.

Steps to reproduce

1. Set language to german.
2. Go to instrument properties.
3. Change amateur or professional pitch range.

Screenshots/Screen recordings

No response

MuseScore Version

4.1.1

Regression

I don't know

Operating system

–

Additional context

No response

[Jojo-Schmitz]

I've just fixed the translation of "Octave 0" from "Oktave 0" to "Subkontra-Oktave", update your translateds in about 15 minutes, thanks for the report, an obvious oversight of mine.

As the pitches in the status bar always show the MIDI octave-1 to 9), and in a non-translateble way, I'm not sure whether we should translate these here. But there's no code change required, just translating the strings from/on https://app.transifex.com/musescore/musescore/translate/#de/$/431867120?q=context%3AEditPitchBase.
I don't see a (clean) way though to use sup- and superscript in the translations.

[mmeyn]

As the pitches in the status bar always show the MIDI octave-1 to 9), and in a non-translateble way, I'm not sure whether we should translate these here. But there's no code change required, just translating the strings from/on https://app.transifex.com/musescore/musescore/translate/#de/$/431867120?q=context%3AEditPitchBase.

There are three possible degrees of translation:

1. No translation at all: B♭ 4, B 4, C 5
2. Translation of the pitch class but not the octave: B 4, H 4, C 5
3. Translation of both pitch class and octave: b¹, h¹, c²

IMHO option 2 (used in the instrument properties dialog) is by far the worst because it’s inconsistent. Option 1 (used in the status bar) is better than 2 but I’d prefer option 3 in places where translation is possible.

I don't see a (clean) way though to use sup- and superscript in the translations.

Couldn’t you just use Unicode characters (₃₂₁¹²³⁴⁵⁶)?

[Jojo-Schmitz]

Hmm, yes, those Unicode characters may work, let's try

Done, but, while showing in that dialog you show above

it doesn't in the Staff/instrument properties dialog

nor in the string data dialog:

nor in the section dialog:

nor, as mentioned, in the status bar

And that's why I have serious doubts about whether this is useful at all

[mmeyn]

Hm … How come that in the string data dialog the B3 is still partially translated as H3? The status bar and the section dialog are consistent (showing B3).

[mmeyn]

Oh, I see: Some string magic is found in the function tpc2name in pitchspelling.cpp. It uses an enum NoteSpellingType that is set depending on the chord name settings in the style dialog. To me it looks like there is no really strict distinction between UI language and engraving/score language of pitches.

[cbjeukendrup]

Yes, localisation support for score content is not in a great state at the moment. For instrument names, tempo markings, expression markings, and in some cases also note names, it uses just the same translation data as the UI, and thus also the same language as the UI. If you add things to a score from someone who has an English computer, and your computer is German, the score will become a funny mix of languages. And often, note names that include octaves are translated by concatenating the translated note name letter with the octave as a number that does not follow any local conventions.
On the other hand, there is that specialised tpc2name function that translates note names according to a limited number of name styles that you might be able to choose somewhere in some dialog. But as far as I know, this is not hooked up to the UI language (and thus score language) in anyway.

What needs to happen, is that we create a dedicated "LocalizationProvider" class for the engraving module. Whenever something inside the score needs to be translated, this LocalizationProvider should be used. There should be at least a setting to set the overall language of the score (but perhaps some fine-grained control would be useful too, idk), and the LocalizationProvider should provide the score with translations in that language.
We might need to make specialised functions like tpc2name, for those situations where just sending strings to Transifex is not going to produce sufficient results. This will require good collaboration between programmers and those who speak the language in question.
Retranslating existing items in the score would be a big step further. Especially trying to preserve changes made by the user in a sensible way would be quite a challenge. I don't think that would be in scope for the near future.

See also #19071 (actually the biggest part of my comment belongs there...)