Split es locale into several variations and migrate existing user translations to es-ES

[diox]

See mozilla/addons#15232

Context

As part of streamlining our locales we're splitting es into several variations. The Pontoon team have asked us to copy over the existing locale to the new ones and they'll sort them (either as actual translations or suggestions) in Pontoon. That makes the diff for this PR rather large and scary since I've copied the existing .po file into several new ones. You can diff them with the es one to make sure I haven't messed it up and then ignore them.

Testing

Locally, you need to either bypass addons-frontend in nginx.conf (by replacing the try_files $uri @frontendamo by try_files $uri @olympia) or build a custom addons-frontend image with mozilla/addons-frontend#13401 otherwise it won't let you use the new locales, as in local development we're proxying requests through addons-frontend instead of fully defining routes in nginx.

The es locale should no exist anymore, and be replaced by the new variants.

Migrations

This change contains 3 migrations that will affect hundreds of thousands of rows in dev/stage/prod. I've tested them locally with 700k+ rows and the biggest one took less than 10 seconds.

[KevinMind]

Oh god how I wish we had enums for locales...

[KevinMind]

@diox how did you create 700k+ rows? Even better, you can zip your database and send it to me by running

make data_dump ARGS="--name pr-22982"

Then zip the directory and send it to me. I can then load that directly on my instance and boom!

[diox]

I'll generate the dump, but for the record, I essentially did:

translations = []
for x in range(0, 700000):
    t = Translation.new('Lorem ipsum dolor sit amet, erat graece accusata eum te', 'es')
    translations.append(t)
Translation.objects.bulk_create(translations, batch_size=1000)

(Translation.new() is a custom hack in addons-server used behind the scenes when creating translations "the normal way", that is there to maintain the separate id sequence table. I've tried to reproduce that behavior here while still being efficient with a bulk_create() after, but I haven't checked if it completely works as expected in very aspect, I was only interested in creating garbage data)

[diox]

Updated, and on top of providing the snippet I used to generate extra data locally I've shared my database dump privately on slack.

[KevinMind]

Verified 🚢

• migration took around 10 seconds with 700k translations.. creating the translations took a lot longer 😆
• confirmed generic ES is not available on devhub selector