Suppose there are two nodes with the same title, but in different languages. It occurs that in some situations, Freelinking returns the page in the other language than the one which is currently.

CommentFileSizeAuthor
#13 freelinking-locale.patch3.91 KBtoemaz
#9 freelinking-locale.patch1.02 KBtoemaz
#3 freelinking_language.patch1.02 KBtoemaz
freelinking_language.patch1.05 KBtoemaz

Comments

toemaz’s picture

toemaz commented

Patch is currently on a production website and working well.
Anyone willing to review it?

toemaz’s picture

toemaz commented
Status: Needs review » Reviewed & tested by the community

Running this in production quiet some time now. No issues so far.
Crucial issue for multi lingual Drupal installs.

toemaz’s picture

toemaz commented
StatusFileSize
new freelinking_language.patch1.02 KB

Updating the patch against the latest revision.

toemaz’s picture

toemaz commented

Updating the patch against the latest revision.

toemaz’s picture

toemaz commented

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.

eafarris’s picture

eafarris commented

It's committed to dev. It will be part of the next release.

eafarris’s picture

eafarris commented
Status: Reviewed & tested by the community » Fixed

Fixed in freelinking-6.x-1.7.

toemaz’s picture

toemaz commented
Status: Fixed » Reviewed & tested by the community

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?

toemaz’s picture

toemaz commented
Priority: Normal » Critical
StatusFileSize
new freelinking-locale.patch1.02 KB

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.

toemaz’s picture

toemaz commented

Kicking this issue back to the top. I know this is 'not done', but I'm getting a little desperate.

toemaz’s picture

toemaz commented
Status: Reviewed & tested by the community » Fixed

Patch has been applied to 6.x-1.x as well as 6.x-2.x

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

toemaz’s picture

toemaz commented
Version: 6.x-1.x-dev » 6.x-2.x-dev
StatusFileSize
new freelinking-locale.patch3.91 KB

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.

summit’s picture

summit commented

SUbscribing, greetings, Martijn

toemaz’s picture

toemaz commented

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.

summit’s picture

summit commented

No fix, needing possibility to be able to use more than one locale source. Greetings, Martijn

Grayside’s picture

Grayside commented

Freelinking 3 Nodetitle does not have localization support. I will review the patches here and determine how to adapt them for v3.

toemaz’s picture

toemaz commented

@Grayside Thanks for looking into this.

Grayside’s picture

Grayside commented
Version: 6.x-2.x-dev » 6.x-3.x-dev
Category: bug » feature
Status: Closed (fixed) » Active

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:

  1. The linked node to draw it's language of choice from some syntax in the freelink (i.e., [[nodetitle:de:Kansas]]).
  2. Failing that, the linked node to match the language of the linking node.
  3. Failing that, the linked node to match the default language of the site.
  4. Failing that, a page in any language, so long as it has the title.

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: Unique Links by Page 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.

Grayside’s picture

Grayside commented
Status: Active » Postponed

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 DB Functionality Through Separate Project.

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented
Version: 6.x-3.x-dev » 7.x-3.x-dev
Issue summary: View changes
Priority: Critical » Normal
Status: Postponed » Needs work
Issue tags: +needs backport to 6.x

This needs to be first fixed for D7, then backported to D6.

Can anyone using Freelinking in production on a multiligual site comment on the status of the problem with the current versions (both for D6 and D7).

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented
Assigned: Unassigned » gisle
Issue summary: View changes
Related issues: +#2240993: Multilanguage URL replacement

Added another multilanguage issue (#2240993: Multilanguage URL replacement) as related.

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented
Status: Needs work » Postponed

As pointed out by toemaz on #13 above:

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.

If you look at the API for the callback function: function callback_filter_process($text, $filter, $format, $langcode, $cache, $cache_id), $langcode is there (4th parameter).

However, it does not do what I expect: No matter what language is used for text, this is set to 'und' (undefined).

This looks like a bug in core to me.

Postponing until this is sorted out.

  • gisle committed c484a6d on 7.x-3.x 
    #314860 by gisle: Added angcode parameter to filter callback function.
gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented
Parent issue: » #2357181: callback_filter_process $langcode parameter is always "und"

Linking to bug report for the core filter module: #2357181: callback_filter_process $langcode parameter is always "und" .

  • gisle committed c484a6d on 8.x-3.x 
    #314860 by gisle: Added angcode parameter to filter callback function.
mradcliffe’s picture

mradcliffe
he/him
Primary language English
commented
Status: Postponed » Closed (outdated)
Issue tags: -needs backport to 6.x

Closing issue for unsupported release. This is working as-is in newer releases.