Re: [translate-pootle] [Fwd: Re: Wordforge]
A couple of comments purely from the translator's point of view. :)
On 10/06/2006, at 8:55 PM, Javier SOLA wrote:
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 in fact will _save_ us further conversion and fiddling around, as
they are used more. Among other things, use of the standards will
facilitate co-operation between the professional and free-software
translation arenas. They are a basis for effective growth and
communication in the likely future.
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
The file-based system using XLIFF can also allow for deeper and more
direct interaction between the infrastructure and the translator/
language team.
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,
This separation can also allow for different editors to interact with
the file server. I know LocFactoryEditor's developer is interested in
interacting with the Pootle server, and I think the Kbabel developers
would also be interested. This type of pluggability will make it much
easier for translators to switch between online and offline editing,
depending on the situation.
[File menu]
New
Open...
Open from server...
...
Save
Save to server...
just as a good text editor interacts with FTP servers and source
control.
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?
and I see "Offline Editors" in the diagram below. This means the
interaction between the main server layer and the one above has to be
flexible enough to allow for different workflows. (I know this kind
of detail isn't that relevant yet, but it's worth keeping in mind
while working on the main server layer at least.)
|---------------------------------------------------------------------
--------|
| 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? |
|---------------------------------------------------------------------
--------|
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.
If we build into the system a capacity to interact with different
backends, nobody will be locked into any single choice in the future.
At different times (and for different projects), different choices
will be appropriate. Keeping our options open at both backend and
frontend interaction levels reduces the barriers not only for
translator and language-team participation, but also for ongoing
technical contribution from the free-software community. I don't mean
that people will be running up new backends over the weekend, but
that whatever situation comes up, people will have the option to
adapt current backends, or to take advantage of new opportunities.
Not so much "agnostic" as "aware".
from Clytie (vi-VN, Vietnamese free-software translation team / nhóm
Việt hóa phần mềm tự do)
http://groups-beta.google.com/group/vi-VN
Reply to: