Now that mailnews has moved, we should move ldap.properties to somewhere sensible for suite as well. http://mxr.mozilla.org/seamonkey/source/directory/xpcom/base/resources/locale/en-US/ldap.properties Thunderbird has this in: mail/locales/en-US/chrome/mozldap/ldap.properties which is the only file in the folder, the resource URI (which we can't change 'cause TB uses it as well) is: chrome://mozldap/locale/ldap.properties 1) Do we want to put it in suite/locales/en-US/chrome/mozldap/ldap.properties or somewhere else? 2) Do we want to just move it manually (rather than requesting a cvs copy) as there's not much history on the original (http://bonsai.mozilla.org/cvslog.cgi?file=/mozilla/directory/xpcom/base/resources/locale/en-US/ldap.properties&rev=HEAD&mark=1.3)

1) The location sounds fine 2) I believe this is up to the module/file owner. But I guess there's not much history dmose would want to preserve ;-)

Patch that does the move. I've tested this on toolkit & xpfe versions of SeaMonkey and found that we don't actually need the content definition for mozldap. The best way to test this patch is with a authenticated ldap connection - request a search and check the password dialog comes up ok.

Comment on attachment 260953 [details] [diff] [review] Patch v1 Having hacked on the xpfe chrome registry I can assure you that without a content package you can't look up the selected locale. I double-checked this on an xpfe build that has never built ldap before (and therefore doesn't have any old mozldap chrome) and it certainly does not work. That said, I guess the best way to fix this is to not delete directory/xpcom/base/resources/content/contents.rdf but instead to #ifndef MOZ_XUL_APP it in the jar.mn for now; sr=me with that fixed.

(In reply to comment #3) > (From update of attachment 260953 [details] [diff] [review]) > Having hacked on the xpfe chrome registry I can assure you that without a > content package you can't look up the selected locale. I double-checked this on > an xpfe build that has never built ldap before (and therefore doesn't have any > old mozldap chrome) and it certainly does not work. Strange seeing as I did a clobber of my xpfe build objdir and it worked. Anyway your alternate suggestion was my backup plan, so I'll do a new patch for that tomorrow.

Leaves the contents info alone for xpfe builds, moves locale info to /suite for both.

Dan has just given me r+ over irc for moving ldap.properties etc without history.

Comment on attachment 260988 [details] [diff] [review] Patch v2 OK, looks good. I wondered that new chrome registry accepts a locale entry without a content one, but apparently this works fine.

Patch checked in -> fixed.