Failing feature for non-English world news
Editions now have a primary locale

So we can differentiate between a normal (English) edition and
non-English ones, we store a "primary locale". By default, this
is English, so existing documents should behave as before.
Editions fallback to their primary locale

globalize3 uses globalize_fallbacks when checking translated attribute
values. By default, it checks the for translations in the current
(globally-set) locale before falling back to whatever the default
locale is (i.e English). By overriding globalize_fallbacks, editions
will fallback to their primary locale instead of the default one,
meaning that non-English editions behave as expected (i.e. are valid)
when loaded in the default English locale.
Non-English editions do not get a slug

Because we cannot reliably generate readable slug strings for
non-English editions, we don't generate one, meaning that document
identification/param-generation will fallback to the document id.
Simplfy update slug logic

The unless / or clause was confusing so I've simplified it with a
guard clause. This uncovered a potential bug where the published?
check would return true even when the documents edition had been
unpublished because the published_edition association was returning
a cached edition.
Disable translations for non-English editions

If a user creates a non-English edition, then they forfeit their right
to translate it. We *could* in-theory allow this, but because the
specific use-case for this story is for news articles that are only
relevant to the local populous, we disable it to keep things simple.
Allow non-English world location news articles
Always save a slug, even for non-English editions

OK, so not having a slug set turns out to make things compicated on
front-end. Thinking on it, it actually makes more sense to save the
slug as the id for non-English editions, that way there is no
intrinsic difference between an English edition and a non-English one
as far as front-end is concerned.
Ensure updates maintain the non-Englishness

Primarily we want to avoid globalize saving the edition in the default
locale.
Stop globalize3 saving blank default translations

By some quirk of the globalize3 internals, non-English editions end up
with a blank English translation saved form them when they are updated
(e.g. published). By renaming the :primary_locale attribute to :locale
and relying on the behaviour added by [this commit](https://github.com/svenfuchs/globalize3/commit/6c7b21a560e06356ac6aed7b4099333a5c6868e0)
in globalize3, we can stop this from happening.
sorted_locales handles non-English editions
Make sure slugs are strings

They end up as strings in the database, but if we are working with
them straight after creation, we want to make sure the slug is a
string to avoid giving the routing helpers grief
Routing helpers handle non-English editions

We set the locale in the routing parameters for non-English editions
to ensure that the generated links always link to the correct
translation.

Note that this assumes non-English editions never have additional
translations, as setting the locale in this way forces it to what we
set, i.e. LocalisedUrlPathHelper will not override it with the current
locale in the public-facing controllers. If in future we decide that
non-English editions *can* have translations, we will have to rethink
how we generate these links so that they default to the edition's
primary locale, but still allow overrides for public-facing routing on
localised pages.
Tweak test stubbing to deal with LocalisedModel

Because we are loading editions as LocalisedModels, stubbing the can?
method with the actual instance no longer works. The simple fix is to
remove the parameter requirements on the stub as we're only interested
in verifying that limited access editions are not accessible, which in
this instance, falls outside the remit of the Authority stuff.
Don't index non-English editions
Enhanced-UI for non-English editions

Make the UX a bit nicer with a sprinkling of JavaScript. We hide the
locale select fields by default, revealing them when the user clicks
a reasonably anonymous link. Non-JS users see the fields by default,
so everything should just work.
Locale returns all right-to-left languages
Handle RTL languages for non-English editions

We apply the appropriate classes to the form if a user selects a
right-to-left language for a non-English edition.
Correctly render right-to-left editions and forms

This makes sure that right-to-left non-English editions are rendered
appropriately when viewed in admin. It also ensures that the edit form
fields are right-to-left when appropriate. Note that I have only
updated the form partials that are directly used for world location
news articles. If non-English support is added to other edition
types, the appropriate form field partials will need updating
accordingly. As a bonus, I've updated admin preview of
translations to account for right-to-left languages.
Fix indentation