[development] low hanging fruit for Drupal 6: variable defaults
metzlerd at metzlerd.com
Fri May 4 18:47:44 UTC 2007
> 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.
Thanks, that helps. I misunderstood what Dries meant by footer, but
isn't this possible simply by passing the result of variable_get
through t()? Or am I missing something? I'm pretty unfamiliar with
I still think the separation is good, but that's my own opinion. I
still maintain a nervousness around the results of variable_get
perhaps being translated without my explicitly asking for it in
code. The choice of the "default" behavior will be important. Or the
work involved in setting up arrays and hooks for every setting I need
to define and tell drupal wether its translatable.
What about providing a variable_get_t call that would automatically
pass this through the new translation API... or am I oversimplifying
Not trying to be difficult, but just trying to understand better the
impact on module developers.
> We are about to propose a basic object based translation system,
> watch the issue queue.
I'll certainly do so.... but doesn't this mean that we're pursuing a
generic solution to translations that could be applied here? Is
there an easy way to watch the issue queue for just this
>> 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.
I've read every post on this topic (hours of reading, but luckily was
sick and had spare time to kill) and perhaps again have
misunderstood. The scope of this discussion has crept a great
deal. If in the end, the patch goes in with the item array syntax,
perhaps we could write some helper functions that would make
something close to the "define" syntax available for module
developers. I'll volunteer to write the functions when we get there :).
More information about the development