Add Simplified Chinese interface localization

[jianchuanqi]

Summary

This PR adds application-wide interface localization and a complete Simplified
Chinese UI option to Activity Browser.

• Add a JSON-backed translation manager for Activity Browser strings and Qt's
  built-in dialogs.
• Add System default, English, and Simplified Chinese choices under
  Project > Settings...; language changes take effect after restart.
• Localize actions, menus, tabs, tables, dialogs, wizards, figures, progress
  messages, and embedded web/start-screen content.
• Keep internal routing and widget behavior independent of translated labels by
  introducing stable semantic IDs where needed.
• Package translation catalogs in source and wheel distributions.

Why

Activity Browser currently exposes its interface only in English. Adding an
internationalization layer makes the application usable in Simplified Chinese
and establishes a catalog structure that can support additional interface
languages later.

The language setting affects only interface text. Scientific database content,
activity names, impact assessment methods, units, and exported source data are
not translated or modified.

Documentation

• Document the language selector, restart requirement, and translation boundary
  in activity_browser/docs/wiki/Settings.md.
• Add a changelog entry describing the user-facing behavior.

Validation

• python -m pytest -q on the 13 newly added localization test modules:
  97 passed.
• python -m pytest -q tests/actions/test_activity_actions.py tests/actions/test_various_actions.py tests/legacy/test_settings.py:
  27 passed (12 existing pytest-qt deprecation warnings).
• git diff --check upstream/main...HEAD: passed.

The repository's full GitHub Actions matrix should provide final validation on
Python 3.10 and 3.11 across Linux, Windows, and macOS.

Review note

Although this is one cohesive feature, it necessarily touches many UI call
sites because the existing English strings were embedded directly throughout
the application. The PR is opened as a draft so maintainers can advise whether
they prefer the framework, catalog, and call-site migration to be reviewed in
separate stages.

Checklist

• Keep pull requests small so they can be easily reviewed.
• Update the documentation
  • In-code documentation follows the NumPy style guide.
  • User documentation is updated in activity_browser/docs/wiki/Settings.md.
• Update tests.

No existing related issue was found, so no closing keyword is included.

If you have write access (otherwise a maintainer will do this for you):

• Add the feature or ui label.
• Add a milestone for the intended release.
• Request a review from another developer.

[bsteubing]

@jianchuanqi Hi there! Thank you very much for your efforts here!!

The PR you made is an interesting addition to the AB. Here some of my thoughts:

• you have made the PR for the "main" branch. However, this has become more of a legacy branch (it is just not yet name like that). The development is happening on the "major" branch and the branch that is deployed as "AB3" is the "beta" branch. So unless you explicitly want to stick with AB2 (only bw2 compatible, not bw2.5), you'd have to refactor this to fit the "major" branch.
• your changes are MASSIVE (138 files, 7.5k additional lines of code) - I would rather like you to start with a proof of principle so we can clearly understand the design principle of having support for several languages. Do you think you could (if you target AB3) make a branch which has minimal changes to "major", showcasing how you would deal with different types of UI text?
• I would like to thorougly review this before committing it to AB3. I do see the value of supporting several languages. But I also see the additional overhead that may create in adding functionality and maintaining code. For example, I don't speak Chinese - so who will be updating any text changes or additions for the Chinese version in the future? I am slightly hesitant to include something that I cannot maintain in the future...

Happy to talk more about this to find the best solution!

[jianchuanqi]

Thanks, this is very helpful. My intention is to support AB3, so I agree that main was the wrong base. I will keep this PR as a reference implementation and prepare a new, deliberately small draft PoC based on major, rather than trying to retarget or rebase the full patch.

The PoC will cover only a few representative cases: a static action or label, a formatted dialog message, a table/model header, and a translated display label separated from its stable internal ID. Scientific and database content will remain outside the translation layer.

I can act as the initial maintainer for the Simplified Chinese translation. English will remain canonical, and missing or unfinished translations will fall back to English, so normal development and releases will not be blocked. CI will fail only on structural problems such as invalid catalogs or placeholder mismatches, while translation coverage will be informational.

I plan to use the native Qt TS/QM translation workflow unless you would prefer another direction. I will link the new draft PoC here once it is ready.