WFS can also be launched together with WfServerRelay (also provided in the application installation download, WfServer.zip). In that mode, client applications can communicate with WfServerRelay, who in turn communicates with WFS. WfServerRelay uses HTTP for communication, and responds to REST-like commands, making integration a lot easier. This way, WfServer can be integrated with an existing application in virtually an hour.
Here are the main REST methods to be used with WFS. Query methods are URL-based. The replies from WfServerRelay are HTTP (XMLHTTP) bare text frames that are made of Unicode UTF-16 (16-bit characters), but which do not include an HTML skeleton.
For the example below, we assume that WFS was set up as for the Wordfast Classic example in Annex 1, where address means a valid IP number, or a valid domain like http://www.MyWebSite.com. The tests below use a local 127.0.0.1 address + default 81 port for WfServerRelay, 127.0.0.1 + default port 47110 for Wordfast Server, an account named EN2FR with a password as password. The WFS EN2FR account points uses a TM that contains leverage (various translations) for our test sentence.
Server reply format
All found Translation Units (TUs) are in tab-delimited text format, meaning all TUs are separated with ASCII 13 (carriage return), and within each TU, fields are separated with ASCII 9 (tabulators). After the block of TUs, there is an ASCII 16 character followed by all found terminology entries, in the same tab-delimited text format. The TU and glossary format is that of Wordfast Classic TM and glossaries, explained in the Wordfast Classic technical reference manual (www.wordfast.net > Products > Download > technical reference manual or click here).
Here is a full example, where the source segment to query is "Nice day for a Wordfast Server test.", and where the reply has one 100% match, one fuzzy 91% match, and two glossary entries, one for day, and one for Server:
Query (opening a session)
Note: this very first command in a session must send an HTTP header where the header's name is "From" and the headers' value is a unique ID that identifies the client application. Keep the ID short, for example, 5 to 15 ASCII characters. The ID should remain the same for one client for the duration of a translation session. It is used to manage accidental deconnection/reconnection during a session, or when multiple clients are connected.
Reply from server:
where 1 means "no error", 22 is an echo of the command, the two other parameters are not used.
The following command instructs WfServer to use the glossary that is attached to the current account. It can be skipped if terminology is not used:
There is no reply to the above command.
the now=token... parameter is used to sidestep the URL caches on most system. Use it if you needed. Most personal computers cache server replies.
All parameter values are URL-encoded. for example, %40127%2E0%2E0%2E1%3A47110 means @127.0.0.1:47110
Query TM and terminology for a source segment
Now let us query the following source segment: Nice day for a Wordfast Server test.
Next, we let the server know we expect a reply buffer:
Note that you may have to introduce a slight delay after this command, depending on how fast the server replies, or check the ReadyState status of your XMLHTTP object . The &getdata value (20000) is the max size of the reply buffer in bytes.
Reply from Wf Server
10020140106~161446 YC 3 EN-US Nice day for a Wordfast Server test. FR-FR Belle journée pour un essai de Wordfast Server.
09120140106~161446 YC 1 EN-US Nice day for a Wordfast Server evaluation. FR-FR Belle journée pour une évaluation de Wordfast Server.
day journée yves' glossary
Server Serveur yves' glossary
The character is ASCII/ANSI 16. It separates the first block of Translation Units (TUs) from the second block, which are glossary entries.
The first three digits in TUs is the match score. The second TU has a match score of 91. Then comes the TU's date+time stamp, translator's initials, re-use counter, source language code, source sentence, target language code, target sentence, and optional meta tags for the TU, also known as "attributes". All fields are separated with tabulators (ASCII 9).
Now we close the session
Other common commands:
15: Concordance search. The ¶= parameter passes the terms to be looked up, separated with a space (meaning OR), or a plus sign (meaning AND). The server sends back a block of TUs, with up to the 50 best hits. TUs either contain some/all terms (OR), or all terms (AND). DOS-like wildcards can be used such as ? and *.
TUs are sent back with the most relevant at the top. Concordancing is done on the target language. If the reply is larger than the reply buffer block size, more replies are sent, and must be fetched.
9: Delete a TU based on entire TU. The TU to be deleted must be passed as argument. All TUs where all fields (date+time, source segment, target segment, language codes, attributes, etc) match the passed TU are deleted.
10: Add a TU. The entire TU must be passed as parameter.
25: Close a translation session.
The full list of commands is in Appendix 3.