Posted by ekes on July 12, 2009 at 2:20pm
| Project: | Active Translation |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
Just basic views 2 integration.
The attached patch (built against HEAD in the module directory - sorry - so you'll need to be in it to run patch -p0 so it creates views directory correctly):
- stops active_translation.module
hook_db_rewrite_sqlfrom altering a views query - adds an active translation relationship to views in the i18n category. Using this relationship and making it Required operates as active_translation normally.
- adds a (default disabled) example of this relationship in use as the view
at_frontpage
This not only has the bonus of being able to switch on and off active translation with views, it makes views aware of the query thus making it possible for it to cache them.
| Attachment | Size |
|---|---|
| active_translation.views-20090712.patch | 7.06 KB |
Comments
#1
this looks good over all some of the comments need to be proper sentences with capital letter and periods though. i think the view should probably be tagged with the module name.
though it brings up a bigger problem with the module, it's using ***CURRENT_LANGUAGE*** as a field name. the problem being that language codes conflict with database reserved works. i'm sure using Icelandic you'll get a column named "is". i won't let fixing that block the views support but it just reminded me of it.
#2
The views replacement is just done by a
str_replaceso it would easy enough to move it to tnid_is (as tnid_***CURRENT_LANGUAGE***) or what ever if the column names were to change.#3
Talking about c&p errors - corrected patch
#4
Has this patch been implemented in the dev release? I'm getting error messages on a multilingual site on a page using a view with a node reference argument. The multilingual options on the node reference argument are turned on. When they are turned off, the error messages disappear, but translations of referenced content are no longer taken in to account.
The error message is as follows
user warning: Unknown column 'n.nid' in 'on clause' query: SELECT node2.nid, node2.vid, node2.title FROM node node INNER JOIN node node2 on node2.tnid = node.tnid INNER JOIN active_translation ON n.nid = active_translation.en WHERE 1 = 1 AND ( node.nid IN (145) AND node.tnid > 0 ) in /Applications/MAMP/htdocs/vem/sites/all/modules/contrib/nodereferrer/views/nodereferrer.views.inc on line 99.#5
The patch isn't in the module no. Any multilingual options therefore I guess are from i18n which is going to be a strange play. Why not try the patch and not the i18n options ;)
#6
Fantastic, patch worked a treat for me. Thanks very much.
#7
It took me a while to workout why I could not create an admin view listing all nodes regardless of language.
Started working on my own fix using a views filter until I saw this patch.
Works for me, Thanks.
#8
There is a problem with relationship handler. It needs to use db_escape_table() on the current language. I run into this problem with the language Chinese. The table column is zhhans and the language code is zh-hans.
#9
I have updated the relationship to use a handler. For some reason WinMerge is giving me errors and I don’t have my Suse machine with me so, sorry I cant give you a patch, but here is the code.
Please note that my views coding experience is limited.
active_translation.views.inc
<?php
// $Id$
/**
* @file
* views 2 integration of active translation
*/
function active_translation_views_data() {
$data['active_translation']['table']['group'] = t('i18n');
// all done by adding the table as a relationship
// could be offered as a base table as well?
return $data;
}
/**
* Implementation of hook_views_data_alter().
*
* Need relationship to node table, probably this as an inner join is
* most common.
*/
function active_translation_views_data_alter(&$data) {
// issue, can we make the join on a different column with a hook?
$data['node']['active_translation'] = array(
'group' => t('i18n'),
'title' => t('Active translation'),
'help' => t('Relate node table to active translations.'),
'relationship' => array(
'relationship table' => 'node',
'relationship field' => 'nid',
'base' => 'active_translation',
'base field' => '***CURRENT_LANGUAGE***',
'handler' => 'active_translation_relationship_handler',
'label' => t('Active translation'),
),
);
}
/**
* Implementation of hook_views_handlers
*/
function active_translation_views_handlers() {
return array(
'info' => array(
'path' => drupal_get_path('module', 'active_translation') . '/views',
),
'handlers' => array(
'active_translation_relationship_handler' => array(
'parent' => 'views_handler_relationship',
),
),
);
}
?>
active_translation_relationship_handler.inc
<?php
class active_translation_relationship_handler extends views_handler_relationship {
function query() {
global $language;
$field = db_escape_table($language->language);
$this->ensure_my_table();
$join = new views_join();
$join->construct('active_translation', $this->table_alias, 'nid', $field, array(), 'INNER');
$this->query->ensure_table('active_translation', $this->relationship, $join);
}
}
?>
#10
subscribing
I'm looking for an alternate to http://drupal.org/project/select_translation as it looks to not be maintained.
I hope this feature request can incorporate Views 3 support.
Thanks!
#11
Taking #9 I've made another patch with slightly more standardized directory and filenames. I've also corrected one of my original un-needed complexities (using the alter hook rather than just putting it into a active_translation part of the views handlers).
I'm leaving this as 'needs review' because of the changes; so if someone has time please do. Other than that this is now pretty well tested I'd say. Trouble with committing it though would be that it will break the assumptions on sites that already have active_translation and views - guess it could be 2.x.
I'll post another version of this to follow up with some useful (but not so tested) relationship handlers for nodequeue and flag.
#12
OK this isn't ready to be committed, just sharing. I've added handlers for nodequeue and flag. I know you can do this by effectively joining on active_translation then joining back on node and then joining nodequeue/flag to this, but my reason for using active_translation is to cut back on these draining joins so this just joins directly to active_translation.
(Oh it's a git patch and I forgot --no-prefix so patch -p1)
#13
I've just worked out that #9 breaks if you are joining the active_translation onto anything other than the base table. A better solution seems to be to just:-
<?php/**
* @file
* Extends views relationship handler to escape the language for the field.
*/
class active_translation_handler_relationship_node extends views_handler_relationship {
function query() {
global $language;
$this->definition['base field'] = db_escape_table($language->language);
parent::query();
}
}
?>
I'm poking other options.
(code is on git://git.iskra.net/drupal/contrib/active_translation too by the way).
#14
the mention of using db_escape_table() on the field names reminds me about #791172: Active translation with Tongan causes SQL errors. Wonder if fixing that there would make the views support easier to add...
#15
Does it still need to go through db_escape_table() as well as getting the lang_ prefix. If it was just the lang_ prefix then it would make the views support much easier, because the ***CURRENT_LANGUAGE*** replacement that already exists would work out-the-box.
#16
@ekes
I would say yes, see comment #8.