Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Hi,
I am helping the Spanish group in the localization server. The revamped user interface is good but I found it rather slower than the previous one due to one simple issue:
- Before: Whenever I moderated/modified or added a translation, all I had to do then was pressing the ok (ditto mark) button next to the item and then it went approved (or erased if I pressed the erase (x) button).
- Now: Whenever I do any of the aforesaid operations, I have to navegate till the bottom of the page to 'save changes'.
As it comes that I work with pages of 30 items (I found this much more comfortable) and I work the issues one by one, this 'Now' behaviour is a nuisance that is getting on my nerves as it slows the work a lot.
So... the question is: Would it be possible adding (or recoverging) the two buttons (ditto and x) per item that we had before?
Thanks in advance.
Gustavo (Posting from Madrid, Spain).
Comments
Comment #1
gábor hojtsyWhy are you trying to submit each one by one and not going through the page and then submitting the whole stuff?
Comment #2
Anonymous (not verified) commentedHi, Gabor,
Some reasons:
1. Unreliable connection. I hate been working through a whole bunch and then losing the job because of a connection failure.
2. Intrinsecal nature of web Interface I work marking issues than sometimes are 'on the other page'.
3. Personal workflow I like working this way... I jump bewteen items because they are related but not placed near... I select first easier items until I reach the difficult ones... I chose one term and then I revise its presence through a whole set of projects...
4. Ease of work (usability) Whatever the reasons above, be they personal or objective, I have found I work much slower having to displace so much instead of clicking the nearest button.
To sum it up: Having these buttons do not reduce usability. Lacking them reduce it (at least for me). Besides: They were there before.
I know any change in the interface is loading more burden upon those in charge and I am sorry and aware of that. I would not do it really if I would not miss them a lot.
Thanks.
Gustavo
Comment #3
gábor hojtsyIf you are so afraid of losing data, then why are you going through 30 strings at once? Any string edits you make will not be saved until the form is saved either? The current workflow just unifies how your modifications are saved instead of doing two things differently.
Comment #4
Anonymous (not verified) commentedLosing data is not the most important issue. It's just the one I placed first.
Most important issue (really) is displacing so much. And as for 'Why do you use 30' the reason is simple: I keep an eye on more items and they usually relate in meaning-use.
But do not think, please, that I translate one-by-one. I mean three, seven, one... I do it in-between my job and sometimes I have some spare minutes. That means I have to work for Drupal in short but frequent spans.
May I ask if it is so difficult to regain those buttons? (I was not able to collaborate in the new interface as I could not identify myself in the temporary server, otherwise, I'd had mentioned this before).
Comment #5
gábor hojtsyWell, adding in two additional buttons for each string which work differently to the current two buttons (radio buttons to approve strings, red circle to decline string) is adding major UI clutter, duplicating controls on the page. This is evidently not something I'd do on a whim. Feedback on the revised UI was very good and nobody mentioned they'd have issues with the form items being unified in terms of how they save data, and making it possible to undo stuff until you submit the whole page. This is how most user interfaces work in Drupal including block/menu/etc. ordering, Views UI, etc, so I think this is what people expect when going back and forth between different Drupal UIs.
All-in-all, I think more general feedback would be useful here, since I've not heard this from others, and obviously major UI changes are better done when discussed wide open (as we did with the current UI).
Comment #6
Anonymous (not verified) commentedOh, well. I'll hope and pray for more general feedback in these sense with my fingers crossed then. ;)
Thanks, Gabor.
Comment #7
cburschkaCouldn't the form optionally submit in the background when a radio-button is toggled? I admit I haven't seen the interface in question, but large forms usually get a lot easier to handle with a bit of jquery/ajax.
This way, the UI controls would remain unchanged, but the form could still be automatically saved.
Comment #8
gábor hojtsy1. What's the user expectation about a form? What would people using the forums ordering UI and the Views UI expect of this form?
2. Should we immediately drop their data if they accidentally click on something? In the previous UI, you'd need to specifically request a list of suggestions to show and then click on an AJAX handled button to approve or decline a string. In this UI, all suggestions are shown by default, so the potential for accidents is much higher.
Comment #9
gábor hojtsyMoving to the right project.