674878 - Make it easier to use (spellchecking) dictionaries with other programs using the toolkit

Status: RESOLVED WONTFIX

(addons.mozilla.org Graveyard :: Dictionaries, enhancement)

Description

[Benedikt Pfeifer]

Applications like Instantbird have the problem that they can't use dictionaries from AMO directly (not really one of your problems, I admit;). Duplicating the dictionaries on our own add-ons website just feels wrong though:

If there's a reason why it is absolutely needed to have a strict compatibility checking (application-/versionwise) for dictionaries, then it's fine. If there's none then it would be great if it would be easier to use them with other programs (e.g. weakening the check to something like: "dictionary is compatible with built-in spellchecker" if such a thing is possible).


--
There were more comments/objections/ideas mentioned on IRC:

13:05:49 * Archaeopteryx has objections: hunspell dictionaries have been supported since fx 3.0, so if a user on 2.0 would have tried to install one of them, this would be bad
13:06:30 - Archaeopteryx: there were also crashes after the french dictionaries had been updated to a newer hunspell version, they had to roll back
13:06:33 - Unfocused: well, we'd still check platform version, of course
13:09:41 - Unfocused: and we could potentially add hunspell version checking 
13:09:46 - Archaeopteryx: if AMO would support [e-mail] as targetApplication, that'd help supporting all gecko based applications

Comment 1

[Dave Townsend [:mossop]]

It sounds like there are still version requirements necessary here, even if they are only requirements on the platform version. I think the best thing to do is to push to move to using [e-mail] for the targetApplication and see why AMO won't support that for dictionaries.

Comment 2

[Vlad [QA]]

Reporter, have you followed the advice from comment1?
If yes, can this be closed?
Thanks

Comment 3

[Benedikt Pfeifer]

