in edit, term editing should ignore those terms with unsupported languages, allowing the user to intentionally be able to save their edits as well as remove those terms at once.

I'm not clear that this is necessary. If we remove the "dead languages" at the time of discontinuing them then it shouldn't be something we need to ignore. If people are trying to make edits that include now-defunct languages I think it might be better that we error and let them know rather than silently ignoring them and leaving them to wonder why the edit they asked for wasn't made; I think this would only happen in the end someone was trying to edit with outdated-data or old code that needs updating.

In T221602#5164087, @Tarrow wrote:

I'm not clear that this is necessary. If we remove the "dead languages" at the time of discontinuing them then it shouldn't be something we need to ignore. If people are trying to make edits that include now-defunct languages I think it might be better that we error and let them know rather than silently ignoring them and leaving them to wonder why the edit they asked for wasn't made; I think this would only happen in the end someone was trying to edit with outdated-data or old code that needs updating.

I agree, if the plan is that before removing support for a lang code that all references to that lang code in the data should first be removed, then if any references to the lag code are left it would probably be better for them to error out so that we notice, rather than hide in the ever growing pile of data.

Since all sub-tasks are in iteration now

Moved back to reduce clutter in iteration board since no sub-tasks are in doing there now