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):
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):