Closed Bug 1869766 Opened 5 months ago Closed 4 months ago

Translations should be cached, at least for a few minutes in volatile memory

Categories

(Firefox :: Translations, enhancement, P3)

Firefox 120
enhancement

Tracking

()

RESOLVED FIXED
123 Branch
Tracking Status
firefox123 --- fixed

People

(Reporter: yumpusamongus, Assigned: gregtatum)

Details

Attachments

(4 files, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:120.0) Gecko/20100101 Firefox/120.0

Steps to reproduce:

Interact with a translated site in a way that requires frequent re-loading of the same page or extremely similar pages. For example, you might be using the geizhals.eu motherboard selector tool: https://geizhals.eu/?cat=mbp4_1700&xf=2897_5 and changing the filter parameters.

Actual results:

Every time I alter the filters, my CPU cranks for many seconds while the same German text is translated to English, element by element.

Expected results:

There should be a small cache of translated texts so that recently-translated texts don't have to be translated again. The user should not have to wait for the same page to translate over and over, and energy should not be wasted doing so.

I don't know how much context the translator uses, but it obviously can't be more than a single HTML element because I can watch them being switched in real time, and pages often contain many elements with the same text. Plus, it is a common usage pattern to load many pages in a short time that contain identical texts (headers, labels, forum signatures, etc.).

The Bugbug bot thinks this bug should belong to the 'Firefox::Translation' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Translation

I was literally thinking about this this morning too. We can probably cache all the translations in the translations engine worker, which lives on a timeout anyway. We can just cache all the translations there, and wait for it to be removed.

It would be as simple as doing const cachedTranslations = new Map() and then when getting a new translation request, check the cache first. The rest of the timeouts should handle clearing it out in a reasonable amount of time.

Priority: -- → P3

Marking this enhancement request as "NEW" to allow the engineering team to consider whether they will implement the suggested change or not.

Severity: -- → S4
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → gtatum
Status: NEW → ASSIGNED

This is a drive-by fix that was causing me unexpected behavior. I fixed
the underlying cause of a test failure, but really these setters should
be a noop if nothing changes.

Depends on D197005

Engine status reporting only happened on the first translation. When
cached translations are used, it's easy to not ask for a new
translation. This makes the URL bar think the engine is never ready.

Depends on D197006

This passes all of the existing tests, but would be hard to test and
mock out all of the caching invalidation behavior. I have manually
tested small cache sizes and short timeouts to verify the behavior
works. The existing tests pass. I believe this should be sufficient.

Depends on D197007

Attachment #9371175 - Attachment is obsolete: true
Pushed by gtatum@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f5d754663499
Rework action logging in tests r=translations-reviewers,nordzilla
https://hg.mozilla.org/integration/autoland/rev/4466f28a3221
Do not dispatch language state changes when nothing changes r=translations-reviewers,nordzilla
https://hg.mozilla.org/integration/autoland/rev/39dff9a7c740
Fix engine status reporting r=translations-reviewers,nordzilla
https://hg.mozilla.org/integration/autoland/rev/31a4b1b64ac0
Cache translations in the TranslationsChild r=translations-reviewers,nordzilla
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: