Re: [translate-pootle] [Fwd: Re: Wordforge]
Javier SOLA <javier@Khmeros.info> writes:
> Hi Otavio, Guintautas,
>
> I would like to propose a course of action.
>
> 1.- Gintautas works on the API (which has to include the separation of
> front-end and back-end), and on the XML-RPC. This will really clear up
> things for further work, and will facilitate the specification of a
> DB. This work is done in a separate branch, as required by the
> project.
That shpuld be done together with WordForge team since they know the
code better with us and would also help to discover how is the easier
way to split them.
> 2.- The WordForge present staff will integrate these changes in Head
> as soon as they are clear, so that Gintautas' branch and Head stay as
> close as possible, and integration is not a problem later.
Good.
> 3.- Independently of the work that is continuing on WordForge
> (front-end or file-based back-end), WordForge will be happy to fund
> somebody to work on designing and implementing a RDB back-end. This
> can be somebody working on parallel during the coming months, or
> Guintautas after he finishes (if he has time before going back to
> school). Then we just use -or continue working on-the best back-end
> that we have. We would work together with this person to ensure that
> all the data that we need in the project is present in the DB (even if
> most of should be defined already defined by the API).
Yes. I agree that WordForge shouldn't stop its development.
> I somehow have a feeling that the optimal result will be something
> between file-based and DB based, again, I could be completelly
> wrong. We will not really know what it is until we try.
I disagree. I think that the files will be the product of the system.
> Some more comments below.
>
> Otavio Salvador wrote:
>
>>Gintautas Miliauskas <gintas@akl.lt> writes:
>>I fully agree with you that we should avoid to store data directly on
>>files also because if we later discover another format will be very
>>difficult to reuse old data and we'll need to make converters for
>>it. So, let does it from basic design.
>>
>>
> I have to disagree with this. Independently of if the best storage is
> files or DB, the standard formats are precisely done so that they will
> last for a long time. XLIFF is an OASIS standard that will evolve, and
> will not be replaced in the coming decades. Same as Unicode, the
> standards are there to last... and, even if change, happened, you
> would still need to write converters. On the contrary, when these
> standards advance (within backwards compatibility), you will have to
> modify the database to admin new types of information, but you would
> not need to modify a file-based system
Well, it depends. 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.
>>One thing that come to my mind just now is that we might have the
>>following design:
>>
>> |--------------------------------------|
>> | | Pootle itself |
>> | Clients |----------------------------|
>> | | Pootle compatibility layer |
>> |--------------------------------------|
>> | XML-RPC server | Other servers |
>> |--------------------------------------|
>> | API to access the data |
>> |--------------------------------------|
>> | RDMS with data |
>> |--------------------------------------|
>>
>>
>>
> Adding a little more meat:... 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.
>>The only drawback on it that I can see is that we won't contribute
>>much code back to Pootle directly. Basically fixes to get it more
>>"backend agnostic" and then plug our backend there. That, IMHO, is a
>>good conseguence since they'll be free to choose and develop other
>>backends without the compromise to us just one.
>>
>>
> Our idea -as I mentioned- is still that we work together in the
> different options. We would not like to see an "our back- end" and a
> "your back-end". The advantage of working together is that there are
> more people thinking, and the good news is that we have sufficient
> funding to look at both options, and then pick up the one that we all
> agree is the best, and continue working in that direction.
My suggestion might, for Gintautas start to work on a prototype of the
RDMS and the API. After we have something useful there, start to write
the Pootle compatibility layer (not the XML-RPC) since it'll be our
first "production system" and also will allow to us to see if it's the
right choice and stop to work on the 'wrong' one ASAP.
Comments?
--
O T A V I O S A L V A D O R
---------------------------------------------
E-mail: otavio@debian.org UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://www.freedom.ind.br/otavio
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
you the whole house."
Reply to: