[development] low hanging fruit for Drupal 6: variable defaults
gabor at hojtsy.hu
Fri May 4 19:10:41 UTC 2007
David Metzler wrote:
>> 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
> 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 translate
t() is not fitting for translating user defined values. There are
multitude of problems with using t(). Here is some starter:
> 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 here.
> Not trying to be difficult, but just trying to understand better the
> impact on module developers.
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.
>> 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
Watch this node for multilanguge updates from time to time (quite
frequently :) http://groups.drupal.org/node/3714
>>> 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 :).
Multiple people pointed out that constants are not viable if you have
variables named dynamically. Maybe you missed this point in the thread.
More information about the development