97541 - Enable multiple spellcheckers in mail/composer

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P3)

Description

[[e-mail] (away - not reading bugmail)]

this is a copy of a Netscape commercial bug concerning dowload of additional 
spellchecker libraries. The spellchecker code lives for the most part in the 
Mozilla tree and the chekin requires driver's approval - hence the reason for 
filing this Bugzilla pendant of Bugscape 8476 
(http://bugscape.mcom.com/show_bug.cgi?id=8476).

Add spell checking functionality for mulitiple languages to Netscape Mail and
Composer. Per AOL legal, AOL and its brands have the license to use multiple
Learnout and Hauspie's spellcheck dictionaries in their products. 
Needed to implement this feature in Netscape 6:
- UI proposal (design agreed through UI team, but not implemented)
- Packaging of .dat dictionary files as .xpi packages
- Hosting of .xpi files on Netscape.com web site

Need engineering resources assigned for UI and xpi work.
Target for emojo release


------- Additional Comments From [e-mail] 2001-08-07 16:54 -------

reassigning to myself, cc'ing potentially interested i18n/l10n folks


------- Additional Comments From [e-mail] 2001-08-14 13:25 -------

accepting, targeting 0.9.4. I'll be attaching a patch shortly. Incidentally, 
most of the changes are in the Mozilla source, so maybe we need to make that 
part public.

I found the ftp location of language packs and I'd suggest that we put the 
spellchecker xpi files there as well. I'll try to identify the people maintaing 
this ftp server.

ftp://ftp.netscape.com/pub/netscape6/langpacks/6.01

Another thought: besides creating this dedicated UI for spellchecker download, 
it would be fairly easy to make them part of the regular language pack 
download. We would only have to modify the server-side JS file sequencing the 
xpi packages, which is located here:

http://home.netscape.com//fr/download/6/langpack.js

I could come up with a modified script and we'd only have to persuade the 
Netcenter folks to use it. This would provide alternative coverage for 5 out of 
the 15 languages we are offering spellcheckers for. What do you think? 

Another idea - we probably should have a dedicated HTML page for spellchecker 
download derived from the existing lang pack page:

http://home.netscape.com/computing/download/languagepacks.html. 

Alternatively, I could come up with server-independent UI, but perhaps for 
consistency (and to help drive Netcenter traffic) it might be preferable to get 
a dedicated page for spellchecker download.



------- Additional Comments From [e-mail] 2001-08-14 17:18 -------

Has the decision being made about whether the spellcheckers should be part of
the langpacks? Just want explore an extra option.


------- Additional Comments From [e-mail] 2001-08-14 17:27 -------

tao - oh, that would be really nice :-) Including them in the language pack 
would reduce the number of files to be downloaded for a given locale and 
thereby improve the overall user experience.


------- Additional Comments From [e-mail] 2001-08-14 18:13 -------

What's the size of these xpis?


------- Additional Comments From [e-mail] 2001-08-14 18:17 -------

Created an attachment (id=2638)
first prototype-quality patch (contains a hard-coded menu item and test ftp URL)



------- Additional Comments From [e-mail] 2001-08-14 18:20 -------

Created an attachment (id=2639)
screenshot of the modified spellchecker dialog (spchk_download.jpg)



------- Additional Comments From [e-mail] 2001-08-14 18:22 -------

Created an attachment (id=2640)
provisionary download page on Frank's server (spchk_download_page.jpg)



------- Additional Comments From [e-mail] 2001-08-14 18:26 -------

I believe we should put the "Download More" item first not last. I had some 
technical difficulties with that and the original design proposal called for 
the last spot, so it's there for now. 

What do you think of putting it first? Also, do you like a new browser window 
being spawned or should we reuse an existing browser window from the 
background? I can come up with a download page design, but will the Netcenter 
folks sign off on that or does it have to be produced by them?


------- Additional Comments From [e-mail] 2001-08-14 18:28 -------