(In reply to Vlad from comment #2)
> Reporter, have you followed the advice from comment1?
> If yes, can this be closed?
> Thanks

I've never created or uploaded a dictionary, so I haven't experienced the "why AMO won't support that [=using [e-mail]] for dictionaries"-problem myself. I think it would be good to get someone involved who knows what he's talking about.
I asked on #bmo how to proceed i.e. if I should change the product/component or CC someone to get someone from AMO involved. (To no avail so far).

Do you have any suggestions?

Comment 4

[Blair McBride [:Unfocused] (UNAVAILABLE)]

When in doubt, make someone else deal with it. Addons Manager -> AMO

Comment 5

[Jesper Kristensen]

Not all Mozilla applications support spell checking (Firefox for mobile) and it would be strange to say that a spell checking dictionary is compatible with an application which does not support spell checking. However the Add-ons manager will soon know if an extension is a spell checking dictionary or not (bug 591780) and if we also tell it if the current application supports spell checking, we could build this extra check into the Add-ons manager, and only have [e-mail] in install.rdf.

Comment 6

[Benedikt Pfeifer]

(In reply to Jesper Kristensen from comment #5)
> Not all Mozilla applications support spell checking (Firefox for mobile) and
> it would be strange to say that a spell checking dictionary is compatible
> with an application which does not support spell checking. However the
> Add-ons manager will soon know if an extension is a spell checking
> dictionary or not (bug 591780) and if we also tell it if the current
> application supports spell checking, we could build this extra check into
> the Add-ons manager, and only have [e-mail] in install.rdf.

If this is the way to go, shall I file an extra bug for the add-on manager part of it?

Comment 7

[Jesper Kristensen]

(In reply to Benedikt P. [:Mic] from comment #6)
> If this is the way to go, shall I file an extra bug for the add-on manager
> part of it?

This was just my suggestion. I don't know if the people in charge thinks this is needed before we can use [e-mail] or if it is even worth the effort.

Comment 8

[Jorge Villalobos [:jorgev] (he/him)]

I think that dictionaries should handle version and application compatibility in their install.rdf file, with the possibility to override it with AMO metadata, just like other add-on types. Switching to the [e-mail] format seems wrong to me given the very limited amount of applications that support them.

I can see how this is a problem for Instanbird; you can't expect many developers to support it by default. Have you considered posing as Firefox just for AMO? I know Flock did a similar thing in order to support Firefox add-ons. Granted, it's not the same for Instantbird, which is a very different application, but you could check client-side if the downloaded XPI is compatible with Instantbird OR is a dictionary.

Would that work?

Comment 9

[Benedikt Pfeifer]

(In reply to Jorge Villalobos [:jorgev] from comment #8)
> with AMO metadata, just like other add-on types. Switching to the
> [e-mail] format seems wrong to me given the very limited amount
> of applications that support them.

For me it doesn't have to be the [e-mail] solution.

In my opinion the important thing is whether an application supports spell-checking or not in this case and I can't think of a reason why a natural language dictionary should be suitable for one application but not another then.

Can we think of a compatible-when-spell-checking-is-supported solution maybe?

Comment 10

[Vlad [QA]]

Reporter, do you have anything new about this issue?
Thanks

Comment 11

[Benedikt Pfeifer]

(In reply to Vlad [QA] from comment #10)
> Reporter, do you have anything new about this issue?
> Thanks

I'm waiting if someone has something to say about this idea here: ;)

(In reply to Benedikt P. [:Mic] from comment #9)
> Can we think of a compatible-when-spell-checking-is-supported solution maybe?

The application would either need to know whether it supports dictionaries and do the toolkit version check if yes, or the check would need to be altered with an #ifdef while building.

Comment 12

[Jorge Villalobos [:jorgev] (he/him)]

I don't think we should just provide dictionaries to any toolkit application, since this is probably wrong for a number of them. Dictionary add-ons can already declare compatibility to the applications we support, and I can see it working with Thunderbird.

In the case of unsupported applications, I think the best approach is to modify the Add-ons Manager to serve their purpose. In this case I think a Firefox dictionary search and overriding application compatibility is the most effective approach.

Comment 13

[Florian Quèze [:florian]]

(In reply to Jorge Villalobos [:jorgev] from comment #12)
> I don't think we should just provide dictionaries to any toolkit
> application, since this is probably wrong for a number of them.

Do you have any example where this would be wrong?
(and by "wrong" I don't mean "the application would do nothing with the dictionary" but really "this would break something")

> Dictionary
> add-ons can already declare compatibility to the applications we support,

But as mentioned several times in this bug, [e-mail] is not supported on AMO.

> and I can see it working with Thunderbird.

Which is a large enough application to be known by most if not all dictionary developers.
 
> In the case of unsupported applications, I think the best approach is to
> modify the Add-ons Manager to serve their purpose. In this case I think a
> Firefox dictionary search and overriding application compatibility is the
> most effective approach.

Assuming you mean modifying the add-on manager only for the "unsupported applications", this seems complicated, error prone, and to have a high maintenance cost (as the tweaks to the add-on manager would need to be updated to stay compatible with changes made to the add-on manager code).

Comment 14

[Jorge Villalobos [:jorgev] (he/him)]

(In reply to Florian Quèze [:florian] [:flo] from comment #13)
> (In reply to Jorge Villalobos [:jorgev] from comment #12)
> > I don't think we should just provide dictionaries to any toolkit
> > application, since this is probably wrong for a number of them.
> 
> Do you have any example where this would be wrong?
> (and by "wrong" I don't mean "the application would do nothing with the
> dictionary" but really "this would break something")

No. I haven't looked at the XUL application world for a very long time, and there's plenty of dark matter out there.

> > Dictionary
> > add-ons can already declare compatibility to the applications we support,
> 
> But as mentioned several times in this bug, [e-mail] is not
> supported on AMO.

Even if it were, it's not useful unless developers actually make use of it. I think adding support to it will cause more confusion than benefit.

> > and I can see it working with Thunderbird.
> 
> Which is a large enough application to be known by most if not all
> dictionary developers.

The majority, but not all. I noticed some dictionaries with Firefox-only compatibility set.

> > In the case of unsupported applications, I think the best approach is to
> > modify the Add-ons Manager to serve their purpose. In this case I think a
> > Firefox dictionary search and overriding application compatibility is the
> > most effective approach.
> 
> Assuming you mean modifying the add-on manager only for the "unsupported
> applications", this seems complicated, error prone, and to have a high
> maintenance cost (as the tweaks to the add-on manager would need to be
> updated to stay compatible with changes made to the add-on manager code).

Yes, I'm not saying it would be easy, but I still believe it's the most effective approach since it doesn't require making changes on AMO (which has been in maintenance mode for years) and convincing dozens of developers to change their compatibility metadata.

Comment 15

[Patrick Cloke [:clokep]]

(In reply to Jorge Villalobos [:jorgev] from comment #14)
> (In reply to Florian Quèze [:florian] [:flo] from comment #13)
> > (In reply to Jorge Villalobos [:jorgev] from comment #12)
> > > I don't think we should just provide dictionaries to any toolkit
> > > application, since this is probably wrong for a number of them.
> > 
> > Do you have any example where this would be wrong?
> > (and by "wrong" I don't mean "the application would do nothing with the
> > dictionary" but really "this would break something")
> 
> No. I haven't looked at the XUL application world for a very long time, and
> there's plenty of dark matter out there.

There's a great power in being able to re-use code written for other XUL applications. I'd suggest you reconsider this point.

> > > Dictionary
> > > add-ons can already declare compatibility to the applications we support,
> > 
> > But as mentioned several times in this bug, [e-mail] is not
> > supported on AMO.
> 
> Even if it were, it's not useful unless developers actually make use of it.
> I think adding support to it will cause more confusion than benefit.

I don't see how this would cause any confusion. It would probably confuse many *users* less (e.g. they don't care why they have a dictionary that works in Firefox but not in Thunderbird, they just want it to work).

I do not find an argument along the lines of assuming what developers will do to be compelling.

> > > In the case of unsupported applications, I think the best approach is to
> > > modify the Add-ons Manager to serve their purpose. In this case I think a
> > > Firefox dictionary search and overriding application compatibility is the
> > > most effective approach.
> > 
> > Assuming you mean modifying the add-on manager only for the "unsupported
> > applications", this seems complicated, error prone, and to have a high
> > maintenance cost (as the tweaks to the add-on manager would need to be
> > updated to stay compatible with changes made to the add-on manager code).
> 
> Yes, I'm not saying it would be easy, but I still believe it's the most
> effective approach since it doesn't require making changes on AMO (which has
> been in maintenance mode for years) and convincing dozens of developers to
> change their compatibility metadata.

Would this really be a major change? I don't find the "Convincing dozen of developers..." argument to be compelling, as I said above, in fact...they might jump at the opportunity to get more people to use their dictionaries. Many developers take pride in providing a needed resource to the community and might not see this as a burden at all. Regardless, I don't want to try to guess what people will do.

If you had suggested modifying the Add-ons Manager code in toolkit to allow dictionaries to be installed without checking compatibility (comment 5 seems to imply this is possible) I'd agree this is a feasible plan forward.