This is enforced by the localisation analyser after
https://github.com/ppy/osu-localisation-analyser/pull/62, but it appears
the analyser was never actually bumped game-side after that change and
I'm not super sure why, as there does not appear to be a reason to _not_
do that. So this commit does it.
Noticed via `osu-resources` build warnings.
There are also a few other warnings about
https://github.com/ppy/osu/pull/27472. Seems something in crowdin
innards may still be exporting those strings even though they have been
fixed already. Not sure how to address that.
Probably need these to be detected via static analysis at this point
since it's happened again. Might look into the feasibility of making
that happen.
Something I ran into when investigating
https://github.com/ppy/osu/issues/28169.
If there are two scores with the same online ID available in the
database - for instance, one being recorded locally, and one recorded by
spectator server, of one single play - the lookup code would use online
ID first to find the score and pick any first one that matched. This
could lead to the wrong replay being refetched and presented / exported.
(In the case of the aforementioned issue, I was confused as to whether
after restarting spectator server midway through a play and importing
the replay saved by spectator server after the restart, I was seeing a
complete replay with no dropped frames, even though there was nothing in
the code that prevented the frame drop. It turns out that I was getting
presented the locally recorded replay instead all along.)
Instead, jiggle the fallback preference to use hash first.