Split es locale into several variations and migrate existing user translations to es-ES
#22982
Conversation
diox
force-pushed
the
create-es-locales-folders
branch
from
b0db161 to
60ef7a2
Compare
diox
changed the title
es locale into several variations and migrate existing user translations to es-ES
diox
requested review from
a team and
KevinMind
and removed request for
a team
diox
force-pushed
the
create-es-locales-folders
branch
from
35a6260 to
cf0de0a
Compare
|
|
||
| def backwards_func(apps, schema_editor): | ||
| Addon = apps.get_model('addons', 'Addon') | ||
| Addon.unfiltered.filter(default_locale='es-es').update(default_locale='es') |
There was a problem hiding this comment.
Is it possible currently for an Addon to have es-es as the default_locale? Could this run backwards blow that state away?
There was a problem hiding this comment.
It's only possible if it was forced or is very, very old. As it turns out we have a single add-on in prod that does this, and it's... the es-ES language pack for Firefox.
In the unlikely event that we'd run the backwards migration for addons and not the one for translations in prod, that add-on would have no name/summary and would need to be manually fixed, which isn't the end of the world since it's really only for its name and summary. I could also have omitted the backwards migration or make it a no-op, I figured it was better to have a real one for local development.
There was a problem hiding this comment.
I think the backwards compat is good for the migration, just wanted to understand the scope of the impact. I agree it's probably okay. Thanks for clarifying.
| @@ -161,7 +161,7 @@ def test_multiple_objects_with_multiple_translations(self): | |||
| assert set(addon2.translations[addon2.name_id]) == ( | |||
| { | |||
| ('en-us', 'English 2 Name'), | |||
There was a problem hiding this comment.
Oh god how I wish we had enums for locales...
| @@ -279,6 +279,7 @@ def fetch_single_translation(self, obj, field, requested_language): | |||
| translations = self.fetch_all_translations(obj, field) or {} | |||
| locale = None | |||
| value = None | |||
| requested_language = to_language(requested_language) | |||
There was a problem hiding this comment.
It's not clear why this change is here.. could you add some context?
There was a problem hiding this comment.
This was a bug in the way we fetch translations coming from ES, it did not convert the requested language like we do when the translations are coming from the database.
It was revealed by the tests when I changed them from es to es-ES - it would only occur when we're fetching a language with a "regional" variant (xx-XX) that is not the default locale for the add-on.
There was a problem hiding this comment.
Should we have an explicit test for this edge case then 1) to be damn sure it works and 2) to document the edge case itself.
src/olympia/translations/management/commands/process_translations.py
Outdated
Show resolved
Hide resolved
| # | ||
| msgid "" | ||
| msgstr "" | ||
| "Project-Id-Version: messages\n" |
There was a problem hiding this comment.
Is the rationale that it is easier for translators to modify the original spanish translation to variants than to start from scratch?
Also.. it's weird.. it's like did we support the different spanish variants already or is this introducing them. On the one hand, you're adding the locale files ... so they weren't there.. but onb the other, there was already reference to those locales ... can you explain that?
There was a problem hiding this comment.
There were no references to the variants before, I'm adding them. Translator teams have expressed different preferences regarding what to do with the files, but the conclusion we reached when talking to @mathjazz (Pontoon lead) was to "seed" the new locales by copying the old file over and they'd sort them out in pontoon later.
There was a problem hiding this comment.
Got it. Probably worth dumping that in the "context" on the PR for posterity.
See mozilla/addons#15232
The diff stats are scary because I'm adding a bunch of
.pofiles that are copied from the existingesone. You can diff them with theesone 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 thetry_files $uri @frontendamobytry_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
eslocale 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.