Closed
Bug 1216546
Opened 9 years ago
Closed 8 years ago
[translate] Optimize loading a large number of entities
Categories
(Webtools Graveyard :: Pontoon, defect, P2)
Webtools Graveyard
Pontoon
Tracking
(firefox44 affected)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox44 | --- | affected |
People
(Reporter: mathjazz, Assigned: jotes)
References
Details
With bug 1215109, people will be able to load all/approved/untranslated/what-ever-filter strings for a particular project in a translate view: https://bugzilla.mozilla.org/show_bug.cgi?id=1215109#c5 That means possible get-entities/ request timeouts for huge projects (Firefox Aurora > 10.000 strings). So we should figure out a way around this. And even currently, some resource files (in AMO, SUMO or Marketplace) contain over 2000 strings which take a lot of time to load. One solution to this is paging of course, but that means refactoring of pretty much everything (search, filters, in-page translation). I suggest we first try with a simpler approach by splitting get-entities/ into several request, so that only first N (50? 100?) strings are loaded initially, followed by the rest in another or several requests. During these requests we'd have an indicator telling us strings aren't fully loaded yet. NB: this should only affect a few files and project-wide filters in a few projects.
Reporter | ||
Updated•9 years ago
|
Summary: [translate] Loading a lot of entities → [translate] Optimize loading a large number of entities
Comment 1•9 years ago
|
||
I think we shouldn't try and avoid the "refactor everything" part of this because having a giant 10k long list of entities in the sidebar isn't usable as a user nor performant as a webpage. I think this is a good candidate for a painful "okay, really, let's sit down and reconsider instead of just making it work okay" bug to get us to actually reconsider the design/UX.
Flags: needinfo?(mkelly)
Reporter | ||
Updated•9 years ago
|
Priority: -- → P2
Reporter | ||
Comment 2•9 years ago
|
||
True that. So instead of loading all strings, we should only load the first N. (We can start with a higher N (e.g. 1000) and then decrease if it proves to be working fine.) Once the user scrolls up and down the entity list, new strings get loaded and the ones on the other end get removed for performance reason. That will require changes to entity list filtering and search, so that it's not only performed on the client side but also with entities that are not currently loaded.
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → jot
Comment 4•8 years ago
|
||
Commits pushed to master at https://github.com/mozilla/pontoon https://github.com/mozilla/pontoon/commit/74a3d50a97cd4f31274eeffdc03d1ee2f1503dd4 Fix bug 1216546: Progressive loading of entities * Only load first 50 entities in the entity list * Load the rest on scroll * Removes Search tab from the Parts menu and locale-project page. * Adds All Resources menu entry instead. * Removes client-side filters and search. * Triggers search only if value changes. * Don't show out of date editor content on search and filter. * Focus iframe properly so history navigation doesn't trigger in the iframe. Co-authored by @jotes and @mathjazz. https://github.com/mozilla/pontoon/commit/798aec2313c87a59d29f012cc20a6f519b5d99e9 Merge pull request #366 from mathjazz/bug-1216546-frontend Bug 1216546: Progressive loading of entities
Updated•8 years ago
|
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Updated•3 years ago
|
Product: Webtools → Webtools Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•