tao - have a look at ftp://ftang/pub/spell. They are pretty large - around 300K 
on average. This might has potential of easily doubling the lang pack size :-(


------- Additional Comments From [e-mail] 2001-08-14 18:32 -------

for easier reference: here is Jen's informal spec forwarded to me by bobj:

Discoverability:
In the Spell checker dialog box under the language pulldown menu we add a bar 
and below it something like "More Dictionaries". This would link to a page on 
Netscape.com with the additional Latin-1 spell checkers. An alternative would 
be to add a button on the spell checker dialog box itself that says something 
like "Add Dictionaries" 
Either one would open a new browser window to a spell checker download page. 

Once the user clicks on the link, it initiates the download and installs a new 
dictionary. The choice dynamically shows up in the pull down menu. The user 
would need to choose the dictionary. This dictionary as the default looks to be 
sticky upon each launch of the app with the current builds we've seen. 

Additional Discoverability:
In addition to the above, we suggest the following to make this functionality 
more discoverable: a tiny arrow, similar to one used for Print, to give the 
user the ability to select "Spell checker options." This would bring up the 
spell checker dialog box and enable the user to either add words to their 
personal dictionary or add additional language dictionaries. 

These suggestions would be for both mail and composer. 



------- Additional Comments From [e-mail] 2001-08-14 18:35 -------

Jen? Is this going in the direction you intended? BTW this would require some 
additional work:

"The choice dynamically shows up in the pull down menu. The user 
would need to choose the dictionary. This dictionary as the default looks to be 
sticky upon each launch of the app with the current builds we've seen."

Depending on the time available to us, we might want to defer such things to 
the second stage and address it in a bug later...


------- Additional Comments From [e-mail] 2001-08-14 18:43 -------

If the xpis are this big, we probably do not want always bundle them in the
langpacks. A download page for them would be sufficient.


------- Additional Comments From Jennifer Mulcaster 2001-08-15 10:51 -------

Sorry to be quiet on this project so far this week. 

Language pack bundling could double the size of those packs. While it's logical,
it could also make the user experience more difficult to pack installation. 
On the topic of UI, including "download more" in the pull down is
sufficient since we want to drive people to the site to see what's available and
what they can install. 
I've cleared this with the Netscape.com international team and they will support
including a dedicated HTML page that lists what is available, similiar to how we
treats packs. 
We are still in the process of making the ftp site live with the XPIs. Right
now, they are on a blind FTP location. If you know the complete file name, you
can access them for testing:  ftp://ftp.netscape.com/pub/netscape6/spellchecker/


------- Additional Comments From [e-mail] 2001-08-15 22:32 -------

Created an attachment (id=2669)
cleaned-up patch, removed hard-coded strings, debug dumps, improved usability, 
fixed spellchecker sorting



------- Additional Comments From [e-mail] 2001-08-15 22:45 -------

Jen: thanks for clarifying this and for contacting the Netcenter folks. I went 
ahead and polished the rough, prototype-level implementation. The patch should 
we in "checkinable" state now. I'm cc'ing Charlie Manske for as composer module 
owner for technical review. 

I'm still using a provisionary URL pointing to Frank's internal FTP server. I 
assume that Netcenter will need a while to come up with the download page and I 
recommend checking in the provisionary URL and modifying it later, possibly 
with PDT approval, should it get that far. Since it would be a one-line change, 
it's going to be much easier to get an late-stage approval for it. 

I'm very anxious to have to bulk of the changes in as soon as possible. If we 
succeed in that, we might also have enough room to  fix the dynamic 
spellchecker list update for the eMojo release. I'll have QA file a bug for 
that, once this is checked in.

cmanske: could you spare a minute to gives us feedback, whether we are headed 
the right way? Thanks a lot!



------- Additional Comments From [e-mail] 2001-08-15 22:50 -------

Created an attachment (id=2670)
spellcheck_dialog.jpg



------- Additional Comments From [e-mail] 2001-08-16 15:59 -------

cmanske, tao: 
could you please have a quick look? What do you think?


------- Additional Comments From [e-mail] 2001-08-20 12:01 -------

Jen,

do you when Netcenter can have the download page ready? We need to have it 
before I can check in the feature with a test link or hythetical link. I just 
spoke with Frank and he is really concerned that it will not happen in time for 
eMojo.


------- Additional Comments From Jennifer Mulcaster 2001-08-20 17:00 -------

Spoke to Evelyn ([e-mail]) in intl netcenter today and she will take
the HTML page jbetak creats for the spellchecker downloads and push them to the
site. I've let her know that timing is this week. 
Also, before we proceed further, I checked in with AOL Legal about unbundled
distribution of these libraries as XPIs. My contact there Jim Bramson will be
getting back to to Frank and I in the next 24 hours. 



------- Additional Comments From [e-mail] 2001-08-21 12:47 -------

Created an attachment (id=2744)
modified download link to point to future Netcenter spellchecker page



------- Additional Comments From [e-mail] 2001-08-21 12:50 -------

I just modified the patch to point to
http://home.netscape.com/computing/download/spellcheckers_61.html, which will
have to be the future download page for spellcheckers. I'll try to get this
reviewed and super-reviewed today, but once it's checked in, it might be tough
to change the link due to the code freeze. Hence the page will have to be pushed
to http://home.netscape.com/computing/download/spellcheckers_61.html...

cc'ing evelyn




------- Additional Comments From Evelyn Prime-MacAdam 2001-08-21 14:36 -------

Are spellcheckers not forwards compatible? Reason I ask is that we don't like 
assigning URLs with browser numbers, unless completely necessary. Pls advise.


------- Additional Comments From [e-mail] 2001-08-21 15:04 -------

Evelyn, thanks for pointing this out! 

Bob - do we know, how often - if at all - the spellcher binaries will change in
future relases?


------- Additional Comments From [e-mail] 2001-08-21 17:07 -------

r=tao on this patch: http://bugscape.mcom.com/showattachment.cgi?attach_id=2744
08/21/01 12:47

Q: why are there two diffs for builtinURLs.rdf?


------- Additional Comments From [e-mail] 2001-08-24 16:44 -------

Created an attachment (id=2833)
this patch addresses the Mac window modality issue



------- Additional Comments From [e-mail] 2001-08-24 16:46 -------

kin / cmanske / sfraser:

could you please put your stamp of approval on this, if possible? I'd like to 
get the driver's approval soon, as time is running out...


------- Additional Comments From [e-mail] 2001-08-24 16:46 -------

assuming that the bulk of the work on the client is finished, I'll start 
working on the download page for Netcenter today and tomorrow...


------- Additional Comments From [e-mail] 2001-08-27 12:00 -------

I don't think we will change the dictionary in the future. Probably we should 
not put a version for now. And while we need one, we could change it later. 


------- Additional Comments From [e-mail] 2001-08-27 13:06 -------

Created an attachment (id=2842)
Updated patch - this removes the version number from the Netcenter link as 
requested by ftang and evelyn



------- Additional Comments From [e-mail] 2001-08-27 13:58 -------

> Bob - do we know, how often - if at all - the spellcher binaries will change 
in
> future relases?

My understanding is that the current implementation has hardcoded version #s for
the spellcheck data files.  There is no way to use different versions
without getting a new binary.  We do have newer dictionaries, but cannot use
them until we change the spellcheck code to either hardcode the new version #s
or be more flexible.  Kin, Is this correct?




------- Additional Comments From Joaquin Blas 2001-08-27 14:13 -------

The INSO spellchecker code has a hardcoded table that maps language/dialect to 
filenames. If there are dictionaries for languages/dialects that aren't in the 
table, or if the name of a dictionary file changes, the spellchecker will not 
find/use it.


------- Additional Comments From Joaquin Blas 2001-08-27 14:22 -------

Comment on the 08/27/01 13:06 attatchment:

I think you need to move the calculation of the defaultIndex in 
InitLanguageMenu() to be inside the 2nd loop that appends the items to the 
menu, 
because sorting the list may change the position of the default item in the 
list.


------- Additional Comments From [e-mail] 2001-08-27 14:44 -------

Thanks for looking at this kin! OK, I'll change it, since it appears less 
confusing. However, I don't think that  sorting affects the default items, 
since both the "Download More" menu item and the menuseparator live in XUL and 
the sort affects only the JS arrays used to append additional items to the 
dropdown.

+        <menulist id="LanguageMenulist" class="small-margin">
+          <menupopup>
+            <menuitem value="more-cmd" label="&moreDictionaries.label;"/>
+            <menuseparator/>
+            <!-- dynamic content populated by JS -->
+          </menupopup>
+        </menulist>


------- Additional Comments From [e-mail] 2001-08-27 15:09 -------

Created an attachment (id=2843)
Updated patch - moved the defaultIndex calculation to the second loop (after 
the sort)



------- Additional Comments From Charles Manske 2001-08-27 16:04 -------

I tested the latest patch.
The browser window to do the new dictionary dialog seems to be modal to the 
spellchecker window. Does that solve the modal problem on Mac?
I though the wording of the message in the intervening dialog was a bit unclear;
I expected it to close the spellchecker (or even the Composer) window. I don't 
think you need that -- just say "
Is the dictionary downloading and installation supposed to work? I selected 
one item to download and it seems to be stuck in the "Software Installation"
dialog with the "Downloading..." message. Clicking on Cancel or "X" doesn't 
close that window. Wait! I now see some errors in console window about not 
finding: 
file jar:resource:///chrome/modern.jar!/skin/modern/global/animthrob_single.gif
and this is causing an assertion in FTP download.


------- Additional Comments From [e-mail] 2001-08-27 16:16 -------

cmanske, thanks for looking at this!

>I expected it to close the spellchecker (or even the Composer) window. I don't 
>think you need that

Yes, I'd need to remove the message altogether, if we go with the new browser 
window modal to the spellchecker window. I rolled up a patch last week, where 
the spellchecker window would close and the existing browser window will be 
redirected to the download page. However I experienced problems with losing 
focus to the composer window upon closing the spellchecker. The download page 
would be then displayed in the background window, which is unacceptable. That's 
when I decided to try a new modal browser window to circumvent the Mac modality 
issue.

>it seems to be stuck in the "Software Installation" dialog with 
>the "Downloading..." 

I've occasionally seen this and believe it might be related to the xpi package 
content. I'll look into this, although we might have more time to address 
server-side issues before the eMojo release.




------- Additional Comments From Charles Manske 2001-08-27 16:28 -------

As long as we don't get stuck in a modal browser window because of a download
error, that strategy seems ok. The focus issues are real annoying, aren't they!
(I've run into that starting a browser from the Open Location dialog).
So I'd remove the message dialog as you suggest or modify the message.
r=cmanske for rest of the editor code.


------- Additional Comments From [e-mail] 2001-08-27 16:43 -------

thanks cmanske! Modified patch coming up, I'll go with the modal browser 
window, seems to be the only sensible option right now. I'll have to see, how 
to prevent the download hangers. 

cc'ing Sean Su. Sean - have you seen some issues with xpi downloads in recent 
builds? I've had some intermittent problems when testing and here is a 
description cmanske came up with:

>selected one item to download and it seems to be stuck in the "Software 
>Installation"dialog with the "Downloading..." message. Clicking on Cancel 
>or "X" doesn't close that window. Wait! I now see some errors in console 
>window about not finding: 
>file jar:resource:///chrome/modern.jar!/skin/modern/global/animthrob_single.gif
>and this is causing an assertion in FTP download.

Would you have any idea?



------- Additional Comments From Joaquin Blas 2001-08-27 17:41 -------

> I don't think that  sorting affects the default items, 
> since both the "Download More" menu item and the menuseparator live in XUL 
and 
> the sort affects only the JS arrays used to append additional items to the 
> dropdown.

The defaultIndex that was calculated is actually the position of that item in 
the menu, so if you calculate the index before the list is sorted, and 
thenbuild 
the menu with the order of the sorted list, there's a good chance the item 
displayed as the default is the wrong one.

In your new patch the defaultIndex should be ok, but one thing I should've 
caught and mentioned earlier was that the order of the dictList and menuStrList 
need to be kept in sync, since the string in the dictList is the value 
(dictionary name) that is used to tell the spellchecker what dictionary to use. 
In the current patch you are sorting menuStrList and not dictList, 
so when you append a menu item with menuStrList[i] and dictList[i], their 
values 
might not match.


------- Additional Comments From [e-mail] 2001-08-27 17:58 -------

kin, oops - you are obviously correct, how embarrassing. I'd recommend baking 
those two strings into one array, that would solve the synchronicity issue, 
wouldn't it? I'll repost the patch in a minute.


------- Additional Comments From [e-mail] 2001-08-27 20:07 -------

Created an attachment (id=2850)
Updated patch - addressed the dictionary sorting issue raised by kin



------- Additional Comments From [e-mail] 2001-08-27 20:11 -------

Created an attachment (id=2852)
Updated patch - addressed the dictionary sorting issue raised by kin (and 
removed a dump I unintentionally left in the source)



------- Additional Comments From [e-mail] 2001-08-28 11:33 -------

kin,

what do you think - could you sr now?


------- Additional Comments From Joaquin Blas 2001-08-28 16:58 -------

Comments/Questions regarding the 08/27/01 20:11 patch:

* It looks like you fixed the sorting problem with a 2 dimensional array, but
  since you are allocating an array of 2 elements for each entry in the
  dictList, you should probably stick to using 0 and 1 as the index into
  array at dictList[i]:

     ie: distList[i][0]
         dictList[i][1]

  Your patch currently uses 1 and 2 as the index which forces the array
  to automatically reallocate a 3 element array when you use the 2
  index ... that's why you don't get a JS error.

* So after the user downloads the new dictionaries, what are we doing
  to restart the Spellchecker? I ask because the spellchecker ui gets
  the list of dictionaries from the Spellchecker backend, which has to be
  restarted to pick up the new dictionaries you just downloaded and installed
  in components/spellchecker.



------- Additional Comments From [e-mail] 2001-08-28 17:30 -------

>* So after the user downloads the new dictionaries, what are we doing
>  to restart the Spellchecker? I ask because the spellchecker ui gets
>  the list of dictionaries from the Spellchecker backend, which has to be
>  restarted to pick up the new dictionaries you just downloaded and installed
>  in components/spellchecker.

currently nothing, since closing the spellchecker window transfers focus to its 
parent window, which happens to be the composer. This means that the download 
browser window would lose focus, which is bad. I played it in different ways 
with and w/o delay, still I couldn't prevent the "stealing" of focus. 

About the only thing I think of, is resurrection of the popup message alerting 
the user that the changes won't take effect until the next spellchecker start.





------- Additional Comments From [e-mail] 2001-08-28 17:39 -------

Created an attachment (id=2864)
modified array indexes to start from 0 - seems like I've spent too much time 
with JDK coding



------- Additional Comments From Jaime Rodriguez, Jr. 2001-08-29 11:57 -------

Jbetak - Pls send an email out requesting sr/a = ASAP. Let's get this one closed
out.


------- Additional Comments From Joaquin Blas 2001-08-29 12:56 -------

jbetak, thanks for fixing the indexes. I trust that you verified
that selecting the various dictionaries from the menu, pass the
correct dictionary name to the backend?

The patch is a good first step, but we need to make sure we
consider the following issues before checking this in for
0.9.4:


  1. The spellchecker UI gets the list of dictionaries
     from the spellchecker backend. The spellchecker
     backend needs to be restarted for it to recognize
     the new dictionaries.

  2. If you restart the spellchecker backend, we need
     to figure out how to get the spellchecker to continue
     checking from where it left off, not from the beginning
     of the text block.

  3. As cmanske/sfraser brought up in earlier conversations,
     focus issues/bugs need to be considered. With the current
     patch, are there any modal focus issues that may lock the app up?

  4. We are adding rdf files to the mozilla tree with Netscape
     specific URLS. We shouldn't be doing that, and we might get
     some flack from mozilla.org contributors for it. Instead, we should
     be providing dummy/no-op files in the mozilla tree that get overridden
     in the commercial tree. Keep in mind that others may be using
     the spellchecker UI in the mozilla tree with other spellchecker
     implementations, like ISpell, where the dictionaries are totally
     different.

  5. Do we really want to hard code the "Download More.." in the
     dictionary menu list? Or do we want to pull in a Commercial
     overlay?

Are we going to consider/investigate all of these before 0.9.4 ships?



------- Additional Comments From [e-mail] 2001-08-29 13:24 -------

>  2. If you restart the spellchecker backend, we need
>     to figure out how to get the spellchecker to continue
>     checking from where it left off, not from the beginning
>     of the text block.

Is this the desired behavior?  I assume that users most likely will spellcheck
using the newly downloaded data file, so wouldn't it be better to spellcheck
from the beginning?  If I'm going to switch to French spellchecking, do I want
the first part of the document spellchecked in English.  Not usually, I think.



------- Additional Comments From [e-mail] 2001-08-29 14:38 -------

>The patch is a good first step

kin, thanks again for taking time to review this. 

>1. The spellchecker UI gets the list of dictionaries
>   from the spellchecker backend. The spellchecker
>   backend needs to be restarted for it to recognize
>   the new dictionaries.

I could resurrect the alert message informing the user about the restart 
requirement. I would not like to close the spellchecker dialog automatically, 
because of issue with focus stealing and because of 2.


>3. As cmanske/sfraser brought up in earlier conversations,
>   focus issues/bugs need to be considered. With the current
>   patch, are there any modal focus issues that may lock the app up?

The application could potentially lock up, if the download locks up. Best 
approach here would be to close the modal spellchecker dialog box and redirect 
an existing browser window to the download page. However, this is not 
practicable due to the issues with focus stealing.


>4. We are adding rdf files to the mozilla tree with Netscape
>   specific URLS. We shouldn't be doing that, and we might get
>   some flack from mozilla.org contributors for it. Instead, we should
>   be providing dummy/no-op files in the mozilla tree that get overridden
>   in the commercial tree. Keep in mind that others may be using
>   the spellchecker UI in the mozilla tree with other spellchecker
>   implementations, like ISpell, where the dictionaries are totally
>   different.

I will change the Mozilla link to a dummy page, but I believe that this is not 
critical since the spellchecker is (not yet) shipping with Mozilla. Once 
Mozilla offers this feature, they could change the URL to a Mozilla-specific 
site. I would even go as far as claiming that including the commercial link, 
which no one except for the Mozilla coders will see, might be better than a 
dummy link. Mozilla contributors could use an existing (and functional) 
commercial site as a target to emulate in an open source fashion.


>5. Do we really want to hard code the "Download More.." in the
>   dictionary menu list? Or do we want to pull in a Commercial
>   overlay?

I'm objecting to the term hard code, it's living in an DTD file. We would also 
need to split the commercial JS file from Mozilla JS. Furthermore, there is a 
fair chance that Mozilla will offer spellchecker library download and could 
user this item.

Kin, again I appreciate the careful consideration you gave to this functional 
extension and I'd be more than happy to comply with all of them, as long as 
they can be addressed in a reasonable fashion. However, I'm facing hard time 
constraints and regret that these apprehensions were not mentioned earlier. I 
also believe that since Mozilla is currently not offering spellchecker 
functionality, some of the concers are of hypothetical nature and could be 
equally well addressed later, and I'd not hesitate to commit that.



------- Additional Comments From Joaquin Blas 2001-08-29 17:42 -------

> > 2. If you restart the spellchecker backend, we need
> > to figure out how to get the spellchecker to continue
> > checking from where it left off, not from the beginning
> > of the text block.
> 
> Is this the desired behavior?  I assume that users most likely will spellcheck
> using the newly downloaded data file, so wouldn't it be better to spellcheck
> from the beginning?  If I'm going to switch to French spellchecking, do I want
> the first part of the document spellchecked in English.  Not usually, I think.


It may be the desired behavior ... don't forget that the dictionary that was
selected before the user selects "Download More ..." should still be selected
after the download. But the behavior you describe is correct if they select a
different language.


> >5. Do we really want to hard code the "Download More.." in the
> > dictionary menu list? Or do we want to pull in a Commercial
> > overlay?
> 
> I'm objecting to the term hard code, it's living in an DTD file. We would 
also 
> need to split the commercial JS file from Mozilla JS. Furthermore, there is a 
> fair chance that Mozilla will offer spellchecker library download and could 
> user this item.


By hard code, I wasn't referring to the string "Download More .." I was
referring to the fact that the menu used to start out empty and was dynamically
populated with the dictionary names. Now it starts out with the "Download More"
item and the separator, which are more or less netscape features.

I understand the time constraints, and I appologize if it seems like I am
resisting you landing this, that's not the case by the way, I just wanted to
make sure all the issues were known ahead of time. There are people on the net
trying to create a pspell implementation for mozilla, and it may use this same
UI, so it's a little more than a hypothetical situation.

That said, I'm going to sr=[e-mail] and hope that some of the things I
mentioned are considered.



------- Additional Comments From [e-mail] 2001-08-29 18:11 -------

kin, thanks for your prompt reply and for clarifying your position. I'm hard-
pressed to land this as soon as I possibly can due to the importance the i18n 
group is putting on this. I can promise you right now, that I'll investigate 
the points you raised and try to accommodate them in the best way I can.

>There are people on the net
>trying to create a pspell implementation for mozilla, and it may use this same
>UI, so it's a little more than a hypothetical situation.

Agreed, although some more time might pass before they are ready to land and 
this would give us a chance to work with them and possibly "commercialize" some 
of the spellchecker features as such the library download. I'd commit to 
helping with putting in commercial overlays or other necessary changes to 
facilitate their efforts.

Comment 1

[[e-mail] (away - not reading bugmail)]

Attachment: most recent patch with r=tao, cmanske, sr=kin

Comment 2

[[e-mail] (away - not reading bugmail)]

targetting for 0.9.4, marking "intl" and "nsBranch+" per original Bugscape 
status

Comment 3

[Sheela Ravindran]

Please reassign the qa contact to the appropriate one in international.Thanks. 

Comment 4

[[e-mail] (away - not reading bugmail)]

changing QA contact to [e-mail], since she is the QA point person 
for the Bugscape pendant of this bug.

Comment 5

[Frank Tang]

please check this into m0.9.4 ASAP. 

Comment 6

[[e-mail] (away - not reading bugmail)]

here is a comment from Asa Dotzler from a private email correspondence:

"97541 can wait till after we've done 0.9.4 and handed the branch off to 
Netscape"

Short of a miracle, I believe we'll have to wait for the branch...

Comment 7

[Jaime Rodriguez, Jr.]

Nominating for PDT+. this was a request from nsenterpise top customer (see msanz
for details). Adding nsenterprise keyword.

Comment 8

[Jaime Rodriguez, Jr.]

nsenterpreise+ per grega.

Pls check it as soon as possible, after 0.9.4 is released.

Comment 9

[[e-mail] (away - not reading bugmail)]

thanks Jaime! I'm very keen on having this in the tree as soon as we have 
access to the branch.

Comment 10

[grega]

I evaluating if we should take this on the branch.  
Have 1-5 been addressed?  
What is the risk if we take this?  
Pinged Brent Harrison for update from AOL
Has this been tested and verified on the trunk?  If you are a key contributor
please come to noon PDT in B21Pit on Monday to discuss.  Thanks, Greg

Comment 11

[Asa Dotzler [:asa]]

0.9.4 is out the door

Comment 12

[Jeff Hooker]

This has been on the P1 radar for months. MFA was a TW committed feature for the
Mojo release. This is a stop deploy issue for eMojo.

Comment 13

[[e-mail] (away - not reading bugmail)]

the open-source part has been checked in into the branch. Still need to checkin 
commercial builtinURLs.rdf. I'm working on that with ftang, since I currently 
don't have access to the commercial tree.

Comment 14

[grega]

eta for landing the commercial tree changes?  We are getting down to the wire,
first candidate builds scheduled for 10/2.

Comment 15

[[e-mail] (away - not reading bugmail)]

grega:

the feature was landed on the branch on Friday, Sept. 21. I'm keeping this bug 
open since the trunk checkin is still due (the milestone is set to 0.9.5), I'll 
land it there by Wednesday, Sept. 26.

Comment 16

[[e-mail] (away - not reading bugmail)]

trunk changes just went into the tree - resolving. 

Comment 17

[esther]

This bug belongs to International, I'll send it to ji 

Comment 18

[ji]

There is another bugscape version of this bug (bug 8746). Verified with 09/26
branch builds. Added vtrunk keyword.

Comment 19

[ji]

Marked it as verified. It's in the product now.