Support for multilingual sites

Good idea...

But what modules are you using on your site? When I tested using just the core Locale and Translation moduels on my test site, the core Search module returned both English and Spanish pages, if the word appeared in both.

Oh I see, if I enable Internationalization and Internationalization Content Types, I see what you are seeing.

Anyway, I think this is a good idea for Search by Page, and will see what I can do about it. Thanks for the request!

It turns out this is a bug in the Internationalization module, at least for Search by Page Nodes. I have filed an issue there, with a patch:
#662344: db_rewrite_sql compatibility

If you apply the patch to the file i18n.module in your sites/all/modules/i18n directory, you should see Search by Page Nodes working correctly with your international site.

SBP Attachments should also be fine with that change in Internationalization.

I'll need to check into the other SBP modules...

Custom block titles not being translatable is a problem with the Block module or the Internationalization module, not with Search by Page. Search by Page doesn't do anything special for the block title beyond what any other blocks do... I guess yo urealized that in your edit?

Just summarizing the status of this issue here:

a) Search by Page (SBP) displays results from multiple languages, even with Internationalization - this turned out to be a bug/incompatibility in the Internationalization module (see #662344: db_rewrite_sql compatibility). That fixed SBP Nodes and SBP Attachments.

b) I still need to check into what happens with the other SBP sub-modules (Paths, Users) on multi-lingual sites.

c) Custom block title translations: outside the scope of SBP - Translation of cutsom block titles should be handled by Block, Internationalization, or one of the Internationalization sub-modules.

@vthirteen: Have you noticed any other problems related to getting SBP working with multi-lingual sites? I did try to make it compatible (i.e. providing ways to translate the text you enter on settings pages, etc.). So it is a bug if it is not working, and I appreciate that you took the time to report the problem.

Another thing to check/fix:

d) I am also unsure whether SBP Nodes will actually work completely correctly on a multi-lingual site. My concern is that SBP indexes pages as rendered by the theme, but it doesn't specifically set the UI language before rendering anything. So it's possible that things like field labels might be rendered in the wrong language, when rendering/indexing a node for searching. I need to check that too.

The core Search module might have the same problem, actually, but I won't worry about that.

Anyway, probably what is needed is a language environment for each item in SBP, so that SBP would set the language correctly before rendering each item. Nodes could be rendered in the language they're defined in (or default language if language-neutral). Other paths and user profiles could conceivably be rendered in each language, and then the search results could be limited to the currently-displayed language.

Also, regarding (c) - the Internationalization module comes with a sub-module called "Block translation" which should take care of your block title issues. Hopefully.

One more note on (d): If you want to be able to translate CCK field labels, you need to install at least version 6.x-1.2 of the Internationalization module (http://drupal.org/project/i18n). Then enable the "CCK Translation" sub-module for internationalization. That will allow you to translate the field labels and probably help text on your CCK fields.

If you want the translated strings to actually appear on-screen, you will also need to use at least CCK 6.x-2.x.

OK. I have investigated (d).

With CCC 6.x-2.x, Internationalization 6.x-1.2, and the patch from #662344: db_rewrite_sql compatibility installed for Internationalization, it looks like the site is getting indexed in just one language, so the field labels are all in that language. For instance, I happened to have Spanish turned on when I ran cron manually, so my field labels indexed for all nodes are in Spanish, even if I am searching for an English-language node.

(By the way, the core Search module does not index the field labels at all, because it doesn't index the node as rendered, but just the content parts.)

That is not correct, so I do think that I need to have a language environment for SBP, so that each node is indexed with the user interface set to the correct language (and possibly all possible languages if the node is marked "language neutral").

That is likely what I need to do for SBP Paths and SBP Users anyway.

I may very well combine this fix with the search environment idea in #492878: Multiple search types.

Just to let you know, I'm working on fixing this in Search by Page now, and should have something for you to test in the next few days.

I have just committed changes to the development version of Search by Page, for these issues:
#662282: Support for multilingual sites
#605458: Search by Page does not return all results
#492878: Multiple search types

Pertinent to this particular issue are multilingual features:
- Search by Page only shows content in the current language (though you may have to also install the fix in #662344: db_rewrite_sql compatibility to the Internationalization module)
- There are more language-related options when setting up Search by Page
- Also note that there is a new "search environments" feature, so the settings pages look a little different (see above issue)

I think it's working fine, and all of my automated tests also pass.

If anyone who's watching this issue wants to test, you can get the development version from CVS, or wait about 24 hours until it's updated on http://drupal.org/project/search_by_page (version 6.x-1.x-dev, but make sure its date/time is after the date/time of this comment here!).

You will need to run the update.php script after updating to this version of the module, and also visit the Search module settings page and tell it to redo the search index.

I'm going to go ahead and mark this issue as fixed now, since it all seems to be working.

These fixes will be in the next release (6.x-1.8) and are now available in the development versions of 6.x and 7.x.