# Delete Lilt Create content
Source: https://support.lilt.com/api-reference/create/delete-lilt-create-content
/api-reference/openapi-bundled.yaml delete /v2/create/{contentId}
Delete a piece of Lilt Create content.
Example CURL:
```bash
curl -X DELETE 'https://api.lilt.com/v2/create/1234?key=API_KEY'
```
# Generate new Lilt Create content
Source: https://support.lilt.com/api-reference/create/generate-new-lilt-create-content
/api-reference/openapi-bundled.yaml post /v2/create
Generate new Lilt Create content with the given parameters.
Example CURL:
```bash
curl -X POST 'https://api.lilt.com/v2/create?key=API_KEY' \
--header 'Content-Type: application/json' \
--data-raw '{
"language":"en-US",
"template":"blog-post",
"templateParams":{
"contentLength":"100",
"language":"en-US",
"sections":[],
"summary":"a blog post about hiking"
},
"preferences":{"tone":"formal","styleguide":""}
}'
```
# Get Lilt Create content
Source: https://support.lilt.com/api-reference/create/get-lilt-create-content
/api-reference/openapi-bundled.yaml get /v2/create
Get a list of all content that has been generated by Lilt Create.
Example CURL:
```bash
curl -X GET 'https://api.lilt.com/v2/create?key=API_KEY'
```
# Get Lilt Create content by ID.
Source: https://support.lilt.com/api-reference/create/get-lilt-create-content-by-id
/api-reference/openapi-bundled.yaml get /v2/create/{contentId}
Get Lilt Create content by ID.
Example CURL:
```bash
curl -X GET 'https://api.lilt.com/v2/create/1234?key=API_KEY'
```
# Update Lilt Create content
Source: https://support.lilt.com/api-reference/create/update-lilt-create-content
/api-reference/openapi-bundled.yaml put /v2/create/{contentId}
Update a piece of Lilt Create content.
Example CURL:
```bash
curl -X PUT 'https://api.lilt.com/v2/create/1234?key=API_KEY' \
--header 'Content-Type: application/json' \
--data-raw '{"language":"de-DE"}'
```
# Download a Document
Source: https://support.lilt.com/api-reference/documents/download-a-document
/api-reference/openapi-bundled.yaml get /v2/documents/files
Export a Document that has been translated in the Lilt web application.
Any Document can be downloaded in XLIFF 1.2 format, or can be retrieved in its original uploaded format by setting `is_xliff=false`.
This endpoint will fail if either (a) export or (b) pre-translation operations are in-progress. The status of those operations can be determined by retrieving the Document resource.
Example CURL command:
```bash
curl -X GET https://api.lilt.com/v2/documents/files?key=API_KEY&id=274 -o from_lilt.xliff
```
# Pretranslate Documents
Source: https://support.lilt.com/api-reference/documents/pretranslate-documents
/api-reference/openapi-bundled.yaml post /v2/documents/pretranslate
Pretranslate one or more Documents using translation memory (TM) and,
optionally, machine translation (MT). Only documents that are not
currently importing/exporting and are not already pretranslating will
be pretranslated; the response always reflects the current state of
every requested Document id, whether or not it was eligible.
This is an asynchronous operation. The endpoint returns immediately
with a `202` response once pretranslation has been queued; poll the
Document resource (or the `is_pretranslating` / `status.pretranslation`
fields it returns) to see when pretranslation has finished.
This endpoint is subject to a per-organization rate limit. See the
[API Rate Limits guide](/developers/guides/rate-limits) for details on
how to read `429` responses and batch requests efficiently by passing
multiple document ids in a single call.
Example CURL:
```bash
curl -X POST 'https://api.lilt.com/v2/documents/pretranslate?key=API_KEY' \
--header 'Content-Type: application/json' \
--data-raw '{"id": [274, 275], "mode": "TM+MT", "auto_accept": true}'
```
# Upload a File
Source: https://support.lilt.com/api-reference/documents/upload-a-file
/api-reference/openapi-bundled.yaml post /v2/documents/files
Create a Document from a file in any of the formats [documented in our knowledge base](/kb/supported-file-formats).
Request parameters should be passed as JSON object with the header field `LILT-API`.
File names in the header can only contain [US-ASCII characters](https://en.wikipedia.org/wiki/ASCII). File names with characters outside of US-ASCII should be [URI encoded](https://en.wikipedia.org/wiki/Percent-encoding) or transliterated to US-ASCII strings.
Example CURL command:
```bash
curl -X POST https://api.lilt.com/v2/documents/files?key=API_KEY \
--header "LILT-API: {\"name\": \"introduction.xliff\",\"pretranslate\": \"tm+mt\",\"project_id\": 9}" \
--header "Content-Type: application/octet-stream" \
--data-binary @Introduction.xliff
```
# Retrieve Domains
Source: https://support.lilt.com/api-reference/domains/retrieve-domains
/api-reference/openapi-bundled.yaml get /v3/domains
Retrieve a list of Domains associated with the Organization's API key.
Each Domain contains potentially 4 Arrays related to the Domain these are as follows:
- models - the list of models associated with the Domain
- filterConfigs - the list of filterConfigs associated with the Domain
- domainMetadata - the list of Domain specific options that have been configured for this domain.
# Add Label to File
Source: https://support.lilt.com/api-reference/files/add-label-to-file
/api-reference/openapi-bundled.yaml post /v2/files/labels
Add a label to a File.
Example CURL:
```bash
curl -X POST 'https://api.lilt.com/v2/files/labels?key=API_KEY&id=1'
--header 'Content-Type: application/json' \
--data-raw '{
"name": "label_name"
}'
```
# Delete a File
Source: https://support.lilt.com/api-reference/files/delete-a-file
/api-reference/openapi-bundled.yaml delete /v2/files
Delete a File.
Example CURL command:
```bash
curl -X DELETE https://api.lilt.com/v2/files?key=API_KEY&id=123
```
# Download file
Source: https://support.lilt.com/api-reference/files/download-file
/api-reference/openapi-bundled.yaml get /v2/files/download
Download a File.
Example CURL:
```bash
curl -X GET 'https://api.lilt.com/v2/files/download?key=API_KEY&id=1'
```
# Remove Label from File
Source: https://support.lilt.com/api-reference/files/remove-label-from-file
/api-reference/openapi-bundled.yaml delete /v2/files/labels
Remove a label from a File.
Example CURL:
```bash
curl -X DELETE 'https://api.lilt.com/v2/files/labels?key=API_KEY&id=1&name=label_name'
```
# Retrieve a File
Source: https://support.lilt.com/api-reference/files/retrieve-a-file
/api-reference/openapi-bundled.yaml get /v2/files
Retrieves one or more files available to your user. Files are not associated with a project or a memory. They are unprocessed and can be used later in the project/document creation workflow step.
To retrieve a specific file, specify the id request parameter. To retrieve all files, omit the id request parameter.
Example CURL command:
```bash
curl -X GET https://api.lilt.com/v2/files?key=API_KEY&id=274
```
# Upload a File
Source: https://support.lilt.com/api-reference/files/upload-a-file
/api-reference/openapi-bundled.yaml post /v2/files
Upload a File in any of the formats [documented in our knowledge
base](/kb/supported-file-formats).
Request parameters should be passed in as query string parameters.
Example CURL command:
```bash
curl -X POST https://api.lilt.com/v2/files?key=API_KEY&name=en_US.json \
--header "Content-Type: application/octet-stream" \
--data-binary @en_US.json
```
Calls to GET /files are used to monitor the language detection results. The API response will be augmented to include detected language and confidence score.
The language detection will complete asynchronously. Prior to completion, the `detected_lang` value will be `zxx`, the reserved ISO 639-2 code for "No linguistic content/not applicable".
If the language can not be determined, or the detection process fails, the `detected_lang` field will return `und`, the reserved ISO 639-2 code for undetermined language, and the `detected_lang_confidence` score will be `0`.
# Archive a Job
Source: https://support.lilt.com/api-reference/jobs/archive-a-job
/api-reference/openapi-bundled.yaml post /v2/jobs/{jobId}/archive
Set job to archived, unassign all linguists and archive all projects and documents inside the job.
It will return the archived job.
Example CURL command:
```bash
curl -X POST 'https://api.lilt.com/v2/jobs/{id}/archive?key=API_KEY'
```
# Create a Job
Source: https://support.lilt.com/api-reference/jobs/create-a-job
/api-reference/openapi-bundled.yaml post /v2/jobs
Create a Job. A Job is a collection of Projects.
A Job will contain multiple projects, based on the language pair.
A Project is associated with exactly one Memory.
Jobs appear in the Jobs dashboard of the web app.
Example CURL command:
```bash
curl -X POST 'https://api.lilt.com/v2/jobs?key=API_KEY' \
--header 'Content-Type: application/json' \
--data-raw '{
"name": "test job",
"fileIds": [5009, 5010, 5011],
"due": "2022-05-05T10:56:44.985Z",
"srcLang": "en",
"srcLocale": "US",
"languagePairs": [
{ "memoryId": 3121, "trgLang": "de" },
{ "memoryId": 2508, "trgLang": "fr" },
{ "memoryId": 3037, "trgLang": "zh" }
]
}'
```
# Delete a Job
Source: https://support.lilt.com/api-reference/jobs/delete-a-job
/api-reference/openapi-bundled.yaml delete /v2/jobs/{jobId}
Delete a job, deletes all projects and documents in the job, deletes all the segments from all the job's translation memories.
Example CURL command:
```bash
curl -X DELETE 'https://api.lilt.com/v2/jobs/{id}?key=API_KEY'
```
# Deliver a Job
Source: https://support.lilt.com/api-reference/jobs/deliver-a-job
/api-reference/openapi-bundled.yaml post /v2/jobs/{jobId}/deliver
Set the job state to delivered and set all the projects in the job to done
It will return the delivered job.
Example CURL command:
```bash
curl -X POST 'https://api.lilt.com/v2/jobs/{id}/deliver?key=API_KEY'
```
# Download a Job
Source: https://support.lilt.com/api-reference/jobs/download-a-job
/api-reference/openapi-bundled.yaml get /v2/jobs/{jobId}/download
Make sure you have exported a job with the same id before using this api.
Downloading files requires the exported job `id` in the param.
Example CURL command:
```bash
curl -X GET 'https://api.lilt.com/v2/jobs/{id}/download?key=API_KEY'
```
# Export a Job
Source: https://support.lilt.com/api-reference/jobs/export-a-job
/api-reference/openapi-bundled.yaml get /v2/jobs/{jobId}/export
Prepare job files for download.
To export translated documents from the job use the query parameter `type=files`:
Example CURL command:
```bash
curl -X GET 'https://api.lilt.com/v2/jobs/{id}/export?key=API_KEY&type=files'
```
To export job memories use the query parameter `type=memory`.
The status of the export can be checked by requesting the job `GET /jobs/:jobId`, `job.isProcessing` will be `1` while in progress,
`0` when idle and `-2` when the export failed.
# Reactivate a Job
Source: https://support.lilt.com/api-reference/jobs/reactivate-a-job
/api-reference/openapi-bundled.yaml post /v2/jobs/{jobId}/reactivate
Set the job state to active. Does not change the state of projects associated with the given job.
It will return the reactivated job.
Example CURL command:
```bash
curl -X POST 'https://api.lilt.com/v2/jobs/{id}/reactivate?key=API_KEY'
```
# Retrieve a Job
Source: https://support.lilt.com/api-reference/jobs/retrieve-a-job
/api-reference/openapi-bundled.yaml get /v2/jobs/{jobId}
Retrieves a job data along with stats. To retrieve a specific job, you will need the job `id` in the url path.
Example CURL command:
```bash
curl -X GET 'https://api.lilt.com/v2/jobs/{id}?key=API_KEY'
```
# Retrieve all Jobs
Source: https://support.lilt.com/api-reference/jobs/retrieve-all-jobs
/api-reference/openapi-bundled.yaml get /v2/jobs
Get all Jobs within a given offset and limit. You can retrieve jobs from your account using the above API.
Example CURL command:
```bash
curl -X GET 'https://api.lilt.com/v2/jobs?key=API_KEY&isArchived=false'
```
# Retrieve Job Leverage Stats
Source: https://support.lilt.com/api-reference/jobs/retrieve-job-leverage-stats
/api-reference/openapi-bundled.yaml get /v2/jobs/{jobId}/stats
Get the TM leverage stats for the job (new/exact/fuzzy matches).
Example CURL command:
```bash
curl -X GET 'https://api.lilt.com/v2/jobs/{id}/stats?key=API_KEY'
```
# Unarchive a Job
Source: https://support.lilt.com/api-reference/jobs/unarchive-a-job
/api-reference/openapi-bundled.yaml post /v2/jobs/{jobId}/unarchive
Set job to unarchived, the job will move to active status.
Example CURL command:
```bash
curl -X POST 'https://api.lilt.com/v2/jobs/{id}/unarchive?key=API_KEY'
```
# Update a Job
Source: https://support.lilt.com/api-reference/jobs/update-a-job
/api-reference/openapi-bundled.yaml put /v2/jobs/{jobId}
Updates a job with the new job properties. To update a specific job, you will need the job `id` in the url path.
You can update job's name and due date by passing the property and new value in the body.
Example CURL command:
```bash
curl -X PUT 'https://api.lilt.com/v2/jobs/{id}?key=API_KEY' \
--header 'Content-Type: application/json' \
--data-raw '{
"name": "test job",
"due": "2022-05-05T10:56:44.985Z"
}'
```
# Retrieve supported languages
Source: https://support.lilt.com/api-reference/languages/retrieve-supported-languages
/api-reference/openapi-bundled.yaml get /v2/languages
Get a list of supported languages.
# Create a Memory
Source: https://support.lilt.com/api-reference/memories/create-a-memory
/api-reference/openapi-bundled.yaml post /v2/memories
Create a new Memory. A Memory is a container that collects source/target
sentences for a specific language pair (e.g., English>French). The data
in the Memory is used to train the MT system, populate the TM, and
update the lexicon. Memories are private to your account - the data is
not shared across users - unless you explicitly share a Memory with your
team (via web app only).
Refer
to our KB for a more detailed description.
# Delete a Memory
Source: https://support.lilt.com/api-reference/memories/delete-a-memory
/api-reference/openapi-bundled.yaml delete /v2/memories
Delete a Memory.
# Delete a segment from a memory.
Source: https://support.lilt.com/api-reference/memories/delete-a-segment-from-a-memory
/api-reference/openapi-bundled.yaml delete /v2/memories/segment
Delete a segment from a memory.
```bash
curl -X DELETE https://api.lilt.com/v2/memories/segment?key=API_KEY&id=ID&segment_id=$SEGMENT_ID
```
# File import for a Memory
Source: https://support.lilt.com/api-reference/memories/file-import-for-a-memory
/api-reference/openapi-bundled.yaml post /v2/memories/import
Imports common translation memory or termbase file formats to a specific LILT memory. Currently supported file formats are `*.tmx`, `*.sdltm`, `*.sdlxliff`(With custom Filters), '*.xliff', and `*.tmq` for TM data; `*.csv` and `*.tbx` for termbase data. Request parameters should be passed as JSON object with the header field `LILT-API`.
Example CURL command to upload a translation memory file named `my_memory.sdltm` in the current working directory:
```bash
curl -X POST https://api.lilt.com/v2/memories/import?key=API_KEY \
--header "LILT-API: {\"name\": \"my_memory.sdltm\",\"memory_id\": 42}" \
--header "Content-Type: application/octet-stream" \
--data-binary @my_memory.sdltm
```
Example CURL command to upload a translation memory file named `my_memory.sdlxliff` in the current working directory, with Custom Filters based on SDLXLIFF fields, conf_name which maps to, percentage, and whether we should ignore unlocked segments.
```bash
curl -X POST https://api.lilt.com/v2/memories/import?key=API_KEY \
--header "LILT-API: {\"name\": \"my_memory.sdlxliff\",\"memory_id\": 12,\"sdlxliff_filters\":[{\"conf_name\": \"Translated\", \"percentage\": 100, \"allow_unlocked\": false}]"}" \
--header "Content-Type: application/octet-stream" \
--data-binary @my_memory.sdlxliff
```
# Query a Memory
Source: https://support.lilt.com/api-reference/memories/query-a-memory
/api-reference/openapi-bundled.yaml get /v2/memories/query
Perform a translation memory query.
# Retrieve a Memory
Source: https://support.lilt.com/api-reference/memories/retrieve-a-memory
/api-reference/openapi-bundled.yaml get /v2/memories
Retrieve a Memory. If you cannot access the Memory (401 error) please check permissions (e.g. in case you created the Memory via the web app with a different account you may have to explicitly share that Memory).
# Termbase download for a Memory
Source: https://support.lilt.com/api-reference/memories/termbase-download-for-a-memory
/api-reference/openapi-bundled.yaml get /v2/memories/termbase/download
Downloads the termbase export for the given memory as a CSV file.
Ensure you first call the `/2/memories/termbase/export` endpoint to
start the export process before you try to download it.
```bash
curl -X GET https://api.lilt.com/v2/memories/termbase/download?key=API_KEY&id=ID
```
# Termbase export for a Memory
Source: https://support.lilt.com/api-reference/memories/termbase-export-for-a-memory
/api-reference/openapi-bundled.yaml post /v2/memories/termbase/export
Exports the termbase entries for the given memory into a CSV file.
Calling this endpoint will begin the export process in the background.
Check that the processing is complete by polling the `GET /2/memories`
endpoint. When the `is_processing` value is 0 then call the
`POST /2/memories/termbase/download` endpoint.
```bash
curl -X POST https://api.lilt.com/v2/memories/termbase/export?key=API_KEY&id=ID
```
# Update the name of a Memory
Source: https://support.lilt.com/api-reference/memories/update-the-name-of-a-memory
/api-reference/openapi-bundled.yaml put /v2/memories
Update a Memory.
# Create a Project
Source: https://support.lilt.com/api-reference/projects/create-a-project
/api-reference/openapi-bundled.yaml post /v2/projects
Create a Project. A Project is a collection of Documents.
A Project is associated with exactly one Memory.
Projects appear in the dashboard of the web app.
# Delete a Project
Source: https://support.lilt.com/api-reference/projects/delete-a-project
/api-reference/openapi-bundled.yaml delete /v2/projects
Delete a Project.
# Retrieve a Project
Source: https://support.lilt.com/api-reference/projects/retrieve-a-project
/api-reference/openapi-bundled.yaml get /v2/projects
Retrieves one or more projects, including the documents associated with each project. Retrieving a project is the most efficient way to retrieve a single project, multiple projects or a list of all available projects.
To retrieve a specific project, specify the `id` request parameter or you can retrieve multiple projects by adding comma (,) between ids eg. `?id=1234,5678`. To retrieve all projects, omit the `id` request parameter. To limit the retrieved projects to those with a particular source language or target language, specify the corresponding ISO 639-1 language codes in the `srclang` and `trglang` request parameters, respectively.
# Create a Segment
Source: https://support.lilt.com/api-reference/segments/create-a-segment
/api-reference/openapi-bundled.yaml post /v2/segments
Create a Segment and add it to a Memory or a Document. A Segment is a source/target
pair that is used to train the machine translation system and populate
the translation memory.
The maximum source length is 5,000 characters.
# Delete a Segment
Source: https://support.lilt.com/api-reference/segments/delete-a-segment
/api-reference/openapi-bundled.yaml delete /v2/segments
Delete a Segment from memory. This will not delete a segment from a document.
# Retrieve a Segment
Source: https://support.lilt.com/api-reference/segments/retrieve-a-segment
/api-reference/openapi-bundled.yaml get /v2/segments
Retrieve a Segment.
# Tag a Segment
Source: https://support.lilt.com/api-reference/segments/tag-a-segment
/api-reference/openapi-bundled.yaml get /v2/segments/tag
Project tags for a segment. The `source_tagged` string contains one or more SGML
tags. The `target` string is untagged. This endpoint will automatically place the
source tags in the target.
Usage charges apply to this endpoint for production REST API keys.
# Unaccept and unlock segments
Source: https://support.lilt.com/api-reference/segments/unaccept-and-unlock-segments
/api-reference/openapi-bundled.yaml post /v2/segments/review/unlock
Unaccept and unlock segments.
Sets individual segments' "Review Done" to false. Confirmed segments will remain confirmed.
Example curl:
```
curl --X --request POST 'https://lilt.com/2/segments/review/unlock?key=API_KEY' \
--header 'Content-Type: application/json' \
--data-raw '{
"segmentIds": [23921, 23922]
}'
```
# Update a Segment
Source: https://support.lilt.com/api-reference/segments/update-a-segment
/api-reference/openapi-bundled.yaml put /v2/segments
Update a Segment in memory. The Memory will be updated with the new target string.
# Download translated file
Source: https://support.lilt.com/api-reference/translate/download-translated-file
/api-reference/openapi-bundled.yaml get /v2/translate/files
Download a translated File.
Example CURL:
```bash
curl -X GET 'https://api.lilt.com/v2/translate/files?key=API_KEY&id=1'
```
# Monitor file translation
Source: https://support.lilt.com/api-reference/translate/monitor-file-translation
/api-reference/openapi-bundled.yaml get /v2/translate/file
Get information about the one or more Files that are being translated with machine translation. Query filters are optional but at least one must be provided.
Example CURL:
```bash
curl -X GET 'https://api.lilt.com/v2/translate/file?key=API_KEY&translationIds=1,2&fromTime=1607966744&toTime=1707966744&status=InProgress'
```
# Translate a File
Source: https://support.lilt.com/api-reference/translate/translate-a-file
/api-reference/openapi-bundled.yaml post /v2/translate/file
Start machine translation of one or more Files that have previously been uploaded. The response will include an `id` parameter that can be used to monitor and download the translations in subsequent calls.
Example CURL:
```bash
curl -X POST 'https://api.lilt.com/v2/translate/file?key=API_KEY&fileId=583&memoryId=2495&configId=123&withTM=true'
```
# Translate a segment
Source: https://support.lilt.com/api-reference/translate/translate-a-segment
/api-reference/openapi-bundled.yaml get /v2/translate
Translate a source string.
Functionally identical to `POST /v2/translate`, with parameters passed
as query string parameters instead of a JSON request body. Useful for
simple integrations that prefer a GET request.
Setting the `rich` parameter to `true` will change the response format
to include additional information about each translation including a
model score, word alignments, and formatting information.
By default, this endpoint also returns translation memory (TM) fuzzy matches, along
with associated scores. Fuzzy matches always appear ahead of machine translation
output in the response.
The maximum source length is 50,000 characters. When a `prefix` is supplied (prefix-based translation), the maximum source length is 5,000 characters.
Word-alignment and formatting fields (`targetWords`, `targetDelimiters`, and `provenance`) are returned only for prefix or `source_hash` requests. Plain (non-prefixed) translations return `target` and `targetWithTags` only. The source-side fields `tokenizedSource` and `sourceDelimiters` are no longer returned.
Usage charges apply to this endpoint for production API keys.
# Translate a segment
Source: https://support.lilt.com/api-reference/translate/translate-a-segment-1
/api-reference/openapi-bundled.yaml post /v2/translate
Translate a source string.
Setting the `rich` parameter to `true` will change the response format
to include additional information about each translation including a
model score, word alignments, and formatting information. The rich
format can be seen in the example response on this page.
By default, this endpoint also returns translation memory (TM) fuzzy matches, along
with associated scores. Fuzzy matches always appear ahead of machine translation
output in the response.
The maximum source length is 50,000 characters. When a `prefix` is supplied (prefix-based translation), the maximum source length is 5,000 characters.
Word-alignment and formatting fields (`targetWords`, `targetDelimiters`, and `provenance`) are returned only for prefix or `source_hash` requests. Plain (non-prefixed) translations return `target` and `targetWithTags` only. The source-side fields `tokenizedSource` and `sourceDelimiters` are no longer returned.
Usage charges apply to this endpoint for production API keys.
# Cancel Multipart Upload
Source: https://support.lilt.com/api-reference/uploads/cancel-multipart-upload
/api-reference/openapi-bundled.yaml delete /v2/upload/s3/multipart/{uploadId}
Cancel/abort a multipart upload and clean up any uploaded parts.
Example CURL command:
```
curl -X DELETE "https://lilt.com/v2/upload/s3/multipart/abc123def456?key=API_KEY&key=uploads/user123/file456.zip"
```
# Complete Multipart Upload
Source: https://support.lilt.com/api-reference/uploads/complete-multipart-upload
/api-reference/openapi-bundled.yaml post /v2/upload/s3/multipart/{uploadId}/complete
Complete a multipart upload by providing all uploaded parts information.
Example CURL command:
```
curl -X POST "https://lilt.com/v2/upload/s3/multipart/abc123def456/complete?key=API_KEY&key=uploads/user123/file456.zip" \
--header "Content-Type: application/json" \
--data-raw '{
"parts": [
{"ETag": "etag1", "PartNumber": 1},
{"ETag": "etag2", "PartNumber": 2}
]
}'
```
# Get All Pending Uploads or specific list of uploads by ids or statuses
Source: https://support.lilt.com/api-reference/uploads/get-all-pending-uploads-or-specific-list-of-uploads-by-ids-or-statuses
/api-reference/openapi-bundled.yaml get /v2/upload
Retrieve all pending uploads for the current user and organization.
Example CURL command:
```
curl -X GET https://lilt.com/2/upload?key=API_KEY
```
# Get S3 Upload Parameters
Source: https://support.lilt.com/api-reference/uploads/get-s3-upload-parameters
/api-reference/openapi-bundled.yaml get /v2/upload/s3/params
Get S3 upload parameters via query string. This endpoint provides the necessary information
to complete the file upload process using GET parameters.
Example CURL command:
```
curl -X GET "https://lilt.com/v2/upload/s3/params?key=API_KEY&filename=example.json&type=application/json&metadata.size=1024&metadata.labels=important,review-needed"
```
# Get Upload by ID
Source: https://support.lilt.com/api-reference/uploads/get-upload-by-id
/api-reference/openapi-bundled.yaml get /v2/upload/{uploadId}
Retrieve a specific upload by its unique identifier.
Example CURL command:
```
curl -X GET https://lilt.com/2/upload/12345?key=API_KEY
```
# Initiate File Upload to Cloud Storage
Source: https://support.lilt.com/api-reference/uploads/initiate-file-upload-to-cloud-storage
/api-reference/openapi-bundled.yaml post /v2/upload/s3/params
Initiate the upload of a file to cloud storage. This endpoint provides the necessary information
to complete the file upload process.
Supports both single file and bulk upload requests. For bulk uploads, pass an array of upload
objects (maximum 100 items). The response format matches the request format - a single object
for single file requests, or an array for bulk requests.
Example CURL command (single file):
```
curl -X POST https://lilt.com/v2/upload/s3/params?key=API_KEY \
--header "Content-Type: application/json" \
--data-raw '{
"filename": "example.json",
"type": "application/json",
"metadata": {
"size": 1024,
"labels": ["important", "review-needed"]
}
}'
```
Example CURL command (bulk upload):
```
curl -X POST https://lilt.com/v2/upload/s3/params?key=API_KEY \
--header "Content-Type: application/json" \
--data-raw '[
{
"filename": "file1.json",
"type": "application/json",
"metadata": { "size": 1024 }
},
{
"filename": "file2.txt",
"type": "text/plain",
"metadata": { "size": 2048 }
}
]'
```
# Initiate Multipart Upload
Source: https://support.lilt.com/api-reference/uploads/initiate-multipart-upload
/api-reference/openapi-bundled.yaml post /v2/upload/s3/multipart
Initiate a multipart upload for large files. This endpoint provides the necessary information
to start a multipart upload process.
Supports both single file and bulk upload requests. For bulk uploads, pass an array of upload
objects (maximum 100 items). The response format matches the request format - a single object
for single file requests, or an array for bulk requests.
Example CURL command (single file):
```
curl -X POST https://lilt.com/v2/upload/s3/multipart?key=API_KEY \
--header "Content-Type: application/json" \
--data-raw '{
"filename": "large-file.zip",
"type": "application/zip",
"metadata": {
"size": 104857600
}
}'
```
Example CURL command (bulk upload):
```
curl -X POST https://lilt.com/v2/upload/s3/multipart?key=API_KEY \
--header "Content-Type: application/json" \
--data-raw '[
{
"filename": "large-file1.zip",
"type": "application/zip",
"metadata": { "size": 104857600 }
},
{
"filename": "large-file2.zip",
"type": "application/zip",
"metadata": { "size": 209715200 }
}
]'
```
# Sign Upload Part
Source: https://support.lilt.com/api-reference/uploads/sign-upload-part
/api-reference/openapi-bundled.yaml get /v2/upload/s3/multipart/{uploadId}/{partNumber}
Get a signed URL for uploading a specific part of a multipart upload.
Make sure to set the part size to 8MB (8388608 bytes).
Example CURL command:
```
curl -X GET "https://lilt.com/v2/upload/s3/multipart/abc123def456/1?key=API_KEY&key=uploads/user123/file456.zip&size=5242880"
```
# Creates a new Webhook Configuration
Source: https://support.lilt.com/api-reference/webhook-configuration/creates-a-new-webhook-configuration
/api-reference/openapi-bundled.yaml post /v3/connectors/configuration/webhooks
Creates a new webhook configuration for your LILT organization.
# Delete a specific Webhook Configuration by ID.
Source: https://support.lilt.com/api-reference/webhook-configuration/delete-a-specific-webhook-configuration-by-id
/api-reference/openapi-bundled.yaml delete /v3/connectors/configuration/webhooks/{id}
# Retrieve a list of Webhook Configurations.
Source: https://support.lilt.com/api-reference/webhook-configuration/retrieve-a-list-of-webhook-configurations
/api-reference/openapi-bundled.yaml get /v3/connectors/configuration/webhooks
Retrieves a list of webhook configurations available to your LILT organization.
Use this to manage your webhook configurations.
# Retrieve a specific Webhook Configuration by ID.
Source: https://support.lilt.com/api-reference/webhook-configuration/retrieve-a-specific-webhook-configuration-by-id
/api-reference/openapi-bundled.yaml get /v3/connectors/configuration/webhooks/{id}
Retrieves a specific webhook configuration by its ID.
Deleted webhook configurations are not returned.
# Update a specific Webhook Configuration by ID.
Source: https://support.lilt.com/api-reference/webhook-configuration/update-a-specific-webhook-configuration-by-id
/api-reference/openapi-bundled.yaml put /v3/connectors/configuration/webhooks/{id}
Updates a specific webhook configuration by its ID.
Only the fields that are provided in the request body will be updated.
# Retrieve workflow templates
Source: https://support.lilt.com/api-reference/workflows/retrieve-workflow-templates
/api-reference/openapi-bundled.yaml get /v2/workflows/templates
Get all of the possible Workflow Templates owned by the team. Useful for retrieving the ids corresponding to each workflow tables, and passing them to subsequent requests, for example, creating a new Job with a specific Workflow.
Example CURL:
```bash curl -X GET 'https://api.lilt.com/v2/workflows/templates?key=API_KEY' ```
# Context Database
Source: https://support.lilt.com/context-database
# **What is the Context Database?**
The Context Database is your centralized data hub for all of your multilingual business context. It brings together Translation Memories (TM), Termbases (TB), Style Guides, Reference Materials, Jobs, Projects, and Segments into a single, highly searchable ecosystem.
Rather than treating these assets as disconnected files, the Context Database cross-references them in real-time. This creates a smart engine that works seamlessly in the background to ensure your translations are accurate, consistent, and perfectly aligned with your brand's voice.
# **How It Powers Your LILT Experience**
The Context Database isn't just a storage system; it actively powers the tools you use every day:
* **Smarter AI Translations:** When LILT AI generates a translation, it instantly pulls relevant data from the Context Database to ensure the output matches your historical preferences and terminology.
* **LILT Agent Assistance:** The database supplies the LILT Agent with the exact context it needs to assist you with tasks, answer questions, and provide recommendations.
# **Unified Search & Filtering**
Looking for a specific phrase from a project you completed last year? The Context Database features a powerful natural language search page built for fast, intuitive discovery.
**What you can search by:**
* File names, job/project names, or specific segment IDs
* Specific terms, phrases, or full sentences
* Subject matter or business use case
* Job-level metadata and custom properties
**How you can narrow results:** Faceted sidebar filters allow you to quickly refine results by data type (e.g., only search within Style Guides or Termbases), content format, language pair, domain, and date range.
# **What Data is Searchable?**
The Context Database indexes a wide variety of your multilingual business data so you can easily find it later. Each item includes rich metadata to give you a complete picture:
| **Data Type** | **Key Metadata** |
| :----------------------- | :------------------------------------------------------------------------------------ |
| **Job/Project** | Name, ID, status, assigned users, dates, source/target languages, word counts, domain |
| **Document** | Name, type, job, status, word counts (new & fuzzy) |
| **Segment** | Segment ID, source/target text, language pair, parent job/project/document |
| **Term base / Glossary** | Term, translation, language pair, dates |
| **Translation Memory** | Source/target segment, language pair, dates |
| **Reference Material** | File name, type, language, linked job |
| **Style Guide** | Domain, language/locale, dates |
# **How to Use the Context Database**
To get started, navigate to **Context Database** from the main navigation menu in LILT. From there, you can:
1. **Search across everything:** Enter any search term, segment ID, document name, or business topic into the universal search bar.
2. **Filter your results:** Use the sidebar controls to narrow your view by asset type, language pair, domain, or date range.
3. **Explore connected details:** Click on any search result to open the **Segment Context sidebar** to review related terms, author information, approval status, project notes, and linked resources.
4. **Take action on your data:** Select individual entries or group multiple results together to kick off a workflow. Use the action menu to send context directly to the LILT Agent, launch a new translation job, or organize assets with custom labels.
5. **Add and manage your assets:** Upload new resources directly to the database in standard translation formats (such as TMX, TBX, CSV, or Excel). Assign language pairs, domains, or tags, and track version history to view or restore earlier versions.
6. **Enjoy automatic context in your translations:** Once your assets are stored, no extra steps are required. LILT automatically feeds this context to both the Contextual AI and the LILT Agent during translation tasks.
**Note on Access:** Search results automatically respect your team's role and domain permissions, so you will only ever see and manage content you are authorized to access.
# **Intelligent Cross-Referencing & QA**
Because all your assets live in one connected ecosystem, the Context Database can do the heavy lifting to keep your content consistent:
* **Smart Terminology Updates:** If a historical Translation Memory (TM) match contains an outdated term, the system automatically cross-references it against your current Termbase to ensure the newest terminology is applied.
* **Continuous AI Learning:** Human linguist confirmations update your entire data ecosystem simultaneously, helping LILT's Contextual AI understand the relationships between your glossaries, TMs, and style guidelines.
* **Connected Context:** Rich details (like authorship, approval status, and project notes) tie your style guidelines to specific glossary terms and are surfaced automatically in the Segment Context sidebar while translating.
* **Automated QA:** Built-in quality assurance rules constantly scan the relationships between your data sets, automatically flagging contradictions (e.g., if a drafted translation conflicts with an approved glossary term).
# **Context Hierarchy: Which Rules Apply?**
To ensure the right terminology is used at the right time, the Context Database organizes information into a hierarchy. When giving instructions to the AI or LILT Agent, context is prioritized in this order:
1. Organization: High-level instructions that apply to your entire company.
2. Domain: Style guides and instructions specific to a certain department, subject, or brand.
3. User: Your personal project instructions, preferred terms, past jobs, and language settings.
# **Security & Permissions**
Your data remains secure. All search results and database views strictly respect role-based and domain-based access controls, meaning users will only ever see the data and assets they are authorized to view.
# Connect Systems To Workflows
Source: https://support.lilt.com/developers/guides/connect-systems-to-workflows
The LILT Connectors framework simplifies the process of integrating external applications and services with the LILT platform. It provides a standardized approach for building connectors, reducing development time and effort. These connectors act as bridges, allowing data to flow seamlessly between LILT and other tools. This not only streamlines workflows but also expands LILT's capabilities by enabling it to leverage functionalities offered by external systems. With the LILT Connectors framework, users can benefit from a wider range of features and data sources, ultimately enhancing the efficiency and effectiveness of their localization processes.
The Connectors that LILT supports grows over time, a current list can be found [here](https://lilt.com/connectors).
If you want an in-depth guide for how the connectors integrate with a specific partner, check out our [knowledge base](/kb/connectors).
# Create Content
Source: https://support.lilt.com/developers/guides/create-new-content
LILT Create offers an alternative to normal translation, by allowing you to generate content in the target language using various prompts to get your message across more organically in the new language. This can make your content easier to understand for users of that language and can empower a global audience. This guide will demonstrate how to:
* [Generate Content](#generate-content)
* [Retrieve Generated Content](#get-generated-content)
* [Update or Delete Content](#update-or-delete-content)
Things you will need:
* API Key - All requests throughout the LILT API use the API Key to authenticate.
## Generate Content
There are a few things to consider before Generating Content:
1. What do I want to generate? This can be as simple as "Write a story about bees" or "Write a paragraph about product X". As long as your prompt is below the character limit of 500.
2. How do I want to group the content to be generated? Writing an article that is split into multiple sections with different headings, add sections to structure the generated content.
3. Do I want to use Terminology specific to my organization? Add a `memoryId` to the request. [See the API docs for more info](/api-reference/create/generate-new-lilt-create-content).
Below is an example request to generate content in English.
```bash theme={null}
curl -X POST 'https://api.lilt.com/v2/create?key=API_KEY' \
--header 'Content-Type: application/json' \
--data-raw '{
"language":"en-US",
"template":"blog-post",
"templateParams":{
"contentLength":"1000",
"language":"en-US",
"sections":["Bees and me","Honey for you", "Conclusion"],
"summary":"a blog post about how important bees are to my honey farm"
},
"preferences":{"tone":"formal","styleguide":""}
}'
```
The response is an event stream of the generated content. You can choose to read the stream, or you can choose to wait until a DONE message is emitted. Try it out with something that makes sense for your organization or a different language you are proficient with.
## Get Generated Content
As you Create more it might become necessary to get content you already generated previously. You can get a complete list of everything you have created previously using this [endpoint](/api-reference/create/get-lilt-create-content):
```powershell theme={null}
curl -X GET 'https://api.lilt.com/v2/create?key=API_KEY'
```
You can also retrieve a single piece of content by its ID using the [Get Lilt Create content by ID endpoint](/api-reference/create/get-lilt-create-content-by-id):
```powershell theme={null}
curl -X GET 'https://api.lilt.com/v2/create/1234?key=API_KEY'
```
## Update or Delete Content
Existing Lilt Create content can be updated (for example, to change the language) or deleted using the content's ID.
```bash theme={null}
curl -X PUT 'https://api.lilt.com/v2/create/1234?key=API_KEY' \
--header 'Content-Type: application/json' \
--data-raw '{"language":"de-DE"}'
```
```bash theme={null}
curl -X DELETE 'https://api.lilt.com/v2/create/1234?key=API_KEY'
```
See the [API Specification](/api-reference/create/get-lilt-create-content-by-id) for the full request and response shapes for these endpoints.
# Create A Data Source
Source: https://support.lilt.com/developers/guides/manage-content/create-a-datasource
What is a Data Source? A Data Source is an object that links all of your translated content together for a given language. It allows the LILT system to reference all of your previous translations, TMX files and Termbases(TB) to provide you with the most accurate translation possible.
Things you will need:
* API Key - All requests through the LILT API use the API Key to authenticate.
* (Optional) TMX File - TMX files contain sentence to sentence translations and serve as a basis for translating content, these files aren't necessary but can produce better Instant Translate results for your documents depending on the quality of the data provided.
* (Optional) TB File - Your business likely has specific product names, advertising terminology, and other words that you may or may not want translated. Adding a TB (Termbase) file to the Data Source creates a managed way to translate certain words/phrases for your business.
**Note:**
Data Sources can also be referred to as Memories. Anywhere in the docs that mentions a `memoryId` or `/memories` endpoint is referring to a Data Source.
## Create a Data Source
Creating a Data Source with LILT is a straight-forward process. For this example we will create a Data Source in English to German using Locales. If you want to try a different language, a list of supported languages and how to access them is available in the [Quick Start Guide](/developers/quickstart). Here is an example API call to create a Data Source plus the Request body. [See the API docs for more info](/api-reference/memories/create-a-memory)
```bash theme={null}
curl -X POST https://api.lilt.com/v2/memories?key=API_KEY \
--header "Content-Type: application/json" \
--data '{"name": "Test Data Source","srclang": "en","trglang": "de","srclocale": "US","trglocale": "DE"}'
```
Once the call is made you should expect to see a response that looks something like this:
```json theme={null}
{
"id": 1234,
"srclang": "en",
"trglang": "de",
"srclocale": "US",
"trglocale": "DE",
"name": "Test Data Source",
"is_processing": false,
"version": 78,
"created_at": 1489147692,
"updated_at": 1489147692,
"resources": ["string"]
}
```
Congratulations, you have successfully created a Data Source.
## Add a TMX file/TB file to your Data Source
A Data Source is only as useful as the data stored within. LILT uses memories as a way to keep track of your organizations content in a language pair format. Adding data to an empty Data Source is a typical first step when onboarding to LILT. If your organization has done localization in the past, chances are that you have a tmx file/tb file that needs to be added to your Data Source to ensure that your historical data is taken into consideration by the LILT Transformative AI. For this example we will upload a tmx file called "test.tmx" using the [import file endpoint](/api-reference/memories/file-import-for-a-memory)
```bash theme={null}
curl -X POST https://api.lilt.com/v2/memories/import?key=API_KEY \
--header "LILT-API: {\"name\": \"test.tmx\",\"memory_id\": 1234}" \
--header "Content-Type: application/octet-stream" \
--data-binary @test.tmx
```
This should elicit a 200 response that looks something like this:
```json theme={null}
{
"id": 123,
"isProcessing": 1
}
```
This response means is that the request was registered successfully and your file is being processed by LILT into Segments which will become part of the Data Source. This process is asynchronous and can be verified using the [memories endpoint](/api-reference/memories/retrieve-a-memory):
```bash theme={null}
curl -X GET https://api.lilt.com/v2/memories?key=API_KEY&id=1234\
```
This request will give you a response similar to the creation logic, with the key difference of seeing the new resource in the resources list.
```json theme={null}
{
"id": 1234,
"srclang": "en",
"trglang": "de",
"srclocale": "US",
"trglocale": "DE",
"name": "Test Data Source",
"is_processing": false,
"version": 78,
"created_at": 1489147692,
"updated_at": 1489147692,
"resources": ["test.tmx"]
}
```
# Data Source Management
Source: https://support.lilt.com/developers/guides/manage-content/tm-query
In the normal course of translation and localization, there will be times where you need to verify the existence of a specific sentence/word/phrase in your Data Source. Whether that is because the target language has changed how it uses the word in the course of a languages evolution or if you simply want to verify that the Term your organization uses to describe a specific product is correct, this guide will show you how to look things up in a LILT Data Source without having to pull down the whole file.
In this guide you will learn how to:
* [Query a Data Source](#get-generated-content)
Things you will need:
* API Key - All requests through the LILT API use the API Key to authenticate.
## Query a Data Source
Querying a Data Source in LILT uses a string lookup to pull specific segments that fit the source provided. In this example the string we will use is "LILT Create". Please note that the n in the query is a limit on the number of segments to pull. [See the API docs for more info](/api-reference/memories/query-a-memory)
```bash theme={null}
curl -X GET https://api.lilt.com/v2/memories/query?key=API_KEY&id=MEMORY_ID&query="LILT Create is a Generative AI tool."&n=100
```
With that we would expect to see a response containing no more than 100 segments that fit the query criteria.
```json theme={null}
[
{
"source": "LILT Create is a Generative AI tool.",
"target": "LILT Create ist ein generatives KI-Tool.",
"score": 100,
"metadata": "object"
}
]
```
In this case, there was a single segment that fit the criteria with a score of 100. The score determines how close the system believes the query provided is close to what you are looking for. Anything less than 75 is automatically discarded.
## Note
The query is a useful tool for verifying small things and ensuring certain phrases are in the right place. Feel free to explore the other Data Source End points in the [API Specification](/api-reference/memories).
# API Rate Limits
Source: https://support.lilt.com/developers/guides/rate-limits
**Recent product change: API rate limits effective June 30, 2026**
LILT is committed to delivering fast, reliable translation performance to every organization on our platform. To protect that shared experience and make sure no single workload can degrade service for others, **we've adding per-organization rate limits to our document pretranslation and file-translation APIs, beginning June 30, 2026**. These endpoints aren't changing; we've simply introduced fair-use limits so capacity stays balanced across all our customers.
*Please note: All LILT Connectors are out of scope for these rate limits. These will only apply to the API.*
***
# Overview
Starting June 30, 2026, LILT is introducing per-organization rate limits on the following endpoints:
* `POST /v2/documents/pretranslate`
* `POST /v2/translate/file`
* `POST /v2/documents/files` (only when the upload invokes MT - see exclusion note below)
* `POST /2/jobs `(only request rate and not character throughput)
Two independent limits apply to every organization:
| **Limit** | **Threshold** |
| :------------------- | :------------------------------ |
| Request rate | 300 requests per minute |
| Character throughput | 2,500,000 characters per minute |
Requests that exceed either limit receive an **HTTP 429 Too Many Requests** response. This guide explains how to read the 429 response headers and restructure your integration to stay comfortably within these thresholds.
### File uploads without Machine Translation (MT) are excluded
`POST /v2/documents/files` uploads a file - it does not, by itself, run machine translation (MT). Uploads that don't invoke MT are not counted against the character-throughput limit: LILT evaluates each request's translation cost and a non-MT upload is measured as zero characters, so it draws down neither your throughput budget. Only calls that actually consume MT (`POST /v2/documents/pretranslate` and `POST /v2/translate/file`, plus a `/v2/documents/files` upload that triggers pretranslation) count toward the 2,500,000-characters-per-minute limit. You can upload source files freely; batch and pace the translation calls that follow.
# Understanding the 429 Response
When a request is rate-limited, LILT returns a 429 with three headers that tell you exactly when you can safely retry:
| **Header** | **Meaning** |
| :---------------------- | :----------------------------------------------------------------------------------- |
| `X-RateLimit-Limit` | Your per-minute allowance (requests or characters, depending on which limit was hit) |
| `X-RateLimit-Remaining` | Requests or characters still available in the current one-minute window |
| `X-RateLimit-Reset` | Seconds until the current window resets and your full quota is restored |
The two limits are **independent**. You can hit the character throughput ceiling without exhausting your request count, or vice versa. Check both headers when handling a 429.
## Example 429 response
```http theme={null}
HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 300
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 38
{
"error": "rate_limit_exceeded",
"message": "Request rate limit reached. Retry after 38 seconds."
}
```
# Handling a 429: Retry with Back-Off
The simplest fix for an occasional 429 is to wait for the window to reset before retrying. Do not tight-loop or immediately re-send. This wastes quota and keeps triggering 429s.
## Recommended retry pattern
On receiving a 429:
1. Read the `X-RateLimit-Reset` value from the response headers.
2. Sleep for that many seconds (plus a small jitter to avoid synchronized retries across parallel workers).
3. Re-send the original request.
## Python example
```python theme={null}
import time, random, requests
def pretranslate(payload, headers):
url = "https://api.lilt.com/v2/documents/pretranslate"
for attempt in range(5):
resp = requests.post(url, json=payload, headers=headers)
if resp.status_code == 429:
reset_in = int(resp.headers.get("X-RateLimit-Reset", 60))
jitter = random.uniform(0.5, 2.0)
wait = reset_in + jitter
print(f"Rate limited. Retrying in {wait:.1f}s (attempt {attempt+1}/5)")
time.sleep(wait)
continue
resp.raise_for_status()
return resp.json()
raise RuntimeError("Exceeded retry limit")
```
## Node.js example
```js theme={null}
async function pretranslate(payload, headers) {
const url = "https://api.lilt.com/v2/documents/pretranslate";
for (let attempt = 0; attempt < 5; attempt++) {
const res = await fetch(url, {
method: "POST",
headers: { ...headers, 'Content-Type': 'application/json' },
body: JSON.stringify(payload),
});
if (res.status === 429) {
const resetIn = parseInt(res.headers.get("X-RateLimit-Reset") ?? "60", 10);
const jitter = Math.random() * 1.5 + 0.5;
const wait = (resetIn + jitter) * 1000;
console.log(`Rate limited. Retrying in ${(wait/1000).toFixed(1)}s`);
await new Promise(r => setTimeout(r, wait));
continue;
}
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json();
}
throw new Error("Exceeded retry limit");
}
```
# Batching Requests
If your integration sends many small, individual translation calls in rapid succession, **batching** (combining multiple documents or files into fewer API calls) is the most effective way to stay well under the rate limits.
## What to batch
| **Endpoint** | **Batching approach** |
| :-------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `POST /v2/documents/pretranslate` | Pass an array of document IDs in a single request body |
| `POST /v2/translate/file` | Batch by referencing multiple already-uploaded files in a single call. Pass their IDs via the fileId query parameter (e.g. ?fileId=1,2,3 or repeated ?fileId=1\&fileId=2). This does not accept multiple source files in the multipart body; the files must already exist (uploaded via the file-upload endpoint first). |
**Character throughput tip**
Batching reduces your request count, but each batch's characters still count toward the 2,500,000 character-per-minute throughput limit. If you're working with very large documents, spread batches across multiple windows rather than sending all characters at once.
## Sizing your batches
There is no fixed rule for batch size — it depends on your document sizes and submission cadence. Use these guidelines as a starting point:
* Keep each batch well under 2,500,000 characters to leave headroom for concurrent jobs from other parts of your organization.
* If you are consistently close to the `X-RateLimit-Remaining` ceiling, reduce batch frequency or split large batches into smaller ones with a brief pause between them.
* For burst workloads (e.g., end-of-sprint file exports), schedule submissions in staggered windows rather than all at once.
## Pretranslation: batching document IDs
The `POST /v2/documents/pretranslate` endpoint accepts an array of document IDs. Instead of issuing one request per document, collect IDs and submit them together:
```python theme={null}
# ✗ One request per document (inefficient)
for doc_id in document_ids:
requests.post('/v2/documents/pretranslate', json={'id': [doc_id]}, headers=headers)
# ✓ All documents in a single request (efficient)
requests.post(
'/v2/documents/pretranslate',
json={'id': document_ids}, # e.g. [1001, 1002, 1003, ...]
headers=headers,
)
```
If you have hundreds of documents to pretranslate, split them into chunks and submit one chunk per window:
```python theme={null}
import time, math, requests
CHUNK_SIZE = 50 # documents per request
WINDOW_SEC = 62 # slightly more than 60 s to be safe
def batch_pretranslate(doc_ids, headers):
chunks = [doc_ids[i:i+CHUNK_SIZE] for i in range(0, len(doc_ids), CHUNK_SIZE)]
for i, chunk in enumerate(chunks):
print(f'Submitting chunk {i+1}/{len(chunks)} ({len(chunk)} docs)')
pretranslate({'id': chunk}, headers) # uses retry helper above
if i < len(chunks) - 1:
time.sleep(WINDOW_SEC)
```
## File translation: Uploading and batching by reference
The `POST /v2/documents/files` accepts one file per request. Additional files in a multipart body are silently ignored.
To translate many files, upload each one individually, then batch the downstream operation by passing the resulting IDs in a single call (e.g. an array of document IDs to `POST /v2/documents/pretranslate`, or multiple field query params to `POST /v2/translate/file`.)
```python theme={null}
▎ import requests
▎
▎ def upload_files(file_paths, headers):
▎ """Upload files one at a time; return the list of created file IDs."""
▎ file_ids = []
▎ for path in file_paths:
▎ with open(path, 'rb') as fh:
▎ files = {'file': (path.split('/')[-1], fh, 'application/octet-stream')}
▎ resp = requests.post(
▎ 'https://api.lilt.com/v2/documents/files',
▎ files=files,
▎ headers=headers,
▎ )
▎ resp.raise_for_status()
▎ file_ids.append(resp.json()['id']) # adjust to actual response field
▎ return file_ids
▎
▎ def translate_files(file_ids, headers):
▎ """Batch-translate already-uploaded files in a single request by reference."""
▎ resp = requests.post(
▎ 'https://api.lilt.com/v2/translate/file',
▎ params={'fileId': ','.join(str(i) for i in file_ids)},
▎ headers=headers,
▎ )
▎ resp.raise_for_status()
▎ return resp.json()
```
# Proactive Throttling
Rather than reacting to 429s, you can read `X-RateLimit-Remaining` and `X-RateLimit-Reset` on every successful response and slow down before you hit the ceiling.
```python theme={null}
def check_and_throttle(response, low_watermark=20):
"""Pause proactively when remaining quota is low."""
remaining = int(response.headers.get("X-RateLimit-Remaining", 999))
reset_in = int(response.headers.get("X-RateLimit-Reset", 0))
if remaining <= low_watermark and reset_in > 0:
print(f'Quota low ({remaining} left). Pausing {reset_in}s.')
time.sleep(reset_in + 1)
```
# Pre-Launch Checklist
Before June 30, verify that your integration:
* Sends arrays of document IDs to `/v2/documents/pretranslate` rather than one ID at a time and arrays of file IDs to `/v2/files/translation`.
* Groups related files into a single `multipart/form-data` request where possible.
* Handles HTTP 429 by sleeping for `X-RateLimit-Reset` seconds (plus jitter) before retrying.
* Does not tight-loop on 429 responses.
* Monitors `X-RateLimit-Remaining` and throttles proactively when quota is low.
* Schedules large burst workloads across multiple one-minute windows.
# Need More Headroom?
The default thresholds are designed to sit well above typical usage patterns. If your workload genuinely requires higher limits, reply to the rate-limits notification email and the LILT team will work with you to find a configuration that fits your needs without impacting the shared platform.
**Contact support**
Reach out via your rate-limits notification email, or contact LILT support at [support.lilt.com](https://support.lilt.com). Please include your organization ID and a brief description of your workload volume when you get in touch.
# AI Translation
Source: https://support.lilt.com/developers/guides/translate-content/instant-translate
In this walkthrough we will demonstrate how to use the LILT API AI Translation functionality. Instant translate is a powerful way to use LILT's Transformative AI to translate your content quickly and accurately without having to wait for a human to verify the results.
Things you will need:
* API Key - All requests through the LILT API use the API Key to authenticate.
* File to Translate - We recommend a simple text file (txt) for a first attempt.
* Memory ID - A LILT Data Source's memoryId to use with the translation - [Create one here!](/developers/guides/manage-content/create-a-datasource)
## File Upload
Please refer to the [File Upload](/developers/guides/upload/file-upload) documentation to get a File ID.
## Translate File
Now that you have a file saved in LILT, let's translate it! To run an AI translation for a single file you will need to use the [translate file endpoint](/api-reference/translate/translate-a-file). The end point below will translate your file, using the provided memoryId, fileId. File Translation is an Asynchronous process.
*Note: If you don't add "withTM" as a parameter, the default setting is TRUE and the instant translation will leverage your TM.*
```powershell theme={null}
curl -X POST 'https://api.lilt.com/v2/translate/file?key=API_KEY&fileId=123&memoryId=1234'
```
The response will be a status object that looks like this:
```json theme={null}
{
"id": 1,
"fileId": "2,",
"status": "InProgress",
"createdAt": 1609357135
}
```
## Monitor Translation
Now that you have the translation id, you can call the [monitor endpoint](/api-reference/translate/monitor-file-translation) to get the current status of your translations. You can ask for status for any number of translations at a time, we recommend bundling these translationIds together.
```powershell theme={null}
curl -X GET 'https://api.lilt.com/v2/translate/file?key=API_KEY&translationIds=1,2,3,4'
```
The response to the Monitor end point will look the same as the POST call you made earlier. The status might be different. Here are the statuses you can expect to see:
* `InProgress` - The Translation has begun!
* `Completed` - Translation is Complete but not yet ready for download.
* `Failed` - The Translation was unsuccessful. 🙃
* `ReadyForDownload` - The Translation was Complete and is available for retrieval.
## Download Translated File
Once you have the green light to download the translated file you can call the [download endpoint](/api-reference/translate/download-translated-file). This endpoint only allows for downloading one file at a time.
```powershell theme={null}
curl -X GET 'https://api.lilt.com/v2/translate/files?key=API_KEY&id=1'
```
The response to this end point will be your content translated into whatever language you picked for the Data Source!
## Notes
The end points described above have additional features, but we don't recommend them for most users. If you are curious, feel free to take a look at the [API Specification](/api-reference).
# Verified Translation
Source: https://support.lilt.com/developers/guides/translate-content/verified-translation
Verified Translation has a human in the loop to ensure the highest translation quality. That means immediate turn around times will not be possible unlike with [Instant Translate](/developers/guides/translate-content/instant-translate).
In this section we will discuss:
* [Uploading Files](#uploading-files)
* [Creating a Job](#creating-a-job)
* [Monitoring Job Status](#monitoring-the-job-status)
* [Downloading Translated Jobs](#downloading-translated-jobs)
* [Archiving Downloaded Jobs](#archiving-downloaded-jobs)
Things you will need:
* API Key - All requests through the LILT API use the API Key to authenticate.
* File to Translate - We recommend a simple text file (txt) for a first attempt.
* Memory ID - A LILT Data Source's `memoryId` to use with the translation - [Create one here!](/developers/guides/manage-content/create-a-datasource)
## Submitting a New LILT Job
A LILT Job encapsulates the various files that you want to translate. A Job is usually made up of multiple Projects. A Project is a grouping of Documents to be translated for an individual language pair (en->de - English to German). The LILT app has a useful wizard for creating Jobs that breaks all of these concepts down into a single package.
In the next section you will learn how to create your first LILT Job. If you are curious about how these objects fit together, feel free to check out the API Reference:
* [Jobs](/api-reference/jobs)
* [Projects](/api-reference/projects)
* [Documents](/api-reference/documents)
* [Files](/api-reference/files)
* [Languages](/api-reference/languages)
## Uploading Files
The first step is to upload some files. For this example, a text (txt) file will be used as it is one of the simplest file types supported for verified translation. [See the API docs for more file upload options](/api-reference/files/upload-a-file).
```java theme={null}
curl -X POST https://api.lilt.com/v2/files?key=API_KEY&name=testfile.txt \
--header "Content-Type: application/octet-stream" \
--data-binary @testfile.txt
```
The response will have an ID that relates to the File:
```javascript theme={null}
{
"id": {Your File Id here},
"name": "testfile.txt",
"file_hash": "3858f62230ac3c915f300c664312c63f",
"detected_lang": "en",
"detected_lang_confidence": 0.7,
"category": "API",
"labels": [],
"created_at": "2024-02-16T22:12:34.000Z",
"updated_at": "2024-02-16T22:12:34.000Z"
}
```
Hold onto the file IDs as you will need them in Step 2. If you lose them, you can always query the [Files API](/api#tag/Files/operation/getFiles) to see a list of your files.
**Tip**
Upload all of the files first before creating a Job with them.
## Creating a Job
To create a Job you need at least one Data Source for the language you want to translate into. We will use the corresponding `memoryId` and the target language from that memory to specify a Language Pair, which can then be linked to the relevant Job.
### Basic Job Creation
For now, let's create a Job for a single File and a single Language Pair. The request to create a Job will look like this. [See the API docs for more info](/api-reference/jobs/retrieve-all-jobs).
```bash theme={null}
curl -X POST 'https://api.lilt.com/v2/jobs?key=API_KEY' \
--header 'Content-Type: application/json' \
--data-raw '{
"name": "test job",
"fileIds": [1234],
"due": "2024-02-05T10:56:44.985Z",
"srcLang": "en",
"srcLocale": "US",
"languagePairs": [
{ "memoryId": 3121, "trgLang": "de" }
]
}'
```
### Advanced Job Creation with Unified Fields
You can also include additional fields to provide more context and metadata:
```swift theme={null}
curl -X POST 'https://api.lilt.com/v2/jobs?key=API_KEY' \
--header 'Content-Type: application/json' \
--data-raw '{
"name": "Marketing Campaign Q1",
"fileIds": [1234, 1235],
"due": "2024-02-05T10:56:44.985Z",
"srcLang": "en",
"srcLocale": "US",
"jobInstructions": "This is a marketing campaign for Q1. Please maintain brand voice and use approved terminology from the style guide.",
"customProperties": {
"purchaseOrder": "PO-2024-Q1-001",
"department": "Marketing",
"campaign": "Q1-Launch",
"priority": "high"
},
"enablePostProcessing": true,
"languagePairs": [
{
"memoryId": 3121,
"trgLang": "de",
"instructions": "Use formal German (Sie form) for B2B audience"
},
{
"memoryId": 3122,
"trgLang": "fr",
"instructions": "Use informal French (tu form) for consumer audience"
}
]
}'
```
**Field Descriptions:**
* **`jobInstructions`** (optional): General instructions that apply to all projects in the job. Visible to all translators and reviewers. Max 5000 characters.
* **`customProperties`** (optional): Key-value pairs for custom metadata. Useful for tracking purchase orders, departments, or other organizational data.
* **`enablePostProcessing`** (optional): Boolean flag to enable additional post-processing steps after translation.
* **`languagePairs[].instructions`** (optional): Language-specific instructions for each target language. Max 200 characters per language pair.
That is all it takes to create a Verified Translation Job in LILT with full context and metadata.
The Job has now been created and the LILT team will handle processing the verified translations. The Job will be marked as Delivered in LILT to indicate that the translations are ready for download.
## Monitoring the Job Status
To determine which translations are ready for download query for jobs where `isDelivered=true` and `isArchived=false`.
```bash theme={null}
curl -X GET https://api.lilt.com/v2/jobs?key=API_KEY&isDelivered=true&isArchived=false
```
[See the API Docs for more info](/api-reference/jobs/retrieve-all-jobs).
## Downloading Translated Jobs
To download the completed translations, first initiate an export of the Job using the [export endpoint](/api-reference/jobs/export-a-job). This will set the `isProcessing` value to `1`.
```powershell theme={null}
curl -X GET 'https://api.lilt.com/v2/jobs/{id}/export?key=API_KEY&type=files'
```
Check the status of the export by calling the [get job by ID endpoint](/api-reference/jobs/retrieve-a-job). When the export is complete, the `isProcessing` value will be set to `0` (or `-2` in the case of an export error).
```powershell theme={null}
curl -X GET 'https://api.lilt.com/v2/jobs/{id}?key=API_KEY'
```
Once the export is complete the translations can be downloaded. The [download endpoint](/api-reference/jobs/download-a-job) will return a zip file containing all of the translations.
```powershell theme={null}
curl -X GET 'https://api.lilt.com/v2/jobs/{id}/download?key=API_KEY'
```
## Archiving Downloaded Jobs
Call the [archive endpoint](/api-reference/jobs/archive-a-job) after successful download of the translations to indicate that the translations have been received.
```powershell theme={null}
curl -X POST 'https://api.lilt.com/v2/jobs/{id}/archive?key=API_KEY'
```
That concludes this end-to-end guide for completing Verified Translation Jobs using the LILT API.
# Cloud Upload API Documentation
Source: https://support.lilt.com/developers/guides/upload/file-upload
## Overview
The LILT Cloud Upload API provides secure file upload capabilities using S3-compatible presigned URLs. This system supports both single file uploads and multipart uploads for large files, enabling efficient and secure file transfers directly to cloud storage.
## Key Features
* **Direct S3 Uploads**: Files are uploaded directly to S3-compatible storage, reducing server load
* **Presigned URL Security**: Time-limited, secure URLs with no exposed credentials
* **Multipart Upload Support**: Efficient handling of large files through chunked uploads
* **Flexible Client Support**: Use any HTTP client library in your preferred programming language
* **Managed Infrastructure**: LILT handles all bucket configuration, CORS setup, and storage management
## How It Works
The upload process uses AWS S3-compatible presigned URLs for secure file transfers:
1. **Request Upload Parameters**: Call the Lilt API to get presigned URL and upload parameters
2. **Upload Directly to Storage**: Use the presigned URL to upload files directly to S3-compatible storage
3. **Complete Upload**:
* For multipart uploads, notify the API when all parts are uploaded
* Poll for antivirus scan completion to get the File ID which you can use for other endpoints (add to jobs or projects)
## API Endpoints
### 1. Initiate Single File Upload
**Endpoint:** `POST /v2/upload/s3/params` or `GET /v2/upload/s3/params`
Initiates a single file upload and returns presigned URL for direct upload to storage.
#### Request Body
```json theme={null}
{
"filename": "document.pdf",
"type": "application/pdf",
"metadata": {
"size": 1048576,
"category": "SOURCE",
"uuid": "123e4567-e89b-12d3-a456-426614174000"
}
}
```
#### Parameters
| Field | Type | Required | Description |
| ------------------- | ------- | -------- | ----------------------------------- |
| `filename` | string | Yes | File name including extension |
| `type` | string | Yes | MIME type of the file |
| `metadata.size` | integer | No | File size in bytes |
| `metadata.category` | string | No | File category (SOURCE or REFERENCE) |
| `metadata.uuid` | string | No | Unique identifier for the file |
#### Response
```json theme={null}
{
"url": "https://storage.example.com/bucket/path/file.pdf?AWSAccessKeyId=...",
"method": "PUT",
"filename": "text2.txt",
"contentType": "text/plain",
"metadata": {
"size": 1048576,
"category": "SOURCE",
"uuid": "123e4567-e89b-12d3-a456-426614174000"
},
"upload": {
"createdAt": "2025-07-08T11:11:27.674Z",
"updatedAt": "2025-07-08T11:11:27.674Z",
"isDeleted": false,
"deletedAt": null,
"id": 362,
"UserId": 10727,
"OrganizationId": 682,
"fileLocation": "gs://.../text2.txt",
"status": "UPLOADING",
"totalBytes": 333,
"uploadedBytes": 0,
"category": "SOURCE"
}
}
```
### 2. Initiate Multipart Upload
**Endpoint:** `POST /v2/upload/s3/multipart`
Initiates a multipart upload for large files (recommended for files > 100MB).
Make sure your part size is set to 8MB (8388608 bytes).
#### Request Body
```json theme={null}
{
"filename": "large-file.zip",
"type": "application/zip",
"metadata": {
"size": 104857600,
"category": "SOURCE"
}
}
```
#### Response
```json theme={null}
{
"uploadId": "abc123def456",
"key": "uploads/user123/large-file.zip",
"upload": {
"createdAt": "2025-07-08T11:11:27.674Z",
"updatedAt": "2025-07-08T11:11:27.674Z",
"isDeleted": false,
"deletedAt": null,
"id": 362,
"UserId": 10727,
"OrganizationId": 682,
"fileLocation": "gs://.../text2.txt",
"status": "UPLOADING",
"totalBytes": 333,
"uploadedBytes": 0,
"category": "SOURCE"
}
}
```
The following parameters are optional and only relevant when uploading video content for translation:
* `extractText`: When uploading a video file, set this parameter to `True` to ensure that text is extracted from the video (if needed).
* `isSourceReviewRequired`: When uploading a video file, set this parameter to `True`to indicate that the source content should be reviewed before translation begins.
### 3. Get Upload Part URL
**Endpoint:** `GET /v2/upload/s3/multipart/{uploadId}/{partNumber}`
Retrieves a presigned URL for uploading a specific part of a multipart upload.
#### Parameters
| Parameter | Type | Required | Description |
| ------------ | ------- | -------- | ------------------------------------------ |
| `uploadId` | string | Yes | Multipart upload ID from initiate response |
| `partNumber` | integer | Yes | Part number (1-based, 1-10000) |
| `s3Key` | string | Yes | Upload key from initiate response |
| `size` | integer | Yes | Size of the file |
#### Example Request
```bash theme={null}
GET /v2/upload/s3/multipart/abc123def456/1?s3Key=uploads/user123/large-file.zip&size=104857600
```
#### Response
```json theme={null}
{
"url": "https://storage.example.com/bucket/path/file.zip?partNumber=1&uploadId=...",
"method": "PUT"
}
```
### 4. Complete Multipart Upload
**Endpoint:** `POST /v2/upload/s3/multipart/{uploadId}/complete`
Completes a multipart upload by providing information about all uploaded parts.
#### Parameters
| Parameter | Type | Required | Description |
| ---------- | ------ | -------- | --------------------------------- |
| `uploadId` | string | Yes | Multipart upload ID |
| `s3Key` | string | Yes | Upload key from initiate response |
#### Request Body
```json theme={null}
{
"parts": [
{
"ETag": "\"abc123def456\"",
"PartNumber": 1
},
{
"ETag": "\"def789ghi012\"",
"PartNumber": 2
}
]
}
```
#### Response
```json theme={null}
{
"success": true,
"location": "https://storage.example.com/bucket/uploads/user123/large-file.zip"
}
```
### 5. Cancel Multipart Upload
**Endpoint:** `DELETE /v2/upload/s3/multipart/{uploadId}`
Cancels a multipart upload and cleans up any uploaded parts.
#### Parameters
| Parameter | Type | Required | Description |
| ---------- | ------ | -------- | --------------------------------- |
| `uploadId` | string | Yes | Multipart upload ID to cancel |
| `s3Key` | string | Yes | Upload key from initiate response |
#### Response
```json theme={null}
{
"success": true,
"message": "Multipart upload cancelled successfully"
}
```
## Upload Workflows
### Simple Upload Flow
```text theme={null}
1. POST /v2/upload/s3/params → Get presigned URL and upload object
2. PUT to presigned URL → Upload file directly to S3
3. Poll GET /v2/upload/:uploadId for AV scan completion
4. File is ready for use when upload.status=SUCCESS and upload.FileId is a number
```
### Multipart Upload Flow
```text theme={null}
1. POST /v2/upload/s3/multipart → Get upload ID and key
2. For each part:
- GET /v2/upload/s3/multipart/{uploadId}/{partNumber} → Get part URL
- PUT to part URL → Upload part to S3
- Save ETag from response
3. POST /v2/upload/s3/multipart/{uploadId}/complete → Complete upload
4. Poll GET /v2/upload/:uploadId for AV scan completion
5. File is ready for use when upload.status=SUCCESS and upload.FileId is a number
```
## Implementation Examples
### Node.js Example
```javascript theme={null}
const axios = require("axios");
const fs = require("fs");
// Initialize axios with base URL
const api = axios.create({
baseURL: "https://api.lilt.com/v2",
headers: {
Authorization: "Bearer YOUR_API_KEY"
}
});
// Single file upload
async function uploadFile(filePath, filename, contentType) {
const fileBuffer = fs.readFileSync(filePath);
// 1. Initiate upload
const { data: uploadParams } = await api.post("/upload/s3/params", {
filename,
type: contentType,
metadata: {
size: fileBuffer.length
}
});
// 2. Upload to S3 using presigned URL
await axios.put(uploadParams.url, fileBuffer, {
headers: {
"Content-Type": contentType,
...uploadParams.headers
}
});
console.log("Upload successful");
}
// Multipart upload for large files
async function uploadLargeFile(filePath, filename, contentType) {
const fileBuffer = fs.readFileSync(filePath);
const chunkSize = 8 * 1024 * 1024; // 8MB chunks
// 1. Initiate multipart upload
const { data: initResponse } = await api.post("/upload/s3/multipart", {
filename,
type: contentType,
metadata: {
size: fileBuffer.length
}
});
const { uploadId, key } = initResponse;
const parts = [];
// 2. Upload each part
for (let i = 0; i < fileBuffer.length; i += chunkSize) {
const partNumber = Math.floor(i / chunkSize) + 1;
const chunk = fileBuffer.slice(i, i + chunkSize);
// Get presigned URL for this part
const { data: partParams } = await api.get(
`/upload/s3/multipart/${uploadId}/${partNumber}`,
{
params: {
s3Key: key,
size: chunk.length
}
}
);
// Upload part
const response = await axios.put(partParams.url, chunk, {
headers: {
"Content-Type": contentType
}
});
parts.push({
ETag: response.headers.etag,
PartNumber: partNumber
});
}
// 3. Complete multipart upload
await api.post(
`/upload/s3/multipart/${uploadId}/complete`,
{
parts
},
{
params: {
s3Key: key
}
}
);
console.log("Multipart upload successful");
}
```
### Python Example
```python theme={null}
import requests
import os
from typing import List, Dict
class LiltUploadClient:
def __init__(self, api_key: str, base_url: str = "https://api.lilt.com/v2"):
self.api_key = api_key
self.base_url = base_url
self.headers = {
'Authorization': f'Bearer {api_key}',
'Content-Type': 'application/json'
}
def upload_file(self, file_path: str, filename: str, content_type: str):
"""Upload a single file"""
with open(file_path, 'rb') as f:
file_data = f.read()
# 1. Initiate upload
response = requests.post(
f"{self.base_url}/upload/s3/params",
json={
"filename": filename,
"type": content_type,
"metadata": {
"size": len(file_data)
}
},
headers=self.headers
)
response.raise_for_status()
upload_params = response.json()
# 2. Upload to S3
upload_headers = {
'Content-Type': content_type,
**upload_params.get('headers', {})
}
upload_response = requests.put(
upload_params['url'],
data=file_data,
headers=upload_headers
)
upload_response.raise_for_status()
print("Upload successful")
def upload_large_file(self, file_path: str, filename: str, content_type: str, chunk_size: int = 8 * 1024 * 1024):
"""Upload a large file using multipart upload"""
file_size = os.path.getsize(file_path)
# 1. Initiate multipart upload
response = requests.post(
f"{self.base_url}/upload/s3/multipart",
json={
"filename": filename,
"type": content_type,
"metadata": {
"size": file_size
}
},
headers=self.headers
)
response.raise_for_status()
init_response = response.json()
upload_id = init_response['uploadId']
key = init_response['key']
parts = []
# 2. Upload each part
with open(file_path, 'rb') as f:
part_number = 1
while True:
chunk = f.read(chunk_size)
if not chunk:
break
# Get presigned URL for this part
part_response = requests.get(
f"{self.base_url}/upload/s3/multipart/{upload_id}/{part_number}",
params={
's3Key': key,
'size': len(chunk)
},
headers=self.headers
)
part_response.raise_for_status()
part_params = part_response.json()
# Upload part
upload_response = requests.put(
part_params['url'],
data=chunk,
headers={'Content-Type': content_type}
)
upload_response.raise_for_status()
parts.append({
'ETag': upload_response.headers['etag'],
'PartNumber': part_number
})
part_number += 1
# 3. Complete multipart upload
complete_response = requests.post(
f"{self.base_url}/upload/s3/multipart/{upload_id}/complete",
json={'parts': parts},
params={'s3Key': key},
headers=self.headers
)
complete_response.raise_for_status()
print("Multipart upload successful")
# Usage
client = LiltUploadClient('your-api-key')
client.upload_file('/path/to/file.pdf', 'document.pdf', 'application/pdf')
```
### Java Example
```java theme={null}
import java.io.*;
import java.net.http.*;
import java.util.*;
import com.fasterxml.jackson.databind.ObjectMapper;
public class LiltUploadClient {
private final String apiKey;
private final String baseUrl;
private final HttpClient httpClient;
private final ObjectMapper objectMapper;
public LiltUploadClient(String apiKey, String baseUrl) {
this.apiKey = apiKey;
this.baseUrl = baseUrl != null ? baseUrl : "https://api.lilt.com/v2";
this.httpClient = HttpClient.newHttpClient();
this.objectMapper = new ObjectMapper();
}
public void uploadFile(String filePath, String filename, String contentType) throws Exception {
byte[] fileData = Files.readAllBytes(Paths.get(filePath));
// 1. Initiate upload
Map uploadRequest = new HashMap<>();
uploadRequest.put("filename", filename);
uploadRequest.put("type", contentType);
Map metadata = new HashMap<>();
metadata.put("size", fileData.length);
uploadRequest.put("metadata", metadata);
HttpRequest request = HttpRequest.newBuilder()
.uri(URI.create(baseUrl + "/upload/s3/params"))
.header("Authorization", "Bearer " + apiKey)
.header("Content-Type", "application/json")
.POST(HttpRequest.BodyPublishers.ofString(objectMapper.writeValueAsString(uploadRequest)))
.build();
HttpResponse response = httpClient.send(request, HttpResponse.BodyHandlers.ofString());
if (response.statusCode() != 200) {
throw new RuntimeException("Failed to initiate upload: " + response.body());
}
Map uploadParams = objectMapper.readValue(response.body(), Map.class);
// 2. Upload to S3
HttpRequest.Builder uploadRequestBuilder = HttpRequest.newBuilder()
.uri(URI.create((String) uploadParams.get("url")))
.header("Content-Type", contentType)
.PUT(HttpRequest.BodyPublishers.ofByteArray(fileData));
// Add any additional headers
Map headers = (Map) uploadParams.get("headers");
if (headers != null) {
headers.forEach(uploadRequestBuilder::header);
}
HttpRequest uploadRequest = uploadRequestBuilder.build();
HttpResponse uploadResponse = httpClient.send(uploadRequest, HttpResponse.BodyHandlers.ofString());
if (uploadResponse.statusCode() != 200) {
throw new RuntimeException("Failed to upload file: " + uploadResponse.body());
}
System.out.println("Upload successful");
}
public void uploadLargeFile(String filePath, String filename, String contentType) throws Exception {
File file = new File(filePath);
long fileSize = file.length();
int chunkSize = 8 * 1024 * 1024; // 8MB chunks
// 1. Initiate multipart upload
Map uploadRequest = new HashMap<>();
uploadRequest.put("filename", filename);
uploadRequest.put("type", contentType);
Map metadata = new HashMap<>();
metadata.put("size", fileSize);
uploadRequest.put("metadata", metadata);
HttpRequest request = HttpRequest.newBuilder()
.uri(URI.create(baseUrl + "/upload/s3/multipart"))
.header("Authorization", "Bearer " + apiKey)
.header("Content-Type", "application/json")
.POST(HttpRequest.BodyPublishers.ofString(objectMapper.writeValueAsString(uploadRequest)))
.build();
HttpResponse response = httpClient.send(request, HttpResponse.BodyHandlers.ofString());
Map initResponse = objectMapper.readValue(response.body(), Map.class);
String uploadId = (String) initResponse.get("uploadId");
String key = (String) initResponse.get("key");
List> parts = new ArrayList<>();
// 2. Upload each part
try (FileInputStream fis = new FileInputStream(file)) {
byte[] buffer = new byte[chunkSize];
int partNumber = 1;
int bytesRead;
while ((bytesRead = fis.read(buffer)) != -1) {
byte[] chunk = bytesRead == chunkSize ? buffer : Arrays.copyOf(buffer, bytesRead);
// Get presigned URL for this part
String partUrl = String.format("%s/upload/s3/multipart/%s/%d?s3Key=%s&size=%d",
baseUrl, uploadId, partNumber, key, chunk.length);
HttpRequest partRequest = HttpRequest.newBuilder()
.uri(URI.create(partUrl))
.header("Authorization", "Bearer " + apiKey)
.GET()
.build();
HttpResponse partResponse = httpClient.send(partRequest, HttpResponse.BodyHandlers.ofString());
Map partParams = objectMapper.readValue(partResponse.body(), Map.class);
// Upload part
HttpRequest uploadPartRequest = HttpRequest.newBuilder()
.uri(URI.create((String) partParams.get("url")))
.header("Content-Type", contentType)
.PUT(HttpRequest.BodyPublishers.ofByteArray(chunk))
.build();
HttpResponse uploadPartResponse = httpClient.send(uploadPartRequest, HttpResponse.BodyHandlers.ofString());
Map part = new HashMap<>();
part.put("ETag", uploadPartResponse.headers().firstValue("etag").orElse(""));
part.put("PartNumber", partNumber);
parts.add(part);
partNumber++;
}
}
// 3. Complete multipart upload
Map completeRequest = new HashMap<>();
completeRequest.put("parts", parts);
HttpRequest completeHttpRequest = HttpRequest.newBuilder()
.uri(URI.create(String.format("%s/upload/s3/multipart/%s/complete?s3Key=%s", baseUrl, uploadId, key)))
.header("Authorization", "Bearer " + apiKey)
.header("Content-Type", "application/json")
.POST(HttpRequest.BodyPublishers.ofString(objectMapper.writeValueAsString(completeRequest)))
.build();
HttpResponse completeResponse = httpClient.send(completeHttpRequest, HttpResponse.BodyHandlers.ofString());
if (completeResponse.statusCode() != 200) {
throw new RuntimeException("Failed to complete upload: " + completeResponse.body());
}
System.out.println("Multipart upload successful");
}
}
// Usage
LiltUploadClient client = new LiltUploadClient("your-api-key", null);
client.uploadFile("/path/to/file.pdf", "document.pdf", "application/pdf");
```
## Best Practices
### File Size Recommendations
* **Small files (\< 100MB)**: Use single file upload (`POST /upload/s3/params`)
* **Large files (> 100MB)**: Use multipart upload (`POST /upload/s3/multipart`)
* **Chunk size**: Use 8MB chunks for multipart uploads
### Error Handling
Implement retry logic for network errors:
```javascript theme={null}
async function uploadWithRetry(uploadFn, maxRetries = 3) {
for (let i = 0; i < maxRetries; i++) {
try {
await uploadFn();
return;
} catch (error) {
if (i === maxRetries - 1) throw error;
await new Promise(resolve =>
setTimeout(resolve, 1000 * Math.pow(2, i))
);
}
}
}
```
### Security Considerations
* Presigned URLs expire after a configurable time (typically 1 hour)
* URLs are single-use for uploads
* All uploads are validated against the original request parameters
* HTTPS is required for all upload operations
## Common Error Responses
### 400 Bad Request
```json theme={null}
{
"error": {
"message": "Invalid file type",
"code": "INVALID_FILE_TYPE"
}
}
```
### 413 Payload Too Large
```json theme={null}
{
"error": {
"message": "File size exceeds maximum allowed size",
"code": "FILE_TOO_LARGE",
"details": {
"maxSize": 104857600,
"actualSize": 209715200
}
}
}
```
### 403 Forbidden
```json theme={null}
{
"error": {
"message": "Upload URL has expired",
"code": "URL_EXPIRED"
}
}
```
## Support
For questions or issues with the Cloud Upload API, please contact [support@lilt.com](mailto:support@lilt.com) or refer to the main [API documentation](/api-reference).
# Webhooks
Source: https://support.lilt.com/developers/guides/webhooks
Receive notifications when events occur in LILT
Webhooks allow you to receive real-time notifications when specific events occur in LILT. When you configure a webhook, LILT sends an HTTP POST request to your specified URL whenever a subscribed event is triggered.
## Event Types
You can subscribe to the following event types when [creating a webhook configuration](/api-reference/webhook-configuration/creates-a-new-webhook-configuration):
| Event Type | Description |
| ----------------------------- | ------------------------------------------------------------------- |
| `JOB_UPDATE` | Triggered when a job is updated |
| `JOB_DELIVER` | Triggered when a job is delivered |
| `PROJECT_UPDATE` | Triggered when a project is updated |
| `PROJECT_DELIVER` | Triggered when a project is delivered |
| `INSTANT_TRANSLATE_COMPLETED` | Triggered when instant file translation task completes successfully |
| `INSTANT_TRANSLATE_FAILED` | Triggered when instant file translation task fails |
## Payload Structure
The payload sent to your webhook URL is a JSON object. The structure varies depending on the event type. Job and project event payloads do not include an explicit event type field, so you must infer the event type from the fields present in the payload. Instant translate event payloads include an `eventType` field.
### JOB\_UPDATE
Sent when a job is updated.
```json theme={null}
{
"OrganizationId": 9,
"due": "2025-03-28T10:32:31Z",
"id": 895890,
"isDelivered": 0,
"name": "Marketing Brochure Q1 - English to German"
}
```
| Field | Type | Description |
| ---------------- | ------- | ------------------------------------- |
| `OrganizationId` | integer | The ID of the organization |
| `due` | string | The due date in ISO 8601 format |
| `id` | integer | The job ID |
| `isDelivered` | integer | Delivery status (`0` = not delivered) |
| `name` | string | The job name |
### JOB\_DELIVER
Sent when a job is delivered.
```json theme={null}
{
"OrganizationId": 9,
"deliveredAt": "2025-03-24T08:10:55Z",
"due": "2025-03-24T10:35:01Z",
"id": 895892,
"isDelivered": 1,
"name": "Product Manual v2.0 - English to French"
}
```
| Field | Type | Description |
| ---------------- | ------- | ----------------------------------------- |
| `OrganizationId` | integer | The ID of the organization |
| `deliveredAt` | string | The delivery timestamp in ISO 8601 format |
| `due` | string | The due date in ISO 8601 format |
| `id` | integer | The job ID |
| `isDelivered` | integer | Delivery status (`1` = delivered) |
| `name` | string | The job name |
### PROJECT\_UPDATE
Sent when a project is updated.
```json theme={null}
{
"OrganizationId": 9,
"id": 37654,
"name": "Website Localization - Spring Release",
"due": "2025-03-20T13:47:09.000Z"
}
```
| Field | Type | Description |
| ---------------- | ------- | ------------------------------- |
| `OrganizationId` | integer | The ID of the organization |
| `id` | integer | The project ID |
| `name` | string | The project name |
| `due` | string | The due date in ISO 8601 format |
### PROJECT\_DELIVER
Sent when a project is delivered.
```json theme={null}
{
"OrganizationId": 9,
"id": 1376873
}
```
| Field | Type | Description |
| ---------------- | ------- | -------------------------- |
| `OrganizationId` | integer | The ID of the organization |
| `id` | integer | The project ID |
### INSTANT\_TRANSLATE\_COMPLETED
Sent when an instant file translation task completes successfully.
```json theme={null}
{
"eventType": "INSTANT_TRANSLATE_COMPLETED",
"translationId": 1376873,
"fileId": 68754
}
```
| Field | Type | Description |
| --------------- | ------- | --------------------------- |
| `eventType` | string | The type of event |
| `translationId` | integer | Instant file translation ID |
| `fileId` | integer | ID of the file translated |
### INSTANT\_TRANSLATE\_FAILED
Sent when an instant file translation task fails.
```json theme={null}
{
"eventType": "INSTANT_TRANSLATE_FAILED",
"translationId": 1376873,
"fileId": 68754
}
```
| Field | Type | Description |
| --------------- | ------- | --------------------------- |
| `eventType` | string | The type of event |
| `translationId` | integer | Instant file translation ID |
| `fileId` | integer | ID of the file translated |
## Distinguishing Event Types
Instant translate events include an `eventType` field in the payload. For job and project events, which do not include an explicit event type field, use the following logic to determine which event triggered the webhook:
| If the payload contains... | Event Type |
| ----------------------------------------------------- | ----------------- |
| `isDelivered: 1` and `deliveredAt` | `JOB_DELIVER` |
| `isDelivered: 0` and `name` (job name) | `JOB_UPDATE` |
| `name` (project name) and `due`, but no `isDelivered` | `PROJECT_UPDATE` |
| Only `OrganizationId` and `id` | `PROJECT_DELIVER` |
If you need to handle multiple event types, consider subscribing to each event type with a separate webhook configuration pointing to distinct endpoints. This removes the need to infer the event type from the payload structure.
# Introduction
Source: https://support.lilt.com/developers/introduction
Welcome to the LILT API Documentation and User Guide.
If you are looking to:
* Effortlessly [**Translate your content**](https://support.lilt.com/developers/guides/translate-content/instant-translate) across multiple languages, using AI and human in the loop translation.
* Streamline content creation using [**Transformative AI**](/developers/guides/create-new-content) to create multilingual content directly in the language of your choice.
* Connect your existing [**Content Management System**](/developers/guides/connect-systems-to-workflows) (CMS) to LILT with a connector.
* [**Manage your multilingual content**](https://support.lilt.com/developers/guides/manage-content/create-a-datasource) using your current translation provider.
You have come to the right place.
***
This comprehensive API empowers developers and businesses of all sizes to unlock the full potential of their content through four key areas of functionality:
1. **Translate Content:** Fundamentally, this API will enable you to translate content. LILT enables you with AI powered models that learn using the data you provide and improve with each iteration. Whether you decide to use [AI Translation](https://support.lilt.com/developers/guides/translate-content/instant-translate) or [Verified Translation](https://support.lilt.com/developers/guides/translate-content/verified-translation) is up to you and your business.
2. [**Create:**](/developers/guides/create-new-content) Open AI's ChatGPT took the world by surprise in 2023 by changing how we think about words online. At LILT we took that a step further to create new content for your organization in the desired language and locale.
3. [**Connect:**](/developers/guides/connect-systems-to-workflows) At LILT we have built many ways to access and connect with your content. One such way is through our Connectors framework. This framework enables you to connect directly from a CMS of your choice to provide content for translation, which will automatically be routed back to your organization's CMS.
4. [**Manage:**](/developers/guides/manage-content/create-a-datasource) Content on the internet comes in many formats and can be hard to manage. LILT makes it easy by providing the ability to connect directly to the tools you already use for your translation services, whether it might be Google Translate, DeepL, or Amazon Translate. We have ways to enable workflows with these providers directly within LILT.
***
Ready to take the first step?
* [Try out the Quick Start Guide](/developers/quickstart) - A quick description of how to authenticate and make your first API request with LILT.
* [Explore the API Reference](/api-reference) - Dive into the details of each endpoint, parameter, and available functionality.
# Quickstart
Source: https://support.lilt.com/developers/quickstart
Let's talk about how to make your first API call using LILT's API. This should take about 5 minutes and by the end you will know all of the available languages that LILT can localize your content into.
## What you need to start:
First you will need to retrieve your Organization's API Key from the LILT User Interface.
Log in to the LILT platform as an Administrator, and select Manage from the sidebar. Select API keys.
![Image]()
Create a new API key, or use an existing one. More information on how to use this is available [here](https://support.lilt.com/kb/organization-settings#api). Then, copy the API Key into your favorite API Platform like Postman, Datadog, etc...
![Image]()
Congratulations, now you have everything you need to make your first Api call to LILT.
## Making your first API Call!
As a first step at LILT, you should examine the languages available for Language Translation. To do this we will access our [languages](/api-reference/languages/retrieve-supported-languages) end point. This end point is a good starting point as all you have to think about is authenticating.
To authenticate for the public LILT endpoint all you need is the LILT provided API Key from earlier.
```bash theme={null}
curl https://api.lilt.com/v2/languages?key={Your API Key here}
```
Then you should see a response that looks something like this:
```json theme={null}
{
"source_to_target": {
"en": {},
"...": "..."
},
"code_to_name": {
"aa": "Afar",
"ab": "Abkhazian",
"af": "Afrikaans",
"...": "..."
}
}
```
Congratulations on making your first API call with LILT!
# Product Overview
Source: https://support.lilt.com/documentation/lilt-converse/product-overview
## LILT Converse: Product Overview & User Guide
LILT Converse is a hardware and software package designed to provide instant, offline language support. While standard translation and localization cover text-to-text needs, Converse handles speech-to-speech interaction, functioning as a "real-time speech translation" or "AI interpretation" tool.
## **Key Capabilities**
* **AI Real-Time Translation:** Converse provides secure, real-time speech translation between English and a variety of other languages.
* **Offline Functionality:** Converse operates completely offline — without Wi-Fi or cellular — ensuring maximum security for sensitive communications or for work in remote areas.
* **Integrated Hardware and Software:** Converse's mobile-native AI is built with integrated hardware and software for a seamless user experience, anywhere where translation is needed.
### **Hardware Specifications**
LILT Converse is a hardware + software package.
* **Hardware:** Converse is currently available for Android Tablets. The Samsung S11 is recommended.
* **Configuration:** Hardware is pre-configured by LILT to meet specific customer requirements before delivery, including the option to load adapted translation models created through the LILT platform.
* **Optional Microphone Support:** While the device has built-in audio, compatible plug-in microphones are recommended for better background noise management.
### **Supported Languages**
Converse supports translation between English and the following languages:
* Spanish
* French
* German
* Portuguese
* Italian
* Dutch
* Arabic (optimized for Modern Standard, Gulf, and Egyptian dialects)
* Chinese (Mandarin), with support for Simplified and Traditional script
* Korean
* Japanese
* Vietnamese
* Ukrainian
* Russian
# User Guide
Source: https://support.lilt.com/documentation/lilt-converse/user-guide
## The Conversation Screen
Upon opening the app, the homepage is the Conversation screen. This screen is the user interface for real-time translations.
### **Interface**
The Conversation screen is a split view, where one side faces Speaker 1 (the primary user) and the other side faces Speaker 2.
* The **Speaker 1** side is always set to English. When the app launches, the Speaker 1 side displays the text "Press button to speak" in English above the microphone button; the other side will display the equivalent instruction in the target language. The Speaker 1 side also displays the buttons for clearing the conversation and accessing the Settings menu.
* The **Speaker 2** side can be set to any available language other than English using the Settings menu.
### Having a Conversation
* **Device Positioning:** Set the device on a flat surface or hold it between yourself and the person you are speaking to. In the basic setup, the person you're speaking to should easily be able to read the Speaker 2 side of the split screen and access the microphone button there.
* **Tap to Speak:** Either speaker can begin by tapping the microphone button on their side of the screen. When their microphone button is activated, the button will turn green. As they speak, the device will display a transcript of their speech on their side of the screen and the translation of their speech on the other side.
* **Taking Turns:**
* While a speaker is speaking, their microphone button will be turned on.
* The speaker can end their turn by tapping their microphone button to turn it off, indicated by the button going from green to gray.
* Alternatively, the other speaker can tap their button at any time to begin their turn. This will automatically end the other speaker's turn, if it's still active.
* **Text-to-Speech:** Converse will produce text-to-speech (TTS) audio for the target language, reading aloud the translation of Speaker 1's speech. There is no TTS in the reverse direction; i.e., translations into English will not be read aloud.
* This functionality allows for Converse to be used in situations where Speaker 2 cannot or should not have physical access to the device. In this scenario, Speaker 1 can manage both microphone buttons, and Speaker 2 will simply hear the translations spoken aloud.
* **Clearing the Conversation:** To clear the Conversation screen, tap the clear button (the circular arrow) in the lower left of the Conversation screen.
* **Managing Background Noise:** Using Converse in noisy audio environments may degrade the quality of the transcription and translation. If this seems to be an issue, move to a location with less background noise or consider using a plug-in microphone to improve audio quality.
![Using LILT Converse]( "Using LILT Converse")
## Settings
To open Settings, tap the Settings icon (the gear) in the lower right of Speaker 1's screen.
![Converse Settings]()
### Select Language
The Select Language menu allows you to select Speaker 2's language. Please note that it may take up to 30 seconds for a new model to load after selection. Selecting a new language will automatically return you to the Conversation screen.
### Conversation Settings
The Conversation Settings cover saving conversations, profanity censoring, and external display settings.
### **Saving Conversations**
LILT Converse allows you to export transcripts and audio recordings of your conversations.
* **Configuring Storage**
* In order to save conversations or audio, an external storage device must be plugged into the USB-C port of the device while the conversation is taking place.
* When plugging in a storage device for the first time while running Converse, a popup will guide you through selecting the desired folder for storage.
* If the storage device is removed while the settings for transcript or audio storage are turned on, Converse will display a warning prompting you to check your external storage before proceeding.
* **Save Conversations**
* Toggle this setting **on** to store conversation transcripts on your external storage device.
* Transcripts are stored as `.txt` files in the location selected during storage configuration. The transcripts will contain timestamps for each speaker turn with the transcript and translation of what was said during each turn.
* Conversations are stored by **app session**. For example, if one conversation takes place, then the Conversation screen is cleared and a separate conversation takes place without closing the app in between, both conversations will be stored in one transcript file.
* **Save Background Audio**
* Toggle this setting **on** to store conversation audio files on your external storage device.
* Audio is stored as `.wav` files in the location selected during storage configuration.
* Audio is stored by **app session**. For example, if one conversation takes place, then the Conversation screen is cleared and a separate conversation takes place without closing the app in between, both conversations will be stored in one audio file.
* **Encrypt Saved Conversations**
* This setting allows you to set a password on exported transcript and audio files.
### **Censor Profanity**
Toggle this setting **on** to censor common profanity words in all languages.
* Note that profanity censoring may be imperfect, as profanities vary widely in different dialects and the definition of profanity is subjective. This feature covers commonly recognized profanity words.
* On the Conversation screen, censored words will be replaced in the transcripts with a series of asterisks ("\*\*\*\*\*\*"). In the translated text, the equivalent word will either be censored in the same way or will be expressed in non-profane terms, depending on the context.
* In Saved Conversation transcripts, profanity will be censored in the same way as on the Conversation screen.
* In Saved Audio files, profanity will not be censored.
### **External Display Settings**
Converse can be used to display live subtitles onto an external display. The displayed text can either be a transcription of the input speech or a live written translation of the speech.
* **External Display Shows:** This can be toggled between *Transcription* and *Translation*
* **External Display Chroma Key:** This optimizes the output for "green screen" setups. It allows the translation or transcription text to be cleanly overlaid onto a broadcast or video system.
* **External Display Logo:** This is a simple toggle to show or hide the Converse logo on the external output. It’s primarily used for demos or when a customer wants branded attribution.
### Performance Notes
* **Accuracy Disclaimer:** LILT Converse can make mistakes. It is not suitable for conversations requiring 100% accuracy.
* **Context Sensitivity:** Converse's AI performs better with more context. Very short conversational passages may exhibit lower performance compared to longer exchanges, where LLMs can better utilize predictive context.
* **Domain Adaptation:** By default, Converse uses general-purpose models that may lack domain-specific expertise. Specialized domain models can be developed by request. Customers of the LILT platform who already have adapted models can request to have those models loaded into Converse.
# 2024 Q4 Release Notes
Source: https://support.lilt.com/kb/2024-q4-release-what-s-new-in-the-lilt-platform
## What's New In The Platform
## **On-Prem Features and Security Updates**
### **LILT Translate**
#### **Improved Tag Projection**
We are excited to announce updates to our tag projection functionality, which improves the overall quality of tag projection and allows linguists to spend less time on adjustment.
Previously, tags were projected by computing a word alignment on the tag-stripped source/target using a variant of our V1 models, then used a rule-based approach to transfer tags based on word alignments. With this new update, tags are projected using a single, multilingual projection model that directly generates the target sentence with tags, without the detour through word alignment.
[***For more information on our Research Team's work on tag projection, see this article.***](https://aclanthology.org/2021.findings-emnlp.299.pdf)
#### **Domains**
LILT’s new **Domains** feature enhances workflow segmentation, allowing organizations to create distinct operational areas within LILT. By assigning resources such as users, models, and preferences to specific domains, administrators can customize experiences to improve productivity, focus, and data privacy for each user group.
**What’s New?**
1. **Customizable Domains**
* Domains allow administrators to segment LILT by operational areas, facilitating tailored experiences across teams or departments.
2. **Enhanced User Personalization**
* Users can switch between assigned domains, with interfaces updating to reflect models, file loaders, and translation jobs associated with the active domain.
3. **Advanced Administrative Control**
* Administrators can set up, manage, and delete domains, assigning specific resources such as users, models, and preferences.
* Default languages, workflows, and file loaders can be specified per domain.
4. **Domain-Specific Analytics and Job Filtering**
* Analytics and job management views are filtered based on the active domain, making it easier for users and admins to manage tasks and track progress relevant to their domain.
#### **Assign Domains as Secondary Reviewers**
We are excited to announce updated assignment functionality where project opportunities can be presented to multiple Secondary Reviewers. With this update, Secondary Reviewers identify which languages they support in their profile, and are then assigned to domains. We can then assign a domain as a Secondary Reviewer, which would share the opportunity with all those qualified and Secondary Reviewers can accept projects based on their availability. For more information, please visit [/kb/customer-review#SecondaryReview-SecondaryReviewerassignmentsthroughdomains](/kb/customer-review#SecondaryReview-SecondaryReviewerassignmentsthroughdomains).
*Please note: This feature is in beta and will be available for all orgs in early November. If you would like to use this feature before then, please reach out to your Account Team to learn more.*
![]()
#### **Additional Data in Concordance search and Data Source Download**
Concordance searches now display additional data: Creation date, Updated date, Created by (name/email), Updated by (name/email), and the file name from which it was created. This allows users to understand who accepted and confirmed segments into their data sources. Only those with the User Visibility permission set are allowed to see the names and emails of those who created or updated the entry. This data is now also available for managers and admins in the Data Source download.
![]()
#### **Recently Used Language Options**
We are excited to introduce a feature improvement to our language dropdown menu that shows customers their most recently used languages when submitting projects for translation. Previously, customers needed to search for languages every time they went to submit new projects. With this update, their recently used languages are more accessible.
![]()
#### **Project-Level Setting for Copy/Paste**
LILT Translate now has a project-level setting to define the usage of Copy/Paste. All new projects inherit the organization setting by default, but can be adjusted at the project level. To learn more about the Copy/Paste setting, please visit the [Organization Settings page](/kb/organization-settings).
![]()
#### **V3 Model Release for PT > EN**
We are excited to introduce an improved and larger Translation and Adaptation V3 model for Portuguese (PT) > English (EN). We will be releasing additional V3 models. Please visit our [Supported Languages](/kb/v2-language-models) page for more information on our available languages and models.
#### **New Keyboard Shortcut**
We released a new keyboard shortcut that will insert the top TM entry from the CAT sidebar into the segment editor. Use Ctrl + Shift + S to insert.
![]()
#### **Setting to Automatically Run Quality Assurance Tools**
We released a new sub-setting for Mandatory Quality Assurance Tools that would automatically run Quality Assurance Tools. When this is enabled, Quality Assurance Tools will run immediately after the selected workflow step is completed. For more information, please visit the [Mandatory Quality Assurance Tools KB page](/kb/mandatory-batch-qa-check).
![]()
#### **Updated Default Roles - Customer, and Customer + LILT Create**
To better reflect the needs of our platform customers, we’ve updated LILT’s default roles so there are two customer roles - Customer, and Customer + LILT Create. This differentiates which users have LILT Create permissions. Both of these roles also had the “User visibility” permission revoked so as to not reveal sensitive information. For more details, please reference [/kb/default-roles](/kb/default-roles).
#### **Customer Review is now Secondary Review**
We’ve updated our product verbiage to better reflect our customers' workflows, and we’ve renamed the Customer Review stage to Secondary Review.
#### **Overwrite Confirmed Segments for Secondary Review**
Forward and backward overwrite confirmed segments is now available in the Secondary Review stage. These are enabled by default, as they are for existing workflow stages.
![]()
#### **Keyboard Shortcut to Insert Top TM Entry**
Linguists and customers now have a keyboard shortcut to insert (copy & paste) the top TM entry from the CAT sidebar into the CAT editor - “Ctrl + Shift + S”.
#### **Reordered Segment Context Panel**
The segment context panel has been reorganized to reflect the importance of information during translation. The blocks now display TM results, Termbase results, and MT results.
![]()
#### **Word Count in Linguist Assignment Emails**
We have added data to linguist assignment emails to provide further details. Translation assignment emails now include the number of Exact Match words across the project. Review assignment emails now include the number of Repetitions & Exact Match words across the project.
#### **Additional Language Models**
We are happy to announce the expansion of our capability to deliver high quality output translations. Learn more about our [supported languages](/kb/v2-language-models) updates.
#### **Block Copy and Paste Functionality**
LILT Translate now supports blocking any usage of copy and paste. This will prevent all copy and pasting within source and target text, and can be applied through the org settings page. For more information, please visit the [Organization Settings page](/kb/organization-settings).
![]()
### **LILT Manage**
#### **Edit Model Names**
![]()
You can now edit the names of your model based on your preferred naming conventions for your teams.
#### **New LLM Support**
We’ve grown the number of models we support in LILT. To access them, these models need to be provided by you in order to leverage them.
**New LLM Services for LILT Create**
OpenAI
* GPT-4o
* GPT-4o-mini
Anthropic
* Claude 3.5 Sonnet
* Claude 3 Haiku
* Claude 3 Sonnet
* Claude 3 Opus
AI21 Labs
* Jamba-Instruct
* Jurassic-2 Ultra
* Jurassic-2 Mid
Google
* Gemini 1.0 Ultra
* Gemini 1.5 Pro
* Gemini 1.0 Pro
* Gemini 1.0 Nano
* Gemini 1.5 Flash
* PaLM 2
**New LLM Services for LILT Translate**
* GPT-4
* GPT-4o
* GPT-4o-mini
#### Data Labeling
LILT announced the release of our Data Labeling feature at our Winter AI Day. This feature is an AI-optimized and human reinforced solution to build high-quality, reliable, and multilingual training data sets used to train foundational Large Language Models. We designed this feature for the world’s leading Generative AI companies, and we are working with those companies to train their foundational LLMs. LILT Label can help:
* \*\*Expand your data pool \*\*- Training LLMs on non-English languages helps avoid biases and apply cultural nuances in a secure environment.
* **Ensure data quality**, because our responses are sourced from native-speaking, domain experts to ensure accuracy and quality.
* **Accelerate the labeling process**, with dedicated interfaces to intuitively build and annotate data.
To learn more, check out our announcement at our Winter AI Day: [https://resources.lilt.com/ai-day-winter24-ty](https://resources.lilt.com/ai-day-winter24-ty)
## **Security and Stability Improvements**
We fixed 90+ issues related to security and stability so that our customers would have a more delightful experience.
1. **Translation Consistency & Performance Enhancements**
* We've improved the handling of batch updates and resolved translation inconsistencies, ensuring greater accuracy in translation quality.
* Addressed timeout and performance issues in AI Review and Instant Translate features.
2. **User Experience & Interface Enhancements**
* Enhanced the UI across multiple areas, ensuring consistency with our design system. Notable fixes include copy/paste functionality, action button alignment, and improved handling of notifications and tooltips.
* Updated the Create page and other components for a cleaner, more intuitive interface.
3. **Connector & Integration Updates**
* Added Box to our Connector Builder for seamless integration.
* Fixed encoding issues in XTM custom MT integration
* Improved Contentful workflow, including publishing and translation warnings.
4. **Domains & Permissions**
* Improved user access and permission handling in Domains, with fixes for non-Admin behavior and verification processes.
5. **Job & Document Management Improvements**
* Enhanced document handling, ensuring large batch jobs and project details load efficiently and correctly.
6. **Technical & Performance Fixes**
* Addressed load performance issues, specifically for Figma projects and the Linguist Homepage.
* Removed outdated dependencies to improve system reliability and responsiveness.
We continue to prioritize your feedback and are committed to delivering a better experience with every update. Thank you for your continued support and insights!
## **Included Patch Updates**
* **User Creation:** Fixed admin-client create-user command
* **Logging Issues:** Fixed logging issue on front-end due to production log obfuscation
* **Services Errors:** Fixed bug causing various services to occasionally throw a 500 Internal Server Error (Data sources, instant translate, job creation)
* **Document Deletion with Comments:** Fixed an issue when documents would not be deleted when segments had comments
* **Untranslated Segments**: Fixed the issue when untranslated segments would not appear in the target file if they are within the same paragraph as a translated/confirmed segment.
* **Inconsistent Letter Case in Data Sources:** Fixed the issue of inconsistent letter cases in the custom properties of a data source.
## **Cloud-only Features**
### **LILT Translate**
#### **Linguist Stats Data Refresh**
Linguists now have visibility into when the data in Linguist stats was last refreshed, to provide visibility into how recent the data is.
![]()
### **LILT Manage**
#### **LILT Financial File Download**
![]()
We are excited to introduce a new feature that allows you to download your monthly financial report directly from the LILT platform. This report will help you easily track your localization spending and stay on top of your financials.
* **Format:** The report is available in Excel format.
* **Availability:** You can download the report every month. And this is available on a per-customer basis - please contact LILT sales with any questions regarding access.
This enhancement is designed to provide you with greater transparency and control over your localization budget.
### **LILT Create**
#### Instant Video Dubbing
We are excited to announce Instant Video dubbing, where you can pair your existing custom models with text-to-speech and voice selection capabilities to receive a dubbed video in a new language within seconds. This offering allows you to consolidate your workflows into one easy-to-use product, expand your audience reach, and maintain brand accuracy by using your fine-tuned models. Interested in learning more? Check out our announcement at our Winter AI Day: [https://resources.lilt.com/ai-day-winter24-ty](https://resources.lilt.com/ai-day-winter24-ty)
### **LILT Connect**
#### **Box App Center Integration**
We're excited to announce that LILT is now available on the Box App Center, making it easier than ever to integrate your translation workflow directly with Box. With this integration, you can seamlessly manage and translate content stored in Box, streamlining localization processes for global teams. Try it today and experience efficient, high-quality translations right from your Box environment.
#### **Contentful x LILT Connector Updates:**
**Support for Rich Text Embedding**
We are introducing a new feature for the Contentful x LILT connector to better support embedded entries within Rich Text fields. With this update, the connector will automatically recognize and include embedded entries in the translation process, just like linked entries. This enhancement will eliminate the need for manual intervention, ensuring a smoother and more efficient localization workflow for content that includes embedded assets.
**Default Locale**
We are working on an update to address issues with the Contentful x LILT connector for customers using a default locale other than **en-US**. Currently, when a customer’s default locale is set to a different variant, such as **en**, the connector does not operate as expected. While a force extract is possible, it does not allow for content to be sent organically using this source language, and the workflow statuses in Contentful are not updated properly.
This update will ensure the connector can seamlessly handle non-**en-US** default locales, allowing for efficient content management and status updates, even at scale with multiple stakeholders involved.
**Auto-Publish Upon Delivery**
We are introducing a new feature in the Contentful x LILT connector that allows content to be automatically published upon delivery from LILT to Contentful. With this option, once translations are completed and delivered back into Contentful, the content can be immediately published without requiring manual intervention. This streamlines the content publishing process, saving time and ensuring quicker go-to-market for localized content.
#### **LILT x Shopify Connector Updates:**
* **Shopify - Feature to Select Only Active Products**
* Added an option to filter and select only active products within the Shopify connector. This improvement enhances the user experience by allowing more granular control over product selection during the translation process.
* **LILT Shopify App Not Showing Metaobjects**
* Fixed a bug where metaobjects were not being displayed in the True Classic LILT Shopify App. This correction ensures that all relevant data is visible to users, improving the user experience.
* **Adjust All Products Filtering**
* Enhanced the product filtering capabilities to provide more comprehensive options within the Shopify connector. The improvements include:
* **Product Count:** Added a count of available products within each section for better visibility and management.
* **Filter Updates:** Changed the filter label from "All Active Products" to "All Products" to reflect the inclusion of all product statuses.
* **Selection Options:** Introduced new filtering options, allowing users to select between "All Active," "All Archived," and "All Draft" products, offering more granular control over product data management.
* **Shopify Connector Import Issues**
* Addressed urgent issues related to product import functionality within the Shopify Connector. This critical fix resolves import errors that were affecting data synchronization.
* **Shopify Connector - Export Products by Tag**
* Added a new feature to export products based on tags in the Shopify Connector. This functionality enables more targeted data exports, enhancing the ability to manage and utilize product data.
#### **LILT x S3 Connector Updates**
* **Duplicate Projects Created During Connector Job**
* Fixed an issue where duplicate projects were being created during connector jobs. This correction ensures that only a single project is generated per job, preventing redundancy and reducing confusion in project management.
* **Expand S3 to Select Source Based on a Directory Path**
* Enhanced the S3 storage-based connector to allow users to select the source based on a specific directory path. This update provides greater flexibility in defining the source data, making it easier to manage large datasets within S3.
* **Add Ability to Create/Set a File-Level Metadata Field When Returning Target Files**
* Introduced the ability to create or set metadata fields at the file level when returning target files. This enhancement allows users to attach custom metadata to files, enabling better organization and retrieval of data within S3.
* **Allow the S3 connector to Use a Different Bucket for Outputs**
* Updated the rclone-based S3 connector to support using a different bucket for output files. This feature provides more control over where processed data is stored, improving flexibility in managing output destinations.
# LILT 5.1 Release Notes
Source: https://support.lilt.com/kb/2025-q1-lilt-5-1-0-release-notes
2025 Q1 Release
## **On-Prem Features and Security Updates**
### **LILT Translate**
#### **Introducing LILT AI Review Agent: Achieve Unprecedented Translation Accuracy & Speed!**
LILT AI Review Agent is a groundbreaking automated editor that acts as an intelligent, independent layer of quality assurance for both AI and human translations. By proactively identifying and correcting errors, it dramatically improves accuracy and streamlines your review process. Say goodbye to review bottlenecks and hello to near-perfect translations, faster than ever before. This innovative feature reduces review time by automating corrections, delivers highly accurate translations with minimal human input, minimizes inconsistencies in manual reviews, speeds up the entire localization lifecycle, and leverages a separate AI model for unbiased quality checks.
**Resources**
* [AI Review Article](/kb/ai-review)
![]()
### **Organization-Level QA Configuration: Tailored Quality Assurance for Your Enterprise**
*Tracker items number 26 and 59*
Implement custom QA configurations at the organization level, applying language-specific quality checks across your entire workflow. This empowers you to achieve higher quality translations by catching more errors with language-specific QA rules. You'll have more control, easily managing QA configurations as an administrator, and benefit from customizable access, ensuring the right people handle QA files with granular permissions. Ultimately, this leads to streamlined workflows and valuable time savings.
**Resources**
* [Custom QA Setup](/kb/custom-qa)
### **Domain-Level Reviewer Error Logging Customization: Enhanced Control and Flexibility**
Set domain-level preferences for reviewer error logging. This allows for workflow automation, automatically applying settings per domain, and provides greater control, optimizing settings based on specific business needs.
### **Project Instructions: Direct Communication for Faster Turnarounds**
Add project-specific instructions directly in the job submission portal. This leads to a streamlined workflow, reducing back-and-forth communication, and faster turnaround, providing instructions directly to linguists. You'll also gain greater control, ensuring accurate project execution with upfront details.
### **Instant Translate Homepage**
We launched a new AI translation workflow designed for specialized organizations, providing fast and secure AI translations without requiring full platform access for individual linguists.
![]()
**Resources**
* [Instant Translate Homepage](/kb/instant-translate-homepage)
### **LILT V3 models now available!**
Our latest purpose-built AI model builds on our V2 model in a few critical ways:
* Expanded V3 parameters by 5X (compared to V2)
* Improved ability to gather broader context for more informed translation choices
* Trained model on a novel Reinforced Learning from Human Feedback (RLHF) concept (EXTERNAL LINK:[*see published paper*](https://arxiv.org/abs/2409.17673)) - so translations sound more natural
* Significantly improved quality and efficiency outputs
* Added additional language pairs
Read more about [supported language pairs](/kb/v2-language-models).
## **Email alerts in Japanese now available**
Email alerts are now translated to Japanese for all profiles set to Japanese. This is available to all on-prem customers.
### **Added CVEs and STIGs**
We’ve implemented security CVEs and Security Technical Implementation Guides (STIGs) for onboarding.
### **Domains in API and Connectors: Streamlined Workflows and Accurate Billing**
Assign Domains to jobs submitted via API and Connectors for improved workflow alignment and reporting. This allows for workflow automation, automatically applying correct settings for each job. You'll also experience improved tracking and reporting with Domain-specific analytics, seamless integration, ensuring CMS Connector jobs follow customer preferences, and accurate billing, tagging Domains for precise cost allocation.
**Resources**
* [Domains Knowledge Base Article](/kb/user-domains-documentation)
## **Cloud-only Features**
### **LILT Translate**
#### **Revamped LILT AEM Connector: Seamlessly Integrate Translation into Your Content Workflow!**
The newly redesigned LILT AEM Connector offers a powerful and intuitive integration of LILT's translation capabilities directly within your Adobe Experience Manager environment. Eliminate cumbersome manual content transfers and unlock a streamlined localization process. This enhanced connector provides greater configurability to adapt to your unique and complex translation needs, empowering marketing teams to translate website and other content faster, maintain consistent brand messaging, and accelerate time-to-market. This integration works directly within AEM, preserving content formatting and crucial context, eliminates manual steps for significant efficiency gains, and easily handles high volumes of content updates with minimal manual effort.
### **Enterprise-Grade SSO and MFA: Enhanced Security and Simplified Access**
We now offer enterprise-grade Single Sign-On (SSO) and Multi-Factor Authentication (MFA) integrations. This results in simplified enterprise access, streamlining logins for large organizations. You'll also benefit from enhanced security with robust multi-factor authentication, and efficient user management through automated provisioning and control.
### **Support for Drupal v11 and other API enhancements!**
LILT now supports Drupal v11, allowing users on this version to access LILT’s full suite of products and services right within Drupal. We've also automated backend notifications within the Drupal Connector further boosting efficiency of translations sent through this Connector.
### **New Contentstack features supported via the LILT Connector**
Additional Contentstack features are now supported when pushing translations through the Contentstack LILT Connector.
Newly supported features include: nested entries, filter search, select all and publish upon delivery. Now users can continue working within Contentstack and push translations to LILT without ever leaving the Contentstack CMS.
### **Job notifications now available via Connector**
Receive automatic notifications on key updates such as changes to documents and job progress right within your business systems. These “webhook style notifications” can be implemented with any of LILT’s 60+ Connectors, so users never have to leave their content management or business systems in order to track status updates.
# LILT 5.2 Release Notes
Source: https://support.lilt.com/kb/2025Q2ReleaseNotes
2025 Q2-Q3 Release
# **On-Prem Features and Security Updates**
### **Structured PDF Translations**
You can now upload a text-based PDF directly to Lilt and get a translated PDF back while retaining original formatting for both Instant and Verified Translation jobs.
LILT’s new PDF translation feature automatically extracts the text, translates it, and reconstructs the document, ensuring that your tables, columns, and images stay right where they should be. Check out more about how it works [here](https://support.lilt.com/kb/image-and-scanned-pdf-file-translation#pdf-translation)
### **Language & Locale Management API**
We now have a new language & locale management API, delivering a more efficient and robust way to handle translation pairs in the Lilt platform. This powerful API brings several key benefits:
**Streamlined Workflow:** Automatically creates missing languages and locales when setting up new translation pairs, eliminating manual setup steps\
**Intelligent MT Integration:** Automatically enables machine translation for supported language pairs (60+ languages), ensuring optimal translation quality with zero configuration\
**Enhanced Reliability:** All pair creation happens in a single transaction, preventing incomplete setups and ensuring data integrity\
**Error-Proof Operations:** Comprehensive validation with clear error messages and graceful handling of duplicates, making integration seamless and reducing support requests
This API represents a significant step forward in making language management more accessible and error-resistant for both administrators and developers. Find out more [here](https://support.lilt.com/kb/additional-languages#adding-additional-languages)
### Improve Translation Memory Management
Prioritize Recency Organization Setting
LILT released a new organization-level setting that allows for recency-based match prioritization. If enabled, 101% matches will be treated as equivalent to 100% matches, prioritizing recency over context precision. This supports customers who want to use the most recent 100+% match translation, regardless of context, without decreasing the strength of TM matches.
### Prioritize Recency Organization Setting
LILT released a new organization-level setting that allows for recency-based match prioritization. If enabled, 101% matches will be treated as equivalent to 100% matches, prioritizing recency over context precision. This supports customers who want to use the most recent 100+% match translation, regardless of context, without decreasing the strength of TM matches.\
Find out more [**here**](https://support.lilt.com/kb/translation-memory-matching#DataSourceMemoryMatching-Prioritizerecencysetting)**.**
### Instant Translate Analytics
We've introduced a powerful new set of analytics specifically for our government users, focusing on **Instant Translation**. These new metrics provide insights into translation efficiency, user activity, and overall ROI. All metrics can be aggregated at the organization, domain, language pair, and user level. Find out more [**here**](https://support.lilt.com/kb/lilt-analytics-v2)**:**
## **LILT 5.2.1**
### **Native AWS RDS and S3 Support**
LILT 5.2.1 introduces native support for Amazon Web Services (AWS) cloud infrastructure, allowing organizations to leverage AWS's managed services for enhanced scalability, reliability, and operational efficiency.
This release includes built-in support for:
* **Amazon RDS** for managed database services, providing automated backups, high availability, and simplified maintenance. Learn more about [Using Amazon RDS Instead of Local MySQL](https://support.lilt.com/system-administration/using-rds-instead-of-mysql).
* **Amazon S3** for secure and scalable object storage, offering enterprise-grade data durability and availability. See our guide on [Using S3 instead of MinIO](https://support.lilt.com/system-administration/using-s3-instead-of-minio).
These integrations reduce operational overhead while providing enterprise-grade infrastructure capabilities for mission-critical translation workloads.
# **Breaking Changes**
## ElasticSearch
ElasticSearch has undergone a major renovation, to switch to the ECK operator and upgrade from version 7 to version 8.\
In order to successfully install this version of LILT, the following should be executed by a system administrator *prior to installing this version of LILT*:
* Uninstall the existing ElasticSearch helm installation
* Ensure ElasticSearch PersistentVolume(s) and PersistentVolumeClaim(s) for elastic have been removed
## Troubleshooting
### Certificate Issues with Dataflow and Internal Tools
If you experience connectivity problems, particularly with Dataflow or when connecting to internal tools, the TLS certificates may need to be regenerated. To resolve this:
1. Remove the `lilt/certs` folder from your installation directory
2. Remove the TLS certificate secrets from your Kubernetes cluster by running:
```bash theme={null}
kubectl delete secret tls-server-certificates -n lilt
kubectl delete secret tls-server-certificates-minio -n lilt
kubectl delete secret tls-client-certificates -n lilt
```
3. Re-run the `install-lilt.sh` script to regenerate certificates
This will create fresh certificates and resolve most connectivity issues between internal services.
# AI Providers
Source: https://support.lilt.com/kb/3rd-party-llm-support-for-the-contextual-ai-engine
In this article, we describe how to set-up your AI Providers to integrate third party models within LILT. This article is meant for anyone interested in using and managing their own LLMs within the LILT platform.
*Administrator role or equivalent API Access role permission is required to configure LLMs in LILT.*
## Configuring and Editing LLM Integrations and Settings
### Manage AI Providers
![]()
LILT enables administrators to set-up and manage LLMs all within the LILT platform. To set-up and manage an LLM:
1. Use the sidebar to navigate to “Manage” then select “AI Providers”.
2. On the first tab, you will see the various providers we support including Google, DeepL, OpenAI, AWS, and Azure. In addition, we also support Custom Models - please contact the LILT team to learn more!
3. From the desired LLM card, select “Configure”
1.
![]()
4. Enter the required configurations for your LLM (e.g. API key, JSON credentials, bucket name, Password, etc). For more information on configuration details, see the relevant pages:
1. [DeepL Configuration](/kb/deepl-configuration)
2. [Google Configuration](/kb/google-configuration)
3. [AWS Configuration](/kb/aws-configuration)
4. [OpenAI Configuration](/kb/openai-configuration)
5. Other selections:
1. Use Terms = allows selected terminology entries from the LILT Data Source attached to the model to be used for fine tuning Models built from this LLM.
2. Allow fine-tuning = allows LILT to share memory entries from selected LILT Data Sources to create more contextualized models.
5. Once you click Verify and Save, you will be able to see all of the associated services that are enabled for your organization based on the credentials provided.
![]()
6. Once you’ve configured your AI Providers, click on the “Services” Tab
1. Here you will see all of the different services (i.e. Translation, Create, etc.) you can access in LILT and the corresponding 3rd party AI services to power it in your platform.
![Screenshot2025 12 02at15 36 22 Pn]()
### Edit LLM Credentials and Settings
Once an LLM is set-up, you can edit the API key, Password, and settings by doing the following:
1. Use the sidebar to navigate to “Manage” then select “AI Providers”
2. From the desired AI Provider, select “Edit”
3. Edit the API Key or Password, and toggle “Enable for your organization”, “Use Terms”, “Allow fine-tuning” as needed, and Save.
# LILT 5.3 Release Notes
Source: https://support.lilt.com/kb/5.3.0ReleaseNotes
2025 Q4 Release
# **On-Prem Features and Updates**
## **Multimodal OCR Service**
LILT 5.3 introduces a powerful new neural-based OCR service that delivers significantly improved accuracy for image and scanned PDF translation. The multimodal OCR service leverages advanced machine learning models to better extract text from complex documents, including those with mixed content types, tables, and challenging layouts.
**Key Benefits:**
* Enhanced accuracy for scanned PDFs and images
* Improved handling of complex document layouts
* Better recognition of tables and formatted content
* Seamless integration with existing translation workflows
**Configuration:**
To enable the multimodal OCR service, update your `values.yaml`:
```yaml theme={null}
ocr:
enabled: true
env:
MQ_PWD: "" # Add to secrets.yaml
```
## **Enhanced LLM Inference Architecture**
LILT 5.3 restructures the LLM inference system into dedicated, optimized services for different AI models. This architectural improvement provides better resource management, improved performance, and more granular control over AI capabilities.
### **New Specialized Inference Services:**
**Llama vLLM Inference**
* Optimized inference for Llama language models
* GPU-accelerated processing (requires 4 GPUs)
* High-performance vLLM backend
* Resource requirements: 100G memory, 5-14 CPUs
**Whisper Speech-to-Text**
* Real-time speech-to-text transcription
* GPU-accelerated for faster processing
* Supports multiple languages
* Ideal for audio/video translation workflows
**Gemma Model Inference**
* Dedicated inference for Gemma3 models
* Optimized for specific translation tasks
* GPU-accelerated processing
**Emma-500 Model Inference**
* Specialized inference for Emma-500 models
* Advanced language understanding capabilities
**Configuration:**
Enable specific inference services based on your needs:
```yaml theme={null}
llama-vllm-inference:
enabled: true # Enable Llama models
llm-inference-whisper:
enabled: true # Enable speech-to-text
gemma-vllm-inference:
enabled: true # Enable Gemma models
emma-500-vllm-inference:
enabled: true # Enable Emma-500 models
```
**GPU Requirements:** Ensure GPU nodes are available and labeled with `capability: gpu`.
## **Third-Party MT Batch Processing**
A new CPU-based batch worker specifically designed for third-party machine translation (3pMT) processing has been added. This dedicated worker improves throughput and reliability for integrations with external MT providers.
**Features:**
* Dedicated CPU-based processing for 3pMT
* Configurable worker pools
* 24G memory for large document handling
* Improved batch processing reliability
**Configuration:**
```yaml theme={null}
batch-worker-cpu-3pmt:
enabled: true
env:
BATCH_WORKERS_MANAGER_3PMT_CPU_MAX_WORKERS: "1"
BATCH_WORKERS_MANAGER_3PMT_CPU_STANDBY_WORKERS: "0"
```
## **Enhanced Document Conversion**
Document conversion timeouts have been made configurable, allowing better handling of large and complex documents. The new timeout settings apply to both the converter and file-translation services.
**Configuration:**
```yaml theme={null}
converter:
env:
APRYSE_TIMEOUT_MINUTES: "5" # Adjust based on document complexity
file-translation:
env:
APRYSE_TIMEOUT_MINUTES: "5" # Adjust based on document complexity
```
Increase timeout values for particularly large or complex documents to prevent conversion failures.
## **MySQL SSL Support**
LILT 5.3 adds comprehensive SSL/TLS support for MySQL connections, enhancing security for database communications. SSL is now enabled by default with flexible configuration options.
**Configuration:**
```yaml theme={null}
file-job:
env:
MYSQL_SSL_MODE: "PREFERRED"
MYSQL_SSL_ENABLED: "true"
memory:
env:
MYSQL_SSL_MODE: "PREFERRED"
MYSQL_SSL_ENABLED: "true"
```
**SSL Modes:**
* `REQUIRED`: Forces SSL connections (recommended for production)
* `PREFERRED`: Uses SSL if available, falls back to unencrypted
* `DISABLED`: Disables SSL (not recommended)
## **Core Platform Updates**
### **Internal Architecture Improvements**
**Service Naming Standardization**
* AV scanner service renamed to `lilt-av-scan` for consistency
* ConfigMap and Secret resources standardized with `lilt-` prefix
* Improved service discovery and management
***
# **Breaking Changes**
## **LLM Inference Service Restructuring**
The generic `llm-inference` service has been **removed** and replaced with specialized inference services. This change improves resource utilization and provides better control over AI model deployment.
**Migration Required:**
If you previously had `llm-inference` enabled, you must:
1. **Disable the old service:**
```yaml theme={null}
llm-inference:
enabled: false # Remove this service
```
2. **Enable the appropriate replacement services:**
```yaml theme={null}
# For Llama models
llama-vllm-inference:
enabled: true
# For speech-to-text
llm-inference-whisper:
enabled: true
# For Gemma models
gemma-vllm-inference:
enabled: true
# For Emma-500 models
emma-500-vllm-inference:
enabled: true
```
3. **Update GPU node labels** if not already configured:
```bash theme={null}
kubectl label nodes capability=gpu
```
## **ConfigMap and Secret Name Changes**
Several services now reference standardized `lilt-configmap` and `lilt-secrets` instead of service-specific resources.
**Affected Services:**
* Translation Memory (tm)
* Lexicon
**Migration Steps:**
1. Ensure your deployment creates resources with the new names:
* `lilt-configmap` (previously `front-configmap`)
* `lilt-secrets` (previously `front-secrets`)
2. If using custom Helm templates, update references:
```yaml theme={null}
# Old:
configMapName: front-configmap
secretsName: front-secrets
# New:
configMapName: lilt-configmap
secretsName: lilt-secrets
```
## **Init Container File Path Changes**
Services using the two-stage init container pattern (lexicon, file-job) must update file path configurations.
**Old Format:**
```yaml theme={null}
lexicon:
init:
filePaths: "s3://lilt/lexicon-data/..."
file-job:
init:
filePaths: "s3://lilt/tesseract/..."
```
**New Format:**
```yaml theme={null}
lexicon:
init:
filePaths: "lexicon-data/..." # Remove s3://lilt/ prefix
file-job:
init:
filePaths: "tesseract/..." # Remove s3://lilt/ prefix
```
**Action Required:** If you have customized init container configurations, update file paths to remove the `s3://lilt/` prefix.
***
# **New Configuration Requirements**
## **Required Secrets**
### **Core-API S3 Credentials**
Add to `secrets.yaml`:
```yaml theme={null}
core-api:
onpremValues:
env:
S3_ACCESS_KEY: ""
S3_SECRET_KEY: ""
```
Set these to match your MinIO or S3-compatible storage credentials.
### **Multimodal OCR (If Enabling)**
Add to `secrets.yaml`:
```yaml theme={null}
multimodal:
env:
MQ_PWD: ""
```
## **Optional Configuration Updates**
### **Backend Configuration Toggle**
A new toggle allows enabling/disabling backend configuration features:
```yaml theme={null}
front:
onpremValues:
backend_config:
enabled: false # Set to true if needed
```
### **BigQuery Integration**
For customers using BigQuery analytics:
```yaml theme={null}
core-api:
env:
BIG_QUERY_ENABLED: "false" # Set to true if using BigQuery
```
### **Batch Worker Memory**
Batch worker memory limits have been increased for improved performance:
```yaml theme={null}
batchv4:
resources:
requests:
memory: 2G # Increased from 1G
limits:
memory: 2G
```
**Action Required:** Ensure worker nodes have sufficient memory capacity.
***
# **Infrastructure Requirements**
## **GPU Node Requirements**
If enabling LLM inference services, ensure GPU nodes are available:
| Service | GPU Count | Memory | CPU |
| ----------------------- | --------- | -------- | -------- |
| llama-vllm-inference | 4 | 100G | 5-14 |
| llm-inference-whisper | Yes | Variable | Variable |
| gemma-vllm-inference | Yes | Variable | Variable |
| emma-500-vllm-inference | Yes | Variable | Variable |
**Required Node Label:** `capability: gpu`
**Setup:**
```bash theme={null}
kubectl label nodes capability=gpu
```
## **Worker Node Requirements**
CPU-intensive services require worker nodes:
| Service | Memory | CPU |
| --------------------- | -------- | -------- |
| batch-worker-cpu-3pmt | 24G | 1 |
| Other batch workers | Variable | Variable |
**Required Node Label:** `node-type: worker`
**Setup:**
```bash theme={null}
kubectl label nodes node-type=worker
```
***
# **Troubleshooting**
## **LLM Inference Services Not Starting**
**Symptom:** LLM inference pods stuck in `Pending` state
**Solution:**
1. Verify GPU nodes are available:
```bash theme={null}
kubectl get nodes -l capability=gpu
```
2. Check GPU resources:
```bash theme={null}
kubectl describe nodes -l capability=gpu | grep nvidia.com/gpu
```
3. Ensure proper node labels:
```bash theme={null}
kubectl label nodes capability=gpu
```
## **Multimodal OCR Connection Issues**
**Symptom:** Multimodal service cannot connect to RabbitMQ
**Solution:**
1. Verify RabbitMQ credentials in `secrets.yaml`:
```yaml theme={null}
multimodal:
env:
MQ_PWD: ""
```
2. Check RabbitMQ connectivity:
```bash theme={null}
kubectl logs -n lilt deployment/multimodal-ocr
```
## **Batch Worker Memory Issues**
**Symptom:** Batch workers being OOMKilled
**Solution:**
1. Verify node capacity:
```bash theme={null}
kubectl describe nodes -l node-type=worker | grep -A 5 Allocatable
```
2. Increase memory if needed:
```yaml theme={null}
batch-worker-cpu-3pmt:
resources:
requests:
memory: 32G # Increase if needed
limits:
memory: 32G
```
## **ConfigMap/Secret Not Found Errors**
**Symptom:** Services failing with "configmap 'lilt-configmap' not found"
**Solution:**
Ensure the main Lilt chart creates these resources. Check your Helm templates include:
```yaml theme={null}
apiVersion: v1
kind: ConfigMap
metadata:
name: lilt-configmap
namespace: lilt
---
apiVersion: v1
kind: Secret
metadata:
name: lilt-secrets
namespace: lilt
```
## **S3/MinIO Connection Issues**
**Symptom:** Services cannot access S3/MinIO storage
**Solution:**
1. Verify S3 credentials in `secrets.yaml`:
```yaml theme={null}
core-api:
onpremValues:
env:
S3_ACCESS_KEY: ""
S3_SECRET_KEY: ""
```
2. Verify internal MinIO endpoint is accessible:
```bash theme={null}
kubectl exec -n lilt deployment/core-api -- curl -k https://minio.lilt.svc.cluster.local:9000
```
# Job Form Editor
Source: https://support.lilt.com/kb/Job-Form-Editor
The Job Form Editor allows you to customize your job submission experience with organization-wide custom job properties. This feature enables you to capture important metadata, such as billing codes, department information, PO numbers, or job identifiers, at the job level, ensuring consistent data collection across your organization.
## Who this is for
* **Admins** who configure job submission for an organization or a specific domain.
* Teams who need to collect consistent **job-level metadata** at submission time.
## What you can do in the Custom Job Form Editor
* **Show / hide** optional sections of the Job Submission flow (so submitters only see what they need).
* Configure **defaults** (for example, default language settings or whether Verified is the default).
* Add **job-level custom properties** to capture organization-specific tracking information.
* Configure at **two levels**:
* **Organization-level** (applies by default)
* **Domain-level** (overrides organization defaults for that domain)
## Where to find it
1. In the LILT platform, open **Manage**.
2. Select **Job Form Editor**.
3. Choose whether you’re editing the **Organization** form or a **Domain** form by using the Domain selector at the top of the page.
![Image]( "Image")
## How organization vs. domain configuration works
* **Organization form** defines the default job submission experience.
* **Domain form** can:
* Use the organization form as-is by selecting "Use organization form for this domain.", or
* Override which fields/steps are shown and which defaults apply for that domain.
![Image]( "Image")
### Recommended setup approach
1. Configure the **organization** form first.
2. Only create **domain overrides** when a domain truly needs a different submission experience.
***
# Configure your Job Submission form
## Step 1: Review required vs. optional sections
Some steps are always required for Job Submission (for example, file upload), while other steps can be optional depending on your organization’s setup.
In the Custom Job Form Editor:
* Ensure required steps are present.
* For optional steps, decide whether to:
* Show them to all submitters,
* Hide them entirely, or
* Make them conditional (if available in your deployment).
* PO Number and Invoice Split are populated for LILT services customers with information from their account, but can be hidden if not relevant.
## Step 2: Set defaults
Use defaults to minimize work for submitters and reduce incorrect submissions.
Common defaults include:
* **Instant vs. Verified** default behavior
![Image]()
* **Default source / target languages** (when applicable)
![Image]( "Image")
## Step 3: Add job-level custom properties
Custom job fields are best for metadata you want to capture *every time* a job is created. Custom properties added to a job will automatically propagate to all projects within that job. Common use cases include:
* **Internal billing and chargebacks**: Capture department codes or cost centers to allocate translation costs
* **PO number tracking**: Link jobs to purchase orders for procurement workflows
* **Project categorization**: Tag jobs by campaign, customer, or project type for better organization
* **Compliance tracking**: Record certification requirements or compliance flags
* **Multi-team coordination**: Identify which team or division requested the translation work
### Supported field types
Depending on your configuration, custom fields may include:
* **Text**
* **Checkbox**
* **Picklist / dropdown**
* **URL**
### Make a field required (optional)
If a field is required, submitters cannot complete Job Submission until it’s filled in.
![Image]( "Image")
### Important notes
* Custom properties only apply to jobs created **after** the property is defined. They are not backfilled to existing jobs.
* All user roles can see and use custom properties if they are enabled for your organization.
* If you delete a custom property, it will no longer appear during job creation, but historical data is preserved.
## Step 4: Save and publish
After making changes:
1. **Save / Publish** the form.
2. Start a **new** Job Submission to confirm the updated flow is displayed as expected.
***
# What happens after a job is created
## Where to see custom field values
Custom job field values are stored as job metadata and can be viewed on the job after submission in [Job Settings](https://support.lilt.com/kb/navigating-the-jobs-list#job-settings).
## Editing values after submission
If enabled in your deployment, you can edit job metadata after creation in Job Settings (useful when a PO number is issued later).
## Filtering and reporting
If enabled, jobs can be **filtered** using the custom fields configured in the Job Form Editor on the Jobs page. For example, filter by PO number, department, or other tracking fields.
***
# Troubleshooting
## I updated the form, but the Job Submission page didn’t change
* Confirm you edited the correct scope (**Organization** vs **Domain**).
* Confirm you **published** changes.
* Start a **new** job submission (changes may not apply to already-created jobs).
## A domain change affected other domains
Domain overrides should only apply to the selected domain. If you see changes leaking across domains, capture:
* Which domain you edited
* Which domains are unexpectedly affected
* A screenshot or short screen recording
…and report it to your LILT support contact.
## Job submission is blocked even though all fields look complete
* Check for a required field that is:
* Hidden behind a collapsed section, or
* Off-screen (scroll to the top and look for validation highlights)
* If quoting is enabled, confirm any quote-required steps are completed.
***
# Admin best practices
* Keep the submission form **minimal** for most domains; add complexity only where it drives real business value.
* Use **consistent naming** for custom fields so reporting and filtering remains clean.
* Avoid creating a custom field with the same name as a standard field (for example, “Status”) to prevent confusion.
# LILT MCP Server
Source: https://support.lilt.com/kb/LILT-mcp
## Introduction
Welcome to the LILT Model Context Protocol (MCP) Server!
By connecting your favorite AI clients—like Claude or ChatGPT— to LILT, you can bridge the gap between advanced LLM reasoning and LILT’s enterprise-grade translation capabilities. Instead of constantly switching tabs, you can now translate text and files, manage translation jobs, and access your organization's custom data sources directly within your active chat sessions.
Whether you're using Claude Desktop/ChatGPT Enterprise for a seamless UI experience or Claude Code to stay in your terminal, you can connect and start prompting in just a few minutes.
The LILT MCP (Model-Context Protocol) server integrates with LILT Enterprise APIs to provide translation capabilities within any harness that supports hosting MCP servers.
# Connecting Your Clients to LILT Enterprise MCP
## 1. Global Setup Overview
Regardless of which AI client you prefer, the core integration workflow always follows these four essential steps:
1. **Register the Server URL:** Client Configuration.
1. Add the secure LILT MCP endpoint to your client: [https://mcp-enterprise.lilt.com/mcp](https://mcp-enterprise.lilt.com/mcp)
2. **Authenticate Your Account:** OAuth Flow.
1. Follow your client's prompt to sign in with your enterprise LILT credentials to securely link your workspace permissions.
3. **Initialize the Session:** Fresh Start.
1. Always start a new chat session immediately after installation to force the LLM to scan and register the new LILT tools.
4. **Target Your Prompts:** Routing.
1. Explicitly include the word "LILT" in your initial prompts (e.g., *"Ask LILT to..."*) so the model knows to route the task to the MCP server.
## 2. Client-Specific Installation
Choose your preferred environment below to complete the step-by-step setup.
### Claude Desktop
1. Open **Claude Desktop**.
2. Click **Customize**, then navigate to **Connectors**.
3. Click the **Plus (+)** icon and select **"Add custom connector"**.
4. Configure the connector fields:
* **Name:** LILT
* **Remote MCP URL:** [https://mcp-enterprise.lilt.com/mcp](https://mcp-enterprise.lilt.com/mcp)
5. Click **Add**, then click **Connect**.
6. Complete the OAuth verification step using your LILT login credentials.
7. Send your first prompt to LILT via Claude Desktop!
### Claude Code (Terminal)
1. In your terminal, register the server by running:
claude mcp add --transport http LILT [https://mcp-enterprise.lilt.com/mcp](https://mcp-enterprise.lilt.com/mcp)
1. Start Claude code by running claude.
2. Run the /mcp command, select LILT, select “Re-authenticate”.
3. Complete the secure login flow in your browser using your LILT account.
4. Send your first prompt to LILT via Claude Code!
### ChatGPT Enterprise
1. Navigate to your workspace's MCP Settings or Admin console.
2. Select Add New Server (or Custom Connector).
3. Input the LILT MCP Server URL: [https://mcp-enterprise.lilt.com/mcp](https://mcp-enterprise.lilt.com/mcp)
4. Complete the OAuth verification step using your LILT login credentials.
5. Send your first prompt to LILT via ChatGPT!
# Account & App Distinction
LILT's MCP Enterprise Server connects directly to a user's pre-existing LILT account, providing the same permissions and access to models, data, content, and other enterprise functionality.
# Optimizely (fka EPIserver)
Source: https://support.lilt.com/kb/Optimizely
LILT's [Optimizely](https://www.optimizely.com/) connector enables companies to automatically send web content from Optimizely CMS and Commerce to LILT for translation, and receive completed translations back — without leaving either platform.
The connector is built as a **.NET NuGet package** (v2.1.0) that installs directly into your Optimizely instance and surfaces as a translation provider inside the native **Language Manager** UI. It supports Optimizely CMS 12 and Commerce 14.
> **Compatibility note:** The connector requires a code-managed Optimizely installation (self-hosted or DXP PaaS). It is **not compatible** with Optimizely SaaS CMS, which does not support NuGet add-ons. CMS 11 and earlier are also not supported.
***
## Supported Content Types
The connector handles translation for the following content types:
* **Pages** (CMS)
* **Blocks** (CMS) — both shared and local blocks
All relevant properties within each content type — such as SEO page titles and meta descriptions — can be individually included or excluded from translation. **Page names and URLs are excluded from translation by default** and will not be sent to LILT.
***
## How It Works
Once configured, the connector exposes LILT as a provider inside Optimizely's Language Manager. Users initiate translation from within Optimizely, and completed translations are returned as **drafts** for manual review before publication.
### Sending Content for Translation
Click the **Auto-Translate** button in the Language Manager gadget to send content to LILT. Language Manager passes the content's translatable properties to LILT as a batch, and LILT returns translations automatically.
> **Note:** The current connector supports **instant (AI) translation only**. Verified (human) translation workflows are not yet supported via this connector. If you require verified translation, contact your LILT account team.
### Receiving Translations
All translated content is returned to Optimizely as a **draft version**. It will not be auto-published — your team reviews and approves each translation before it goes live.
### Job Controls
* You **cannot submit a duplicate job** for the same content and language pair while a translation is already in progress. This prevents conflicting or redundant submissions.
* You **can** submit jobs for different language pairs on the same content simultaneously.
* If an error occurs, you will be notified via Optimizely's built-in notification system.
***
## Configuration
### Prerequisites
* Optimizely CMS 12 or Commerce 14, running on a self-hosted or DXP PaaS installation (not SaaS CMS)
* .NET 8 runtime
* A LILT API key (provided by your LILT account team)
### Installation
1. Add the `Lilt.Episerver.LanguageManager` NuGet package to your Optimizely project.
2. Register LILT services in your application startup:
```csharp theme={null}
builder.Services.AddLiltProvider();
```
3. Add the following to your `appsettings.json`:
```json theme={null}
{
"Lilt": {
"ApiBaseUrl": "https://connectors-admin.lilt.com",
"ApiBasePath": "/api/v1.0",
"TimeoutSeconds": 30,
"TranslationPollingTimeoutSeconds": 120,
"TranslationPollingIntervalSeconds": 2,
"AutoSyncOnPublish": true,
"DefaultFallbackLanguages": "fr,sv"
}
}
```
| Setting | Description |
| ----------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| `ApiBaseUrl` | Base URL for the LILT Connectors API |
| `TimeoutSeconds` | Request timeout for LILT API calls |
| `TranslationPollingTimeoutSeconds` | Maximum time to wait for a translation job to complete |
| `TranslationPollingIntervalSeconds` | How often to check for completed translations |
| `AutoSyncOnPublish` | When `true`, automatically copies property values from a published language to any configured fallback languages |
| `DefaultFallbackLanguages` | Comma-separated list of fallback language codes for content sync |
4. In the Optimizely Admin UI, go to **Tools → Language Manager**, select **LILT** as the translation provider, and enter your API key.
5. Under **Admin → Config → Manage Website Languages**, add and enable the target languages you want to translate into.
***
## Language Synchronization
When `AutoSyncOnPublish` is enabled, the connector includes a content sync handler that automatically copies property values from a published language version to any configured fallback languages. This is useful for ensuring fallback locales stay in sync without additional manual steps.
***
## Need Help?
Contact your LILT project manager or reach out via the [LILT Help Desk](https://lilt.atlassian.net/servicedesk/customer/portals) for setup assistance or troubleshooting.
# PII Omitted Segments
Source: https://support.lilt.com/kb/PII-Omitted-Segments
Linguists and translators can omit Personally Identifiable Information (PII) and other information during translation and review stages. Marking PII text in a segment will omit the segment from the Data Source (translation memory) and the PII information will not be available in document export for linguist and customer roles.
## How PII Omitted Segments works
* LILT will automatically identify and highlight data in segments that potentially contains PII at the beginning of a workflow stage. Linguists can also manually identify this information.
* Any segments marked as PII will not be saved into the Data Source.
* This data will be redacted in the final document export, unless the user is in an Admin role, in a Custom role with the relevant permission enabled, or if the delivery happens through a connector.
## PII org setting
This feature is controlled by a setting within Organization Settings. In order to trigger this workflow, the organization must have this turned on.
![Screenshot2026 01 20at12 18 05]()
## Automated PII identification
When you open CAT in any workflow stage, you will see a warning that the “File contains PII”, and that PII will not get saved to the data source. If you click to not show this warning in the future, then this pop-up will never appear again. The upper right corner will also show an orange “Omitted segments” alert.
![Image]( "Image")
![Image]( "Image")
If a segment has identified PII, there will be a chip at the bottom flagging that it will be omitted from the data source & AI training when segments are confirmed.
## Manual PII identification
Linguists can highlight and tag PII data manually if the data isn't automatically identified, or edit any automatically identified information. The segment will have tags that can be moved to identify where the PII starts/ends.
* To manually add PII identification, highlight the desired text in the editor (source or target). You will see an option in the dropdown to “Mark as PII”. Once marked as PII, the user should see a green toast notification showing that the selection was marked as PII.
* To edit or deselect a segment, click on the orange highlighted text and unmark the data as PII. Note: This can be done regardless of whether the segment was automatically or manually identified as having PII.
![Image]()
![Image]()
## Redacted file export
All non-Admin users will see anything marked as PII as redacted in the file export from the platform or via a connector.
## Non-redacted file export
If you need to export a document with full PII visible and not redacted, this can be done in two ways:
* When an Admin user exports a document with PII, the final export will contain ALL information (no redactions).
* If a Custom Role has the permission set to export PII data, then they will also be able to export a document with full PII visible. Please review the [Custom Roles page](https://support.lilt.com/kb/custom-roles).
![Image]( "Image")
# Secure File Delivery
Source: https://support.lilt.com/kb/Secure-File-Delivery
The Secure File Delivery feature allows you to deliver files that require post-processing (such as Desktop Publishing, multimedia files, or other manually processed content) directly to customers through LILT, maintaining data security and compliance.
## How it works for Customers
1. Specify that you need files formatted before delivery when you create your job in LILT. You can do this through the "Additional Options" button at the bottom of the job submission page, by toggling "**Format all translated files before delivery**" on. Having this setting on will ensure that the job will enter a Post-Processing stage once translation is complete.
![Image]( "Image")
* Alternatively, if you miss or forget to set this during job creation, you can configure this by going to Job Settings and toggling on.
2. LILT will translate and perform any necessary post-processing on your files (including Desktop Publishing, voiceover work for multimedia files, and more).
3. You will receive an email delivery notification when your language-specific projects have been delivered. Click on "**View documents**" to take you directly to the LILT platform.
![Image]( "Image")
4. This link will take you to the "**Files for Delivery**" tab within LILT, where you can download all post-processed files at the project level.
## How it works for Internal Production Teams
1. If the setting has been turned on, the project status will automatically transition to "**Post-processing**" once all translation and review stages are complete.
1. If a customer doesn't set this during job creation, you can configure this by going to Job Settings and toggling on.
![Image]()
2. Perform any necessary processing offline and prepare the files for the customer.
3. Navigate to the project within LILT and select the "**Files for Delivery**" tab. Click "**Upload files**".
* \*Note: This tab is only visible when the "\****Process translated files before delivery***\_" setting is on. \_
4. Upload one or more files (including .zip files and other supported formats).
* LILT supports multiple file types, including .zip files.
* Files up to 20GB are supported.
* If you upload files with duplicate names, they'll be automatically renamed with a counter.
![Image]()
5. Once all the processed files are uploaded, click "**Deliver**" on the project in the upper right hand corner. The project status will automatically change from "Post-processing" to "Done", and this will trigger an email notification to the customer who created the job letting them know their files are ready for download.
* You will see a warning if you attempt to deliver a post-processing job without uploading any files. If you proceed, the project will be delivered and the customer will receive the delivery email.
![Image]( "Image")
6. When all projects in the job are Done, the job status will also transition to "Done".
### Important Notes
* If post-processing is **disabled**, jobs are automatically delivered when all translation stages are complete.
* If post-processing is **enabled**, manual file upload and delivery by a Production Manager is required.
# Unified Job Submission
Source: https://support.lilt.com/kb/Unified-Job-Submission
Unified Job Submission is LILT's streamlined, intelligent workflow automation within the platform that removes the guesswork from translation job submission. This completely reimagined, easy-to-navigate job submission experience empowers every user to self-serve with confidence. It automatically detects uploaded file types, routes to appropriate translation workstreams, applies the right models, and guides users through job submission steps. This simplifies complex translation task configuration and drastically saves time.
## How it works
1. Start by uploading the files you need to translate. The system automatically detects file types, routing all file types to the appropriate translation work streams and processing steps.
2. The system will automatically detect the source language (if text-based), and surfaces the right models approved for the domain and user, eliminating the risk of submission errors.
3. Choose your workflow, instant for AI-only translations, or expert verified workflows for a review by LILT experts.
4. The streamlined UI then steps you through to input relevant job-level details, such as job instructions for expert reviewers, or custom job requirements set up by your organization.
5. If configured, LILT's quoting options will allow you to get quotes offline or instantly to get an estimate of how much it will cost. Once you're good with the estimate, click send for translation.
For detailed instructions, please reference the below pages.
* [Verified Translation](https://support.lilt.com/kb/Verified-Translation)
* [Instant File Translation](https://support.lilt.com/kb/instant-translate-documents)
* [Instant Text Translation](https://support.lilt.com/kb/instant-translate-text)
* [Instant Video Dubbing](https://support.lilt.com/kb/instant-video-dubbing#instant-video-dubbing)
* [Subtitling and Captioning](https://support.lilt.com/kb/subtitling-and-captioning)
* [PDF and Image File Translation](https://support.lilt.com/kb/pdf-image-file-translation)
* [Audio File Translation](https://support.lilt.com/kb/audio-file-translation)
* [Custom File Filters](https://support.lilt.com/kb/lilt-file-loaders)
* [Quoting](https://support.lilt.com/kb/quoting-in-lilt)
* [Job Form Editor](https://support.lilt.com/kb/Job-Form-Editor)
# Verified Translation
Source: https://support.lilt.com/kb/Verified-Translation
This page outlines a step-by-step guide for submitting content for translation.
## LILT Verified translation
The **Translate files** tab allows you to submit files for translation. This section outlines step-by-step guidance to send content to LILT for an expert-verified translation.
![Image]()
1. Upload or drag and drop the files you want to send for translation.
1. LILT will automatically generate a title for your new job based on the files uploaded. To edit the auto-generated name, click on the pencil icon in the bottom left corner.
2. Set your source and target languages. The system will automatically detect the source language (if text-based), and surfaces the right models approved for the domain and user, eliminating the risk of submission errors.
3. Toggle "Receive an expert-verified translation" on to send your content to a LILT-verified workflow. Toggle whether you want to review the text yourself before delivery (Customer Verification), and optionally assign a reviewer from users within your domain and organization.
* Those in an admin role will also be able to select a workflow. Anyone not in an admin role will use the default model defined for your organization.
* To assign a reviewer from users within your domain and organization, you will need to be in a Customer, Manager, or Admin role, or in a [Custom Role](https://support.lilt.com/kb/custom-roles) that has the "Assign Reviewer" permission set.
4. Click next, or scroll down to Job details.
5. Add job details, including job-level instructions, reference materials, any job-level custom properties, and a desired due date. \_Note: LILT will automatically populate a due date based on your contract-defined Service Level Agreement and the word count. \_
![Screenshot2026 01 07at12 40 40 1]()
6. Scroll down to the quote component. LILT will automatically generate a quote for your submission based on the word count, number of languages, and your price per word.
* You can optionally request an [official quotation](https://support.lilt.com/kb/quoting-in-lilt#offline-quoting) if you want a quote for a job that would include offline work, such as pre- or post-processing, or if you would like to have a stakeholder approve the quote before translation begins.
![Screenshot2026 01 07at15 14 49]()
7. Under additional options, you can identify whether you want files formatted before delivery (post-processed), whether you want [ICU Plurals](https://support.lilt.com/kb/cat-icu-plurals) enabled, and you can add language-specific instructions as needed.
1. For PDF and image files, you can also enable **Review extracted text before translation**, which pauses the job after processing so you (or an assigned reviewer) can verify the text LILT has extracted from your PDFs or images— particularly useful for scanned documents.
2. Those in an admin role will also be able to change the selected model per language here as well. Anyone not in an admin role will use default models set by your organization.
![Screenshot2026 01 07at15 19 01]( "Screenshot2026 01 07at15 19 01")
8. Click "Submit" to send your job for creation.
# Accepting Document Assignments
Source: https://support.lilt.com/kb/accepting-document-assignments
When a project manager assigns you as the translator or reviewer of a document (as described in the [Document Actions](/kb/document-actions) article), you will receive an email notification from [Jobs list](/kb/navigating-the-jobs-list).
From the Jobs list, you can open the job and project to browse the assigned documents, and then accept or reject each assignment (individually or in batches). To batch accept/reject, select each document you want to accept/reject (or click the `Select all documents` button at the top), then click `Accept selected` or `Reject selected`.
![]()
You can also accept or reject assignments directly from the email notification by clicking on the `Accept all` / `Reject all` buttons or the check ![]()
/ cross ![]()
buttons next to each document.
![]()
## Ready for review notification
When documents have been marked as done in translation, the assigned reviewer will be notified (both by email and in the application) that the document is ready for review. Reviewers will only receive these notifications if they have accepted the assignment before the document has been marked as done in translation.
**Application notification:**
![]()
**Email notification:**
![]()
# Access To MongoDB
Source: https://support.lilt.com/kb/access-to-mongodb
## MongoDB
### Workaround Steps
The steps listed in this Workaround Steps section have been fixed in the release coming out in April, so this workaround is not needed if you have installed the April release.
The currently shipped MongoDB chart needs to be edited to support connection to the mongo database. This can be done by starting from the install\_dir/charts directory and following the steps below:
Extract the mongo chart like:
```bash theme={null}
tar xvf mongodb-13.15.5.tgz -C .
```
1. Edit the \*MONGODB\_CLIENT\_EXTRA\_FLAGS \*value in \*templates/standalone/dep-sts.yaml \*to include *–tlsAllowInvalidHostNames*. The resulting value will look like the image shown below:
2.
![]()
3. Save the file.
4. From the install\_dir/install\_scripts directory, run below command which will reinstall mongodb with the connectivity set up.
```bash theme={null}
sh install-mongodb.sh
```
### Connecting within the Cluster
In order to connect within the cluster, you can run the following commands:
Connect to the pod in the cluster:
```bash theme={null}
kubectl exec -it -- /bin/sh
```
Run the command to connect and provide credentials:
```bash theme={null}
mongosh admin --host 127.0.0.1 --authenticationDatabase admin -u root $MONGODB_CLIENT_EXTRA_FLAGS
```
You should now be authenticated into the database and can switch to the database you want to query using:
```bash theme={null}
use lilt_prod;
```
You can also list the collections of interest using the command to display the AuditLogs collections that can be queried further.
```bash theme={null}
show collections;
```
### Connecting from outside the Cluster
#### Caveat
We currently have to specifically allow invalidHostNames for mongodb to allow TLS connection from outside the cluster. We are in the process of testing certificates created and passed with TLS so that we can remove this flag. This flag can be passed when using the mongosh client from outside the cluster but may not be supported from other clients unless they have a similar flag. We will provide an update on a solution for this soon.
#### Steps
Connecting from outside the cluster is similar from connecting within the cluster except for the changes listed below:
Edit the mongodb service so that it runs as a NodePort type of Kubernetes service that can be accessed from outside the cluster. You can run this command to do that:
```bash theme={null}
kubectl edit svc mongodb
```
1. In the resulting file that opens, change the *type* field of the service from ClusterIP to NodePort. Also, under the ports section, add a new field for *nodePort*. Please use a 5 digit value above 30000 for nodePort value to prevent port conflicts. See the example below:
1.
![]()
2. Save the file and exit. This will automatically redeploy the service and expose it as a nodePort service. You can describe the service to confirm that its type is now NodePort using:
```bash theme={null}
kubectl describe svc mongodb
```
1. Setting up certificates for authentication. Authenticating requires passing certificate files which can currently be retrieved from the mongodb pod as shown below:
1. mongodb.pem: Exec into the pod as described above and save the contents of the */certs/mongodb.pem* file into a local file that we will refer to as mongodb.pem below.
2. Save the contents of the \*/certs/mongodb-ca-cert \*file into a local file that we will refer to as ca-file below.
2. With the service type setup and cert files available locally, you should be able to connect to the mongodb service from any machine that has connectivity to the cluster’s node worker’s IP address using the command:
```bash theme={null}
mongosh admin --host --port --authenticationDatabase admin -u root -p --tls --tlsCertificateKeyFile --tlsCAFile --tlsAllowInvalidHostnames
```
This should set up connectivity and allow for interaction with the MongoDB as shown from within the cluster above.
# Adding Users To An Organization
Source: https://support.lilt.com/kb/adding-users-to-an-organization
Managers and Administrators have the ability to add users to an organization. Note that managers cannot add administrators.
To add a user to your organization, navigate to the `Manage > Users` tab.
![]()
Use the New User button in the top right corner of the page to invite team members to join the LILT Platform. Input the email address(es) of the user(s) you want to add and assign roles to each, respectively.
![]()
Once you have added emails and selected roles for all the users you want to add, click the `Invite` button to invite them to the organization. This will send an email from [info@lilt.com](mailto:info@lilt.com) to each user with instructions for setting up their LILT account.
![]()
After a user has accepted your invitation and set up their account, they will appear on the `Users` page with their `Name` populated (if available). Users can set their display name on the [Account](https://lilt.com/app/account/settings/profile) page. This view will also display which domains (if any) a user has been added to.
![]()
## Settings
Settings for users in your organization can be configured from the Settings page.
* **Require full name:** Make full name mandatory for members of the organization.
* **Require timezone:** Make timezone mandatory for members of the organization.
![Screenshot2025 08 20at15 24 27 Pn]()
# Adobe Workfront
Source: https://support.lilt.com/kb/adobe-workfront
[Adobe Workfront](https://business.adobe.com/products/workfront.html) is a work management platform for planning, tracking, and executing marketing and creative projects. It supports intake forms, task assignments, timelines, approvals, and reporting, often connected to creative tools and asset repositories.
## Overview
Once all configuration parameters are set, the connector will be able to:
* Allow users in the LILT platform to select files from Adobe Workfront for import into LILT translation workflows
* Preserve key metadata fields during file import
* Deliver translated files to the original project folder in Workfront
## Configuration
Create a Workfront OAuth application:
1. In Workfront, go to **Setup**.
2. Navigate to **System** → **OAuth Applications**.
3. Click **+ Create App Integration**.
4. Choose **Web Application** and give it a name.
5. Click **+ Add Client Secret** and copy the generated value.
6. Add the following redirect URL and save:
* [https://connectors-admin.lilt.com/configuration-api/v1.0/platform/oauth/workfront/redirect](https://connectors-admin.lilt.com/configuration-api/v1.0/platform/oauth/workfront/redirect)
To complete your configuration, share the following details with your Solutions Architect at LILT:
* Workfront domain
* Workfront client ID
* Workfront client secret
# AEM
Source: https://support.lilt.com/kb/aem
LILT's connector for [Adobe Experience Manager](https://www.adobe.io/apis/experiencecloud/aem.html) (AEM) enables companies to automatically push and pull web content between AEM and LILT for translation. The connector supports both **AEM 6.5 (on-premise)** and **AEM as a Cloud Service (AEMaaCS)**.
Once installed, content authors can create translation submissions directly from the **Lilt Translations** app within AEM — selecting pages, assets, tags, and target languages — and the connector handles sending content to LILT and importing completed translations back into AEM.
As of connector version 1.8, repositories can operate in one of two modes: **JCR Properties** (the standard page, content fragment, and property/metadata flow) or **DAM Asset Content** (translating binary document files directly). See [Translating DAM Asset Content](https://support.lilt.com/kb/aem#translating-dam-asset-content) for details.
## Supported Content Types
| Content Type | AEM 6.5 | AEMaaCS |
| ---------------------------------------------------------------------------------------------------------------- | ------- | ----------- |
| Content Pages | ✅ | ✅ |
| Experience Fragments | ✅ | ✅ |
| Experience Fragment Variants | ✅ | ✅ |
| Content Fragments | ✅ | ✅ |
| Content Fragment Variants | ❌ | ✅ (v1.5.0+) |
| Assets Metadata | ✅ | ✅ |
| Tags (referenced)
Tags attached to a submitted page | ✅ | ✅ |
| Tags (standalone)
Tags submitted on their own, no page required — see [Translating Tags](#translating-tags) | ❌ | ✅ (v1.12+) |
| DAM Asset Content (html, txt, docx, pptx, xlsx) | ❌ | ✅ (v1.8.0+) |
**Assets Metadata** and **DAM Asset Content** are different things. *Assets Metadata* translates the JCR properties attached to an asset (title, description, etc.). *DAM Asset Content* translates the binary file itself (`.docx`, `.xlsx`, `.pptx`, `.txt`, `.html`) and is configured on a dedicated DAM Asset Content repository.
## Installation
Installation methods depend on your AEM environment. In both cases, contact your LILT account team to obtain the connector package and the appropriate version for your environment.
Check with your LILT account team for the latest connector version.
### AEM as a Cloud Service
For AEMaaCS, the connector package must be deployed through your source code repository. AEM Cloud Service only allows one repository to be deployed at a time, so the LILT connector package must be embedded into your project's `all` package.
There are two deployment options:
**Option 1: Maven Dependency**
This method links your AEM project to the LILT connector repository via Maven. At a high level:
1. Create a GitHub Personal Access Token with `repo` and `write:packages` scopes.
2. Add a Maven settings file (`.cloudmanager/maven/settings.xml`) with your GitHub credentials.
3. Add the LILT connector repository and dependency to your root `pom.xml`.
4. Add the dependency and embedded package configuration to your `all/pom.xml`.
5. Deploy via Cloud Manager.
Your LILT account team will provide the specific repository URL, artifact coordinates, and version number to use.
**Option 2: Local Package File**
If you prefer not to connect to the Maven repository, you can deploy from a local copy of the connector package:
1. Obtain the connector `.zip` file from your LILT account team.
2. Create a `local-repo` directory in your AEM project and copy the package there.
3. Add a local repository reference to your root `pom.xml`.
4. Add the dependency and embedded package configuration to your `all/pom.xml`.
5. Commit the `local-repo` directory and deploy via Cloud Manager.
### AEM 6.5 (On-Premise)
For AEM 6.5, there are two installation methods:
**Option 1: Manual Package Upload (Quick Setup)**
1. Obtain the connector `.zip` file (e.g., `lilt-connector.all--6.5.zip`) from your LILT account team.
2. Log into your AEM Author instance and navigate to **Tools** > **Deployment** > **Packages** (or access Package Manager directly at `http://:/crx/packmgr/index.jsp`).
3. Click **Upload Package**, select the `.zip` file, and click **OK**.
4. Locate the uploaded package in the list and click **Install**.
5. Keep the default installation settings and click **Install** to confirm.
The connector package installs 4 components. Verify all 4 are successfully installed. If upgrading, uninstall the previous version before uploading the new package.
**Option 2: Maven Deployment**
Follow the same Maven approach as AEM Cloud Service Option 1, with two key differences:
* Use the `-6.5` version classifier (e.g., `1.5.0-6.5` instead of `1.5.0-cloud`).
* In `all/pom.xml`, use `` instead of `` in the `filevault-package-maven-plugin` configuration.
### Verifying Installation
After installation completes on either environment:
1. Check that the package status shows as **Installed** in Package Manager.
2. Navigate to the AEM Apps view.
3. Verify that the **Lilt Translations** app appears in the apps list.
## Configuration
After installing the connector, you must complete configuration on both the LILT side (Connectors Builder) and the AEM side (Lilt Translations app) before you can submit content for translation.
### Step 1: Set Up the Connector in Connectors Builder
The AEM connector must be configured with support from LILT's technical support team using Connectors Admin and Connectors Builder — not through the AEM UI alone.
1. Have your LILT technical point-of-contact generate a new API token for this connector in connectors admin and save it — you'll need it for the AEM configuration.
2. Give your LILT technical point-of-contact the list of languages (and models/data sources if applicable) you would like to use for translation. They will configure these in your LILT Connectors Builder.
### Step 2: Access the Lilt Translations App
1. Open your AEM instance.
2. Navigate to the **AEM Apps** view.
3. Click on the **Lilt Translations** app.
This is your main interface for configuring the connector. **Both the Configurations and Repositories sections must be set up before you can create any translation submissions.**
### Step 3: Configure General Settings
Navigate to **Configurations > General** and enter the following:
| Setting | Value |
| ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Web Services URL** | `https://connectors-admin.lilt.com/api/v1.0` |
| **Lilt API Token** | The token you generated in Connectors Admin |
| **Scheduler Period (Minutes)** | How often AEM should poll the LILT API for completed translations (e.g., `15`) |
| **Nested content fragment max depth** | How many levels deep the connector will follow content fragment references when "Translate nested content fragments" is enabled. Default: `5`. Allowed range: 1–20. |
You will also need to configure the **Translate Assets** setting, which controls how images, documents, and other digital assets are handled during translation. **This setting applies to JCR Properties repositories only** — it has no effect on DAM Asset Content repositories, where the file itself is always the translated output.
* **Clone asset to target language**: Creates a separate copy of each asset for every target language. Use this if you need different asset versions per language.
* **Append translatable fields to existing asset**: Keeps a single copy of each asset and adds translated metadata (title, description, etc.) for each language. Use this to manage all language versions in one place.
### External Locale Mapping
**Relevant for tag translation only.** Some AEM instances expect language codes that differ from the codes LILT uses (for example, LILT `no-NO` maps to AEM `nb_NO`). Add any such discrepancies to the **External Locale Mapping** field so translated content is written back under the code AEM expects. This is a global setting that applies to all submissions. Compare the codes before translating into a new language, especially Norwegian and Chinese.
### Step 4: Configure Proxy Settings (Optional)
If your organization requires outgoing traffic to go through a proxy server, navigate to **Configurations > Proxy** and enter the proxy host, port, and credentials. Enable the proxy toggle to activate it. Most users can leave this section blank.
### Step 5: Configure Auto-Archiving (Optional)
Navigate to **Configurations > Auto-Archiving** to automatically archive old or completed translation jobs. You can set the frequency (Never, Weekly, or Monthly) and choose which job statuses should be archived (e.g., Completed, Failed, Canceled). This is especially helpful for teams with a high volume of translation jobs.
### Step 6: Configure Functionality
Depending on the version of AEM you are currently running, you will have access to a functionality tab which modifies the default views and functionalities available in repositories and job submission.
![Screenshot 2026 05 13 At 9 55 53 Am]()
### Step 7: Create a Repository
A **repository** defines which content in AEM is available for translation and how it should be processed. You must create at least one repository before you can submit content for translation.
Navigate to **Repositories** and click **Create New Repository**.
#### Basics
* **Content Type**: Determines how the repository translates content — **JCR Properties** (default; pages, content fragments, and properties/metadata) or **DAM Asset Content** (binary document files). This is **locked after the repository is created** and cannot be changed later. See [Translating DAM Asset Content](https://support.lilt.com/kb/aem#translating-dam-asset-content).
To translate tags on their own, point a **JCR Properties** repository at a `cq:tags` path (the root or a specific namespace). Only `jcr:title` and `jcr:description` are translated for tags, regardless of the repository's configured properties, and transformation and link rewrite rules do not apply. See [Translating Tags](#translating-tags).
* **Name**: A friendly name for your repository (e.g., "Main Site").
* **Path**: The root path in AEM where translatable content lives (e.g., `/content/wknd`). Only content under this path will be available for translation through this repository. *For DAM Asset Content repositories, this path is constrained to* `/content/dam`*.*
* **Default Submission Status**: The initial status for new submissions — `NOT_READY` (requires review before sending) or `READY` (can be sent immediately).
* **Submission Name Pattern**: A template for how submission names are generated (see [Submission Pattern Name](#submission-pattern-name) below).
* **Deliver to Launch default (v1.10+, AEM as a Cloud Service).** For repositories translating Sites pages and Content Fragments, you can set a default for Deliver to Launch at the repository level. Authors can override the default on individual submissions. This setting has no effect on DAM Asset Content repositories, which cannot deliver to Launches.
#### Translation Rules
**Transformation Rules** define how source content paths and languages map to target locations. These paths are **case sensitive**. Each rule maps a source path to a target language and target path:
```text theme={null}
/content/site/en > de:/content/site/de
/content/site/en > fr:/content/site/fr
/content/site/en > es:/content/site/es
```
##### **Transformation Rule Validation**
Starting with AEM Cloud connector version 1.7.0, the connector can validate your transformation rules at key points in the workflow — when saving a repository and when starting a submission — so configuration issues are caught before content is sent for translation. To enable this functionality, you will need to toggle on the following functionalities in the configurations modal.
* Validate submission transformation rules
* Validate content path
* Restrict rule languages to domain
* New design experience
##### **What Gets Validated**
* **When saving a repository**, the connector checks that your transformation rules are well-formed and that source paths map to valid target language and path combinations.
![Screenshot 2026 05 11 At 3 28 36 Pm]()
* **When starting a submission**, the connector checks that every content path in the submission has a matching transformation rule for each selected target language. If a target language is missing a rule, the connector will flag the issue and suggest how to resolve it — for example, by adding the missing language mapping to your repository's transformation rules.
![Screenshot 2026 05 11 At 3 36 23 Pm]()
##### **Redesigned Transformation Rules Editor**
Alongside validation, cloud version 1.7.0 includes a redesigned transformation rules editor in the repository configuration. The new editor provides a clearer view of your source-to-target path mappings, making it easier to spot gaps and configure rules correctly.
##### **Disabling Validation**
If your setup uses custom content structures that don't follow standard path conventions, you can disable path validation in the 'Configurations> Functionality'. In most cases, we recommend keeping validation enabled.
**Link Rewriting Rules** (optional) control how internal links are rewritten during translation to point to the correct target-language pages:
```text theme={null}
content@href="@html"@*
text@href="@html"@*
```
**Translate Properties** specify which AEM properties (like `jcr:title`, `jcr:description`, etc.) should be included for translation. You can also set optional character limits:
```text theme={null}
jcr:title@*
jcr:description@*@50
text@*
```
**Do Not Translate Properties** lets you exclude specific content paths or resources from translation:
```text theme={null}
/content/site/en/secret-page
/content/site/en/drafts/*
```
On **DAM Asset Content** repositories, **Link Rewriting Rules**, **Translate Properties**, and **Translate Content Fragment Variations** are hidden, because they only apply to property-based content. **Transformation Rules** still apply and determine where translated files are delivered.
#### Automation (Optional)
If you want translation submissions to be created automatically on a schedule, configure the automation time, frequency (daily or weekly), and other submission parameters. Select "Don't send automatically" to disable this feature.
Automation is **not available for DAM Asset Content repositories** **or tags as a standalone content type** — the Automation tab is hidden for them and they must be started manually, even when the default submission status is `READY`.
## Submitting Content for Translation
Once configuration is complete, you can create translation submissions from the **Lilt Translations** app in AEM.
### Creating a Submission
Navigate to **Submissions** and click **Create New Submission**. The submission wizard has three steps:
![Screenshot 2026 05 11 At 5 14 45 Pm]()
**1. Job Setup**
* **Submission Name**: A name to identify this submission in the list.
* **Repository**: Select which repository to use (determines available content and rules).
* **Project Name**: Select the domain from your LILT organization.
* **Source Language**: The language of the original content (filtered by the selected domain).
* **Target Languages**: One or more languages to translate into (filtered by domain and source language with Cloud 1.7).
* **Due Date** (optional): Set a deadline for the translation.
* **Purchase Order / JIRA Ticket** (optional): Add tracking or billing information.
* Choose whether to translate **assets** and **referenced tags** alongside pages. Referenced tags are the tags attached to the pages in this submission. To translate tags on their own, see [Translating Tags](#translating-tags).
* *These options apply to JCR Properties repositories. On DAM Asset Content repositories, the **Translate Asset Metadata** and **Translate Tags** options are hidden, since only the file itself is translated, and the content picker is rooted under* `/content/dam `*and limited to supported file types.*
* If your repository supports it, a **Deliver to Launch** option appears on this step. Set it before selecting content; it applies to the whole submission. It defaults to the repository's configured value and can be overridden here per submission.
### Translating Nested Content Fragments
Available in v1.9+. This option automatically discovers and includes referenced content fragments when you create a submission.
To use it, check **Translate nested content fragments** in the Job Setup step of the submission wizard.
When enabled:
* Select a Sites page or parent content fragment as usual in the Content step.
* The connector automatically adds any linked content fragments to the submission.
* Discovered fragments appear in the content table grouped under the item that references them, so you can see which fragments were pulled in from which path.
* Removing a seed path also removes its auto-discovered nested fragments.
Discovery runs when you advance from the Content step (and again at submit), and discovered fragments are included in transformation rule validation, the send pipeline, and the Review step.
**Configuring nesting depth**
Administrators can set the maximum reference depth at **Configurations > General > Nested content fragment max depth** (default: 5, range: 1–20). This limit applies consistently across the wizard, path validation, and the send pipeline.
**Requirements and limitations**
* Available for JCR Properties repositories only — not shown for DAM Asset Content repositories.
* Transformation rules must cover every discovered fragment path and target language. If a nested fragment has no matching rule, validation will flag it the same way as any other unmatched path.
* The option is off by default and must be enabled per submission.
**2. Content Selection**
* **Content Paths**: Choose the path(s) to send for translation.
* **Include Children** (optional): Include all subpages under the chosen path, so you can translate an entire section at once.
* For tag folders, "Include Children" does not apply — selecting a tag folder
automatically includes every tag within it.
**3. Review**
* Review all selections — job details, content, and settings.
* Go back to previous steps if changes are needed.
* When Deliver to Launch is on, the Review step shows the date-based Launch folder that will be created (`/content/launches/YYYY/MM/DD//…`) so you can confirm the destination before submitting.
* Click **Save Submission** to create the submission.
### Starting a Submission
After saving, the submission appears in the submissions list. To send it for translation:
1. Click the submission to view its details.
2. Review the selected content, languages, and settings.
3. Click **Start Submission** to send the job to LILT.
4. The status will update as the job progresses: `SENDING` → `IN_PROGRESS` → `COMPLETE`.
### Importing Translated Content
Once the translation is complete, import the results back into AEM:
1. When the submission status shows **Import Complete**, the **Reimport Content** button becomes available in the submission detail view.
2. Click **Reimport Content** to bring the translated pages, assets, and tags into your AEM instance.
3. The connector places translations according to your repository's transformation rules.
## FAQ / Troubleshooting
* Verify the package was installed successfully in Package Manager and that all 4 components are present.
* Check that the package status shows as **Installed**.
* Restart AEM and check again.
* Review AEM error logs for installation issues.
* Verify the Web Services URL is exactly: `https://connectors-admin.lilt.com/api/v1.0`
* Check that the API token is correct and has no extra spaces.
* Confirm the token was generated in Connectors Builder for this specific connector.
* Test network connectivity from your AEM instance to `connectors-admin.lilt.com`.
* Check that firewall rules allow outbound HTTPS traffic.
* If using a proxy, verify the proxy settings in the connector configuration are correct.
This may indicate a sync issue between AEM and LILT. Contact your LILT account team for support, or submit a request through the [LILT Help Center](https://lilt.atlassian.net/servicedesk/customer/portal/3).
Check your repository's **Transformation Rules**. Ensure the source path and target language codes match your AEM content structure. For example, if your English content is at `/content/site/en`, verify the rules correctly map to the expected target paths like `/content/site/de` or `/content/site/fr`.
* Verify your **Translate Properties** configuration includes all the properties that need translation.
* Check that the content you submitted is under the correct source language path defined in your transformation rules.
Contact your LILT account team immediately for cancellations. They can cancel the job in LILT and help you clean up the submission in AEM.
Notify your LILT account team of any source changes. They will work with you to ensure the correct content is translated and returned.
Contact your LILT account team. If a delivered project requires changes, they will walk you through the process to cancel the submission in AEM so that LILT can redeliver the files after implementing your modifications.
As of connector version 1.10, LILT's connector can deliver translations into AEM Launches. See **Deliver to Launch** below. (Launch delivery is available on AEM as a Cloud Service, for Sites pages and Content Fragments.)
LILT runs weekly cleanup jobs in the LILT + AEM connector and removes projects older than 45 days. This is built to address an AEM limitation where an item in the JCR can have no more than 10k child nodes.
This is expected, not an error. **"See all (Y)"** counts the AEM content paths a user selects; the imported count only considers the translatable content imported into LILT which likely differs from all content selected. (files × target languages, after bundling and filtering). The connector consolidates asset metadata into single files (Append mode), bundles all tags into one file, and skips paths with no translatable content. A completed **X/X** means the submission finished successfully — no content was dropped silently. If you believe specific content is genuinely missing, contact your LILT account team to review that submission.
## Submission Pattern Name
When you create or edit a repository, you can create or modify the naming conventions of the submission name.
You can add the following variables to the submission name, making sure they are surrounded by curly brackets:
* **today** — Today's date, formatted as YYYY-MM-DD.
* **filename** — The name of the current file being uploaded.
* **project\_prefix** — The `project_prefix` value provided in the configuration.
* **project\_name** — The `project_name` value assigned to the file in the code.
* **connector\_id** — The Connector ID.
* **connector\_type** — The Connector Type (e.g., "aem").
* **path\_names\[index]** — Specifies the name of the directory at the given level above the file being uploaded. The index corresponds to the directory level, starting from 0 for the file itself. For example, given the filename `en-US/fr-FR/file.txt` and the template option `path_names[2]`, the result will be `en-US`, as it is the second-level parent directory above the file.
### Deliver to Launch (v1.10+)
By default the connector writes returning translations straight to the live target page. **Deliver to Launch** instead routes them into an AEM Launch — a synced, staging copy of the content — so your team can review the translation and promote it to the live page manually. The live page is never touched until you promote the Launch.
This is useful when a page may be edited during the translation cycle: because the translation returns into the Launch rather than the live path, in-flight edits to the live page are never overwritten.
**Availability**
* AEM as a Cloud Service only.
* Sites pages, Experience Fragments and Content Fragments. Not available for DAM assets.
**Turning it on**
* *Per submission:* On the submission Setup step, toggle **Deliver to Launch** on before selecting content. The setting applies to the whole submission.
* *Repository default:* Administrators can set a default for Deliver to Launch in the repository configuration (see *Repository configuration* below). Authors can override the default on any individual submission.
**What the connector does automatically**
* Creates the AEM Launch and the per-language paths at submission time — you don't need to pre-build Launches or target-language paths.
* Creates one Launch per page per language (languages are not bundled into a single Launch).
* Uses date-based Launch paths: `/content/launches/YYYY/MM/DD//…`. The assigned Launch folder is shown on the Review step before you submit.
**Delivery, reimport, and promotion**
* Both the initial delivery and any reimport write into the Launch, not the live path.
* Reimporting overwrites the existing content in that Launch. If the expected Launch folder already exists, the connector reuses it; otherwise it creates it.
* **Promotion is a manual, native AEM action.** The connector does not promote or auto-promote. Review the content in the Launch, then promote the Launch to live using standard AEM authoring when you're ready. Publish as normal after that.
**Good to know**
* A submission keeps whichever Launch option it was created with. Changing the repository default later does not change in-flight submissions (including their reimports) — only new submissions.
* If the live target-language page does not yet exist, that content delivers to the live path even with Deliver to Launch on, because there is no existing live content to protect.
* **Content Fragments:** adding Content Fragments to Launches can cause version-control issues, particularly with fragments that reference other fragments or assets. This is a known behavior of AEM Launches, not of the connector, so take care when using Launch delivery for heavily-referenced Content Fragments.
* When Deliver to Launch is enabled for a submission, the submissions table shows this per submission. The indicator is a button that opens the full list of Launch paths the submission uses.
## Translating DAM Asset Content
Starting with **AEM Cloud connector version 1.8**, the connector can translate **assets** stored in the AEM Digital Asset Manager (DAM) — Word, Excel, PowerPoint, plain text, and HTML files — by sending the original file to LILT and writing the translated file back into AEM.
This is a separate pipeline from the standard page/property translation flow. It is intended for customers who want to translate document assets directly, rather than pages, content fragments, or asset metadata.
DAM Asset Content translation is configured at the repository level using a new Content Type setting. A single repository is either a JCR Properties repository (the existing flow) or a DAM Asset Content repository — not both.
### Supported File Types
DAM Asset Content repositories support the following binary file types:
| File Type | Extension |
| :--------- | :-------- |
| Word | `.docx` |
| Excel | `.xlsx` |
| PowerPoint | `.pptx` |
| Plain text | `.txt` |
| HTML | `.html` |
The content path picker only allows selection of these supported file types. Other asset types (images, PDFs, etc.) are not selectable in a DAM Asset Content submission.
### Setting the Content Type on a Repository
When you create a repository, the repository wizard now includes a **Content Type** field with two options:
* **JCR Properties** (default) — the existing page, content fragment, and property-based translation pipeline.
* **DAM Asset Content** — the new pipeline for translating document assets.
The Content Type is locked after the repository is created and cannot be changed when editing the repository. If you need to switch a repository between modes, create a new repository with the desired Content Type.
When **DAM Asset Content** is selected, the repository configuration changes in the following ways:
* The repository **path is constrained to** `/content/dam` — only assets under the DAM root can be translated.
* The **Automation** tab is hidden. Scheduled/automatic submissions are not supported for this mode (see note below).
* **Link Rewriting Rules**, **Translate Properties**, and **Translate Content Fragment Variations** are hidden, because these only apply to property-based content and have no effect on these files.
You still configure **Transformation Rules** as normal — they determine where translated files are delivered (`source > lang:target` format).
Scheduled submissions (Automation) are not available for DAM Asset Content repositories. On AEM as a Cloud Service this mode relies on Sling jobs, so submissions must always be started manually — even for repositories with a default status of READY.
### Global "Translate Assets" Setting
The global **Translate Assets** option under **Configurations → General** applies to **JCR Properties repositories only**. It has no effect on DAM Asset Content repositories, where the file itself is always the translated content.
### Submitting DAM Asset Content for Translation
Creating a submission from a DAM Asset Content repository follows the same overall flow as a standard submission, with a few differences:
* DAM Asset Content repositories are clearly flagged in the repository picker so you can tell them apart from JCR Properties repositories.
* The **content path picker is rooted under** `/content/dam` and only shows the supported file types listed above.
* The **Translate Asset Metadata** and **Translate Tags** options are hidden, because these are JCR-only features. For DAM Asset Content, only the file is sent — no metadata, tags, or properties are translated.
Once content is selected, save and start the submission as usual. As with all submissions, click **Start Submission** to send the job to LILT.
When submitting an asset for translation, the delivery locations **must be different** to the source location. Each language must have a unique delivery location. If this is not followed, the delivery file will overwrite the source file
### How Translated Files Are Imported
When a DAM Asset Content job is complete, the connector imports the translated files back into AEM:
1. If the target asset does not already exist, the connector **deep-copies the source asset** to the target path, preserving metadata and rendition structure.
2. It then **replaces only the original file content** of the asset with the translated version.
3. It triggers **full asset reprocessing** so that PDF previews, thumbnails, and other web renditions are regenerated to reflect the translated content.
Target paths are derived from your repository's **Transformation Rules** (`source > lang:target` format).
After import, the file content is translated immediately, but AEM regenerates its renditions (the thumbnail and preview representations AEM uses to display an asset) asynchronously. This reprocessing can take a few minutes. If the preview or PDF viewer still shows the source language right after import, it is usually just the rendition being regenerated — the underlying file is already translated.
Import failures are recorded per file and surfaced on the **Documents** page with an error message. **Reimporting** a completed DAM Asset Content job is supported.
### Updating or Redelivering a File
If the source asset changes after a translation has been delivered, create a **new submission** for the updated file. The new delivery replaces the previous translated file at the target path; the connector does not keep the prior delivery, since the source it was based on has changed.
## Translating Tags
Starting with **AEM Cloud connector version 1.12**, the connector can translate **tags** as a standalone submission — with no page or content fragment required.
Standalone tag translation is available on **AEM as a Cloud Service (AEMaaCS)** only.
In AEM, a tag is a JCR node at a path like `/content/cq:tags/properties/style`. The node path is a stable identifier that never changes; what gets translated is the tag's **title** (`jcr:title`) and, optionally, its **description** (`jcr:description`). Tags are grouped into namespaces (the top folder under `/content/cq:tags`) and can nest into child tags.
Previously, tags could be translated only as part of a page submission — by checking **Translate Referenced Tags** in Job Setup, which bundles the tags attached to the selected pages into that job. You can now point a repository at a tag location and submit tags directly, independent of any page.
### Setting Up a Repository for Tags
Add a `cq:tags` path — either the root (`/content/cq:tags`) or a specific namespace (for example, `/content/cq:tags/properties`) — to a **JCR Properties** repository. The repository can be an existing one that already has site content paths, or a dedicated one for tags. Tag folders and namespaces under that path become selectable as submission content.
For tags, only `jcr:title` and `jcr:description` are translated, regardless of the properties configured on the repository. Transformation and link rewrite rules do not apply to tag content.
### External Locale Mapping
Tag localization can surface a mismatch between the language codes LILT uses and the codes AEM expects (for example, LILT `no-NO` maps to AEM `nb_NO`). Before translating tags into a new language — Norwegian and Chinese are common cases — compare the codes and add any discrepancies to the **External Locale Mapping** field in the connector configuration. This is a global setting that applies across submissions. See [Configure General Settings](#step-3-configure-general-settings).
### Submitting Tags for Translation
Tag submissions use the same three-step submission wizard as other content:
Select the tag-configured repository. Standard job fields apply: submission name, source language, target languages, due date, and PO/JIRA tracking. You do **not** need to check Translate Referenced Tags to submit standalone tags.
Select a **tag folder** or **individual tags**. Selecting a tag folder automatically includes every tag in it — there is no separate "Include Children" step as there is for pages. You can also add pages to the same submission; those pages will include their referenced tags only if you checked Translate Referenced Tags in Job Setup.
Review your selections and start the submission. All tags in the submission are combined into a single JSON file and sent to LILT.
### How Translated Tags Are Imported
Translated tags are written back as locale-suffixed properties on the **same tag node** (`jcr:title.de`, `jcr:title.fr`, and so on). No new tag paths are created and the tag ID stays stable — this is Adobe's recommended localization pattern and keeps a single source of truth per tag. Import writes or overwrites the locale-specific property for each delivered language.
### Limitations
Reimport overwrites any existing locale-specific property for the delivered language, including hand-authored localized titles.
* **AEMaaCS only.** Tag translation is not available on AEM 6.5 (on-premise).
* **Tags must be within a configured tag path.** Tags outside the configured `cq:tags` root are not selectable.
* **Only `jcr:title` and `jcr:description` are translated.** Custom tag properties are not supported.
* **Tag IDs and node paths are never changed.** Only the title and description are translated; the tag's identity stays stable.
* **No scheduled or automated tag submissions.** Tag jobs are started manually.
* **No separate per-language tag trees.** Translations live on the same node.
## Testing New Connector Versions
AEM is a highly customisable suite, and no two AEM instances are configured the same way. Language master structures, folder hierarchies, content fragment models, experience fragment templates, and workflow models all differ between customers — and sometimes between a customer's own staging and production environments. Connector behaviour that is perfect in LILT's testing environment, and even perfect in another customer's instance, can surface issues unique to your setup. For this reason, **customers are expected to test major connector releases in a staging or lower-level environment before deploying to production.** We strongly recommend giving the LILT team access to your staging environment during onboarding so we can observe your language master structure and content layout directly and validate behaviour against it.
When a new connector version is released, please:
1. Test the new feature or fix specifically — exercise the change in isolation against representative content.
2. Roundtrip-test every content type (content pages, content fragments, experience fragments, assets, tags, etc.) in **one** language first.
3. Roundtrip-test every content type in **all** target languages once single-language testing passes.
### Risks of Skipping Staging Testing
Deploying a new connector version directly to production carries real risk. Issues that staging testing typically catches include:
* **Content type regressions** — a release that handles content pages cleanly may mis-handle content fragments or experience fragments in your specific model configuration.
* **Language master / folder structure mismatches** — your language master layout may differ from the layouts the release was validated against, causing translations to land in the wrong path or fail to land at all.
* **Silent field omissions** — custom fields, metadata, or structured content fragment elements unique to your instance may not be picked up or returned as expected.
* **Workflow and status desynchronisation** — project or file statuses can fall out of sync between AEM and LILT, leaving in-flight work in an ambiguous state that is difficult to unwind in production.
* **Production rollback complexity** — issues discovered in production after live content has been sent are significantly harder to recover from than the same issues caught in staging, and may require manual re-translation, re-publication, or content surgery in AEM.
* **Translator and reviewer time wasted** — translation work performed against a misconfigured connector may need to be redone after the underlying issue is fixed.
If you don't have a staging environment available, contact your LILT Account team before upgrading — we'll help you scope a safe rollout plan.
# Get Started with LILT Assist
Source: https://support.lilt.com/kb/agent-kb
LILT Assist is a dedicated enterprise AI agent that helps you manage translation projects, create content, and work smarter within the LILT platform. Assist is built to simplify complex tasks, orchestrate your entire workflow, and eliminate time-consuming manual effort, making it easier than ever to take your content global.
## Getting Started
* **Access Assist:** Click the **agent icon** in the left-hand toolbar in the LILT platform.
* **Start a Conversation:** Type a prompt into the chatbox or select a module from the bottom of the screen.
* **Upload Content:** Click + to upload [single files](https://support.lilt.com/kb/supported-file-formats) (Word, PDF, PPT, Excel, etc.) or entire folders. You can also paste text directly into the chat.
* **Specify Content Needs:** Define your target languages (e.g., "English to Spanish"), content types (e.g., "marketing materials," "technical documentation"), and quality requirements (e.g., "I need this to be perfect" vs. "This is just for internal use").
* **Review and Approve:** Review the agent’s summary of the planned workflow, suggest changes as needed, and then confirm that Assist can get started.
* **Let the Agent Work:** Once you approve, the agent handles the technical details. You'll get updates on progress and can ask questions or make changes along the way.
## Capabilities
### [Translation](https://support.lilt.com/kb/translate-with-assist)
Insert text or upload files (documents, presentations, websites) for translation into multiple languages. The agent can recommend translation methods based on document type—choose **Instant Translation** for quick turnaround or **Verified Translation** for quality-critical content. You can also get quotes before starting, track progress in real-time, and create or use custom translation models.
### [Content Creation](https://support.lilt.com/kb/create-with-assist)
Generate original content in any language using your **company’s trained AI models**. To ensure high-quality output that matches your brand voice, provide specific details about the **topic, content type** (e.g., blog post, training manual, email), **audience, tone, and length**.
### [Terminology Management](https://support.lilt.com/kb/manage-terminology-with-assist)
Extract key terms from documents, websites, or search results to build custom glossaries (termbases). This ensures consistent translations across projects, especially for technical or specialized content. You can review and edit the termbase within the chat; once ready, it can be uploaded to your data source for use in future translation projects.
### [Insights and Analytics](https://support.lilt.com/kb/explore-analytics-with-assist)
Track [program analytics](https://support.lilt.com/kb/lilt-analytics-v2), like translation quality over time, AI accuracy and delivery performance, to inform your translation method choices. You can ask the agent to generate customizable reports with graphs and tables over different time frames and download charts and CSVs for further analysis.
```text theme={null}
User: "Can you provide AI accuracy data by language pairs?"
Assist: "To pull this data for you, I need a few details:
- Time Period: What date range would you like to analyze?
- Domain: Are you looking at data from a specific domain, or all domains?
- Model Type: Would you like to see Unadapted AI (baseline) and Adapted AI (fine-tuned)?
- Format Preference: Would you prefer a data table with all language pairs or a visual chart/graph?
Once you provide these details, I can generate the analysis for you."
User: "Please provide data on adapted AI over the last six months for all domains in a table."
Assist: "Perfect! I'll help you analyze Adapted AI accuracy by language pair over the last six months. Let me set up the plan for you."
```
### Team and Project Management
Automatically assign translators and reviewers, manage workflow stages for quality control, and track assignments and project timelines.
## Best Practices
* **Be Specific:** Precision improves results. Instead of *"Translate this,"* say *"Translate this marketing brochure from English to Spanish for our Latin American customers."*
* **Use the Agent's Expertise:** Ask for recommendations on workflow stages or quality levels. Use prompts like *"help getting started"* to explore features. You can also ask Assist to explain any terms or concepts you don't understand.
* **Plan for Scale:** Large files (>50MB) and human-verified projects require more processing time.
* **Review before Approving:** Always review the plan the agent creates before approving. Provide details when asked—this helps the agent give you better results. Don't skip the confirmation step.
## Limitations
* Cannot create new LILT accounts; requires an existing account with API access
* **2GB** file size limit; cannot process [file formats that LILT doesn't support](https://support.lilt.com/kb/supported-file-formats)
* Cannot create or use connector integrations
* Works best with modern browsers (Chrome, Edge, Safari). Some features require specific LILT subscription levels or roles.
# AI QA
Source: https://support.lilt.com/kb/ai-qa-v2
AI QA is an agentic quality assurance feature that detects and helps resolve translation issues before delivery. It reduces reliance on external QA tools, speeds up review, and improves end quality with an AI-driven check aligned to industry QA practices. AI QA has been proven to result in fewer missed errors and fewer false positives than traditional, script-based QA checks, based on LILT internal evaluations and linguist preference polling. AI QA is available for all language pairs.
**What's New in V2** AI QA has a refreshed interface. QA results now appear directly in the CAT sidebar for both segment-level and full-document QA — batch QA is no longer a separate pop-out. You can filter errors by category, severity, and check type, and flag errors that aren't relevant to your language. Full-document QA results now load progressively, so you can start reviewing before the entire document finishes processing.
## AI QA Interface
AI QA is an in-workflow step for linguists that integrates directly into LILT's CAT editor sidebar — for both segment-level QA and full-document QA
![Screenshot 2026 05 18 At 10 44 44 Am]()
1. In all workflow stages, a **QA icon** is visible next to each segment. Once the segment is confirmed or accepted, AI QA will run on that segment automatically.
2. You can also run QA on an **unconfirmed** segment by clicking the QA icon next to it.
3. Once AI QA finishes running, the icon indicates the result: a **green check mark** if no issues were found, or a **red number** showing the count of issues.
4. When you click on a segment in the editor (left), the **QA tab** in the right sidebar will navigate to that segment's QA results (if a QA error exists). The sidebar shows error category, severity, a plain-language explanation.
5. The suggested correction appears in the area where the MT suggestion or TM match is normally displayed. Segments can have multiple types of errors logged but will only have **one correction** per segment.
6. You can re-run AI QA on a segment using the re-run icon in the sidebar, or the QA icon next to the segment.
7. In the QA Sidebar, you will now see and be able to scroll through QA issues flagged in all segments where QA has been run.
## How AI QA interacts with AI Review
If your document uses an **Instant > AI Review > Review** workflow, both AI Review and AI QA results will appear in the sidebar.
### How they interact
* **AI Review corrections** appear in the sidebar first. The correction is applied to the target segment, and the original (pre-correction) text is shown in the sidebar so you can revert if desired.
* **When you confirm a segment**, AI QA runs on it. The QA results replace the AI Review results for that segment in the sidebar.
* **AI QA suggested corrections** appear *below* the segment (in the TM suggestion area). Segments can have multiple error types but will only have one correction.
![Screenshot 2026 05 18 At 10 53 45 Am]()
### Filtering between AI Review and AI QA
When you are working through a document with both AI Review changes and AI QA errors, you can use the **"Check Type" filter** in the sidebar to show only AI Review results or only AI QA results.
![Screenshot 2026 05 18 At 10 56 55 Am]( "Screenshot 2026 05 18 At 10 56 55 Am")
### Warning when running full-document QA with unreviewed AI Review
If you run full-document QA while there are still **unreviewed AI Review suggestions**, a warning dialog will appear informing you that proceeding will cause AI Review suggestions to disappear. You can choose to cancel or proceed
![Screenshot 2026 05 18 At 10 57 47 Am]( "Screenshot 2026 05 18 At 10 57 47 Am")
## New Batch QA
Full-document QA replaces the previous batch QA pop-out window. It now runs entirely within the CAT sidebar.
### Running full-document QA
1. Open a document in the CAT editor and initiate full-document QA from the sidebar.
2. QA can run on **all segments** — both confirmed and unconfirmed, including 100% TM matches (if enabled in org settings).
3. Results **stream in progressively** from the first segment to the last. You can start reviewing errors as soon as they appear — you don't have to wait for the entire document to finish.
4. You can **navigate away** from the document while QA is processing. When you return, your results will still be there.
### Time estimates for large documents
* Large documents may take some time to run, you can navigate away from the document and return later.
### Reviewing and acting on errors
1. The sidebar lists all errors found, organized by segment order. Click on the **segment name** in the QA tab to **navigate to that segment** in the editor. Double-click the **segment number** to collapse or expand the error details for that segment.
2. **Filter errors** using the filter controls at the top of the sidebar:
* **Error category** — e.g., terminology, formatting, tags, grammar, omission, mistranslation, custom (coming from custom QA checks added to organization settings)
* **Severity** — e.g., critical, major, minor
* **Check type** — Style-based (AI QA) or AI Review
3. For each error, you can:
* **Accept** the suggested correction (applies the fix to the segment text)
* **Ignore** the error (removes it from the active list; it can be shown again via the toggle)
* **Flag** the error — select a reason and optionally add a comment to report it as irrelevant or incorrect for your language
4. **Ignored errors:** When you re-run full-document QA, you have the option to **show or hide ignored errors**. Ignored errors appear greyed out when shown.
![Screenshot 2026 05 18 At 11 03 32 Am]( "Screenshot 2026 05 18 At 11 03 32 Am")
### Mandatory batch QA
If your organization has **Required Batch QA** enabled, you must confirm or ignore all errors before you can submit a task. You will not be able to mark the workflow stage as done until all flagged AI QA errors have been addressed.
## Flagging errors
If you encounter a QA error that doesn't make sense for your language pair or domain, you can flag it for review.
1. Click the **flag icon** on any error in the sidebar.
2. Select a **reason** for flagging.
3. Optionally add a **comment** with additional context.
4. Submit — the error will show a colored flag indicator.
LILT's research team periodically reviews flagged errors when updating the AI QA model and prompt. The more specific your feedback, the more useful it is for improving accuracy.
![Screenshot 2026 05 18 At 10 35 36 Am]( "Screenshot 2026 05 18 At 10 35 36 Am")
## Custom AI QA checks
Admins and managers can define additional AI QA checks to run based on natural language input within [LILT org settings](https://support.lilt.com/kb/organization-settings#organization-settings). When QA runs during a workflow, AI QA will also evaluate against these custom checks and surface relevant errors. These checks can be set for all languages or just a subset.
*Please note that this is an experimental feature and may not catch all errors. If you find that a custom check isn't detecting an issue, try rewriting the prompt to be more specific or include an example.*
![Screenshot 2026 07 31 At 9 48 08 Am]()
## Enabling AI QA and exact matches setting
AI QA is configured within [LILT Org settings](https://support.lilt.com/kb/organization-settings#organization-settings).
![Screenshot 2026 05 18 At 10 33 36 Am]()
There is a setting for whether AI QA should run on exact (100/101%) matches. If you would like AI QA to run on exact matches, an Admin or Manager will need to enable this in org settings.
* If exact matches are locked for the org, in order to accept any proposed suggestions on exact matches, the setting for [Unlock Locked Segments](https://support.lilt.com/kb/organization-settings#allow-unlocking-locked-segments) must also be turned on.
***
## AI QA Categories & Sub-categories
| **Category** | **Sub-category** | **Definition** |
| :------------------------------- | :----------------------- | :--------------------------------------------------------- |
| Accuracy & Completeness | Mistranslation | Meaning deviates from source |
| | Addition | Extra information added |
| | Omission | Missing information |
| | Untranslated | Source text left untranslated |
| | Scope or Plurality shift | Change in meaning breadth (e.g. singular ↔ plural) |
| | Length deviation | Target too short or too long compared to source |
| Linguistic Conventions & Fluency | Grammar | Incorrect syntax or structure |
| | Number/Plural alignment | Mismatch between singular/plural or subject-verb |
| | Spelling | Obvious typos or spelling mistakes |
| | Punctuation | Errors affecting clarity or meaning |
| | Repeated words | Accidental duplication |
| | Wrong language | Text not in target language |
| | Locale conventions | Incorrect local formats (dates, currencies, numbers) |
| Style & Readability | Awkward/Unidiomatic | Unnatural or clumsy phrasing |
| | Tone/Register mismatch | Inappropriate style or tone for the domain or context |
| Technical & Formatting | Tag integrity | Broken or mismatched tags |
| | Numeric mismatch | Inconsistent numbers or formats |
| | Alphanumeric mismatch | Incorrect codes, IDs, or mixed data |
| | Symbol mismatch | Unbalanced punctuation (quotes, brackets, etc.) |
| | Case mismatch | Incorrect capitalization |
| | Whitespace | Extra or missing spaces affecting structure or readability |
| Terminology & Consistency | Term plausibility error | Incorrect or implausible term translation |
| | Brand name handling | Improper treatment of brand names |
| | DNT violation | Translated "Do Not Translate" items (e.g., "Wi-Fi", URLs) |
| | Forbidden Terms | Use of explicitly banned or deprecated terms |
***
## FAQs
1. **Is AI QA replacing human review?** No. AI QA reduces manual effort and catches issues early, but human judgment remains the final gate for high-stakes content.
2. **Does AI QA enforce terminology?** The translation model may flex on terms in context. AI QA provides a stricter post-editing layer that detects and corrects terminology mismatches for compliance. Incorrect terminology matches are still highlighted in red in the editor.
3. **Can I use AI QA with third-party translation models?** Yes. LILT supports model choice and evaluation across providers, and AI QA can operate in workflows that include third-party engines.
4. **My custom AI QA check didn't detect an error.** Custom AI QA checks is an experimental feature. If your check didn't find a specific error, try rewriting the prompt to be more specific, or include an example.
5. **Does AI QA work with Automatic Batch QA and Required Batch QA settings?** Yes. If Automatic Batch QA or Mandatory Batch QA are enabled for the org, those will trigger as usual. If Mandatory Batch QA is on, linguists will not be able to mark the workflow stage as done until all AI QA errors have been accepted or ignored.
6. **What happens if a segment has multiple errors but only one correction?** Segments can have multiple error types flagged, but AI QA will provide only one suggested correction per segment.
7. **Where did the batch QA pop-out go?** Batch QA is now called full-document QA and lives entirely in the CAT sidebar. There is no longer a separate pop-out window.
8. **Can I run QA on unconfirmed segments?** Yes. QA runs automatically on confirmed segments, but you can also manually trigger QA on unconfirmed segments by clicking the QA icon next to the segment or by running full-document QA.
9. **What should I do if I see an error that's not relevant to my language?** Use the flag feature to report it. Select a reason and optionally add a comment. LILT's research team reviews flagged errors to improve AI QA accuracy over time.
10. **Can I leave the page while full-document QA is running?** Yes. QA will continue processing in the background, and your results will be preserved when you return.
11. **Are the current AI QA changes to the UI or to the QA model itself?** The recent updates are to the UI and workflow experience only. Changes to the underlying QA model and prompt — including what is checked and how errors are communicated — are planned separately. Use the flag feature to help inform those future improvements.
# AI Review
Source: https://support.lilt.com/kb/ai-review
Automated quality assurance that corrects translation errors and enforces style guidelines before human review
AI Review Agent automatically corrects errors in translations, providing a second layer of quality assurance before human review. It improves translation quality by identifying and fixing issues while enforcing your organization's style guidelines.
## Scope
AI Review checks:
* [Style guide](/kb/organization-settings#OrganizationSettings-Styleguide) compliance (except formatting and alignment)
* Termbase terminology validation
* Critical, Major, and Minor errors
AI Review excludes:
* Segments with "No error" status
* Exact matches (100%) and In-context exact matches (101%)
## Enabling AI Review
Set your default workflow to AI Review in LILT Settings by selecting one of the below options at the organization or domain level:
* Instant > AI Review > Review
* Instant > AI Review > Review > Secondary Review
Admins can select this workflow during job submission if needed.
**Timing:** AI Review runs after Instant Translate completes and can take up to 3 hours. Users cannot translate or review segments while AI Review is running.
**AI Workflow Optimization:** After AI Review, all segments are analyzed by LILT's proprietary segment prioritization model to assess the likelihood of errors. Segments with a low likelihood of errors will come through as locked in the Review stage. Note: AI Workflow optimization will run on all languages within the job created, even if some of those languages aren't supported by AI Review.
![]()
### Model Learning
All reviewed and accepted segments are saved to your selected model, continuing the fine-tuning of your custom models.
### AI Provider
The AI Provider for AI Review is configured in [AI Providers](https://support.lilt.com/kb/3rd-party-llm-support-for-the-contextual-ai-engine#ai-providers). The default is LILT Contextual AI. However, AI Review can be configured to use Anthropic Claude as an alternative provider.
## Supported Languages
AI Review is available for all language pairs as of July 2026
**Language limitations:**
* Jobs with languages that lack MT support cannot be submitted.
## Linguist Interface
### Viewing AI Review Corrections
AI Review results appear in the CAT sidebar. Changes made by AI Review are shown with struck-through text (removed) in red and added text in green. Issues found are categorized by severity, category, and sub-category.
You must accept segments that have been corrected by AI Review. This also reprojects any tags to ensure correct formatting.
![Image]()
Once a segment is accepted, [AI QA](https://support.lilt.com/kb/ai-qa#ai-qa) runs. The results of AI QA will replace the results of AI Review, and will offer the ability to accept/ignore the QA suggestions.
### Rejecting AI Review Corrections
You can reject AI Review changes to revert the text to its original state before you accept the segment. To reject the changes, click on "Revert correction". At this point, this will be logged as an error and will appear under the error logging flag.
### Providing feedback on AI Review
Using the flag icon at the bottom left of an AI Review suggestion gives experts the ability to give direct per-segment feedback to the LILT research team who will use this information periodically to improve AI Review performance over time.
![Screenshot 2026 07 31 At 9 51 36 Am]()
## Revision Reports
Revision reports show AI Review corrections alongside reviewer changes.
![]()
**In reports, AI Review changes include:**
* Error category and severity
* "LILT AI Reviewer" in the Comments column
* "Yes" in the Reviewer changes? column
**Downloaded reports (Admin/Manager only):**
* AI Review error rate percentage (calculated over 80% of segments processed)
* All AI Review changes marked with "LILT AI Reviewer"
## Custom Style Guides
AI Review enforces custom style guides to maintain consistency across translations. Style guides control spelling, punctuation, vocabulary, date/time formats, and number formats.
Ask a linguist to verify the rules and AI review results before deployment.
### Writing Effective Rules
**Use explicit, prescriptive commands**
* Write "Replace X with Y" or "Use X instead of Y"
* Avoid "Consider using X" or "X might be preferred"
**Structure by category, critical rules first**
* Group related rules (spelling, punctuation, terminology)
* Place most important requirements at the top
* Provide 2-3 concrete examples per rule
**Repeat key constraints**
* State critical requirements in multiple rule contexts
* Repetition improves adherence given AI variability
* Example: If preserving variables is critical, repeat this in every category
**Per-language Rules**
* Use explicit language 'gates' and prescriptive commands
* Start each rule with a clear language gate. Keep gates consistent across the guide.
```text theme={null}
“de-DE only: Replace …”
“fr-FR only: Use …”
```
* Use full locale when norms differ: `pt-BR only:…` vs `pt-PT only: …`
* Avoid mixed-language rules; only one language per rule. Do not define overlapping rules for the same language in multiple sections.
* Examples:
```text theme={null}
fr-FR only: Use non-breaking space before ! ? ; : % and units.
- “Bonjour!” → “Bonjour !”
- “50 %” → “50 %”
es-ES only: Use opening marks for questions/exclamations.
- “Como estas?” → “¿Cómo estás?”
de-DE only: Replace straight quotes with „“ in running text.
- "Beispiel" → „Beispiel“
```
**Avoid formatting rules**
* Don't specify spacing, line breaks, or text alignment
* Don't control HTML/XML tag structure
* AI Review cannot process document-level formatting context
**Preserve technical elements**
* Instruct AI Review to never modify `{variables}`, ``, or `[placeholders]`
* Repeat this constraint in multiple rule categories
### Rule Categories
Structure your style guide with these categories:
**1. Spelling Standardization**
```text theme={null}
Replace US English spellings with UK English equivalents:
- color → colour
- organize → organise
- center → centre
Replace -ize endings with -ise endings:
- standardize → standardise
- optimize → optimise
- realize → realise
Do not modify technical terms, product names, or text inside {variables}.
```
**2. Punctuation Conventions**
```text theme={null}
Use single quotation marks for all inline quotations:
- "example" → 'example'
- He said "hello" → He said 'hello'
Do not use serial commas (Oxford commas):
- red, white, and blue → red, white and blue
- lions, tigers, and bears → lions, tigers and bears
Use periods in abbreviations:
- Mr → Mr.
- Dr → Dr.
- etc → etc.
Do not modify punctuation inside tags or variables in angle/curly brackets.
```
**3. Date and Time Formats**
```text theme={null}
Use DD/MM/YYYY format for all dates:
- 03/15/2024 → 15/03/2024
- December 5, 2024 → 05/12/2024
Use 24-hour time format:
- 2:30 PM → 14:30
- 9:00 AM → 09:00
Do not change date/time values inside {placeholders} or technical specifications.
```
**4. Vocabulary Standardization**
```text theme={null}
Replace US vocabulary with UK equivalents:
- apartment → flat
- elevator → lift
- truck → lorry
Replace technical jargon with preferred terminology:
- click → select
- hit → press
- login → log in (as verb)
Do not replace terms inside product names, brand names, or {variables}.
```
**5. Number and Measurement Formats**
```text theme={null}
Use metric measurements:
- miles → kilometers (with numeric conversion)
- pounds → kilograms (with numeric conversion)
- fahrenheit → celsius (with numeric conversion)
Use comma as decimal separator:
- 3.14 → 3,14
- 10.5 → 10,5
Use space as thousands separator:
- 1,000 → 1 000
- 10,000 → 10 000
Do not modify numbers inside variables, tags, or placeholders in brackets.
```
### Examples
![]()
![]()
![]()
# Amazon Workdocs
Source: https://support.lilt.com/kb/amazon-workdocs
This documentation provides an overview and setup instructions for the connector integrating LILT with Amazon WorkDocs. Amazon WorkDocs is a secure, fully managed file storage and sharing service designed for enterprise use, emphasizing user productivity through robust administrative controls and feedback mechanisms. By leveraging this connector, users can seamlessly integrate LILT's translation services with Amazon WorkDocs, enabling efficient and secure management of translation workflows directly within their cloud storage environment. Amazon WorkDocs securely stores files in the cloud, making them accessible only to the owner and explicitly authorized contributors and viewers. This ensures privacy within an organization, as users cannot access others' files without permission. The integration facilitates a streamlined workflow where documents stored in Amazon WorkDocs can be automatically sent to LILT for translation and then received back and stored securely, enhancing productivity and collaboration across global teams.
## **Accounts for Testing and Demonstrations**
For integration and testing purposes, it's necessary to use an IAM (Identity and Access Management) user with read/write permissions to your Amazon WorkDocs instance. Detailed guidance on setting this up is available in the [Amazon WorkDocs API documentation](https://docs.aws.amazon.com/workdocs/latest/APIReference/Welcome.html).
## **Setup and Configuration**
### **In the Partner App:**
* Log in as outlined in the [Accounts for Testing and Demonstrations](#accounts-for-testing-and-demonstrations) section.
* Select or create folders for pulling content into LILT for translation, storing translated documents, and optionally, moving processed documents to avoid duplication.
### In Connector Configuration and LILT Account:
* Obtain the **API Key** from the LILT user interface, ensuring it is valid.
* **WorkDocs Access Key ID** and **Secret Access Key** should be provided by the customer through an IAM user with WorkDocs access.
* Specify the **AWS region name** as provided by the customer.
* Use the specific **Folder Ids** for source content and target folders for translated documents, as detailed in the partner app section.
* Set **WorkDocs Max Depth** to define how deep to search for content within directories, with a default of 2.
* Optionally, specify a **Processed Folder Id** where files will be moved post-processing to avoid duplication. Without this, the connector uses a "Last Check" flag to manage content duplication.
# Amplience
Source: https://support.lilt.com/kb/amplience
The LILT + [Amplience](https://amplience.com/) connector enables automated translation of Amplience Dynamic Content directly from the LILT platform. Content is browsed and selected inside LILT (no plugin or app installed inside Amplience), translated by LILT, and delivered back to your Amplience hub for your local teams to review and publish.
This article covers everything needed to set up, send content, and test the connector. The LILT team handles the connector configuration on the LILT side; the customer provides Amplience credentials and identifiers listed below.
## Access Required
LILT requires the following from your Amplience environment for both your **development/sandbox** and **production** hubs. Each environment is configured as a separate connector instance.
1. **Personal Access Token (PAT)** — ideally created on a dedicated service-account user (not a personal account). Generated in Amplience under **Development > Personal Access Tokens**.
1. Provide the PAT over a secure channel (1Password share, encrypted email, or whatever your security policy requires for long-lived secrets). Never paste it into a public chat channel.
2. **Service-account user with hub access** — the user that owns the PAT must have read + write permission on the source repository and rights to transition workflow states.
3. **Hub ID** — your production Amplience hub identifier. Found in the hub URL or via `GET /v2/content/hubs`.
4. **Source repository ID** — the repository LILT pulls source content from (e.g., a "Global Content" repo). Found in **Settings > Repositories**.
5. **Target repository IDs** — the repositories LILT delivers content to (e.g., an APAC repo). Found in **Settings > Repositories**.
6. **Source folder ID** — for folder delivery mode only.
7. **Target folder names** — for folder delivery mode only
8. **Workflow-state IDs** — the alpha-numeric IDs (not labels) of the workflow statuses LILT will read and write:
1. "Ready for Translation" (the status your team uses to signal content is ready — the connector does not read this status to select content; selection happens in LILT, see the FAQ)
2. "In Progress" (optional — set by LILT when extraction begins)
3. "Translation Complete" (or your equivalent post-translation status — set by LILT when delivery finishes)
9. **Content schema list** — for each content type in translation scope, LILT needs: schema name, content type ID, schema URI, and the list of localizable field paths per schema. If you are migrating from another translation tool that stored translatable-field configuration, exporting `installationParameters` from that tool provides the input LILT needs.
10. **For field-mode schema translation:** the list of content schemas in scope, and the mapping of each schema to its per-locale target item (where each locale's translations are delivered).
11. **Regional Repository and Language Mappings** — Where you have languages that need to be delivered to different repositories, please provide a list of these, as well as any one-to-many language mappings (e.g. itIT is mapped to itIT and itCH).
***
## Installation and Setup
The connector is installed and configured by LILT on the LILT side. There is no plugin, app, or extension installed inside Amplience.
### Step 1: Create a service-account user in Amplience
Create a dedicated user (e.g., `lilt-connector@yourcompany.com`) and grant it read + write on the source repository plus workflow-state transition permissions.
### Step 2: Generate a PAT
Log in as the service-account user. Go to **Development > Personal Access Tokens** and create a token named `lilt-connector-{env}` (e.g., `lilt-connector-prod`). Copy the token immediately — it is shown only once.
### Step 3: Gather configuration values
From the Amplience admin UI or Management API, collect the Hub ID, source repository IDs, and workflow-state IDs listed in **Access Required** above. Determine what delivery mode you would like.
* **Entity mode:** each target locale is created as a native variant linked to the source (visible under the source's **Variants** panel).
* **Repository-only mode:** one item per market/region is created in the relevant regional repository, holding the subset of locales.
* **Field mode:** locale values are written back into the existing item in place.
* **Folder mode**:
* Source content lives in a Source content folder inside the same repository as all translations.
* Translated content is delivered into per-country, locale or market folders inside the same repository, using the same folder path as the source item. For example, a source file in `Source Content/Content Assets/2026 Campaign/Translation_File` is delivered to `Germany Content/Content Assets/2026 Campaign/Translation_File`.
* **In all modes:** non-translatable fields, IDs, and references are preserved unchanged, and entity and region deliveries mirror the source's folder path in the regional repository.
* In entity, folder and region modes, the configured "Translation Complete" workflow status is set on the delivered content, and the source item is also set to "Translation Complete" once every language submitted in the job has been delivered. Field mode leaves workflow state unchanged (the item is shared across all target locales, so flipping it on one delivery would prematurely close the workflow).
### Step 4: Hand off to LILT
Pass the PAT, IDs, and content-type schemas to your LILT Account Manager or Solutions Architect over a secure channel. LILT will:
* Create the connector instance and enter your configuration
* Set up the locale-to-language mapping (Amplience locales like `fr-FR` mapped to LILT language codes)
* Set up the translatable-field mapping per content type
* Set up translation defaults (translation memory, model, workflow type, target languages) per region
* Run the connector's built-in validations (API connectivity, hub access, source repository access, workflow-state existence)
### Step 5: Supervised first job
Once all validations pass, LILT runs a supervised first translation job with you spanning different content types, in your development environment. Verify:
* The translated content landed where your delivery mode produces it: a locale variant under the source item's **Variants** panel (entity mode), a module in the region's repository (region mode), or updated in place on the source item (field mode)
* Non-translatable fields (IDs, references, media URLs) are preserved unchanged
* For entity and region modes, the delivered content lands in the same folder path as the source item but in the correct regional repository
* The workflow state on the variant transitioned to your configured "Translation Complete" status
* For large feature upgrades and changes, LILT recommends testing all content types in a single language first, then multiple languages.
### Step 6: Production cutover
After dev sign-off, LILT creates a separate production connector instance using your production PAT and re-validates against the production hub. LILT recommends customers thoroughly test the connector in the production environment before deploying for use. Reach out to your account manager for a test plan and any support required for testing.
***
## Sending Content for Translation
![Screenshot 2026 07 31 At 9 54 36 Am]()
Content is selected, submitted, and tracked inside the LILT platform — not inside Amplience. The high-level flow:
**How delivery looks depends on your configured delivery mode.** LILT sets this per connector instance:
* **Entity (variant) mode:** each target locale is created as a native Amplience locale variant of the source, linked under the source item's **Variants** panel and navigable via the locale dropdown. Variants land in the mapped regional repository.
* **Region mode:** one content item per region/repository is created per regional repository, with the repository's locales populated inside it. These are standalone items, not native variants, so they do not appear under the source's Variants panel.
* **Field mode:** translates **source text authored directly in content schemas**. The connector reads the source text from the configured schemas, translates it, and writes the translations back into the **mapped schema items** for each locale (at field level). Field-mode configurations run **automatically on a schedule** (see *Automatic (scheduled) translation*).
The steps below describe entity mode (the default). Where they mention "variant" or the "Variants panel," substitute the region module or in-place item if your instance uses region or field mode.
1. **Set workflow status in Amplience (optional convention).** Teams typically move items into a "Ready for Translation" status to signal intent.
2. **Browse and select in LILT.** Open the Amplience icon in LILT, select your preferred configuration, browse the source repository by folder and content type, and select the items you want to send. The connector lists content types based on what is configured in the connector admin.
3. **Create a job.** Set the language pairs, choose Verified (human-reviewed) or Instant (AI-only) translation, set a due date. Domain templates can auto-fill defaults per region.
4. **Translate.** LILT extracts only the configured localizable fields, preserving non-translatable fields, formatting, and media references. Character limits defined in your Amplience content type schemas surface in the LILT editor — translators see a per-segment character count and a warning when a translation exceeds the limit (Amplience itself enforces the limit on save). Translation proceeds in Verified or Instant workflow.
5. **Delivery.** When the job is complete, LILT delivers translations back to Amplience automatically, in the shape set by your delivery mode configured when the connector is initially being created:
6. Your local market teams then review and publish the delivered content in Amplience.
### Automatic (scheduled) translation (field mode)
When source text is authored directly in content schemas, there is no manual browse-and-submit step. The connector runs on a schedule agreed at setup:
1. On each run it detects source text added to the configured schemas since the last run.
2. It translates the new text, reusing translation memory for anything already translated.
3. It writes **only the new translations** back into the mapped items for each locale — existing translations are never overwritten.
4. Delivered content is left **unpublished** for local teams to review and publish.
Runs can also be triggered on demand by users with the appropriate permissions: **Manage → Connectors → select the configuration → Trigger job**.
### Adding new content types after launch
When you create a new content type in Amplience that should be translatable, notify your LILT Account Manager with the schema URI and list of localizable field paths. LILT updates the connector configuration — no engineering effort is required, just JSON field mapping. Validation runs again before the new type is available for translation.
***
## Limitations
The following constraints apply:
* **Delivered content is left unpublished.** The connector never publishes, so delivered content stays unpublished until your local market teams publish it. There is no auto-publish.
* **Parent-only translation.** Content items with `content-link` or `content-reference` children translate the parent only. Linked or referenced child content remains in the source language and renders through to the variant unchanged. Recursive translation of linked content is a planned follow-up.
* For standard translation, content is selected manually in the LILT UI; webhook-driven automatic discovery is not supported. **Field mode — which translates source text authored directly in content schemas — runs on a schedule** instead of manual selection, and can also be triggered on demand (**Manage → Connectors → Trigger job**).
* **No in-context preview pre-delivery.** LILT does not render Amplience content visually during translation. After delivery, the variant can be previewed in Amplience's native visualization tools.
* **Per-region job splitting is not supported.** A single LILT job delivers translations to all submitted locales together. The connector does not split one job into per-region sub-deliveries; submit individual languages or all submitted languages, not arbitrary subsets at delivery time.
* **Character-limit warnings depend on hub tier.** Per-segment character-limit warnings use Amplience's `effective-content-type-schema` endpoint, which lower-tier Amplience hubs do not expose. Translation works on any tier; only the in-editor character-limit warning depends on the hub's plan.
* **Field-mode** schema translation delivers **new strings only** — strings that already have a translation for a locale are not re-sent or overwritten.
* Source text must be in the **base source language** and follow the connector's expected field structure to be picked up; text authored under a regional variant of the source language is skipped until corrected.
* **Net-new schemas and their per-locale target items must be mapped in the configuration** before they will translate. Adding fields to an already-mapped schema needs no further setup.
***
## FAQ — Testing the Connector
These cover the most common questions during the customer test phase.
**Q: How do I trigger the connector to pick up my test content?**
A: Open the Amplience connector in LILT and browse the source repository, then select the item and create a job. You do not need to set any workflow status first and there is no polling delay, browse returns every item in the source repository regardless of its workflow state. (Workflow status is something the connector writes back, not something it reads to gate selection.)
**Q: Why doesn't my content appear in the LILT browse view?**
A: Three common causes:
* The content type isn't configured in the connector. Confirm with your LILT contact that the content type's schema URI and localizable fields are in the connector configuration.
* A source-language mismatch. Browse filters by the configured source language; an item whose locale does not match the configured source will not appear.
* The source repository the connector reads from doesn't contain the item. The connector reads only from the configured source repository.
**Q: My translated content landed at the root of the variant repository instead of in the source folder. Why?**
A: This indicates folder preservation didn't complete (typically a transient Amplience or network error during the post-localize folder PATCH). The variant itself is correct — only the location is at the root. Re-run the delivery, or move the variant manually. If this recurs, raise it with LILT.
**Q: Some text shows HTML entities like `Jusqu'à` instead of `Jusqu'à`. How do I fix this?**
A: This indicates the HTML-unescape setting was disabled for your connector instance. Ask your LILT Account Manager for support on this.
**Q: Delivery failed with "Amplience source content item is missing". What happened?**
A: The source item was deleted from Amplience between the time the job was extracted and when delivery ran. Either restore the source item in Amplience and retry the delivery, or remove the affected document from the LILT job.
**Q: Delivery failed with a 409 version conflict after 3 retries. What now?**
A: The target variant was being edited concurrently with delivery. Pause edits in the target repository (or hold the source item constant) and retry. If the conflict persists, coordinate with whoever is editing the variant.
**Q: Can I re-send the same content for translation?**
A: Yes. Re-submitting an item updates the existing target-locale variant in place (no duplicate variant is created). LILT skips re-extraction when the source body hash hasn't changed since the last extract — change a source field or work with your LILT contact to clear the state-index entry to force a re-extract.
**Q: I sent content in two languages but only one came back. What's happening?**
A: Check the job status in LILT — Verified workflow jobs require human review and may complete at different times per language. Once each language reaches the delivered state in LILT, its variant is created in Amplience. Confirm all language pairs in the job reached "Done" before raising it.
**Q: Will the LILT connector work alongside our existing translation connector during transition?**
A: Typically yes. Both connectors can run in the same Amplience environment concurrently, but sending the same content through both at the same time can produce conflicting variant states. We recommend running the LILT connector on a non-overlapping content set during transition, then rolling off the legacy connector once you're satisfied with LILT's behavior.
**Q: My source text is authored directly in content schemas, not in a selectable item — how does it get translated?**
A: Use a field-mode configuration with scheduled runs. On each run the connector reads new source text from the configured schemas and writes the translations back to the mapped items for each locale — there's no manual selection. You can also trigger a run on demand via **Manage → Connectors → Trigger job**.
**Q: Will scheduled field-mode translation overwrite translations my team has already made**
A: No. It delivers only strings that are missing a translation for a locale; existing values are left unchanged.
**Q: I added a new schema (or a new market/locale) — why isn't it translating?**
A: New schemas and their per-locale target items must be mapped in the configuration before the connector knows where to deliver. Ask LILT to add the mapping; once mapped, subsequent runs pick it up automatically
***
For configuration changes, new content types, or any issues during testing, reach out to your LILT Account Manager or [LILT Support](https://lilt.atlassian.net/servicedesk/customer/portals).
# Anthropic Configuration
Source: https://support.lilt.com/kb/anthropic-configuration
To configure Anthropic as an AI Provider, the customer only needs a single key.
### Access
Configuring the Anthropic provider in AI Providers will enable the customer to access all available services directly via Anthropic for Translate & Create, including:
* Sonnet 4.5
* Haiku 4.5
* Opus 4.1
* Opus 4.5
### Configuration steps
1. Retrieve the API Key from Anthropic. You can find your API key in your [Anthropic account](https://console.anthropic.com/) under API Keys. To get access to a key and to be able to use Anthropic, you'll need access to the respective API's. The API key will look similar to **sk-ant-api03-...**
2. Enter in LILT AI Providers configuration for Anthropic.
![Screenshot2026 01 13at15 43 23]()
### Setting Anthropic as a Translation Provider
After configuring your API key in AI Providers, you can create a new Custom Model with one of the Anthropic models as your provider.
![Screenshot2026 01 16at14 59 12 1]( "Screenshot2026 01 16at14 59 12 1")
### FAQs
**What is an authentication key and how can I use it?**\
An API key is a code that allows you to use Anthropic directly in LILT Create or LILT Audio/Video-To-Text Translations. When integrating Anthropic into LILT Create, content creators can use this to create multi-lingual content from scratch.
# API
Source: https://support.lilt.com/kb/api
The API section lets you manage the API tokens used to authenticate with the LILT API.
### Legacy API Key
Your original API key is displayed at the top of this section. This key continues to work as before and is not affected by the introduction of API tokens.
![Screenshot 2026 05 26 At 6 59 51 Pm]()
### Individual API Tokens
The API Tokens section allows you to create and manage multiple named tokens for different integrations. This is useful when you connect several systems to LILT (e.g., a CMS connector, a CI pipeline, and an internal tool) and want to manage each one independently.
**Creating a token**
1. Click **Create Token**.
2. Enter a descriptive name (e.g., "Contentful connector").
3. Select who this token is for. Typically this will be the token creator but could be another customer contact or admin\
The API key permissions will match the permissions of the user role being assigned that key.
4. Optionally set an expiration date.
5. Click **Create**. The full token is displayed once — copy it immediately and store it securely. It cannot be retrieved later.
![Screenshot 2026 05 26 At 7 00 39 Pm]()
**Managing tokens**
The token list shows each token's name, prefix (e.g., `lilt_abc1...`), creation date, expiry, and when it was last used.
From this list you can:
* **Revoke** a token to permanently disable it without affecting other tokens.
* **Rotate** a token to generate a new secret while keeping the same name and configuration. The new token is shown once for copying.
![Screenshot 2026 05 26 At 7 02 49 Pm]()
**Best Practices for API Keys**
Generate one API key per user per application. For example
1. Each connector has it's own API key
2. Each user gets their own API key (e.g. if I'm using an API key for some sort of integration, I generate a new API key)
3. You can only access/copy an API key at the time of creation. You can't go back and copya key after it's been initially generated.
4. Temporary uses should have temporary keys but connectors should have non-expiring keys or expiration dates long in the future (because of the risks of connector API keys expiring)
API tokens use the same authentication methods (`?key=` query parameter or Basic Auth) as the legacy key, so no changes are needed in existing SDKs or CMS plugins. For more information, see our [API documentation](https://lilt.com/docs/api).
# Audio File Translation
Source: https://support.lilt.com/kb/audio-file-translation
Translating an audio file in LILT is very similar to the text translation workflow you're used to, and is available for both **Instant** and **Verified Translation** jobs.
### **How It Works**
1. **Upload audio file:**
* Upload your audio file using unified job submission. You will need to have an [**AI Provider**](https://support.lilt.com/kb/3rd-party-llm-support-for-the-contextual-ai-engine#ai-providers) configured.
* Select whether you want a verified or instant translation. For Instant translation, the toggle for "Receive an expert-verified translation" should be set to off.
* In Additional Options, select whether you want to review the extracted text before translation.
2. LILT will begin extracting the text.
![Image]()
3. If you selected “Review extracted text”, you have the opportunity to make any necessary changes to the extracted text and timestamps. Once you’re satisfied with the source text, click on “Mark as reviewed” and then “Text review completed”.
![Image]()
4. If you selected an Instant translation, LILT will then use your selected custom model to instantly translate the text.
5. If you selected a Verified Translation, LILT will send your extracted text to our experts for a translation.
# Audit Logs
Source: https://support.lilt.com/kb/audit-logs
## Introduction
LILT Translate stores audit logs for all actions performed throughout the platform. The audit logs can be queried by calling the **/activities** endpoint. The logs are stored and returned as JSON blobs. Users can pass request parameters in to query logs based on certain criteria.
## Querying Audit Logs
### Path:
GET **/activities**
```shell CODE theme={null}
https://lilt.com/2/activities
```
### Description:
Fetches audit logs related to your organization/team.
Example curl command:
```shell CODE theme={null}
curl -X GET https://lilt.com/2/activities?key=API_KEY&organizationId=274&from=2021-06-25T00:48:45Z
```
### Request Parameters:
Enlarges the table by opening it in a full screen dialogOpen
| **Parameter** | **Description** | **Example Value** | **Type** |
| ------------------ | --------------------------------------------------------------------------- | -------------------- | ------------------ |
| **organizationId** | Your organization id | 274 | Integer (Required) |
| **from** | A date and time in ISO8601 format. | 2021-06-05T00:45:42Z | String (Optional) |
| **to** | A date and time in ISO8601 format. | 2021-06-05T00:45:42Z | String (Optional) |
| **actionType** | One of DATABASE\_ACCESS\_EVENT, API\_CALL\_EVENT, LOGIN\_EVENT | API\_REQUEST | String (Optional) |
| **userId** | The user id you want to query | 2344 | Integer (Required) |
| **userName** | The username of the user | testuser | String (Optional) |
| **resourceType** | The type of the resource being accessed (i.e. MEMORY, DOCUMENT, JOB, etc.). | MEMORY | String (Optional) |
| **requestResult** | One of ATTEMPT or SUCCESS | ATTEMPT | String (Optional) |
| **correlationId** | A UUID generated for a specific request. | | String (Optional) |
### Response:
The audit log response is a single JSON object with one field, containing an array with multiple log records. The base schema has the following fields return, irrespective of which action type is requested.
Enlarges the table by opening it in a full screen dialogOpen
| **Field** | **Description** | **Type** |
| ----------------- | -------------------------------------------------------------------------------------------------------------------- | -------- |
| **auditLogs** | An array of JSON blobs containing each audit log.
Depending on the actionType, they will have different fields. | Array |
| **id** | Unique identifier for the audit log | Long |
| **timestamp** | UTC date in ISO 8601 format | String |
| **userName** | string identifier for the user,
usually an email | String |
| **userId** | unique identifier for the user | Integer |
| **teamId** | unique identifier for the team | Integer |
| **eventType** | one of "LOGIN\_EVENT",
"API\_CALL\_EVENT",
"DATABASE\_ACCESS\_EVENT" | String |
| **requestResult** | enum of either ATTEMPT, SUCCESS | String |
| **correlationId** | UUID of the request | String |
### Response Types
Response types are based on the `actionType` submitted within the request parameter. The available actionType values are API\_CALL\_EVENT, LOGIN\_EVENT, and DATABASE\_ACCESS\_EVENT.
**DATABASE\_ACCESS\_EVENT log:**
Enlarges the table by opening it in a full screen dialogOpen
| **Field** | **Description** | **Type** |
| ------------------ | -------------------------------------------------------------------------------- | -------- |
| **resourceType** | The type of resource being accessed. | String |
| **resourceId** | The id of the resource being accessed. | Integer |
| **action** | CREATE, READ, UPDATE, or DELETE | String |
| **queryArguments** | Parameters being changed in the resource
if it is a CREATE or UPDATE event. | String |
| **serviceSource** | The name of the service generating the event. | String |
**API\_CALL\_EVENT log:**
Enlarges the table by opening it in a full screen dialogOpen
| **Field** | **Description** | **Type** |
| ------------------ | ------------------------------------------------------------- | -------- |
| **urlSlug** | The url being requested. | String |
| **httpMethod** | The http method of the request | String |
| **requestHeaders** | The request headers. | String |
| **queryArguments** | The request body. | String |
| **statusCode** | The status code of the response. | Integer |
| **endpoint** | Enum with human readable
name for what the endpoint does | String |
**LOGIN\_EVENT log:**
Enlarges the table by opening it in a full screen dialogOpen
| **Field** | **Description** | **Type** |
| ------------- | ---------------------------------- | -------- |
| **loginType** | enum of either “LOGIN” or “LOGOUT” | String |
Example Response:
```json JSON theme={null}
{
"error": "",
"auditLogs": [
"{\"_id\": {\"$oid\": \"62c5dc0dd41f7023116bffb1\"}, \"resourceType\": \"FeatureFlag\", \"resourceId\": 1, \"action\": \"READ\", \"type\": \"DATABASE_ACCESS_EVENT\", \"timestamp\": \"2022-07-06T19:01:33.879Z\", \"userId\": 1, \"userName\": \"admin@lilt.com\", \"orgId\": 1, \"teamId\": 1, \"requestResult\": \"ATTEMPT\", \"correlationId\": \"89a954e2-a92f-4df9-8ce7-e20f2892882e\"}",
"{\"_id\": {\"$oid\": \"62c5dc0ed41f7023116bffb3\"}, \"resourceType\": \"FeatureFlag\", \"resourceId\": 1, \"action\": \"READ\", \"type\": \"DATABASE_ACCESS_EVENT\", \"timestamp\": \"2022-07-06T19:01:34.386Z\", \"userId\": 1, \"userName\": \"admin@lilt.com\", \"orgId\": 1, \"teamId\": 1, \"requestResult\": \"SUCCESS\", \"correlationId\": \"89a954e2-a92f-4df9-8ce7-e20f2892882e\"}",
"{\"_id\": {\"$oid\": \"62c5dc0ed41f7023116bffb4\"}, \"resourceType\": \"FeatureFlag\", \"resourceId\": 2, \"action\": \"READ\", \"type\": \"DATABASE_ACCESS_EVENT\", \"timestamp\": \"2022-07-06T19:01:34.386Z\", \"userId\": 1, \"userName\": \"admin@lilt.com\", \"orgId\": 1, \"teamId\": 1, \"requestResult\": \"ATTEMPT\", \"correlationId\": \"89a954e2-a92f-4df9-8ce7-e20f2892882e\"}",
}
```
# Overwrite Confirmed Segments
Source: https://support.lilt.com/kb/auto-propagation
Overwrite Confirmed Segments (formerly called Auto-Propagation) is a feature of [LILT Translate](/kb/introduction-to-lilt-translate) that saves linguists time by automatically completing and confirming repeated segments. Overwriting confirmed segments affects only the current document.
![]()
## Enabling the functionality
By default, forward and backward overwriting are both enabled. You can enable or disable overwriting confirmed segments through the `Settings` tab by selecting/deselecting the following options:
* \*\*Forward overwrite confirmed segments:\*\*Propagates changes to all segments going forward, i.e. all later repetitions. When a segment is confirmed, Forward overwrite copies the confirmed target text to all forward repetitions (including previously confirmed segments) in the document and marks those segments as confirmed.
* \*\*Backward overwrite confirmed segments:\*\*Propagates changes to all segments going backward, i.e. all previous repetitions. When a segment is confirmed, Backward overwrite copies the confirmed target text to all backward repetitions (including previously confirmed segments) in the document and marks those segments as confirmed.
![]()
Overwrite confirmed segments settings
## Use cases for Forward and Backward Overwriting
* Forward and Backward Overwriting are \*\*both enabled \*\*by default. This is a useful way to make sure translations are consistent across a document, because if you make a change to a segment, all segments with matching source text will update their target text to match.
* If you want to ensure you do not overwrite content in confirmed segments, **turn off both** Forward and Backward Overwriting.
* **Enabling only Forward overwrite confirmed segments** is a good way to speed up translation (by automatically populating segments you haven't reached yet), while making sure to not overwrite content in matching segments you have already processed.
* It is not common to **only enable Backward overwrite confirmed segments**.
Note that in Review or Secondary Review mode, with Forward or Backward overwrite confirmed segments enabled, changes to accepted segments will overwrite segments that are not part of the review sample.
# AWS Configuration
Source: https://support.lilt.com/kb/aws-configuration
### Background:
The first step when helping a customer set-up AWS credentials is to ask their IT department if they have:
* Keys for a user with TranslateFullAccess and AmazonS3FullAccess policies
* An S3 bucket that user has access to
If the customer does not have a keys for a user with that information or a bucket. Someone from their IT department will have to do the following:
## Access:
Configuring the AWS Configuration in AI Hub, will enable the customer to access all available services via the AWS Bedrock ecosystem, including:
* Amazon Titan Express
* AI21 Labs
* Anthropic Claude Models via Bedrock (Sonnet 4.5, Haiku 4.5, Opus 4.1, and Opus 4.5) for LILT Create
* Amazon Textract
* Amazon Transcribe
### Create a new user
* Search for IAM and select IAM.
* Select Users, “Create User”
*
![]()
* You do not need to select “Provide user access to the AWS Management Console”
* Attach policies directly
* TranslateFullAccess
* AmazonS3FullAccess
* AmazonTextractFullAccess (OCR Only)
* AmazonTranscribeFullAccess (ASR only)
*
![]()
* Now click Create User
* Search for the user created in the previous step and select
*
![]()
* Click Security credentials
*
![]()
* Click “Create access key”
*
![]()
* Select Third-party service, select Next
*
![]()
* Name the key
* Download .csv file this is your “AWS Access Key ID” and “AWS secret access key”. You will not be able to recreate the .csv
### Create AWS data access ARN
* Search for the user you created in “Create user” steps
* Click into the user
* Scroll down to Permissions policies
* Select “TranslateFullAccess”
* The ARN will be on the top right
![]()
### Create S3 Bucket
* Type in S3 in bar
* Click S3
* Create Bucket
*
![]()
* Choose an AWS region
* We recommend US-EAST-1
* Select a General purpose
* Name the bucket
*
![]()
* Unselect “block public access”
*
![]()
* Disable Bucket versioning
*
![]()
* (Optional) we recommend that you add a LILT tag, so that you can track your usage
*
![]()
* Click create the bucket
*
![]()
* Enter this bucket name into LILT’s Amazon credentials, and select the region the Bucket is assigned
### FAQs
Q: Which Amazon Translate **actions** do I need to include in the IAM policy?
A: Translate, S3 bucket
Q: Do specific **resource types** need to be indicated in the policy or the ARN?
A: Ideally yes, you would create a very specific IAM. Without specific resource types, someone could have more or less privileges than what you want on your AWS account.
Q: For the **ARN**, we need more information about what exactly is required. Is this for encryption?
A: No it is to access translate client, S3, and other resources needed for translation.
Q: What happens if we turn on the "**Use Terminology**" option? Will this create a terminology resource in AWS with our LILT glossary/TB or the other way around (it will use custom terminology already uploaded to AWS)?
A: LILT will send the terminology from the data source to AWS, and the terminology will be used in AWS.
# AWS S3
Source: https://support.lilt.com/kb/aws-s3
Connect your Amazon S3 bucket to LILT for seamless translation and localization workflows
## Overview
The S3 connector enables you to sync and manage translation files between your Amazon S3 storage and LILT platform. This connector provides real-time translation and localization support for your stored content, making it easy to manage multilingual content at scale.
During the process of onboarding a new client, LILT will help identify whether the AWS S3 integration can be used. If it can be used, LILT will set up the S3 integration for the client. From the client, we will utilize the following information:
* S3 Access Key ID
* S3 Secret Access Key
* S3 Region
* S3 Bucket name
For enhanced security, LILT can also connect to your S3 bucket using an IAM User account. This avoids needing to share your Access Key ID and Secret Access Key.
Alternatively, the client can provide SFTP access to the bucket through the SSH key. LILT will organize this configuration with the client.
## Workflow
Once the connector is configured, content is automatically moved between LILT and S3 as outlined in the sections below.
### Project creation
LILT periodically checks for new content on S3. When new content is detected, LILT Projects are automatically created for the content to be translated.
### Project completion
LILT periodically checks for completed LILT Projects. Completed Project content is automatically pushed back to S3 into the buckets specified during configuration.
## FAQ
**Question:** How often does LILT check for new content?
**Answer:** LILT periodically checks for new content and completed Projects. The frequency is determined during setup and can be as frequent as every 15 minutes.
**Question:** What file formats does the S3 connector support?
**Answer:** LILT will only import [supported files](/kb/supported-file-formats) for translation; it will ignore unsupported file formats.
# Azure Blob
Source: https://support.lilt.com/kb/azure-blob
LILT + Azure Blob Storage connector enables companies to automatically push and pull content between Blob and LILT. This saves you time by providing seamless localization while letting you continue to work in the systems you know.
## Configuration
During the process of onboarding a new client, LILT will help identify whether the Azure Blob integration can be used. If it can be used, LILT will set up the Blob integration for the client.
## Workflow
Once the connector is configured, content is automatically moved between LILT and Blob. With the LILT connector installed, the client will be able to automatically see "connector-input" and "connector-output" containers, which is where the client will be able to upload and import source and target files, respectively.
![]()
### Project creation
LILT periodically checks for new content on Blob. When new content is detected, LILT Projects are automatically created for the content to be translated.
### Project completion
LILT periodically checks for completed LILT Projects. Completed Project content is automatically pushed back to the individual Blob container, under "connector-output", specified during configuration.
## Limitations
LILT does not continuously check for new content; it only periodically checks for new content and completed Projects. The frequency that LILT checks for content is determined when the connector is set up and can be as fast as 15 minutes.
LILT will only import [supported files](/kb/supported-file-formats) for translation; it will ignore unsupported file formats.
# Back Up and Restore Elasticsearch
Source: https://support.lilt.com/kb/backup-and-restore-elasticsearch
## Overview
LILT runs Elasticsearch under the Elastic Cloud on Kubernetes (ECK) operator.
Elasticsearch holds the indices behind translation-memory search, user resources
and job search.
The installer does not configure a snapshot repository. Until you register one,
Elasticsearch has nowhere to write a backup to, so a new installation has no
backup even though the upgrade procedures tell you to take one. This article
covers registering a repository, taking and restoring snapshots, and rebuilding
the search index from the LILT database.
For the upgrade itself, see [Upgrade Elasticsearch Across Major
Versions](/kb/upgrade-elasticsearch).
Every command on this page assumes the LILT namespace is `lilt`. If you
installed into a different namespace, substitute it for `NAMESPACE`.
## Snapshot or rebuild?
Everything LILT stores in Elasticsearch is derived from the LILT database, so a
lost Elasticsearch cluster is a rebuild rather than permanent data loss. One
detail decides which path you take:
| | Restore a snapshot | Rebuild from the database |
| ------------------------------------ | ------------------ | ----------------------------- |
| Time to complete | Minutes | Hours on a large installation |
| Rebuilds the `segments` index | Yes | Yes |
| Rebuilds `user_resources` and `jobs` | Yes | No tool exists |
| Needs setup beforehand | Yes, a repository | No |
Set up snapshots even though the data is derived. A rebuild covers only the
`segments` index, so it is a partial recovery, and it is much slower. Use a
rebuild for a damaged or incomplete `segments` index, and a snapshot for the
loss of a cluster.
## Connect to the cluster
Every `curl` command on this page reaches Elasticsearch through a port forward.
Target a pod rather than a service: LILT applications reach Elasticsearch
through a service of type `ExternalName`, which `kubectl port-forward` cannot
use.
```bash theme={null}
NAMESPACE=lilt
ESPOD=$(kubectl -n $NAMESPACE get pods -l common.k8s.elastic.co/type=elasticsearch \
-o jsonpath='{.items[0].metadata.name}')
kubectl -n $NAMESPACE port-forward "pod/$ESPOD" 9200:9200 &
```
Leave this running while you work, and stop it when you finish. The shipped
cluster runs with TLS disabled, because Istio carries the transport security, so
these commands need no credentials. That is also a reason not to leave the port
forward open.
## Register a snapshot repository
Elasticsearch writes backups to a *snapshot repository*, which you register
once.
Elasticsearch includes S3 support, so both procedures that follow use the `s3`
repository type. A shared-filesystem repository is not an option: the
Elasticsearch volumes are `ReadWriteOnce` and a filesystem repository must be
mounted on every node in the cluster.
Add the credential settings to `eck-cluster/on-prem-values.yaml` or
`eck-cluster/eks-values.yaml`. A LILT release replaces those files, so
re-apply the settings after each upgrade and confirm that snapshots still
succeed. The repository itself is stored in the Elasticsearch cluster state
and survives an upgrade; the credentials that make it usable do not.
### On AWS with an S3 bucket
Your installation already has an AWS identity for S3: `install-s3-irsa.sh`
creates the `lilt-s3-workload` service account and binds it to the
app-workload IAM role. Run Elasticsearch as that service account rather than
creating a second role.
In `eck-cluster/eks-values.yaml`:
```yaml theme={null}
serviceAccount:
create: false
name: lilt-s3-workload
```
This works under both of the mechanisms the installer supports, so you do not
need to know which one your cluster uses.
Do not add an `eks.amazonaws.com/role-arn` annotation to the service account.
That annotation is correct only when `IAM_AUTH_METHOD=irsa`. When your
installation uses EKS Pod Identity, `install-s3-irsa.sh` deliberately
removes the annotation, because a leftover one takes precedence over the Pod
Identity binding and sends the AWS SDK to a web identity provider your
account may not have. Naming the service account, as shown, is correct
either way.
The app-workload role's policy has to allow the snapshot bucket. It is scoped
to the buckets LILT itself uses, so if you follow the recommendation to keep
snapshots in a separate bucket, add that bucket to the role's policy first.
Reusing the service account gives Elasticsearch the identity; it does not
widen what that identity may do.
If no AWS identity is available, store access keys in a Kubernetes secret
instead:
```bash theme={null}
kubectl -n $NAMESPACE create secret generic es-s3-credentials \
--from-literal=s3.client.default.access_key='ACCESS_KEY' \
--from-literal=s3.client.default.secret_key='SECRET_KEY'
```
Then reference the secret in `eck-cluster/eks-values.yaml`:
```yaml theme={null}
secureSettings:
- secretName: es-s3-credentials
```
The two key names are exact. They are Elasticsearch keystore entries, so a
different name is ignored.
Apply the change. A component script does not read `install.env` — only
`install-lilt.sh` and `install-lilt-eks.sh` load that file — so load it
yourself and set `VALS_FILE` on AWS:
```bash theme={null}
set -a; . ./install.env; set +a
VALS_FILE=eks-values.yaml sh install_scripts/install-elastic-eck-cluster.sh
```
On an on-premise installation, omit `VALS_FILE`.
Do not skip `install.env`. With `DNS_DOMAIN` unset the script stops with
`ERROR: DNS_DOMAIN is required`. If `DNS_DOMAIN` happens to be exported but
`REGISTRY_BASE` is not, the values resolve to a LILT-internal registry host
your cluster cannot pull from and the script completes anyway, leaving
Elasticsearch unable to start its image. The check that catches a missing
`REGISTRY_BASE` lives in the entrypoint, not in the component script.
The operator loads the credentials without restarting the cluster.
Register the repository:
```bash theme={null}
curl -s -X PUT 'localhost:9200/_snapshot/lilt-es-backup' \
-H 'Content-Type: application/json' -d '{
"type": "s3",
"settings": { "bucket": "BUCKET_NAME", "client": "default" }
}'
```
### On-premise with MinIO
An on-premise installation has no S3, but it does include MinIO. Point the same
repository type at it, and set an endpoint.
Create the credentials secret as described in the preceding section, using your
MinIO access key pair, then register the repository:
```bash theme={null}
curl -s -X PUT 'localhost:9200/_snapshot/lilt-es-backup' \
-H 'Content-Type: application/json' -d '{
"type": "s3",
"settings": {
"bucket": "lilt-es-snapshots",
"endpoint": "minio.lilt.svc.cluster.local:9000",
"protocol": "http",
"path_style_access": true,
"client": "default"
}
}'
```
Create the bucket first with `mc mb`.
Use a separate bucket, not the `lilt` bucket. The `lilt` bucket holds your
translation documents, so snapshots stored there share a failure domain with
the data they protect. Treat a MinIO snapshot as a convenience copy, and
replicate it to storage outside the cluster for disaster recovery.
### Verify the repository
A repository you have never verified is not a backup. Check that every node can
write to it:
```bash theme={null}
curl -s -X POST 'localhost:9200/_snapshot/lilt-es-backup/_verify'
```
A successful response lists the cluster nodes. A `403` or a
`repository_verification_exception` means the credentials or the bucket
permissions are wrong, and a snapshot fails at the moment you need it.
## Take a snapshot
Take a snapshot before every upgrade. Each version step changes the data on disk
and cannot be reversed.
```bash theme={null}
SNAPSHOT="pre-upgrade-$(date +%Y%m%d-%H%M%S)"
curl -s -X PUT "localhost:9200/_snapshot/lilt-es-backup/$SNAPSHOT?wait_for_completion=true" \
-H 'Content-Type: application/json' \
-d '{"indices": "segments,user_resources,jobs", "include_global_state": false}'
curl -s 'localhost:9200/_cat/indices/segments,user_resources,jobs?h=index,docs.count' \
> es-backup-baseline.txt
```
The response reports a `state`. `SUCCESS` means the snapshot is complete.
`PARTIAL` means some shards were unavailable and the snapshot is not a usable
backup: fix the cluster health and take it again.
Keep `es-backup-baseline.txt`. The document counts it records are how you tell a
complete restore from a partial one.
To take snapshots on a schedule, create a snapshot lifecycle management policy:
```bash theme={null}
curl -s -X PUT 'localhost:9200/_slm/policy/nightly' \
-H 'Content-Type: application/json' -d '{
"schedule": "0 30 2 * * ?",
"name": "",
"repository": "lilt-es-backup",
"config": { "indices": "segments,user_resources,jobs", "include_global_state": false },
"retention": { "expire_after": "30d", "min_count": 5, "max_count": 30 }
}'
```
## Restore from a snapshot
A restore replaces the contents of the indices it targets. Run it in a
maintenance window with LILT quiesced, otherwise the indexer writes into the
indices while the restore is in progress.
1. Close the indices you are restoring. A restore cannot write to an open index.
Skip this step when you restore into an empty cluster, where the indices do
not yet exist:
```bash theme={null}
curl -s -X POST 'localhost:9200/segments,user_resources,jobs/_close'
```
2. Restore the snapshot:
```bash theme={null}
curl -s -X POST "localhost:9200/_snapshot/lilt-es-backup/$SNAPSHOT/_restore?wait_for_completion=true" \
-H 'Content-Type: application/json' \
-d '{"indices": "segments,user_resources,jobs", "include_global_state": false}'
```
3. Reopen the indices:
```bash theme={null}
curl -s -X POST 'localhost:9200/segments,user_resources,jobs/_open'
```
4. Confirm that the cluster is healthy and the document counts match your
baseline:
```bash theme={null}
curl -s 'localhost:9200/_cluster/health?wait_for_status=green&timeout=120s'
diff es-backup-baseline.txt \
<(curl -s 'localhost:9200/_cat/indices/segments,user_resources,jobs?h=index,docs.count')
```
## Rebuild the search index from the database
Use this when the `segments` index is damaged or incomplete and you have no
usable snapshot. Read the scope limits at the end of this section before you
plan a recovery around this procedure.
Run the tool from the indexer pod, which has both database and Elasticsearch
access:
```bash theme={null}
kubectl -n $NAMESPACE exec -it deploy/indexer-core -- sh -c \
'./core-services/scripts/lltrun com.lilt.indexer.tools.ReindexMemoryTool reindexOrganization \
--orgId=ORG_ID --threads=4 --batchSize=1000 \
--dburl="jdbc:mysql://$DB_HOST:3306/DB_NAME"'
```
The command runs through `sh -c` inside single quotes so that `$DB_HOST`
expands in the pod, not in your own shell. Without the single quotes your shell
substitutes it first, and it is empty there.
Substitute the organization to rebuild for `ORG_ID` and your database name for
`DB_NAME`.
The pod's own environment supplies the rest. The database user and password
come from `DB_USER` and `DB_PASSWORD`, and Elasticsearch is reached through
`ELASTIC_HOST` with the default port and scheme, so none of those need a flag.
Pass `--dburl` even though the other connection details come from the
environment. The option reads the `DB_URL` variable, which the indexer pod
does not set — it sets `DB_HOST` instead. With no `--dburl`, the tool falls
back to `jdbc:mysql://localhost:3306/`, which fails to reach your database
rather than reporting a missing setting.
To rebuild named translation memories instead of a whole organization, use
`reindexMemory` with a comma-separated list of memory IDs:
```bash theme={null}
... ReindexMemoryTool reindexMemory --memoryId=12345,12346 \
--dburl="jdbc:mysql://$DB_HOST:3306/DB_NAME"
```
The tool removes each memory's existing documents from Elasticsearch, then reads
the confirmed segments back from the database. Rebuilding a memory is safe to
repeat, but it is not additive: if a run is interrupted, that memory is left
partly indexed, so run it again to completion.
### Scope limits
* **One organization per run.** `reindexOrganization` takes a single `--orgId`.
To rebuild every organization, run the command once per organization and track
which ones finished.
* **No progress reporting or retries.** The tool logs its own progress, and
nothing resumes it if it stops.
* **Only the `segments` index can be rebuilt.** The `user_resources` and `jobs`
indices are populated as LILT runs, and no tool rebuilds them. This is why a
snapshot repository is worth setting up even though the data is derived.
If you lose Elasticsearch with no snapshot, rebuild `segments` with the
preceding procedure and contact LILT support about the remaining indices.
## Related pages
* [Upgrade Elasticsearch Across Major Versions](/kb/upgrade-elasticsearch)
# Translator Rebuttal Best Practices
Source: https://support.lilt.com/kb/best-practices-for-rebuttal-translators-replying-t
## Translators Replying To Reviewers
Replying to reviewers' comments is essential to more accurately assess the applicability and validity of the issues raised during LQE or IR. It is important translators have this opportunity to back-up their choices and provide arguments for issues that are not visible to the reviewer. It is a chance for translators to improve possible Fail scores. For this, translators will receive the feedback provided by reviewers in the LQE form - please note the LQE form template may vary across customers.
This is the process that translators have to follow:
1. Get familiar with the instructions, and the Category and Severity descriptions to adhere to, which are described in the Review section.
2. Work on the ARBITRATION tab/columns in the LQE form.
3. Have a look at the issues reported (Source, Target, Category, Severity, and comment).
4. Based on this fill in the following columns - or the columns specifically requested in the HO.
![]()
![]()
## Column definitions
1. **Change implemented?** Please check the instructions from the PS/PM whether implementation is necessary or not.
2. **Valid error & categorization?**
1. Select YES if you agree not only with the issue reported, but with the issue category and severity as well
2. Select NO if you disagree with either the issues reported, and the category/severity, or both.
3. *Note: If you selected YES, you don’t need to fill in the rest of the columns. This means that this error will be counted in the penalization and will be considered for the final result.*
3. **If no, why?**
1. Select OVERPENALIZED if you think that the severity should be lower
2. Select UNDERPENALIZED if you think that the severity should be higher
3. Select MISCATEGORIZED if you think that the categorization should be different
4. Select OTHER
4. **Recategorisation**. If you had disagreed with the category, please select the one you think should be correct.
5. **Revised severity**. If you had disagreed with the severity, please select the one you think should be correct.
6. **Arbitration comment**. This field is mandatory. Here, you have to explain why you disagree with the reviewer's change or categorization. For writing comments correctly, adhere to the Adding Comments section above.
4. For writing these comments, keep in mind the KEY FOCUS AREAS mentioned above.
### Examples of arbitration comments
| **Do** | **Don’t** |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- |
| According to the reviewer’s comment/translation, the meaning of the translation is shifted, but these are just two different ways of saying the same. There is no change in meaning, and the original translation sounds more natural. | I think the suggested translations are wrong. |
| The original translation “XYZ”, which means “ABC” in English, is back translated as “ABC”. The suggested translation “XYZ” is also translated as “ABC”. Please consider this as a preferential change since the original translation conveys just the same… | Can you tell me how XXX is wrong? |
| The original translation adheres to the glossary/termbase available in LILT. The reviewer translation is using a different translation for the term “XXXX”. | The reviewer is wrong |
# Reviewer Best Practices
Source: https://support.lilt.com/kb/best-practices-for-reviewers-offline-lqe-lilt-revi
## Offline LQE, Review, And Secondary Review
## Selecting Error Typology
Each change made to the translation requires a Category and Severity.
* This is done ONLY if the segment was modified during Review/LQE. For assigning the correct categories and severities, you can:
* Review the [/kb/segment-comments#SegmentCommentsandErrorFlagging-ErrorTypology](/kb/segment-comments#SegmentCommentsandErrorFlagging-ErrorTypology) Knowledge Base page.
* Check the Categories and Severities tab of the LQE sheet that you received.
![]()
Tabs of an LQE sheet
* Categories and Severities are NOT needed if no change is made to the string.
* Only KUDOS severity can be used to highlight a particularly good translation or one that has a high positive impact.
### FAQs
* **What should I do if more than one error type is found in the same segment?** Mark only the highest severity and report it only once. In the comment, please explain all the changes. For example, if there was a shift in meaning and also a typo, use Accuracy - Major only.
* **What should I do if there are repeated errors?** The first time you see the error, mark it as usual by using a Category and Severity (Minor/Major/Critical). Starting the second time, use the same category but select the Repeated Error Severity. This should be done:
* If the segments are identical, or
* If the segments are different, but the error is the same. For example, an incorrect term used in different sentences, or incorrect punctuation for list items used in different segments.
## Adding Comments
LQE reports serve as communication tools between translators, reviewers, and other stakeholders, such as decision-makers, in the process of understanding and assessing the quality of the translations. For this reason, it is important that every aspect of the original translation that needs to be reconsidered includes a comment that clearly explains what the issue is.
When writing comments in LQE reports, consider the following audiences: **Client, LILT Production Team, Quality Manager, Reviewer, Translator.**
### Key Focus Areas
1. **Language clarity:**
1. Explain all errors clearly, regardless of severity.
2. Use language that all parties can understand, preferably English.
2. **Support with evidence:**
1. Provide logical and solid proof for suggestions or corrections.
2. Use references (links, glossaries, SGs, instructions, etc.), examples, or back translations to support your points.
3. **Professional tone:**
1. Maintain a polite and professional tone in all interactions.
2. Report any unprofessional behavior to your Point of Contact (PoC).
4. **Objectivity:**
1. Avoid personal bias.
2. Present arguments impartially, respecting diverse viewpoints.
5. **Precision and conciseness:**
1. Keep messages concise and to the point.
2. Be precise in your feedback.
6. **Back translations:**
1. Include back translations to clarify issues.
### What not to do
1. **Emotional feedback:**
* Avoid emotional or angry responses.
* Focus on rationale.
2. **Avoid exclamation marks and personalization:**
* Use neutral language.
* Refrain from rhetorical questions, rude comments, or irony.
3. **Defend, don’t attack:**
* Explain why a variant is incorrect, but do so professionally.
4. **Be subjective.**
5. **Be aggressive.**
6. **Use long sentences.**
* Opt for short, to-the-point sentences.
7. **Be personal.**
* Bear in mind the business context.
* Golden Rule: Treat others as you’d like to be treated.
#### Examples
| | | |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------- |
| **Category/Severity** | **Do** | **Don’t** |
| Fluency - Minor | Grammatical and syntax errors. Article " an" missing and quite repetitive. Please avoid this. | This is a grammar error |
| Fluency - Minor | "Lilt Page" should be written in title case, according to Glossary. | Use capitals!!! |
| Fluency - Minor | Inconsistent use of "newsroom" throughout the documents. Also, missing quotation mark at the beginning of the sentence. | Inconsistency and wrong punctuation |
| Accuracy - Major | "example applications" is mistranslated as "example apps" when it would mean "example use". ”Balloon" is mistranslated as "Ball” | Misinterpretation of the source |
| Accuracy - Major | The original translation uses “XXX” which means “xxxxx” (*backtranslation*). In this context, the source text means “xxx” which should be translated as “XXXXX” | “XXXXXX” should be “XXXXX” in the target language. |
| Accuracy - Major | The original translation is not appropriate for this context because it is commonly used in (a specific) field. In this context, “xxx” should be used. | “XXX” is incorrect/inaccurate Out of context |
| Terminology – Major | The correct term for “xxx” is “XXXX” according to the glossary provided/according to specific industry terminology. | Here ,“XXXX” should be used. |
| Terminology – Major/Minor | As per glossary, the correct terminology is “XXX” \*a “more correct” term can always be suggested, but then it should take the “Neutral” severity, so it does not count as an error. | “XXX” is more correct/appropriate |
| Accuracy - Major | The original translation back translates “xxxx”, which doesn’t correspond to the source text. | The translation is wrong |
| Accuracy - Major | The word template is translated wrongly. “Unkaa” means 'form', the correct term is qajojiila | Wrong translation |
| Accuracy - Major | “dropdown” was mistranslated as “expand” | The whole sentence is mistranslated regarding the English version |
| Accuracy – Major/Minor | -The translation for the word "can" is missing. The full translation should be …. -The translation for "use" (uso) is added to the target text. It is not present in the source text. -In the source “Is this how you want it to sound?”, the translator has translated; "Would you like your voice to be like this?" While there is no "your voice" in the source. | Added words |
| Accuracy – Major/Minor | "Endorsement" is omitted in the target text. | Omission/ Missing word |
| Fluency - Minor | According to target language rules, there should be a space in between "XX" and "XXXX | Add a space |
| Fluency - Minor | Full stop is missing between the last 2 sentences. | Incorrect punctuation |
| Fluency - Minor | The sentence should start with capital letter as per standard rules | Incorrect capitals |
| Terminology - Minor | -The translation for the word "Profile" is not consistent through the file. It should be translated as "កម្រងព័ត៌មាន" rather than "ទម្រង់ព័ត៌មាន" -The translator has used two words "bertek" and "Paşrakışından" for the word "Feedback", for the consistency of the translation, it is better to use the word "bertek" which is more specialized | Inconsistent translation |
| Fluency – Major/Minor | All objects and phenomena are divided into masculine and feminine in the Kurmanji dialect, and the suffix "a" or "ê" is added to them at the end of the word in relation to the gender, Tim is feminine in Kurmanji, so it takes the suffix "a" instead of suffix "ê" | Wrong gender |
| Style - Neutral | The reviewed target improves the fluency of the original translation by replacing "ផ្តល់ឱ្យ" (give) with "អនុញ្ញាតឱ្យ" (allow), which is more natural in the context of granting access. The reviewed target improves the original translation by removing the word "ដែល" (which) before "ប្រហែលជា" (maybe). This change makes the sentence more concise and natural-sounding, eliminating an unnecessary word that does not add to its meaning. | Style Improvement |
| Style - Neutral | Sentence structure was adjusted for better readability. | The translation sound awkward |
| Style - Neutral | The reviewed target translation is a more fluent and natural way to express the idea in Khmer. The word order is adjusted slightly, and the word "កាន់" (meaning "to") is added to make the sentence smoother. The reviewed translation is a good improvement over the original and should be preferred for its naturalness and clarity. | It is unnatural |
# Bi-Directional Text Marks
Source: https://support.lilt.com/kb/bi-directional-text-marks
[LILT Translate](/kb/introduction-to-lilt-translate) supports right-to-left (RTL) and left-to-right (LTR) directional marks. These controls are used to determine the way adjacent characters are grouped with the respect to text direction.
As an example, let's look at the phrase: *"The language C++ is a programming language used..."*
When translating from English to Arabic without an LTR mark, the browser will render the phrase into this:
لغة ++C هي لغة برمجة تستخدم...
With an LTR entered inserted after *"C++"*, it will render as the writer intends:
لغة C++ هي لغة برمجة تستخدم...
This [video demo](https://lilt.wistia.com/medias/qamps918q6) in a previous version of LILT Translate further demonstrates how directional marks work.
Directional marks can be added into the target text field from the `Insert` tab. Add a mark directly after the word you want to set directionality on.
![]()
You can also insert marks by using the following keyboard shortcuts:
| **Marker** | **Windows Shortcut** | **Mac Shortcut** |
| ------------------- | -------------------- | ---------------- |
| Right-to-Left (RTL) | Ctrl + K | ⌘ + K |
| Left-to-Right (LTR) | Ctrl + L | ⌘ + L |
# BitBucket
Source: https://support.lilt.com/kb/bitbucket
This guide provides step-by-step instructions for configuring and utilizing the BitBucket Server connector with minimal configurations for ensuring a successful round trip.
## Overview
Once all configuration parameters are set, the connector will be able to:
* Clone the source branch from your repository
* Process files for translation
* Push translated files to the delivery branch
* Create pull requests with the specified template
## Configuration
1. Configure Bitbucket Host.
**Parameter:** Bitbucket Host
**Description:** The base URL of your BitBucket Server instance. This is typically unique for each client.
**Examples:**
* Testing environment: `http://34.72.91.92:7990`
* Customer environment: `https://salesforce.bitbucket.com/`
2. Set Bitbucket project key.
**Parameter:** Bitbucket Project Key
**Description:** The project key required for API requests.
**How to obtain:**
* Navigate to **Projects** in BitBucket Server.
![Proj 1 Pn]( "Proj 1 Pn")
* Select the project containing your repository
* Go to **Project Settings**.
![Proj 2 Pn]( "Proj 2 Pn")
* On the **Project Details** page, locate the **Project Key**.
![Proj 3 Pn]()
* Copy the key and paste it into the connector configuration
3. Configure repository name.
**Parameter:** Bitbucket Repository Name
**Description:** The name of the repository to connect to.
**How to obtain:**
* Navigate to your target repository.
![Repo 1 Pn]( "Repo 1 Pn")
* Go to **Settings**.
![Repo 2 Pn]()
* On the **Repository Details** page, find the repository name (test-qa).
* Copy and paste it into the connector configuration.
4. Set Git Repo URL.
**Parameter:** Git Repo URL
**Description:** The full repository URL used for Git operations.
**How to obtain:**
* Navigate to your target repository.
![Repo 1(1) Pn]()
* Go to **Settings**.
![Repo 2(1) Pn]()
* On the **Repository Details** page, locate the repository URL.
![Repo Url 2 Pn]()
* Copy the URL and paste it into the connector configuration.
5. There are two ways to use this connector. We outline both below. Bitbucket\_Server will have a dynamic source branch selection enabled but also inherits the regular Git connector single source branch.
1. Single source branch flow
2. Dynamic source branch flow
6. Generate Bitbucket API token.
**Parameter:** Bitbucket API Token
**Description:** A user-specific access token used by the connector to create pull requests via the BitBucket API.
**How to generate:**
* Navigate to **Manage Account** (User Settings).
![Api 1 Pn]()
* Select **HTTP Access Tokens**.
![Api 2 Pn]()
* Click **Generate Token**.
![Api 3 Pn]()
* Grant **Read** and **Write** permissions.
* Copy the token immediately (it can only be copied once).
* Save the token in the connector configuration.
***Important:*** This token is associated with a specific user account. When a pull requests is created, it points to the account for which the token is generated. It MUST NOT be a Bitbucket GIT Token.
7. Set Bitbucket account user.
**Parameter:** Bitbucket Account User
**Description:** The username of the BitBucket account for which the API token was generated (from Step 7).
8. Generate Bitbucket GIT token.
**Parameter:** Bitbucket GIT Token
**Description:** An HTTP access token used specifically for cloning and pushing to the repository via Git.
**How to generate:**
* Navigate to your target repository.
![Repo 1(2) Pn]()
* Go to **Settings**.
![Repo 2(2) Pn]()
* Select **HTTP Access Tokens**.
![Repo 2(3) Pn]()
* Click **Generate Token**.
![Repo 4 Pn]()
* Grant **Read** and **Write** permissions.
* Copy the token immediately (it can only be copied once).
* Save the token in the connector configuration.
**Note:** This is separate from the API token and is used for Git operations ONLY. Do not use it for BitBucket API Token configuration.
9. Configure pull request template
**Parameter:** Bitbucket Pull Request Template
**Description:** The title template used for pull requests created by the connector.
**Example:** `[Translation] {language} - {date}`, `Update translations for {target_locale}`
## Configuration example
```
{
"project_prefix": "[QA] BitBucket Server v1",
"target_memories": {
"de-DE": {
"id": 14384
}
},
"lilt_api_key": "redacted",
"fs_export_path_map": {},
"git_delivery_branch_template": "wwtest-new-branch-newwww",
"git_repo_url": "http://34.72.91.92:7990/scm/test/test-qa.git",
"git_source_branch": "main",
"bitbucket_access_token": "BBDC-NTAxMzI0NjkxMDE0Oq9H+QWjb8zFB0redacted",
"bitbucket_pr_template": "test-template",
"bitbucket_project_key": "TEST",
"bitbucket_repo_git_token": "BBDC-MjIxNzQzMDk0OTI4Oo2Ji8Q+n8014redacted",
"bitbucket_repo_name": "test-qa",
"bitbucket_username": "victor.danila",
"bitbucket_host": "http://34.72.91.92:7990",
"lilt_translation_workflow": "MT"
}
```
# Box
Source: https://support.lilt.com/kb/box
LILT + Box connector enables companies to automatically push and pull content between Box and LILT. This saves you time by providing seamless localization while letting you continue to work in the systems you know.
## Configuration
During the process of onboarding a new client, LILT will help identify whether the Box integration can be used. If it can be used, LILT will set up the Box integration for the client. From the client, we will utilize the following information:
* Client ID
* Client Secret
In Box, under **Authorization**: Make sure you authorize and enable the app. (This will send you an email to let you know the app has been authorized).
![]()
## Workflow
Once the connector is configured, content is automatically moved between LILT and Box as outlined in the sections below.
### Project creation
LILT periodically checks for new content on Box. When new content is detected, LILT Projects are automatically created for the content to be translated.
### Project completion
LILT periodically checks for completed LILT Projects. Completed Project content is automatically pushed back to Box into the buckets specified during configuration.
## Limitations
LILT does not continuously check for new content; it only periodically checks for new content and completed Projects. The frequency that LILT checks for content is determined when the connector is set up and can be as fast as 15 minutes.
LILT will only import [supported files](/kb/supported-file-formats) for translation; it will ignore unsupported file formats.
# Braze
Source: https://support.lilt.com/kb/braze
Enhance your outreach through Braze by integrating with LILT’s powerful translation services. Seamlessly localize your campaigns to resonate with diverse audiences across the globe.
* Effortlessly translate your messages, ensuring that your content in Braze, including email campaigns are accurately localized.
* Access over 60 languages to precisely target and engage your desired audience segments.
* Verify translations beforehand to maintain brand consistency and message accuracy, ensuring your content aligns perfectly with your brand identity.
## Getting started
**Braze API Key**
1. Sign in to your Braze Account
2. Generate a Braze API key [here](https://dashboard-03.braze.com/app_settings/developer_console/apisettings/63c8600b02eb1a729e06564d?locale=en) and provide LILT with key via an email to [Solutions@lilt.com](mailto:Solutions@lilt.com)
3. Enable all permissions under `template`
![]()
4. Set up LILT Tags: Settings > Manage Tags > Add New Tag
1. `LILT: Ready`
1. Indicates projects that are ready to be sent to LILT for translation
2. `LILT: In progress`
1. Indicates projects that are being pulled into LILT
3. `LILT: Sent to LILT`
1. Projects that are currently going through the LILT localization workflow
4. `LILT: Delivered`
1. Projects that have been delivered back to LILT
5. `LILT: Needs Attention`
1. Projects that have an error and need the user to fix before submitting to LILT
![]()
**Braze API Base URL.**
1. Grab this information from your API endpoint: [https://dashboard.braze.com/](https://dashboard.braze.com/)
![]()
## How to send content for translation
1. Select the pages or content you want to translate.
2. Choose “`LILT: Ready`" from the tags you created above. From there, the LILT connector will pick up new jobs every 15 minutes *(the timing can be less frequent)* with this tag.
1. If you want only send one language at a time, you will need to create a new Language-only tag, such as `LILT: Translate de-DE`
![]()
3. If you’d like to submit for Instant Translate instead of Verified Translation, add the `LILT: Instant tag`
![]()
4. When the content translation is in progress, the status will show as `LILT: In Progress`
5. When the content translation is delivered back to Braze, the status will show as `LILT: Delivered`
![]()
6. When the content translation process has an error or issue in delivery, the status will show as `LILT: Needs Attention`
![]()
# Brute Force Protection
Source: https://support.lilt.com/kb/brute-force-protection
The **bruteforce protection** enables safeguarding LILT app from unidentified logins. Here are the default values:
* Default no. of failed consecutive attempts: 5 (user will get blocked in the 5th attempt, this is configurable)
* Default block duration: 2 mins
* Total failed attempts per day / IP: 30 (Configurable)
## Unblock users
### Using `admin-cli` / `npm run dist-admin-cli` commands
\*\*NOTE: For LILT November 2023 release onwards, please use **`npm run dist-admin-cli`** instead of **`admin-cli`**.
Administrators of self-managed instance can now use two new `admin-cli` / `npm run dist-admin-cli` commands:
#### Connect to front pod
```bash theme={null}
kubectl exec -it -n lilt -- /bin/bash
```
#### Updating the max consecutive failed attempts and block duration
```bash theme={null}
yarn admin-cli update-max-failed-login-attempts -m [-b ]
```
```bash theme={null}
npm run dist-admin-cli -- update-max-failed-login-attempts -m [-b ]
```
* With `updatedMaxConsecutiveLogins` being a `number` that updates the default max consecutive failed login attempts before a user is temporarily blocked. Flag: `-m` .
* With **the optional argument** `blockDuration` being a `number` that represents the minutes a user is blocked from attempting to login after reaching the max consecutive failed login attempts. Flag: `-b` .
* If `blockDuration` is set to `-1`, users will be blocked indefinitely, and should be manually unblocked by admins in order to resume use of their accounts.
* If `blockDuration` is set to `0` , the block duration defaults back to the platform’s default value of `2` minutes (default value subject to change in the future).
#### Unblocking a user
\*\*NOTE: \*\*\*\*For LILT November 2023 release onwards, please use **`npm run dist-admin-cli`** instead of \*\*`admin-cli`
```bash theme={null}
yarn admin-cli unblock-user -e
```
```bash theme={null}
npm run dist-admin-cli -- unblock-user -e
```
* With `email` being a `string` for the blocked user's LILT email.
* The command will unblock user who has been blocked due to multiple consecutive failed login attempts.
### Unblock IP restrictions
To check and unlock IP restrictions, follow below method:
* Connect to `redis` pod:
```bash theme={null}
I have no name!@cache-redis-6bd6c7f95c-cs9zf:/$ redis-cli --tls \
--cert /opt/bitnami/redis/certs/tls.crt \
--key /opt/bitnami/redis/certs/tls.key \
--cacert /opt/bitnami/redis/certs/ca.crt
127.0.0.1:6379> auth dummypass
OK
127.0.0.1:6379> KEYS *fail_ip_per_day*
1) "fail_ip_per_day:12.0.170.98"
127.0.0.1:6379> GET fail_ip_per_day:12.0.170.98
"97"
```
* To reset it, delete the key-value pair, which in this case would probably go something like this:
```powershell theme={null}
DEL fail_ip_per_day:12.0.170.9
```
* To unblock consecutive user lockouts, connect to redis and remove\* the keys with `*fail_consecutive_ip*` prefix.
# Bulk Document Actions
Source: https://support.lilt.com/kb/bulk-document-actions
LILT's batch document actions help save you time by making document management and assignment as easy as possible. This article goes over the actions that can be performed on multiple documents. To learn about single document actions, see the [Document Actions](/kb/document-actions) article.
In order to perform actions on multiple documents at once, you will need to select the desired documents.
* Use the `Select all documents` button to select all Document cards.
* Use the `Deselect all documents` button to deselect all Document cards.
* Document cards can be selected and deselected individually by clicking on the checkbox next to the document name.
![]()
Once the desired Documents are selected, you can select one of the following options to perform:
* Assign
* Pretranslate
* Delete
These operations are described in the sections below.
## Bulk assigning
When one or more Document cards is selected, click the `Assign` button to assign a translator or a reviewer to the documents. You can also optionally set due dates for translators and reviewers. Once you have selected a translator or reviewer, clicking the `Assign` button will assign them to the document and send them an email from [noreply@em.LILT.com](mailto:noreply@em.lilt.com) letting them know they have been given an assignment.
For more information, see the [Document Actions](/kb/document-actions) article.
## Bulk pretranslating
When one or more Document cards is selected, click the `Pretranslate` button to [Instant Translate](/kb/pretranslating-documents) all the documents using the Data Source associated with the project.
## Bulk deleting
When one or more Document cards is selected, click the `Delete` button to bring up a popup form that confirms you want to permanently delete all the selected documents from the project.
![]()
# ICU + Plurals
Source: https://support.lilt.com/kb/cat-icu-plurals
## **Review and Instant Workflows**
LILT does not support ICU plurals in Instant translation, whether Instant runs alone or as the first stage of a workflow (e.g. Instant > Review).
If an exact match exists for a segment containing ICU plurals, LILT will still populate it. If no exact match exists, the plural forms remain empty.
When this happens, the Expert reviewing the segment sees an empty plural modal and must populate each plural form manually.
## Translate workflow stage
LILT's ICU and Plurals modal allows Linguists to navigate LILT Translate and modify all of the forms for both the source and target languages. The number of forms for both source and target are automatically determined by the [Unicode CLDR rules](https://www.unicode.org/cldr/charts/45/supplemental/language_plural_rules.html) for that language; however, a linguist can easily delete an existing form or “Add another” depending on the sentence and context.
![]()
### Pretranslate and Data Sources
After a segment containing plurals has been translated it will appear in the Data Source entries. Future source text with the exact number of forms and segment text will match 100%, and the Data Source will be leveraged. If pretranslation is used in Translate workflows, the target will be populated with Data Source entries if the match score is greater than 75%.
## **What we don’t support**
* We do not support non-standard formats which would produce errors in the ICU parser, iOS compiler, or Android compiler
* We do not support iOS strings catalog
* Tags within plurals
* Instant, MT or pretranslation within the plural modal. Linguists will not receive plural form suggestions.
# Character Limits
Source: https://support.lilt.com/kb/character-limits
## Overview
LILT enforces character limits across all verified workflows to ensure translated segments meet length requirements defined by source files. Character limits are supported for existing character-limited file types via connector and XLSX files.
## How Character Limits Work
### Pretranslation
* **100% TM matches that exceed the character limit** are populated but unlocked for editing, and considered new words.
* Instant translations which exceed the character limit will also always be unlocked.
### In the CAT Editor
* Linguists **cannot confirm a segment** that exceeds the character limit. A warning is displayed when attempting to confirm an oversized segment.
* The character limit is visible in the segment metadata in the field `max_char_limit` so linguists can adjust translations accordingly.
![Image]()
## What's Out of Scope
* **Multi-segment character limits** (a single limit shared across multiple segments in a paragraph) are not currently supported.
* **Setting character limits at the domain level** is not supported.
* **Tag inclusion/exclusion** from character count calculations is not configurable at this time.
# Contacting LILT
Source: https://support.lilt.com/kb/communication-guidelines
## Payment Support
If you have any questions about payments, payment policy, or payment rate, please raise a **Payments ticket** via the [LILT Help Center](https://lilt.atlassian.net/servicedesk/customer/portals), where our team is available to assist you.
When contacting us, please provide as much information as possible so we can help you more quickly:
* Fully describe your issue or question.
* Include any screenshots you believe may be helpful.
* Provide any relevant customer names and project names.
* If applicable, include the pay period you have a question about.
We commit to responding to you within 24 hours to acknowledge receipt of your inquiry and that it is being processed in the queue. We aim to resolve each inquiry within 1 week; however, resolving more complex issues may take longer. The payments team continually works through the queue to help everyone as fast as possible; we appreciate your patience and understanding.
## Project-related questions
There may be other translators experiencing similar issues! Each project-specific Discourse Workspace has a general channel to communicate with all language groups for a particular project. For questions specific to your language pair, post your queries in your language channel. Language channels will be marked with your target language (example: #customer\_ko\_ko). Please also keep in mind: there may be a designated Language Lead in your language channel who can answer your question!
When reaching out with questions, it is most helpful to include the following:
* A specific description of the issue
* Your question
* Screenshots, if applicable
* Link to LILT project URL
## Project-related updates
Openly communicating on project updates in real time with LILT and customers is essential to managing deadlines and expectations to keep everyone in the loop!
**If you have a deadline update**, please reach out to your Language Lead (if applicable) or to [services@lilt.com](mailto:services@lilt.com).
Please give a detailed, succinct description of your question so we can help as best we can!
## Recommendations
We love recommendations! Please send any recommendations to [translators@lilt.com](mailto:translators@lilt.com) and our team will get in touch.
## General queries
We use Discourse to keep our project communication both open and organized.
While we encourage sharing general questions and feedback, it's important to make sure your message is going to the right person or channel, especially if it's a sensitive topic.
If you're not sure where your question or issue fits in, send your query to [translators@lilt.com](mailto:translators@lilt.com), and we'll point you in the right direction.
## Product feedback
We love product feedback! If you have ideas for how we can make LILT better, please submit a ticket through our [Help Portal](https://lilt.atlassian.net/servicedesk/customer/portals) with a specific description of what you would like to see improved in the tool.
If something's not working correctly in the platform, you can also submit a ticket through our [Help Portal](https://lilt.atlassian.net/servicedesk/customer/portals) and describe the issue. Our team is here to help!
# Concordance
Source: https://support.lilt.com/kb/concordance
Concordance assists translators and reviewers by providing quick access to information about word and phrase usage in a target language. The Concordance sidebar is available right in [LILT Translate](/kb/introduction-to-lilt-translate), allowing linguists to work faster by keeping more of their work in one place.
The concordance search pulls data from the following sources:
* **Public data:** There is a static set of public concordance data that is available to everyone.
* **Memory data:** All data that you add to your own Data Sources, either by uploading TMX files or by performing translation in the tool.
* **Concordance-only data:** When uploading TMX files, you can choose the option "for concordance only", in which case it will be indexed for concordance but not used to train the MT or as TM results.
![]()
# Configuring GPU Worker Counts In LILT
Source: https://support.lilt.com/kb/configuring-gpu-worker-counts-in-lilt
## Overview
This article details how to manipulate the helm-chart customization to set the number of GPU workers.
## Steps
Any customizations made your installation should be made in the `install_dir/lilt/environments/lilt/values.yaml` file. In order to edit the GPU worker counts, open this file in a text editor.
### V4 Language Model GPU Worker Count
To edit the amount of GPU worker counts, set the following values:
```bash theme={null}
batchv4:
onpremValues:
config:
# Maximum number of GPU workers. Can be set to 0 to disable GPU workers.
# In an environment without autoscaling, this number of workers will
# be up at all times.
BATCH_WORKERS_MANAGER_GPU_MAX_WORKERS: 1
# The standby workers option should only be modified in environments that use autoscaling.
# It controls the minimum number of GPU workers that are kept running at
# any given time, even when there are no batch jobs in progress.
BATCH_WORKERS_MANAGER_GPU_STANDBY_WORKERS: 1
batch-worker-gpu:
onpremValues:
# The number of replicas is controlled by BatchWorkersManager.
replicaCount: 1 # this should match BATCH_WORKERS_MANAGER_GPU_MAX_WORKERS
```
# Connector Login Credentials
Source: https://support.lilt.com/kb/connector-login-credentials
Below are useful scripts and CLI commands to setup and manage connector applications. A proper connector deployment has about 9 services but the `manager-ui` is the most important. It provides the admin UI portal for a user to create connectors, trigger a job and create organizations.
Connector services:
* beehive
* configuration-api
* events-consumer
* login
* manager-ui
* monitor
* plugin-api
* token-proxy
* webhooks
* webhooks-consumer
## Connectors Domain
The Connectors Admin panel is accessible by default at [https://bare.lilt.com/connectors-admin](https://bare.lilt.com/connectors-admin).
By default, the self-managed installation configures the [connectors-api-bare.lilt.com](https://connectors-api-bare.lilt.com) subdomain with the corresponding certificates. Once the LILT installation is complete and all the LILT apps are running correctly, you should be able to access the **connectors-admin UI** by mapping the IP of the worker node on your local machine to [connectors-api-bare.lilt.com](https://connectors-api-bare.lilt.com) (in Linux distributions, **/etc/hosts** is often the main file that holds such mappings).
The new entry at /etc/hosts, will be similar to this:
```
34.121.21.233 connectors-api-bare.lilt.com
```
Once that's done, you could ping the URL [connectors-api-bare.lilt.com](http://connectors-admin-bare.lilt.com), and you should get the IP of the node. If that's correct and the LILT apps are running properly, you should be able to go to the browser and enter the following: [**https://connectors-api-bare.lilt.com**](https://connectors-admin-bare.lilt.com)
## Create user credentials for UI portal
**NOTE:** From LILT versions `lilt-enterprise-2024.02.08` or later, the username and password are `admin`/`admin` by default.
The admin portal UI doesn't have the capability to add users with buttons and also it doesn’t manage user privileges. To put it briefly, every user is an admin. There is python command `tools.manage_users` for creating login users.
```sh theme={null}
python -m tools.manage_users create --username --password
```
**NOTE**: You must run the script inside one of the connectors Kubernetes pods, preferably the `manager-ui` pod.
First display all the running connectors pods from your kubernetes namespace
```powershell theme={null}
$ kubectl get pods -n
# output
lilt-manager-ui-dcfddd97c-5xd26 1/1 Running 5 (11h ago) 11h
lilt-monitor-58df986bc9-c86d9 1/1 Running 5 (11h ago) 11h
lilt-plugin-api-5b9f4c6f4f-mc5jt 1/1 Running 5 (11h ago) 11h
lilt-token-proxy-fb997f96b-pql9m 1/1 Running 0 11h
lilt-webhooks-85475cc977-wzqfw 1/1 Running 5 (11h ago) 11h
lilt-webhooks-consumer-7c98b956f8-pz67p 1/1 Running 0 11h
....
```
You can now attach your console to the `manager-ui` pods
```sh theme={null}
$ kubectl exec -it lilt-manager-ui-dcfddd97c-5xd26 bash
```
Create a login user `admin` with password `admin`
```
python -m tools.manage_users create --username admin --password admin
```
Now go to your browser and login to portal, you should see:
![]()
# Connectors
Source: https://support.lilt.com/kb/connectors
LILT has the ability to connect with different technologies to provide continuous localization, file sharing, and communication.
Our process is simple:
1. LILT sources your very own dedicated translator team.
2. LILT trains the dedicated team on your unique style.
3. You send us content via an API or connector.
4. The dedicated team translates the content.
5. The translated content is automatically sent back to you via the API or connector.
This automatic import and delivery of content ensures maximum efficiency and flexible configuration into your content creation process.
***
# Contacting Support
Source: https://support.lilt.com/kb/contacting-support-submitting-feature-requests
You can contact support directly through [LILT’s Help Desk](https://lilt.atlassian.net/servicedesk/customer/portals). You can navigate to the Help Desk by clicking on the ![]()
icon next to your Profile avatar and Inbox at the bottom of the left sidebar.
![]()
# Contentful
Source: https://support.lilt.com/kb/contentful
LILT + [Contentful](https://www.contentful.com/) connector enables companies to automatically push and pull web content between Contentful and LILT. This saves you time by providing seamless localization while letting you continue to work in the systems you know.
The LILT + Contentful Connector is built on the principle of field-level localization. By working on a field-level localization, you can ensure localization consistency across stakeholders, while also providing a stable environment for LILT's connector infrastructure.
This Knowledge Base article will cover all of the necessary steps for install, configuration and use, as well as an FAQ with additional info and tips!
## Installing and Configuring the LILT Connector
1. To install the LILT Connector, start by going to Apps > Manage Apps in your instance of Contentful. In the list of Available apps, you will find LILT > Install.
![]()
2. In the Install pane, you can find more information about this Connector. You can review LILT's website and documentation, and send any questions to our support team.
3. Once you click Install, authorize access for the LILT app to connect with Contentful
![]()
4. To configure your application, you have one of two options
1. Option 1: Configure via your Contentful account
1.
![]()
2. Option 2: Configure via your LILT account
1.
![]()
5. Finally, you can add LILT to your Contentful sidebar. Navigating to `Content Model`, (and for each content type you want to enable the LILT app for), open the content type, click on `Sidebar`, add the LILT app to the custom sidebar, and click `Save`.
![]()
6. Prior to a demo or a POC, you will need to provide your LILT Account Manager with the following information to ensure that the necessary configurations are enabled for integration between your LILT and Contentful instances.
1. Contentful Space ID
2. Contentful Environment ID
3. List of enabled Content type IDs\*(Pulled from Content Models)\*
4. Contentful Management Token
5. Language Pairs
6. Confirmed Link Depth
***
## Setting up Content Models for Translation
As LILT works with Contentful for field-level localization, there are certain parameters that must be met within the content model to ensure a stable environment. Now that you've added LILT as an app in the sidebar for the content models you would like to localize, there are a few final steps to ensure LILT is ready to handle translations at scale!
There are two required fields - `LILT Status` and `LILT Metadata`- that will auto-populate. Activate this by completing the following:
1. Add LILT to your sidebar
2. Ensure there are fields enabled for localization
3. Go to `Content`>`Create a new entry`
4. Re-load page to initialize the LILT Connector
5. Return to your content model, and you will now see that the two fields have been automatically added
6. Change the `LILT Metadata`field to “Show field when editing”. The field will automatically change to “Disabled in response”, which is the necessary setting.
![]()
***
## Sending a Request for Translation
By adding LILT to your content model sidebar, your team can easily view localization statuses and send requests for translation at any time using the steps below.
### Project creation
1. In Contentful, open a content piece and click the`Send for Localization`button under LILT in the sidebar. A popup will appear where you’ll be able to select translation type and your target languages.
![]()
2. Select Translation Type & Target Language. If your LILT instance has both Instant and Verified Translation configured, you will be able to select your Translation Type between the two.
A few tips and tricks:
1. The selection you make will persist across future localization jobs. You don’t have to set the Translation Type every time you send the entry for localization.
2. If the entry is in a Release you can use “Manage Other Entries” to batch set the Translation Type for multiple entries at once.
3. With both Verified and Instant Translate, the Entry isn’t pulled into LILT right away. It will still get picked up by the scheduler like all other Contentful Entries.
4. If you're interested in both Instant and Verified Translation and do not see the option to select Translation Type, please discuss with your LILT Account Manager.
3. In the same popup, you will find be able to select your Target Language either by search or checking the respective boxes. Make your language selections and click`Submit`.
![]()
### Project Statuses
1. Once submitted for localization, the status will change to “Ready to start.” This status is how our Connector identifies entries that are ready to be picked up for localization.
![]()
2. LILT periodically checks Contentful for content that has been sent for localization with LILT. When this content is found, LILT Projects are automatically created that contain the content to be localized. Once the content is pulled into LILT, the content sidebar in Contentful will display`In Progress`.
![]()
3. LILT periodically checks for Projects marked as `Done`. When this is detected, the translated content is automatically sent back to Contentful.Your language pair statuses will update in real time as they are delivered.
![]()
4. To view your translations, ensure you have multiple locales selected on your sidebar. Once all languages are completed to satisfactory quality, click`Complete Localization` to finalize the content and prepare it for publishing.
### Using Contentful Release Functionality with LILT
The “Release” functionality in Contentful can be used to bulk export Entry IDs to send to LILT for Translation. This is another way you can set up your workflow for the LILT + Contentful connector.
Here's a quick walkthrough of what this process looks like as a whole!
[LILT - Contentful - Release Functionality.mp4](../__attachments/11305109/LILT%20-%20Contentful%20-%20Release%20Functionality.mp4?inst-v=8633d73d-9ae2-4b9a-ace9-a81b872bab86)
***
## LILT Create
LILT Create is integrated into the Contentful app ecosystem, which allows creation of on-brand, AI-generated multilingual content directly within Contentful's content models, saving time and streamlining workflows. Because LILT specializes in brand-specific translation, users can generate content across any number of languages with the same prompt - making content ready to publish globally in partnership with regional marketing teams significantly faster than possible through traditional translation workflows.
#### What is LILT Create?
LILT Create is a new, multilingual content generation product that allows users to quickly create on-brand, locally relevant content in any language. LILT Create pairs your company context and linguistic assets with LLMs to instantly generate enterprise-grade content for the user to review, tweak, and finalize. This new workflow eliminates multiple manual and repetitive steps of content exchange, review, and approval to streamline multilingual content generation and get your content in front of customers faster. To learn more about LILT Create, check out our page [here](/kb/lilt-create).
LILT Create is offering a public preview period for new and existing customers wherein the product is available for any user to try free of charge. Please follow the steps below to set up Create in your Contentful connector as an existing or new user.
#### How to access LILT Create in Contentful as an existing LILT user
If you are an existing LILT user, click on "Log in with your LILT account". You'll get a pop-up in a new window, where you should enter your LILT account credentials.
*Note: If you receive a 404 error in the pop-up, this is likely because you're logged in at lilt.com. Please go to lilt.com and log out, then refresh Contentful and try logging in with LILT again.*
![]()
#### How to access LILT Create in Contentful as a new user
Follow steps 1 and 2 in the "Installing and Configuring the LILT Connector" section above. If you are a new LILT Contentful user, you should sign in with your Contentful account. Click on "Install" in the upper right corner of the page, and then click on "Sign in with Contentful".
![]()
You will then see a message that you have successfully signed into your Contentful account. Click on "Save" in the upper right-hand corner and continue.
![]()
Now that the LILT app is installed, you will see the LILT app in your right sidebar with the option to "Generate content using Contextual AI". Click on this, and it will open up the Create modal.
#### How to use LILT Create in Contentful
1. Once you have the LILT Create modal open, prompt LILT Create with what you are trying to generate. Identify the specific content you want to create and provide relevant context in a clear and concise manner. Here are a few examples to illustrate how to interact with LILT Create effectively:
* Create a blog post about healthy eating habits for children.
* Write an article about how AI is revolutionizing the e-commerce industry.
2. Select a target language to generate content in.*Note: Please make sure that your selected language is in the entry UI.*
3. Select a linguistic data source (if available) to provide context to the AI. See section below for more details on data sources.
4. Set your brand style guideto create a centralized style guide for all LILT Create users in your organization. Set your Create style guide preferences by selecting a tone and typing (or copy and paste) any relevant guidance that will help refine your content output. For many of you, this may be a direct copy/paste from your company's brand guidelines (Word document, PowerPoint, etc.). Be clear and concise with any additional guidelines, as this will help ensure accuracy.
5. Add any remaining additional guidelines, such as SEO keywords, an approximate word count for your content,or any structural sections you would like to see in your created content (these can be particularly useful for longer-form types of content, such as blog posts or articles).
6. Click “Create”. LILT will take \~30 seconds to generate net-new content based on these prompts. While generating your content, the right side of the screen will display a loading icon and your text will appear as it is being created. Once your content has been generated, you can use the markdown editor to tweak and finalize your content.
7. If you are not satisfied with the content that was created, edit any of the parameters on the left and click “Create” again. This will regenerate the content referencing the edits and updates you made to the fields on the left. If you recreate your content, it will overwrite the previously generated text (as well as any edits you made) and create new content from scratch.
8. Once your content is created, select the fields in your Contentful form where you would like to paste the content. We recommend selecting the section that corresponds to the body of your content. Click "Paste to field".
9. From here, the LILT Create modal will close, and your generated content will appear in the fields you previously selected. You can now continue with your content workflow (publishing, sending for localization, etc.).
#### Data Sources
When LILT provides translation services for an enterprise customer, that customer’s company account automatically creates and passively trains a customized, bespoke language model in each respective language serviced in that company’s account. If you haven’t previously worked with LILT for translation, your company account will not have these pre-existing customized language models, but you are welcome to add more to your LILT company instance. Examples of content you might want to upload could include translation memories, term bases, and glossaries.
LILT Create leverages the*target*language from an existing language model as a prompt. For example, if you select an existing Data Source that is En\_to\_Fr, it will leverage your existing model for English to French translations, but it will only leverage target segments (French) and not source segments (English).
Glossary terms from your data source will be sent as context if those keywords are found in the prompt. If you would like to specify which words to use in certain cases as you would with a glossary, we also suggest specifying these in the prompt or the style guide (e.g. Always use "crêpe" instead of "pancake").
Please [contact LILT Sales](https://getstarted.lilt.com/contact-sales-lp/) to learn more.
***
## FAQ
#### **Q: How do I resubmit content for translation?**
* A: Delete all content in the “LILT Status” field. (eg. Delete “Complete” or "Needs Localization"). Delete all content in the “Metadata” fields. Refresh the page, which will update the button to `Send for Localization` again.
#### **Q: Why do I need to click the Complete Localization button for each job?**
* A: The`Complete Localization` button functions to lock the translated content files as finalized and ready for publishing. This helps ensure that any future source changes are clearly delineated as content that may require updated translation steps. Clicking `Complete Localization` will update the labels the LILT platform checks so that when the time comes, it will be ready for these followup translation jobs on the same content after source updates.
#### **Q: Can LILT auto-confirm entries for me?**
* A: Yes! Talk to your LILT Account Manager to update your LILT + Contentful connector configuration to auto-confirm entries on completion. This will change your workflow to look like the following:
* Upon Delivery, Complete Localization is automatically configured
* When source updates are detected, you will see a warning message in the sidebar
* You can dismiss this warning message if needed
* When relevant, you can then resubmit content for translation\
[Auto-Complete Contentful.mp4](../__attachments/11305109/Auto-Complete%20Contentful.mp4?inst-v=8633d73d-9ae2-4b9a-ace9-a81b872bab86)
#### **Q: We don't like/use the LILT Statuses. Can we hide those to simplify the view?**
* A: Yes. This is possible through the configuration of the LILT connector. Reach out to your LILT Account Manager for assistance making this change.
#### **Q: I sometimes see inaccurate statuses after I duplicate tasks in Contentful. What should I do?**
* A: Contentful's duplication feature duplicates all metadata, including the LILT status. It is best practice to avoid duplicating tasks for any content that has already been submitted for translation. Instead, you can create a new entry to ensure that the workflow status restarts from the first stage.
#### **Q: I get a lot of pop-up warnings about content translation when I try to publish. Is that expected?**
* A: Contentful has a robust verification system geared toward avoiding unintended content getting published. With that, even non-critical updates to files can trigger popup warnings when publishing. This is expected behavior, and these popups can be dismissed in cases where this is not relevant to any source/translation changes.
#### **Q: Some content says it has changed, but I know the source has remained the same. What's wrong?**
* A: Contentful is extremely sensitive to source updates, which can cause it to show content as "modified" even when only metadata or non-source changes have been made.
#### **Q: What content models should I apply the LILT sidebar to?**
* A: Apply the LILT sidebar to any content model you wish to send translation jobs for. These can be set up one at a time using the instructions above.
#### **Q: The LILT app and other buttons on the sidebar are similar and confuse some users. Can we change it?**
* A: The Contentful sidebar is customizable. In the sidebar setup page for any given content type, drag and drop the active sidebar apps to adjust the ordering.
#### **Q: How does my Contentful Link-Depth work with the LILT connector?**
* A: Verified Translation will honor your link-depth strategy. (Remember that you need to share your link-depth information with your LILT account team at the time of setup!)
* A: Instant Translate does NOT take into account link-depth, and only directly selected entries will be sent for instant translation.
#### **Q: Can I pull a list of Entry IDs from a release?**
* A: Add content to a release and go to your release in the Launch app. Hit "F12" on your keyboard to pull up Developer Tools in your browser and navigate to the `Console` tab.
1. Click the blue carrot next to`Add Content`.
![]()
2. Enter the following script in the developer tools Console box:
CODE
```javascript theme={null}
x = document.querySelectorAll('td[data-test-id="checkbox-cell"] div label')
x.forEach(c => console.log(c.getAttribute('data-test-id').replace('checkbox-', '')))
```
Copy
3. Once you click "Enter", Entry IDs will populate.
![]()
4. Copy and paste the list of Entry IDs, and reformat as needed.
# Contentstack
Source: https://support.lilt.com/kb/contentstack
The LILT Connector for Contentstack can help you expand your store accessibility to international markets by bridging language barriers with LILT’s translation services.
* Translate all of your site’s content, including product descriptions, checkout pages, and customer service messages.
* Choose from 60+ languages to cater to your target audience’s needs.
* Preview translations for accuracy and brand suitability before publishing.
## Getting started
1. Sign in to your Contentstack account.
2. Go to the Contentstack [marketplace](https://www.contentstack.com/marketplace) and search for "[LILT Connector.](https://www.contentstack.com/marketplace/lilt)"
3. Install the app and follow the on-screen instructions to set it up.
4. When the app is installed, you’ll need to provide a LILT Token to complete the connection.
![]()
5. Contact us through [this link](https://resources.lilt.com/contact-us) and tell us “I need a LILT token for the Contentstack app”.
6. Our team will reach out to help with everything needed to start translating your Contentstack site, including brand-alignment documentation and customized configuration for your LILT Connector.
## How to send content for translation
1. Select the pages or content you want to translate.
2. Choose between *Instant translation* (machine translation with Contextual AI) or *Verified translation* (which includes a quality guarantee).
![]()
3. Choose the target language(s) for your website translation.
4. Click `Translate`.
It's that simple! When your translations are complete, you can import, preview and publish translated content, all within the Contentstack app.
# Craft
Source: https://support.lilt.com/kb/craft
LILT + Craft connector enables companies to automatically push and pull web content between Craft and LILT. This saves you time by providing seamless localization while letting you continue to work in the systems you know.
This Knowledge Base article will cover all of the necessary steps for install, configuration and use, as well as an FAQ with additional info and tips!
## Installing and Configuring the LILT Connector
1. To install the LILT Connector, start by going to the Plugin Store in your instance of Craft. In the list of available apps, you can search for / or look under Localization in the side panel to find LILT.
![]()
2. When you click into LILT, you can find more information about this Connector. You can review LILT’s website and documentation, and send any questions to our support team. From here, scroll down and click “Install”
### **Enabling the LILT Plugin**
3. Log in to your Craft CMS control panel as an administrator.
4. Go to the "Settings" section and click on "Plugins".
![]()
5. Find the LILT plugin in the list of available plugins and click on the "Install" button.
![]()
**Configuring Plugin Settings**
6. In the LILT plugin settings, you will find two important settings: API Key and API URL.
1. Contact the LILT sales team to obtain your API Key and API URL.
2. Enter the provided API Key and API URL in the respective fields within the plugin settings.
3. Click “Update configuration” button
![]()
***
## Sending a Request for Translation
By adding LILT to your content model sidebar, your team can easily view localization statuses and send requests for translation at any time using the steps below.
### Project creation
1. In Craft, click on the LILT plugin in the sidebar
![]()
2. Create a New Job
1. Click on “New Job” in the upper right hand corner
2. Fill in the corresponding fields
1. Title
2. Entry
1. Select from all existing entries in your Craft instance
2. Select the relevant draft (i.e. current)
3. Source Site
4. Target Site
3. **Instant translation:** To immediately localize the selected content using LILT's Contextual AI, ensure that `Instant translation` is selected
4. **Verified translation:** To send the selected content to LILT's in-house translators for localization, ensure that `Verified translation` is selected
5. Click Create Job in the upper right hand corner
3. Manage Jobs
1. See Statuses of all jobs under the All Jobs tab
1. Statuses include
1. Draft
2. New
3. In Progress
4. Ready for Review
5. Ready for Publish
6. Complete
7. Failed
2. Or Select the status under the options in the left hand side
![]()
4. In the same popup, you will find be able to select your Target Language either by search or checking the respective boxes. Make your language selections and clickSubmit.
### Project Statuses
1. Once submitted for localization, the status will change to “Ready to start.” This status is how our Connector identifies entries that are ready to be picked up for localization.
2. LILT periodically checks Craft for content that has been sent for localization with LILT. When this content is found, LILT Projects are automatically created that contain the content to be localized. Once the content is pulled into LILT, the content sidebar in Craft will displayIn Progress.
3. LILT periodically checks for Projects marked as Done. When this is detected, the translated content is automatically sent back to Craft.Your language pair statuses will update in real time as they are delivered.
4. To view your translations, ensure you have multiple locales selected on your sidebar. Once all languages are completed to satisfactory quality, click to finalize the content and prepare it for publishing.
**Preview**
1. Click Preview in the Upper Right Hand corner to see a Preview of the content
![]()
2. Here, you’ll be able to see a draft version of what the target site could look like
![]()
***
## FAQ
**How will we know when there are connector updates?**
We will update the marketing material and corresponding instructions in the connector site and this KB. We will send a message to customers who currently use the plugin to update them. Finally, for more meaningful updates, we will schedule training with existing users.
# Create Backup
Source: https://support.lilt.com/kb/create-backup
## Introduction and Terminology
This guide describes the back-up, reset and restoration of an installed LILT system. The terminology *master* and *node* refer to Kubernetes nodes created in the original installation.
| | |
| ------ | ------------------------------------------- |
| master | All apps are deployed in kubernetes cluster |
| node | Content is saved inside \$shared\_storage |
## Creating Back-up
Creating a database backup saves database information, documents, and assets for later restoration.
#### master
Database
```ruby theme={null}
$ mysqldump --host --user root -p lilt_dev > backup.sql
```
\ can be found by running:
```csharp theme={null}
$ kubectl get configmap -n lilt lilt-configmap -o yaml | grep -i dbhost
```
#### **node**
Documents and Assets
Copy and save contents of \$shared\_storage/PVC(s) (e.g. /liltdata/pvc\_\*), to the desired location.
#### **Reset**
Resets the installation to its initial state. This is an *optional* procedure for the following use case:
Team A in the organization is using LILT, and has accumulated data. Then, Team B asks for a “fresh install” of LILT, but instead of re-provisioning a second set of hardware and re-installing from scratch, you can backup Team A’s data, reset LILT to a pristine state, and allow Team B to use LILT. When Team B is finished with the evaluation, you can backup Team B’s data, reset LILT to a pristine state, and restore Team A’s data.
**Do not run these steps without performing a back-up. It will irrevocably delete all data in the system.**
Follow the below steps in order:
#### master
Remove all apps
Run the following:
`$ cd $install_dir`
`$ ./uninstall-lilt.sh`
#### **node**
Remove \$shared\_storage
`$ sudo rm -rf /$shared_storage/pvc*`
#### **master**
Install apps with no data
Run the following:
`$ cd $install_dir`
`$ ./install-lilt.sh`
#### **Verification**
If you see **Error: UPGRADE FAILED: timed out waiting for the condition**, please continue as this can happen due to time taken by the pods to startup, apps deployment happens as expected.
* Please ensure all the pods are healthy (in “Running” status). This can take some time as all pods would connect to local docker-registry to download the new images in the node.
* `$ kubectl get pods -n lilt`
* Browse the site over ingress host URL by pointing it to one of the node IP addresses.
# Create ImagePullSecrets
Source: https://support.lilt.com/kb/create-imagepullsecrets
ImagePullSecrets are authorization tokens, or secrets, that store Docker credentials used to access a private registry. The following describe how to create and implement `imagePullSecrets` for pulling private container images with service account auth (service account must have required permissions to pull images from registry).
Although the below example uses Google Artifact Registry, this can be applied to any private container registry.
### Service Account
AWS, GCP, Azure, etc… utilize service accounts for controlling user access. Within the service account, there will be an option to create an access key. Create the `key.json` file and download to a server or local machine. Example file from GCP:
```bash theme={null}
{
"type": "service_account",
"project_id": "",
"private_key_id": "fhrk45h89egh945h89hehg948",
"private_key": "-----BEGIN PRIVATE KEY-----\hfdiegic34587697dfmty796^&*^TYIG*&R*&^UTOIY9hreytn9vgmefhiv9eorityrshf8yiftgreh7tiuygvhiuxdkflyg598yyu58rytgf8eryihgknruotrty8erityhgjtoirkjghmrkfdmgkstj3oit4ru89y*^%&^*%OIUTFBDV^&UY$RTYI\n-----END PRIVATE KEY-----\n",
"client_email": "@.iam.gserviceaccount.com",
"client_id": "348579836789347805460459",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://oauth2.googleapis.com/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/your-servie-account.iam.gserviceaccount.com",
"universe_domain": "googleapis.com"
}
```
### Create Secret
Utilize `kubectl` to create the secret. This uses the `key.json` file created in the previous step from the service account. This example creates a secret in the lilt namespace using the service account email:
NOTE: Google Artifact Registry is REPOSITORY specific, not just region. Secrets are also namespace specific, must create a new secret for each additional namespace.
```bash theme={null}
kubectl -n lilt create secret docker-registry \
--docker-server="https:us-docker.pkg.dev/" \
--docker-username=_json_key \
--docker-password="$(cat key.json)" \
--docker-email="@.iam.gserviceaccount.com"
```
Optional: If need to use the same secret in other namespaces, copy with the following command:
```bash theme={null}
kubectl get secret --namespace=lilt -oyaml | grep -v '^\s*namespace:\s' | kubectl apply --namespace= -f -
```
Verify secrets:
```bash theme={null}
kubectl get secrets -A
```
### Helm Chart, Manifest
Utilize the `imagePullSecret` in a helm chart `values.yaml` or manifest file:
```bash theme={null}
global:
imagePullSecrets:
-
```
# Create User/Organization
Source: https://support.lilt.com/kb/create-user-organization
## Overview
This document walks the installer through the process of user and organization management. Please refer to the [knowledge base](/kb/organization-management) on getting more information about Organization & User Management.
## Required Tools
You will need to use SSH to connect to the systems.
* On the Mac or Linux, you can open a terminal window and use ssh.
* On Windows, you can use the PuTTY ssh client.
You will also need a web browser to browse the website post installation and verification.
### Installer Privileges
Users need to have access to the kubernetes cluster that hosts the application.
## Create new organization
To create a new organization we start with creating an admin for the organization. Creating an admin user will automatically create the organization.
#### Connect to the front pods
`$ kubectl exec -it -c front -- /bin/bash`
Steps to fetch \:
* connect to the kubernetes cluster
* fetch \ by running:
* `kubectl get pods -n lilt | grep -i front`
#### Create organization admin
\*\*NOTE: For LILT November 2023 release onwards, please use **`npm run dist-admin-cli`** instead of \*\*`admin-cli`
This step creates the admin account, along with the organization. Once the user is created, the organization will be automatically generated and will be viewable in the UI.
`$ npm run dist-admin-cli -- create-user --email --password `
#### Promote admin to the EnhancedAdmin
Organizations require at least one member to hold the EnhancedAdmin role in order for the Organization to be active. The following step promotes the newly created admin user to the EnhancedAdmin role.
`$ npm run dist-admin-cli -- mass-enable-feature --users= --feature=EnhancedAdmin`
## Add user to an Organization
Once your organization is created with CLI, admin and manager team members can add users from the LILT UI. To add users to your team, Login to UI as an admin and navigate to the `Organization` screen. You can add users by clicking the `Users` button.
![]()
# Create with Assist
Source: https://support.lilt.com/kb/create-with-assist
LILT Assist allows users to quickly create on-brand, locally relevant content in any language. By pairing your company context and linguistic assets with specifically trained AI models, Assist generates enterprise-grade content that you can review, tweak, and finalize in a single workflow.
### Key Features
* **Generative Content Engine:** Instantly draft high-quality, enterprise-grade content from scratch using your company’s unique business context and trained AI models.
* **Iterative Refinement:** Seamlessly edit and refine the content the agent has just created—adjusting tone, length, or focus until the draft is exactly where you need it.
* **Multilingual Continuity:** Move from a finalized source draft directly into localization workflows without manual handoffs or file exports.
* **Consistent Global Voice:** Automatically incorporate company-specific TMs and glossaries, ensuring your brand voice is consistent across all regional and local content.
* **Local Tone and Relevance:** Create global content that resonates with local audiences by integrating local context with your company’s core message.
### How to Use
1. To get started, use a prompt (e.g., *"Write a blog post"*) or click the Create Content card at the bottom of the LILT Assist screen.
2. Provide Assist with specific details:
* **Content Type:** Specify if you need product descriptions, marketing copy, technical documentation, or website content.
* **Topic & Goals:** Describe the core subject and what you want the content to achieve.
* **Language(s):** List the target language for the content.
* **Source material:** Click `+` to provide any existing reference files or style guides.
* **Linguistic Assets:** Mention specific termbases, translation memories, or custom models the agent should prioritize.
* **Content Details:** Define the desired length, scope, target audience, and tone.
3. Review the Agent’s proposed plan and confirm to begin.
4. Assist will generate a draft based on your prompts and company's trained models. Review the draft text directly in the chat interface.
5. Ask Assist for specific changes or tweaks (e.g., “Make the tone more professional” or “Add a call to action”).
6. Once the source content is approved, the content can be easily copied or downloaded for sharing and publication.
### Best Practices for Content Prompts
The more specific you are regarding your audience and intent, the better the agent can assist you.
Avoid unnecessary language and filler words when writing prompts. If you aren’t sure which workflow to use, simply ask Assist to recommend one. Use these four details to build a strong prompt:
* **Action:** What do you want generated? (*Create, draft, summarize*)
* **Object:** What is the content type? (*Blog post, email, training manual*)
* **Parameters:** Key details (*Topic, target audience, length, languages*)
* **Context:** What is the desired tone? (*Professional, instructional, persuasive*)
### Quick-Start Prompts
**New Content Generation**
* *Using our English-Austrian model, draft a professional 800-word blog post about our new AI features for business users in German. Tone should be educational.*
* *Generate a friendly 150-word announcement email in Italian for our Milan office regarding the holiday schedule.*
* *Write a 200-word product description for our new enterprise platform targeting CTOs.*
* *Create a technical training module for software engineers explaining our security protocols.*
**Revising Generated Content**
* *Rewrite the second paragraph of this draft to be more concise and focus on cost-saving benefits.*
* *Update the tone of this email to be more urgent and change the call to action to 'Register Now'.*
### Sample Agent Interactions
```text theme={null}
User: "I need a blog post about our new product in English, German, and Japanese"
Assist: "I'd be happy to help create a multilingual blog post. Let me gather some details:
- What's the main topic or angle of the blog post?
- Who is your target audience?
- How long should the post be?
- Do you have any specific keywords or topics to include?"
Users: "It's about our new AI translation feature, targeting business users, around 800 words. Use the attached files as a reference"
Assist: "I'll create a professional blog post about your AI translation feature. Let me generate this in English first, then German and Japanese..."
```
# Creating Jobs
Source: https://support.lilt.com/kb/creating-jobs
Work in LILT is accomplished through Jobs:
* Each Job is created with one source language (e.g. English).
* Each Job holds a collection of one or more Projects, with each Project designated by a specific language pair (e.g. English to French, English to German, English to Spanish). Projects can only be created with the same source language as the Job they are in.
* Each Project holds one or more documents to be translated.
LILT makes Job and Project creation simple by automatically creating separate Projects for each desired target language and populating each Project with the documents to be translated.
## Creating a Job
Create a new Job by navigating to the `Jobs` tab and clicking the `New job` button in the upper-right. This opens up the Job creation popup form.
![]()
### Enter Job details and upload files
The first screen of the Job creation popup form is where you fill out the Job information, add source files, and add reference materials.
* **Job name:** Give a name to your Job.
* **Source language:** Select the source language of the content being translated (this should match the language of the documents you upload).
* **Deadline (optional):** Job deadlines can be different than Project due dates
* **Documents:** Upload documents you want to localize. At least one document must be uploaded to create a Job. Drag and drop files into the box, or click the `Import` button to browse for files on your computer. You can also drag and drop a folder of documents into the box to upload all the files in the folder at once. See the [Supported File Formats](/kb/supported-file-formats) article for a full list of file formats that LILT supports.
* **Reference materials (optional):** Upload any relevant reference materials to aid linguists during localizing.
\*\*Note: \*\*Documents and reference materials will be added to all Projects under this Job. Additional documents and reference materials can be manually added later, but must be added to each Project individually.
\*\*Once finished, click \*\*`Next: Select target languages` to advance to the next screen.
![]()
### Select target languages and memories
The second screen of the Job creation popup form is where you select target languages and also where you select a Data Source to use for each language pair. Each selected target language will generate a Project within the Job. You can add as many languages as you need, but a target language cannot be selected twice.
* **Language:** Select the target language you want to translate content into.
* **Memory:** Select from an existing Data Source or create a new one. *Note: Once the Job is finalized and its Projects are created, the Data Source associated with each Project cannot be changed.*
* Create a new Data Source by typing out the desired name and clicking the `Create` button.
* If you don't have any Data Sources for a language pair, click the `Create your first data source` button to quickly create a [Default Data Source](/kb/managing-your-lilt-memories#ManagingYourLiltMemories-DefaultLiltMemories).
* **Due date (optional):** Set a due date for the Project. This can be added or changed later in the [Project Settings](/kb/project-settings). *Project due dates can be different than Job deadlines.*
![]()
*Default Project settings can be modified in the [Organization Settings](/kb/organization-settings) area.*
Note: you can add source documents or references to individual Projects within a Job once it’s been created, you can’t add additional Projects to an existing Job.
Once finished, click the `Create job` button and LILT will:
* Create the Job and add it at the top of your Jobs list.
* Create a Project (within the Job) for each target language and set each Project’s state as `Ready to start`.
* Populate each Project with the documents and reference materials uploaded on the first screen.
# Crowdin
Source: https://support.lilt.com/kb/crowdin
The LILT + Crowdin connector enables companies to automatically push and pull web content between Crowdin and LILT, saving you time by providing seamless localization while letting you continue to work in the systems and workflow you already know.
The Crowdin connector supports:
* **Job submission via Crowdin**: Create a new Job in LILT by creating a [*task*](https://support.crowdin.com/tasks/?q=task) in Crowdin and assigning it to a LILT Crowdin user.
* **Job progress monitoring**: Within Crowdin, you can check whether a task has been retrieved by the LILT connector and whether the task has been delivered back into Crowdin.
* **Job delivery to Crowdin**: Once content is localized in LILT, LILT delivers the localized content back to Crowdin for approval.
## **Configuration**
At a high level, the installation steps are as follows:
1. Invite LILT as a Contributor to your Crowdin workspace and projects
2. LILT accepts the invite and procures a Crowdin API token.
To set up your LILT + Crowdin connector:
1. You must first invite LILT as a[](https://docs.lokalise.com/en/articles/2983736-onboarding-guide-for-project-managers)[*Translator*](https://support.crowdin.com/inviting-participants/) to your Crowdin workspace. This can be accomplished by navigating to User Management > INVITE USERS and entering [connector-accounts@lilt.com](mailto:connector-accounts@lilt.com) as the email address.
2. Invite [connector-accounts@lilt.com](mailto:connector-accounts@lilt.com) to your projects by opening a project, navigating to Members > INVITE PEOPLE.
3. LILT will receive an invite email with instructions for how to create an account within your Crowdin team. Once in Crowdin, the API token can be retrieved by navigating to Account settings > Access tokens. A new token can be created by selecting the “NEW TOKEN” button.
4. LILT will configure the connector.
## **Workflow**
Once the connector is configured, content is moved between LILT and Crowdin as outlined below.
### **Job creation**
Customers can send new or existing content to LILT for localization by assigning the LILT contributor to one or many tasks. The connector periodically checks for tasks that have been assigned to the LILT contributor. When tasks are found, the content is automatically pulled into LILT for localization.
### **Job completion**
Once the content has been localized in LILT, the target content is automatically delivered back to Crowdin.
# Custom QA
Source: https://support.lilt.com/kb/custom-qa
Customers are now able to upload and use custom QA configurations that are supported at the organization level. These QA checks will be applicable when running Quality Assurance Tools in the CAT editor.
The ability to upload QA config files is restricted to admin users.
Custom QA configurations support .qccfg file types, which can be created with [Okapi Checkmate](https://okapiframework.org/wiki/index.php/CheckMate). To learn more about how to do this, please reference [CheckMate - Quality Check Configuration, Okapi Framework](https://okapiframework.org/wiki/index.php/CheckMate_-_Quality_Check_Configuration).
## Step 1: Navigate to “Organization settings”
![]()
## Step 2: Select “Custom QA checks”
![]()
## Step 3: Select “+ QA config file”
## Step 4: Select language pairs and upload file
* Files must be .qccfg file type, and LILT will prevent the upload of any other file type.
* We will only allow one config file per language pair. If you need to update a config file, you will need to first delete the existing file and reupload a new one.
![]()
To delete a config file, click on the dropdown arrow next to the download button and select “Delete”.
![]()
# Custom Role For Instant Translate
Source: https://support.lilt.com/kb/custom-role-for-instant-translate
Users with the [Default Roles](/kb/default-roles) of Admin or Manager are able to use their organization's Models in Instant Translate. However, users with the default roles of Translator or Reviewer are not able to use the organization's custom Models in Instant Translate. Translators and Reviewers are only able to use LILT's **Default** Models per language pair, but if you would like them to be able to use all of the Models in the organization, you will need to create a custom role for your translators and reviewers.
Follow the instructions in the [Custom Roles](/kb/custom-roles) article to set up a custom role. For a role to be able to access all Models in Instant Translate, make sure to enable the permission to `View` `Sources`, as shown in the screenshot below. This will control both Data Source and Model visibility for users assigned to the role.
![]()
Once you have created the custom role, follow the instructions in the [Reassigning Roles](/kb/reassigning-user-roles) article to assign the new custom role to the desired users. These users will now be able to see all of your organization's Models in the Instant Translate `Model` selection dropdown:
![]()
# Custom Roles
Source: https://support.lilt.com/kb/custom-roles
If you need to expand beyond the [Default Roles](/kb/default-roles) to better fit your organization, you can easily define your own custom roles within LILT. By default, adding and editing custom roles is only available to the administrator role.
To get started, navigate to the `Manage > Users`.
![Image]( "Image")
Select the `Roles` tab, which will display all the default roles and custom roles of the organization.
To add a new role, clicking the `New role` button in the upper-left. This opens a pop-up where you can set the name for the custom role, add a description, and toggle on each permission you want the role to have.
![Image]( "Image")
If a user has been assigned the "Linguist" role type, they will not have the ability to create verified or instant translation jobs.
The permissions available to be toggled shown below for reference. To compare against what permissions the default roles have, see the [Default Roles](/kb/default-roles) article.
| **Permission** | **View** | **Create / Edit** | **Upload** | **Download** |
| --------------------- | -------- | ----------------- | ---------- | ------------ |
| Jobs | ☐ | ☐ | | |
| Projects | ☐ | ☐ | | |
| Documents | | ☐ | | |
| Assignment | | ☐ | | |
| Files | | | ☐ | ☐ |
| Memories | ☐ | ☐ | | |
| Terminology data | ☐ | ☐ | | |
| Reports | ☐ | | | |
| Team members | | ☐ | | |
| Integrations | | ☐ | | |
| Roles | | ☐ | | |
| API key | ☐ | ☐ | | |
| Organization settings | ☐ | ☐ | | |
| User visibility | ☐ | | | |
**User visibility** is a security feature that can anonymize translator information of TM entries displayed in [LILT Translate](/kb/introduction-to-lilt-translate). This helps keep sensitive information away from roles that don’t need it to perform their duties.
* If a role has the `User visibility` option **turned on**, users with that role **can** see user data from within the org (e.g. a Translator role added to their org), but no LILT expert user data. This includes translator information for TM entries, and assignment for any non-LILT expert.
* If a role has the `User visibility` option **turned off**, users with that role **cannot** see any user information in TM entries or for assignment. The translator information will instead be filled with asterisks. The default roles “Translator” and “Reviewer” have this setting.
* If a user is within the org AND in the LILT expert pool, their information will still be redacted.
Only the default Admin role has access to LILT expert user information.
| | |
| ------------------------------ | ----------------------------- |
| **User visibility turned off** | **User visibility turned on** |
| ![]()
| ![]()
|
**Assign Reviewer** is a permission that will allow the role to assign Secondary Reviewers (customers) during job submission.
![Image]( "Image")
# Custom Segmentation Using SRX Files
Source: https://support.lilt.com/kb/custom-segmentation-using-srx-files
Custom Segmentation using SRX files offers segmentation flexibility, allowing organizations to leverage their own segmentation rules on a per-job or org-wide basis, directly addressing the unique content structures and translation memory (TM) alignment needs of larger, localization-savvy clients. Key features include SRX file support in file loaders, enhanced control over segmentation, and a seamless integration with translation workflows.
## How to set SRX files
1. Click “Manage” on the left rail
![]()
2. Click on “File Loaders”
![]()
3. Click on “+ New Loader” in the top right corner
![]()
4\. Select “Segmentation Only”
![]()
5\. In the Segmentation dropdown on the right section select “Upload Custom SRX File”
![]()
6. Click on “Upload custom SRX File” - click on that and in the new selection window - pick out the SRX file that you want to upload
![]()
![]()
7. After uploading the file, click Next in the bottom right corner
![]()
8. Name the loader. Optionally, you can:
1. Add a short description of the loader.
2. Add it to any domains that you want to apply this loader to. If you select specific domains, then the SRX file will only apply to those. Otherwise, it will apply to all users of the organization.
![]()
9. Click “Create” at the bottom of the screen and you SRX file loader will be ready to use.
# Secondary Review
Source: https://support.lilt.com/kb/customer-review
Secondary Review is established when a customer has internal team members that are bilingual or native speakers of the target language and whose roles include reviewing translated content. These customers will review translations in the LILT platform so LILT can capture their feedback in the translation memory and provide a revision report to linguists if necessary. This step is added to the projects in the LILT org using the Translate > Review > Secondary Review workflow.
This article outlines the tools and workflow of a Secondary Reviewer using LILT.
## Accessing the Project
Before a Secondary Reviewer can access and begin working on a document, a project manager needs to assign the Secondary Reviewer to the document. Assignment emails for secondary reviewers will be sent once all preceding stages are complete. The Secondary Reviewer can then [accept the document assignment](/kb/accepting-document-assignments) and begin reviewing.
When you have been assigned to review a project, you will receive an email notification from LILT, which will direct you to log into the LILT platform using your login credentials. The project will appear in your LILT dashboard as an ‘Active job.’
**Deadline for delivery**
Check the deadline for delivery; if you do not feel confident you will meet the delivery deadline, please notify LILT or the original project requestor, so that other arrangements can be made.
**Accepting the assignment**
Once you have clicked into the project, you will see all documents associated with the project. To accept the assignment as Secondary Reviewer for the project, first click into the project, then click ‘Accept Secondary Review.’
![]()
## Reviewing Segments
When a Secondary Reviewer opens a document, it will load LILT Translate in Secondary Review mode. The Secondary Review mode interface is the same editor used for [Translation](/kb/translating-documents), but with a few slight differences, as described in the [Introduction to LILT Translate](/kb/introduction-to-lilt-translate) article.
All segments will appear as confirmed by the original LILT translator. This is visible by the green line and check mark that will appear to the right of the segment.
![]()
The various tools and features (as described in the [Introduction to LILT Translate](/kb/introduction-to-lilt-translate) article) all come together to create an efficient workflow. The most important tools for Secondary Reviewers to know are the [segment editor](/kb/introduction-to-lilt-translate), [Quality Assurance Checks](/kb/quality-assurance-tools), and [hotkeys.](/kb/hotkeys)
## Accepting segments
Review each segment. If no errors are found, you can accept the segment. Accept the segment by clicking the double checkmark in the bottom right corner, or by using the shortcut (`Ctrl`+`Enter`). The segment will then be shaded green, indicating it has been successfully reviewed.
![]()
Once accepted, the segment can still be unaccepted and modified in Review or Secondary Review mode, but can no longer be modified in [Translate mode](/kb/translating-documents). *Note: Segments do not have to be confirmed in Translate mode for Secondary Reviewers to accept the segment in Secondary Review mode.*
## Editing or correcting a segment
If an error is found during Secondary Review, make the necessary changes and use the error typology to provide feedback.
To make an edit or correction to any part of the translation, simply click on the segment and make any changes necessary in the text. Once you are done, click the double check mark on the right side and this will accept the segment.
### Using error typology to provide feedback
When you edit or correct a segment, you may be prompted by a pop-up to log the error information if your organization has the mandatory error logging setting turned on.
Within the pop-up, select the appropriate Category, Sub-category and Severity level from the dropdown menus, and provide a comment or explanation of the error and/or change made. Then, click “Add”. For a detailed explanation of the error severities, categories, and sub-categories, please refer to the Section “[Error Typology](/kb/segment-comments#Error-Typology)”.
![]()
![]()
![]()
![]()
Each edit or correction should be tied to specific error information and a supporting comment. These corrections are later shared with LILT’s team to improve future performance.
When you have updated the segment with error annotations, the flag icon will be updated and the error will be recorded. If the segment contains more than one error, please log the second error in the error annotation. The error count next to the flag will change each time a new error is logged. Error annotations can be edited or deleted by clicking on the three dots and selecting the corresponding option.
Once you are done, click the double check mark on the right side and this will accept the segment.
![]()
## Filtering and batch actions
Secondary Reviewers can filter for unreviewed segments by selecting the “View” tab, then “Segments”, then “Unreviewed”. This can help keep track of progress should the Secondary Reviewer need to come back at another time to complete the stage.
![]()
Secondary Reviewers have the option to accept/unaccept multiple segments within a document at once from the `Edit` tab:
* `Accept all confirmed` (shortcut: `Ctrl`+`Shift`+`Enter`): Accept all segments that have been confirmed in Review mode.
* `Unaccept all reviewed` (shortcut: `Ctrl`+`Shift`+`A`): Unaccept all segments that have been accepted in Review mode.
## Marking the document as done
When all segments in a document have been accepted, a `Mark as done` popup will appear, allowing the reviewer to mark that the document has been completed in Secondary Review mode. This action will automatically notify LILT that the Secondary Review of the document is complete.
![]()
If a manager has enabled mandatory [Quality Assurance Tools](/kb/mandatory-batch-qa-check), the Secondary Reviewer will need to run Quality Assurance Tools checks (which runs a QA check on all the document's segments) before the document can be marked as done.
![]()
## Secondary Reviewer assignments through domains
Secondary Reviewers belonging to a domain can take advantage of a new feature to support assignments by domain. With this feature, Secondary Reviewers are assigned to domains, and identify which languages they support in their LILT profile. LILT’s production management team can then assign a domain as a Secondary Reviewer during the assignment stage, which would share the opportunity with all those qualified. Secondary Reviewers can then accept projects based on their availability. To take advantage of this feature, please follow these steps:
#### Identify which languages you support on your Secondary Review profile.
1. Navigate to the profile icon in the bottom left corner and select Profile.
![]()
2. Add supported Language Pairs. ***Please note: These need to be the same languages as the projects that come into LILT.***
![]()
#### Assign Secondary Reviewers to domains
Follow the steps in [/kb/lilt-domains](/kb/lilt-domains) to assign Secondary Reviewers to domains.
#### Assign a domain as the Secondary Reviewer
When a domain is set as the Secondary Reviewer, the assignment will be sent to all users in the Secondary Reviewer role in that domain who have the language pair on their profile. ***Please note: If there is a mismatch between the language pair on the Secondary Reviewer profile with the project language pair, the Secondary Reviewer will not receive the assignment offer. For example, if the language pair on the Secondary Reviewer profile is enUS > esES, but the project is en > es, the Secondary Reviewer will not receive the offer.***
![]()
# Data Cleanup & Building Data Sources
Source: https://support.lilt.com/kb/data-cleanup-building-memories
The key component to machine translation within the LILT platform is processing parallel text of one language to an exact translation in another language, known as parallel corpora. LILT uses both open and paid data sources to get parallel text data used for training the models. Open sources are freely available and vetted sources of parallel text data, usually made available with the license CC-BY or CC-BY-SA. Some of the sources are Opus, Paracrawl, and CCMatrix. While some data sources are of high quality, some require manual cleaning. This guide details processes for manual cleaning of data and the steps for uploading new Data Sources.
## Introduction to Data Cleansing
LILT uses a number of methods acquiring and processing parallel corpora with machine translation (MT). Some of the methods for cleansing include sentence alignment, filtering of noisy parallel corpora data, and monolingual pre-training. These high-level methods are broken down into steps outlined in the following section. Once data is cleaned, Data Sources can be uploaded for training.
## Data Cleanup and Quality Assurance Steps
The data cleanup process contains multiple steps that can be performed for data being imported to LILT Translate.
#### Clean and validate
We perform a basic syntax-based cleaning using the below substeps:
1. Remove any blank sentences
2. Remove sentences containing only punctuation
3. Validate that source and target language files contain a matching number of segments (otherwise, discard the source).
#### Normalize Segments
To ensure consistency of all segments, the following steps can be performed:
1. Normalize Unicode: Text like unicode or HTML text can be converted to human readable text. Eg *Broken text\… it\’s flubberific!* is converted to *Broken text... it's flubberific!*
1. A common method for normalizing unicode or HTML text is to use Python string and HTML parsing libraries.
2. Normalize non-breaking spaces: For languages like French, where there are strict rules about positions of non-breaking spaces, this step adds the spaces where necessary, if they are not already present.
#### Filter
First, remove potentially problematic segments from a corpus at segment- or segment-pair-level. This is known as individual filtering.
1. Script: It’s a fair assumption that if a *ja* (Japanese) segment contains a *ta* (Tamil) token/phrase, it may not be usable during training. We maintain rules for scripts that are not effective when embedded in another script, and remove those segments.
2. Language code: We use the python cld3 package to identify a segment’s language; if it doesn’t match the corpus language, it is discarded.
3. Exclude patterns: We exclude segments matching regexes that identify problematic patterns, for example, “http\://” for URLs
4. Segment length: We exclude any segment longer than 300 words (configurable per language).
5. Number mismatches: We exclude any segment pair which uses the same numeral system, but contains different numbers in the source and target segments.
6. Length Ratio: We exclude any segments where the source or the target segments are unusually long or short for a segment pair, after comparing with a threshold computed on the entire corpus.
7. Edit Distance: We exclude any segments where the source and target segments are identical or similar, since this may indicate mistranslation. We check the edit distance between the source and target segments against a minimum of 0.2.
#### Augment Data
When presented with unfamiliar or underrepresented data, machine translation models can fail by producing “hallucinations” -- translated text that is divorced from the original source text. To ameliorate this problem, we artificially generate (augment) examples of parallel sentences. Training with the augmented examples improves the model’s robustness and resilience towards these data, allowing us to effectively translate a wide variety of customer domains. We augment existing segment pairs in the following ways:
1. Multi-segment: We concatenate up to 5 consecutive segments to form a single long segment.
2. Capitalization: We capitalize the selected segments based on *UPPERCASE* and *Title Case* capitalization schemes.
3. Non-Translatables: We introduce non-translatables used by our customers by detecting common tokens/phrases in source and target segments and wrapping them with \$\{ and } characters.
#### Byte-pair Encode (BPE)
The vocabulary for a large corpus can be huge, with many words seen rarely. We perform byte- pair encoding (BPE) on the words to break them down into word pieces (e.g., *eating* might be separated into *eat* and *ing*). This allows us to fix the size of the vocabulary, and in extension, the MT model and hence the resources required to train the model.
BPE further allows us to translate segments with tokens which haven’t appeared in the training corpora, common in morphologically rich languages such as romance and slavic languages, since we can split tokens into familiar word pieces.
## Uploading New Data Sources for Training
This section walks through uploading memory files to new or existing Data Sources. Uploading memory files to a Data Source allows LILT to better find translation matches and provide translation suggestions within [LILT Translate](/kb/introduction-to-lilt-translate).
All the LILT Data Sources you are the owner of are located under the `Data Sources` button on the `Data` navigation.
![]()
Files can only be uploaded to existing Data Sources. If you want to upload a memory file to an empty Data Source, you'll need to first create a new Data Source by clicking the `Create new data source` button in the upper-right. See [Managing Data Sources](/kb/managing-your-lilt-memories) for more details.
![]()
Once you have located the Data Source you want to upload your memory files to, click the Data Source card or its `Edit data source` button to open up the Data Source view.
![]()
On the Data Source view, navigate to the `Manage resources` page. This page displays all documents that have been uploaded to the Data Source.
![]()
To add memory files, click the `Upload memory files` button in the upper-right and select the type of memory files you want to upload. Selecting one of the dropdown options will bring up a window for you to locate and select the files you want to upload. After the selected files are loaded into LILT, they will be available to view on the `Manage resources` page.
![]()
**TM supported file types:** JSON, SDLTM, TBM, TMQ, TMX, ZIP
**TB supported file types:** CSV, TBX, TSV, XLSX
**File limitations:**
* Memory files can contain as many terms as you like, so long as the file adheres to the [TM Size limits](/kb/tm-size-content-guidelines). In particular, individual files cannot exceed 200 MB. If files exceed this size, zip them before uploading. Once uploaded, the file will be parsed into individual, editable entries.
* See the [Memory Maintenance Best Practices](/kb/memory-maintenance-best-practices) article for information on how to structure CSV files for uploading Termbases.
* Termbase column entries cannot contain more than 10,000 characters. When uploading a file where any column entries are more than 10,000 characters, LILT will not process the file and will display the following warning:
* When importing JSON files as TM entries into LILT, use the format shown below to ensure your memory entries are properly imported:
```json theme={null}
[
{
"srclang": "es",
"creationdate": "2019-04-04T11:24:22Z",
"text": "Introducción[editar]",
"units": [
{
"trglang": "en",
"text": "Introduction"
}
]
},
{
"srclang": "es",
"creationdate": "2019-04-04T11:24:22Z",
"text": "Aumentar",
"units": [
{
"trglang": "en",
"text": "Increase"
}
]
}
]
```
**Memory types:**
* **Memory (TM):** Choose this option if you want your memory files to be indexed for Concordance, used to train the [MT](/kb/machine-translation), and used as TM results. The MT model learns from uploaded data immediately upon upload. Note that deleting documents from a Data Source **does not** affect the MT model (i.e. the MT model does not unlearn the deleted resources). However, there is a recency bias, meaning the most recent documents have a stronger input on the translation output.
* **Memory (TM, concordance only):** Choose this option if you want your memory files to only be indexed for [Concordance](/kb/concordance) but not used to train the MT and not used as TM results.
* **Termbase (TB):** Choose this option if your Termbase document **does not** have a header and you want all entries to be added to the Termbase entries of the Data Source.
* **Termbase (TB, with header):** Choose this option if your Termbase document has a header at the top of the file that you want to exclude from adding to the Termbase entries of the Data Source.
**Metadata:** If you load in a file with metadata, LILT creates and populates custom fields for each TM/TB entry as the file is added to the Data Source. Metadata can be useful for providing context about translations. Metadata fields for each Data Source entry can be modified from within LILT by opening a TM/TB entry for editing. More details on this can be found in the [Managing Termbase and Translation Memory Entries](/kb/managing-termbase-and-translation-memory-entries) article.
When uploading a file with metadata fields, you will be presented with a popup form to map the metadata fields to existing metadata fields or new metadata fields.
### Deleting Memory files
Click the `Delete` button in the upper-right to bring up a popup to confirm you want to permanently delete the selected resources. Deleting a resource permanently removes all that resource's TM/TB entries from the Data Source.
![]()
# DeepL Configuration
Source: https://support.lilt.com/kb/deepl-configuration
To configure DeepL the customer only needs a single key. If the customer can login to DeepL, grabbing the key should be simple.
DeepL has their own instructions [here](https://support.deepl.com/hc/en-us/articles/360020695820-Authentication-Key).
1. Sign into DeepL (Username and PWD)
2. Click on [account](https://www.deepl.com/account/summary)
![]()
3. On Accounts page, scroll down to Authentication Key for DeepL API.
![]()
4. Copy key from DeepL and input into LILT. Click enable for your organization, turn on terminology if customer is interested. Click “Save”.
### FAQ
Q: Is formality turned on or off by default
A: Formality is turned off so that terminology is respected.
# Default Roles
Source: https://support.lilt.com/kb/default-roles
LILT comes with default roles to help you easily manage your translation team within LILT: customer administrator, manager, customer, translator, reviewer, and secondary reviewer.
This article outlines the permissions for each of the default roles. If you need to add additional roles, you can create them using [Custom Roles](/kb/custom-roles).
## Job and Project permissions
This permission table applies to Jobs and Projects created by administrators and managers of the organization. Jobs and Projects created by translators and reviewers are treated as private projects that aren’t accessible by the organization. Read more about this in the [Team Resources](/kb/team-resources) article.
| | **Customer Administrator** | **Manager** | **Customer** | **Translator / Reviewer** | **Secondary Reviewer** | **Customer + Create** |
| ------------------------------------------ | -------------------------- | ----------- | ----------------- | ------------------------- | ---------------------- | --------------------- |
| View Jobs | **✓** | **✓** | **✓2** | **✓1** | **✓1** | **✓2** |
| Create/edit Jobs | **✓** | **✓** | **✓3** | **—** | **—** | **✓3** |
| View Projects | **✓** | **✓** | **✓2** | **✓1** | **✓2** | **✓2** |
| Create/edit Project | **✓** | **✓** | **—** | **—** | **—** | **—** |
| Manage documents | **✓** | **✓** | **—** | **—** | **—** | **—** |
| Edit documents in Translate or Review mode | **✓** | **✓** | **—** | **✓1** | **✓1** | **—** |
| Assign tasks to translators and reviewers | **✓** | **✓** | **—** | **—** | **—** | **—** |
| Upload files | **✓** | **✓** | **✓3** | **—** | **—** | **✓3** |
| Download files | **✓** | **✓** | **✓** | **—** | **—** | **✓** |
| View reports | **✓** | **✓** | **—** | **—** | **—** | **—** |
| Edit Source Segment | **✓** | **✓** | **—** | **—** | **—** | **—** |
| LILT Create access (if enabled) | **✓** | **—** | **—** | **—** | **—** | **✓** |
| Analytics | **✓** | **✓** | **✓** | **—** | **—** | **✓** |
1 *Translators and reviewers can only view jobs/projects they have been assigned to.*
2 *Can only see project information, no personal identifiers about linguists assigned.*
3 *Customers can create jobs using the enterprise portal*
## Data Source permissions
| | **Customer Administrator** | **Manager** | **Translator / Reviewer** | **Secondary Reviewer** | **Customer** | **Customer + Create** |
| ---------------------------- | -------------------------- | ----------- | ------------------------- | ---------------------- | ------------ | --------------------- |
| View Data Sources | **✓** | **✓** | **—** | **—** | **—** | **—** |
| Create/edit Data Sources | **✓** | **✓** | **—** | **—** | **—** | **—** |
| View terminology data | **✓** | **✓** | **✓** | **—** | **—** | **—** |
| Create/edit terminology data | **✓** | **✓** | **✓** | **—** | **—** | **—** |
## Role permissions
| | **Customer Administrator** | **Manager** | **Translator / Reviewer** | **Secondary Reviewer** | **Customer** | **Customer + Create** |
| ------------------------ | -------------------------- | ----------------- | ------------------------- | ---------------------- | ------------ | --------------------- |
| Create/edit team members | **✓** | **✓1** | **—** | **—** | **—** | **—** |
| Manage integrations | **✓** | **—** | **—** | **—** | **—** | **—** |
| Create/edit roles | **✓** | **—** | **—** | **—** | **—** | **—** |
1 *Managers cannot create or edit administrators.*
## Organization permissions
| | **Customer Administrator** | **Manager** | **Translator / Reviewer** | **Secondary Reviewer** | **Customer** | **Customer + Create** |
| --------------------------------- | -------------------------- | ----------- | ------------------------- | ---------------------- | ------------ | --------------------- |
| View API key | **✓** | **✓** | **—** | — | **✓** | **✓** |
| Create/edit API key | **✓** | **—** | **—** | **—** | **—** | **—** |
| View organization settings | **✓** | **—** | **—** | **—** | **—** | **—** |
| Create/edit organization settings | **✓** | **—** | **—** | **—** | **—** | **—** |
| View user visibility¹ | **✓** | **✓** | **—** | **—** | **—** | **—** |
| Activate MCP connectivity | **✓** | **—** | **—** | **—** | **—** | **—** |
1 [**`Read more about the View user visibility option in the Custom Roles article.`**](/kb/custom-roles)
#### External Linguist Role
The external linguist role has all the same permissions as a Translator or Reviewer role, without any Payment data on [My Stats](/kb/linguist-stats).
# Troubleshooting
Source: https://support.lilt.com/kb/deleting
## Resetting AI Models
To reset AI models, follow the guide at [Enable/Disable Features](/kb/enable-features) and run the command:
`npm run dist-admin-cli -- mass-reset-ai --orgId=`
## Deleting Resources
### Deleting Jobs via Database
* After accessing your Lilt DB and given you know the id of the corrupt job you can simply update the isDeleted and deletedAt rows as so
* Change the deletedAt date and id to the relevant values
* UPDATE lilt\_dev.Jobs t\
SET t.isDeleted = 1, t.deletedAt = '2024-06-06 09:18:03'\
WHERE [t.id](http://t.id) = 9;
### Deleting Default DataSource via Database
* Similarly to delete the default data source you will do a similar process on the Memories table
* Change the deletedAt date and id to the relevant values
* UPDATE lilt\_dev.Memories t\
SET t.isDeleted = 1, t.deletedAt = '2024-06-06 09:33:21'\
WHERE [t.id](http://t.id) = 1;
### Finding ID of the DataSource
* Simply navigate to the datasource you want to delete and the route should be something like this, /app/memories/\/edit/resources
### Finding the ID of the Corrupt Job
* There isn't enough information for us to correctly identity it, we believe the best way might be to just visit every job this user has to see if it will load or not. If a job doesn't load it's a likely candidate to deletion
* Jobs URL should look like this, /app/jobs/\/projects
* Getting a list of jobs from the database should be as follows, simply swap out the UserId with the correct one.
* SELECT \* FROM lilt\_dev.Jobs WHERE UserId = 2
# Disk Space Requirements
Source: https://support.lilt.com/kb/disk-space-requirements
Customers with a self-managed installation of LILT will need to provision disk space according to their own translation volumes. This article provides guidance on a disk space rules-of-thumb and file type distributions.
## Stored artifacts
When a file is initially imported into LILT, LILT stores the following artifacts:
* source file
* intermediate Okapi artifact
* intermediate extracted XLIFF
* translated target file
This results in an upper-bound disk space requirement of approximately 4x the total source file size. That is, customers planning to translate 10 GB of documents using LILT should provision at least 40 GB of hard drive space.
## Typical file size distribution
Customers may expect to translate predominantly text documents (TXT, CSV, HTML, XML, JSON) and desktop publishing formats (WORD, EXCEL, PDF, etc.) without knowing the distribution of files on their system.
A random sample of LILT data shows that text-based file formats are the most common, but multimedia-heavy formats such as PPTX files use the most disk space:
| | | |
| ------------ | -------------------------------- | -------------------------- |
| **Filetype** | **Number of files (% of total)** | **Data used (% of total)** |
| PPTX | \<1% | 46% |
| SDLXLIFF | 8% | 14% |
| DOCX | 7% | 14% |
| MIF | \<1% | 5% |
| PDF | \<1% | 5% |
| XLSX | 2% | 4% |
| XML | 37% | 2% |
| XLIFF | 3% | 2% |
| JSON | 2% | 2% |
| XLF | 4% | 2% |
| IDML | \<1% | 1% |
| MQXLIFF | \<1% | 1% |
| HTML | 6% | \<1% |
| JSON+HTML | 22% | \<1% |
| TXT | \<1% | \<1% |
# Document Actions
Source: https://support.lilt.com/kb/document-actions
The information and actions available on LILT’s Document cards facilitates an efficient translation workflow for both linguists and project managers.
This article goes over the actions that can be performed on single documents. To see how to perform actions on multiple documents at once, see the [Bulk Document Actions](/kb/bulk-document-actions) article.
## Document card
Click on the expand button ![]()
on a Document card to open up a detailed view of the document.
* **Assignment accepted/rejected icon:**
* If all linguists assigned to a document have accepted their assignment, a check mark icon ![]()
will display next to the document name.
* If there are any linguists who have not yet accepted their assignment, **no icon** will display next to the document name.
* If any of the linguists have rejected their assignment, a cross icon ![]()
will display next to the document name.
* **Last updated time (upper-left):** The last update time updates when assignments change, when changes are made in Translate mode, or when changes are made in Review mode.
## Upload documents
To upload documents to a Project, drag and drop the files into the box at the top of the screen, or click the `Import` button to browse for files on your computer. You can also drag and drop a folder of documents into the box to upload all the files in the folder at once.
![]()
## Assign and set due dates
Once a document has been uploaded, project managers can assign linguists and due dates for the document in several ways:
* Assignments can be made from the [Project view](/kb/navigating-the-projects-list).
* Assignments can be made from the Document card dropdown menu by clicking the `Assign` button.
![]()
* Assignments can be set from the Document card by clicking any of the `Assign` or `Set due date` buttons.
![]()
Clicking any of the buttons mentioned above will open the assignment popup form where you can select a translator, translation due date, reviewer, and review due date.
![]()
Once linguists have been added, click the `Assign` button to assign them to the document. They will be sent an email from [noreply@em.lilt.com](mailto:noreply@em.lilt.com) letting them know they have been assigned. Then the linguists can accept or reject the assignment.
![]()
Once translation and review due dates are set, they are displayed on the Document card.
![]()
## Open a document to translate or review
**Translator:** If you are assigned to a document as a translator, click the `Translate` button (or click the Document name) to open the document into LILT Translate in Translate mode.
![]()
\*\*Reviewer:\*\*If you are assigned to a document as a reviewer, click the `Review` button (or click the Document name) to open the document into LILT Translate in Review mode.
![]()
\*\*Project manager:\*\*If you are a project manager, you can open into either mode:
* Open Translate mode by clicking the `Translate` button.
* Open Review mode by opening the Document card dropdown menu and clicking the `Review` button.
![]()
## Pretranslate documents
![]()
Under the document options dropdown ![]()
, you have the option to Pretranslate documents. More information on Pretranslating can be found in these articles:
* [Instant Translating Documents](/kb/pretranslating-documents)
* [Using Pretranslation Effectively](/wiki/pages/createpage.action?spaceKey=KNOWLEDGEB\&title=Using%20Pretranslation%20Effectively%20\&linkCreation=true\&fromPageId=10486009)
## Download documents
![]()
Under the document options dropdown ![]()
, there are several options for downloading a document:
* **Download:** Download the document in its original format.
* **Download TXT:** Download the document as a TXT file.
* **Download XLIFF:** Download the document as an XLIFF file.
## Delete documents
![]()
Under the document options dropdown ![]()
, you have the option to delete a document. Clicking this button will bring up a popup box to confirm that you want to permanently delete the document.
## Filter Documents
Filtering Document cards lets you quickly get to the documents that need your attention. The `Translator` and `Reviewer` filters can be used together or individually to display Document cards based on various translation and review statuses. If any translators or reviewers are assigned to documents in the project, their emails will show up in the filter lists.
![]()
## Sort documents
The sort option gives you several methods to sort the Document cards within a project. By default, Document cards are sorted by name.
![]()
Once you have selected the sorting method, you can click the sort order button next to the sort list button to change the sort order between ascending and descending.
![]()
## Search documents
Search for documents by name by typing into the search bar. Documents will filter in real-time as you type.
![]()
# Document Navigation Tab
Source: https://support.lilt.com/kb/document-navigation-tab
The Document sidebar tool in [LILT Translate](/kb/introduction-to-lilt-translate) allows linguists to quickly navigate between documents in a Project. Once located, these phrases can be replaced as desired. This is a useful tool for keeping track of the status of documents fully translated and reviewed, and navigating between them.
![]()
# Drupal
Source: https://support.lilt.com/kb/drupal
LILT + [Drupal](https://www.drupal.org/) connector enables companies to automatically push and pull content between Drupal and LILT. This saves you time by providing seamless localization while letting you continue to work in the systems you know.
Our integration with Drupal allows LILT to send completed translation projects right back into Drupal so that translated content is ready to be published. The Drupal connector is an app based connector. Job submission and management is controlled inside the Drupal interface; everything is handled inside the TMGMT interface.
## Configuration
At a high level, the installation steps are as follows:
1. Install the TMGMT module.
2. Install the TMGMT LILT Provider module.
3. Enable the modules.
4. Configure the LILT Provider module.
Drupal supports installing modules directly in the admin interface. The package installation procedure is detailed [here](https://www.drupal.org/docs/user_guide/en/extend-module-install.html).
1\. Log in to the admin interface.
2\. Go to `Extend`>`Install New Module`.
![]()
3\. Enter the package URL that you want to install and click Install.
![]()
Two packages will need to be installed. Perform the installation procedure described above for the following two packages.
1. [TMGMT](https://www.drupal.org/project/tmgmt/releases/8.x-1.11)
2. [TMGMT LILT Provider](https://www.drupal.org/project/tmgmt_lilt/releases/8.x-1.x-dev)
Use these links in the installations steps described above.
### Enable packages
Once the packages are installed, go to the modules overview page, enable the Translation Management packages, then click `Install`.
![]()
![]()
### Configure LILT provider
1\. Go to the `Translation` > `Providers` page.
![]()
2\. On the LILT provider entry, click the `Edit` button.
![]()
3\. Enter the LILT API Key, and click `Save`. *Note: the URLs will default to the correct values, and the remaining values are optional.*
![]()
## Workflow
Once the connector is configured, content is moved between LILT and Drupal as outlined in the sections below.
### Job submission
1\. Navigate to `Translation`>`Sources`.
![]()
2\. Select the content and languages you want, request translation, and complete the checkout form (including due date and data source / memory selection). When a job is submitted, the projects will show up in LILT right away.
![]()
![]()
### Job progress and completion
1\. Navigate to `Translation`>`Jobs` to view a list of all current jobs.
![]()
2\. Find the desired job and click `Manage` to open the job.
![]()
3\. Click `Pull Translations` to pull in completed translations into Drupal. For content to be returned, the projects must be marked as `Done` in LILT.
![]()
4\. Click `Review` to preview the translation.
![]()
5\. Click `Save` to complete. The translation will be published once it is completed.
![]()
# Setting Deadlines
Source: https://support.lilt.com/kb/due-dates-for-jobs-projects-documents
## For Jobs, Projects & Documents
The LILT platform allows managers to optionally set deadlines at the Job, Project, and Document level to ensure content is delivered on schedule. It is important to note that each of these deadlines is separate from one another. Linguists need to pay attention to Document level deadlines to ensure they complete their tasks on time to allow on-time delivery for Projects and Jobs.
The sections below outline where to find each type of deadline.
If a job is created without a set deadline, it will default to the standard deadlines determined in a customer’s contract.
If a customer creates a job with a deadline beyond the standards defined in their contract, then the job will respect the deadline set by the customer.
## Job deadlines
As described in the [Navigating the Browse Jobs List](/kb/navigating-the-jobs-list) article, the deadline for each Job is displayed on each Job card (for all Jobs with deadlines).
![]()
## Project deadlines
As described in the [Navigating the Projects List](/kb/navigating-the-projects-list) article, the deadline for each Project is displayed on each Project card (for all Projects with deadlines).
![]()
## Translation and review deadlines
As described in the [Document Actions](/kb/document-actions) article, when browsing a Project’s documents, the translation and review dates for each document are displayed on each Document card (for all documents with deadlines).
Translation deadline:
![]()
Review deadline:
![]()
Document-level deadlines can also be found in the document assignment emails automatically sent to translators and reviewers. However, it is important to note that linguists are not notified of changes to deadlines after assignment.
# Heretto (Fka EasyDITA)
Source: https://support.lilt.com/kb/easydita
LILT + [heretto](https://www.heretto.com/) connector enables companies to automatically push and pull content between easyDITA and LILT. This saves you time by providing seamless localization while letting you continue to work in the systems you know.
Watch this [3-minute overview](https://fast.wistia.com/embed/iframe/mb2qrwmroi) to see what LILT + Heretto (fka EasyDITA) can do for you.
## Configuration
Within Heretto, create a new user and provide its login credentials to your contact at LILT.
## Workflow
Once the connector is configured, content is moved between LILT and Heretto as outlined in the sections below.
### Project creation
In Heretto, open the action menu on the file you want to localize and click`Localization Jobs`. Click `XLIFF Package` in the top-right and click `Go`. Add the desired target locales and click `Save`. This queues the content for localization.
LILT periodically checks Heretto for new content queued for localization. When new content is found, it is automatically pulled into LILT as new Projects where the content can be translated.
### Project completion
LILT periodically checks for Projects marked as `Done`. When found, the localized content is automatically sent back to Heretto.
# Enable/Disable Features
Source: https://support.lilt.com/kb/enable-features
## Feature List
The complete list of feature flags and org settings — including scope and how each is configured — is documented in the [Feature Flag Reference](/kb/feature-flags). The flags below are configured via the procedures on this page and are most relevant to self-managed deployments:
| **Feature** | **Type** | **See** |
| ---------------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
| enableNewLinguistPage | [Admin CLI](/kb/enable-features#enable-features-via-admin-cli) | [Linguist Homepage](#linguist-homepage) below |
| enableLiltCreate | Both | [LILT Create](#lilt-create) below |
| Incompatible Browsers | [Environment Variable](/kb/enable-features#enabling-features-via-environment-variables) | [Incompatible Browsers](#incompatible-browsers) below |
| enableOCR | [Admin CLI](/kb/enable-features#enable-features-via-admin-cli) | Enable OCR using internal Tesseract deployment |
| enableOpenAiWhisper | [Admin CLI](/kb/enable-features#enable-features-via-admin-cli) | Enable ASR using internal Whisper deployment |
| enableWSO2Login | [Admin CLI](/kb/enable-features#enable-features-via-admin-cli) | See [WSO2 SSO configuration](/kb/single-sign-on-sso#wso2) |
| External Model Configuration | [Environment Variable](/kb/enable-features#enabling-features-via-environment-variables) | [External Model Configuration](#external-model-configuration) below |
## Enable Features via Admin CLI
NOTE: For LILT November 2023 release onwards, please use `npm run dist-admin-cli` instead of `admin-cli`
Perform the following steps to enable features for the organization:
1. Connect to front pod:\
`master# kubectl exec -it -n lilt -c front -- /bin/bash`
2. To enable the feature for an organization, run this command from a front pod, replacing `[enableFeature]` with the appropriate feature and `` with the relevant Organization ID:\*\*
```bash theme={null}
npm run dist-admin-cli -- set-org-setting --orgIds --settingName=[enableFeature] --value=true
```
3. Refresh the UI.
4. Repeat this for all the organizations.
### Linguist Homepage
The Linguist Homepage is enabled for the default Translator and Reviewer roles. For custom roles, you will need to select what the user’s homepage should be. For more information, please refer to documentation for the [Linguist Homepage](/kb/lilt-linguist-homepage).
![]()
#### Configuration instructions
In order to configure the Linguist Homepage, please run the following command for each org:
`npm run dist-admin-cli -- set-org-setting -o=1 -s=enableNewLinguistPage -v=true`
Please note: New customers as of Q2 2024 have this enabled by default. If you’re a customer who has been working with LILT since before Q2 2024, you will need to enable this if you’d like the Linguist Homepage.
## Enable workflow
Workflows are enabled by default. However, if you don’t see them due to migration issues, connect to the front pods and run the following commands.
```bash theme={null}
npm run dist-admin-cli -- create-workflows-data -o=
```
## Enabling Features via Environment Variables
### Incompatible Browsers
Add a new environment variable to the front values.yaml file as such `ALLOW_INCOMPATIBLE_BROWSERS: true` . This should be the same place customers configure their header and footer text.
## LILT Create
### In the UI
LILT Create is enabled by default. In environments where this has the possibility to cause confusion to users, system administrators can configure LILT Create per organization. If disabled, users navigating to the LILT Create page will instead see a brief statement that LILT Create has not been enabled for their organization.
![]()
#### Configuration instructions
In order to disable the LILT Create page, please run the following command for each org:
`npm run dist-admin-cli -- set-org-setting -o=1 -s=enableLiltCreate -v=false`
### System Configuration
Please follow the instructions in the section [Enable LLM Services](#enable-llm-services).
## Miscellaneous Configurations
### LILT QA Checks
LILT QA Checks are enabled by default. To disable this functionality, set the following value in your `lilt/environments/lilt/values.yml` file:
```bash theme={null}
qa:
onpremValues:
app:
args:
option4: --disable-lilt-qa-checks
```
## LLM Services
With the LILT v5.3.0 release (November 2025), customers can now opt to enable a set of additional LLM services. Follow the steps below to configure the following features:
| **Feature** | **Service/ Model** |
| ---------------------------------- | ------------------ |
| LILT Create | Llama3 (GPU Only) |
| OCR | Gemma (GPU Only) |
| ASR (Automatic Speech Recognition) | Whisper (GPU/ CPU) |
### Prerequisite
Each of these services requires dedicated GPU resources. Please refer to the [Self-Managed Hardware Requirements](/kb/self-managed-hardware-requirements) for the specific resource needs.
### Enable
1. GPU Availability: LLM services should not be enabled on systems with only 3 GPUs, as this may cause instability in standard neural services (translation, update) due to limited resources.
2. Update `values.yaml` and enable the following services for the required feature:
a. `llama-vllm-inference`: Llama3 model for LILT Create
b. `gemma-vllm-inference`: Gemma model for OCR
c. `llm-inference-whisper`: Whisper model for ASR
##### Using CPU Workers for ASR (Whisper Model)
To run ASR (Whisper) on CPU workers instead of GPU, follow the guidance in your custom `values.yaml` and deploy. For example:
```bash theme={null}
# Uncomment the following lines if using CPU workers
# includeTensorflowThreadSettings: false
# bucket: lilt
# resources:
# requests:
# cpu: 1
# memory: 8G
# limits:
# memory: 8G
# Remove the following nodeSelector if using CPU workers
nodeSelector:
capability: llm-gpu
node-type: whisper
# Uncomment the following lines if using CPU workers
# nodeSelector:
# node-type: worker
```
## External Model Configuration
Self-managed deployments can optionally allow organization administrators to control which external AI providers (e.g., Amazon Translate, Google Translate, DeepL, Azure, OpenAI, Anthropic, AWS Bedrock) are available on the AI Providers page.
When enabled, a new **External Models** tab appears under **Organization Settings** where administrators can toggle individual providers on or off.
### Enable
Set `ENABLE_EXTERNAL_MODEL_CONFIG` to `true` in your `values.yaml` and deploy. The **External Models** tab will then appear under **Organization Settings** for all organizations.
### Configure Providers
Administrators can enable providers in two ways:
**Via the UI:**
1. Navigate to **Organization Settings** > **External Models**
2. Toggle on the desired providers
3. Enabled providers will immediately appear on the **AI Providers** page
**Via the Admin CLI:**
```bash theme={null}
npm run dist-admin-cli -- set-org-setting --orgIds \
--settingName=enabledAIProviders \
--value='{"aws":true,"google":true,"deepl":true}'
```
The setting accepts a JSON object where keys are provider identifiers and values are booleans. Available provider keys:
| **Key** | **Provider** |
| ------------ | ---------------- |
| aws | Amazon Translate |
| google | Google Translate |
| deepl | DeepL |
| azure\_gpt | Azure |
| open\_ai | OpenAI |
| anthropic | Anthropic |
| aws\_bedrock | AWS Bedrock |
Providers that are already configured (i.e., credentials have been saved) will always appear on the AI Providers page regardless of the toggle state. The toggle only controls visibility of unconfigured providers.
# Enable Incompatible Browsers
Source: https://support.lilt.com/kb/enable-incompatible-browsers
Add a new environment variable to the front values.yaml file as such `ALLOW_INCOMPATIBLE_BROWSERS: true` . This should be the same place customers configure their header and footer text.
# Encryption And Access Control
Source: https://support.lilt.com/kb/encryption-and-access-control
## Encryption and Encoding
### Database
The application database is configured to use the *AES-128* encryption algorithm in ECB (Electronic Codebook) mode.
### Storage
The data is stored using the openebs-localpath PVC storage class, leveraging the default Linux-enabled encryption set up within the customer’s infrastructure (by customer’s sysadmin). If AWS is used for storage, the app is compatible with buckets encrypted using AWS KMS.
### Kubernetes
*Istio* STRICT mode enables end-to-end encryption in Kubernetes clusters by using mutual TLS (mTLS) for secure service-to-service communication.
Kubernetes secrets are stored in etcd in a *base64-encoded* format.
### Application
User passwords in the application are hashed using *bcrypt*.
## Access Control
### Application
#### Organizations
Organizations represent the highest granularity multi-tenancy. Users in separate organizations do not share translation data, user accounts or other project information.
#### Role-Based Access Control & Domains
Within an organization, LILT manages application access through role-based access control. For more information, visit our public article [/kb/role-based-access-control](/kb/role-based-access-control) .
[LILT Domains](/kb/lilt-domains) allows organizations to segment their workflows by assigning resources—such as users, models, and preferences—to specific domains.
### Services
Application access to backend services is managed through *Kubernetes* service accounts and secrets. These details can be configured during the application setup.
# Explore Analytics with Assist
Source: https://support.lilt.com/kb/explore-analytics-with-assist
LILT Assist provides real-time visibility into your global content program. By analyzing complex data through a conversational interface, Assist helps you track quality trends, monitor AI performance, and evaluate budget and delivery metrics to make data-driven decisions about your translation strategy.
### Key Features
* **Quality Trend Tracking:** Monitor how translation quality scores evolve over time across different language pairs and content types.
* **AI Accuracy Monitoring:** Evaluate the performance of your company’s trained models against human-vetted benchmarks to identify where automation is most effective.
* **Delivery Performance:** Analyze turnaround times, project velocity, and deadline compliance to ensure global content stays on schedule.
* **Customizable Visualization:** Request specific data views, such as bar charts or tables, and download findings as CSVs or images for internal presentations.
* **Data Portability:** Quickly generate and download reports in CSV format or export charts for use in internal stakeholder presentations.
### How to Use
1. To get started, use a prompt (e.g., *"What was the AI accuracy for my english-dutch model from last month"*) or click the Analytics card.
2. Tell the agent exactly what data you are looking for. (Note: You can only access data that your user role is permitted to see on the [Analytics page](https://support.lilt.com/kb/lilt-analytics-v2#analytics) in LILT).
* **Metric:** Specify your interest (e.g., *model accuracy, delivery reports, OTD trends, or budget information*).
* **Segment:** Define the focus (e.g., *specific language pairs, connectors, or projects*).
* **Timeframe:** State the period (e.g., *past quarter, last 30 days, or year-to-date*).
* **Format:** Choose the presentation (e.g., *table, bar chart, or CSV*).
3. Review the Agent’s proposed plan and confirm to begin.
4. Assist will generate the visualization directly in the chat. You can ask for further filters or request a download link for the CSV or image file.
### Best Practices for Analytics Prompts
To get the most accurate insights, be **clear and direct**. Since the agent draws from the same data pool as the platform's reports, specific commands work best. Use these four details to build a strong prompt:
* **Action:** What should the agent do? (*Analyze, compare, list, generate*)
* **Object:** What specific data is being looked at? (*WPA metrics, invoices, OTD rates*)
* **Parameters:** What filters apply? (*Language pairs, connectors, or specific linguists*)
* **Context:** Any special requirements? (*Time period, data format*)
### Quick-Start Prompts
**Performance and Quality**
* *Show me on-time delivery by language pair for all projects completed this month.*
* *Can you generate a bar chart with our AI accuracy for english-german for the past six months?*
**Financial and Operational Data**
* *Provide a pricing breakdown by language pair for all invoices processed in March 2026.*
* *Show me the error rates and job statistics for our Contentful connector over the last 30 days.*
### Sample Agent Interactions
```text theme={null}
User: "Can you provide AI accuracy data by language pairs?"
Assist: "To pull this data for you, I need a few details:
- Time Period: What date range would you like to analyze?
- Domain: Are you looking at data from a specific domain, or all domains?
- Model Type: Would you like to see Unadapted AI (baseline) and Adapted AI (fine-tuned)?
- Format Preference: Would you prefer a data table with all language pairs or a visual chart/graph?
Once you provide these details, I can generate the analysis for you."
User: "Please provide data on adapted AI over the last six months for all domains in a table."
Assist: "Perfect! I'll help you analyze Adapted AI accuracy by language pair over the last six months. Let me set up the plan for you."
```
```text theme={null}
User: "Can you give me a pricing breakdown for our projects last month?"
Assist: "I've pulled your financial data for March 2026. I can break this down by language pair, invoice total, or monthly trend. Which view would be most helpful for your review?"
User: "Break it down by language pair and download as a CSV."
Assist: "Understood. I have generated a pricing breakdown by language pair for March 2026. You can download the CSV file here: [File Download Link]."
```
# Feature Flag Reference
Source: https://support.lilt.com/kb/feature-flags
This page lists every configurable feature flag and org setting exposed by the LILT platform. For the on-premises Admin CLI and environment-variable procedures, see [Enable/Disable Features](/kb/enable-features).
## Translation & Workflow
Free-text additional guidelines attached to Prompt Response jobs. Set during job creation and persisted onto the job's settings by `createJob`; surfaced back in the job details/additional-guidelines field for prompt-response job types.
Enables bulk auto-assignment of due dates across projects, surfaced in the "Bulk Assign Due Dates" project-list modal and its onboarding-flow counterpart, and used by the project assignment API service when computing/submitting bulk due-date assignments.
Controls whether exact TM matches and repetitions are automatically confirmed without requiring translator/reviewer action. Read into the CAT editor's settings object (`useCATSettings`) as `autoConfirmExactMatchesAndRepetitions`. Editable via the project's Workflow Settings form and listed in `projectSettingKeys` so a project can override the org default.
When automatic pretranslation (`EnableAutoPretranslate`) is on, controls whether pretranslated segments are automatically accepted and locked rather than left pending for translator review. Read at document/job creation (`createJob`, `createDocument`, `addDocumentToProject`) and by `PretranslateSettingsService`, which maps it to the `autoAccept` flag returned to the pretranslate pipeline. Editable via the project's Workflow Settings form alongside the other `AutoPretranslate*` sub-settings.
Org-level toggle added alongside the other `AutoPretranslate*` sub-settings (see `add-pretranslation-setting-keys` migration) to control case sensitivity of pretranslate TM matching, but `PretranslateSettingsService.getPretranslateSettings` actually sources its `caseSensitive` result from the separate `CaseSensitiveTMMatch` setting, not this one. No current front-end or server code path reads this setting, so treat it as reserved/likely inert (superseded by `CaseSensitiveTMMatch`).
When automatic pretranslation (`EnableAutoPretranslate`) is on, controls whether exact TM matches used for pretranslation are attributed to the matched translator (authorship) rather than the system. Read at document/job creation and by `PretranslateSettingsService`, which maps it to the `takeMatchAttribution` flag returned to the pretranslate pipeline. Editable via the project's Workflow Settings form alongside the other `AutoPretranslate*` sub-settings.
When automatic pretranslation (`EnableAutoPretranslate`) is on, controls whether MT (machine translation) output is used to pretranslate segments that don't have a TM match, versus leaving unmatched segments untranslated. Read at document/job creation and by `PretranslateSettingsService`, which switches the pretranslate mode between `TRANSLATE_WITH_TM` and `TRANSLATE_WITH_TM_AND_MT` based on this value. Editable via the project's Workflow Settings form alongside the other `AutoPretranslate*` sub-settings.
Toggles whether post-processing is enabled by default at job creation. Read by `createJob`/`JobsController` on the server (when explicit per-job `enablePostProcessing` isn't provided) to seed the job's post-processing flag, and by `VerifiedTranslationOptions`/ `FileTranslationTab` on the client to initialize the job-creation form.
Sets whether newly created jobs default to the "verified translation" workflow. Read by `TranslateHomepage`/`FileTranslationTab` to initialize the job-creation form. Editable via the org's Job Form Editor and listed in `projectSettingKeys` so a project can override the org default.
Sets the workflow template pre-selected by default when creating a new job/project. Read by `useWorkflows`/`SettingDefaultWorkflow` on the client and by `createJob`/`createNewProject` on the server to seed a job's workflow when the caller doesn't specify one explicitly. Editable in the org's General Settings form and listed in `projectSettingKeys` so a project can override the org default.
Org-level, non-user-facing (`isUserFacing: false`) toggle historically intended to disable TM fuzzy matching. No current front-end or server code path reads this setting outside of the on-prem default-value migration, so treat it as reserved/likely inert until a live consumer is found.
Org-level toggle intended to enable Automatic Speech Recognition (ASR) functionality. No current front-end or server code path reads this setting outside of the on-prem default-value migration, so treat it as reserved/likely inert until a live consumer is found.
Master toggle for automatic pretranslation of new documents/jobs: when enabled, incoming segments are pretranslated from TM/MT at document creation (`createDocument`/`addDocumentToProject`) instead of starting blank, and the sibling `AutoPretranslate*` settings (accept & lock, exact-match authorship, MT-for-unmatched) only take effect while this is on. Surfaced as an editable field in both the org-level General Settings form and a project's Workflow Settings form, and listed in `projectSettingKeys`/`projectSettings` so a project can override the org default.
Org-level toggle originally added alongside `EnableAutoPretranslate` and its sibling sub-settings (see `add-pretranslation-setting-keys` migration), but unlike those siblings it is not user-facing (`isUserFacing: false`) and no current front-end or server code path reads it. Treat as reserved/likely inert until a live consumer is found.
Marks a project/job as using the auto-revisions feature of an AI-optimized (Human+AI Optimized) workflow. Not user-toggled directly — `createJob`/`createNewProject` write this setting automatically (scoped to the project) whenever the selected workflow is one of the `kOptmizedWorkflowNames` optimized workflows.
Org-level toggle intended to control backward propagation of translation/TM corrections (e.g. applying a later correction back to earlier matching segments). No current front-end or server code path reads this setting outside of the on-prem default-value migration, so treat it as reserved/likely inert until a live consumer is found.
Org-level toggle for the Data Labeling workflow feature: gates the "Data Labeling" nav sidebar item and homepage card, and filters which workflow templates `useWorkflowTemplates` offers for prompt-response jobs (only `kDataLabelingWorkflowNames` templates are surfaced when enabled). Also read by `WorkflowSettingsForm` to decide whether to show the related "Prompt Labeling" project setting.
Org-level toggle that enables direct-to-cloud (client-to-storage) uploads for job file uploads, bypassing the app server for large files. Read at client startup (`client_initial_state_provider`) and applied via `setEnableDirectToCloudUploads` in the cloud upload middleware.
Controls whether the TM export modal (`ExportTmxModal`) offers the filtered-export option when exporting a memory as TMX, letting users scope the export with field-based filters (`ExportTmxFilters`/`MemoryExportFilter`) instead of exporting the full memory.
Org-level toggle that switches job creation to use the project-level quote-and-recalculation flow with a loading indicator, instead of the legacy per-job quoting path.
Org-level toggle historically intended to enable use of Google Translate results when performing TM (Translation Memory) lookups. No current front-end or server code path reads this setting outside of the on-prem default-value migration, so treat it as reserved/likely inert until a live consumer is found.
Org-level toggle that enables automatic Jira ticket creation for jobs. Checked in the job-created notification handler; tickets are only created when this setting is enabled and the requesting user is external (non-`@lilt.com`).
Legacy 2021-era rollout flag for the Jobs feature area. Not user-facing (`isUserFacing: false`) and not read anywhere in the current front client/server code; Jobs are now a standard, always-on part of the platform, so this flag appears vestigial.
Legacy rollout flag for the paginated Jobs list view. Not user-facing (`isUserFacing: false`) and no longer read anywhere in the front client/server code; on-prem and cloud migrations now force its default to `true` fleet-wide, indicating the paginated list is standard behavior and this flag is vestigial.
Routes an organization into the redesigned Job/Translate experience: gates the Job Form Editor, Translate V2, and Instant Job Details routes and the "translate" nav link destination, falling back to the legacy Translate/Home pages when disabled. Rolled out per-org via a dedicated enablement migration rather than an admin toggle.
Org-level toggle historically intended to enable an org-default translation memory. No current front-end or server code path reads this setting outside of the on-prem default-value migrations, so treat it as reserved/likely inert until a live consumer is found.
Job-level setting (default off) that determines whether post-processing (PP) runs on a job. Read during job creation (`createJob`) and by connector auto-delivery logic, which waits for PP to complete before delivering if this is enabled.
Org-level toggle historically intended to enable a "Quick Translate" feature. No current front-end or server code path reads this setting outside of a test fixture and the on-prem default-value migrations, so treat it as reserved/likely inert until a live consumer is found.
Org-level workflow toggle whose on-prem default is forced to `true` (ID 135). Not read anywhere in the current front client/server code (distinct from the actively-used `EnableRejectDocument` project setting), so its behavior is presumably enforced downstream.
Org-level toggle that allows uploading `.string.info` companion files alongside source files. Read by `useAcceptedFileFormats` to add `.info` to the set of accepted upload extensions during job creation.
Org-level toggle intended to control segmentation of subfilters in the Custom File Processing / file filter configuration feature. The underlying setting key was deleted outright by a later migration (`removeEnableSubfilterSegmentation`) and no current front-end or server code path reads it, so treat it as reserved/removed.
Org-level toggle for "Universal File Upload" (enterprise): when enabled, all accepted file types are allowed for upload and OCR pre-processing is started automatically for uploaded files (`ocrMiddleware`), and translate-job submission forces every job through the pre-processing pipeline (`submitJobThunk`/`submitJob`). Read in several job-creation and file-upload flows (`FileCard`, `useAcceptedFileFormats`, `QuotingActions`).
Controls whether segments can be unlocked stage-by-stage in the CAT editor (`catUnlockSegmentsByStage` in `useCATSettings`, sourced from `useDocumentCATSettings`). The setting's DB/string key retains the name "enableUnlockExactMatchedSegmentsByStage" for back-compat, but usage has since expanded to cover all segments, not just exact matches — do not rely on the key name to infer scope. Editable via the project's Workflow Settings form and listed in `projectSettingKeys` so a project can override the org default.
Org-level feature toggle for the Video Dubbing job type. Read by `useEnableVideoDubbing` to control whether Video Dubbing is offered as an option in Instant Translate and job creation.
Legacy org-level toggle originally meant to gate the CAT/document editor's workflow features. `useCATSettings` now hardcodes `enableWorkflows: true` in the settings object it builds ("hardcoded to true until cat removal"), and the only remaining server-side reference (`setEnableWorkflowFlagForOrganization`) is explicitly marked "DEPRECATED - only used in a migration". Treat as deprecated/inert.
Non-user-facing, project-scoped setting storing the numeric id of an external MT model wired up at project creation. Read by the GraphQL `Project.externalModel` field resolver (only evaluated when the client selects that field) to look up and return the model, mirroring Core's `JobStatsManagerImpl.addExternalModelsIfAvailable` selection logic — the setting is the sole source of truth, with no memory/language-pair fallback heuristic.
Org/project-level default for whether newly created jobs use the "AI-optimized" (human+AI hybrid) workflow. Drives the "optimize workflow" toggle default at job creation, is only actionable when the selected default workflow is recognized as AI-optimized and AI Review is enabled, and is configurable from both the org's Default Workflow settings and a domain's workflow preferences.
Org-level JSON setting declaring which opt-in non-translatable (NT) placeholder syntaxes (e.g. double\_brace, single\_brace, percent\_format) the org uses, replacing hardcoded per-customer org-ID lists in core's NTHandler. The universal `${foo}` handling is always on and is not controlled by this setting.
Setting key for a "verified quoting v2" job-creation experience, conceptually paired with the now-deprecated `ShowRequiredQuotingV2`. As of this writing it has no read call site anywhere in `client/` or `server/`; the only reference outside its own enum declaration is the on-prem defaults migration (`changeDefaultSettingOnPrem`), which forces its default to `false` on-prem. The feature it was intended to gate does not appear to be wired up yet.
Org-level toggle added alongside `EnableAutoRevisions` to control whether that setting is surfaced in the org settings UI. No current front-end or server code path reads this setting outside of the on-prem default-value migration, so treat it as reserved/likely inert until a live consumer is found.
## Review & QA
Org-level toggle, nested under `EnableAIQA` in `settingKeysGroups`, that excludes exact TM matches from AI QA checks. Listed in `invertedSettingKeys`, so its stored/displayed boolean is the inverse of the UI label's sense; defaults to `true` per its rollout migration.
Automatically marks the batch-level QA check as done for the secondary (customer) review stage instead of requiring a customer reviewer to run/confirm it manually. Mirrors `AutomaticBatchQaTranslator` and `AutomaticBatchQaReviewer` for the customer-review role and is configured from the org's and a project's Workflow Settings forms (the secondary-reviewer column of the Workflow Settings table).
Automatically marks the batch-level QA check as done for the review stage instead of requiring a reviewer to run/confirm it manually. Mirrors `AutomaticBatchQaTranslator` for the review role and is configured from the org's and a project's Workflow Settings forms.
Automatically marks the batch-level QA check as done for the translation stage instead of requiring a translator to run/confirm it manually. Read in the CAT editor via project/document settings resolution and configured from the org's and a project's Workflow Settings forms.
Default percentage of translated segments sampled for the primary review stage when a new project or job is created. Prefills `sampleReviewPercentage` at project/job creation time and is the sampling-rate control shown in both the org-level Workflow Settings and a project's Workflow Settings form.
Default percentage of segments sampled for the secondary (customer) review stage when a new project or job is created. Behaves like `DefaultReviewSamplingSize` but applies to the secondary review workflow stage, and is set from the same org/project Workflow Settings forms.
Org-level toggle for AI-powered QA checks on document segments. Referenced in document QA issue counting and QA check result endpoints, and groups the `AiQAExcludeExactMatches` sub-setting in `settingKeysGroups`.
Org-level toggle for the AI Review workflow stage/option. Referenced by workflow-template and default-workflow UI, domain preferences, and the Verified Translation advanced options when deciding whether AI Review can be offered as a workflow stage.
Controls whether a document can be sent to review while translation is still incomplete. Read into the CAT editor's settings object (`useCATSettings`, `useDocumentCATSettings`) as `enableBlockReviewUnlessTranslationDone` and consulted by `useAllowedActions` to gate the "send to review" document action (`DocumentDropdown`).
Org-level toggle historically intended to enable a customer-review QA flow. No current front-end or server code path reads this setting outside of the on-prem default-value migration, so treat it as reserved/likely inert until a live consumer is found.
Org-level toggle that gates the ability to upload a custom QA configuration. Wired into `shared/permissions.ts` as the `requiredSetting` for the `qaConfig.upload` permission, so the permission is only granted when this setting is enabled.
Enables the "mark for review" action in the CAT/document editor, letting a translator or reviewer explicitly flag a segment as needing another look during a later review stage. Resolved per-document via the CAT settings hooks and read through the active-settings selectors; not exposed on the org settings UI.
Legacy boolean toggle (added 2023, `isUserFacing: true`) originally intended to gate MQM issue-type functionality. No live consumer was found in current client or server code — only settings migrations reference it, including `turnDeprecatedSettingsOff`, which forces it to `false` org-wide as part of a bulk cleanup of deprecated settings.
Org-level toggle intended to enable automatic, neural-model-driven review of translated segments. No current front-end or server code path reads this setting outside of the on-prem default-value migration, so treat it as reserved/likely inert until a live consumer is found.
Org-level toggle that enables PII redaction. When enabled, `shouldRedactPII` causes PII to be redacted for any user who lacks the `ExportPII` permission.
Historically gated whether a linguist/reviewer could reject a document back out of a workflow stage. Read into the CAT editor's settings object via `useDocumentCATSettings`, but `useCATSettings` currently hardcodes `enableRejectDocument: false` for every caller ("temporarily hide enableRejectDocument"), so the feature is disabled in the editor regardless of this setting's stored value. Listed in `projectSettingKeys`/`workflowOnlySettingKeys` so a project can still override the (currently inert) org default.
Enables the QA ("consistency check") view inside the Translation Memory / Termbase editor, including the "Run QA" action and the QA results sidebar. When disabled, a user viewing the QA tab is redirected back to the main termbase view.
Extends the Translation Memory / Termbase QA consistency-check to also flag grammar and spelling issues, not just term-consistency mismatches. Gates the grammar/spelling error display in the Termbase QA mismatch view (client) and selects the grammar/spelling consistency-check type on the server (`getConsistencyCheckType`).
Org-level toggle for the Verify Segments feature. When disabled, the on-prem Analyst role is filtered out of the org's available roles (`getRoles`), and document CAT settings hide the "verify segments" capability in the editor.
Requires translators/reviewers to explicitly flag segment-level errors during translation and review. Surfaced as a toggle group ("mandate error logging for the stages") in the org Settings UI and consumed by the CAT editor settings hooks to control error-flagging behavior in the editor.
Controls whether error flagging is mandatory during the secondary commercial review stage. Read into the CAT editor's settings object (`useCATSettings`, `useDocumentCATSettings`) as `mandatoryErrorFlaggingSecondaryReviewCommercial`, with document-level overrides taking precedence over org/domain defaults. Editable via the org's General Settings tab (`settingsTabs.ts`).
Org-level JSON configuration for multimedia QA checks (caption duration, reading speed/chars-per-line for word- and character-based languages, max lines), each with min/max thresholds and a blocking flag. Configured on the General Settings custom tab and consumed by the editor's document CAT settings.
Org-level JSON setting holding the list of custom AI QA check prompts an org has authored. Rendered and edited via the Custom QA Checks settings tab (`CustomQAChecksTab`), which reads and writes the `prompts: string[]` shape.
Requires a batch-level QA check to be completed for the customer review stage before a customer reviewer can finish their work on a document. Mirrors `RequireBatchQaTranslator` for the customer-review role and is configured from the org's Workflow Settings form.
Requires a batch-level QA check to be completed for the review stage before a reviewer can finish their work on a document. Mirrors `RequireBatchQaTranslator` for the review role and is configured from the org's and a project's Workflow Settings forms.
Requires a batch-level QA check to be completed for the translation stage before a translator can finish their work on a document. Read in the CAT editor via project/document settings resolution and configured from the org's and a project's Workflow Settings forms.
Org-level toggle intended to require that different linguists occupy the translator and reviewer roles on the same document/job (i.e. disallow self-review). No current front-end or server code path reads this setting outside of the on-prem default-value migration, so treat it as reserved/likely inert until a live consumer is found.
Excludes 100%/exact TM matches from the primary review sampling calculation, so exact matches are not counted toward `DefaultReviewSamplingSize`. Surfaced as the "include exact matches" toggle in the Reviewer column of the org's and a project's Workflow Settings forms; stored as an inverted setting key.
Excludes 100%/exact TM matches from the secondary (customer) review sampling calculation, mirroring `ReviewSamplingExcludeExactMatches` for the secondary review stage. Surfaced as the "include exact matches" toggle in the Secondary Reviewer column of the org's and a project's Workflow Settings forms; stored as an inverted setting key.
Controls whether comments left during a prior review stage are shown to the secondary commercial reviewer. Read into the CAT editor's settings object (`useCATSettings`, `useDocumentCATSettings`) as `showPreviousStageCommentsSecondaryReviewCommercial` and listed in `projectSettingKeys`/`workflowOnlySettingKeys` so a project can override the org default via the project's Workflow Settings form.
Org-level workflow toggle whose on-prem default is forced to `true` (ID 79). Not read anywhere in the current front client/server code, so the reviewer-skip behavior implied by its name is presumably enforced downstream (e.g. in the workflow/assignment engine) rather than in front itself.
## Editor
Controls whether TM match lookups treat differing letter case as a mismatch. Read into the CAT editor's settings object (`useCATSettings`/`useDocumentCATSettings`) to drive case-sensitive TM-match behavior, and separately consumed directly by `PretranslateSettingsService` to set the `caseSensitive` flag used when pretranslating new documents/jobs from TM. Rendered generically as part of the "Translate or CAT" settings group on the org's General Settings tab, alongside `Disable101TMMatches` and `EnableTargetCharLimit`.
Controls which MT suggestion provider is used for CAT/MT suggestions in the editor. Listed in both `editorSettingKeys` and `translateOrCatSettingKeys`, and read by the editor's `useDocumentCATSettings` hook to determine which provider's suggestions to fetch and display for a given document.
Controls copy/paste behavior in the CAT editor. The stored numeric option is mapped via `mapControlCopyAndPasteOptions` to one of `"allow" | "warn" | "block"` and passed to the `@lilt/cat` editor package as `controlCopyAndPaste`. Rendered generically as part of the "Translate or CAT" settings group on the org's General Settings tab.
Excludes 100%/exact TM matches from the CAT editor's TM-match behavior. Rendered generically as part of the "Translate or CAT" settings group (`translateOrCatSettingKeys`) on the org's General Settings tab, alongside `CaseSensitiveTMMatch` and `EnableTargetCharLimit`.
Org-level toggle intended to enable infinite-scroll pagination of segments in the CAT editor. The value is fetched into `selectCatSettings`, but no current front-end code path threads it into the `CatSettings` object built by `useCATSettings`/ `useDocumentCATSettings`, so treat it as reserved/likely inert until a live consumer is found.
Enables next-word autocomplete suggestions in the CAT editor. Read into the editor's settings object (`useCATSettings`/`useDocumentCATSettings`) as `enableNextWordSuggestions` and passed straight through to the `@lilt/cat` editor package's `CatSettings`.
Project-level toggle that surfaces prompt-labeling controls for the CAT editor: it decides whether the prompt-labeling option is shown in the project's Workflow Settings form and is passed through to project CAT settings consumed by the segment editor.
Enables enforcement of a target-segment character limit in the CAT editor. Read into the editor's settings object (`useCATSettings`/`useDocumentCATSettings`) as `enableTargetCharLimit`. Rendered generically as part of the "Translate or CAT" settings group on the org's General Settings tab, alongside `CaseSensitiveTMMatch` and `Disable101TMMatches`.
Org-level Text Specification Framework style guide, stored as a JSON object (hard line breaks, tags/placeholders, and special rules, each with an enabled flag). Surfaced in the editor via `useStyleGuide`/`useCATSettings` to drive CAT-side style checks.
## AI Providers & Models
JSON preferences blob storing the org's selected AI-review provider, added by the `add-ai-review-provider-setting` migration with a default value of `{ defaultValue: LLMProvider.NEURAL }`. Used to pick which model backs automated AI review scoring.
JSON preferences blob analogous to `GenerativeModelsPreferences` but for audio-to-text (speech-to-text) models — consumed as one of the `ServicesProps.type` variants in the AI Providers V2 services tab for managing which audio-to-text provider/model is active for the org.
Legacy per-provider toggle intended to control availability of the Amazon Textract OCR option. It is not read by the current `useImageToTextLLMOptions` hook, which always shows Amazon Textract (`isVisible: true`) and gates only on live credential configuration and the org's `ImageToTextModelsPreferences`; only data migrations reference this setting name. Appears superseded/dormant.
Legacy per-provider toggle intended to control availability of the Amazon Transcribe ASR option. It is not read by the current `useSpeechToTextLLMOptions` hook, which always shows the Amazon Transcribe option (`isVisible: true`) and gates only on live service validation/credential configuration; only data migrations reference this setting name. Appears superseded/dormant.
Legacy per-provider toggle intended to control availability of the Amazon Translate MT provider. It has no read call site in `client/` or `server/` today; only data migrations reference it (enabled by default for SaaS, forced off on-prem per `changeDefaultSettingOnPrem`). Provider availability in the current AIProvidersV2 UI is instead driven by `EnabledAIProviders` plus live credential configuration.
Legacy per-provider toggle intended to control availability of the Azure GPT-3.5 translation/generation model. It has no read call site in `client/` or `server/` today — only data migrations reference it (turned on org-wide by `turnDeprecatedSettingsOn`, forced off on-prem). Provider availability in the current AIProvidersV2 UI is instead driven by `EnabledAIProviders` plus live per-provider credential configuration, so this flag appears to be superseded/dormant rather than actively gating anything.
Gates the Azure-hosted GPT-5 option in the LILT Create / AI Hub generative model list — a separate entry from OpenAI's own GPT-5 that reuses the org's existing Azure LLM configuration (`isConfigured: true // Azure GPT-5 uses same Azure configuration`).
Legacy per-provider toggle intended to control availability of the AWS Bedrock AI21 Jurassic model. It has no read call site in `client/` or `server/` today; only data migrations reference it (forced off both by default and on-prem). Appears superseded/dormant.
Legacy per-provider toggle intended to control availability of the AWS Bedrock Claude 2 model. It has no read call site in `client/` or `server/` today; only data migrations reference it (forced off on-prem). Appears superseded/dormant.
Legacy per-provider toggle intended to control availability of the AWS Bedrock Claude 3 Sonnet model. It has no read call site in `client/` or `server/` today; only data migrations reference it (turned on org-wide by `turnDeprecatedSettingsOn`, forced off on-prem). Appears superseded/dormant.
Legacy per-provider toggle intended to control availability of the AWS Bedrock Titan model. It has no read call site in `client/` or `server/` today; only data migrations reference it (forced off on-prem). Appears superseded/dormant.
Legacy per-provider toggle intended to control availability of the AWS Bedrock Titan Text Express model. It has no read call site in `client/` or `server/` today; only data migrations reference it (turned on org-wide by `turnDeprecatedSettingsOn`, forced off on-prem). Appears superseded/dormant.
JSON object of enabled external AI providers (e.g. \{"aws": true, "google": true}).
Legacy per-provider toggle intended to control availability of the DeepL MT provider. It has no read call site in `client/` or `server/` today; only data migrations reference it (turned on org-wide by `turnDeprecatedSettingsOn`, forced off on-prem). Provider availability in the current AIProvidersV2 UI (DeepL is offered unconditionally alongside Lilt Contextual AI, Amazon, Google, and Anthropic in `useProviderList`) is instead driven by `EnabledAIProviders` plus live credential configuration.
Legacy per-provider toggle intended to control availability of the Google Cloud ASR option. Not read by the current `useSpeechToTextLLMOptions` hook (Google Cloud ASR visibility there is unconditional, gated only by live service validation/credential configuration); only data migrations reference this setting name. Appears superseded/dormant.
Legacy per-provider toggle intended to control availability of the Google Cloud Vision OCR option. Not read by the current `useImageToTextLLMOptions` hook (Google Cloud Vision visibility there is unconditional, gated only by live credential configuration); only data migrations reference this setting name. Appears superseded/dormant.
Legacy per-provider toggle intended to control availability of the Google PaLM 2 generative model. It has no read call site in `client/` or `server/` today; only data migrations reference it. Appears superseded/dormant, likely predating removal of PaLM 2 from the model lineup entirely.
Legacy per-provider toggle intended to control availability of the Google Translate MT provider. It has no read call site in `client/` or `server/` today; only data migrations reference it (enabled org-wide by `turnDeprecatedSettingsOn`, forced off on-prem). Provider availability in the current AIProvidersV2 UI is instead driven by `EnabledAIProviders` plus live credential configuration.
Setting key seemingly intended to gate availability of the Google Translate v3 API as a distinct provider/model option. Unlike its siblings in this group, it has zero references anywhere else in the repository — not even in a data migration — so it cannot currently affect any behavior.
Setting key seemingly intended to gate a migration path from the legacy Google Translate API to v3 (e.g. for switching existing orgs over without changing their selected provider). Like `EnableGoogleTranslateV3`, it has zero references anywhere else in the repository — not even in a data migration — so it cannot currently affect any behavior.
Shows the "Lilt-hosted Nvidia" translation provider as a selectable option in MT provider pickers (`useProviderList`/`useLLMOptions` on the Contextual AI / target-language provider forms, and the AIProvidersV2 Services tab), in addition to the always-available Lilt Contextual AI, Amazon, DeepL, Google, and Anthropic options. No org-settings-ui form exposes it directly; it's flipped via data migration/admin-cli, and is forced off by default on-prem.
Legacy per-provider toggle intended to control availability of a LLaMa 2 translation/generation model. It has no read call site in `client/` or `server/` today; only data migrations reference it (turned on org-wide by `turnDeprecatedSettingsOn`, forced off on-prem). Appears superseded/dormant.
Org-level toggle historically intended to gate a dedicated LLM Configuration Settings UI/flow. No current front-end or server code path reads this setting outside of the on-prem default-value migrations, so treat it as reserved/likely inert until a live consumer is found.
Org-level toggle to enable the Model Context Protocol (MCP) integration.
Org-level toggle historically intended to enable OCR (Optical Character Recognition) functionality. No current front-end or server code path reads this setting outside of the on-prem default-value migrations (OCR triggering elsewhere in the codebase is instead driven by `EnableUniversalFileUploadEnterprise`), so treat it as reserved/likely inert until a live consumer is found.
Gates the OpenAI GPT-3.5 option in the LILT Create / AI Hub generative model list (`useGenerativeLLMOptions`'s `createOpenAIModel` helper sets `isVisible` from this setting). Added by the `add-lilt-create-provider-settings` migration and defaulted off for on-prem deployments (`changeDefaultSettingOnPrem`); also force-disabled org-wide by the `turnDeprecatedSettingsOn`/`changeDefaultValuesOfDeprecatedSettings` migration sweeps alongside the other older OpenAI models.
Gates the OpenAI GPT-4 option in the LILT Create / AI Hub generative model list. Also read directly (outside the AI Hub list) as a general "is OpenAI configured/enabled" check in several unrelated call sites — `useLLMOptions`, `useAIProvidersLLMOptions`, and the target-language provider list (`useProvidersList`) all gate OpenAI-provider visibility on this single flag rather than a dedicated one.
Gates the OpenAI GPT-4 Turbo option in the LILT Create / AI Hub generative model list, alongside the plain GPT-4 and GPT-3.5 options. Added by the same `add-lilt-create-provider-settings` migration and defaulted off on-prem.
Gates the OpenAI GPT-4o option in the LILT Create / AI Hub generative model list. Added later than the other GPT-4 variants (dedicated `add-enable-gpt4o-setting` migration) and defaulted off for on-prem.
Gates the OpenAI GPT-5 option (`createOpenAIModel` with high speed, high cost, high quality) in the LILT Create / AI Hub generative model list.
Gates the OpenAI GPT-5 Mini option (high speed, medium cost, high quality) in the LILT Create / AI Hub generative model list.
Gates the OpenAI GPT-5 Nano option (high speed, low cost, medium quality) in the LILT Create / AI Hub generative model list.
Controls visibility of the OpenAI Whisper ASR option (both the on-prem "Lilt-hosted" variant and the SaaS Azure-backed variant) in the AIHub speech-to-text provider list (`useSpeechToTextLLMOptions`), independent of the Amazon Transcribe and Google Cloud ASR options which are always shown. Combined with live per-provider credential configuration to determine whether the option is actually usable.
Setting originally added (`add-enable-tesseract-provider`, `isUserFacing: false`) to gate the Tesseract/"Lilt Contextual AI" OCR option. The current `useImageToTextLLMOptions` hook no longer reads it directly — Tesseract's visibility there is driven purely by `isOnPrem` — though a companion spec still mocks this setting, suggesting the read was refactored away without updating the test. Only data migrations (turned on org-wide by `turnDeprecatedSettingsOn`, forced on for on-prem defaults) still reference it live.
JSON blob of preferences (style guide overrides, preferred LLM provider) for LILT Create generated content, matching the `GeneratedContentPreferences` shape consumed as `GeneratedContentTemplateParams.preferences`. Not user-facing (`isUserFacing: false`); its migration deletes rows from OrganizationSettings, ProjectSettings, and UserSettings alike, indicating it can be stored at multiple scopes rather than only the org level.
Selects which generative model/service backs LILT Create's content generation (`useGeneratedContentService`), consumed by `useSupportedLanguages` to determine supported languages for the selected model. Editable via the org's General Settings tab (`GeneralSettings.tsx`, `SettingsTabs/custom`) and kept current by migrations that flip its value across Gemini model versions.
JSON preferences blob holding the org's per-model enable/disable state and defaults for generative (LLM) models — `useGenerativeLLMOptions` reads `preferences.value.enabledModels` to decide which configured model each provider row should show as enabled, and it's the primary settingName threaded through the AI Providers V2 services tab (`ServiceCard`, `useAIProviders`, `useBedrockServices`) for saving updates to generative model selection.
JSON preferences blob analogous to `GenerativeModelsPreferences` but for image-to-text (OCR) models — read by `useImageToTextLLMOptions` and the job-creation OCR provider picker (`useOCRProvider`) to determine the org's configured OCR provider/model.
JSON preferences blob analogous to `GenerativeModelsPreferences` but for translation (MT) models — used across job creation (`ModelSelector`, `JobForm`, `useFillPromptLangPairs`) to determine which translation model/provider is enabled and available for a given org.
Org-level toggle historically intended to gate visibility of Contextual AI / LLM-related UI. No current front-end or server code path reads this specific setting outside of the on-prem default-value migrations (the large set of Contextual-AI-branded containers found in the codebase are not gated by this key), so treat it as reserved/likely inert until a live consumer is found.
Shows the External Models tab under Organization Settings, letting admins toggle which external AI providers are available.
## Authentication & Security
Org-level toggle that allows WSO2-backed OIDC login for an organization. Checked in `addMember` when the org's authentication type is `EMBEDDED_OIDC`, to decide whether WSO2 login is permitted for newly added members.
Org-level numeric override (in minutes) for how long a user's login session stays valid. Read by `getSessionCookieTimeout`/ `setSessionCookieTimeout`, cached per-user for 4 hours; a value of 0 (or unset) means no custom timeout is applied.
## Connectors
String setting (default `""`) added by the `add-allowedConnectors-SettingKeyNames` migration to restrict which connectors an org is allowed to use. No live reader was found in current client or server code beyond the migration that created it — it appears to be an unused/dormant setting today.
Org-level toggle for the auto-delivery feature. When enabled, jobs whose documents are all marked done are automatically delivered (subject to post-processing — if PP is still active, delivery waits until PP completes). When disabled (default), automatic delivery is blocked unconditionally and a PM must click Deliver manually. The DB key name retains "Blocking" for back-compat with existing org settings rows; do not rely on the name to infer the runtime behavior. Manual (PM-initiated) delivery is always allowed regardless of this setting.
Org-level toggle intended to enable the Connectors Builder feature. No current front-end or server code path reads this setting outside of the on-prem default-value migration, so treat it as reserved/likely inert until a live consumer is found.
Org-level toggle to allow manual submissions for connectors flows. When enabled, users can select content from a connector and submit it manually.
Org-level toggle for the Connectors nav entry: gates the "Connectors" link/card on the homepage and manage-home navigation (`NavigationCards`/`ManageHomepage`, via `useHasSetting`).
## Analytics
Customer identifier embedded into the Looker Studio embed URL for the AnalyticsV2 Custom Analytics tab (`AnalyticsV2/CustomAnalytics`).
Enables the per-model breakdown view in the Analytics "AI Accuracy" tab, letting users see AI accuracy metrics broken out by individual model rather than only in aggregate.
Switches the Analytics page over to the AnalyticsV2 experience (`AnalyticsPage`/`DataAnalytics/index.tsx`), which otherwise falls back to the legacy `DataAnalytics` view. Set to `true` as part of new organizations' default settings (`setDefaultOrgSettings`).
Shows the Custom Analytics tab inside AnalyticsV2 (`AnalyticsV2/index.tsx`), which embeds a customer-specific Looker Studio report via `CustomAnalyticsKey`.
Org-level toggle that gates access to financial data in Analytics reports — when disabled, `useReports` treats the org as having no financial data and hides financial figures from report views.
Shows the Financials tab inside AnalyticsV2 (`AnalyticsV2/index.tsx`), exposing financial reporting alongside the Overview, AI Accuracy, and Quality tabs.
Switches an organization's Analytics dashboards (Overview and Quality tabs) from the legacy "average errors per word" quality metric to the LQA (Language Quality Assessment) score, swapping in the average quality score widget in place of the average errors/words widget. Not exposed on the org settings UI; toggled per organization by Lilt staff.
Org-level toggle historically intended to gate access to the Linguist Stats "OPM" (operations-per-minute) productivity report under Insights. No current front-end or server code path reads this specific setting to gate that report outside of the on-prem default-value migrations, so treat it as reserved/likely inert until a live consumer is found.
Org-level toggle that automatically links Salesforce opportunities to projects. Non-user-facing; only referenced by its creation migration and the on-prem default-settings migration — no live application reader was found beyond that.
Org-level target gross margin percentage (0-100) associated with Human+AI Optimized workflow jobs. Defaults to 80; validated as a 0-100 percentage but not yet read by any front-end or server code path in this repo — likely feeds a downstream pricing/margin-reporting consumer.
Org-level target gross margin percentage (0-100) associated with Verified-translation jobs. Defaults to 70; validated as a 0-100 percentage but not yet read by any front-end or server code path in this repo — likely feeds a downstream pricing/margin-reporting consumer.
Customer identifier embedded into the Looker Studio embed URL for the legacy Program Insights report (`Homepage/ProgramInsights`, `DataAnalytics/ProgramInsights`), used to parameterize the report to the current organization.
Gates the "by user" drill-down modals (Quality by User, AI Accuracy by User) inside AnalyticsV2 (read via `useHasUsageAnalyticsEnabled`/ `useHasSetting`, and directly in `AnalyticsV2/index.tsx`) so only orgs with this flag can open per-user breakdowns from chart clicks. Not user-editable; enabled per-org via a series of one-off data migrations (`create-enableUsageAnalytics-org-setting`, later migrations flipping the default to `true`).
Gates visibility of the "Insights" nav link in the app header and access to the embedded Volume & Leverage insights report/route. When disabled, users are redirected away from the report page. Not exposed on the org settings UI; toggled per organization by Lilt staff.
Org-level toggle intended as a secondary/variant flag alongside `ViewEmbeddedAppInsights` for embedded app insights access. No current front-end or server code path reads this setting outside of the on-prem default-value migration, so treat it as reserved/likely inert until a live consumer is found.
Org-level toggle historically intended to gate access to the Linguist Stats report under Insights. No current front-end or server code path reads this specific setting outside of the on-prem default-value migrations — visibility of that report area is instead governed by the separate `Permissions.LinguistStatsRead` role-permission system — so treat it as reserved/likely inert until a live consumer is found.
Org-level toggle historically intended to gate access to the Program Insights homepage/analytics widget. No current front-end or server code path reads this specific setting outside of the on-prem default-value migrations, so treat it as reserved/likely inert until a live consumer is found.
Org-level toggle historically intended to gate access to the Projects Stats report under Insights/Analytics. No current front-end or server code path reads this specific setting outside of the on-prem default-value migrations, so treat it as reserved/likely inert until a live consumer is found.
## Users & Assignment
Org-level flag whose name implies gating availability of the Linguist Qualities feature for the account. Not read anywhere in the current front client/server code — the related `selectIsLinguistQualitiesEnabled` selector is role-based only and does not consult this setting — so its enforcement point (if still active) is presumably outside this repo.
Org-level toggle that allows automatic assignment (AA) to be triggered immediately when a job transitions to "Ready to Start", rather than waiting for the next scheduled AA run. Read by the client's `autoAssignmentTrigger` utility.
Org-level toggle historically intended to enable automatic assignment of work to linguists. The underlying setting key was deleted outright by a later migration (`remove-enable-auto-assign-setting`) and no current front-end or server code path reads it, so treat it as reserved/removed.
Org-level toggle allowing domains (not just individual users) to be assigned as the customer reviewer on projects/jobs. Read by `useEnableCustomerReviewerDomainAssignment` to gate the relevant assignment UI in job creation and account/member forms.
Org-level toggle for the Domains feature. Gates access-control and UI surfaces (e.g. the Domains admin page, model/memory domain scoping, domain-based job access checks) that let an org partition users, memories, and models by domain.
Org-level toggle for the Experts feature. When enabled, an "Experts" tab is surfaced in Manage Users (for users with the TeamsWrite permission) and in the account profile page, exposing expert-role management UI that is otherwise hidden.
Org-level toggle historically intended to enable a redesigned linguist homepage/landing page. No current front-end or server code path reads this setting outside of the on-prem default-value migrations, so treat it as reserved/likely inert until a live consumer is found.
Requires a user to have their full name set on their account profile. Read by the `MandatoryAccountInformationModal`, which forces the user to fill in their full name (via a blocking modal) after login when this is enabled and the field is still unset.
Free-text/HTML instructions template configured per job and shown to linguists on the job's instructions page/form (`client/reactApp/containers/Jobs/Detail/Settings/JobInstructions`), fetched via `getJobInstructions`/`getInstructionsImpl` which read it from the job's own settings scope (distinct from the org-level `OrganizationInstructionsEmailTemplate` and the project-level `ProjectInstructionsEmailTemplate`, all three of which are surfaced together on the instructions view). Saved via `saveJobInstructions`.
Org-level toggle that restricts automatic assignment (AA) so that only onboarded users are eligible candidates; users who have not completed onboarding are excluded from AA candidate pools. Surfaced in the org's Assignment settings card alongside `AutoTriggerAssignment`.
Controls whether a user's Linguist Availability preferences are exposed on their Account Profile page. Read via `useLinguistPreferencesEnabled`, which requires both this setting and the (role-based) Linguist Qualities eligibility check to be true before showing the preferences UI (`AccountProfileForm`).
Free-text/HTML instructions template configured at the organization level and shown to linguists on job/project instruction pages (`ProjectInstructions`, `getJobInstructions`). Distinct from the per-project `ProjectInstructionsEmailTemplate`; both are rendered together on the instructions view. Editable via `SettingEmailTemplate` and listed in `assignmentSettingKeys` for the org's Assignment settings tab.
Org-level boolean flag (`isUserFacing: true` at creation) whose name implies gating on completed linguist/organization training. Not read anywhere in the current front client/server code, so its enforcement point (if still active) is presumably outside this repo.
Free-text/HTML instructions template configured per project and shown to linguists alongside the org-level `OrganizationInstructionsEmailTemplate` on job/project instruction pages (`ProjectInstructions`, `getJobInstructions`). Read/written through the project-scoped settings service (not an org default with override — this setting only exists at the project level) and editable via the project's Workflow Settings form (`SettingEmailTemplate`).
Requires a user to have their timezone set on their account profile. Read by the `MandatoryAccountInformationModal`, which forces the user to select a timezone (via a blocking modal) after login when this is enabled and the field is still unset.
Numeric cap intended to separately limit how many users with `create.write` permissions (e.g. Manager-type roles) an org can add, distinct from the overall `UserLimit`. Added alongside `UserLimit` by the `add-user-and-create-limits` migration and still exercised by `addMember.spec.ts` (which shows Administrator-role adds as exempt from it), but the current `addMember.ts` implementation only reads `UserLimit` — no production code path was found constructing a `getSettingKeyInfo(UserCreateLimit)` lookup, suggesting the check was refactored away without the test being updated.
Per-user JSON preferences for the Domains feature (currently just a `defaultDomainId`), edited from the Account Profile page and used to pre-select the user's default domain in domain-scoped UI.
Per-user preferred UI/content language, stored as a string setting (default `"en-US"`) on the user's account. Read/written from the Account Profile page and used when rendering the user's own settings.
Numeric cap on the total number of active (non-`@lilt.com`) members an org may have. Enforced in `addMember`'s controller: the invite is rejected once the non-Lilt-employee member count reaches this value, unless the value is negative, which is treated as unlimited seats (`hasInfinitelyManySeats`).
## Misc
Org-level setting listing which Enterprise Agent tools (translate, termbase, create, analyze) are available to the org's AI Assistant. Edited via a multi-select dropdown in the General Settings tab (`AvailableAgentTools` custom setting).
Selects which page (per `HomepageOptions`, e.g. `PLATFORM`) a role's members land on after login. Read client-side via the `useDefaultHomepage` hook (falling back to `HomepageOptions.PLATFORM` when unset) and exposed on `MemberRole.homepage` via the organization GraphQL mapper; settable per role through `organizationRoleOperations.ts`.
Org-level toggle that switches the app's default landing page to the Enterprise Agent homepage. Read by the navigation sidebar and the Homepage container to decide which home experience to render.
Org-level toggle that enables the AI Assistant. When enabled (and combined with the `enableAIAssistant` feature toggle), it surfaces the AI Assistant entry point in the navigation sidebar.
Org-level toggle historically intended to enable selection between generated-content services (introduced alongside the `enableLiltCreate` setting). No current front-end or server code path reads this setting outside of the on-prem default-value migration, so treat it as reserved/likely inert until a live consumer is found.
Org-level toggle historically intended to enable a dedicated Home Page experience. No current front-end or server code path reads this setting outside of the on-prem default-value migration, so treat it as reserved/likely inert until a live consumer is found.
Legacy org-level toggle historically intended to control visibility of an organization settings view. It no longer appears in any production route or component — the remaining references are on-prem default-value migrations and settings-framework unit tests that use it as a generic example setting key.
Org-level toggle historically intended to enable a platform-wide UI redesign. No current front-end or server code path reads this setting outside of the on-prem default-value migrations, so treat it as reserved/likely inert until a live consumer is found.
Org-level toggle historically intended to gate visibility of a project settings view/page. No current front-end or server code path reads this setting outside of the on-prem default-value migrations, so treat it as reserved/likely inert until a live consumer is found.
Org-level toggle historically intended to enable a split/restructured organization settings page. No current front-end or server code path reads this setting outside of the on-prem default-value migration, so treat it as reserved/likely inert until a live consumer is found.
Selects which navigation layout (e.g. the legacy default vs. the newer "platform" layout) a role's members see, per `NavigationLayoutModes`. Exposed on `MemberRole.navigationLayout` via the organization GraphQL mapper (`roleSettingStringValue`) alongside `DefaultHomepage`, and can be set per role (e.g. `set-navigationLayoutMode-agency-translator` migration).
Allows users on unsupported/incompatible browsers to access the platform instead of being blocked.
# 2025 LILT February Patch Release Notes
Source: https://support.lilt.com/kb/february-2025-patch-release-notes
## Bug Fixes and Improvements
1. **V3 Model retraining:**
1. Improved efficiency of V3 retraining, now requiring less data input from users.
2. **New V3 Languages:**
1. This release includes the addition of new language pairs for Somali and Tajik:\
\- EN:SO\
\- EN:TJ
3. **Improved performance:**
1. We've improved the performance of translations appearing in LILT Translate allowing for users to complete translations quicker.
4. **Domains Enhancements:**
1. Starting this release, Custom Roles will now also work with Domains
## Upcoming changes
Starting with the next release, we will be changing the LILT product versioning.
# Figma
Source: https://support.lilt.com/kb/figma
LILT + [Figma](https://www.figma.com/) plugin enables companies to select one or many Figma frames to send to LILT for seamless localization. At a high-level, LILT's Figma plugin handles:
* **Submission via Figma**: Select one or many Figma frames to send to LILT for localization.
* **Translation Method**: At submission, the user can select between one of two workflows:
1. **Instant Translate**: The user can request Figma frames to be immediately localized into any language using LILT's Contextual AI.
2. [**Verified Translation**](/kb/what-is-lilt): Send Figma frames to LILT's in-house translators for localization.
* **Deliver to Figma**: LILT to deliver localized frames to Figma, creating one page per target language.
Check out the video below to see the LILT + Figma connector in action.
## Configuration
1. Install the LILT plugin from the [Figma Community](https://www.figma.com/community):
* In Figma, navigate to `Plugins` > `Browse plugins in Community`.
![]()
* Search for `LILT` and select `Install`.
2. Configure the LILT Figma plugin:
* In Figma, launch the LILT plugin and navigate to `Settings`.
* Enter the following information:
* **LILT Token:**
![]()
* Click `Save settings` to conclude the configuration process.
## Workflow
Once the plugin is configured, content can be sent between LILT and Figma as outlined in the sections below.
### Project creation
1\. Navigate to the Figma page containing the content you want to localize.
2\. Launch the LILT Figma plugin from the menu bar by selecting `Plugins` > `LILT Figma Plugin`.
3\. Select one or many Figma frames or layers that you want to localize. \*\*By default, if no frames or layers are selected, the LILT plugin will localize the entire page.\*\**Starting August 22nd,you will be able to view all orders associated with your Figma file. Any Pages in the left hand column of your Figma file, will automatically appear in the Orders form in your LILT plugin for you to be able to choose for translation.*
4\. In the LILT Figma plugin, select the desired Translation method:
* **Instant translation:** To immediately localize the selected content using LILT's Contextual AI, ensure that `Instant translation` is selected in the `Translate` tab.
* **Verified translation:** To send the selected content to LILT's in-house translators for localization, ensure that `Verified translation` is selected in the `Translate` tab.
![]()
6\. In the LILT Figma plugin, specify the `Source language` and one or more `Target language(s)`.
7\. In the LILT Figma plugin, click `Translate selected` to send the selected content to LILT for localization.
### Project completion
The status of the translation job can be tracked in the `Status` section of the LILT plugin, with new translation jobs will show as the first results.
Once the content for a job has been translated (either through instant AI translation or by LILT's in-house translators), the job's status will change from `In Progress` to `Complete`. To import the translated content:
1. Navigate to the Figma page that was used to create the translation job.
2. On the `Status` tab, click `import` to update the Figma page with the localized content.
## LILT Figma plugin limitations
* Layers containing multiple typefaces cannot be localized.
* The `Status` tab only displays the status of the latest 30 projects created through Figma.
* When translated text is delivered from LILT to Figma, Figma uses the source font to display the translated text. The source font may not support all characters in the target language, in which case, the delivered content will not accurately reflect the translated content. To fix this, simply change the page font to a font that fully supports the target language. This can be done either before or after the localized content is imported into Figma.
# Budget Tracking
Source: https://support.lilt.com/kb/financial-reports
Budget tracking allows enterprises to keep tabs on the spend of completed projects and to project future spend. With Budget Tracking, you can:
* **Streamline workflow management** - Reducing workflow management overhead while setting teams up for success.
* **Enhance clarity & accountability** - Minimize risk of missed tasks and enhanced team collaboration
* **Control data access by domain** - Oversee, control, and restrict access to information, models, and data sets per user
The data in Budget Tracking is refreshed at the end of the month or on a bi-monthly basis, depending on the billing contract with the customer. Budget Tracking data is displayed in the currency of a customer’s LILT contract. If you have multiple currencies on your contract, LILT has selected the primary currency for this data, and we do not do any currency conversion.
Archived jobs are displayed in Budget Tracking, which differs from the rest of Analytics. If an archived job is appearing on this tab that shouldn’t be, please reach out to your LILT point of contact and make sure the job is marked as “Do not bill”.
If you have any questions about the data in Budget Tracking, please reach out to your LILT representative.
![]()
**Reserved capacity** - The committed spend amount of service-related SKUs, which exclude any software or connector costs, if included in your contract. At the end of the defined period, you will be billed for the remaining amount if the total wasn’t reached. The dates displayed are associated with your contract.
**Detailed financial report** - This is a downloadable monthly financial report to help track your localization spending and stay on top of your financials. The report is available in Excel format, and is available on a monthly basis. Please contact your LILT representative with any questions regarding access.
**Invoiced amount** - Invoiced amount is the final amount per completed project, language pair, or total within the filtered time frame.
* **Online services** - The invoiced amount for online services for jobs and projects that are marked as done.
* **Offline services** - The invoiced amount for offline services, such as Desktop Processing (DTP).
## Filters
Within Budget Tracking, you can filter your data by:
* Job status - Pre-processing, Ready to Start, In progress, Done
* Date - Range selector, up to 12 months
* Due date
* Domains. *Note: If you are viewing as part of a domain, you will only see data for the jobs created within your domain.*
Filters default to the previous six months of data, and only apply to the data beneath the filter (i.e. the three boxes above the filters are static data). Budget tracking data is only available for the last 12 months.
# Find & Replace
Source: https://support.lilt.com/kb/find-replace
The Find and Replace sidebar tool in [LILT Translate](/kb/introduction-to-lilt-translate) allows linguists to quickly locate phrases in the source text and target text of documents in a Project. Once located, these phrases can be replaced as desired. This is a useful tool for maintaining consistency across a Project.
Click the magnifying glass icon on the sidebar to open the Find and Replace tool, or use hotkeys to open directly into **Find mode**(Mac: `⌘`+ `F`; Windows: `Ctrl` + `F`) or \*\*Replace mode \*\*(Mac: `⌘`+ `H`; Windows: `Ctrl` + `H`).
![]()
## Find
To find a word or phrase in a document or Project:
1. Type at least one character in the search field.
2. Select any optional parameters for the search:
* **Whole words:** If enabled, LILT only searches for whole word matches. If not enabled, LILT searches for partial word matches.
* **Case-sensitive:** If enabled, LILT only searches for matches with matching case. If not enabled, case differences are ignored.
* **Search across an entire Project:** If enabled, LILT searches through all the Project's documents that you have access to. If not enabled, LILT searches only in the current document.
3. Click the `Find` button to display a list of search results, including a count of how many results were found for each document searched.
![]()
Click the `All`, `Source`, or `Target` buttons to filter which result types are displayed.
Within each result, the search term is highlighted. Click a search result to bring the segment into focus in the editor.
When searching an entire Project, segment results are grouped by document. This is especially useful to make sure you only replace phrases within the desired documents.
![]()
## Replace
To replace text, make sure the `Replace with` field is visible. The `Replace with` field can be toggled by clicking the dropdown button next to the `Search word or phrase` field.
![]()
Once you have clicked the `Find` button to search for text, type text into the `Replace with` field to preview the replacement text in all the matching segments.
![]()
Click the `Replace all` button to replace the phrase across the entire document or Project, or click any of the `Replace target` buttons next to a segment to replace the phrase in only that segment.
***Please note: Making changes to confirmed or accepted segments will unconfirm/unaccept the segments where the changes were made. In these cases, you must re-confirm/re-accept in order for the changes to be added to the memory.***
# Generate Evaluation Metrics (WPA, BLEU)
Source: https://support.lilt.com/kb/generate-evaluation-metrics-wpa-bleu
## Word Prediction Accuracy (WPA)
Use below method to calculate the WPA metrics at LILT.
### Enable WPA writes
WPA is enabled by default to write data to minIO/s3. However, if you have release prior to the Q2 2024 release and would like to enable, add below configs in the custom `values.yaml` and redeploy app
```bash theme={null}
updatev4:
onpremValues:
config:
# Configure WPA DataStore
wpaDataStoreType: "csv"
# Write updates for every 10 confirmed segments, change this as required
wpaDataStoreBatchSize: 10
# Path to store WPA results, change it as required
wpaDataStoreBasePath: "s3://lilt/wpa/"
```
```bash theme={null}
cd ~/install_dir
./install-lilt.sh
```
### Read WPA stats
Use these steps to read the WPA stats generated using above method:
1. Fetch update-neural pod using
```bash theme={null}
kubectl get pods -n lilt | grep update-neural
```
2. Use below command to fetch the stats
```bash theme={null}
kubectl -n lilt exec -- bash scripts/metrics/visualize_wpa.py --datastore csv --base-path s3://lilt/wpa --start_date --end_date --memory_id
```
*Parameters:*
* `--datastore` (required): csv
* `--base-path`: Location to store the results. Should be similar to the value of `wpaDataStoreBasePath` values file parameter. It’s possible to use the local pod folders as base path by referring it as `file://`
* `--src_lang`: Only results for this source language will be used. Each language is given as a 2 letter code according to ISO 639-1, e.g., de for german. More details [here](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes).
* `--tgt_lang` - Only results for this target language will be used. The format is the same as `--src_lang`
*Sample output*
```bash theme={null}
Backend v4
Number of segments: 10
Average prediction accuracy unadapted model: 81.4%
Average prediction accuracy adapted model: 82.6%
Difference: 1.2%
Average char prediction accuracy unadapted model: 77.0%
Average char prediction accuracy adapted model: 79.9%
Char difference: 2.9%
```
* **Unadapted model %**: Percentage of words/ char correctly predicted by the system when using an unadapted/pre-training model.
* **Adapted model %**: Percentage of words/ char correctly predicted by the system when using an adapted/trained model.
## BLEU score
Take a look at [Wikipedia’s](https://en.wikipedia.org/wiki/BLEU) description of the BLEU algorithm.
BLEU score can be useful for determining the performance of your LILT Data Sources in terms of:
* Which Data Sources perform best.
* Which Data Sources are best suited for a given translation project.
### Preparing the evaluation set
If you would like to calculate the BLEU score on your sample evaluation dataset then use below method to prepare the evaluation set:
Select one or more reference documents as your evaluation set. Each sentence in your evaluation set must have at least one human reference translation. Preferably, each sentence has multiple reference translations to increase the robustness of the BLEU metric.
Documents in the evaluation set:
* must have high-quality human reference translations
* must not have been uploaded to or translated with LILT, or any competing engines you are evaluating against
* must have sentences in source and target language as we need to translate the source using LILT for comparison
* should be representative of the type of text you usually translate
* should contain 1000 – 3000 sentences, as too small evaluation sets lead to unreliable metrics
* sentence size: longer reference sentences can potentially make it more challenging for machine translations to achieve high BLEU scores, as the machine translation may not match the reference sentence exactly in terms of word order or structure. On the other hand, shorter reference sentences may make it easier for machine translations to achieve higher scores.\**It's important not to sacrifice diversity and naturalness for the sake of higher scores*.\*In summary, there isn't a universally "good" reference sentence size, but it's essential to prioritize naturalness, diversity, and relevance to the evaluation goals. Using multiple reference sentences and considering variations in translation quality is generally a good practice. Ultimately, the choice of reference sentences should align with the specific context and objectives of the machine translation evaluation.
### Running the evaluation test
This section will provide instructions on how to capture BLEU score by running the batch updater and inference on the segments present in the Segments table. In summary, this section will describe steps to download the segments, split them into train and test sets, and run inference evaluation. The code will be provided as a docker image.
1. Load the inference docker file
```bash theme={null}
Docker:
docker load -i on_prem_inference_docker.tar
Containerd:
ctr image import on_prem_inference_ctr.tar
```
2. Preparing config and data directories: In a desired directory (henceforth referred to as `/path/to/root/directory`), create 2 directories as below
```bash theme={null}
mkdir configs && mkdir data
```
3. Download segments from the database
1. Connect to database using `kubectl` proxy or preferred method of your choice
```bash theme={null}
kubectl port-forward -n lilt service/mysql 3306:3306
```
2. Create a config with below values
```bash theme={null}
db-connection:
# DB username
user: "DB_USER_NAME"
# DB password
password: "DB_PASS_WORD"
user-data:
# Don't change data-output-path
data-output-path: "/home/lilt/external_data/db_segments"
# Replace with source and target language ISO code
language-pair: ["SRC_LANG", "TGT_LANG"]
# Memory ID for above lang-pair
memory-ids: []
# Don't change data-type
data-type: "segments"
```
3. Copy above config to this path: `/path/to/root/directory/configs/download_user_data.yaml`
4. Use below docker command to download the segments
```bash theme={null}
docker:
docker run \
--volume /path/to/root/directory/configs/:/home/lilt/external_configs \
--volume /path/to/root/directory/data/:/home/lilt/external_data \
--network="host" \
on-prem-inference:1 \
bash -c "cd /home/lilt; source py_env/bin/activate; bash src/download_segments_data.py -c /home/lilt/external_configs/download_user_data.yaml;"
Containerd:
sudo ctr run -t --net-host \
--mount type=bind,src=/path/to/root/directory/configs/,dst=/home/lilt/external_configs,options=rbind:rw \
--mount type=bind,src=/path/to/root/directory/data,dst=/home/lilt/external_data,options=rbind:rw \
--rm docker.io/library/on-prem-inference:ubuntu on-prem-inference-ubuntu \
/bin/bash -c "cd /home/lilt; source py_env/bin/activate; bash src/download_segments_data.py -c /home/lilt/external_configs/download_user_data.yaml;"
```
The output of this should be the below files
```bash theme={null}
$ ls /path/to/root/directory/data/db_segments
meta_data.json segments.SRC_LANG segments.TGT_LANG
```
`Meta_data.json` contains the # of segments\
`segments.SRC/TGT_LANG` contains the source and target segments
4. Split segments data into train and test sets
```bash theme={null}
docker:
docker run \
--volume /path/to/root/directory/configs/:/home/lilt/external_conf--volume /path/to/root/directory/data/:/home/lilt/external_data \
--network="host" \
on-prem-inference:1 \
bash -c "cd /home/lilt; source py_env/bin/activate; bash src/train_test_split.py -i /home/lilt/external_data/db_segments -o /home/lilt/external_data/splits -s SRC_LANG -t TGT_LANG -p TRAIN_SPLIT_PROPORTION;"
Containerd:
sudo ctr run -t --net-host \
--mount type=bind,src=/path/to/root/directory/configs/,dst=/home/lilt/external_configs,options=rbind:rw \
--mount type=bind,src=/path/to/root/directory/data,dst=/home/lilt/external_data,options=rbind:rw \
--rm docker.io/library/on-prem-inference:ubuntu on-prem-inference-ubuntu \
/bin/bash -c "cd /home/lilt; source py_env/bin/activate; bash src/train_test_split.py -i /home/lilt/external_data/db_segments -o /home/lilt/external_data/splits -s SRC_LANG -t TGT_LANG -p TRAIN_SPLIT_PROPORTION;"
```
Here `TRAIN_SPLIT_PROPORTION` is a floating point number between 0 and 1 to indicate how much of the downloaded segments need to be used for training. Eg, if set to 0.7, then 70% of the segments downloaded into `/path/to/root/directory/data/db_segments` will be used for train and the remaining 30% will be used for test. For the provided sample within `sample_data/db_segments` using a `TRAIN_SPLIT_PROPORTION` of 0.7 will yield 7 train segments and 3 test segments as provided within `sample_data/db_segments/splits/{train,test}`
5. Run inference evaluation
1. Prepare the config to run inference evaluation
```bash theme={null}
languages:
# Source language ISO code
src-lang: "en"
# Target language ISO code
tgt-lang: "es"
db-connection:
# DB username
user: "DB_USER_NAME"
# DB password
password: "DB_PASS_WORD"
inference:
# Don't change
model-owners: [ "lilt_api" ]
# Tasks to perform
operations: [ "batch-updater", "translate" ]
# Don't change
metrics: [ "bleu" ]
# TOKENIZER: use `zh` for target languages `zh` and `zt`,
# `ja-mecab` for target language `ja`
# `ko-mecab` for target language `ko`
# `13a` for everything else
sacrebleu-tokenizer: "TOKENIZER"
# Source directory for batch updates
batch-updater-source: "train"
# Set to false to overwrite the existing results
ignore-operation-if-output-present: true
lilt_api:
# Lilt API key
api-key: "API_KEY"
# API endpoint, for eg. https://test.lilt.com/2
api-endpoint: "API_ENDPOINT"
# Uncomment to reuse existing memory/ project id
# memory-id:
# project-id:
```
2. Run below docker command
```bash theme={null}
docker:
docker run \
--volume /path/to/root/directory/configs/:/home/lilt/external_configs \
--volume /path/to/root/directory/data/:/home/lilt/external_data \
--network="host" \
on-prem-inference:1 \
bash -c "cd /home/lilt; source py_env/bin/activate; bash src/run_inference.py -c /home/lilt/external_configs/inference_evaluation.yaml -i /home/lilt/external_data/splits -m /home/lilt/external_data/evaluation.json"
Containerd:
sudo ctr run -t --net-host \
--mount type=bind,src=/path/to/root/directory/configs/,dst=/home/lilt/external_configs,options=rbind:rw \
--mount type=bind,src=/path/to/root/directory/data,dst=/home/lilt/external_data,options=rbind:rw \
--rm docker.io/library/on-prem-inference:ubuntu on-prem-inference-ubuntu \
/bin/bash -c "cd /home/lilt; source py_env/bin/activate; bash src/run_inference.py -c /home/lilt/external_configs/inference_evaluation.yaml -i /home/lilt/external_data/splits -m /home/lilt/external_data/evaluation.json"
```
This command first creates a fresh memory and project to be used for the purpose of this evaluation. Their respective ids are printed in the logs as below
```bash theme={null}
INFO:root:Using Memory Id: 1234
INFO:root:Using Project Id: 5678
```
If these memory and project ids need to be reused, then the evaluation config needs to be updated with these
```bash theme={null}
lilt_api:
memory-id: 1234
project-id: 5678
```
Once the memory and project are created/reused, the data present within `/path/to/root/directory/data/splits/train` will be used to run a batch updater operation, and once completed, the data present within `/path/to/root/directory/data/splits/test` will be used to run batch translate operation on the recently updated memory. The results will be downloaded and the computed bleu scores will be persisted in `/path/to/root/directory/data/evaluation.lilt_api.json`
*Sample output*
```bash theme={null}
INFO:root:Seeding meta_data.json files for data sources in /home/lilt/external_data/splits
INFO:root:Validating test
INFO:root:Validating train
INFO:root:Running Lilt API inference
INFO:root:engine URL: mysql://root:***@127.0.0.1:3306/lilt_dev?charset=utf8mb4
Handling connection for 3306
INFO:root:connection established:
INFO:root:Using Memory Id: 10
INFO:root:Using Project Id: 10
INFO:root:Generating a TMX file from the data present in train
INFO:root:Uploading /home/lilt/external_data/splits/train/train.tmx to memory 10 and running batch updater
Handling connection for 3306
INFO:root:Successfully uploaded /home/lilt/external_data/splits/train/train.tmx. Waiting till batch updater completes
INFO:root:Pretranslating document at path /home/lilt/external_data/splits/test/test.de
INFO:root:Creating a temp file /tmp/tmp3u_rqp_p/test.de.test.txt compatible with API usage
INFO:root:Requested pretranslation for document test.de.test.txt with id 12
INFO:root:Waiting for pretranslation on document test to complete
INFO:root:Downloading pretranslated document for test into /home/lilt/external_data/translations_out/lilt_api_10_10/test/translated.en
INFO:root:Computing BLEU scores
INFO:root:Metrics for lilt_api:
{
"bleu": {
"lilt_api_10_10": {
"test": [
79.98082588232835,
"90.7/82.5/76.5/71.4"
]
}
}
}
INFO:root:Saving metrics json in path: /home/lilt/external_data/evaluation.lilt_api.json
```
The inference will be run on the directories present within the `splits` directory, except for the ones which aren't mentioned to be used for batch updater. If the `inference` section in the config is updated to `operations: [ "translate" ]`, then `train` directory won't be used for batch updater anymore and inference will be run on that too. To prevent this, `train` directory can be deleted from the `splits` directory so the inference is run only on `test`.
# GitHub
Source: https://support.lilt.com/kb/github
LILT + [GitHub](https://github.com/) connector enables companies to automatically push and pull content between GitHub and LILT. This saves you time by providing seamless localization while letting you continue to work in the systems you know.
* **Submission via GitHub**: Creating or updating content in GitHub automatically creates a Job in LILT containing the source content that needs to be translated.
* **Translation Method**: During configuration, the user can specify the desired workflow:
1. **Instant Translate**: GitHub content is immediately localized into any desired language using LILT's Contextual AI.
2. [**Verified Translation**](/kb/what-is-lilt): Send GitHub content to LILT's in-house translators for localization.
* **Deliver to GitHub**: When a LILT Job is finished, the localized content is automatically delivered to GitHub.
## Configuration
During the process of onboarding a new client, LILT will help identify whether the GitHub integration can be used. If it can be used, LILT will set up the GitHub integration for the client.
## Workflow
Once the connector is configured, content is automatically moved between LILT and GitHub as outlined in the sections below.
### Project creation
LILT periodically checks for new content on GitHub. When new content is detected, LILT Projects are automatically created for the content to be translated.
### Project completion
LILT periodically checks for completed LILT Projects. Completed Project content is automatically pushed back to GitHub into the folders specified during configuration.
## Limitations
LILT does not continuously check for new content; it only periodically checks for new content and completed Projects. The frequency that LILT checks for content is determined when the connector is set up.
## **Pull Request (PR-only) workflow**
The PR-only workflow is an optional GitHub connector mode designed for teams that manage content changes through pull requests. Instead of translating from a single fixed branch, the connector detects eligible pull requests and translates the content from each PR’s source branch, so translations can be reviewed and merged alongside the code/content changes.\
\
**How it works**
1. Find matching pull requests (Import)
1. On import, the connector uses the GitHub API to look for pull requests that match your configured criteria (for example: PR labels, PR title, and/or approval status). Pull requests must all be from the same primary branch listed in the LILT Connectors admin page.
2. If one or more PRs match, the connector selects the source branch for each PR.
2. Extract and submit content for translation (Import)
1. The connector clones the repository, checks out the PR’s source branch, and extracts files using your configured include/exclude patterns.
2. The extracted content is then submitted to Lilt for translation.
3. Notify contributors in GitHub
1. The connector adds a label and/or comment on the pull request to indicate that content has been imported for translation (or to indicate there was no translatable content).
4. Return translations to the same PR branch (Export)
1. When translations are ready, the connector downloads the translated files and pushes them back to the same PR source branch, so the PR includes the translated updates before it’s merged.
# GitLab
Source: https://support.lilt.com/kb/gitlab
LILT + [GitLab](https://gitlab.com/) connector enables companies to automatically push and pull content between GitLab and LILT. This saves you time by providing seamless localization while letting you continue to work in the systems you know.
## Configuration
During the process of onboarding a new client, LILT will help identify whether the GitLab integration can be used. If it can be used, LILT will set up the GitLab integration for the client.
## Workflow
Once the connector is configured, content is automatically moved between LILT and GitLab as outlined in the sections below.
### Project creation
LILT periodically checks for new content on GitLab. When new content is detected, LILT Projects are automatically created for the content to be translated.
### Project completion
LILT periodically checks for completed LILT Projects. Completed Project content is automatically pushed back to GitLab into the folders specified during configuration.
## Limitations
LILT does not continuously check for new content; it only periodically checks for new content and completed Projects. The frequency that LILT checks for content is determined when the connector is set up.
# Google Configuration
Source: https://support.lilt.com/kb/google-configuration
### Background:
The first step when helping a customer set-up GCP credentials is to ask their IT department if they have:
* Service account keys with Cloud translation API Admin, Storage admin, and Storage object admin permissions
* Bucket with Location =US-Central1, and Storage class = standard class.
If the customer does not have a service account or bucket with that information. Someone from their IT department will have to do the following:
## Access:
Configuring the Google Configuration in AI Hub, will enable the customer to access all available services via the Google Cloud ecosystem, including:
* Google PaLM2
* Google Gemini
* Google Cloud ASR
* Google Cloud Image to Text
### Create a Service Account and get Keys
* Type Service accounts into search bar and select “Service accounts IAM & Admin”
* Click “Create service account”
* Give name, click “Create and Continue”
* Grant service account with the correct permissions:
* Cloud translation API admin
* Storage admin
* Storage object admin
![]()
* If setting up OCR and ASR
* (If setting up OCR also include “Cloud Vision AI Service Agent”)
* (If setting up ASR also include “Cloud Speech-to-text Service Agent”)
* Grant users access to this service account
* Leave all fields empty
*
![]()
* Click Done
* Create the key
* Search for the service account created in previous step, select the service account
* It should say “No keys”, which means we have to generate keys
*
![]()
* Click “Keys”
* Click “Add Key”
* Please note that you cannot regenerate a key so you need to store the key once it is created.
* Select JSON and click “Create”
*
![]()
* This JSON key can be imported into [LILT](https://lilt.com/app/manage/llms)
![]()
### Creating a bucket
The customer can use whatever bucket they want as long as the bucket is Location =US-Central1 and Storage class = standard class. If the customer does not have a bucket that meets these criteria, follow the steps below:
* Bucket
* Search Buckets and select “Buckets”
*
![]()
* Create a bucket
* Name the bucket
* Select region US-Central1
*
![]()
* Storage Class for Data = Standard
*
![]()
* Choose how to control access to objects
* LILT can work with either choice, customer should choose whichever is best for their systems.
*
![]()
* Choose how to protect object data
* LILT can work with either choice, customer should choose whichever is best for their systems.
*
![]()
* Click Create, choose confirm
* Input the bucket name into LILT
*
![]()
* In the example above you would paste “example-bucket-lilt” into LILT credentials
# Google Drive Connector
Source: https://support.lilt.com/kb/google-drive
Connect your Google Drive to LILT for seamless translation and localization workflows
## Overview
The Google Drive connector enables you to sync and manage translation files between your Google Drive and LILT platform. This connector provides automated translation workflows for your Google Drive content, making it easy to collaborate on multilingual projects within your existing Google Workspace environment.
## Setup
### Prerequisites
Before setting up the Google Drive connector, ensure you have:
* A Google Workspace account with admin privileges
* Access to Google Cloud Console for creating service accounts
* A Google Drive Shared Drive (Team Drive) for file organization
* Files in supported formats (see [supported file types](/kb/supported-file-formats))
There are two ways to configure the Google Drive connector: Automatic Authentication (Recommended) or Manual Authentication.
## **Automatic Authentication via Translate Page (Option 1 - Recommended)**
The easiest and recommended way to connect your Google Drive to Lilt is directly through the Translate page. This method allows you to authenticate and access your Google Drive files in just a few clicks, without needing to navigate to separate settings or configuration pages.
### **Benefits**
This authentication method provides a streamlined experience that integrates directly into your translation workflow. Once connected, you can browse and select files from Google Drive just as easily as selecting files from your local computer. Your authentication persists across sessions, so you only need to grant permissions once.
### **How to Connect**
Follow these steps to connect your Google Drive account:
1. **Navigate to the Translate page** in Lilt.
2. Locate the **Upload** button and click the dropdown arrow to expand the menu.
3. Select **Add from Google Drive** from the dropdown options.
4. A Google authorization window will appear. Sign in to your Google account (if not already signed in) and grant Lilt permission to access your Google Drive files.
5. Once permissions are granted, you will be able to browse your Google Drive folders and select files for translation.
### **After Authentication**
Once you have successfully authenticated, Google Drive will appear as a source option whenever you upload content for translation. You can navigate through your Drive folders, preview files, and select multiple items for translation—all within the familiar Lilt interface. The experience mirrors selecting files from your local file system, making it easy to incorporate cloud-based content into your translation workflows.
\*\*Note: \*\*Your Google Drive connection remains active until you explicitly revoke access. If you need to disconnect your Google Drive or switch to a different Google account, you can manage your connected accounts in your Lilt Connect page.
## Automatic Authentication (Option 2)
A second method is to use LILT's Connect interface to authenticate. This method allows a user with the appropriate permissions to authorize the connection directly by logging in with their Google credentials.
1. **Navigate to the Connectors page in LILT** and select the Google Drive connector.
2. **Click "Sign in with Google Drive"** to initiate the Google OAuth 2.0 flow.
3. **Authorize Access**: A Google sign-in window will appear. Log in with a Google account that has **Content Manager** access to the Shared Drive you want to connect. It is highly recommended to use a generic service account rather than an individual user's account to avoid issues if the user leaves the company.
4. **Grant Permissions**: Grant LILT the necessary permissions to access your Google Drive.
5. **Automatic Credential Population**: Once authorized, the required authentication fields will be automatically populated.
6. **Complete Configuration**: Fill in the remaining `google_drive_team_drive_id` and `rclone_backend_path` fields as described in the manual setup instructions below.
7. **Validate and Save**: Click **Validate** to test the connection and then save the connector.
**Important Notes:**
* The user account used for authentication must have "Content Manager" permissions for the target Shared Drive.
## Manual Authentication (Option 3)
This method requires you to manually create and configure a Google Cloud Project and service account to generate the necessary credentials.
#### Required Configuration Parameters
##### Authentication
Your Google API Client ID from the Google Cloud Console
Your Google API Client Secret from the Google Cloud Console
OAuth 2.0 refresh token for ongoing access to your Google Drive
##### Drive Configuration
The full folder path from the root of the Shared Drive (e.g., `Customer Folder/Production/Lilt`)
A list of glob patterns. Any files matching one of the patterns will be downloaded. Required — without at least one pattern, no files will be imported.
A map from glob patterns to template strings controlling where exported files are delivered, e.g. `delivery/{trglang}/{parent}/{stem}.{suffix}`. This is inherited from the base file-system connector and is required on every rclone-based connector.
The Team Drive ID where your translation files are stored. Optional, but typically needed when connecting to a Shared Drive rather than My Drive.
The folder path for exported translated files. If not specified, files are exported to the same location as import
#### Manual Setup Instructions
##### Step 1: Create Google Cloud Project
1. Go to the [Google Cloud Console](https://console.cloud.google.com/)
2. Create a new project or select an existing one
3. Enable the Google Drive API for your project
4. Navigate to **APIs & Services** → **Credentials**
##### Step 2: Create OAuth 2.0 Credentials
1. Click **Create Credentials** → **OAuth 2.0 Client ID**
2. Configure the consent screen if prompted
3. Select **Web application** as the application type
4. Add authorized redirect URIs:
* `https://developers.google.com/oauthplayground`
* Any other URIs you need for testing
5. Save the credentials and note down:
* **Client ID**
* **Client Secret**
##### Step 3: Create Service Account
1. In the Google Cloud Console, go to **IAM & Admin** → **Service Accounts**
2. Click **Create Service Account**
3. Fill in the service account details
4. Grant the service account **Content Manager** permissions
5. Create and download a JSON key file (optional for advanced setups)
##### Step 4: Generate Refresh Token
1. Visit the [OAuth 2.0 Playground](https://developers.google.com/oauthplayground)
2. Click the settings gear icon and check **Use your own OAuth credentials**
3. Enter your Client ID and Client Secret
4. In the left panel, select **Drive API v3** and choose:
* `https://www.googleapis.com/auth/drive`
5. Click **Authorize APIs** and complete the OAuth flow
6. Click **Exchange authorization code for tokens**
7. Copy the **Refresh Token** for your connector configuration
##### Step 5: Set Up Shared Drive
1. Create a new Shared Drive in Google Drive or use an existing one
2. Share the Shared Drive with your service account email
3. Grant the service account **Content Manager** permissions
4. Create the folder structure you want LILT to use
5. Copy the Team Drive ID from the URL when viewing the Shared Drive
##### Step 6: Configure the Connector
1. In LILT, navigate to **Connectors** → **New Connector**
2. Select **Google Drive** from the connector list
3. Fill in the configuration parameters:
* **Client ID**: From Step 2
* **Client Secret**: From Step 2
* **Refresh Token**: From Step 4
* **Team Drive ID**: From Step 5
* **Folder Path**: Full path from Shared Drive root
##### Step 7: Test the Connection
1. Click **Validate** to test your configuration
2. The connector will verify:
* Authentication credentials
* Drive access permissions
* Folder path validity
## Optional Configuration Parameters
### Content Filtering
List of glob patterns to exclude specific files (e.g., `["**/temp/*", "**/*.tmp"]`)
### Google Drive-Specific
Comma-separated list of file formats to convert back into native Google formats on upload (e.g. `docx`), so translated files round-trip as native Google Docs/Sheets/Slides instead of staying in the exported format. See the [rclone docs](https://rclone.org/drive/#import-export-of-google-documents).
Operate on the "Shared with me" folder instead of My Drive.
Use the created date instead of the modified date when checking for changes.
Used with the `--drive-impersonate` flag to access a specific user's folder.
## Advanced Configuration
### File Filtering
Control which files are processed:
```yaml theme={null}
# Include only specific document types
rclone_includes:
- "**/*.docx"
- "**/*.xlsx"
- "**/*.json"
- "**/*.xml"
# Exclude temporary and system files
rclone_excludes:
- "**/temp/*"
- "**/.DS_Store"
- "**/~$*"
- "**/*.tmp"
```
### Folder Organization
Organize your content with clear folder structure:
```
Team Drive Root/
├── Customer Folder/
│ ├── Production/
│ │ ├── Lilt/
│ │ │ ├── Source/
│ │ │ └── Translated/
│ │ └── Archive/
│ └── Review/
└── Templates/
```
## Best Practices
### File Organization
* Use a consistent folder structure in your Shared Drive
* Create separate folders for source and translated files
* Use descriptive folder names that include project or language information
* Implement an archive system for completed projects
### Security
* Use service accounts with minimal required permissions
* Regularly review and rotate OAuth credentials
* Enable two-factor authentication on Google accounts
* Monitor access logs through Google Admin Console
### Performance
* Use include/exclude patterns to limit file scanning scope
* Organize files in logical folder structures to improve sync performance
* Consider file size limits when working with large documents
* Use Google Drive's version control features for tracking changes
### Collaboration
* Set up proper sharing permissions for team members
* Use Google Drive's commenting and suggestion features for review workflows
* Implement naming conventions for files at different stages of translation
* Consider using Google Drive's approval workflows for quality control
## Troubleshooting
### Authentication Issues
**Error**: "Invalid credentials"
* **Solution**: Verify your Client ID and Client Secret are correct
* **Solution**: Ensure the OAuth consent screen is configured properly
* **Solution**: Check that the Google Drive API is enabled in your project
**Error**: "Refresh token expired"
* **Solution**: Generate a new refresh token using the OAuth Playground
* **Solution**: Ensure the refresh token was copied completely without truncation
* **- Solution**: Check that the OAuth application has the correct scopes
### Drive Access Issues
**Error**: "Drive not found"
* **Solution**: Verify the Team Drive ID is correct
* **Solution**: Ensure the service account has been granted access to the Shared Drive
* **Solution**: Check that the Shared Drive hasn't been deleted or moved
**Error**: "Insufficient permissions"
* **Solution**: Grant the service account Content Manager permissions
* **Solution**: Verify the service account email is shared with the correct Shared Drive
* **Solution**: Check that the account has access to the specific folders in the path
### File Processing Issues
**Error**: "Folder path not found"
* **Solution**: Verify the folder path exists and is spelled correctly
* **Solution**: Ensure the path is relative to the Shared Drive root
* **Solution**: Check that folders in the path haven't been moved or deleted
**Issue**: Files not being imported
* **Solution**: Check your include/exclude patterns are not too restrictive
* **Solution**: Verify file formats are supported by LILT
* **Solution**: Ensure files are not corrupted or empty
### Performance Issues
**Issue**: Slow synchronization
* **Solution**: Use more specific include patterns to reduce scanning scope
* **Solution**: Organize files in smaller, focused folders
* **Solution**: Check Google Drive API quota limits and usage
**Issue**: Large file processing problems
* **Solution**: Consider file size limits for your content type
* **Solution**: Break large files into smaller, manageable chunks
* **Solution**: Monitor Google Drive storage limits and usage
## FAQ
**Q: Can I use a personal Google account instead of Google Workspace?** A: While technically possible, Google Workspace is recommended for better security, admin controls, and Shared Drive features.
**Q: What's the difference between a regular folder and a Shared Drive?** A: Shared Drives provide better collaboration features, centralized ownership, and are recommended for team-based translation workflows.
**Q: How do I find my Team Drive ID?** A: The Team Drive ID is visible in the URL when you're viewing the Shared Drive. It's the long string after `/folders/` in the URL.
**Q: Can I connect multiple Google Drives?** A: Yes, you can set up multiple connectors for different Shared Drives or use different folder paths within the same Shared Drive.
**Q: What file formats are supported?** A: The connector supports all file formats that LILT can process. See the [supported formats guide](/kb/supported-file-formats) for details.
**Q: How often does the connector sync?** A: The sync frequency depends on your connector schedule configuration and can be set to run at regular intervals or triggered manually.
**Q: Can I use this with native Google Docs/Sheets/Slides format?** A: Yes. Set `google_drive_import_formats` to a comma-separated list of the formats you want converted back into native Google formats on upload (e.g. `docx` so translated files are re-imported as native Google Docs rather than left as `.docx`). See the [rclone docs](https://rclone.org/drive/#import-export-of-google-documents) for the supported format list. You don't need to manually export to DOCX first — native Google files are read and, if configured, re-created as native files after translation.
**Q: What happens if someone moves a file while it's being processed?** A: The connector may encounter errors if files are moved during processing. It's recommended to establish file handling procedures to avoid conflicts.
# GPU Profiles And Values Overlays
Source: https://support.lilt.com/kb/gpu-profiles-and-values-overlays
LILT ships alternative GPU allocations and identity-provider configurations as files you copy into an overlay directory. Nothing is edited in place, so your choices survive an upgrade.
## The Overlay Directory
`install-lilt-charts.sh` applies every `*.yaml` file under `lilt/environments//values.d/` on top of the base values file and the environment overlay. `ENV_NAME` defaults to `lilt`, so the directory is usually `lilt/environments/lilt/values.d/`.
```bash theme={null}
mkdir -p lilt/environments/lilt/values.d
cp lilt/gpu-profiles/gemma-single-large.yaml lilt/environments/lilt/values.d/
```
The directory is yours. The installer reads it and never writes to it or prunes it, so one copy holds until you undo it. Delete the file to return to the default.
This is the supported way to change values the installer ships. Editing `lilt/values.yaml` or `lilt/eks-values.yaml` directly produces the same result at deploy time, but you then have to remember to reapply the edit on every upgrade.
Files are applied in alphabetical order, and a later layer replaces an earlier one. Two files that set the same top-level key conflict silently: the alphabetically last one wins and the other is discarded with no warning. Keep at most one profile per service.
Helm replaces list values wholesale rather than merging them, so a profile's `nodeSelectorTerms` supersede the default entirely rather than adding to it.
Files that set different top-level keys compose safely. A GPU profile and an SSO profile can sit in the directory together.
## GPU Profiles
The base values file ships one GPU allocation per service, sized for the smallest hardware that service supports. On larger cards the same model needs fewer of them, and the surplus is not free: the device plugin assigns GPUs exclusively, so a card reserved by a pod that never uses it cannot be used by anything else.
The profiles in `lilt/gpu-profiles/` are alternative allocations for hardware that allows a different one. They are optional. Installing nothing keeps the defaults, which work on every card the service supports.
### Read Your Cards First
A profile is matched against the VRAM the driver reports, which is lower than the size the card is sold as. An L4 sold as 24 GB reports 23034 MiB.
```bash theme={null}
kubectl get nodes -L nvidia.com/gpu.memory,nvidia.com/gpu.product
```
These labels come from GPU Feature Discovery, which the NVIDIA GPU Operator provides. They are a hard requirement of any GPU install, not something a profile introduces. If the labels are absent, GPU pods stay `Pending` because no node satisfies their affinity.
### Choosing a Profile
Pick the smallest card count your hardware allows.
| Service | Configuration | Cards | Memory floor | Compute capability | Sized for |
| ---------------------- | ------------------------- | ----- | ------------------ | ------------------ | ------------------------------------ |
| `gemma-vllm-inference` | on-premises default | 2 | 22000 MiB | 8.9 | L4 (23034 MiB) |
| `gemma-vllm-inference` | EKS default | 1 | 43400 MiB | 8.9 | L40S (46068 MiB) |
| `gemma-vllm-inference` | `gemma-dual-medium.yaml` | 2 | 22000 to 43399 MiB | 8.9 | L4 |
| `gemma-vllm-inference` | `gemma-single-large.yaml` | 1 | 43400 MiB | 8.9 | L40, L40S, H100, H200 |
| `llama-vllm-inference` | default | 4 | 15000 MiB | 7.5 | T4 (15360 MiB) and larger |
| `llama-vllm-inference` | `llama-dual-medium.yaml` | 2 | 30000 to 57999 MiB | 7.5 | RTX 5000 Ada, A100 40GB, L40S, A6000 |
| `llama-vllm-inference` | `llama-single-large.yaml` | 1 | 58000 MiB | 7.5 | A100 80GB, H100, H200 |
The two defaults differ because the hardware does. An on-premises cluster typically has several smaller cards, so the default takes two of them. An AWS GPU node carries one large card, so the EKS default takes one and raises the floor high enough that the card can hold the whole model.
Every gemma configuration requires compute capability 8.9 or higher, on both flavors. Gemma is FP8-quantised and native FP8 support starts with the Ada generation, so every Ampere card is excluded, including the 80 GB A100. This is a separate condition from the memory floor: a card with plenty of VRAM and an older architecture still does not qualify.
The memory floors are exclusive comparisons in the values files. A floor written as `43399` admits cards reporting 43400 MiB or more. The numbers in the preceding table are the values that actually qualify.
### When to Use Each Profile
**`gemma-dual-medium.yaml`** — your cards are the 24 GB class and gemma stays `Pending` because no single card clears the EKS default's floor. Two cards together hold what one cannot. The profile is bounded above, so it will not also match a larger card and reserve two where one would do.
**`gemma-single-large.yaml`** — your cards are 48 GB or larger and the on-premises default is reserving two where one suffices.
**`llama-dual-medium.yaml`** — your nodes have fewer than four cards, so the default never schedules. Here the profile is what makes llama runnable, not what makes it faster.
**`llama-single-large.yaml`** — your cards are 80 GB or larger.
`llama-vllm-inference` ships disabled on both flavors, as it is being retired in favour of Gemma. A llama profile only takes effect on a cluster that has turned it back on.
### Why a Profile Is a File
Each profile changes two fields that are only correct together: the GPU count Kubernetes reserves, and the memory floor in the node affinity that decides which cards are eligible.
Changing one without the other fails, and the two failures look nothing alike. A count lowered without raising the floor still schedules, then the pod lands on cards too small for the model and dies during startup with a VRAM error. A floor raised without lowering the count never schedules at all, and the pod sits `Pending` forever.
Kubernetes cannot make this choice for you. The GPU count is a resource request, fixed when Helm renders the manifest, and the scheduler needs that number to pick a node, so it cannot depend on which node was picked. Keeping both fields in one file is what makes them impossible to apply by halves.
### Services Without a Profile
`llm-inference-whisper`, `batch-worker-gpuv4`, and `translatev4` carry GPU floors of their own but ship no profile. To change their allocation you edit the base values file, or write your own overlay file setting the same two fields.
## Single Sign-On Profiles
LILT ships with external SSO disabled, so password sign-in works out of the box and no install points at an identity provider you do not control.
The files in `lilt/sso-profiles/` are complete configurations for one provider each. Apply one the same way:
```bash theme={null}
cp lilt/sso-profiles/.yaml lilt/environments/lilt/values.d/
```
Then set the client secret, which no profile carries, as the `singleOidcClientSecret` key of the `lilt-secrets` secret. Add it to the environment's `secrets.yaml`, or provision it through External Secrets Operator.
The `panva-sandbox.yaml` profile targets a public sandbox provider with a shared test client. Anyone can authenticate as anyone. Use it to check that the SSO path works end to end, never on a customer install.
### Writing a Profile for Your Own Provider
A profile sets all eight values on three services: `front`, `av-scan`, and `auth-service`. Each reads its own copy of the same block, so a profile covering only one of them leaves the other two disabled.
| Value | Set it to |
| --------------------------------------------------- | -------------------------------------- |
| `SINGLE_OIDC_PROVIDER_ENABLED` | `true` |
| `SINGLE_OIDC_PROVIDER_CLIENT_ID` | The client ID your provider issued |
| `SINGLE_OIDC_PROVIDER_ID_TOKEN_SIGNED_RESPONSE_ALG` | The signing algorithm, usually `RS256` |
| `SINGLE_OIDC_PROVIDER_ISSUER_NAME` | The issuer name or URL |
| `SINGLE_OIDC_PROVIDER_ISSUER_AUTH_ENDPOINT` | The authorization endpoint |
| `SINGLE_OIDC_PROVIDER_ISSUER_TOKEN_ENDPOINT` | The token endpoint |
| `SINGLE_OIDC_PROVIDER_ISSUER_USERINFO_ENDPOINT` | The userinfo endpoint |
| `SINGLE_OIDC_PROVIDER_ISSUER_JWKS_URI` | The JWKS URI |
Set all of them together. `front` validates the block when the provider is enabled and exits on the first empty field, so a partial profile crashes the pod at startup rather than falling back to no SSO.
To customise TLS for the calls LILT makes to your provider, populate the `single-oidc-provider-tls-options` secret and set the matching `SINGLE_OIDC_PROVIDER_TLS_OPTIONS_PATH_TO_*` values.
## Apply a Profile
Copying a file changes nothing on its own. Re-run the installer:
```bash theme={null}
sh install-lilt.sh # on-premises
sh install-lilt-eks.sh # EKS
```
Confirm the layer was picked up. The installer prints a line for each file it applies:
```
Applying extra values layer: lilt/environments/lilt/values.d/gemma-single-large.yaml
```
Then check that the pods scheduled:
```bash theme={null}
kubectl get pods -n lilt -l app=gemma-vllm-inference
kubectl describe pod -n lilt | grep -A5 'Events'
```
A pod stuck in `Pending` with `didn't match Pod's node affinity` means no card in the cluster clears the profile's floor. Compare the profile you chose against the `nvidia.com/gpu.memory` labels on your nodes.
## Related Articles
* [Install System (AWS EKS)](/kb/install-system-aws-eks)
* [Self-managed hardware requirements](/kb/self-managed-hardware-requirements)
* [Single sign-on (SSO)](/kb/single-sign-on-sso)
# Helpshift
Source: https://support.lilt.com/kb/helpshift
### LILT + Helpshift Connector
The LILT + Helpshift connector enables support teams to automate the translation process for customer chat messages within Helpshift. This integration simplifies the localization of support interactions, ensuring that customer support is seamless and linguistically inclusive, no matter the customer's language.
#### Submission via Helpshift
Creating or updating a chat message in Helpshift automatically sends the content to LILT for translation, allowing real-time interactions with customers in their native languages.
#### Translation Method
Users can select between two types of translation workflows for messages:
* **Instant Translate:** Messages are instantly translated using LILT's AI, facilitating immediate communication with customers.
* **Verified Translation:** For sensitive or complex inquiries, messages can be sent to LILT’s professional translators for high-quality, human-reviewed translation.
#### Delivery to Helpshift
Once a translation job is completed in LILT, the translated content is automatically pushed back into Helpshift, ready to be used in ongoing customer interactions. This ensures that support teams can continue conversations without interruption, maintaining context and quality in customer support.
#### Configuration
Onboarding new clients includes a configuration phase where the suitability and specifics of the Helpshift integration are determined. LILT assists in setting up the Helpshift connector according to the client's requirements.
#### Workflow
* **Project Creation:** LILT automatically detects new content in Helpshift needing translation and creates translation projects.
* **Project Completion:** LILT checks for completed translation projects and pushes the translated content back to Helpshift in its original format.
#### Limitations
The system does not continuously monitor for new content; it checks periodically based on a pre-set schedule established during the setup of the connector.
### Key Benefits
* **Speed and Efficiency:** Instant Translate allows for real-time communication, essential for maintaining customer satisfaction and engagement.
* **Quality Assurance:** Verified Translation ensures that complex or sensitive communications are accurately translated by professional linguists.
* **Seamless Integration:** The connector works natively with Helpshift, allowing customer support teams to operate within a familiar system without the need to switch between platforms.
This integration empowers organizations to provide superior and inclusive customer support, bridging language barriers effortlessly and efficiently.
# Hotkeys
Source: https://support.lilt.com/kb/hotkeys
[LILT Translate](/kb/introduction-to-lilt-translate) is designed with a range of keyboard shortcuts that enable linguists to operate the editor entirely from the keyboard. Mastering these hotkeys will help linguists save time when processing documents.
Hotkeys work across all languages. However, some hotkeys may not always be available for a given document. For example:
* If the language pair doesn't have Contextual AI support, LILT does not generate suggestions, meaning the autocompletion hotkeys will not be available.
* If the document does not have any tags, the tag hotkeys will not be available.
Options that are unavailable are grayed out in the [header toolbar](/kb/introduction-to-lilt-translate).
⭐ = most important hotkeys to know
## Text operations
| | **Action** | **Mac hotkey** | **Windows hotkey** |
| - | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ---------------------- |
| ⭐ | Insert highlighted phrase suggestion | `Return` | `Enter` |
| | Select next phrase suggestion | `Shift`+`Tab` | `Shift`+`Tab` |
| ⭐ | Insert full suggestion | `Shift`+`Return` | `Shift`+`Enter` |
| | Toggle case of selected target text | `Shift`+`F3` | `Shift`+`F3` |
| | Insert non-breaking space | `⌘`+`Shift`+`Space` | `Ctrl`+`Shift`+`Space` |
| | Insert line break | `Option`+`Enter` | `Alt`+`Enter` |
| | Copy source to target | `⌘`+`I` | `Ctrl`+`I` |
| | Insert [right to left marker](/kb/bi-directional-text-marks) | `⌘`+`K` | `Ctrl`+`K` |
| | Insert [left to right marker](/kb/bi-directional-text-marks) | `⌘`+`L` | `Ctrl`+`L` |
| | Undo last change | `⌘`+`Z` | `Ctrl`+`Z` |
| | Insert top TM entry from the CAT sidebar into the segment editor*Note: If no TM entries exist for the segment, then this shortcut will insert the AI suggestion.* | `⌘`+`Shift`+`S` | `Ctrl`+`Shift`+`S` |
## Text navigation
| | **Action** | **Mac hotkey** | **Windows hotkey** |
| - | ---------------------------------- | ------------------------ | ---------------------- |
| | Move cursor one character forward | `Right` | `Right` |
| | Move cursor one character backward | `Left` | `Left` |
| | Move cursor one word forward | `Option`+`Right` | `Ctrl`+`Right` |
| | Move cursor one word backward | `Option`+`Left` | `Ctrl`+`Left` |
| | Select character forward | `Shift`+`Right` | `Shift`+`Right` |
| | Select character backward | `Shift`+`Left` | `Shift`+`Left` |
| | Select word forward | `Option`+`Shift`+`Right` | `Ctrl`+`Shift`+`Right` |
| | Select word backward | `Option`+`Shift`+`Left` | `Ctrl`+`Shift`+`Left` |
## Segment actions
| | **Action** | **Mac hotkey** | **Windows hotkey** |
| - | --------------------------------------------- | ------------------- | ------------------- |
| ⭐ | Confirm/unconfirm segment | `⌘`+`Return` | `Ctrl`+`Enter` |
| | Go to next unconfirmed/unaccepted segment | `⌘`+`Down` | `Ctrl`+`Down` |
| | Go to previous unconfirmed/unaccepted segment | `⌘`+`Up` | `Ctrl`+`Up` |
| | Go to next segment | `⌘`+`Option`+`Down` | `Ctrl`+`Alt`+`Down` |
| | Go to previous segment | `⌘`+`Option`+`Up` | `Ctrl`+`Alt`+`Up` |
| | Open [comments](/kb/segment-comments) | `Ctrl`+`Shift`+`M` | `Ctrl`+`Alt`+`M` |
## Tags
| | **Action** | **Mac hotkey** | **Windows hotkey** |
| - | ---------------------------------------------------------------------------------------- | ---------------- | ------------------ |
| | Select next tag1 | `⌘`+`]` | `Ctrl`+`]` |
| | Select previous tag2 | `⌘`+`[` | `Ctrl`+`[` |
| | Select matching tag (in a tag pair) | `Option`+`Shift` | `Alt`+`Shift` |
| | Move selected tag one word left (if character-based language, moves 5 characters left) | `M` or `H` | `M` or `H` |
| | Move selected tag one character left | `,` or `J` | `,` or `J` |
| | Move selected tag one character right | `.` or `K` | `.` or `K` |
| | Move selected tag one word right (if character-based language, moves 5 characters right) | `/` or `L` | `/` or `L` |
*German keyboard hotkeys:*
* *1Select next tag: *`Ctrl`*+*`Alt`*+*`9`
* *2Select previous tag:*`Ctrl`*+*`Alt`*+*`8`
## Tools
| | **Action** | **Mac hotkey** | **Windows hotkey** |
| - | --------------------------------------------------- | ---------------- | ------------------ |
| | Open Concordance | `⌘`+`Option`+`C` | `Ctrl`+`Alt`+`C` |
| | Open find & replace | `⌘`+`H` | `Ctrl`+`H` |
| | Open form to [Add New Terminology](/kb/terminology) | `Option`+`A` | `Alt`+`A` |
| | Toggle preview mode | `Ctrl`+`⌘`+`P` | `Ctrl`+`Shift`+`P` |
| | Close TM diff view | `Esc` | `Esc` |
## Quality assurance
| | **Action** | **Mac hotkey** | **Windows hotkey** |
| - | --------------------------------- | -------------- | ------------------ |
| | Run FullQA Check | `F7` | `F7` |
| | Run Quality Assurance Tools Check | `F9` | `F9` |
# Leverage Reports
Source: https://support.lilt.com/kb/how-to-read-leverage-reports
LILT Leverage Reports provide information on how much your Data Sources can be leveraged for a given Project, helping project managers estimate time and budget needs. This article covers generating, reading, and utilizing Leverage Reports to make the most of the LILT platform.
## Viewing leverage reports
Project managers can access the Leverage Reports page from the Project view by clicking on the `Leverage Report` button under `Reports`.
![]()
When documents are imported into LILT a leverage report will be automatically generated. The word counts will remain static based on the Data Source at the time of importing, unless the recalculation button is used (see below).
## Reading and making use of Leverage Reports
Leverage reports are broken down into two sections: Project Leverage and Document Leverage. Each of these is discussed in the sections below.
### Project Leverage
The Project Leverage section provides you with a combined overview of all Project documents.
![]()
Table rows:
* **Segment Count:** Information on all segments within a Project.
* **Words Count:** Information on all words within a Project.
The table columns provide information on percent matches to the TM:
* **101:** Exact match with previous segment and next segment also matching.
* **100:** Exact match.
* **95-99:** Very close match (maybe punctuation is different).
* **85-94:** Very similar match (maybe one word is different).
* **75-84:** Similar, but not super close (maybe the source is talking about disliking the color red and the similar match is something talking about liking purple).
* **New:** Completely new segment that doesn't have a close match in the TM.
* **Repetitions:** Number of repeated segments/words in the source text.
* **Source:** Number of segments/words in the source text.
Project managers can utilize all this information to get a better sense of the total time, effort, and budget needed for a Project, especially if your budgeting takes into account how much of a Project has fuzzy matches. Project managers can also provide this information to prospective translators to ensure the translators know what they are getting into and are appropriate for the assignment.
### Document Leverage
The Document Leverage section is structured similarly to the Project Leverage section, but provides a breakdown of word matches for each document in the Project.
![]()
This information can be utilized by Project managers to determine which documents are likely going to take more effort to translate, allowing the Project manager to assign each document to an appropriate translator. This information can also be shared with prospective translators to give them a better sense of a Project before they start working on it.
Note: leverage is computed at the time of import, so it is possible that documents imported later will show more repetitions if there are duplicate segments. If documents are translated out of order, e.g. a document imported later, repetitions may not be correctly represented at the document level, but will always be correct in the project section.
## Recalculating Leverage
![]()
There are instances where the entire leverage report needs to be recalculated. These instances are often due to document splitting or deleting original documents. After a leverage report is recalculated 101, 100, and 95-99 matches are likely to drop if significant time has passed between import and recalculation--this is due to the data source increasing in size. Please use this button cautiously. A warning pop-up will require the user to check “I understand that if the data source has grown substantially since the last update, New and Fuzzy word counts will drop”, before finally clicking “Recalculate”
![]()
## Downloading Leverage Reports
![]()
Leverage Reports can be downloaded for offline use. Note, they will only reflect documents imported up to that point. If there have been recalculations word counts will likely change due to TM increasing.
# Project Reports
Source: https://support.lilt.com/kb/how-to-read-project-reports
LILT Project Reports provide information to help project managers assess the efficiency of translators and reviewers working on a Project. This article covers generating, reading, and utilizing Project Reports to make the most of the LILT platform.
## How to generate Project Reports
Project managers can access the Project Reports page from the Project view by clicking on the `Project Report` button under `Reports`.
![]()
On the Project Report page, click the `Generate` button to generate your first report for the Project.
![]()
If a report already exists, you can regenerate the report by clicking on the `Refresh` button in the upper-right of the Project Report page.
Reports are stored temporarily in your browser and are not saved within LILT, so if you come back at a later time, you will need to generate a new report. If you want to save a report to reference later on, click the `Download report` button in the upper-right to download an XLSX file containing all the information shown on the report page.
![]()
## Reading and making use of Project Reports
Project reports break down both the progress made on a Project as a whole and the contributions made by each translator and reviewer. For this reason, one of the most useful times for a Project manager to generate a Project Report is after the Project is complete. It can also be very useful to generate Project Reports part way through a Project to assess if a Project is on track, especially for larger Projects.
The Project Report is sectioned into two areas that are detailed out in the sections below.
### Project overview section
The top area of the Project Report provides useful information for Project managers to quickly assess the progress being made on a Project. If there is anything concerning, such as a high error rate, the Project manager can then look through the individual sections for each contributor to find the sources of concern.
![]()
* **Translated:** Percent of segments in the Project that have been confirmed in Translate mode.
* **Reviewed:** Percent of segments in the Project that have been accepted in Review mode. *Note that segments that have been accepted automatically due to Review Sampling count toward this percent.*
* **Words per hour translated:** The average words per hour for all translators working on the Project.
* **Words per hour reviewed:** The average words per hour for all translators working on the Project.
* **Total translation time:** How much time has been spent by all translators on the Project (including research time).
* **Total review time:** How much time has been spent by all reviewers on the Project (including research time).
* **Estimated translation remaining:** How much time LILT estimates it will take translators to finish translating the Project.
* **Estimated Review Remaining:** How much time LILT estimates it will take reviewers to finish reviewing the Project.
* **Sampling percentage:** The Review Sample size for the Project.
* **Number of sampled segments:** The number of segments were chosen for review. This is calculated as the total number of segments multiplied by the sampling percentage. Note: the sample size is treated as 100% until the document is marked as done in translation.
* [**Error rate**](/kb/what-does-error-rate-mean): The percent of segments reviewers have marked as having errors out of the total number of segments reviewed. **Note: The error rate for a Project displays the collective error rate for documents that are fully reviewed. If there are no documents that have been fully reviewed, the error rate will not display at all.**
### Individual overview section
The bottom area of the Project Report has sections for each user who made contributions to the Project. It breaks down the contributions of each user and how long they spent working on the Project. This is useful for Project managers to check after a Project is complete in order to see things like error rates for each translator.
![]()
* **Words:** Total number of words translated.
* **New words:** Number of words translated into new words not already in the TM.
* **Fuzzy words:** Number of words translated utilizing fuzzy matches from the TM.
* **Exact words:** Number of words translated utilizing exact matches from the TM.
* **Deleted words:** Total number of words contributed to documents that have been deleted.
* **Deleted new words:** New words (that aren't in the Data Source) contributed to documents that have been deleted.
* **Deleted fuzzy words:** Number of words contributed to deleted documents that are fuzzy matches to existing entries in the Data Source.
* **Deleted exact words:** Exact words (that are in the Data Source) contributed to documents that have been deleted.
* **Reviewed words:** Number of words reviewed.
* **Total time:** Total time spent translating, researching, and reviewing.
* **Translation time:** Time spent in Translate mode.
* **Review time:** Time spent in Review mode.
* **Research time:** Time spent researching away from the editor, but not idle.
* **Words per hour:** `words` divided by `translation time`.
* **New words per hour:** `new words` divided by `translation time`.
* **Reviewed words per hour:** `reviewed words` divided by `review time`.
Note: If a Project manager Pretranslates a document, they have the option to attribute those Pretranslations to their account, if they choose this option, they will have their own contributor section here as a reviewer. If they Pretranslate a document and choose not to be attributed, the attribution goes to the original person who made the translation in the associated memory, and that person will have their own contributor section in the Project Report as a translator.
# Revision Reports
Source: https://support.lilt.com/kb/how-to-read-revision-reports
Revision Reports provide summaries of all segment revisions made by reviewers across all documents within a Project. Project managers and linguists can utilize Revision Reports to gauge performance and make adjustments that increase productivity in future Projects. Revision reports will only show changes once segments have been accepted by the reviewer.
Revision Reports let project managers see how linguists are performing both at a glance and in a detailed breakdown. This article helps project managers understand how to read revision reports and use them to improve their quality metrics.
Revision Reports show project managers how translations were edited by reviewers. This data can help improve translation quality and allow project managers to train translators on how to better meet client expectations.
## Generating a Revision Report
To generate a Revision Report, navigate into the desired Project, and navigate to the `Reports > Revision Report` tab. This report contains all revisions made within the Project.
![]()
## Reading Revision Reports
Revision Reports highlight important metadata at the top of the table, and use a tabular format to show all revisions made by Reviewers and Secondary Reviewers, respectively. LILT groups changes made within a certain time frame and will display them as one revision. If a linguist makes many changes to a segment many seconds/minutes/hours apart, they will all show as distinct revisions in the in-product revision report. Comments from the Reviewer or Secondary Reviewer will point to the latest revision. Comments from [LILT AI Review](/kb/ai-review) will point to the first revision.
![]()
## Downloading Detailed Revision Reports
Using the Deliver > Download revision report action in the top right corner of the page, you can access an Excel file with more detailed revision history. This includes two tabs: Summary and Revisions.
![]()
### Summary
The `Summary` sheet provides a summary of all revision information for a Project.
| | |
| -------------------------------------------------- | --------------------------------------------------------------------------------- |
| **Total source segment count** | The number of source segments in the Project. |
| **Accepted segment count** | The number of segments with accepted translations. |
| **Accepted sampled segment count** | The number of sampled segments that were accepted. |
| **Accepted sampled segments with revisions** | The number of sampled segments accepted with revisions. |
| **% Accepted sampled segments with revisions** | Out of all the sampled segments, the percent of segments accepted with revisions. |
| **Accepted random sampled segments with errors** | The number of random sampled segments with errors. |
| **% Accepted random sampled segments with errors** | The percent of random sampled segments with errors. |
| **AI Review Error Rate** | The error rate (%) among the segments that were selected for AI Review. |
For more information on sampling, see the [Review Sampling](/kb/review-sampling) article.
### Revisions
The `Revisions` sheet provides detailed information for every change made to every reviewed segment in the Project. Each row is dedicated to a specific revision of a segment.
| | |
| ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| **Document Name** | The name of the document the revision took place in. |
| **Segment Number** | The segment number in the document. |
| **Segment ID** | The ID number of the segment that was revised. |
| **Source** | The source text being reviewed. |
| **Sampled Segment** | A `True` or `False` value indicating whether the segment was sampled during Review Sampling. |
| **Confirmed Target** | The text when it was confirmed by the translator. |
| **Reviewed Target** | The text accepted by the reviewer. |
| **Reviewer Changes?** | A `Yes` or `No` value indicating whether the reviewer made changes to the confirmed target. |
| **Translator** | The name of the translator, if they have given a name for their account. |
| **Translator Email** | The email associated with the translator’s account. |
| **Reviewer** | The name of the reviewer, if they have given a name for their account. |
| **Reviewer Email** | The email associated with the reviewer’s account. |
| **Error Resolved?** | A `Yes` or `No` value indicating whether the error indicated by the reviewer was resolved by the translator. |
| **Error Category** | The category of error selected by the reviewer. For more information on error categories, see [this](/kb/segment-comments) article. |
| **Error Sub-Category** | The sub-category of error selected by the reviewer. For more information on error categories, see [this](/kb/segment-comments) article. |
| **Error Severity** | The severity of error selected by the reviewer. For more information on error categories, see [this](/kb/segment-comments) article. |
| **Error Comment** | The comment left by the reviewer when indicating the error. *This does not include translator comments.* |
| **Error Commenter** | The name of the reviewer who left the comment. |
| **Revision Target** | The segment content before the reviewer reviews it, which is generally the same as the confirmed target. |
| **Error Revision ID** | The ID of the revisions. |
| **Revision Reviewer** | The name of the reviewer who last made a revision to the segment. |
| **Revision Reviewer Email** | The email address of the reviewer who last made a revision to the segment. |
| **Revision Date** | The date and time (GMT) at which the revision occurred. |
| **Segment last update Date** | Timestamp of when the segment was last updated by anyone. |
### Revisions overview
The `Revisions overview` sheet provides the same information as the `Revisions` sheet, except that instead of displaying every change, the `Revisions overview` sheet is a consolidated display of the most recent changes for each segment, with only displays one entry per segment.
### Secondary Review Revisions
| | |
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Document Name** | The name of the document the revision took place in. |
| **Segment ID** | The ID number of the segment that was revised. |
| **Segment Number** | The segment number in the document. |
| **Source** | The source text being reviewed. |
| **Reviewed Target** | The text accepted by the reviewer. |
| **Secondary Review Errors** | The comment left by the secondary reviewer when indicating the error. *This does not include translator comments.* |
| **Secondary Review Error Category** | The category of error selected by the secondary reviewer. For more information on error categories, see [this](/kb/segment-comments) article. |
| **Secondary Review Error Sub-Category** | The sub-category of error selected by the secondary reviewer. For more information on error categories, see [this](/kb/segment-comments) article. |
| **Secondary Review Error Severity** | The severity of error selected by the secondary reviewer. For more information on error categories, see [this](/kb/segment-comments) article. |
| **Secondary Reviewers** | The name of the secondary reviewer, if they have given a name for their account. |
## Utilizing Revision Reports as a linguist
While linguists do not have access to generate Revision Reports, it can be useful for project managers to share the report with translators to provide an overview of the translator’s performance and identify areas for improvement. If translators do not receive regular feedback on their translations, they will not know what parts of their work require revision, and therefore will make repeated mistakes, creating additional work for reviewers or clients.
The Revision Report columns `Error Category`, `Error Sub-Category`, `Error Severity`, and `Error Comment`allow translators to see what errors were flagged by reviewers and what changes were made to the translations. This facilitates discussion between translators and reviewers to help them formulate plans for improving team communication, collaboration, and performance. For example, if a linguist notices they’ve received mostly literal translation errors, they might ask the project managers or reviewers for best practices on how to have a more marketable style.
## Utilizing Revision Reports as a project manager
Similar to a linguist, project managers also use the revision report as a basis to see how linguists are doing based on the error rates in a report.
When a Project has a high error rate, this signifies that a linguist might have quality issues. Within Lilt, an error rate of more than 5% is considered high. When this happens, it is the project manager’s responsibility to go into the Revision Reports to see what kind of errors are being made by the linguists. From there, the project manager will devise tactics to help the linguists improve quality.
As the project manager analyses the report, they might see a pattern in errors, such as most errors being of a specific type. With that information, the project manager can formulate an action plan for the linguist based on the errors committed.
# HubSpot
Source: https://support.lilt.com/kb/hubspot
The HubSpot Connector enables seamless integration between LILT's translation platform and HubSpot CMS, allowing you to translate HubSpot content (pages, blog posts, marketing emails, forms) directly within your translation workflow. The connector supports both manual content submission and automated scheduled translations.
## Features
### Manual Submission
* **Browse and Select Content**: Users can browse HubSpot resources by type and select specific content for translation
* **Resource Type Filtering**: Filter content by resource type (Site Pages, Landing Pages, Blog Posts, Marketing Emails, Forms)
* **Multi-Select Support**: Select multiple resources at once for batch translation
* **Source Language Filtering**: Filter resources by source language to only see content in specific languages. This can be done through language selection in the LILT job submission page.
* **Instant Materialization**: Selected resources are immediately materialized into translation-ready files
### Automated Schedules
* **Multiple Schedules**: Create multiple automated schedules per connector, each with its own configuration
* **Flexible Scheduling**: Support for daily and weekly schedules
* **Timezone Support**: Configure schedules in any IANA timezone
* **Resource Selection**: Choose specific resources or entire resource types for automated translation
* **Change Detection**: Only translates content that has changed since the last run (state-aware)
* **Project Naming Templates**: Customize project names using templates with placeholders
### Supported Resource Types
| Resource Type | Translatable | Delivery Method |
| :--------------- | :------------------------------------------------------------------------------------------- | :--------------------------------------- |
| Site Pages | Layout sections, headings, text content, descriptions | Language variant (created automatically) |
| Landing Pages | Layout sections, headings, text content, descriptions | Language variant (created automatically) |
| Blog Posts | Post body, name/title | Language variant (created automatically) |
| Marketing Emails | Email subject, content (HTML and plain text), preview text | Copy with language appended to name |
| Forms (Legacy) | Field labels, options, submit text, inline messages, validation messages, legal consent text | Copy with language appended to name |
**Language variants** — For site pages, landing pages, and blog posts, the connector automatically creates a language variant in HubSpot for each target language. If a variant already exists, it is updated. You do **not** need to manually create language variants for each page — the connector handles this automatically.
![Image]()
**Copies** — For marketing emails and forms, HubSpot does not support language variants. Instead, the connector looks for an existing copy with the same name followed by a dash and the target language code (e.g., `some-name - en-US`). If a match is found, it updates that content. Otherwise, it creates a new copy using that naming format.
### Unsupported Content
The connector does not extract or translate the following. If any of these are in scope, they must be handled outside the connector (e.g. manual theme translation billed as a separate service item).
* **Global / theme content**: Reusable template files such as headers, footers, and other theme modules are not picked up. Strings hardcoded into theme or module files are not accessible through the connector and require manual translation.
* **Pop-up Forms and Blog Comment Forms**: Only forms built with HubSpot's **Legacy Form Editor** are supported (see below). Pop-up forms and blog comment forms are not extracted.
* **Non-legacy "Form Editor" forms**: Forms created with HubSpot's newer Form Editor are not currently supported, as they are not yet exposed via a HubSpot API.
### Prerequisites
* A LILT organization account
* A HubSpot account with CMS access
**Note:** Free HubSpot accounts are limited to 3 language variants per page. If you need more target languages, confirm your HubSpot plan supports the number of language variants you require.
### Initial Setup
### Step 1: Connect HubSpot to LILT
*Users installing apps in their HubSpot account must either be a [Super Admin](https://knowledge.hubspot.com/user-management/hubspot-user-permissions-guide#super-admin) or have [HubSpot Marketplace Access](https://knowledge.hubspot.com/user-management/hubspot-user-permissions-guide#settings) permissions.*
1. Tell your **LILT team** you would like to add a HubSpot integration so they can enable HubSpot connectivity.
2. Navigate to the [Job Submission Page](https://lilt.com/app/translate/v2) in LILT
3. Select the **HubSpot** icon
![Image]()
4. Click **Sign in to your HubSpot account** to start the OAuth authentication flow
5. You will be redirected to HubSpot — authorize LILT to access your content
6. Once authorized, you are redirected back to LILT and the connector is ready to use
### OAuth Authentication Flow
The HubSpot connector uses OAuth 2.0 for secure authentication. The flow works as follows:
1. **Initiation**: User clicks "Connect HubSpot" in the LILT interface
2. **Redirect to HubSpot**: User is redirected to HubSpot's OAuth authorization page
3. **Authorization**: User grants permissions (scopes: `oauth`, `content`, `forms`)
4. **Token Exchange**: HubSpot returns an authorization code
5. **Token Storage**: The connector exchanges the code for a refresh token, which is securely stored
6. **Automatic Refresh**: Access tokens are automatically refreshed when they expire (typically every 6 hours
![Image]()
### OAuth Scopes
The connector requests the following OAuth scopes:
* `oauth`: Basic OAuth access
* `content`: Access to CMS content (pages, blog posts, etc.)
* `forms`: Access to form data
## Manual Submission
### Overview
Manual submission allows users to browse HubSpot content and select specific resources for translation on-demand, without setting up automated schedules.
### Browsing and selecting content
1. Navigate to **Create Job** or **Instant Translate**
2. Select the **Source Language** in LILT first, to show only content in that specific language
3. Click the **Upload** dropdown and select **Add from HubSpot**
![Image]( "Image")
4. In the resource selection modal, choose a **Resource Type** from the dropdown:
* Site Pages
* Landing Pages
* Blog Posts
* Marketing Emails
* Forms (Legacy)
5. Use the **Search** field to find specific resources by name
6. Click **Add** — the connector fetches full content from HubSpot and prepares it for translation
7. Configure translation settings (workflow, etc.)
8. Click **Submit** to start the translation
**Pagination:** For resource types with many items, navigate through paginated results. Your selections persist across pages.
![Image]()
### Tracking translation status
After submission, jobs progress through the following stages: **Draft > Submitted > In-progress > Complete**.
**Instant translations** are processed automatically. No further action is needed — the translated content is delivered back to HubSpot once the job reaches “Complete.”
**Verified translations** are sent to the LILT platform for human review. Once the linguist completes their review, the translated content is delivered back and the job status updates to “Complete.”
### What happens after delivery
* **Site Pages, Landing Pages, and Blog Posts**: A new language variant is created (or updated) in HubSpot. The source content is never modified.
* **Marketing Emails and Forms**: A new copy is created with the target language code appended to the name (e.g., `Newsletter - es`). If a copy already exists for that language, it is updated.
#### Re-translating content
* Submitting the same resource for the same target language again will **update** the existing translation — no duplicates are created.
## Automated Schedules
### Overview
Automated schedules allow you to set up recurring translation jobs that automatically extract and translate HubSpot content based on a schedule.
### Schedule Configuration
Each schedule can be configured with:
* **Schedule Type**:
* `daily`: Runs every day at a specified time
* `weekly`: Runs on specific days of the week at a specified time
* **Time of Day**: 24-hour format (HH:mm:ss), e.g., "14:30:00" for 2:30 PM
* **Timezone**: IANA timezone format (e.g., "America/New\_York", "Europe/London")
* **Days of Week** (for weekly schedules): Array of days: `["mon", "tue", "wed", "thu", "fri", "sat", "sun"]`
![Screenshot 2025 12 11 At 17 50 20]()
### Resource Selection for Schedules
Schedules can be configured to translate:
1. **Specific Resources**: Provide a list of specific resources with `object_id` and `resource_type`
2. **Resource Types**: Select entire resource types (e.g., all blog posts, all landing pages)
3. **Combined**: Mix of specific resources and resource types
### Schedule Configuration Fields
* **Source Language**: Language code (e.g., "en", "en-us") or "auto" for automatic detection
* **Target Languages**: Array of target language configurations, each with:
* `target_language`: Target language code
* `memory_id`: Translation memory ID (optional)
* `model_id`: External model ID (optional)
* `instructions`: Translation instructions (optional)
* **Workflow ID**: LILT workflow to use (e.g., "Translate", "Translate > Review")
* **Connector Workflow**: `instant` or `verified`
* **Project Name Template**: Template for project names (supports `{{NAME}}` placeholder)
* **Options (TBD)**:
* `include_tags_and_metadata`: Include tags and metadata in translation
* `only_send_updated_content`: Only send content that has changed
### Multiple Schedules
The HubSpot connector supports **multiple schedules per connector**, allowing you to:
* Create different schedules for different resource types
* Set different schedules for different languages
* Configure different workflows for different content types
* Each schedule runs independently with its own configuration
### Schedule Limitations
* **One Job Per Day**: Each schedule can create at most one job per day
* **Next Run Calculation**: The next run time is calculated based on the schedule configuration
* **Timezone Handling**: All times are stored and calculated in UTC
## Technical Limitations
1. **One Connector Per HubSpot Site**: Each LILT organization can connect to only one HubSpot account/site. Attempting to create a second HubSpot connector for the same organization will result in an error: *"A connectors configuration already exists for this organization and kind"*
2. **OAuth Scope**: The connector requires specific OAuth scopes (`oauth`, `content`, `forms`). If these scopes are not granted, the connector will not function properly.
3. **API Rate Limits**: HubSpot API has rate limits. The connector implements retry logic with exponential backoff, but very high-volume operations may be throttled.
4. **Content Format**: The connector works with HubSpot's CMS API structure. Custom modules or non-standard content structures may not be fully supported.
5. **Language Variations**: HubSpot manages language variations separately. The connector delivers translations as new language variations in HubSpot.
6. **Form API Version**: Currently, only legacy forms (v2 API) are fully supported. The new forms API (v3) is not yet fully available in HubSpot.
7. **Supported form types**: Only forms created with HubSpot's **Legacy Form Editor** (v2 API) are supported. Forms built with the newer **Form Editor** (v3 API), **pop-up forms**, and **blog comment forms** are not supported and will not be picked up by the connector.
8. **Forms and Marketing Emails delivery:** Delivery for this content types are returned as cloned versions of the original selected resource. This is because this CRM content does not support language variations.
### HubL Templating Language
LILT does not have complete native support for HubSpot's [HubL templating language](https://developers.hubspot.com/docs/cms/reference/hubl/overview). Behavior depends on how HubL is used:
* **Supported (simple tokens):** Inline personalization and CTA tokens are handled by converting them into inline placeholders that are preserved through translation, for example:
```text theme={null}
{{ contact.firstname }}
{{ personalization_token('contact.firstname', '-') }}
{{ cta('6e4122dc-6bfc-45de-8329-5e7f0a5a573b') }}
```
**Not reliably supported (logic-based HubL):** Open-ended or logic-based constructs — [modules](https://developers.hubspot.com/docs/cms/reference/hubl/overview#modules), [if statements](https://developers.hubspot.com/docs/cms/reference/hubl/overview#if-statements), and [for loops](https://developers.hubspot.com/docs/cms/reference/hubl/overview#for-loops) — may not be handled correctly. If your content uses these, share examples with your LILT team so they can assess feasibility and set expectations before setup.
> **Note:** Marketing emails that use HubL tags may require additional file-filter configuration during onboarding. Your LILT team will handle this as part of setup.
## Error Troubleshooting
This section provides detailed information about common errors, their explanations, and step-by-step solutions.
### OAuth and Authentication Errors
**Error**: "OAuth code not found" or "OAuth authorization failed"
**Explanation**: This error occurs when the OAuth flow is interrupted or the authorization code is missing from the callback. This can happen if:
* The user cancels the authorization in HubSpot
* The redirect URI is misconfigured
* The OAuth state parameter is invalid or expired
* Network issues during the OAuth callback
**How to Solve**:
1. **Retry the OAuth flow**: Navigate back to Integrations → HubSpot and click "Connect" again
2. **Check redirect URI**: Ensure the redirect URI in HubSpot app settings matches: `{connectors_webhooks_url}/webhooks/oauth/hubspot/redirect`
3. **Clear browser cache**: Clear cookies and cache, then retry
4. **Check HubSpot app status**: Verify your HubSpot app is active and has the correct scopes configured
5. **Verify network connectivity**: Ensure there are no firewall or network issues blocking the OAuth callback
**Error**: "A connectors configuration already exists for this organization and kind"
**Explanation**: Only one HubSpot connector can exist per LILT organization. This error occurs when attempting to create a second HubSpot connector for the same organization.
**How to Solve**:
1. **Use existing connector**: If you need to connect to the same HubSpot site, use the existing connector configuration
2. **Update existing connector**: If you need to change HubSpot accounts, disconnect the current connector first, then create a new one
3. **Use separate organization**: If you need to connect to a different HubSpot site, create a separate LILT organization for that connection
4. **Delete old connector**: If the existing connector is no longer needed, delete it first before creating a new one
### Resource and Content Errors
**Error**: "Unable to determine HubSpot resource type from filename"
**Explanation**: The connector couldn't parse the resource type and ID from the translated file's filename. This typically happens when:
* The filename format is incorrect (should be `{resource_type}_{object_id}.json+html`)
* The file was manually modified or corrupted
* The resource type is not supported
**How to Solve**:
1. **Check file format**: Ensure files follow the naming convention: `{resource_type}_{object_id}.json+html` (e.g., `landing-pages_12345.json+html`)
2. **Verify resource type**: Ensure the resource type is one of the supported types (site-pages, landing-pages, blog-posts, marketing-emails, forms-legacy)
3. **Reload resources**: If using manual submission, re-select and reload the resources
4. **Check connector logs**: Review logs for the specific resource that failed to identify the issue
**Error**: "No resources to extract" or "No resources found"
**Explanation**: The connector couldn't find any resources matching the specified criteria. This can occur when:
* The source language filter doesn't match any resources
* The resource type has no content
* The OAuth token doesn't have access to the resources
* The HubSpot account has no content of the selected type
**How to Solve**:
1. **Check source language filter**: Verify the source language matches your content's primary language (e.g., "en" for English, "en-us" for US English)
2. **Remove language filter**: Try removing the source language filter to see all resources
3. **Verify resource type**: Ensure the selected resource type exists in your HubSpot account
4. **Check HubSpot permissions**: Verify the OAuth token has access to the CMS content (check scopes)
5. **Test with different resource type**: Try selecting a different resource type to confirm the connector is working
**Error**: "Failed to materialize HubSpot resource" or "Resource not found"
**Explanation**: The connector couldn't retrieve the full content of a specific resource from HubSpot. This can happen when:
* The resource was deleted in HubSpot after selection
* The resource ID is invalid
* The OAuth token doesn't have permission to access the specific resource
* The HubSpot API is temporarily unavailable
**How to Solve**:
1. **Verify resource exists**: Check in HubSpot that the resource still exists and hasn't been deleted
2. **Re-select resources**: In manual submission, re-select the resources and try again
3. **Check permissions**: Ensure the OAuth token has the `content` scope and access to the specific resource
4. **Retry operation**: Wait a few minutes and retry, as this could be a temporary API issue
5. **Check HubSpot API status**: Verify HubSpot's API status page for any known issues
### Translation Delivery Errors
**Error**: "Failed to deliver translated content to HubSpot" or "BadRequestProblem"
**Explanation**: The connector couldn't deliver translated content back to HubSpot. This can occur due to:
* Invalid JSON format in translated content
* Missing required fields in the translated content
* HubSpot API validation errors
* Network connectivity issues
* API rate limiting
**How to Solve**:
1. **Check translation job status**: Verify the translation job completed successfully in LILT
2. **Validate JSON format**: Ensure the translated content is valid JSON (check for syntax errors)
3. **Review HubSpot API response**: Check connector logs for the specific HubSpot API error message
4. **Retry delivery**: Some errors are transient; try re-delivering the translation
5. **Check API rate limits**: If you're processing many resources, you may be hitting HubSpot's rate limits - wait and retry
6. **Verify resource still exists**: Ensure the target resource hasn't been deleted in HubSpot
**Error**: "LANGUAGE\_ALREADY\_TRANSLATED" (treated as success)
**Explanation**: This is not actually an error - it's an informational message. HubSpot returns this when attempting to create a language variation that already exists. The connector treats this as a success case and skips creating a duplicate.
**How to Solve**:
* **No action needed**: This is expected behavior. The translation already exists in HubSpot for that language
* **Update existing translation**: If you want to update the existing translation, delete the language variation in HubSpot first, then re-deliver
### Schedule and Automation Errors
**Error**: "Schedule not running" or "No jobs created for schedule"
**Explanation**: A scheduled translation job didn't execute as expected. This can happen when:
* The schedule configuration is invalid
* The next run time hasn't been reached
* The schedule already ran today (one job per day limit)
* The scheduler service is not running
* There are no resources matching the schedule criteria
**How to Solve**:
1. **Check schedule configuration**: Verify the schedule type, time, timezone, and resource selection are correct
2. **Verify next run time**: Check the schedule's `next_run` timestamp to ensure it's in the past
3. **Check one-per-day limit**: Each schedule can only create one job per day. If it already ran today, wait until tomorrow
4. **Verify resources exist**: Ensure there are resources matching the schedule's resource type and source language criteria
5. **Check scheduler service**: Verify the connector scheduler service is running (contact support if needed)
6. **Review schedule logs**: Check connector logs for any errors during schedule execution
**Error**: "source\_language is required in scheduler\_settings"
**Explanation**: A scheduled job was created without a source language specified in the schedule configuration. The source language is required for the connector to filter and process resources correctly.
**How to Solve**:
1. **Update schedule configuration**: Edit the schedule and ensure a `source_language` is specified (e.g., "en", "en-us", or "auto" for automatic detection)
2. **Verify schedule settings**: Check that the schedule configuration includes all required fields:
* `source_language`
* `target_languages`
* `schedule` (with kind, time\_of\_day, timezone)
* `resource_types` or `resources`
3. **Recreate schedule**: If the configuration is corrupted, delete and recreate the schedule with proper settings
**Error**: "No target languages configured" or "target\_languages is empty"
**Explanation**: The schedule configuration doesn't have any target languages specified, so the connector doesn't know which languages to translate to.
**How to Solve**:
1. **Add target languages**: Edit the schedule and add at least one target language configuration
2. **Verify target language format**: Ensure each target language has:
* `target_language`: Language code (e.g., "fr", "es", "de")
* Optional: `memory_id`, `model_id`, `instructions`
3. **Check schedule validation**: Use the connector validation feature to verify the schedule configuration is correct
### API and Network Errors
**Error**: "RequestException" or "Network error"
**Explanation**: The connector couldn't communicate with HubSpot's API. This can be due to:
* Network connectivity issues
* HubSpot API being temporarily unavailable
* Firewall or proxy blocking requests
* DNS resolution problems
**How to Solve**:
1. **Check network connectivity**: Verify the system can reach `api.hubapi.com`
2. **Check HubSpot status**: Visit HubSpot's status page to see if there are known API issues
3. **Retry operation**: Network errors are often transient - wait a few minutes and retry
4. **Check firewall rules**: Ensure outbound HTTPS connections to `api.hubapi.com` are allowed
5. **Review DNS settings**: Verify DNS can resolve HubSpot's API domain
6. **Check proxy settings**: If using a proxy, ensure it's correctly configured
**Error**: "Rate limit exceeded" or "429 Too Many Requests"
**Explanation**: HubSpot's API has rate limits, and the connector has exceeded the allowed number of requests in a given time period. HubSpot typically allows a certain number of requests per minute/hour.
**How to Solve**:
1. **Wait and retry**: Rate limits reset after a time period. Wait 1-5 minutes and retry
2. **Reduce batch size**: If processing many resources, reduce the number of resources processed at once
3. **Space out operations**: For scheduled jobs, consider spreading them across different times
4. **Check HubSpot plan limits**: Verify your HubSpot plan's API rate limits
5. **Use retry logic**: The connector automatically retries with exponential backoff, but you may need to wait longer
# ICU Support
Source: https://support.lilt.com/kb/icu-support
### Background
ICU stands for international components for Unicode. ICU is a set of libraries that support the globalization of software applications. LILT automatically supports ICU plurals, select, select-ordinals, date, time, and number functions.
### Plurals
In addition LILT’s support of multiple plural forms, we support ICU. We automatically process plurals and place them into the CAT so that linguists can easily perform translation using our plurals modal.
### Select and Select-Ordinals
Select is most commonly used for genders. It can be used to select the correct gender words or pronouns. When translating english pronouns she, he, they need to be defined. In other languages other words could be gendered as well.
Select-Ordinals are used to properly describe the suffix of a number. For example in English depending on whether the number is 1, 2, 3, 4, or greater than 5, the suffix attached will be different: 1st, 2nd, 3rd, 4th, 5th,.. 10th.
```json theme={null}
{
"ADOPTION_INSTRUCTIONS_UPDATE_AVAILABLE": "{type, select, protectOnly {Update UniFi Protect.} uosOnly {Update UniFi OS.} other {Update UniFi OS and UniFi Protect.}}",
"COMMON_SMART_DETECTION_AGREEMENT_CONTACT_OWNER": "Please contact {ownerName, select, unknown {the console owner} other {{ownerName}}} to Enable Smart Detection to differentiate between a wider variety of objects, and enjoy more targeted event recording.",
"DASHBOARD_HARD_DISK_NOT_ENOUGH_SIZE_MESSAGE": "You need at least {minCapacity} to record {replaceableHDD, select, true {continuously} other {video}}. Please increase your storage. For the best experience, we recommend using a model from our Protect-ready HDD selection.",
"DEVICE_SIDE_PANEL_BARRIER_CLOSED": "{barrier, select, window {Window} garage {Garage} other {Door}} Closed",
"DEVICE_SIDE_PANEL_BARRIER_CLOSED_WITH_TIME": "{barrier, select, window {Window} garage {Garage} other {Door}} Closed (Open for {duration})",
"DEVICE_SIDE_PANEL_BARRIER_OPENED": "{barrier, select, window {Window} garage {Garage} other {Door}} Opened",
"DEVICE_SIDE_PANEL_BARRIER_STATUS": "{barrier, select, window {Window} garage {Garage} other {Door}} {isOpened, select, true {open} other {closed}} since {formattedTime} ({timeSince})",
"NO_TIMELAPS_CAMERAS_FOOTAGE": "You have no {isAnalytics, select, true {cameras} other {timelaps footage}}"
}
```
### Date/Time
The way a date is reported depends on the language and region. As an example the US uses MM:DD:YYYY for dates whereas the EU uses DD:MM:YYY. ICU has four classes which are related to time and date: Calendar, GregorianCalendar, Time Zone, and Simple Time Zone. LILT supports all date classes within the ICU code library.
We do handle date and time formats embedded in the ICU message format, such as `{1,time,::jmm}` or `{1,date,::dMMMM}`
### Number
ICU supports both number and currency formatting.
# Image File Translation
Source: https://support.lilt.com/kb/image-file-translation
## mage File Translation
Translating an image file (e.g. PNG, JPEG, TIFF) in LILT is very similar to the text translation workflow you're used to, and is available for both **Instant** and **Verified Translation** jobs.
### How It Works
1. **Upload your image file(s)**:
* Upload your image(s) using unified job submission. You will need to have an [AI Provider](https://support.lilt.com/kb/3rd-party-llm-support-for-the-contextual-ai-engine#ai-providers) configured for image-to-text transcription.
2. **Text extraction**:
* Under **Additional options**, select whether you want to review the extracted text before translation.
* LILT will begin extracting the text.\\
![Image]()
3. If you selected **Review extracted text**, you will be able to make any necessary changes to the extracted text. Once you're satisfied, click **Mark as reviewed** and then **Text review completed**.
![Image]()
4. If you selected Instant translation, LILT will then use your selected custom model to instantly translate the text.
5. If you selected Verified Translation, LILT will send your extracted text to our experts for translation.
### Supported Features
* **Input Formats**: Images (PNG, JPEG, TIFF, and others — see [Supported File Formats](https://support.lilt.com/kb/supported-file-formats) for the full list per AI provider)
* **Output Formats**: TXT, unless you have requested and paid for additional post-processing with your LILT Production team
* **Translation Types**: Instant and Verified Translation
* **Batch Actions**: Download multiple translated files (in TXT form) at once.
# Image File Translation
Source: https://support.lilt.com/kb/image-file-translation-self-managed
Description of your new file.
Translating an image file in LILT is very similar to the text translation workflow you’re used to.
Similar to text files:
Each Job is created with one source language (e.g. English).
Each Job holds a collection of one or more Projects, with each Project designated by a specific language pair (e.g. English to French, English to German, English to Spanish). Projects can only be created with the same source language as the Job they are in.
Each Project holds one or more documents to be translated.
LILT makes Job and Project creation simple by automatically creating separate Projects for each desired target language and populating each Project with the documents to be translated.
Create a new Job by navigating to the Homepage tab and clicking the opens up the Job creation window.
\*\*Translate \*\*under Image files. This Page 143 / 1317 The first screen of the Job creation popup form is where you fill out the Job information, add source files, and add reference materials.
Select the toggle in order to “Send for human verification to ensure quality, factuality, and accuracy”, or untoggle to send for instant translation.
Source language: Select the source language of the content being translated (this should match the
language of the documents you upload).
\*\*Target languages:\*\*Select one or multiple target languages. Each of these targets will become its own project.
Job name: Give a name to your Job.
Desired due date (optional): Job deadlines can be different than Project due dates
\*\*Advanced options:\*\*Under this tab you will see advanced options.
Provider for Image to Text:This is where you will be able to choose which OCR provider you’d like to utilize for image-to-text transcription based on your configurations in AI Hub.
\*\*Workflow:\*\*This specifies the translation workflow. For more about workflows, please reference
/kb/lilt-workflows.
ICU support: Enable if your documents contain ICU Plurals formatting
Page 144 / 1317 Documents: Upload documents you want to localize. At least one document must be uploaded to create a Job. Drag and drop files into the box, or click the **Import** button to browse for files on your computer.
You can also drag and drop a folder of documents into the box to upload all the files in the folder at once.
See the Supported File Formats article for a full list of file formats that LILT supports.
Reference materials (optional): Upload any relevant reference materials to aid linguists during localizing.
Review source text: Review the results of the text extraction and click “Mark reviewed”
. The “Send for translation” button will be enabled once all are reviewed.
Source text review and edit.
Note: Documents and reference materials will be added to all Projects under this Job. Additional documents and reference materials can be manually added later, but must be added to each Project individually.
\*\*Once finished, click \*\* **Next: Send for translation.**
**After converting from image to text, send the content for translation in the typical text translation workflow.**
Default Project settings can be modified in the Organization Settings area.
# In-Context Preview
Source: https://support.lilt.com/kb/in-context-preview
Use In-Context Preview to see your translations rendered in the source file's original layout as you work. This helps catch formatting issues, verify text fits within design constraints, and ensure the translated content looks correct before delivery.
## Supported file types
In-Context Preview is available for the following file formats. If your file type is not listed above, the preview panel will not appear in the editor.
| File Type | Extension | Notes |
| -------------------- | --------------- | ---------------------------------------------------------------------------------- |
| PDF | `.pdf` | Text-based PDFs recommended. Image-based PDFs supported with reduced fidelity. |
| Microsoft Word | `.docx` | Open replacement fonts used; proprietary fonts will be approximated. |
| Microsoft PowerPoint | `.pptx` | Open replacement fonts used; proprietary fonts will be approximated. |
| Microsoft Excel | `.xlsx` | Open replacement fonts used; proprietary fonts will be approximated. |
| HTML | `.html`, `.htm` | Static rendering only. Inline and embedded CSS supported. No JavaScript execution. |
| Plain Text | `.txt` | Includes desktop and mobile view presets. RTL/LTR formatting supported. |
| Markdown | `.md` | Open replacement fonts used; proprietary fonts will be approximated. |
| CSV | `.csv` | Open replacement fonts used; proprietary fonts will be approximated. |
## Step-by-step
1. **Open the document you've been assigned to in LILT.** Navigate to your job and click the document name to open it.
![Image]()
2. **The In-Context Preview panel will automatically open for your review.** If you exit out, click the **View > In Context Preview** to re-open.
1. Use the Horizontal vs. Vertical split button to reorient the preview.
![Screenshot 2026 08 18 At 15 57 44]()
![Screenshot 2026 06 16 At 10 55 12]()
3. **Select a segment.** Click any segment in the editor. The preview panel will automatically scroll to and highlight the corresponding text within the rendered file view.
![Screenshot 2026 06 16 At 10 56 35]()
4. **Review your translation in context.** As you type, make changes, or confirm a translation in the editor, click Reload to reflect your changes. Check for text overflow, truncation, or layout breaks.
![Screenshot 2026 06 16 At 10 57 58]()
5. **Navigate between segments using the preview.** You can click directly on text within the preview panel to jump to that segment in the editor.
6. **Toggle the preview panel on or off, or expand the view.** Click the **Preview** tab or the collapse icon to hide the panel, or maximize your editing space by dragging the bar to make the preview larger or smaller.
7. Finish reviewing as you normally would.
## Frequently Asked Questions
**Is In-Context Preview available for all file types?**
No. Preview is supported for TXT, PDF, HTML, DOCX, PPTX, XLSX, Markdown, and CSV files. If your file type is not supported, the preview panel will not appear.
**Why is my preview panel blank or not loading?**
Your file type may not support preview. If the format is supported, try refreshing the page. PDF files can take up to 60 seconds to generate on first load.
**Why does the initial PDF preview take so long to load?**
PDF rendering requires an export process that can take up to 60 seconds on first load. Subsequent previews for the same file are faster.
**Can I edit my translation directly in the preview panel?**
No. The preview is view-only. All edits must be made in the CAT editor segments. Refresh the preview manually after making changes to see them reflected.
**Why does the preview look different from the final delivered file?**
The preview renders an approximation of the source layout. For DOCX, PPTX, XLSX, Markdown, and CSV files, open replacement fonts are used in place of proprietary fonts, which may cause slight differences in text width or line wrapping. PDF files with multi-column layouts may also display text matching issues.
**The preview isn't highlighting my selected segment. What should I do?**
Click the segment in the editor again to re-trigger the highlight. If that doesn't work, refresh the page and reopen the document. If the issue persists, submit a support ticket.
**In which workflow stages is In-Context Preview available?**
In-Context Preview is available in all workflow stages (Translate, Review, Secondary Review), as long as the file type is supported.
**Does the preview update automatically as I translate?**
No. The preview does not update in real time. Manually refresh the preview panel to see your latest translations reflected.
**The layout doesn't feel right for my workflow. Can I change it?**
The default preview will align with the orientation of your source file.
* **Portrait source files** default to a **side-by-side** layout.
* **Landscape source files** default to a **top-and-bottom** layout.
You can change this by clicking on the orientation buttons at the top of the panel.
## Known limitations
* **Manual refresh required.** The preview updates on manual refresh rather than automatically, so you have full control over when you see the latest version. Refresh after each change to see your updates reflected.
* **Initial load time.** The first PDF preview typically takes up to 60 seconds to generate, depending on file size, and you'll see a loading state while it processes. Once that first preview is generated, subsequent previews for the same file load faster.
* **Multi-column PDF layouts.** Text can occasionally be split across columns in a way that leads to mismatched segment highlighting.
* **Mobile view.** Mobile view is optimized for TXT files today, so that's the best format to use if you're previewing on the go.
* **Invisible content.** The preview focuses on visible content, so invisible placeholder text, notes, and comments won't appear there. If your file includes these, you may see "unmatched" segments (segments in the editor with no corresponding spot in the visual preview). This is expected behavior given how the preview renders content.
# Information Assurance (IA)
Source: https://support.lilt.com/kb/information-assurance-ia
This article details the Information Assurance guidelines for self-managed LILT installations
## Purpose
LILT shall perform a static vulnerability analysis of all Docker images provided to Customer before delivery. The purpose is to keep known common vulnerabilities and exposures (CVEs) from deployment on secure systems.
### Analysis
LILT uses Grype, an open source project by [*Anchore*](https://github.com/anchore/grype), and a comprehensive vulnerability/misconfiguration scanner for containers and other artifacts.
### Vulnerability Levels
1. LILT shall attempt to resolve all CRITICAL, HIGH, MEDIUM, and LOW CVEs with known fixes in advance of any deliverable.
2. LILT will track any CRITICAL, HIGH, MEDIUM, and LOW that have no known fixes and resolve them in advance of the next deliverable after fixes are reported or other alternatives are found to mitigate the CVE issue while also keeping the LILT application operational.
3. In instances where vulnerabilities cannot be resolved because they would impair functionality of the LILT system, such vulnerabilities shall be documented with an explanation.
4. INFORMATIONAL/NEGLIGIBLE CVEs shall not be regularly resolved.
5. LILT resolves CRITICAL, HIGH, MEDIUM, and LOW CVEs within its images as part of continuous CVE evaluation and hardening. Security patches outside of the regular update cadence (see below) will be done on an ad-hoc basis when either a) LILT identifies an immediate need or b) customer(s) request **and** LILT agreeds that a volunerability poses an immediate security risk to the LILT platform.
### Regular Updates
For the duration of contractual obligations, LILT shall deliver container image updates to the Customer’s technical team every twelve weeks. The Customer shall be responsible for system upgrades using these assets unless otherwise agreed upon.
### External Dependencies
External dependencies shall be used as-is, but shall also be scanned prior to delivery. LILT shall regularly review external dependencies to best mitigate CVEs.
## Development Process
In order to ensure release of the safest, highest-quality code, the LILT development follows the below process.
### Development
A developer from LILT’s technical team assesses the product requirements for a feature. Thereafter, the developer begins software development in a branch off of the `main` coding branch of the relevant repository. LILT has multiple code repositories, one for each major section of the LILT architecture.
### Code Review and Unit Testing
Before code is merged back into a `main` branch, the author of the code opens a pull request on LILT’s Github instance.
Unit and integration tests are automatically performed on our CI/CD instance, Jenkins which runs on LILT servers. The results of the tests are then automatically displayed in the pull request with a green check mark indicating tests successfully passed.
When tests are passed, LILT’s configuration requires both AI and human review of the code, or an area expert is selected if the code is particularly sensitive. The code is not merged into the `main` branch until peer reviewers manually approve the request.
### Release
Self-managed releases happen once quarterly. In this process, all technical teams are required to have code finished and tested per the above process by a particular date (“soft deadline”).
Finally, the build is pushed to a staging environment that mimics a self-managed customer's operating environment, and the technical team and our QA testers manually confirm that all new features work as desired, as well as a standard set of critical platform features.
### Deployment
For self-managed releases, packages are provided as Docker images in .tar format and ECR via the channel most appropriate to the customer. Typically, images are hosted on a private S3 bucket, but can also be physical media or other solutions.
### CVE Review
CVEs are automatically reported via our CI/CD tool based on the Grype scanner. Repositories are required to be clean of any LOW and higher CVEs before any release is deployed; additionally, a final check before the release of any deliverable is done to ensure no self-managed packages are deployed with known LOW or higher CVEs at the time of release, though LILT reserves the right to make a discretionary call to release the software with CVEs if testing is complete and the newly discovered CVEs are deemed to have mitigating factors that lower the impact severity. These CVEs will be included in the justification documentation.
# Infrastructure Release Notes
Source: https://support.lilt.com/kb/infrastructure-release-notes
This article details the infrastructure changes required when installing this version of LILT.
## 6.1.0
This section is under active development and has not yet been verified — content was auto-generated from a diff between the `5.3.x` and `main` branches of `on-prem-installer` and needs human review before this constitutes guidance.
### In-Cluster Vault (Default ESO Backend)
EKS and on-prem installs now default to deploying a HashiCorp Vault instance in-cluster (`ENABLE_VAULT=true`) as the backend for External Secrets Operator (ESO), in place of direct secret seeding. The Vault server image ships in the delivery tarball with every other image.
On EKS this is the working default: External Secrets reads its secrets from that Vault, and AWS KMS auto-unseal means the pod recovers on its own after a restart.
**On-prem installs get Vault, but nothing that uses it.** External Secrets Operator is installed only on the EKS path, so on the on-prem flavor the shipped Vault is deployed and then consumed by nothing, and `SECRET_BACKEND` has no effect. Secrets continue to come from the seed file exactly as before.
An on-prem install that does not want the unused component can skip it:
```bash theme={null}
# install.env
ENABLE_VAULT=false
```
Note also that on-prem Vault seals itself on every restart or node drain, because it uses Shamir rather than KMS auto-unseal and the bootstrap runs only at install time.
Customers pointing ESO at their own external Vault, rather than the shipped in-cluster one, continue to use the `SECRET_BACKEND=vault` and `VAULT_AUTH=approle` path, which is unchanged.
See [Secrets and Vault](/kb/secrets-and-vault) for the backends, the Vault path and key inventory, and the unseal behaviour.
### Hardware Requirements
`gemma-vllm-inference` now requires **compute capability ≥8.9 (Ada generation or later) on both EKS and on-prem**. Gemma is FP8-quantised and native FP8 support starts with Ada, so this excludes every Ampere card, including the 80 GB A100, regardless of how much VRAM it has. The VRAM floor differs between the two:
* **EKS:** the GPU VRAM floor has been raised from 21999 MiB to 43399 MiB, and the GPU count is 1. **L4 GPUs (23034 MiB) no longer satisfy this requirement.** L40, L40S, H100, or H200 cards are required going forward. A cluster whose only Ada hardware is the 24 GB class can size back down with the `gemma-dual-medium` GPU profile.
* **On-prem / classic:** `gemma-vllm-inference` previously had no VRAM floor (only a generic `capability: gpu` node selector). It now requires ≥22000 MiB of GPU memory. This admits L4, L40, L40S, and H100; it excludes T4, A10G, A6000, and A100. GPU count is unchanged at 2.
See [GPU profiles and values overlays](/kb/gpu-profiles-and-values-overlays) for the profile tables and how to change an allocation.
### Configuration Updates
* The APRYSE keys (`APRYSE_KEY`, `APRYSE_DOCX_KEY`) moved from inline environment variables on the `converter`/`file-translation` services to the `lilt-secrets` Kubernetes Secret, referenced via `envValueFrom`. Before upgrading, ensure `lilt-secrets` contains `apryseKey` and `apryseDocxKey`, or the `core-tmx-import` WorkflowTemplate will fail with a duplicate-value error.
* A new `connectors-secrets` Kubernetes Secret was introduced (`managerUiSecretKey`, `webhookAuthToken`). This must be seeded before upgrading.
* The `cluster-autoscaler` Helm chart is now pulled from Lilt's internal GAR OCI registry (`CHART_BASE`, defaults to `oci://us-central1-docker.pkg.dev/lilt-service-48916b30/charts`) instead of the public `https://kubernetes.github.io/autoscaler` repo. Air-gapped or firewall-restricted customers must ensure OCI chart pull access to this registry.
* Customers setting `SECRET_BACKEND=vault` or `SECRET_BACKEND=aws` (ESO-backed secrets, distinct from the in-cluster Vault above) must provision each secret in the README's "Secret provisioning (External Secrets)" table as a JSON object, either under `BASE_VAULT_PATH` or via a per-secret `_SECRET_PATH` override — do **not** provision `lilt-secrets` directly, it's composed by ESO from the other secrets. The external-Vault approle path (`VAULT_AUTH=approle`) additionally requires a pre-existing `vault-approle` Kubernetes Secret in the `external-secrets` namespace, provisioned out-of-band. The default in-cluster-Vault path (`VAULT_AUTH=kubernetes`) needs no such secret. The AWS path uses IRSA — leave S3/AWS credential keys empty or they'll override IRSA and break S3 access.
### Service Mesh (Istio)
Istio has been bumped two minor versions: the `istiod` chart from `1.26.2-rc4` to `1.28.0` (image tags `1.28` → `1.30`), and `istio-ingressgateway` from `1.26.2-rc2` to `1.30.0`. `PeerAuthentication` is no longer enabled by the `istiod` chart directly — it's now managed by the `lilt-networking` chart instead.
### Identity Provider (WSO2 SSO)
* `install-wso2.sh` gained an `ENABLE_WSO2` toggle (default `true`) and the chart was bumped from `7.4.0-3` to `7.4.1-3`, which includes a patch disabling OpenTelemetry auto-instrumentation on the WSO2 pod to avoid a `LinkageError`.
* `EMBEDDED_OIDC_PROVIDER_ENABLED` was flipped from `true` to `false` on `front`, `av-scan`, and `auth-service`.
TODO: assess customer-facing impact of the `EMBEDDED_OIDC_PROVIDER_ENABLED` flip for installs relying on the embedded OIDC provider rather than external WSO2/SSO.
### Deprecation Notice
* `nonInteractiveMqPwd` has been removed from the secrets seed. Installs seeded before this change should manually remove the key from their `secrets.yaml` before upgrading.
* `translatev4` has been disabled; its `/2/translate` routes are now served through Rayman. No customer action is expected, but flag if any override files still reference `translatev4` directly.
* Dead non-interactive RabbitMQ environment variables (`MQ_NON_INTERACTIVE_HOST`, `_PORT`, `_PORT_SSL`, `_USER`, `_PASSWORD`) were removed from all neural service blocks. Customers with these variables in override files can remove them.
### Patch Updates
* `kuberay-operator` bumped from `1.5.1` to `1.6.2`.
* Resource defaults changed for a few pre-existing services, relevant to capacity planning: `converter` memory request 26Gi → 27Gi and memory limit 28Gi → 36Gi; `tm` CPU request 4 → 6 cores; `front`'s 2-core CPU limit was removed (now unbounded); `beehive` gained a new 4-core CPU limit where none existed before. No replica-count changes were found for any pre-existing service. Firewall port requirements and the Flannel CNI chart version (`v0.27.0`) are unchanged.
### Known CVE Issues
| Package | Severity | Component | Fixed In |
| -------------------- | ------------------------- | --------------------------- | -------------------------- |
| libcrypto3 / libssl3 | CRITICAL (CVE-2026-34182) | rayman-artifacts base image | `rayman-artifacts_535c6c4` |
| wget | HIGH (CVE-2026-58469) | rayman-artifacts base image | `rayman-artifacts_535c6c4` |
TODO: a full CVE scan is expected alongside the 6.1.0 release; add any additional findings here.
## 2025
### Patch Updates
The configuration of GPU requirements has changed. Starting with this release, 24GB of VRAM is necessary to run the translate pod successfully.
For customers running on T4 GPUs, this means that the GPU node **must** have at least two (2) T4s attached to it. Put another way, it is **not sufficient** to have two (2) nodes, each with one (1) T4 GPU attached.
## 2024 Q4
### Deprecation Notice
The `analytics-api` application, part of the old analytics implementation, has been officially deprecated and removed.
### Node Labeling
In order to support better utilization of clusters, we have adjusted the way we recommend labeling clusters. [Node Labels](/kb/node-labels) describes the expected labeling of nodes.
### Troubleshooting
Updated the [Troubleshooting](/kb/deleting) guide to include the newly added CLI command to reset the AI models.
### Default Values
Updated resource defaults for services to optimize performance. These changes are documented within [Resource Metrics](/kb/resource-metrics).
### Flannel CNI
Flannel is now a helm chart and included in the overall `install-lilt.sh` script and no longer a separate deployment. If upgrading LILT from a previous version and `flannel `is already installed, comment out the flannel section of the install script:
```bash theme={null}
# install-lilt.sh
# Install flannel, on-prem customers only
kubectl label --overwrite ns kube-flannel pod-security.kubernetes.io/enforce=privileged
sh install_scripts/install-flannel.sh
# wait until pod ready
kubectl wait --namespace kube-flannel --for=condition=ready pod -l app=flannel --timeout=180s
```
If installing `flannel` for the first time via the helm chart, ensure that the `podCidr` is consistent with K8S cluster settings:
```python theme={null}
# flannel/on-prem-values.yaml
flannel:
podCidr: "192.168.100.0/19"
```
### Redis
Memory limits have been implemented to prevent pod restarts/crashes. This ensures that consumed memory does not exceed pod resource limits. Settings for `maxmemory` must be slightly below `pod mem limits`. Memory can be increased if required:
```python theme={null}
# redis/on-prem-values.yaml
global:
redis:
# maxmem needs to be just below resource limit
maxmemory: "5.8gb"
maxmemoryPolicy: "allkeys-lru" # evict least recently used keys
#
master:
resources:
limits:
memory: 6G
```
Persistent storage is now disabled by default. This increases performance and reduces storage requirements.
```cpp theme={null}
# redis/on-prem-values.yaml
master:
persistence:
enabled: false
```
If persistence is required for cache security logging/audit, reenable and ensure that the storage size is sufficient for estimated usage:
```cpp theme={null}
# redis/on-prem-values.yaml
master:
persistence:
enabled: true
size: 20Gi # up to 100Gi for heavy usage
```
### Istio
Additional `kernel`parameters are required to prevent `ztunnel` pod restarts:
```bash theme={null}
# avoid ztunnel container restarts due to load
# append to end of file
cat <> /etc/security/limits.conf
soft nofile 131072
hard nofile 131072
EOF
cat <> /etc/systemd/system.conf
DefaultLimitNOFILE=131072
EOF
```
### Firewall Ports
Additional ports are required for `Istio`, `api`, `Clickhouse`, and `Flannel`. Please ensure that the following are enabled:
```csharp theme={null}
firewall-cmd --permanent --add-port={22,80,443,2379,2380,5000,6443,10250,10251,10252,10255}/tcp
# api
firewall-cmd --permanent --add-port={5005,8011,8080}/tcp
# istio
firewall-cmd --permanent --add-port={15000,15001,15006,15008,15009,15010,15012,15014,15017,15020,15021,15090,15443,20001}/tcp
# flannel
firewall-cmd --permanent --add-port=8472/udp
# clickhouse
firewall-cmd --permanent --add-port=8123/tcp
```
### Containerd
Additional workloads now run on the `GPU` node in parallel with the `Worker` node. If NOT using a centralized repository for all images, ensure that the following are loaded via `containerd` on the `GPU` node:
```powershell theme={null}
pilot*
proxyv2*
install-cni*
ztunnel*
kiali*
flannel* # (only if new install)
k8s-device-plugin*
metrics-server*
neural* # (all neural from docker_images master/node)
llm*
batch*
```
## 2024 Q2
### **Hardware Requirements**
Due to the inclusion of newer models by default, the hardware requirements have changed. [Resource Metrics](/kb/resource-metrics) reflects the additional deployments that need to be considered, and the following recommendations have been updated:
* Master node disk requirement has increased from 200 GB to 500 GB to accommodate for additional container images, configuration, and logging.
* GPU Node instance type updated from `g4dn.2xlarge (8 vCPUs, 32 GB RAM)` to `g4dn.8xlarge (32 vCPUs, 128 GB RAM)`, in order to be able to run the V4 neural services.
* Due to the added models, the hard disk space requirements have been increased. See [Installation Requirements](/kb/install-system-amazon-linux-2023-or-rocky-8-9) for more information.
#### V4 Language Model Updates
As we introduce newer, more accurate language models into LILT, we’ve continually updated our hardware requirements. See [Language Models](/kb/v2-language-models) for the latest in V4 model information. More information can be found in the Knowledge Base around Resource Requirements.
### **Operating System Requirements**
#### CentOS 7 → Rocky Linux 8
New software features of the LILT platform are incompatible with CentOS 7\[1]. All installations still on CentOS 7 should migrate before adopting this release.
Some previous LILT installations were done using CentOS 7, which reached End of Life (EOL) support as of June 30, 2024. The recommended base operating system, and the one being tested in our QA environment, is using Rocky Linux 8. Rocky Linux 8 provides a secure environment similar to CentOS 7, with an End of Life (EOL) support date of May 2029.
#### Istio Module Support
##### Modules
All installations have updated modules needed to support Istio. See the section regarding [kernel modules](/kb/install-system-amazon-linux-2023-or-rocky-8-9) which now includes the following modules to install:
```
overlay
br_netfilter
nf_nat
xt_REDIRECT
xt_owner
iptable_nat
iptable_mangle
iptable_filter
```
These will need to be installed on all existing nodes.
##### Ports
All installations have updated firewall port changes needed to support Istio. See the section regarding [Firewall Settings](/kb/install-system-amazon-linux-2023-or-rocky-8-9) which now includes opening up ports `15000,15001,15006,15008,15009,15010,15012,15014,15017,15020,15021,15090,15443,20001}/tcp` for Istio.
### **Configuration Updates**
#### Custom Domains
New configurations should be done, as described in [Set custom Domain and Certificates](/kb/set-custom-domain-and-certificates) and [Set Connectors Domain](/kb/connector-login-credentials).
#### Upgrading Process
The upgrading process, which involves Helm values files, has been updated for this release to make upgrading simpler in the future. See [Q2 2024 Updates](/kb/upgrade-system#UpgradeSystem-Q22024Updates) for more details.
#### MinIO Resize
In previous releases, the PersistentVolume for MinIO was set to 200GB. With the release of newer models, this is no longer large enough to support them. The default size has been updated from 200GB to 400GB, however, this will not automatically resize existing installations.
If your backing MinIO PersistentVolume is resizable, please resize to 400GB. If it is not able to be resized, the recommended procedure is as follows:
* Back up the MinIO data (if necessary)
* Delete the MinIO PersistentVolumeClaim and PersistentVolume
* Restart the new MinIO deployment
* Restore MinIO data (if necessary)
#### WPA Metrics
WPA metrics, as described in [Generate Evaluation Metrics (WPA, BLEU)](/kb/generate-evaluation-metrics-wpa-bleu) , are now enabled by default.
#### SMTP Notifications
See the new page around configuring SMTP Notifications here: [SMTP Email Notifications](/kb/smtp-email-notifications)
#### Guide on how to handle GPU worker counts
As GPU processing has become increasingly critical in LILT’s models, we’ve added [Configuring GPU Worker Counts in LILT](/kb/configuring-gpu-worker-counts-in-lilt) to assist system administrators in configuring the LILT application for GPU use.
### Vulnerability (CVE) Scan Results
LILT has conducted thorough scans of all services and components to confirm there are no components rated as High or Critical CVEs\[2]. Self-Hosted customers can find further details in the CVE Scan PDF provided with the release.
### **Known Issues**
#### MongoDB Upgrade
The latest MongoDB version has a known [issue](https://github.com/bitnami/charts/issues/27604) that may cause it to fall into a CrashLoop upon upgrading. If this occurs, the recommended fix is as follows:
* Back up the MongoDB data (if necessary)
* Delete the MongoDB PersistentVolumeClaim and PersistentVolume
* Restart the new MongoDB deployment
* Restore MongoDB data (if necessary)
#### Known CVE issues
| **Vulnerability Reference** | **Application** | **Mitigation / Notes** |
| --------------------------- | ------------------- | ----------------------------------------------------------------------------------------------- |
| CVE-2024-31580 | neural | To be fixed in next release, requires upgrade of package that is used by internal dependencies. |
| CVE-2024-31583 | neural | To be fixed in next release, requires upgrade of package that is used by internal dependencies. |
| CVE-2023-6378 | core-api | To be fixed in next release, requires upgrade of package that is used by internal dependencies. |
| CVE-2023-6481 | core-api | To be fixed in next release, requires upgrade of package that is used by internal dependencies. |
| CVE-2024-22257 | core-api | To be fixed in next release, requires upgrade of package that is used by internal dependencies. |
| CVE-2016-1000027 | core-api | To be fixed in next release, requires upgrade of package that is used by internal dependencies. |
| CVE-2024-22243 | core-api | To be fixed in next release, requires upgrade of package that is used by internal dependencies. |
| CVE-2024-22259 | core-api | To be fixed in next release, requires upgrade of package that is used by internal dependencies. |
| CVE-2024-22262 | core-api | To be fixed in next release, requires upgrade of package that is used by internal dependencies. |
| CVE-2023-32697 | core-api | To be fixed in next release, requires upgrade of package that is used by internal dependencies. |
| CVE-2022-1471 | core-api | To be fixed in next release, requires upgrade of package that is used by internal dependencies. |
| CVE-2022-25857 | core-api | To be fixed in next release, requires upgrade of package that is used by internal dependencies. |
| CVE-2024-21634 | core-api | To be fixed in next release, requires upgrade of package that is used by internal dependencies. |
| GHSA-m425-mq94-257g | localpv-provisioner | Vulnerability exists in latest version of this application. Waiting on a newer release to fix. |
| CVE-2024-24790 | localpv-provisioner | Vulnerability exists in latest version of this application. Waiting on a newer release to fix. |
| CVE-2023-39325 | localpv-provisioner | Vulnerability exists in latest version of this application. Waiting on a newer release to fix. |
| CVE-2023-45283 | localpv-provisioner | Vulnerability exists in latest version of this application. Waiting on a newer release to fix. |
| CVE-2023-45287 | localpv-provisioner | Vulnerability exists in latest version of this application. Waiting on a newer release to fix. |
| CVE-2023-45288 | localpv-provisioner | Vulnerability exists in latest version of this application. Waiting on a newer release to fix. |
| CVE-2023-1370 | elasticsearch | Vulnerability exists in latest version of this application. Waiting on a newer release to fix. |
| CVE-2021-40690 | elasticsearch | Vulnerability exists in latest version of this application. Waiting on a newer release to fix. |
| CVE-2022-1471 | elasticsearch | Vulnerability exists in latest version of this application. Waiting on a newer release to fix. |
| CVE-2024-41110 | istiod | Vulnerability exists in latest version of this application. Waiting on a newer release to fix. |
### Appendix
\[1] The Analytics dashboard relies on Istio, which uses some underlying code libraries in the operating system kernel that are not present in CentOS 7.
\[2] Fixed High and Critical CVEs refer to vulnerabilities for which fixes are available and do not break the integration of the application and its dependencies. It should be noted that vulnerabilities are continuously discovered, and new CVEs may have been identified but not yet addressed.
# Inriver PIM
Source: https://support.lilt.com/kb/inriver
[**Inriver PIM**](https://www.inriver.com/) is a Product Information Management platform that serves as a single source of truth for brands, manufacturers, and retailers to centralize, structure, and enrich their product data.
## Overview
Once all configuration parameters are set, the connector will be able to:
* Browse and select Inriver product entities, product types, folders, and fields directly in the LILT job creation page.
* Choose which product attributes to translate, such as names, descriptions, specifications, and other custom fields.
* Create translation jobs from Inriver content using LILT’s standard job setup options, including target languages, due dates, priorities, and workflow settings.
* Save reusable job creation templates for common product groups, field selections, or market/language configurations.
* Translate and review Inriver content in LILT while preserving product structure, field context, formatting, and relationships.
* Track translation progress, sync status, and errors from within LILT, with clear guidance when imports or exports fail.
* Automatically send completed translations back to the correct Inriver fields, with support for draft or published delivery based on your configuration.
## Configuration
1. Starting at the LILT homepage as an Administrator, navigate to *Manage* and then click *Connectors.*
2. Select *Inriver*.
1. If Inriver is not selectable, contact your LILT Solutions Architect for help.
3. In *Setup*, enter your Inriver instance URL and API Key.
4. Click *Test Connection*.
1. If the connection test fails, contact your LILT Solutions Architect for help.
5. Save the configuration.
## Marking Fields as "Do Not Translate"
The connector is built to support your custom data structures in Inriver. If your product data in Inriver contains fields that should not be translated, contact your LILT Solutions Architect to configure these fields. Any fields marked as "Do Not Translate" will be omitted from translation jobs created through the connector and will remain unchanged when finished translations are synced back to the Inriver system.
## Creating Jobs with the Inriver Connector
Once the connector is live, you can create jobs from Inriver directly in the LILT Job Creation page. Clicking the Inriver icon in the file upload box will open a sidebar where you can browse, search, and filter your Inriver content and select files for translation. Finished translations will automatically be delivered back to Inriver.
# Install on an Existing EKS Cluster
Source: https://support.lilt.com/kb/install-aws-existing-cluster
You do not have to use the LILT Terraform module. If you provision AWS resources with your own tooling, or you already have an EKS cluster, the installer works against it as long as the cluster meets the requirements below and you name each resource explicitly in `install.env`.
This article lists what your cluster and account must provide, and how to configure the installer to use resources it did not create. For the Terraform path instead, see [Provision AWS infrastructure with Terraform](/kb/install-aws-terraform-module).
## What Your Cluster Must Provide
### Kubernetes
* Amazon EKS version 1.32 or later.
* The EBS CSI driver, with a StorageClass the installer can use. The installer creates `ebs-gp3` and `ebs-gp3-retain` by default. To use a class you already have, set `STORAGE_CLASS` and `STORAGE_CLASS_RETAIN`, and also set `ENABLE_CLUSTER_PREREQS=false`.
Pointing `STORAGE_CLASS` at your own class without setting `ENABLE_CLUSTER_PREREQS=false` makes Helm take ownership of that class. A later uninstall then deletes it.
* The AWS Load Balancer Controller, or another controller that can provision a Network Load Balancer for the Istio ingress gateway.
* A node group for application workloads. Size it against [Self-managed hardware requirements](/kb/self-managed-hardware-requirements). Give each node at least 300 GB of disk: the neural services pull trained-data images that are tens of gigabytes compressed and roughly double that unpacked.
* Node kernel settings. A raised file-descriptor limit for Istio's ztunnel and `vm.max_map_count` for Elasticsearch are not part of the stock AMI baseline. If you build your own AMI, the Kubernetes baseline is yours to provide too. See [Node kernel settings](/kb/install-system-aws-eks#node-kernel-settings).
* GPU nodes labelled `capability=gpu`, if you run the translation, OCR, review, or speech models. Each GPU node group needs the `nvidia.com/gpu` taint so that only GPU workloads land on it.
### AWS Resources
| Resource | Purpose | Configured with |
| ------------------- | ------------------------------------------------------------- | ---------------------------------- |
| RDS MySQL instance | The application database | `RDS_IDENTIFIER`, `DB_NAME` |
| S3 bucket | Object storage for documents and memories | `S3_BUCKET` |
| SQS queue | Asynchronous work, subscribed to bucket events | `SQS_QUEUE_URL` |
| Container registry | Every LILT image. The node role must be able to pull from it. | `REGISTRY_BASE`, `REGISTRY_PATH_*` |
| Route53 hosted zone | The hostnames LILT serves | `HOSTED_ZONE_ID`, `DNS_DOMAIN` |
The installer reads the RDS master credentials from the AWS Secrets Manager secret that RDS created with the instance. Create your database with a managed master password so that this works without further configuration.
### Registry Access from the Nodes
LILT relies on node-level authentication to pull images, not on per-namespace pull secrets. Attach `AmazonEC2ContainerRegistryReadOnly`, or an equivalent scoped policy, to your node group's IAM role. The LILT Terraform module does this for you; a cluster you built yourself may not have it.
Without it, pods sit in `ImagePullBackOff` with an error that names the image but not the missing permission.
### Workload Identity
Two service-facing roles must exist before you install:
* An **application workload role** with read and write access to your S3 bucket and SQS queue. Set `APP_WORKLOAD_ROLE_NAME` to its name.
* A **Cluster Autoscaler role**, if you run Cluster Autoscaler. Set `CLUSTER_AUTOSCALER_ROLE_NAME` to its name.
Bind each role to its Kubernetes service account with either EKS Pod Identity or IAM Roles for Service Accounts. Pod Identity is the better choice for a new cluster.
Then tell the installer which one you used. `IAM_AUTH_METHOD` defaults to `irsa`:
```bash theme={null}
# install.env
IAM_AUTH_METHOD=pod_identity # or irsa
```
The install scripts find these roles by a substring match on the role **name**, not the ARN. Set the variables to the name only, without the `arn:aws:iam::...:role/` prefix.
Under EKS Pod Identity, leave the service accounts unannotated. An `eks.amazonaws.com/role-arn` annotation overrides the Pod Identity association, and the pod then fails to reach S3 with a credentials error that does not name the annotation.
## Tools on the Install Host
Helm 4, `kubectl`, `aws` CLI v2, and `jq`. Add [crane](https://github.com/google/go-containerregistry) if you populate your registry with `seed-registry.sh`. None of these are installed for you.
Confirm Helm 4 with `helm version --short` before you start. Helm 3 fails partway through the install rather than at the beginning.
## Configure the Install
Copy the template and fill it in. With no `PREFIX` set, the installer takes each identifier from the value you give it and derives nothing.
```bash theme={null}
cp install.env.example install.env
chmod 0600 install.env
```
A minimal bring-your-own configuration:
```bash theme={null}
# Identity and location
SUBDOMAIN=myenv
DNS_DOMAIN=example.com
AWS_REGION=us-east-1
# Pre-existing resources, named explicitly
CLUSTER_NAME=my-eks-cluster
RDS_IDENTIFIER=my-rds-instance
DB_NAME=lilt_dev
S3_BUCKET=my-lilt-bucket
SQS_QUEUE_URL=https://sqs.us-east-1.amazonaws.com/111122223333/my-lilt-queue
SA_NAME=lilt-s3-workload
APP_WORKLOAD_ROLE_NAME=my-app-workload-role
CLUSTER_AUTOSCALER_ROLE_NAME=my-cluster-autoscaler-role
# Registry
REGISTRY_BASE=111122223333.dkr.ecr.us-east-1.amazonaws.com
REGISTRY_PATH_APP=
REGISTRY_PATH_GAR=
REGISTRY_PATH_INFRA=
# TLS, supplied by you
TLS_CRT_FILE=/opt/lilt/certs/lilt.crt
TLS_KEY_FILE=/opt/lilt/certs/lilt.key
# Required. The /connectors-admin console login.
CONNECTORS_ADMIN_PASSWORD=
```
### Registry Paths
A full image reference is `//`. The three path variables exist because LILT's own registry proxies three upstreams, and a mirror of it keeps that layout.
For a plain Amazon ECR registry there is no proxy path. Set all three `REGISTRY_PATH_*` variables to an empty value, as shown above. An empty value is honoured, not replaced with the default, and the reference collapses to `/` with no double slash.
### TLS Certificate
Without the Terraform module and without cert-manager, you supply the certificate. Set `TLS_CRT_FILE` and `TLS_KEY_FILE`, and the installer seeds the `lilt-com-tls` secret once.
The certificate must cover all of these names. They are siblings, not subdomains, so a single `*..` wildcard is not enough:
```
*..
.
core-api-.
connectors-api-.
wso2-.
```
If `ENABLE_VAULT_UI=true`, add the Vault UI host as well. Miss one and browsers look correct while API clients fail hostname verification, which reads as a TLS bug rather than as a missing name.
Do not set `TLS_CRT_FILE` together with `ENABLE_CERT_MANAGER=true`. The installer skips the file-seed step when cert-manager is on, to keep two owners off the same secret.
### DNS Records
Set `ENABLE_DNS=false` if you create DNS records with your own tooling. Point each LILT hostname at the Network Load Balancer that the Istio ingress gateway provisions. Read its address after the install with:
```bash theme={null}
kubectl get svc -n istio-ingressgateway
```
## Turn Off What the Cluster Already Has
The EKS entrypoint never installs the self-hosted infrastructure that the on-premises flavor brings, so there is nothing to disable for networking, storage, or load balancing.
Set these to `false` for anything your cluster already runs, so that the installer does not install a second copy:
| Variable | Component |
| ---------------------------- | ---------------------------- |
| `ENABLE_CLUSTER_AUTOSCALER` | Cluster Autoscaler |
| `ENABLE_METRICS_SERVER` | metrics-server |
| `ENABLE_PROMETHEUS` | Prometheus |
| `ENABLE_CERT_MANAGER` | cert-manager |
| `ENABLE_NVIDIA_GPU_OPERATOR` | NVIDIA GPU Operator |
| `ENABLE_CLUSTER_PREREQS` | The `ebs-gp3` StorageClasses |
The `enable_cloudwatch_observability` EKS add-on injects OpenTelemetry auto-instrumentation into every pod through `NODE_OPTIONS`. MongoDB's health probes shell out to `mongosh`, which is a Node.js program, so each probe loads the agent, exceeds its 5-second timeout, and pushes the container past its memory limit into a restart loop. If you run that add-on, raise the MongoDB container's memory limit or exclude the `lilt` namespace from injection.
## Install
```bash theme={null}
sh install-lilt-eks.sh 2>&1 | tee /var/log/lilt-install.log
```
If your cluster's API endpoint is private, run this from inside the VPC. See [Install from a bastion](/kb/install-from-a-bastion).
The rest of the process, including phased bring-up, secrets, verification, and recovering from a failed component, is the same on both paths. See [Install System (AWS EKS)](/kb/install-system-aws-eks).
# Provision AWS Infrastructure with Terraform
Source: https://support.lilt.com/kb/install-aws-terraform-module
The EKS install package ships a Terraform module, `lilt-aws-env`, that provisions the AWS infrastructure LILT runs on. This article covers what the module creates, how to configure it, and how to map its outputs into the installer's configuration.
You do not need access to any LILT source repository. The module is a plain local module inside the tarball.
## The Two Layers
An EKS deployment has two layers, and they run in order:
1. **`lilt-aws-env`** provisions the AWS resources: subnets, the EKS cluster and its node groups, the RDS database, the S3 bucket, the SQS queue, and the IAM roles the workloads assume.
2. **`install-lilt-eks.sh`** deploys LILT onto that cluster with Helm. See [Install System (AWS EKS)](/kb/install-system-aws-eks).
If you already have a cluster, or you provision AWS resources with your own tooling, skip this article and see [Install on an existing EKS cluster](/kb/install-aws-existing-cluster) instead.
## Prerequisites
### Tools
| Tool | Minimum version | Notes |
| --------- | --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| Terraform | 1.10 | The module declares `required_version = ">= 1.10"`. `terraform init` fails on an earlier version. OpenTofu of an equivalent version also works. |
| AWS CLI | 2.x | Must resolve credentials for the target account. Version 1 is not sufficient. |
| `kubectl` | Matching the cluster Kubernetes version | |
| Helm | 4.0 | The installer requires Helm 4. |
### AWS
* An IAM role or user that can create EKS, RDS, S3, SQS, IAM, KMS, and Route53 resources in the target account.
* A VPC with at least one NAT gateway. The module creates subnets inside your VPC. It does not create the VPC.
* Two non-overlapping CIDR blocks available in that VPC for the module's private subnets. A `/22` in each of two availability zones is a reasonable starting point.
* A Route53 hosted zone for your base domain.
## What the Module Creates
| Area | Resources |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Networking | Private subnets in two availability zones, a route table pointing at your NAT gateway, and a network ACL that isolates east-west traffic. |
| EKS | The cluster with a private API endpoint, the VPC CNI, CoreDNS, kube-proxy, EBS CSI driver and Pod Identity agent add-ons, and the `system` and `application` managed node groups. |
| GPU | Four GPU node groups by default. See [GPU node groups](#gpu-node-groups). |
| Database | An RDS MySQL instance, KMS-encrypted, with an AWS-managed master password held in Secrets Manager. The password is never written to Terraform state. |
| Storage and queueing | A versioned, KMS-encrypted S3 bucket and an SQS queue subscribed to its events. |
| IAM | Roles for the application workloads, Cluster Autoscaler, ExternalDNS, cert-manager, and the AWS Load Balancer Controller. |
| DNS | A Route53 ownership record for ExternalDNS. |
| Optional | A bastion host, VPC endpoints, an ECR repository, Karpenter prerequisites, and an ACME wildcard certificate. |
## Instantiate the Module
Create a `terraform/` directory next to the extracted tarball, so that the relative module path resolves:
```
/opt/lilt/
├── install-lilt-eks.sh
├── terraform-modules/
│ └── lilt-aws-env/
└── terraform/
└── main.tf # you create this
```
Every variable without a default is required. The following example sets the required variables plus the ones most deployments tune:
```hcl theme={null}
module "lilt_env" {
source = "../terraform-modules/lilt-aws-env"
# Identity. Every resource name derives from prefix.
prefix = "acme-prod"
subdomain = "prod"
base_domain = "example.com"
# Networking, from your own VPC layer.
vpc_id = "vpc-0abc123def456789a"
vpc_cidr = "10.20.0.0/16"
nat_gateway_id = "nat-0abc123def456789a"
az_a = "us-east-1a"
az_b = "us-east-1b"
module_cidr_a = "10.20.80.0/22"
module_cidr_b = "10.20.84.0/22"
shared_cidrs = ["10.20.0.0/24"]
# Who administers the cluster. Omitting yourself locks you out.
eks_cluster_admin_arns = {
"operators" = "arn:aws:iam::111122223333:role/lilt-operators"
}
# DNS.
r53_hosted_zone_id = "Z0EXAMPLE1234567890"
# Database. Set rds_multi_az to true for production.
rds_instance_class = "db.r6g.large"
rds_allocated_storage = 100
rds_multi_az = true
# Node sizing.
eks_application_instance_types = ["r6i.2xlarge", "r5.2xlarge"]
eks_application_min_size = 2
eks_application_max_size = 8
eks_application_volume_size = 300
# Run the installer from inside the VPC. The EKS endpoint is private.
enable_bastion = true
}
```
Then run:
```bash theme={null}
cd terraform
terraform init
terraform plan
terraform apply
```
`eks_bootstrap_creator_admin` has no default, and AWS treats an unset value as `false`. The cluster is then reachable only by the principals listed in `eks_cluster_admin_arns` and by the bastion. If you leave both empty, every `kubectl` call returns a 401 and there is no way back in. Confirm that `eks_cluster_admin_arns` contains a role you can assume before you apply.
## Required Variables
| Variable | Type | Purpose |
| ------------------------ | ------------ | -------------------------------------------------------------------------------- |
| `prefix` | string | Prefix for every resource name. The installer's `PREFIX` variable must match it. |
| `vpc_id` | string | The VPC to create subnets in. |
| `vpc_cidr` | string | That VPC's CIDR block. |
| `nat_gateway_id` | string | The NAT gateway the private route table points at. |
| `shared_cidrs` | list(string) | CIDRs the network ACL allows through. |
| `eks_cluster_admin_arns` | map(string) | Name to IAM role ARN. Each role gets cluster-admin. |
| `r53_hosted_zone_id` | string | The Route53 zone for `base_domain`. |
## Commonly Tuned Variables
| Variable | Default | Notes |
| -------------------------------- | ------------------------------ | ------------------------------------------------------------------------------------- |
| `subdomain` | `prefix` | Hostnames become `-.`. |
| `base_domain` | `""` | Your base domain, for example `example.com`. |
| `az_a`, `az_b` | The region's first two zones | Set these explicitly if you care which zones you land in. |
| `module_cidr_a`, `module_cidr_b` | `""` | Required when `create_subnets` is `true`, which is the default. |
| `create_subnets` | `true` | Set to `false` and supply `existing_subnet_ids` to bring your own subnets. |
| `eks_version` | `"1.35"` | |
| `eks_system_instance_types` | `["m6i.large","m6i.xlarge"]` | Runs kube-system, Istio, and monitoring. |
| `eks_application_instance_types` | `["r6i.2xlarge","r5.2xlarge"]` | Qdrant alone requests 4 CPU, which does not fit a 4-vCPU node's allocatable capacity. |
| `eks_application_volume_size` | `100` | Raise this. See the warning that follows. |
| `rds_instance_class` | `"db.r6g.large"` | |
| `rds_engine_version` | `"8.0"` | MySQL 8.0 reaches the end of RDS standard support on 31 July 2026. Consider `"8.4"`. |
| `rds_multi_az` | `false` | Set to `true` for production. |
| `iam_auth_method` | `"pod_identity"` | See [Workload identity](#workload-identity). |
| `enable_bastion` | `false` | |
| `enable_cluster_autoscaler` | `true` | |
| `enable_cert_manager` | `false` | The IAM role only. The controller is installed by `install-lilt-eks.sh`. |
| `enable_external_dns` | `false` | |
| `enable_ecr` | `false` | Creates one ECR repository named after `prefix`. |
| `enable_vpc_endpoints` | `false` | Set to `true` for a deployment with no route to the public internet. |
Raise `eks_application_volume_size` above its `100` GB default. The neural services pull trained-data images that are tens of gigabytes compressed and roughly double that unpacked, so 100 GB cannot hold one. The pull fails part way through with `no space left on device`. A 300 GB volume is a safe starting point.
## GPU Node Groups
`eks_extra_node_groups` defaults to the four GPU pools LILT needs. LILT spreads its GPU workloads across all four, and a partial set fails in a way that does not name itself: `batch-worker-gpuv4` stays `Pending`, and the neural services block on the artifacts endpoint it serves rather than reporting a GPU shortage.
| Pool | Instance type | GPUs | Serves |
| -------------- | --------------- | -------- | --------------------------------------- |
| `gpu-multi` | `g4dn.12xlarge` | 4 x T4 | AI Review and LILT Create |
| `gpu-vram` | `g6e.4xlarge` | 1 x L40S | OCR and the larger single-GPU models |
| `gpu-standard` | `g6.12xlarge` | 4 x L4 | Translation, VMF, and the batch workers |
| `gpu-whisper` | `g4dn.2xlarge` | 1 x T4 | Speech recognition |
Each pool carries the `nvidia.com/gpu` taint and the `capability: gpu` label that the LILT charts select on.
Four warm GPU nodes are expensive. To let the autoscaler bring each pool up on demand, set `min_size` to `0` for the pools you want cold. Cluster Autoscaler is enabled by default, which is what makes a group at zero discoverable. For an infrastructure-only deployment with no GPU workloads, set `eks_extra_node_groups = {}`.
Widen `availability_zones` on each GPU pool. The default is empty, which places every pool in the cluster's own two zones. GPU instance types are frequently capacity-constrained per zone: a `g6.12xlarge` request can return `InsufficientInstanceCapacity` in both zones, and the group has nowhere else to go. Listing every zone in the region for each pool avoids this. The field is replace-forcing, so set it before your first apply.
Setting `eks_extra_node_groups` replaces the default map wholesale rather than merging into it, so list every pool you want, not only the one you are changing. The block below is the shipped default with `availability_zones` added to each pool. Substitute the zones your region offers.
```hcl theme={null}
locals {
# Every zone in the region, so a GPU pool has somewhere else to go when one
# zone is out of capacity.
gpu_azs = ["us-east-1a", "us-east-1b", "us-east-1c", "us-east-1d", "us-east-1f"]
gpu_labels = {
"node-type" = "gpu"
"capability" = "gpu"
"nvidia.com/gpu.present" = "true"
}
gpu_taints = [{ key = "nvidia.com/gpu", value = "true", effect = "NO_SCHEDULE" }]
}
eks_extra_node_groups = {
# 4x T4, 48 vCPU, 192 GiB - AI Review and LILT Create.
"gpu-multi" = {
instance_types = ["g4dn.12xlarge"]
min_size = 1
max_size = 2
volume_size = 2000
gpu = true
cluster_autoscaler = true
availability_zones = local.gpu_azs
labels = merge(local.gpu_labels, { "gpu-class" = "multi" })
taints = local.gpu_taints
}
# 1x L40S, 48 GiB VRAM - OCR and the larger single-GPU models.
"gpu-vram" = {
instance_types = ["g6e.4xlarge"]
min_size = 1
max_size = 2
volume_size = 2000
gpu = true
cluster_autoscaler = true
availability_zones = local.gpu_azs
labels = merge(local.gpu_labels, { "gpu-class" = "vram" })
taints = local.gpu_taints
}
# 4x L4, 48 vCPU, 192 GiB - translation, vmf and the batch workers.
"gpu-standard" = {
instance_types = ["g6.12xlarge"]
min_size = 1
max_size = 2
volume_size = 2000
gpu = true
cluster_autoscaler = true
availability_zones = local.gpu_azs
labels = merge(local.gpu_labels, { "gpu-class" = "standard" })
taints = local.gpu_taints
}
# 1x T4, 8 vCPU, 32 GiB - speech recognition.
"gpu-whisper" = {
instance_types = ["g4dn.2xlarge"]
min_size = 1
max_size = 2
volume_size = 1000
gpu = true
cluster_autoscaler = true
availability_zones = local.gpu_azs
labels = merge(local.gpu_labels, { "gpu-class" = "whisper" })
taints = local.gpu_taints
}
}
```
The `gpu-class` label is what the LILT charts select on, so each pool needs its own value. The root volumes are large because the neural services pull trained-data images of tens of gigabytes.
To let the autoscaler bring a pool up only when something needs it, set that pool's `min_size` to `0`. `cluster_autoscaler = true` is what makes a group at zero discoverable.
## Workload Identity
`iam_auth_method` selects how pods obtain AWS credentials.
| Value | Mechanism |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------- |
| `pod_identity` (default) | EKS Pod Identity. The module creates a Pod Identity association for each service account and no OIDC provider. |
| `irsa` | IAM Roles for Service Accounts. The module creates an OIDC provider and roles that trust `sts:AssumeRoleWithWebIdentity`. |
Use `pod_identity` for a new environment. Use `irsa` only when something in your environment already depends on OIDC federation.
**The module and the installer default to different values. Set both.** The module's `iam_auth_method` defaults to `pod_identity`, but the installer's `IAM_AUTH_METHOD` defaults to `irsa`. Left at their defaults, the module creates Pod Identity associations and no OIDC provider, and the installer then annotates the service accounts with `eks.amazonaws.com/role-arn` anyway. The annotation wins over the association, the SDK looks for a web identity provider that the account does not have, and every S3 call fails with a credentials error that mentions none of this.
Set `IAM_AUTH_METHOD` in `install.env` to the same value as the module's `iam_auth_method`:
```bash theme={null}
# install.env - must match the module's iam_auth_method
IAM_AUTH_METHOD=pod_identity
```
Under `pod_identity`, leave the service accounts unannotated. The installer does that for you once `IAM_AUTH_METHOD` is set correctly.
## Read the Outputs
```bash theme={null}
terraform output -json
```
| Output | Maps to |
| ----------------------------- | ----------------------------------------------------------- |
| `cluster_name` | `CLUSTER_NAME` |
| `bucket_name` | `S3_BUCKET` |
| `queue_url` | `SQS_QUEUE_URL` |
| `subdomain` | `SUBDOMAIN` is the label before the first dot. |
| `app_workload_role_arn` | `APP_WORKLOAD_ROLE_NAME`, the role name from the ARN. |
| `cluster_autoscaler_role_arn` | `CLUSTER_AUTOSCALER_ROLE_NAME`, the role name from the ARN. |
| `cert_manager_role_arn` | `CERT_MANAGER_ROLE_NAME`, the role name from the ARN. |
| `rds_master_secret_arn` | Read by `install-rds-secrets.sh`. No configuration needed. |
| `rds_endpoint`, `rds_port` | Informational. |
| `ecr_repository_url` | The registry to seed, when `enable_ecr` is `true`. |
| `bastion_instance_id` | The instance to run the installer from. |
The install scripts find IAM roles by a substring match on the role **name**, not the ARN. Take the part after the last slash: `arn:aws:iam::111122223333:role/acme-prod-app-workload` becomes `acme-prod-app-workload`.
### The PREFIX Shortcut
If you set `PREFIX` in `install.env` to the same value as the module's `prefix`, the installer derives these names and you can leave them unset:
* `CLUSTER_NAME` becomes `-eks`
* `RDS_IDENTIFIER` becomes `-rds`
* `S3_BUCKET` becomes `-s3`
* `SQS_QUEUE_URL` becomes `https://sqs..amazonaws.com//-sqs`
* `APP_WORKLOAD_ROLE_NAME` becomes `-app-workload`
* `CLUSTER_AUTOSCALER_ROLE_NAME` becomes `-cluster-autoscaler`
* `CERT_MANAGER_ROLE_NAME` becomes `-cert-manager-role`
## Certificate Ownership
Both the module and the installer can obtain a TLS certificate, and both write the same `lilt-com-tls` secret. Pick one.
* Set `enable_tls_certificate = true` in the module to run an ACME DNS-01 challenge against your Route53 zone and store the certificate in Vault. Leave `ENABLE_CERT_MANAGER=false` in `install.env`.
* Or leave the module's flag at `false` and set `ENABLE_CERT_MANAGER=true` in `install.env`, which makes cert-manager the permanent owner of the secret.
Enabling both makes the two owners compete for the same Let's Encrypt identifier set, which is rate-limited to five certificates per 168 hours. You lose the week.
Whichever path you choose, the certificate must cover every LILT hostname. The hostnames are siblings, not subdomains, so a `*..` wildcard does not cover them. The full list is in `install.env.example`, and it includes `core-api-`, `connectors-api-`, and `wso2-` prefixed names. If you miss one, browsers look correct while API clients fail hostname verification, which reads as a TLS bug rather than as a missing name.
## Version Pinning
The module is vendored into the tarball at a single commit. Read `terraform-modules/lilt-aws-env/PROVENANCE.md` in the extracted tarball to see which commit shipped with your release.
To source the module from a location of your own, copy the `terraform-modules/lilt-aws-env` directory wherever suits your layout and point `source` at it. Pin by commit rather than by branch so that a given apply is reproducible.
## Known Constraints
* `eks_service_cidr` defaults to empty, which lets AWS pick `10.100.0.0/16`. Changing this value later replaces the cluster. Pin it before your first apply if you might ever need a different range.
* `enable_karpenter = true` creates the AWS prerequisites, the IAM role and the SQS interruption queue. It does not install the Karpenter controller.
* Let's Encrypt limits you to five certificates per identifier set per 168 hours. Repeated rebuilds of the same environment exhaust that quota.
## Next Steps
* [Install from a bastion](/kb/install-from-a-bastion) — the module gives the cluster a private API endpoint, so the installer runs from inside the VPC.
* [Install System (AWS EKS)](/kb/install-system-aws-eks) — configure `install.env` and run the install.
# install.env Reference
Source: https://support.lilt.com/kb/install-env-reference
`install.env` holds every setting the installer reads. Copy `install.env.example` to `install.env`, uncomment what you need, and leave the rest alone to keep the defaults.
```bash theme={null}
cp install.env.example install.env
chmod 0600 install.env
```
The file is sourced by both entrypoints and exported to every component script. It is git-ignored. Never commit it: it holds credentials.
This page is a lookup table. For the reasoning behind a group of settings, follow the links in each section.
## Identity
Set these first. Every resource name and hostname derives from them.
| Variable | Default | Purpose |
| ---------------- | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| `SUBDOMAIN` | none, **required** | Environment subdomain. Hostnames become `-.`. |
| `DNS_DOMAIN` | none, **required** | Base domain. Required on both flavors. |
| `PREFIX` | unset | Terraform resource prefix. Setting it derives `CLUSTER_NAME`, `RDS_IDENTIFIER`, `S3_BUCKET`, `SQS_QUEUE_URL` and the `*_ROLE_NAME` values. |
| `AWS_REGION` | `us-east-1` | Region for the S3 endpoint and SQS URL. |
| `AWS_ACCOUNT_ID` | from `aws sts get-caller-identity` | Used to build resource ARNs. |
| `AWS_PROFILE` | the default profile | AWS CLI named profile. |
## Pre-existing Resources
Set these when your infrastructure does not follow the `-` naming. Each one bypasses the derived lookup.
| Variable | Default | Purpose |
| ------------------------------ | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `CONNECTORS_ADMIN_PASSWORD` | none, **required** in seed mode | Login for the `/connectors-admin` console. The install fails loudly if unset. Under an ESO backend it comes from your secret store instead. |
| `CLUSTER_NAME` | `-eks` | EKS cluster to target. |
| `RDS_IDENTIFIER` | `-rds` | RDS instance lookup key. |
| `DB_NAME` | `lilt_dev` | Application database. |
| `S3_BUCKET` | `-s3` | Object storage bucket. |
| `SQS_QUEUE_URL` | derived from region, account and prefix | Queue for asynchronous work. |
| `SA_NAME` | `lilt-s3-workload` | Service account granted S3 access. |
| `MONGO_PASS` | `dummypass` | MongoDB `lilt` user password. Change it. |
| `APP_WORKLOAD_ROLE_NAME` | `-app-workload` | IAM role name, matched as a substring. |
| `CLUSTER_AUTOSCALER_ROLE_NAME` | `-cluster-autoscaler` | IAM role name for Cluster Autoscaler. |
| `CERT_MANAGER_ROLE_NAME` | `-cert-manager-role` | IAM role name for cert-manager. |
| `IAM_AUTH_METHOD` | `irsa` | `irsa` or `pod_identity`. Must match how your roles are bound. See [Provision AWS infrastructure with Terraform](/kb/install-aws-terraform-module#workload-identity). |
## DNS and TLS
See [Set custom domain and certificates](/kb/set-custom-domain-and-certificates) for the hostname list and the required certificate names.
| Variable | Default | Purpose |
| --------------------- | ------- | -------------------------------------------------------------------------------------------------------- |
| `HOSTED_ZONE_ID` | unset | Route53 zone for `DNS_DOMAIN`. |
| `ENABLE_DNS` | `false` | Create Route53 records. Needs `HOSTED_ZONE_ID` and Route53 write access. |
| `ENABLE_CERT_MANAGER` | `false` | Issue the certificate with cert-manager over Route53 DNS-01. |
| `TLS_CRT_FILE` | unset | Path to your PEM chain. Must not be set together with `ENABLE_CERT_MANAGER=true`. |
| `TLS_KEY_FILE` | unset | Path to the matching private key. |
| `LB_IP` | unset | On-premises only. The address MetalLB hands the ingress gateway. Required when `ENABLE_METALLB` is true. |
## Image Registry
A full image reference is `//`. See [Install package](/kb/install-package).
| Variable | Default | Purpose |
| ---------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `REGISTRY_BASE` | `harbor..` on EKS | The registry host to pull from. |
| `REGISTRY_PATH_APP` | `proxy-gcr/lilt-service-48916b30` | Path segment for most application images. Set empty for plain ECR. |
| `REGISTRY_PATH_GAR` | `proxy-gar-core/lilt-service-48916b30` | Path segment for core images. Set empty for plain ECR. |
| `REGISTRY_PATH_INFRA` | `proxy-gar-core/lilt-service-48916b30/chainguard/lilt.com` | Path segment for infrastructure base images. Set empty for plain ECR. |
| `CHART_BASE` | an OCI registry URL | Helm chart source. **Set this to an absolute path such as `/opt/lilt/charts` to install from the charts in the tarball.** |
| `CHART_REGISTRY_BASE` | `us-central1-docker.pkg.dev/lilt-service-48916b30` | Host and project behind the default `CHART_BASE`. |
| `STORAGE_CLASS` | `ebs-gp3` on EKS, `openebs-hostpath` on-premises | StorageClass every stateful component requests. |
| `STORAGE_CLASS_RETAIN` | `-retain` | Retaining variant. |
`NVCR_REGISTRY` and `K8S_REGISTRY` default to routing through `REGISTRY_BASE` like every other image. Setting them explicitly to `nvcr.io` or `registry.k8s.io` makes those components pull straight from the public internet, which breaks an air-gapped install. Leave them unset unless you know you want that.
Pointing `STORAGE_CLASS` at a class you already have, without also setting `ENABLE_CLUSTER_PREREQS=false`, makes Helm take ownership of it. A later uninstall then deletes it.
## Registry Seeding
Off by default. See [Seed your container registry](/kb/install-package#seed-your-container-registry).
| Variable | Default | Purpose |
| ---------------------------- | ------------------- | --------------------------------------------------- |
| `ENABLE_SEED_REGISTRY` | `false` | Run `seed-registry.sh` as part of the install. |
| `SEED_REGISTRY_RELEASE` | unset | Extracted release directory, or an `s3://` prefix. |
| `SEED_REGISTRY_TARGET` | `REGISTRY_BASE` | Destination registry. |
| `SEED_REGISTRY_PATH` | `REGISTRY_PATH_APP` | Destination path segment. |
| `SEED_REGISTRY_APPLY` | `false` | `true` pushes. `false` only reports. |
| `SEED_REGISTRY_WORK_DIR` | `/var/tmp` | Staging directory. Must be on real disk, not tmpfs. |
| `SEED_REGISTRY_FORCE` | `false` | Re-push images the registry already has. |
| `SEED_REGISTRY_CREATE_REPOS` | `true` | Create each ECR repository before its first push. |
## Feature Toggles
Each component self-gates on its own flag. See [Install System (AWS EKS)](/kb/install-system-aws-eks#component-flags) for the full list and the dependency warnings.
**On-premises infrastructure**, all default `true`. Set to `false` on a managed cluster that brings its own.
| Variable | Component |
| ---------------------------- | ------------------------------------------- |
| `ENABLE_FLANNEL` | Flannel CNI |
| `ENABLE_LOCALPV_PROVISIONER` | Local persistent-volume provisioner |
| `ENABLE_METALLB` | MetalLB. Off means `LB_IP` is not required. |
| `ENABLE_MINIO` | MinIO object storage |
| `ENABLE_MYSQL` | In-cluster MySQL |
**GPU**
| Variable | Default | Purpose |
| ----------------------------- | ------------------------------------ | -------------------------------------------------------------------------------------- |
| `ENABLE_NVIDIA_GPU_OPERATOR` | `true` on EKS, `false` on-premises | Install the NVIDIA GPU Operator. |
| `ENABLE_NVIDIA_DEVICE_PLUGIN` | the inverse of the GPU Operator flag | Standalone device plugin, for clusters not using the operator. |
| `NVIDIA_DRIVER_ENABLED` | unset | Let the GPU Operator manage the driver. Changes node runtime configuration. |
| `NVIDIA_TOOLKIT_ENABLED` | unset | Let the GPU Operator manage the container toolkit. Changes node runtime configuration. |
GPU sizing is not set here. See [GPU profiles and values overlays](/kb/gpu-profiles-and-values-overlays).
## Notifications
`notification-core` sends transactional email, such as assignment and review-request notifications. It is off by default, and the SMTP values it ships with are placeholders rather than a working relay. Supply your own relay details and verify that mail is delivered before you enable it.
| Variable | Default | Purpose |
| ------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| `NOTIFICATIONS_SERVICE_ENABLED` | `false` | Deploy `notification-core`. |
| `SMTP_HOST` | a placeholder | Your relay host. The shipped value does not resolve on a customer install. |
| `SMTP_PORT` | `1025` | Your relay port. |
| `SMTP_USERNAME` | unset | Relay user. Note the name: `SMTP_USERNAME`, not `SMTP_USER`. |
| `SMTP_PASSWORD` | unset | Relay password. Seed mode only; under an ESO backend it comes from ``, property `smtp_password`, and this variable is ignored. |
| `DEFAULT_SENDER_EMAIL` | a test address | The `From:` address on outbound mail. |
| `NOTIFICATION_DOMAIN` | empty | Host used to build links inside emails. Empty renders links with no host, so set it to your front origin. |
| `WHITE_LIST_EMAIL_DOMAINS` | empty | Comma-separated recipient domain allow-list. |
| `MAILER_PROVIDER` | derived | `front`'s mailer: `smtp`, `sendgrid`, or empty. Defaults to `smtp` when notifications are enabled. |
An empty `WHITE_LIST_EMAIL_DOMAINS` means **send to everyone**, not block everyone. The service treats an empty list as no restriction. Set it on any non-production install, or a test run mails real customers.
In seed mode the installer inlines `SMTP_PASSWORD` into YAML with `awk`, so a password containing a double quote, a backslash, or a newline corrupts the file. Use a secret backend for passwords like that.
Setting `MAILER_PROVIDER=smtp` explicitly makes `front` send even when notifications are disabled, because its SMTP path ignores the enable flag. Set `SMTP_HOST` too, or it dials the placeholder host and mail silently goes nowhere.
## Secret Backend
See [Secrets and Vault](/kb/secrets-and-vault) for the full path and key inventory.
| Variable | Default | Purpose |
| -------------------- | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `SECRET_BACKEND` | `seed` | `seed`, `vault`, or `aws`. No effect on the on-premises flavor. |
| `BASE_VAULT_PATH` | `lilt/bare/aws` | Prefix every secret lives under. |
| `_SECRET_PATH` | derived from the base | Relocate one secret. `MYSQL_`, `MONGODB_`, `RABBITMQ_`, `CACHE_REDIS_`, `CLICKHOUSE_`, `DATADOG_`, `RDS_CA_`, `AUTH_`, `API_KEYS_`, `CONNECTORS_`, `SMTP_`, `LILT_SECRETS_`. |
## In-cluster Vault
| Variable | Default | Purpose |
| ---------------------------- | ----------------------------------- | ---------------------------------------------------------------------------------- |
| `ENABLE_VAULT` | `true` | Install the shipped Vault as the ESO backend. |
| `ENABLE_VAULT_BOOTSTRAP` | `true` | Initialise, unseal, and wire ESO. Set `false` to manage it yourself. |
| `VAULT_SEAL_MODE` | `awskms` on EKS, `shamir` elsewhere | Auto-unseal or manual. Use `shamir` for AWS without KMS. |
| `VAULT_SEAL_KMS_KEY_ID` | `alias/-vault-unseal` | KMS key for auto-unseal. |
| `VAULT_UNSEAL_ROLE_NAME` | `-vault-unseal-role` | IAM role for the Vault service account. |
| `VAULT_KV_MOUNT` | `lilt` | KV v2 mount path. |
| `VAULT_ESO_ROLE` | `eso` | Vault Kubernetes auth role bound to the ESO service account. |
| `VAULT_AUTH` | `kubernetes` | `kubernetes` for the in-cluster Vault, `approle` for your own. |
| `ENABLE_VAULT_UI` | `false` | Publish the Vault UI on its own hostname. |
| `VAULT_UI_HOST` | `vault..` | That hostname. Needs a DNS record and certificate coverage. |
| `VAULT_CHART_VERSION` | set by the installer | Override the wrapper chart version. |
| `ONBOARD_VAULT_PLACEHOLDERS` | `false` | Seed placeholder entries during the install so ESO can sync against a fresh Vault. |
| `VAULT_TOKEN` | unset | Write token, required only when onboarding placeholders. |
| `VAULT_K8S_NAMESPACE` | `vault` | Namespace of the in-cluster Vault. |
| `VAULT_K8S_SERVICE` | `vault` | Service name of the in-cluster Vault. |
## External Vault
This section applies only if you already run your own HashiCorp Vault and want LILT to read its secrets from it, instead of from the Vault that ships in the tarball. If you are using the shipped one, skip this section entirely: it authenticates with a Kubernetes service account token and needs none of these settings.
To use your own Vault, set three things:
```bash theme={null}
# install.env
ENABLE_VAULT=false # do not deploy the shipped Vault
SECRET_BACKEND=vault # read secrets through External Secrets Operator
VAULT_AUTH=approle # authenticate to your Vault with AppRole
VAULT_ADDR=https://vault.example.com
```
| Variable | Default | Purpose |
| ------------ | ------- | --------------------------------------------- |
| `VAULT_ADDR` | unset | Your Vault server URL. Required on this path. |
Set `ENABLE_VAULT=false` as well. The shipped Vault and your own are mutually exclusive, and two secret stores of the same name must never be active on one cluster.
### The AppRole Credentials
The AppRole role ID and secret ID are deliberately not `install.env` variables. There are no `VAULT_ROLE_ID` or `VAULT_SECRET_ID` settings, and no install script reads them from the environment, so they never pass through a file that could be committed or a shell that logs its arguments.
Instead, External Secrets reads them from a Kubernetes Secret named `vault-approle` in the `external-secrets` namespace. Create it before you run the installer:
```bash theme={null}
kubectl create namespace external-secrets --dry-run=client -o yaml | kubectl apply -f -
kubectl create secret generic vault-approle \
--namespace external-secrets \
--from-literal=role-id= \
--from-literal=secret-id=
```
The key names matter: `role-id` and `secret-id`. The installer never creates this Secret and stops with an error if it is missing.
The AppRole you use needs read access to every path in the secret inventory. See [Secrets and Vault](/kb/secrets-and-vault#what-vault-must-contain).
## Advanced
Escape hatches. Do not set these without a reason.
| Variable | Default | Purpose |
| ------------------------ | ------------------------ | ------------------------------------------------------------- |
| `ENV_NAME` | `lilt` | The chart custom-values directory under `lilt/environments/`. |
| `ALLOW_RELEASE_DELETE` | `false` | Let the installer delete a stuck Helm release. |
| `SKIP_BOOTSTRAP` | unset | Skip the database bootstrap step. |
| `NODE_TYPE` | `application` | Node-selector value for application pods. |
| `TLS_CERT_PASSWORD_FILE` | `/certs/client/password` | Path to the Java truststore password file. |
| `CLOUDENV` | `on-prem` | Runtime environment label. Documentation only. |
## Related Articles
* [Install System (AWS EKS)](/kb/install-system-aws-eks)
* [Install package](/kb/install-package)
* [Secrets and Vault](/kb/secrets-and-vault)
* [Set custom domain and certificates](/kb/set-custom-domain-and-certificates)
* [GPU profiles and values overlays](/kb/gpu-profiles-and-values-overlays)
# Install from a Bastion
Source: https://support.lilt.com/kb/install-from-a-bastion
`install-lilt-eks.sh` has to run somewhere that can reach the Kubernetes API. When the EKS endpoint is private, which is the default for clusters created by the `lilt-aws-env` Terraform module, an operator's laptop has no such route. The install runs from a small EC2 instance inside the VPC instead.
This article covers what that machine needs: the tools, the IAM permissions, and the order to do things in.
The Terraform module creates the instance when you set `enable_bastion = true`. Your own jump host works equally well. Nothing here depends on the module having created it.
## Why a Bastion
* **The EKS API is private.** `helm`, `kubectl`, and every install script need to reach it.
* **Seeding the registry moves a lot of data.** `seed-registry.sh` pushes about 180 GB of images into your registry. From inside the VPC that traffic stays on the AWS network. From a laptop it crosses your uplink twice.
* **The install takes hours.** A long-running unit on an instance survives a closed laptop lid.
## Sizing
Give the instance a root volume with room for the largest image in the release, which is roughly 47 GB. A 120 GB volume is comfortable. `seed-registry.sh` streams one image at a time, so it does not need room for all 180 GB at once.
## Tools
Install these before you start. The installer does not install them for you, and a missing tool usually surfaces late, after an hour of successful steps.
| Tool | Version | Why |
| ------------- | ---------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| AWS CLI | 2.x | Every script that touches AWS. Version 1 is not sufficient. |
| `kubectl` | Matching the cluster minor version | Applies manifests and waits on rollouts. |
| Helm | 4.x | `get-helm-4` installs the current Helm 4. The shipped charts use OCI features and flags Helm 3 does not have. |
| `crane` | 0.22 or later | `seed-registry.sh` copies images with it and does not install it. |
| `jq` | Any | Parsing AWS and Kubernetes JSON. |
| `tar`, `gzip` | Any | Unpacking the release tarball. |
| `openssl` | Any | Only if you seed a TLS certificate yourself. |
On Amazon Linux 2023:
```bash theme={null}
dnf install -y jq tar gzip
curl -fsSLo /usr/local/bin/kubectl \
"https://dl.k8s.io/release/$(curl -fsSL https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x /usr/local/bin/kubectl
curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4 \
| HELM_INSTALL_DIR=/usr/local/bin bash
curl -fsSL "https://github.com/google/go-containerregistry/releases/download/v0.22.0/go-containerregistry_Linux_x86_64.tar.gz" \
| tar xz -C /usr/local/bin crane
chmod +x /usr/local/bin/crane
```
The AWS CLI is preinstalled on Amazon Linux 2023. On other distributions, follow [Install or update to the latest version of the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) in the AWS documentation. Version 1 is not sufficient.
## IAM Permissions
The bastion's instance profile needs whatever the install scripts call. The policy below is derived from the scripts themselves, rather than discovered one failed run at a time. Scope the resources to your own account, region, and names.
Attach it to the module's bastion with `bastion_extra_policy_arns`.
```hcl theme={null}
data "aws_iam_policy_document" "lilt_installer" {
# seed-registry.sh authenticates, pushes the release images, and pulls them
# back. Drop both ECR blocks if your registry is not ECR.
statement {
sid = "EcrAuth"
actions = ["ecr:GetAuthorizationToken"]
resources = ["*"]
}
statement {
sid = "EcrReadWrite"
actions = [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchCheckLayerAvailability",
"ecr:InitiateLayerUpload",
"ecr:UploadLayerPart",
"ecr:CompleteLayerUpload",
"ecr:PutImage",
"ecr:DescribeRepositories",
"ecr:DescribeImages",
"ecr:ListImages",
"ecr:CreateRepository",
]
resources = ["arn:aws:ecr:${var.region}:${var.account_id}:repository/*"]
}
# install-rds-secrets.sh reads the endpoint, and the managed master secret
# when the database was created with one.
statement {
sid = "ReadDatabase"
actions = ["rds:DescribeDBInstances"]
resources = ["*"]
}
statement {
sid = "ReadDatabaseSecret"
actions = ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"]
resources = ["*"]
}
# install-s3-irsa.sh finds the app-workload role by name.
statement {
sid = "ListRolesForRoleLookup"
actions = ["iam:ListRoles"]
resources = ["*"]
}
# install-dns-records.sh writes the service records and waits for the change
# to propagate. DescribeLoadBalancers resolves the load balancer's hosted
# zone ID, which an alias record needs.
statement {
sid = "WriteDnsRecords"
actions = ["route53:ChangeResourceRecordSets", "route53:ListResourceRecordSets"]
resources = ["arn:aws:route53:::hostedzone/${var.hosted_zone_id}"]
}
statement {
sid = "ReadDnsChangeStatus"
actions = ["route53:GetChange"]
resources = ["*"]
}
statement {
sid = "DescribeLoadBalancers"
actions = ["elasticloadbalancing:DescribeLoadBalancers"]
resources = ["*"]
}
}
```
Two notes on scoping:
* `ecr:GetAuthorizationToken`, `route53:GetChange`, and the `Describe*` actions do not accept a resource ARN. `"*"` is the only valid value, and the API itself is the boundary.
* Narrow `ReadDatabaseSecret` to the specific secret where you can. When RDS manages the master password, the secret's ARN is not known until the database exists, so scoping by a resource tag is usually easier than scoping by ARN.
Beyond this list, add whatever your own delivery path needs, such as read access to the bucket that holds the release tarball.
## Step 1: Get the Release onto the Bastion
Copy the tarball across however you normally move artifacts, then unpack it:
```bash theme={null}
mkdir -p /opt/lilt && cd /opt/lilt
tar xzf on-prem-installer-eks_.tar.gz
test -f install-lilt-eks.sh # confirms this is the EKS flavor
```
See [Install package](/kb/install-package) for how to download and verify the tarball.
## Step 2: Point kubectl at the Cluster
```bash theme={null}
aws eks update-kubeconfig --region --name
kubectl get nodes
```
If `kubectl get nodes` times out, the bastion has no route to the API endpoint. Fix that before you go further. Every later step depends on it, and the failures it produces are much harder to read than this one.
## Step 3: Write install.env
```bash theme={null}
cp install.env.example install.env
chmod 0600 install.env
```
Fill it in as described in [Install System (AWS EKS)](/kb/install-system-aws-eks). Keep the file at mode `0600`. It holds credentials.
## Step 4: Seed the Registry
```bash theme={null}
sh install_scripts/seed-registry.sh --help
```
This is the long step. It skips images your registry already has, so a re-run after a failure resumes rather than restarting. See [Seed your container registry](/kb/install-package#seed-your-container-registry) for the full options.
Point `SEED_REGISTRY_WORK_DIR` at real disk. It defaults to `/var/tmp` for a reason: on most current distributions `/tmp` is a tmpfs sized at half of system RAM, and staging a large image there fails with `No space left on device` while `df` shows the root volume nearly empty.
## Step 5: Run the Install
```bash theme={null}
sh install-lilt-eks.sh 2>&1 | tee /var/log/lilt-install.log
```
Budget roughly two hours. Keep the log. When something fails at minute 90, it is the only account of what happened.
For an environment you expect to rebuild, running the installer as a unit rather than in a shell survives a dropped connection and keeps the log in one place.
```ini theme={null}
[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutStartSec=infinity
WorkingDirectory=/opt/lilt
ExecStart=/opt/lilt/install-lilt-eks.sh
StandardOutput=append:/var/log/lilt-install.log
StandardError=append:/var/log/lilt-install.log
```
With `RemainAfterExit=yes`, use `systemctl restart` to run the installer again. A `systemctl start` against a unit that already succeeded is a silent no-op, which reads exactly like a run that finished instantly.
## Step 6: Verify
Three checks, working outwards from the cluster to the browser. Run them in order: each one only makes sense if the previous one passed.
**1. Are the pods healthy?**
```bash theme={null}
kubectl get pods -n lilt | grep -v Running | grep -v Completed
```
The filter leaves only pods that need attention, so **no output is the result you want**. A pod in `Init` or `ContainerCreating` shortly after the install is usually still pulling an image; the neural images are tens of gigabytes. Anything in `CrashLoopBackOff` or `Pending` needs `kubectl describe pod`.
**2. Did the load balancer get an address?**
```bash theme={null}
kubectl get svc -n istio-ingressgateway
```
The `EXTERNAL-IP` column should hold a hostname, not ``. Stuck at `` means no controller claimed the Service: on EKS, the AWS Load Balancer Controller is missing or lacks permissions. Nothing outside the cluster can reach LILT until this resolves.
**3. Does the whole path work from outside?**
```bash theme={null}
curl -sS -o /dev/null -w '%{http_code} verify=%{ssl_verify_result}\n' https:///
```
This tests DNS, the load balancer, the gateway, and the certificate in one request.
* **`verify=0`** is the part that matters. It means the certificate chain validated. A chain missing its intermediate still satisfies a browser that cached it, then fails in a stricter client later, so check it here rather than by loading the page.
* **Any status code** means the request reached the gateway. A `200`, `302`, or `401` are all fine at this stage. A connection or TLS error is not.
If curl reports a TLS error, see [Set custom domain and certificates](/kb/set-custom-domain-and-certificates).
## Tear Down in the Right Order
To decommission an environment, uninstall LILT from inside the cluster **before** you run `terraform destroy`:
```bash theme={null}
WIPE_DATA=true PURGE_CRDS=true sh uninstall-lilt.sh
```
Destroying the AWS resources first leaves the load balancer and the volumes that persistent volume claims created still attached to network interfaces in the VPC. The VPC deletion then hangs.
## When It Fails
The install is re-runnable. Fix the cause and run it again. Every component uses `helm upgrade --install`, which is a no-op when the chart and values are unchanged. See [Resuming a failed install](/kb/install-system-aws-eks#resuming-a-failed-install).
# Install K8S In Offline Environment (Rocky 8)
Source: https://support.lilt.com/kb/install-k8s-in-offline-environment-rocky-8
## Overview
This document entails steps and procedures to install k8s in an offline environment without internet access, whether in the cloud (public or private), or on bare-metal hardware.
#### System Parameters/Versions Used for this Example:
* Rocky Linux: 8.10
* K8s: 1.29.12
* Containerd: 1.7.23
* Docker: 27.2.0
## Tools you will need
* One computer/system with containerd/docker installed and internet access.
* recommend to use a system with the same chipset as installation system (i.e. AMD64)
* Destination offline system for installation (no internet access).
## Prerequisites
The following packages/dependencies should already be completed:
* base operating system (OS) updated and patched
* containerd or docker installed (both on-line and off-line systems)
* firewalld installed
## Prepare K8S Images/Binaries
### System with Internet Access
Download all required binaries/images. Perform the following steps from the system with internet access. This example uses a linux machine.
#### Step 1: Set Version
Set desired K8S version:
```bash theme={null}
export K8S_VERSION=v1.35
```
#### Step 2: Download K8S Packages
Download all K8S packages for installation on Rocky 8. Set the repository:
```bash theme={null}
# set repository and repo
cat <
NOTE: Ensure that CNI and Service CIDRs are consistent with previous or desired installation.
Set `kubectl `config:
```bash theme={null}
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
export KUBECONFIG=/etc/kubernetes/admin.conf
```
Verify that the cluster is running:
```bash theme={null}
kubectl get nodes
```
Output should be similar to the following:
```bash theme={null}
NAME STATUS ROLES AGE VERSION
ip-172-31-9-184.ec2.internal NotReady control-plane 37m v1.29.12
```
List running pods:
```bash theme={null}
kubectl get pods -A
```
Output should be similar to the following:
```bash theme={null}
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-76f75df574-msppj 0/1 Pending 0 37m
kube-system coredns-76f75df574-pdn7f 0/1 Pending 0 37m
kube-system etcd-ip-172-31-9-184.ec2.internal 1/1 Running 0 37m
kube-system kube-apiserver-ip-172-31-9-184.ec2.internal 1/1 Running 0 37m
kube-system kube-controller-manager-ip-172-31-9-184.ec2.internal 1/1 Running 0 37m
kube-system kube-proxy-fj4k8 1/1 Running 0 37m
kube-system kube-scheduler-ip-172-31-9-184.ec2.internal 1/1 Running 0 37m
```
NOTE: `coredns` pods will be in *“Pending”* state until flannel (or other CNI) is installed.
# Install Package
Source: https://support.lilt.com/kb/install-package
LILT ships each self-managed release as a signed set of artifacts in Amazon S3. The install package is a single tarball that contains the install scripts, the Helm charts, and the values files for one deployment flavor. This article describes the artifacts, how to verify them, and what you get when you extract one.
## Release Flavors
Every release builds two install packages from the same source. You choose a flavor by downloading the matching tarball. There is no runtime flag that switches between them.
| Flavor | Tarball | Entrypoint | Use it when |
| ----------- | ------------------------------------- | --------------------- | --------------------------------------------------------------- |
| EKS | `on-prem-installer-eks_.tar.gz` | `install-lilt-eks.sh` | You run LILT on Amazon Elastic Kubernetes Service. |
| On-premises | `on-prem-installer_.tar.gz` | `install-lilt.sh` | You run LILT on bare-metal or virtual machines that you manage. |
`` is the first eight characters of the source commit the release was built from. Both tarballs in a release share the same hash.
The two flavors differ in what infrastructure they bring with them:
* The **on-premises** flavor installs the supporting infrastructure itself: Flannel for cluster networking, MetalLB for load balancing, the local persistent-volume provisioner for storage, MySQL, and MinIO for object storage.
* The **EKS** flavor leaves that to AWS. It expects the VPC CNI, an Elastic Load Balancer, the EBS CSI driver, Amazon RDS, and Amazon S3. In their place it adds Cluster Autoscaler and External Secrets Operator, both installed by default, plus cert-manager *(optional)* and the `lilt-aws-env` Terraform module *(optional)*.
Optional here means the component ships in the tarball either way and you decide whether to use it. cert-manager is off unless you set `ENABLE_CERT_MANAGER=true`, and the Terraform module is only used if you provision your infrastructure with it. Every component the installer runs has a toggle of its own, so anything in the list can be turned off — see [Component flags](/kb/install-system-aws-eks#component-flags).
The EKS tarball is the only one that contains the Terraform module. If you plan to provision AWS infrastructure with Terraform, download the EKS flavor. See [Provision AWS infrastructure with Terraform](/kb/install-aws-terraform-module).
## Download the Package
LILT gives you an S3 release URI for your version, in the form `s3:///lilt-enterprise-/`. The bucket is chosen per release when it is published, so use the URI LILT gives you rather than assuming one. Current releases are published to `lilt-self-managed-releases`; releases from before the move are in `lilt-enterprise-releases`.
This is LILT's distribution bucket, which is where you download from. It is unrelated to the S3 bucket LILT runs on. That one lives in your own account, is named `-s3` by the Terraform module, and is set with `S3_BUCKET` in `install.env`.
Every release uses the same layout under the release prefix:
```
lilt-enterprise-/
├── install_packages/ # the two flavor tarballs and their .md5 sidecars
├── docker_images/ # container image tarballs
└── documentation/
├── md5sum.txt # consolidated checksums for the whole release
├── image_map.tsv # LILT application images: tag, target repo, source repo
└── image_list.txt # third-party images
```
Set the release URI and the flavor you want, then download:
```bash theme={null}
export RELEASE_URI="s3:///lilt-enterprise-"
export FLAVOR="on-prem-installer-eks" # or "on-prem-installer" for on-premises
mkdir -p ~/lilt-release && cd ~/lilt-release
aws s3 cp "$RELEASE_URI/documentation/md5sum.txt" .
aws s3 sync "$RELEASE_URI/install_packages/" ./install_packages/ \
--exclude '*' --include "${FLAVOR}_*"
```
## Verify the Package
Each tarball is published with a `.md5` sidecar that holds the checksum of the local file. The consolidated `documentation/md5sum.txt` covers every artifact in the release.
Do not compare an S3 ETag against a checksum. LILT uploads these artifacts as multipart objects, so the ETag is a hash of part hashes, not the MD5 of the file. Use the published `.md5` files.
Verify the tarball you downloaded:
```bash theme={null}
cd ~/lilt-release/install_packages
md5sum -c "$(ls ${FLAVOR}_*.tar.gz).md5"
```
To verify everything you pulled, run `md5sum -c md5sum.txt` from the directory that holds the release tree. The file lists paths relative to the release prefix.
## Extract the Package
```bash theme={null}
mkdir -p /opt/lilt && cd /opt/lilt
tar xzf ~/lilt-release/install_packages/${FLAVOR}_*.tar.gz
```
Confirm that you extracted the flavor you expected. Only the EKS tarball contains `install-lilt-eks.sh`:
```bash theme={null}
test -f install-lilt-eks.sh && echo "EKS flavor"
test -f install-lilt.sh && echo "on-premises flavor"
```
## What the Package Contains
| Path | Contents |
| ------------------------------------------ | --------------------------------------------------------------------------------------------- |
| `install-lilt-eks.sh` or `install-lilt.sh` | The entrypoint for the flavor. Runs each component in order. |
| `install.env.example` | Every configuration variable the installer reads, with its default. Copy it to `install.env`. |
| `install_scripts/` | One `install-.sh` per component, plus shared helpers and `seed-registry.sh`. |
| `charts/` | Every Helm chart the install needs, vendored at the pinned version. |
| `lilt/` | The LILT umbrella chart, its environment overlays, and the secret seed files. |
| `lilt-networking/` | The HTTPRoute and Gateway resources that publish LILT. |
| `docs/` | The install guides for the flavor you downloaded. |
| `uninstall-lilt.sh` | Ordered teardown of everything the installer created. |
| `terraform-modules/lilt-aws-env/` | EKS flavor only. The Terraform module that provisions the AWS infrastructure. |
The charts in `charts/` are vendored as local `.tgz` archives, pinned to the versions the release was tested with, but the installer does not use them unless you tell it to. `CHART_BASE` defaults to an OCI registry that an air-gapped cluster cannot reach. To install from the charts in the tarball, point `CHART_BASE` at that directory:
```bash theme={null}
# install.env
CHART_BASE=/opt/lilt/charts
```
Use an absolute path. When `CHART_BASE` is a filesystem path, the installer resolves each chart to the packaged `.tgz` in that directory and ignores the version flag, because the vendored archive already is the pinned version.
Do not point `CHART_BASE` at a container registry mirror unless you have confirmed that every chart the release uses is present there. Mirroring only the LILT-authored charts leaves the third-party ones unresolvable.
## Seed Your Container Registry
The cluster pulls LILT images from a registry that you control. `install_scripts/seed-registry.sh` copies the release's images from the release tree, or straight from S3, into that registry. This is the step an air-gapped install depends on, and it is the longest step in the whole process.
The script reads `documentation/image_map.tsv` and `documentation/image_list.txt` from the release, so it always seeds exactly the images that release needs.
Install [crane](https://github.com/google/go-containerregistry) before you run this. The installer does not install it, and `seed-registry.sh` stops immediately with `ERROR: crane not on PATH.` The script ships with both flavors, so this applies to on-premises and EKS alike.
```bash theme={null}
curl -fsSL "https://github.com/google/go-containerregistry/releases/download/v0.22.0/go-containerregistry_Linux_x86_64.tar.gz" \
| tar xz -C /usr/local/bin crane
chmod +x /usr/local/bin/crane
```
crane reads the usual Docker credential config, so authenticate first, for example with `aws ecr get-login-password --region | crane auth login --username AWS --password-stdin .dkr.ecr..amazonaws.com`.
### Point It at the Release
`--release` takes either the S3 release prefix or a release directory you already downloaded. Both hold the same images; they differ in how much disk you need.
| Form | Value | Disk needed |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- |
| S3 prefix | The release URI LILT gave you, the same one used to [download the package](#download-the-package), for example `s3:///lilt-enterprise-` | One image at a time. Each is fetched, pushed, then deleted. |
| Local directory | The directory you synced the release into, for example `~/lilt-release` | The whole release, about 180 GB. |
Prefer the S3 form unless the machine has no route to S3. It needs room for the largest single image rather than the entire bundle, and it is the same URI you already have.
`--release` points at the **release**, which contains `documentation/` and `docker_images/`. It is not the extracted installer tarball, which contains the install scripts and charts.
```bash theme={null}
export RELEASE_URI="s3:///lilt-enterprise-"
export TARGET_REGISTRY=".dkr.ecr..amazonaws.com"
```
### Preview, Then Push
Without `--apply` the script reports a plan and copies nothing. Run this first:
```bash theme={null}
sh install_scripts/seed-registry.sh \
--release "$RELEASE_URI" \
--registry "$TARGET_REGISTRY"
```
Each image is listed as `PUSH` or, if your registry already holds that tag, `HAVE`. When the plan looks right, add `--apply`:
```bash theme={null}
sh install_scripts/seed-registry.sh \
--release "$RELEASE_URI" \
--registry "$TARGET_REGISTRY" \
--apply
```
Add `--path` if you set the `REGISTRY_PATH_*` variables in `install.env`. It defaults to empty, which matches the plain-ECR layout where those variables are also empty. Set one and not the other and the install pulls from a path nothing was pushed to.
You can also drive the script from `install.env` with `ENABLE_SEED_REGISTRY`, `SEED_REGISTRY_RELEASE`, `SEED_REGISTRY_TARGET`, and `SEED_REGISTRY_APPLY`, which lets the installer run it as part of an unattended install.
The script skips images your registry already has, so a re-run after a failure resumes rather than starting over.
### Sizing the Staging Directory
`seed-registry.sh` stages each image on local disk before it pushes. A release moves roughly 180 GB in total, and the largest single image is about 47 GB.
Set `SEED_REGISTRY_WORK_DIR` to a path on a real disk, and give that disk room for the largest image in the release. On Amazon Linux 2023, RHEL 9, Debian 12, and most other current distributions, `/tmp` is a tmpfs sized at half of system RAM. Staging a large image there fails with `No space left on device` while `df` shows the root volume nearly empty. The default of `/var/tmp` avoids this.
### Amazon ECR
Amazon ECR does not create a repository when you push to one that does not exist. `seed-registry.sh` creates each repository before its first push, which needs the `ecr:CreateRepository` permission. If your repositories are provisioned separately, set `SEED_REGISTRY_CREATE_REPOS=false`.
### Let the Cluster Pull
Seeding puts the images in your registry. The cluster still has to authenticate to pull them, and LILT relies on node-level authentication for that rather than on per-namespace pull secrets.
On EKS with ECR this is already handled: the LILT Terraform module attaches the `AmazonEC2ContainerRegistryReadOnly` policy to the node role, so every node can pull from the account's registry with no further configuration. If you provision your own cluster, grant the node role the same access. See [Install on an existing EKS cluster](/kb/install-aws-existing-cluster).
For a registry that cannot authenticate at the node level, configure the credential the way your runtime expects before you install. A pod that cannot pull sits in `ImagePullBackOff`, which names the image but not the missing credential.
## Next Steps
* [Install System (AWS EKS)](/kb/install-system-aws-eks) — configure and run the EKS install.
* [Provision AWS infrastructure with Terraform](/kb/install-aws-terraform-module) — create the cluster, database, and IAM roles with the `lilt-aws-env` module.
* [Install on an existing EKS cluster](/kb/install-aws-existing-cluster) — use infrastructure you provisioned yourself.
* [Install System (Amazon Linux 2023 or Rocky 8/9)](/kb/install-system-amazon-linux-2023-or-rocky-8-9) — the on-premises flavor.
# Install System (Amazon Linux 2023 Or Rocky 8/9)
Source: https://support.lilt.com/kb/install-system-amazon-linux-2023-or-rocky-8-9
## Overview
This article walks the installer through the process of bringing the environment up to test LILT in a secure platform, whether in the cloud (public or private), or on bare-metal hardware. The intent is to limit the amount of manual console interaction in favor of scripted installation that is fully documented.
In working through the installation, references will be made as appropriate to provide context.
#### System Parameters/Versions:
* LILT: 5.0-5.1
* Base OS:
* Amazon Linux 2023: `ami-05576a079321f21f8`
* Rocky 8.10/9.5
* K8S: 1.32.4
* Pause: 3.10 (can be configured in `containerd/config.toml`)
* Containerd:
* 2.0.5 (v2.0.0+ requires K8 >= 1.30 and Rocky 9 with kernel 5.x)
* 1.6.x/1.7.x (Rocky 8 with kernel 4.x)
* Runc: 1.2.6
* CNI plugin: 1.7.1
* Flannel, 0.26.0
* NVIDIA Driver: 565.57.01, dkms
* Cuda: 12.7
* Cuda-toolkit: 12.6
* Cudnn: 9.6.0
* GPU: L4 (current standard; A10G also validated)
## Tools you will need
SSH to connect to systems.
* On the Mac or Linux, you can open a terminal window and use ssh.
* On Windows, you can use the PuTTY ssh client.
Web browser for post installation and verification.
### Installer privileges
Many sections of this article include text formatted to indicate console input and output. The commands are prefixed with a \$ or # depending on if the administrator should run them as root or not. Additionally, to assist the user to know which machine to run commands on, the prefix node, master, and gpu will be given when the machine should be switched. All following commands after a switch should use those.
## Prerequisites
Before running installation scripts we need to prepare the system with all the dependencies.
### Data Location
For the rest of the installation, please ensure that:
Containerd, images and RPM packages are mounted and available to all of the nodes (master, worker, and GPU).
In the typical installation, the system administrator will receive this data from LILT prior to installation, and the system administrator will mount all requirements.
### Kubernetes Cluster Installation
#### Installation Overview
##### Kubernetes
The LILT system is a collection of containers that interact with each other. LILT requires the use of Kubernetes to handle orchestration. Further, there must be persistent volume storage mounted to nodes in Kubernetes.
##### LILT Component Overview
Note: See the section “LILT System Architecture Diagram” for a visual depiction of the following information.
The LILT application consists of three major logical component groups:
* “Front”, which services API calls as well as the interface and editor logic
* “Neural”, which performs neural machine translation
* “Core”, which performs linguistic pre-processing and post-processing, as well as document import and export
RabbitMQ is used for message passing between the services; MySQL is used for the application database, ElasticSearch for search purposes, Minio as s3 storage, OpenEBS for storage allocation, the Istio ingress gateway (with MetalLB) for ingress and Redis for a memory cache. For each of these 7 services, LILT will provide a containerd image that is installed as part of the installation process. Optionally, customers can use a self-hosted version of any of those five services that can be pointed to by the LILT system (for example, a separately running ElasticSearch instance, AWS RDS in place of mysql, or s3 instead of minio).
Finally, there must be a persistent location for stored user documents that is mountable as a persistent volume to a Kubernetes node. This volume will be used by Minio, Elasticsearch, MySql, Redis and RabbitMQ.
#### LILT System Architecture Diagram
Refer to: [https://self-managed-docs.lilt.com/kb/lilt-system-architecture](https://self-managed-docs.lilt.com/kb/lilt-system-architecture)
#### System Maintenance and Update Frequency
LILT recommends a system update every quarter. The update can proceed in one of two ways:
1. (Recommended) A customer systems engineer installs the system from scratch given an installation document and assets package delivered via cloud or flash drive.
2. A LILT systems engineer is given SSH access to the customer system, and performs the update remotely.
To schedule a system update, contact your Account Manager.
### Recommended System Requirements
LILT recommends a minimum of three separate servers as nodes for the kubernetes cluster.
#### k8s-master server
This server controls cluster scheduling, networking and health. In comparison to the node server(s), it is resource-light.
Instance type: m5.xlarge (4 vCPUs, 16 GB RAM)
Disk space: 500 GB
#### k8s-node server(s)
These server(s) are the main application workhorse and listen to the master server, host containerd containers for the main application, and mount storage. Usually, one node suffices, but for increased system performance, multiple nodes can be setup. In that case, the hardware requirements should be correspondingly replicated for each node, with the exception of the disk mounts. Disk mounts need to be shared across all nodes. A few notes here:
1. The total system requirements for the node server can either be fulfilled on a single machine, or split among multiple nodes that in sum are equal or greater than the recommended system requirements. However, if splitting the node server into separate physical nodes, please note that individual nodes have *minimum* requirements; see the details below.
2. On the nodes with GPUs installed, NVIDIA drivers will have to be installed (these will be specified in the installation document).
##### Worker Node
Instance type: r5n.24xlarge (96 vCPUs, 768 GB RAM)
Total disk space: 2 TB
* If create multiple drives
* Boot disk space: 400 GB
* Common space: 1.6 TB (increase based on total documents ingested).3
* containerd and all PVCs
If unable to create multiple mounts/drives and all data is stored in root, one drive of 2TB is sufficient.
##### GPU Node
V4 models require a minimum of 24 GB GPU memory; either two combined T4s, one L4, one A10, or one A100. Batch processing requires a minimum of one GPU; T4, L4, A10, or A100.
The following are tested recommendations but any configure can be utilized as long as the minimum requirements are met.
Minimum instances, T4 GPUs (node with 2 GPUs required for translate v4, node with 1 GPU required for batch):
* 1 x g4ad.8xlarge (32 vCPUs, 128 GB RAM, 2 GPUs)
* 1 x g4dn.4xlarge (16 vCPUs, 64 GB RAM, 1 GPU)
Sufficient instance type, T4 GPUs:
g4dn.12xlarge (48 vCPUs, 192 GB RAM, 4 GPUs)
Preferred instance type, L4 GPUs (current standard; see [Self-Managed Hardware Requirements](/kb/self-managed-hardware-requirements)):
g6.12xlarge (48 vCPUs, 192 GB RAM, 4 GPUs)
Optimal instance type, L4 GPUs:
g6.48xlarge (192 vCPUs, 768 GB RAM, 8 GPUs)
Alternative instance type, A10 GPUs (still supported):
g5.12xlarge (48 vCPUs, 192 GB RAM, 4 GPUs) or g5.48xlarge (192 vCPUs, 768 GB RAM, 8 GPUs)
Total disk space: 2 TB. These store pods' runtime assets, including large neural assets.
## Install Kubernetes Cluster
### All Nodes (master, worker, gpu)
Login to the each node and complete the following steps.
Commands have to be performed as root (since it involves installation of Kubernetes).
```bash theme={null}
sudo su -
```
#### Step 1: Update base OS, Install required packages
Each base OS has different package requirements.
* *Amazon Linux 2023*:
```bash theme={null}
# update OS
dnf check-release-update
sudo dnf update -y
# install bash
sudo dnf install bash -y
# install git
sudo dnf install -y git
# install ip route, used by k8s
sudo dnf install -y iproute-tc
```
* *Rocky 8/9*:
```bash theme={null}
# update system
dnf update -y
# utilities
sudo dnf install -y curl wget vim bash-completion gnupg2 lvm2
# required to unzip packages
dnf install zip unzip -y
# (optional) install aws
yum remove awscli
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
./aws/install
# install bash
sudo dnf install bash -y
# install jq
sudo dnf install jq -y
# install git
sudo dnf install -y git
# reboot so that the below packages can use the updated kernel
reboot
Step 2: Install helm
```
```bash theme={null}
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4
chmod 700 get_helm.sh
./get_helm.sh
```
The installer requires Helm 4 and refuses to run with Helm 3. Verify with `helm version --short`.
#### Step 3: Install k9s (MASTER NODE only. Optional, but highly recommended)
```bash theme={null}
export K9S_V="0.50.4"
curl -LO "https://github.com/derailed/k9s/releases/download/v$K9S_V/k9s_Linux_amd64.tar.gz"
tar -xzf k9s_Linux_amd64.tar.gz
sudo mv k9s /usr/local/bin/
```
#### Step 4: Set kernel parameters as required by Istio
```bash theme={null}
# avoid ztunnel container restarts due to load
# append to end of file
cat <> /etc/security/limits.conf
* soft nofile 131072
* hard nofile 131072
EOF
cat <> /etc/systemd/system.conf
DefaultLimitNOFILE=131072
EOF
```
#### Step 5: Set kernel parameters as required by Kubernetes
```bash theme={null}
bash -c 'cat <
![]()
NOTE: if using version of K8S older than v1.29, it is possible that insecure port (`10255`) is still being utilized. The following setup does NOT include the old insecure port. It is highly recommended that customers upgrade to K8S v1.30 or higher which includes the new secure port (`10250`) by default.
```bash theme={null}
# disable swap
swapoff -a
sed -e '/swap/s/^/#/g' -i /etc/fstab
# disable SELinux
sudo setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
# setup firewall
dnf install -y firewalld
systemctl unmask firewalld && systemctl enable firewalld && systemctl restart firewalld
firewall-cmd --permanent --zone=public --set-target=ACCEPT
firewall-cmd --permanent --add-port={22,80,443,2379,2380,5000,6443,10250,10251,10252}/tcp
# api
firewall-cmd --permanent --add-port={5005,8011,8080}/tcp
# istio
firewall-cmd --permanent --add-port={15000,15001,15006,15008,15009,15010,15012,15014,15017,15020,15021,15090,15443,20001}/tcp
# flannel
firewall-cmd --permanent --add-port=8472/udp
# clickhouse
firewall-cmd --permanent --add-port=8123/tcp
# WSO2
firewall-cmd --permanent --add-port={4000,9443,9763}/tcp
# reload firewall
firewall-cmd --reload
# Add vm.max_map_count=262144 to /etc/sysctl.conf
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf
# Apply the sysctl settings
sudo sysctl -p
# Verify the change
sysctl vm.max_map_count
```
#### Step 7: Install containerd and add runc to the runtime
```bash theme={null}
# containerd
export CONTAINERD_V="2.0.5"
export RUNC_V="1.2.6"
wget https://github.com/containerd/containerd/releases/download/v$CONTAINERD_V/containerd-$CONTAINERD_V-linux-amd64.tar.gz
tar Cxzvf /usr/local containerd-$CONTAINERD_V-linux-amd64.tar.gz
# if going to use systemd (yes in this install), need to add the following file
mkdir -p /usr/local/lib/systemd/system/
curl "https://raw.githubusercontent.com/containerd/containerd/main/containerd.service" -o "/usr/local/lib/systemd/system/containerd.service"
# restart
systemctl daemon-reload
systemctl enable --now containerd
# runc
wget https://github.com/opencontainers/runc/releases/download/v$RUNC_V/runc.amd64
install -m 755 runc.amd64 /usr/local/sbin/runc
```
#### Step 8: Install cni plugin
```bash theme={null}
# cni plugin
export CNI_V="1.7.1"
wget https://github.com/containernetworking/plugins/releases/download/v$CNI_V/cni-plugins-linux-amd64-v$CNI_V.tgz
mkdir -p /opt/cni/bin
tar Cxzvf /opt/cni/bin cni-plugins-linux-amd64-v$CNI_V.tgz
```
#### Step 9: Setup containerd
##### Create containerd directory:
```bash theme={null}
mkdir -p /etc/containerd/
```
![]()
NOTE: If need to specify pause sand\_box image, add the following to each respective `config.toml`:
```bash theme={null}
[plugins]
[plugins."io.containerd.grpc.v1.cri"]
sandbox_image = "k8s.gcr.io/pause:3.10"
```
##### Master and Worker Nodes:
```bash theme={null}
cat < /etc/containerd/config.toml
version = 2
[plugins]
[plugins."io.containerd.grpc.v1.cri"]
[plugins."io.containerd.grpc.v1.cri".containerd]
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
runtime_type = "io.containerd.runc.v2"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true
EOF
sudo systemctl restart containerd
```
##### GPU Nodes:
```bash theme={null}
cat < /etc/containerd/config.toml
version = 2
[plugins]
[plugins."io.containerd.grpc.v1.cri"]
[plugins."io.containerd.grpc.v1.cri".containerd]
default_runtime_name = "nvidia"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
runtime_type = "io.containerd.runc.v2"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia]
privileged_without_host_devices = false
runtime_type = "io.containerd.runc.v2"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia.options]
BinaryName = "/usr/bin/nvidia-container-runtime"
SystemdCgroup = true
EOF
sudo systemctl restart containerd
```
#### Step 10: Install & Setup - Kubernetes
```bash theme={null}
# set repository and repo
export K8S_V="1.32"
cat <&1)
# Check if nvidia-smi failed with a specific error
if echo "$nvidia_output" | grep -q "NVIDIA-SMI has failed"; then
echo "nvidia-smi failed with error: NVIDIA-SMI has failed. Checking DKMS status..."
# Get the DKMS status
dkms_status=$(dkms status)
echo "DKMS Status:"
echo "$dkms_status"
# Extract the NVIDIA module version and remove the trailing colon
nvidia_version=$(echo "$dkms_status" | grep nvidia | awk '{print $1}' | awk -F/ '{print $2}' | sed 's/:$//')
if [ -n "$nvidia_version" ]; then
echo "Attempting to install NVIDIA DKMS module version: $nvidia_version"
sudo dkms install nvidia/"$nvidia_version"
else
echo "No NVIDIA DKMS module found in DKMS status. Please check manually."
fi
else
echo "nvidia-smi is working correctly."
fi
# zlib is required for cudnn
sudo dnf -y install zlib
# install cudnn
sudo dnf -y install --allowerasing cudnn9-cuda-12
# install container-toolkit
curl -s -L https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo | \
sudo tee /etc/yum.repos.d/nvidia-container-toolkit.repo
# Pin to compatible version 1.17.6-1 and install
NVIDIA_CONTAINER_TOOLKIT_VERSION=1.17.6-1
sudo dnf install -y nvidia-container-toolkit-${NVIDIA_CONTAINER_TOOLKIT_VERSION} nvidia-container-toolkit-base-${NVIDIA_CONTAINER_TOOLKIT_VERSION} libnvidia-container-tools-${NVIDIA_CONTAINER_TOOLKIT_VERSION} libnvidia-container1-${NVIDIA_CONTAINER_TOOLKIT_VERSION}
# NOTE: If you want to use the latest nvidia-container-runtime:
# 1. Install the latest NVIDIA container toolkit:
# sudo dnf install -y nvidia-container-toolkit
# 2. Enable legacy mode for compatibility (tested with nvidia-container-runtime v1.18.0):
# sudo nvidia-ctk config --in-place --set nvidia-container-runtime.mode=legacy
# sudo systemctl restart containerd
# This ensures proper integration with containerd.
```
Verify that all NVIDIA drivers/packages were correctly installed
```bash theme={null}
nvidia-smi
```
Output should be similar to the following (depending on the number of server GPUs). If not, reinstall NVIDIA drivers from the previous section:
```bash theme={null}
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 565.57.01 Driver Version: 565.57.01 CUDA Version: 12.7 |
|-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA A10G Off | 00000000:00:16.0 Off | 0 |
| 0% 20C P8 9W / 300W | 1MiB / 23028MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
| 1 NVIDIA A10G Off | 00000000:00:17.0 Off | 0 |
| 0% 19C P8 10W / 300W | 1MiB / 23028MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
| 2 NVIDIA A10G Off | 00000000:00:18.0 Off | 0 |
| 0% 21C P8 9W / 300W | 1MiB / 23028MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
| 3 NVIDIA A10G Off | 00000000:00:19.0 Off | 0 |
| 0% 21C P8 9W / 300W | 1MiB / 23028MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
| 4 NVIDIA A10G Off | 00000000:00:1A.0 Off | 0 |
| 0% 20C P8 9W / 300W | 1MiB / 23028MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
| 5 NVIDIA A10G Off | 00000000:00:1B.0 Off | 0 |
| 0% 20C P8 9W / 300W | 1MiB / 23028MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
| 6 NVIDIA A10G Off | 00000000:00:1C.0 Off | 0 |
| 0% 20C P8 9W / 300W | 1MiB / 23028MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
| 7 NVIDIA A10G Off | 00000000:00:1D.0 Off | 0 |
| 0% 20C P8 9W / 300W | 1MiB / 23028MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| No running processes found |
+-----------------------------------------------------------------------------------------+
```
Verify cuda toolkit installed:
```bash theme={null}
/usr/local/cuda/bin/nvcc -V
```
Output should be similar to the following:
```bash theme={null}
nvcc: NVIDIA (R) Cuda compiler driveright (c) 2005-2024 NVIDIA Corporation
Built on Tue_Oct_29_23:50:19_PDT_2024
Cuda compilation tools, release 12.6, V12.6.85
Build cuda_12.6.r12.6/compiler.35059454_0
```
Very container-toolkit installed:
```bash theme={null}
nvidia-container-cli -V
```
Output should be similar to the following:
```bash theme={null}
cli-version: 1.17.3
lib-version: 1.17.3
build date: 2024-12-04T09:47+0000
build revision: 16f37fcafcbdaf67525135104d60d98d36688ba9
build compiler: gcc 4.8.5 20150623 (Red Hat 4.8.5-44)
build platform: x86_64
build flags: -D_GNU_SOURCE -D_FORTIFY_SOURCE=2 -DNDEBUG -std=gnu11 -O2 -g -fdata-sections -ffunction-sections -fplan9-extensions -fstack-protector -fno-strict-aliasing -fvisibility=hidden -Wall -Wextra -Wcast-align -Wpointer-arith -Wmissing-prototypes -Wnonnull -Wwrite-strings -Wlogical-op -Wformat=2 -Wmissing-format-attribute -Winit-self -Wshadow -Wstrict-prototypes -Wunreachable-code -Wconversion -Wsign-conversion -Wno-unknown-warning-option -Wno-format-extra-args -Wno-gnu-alignof-expression -Wl,-zrelro -Wl,-znow -Wl,-zdefs -Wl,--gc-sections
```
## Initialize Cluster
#### Master Node
Login to the k8s-master node and follow the below steps. Note that the following steps have to be performed as root (`sudo su -`) (since it involves installation of Kubernetes).
Run below command to initialize and setup Kubernetes master.
NOTE: Ensure that CNI and Service CIDRs do NOT conflict with local server/node IP addresses. CNI\_CIDR must match Flannel IP value set below.
CIDR, `192.168.100.0/19`, will allow for up to 32 nodes (flannel reserves one subnet for each node). If more nodes are required, need to increase netmask/subnet size.
CNI and service CIDRs can be modified to match respective network requirements:
```bash theme={null}
CNI_CIDR="192.168.100.0/19"
SERVICE_CIDR="192.168.200.0/19"
NODE_NAME="master"
kubeadm init \
--pod-network-cidr $CNI_CIDR \
--service-cidr $SERVICE_CIDR \
--node-name $NODE_NAME
```
Save the section of the output that resembles the following, as you will need it to join the worker nodes to the master:
```bash theme={null}
# example, real output will differ
kubeadm join 10.10.3.8:6443 --token 72dx7i.i1q8hymni6lw3f3f \
--discovery-token-ca-cert-hash sha256:9befd70bffbdf6009b96b4e2a3419458a1f2c5661c062246bef4ae38ca8fd7f7
```
To use `kubectl` commands, need to update kubeconfig (regular or root user):
```bash theme={null}
# update kubeconfig
export KUBECONFIG=/etc/kubernetes/admin.conf
# or if not root user
mkdir -p $HOME/.kube
sudo cp -f /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
systemctl enable kubelet.service
systemctl start kubelet.service
```
Verify that node has been installed correctly:
```bash theme={null}
kubectl get nodes
```
Expected output:
NOTE: STATUS will be `NotReady` until Flannel is installed.
```
NAME STATUS ROLES AGE VERSION
master NotReady control-plane 66s v1.32.4
```
If a period of time has passed between initializing cluster and joining nodes and the join token is expired, run the following command to create a new join token:
```bash theme={null}
kubeadm token create --print-join-command
```
#### Worker Node
Login to the k8s-worker node and follow the below steps. Note that the following steps have to be performed as root (`sudo su -`) (since it involves installation of Kubernetes).
Run following command to join the Kubernetes cluster created in the previous section:
```bash theme={null}
# example, real output will differ
NODE_NAME="worker"
kubeadm join 10.10.3.8:6443 --node-name $NODE_NAME \
--token 72dx7i.i1q8hymni6lw3f3f \
--discovery-token-ca-cert-hash sha256:9befd70bffbdf6009b96b4e2a3419458a1f2c5661c062246bef4ae38ca8fd7f7
```
From the master node, verify that the worker node has joined correctly:
```bash theme={null}
kubectl get nodes
```
Expected output:
![]()
NOTE: STATUS will be `NotReady` until Flannel is installed.
```
NAME STATUS ROLES AGE VERSION
master NotReady control-plane 149m v1.32.4
worker NotReady 8s v1.32.4
```
#### GPU Node
Login to the k8s-gpu node and follow the below steps. Note that the following steps have to be performed as root (`sudo su -`) (since it involves installation of Kubernetes).
Run following command to join the Kubernetes cluster created in the previous section:
```bash theme={null}
# example, real output will differ
NODE_NAME="gpu"
kubeadm join 10.10.3.8:6443 --node-name $NODE_NAME \
--token 72dx7i.i1q8hymni6lw3f3f \
--discovery-token-ca-cert-hash sha256:9befd70bffbdf6009b96b4e2a3419458a1f2c5661c062246bef4ae38ca8fd7f7
```
From the master node, verify that the worker node has joined correctly:
```bash theme={null}
kubectl get nodes
```
Expected output:
NOTE: `STATUS`will be `NotReady` until Flannel is installed.
```
NAME STATUS ROLES AGE VERSION
gpu NotReady 9s v1.32.4
master NotReady control-plane 177m v1.32.4
worker NotReady 28m v1.32.4
```
## Prepare the LILT Platform
### Import Dependencies
All images and scripts are packaged based on system requirements. Lilt is designed to work as a distributed system, utilizing specific nodes for each workload.
It is not necessary to download the entire install package on each node. The following examples utilize a remote s3 bucket for retrieving data.
![]()
Highly recommended to use a central repository for all images. The below examples utilize local image storage on each node. If using a central repository, containerd image import sections can be ignored. If use a central repository, ensure to modify all helm charts to replace the default value `lilt-registry.local.io:80`
#### Step 1: Set Release Tag (all nodes)
This can be ignored if downloading the entire package separately.
Login to each node (master, worker, gpu) and set release tag var:
```bash theme={null}
export RELEASE_TAG="lilt-enterprise-x.x.x"
```
#### Step 2: Import install packages and images
**Master Node**
Login to the k8s-master node and follow the below steps. Note that the following steps have to be performed as root (`sudo su -`).
Move to the root directory:
```bash theme={null}
cd /
```
Download install package and documentation from remote s3 bucket:
```bash theme={null}
aws s3 cp s3://lilt-enterprise-releases/$RELEASE_TAG/install_packages/ /$RELEASE_TAG/install_packages --recursive --exclude "*" --include "on-prem-installer*"
aws s3 cp s3://lilt-enterprise-releases/$RELEASE_TAG/documentation/ /$RELEASE_TAG/documentation --recursive
```
Unpack installer:
```bash theme={null}
mkdir -p /install_dir
tar -xzf /$RELEASE_TAG/install_packages/on-prem-installer* -C /install_dir
```
If not using a central image repository, complete the following:
* Download required images:
* istio pilot/proxyv2/install-cni/ztunnel/kiali
* flannel
```bash theme={null}
aws s3 cp s3://lilt-enterprise-releases/$RELEASE_TAG/docker_images/master/packages/ /$RELEASE_TAG/docker_images/master/packages --recursive --exclude "*" --include "pilot*" --include "proxyv2*" --include "install-cni*" --include "ztunnel*" --include "kiali*" --include "flannel*"
```
* Load images to containerd (update ``):
```bash theme={null}
for file in $(find /$RELEASE_TAG/docker_images -type f) ; do ctr -n=k8s.io image import $file --digests=true ; done
```
**Worker Node**
Login to the k8s-worker node and follow the below steps. Note that the following steps have to be performed as root (`sudo su -`).
Move to the root directory:
```bash theme={null}
cd /
```
If not using a central image repository, complete the following:
* Download required images (all of them):
```bash theme={null}
aws s3 cp s3://lilt-enterprise-releases/$RELEASE_TAG/docker_images/ /$RELEASE_TAG/docker_images --recursive
```
Load images to containerd (update ``):
```bash theme={null}
for file in $(find /$RELEASE_TAG/docker_images -type f) ; do ctr -n=k8s.io image import $file --digests=true ; done
```
**GPU Node**
Login to the k8s-gpu node and follow the below steps. Note that the following steps have to be performed as root (`sudo su -`).
Move to the root directory:
```bash theme={null}
cd /
```
If not using a central image repository, complete the following:
* Download required images:
* istio\_pilot/proxyv2/install-cni/ztunnel/kiali/k8s-device-plugin/metrics-server/flannel
* all neural/llm/batch
```bash theme={null}
aws s3 cp s3://lilt-enterprise-releases/$RELEASE_TAG/docker_images/master/packages/ /$RELEASE_TAG/docker_images/master/packages --recursive --exclude "*" --include "pilot*" --include "proxyv2*" --include "install-cni*" --include "ztunnel*" --include "kiali*" --include "flannel*" --include "k8s-device-plugin*" --include "metrics-server*"
aws s3 cp s3://lilt-enterprise-releases/$RELEASE_TAG/docker_images/master/apps/ /$RELEASE_TAG/docker_images/master/apps --recursive --exclude "*" --include "neural*" --include "llm*" --include "batch*"
aws s3 cp s3://lilt-enterprise-releases/$RELEASE_TAG/docker_images/node/ /$RELEASE_TAG/docker_images/node --recursive --exclude "*" --include "neural*"
```
* Load images to containerd (update ``):
```bash theme={null}
for file in $(find /$RELEASE_TAG/docker_images -type f) ; do ctr -n=k8s.io image import $file --digests=true ; done
```
#### Step 3: Label Nodes
Lilt cluster utilizes `nodeSelector` for scheduling pods on specific nodes. This is a simple way to control where pods are scheduled by adding a key-value pair to chart/manifest specifications.
**Master Node**
Login to the k8s-master node and follow the below steps. Note that the following steps have to be performed as root (`sudo su -`).
Worker node is used for running the bulk of application workloads, typically separate from the master and GPU nodes. Label this node as `worker` (node name set in the above section) by executing the following command:
```bash theme={null}
kubectl label nodes worker node-type=worker
```
GPU node is generally used for running GPU intensive pods/applications aside from the worker node; however, this node can also be used for additional workloads if the instance has sufficient resources to handle GPU and application tasks. This decision is up to the cluster admin to determine if GPU nodes can also handle application workloads.
If using this node for standard GPU services (translate, batch) and LLM services (llama, gemma and whisper) label as `gpu` (node name set in the above section) by executing the following command:
```bash theme={null}
kubectl label nodes gpu capability=gpu
```
Optional: if the GPU node has sufficient resources to run additional workloads, also add worker label:
```bash theme={null}
kubectl label nodes gpu capability=gpu node-type=worker
```
Verify output:
```bash theme={null}
# Show labels
kubectl get nodes --show-labels
```
If necessary to remove a previous node label, use the following command. Is this example, removing `node-type` label from the `gpu` node
```bash theme={null}
kubectl label node gpu node-type-
```
#### Step 4: Create Namespaces
The cluster uses various namespace to separate pods and services.
**Master Node**
Login to the k8s-master node and follow the below steps. Note that the following steps have to be performed as root (`sudo su -`).
```bash theme={null}
kubectl create ns lilt
kubectl create ns istio-system
kubectl create ns kube-flannel
```
Confirm that namespaces were created:
```bash theme={null}
kubectl get ns
```
Output should be similar to the following:
```
NAME STATUS AGE
default Active 4h
istio-system Active 4h
kube-flannel Active 4h
kube-node-lease Active 4h
kube-public Active 4h
kube-system Active 4h
lilt Active 4h
```
#### Step 5: Modify Flannel Helm Chart Values
Flannel helm chart CIDR must match k8s CIDR range.
**Master Node**
Login to the k8s-master node and follow the below steps. Note that the following steps have to be performed as root (`sudo su -`).
Modify flannel `on-prem-values.yaml`:
```bash theme={null}
vi /install_dir/flannel/on-prem-values.yaml
```
Edit `podCidr` to match k8s `CNI_CIDR`set above:
```bash theme={null}
podCidr: "192.168.100.0/19"
```
Save file and exit.
#### Step 6: Image Pull Secrets (optional)
If using a private central repository for hosting images that requires authentication, create image pull secrets for the cluster to reference. The following example utilizes username and password, for service accounts with a `json` key use this document [Create imagePullSecrets](/kb/create-imagepullsecrets)
**Master Node**
Login to the k8s-master node and follow the below steps. Note that the following steps have to be performed as root (`sudo su -`).
Create cluster image pull secret:
```bash theme={null}
kubectl -n create secret docker-registry \
--docker-username= \
--docker-password= \
--docker-server= \
--docker-email=
```
NOTE: Image pull secrets are namespace specific, must create a new secret for each additional namespace.
Verify secret was created:
```bash theme={null}
kubectl get secrets -A
```
LILT helm charts utilize a custom values file, usually `on-prem-values.yaml`. Update these files with the new `imagePullSecret`.
As an example, this is from `redis` custom values:
```bash theme={null}
global:
imagePullSecrets:
-
```
## Install LILT
### LILT app
Assuming that all images have been loaded into the nodes as explained in the previous steps, we can proceed to install the apps
#### Step 1: Installation
Run the main install script, this includes all third-party and lilt dependencies. This can take up to two hours to fully complete.
Change to install directory:
```bash theme={null}
cd /install_dir
```
Configure the installer. Copy the example and set the values for this cluster — the installer stops with an error if any of the first three are missing:
```bash theme={null}
cp install.env.example install.env
vi install.env
```
```bash theme={null}
SUBDOMAIN=lilt # every hostname renders as -.
DNS_DOMAIN=example.com # your base domain; the main page will be .
LB_IP=10.10.3.240 # a free IP in the node network; MetalLB assigns it to the ingress gateway
TLS_CRT_FILE=/root/tls.crt # PEM certificate chain for the gateway hostnames
TLS_KEY_FILE=/root/tls.key # matching private key
```
The certificate SANs must cover `.` and the sibling hostnames listed in `lilt-networking/on-prem-values.yaml` (`core-api-`, `connectors-api-`, `minio-`, `minio-...-ui`). Without `TLS_CRT_FILE`/`TLS_KEY_FILE` the install completes but the gateways serve no HTTPS until the `lilt-com-tls` secret is created — the installer prints the exact `kubectl create secret tls` command.
Run install script:
```powershell theme={null}
sh install-lilt.sh
```
If installed k9s, can monitor install progress:
```bash theme={null}
k9s
```
If did not install k9s, use kubectl to watch pods:
```bash theme={null}
kubectl get pods --all-namespaces --watch
```
Can also watch k8s events:
```bash theme={null}
kubectl events --all-namespaces --watch
```
When ready, list all pods:
```bash theme={null}
kubectl get pods --all-namespaces
```
Output should be similar to the following:
```
NAMESPACE NAME READY STATUS RESTARTS AGE
istio-system istio-cni-node-7fmp4 1/1 Running 0 5d1h
istio-system istio-cni-node-7fvcq 1/1 Running 0 5d1h
istio-system istio-cni-node-ljg7h 1/1 Running 0 5d1h
istio-system istiod-68fcbb5f87-vlg8m 1/1 Running 0 5d1h
istio-system kiali-c5748bfb9-7ns2g 1/1 Running 0 6h26m
istio-system prometheus-server-99f4cd586-5xbnt 1/1 Running 0 5d1h
istio-system ztunnel-b57qw 1/1 Running 0 5d1h
istio-system ztunnel-kwdz9 1/1 Running 0 5d1h
istio-system ztunnel-p8fhc 1/1 Running 0 5d1h
kube-flannel kube-flannel-ds-lvqr7 1/1 Running 0 5d2h
kube-flannel kube-flannel-ds-m7rbh 1/1 Running 0 5d2h
kube-flannel kube-flannel-ds-xqkfz 1/1 Running 0 5d2h
kube-system coredns-76f75df574-7p66z 1/1 Running 0 5d2h
kube-system coredns-76f75df574-svzk9 1/1 Running 0 5d2h
kube-system etcd-master-shared-vpc 1/1 Running 1 (5d2h ago) 5d2h
kube-system kube-apiserver-master-shared-vpc 1/1 Running 1 (5d2h ago) 5d2h
kube-system kube-controller-manager-master-shared-vpc 1/1 Running 1 (5d2h ago) 5d2h
kube-system kube-proxy-86855 1/1 Running 0 5d2h
kube-system kube-proxy-jggvv 1/1 Running 0 5d2h
kube-system kube-proxy-k5t6k 1/1 Running 0 5d2h
kube-system kube-scheduler-master-shared-vpc 1/1 Running 1 (5d2h ago) 5d2h
kube-system metrics-server-865f9f4b55-b9t4r 1/1 Running 0 5d1h
lilt assignment-core-976f6bc6c-xzsr8 1/1 Running 7 (5d1h ago) 5d1h
lilt auditlog-core-67b45f45b9-h25fs 1/1 Running 4 (5d1h ago) 5d1h
lilt auth-856c98d8f6-5f262 2/2 Running 0 4d22h
lilt batch-tb-core-7dc4fd97c7-sfmks 1/1 Running 7 (5d1h ago) 5d1h
lilt batch-worker-cpu-neural-74db44c979-pkl4t 1/1 Running 0 6h24m
lilt batch-worker-gpuv4-neural-866dcb59c4-hbhhd 1/1 Running 0 6h24m
lilt batchv4-neural-dd58d87b6-zzr6d 1/1 Running 0 5d1h
lilt cache-redis-master-0 1/1 Running 0 5d1h
lilt clickhouse-shard0-0 1/1 Running 0 5d1h
lilt connectors-ingressgateway-6d85dd9b5-58n2f 1/1 Running 0 5d1h
lilt converter-core-64d87b55d-fbffd 1/1 Running 4 (5d1h ago) 5d1h
lilt elasticsearch-master-0 1/1 Running 0 5d1h
lilt elasticsearch-master-1 1/1 Running 0 5d1h
lilt file-job-core-67598b8bb4-bv5r6 1/1 Running 0 5d1h
lilt file-translation-core-76fcfd7979-qj4dq 1/1 Running 0 5d1h
lilt front-app-7f75c8745c-w2bbs 2/2 Running 0 4d22h
lilt indexer-core-6bd8f76c45-lnxqs 1/1 Running 9 (5d1h ago) 5d1h
lilt istio-ingressgateway-6dc78b487c-nht2v 1/1 Running 0 5d1h
lilt job-core-5c5494cbcd-dxqr2 1/1 Running 0 5d1h
lilt langid-neural-57898fb4c5-7xcdv 1/1 Running 0 4d22h
lilt langid-neural-57898fb4c5-nfcqr 1/1 Running 0 4d22h
lilt lilt-beehive-5bf9d6ff6b-n87dh 1/1 Running 0 5d1h
lilt lilt-configuration-api-5c49db4797-8jnxq 2/2 Running 0 5d1h
lilt lilt-connectors-builder-678448f4f6-4g4pq 2/2 Running 0 7h50m
lilt lilt-connectors-create-admin-user-kjv2k 0/1 Completed 0 6h25m
lilt lilt-connectors-exporter-cronjob-28856445-zqnkx 0/1 Completed 0 53s
lilt lilt-connectors-scheduler-cronjob-28856445-gjhd7 0/1 Completed 0 53s
lilt lilt-core-api-67bcb48c6b-84gtt 2/2 Running 0 5d1h
lilt lilt-dataflow-clickhouse-migration-job-5tqms 0/1 Completed 0 6h25m
lilt lilt-dataflow-generate-memory-snapshot-cronjob-28855920-l5cnf 0/1 Completed 0 8h
lilt lilt-dataflow-ingest-comments-cronjob-28856400-988db 0/1 Completed 0 45m
lilt lilt-dataflow-ingest-connectorjobs-cronjob-28856400-9kzxp 0/1 Completed 0 45m
lilt lilt-dataflow-ingest-revision-reports-cronjob-28855020-mhwd4 0/1 Completed 0 23h
lilt lilt-dataflow-ingest-wpa-minio-cronjob-28856280-6p5jz 0/1 Completed 0 165m
lilt lilt-dataflow-segment-quality-cronjob-28856400-rr9rs 0/1 Completed 0 45m
lilt lilt-manager-ui-f54749467-sc6cf 2/2 Running 9 (5d1h ago) 5d1h
lilt linguist-core-7ddd8fcfbb-6rv8b 1/1 Running 0 5d1h
lilt llm-inference-neural-6bb49c48b6-mtfff 1/1 Running 0 5d1h
lilt localpv-provisioner-5cfff7dcb5-g2zc5 1/1 Running 0 5d1h
lilt memory-core-f697888d9-ccxxh 1/1 Running 0 5d1h
lilt minio-85c7cb7f85-kspj5 1/1 Running 0 5d1h
lilt mongodb-688f5c8c5b-zmh77 1/1 Running 0 5d1h
lilt mq-rabbitmq-0 1/1 Running 1 (5d1h ago) 5d1h
lilt mysql-0 1/1 Running 0 5d1h
lilt nvidia-device-plugin-42ntc 1/1 Running 0 5d1h
lilt nvidia-device-plugin-njpdp 1/1 Running 0 5d1h
lilt nvidia-device-plugin-rqqp9 1/1 Running 0 5d1h
lilt qa-core-5d474c46b4-sncqn 1/1 Running 3 (5d1h ago) 5d1h
lilt routing-neural-79df5944c5-m962l 1/1 Running 0 4d22h
lilt search-core-5f9ddbb697-b46q4 1/1 Running 0 5d1h
lilt segment-core-8545b9dbcf-v5jzc 1/1 Running 4 (5d1h ago) 5d1h
lilt tag-core-544c77757d-9qxm6 1/1 Running 4 (5d1h ago) 5d1h
lilt tb-core-795dbf757d-9nkl7 1/1 Running 0 5d1h
lilt tm-core-55c74c49cf-ntmqz 1/1 Running 0 5d1h
lilt translatev4-neural-6c46b4755d-s84n2 1/1 Running 0 5d1h
lilt update-managerv4-neural-77c89bf757-zs5d5 1/1 Running 0 5d1h
lilt updatev4-neural-6474b69644-kmxdh 1/1 Running 0 5d1h
lilt valid-words-replace-neural-7f9fc59958-hk8vw 1/1 Running 0 4d22h
lilt valid-words-update-neural-6956b97db9-gf5d4 1/1 Running 0 4d22h
lilt watchdog-core-67895dbc9d-pmg8n 1/1 Running 0 5d1h
lilt workflow-core-7bff648cf5-7b77g 1/1 Running 4 (5d1h ago) 5d1h
```
#### Step 2: Access Lilt Main Page
Once all pods are running/ready, connect to the LILT main page at `https://.` (the values set in `install.env`). Traffic enters through the Istio ingress gateway on the `LB_IP` address MetalLB assigned to it. Verify:
```bash theme={null}
kubectl -n istio-ingressgateway get svc istio-ingressgateway
```
The `EXTERNAL-IP` column must show the `LB_IP` value.
Create DNS records for `.` and the sibling hostnames pointing at that address. For a quick test without DNS, modify the `hosts` file on your local workstation:
```bash theme={null}
vi /etc/hosts
```
Add a line with the `LB_IP` address and the main hostname:
```bash theme={null}
10.10.3.240 lilt.example.com
```
Navigate to LILT using a browser at `https://./signin`:
![]()
After the admin password is set, LILT can be accessed via `https://./signin`.
![]()
#### Debugging
Depending on network speed(to download/upload containerd images) some of the pods can take more time than others, here are some known debugging techniques:
1. If you see
*Error: UPGRADE FAILED: timed out waiting for the condition*, please continue as this can happen due to time taken by the pods to startup, apps deployment happens as expected.
2. If you see pods stuck in
*ContainerCreating* for a longer time(>15 mins), it's safe to restart the pods by using `kubectl delete pod -n lilt `
1. If the apps aren't healthy even after all containerd images have been loaded to the node, it's safe to revert to previous version and redo the install, use below commands for the same:
```powershell theme={null}
master $ cd $install_dir
## Rollback
$ helm rollback lilt 1
## Clean-up jobs
$ kubectl delete jobs -n lilt --all
## Remove statefulset PVCs
$ kubectl get pvc -n lilt | grep elasticsearch $ kubectl delete pvc -n lilt
## Perform Install
$ ./install-lilt.sh
```
#### Flannel Error
Sometimes `flannel` does not load correctly on all nodes. Verify which node that the `flannel` init container does not complete and restart `containerd`:
```bash theme={null}
sudo systemctl restart containerd
```
#### Gateway Error 502
Sometimes after a server reboot the ingress gateway needs a restart to pick up new endpoints. Restart the `istio-ingressgateway` deployment:
```bash theme={null}
# restart the ingress gateway
kubectl rollout restart deployment/istio-ingressgateway -n istio-ingressgateway
```
#### CORE Pods
When a cluster is restarted, `core` pods may be stuck in `CrashLoopBackOff` because they cannot reach Elasticsearch. Restart the Elasticsearch StatefulSet first:
```bash theme={null}
kubectl rollout restart statefulset eck-cluster-es-default -n lilt
kubectl rollout status statefulset eck-cluster-es-default -n lilt
```
If the pods still do not recover, delete the Elasticsearch release and its volumes, then reinstall it.
This deletes the Elasticsearch data. The search index is recoverable: LILT can re-index it from the database. That is not a quick operation. It takes hours, and on a large corpus it can take days, during which search results are incomplete.
Delete the volumes while the storage provisioner is still running. Elasticsearch claims them through the StatefulSet's `volumeClaimTemplates`, which Helm never owned, so `helm uninstall` leaves them behind and they have to go separately. Once the provisioner is gone the PersistentVolumes stay `Released` and their data is stranded on the nodes.
Confirm the re-index time against your own data volume with LILT support before you start.
```bash theme={null}
# Remove the release.
helm uninstall eck-cluster -n lilt
# List its volumes, then delete the ones it owns.
kubectl get pvc -n lilt | grep eck-cluster
kubectl delete pvc -n lilt ...
# Reinstall.
sh install_scripts/install-elastic-eck-cluster.sh
```
Elasticsearch is deployed by the Elastic Cloud on Kubernetes (ECK) operator as of the July 2025 release. The Helm release is `eck-cluster`, not `elasticsearch`, and it is installed by `install-elastic-eck-operator.sh` followed by `install-elastic-eck-cluster.sh`. The older `install_scripts/install-elasticsearch.sh` no longer ships. If you are following an older runbook that calls it, use the two ECK scripts instead.
If some core pods are still not running, try to restart `lilt-beehive` deployment:
```bash theme={null}
kubectl rollout restart deployment/lilt-beehive -n lilt
```
#### GPUs
If GPUs are not working, verify that the expected number is allocated to the cluster:
```bash theme={null}
kubectl get nodes -o custom-columns=":metadata.name" | while read node; do kubectl describe node "$node" | grep -i "nvidia.com/gpu"; done
```
Output should similar to the following (GPU node shows 8, main and worker nodes show 0):
```bash theme={null}
nvidia.com/gpu: 8
nvidia.com/gpu: 0
nvidia.com/gpu 0
```
If the output shows zero for all nodes, reinstall GPU drivers from the above section and reapply nvidia-device-plugin `sh install_scripts/install-nvidia-device-plugin.sh`
#### Translate v4
Sometimes after a server reboot, translate pods will not initialize. This can be attributed to service endpoints not refreshing from the previous deployment. Possible solutions are restarting the `rabbitmq` statefulset and `minio` deployment:
```bash theme={null}
# restart rabbitmq
kubectl rollout restart statefulset/mq-rabbitmq -n lilt
# restart minio
kubectl rollout restart deployment/minio -n lilt
```
#### Restart all Deployments/Statefulsets
If have various pod failures, can also try and restart all Lilt deployments and statefulsets:
```
kubectl rollout restart deployment -n lilt
kubectl rollout restart statefulset -n lilt
```
## Reset Cluster
If there are any issues that can’t be resolved, as last resort reset each node in the cluster.
NOTE: reseting the cluster will not remove all configuration artifacts. Follow the onscreen output instructions from the below reset command.
#### All Nodes (master, worker, gpu)
Login to the each node and complete the following steps.
Commands have to be performed as root (since it involves installation of Kubernetes).
```bash theme={null}
sudo su -
```
Reset the node:
```bash theme={null}
kubeadm reset
```
Reinstall the cluster starting from the beginning of this document.
# Install System (AWS EKS)
Source: https://support.lilt.com/kb/install-system-aws-eks
This article describes how to install LILT on Amazon Elastic Kubernetes Service from the EKS install package. It covers configuration, the phased install, secrets, verification, and recovery.
## Overview
An EKS deployment has two layers:
1. **The AWS infrastructure**: a VPC and subnets, the EKS cluster and its node groups, an RDS MySQL instance, an S3 bucket, an SQS queue, a container registry, and the IAM roles the workloads assume.
2. **The LILT application stack**, deployed by `install-lilt-eks.sh`: Istio and the Gateway API routes, the data stores, and the LILT Helm charts.
Choose one of two paths for the first layer:
| Path | Use it when | Guide |
| ---------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------- |
| Terraform module | You want LILT to provision the infrastructure. The `lilt-aws-env` module ships in the install package. | [Provision AWS infrastructure with Terraform](/kb/install-aws-terraform-module) |
| Bring your own | You already have a cluster, or you provision AWS resources with your own tooling. | [Install on an existing EKS cluster](/kb/install-aws-existing-cluster) |
Both paths converge here for the second layer.
For a bare-metal or virtual-machine deployment, use the on-premises install package instead. See [Install System (Amazon Linux 2023 or Rocky 8/9)](/kb/install-system-amazon-linux-2023-or-rocky-8-9).
## Prerequisites
1. An EKS cluster, version 1.32 or later, with the EBS CSI driver installed. Version 1.35 is the tested default, and the LILT Terraform module creates 1.35.
2. Helm 4, plus `kubectl`, `aws`, and `jq` on your PATH.
Check your Helm version before you start.
```bash theme={null}
helm version --short # must report v4.x
```
Several component scripts use flags that exist only in Helm 4, among them `--rollback-on-failure` for ArgoCD and Argo Rollouts and `--server-side` for the Elasticsearch cluster and the LILT charts. On releases whose `install-lilt-eks.sh` does not check the version at startup, Helm 3 gets through the prerequisites and the data stores and then fails an hour in, reporting an unrecognised flag rather than the Helm version.
Add [crane](https://github.com/google/go-containerregistry) if you populate your registry with `seed-registry.sh`. The installer does not install it, and the script stops with `ERROR: crane not on PATH.` Skip it only if you mirror the release images by some other means.
3. An RDS MySQL instance, an S3 bucket, and an SQS queue that the cluster can reach.
4. A container registry the cluster can pull from, seeded with the release images. See [Seed your container registry](/kb/install-package#seed-your-container-registry).
5. IAM roles for the workloads that need AWS access, bound with EKS Pod Identity or IRSA.
6. The extracted install package. See [Install package](/kb/install-package).
Run the installer from a machine that can reach the Kubernetes API. Clusters created by the LILT Terraform module have a private API endpoint, so the install runs from inside the VPC. See [Install from a bastion](/kb/install-from-a-bastion).
## Node Kernel Settings
The EKS-optimized Amazon Linux 2023 AMI already carries the kernel modules, `sysctl` values and swap and SELinux settings that Kubernetes needs, so a cluster on the stock AMI needs nothing here.
Two settings are not part of that baseline and matter to LILT specifically. Check them on your nodes whichever AMI you use:
```bash theme={null}
# Istio's ztunnel restarts under load without a raised file-descriptor limit.
ulimit -n # want 131072
# Elasticsearch fails to start below this.
sysctl vm.max_map_count # want 262144
```
To set them, on each node:
```bash theme={null}
cat <> /etc/security/limits.conf
soft nofile 131072
hard nofile 131072
EOF
echo "DefaultLimitNOFILE=131072" >> /etc/systemd/system.conf
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf
sysctl --system
```
If you build your own AMI, or run a node OS that is not the EKS-optimized image, the Kubernetes baseline is yours to provide as well. Bake this into the image rather than applying it to running nodes, so replacements and scale-ups inherit it.
```bash theme={null}
# Kernel modules for kube-proxy and the Istio redirect rules.
cat <
## Configure the Install
Copy the template and edit it. Every variable the installer reads is documented there with its default.
```bash theme={null}
cp install.env.example install.env
chmod 0600 install.env
```
The file is organised by intent: identity, pre-existing resources, DNS and TLS, image registry, feature toggles, and the secret backend. Leave a line commented to keep the default shown next to it. Every variable is listed in the [install.env reference](/kb/install-env-reference).
The settings almost every install needs:
| Variable | Purpose |
| --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| `SUBDOMAIN`, `DNS_DOMAIN` | Every ingress hostname is `-.`. Both are required. |
| `AWS_REGION`, `AWS_ACCOUNT_ID` | Resource ARNs and registry hosts. The account ID defaults to your current caller identity. |
| `REGISTRY_BASE` | The registry to pull images from. |
| `S3_BUCKET`, `SQS_QUEUE_URL`, `DB_NAME` | The pre-existing resources to use. |
| `CONNECTORS_ADMIN_PASSWORD` | The `admin` login for the `/connectors-admin` console. The install stops with an error if this is unset, so choose one before you start. |
| `SECRET_BACKEND` | `seed`, `vault`, or `aws`. Defaults to `seed`. |
| `IAM_AUTH_METHOD` | `irsa` or `pod_identity`. Defaults to `irsa`. It must match how your IAM roles are actually bound, or every AWS call from a pod fails. |
| `PREFIX` | Optional. Set it to the Terraform module's `prefix` and the installer derives the resource names for you. |
## How the Installer Works
`install-lilt-eks.sh` is a flat sequence of component scripts. Each one:
* Prints `--- Installing ---` before it runs, so the last such line names the component that failed.
* Checks its own `ENABLE_` variable and exits without doing anything when that variable is not `true`.
* Uses `helm upgrade --install`, which is a no-op when the chart and its values are unchanged.
Together these three properties make the whole script safe to re-run from the top. That is the intended recovery path.
### Component Flags
Set any of these to `false` in `install.env` to skip that component.
**Optional components, enabled by default:**
`ENABLE_CLUSTER_AUTOSCALER`, `ENABLE_MONGODB`, `ENABLE_CLICKHOUSE`, `ENABLE_DRAGONFLY_OPERATOR`, `ENABLE_CACHE_DRAGONFLY`, `ENABLE_RABBITMQ`, `ENABLE_ECK_OPERATOR`, `ENABLE_ECK_CLUSTER`, `ENABLE_ARGOCD`, `ENABLE_ARGO_ROLLOUTS`, `ENABLE_ARGO_WORKFLOWS`, `ENABLE_PROMETHEUS`, `ENABLE_METRICS_SERVER`, `ENABLE_ISTIO_INGRESSGATEWAY`, `ENABLE_QDRANT`, `ENABLE_PROXY_SQL`, `ENABLE_WSO2`, `ENABLE_MYSQL_CLIENT`, `ENABLE_RAY_OPERATOR_CRDS`, `ENABLE_RAY_OPERATOR`, `ENABLE_RAYMAN`, `ENABLE_LILT_CHARTS`, `ENABLE_EXTERNAL_SECRETS`, `ENABLE_VAULT`, `ENABLE_NVIDIA_GPU_OPERATOR`.
**Optional components, disabled by default:**
| Flag | Component |
| ---------------------- | --------------------------------------------- |
| `ENABLE_DNS` | Route53 record creation |
| `ENABLE_CERT_MANAGER` | cert-manager with Route53 DNS-01 |
| `ENABLE_SEED_REGISTRY` | Copying the release images into your registry |
`install.env.example` also lists `ENABLE_DATADOG` and `ENABLE_OTELCOL`. Neither entrypoint calls an installer for them, and neither component ships in the tarball, so setting these has no effect on a customer install.
**Prerequisites, enabled by default:**
`ENABLE_NAMESPACE`, `ENABLE_CLEANUP_STALE_PODS`, `ENABLE_CLUSTER_PREREQS`, `ENABLE_RDS_SECRETS`, `ENABLE_S3_IRSA`, `ENABLE_RDS_LILT_USER`, `ENABLE_DATABASE_BOOTSTRAP`, `ENABLE_PREINSTALL_ISTIO_CRDS`, `ENABLE_GATEWAY_API_CRDS`, `ENABLE_ISTIOD`, `ENABLE_LILT_NETWORKING`.
Prerequisites are foundational, and everything after them depends on them. Disable one only on a cluster where that step has already completed.
Dependency order matters among the optional components too. The ECK operator has to exist before its cluster, the Ray operator before Rayman, and ProxySQL fronts the database.
### Phased Bring-Up
Bringing the infrastructure and data stores up first, and the application afterwards, makes a failure much easier to attribute.
**Phase 1: infrastructure and data stores.** Add these lines to `install.env`:
```bash theme={null}
ENABLE_ARGOCD=false
ENABLE_ARGO_ROLLOUTS=false
ENABLE_ARGO_WORKFLOWS=false
ENABLE_PROMETHEUS=false
ENABLE_QDRANT=false
ENABLE_PROXY_SQL=false
ENABLE_WSO2=false
ENABLE_MYSQL_CLIENT=false
ENABLE_RAY_OPERATOR_CRDS=false
ENABLE_RAY_OPERATOR=false
ENABLE_RAYMAN=false
ENABLE_LILT_CHARTS=false
```
Run the installer, then confirm that the data stores are healthy:
```bash theme={null}
sh install-lilt-eks.sh
kubectl get pods -n lilt
```
**Phase 2: the full stack.** Remove those lines so each component reverts to its default, and run the installer again.
## Secrets
`SECRET_BACKEND` selects where the installer reads application secrets from: `seed` (the default, from the file in the tarball), `vault`, or `aws`. LILT also ships an in-cluster HashiCorp Vault as the default External Secrets Operator backend.
The seed file holds placeholder values, most of them the literal string `dummypass`. Do not run a production install with them. On EKS the file is overwritten from the seed on every run while `SECRET_BACKEND=seed`, so edits there do not persist.
See [Secrets and Vault](/kb/secrets-and-vault) for the backend comparison, the full Vault path and key table, the per-secret path overrides, `seed-vault-secrets.sh`, and how to point LILT at a Vault or AWS Secrets Manager you already run.
## Override Values
Every `.yaml` file under `lilt/environments/lilt/values.d/` is applied after the environment overlay. Drop a whole override file in there rather than editing the values files the installer ships. Your overrides then survive an upgrade.
GPU sizing and single sign-on are configured the same way, by copying a shipped profile into that directory. See [GPU profiles and values overlays](/kb/gpu-profiles-and-values-overlays) for the profile tables, the memory and compute-capability floors, and the rule for combining files.
## Single Sign-On
LILT ships with external SSO disabled, so password sign-in works out of the box and no install points at an identity provider you do not control.
To connect a provider, copy a file from `lilt/sso-profiles/` into `lilt/environments/lilt/values.d/`, then add the client secret as the `singleOidcClientSecret` key of the `lilt-secrets` secret. See [GPU profiles and values overlays](/kb/gpu-profiles-and-values-overlays#single-sign-on-profiles) for the full value list.
Set `SINGLE_OIDC_PROVIDER_ENABLED=true` only when every other `SINGLE_OIDC_PROVIDER_*` value is filled in. With one of them empty, `front` fails its startup validation and the pod crashes.
## Run the Install
```bash theme={null}
sh install-lilt-eks.sh 2>&1 | tee /var/log/lilt-install.log
```
Budget roughly two hours. Keep the log: when something fails 90 minutes in, it is the only account of what happened.
## Verify
```bash theme={null}
# Anything not Running or Completed needs a look.
kubectl get pods -n lilt | grep -v Running | grep -v Completed
# The ingress load balancer should have an address.
kubectl get svc -n istio-ingressgateway
# The application should answer through the ingress.
curl -sS -o /dev/null -w '%{http_code} verify=%{ssl_verify_result}\n' https://./
```
Read them outwards from the cluster. The first command filters to pods that need attention, so no output is the result you want. The second should show a hostname in `EXTERNAL-IP`, not ``. The third tests DNS, the load balancer, the gateway and the certificate in one request: any status code means it reached the gateway, and `verify=0` means the certificate chain validated. A chain missing its intermediate still satisfies a browser that has cached it, and fails later in a stricter client.
For the same checks with the failure modes spelled out, see [Install from a bastion](/kb/install-from-a-bastion#step-6-verify).
## Resuming a Failed Install
The installer runs with `set -e`, so it stops at the first failing component and the last `--- Installing ---` line names it.
1. Inspect the component that failed:
```bash theme={null}
kubectl get pods -n lilt
kubectl describe pod -n lilt
kubectl logs -n lilt
```
2. Fix the underlying cause: a missing value, an unreachable dependency, or a resource limit.
3. Run the installer again from the top. Components that already succeeded are no-ops.
To skip a component you have already dealt with, set its flag for that run only:
```bash theme={null}
ENABLE_MONGODB=false sh install-lilt-eks.sh
```
### Common Failures
**A pod stays in `ContainerCreating` for more than 15 minutes.** The image is usually still pulling. The neural images are tens of gigabytes. Check `kubectl describe pod` for a pull error before you intervene.
**`UPGRADE FAILED: timed out waiting for the condition`.** A component took longer to become ready than its timeout allowed. Confirm the pods are healthy and run the installer again.
**A pod cannot reach S3.** Check that the service account carries no `eks.amazonaws.com/role-arn` annotation if the cluster uses EKS Pod Identity, and that no static AWS credentials are set in the secrets file. Either one overrides workload identity.
## Uninstall
To remove LILT and leave the data in place:
```bash theme={null}
sh uninstall-lilt.sh
```
The script tears the stack down in dependency order: application, then data services, then platform. It also removes the objects Helm never owned, which a bare `helm uninstall` leaves behind.
Data volumes are kept by default. To destroy them as well, opt in on the command line:
```bash theme={null}
WIPE_DATA=true sh uninstall-lilt.sh
```
To remove the installer's custom resource definitions too:
```bash theme={null}
PURGE_CRDS=true sh uninstall-lilt.sh
```
Pass `WIPE_DATA` and `PURGE_CRDS` on the command line only. Never put them in `install.env`, which persists across installs.
To decommission an environment entirely, run the uninstall before you destroy the AWS resources. Destroying them first leaves the load balancer and the volumes behind persistent volume claims still attached to network interfaces, and the VPC deletion hangs.
Neither form removes the AWS resources themselves. Delete those separately, or with `terraform destroy` if you created them with the module.
## Related Articles
* [Install package](/kb/install-package)
* [Provision AWS infrastructure with Terraform](/kb/install-aws-terraform-module)
* [Install on an existing EKS cluster](/kb/install-aws-existing-cluster)
* [Install from a bastion](/kb/install-from-a-bastion)
* [Self-managed hardware requirements](/kb/self-managed-hardware-requirements)
* [Infrastructure release notes](/kb/infrastructure-release-notes)
# Instant Translate Files
Source: https://support.lilt.com/kb/instant-translate-documents
LILT's Instant Translate Files feature allows for easy batch translation of multiple documents (of the same source language) at the same time using LILT’s Contextual AI Engine. This tool is convenient when you want to quickly translate content without having to commit to using a dedicated translator and reviewer.
## LILT Instant File translation
The **Translate files** tab allows you to submit files for translation. This section outlines step-by-step guidance to send content to LILT for an expert-verified translation.
1. Upload or drag and drop the files you want to send for instant translation.
2. Set your source and target languages. The system will automatically detect the source language (if text-based), and surfaces the right models approved for the domain and user, eliminating the risk of submission errors.
3. Toggle "Receive an expert-verified translation" OFF.
![Image]()
4. Optionally, select if you'd like to send your document for Customer Verification (Secondary Review stage) following the instant translation. You can assign this to anyone in your org or domain. You can also assign a review by date.
* For PDF and image files, you can additionally enable **Review extracted text before translation** under Additional options. When enabled, the job pauses after LILT processes your PDF or image so you can review and edit the extracted text before translation begins.
* To assign a reviewer from users within your domain and organization, you will need to be in a Customer, Manager, or Admin role, or in a [Custom Role](https://support.lilt.com/kb/custom-roles) that has the "Assign Reviewer" permission set.
![Image]( "Image")
5. Click "Translate". Your job will queue for instant file translation. Feel free to leave the page during translation.
![Image]()
6. If you stayed on the page, your translated files will be available for download once translation is complete. You can download individual files, or all at once.
![Image]()
7. If you left the page during instant translation, click on "View job" to access your translated files through the notification panel.
![Image]()
# AI Only User Role
Source: https://support.lilt.com/kb/instant-translate-homepage
## Overview
The AI Only user role & home view provides quick access to all available language models while restricting access to other platform features. This streamlined interface is designed for organizations that need rapid AI translation without full platform access.
Users in an AI Only role cannot access verified translations, user management, or view current or past translation projects.
![Image]()
## How to setup
1. As an Admin user, navigate to Manage > Users. Select the Role tab, and click "New role".
![Image]()
2. Create an AI Only User Role. Set Default Home view as "AI Only Home" and Role type as "AI Only".
![Image]()
3. Enable permissions for the role.
* Enable Create/Edit permissions for "Instant Translate".
* Enable Upload/Download permissions for "Files".
![Image]()
4. Navigate to Users and User Management. Set the new Instant Translate Role for an existing user.
![]()
*NOTE: Users can only be assigned either the Instant Translate Homepage role or other organizational roles—not both simultaneously. Users with the Instant Translate Homepage role will have exclusive access to the instant translation interface and cannot access other platform features.*
# Type and translate
Source: https://support.lilt.com/kb/instant-translate-text
Type and translate allows you to translate a block of text using your custom LILT models. This is convenient for when you want to quickly translate content without having to commit to using a dedicated translator and reviewer.
To access, navigate to the Type & Translate tab. LILT will instantly translate your text as soon as you begin typing. Change the source and target languages as needed; LILT will leverage the default model for the selected language pair.
* If you have more than one model configured for the language pair selected, you will see an option to select which model you would like to use.
![Image]()
### Third party model support
If your models have been configured with a third-party provider instead of with LILT, please note that these translations may take longer.
# Instant Video Dubbing
Source: https://support.lilt.com/kb/instant-video-dubbing
With instant video dubbing, you can submit videos to be instantly translated and dubbed using your existing custom LILT models to increase quality and brand accuracy. This workflow is ideal for short-form videos with one speaker, such as product training videos, launch announcement, or internal communications. Instant video dubbing takes only minutes to receive a fully dubbed video!
This is a self-service feature for instant video translation & dubbing, as compared to the wide range of other multimedia LILT supports through its verified translation services offering.
## Supported languages
LILT supports video dubbing for any two languages within a below system.
| **System** | **Language grouping (Any two)** | **Codes** |
| ---------- | --------------------------------------------------------------------------------- | ---------------------------------- |
| 1 | English, German, Spanish, French, Italian, Portuguese | EN, DE, ES, FR, IT, PT |
| 2 | English, Japanese, Korean, Chinese (Simplified), Chinese (Traditional) | EN, JA, KO, ZH, ZT |
| 3 | English, Bulgarian, Czech, Croatian, Polish, Romanian, Russian, Slovak, Ukrainian | EN, BG, CS, HR, PL, RO, RU, SK, UK |
| 4 | English, Danish, German, Greek, Finnish, Hungarian, Dutch, Swedish, Turkish | EN, DA, DE, EL, FI, HU, NL, SV, TR |
| 5 | English, Arabic, Hindi, Tamil | EN, AR, HI, TA |
| 6 | English, Indonesian, Malay | EN, ID, MS |
## File structure
Instant video dubbing supports videos that are:
* Up to 2GB. Please see [supported file types](/kb/supported-file-formats#SupportedFileFormats-Audio/Videofiles) for formats accepted.
* Single speaker
* Single language
## Submitting a video for instant dubbing
1. Select Translate on the LILT homepage, and upload your video file. You can optionally add a subtitle file, which will bypass the text extraction step. If you don't add a subtitle file, LILT will extract text to be translated and dubbed using your configured [AI provider](https://support.lilt.com/kb/3rd-party-llm-support-for-the-contextual-ai-engine#ai-providers).
![Image]()
2. Set your source and target languages, and make sure that the toggle for "Receive an expert-verified translation" is toggled off.
![Screenshot2026 01 30at12 09 26]()
3. Under Additional Options, toggle "Dubbing for videos" on and select a voice for your dub. You can listen to each voice before selecting one. Select whether you want to "Review extracted text before translation". Click "Translate" in the lower right corner and your job will be queued.
![Image]()
4. If you didn't upload a subtitle file and there is text to extract, LILT will begin extracting the text.
![Image]()
5. If you selected "Review extracted text", you have the opportunity to make any necessary changes to the extracted text and timestamps. Once you're satisfied with the source text, click on "Mark reviewed". Click on "Mark as reviewed" and then "Text review completed" to instantly translate the content.
![Image]()
6. LILT will then use your selected custom model to instant translate the video.
![]()
7. After the instant translation is completed, review and make any changes to the instant translated text. This might involve adjusting words per caption, or broken words/phrases. You can also adjust the time stamps and click the "Play" button next to each segment to hear the dubbed segment. Once you are satisfied with the translated text, click "Mark as reviewed", then "Text review completed".
![Image]()
8. Your video will be dubbed into the target language selected.
![]()
9. Once the dubbing has been completed, you can view your dubbed video in the platform. You also have options to "Download all", which will download both the Dubbed video (.mp4) and the subtitle file (.srt).
*Please note: LILT does not support re-integration of the subtitle file into the dubbed video at this time.*
![Image]()
10. At any point during the text extraction, instant translation, or dubbing, you can leave the instant video dubbing screen. Progress notifications will appear in your notification tray when the step completes and you can access the in progress project.
![Image]( "Image")
## Best practices
1. Managing segment lengths is key to a high-quality dub. Try to match the length of your source and target segments as much as possible. You can copy/paste text from one segment to another to preserve the instant translation. Additional considerations:
1. Keep the subtitles concise: Maximum 2 lines per subtitle.
2. The standard reading speed is 12 words per subtitle.
3. Subtitle lines should end at natural linguistic breaks.
4. Do not break a person's name or title from within a line.
5. Always start sentences in capital letters.
2. After instant translation, you can use the play button next to each target segment to hear what the segment sounds like using your selected voice.
1. If you hear the voice speaking very quickly, consider shortening the text in the target segment, or extending the time stamp for the segment.
2. If you hear the voice speaking very slowly, consider lengthening the text in the target segment, or shortening the time stamp for the segment.
![]()
# Instructions To Delete Container Images
Source: https://support.lilt.com/kb/instructions-to-delete-container-images
## Docker
To delete images in Docker, you can use the `docker rmi` or `docker image rm` commands. Here are the steps:
1. **List the Docker images**: Before you can delete an image, you need to know its ID or name. You can list all Docker images on your system with the `docker images` command:
```
docker images
```
This will display a list of all Docker images along with their repository name, tag, image ID, creation date, and size.
2. **Delete a Docker image**: Once you have the image ID or name, you can delete the image. Replace `` with the ID of the image you want to delete:
```python theme={null}
docker rmi
```
Or, if you prefer to use the image name and tag, replace `:` with the name and tag of the image you want to delete:
```ruby theme={null}
docker rmi :
```
3. **Delete all Docker images**: If you want to delete all Docker images, you can use the following command:
```javascript theme={null}
docker rmi $(docker images -q)
```
This command uses `docker images -q` to list all image IDs and then passes them to `docker rmi` to delete them.
Please note that you cannot delete an image that is being used by an existing container. You would first need to delete or stop the container that is using the image.
## containerd
To delete images in containerd, you can use the `ctr` command-line interface. Here are the steps:
1. **List the containerd images**: Before you can delete an image, you need to know its ID or name. You can list all containerd images on your system with the `ctr images ls` command:
```bash theme={null}
ctr images ls
# if no images are listed, use namespace
ctr -n k8s.io images ls
```
This will display a list of all containerd images along with their name and size.
2. **Delete a containerd image**: Once you have the image ID or name, you can delete the image. Replace `` with the name of the image you want to delete:
```bash theme={null}
ctr images rm
# use namespace if necessary
ctr -n k8s.io images rm
```
3. **Delete all containerd images**: If you want to delete all containerd images, you can use the following command:
```bash theme={null}
ctr images ls -q | xargs -r ctr images rm
# use namespace if necessary
ctr -n k8s.io images ls -q | xargs -r ctr images rm
```
This command uses `ctr images ls -q` to list all image names and then passes them to `ctr images rm` to delete them.
Please note that you cannot delete an image that is being used by an existing container. You would first need to delete or stop the container that is using the image.
# Integrate Your Workflow With LILT
Source: https://support.lilt.com/kb/integrate-your-workflow-with-lilt
LILT has the ability to integrate with other software to streamline communication and project management throughout the localization process.
![]()
LILT integrates with the following software:
* [Jira](/kb/jira)
# Intercom
Source: https://support.lilt.com/kb/intercom
LILT + Intercom connector enables companies to automatically push and pull Help Center content between Intercom and LILT. This saves you time by providing seamless localization while letting you continue to work in the systems you know.
The connector supports:
* **Submission via Intercom:** Select one or many Intercom Help Center [Sections](https://www.intercom.com/help/en/articles/56647-create-useful-collections-for-customers-to-explore), [Collections](https://www.intercom.com/help/en/articles/56647-create-useful-collections-for-customers-to-explore), or Articles to send to LILT for localization.
* **Deliver to Intercom:** LILT delivers localized content to Intercom as a multilingual article.
## Configuration
At a high level, the installation steps are as follows:
1. Create a new Intercom App.
2. Provide LILT with Intercom credentials (authorization token + client ID).
3. Define the target languages to be localized.
To set up your LILT + Intercom connector:
1. Add LILT as a `New app` within the Intercom Developer Hub. This can be accomplished by navigating to `Profile`>`Settings`>`Developers`>`Developer Hub` and clicking the `New app` button. For the purposes of this tutorial, we will name the app "LILT Connector".
![]()
2. Provide LILT with your Intercom Client ID and Intercom Access Token.
* The Client ID can be located in the LILT App by navigating to `Profile`>`Settings`>`Developers`>`Developer Hub`>`LILT Connector`>`Basic`.
![]()
* The access token can be located in the newly created LILT App by navigating to `Profile`>`Settings`>`Developers`>`Developer Hub`>`LILT Connector`>`Authentication`. Your Intercom Access Token will be listed under the `Access token` section.
![]()
3. Add the target languages to be localized. This can be accomplished in Intercom by heading to `Articles`>`Help Center`>`Settings`>`Localize your Help Center`.
![]()
4. By default, the connector will localize all Intercom Help Center [Collections](https://www.intercom.com/help/en/articles/56647-create-useful-collections-for-customers-to-explore). If you want to localize certain Collections, provide LILT with the Collection IDs for those Collections. To locate a Collection ID, open the Collection and copy the 7-digit ID from the URL bar.
![]()
## Workflow
Once the connector is configured, content is automatically moved between LILT and Intercom as outlined in the sections below.
### Project creation
LILT periodically checks for new articles that have been published in any Intercom Help Center Collections that LILT is tracking. When articles move to a published state, the content is automatically pulled into LILT for localization. The connector creates one LILT project per language pair.
### Project completion
Once content has been localized in LILT, the target content is delivered back to Intercom Help Center. Each localized article can be found within the article editor. From the article editor, the target article can be previewed and published.
![]()
# Introduction To LILT For Project Managers
Source: https://support.lilt.com/kb/introduction-to-lilt-for-project-managers
This article provides an entry point for project managers into both the LILT Platform and the LILT Knowledge Base.
*To help solidify your knowledge, follow along in the LILT Platform as you read through the various articles listed below.*
## Core concepts
Read through the following articles to understand the basics of LILT Translate that you will need as a project manager:
* [Introduction to LILT Translate](/kb/introduction-to-lilt-translate)
* [Tags & Formatting](/kb/tags-formatting)
* [Non-Translatables](/kb/non-translatables)
* [Bi-Directional Text Marks](/kb/bi-directional-text-marks)
* [Terminology](/kb/terminology)
* [Overwrite Confirmed Segments](/kb/auto-propagation)
Read through all the articles in the following sections:
* [Settings & Organization Management](/kb/organization-settings): Manage the users and settings for your LILT organization.
* [Navigating the Jobs list](https://support.lilt.com/kb/navigating-the-jobs-list): Create and manage your jobs.
* [Managing Data Sources and Memory Entries](https://support.lilt.com/kb/managing-your-lilt-memories): Create and manage translation resources (Custom Models, Data Sources, Termbases).
# Linguist Getting Started
Source: https://support.lilt.com/kb/introduction-to-lilt-for-reviewers
This article provides an entry point for linguists into both the LILT Platform and the LILT Knowledge Base.
*To help solidify your knowledge, follow along in the LILT Platform as you read through the various articles listed below.*
## Core concepts
Learn the core features you will need in order to perform the role of reviewer in LILT:
1. [Introduction to LILT Translate](/kb/introduction-to-lilt-translate)
2. [LILT Linguist Homepage](/kb/lilt-linguist-homepage)
3. [Translating Documents](/kb/translating-documents) and [Reviewing Documents](/kb/reviewing-documents)
4. [Segment State Indicators](/kb/segment-state-indicators)
5. [Segment Comments](/kb/segment-comments)
6. [Split & Merge Segments](/kb/split-merge-segments)
7. [Tags & Formatting](/kb/tags-formatting)
8. [Non-Translatables](/kb/non-translatables)
9. [Bi-Directional Text Marks](/kb/bi-directional-text-marks)
10. [Hotkeys](/kb/hotkeys)
11. [Translation Memory Suggestions](/kb/translation-memory-suggestions)
12. [Contextual AI](/kb/machine-translation)
## Advanced concepts
Learn to use LILT's tools to make your review process more efficient:
* [Source Highlighting Tool](/kb/source-highlighting-tool)
* [Segment Context](/kb/segment-context)
* [Concordance](/kb/concordance)
* [Terminology](/kb/terminology)
* [Find & Replace](/kb/find-replace)
* [In-Context Preview](/kb/monolingual-preview)
* [Auto Review](/kb/quality-assurance-tools):
* [Linguistic Quality Assurance](/kb/quality-assurance-tools)
* [Tags Quality Assurance](/kb/tags-quality-assurance)
* [Neural Auto Review](/kb/quality-assurance-tools)
* [Overwrite Confirmed Segments](/kb/auto-propagation)
* [TM Leveraging](/kb/tm-leveraging)
* [Data Source Memory Matching](/kb/translation-memory-matching)
# Introduction To LILT Translate
Source: https://support.lilt.com/kb/introduction-to-lilt-translate
LILT Translate/Verify is a computer-aided translation (CAT) editor that enables you to create high-quality multilingual content. LILT Translate incorporates a wealth of AI-powered features and tools that enable efficient workflows for content translators and reviewers.
![]()
## Editor modes
LILT Translate has two modes that are largely the same (including [hotkeys](/kb/hotkeys)).
* [Translate mode](/kb/translating-documents) empowers translators by leveraging the [LILT Contextual AI Engine](/kb/lilt-translate-engine), a self-learning neural translation system with integrated data sources for historical translation leverage.
* [Review mode](/kb/reviewing-documents) empowers reviewers by leveraging the [LILT Review Engine](/kb/lilt-review-engine), an AI-powered quality assurance tool.
Mode differences:
* In Translate mode, segments are confirmed. In Review mode, segments are accepted. Unconfirmed and confirmed segments can still be edited in both modes, while accepted segments can only be edited in Review mode.
* [Translators add comments, while reviewers add error flags/annotations](/kb/segment-comments).
How to access the different modes:
* Users assigned to a document as a **translator** can only open the document in **Translate mode**.
* Users assigned to a document as a **reviewer** can only open the document in **Review mode**.
* Users with a [**manager or admin role**](/kb/default-roles) can open the document in either **Translate** or **Review mode**.
*Project managers can assign translators and reviewers to documents as described in the [Document Actions](/kb/document-actions) article.*
In LILT Translate, the editor mode is displayed in the upper-right as
![]()
or
![]()
.
![]()
Both editor modes share the same layout. The layout is outline in the sections below:
* [Segment editor](/kb/introduction-to-lilt-translate#h_01FA621FFWH9TNJKH9BGQEW8B6)
* [Sidebar](/kb/introduction-to-lilt-translate#h_01F3R82ENNBPF6TC789BFQC7FV)
* [Document information footer](/kb/introduction-to-lilt-translate#h_01FA623EMZDA5EAXX75WXP98ZQ)
* [Toolbar](/kb/introduction-to-lilt-translate#h_01FA6219V53VNSSAKSENERWBVQ)
## Segment editor
When opening a document into LILT Translate, you will find the document's source text divided into numbered segments. The segment in focus (the active segment) has several components:
![]()
1. **Segment number**
2. **Source text (ST)**
3. **Target text (TT) typing area:** You can type in your translation manually, or insert a suggestion from the suggestion area. Alternatives for the next word to insert may appear in this area as ghost-words. At the far right of the typing area, there is a number display for how many characters are inside the typing area.
4. **AI translation suggestion area:** Displays suggested translations. TM matches above 75% are shown first. If a match does not exist, the interactive MT output appears. This section updates as you type. You can click on any of the suggested words to add that word to the typing area. You can learn more about suggestions in the [Data Source Memory Matching](/kb/translation-memory-matching) article.
5. **Segment editing tools:** Allows linguists to [Split & Merge](/kb/split-merge-segments) segments, in addition to the actions for `Copy source to target` and `Insert full suggestion`.
6. [**Segment comments**](/kb/segment-comments): Allows linguists to add comments (in Translate mode) or flag errors (in Review mode).
7. [**QA**](/kb/quality-assurance-tools): Performs a QA check on the segment and raises any found errors.
8. [**Segment state indicator**](/kb/segment-state-indicators): The checkmark on each segment lets linguists confirm (for Translate mode) or accept (for Review mode) the segment to mark it as complete. Once confirmed/accepted, the segment will display a green checkmark (for confirmed) or a double green checkmark (for accepted) next to the segment number, and the checkmark in the bottom-right will turn into a cross that be clicked to unconfirm/unaccept the segment.
In addition, segments have the following features:
* [**Source Highlighting Tool**](/kb/source-highlighting-tool): Provides quick access to terminology information upon selecting source text.
* [**Terminology**](/kb/terminology): Any source phrases that match entries in the termbase are highlighted. Hovering over a highlighted phrase provides linguists with terminology information.
* [**Bi-Directional Text Marks**](/kb/bi-directional-text-marks): Segments support markers to allow linguists to orient phrases in a direction opposite to the direction of the language (left-to-right or right-to-left).
* [**Non-Translatables**](/kb/non-translatables): Segments support special tags for content that should not be translated, prohibiting linguists from modifying any content within a non-translatable tag.
## Sidebar
![]()
The sidebar on the right holds the following tools for easy access during translation:
* [**Segment Context**](/kb/segment-context): Segment context provides translation information about the segment selected.
* [**Concordance**](/kb/concordance): The Concordance tab gives in-context examples of how a word of phrase is used in the target language.
* [**Find and Replace**](/kb/find-replace): The find and replace tool allows linguists to search for text across the document.
## Document information footer
![]()
At the bottom, the document information footer provides linguists with the following:
* Name of the document.
* Language pair.
* Current segment number, total number of segments, and how many segments have been confirmed/accepted.
* Word/segment display:
* **Translate mode:** Number of words translated and the total number of words in the document.
* **Review mode:** Number of segments reviewed and total number of segments in the document.
* Linguists can navigate to a specific segment by typing a number into the segment text box.
* Estimate of how much time it will take to finish translating/reviewing the document.
## Toolbar
The toolbar at the top has a range of options available for managing and customizing your experience with LILT Translate. Each tab of the header is described in the subsections below.
* [File](/kb/introduction-to-lilt-translate#h_01FNJFF8QRJ54Y5ADC1P5ATEGC)
* [Edit](/kb/introduction-to-lilt-translate#h_01FNJFFEBGWDWVG7KWXCXCNTCD)
* [View](/kb/introduction-to-lilt-translate#h_01FNJFFJV3XGT3G4JPHNCHAGBQ)
* [Insert](/kb/introduction-to-lilt-translate#h_01FNJFFQEJXQ91KXEZ08YSKNPY)
* [Tags](/kb/introduction-to-lilt-translate#h_01FNJFFWA2M4JHJQX51WNRY88R)
* [Settings](/kb/introduction-to-lilt-translate#h_01FNJFG0SVKK4S4VSJRSH32T46)
### File tab
![]()
The `File` tab provides several actions to help manage documents.
* **Download:** Use this option to download the translated document in one of three formats:
* **Option 1:** original format
* **Option 2:** TXT format
* **Option 3:** XLIFF format
* **Unlock document translation:** If the document has been locked for translation, the project manager can use this option to unlock the document in Translate mode so it can be worked on again by translators. For more information on this, see the [CAT Guide for Project Managers](/kb/lilt-translate-guide-for-project-managers).
* [**QA checks**](/kb/quality-assurance-tools): There are two types of QA checks that can be run from the `File` menu: full QA checks and linguistic batch QA checks.
### Edit tab
The `Edit` tab contains a list of commonly used actions to help speed up your work within LILT Translate.
![]()
* **Undo (shortcut `Ctrl` + `Z`):** Undo the last edits that were made in the segment editor.
* **Select next word (**`Shift`\*\* + **`Tab`**):\*\* Select the next suggested word from the suggestion area below the typing text.
* [**Concordance**](/kb/concordance)\*\* (**`Ctrl`** + **`Alt`** + **`C`**):\*\* Opens the Concordance sidebar.
* [**Find and Replace**](/kb/find-replace)\*\* (**`Ctrl`** + **`H`**):\*\* Search for text in all typing areas of the document. Includes the option to require the whole word to match, require the case to match, and to search through the entire Project instead of just the document.
![]()
* **Highlight to change case (**`Shift`\*\* + **`F3`**): \*\*Changes the case of the currently selected section of target text.
### View tab
The `View` tab options affect how segments are displayed in LILT Translate.
![]()
* **Segments:**
* Filter segments by status:
* **All segments:** Segments with any confirmed/accepted status.
* **Confirmed:** Segments that have been confirmed in [Translate mode](/kb/translating-documents).
* **Unconfirmed:** Segments that have **not** been confirmed in Translate mode.
* **Unreviewed:** Segments that have **not** been accepted in [Review mode](/kb/reviewing-documents).
* **Reviewed:** Segments that have been accepted in Review mode.
* **Changed:** Segments that have been modified and confirmed during the current user session.
* Filter segments by additional content:
* **Segments with notes:** Segments with notes added in Translate mode.
* **Segments with errors:** Segments with errors added in Review mode.
* **Segments with tags:** Segments that have tags in their content.
* **Locked:** Segments that are confirmed, reviewed, or locked.
* Both these filter sections compound with each other.
* To remove a filter, click the filter again.
![]()
* **Previous segment** (`Ctrl` + `Up Arrow`): Navigate up through the document, segment by segment.
* **Next segment (**`Ctrl`\*\* + **`Down Arrow`**):\*\* Navigate down through the document, segment by segment.
* [**Preview mode**](/kb/monolingual-preview): Toggles between segment edit mode and preview mode. Preview mode displays confirmed or accepted target segments with paragraph and HTML formatting.
* **Split view:** With split view disabled (the default setting), target text is displayed beneath the source text. If split view is enabled, target text is displayed to the right of the source text. Split view helps increase proofreading speed.
![]()
* **Show invisible characters:** When enabled, displays characters that are normally invisible (such as spaces, tabs, right-to-left marks, and left-to-right marks) in both the source and target text.
![]()
### Insert tab
The `Insert` tab has a range of tools for interacting with text in the segment editor.
![]()
* **Suggested phrase (**`Enter`**):** Insert the suggested word into the target text field.
* **Full suggestion (**`Shift`\*\* + **`Enter`**):\*\* Insert the full suggested sentence into the target text field.
* **Non-breaking spaces (**`Ctrl`\*\* + **`Shift`** + **`Space`**)\*\* : Insert a non-breaking space into the target text field. These can be useful in certain situations, as the non-breaking spaces do not get erased in document formats that ignore extra spaces, such as HTML.
* **Line break (**`Alt`\*\* + **`Enter`**)\*\*: Adds a line break on the currently selected line in the target text field. Line breaks can also be copied from source text to target text by using the `Copy source to target` option in the segment editing tools.
* **Copy source to target (**`Ctrl`\*\* + **`I`**):\*\* Inserts the source text into the target text field. This is useful if a segment does not have to be translated for whatever reason.
* **Add new term (**`Alt`\*\* + **`A`**):\*\* Opens a popup where you can add a new translation entry to the associated Data Source.
* **Add comment (**`Ctrl`\*\* + **`Alt`** + **`M`**):\*\* Add a comment to the currently selected segment. These are the same comments you can add using the `View Note` button
![]()
next to a segment.
* **Insert right-to-left mark (**`Ctrl`\*\* + **`K`**):\*\* Inserts an invisible right-to-left mark character into the target text field. These are used to determine how the adjacent characters are grouped in respect to text direction.
* **Insert left-to-right mark (**`Ctrl`\*\* + **`L`**):\*\* Inserts an invisible left-to-right mark character into the target text field. These are used to determine how the adjacent characters are grouped in respect to text direction.
### Tags tab
The `Tag` tab provides tools for manipulating tags within the segment editor. For more detailed information about tags, see the article on [Tags and Formatting](/kb/tags-formatting).
![]()
* **Show source tags:** Toggles whether tags in the source text are displayed.
* **Project target tags (**`Ctrl`\*\* + **`Alt`** + **`N`**):\*\* Projects target tags onto the segment.
* **Select next tag (**`Ctrl`\*\* + **`]`**):\*\* Navigate forward through tags.
* **Select previous tag (**`Ctrl`\*\* + **`[`**):\*\* Navigate backward through tags.
* **Select matching tags (**`Alt`\*\* + **`Shift`**):\*\* Toggle between which tag is selected in a matching pair of tags.
* **Move tag one word left (**`M`**):** Move the selected tag one word to the left area.
* **Move tag one word right (**`/`**):** Move the selected tag one word to the right.
* **Move tag one character left (**`,`**):** Move the selected tag one character to the left.
* **Move tag one character right (**`.`\*\*): \*\*Move the selected tag one character to the right.
### Settings tab
The `Settings` tab contains a variety of ways for you to customize the behavior of LILT Translate to suit your needs. These settings are set on a per-account basis, with changes persisting across documents and Projects.
![]()
* [**Forward Overwrite Confirmed Segments and Backward Overwrite Confirmed Segments**](/kb/auto-propagation): When enabled and a segment is confirmed, LILT uses the segment's target text to fill and replace the target text of other segments with matching source content forward/backward in the document. Overwrite Confirmed Segments always occurs for unconfirmed segments.
* **Keep sidebar open:** This option toggles whether the sidebar is kept open or not. By default, this is enabled.
* \*\*Auto-scroll editor: \*\*With auto-scroll on, when a segment is confirmed, LILT Translate automatically places you into editing the next segment and scrolls the page to keep the selected segment in view.
# Introduction To LILT Translation
Source: https://support.lilt.com/kb/introduction-to-lilt-translation
LILT Translate is a computer-aided translation (CAT) editor used to translate documents. LILT Translate incorporates a wealth of features and tools that enforce an efficient workflow for content translators and reviewers.
![]()
## Editor modes
LILT Translate has two modes that are largely the same (including [hotkeys](/kb/hotkeys)).
* [Translate mode](/kb/translating-documents) empowers translators by leveraging the [LILT Translate Engine](/kb/lilt-translate-engine), a self-learning neural translation system with integrated translation memory and termbase.
* [Review mode](/kb/reviewing-documents) empowers reviewers by leveraging the [LILT Review Engine](/kb/lilt-review-engine), an AI-powered quality assurance tool.
Mode differences:
* In Translate mode, segments are confirmed. In Review mode, segments are accepted. Unconfirmed and confirmed segments can still be edited in both modes, while accepted segments can only be edited in Review mode.
* [Translators add comments, while reviewers add error flags/annotations](/kb/segment-comments).
How to access the different modes:
* Users assigned to a document as a **translator** can only open the document in **Translate mode**.
* Users assigned to a document as a **reviewer** can only open the document in **Review mode**.
* Users with a **[manager or admin role](/kb/default-roles)** can open the document in either **Translate** or **Review mode**.
*Project managers can assign translators and reviewers to documents as described in the [Document Actions](/kb/document-actions) article.*
In LILT Translate, the editor mode is displayed in the upper-right as
![]()
or
![]()
![]()
Both editor modes share the same layout. The layout is outline in the sections below:
* [Segment editor](/kb/introduction-to-lilt-translate#h_01FA621FFWH9TNJKH9BGQEW8B6)
* [Sidebar](/kb/introduction-to-lilt-translate#h_01F3R82ENNBPF6TC789BFQC7FV)
* [Document information footer](/kb/introduction-to-lilt-translate#h_01FA623EMZDA5EAXX75WXP98ZQ)
* [Toolbar](/kb/introduction-to-lilt-translate#h_01FA6219V53VNSSAKSENERWBVQ)
## Segment editor
When opening a document into LILT Translate, you will find the document's source text divided into numbered segments. The segment in focus (the active segment) has several components:
![]()
1. **Segment number**
2. **Source text (ST)**
3. **Target text (TT) typing area:** You can type in your translation manually, or insert a suggestion from the suggestion area. Alternatives for the next word to insert may appear in this area as ghost-words. At the far right of the typing area, there is a number display for how many characters are inside the typing area.
4. **Machine translation (MT) suggestion area:** Displays suggested translations. TM matches above 75% are shown first. If a match does not exist, the interactive MT output appears. This section updates as you type. You can click on any of the suggested words to add that word to the typing area. You can learn more about suggestions in the [Translation Memory Matching](/kb/translation-memory-matching) article.
5. **Segment editing tools:** Allows linguists to [Split & Merge](/kb/split-merge-segments) segments, in addition to the actions for `Copy source to target` and `Insert full suggestion`.
6. **[Segment comments](/kb/segment-comments):** Allows linguists to add comments (in Translate mode) or flag errors (in Review mode).
7. **[QA](/kb/quality-assurance-tools):** Performs a QA check on the segment and raises any found errors.
8. **[Segment state indicator](/kb/segment-state-indicators):** The checkmark on each segment lets linguists confirm (for Translate mode) or accept (for Review mode) the segment to mark it as complete. Once confirmed/accepted, the segment will display a green checkmark (for confirmed) or a double green checkmark (for accepted) next to the segment number, and the checkmark in the bottom-right will turn into a cross that be clicked to unconfirm/unaccept the segment.
In addition, segments have the following features:
* **[Source Highlighting Tool](/kb/source-highlighting-tool):** Provides quick access to terminology information upon selecting source text.
* **[Terminology](/kb/terminology):** Any source phrases that match entries in the termbase are highlighted. Hovering over a highlighted phrase provides linguists with terminology information.
* **[Bi-Directional Text Marks](/kb/bi-directional-text-marks):** Segments support markers to allow linguists to orient phrases in a direction opposite to the direction of the language (left-to-right or right-to-left).
* **[Non-Translatables](/kb/non-translatables):** Segments support special tags for content that should not be translated, prohibiting linguists from modifying any content within a non-translatable tag.
## Sidebar
![]()
The sidebar on the right holds the following tools for easy access during translation:
* **[Segment Context](/kb/segment-context):** Segment context provides translation information about the segment selected.
* **[Concordance](/kb/concordance):** The Concordance tab gives in-context examples of how a word of phrase is used in the target language.
* **[Find and Replace](/kb/find-replace):** The find and replace tool allows linguists to search for text across the document.
## Document information footer
![]()
At the bottom, the document information footer provides linguists with the following:
* Name of the document.
* Language pair.
* Current segment number, total number of segments, and how many segments have been confirmed/accepted.
* Word/segment display:
* **Translate mode:** Number of words translated and the total number of words in the document.
* **Review mode:** Number of segments reviewed and total number of segments in the document.
* Linguists can navigate to a specific segment by typing a number into the segment text box.
* Estimate of how much time it will take to finish translating/reviewing the document.
## Toolbar
The toolbar at the top has a range of options available for managing and customizing your experience with LILT Translate. Each tab of the header is described in the subsections below.
* [File](/kb/introduction-to-lilt-translate#h_01FNJFF8QRJ54Y5ADC1P5ATEGC)
* [Edit](/kb/introduction-to-lilt-translate#h_01FNJFFEBGWDWVG7KWXCXCNTCD)
* [View](/kb/introduction-to-lilt-translate#h_01FNJFFJV3XGT3G4JPHNCHAGBQ)
* [Insert](/kb/introduction-to-lilt-translate#h_01FNJFFQEJXQ91KXEZ08YSKNPY)
* [Tags](/kb/introduction-to-lilt-translate#h_01FNJFFWA2M4JHJQX51WNRY88R)
* [Settings](/kb/introduction-to-lilt-translate#h_01FNJFG0SVKK4S4VSJRSH32T46)
### File tab
![]()
The `File` tab provides several actions to help manage documents.
* **Download:** Use this option to download the translated document in one of three formats:
* **Option 1:** original format
* **Option 2:** TXT format
* **Option 3:** XLIFF format
* **Unlock document translation:** If the document has been locked for translation, the project manager can use this option to unlock the document in Translate mode so it can be worked on again by translators. For more information on this, see the [CAT Guide for Project Managers](/kb/lilt-translate-guide-for-project-managers).
* **[QA checks](/kb/quality-assurance-tools)**: There are two types of QA checks that can be run from the `File` menu: full QA checks and linguistic batch QA checks.
### Edit tab
The `Edit` tab contains a list of commonly used actions to help speed up your work within LILT Translate.
![]()
* \*\*Undo (shortcut \*\*`Ctrl` + `Z`): Undo the last edits that were made in the segment editor.
* **Select next word (**`Shift` + `Tab`): Select the next suggested word from the suggestion area below the typing text.
* **[Concordance](/kb/concordance) (**`Ctrl` + `Alt` + `C`**):** Opens the Concordance sidebar.
* **[Find and Replace](/kb/find-replace) (**`Ctrl` + `H`): Search for text in all typing areas of the document. Includes the option to require the whole word to match, require the case to match, and to search through the entire Project instead of just the document.
![]()
* **Highlight to change case (**`Shift` + `F3`): Changes the case of the currently selected section of target text.
### View tab
The `View` tab options affect how segments are displayed in LILT Translate.
![]()
* **Segments:**
* Filter segments by status:
* **All segments:** Segments with any confirmed/accepted status.
* **Confirmed:** Segments that have been confirmed in [Translate mode](/kb/translating-documents).
* **Unconfirmed:** Segments that have **not** been confirmed in Translate mode.
* **Unreviewed:** Segments that have **not** been accepted in [Review mode](/kb/reviewing-documents).
* **Reviewed:** Segments that have been accepted in Review mode.
* **Changed:** Segments that have been modified and confirmed during the current user session.
* Filter segments by additional content:
* **Segments with notes:** Segments with notes added in Translate mode.
* **Segments with errors:** Segments with errors added in Review mode.
* **Segments with tags:** Segments that have tags in their content.
* **Locked:** Segments that are confirmed, reviewed, or locked.
* Both these filter sections compound with each other.
* To remove a filter, click the filter again.
![]()
* **Previous segment** (`Ctrl` + `Up Arrow`): Navigate up through the document, segment by segment.
* **Next segment (**`Ctrl` + `Down Arrow`): Navigate down through the document, segment by segment.
* **[Preview mode](/kb/monolingual-preview):** Toggles between segment edit mode and preview mode. Preview mode displays confirmed or accepted target segments with paragraph and HTML formatting.
* **Split view:** With split view disabled (the default setting), target text is displayed beneath the source text. If split view is enabled, target text is displayed to the right of the source text. Split view helps increase proofreading speed.
![]()
* **Show invisible characters:** When enabled, displays characters that are normally invisible (such as spaces, tabs, right-to-left marks, and left-to-right marks) in both the source and target text.
![]()
### Insert tab
The `Insert` tab has a range of tools for interacting with text in the segment editor.
![]()
* **Suggested phrase (**`Enter`): Insert the suggested word into the target text field.
* **Full suggestion (**`Shift` + `Enter`): Insert the full suggested sentence into the target text field.
* **Non-breaking spaces (**`Ctrl` + `Shift` + `Space`) : Insert a non-breaking space into the target text field. These can be useful in certain situations, as the non-breaking spaces do not get erased in document formats that ignore extra spaces, such as HTML.
* **Line break (**`Alt` + `Enter`): Adds a line break on the currently selected line in the target text field. Line breaks can also be copied from source text to target text by using the `Copy source to target` option in the segment editing tools.
* **Copy source to target (**`Ctrl` + `I`): Inserts the source text into the target text field. This is useful if a segment does not have to be translated for whatever reason.
* **Add new term (**`Alt` + `A`): Opens a popup where you can add a new translation entry to the associated Data Source.
* **Add comment (**`Ctrl` + `Alt` + `M`): Add a comment to the currently selected segment. These are the same comments you can add using the `View Note` buttonnext to a segment.
* **Insert right-to-left mark (**`Ctrl` + `K`): Inserts an invisible right-to-left mark character into the target text field. These are used to determine how the adjacent characters are grouped in respect to text direction.
* **Insert left-to-right mark (**`Ctrl` + `L`): Inserts an invisible left-to-right mark character into the target text field. These are used to determine how the adjacent characters are grouped in respect to text direction.
### Tags tab
The `Tag` tab provides tools for manipulating tags within the segment editor. For more detailed information about tags, see the article on [Tags and Formatting](/kb/tags-formatting).
![]()
* **Show source tags:** Toggles whether tags in the source text are displayed.
* **Project target tags (**`Ctrl` + `Alt` + `N`): Projects target tags onto the segment.
* **Select next tag (**`Ctrl` + `]`): Navigate forward through tags.
* **Select previous tag (**`Ctrl` + `[`): Navigate backward through tags.
* **Select matching tags (**`Alt` + `Shift`): Toggle between which tag is selected in a matching pair of tags.
* **Move tag one word left (**`M`): Move the selected tag one word to the left area.
* **Move tag one word right (**`/`): Move the selected tag one word to the right.
* **Move tag one character left (**`,`): Move the selected tag one character to the left.
* **Move tag one character right (**`.`): Move the selected tag one character to the right.
### Settings tab
The `Settings` tab contains a variety of ways for you to customize the behavior of LILT Translate to suit your needs. These settings are set on a per-account basis, with changes persisting across documents and Projects.
![]()
* **[Forward Overwrite Confirmed Segments and Backward Overwrite Confirmed Segments](/kb/auto-propagation):** When enabled and a segment is confirmed, LILT uses the segment's target text to fill and replace the target text of other segments with matching source content forward/backward in the document. Overwrite Confirmed Segments always occurs for unconfirmed segments.
* **Keep sidebar open:** This option toggles whether the sidebar is kept open or not. By default, this is enabled.
* \*\*Auto-scroll editor: \*\*With auto-scroll on, when a segment is confirmed, LILT Translate automatically places you into editing the next segment and scrolls the page to keep the selected segment in view.
# Jira
Source: https://support.lilt.com/kb/jira
The LILT + Jira integration facilitates efficient communication and project management using your organization's existing Jira project tracker. The integration works by enabling LILT to automatically create new Jira Issues when a new LILT Project is created via another connector ([Contentful](/kb/contentful), [Zendesk](/kb/zendesk), etc.) integrated with LILT.
The LILT + Jira integration supports the following:
* **Ticket creation**: LILT automatically creates a Jira Issue ticket when a new project is created via a connector (Contentful, Zendesk, etc.).
* **Ticket properties**: The following information will be automatically populated at ticket creation.
* **Project name**: Name of project as it appears in LILT.
* **Project link**: Links back to the associated project in LILT.
* **Project status**: Received or delivered.
* **Documents**: List of documents contained in the project.
* **Labels**: Apply one or many labels to the Jira ticket.
* **Assign**: Ability to assign the ticket to specific Jira users (if desired).
* **Task creation**: The customer can create tasks within the project for tracking purposes as part of the Linguistic Quality Assurance (LQA) process.
* **Reject via Jira**: The customer can assign a Jira Issue to LILT to indicate revisions are required.
* **Assign to LILT**: The customer can assign a \[LILT generated] Jira Issue back to the `LILT` user, in order to indicate rework is required.
* **Rework notifications**: Jira will send an email to the alias associated with the `LILT` Jira user when a ticket is assigned back to LILT.
## Configuration
1. Create a normal user in Jira with your choice of name (for example, `LILT`).
2. [Enable sub-tasks](https://confluence.atlassian.com/adminjiraserver/configuring-sub-tasks-938847874.html) in the Jira project so LILT can create ticket sub-tasks.
3. Contact the LILT Solutions team and provide them with the following information to enable the LILT + Jira integration:
* `Jira username`
* `API token`
* `Jira server URL`
## Workflow
Once you have configured your Jira account to work with LILT, you can get to work.
### Setup
1. A translation job is created in the connected [content management system](/kb/connectors) (CMS) of your choice. For the purposes of this example, we will use Contentful.
2. For each target language in Contentful, LILT creates a corresponding project.
3. Jira creates an Issue Ticket tied to the project.
### Translation Flow
Once the project is in place, each selected entry in Contentful will have a corresponding document created in LILT. Subtask Tickets are then created in Jira corresponding to these documents. For example, you would have a LILT project for an English to French translation, a corresponding Jira Issue Ticket for the project, and then for each document in the project, a Subtask Ticket for that document.
The documents are then translated in LILT, and the Subtask's status is updated. It can then be reviewed. If there is any feedback, the Jira status can be updated again, which instructs the LILT Production Manager to unarchive the project and notify the linguist of changes that need to be made. This cycle continues until the document is complete.
### Completion
Once there is no more document feedback, the Jira subtask is marked as completed. Once every document subtask has been marked complete, the issue they belong to is marked complete as well. When all issues are marked as completed, the translation job is done.
# Job Stats
Source: https://support.lilt.com/kb/job-stats
![]()
The Job Stats Report allows you to see active projects. You will have an overview of the number of jobs that are in each state (i.e. Ready to Start, In Progress, In Review, Secondary Review, and Completed). Under the Job Stats tab, you will be able to see further details regarding individual projects that you’ve sent to LILT for Translation. Stats such as State, Created date, Due date and Delivery Date help you and your localization teams manage your day-to-day tracking of projects directly from our platform. You will be able to filter by time (“From” and “To”), Source language, or Target language.
## Video Overview
# Knowledge Base Dictionary
Source: https://support.lilt.com/kb/knowledge-base-dictionary
This article outlines terminology usage across the LILT Platform and Knowledge Base.
## LILT Platform
* [**LILT Translate**](/kb/introduction-to-lilt-translate): LILT's CAT editor tool for translators and reviewers, powered by [Contextual AI](/kb/what-is-interactive-adaptive-mt)
- [**Data Source**](/kb/managing-your-lilt-memories): Aggregates the following linguist assets:
* [**Translation Memory**](/kb/translation-memory-matching) *(described below)*
* [**Termbase**](/kb/managing-termbase-and-translation-memory-entries) *(described below)*
- [**Quality Assurance Checks**](/kb/lilt-review-engine): LILT's automated quality assurance tools
- [**LILT Manage**](/kb/manage): LILT's project management tool
- [**LILT Connect:**](/kb/connect) LILT's suite of integrations and connectors
## Data Sources
* **Data Source:** A collection of translation memory and termbase entries.
* *A translation memory is a collection of previously translated segments.*
* *A termbase is a glossary of terms that helps to maintain consistent terminology usage.*
* **TM File:** A TMX file containing a collection of TM entries.
* **TM Entry:** An individual source/target segment. Entries will be added to the Translation Memory when any of the following actions occur:
* A manager [Imports a TM File](/kb/uploading-memory-files).
* A translator confirms a segment via the [LILT Translate](/kb/introduction-to-lilt-translate).
* TM Leveraging fills in and confirms a segment.
* [Instant Translate](/kb/pretranslating-documents) fills in and confirms a segment.
* Manual creation of a TM entry using [LILT’s TM editor](/kb/managing-termbase-and-translation-memory-entries).
- **TB File:** A CSV, TBX, or XLSX file containing a collection of TB entries.
- **TB Entry:** An individual source/target phrase. TB entries are added to a Translation Memory via:
* [Importing a TB File](/kb/uploading-memory-files).
* Manual creation of a TB entry using [LILT's TM editor](/kb/managing-termbase-and-translation-memory-entries).
## General terminology
* [**BLEU score**](/kb/generate-evaluation-metrics-wpa-bleu): A value between 0 and 1 indicating how closely matched a machine-translated segment is to a good quality reference translation. This value is useful in evaluating the quality of machine-translated text.
* **Computer-Assisted Translation (CAT):** Human translation completed with help from computer software. This is also sometimes referred to as machine-assisted translation.
* [**Non-Translatables**](/kb/non-translatables): Phrases, terms or sections of text that should not be translated, such as mathematical expressions or variable names in code.
* **Machine Translation (MT):** Automated translation completed by the computer without a human translator. LILT's Contextual AI Engine generates a form of machine translation.
* **Machine Translation Post-Editing (MTPE):** A task assigned to a human translator to post-edit machine translations, often with the goal of achieving human-quality translation results.
* **Translation Management System (TMS):** Software that helps manage and automate the translation process by:
* Organizing localization workflow.
* Tracking progress of translation projects.
* Reducing manual tasks via automation.
# LanguageTool QA Rules
Source: https://support.lilt.com/kb/languagetool-qa-rules
LILT’s Linguistic Auto Review integrates [LanguageTool](https://languagetool.org/dev), an open-source proof-reading tool for many languages. LanguageTool incorporates community-based QA rules for spelling, grammar, and style. You can browse the language rules on their website, such as the English rules.
The sections below list the rules and categories from LanguageTool that LILT has chosen to disable when integrating LanguageTool with LILT’s Auto Review.
## Disabled rules
```json theme={null}
{
"de": [
"DE_AGREEMENT",
"DE_AGREEMENT2",
"EINHEITEN_METRISCH",
"FALSCHES_RELATIVPRONOMEN",
"GERMAN_SPELLER_RULE",
"HUNSPELL_RULE",
"ICH_WUENSCHTE_ICH_KOENNTE",
"KOMMA_ZWISCHEN_HAUPT_UND_NEBENSATZ",
"LEERZEICHEN_HINTER_DOPPELPUNKT",
"MATHE",
"MEIN_KLEIN_HAUS",
"MULTIPLICATION_SIGN",
"SENT_START_SIN_PLU",
"ZUSAMMENGESETZTE_VERBEN",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS"
],
"de-AT": [
"DE_AGREEMENT",
"DE_AGREEMENT2",
"EINHEITEN_METRISCH",
"FALSCHES_RELATIVPRONOMEN",
"GERMAN_SPELLER_RULE",
"HUNSPELL_RULE",
"ICH_WUENSCHTE_ICH_KOENNTE",
"KOMMA_ZWISCHEN_HAUPT_UND_NEBENSATZ",
"LEERZEICHEN_HINTER_DOPPELPUNKT",
"MATHE",
"MEIN_KLEIN_HAUS",
"MULTIPLICATION_SIGN",
"SENT_START_SIN_PLU",
"ZUSAMMENGESETZTE_VERBEN",
"AUSTRIAN_GERMAN_SPELLER_RULE",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS"
],
"de-CH": [
"DE_AGREEMENT",
"DE_AGREEMENT2",
"EINHEITEN_METRISCH",
"FALSCHES_RELATIVPRONOMEN",
"GERMAN_SPELLER_RULE",
"HUNSPELL_RULE",
"ICH_WUENSCHTE_ICH_KOENNTE",
"KOMMA_ZWISCHEN_HAUPT_UND_NEBENSATZ",
"LEERZEICHEN_HINTER_DOPPELPUNKT",
"MATHE",
"MEIN_KLEIN_HAUS",
"MULTIPLICATION_SIGN",
"SENT_START_SIN_PLU",
"ZUSAMMENGESETZTE_VERBEN",
"SWISS_GERMAN_SPELLER_RULE",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS"
],
"de-DE": [
"DE_AGREEMENT",
"DE_AGREEMENT2",
"EINHEITEN_METRISCH",
"FALSCHES_RELATIVPRONOMEN",
"GERMAN_SPELLER_RULE",
"HUNSPELL_RULE",
"ICH_WUENSCHTE_ICH_KOENNTE",
"KOMMA_ZWISCHEN_HAUPT_UND_NEBENSATZ",
"LEERZEICHEN_HINTER_DOPPELPUNKT",
"MATHE",
"MEIN_KLEIN_HAUS",
"MORFOLOGIK_RULE_DE_DE",
"MULTIPLICATION_SIGN",
"SENT_START_SIN_PLU",
"ZUSAMMENGESETZTE_VERBEN",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS"
],
"es": [
"ROMAN_NUMERALS_CHECK",
"E_SINGLE_CHAR",
"SUBJUNTIVO_PASADO",
"MIN_DIAS_SEMANA",
"MIN_ESTACIONES",
"UNPAIRED_BRACKETS",
"SINGLE_CHARACTER",
"PRON_HABER_PARTICIPIO",
"PROMEDIO",
"ARROWS",
"PREP_VERB",
"MORFOLOGIK_RULE_ES",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UPPERCASE_SENTENCE_START"
],
"fr": [
"FR_SPELLING_RULE",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS"
],
"it": [
"ARTICOLATA_SOSTANTIVO",
"ST_01_005",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS",
"UPPERCASE_SENTENCE_START"
],
"ja": [
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS"
],
"nl": [
"WOORD_MET_UNDERSCORE",
"EN_EN_EN",
"NADRUKTEKENS",
"TOO_LONG_SENTENCE",
"AFKO_PUNT",
"VAAG",
"KORT_1",
"KORT_2",
"AFGEZIEN_VAN",
"ALDUS",
"IN_HET_KADER_VAN",
"OP_BASIS_VAN",
"HOEWEL",
"OP_HET_GEBIED_VAN",
"VOORWAARDEN",
"ERVARING",
"INTEGREREN",
"V_H",
"EN_OF",
"AANVRAGE",
"ALWAAR",
"OVERDRIJVING",
"ANDERSZINS",
"BNW-VRIJ",
"ONTKEN_2",
"DE_ONVERWACHT",
"BELEDIGEND",
"MATCH",
"LANG_WOORD",
"ERG_LANG_WOORD",
"DOORONTWIKKELEN",
"DOORPAKKEN",
"T",
"OP_GROND_VAN",
"TM",
"V_D",
"DES_TE-VREEMD",
"GROTERE_ALS",
"GEMOORD_GEMORD",
"TEN_DODE",
"MORFOLOGIK_RULE_NL_NL",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS"
],
"nl-BE": [
"WOORD_MET_UNDERSCORE",
"EN_EN_EN",
"NADRUKTEKENS",
"TOO_LONG_SENTENCE",
"AFKO_PUNT",
"VAAG",
"KORT_1",
"KORT_2",
"AFGEZIEN_VAN",
"ALDUS",
"IN_HET_KADER_VAN",
"OP_BASIS_VAN",
"HOEWEL",
"OP_HET_GEBIED_VAN",
"VOORWAARDEN",
"ERVARING",
"INTEGREREN",
"V_H",
"EN_OF",
"AANVRAGE",
"ALWAAR",
"OVERDRIJVING",
"ANDERSZINS",
"BNW-VRIJ",
"ONTKEN_2",
"DE_ONVERWACHT",
"BELEDIGEND",
"MATCH",
"LANG_WOORD",
"ERG_LANG_WOORD",
"DOORONTWIKKELEN",
"DOORPAKKEN",
"T",
"OP_GROND_VAN",
"TM",
"V_D",
"DES_TE-VREEMD",
"GROTERE_ALS",
"GEMOORD_GEMORD",
"TEN_DODE",
"MORFOLOGIK_RULE_NL_NL",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS"
],
"pt" : [
"ABREVIATIONS_PUNCTUATION",
"BARBARISMS",
"CACOPHONY",
"DASH_ENUMERATION_SPACE_RULE",
"DATE_FUTURE_VERB_PAST",
"DATE_NEW_YEAR",
"DECIMAL_COMMA",
"ELES_ELAS",
"E_NO_COMECO",
"EQUAL_OR_X",
"FINAL_STOPS",
"FRAGMENT_TWO_ARTICLES",
"GENERAL_NUMBER_FORMAT",
"HIPHEN_SPACE_RULES",
"INFORMALITIES",
"INTERJECTIONS_PUNTUATION",
"INTERNET_ABBREVIATIONS",
"INTERROGATIVES_PUNTUATION",
"INVARIABLE_NOUNS",
"MULTIPLICATION_SIGN",
"OBLIQUOUS_PRONOUN_VERB",
"ORDINAL_ABREVIATION",
"PLURAL_IN_UNITS_OF_MEASURE",
"PORTUGUESE_WRONG_WORD_IN_CONTEXT",
"PT_WORDINESS_REPLACE",
"PUNCTUATION_PARAGRAPH_END",
"PUNCTUATION_PARAGRAPH_END2",
"REDUNDANT_CONJUNCTIONS",
"REGARDS_COMMA",
"REPETITIONS_STYLE",
"ROMAN_NUMBERS_CHECKER",
"SENT_START_NUM",
"SI_UNITS_CASE",
"WORD_CONTAINS_UNDERSCORE",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS",
"UPPERCASE_SENTENCE_START"
],
"pt-BR": [
"ABREVIATIONS_PUNCTUATION",
"AO90_CARDINAL_POINTS_CASING",
"BARBARISMS",
"CACOPHONY",
"DASH_ENUMERATION_SPACE_RULE",
"DATE_FUTURE_VERB_PAST",
"DATE_NEW_YEAR",
"DECIMAL_COMMA",
"ELES_ELAS",
"E_NO_COMECO",
"EQUAL_OR_X",
"FINAL_STOPS",
"FRAGMENT_TWO_ARTICLES",
"GENERAL_NUMBER_FORMAT",
"HIPHEN_SPACE_RULES",
"INFORMALITIES",
"INTERJECTIONS_PUNTUATION",
"INTERNET_ABBREVIATIONS",
"INTERROGATIVES_PUNTUATION",
"INVARIABLE_NOUNS",
"MULTIPLICATION_SIGN",
"OBLIQUOUS_PRONOUN_VERB",
"ORDINAL_ABREVIATION",
"PLURAL_IN_UNITS_OF_MEASURE",
"PORTUGUESE_WRONG_WORD_IN_CONTEXT",
"PT_WORDINESS_REPLACE",
"PUNCTUATION_PARAGRAPH_END",
"PUNCTUATION_PARAGRAPH_END2",
"REDUNDANT_CONJUNCTIONS",
"REGARDS_COMMA",
"REPETITIONS_STYLE",
"ROMAN_NUMBERS_CHECKER",
"SENT_START_NUM",
"SI_UNITS_CASE",
"WORD_CONTAINS_UNDERSCORE",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS",
"UPPERCASE_SENTENCE_START"
],
"pt-PT": [
"ABREVIATIONS_PUNCTUATION",
"AO90_CARDINAL_POINTS_CASING",
"BARBARISMS",
"CACOPHONY",
"DASH_ENUMERATION_SPACE_RULE",
"DATE_FUTURE_VERB_PAST",
"DATE_NEW_YEAR",
"DECIMAL_COMMA",
"ELES_ELAS",
"E_NO_COMECO",
"EQUAL_OR_X",
"FINAL_STOPS",
"FRAGMENT_TWO_ARTICLES",
"GENERAL_NUMBER_FORMAT",
"HIPHEN_SPACE_RULES",
"INFORMALITIES",
"INTERJECTIONS_PUNTUATION",
"INTERNET_ABBREVIATIONS",
"INTERROGATIVES_PUNTUATION",
"INVARIABLE_NOUNS",
"MULTIPLICATION_SIGN",
"OBLIQUOUS_PRONOUN_VERB",
"ORDINAL_ABREVIATION",
"PLURAL_IN_UNITS_OF_MEASURE",
"PORTUGUESE_WRONG_WORD_IN_CONTEXT",
"PT_WORDINESS_REPLACE",
"PUNCTUATION_PARAGRAPH_END",
"PUNCTUATION_PARAGRAPH_END2",
"REDUNDANT_CONJUNCTIONS",
"REGARDS_COMMA",
"REPETITIONS_STYLE",
"ROMAN_NUMBERS_CHECKER",
"SENT_START_NUM",
"SI_UNITS_CASE",
"WORD_CONTAINS_UNDERSCORE",
"AVOID_GERUND",
"PT_BR_SIMPLE_REPLACE",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS",
"UPPERCASE_SENTENCE_START"
],
"ru": [
"Cap_Letters_Fam",
"CASING",
"Comma_Chtobi_2VERB",
"DotOrCase",
"DoubleNOT",
"grammar_bez_ucheta_and_Noun",
"grammar_v_adress_and_Noun",
"grammar_v_vedenie_and_Noun",
"grammar_v_vidah_and_Noun",
"grammar_v_vide_and_Noun",
"Latin_letters",
"Latin_single_letter",
"Many_PNN",
"missing_noun_at_end",
"NEUJTO",
"noun_genitive_3",
"O_P_padeg",
"OPREDELENIA",
"plit_lodkoj",
"pouchastvovat",
"PREP_C_and_ADJ",
"PREP_C_and_Noun",
"PREP_K_and_ADJ",
"PREP_K_and_Noun",
"PREP_K_and_Num",
"PREP_Na_And_Noun",
"PREP_O_and_ADJ",
"PREP_O_and_Noun",
"PREP_Ob_And_Noun",
"PREP_PO_and_Noun",
"PREP_POD_And_NOUN",
"PREP_Pri_and_ADJ",
"PREP_Pri_and_Noun",
"PREP_Pro_And_Noun",
"PREP_U_and_ADJ",
"PREP_U_and_Noun",
"PREP_V_and_Noun",
"PREP_Za_And_Noun",
"ROST",
"SoglasovanieNN_Verb",
"Two_PREP",
"Unify_Adj_NN_gender",
"Unify_Adj_NN_number",
"Unify_PADJ_NN_gender",
"Unify_PADJ_NN_number",
"upravlauchij_NN",
"Verb_and_PREP",
"vopreki_NN",
"zaslujit_NN",
"zaslujivat_NN",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS",
"UPPERCASE_SENTENCE_START"
]
}
"de": [
"DE_AGREEMENT",
"DE_AGREEMENT2",
"EINHEITEN_METRISCH",
"FALSCHES_RELATIVPRONOMEN",
"GERMAN_SPELLER_RULE",
"HUNSPELL_RULE",
"ICH_WUENSCHTE_ICH_KOENNTE",
"KOMMA_ZWISCHEN_HAUPT_UND_NEBENSATZ",
"LEERZEICHEN_HINTER_DOPPELPUNKT",
"MATHE",
"MEIN_KLEIN_HAUS",
"MULTIPLICATION_SIGN",
"SENT_START_SIN_PLU",
"ZUSAMMENGESETZTE_VERBEN",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS"
],
"de-AT": [
"DE_AGREEMENT",
"DE_AGREEMENT2",
"EINHEITEN_METRISCH",
"FALSCHES_RELATIVPRONOMEN",
"GERMAN_SPELLER_RULE",
"HUNSPELL_RULE",
"ICH_WUENSCHTE_ICH_KOENNTE",
"KOMMA_ZWISCHEN_HAUPT_UND_NEBENSATZ",
"LEERZEICHEN_HINTER_DOPPELPUNKT",
"MATHE",
"MEIN_KLEIN_HAUS",
"MULTIPLICATION_SIGN",
"SENT_START_SIN_PLU",
"ZUSAMMENGESETZTE_VERBEN",
"AUSTRIAN_GERMAN_SPELLER_RULE",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS"
],
"de-CH": [
"DE_AGREEMENT",
"DE_AGREEMENT2",
"EINHEITEN_METRISCH",
"FALSCHES_RELATIVPRONOMEN",
"GERMAN_SPELLER_RULE",
"HUNSPELL_RULE",
"ICH_WUENSCHTE_ICH_KOENNTE",
"KOMMA_ZWISCHEN_HAUPT_UND_NEBENSATZ",
"LEERZEICHEN_HINTER_DOPPELPUNKT",
"MATHE",
"MEIN_KLEIN_HAUS",
"MULTIPLICATION_SIGN",
"SENT_START_SIN_PLU",
"ZUSAMMENGESETZTE_VERBEN",
"SWISS_GERMAN_SPELLER_RULE",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS"
],
"de-DE": [
"DE_AGREEMENT",
"DE_AGREEMENT2",
"EINHEITEN_METRISCH",
"FALSCHES_RELATIVPRONOMEN",
"GERMAN_SPELLER_RULE",
"HUNSPELL_RULE",
"ICH_WUENSCHTE_ICH_KOENNTE",
"KOMMA_ZWISCHEN_HAUPT_UND_NEBENSATZ",
"LEERZEICHEN_HINTER_DOPPELPUNKT",
"MATHE",
"MEIN_KLEIN_HAUS",
"MORFOLOGIK_RULE_DE_DE",
"MULTIPLICATION_SIGN",
"SENT_START_SIN_PLU",
"ZUSAMMENGESETZTE_VERBEN",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS"
],
"es": [
"ROMAN_NUMERALS_CHECK",
"E_SINGLE_CHAR",
"SUBJUNTIVO_PASADO",
"MIN_DIAS_SEMANA",
"MIN_ESTACIONES",
"UNPAIRED_BRACKETS",
"SINGLE_CHARACTER",
"PRON_HABER_PARTICIPIO",
"PROMEDIO",
"ARROWS",
"PREP_VERB",
"MORFOLOGIK_RULE_ES",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UPPERCASE_SENTENCE_START"
],
"fr": [
"FR_SPELLING_RULE",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS"
],
"it": [
"ARTICOLATA_SOSTANTIVO",
"ST_01_005",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS",
"UPPERCASE_SENTENCE_START"
],
"ja": [
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS"
],
"nl": [
"WOORD_MET_UNDERSCORE",
"EN_EN_EN",
"NADRUKTEKENS",
"TOO_LONG_SENTENCE",
"AFKO_PUNT",
"VAAG",
"KORT_1",
"KORT_2",
"AFGEZIEN_VAN",
"ALDUS",
"IN_HET_KADER_VAN",
"OP_BASIS_VAN",
"HOEWEL",
"OP_HET_GEBIED_VAN",
"VOORWAARDEN",
"ERVARING",
"INTEGREREN",
"V_H",
"EN_OF",
"AANVRAGE",
"ALWAAR",
"OVERDRIJVING",
"ANDERSZINS",
"BNW-VRIJ",
"ONTKEN_2",
"DE_ONVERWACHT",
"BELEDIGEND",
"MATCH",
"LANG_WOORD",
"ERG_LANG_WOORD",
"DOORONTWIKKELEN",
"DOORPAKKEN",
"T",
"OP_GROND_VAN",
"TM",
"V_D",
"DES_TE-VREEMD",
"GROTERE_ALS",
"GEMOORD_GEMORD",
"TEN_DODE",
"MORFOLOGIK_RULE_NL_NL",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS"
],
"nl-BE": [
"WOORD_MET_UNDERSCORE",
"EN_EN_EN",
"NADRUKTEKENS",
"TOO_LONG_SENTENCE",
"AFKO_PUNT",
"VAAG",
"KORT_1",
"KORT_2",
"AFGEZIEN_VAN",
"ALDUS",
"IN_HET_KADER_VAN",
"OP_BASIS_VAN",
"HOEWEL",
"OP_HET_GEBIED_VAN",
"VOORWAARDEN",
"ERVARING",
"INTEGREREN",
"V_H",
"EN_OF",
"AANVRAGE",
"ALWAAR",
"OVERDRIJVING",
"ANDERSZINS",
"BNW-VRIJ",
"ONTKEN_2",
"DE_ONVERWACHT",
"BELEDIGEND",
"MATCH",
"LANG_WOORD",
"ERG_LANG_WOORD",
"DOORONTWIKKELEN",
"DOORPAKKEN",
"T",
"OP_GROND_VAN",
"TM",
"V_D",
"DES_TE-VREEMD",
"GROTERE_ALS",
"GEMOORD_GEMORD",
"TEN_DODE",
"MORFOLOGIK_RULE_NL_NL",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS"
],
"pt" : [
"ABREVIATIONS_PUNCTUATION",
"BARBARISMS",
"CACOPHONY",
"DASH_ENUMERATION_SPACE_RULE",
"DATE_FUTURE_VERB_PAST",
"DATE_NEW_YEAR",
"DECIMAL_COMMA",
"ELES_ELAS",
"E_NO_COMECO",
"EQUAL_OR_X",
"FINAL_STOPS",
"FRAGMENT_TWO_ARTICLES",
"GENERAL_NUMBER_FORMAT",
"HIPHEN_SPACE_RULES",
"INFORMALITIES",
"INTERJECTIONS_PUNTUATION",
"INTERNET_ABBREVIATIONS",
"INTERROGATIVES_PUNTUATION",
"INVARIABLE_NOUNS",
"MULTIPLICATION_SIGN",
"OBLIQUOUS_PRONOUN_VERB",
"ORDINAL_ABREVIATION",
"PLURAL_IN_UNITS_OF_MEASURE",
"PORTUGUESE_WRONG_WORD_IN_CONTEXT",
"PT_WORDINESS_REPLACE",
"PUNCTUATION_PARAGRAPH_END",
"PUNCTUATION_PARAGRAPH_END2",
"REDUNDANT_CONJUNCTIONS",
"REGARDS_COMMA",
"REPETITIONS_STYLE",
"ROMAN_NUMBERS_CHECKER",
"SENT_START_NUM",
"SI_UNITS_CASE",
"WORD_CONTAINS_UNDERSCORE",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS",
"UPPERCASE_SENTENCE_START"
],
"pt-BR": [
"ABREVIATIONS_PUNCTUATION",
"AO90_CARDINAL_POINTS_CASING",
"BARBARISMS",
"CACOPHONY",
"DASH_ENUMERATION_SPACE_RULE",
"DATE_FUTURE_VERB_PAST",
"DATE_NEW_YEAR",
"DECIMAL_COMMA",
"ELES_ELAS",
"E_NO_COMECO",
"EQUAL_OR_X",
"FINAL_STOPS",
"FRAGMENT_TWO_ARTICLES",
"GENERAL_NUMBER_FORMAT",
"HIPHEN_SPACE_RULES",
"INFORMALITIES",
"INTERJECTIONS_PUNTUATION",
"INTERNET_ABBREVIATIONS",
"INTERROGATIVES_PUNTUATION",
"INVARIABLE_NOUNS",
"MULTIPLICATION_SIGN",
"OBLIQUOUS_PRONOUN_VERB",
"ORDINAL_ABREVIATION",
"PLURAL_IN_UNITS_OF_MEASURE",
"PORTUGUESE_WRONG_WORD_IN_CONTEXT",
"PT_WORDINESS_REPLACE",
"PUNCTUATION_PARAGRAPH_END",
"PUNCTUATION_PARAGRAPH_END2",
"REDUNDANT_CONJUNCTIONS",
"REGARDS_COMMA",
"REPETITIONS_STYLE",
"ROMAN_NUMBERS_CHECKER",
"SENT_START_NUM",
"SI_UNITS_CASE",
"WORD_CONTAINS_UNDERSCORE",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS",
"UPPERCASE_SENTENCE_START"
],
"pt-PT": [
"ABREVIATIONS_PUNCTUATION",
"AO90_CARDINAL_POINTS_CASING",
"BARBARISMS",
"CACOPHONY",
"DASH_ENUMERATION_SPACE_RULE",
"DATE_FUTURE_VERB_PAST",
"DATE_NEW_YEAR",
"DECIMAL_COMMA",
"ELES_ELAS",
"E_NO_COMECO",
"EQUAL_OR_X",
"FINAL_STOPS",
"FRAGMENT_TWO_ARTICLES",
"GENERAL_NUMBER_FORMAT",
"HIPHEN_SPACE_RULES",
"INFORMALITIES",
"INTERJECTIONS_PUNTUATION",
"INTERNET_ABBREVIATIONS",
"INTERROGATIVES_PUNTUATION",
"INVARIABLE_NOUNS",
"MULTIPLICATION_SIGN",
"OBLIQUOUS_PRONOUN_VERB",
"ORDINAL_ABREVIATION",
"PLURAL_IN_UNITS_OF_MEASURE",
"PORTUGUESE_WRONG_WORD_IN_CONTEXT",
"PT_WORDINESS_REPLACE",
"PUNCTUATION_PARAGRAPH_END",
"PUNCTUATION_PARAGRAPH_END2",
"REDUNDANT_CONJUNCTIONS",
"REGARDS_COMMA",
"REPETITIONS_STYLE",
"ROMAN_NUMBERS_CHECKER",
"SENT_START_NUM",
"SI_UNITS_CASE",
"WORD_CONTAINS_UNDERSCORE",
"AVOID_GERUND",
"PT_BR_SIMPLE_REPLACE",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS",
"UPPERCASE_SENTENCE_START"
],
"ru": [
"Cap_Letters_Fam",
"CASING",
"Comma_Chtobi_2VERB",
"DotOrCase",
"DoubleNOT",
"grammar_bez_ucheta_and_Noun",
"grammar_v_adress_and_Noun",
"grammar_v_vedenie_and_Noun",
"grammar_v_vidah_and_Noun",
"grammar_v_vide_and_Noun",
"Latin_letters",
"Latin_single_letter",
"Many_PNN",
"missing_noun_at_end",
"NEUJTO",
"noun_genitive_3",
"O_P_padeg",
"OPREDELENIA",
"plit_lodkoj",
"pouchastvovat",
"PREP_C_and_ADJ",
"PREP_C_and_Noun",
"PREP_K_and_ADJ",
"PREP_K_and_Noun",
"PREP_K_and_Num",
"PREP_Na_And_Noun",
"PREP_O_and_ADJ",
"PREP_O_and_Noun",
"PREP_Ob_And_Noun",
"PREP_PO_and_Noun",
"PREP_POD_And_NOUN",
"PREP_Pri_and_ADJ",
"PREP_Pri_and_Noun",
"PREP_Pro_And_Noun",
"PREP_U_and_ADJ",
"PREP_U_and_Noun",
"PREP_V_and_Noun",
"PREP_Za_And_Noun",
"ROST",
"SoglasovanieNN_Verb",
"Two_PREP",
"Unify_Adj_NN_gender",
"Unify_Adj_NN_number",
"Unify_PADJ_NN_gender",
"Unify_PADJ_NN_number",
"upravlauchij_NN",
"Verb_and_PREP",
"vopreki_NN",
"zaslujit_NN",
"zaslujivat_NN",
"BILINGUAL_NUMBER_MISMATCH",
"LILT_DIFFERENT_PUNCTUATION",
"SAME_TRANSLATION",
"TRANSLATION_LENGTH",
"UNPAIRED_BRACKETS",
"UPPERCASE_SENTENCE_START"
]
}
```
## Disabled categories
```json theme={null}
{
"es": [
"FALSE_FRIENDS"
],
"de": [
"FALSE_FRIENDS"
],
"de-AT": [
"FALSE_FRIENDS"
],
"de-CH": [
"FALSE_FRIENDS"
],
"de-DE": [
"FALSE_FRIENDS"
],
"fr": [
"CAT_GRAMMAIRE",
"CAT_ANGLICISMES",
"CAT_REGIONALISMES",
"FALSE_FRIENDS"
],
"it": [
"CAT11",
"CAT12",
"CAT13",
"FALSE_FRIENDS"
],
"ja": [
"CAT1",
"CAT2",
"CAT3",
"CAT4",
"CAT5",
"CAT6",
"CAT7",
"CAT8",
"FALSE_FRIENDS"
],
"nl": [
"CLICHES"
],
"nl-BE": [
"CLICHES"
],
"pt": [
"FALSE_FRIENDS"
],
"pt-BR": [
"FALSE_FRIENDS"
],
"pt-PT": [
"FALSE_FRIENDS"
]
}
"es": [
"FALSE_FRIENDS"
],
"de": [
"FALSE_FRIENDS"
],
"de-AT": [
"FALSE_FRIENDS"
],
"de-CH": [
"FALSE_FRIENDS"
],
"de-DE": [
"FALSE_FRIENDS"
],
"fr": [
"CAT_GRAMMAIRE",
"CAT_ANGLICISMES",
"CAT_REGIONALISMES",
"FALSE_FRIENDS"
],
"it": [
"CAT11",
"CAT12",
"CAT13",
"FALSE_FRIENDS"
],
"ja": [
"CAT1",
"CAT2",
"CAT3",
"CAT4",
"CAT5",
"CAT6",
"CAT7",
"CAT8",
"FALSE_FRIENDS"
],
"nl": [
"CLICHES"
],
"nl-BE": [
"CLICHES"
],
"pt": [
"FALSE_FRIENDS"
],
"pt-BR": [
"FALSE_FRIENDS"
],
"pt-PT": [
"FALSE_FRIENDS"
]
}
```
# Analytics
Source: https://support.lilt.com/kb/lilt-analytics-v2
## LILT Analytics Overview
LILT Analytics provides comprehensive insights into the performance and accuracy of AI translations over time. This article will guide you through the various metrics and visualizations available in LILT Analytics.
Monthly analytics data is available at the beginning of the following month. We only display complete monthly datasets.
![]()
## AI Accuracy
AI Accuracy provides insights into the accuracy of AI suggestions across two models and workflows: Unadapted AI (pure MT) and Adapted AI (LILT Contextual AI model with Data Sources).
* **Unadapted AI (Green)**: Represents the raw AI translation accuracy without any modifications (LILT’s baseline models).
* **Adapted AI (Orange)**: Shows the AI translation accuracy after adjustments and improvements from Fine Tuned Data Sources (customer’s fine-tuned models).
![]()
AI Accuracy does not include data for any third party model usage (e.g. Google Translate models), nor does it include scores for files that come in via a pretranslated XLIFF.
### AI Accuracy Per Language Pair
The "AI Accuracy Per Language Pair" table provides detailed accuracy metrics for different language pairs over several months. This table helps identify which language pairs have higher or lower accuracy and track their performance trends.
AI Accuracy does not differentiate between locales, and we track at the language level.
## Quality
Quality metrics displays data from either the Review or Secondary Review stage (whichever occurred last).
Please note that if you do not regularly have a Secondary Review stage, then this page will reflect a restricted view (see below).
![]()
![]()
#### Errors Resolved / 1k Words
This metric shows the number of errors resolved per 1000 words that were resolved between the last month and the current month.
#### Errors Resolved / 1k Change
This metric shows the numerical difference in number of errors per 1000 words that were resolved between the last month and the current month.
#### Most Common Error Type Resolved
This metric shows the most common error type that was found and resolved during the LILT review step based on the [MQM framework](https://themqm.org/the-mqm-typology/).
#### Model Size Over Time
The "Model Size Over Time" chart tracks the growth of the LILT AI model in terms of the number of words added per month. This metric shows how the AI model expands its knowledge base to improve translation accuracy.
#### Quality Scores Over Time
If you do not have the restricted quality score view because your workflows have a Secondary Review stage, then you will see a chart for Quality Score Over Time. This table breaks quality scores down by locale and gives insight into average scores by language/locale pair. These scores dynamically update when filters are applied. This data can give clearer insights into quality performance, making it easier to decide whether quality is high enough to switch to instant translation.
![Image]()
### Connector Jobs
The "Connector Jobs" table provides insights into the performance of various connectors, including their AI accuracy, volume, and submission errors. This information helps identify which connectors perform well and which may need improvements.
Jobs submitted directly via the API (i.e., not associated with a connector) are not included in the Connectors tab analytics.
### On-Time Delivery (OTD) and Words Per Hour (WPH)
* **OTD Over Time**: Tracks the on-time delivery performance of translations over several months.
* **WPH Over Time**: Monitors the words processed per hour, indicating the efficiency of the translation process.
![]()
#### OTD Per Language Pair
The "OTD Per Language Pair" table provides a breakdown of on-time delivery performance for different language pairs.
#### Project Stats
![]()
The Project Stats Report allows you to see active projects. You will have an overview of the number of jobs that are in each state (i.e. Ready to Start, In Progress, In Review, Secondary Review, and Completed). Under the Job Stats tab, you will be able to see further details regarding individual projects that you’ve sent to LILT for Translation. Stats such as State, Created date, Due date and Delivery Date help you and your localization teams manage your day-to-day tracking of projects directly from our platform. You will be able to filter by time (“From” and “To”), Source language, or Target language.
*Note: Project Stats will not display any archived projects.*
### Usage Analytics - Volume & User Activity tabs
**Volume**\
Understand the total amount of translation work being done in LILT.
* **Total Word Volume Translated:** This is the total volume of words translated using LILT’s file Instant Translate feature. You can track this volume over time on a monthly basis to see how it increases or decreases.
* **Per-User Volume:** For any given month, you can drill down to see the Instant Translate volume on a per-user level. Click anywhere into the monthly charts to see a per-user volume breakdown in words.
* **Total File Translate:** See how many files translated total and which users are translating how many files.
**User Activity**\
Track user engagement with the LILT platform.
* **Total User Logins:** See the total number of user logins and track this metric over time.
* **Monthly Drill-Down:** Drilling down into a given month gives insights on the number of total logins, the number of unique users who logged in, and the number of total logins and their last login date on a user level. Click anywhere into the monthly charts to see a drilldown into the total logins per user and their last login date.
### Conclusion
LILT Analytics offers a detailed view of translation accuracy, quality, and efficiency. By monitoring these metrics, users can identify areas for improvement, track progress over time, and ensure high-quality translations across various language pairs and connectors.
# Connect Workflows
Source: https://support.lilt.com/kb/lilt-connect-workflows
**Introducing the Ultimate No-Code Solution for Seamless LILT Integration**
In today’s dynamic digital ecosystem, the agility to adapt and innovate global content workflows is pivotal. Our pioneering no-code connector builder redefines how businesses integrate LILT with their Content Management Systems (CMS) and Translation Management Systems (TMS), offering an unparalleled pathway to global content excellence.
**Transformative Integration at Your Fingertips**
* **Effortless Implementation**: No coding required. Intuitive drag-and-drop interface makes LILT integration with any CMS or TMS straightforward.
* **Scalable Automation**: Automate content translation and distribution workflows to scale with your global ambitions effortlessly.
* **Versatile Compatibility**: Supports a wide range of platforms, ensuring your content is always where it needs to be, seamlessly.
* **Enhanced Collaboration**: Unites content creators, translators, and marketers in a collaborative ecosystem, powered by real-time updates.
* **Culturally Resonant Content**: Guarantees that your content does more than translate—it transforms to engage global audiences meaningfully.
Our no-code connector builder is not just a tool but a transformative solution designed to simplify your global content strategy. By eliminating the complexities of traditional integration methods, we empower your team to focus on creating impactful, culturally resonant content that drives international growth.
## How it works:
Log into LILT and click into Connect
![]()
Click New Connector, at which point you will need to select the system you’d like to connect LILT with. See [here](https://lilt.com/connectors) to find the full list of connectors LILT supports.
![]()
For the connector you’ve chosen to build, select the localization workflow you’d like to set up. See [here](/kb/lilt-workflows) for a review of LILT workflows.
![]()
For your specific workflow and partner system, find and fill in the relevant information for your connector configuration. More information can be found in the knowledge base of individual [connectors](/kb/connect) (i.e. finding the right API key).
![]()
Once you’ve configured the connector, click Verify in the upper right hand corner. This will test the connector setup - the system will notify you of any errors in the configuration (i.e. typo in an API Key), and if there are none, you will be able to save and configure the connector!
## Video Overview
# WebTranslateIt
Source: https://support.lilt.com/kb/lilt-connector-compatible-with-webtranslateit
The LILT connector enables companies to automatically push and pull web content between your preferred project management tool and LILT. This saves you time by providing seamless localization while letting you continue to work in the systems you know.
## Configuration
1. Open your Project in the project management tool, click on `Settings / API Tokens`, and copy the project API token.
2. Email the project management tool API token to your point of contact at LILT to get the integration set up.
## Workflow
Once the connector is configured, content is automatically moved between LILT and the project management tool, as outlined in the sections below.
### Project creation
1. Upload the file you'd like translated into the project management tooI and select the target languages.
2. LILT periodically checks for new files in the project management tool. When new files are detected, LILT automatically creates a Project for each file (and target language) where the content can be localized.
### Project completion
LILT periodically checks for LILT Projects that have been marked as `Done`. When detected, the localized content is automatically pushed back to the project management tool.
\*All third party product and company names are trademarks™ or registered® trademarks of their respective holders. Use of any third party marks does not imply any affiliation with or endorsement by such product or company.
# Create
Source: https://support.lilt.com/kb/lilt-create
LILT Create has been retired and consolidated into **LILT Assist**. Content generation is now available through Assist's Content Creation capability.
LILT Create previously offered standalone, multilingual content generation. That functionality now lives inside LILT Assist, which pairs your company context and linguistic assets with AI models to generate on-brand, locally relevant content in any language — all from a single conversational workflow.
To get started, see:
* [Get Started with LILT Assist](/kb/agent-kb)
* [Create with Assist](/kb/create-with-assist)
If you have questions about this transition, please reach out to your Account Executive or [contact@lilt.com](mailto:contact@lilt.com).
# Domains
Source: https://support.lilt.com/kb/lilt-domains
The **Domains** feature in LILT allows organizations to segment their workflows by assigning resources—such as users, models, and preferences—to specific domains. Whether you're a manager working within a particular domain or an administrator overseeing several, Domains enables you to tailor the LILT experience for each user group. This guide will walk you through setting up, switching, and managing domains.
## What Are Domains?
**Domains** in LILT refer to different operational areas within an organization. They allow administrators to customize and filter data, models, file loaders, and job assignments for specific groups of users, improving focus, efficiency, and privacy between groups' projects.
## Key Features of Domains
* **Personalized User Experience**: Users can switch between domains they have access to, and LILT will update the interface to reflect the content, models, and jobs associated with the active domain.
* **Enhanced Administrative Control**: Admins can create new domains, assign users, and link models, file loaders, and preferences to domains, ensuring efficient workflow management.
* **Domain-Specific Analytics and Job Filtering**: Analytics and job management are automatically filtered by the active domain, making it easier to track and manage tasks.
***
## Setting Up a New Domain
As an **Administrator**, you can create and manage multiple domains to streamline operations across different departments or teams. Here’s how to set up a new domain:
### Step-by-Step Guide for Admins
1. **Navigate to the Domain Management Page**:
* Log in as an Admin role
* Go to the **Settings** menu, and select **Manage Domains**
2. **Create a New Domain**:
* Click on **Create New Domain**
* You’ll be prompted to assign **users**, **models**, and **preferences** (such as file loaders and default languages) to the domain.
3. **Assign Users**:
* Add users to the domain by selecting them from the user list.
* These users will only have access to the models, preferences, and workflows associated with this domain.
![]()
4. **Select Models and Preferences**:
* Choose the models available for the domain. ***Note: Your domain users will only be able to submit jobs for language pairs that have models assigned to the domain. For example, if you have a model assigned to a domain for enUS > frFR and a user tries to create a job for enUS > fr, your job creation will fail. You must have a model created for the domain to create jobs in that language pair.***
![]()
* Set default values, including:
* **Source Language**: The language most commonly used for translation jobs in the domain.
* **Target Languages**: Select default target languages for both **Verified** and **Instant** translation types.
* **File Loaders**: Specify file loaders for the domain, enabling the upload of specific formats.
* **Workflow**: Set the default translation workflow (e.g., Human Translation, Machine Translation).
* **ICU Plural Support**: Toggle on/off ICU plurals based on domain needs.
* **Error logging**: Determine whether error logging in the Review stage is required based on domain needs.
![]()
5. **Save the Domain**:
* After assigning users, models, and preferences, click **Save Domain**. The new domain will appear in the **Domain List** and be available to users in the organization.
![]()
> **Tip:** When setting up domains, consider grouping users by departments (e.g., Marketing, Sales) or by project scope to better tailor workflows.
***
## Switching Between Domains
Once domains are set up, users—particularly **linguistic leads**, **content creators**, and **managers**—can easily switch between them. Switching domains ensures that everything in LILT, including jobs, analytics, and file loaders, is filtered according to the active domain.
### How to Switch Domains:
1. **Locate the Domain Dropdown**. In the upper left corner of LILT, you will see a dropdown that shows your current domain.
2. **Select a New Domain**. Click the dropdown and select from the list of available domains. After selecting a new domain, all domain-specific content, including **jobs**, **models**, **data sources**, **file loaders**, and **analytics**, will automatically update to reflect the new domain.
![Image]( "Image")
#### What Changes When You Switch Domains:
* **Analytics**: All project data is filtered to display analytics only for the selected domain.
* **Jobs**: You will only see jobs associated with the selected domain under **Browse Jobs**.
* **Models**: Only models relevant to the current domain will be visible in the **Custom Models** section.
* **Data Sources**: Only data sources relevant to the current domain, based on Custom Models, will be visible in the Data Sources section.
* **Preferences**: Default languages, file loaders, workflows, and settings on the **Translate Upload** page will reflect the settings for the active domain.
***
## Admin Functionality: Managing Domains
### Domain Management Overview
As an admin, you have full control over the creation and management of domains. This includes not only setting up domains but also editing and removing them as organizational needs change. Here are key actions an admin can perform:
### Editing Domains
1. **Edit Domain Details**:
* Navigate to **Manage Domains**.
* Select the domain you want to edit.
* You can update **domain name**, reassign users, or modify preferences like file loaders and models.
2. **Assign and Manage Users**:
* In the domain settings, you can add or remove users. This ensures that only users within the domain have access to its resources and workflows.
3. **Add or Remove Models and File Loaders**:
* Add or remove models or file loaders as needed, allowing the domain to evolve alongside changes in the team’s requirements.
4. **Set Default Domain Preferences**:
* Set preferences like default source/target languages and workflows. Any changes here will apply to all users within the domain, streamlining their translation process.
![]()
### Deleting a Domain
1. **Navigate to Domain Management**:
* If a domain is no longer required, go to the **Manage Domains** page
2. **Delete the Domain**:
* From the domain list, select the **Delete** option next to the domain you want to remove.
* A confirmation modal will appear; click **Delete** to remove the domain.
* LILT will update, and the domain will be removed from all associated users and resources.
### Key Considerations
* Deleting a domain will remove all associated user settings, models, and file loaders tied to that domain. Make sure to communicate with your team before making any changes.
* **Billing**: Jobs and projects linked to the domain will still be accessible for billing purposes in the backend, ensuring there are no discrepancies.
### Using Domains with Single Sign On
For more information about using Domains with Single Sign On, see [here](https://support.lilt.com/kb/single-sign-on-sso-for-lilt-com).
***
## How Domains Affect Users
### Day-to-Day Use for Non-Admins
For non-admins, such as **project managers**, Domains simplify the user experience by tailoring LILT's interface and content to specific workflows. When a user switches to a domain, the following actions are customized:
* **Translation Jobs**: Users will only see the jobs relevant to the domain they are currently working in.
* **Analytics**: Project analytics will be filtered by the selected domain, ensuring users can focus on the metrics that matter.
* **Upload Defaults**: Source and target languages, file loaders, models, and workflows will be pre-filled based on the active domain, speeding up the translation process.
* ***Note: You will only be able to submit jobs for language pairs that have models assigned to the domain. For example, if you have a model assigned to a domain for enUS > frFR and you try to create a job for enUS > fr, your job creation will fail. You must have a model created for the domain to create jobs in that language pair.***
***
## Conclusion
The **Domains** feature in LILT is a transformative tool for large organizations, offering enhanced control over user experiences, resource management, and workflow optimization. By enabling administrators to set up domains and manage them with precision, LILT ensures that each team can operate within the specific context they need to succeed.
For more detailed instructions on setting up, switching, and managing domains, please visit the **Help Center** or contact **LILT Support**.
# File Loaders
Source: https://support.lilt.com/kb/lilt-file-loaders
## Overview
LILT's custom file loader feature allows managers and administrators to upload, apply, and manage organization-specific file loaders for translation workflows. This guide outlines the procedures for utilizing custom file loaders within the LILT platform, ensuring a tailored translation process that fits your organization's needs.
*Note: Loaders are commonly referred to as filters in localization. They function in a similar manner.*
## Uploading a Custom File Loader
### Accessing the Custom File Processing Interface
1. Navigate to the LILT dashboard.
2. Click on “Manage” in the navigation bar.
3. Select “File loaders”.
### Creating a New File Loader Configuration
1. Click the “New configuration” button.
2. Fill in the following fields:
* **Name**: Enter a distinctive name for the file loader.
* **Description**: Provide a brief description of the loader's functionality
* **Base loader (filter)**: Select an existing base loader as a foundation for the new configuration, if needed.
### Uploading the Configuration File
1. Under “Upload a file”, click “Upload”.
2. Choose the appropriate configuration file from your device (maximum size 200MB).
**Note**: The platform supports a variety of file formats. Ensure your file meets the required specifications by checking “See supported formats.”
![]()
## Selecting a File Loader for Translation
### Applying a Custom File Loader During Translation
1. When sending a file for translation, select the “Translate” tab.
2. Go through the Translation workflow and click “Upload” to choose the file to be translated.
3. The system will automatically detect the file type and suggest a corresponding file loader.
* If necessary, you can override the suggested file loader by selecting “Change File Filter” from the dropdown list.
![]()
### Applying a Custom File Loader after Pre-processing
If a job was created with an unprocessable file by default and needed pre-processing, File Loaders can be set and applied while pre-processing documents.
1. After a job is created with a pre-processing stage, download and process the files offline.
2. Once your files have been processed, upload back to the LILT platform in the Source Files section.
3. To apply a file loader, click on "Change file loader" and select one of your configured file loaders. If a default file loader was set for the detected file type, it will be automatically chosen. If none is chosen, LILT's platform file loader will be applied.
![Screenshot2025 10 01at10 42 25 Pn]()
### Setting and Using Default Loaders
1. If a default file loader is set for the detected file type, it will be automatically chosen. If none is chosen, LILT’s platform file loader will be applied.
2. To change the loader, click on the dropdown list and select an alternative loader.
3. If no default is set, the dropdown will display an empty state.
* It is optional to have a loader designated as Default.
## Managing Custom File Loaders
### Accessing File loader Management
1. Under "Manage" on the LILT dashboard, access "File Loaders".
### Managing Existing Loaders
1. To delete a loader, locate the loader and select the delete option. Deleted loaders will no longer appear in the dropdown.
2. To set or change a default file loader, select the appropriate option from the loader's settings.
## Default System Behavior
If no custom file loader is selected, LILT will continue to use the Okapi default loader as per the existing behavior.
## Important Considerations
* Deleted loaders cannot be recovered.
* The ability to upload and manage file loaders is limited to users with manager or administrator roles.
* Ensure that the configuration file complies with LILT's format requirements to avoid upload errors.
* For assistance or troubleshooting, contact LILT support.
# Evaluate
Source: https://support.lilt.com/kb/lilt-label
LILT Evaluate is an AI-optimized and human-reinforced solution for labeling multilingual AI training data that allows you to confidently build AI datasets. In short, this module is designed to make conversational AI models multilingual.
Labeling data with LILT Evaluate offers many benefits, such as:
* **Expanded data pool** - Curate non-English datasets to avoid biases and broaden global perspectives in a ***secure environment***.
* **Assured data quality** - Source responses from native-speaking, domain experts to ensure accuracy and cultural nuance.
* **Accelerate the creation process** - Utilize a quick and intuitive solution for building, annotating and refining data with ease.
Jobs are structured similarly to traditional translation jobs: Job - Project - Document. Each prompt is considered one “document” and doesn’t go through any segmentation. For example, if an uploaded excel has 10 rows of prompts, it will appear as one project with 10 documents.
LILT Evaluate has a separate Browse Jobs list and separate linguist interface. Any jobs created within LILT Evaluate will not be available or visible from the Translate Browse Jobs page.
For pricing and more information, please reach out to your Account Executive.
# Linguist Homepage
Source: https://support.lilt.com/kb/lilt-linguist-homepage
The Linguist homepage is a completely redesigned homepage for linguists. The designs were optimized for simple navigation and project prioritization. On the Linguist Homepage, linguists can now see due dates, customer names, project stages, total segments, and completion percentage for each individual document. These documents can be organized into completion states, quickly filtered, and easily ordered. All these improvements enable linguists to quickly sort through their documents, find the most important job, and start translating!
![]()
On Home, you will find 4 primary categories of Jobs:
* New
* *Jobs that have just been assigned to you, where you will have the option to Reject or Accept*
* In Progress
* *Jobs that you have begun work (translation or review) on but not yet completed*
* Completed
* *Jobs that you have completed work on*
* Quality Feedback (Delivered)
* *Any jobs that have been delivered to the customer, with potential access to revision reports.*
Please note you will still have access to the **Jobs** view, and **Linguist Stats** via the sidebar.
# LILT MCP Admin
Source: https://support.lilt.com/kb/lilt-mcp-admin-page
LILT's **MCP admin page** is the administrative interface for enabling and disabling LILT's MCP (Model Context Protocol) server and viewing or revoking connections from external AI assistants. It enables organization admins to manage LILT's MCP server integration. To access the MCP Admin page, navigate to "Manage" on the sidebar, and scroll to the bottom to double click the "MCP" bar.
![MCP Admin Navigation]()
## **MCP "On/Off" Toggle**
Toggle the org-wide setting to the right to enable org users to connect LLMs to LILT via LILT's MCP Server.
![LILT MCP On Off Toggle]()
## **MCP Connections Overview**
The MCP Admin home page displays which external AI clients (Claude, ChatGPT, Gemini, Copilot, etc.) are connected to LILT's MCP server, along with their connection status.
## **Client Connection Deep Dive**
Double click on a specific client to see connected users and revoke individual connections as preferred.
# Custom Models
Source: https://support.lilt.com/kb/lilt-model-hub
## Managing Models within LILT
Within the Model Hub you can create and update Models from LILT and third party translation providers.
### Setting up a Model
![]()
To get started, navigate to the `Manage` tab. Inside the `Model Hub` tab you'll see a list of models
To create a new model:
1. Using the sidebar navigate into “Manage” then select “Model Hub”.
2. Once on the Models page, select “+ New Model”.
1. Create a name for your model, note this name will carry over onto the third party system as well.
2. Enter source and target languages
1. The source and target languages shown are pulled live from your connected provider account, so they always reflect what that provider supports for your specific account (plan, region, and project settings can affect this). If the picker appears empty or a language is missing, confirm your provider credentials include list-languages permission — LILT will prompt you if additional credential scope is required.
3. Select a reference Data Source. Memory and Termbase entries from this Data Source will be sent to your 3rd-party LLM provider to fine-tune your Model.
4. Select from enabled [AI providers](/kb/3rd-party-llm-support-for-the-contextual-ai-engine).
5. Click `Create`.
![]()
### Retraining an existing Model
LILT stores your linguistic assets in Data Sources, and adds entries with each sentence translated during Verified Translation projects. If at any time, you want to use that data to retrain and customize your 3rd-party models, simply navigate to the models page and select “Retrain”. This action will prompt you with a confirmation modal showing the LLM and time since last training. If you wish to update the model with the new entries from your Data Source, confirm by clicking “Retrain”.
✔️ Please note that LILT Contextual AI models are continuously trained in real time, so there is no need to retrain manually through this process!
## Available Translation LLM Integrations Within LILT
Alternate LLMs that can be configured in [AI providers](/kb/3rd-party-llm-support-for-the-contextual-ai-engine) that may support other languages. Translation quality can vary for less common languages. Please reference the linked documentation below for their list of supported languages, and the [LILT Custom Models](/kb/lilt-model-hub) page for more information.
* [Amazon Translate](https://docs.aws.amazon.com/translate/latest/dg/what-is-languages.html)
* Google Translate.
* Language pairs that support [custom models](https://docs.cloud.google.com/translate/docs/languages#automl) offer fine-tuning capabilities through Google's Cloud Translation API.
* Language pairs from the [Neural Machine Translation model](https://docs.cloud.google.com/translate/docs/languages#nmt) section will support instant translation but NOT fine-tuning of any kind.
* [DeepL](https://developers.deepl.com/docs/getting-started/supported-languages)
* [OpenAI](https://platform.openai.com/docs/guides/speech-to-text/supported-languages#supported-languages)
* [Anthropic](https://platform.claude.com/docs/en/build-with-claude/multilingual-support)
LILT, Amazon, and Google all offer fine tuning of their LLMs with parallel data. As your Data Sources within LILT grow, you can easily retrain your Models from these LLMs through LILT’s Model Builder interface on the Models page. Fine-tuning allows for improved translation with extra data from segments and terminology. Only LILT Contextual AI models allow for [real-time training and adaptation](/kb/what-is-interactive-adaptive-mt#WhatisContextualAI?-ContextualAIisAdaptive).
| **LLM** | **Fine tuning: segments** | **Fine tuning: terminology** | **Real-time training** |
| ------------------ | ------------------------- | ---------------------------- | ---------------------- |
| LILT Contextual AI | Yes | Yes | Yes |
| Amazon Translate | Yes | Yes | No |
| Google Translate\* | Yes | Yes | No |
| DeepL | No | Yes | No |
| OpenAI | No | Yes | No |
\*Only available on US-Central
## Video Overview
# System Architecture
Source: https://support.lilt.com/kb/lilt-system-architecture
## Overview
This article details the LILT System Architecture, including LILT-managed components, integrations, and customer-managed services. LILT supports three deployment models: GCP-hosted (multi-region), self-managed on AWS, and self-managed on bare metal infrastructure.
## Architecture Overview
![Lilt Architecture Overview]()
## Architecture Diagrams
### GCP Hosted Architecture
The GCP-hosted deployment runs across US, Asia, and Europe regions with Google-managed services for data storage and analytics.
![LILT GCP Hosted Architecture]()
**Key characteristics:**
* **Multi-region:** Cloud Load Balancing, GKE, Front App, and Redis are deployed across US, Asia, and Europe
* **US-only services:** Core Services, Neural Services, Connectors, Elasticsearch, Cloud SQL, Cloud Storage, BigQuery, GPU Pool, and the LILT Assist / Enterprise MCP backend
* **GCP managed services:** Pub/Sub, Cloud SQL (MySQL), Cloud Storage, BigQuery, Salesforce (CRM integration), and Google Cloud Vertex AI (Gemini / Claude Haiku LLM reasoning)
* **Cluster services:** Redis (caching), ClickHouse (analytics), Dataflow, and the LILT Assist / Enterprise MCP Server backend
* **Analytics pipeline:** Dataflow connects Core Services to ClickHouse; Cloud SQL feeds BigQuery via Scheduler; Salesforce data flows into BigQuery
### Self-Managed AWS Architecture
For customers deploying on AWS infrastructure with AWS-managed data services.
![LILT Self-Managed AWS Architecture]()
**Key characteristics:**
* **AWS managed services:** RDS (MySQL), S3, SQS
* **Cluster services:** Redis, ClickHouse, MongoDB, Dataflow
* **Additional components:** Dataflow connects Core Services to ClickHouse; SQS provides message queuing
* **Neural services** include LLM inference workloads (VLLM-based: Gemma, LLaMA) alongside traditional translation services
### Self-Managed Bare Metal Architecture
For air-gapped or on-premises deployments where all services run within a single Kubernetes cluster.
![LILT Self-Managed Bare Metal Architecture]()
**Key characteristics:**
* **All services self-hosted:** MySQL, MinIO (object storage), Redis, MongoDB, ClickHouse, Elasticsearch
* **Additional components:** Dataflow connects Core Services to ClickHouse
* **Single Kubernetes cluster** with client load balancer and ingress
* **No external cloud dependencies** — suitable for air-gapped environments
## LILT-Managed Components
This section details the components managed by LILT. The LILT-managed components include all Application services, the Neural services performing translations, and the Core services responsible for the backend functionalities such as file import/export, audit logs, search and more. All components are integrated with RabbitMQ to communicate via message sharing.
### Neural services
LILT's neural services include all of the components that perform language detection and machine translations. The neural services are responsible for detecting languages, performing interactive and batch translations, and memory management.
### Front services
LILT's front services include the user-facing applications. Information and actions performed in the front services are transferred to the core and neural via RabbitMQ.
### Core services
LILT's core services handle everything outside of translation and language detection. This includes audit file handling, logging, tagging, QA, assignments and more. The core services act as the central management hub for LILT, passing information to the front containers and submitting work for the neural containers.
### Assist services
LILT's Assist services are user-facing AI chat services. They are composed of the Assist UI (an interactive frontend chat interface embedded in the translation editor) and the MCP Server backend (the backend execution coordinator). LILT Assist leverages the Google Agent Development Kit (ADK) to run an iterative reasoning loop, calling external LLMs (such as Claude Haiku 4.5 via Google Vertex AI) and querying LILT Core services for translation memory (TM) and termbase (TB) lookups. All Assist requests and tool executions are securely scoped and restricted to the specific roles, resources, and organization permissions of the current signed-in user.
### Enterprise MCP Gateway
The LILT Enterprise MCP Gateway is a Model Context Protocol endpoint hosted within the MCP Server backend at `https://mcp-enterprise.lilt.com/mcp`. It exposes the exact same underlying tools and reasoning capabilities as the LILT Assist chatbot (including translating text, searching translation memories, or querying terminology) to external enterprise AI agents, orchestrators (e.g., LangChain), and IDE extensions (e.g., Cursor). It is fully secured using Ory Hydra OAuth 2.1 with opaque token introspection, allowing secure external execution contexts. All queries and tool executions dispatched through the MCP gateway are securely scoped and restricted to the specific roles, resources, and organization permissions of the current authenticated user session.
## Self-Managed Components
### Data Storage and Microservices
All data storage and microservices are managed by the customer in the self-managed implementation.
### Infrastructure services
For self-managed installation of LILT, the applications below are also installed to enable LILT to function:
* [MinIO](https://min.io/): Object Storage Server
* [OpenEBS](https://openebs.io/): Local Persistent Volume Provisioner
* [MySQL](https://www.mysql.com/): Database
* [Redis](https://redis.io/): Data Structure Caching
* [RabbitMQ](https://www.rabbitmq.com/): Queue Management
* [Istio](https://istio.io/): Service mesh and ingress gateway. Deployed in [ambient mode](https://istio.io/latest/docs/ambient/overview/), which uses a per-node `ztunnel` proxy for transparent mTLS between workloads instead of injecting a sidecar into each pod.
* [ElasticSearch](https://www.elastic.co/): Indexing
* [ClickHouse](https://clickhouse.com/): Analytics Database
* [MongoDB](https://www.mongodb.com/): Auditlogs database
* [Qdrant](https://qdrant.tech/): Vector database used by the neural translation service (rayman) for translation-memory nearest-neighbor retrieval
* [KubeRay](https://github.com/ray-project/kuberay): Kubernetes operator that manages the Ray cluster powering the neural translation service (rayman)
* [Nvidia-device-plugin](https://github.com/NVIDIA/k8s-device-plugin): GPU management in Kubernetes
# Project Manager Guide
Source: https://support.lilt.com/kb/lilt-translate-guide-for-project-managers
This article discusses the tools for downloading and unlocking a document. Project managers make use of these tools to manage document workflow through the translation process.
The downloading and unlocking tools are available in the `File` menu from inside [LILT Translate](/kb/introduction-to-lilt-translate).
![]()
## Document download
When downloading, the translated version of the document will be downloaded. If some parts of the text have not been translated yet, they will be preserved in the original language. Download options:
* **Download:** Download in the same format as the document was uploaded. This option is not available for documents uploaded as PDF files.
* **Download TXT:** Download in TXT format.
* **Download XLIFF:** Download in XLIFF format.
![]()
Downloading documents individually can be useful if you need to use a document before the other documents in a Project have been completed. To learn about downloading all documents in a Project, see the article on [Project Delivery](/kb/project-delivery).
## Unlock document for translation
After a document has been marked as done in Translate mode, project managers (and any other users with [Create/Edit Project](/kb/default-roles) permissions) will see an option under the `File` menu to `Unlock document translation`. Selecting this option will undo the `Mark As Done` option applied by the translator to reopen the document in Translate mode, making all unaccepted segments available to edit by translators.
![]()
Project managers can also unconfirm individual segments in a document.
## Unlock document for review
After a document has been marked as done in Review mode, project managers (and any other users with [Create/Edit Project](/kb/default-roles) permissions) will see an option under the `File` menu to `Unlock document review`. Selecting this option will undo the `Mark As Done` option applied by the reviewer to reopen the document in Review mode, making all segments (that aren't locked) available to edit by reviewers.
![]()
Project managers can also unaccept individual segments in a document.
## Marking a document as done
The `Mark as done` popup appears in Translate mode when all segments are confirmed and in Review mode when all segments are accepted.
![]()
If a document has been marked as done, a status indicator will be displayed at the top-right of the document in LILT Translate.
* Translate mode status indicator:
![]()
* Review mode status indicator:
![]()
When a document is marked as done, the segments become locked and cannot be edited by the translator or reviewer.
* Marking a document as done in Translate mode locks the segments in Translate mode.
* Marking a document as done in Review mode locks the segments in Review mode.
If changes need to be made after a document is locked, project managers can unlock an entire document or can unconfirm/unaccept individual segments within the document, as described in the sections above.
Even while a document is locked, linguists can still use the [Find and Replace](/kb/find-replace) functionality and tools like [Concordance](/kb/concordance).
# Workflows
Source: https://support.lilt.com/kb/lilt-workflows
Workflows in LILT are designed to provide flexibility in balancing AI efficiency with human expertise based on a customer's specific translation needs and quality requirements.
## Available workflow options
1. Translate
2. Translate > Review
3. Translate > Review > Secondary Review
4. Translate > Secondary Review
5. Instant > Review
6. Instant > Review > Secondary Review
7. Instant > AI Review > Review
8. Instant > AI Review > Review > Secondary Review
All jobs and projects are required to have a workflow assigned, and different workflows support various levels of automation and human oversight. A few other things to note:
* Review cannot start until the translator marks the document as done.
* Workflows that start with an Instant stage will automatically process the Instant translation step. Once the Instant step is completed, the Review step can be started.
* Secondary reviewers cannot access the document until the document is ready for secondary review (Doc status = Secondary Review).
* Please reference our [AI Review Agent page](https://support.lilt.com/kb/ai-review#ai-review) for more information on that workflow stage.
#### Selecting a workflow
All jobs and projects are required to have a workflow. Default workflows are defined in the [Job Form Editor](https://support.lilt.com/kb/Job-Form-Editor). Admins can change the workflow during job creation.
![]()
On the Jobs page, Admin and Managers can see the workflow defined for the job.
![]()
For added visibility, Admins and Managers can also see which workflow was selected at the top of the Documents page.
![]()
#### Document Status
Document statuses automatically update based on user actions as illustrated below.
![]()
Users with the permission to create/edit jobs and projects (like Admins and Managers) can manually change the document status. This can be used if you want to skip a step in the flow.
![]()
For translator roles, the document status does not appear editable and cannot be manually changed.
#### User Assignment & Workflows
The workflow selected affects the number of users you can assign at the project/document level.
For example, you can assign two users if you select the Translate > Review workflow. Three if you select the Translate > Review > Secondary Review workflow or only one if you select the Translate workflow.
Document level user assignment. Project is using the Translate > Review workflow. (you can’t have documents with different workflows. they all use the workflow assigned at the project level)
![]()
Project level assignment. Project is using the Translate only workflow.
![]()
### FAQ
#### When should I use a workflow with the Secondary Review stage?
The Secondary Review stage in LILT is only meant for secondary review performed inside LILT’s CAT editor. If you are doing secondary review offline (outside of LILT) please do not select a workflow that has the secondary review stage included.
#### What should I do if a notification appears that MT is in progress?
This means that either the Instant step or pre-translation is being completed. Once either is complete, the workflow will automatically advance to the next stage.
#### What if I want to change a project’s workflow?
You cannot change a job or project’s workflow once created.
#### Connectors
Any job/project created via connector will be assigned the organization's default workflow. The ability to assign a different workflow depending on the connector will come in a future feature release.
Please note that after the connector brings the project into LILT, you cannot change the workflow.
# LILT x Google Translate
Source: https://support.lilt.com/kb/lilt-x-google-translate
In 2023, LILT built an integration with Google Translate. With this integration, customers can input their GCP credentials and send documents to Google Translate for both instant translation and AI>Review workflows. This integration can:
* Integrate with Google Translate and pull Google Translate content into LILT
* Deploy Google Translate content in workflows
* Send training data back to Google Translate for fine-tuning
Below is a description of how this is completed.
Configuring Google Translate within LILT is a straightforward process. In LILT’s AI Hub, users upload a Google service account credentials file and specify a Google Cloud Storage bucket name. Note that this bucket must be located in the `us-central1` region — all Google-side model resources are created there, and fine-tuning is only available for this region. Once this is complete, a user navigates to LILT Model Hub to create a Google model. Creating a model in LILT sends a request to Google's Cloud Translation API to create a custom translation model (this capability was previously built on Google's legacy AutoML Translation API, which Google retired in September 2025; LILT's integration now uses Google's current Cloud Translation Advanced/v3 API for the same custom-model training). If the user desires, they can send bilingual translations stored in LILT to fine-tune the Google model. A fine-tuned model will produce translations which are more contextually accurate to the bilingual training data.
Once a Google model is created within LILT, it can be used for translating documents and in LILT’s AI>Review workflow. The translation of documents will use an API call to Google to complete a document translation. The AI>Review workflow is similar, but different in that the translated document is parsed into LILT’s CAT editor, where a reviewer can go through and make post-editing modifications as needed.
For more information about LILT third-party integrations and Google specific credentials see the following LILT knowledge base entry:
* [/kb/3rd-party-llm-support-for-the-contextual-ai-engine](/kb/3rd-party-llm-support-for-the-contextual-ai-engine)
* [/kb/google-configuration](/kb/google-configuration)
### Appendix A: Google Translate Orchestration in LILT
![]()
# My Stats
Source: https://support.lilt.com/kb/linguist-stats
My Stats provides information on payment data broken down by Project and Document.
## Accessing the report
You can access the report by clicking the `My Stats` tab underneath your homepage.
If you are having issues accessing the report, try the following:
* Disable any ad blockers from running on lilt.com.
* Access LILT in an incognito browser window.
## The report explained
### Important notes about this feature
* This report does not impact your payments. Payment procedures are outlined in the [Payment Policy](https://discourse.lilt.com/t/lilt-payment-policy/10345/9) article on Discourse.
* Project information is only viewable in the LILT Platform while a Project is in a non-archived state. Once a Project is archived, Project status information becomes inaccessible.
* The dashboard does not update in real-time. It takes **4 hours** before your work will show up in the dashboard.
* Platform work is paid at a fixed rate per task or project, set and visible in the offer email before you accept.
### Payment by Project and document
The table displays a number of metrics broken down by Project and document.
![]()
* **ProjectID & Project Name:** Identify the project associated with your stats and payout.
* **Source & Target Language:** Source and target language of the project worked on.
* **Est Review Payout:** Your payout based on what you accepted from the assignment email.
* **Est Translation Payout:** Your payout based on what you accepted from the assignment email.
* **Est Total Payout:** Your total payout based on what you accepted from the assignment email.
* **Customer Name:** Name of customer related to the project
* **Translator Delivery Date:** The date that your work was completed
* **Customer Delivery Date:** The date that LILT delivered to the customer
* **Payout Date:** The date that you should expect to be paid based on LILT's payout schedule.
*Note: If you are an Agency expert working with LILT, you will not see payout information in your offer emails or in your My Stats dashboard.*
**Offline Projects**
For offline payments, click on Offline Payments next to Project-wise details, which will provide a breakdown of the project, the date, amount, and status of your payment.
![]()
# First Time Login
Source: https://support.lilt.com/kb/logging-into-lilt-for-the-first-time
## Logging Into LILT For The First Time
You can login to LILT for the first time with three easy steps:
1. When being onboarded as a linguist, new organization, or new team member you should receive an email with the subject \[name/person] “invited you to join LILT”. Within the email, click “Get a Free Account”.
![]()
2. The "Get a Free Account" link will navigate you to a password reset page. Set your password for the first time using a password that meets our requirements. This will be your login password.
![]()
3. Use the email address where you received the Invitation to LILT and the password you created to login to LILT for the first time!
4. For more information about setting up SSO see our [Single Sign-on (SSO) for LILT.com](/kb/single-sign-on-sso-for-lilt-com)
![Image]()
## Language configuration
Use the Language selector in the upper right corner of the login page to set the platform language. LILT currently supports English, German, and Japanese. Language can also be set from your profile once logged in.
![Screenshot2026 01 13at10 46 39]()
Alternatively, this can be configured after logging in by going to Profile > Display Language.
![Screenshot2026 01 13at10 44 39]()
# Lokalise
Source: https://support.lilt.com/kb/lokalise
The LILT + Lokalise connector enables companies to automatically push and pull web content between Lokalise and LILT. This saves you time by providing seamless localization while letting you continue to work in the systems you know.
The connector supports:
* **Job submission via Lokalise**: Create a new Job in LILT by creating a [task](https://docs.lokalise.com/en/articles/1457259-tasks) in Lokalise and assigning it to a LILT Lokalise user.
* **Job progress monitoring**: Within Lokalise, you can check whether a key has been retrieved by the LILT connector and whether a key has been delivered back into Lokalise.
* **Job delivery to Lokalise**: Once content is localized in LILT, LILT delivers the localized content to Lokalise for approval.
* **TM selection**: LILT can set up Lokalise TMS to be used with specific language pairs.
Check out the video below to see the LILT + Lokalise connector in action.
## Configuration
At a high level, the installation steps are as follows:
1. Invite LILT as a Contributor to your Lokalise organization.
2. LILT accepts the invite and procures a Lokalise API token.
To set up your LILT + Lokalise connector:
1. The customer must first invite LILT as a [Contributor](https://docs.lokalise.com/en/articles/2983736-onboarding-guide-for-project-managers) to their Lokalise team. This can be accomplished by navigating to `Contributors` > `Invite` and entering `connector-accounts@lilt.com` as the email address.
![]()
2. LILT will receive an invite email with instructions for how to create an account within the customer's Lokalise team. Once in Lokalise, the API token can be retrieved by navigating to `Account` > `Personal profile` > `API tokens`. A new token can be created by selecting the `Generate a new token` button.
![]()
3. Once the API token has been retrieved, the connector can be configured by LILT.
## Workflow
Once the connector is configured, content is moved between LILT and Lokalise as outlined in the sections below.
### Job creation
Customers can send new or exiting content to LILT for localization by assigning the LILT contributor to one or many tasks. The connector periodically checks for tasks that have been assigned to the LILT contributor. When tasks are found, the content is automatically pulled into LILT for localization.
Keys imported by LILT are labeled with specific tags, so customers can see which keys will be translated by LILT.
### Job completion
Once the content has been localized in LILT, the target content is automatically delivered to Lokalise.
Keys delivered by LILT are labeled with specific tags, so customers can see which keys have been translated by LILT.
# Instant Translate
Source: https://support.lilt.com/kb/machine-translation
## Contextual AI Engine
LILT uses Contextual AI to provide quick translations and to provide translation suggestions to linguists working in [LILT Translate](/kb/introduction-to-lilt-translate). Each Data Source has its own Contextual AI model that can be [managed from inside the Data Source](/kb/resetting-the-mt-purging-or-preserving-memories). Each model starts out as a copy of LILT's baseline model, built using training data. If the `in-context learning` option is enabled for the Data Source, the model adapts as linguists process translations in LILT Translate.
## Where Contextual AI is used in LILT
* LILT Translate segment suggestions.
* [**Pretranslation**](/kb/pretranslating-documents)\*\* or Instant workflow stages\*\*: Pretranslation or Instant workflow stages will translate any segments that aren't 99% or exact matches (100% or 101%).
* [**Instant translate documents**](/kb/instant-translate-documents) and [**instant translate text**](/kb/instant-translate-text): Self-managed customers can utilize Contextual AI to quickly translate documents and blocks of text.
## Contextual AI segment suggestions
When working in LILT Translate, translation suggestions are provided to linguists for the active segment. If there are any [TM matches](/kb/translation-memory-matching) above 75%, the best match will be displayed as the suggestion. However, if there are no such TM matches, LILT uses the associated Contextual AI to provide suggestions to the linguist. [***Note that if the language pair does not have Contextual AI support, no suggestions will be shown.***](/kb/supported-languages)
![]()
# Contextual AI Model Training
Source: https://support.lilt.com/kb/machine-translation-model-training
## How We Train Our Contextual AI Models
In this article, we describe how LILT trains its Contextual AI models behind the scenes. This article is meant for a technical audience or anyone interested in turning raw data into functioning Contextual AI models.
## Data Collection
LILT uses both open and paid data sources to get parallel text data, the key component to translating Contextual AI models.
Open sources are freely available and vetted sources of parallel text data, usually made available with the license CC-BY or CC-BY-SA. Some of the sources are [Opus](https://opus.nlpl.eu/), [Paracrawl](https://www.paracrawl.eu/), and [CCMatrix](https://github.com/facebookresearch/LASER/tree/main/tasks/CCMatrix).
Paid sources are those made under the CC-NC license, which makes them usable for only non-commercial and research purposes. We need to pay a fee to be able to use them in our models. An example source is [WIPO COPPA V2](https://www.wipo.int/patentscope/en/data/).
When it comes to data size -- the more, the better. More data generally leads to higher quality Contextual AI models. To date, we have collected 3.8B segments across 76 language pairs.
## Data Preparation
Each piece of data we obtain from the above sources is rigorously processed. Suffice to say that preparation of the data is a Herculean task -- before we even start training. Here’s how we do it!
### Clean and validate
We perform a basic syntax-based cleaning using the below substeps:
1. Remove any blank sentences
2. Remove sentences containing only punctuation
3. Validate that source and target language files contain a matching number of segments (otherwise, discard the source).
### Version the Data
We version our data with [DVC](https://dvc.org/features), as it allows combining the source and target files, and any additional internal tracker files into a single unit. The single unit is a .dvc file, which is committed to our GitHub to track all the data sources we use.
### Normalize Segments
To ensure consistency of all segments, we perform the following steps:
1. Normalize Unicode: Text like Unicode or HTML text is converted to human readable text. Eg *Broken text\… it\’s flubberific!* is converted to *Broken text... it's flubberific!*
2. Normalize non-breaking spaces: For languages like French, where there are strict rules about positions of non-breaking spaces, this step adds the spaces where necessary, if they are not already present.
### Filter
First, we remove potentially problematic segments from a corpus at segment- or segment-pair-level. This is known as individual filtering.
1. Script: It’s a fair assumption that if a *ja* (Japanese) segment contains a *ta* (Tamil) token/phrase, it may not be usable during training. We maintain rules for scripts that are not effective when embedded in another script, and remove those segments.
2. Language code: We use the python cld3 package to identify a segment’s language; if it doesn’t match the corpus language, it is discarded.
3. Exclude patterns: We exclude segments matching regexes that identify problematic patterns, for example, "http\://" for URLs.
4. Segment length: We exclude any segment longer than 300 words (configurable per language).
5. Number mismatches: We exclude any segment pair which uses the same numeral system, but contains different numbers in the source and target segments.
6. Length Ratio: We exclude any segments where the source or the target segments are unusually long or short for a segment pair, after comparing with a threshold computed on the entire corpus.
7. Edit Distance: We exclude any segments where the source and target segments are identical or similar, since this may indicate mistranslation. We check the edit distance between the source and target segments against a minimum of 0.2.
### Augment Data
When presented with unfamiliar or underrepresented data, machine translation models can fail by producing “hallucinations” -- translated text that is divorced from the original source text. To ameliorate this problem, we artificially generate (augment) examples of parallel sentences. Training with the augmented examples improves the model’s robustness and resilience towards these data, allowing us to effectively translate a wide variety of customer domains. We augment existing segment pairs in the following ways:
1. Multi-segment: We concatenate up to 5 consecutive segments to form a single long segment.
2. Capitalization: We capitalize the selected segments based on *UPPERCASE* and *Title Case* capitalization schemes.
3. Non-Translatables: We introduce Non-Translatables used by our customers by detecting common tokens/phrases in source and target segments and wrapping them with \$\{ and } characters.
### Byte-pair Encode (BPE)
The vocabulary for a large corpus can be huge, with many words seen rarely. We perform byte-pair encoding (BPE) on the words to break them down into word pieces (e.g., *eating* might be separated into *eat* and *ing*). This allows us to fix the size of the vocabulary, and by extension, the Contextual AI model and hence the resources required to train the model.
BPE further allows us to translate segments with tokens which haven’t appeared in the training corpora, common in morphologically rich languages such as romance and Slavic languages, since we can split tokens into familiar word pieces.
## Training the Contextual AI Models
Since the Transformer architecture hit the scene, we’ve based our production translation models on it.
Before we move into the specifics of the transformer model, permit a quick digression on a concept known as the \*embedding space \*or *continuous representation space*. Each point in this high-dimensional space represents the meaning of a sentence. Two sentences that are similar in meaning will have representations that are close to each other. You can guess how this concept fits into designing a machine translation model. We just design two components:
\*Encoder: \*This takes a source sentence(s) and transforms it into the embedding space representation
\*Decoder: \*This takes the embedding space representation and converts it into a sentence(s) of the target language
The Encoder and Decoder together form a Contextual AI model for a given language pair. Sequence-to-sequence (seq2seq) is a catchall name for the models using this encoder-decoder architecture, of which the Transformer is widely regarded as the most performant.
This is what a Transformer model looks like:
![]()
Given the architecture, we must choose the size of the model. The model size is determined by the number of parameters, and is akin to the capacity of a hotel. The information learned from the corpora in training is analogous to the number of people actually in the hotel.
We want to achieve maximum utilization, so we use the number of sentences in the parallel corpora obtained from the **Data Preparation** section to determine which model size is best for a given language pair:
* Small model for when fewer parallel sentence pairs are available, eg English -> Hindi
- Large model for when abundant parallel sentence pairs are available, eg English -> German
Then, we train the model. The specifics could be described in a future blog post, but suffice to say we spin up lots of high-performance compute nodes, train the model with the generated training data from the Data Preparation section, and benchmark the model’s performance using test sets prepared by organizations like [WMT](https://www.statmt.org/wmt21/translation-task.html), [TED](https://wit3.fbk.eu/), and academic groups like [LTI](https://pmichel31415.github.io/mtnt/index.html).
To score the models, we use automatic metrics like the [BLEU](https://en.wikipedia.org/wiki/BLEU) score, which answers questions like “How do I objectively evaluate what is a\* good\* English to French model?”.
Having passed muster, we ship the model to our production servers, and our translators can start using it right away!
## Training Data
LILT uses parallel corpora for training the Machine Translation model. Here, we define parallel corpora as text data which contain source sentences in one language and their corresponding translations in another language.
The data used for MT model training and customer data adaptation can be categorized into two types:
1. Background data: This is a parallel corpus constructed from various publicly available resources (Eg WMT \[1], OPUS \[2]), where the licensing \[3] supports the data being used for commercial purposes (Eg. CC BY, CC BY-SA, CC BY-ND). This data is used to train the baseline Machine Translation models, which are made available to all LILT customers.
2. Customer data: This is a parallel corpus constructed from customer data, either uploaded to LILT memories as TMX files or verified within the LILT platform by a linguist during the translation and review processes. This data is used to update only the customer specific adapter parameters. These adapter parameters are plugged into the background Machine Translation model before running translations on customer data. These adapter parameters are only local to the customer memories which supply the data to train them.
## Model Architecture
The transformer \[4] architecture is used for the Machine Translation models. Since this is a neural network \[5] style model, it will not store any text data it will be exposed to during background model training or customer data adaptation. The data will be used solely to update the weights of the background model (1.2B parameters) and the customer data adapters (140M parameters).
## Customer Data
Customer data is currently only stored in the Database within the LILT platform. This data is made visible to the Machine Translation adaptation process when necessary, but is not stored within the background model or the customer data adapters as demonstrated in Fig 1.
![]()
### References
\[1] [https://www2.statmt.org/wmt25/mtdata/](https://www2.statmt.org/wmt25/mtdata/)
\[2] [https://opus.nlpl.eu/](https://opus.nlpl.eu/)
\[3] [https://creativecommons.org/share-your-work/cclicenses/](https://creativecommons.org/share-your-work/cclicenses/)
\[4] [https://arxiv.org/abs/1706.03762](https://arxiv.org/abs/1706.03762)
\[5] [https://news.mit.edu/2017/explained-neural-networks-deep-learning-0414](https://news.mit.edu/2017/explained-neural-networks-deep-learning-0414)
# Magento
Source: https://support.lilt.com/kb/magento
The LILT Connector for Magento can help you expand your store accessibility to international markets by bridging language barriers with LILT’s translation services.
* Translate all of your site’s content, including product descriptions, checkout pages, and customer service messages.
* Choose from 60+ languages to cater to your target audience’s needs.
* Preview translations for accuracy and brand suitability before publishing.
## Getting started
1. Sign in to your Magento account.
2. Go to the Magento [marketplace](https://commercemarketplace.adobe.com/) and search for "[LILT Connector.](https://commercemarketplace.adobe.com/lilt-magento2-module.html)"
3. Install the app and follow the on-screen instructions to set it up.
4. When the app is installed, you’ll need to provide a LILT Token to complete the connection.
![]()
5. Contact us through [this link](https://resources.lilt.com/contact-us) and tell us “I need a LILT token for the Magento app”.
6. Our team will reach out to help with everything needed to start translating your Magento store, including brand-alignment documentation and customized configuration for your LILT Connector.
## How to send content for translation
1. Select the pages or content you want to translate.
2. Choose between *Instant translation*\*\* **(machine translation with Contextual AI)**\* \***or *Verified translation*** \*\*(which includes a quality guarantee).
![]()
3. Choose the target language(s) for your website translation.
4. Click `Translate`.
It's that simple! When your translations are complete, you can import, preview and publish translated content, all within the Magento app.\
It's that simple! When your translations are complete, you can import, preview and publish translated content, all within the Magento app.\\
## Magento2 \<> LILT Plugin
### Overview
The Megento2 \<> LILT plugin allows you to do the following without leaving Magento2:
* Easily send products to LILT for translation
* Track the status of your translations
* Publish orders
### General Workflow
1. Create a new order from the LILT plugin
2. Select Products
3. Choose target locales & the desired workflow
4. Send for translation
5. Publish translations
### Create a new order from the LILT Plugin
1. Open the Orders section of the LILT plugin.
2. Click **Translate** to create a new order.
💡Each order needs to have one product, one target locale at a minimum, and a **translation workflow.**
Orders are often used for large projects like, “I want to translate all of my blogs to Korean." So orders are generally translated, reviewed and published in batches.
3. Give the Order a name and select resources.
### Select Products
1. Give the Order a name and select resources.
### **Choose target locales & the desired workflow**
1. The **Source site** should be the default language for your source text. In most cases you’re translating *from* an English **source site** *to* a Non-English **target site** (e.g. English → German) so you won’t need to change this.
2. Choose one or more **Target sites.**
💡The list of **Target sites** come from the LILT API configuration, not from the LILT Plugin. If you’d like to add new Target sites, contact LILT.
3. Choose a translation workflow.
💡There are 2 workflows: Instant and Verified\
\
**Instant:** Provides fast *machine translation* of your source site. This can be used for situations where you need to get a lot of pages translated quickly.\
\
**Verified:** Uses LILT’s team of linguists to provide a high-quality translation of your source site. This can be used as a follow up to machine translation, or for situations where you want a high quality translation from the beginning.
### Send for Translation
1. When you’re ready to send content to LILT for translation, click the **Submit for translation** button.
2. The **Order status** will update to **In progress** and each entry on the **Translations** tab will have an **Sent** status as well.
3. As soon as the order is **Sent or In Progress**, no further action is needed.
### Publish Translations
1. When all of the translations are reviewed, you’ll receive a notification that the review is complete, and the order status will automatically change to **Delivered.**
2. To publish the order, click the **Import** button.
3. When the translations are published, you’ll receive a **Order Imported** notification.
# Scheduling Maintenance-Window Banners
Source: https://support.lilt.com/kb/maintenance-windows
## Overview
Display a platform-wide banner to notify users of an upcoming or in-progress maintenance window. The banner appears on every page of the Lilt UI while the current time is within the window, and disappears automatically when the window ends.
For self-managed installations, banners are scheduled and cancelled with the `admin-cli` tool. (Lilt SaaS uses Retool against the same underlying `WebsiteBanners` table.)
## Required Tools
You will need to use SSH to connect to the systems.
* On the Mac or Linux, you can open a terminal window and use ssh.
* On Windows, you can use the PuTTY ssh client.
### Installer Privileges
Users need to have access to the kubernetes cluster that hosts the application.
## Schedule a maintenance-window banner
#### Connect to the front pods
`$ kubectl exec -it -c front -- /bin/bash`
Steps to fetch \:
* connect to the kubernetes cluster
* fetch \ by running:
* `kubectl get pods -n lilt | grep -i front`
#### Create the banner
**Times must be ISO 8601 with explicit UTC** (`Z` or `+00:00`). Local times are rejected to prevent banners from showing at the wrong time.
`$ npm run dist-admin-cli -- create-maintenance-window --start "" --end "" --message ""`
Example:
```bash theme={null}
$ npm run dist-admin-cli -- create-maintenance-window \
--start "2026-06-01T03:00:00Z" \
--end "2026-06-01T05:00:00Z" \
--message "Scheduled maintenance: Lilt will be unavailable for approximately 2 hours."
```
The command prints the new banner's `id`:
```
Maintenance window created (id=42).
Starts: 2026-06-01T03:00:00Z
Ends: 2026-06-01T05:00:00Z
Message: Scheduled maintenance: Lilt will be unavailable for approximately 2 hours.
```
Record the `id` from the output. You will need it to cancel the banner before its scheduled end time.
## Cancel a scheduled banner
#### Connect to the front pods
`$ kubectl exec -it -c front -- /bin/bash`
#### Delete by id
`$ npm run dist-admin-cli -- delete-maintenance-window --id `
Example:
```bash theme={null}
$ npm run dist-admin-cli -- delete-maintenance-window --id 42
Deleted maintenance window id=42.
```
#### Delete every currently-active banner (when the id is unknown)
`$ npm run dist-admin-cli -- delete-maintenance-window --all-active`
Example:
```bash theme={null}
$ npm run dist-admin-cli -- delete-maintenance-window --all-active
Deleted 1 currently-active maintenance window(s).
```
This only affects banners whose window includes the current time. Past banners are left as historical records; future banners (not yet started) are also untouched.
## Notes
* Banners are **soft-deleted** — the row remains in the `WebsiteBanners` table with `isDeleted = true` for audit purposes.
* Past banners (whose `endDate` has passed) disappear from the UI automatically; there is no need to delete them.
* Banner display is identical to Lilt SaaS — the UI reads the same `/website-banners` endpoint.
# Manage Memory and Termbase
Source: https://support.lilt.com/kb/manage-memory-and-termbase
## Create new model and add custom assets (Translation memory & Termbase)
* Go to `Contextual AI > Models`
![]()
* Click on `New model` and enter `Source language`, `Target language` and `Reference data source`
![]()
If a default model doesn't exist for that language pair, it will also be created
![]()
* To view the model entries, click on `Show source`
![]()
* Use `Upload files` option to import the `Memory(TM)` and `Termbase(TB)` entries
![]()
For larger datasets, upload the Memory file in TMX or TMX.zip format, and the Termbase in any of the following formats: TBX, TSV, CSV, XLSX, TMG. The file size limit is 200MB.
* Use `Manage entries` to manage Memory and Termbase
![]()
* (Optional) Change model `settings` and set `Reviewed` by default
![]()
* Create a New entry to do the following
* Create entry to train the memory. To do this, add a `Memory` type entry
![]()
* Create a `Termbase` entry to overwrite the memory without training it. This is same as glossary or dictionary items
![]()
* Added `Termbase` entry will be highlighted during the translation
![]()
# Manage Terminology with Assist
Source: https://support.lilt.com/kb/manage-terminology-with-assist
LILT Assist enables you to extract, organize, and maintain your brand’s technical terms and proprietary language through a conversational interface. By managing your terminology at the source, Assist ensures that your custom AI models and human reviewers remain consistent across every project and locale.
### Key Features
* **Automated Term Extraction:** Scan documents, websites, or technical manuals to instantly identify high-frequency terms and industry-specific shorthand.
* **Multilingual Glossary Building:** Generate term translations across multiple target languages simultaneously to build a unified global reference.
* **Interactive Review & Edit:** Refine extracted terms directly within the chat. Add definitions, approve suggested translations, or remove irrelevant entries.
* **Data Source Integration:** Automatically upload finalized termbases to your LILT Data Sources to enforce consistency in future translation and creation workflows.
* **Consistency Enforcement:** Ensure that your company’s specifically trained models always use your preferred brand language, reducing the need for manual corrections later.
### How to Use
1. To get started, use a prompt (e.g., *"I want to build a glossary"*) or click the Generate termbase card.
2. Tell the agent what content to analyze:
* Click + to upload files (see [supported file formats](https://support.lilt.com/kb/supported-file-formats#supported-file-formats)).
* Provide a link to a website or documentation page for the agent to crawl.
3. Identify which languages need translations (e.g., *“English to Spanish and Chinese”*).
4. Review the Agent’s proposed plan and confirm to begin.
5. Assist will present a list of identified terms and proposed translations. Review these directly in the chat interface.
6. Ask for changes to specific terms (e.g., *“Change the translation for 'Cloud Storage' to 'Almacenamiento en la nube'”*) or provide definitions for clarity.
7. Once satisfied, ask the agent to upload the glossary to your project’s Data Source for immediate use.
### Best Practices for Terminology Prompts
To build a precise and useful termbase, be clear and direct about the scope of the extraction. Avoid vague requests; instead, define the specific material and the intended outcome. Use these details to build a strong prompt:
* **Action:** What should the agent do? (*Extract, translate, update, check*)
* **Object:** What is the source material? (*PDF, URL, existing list*)
* **Parameters:** Which languages and how many terms? (*"Top 20 terms," "English to French"*)
### Quick-Start Prompts
**Extraction and Creation**
* *Analyze my product documentation to extract the top 25 technical terms and create a glossary in English, Spanish, and Chinese.*
* *Extract all product names and proprietary terms from this marketing whitepaper in German.*
* *Review this URL and identify all frequent technical terms to start a new termbase for our API documentation*
**Updating and Managing**
* *Add the term 'Scalable Architecture' to our existing Spanish glossary with the definition 'Arquitectura escalable'.*
* *This glossary looks good; please upload it to our 'Enterprise' data source for all future projects.*
### Sample Agent Interactions
```text theme={null}
User: "I want to create a glossary of technical terms for my software company"
Assist: "A glossary will help maintain consistency across all your translations. I can help you:
- Extract terms from your existing documents
- Create a structured glossary
- Translate terms to your target languages
What languages do you need, and do you have some sample documents I can analyze?"
User: "We need English, Spanish, and Chinese. I have some product documentation I can upload."
Assist: "I'll analyze your documentation to extract key technical terms and create a comprehensive glossary..."
```
# Managing Data Sources and Memory Entries
Source: https://support.lilt.com/kb/managing-your-lilt-memories
In LILT, all translation data is organized into Data Sources. Each Data Source is designated by a language pair and aggregates the following linguistic assets:
* [Translation Memory](/kb/translation-memory-matching) (one or many): A collection of source/target TM entries (previously translated segments).
* [Termbase](/kb/managing-termbase-and-translation-memory-entries) (zero or many): A collection of source/target TB entries (Termbase terms that help to maintain consistent terminology usage).
* [Contextual AI](/kb/lilt-translate-engine): A self-learning neural translation system.
*Note that there can be more than one Data Source for a given language pair.*
Each Project in LILT is associated with one Data Source, and only uses the resources from that Data Source. Multiple Projects can share the same Data Source.
## Managing your Data Sources
Managing your Data Sources is an important part of localization. To get started, navigate to the `Data > Sources` tab.
![Screenshot2026 01 06at11 48 30]()
Data Sources are grouped into sections based on language pairs. Use the search bar to filter Data Sources by language code or name.
![]()
Each Data Source is displayed as a card with the following information:
* Data Source name
* Data Source languages
* Date the Data Source was last updated. *Note: This date reflects the last time an action was taken against the data source directly (e.g. adding a TMX file) and does not represent the last time a segment was added.*
## Create a Data Source
Data Sources can be created at any time. Click the `New data source` button in the upper-right. This will open a popup box with the following fields to fill out in order to create your new Data Source:
* **Name:** The name of the Data Source.
* **Source language:** The source language of the Data Source.
* **Target language:** The target language of the Data Source.
* **In-context learning:** Whether to enable LILT's [Contextual AI](/kb/what-is-interactive-adaptive-mt) for translation suggestions.
* **Force TB case-sensitivity:** Whether to enforce term matches to respect case-sensitivity.
![Screenshot2026 01 06at11 50 07]()
After filling in the fields, click the `Create` button to create the Data Source. Once created, you can [Upload Memory Files](/kb/uploading-memory-files) to it, and you can make use of the Data Source in your Projects.
### Default Data Sources
Whenever a Model is created that uses a new language pair, LILT also creates a Default Data Source for that language pair. Default Data Sources are distinguished by the `Default` text next to the name.
![]()
Each language pair must have exactly one Default Data Source. The Data Source set as the default cannot be deleted. However, administrators and managers can change the Default Data Source for a language pair by clicking the dropdown and selecting the option to `Set as default data source`.
![]()
## Delete a Data Source
Clicking the `Delete`button in the dropdown and confirm that you want to permanently delete the Data Source.
![]()
## Edit a Data Source
Updating a Data Source will affect all Projects using that Data Source (with no latency). Your translators are guaranteed to always be working with the most up-to-date version of the Data Source.
Click on the Data Source name or the `Edit` button to open up the Data Source, where you can edit all the entries and settings of the selected Data Source.
From the Data Source detail page, you can access all the [Data Source Settings](/kb/memory-settings) and manage the contents of the selected Data Source.
![]()
## Managing Termbase and Translation Memory Entries
Managing your Termbase (TB) and Translation Memory (TM) entries in Data Sources is an important part of localization. LILT provides tools for adding and editing entries directly within the application.
TB/TM entries can be added to a Data Source in several ways:
* [Uploading TMX (Memory) Files](/kb/uploading-memory-files) directly to the Data Source.
* Manually adding individual entries on the Data Source's `Manage entries` page.
* From inside [LILT Translate](/kb/introduction-to-lilt-translate):
* TM entries are added when a segment is confirmed.
* TB entries can be added manually in the [Segment Context](/kb/segment-context) sidebar.
### Manage resources
The `Manage resources` page on the left sidebar lets you [Upload TB/TM Files](/kb/uploading-memory-files) to the selected Data Source.
* Uploaded TM file entries are used in [TM Matching](/kb/translation-memory-matching) to train the Data Source's [Model](/kb/machine-translation).
* Uploaded TB file entries provide Termbase references within [LILT Translate](/kb/introduction-to-lilt-translate).
Files supported include:
* Data Source (TM)
* Data source (TM, concordance only)
* Termbase (TB)
* Termbase (TB, with header)
### Manage entries
To edit existing TM/TB entries in a Data Source, navigate to the `Manage entries` page on the tabs at the top of the page.
Under Manage Entries, you will be able to:
* Make changes to your source and target text
* See the State of your review
* Edit the entry
* View the metadata
* Delete the source/target pair
### Editing an Entry
![]()
* **Source Text:** Source text cannot be changed once set. Note that term matching is case-sensitive. If you need to change the source text of an entry, you can delete it and create a new entry.
* **Target Text:** Use this field to make changes to the translation text.
* **State:** This is a legacy field used to show the approval status of the entry (Reviewed, Draft and Unreviewed). An entry's State does not impact TM leveraging or model training.
* **Custom Fields:** Adding a custom field will add the custom field to all entries within the Data Source. Custom fields can hold metadata to provide context to linguists about a given translation. Linguists can view metadata directly in LILT Translate from the [Segment Context Menu](/kb/segment-context). Note that custom fields can also be created from the [Data Source Settings](/kb/memory-settings) page, and can only be deleted from the `Settings` page.
### Delete one or more entries
To delete entries, select one or more checkboxes on the left-hand side of the table. A bar will appear at the bottom of the page to "Delete selected" entries. Confirm that you want to delete the entries.
![Screenshot2026 01 06at11 58 38]()
Alternatively, you can use the top-most checkbox to select all entries on the page (up to 100). Scrolling down the page will load the next 100. If you leave the top-most checkbox selected, scrolling down will include those in the selected entries.
### Settings
Under Settings, you will be able to edit the Data source name, entry statuses, and more custom properties.
* Note: To select the default status, you will need to select the status chip until it turns green. Once green, it will be the default one used on import. Please see video below for example.
## Download Data Source Entries
While Data Sources cannot be downloaded in full, the translation memory and termbase entries can be downloaded separately.
To download all entries in a Data Source, click the `Download`button in the top right corner, then select from the modal which items you’d like to download and in what format.
![]()
To download only specific TM entries or TB entries, open the `Manage entries`page, select the desired entries, and then clicking the `TM entries` or `TB entries` button.
![]()
# Mandatory Batch QA
Source: https://support.lilt.com/kb/mandatory-batch-qa-check
[Batch QA](https://support.lilt.com/kb/quality-assurance-tools#batch-qa) checks the entirety of a translated document for errors. Administrators can force a Quality Assurance Tools check to be run before any document is marked as completed by a translator or reviewer. Enabling Mandatory Batch QA helps catch issues earlier and helps reveal issues that might have otherwise slipped through unnoticed.
## Mandatory Batch QA
When Mandatory Batch QA is enabled and a linguist goes to mark a document for completion, they will be prompted to first run a Batch QA check on the document. All QA errors will need to be Accepted or Ignored in order to mark the document as done.
Administrators can enable mandatory Batch QA by following these steps:
1. Open the `Settings` page and navigate to the LILT Translate settings.
2. Select which workflow stages you would like to make Batch QA Mandatory and Automatic.
![Screenshot2025 10 23at14 14 05 Pn]()
![]()
# Data Source Settings
Source: https://support.lilt.com/kb/memory-settings
The `Settings` page provides you with the tools to streamline the process of managing your Data Source.
## General settings
![Image]()
Note: All changes under `Settings` are only applied if you click the `Save settings` button at the bottom of the `Settings` section.
**Data source name:** This field lets you change the name of the Data Source.
**Default termbase entry status:** Select the default status for new Termbase entries. By default, this option is set to `Reviewed`. Only entries that are `Reviewed` are shown to translators in LILT Translate.
* **Draft:** Entries are not used in translation and not shown to translators.
* **Reviewed (default option):** Entries are used in translation and shown to translators.
* **Unreviewed:** Entries are not used in translation and not shown to translators.
When an entry in the `Draft` state or `Unreviewed` state is reviewed, it automatically moves to the `Reviewed` state. Terms are only visible under the `Segment Context` tab of LILT Translate if they are in the `Reviewed` state.
**In-context learning:** This option allows you to enable or disable in-context learning. For more information, see the [What is Contextual AI?](/kb/what-is-interactive-adaptive-mt) article.
**Case-sensitive matching:** This option allows you to enable or disable case-sensitivity when matching TB entries. For more information, see the [Terminology](/kb/terminology) article.
**Custom properties:**
![]()
The `Custom properties` section allows you to add custom metadata fields to all your TM and TB entries within the Data Source. Custom fields allow you to add metadata about translations that provide context to translators about the translation. Once a custom field is created, you can change the `Field Name` and whether it is a `Required field`, but you cannot change the field type. Clicking on the trash can icon will immediately remove the custom field and permanently delete the field from all TM and TB entries in the Data Source. You can also set a default value for the picklist custom property. If you add a custom property to the data source and the data source was already attached to existing projects, the picklist values and attributes will remain as they are for the existing projects. If you click on Propagate and save, then that custom property and picklist value will get added to new projects.
Custom properties are only applied if you click the `Save` button at the bottom of the `Settings` section. So if you accidentally delete a custom field, simply leave the page without clicking the `Save` button and your custom fields will remain intact.
Deleting a custom property from the data source: If you delete a custom property from the data source, it will no longer be in any project (regardless of if it was propagated or not).
## Reset MT
If in-context learning is turned on, LILT’s translation models learn every time a user confirms a segment during translation. If for some reason the translation recommendations aren’t quite what you are looking for, clicking the `Reset` button will reset the model to a clean state. Resetting the MT does not affect the Termbase or memory entries in the Data Source.
![]()
## Purge data source & termbase
To remove all data source entries, all Termbase entries, and all resources from a Data Source, click the `Purge Data Source` button. This will bring up a popup to confirm you want to permanently delete these assets.
![]()
# Data Source/Terminology Management
Source: https://support.lilt.com/kb/memory-terminology-management
## Introduction
This document details the best practices for Data Sources and terminology, including suggestions for organization and practices to avoid.
## Data Source Management
### Data Source Organization Best Practices
* When creating Data Sources, default toward combining Data Sources to focus on a smaller number of Data Sources. Splitting Data Sources too aggressively can reduce the benefit of adaptation.
* Style impacts translation quality. Prefer to split TMs on the style anticipated by the audience, as mixing styles of writing or registers, e.g. academic journals vs. social media content/text messages may result in translation “unfit” for the task.
* Including multiple types of content in one Data Source may improve the translation results across each type of content. It can often be better to combine content into a smaller number of Data Sources.
### Separating Data Sources
There are reasons you may want to separate Data Sources:
* \*\*Different Topics or Content Domains: \*\*Data Sources containing completely unrelated content domains may result in conflicting machine translation suggestions
* **Access control**: Some Data Sources may contain information only accessible to certain groups or roles and can not be shared with other audiences.
* **Confidential Project Information:** Where content is sensitive and should not be freely accessible to users on other projects
## Terminology Management
Terminology management is a core part of the overall quality management process for translation. Terminology management is often a complex decision-making process involving many stakeholders in an organization.
For example:
* When dealing with terminology in public-facing materials (such as a website), the marketing, public relations, and/or branding department may need to get involved.
* When dealing with terminology in a product, a product team and technical writing team would make the final decision.
### Creating Terminology
When team members suggest a termbase (TB) entry, the term does not immediately appear in [LILT Translate](/kb/introduction-to-lilt-translate) for translators. The term must be accepted by a reviewer for it to show up as a TB suggestion. Once accepted, the TB entry will be highlighted within any document in a project sharing the same Data Source. Below are common best practices and things to avoid when submitting terminology:
#### Best practices:
* Check with your LILT services team to understand requirements before adding terms (some programs have external terminology systems).
* Use the `Segment context` sidebar to make sure the associated Data Source doesn't already contain the term you want to add in the same form (singular, plural, lowercase, capitalized, or as part of combined words). If the term should be matched in multiple forms (ex. singular and plural), you will need to have multiple entries.
* Perform a quick search to ensure the translation you want to add is widely accepted in the locale.
* Check a trustworthy dictionary for your language (i.e. Oxford Dictionary for English) to make sure your translation doesn’t conflict/contradict with the source term’s definition or connotation.
* Include appropriate metadata to each entry you add:
* Part of speech
* Context
* Source
#### Things to avoid:
When adding terms, be careful to avoid:
* Typos
* General terminology (a termbase is not a dictionary)
* Terms that appear infrequently in the document
* Terms you are unsure of and want someone else to confirm
* New translations for an existing term (unless you add metadata to indicate specific and distinct use)
Don't add terms that are:
* A number
* Context-sensitive
* More than four words
* Variants of existing terms:
* Differences in capitalization
* Inflected forms of a word
### Terminology Organization
Terms are created within a Data Source and are not recognized globally across multiple Data Sources. If you need terms in multiple Data Sources, the entries will need to be added to each of those Data Sources.
# Migrate Database (MySQL to RDS)
Source: https://support.lilt.com/kb/migrate-database-mysql-to-rds
## Overview
This article walks the installer through migrating the LILT application database from an in-cluster MySQL deployment to an Amazon RDS for MySQL instance. It applies when moving an existing self-managed installation onto a fully managed cluster, such as the environment described in [Install System (AWS EKS)](/kb/install-system-aws-eks), where RDS replaces the in-cluster database.
The database is exported through a proxied connection to a staging host and restored into RDS from there. Nothing is written inside the database pod at any point, so the procedure works even when the existing storage volume has no free space for a dump file. The export stage is read-only against the source cluster, leaving the original environment available as a fallback until the migration is accepted.
Object storage migration is a separate procedure; see [Migrate Object Storage (MinIO to S3)](/kb/migrate-object-storage-minio-to-s3).
## Tools you will need
* AWS user with permissions to describe the RDS instance, modify its parameter group, and create snapshots.
* Required utilities for the staging host:
* AWS CLI
* `kubectl`, with access to the source cluster
* MySQL client tools matching the source server version
* A staging host with:
* Network access to the RDS endpoint, or the ability to transfer the dump file to a host that has it
* Free disk space for the compressed dump
## Structure of this Article
The first section explains where the database migration belongs in the overall install sequence, because restoring at the wrong point produces a schema that cannot be repaired automatically.
The remaining sections cover assessing the source database, preparing the RDS instance, exporting and restoring the data, reconciling the schema migration metadata, applying pending schema migrations, rebuilding the search index, and verifying the result.
### Installer privileges
All commands are run from a staging host by a user with the permissions stated in the “Tools” section above. Commands that target the source cluster assume the LILT namespace is `lilt` and the database pod is `mysql-0`; adjust if your installation differs.
## Migration Order
### Restore before installing LILT
The application's schema migrations are the mechanism that brings an older database up to the current schema. They must run against the restored data, which means the restore has to complete before LILT is installed on the new cluster.
Installing first and restoring afterwards does not work, and fails in a way that is difficult to detect. On an empty database the installer applies every migration and produces a complete current-version schema. Restoring an older dump on top of that does not reset it: a dump drops and recreates only the tables it contains, so every table introduced after the dump was taken survives untouched, while the migration metadata table is replaced wholesale with the older list. The result is a mixture of old and new tables whose metadata claims the newer migrations never ran. Nothing reports an error at that point; the inconsistency surfaces later as failures during a subsequent upgrade.
The correct sequence is:
1. Provision the RDS instance and prepare the parameter group
2. Create the application database user and grants
3. Restore the dump
4. Reconcile the schema migration metadata
5. Take an RDS snapshot
6. Install LILT, which applies the pending schema migrations
7. Reset the search index cursor and restart the indexer
8. Verify, then return the environment to service
### Migrate first, upgrade separately
If the new environment also runs a newer LILT release than the source, treat the storage move and the version upgrade as two operations. Restore the data and confirm it is intact at the original version first, then perform the version upgrade against RDS. Combined, a failure partway through several hundred schema migrations cannot be attributed to either cause.
## Assess the Source Database
#### Set the user environment variables
```bash theme={null}
export SOURCE_DB="lilt_dev"
export STAGE_DIR="/export"
```
`lilt_dev` is the default application database name. Confirm it against your installation:
```bash theme={null}
kubectl get configmap -n lilt lilt-configmap -o yaml | grep -i dbname
```
#### Read the database credentials
```bash theme={null}
export SRC_PASS=$(kubectl -n lilt get secret mysql-svcbind-root \
-o jsonpath='{.data.password}' 2>/dev/null | base64 -d)
```
If that secret does not exist in an older installation, use the root password configured for the database chart.
#### Record the server configuration
These values determine the export options and the RDS parameter group. Record all of them before continuing:
```bash theme={null}
kubectl -n lilt exec -i mysql-0 -- mysql -uroot -p"$SRC_PASS" -N -e "
SELECT @@VERSION, @@GLOBAL.GTID_MODE, @@GLOBAL.ENFORCE_GTID_CONSISTENCY,
@@GLOBAL.max_allowed_packet, @@GLOBAL.character_set_server,
@@GLOBAL.collation_server;"
```
Record the database-level character set and collation separately. These must be reproduced on RDS:
```bash theme={null}
kubectl -n lilt exec -i mysql-0 -- mysql -uroot -p"$SRC_PASS" -N -e "
SELECT default_character_set_name, default_collation_name
FROM information_schema.schemata WHERE schema_name='$SOURCE_DB';"
```
#### Measure the database
This sizes the disk requirement on the staging host. A logical dump is smaller than the reported total because it contains no index data, and compresses further:
```bash theme={null}
kubectl -n lilt exec -i mysql-0 -- mysql -uroot -p"$SRC_PASS" -N -e "
SELECT ROUND(SUM(data_length+index_length)/1024/1024/1024,2) AS gb, COUNT(*) AS tables
FROM information_schema.tables WHERE table_schema='$SOURCE_DB';"
kubectl -n lilt exec mysql-0 -- df -h /var/lib/mysql
```
#### Reclaim space on the storage volume
When binary logging is enabled, the log files are written into the data directory and can occupy a significant share of a small volume. Reclaiming that space reduces the risk of the volume filling during the export:
```bash theme={null}
kubectl -n lilt exec -i mysql-0 -- mysql -uroot -p"$SRC_PASS" -e "SHOW BINARY LOGS;"
kubectl -n lilt exec -i mysql-0 -- mysql -uroot -p"$SRC_PASS" -e \
"PURGE BINARY LOGS BEFORE NOW() - INTERVAL 1 HOUR;"
```
## Prepare the RDS Instance
#### Engine version
Create the instance with an engine version matching the source server recorded above. Restoring a dump taken from a newer server into an older engine version can fail on syntax or features the older version does not support.
#### Parameter group
Set the following in the instance's parameter group:
```text theme={null}
log_bin_trust_function_creators = 1
max_allowed_packet =
```
`log_bin_trust_function_creators` is required because the restoring user does not hold the `SUPER` privilege on RDS, and stored routines or triggers in the dump fail without it.
If the application's database client cannot negotiate the `caching_sha2_password` authentication plugin, also enable `mysql_native_password` in the parameter group. Recent MySQL versions disable that plugin by default, and the failure only appears when the application connects — testing as the administrative user succeeds regardless.
#### Correct the database character set and collation
This step is required when the database was created for you, either by the instance's initial database name setting or by an infrastructure-as-code definition.
A dump taken with the `--databases` option includes a `CREATE DATABASE ... IF NOT EXISTS` statement carrying the source character set and collation. When the database already exists, that statement does nothing and its collation clause is ignored, leaving the database on the engine's default collation instead of the source's.
The restored tables are unaffected, because every `CREATE TABLE` statement in the dump carries its own character set and collation. The problem appears later: tables created by subsequent schema migrations without an explicit collation inherit the database default, and queries joining them against restored tables fail with `Illegal mix of collations`. That surfaces days afterwards as intermittent errors rather than as a restore failure.
Create a credentials file for the administrative user and correct the collation to match the source:
```bash theme={null}
export RDS_ENDPOINT="example-instance.abcdefghijkl.us-east-1.rds.amazonaws.com"
umask 077
cat > /tmp/rds-admin.cnf <
password=
ssl-mode=REQUIRED
EOF
mysql --defaults-extra-file=/tmp/rds-admin.cnf -e \
"ALTER DATABASE \`$SOURCE_DB\` CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql --defaults-extra-file=/tmp/rds-admin.cnf -e "
SELECT default_character_set_name, default_collation_name
FROM information_schema.schemata WHERE schema_name='$SOURCE_DB';"
```
Substitute the character set and collation recorded from the source. `ALTER DATABASE` changes only the default applied to newly created objects; it does not rewrite existing data.
#### Create the application database user
User accounts and grants are not carried by the dump and must be created directly. Skip this step if your infrastructure definition already provisions the user:
```bash theme={null}
mysql --defaults-extra-file=/tmp/rds-admin.cnf <<'SQL'
CREATE USER IF NOT EXISTS 'lilt'@'%' IDENTIFIED WITH mysql_native_password BY '';
ALTER USER 'lilt'@'%' IDENTIFIED WITH mysql_native_password BY '';
GRANT ALL PRIVILEGES ON `lilt_dev`.* TO 'lilt'@'%';
FLUSH PRIVILEGES;
SQL
```
A database-level grant is valid even before the database exists, and the `CREATE` privilege it includes is what allows the dump to create the database if it is not already present.
Do not run any database bootstrap or schema initialization job at this stage. Creating the database and user is required; applying schema migrations before the restore produces the inconsistent schema described in “Migration Order”.
## Export the Database
#### Stop application writes
A dump is only consistent if nothing is writing to the database. This also protects the storage volume: a consistent dump requires the server to retain previous row versions for the duration of the export, and on a volume with little free space a long export against a live database can exhaust it.
Record the current replica counts first, so the environment can be restored if the migration is abandoned:
```bash theme={null}
kubectl -n lilt get deploy,statefulset \
-o custom-columns='KIND:.kind,NAME:.metadata.name,REPLICAS:.spec.replicas' \
--no-headers > /tmp/replicas-before.txt
```
Scale down the application, excluding the data services:
```bash theme={null}
DATA_SVCS='mysql|mongodb|rabbitmq|clickhouse|elasticsearch|redis|dragonfly|qdrant|minio'
kubectl -n lilt get deploy -o name \
| grep -vE "$DATA_SVCS" \
| xargs -r -I{} kubectl -n lilt scale {} --replicas=0
kubectl -n lilt get rollout -o name 2>/dev/null | xargs -r -I{} \
kubectl -n lilt patch {} --type=merge -p '{"spec":{"replicas":0}}'
kubectl -n lilt get cronjob -o name 2>/dev/null | xargs -r -I{} \
kubectl -n lilt patch {} --type=merge -p '{"spec":{"suspend":true}}'
kubectl -n lilt get cronworkflow -o name 2>/dev/null | xargs -r -I{} \
kubectl -n lilt patch {} --type=merge -p '{"spec":{"suspend":true}}'
```
Do not scale down every deployment in the namespace with a single command. Doing so stops the database, which the export reads from, and discards the replica counts needed to restore the environment.
#### Open a connection to the database
Forward the database service port to the staging host. Port `13306` is used locally to avoid conflicting with any MySQL instance already running there:
```bash theme={null}
kubectl -n lilt port-forward svc/mysql 13306:3306 &
PF_PID=$!
sleep 2
mysql -h 127.0.0.1 -P 13306 -u root -p"$SRC_PASS" -N -e "SELECT 'connection ok', @@VERSION;"
```
Write the credentials to a protected file rather than passing them on the command line, so the password does not appear in the process list:
```bash theme={null}
umask 077
cat > /tmp/src.cnf <
ssl-mode=REQUIRED
```
Certificate validation fails even with a valid certificate when connecting through a forwarded port, because the certificate is issued for the in-cluster service name and does not match `127.0.0.1`. Use `ssl-mode=VERIFY_CA` with `ssl-ca` pointing at the issuing authority if validation is required, and connect by a name the certificate covers rather than by address:
```text theme={null}
ssl-mode=VERIFY_CA
ssl-ca=/path/to/ca.pem
```
If the source server does not accept encrypted connections at all, set `ssl-mode=DISABLED` instead. Do not carry any of these settings over to the RDS credentials file: RDS requires encrypted connections and presents certificates from a public authority, so it keeps `ssl-mode=REQUIRED` as shown later in this article.
Port forwarding tunnels through the Kubernetes API server and can drop during a long transfer. If the connection proves unstable, capture the service definition, expose it as a NodePort for the duration of the migration, connect directly to a node, and restore the original definition afterwards:
```bash theme={null}
kubectl -n lilt get svc mysql -o yaml > /tmp/svc-mysql-before.yaml
kubectl -n lilt patch svc mysql -p \
'{"spec":{"type":"NodePort","ports":[{"name":"mysql","port":3306,"targetPort":"mysql","nodePort":32306}]}}'
# transfer, then restore
kubectl -n lilt apply -f /tmp/svc-mysql-before.yaml
```
#### Export to the staging host
The export runs on the staging host and writes only there. No dump file is created inside the database pod:
```bash theme={null}
mysqldump --defaults-extra-file=/tmp/src.cnf \
--databases $SOURCE_DB \
--single-transaction --routines --triggers --events \
--set-gtid-purged=OFF --no-tablespaces --hex-blob \
--default-character-set=utf8mb4 --max-allowed-packet=512M \
--compression-algorithms=zlib \
| sed -E 's/DEFINER=`[^`]+`@`[^`]+`//g' \
| gzip -1 > $STAGE_DIR/$SOURCE_DB.sql.gz
```
Each option addresses a specific requirement:
* `--defaults-extra-file` must be the first argument on the command line, or it is ignored without warning.
* `--set-gtid-purged=OFF` is required when the source has GTID mode enabled. Without it the dump contains a statement that sets a global GTID variable, which RDS rejects because the restoring user does not hold `SUPER`.
* `--no-tablespaces` avoids a statement requiring the `PROCESS` privilege, which the restoring user does not hold.
* `--single-transaction` produces a consistent snapshot without locking tables.
* `--databases` includes the `CREATE DATABASE` and `USE` statements, making the dump self-contained.
* The `sed` filter removes `DEFINER` clauses, which reference user accounts that do not exist on the new instance. Applying it in the same pipeline avoids writing the data to disk twice.
#### Validate the export
A truncated dump that appears to restore successfully is the worst outcome, so validate before restoring:
```bash theme={null}
gunzip -t $STAGE_DIR/$SOURCE_DB.sql.gz && echo "archive intact"
gunzip -c $STAGE_DIR/$SOURCE_DB.sql.gz | tail -5 | grep -c "Dump completed"
gunzip -c $STAGE_DIR/$SOURCE_DB.sql.gz | grep -c "GTID_PURGED"
gunzip -c $STAGE_DIR/$SOURCE_DB.sql.gz | grep -c "DEFINER="
ls -lh $STAGE_DIR/$SOURCE_DB.sql.gz
```
The first count must be `1` and the other two must be `0`. The `Dump completed` marker is written only when the export finishes cleanly, so its absence means the connection dropped partway and the export must be repeated.
#### Record the row-count baseline
Capture this while writes are still stopped. It is the reference for verification after the restore:
```bash theme={null}
mysql --defaults-extra-file=/tmp/src.cnf -N -e "
SELECT table_name, table_rows FROM information_schema.tables
WHERE table_schema='$SOURCE_DB' ORDER BY table_name;" | sort > $STAGE_DIR/src-rows.txt
wc -l $STAGE_DIR/src-rows.txt
```
#### Close the connection
```bash theme={null}
kill $PF_PID
```
## Restore into RDS
If the staging host cannot reach the RDS endpoint, transfer the dump to a host that can before continuing.
Create a credentials file for the application user and restore:
```bash theme={null}
umask 077
cat > /tmp/rds.cnf <
ssl-mode=REQUIRED
EOF
time gunzip -c $STAGE_DIR/$SOURCE_DB.sql.gz \
| mysql --defaults-extra-file=/tmp/rds.cnf --max-allowed-packet=512M \
2>&1 | tee /tmp/restore.log
```
RDS requires encrypted connections, hence `ssl-mode=REQUIRED`. Expect the restore to take considerably longer than the export, because it rebuilds every index.
If the restore fails partway, do not retry over the partial result. Recreate the database with the correct collation and start again:
```bash theme={null}
mysql --defaults-extra-file=/tmp/rds-admin.cnf -e "
DROP DATABASE IF EXISTS \`$SOURCE_DB\`;
CREATE DATABASE \`$SOURCE_DB\` CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
GRANT ALL PRIVILEGES ON \`$SOURCE_DB\`.* TO 'lilt'@'%';"
```
## Reconcile the Schema Migration Metadata
The application records each applied schema migration by filename in a metadata table named `SequelizeMeta`, and matches them by exact filename. Some migrations are authored with a `.ts` extension and shipped in the application image compiled to `.js`. If a database recorded them under their `.ts` names, the installed application sees those migrations as never applied, attempts to run them again, and fails on objects that already exist — typically reported as a duplicate key or duplicate column error.
Check whether the restored database is affected:
```bash theme={null}
mysql --defaults-extra-file=/tmp/rds.cnf -D $SOURCE_DB -e "
SELECT SUM(name LIKE '%.ts') AS ts, SUM(name LIKE '%.js') AS js, COUNT(*) AS total
FROM \`SequelizeMeta\`;"
```
If `ts` is `0`, no action is needed. Otherwise normalize the recorded names to the compiled extension. This affects only the metadata table — no schema and no application data are modified — and running it a second time has no effect:
```sql theme={null}
CREATE TABLE IF NOT EXISTS `SequelizeMeta_backup` AS SELECT * FROM `SequelizeMeta`;
START TRANSACTION;
DELETE t FROM `SequelizeMeta` t
JOIN `SequelizeMeta` j
ON j.name = CONCAT(SUBSTRING(t.name, 1, CHAR_LENGTH(t.name) - 3), '.js')
WHERE t.name LIKE '%.ts';
UPDATE `SequelizeMeta`
SET name = CONCAT(SUBSTRING(name, 1, CHAR_LENGTH(name) - 3), '.js')
WHERE name LIKE '%.ts';
SELECT SUM(name LIKE '%.ts') AS must_be_zero FROM `SequelizeMeta`;
COMMIT;
```
The `DELETE` handles the case where both extensions are recorded for the same migration, which would otherwise collide on the table's primary key during the rename.
## Take a Snapshot
Create a snapshot before any schema migration runs. This is the only inexpensive way to recover from a migration that applies partially:
```bash theme={null}
aws rds create-db-snapshot \
--db-instance-identifier \
--db-snapshot-identifier pre-migration-$(date +%Y%m%d%H%M)
```
## Apply Schema Migrations
Install LILT on the new cluster as described in [Install System (AWS EKS)](/kb/install-system-aws-eks), with the database connection pointing at the RDS endpoint. During installation the application applies every schema migration recorded as unapplied, bringing the restored database up to the current schema.
When migrating from an older release, expect a large number of migrations to run. This is normal and represents the accumulated schema changes between the two versions.
#### Confirm the migrations succeeded
Do not infer success from pod status. A migration failure does not necessarily cause the pod to report a failure, so the application can start against a partially migrated schema. Inspect the initialization container's logs directly:
```bash theme={null}
kubectl -n lilt get pods | grep front
kubectl -n lilt logs -c | grep -iE "error|failed|duplicate"
```
Confirm the metadata table grew as expected. Record the count before installation and compare it afterwards; the difference is the number of migrations applied:
```bash theme={null}
mysql --defaults-extra-file=/tmp/rds.cnf -D $SOURCE_DB -e "
SELECT COUNT(*) AS applied, SUM(name LIKE '%.ts') AS unreconciled
FROM \`SequelizeMeta\`;"
```
`unreconciled` must be `0`. If it is not, the reconcile step was skipped or new entries were recorded under the wrong extension, and the next upgrade will attempt to reapply them.
Installation is idempotent with respect to migrations: any that did not run are applied on the next install or upgrade. If the logs show a failure, resolve the cause and run the installer again rather than editing the metadata table by hand.
## Rebuild the Search Index
The search index on the new cluster is empty, and restored content is not indexed automatically. The indexer tracks its position in a table named `IndexerCursor`, which holds a timestamp; only records modified after that timestamp are indexed. The restored row carries the position reached on the original cluster, and every restored record predates it, so without this step search returns no results for migrated content.
Perform this after the schema migrations have completed. The cursor is read once when the indexer starts, so it must be paired with a restart.
`CURSOR` is a reserved word in MySQL and must be quoted with backticks:
```bash theme={null}
mysql --defaults-extra-file=/tmp/rds.cnf -D $SOURCE_DB -e \
"SELECT id, \`cursor\` FROM \`IndexerCursor\`;"
mysql --defaults-extra-file=/tmp/rds.cnf -D $SOURCE_DB -e \
"UPDATE \`IndexerCursor\` SET \`cursor\` = '1970-01-01 00:00:00' WHERE id = 1;"
mysql --defaults-extra-file=/tmp/rds.cnf -D $SOURCE_DB -e \
"SELECT id, \`cursor\` FROM \`IndexerCursor\`;"
```
Restart the indexer so it reads the new position:
```bash theme={null}
kubectl -n lilt rollout restart deploy/indexer-core
kubectl -n lilt logs deploy/indexer-core | grep -i "cursor"
```
The column is a `DATETIME`, so a date before 1970 is also accepted; the value above is simply a conventional starting point. The search indices themselves are created automatically when the indexer starts and require no manual step.
Monitor progress by watching the index document counts grow:
```bash theme={null}
kubectl -n lilt exec deploy/indexer-core -- \
curl -s 'http://elasticsearch.lilt.svc.cluster.local:9200/_cat/indices?v'
```
## Verify the Migration
#### Compare row counts
```bash theme={null}
mysql --defaults-extra-file=/tmp/rds.cnf -N -e "
SELECT table_name, table_rows FROM information_schema.tables
WHERE table_schema='$SOURCE_DB' ORDER BY table_name;" | sort > /tmp/dst-rows.txt
diff $STAGE_DIR/src-rows.txt /tmp/dst-rows.txt
```
Row counts reported by `information_schema` are estimates for InnoDB tables, so use this comparison to identify substantial differences and confirm those with a direct `COUNT(*)` on the largest tables. Counts will legitimately differ for tables that the schema migrations altered.
#### Confirm the character set and collation
```bash theme={null}
mysql --defaults-extra-file=/tmp/rds.cnf -e "
SELECT default_character_set_name, default_collation_name
FROM information_schema.schemata WHERE schema_name='$SOURCE_DB';"
```
#### Application checks
Perform these in order, because each one exercises a different part of the migration:
1. Sign in, which confirms the application can authenticate against the restored user records.
2. Confirm the jobs list is populated, which confirms general read access to restored data.
3. Open a previously existing document, which confirms the restored records resolve correctly.
4. Search for a phrase from restored content, which confirms the index was rebuilt.
5. Create a new job and run a translation, which confirms writes succeed against the new instance.
## Post-Migration Configuration
* **Connection settings.** The database host, port, user and password must point at the RDS endpoint. Confirm every location where the deployment configures them.
* **Application user.** Confirm the application authenticates as the dedicated database user rather than the instance's administrative user.
* **In-cluster database.** Once the migration is accepted, the in-cluster MySQL deployment is no longer used. Leave it in place until then, since it is the fallback.
* **Encrypted connections.** RDS requires TLS. Any component configured for an unencrypted in-cluster connection must be updated.
## Cleanup
Restore the application to its previous replica counts using the file recorded before the export, then remove the credentials files and the staged dump:
```bash theme={null}
rm -f /tmp/src.cnf /tmp/rds.cnf /tmp/rds-admin.cnf
rm -f $STAGE_DIR/$SOURCE_DB.sql.gz
```
Restore the database service definition if it was exposed as a NodePort. Retain the row-count baseline and the restore and migration logs as a record of the migration.
Keep the in-cluster database volume intact until the migration has been accepted. No step in the export modifies it, so the original environment remains a complete fallback.
## Debugging
**`Access denied` when the application connects, while administrative access works**: the application's client cannot negotiate the instance's default authentication plugin. Enable `mysql_native_password` in the parameter group and recreate the application user with that plugin.
**Restore fails on a stored routine or trigger**: `log_bin_trust_function_creators` is not set to `1` in the parameter group.
**Restore fails on a statement setting a global GTID variable**: the export was taken without `--set-gtid-purged=OFF`. Repeat the export with that option.
**`Illegal mix of collations` after an upgrade**: the database default collation does not match the restored tables, because the database was created before the restore and its collation was not corrected. Compare the database default against a restored table's collation and correct it, then recreate the affected tables.
**Duplicate key or duplicate column errors during schema migration**: migration metadata records entries under a different file extension than the installed image uses. See “Reconcile the Schema Migration Metadata”.
**Search returns no results for migrated content**: the index cursor was not reset, or the indexer was not restarted after resetting it.
**The export stops partway with a connection error**: the port-forward tunnel dropped. The dump cannot be resumed; repeat the export, and use the NodePort approach if the tunnel proves unreliable.
# Migrate Flannel To Calico
Source: https://support.lilt.com/kb/migrate-flannel-to-calico
Flannel is a general purpose container network interface (CNI) for Kubernetes clusters but offers limited integration for mTLS and container security. Calico has more robust capabilities and direct support for Istio service mesh, offering pod traffic controls, ingress traffic, and additional firewall rules.
Calico is compatible with a wide range of Kubernetes versions and cloud environments. It supports various Linux distributions and integrates with different container runtimes. Additionally, Calico can work with both on-premises and cloud-native infrastructures, including AWS, Azure, and Google Cloud.
The below steps were successfully tested on a cluster running:
* Kubernetes v1.29.8
* Flannel v0.22.0
* Calico v3.28.1
NOTE: live migration will NOT work on a full Lilt deployment. Nodes are unable to reschedule due to LLM image file sizes.
Since Live Migration is not available, must use the following steps for manual migration. This requires the cluster be DOWN for approximately 15 minutes. Please notify all users prior to proceeding.
### Delete Flannel
Switch to root user:
```bash theme={null}
sudo su -
```
On main (control-plane) node, default flannel installation is via a daemonset yaml and must be deleted:
```bash theme={null}
kubectl delete -f kube-flannel-v0.22.0.yaml
```
On EVERY node in the cluster, ssh and stop `kubelet` and `containerd` services:
```bash theme={null}
sudo systemctl stop kubelet.service
sudo systemctl stop containerd
```
On EVERY node in the cluster, ssh and delete the following local files associated with Flannel CNI:
```bash theme={null}
sudo rm -rf /var/lib/cni
sudo rm -rf /run/flannel
sudo rm -rf /etc/cni
# delete flannel driver
rmmod vxlan
```
On EVERY node in the cluster, ssh and delete ip interfaces associated with Flannel:
```bash theme={null}
# Look for any CNI/Flannel related interfaces, and remove them
sudo ip link
# links are usually the following
sudo ip link delete cni0
sudo ip link delete flannel.1
```
On the main node (or one of the control-plane nodes), restart `kubelet` and `containerd` services:
```bash theme={null}
sudo systemctl restart containerd
sudo systemctl restart kubelet.service
```
Verify that the `kube-flannel` namespace does not exist:
```bash theme={null}
kubectl get namespace
```
If the namespace `kube-flannel` is listed, delete it:
```bash theme={null}
kubectl delete namespace kube-flannel
```
### Install Calico (tigera-operator)
There are two options for installing Calico; operator and manifest. Manifest is the easiest option but only installs the basic CNI interface. Lilt requires the Calico operator for integration with Istio mesh services.
If installing on a single-node cluster, need to remove taint on the control-plane so that the operator will schedule:
```bash theme={null}
kubectl taint nodes --all node-role.kubernetes.io/control-plane-
```
On the main (control-plane) node, create a values override file for the helm install. Need to ensure that the CIDR range is the same as the previous Flannel installation:
* default Flannel CIDR: `192.168.0.0/17`
```bash theme={null}
mkdir /tigera-operator
cat <
image: tigera/operator
version: v1.34.3
calicoctl:
image: /calico/ctl
tag: v3.28.1
# this creates the secret for you, DO NOT use if already have existing secrets in the cluster
imagePullSecrets: {}
installation:
enabled: true
# custom registry for pulling additional images, similar to operator above
# image tags MUST be default, i.e. calico/apiserver
# must end with "/"
registry: /
# set if using existing secrets already in the cluster
imagePullSecrets:
- name: third-party
- name: gar-json-key
# network settings
calicoNetwork:
ipPools:
# MUST match kubeadm init and previous flannel CIDRs
- cidr: 192.168.0.0/17
defaultFelixConfiguration:
enabled: false
EOF
```
If have external internet access, pull helm chart and install with override file:
```bash theme={null}
helm repo add projectcalico https://projectcalico.docs.tigera.io/charts
kubectl create namespace tigera-operator
helm upgrade calico projectcalico/tigera-operator \
--install \
--namespace tigera-operator \
--create-namespace \
--version v3.28.1 \
-f /tigera-operator/on-prem-values.yaml
```
Check install status with the following command (can take up to a minute to be fully ready):
```bash theme={null}
kubectl get tigerastatus
```
Result when fully ready:
```bash theme={null}
NAME AVAILABLE PROGRESSING DEGRADED SINCE
apiserver True False False 3s
calico True False False 13s
ippools True False False 38s
```
OPTIONAL: If coredns pods are installed but not ready, or have CrashLoopBack errors, need to restart coredns:
```bash theme={null}
kube-system coredns-76f75df574-2xkkf 0/1 Running 0 27m
kube-system coredns-76f75df574-q6z45 0/1 Running 0 27m
# or
kube-system coredns-76f75df574-2xkkf 0/1 CrashLoopBackOff 7 (3m13s ago) 46m
kube-system coredns-76f75df574-q6z45 0/1 CrashLoopBackOff 7 (3m13s ago) 46m
```
Restart coredns:
```bash theme={null}
kubectl rollout restart -n kube-system deployment/coredns
```
Coredns will then recognize Calico CNI and be in ready state:
```
kube-system coredns-6b48cb45df-9qvn7 1/1 Running 0 4s
kube-system coredns-6b48cb45df-xgs62 1/1 Running 0 4s
```
OPTIONAL: If Calico will not schedule, can also restart containerd again:
```bash theme={null}
sudo systemctl restart containerd
```
Restart ALL updated/modified nodes. Required to implement new CNI settings:
```bash theme={null}
sudo reboot
```
After reboot, some pods might be in pending/running state but not healthy/complete:
```powershell theme={null}
lilt-dataflow-ingest-wpa-minio-cronjob-28767000-7mk44 1/2 Running 4 192.168.119.203 node-1 21h
lilt-dataflow-ingest-wpa-minio-cronjob-28768440-4xxqt 1/2 Running 0 192.168.119.177 node-1 10m
```
Delete the pods and they should be back to healthy:
```bash theme={null}
kubectl delete pod lilt-dataflow-ingest-wpa-minio-cronjob-28767000-7mk44
```
Result:
```bash theme={null}
lilt-dataflow-ingest-wpa-minio-cronjob-28767000-ftmhj 0/2 Completed
```
### Install calicoctl (optional, but highly recommended)
calicoctl is a command line tool that can be used to manage the Calico network and security policies and other Calico configurations. It communicates directly with etcd to manipulate the datastore. It provides a number of resource management commands and can be used to troubleshoot Calico network issues.
Install calicoctl as a binary on a single host (usually the main control-plane node):
```bash theme={null}
curl -L https://github.com/projectcalico/calico/releases/download/v3.28.1/calicoctl-linux-amd64 -o calicoctl
```
Set the file to executable:
```bash theme={null}
chmod +x ./calicoctl
```
Move to local bin dir:
```bash theme={null}
mv calicoctl /usr/local/bin/calicoctl
```
Verify functionality and version:
```bash theme={null}
calicoctl version
```
# Migrate Object Storage (MinIO to S3)
Source: https://support.lilt.com/kb/migrate-object-storage-minio-to-s3
## Overview
This article walks the installer through migrating LILT object storage from an in-cluster MinIO deployment to an Amazon S3 bucket. It applies when moving an existing self-managed installation onto a fully managed cluster, such as the environment described in [Install System (AWS EKS)](/kb/install-system-aws-eks), where S3 replaces MinIO as the object store.
Object data is read out of MinIO through its S3-compatible API into a plain directory tree on a staging host, then uploaded to the destination bucket. The procedure is read-only against the source cluster: nothing in the export stage modifies the running MinIO deployment or its volume, so the original environment remains available as a fallback until the migration is accepted.
Database migration is a separate procedure and is not covered here.
## Tools you will need
* AWS user with permissions to read and write the destination S3 bucket, and to use its KMS key if the bucket is encrypted with SSE-KMS.
* Required utilities for the staging host:
* AWS CLI
* `kubectl`, with access to the source cluster
* A staging host with:
* Free disk space greater than the total size of the object data
* A case-sensitive filesystem (Linux `ext4` or `xfs`)
## Structure of this Article
The first section explains why the MinIO storage volume cannot be copied directly, and how to confirm which on-disk format your deployment uses.
The remaining sections cover preparing the destination bucket, exporting the objects, uploading them without overwriting existing data, verifying the result, and the configuration changes required before the application can read from the new bucket.
### Installer privileges
All commands are run from a staging host by a user with the permissions stated in the “Tools” section above. Commands that target the source cluster assume the LILT namespace is `lilt`; adjust if your installation uses a different namespace.
## MinIO On-Disk Format
### Why the storage volume cannot be copied directly
Current MinIO releases do not store objects as plain files, even in single-drive deployments. Objects are held in an erasure-coded layout:
* Each object key is a directory containing a metadata file named `xl.meta`
* Object data is written into a version-UUID subdirectory as `part.1`, `part.2`, and so on
* Objects smaller than 128 KiB are inlined into `xl.meta` and have no separate data file
* Drive-level state is kept in a hidden `.minio.sys` directory
Copying that directory tree into S3 uploads unusable metadata fragments under altered key names, and objects below the inline threshold are lost entirely because they never existed as files.
The layout is misleading at a glance. Object keys containing `/` become nested directories under either format, so the directory tree on the volume resembles the output of `aws s3 ls`. Recognising the prefix structure is not evidence that a direct copy will work.
### Confirm the on-disk format
Read the drive format from the MinIO pod. The data volume is mounted at `/export`:
```bash theme={null}
kubectl -n lilt exec -- cat /export/.minio.sys/format.json
```
The `format` field determines which method applies:
* `xl-single` or `xl` — erasure-coded. Use the procedure in this article.
* `fs` — a legacy plain-file layout, used only by installations created by much older MinIO releases. A direct copy of the bucket directory is valid in that case; see “Legacy filesystem layout” at the end of this article.
A second check confirms the result. Under the erasure-coded format, no file is named after an object key:
```bash theme={null}
kubectl -n lilt exec -- sh -c 'find /export -name xl.meta | head -3'
```
## Prepare the Destination
#### Set the user environment variables
```bash theme={null}
export AWS_REGION="us-east-1"
export DEST_BUCKET="example-object-storage"
export STAGE_DIR="/export/objects"
```
#### Confirm bucket access and configuration
Record the encryption and versioning settings; they determine which permissions are required and whether an accidental overwrite can be recovered:
```bash theme={null}
aws s3api head-bucket --bucket $DEST_BUCKET
aws s3api get-bucket-encryption --bucket $DEST_BUCKET
aws s3api get-bucket-versioning --bucket $DEST_BUCKET
```
#### Required permissions
The uploading principal needs the following. If `get-bucket-encryption` reports `aws:kms`, the KMS permissions are also required — without them every upload fails with `AccessDenied`, which is easily mistaken for an S3 policy problem:
```text theme={null}
s3:PutObject, s3:AbortMultipartUpload, s3:ListBucket, s3:GetBucketLocation, s3:GetObject
kms:GenerateDataKey, kms:Encrypt, kms:DescribeKey (only when the bucket uses SSE-KMS)
```
Validate write access with a single object before starting a long transfer:
```bash theme={null}
echo test > /tmp/probe
aws s3 cp /tmp/probe s3://$DEST_BUCKET/migration-probe
aws s3 rm s3://$DEST_BUCKET/migration-probe
rm /tmp/probe
```
## Export Objects from MinIO
#### Stop application writes
An object store copy is only consistent if nothing is writing to it. Scale down the application workloads while leaving the data services running, since MinIO is the source of the export.
Record the current replica counts first, so the environment can be restored if the migration is abandoned:
```bash theme={null}
kubectl -n lilt get deploy,statefulset \
-o custom-columns='KIND:.kind,NAME:.metadata.name,REPLICAS:.spec.replicas' \
--no-headers > /tmp/replicas-before.txt
```
Scale down the application, excluding the data services:
```bash theme={null}
DATA_SVCS='minio|mysql|mongodb|rabbitmq|clickhouse|elasticsearch|redis|dragonfly|qdrant'
kubectl -n lilt get deploy -o name \
| grep -vE "$DATA_SVCS" \
| xargs -r -I{} kubectl -n lilt scale {} --replicas=0
kubectl -n lilt get rollout -o name 2>/dev/null | xargs -r -I{} \
kubectl -n lilt patch {} --type=merge -p '{"spec":{"replicas":0}}'
```
Suspend scheduled work, which would otherwise continue writing after the deployments are scaled down:
```bash theme={null}
kubectl -n lilt get cronjob -o name 2>/dev/null | xargs -r -I{} \
kubectl -n lilt patch {} --type=merge -p '{"spec":{"suspend":true}}'
kubectl -n lilt get cronworkflow -o name 2>/dev/null | xargs -r -I{} \
kubectl -n lilt patch {} --type=merge -p '{"spec":{"suspend":true}}'
```
Do not scale down every deployment in the namespace with a single command. Doing so stops MinIO, which the export reads from, and discards the replica counts needed to restore the environment.
#### Retrieve the MinIO credentials
Read them from the cluster rather than assuming the installation defaults are still in place:
```bash theme={null}
kubectl -n lilt get secret minio -o jsonpath='{.data.rootUser}' | base64 -d; echo
kubectl -n lilt get secret minio -o jsonpath='{.data.rootPassword}' | base64 -d; echo
```
#### Open a connection to the MinIO API
Forward the MinIO service port to the staging host:
```bash theme={null}
kubectl -n lilt port-forward svc/minio 9000:9000 &
PF_PID=$!
sleep 2
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:9000/minio/health/live
```
A response of `200` confirms the connection.
Port forwarding tunnels through the Kubernetes API server and can drop during a long transfer. If the connection proves unstable, capture the service definition, expose it as a NodePort for the duration of the migration, connect directly to a node, and restore the original definition afterwards:
```bash theme={null}
kubectl -n lilt get svc minio -o yaml > /tmp/svc-minio-before.yaml
kubectl -n lilt patch svc minio -p \
'{"spec":{"type":"NodePort","ports":[{"name":"http","port":9000,"targetPort":9000,"nodePort":32000}]}}'
# transfer, then restore
kubectl -n lilt apply -f /tmp/svc-minio-before.yaml
```
#### Configure the AWS CLI for MinIO
MinIO does not provide per-bucket DNS, so path-style addressing is required. This profile is used only to read the source; the upload uses your normal AWS credentials:
```bash theme={null}
aws configure set aws_access_key_id "" --profile minio
aws configure set aws_secret_access_key "" --profile minio
aws configure set region $AWS_REGION --profile minio
aws configure set s3.addressing_style path --profile minio
mio() { aws --profile minio --endpoint-url http://127.0.0.1:9000 "$@"; }
```
#### TLS-enabled MinIO endpoints
A default installation serves the MinIO API over plain HTTP inside the cluster, which is what the endpoint above assumes. If custom certificates have been applied to MinIO outside of the service mesh, the endpoint must use `https` instead, and certificate verification usually has to be relaxed for the export:
```bash theme={null}
mio() { aws --profile minio --endpoint-url https://127.0.0.1:9000 --no-verify-ssl "$@"; }
```
Verification fails even with a valid certificate when connecting through a forwarded port, because the certificate is issued for the in-cluster service name and does not match `127.0.0.1`. `--no-verify-ssl` is acceptable here since the connection is a local tunnel to a port on the same host.
The alternative is to trust the certificate authority properly and connect by a name the certificate covers, which avoids disabling verification:
```bash theme={null}
export AWS_CA_BUNDLE=/path/to/ca-bundle.crt
```
The same applies to the health check earlier in this section: use `curl -k https://127.0.0.1:9000/minio/health/live` when the endpoint is served over TLS.
These settings affect only the export from MinIO. Connections to the destination S3 bucket use public AWS certificates, which verify against the system trust store, so no equivalent option is needed and `AWS_CA_BUNDLE` must not remain set for those commands.
Identify the source bucket. A default installation uses a single bucket for application object storage:
```bash theme={null}
mio s3 ls
export SOURCE_BUCKET=""
```
#### Record the source inventory
These files are the reference for every verification step, including after the upload. Retain them:
```bash theme={null}
mio s3 ls --recursive --summarize s3://$SOURCE_BUCKET/ > /tmp/src-listing.txt
tail -3 /tmp/src-listing.txt
awk 'NF>3 { $1=""; $2=""; $3=""; sub(/^ +/,""); print }' /tmp/src-listing.txt \
| sort > /tmp/src-keys.txt
wc -l /tmp/src-keys.txt
df -h $STAGE_DIR
```
Free space on the staging host must exceed the reported total size.
#### Check the object key names
Some valid S3 keys cannot be represented as filesystem paths. Check before starting a long transfer rather than after. No output from all four commands is the expected result:
```bash theme={null}
grep -c '/$' /tmp/src-keys.txt # directory-marker keys
grep -n '//' /tmp/src-keys.txt # empty path segment
grep -nE '(^|/)\.\.?(/|$)' /tmp/src-keys.txt # . or .. path segments
tr 'A-Z' 'a-z' < /tmp/src-keys.txt | sort | uniq -d # case-only collisions
```
Any result here requires a decision before proceeding. S3 keys are case-sensitive, so two keys differing only in case are distinct objects that a case-insensitive filesystem would silently merge into one file. A key ending in `/` cannot round-trip through a filesystem at all.
#### Export to the staging directory
```bash theme={null}
mkdir -p $STAGE_DIR
aws configure set default.s3.max_concurrent_requests 32 --profile minio
mio s3 sync s3://$SOURCE_BUCKET/ $STAGE_DIR/ --no-progress 2>&1 | tee /tmp/export.log
```
#### Verify the export format
Confirm the export contains objects rather than MinIO's internal layout. All four commands must return `0`. A non-zero result means the storage volume was copied instead of the API contents, and the export cannot be used:
```bash theme={null}
find $STAGE_DIR -name 'xl.meta' | wc -l
find $STAGE_DIR -name 'part.*' | wc -l
find $STAGE_DIR -name '.minio.sys' | wc -l
find $STAGE_DIR -type d -empty | wc -l
```
Confirm the exported entries are regular files. Under the erasure-coded format these same paths were directories, so this is the positive signal:
```bash theme={null}
find $STAGE_DIR -type f | head -5 | xargs -I{} sh -c 'printf "%s\n " "{}"; file -b "{}"'
```
#### Verify the export is complete
The object count and byte total must match the inventory, and both `comm` commands must produce no output:
```bash theme={null}
find $STAGE_DIR -type f | wc -l ; grep 'Total Objects' /tmp/src-listing.txt
du -sb --apparent-size $STAGE_DIR ; grep 'Total Size' /tmp/src-listing.txt
( cd $STAGE_DIR && find . -type f | sed 's|^\./||' | sort ) > /tmp/exported-keys.txt
comm -23 /tmp/src-keys.txt /tmp/exported-keys.txt # in MinIO, missing locally
comm -13 /tmp/src-keys.txt /tmp/exported-keys.txt # local, not in MinIO
```
Use `--apparent-size` with `du`. Without it, `du` reports allocated blocks and overstates the total against the byte count S3 reports.
#### Verify content integrity on a sample
Matching names and sizes do not prove the contents are correct. For objects uploaded in a single part, the MinIO ETag is the MD5 of the content and can be compared directly. Objects uploaded in multiple parts have an ETag ending in `-` and are skipped by this check:
```bash theme={null}
shuf -n 25 /tmp/src-keys.txt | while IFS= read -r key; do
etag=$(mio s3api head-object --bucket $SOURCE_BUCKET --key "$key" \
--query ETag --output text 2>/dev/null | tr -d '"')
case "$etag" in *-*) printf 'SKIP (multipart) %s\n' "$key"; continue ;; esac
local_md5=$(md5sum "$STAGE_DIR/$key" | cut -d' ' -f1)
[ "$etag" = "$local_md5" ] && printf 'OK %s\n' "$key" \
|| printf 'MISMATCH %s (minio=%s local=%s)\n' "$key" "$etag" "$local_md5"
done
```
Also check the largest objects, where a truncated transfer appears first:
```bash theme={null}
sort -k3 -n -r /tmp/src-listing.txt | head -10
```
Any `MISMATCH` result means the export must be repeated for those keys before continuing.
#### Close the connection
```bash theme={null}
kill $PF_PID
```
## Upload Objects to S3
Object keys are preserved exactly. Only the bucket name changes: `$STAGE_DIR/` maps to `s3://$DEST_BUCKET/`. Do not introduce an additional prefix at the destination — the application stores these keys in its database, and adding a prefix invalidates every stored reference.
#### Inventory the destination
The destination bucket may already contain objects that must not be overwritten. Record its contents in detail first. This listing is also the baseline that proves, after the upload, that nothing pre-existing was modified:
```bash theme={null}
aws s3api list-objects-v2 --bucket $DEST_BUCKET \
--query 'Contents[].[Key,ETag,LastModified,Size]' --output text \
| sort > /tmp/dst-before-detail.txt
cut -f1 /tmp/dst-before-detail.txt | sort > /tmp/dst-before.txt
comm -12 /tmp/src-keys.txt /tmp/dst-before.txt > /tmp/collisions.txt
comm -23 /tmp/src-keys.txt /tmp/dst-before.txt > /tmp/to-upload.txt
wc -l /tmp/collisions.txt /tmp/to-upload.txt
```
Keys listed in `collisions.txt` are skipped by the upload, so the object already in the destination is kept and the exported copy is not migrated. Review the list before continuing: for any colliding key whose contents differ, the source version is silently left behind, and the application will serve the destination version because it references keys rather than contents.
#### How aws s3 sync decides what to transfer
`aws s3 sync` does not blindly re-upload everything. The reference documentation states the rule:
> A local file will require uploading if the size of the local file is different than the size of the S3 object, the last modified time of the local file is newer than the last modified time of the S3 object, or the local file does not exist under the specified bucket and prefix.
Two consequences matter for this migration:
* An object already present at the destination, with the same size and an equal or later modification time, is **not** transferred. `sync` will not re-upload identical objects, so re-running it after an interruption resumes rather than repeating work.
* An object already present at the destination **is** replaced if its size differs from the exported copy, or if the exported copy carries a newer modification time. Presence at the destination is therefore not by itself a guarantee that the existing object is preserved.
For a migration into a bucket that already holds data, rely on the key list built in the previous step rather than on the comparison rule. Uploading only the keys that are absent from the destination makes an overwrite impossible, because no request is ever issued against an existing key. This method also behaves identically on every AWS CLI version.
#### Upload only the keys absent from the destination
```bash theme={null}
export DEST_BUCKET STAGE_DIR
upload_one() {
key="$1"
if aws s3api head-object --bucket "$DEST_BUCKET" --key "$key" >/dev/null 2>&1; then
printf 'SKIPPED-EXISTS %s\n' "$key"
elif aws s3 cp "$STAGE_DIR/$key" "s3://$DEST_BUCKET/$key" --only-show-errors; then
printf 'UPLOADED %s\n' "$key"
else
printf 'FAILED %s\n' "$key"
fi
}
export -f upload_one
tr '\n' '\0' < /tmp/to-upload.txt \
| xargs -0 -P 8 -I{} bash -c 'upload_one "$@"' _ {} \
| tee /tmp/upload.log
```
Each key is checked immediately before it is written, which also catches anything added to the destination since the inventory was taken. Confirm the results:
```bash theme={null}
grep -c UPLOADED /tmp/upload.log # equals the line count of to-upload.txt
grep SKIPPED-EXISTS /tmp/upload.log # expected empty
grep FAILED /tmp/upload.log # must be empty
```
The command requires `bash` for `export -f`. Remove `-P 8` to run the uploads serially. Re-running is safe: keys already uploaded are skipped by the check.
Do not set `--sse` or `--sse-kms-key-id`; the bucket's default encryption is applied server-side, and specifying a different key only introduces a failure.
#### Using aws s3 sync instead
If the destination bucket is empty — confirmed by the inventory in the previous step reporting no objects — `aws s3 sync` is simpler and parallelises automatically:
```bash theme={null}
aws configure set default.s3.max_concurrent_requests 32
aws s3 sync $STAGE_DIR/ s3://$DEST_BUCKET/ --dryrun | wc -l
aws s3 sync $STAGE_DIR/ s3://$DEST_BUCKET/ --no-progress 2>&1 | tee /tmp/upload.log
```
The trailing slashes are required for keys to map correctly. Never pass `--delete`, which removes destination objects that are absent from the source.
Recent AWS CLI versions also provide a `--no-overwrite` option, described in the reference as preventing overwriting at the destination so that only files not already present are transferred. It is not available in every version, so confirm it before depending on it:
```bash theme={null}
aws --version
PAGER=cat aws s3 sync help | col -b | grep -c -- '--no-overwrite'
```
A result of `0` means the installed version does not support it, and a `sync` issued with the flag would fail or ignore it. Use the key-list method above in that case.
#### Stricter alternative for a bucket in active use
If other writers may be adding objects to the bucket while the upload runs, a conditional write removes the remaining race. The service rejects the request with `PreconditionFailed` when the key already exists, so an overwrite is impossible at the API level rather than by prior inspection:
```bash theme={null}
aws s3api put-object --bucket $DEST_BUCKET --key "" \
--body "$STAGE_DIR/" --if-none-match '*'
```
A single request of this form is limited to 5 GiB, so any larger object must be uploaded by one of the methods above. Identify them first:
```bash theme={null}
awk 'NF>3 && $3+0 > 5368709120 { size=$3; $1="";$2="";$3=""; sub(/^ +/,"");
print size "\t" $0 }' /tmp/src-listing.txt
```
## Verify the Migration
#### Confirm no existing objects were modified
Take the detailed listing again and compare it against the baseline recorded before the upload. No output is the expected result, and confirms that no pre-existing object changed:
```bash theme={null}
aws s3api list-objects-v2 --bucket $DEST_BUCKET \
--query 'Contents[].[Key,ETag,LastModified,Size]' --output text \
| sort > /tmp/dst-after-detail.txt
comm -23 /tmp/dst-before-detail.txt /tmp/dst-after-detail.txt
```
Any line in the output identifies an object that was overwritten. If bucket versioning is enabled, the previous version can be recovered:
```bash theme={null}
aws s3api list-object-versions --bucket $DEST_BUCKET --prefix ""
```
#### Confirm every source object arrived
This comparison must produce no output:
```bash theme={null}
aws s3api list-objects-v2 --bucket $DEST_BUCKET \
--query 'Contents[].Key' --output text | tr '\t' '\n' | sort > /tmp/dst-keys.txt
comm -23 /tmp/src-keys.txt /tmp/dst-keys.txt
```
Compare the object counts and total sizes as well:
```bash theme={null}
aws s3 ls --recursive --summarize s3://$DEST_BUCKET/ | tail -3
tail -3 /tmp/src-listing.txt
```
The destination totals include any objects that were already present, so they will exceed the source totals by that amount. Compare the key sets and per-object sizes rather than the totals alone.
Do not compare ETags between MinIO and S3. Server-side encryption and multipart uploads both change the ETag, so a difference between the two systems carries no meaning. ETag comparison within the destination bucket, as used in the check above, is valid because the bucket and its encryption settings are the same on both sides.
#### Confirm the expected prefixes are present
```bash theme={null}
aws s3 ls s3://$DEST_BUCKET/
```
## Post-Migration Configuration
Migrating the data does not by itself connect the application to the new bucket. Confirm the following before returning the environment to service.
* **Bucket name.** The bucket name configured for the application must match the destination bucket. Check every location where the deployment sets it, including any per-service override, since a single global value can be shadowed by a stale one elsewhere.
* **Object storage endpoint.** Any MinIO endpoint, region placeholder, or TLS verification override used for in-cluster storage must be replaced with the AWS S3 endpoint and the real region.
* **Credentials.** If pods obtain AWS credentials from an IAM role for service accounts, any static access key left in the configuration must be cleared. A static value takes precedence over the role in the AWS SDK credential chain, so leftover MinIO development keys cause every read to fail against S3.
* **Certificate bundle.** Any custom CA bundle configured for a private object store must be unset. AWS certificates verify against the system trust store.
* **Upload notifications.** In-cluster MinIO publishes object-created events over AMQP. With S3, the equivalent notification is delivered through SQS, so the queue the application subscribes to must exist in the same account and be named correctly in the configuration. Without it, uploads never complete in the interface.
* **Notification event types.** The bucket notification must include `s3:ObjectCreated:CompleteMultipartUpload` in addition to `s3:ObjectCreated:Put`. Browser uploads above the multipart threshold emit the former, so a configuration covering only `Put` results in small files working and large files appearing to hang:
```bash theme={null}
aws s3api get-bucket-notification-configuration --bucket $DEST_BUCKET
```
* **CORS.** Browsers upload directly to the bucket, so the CORS configuration must allow the application's front-end origin:
```bash theme={null}
aws s3api get-bucket-cors --bucket $DEST_BUCKET
```
## Cleanup
Restore the application to its previous replica counts using the file recorded before the export, then remove the staged copy and temporary credentials:
```bash theme={null}
rm -rf $STAGE_DIR
aws configure --profile minio set aws_access_key_id ""
aws configure --profile minio set aws_secret_access_key ""
```
Remove any temporary IAM access key created for the upload, and restore the MinIO service definition if it was exposed as a NodePort.
Retain the inventory files and transfer logs as a record of the migration.
Keep the MinIO storage volume intact until the migration has been accepted. No step in the export modifies it, so the original environment remains a complete fallback.
## Legacy Filesystem Layout
This section applies only if the format check reported `fs`, which occurs on installations created by much older MinIO releases. In that case the bucket directory contains regular files named after the object keys, and it can be synchronised directly.
Inspect the dry run before running the transfer. Every key listed must be a real object key, with no `xl.meta`, no `part.1`, and no UUID path segments. If any of those appear, the format check was misread and the procedure in this article applies instead:
```bash theme={null}
aws s3 sync // s3://$DEST_BUCKET/ \
--exclude '.minio.sys/*' --dryrun
```
## Debugging
**`AccessDenied` on upload with correct S3 permissions**: the bucket uses SSE-KMS and the uploading principal is missing `kms:GenerateDataKey` or `kms:Encrypt` on the bucket's key. The error names S3 rather than KMS, which makes this easy to misdiagnose.
**The export contains `xl.meta` or `part.1` files**: the storage volume was copied instead of reading through the API. Delete the staged copy and repeat the export using the MinIO endpoint.
**An object already in the destination bucket was replaced**: `aws s3 sync` transfers an object whose size differs from the exported copy, even when the key already exists. Use the key-list method in “Upload only the keys absent from the destination” for a bucket that already holds data. If versioning is enabled on the bucket, recover the previous version with `aws s3api list-object-versions --bucket $DEST_BUCKET --prefix ""`.
**Small files migrate but large files do not appear in the application**: the bucket notification is missing `s3:ObjectCreated:CompleteMultipartUpload`.
**The transfer stops partway with a connection error**: the port-forward tunnel dropped. Re-establish it and run the export again; `aws s3 sync` skips objects already present in the staging directory, so the transfer resumes rather than restarting.
**Objects are present in the bucket but the application reports them as missing**: the configured bucket name does not match the destination bucket, or an additional prefix was introduced during the upload. Compare a key from `src-keys.txt` against the same object in the bucket.
# In-Context Preview
Source: https://support.lilt.com/kb/monolingual-preview
In-Context Preview is a feature of [LILT Translate](/kb/introduction-to-lilt-translate) that allows linguists to preview all confirmed or accepted segments of a document as formatted text. This allows linguists to quickly check for and fix formatting issues. It also allows linguists to view the target text in the context of its neighboring segments without the accompanying source text.
## Preview mode
To open In-Context Preview in LILT Translate, click the `View` tab and select `Preview mode` (shortcut: `Ctrl`+`Shift`+`P`).
![]()
How to access Preview mode
Once open, the in-context document preview displays the translated content with paragraph and HTML formatting.
![]()
Preview mode
### Preview mode actions
* **View source segment:** To view the source content of a segment, click on the segment to open its TM entry in the `Segment context` sidebar.
* **Edit a segment:** Double-click on a segment to be taken back to segment edit mode with the selected segment brought into focus.
* **Exit preview mode:** Click `View`>`Preview mode` to return to segment edit mode.
## Supported HTML formatting
The table below lists the supported formatting types alongside their respective HTML tags. Unsupported formatting will show in plain text in preview mode.
| **Formatting Type** | **HTML Tags** |
| ------------------- | ------------- |
| Bold | b, strong |
| Italic | i, em |
| Underline | u |
| Strikethrough | strike |
| Subscript | sub |
| Superscript | sup |
| Link | a |
| Line break | br |
# Move The System Offline
Source: https://support.lilt.com/kb/move-the-system-offline
## Overview
This section walks the installer through the process of moving a LILT deployed system to an offline location. Please follow this documentation only if the internal IP of the server has changed during the migration.
## Required Tools
You will need to use SSH to connect to the systems.
* On the Mac or Linux, you can open a terminal window and use ssh.
* On Windows, you can use the PuTTY ssh client.
You will also need a web browser to browse the website post installation and verification.
### Installer Privileges
Many sections of this document include text formatted to indicate console input and output. The commands are prefixed with a \$ or # depending on if the administrator should run them as root or not. Additionally, to assist the user to know which machine to run commands on, the prefix node, master, and gpu will be given when the machine should be switched. All following commands after a switch should use those.
#### Non-root commands
```bash theme={null}
$ ./run_a_command as a normal user
node$ ./run_a_command as a normal user on the node machine
```
#### Root commands
```bash theme={null}
# ./run_a_command as root
```
## Prerequisites
This upgrade document is only valid for an existing on-premise install previously installed using on-prem-installer scripts. Before running the scripts, we must prepare dependencies.
### Data Location
Please ensure that:
* Docker images and RPM packages are mounted and available at *\$package\_dir* to all of the nodes (master, non-GPU, and GPU).
In the typical installation, the system administrator will receive this data from LILT prior to installation, and the system administrator will mount the data.
### Host Name
This install is only valid if the Kubernetes node name is consistent during the process, eg. node machines should have the host names as: localhost.localdomain or localhost.node1 etc. You can set it using below commands:
```bash theme={null}
# hostname localhost.localdomain
# hostnamectl set-hostname NEW_HOSTNAME
# exit and re-login
```
This is due to the added persistent volumes which get created inside a k8s node. This field is immutable, so if k8s node is referring to the IP address, it will change after the migration and Persistent Volumes (PV’s) won’t work.
## Backup
We will back-up the running system prior to upgrade. This backup is optional, but recommended, and will be used to restore the projects, documents and memory content in case of any issues.
### InstallDir
Backup Old Install Directory (used for previous install), referred as `backupInstall` in next steps.
### Database
Backup database by running below commands on the installer system:
```bash theme={null}
$ mysqldump --host HOST --user root --password=ROOT_PWD lilt_dev > backup.sql
```
### Documents, Memory
Backup documents by copying `openebs` mount folders in k8s-node.
## Migration steps
After the server has been moved to the offline location, ensure its hostname still remains the same (eg. localhost.localdomain) and the IP address changes.\
Kubernetes will stop working due to the updated IP address. Follow the steps below to complete the migration.
#### 1. Stop the services
```bash theme={null}
# systemctl stop kubelet docker
```
#### 2. Switch Directory
```bash theme={null}
# cd /etc/
```
#### 3. Backup old kubernetes data
```bash theme={null}
# mv kubernetes kubernetes-backup
# mv /var/lib/kubelet /var/lib/kubelet-backup
```
#### 4. Restore certificates
```bash theme={null}
# mkdir -p kubernetes
# cp -r kubernetes-backup/pki kubernetes
# rm kubernetes/pki/{apiserver.,etcd/peer.}
```
#### 5. Start docker
```bash theme={null}
# systemctl start docker
```
#### 6. Re-init master with data in etcd
```bash theme={null}
# kubeadm init -ignore-preflight-errors=DirAvailable-var-lib-etcd --pod-network-cidr=10.244.0.0/16
```
#### 7. Update kubectl config
```bash theme={null}
# cp /etc/kubernetes/admin.conf ~/.kube/config
```
#### 8. Remove old nodes
```bash theme={null}
# kubectl get nodes --sort-by=.metadata.creationTimestamp
# kubectl delete node $(kubectl get nodes -o jsonpath='{.items[?(@.status.conditions[0].status=="Unknown")].metadata.name}')
```
#### 9. Check running pods
```bash theme={null}
# kubectl get pods --all-namespaces -o wide
```
#### 10. Label/ taint node
Ignore if any of the below commands shows an existing value warning.
```bash theme={null}
# kubectl label nodes node-type=worker
# kubectl label nodes node-role.kubernetes.io/master=master
# kubectl label nodes node-role.kubernetes.io/worker=worker
# kubectl taint nodes node-role.kubernetes.io/master-
```
#### 11. Verify Node
Check if node is in ready status
```bash theme={null}
# kubectl get nodes -o wide
```
#### 12. Restart pods
```bash theme={null}
# kubectl get pods -n kube-system | awk '{print $1}' | xargs kubectl delete pod -n kube-system
# sleep 30
# kubectl get pods -n lilt | awk '{print $1}' | xargs kubectl delete pod -n lilt
```
#### 13. Verify Pods
Ensure all pods are in running status.
```bash theme={null}
# kubectl get pods -A -o wide
```
# QA Rules for Data Sources
Source: https://support.lilt.com/kb/multilingual-asset-management
Leveraging TM entries from [Data Sources](/kb/managing-your-lilt-memories) allows your organization to increase translation quality and accelerate turn-around-time. Maintaining your Data Sources is an important part of creating quality localized content, as your Data Source may degrade over time, leading to decreased accuracy and consistency.
The QA rules for Data Source within LILT makes it easy to maintain your Data Sources by giving you the tools to quickly identify and resolve the following QA issues:
* [TM/TB Mismatches](/kb/multilingual-asset-management#tmtb-mismatches)
* [Spelling Errors](/kb/multilingual-asset-management#h_01FCSBEVWMTGH3FSVE1C4KP72A)
* [Grammatical Errors](/kb/multilingual-asset-management#h_01FCSBF8455ZQ24EATN5A83VCE)
* [Typographical Errors](/kb/multilingual-asset-management#h_01FCSBFH1HQTDPD1AJYSVS3ZB3)
## Running QA
To run QA Rules, open the desired Data Source, navigate to the `Manage entries` page, and click the `Run QA` button in the top right corner.
*Note that it can take 30+ minutes for the QA check to complete for a Data Source containing a high volume of TM and TB entries.*
![]()
After the automated quality check has completed, you will see a summary of all the QA errors that were found. Errors are displayed at the segment level.
## Spelling + grammar errors
### Resolving a spelling error
TM QA can identify when a target segment contains one or many spelling errors. LILT will strike through the spelling error and provide a suggested fix in green.
![]()
There are three options for resolving a spelling error:
1. **Accept suggestion**: Select `Accept` to update the segment with the suggested spelling correction.
2. Ignore the spelling error
3. Delete the segment
### Resolving a grammatical error
TM QA can identify when a target segment contains one or many grammatical errors. LILT provides additional information to aid in resolving the error. Above the segment, you can find additional details as to what prompted LILT to flag the segment. LILT will strike through the spelling error in the target text and provide a suggested fix in green.
![]()
There are three options for resolving a grammatical error:
1. **Accept suggestion**: Select `Accept` to update the segment with the suggested grammatical correction.
2. Ignore the spelling error
3. Delete the segment
### Resolving a typographical error
TM QA can identify when a target segment contains one or many typographical errors. LILT will strike through the typographical error and provide a suggested fix in green. When more than one typographical error exists in a segment, details about each of the errors can be found in the header above the segment result.
![]()
There are three options for resolving a typographical error:
1. **Accept suggestion**: Select `Accept` to update the segment with the suggested typographical correction.
2. Ignore the spelling error
3. Delete the segment
## TM/TB mismatches
### Resolving a partial mismatch
If part of a TM segment's source text matches a Termbase (TB) entry, but this partial target text differs from the TB entry, this is known as a partial TM/TB mismatch. In this case, LILT will highlight the mismatched terms in the entry’s source text. Hovering over a highlighted term will display the missing target term.
![]()
There are three options for resolving a partial mismatch:
1. **Update the target:** Select the segment to edit the target text. Add the missing terms to the target segment and click `Update` to apply the changes to the entry.
2. **Ignore the mismatch:** Click the `Ignore` button to permanently ignore an entry. This is a useful option if you have determined there are no issues with the entry and want to continue leveraging the entry as-is for future translations.
3. **Delete the TM entry:** Click the trash icon to permanently remove the TM entry from the Data Source. This action cannot be undone and will ensure the entry is not leveraged in future translations.
### Resolving a full mismatch
If a TM segment’s source text matches a TB entry, but the target text differs from the TB entry, this is known as a full TM/TB mismatch. The QA Rules feature will identify these mismatches, highlight the source segment in red, and provide the TB target text as a suggestion in green.
![]()
There are three options for resolving a full mismatch:
1. **Accept suggestion:** Click the `Accept` button to update the segment with the suggested target text.
2. **Ignore the mismatch:** Click the `Ignore` button to permanently ignore an entry. This is a useful option if you have determined there are no issues with the entry and want to continue leveraging the entry as-is for future translations.
3. **Delete the TM entry:** Click the trash icon to permanently remove the TM entry from the Data Source. This action cannot be undone and will ensure the entry is not leveraged in future translations.
# Navigating The Jobs Page
Source: https://support.lilt.com/kb/navigating-the-jobs-list
LILT makes it easy for you to manage all your Jobs and Projects from our Jobs page.
![Image]()
This article goes over the tools at your disposal in the pages as your headers:
* **Active jobs:** Displays all Jobs still in production.
* **Archived jobs:** Displays all archived Jobs.
* **Delivered jobs:** Displays all delivered Jobs.
Admins and Managers can deliver, archive, delete, and change settings on Jobs.
## Filters
You can filter the Jobs page by:
* Delivery due date
* Creation date
* Job status (Ready to start, In progress, Done)
* Any [job-level custom properties](https://support.lilt.com/kb/Job-Form-Editor#create-a-new-job-level-custom-property) configured at your org or domain level.
![Image]( "Image")
## Job cards
Each Job is represented by a card that displays the Job name, delivery count, language pairs, due date, and word count. Job cards display the most relevant information about the Job so you can quickly see the status of all your Jobs.
![]()
* **Open the Job:** Click the name field or the `Open` button to navigate into [Project List](/kb/navigating-the-projects-list) page, where you will find the Job settings and all the Job's Projects.
* **View Projects:** You can expand Job cards to view and manage its Projects directly from the Job list.
![]()
* **Additional actions:** There are several actions in the far-right dropdown menu on the card that allow you to perform quick tasks without having to open up the Job. These actions are discussed in the sections below. Actions can also be performed on the Projects within the Job. These actions are discussed in the [Projects List](/kb/navigating-the-projects-list) article.
![]()
## Job settings
Click `Job settings` to navigate into the Job's settings page, where you are presented with the following options:
* Change the Job name.
* Change the Job due date.
* Edit settings, such as post-processing, custom properties, and job instructions.
* Archive and unarchive the Job
* Delete the Job.
![Image]()
## Deliver a Job
![]()
When a Job is complete, use the `Deliver` option to perform the following actions:
* Move the Job from the `Active Jobs` page to the `Delivered Jobs` page.
* Mark the Job with a timestamp that is used to measure On-Time Delivery (OTD).
* Set the states of all the Job's Projects to `Done`, moving them to the `Delivered projects` page.
## Archive Jobs
![]()
When a Job is incomplete but no longer being worked on, use the `Archive` option to move it out of the `Active jobs` page. Archiving Jobs allows you to keep your workspace clean and ensures the archived Jobs are not worked on.
Archiving a job will perform the following actions:
* Move the Job from the `Active jobs` page to the `Archived jobs` page.
* Unassign all linguists from their Projects within the Job.
* Archive all Projects and documents within the Job.
Jobs can be unarchived at any time on the `Archived jobs` page. Unarchiving a Job also unarchives its Projects.
*Note: Connector-based Projects within jobs automatically transition from Delivered to Archived once the connector completes the delivery.*
*Note: The benefit of archiving over deleting is that archiving keeps Project TM entries in their associated Data Source (which can be used in other Projects), whereas deleting will remove Project TM entries from their associated Data Source.*
## Download a Job's files
![]()
Click `Download files` to download a ZIP file containing a folder for each Project. Each Project folder contains the Project's target files.
## Download a Job's memory files
![]()
Click `Download memories` to download a ZIP file containing a folder for each Project. Each Project folder contains the Project's memories as TMX files.
## Delete Jobs
![]()
Click `Delete` to permanently remove a Job and its Projects.
*When Projects are deleted, their documents are deleted and their segments are deleted from the associated Data Source. When Jobs and Project are deleted, the associated Data Sources are **not** deleted, allowing for the Data Sources to be used in other Projects. Data Sources are managed through the [Data > Sources](/kb/managing-your-lilt-memories) tab.*
# Navigating The Projects List
Source: https://support.lilt.com/kb/navigating-the-projects-list
LILT makes it easy for you to manage all your Projects from the Projects list page. Opening any Job takes you to the Projects list page for that Job. The Projects list page contains the following sidebar pages:
* **Active Projects**
* **Delivered Projects**
* **Archived Projects**
* **Files**
* **Job Settings**
![]()
This article discusses the tools available to project managers on the following pages: **Active Projects**, **Delivered Projects**, and **Archived Projects**. Project managers and owners are able to manage Projects, while translators and reviewers are only able to open Projects to work on the documents.
## Project cards
Each Project is represented by a card that displays the Project name, status, language pair, due date, and word count. Project cards display the most relevant information about the Project, so you can quickly see the status of all your Projects. Mouse over the `?` icons to view additional information about a Project.
* The green bar at the bottom represents the translation percent complete, and the blue bar represents the review percent complete.
* If any documents have been assigned to linguists, the number of assignments and number of assignments accepted are displayed on the Project card above the text `translators` or `reviewers`.
![]()
The Project actions described throughout the rest of this article are also available from the [Jobs List](/kb/navigating-the-jobs-list) page on the Project cards displayed within each Job card.
* **Open the Project:** Click the name field or the `Open` button to navigate into [Project View](/kb/project-view) page, where all the Project tasks and settings are located.
* **Additional actions:** The dropdown menu on the far-right of the Project card has various actions available to quickly manage a Project. These options are discussed in the sections below.
![]()
## Assign Projects
![]()
Click `Assign` to assign all the documents within the project to a translator or reviewer. *Note: You will be directed to the project page with all the Document cards preselected.*
![]()
## Deliver Projects
![]()
Click `Deliver` to bring up a window to confirm Project delivery. After delivering, the Project's state will be automatically set to `Done`, moving it to the `Delivered projects` page.
![]()
## Archive Projects
![]()
Click `Archive` to move the Project from the `Active projects` page to the `Archived projects` page. Archived Projects will remain visible on the [Jobs list](/kb/navigating-the-jobs-list) page.
Archiving Projects allows you to keep your Projects list clean from Projects that aren’t currently being worked on. The benefit of archiving over deleting is that archiving keeps the Project's TM entries in the associated Data Source (which can be used in other Projects). Projects can be unarchived at any time on the `Archived projects` page.
*Note: Connector-based Projects within jobs automatically transition from Delivered to Archived once the connector completes the delivery.*
## Download a Project's files
![]()
Click `Download files` to download a ZIP file containing the Project's target files.
## Download a Project's TMX memory file
![]()
Click `Download memories` to download a TMX file of the Project's data source.
## Delete Projects
![]()
Click `Delete` to bring up a popup that walks you through the permanent deletion of the Project. Deleting a Project will also permanently delete all of that Project’s documents and segments from the Data Source. Deleting a Project will not delete the Data Source associated with the Project. Data Sources are managed through the [Data > Sources](/kb/managing-your-lilt-memories) tab.
![]()
## Bulk action projects
Selecting one or more projects will give you options to bulk edit, deliver, auto-assign, archive or delete. Clicking on “Edit” will give you the ability to bulk change the project workflow due dates. Updating due dates will override any previously set project or document due dates.
![]()
![]()
# Navigation In The Platform
Source: https://support.lilt.com/kb/new-navigation-in-the-lilt-platform
This article provides information about the sidebar navigation. It enables users to navigate through the different sections and features of the product easily, reducing the time and effort required to find what you are looking for. The sidebar navigation is composed of two main components, the sidebar menu, and the associated submenus. Read more about each section below.
![]()
**Jobs:** A nested list of jobs, projects, and documents. Context-specific actions and sub-tabs are on the main pane of the screen with secondary navigation along the top, and action buttons in the top right.
**Data:** Memories and Termbases.
**Contextual AI:** Your system’s Contextual AI models that power your LILT translation behind the scenes, per language-pair, with links to the associated translation memory. If you have account permissions to view Instant Translate, it is also listed. We’ve also released a feature to train new models. Reach out to your LILT account team to learn more!
**Observability:** Reports depending on your role permissions. Linguists can find the Linguist Stats report here; others can find program-level insights.
**Organization:** Admins and users with the necessary role permissions can manage settings, users, and role permissions under this menu item.
**Connect:** Available LILT connectors, and your organization's API key for use in integrations. Note: Users of on-premises instances of LILT may not have access to the connectors submenu.
**Other Navigation:** Found at the bottom of the page. Click your avatar to change profile settings and logout. Access LILT’s Knowledge Base through the ![]()
icon, and see inbox notifications.
# Node Labels
Source: https://support.lilt.com/kb/node-labels
Lilt cluster utilizes `nodeSelector` for scheduling pods on specific nodes. This is a simple way to control where pods are scheduled by adding a key-value pair to a chart or manifest specification.
There are generally three types of nodes in a cluster: main, worker, and GPU.
### Main Node
By default, main nodes (control-plane) are tainted with specification `node-role.kubernetes.io/control-plane:NoSchedule`. This prevents any non-essential cluster workloads from being scheduled.
If the main node has sufficient resources to handle additional workloads or the installation environment is constrained by the number of available nodes, this taint can be removed:
```bash theme={null}
kubectl taint nodes --all node-role.kubernetes.io/control-plane-
```
The node can then be labeled as `worker` as described in the next section.
Allowing workloads to be scheduled on the main node is at the discretion of the cluster admin. This will not negatively affect cluster performance in a low-mid level operations.
### Worker Node
This node is used for running the bulk of application workloads, typically separate from the main and GPU nodes. Label this node as `worker` by executing the following command from a **main** (control-plane) node:
```bash theme={null}
> kubectl label nodes node-type=worker
```
**Verify output**
```bash theme={null}
# Show labels
kubectl get nodes --show-labels
```
### GPU Node
This node is generally used for running GPU intensive pods/applications aside from the worker node; however, this node can also be used for additional workloads if the instance has sufficient resources to handle GPU and application tasks. As with the main node, this decision is up to the cluster admin to determine if GPU nodes can also handle application workloads.
If only using this node for GPU specific tasks, label as `gpu` by executing the following from the **main** (control-plane) node:
```bash theme={null}
> kubectl label nodes capability=gpu
```
Optional: if the GPU node has sufficient resources to run additional workloads, also add worker label:
```bash theme={null}
> kubectl label nodes capability=gpu node-type=worker
```
**Verify output**
```bash theme={null}
# Show labels
kubectl get nodes --show-labels
```
NOTE: nodes must contain the respective pod images. This can be achieved by manually importing images to containerd on each node or using a centralized repository.
### Helm Charts / Manifest
Each helm chart and/or manifest yaml must include proper `nodeSelector: key:value` for pods to schedule.
Example for worker node only:
```bash theme={null}
nodeSelector:
node-type: worker
```
Example for GPU node only:
```bash theme={null}
nodeSelector:
capability: gpu
```
NOTE: if two `key:value` are designated for `nodeSelector`, then BOTH labels MUST be present on the node. Only use the following example if the true intent is to specifically limit pods to a certain node.
This example will only schedule pods on a node that contains BOTH labels:
```bash theme={null}
nodeSelector:
node-type: worker
capability: gpu
```
# Non-Translatables
Source: https://support.lilt.com/kb/non-translatables
A Non-Translatable (also known as Do Not Translate or DNT) is a series of characters that should not be translated. [LILT Translate](/kb/introduction-to-lilt-translate) can be set up to automatically recognize and protect Non-Translatables, which will prohibit changes to the Non-Translatables during translation and review. Project managers can make use of this Non-Translatable protection to keep Non-Translatables from being accidentally translated, saving on overall translation time.
When LILT recognizes Non-Translatables (determined by special formatting set up on an account basis), the Non-Translatables will be displayed in gray boxes to indicate to translators and reviewers that these items are not to be translated.
![]()
Non-Translatables can be used in a wide range of applications, such as:
* numbers
* formulas
* code
* email addresses
* currency
* proper names
LILT does not currently support a standardized Non-Translatable format. However, LILT can enable custom Non-Translatable pattern-matching rules for your account. Reach out to your account representative for more information about enabling custom Non-Translatable rules. Note that Non-Translatables will not be recognized in documents uploaded before this feature is enabled on your account; Non-Translatable matching only works for documents uploaded after your account is enabled with Non-Translatable pattern matching.
## **Using Non-Translatables in LILT Translate**
If a segment contains Non-Translatables, the Non-Translatable items are displayed inside gray boxes in the source text field. The suggestion field also displays any Non-Translatables in gray boxes.
Once a segment is confirmed, Non-Translatables are automatically projected into the target text field using Contextual AI. Non-Translatables may not always be projected into the correct positions; therefore, it is good practice to check the positioning of Non-Translatables after confirming a segment. Once Non-Translatables are added to the target text field, they can be moved around, but cannot be edited or deleted. Note that Non-Translatables can be moved even after the segment is confirmed.
![]()
If you want to add Non-Translatables to the target text field before confirming a segment, you can manually project Non-Translatables at any time by clicking on the gray boxes in the suggestion field.
![]()
When [Pretranslating](/kb/pretranslating-documents), for any segments with 100% TM matches available, any Non-Translatables will be carried over into the target text. In addition, when selecting the Pretranslation option to `UseContextual AI for unmatched segments`, Non-Translatables in the source text will be projected into the target text using Contextual AI. Projecting Non-Translatables using Pretranslation provides more accurate results than projecting Non-Translatables within LILT Translate.
There are two types of Non-Translatables discussed in the sections below: standalone Non-Translatables and paired Non-Translatables.
## **Standalone Non-Translatables**
Standalone Non-Translatables appear on their own and are not related to any other Non-Translatable item in the segment. Standalone Non-Translatable examples:
* HTML tags:
* * \
* \![]()
* Variables in software strings, such as:
* * `"String with one variable {0}"`
* `"String with one variable {0}"`
As an example, if your LILT account is configured to recognize text within two curly braces as Non-Translatables, then an English to French document containing `{{small}}` will not be translated to`{{pétit}}`, but will instead to preserve it as `{{small}}` when it is projected to the target text field.
## **Paired Non-Translatables**
A paired Non-Translatable item is an element of a tag pair. LILT currently supports paired Non-Translatables in this format:
* \ … \
Using paired Non-Translatables in this format causes LILT to treat them as tags within LILT Translate. This means they are not protected like with standalone Non-Translatables, and must be projected into the target text field using the `Project target tags` option under the `Tags` tab. For information on how to use tags, see the [Tags & Formatting](/kb/tags-formatting) article.
Paired Non-Translatables can be nested (and can encompass standalone Non-Translatables):
* `This sentence uses bold and