Dries Buytaert wrote:
On 03 May 2007, at 14:39, Earnie Boyd wrote:
<?php define('MY_DEFAULT_VALUE', t('my_default_value')); ?>
How about this:
define('site_name', 'example');
function variable_get($name) { $value = db_result(db_query(...)); return $value ? $value : constant($name); }
print variable_get('site_name');
Might get us the best of both worlds? :)
This is possibly good for the defaults repetition problem, yes. As I have said, we will come out with a way to provide locale related meta information about certain Drupal objects, like content types, where we need to know what is possible to get localized. We will need a list of site settings to localize too, so we will need to have a list of site settings defined by a module defined in that module soon. We can have that in hook_locale(), and we can collect the default values by looking at constants defined by the same names. It seemed to be logical to suggest a more universal hook, but whatever simplification comes out of this thread, we will need stuff like: function system_locale($op = 'groups') { switch($op) { case 'groups': return array('variables' => t('Site settings')); case 'objects': return array('variable' => array('site_name', 'site_logo', ...); } } Note for those not following Drupal 6.x-dev: hook_locale() will be used by the new localization solutions we are working on. Different parts of Drupal will define text groups, like 'Content types', 'Site settings' and so on. You can translate objects in these groups, a content type object having a title, a description, a title_label a body_label and so on. We need a little bit of meta information about these objects, so we know what to translate from them. (hook_locale() is already in core, but only implements the groups $op yet! A detailed explanation of how this works, and deep reasoning comes up tomorrow in the form of a patch, so stay tuned :). So we need a list of what variables are for localization, and we need their default values, so localizers can go and change values even if certain settings forms were not submitted by the original administrator before. It would be quite awkward to tell an administrator to first submit all forms where localized stuff is set, even if nothing needs to be modified there, so we have information about the actual values to localize. So anyway, I am just trying to point out that we will need to have a list of at least the localized variables, and we will need to figure out their defaults. If the current implementation stays in Drupal 6.x, we would need to repeat the defaults in a hook_locale() implementation. If PHP constants are to be used, we would need to look them up ourselfs (but admittedly that would not be hard). A list of variables will still be required. So people trying to get rid of such an idea will not be able to achieve their goal, as far as the current state of Drupal localization stands in our development branch. Gabor