MuseScore
MuseScore copied to clipboard
musescore
[MU4 Issue] The date macros ($d, $D, $M) for header/footer show the dates in US format (MM/DD/YY)
Describe the bug The date macros ($d, $D, $M) for header/footer show the dates in US format (MM/DD/YY)
Expected behavior Same as MuseScore 3 and before: obey MuseScore's language settings or the computer's regional settings
As an alternative (and the least thing to do) use the ISO format, YYYY-MM-DD
Tried with
- MU4 - Official: Language setting is German. Date format is also German
- Nightly: Language setting is English. Date format is German
OS: Linux
Not so on my Windows 11. System, Language and Date settings all in German, MuseScore date shows in US format
And it isn't just me but also the user from https://musescore.org/de/node/339004
Confirmed on Windows 10 21H2 (19044.2251): even after explicitly setting MS4 to German the dates are still in US format. Tested with official (MuseScore version (64-bit): 4.0.0-223472200, revision: github-musescore-musescore-5485621) and 27 Dec nightly (MuseScore version (64-bit): 4.0.0-223610304, revision: github-musescore-musescore-002fd32)
I see the code differences, but my cpp skills are too limited to draw the right conclusions from what I see...
version 4: https://github.com/musescore/MuseScore/blob/9055e9730b89f56bb8a04303e94429c198accf3f/src/engraving/libmscore/page.cpp#L463
version 3.6.2: https://github.com/musescore/MuseScore/blob/4566605d92467b0f5a36b3731b64150500e48583/libmscore/page.cpp#L357
As said: I don't have a clue of cpp so I cannot judge.... But it might well be that the Date object always and only uses the underlying C locale (en_US). As long as you are on an en_US system it does not matter for obvious reasons, but there must have been a reason to use QDate and Qt localization previously.
A bit of background: the reason that we are not using Qt anymore for this, is that we don't want our engraving library to depend on such a specific and huge framework as Qt, which is primarily used for building user interfaces. To mention one advantage: without this huge dependency, it becomes much easier to use our library in other applications, if anyone would ever want that. Another is that our engraving module is safe when a new major version of Qt is released, or if Qt suddenly quits its open source licenses, like they are already doing for LTS releases. However, the "loss" of Qt inevitably has some disadvantages; in some places, its easy localisation system will be missed. The solution might be to write a wrapper for Qt, like we have done for QPainter; so in this case, we could create an interface like "ILocalizationProvider" which would be used for various localised formatting tasks, with an underlying Qt implementation, but this implementation is hidden from the rest of the engraving module.
For me it would be sufficient to have a possibility to specify my preferred date & time format somewhere (e.g. close to the language setting in general preferences). Actually that would be even better than localization because I could use universal ISO format...
If not configurable or as per locale, ISO format is the only right and sensible choice (and US format being the worst and wrongest choice). Also that, and only that, should be in used on musescore.com, i.e. by the backend.
After uprgading my scores to version 4, I'm being bitten by this bug too, with the wrong date being displayed (for my locale - day and month in wrong order). I would ideally like to see:
- The application picks up the locale of the local OS, whatever that is. (I appreciate that this is probably the hard part, given that MuseScore works cross-platform - which is important - and so probably has to account for all possible local OS libraries for determing it. I'm imagining lots of
ifdefs.) - By default, new scores pick up the locale of the application, and the locale gets stored into the new score file, affecting how it is formatted. (This way, if the file is sent to someone else, it displays exactly as it was authored. That's my preference for the default anyway, since it is least likely to catch someone out, but an alternative for the default could be for it to always pick up what the application locale is.)
- The musescore file locale can be altered by the user. (A specific locale can be chosen, or it can be set to always pick up the application locale.)
- The date format can be configured. My preference would be for placeholders representing the "conversion specifiers" of
strftime's format string to be added to the existing ones already available for use within the header and footer text input fields.Y,y,manddat a minimum.
Of these, number 4 is the most important. With number 4, it is possible to write a date in a locale-independent way (e.g. Y-m-d), which would make it possible to work around the problem of determining the user's locale problem, which sounds like more of a challenge. It would hopefully be a simple partial fix.
The choice of the US format is the worst of all...
For me this issue is a showstopper (not the only one though) for updating my scores to 4.0, as I'm using Version $Mon all my scores, and that US format is just confusing as hell to non-US users
@cbjeukendrup : any chance to quickly change the default format to ISO (yyyy-MM-dd) instead of LocaleShortFormat? https://github.com/musescore/MuseScore/blob/9055e9730b89f56bb8a04303e94429c198accf3f/src/engraving/libmscore/page.cpp#L463
That would for sure be an excellent workaround for all non-US users - a really quick win with minimal effort.
Yes, ISO would be the very least thing to do here. At least for a 4.0.2. For 4.1 I'd rather see a more adcanced solution
Let's try that. See #15906.
@Tantacrul This seems indeed appropriate for 4.0.2 (and is low risk anyway)
Hasn't this fix made it into 4.0.2? If so it doesn't work, I still see MM/DD/YY rather than YYYY-MM-DD
Reopening awaiting a proper solution for 4.1
Based on @cbjeukendrup's comment, I'd say 'no'.
That comment shouldn't indicate that, just that for 4.1 a more complete solution is wanted than the simple ISO date one for 4.0.2. But instead the ISO version went into master but not into 4.0.2 :-(
I must admit, this one was handled by other folk, so I think I'll wait for someone who was involved to comment. Apologies, just a little busy so can't quite take time to look.
@Tantacrul The plan was to put a low-risk trivial fix in 4.0.2, and work on a more complicated fix for 4.1. According to the history of this thread, I communicated this back then, and you added it to the 4.0.2 project accordingly.
But then there was a misunderstanding/whatever: the fix for 4.0.2 had been merged to master, and you moved the issue to the 4.1 project, awaiting the promised proper fix, but at that point the fix intended for 4.0.2 had not yet been cherry-picked to the 4.0.2 branch. And because the issue had been removed from the 4.0.2 project, that never happened anymore, unfortunately.
Let's hope that the months until 4.1 will pass quickly :)
Ah, well sorry if this seems rather convoluted. It is entirely likely that someone on the dev team asked me to move it for some reason. At least if it is assigned to 4.1, we still have the task prepared to be worked on.
I too am annoyed by the US format even though it has a logic of its own ... Thanks for the background info, I now appreciate more the convolutions that go with this seemingly small issue.
