Now that dictionaries can be packaged properly in extensions (http://developer.mozilla.org/en/docs/Bundles#Application-specific_Extension_Files) we should repackage the dictionaries which are currently available from http://www.mozilla.com/thunderbird/dictionaries.html as extensions and they should have their own toplevel category or extension category on AMO. (and we'll need to hook up the Firefox UI to link with the website).

Could we have a URL on which these dictionaries will end up so that we can improve on the UI part of this? I guess some https://addons.mozilla.org/dictionaries could cut it.

That URI works fine -- we can assume that, and fill in the server component later once the xpi's are packaged. It'd be better to add a trailing slash, so let's agree on this unless shaver (cc'd) objects: https://addons.mozilla.org/dictionaries/

amo/dictionaries is fine. We should figure out where localization parameters go in that URL, too (pathinfo please). I don't know if they're getting a top-level section or not, but it's not a problem we need to solve right now.

Is there an example for the necessary install.rdf?

http://benjamin.smedbergs.us/tests/fr-dictionary.xpi is the extension I was using for testing the original patch.

I copied the thunderbird dictionaries page into the AMO template here: https://update-staging.mozilla.org/~clouser/amo/v2/public/htdocs/dictionaries/ I also had to add a custom rule to the .htaccess because /dictionaries/ is inconsistent with our /<app>/<page>/ rules. Is this what we're looking for? I assume we're going to need to add some more text to the page (and repackage/host the dictionaries?).

I actually figured it would just be another category in the "Extensions" section, but this looks better. Should we still upload/maintain the extensions using the regular administration interface?

Ah, I think a "dictionary" category in extensions would be more appropriate (I was modeling this after the search engines page). The less special cases the better, I think, and just using another category would allow us to use the current admin tools to upload/approve/etc.

Please add an install.js file into those new dictionary XPI packages that install the dictionary into <appdir>/dictionaries on xpfe-based SeaMonkey versions.

Please file a separate bug on that, preferably with a patch to the build mechanisms, if you want that seriously considered during the remaining time before Fx2.

Shaver, there are no existing build mechanisms... as far as I know the current dictionaries were packaged manually. I was/am planning on writing a little tool that will easily package up a .dic and .aff into an extension.

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

This is required for Firefox 2 dictionary installation. It is currently broken because the add-ins install into "myspell" but we now use "dictionaries"

Wil, can you (ASAP) provide an entrance URL for the "Get New Dictionaries" UI in Firefox/Tbird? (see bug 335605).

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

I think the localized URL scheme will be addons.mozilla.org/{locale}/path but don't quote me on it.

The URL will be http://addons.mozilla.org/$locale/$appname/$appversion/dictionaries/ from which we will likely redirect to another part of the site. $locale should refer to the locale in which we want content (_("These are extra dictionaries you can add to enhance Firefox's spell-checking capabilities"), etc.) to be presented.

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

