Off the top of my head I'd say it's likely safer to include the Delete button as part of your portal layout . . . it will be on each row. As well, if the button's not in the row you have a whole lot more work to do in specifying the portal row as once the focus is on the button it's no longer on the row. If the "delete master/related" dialog can be trapped with error capturing (not sure . . easy to find out) then you could present a custom dialog that involves more understandable language. Or you could disable deletion of portal rows and instead direct the user to a layout "native" to the portal table and have them make the decision there, where the context is more obvious. There are other ways of re-directing such as disallowing any kind of deletion from a given layout with a portal and redirecting.
Here's how I do it. This script highlights the portal row and displays a custom dialog that displays data from the selected portal row to confirm the delete and the buttons "Yes" and "No". Then, if the user clicks "Yes"in the custom dialog, it deletes the portal row.
If[not IsEmpty ( PortalTO::ForeignKey ) /* There is a line to delete */]
#Highlight the portal row
Go To Portal Row [select; No dialog ; Get (PortalRowNumber) ]
Show Custom Dialog ["Confirm Delete" ; "Delete " & //put expression here with one or more fields from your portal row here & "?"]
If [get(LastMessageChoice) = 2 /* user clicked "Yes" button */]
Delete Portal Row [no dialog]
It still deleted all portal records but that was because of my relationship being cartesian, changed that and it worked bueatifully.