Anyway, let's step back for a bit. It seems like we're trying to solve two problems in this thread:
1. For convenience, we want a central place to define a variable's default value.
2. Out of necessity, we want a mechanism to let the locale system translate variables that have dynamic content shown on the UIs (i.e. the footer message).
While I agree with what the problems are, I disagree with trying to solve item 2 with variables. variable_get and set are an elegantly simple way of storing configuration data about how your application should behave. If we need a way to translate data for the UI, I think it should be stored in a different place, using different structures. UI's are usually tied to page loads formid and such and as such have different caching needs. Loading a lot of complex meaning onto the basic concept of a variable seems like unnecessary complexity to me. You want to be able to give users the ability to alter much of this translation data as possible, but you don't want them mucking around with variables. I recently created a formdefaults module to hand off the altering of what I felt were translatable UI components to the Site admins. I thought about storing this data in variables, but ultimately decided against it, because I didn't want to intermingle UI data with variables. By the way, I'd love to see if there was a slick way to tie my formdefaults module into a translation system so that it was language aware. Any takers on helping? 1. Seems elegantly solvable using DEFINE and using the normal module namespace conventions. It's also the way most programming languages deal with this simple problem. define('EXAMPLEMODULE_MYVALUE','www.example.com');