Ability to view adjacent strings to a search result
Categories
(Webtools Graveyard :: Pontoon, defect, P3)
Tracking
(Not tracked)
People
(Reporter: stoyan, Assigned: mitchelloliver1991)
References
Details
Attachments
(1 file)
|
421.12 KB,
image/png
|
Details |
reveal surrounding.png
The idea is to have search result that shows few strings before and few stings after it. Pootle has it. While not needed for every day use I find it very convenient at times and critical at others (basically no other way around it). The idea is that related strings are close together in the source file. The classic example is the strings for pagination. You have "First", "Prev", "Next" and "Last" strings filed one after the other. I know that "Prev" and "Next" are together, but currently have no easy way to identify the correct "Prev"/"Next" pair I want to edit, let alone all four mentioned. In a projects like AMO that lacks any kind of searchable meta-data attached to strings it is the only way to navigate to different sections of this 2 file, 2.8k strings project.
|
||
Comment 1•7 years ago
|
||
Having such feature would be very welcome. I'm thinking about the UX. The main question is, how often do surrounding strings in the file contain relevant context information. If most of the time, we should refactor the translate UI quite dramatically to always show surrounding strings. And figure out how many of them should be displayed. If not... Bug 1324936 made me wonder if we could just add a "Reveal string in the file" button. It would take you to the translate view with the current string selected, surounded by all the strings in the file, without any filters or search criteria applied.
|
Reporter | |
Comment 2•7 years ago
|
||
Talking from my experience for most projects surrounding strings are relevant. Yet, this is not a highly demanded feature and I guess UI refactoring would be an overkill having other way of achieving the same result. For me the "Reveal string in the file" button will do the job. The only downside I see is that when string is called by an id it is shifted to the first recordset (first page of results) thus losing its "positional context". I see this as potentially hard to overcome. Probably bug 1324933 can come to the rescue.
|
|
||
Comment 3•7 years ago
|
||
(In reply to Stoyan Dimitrov [:stoyan] from comment #2) > For me the "Reveal string in the file" button will do the job. The only > downside I see is that when string is called by an id it is shifted to the > first recordset (first page of results) thus losing its "positional > context". I see this as potentially hard to overcome. Probably bug 1324933 > can come to the rescue. If we decide to go down this route, we'd also need to fix paging so that the right page is displayed and you'll be able to scroll up and down the list.
|
||
Comment 4•7 years ago
|
||
I added my vote for this bug some time ago but I want to emphasize on the need for some solution here: sometimes bare access keys are listed in the filtered set of strings, which makes the translating experience unnecessarily challenging due to the surrounding string not being present. The current workaround I use is manually removing the filter from the URL and loading the string by ID in a separate tab.
|
Assignee | |
Comment 6•3 years ago
|
||
I would like to be assigned to this, please!
|
|
||
Updated•3 years ago
|
|
|
||
Comment 7•3 years ago
•
|
||
A potential UX:
When any filter or search is applied in the string list, "Reveal surrounding strings" icon appears next to each string (left image). After clicking on it, 2 preceding and 2 succeeding strings are loaded before or after the string unless they are already loaded (right image).
See the attachment for the proposed UI. Note that the styling details still need to be decided upon and finalized.
The benefit of this approach vs. using a dedicated tab/panel is that we don't need to sacrifice additional space in the translate UI permanently. Also, all the available metadata of the string is easily available. The drawback is that one needs to manually request surround strings every time they are needed.
A potential improvement would be to always show an indicator of hidden surrounding strings between the two strings, similar to the GitHub diff view.
|
|
||
Comment 8•3 years ago
|
||
(In reply to Matjaz Horvat [:mathjazz] from comment #7)
The benefit of this approach vs. using a dedicated tab/panel is that we don't need to sacrifice additional space in the translate UI permanently. Also, all the available metadata of the string is easily available. The drawback is that one needs to manually request surround strings every time they are needed.
Some time ago we implemented something similar for translate.evernote.com, but instead of expanding the existing string list, we would overlay (i.e. reveal) surrounding strings on top of the filtered result set.
Here's an example of the feature: https://translate.evernote.com/de/skitch_component_evernote/translate/#search=rotate&unit=7205133
Hover over the unit ID to reveal context strings, optionally holding ctrl to keep the list permanently open. Minimal UI space was sacrificed for this.
|
|
||
Comment 9•3 years ago
|
||
Thank you for sharing this example, Julen. I like it.
Perhaps we should also only add the "reveal" icon to the selected string? And make it always visible in that case?
The challenge of implementing such overlay in the Pontoon UI is that there's no space above the first or below the last string in the list. Additionally, the amount of space per-string is not fixed and can even exceed the height of the string list.
|
||
Comment 10•3 years ago
|
||
*This bug has been moved to GitHub.* *Please check it out on https://github.com/mozilla/pontoon/issues.*
|
|
||
Updated•3 years ago
|
Description
•