i18n and links

This is tough one, since while I agree that most of the entry would not be translated, there are some parts that some would probably want to translate, like the abstract. So it's one of those situations where you can't please everyone.

Do you know of any workaround? I18n let's you specify exactly which node types to translate - so maybe it would be possible to fetch the "original" node id for list display if i18n is disabled for the biblio node type, and fetch the node id via the translations table in cases where i18n is enabled for the biblio node type. Right now I'm only using biblio on a small non-profit organisation's web site, but this would be a very important issue to me if we would consider switching to Drupal with Biblio at work (a university department). My users would not want translation of bibliographic entries, however the rest of the website would have to be multilingual since it's a Swedish university but the language of science is English, and many of our researchers are non-Swedish-speakers.

Cheers
T

Maybe I misunderstood the original issue then, since I thought it behaved as you describe in your last post. Let me do some testing and get back to you.

Ron.

I have tried to make a complete reinstallation of biblio now, but still get the bad behavior with "en/node" links on the list page. If I make a view listing publications, I get the correct links from the title. But then I miss all the good stuff with sorting and author search etc.

Cheers
T

Ok, I found out that i18n_db_rewrite_sql() for the listing query in biblio overwrites the nid with NULL, or whatever is happening. Anyway the result of the i18n_db_rewrite is a query where the node table is joined with biblio table and i18n_node table on nid, which results in nid=NULL from the last join when no entries for the biblio entries are found in the i18n_node table (remember I have not enabled i18n for biblio content type).

So to get this working for my particular case, I hacked biblio.module to pass on a i18n_db_rewrite_mode argument to i18n_db_rewrite, and I hacked i18n_module to take notice of this argument.

biblio.module around line 1684:

i18n.module around line 705:

Not very neat with the hardcoded i18n_db_rewrite_mode='off', but it seems to work in this case.

Cheers
T

Strangely, I can't reproduce the behavior you describe (although I thought I had before). I just installed the latest i18n module and biblio still works as it did before, only with a language designator, ie. localhost://en/node/489 or localhost://en/biblio

Ron.

Hi,

I'm exactly with the same issue on drupal 5.1, biblio 5.x-1.2 and i18n 5.x-2.0.

When i18n is installed but NOT requested to translate biblio nodes, biblio listing don't render links correctly (nid is null so every article is linked to /en/node/ and export links so).
Same happens if i18n is enabled on biblio nodes but you DON'T select an specific language (selecting the "blank entry" in the language dropdown).

Finally, if i18n is enabled for biblio nodes and a language is selected, everything works like a charm.

I'm pretty sure that tobbe_s solution will work but... do you think we can find a solution without changing i18n?
Why nid is returned as null? Isn't it possible to drive query in a different way?

Thanks for your work,

m.

BTW, I installed drupal, then i18n and finally biblio on their head versions.

Here you a backup of my drupal so you can reproduce the issue if you like:
http://psicologiasocial.uab.es/base/drupal-backup-20070523122629-6056436...

As is now, you can test selecting a language (that works) or leaving lang dropdown as blank (that fails).
If you disable i18n over biblio nodes it will also crash.

Diff module is also installed, but is patched as you suggested in former issues.

Cheers,

m.

Sorry to annoy again... and sorry in advance if I'm talking rubbish.

I traced the issue and the existing debugging "echo $query" in biblio_db_search function shows:
"SELECT * FROM {node} n left join {biblio} b on n.vid=b.vid WHERE n.type='biblio' ORDER BY b.biblio_year %s, b.biblio_date DESC, SUBSTRING(n.title,1,1) ASC, b.biblio_type ASC"

I'm unsure why a %s isn't parsed here, but the funny part is, if I execute this same query (with db_prefixes) against my DB, "nid" is returned twice but with right values.

So following tracing, I noticed that "nid" is overwritten by db_rewrite_sql when joining.

Here it is the query:

And an example of the returned values:

On a "i18n enabled for biblio nodes scenario", first row is an article without an specific language (that fails) while second article was set on english (and nid is returned ok). And again, two attributes with the same name and the second "nid" is the returned one.

