And plenty of good old "feed yards" in Hereford.
Indeed, we do quite a bit of work in agricutural sector and have a large tannery management system so such terms our close to our heart. In Australia we call abattoirs 'Abattoirs' but in New Zealand they call them 'Freezing Works' and in the US you call them 'Packing Plants'. So, even though the base is English, an industry specific lexicon comes into play.
Cheers, Peter
Your example made me laugh....it isn't every day you have the word "Abattoir" posted on a technical web site
As for your question, since you have the need to allow the end-user to change the localization values while in the field, then I would recommend using SQL Server. XML is generally better when the messages will be embedded within the application and will not be changed by the end-user.
We have an application in which nomenclature can be important from the user's perspective, e.g. one man's 'Abattoir' is another man's 'Freezing Works' - both English but different wording for the same entity. If our user's want to get down to this level, and change screen labels and messages, we want them to be able to do so. We do this at the moment by taking all UI text and messages from our database and give the user a maintenance form in which they can change the text they see on screen and in reports.
I presume in SF we could do this if we deployed messaging via either external XML files or SQL tables. Which approach would you recommend?