Hello, I've started sketching the API, but I would like to have a chat on IRC with the developers who are working on the new base classes. Should I use your branch or start a new one? When can I find you online, guys? Perhaps I can find you on Jabber? Ottavio? David? Friedle? > 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. I would suggest to wait until the API works with the file-based backend before starting work on an RDB binding. Designing the DB schema should not be difficult here, because we will have the object model in the API and we will only need to do a direct translation "OO model" -> "RDB schema", which is a mechanical task. What is needed here is experience of engineering components that use an RDB, and admittedly I don't have much of that. > 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. Everything that is in XLIFF will have to be in the API too, because it is an abstraction layer. There can't possibly be any piece of information that is not abstracted, so there should not be anything new directly related to an RDB. > 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 Sure, statistics will be made abstract operations too. > I agree that this work should take priority over the XML-RPC. XML-RPC would be a layer above the new backend, so it makes no sense to start doing it now. > 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. IOW, the translation memory should be a separate component. Agreed. > 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. I'm not Friedle or David ;) but I think that this is not conceptually sound. In the online editor the user is not editing a "file", s/he is editing translations. That's the whole point: if they want a file, they use the "file server" frontend, and if they want to change a single string through-the-web, they use a web-based frontend built directly on our backend which will have a specific operation for changing a single string. Would you agree? -- Gintautas Miliauskas http://gintasm.blogspot.com
Attachment:
signature.asc
Description: PGP signature