Added back-migration for Big Locale Refactoring #14062
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Just in case something goes horribly wrong with an upgrade to v6.3.0 (or wherever we land this Giant Locale Change), I thought it best for us to have a back migration.
This change pulls the giant Language Array out into a
$language_map
static variable, so it can continue to be used by the existingmapLegacyLocale
static Helper method, as well as the newmapBackToLegacyLocale
static Helper method. I could have done some kind of clever loading up another array with smart keys-and-values, but this is probably only going to ever be used in the back-migration, and nowhere else. So hopefully not used much at all. Because of that, I left it unoptimized.I tested by looking at my users and my settings record, then running the migration, checking those tables again, then migrating back, and checking those tables again. And they seem like they look kinda how you'd expect.