[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