Use 'default' instead of '' as undefined default language
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | language system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | hswong3i |
| Status: | won't fix |
For D7 we are now using '' (empty string) as undefined default language, for both locale, path, node and user modules. This issue hope to redefine this empty string as 'default'.
As mentioned in #334687: [DBTNG + XDB] NOT NULL fields using a DEFAULT '' clause , '' (empty string) is not always functioning for all database engine, e.g. Oracle will translate empty string as NULL automatically, which is not ANSI standard. It is also not too meaningful if using empty string as undefined default value. Use 'default' seems to be a possible replacement.
This patch can help #334687: [DBTNG + XDB] NOT NULL fields using a DEFAULT '' clause : once they are integrated, all 4 error message for path simpletest are solved. This patch also tested with all MySQL + simpletest test case and pass.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| language-default-1227088395.patch | 20.25 KB | Idle | Failed: Failed to apply patch. | View details | Re-test |
#1
The last submitted patch failed testing.
#2
We are still not into changing core because Oracle is buggy. I explained in painkstaking detail at http://drupal.org/node/334687
#3
This idea is not something new, locale module also coming with the use of 'default'. With revamp default undefined language as 'default' we can sync with locale's handling in similar coding style and syntax, which are both i18n related.
modules/locale/locale.install (line 326):
<?php'textgroup' => array(
'type' => 'varchar',
'length' => 255,
'not null' => TRUE,
'default' => 'default',
'description' => 'A module defined group of translations, see hook_locale().',
),
?>
modules/locale/locale.module (line 380):
<?php$result = db_query("SELECT s.source, t.translation, t.language FROM {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = '%s' WHERE s.textgroup = 'default' AND s.version = '%s' AND LENGTH(s.source) < 75", $langcode, VERSION);
...
$translation = db_fetch_object(db_query("SELECT s.lid, t.translation, s.version FROM {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = '%s' WHERE s.source = '%s' AND s.textgroup = 'default'", $langcode, $string));
...
db_query("INSERT INTO {locales_source} (location, source, textgroup, version) VALUES ('%s', '%s', 'default', '%s')", request_uri(), $string, VERSION);
?>
includes/locale.inc (line 1675):
<?php$result = db_query("SELECT lid, location FROM {locales_source} WHERE source = '%s' AND textgroup = 'default'", $string);
...
db_query("INSERT INTO {locales_source} (location, source, textgroup) VALUES ('%s', '%s', 'default')", $filepath, $string);
?>
#4
The last submitted patch failed testing.
#5
There's a difference between locale.module providing a default group of language strings - similar to the default contrib module package of 'other' - something which is used in the UI, and changing a convention across the board. If this can at all be dealt with in the Oracle driver, which going by SQLite it should be, then it needs to be done there.