Translations should be cached, at least for a few minutes in volatile memory
Categories
(Firefox :: Translations, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox123 | --- | fixed |
People
(Reporter: yumpusamongus, Assigned: gregtatum)
Details
Attachments
(4 files, 1 obsolete file)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
Bug 1869766 - Do not dispatch language state changes when nothing changes r?#translations-reviewers!
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
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.).
Comment 1•1 year ago
|
||
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.
Assignee | ||
Comment 2•1 year ago
|
||
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.
Assignee | ||
Updated•1 year ago
|
Comment 3•1 year ago
|
||
Marking this enhancement request as "NEW" to allow the engineering team to consider whether they will implement the suggested change or not.
Assignee | ||
Comment 4•1 year ago
|
||
Updated•1 year ago
|
Assignee | ||
Comment 5•1 year ago
|
||
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
Assignee | ||
Comment 6•1 year ago
|
||
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
Assignee | ||
Comment 7•1 year ago
|
||
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
Assignee | ||
Comment 8•1 year ago
|
||
Updated•1 year ago
|
Comment 10•1 year ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/f5d754663499
https://hg.mozilla.org/mozilla-central/rev/4466f28a3221
https://hg.mozilla.org/mozilla-central/rev/39dff9a7c740
https://hg.mozilla.org/mozilla-central/rev/31a4b1b64ac0
Description
•