Workbench: some text not localized even though we have its translation

[emilyanndavis]

Description

Some text in the Workbench is not being localized even though we have a translation for it. I'm still narrowing down the scope of the problem, but I think it might be an artifact of the model spec refactor—maybe specifically the abstraction of common args (e.g., workspace, suffix) that are now defined in spec.py rather than in each individual model spec.

To replicate

1. Launch the Workbench.
2. Change the language to Spanish.
3. Open the Almacenamiento y secuestración de carbono (Carbon) model.
4. Observe that some arg names and descriptions are in Spanish, but others remain in English. Some of these discrepancies may be due to changes to relatively recent arg names/descriptions (and therefore missing translations), but others are not. For example: Workspace—and its description—are in English, even though we have existing Spanish translations for these strings:

Environment

• InVEST version number: 3.18.0
• InVEST interface (Workbench, CLI, or Python API): Workbench

[emilyanndavis]

I initially addressed this (in PR #2477) by reloading natcap.invest.spec whenever we need to localize text defined in a model spec. This solves the problem (because it forces a call to gettext with each of the translatable strings in common model inputs/outputs defined in natcap.invest.spec) … but it also causes test failures.

I haven't been able to nail down precisely what is causing the failures, but I do know that reloading spec in any of the three relevant locations (cli, ui_server, rst_generator) causes 39 failures in test_validation, and reloading spec in rst_generator causes an additional 3 failures in test_spec. (There are also some Workbench test failures, which I've ignored thus far, under the assumption that resolving the core InVEST failures will resolve the Workbench failures as well.) It's worth noting that all tests in test_validation and test_spec pass when those test suites are run in isolation (either one at a time or both together).

The simplest solution may be to move common model inputs and outputs out of spec and into their own module (e.g., spec_common), then reload that module instead of reloading spec. The downside there is we'd have to update import statements and object references in every model module (including plugins that directly reference common inputs/outputs currently defined in spec). (A tempting alternative would be to avoid updating any model code by importing spec_common into spec, but that would create a circular dependency since anything defined in spec_common would rely on input/output types defined in spec.)

A more involved solution would entail some other flavor of refactoring that allows us to avoid reloading modules at all (see #2473).

In any case, this won't make it into 3.19.0. Any significant refactoring (including the "simplest solution" outlined above) will likely warrant a minor release, so I'll bump this to 3.20.0.

[emlys]

Ooh, I think I remember running into a similar error once...

One unfortunate side effect of reloading a module is that all its objects get redefined - a new object is created with a new address in memory. This means that comparisons using is or isinstance can fail unexpectedly. For example, if the module defines a class A, and then you reload the module and get a second reference to it, instances of the old A are not instances of the new A. This might be a problem for pydantic validation or other assertions in our tests.