Implement "language packs" on the "languages and dictionaries" page

VERIFIED FIXED in 3.2

Status

VERIFIED FIXED
11 years ago
3 years ago

People

(Reporter: stephend, Assigned: wenzel)

Tracking

Dependency tree / graph

Details

(URL)

Attachments

(3 attachments, 1 obsolete attachment)

(Assignee)

Comment 1

11 years ago
All right, in today's meeting we decided to run some DB magic in order to mark the "extensions" that are actually language packs with the right add-on type.

However, they don't seem to have a uniform way of describing what locale they are focusing on (unlike dictionaries, most of which have a parsable GUID), so we'll be unable to put them into the list in the right order.

I have a feeling in order to do this right we need a new database table for "this dictionary or language pack covers locale x". Though this obviously needs additional GUI for the dev panel etc then :-/

Clouserw, can you comment?
(Assignee)

Comment 2

11 years ago
A search for "language pack" is returning 38 possible candidates.

https://preview.addons.mozilla.org/en-US/firefox/search?q=language+pack&cat=all

Comment 3

11 years ago
ping.

Given our discussion on today's call - we should try to get some resolution to this page and its design. If you need some manual figuring out of the locale for these 38 language packs, I'll be OK with doing that.
We're putting "Language Pack" as a separate type when someone first uploads an add-on, right?  So, could we just put a textbox that asks for what locale there?  (Or better, put it in the .rdf)

Filling in the locales manually in the db would work for the short term
Assignee: nobody → fwenzel
Target Milestone: --- → 3.2
(Assignee)

Comment 5

11 years ago
Okay, I'll add a new field to the DB that holds the "target locale" for dictionaries and language packs (and is NULL otherwise). Devs will be able to enter a language code in there.

Displaying the dictionaries/lang pack page is then very easy, because there's no guessing anymore what locale they belong to.

Protection against screwed up language codes and such comes from the sandbox: Only dictionaries/lang packs that have a correct locale code assigned may be pushed public.
(Assignee)

Comment 6

11 years ago
clouserw says:
- for dictionaries we need to store 3 new things:  locale, additional info, primary flag
- the first two are up to the developer, the flag is decided by admins
(Assignee)

Updated

11 years ago
Blocks: 421129
(Assignee)

Comment 7

11 years ago
Created attachment 308893 [details] [diff] [review]
Allow adding target locale to dicts and lang packs

This patch allows adding target locale and locale disambiguation info to dictionaries and application language packs.

Does that look right, clouserw?

Note that this needs some l10n, I am not quite sure what to do about that: If we want to deploy this change by 3.2, we need to give the fields names in the dev cp, in spite of l10n being frozen. Suggestions?
Attachment #308893 - Flags: review?(clouserw)
(Assignee)

Comment 8

11 years ago
Created attachment 308894 [details]
Incremental SQL

This is the SQL to be run on a current database, in order to add the two fields. It also fills in the target locale for all current dictionaries.
(Assignee)

Updated

11 years ago
Attachment #308893 - Attachment is patch: true
Attachment #308893 - Attachment mime type: application/octet-stream → text/plain
(Assignee)

Comment 9

11 years ago
Created attachment 308910 [details] [diff] [review]
Updated patch, including l10n

Updated patch: It now contains l10n, en-US only.

Will work on the frontend (dictionaries page) part once this is reviewed.
Attachment #308893 - Attachment is obsolete: true
Attachment #308910 - Flags: review?(clouserw)
Attachment #308893 - Flags: review?(clouserw)
Comment on attachment 308910 [details] [diff] [review]
Updated patch, including l10n

Looking good to me.  It would be nice if we could say something about what the target locale means, just to make sure we're all using iso 639-1 names with optional country codes afterwards.  Not sure how to make that sound simple though.  In the mean time, r+
Attachment #308910 - Flags: review?(clouserw) → review+
(Assignee)

Comment 11

11 years ago
Code changes (so far) are in r11250, l10n changes in r11251. The incremental SQL to be run is on the wiki, too.
(Assignee)

Comment 12

11 years ago
Created attachment 309097 [details]
Screenshot:  Multiple dictionaries per target locale

I implemented the front-end side now. The attachment shows what it looks like when you add two dictionaries to the same target locale now.

Note that language packs still don't show up because most of them (all?) have the wrong addon type and none have a target locale assigned atm. I filed bug 422636 to have this fixed.
(Assignee)

Comment 13

11 years ago
This is in r11265, and fixed. Please reopen if you notice anything I may have overlooked.
Blocks: 422636
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Verified; I installed them all (13) using Firefox 2.0.0.12:

https://preview.addons.mozilla.org/en-US/firefox/browse/type:3#dictionaries
Status: RESOLVED → VERIFIED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.