Add language pack model in zamboni

RESOLVED FIXED in 2015-01-27

Status

Marketplace
Developer Pages
P2
normal
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: Andy McKay, Assigned: mat)

Tracking

Avenir
2015-01-27
x86
Mac OS X
Points:
---

Details

(Whiteboard: [qa-])

(Reporter)

Description

4 years ago
Create a model in zamboni that contains database tables and constants etc. First job is to figure out what those fields are maybe:

- firefox os version
- language
- created
- updated
- active

We'll also need a version table that is maybe:

- lang pack version number
- path on the file system
- updated
- created
- active

It was suggested that this should be a separate set of models from Webapp, Version and File.
(Assignee)

Comment 1

4 years ago
Are we really going to need the version table ? It seems overkill...
could a collection for each FxOS version and a consistent naming scheme achieve this without a new model?
(In reply to Andrew Williamson [:eviljeff] from comment #2)
> could a collection for each FxOS version and a consistent naming scheme
> achieve this without a new model?

If you're suggesting to wedge language packs into the Webapp model (because collections are collections of apps, right?), I was hoping we could avoid that. Language packs seem different in subtle ways that I fear we'd be fighting an uphill battle adding exceptions all over our code. There's also a future possibility of associating language packs to apps where a separate model would be the right way to model that relationship.
(In reply to Rob Hudson [:robhudson] from comment #3)
> (In reply to Andrew Williamson [:eviljeff] from comment #2)
> > could a collection for each FxOS version and a consistent naming scheme
> > achieve this without a new model?
> 
> If you're suggesting to wedge language packs into the Webapp model (because
> collections are collections of apps, right?), I was hoping we could avoid
> that. Language packs seem different in subtle ways that I fear we'd be
> fighting an uphill battle adding exceptions all over our code. There's also
> a future possibility of associating language packs to apps where a separate
> model would be the right way to model that relationship.

I meant more as an alternative to a osversion table, following on from #c1. So each lang+osversion would be a 'langpack' object, i.e. langpack->version->file like we have with webapps; rather than langpack->osversion->version->file. And if we could use collections to collect all langpacks for a particular osversion if that was needed.

As for langpacks being wedged into Webapp vs a new model, I don't really have a strong on opinion on that. Either way I can see changes being needed in various places.
(Assignee)

Updated

4 years ago
Assignee: nobody → mpillard
(Assignee)

Updated

4 years ago
Priority: P3 → P2
(Assignee)

Updated

4 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 5

4 years ago
Fixed in https://github.com/mozilla/zamboni/commit/6c71afc5be6f43b0b53e6893f3b45b1a26b91528
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Whiteboard: [qa-]
Target Milestone: --- → 2015-01-27
You need to log in before you can comment on or make changes to this bug.