"Translations Block" does the same thing as the "Language Switcher" Block
sobaboy - October 1, 2007 - 15:25
| Project: | Internationalization |
| Version: | 5.x-2.1 |
| Component: | Code |
| Category: | task |
| Priority: | minor |
| Assigned: | Unassigned |
| Status: | won't fix |
Jump to:
Description
The code for the Translation Block in /modules/i18n/translation/translation.module is the same as the Language Switcher block (/modules/i18n/i18n.module).
Which means it ignores whether there is an association existing between the node and a translation in another language before displaying the link.
This issue also exists for Internationalization 4.7-1.0 and 4.7-dev
#1
The code is not exactly the same.
In Translations block, from the translation sub-module of i18n:
$blocks['content'] = theme('item_list', translation_get_links($_GET['q'], empty($query) ? NULL : $query));In the Language switcher block:
$blocks['content'] = theme('item_list', i18n_get_links($_GET['q'], empty($query) ? NULL : $query));</coded>
The difference is that the translation block, which is meant to look exactly like the Language switcher block (and this surely confuses every person who uses i18n), calls <code>translation_get_links
i18n_get_links.That said, I can't verify what the difference in practice is between the different code.
#2
The reason I came here is that, trying to retheme Translations block function to not show the flag, and coming to the sad conclusion that I would need to recreate it, I noticed that the code commenting was inaccurate (copy-paste error). Since it is probably the reason sobaboy thought the code itself is the same, this minor task is related enough to post here.
The comment text for the translations block (i18n/translation/translation.module, about line 143-147) is identical to the Language switcher block (from which it was undoubtedly copied) in i18n.module:
It should read something like "This is a block which looks like the language switcher provided by i18n module but also links to translations when available."
I can roll a patch if that wording looks good (taken from the admin help).
#3
removing the path to the language icons on /admin/settings/i18n will not output the image tag and therefore not display the flags.
The link is still there though.
#4
Thanks, that's a nice quick fix.
As for the topic of this thread, do you agree it's a minor code comment change that's needed or is there an issue with the functionality?
#5
I would agree that its a very minor change in a comment. Seeing as most people don't delve into the code, a fix for this will take a while to be done most likely. Either way it doesn't affect any functionality.
As for your flag issue, the correct way to do it is to override the i18n_link function in template.php. This allows you to then fully customize what information is outputted.
Try this code:
<?php/**
* Override translation links block output
**/
function yourthemename_i18n_link($text, $target, $lang, $query= NULL, $fragment = NULL){
$output = '<span class="i18n-link">';
$attributes = ($lang == i18n_get_lang()) ? array('class' => 'active') : NULL;
$output .= l($text, $target, $attributes, $query, $fragment, FALSE, TRUE);
$output .= '</span>';
return $output;
}
?>
Just change "yourthemename" to the name of your theme.
#6
I think I am expecting the Translations Block to do something it's not designed to do.
from http://drupal.org/node/70187 :
If you activate both to see what the difference is, there isn't much except that the Translations block will give url aliases instead of node numbers.
I was expecting the Translation block to be a more restricted list of only links to translated versions of this node. Also, that it would not show the current language.
When you look at what the code that the i18n_block and the translation_block call, i18n_get_links and translation_get_links, repectively, the code is essentially the same code except the translation_get_links will pass translation_url($path, $lang) instead of the plain $path to i18n_path.
from i18n.module
<?php/**
* Function i18n_get_links
*
* Returns an array of links for all languages, with or without names/flags
*
* @param $path
* Drupal internal path
* @param $query
* Query string
* @param $names
* Names to use for the links. Defaults to native language names
*/
function i18n_get_links($path = '', $query = NULL, $names = NULL) {
if($path == i18n_frontpage()) {
$path = '';
}
$names = $names ? $names : i18n_languages('native');
foreach (array_keys(i18n_supported_languages()) as $lang){
$links[$lang]= theme('i18n_link', $names[$lang], i18n_path($path, $lang), $lang, $query);
}
return $links;
}
?>
from translations.module
<?php/**
* Returns an array of links for all languages
*
* @param $path
* Drupal internal path
* @param $query
* Query string
* @param $names
* Names to use for the links. Defaults to native language names
*/
function translation_get_links($path = '', $query = NULL, $names = NULL) {
$current = i18n_get_lang();
$names = $names ? $names : i18n_languages('native');
foreach (array_keys(i18n_supported_languages()) as $lang){
$url = translation_url($path, $lang);
$links[]= theme('i18n_link', $names[$lang], i18n_path($url, $lang) , $lang, $query);
}
return $links;
}
?>
I don't see that there is enough of a difference between the two blocks.
I think the Translation block could be come the Language switcher block and the Translations block would be come like is something like the "Links to node translations" option in /admin/settings/i18n/translation which places a set of links to translated nodes related to this node available as a block with options to show flags, language in default language, and/or language in native characters. And it should make an excellent espresso too. :-)
#7
The way the two blocks (Translation and Language Switcher) should be used, in my experience, is as follows:
1. Language Switcher: active on ONLY the front page
2. Translations: active on every other page, EXCEPT the front page
If you follow this, you should have no problems. I do this on all my multilingual sites and everything works perfectly. I will concede that the documentation might explain things a bit more clearly, and for those people that delve into the code, the comments for the two functions should be corrected. However, changing the functioning of the two blocks, or merging them into one is unlikely to happen at this point in time. Maybe things will change in D6, but that's for the future :)
#8
I am going to close this marking it as wontfix.
I modified i18n-5.x to work the way I wanted it to.
I have a site with 11 languages. 1 primary, 1 secondary and 9 tertiary languages.
I would say 70% of the content is in the primary language only, 10% in primary and secondary, 18% in the secondary language only, and a very small set of pages are available in the primary, secondary and tertiary languages.
i18n works great out of the box if you have a site where the content is represented in all available languages. This is not the case for this site.
I commented out the session language stuff and removed language specific path prefixes as well as writing a quick and dirty block to show links to ONLY available translations of a node.
Given what I have seen in Drupal 6, which has improved options for i18n, the chances of fixes for Drupal 5.x are slim.
I would like to thank you all for your time and suggestions.