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.
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.
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.
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.
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.
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 will copy this design to the Wiki, putting the editor on top of Pootle.
Javier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
