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

David Metzler metzlerd at metzlerd.com
Fri May 4 20:22:05 UTC 2007


> Most of what Drupal returns now is translated. Drupal has a concept  
> of a language used to display a page. The default will probably be  
> that variable_get() and friends return values in the page language  
> used. We intend to support asking for values in other languages on  
> demand.

This is precisely what I was concerned about.   Although is is  
certainly common to use variables for storing things like site  
slogans, site names, etc.  Much of the data stored in variables is  
not textual in nature and is not in fact designed to be alterable,  
regardless of the language used.  What does it mean to translate an  
array, or an integer for example?

There are countless examples of code that tests for text values,  
radio buttons, array selections, etc.  I would hate to see those  
chunks of code start misbehaving because the values they were testing  
against in If's,  foreaches, cases, etc.  got translated, cause the  
coder didn't know better and didn't test for a translated case.

I realize that we could put the burden on the developer to make sure  
to intialize all their data structures appropriately as  
NON_TRANSLATABLE, but it seems like a lot of overhead when writing  
code, (Hey all I wanted was a persistant configuration variable).   
I'm concerned that this will make contrib modules less stable in the  
end.

Wouldn't it be better to store translatable text strings somewhere  
else entirely? And then make site slogans, etc store data in these  
locations instead?  Make the data domain allowed to be stored in  
these cases be textual only (not serialized structured data).

I don't want to clog the airwaves, so I'll humbly step out of this  
debate if I'm alone in this concern.

Dave

P.S. I get the problem with define now.  Thanks for the synopsis.





More information about the development mailing list