I have started to work on this JIRA issue:
In it, @darius has suggested the following:
We need to decide the best match for the retire and unretire. Personally I would like deactivate and reactivate . Lets try to find out the best option over here. Your ideas are welcome on this issue to complete this issue.
This has been a longtime in the queue.
I concur with your suggestion and also like deactivate and reactivate. It makes logical sense to me.
So shall we go with this combination?
@darius what do you think? Is the time (2 days) enough to decide this?
Next step is to do some research with implementers/users about which pair of options to go with for retire and unretire
Having this posted here for two weekend days isnāt sufficient to count as āresearch with implementers/usersā (or even long enough to presume that people have read this and thought about it yet).
Iād also especially appreciate any feedback from implementers and not developers like Robby and Iā¦
One thing: I wrote this ticket in 2011, but since they weāve built an entirely new OpenMRS 2.x Reference Application. So, at this point I think we should move this ticket to the RA project in JIRA, and only make these changes in Reference Application 2.x (mainly in the Admin UI module, I think). We shouldnāt make this kind of a sweeping change to the Legacy UI anymore.
For me, it doesnāt matter what itās called, so long as itās consistent (the same terminology is used everywhere). In my quick look at the Reference App, it seems Retire/Unretire are used, so for simplicity, I would suggest just making sure that is used everywhere. Perhaps I feel this way because Iāve already learned what retire and unretire mean. Hearing from some new implementers would be beneficial. @ngoel2 and @jmpango, any suggestions from your perspectives?
Remember, the documentation and screen shots will need to be updated as part of this ticket where changes are made.
This just concerns display text/verbiage, correct, not the change of any underlying DB tables or API methods? Since the webapp is now the ālegacy webappā, are we talking about making the changes there, or just in any reference app UI pages?
I think we should only make these changes in the Reference Application.
Whoops. Sorry for not reading closer. 
I could live with āDeactivate / Reactivateā, but I favor the terms āRetire / Unretireā, since, to me, these better communicates the notion that something that once was in use is no longer in use. āDeactivateā suggests that something was previously activated, which is often not true. Also, āDeactivate / Reactivateā implies something that can simply be toggled between active & inactive states; whereas, āUnretireā more correctly implies itās an unusual action. And, as @arbaughj points out, weāve been using āRetire / Unretireā so it will take less work to ensure weāre consistent.
Just my 2Ā¢.
I could live with keeping Retire/Unretire as terminology, because itās less work.
(But we definitely need to change Void/Unvoid to Delete/Undelete.)
That said, Iād want to get some feedback from someone outside of the OpenMRS bubble as to whether āretireā makes sense in this context.
Iām new, and didnāt really have a problem understanding Retire/Unretire as terminology. It also makes sense from the point of view of āretiringā user accounts. It makes sense to keep it consistent, and I tend to agree with @burke
I kind of actually like void/unvoid, coz ādeleteā has a scary āyou will never see this data againā implication, but thatās just my personal opinion. I got used to void/unvoid quickly and its more consistent with the terminology used in the data model.
For me, Retire/Unretire is part of me.that is the combination that works for me
Looking at the feedback up to now, it is clear that the Retire/Unretire is the terminology preferred by existing and new users. Looking at the user experience point of view, it really doesnāt matter as far as we keep the consistency with these terms.
So shall we move on with changing Void/Unvoid to Delete/Undelete.
Adding my 2cents, though it seems odd to use the term undelete instead of restore, it is more consistent and intuitive to use āUndeleteā in understanding the concept. WDYT?
Retire/unretire is good.
I like delete/restore, as I originally said on the ticket (and not undelete like I said in a comment on this thread)
You may proceed with working on this. Note that, as mentioned in this thread, these changes should be made to the Reference Application, and not to the legacy UI. (I donāt remember if we updated the ticket or not.
-Darius (by phone)
Noted it. I will update the ticket as well.
So I will use delete/restore for void/Unvoid.
Thanks.
Just to note, that Admin UI module seems to be using the proposed terminology already. Or have I missed something. Can someone please clarify?
I went through all the modules used in reference app and verified that the proposed terminology is used everywhere in uis and messages. Please review PRs below. Additionally if we are to back-port these PRs please let me know. Hope we can close this ticket now, unless openmrs-core needs to be updated with this terminology in other languages.
Thanks.
Thanks for doing this, but, unfortunately, I donāt think we want to make these changes to the appointment scheduling moduleāsee my comments on the ticket for more info.
: