Projects:Translation Management/Initial Requirements

Translation Management - Initial Requirements

Original requirements received from Paolo Juvara.

I would like to have him think of the full life cycle of the translation process:

• Initial creation of a translation
  • This would probably entail being able to easily generate a set of PO files from our base language, importing them into a translation tool such as KBabel, translate and publish
  • Do we need XML files?
  • If we do, rather than having a proprietary format as we do now, is there a standard? Can we leverage DBSourceManager to export translations rather than having a dedicated piece of code as we do now?
  • What does it mean to publish (see below)?
• Publication of statistics of availability, completeness and quality (as a subjective measure based on community voting or endorsements) of translations
• Installation of a translation
• Refinement of a translation
  • What I envision here is that the user would run Openbravo in a "Refine translation" mode. In that mode (which needs to be secured and available only to certain roles), user would be able to use the application as usual but when they find a translation that is incorrect or invalid, they could press a button on the top of the screen and edit it directly in the transactional UI.
  • They should be able to decide whether this change is local to the current instance or is submitted to the community as a proposed change.
  • In the latter case, a request for change would be submitted as web service call to a central repository that holds all the published translations.
  • The central repository could be a hosted Openbravo environment that is able to receive these requests. Requests are routed for approval to the owner of the translation (the original author or somebody else that we appoint). That person can review it and either accept or reject the correction. If accepted the new translation replaces the old one.
  • This environment should have appropriate reporting capabilities to know how many requests have been submitted, accepted, rejected and how many are pending. This would allow us to manage the community.
  • It could also be the source of truth for the statistics.
  • Users should be able to download a language pack on demand from this environment. They should be able to download either the latest translation including only approved changes or the latest translation including the pending changes as well (for testing purposes)
  • We could also think of automating the publication process to SF from this environment (i.e. press a button and all the languages are published to SF).
• Testing to Production:
  • I think that users should use good life cycle management practices for local changes to the translation. If you want to customize it to fit your own terminology, you should first do that in a test environment and then promote it to your production environment.
  • How do we do that?
  • This is potentially where XML and DBSourceManager could play a role.

Clearly all of this would need to be broken down in several smaller projects, possibly implemented over the course of several releases, but I think it is good to have the big picture in mind before we start.