Closed Bug 35121 Opened 24 years ago Closed 24 years ago

Pls move Sherlock .src files to chrome/.../locale/

Categories

(SeaMonkey :: Search, defect, P3)

Product:
SeaMonkey
Component:
Search
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: fergus, Assigned: tao)

References

Details

(Whiteboard: [nsbeta2-] - checked in on win/linux. pending on mac) 

Currently all Sherlock .src files reside in \res\rdf\datasets.  Please move them 
to \chrome\...\locale

We want to be able to provide different sets of search engines for different 
geographies:  perhaps a UK-centric search engine for Britain, and Japanese, 
French and German search engines for those locales, to name but a few.  The best 
way to manage this is to have the Sherlock .src files in locale directories.
adding rjc to the cclist.
ccing tao
Blocks: 34145
Blocks: 12394
Giving to rjc since i'm about to go on sabbatical
Assignee: matt → rjc
I'd like to make a suggestion (if you don't think its the right thing to do, just 

say so; its only a thought):



can we ship ALL versions of the browser with ALL the search engines we partner 

with?



Non-local (to the area in question) search engines can be put into a different 

search category.  (Basically, they don't have to be easily discoverable.)



By shipping with ALL the search engines, it means that if a user happens to 

search on a "foreign" website, we'll still show the abbreviated results in the 

sidebar.  If we don't ship them, then that doesn't happen.



Any opinions?


CC Cindy Roberts for comments.
Cindy?
Assignee: rjc → roberts
Assigning to Tao as this is part of the Country Picker project in which he's 
rearchitecting the file structure for locale info and including several locales 
in one build.
Assignee: roberts → tao
Keywords: nsbeta2
Status: NEW → ASSIGNED
Target Milestone: --- → M16
Putting on [nsbeta2+][5/16] radar.  This is a feature MUST complete work by 
05/16 or we may pull this feature for PR2.
Whiteboard: [nsbeta2+][5/16]
Tao, you checked in some changes today (5/16) which has caused serious search 
problems.  Please backout your changes as soon as possible.

The problem(s) with your changes:

o  By design, there should be one "Search Plugins" folder (analogous to the 
"Plugins" folder) where search files go.  Users can add or remove files from 
this folder by hand.  By moving it into chrome:// you've made it very hard for 
the user to know what they are customizing, as each locale would have its own 
searchplugins folder.

o  Each *profile* gets a "search.rdf" file which specified how the installed 
search files are to be organized into search categories.  This "search.rdf" 
can't work with multiple chrome:// locales where the search files are different.

o  Search files can be installed via any web page by using a Javascript API.  
The intention is to have these files installed globally (in the "Search Plugins" 
folder). However, with your changes, the new plugins would be installed into the 
chrome:// directory which is bad (they aren't globally shared).

If you want to be able to include multiple multiple search files for multiple 
locales, that's OK... you can do that, but at installation the appropriate 
search files should be installed into the "Search Plugins" folder.

(I'm out of work this week, although I'm checking email at least once a day.)  
Please talk with DP if any of this isn't clear, or you can try calling my 
cellphone.

Since I hadn't seen any objection in this bug report, I thought that you 
agreed at the very beginning that we move all Sherlock files to 
chrome/[...]/locale directory :-)


Anway, see my comments below:

>o  By design, there should be one "Search Plugins" folder (analogous to the 
> "Plugins" folder) where search files go.  

> Users can add or remove files from 
> this folder by hand.  By moving it into chrome:// you've made it very hard for 
> the user to know what they are customizing, as each locale would have its own 
> searchplugins folder.
If it is for end users's customization, "searchplugins/" should probably 
reside in user's profile directory.

>o  Each *profile* gets a "search.rdf" file which specified how the installed 
>search files are to be organized into search categories.  This "search.rdf" 
>can't work with multiple chrome:// locales where the search files are 
>different.

During the process of moving, I found that this file should be moved to 
chrome://.../locale, too, so it matches the files in "searchplugins/." I'll
log another bug against this.

However, keeping in mind that at any time, only one "locale", i.e, one set of
"search.rdf" and "searchplguins/*.{src,gif}", is visible to Seamonkey.

> o  Search files can be installed via any web page by using a Javascript API.
> The intention is to have these files installed globally (in the "Search 
> Plugins" folder). However, with your changes, the new plugins would be 
> installed into the chrome:// directory which is bad (they aren't globally 
> shared).

Again, any add-ons from remote websites shall probably go to the user's profile
directory. For UNIX NFS deployment, this is essential; otherwise, the 
"searchplugins/" direcotry would be stuffed with various Serlock files 
introduced by individual intranet users' visits to remote websites.

Another problem with this "website" installed plugins is that the JS script
most likely will not have write permission to the globally shared directory in
NFS environment.

