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

[Gabor Hojtsy]

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 
>> 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 translate 
> API's.

t() is not fitting for translating user defined values. There are 
multitude of problems with using t(). Here is some starter: 
http://groups.drupal.org/node/1827

> 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.
>>> define('EXAMPLEMODULE_MYVALUE','www.example.com');
> 
> 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.

Gabor