lets assume /node/1 > /en/page1 (english page)
and /node/2 > /el/page2 (greek translation of previous page)

if we enable the nodewords
and configure canonical url output on page (in /admin/content/nodewords/default)

visiting /en/page1 we get
<link rel="canonical" href="http: // host/en/page1" />
visiting /el/page2 we get
<link rel="canonical" href="http: // host/el/page2" />

visiting /el/node/1 we get
<link rel="canonical" href="http: // host/el/node/1" />
instead of correct
<link rel="canonical" href="http: // host/en/page1" />

and visiting /en/node2 we get
<link rel="canonical" href="http: // host/en/node/2" />
instead of correct
<link rel="canonical" href="http: // host/el/page2" />

I used the default version 6.x-1.9

but also used the 6.x-1.2beta9 and the currect dev versions (the last two used tokens)

and had the canonical URL take the values of
[node-path]
[node-url]
[current-page-path]
[current-page-url]
[metatags-url-alias]

but all of them had the previous behaviour

I suspect this is the problem of the pathauto module not passing the correct path-alias but I wanted to confirm with the developers of this module.

Comments

mthomason’s picture

There is a problem here. Here's how it's working.

Say you have the following location:

node/1 <-English default language. Original node. Canonical URL: node/1

You translate it, and you get the next few:

node/2 <-Spanish translation. Canonical URL: es/node/2
node/3 <-German translation. Canonical URL: de/node/3
node/4 <-French translation. Canonical URL: fr/node/4

Since it's translated, each nodes of this form:

lang/node/#

Visit Bad Result
es/node/1 Canonical URL: es/node/1 Expected Canonical: node/1
es/node/3 Canonical URL: es/de/node/3 Expected Canonical: de/node/3

Those two results are wrong.

Wouldn't it work if a user could just enter a static string that is protected from the rest of the system?

big67’s picture

I can confirm this issue.

I am using:
Drupal 6.19
Nodewords 6.x-1.11
Nodewords basic metatags 6.x-1.11

Internationalization and Pathauto 6.x-1.2

drupalina’s picture

Priority: Normal » Critical

I have the same issue and I've been banging my head against the wall because of this, because my Google Webmaster Tools is now filled with hundreds of 404 errors because when you (or the Google bot) go to mysite.com/es/Russian_title (as per rel="canonical" request) naturally it gives a 404 Page Not Found error. Having Google think that you have more pages that don't exist than those that do exist is VERY-VERY BAD for SEO.

I think this could be easily corrected if on node edit form the Canonical URL slot would accept the full URL -- so that we could manually enter "http://example.com/es/Spanish_title" rather than than "Spanish_title" as it is the case right now.

mrfelton’s picture

I can confirm this issue as well.

When visiting a node using an alternate node prefix, the Canonical URL uses the prefix that you have used to visit the page, as opposed to the prefix that should be associated with the node.

I think the comments in #1 describe the problem and what is expected exactly.

DamienMcKenna’s picture

Status: Active » Postponed (maintainer needs more info)

Please take a look at the latest 6.x-1.x-dev codebase, examine nodewords_basic_canonical_prepare() in nodewords_basic.module and let me know what logic should be applied to identify the correct path give standard Drupal 6 practices for internationalization. I will admin to not being familiar with how Drupal handles internationalized paths but will gladly accept pointers and code :) that doesn't bloat the code any further.

DamienMcKenna’s picture

Assigned: Unassigned » DamienMcKenna
Status: Postponed (maintainer needs more info) » Active

Lets try to fix this for the next release.

thetrickyt’s picture

That would be really great. This causes us some pain.

DamienMcKenna’s picture

Assigned: DamienMcKenna » Unassigned

Taking this off the slate for now. I'd also appreciate some input from the community on whether the change in #1697936: _nodewords_prepare_path() uses incorrect base URL to trim the argument helps with the problem.

DamienMcKenna’s picture

Status: Active » Postponed (maintainer needs more info)

I've committed the code from #1697936, so I'd like some feedback on whether the problem still exists. Thanks.

DamienMcKenna’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Closed (won't fix)

Thank you for taking the time to work on this. However, the module is no longer supported, so I'm closing this issue.