I will back out my patch once the tree is open and reassign the bug to you. But,
my suggestion would be to placed the "search.rdf" and the matching Sherlock
files into the same chrome://.../locale/ directory.

Comments?






BTW, I forgot to mention that any new theme/locale pack could be installed into
either the global chrome/ directory or a "Chrome" directory in the user's
profile.

>  Since I hadn't seen any objection in this bug report, I thought that you 
agreed at the very beginning that we move all Sherlock files 
to chrome/[...]/locale directory :-)

Please see my "suggestion" higher up in this bug report.  :^)

By moving things into chrome:// you are making them basically be global instead 
of on a per-profile basis.  Take "search.rdf" for example.  Its customizable by 
the user... we have UI in the product to basically edit this file.  It should 
therefore be in the user's profile.

"search.rdf" specifies which search engines are in which categories.  If "Search 
Plugins" (which contains the search engines) is in the user's profile, that 
means that they aren't shared across profiles as they should be.

By keeping the "Search Plugins" folder in the same directory as "Plugins", it 
has the same "issues".  Is it writable by the user?  If no, that means that they 
can't add plugins either.  Would we move "Plugins" into the chrome:// hierarchy? 
 That seems to have little value.

I understand (I believe) what you are trying to do with locales.  As per my 
original suggestion, I'd like to see us ship all versions of the browser with 
ALL the search files we have.  "search.rdf" can then be used to say "Which 
engine goes where" and "Which engines are visible".  Basically, we shouldn't be 
switching out a user's list of preferred search engines out from underneath 
them, just because they've changed their locale.  We should allow it (which the 
Search Editor does) but not force it upon the user.


>  Again, any add-ons from remote websites shall probably go to the user's 
profile directory. For UNIX NFS deployment, this is essential; otherwise, the 
"searchplugins/" direcotry would be stuffed with various Serlock files 
introduced by individual intranet users' visits to remote websites.

Again, this is the same issue as with plugins.  On the other hand, just because 
User A added a Sherlock file doesn't mean that User B will necessary see it in 
their preferred list of search engines.  User B could however choose to add it 
in via the "Search Editor".

Hi, Robert:

Thanks for the quick response. See my comments below:

> Please see my "suggestion" higher up in this bug report.  :^)

Guess you have been polite :-) 

>By moving things into chrome:// you are making them basically be global instead 
> of on a per-profile basis.  Take "search.rdf" for example.  Its customizable 
by 
> the user... we have UI in the product to basically edit this file.  It should 
therefore be in the user's profile.

> "search.rdf" specifies which search engines are in which categories.  If > 
"Search 
> Plugins" (which contains the search engines) is in the user's profile, that 
> means that they aren't shared across profiles as they should be.
     My understanding is that all files under "bin/defaults/profile/",
     including "search.rdf" and "panels.rdf" are copied to a new profile
     during creation. After the creation, those user's copies are customized 
     by users via UI or other means

     All I do is move files under "bin/defaults/*" to the proper place under 
     "chrome://../locale/". They (including the search.rdf/panels.rdf) will
     live in user's profile afterward.
  
>By keeping the "Search Plugins" folder in the same directory as "Plugins", it 
>has the same "issues".  Is it writable by the user?  If no, that means that 
they 
>can't add plugins either.  Would we move "Plugins" into the chrome:// 
hierarchy? 
> That seems to have little value.

The differnce being the sherlock files are provided and shipped w/ the client.
All client deliverables are supposed to be localizable. We don't have control
over third party plugins for now. When chrome "add-ons" feature is available,
we probably will be able to take care plugins's localizability issues.

>I understand (I believe) what you are trying to do with locales.  As per my 
>original suggestion, I'd like to see us ship all versions of the browser with 
>ALL the search files we have.  "search.rdf" can then be used to say "Which 
>engine goes where" and "Which engines are visible".  Basically, we shouldn't be 
>switching out a user's list of preferred search engines out from underneath 
>them, just because they've changed their locale.  We should allow it (which the 
>Search Editor does) but not force it upon the user.

Be careful for what you are wishing for :-)

