Remaining bugs
==============
(most important first)

- You should not be able to edit language-independent fields in a translation.
  The translator should only translate, not change the canonical content in any
  way. Right now he can.

- You can edit the Description of the canonical object inside a translation for
  some reason. The same happens on the Attendees and Event Type fields on an
  Event. Looks like an error in the AT text widget or something, since it
  happens consistently in all of these cases?

- You have two documents - frontpage-en and frontpage-pt. If you have a direct
  link to frontpage-pt, but your language settings are English - you get the
  English page - which is really cool. However, the URL is still frontpage-pt
  even though you are viewing frontpage-en. Can we fix this with a redirect or
  something? Having the content in one language while the URL is for another
  language sounds like a recipe for search engine indexing disaster to me.

- "Edit" tab of a translation is not highlighted when you click it

- Remove the workflow pulldown when on the Translation Unavailable screen
  (maybe disable the entire border, I think that makes sense. You are not
  in a content item anymore)

- No Cancel button on split screen translation form


To do before 1.0 release
========================

  LinguaPlone changes:

  - Pending translations managed using worklists, workflow script to mail
    maintainers with diff of changes in canonical version.

 - AUTO_NOTIFY_CANONICAL_UPDATE - it's accessible only in the config.py, a way
   to set the value through the web is better so we can manage the plone
   instance behavior.

 - When translating a folder and copying over already translated subobjects,
   chop off the -languagecode appendix of the id of the translated objects.


  Plone changes post-2.1:

  - Footer in Plone sites need to be a content item, so it can be translated.

  - File and image fields need special attention when language independent.
    If you create content, upload file, then create a translation the file
    is not copied over to the translation, and will not be copied over when
    saving, like other fields will. Can either sync on save or copy everything
    over when creating the translation. Accessor lookup should work as normal.


Documentation
=============

  - Write "Content Language Fallback Considered Harmful" document to avoid
    getting silly patches and add-on products that try to do things you
    shouldn't do. Also for consultants to give to their customers.


Archetypes changes
==================

  - Enable language aware references tool to enable linking to canonical and
    retrieval of correct translation (this has to be fixed in Archetypes).


Additional notes
================

  - Our approach so far has been that you delete all translations when you do a
  delete operation, and you can remove individual translations with the
  Manage Translations menu item on the objects themselves - I still think
  this is the most sane and usable approach.

  It's not implemented for copying and moving objects. We should
  probably consider implementing it, but it's not straight forward.

  Some cases:

  If you move content between folders, you'd expect that translations are
  moved between corresponding translated folders. What if you're moving to a
  folder that isn't translated yet. Everything could be moved into the
  untranslated folder, but then you'd need id resolution.

  Can you only move the original content (canonical translation), or can you
  move translations? Technically it's not a problem to have different
  hierarchies in the different languages as it's all done by references, but
  it might not desirable.

  When you paste, you might get id conflicts. These are typically resolved by
  'copy of id', but it's not obvious what happened to the ids of the copied
  translations until you check the screen later. And there is no easy way of
  easily changing all ids. Maybe we should change all translation ids that
  are the same as the id of the canonical translation when renaming the
  canonical translation.

  There are probably more gotchas that would have to be worked out.