(In reply to comment #14) > Wil, can you (ASAP) provide an entrance URL for the "Get New Dictionaries" UI > in Firefox/Tbird? (see bug 335605). > Shaver's URL (comment 17) is correct.

I've written a repackaging tool for dictionaries that can be found at http://benjamin.smedbergs.us/blog/2006-07-26/dictionaries-in-firefoxthunderbird-2/ Should we ask each l10n team to use this tool and submit a dictionary extension themself

Wil, when would we be able to get this live?

FWIW, I've added the "Dictionaries" category to Ffox/Tbird/SM, so all that's left in the short term is to have a redirect from the canonical entrance URL to https://addons.mozilla.org/search.php?cat=68&app=firefox&type=E

We need a way to make it clear to add-on developers that the dictioanries category is only for dictionaries, not add-ons related to dictionaries. We already have one in there - https://addons.mozilla.org/firefox/3005/ Would it be useful for me to grab the dictionaries from http://www.mozilla.com/thunderbird/dictionaries.html, pull them apart, package them properly and throw them at amo? Or do you want them owned by the localisation teams? What about dictionaries for which we don't yet have localisation teams? (eg. en-AU)

I'm not sure whether the new dictionaries section should be for "mozilla dictionraies" only... I've been wavering back and forth. I think that we want the l10n teams to be responsible for uploading the dictionaries at the present time. If an Australian wants to take charge of owning the en-AU dictionary that would be great. The less centralized work we're doing the better.

I thought dictionaries would be a separate "type", like extension-vs-theme(-vs-search-plugin-vs-plugin in the future?), rather than just a category. When did we decide to use a category for this? I confess that I don't fully understand the review or display expectations are from the browser side -- how are in-tree dictionaries reviewed and vetted? Would we be OK with an "urban slang" dictionary pack appearing on the page at the end of "Add dictionaries..."? What if someone wants to submit an alternate dictionary for a given locale that we support? (Maybe these issues have been explored somewhere; I haven't looked extremely hard for such a discussion, so please do let me know if there's one I can learn from.)

> just a category. When did we decide to use a category for this? In Firefox's mind, dictionaries are just extensions. So for expediency, I agreed with wclouser and morgamic that using a category was a good short-term solution. We agreed to explore alternate ways to present that category as a secondary step, as well as ways to feature dictionaries near the front page, especially for ffox/tbird users who don't get a dictionary installed by default due to licensing reasons. The use of a standard ID scheme for dictionaries (provided by my repackager tool) should help make customized UI presentation easier. > I confess that I don't fully understand the review or display expectations are > from the browser side -- how are in-tree dictionaries reviewed and vetted? There has not been a significant UI review of the process... I asked beltzner to provide some thoughts once the UI was hooked up properly. In-tree dictionaries are submitted by the l10n teams and are minimally vetted for licensing by Gerv and/or Pike. The dictionaries on AMO may or may not be the in-tree dictionaries (and the most important ones are the ones which cannot be in-tree dictionaries, for licensing reasons). What if someone wants to submit an alternate > dictionary for a given locale that we support? I'd say that the l10n team owners should have control over which dictionaries appear. I don't know/whether we'd enforce that unless this issue arose in practice.

(In reply to comment #21) > Wil, when would we be able to get this live? > The redirect is in CVS and needs to be manually applied to the .htaccess. At this point I'll add it to the list for our next update (anytime within the next couple weeks), or I can request another AMO update right away if you need it.

Can we do this during the AMO maintenance window on Sat?

I don't see why not. Also, we'll need to put in the rewrite for blocklisting as well (bug 290759).

https://addons.mozilla.org/en-us%2C%20en/firefox/3.0a1/dictionaries/ 404 Not Found

That URI contains "en-us, en" -- so that raises some questions: a) is that actually a locale name? b) where was that mentioned in the previous discussion c) when would this be used in a link coming from a client? Just seems kind of strange that all of a sudden we're doing "en-us, en".

That's what shaver and I discussed, that the format of $locale would be the comma-delimited list of preferred locales, which matches what is passed in the accept-lang HTTP header.

