Closed
Bug 35121
Opened 25 years ago
Closed 25 years ago
Pls move Sherlock .src files to chrome/.../locale/
Categories
(SeaMonkey :: Search, defect, P3)
SeaMonkey
Search
Tracking
(Not tracked)
VERIFIED
FIXED
M16
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.
Reporter | ||
Comment 1•25 years ago
|
||
adding rjc to the cclist.
Reporter | ||
Comment 2•25 years ago
|
||
ccing tao
Comment 4•25 years ago
|
||
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?
Comment 7•25 years ago
|
||
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
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]
Comment 9•25 years ago
|
||
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.
Assignee | ||
Comment 10•25 years ago
|
||
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?
Assignee | ||
Comment 11•25 years ago
|
||
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.
Comment 12•25 years ago
|
||
> 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".
Assignee | ||
Comment 13•25 years ago
|
||
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.
Comment 14•25 years ago
|
||
> 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!
Assignee | ||
Comment 15•25 years ago
|
||
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.
Comment 16•25 years ago
|
||
> 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>
Comment 17•25 years ago
|
||
> 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.
Assignee | ||
Comment 18•25 years ago
|
||
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
Assignee | ||
Comment 19•25 years ago
|
||
I just backed out the changes. Now, "searchplugins" is back to bin/.
Assignee | ||
Comment 20•25 years ago
|
||
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.
Comment 21•25 years ago
|
||
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: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 22•25 years ago
|
||
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 → ---
Comment 23•25 years ago
|
||
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-]
Comment 24•25 years ago
|
||
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... ?
Assignee | ||
Comment 25•25 years ago
|
||
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
Assignee | ||
Comment 26•25 years ago
|
||
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: 25 years ago → 25 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•