Closed Bug 59332 Opened 24 years ago Closed 17 years ago

Problems about different directory name of searchplugins

Categories

(Core Graveyard :: Installer: XPInstall Engine, defect, P3)

All
Windows NT
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: kazu, Assigned: dveditz)

Details

(Whiteboard: [xpiprd])

This bug is related to Bug 48872 which is verified wontfix. But Bug 48872 is still remained. And I don't think newsgroup isn't appropriate bug tracking. So I'm opening the problem at Bugzilla. I read some source cord to know what parameter is acceptable for getFolder(). http://lxr.mozilla.org/seamonkey/source/xpinstall/src/nsInstallFolder.cpp#51 There isn't the item for searchplugins. So I can't use getFolder() method now. And I don't think it's good approach to calling getFolder("Mac System"). I know that Windows and Linux use "searchplugins" and Macintosh use "Search Plugins". But I don't know what directory is used for OS/2, BeOS, MacOS X and so on. And Mozilla will be ported to new platforms by hackers community of new platforms. I wouldn't like to check all platforms. The folder name of "plug-ins" has historical reason (Bug 54778). But I think "searchplugins" is new feature. So you can rename it easily. How about "search_plugins" ? It's human readable and has no white space.
I'm going to confirm this bug because as discussions in Bug 48872 show, there is a problem to be addressed. I have not seen in that bug a solution that would be easily acceptable to localizers. At the least we should discuss merits of the proposed solution to a real problem.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Question to kazu: Would it be acceptable if we can get the getFolder() method to return the correct SearchPlugin folder destination value for any platform ? Dan indiactes that this would be an RFE but should be doable.
Yes. I'll be glad if we can get the correct SearchPlugin folder destination. I've created language pack for mozilla including searchplugins. But it has folder name problems. http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=207 (Sorry, it's Japanese Bugzilla) I wouldn't like to create langpacks every all platforms. I think platform specific resource (for example, folder name) should minimize as far as possible because it increases the cost for localization. I wish you solve this problem.
I agree. This is important for localization.
Keywords: nsbeta1
Whiteboard: [xpiprd]
Keywords: l12y
Moz 0.8 tasks
Target Milestone: --- → mozilla0.8
We're past time to cut these low priority bugs from mozilla0.8. Please update these bugs today.
Target Milestone: mozilla0.8 → mozilla0.9
Keywords: l12y, nsbeta1nsbeta1+
Keywords: nsbeta1+nsbeta1-
Target Milestone: mozilla0.9 → ---
Keywords: nsbeta1-
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.9
No it's not a dupe. It may be causing problems writing an XP content pack but it is an independent problem.
If we're going to add this API we need to do so by mozilla1.0, or decide by then not to.
Keywords: mozilla1.0
Target Milestone: mozilla0.9.9 → mozilla1.0
Summary: Problems about differet directory name of searchplugins → Problems about different directory name of searchplugins
Resetting milestone of all nsbeta1-bugs, only nsbeta1+ bugs should have a target milestone.
Target Milestone: mozilla1.0 → ---
Resetting milestone, only nsbeta1+ bugs can have a milestone on them, these are niminated, but not yet plussed.
The xpinstall script engine has been removed from the trunk, bugs in it are obsolete.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.