Closed Bug 1370173 Opened 4 years ago Closed 1 month ago
Ability to view adjacent strings to a search result
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.
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.
Priority: -- → P3
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.
(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.
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: nobody → mitchelloliver1991
Status: NEW → ASSIGNED
*This bug has been moved to GitHub.* *Please check it out on https://github.com/mozilla/pontoon/issues.*
Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → MOVED
You need to log in before you can comment on or make changes to this bug.