For US product only, there are 10 set of search engines already. Assuming that
there will be 20+ (which is a little bit under 4.x's) localized versions, you
would be shipping 200+ searching engines w/ a single product. I'm not sure if 
this is what we'd like to do.

However, I do like the idea of having search engines of multiple culture 
co-exist in the searchplugins/ directory, though. Let me visit our marketing
peers...

At last, do we agree that "search.rdf" shall be moved to chrome://../locale/.. 
??

Also, we need to find out how to add culture/region specific search engines
to a "non-localizable" drectory shall we decide to ship all engines w/ a single
product.



Thanks for listening.
>  For US product only, there are 10 set of search engines already. Assuming 
that there will be 20+ (which is a little bit under 4.x's) localized versions, 
you would be shipping 200+ searching engines w/ a single product. I'm not sure 
if this is what we'd like to do.

I know its what *I would do!  :^)  The more engines we directly ship, the more 
possibilities we have for keeping users searching us (or our partners).  It also 
provides more value to the search sidebar panel (as the installed engines are 
the only ones which can populate search results in the panel).  Finally, it 
makes for a more powerful marketing campaign:  "We support hundreds of search 
engines, WAY MORE than our competitors."


>  At last, do we agree that "search.rdf" shall be moved to 
chrome://../locale/..  ??

IF its the case that upon installation they are installed into the user's 
profile directory and the code actually looks in the user's profile directory 
for the file, then yes.  Your code changes looked like that was NOT the case.  
:^(

[I'll be out of work for the rest of the day, but can talk more about this 
either over email (slow response), via my cellphone (if I'm not in a session), 
or perhaps we can chat early next week.]


> Thanks for listening.

Thanks too!


My patch moves the sherlock files only; it hasn't touch the "search.rfd" file
yet. Do you want to move the search.rdf yourself or you want me to do it? If
you can't review it, who can help? We need to solve this by Friday.

As to shipping sherlock files for all versions, I was concerning about the 
length of the candidate list; 200+ entries are probably too overwhelming :-)

For now, it's OK, though.
>  Do you want to move the search.rdf yourself or you want me to do it? If
you can't review it, who can help?

I can't do it (this week, anyway).  If you can do it, that would be great.  
Please test to ensure that creating a new profile gets its own copy of the file 
(as it will be modified).  :^)  

If you email me a diff, I can code-review and approve it within a day.  (I 
usually check my email in the evenings.)  If you haven't heard from me, try 
waterson.

As far as backing out your previous checkins, until this is all resolved, can 
you do that as soon as absolutely possible?  There is feature work that still 
needs to be done, as well as some check-ins by jbetak@netscape.com (who is 
waiting for approval from me), and I would like to prevent changes from others 
to be lost due to CVS revisions going back and forth.  <grin>
>  As to shipping sherlock files for all versions, I was concerning about the 
length of the candidate list; 200+ entries are probably too overwhelming :-)

Don't be overly concerned about the # of search engines.  The 
*purpose* of "search.rdf" is to allow us to have categories/hierarchies of 
search engines instead of one huge/long flat list.  With the "Search" editor, 
users can customize all this to their heart's content.

In terms of performance, the internet search datasource is very lazy at reading 
in search files... basically, it doesn't bring them in until they are needed.

So, in general, the more search engines, the better.

The tree is closed for bustage only. Unless I get a "go" from the sherif, I'd 
rather wait until the tree open for general bug fixing. Let me know if you 
want me to pull it now.

As to the patch of moving "search.rdf", I'll attach the patch here once it is
 avaiable.

Thanks
I just backed out the changes. Now, "searchplugins" is back to bin/.
Depends on: 39671
We have decided not to move Sherlock files. The localizability solution 
of the "Search" feature will be to move "search.rdf" instead.

This bug will be fixed when 39671 is fixed. I have a patch that will solve
these types files all at once. See 33663 for details.
I'm sorry. Can you provide more info re: what you mean by "The localizability 
solution of the "Search" feature will be to move "search.rdf" instead." ???

Realize that the user can & will make changes to "search.rdf" to specify what 
search engines they want in what search categories. (We have UI in the browser 
to make this easy to do.) These user-specified changes shouldn't be lost, just 
because the locale has changed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Hi, Robert:

Here is the excerpt from bug 33663:

"I have come up w/ a patch that will first 
look for bin/defaults/profile/{locale name}/* and then bin/defaults/profile/*
in copying the default files for a new profile. This solution will solve the
localizability of all files (under bin/defautls/profile), including 
seach.rdf, under bin/defaults/profile."

Hope that this helps. 

Reopen the bug since the fix has not been checked in yet.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Pulling [nsbeta2+][5/16].  Looks like just a bug now, not feature.  Putting on 
[nsbeta2-] radar, adding nsbeta3 keyword.
Keywords: nsbeta3
Whiteboard: [nsbeta2+][5/16] → [nsbeta2-]
Hi Tao,

At first glance, this sounds better to me.  Out of curiousity though, why still 
have the fallback to "bin/defaults/profile/*" at all?  It seems like that should 
just go away... ?

Just in case that a third party software/plugins wants to drop some default
files into that directory but they don't have international support for all
installed locales.
Status: REOPENED → ASSIGNED
Whiteboard: [nsbeta2-] → [nsbeta2-] - checked in on win/linux. pending on mac
fix checked in.

The solution is to use search.rdf to control the default search engines
to use for localized builds.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
marking VERIFIED Fixed (2000113004 builds)
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.