Spanish translation

[emlys]

Description

This PR introduces our first translation of InVEST into Spanish:

expected tasks

• Add the Spanish message catalogs
• Remove the logic we used to hide the workbench language setting in production mode
• Uncomment the code that builds message catalogs as part of the setup.py build process

bug fixes

• Refresh the app when the language setting changes to ensure that all content displays in the new language. We decided that users will have to refresh the app for the language setting to take effect. It was more complicated than it's worth to make sure that every affected component re-renders in a new language. In a future PR, I'll add a feature to prompt the user to choose a language when first opening the app.
• Fix a couple of module reloads in ui_server.py
• I'm not sure exactly why, but the small change to module reloading in ui_server.py triggered a weird bug where the test suite would hang indefinitely, on unrelated tests, and only when running most of the tests all together (could not reproduce with an individual test suite). It was fixed by moving the unit registry definition to its own module so that u isn't redefined when we reload spec_utils.
• While debugging that, I noticed that 3 test suites (CBC, CV, and translation) imported the module under test at the top level. That meant that any import errors would crash the whole pytest command, rather than record as a test failure. I moved those imports into each individual test like we do for other models.

small enhancement

We now get the list of supported languages and their localized names from the backend, rather than defining them in the workbench.

notes

I tried to test that the page reloads when the language is changed, following this example, but it didn't work and I didn't think it was that important.

There is also a PR in the works for the user's guide translation, but I don't think those need to be linked to this PR.

Checklist

• Updated HISTORY.rst and link to any relevant issue (if these changes are user-facing)
• Updated the user's guide (if needed)
• Tested the affected models' UIs (if relevant)

[phargogh]

👍 🎉

[phargogh]

I didn't know we could include globs here! Very cool.

[phargogh]

Should the Last-Translator be Patricio's email?

[emlys]

Sure, I don't think any of these fields are required but I'll fill in his email

[phargogh]

I don't recall why my email is here ... @emlys would you like this to be your email? Or maybe we should have it email the software team email list, or else an alias at naturalcapitalproject.org?

[davemfish]

Thanks @emlys , this is awesome. I reviewed the whole thing.

One thing I noticed when testing it out is that the Workbench strings are not translating, and I'm not sure how that is supposed to work exactly. And strangely, there is a test that tests for that, which somehow passes.

Other than that, I just a few minor comments.

[davemfish]

Functionally it's the same, but for consistency across the codebase, how do you feel about using async/await here instead of chaining the .then calls?

I realize we're not 100% consistent on this -- we tend to use .then/.catch for fetch calls such as in server_requests.js (for no particular reason), but I'd prefer to migrate towards async/await.

[emlys]

Sure!

[davemfish]

This is a comment about the test in this block, which didn't actually have any changes...

I think it would be best to mock window.location.reload() also. jsdom has a global window, but I see a console error saying Error: Not implemented: navigation (except hash changes) on the reload call.

Also in that test, it looks like we test that some workbench strings were translated (as opposed to invest strings) and those checks pass despite the browser refresh not happening, which I think makes sense? But if I use the workbench and change the language, I don't see those workbench strings translated. So I'm not exactly sure what's going on there.

[emlys]

If you're not on the latest commit, you might also be missing the message catalog for the workbench strings, hence it's defaulting to English. The translation test mocks the message catalog, so I'd expect it to pass either way.

[davemfish]

@emlys I've confirmed that I have the latest changes, including the workbench message catalog and a fresh install, but I still can't get the workbench strings to translate. I also tried building a production version and don't get the translated strings there either. I confirmed this function is called with the correct & complete messageCatalogPath, so I'm not sure how to debug further.

function loadMessageCatalogs() {
  // load each language's message catalog PO file into an object
  // for easy access when we switch languages
  const languages = fs.readdirSync(`${__dirname}/../static/internationalization/locales`);
  if (languages) {
    languages.forEach((language) => {
      const messageCatalogPath = `${__dirname}/../static/internationalization/locales/${language}/LC_MESSAGES/messages.po`;
      console.log(messageCatalogPath)
      i18n.loadJSON(readMessageCatalog(messageCatalogPath), 'messages');
    });
  }
  logger.debug('loaded message catalogs');
}

[emlys]

This should be fixed now - the language code in the PO file was wrong, resulting in the messages not being used.

[davemfish]

I tried to test that the page reloads when the language is changed, following this example, but it didn't work and I didn't think it was that important.

I agree it's not important to test that. Though I think that basic approach would work if window.location.reload() is a mock function, which I suggested for a different reason in another comment.

[emlys]

Though I think that basic approach would work if window.location.reload() is a mock function

I've spent a few hours on this now and can't get it to work. The mock doesn't work, and the test doesn't pass. If it's important to mock this maybe we can debug it together, otherwise, I don't think it's worth the effort to test.

[davemfish]

I've spent a few hours on this now and can't get it to work. The mock doesn't work, and the test doesn't pass.

@emlys I've been there.

If it's important to mock this maybe we can debug it together, otherwise, I don't think it's worth the effort to test.

I'd be happy to work through it together. I don't think it's important to test whether window.location.reload is called, but right now it is being called during the tests and it's raising a console.error because it's not implemented in jsdom. So I think it's worth mocking just to clean up our jest output. And from there we can decide whether to go further and actually assert anything in the test.

[dcdenu4]

Thanks @emlys, this looks awesome! And thanks Dave for giving this a thorough look and helping debug!

[dcdenu4]

Hey @emlys, I just loaded up the Workbench and tried switching to Spanish. I just had a few quick questions and sorry if they've already been addressed.

• I noticed a capitalization difference in the options, "English" v "espanol". Should that be consistent?
• Are we foregoing trying to translate the File | Edit | View | Window | About menus?
• I noticed for a models input helper text (raster, csv, directory, number, ...) that some are translated and some are not. I was curious how that is determined. For instance, I see both tasa: un decimal de 0 - 1 and number. Just curious, thanks!

So cool to see it in action!

[emlys]

@davemfish I think I finally fixed the window reload mocking issue. I had to delete the object first, and also mock it in another test where the language setting changes.

[davemfish]

@davemfish I think I finally fixed the window reload mocking issue. I had to delete the object first, and also mock it in another test where the language setting changes.

@emlys Thanks for figuring that out! I guess window.location is kind of special in jsdom jestjs/jest#5124