Closed (won't fix)
Project:
Internationalization
Version:
5.x-2.1
Component:
Code
Priority:
Minor
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
1 Oct 2007 at 15:25 UTC
Updated:
8 Aug 2008 at 03:59 UTC
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
Comments
Comment #1
mlncn commentedThe 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:
instead of
i18n_get_links.That said, I can't verify what the difference in practice is between the different code.
Comment #2
mlncn commentedThe 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).
Comment #3
sobaboy commentedremoving 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.
Comment #4
mlncn commentedThanks, 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?
Comment #5
davemybes commentedI 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:
Just change "yourthemename" to the name of your theme.
Comment #6
sobaboy commentedI 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
from translations.module
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. :-)
Comment #7
davemybes commentedThe 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 :)
Comment #8
sobaboy commentedI 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.