Prior to Summer '14, you could use the sidebar loading trick to inject JavaScript, but with this feature being removed, you'll have to rely on another mechanism.
Personally, if you're really hung up on the delete button showing some sort of confirmation dialog, I would suggest you create a Visualforce override. This gives you control over what's shown. Such an override might look like this:
<apex:page standardController="Account">
<apex:form>
<apex:pageMessages />
<apex:pageMessage severity="confirm" summary="Are you sure?" detail="You are about to delete this account. Are you sure you want to do this?" />
<apex:commandButton action="{!delete}" value="Delete" />
<apex:commandButton action="{!cancel}" value="Cancel" />
</apex:form>
</apex:page>
Then, assign it to the Delete button as an override, and they'll see the screen and have to confirm their choice. You can show whatever you want here, as it is Visualforce.
Using a trigger would show an outright error, preventing deletion entirely, which may not be ideal, and overriding the entire detail page just to add a confirmation dialog is not desirable either, for a variety of reasons (mostly being a waste of time, and making maintenance more expensive in terms of time).
Response to Edit
Since you are trying to prevent deletes, use a Visualforce page that attempts to delete, catches any errors, and displays them in a pretty format if any errors occur. This will let you reuse what you've already written. Or, you could have the Visualforce page check the condition, and show the error instead of even attempting to delete, but this is duplicating code.
Edit
Code example that shows the design to use:
<apex:page standardController="Account" extensions="accountDelete" action="{!deleterecord}">
<apex:pageMessages />
</apex:page>
And the extension:
public with sharing class accountDelete {
apexpages.standardcontroller controller;
public accountDelete(ApexPages.StandardController controller) {
this.controller = controller;
}
public pagereference deleteRecord() {
try {
delete controller.getRecord();
return new pagereference('/home/home.jsp');
} catch(exception e) {
apexpages.addmessages(e);
}
return null;
}
}
You can't call {!delete}
directly because of the override, plus we're trying to catch the error, so you need a bit more code to support it.
Also, you'll want to spruce this up a bit, perhaps with a link back to the record, etc. Here's a screenshot of the code in action:
I agree it is curious there is no obvious way to make this appear in the UI. So for now it is workarounds.
Visible is easy. A workaround could be to create a formula field that took the Lat/Long values and simply displayed them in string format.
TEXT(BillingLatitude) & " , " & TEXT(BillingLongitude)
To have them editable, there are a few ways, such as inline visualforce pages. But maybe a nice clean way would be link to a visualforce page and edit there. In this instance, a basic edit page might look as follows:
<apex:page standardController="Account" >
<apex:form>
<apex:pageBlock mode="edit">
<apex:pageBlockButtons>
<apex:commandButton action="{!save}" value="Save"/>
<apex:commandButton action="{!cancel}" value="Cancel"/>
</apex:pageBlockButtons>
<apex:pageBlockSection>
<apex:inputField value="{!Account.BillingLatitude}"/>
<apex:inputField value="{!Account.BillingLongitude}"/>
</apex:pageBlockSection>
</apex:pageBlock>
</apex:form>
</apex:page>
Then you would change the formula field to add a link as follows:
TEXT(BillingLatitude) & " , " & TEXT(BillingLongitude) & " " &
HYPERLINK("apex/AccountGeolocation?id="&Id&"&retURL=%2f" & Id ,"(Change)", "_self")
And that gets you page flow that mirrors the user experience for editing ownership, and record type:
There are certainly other bells and whistles you might want to add. For instance you could stick some Javascript in your geolocation page to use the geo api and get it from the device the user is using. But this should get you started.
Best Answer
No, unfortunately it's not possible without using workarounds described here: End of javascript sidebar workarounds? Note that these kind of workarounds are not supported by Salesforce and are likely to break in future versions.
The Standard Edit is very restrictive and less customizable than the View is - that's one reason some of us still use the workarounds.
The best practice approach is: override the Edit page with a Visualforce page.
As a matter of fact the restrictions of the Standard Edit makes it less attractive in my opinion. If you don't like the Visualforce override, you could try to train the users to prefer the View and use Inline-Editing there to update the records. With View+Inline-Edit you have your formulas an much more just at a glance and without any additional effort.