phetsims / phetsims/rosetta

Make retrieval of string data for translation report more efficient

Open
#481 1 comment 0 reactions 1 assignee View on GitHub

@jbphet is already working on this.

Since Sep 3, 2025.

priority:5-deferred
Dominant language
TypeScript
Stars
3
Forks
3
PR merge metrics
No merged PRs in 30d

Description

To create the translation report, Rosetta has to figure out what strings are used in a sim and then which of those strings are translated for a given locale. The translation information generally exists in several files, including the sim-specific translated strings (e.g. build-an-atom-strings_de.json) and common code translations (e.g. joist-strings_de.json, scenery-phet-strings_de.json, etc.). Currently Rosetta re-requests the common code strings from long term storage - i.e. GitHub - for every row of the translation report, which is basically for every published simulation. That is a lot of redundant information, and we could greatly reduce the time needed to create the report by reusing the common code string information. This would also reduce the number of GitHub requests that Rosetta makes, which would help reduce the probability of running into the throttling issue reported in this issue. I'm thinking we could probably cache the common code information while creating the translation report object for a given locale.

Also, based on the tests I ran to verify this, it appears that Rosetta is also requesting the English string file for every common code repo for every row in the report. I'm not sure why it needs this information at all, though there may be a good reason that I'm not aware of at the moment. Regardless, this info could also be cached.

For reference, here's a screenshot of an abbreviated translation report (we often use this abbreviated format when debugging to save time):

Image

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.