ubuntu-accomplishments-contributors team mailing list archive

[Jono Bacon <jono@xxxxxxxxxx>]

On 1 April 2012 22:32, Janos Gyerik <janos.gyerik@xxxxxxxxx> wrote:
>> 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

My hunch is that only admins can change these things for now. You may
want to include them anyway so we can provide this functionality in
the future if desired.

> 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.

My feeling here is that the web editor should be the recommended way
to edit accomplishments (e.g. for ubuntu-community-accomplishments) we
should recommend all changes via the web editor. I do think we should
still be able to make manual edits if needed and then be able to hit a
button in the web editor that will just rescan the branch to update
the DB with any branch changes. Make sense?

>> 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?

Good point about making completely new translations; I agree we will
want to be able to do this.

I think importing all the recognized language codes would make sense
and maybe put them in a SupportedLanguages table.

  Jono

-- 
Jono Bacon
Ubuntu Community Manager
www.ubuntu.com / www.jonobacon.org
www.identi.ca/jonobacon www.twitter.com/jonobacon