[development] low hanging fruit for Drupal 6: variable defaults

[Gabor Hojtsy]

David Metzler wrote:
>>> 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 

David, you seem like confusing "translating what we have in variables 
already" with "translating things in Drupal with variables". We are 
definitely not solving translation problems with storing translations of 
Drupal stuff in variables.

> 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.

We are about to let the user be able to translate things like "site 
footer", "site slogan", "user welcome mail" and so on, all stored in 
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.

Yes, it is a bad idea to abuse the variables system to store unrelated data.

> 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?

We are about to propose a basic object based translation system, watch 
the issue queue.

> 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');

Please read up on previous discussion about why this is problematic.

Gabor