(In reply to comment #32) Why should it be? Why send the same information two times (in URL and accept-lang)?

Because, for testing and navigation purposes, shaver wants to be able to hand out URLs that have l10n information encoded in them.

Okay -- so the current regexp just doesn't accomodate for that format (, or \s). In the previous comments $locale was mentioned, not $listoflocalessortedbypreference -- so it kind of led Wil to believe it was a singular locale in the "blah-blah" format that you see on some l10n sites following the domain. (domain.com/$locale/.*). We could totally change it, if we're sure that is what we want -- it's an easy fix.

I believe that's what we want... we should honor the user's language preferences.

(In reply to comment #36) > I believe that's what we want... we should honor the user's language > preferences. > Agreed, but I never heard of giving them a comma delimited list in the URL. Shaver?

Hmm guys, I think you're on the wrong track here. In this case, you shouldn't use HTTP_ACCEPT_LANGUAGE to select what language the user might want to see, but the language that can be found in HTTP_USER_AGENT (the language of the software). For example, my current HTTP_ACCEPT_LANGUAGE is : nl-be nl;q=0.8 en;q=0.6 es;q=0.4 fr;q=0.2 So I get a rather weird URL : https://addons.mozilla.org/nl-be%2Cnl%2Cen%2Ces%2Cfr/firefox/2.0b1/dictionaries/ But my HTTP_USER_AGENT is Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b1) Gecko/20060806 BonEcho/2.0b1 You might to try to send the 'main' language here (nl-be), but that's no guarantee that the page exists (nl does, and so does the rest). So do we want to test them one by one, until we found the first non-404 ? But there's no reason to do something so complicated. We should take the language of the software (used for menu, dialog boxes, etc ...). The user is already using it, and should be able to understand the page. Even when he/she messed around with the configuration, and potentially removed the original setting (I could have removed 'en' from my list). And the page should definitely exist, at least for a n official build of Mozilla

Jo, thanks for the sample for accept_lang. Note, even for official builds, we don't want to force every localization team to provide an official localization of each of our websites. fy-NL is one example, the 11 south african locales are another example. Or catalan, where we even have folks that may prefer french as secondary language. Using accept_lang has the benefit of giving the user the choice. Webtools folks prefer to have that string in the URL as that makes it easier to do the rewrite rules. At least, so they said before being flooded with all the possible options ;-).

(In reply to comment #32) > That's what shaver and I discussed, that the format of $locale would be the > comma-delimited list of preferred locales, which matches what is passed in the > accept-lang HTTP header. I don't recall ever discussing multiple locales here. Where did we have that discussion?

On IRC, and I don't have a log. But you stated your server-side requirement for URLs that expressed the locale (for testing/management purposes), and I expressed the need to honor by default the user setting for preferred language. I can't remember the exact quote, but it was something like "then put that information in the URL".

(In reply to comment #38) > > ... but that's no > guarantee that the page exists (nl does, and so does the rest). So do we want > to test them one by one, until we found the first non-404 ? No, we want to handle this entirely on the server. For each locale, on the server, we can specify a fallback path for pages that don't exist. So indeed, we could teach the server that nl-be pages should fall back to nl, and if that's missing too, fall back to en-US. > But there's no reason to do something so complicated. We should take the > language of the software (used for menu, dialog boxes, etc ...). The user is > already using it, and should be able to understand the page. Even when he/she > messed around with the configuration, and potentially removed the original > setting (I could have removed 'en' from my list). Precisely. The whole l10n group went around and around on this issue today, and this was the consensus: - The URL should have one locale, not a list - The specified locale will be the locale currently in use for chrome, etc So even if the user, or an extension, modifies the user agent locale to a nonsense value, we will use whichever locale the chrome fell back to.

> Precisely. The whole l10n group went around and around on this issue today, > and this was the consensus: I'm sorry to have missed this meeting. > - The specified locale will be the locale currently in use for chrome, etc This is the crux of the issue, and what I disagree with. Why do we even bother giving the user preferences to change the language they prefer their website content to be in, if we're not going to use those preferences on our own websites? Shaver convinced me that, for ease of testing and maintenance we should not rely solely on the HTTP Accept-Lang header, but pass the values in the URI. But that doesn't mean we should be blindly setting website content to match the language of the browser.

(In reply to comment #43) > > - The specified locale will be the locale currently in use for chrome, etc > > This is the crux of the issue, and what I disagree with. Why do we even bother > giving the user preferences to change the language they prefer their website > content to be in, if we're not going to use those preferences on our own > websites? Because the pages we're linking to are selected by the application, not the user, and act effectively as extensions to the product.

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

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

(In reply to comment #26) > > just a category. When did we decide to use a category for this? > > In Firefox's mind, dictionaries are just extensions. So for expediency, I > agreed with wclouser and morgamic that using a category was a good short-term > solution. People are adding non-dictionary add-ons to the "dictionaries" category, in some cases extensions that are related to dictionaries and such tools on the web. Is that OK? Is that not OK? Maybe what I'm asking is: what are the general requirements for the non-short-term solution, and who's doing that work? > What if someone wants to submit an alternate > > dictionary for a given locale that we support? > > I'd say that the l10n team owners should have control over which dictionaries > appear. I don't know/whether we'd enforce that unless this issue arose in > practice. The l10n owners need to be identified to the AMO system then (and we just had someone else ask to upload a de-DE dictionary, so I think it's upon us). Also, the addition of the 2.0.0.* version number is causing us some non-trivial pain with non-dictionary add-ons, so I think it's going away pretty shortly. We'll need to find another way to accommodate those, should we in fact actually be _certain_ that dictionaries working today will 100% work with the final 2.0.0.* stream.

I was asking to upload a de-DE dictionary. And I'm german mail owner - not "some one else" ;-)

(In reply to comment #48) > I was asking to upload a de-DE dictionary. And I'm german mail owner - not > "some one else" ;-) Alex, I thought I alread have uploaded a de-DE one, which is already listed in that section?

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

Clearing blocking Firefox2 status. With the existing server-side redirect for beta 2, and with planned changes to the first run and updated pages on mozilla.com, I think we're in OK shape for Firefox 2 even if this doesn't get resolved before then.

Is this resolved? The dictionaries page has been live on AMO since Fx2 launch (https://addons.mozilla.org/firefox/dictionaries) and dictionaries will have their own add-on type in Remora.

Aye.