Otavio, Gintautas,I think that we are rolling now, except that, if we want to start with the DB as soon as possible, somebody else -other than Gintautas, who will be busy with the API- should start looking into the design of the DB, and then adapt to the API that Gintautas will develop. It would be great if we can find somebody who has the right expertise and is already involved in Debian. As I said, WorForge could put some money into it. We would work with this developer providing information and guidance (types of information and relationships) and Dwayne also has quite a bit of experience on RDB design. The developer would have to work closely with Gintautas, as while doing the DB design, a lot of new necessary pieces of data will come out (metadata that is not in the XLIFF files about workflow, statistics, etc...) and this data will also have to be managed by the API.
The API will have to include things that are not implemented now, building on the work that Friedle is doing on statistics, as we will have to keep data on goals, as well as objects that we have not yet implemtented (data on projects, packages..). I would be really happy if we have this at the end of the summer. It will take work from many of us, but will clearly finish the design of the data that will be used by Pootle at the end
I agree that this work should take priority over the XML-RPC.If you agree with this. How do we go about finding somebody who has a couple of months to work on the DB?
Some more comments below.
Translation memory would always be in a database (capable of importing and exporting TMX format), which would be common to all projects in the same language, even if each translation would be marked with its project and string of origin, so that matching engines can give priority to strings that come from the same project, but can also find others. The translation memory database would be (logically) separate from the DB that includes current projects, as it might come from the outside (from projects external to Pootle) or match translation that are no longer in this Pootle server.If we use a common database as backend we won't need to write converters to share translations between all the projects and formats. We can just reuse a existent string as suggestion in case of it to be used in more then one project and also, in case of someone fix the traslation be able to suggest the improvement to other projects that use the same string. That wouldn't happen very often but will help or translators a bit.
Nevertheless, if all was in databases, the process of matching translation memory would have as result that information is copied from the TM DB into the "current projects" database, as matches that are related to a particular untranslated string.
This is probably correct. At the end the editor will have to work with files. In the Pootle server interface, the translator will first identify the files that (s)he wants to work in, and then will decide if (s)he want to translate them online or download them. The editor is called from the server. I would like to have Friedle's or David's opinion on this.Also, I would see the a separation between the Pootle web-based file server and the Pootle editor, and maybe putting them on top of the API, even if maybe this is not the best place for the editor. Would this break the idea that you expressed with the server layer above? |-----------------------------------------------------------------------------| | Clients | | CVS/SVN | | Other Pootle | | FOSS projects | | servers | | | | Rosetta | Translators Reviewers, etc. | | | Off-line Editors| | | | Compiler farm | | | |-----------------------------------------------------------------------------| | XML-RPC server | Pootle file Server| Pootle Editor| Other servers + filters| |-----------------------------------------------------------------------------| | API to access the data | |-----------------------------------------------------------------------------| | RDMS with data | File based System | Other back-ends? | |-----------------------------------------------------------------------------|No. It doesn't break anything. When I said Pootle I meant anything that's involved on it. My suggestion might put Pootle File Server bellow of Pootle Editor since it might allow us to just put the compatibility layer at this level.
I will copy this design to the Wiki, putting the editor on top of Pootle. Javier