i18n: language (locale) not taken into account for finding title
toemaz - September 29, 2008 - 15:10
| Project: | freelinking |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | postponed |
Description
Suppose there are two nodes with the same title but both in different language. It occurs that the freelinking module returns the page in the other language than the one which is currently.
Very short patch. Running on a production website.
| Attachment | Size |
|---|---|
| freelinking_language.patch | 1.05 KB |
#1
Patch is currently on a production website and working well.
Anyone willing to review it?
#2
Running this in production quiet some time now. No issues so far.
Crucial issue for multi lingual Drupal installs.
#3
Updating the patch against the latest revision.
#4
Updating the patch against the latest revision.
#5
The patch is running in production on http://musescore.org since a month now, which is quite a big i18n install.
I hope it can be committed.
#6
It's committed to dev. It will be part of the next release.
#7
Fixed in freelinking-6.x-1.7.
#8
Somehow, the patch was committed but the next commit took it out again. Clearly visible at: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/freelinking...
Can it be committed again?
#9
Rerolling patch against latest 1.x-dev
Allow me to put this on critical. Without this patch, the use of freelinking module on a multilingual website is pointless. I'm running patch for 4 months now at http://musescore.org which has a quite large multilingual setup.
#10
Kicking this issue back to the top. I know this is 'not done', but I'm getting a little desperate.
#11
Patch has been applied to 6.x-1.x as well as 6.x-2.x
#12
Automatically closed -- issue fixed for 2 weeks with no activity.
#13
It's been a couple of moths now since I use this patch in production and I must say, freelinking module is still not working as it is supposed to run for a multilingual site. It's quite obvious when you check out the patch.
It takes the global $language; in order to find out what language the website interface is currently in and uses this in the where statement of the query to find the right node. Seems like a good solution but it isn't!
Image you are on node/xx which has language field set to nl but you are browsing in an en interface. This means the freelinking filter will search for en node titles. Instead it should search for nl node titles. So the only decent solution is to retrieve the node language and use that to query with.
This still doesn't solve the complete problem because the resulting freelink is created in url() where it uses global $language; to define the what iso code to use in the url. Instead, the freelinking module should pass on the proper language of the node in the options array of the l($text, $path, $options = array()) function.
The solution to this problem could have been easy in case the freelinking module had awareness of the node, but it hasn't. It only gets the node text without language context.
So eventually I tried to solve this in an ugly way. See the patch attached. I hope you can figure it out.
#14
SUbscribing, greetings, Martijn
#15
Hi Martijn,
Did you encounter the same problem? Do you have a fix for it you can share?
In the meantime, freelinking has moved up to version 3 and I have not checked so far whether it incorporates i18n dependencies like applied to the 6-2 branch.
#16
No fix, needing possibility to be able to use more than one locale source. Greetings, Martijn
#17
Freelinking 3 Nodetitle does not have localization support. I will review the patches here and determine how to adapt them for v3.
#18
@Grayside Thanks for looking into this.
#19
Moving the discussion to 6.x-3.x-dev as a "new feature" in language support. Also, marking this active again to work out the improved locale support discussed in #13.
To recap, when linking to a node you want:
Option (2) in the sequence is specifically what #13 is pursuing. Unfortunately, because input filters lack insight into the object that supplied the text for filtration, it is impossible to consistently grab the language of the "linking node"/etc.
It is possible to determine via the current page request which node you are currently viewing, and thus the language of that node. However, if we pursue this technique the link will probably change depending on whether you view the text on the node page, a teaser listing, or some other view. That seems unacceptable to me.
Potentially, #621180: Building a Robust FL3 API and some module built around it could engineer a fix for this, but it is outside the imminent scope Freelinking. (Unless, of course, I am missing something obvious.)
I will proceed with implementing (1), (3), and (4) to provide some kind of good localization behavior. I more than welcome any thoughts as to the syntax of #1, aspects of Locale module I have not considered, or especially a magic trick for #2.
#20
The changes I outlined as feasible in #19 have been released in 3.0-alpha3. Point #2 is a database-dependent sort of problem, so I am marking this issue postponed for that functionality. It must wait on #637842: FL3 should be released with an FL3DB sub-module.