Technical architecture

When a person translates a text in a particular language, she is then a translator of this language.

To each translation, translator, text and language are associated a numeric value called "karma".

Any person can moderate up or down a translation's karma, and indirectly the karma of all associated elements: translator, text, language.

A translator can override an existing translation if his karma is larger than the translation's.

A person authentificates herself in the system when logging, this authentification is used to determine what is readable and/or writable.

Passwords are (still) kept in the clear in the database.

Anonymous emails are never read from the database.

There are different kind of choices available, the most widely used concern every non-container element and allow to set a level.
This level could be designed in three major ways:

The first method doesn't account for disagreeing people, which mean an element with a high number of "yes" would be considered interesting even with an higher number of "no".

Just looking at a volume would mean that elements with a high volume of "no" (ex: 90%) would be considered important.

Taking the difference between "yes" and "no" is the only solution to scale well with volume and to really account for agreeing and disagreeing people.

Delegations embody two major features, they are done on one element and its sub-elements, they can be overriden with other delegations or choices.

At first, I thought delegations could form a cycle without any trouble: ie person A delegate her voice to B, B to C, C to A (A->B->C->A). But after two weeks trying to come up with some algorithm, I finally gave up, so delegations which could result to a cycle are now refused.

Another difficulty was determining the number of voices given to choices, the tree of delegations potentially leading to very complex calculations. To handle that, sub-delegations are introduced at every step in the tree to propagate overriding choices or delegations.