Patch draper to make it compatible with the `localize` method.

The `localize` method takes two arguments, but our version of Draper
only accepts one in it's wrapper method. This is fixed in the latest
versions of Draper, but upgrading requires a lot of changing of
code (see [the upgrade manual][1]).

The fix is actually present in Draper 0.18, which requires less of
an upgrade in terms of our presenters, but insists on having
ActiveSupport `~> 3.2`, and we are presently on Rails 3.1.

The simplest way to make progress is, unfortunately, to just patch
the method.

[1]: https://github.com/drapergem/draper/wiki/Upgrading-to-1.0
Show translated page labels on the world location show view.

We've extracted all of the currently-available page labels into
locale files (initially just English and French to demonstrate the
functionality).

The locale a page is shown in can currently only be set by adding a
`locale=fr` parameter to the URL. How the actual URL is constructed
and the UI for chosing a locale is a separate concern.

It's possible that we'll need to revise the taxonomy of translated
items as other languages with less Latin-compatible pluralisation are
added, but for the moment this is a sufficient first step.

Where any sophisticated construction of translates is required, we
should encapsulate that into helper methods. This will help protect
the view from too much churn as the needs of varying languages come
to bear on the application.

We plan to use Localeapp[1] to administer the translation files, I'll
go into that in more detail in a later commit.

[1]: http://www.localeapp.com
Introduce Localeapp.

The Localeapp gem allows us to push and pull translations to the
[online application][1]. As we extract or adapt the translation
keys, we push up our base (en) translation file to the service, e.g.

    bundle exec localeapp push config/locales/en.yml

On the application, we can then see which translations are missing in
any of the other created locales.

Translators can have accounts on the service, and can be restricted
to editing only specific locales. When they have made translations,
we (the developers) can *pull* their changes down.

    bundle exec localeapp pull

I have made this application private, and we'll need to invite
developers and translators. It appears to be free to use, which is a
bonus.

The changes to the locale files within this commit are a result of
pushing and pulling them from the service, which has added some
translations, and re-ordered the existing ones.

Locale appears to include a YML file in the log directory; it's not
clear if this is an important part of the sync data or if it can be
ignored, so I'm defaulting to ignore it for now.

[1]: http://www.localeapp.com/projects/3437
An alternative translation flow to Localeapp.

It seems like getting disparate, non-technical users to integrate
with Localeapp is a non-starter. That's a shame.

Instead, they will be most effective if they are given spreadsheets
of data to translate.

We can generate this data from the existing translations. This commit
includes a rake task which will export a CSV suitable for spreadsheet
based translation. The command:

    bundle exec rake "translation:export[.,en,fr]"

will export "fr.csv" into the current directory, containing a mapping
of source and translation strings. It should be fairly trivial to
sort the sheet in Excel/Google Docs and see where some translation is
missing.

The translators will still need some training (if only "avoid date and
time translations that you don't understand"), but this could form
the basis of a workflow that is less taxing on the organisation as a
whole.
Allow importing of translated CSV files.
Move locale setting to public facing controllers.

We don't need this functionality in the admin.
Tiny formatting niggle.
Tasks for exporting and importing all locales to/from CSV.
Import booleans and numbers back to yaml properly.
Prevent commit churn by normalising file whitespace.

There's still a bit of work yet on this, but adding a trailing
newline helps.