Unsure if it's in biblio or i18n field goal... but any clue about how to fix it?

Thanks for your help,

m.

Hi,

I think that the problem really lies with i18n. I18n should not attempt to rewrite the query when translation is not enabled for a certain node type (i.e. biblio). However, i18n do rewrite the query, with the result that the query returns the nid from the last join, which is null since there is no entry for the particular node in the i18n-table that stores info about available translations for different nodes.

All queries for all modules that are constructed using the function db_rewrite_sql() will be sent to hook_db_rewrite_sql() in all modules where this hook is implemented, so I guess it's up to i18n_db_rewrite_sql() to choose whether to rewrite a particular query or not. In this case it shouldn't, but it does anyway.

/T

Yes, that was my impression to. This should be easy enough to fix on the i18n side, however this module is moving into the core of drupal as of version 6 so there may not be much incentive to fix version 5.

Hi, here i18n module maintainer

I still dont understand a word about why these queries shouldn't be rewritten. They are node queries so, whatever, language conditions should apply. If you dont have translations but the nodes have language....

So maybe just disable language for that node types, or easy code fix

module_invoke('i18n', 'db_rewrite_mode', 'off');
... query here
module_invoke('i18n', 'db_rewrite_mode', 'reset');

However, for the module maintainer, if you really want i18n module to skip rewriting this queries -which I dont really understand why- and have a quick fix for i18n_db_rewrite_sql, let me know

like preg_match('.....{biblio}...', $query), I just need a regexp that matches all the queries you want to skip

So rjerome, please, let me know if you want such a fix

Hi,

My wife is using Drupal 5.2 with i18n 2.1 and biblio 1.9. Translation is not enabled for biblio node types and it seems to work ok (see http://csam.univ-ovidius.ro/~ebautu/en/biblio)

Best wishes to all (especially to the biblio and i18n maintainers).
Andrei

First of all thanks Ron for making a truly great module!

However, I am having issues with internationalization and biblio too. It is a similar problem as others have mentioned. I have to have biblio nodes set to be translatable otherwise they do not appear in any searches on the /biblio interface. Even if I set biblio nodes to have translation workflow, it is only biblio entries that are manually entered that appear on a search. Anything that is imported from a bibtex or endnote file exists as nodes in drupal, but for some reason doesn't come up in the biblio search, they do appear in the filter builder though.

I have no choice but to use internationalization where I work: in a Welsh University. Is there some issue with the import from file not setting up internationalization of the nodes? Perhaps an SQL rewrite is missing? I have no clue where to start looking at this problem but I really need to import a lot of references into biblio and have them come up in the search.

Any help you can give would be much appreciated. I have just moved to the dev version of biblio but it hasn't helped. I am on the most recent release candidate for i18n too. FYI if I add a biblio node manually, I don't have the link problem mentioned here the search works fine and links to the node. I just have this issue with queries not working with imported data. I just get "No items found" on the List tab, but clearly the module knows about the imported content I've added because the Filter shows up with the Authors and Years that are available to search by.

This is the SQL that biblio is executing, so I assume the imported nodes do not have i18n entries set up for them?

If I do the following query I get a list of all the biblio entries that have been imported, so internationalization information is missing:

MySQL complained about the {} and %s notation so I'm not too sure what that is about, I just removed it from my query.

I think the problem lies in _biblio_save_imported_nodes(...) {} biblio.module line #2465. It's not creating any internationalization information for the node, I'm not sure if this is to do with node_save() and a deficiency in i18n or what? I am happy to investigate this myself and submit a patch if no one else has any time or ideas, but any help is welcome. I have to have this working within the next couple of days to meet my deadlines :[.

I think I tracked down this problem and fixed it. During file import, the default language was not being set, and thus an i18n entry was not being created.

Give the 5.x-dev version a try and let me know if it solves your problem.

Ron.

Hi Ron,

As far as I can tell this is working fine. Thanks for your efforts on this, and speedy reply, it is very much apreciated!

Matt.