Closed (fixed)
Project:
Internationalization
Version:
master
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
28 Apr 2006 at 14:11 UTC
Updated:
13 May 2006 at 17:25 UTC
When I submit a node (for example this one: http://housetier.kicks-ass.net/index.php?q=en/de_test) and then create a translation (http://housetier.kicks-ass.net/index.php?q=en/en_test) I cannot use the neat flag at the bottom of the post to switch languages.
When I click on the flag I always see this:
======================
Primary links
2
======================
However I expected to see the corresponding translation of the node.
I use drupal 4.7.0-rc3 and i18n-cvs
Comments
Comment #1
nathandigriz commentedHas work on this even started? The cvs is probably the cvs for version 4.6
Comment #2
housetier commentedAccording to here: viewcvs i18n there have very recent updates to the i18n module. Also I recall a conversation on irc on this topic:
I sent an email and received a response telling me about the updates.
Comment #3
housetier commentedhmm ok in the above post the irc log came out garbled (the preview didnt show anything), dunno what I can do. Also, I changed the title back to what it was originally.
Comment #4
jose reyero commentedAbout the module, yes, it's being updated, nearly done, and the cvs version is intended to work with Drupal 4.7.
About the translated nodes, which is exactly the link that is not working?
Please, check the new options in both i18n.module and translation.module
Comment #5
profix898 commentedSame problem here. I have a german page on node/13 and the according english page on node/12. Looking in translation tab the two nodes are listed to be translations of each other. I have 'language switcher' block enabled. First page is accessed from de/node/13, clicking on the english flag the path changes to en/node/13 and the interface language switches to english, but the page is still in german.
Comment #6
profix898 commentedI just took a look into the db. Could this be an installation problem!? I18n added a new column 'language' to tables 'node' and 'term_data', but the field is empty for every entry in both tables. Also the new 'i18n_variable' table is empty. Table 'i18n_node' look like this
.
Hope this helps. I'm using a clean 4.7 installation. To install i18n I added i18n.mysql to the db and enabled the two modules.
Comment #7
jose reyero commentedIn this latest version -cvs-, there are two language blocks:
- One in i18n module, which is only a language switcher, which means doesnt handle translations.
- One in translation module, which is the one for links to translations.
Also, there are some options in translation module's settings about node links -the flags below the node body-
Hope this helps
Comment #8
profix898 commentedSo the 'language switcher' block is only to switch the interface language!? I cant find any difference between the two blocks you mentioned. They both seem to only switch the interface! I have translation module configured like this:
Language Management: Interface language depends on content
Links to node translations: Main page only
and i18n.module with default options (Only current language and no language).
Clicking on the flag below the node body points to the translated node (this works perfectly), but it doesnt change the interface language. Other way round clicking on the 'language switcher' block only the interface switches and the node/page remains.
From my understanding, with 'Interface language depends on content' at least the first version (click on flag below the node body) should also switch the interface, right?
Is it possible to make content depend on interface AND vice versa? What I want is:
Whenever someone clicks on the 'language switcher' flags the interface and the content switch to the selected language. It is very confusing for users, if only the interface changes and all pages remain in foreign language. 'Un-localized' nodes however should be visible for both languages (with option 'Only current language and no language' enabled).
Comment #9
profix898 commentedAny statements? Would be great to know what the intended behaviour is like and whether this is a bug or not! ;)
Comment #10
jose reyero commentedYep, that was actually a bug. It should be fixed by now.
Comment #11
profix898 commentedMuch better. Thanks.
Comment #12
jose reyero commented