Memories and glossaries

Memories and glossaries are how the engine learns to translate your way. Both belong to one language pair, and both are used by naming them when you translate.

	Translation memory	Glossary
Holds	Sentences you have already translated.	Terms that must always be translated the same way.
Effect	A sentence that is in the memory is not sent to the engine. Close matches guide the translation.	Its terms are applied in every sentence where they appear.
Id	tm_…	gl_…
Files	TMX, CSV, TSV	TBX, CSV, TSV
Routes	/v1/memories	/v1/glossaries

Upload a file

Send the file as a form (multipart/form-data) with its two languages. The answer is 202 with the memory or the glossary in the status indexing: its entries are being read. When the status is ready, it can be used.

AUTH="Authorization: Bearer $TRANSLAQE_API_KEY"

# A translation memory, from a TMX file. It is ready when its status is "ready".
curl -s https://api.translaqe.com/v1/memories -H "$AUTH" \
  -F "[email protected]" -F "source_lang=es" -F "target_lang=en" -F "name=Legal ES-EN"

# An empty glossary, filled term by term.
curl -s https://api.translaqe.com/v1/glossaries -H "$AUTH" \
  -H "Content-Type: application/json" \
  -d '{"name": "Legal terms", "source_lang": "es", "target_lang": "en"}'

curl -s https://api.translaqe.com/v1/glossaries/gl_3f9a1c2b7d5e4f60a1b2c3d4e5f60718/entries \
  -H "$AUTH" -H "Content-Type: application/json" \
  -d '{"source": "preaviso", "target": "notice period"}'

To know when it is ready, ask for it (GET /v1/memories/{id}), follow its job (job_id, at GET /v1/jobs/{job_id}) or give a webhook_url when you upload it. If it ends failed, error_code says why: invalid_resource, empty_resource.

A CSV or TSV file must be in UTF-8, with the source in the first column and the target in the second. If the first row names the languages (es, en), those columns are used wherever they are. A file can be up to 50 MB.

Or build it entry by entry

Send JSON instead of a file and you get an empty memory or glossary, ready at once (201). Then add entries one at a time:

• POST …/entries adds an entry. If there was one with the same source, it is replaced (200); if it is new, 201.
• PATCH …/entries/{entry_id} changes the target of an entry.
• DELETE …/entries/{entry_id} removes it.
• GET …/entries lists them; with q, the ones whose source is closest to a text.

An entry can be used from the moment it is added. This is how you keep a glossary alive from your own terminology tool, or feed a memory with what your reviewers approve.

Use them

Name them in memory_ids and glossary_ids when you translate text or a document: up to 20 of each, and all for the language pair of the request. One that is for another pair is rejected with 400 (resource-language-mismatch).

Projects

A project groups the memories and the glossaries of one client or one kind of content. Add them once:

PUT /v1/projects/prj_…/resources/tm_… HTTP/1.1
Authorization: Bearer tq_live_…

Then translate with project_id and all the ones for that language pair are used, without listing them each time. Documents sent with a project are listed under it (GET /v1/jobs?project_id=prj_…).

Feed the memory with what gets reviewed

After a document has been reviewed, POST /v1/jobs/{job_id}/review adds to a memory the sentences a person wrote or approved. It is the loop that makes each translation cheaper and closer to your style than the last.