User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.54 [en] Build Identifier: In the magnifying glass/quick search window, one can specify "entire message" as the scope of the search. Conversely, the search messages dialog apparently uses "body" to mean the same thing. So, this could be confusing to users to use two terms that mean the same thing. Further, "entire message" should mean the entire thing, body AND headers. However, both the quick search "entire message" and "body" seem to mean "body of email without headers". This also has the potential for confusion. Reproducible: Always Steps to Reproduce: 1a. Go to quick search 2a. Choose "entire message" from the magnifying class 3a. Input a search key known to be in a header, but not body of any email. 1b. Right click on a mailbox 2b. Select Search Messages... 3b. Input a search key known to be in a header, but not body of any email. Actual Results: Both searches returned empty results. Expected Results: For "entire message" I would have expected a hit, for body, not. Since this is part bug, part RFE, here is what I would like to see: 1) What is currently called "entire message" in quick search changed to "body" 2) A feature added to both that really does search the entire message.

(In reply to comment #0) While evaluating Thunderbird as a replacement for Eudora I came across this same issue. I agree with the previous comments and would like to see: Find in entire message // both headers and body. Find in headers Find in body Thanks, Bill

I strongly agree with prior comments; i.e., I would like to see: * Find in entire message // both headers and body. * Find in headers * Find in body

*** Bug 314296 has been marked as a duplicate of this bug. ***

*** Bug 326612 has been marked as a duplicate of this bug. ***

Given that the primary problem with this bug is that the search field is improperly titled, can someone please make the *simple* change to change the text from "entire message" to "body"??? Then we can continue with the RFE for a search that does indeed search the "entire message".

we switched it from body to entire message because in some situations, we were searching over the entire message - cvs blame on the dtd file would probably point to the bug that made us switch it.

Regardless, it's badly confusing. What's needed is to (1) fix the logic to work consistently, (2) properly label that logic, and (3) add an option to search over the entire message (headers and body). What we have now is a real pain, in my opinion currently one of the biggest weaknesses, if not the biggest weakness, in Thunderbird. (In reply to comment #6) > we switched it from body to entire message because in some situations, we were > searching over the entire message - cvs blame on the dtd file would probably > point to the bug that made us switch it.

The enhancement requests here are the same as Bug 229142 and maybe Bug 235908. I agree completely with the user requests here, that "Entire Message" should mean the headers as well, "Body" should mean the message without the headers, and both of those, plus "All Headers" should be available as search options. If mutt did it more than 10 years ago, Thunderbird can do it now. The OS for this bug could be changed to All.

(In reply to comment #8) > The enhancement requests here are the same as Bug 229142 perhaps >and maybe Bug 235908 suite bug

(In reply to comment #8) > The enhancement requests here are the same as Bug 229142 No, that bug refers to the "Search Messages" window. This bug refers to the "quick search" field of the main mail window. >and maybe Bug 235908. Not exactly. That's an enhancement request asking for an "Entire message" search option, which exists. This bug exists because that search option does not in fact search the entire message. (In reply to comment #5) > Given that the primary problem with this bug is that the search field is > improperly titled, can someone please make the *simple* change to change the > text from "entire message" to "body"??? Then we can continue with the RFE for > a search that does indeed search the "entire message". Is it really that hard to just change the data that's being searched so it does what people obviously want? Declaring it a feature by labelling correctly the undesirable behavior seems like quite a cop-out. (I think it's quite a stretch to imagine that people really would prefer to be able to search the body only as opposed to the whole message.) There's code somewhere that can get at the whole message in order to view source. There's also code somewhere to search through a supplied chunk of text for quick search. Plug these two together and it's done. Or am I not seeing some supreme complication deep within the code?

(In reply to comment #10) > Is it really that hard to just change the data that's being searched so it does > what people obviously want? Declaring it a feature by labelling correctly the > undesirable behavior seems like quite a cop-out. (I think it's quite a stretch > to imagine that people really would prefer to be able to search the body only > as opposed to the whole message.) 1. Many of us *do* want to be able to search just the body! 2. We *also* want the *option* in Quick Search of searching headers and body at the same time. 3. We'd like *both* Quick Search options to be named in ways that are meaningful, not misleading, and consistent with other TB searches (e.g., Entire Message for headers and body, Message Body for just the body). 4. We'd also like the option in full Search Messages of searching headers and body at the same time, but that's a different issue.

I can confirm that this is really confusing. I just learned I was using this wrong as long as this feature exists and now I understand, why I never found some messages. I suggest to at least rename this item to "Search Body" as a minimal change but having a really "Search Entire Message" would be great!

(In reply to comment #10) > (In reply to comment #8) > > The enhancement requests here are the same as Bug 229142 > > No, that bug refers to the "Search Messages" window. This bug refers to the > "quick search" field of the main mail window. Quick Search won't get this capacity unless and until the basic back-end search code has gotten it. Adding a dependency here on that bug; if someone thinks that it would be useful to change the text "Entire messag" to "message body", at least until the full-message search is implemented, they should open a new bug specifically for that. > (In reply to comment #5) > Is it really that hard to just change the data that's being searched so it > does what people obviously want? No. What is hard is getting enough people to learn the program well enough to make changes like this. There are thousands and thousands of open bugs of varying degrees of importance, and which bugs are important depends on who is looking at them. There are only a half-dozen people making regular fixes available to the mail side of the program, and because they are not employees but volunteers, they fix the things that look important to them. If you would volunteer instead of kibbitz, this feature would get done quickly. If you think that's an unreasonable attitude, then you need to use other software.

Not everyone who uses OSS is a developer. It is a good idea to gracefully accept feedback (bug reports, suggestions) from non-developers so that the developers can learn what the general public experiences when using the software. The bug report here has several aspects: A) The "entire message" search process is broken - it does NOT search the entire message. This is functionality that is desired. B) A simple fix for *this bug* is to change the quick-search text so that it says what it actually does (search message body). C) A long term fix is to fix search so that "search entire message" does exactly that. When it does, then add back a quick-search menu for "search entire message" at that time. I'm not a developer - I can't make these fixes happen. But I can clarify the bug report and hope that a developer takes the time to incorporate B soon (since this is a simple text fix) and that C gets noted in the appropriate bug entry for "search entire message".

(In reply to comment #13) > (In reply to comment #10) > Quick Search won't get this capacity unless and until the basic back-end search > code has gotten it. Adding a dependency here on that bug; if someone thinks > that it would be useful to change the text "Entire messag" to "message body", > at least until the full-message search is implemented, they should open a new > bug specifically for that. [sigh] OK: Bug 353347 > > (In reply to comment #5) > > Is it really that hard to just change the data that's being searched so it > > does what people obviously want? > > No. What is hard is getting enough people to learn the program well enough to > make changes like this. There are thousands and thousands of open bugs of > varying degrees of importance, and which bugs are important depends on who is > looking at them. There are only a half-dozen people making regular fixes > available to the mail side of the program, and because they are not employees > but volunteers, they fix the things that look important to them. > > If you would volunteer instead of kibbitz, this feature would get done quickly. > If you think that's an unreasonable attitude, then you need to use other > software. With all due respect, that was uncalled for and unhelpful. Not everyone can code; feedback is valuable; and Thunderbird is best served by paying attention to what the market wants.

For what it's worth I fully agree with the previous comments. i.e., I would like to see: * Find in entire message // both headers and body. * Find in headers * Find in body

Might be naming issue here. CC'ing Bryan Clark on this.

At least for naming, pls consider bug 353347 which was "split" from here - see comment 15 should these two be dependent somehow? and related to other quick search improvements bug 372068 or speed bug 383895 (and bug 380898 and bug 312282 ) or somehow related /grouped under a quick search metabug?

The searching should also be made consistent with the "Search Messages" function so that its possible to search the Body and headers without specifying every single possible header where the search term could show up. "Entire Message" should be an optional shortcut (like "To or Cc" is an option now)

Some search thoughts very related to this are on bug 240454 comment 7

This should not be an "Enhancement." This is a bug, given that "Entire Message" is a very different thing from "Message Body" (which is not an option). It tells the user that it will search the entire message, but it fails to do so. How is fixing that an enhancement?

Not only is this a BUG, it's a VERY OLD BUG, that's long overdue for fixing!

Indeed. It has been FOUR YEARS since I filed this bug and all I've seen is finger pointing, state shifting and DIY recriminations. No progress that I can see on actually solving the problem.

The bug's is ancient though its still marked "new" - weird for one that should just require changing the word "Entire Message" to "Body". I've filed a similar, but slightly different bug 476341 where searches for "Body" also incorrectly search the headers (other than specific headers like "Subject").

Every locale must have this line changed: <!ENTITY searchMessageBody.label "Entire Message"> to <!ENTITY searchMessageBody.label "Message Body"> And add this line: <!ENTITY searchEntireMessage.label "Entire Message"> Of course in the locale language.

I'm sick of waiting for this to be implemented so here's a patch. Hope the maintainers will add it in the next version.

(In reply to comment #28) > I'm sick of waiting for this to be implemented ... Me too. Not even assigned. Classified as "enhancement" instead of the BUG it is. Serious black eye for Thunderbird in my opinion. Enough for me to remove the recommendation for Thunderbird from my websites, and think seriously of moving my clients to different, better supported email software. Pity.

Alakdae: please attach a unified diff - put something like diff =-p -U 9 ... into your ~/.hgrc

Unified diff version

Magnus, would you have time to look at these patches?

Comment on attachment 367056 [details] [diff] [review] Changes "Entire message" to "Body" and implements REAL "Entire Message" search Sure. So this creates a "complete" search by adding all the fields in the quick search to the search. That's one approach, I guess.

Comment on attachment 366802 [details] [diff] [review] Changes "Entire message" to "Body" and implements REAL "Entire Message" search Obsoleted by the unified diff.

Comment on attachment 367056 [details] [diff] [review] Changes "Entire message" to "Body" and implements REAL "Entire Message" search This patch doesn't apply, at all. Please make an hg patch against the current tip. <http://developer.mozilla.org/en/Comm-central_source_code_(Mercurial)> >+const kQuickSearchEntireMessage = 4; > // const kQuickSearchHighlight = 4; // * We no longer support this quick search mode..* > const kQuickSearchRecipient = 5; Please don't reuse the 4. >- if (gSearchInput.searchMode == kQuickSearchSubject || gSearchInput.searchMode == kQuickSearchSenderOrSubject) >+ if (gSearchInput.searchMode == kQuickSearchSubject || gSearchInput.searchMode == kQuickSearchSenderOrSubject || gSearchInput.searchMode == kQuickSearchEntireMessage) Wrap the long lines, here and elsewhere, like if (gSearchInput.searchMode == kQuickSearchSubject || gSearchInput.searchMode == kQuickSearchSenderOrSubject || gSearchInput.searchMode == kQuickSearchEntireMessage) >-<!ENTITY searchMessageBody.label "Entire Message"> >+<!ENTITY searchMessageBody.label "Message Body"> >+<!ENTITY searchEntireMessage.label "Entire Message"> > <!ENTITY saveAsVirtualFolderMenu.label "Save Search as a Folder..."> When you change the string you have to change the entity key value too, otherwise localizers can't keep up. (Yes, it's unfortunate.) AFAIKT, it seems to be the message body, so I'm fine with changing that. Not sure "Entire Message" is the best phrase, especially given it's just a "all of the above" kind of choice. How about "Any Field"?

Entire Message seems right to me for this. Though I agree Message Body conflicts so perhaps we change that phrase to "Body Only".

Disappointing to see the version bumped to 3.0b4 without fixing this trivial wording error!

(In reply to comment #38) > Disappointing to see the version bumped to 3.0b4 without fixing this trivial > wording error! Patches welcome :-)

Unfortunately, not all of us are able to write patches... :| Requesting "blocking Thunderbird 3" not just because this age-old bug has 27 votes and 5 duplicates already in spite of being really trivial to fix (I mean the wording part of it, not the extra RFEs)...: Does it make sense to implement all sorts of major backend and UI changes like gloda and experimental search bar, all with the intention of improving the user's search experience, while not fixing as basic a thing as wrong and inconsistent search labels that will obviously spoil basic searching?

Alakdae: can you provide an updated patch?

@Alakdae: Perhaps you can provide "label patch" for bug 353347 as a separate patch? (Explanation below) In reply to my comment #40: I spoke too fast, cause things are complex and a bit messy around this bug. Let me try to sort em out: 1.) As per comment #15, the wording / labelling bug has been moved out to Bug 353347 (Quick Search label "Entire Message" should be changed to "Body"), and my request for "blocking Thunderbird 3" was primarily meant to address the label problem, as has been suggested many times in this bug as a "minimal solution" (comment #5, comment #14 B), comment #17, recent comment #38 and others). 2.) Starting with comment #0, the focus of this bug seems to have shifted towards implementing a new quick search feature "Search entire message" (and possibly additional quick search features "Search header only"). That explains why its importance has been deliberately set to "enhancement" in spite of considerable protest. However, the current summary of bug 271222 (""Entire message" quick search criteria is only the body") is fuzzy and can easily be confused with bug 353347. 3.) Bug 353347 requires a trivial label change and must be way easier to fix than this enhancement request. I conclude that we're having two separate bugs for a reason and that a) the summary of this bug should be improved to better reflect the enhancement request (I'll try that while committing this comment) b) maybe label bug 353347 should be patched first and separately from the enhancement patch that implements "Entire Message" quick search feature. c) "polish" keyword was probably meant for label bug 353347 but IMHO seems inadequate for either of the two bugs as it suggests they are minor which they are clearly not ("polish" should be removed from this bug unless it helps to draw attention) If you disagree or are unhappy with anything I said or changed, please let me know or just change again. I'm still learning (and eager to help get things sorted...) But I do think a lot before I actually change things ;)

Not going to block the TB 3 release on this but that shouldn't work from continuing.

removed "polish" keyword as per comment #42, conclusion c). This seems to require more than "only a small change" which is part of the definition of "polish".

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5pre) Gecko/20091010 Shredder/3.0pre (In reply to comment #41) > can you provide an updated patch? This patch adds much-wanted "Entire Message filter" functionality to quicksearch. This needs one new label (l10n). I tested this on my installation and it works fine. Thanks to Philipp Kewisch for helping with the diff (I'm still new to patches). This search combines nsMsgSearchAttrib.AllAddresses and nsMsgSearchAttrib.Body, which will cover 99% of the use cases. So technically we're not searching the entire header section, but the Subject and "AllAddresses", plus all of the Body. I think this is where we strike a balance between perfection for the sake of perfection and adding basic functionality with great value for everyone. We are also getting rid of this 5-year-old inglorious bug. (Eventually, someone will have to implement nsMsgSearchAttrib.MessageHeader and/or nsMsgSearchAttrib.EntireMessage. We can then add perfection to the backend lateron without touching the frontend/l10n strings).

Comment on attachment 405757 [details] [diff] [review] Add "Entire Message filter" functionality to quicksearch searchEntireMessage.label is not included in the patch >- // create, fill, and append the recipient >+ // create, fill, and append a term for the recipient >+ // we still need to include bcc here Nit: please don't indent it differently. I'd prefer // XXX: need to include bcc here

Yep.

Comment on attachment 405926 [details] [diff] [review] Add "Entire Message filter", nitfix Looks good thx! r=mkmelin Patch complains about "(Stripping trailing CRs from patch)".

You should also have clarkbw ui-r the patch

Bryan, could you ui-review this? Have a look at the new quick filter option by the familiar name "Entire Message filter"... Nothing new here except that it now does what it says... Capitalization: We have "Message body filter", so maybe I should change this to "Entire message filter" (with lower-case for the word message)? Position: "Entire message filter" has always been at the end of the list. Logical order is now: 1) Header filters (in their variants) 2) Body filter 3) Entire message filter (=Header+Body) I think that makes sense.

Comment on attachment 406063 [details] Screenshot of "Entire Message filter" looks like it makes sense. thanks for the detailed screenshot.

Nitfix: change of capitalization pattern to match existing "Message body filter" --> "Entire message filter" (instead of "Entire Message filter") (In reply to comment #48) > (From update of attachment 405926 [details] [diff] [review]) > Looks good thx! r=mkmelin > Patch complains about "(Stripping trailing CRs from patch)". Removed blank line at the end of patch, is that what it was complaining about? Otherwise no changes, Magnus & Bryan could you please set the (ui)review+ flags again? What do I have to do next to get the patch checked in for TB3rc1? Can I set [checkin-needed] on whiteboard?

Comment on attachment 406085 [details] [diff] [review] Add "Entire message filter", nitfix capitalization wow, i read the title but ignored the capitalization of the screenshot and in the comments. nice catch, thanks.

(In reply to comment #52) > Removed blank line at the end of patch, is that what it was complaining about? No it' was complaining about you using a Windows editor where each lines ends up with CRLF while in unix/mac it's only LF. Double check your .hgrc conf file as I think that's the way to make hg diff behave correctly. > Otherwise no changes, Magnus & Bryan could you please set the (ui)review+ flags > again? > > What do I have to do next to get the patch checked in for TB3rc1? > Can I set [checkin-needed] on whiteboard? use the cheking-needed keywords is the thing to do.

(In reply to comment #54) > > Otherwise no changes, Magnus & Bryan could you please set the (ui)review+ flags > > again? > > > > What do I have to do next to get the patch checked in for TB3rc1? > > Can I set [checkin-needed] on whiteboard? > > use the cheking-needed keywords is the thing to do. Generally in this case it is better to say [ready to land after branch] - going through the [needs branch] bugs will be something to happen after we've branched. It is preferred not to add it until you have all the review flags necessary. Of course, once the branch has happened, then you are welcome to add checkin-needed to the keywords though.

Comment on attachment 406085 [details] [diff] [review] Add "Entire message filter", nitfix capitalization [checkin-needed] This patch is ready for checkin (review+ per Magnus' comment #48, ui-review+ for final capitalization nitfix per Bryan's comment #53). Simon, there's one new l10n string in http://mxr.mozilla.org/comm-central/source/mail/locales/en-US/chrome/messenger/quickSearch.properties: +searchEntireMessage.label=Entire message filter Simon, is there a way to provide a comment on this string for localizers' attention? We had this label's text in TB2 quicksearch before but it used to mean "body" whereas now it actually means "Entire message filter" aka header+body. This is basic filtering functionality, valuable and much-wanted (see votes). It would be much appreciated if this could land for TB3rc1. (Actually people will see it as a regression if we don't, because TB2 already had this filter albeit it was wrongly labelled and thus didn't work as expected - bug 353347).

(In reply to comment #56) > This is basic filtering functionality, valuable and much-wanted (see votes). It > would be much appreciated if this could land for TB3rc1. We are now in string freeze which means we cannot land new strings without a very good reason (especially as localisers have started opting in). > (Actually people will see it as a regression if we don't, because TB2 already > had this filter albeit it was wrongly labelled and thus didn't work as expected > - bug 353347). I don't see that as a regression, and the global search does much of that functionality anyway.

(In reply to comment #56) > This patch is ready for checkin (review+ per Magnus' comment #48, ui-review+ > for final capitalization nitfix per Bryan's comment #53). As mark already said, this patch will introduce a new string during the string freeze. We will only break the string freeze in very rare cases, where the benefit of this fix would clearly outweigh the cost (50 locales would need to do additional work). Therefore this should be targeted towards 3.1a1. > Simon, there's one new l10n string in > http://mxr.mozilla.org/comm-central/source/mail/locales/en-US/chrome/messenger/quickSearch.properties: > > +searchEntireMessage.label=Entire message filter > > Simon, is there a way to provide a comment on this string for localizers' > attention? We had this label's text in TB2 quicksearch before but it used > to mean "body" whereas now it actually means "Entire message filter" aka > header+body. Just add a localization note, modeled after the example at http://mxr.mozilla.org/comm-central/source/mail/locales/en-US/chrome/messenger/glodaFacetView.dtd where you clearly describe the intent and the meaning of the added string.

(In reply to comment #58) >Just add a localization note, modeled after the example at >http://mxr.mozilla.org/comm-central/source/mail/locales/en-US/chrome/messenger/glodaFacetView.dtd >where you clearly describe the intent and the meaning of the added string. This is a better example for a .properties file: http://mxr.mozilla.org/comm-central/source/mail/locales/en-US/chrome/messenger/glodaComplete.properties#38

Mark, Simon: You people are really a major problem. This bug is FIVE YEARS OLD and when someone finally gets to finishing it, you create hurdles for them to put it into the code. The age of this bug alone should be a "very good reason" for putting it in rc1. So stop focusing on the minutae of your process and try focusing on what the users actually want. Which seems more critical to you user base: having a feature that many people have voted for, but is missing say, the Croatian localization because it got in late or not having the feature at all?

(In reply to comment #60) > So stop focusing on the minutae of your process and try focusing on what the > users actually want. Which seems more critical to you user base: having a > feature that many people have voted for, but is missing say, the Croatian > localization because it got in late or not having the feature at all? Glenn, it is no longer useful or wanted to have incomplete localisations of Thunderbird or other products - English isn't the only language we ship in, and including this now would involve extra work for all localisations (some of whom have already completed their Thunderbird 3 work) and these are all volunteers. It also constitutes feature creep and although we haven't strictly said we are in feature freeze having the UI strings frozen means that we effectively are, and me also must reduce the scope for additional bugs creeping in between the last beta (beta 4) and the final release. I am grateful that Thomas has supplied the patch, however it unfortunately missed the deadline. It is not lost, we will be branching within two weeks and so the patch will be able to be checked in to the code base at that time and is therefore certain to become part of Thunderbird after the 3.0 version.

Glenn, the "hurdles" as you call them are necessary to ship a product with 50 locales simultaneously. This is very important for a lot of users given the fact that the majority (that means more than 50%) of our users and our downloads come from countries were English is not the native language. Given the fact that we're only shipping complete localizations this could become a make or break decision. That may be unfortunate for some people (especially those with an US-centric POV) but we have to look at our overall userbase and not just small parts of it. As Mark says, this patch will be in TB 3.1, most likely already its first alpha release.

Comment on attachment 406085 [details] [diff] [review] Add "Entire message filter", nitfix capitalization Looks good, however, there's something wrong with this patch. patch -p1 < attachment406085 [details] [diff] [review].pacth (Stripping trailing CRs from patch.) patching file mail/base/modules/quickSearchManager.js (Stripping trailing CRs from patch.) patching file mail/locales/en-US/chrome/messenger/quickSearch.properties patch unexpectedly ends in middle of line patch: **** malformed patch at line 163: To be clear, you shouldn't manually change anything in the patch file. Just do the fixes in the files, then do "hg diff > bugxxx.patch" (or hg export) Similar for hg import: magnus@magnus-desktop:/opt/comm-central/src$ hg import --no-commit /opt/review/attachment406085 [details] [diff] [review].patch applying /opt/review/attachment406085 [details] [diff] [review].patch patching file mail/base/modules/quickSearchManager.js Hunk #1 FAILED at 19 Hunk #2 FAILED at 75 Hunk #3 FAILED at 111 Hunk #4 FAILED at 162 Hunk #5 FAILED at 199 5 out of 5 hunks FAILED -- saving rejects to file mail/base/modules/quickSearchManager.js.rej patching file mail/locales/en-US/chrome/messenger/quickSearch.properties Hunk #1 FAILED at 0 1 out of 1 hunks FAILED -- saving rejects to file mail/locales/en-US/chrome/messenger/quickSearch.properties.rej : No such file or directorychManager.js : No such file or directoryessenger/quickSearch.properties abort: patch failed to apply

For me https://bugzilla.mozilla.org/attachment.cgi?id=406085 applies just fine. I'm applying it to a current trunk tree. I only get a " patch unexpectedly ends in middle of line patch: **** malformed patch at line 163: " message. This patch doesn't do that, if that matters.

Yeah but it doesn't include the searchEntireMessage.label value either (because as patch said, the patch is malformed).

Hi, sorry for the confusion, probably just a patch newbie mistake, see my comment #52: > > Patch complains about "(Stripping trailing CRs from patch)". > I Removed blank line at the end of patch, is that what it was complaining about? Ok, please be patient with a newbie to patches and notice the following: - This patch re-adds the missing LF at the end of the patch. This should fix the problem "patch: **** malformed patch at line 163:". - I converted CR-LFs into unix LFs. This should fix the problem "Stripping trailing CRs from patch.". - Otherwise, this patch is different from patch of attachment 405926 [details] [diff] [review] (with Magnus' review+) only in one single letter (capitalization): "Entire /m/essage filter". IOW, if patch of attachment 405926 [details] [diff] [review] applied correctly, then this patch should apply correctly, too. Unless... - I have not checked the underlying source code for changes, no reason to assume it did. If the underlying source code changed, we'll need a new diff for this. - FTR, I do NOT have a build environment set up, I can only commpare manually against files from MXR. I don't know if MXR represents trunk or branch. - I am using WinMerge to create the diffs. Magnus, thanks for looking into this. Could you try this patch with my comments in mind and report back what you get?

Comment on attachment 406406 [details] [diff] [review] Add "Entire message filter", nitfix missing LF at EOF, unix LFs This works fine, thx!

We have now branched comm-1.9.1 (I think). Setting checkin-needed.

(In reply to comment #68) > We have now branched comm-1.9.1 (I think). Setting checkin-needed. No we haven't. We have created the branch repository but we have NOT officially branched.

(In reply to comment #69) > (In reply to comment #68) > > We have now branched comm-1.9.1 (I think). Setting checkin-needed. > > No we haven't. We have created the branch repository but we have NOT officially > branched. Oh, sorry, it's October 22nd, apologies for that! http://ccgi.standard8.plus.com/blog/archives/302

Checked in: http://hg.mozilla.org/comm-central/rev/f777867964d1

Mark, thanks for checking this in to trunk. Please land the nitfix patch attached on top of the previous patch. nitfix: There's an unreadable u-umlaut character in my name, because I was using the wrong charset. UTF8 without BOM seems to be the correct format.

Comment on attachment 414032 [details] [diff] [review] nitfix broken umlaut in contributors [on top of patch of attachment 406406 [details] [diff] [review]] I actually had to work this out by hand as patch didn't want to apply it. However, at least I know how to get emacs into the right mode for saving now :-) Fixed: http://hg.mozilla.org/comm-central/rev/31c40ccc31f8

Thank you!

It's possible implement this feature in an extension for TB3.0? It's great!!

Simon, this bug has l10n impact: it introduces a new label. Anything we still need to do to get this translated, like setting flags etc? > +++ b/mail/locales/en-US/chrome/messenger/quickSearch.properties > +searchEntireMessage.label=Entire message filter What's the actual status of this bug? (in reply to Mark's comment 61) > the patch will be able to be checked in to the code base at that time and is > therefore certain to become part of Thunderbird after the 3.0 version. (in reply to Simon's comment 62) >...most likely already its first alpha release. Looking at Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100119 Shredder/3.0.2pre, this hasn't landed there yet. As has been promised, this bug should be included in the next minor update of Thunderbird 3.0. It's - much-wanted (28 votes, and comment 75 :) - age-old (2004) - high-value - low-risk - review+ --> please land this in the 3.0.x branch.

(In reply to comment #76) > Simon, this bug has l10n impact: it introduces a new label. > Anything we still need to do to get this translated, like setting flags etc? No, nothing to do, locales will pick it up in due course. > What's the actual status of this bug? This bug is fixed in Thunderbird 3.1 Alpha 1 and later builds. > (in reply to Mark's comment 61) > > the patch will be able to be checked in to the code base at that time and is > > therefore certain to become part of Thunderbird after the 3.0 version. It appears my comment was not clear enough. As we have a string change in this patch, it can only become part of Thunderbird in the next major release after 3.0. Minor releases cannot accept string changes. > As has been promised, this bug should be included in the next minor update of > Thunderbird 3.0. No, it was not promised. The only thing that was said is that it could land for the 3.1 builds, which it already has done. Unfortunately it appears the comments weren't clear enough and/or misunderstood. > --> please land this in the 3.0.x branch. Sorry, but string changes are just not allowed on a stable branch and this bug is therefore wontfix on that branch.

Mark, thanks for the clarification. Yes, comments weren't clear enough and/or misunderstood *sigh*. Looking at the timetable on https://wiki.mozilla.org/Thunderbird:Thunderbird3.1, I understand we'll see this feature available for the general public on April 6, 2010, God willing. That's 6 months after the accepted patch was provided on 2009-10-14. I appreciate that's pretty quick if compared with the former development cycles of TB. However, IMHO there's still room for improvement on the often-mentioned new "agility" of the process. 6 months seems too long for as essential a feature as full-text filtering with only three words to translate. Personally, I can't imagine localizers would feel strained if you feed them a couple of words or sentences, say, every 3 months. Or maybe the localization system could be changed in a way that allows localizers to be notified immediately about new needed strings, so that they can optionally translate them in the time between major releases, without any pressure or deadlines. We could send a monthly summary to localizers with a tabular breakup stating how many percent of the languages have already translated a given string, and if the translation in their language is still missing or not. Perhaps with some advertising in the notification, we'd be surprised to see the strings universally translated /before/ the next major release.

Thomas, I think its clear you're not understanding our processes. We had a 4 to 5 week string freeze before the first release candidate of TB 3 to allow our locales (all done by volunteers) to finish localising the release - not only translating the strings, but having a stable period to do QA and testing that they needed to do. Some teams do not have the members to do it in little bits all the way round the year. Unfortunately this patch missed the deadline. Therefore it missed TB 3. It will get in the next release. Some patches make it, some don't - that is always going to be an issue around release time especially when we're starting to try and ensure stability in the builds. Anyway, bugzilla isn't the right place for this discussion. I suggest you raise it on mozilla.dev.apps.thunderbird if you still have concerns.

I don't claim I fully understand all the processes and details of localization, versioning and branching, but I think I know some of the basics. I was actually mentioning initial ideas that propose *changes to the current processes* to avoid unsatisfactory situations like this in the future. For the degree of dissatisfaction, comment 60 might be a good indicator, even though it's emotional and probably much less aware of the processes. I see from your comment 79 that if at all, you want such potential changes discussed on the newsserver (which for me personally is a hurdle that I'm unlikely to take). Finally, thanks for your immediate responsiveness. A factual and respectful response is always helpful to better understand the processes, which aren't very transparent for people who aren't immediately involved. Explanatory responses can make us contributors feel heard und understood while clearing up misunderstandings that me may have about these complex processes.

(In reply to comment #78) > However, IMHO there's still room for improvement on the often-mentioned new > "agility" of the process. 6 months seems too long for as essential a feature > as full-text filtering with only three words to translate. Personally, > I can't imagine localizers would feel strained if you feed them a couple of > words or sentences, say, every 3 months. If those were the only words or sentences, then they certainly wouldn't feel strained. The reality however is, that we have very few localizers who work on Thunderbird exlusively. Most work on other mozilla.org projects as well (Firefox, Firefox Mobile, Lightning, SeaMonkey, Kompozer), some even add to that other major Open Source projects like KDE, OpenOffice.org or GNOME. Add to that that nowadays, we do not only ask localizers to localize the actual product, but web content for the respective product as well, and you'll begin to grasp, why we try to make our processes as non-invasive as possible for localizers. These people are hard to come by, especially for less-popular languages, harder even than developers. Therefore we try to take good care of them and keeping the promise of a string freeze (except for security-related string changes) falls into that category. > Or maybe the localization system could be changed in a way that allows > localizers to be notified immediately about new needed strings, so that > they can optionally translate them in the time between major releases, > without any pressure or deadlines. We could send a monthly summary to > localizers with a tabular breakup stating how many percent of the > languages have already translated a given string, and if the translation > in their language is still missing or not. Such a tool is already available in real-time for more than 16 months. It is called the l10n dashboard and is available at http://l10n.mozilla.org/dashboard/ Like Mark said, your lack of knowledge of our processes leads you to false assumptions. Please rest assured (this coming from the responsible localization coordinator), that we feel your pain with regards to this bug. We do not intentionally try to make you or anyone else here unhappy. But these things happen for a reason, which Mark and I have tried to lay out to you.