902435 - Clean up apps with empty names or empty descriptions

Status: RESOLVED WONTFIX

(Marketplace Graveyard :: General, defect, P4)

Description

[Mathieu Pillard [:mat]]

We have a few hundred apps in production that have empty descriptions or empty name in some locale (usually english) because of bug 891376, bug 894563, and bug 888831 which have since been fixed.

This can cause the developers or admins to be unable to edit basic details for these apps, as long as bug 896466 is not fixed.

We need to come up with a way of removing those empty Translations. We need to be careful though, not to remove Translations, even if they are empty, if they are the only Translation for that field for each affected app.

I ran different queries to check, and it appears that we have (in remora at least, so possibly more in production):
- 286 non-deleted apps with empty descriptions. Of those, many are disabled or not public. If we only consider public ones, that drops to 104. 
- 82 non-deleted apps with empty names. If we only consider public non-disabled ones, that drops to 49.

(There is some possible overlapping between the 2 lists)

I'll come up with the SQL query to clean them up. This is something that I prefer to check manually instead of automating, we need to be extra careful about what we delete.

Comment 1

[Andrew Williamson [:eviljeff]]

Attachment: output.txt

apps with an empty description that are public or queued on prod

Comment 2

[Mathieu Pillard [:mat]]

It's more difficult I thought, because of the way our translations are set up.

We are using a MySQL InnoDB "feature" that allows you to have a Foreign Key Constraint pointing to a non-unique field. Because of this, you can DELETE (or UPDATE the id of) translation rows, even if there are other translations in other languages for the same id. The only ways to delete the problematic rows is to:
a) Disable constraint checking before doing it, using django.db.connection.constraint_checks_disabled context manager in python, or SET FOREIGN_KEY_CHECKS = 0 in SQL
b) Set the field on the addon to NULL before deleting the translation and then back to the correct id

The method a) is probably the best, although it scares me to disable foreign key checks, even in a specific script.

Comment 3

[Mathieu Pillard [:mat]]

Turns out it's even more difficult than I thought yesterday, and things already looked pretty grim then.

I have a branch here that almost works: https://github.com/diox/zamboni/tree/delete-translations

I say "almost" because there is another problem: when we fetch translations for a model, we only consider 2 locales: 1) the current_language and 2) the model's get_fallback() method (which, for apps, is their default_locale). 

Therefore, depending on the translation you try to delete you might end up with an empty result when fetching the corresponding model later, just because our code only fetches translations in those 2 locales. I'm not sure how to fix it, so I'm stuck here for now.

Comment 4

[Matt Basta [:basta]]

Sounds like we should put the site into read-only mode (there's a bug for that) before we make this change, yes?

Comment 5

[Mathieu Pillard [:mat]]

Yep. I do hope that the fallback mechanism won't get in the way: If most of the concerned apps have a default_locale set to something other than the locale their empty translations is, it'll be fine. If not, then we'll be unable to remove the translation, and might have to work on a case by case basis to fix them.

Comment 6

[Mathieu Pillard [:mat]]

I merged https://github.com/mozilla/zamboni/commit/b5fd0309cc3683f84eb3d26c5d862b5f4ac9bd6e to allow us to delete individual Translations.

The issue mentioned in comment 3 is still there, though, but at least we made some progress...