CMSEditLink() was changed to always add a locale, but the link
creation for "Existing Translations" in Translatable#updateCMSFields
assumed there was no query string on the end of CMSEditLink()s return
value
Note that youll still end up with duplicate locale parameters after
this patch, but it will work as PHP always takes the last parameter
for preference. A seperate patch for Controller::join_links will
fix the duplicate parameters
Corrected Translatable docs in setting the locale based on $member->Locale to the correct method: Translatable::set_current_locale($member->Locale); instead of Translatable::set_reading_locale($member->Locale)
When you publish a node in the default locale it calls forceChange to make
every field behave as if it has changed. The problem in Translatable is then
it would think that you actually changed the class of the default locale node
and it would force a change on every translation. This was unnecessary when you
have not actually changed the class name. If you have a great deal of
translations this was causing a significant lag when you publish anything in
the default locale.
This breaks code that tries to get all instances of SiteConfig like:
```
Translatable::disable_locale_filter();
$all = SiteConfig::get();
Translatable::enable_locale_filter();
```
What was happening was that our populateSiteConfigDefaults method was
getting called before the actual data list the users uses above is
created, so it was re-enabling the locale filter before the
augmentDataQuery function was called on the data list created for the
user. Thus, they'd get a locale-augmented query and only get the
SiteConfig for the current locale, and not all as clearly intended.
Iterating over an array of locales and querying for each one causes tons
of unnecessary queries. This is especially evident when you get up to
hundreds of translations of a page. It makes the CMS admin UI insufferably
slow. This is a little tweak to query for all of them at once instead of
individually.
Even though it is an edge-case, some sites may allow translation groups to be
composed of different classes. In that case, Translatable->getTranslations()
should still work.
Also, this commit adds a helper function for testing two array for equality
where you don't care about the order of the elements. This cleaned up a lot
of copy and paste boilerplate code that was sorting arrays to test.
