the special symbols $m/$M/$d/$D ignoring the settings of the regional format in ubuntu 16.04 LTS
Type
Wording/Translation
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project
my preferred language for the menus and windows in my system (ubuntu 16.04 lts) is the preinstalled english language (US). for date/currency i use the german regional format (de_DE). but musescore seems to ignore my regional attitudes. the values I get for $m/$M/$d/$D etc. are always from the language currently defined in musescore. in my case, i always get the american representation of the date: m/d/y. the confusion is not very far if you also use $:creationDate: in the same project.
OS: Ubuntu 16.04.5 LTS, Arch.: x86_64, MuseScore version (64-bit): 2.3.2, revision: 4592407
Comments
$d
,$D
,$m
and$M
useQt::DefaultLocaleShortDate
, see http://doc.qt.io/qt-5/qdatetime.html:If the format is
Qt::DefaultLocaleShortDate
orQt::DefaultLocaleLongDate
, the string format depends on the default application locale. This is the locale set withQLocale::setDefault()
, or the system locale if no default locale has been set. Identical to callingQLocale().toString(datetime, QLocale::ShortFormat)
orQLocale().toString(datetime, QLocale::LongFormat)
.I can't find a way to differentiate the general locale from those for just language, or just time and date, or just currency, etc.
sorry, i do not understand. what does this have to do with musescore?
In reply to sorry, i do not understand… by rijo
Use an online translator and read the original discussion under "What links here"
Qt is a library MuseScore uses, and that doesn't seem to have the ability to have date and time being rendered independantly from the general language settings
Hello,
I'm using the German locale (with a DD.MM.YY date format), and this format was also used by MuseScore 3.6 for the $p placeholder in my footer.
With MuseScore 4.0, I get the American formatting (MM/DD/YY).
This seems like a bug - or a regression at least...
Yes, but an entirely different bug than the one at hand in this issue, see https://github.com/musescore/MuseScore/issues/15437