Records published in one language are displaied in both site languages

I am starting to think that this is due to Falang behaviour: when you switch language and it does not find a translation for the viewed content

(and it will never find one because I used parallel translation method, I didn't translate the contents, but duplicated them and assigned to another language)

it display the same content again does make sense in your opinion?

oloccina I didn't translate the contents, but duplicated them and assigned to another language

AFAIK, that is always the case for Cobalt records/articles! They can't be translated with FaLang.

BTW, did you notice that you can translate ALL Cobalt items with J! core funktionality? Related topic here. If you don't have other content and extensions, I would go this route.

FaLang:
There was an update for J! 3.3, maybe it does fix something?!

pepperstreet AFAIK, that is always the case for Cobalt records/articles! They can't be translated with FaLang.

BTW, did you notice that you can translate ALL Cobalt items with J! core funktionality? Related topic here. If you don't have other content and extensions, I would go this route.

thanks, very interesting info!

FaLang:

There was an update for J! 3.3, maybe it does fix something?!

I don't think so as this site is still on Joomla 3.2.3

thank you

Language filter working as you say. It work in list, but if you go to full view of the article lang variable don't work. But you can access article in this way only if you input full url in browser address, from the list you can do that.

But look there is no link to the same article in the list. SO actualy Google never will create 2 urls of differnt language to same article. Only if you change the language manually. But who will do that?

Sergey http://www.sarteanoliving.it/ it/1/voce/15-itinerari/476-il-percorso-dell-acqua http://www.sarteanoliving.it/ en/1/voce/15-itinerari/476-il-percorso-dell-acqua

Aah, i did not get your actual issue... now I see what you are talking of. Actually, everything is fine on your site.

But your assumption about the URLs is slightly wrong. Section and category ID# stay the same for EN/IT. But that is NOT the case for Cobalt records ;-) Since Cobalt duplicates the records! So, you will always get a NEW record ID for EACH language!

Example for section and categories (different LANG, same ID#):

www.sarteanoliving.it/it/1/categoria/3-sarteano/28-io-sono-sarteano
www.sarteanoliving.it/EN/1/categoria/3-sarteano/28-io-sono-sarteano

If you check the record links on the list, everything is o.k.!

Example Record full view (allways gets different record ID#):

http://www.sarteanoliving.it/it/1/voce/33-acqua-sport-e-benessere/ 503-il-parco-delle-piscine
http://www.sarteanoliving.it/ EN/1/voce/33-acqua-sport-e-benessere/51-il-parco-delle-piscine

I assume, you were testing WITHOUT visible language switcher... by just replacing the LANG variable... This won't work, because you will keep the same (wrong) record ID in your full view URL ;-)

Test with langauge switcher, or from Cobalt list.

Sergey But look there is no link to the same article in the list. SO actualy Google never will create 2 urls of differnt language to same article. Only if you change the language manually. But who will do that?

Yes Sergey, that is what I was thinking, and which should not create any duplicate content issue.

This problem has been notified to me from a SEO specialist which was analyzing the website with a sofwtare, those 2 urls (identical content but different urls) where indexed in Google serp, that is why he notified me the issue. But maybe was justa one time issue.

Even publishing those urls with duplicated content in this forum topic may cause Google to index them I think.

pepperstreet Example Record full view (allways gets different record ID#):

http://www.sarteanoliving.it/it/1/voce/33-acqua-sport-e-benessere/ 503-il-parco-delle-piscine

http://www.sarteanoliving.it/ EN/1/voce/33-acqua-sport-e-benessere/51-il-parco-delle-piscine

yes, I think I get you

I assume, you were testing WITHOUT visible language switcher... by just replacing the LANG variable... This won't work, because you will keep the same (wrong) record ID in your full view URL ;-)

Nope, I was using the language switcher, I was viewing a record in italian, then switched languaged and the result was the same record but with a different URL

This maybe cause by Falang, I don't know, anyway I will solve this particular issue by not using the language switcher at all, I will simply use a custom html module with flags, each flag is linked to the website homepage for that language, period.

Otherwise a visitor viewing a record in italian and switching to english language would see the same italian record, not the translated one (I think thsi is due to records translations being not handled by Falangm, which thus cannot find a translation and send you to the same record when you switch language... or am I wrong?)

oloccina Otherwise a visitor viewing a record in italian and switching to english language would see the same italian record,

Good point! Do you stay on the same IT record? No re-drirect to EN-homepage?

not the translated one (I think thsi is due to records translations being not handled by Falangm, which thus cannot find a translation and send you to the same record when you switch language... or am I wrong?)

Exactly, usually this is handled by Falang, if the item is translated by FaLang. Not the case for Cobalt records.

I guess, you would have the same effect with Joomla core translation. Their is no association between the Cobalt records. There might be a translated record or even not.

No matter which translation method and tool is used...,
I think we should be re-directed to the respective homepage. At least when Cobalt can't handle the association, yet. I remember, this was Joomla's default behavior in the past)

SEO - duplicated content

I see no problem, as long as the URL has a specific language part... AND the page gets the correct HTML language attribute. Check the respective Joomla system plugin and the resulting page source.