ubuntu-accomplishments-contributors team mailing list archive

[Janos Gyerik <janos.gyerik@xxxxxxxxx>]

> If the static fields that can't be edited need changing, they can
> always be changed in the branch with a text editor.

Btw the admins can make changes to the static fields using django
admin, no need to edit text files for that.

If you want to let users propose changes to the static fields, then we
should make that part of the web editor right from the start. I mean
these fields: descriptor, needsinformation, categories, icon,
needssigning, depends

If we don't need proposals for these then the model in the previous
post should be fine. If any of these should be subject for proposals,
then we might just as well include all of them.

Btw, after the web editor is deployed, it will be best if all the
changes to accomplishments go through the web editor, and not merged
in bzr outside of it. If there are changes outside they need to be
synchronized to django, which will be difficult (but of course
possible). It would be good if we can avoid or at least minimize that.

> One small suggestion - you may want AccomplismentProposal.lang to be a
> foreign key to another table that lists all the available languages
> for a given accomplishment set (this could be scanned (scanning which
> lang subdirs are available)).

Don't you want to allow completely new translations? Either way,
another table with all the accepted languages will be good. But should
it be limited to existing accomplishment languages? How about we
import all iso639-2 language codes like en, ja, hu, ... ? Btw do we
really need en_gb?

Cheers,
Janos
-- 
Janos Gyerik
http://www.janosgyerik.com/