= Translations-Bazaar integration =

There are several things that need to be done to integrate Rosetta with Bazaar:

 * Import static translation files from a branch into Rosetta
   * Import POT files
   * Import PO + POT files (default)
   * Import PO files only (i.e. POTs will be manually uploaded) - not needed?

   * Re-generate POT files for certain module layouts (future)
     (harder, but already done in damned-lies for intltool, not standard gettext)

 * Commit to a predefined branch
   * Overwrite existing PO files (no need to worry about merging issues)

   * Branch has canonical translations: accept only improvements (msgmerge giving precedence to what is in the branch already)
   * LP is the canonical translations source (msgmerge giving precedence to what is in LP)

These are preliminary notes from the call: they need to be further discussed inside the Translations team, and separate blueprints filed along with estimation of task costs.

== Notes ==

 * bzrlib allows working on entire branch in memory; with a LP IBranch, one can do getBzrBranch() to get the actual branch.
 * job management should be ready with example scripts in 2.2.1
 * make sure un-committing stuff doesn't cause any problems
 * vcs-imported branches act the same for reading (and that's what we'd most be interested in; we'd need to make sure one can't designate vcs-imported branch as the commit target)
 * import PO files from vcs-imported branches is more important than committing; for hosted branches it's the other way around (maintainers can do only an initial upload of translations, and never have to upload them again)
 * joining the import and commit together brings another problem: do not enter an infinite loop where LP imports translations which LP just committed

== Import translation files from a branch ==

 1. Add ProductSeries.translation_sync_level = TEMPLATE | TEMPLATE_AND_TRANSLATIONS
    or Product.translation_sync_level (i.e. for maintainers to decide on whether to import only POT or both POT and PO files)
 2. Choose a branch to work on: act when branch-scanner gives us the branch ID.
 3. Branch ID is passed to the rosetta-branch-importer.py, where we figure out the product and series it's relevant to (only one branch per series)
 4. Get branch and make use of bzrlib to access all the latest files and figure out which ones we need, then directly append them to translation_import_queue
 5. Testing all this is going to be a bit involved (how best to do it?)

=== Notes ===

 * One might not want to sync translations periodically, especially for hosted branches, if they are using Launchpad as the main translations repository (i.e. that resets the "is_imported/published" flag for each message to True if commit is enabled as well, and we'd probably want that to happen only on actual release).
 * Private branches can be handled in exactly the same way, except that we don't support private translations (Closed, yes, but one can still see msgids): is this a concern or not?
 * Implementing support for extracting POT files properly when module uses one of standard layouts, like GNU gettext (along with gettext.m4) or intltool (and rules from intltool.m4) is left for later; initially, we should support only static POT files.
 * Multiple POTemplate can be handled in the same way, we'd need to be careful with path handling though.

== Commit PO files to a branch ==

For the simple case of overwriting existing files during commit, we'd need to do the following:

 1. Add ProductSeries.translation_branch for commits (can be any of the existing branches, including the series one [default], but has to be hosted in Launchpad)
 2. A Rosetta export job to export anything that has changed since the last export (contention issues?), and with that data available, prepare for commit
 3. Allow loganberry/forster access to bazaar branch storage (to be able to commit)
 4. Do the commit of the new translation files
 5. Push the branch if it's needed

=== Notes ===

 * Watch out not to cause infinite loops when committing a file, importing it back, then committing it again, and so forth.
 * Commits would happen periodically (eg. every day)
 * Private branches can be handled in the same way
 * Multiple POTemplates per product will cause problems due to existing bugs with path handling (i.e. we sometimes export files with bad paths).
 * Periodically exporting a tarball with all translations would solve another big set of use cases for those not wanting to use bzr branches for translations (though, we'd have to be careful to store only a limited set of tarballs, eg. the last few, or with a certain pre-set "smart" time distance).