Monolingual formats

Bilingual

• retain existing behaviour for bilingual projects
• any useful features may be ported across once stable

Template authority

• templates are absolutely authoritative
  • a store cannot exist in a lang tp if not in corresponding template tp
  • a unit cannot existing in lang stores if not in corresponding template store
  • all stores/units in template tp are present in all lang tps

Unit/Store persistence

• 2 possible approaches
  • Stores/Units are only created in db when the lang unit has a target (or other data)
    • lets call it "shadowed tps"
  • Stores/Units are created/updated/deleted in every lang tp on template change
    • "mirrored tps"

Shadowed TPs

• far better design
  • more efficient
  • less units
  • less change
• requires more work most of the way through stack
  • de/serialization
  • unit retrieval (ie get_units)
  • diffing/Store.update

Mirrored TPs

• way less efficient
• requires far less work to implement
• could be converted to shadowed approach once stable

Template versioning

• when templates are significant there are some advantages to retaining a copy of the template at a particular sync/revision
• in the mlo case there is a desire to preserve formatting (present in the template) in the target lang files, so having a stored copy of template will make it easier to do so

pootle_fs/project_tree

• initial focus is on getting pootle_fs to (be able to) do things in the right order and delegating to correct authority
• not clear what (if any) changes to project_tree codepath would be required to make it work - may be just a matter of documentation
• disable monolingual formats for non-pootle_fs ?

source_language authority

• still need to resolve relationship between named templates tp and linked source_language for a given project