Improve Consistency of terms in registration and information sheet

In the attached patch all the instances of "Physical" are replaced with "Billing" in address type labels.

Tested and working. I'm not sure how many of these strings are still in use, but the patch fixed the label in the patron summary, and it makes sense to change other potential strings for consistency. I used the patch to make a branch, added Alex as the author (but didn't add his signoff), and added my signoff.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/rsteed/lp1068646_physical_to_billing_address

This looks fine, but it seems like both "Physical" and "Billing" are used a lot internally. Does anyone want to argue for unifying on "Physical" instead? I don't feel strongly one way or another, and we should certainly make the display consistent, so I am just trying to solicit views on which way we should be taking this. If nobody speaks up, we should just push in the written change to "Billing".

I'd definitely vote on Physical, we used to have a local customization for that here (appears to have gotten lost in an upgrade, hmm). Mailing and Billing mean the same thing in the general case, because of course you're going to send your bills to their mailing address. The Physical address is the one that proves their residency within your taxing district, contract / service area, etc. There may be special cases where you need additional addresses, that's what the address type field can be used for, because it is likely a niche case.

Another vote for physical. We have towns that only have PO box mailing addresses but span multiple counties so we need to know what their physical address is separate from their mailing/billing address.

As Tim mentioned in his original report, mailing and billing is essentially the same thing. +1 to physical from me too.

A. I think the supplied solution in a simplest and minimally disruptive way improves consistency of terms at the interface level. The patch fixes the bug with the least effort and side-effects, although I agree the result is not perfect.

I do not have a lot of time that I can spend on this issue right now, but if I recall correctly from the time when I worked on it, the replacements made in the patch were the only few instances of the word "Physical" that were used in the front-end interface -- whereas everywhere else the term "Billing" was used, including on the registration interface. The back-end is a bit more of a soup, but in the database corresponding fields in actor.usr are currently labelled "mailing_address" and "billing_address". I think of the database schema as sort of a basic "truth" as a point of reference, which in this case helped me choose the direction.

I suggest we move ahead with this patch as-is or otherwise mark this bug as "won't fix". Maybe I am overanalyzing this a bit, but theoretically, even if someone wants to make a patch with from "Billing" to "Physical" renaming for the patron interface, I imagine that could create far more inconsistencies with other interface areas and possibly additional issues for documentation materials as well. To rename from "Billing" to "Physical" everywhere may require quite a bit of work, perhaps disproportionate to the level of the bug.

B. Considering the lifecycle stage of the current staff client and regardless of the resolution of this bug, perhaps it could be useful to have a comprehensive discussion/analysis of the various current and future (e.g. for academic) library preferences and needs for address types. That discussion may well lead to exactly where we're at now, but with the development of the new web-based staff client this could be a perfect time to (re)evaluate this topic with the idea that any significant changes would be implemented in the new web-based interface. If there is any interest, I am willing to start that discussion in the form of a bug and/or some other medium and to contribute work towards implementation.

Adding the fixedinwebby tag to this since berick's angular patron editor branch has changed the labels in the patron editor to mailing and physical.

Setting this bug to Won't Fix since it is fixed in the web client and the xul client is now deprecated.