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 code-path 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