Description: In Writer 25.8, there's a new "reinstate" feature, described in this blog post: https://vmiklos.hu/blog/sw-redline-reinstate.html Nothing wrong with the feature itself, however the word "reinstate" is being used in a misleading way in UI strings. Normally, if something is reinstated, it is being restored to a previous state or position: https://en.wiktionary.org/wiki/reinstate Strings like "Reinstate Track Change" sound like the meaning is "restore the change to its original state". The actual meaning as described by the blog post is "decline the change and restore the document to its original state, while also preserving the change". I'm not sure if this kind of functionality can be described using just one word, but maybe "reject and retain" would be a reasonably short yet more easily understandable replacement for "reinstate" in this case? Steps to Reproduce: 1. See https://translations.documentfoundation.org/search/libo_ui-master/-/en/?q=reinstate&sort_by=-priority%2Cposition&checksum= Actual Results: The word "reinstate" is being used in a way opposite to what one would normally expect. Expected Results: Succinct, yet more descriptive terminology is used. Reproducible: Always User Profile Reset: No Additional Info: n/a
Hmm, kind of agree. 'Declined' with prejudice, i.e 'Dropped', as opposed to 'Rejected' but kept for tracking. The 'Reinstate' labeling suggests an action that could be reversed. Rather than its actual rejection.
I'm not a native speaker; the reinstate naming is meant to refer to the restored original state after you reject/reinstate a delete. I agree it's harder to understand it when you would reinstate an insert. Perhaps add a tooltip to give more information? There are 116 references to reinstate in the code by now, so renaming the actual UNO command would not be ideal.
(In reply to Miklos Vajna from comment #2) > I'm not a native speaker; the reinstate naming is meant to refer to the > restored original state after you reject/reinstate a delete. I agree it's > harder to understand it when you would reinstate an insert. The problem is that strings like "Reinstate Track Change" sound like it's the change that's being reinstated (instead of the state of the document). "Reinstate the original state of the document while preserving the change" would be an unambiguous description (if I understand the feature correctly), but that's a bit too long for a UI string. So I wonder if we could have UI strings that are not overly long, but still describe the feature correctly. > Perhaps add a tooltip to give more information? We could do that, but let's see first if we could come up with a succinct term. > There are 116 references to reinstate in the code by now, so renaming the > actual UNO command would not be ideal. I think usually when user-facing strings change in LO, the developer-facing names in the code are not changed. But that's really up to the developer(s) to decide.
Thesaurus comes up with repudiate, refuse, decline, discard... but I don't think any other word makes the situation more clear. "Reject and Retain" (isn't this kind of an oxymoron?) sounds good after pondering a while over the topic but I doubt it helps casual users.
Brainstorming a bit; not a native speaker. I admit quite a number have some biblical connotation. Or being loaded in a different way, like: resuscitate Revert [change with history] Revive [change with history] Resurrect [change with history] Reinstitute [change with history] Resuscitate [change with history] Restore [change with history] Resurrect appears to describe the action pretty well, I think. And I expect it to be translatable too..
(In reply to Telesto from comment #5) > Brainstorming a bit; not a native speaker. I admit quite a number have some > biblical connotation. Or being loaded in a different way, like: resuscitate > > Revert [change with history] > Revive [change with history] > Resurrect [change with history] > Reinstitute [change with history] > Resuscitate [change with history] > Restore [change with history] > > Resurrect appears to describe the action pretty well, I think. And I expect > it to be translatable too.. I don't think we can "resurrect" a change unless we "kill" it first. Anyway, I find that kind of language a bit over the top, although there's of course precedent in Unix for "killing" processes...
(In reply to Heiko Tietze from comment #4) > Thesaurus comes up with repudiate, refuse, decline, discard... but I don't > think any other word makes the situation more clear. "Reject and Retain" > (isn't this kind of an oxymoron?) sounds good after pondering a while over > the topic but I doubt it helps casual users. Perhaps "Decline and Retain" would sound less oxymoronic? OTOH, I think there's a point to be made for emphasising the commonalities between "Reject" and the-function-currently-known-as-Reinstate: "Reject" = Decline the change, restore the document to original state, discard the change. "Reject and Retain" = Decline the change, restore the document to original state, retain the change. I think it will be helpful if we use terms that make it clear that the two functions are closely related.
(Caveat: I am basing this comment on the blog post description of the feature) "Reinstate" is simply an incorrect, and quite confusing description of this action: Reinstatement takes something that had been unstated (stripped or deprived of office, rank, state, status), and "instates" it once again (restores its office, rank, state, status). In our case, we don't have a binary of "with state", "without state", since content can be: * In the document with a proposition to change it * A proposition of change to the document * Non-existent/gone (and that's ignoring the fact that a change can itself be an addition, deletion, or modification with no addition or deletion) So, please confirm this bug! ----- Now, what shall we use instead? Definitely not a synonym of "reinstate". In fact, this action can be achieved by accepting the change, then undoing it while tracking. So, here are several ideas, although I'm not thrilled about any of them: * "Accept then Suggest an Undo" * "Accept then Suggest Undo" * "Accept then Undo" * "Accept & Track Revert" * "Accept & Track Reversion" * "Accept & Revert" THe following suggestions are vague, but - they have the benefit of quite difficult to misinterpret, which is a plus: * "Invert suggestion" * "Invert change" * "Flip to reversion" * "Invert" --------------------------- Comments on other suggestions: (In reply to V Stuart Foote from comment #1) > 'Declined' with prejudice, i.e 'Dropped', as opposed to 'Rejected' but kept > for tracking. Ah, but the change is more accepted than it is declined. (In reply to Heiko Tietze from comment #4) > "Reject and Retain" (isn't this kind of an oxymoron?) sounds good > after pondering a while over the topic but I doubt it helps casual users. Same point as above: This does not reject the change, it _accepts_ the change. But instead of retaining the accepted change, it (In reply to Heiko Tietze from comment #4) > Thesaurus comes up with repudiate, refuse, decline, discard... Which is why we definitely should not use any of those :-( (In reply to Telesto from comment #5) > Revert I think "Invert" captures the semantics better. > Revive > Resurrect > Resuscitate > > Resurrect appears to describe the action pretty well, I think. But nothing has died! What are you resurrecting? And what does it mean to be "alive" rather than "dead"? We don't use that metaphor anywhere w.r.t. track changes. > Restore > Reinstitute But nothing has been lost. This is too close to being a synonym of reinstate. (In reply to Tuomas Hietala from comment #7) > Perhaps "Decline and Retain" would sound less oxymoronic? Same point as in my replies to Stuart and Heiko: We're not declining, we're accepting. "Decline and Retain" for a proposed change would be a no-op. > I think it will be helpful if we use terms that make it clear that the two > functions are closely related. Disagree. What is now "reinstate" is both similar and opposite to "accept" and to "reject" - depending on whether, after the "reinstate", you accept-all changes or reject-all changes; i.e. whether you think of the proposed document or the unaltered document. ------------------------ Other comments: (In reply to Miklos Vajna from comment #2) > Perhaps add a tooltip to give more information? Definitely, but that should happen regardless. > There are 116 references to reinstate in the code by now, so renaming the > actual UNO command would not be ideal. On the contrary, it's important we do so now, before there are 1160 references to "reinstante". (In reply to Tuomas Hietala from comment #3) > I think usually when user-facing strings change in LO, the developer-facing > names in the code are not changed. But that's really up to the developer(s) > to decide. IMNSHO, it's better if this is changed for developers as well, since they are also people and would definitely be confused by this phrase - especially when the UI calls it something different.
Maybe something like: Reject but keep?
(In reply to Telesto from comment #9) > Maybe something like: Reject but keep? Again, it's the opposite of what this does. It's "Accept, but suggest not-keeping".
(In reply to Eyal Rozenberg from comment #10) > Again, it's the opposite of what this does. It's "Accept, but suggest > not-keeping". You mentioned this before in comment 8. However don't grasp why you see/ frame it as 'Accept' Quote; "This action can be achieved by accepting the change, then undoing it while tracking." This is not totally true. If someone else made a change, you accept the change. The record vanishes fro track changes. Undo the change manually by activating Track Changes -> Record and for example retyping the previous. A) you lose the author of the original change B) You didn't truely accept the change; which implied by your action reverting it back manually. From: https://vmiklos.hu/blog/sw-redline-reinstate.html ... if a proposed insertion or deletion is not wanted, then one can reject it to push back on the proposal. So far such an action left no trace in the document, which is sometimes not wanted. Calling reinstate on a change behaves like reject, but with history: it reinstates the original state, with the rejected change preserved in the document. OK: you could say: I liked the previous better, you don't fully reject it when using reinstate. You only want to push back on the change. So 'reverse'. Which would be something like 'reverse and perserve (keep latter as a record)
(In reply to Telesto from comment #11) > A) you lose the author of the original change > B) You didn't truely accept the change; which implied by your action > reverting it back manually. But you have truly accepted it: After this action, the document has the change applied and integrated. The change back is just a proposal now.
Just another use-case if that helps: I think reinstate isn't too hard to understand if you focus on the delete redline case. A text was proposed to be deleted, so give me a UI which will create the opposite insert redline. A workaround to do this in Word is: reject the delete, select the text, copy, undo, go after the redline, insert. Reinstate is meant to allow not doing this workaround. (And then the opposite for insert, but that's easier to work around.) I appreciate if the naming of this is tweaked at a UI level and the rest is not changed, so people can start storing the uno command name in document macros, etc.
(In reply to Miklos Vajna from comment #13) Let me first say that this is quite the useful feature when editing. Thanks :-) > I think reinstate isn't too hard to > understand if you focus on the delete redline case. A text was proposed to > be deleted, so give me a UI which will create the opposite insert redline. A > workaround to do this in Word is: reject the delete, select the text, copy, > undo, go after the redline, insert. But that's the long workaround. The short workaround is: Accept the deletion, type in the deleted text - done. (Yes, of course for that to happen you need to be able to type it in, so it might not be so easy, but the point is that it's two steps.) > I appreciate if the naming of this is tweaked at a UI level and the rest is > not changed, so people can start storing the uno command name in document > macros, etc. But that's exactly the reason why the name _should_ be changed, so that people won't start using the wrong name all over the place.
bypass? pass over? passthrough?
(In reply to Alfio Littletree from comment #15) > bypass? > pass over? > passthrough? Can you elaborate on the rationale for those?
(In reply to Eyal Rozenberg from comment #16) > Can you elaborate on the rationale for those? Sure. I was thinking the tracking as a path, where the document is driven by its authors. > > bypass? > > pass over? > > passthrough? The document go past the last change. It do not remove the change, simply go ahead, go over the obstacle that was bringing it in a new direction. The words "over" or "ahead" make me think of many of the comments I read here. I hope I didn't disturb you, I just wanted to add three proposals to the brainstorming.