If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED WONTFIX

Status

addons.mozilla.org Graveyard
Dictionaries
--
enhancement
RESOLVED WONTFIX
6 years ago
2 years ago

People

(Reporter: Mic, Assigned: jorgev)

Tracking

(Blocks: 1 bug)

Details

(Reporter)

Description

6 years ago
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 toolkit@mozilla.org as targetApplication, that'd help supporting all gecko based applications
(Reporter)

Updated

6 years ago
Blocks: 596002
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 toolkit@mozilla.org for the targetApplication and see why AMO won't support that for dictionaries.
(Reporter)

Updated

6 years ago
Summary: Weaken application compatibility checks on (spellchecking) dictionaries → Make it easier to use (spellchecking) dictionaries with other programs using the toolkit

Comment 2

6 years ago
Reporter, have you followed the advice from comment1?
If yes, can this be closed?
Thanks
(Reporter)

Comment 3

6 years ago
(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 toolkit@mozilla.org] 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?
When in doubt, make someone else deal with it. Addons Manager -> AMO
Component: Add-ons Manager → Dictionaries
Product: Toolkit → addons.mozilla.org
QA Contact: add-ons.manager → dictionaries

Comment 5

6 years ago
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 toolkit@mozilla.org in install.rdf.
Assignee: nobody → jorge
(Reporter)

Comment 6

6 years ago
(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 toolkit@mozilla.org 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

6 years ago
(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 toolkit@mozilla.org or if it is even worth the effort.
(Assignee)

Comment 8

6 years ago
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 toolkit@mozilla.org 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?
(Reporter)

Comment 9

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

For me it doesn't have to be the toolkit@mozilla.org 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

6 years ago
Reporter, do you have anything new about this issue?
Thanks
(Reporter)

Comment 11

5 years ago
(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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 12

3 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
(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, toolkit@mozilla.org 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).
(Assignee)

Comment 14

3 years ago
(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, toolkit@mozilla.org 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.
(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, toolkit@mozilla.org 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.
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.