[Freecats-Dev] Dan's API - first remarks

[Henri Chorand]

Hi all,

> I've also broken out the services into separate TranslationMemory,
> TranslationGlossary and MachineTranslation pieces, even though
> they're served by the same server; that way they don't have to be.

This is a good precaution.

> Here's a brief description of the API functions, all strings are utf-8
> encoded:

If I got it well, you suggest using SOAP as a general RPC (remote procedure
call) mechanism. I only have a basic understanding of this, and I don't have
any opinion about which one to choose and implement.

Let me know if there is a not-too-technical description of SOAP somewhere,
it will interest people like me.


I'll have a more detailed look at your document. For now, I'm enclosing a
few remarks.

> ++++++++++++++++++++++++++++++++++++++++++++++++
>
> TranslationMemory  # Implements translation memory
> =================
>
>  >> getSegmentMatches() <<
>
> Arguments:
> ^^^^^^^^^^
> user # Username of user accessing database; I don't do
> # anything with this yet but it's there for eventual # access control

It will definitely prove useful.
I thought about implementing a basic access control.


> project       # Only return segments that belong to this project, or
>                        # use "_ALL_" for any project. This *WILL
> CHANGE* in # future to an array to allow a list of projects

One remark here.
A TM server should be able to serve requests concerning several TMs (one at
a time, obviously). So, the TM's ID should be part of the input parameters.

In order to better manage TM contents, we thought about the possibility to
add some description fields to each TU in a TM.
My draft proposal is closely inspired from what we presently find in Trados.
I suggest using two list of string values:

1) sub-project values list
Each one being "on" or "off" (selected or not) in order to identify a given
TU and to apply filters when needed, so as to better mark each TU when used
(Example: User Interface, Online documentation, Paper documentation,
Marketing docs etc. etc.)
The idea is that the administrator will create and maintain a list of string
values, their use being optional.

2) category values list
This would enable to mark each TU as:
Not translated
Translated
Reviewed
Legacy (exists in TM prior translation, but not reviewed yet)

This would make up the basis of a rather strict workflow-style management of
the translation process.

As a rule, there is no point in trying to use a "big mamma TM" in which one
would mix TUs originating from several different projects.



Cheers,

Henri