# 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.

<Note>
  *Administrator role or equivalent API Access role permission is required to configure LLMs in LILT.*
</Note>

## Configuring and Editing LLM Integrations and Settings

### Manage AI Providers

<Frame>
  <img alt="" />
</Frame>

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. <Frame>
        <img alt="" />
      </Frame>
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.

   <Frame>
     <img alt="" />
   </Frame>
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.

<img alt="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.


# 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.
   <Frame>
     <img alt="Image" title="Image" />
   </Frame>

## 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.
  <Frame>
    <img alt="Image" title="Image" />
  </Frame>

### 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
  <Frame>
    <img alt="Image" />
  </Frame>
* **Default source / target languages** (when applicable)
  <Frame>
    <img alt="Image" title="Image" />
  </Frame>

## 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.

<Frame>
  <img alt="Image" title="Image" />
</Frame>

### 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.


# PII Omitted Segments
Source: https://support.lilt.com/kb/PII-Omitted-Segments

Experts 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.

<img alt="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.

<img alt="Image" title="Image" />

<img alt="Image" title="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.

  <img alt="Image" />

<img alt="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).

  <img alt="Image" title="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.

   <img alt="Image" title="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.

   <img alt="Image" title="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.

      <img alt="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.

   <img alt="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.

     <img alt="Image" title="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.

<iframe name="wistia_embed" />

<script />

<script />

## 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.

<img alt="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. \_
   <img alt="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.
     <img alt="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.
      <img alt="Screenshot2026 01 07at15 19 01" title="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`.

<Frame>
  <img />
</Frame>

You can also accept or reject assignments directly from the email notification by clicking on the `Accept all` / `Reject all` buttons or the check <img /> / cross <img /> buttons next to each document.

<Frame>
  <img />
</Frame>

## 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:**

<Frame>
  <img />
</Frame>

**Email notification:**

<Frame>
  <img />
</Frame>


# 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.

<Info>
  **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.
</Info>

## 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

<Frame>
  <Frame>
    <img alt="Screenshot 2026 05 18 At 10 44 44 Am" />
  </Frame>
</Frame>

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.

<Frame>
  <Frame>
    <img alt="Screenshot 2026 05 18 At 10 53 45 Am" />
  </Frame>
</Frame>

### 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.

<Frame>
  <img alt="Screenshot 2026 05 18 At 10 56 55 Am" title="Screenshot 2026 05 18 At 10 56 55 Am" />
</Frame>

### 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

<Frame>
  <Frame>
    <img alt="Screenshot 2026 05 18 At 10 57 47 Am" title="Screenshot 2026 05 18 At 10 57 47 Am" />
  </Frame>
</Frame>

## 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.
   <Frame>
     <img alt="Screenshot 2026 05 18 At 11 03 32 Am" title="Screenshot 2026 05 18 At 11 03 32 Am" />
   </Frame>

### 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.

<Frame>
  <img alt="Screenshot 2026 05 18 At 10 35 36 Am" title="Screenshot 2026 05 18 At 10 35 36 Am" />
</Frame>

## 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.*

<Frame>
  <img alt="Screenshot 2026 07 31 At 9 48 08 Am" />
</Frame>

<Frame />

## Enabling AI QA and exact matches setting

AI QA is configured within [LILT Org settings](https://support.lilt.com/kb/organization-settings#organization-settings).

<Frame>
  <img alt="Screenshot 2026 05 18 At 10 33 36 Am" />
</Frame>

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.

<Frame>
  <img alt="" />
</Frame>

### 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.

<Frame>
  <img alt="Image" />
</Frame>

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.

<Frame>
  <img alt="Screenshot 2026 07 31 At 9 51 36 Am" />
</Frame>

## Revision Reports

Revision reports show AI Review corrections alongside reviewer changes.

<Frame>
  <img alt="" />
</Frame>

**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.

<Note>
  Ask a linguist to verify the rules and AI review results before deployment.
</Note>

### 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}`, `<tags>`, 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

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>


# 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.

   <img alt="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.

<img alt="Screenshot2026 01 16at14 59 12 1" title="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.


# 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.

   <img alt="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”.

   <img alt="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.


# Overwrite Confirmed Segments
Source: https://support.lilt.com/kb/auto-propagation



Overwrite Confirmed Segments (formerly called Auto-Propagation) is a feature of [LILT Verify](/kb/introduction-to-lilt-translate) that saves linguists time by automatically completing and confirming repeated segments. Overwriting confirmed segments affects only the current document.

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

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”
* <Frame>
    <img alt="" />
  </Frame>
* 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)
  * <Frame>
      <img alt="" />
    </Frame>
* Now click Create User
* Search for the user created in the previous step and select
  * <Frame>
      <img alt="" />
    </Frame>
* Click Security credentials
  * <Frame>
      <img alt="" />
    </Frame>
* Click “Create access key”
  * <Frame>
      <img alt="" />
    </Frame>
* Select Third-party service, select Next
  * <Frame>
      <img alt="" />
    </Frame>
* 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

<Frame>
  <img alt="" />
</Frame>

### Create S3 Bucket

* Type in S3 in bar
* Click S3
* Create Bucket
  * <Frame>
      <img alt="" />
    </Frame>
  * Choose an AWS region
    * We recommend US-EAST-1
  * Select a General purpose
  * Name the bucket
  * <Frame>
      <img alt="" />
    </Frame>
  * Unselect “block public access”
  * <Frame>
      <img alt="" />
    </Frame>
  * Disable Bucket versioning
  * <Frame>
      <img alt="" />
    </Frame>
  * (Optional) we recommend that you add a LILT tag, so that you can track your usage
  * <Frame>
      <img alt="" />
    </Frame>
  * Click create the bucket
  * <Frame>
      <img alt="" />
    </Frame>
* 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.


# Bi-Directional Text Marks
Source: https://support.lilt.com/kb/bi-directional-text-marks



[LILT Verify](/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 Verify 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.

<Frame>
  <img />
</Frame>

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 |


# 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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>


# 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 Verify 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.

<Frame>
  <img alt="" />
</Frame>

### 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.
  <Frame>
    <img alt="Image" />
  </Frame>

## 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.


# 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 Verify](/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.

<Frame>
  <img />
</Frame>


# 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.’

<Frame>
  <img alt="" />
</Frame>

## 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.

<Frame>
  <img alt="" />
</Frame>

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.

<Frame>
  <img alt="" />
</Frame>

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)”.

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

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.

<Frame>
  <img alt="" />
</Frame>

## 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.

<Frame>
  <img alt="" />
</Frame>

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.

<Frame>
  <img alt="" />
</Frame>

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.

<Frame>
  <img alt="" />
</Frame>

## 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.
   <Frame>
     <img alt="" />
   </Frame>
2. Add supported Language Pairs. ***Please note: These need to be the same languages as the projects that come into LILT.***
   <Frame>
     <img alt="" />
   </Frame>

#### 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.***

<Frame>
  <img alt="" />
</Frame>


# 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)

   <Frame>
     <img />
   </Frame>

3. On Accounts page, scroll down to Authentication Key for DeepL API.

   <Frame>
     <img />
   </Frame>

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.


# 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 <img /> 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 <img /> 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 <img /> 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.

<Frame>
  <img />
</Frame>

## 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.

  <Frame>
    <img />
  </Frame>

* Assignments can be set from the Document card by clicking any of the `Assign` or `Set due date` buttons.

  <Frame>
    <img />
  </Frame>

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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

Once translation and review due dates are set, they are displayed on the Document card.

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

\*\*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.

<Frame>
  <img />
</Frame>

\*\*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.

<Frame>
  <img />
</Frame>

## Pretranslate documents

<Frame>
  <img />
</Frame>

Under the document options dropdown <img />, 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

<Frame>
  <img />
</Frame>

Under the document options dropdown <img />, 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

<Frame>
  <img />
</Frame>

Under the document options dropdown <img /> , 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.

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

## Search documents

Search for documents by name by typing into the search bar. Documents will filter in real-time as you type.

<Frame>
  <img />
</Frame>


# Document Navigation Tab
Source: https://support.lilt.com/kb/document-navigation-tab



The Document sidebar tool in [LILT Verify](/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.

<Frame>
  <img />
</Frame>


# 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).

<Frame>
  <img />
</Frame>

## 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).

<Frame>
  <img />
</Frame>

## 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:

<Frame>
  <img />
</Frame>

Review deadline:

<Frame>
  <img />
</Frame>

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.


# 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](/self-managed/v6.1/enable-features).

## Translation & Workflow

<ResponseField name="additionalGuidelines" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="autoAssignDueDates" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="autoConfirmExactMatchesAndRepetitions" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="autoPretranslateAcceptAndLock" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="autoPretranslateCaseSensitiveTranslation" type="Admin CLI">
  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`).
</ResponseField>

<ResponseField name="autoPretranslateExactMatchesAuthorship" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="autoPretranslateUseMtForUnmatchedSegments" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="defaultPostProcessing" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="defaultVerifiedTranslationJobCreation" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="defaultWorkflow" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="disableTMFuzzyMatch" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableASR" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAutoPretranslate" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="enableAutoPretranslationSetting" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAutoRevisions" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableBackwardPropagation" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableDataLabeling" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableDirectToCloudUploads" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableFilteredTMX" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableFixedLinguistPayment" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableGoogleTranslateInTMLookup" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableJobJiraTickets" type="Admin CLI">
  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`).
</ResponseField>

<ResponseField name="enableJobsFlow" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableJobsListPaginated" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableJobV2" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableOrgDefaultMemory" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enablePostProcessing" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableQuickTranslate" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableRejectWorkflows" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableStringInfoFiles" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableSubfiltersSegmentation" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableUniversalFileUploadEnterprise" type="Org Settings UI">
  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`).
</ResponseField>

<ResponseField name="enableUnlockExactMatchedSegmentsByStage" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="enableVideoDubbing" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableWorkflows" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="externalModelId" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="humanAIOptimizedWorkflow" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="nonTranslatablePatterns" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="showVerifiedQuotingV2" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="surfaceEnableAutoRevisionsOrgSetting" type="Admin CLI">
  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.
</ResponseField>

## Review & QA

<ResponseField name="aiQAExcludeExactMatches" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="automaticBatchQaCustomerReviewer" type="Org Settings UI">
  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).
</ResponseField>

<ResponseField name="automaticBatchQaReviewer" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="automaticBatchQaTranslator" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="defaultReviewSamplingSize" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="defaultSecondaryReviewSamplingSize" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="enableAIQA" type="Org Settings UI">
  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`.
</ResponseField>

<ResponseField name="enableAIReview" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableBlockReviewUnlessTranslationDone" type="Org Settings UI">
  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`).
</ResponseField>

<ResponseField name="enableCustomerReviewQA" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableCustomQAConfig" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableMarkForReview" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableMQMIssueType" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableNeuralAutoReview" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enablePII" type="Org Settings UI">
  Org-level toggle that enables PII redaction. When enabled, `shouldRedactPII` causes PII to be redacted for any user who lacks the `ExportPII` permission.
</ResponseField>

<ResponseField name="enableRejectDocument" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableTmEditorQa" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableTmEditorQaGrammarSpelling" type="Admin CLI">
  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`).
</ResponseField>

<ResponseField name="enableVerifySegments" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="mandatoryErrorFlagging" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="mandatoryErrorFlaggingSecondaryReviewCommercial" type="Org Settings UI">
  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`).
</ResponseField>

<ResponseField name="multimediaQAChecks" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="qaCheckPrompts" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="requireBatchQaCustomerReviewer" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="requireBatchQaReviewer" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="requireBatchQaTranslator" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="requireDistinctReviewers" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="reviewSamplingExcludeExactMatches" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="secondaryReviewSamplingExcludeExactMatches" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="showPreviousStageCommentsSecondaryReviewCommercial" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="skipReviewerIfTranslatorPreferred" type="Admin CLI">
  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.
</ResponseField>

## Editor

<ResponseField name="caseSensitiveTMMatch" type="Org Settings UI">
  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`.
</ResponseField>

<ResponseField name="catMTSuggestionProvider" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="controlCopyAndPaste" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="disable101TMMatches" type="Org Settings UI">
  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`.
</ResponseField>

<ResponseField name="enableCatInfiniteScroll" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableNextWordSuggestions" type="Admin CLI">
  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`.
</ResponseField>

<ResponseField name="enablePromptLabeling" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="enableTargetCharLimit" type="Org Settings UI">
  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`.
</ResponseField>

<ResponseField name="TSFStyleGuide" type="Org Settings UI">
  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.
</ResponseField>

## AI Providers & Models

<ResponseField name="aiReviewModelsPreferences" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="audioToTextModelsPreferences" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="enableAmazonTextract" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAmazonTranscribe" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAmazonTranslate" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAzureGPT35" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAzureGPT5" type="Admin CLI">
  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`).
</ResponseField>

<ResponseField name="enableBedrockAI21Jurassic" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableBedrockClaude2" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableBedrockClaude3Sonnet" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableBedrockTitan" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableBedrockTitanTextExpress" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enabledAIProviders" type="Org Settings UI">
  JSON object of enabled external AI providers (e.g. \{"aws": true, "google": true}).
</ResponseField>

<ResponseField name="enableDeepL" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableGoogleCloudASR" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableGoogleCloudVision" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableGooglePalm2" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableGoogleTranslate" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableGoogleTranslateV3" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableGoogleTranslateV3Migration" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableLiltHostedNvidia" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableLLaMa2" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableLLMConfigurationSettings" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableMcp" type="Org Settings UI">
  Org-level toggle to enable the Model Context Protocol (MCP) integration.
</ResponseField>

<ResponseField name="enableOCR" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableOpenAIGPT3_5" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableOpenAIGPT4" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableOpenAIGPT4_Turbo" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableOpenAIGPT4O" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableOpenAIGPT5" type="Admin CLI">
  Gates the OpenAI GPT-5 option (`createOpenAIModel` with high speed, high cost, high quality) in the LILT Create / AI Hub generative model list.
</ResponseField>

<ResponseField name="enableOpenAIGPT5Mini" type="Admin CLI">
  Gates the OpenAI GPT-5 Mini option (high speed, medium cost, high quality) in the LILT Create / AI Hub generative model list.
</ResponseField>

<ResponseField name="enableOpenAIGPT5Nano" type="Admin CLI">
  Gates the OpenAI GPT-5 Nano option (high speed, low cost, medium quality) in the LILT Create / AI Hub generative model list.
</ResponseField>

<ResponseField name="enableOpenAiWhisper" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableTesseract" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="GeneratedContentPreferences" type="API">
  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.
</ResponseField>

<ResponseField name="GeneratedContentService" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="generativeModelsPreferences" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="imageToTextModelsPreferences" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="translationModelsPreferences" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="viewContextualAI" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="ENABLE_EXTERNAL_MODEL_CONFIG" type="Environment Variable">
  Shows the External Models tab under Organization Settings, letting admins toggle which external AI providers are available.
</ResponseField>

## Authentication & Security

<ResponseField name="enableWSO2Login" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="sessionTimeout" type="Admin CLI">
  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.
</ResponseField>

## Connectors

<ResponseField name="allowedConnectors" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAutoDeliveryBlocking" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableConnectorsBuilder" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableConnectorsManualSubmission" type="Admin CLI">
  Org-level toggle to allow manual submissions for connectors flows. When enabled, users can select content from a connector and submit it manually.
</ResponseField>

<ResponseField name="enableConnectorsView" type="Admin CLI">
  Org-level toggle for the Connectors nav entry: gates the "Connectors" link/card on the homepage and manage-home navigation (`NavigationCards`/`ManageHomepage`, via `useHasSetting`).
</ResponseField>

## Analytics

<ResponseField name="customAnalyticsKey" type="Admin CLI">
  Customer identifier embedded into the Looker Studio embed URL for the AnalyticsV2 Custom Analytics tab (`AnalyticsV2/CustomAnalytics`).
</ResponseField>

<ResponseField name="enableAIAccuracyPerModel" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAnalyticsV2" type="Org Settings UI">
  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`).
</ResponseField>

<ResponseField name="enableCustomAnalytics" type="Org Settings UI">
  Shows the Custom Analytics tab inside AnalyticsV2 (`AnalyticsV2/index.tsx`), which embeds a customer-specific Looker Studio report via `CustomAnalyticsKey`.
</ResponseField>

<ResponseField name="enableFinancialData" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableFinancialsAnalytics" type="Org Settings UI">
  Shows the Financials tab inside AnalyticsV2 (`AnalyticsV2/index.tsx`), exposing financial reporting alongside the Overview, AI Accuracy, and Quality tabs.
</ResponseField>

<ResponseField name="enableLQA" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableOPMStats" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableOpportunitySync" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="grossMarginPercentHumanAiOptimized" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="grossMarginPercentVerified" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="programInsightsKey" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="usageAnalytics" type="Admin CLI">
  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`).
</ResponseField>

<ResponseField name="viewEmbeddedAppInsights" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="viewEmbeddedAppInsightsB" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="viewLinguistStats" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="viewProgramInsights" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="viewProjectsStats" type="Admin CLI">
  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.
</ResponseField>

## Users & Assignment

<ResponseField name="accountLinguistQualitiesIsAvailable" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="autoTriggerAssignment" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAutoAssignment" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableCustomerReviewerDomainAssignment" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableDomains" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableExperts" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableNewLinguistPage" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="fullNameMandatory" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="jobInstructionsEmailTemplate" type="Org Settings UI">
  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`.
</ResponseField>

<ResponseField name="limitAssignmentsToOnboardedUsers" type="Org Settings UI">
  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`.
</ResponseField>

<ResponseField name="linguistAvailabilityToggle" type="Org Settings UI">
  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`).
</ResponseField>

<ResponseField name="organizationInstructionsEmailTemplate" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="organizationTrainingRequired" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="projectInstructionsEmailTemplate" type="Org Settings UI">
  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`).
</ResponseField>

<ResponseField name="timezoneMandatory" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="userCreateLimit" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="userDomainsPreferences" type="API">
  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.
</ResponseField>

<ResponseField name="userLanguagePreference" type="API">
  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.
</ResponseField>

<ResponseField name="userLimit" type="Admin CLI">
  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`).
</ResponseField>

## Misc

<ResponseField name="availableAgentTools" type="Org Settings UI">
  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).
</ResponseField>

<ResponseField name="defaultHomepage" type="Admin CLI">
  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`.
</ResponseField>

<ResponseField name="enableAgentHomepage" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAIAssistant" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableGeneratedContentServiceSelection" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableHomePage" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableOrgSettingsView" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enablePlatformRedesign" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableProjectSettingsView" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableSplitSettingsPage" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="navigationLayoutMode" type="Admin CLI">
  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).
</ResponseField>

<ResponseField name="ALLOW_INCOMPATIBLE_BROWSERS" type="Environment Variable">
  Allows users on unsupported/incompatible browsers to access the platform instead of being blocked.
</ResponseField>


# 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.

<Frame>
  <img />
</Frame>

**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 Verify](/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`).

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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.***


# 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

      <Frame>
        <img />
      </Frame>

      * 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

      * <Frame>
          <img />
        </Frame>

    * 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

      * <Frame>
          <img />
        </Frame>

    * 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”

      * <Frame>
          <img />
        </Frame>

  * This JSON key can be imported into [LILT](https://lilt.com/app/manage/llms)

<Frame>
  <img />
</Frame>

### 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”

  * <Frame>
      <img />
    </Frame>

  * Create a bucket

    * Name the bucket

    * Select region US-Central1

    * <Frame>
        <img />
      </Frame>

      * Storage Class for Data = Standard

    * <Frame>
        <img />
      </Frame>

    * Choose how to control access to objects

      * LILT can work with either choice, customer should choose whichever is best for their systems.

      * <Frame>
          <img />
        </Frame>

    * Choose how to protect object data

      * LILT can work with either choice, customer should choose whichever is best for their systems.

      * <Frame>
          <img />
        </Frame>

      * Click Create, choose confirm

      * Input the bucket name into LILT

      * <Frame>
          <img />
        </Frame>

* In the example above you would paste “example-bucket-lilt” into LILT credentials


# Hotkeys
Source: https://support.lilt.com/kb/hotkeys



[LILT Verify](/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`.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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

<Frame>
  <img />
</Frame>

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”

<Frame>
  <img />
</Frame>

## Downloading Leverage Reports

<Frame>
  <img />
</Frame>

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`.

<Frame>
  <img />
</Frame>

On the Project Report page, click the `Generate` button to generate your first report for the Project.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

* **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.

<Frame>
  <img />
</Frame>

* **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.

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

### 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.


# 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.\\
     <img alt="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**.
   <Frame>
     <img alt="Image" />
   </Frame>
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.


# 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. |
| IDML | .idml | Embedded images shown. Linked images will have placeholders. |

## 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.
   <Frame>
     <img alt="Image" />
   </Frame>
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.
      <Frame>
        <img alt="Screenshot 2026 08 18 At 15 57 44" />
      </Frame>
      <Frame>
        <img alt="Screenshot 2026 06 16 At 10 55 12" />
      </Frame>
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.
   <Frame>
     <img alt="Screenshot 2026 06 16 At 10 56 35" />
   </Frame>
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.
   <Frame>
     <img alt="Screenshot 2026 06 16 At 10 57 58" />
   </Frame>
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.


# 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.

<img alt="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.
     <img alt="Image" title="Image" />
5. Click "Translate". Your job will queue for instant file translation. Feel free to leave the page during translation.
   <Frame>
     <img alt="Image" />
   </Frame>
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.
   <Frame>
     <img alt="Image" />
   </Frame>
7. If you left the page during instant translation, click on "View job" to access your translated files through the notification panel.
   <Frame>
     <img alt="Image" />
   </Frame>


# 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.

<img alt="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).
   <img alt="Image" />
2. Set your source and target languages, and make sure that the toggle for "Receive an expert-verified translation" is toggled off.
   <img alt="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.
   <img alt="Image" />
4. If you didn't upload a subtitle file and there is text to extract, LILT will begin extracting the text.
   <img alt="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.
   <img alt="Image" />
6. LILT will then use your selected custom model to instant translate the video.
   <Frame>
     <img alt="" />
   </Frame>
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".
   <img alt="Image" />
8. Your video will be dubbed into the target language selected.
   <Frame>
     <img alt="" />
   </Frame>
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.*
   <Frame>
     <img alt="Image" />
   </Frame>
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.
    <img alt="Image" title="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.

<Frame>
  <img alt="" />
</Frame>


# 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 Verify
Source: https://support.lilt.com/kb/introduction-to-lilt-translate



LILT Verify is a computer-aided translation (CAT) editor that enables you to create high-quality multilingual content. LILT Verify incorporates a wealth of AI-powered features and tools that enable efficient workflows for content translators and reviewers.

<Frame>
  <img alt="" />
</Frame>

## Editor modes

LILT Verify 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 Verify, the editor mode is displayed in the upper-right as

<Frame>
  <img alt="" />
</Frame>

or

<Frame>
  <img alt="" />
</Frame>

.

<Frame>
  <img alt="" />
</Frame>

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 Verify, you will find the document's source text divided into numbered segments. The segment in focus (the active segment) has several components:

<Frame>
  <img alt="" />
</Frame>

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): Hovering over a highlighted phrase shows its target terms. If the termbase has more than one approved target term, all of them are listed.
* [**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

<img alt="Screenshot 2026 10 01 At 2 43 51 Pm" title="Screenshot 2026 10 01 At 2 43 51 Pm" />

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 List: The document list allows users to easily navigate through different documents in their assigned project
* Style Guide: This Style Guide allows users to see the relevant style guide for the project.
* QA Panel: Segments level and batch level QA results are shown here, along with AI Review changes.

To close the sidebar, click the active icon in the icon rail on the right. The sidebar collapses to the rail and the segment editor expands to use the full width. Click any rail icon to reopen the sidebar to that tab.

To resize the sidebar, drag its left edge. This is especially helpful when reviewing the style guide or concordance, where a larger viewing pane is often needed. The width resets to the default when you reload the page.

See [Segment Context](https://support.lilt.com/kb/segment-context) for more detail.

## Document information footer

<Frame>
  <img alt="" />
</Frame>

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 Verify. 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

<Frame>
  <img alt="" />
</Frame>

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 Verify.

<Frame>
  <img alt="" />
</Frame>

* **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.

<Frame>
  <img alt="" />
</Frame>

* **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 Verify.

<Frame>
  <img alt="" />
</Frame>

* **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.
    <Frame>
      <img alt="" />
    </Frame>
* **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.

<Frame>
  <img alt="" />
</Frame>

* **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.

<Frame>
  <img alt="" />
</Frame>

### Insert tab

The `Insert` tab has a range of tools for interacting with text in the segment editor.

<Frame>
  <img alt="" />
</Frame>

* **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
  <Frame>
    <img alt="" />
  </Frame>
  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).

<Frame>
  <img alt="" />
</Frame>

* **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 Verify to suit your needs. These settings are set on a per-account basis, with changes persisting across documents and Projects.

<Frame>
  <img alt="" />
</Frame>

* [**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 Verify automatically places you into editing the next segment and scrolls the page to keep the selected segment in view.


# Job Stats
Source: https://support.lilt.com/kb/job-stats



<Frame>
  <img />
</Frame>

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

<video />


# 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**](/self-managed/v6.1/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.

<Frame>
  <img alt="" />
</Frame>

## 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).

<Frame>
  <img alt="" />
</Frame>

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).

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

#### 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.

<Frame>
  <img alt="Image" />
</Frame>

### 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.

<Frame>
  <img alt="" />
</Frame>

#### OTD Per Language Pair

The "OTD Per Language Pair" table provides a breakdown of on-time delivery performance for different language pairs.

#### Project Stats

<Frame>
  <img alt="" />
</Frame>

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.


# 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!

<Frame>
  <img />
</Frame>

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.


# 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

<Frame>
  <img alt="" />
</Frame>

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`.

<Frame>
  <img alt="" />
</Frame>

### 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”.

<Tip>
  ✔️ Please note that LILT Contextual AI models are continuously trained in real time, so there is no need to retrain manually through this process!
</Tip>

## 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

<video />


# 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).

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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:

  <Frame>
    <img />
  </Frame>

* Review mode status indicator:

  <Frame>
    <img />
  </Frame>

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.

<Frame>
  <img alt="" />
</Frame>

On the Jobs page, Admin and Managers can see the workflow defined for the job.

<Frame>
  <img alt="" />
</Frame>

For added visibility, Admins and Managers can also see which workflow was selected at the top of the Documents page.

<Frame>
  <img alt="" />
</Frame>

#### Document Status

Document statuses automatically update based on user actions as illustrated below.

<Frame>
  <img alt="" />
</Frame>

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.

<Frame>
  <img alt="" />
</Frame>

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)

<Frame>
  <img alt="" />
</Frame>

Project level assignment. Project is using the Translate only workflow.

<Frame>
  <img alt="" />
</Frame>

### 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

<Frame>
  <img />
</Frame>


# 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”.

<Frame>
  <img alt="" />
</Frame>

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.

<Frame>
  <img alt="" />
</Frame>

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)

   <img alt="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.

<img alt="Screenshot2026 01 13at10 46 39" />

Alternatively, this can be configured after logging in by going to Profile > Display Language.

<img alt="Screenshot2026 01 13at10 44 39" />


# 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)

<Frame>
  <img alt="" />
</Frame>


# 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:

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

### 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)


# 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.

<img alt="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.

<Frame>
  <img />
</Frame>

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.

<img alt="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.

<Frame>
  <img alt="" />
</Frame>

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`.

<Frame>
  <img alt="" />
</Frame>

## Delete a Data Source

Clicking the `Delete`button in the dropdown and confirm that you want to permanently delete the Data Source.

<Frame>
  <img alt="" />
</Frame>

## 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.

<Frame>
  <img alt="" />
</Frame>

## 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

<Frame>
  <img alt="" />
</Frame>

* **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.

<img alt="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.

  <video />

## 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.

<Frame>
  <img alt="" />
</Frame>

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.

<Frame>
  <img alt="" />
</Frame>


# 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.

   <img alt="Screenshot2025 10 23at14 14 05 Pn" />

<Frame>
  <img alt="" />
</Frame>


# 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

<Frame>
  <img alt="Image" />
</Frame>

<Frame>
  Note: All changes under `Settings` are only applied if you click the `Save settings` button at the bottom of the `Settings` section.
</Frame>

**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:**

<Frame>
  <img alt="" />
</Frame>

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.

<Frame>
  <img alt="" />
</Frame>

## 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.

<Frame>
  <img alt="" />
</Frame>


# Preview mode
Source: https://support.lilt.com/kb/monolingual-preview



Preview mode is a feature of [LILT Verify](/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 Verify, click the `View` tab and select `Preview mode` (shortcut: `Ctrl`+`Shift`+`P`).

<Frame>
  <img />
</Frame>

How to access Preview mode

Once open, the in-context document preview displays the translated content with paragraph and HTML formatting.

<Frame>
  <img />
</Frame>

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 |


# 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.*

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img alt="Image" />
</Frame>

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.

<Frame>
  <img alt="Image" title="Image" />
</Frame>

## 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.

<Frame>
  <img alt="" />
</Frame>

* **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.

<Frame>
  <img alt="" />
</Frame>

* **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.

<Frame>
  <img alt="" />
</Frame>

## 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.

<Frame>
  <img alt="Image" />
</Frame>

## Deliver a Job

<Frame>
  <img alt="" />
</Frame>

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

<Frame>
  <img alt="" />
</Frame>

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

<Frame>
  <img alt="" />
</Frame>

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

<Frame>
  <img alt="" />
</Frame>

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

<Frame>
  <img alt="" />
</Frame>

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**

<Frame>
  <img />
</Frame>

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`.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

## Assign Projects

<Frame>
  <img />
</Frame>

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.*

<Frame>
  <img />
</Frame>

## Deliver Projects

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

## Archive Projects

<Frame>
  <img />
</Frame>

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

<Frame>
  <img />
</Frame>

Click `Download files` to download a ZIP file containing the Project's target files.

## Download a Project's TMX memory file

<Frame>
  <img />
</Frame>

Click `Download memories` to download a TMX file of the Project's data source.

## Delete Projects

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

<Frame>
  <img />
</Frame>


# 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 Verify](/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.

<Frame>
  <img />
</Frame>

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 Verify**

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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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 Verify.

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:

* * \<br>

  * \<img>

* 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:

* \<strong> … \</strong>

Using paired Non-Translatables in this format causes LILT to treat them as tags within LILT Verify. 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 <b>bold and <i>italics</i> together {{0}}</b>.`

LILT does not currently support paired Non-Translatables in any other formats, such as:

* \{strong} … \{strong}

* \[bold] … \[/bold]


# OpenAI Configuration
Source: https://support.lilt.com/kb/openai-configuration



To configure OpenAI the customer only needs a single key. If the customer can login to OpenAI, grabbing the key should be simple.

1. Sign into OpenAI (Username and PWD)

2. Go to to [API Keys](https://platform.openai.com/api-keys)

3. Either Create a new Secret Key or find your previous Secret Key

4. Enter in LILT AI Hub

<Frame>
  <img />
</Frame>

### FAQ

Q: If I enter my OpenAI key for GPT4, can this also be used for other OpenAI services, such as Whisper?

A: Yes! Entering the configuration once should enable access to all services from the same provider


# Organization Settings
Source: https://support.lilt.com/kb/organization-settings



LILT provides organizations with several settings that can be tweaked to streamline the translation process in the way that works best for your organization.

To find the settings, navigate to the `settings gear` on the left sidebar.

Organization settings are broken down into the following sections:

* Custom QA checks
* Translate / CAT Editor
* Workflow
* Assignment
* Style guide
* API
* Assist
* External Models (self-managed only, when [enabled](/self-managed/v6.1/enable-features#external-model-configuration))

For the complete list of feature flags and org settings across the platform, see the [Feature Flag Reference](/kb/feature-flags).

<img alt="Screenshot2025 08 20at13 06 07 Pn" />

The options within the `Settings` page affect all users and projects across your organization. Changing settings will affect your session immediately and will take effect for other organization members when they refresh their page.

## Custom QA checks

Customers are able to upload and use custom QA configurations at the organization level. These QA checks will be applicable when running Batch QA in the CAT editor. The ability to upload QA config files is restricted to admin users.

Files must be .qccfg file type, and LILT will prevent the upload of any other file type. LILT only allows 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.

<img alt="Screenshot2025 08 20at13 29 12 Pn" title="Screenshot2025 08 20at13 29 12 Pn" />

## Translate / CAT Editor

<img alt="Screenshot2025 08 20at13 09 08 Pn" />

**AI provider for CAT suggestions:** If the AI provider is set to "LILT Contextual AI", linguists will see suggestions in both the CAT and the CAT sidebar. If suggestions are set to "None", there will be no suggestions. "None" is typically used when a translation needs zero MT bias.

**Allow Copy/Paste:** If the`Allow Copy/Paste` setting is set to "Warn", linguists will get the below popup if they copy/paste content from outside of the LILT Platform into LILT Translate. If the setting is set to "Block", all copy and paste will be blocked within LILT Translate.

<Frame>
  <img alt="" />
</Frame>

**Fuzzy match threshold:** This is a set 75% threshold and not configurable. More information is available in [Data Source Memory Matching](https://support.lilt.com/kb/translation-memory-matching-and-suggestions#tm-match-scores).

**Case-sensitive matching:** If this is turned on, Data source matches are forced to respect case-sensitivity.

**Segment character limit control:** When enabled, this will warn the translator that the space of the translation is limited based on character count metadata (if available).

**Prioritize recency:** If enabled, this will disable 101% match priority and allow for recency-based match prioritization. 101% matches will be treated as equivalent to 100% matches, prioritizing recency over context precision. For more information, please reference [Translation Memory Matching and Suggestions](https://support.lilt.com/kb/translation-memory-matching-and-suggestions).

<frame name="frame" />

**Mandate Error logging:** If turned on, error logging is mandatory in the selected stage(s) when a reviewer changes anything in the target segment. For more information on error flagging, please reference [Segment Comments and Error Flagging](https://support.lilt.com/kb/segment-comments).

### Subtitling QA checks

Please reference [Subtitling QA checks](https://support.lilt.com/kb/subtitling-and-captioning#subtitling-qa-checks) for more information.

<img alt="Screenshot2025 08 20at13 18 50 Pn" />

### Non-Translatable Placeholders

Org admins can now control which placeholder formats should be excluded from translation, directly from org settings. Toggle on the pattern types your content uses:

* **Double curly braces** — e.g. `{{variable}}`
* **Single curly braces** — e.g. `{0}`, `{placeholder}`
* **Percent format specifiers** — e.g. `%s`, `%d`

Once enabled, LILT will automatically recognize and preserve these patterns during translation, so placeholders stay intact in the target content. If your organization uses a pattern that isn't listed here, reach out to your LILT contact to have it added.

<Frame>
  <img alt="Image" />
</Frame>

## Workflow

The Workflow settings section allows you to set the default settings for new Projects created within your organization. These settings can be overridden on a per-Project basis from the [Project Settings](/kb/project-settings) page of existing Projects.

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

### Allow unlocking locked segments

Unlocking locked segments allows for any role to unlock and update locked segments during the selected workflow stage(s). This is intended as a safety valve specifically for Reviewers and Customer Reviewers if errors are spotted during their review so they can quickly and easily correct any errors present, instead of needing to manually update Data Sources. After making any changes to a locked segment, the segment will be re-accepted and will no longer appear as locked. Any changes made will update the data source, auto-propagate to other exact matches in the document, and update in other translations in progress. The default status for this setting is OFF.

**Note: Billing for LILT Services customers**

If you use LILT Services, turning this setting on for the **Translate** or **Review** stage means exact matches (100% and 101%) are reviewed and billed. Here's how it works:

* **Your contracted rate applies** if your agreement includes a Verified Exact Match rate.
* **A default rate of \$0.02 per word applies** if your agreement doesn't include one.
* **All exact-match words in scope are billed**, whether or not they're changed during review.
* **Quotes and invoices show exact matches** as a separate line item.

Enabling this for **Secondary Review** only does not add exact-match charges.

## Assignment settings

When a linguist is assigned to a document, they are automatically sent an email notification. Whatever content is in the `Organization level instructions` field will be included in all assignment emails for the organization. This is a great place to include:

<Frame>
  <img alt="" />
</Frame>

Note that assignment instructions can also be added at the Project level, as described in the [Project Settings](/kb/project-settings) article.

**Limit Assignments:** Only users and linguists directly in the organization can be assigned.

**Auto assign linguists:** When turned on, Auto Assign will trigger 30 minutes after job creation.

## Style guide

LILT’s style guide contains settings that are used for LILT Create and AI Review. Additionally, the style guide is available to linguists as part of Reference Materials and displayed directly within the CAT editor sidebar. Default values are applied, which can then be customized at the organization level as needed. Changes are saved on a field change. When a toggle switch is activated to indicate “Yes”, an open text box appears to provide additional specifics as needed.

**LILT Create** - The LILT Create prompt is customized with all inputs from the style guide to provide context for content generation. To access the style guide from LILT Create, users can click on “Update your settings for LILT Create”, which will open the style guide in a new tab.

**AI Review** - The AI Review scoring and automated revisions are customized with all inputs from the style guide, with the exception of the Formatting section, as those require document-level and external source context.

The style guide is broken down into six sections:

* General
* Terminology
* Conventions
* Style
* Special rules
* Formatting

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

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<br />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.


# PDF File Translation
Source: https://support.lilt.com/kb/pdf-file-translation



LILT supports the direct upload, translation, and export of PDF documents - including text-based PDFs, scanned (image-based) PDFs, and PDFs that contain a mix of both. Translated PDFs preserve the original layout as closely as possible, including columns, tables, and image placement.

This functionality is available for both **Instant** and **Verified Translation** jobs. You can upload one or more PDFs in a single job, and the system will automatically handle the OCR text extraction, translation, and reconstruction of the final document. The translated output can be downloaded as a PDF, individually or in a batch.

*While we aim to perfectly replicate the original layout, formatting differences may occur depending on the complexity of the source document. **If you need formatting explicitly preserved, consider a human verification workflow with add-on post-processing (Desktop Publishing) support through our [Secure File Delivery](https://support.lilt.com/kb/Secure-File-Delivery) feature.***

### How It Works

1. **Upload your PDFs**:
   * Upload one or more PDFs using unified job submission. You do not need to specify whether a PDF is text-based or scanned — LILT processes all PDFs through a single pipeline that automatically handles both OCR text extraction.
2. **Optional — Review extracted text**:
   * Under **Additional options**, you can enable **Review extracted text before translation**. When enabled, the job pauses after processing so you can review (and edit, if needed) the text LILT has extracted from your PDF before it is sent for translation. This is especially useful for scanned PDFs, where OCR quality can vary.
   * Review extracted text before translation is typically off by default. Organization admins can change the default in the [Job Form Editor](https://support.lilt.com/kb/Job-Form-Editor) but this toggle can still be switched on or off during job submission.
     <Frame>
       <img alt="Image" />
     </Frame>
3. **Translation**:
   * After extraction (and optional review), the text is translated using either Instant or Verified Translation, based on your workflow selection. For Instant translation, the toggle for "Receive an expert-verified translation" should be set to off.
   * Once translation is complete, LILT uses a specialized reconstruction service to reassemble the translated text back into the original PDF layout, preserving column breaks, image placement, and table alignment.
4. **Download translated files**:
   * Download your translated PDFs for your selected workflow. LILT also provides DOCX exports so if layouts break due to formatting issues, you can make any formatting changes needed before re-saving as a PDF.
     1. For Instant jobs, "Download" will download .zip folders of the PDF and DOCX translation for individual languages. "Download all" will download a .zip folder of PDF and DOCX translations for all languages in the instant job.
        <Frame>
          <img alt="Image" />
        </Frame>
     2. For Verified jobs:
        * Download your translated PDFs for your job. Click on the "Download files" button in your job delivery email, and use the dropdown to the right of the job to "Download files". This will download a .zip folder of PDF and DOCX translations for each project within the job.
          <Frame>
            <img alt="Screenshot 2026 05 26 At 13 59 32" />
          </Frame>
        * Alternatively, you can download the translated PDF/DOCX files from the Project (Language) level.
          <Frame>
            <img alt="Screenshot 2026 05 26 At 14 01 16" />
          </Frame>

### Supported Features

* **Input Formats**: PDF (text-based, scanned, or a mix of both)
* **Output Formats**: PDF, DOCX
* **Translation Types**: Instant and Verified Translation
* **Batch Actions**: Download multiple translated files at once.

### Important Notes

* **Automatic PDF export is currently only supported for same-direction languages.** For example, EN \<> AR is not supported as English is Left-To-Right and Arabic is Right-To-Left. We are working to support this and will share an update once available. In cases like this, the download will only be available as a TXT file.
* While we aim to perfectly replicate the original layout, formatting differences may occur depending on the complexity of the source document. **If you need formatting explicitly preserved, consider a human verification workflow with add-on post-processing (Desktop Publishing) support.** We cannot automatically resize graphical elements in the PDF to account for text expansion in translation. This can only be done with a manual post-processing workflow step by a member of the LILT team.
* To help improve quality, we recommend enabling **Review extracted text before translation** so you can catch and correct any OCR issues before translation begins (e.g. poor scan quality or unusual layouts).
* **We do not support scanned PDFs of handwritten text.**


# Instant (or Pretranslate) as part of your Workflow
Source: https://support.lilt.com/kb/pretranslating-documents



Instant or Pretranslate is a powerful way to accelerate the translation process by having LILT automatically translate segments for you. Instant leverages a document's associated Translation Memory to translate segments that have 99%, Exact matches (100%) or ICE matches (101%) with TM Entries. In this way, Instant Translate can also be used as a preparatory tool to gauge how much of a document's text comprises new words. Pretranslation can optionally be used to populate Contextual AI suggestions into segments with no TM matches.

## How it works

When you Pretranslate or Instant translation stage, LILT scans the entire document for any unconfirmed segments that are Exact or ICE matches with TM entries in the Project's associated Translation Memory. [*LILT's TM entry prioritization order is described in the Data Source Memory Matching article.*](/kb/translation-memory-matching) Any found matches are used to populate the target text of the matching segment. The translated segments are then marked as `confirmed` and are attributed to the user who made the original TM entry in the associated Translation Memory.

Pretranslate ignores any already confirmed segments, so you don't have to worry about overwriting any translation work that has already been done.

### 99% matches

* 99% matches are left unconfirmed, so they're still presented to linguists in classic Translate > Review workflows for validation.
* In AI Review workflows, 99% matches are excluded from AI Review (just like exact matches), ensuring linguists see them during the Review stage.
* For review sampling, 99% matches are not excluded, maintaining quality control where needed.

## How to use Pretranslate

To use Pretranslate, find the desired document within a Project. On the Document card, open the document options menu, and then click `Pretranslate`.

For multiple documents, select the desired documents within a Project and then click the `Pretranslate` button that appears (as described in the [Bulk Document Actions](/kb/bulk-document-actions) article).

Once the Pretranslate popup opens, you can select any additional translation options you want to use:

<Frame>
  <img alt="" />
</Frame>

The additional options are as follows:

* **Attribute translation authorship of exact matches to \[current user]** : All translated segments with exact matches will be attributed to the current user who is running Pretranslate, regardless of attribution within the associated Translation Memory.

* **Accept and lock exact matches:**
  * **If selected**, segments with Exact or ICE matches:
    * are `confirmed` in Translate mode
    * locked from editing in Translate mode (moving the segment out-of-scope)

      <Frame>
        <img alt="" />
      </Frame>
    * `accepted` in [Review](/kb/reviewing-documents) mode; reviewers are still able to make edits to these segments in Review mode without needing to `unaccept` the segment

      <Frame>
        <img alt="" />
      </Frame>
  * **If not selected**, Exact or ICE match segments:
    * are `confirmed` in Translate mode, but can be edited without needing to `unconfirm` the segment
    * remain unlocked in Translate mode, leaving them in-scope
    * and are not marked as `accepted` in Review mode

* **Use MT for unmatched segments:** Segments that do not have an exact TM match will be translated with Contextual AI. Segments translated in this way are not marked as `confirmed`, whereas segments translated from Exact or ICE matches are marked as `confirmed`. This option is only available for [language pairs with MT support](/kb/supported-languages).

Once you have selected the desired options (if any), click the `Pretranslate`button to begin translating the documents. The documents being translated will display a spinner icon and the text "Pretranslating" while they are being processed. Once finished processing, the spinner icon and "Pretranslating" text will go away.

<Frame>
  <img alt="" />
</Frame>


# Pretranslate Options Deep Dive
Source: https://support.lilt.com/kb/pretranslation-options-deep-dive



This article outlines how project managers can make use of LILT's Pretranslate options to speed up the translation workflow.

To use Pretranslate, navigate to the desired document within a Project, click the `Document Options` button, and then click `Pretranslate`. Multiple documents can be Pretranslated at once using [Bulk Document Actions](/kb/bulk-document-actions).

<Frame>
  <img />
</Frame>

In the Pretranslate popup, select any options you want and then click the `Pretranslate` button to begin translation of the document using Contextual AI. The four options are discussed in the sections below.

<Frame>
  <img />
</Frame>

Based on the options you select when using Pretranslate, you may see the document progress bars grow. The gray bar indicates translation progress. The green bar indicates review progress. Only `confirmed` segments are counted toward the progress bars. The progress bars increase the same as if the segments were `confirmed` manually without using Instant Translate.

<Frame>
  <img />
</Frame>

The following sections in this article detail the functionality of various option combinations:

* [Running Pretranslate with no options selected](/kb/pretranslation-options-deep-dive#running-pretranslate-with-no-options-selected)

* [Option #1: Attribute translation authorship](/kb/pretranslation-options-deep-dive#option-%231%3A-attribute-translation-authorship)

* [Option #2: Accept and lock exact matches](/kb/pretranslation-options-deep-dive#h_01FA3PHH130XC1GW7FXF73RMAA)

* [Option #1 and Option #2](/kb/pretranslation-options-deep-dive#option-%231-and-option-%232)

* [Option #3: Case sensitive matching](/kb/pretranslation-options-deep-dive#option-%233%3A-using-mt-for-unmatched-segments)

* [Option #4: Using MT for unmatched segments](/kb/pretranslation-options-deep-dive#h_01FA3PJ0FA9WCQ6V84JCDC6737)

## Running Pretranslate with no options selected

If none of the options are selected when using Pretranslate:

* All segments with [Exact (100%) or ICE (101%) matches](/kb/translation-memory-matching) are translated, regardless of letter casing.

* Segments with matches of less than 100% are not translated.

* Translation attribution is given to the person who made the original translation in the associated Translation Memory.

* Segments are **not** locked for editing in Translate mode, keeping them in-scope.

* Segments are \*\*not \*\*marked as `confirmed` in Translation mode.

* Segments are \*\*not \*\*marked as `accepted` in Review mode.

## Option #1: Attribute translation authorship

If Option #1 is selected, all translated segments with exact matches will be attributed to the current user running Pretranslate, regardless of attribution within the associated Translation Memory. The translated segments are `confirmed` in Translate mode, but can still be edited as needed.

If Option #1 is not selected, attribution will be given to the person who made the original translation in the associated Translation Memory and the segment will **not** be marked as `confirmed` in Translate mode.

Selecting Option #1 can be useful for tracking contributions across an entire Project. As described in the [How to Read Project Reports](/kb/how-to-read-project-reports) article, within Project Reports, segments generated by Pretranslate are counted as contributions under the designated author’s contribution section. If the project manager is attributed, the contributions will fall under their section. Otherwise, the contributions will be shown under the original translator, who may or may not be working on the Project. If they are working on the Project, the Pretranslate data will be combined with the data from manual contributions.

## Option #2: Accept and lock exact matches

If Option #2 is selected, segments with Exact (100%) or ICE (101%) matches are:

* `confirmed` in Translate mode

* locked from editing in Translate mode, moving the segments out-of-scope

  <Frame>
    <img />
  </Frame>

* `accepted` in [Review](/kb/reviewing-documents) mode; reviewers are still able to make edits to these segments in Review mode without needing to `unaccept` the segment

  <Frame>
    <img />
  </Frame>

Enabling Option #2 is useful for project managers who are confident in the accuracy of a Project’s associated Translation Memory and want to minimize the amount of time translators spend on a document.

If Option #2 is **not selected**, Exact or ICE match segments:

* are `confirmed` in Translate mode, but can be edited without needing to `unconfirm` the segment

  <Frame>
    <img />
  </Frame>

* remain unlocked in Translate mode, leaving them in-scope

* and are not marked as `accepted` in Review mode

Not enabling Option #2 can be useful when starting a new Project where you are borrowing a TM from a previous Project, because the specific translations for the new Project might be slightly different and could need to be adjusted by the translators.

## Option #1 and Option #2

Selecting both Option #1 and Option #2 together will mark Pretranslate segments as translated and reviewed. Pretranslate segments will be `confirmed` and locked in Translate mode, but reviewers can still edit `accepted` segments in Review mode.

This option is useful for Project Managers who are very confident in the accuracy of a Project’s associated Translation Memory and want to minimize the amount of time reviewers spend on a document.

## Option #3: Using MT for unmatched segments

If Option #3 is selected, segments that do not have [Exact or ICE](/kb/translation-memory-matching) TM matches will be generated using the Contextual AI Engine. Segments translated this way will not be marked as `confirmed` in Translate mode, and thus will not increase the document progress bar. This is shown in the example below that used Option #3 for Pretranslate:

<Frame>
  <img />
</Frame>

This option is useful for project managers who know they want to make extensive use of MT and want to save time by pre-populating the Contextual AI suggestions using Pretranslate to save their translators time from having to manually populate thesuggestions for each segment.

This option is only available for [language pairs with MT support](/kb/supported-languages).

If Option #3 is not selected, segments that do not have Exact or ICE TM matches will not be translated at all through Pretranslate.

If you use this option in combination with Option #1, be aware that the Pretranslate segments will become locked in the Translate mode, meaning that translators will not be able to fix any issues that arise through Pretranslate. These Pretranslate issues can only be fixed by reviewers.


# Project Custom Properties
Source: https://support.lilt.com/kb/project-custom-properties



Using Project custom properties, you can add metadata to a Project’s TM entries. This metadata is included when you deliver your Project to an external system, which can be particularly useful if you have LILT connected to an external Content Management System (CMS). For example, you could use metadata to add reference IDs for external systems like ticket numbers or configuration settings. Custom properties are also useful in managing metadata that gets used for automation/API purposes.

By default, custom properties metadata only affects the Project; it does not add metadata to the associated Data Source and does not affect other Projects using the associated Data Source.

To manage a Project's custom properties, open the desired Project, navigate to the `Settings` tab, and scroll down to the `Custom Properties` section.

<Frame>
  <img />
</Frame>

This sections below discusses adding, editing, and deleting custom properties. It is important to note that changes to custom properties are only applied if you click the `Save` button at the bottom of the `Custom Properties` section.

If you want to undo any changes you have made, simply refresh the page without clicking the `Save` button and the changes will be reverted.

## Adding custom properties

In the `Custom Properties` section, click the `Add custom property` button to add new empty entries.

<Frame>
  <img />
</Frame>

Each entry has the following fields to fill out:

* **Propagate (checkbox):**

  * **If not selected**, the custom property will only exist as metadata within the Project.

  * **If selected**, the custom property becomes locked and is added to all the associated Data Source TM entries. This means other projects using the same Data Source will also be affected. Locked custom property entries cannot be edited, but can be deleted. Be careful when propagating; propagation is not always easily undone for the following reasons:

    * Deleting a custom property from a Project does not delete it from the associated Data Source.

    * An existing custom property with the same name as your new custom property will have its value overwritten in all the Data Source TM entries.

* **Name (text field):** Add the name of the custom property. This is a unique identifier of the metadata field. If you use the same name as any existing custom properties, the existing value will be overwritten.

* **Value (text field):** Add the value of the custom property.

<Frame>
  <img />
</Frame>

When finished adding new entries, click the `Save` button to apply any changes you have made.

## Editing custom properties

If you need to edit any custom property entries, click the name or value text fields, modify the text, and click the `Save` button.

Note that locked custom properties cannot be edited from the Project settings page. Instead, you can edit the name field on the associated [Data Source Settings Page](/kb/memory-settings), and you can edit the value field on an individual basis for each of the Data Source's[TM Entries](/kb/managing-termbase-and-translation-memory-entries).

## Deleting custom properties

If you need to delete any custom properties, click the Delete icon for each entry you want to remove and then click the `Save` button to permanently delete them.

Deleting a custom property from a Project will only remove it from that Project. If any custom properties were propagated to the associated Data Source, you can delete them on the [Data Source's Settings Page](/kb/memory-settings).


# Project Delivery
Source: https://support.lilt.com/kb/project-delivery



When a Project is complete, you can use the `Deliver` button in the top right corner of the page to send the finalized content.

<Frame>
  <img />
</Frame>

## Project TMX

Clicking the `Download TMX` button generates a TMX file for you to download containing the translation data for the entire project.

## Project ZIP

Clicking the `Download project ZIP` button generates a ZIP file of the project for you to download. The file contains the most current translations for all project documents (whether or not the translations have been reviewed).

## Document list

Clicking the `Download document list` button downloads an Excel file with basic document metadata and statuses.

## Revision Report

Clicking the `Download revision report` button downloads an Excel file with a read out of all segment revisions and comments made during Review stages.

## Deliver

When it comes time to notify that a project has been completed, click the `Deliver` button and confirm this action. Confirmation will move the project from the Active Projects list to the Delivered Projects list, and send the content through any LILT Connector that is integrated.

## Delivering content

There are several ways that completed translation content can be delivered to its target destination:

1. Manually download the content and send them to where they need to go.

2. Use one of the available [Integrations](/kb/connectors) to send content directly between the platform and the connected application.

3. Use the [LILT for Developers](/kb/developers) to build your own custom delivery solution.


# Project Settings
Source: https://support.lilt.com/kb/project-settings



The Project `Settings` page allows you to adjust the settings of your Projects to help you better manage and streamline the translation process.

<Frame>
  <img />
</Frame>

The `Settings` page contains the following sections that are each discussed below:

* [General settings](/kb/project-settings#h_01FF3405BNRDV3XFJ7M3WWKMVX)

* [Custom properties](/kb/project-settings#h_01FF340AEXXC39FHRH3KEBS857)

* [Workflow settings](/kb/project-settings#h_01FF340F2DY59C5XC7YG7MD96N)

* [Assignment settings](/kb/project-settings#h_01FF3411DER24VEETPE3J54932)

* [Archive and delete](/kb/project-settings#h_01FF340V4NJH3Z1EP786R38MPD)

## General settings

Under general settings, you can change the **Project Name** and **Deadline** of a Project. Click the `Save settings` button to apply any changes you make.

<Frame>
  <img />
</Frame>

## Custom properties

Custom properties add metadata to all segments (of all documents) within a Project. Read the [Project Custom Properties](/kb/project-custom-properties) article for details on how custom properties work and when to use them.

<Frame>
  <img />
</Frame>

## Workflow settings

Note: the default workflow settings for new Projects created within your organization can be set in [Organization Settings](/kb/organization-settings). Adjusting the settings in the Project settings area will only affect that Project.

<Frame>
  <img />
</Frame>

* [**Review sampling rate**](/kb/review-sampling): The percent of segments to be included in the review sample.

* [**Include exact matches**](/kb/review-sampling): Whether to include exact matches from the sample when review sampling.

* **Pretranslate by default:** Whether to automatically Instant Translate documents immediately when they are uploaded. If enabled, you will be able to select the options you want to apply to the documents. These options are explained in the ['Instant Translate as part of your Workflow'](/kb/pretranslating-documents) article.

<Frame>
  <img />
</Frame>

* **Auto-confirm exact matches & repetitions:** TM Leveraging is a feature of LILT that automatically populates unreviewed 100% and 101% [TM matches](/kb/translation-memory-matching) into the empty target text fields of repeated segments across a document that share a Data Source. When the `Auto-confirm exact matches & repetition` option is enabled, segments populated by TM Leveraging:

  * are automatically confirmed

  * have the metadata of the most recent TM match (reviewed or unreviewed)

  * can still be edited by translators and reviewers

*For information on the differences between TM Leveraging and Overwrite Confirmed Segments, see the *[*Overwrite Confirmed Segments*](/kb/auto-propagation)* article.*

## Assignment settings

When a linguist is assigned to a document, they are automatically sent an email notification. Whatever content is in the `Project level instructions` field will be included in all assignment emails for the Project. This is a great place to include any Project instructions that will help your linguists.

<Frame>
  <img />
</Frame>

Note that assignment instructions can also be added at the Organization level, as described in the [Organization Settings](/kb/organization-settings) article.

## Archive and delete

Clicking the `Archive` button archives the Project. This moves the Project from the `Active projects` page to the `Archived projects` page, where it is stored indefinitely. The `Archive` button will then turn into an `Unarchive` button that you can use to move the Project back to the `Active projects` page. Projects can also be unarchived at any time on the `Archived projects` page, as described in the [Navigating the Projects List](/kb/navigating-the-projects-list) article.

Archiving Projects allows you to keep your Active Projects page clean from Projects that aren’t currently being worked on, while still retaining the Project's TM entries in the associated [Data Source](/kb/managing-your-lilt-memories).

<Frame>
  <img />
</Frame>

Clicking the `Delete project` button opens a popup form that walks you through the permanent deletion of the Project. Deleting a Project will permanently delete all its documents and all its TM entries from the associated [Data Source](/kb/managing-your-lilt-memories). Deleting a Project will not delete the associated Data Source.


# Project View
Source: https://support.lilt.com/kb/project-view



When you open a project from the [Projects List](/kb/navigating-the-projects-list), it brings you into the Project view. The Project view gives you access to all the tools you need to monitor and manage a project.

Follow the links below to read more about each page of the Project view:

* **[Documents](/kb/document-actions):** manage the translation documents.

* **[Reference Materials](/kb/reference-materials):** manage reference material to aid in translation.

* **Reports:**

  * **[Leverage Report](/kb/how-to-read-leverage-reports):** view information that can help estimate project duration and budget.
  * **[Project Report](/kb/how-to-read-project-reports):** view information on Project progress and linguist efficiency.
  * [**Revision Report:**](/kb/how-to-read-revision-reports) view segment level revisions and comments from Review stages.

* **[Settings](/kb/project-settings):** adjust the individual Project's settings.

* **[Delivery](/kb/project-delivery):** download, review, and deliver the finalized Project.

<Frame>
  <img />
</Frame>


# Quality Assurance Checks
Source: https://support.lilt.com/kb/quality-assurance-tools



This article provides an overview of various quality assurance (QA) tools that linguists can make use of to translate and proofread more efficiently and accurately. The following articles delve into the specifics of LILT’s QA checks, which automate a series of standard QA checks to flag errors and warnings to the translator or reviewer.

## Full QA checks

Running a full QA check will search through all segments in the current document for [Linguistic Errors](https://support.lilt.com/kb/quality-assurance-tools#linguistic-error-options) and [Tag Errors](https://support.lilt.com/kb/quality-assurance-tools#tag-error-options).

From within [LILT Translate](/kb/introduction-to-lilt-translate), open the `File` tab and click on `Run full QA check`.

<Frame>
  <img alt="" />
</Frame>

After the full QA check has run, all segments in the document will have a display indicating how many QA issues were found. For example:

* No issues found:
  <Frame>
    <img alt="" />
  </Frame>
* Two issues found:\\
  <Frame>
    <img alt="Screenshot 2026 06 22 At 10 04 33 Am" />
  </Frame>

<Frame>
  To run Auto Review on a single segment, click on the segment’s `QA` button. This is useful for rechecking a segment after making edits to correct any errors the Auto Review flagged.
</Frame>

## 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.

## Linguistic error options

Batch QA displays segments with linguistic errors, and will often provide a suggestion to fix the error. You can accept these suggestions or click on the target text to make your own changes. QA errors can also be `Ignored` if you determine there is no error.

* **Accept:** Clicking `Accept` on an individual segment will apply the suggested fixes to that segment. You can also click on the suggested text area to edit the text manually before accepting the changes.
* **Undo:** If you have accepted a section or segment but still need to make changes, click the `Undo` button to revert the changes and allow the segments to be edited again
* **Ignore:** Clicking `Ignore` on a QA suggestion will ignore the issue for the current Auto Review.

## Tag error options

Batch QA checks highlights tag errors in the target text for each segment. Move the highlighted tags to where they should be, and then click `Save` to apply the changes.

## Require Batch QA

If you are a project manager, you can turn on [Mandatory Batch QA](https://support.lilt.com/kb/mandatory-batch-qa-check#mandatory-quality-assurance-tools) or Automatic Batch QA for translators, reviewers, or secondary reviewers in [Organization settings](https://support.lilt.com/kb/organization-settings#organization-settings). Enabling this will require linguists to accept or ignore all QA errors before marking a document as done. This helps to catch errors earlier, saving on overall review time.

## Split view

LILT Translate has the option to operate in split view. Split view provides a compact tabular layout to make proofreading easier.

<Frame>
  <img alt="" />
</Frame>

Split view can be toggled on and off from `View` tab of LILT Translate.

<Frame>
  <img alt="" />
</Frame>


# Quoting
Source: https://support.lilt.com/kb/quoting-in-lilt



### Overview

LILT offers a versatile quoting system to provide cost transparency before translation work begins.

* Customers can access **Instant quoting** for processable file types, which automatically generates cost estimates based on word count and language pair pricing defined in their contract.
* For more complex projects, **Formal quoting** allows customers to submit files and receive a quote prepared by LILT’s production team, where quotes need approval from the submitter before work begins. These projects may be for processable or non-processable file types, and may include manual processing or text extraction.

Both quoting methods support an approval workflow where customers can review and approve quotes before work begins. These features are particularly valuable for enterprises managing budgets across departments, organizations with tight spending controls, or when working with complex multimedia content that requires specialized handling like desktop publishing (DTP) or localization engineering. Quotes are displayed in the currency of a customer’s LILT contract. If a customer has multiple currencies on their contract, LILT has selected the primary currency for this data. LILT does not do any currency conversion.

If you have any questions or are looking for access, please reach out to your LILT representative.

**Please note that all quotes are an estimate, and the final cost may vary.**

## Instant quoting

### When to use the Instant quoting feature

When submitting a job for verified translation via any of the translation workflows, you can view the estimated quote before clicking the "Send for Translation" button. This feature is helpful when budgeting or when you need approval for translation costs. Instant quoting can be turned on in [Job Form Editor](https://support.lilt.com/kb/Job-Form-Editor).

### How to get an Instant quote

1. Instant quotes will display once you have selected the languages and uploaded the files in your job submission on the quoting step. The system will automatically calculate the estimated quote based on the number of words and complexity, and takes into consideration any file filters. The quote will be displayed at the bottom of the page.
   * The estimated cost is calculated to mimic the process in billing. However, the estimate is for reference only, and the final cost may vary.
     <img alt="Image" />
2. **Confirm and submit**: After reviewing the quote, you can proceed by clicking "Send for Translation." If any adjustments are needed, you can modify your file or language selection before submission.

### Important notes

* **Language availability**: Instant quotes will only be provided for languages that are part of your organization's language agreement with LILT.
* **File type availability:** Instant quotes will only be provided for text-based job inputs. If you submit anything in your job that requires text extraction (e.g. video), then we will not be able to calculate an instant quote.
* **Estimated costs**: The translation cost provided is a rough estimate and may vary depending on the final project details. Changes in word count, file types, and translation complexity (e.g. Desktop publishing) may affect the final billing.

## Offline quoting

### When to use the Offline quoting feature

Some LILT customers need to be able to get quotes on projects and have stakeholders (not job submitters) approve the quote before translation begins. These projects may include offline work, such as file pre-processing for unsupported file types, or require text extraction. Offline quoting can be turned on in [Job Form Editor](https://support.lilt.com/kb/Job-Form-Editor).

### How to get an offline quote

1. After uploading one (or more) files and filling in the job submission form, you can indicate using the toggle at the bottom of the form that you would like to receive an official quote and submit for approval.
   <img alt="Screenshot2026 01 07at15 14 49 1" />
2. Once created, the job will go to the “Awaiting quotation” state.
   <Frame>
     <img alt="" />
   </Frame>
3. At this point, the LILT team will assemble a quote. Once the quote is ready, the job transitions to an “Approval pending” state.
   <Frame>
     <img alt="" />
   </Frame>
   You will receive a notification in-platform and an email when the quote is ready for approval.
   <Frame>
     <img alt="" />
   </Frame>

<Frame>
  <img alt="" />
</Frame>

4. Review and approve the detailed, offline quotation. You can download the detailed quotation (Excel or PDF) with a breakdown of your total costs (if provided).
   <Frame>
     <img alt="Image" />
   </Frame>
5. Approving the quotation will move the job from the “Approval pending” to the “Ready to start” stage. Rejecting the quotation will delete the job.

### Important notes

1. **Estimated costs**: The translation cost provided is a rough estimate and may vary depending on the final project details. Changes in word count, file types, and translation complexity may affect the final billing.


# Reference Materials
Source: https://support.lilt.com/kb/reference-materials



Reference materials can be added to Projects to provide context for translators and reviewers during translation. For example, if a document describing an image is being translated, it could be useful to provide the image to translators and reviewers. Project managers can utilize the reference materials page to keep all relevant Project files in one place, making the translation process as easy as possible for linguists.

To see the reference material for a Project, navigate to the Project and open `Reference Materials` tab to view the `Project instructions` page and the `Files` pages.

<Frame>
  <img />
</Frame>

## Files

Any reference materials that have been uploaded to the Project will be shown under the `Files` page. Reference material files are Project-specific.

<Frame>
  <img />
</Frame>

## Project instructions

The `Project instructions` page displays additional assignment information for linguists. This information is set by the managers in the [Organization Settings](/kb/organization-settings) (not project-specific) and [Project Settings](/kb/project-settings) (project specific).

<Frame>
  <img />
</Frame>

## Uploading reference materials

Any user with write permissions can upload reference material from their device (for more information on user role permissions, see the [RBAC](/kb/role-based-access-control) article).

Reference materials can be quickly added to Projects during Job creation:

<Frame>
  <img />
</Frame>

To add new reference materials after a Project has already been created, open the Project, navigate to `Reference Materials` > `Files`, click on the `Upload new file` button in the upper-right, and select the files you want to upload. There is no file size limit, but for uploads exceeding 1 GB, it is advised to upload them as a ZIP file.

## Label reference materials

If a Project has many reference documents, labelling them can be a useful way to efficiently organize them. To label a document, click the label button on the right side of the Document card and select the labels you want to apply to the document.

<Frame>
  <img />
</Frame>

## Delete reference materials

If a piece of reference material is no longer needed, it can be deleted by clicking the delete button on the right side of the Document card. This brings up a popup to confirm you want to permanently remove the document from the Project’s reference material for all users.

## Download reference materials

<Frame>
  <img />
</Frame>

Users can download a document by clicking on the `Download` button on the right side of the Document card.

## Search and filter reference materials

If there are many reference materials in a Project, you can easily filter through the documents by their labels to find the documents you need:

1. Click the dropdown button on the Filter button.

2. Select the labels you want to filter by.

3. Clicking the `Apply` button.

You can also search for reference materials by typing into the search bar. The search results will actively filter as you type.

<Frame>
  <img />
</Frame>


# Managing Data Sources
Source: https://support.lilt.com/kb/resetting-the-mt-purging-or-preserving-memories



## Resetting The Contextual AI & Purging Or Preserving Data Sources

Contextual AI suggestions can degrade over time if poor Translation Memory (TM) entries are uploaded to your Data Sources. To help you manage the quality of Contextual AI models, the LILT platform allows you to do the following:

* Reset a Contextual AI model.
* Purge a Data Source.
* Preserve a Data Source.

See the [TM Size and Content Guidelines](/kb/tm-size-content-guidelines) article for guidelines on what TM data is best suited for LILT.

## Resetting AI suggestions

You can reset the model by following these steps:

1. Open the `Custom Models` tab.
2. Click the dropdown arrow next to the Edit button and select "Reset AI suggestions".

   <img alt="image.png" title="image.png" />

Reset the Contextual AI to perform the following:

* Reset the [LILT Translate](/kb/introduction-to-lilt-translate) automatic suggestions to a clean slate
* Re-train the Contextual AI model on all confirmed segments in the Data Source

*Note: when resetting the Contextual AI, your TB and TM entries will remain untouched.*

## Purging memory and termbase entries

You can restore your Data Source to a clean slate by purging the memory and termbase entries:

1. Open the `Data > Sources` tab.
2. Open the desired Data Source by clicking on the Data Source name or clicking the `Edit`button.
3. Open the `Settings` page.
4. Under the `Purge data source and termbase` section, click the `Purge data source and termbase`button to open a popup where you will need to confirm you want to purge the Data Source.

<Frame>
  <img alt="" />
</Frame>

Purge the Data Source & Termbase to perform the following:

* **remove all the custom TB and TM entries** from the Data Source
* reset the [LILT Translate](/kb/introduction-to-lilt-translate) automatic suggestions to a clean state; does **not** retrain on the existing TM data

## Preserving Data Source by disabling in-context learning

By default,Data Source adapt to both uploaded TMX files and the linguistic activity of translators and reviewers in LILT Translate. If at any point you need to stop a Data Source from adapting any further, you can do so by disabling the `in-context learning` option within the Data Source settings.

### Disabling in-context learning when creating a new Data Source

During the creation of a new Data Source, toggle off the option for `in-context learning`and then continue with creating the Data Source.

<Frame>
  <img alt="" />
</Frame>

### Disabling in-context learning on an existing Data Source

1. Open the `Data > Sources` tab.
2. Open the desired Data Source by clicking on the name or clicking the `Edit`button.
3. Open the `Settings` page.
4. Toggle in-context learning off. This can be enabled/disabled at any time.

<Frame>
  <img alt="" />
</Frame>


# Review Sampling
Source: https://support.lilt.com/kb/review-sampling



LILT’s review sampling settings allow managers to find their team’s perfect balance between reviewing more segments to catch errors and reviewing fewer segments to save on time and money.

By default, a reviewer will review 100% of each document within a Project. However, it is possible to assign only a sample of the Project to be reviewed. Reducing the sample rate can help reduce the time and costs of translation projects.

The default settings for review sampling are managed at the organization level, but they can also be adjusted on a per-Project basis (either when creating a new Project, or in the Project settings page of existing Projects).

The sections below discuss the functionality of the different review sample settings and where the settings are managed within LILT.

## Review sampling workflow

A document must be marked as `Done` in the translation stage for review sampling to take effect. If the document is not marked as `Done` by the translator, the reviewer will be given the entire document to review.

When reviewing a document and review sampling is less than 100%, once the document has been marked as done in Translate mode, a portion of the segments in the document become locked (for both translators and reviewers) equal to the review sampling rate. Reviewers are shown the entire document, but they are only able to work on unlocked segments.

<Frame>
  <img alt="" />
</Frame>

Reviewers will go through all the unlocked segments to accept any segments with correct translations and edit any segments that need to be corrected.

When all documents in the Project are marked as done in Review mode, the manager will be notified.

<Frame>
  <img alt="" />
</Frame>

The manager is notified the project is completed via email. The email includes the number of segments reviewed and the error rate of those segments.

<Frame>
  <img alt="" />
</Frame>

Please note: Each time a document enters the "Review" stage, review sampling generates a fresh, unique set of segments. Returning to a previous workflow stage restarts the sampling process. For example, if a document follows a workflow like "Review > Translate > Review" (with sampling enabled), the sampled segments in the second review will be different from those in the first.

### How to unlock segments

*Once segments have become locked in a document, if you need to unlock any segments, follow these steps:*

1. ***`A project manager needs to open the document in Translate mode and click on File > Unlock document translation.`***
2. *In Review mode, the locked segments can now be unaccepted to unlock them in both Translate and Review mode.*
3. *Once the necessary segments have been modified, marked as done in Translate mode again to lock the segments and proceed with the document review.*

## Review sampling settings

### Review Sampling Rate

The review sample rate is a value from 10% to 100% and can be set in increments of 10%. This value controls the percent of segments that will be assigned for review. The review percentage applies to all documents in the Project.

For example, in a Project with a 20% review sample rate, a document with 100 segments would have 20 segments assigned for review.

### Include exact matches

If the “include exact matches” setting is **enabled**, the following segment types are **included** inthe pool of segments that can be selected for review:

* 100% TM matches
* Repeated segments

If this setting is **disabled**, the above segment types are **excluded** from the pool of segments that can be selected for review. There are two separate settings to apply this to the Review Sample and the Secondary Review Sample.

For example, if a document is 100 segments long and has 40 repeated segments, the remaining 60 segments will be included in the pool of segments that can be selected for review. If this document is in a project with a review sampling rate of 20%, then 20% of the remaining 60 segments would be sampled (12 segments).

## Managing review sample settings

The review sample settings are set in the [Organization Settings](/kb/organization-settings) and are used to populate the settings of new Projects. Review sample settings can also be set on a per-Project basis in Project settings.

### Organization setting

To set the review sample settings for your organization, navigate to the `Settings` page, open the `Workflow` tab, and scroll down to the `Review` section. From there, you can set the settings for:

* Review sampling rate (two separate settings for Review and Secondary Review samples)
* Include exact matches (two separate settings for Review and Secondary Review samples)

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

*Note: Changing the default setting for review sampling in the Organization Settings does not update the settings of existing Projects.*

The “Include exact matches” setting is toggled off by default. Turning on “Include exact matches” at an org level would then turn it on for all new projects, or you can turn it on on a project basis depending on their needs.

### Project setting

Once a Project has been created, you can change the review sample settings by opening the Project, navigating to the `Project settings` page, and scroll down to the `Workflow settings` section.

<Frame>
  <img alt="" />
</Frame>

After changing the settings, click the `Save settings` button to apply the changes. Making changes here will not affect documents that have already been sampled for review, nor will it affect the Organization workflow settings.


# Reviewing Documents
Source: https://support.lilt.com/kb/reviewing-documents



[LILT Translate](/kb/introduction-to-lilt-translate) has a range of tools that provide a streamlined workflow for document reviewers. This article outlines the tools and workflow of a reviewer using LILT.

Before a reviewer can access and begin working on a document, a project manager needs to assign the reviewer to the document. The reviewer can then [accept the document assignment](/kb/accepting-document-assignments) and begin reviewing.

## Reviewing documents

When a reviewer opens a document, it will load LILT Translate in Review mode. The 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.

When opening a document in Review mode, if it has not been marked as `Done` in Translation, the Reviewer will be warned via a popup, and a `Translation in progress` icon will be displayed in the top-right corner of LILT Translate.

<Frame>
  <img />
</Frame>

The role of a reviewer is to review all the segments of a document that have been translated. 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 review workflow. The most important tools for reviewers to know are the [segment editor](/kb/introduction-to-lilt-translate), [Quality Assurance Checks](/kb/quality-assurance-tools), and [hotkeys.](/kb/hotkeys)

When reviewing a segment, if there are any issues with the translation, the reviewer makes the necessary changes and [adds an error flag/annotation](/kb/segment-comments) to the segment.

*Please note: If the organization setting for Error Logging is turned on, error logging is mandatory when a reviewer changes anything in the target segment. Please reference the *[*Organization Settings*](/kb/organization-settings)* page for more information.*

After a segment has been reviewed (whether modified or not), the reviewer clicks `Accept` (shortcut: `Ctrl`+`Enter`) in the bottom-right of the segment to indicate that the segment has been reviewed. Once accepted, the segment can still be unaccepted and modified in 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 reviewers to accept the segment in Review mode.*

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

To learn about who is given authorship for a segment's translation, see the [Data Source Memory Matching](/kb/translation-memory-matching) article.

## Marking the document as done in Review mode

When all segments in a document have been accepted by the reviewer, a `Mark as done` popup will appear, allowing the reviewer to mark that the document has been completed in Review mode.

<Frame>
  <img />
</Frame>

If a manager has enabled mandatory[Auto Review](/kb/mandatory-batch-qa-check), the reviewer will need to run Auto Review (which runs a QA check on all the document's segments) before the document can be marked as done.

Documents can also be marked as done from the `File` tab.

<Frame>
  <img />
</Frame>


# Segment Comments and Error Flagging
Source: https://support.lilt.com/kb/segment-comments



[LILT Verify](/kb/introduction-to-lilt-translate) is equipped with an easy-to-use comment system for translators and reviewers. Comments are intended to help explain or accompany direct changes to segments rather than dictate changes to the translation itself. This comment system facilitates organized and efficient communication to save everyone time while processing documents. This article discusses ways that translators and reviewers can make the most of the LILT comment system.

### Comment scope

Comment data is only accessible from the document and Project the comment was made in. Comment data is not added to the translated content as any kind of metadata. To share comment information outside a Project, a manager can download and share the Project's [Revision Report](/kb/how-to-read-revision-reports).

### Comments in Translate mode

In Translate mode, comments can be added to any segment by clicking the `Add note` button next to the desired segment.

<Frame>
  <img />
</Frame>

Translators can utilize segment comments to communicate with reviewers and managers, add notes, make to-do lists, and create reminders. If there are multiple translators, comments can be used as a space for discussion among translators.

Multiple comments can be made on one segment and are kept in a thread, allowing you to see the entire comment history.

Comments can contain clickable URLs. As an example, sometimes you may want to link to web pages with term definitions.

If a segment has any comments, it will display the number of comments on the `Add note` button so it’s easy to tell which segments need attention.

<Frame>
  <img />
</Frame>

If your comment is about an issue that has been resolved, you can click the `Resolve` button.

<Frame>
  <img />
</Frame>

to remove your comment from the thread, and the comment will no longer show in the Translate stage.

If you need to edit or delete your comment, you can bring up those options by clicking the `More actions` button on the comment.

### Error flagging in Review and Secondary Review mode

In Review and Secondary Review mode, reviewers can flag any segment as having an error by clicking the "`Add/View errors"`button.

<Frame>
  <img />
</Frame>

To add an error, the reviewer will need to select an error category, sub-category, severity, and enter a comment about the error. Once completed, click the "`Add"` button.

<Frame>
  <img />
</Frame>

*Please note: If the organization setting for Error Logging is turned on, error logging is mandatory when a reviewer changes anything in the target segment. Please reference the [Organization Settings](/kb/organization-settings) page for more information.*

**Error categories**: Accuracy; Linguistic Conventions; Terminology; Style; Design; Locale convention; Audience appropriateness; Source

**Error sub-categories**:

* *Accuracy*: Addition, Omission, Mistranslation, Over-translation, Under-translation, Untranslated, Improper TM match, Do not translate

* *Linguistic Conventions*: Punctuation, Spelling, Grammar, Inconsistency, Character encoding, Unintelligible

* *Terminology*: Inconsistent with termbase, Inconsistent use of terminology, Wrong term

* *Style*: Awkward, Company style, Inconsistent style, Third-party style, Unidiomatic, Language register,Inconsistent with external reference

* *Design*: Local formatting, Markup, Missing text, Truncation/text expansion, Link/cross reference, Character formatting, Layout

* *Locale Convention*: Address format, Date format, Currency format, Measurement format, Shortcut key, Telephone format, Number format, Time format

* *Audience appropriateness*: Culture Specific Reference, Offensive

* *Source*: Source error

**Error Severities:** Critical, Major, Minor, Neutral, Kudos, and RepeatedError

If your error flag is about an issue that has been resolved, you can click the `Resolve` button to remove your error flag from the thread, which means it will no longer show in the Review stage.

<Frame>
  <img />
</Frame>

If you need to edit or delete your error flag, you can bring up those options by clicking the `More actions` button on the comment.

If a segment has any error flags, it will display the number of error flags on the `Add/View errors`button so it’s easy to tell which segments need attention.

<Frame>
  <img />
</Frame>

Errors are compiled into a [Revision Report](/kb/how-to-read-revision-reports) that is delivered to the translators at the end of the project. The report displays the source text and target text so translators can learn from errors made during the project.

## Error Flagging 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 change. For example, if there was a shift in meaning and also a typo, use category “Accuracy” and severity “Major”. Please see the [Error Typology](/kb/segment-comments#SegmentCommentsandErrorFlagging-ErrorTypology) table below for definitions of severities, categories, and sub-categories.

**What should I do if I have a repeated error?**

The first time you see an error, mark it as usual: using a category, sub-category, and severity. The second time onward, use the same category/sub-category, but use the severity *Repeated Error*. This should be done if:

* The segments are identical

* 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.

Please see the definition for *Repeated Error* in the Error typology table below for a complete definition.

## Error Typology

<table>
  <tbody>
    <tr>
      <th>
        <p><strong>Error Severities</strong></p>
      </th>
    </tr>

    <tr>
      <td>
        <p>Critical</p>
      </td>

      <td>
        <p>This is the severest category type available, weighing above Major in its extreme severity. Usage is strictly restricted to only the most extremely severe of errors, which would render the content unfit for use. </p>
        <p><em>Example: The error renders the target text unfit for purposes or incomprehensible, or poses a risk for serious physical, financial or reputational harm.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Major</p>
      </td>

      <td>
        <p>An error that changes the core meaning significantly. It is likely to seriously mislead or confuse the user.</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Minor</p>
      </td>

      <td>
        <p>An error that doesn’t lead to loss of meaning and wouldn’t confuse or mislead the user, but would be noticed.</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Neutral (Not an Error)</p>
      </td>

      <td>
        <p>Used for edits that are not error corrections, but reflect an evaluator’s choice or preference.</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Repeated Error</p>
      </td>

      <td>
        <p>If the same, identical error recurs, record the 2nd occurrence onwards as 'Repeated'. For example, if dates have been written as MM/DD/YYYY consistently through the text, as opposed to DD/MM/YYYY, record the 2nd instance onwards as a repeated error.</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Kudos</p>
      </td>

      <td>
        <p>Used to highlight a particularly good translation or one that has a high positive impact.</p>
      </td>
    </tr>
  </tbody>
</table>

<table>
  <tbody>
    <tr>
      <th>
        <p><strong>Error Categories and Sub-Categories</strong></p>
      </th>
    </tr>

    <tr>
      <td>
        <p>Accuracy</p>
      </td>

      <td>
        <p>Addition</p>
      </td>

      <td>
        <p>Target content that includes content not present in the source.</p>
        <p><em>Example: A translation includes portions of another translation that were inadvertently pasted into the document.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Omission</p>
      </td>

      <td>
        <p>Errors where content is missing from the translation that is present in the source.</p>
        <p><em>Example: A paragraph present in the source is missing in the translation.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Mistranslation</p>
      </td>

      <td>
        <p>Target content that does not accurately represent the source content.</p>
        <p><em>Example: A source text states that a medicine should not be administered in doses greater than 200 mg, but the translation states that it should be administered in doses greater than 200 mg (i.e., negation has been omitted).</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Over-translation</p>
      </td>

      <td>
        <p>Target text that is inappropriately more specific than the source text.</p>
        <p><em>Example: The source text refers to a boy, but is translated with a word that applies only to young boys rather than the more general term.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Under-translation</p>
      </td>

      <td>
        <p>Target text that is inappropriately less specific than the source text.</p>
        <p><em>Example: The source text uses words that refer to a specific type of military officer, but the target text refers to military officers in general. </em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Untranslated</p>
      </td>

      <td>
        <p>Errors occurring when a text segment that was intended for translation is left untranslated in the target content.</p>
        <p><em>Example: A sentence in a Japanese document translated into English is inappropriately left in Japanese.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Improper TM match</p>
      </td>

      <td>
        <p>A match from the translation memory has been left unedited in the target text, where it does not accurately reflect the source.</p>
        <p><em>Example: A 99% match from the translation memory has been inserted into the translation but has not been edited to include the extra tag that exists in the new source text.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Non-Translatables</p>
      </td>

      <td>
        <p>Errors occurring when a text segment or even a whole section of a text marked in the specifications as “Do not translate!” is translated in the target text.</p>
        <p><em>Examples: </em></p>

        <ul>
          <li>
            <p><em>A marketing slogan for worldwide use is intended to remain in English. </em></p>
          </li>

          <li>
            <p><em>A product name should not be translated because it is supposed to remain in English.</em></p>
          </li>
        </ul>
      </td>
    </tr>

    <tr>
      <td>
        <p>Linguistic Conventions</p>
      </td>

      <td>
        <p>Punctuation</p>
      </td>

      <td>
        <p>Punctuation incorrect for the locale or style.</p>
        <p><em>Example: An English text uses a semicolon where a comma should be used.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Spelling</p>
      </td>

      <td>
        <p>Error occurring when the letters in a word in an alphabetic language are not arranged in the normally specified order.</p>
        <p><em>Example: The German word Zustellung is spelled Zustetlugn.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Grammar</p>
      </td>

      <td>
        <p>Error that occurs when a text string (sentence, phrase, other) in the translation violates the grammatical rules of the target language.</p>
        <p><em>Example: An English text reads: The man was seeing the his wife.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Unintelligible</p>
      </td>

      <td>
        <p>Text garbled or incomprehensible, perhaps due to conversion or other processing errors.</p>
        <p><em>Example: The following text appears in an English translation of a German automotive manual: “The brake from whe this કુતારો િસ S149235 part numbr,,.”</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Character encoding</p>
      </td>

      <td>
        <p>Error occurring when characters garbled due to incorrect application of an encoding.</p>
        <p><em>Example: A text document in UTF-8 encoding is opened as ISO Latin-1, resulting in all upper ASCII characters being garbled.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Inconsistency</p>
      </td>

      <td>
        <p>Inconsistency in Linguistic Conventions can arise when a translation fails to consistently apply the rules and stylistic preferences of the target language. This may include variations in terminology, grammatical structures, punctuation, capitalization, and idiomatic expressions.</p>
        <p><em>Example: Irregular application of capitalization rules, such as capitalizing certain nouns in one instance but not in others, contrary to the conventions of the target language.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Terminology</p>
      </td>

      <td>
        <p>Inconsistent with termbase</p>
      </td>

      <td>
        <p>Use of a term that differs from term usage required by a specified termbase or other resource.</p>
        <p><em>Examples:</em></p>

        <ul>
          <li>
            <p><em>A termbase specifies that the term USB memory stick should be used, but the text uses USB flash drive.</em></p>
          </li>

          <li>
            <p><em>A French text translates English e-mail as email but terminology guidelines mandated that courriel be used.</em></p>
          </li>

          <li>
            <p><em>The English musicological term dog is translated (literally) into German as Hund instead of as Schnarre, as specified in a terminology database.</em></p>
          </li>
        </ul>
      </td>
    </tr>

    <tr>
      <td>
        <p>Inconsistent use of terminology</p>
      </td>

      <td>
        <p>Use of multiple terms for the same concept in cases where consistency is desirable.</p>
        <p><em>Example: The text refers to a component as the brake release lever, brake disengagement lever, manual brake release, and manual disengagement release.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Wrong term</p>
      </td>

      <td>
        <p>Use of a term that is not the term a domain expert would use or because it gives rise to a conceptual mismatch. </p>
        <p><em>Example: The word 'river' in an English source text is translated into French as 'rivière' . But the river in question flows into the sea, not into a lake or another river, so the correct French translation should have been ' fleuve'.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Style</p>
      </td>

      <td>
        <p>Awkward style</p>
      </td>

      <td>
        <p>Style involving excessive wordiness or overly embedded clauses, often due to inappropriate retention of source text style in the target text.</p>
        <p><em>Example: A text is written with many embedded clauses and an excessively wordy style. While the meaning can be understood, the text is unnatural and difficult to follow.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Company style</p>
      </td>

      <td>
        <p>Errors occurring where the text violates company-specific style guidelines.</p>
        <p><em>Example: Company style states that passive sentences may not be used, but the text uses passive sentences.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Inconsistent style</p>
      </td>

      <td>
        <p>Style that varies inconsistently throughout the text, often due to multiple translators contributing to the target text.</p>
        <p><em>Example: One part of a text is written in a light and terse style while other sections are written in a more verbose style.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Third-party style</p>
      </td>

      <td>
        <p>Errors occurring when the text violates a third-party style guide.</p>
        <p><em>Example: Specifications stated that English text was to be formatted according to the Chicago Manual of Style, but the text delivered followed the American Psychological Association style guide.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Unidiomatic style</p>
      </td>

      <td>
        <p>Style that is grammatical, but unnatural, often due to interference from the source language.</p>
        <p><em>Example: The following text appears in an English translation of a German letter: “We thanked him with heart” where “with heart” is an understandable but non-idiomatic rendering, better stated as “heartily”.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Inconsistent with external reference</p>
      </td>

      <td>
        <p>Errors occurring when text fails to conform to an external resource.</p>
        <p><em>Examples:</em></p>

        <ul>
          <li>
            <p><em>A translation refers to a court decision but does not accurately reflect the language of the decision.</em></p>
          </li>

          <li>
            <p><em>A target text translates text that should have been quoted from an existing text.</em></p>
          </li>
        </ul>
      </td>
    </tr>

    <tr>
      <td>
        <p>Register</p>
      </td>

      <td>
        <p>Errors occurring when a text uses a level of formality higher or lower than required by the specifications or by common language conventions.</p>
        <p><em>Example: A formal letter uses contractions, colloquialisms and expressions characteristic of spoken rather than written language, and thus makes a less serious impression than intended.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Design</p>
      </td>

      <td>
        <p>Layout</p>
      </td>

      <td>
        <p>Inappropriate presentation format of paragraphs, headings, graphical elements, and user interface elements and their arrangement on a form, page, website, or application screen.</p>
        <p><em>Example: A fully justified paragraph was copied from one document and pasted into another where surrounding paragraphs were flush left, ragged right, creating a visual mismatch.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Character formatting</p>
      </td>

      <td>
        <p>Inappropriate application of any glyph variation that is applied to a character or string of characters, such as font, font style, font color, or font size.</p>
        <p><em>Examples:</em></p>

        <ul>
          <li>
            <p><em>A corporate style guide specifies that body text in technical publications should be set in a serif font, but body text in advertising and public reports should be set in a sans serif font. </em></p>
          </li>

          <li>
            <p><em>The body text for an annual report was incorrectly set using the serif font specified for technical publications.</em></p>
          </li>
        </ul>
      </td>
    </tr>

    <tr>
      <td>
        <p>Markup tag</p>
      </td>

      <td>
        <p>Incorrect markup tag or tag component.</p>
        <p><em>Example: Markup is used incorrectly, resulting in incorrect formatting.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Missing text</p>
      </td>

      <td>
        <p>Existing text missing in the final laid-out version.</p>
        <p><em>Example: A translation is complete, but during DTP a text box was inadvertently moved off the page and so the translated text does not appear in a rendered PDF version.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Truncation/text expansion</p>
      </td>

      <td>
        <p>Target text that is longer or shorter than allowed or where there is a significant and inappropriate discrepancy between the source and the target text lengths.</p>
        <p>Examples:</p>

        <ul>
          <li>
            <p>The German translation of an English string in a user interface runs off the edge of a dialogue box and cannot be read.</p>
          </li>

          <li>
            <p>An English sentence is 51 characters, but its German translation is 253 characters and does not fit in the available space.</p>
          </li>

          <li>
            <p>A source text is 300 characters but the translation is 15 characters, indicating a likely problem.</p>
          </li>
        </ul>
      </td>
    </tr>

    <tr>
      <td>
        <p>Link/cross-reference</p>
      </td>

      <td>
        <p>Incorrect or invalid (no longer active) link or URI.</p>
        <p><em>Example: An HTML file contains numerous links to other HTML files; some have been updated to reflect the appropriate language version while some point to the source language version.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Locale formatting</p>
      </td>

      <td>
        <p>Errors or inconsistencies in the visual or structural presentation of translated content that fails to align with the locale-specific conventions or expectations. These issues are distinct from text-specific translation errors and focus on the design aspects that influence how the content is perceived and understood in the target locale.</p>
        <p><em>Example: Failing to adapt the layout and orientation of content for right-to-left languages like Arabic or Hebrew, leading to awkward or confusing user experiences.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Locale convention</p>
      </td>

      <td>
        <p>Address format</p>
      </td>

      <td>
        <p>Inappropriate address format for its locale.</p>
        <p><em>Example: An online form translated from English to Hindi requires a house number even though many addresses in India do not include a house number, or the postal code is in the wrong position for a given locale.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Number format</p>
      </td>

      <td>
        <p>Inappropriate number format for its locale.</p>
        <p><em>Example: US-English target text retains German-style use of full stops and commas.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Date format</p>
      </td>

      <td>
        <p>Inappropriate date format for its locale.</p>
        <p><em>Example: A German text has 06/07/2012 for 7 June 2012 instead of 07.06.2012.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Currency format</p>
      </td>

      <td>
        <p>Incorrect currency format for its locale.</p>
        <p><em>Example: A text dealing with business transactions from English into Hindi assumes that all currencies will be expressed in simple units, while the convention in India is to give such prices in lakh rupees (100,000 rupees).</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Measurement format</p>
      </td>

      <td>
        <p>Inappropriate measurement format for its locale.</p>
        <p><em>Example: A text created for use in France uses feet and inches and Fahrenheit temperatures.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Shortcut key</p>
      </td>

      <td>
        <p>Shortcuts in a translated software product do not conform to locale expectations or make no sense for the locale.</p>
        <p><em>Example: A software product uses CTRL-S to save a file in Hungarian, rather than the appropriate CTRL-M (for menteni).</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Telephone format</p>
      </td>

      <td>
        <p>Inappropriate telephone form for telephone numbers for its locale.</p>
        <p><em>Example: A German text presents a telephone number in the format (xxx) xxx - xxxx instead of the expected 0xx followed by a group of digits separated into groups by spaces.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Time format</p>
      </td>

      <td>
        <p>Error involving incorrect time format for its locale. </p>
        <p><em>Example: Unless specified as using a 24 hour clock, US time formats report time after noon using 12-hour notation (for instance, '7:54:12 pm' instead of '19:54:12' used in many other countries.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Audience appropriateness</p>
      </td>

      <td>
        <p>Culture specific reference</p>
      </td>

      <td>
        <p>Errors where content inappropriately uses a culture-specific reference that will not be understandable to the intended audience.</p>
        <p><em>Example: An English text refers to steps in a process as First base, Second base, and Third base, and to successful completion as a Home run and uses other metaphors from baseball. These prove difficult to translate and confuse the target audience in Germany.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Offensive</p>
      </td>

      <td>
        <p>Content that breaches commonly accepted standards of decent and proper speech, and is hence likely to offend the intended audience or other likely readers. </p>
        <p><em>Example: A source text refers to bacon as an example of a tasty food, but the reference is offensive when translated into Arabic.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Source</p>
      </td>

      <td>
        <p>Source error/ambiguity</p>
      </td>

      <td>
        <p>An error introduced due to an error or ambiguity in the source text.</p>
      </td>
    </tr>
  </tbody>
</table>


# Segment Context
Source: https://support.lilt.com/kb/segment-context



LILT's Segment Context sidebar provides linguists with a range of tools to assist with translation. Utilizing these tools helps to maintain consistent translations across documents that share a Data Source.

The Segment Context sidebar displays the following information for the active segment:

* Any Translation Memory (TM) matches
* Any Termbase (TB) matches
* Suggested translation (powered by LILT's Contextual AI Engine)
* Segment metadata (e.g. character limits)

<Frame>
  <img alt="" />
</Frame>

## TM match results

If the active segment matches with any TM entries in the associated Data Source, the matching TM entries are displayed.

TM entry display order:

* **reviewed** (green `TM` icon) / **unreviewed** (gray `TM` icon)
* **match percent** (matches below 75% are not displayed)
* **most recently updated**

***Note that while TM entries in the Segment Context sidebar are displayed in order of reviewed/unreviewed status, the reviewed/unreviewed status does not affect TM match prioritization or model training.***

If there are any duplicate TM entries, this will be displayed as an `identical results` dropdown. Click on the dropdown to display the `author` and `time updated` data for each of the identical entries.

Use keyboard shortcut “Ctrl + Shift + S” to insert the top TM entry into the segment editor.

<Frame>
  <img alt="" />
</Frame>

## TB match results

Matching TB entries are displayed in `Segment context` sidebar. If a source term has more than one approved target term, each is shown as a separate match (up to the 4 most recent).

<Frame>
  <img alt="" />
</Frame>

**Note that terms must be been marked as reviewed to be able to show up as matches.**

As described in the [Terminology](/kb/terminology) article, new TB entries can be added directly from inside [LILT Verify](/kb/introduction-to-lilt-translate) by clicking the `Add New` button.

### TB entry metadata

To view TB entry metadata, click on the term or the info icon.

<img alt="Screenshot 2026 10 01 At 2 41 52 Pm" />

When importing files, LILT looks for and imports metadata based on common patterns, such as Excel cell locations, JSON keys, web page property types, etc. If your file is highly customized or provides metadata in an alternate method, that metadata may not show up on the Segment Metadata section of the Segment Context sidebar. Metadata fields can also be added inside the LILT application, as described in the following articles:

* [Managing Termbase and Translation Memory Entries](/kb/managing-termbase-and-translation-memory-entries)
* [Data Source Settings](/kb/memory-settings)

Metadata typically is structured into relevant information for a given word or phrase in regard to the part of speech, participle, case, as well as links to image context.

## Contextual AI result

TheContextual AI result displayed in the Segment Context sidebar is the same as the translation suggestion displayed under the segment when the target text is empty.

The translation [suggestion](/kb/machine-translation) is generated by the trained Contextual AI model and the associated Data Source.

<Frame>
  <img alt="" />
</Frame>

### Opening, closing and resizing the sidebar

The sidebar sits on the right of the editor, next to an icon rail.

* **Close:** click the active rail icon. The sidebar collapses to the rail and the segment editor expands to fill the space.
* **Open:** click any rail icon to open the sidebar to that tab.
* **Resize:** drag the sidebar's left edge to make it wider or narrower. This is especially helpful when reviewing the style guide or concordance, where a larger viewing pane is often needed. The width resets to the default when you reload the page.

The editor expands when the sidebar is closed in both default and split view.


# Segment Deletion & Document Management
Source: https://support.lilt.com/kb/segment-deletion-document-management



At times, you may want to delete a document in a project. The following FAQs describes the security model of document deletion and implications to translations.

## What are the implications of deleting a document?

Deleting a document from a Project also deletes the translations in that document from the Project's associated Data Source. In other words, translations in a document are no longer available via memory matches from the data source once the document is deleted.

## If a document is deleted, are all segments removed?

Yes, although it is a "soft delete" in which the rows are marked as deleted and become unavailable to the application.

## If segments are deleted, are they removed from the Data Source?

The segments are still trained into the Contextual AI model. However, they will no longer be available as memory matches from the data source.

## What are the benefits, if any, of keeping documents in the system?

Retaining translated documents improves translation speed by offering memory matches from the data source and Contextual AI suggestions during translation. Additionally, translations from retained documents will continue to be returned via the Concordance search.

## Once a document is deleted, are the contents retained anywhere?

Yes. Segment data is still present in the database (marked as deleted). The imported and exported documents, along with intermediate processing artifacts, remain in persistent storage.

## Can a file be attached to multiple projects?

A document can only be attached to a single project, but the same file could be uploaded as a document across multiple projects.

## How do I permanently remove segments from the Data Source and the LILT Platform?

Hard-delete is an available option for self-managed customers only. When enabled:

* Deleting a document permanently removes the document and its relevant segment information from the system.

* Deleting a project permanently removes the project's documents and relevant segment information from the system.

Note that segment data is also stored in the associated Data Source. Deleting a project or document doesn't delete the associated Data Source entries (since Data Sources can be attached to multiple projects). To remove all traces of project segment content from the system, the associated Data Source entries also must be deleted.


# Segment State Indicators
Source: https://support.lilt.com/kb/segment-state-indicators



The segment state indicators within [LILT Verify](/kb/introduction-to-lilt-translate) display the state of each segment to translators and reviewers at a glance, allowing them to spend their time efficiently when working within LILT Verify.

## Translation indicators

When a translator confirms a segment, a \*\*single checkmark icon \*\*is displayed on the left side of the confirmed segments. This icon indicates that the segment is confirmed and ready for review. Unconfirmed segments do not have any checkmarks.

<Frame>
  <img />
</Frame>

Confirmed segment state

## Review indicators

Once a reviewer starts working on the document, they will see segments with **single checkmarks**, indicating that those segments are ready for review. When a reviewer accepts a segment, the icon will convert to **double checkmarks in a solid green circle**.

<video />

Review segment state

## Locked segment state

You may encounter locked segments during your review. For example, if [Review Sampling](/kb/review-sampling) is enabled, segments that are not included in the review sample are marked with a **padlock icon in a gray circle**.

<Frame>
  <img />
</Frame>

Locked segments from Review Sampling

Organizations may allow linguists to unlock and update locked segments during the Review workflow stage. This is intended as a safety valve specifically if errors are spotted during a Review so you can quickly and easily correct any errors present. To unlock a segment, click on the unaccept button. Make any necessary edits and re-accept the segment.

*Please note: If the segment you unaccepted was an exact match, an* <img /> *icon will appear and share that information upon hover.*

<video />

Unlocking and updating locked segments


# Single Sign On (SSO) For LILT.com
Source: https://support.lilt.com/kb/single-sign-on-sso-for-lilt-com



LILT platform customers can use Single Sign-On (SSO) to sign in using their organization's identity provider. SSO simplifies account management and reduces password fatigue.

**Note:** User accounts must exist in LILT before SSO authentication, unless auto-provisioning is configured (see SAML Setup section).

## Google SSO

LILT platform users can sign in using their Google account.

After receiving an invitation from your organization, you can create an account using Google Sign-On.

If you have an existing LILT account with traditional username/password authentication, you can access it using Google Sign-On with a matching email address. Both sign-in methods work interchangeably.

## OpenID Connect

LILT supports [OpenID Connect (OIDC)](https://openid.net/developers/how-connect-works/) for SSO authentication. OIDC is a modern authentication protocol built on OAuth 2.0 (IETF RFC 6749 and 6750). It provides a standardized way to verify user identity through an Authorization Server and obtain user profile information. OIDC works with many identity providers including Microsoft Entra ID, Okta, and Amazon.

For setup instructions, see the [OIDC Setup](#openid-connect-oidc-setup) section below.

## Microsoft SSO

LILT supports Microsoft authentication for platform customers. Organizations using Active Directory or Azure credentials can use their existing SSO for LILT.

To set up Microsoft SSO, a user from your organization needs to:

1. Log into LILT.com using Microsoft SSO
2. Complete the consent page

After setup, the SSO app appears under `Enterprise applications` in your Azure Active Directory (AD) or Azure Entra ID, where you can configure access controls.

### Restricting Access

To limit access to specific users:

1. Click on the LILT app in Enterprise applications and navigate to **Manage > Properties**
2. Set `Assignment required` to **Yes**

   <Frame>
     <img alt="" />
   </Frame>

   <Frame>
     <img alt="" />
   </Frame>
3. Add users under **Manage > Users and Groups**

   * Grant access to entire roles, or
   * Add individual users

   <Frame>
     <img alt="" />
   </Frame>

## SAML Setup

To set up a SAML connection with LILT, your organization needs to engage with your LILT customer team. The setup process involves: **LILT Actions**

* LILT creates a new organization configuration with a specific identifier (for example: `customer:okta`)
  * You can choose any name in place of `customer:okta`. This acts as a verification piece to ensure you're connecting to the correct configuration.

**Customer Actions**

* Set up SAML configuration on your organization's side and provide the following to LILT:
  1. The sign-on URL for your application
  2. The entity ID for your application
  3. The metadata file for your application
  4. The certificate for your application
* New user accounts will be provisioned automatically through just-in-time provisioning when users first log in through SAML
* Configure two custom claims in your organization's identity provider:

#### Required Claims for JIT Provisioning

Both of the following claims are **required** for automatic user provisioning:

* **`lilt_api`** - Your organization's API key for organization identification
  * This claim is only required for **new users** being provisioned through JIT. Existing LILT users can authenticate via SSO without this claim.
  * To find your API key:
    1. Log into lilt.com using a non-SSO admin account
    2. Click the gear icon in the lower left corner
    3. Navigate to the API tab
    4. Copy your API key value
  * **Warning:** Do not log into your admin account via SSO, as this will convert it to SSO-only and you will lose access via the regular login page.
  1. **Numeric role ID** (e.g., `4`) — matches by role ID
  2. **Internal role name** (e.g., `Administrator`, `Manager`) — exact match, case-sensitive
  3. **Localized display name** (e.g., `External Linguist`, `Korrektor`, `外部担当者`) — case-insensitive match via alias map
  * If `lilt_role` is omitted or does not match any role, the user will be assigned the organization's default role (typically "Customer")
  * This can be configured as either:
    * An individual user attribute in your IdP, or
    * A custom group claim (recommended if most users should have the same role)
  * **Important:** This attribute will override any manual role changes in LILT whenever the user logs in via SSO

#### Technical Configuration Details

When setting up your SAML claims, ensure:

* The `emailaddress` claim should **not** have a namespace value configured
* LILT uses email addresses as usernames in the system
* If your IdP's `user.mail` attribute is not consistently populated, you can use `user.userprincipalname` instead (provided it's formatted as an email address)
* The `lilt_role` attribute supports numeric IDs, exact internal names (case-sensitive), and localized display names (case-insensitive)
* We recommend a phased rollout approach, starting with your admin and 5 test users before migrating all users to the new SSO experience

## OpenID Connect (OIDC) Setup

LILT supports OpenID Connect (OIDC) for SSO, providing a modern alternative to SAML. OIDC is built on OAuth 2.0 and uses JSON Web Tokens (JWT), making it simpler to configure with most modern identity providers.

### How It Works

When a user logs in via OIDC SSO:

1. The user is redirected from LILT to your organization's identity provider
2. The user authenticates with the identity provider (password, MFA, etc.)
3. The identity provider returns an ID token containing user claims to LILT
4. LILT uses the claims to identify, provision, and assign roles/domains to the user

### Setting Up OIDC

To set up an OIDC connection with LILT, your organization needs to engage with your LILT customer team.

**Customer Actions**

1. Create an application registration in your identity provider (e.g., an App Registration in Microsoft Entra ID, or an Application in Okta)

2. Provide the following to LILT:

   * **Discovery URL** (preferred) — your IdP's `.well-known/openid-configuration` endpoint. This is a single URL that contains all the configuration LILT needs.
   * **Client ID** — the application's client identifier
   * **Client Secret** — the application's client secret

   If your IdP does not support a discovery URL, provide these endpoints individually:

   * Authorization endpoint
   * Token endpoint
   * UserInfo endpoint
   * JWKS URI
   * End session endpoint

3. Configure the custom claims listed below in your identity provider

4. Ensure the custom claims are included in the **ID token** (not only in the UserInfo response)

**LILT Actions**

* LILT creates a new organization configuration with a specific identifier (for example: `customer-name`)
* LILT configures the connection and provides the **Redirect URI** (callback URL) that you must add to your application's allowed redirect URIs

### Required Claims for OIDC

The same custom claims used for SAML apply to OIDC:

* **`lilt_api`** (required for JIT provisioning) — Your organization's API key for organization identification
  * To find your API key: log into lilt.com, click the gear icon, navigate to the API tab, and copy your API key
  * Set this as a static claim value — it is the same for all users in the organization
* **`lilt_role`** (recommended) — The user's role within LILT. Accepts three formats:

  | Format | Example | Notes |
  | :- | :- | :- |
  | Numeric role ID | `"4"` | Most reliable — never changes |
  | Internal role name | `"Agency Translator"` | Case-sensitive, must match exactly |
  | Localized display name | `"External Linguist"` | Case-insensitive |

  If omitted or unrecognized, the user receives the default role.
* **`lilt_domains`** (optional) — Automatic domain assignment. See the [Set SSO Users' Domains on Account Creation](#set-sso-users-domains-on-account-creation) section below for details.

## **Set SSO Users’ Domains on Account Creation**

Many enterprises have multiple teams using LILT, each with a unique set of needs. To support this, our Domains feature allows administrators to segment their workflows by assigning resources—such as users, models, and preferences—to specific domains. You can read more about this feature under [Domains](https://support.lilt.com/kb/lilt-domains#domains).

This section explains how to configure automatic domain assignment for users via OIDC claims during SSO authentication.

Supported Identity Providers

* WSO2 Identity Server (WSO2 IS)
* Asgardeo
* Any OIDC-compliant identity provider that supports custom claims

### Claim Configuration

To utilize this feature, you must configure the `lilt_domains` claim within your Identity Provider (IdP).

**Claim Name**

`lilt_domains`

**Claim Format**

The claim supports multiple formats to accommodate different user store configurations:

| Format | Example | Description |
| :- | :- | :- |
| Single value | `"Marketing"` | Assign user to one domain |
| Comma-separated | `"Marketing,Sales,Legal"` | Assign user to multiple domains |
| JSON array | `["Marketing", "Sales"]` | Assign user to multiple domains |
| Domain ID | `"123"` | Reference domain by numeric ID |
| Mixed | `"Marketing,456,Sales"` | Combine names and IDs |

**Note:** Leading and trailing whitespace is trimmed from each value. If a domain cannot be found, it is skipped without causing an error — partial matches are allowed.

**Claim Scope**

The `lilt_domains` claim must be included in the **profile** scope (or a custom scope that is requested during the authentication process).

**Identity Provider Setup**

WSO2 Identity Server / Asgardeo

1. Create the claim
   1. Navigate to **Claims > Add Local Claim**
   2. Claim URI: `http://wso2.org/claims/lilt_domains`
   3. Display Name: `LILT Domains`
   4. Mapped Attribute: Configure this based on your specific user store
2. Add to OIDC scope
   1. Navigate to **OIDC Scopes > profile** (or create a custom scope)
   2. Add the `lilt_domains` claim to the scope
3. Map to OIDC claim
   1. Navigate to **Claims > Add External Claim**.
   2. Dialect: `http://wso2.org/oidc/claim`.
   3. External Claim URI: `lilt_domains`.
   4. Mapped Local Claim: Select the local claim created in Step 1.
4. Assign values to users
   1. Edit user profiles to manually set the `lilt_domains` attribute.
   2. Alternatively, configure attribute mapping from your user directory (such as LDAP or AD).

### Domain Resolution

When a user authenticates, LILT resolves domains in the following order:

1. **Numeric values** (e.g., `"123"`) are treated as **domain IDs**.
2. **Non-numeric values** (e.g., `"Marketing"`) are treated as **domain names**.

**Limitation on Purely Numeric Domain Names**: Domains with purely numeric names cannot be assigned via the `lilt_domains` claim. If a domain is named `"123"`, specifying `"123"` in the claim will attempt to find a domain with *ID* 123, not a domain *named* "123".

* **Workaround:** Rename such domains to include at least one non-numeric character (e.g., `"123-dept"` or `"Dept 123"`).

### Behavior

**On User Login** **On First Login (JIT Provisioning)**

When a **new user** is provisioned via SSO with a `lilt_domains` claim:

1. LILT parses the claim value into individual domain identifiers
2. Each identifier is resolved to a domain within the user's organization
3. The user is assigned to all successfully resolved domains
4. Domains that cannot be found are logged but do not cause authentication failure

**Note:** Domain assignments via the `lilt_domains` claim are only applied when a user is first provisioned. Subsequent SSO logins do not update domain assignments. To change domain assignments for existing users, update them directly in LILT.

**Domain Assignment**

* Users are **added** to the specified domains
* Existing domain assignments are preserved
* The claim does not **remove** users from domains not listed

### Related Claims

| Claim | Purpose |
| :- | :- |
| `lilt_role` | Assign user to a specific role |
| `lilt_api` | Associate user with an API key (determines organization) |
| `lilt_domains` | Assign user to domains |

## Troubleshooting

### JIT Provisioning Is Not Working

If new users cannot log in or are not being automatically provisioned:

1. **Verify both required claims are configured** in your IdP:
   * `lilt_api` must contain your organization's API key
   * `lilt_role` must contain a valid role identifier (numeric ID, internal name, or localized display name)
2. **Check for common configuration issues:**
   * The `emailaddress` claim should not have a namespace configured
   * The `lilt_role` value is case-sensitive and must match exactly
   * Ensure users are accessing the SSO login via the SSO button on `/signin`
3. **Confirm existing vs. new user behavior:**
   * Existing LILT users can authenticate via SSO even without the `lilt_api` claim
   * New users require both `lilt_api` and `lilt_role` claims for JIT provisioning

### Users Are Locked Out After SSO Setup

If admin users lose access to their accounts:

* Admin accounts that log in via SSO are automatically converted to SSO-only
* Once converted, these accounts can only access LILT through the SSO button on `/signin`
* To avoid this, maintain a separate non-SSO admin account for configuration purposes

### Domains Are Not Being Assigned

If users are not being assigned to domains as expected, check the following:

1. **Verify the claim is in the token**
   1. Check your IdP's token preview or debug feature
   2. Ensure `lilt_domains` appears in the userinfo response
2. **Verify scope configuration**
   1. The claim must be included in a scope requested during authentication
   2. Typically, this is the `profile` scope
3. **Check domain exists**
   1. The domain must exist in the user's organization
   2. Domain names are case-sensitive
4. **Check for numeric name conflict**
   1. If using a numeric domain name, rename it to include non-numeric characters

### **Logging**

Domain assignment events are logged with the component `embedded-oidc`. Look for the following entries:

* `"embedded-oidc: Domain not found for lilt_domains claim"`  Indicates the domain could not be resolved.
* `"embedded-oidc: Assigned user to domains"`  Indicates successful assignment

## Frequently Asked Questions

**Is SCIM supported?** Currently, SCIM is not supported. Auto-provisioning is handled through the two custom claims/attributes (`lilt_api` and `lilt_role`) listed in the SAML configuration section. If JIT provisioning is not working:

* Verify both claims are present in your SAML configuration
* Confirm the `lilt_role` value is a valid role identifier (numeric ID, internal name, or localized display name)
* Ensure the `lilt_api` contains your organization's valid API key

**Is SSO a global setting or per user/group?** SSO is configured per user. The LILT platform supports:

* Regular logins via `/signin`
* SSO logins via the SSO button on `/signin`

If a user is configured for SSO and attempts to log in through SSO, then tries to log in as a regular user, the system will deny entry and require SSO login.

For organization-wide SSO implementation, auto-provisioning works as follows:

* If a user doesn't exist in the LILT database, they'll be automatically added when they first log in via SSO
* The user's SAML assertion must include the `lilt_api` claim with your organization's API key (to identify which organization to add them to)
* The user's SAML assertion must include the `lilt_role` claim with a valid role identifier (numeric ID, internal name, or localized display name)
* If either claim is missing or incorrectly configured, JIT provisioning will fail
* Once configured this way, users can only log in via SSO on `/signin`
* Your organization won't need to manually add users to the LILT system

**Does LILT support multiple Azure app connections for SSO for a single domain?** This capability depends on your specific Azure configuration. Each implementation may have unique requirements. Please contact your LILT customer team for guidance on your specific Azure setup.

## See Also

* [<u>WSO2 IS Documentation</u>](https://is.docs.wso2.com/)
* [<u>Asgardeo Documentation</u>](https://wso2.com/asgardeo/docs/)
* [<u>LILT Domains</u>](https://support.lilt.com/kb/lilt-domains)


# Source Highlighting Tool
Source: https://support.lilt.com/kb/source-highlighting-tool



[LILT Verify](/kb/introduction-to-lilt-translate) comes with a source highlighting tool that gives linguists quick access to terminology tools. To open the tool options popup, simply highlight the desired word or phrase in the source text. Once open, click any of the options to perform the corresponding action.

<Frame>
  <img />
</Frame>

Source highlighting tool options:

* **Copy to clipboard:** Copies the highlighted source words to the clipboard.

* \*\*Copy to target: \*\*Copies the highlighted source words into the target text field.

* **Lookup in Segment Context:** Opens the [Segment Context](/kb/segment-context) sidebar, puts the selected source text into the search field, and searches for the text.

* **Lookup in Concordance:** Opens the [Concordance](/kb/concordance) sidebar, puts the selected source text into the search field, and searches for the text.


# Source Text Editing
Source: https://support.lilt.com/kb/source-text-editing



Source text editing allows users to edit the source text of a segment in the LILT Verify.

### How to edit source text

Open a document in the LILT Verify

Click the pencil icon to the right of the segment.

<Frame>
  <img />
</Frame>

Change the segment source text and click ‘Save changes’

<Frame>
  <img />
</Frame>

The Contextual AI suggested target text will update based on changes made to the source text.

### When to edit source text

You can only edit source text if the segment is not confirmed. If you want to edit the source text of a confirmed segment, the user must un-confirm the segment first.

### Who can edit source text

Only users with the permission ‘Segment Source’ are allowed to edit source text. Users assigned to the Administrator, Manager, Translator, or Reviewer role have this permission enabled.


# Split & Merge Segments
Source: https://support.lilt.com/kb/split-merge-segments



[LILT Verify](/kb/introduction-to-lilt-translate) contains functionality to easily split and merge segments, allowing linguists to organize a document's segments as they see best.

When a document is uploaded, LILT processes the source text into segments in a way that aims to maximizethe quality of AI-generated translations. While segments can range in length from a paragraph to a one word header, quality tends to degrade with sentence length, so LILT prefers shorter segments. The segmenter can sometimes make mistakes, but these mistakes can be corrected afterward by manually splitting or merging segments.

The split and merge tools can be accessed at any time by clicking on the `Segment editing tools` button within the segment you want to edit.

<Frame>
  <img alt="" />
</Frame>

Confirmed segments cannot be split or merged. To perform these actions with a confirmed segment, you need to first unconfirm the segment.

## Splitting a segment

1. Click the `Split segment` button to bring up the split segment tool. This tool displays as a vertical marker within the segment.

<Frame>
  <img alt="" />
</Frame>

2. Drag and drop the vertical marker to set the split position. All content before the marker will be kept in the current segment. All content after the marker will be split into a new segment inserted after the current segment.

<Frame>
  <img alt="" />
</Frame>

3. Once the vertical marker is where you want it, click the check mark in the bottom-right to split the segment. You can also cancel by clicking on the `X` button in the top-right.

## Merging segments

Click the `Merge with next segment` button to merge the current segment with the segment below it.

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

Note that LILT does not allow merging of segments that are:

* from different paragraphs in the source text
* from two different cells in a spreadsheet
* two different trans-units in XLIFF files
* already confirmed (to rectify, unconfirm the segments, merge them, and then re-confirm)


# Subtitling and captioning
Source: https://support.lilt.com/kb/subtitling-and-captioning



LILT’s new subtitling and captioning functionality enables end-to-end workflows for subtitling and captioning, bringing major improvements to scalability, efficiency, quality, file security, and user experience. Key highlights include:

* In-context video review during all workflow stages, including Secondary Review, to facilitate translation and quality analysis.
* Integrated subtitling-specific QA checks that are configurable at the organization level.
* Translation for on-screen text, titles, and synopses.

## Creating a subtitling job

To create a subtitling job:

1. Log in to LILT and go to "Translate". Upload your video file and toggle "Receive an expert-verified translation" on.

   <img alt="Image" />
2. We support the following video file types: MP4, MOV, AVI, MKV, WebM, WMV. If you have a subtitle file (e.g., SRT or VTT), you can upload it directly; if not, LILT will extract text using Automatic Speech Recognition (ASR). If you don’t have a third-party provider configured, please configure one in [AI Providers](/kb/3rd-party-llm-support-for-the-contextual-ai-engine). **An ASR provider is mandatory if you're uploading a video without an associated subtitle file; optional if you already have one.**
3. Click "Send for translation". LILT will start background text extraction (status visible in the job view).

## Source Review workflow stage

After file upload and text extraction, the job enters the Source Review workflow stage. When in this stage, each source file needs to be reviewed to proceed to translation, and the project-related tabs are hidden. The Source Review workflow stage can be assigned to a linguist, or can be reviewed internally by LILT. This stage provides:

* Side-by-side viewing and editing of the source extracted text alongside the video.
* Ability to make corrections for timing, segmentation, and transcription quality.
* Adding and removing segments as needed, for example, to capture on-screen text for localization.

The Source text review stage looks similar to CAT, but only has source segments. The purpose of this stage is to compare the text with the source video file, and ensure the caption times and text are accurate.

<Frame>
  <img alt="" />
</Frame>

QA errors will flag issues related to subtitling-specific QA checks (see section below for more information).

To add or delete a segment, click on the Segment Editing tools, and select “Add a new segment” or “Delete this segment”.

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

To insert a line break, click into the top menu, select Insert, and then Line Break. Alternatively, you can use the hotkey shortcut.

<Frame>
  <img alt="" />
</Frame>

### Complete Source Review

Once all segments are confirmed, the source review gets marked as “Reviewed”. You can also accept all segments by going into the “Edit” dropdown and selecting “Accept all segments”.

Once all source files in the job are reviewed, click on “Complete Source Review” to move the job to the next stage in the workflow (e.g. Translate).

<Frame>
  <img alt="" />
</Frame>

Alternatively, you can mark the job as “Source review complete” without marking all documents as “Review completed”.

<Frame>
  <img alt="" />
</Frame>

## Segment states

<Frame>
  <img alt="" />
</Frame>

## Progressing through the workflow

After completing the source text review, the video will move through the rest of the workflow stages. All of the standard CAT functionality will be available, as well as the in-context video for review and the Subtitling QA checks.

## Subtitling QA checks

LILT includes automated QA checks tailored for subtitling, ensuring:

* Compliance with character limits, line lengths, and reading speed guidelines.
* Verification of synchronization between subtitles and video content.
* Detection of overlapping or missing subtitles, and issues with timing or placement.

These QA checks are configurable at the organization level.

<Frame>
  <img alt="" />
</Frame>

### Subtitling QA checks at the org level

Users can set minimum and maximum limits for each of the QA checks, and define whether this is a Blocking issue. If any of these checks are determined as blocking, then linguists will not be able to confirm a segment until the issue is resolved.

These QA checks will flag in Quality Assurance Tools and in Segment QA:

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

## Linguist homepage

Assignments for any subtitling or captioning will appear in the Linguist homepage with the “Video subtitling chip.

<Frame>
  <img alt="" />
</Frame>

## FAQs

1. **What file types are supported for upload and export?**
   * Upload: MP4, MOV, AVI, MKV, WebM, WMV file types up to 2GB.
   * Subtitle download formats: SRT, VTT, ITML, ITT.
2. **Can I submit subtitling jobs through the LILT API?** Yes, job creation, cloud uploads, and retrieval are supported via the LILT API. To submit files through the API, customers will need to update their API endpoints to take advantage of the new size limit released in July by following the instructions for direct cloud uploads in our API documentation: [Uploading files](https://developers.lilt.com/guides/upload/file-upload) and [Instant and Verified uploading guides](https://developers.lilt.com/guides/translate-content/instant-translate#file-upload).
3. **Will captions be burned into my videos automatically?** No, this is currently out of scope. Subtitle files are delivered in one of the following formats: VTT, SRT, ITML, ITT. Advanced post-processing for burnt-in captions and other video post-editing features will be considered in the future.
4. **Can I download the original source video?** Yes, to access the original source video, go to the Source Files tab and select the video file for download.

   <img alt="Screenshot2025 10 08at13 58 23 Pn" />


# Supported File Formats
Source: https://support.lilt.com/kb/supported-file-formats



# Supported File Formats

LILT supports the import and export of a wide range of file types to make your translation workflow as streamlined as possible. All supported formats are listed in the tables below. Any format not in tables below will require [file pre-processing](https://support.lilt.com/kb/supported-file-formats#pre-processing-for-unsupported-file-formats) and do not support instant file translation.

By default, documents are exported in the same format they were uploaded. Exporting to plain text and XLIFF 1.2 is also available (see the Document Downloads section of the [Document Actions](/kb/document-actions) article). All translated and confirmed segments can also be exported in TMX format for each [Data Source](/kb/managing-your-lilt-memories). Supported formats are TMX and SDLTM.

## Desktop publishing formats

| **Extension** | **Format** | |
| - | - | - |
| DOCM, DOCX, DOTM, DOTX, POTM, POTX, PPSM, PPSX, PPTM, PPTX, XLSM, XLSX, XLTM, XLTX, VSDM, VSDX | Microsoft Office 2007+ | |
| ODG, ODP, ODS, ODT, OTG, OTP, OTS, OTT | OpenOffice / LibreOffice | |
| PDF | PDF  **PDF** files — text-based, scanned (image-based), and mixed PDFs — are <br />all handled through a single processing pipeline and export back to PDF format. <br />PDF export is only supported for same-direction language pairs <br />(for example, EN \<> AR is not currently supported as English is Left-To-Right <br />and Arabic is Right-To-Left); in these cases, export is available as TXT only. <br />See [PDF and Image File Translation](https://support.lilt.com/kb/pdf-image-file-translation) for details. | |
| IDML, MIF | Adobe InDesign, FrameMaker | |
| DXF | AutoCAD DXF (text-based only) | |

The following formats have limited or no export support in their original format:

* **Microsoft Office** legacy file formats (**DOC**, **XLS**, and **PPT**) will only support export to TXT or XLIFF. *Note: The import of Microsoft Office legacy file formats is only available via the API.*

## Text and software localization formats

| **Extension** | **Format** |
| - | - |
| CSV, TSV, TXT | Comma-Separated Values, Tab-separated Values, Plain text |
| HTM, HTML, PHP, XML | HTML, PHP, XML |
| MD, MDX | Markdown |
| SRT | SubRip subtitle file |
| TTML | Subtitle and captioning data |
| JSON | JavaScript Object Notation (JSON) |
| JSON + HTML | JavaScript Object Notation (JSON) with embedded HTML |
| YAML, YML | YAML |
| STRINGS | iOS/Mac Strings |
| PROPERTIES | Java properties |
| PO | Portable Object (may require a custom filter) |
| RESX, WIX | .NET resources, Windows installer XML |
| LANG | Skype language files |
| RDF | Mozilla RDF |
| DITA, DITAMAP | DITA |
| ARB | Software Strings (only supported in connectors and API, not UI) |
| VTT | Subtitles |

### Multimedia file type support

Image, audio, and video file support depends on the third-party [AI provider](/kb/3rd-party-llm-support-for-the-contextual-ai-engine) you have configured within LILT.

### Image files

| **Provider** | **Formats accepted** |
| - | - |
| [Amazon Textract](https://aws.amazon.com/textract/faqs/#:~:text=Amazon%20Textract%20currently%20supports%20PNG,%2C%20TIFF%2C%20and%20PDF%20formats.) | PNG, JPEG, TIFF. |
| [Google Cloud Vision](https://cloud.google.com/vision/docs/supported-files) | JPEG, PNG8, PNG24, GIF, Animated GIF (first frame only), BMP, WEBP, RAW, ICO, TIFF |
| Custom AI Provider | Please reach out to your LILT representative to discuss custom AI solutions. |

### Audio/Video files

| **Provider** | **Formats accepted** |
| - | - |
| [Amazon Transcribe](https://docs.aws.amazon.com/transcribe/latest/dg/how-input.html) | AMR, FLAC, M4A, MP3, MP4, Ogg, WebM, WAV.Recommended formats: FLAC, WAV with PCM 16-bit encoding. |
| [Google Cloud ASR](https://cloud.google.com/speech-to-text/docs/encoding) | MP3, FLAC, LINEAR16, MULAW, AMR, AMR\_WB, OGG\_OPUS, SPEEX\_WITH\_HEADER\_BYTE, WEBM\_OPUS |
| [OpenAI Whisper](https://help.openai.com/en/articles/7031512-whisper-audio-api-faq) | M4A, MP3, WEBM, MP4, MPGA, WAV, MPEG |
| [LILT’s Instant Video Dubbing](/kb/instant-video-dubbing) | MP4, MP3, FLAC, LINEAR16, MULAW, AMR, AMR\_WB, OGG\_OPUS, SPEEX\_WITH\_HEADER\_BYTE, WEBM\_OPUS |
| [LILT subtitling and captioning](https://support.lilt.com/kb/subtitling-and-captioning) | MP4, MOV, AVI, MKV, WEbM, WMV<br />Output support: VTT, SRT, TTML, ITT |
| Custom AI Provider | Please reach out to your LILT representative to discuss custom AI solutions. |

## Bilingual formats

| **Extension** | **Format** |
| - | - |
| XLF, XLIFF | XLIFF 1.2 |
| MXLF, MXLIFF | Memsource XLIFF (undocumented format) |
| MQXLIFF | MemoQ XLIFF (undocumented format) |
| SDLXLF, SDLXLIFF | SDLXLIFF (undocumented format) |
| TXML | Wordfast Pro TXML |
| TTX | Trados Tag Editor |

#### Overall limitations

* **Maximum TM file size:** 2GB, applicable to all file types listed in the table above. If submitting a zip file, the uncompressed files must have a total size below 2GB.
* **Large files:** For larger files, zip the TMX file and upload with the extension `.tmx.zip`. TMX files are currently the only type of zipped memory file LILT supports for import.

## Translation Memory (TM)

| **Extension** | **Format** |
| - | - |
| TMX, TMX.ZIP | Translation Memory eXchange |
| SDLTM | SDL Trados Studio Translation Memory (import only) |

### Termbase (TB)

| **Extension** | **Format** |
| - | - |
| TBX | TermBase eXchange (import only) |
| TSV | Tab-delimited text (import only) |
| CSV | Comma-delimited text |
| XLSX | Microsoft Excel 2007+ (import only) |
| TMG | TestMaster (import only) |

#### File limitations for Translation Memory (TM) and Termbase (TB)

* **Maximum TB file size:** 200 MB, applicable to all file types listed in the table above.
* **File structure:** For TSV, CSV, and XLSX Termbases, simply use a two-column format where the first column contains the terms in the source language and the second column the corresponding translations in the target language. See the [Data Source Maintenance Best Practices](/kb/memory-maintenance-best-practices) article for more details.

### Packages

| **Extension** | **Format** |
| - | - |
| SDLPPX | SDL Trados Studio Project Package (import only) |

SDLPPX packages can be imported in the Project's `Documents` window. LILT will upload the first document in the package and will automatically upload any associated SDLTM files into the Data Source.

# Pre-processing for unsupported file formats

If your files are not automatically processable, you will see a “Needs pre-processing” tag when creating your job.

<img alt="Image" />

Once the job has been created, the job will go into the "pre-processing" status and you can track the state of these jobs under the Browse Jobs page. The status will show as "pre-processing".

<img alt="Image" />

### Services customers

* Once these files are submitted for translation, the LILT translation team will work on adapting the files to be able to be processable by the LILT system for translation.
* Once the job is in a processable state, the job status will automatically move to an "In progress" state. From here, the job will follow the localization workflow as defined.

### Platform customers

* If you are a platform customer, an Admin or Manager will need to access the job in pre-processing stage and adapt the file so it can be processable.
* Once the job is in a processable state, the job status will automatically move to an "In progress" state. From here, the job will follow the localization workflow as defined.


# Supported Languages
Source: https://support.lilt.com/kb/supported-languages



LILT provides high-quality machine translation (MT) and human translation services across 1,000+ language pairs. Our capabilities are powered by three distinct generations of LILT-native models (V3.0, V3.5, and V4.0) as well as support for 3rd party translation engines. All LILT-native and 3rd party models used through LILT adapt to your business by learning from completed translations. In addition, LILT-native models learn *in real time* as translations are verified and approved, giving you the highest quality results every time.

The LILT Platform supports the following language features:

* 200+ languages with Adaptive AI and Machine Translation support, most of which can be configured in pairs between any source and target language.
* Unlimited additional languages using Translation Memory (TM) only translation.
* The ability to train models for specific language locales on a per-project basis.

LILT’s [<u>Adaptive AI models</u>](/kb/what-is-interactive-adaptive-mt) are trained at the language level. In addition, each project has an associated [<u>Translation Memory</u>](/kb/translation-memory-matching-and-suggestions) and its own *unique* [<u>Adaptive AI model</u>](/kb/what-is-interactive-adaptive-mt). Both of these adapt to the locale of a project as TM entries are added (either by importing existing TM data or by translating segments in [<u>LILT Translate</u>](/kb/introduction-to-lilt-translate)).

## **Translation Model Generations**

LILT uses different model architectures depending on the language pair. Below is a breakdown of how these models function:

### **LILT V3.0 & V3.5**

Our highest-volume languages are currently served by V3.0 and V3.5 models.

* **Regional Groups:** Our V3.0 models are trained in regional groups as opposed to single language pairs. V3.5 models are available for any two languages within each group. 
* **V3.5 Enhanced Models:** V3.5 models use the context of the entire document to improve naturalness and terminology accuracy.
* **V3.0 Standard Models:** V3.0 models utilize Translation Memory and Termbases for accuracy but focus on sentence-level context.
* **Editor Experience:** V3.0 models produce a translation preview after the first five words are entered and update once the sentence is completed.

### **LILT V4.0**

The V4.0 architecture is our most flexible model to date.

* **Broad Global Coverage:** Our V4.0 models expand LILT’s coverage with support for 70 languages from diverse geographies.
* **Any-to-Any Translation:** Unlike previous generations of LILT models, V4.0 supports translation between any two V4.0 languages, available per customer demand.
* **Real-Time Feedback:** In the LILT CAT editor used by translators and reviewers, V4.0 models provide a word-by-word preview as you type.

### **3rd Party Models**

LILT can integrate 3rd party translation models. However, please note that **only LILT-native models** support our signature real-time training and adaptation.

3rd party model integrations can be configured with Amazon, Google, DeepL, and OpenAI. 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 models allow for [real-time training and adaptation](https://support.lilt.com/kb/what-is-interactive-adaptive-mt#WhatisContextualAI?-ContextualAIisAdaptive).

## Human Verification & TM-Only Translation

* **Human Verification:** We offer human verification for all language combinations for which a LILT or 3rd party model exists.
* **TM-Only Translation:** LILT supports *unlimited* languages using [Translation Memory](/kb/translation-memory-matching-and-suggestions) (TM) only. If a bidirectional translation model does not exist, LILT can still offer human translation services, where translated content is stored in the Translation Memory. As the TM expands, LILT will provide translation suggestions to translators in the CAT tool for segments with matches above 75%, showing the best match available in the TM.

## Support for New Languages

We add new AI-supported languages to the LILT Platform continuously based on three criteria:

* Community and customer demand
* Availability of training data
* Baseline translation quality that is competitive with Google Translate and Microsoft Translator

Contact us at [sales@LILT.com](mailto:sales@lilt.com) to request LILT support for additional languages.

## **LILT V3.0 and V3.5 Supported Languages**

Our 3rd generation models (V3.0 and V3.5) are trained in groups as opposed to single language pairs. Our 3rd generation models can translate directly between *any two languages within each group*. If you need to translate between languages in different groups, contact LILT for more information.

Languages marked with an asterisk (\*) below will be supported with a V3.0 model. The only difference between V3.0 and V3.5 models is that V3.5 models use more context to ensure the highest quality translation.

| **Group** | V3.0 and V3.5 Supported Languages | **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, Belarusian\*, Bulgarian, Czech, Croatian, Lithuanian, Latvian, Polish, Romanian, Russian, Slovak, Slovenian, Albanian, Serbian (Cyrillic), Ukrainian | EN, BE\*, BG, CS, HR, LT, LV, PL, RO, RU, SK, SL, SQ, SR, UK |
| 4 | English, Afrikaans, Danish, German, Greek, Estonian, Finnish, Hungarian, Armenian, Dutch, Norwegian, Swedish, Turkish | EN, AF, DA, DE, EL, ET, FI, HU, HY, NL, NO, SV, TR |
| 5 | English, Arabic, Bengali\*, Kurdish\*, Persian (Farsi), Dari, Gujarati, Hebrew, Hindi, Kannada\*, Malayalam\*, Marathi, Nepali\*, Punjabi\*, Pashto\*, Tamil\*, Telugu\*, Tajik, Urdu | EN, AR, BN\*, CKB\*, FA, FS, GU, HE, HI, KN\*, ML\*, MR, NE\*, PA\*, PS\*, TA\*, TE\*, TG, UR |
| 6 | English, Indonesian, Igbo\*, Javanese\*, Malay, Burmese (Myanmar), Thai, Tagalog (Filipino)\*, Samoan\*, Somali\*, Swahili\*, Vietnamese | EN, ID, IG\*, JV\*, MS, MY, TH, TL\*, SM\*, SO\*, SW\*, VI |

## **LILT V4.0 Supported Languages**

Our V4.0 models enable translation directly between any two languages in the V4.0 list, available per customer demand.

| **V4.0 Supported Languages** | **Codes** |
| - | - |
| Acehnese, Aragonese, Asturian, Awadhi, Azerbaijani (Azeri), Balinese, Banjar, Bashkir, Basque, Bhojpuri, Bosnian, Catalan, Cebuano, Chechen, Chhattisgarhi, English, Esperanto, Faroese, Fijian, Friulian, Galician, Georgian, German (Switzerland), Haitian Creole, Icelandic, Iloko, Irish (Gaelic), Kazakh, Kinyarwanda, Kyrgyz, Lao, Latgalian, Ligurian, Limburgish, Lingala, Luxembourgish, Macedonian, Magahi, Maithili, Malagasy (Plateau), Maltese, Maori, Minangkabau, Mongolian, Odia, Pangasinan, Papiamento, Sardinian, Scottish Gaelic, Serbian, Shona, Sicilian, Silesian, Sindhi, Sinhala, Sotho (Northern), Sotho (Southern), Sundanese, Tok Pisin, Tswana, Tumbuka, Turkmen, Uyghur, Uzbek, Venetian, Waray, Welsh, Xhosa, Yiddish, Zulu | ACE, AN, AST, AWA, AZJ, BAN, BJN, BA, EU, BHO, BS, CA, CEB, CE, HNE, EN, EO, FO, FJ, FUR, GL, KA, DE, HT, IS, ILO, GA, KK, RW, KY, LO, LTG, LIJ, LI, LN, LB, MK, MAG, MAI, PLT, MT, MI, MIN, MN, OR, PAG, PAP, SC, GD, SR, SN, SCN, SZL, SD, SI, NSO, ST, SU, TPI, TN, TUM, TK, UG, UZ, VEC, WAR, CY, XH, YI, ZU |

## **Languages Supported Through 3rd Party Models**

LILT can support the following languages through 3rd party models, available through platform integrations. When used in the LILT platform, these 3rd party models also adapt to your business context, but do not learn in real time as LILT-native models do. Please reference the [<u>LILT Custom Models</u>](https://support.lilt.com/kb/lilt-model-hub) page for more information about 3rd party provider language support.

| **Languages Supported by 3rd Party Models** | **Codes** |
| - | - |
| Acholi, Amharic, Assamese, Bemba, Chichewa (Nyanja), Ewe, Fula (Fulfulde), Ganda, Guaraní, Hausa, Hiligaynon, Hmong, Khmer (Cambodian), Luo, Oromo, Rundi, Swati, Tsonga, Twi (Akan), Wolof, Yoruba | ACH, AM, AS, BEM, NY, EE, FUL, LG, GN, HA, HIL, HMN, KM, LUO, OM, RN, SS, TS, TW, WO, YO |

## Extended Language Support

LILT can support *unlimited* *languages* with human translation services and TM-only workflows. Below is a non-exhaustive list of languages we can work with. [Contact us](mailto:sales@LILT.com) for information about how arranging extended language support for a language not listed here.

| **Languages Supported by Human Translation and TM-Only Workflows** | **Codes** |
| :- | :- |
| Balochi, Chuukese, Gikuyu, Gilaki, Gilbertese (Kiribati), Ibibio, Kiyombe, Koalib, Kosraean, Kuchi, Lozi, Marshallese, Montenegrin, Mooré (Mossi), Nobiin, Norwegian (Nynorsk), Pohnpeian, Sámi (Northern), Tahitian, Tongan, Venda, Yapese, Zaza | BGP, CHK, KI, GLK, GIL, IBB, KG, KIB, KOS, KFR, LOZ, MH, CNR, MOS, FIA, NO, PON, SE, TY, TO, VE, YAP, ZZA |


# System Requirements
Source: https://support.lilt.com/kb/system-requirements-for-translators



This article describes the minimum system requirements for using LILT.

LILT is a cloud-based software. Once LILT is installed by your systems administrator (or an account is provided to you on LILT.com), translators can simply log in to LILT using the browser to start translating.

Please visit our [LILT status page](status.lilt.com) for communication in regards to incidents, outages, and degradation events.

## OS Support

The majority of LILT’s features are operating system agnostic; however, users must fulfill the browser, hardware, and network requirements listed in this article.

## Browser Requirements

LILT is supported on the minimum version (and newer versions) of the browsers listed below.

| **Browser** | **Minimum version supported** |
| - | - |
| Chrome | 79 |

For security and performance reasons, we strongly recommend [running the latest browser version](https://browsehappy.com/?locale=en).

## Hardware Requirements

LILT runs best on systems with at least:

* 1.9 gigahertz (GHz) x86- or x64-bit dual-core processor with SSE2 instruction set.
* 2 GB of RAM (4 GB recommended).
* Display resolution of at least 1024 x 768.

Additionally, LILT can be run on the newer models of Android tablets and iPads.

## Network Requirements

A stable, fast internet connection is essential for using [LILT](/kb/introduction-to-lilt-translate), at minimum with:

* Bandwidth greater than 50 Kbps (400 Kbps).
* Latency under 150 ms.

LILT does not cache work during connection outages. To determine what has been saved, reload LILT after restoration of the connection.


# Tags & Formatting
Source: https://support.lilt.com/kb/tags-formatting



[LILT Verify](/kb/introduction-to-lilt-translate) supports the importing, exporting, and arranging of tagged text. This includes both structural tags (e.g. spacing, line breaks) and formatting tags (e.g. **bold**, *italic*, underline). Other arbitrary tags may not be displayed in LILT Verify, but they will be preserved in the document.

As an example, let's see how LILT would display a Word document containing the following sentence:

This sentence has some bold text.

In LILT Verify, the bolded text will be wrapped in a tag pair. Each tag pair holds information about what kind of formatting should be applied to the text within the tag pair.

<Frame>
  <img />
</Frame>

Tags in the source text are fixed, but tags in the target text can be moved around to allow linguists to ensure the structure and formatting of content is carried over correctly during translation.

This article covers the following topics:

* [Tags overview](/kb/tags-formatting#h_01F3XZVKB947Q7MNV9S6NKXFMQ)

* [Editing tags](/kb/tags-formatting#h_01F3XZVT0JMME25K4Q3HWRW2PS)

* [Tag color indicators](/kb/tags-formatting#h_01F3XZVXZCKZYRAM1T4JY9EZKP)

* [Tag validation](/kb/tags-formatting#h_01F3XZW26BMVK83STNKKR3E3AR)

* [Tag auto-propagation](/kb/tags-formatting#h_01F3XZW655X48736XD7ETV4HJV)

For information on Tags QA, see the [Tags Quality Assurance](/kb/tags-quality-assurance) article.

## Tags overview

Once a segment has been translated and confirmed, LILT will automatically project the source tags into the translated text. For this reason, tags can generally be ignored during translating. *For more information on our Research Team's work on tag projection, see [this article](https://aclanthology.org/2021.findings-emnlp.299.pdf).*

<video />

If you want to move tags around before confirming a segment, you can manually project the tags at any time by opening the `Tags` tab and selecting the `Project target tags` option (shortcut `Ctrl` + `Alt` + `N`). Note that tags can be moved even after the segment is confirmed.

<video />

Once tags have been projected into the target text, they will always be displayed. For this reason, we recommend using the menu to Project target tags, and then move the tags if required before confirming the segment. Tags will project automatically when the segment is confirmed, and must be checked before moving onto the next segment.

Each tag is part of a tag pair that marks where the tag starts and ends:

* **The opening tag:**

  <Frame>
    <img />
  </Frame>

  contains the tag number and tipple dot: `...`

* **The closing tag:**

  <Frame>
    <img />
  </Frame>

  contains a backslash and the tag number

Clicking on the tipple dot `...` part of an opening tag displays information about the tag.

<video />

## Display settings

<Frame>
  <img />
</Frame>

**Show source tags** - By default, LILT Verify displays source text tags. If you find this gets in the way during translation, you can hide the source tags by deselect the `Show source tags` option in the `Tags` tab.

* Note that 100% and 101% TM matches with the same source text, but different source tags, are counted as 99% matches.

**Show target tags** - By default, LILT Verify displays target tags. Disabling this setting hides all tags in the target segment (even if the segment has been confirmed). QA still checks for tag errors and linguists will need to fix any tag errors before they can confirm a segment. LILT will automatically unhide tags in the target segment if segment confirmation fails because of tag errors (ignoring the setting for just that segment) so linguists don’t have to manually turn off the setting every time.

**Project target tags** - If you want to move tags around before confirming a segment, you can manually project the tags at any time by opening the `Tags` tab and selecting the `Project target tags` option (shortcut `Ctrl` + `Alt` + `N`). Note that tags can be moved even after the segment is confirmed. Once tags have been projected into the target text, they will always be displayed. For this reason, we recommend using the menu to Project target tags, and then move the tags if required before confirming the segment. Tags will project automatically when the segment is confirmed, and must be checked before moving onto the next segment.

## Editing tags

Once tags have been projected into the target text, they can be manipulated with keyboard shortcuts so you don’t have to take your hands off the keyboard while processing segments in LILT Verify.

<video />

You can find the tag hotkeys listed in the `Tags` tab and in the [Hotkeys](/kb/hotkeys) article.

If you prefer to use your mouse, tag editing can be accomplished by mousing over a tag, clicking it, dragging it to where you want, and then releasing the mouse button to place the tag.

<video />

A few notes about tag manipulation:

* Manipulating tags will unconfirm/unaccept segments.

* Tags are automatically saved after being placed. No additional saving is required.

* Tags cannot be added, changed, or deleted.

## Tag color indicators

Tags are shown in different colors to indicate different states:

* <img />

  **Gray:** normal tag

* <img />

  **Green:** currently selected tag (use the keyboard shortcuts to move the currently selected tag)

* <img />

  **White with green outline:** the matching paired tag for the currently selected tag (you can use the keyboard shortcut to jump to the matching tag)

* <img />

  <img />

  **Red:** invalid position (nesting does not match source)

## Tag validation

LILT has automatic checks to determine whether tags are positioned and nested correctly. When a tag is invalid, it shows as red and cannot be saved (or segment confirmed) until the tag position is resolved to be valid.

<Frame>
  <img />
</Frame>

LILT also has a [QA check tool](/kb/quality-assurance-tools) that allows linguists to search for potential [tag issues](/kb/quality-assurance-tools) at any time across a single segment or all segments in a document.

## Tag auto-propagation

If forward auto-propagation or backward auto-propagation are turned on in the `Settings` tab, tag changes are automatically propagated across the document for segments with 100% TM matches. This means that if you change target tag positions in a segment and confirm the segment, in any other segment with the same source tags, the target tags will be propagated to match.

<video />


# Tags Quality Assurance
Source: https://support.lilt.com/kb/tags-quality-assurance



Tag errors are easy to miss. That’s why LILT’s Auto Review automatically searches for potential tag errors for you, saving time and effort. This article goes over using Auto Review for finding tag errors. To learn more about tags in general, see the [Tags & Formatting](/kb/tags-formatting) article.

## Running Full QA Checks

To reveal tag errors across all segments in a document, open the `File` tab and click `Run full QA check`.

<Frame>
  <img />
</Frame>

To run QA Checks on a single segment, click on the `QA` button on the right side of the segment.

<Frame>
  <img />
</Frame>

After running QA Checks, if any potential tag issues are found, they will be highlighted in [LILT Translate](/kb/introduction-to-lilt-translate). Note that the QA Checks also searches for and displays [Linguistic Errors](/kb/quality-assurance-tools).

Hover over any tags highlighted by the QA check to see information and suggestions about the tag error.

<Frame>
  <img />
</Frame>

Issues with tag placement are typically found around punctuation, whitespace, or numbers. These types of tag errors can be easily overlooked, so utilizing LILT’s QA Checks to automatically search for them is a good way to ensure accuracy.

## Summary of the Tag QA rules

| **Error Message** | **Possible Triggers** | **Example** |
| - | - | - |
| **Tags may be misplaced around punctuation** | • Tag has a leading or trailing punctuation mark in the source, but not the target.<br />• Tag has an extra leading or trailing punctuation mark in the target. | **Source:**<br />`<b>Hello,</b> from LILT`<br />**Target with error:**<br />`<b>Bonjour</b>, de LILT`<br />**Target without error:**<br />`<b>Bonjour,</b> de LILT` |
| **Tags may be misplaced around whitespace** | • Tag has a leading or trailing space in the source, but not the target.<br />• Tag has an extra leading or trailing space in the target. | **Source:**<br />`<b>Hello there </b>` <br />**Target with error:**<br />`<b>Bonjour</b>` <br />**Target without error:**<br />`<b>Bonjour </b>` |
| **Tags do not wrap identical content in the target** | • Span wrapped by a tag pair in the source appears exactly in the target, but it is not wrapped by the tag pair. | **Source:**<br />`<b>The shovel</b> works well` <br />**Target with error:**<br />`<b>La pelle fonctionne bien</b>` <br />**Target without error:**<br />`<b>La pelle</b> fonctionne bien` |
| **Tags co-located in the source are not co-located in the target** | • Two tags have the same position in the source, but don't have the same position in the target. | **Source:**<br />`<1><2>Hello` <br />**Target with error:**<br />`<1>Bonjour<2>` <br />**Target without error:**<br />`<1><2>Bonjour` |
| **Missing text between tags** | • There is a paired tag with text between it in the source, but not in the target. | **Source:**<br />`<b>Hello</b>` <br />**Target with error:**<br />`<b></b>Bonjour` <br />**Target without error:**<br />`<b>Bonjour</b>` |
| **Mismatched tags at beginning of sentence** | • Tag has position 0 in the source, but not position 0 in the target.<br />• Tag has position 0 in the target, but not in the source. | **Source:**<br />`<1><2>Hello`<br />**Target with error:**<br />`<1>Bonjour<2>`<br />**Target without error:**<br />`<1><2>Bonjour` |
| **Mismatched tags at end of sentence** | • Tag is at end of source, but not at end of target.<br />• Tag is at end of target, but not at end of source. | **Source:**<br />`Hello, from <b>LILT</b>`<br />**Target with error:**<br />`Bonjour, de <b></b>LILT`<br />**Target without error:**<br />`Bonjour, de <b>LILT</b>` |


# Terminology
Source: https://support.lilt.com/kb/terminology



LILT provides a range of tools for project managers, translators, and reviewers to efficiently manage terminology. The tools and functions of [LILT Verify](/kb/introduction-to-lilt-translate) encourage translators and reviewers to adhere to terminology standards for a given project.

Terminology refers to terms (words or phrases) that have pre-defined translations. In LILT, terminology is held inside the Data Source as Termbase (TB) entries, where each TB entry contains a source term and a target term.

## Terminology in LILT Verify

When a document is opened in LILT Verify, LILT automatically searches the associated Data Source for matching TB entries that are marked as reviewed. When a match is found, the term is highlighted in the following places:

1. **Source text:** Source terms are highlighted in orange if the corresponding target term is not already in the target text area. If the term is in the target text area, the source term is highlighted in green.
2. **Translation suggestions:** The Contextual AI Engine displays terminology suggestions in orange.

Once the term has been used, the word is highlighted in green in the source and target text.

<Frame>
  <img alt="" />
</Frame>

If there are overlapping term entries (e.g. for "Ancient Greece" and "Greece"), only the longest term is highlighted in the source text and displayed in the tooltip.

In the Segment Context sidebar, each approved target term is now shown as a separate match with its own metadata (up to the 4 most recent). The Segment Context sidebar also displays term metadata about who approved the term and the approval date.

### Multiple target terms

A source term can have more than one approved target term — for example, when the right translation depends on context. When this happens, the Segment Context sidebar shows each target term as a separate match, with its own metadata, so you can choose the right one for the segment.

* Up to the **4 most recent distinct target terms** are shown for each source term.
* If the same source and target pair appears more than once in the termbase, it's shown once, using the metadata from the most recent entry.
* **AI QA and terminology checks** treat any of these target terms as correct. Using an approved alternative won't be flagged as an error.
* **AI Review** uses the most recent target term.

If your termbase has many duplicate or conflicting entries, we recommend cleaning them up or adding metadata (such as a definition or usage note) so experts can tell the options apart.

## Case sensitivity for TB matching

The case sensitivity of TB matching is set in the [Settings](/kb/memory-settings) page of each Data Source. By default, newly created Data Source have the `Case-sensitive matching` option enabled.

<Frame>
  <img alt="" />
</Frame>

As an example, let's see what would happen if we are use an English to GermanData Source with only one TB entry:

bananas > bananen

<Frame>
  <img alt="" />
</Frame>

We'll also add a document with the following segment into a Project that utilizes this Data Source:

Bananas come in different sizes and colors, but all bananas grow in clusters.

If the `Case-sensitive matching` option is disabled, LILT ignores differences in case when finding matches. In LILT Verify, we will see that both "Bananas" and "bananas" are found to have TB matches.

<Frame>
  <img alt="" />
</Frame>

If the `Case-sensitive matching` option is enabled, LILT obeys differences in case when finding matches. In LILT Verify, we see that only "bananas" is found to have a TB match.

<Frame>
  <img alt="" />
</Frame>

## Searching existing terminology

You can search for terminology in the Segment Context sidebar. If you are searching for an item which has multiple variations within the Termbase, several options may appear in the target list. Depending on how thorough the Termbase is that was uploaded into the Data Source, this functionality assists in selecting the best possible translation for the source content you are translating.

## Adding new terminology

Translators and reviewers can manually add new terminology to the Termbase for future reference. When operating in teams, this can be an especially powerful tool to help maintain consistency across the team.

TB entries can be added by opening the `Segment context` sidebar and clicking the `Add entry` button (Windows shortcut: `Alt`+`A`; Mac shortcut: `Option`+`A`) to open the `Add new entry` form.

<Frame>
  <img alt="" />
</Frame>

Adding new terminology from the sidebar

The `Add new entry` form has the following fields to fill in:

* **Source text**
* **Target text**

**Approval status (managers and reviewers only):** Draft, reviewed, unreviewed. Note: when translators add an entry, the approval status will be set to `unreviewed`.  Entries must be in the `reviewed` state for them to be displayed in LILT Verify.

* **Custom fields:** Custom fields allow metadata to be added.

In addition, the following fields are automatically filled in (based on the segment in focus) and cannot be changed:

* Segment source
* Segment target

<Frame>
  <img alt="" />
</Frame>

## Reviewing and approving new terms

Managers and reviewers who open a document in Review mode have the ability to approve new terms from directly within the LILT Verify. *Note: Reviewers must be assigned to the document to be able to open the document are review the relevant added terms.*

In Review mode, you will see an `unreviewed terms` indicator (matching the number of terms to review) on the segment links sidebar icon. Click the segment links icon, then review each term to either `approve` the term to move it to the `reviewed` state, or `ignore` the term to leave it in the `unreviewed` state.

\*\*Note: \*\***`Entries must be in the reviewed state for them to be displayed in LILT Verify.`**

<Frame>
  <img alt="" />
</Frame>

## Terminology metadata

Click on any TB match in the sidebar (either the info icon or on the term directly) to see any metadata attached to the term. When a source term has multiple target terms, each one shows its own metadata.

<img alt="Screenshot 2026 10 01 At 2 41 52 Pm" />

## Source highlighting tool

The source highlighting tool functions as a way to quickly access the terminology tools. Using the mouse, highlight the source text you're interested, then right-click on the text to open the tool options:

* **Copy to target:** Copies the highlighted source words into the target text field.
* **Lookup in Segment context:** Opens the Segment Context sidebar, puts the selected source text into the search field, and searches for the text.
* **Lookup in Concordance:** Opens the Concordance sidebar, puts the selected source text into the search field, and searches for the text.

<Frame>
  <img alt="" />
</Frame>

## Terminology and Contextual AI

LILT Contextual AI is aware of the terminology and will in most cases reproduce the correct target term, sometimes in inflected form to match the grammatical structure of the target language sentence. In some cases it may choose to omit the term, e.g. if the uploaded translation memories contain examples that do not use the term.

## Maximum Character in Terminology Entries

Term base entries of 60 characters or less will be recognized in the CAT editor. Entries over 60 characters will not be recognized in the editor.


# TM Leveraging
Source: https://support.lilt.com/kb/tm-leveraging



To speed up translation and reduce errors, LILT automatically leverages Translation Memory (TM) to populate the target text of empty, unreviewed segments with 100% or 101% matches. This feature is called TM Leveraging.

TM Leveraging is automatically applied to all documents that share a Translation Memory (even across Projects) each time they are opened in [LILT Translate](/kb/introduction-to-lilt-translate) (or when the LILT Translate page is refreshed).

* If a segment has any target text, TM Leveraging will not be applied (TM Leveraging will not overwrite any target text).

* Segments populated by TM Leveraging will display red match annotation of `100%` or `101%` to indicate what kind of match was found in the TM. This match annotation will go away when the document is reopened.

* If the [Project Settings](/kb/project-settings) option `Auto-confirm exact matches & repetitions` is enabled, segments populated by TM Leveraging will be automatically marked as confirmed. Otherwise, they will be left unconfirmed.

The following graphic displays what LILT Translate would look like after translating "A window" to "Una ventana" in one document and then opening another document that also contains matching segments.

<Frame>
  <img />
</Frame>

Segments in this example:

1. **"A window":** This was found to be a 101% match, so TM Leveraging was used.

2. **"A window"**: This segment already had text, and so TM Leveraging was not used.

3. **"The bus"**: No matching entry was found in the associated TM, so TM Leveraging was not used.

4. **"A window"**: This was found to be a 100% match, so TM Leveraging was used.

5. **"The car"**: No matching entry was found in the associated TM, so TM Leveraging was not used.

## TM Leveraging vs Overwrite Confirmed Segments

TM Leveraging differs from [Overwrite Confirmed Segments](/kb/auto-propagation) differs following ways:

| | **TM Leveraging** | **Overwrite Confirmed Segments** |
| - | - | - |
| **Scope** | All documents sharing a Data Source | Current document open in LILT Translate |
| **Populates empty, unconfirmed segments** | Yes | Yes |
| **Populates filled, unconfirmed segments** | No | Yes |
| **Confirms the segment after populating** | No/Yes1 | Yes |
| **Overwrites target text** | No | Yes |
| **Overwrites confirmed segments** | No | No/Yes2 |
| **Displays match annotation after populating** | Yes | No |

1 If `Auto-confirm exact matches & repetitions` is enabled in the [Project Settings](/kb/project-settings), segments populated by TM Leveraging will be marked as confirmed; otherwise, they will be left unconfirmed.

2 If Forward Overwrite Confirmed Segments or Backward Overwrite Confirmed Segments are enabled, in addition to Overwrite Confirmed Segments being applied to unconfirmed segments, Overwrite Confirmed Segments will also be applied to confirmed matching segments.


# Translation Memory Guidelines
Source: https://support.lilt.com/kb/tm-size-content-guidelines



This article outlines several Data Source guidelines for making the most of LILT's technology.

## Content guidelines

To ensure the highest quality model adaptation, translation memory files should mostly consist of full natural-language sentences. Uploading a large quantity of short segments may degrade model performance and require a model reset.

## Size guidelines

The maximum file size for TM uploads is 200 MB. For file sizes larger than 200 MB, the files can be zipped before upload.

For self-managed customers, processing of TMs larger than 3,000 parallel segments is only recommended when a GPU is installed on the system. Otherwise, memory updates may be slow.

LILT processes TMs much faster when using a GPU. The exact rate varies by language pair, type of GPU, and amount of CPU and RAM available to the system.


# Translating Documents
Source: https://support.lilt.com/kb/translating-documents



[Translate](/kb/introduction-to-lilt-translate) has a range of tools that provide a streamlined workflow for document translators. This article outlines the workflow and tools available to translators using LILT.

Before a translator can access and begin working on a document, a project manager needs to assign the translator to the document. A translator can then [accept the document assignment](/kb/accepting-document-assignments) and begin translating.

## Translating documents

When a translator opens a document, it will load [LILT Verify](/kb/introduction-to-lilt-translate) in Translate mode. The Translate mode interface is the same editor used for [Review](/kb/reviewing-documents), but with a few slight differences, as described in the [Introduction to LILT Verify](/kb/introduction-to-lilt-translate) article.

The role of a translator is to translate all the segments of a document. The various tools and features (as described in the [Introduction to LILT Verify](/kb/introduction-to-lilt-translate) article) all come together to create an efficient translation workflow. The most important tools for translators to know are the [segment editor](/kb/introduction-to-lilt-translate), [quality assurance tools](/kb/quality-assurance-tools), and [hotkeys.](/kb/hotkeys)

After a translator has translated a segment, they click `Confirm` in the bottom-right of the segment to indicate that the segment has been translated. Once confirmed, the segment can be unconfirmed if it needs to be edited. [*Note: Once a segment has been accepted in Review mode, that segment can no longer be edited in Translate mode.*](/kb/reviewing-documents)

<img alt="Screenshot2025 08 26at18 58 58 Pn" />

Translators can add [comments](/kb/segment-comments) to a segment if they have questions or want to add notes.

To learn about who is given authorship for a segment's translation, see the [Data Source Memory Matching](/kb/translation-memory-matching) article.

## Marking the document as done in Translate mode

When all segments in a document have been confirmed by the translator, a `Mark as done` popup will appear, allowing the translator to mark that the document has been completed in Translate mode.

<Frame>
  <img alt="" />
</Frame>

Mark as done popup

If a manager [requires Quality Assurance Tools checks for translators](/kb/mandatory-batch-qa-check), the translator will need to run Quality Assurance Tools (which runs a QA check on all the document's segments) before the document can be marked as done.

Documents can also be marked as done from the `File` tab.

<Frame>
  <img alt="" />
</Frame>

Mark as done from File tab


# Translation Memory Matching and Suggestions
Source: https://support.lilt.com/kb/translation-memory-matching-and-suggestions



Each Data Source has memory entries containing source/target pairs, called TM entries. LILT improves translation speed and consistency by matching TM entries to segments that need translating and providing them as suggestions to linguists.

## Where TM matching is used in LILT

* **[TM segment suggestions](#tm-suggestions-in-lilt-translate):** When working in LILT Translate, translation suggestions are provided to linguists for the active segment. If there are any TM matches 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](/kb/machine-translation) model to provide suggestions to the linguist. *Note that if the language pair does not have [Contextual AI](/kb/supported-languages), no Contextual AI suggestions will be shown.*

* **[Pretranslation](/kb/pretranslating-documents):** When Pretranslation is run, any segments that have 100% or 101% matches with TM entries in the associated Data Source are translated.

* **[TM Leveraging](/kb/tm-leveraging):** LILT automatically leverages TM entries in the associated Data Source to populate the target text of empty, unreviewed segments with 100% or 101% matches. This is performed across all documents that share the Data Source.

* **[Overwrite Confirmed Segments](/kb/auto-propagation):** When a linguist confirms or accepts a segment in LILT Translate, Overwrite Confirmed Segments updates matching segments (100% and 101%) with the same changes.

## TM match ordering

LILT leverages TM matches in the following order:

| **Prioritization order** | **Prioritization method** | **Prioritization** |
| - | - | - |
| 1 | Match percent | TM entries with higher match percents are prioritized over TM entries with lower match percents. *For example, a TM entry that is a 100% match is prioritized over a TM entry that is a 95% match.* |
| 2 | Recency | More recently updated TM entries are prioritized over entries that weren't updated as recently based on the TM entry's modification time. |

*Note that the reviewed/unreviewed status of a TM entry does not affect match prioritization.*

### Prioritize recency setting

If enabled in Organization settings, this will disable 101% match priority and allow for recency-based match prioritization. 101% matches will be treated as equivalent to 100% matches, prioritizing recency over context precision.

<Frame>
  <img />
</Frame>

## TM match scores

The table below outlines the various match scores in LILT.

| **Match percent** | **Match name** | **Match description** |
| - | - | - |
| 101% | ICE Match (In-Context Exact Match), sometimes called a Guaranteed Match | The selected segment has the exact same words as a TM entry. In addition, the segments before and after the selected segment are also identical to a set of three consecutive segments in the TM. |
| 100% | Exact Match | The selected segment has the exact same words as a TM entry. |
| 99% | 99% Fuzzy Match | The selected segment is almost exactly the same as a TM entry. A 99% match usually indicates there is a whitespace or tag mismatch. |
| >75% | Fuzzy Match | The segment has similar words to a TM entry, but there are significant differences. |

The lowest match percentage available is 75%. This is a set threshold and not configurable.

If the [Organization Setting](/kb/organization-settings) for `Case-sensitive matching` is enabled, TM match scoring takes into account any differences in letter casing; otherwise, casing is ignored.

**In LILT, 100% matches that have whitespace differences or tag differences are downgraded to 99% matches.** In the example below, the bottom segment doesn't have a new line whitespace like the top segment does, so the TM match for the bottom segment is displayed as a 99% match.

<Frame>
  <img />
</Frame>

## How TM match percentages are calculated

LILT uses an [Edit Distance](https://en.wikipedia.org/wiki/Edit_distance) algorithm to calculate match percentages. However, because TMs can be large, it is not practical to compare every source segment to every entry in the TM. To simplify this problem, LILT first uses a [Locality-Sensitive Hashing](https://en.wikipedia.org/wiki/Locality-sensitive_hashing) algorithm to find a subset of the TM that is roughly similar to the source string, and then calculates the match percentage against each of those possibilities. This process is not 100% guaranteed to always produce every possible fuzzy match candidate, but rather allows for an optimized balance between quality of TM matches with speed/time to match.

In cases where our algorithm misses a fuzzy match, this is likely due to having multiple languages present in the same segment.

## TM suggestions in LILT Translate

Translation Memories (TM) entries are used to provide translation suggestions to linguists working in [LILT Translate](/kb/introduction-to-lilt-translate). When a segment is active in LILT Translate, the associated Translation Memory is checked for TM entries with similar phrases. If any TM entries are found with similar phrases to the segment, the highest matching, most recent TM entry is displayed under the segment as a translation suggestion.

<Frame>
  <img />
</Frame>

* 100% and 101% matches are automatically populated into the target text area (via [TM Leveraging](/kb/tm-leveraging)), rather than being provided as suggestions.

* If no matches exist above 75%, LILT provides a [Contextual AI suggestion](/kb/machine-translation) for the target text. If the language pair does not have [MT support](/kb/supported-languages), no MT suggestion will be shown.

## TM difference display

Fuzzy matches (less than 100%) are shown along with a display of the differences between the TM entry and the source.

Let's look at an example:

* **Segment source text:** `The hares and the tortoise`

* **TM entry:** `The hare and the tortoise` > `La liebre y la tortuga`

In this case, the TM diff displays the following: `The hare<sup>hares</sup> and the tortoise`. The TM entry uses `hare`, while the source uses `hares`. Any words in the TM suggestion that are missing from the source are underlined. Substitutions from the source are displayed in superscript.

<Frame>
  <img />
</Frame>

If you do not want to see the TM diff display for the active segment, press `Escape` to close it. Once closed, you can still access and use the TM suggestion, but the TM diff display (including match percent) will go away. The diff display can be brought back by refreshing the page.

<Frame>
  <img />
</Frame>

## View all TM matches for a segment

If there are multiple suggestions, they can be viewed in the [Segment Context](/kb/segment-context) pane on the right side of LILT Translate. The `Segment context` pane displays TM matches sorted in the following order:

1. Reviewed/unreviewed
2. Match percent
3. Most recently updated

**Note: The order of TM entries displayed in the `Segment context` pane is not the same as the TM match order. While the `Segment context` pane sorts by reviewed/unreviewed status, TM matching ignores reviewed/unreviewed status.**

<Frame>
  <img />
</Frame>

If there are any identical TM entries in the associated Translation Memory, the `Segment context` pane will display so. Click the `identical results` dropdown to display the following metadata for each identical TM entry:

* attributed user
* timestamp of when the entry was last updated

<Frame>
  <img />
</Frame>

## How TM entries are added to and removed from Data Sources

**TM entry metadata:** When a TM entry is added or modified, its metadata is updated:

* **Entry author:** Email address of the author. *Authorship is not always changed when an entry is updated. The sections below describe how and when authorship is updated.*

* **Entry timestamp:** Date and time the TM entry was last updated. *The time is displayed in the viewer's time zone.*

### Linguist actions that update TM entries

| **Action** | **Adds TM entry** | **Modifies TM entry** | **Removes TM entry** |
| - | - | - | - |
| A **translator** confirms a segment. | **✓** | | |
| A **translator** modifies and confirms a segment. | | **✓** | |
| A **translator** unconfirms a segment. | | | **✓** |
| A **reviewer** accepts a confirmed segment. | — | — | — |
| A **reviewer** modifies and accepts a confirmed segment. | | **✓** | |
| A **reviewer** accepts an unconfirmed segment. | **✓** | | |

The last person to confirm a segment is attributed as the TM entry author.

* *When a reviewer accepts a confirmed segment without modifying the target text, the author is left as the translator who confirmed the segment.*
* *When a reviewer accepts an unconfirmed segment, they are given authorship.*
* *Reviews have the ability to unconfirm segments, meaning that if a reviewer unconfirms a segment and then accepts the segment, they will be given authorship.*

### Project manager actions that update TM entries

| **Action** | **Adds TM entry** | **Modifies TM entry** | **Removes TM entry** |
| - | - | - | - |
| A **project manager** [uploads a TM file](/kb/uploading-memory-files) to the Data Source. | **✓** | | |
| A **project manager** [removes a TM file](/kb/uploading-memory-files) from the Data Source on the `Manage resources` page. *Note: This will only remove the entries in the Data Source that were added from the file.* | | | **✓** |
| A **project manager** adds an individual TM entry in the Data Source from the `Manage entries` page. | **✓** | | |
| A **project manager** modifies an individual TM entry in the Data Source from the `Manage entries` page. | | **✓** | |
| A **project manager** removes an individual TM entry in the Data Source from the `Manage entries` page. | | | **✓** |

TM entries uploaded to the Data Source by a project manager are attributed to the TM entry authors listed in the TM file.

When a project manager manually adds a TM entry on the `Manage entries` page, they are made the author of the entry.

When a project manager manually modifies a TM entry on the `Manage entries` page, authorship is not changed.

### Automated processes that update TM entries

| **Action** | **Adds TM entry** | **Modifies TM entry** | **Removes TM entry** |
| - | - | - | - |
| [**TM Leveraging**](/kb/tm-leveraging) populates and confirms an unconfirmed segment. | **✓** | | |
| [**Overwrite Confirmed Segments**](/kb/auto-propagation) populates and confirms an unconfirmed segment. | **✓** | | |
| [**Overwrite Confirmed Segments**](/kb/auto-propagation) overwrites a confirmed segment. | | **✓** | |
| [**Pretranslation**](/kb/pretranslating-documents) populates and confirms an unconfirmed segment. | **✓** | | |

TM Leveraging and Overwrite Confirmed Segments attribute authorship to the user in the document when TM Leveraging or Overwrite Confirmed Segments is run.

Pretranslation attributes authorship to either the project manager or the author of the matching entries (depending on the Pretranslation settings).


# Uploading and Maintaining Memory Files
Source: https://support.lilt.com/kb/uploading-memory-files



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). This article walks through uploading memory files to new or existing Data Sources.

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 `New Data Source` button in the upper-right corner of the `Data > Sources page`. See [Managing Data Sources](/kb/managing-your-lilt-memories) for more details on creating new Data Sources.

<Frame>
  <img alt="" />
</Frame>

Once you have located the Data Source you want to upload your memory files to, click the Data Source card or its `Edit` button to open up the data source management view.

Navigate to the `Manage resources` page. This page displays all documents that have been uploaded to the Data Source.

To add files to the Data Source, click the `Upload files` button in the upper-right and select the type of 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.

<Frame>
  <img alt="" />
</Frame>

**TM supported file types:** JSON, SDLTM, TBM, TMQ, TMX, TMX.ZIP, SDLTM, SDLXLIFF, XLIFF

**TB supported file types:** CSV, TBX, TSV, XLSX

**File limitations:**

* Data Source files can contain as many entries 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 and add filename.tmx.zip appendage before uploading. Once uploaded, the file will be parsed into individual, editable entries.
* See the [Data Source 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:
  <Frame>
    <img alt="" />
  </Frame>
* 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"
        }
      ]
    }
  ]
  ```

**Data Source entry 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 Contextual AI model learns from uploaded data immediately upon upload. Note that deleting documents from a Data Source **does not** affect the Contextual AI model (i.e. the Contextual AI 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 Contextual AI 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 Translation Memory 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.

<Frame>
  <img alt="" />
</Frame>

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.

<Frame>
  <img alt="" />
</Frame>

## Deleting Data Source files

1. Select the files you want to delete by clicking the checkbox next to the resource name. Alternatively, you can select all files with the `Select all` button. If any files are selected, this turns into a `Deselect` button that will deselect all the resources currently selected.
2. 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.

<Frame>
  <img alt="" />
</Frame>

## Data Source Maintenance Best Practices

This section provides insights into various tactics that project managers can utilize to enhance localization workflows by leveraging data sources.

### TMX File Uploads

* **TM files under 200 MB** can be directly uploaded to LILT.
* **For TM files over 200 MB**, compress the TMX file and upload it as `.tmx.zip`. Currently, LILT supports only TMX file format for zipped memory files.

For additional information on file support, refer to the Supported File Formats documentation.

### Termbase (TB) CSV File Formatting

Prior to uploading CSV files, consider the following:

* **For immediate visibility to translators**, set the Default TB Entry Status to Reviewed.
* **For entries requiring linguist review** before use, set the Default TB Entry Status to Unreviewed or Draft.

CSV files should be formatted with the **first two columns** for source and target text, respectively. Rows lacking either will not be imported. Termbase CSV files may include an optional header row.

<Frame>
  <img alt="" />
</Frame>

Note: **Wrap text containing commas in quotes** to ensure correct parsing. Omitting quotes will lead to parsing at the first encountered comma.

For header row CSV files, utilize the Termbase (TB, with header) import option. Metadata columns in CSV files, like status or dates, enhance translation content understanding.

Ensure **no unwanted spaces** exist in CSV files, as spaces post-commas are included upon import.

### TMX File Preparation

**Before upload**:

* **Remove outdated TM entries** by date.
* **Eliminate duplicate entries** with identical source text but differing target texts.

### TMX File Naming

Use informative labels, including the date, content type, and project or product name, to facilitate easier tracking and organization.

**Naming Convention Example**: `[DATE]-[CONTENT TYPE]-[NAME]`

### Managing TM Repetition

LILT Translate adds translated segments to the Data Source, stacking duplicate source/target pairs for clarity. Project managers decide on the frequency and necessity of duplicate removals, accessible via the Manage entries page in the Sources tab.

### Archiving Projects

To preserve TM entries while removing a project from the list, opt for archiving over deletion. Archiving retains TM entries within the Data Source, whereas deletion removes them. Consider downloading TM and TB entries before deleting a project for future use.

### TMX Files and Machine Translation

Uploaded TMX files are immediately learned by the associated Data Source's Contextual AI model, unaffected by subsequent deletions. While the most recent documents significantly influence translation outputs, retaining older, relevant translations is advisable for comprehensive data retention.

For outdated TMX files still holding value, uploading for Concordance only allows their indexing without affecting Contextual AI training or TM results.


# Using Pretranslate or Instant Translation Effectively
Source: https://support.lilt.com/kb/using-pretranslation-effectively



Using [Instant Translate as part of your Workflow](/kb/pretranslating-documents) can translate multiple files in parallel to save you from having to do so individually for multiple files. Grouping documents into Pretranslate batches also significantly increases throughput as compared to submitting files for Pretranslate individually. You can submit batches of files directly in the LILT application or through the API.

## Behind the scenes

LILT uses GPUs to translate documents for maximum speed. [Self-managed](/self-managed/v6.1/self-managed-features) customers benefit from the usage of all recognized GPUs in the system. A single batch request may be processed by one or more GPUs, depending on the number of documents and segments in it.

## Pretranslate in the LILT application

1. Navigate into the desired Project and open the `Documents` page.

2. Click the `Select all documents` button to select all the Project's Document cards.

3. Click Pretranslate, select the option to `Use MT for unmatched segments`, and click Pretranslate.

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

Once submitted for Pretranslate, each Document card will display the text Pretranslating along with a spinner icon. Once Pretranslating is complete, the spinner and `Pretranslating` text will go away, and the Document card progress indicators will show that the document has been translated.

## Batch Instant Translate & Pretranslate using the API

You can use Instant Translate (powered by LILT's Contextual AI Engine) for one or more files that have been previously uploaded by using the `/translate/file` endpoint and specifying multiple file IDs as documented [here](https://lilt.com/docs/api#operation--translate-file-post). This option bypasses writing data to our database and is useful for pure Contextual AI workflows. Alternatively, you can use our `Pretranslate` endpoint [here](https://lilt.com/docs/api#operation--documents-pretranslate-post), which is similar to clicking the `Pretranslate` button in the LILT application.


# Volume & User Activity
Source: https://support.lilt.com/kb/volume



The Volume and User Activity modules allow enterprises to track how much value they get from LILT by volume, throughput, and individual user activity. This data is rolled up at the Organization level, allowing administrators to better understand how people throughout their organization are making use of LILT over time.

## Volume

The Volume tab provides a view into the total volume of words processed through LILT over time.

* **Filters** are available to narrow down the analysis by date range, source language, and target language. You can also use the Filters menu to toggle between reporting on *words* and *characters*.
* **Volume Charts** show total instant source words, total verified source words, source word count trends over time.
* **Throughput Charts** show average instant source words per hour, average verified source words per hour, and average human expert processing speed in words per hour. Customers using their own in-house translators and review experts can view statistics related to individual expert performance.
* The **Model Usage** chart shows the total source words translated over time.
* The **Export to CSV** button allows for data export from the Analytics dashboard.

## User Activity

The User Activity tab provides insight into how users are making use of LILT.

* **Filters** are available to narrow down the analysis by date range, source language, and target language.
* **Logins** show total logins, unique logins, and logins over time.
* **User Activity by Workflow Stage** shows the breakdown of user activity by words submitted, words verified, and words reviewed.


# Error Rates
Source: https://support.lilt.com/kb/what-does-error-rate-mean



Project error rate is a useful metric that project managers can use to evaluate the performance of translators assigned to a Project. Error rate is an indicator of overall translation quality for a Project or document. LILT considers an error rate over 5% to be a serious indicator that a document should be unlocked and have its whole contents reviewed.

A Project’s error rate is displayed as a value between 0% and 100%, signifying the rate of translation errors across the Project’s documents. More precisely, error rate is the percent of segments reviewers have marked as having errors out of the total number of segments reviewed.

Note that if [Review Sampling](/kb/review-sampling) is on, the number of segments reviewed is less than the total number of segments in a Project. As an example, if 10 segments were reviewed and the reviewer marked 4 segments as having translation errors, there would be a 40% error rate.

The following error categories contribute to error rate:

* **Accuracy**

* **Linguistic conventions**

* **Terminology**

* **Style**

* **Design**

* **Locale convention**

* **Audience appropriateness**

The following error categories do not contribute to error rate:

* **Source**

The following error severities contribute to error rate:

* **Critical**

* **Major**

* **Minor**

* **Repeated error**

The following error severities do not contribute to error rate:

* **Kudos**

* **Neutral**

<Frame>
  <img />
</Frame>

## Viewing Project error rate

The error rate for a Project displays the collective error rate for documents that are fully reviewed. Project error rate is displayed in two places: project reports and revision reports.

### Project report

The Project error rate can be found in the [Project Report](/kb/how-to-read-project-reports) tab after generating or updating the report. If the Project doesn't have any documents that have been fully reviewed, the error rate will not display at all.

<Frame>
  <img />
</Frame>

### Revision report

If the review of documents has not yet been completed, but you would like to see the percent of reviewed segments that have been marked with errors, you can generate a [Revision Report](/kb/how-to-read-revision-reports) on the Project page by clicking on `Deliver` and then clicking `Revision Report`.

<Frame>
  <img />
</Frame>

This will download an XLSX spreadsheet file with a detailed report about the number of segments reviewed and the number of segments marked as having errors.

<Frame>
  <img />
</Frame>


# Contextual AI
Source: https://support.lilt.com/kb/what-is-interactive-adaptive-mt



LILT uses [Contextual AI](/kb/machine-translation) models to provide translation suggestions. Contextual AI is a form of artificial intelligence that can understand and interpret the context of a given situation or query to provide fine tuned responses or outputs.

LILT has two types of models:

* **Baseline language models:** The baseline model is shared across all customers. Each language pair has its own baseline model. LILT typically improves baseline models once a year using general-purpose data. Baseline models do not adapt based on new data.

* **Contextual AI models:** For every Data Source, LILT creates a paired fine-tuned model on top of the baseline language model. This is specific to the Data Source, content context, and real-time adaptation through the human feedback cycle during translation in LILT, creating a specialized ability to generate on-brand, in-context translations.

## Contextual AI is **Interactive**

Interactivity refers to the process of integrating AI suggestions into the translation workflow.

When translating in LILT, the Contextual AI intelligently suggests translations of the source segment that can be used during human translation.

<Frame>
  <img />
</Frame>

## Contextual AI is **Adaptive**

'Adaptive' refers to the ability of LILT’s translation models to change in response to confirmed segments.

When a translator confirms a segment, the Contextual AI model processes the source/target pair as correct and uses it as an example to learn from when providing future translation suggestions. In essence, the translator teaches the AI system to adapt translation suggestions to the style, grammar, and word choice of the translator.

Adaptation speed differs across [Data Sources](/kb/translation-memory-matching). In some cases, adaptation will pick up on updated terminology in the very next segment. In other cases, it may take longer. The context of a segment is also important when referring to adaptation speed. For example, the translation of a particular segment may be used when the AI provides suggestions for nearby segments; however, the AI may fall back to its original suggestions for segments farther away in the document.


# LILT Overview
Source: https://support.lilt.com/kb/what-is-lilt



We combine connectors, artificial intelligence, and advanced human computer interactions to provide an end-to-end AI solution. Translation with LILT is faster, more accurate, and more affordable for organizations around the world. We provide services and a powerful platform for in-house translation for commercial and government enterprises.

<video />

## The Platform

LILT Connect integrates the platform with multiple different TMS, data stores, and web management systems. LILT Connect allows seamless integration with [many systems](/kb/connectors).

Translate leverages our Contextual AI Engine to provide predicted translations right within the interface. As linguists complete work and accept, amend, or reject the provided predictions, the system learns from that feedback in real-time to provide more accurate predictions over time.

The platform was built specifically with the translator experience in mind. Our cloud-based LILT Translate ([Translate](/kb/introduction-to-lilt-translate)) provides linguists with all the functionality needed to enable skilled translators to do the best work of their careers quickly, accurately, and efficiently.

## Verified Translation

Unlike most Language Service Providers (LSPs), we do not use Machine Translation Post-Editing (MTPE) for our Verified Translation service. MTPE is a process where Machine Translation (MT) is used to pre-translate texts for later human correction. Verified Translation revolutionizes translation by replacing post-editing with interactive and adaptive Contextual AI that empowers human translators. This interactive, real-time experience helps linguists create the highest quality translated content for your global audience.

Interested in a demo? Sign up for a demo at [lilt.com](https://lilt.com/) by submitting your email through the `Get in Touch` form.

<Frame>
  <img alt="" />
</Frame>


# Product Updates
Source: https://support.lilt.com/kb/what-s-new-in-the-lilt-platform



## October 2026

### **LILT Launches in OpenAI's ChatGPT Plugin Directory**

Following our listings for [<u>Claude</u>](https://claude.ai/directory/88245f33-e3a7-468f-ae27-3f118bef198a) and [<u>Gemini</u>](https://console.cloud.google.com/marketplace/product/lilt-public/lilt-assist), LILT is now available in the [<u>ChatGPT plugin directory</u>](https://chatgpt.com/plugins/plugin_asdk_app_6aacca61d8dc8191881b23de486b25e3?search=lilt)! Powered by LILT MCP, the new plugin turns ChatGPT into a secure, natively multilingual workspace connected directly to your enterprise language assets, translation memories, and custom AI models. Teams can now self-serve brand-aligned content, launch translation jobs, and track delivery analytics without leaving their daily workflows. Whether you need automated AI quality checks for everyday communications or expert human review for high-stakes assets, you get full governance and real-time oversight inside your chat interface.

[<u>\[Get Started\]</u>](https://chatgpt.com/plugins/plugin_asdk_app_6aacca61d8dc8191881b23de486b25e3?search=lilt)

### In Context Preview - IDML support

We expanded our In-Context Preview feature to now support IDML files. See your translations rendered in the source file's original layout as you work, so you can catch formatting issues, verify text fits design constraints, and check content looks right before delivery.

For IDML files, embedded images will display in the preview. If an IDML references images that aren’t embedded, the preview will show placeholders.

Full details, including FAQs, available here: [https://support.lilt.com/kb/in-context-preview](https://support.lilt.com/kb/in-context-preview)

### **Multiple Terminology Matches**

When a source term has more than one approved target term in the termbase, the CAT sidebar now shows all of them — up to the 4 most recent distinct target terms — instead of only the most recent. Each option has its own metadata (definition, part of speech, custom fields), one click away.

AI QA and terminology QA checks now treat any of these 4 target terms as valid, so experts are no longer flagged for using an approved term that isn't LILT's top choice. Hovering over a highlighted term in the segment editor shows all target options.

<img title="image (16).png" />

### Expandable and Resizable Segment Context Panel

Closing the Segment context panel now gives its space back to the editor. The panel collapses to the icon rail on the right and the segments expand to fill the full width — no more empty gap. Click any rail icon to reopen the panel to that tab.

* **Drag to resize:** drag the panel's left edge to set its width. This is especially helpful in reviewing the style guide or concordance, where a larger viewing pane is often needed. Width resets to the default on reload.
* **Split view:** the editor also expands when the panel is closed in split (side-by-side) view.

### AEM Connector Updates — Standalone Tag Translation

LILT's AEM Cloud Connector (v1.12+) can now translate tags on their own, without a page or content fragment. Previously, tags could only be sent if they were linked to a page being submitted for translation.

* Translate tag folders or individual tags with no page required.
* Tag titles and descriptions are written back to the same tag node, so tag IDs stay stable.
* Locale code differences between LILT and AEM can be mapped in the connector settings.
* Tags and pages can still go in the same submission.

Find more information in the KB [here](https://support.lilt.com/kb/aem).

### **Inriver Connector: Launch Global Campaigns Faster**

Eliminate manual exports and reimports, and easily translate your product-related content in Inriver—a product information management (PIM) system—using the new Inriver connector. Launch ecommerce products and global campaigns faster and more accurately, with less overhead.

[\[Learn More\]](https://support.lilt.com/kb/inriver)

### **Amplience Connector: Automate Source-to-Delivery in a Few Clicks**

Seamlessly translate all your Amplience content—web, promotional banners, and more—using the new Amplience connector. Simply submit the job by marking the status as ready for translation and choosing your target languages and workflow—instant or expert-verified. When translation is complete, LILT delivers the content back to the repository of your choice, organized by language or region.

[<u>\[Learn More\]</u>](https://support.lilt.com/kb/amplience)

### API Key Search, Filter and Delete

Managing API keys is now faster for teams with many keys. In **Manage → API** you can:

* **Search** by key name, owner or key
* **Filter** by status: Active, Expired or Revoked
* **Sort** by creation, expiry or last used date, with keys expiring soon highlighted
* **Delete** expired or revoked keys to keep your list clean

## September 2026

### In Context Preview - Exclusive Open Preview!

In-Context Preview lets you see your translations rendered in the source file's original layout as you work, so you can catch formatting issues, verify text fits design constraints, and check content looks right before delivery. It's available for PDF, DOCX, PPTX, XLSX, HTML/HTM, TXT, Markdown, and CSV files, across all workflow stages.

The panel opens automatically for supported files; click a segment in the editor to highlight it in the preview, or click text in the preview to jump to that segment. You can split the view horizontally or vertically, or collapse the panel to free up space.

Read more about [In Context Preview](https://support.lilt.com/kb/in-context-preview).

<img alt="Image" />

### Introducing the LILT Context Database: Your Centralized Data Hub

Managing and querying multilingual data across an entire organization can be challenging.  We are excited to introduce the **Context Database**, a centralized hub that brings your translation memories, termbases, style guides, and project metadata together into one powerful context engine. This unified, searchable ecosystem eliminates data silos so teams can query and filter organizational context at scale.

* **Natural Language Search:** Find assets instantly across all projects using document names, segment IDs, specific terms, metadata, or job status.
* **Faceted Filtering:** Effortlessly refine results by asset type, language pair, business domain, and date range.
* **Smart Cross-Referencing:** Dynamically applies your newest terminology to historical TM matches and flags contradictions in real-time.
* **Enterprise Security:** Strictly enforces existing role-based and domain-based permissions to keep secure data protected.

Learn more about the [LILT Context Database](https://support.lilt.com/context-database#what-is-the-context-database)!

### **Change to API download filenames, effective September 8**

Starting September 8, we are standardizing file download names across the platform to include the target locale, not just the target language.

What’s changing:

* **API downloads** will move from language-only to full locale. Today, a file translated into fr-FR downloads as filename.fr.docx via the API. After this ships, it will download as filename.frFR.docx.
* **All platform downloads** are also being updated to include locale consistently. Some parts of the LILT platform already do this today; after September 8, all of them will.

Here's how the API filenames have changed:

<img alt="Image" />

### AEM Connector Updates - Launch functionality

LILT’s AEM Cloud Connector (**v1.10 +)** can now deliver translations from LILT into **AEM Launch spaces**, giving content managers more control over both published pages and new campaigns. Teams can review and promote updates on their own timeline, and nothing goes live until it is manually approved.

More information available on the [AEM Connector page](https://support.lilt.com/kb/aem#deliver-to-launch-v1-10+).

## August 2026

### AI Review for all languages

[AI Review](https://support.lilt.com/kb/ai-review#supported-languages) is now enabled for all languages. These newly added languages represent \~10% of LILT’s overall content volume.

### One-Click Terminology

Terminology Base (TB) matches now open with one click. Select a TB match in the CAT sidebar to view full entry metadata (e.g., definition, part of speech, usage examples) without expanding a dropdown. Read more about [Terminology metadata](https://support.lilt.com/kb/terminology#terminology-metadata).

### Per-Language QA Rules

[QA agent rules](https://support.lilt.com/kb/ai-qa-v2#custom-ai-qa-checks) can now be scoped to specific language pairs. For example, a rule set written for EN→FR and EN→IT will only apply to French and Italian projects, reducing false positives and improving review efficiency.

If you already have Custom AI QA rules, they will apply for all languages (as they do now). Recommended action is to remove any language-specific rules and put them in their own language section to see improved results.

### AI Review error flagging

Reviewers can now [flag AI Review suggestions](https://support.lilt.com/kb/ai-review#providing-feedback-on-ai-review) they disagree with and add a brief explanation. This feedback is captured in an actionable format to improve AI Review over time.

### Selectable Connector Configurations in the LILT UI

Organizations using in-LILT connectors (e.g., Amplience and inRiver) can now create multiple connector configurations and select the appropriate one during job submission. Previously, only the most recently created configuration was used by default.

### LILT Performance improvements

LILT is getting faster, across the board. We’ve made significant performance improvements to LILT Analytics. Reports that once kept you waiting or timed out now load quickly and reliably every time:

* On-time delivery reporting: up to 88% faster
* Words per hour reporting: up to 80% faster
* Quality score reporting: up to 65% faster
* AI accuracy reporting: up to 45% faster

We have also rebuilt the search indexer behind our TM editor from the ground up. Search results now stay fast, complete, and up to date even during busy periods.

### **View and Control Every MCP Connection in One Place**

Managing how your team connects LILT with external AI assistants just got easier. The new Model Context Protocol (MCP) Admin Page gives admins total visibility and control over LILT's MCP server with a centralized interface.

* Seamlessly enable or disable LILT’s MCP server integration for your entire organization using a simple On/Off toggle.
* Get immediate visibility into which external AI tools (like Claude, ChatGPT, Gemini, and Copilot) are connected, along with their live status.
* Open any client to view specific connected users and easily revoke individual connections whenever necessary.

[\[Learn more\]](https://support.lilt.com/kb/lilt-mcp-admin-page)

### **Coming soon: Change to API download filenames, effective September 8**

Starting September 8, we are standardizing file download names across the platform to include the target locale, not just the target language.

What’s changing:

* **API downloads** will move from language-only to full locale. Today, a file translated into fr-FR downloads as [filename.fr](http://filename.fr).docx via the API. After this ships, it will download as filename.frFR.docx.
* **All platform downloads** are also being updated to include locale consistently. Some parts of the LILT platform already do this today; after September 8, all of them will.

Here's how the API filenames change:

<Frame>
  <img alt="Image" />
</Frame>

## July 2026

### API Rate Limits

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 added per-organization rate limits to our document pretranslation and file-translation APIs, beginning June 30, 2026**. These endpoints aren’t changing; we’re simply introducing fair-use limits so capacity stays balanced across all our customers.

**Limits and thresholds (per organization):** A request is counted against whichever limit it touches; the two are independent.

* Request rate - 300 requests per minute
* Character throughput - 2,500,000 characters per minute

For more information, please reference our [API Rate Limiting KB page](https://support.lilt.com/developers/guides/rate-limits#api-rate-limits).

*Please note: All LILT Connectors are out of scope for these rate limits. These will only apply to the API.*

### **\[Beta] Amplience Connector: Automate Source-to-Delivery in a Few Clicks**

Seamlessly translate all your Amplience content  — web, promotional banners, and more —  using the new Amplience connector. Simply submit the job by marking the status as ready for translation and choosing your target languages and workflow — instant or expert-verified. When translation is complete, LILT delivers the content back to the repository of your choice by language or region.

[<u>\[Learn More\]</u>](https://support.lilt.com/kb/amplience)\\

### **\[Beta] Inriver Connector: Launch Global Campaigns Faster**

Eliminate the manual exports and reimports and easily translate your product-related content in Inriver using the new Inriver connector. Launch global campaigns faster and more accurately, with less manual overhead.

[<u>\[Learn More\]</u>](https://support.lilt.com/kb/inriver)

### **\[Beta] AEM Connector Enhancement: Now Translate Document Assets**

The AEM connector can now translate document assets stored in the Digital Asset Manager (DAM) including Word, Excel, PowerPoint, plain text, and HTML files. Accelerate projects without hassle by sending the original to LILT and get the translated file back into AEM using the same interface and workflow as your webpage submissions. 

\[[<u>Learn More</u>](https://support.lilt.com/kb/aem#translating-dam-asset-content)]

## June 2026

### Secure Enterprise Controls and Advanced Tooling

MCP Enterprise SaaS V1 brings robust governance and the entire LILT Assist toolkit directly into the GenAI environments our customers use every day (like Claude desktop, ChatGPT Enterprise, or homegrown internal apps). By transforming LILT into an integrated service layer, we enable customer admins to eliminate the productivity decay and security risks caused by employees context-switching and app-switching to access enterprise translation capabilities.

This major milestone introduces comprehensive enterprise controls and an expanded toolkit:

* **The Full LILT Assist Experience:** Without leaving their active LLM workflow or logging in twice, users can now access any and all functionality that’s available directly within Assist in the LILT platform.
* **Enterprise Governance & Security:** A new identify authorization workflow enables automated user identity mapping to strictly enforce native LILT Role-Based Access Controls (RBAC) and ensure compliant data handling.

### DOCX download for PDF workflow (Instant & Verified)

When translating PDF files, you can now download your translated content as a DOCX file in addition to PDF — available at the job, project, and document level, including in Instant Flow. If formatting breaks during translation, the DOCX export lets you make any layout adjustments you need in Word before re-saving as a PDF. Read more about [<u>PDF File Translation</u>](https://support.lilt.com/kb/pdf-file-translation).

<Frame>
  <img alt="Screenshot 2026 05 26 At 13 59 32" />
</Frame>

### **AI QA Interface Refresh**

[AI QA](https://support.lilt.com/kb/ai-qa-v2) has been redesigned with a streamlined interface that makes it faster to review and act on quality errors.

Previously, batch QA opened in a separate pop-out window, and linguists had limited control over how errors were displayed. All QA results now appear directly in the CAT sidebar — for both segment-level and full-document QA. Linguists can filter errors by category, severity, and check type (AI Review and AI QA), and navigate between the editor and sidebar by clicking on segments or error entries. Full-document QA results load progressively from first to last segment, so review can begin before the entire document finishes processing.

A new flag feature lets linguists report errors that aren't relevant to their language pair. Flagged errors are reviewed by LILT's research team and used to improve the AI QA model over time.

Other changes:

* AI Review and AI QA results both appear in the sidebar; use the "Check Type" filter to separate them
* Ignored errors can be shown or hidden when re-running full-document QA
* If Required Batch QA is enabled, all errors must be confirmed or ignored before submitting

These updates are to the AI QA interface only. Changes to the underlying QA model and prompt are planned separately.

### Usage Analytics

LILT platform usage analytics are now available for LILT customers on SaaS deployment! This new analytics view provides in-depth insights into word volumes, throughput statistics, and user activity throughout your organization. Read more about [<u>Volume & User Activity Analytics</u>](https://support.lilt.com/kb/volume#volume-&-user-activity).

### **AEM Cloud Connector v1.7.1**

This releases introduced a redesigned transformation rules experience to the content submission workflow in [AEM Connector Cloud](https://support.lilt.com/kb/aem) and some minor bugfixes. Contact your LILT team to receive this latest connector package.

**v1.7 updates**

* **Guided transformation rules** — A new Grouped view walks users through source/target rule setup and restricts target language selection to only languages configured in their domain, preventing invalid language codes.
* **Submission validation** — The connector now checks that transformation rules exist for all selected target languages before submission, surfaces a suggested fix if rules are missing, and allows revalidation without leaving the flow.
* **Extraction preview** — Users can now preview exactly how content will be transformed and which properties will be extracted before submitting a job.
* **Repository cloning** — Repositories can now be duplicated with one click for faster configuration of similar setups.

**v1.7.3 updates**

* **No duplicate jobs from automated submissions** — Resolved an issue where automated submissions could created duplicate LILT jobs across AEM Cloud pods.
* **MSM Live-Copy links preserved** — Translation imports can no longer strip MSM state from live-copy targets.
* **Correct handling of special characters** — Fixed issues where characters like `&` and `\\'` could be incorrectly escaped in translated content.
* **Path-picker modal fix** — Fixed the path-picker modal cutting off slug subtext in the column view on AEM Cloud.

### Updated Quality Analytics

Customers can now view quality scores broken down by locale (previously only available at the overall language level) and see average scores by language/locale pair, dynamically updated when a date filter is applied. This gives customers clearer insight into quality performance, making it easier to decide when instant translation may meet their quality bar or if verified (human) translation is still needed.

*This is only available for customers who regularly have a Secondary Review stage. Read more about [Quality Analytics](https://support.lilt.com/kb/lilt-analytics-v2#quality).*

<Frame>
  <img alt="Image" />
</Frame>

### API access tokens improvements

We’ve rolling out support for **multiple named API tokens per user**, replacing the current single-key model.

**What it solves:** Today, every org gets one API key that's shared across all their integrations — CMS connectors, CI pipelines, internal tools, etc. If any one of those is compromised, the entire account is exposed. There's also no way to rotate or expire keys independently.

**What's new:**

* **Multiple tokens per user** — admins can create as many tokens as they like, one for each integration to be managed independently.
* **Named tokens** — give each one a descriptive name (e.g., "Contentful connector," "CI pipeline") so you know what's used where
* **Rotation & revocation** — rotate or revoke individual tokens without breaking other integrations
* **Optional expiry** — set an expiration date on tokens that should be time-limited
* **Audit trail** — logs now show which specific token was used, not just which user

**What stays the same:** Existing API keys keep working — nothing breaks. The new tokens use the same `?key=` and Basic Auth transport, so all SDKs and CMS plugins work with them out of the box. New tokens will appear in a new "API Tokens" section in Settings, alongside the existing key.

Additional information available [here](https://support.lilt.com/kb/organization-settings#api).

### Adobe Workfront Connector

We’ve released the **Adobe Workfront Connector**, enabling teams to connect Workfront to LILT and streamline localization workflows without manual exporting, file handoffs, or status chasing.

* **Submit Workfront content for translation** directly from your Workfront workflow.
* **Track translation progress** through the connector so project status stays transparent.
* **Automatically deliver translated content back** into the right place in Workfront, reducing copy/paste and rework.
* **Support both Instant and Verified workflows** so you can choose speed vs. human-reviewed quality based on the content.
  <Frame>
    <img alt="Image" />
  </Frame>

Read more about the [Adobe Workfront Connector.](https://support.lilt.com/kb/adobe-workfront)

## May 2026

#### 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.

**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)

Read more about the [Job Form Editor](https://support.lilt.com/kb/Job-Form-Editor).

<Frame>
  <img alt="Image" title="Image" />
</Frame>

#### Unified PDF Translation Pipeline

LILT now handles all PDF translation through a single, unified pipeline — regardless of whether your PDF is text-based, scanned (image-based), or a mix of both.

Previously, the Platform required PDFs to be routed as either "text-based" or "image-based" at job creation, with image-based PDFs running through a separate OCR step that had to complete in the browser before the job could be created. That distinction is now gone. LILT handles both the OCR text extraction automatically for all PDFs, so every PDF follows the same path: upload → review source (optional) → translate.

Read more about [PDF Translation](https://support.lilt.com/kb/pdf-image-file-translation).

#### **Sanity Connector Enhancements**

Handle more complex content with finer content selection and save time with new search and pagination. Eliminate manual exports and launch global campaigns faster and more accurately.

Read more about our [Sanity Connector](https://support.lilt.com/kb/sanity).

## April 2026

#### LILT V4.0 - New Language Support

LILT has doubled our language support - adding **67 new languages**, including low-resource languages - to ensure no region is out of reach. With this expanded language support, customers can:

* **Extend Global Reach:** Instantly access, translate, and create content in underserved dialects across in Africa, Southeast Asia, South Asia, the Caribbean, Europe, and Oceania. Engage audiences in emerging and remote markets alike.
* **Accelerate Launches:** Capture market share faster with AI-driven speed, high-accuracy translations, and optional expert verification.
* **Unified Global Control:** Eliminate vendor chaos by centralizing your multilingual workflows and language needs in one seamless platform.

For more information, please reference:

* [LILT V4.0 model generation](https://support.lilt.com/kb/supported-languages#lilt-v4-0)
* [LILT V4.0 supported languages](https://support.lilt.com/kb/supported-languages#lilt-v4-0-supported-languages)

#### New LILT Home Page featuring LILT Assist

The LILT “Platform Home” View shows LILT Assist front and center, driving users to engage with and use Assist as a part of their daily operations within LILT.

* [LILT Assist KB page](https://support.lilt.com/kb/agent-kb)
* [The Shift to Agentic Global Content Operations](https://lilt.com/blog/the-shift-to-agentic-global-content-operations)

<Frame>
  <img alt="Image" />
</Frame>

### AEM Connector Cloud 1.5.1

This release focuses on performance and reliability improvements to the content submission workflow in [AEM Connector Cloud](https://support.lilt.com/kb/aem). Contact your LILT team to receive this latest connector package.

* **Faster content submissions** — Submissions now process smoothly even at high volume.
* **Faster error reporting** — The connector now immediately surfaces errors that can't be resolved by retrying, instead of repeatedly re-attempting and adding unnecessary delays.
* **Improved configuration resilience** — The connector now automatically recovers from temporary configuration issues and provides clearer error messages when troubleshooting is needed.
* **Quicker file upload detection** — Reduced the time it takes to confirm file uploads have completed, speeding up every file in a submission.

#### Usage Analytics

Gain in-depth insights into word volumes, throughput statistics, and user activity to demonstrate clear ROI to your leadership. Use these metrics to highlight how your program is accelerating time-to-market and expanding your global reach. For more information, please visit the [Volume & User Activity KB page](https://support.lilt.com/kb/volume).

#### Unified Job Submission Updates

* **Edit job-level custom properties after job creation.** After creating a job, your custom properties now appear as job-level metadata in the [Job Settings](https://support.lilt.com/kb/navigating-the-jobs-list#job-settings) tab, and can be edited as needed.
* **Filter by job-level custom properties.** [Search and view jobs](https://support.lilt.com/kb/navigating-the-jobs-list#filters) using the custom fields defined in the Job Form Editor. Filter by PO number, department usage, or any enterprise-specific tracking data directly within LILT.
* **Delayed secondary reviewer notification.** [Secondary Reviewer alerts](https://support.lilt.com/kb/customer-review#accessing-the-project) are now delayed until all preceding stages, such as instant or verified workflows, are complete.
* **\[Coming soon]: Custom form builder.** The Custom Job Form builder is intended to let customers configure their job submission experience at both the organization and domain level by choosing which fields appear during job creation and offering default customization. The impact is a more tailored, less overwhelming submission flow for different customer needs (including per-domain variations).
  <Frame>
    <img alt="Image" />
  </Frame>

#### Faster instant translation

Instant translation is now faster, more reliable, and more efficient than ever before. Our reengineered instant translation system efficiently handles models and data, resulting in a massive 7.5x increase in speed.

## March 2026

### Unified Job Submission - Updates

Building on the momentum of last month’s Unified Job Submission release, we released four enhancements to the feature based on customer feedback.

* **Third-party model support for Type & Translate.** Type & translate capability, i.e. instant text translations within LILT UI, now supports [third-party model providers](https://support.lilt.com/kb/instant-translate-text). This update provides consistent, high-speed translation capabilities regardless of the underlying model preference. Please note that these translations may take longer if using a provider other than LILT.
* **Job submission fields available for API submission.** The LILT API now [supports the full range of job submission fields,](https://support.lilt.com/api-reference/jobs/create-a-job) including job-level instructions and custom metadata. This ensures automated workflows maintain the same level of detail and customization as submissions via LILT Platform.
* **Edit job names for Instant > Secondary Review workflows.** You can now customize the job name when [submitting files for instant translation](https://support.lilt.com/kb/instant-translate-documents#lilt-instant-file-translation) with a Secondary Review stage. This is helpful since these jobs appear on the Jobs list.

### AEM Cloud Connector now supports Content Fragment Variations

LILT’s [**AEM Cloud Connector**](https://support.lilt.com/kb/aem) **(v1.5.0)** now supports translating Content Fragment Variations. This ensures customers who rely on Content Fragment Variations can translate all variation content, instead of only the master.

### Reviewed and Unreviewed Translation Memory States Deprecated

LILT is sunsetting reviewed and unreviewed translation memory states in [data sources](https://support.lilt.com/kb/managing-your-lilt-memories). Going forward, this state will no longer appear in the main data source table, but can still be viewed for individual segments in data sources and in the[ CAT editor.](https://support.lilt.com/kb/segment-state-indicators)

### Instant Translate - Supports 99% Matches

LILT's Instant Translate now prioritizes high-quality 99% translation memory matches over AI-generated translations in AI-driven workflows⁠⁠. These 99% matches, typically perfect matches with minor formatting differences, are now used preferentially during Instant workflow stages or pretranslation, ensuring faster and more consistent translations⁠⁠. The update keeps 99% matches unconfirmed for linguist validation in classic workflows and excludes them from AI Review (similar to exact matches), while still including them in review sampling for quality control⁠⁠. This change delivers higher quality by leveraging proven TM matches, speeds up workflows by reducing linguist intervention, and cuts costs by minimizing unnecessary AI translations and review time⁠⁠. For more information, please review [Pretranslation or Instant workflow stage](https://support.lilt.com/kb/pretranslating-documents).

## February 2026

### Unified Job Submission

Unified Job Submission is LILT’s new 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.

<iframe name="wistia_embed" />

**Additional resources**

* [Unified Job Submission](https://support.lilt.com/kb/Unified-Job-Submission)

### Job-Level Custom Properties

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.

<img alt="Image" title="Image" />

**Additional resources**

* [Job Form Editor](https://support.lilt.com/kb/Job-Form-Editor)

### 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.

As part of this release, LILT has made a change to automatically deliver files. Once all documents in a project are marked done, the project will be automatically marked as Done and Delivered.

1. This will trigger a delivery email to the customer for the project (language) that was delivered.
2. Once all projects within a job are marked as Done/Delivered, then the Job will automatically move to the Done/Delivered status.

**Additional resources**

* [Secure file delivery via LILT](https://support.lilt.com/kb/Secure-File-Delivery)

### Detect & redact sensitive data (PII)

LILT automatically detects and flags Personally Identifiable Information (PII) in segments, giving linguists full control to confirm or exclude it. Flagged segments are kept out of customers’ translation memories and AI training data, while sensitive information is automatically redacted in final exports, ensuring compliance and eliminating the risk of accidental data exposure.

<img alt="Image" title="Image" />

**Additional resources**

* [PII Omitted Segments](https://support.lilt.com/kb/PII-Omitted-Segments#pii-omitted-segments)

### Webhooks for Instant Translation Alerts

LILT’s architecture now includes webhooks for instant file translations (completed & failed), providing a robust foundation for seamless automation. Receive notifications for instant translated files to keep your global projects moving at the speed of business.

**Additional resources**

* [Webhooks](https://support.lilt.com/developers/guides/webhooks#webhooks)

### Salesforce Commerce Cloud Connector

The [Salesforce Commerce Cloud (SFCC) Connector](https://support.lilt.com/kb/salesforce-commerce-cloud) enables seamless translation of product catalogs and content directly within your Commerce Cloud instance. This integration streamlines e-commerce localization by allowing teams to submit translation orders, preview results, and deliver translated content without leaving their SFCC environment.

**What's new**

* Submit translation orders directly from the SFCC interface via the Lilt plugin.
* Choose between Instant (AI-powered) or Verified (human-reviewed) translation workflows.
* Select specific products or entire catalogs for translation with flexible language pair selection.
* Preview translations side-by-side (source and target) before delivery.

**Customer Impact**

* **Faster Time-to-Market:** Launch products in new markets quickly without manual export/import workflows.
* **Streamlined Operations:** Manage translations directly in SFCC, eliminating context switching.
* **Flexible Workflows:** Choose the right translation approach (Instant or Verified) based on content needs.
* **Quality Control:** Review translations in context before publishing to ensure accuracy.

**Feature Availability**

* GA - For customers who choose to enable this connector

**Additional Resources**

* [SalesForce Commerce Cloud Connector](/kb/salesforce-commerce-cloud)

### LILT Anthropic Marketplace Listing

LILT is now available in the [Claude Marketplace](https://claude.ai/directory/88245f33-e3a7-468f-ae27-3f118bef198a). Paying Claude users can now connect to LILT with a few simple clicks, send content to LILT for Instant and Verified translation, and check on job status right from within their Claude instance.

## December 2025

### Connector updates

We are thrilled to expand our already massive library of  100+ pre-built connectors.

* [**HubSpot Connector**](https://support.lilt.com/kb/hubspot), allows you to seamlessly translate your content in Hubspot - emails, blogs, forms, web pages, and landing pages via instant or verified workflows. This eliminates manual exports, letting you launch global campaigns faster and more accurately.
* [**BitBucket Data Center (DC) Connector**](https://support.lilt.com/kb/bitbucket), built for self-managed systems, keeps your dev team in their flow by integrating localization directly into the coding repository.
* **[Google Drive Connector](https://support.lilt.com/kb/google-drive):** Now you can save time by skipping the manual Google Connector configuration entirely and seamlessly access your files in Google Drive for translation in LILT simply using your Google account.

### TM Editor Improvements

LILT has improved our TM editor with improvements to support:

* *Multi-select entries and bulk delete.* 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.
* *Loading 100 entries at a time and per page.* Scrolling to the bottom of the table will lazy load the next 100 entries.

**Additional Resources**

* [Managing Data Source Entries KB Page](https://support.lilt.com/kb/managing-your-lilt-memories#delete-one-or-more-entries)

### **LILT – Jetzt auf Deutsch (Now in German)!**

Ab heute ist LILT auch auf Deutsch verfügbar! Our global vision just took a massive leap forward: The **LILT platform is now available in German**.

<img alt="Image" title="Image" />

**Additional Resources**

* [Language Configuration KB Page](https://support.lilt.com/kb/logging-into-lilt-for-the-first-time#language-configuration)

### Third-party Model Provider Updates

We are committed to keeping you at the cutting edge of innovation. LILT now features the latest advanced models with Anthropic Claude as an option for a [direct configuration through Anthropic](https://support.lilt.com/kb/anthropic-configuration) or via [AWS Bedrock](https://support.lilt.com/kb/aws-configuration). This includes the most updated models: **Claude Sonnet 4.5, Haiku 4.5, Opus 4.1, and Opus 4.5.**

### Reorganized Domain navigation

Navigation within Domains is updated to help users quickly identify and select the right domain from the top navigation, so they can work in the correct context without errors and easily switch between their domains. As part of this change:

* The Domain selector has been moved to the Breadcrumb navigation from the User Profile.
* The currently selected Domain/Org name is displayed in full (no abbreviations or single letters) within the breadcrumb.
* Clicking the current domain name should trigger a dropdown menu, which sorts Domains in alphabetical order and includes a search input field to filter the list of domains (essential for large lists).
  <img alt="Image" title="Image" />

## November 2025

### AI QA

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 is an in-workflow step for linguists and reviewers that integrates with LILT's existing UI for segment level QA, batch QA, and subtitling QA checks.
* 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 runs in conjunction with Automatic & Mandatory Batch QA settings, if enabled. If Mandatory Batch QA is turned on, all AI QA errors need to be accepted or ignored before the linguist can mark the document as done.

**Additional Resources**

* [LILT AI QA](/kb/ai-qa#ai-qa)

### AI Review - AI-optimized workflows

We're introducing AI Review Segment-Optimization, a new workflow that combines [AI Review](/kb/ai-review) with machine learning to deliver faster, more cost-effective translations without compromising quality. In this workflow:

* Segments are automatically evaluated after AI Review using LILT's proprietary ML Segment Prioritization model.
* Segments identified as error-free are automatically confirmed, accepted, and locked at the Review stage, allowing your linguistic team to focus only on content that needs human attention.

This workflow offers a faster, more affordable alternative to full-verified workflows while maintaining quality standards that exceed traditional translation-only approaches. It's ideal for projects where speed and cost efficiency are priorities alongside quality.

**Additional Resources**

* [AI Review](/kb/ai-review)
* [Enabling AI Review workflows](/kb/ai-review#enabling-ai-review) (see AI optimization section)

### Additional AI Review Provider - Anthropic Claude

The default provider for AI Review workflows is LILT Contextual AI, however, Anthropic Claude can now be configured as an alternative provider. To change your provider, please review the [AI Provider](https://support.lilt.com/kb/3rd-party-llm-support-for-the-contextual-ai-engine#ai-providers) configuration for your org.

<img alt="Image" />

### Separate Secondary Review assignment email

Previously, we used the same email template for both Review and Secondary Review assignments, which confused Secondary Reviewers who saw unnecessary data and information. There is now a separate assignment email for the Secondary Review stage that is tailored to the customer role and removes mentions of Linguist Contractor agreements, payment support links, and time-bound notifications.

### Improved TMX export experience

LILT invested time this month to improve the TMX export process, to make it significantly faster and more reliable. Customers will experience a much smoother and more predictable workflow, as well as an enhanced download process with clearer notifications, so you can access their files with ease.

## October 2025

### LILT Assist

LILT Assist - our AI agent automates much of the tedium that comes with localization for both translation experts and content creators. Think of Assist as a helper for all things translation, project management, analytics, and even terminology management. Starting today, and continuing over the next few weeks, we are turning on LILT Assist agent in customer batches. Be on the lookout for the Assist icon in the navigation bar, and if you can’t wait to start using it, contact your Customer Success Manager.

**Additional Resources**

* [LILT Assist KB](/kb/agent-kb)

**Feature Availability**

* Beta

### New AI Review language added

AI Review is now supported for Chinese > English (ZH > EN), improving the quality for this verified workflow. This includes all Chinese (ZH) locales.

**Additional Resources**

* [AI Review Supported Languages](/kb/ai-review#supported-languages)

**Feature Availability**

* GA

## September 2025

### Custom file loaders available during pre-processing stages

Custom file loaders are now available for all pre-processing jobs. Internal teams can now leverage pre-configured loaders, eliminating manual job recreation or workarounds for un-editable files. Read more about [LILT File Loaders](/kb/lilt-file-loaders) and [Applying a Custom File Loader after Pre-processing](/kb/lilt-file-loaders#applying-a-custom-file-loader-after-pre-processing).

### Instant Translate Analytics

We’ve introduced a powerful new set of analytics 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 within an organization. Read more about [Usage Analytics](/kb/lilt-analytics-v2#usage-analytics), and reach out to your LILT representative if you would like this turned on.

## August 2025

### Subtitling in LILT

LILT’s new subtitling and captioning functionality enables end-to-end workflows for subtitling and captioning, bringing major improvements to scalability, efficiency, quality, file security, and user experience. Key highlights include:

* In-context video review during all workflow stages, including Secondary Review, to facilitate translation and quality analysis.
* Integrated subtitling-specific QA checks that are configurable at the organization level.
* Translation for on-screen text, titles, and synopses.

Read more about [Subtitling and captioning workflows](/kb/subtitling-and-captioning#subtitling-and-captioning) at LILT.

### Structured PDF Translations

LILT users 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. Read more about [PDF Translation](https://support.lilt.com/kb/pdf-image-file-translation#structured-text-based-pdf-translation).

### Quoting

LILT now offers a versatile quoting system to provide cost transparency before translation work begins. This is particularly valuable for enterprises managing budgets across departments, organizations with tight spending controls, or when working with complex multimedia content that requires specialized handling like desktop publishing (DTP) or localization engineering. The two types of quoting LILT offers are:

* **Instant quoting** for [processable file types](/kb/supported-file-formats), which automatically generates cost estimates based on word count and language pair pricing defined in their contract before submitting jobs.
* For more complex projects, **Formal quoting** allows customers to submit files and receive a quote prepared by LILT’s production team, where quotes need approval from the submitter before work begins. These projects may be for processable or non-processable file types, and may include manual processing or text extraction.

Read more about [Quoting](/kb/quoting-in-lilt#quoting).

## July 2025

### LILT Visual Design Update - A Fresh Look

We are excited to announce the release of our new design system, which brings a cleaner and more consistent experience to the platform. This update goes live for all customers on July 31. We will continue to roll out experience updates throughout the quarter.

### Archived Jobs and Projects Available in Analytics

Analytics now provides a more accurate and complete view of your data by including archived jobs and projects. Previously, jobs were archived to keep views clean for both customers and LILT production teams, but these archived jobs, including Connector jobs after delivery, were excluded from Analytics. Read more about [Analytics](/kb/lilt-analytics-v2).

### AI Review Prompt Now Corrects Terminology Errors

LILT’s AI Review Agent now corrects terminology errors based on a customer’s termbase (TB), whenever a mismatch is detected between the target and termbase entry. This update will ensure greater consistency across translated content. Read more about [AI Review](/kb/ai-review).

### Languages in Job Creation

We have made the process of creating a job even faster and easier. The language dropdown lists will now only show source and target languages with configured models, helping to prevent errors and ensuring an efficient workflow.

### Webflow Marketplace App Launch

The [LILT - Webflow Connector](https://support.lilt.com/kb/webflow) is now live in the Webflow Marketplace, enabling prospective customers to download and configure the app directly. While some setup, like API keys, will still require production support, this new listing makes it easier to get started with the integration.

## June 2025

### Enhanced Connector Updates

**Streamlined Workflows Across Multiple Platforms** Our connector ecosystem continues to expand with significant improvements across WPML, XTM, Smartling, AEM, and SharePoint integrations.

* [**WPML Connector**](/kb/wordpress) now features Instant Pre-translation for jobs containing the “Instant” keyword, automatically bypassing the standard human-in-the-loop workflow for faster delivery.
* [**XTM Connector**](/kb/xtm-cloud) includes enhanced workflow stage handling, allowing specific workflow stages to be treated as memory resources with specialized memory configuration filters.
* [**Smartling Connector**](/kb/smartling-tms) offers improved segment workflow advancement by uploading modified XLIFF with dot-replaced segments, ensuring all segments are processed and advanced in the workflow.
* [**AEM Connector**](/kb/aem) supports automated translation workflows, enabling content to return to its original AEM location while supporting translation of tags, assets, and metadata.
* [**SharePoint**](/kb/sharepoint) now supports Microsoft’s New Graph API with simplified setup using tenant ID configuration and direct content access from the root path.

### Budget Tracking

**Enhanced Project Spend Management for Enterprises** Track project spend with comprehensive workflow management and accountability features. This new capability provides domain-specific data access control, enabling enterprises to maintain better oversight of translation costs and resource allocation.

### Additional Platform Enhancements

**Improved Performance and Capacity** Several key improvements enhance the overall platform experience: recency-based match prioritization for better translation quality, increased file upload size capacity up to 2GB, and SSO auto-provisioning support with Asgardeo/WSO2 for simplified enterprise authentication.

## April 2025

### Enhanced Domain Control

**Tailored Precision and Streamlined Workflows** Administrators now have access to a new domain-level setting to control error logging in the Review stage. This enhancement offers tailored precision, streamlined workflows, increased adaptability, and empowered administration capabilities.

### Terminology Base Entry Status

**Improved Quality with Reviewed Default Status** The default Terminology Base entry status for new data sources is now set to “Reviewed” instead of “Unreviewed”. This change addresses previous quality issues while maintaining existing data sources’ current status settings.

## March 2025

### 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.

Read more about [AI Review](/kb/ai-review).

### 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.

Read more about [AEM Connector](/kb/aem).

### 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.

Read more about [Enterprise Security](/kb/single-sign-on-sso-for-lilt-com).

### Organization-Level QA Configuration

**Tailored Quality Assurance for Your Enterprise** 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.

### 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. Read more about [Domains](/kb/lilt-domains).

### Domain-Level Reviewer Error Logging Customization

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

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.


# 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.

<br />


# 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.

<img alt="Using LILT Converse" title="Using LILT Converse" />

## Settings

To open Settings, tap the Settings icon (the gear) in the lower right of Speaker 1's screen.

<img alt="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.


# 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.

<iframe title="YouTube video player" />

# 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.


# 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.

<Frame>
  <img alt="" />
</Frame>

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.

<Frame>
  <img alt="" />
</Frame>

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.

<Frame>
  <img alt="" />
</Frame>

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.

<Frame>
  <img alt="" />
</Frame>

## 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.

<img alt="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)<br />Tags attached to a submitted page | ✅ | ✅ |
| Tags (standalone)<br />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+) |

<Note>
  **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.
</Note>

## 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.

<Note>
  Check with your LILT account team for the latest connector version.
</Note>

### 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-<version>-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://<your-aem-host>:<port>/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.

<Note>
  The connector package installs 4 components. Verify all 4 are successfully installed. If upgrading, uninstall the previous version before uploading the new package.
</Note>

**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 `<subpackages>` instead of `<embeddeds>` 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.

#### **Access Required**

To be able to access and configure the connector, users need read and write permissions to all locations under /etc/lilt-connector.

| **Location** | **Permissions needed** |
| :- | :- |
| Content being submitted | Read, so the user can select and validate the source pages/assets. |
| `/etc/lilt-connector/repositories` | Read |
| `/etc/lilt-connector/submissions` | Read/write |
| `/etc/lilt-connector/configuration` | Read |

### Step 1: Set Up the Connector in Connectors Builder

<Note>
  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.
</Note>

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.<br />Any nested fragment filter on the repository is applied within this limit. |

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.

### Step 4: 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 5: 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 6: 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 7: 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.

<Frame>
  <img alt="Screenshot 2026 05 13 At 9 55 53 Am" />
</Frame>

Once you have finished setting up the configurations, you will need to move on to setting up some repositories for translation

## 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**.

#### **Access Required**

To be able to access and configure the connector, users need read and write permissions to all locations under /etc/lilt-connector.

To submit only, the following access is required.

| Location | Permissions needed |
| :- | :- |
| Content being submitted | **Read**, so the user can select and validate the source pages/assets. |
| `/etc/lilt-connector/repositories` | **Read** |
| `/etc/lilt-connector/submissions` | **Read/write** |
| `/etc/lilt-connector/configuration` | **Read** |

### 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).
  <Note>
    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).
  </Note>
* **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.
* **Nested Fragment Filtering** (JCR Properties, v1.13+ Cloud only) — Optional allow-list or deny-list of paths that limits which nested content fragments are discovered when *Translate nested content fragments* is enabled. Leave empty to include all nested fragments.

### Translation Rules

**Transformation Rules** define how source content paths and languages map to target locations. These paths are **<u>case sensitive</u>**. 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.
  <Frame>
    <img alt="Screenshot 2026 05 11 At 3 28 36 Pm" />
  </Frame>
  * **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.
    <Frame>
      <img alt="Screenshot 2026 05 11 At 3 36 23 Pm" />
    </Frame>

### **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/*
```

<Note>
  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.
</Note>

### 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.

<Note>
  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`.
</Note>

## 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:

<Frame>
  <img alt="Screenshot 2026 05 11 At 5 14 45 Pm" />
</Frame>

**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.*
* Choose whether or not you want to include nested content fragments.
* 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.

**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/<launch-name>/…`) 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.

## 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/<launch-name>/…`. 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.

<Note>
  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.
</Note>

### 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.

<Note>
  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.
</Note>

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).

<Note>
  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.
</Note>

### 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.

<Warning>
  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
</Warning>

### 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).

<Note>
  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.
</Note>

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.

<Info>
  Standalone tag translation is available on **AEM as a Cloud Service (AEMaaCS)** only.
</Info>

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.

<Note>
  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.
</Note>

### 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:

<Steps>
  <Step title="Job Setup">
    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.
  </Step>

  <Step title="Content Selection">
    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.
  </Step>

  <Step title="Review">
    Review your selections and start the submission. All tags in the submission are combined into a single JSON file and sent to LILT.
  </Step>
</Steps>

### 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

<Warning>
  Reimport overwrites any existing locale-specific property for the delivered language, including hand-authored localized titles.
</Warning>

* **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.
* **No scheduled or automated tag submissions.** Tag jobs are started manually. When a tag folder is selected, the automation option is greyed out.
* **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.

### 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.
* If the repository has a nested fragment filter configured, only fragments that pass the filter are added. See [Filtering nested content fragments by path](#filtering-nested-content-fragments-by-path).
* 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.

#### Filtering nested content fragments by path

Available in v1.13+ for AEM as a Cloud Service. By default, nested discovery includes every referenced fragment within the max depth. If some referenced content should not be translated — shared or global components, boilerplate, or fragments owned by another team — you can filter nested discovery by path at the repository level.

**Setting up a filter**

Open the JCR Properties repository configuration and find the **Nested Fragment Filtering** section.

<img alt="Screenshot 2026 10 12 At 1 42 55 Pm" />

1. Choose a mode:
   * **Allow-list** — only nested fragments whose path matches an entry are included.
   * **Deny-list** — all nested fragments are included except those whose path matches an entry.
2. Add one path per entry, for example `/content/dam/aem-demo-assets/en/global_header`.
3. Save. The filter applies to the next submission that uses this repository with **Translate nested content fragments** enabled.

**How paths are matched**

* Entries match the exact path of a nested fragment, or a parent folder of it. To exclude a whole folder, list the folder path with a trailing slash, e.g. `/content/dam/site/en/navigation/`. This also excludes everything beneath it, such as `/content/dam/site/en/navigation/footer/countrylist`.
* A folder entry respects folder boundaries: `/content/dam/site/en/navigation/` does not match `/content/dam/site/en/navigation-old/`.
* Matching is case sensitive. `/content/dam/site/Team-A/promo` does not match `/content/dam/site/team-a/promo`.
* Wildcards, regular expressions, and partial matches are not supported.

**What to expect**

* The filter runs during nested discovery, so filtered-out fragments never appear in the Content step, the Review step, transformation rule validation, or the submission. They are skipped silently; there is no "excluded" indicator.
* Discovery does not continue through an excluded fragment. If fragment A is excluded and A is the only item referencing fragment D, D is excluded too, even if D would otherwise be allowed.
* The content you select directly in the Content step is never filtered. The filter applies only to fragments discovered automatically through the inclusion of nested fragments.
* The filter is ignored when **Translate nested content fragments** is off for a submission.
* Filters are per repository. Different repositories can use different modes and paths.
* An empty **Deny-list** includes all nested fragments, the same as having no filter. An empty **Allow-list** includes none.

**Limitations**

* One mode per repository; Allow-list and Deny-list cannot be combined.
* Filtering is by path only — not by tag, fragment model, template, property, or resource type.
* Filters cannot be overridden per submission.
* A fragment is included or excluded as a whole; individual fields cannot be filtered.
* Not available for DAM Asset Content repositories or AEM 6.5 (On-Premise).
* The max depth limit and transformation rule validation still apply to everything that passes the filter.

**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.
* Administrators can limit which nested fragments are discovered by path using an allow-list or deny-list on the repository (v1.13+, AEMaaCS only)

## FAQ / Troubleshooting

<AccordionGroup>
  <Accordion title="The Lilt Translations app is not visible after installation">
    * 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.
  </Accordion>

  <Accordion title="Cannot connect to the LILT API">
    * 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.
  </Accordion>

  <Accordion title="My submission is stuck in SENDING or IN_PROGRESS status">
    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).
  </Accordion>

  <Accordion title="Translated content appears in the wrong location">
    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`.
  </Accordion>

  <Accordion title="Source text appears in the translated output">
    * 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.
  </Accordion>

  <Accordion title="I need to cancel a translation job">
    Contact your LILT account team immediately for cancellations. They can cancel the job in LILT and help you clean up the submission in AEM.
  </Accordion>

  <Accordion title="Source content was updated after submission">
    Notify your LILT account team of any source changes. They will work with you to ensure the correct content is translated and returned.
  </Accordion>

  <Accordion title="We do quality reviews outside of LILT and have corrections to apply">
    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.
  </Accordion>

  <Accordion title="Launch Spaces and Projects">
    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.)
  </Accordion>

  <Accordion title="The 'selected' and 'sent/imported' counts don't match (e.g. 'See all 44' vs '24/24')">
    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.
  </Accordion>

  <Accordion title="A nested fragment I expected isn't in my submission">
    Check the repository's Nested Fragment Filtering section. In Deny-list mode, the fragment or one of its parent folders may be listed; in Allow-list mode, it may not be. Also check that the fragment isn't referenced only through an excluded fragment, and that the path casing matches exactly.
  </Accordion>

  <Accordion title="Submission Retention Policy">
    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.
  </Accordion>
</AccordionGroup>

## 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 <kbd>+</kbd> 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.

<iframe title="YouTube video player" />

## 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.

<iframe title="YouTube video player" />

### [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**.

<iframe title="YouTube video player" />

### [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.

<iframe title="YouTube video player" />

### [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.

<iframe title="YouTube video player" />

```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.


# 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

<Frame>
  <img alt="Screenshot 2026 07 31 At 9 54 36 Am" />
</Frame>

Content is selected, submitted, and tracked inside the LILT platform — not inside Amplience. The high-level flow:

<Note>
  **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.
</Note>

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&#39;à` 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).


# API
Source: https://support.lilt.com/kb/api



The API section lets you manage the API tokens used to authenticate with the LILT API.

API keys are managed in **Manage → API**. This page is available to Admins and Customer Admins.

<img alt="Screenshot 2026 10 01 At 1 02 48 Pm" />

### 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.

<img alt="Screenshot 2026 10 01 At 1 04 08 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.

<Frame>
  <img alt="Screenshot 2026 05 26 At 7 00 39 Pm" />
</Frame>

**Managing tokens**

The token list shows each token's name and status, owner, prefix (e.g., `lilt_abc1...`), creation date, expiry date and when it was last used. Status is shown as a badge: **Active** (green), **Expired** (gray) or **Revoked** (red).

By default, the list shows Active tokens only.

**Search:** Use the search field to find a token by name, owner or key. Click ✕ to clear the search.

**Filter:** Click **Filters** to show Active, Expired or Revoked tokens. Applied filters appear as chips you can remove.

**Sort:** Sort by creation date, expiry date or last used date, ascending or descending. Tokens expiring within 30 days show their expiry date in orange; expired tokens show it in red.

**Actions:**

* **Rotate** (active tokens): generates a new secret while keeping the same configuration.
* **Revoke** (active tokens): permanently disables the token.
* **Delete** (expired or revoked tokens): removes the token from your list. You'll be asked to confirm. Active tokens can't be deleted — revoke them first.
  <img alt="Screenshot 2026 10 01 At 2 35 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)
5. Regularly delete expired and revoked tokens to keep your list easy to manage.
6. Sort by expiry date to find tokens that are about to lapse, and rotate them before they expire.

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).


# 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.

<Frame>
  <img />
</Frame>

### 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.


# 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.

<Frame>
  <img />
</Frame>

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

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 |


# 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.

     <img alt="Proj 1 Pn" title="Proj 1 Pn" />
   * Select the project containing your repository
   * Go to **Project Settings**.

     <img alt="Proj 2 Pn" title="Proj 2 Pn" />
   * On the **Project Details** page, locate the **Project Key**.

     <img alt="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.

     <img alt="Repo 1 Pn" title="Repo 1 Pn" />
   * Go to **Settings**.

     <img alt="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.

     <img alt="Repo 1(1) Pn" />
   * Go to **Settings**.

     <img alt="Repo 2(1) Pn" />
   * On the **Repository Details** page, locate the repository URL.

     <img alt="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).

     <img alt="Api 1 Pn" />
   * Select **HTTP Access Tokens**.

     <img alt="Api 2 Pn" />
   * Click **Generate Token**.

     <img alt="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.

     <img alt="Repo 1(2) Pn" />
   * Go to **Settings**.

     <img alt="Repo 2(2) Pn" />
   * Select **HTTP Access Tokens**.

     <img alt="Repo 2(3) Pn" />
   * Click **Generate Token**.

     <img alt="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).

<Frame>
  <img />
</Frame>

## 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`

<Frame>
  <img />
</Frame>

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

<Frame>
  <img />
</Frame>

**Braze API Base URL.**

1. Grab this information from your API endpoint: [https://dashboard.braze.com/](https://dashboard.braze.com/)

<Frame>
  <img />
</Frame>

## 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`

      <Frame>
        <img />
      </Frame>

3. If you’d like to submit for Instant Translate instead of Verified Translation, add the `LILT: Instant tag`

   <Frame>
     <img />
   </Frame>

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`

   <Frame>
     <img />
   </Frame>

6. When the content translation process has an error or issue in delivery, the status will show as `LILT: Needs Attention`

<Frame>
  <img />
</Frame>


# 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!


# Connectors
Source: https://support.lilt.com/kb/connectors

Connect LILT to your CMS, code repository, file storage, or TMS for continuous localization with automatic content import and delivery.

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.

***

<CardGroup>
  <Card title="Adobe Workfront" href="/kb/adobe-workfront" />

  <Card title="AEM" href="/kb/aem" />

  <Card title="Amazon Workdocs" href="/kb/amazon-workdocs" />

  <Card title="Amplience" href="/kb/amplience" />

  <Card title="AWS S3" href="/kb/aws-s3" />

  <Card title="Azure Blob" href="/kb/azure-blob" />

  <Card title="Bitbucket" href="/kb/bitbucket" />

  <Card title="Box" href="/kb/box" />

  <Card title="Braze" href="/kb/braze" />

  <Card title="Contentful" href="/kb/contentful" />

  <Card title="Contentstack" href="/kb/contentstack" />

  <Card title="Craft" href="/kb/craft" />

  <Card title="Crowdin" href="/kb/crowdin" />

  <Card title="Drupal" href="/kb/drupal" />

  <Card title="Figma" href="/kb/figma" />

  <Card title="GitHub" href="/kb/github" />

  <Card title="GitLab" href="/kb/gitlab" />

  <Card title="Google Drive" href="/kb/google-drive" />

  <Card title="Helpshift" href="/kb/helpshift" />

  <Card title="Heretto (fka EasyDITA)" href="/kb/easydita" />

  <Card title="HubSpot" href="/kb/hubspot" />

  <Card title="Inriver PIM" href="/kb/inriver" />

  <Card title="Intercom" href="/kb/intercom" />

  <Card title="Lokalise" href="/kb/lokalise" />

  <Card title="Magento" href="/kb/magento" />

  <Card title="Optimizely (fka EPIserver)" href="/kb/Optimizely" />

  <Card title="Phrase TMS" href="/kb/phrase-tms-fka-memsource" />

  <Card title="Salesforce Commerce Cloud" href="/kb/salesforce-commerce-cloud" />

  <Card title="Salesforce Knowledge" href="/kb/salesforce-knowledge" />

  <Card title="Sanity" href="/kb/sanity" />

  <Card title="SDL TMS" href="/kb/sdl-tms" />

  <Card title="SDL WorldServer" href="/kb/sdl-worldserver" />

  <Card title="SharePoint" href="/kb/sharepoint" />

  <Card title="Shopify" href="/kb/shopify" />

  <Card title="Sitecore XP 10.0" href="/kb/sitecore-xp-10-0" />

  <Card title="Smartling TMS" href="/kb/smartling-tms" />

  <Card title="Termweb" href="/kb/termweb-connector" />

  <Card title="Trados Enterprise" href="/kb/trados-enterprise" />

  <Card title="Webflow" href="/kb/webflow" />

  <Card title="WebTranslateIt" href="/kb/lilt-connector-compatible-with-webtranslateit" />

  <Card title="WPML WordPress" href="/kb/wordpress" />

  <Card title="XTM Cloud" href="/kb/xtm-cloud" />

  <Card title="Zendesk" href="/kb/zendesk" />
</CardGroup>


# 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 <img /> icon next to your Profile avatar and Inbox at the bottom of the left sidebar.

<Frame>
  <img />
</Frame>


# 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.

   <Frame>
     <img />
   </Frame>

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

   <Frame>
     <img />
   </Frame>

4. To configure your application, you have one of two options

   1. Option 1: Configure via your Contentful account
      1. <Frame>
           <img />
         </Frame>
   2. Option 2: Configure via your LILT account
      1. <Frame>
           <img />
         </Frame>

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`.

   <Frame>
     <img />
   </Frame>

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.

<Frame>
  <img />
</Frame>

***

## 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.

   <Frame>
     <img />
   </Frame>

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.

<Note>
  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.
</Note>

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`.

   <Frame>
     <img />
   </Frame>

### 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.

   <Frame>
     <img />
   </Frame>
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`.

   <Frame>
     <img />
   </Frame>
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.

   <Frame>
     <img />
   </Frame>
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.*

<Frame>
  <img />
</Frame>

#### 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".

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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`.

     <Frame>
       <img />
     </Frame>

  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.

     <Frame>
       <img />
     </Frame>

  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.

   <Frame>
     <img />
   </Frame>

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).

   <Frame>
     <img />
   </Frame>

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.

   <Frame>
     <img />
   </Frame>

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".

   <Frame>
     <img />
   </Frame>

5. Find the LILT plugin in the list of available plugins and click on the "Install" button.

   <Frame>
     <img />
   </Frame>

**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

      <Frame>
        <img />
      </Frame>

***

## 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

   <Frame>
     <img />
   </Frame>

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

         <Frame>
           <img />
         </Frame>

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

   <Frame>
     <img />
   </Frame>

2. Here, you’ll be able to see a draft version of what the target site could look like

   <Frame>
     <img />
   </Frame>

***

## 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 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 <kbd>Create Content</kbd> 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.

<iframe title="YouTube video player" />

### Best Practices for Content Prompts

<Tip>
  The more specific you are regarding your audience and intent, the better the agent can assist you.
</Tip>

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..." 
```


# 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 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`.

<img alt="Image" title="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.

<img alt="Image" title="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** |
| <img /> | <img /> |

**Assign Reviewer** is a permission that will allow the role to assign Secondary Reviewers (customers) during job submission.

<img alt="Image" title="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

<Frame>
  <img />
</Frame>

2. Click on “File Loaders”

<Frame>
  <img />
</Frame>

3. Click on “+ New Loader” in the top right corner

<Frame>
  <img />
</Frame>

4\. Select “Segmentation Only”

<Frame>
  <img />
</Frame>

5\. In the Segmentation dropdown on the right section select “Upload Custom SRX File”

<Frame>
  <img />
</Frame>

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

<Frame>
  <img />
</Frame>

<Frame>
  <img />
</Frame>

7. After uploading the file, click Next in the bottom right corner

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

9. Click “Create” at the bottom of the screen and you SRX file loader will be ready to use.


# 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 | **✓** | **✓** | **<sup>✓2</sup>** | **<sup>✓1</sup>** | **<sup>✓1</sup>** | **<sup>✓2</sup>** |
| Create/edit Jobs | **✓** | **✓** | **<sup>✓3</sup>** | **—** | **—** | **<sup>✓3</sup>** |
| View Projects | **✓** | **✓** | **<sup>✓2</sup>** | **<sup>✓1</sup>** | **<sup>✓2</sup>** | **<sup>✓2</sup>** |
| Create/edit Project | **✓** | **✓** | **—** | **—** | **—** | **—** |
| Manage documents | **✓** | **✓** | **—** | **—** | **—** | **—** |
| Edit documents in Translate or Review mode | **✓** | **✓** | **—** | **<sup>✓1</sup>** | **<sup>✓1</sup>** | **—** |
| Assign tasks to translators and reviewers | **✓** | **✓** | **—** | **—** | **—** | **—** |
| Upload files | **✓** | **✓** | **<sup>✓3</sup>** | **—** | **—** | **<sup>✓3</sup>** |
| Download files | **✓** | **✓** | **✓** | **—** | **—** | **✓** |
| View reports | **✓** | **✓** | **—** | **—** | **—** | **—** |
| Edit Source Segment | **✓** | **✓** | **—** | **—** | **—** | **—** |
| LILT Create access (if enabled) | **✓** | **—** | **—** | **—** | **—** | **✓** |
| Analytics | **✓** | **✓** | **✓** | **—** | **—** | **✓** |

<sup>1</sup> *Translators and reviewers can only view jobs/projects they have been assigned to.*

<sup>2</sup> *Can only see project information, no personal identifiers about linguists assigned.*

<sup>3</sup> *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 | **✓** | **<sup>✓1</sup>** | **—** | **—** | **—** | **—** |
| Manage integrations | **✓** | **—** | **—** | **—** | **—** | **—** |
| Create/edit roles | **✓** | **—** | **—** | **—** | **—** | **—** |

<sup>1</sup> *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 | **✓** | **—** | **—** | **—** | **—** | **—** |

<sup>1</sup> [**`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).


# 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`.

<Frame>
  <img />
</Frame>

3\. Enter the package URL that you want to install and click Install.

<Frame>
  <img />
</Frame>

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`.

<Frame>
  <img />
</Frame>

<Frame>
  <img />
</Frame>

### Configure LILT provider

1\. Go to the `Translation` > `Providers` page.

<Frame>
  <img />
</Frame>

2\. On the LILT provider entry, click the `Edit` button.

<Frame>
  <img />
</Frame>

3\. Enter the LILT API Key, and click `Save`. *Note: the URLs will default to the correct values, and the remaining values are optional.*

<Frame>
  <img />
</Frame>

## 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`.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

<Frame>
  <img />
</Frame>

### Job progress and completion

1\. Navigate to `Translation`>`Jobs` to view a list of all current jobs.

<Frame>
  <img />
</Frame>

2\. Find the desired job and click `Manage` to open the job.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

4\. Click `Review` to preview the translation.

<Frame>
  <img />
</Frame>

5\. Click `Save` to complete. The translation will be published once it is completed.

<Frame>
  <img />
</Frame>


# 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.


# 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 <kbd>Analytics</kbd> 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.

<iframe title="YouTube video player" />

### 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]."
```


# 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.

<Frame>
  <iframe />
</Frame>

## Configuration

<Frame>
  <iframe />
</Frame>

1. Install the LILT plugin from the [Figma Community](https://www.figma.com/community):

   * In Figma, navigate to `Plugins` > `Browse plugins in Community`.

     <Frame>
       <img />
     </Frame>

   * 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:**

       <Frame>
         <img />
       </Frame>

   * 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.

<Frame>
  <img />
</Frame>

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.


# 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 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

<ParamField type="string">
  Your Google API Client ID from the Google Cloud Console
</ParamField>

<ParamField type="string">
  Your Google API Client Secret from the Google Cloud Console
</ParamField>

<ParamField type="string">
  OAuth 2.0 refresh token for ongoing access to your Google Drive
</ParamField>

##### Drive Configuration

<ParamField type="string">
  The full folder path from the root of the Shared Drive (e.g., `Customer Folder/Production/Lilt`)
</ParamField>

<ParamField type="array">
  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.
</ParamField>

<ParamField type="object">
  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.
</ParamField>

<ParamField type="string">
  The Team Drive ID where your translation files are stored. Optional, but typically needed when connecting to a Shared Drive rather than My Drive.
</ParamField>

<ParamField type="string">
  The folder path for exported translated files. If not specified, files are exported to the same location as import
</ParamField>

#### 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

<ParamField type="array">
  List of glob patterns to exclude specific files (e.g., `["**/temp/*", "**/*.tmp"]`)
</ParamField>

### Google Drive-Specific

<ParamField type="string">
  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).
</ParamField>

<ParamField type="boolean">
  Operate on the "Shared with me" folder instead of My Drive.
</ParamField>

<ParamField type="boolean">
  Use the created date instead of the modified date when checking for changes.
</ParamField>

<ParamField type="string">
  Used with the `--drive-impersonate` flag to access a specific user's folder.
</ParamField>

## 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.


# 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.


# 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.

<Frame>
  <img alt="Image" />
</Frame>

**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
   <Frame>
     <img alt="Image" />
   </Frame>
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
   <Frame>
     <img alt="Image" />
   </Frame>

### 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**
   <Frame>
     <img alt="Image" title="Image" />
   </Frame>
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.

<Frame>
  <img alt="Image" />
</Frame>

### 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"]`

<img alt="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


# 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.


# 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.

<Frame>
  <img alt="Image" />
</Frame>

## How to setup

1. As an Admin user, navigate to Manage > Users. Select the Role tab, and click "New role".

   <Frame>
     <img alt="Image" />
   </Frame>
2. Create an AI Only User Role. Set Default Home view as "AI Only Home" and Role type as "AI Only".

   <Frame>
     <img alt="Image" />
   </Frame>
3. Enable permissions for the role.
   * Enable Create/Edit permissions for "Instant Translate".
   * Enable Upload/Download permissions for "Files".

     <Frame>
       <img alt="Image" />
     </Frame>
4. Navigate to Users and User Management. Set the new Instant Translate Role for an existing user.

<Frame>
  <img alt="" />
</Frame>

*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.*


# 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.

<Frame>
  <img />
</Frame>

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".

   <Frame>
     <img />
   </Frame>

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`.

     <Frame>
       <img />
     </Frame>

   * 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.

     <Frame>
       <img />
     </Frame>

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`.

   <Frame>
     <img />
   </Frame>

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.

   <Frame>
     <img />
   </Frame>

## 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.

<Frame>
  <img />
</Frame>


# 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.


# 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

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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).

<Frame>
  <img />
</Frame>

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

<video />


# 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



<Note>
  LILT Create has been retired and consolidated into **LILT Assist**. Content generation is now available through Assist's Content Creation capability.
</Note>

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.

     <Frame>
       <img alt="" />
     </Frame>
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.***

     <Frame>
       <img alt="" />
     </Frame>
   * 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.

       <Frame>
         <img alt="" />
       </Frame>
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.

<Frame>
  <img alt="" />
</Frame>

> **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.

   <img alt="Image" title="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.

<Frame>
  <img alt="" />
</Frame>

### 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.”

<Frame>
  <img alt="" />
</Frame>

## 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.

<Frame>
  <img alt="" />
</Frame>

### 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.

   <img alt="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.


# 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.

<Frame>
  <img alt="MCP Admin Navigation" />
</Frame>

## **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.

<Frame>
  <img alt="LILT MCP On Off Toggle" />
</Frame>

## **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.


# 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.

<Frame>
  <img alt="" />
</Frame>

* **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.

<Frame>
  <img alt="" />
</Frame>


# 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.

<Frame>
  <iframe />
</Frame>

## 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.

   <Frame>
     <img />
   </Frame>

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.

   <Frame>
     <img />
   </Frame>

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.


# 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.
   <Frame>
     <img alt="" />
   </Frame>
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).
   <Frame>
     <img alt="" />
   </Frame>
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.
   <Info>
     💡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.
   </Info>
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.**
   <Info>
     💡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.
   </Info>
3. Choose a translation workflow.
   <Info>
     💡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.
   </Info>

### 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.


# 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 <kbd>Generate termbase</kbd> card.
2. Tell the agent what content to analyze:
   * Click <kbd>+</kbd> 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.

<iframe title="YouTube video player" />

### 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..."
```


# Organization Owners
Source: https://support.lilt.com/kb/organization-owners



Every organization using LILT's services must have one account designated as the organization owner. The owner isn’t necessarily the owner of your company, but rather the account of the person in charge of localization, for example, the localization manager. While typically the organization owner is assigned to the most senior person on the localization project, each organization can choose what works best for them.

Users with roles that permit them to create and edit team members (administrators and managers) can see a list of all members in the organization by navigating to the `Organization > Users` tab.

<Frame>
  <img />
</Frame>

The organization owner:

* is always an [Administrator Role](/kb/default-roles)

* is listed at the top of the member list

* has their `Name` displayed in bold

<Frame>
  <img />
</Frame>

The owner can utilize [Role-Based Access Control](/kb/role-based-access-control) to [Add Users](/kb/adding-users-to-an-organization) and [Reassign Roles](/kb/reassigning-user-roles) as needed.


# Phrase TMS
Source: https://support.lilt.com/kb/phrase-tms-fka-memsource



The LILT + Phrase TMS connector enables you to automatically push and pull web content between Phrase TMS and LILT, providing seamless localization in the systems you know.

## Setting up the Phrase connector

In order to connect Phrase to LILT, you'll need LILT's vendor token, which our Solutions team will provide to you.

### 1. Add LILT as a Vendor in Phrase

1. In Phrase, navigate to **Settings** > **Administration** > **Vendors** and click **+ New**
2. Enter LILT's vendor token provided to you by LILT
3. Specify any relevant source languages, target languages, clients, domains, subdomains, and workflow steps
4. Click **Save** to link the LILT vendor account to your Phrase instance

### 2. Create a LILT Connector User

Create a user in Phrase for assigning translation jobs:

1. Create a user with email: `connector-accounts+{companyName}@lilt.com`(replace companyName with your company name)
2. Assign the **Project Manager** role with the following permissions:
   <img alt="Phrase TMS Project Manager permissions" />

### 3. Configure Single Project (Optional)

If you're using a single Phrase project for all translations:

1. Note the project ID from your Phrase project
2. Share this project ID with LILT so we can bind the connector to that specific project

### 4. Create Translation Memory and Termbase Import User

Create a separate user for TM and TB synchronization:

1. Create a user with email: `connector-accounts+tm+{companyName}@lilt.com`(replace companyName with your company name)
2. Assign the **Project Manager** role and grant the following permissions
   <img alt="Phrase Tms Permissions Pn" title="Phrase Tms Permissions Pn" />

### 5. Notify LILT

Contact LILT once you've completed the following:

* Added the vendor
* Created the translation user
* Created the TM/TB import user
* Identified the single project ID (if applicable)

### 6. Connector Setup and Testing

LILT will complete the connector setup, which includes:

* A round-trip test using AI-only translation to ensure connectivity
* Assigning a test file to verify the integration works properly

### 7. Configure TM/TB Import Frequency

Discuss with LILT the frequency of Translation Memory and Termbase imports.  Translation memories and termbases in Phrase can be queried and imported into LILT on a set schedule so that any updates to these in Phrase are reflected in LILT.

To achieve this, create another user in Phrase with the email address - [connector-accounts+tm+@lilt.com](mailto:connector-accounts+tm+\{companyName}@lilt.com).

Assign that user to a **Project Manager** role with the permissions below and alert your LILT team to create a new connector for TM/TB syncing.

<Frame>
  <img alt="Image" title="Image" />
</Frame>

## Sending files to LILT for translation

To send files from Phrase to LILT:

1. In your Phrase project, select the files you want to translate
2. Click **Edit**
   <img alt="Phrase TMS file selection" />
3. Choose the LILT vendor you created as the provider
4. Set status to **New**
5. Add an optional due date if required
6. Click **Save**
   <img alt="Phrase TMS vendor settings" />

The LILT connector will poll and import these files into LILT for translation automatically. Once translation is completed, the files will be returned to your Phrase project automatically.

## Importing content back into Phrase from LILT

Once the translation is completed and delivered in LILT, the LILT Phrase connector will run again on the same schedule to check if any files are ready to be delivered back to Phrase and once complete, the translated files will automatically appear in your instance of Phrase.

### TM and TB Sync

This feature responds directly to customer feedback, allowing for selective import of TMs based on specific requirements.

### Importing Translation Memories

* **Selective Import Options**: Users can choose to import only those TMs for which they have appropriate permissions, enhancing security and compliance with access controls.
* **Automatic Project Synchronization**: During the import process, TMs are automatically associated with corresponding projects in LILT, ensuring consistency across platforms.

### Importing Term Bases

* **Streamlined Integration**: Similar to TMs, TBs from Phrase can be imported seamlessly into LILT projects, maintaining uniformity in terminology usage across both platforms.

**Workflow Compatibility**: The feature is designed to work best with certain project workflow configurations. To avoid potential conflicts and ensure optimal functionality, some configurations might be less compatible when used simultaneously with this feature.

**Segment Statuses**

1. `Confirmed` segments from Phrase TMS are marked as confirmed in LILT as well
   1. Confirmed includes 100% and 101% pre-translated matches
2. Fuzzy matches will show up for linguists as drafts

**Noteworthy Features**

1. The LILT connector will update ***all*** relevant intermediary workflow steps’ statuses in Phrase with their respective progress
2. The LILT connector will map distinct domain Data Sources based on the Content Type indicated in the Project Name
3. The LILT connector segment statuses set in Phrase TMS to LILT Translate will be available for linguists to reference


# Plurals Support
Source: https://support.lilt.com/kb/plurals-support-1



### **Background**

Plurals are a mechanism of language that allows a speaker or writer to differentiate types of nouns or phrases. In English we have two plural forms singular and plural. These forms are represented in different ways:

* Standard: appending an “-s”, “-es” or changing “-y” to “-ies” for a singular noun.

  * Example: cat - cats, baby - babies

* Irregular plural: some nouns do not follow specific rules

  * Example: mouse - mice

* No change: some nouns have no change between forms

  * Example: deer - deer,

* Latin and Greek: some forms derive from Latin or Greek origin

  * Example: cactus - cacti

English forms are just the beginning, in Arabic there are six forms and completely different rules. The localization industry has created multiple syntax’s including ICU and i18n to support this eccentricity of language.

## **LILT’s Plural support**

### What we support

At LILT we provide automated support for plurals created with ICU, Android, and iOS libraries. Users can upload files with the ICU syntax, easily translate, and export with correct formatting.

#### ICU

LILT supports ICU plural functions, in addition to the other [ICU functions](/kb/plurals-support). Product strings or product documents uploaded with ICU plural functions can be automatically processed by our filters. For [linguists these plurals will appear in the CAT](/kb/cat-icu-plurals) as any other [plural form](https://www.unicode.org/cldr/charts/45/supplemental/language_plural_rules.html) we automatically filter.

```swift theme={null}
{applesCount, plural, 
    zero {{pearsCount, plural, 
        zero {{orangesCount, plural, 
            zero {I have no fruit}
            other {I have some oranges}
        }}
        other {{orangesCount, plural, 
            zero {I have some pears}
            other {I have some pears and some oranges}
        }}
    }}
    other {{pearsCount, plural, 
        zero {{orangesCount, plural, 
            zero {I have some apples}
            other {I have some apples and some oranges}
        }}
        other {{orangesCount, plural, 
            zero {I have some apples and some pears}
            other {I have some apples, some pears, and some oranges}
        }}
    }}
}
```

#### Android

LILT supports Android plurals. Product strings or product documents uploaded with ICU plural functions will be automatically processed by our filters. For [linguists these plurals will appear in the CAT](/kb/cat-icu-plurals) as any other plural form we automatically filter.

XML

```xml theme={null}
<!-- Snippet from source EN Android XML File -->
<plurals name="number_of_beds">
		<item quantity="one">%d bed</item>
		<item quantity="other">%d beds</item>
</plurals>
```

#### iOS

LILT supports iOS plurals. Product strings or product documents uploaded with ICU plural functions will be automatically processed by our filters. For [linguists these plurals will appear in the CAT](/kb/cat-icu-plurals) as any other plural form we automatically filter.

XML

```xml theme={null}
<!-- Snippet from source EN .stringsdict File -->
<plist version="1.0">
    <dict>
        <key>number_of_beds</key>
        <dict>
            <key>NSStringLocalizedFormatKey</key>
            <string>%#@count@</string>
            <key>count</key>
            <dict>
                <key>NSStringFormatSpecTypeKey</key>
                <string>NSStringPluralRuleType</string>
                <key>NSStringFormatValueTypeKey</key>
                <string>d</string>
                <key>one</key>
                <string>%1$d bed</string>
                <key>other</key>
                <string>%1$d beds</string>
            </dict>
        </dict>
    </dict>
</plist>
```

### What we don’t support

If it not above, it is not supported. To answer some specific questions, we do not 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

* MT/Pre-translation within the plural modal. Linguists will not receive plural form suggestions.


# Prompt Response
Source: https://support.lilt.com/kb/prompt-response



This page details how to submit, view, respond, and review Prompt Response jobs.

## File structure

Files must be an XLSX or CSV file and must be monolingual when uploading through the UI. Each row is a separate prompt. There are two ways to upload a job through the UI:

1. With columns in a specific order using the following headings:

   1. id - A unique identifier for the prompt

   2. prompt - The prompt itself

   3. usecase - Any specific domain or use case associated with the prompt (if available). *Note: This column must be present, even if there is no usecase from the customer.*

   4. prompt\_EN - The relevant prompt in English, if provided.

   5. Prompt response - Leave empty, but this will be where the prompt responses will be downloaded.

2. With columns in any order with a file filter implemented. To request a file filter, please reach out to the CE team.

## Submitting a job

1. Click “Build” on the LILT Evaluate module.

2. Upload your files and reference materials (XLSX or CSV). Please see the “[File structure](https://lilt.atlassian.net/144c66a75a50803ea3ddfc520060fd0e?pvs=25#144c66a75a5080e7844dca75d6e34b12)” section above for more information on how to structure your file. Reference materials are available for download from the Data Sets UI in the sidebar while the linguist is responding/reviewing.

   <Frame>
     <img />
   </Frame>

3. Add a Job Type.

4. Add a Job Name and source language. Document any additional guidelines, and add a due date. Additional guidelines are provided to the linguist as context in the LILT Evaluate sidebar, and are also included in the assignment email.

5. Click “Submit”.

   <Frame>
     <img />
   </Frame>

6. Once your job is created, you’ll receive a confirmation email (as you would for a Translate job). Your job will be in the “Ready to Start” stage.

   <Frame>
     <img />
   </Frame>

## Viewing open jobs

The Evaluate Browse Jobs page displays a list of all your Active, Archived, and Delivered jobs. This page works the same way as the Translate Browse Jobs page.

The jobs in this list will identify that they are in the Prompt Response + Prompt Review workflow.

<Frame>
  <img />
</Frame>

If you expand the dropdown arrow, you can see all projects and project-level stats for % complete, language, delivery due date, and the linguists assigned.

## Prompt Response UI

Linguists will see assigned Prompt Response work in their Linguist Homepage if they’ve been manually assigned. The chip details if it’s Prompt Response or Prompt Review work, and they can accept or reject the assignment.

<Frame>
  <img />
</Frame>

The prompt response UI is structured similarly to the CAT editor, but has had the irrelevant functionality removed.

* Linguists can see the prompt in green on the left side. If there was the English version of the prompt included in the upload, they can also click to “See prompt in English”.

* At the bottom of the page, there is a box for them to write their response.

* The upper right corner of the page will display how many prompts are remaining.

* If linguists expand the Task bar, they can view the job-specific guidelines and any additional reference materials added to the submission as a download.

  <Frame>
    <img />
  </Frame>

Once the linguist writes their response, they click “Confirm”. They can choose to edit it if needed. Clicking “Mark done” will mark the prompt as done and take them to their next prompt response.

<Frame>
  <img />
</Frame>

Once all prompts have been responded to, the status will change from “Responding” to “Prompt response complete”. The linguist can then exit the editor view.

<Frame>
  <img />
</Frame>

## Prompt Review UI

In the prompt review stage, linguists should read the following prompt and review the response. They can leave a comment or edit the response if they find errors or issues.

The prompt review UI will display the prompt response in a box in the lower right.

<Frame>
  <img />
</Frame>

If the reviewer has any changes to make, they should click “Edit”. This will re-open the response box, and the linguist can make any changes. Once they’re satisfied, they can click “Update”.

<Frame>
  <img />
</Frame>

After making any changes, the linguist can leave a note describing the change they made.

<Frame>
  <img />
</Frame>

Once they are happy with the overall prompt response, they can click “Accept”. This will cycle them through the prompts until they’ve accepted all the prompts. Once all prompts have been reviewed, the status will change from “Reviewing” to “Prompt review complete”. The linguist can then exit the review view.

<Frame>
  <img />
</Frame>

## Downloading completed prompt response jobs

Once the project has been completed, you can download the completed prompts from the “Deliver project” button at the top of the project.

* The file will download in whatever format was used to upload the project (XLSX or CSV).

* The prompt response will display in the sixth column.

* Each prompt will have its own row.

  <Frame>
    <img />
  </Frame>


# Reassigning User Roles
Source: https://support.lilt.com/kb/reassigning-user-roles



LILT makes it easy for Managers and Administrators to edit the roles of members as the structure and needs of your organization shift. This article explains how to change member roles.

*Note that managers cannot change the roles of administrators.*

To reassign the role of a member, navigate to the `Manage > Users` tab.

<Frame>
  <img />
</Frame>

Next, locate the user you want to edit and click the `Edit` buttonnext to their entry. Apopup will open where you can set the member’s role to the available default roles and any [Custom Roles](/kb/custom-roles) that have been created.

<Frame>
  <img />
</Frame>

Note that members are not notified when their role has been changed, so if you change a member’s role, it is recommended to let the member know what access they have within your organization.


# Removing Users From An Organization
Source: https://support.lilt.com/kb/removing-organization-members



Managers and administrators have the ability to remove users from an organization. Note that managers cannot remove administrators.

To remove a user from your organization, navigate to the `Organization > Users` tab.

<Frame>
  <img />
</Frame>

Next, locate the user you want to remove and click the trash icon next to their entry.

<Frame>
  <img />
</Frame>

Clicking the trash button will open a popup to confirm you want to remove the user from the organization.

<Frame>
  <img />
</Frame>


# Role Based Access Control
Source: https://support.lilt.com/kb/role-based-access-control



Teams are easy to manage on LILT with Role-Based Access Control (RBAC). The system works by giving different permissions to different roles and then assigning each team member to one of the roles. RBAC comes with [Default Roles](/kb/default-roles) for administrators, managers, translators, reviewers, customer reviewers, customers, and LILT Create users. If the predefined roles don’t match your needs, you can create[Custom Roles](/kb/custom-roles) to tailor LILT to your organization’s structure.

Administrators and Managers can access the RBAC tools by clicking on the `Manage`> Users and then clicking on the Rolestab. Note that the `Roles` page is only available to Administrators.

<Frame>
  <img />
</Frame>

Within these pages, you have access to all the team management tools you need to:

* [add users](/kb/adding-users-to-an-organization)

* [remove users](/kb/removing-organization-members)

* [change user roles](/kb/reassigning-user-roles)

* [create, edit, and delete roles](/kb/custom-roles)


# Roles FAQ
Source: https://support.lilt.com/kb/roles-faq



Below are answers to some frequently asked questions regarding role-based access control.

## Projects

### Can a Project's ownership be changed once it has been created?

No. However, if the Project was created by a user with organization permissions to create Projects, the primary owner of the Project is the organization, not the user. That means that if the user who created the Project is removed from the organization, the organization still has full control over the Project and the user no longer has control of the Project.

### Are Projects created by Translators or Reviewers private?

Yes, projects created by Translators or Reviewers are effectively private. No-one else (including admins) can see them.

### Can administrators see all projects?

No, administrators cannot see projects created by users who do not have organization permissions to create Projects (which by default are translators and reviewers).

## Assignment

### Is it possible to force assign people such that they do not need to accept?

No, currently, assignees must accept or reject assignment.

### Who can I assign to a document for translation or review?

Non-organization members can be assigned to documents as a translator or reviewer. However, please note that only individuals within your organization can be assigned as Customer Reviewers due to the level of data access they would receive.

### Can assignment be performed at the Project level rather than Document level?

No, assignments are at the Document level. However, it is possible to batch assign all documents in a Project in either of the following ways:

* From the [Projects List](/kb/navigating-the-projects-list) page, click a Project's action dropdown menu and then click the `Assign` option.

<Frame>
  <img />
</Frame>

* Open a Project to the `Documents` page, click the “Select all” option, and then clicking `Assign` (as described in the [Bulk Document Actions](/kb/bulk-document-actions) article).

## Roles

### Is self-organization possible in the permissions model?

The permissions model is top-down; i.e., there is no self-organization.

### Does the API support user and role management?

No, there is currently no API support for user and role management; this is only available in the UI. However, don't hesitate to write us if this is a feature you need!


# Salesforce Commerce Cloud
Source: https://support.lilt.com/kb/salesforce-commerce-cloud

The Salesforce Commerce Cloud Connector allows you to seamlessly translate your product catalog and content directly from within Salesforce, eliminating manual exports and enabling faster global launches. Read below for configuration information. 

## **Prerequisites**

* Access to **Salesforce Account Manager** ([account.demandware.com](https://account.demandware.com/)) with permissions to create and manage API clients.
* Access to **Business Manager** for your Commerce Cloud instance (for cartridge registration and code deployment, if applicable).
* Your **organization ID** and **instance short code** (e.g. from your SFCC project or Account Manager).
* For cartridge installation: **Node.js** and **npm**, and (if using the upload CLI) a cartridge archive and optional `dw.json` configuration.

***

## **1. Enable SCAPI and API credentials**

The connector uses **SCAPI (Salesforce Commerce API)** with OAuth 2.0. You need to create an API client in Account Manager, assign the **Salesforce Commerce API** role, and configure it for your organization and instance(s). Use your SFCC/Account Manager documentation for the exact steps.

***

## **2. Enable product write and catalog read**

For the connector to read and update product data (including translating products in bunches), your API client must have **product write** and **catalog read** permissions enabled in Account Manager. Configure the required OAuth scopes according to your SFCC documentation.

***

## **3. Configure the connector**

You need to provide the following details so Lilt can set up the connector configuration on the Lilt side. All of these are required for connector setup.

* `sfcc_data_url` — SCAPI Data API base URL (e.g. `https://shortcode.api.commercecloud.salesforce.com`).
* `sfcc_auth_url` — OAuth token URL (e.g. `https://account.demandware.com/dwsso/oauth2/access_token` or the SLAS/Account Manager URL in use).
* `sfcc_client_id` — API client ID from Account Manager.
* `sfcc_client_secret` — API client password (client secret).
* `sfcc_organization_id` — Organization ID.
* `sfcc_bm_user_id` / `sfcc_bm_user_password` — Business Manager user credentials (used when using BM user grant instead of client credentials).

***

## **4. Install cartridge from archive**

To deploy the connector cartridge to your SFCC instance, use the **Salesforce Commerce Cloud CLI** (`sfcc-ci`). Install it if needed (`npm install -g sfcc-ci`), then run:

```
sfcc-ci code:deploy $(ZIP_FILE) --activate
```

Replace `$(ZIP_FILE)` with the path to your cartridge zip (e.g. `./connector-cartridge.zip`). The `--activate` flag activates the deployed code version. Ensure your environment is configured for your instance (e.g. via `dw.json` or environment variables as required by `sfcc-ci`).

***

## **5. How to use the connector**

To start working with the connector, in the **right vertical navbar** in SFCC go to **Lilt** and open the **Orders** page.

<img alt="SFCC1" />

If it is your first time, you will be prompted to enter your **Lilt Plugin API** token. Enter it and click **Save**.

<img alt="SFCC2" />

After the token is saved, you will be redirected to the Orders page, where you can create your first order or see the list of already submitted orders.

<img alt="SFCC3" />

### **Creating a new order**

To create a new order, choose **Translate** or **Create your first translation order**.

**Choose the flow:**

* **Instant** — Translation runs instantly without human involvement.
* **Verified** — The order is created on the Lilt platform and requires linguists to translate or verify it, depending on your workflow.

In the new order form, choose **source and target languages**, enter an **order name**, and select **products or catalogs** you want to translate. Then click **Submit for translations**.

<img alt="SFCC4" />

After you submit, the order is sent to the Lilt platform.

<img alt="SFCC5" />

### **When the job is done**

When the job is done, you can **Preview** or **Deliver** it.

<img alt="SFCC6" />

* **Preview** — Opens a modal with available files and languages. Open one of the files to see content **side by side**: source content on the left, target content on the right.

  <img alt="SFCC7" title="SFCC7" />
* **Deliver** — If everything looks good, click **Deliver**. This starts the process of writing translations to your files.

  <img alt="SFCC8" title="SFCC8" />

Once delivery is complete, the order status changes to **Complete**.

<img alt="SFCC9" title="SFCC9" />

***

## **6. References**

* [Use the API Clients API | Account Manager](https://developer.salesforce.com/docs/commerce/account-manager/guide/api-clients.html) – Create and manage API clients.
* [Authorization Scopes Catalog | SCAPI](https://developer.salesforce.com/docs/commerce/commerce-api/guide/auth-z-scope-catalog.html) – OAuth scopes for SCAPI (e.g. `sfcc.products`, `sfcc.products.rw`, `sfcc.catalogs`).
* [Authorization for SCAPI Admin APIs](https://developer.salesforce.com/docs/commerce/commerce-api/guide/authorization-for-admin-apis.html) – Admin API authentication.
* [Cartridges | B2C Commerce](https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/b2c-cartridges.html) – Cartridge overview and structure.
* [Upload and Configure Cartridges (Trailhead)](https://trailhead.salesforce.com/content/learn/modules/b2c-cartridges/b2c-cartridges-upload-configure) – Upload and configure cartridges.


# Salesforce Knowledge
Source: https://support.lilt.com/kb/salesforce-knowledge



LILT + Salesforce Knowledge connector enables companies to automatically push and pull knowledge base content from Salesforce. This saves you time by providing seamless localization while letting you continue to work in the systems you know.

**Watch this 3-minute overview** to see what LILT + Salesforce Knowledge can do for you. 🎥

<Frame>
  <iframe />
</Frame>

## Configuration

1. [Create a new Salesforce user](https://help.salesforce.com/articleView?id=sf.adding_new_users.htm\&type=5) called "LILT".

2. Provide your LILT account representative with the credentials for the Salesforce "LILT" users.

## Workflow

Once the connector is configured, content is automatically moved between LILT and Salesforce as outlined in the sections below.

### Project creation

1. In your Salesforce translation workflow, assign your content piece to the new "LILT" user and click `submit`.

2. LILT periodically checks for new content under the "LILT" user and imports those files as Projects into LILT for translation.

### Project completion

LILT periodically checks for completed Projects. Completed project content is automatically delivered back into Salesforce for approval and publishing.


# Sanity
Source: https://support.lilt.com/kb/sanity

Connect Sanity to Lilt for seamless, AI-driven translations.

## Overview

The LILT Sanity Connector streamlines the localization of your Sanity CMS content. By integrating directly with your Sanity Studio, you can request translations for your documents and receive translated content back without leaving your CMS. The connector is a Sanity Studio v3 plugin. The connector can support complex content models including nested and embedded content, and both instant (AI-only) and verified (human-reviewed) translation workflows.

## Prerequisites

* Sanity Studio v3 project
* Node.js >= 18
* A Sanity API token with **read + write** permissions (created in Sanity management console > API settings)

## Setup

### Step 1: Install dependencies

### 1a. Configure npm for LILT packages

Add to `.npmrc` in the project root:

```text theme={null}
//npm.pkg.github.com/:_authToken=<GITHUB_TOKEN>
@lilt:registry=https://npm.pkg.github.com
always-auth=true
```

The GitHub token needs `read:packages` scope. LILT will provide this or the customer can generate one with access to the LILT org.

### 1b. Install packages

```bash theme={null}
npm install @lilt/sanity-plugin @sanity/document-internationalization
```

### Step 2: Add language field to translatable schema types

Every document type that should be translatable **must** have a hidden `language` field. Without it, the connector cannot see the document.

## Overview

```tsx theme={null}
import {defineField} from 'sanity'

// Add this field to each translatable document type
defineField({
  name: 'language',
  type: 'string',
  readOnly: true,
  hidden: true,
})
```

Example in a full schema type:

```tsx theme={null}
export default defineType({
  name: 'blogPost',
  title: 'Blog Post',
  type: 'document',
  fields: [
    defineField({
      name: 'language',
      type: 'string',
      readOnly: true,
      hidden: true,
    }),
    defineField({name: 'title', type: 'string', title: 'Title'}),
    defineField({name: 'body', type: 'array', title: 'Body', of: [{type: 'block'}]}),
    // ... other fields
  ],
})
```

**Types that should NOT have the language field** (and will not be translatable):

* Tag or category types used only for internal classification (e.g., ArticleTag, CaseStudyTag)
* Script or code embed types
* Types that only contain references, images, or non-text configuration

### Step 3: Configure plugins in sanity.config.ts

```tsx theme={null}
import {defineConfig} from 'sanity'
import {liltPlugin} from '@lilt/sanity-plugin'
import {documentInternationalization} from '@sanity/document-internationalization'

export default defineConfig({
  // ... existing config (projectId, dataset, etc.)

  plugins: [
    // 1. Document internationalization (manages language variants)
    documentInternationalization({
      supportedLanguages: [
        {id: 'en', title: 'English'},
        {id: 'es', title: 'Spanish'},
        {id: 'de', title: 'German'},
        // Add all target languages here
      ],
      schemaTypes: [
        'blogPost',
        'page',
        // List every translatable document type name
      ],
    }),

    // 2. Lilt translation plugin
    liltPlugin({
      languageField: 'language',
      connectorUrl: '<PROVIDED_BY_LILT>',    // Lilt connector backend URL
      pluginApiUrl: '<PROVIDED_BY_LILT>',    // Lilt Plugin API URL
    }),

    // ... other plugins (deskTool, etc.)
  ],
})
```

LILT will provide the `connectorUrl` and `pluginApiUrl` values during onboarding. These are environment-specific.

### Step 4: Deploy and verify

1. Deploy the updated Sanity Studio
2. Open Sanity Studio in a browser
3. Click the LILT tab in the top navigation bar
4. Authenticate with the connector token (provided by LILT during onboarding)
   <Frame>
     <img alt="Image" />
   </Frame>
5. Verify translatable document types appear in the resource type dropdown
6. Verify documents load in the list view

## How Translation Works

### Browsing and selecting content

The LILT plugin provides a resource browser within Sanity Studio for selecting content to translate.

**Resource type filtering:** Use the resource type dropdown to filter by content type (e.g., Pages, Blog Posts). Document types appear with names based on their schema type.

**Search:** Use the search field to find specific documents by name within a selected resource type.

**Pagination:** For resource types with many documents, navigate through paginated results. Selections persist across pages when using bulk selection.

> **Note:** Only published documents appear in the connector. Draft-state documents are not shown.

### Creating a translation job

1. In the LILT tab, click **Translate**
2. Select your translation type:
   * **Instant** — translation with AI and no human intervention, delivered automatically
   * **Verified** — translated and then reviewed in the LILT platform
3. Choose source and target languages
4. Select documents from the resource browser
5. Click **Submit for translation**
   <Frame>
     <img alt="Image" />
   </Frame>

### Tracking translation status

After submission, jobs progress through the following stages: **Draft → Submitted → In-progress → Complete**.

**Instant translations** are processed automatically and delivered back to Sanity once complete. No further action is required after submission — simply wait for the job status to reach “Complete,” then import.

**Verified translations** are sent to the LILT platform for human review. In most configurations, this will be completely managed by the LILT team. Once the LILT expert completes their review, the translated content is delivered back and the job status will update to “Complete.”

### Importing translations

1. In the **Orders** tab, find a completed job (status: “Delivered”)
   <Frame>
     <img alt="Image" />
   </Frame>
2. Click **Preview** to review translations
   <Frame>
     <img alt="Image" />
   </Frame>
3. Click **Import** to create translated variants in Sanity

### What happens after import

* A new **draft variant document** is created for each target language
* The source document is **never modified**
* Translated variants appear in the document’s **Translations** panel (language picker)
* Variants are created as **drafts** by default and must be manually published in Sanity Studio
* The document slug receives a language suffix (e.g., `my-page` becomes `my-page-de`)
* A **Translation Metadata** section becomes visible on translated documents in the Sanity Studio sidebar, showing translation status and links between source and translated variants

### Re-translating content

Submitting the same document for the same target language again will **overwrite** the existing translation variant. No duplicates are created.

## Troubleshooting

### “I can’t see my document type in the resource dropdown”

The document type is likely missing the `language` field. Add it to the schema and redeploy. Additionally, non-translatable types (such as tag or category types) are intentionally excluded from the dropdown.

### “I can’t find a specific document in the list”

* The document may be in **draft state**. Only published documents appear in the connector.
* Try using the search field to narrow the results.

### “Translation is missing some fields”

All string and text fields are extracted by default. If specific fields should not be translated (such as slugs, image references, or display settings), ask your LILT contact to configure DNT (Do Not Translate) filters. Conversely, if fields you expected to be translated are missing, contact your LILT representative to review the content extraction configuration.

### “Where are my translated documents?”

After import, translations appear as draft documents. Look for them in:

1. The **Translations** panel on the source document (language picker)
2. The document list, filtered to the target language
3. Under **Translation Metadata** in the Sanity Studio sidebar

### “How do I delete a translation?”

Navigate to the **Translation Metadata** section in the Sanity Studio sidebar for the translated document. From there you can delete the translation metadata entry. Note that this removes the link between the source and translated variant — the translated document itself may need to be deleted separately.

### “My nested content wasn’t translated”

Check with your support team to see if your connector setup supports translating nested entries or not. This setting to translate nested entries can be configured by the LILT Team using the field `sanity_include_nested_content`.

### “My job is stuck or shows an error”

If a job remains in “In-progress” for an unexpectedly long time or you see an error during import, try the following:

* **Refresh the page** and check the job status again in the **Orders** tab. Temporary connection issues can sometimes cause the status to appear stale.
* **Re-submit the job** if the status has not progressed. Submitting the same document again will not create duplicates — it will update the existing translation.

## What LILT Configures

These are handled by the LILT team during onboarding:

* Connector creation and API credentials
* Translation memory and model configuration
* Workflow configuration (instant vs. verified)
* Content filters (DNT rules for non-translatable fields such as slugs, images, and display settings)
* Resource type visibility and excluded types
* Whether nested entries are included for translation or not.


# SDL TMS
Source: https://support.lilt.com/kb/sdl-tms



The LILT + SDL TMS connector enables companies to automatically push and pull web content between SDL and LILT. This saves you time by providing seamless localization while letting you continue to work in the systems you know.

## Configuration

1. Within SDL, create a new user and provide its login credentials to your contact at LILT. For this example, we'll call the user "LILT SDL User".

2. Create a workflow template that assigns this user as the linguist under the “translate” step.

## Workflow

Once the connector is configured, content is automatically moved between LILT and SDL as outlined in the sections below.

### Project creation

Create a translation project in SDL under the LILT SDL User. LILT periodically checks for new projects assigned to the LILT SDL User. When found, new content is automatically pulled into LILT to create new LILT Projects where the content can be translated.

Existing memories in SDL are automatically shared to LILT and are continuously updated with changes made in LILT. In SDL, you can specify any TMs you want to share with LILT.

### Project completion

LILT periodically checks for LILT Projects marked as `Done`. When found, the content of these completed Projects is automatically sent back into SDL and the workflow step is advanced for final review and approval in SDL.


# SDL WorldServer
Source: https://support.lilt.com/kb/sdl-worldserver



The LILT + SDL WorldServer connector enables companies to automatically push and pull web content between WorldServer and LILT. This saves you time by providing seamless localization while letting you continue to work in the systems you know.

## Configuration

1. Within WorldServer, create a new user with the role of `pm` or `customer_pm` and provide its login credentials to your contact at LILT. For this example, we'll call the user "LILT WorldServer User".

2. Create a workflow template that assigns the LILT WorldServer User as the linguist under the `translate` step.

## Workflow

Once the connector is configured, content is automatically moved between LILT and WorldServer as outlined in the sections below.

### Project creation

Create a translation project in WorldServer using the workflow template created in the configuration steps. This automatically assigns the project to the LILT WorldServer User. LILT periodically checks for new projects assigned to the LILT WorldServer User. When found, new content is automatically pulled into LILT to create new LILT Projects where the content can be translated.

Existing memories in WorldServer are automatically shared to LILT and are continuously updated with changes made in LILT. In WorldServer, you can specify any TMs you want to share with LILT.

This video demonstrates project creation in WorldServer:

[\<ac:image ac:align="left" ac:layout="align-start">\<ri:attachment ri:filename="4402621147031-sdl\_worldserver\_project\_creation\_696x351.gif" ri:version-at-save="1" />\</ac:image>](../__attachments/11370694/4404665920535-worldserver_project_creation_2876x1450.gif?inst-v=8633d73d-9ae2-4b9a-ace9-a81b872bab86)

### Project completion

LILT periodically checks for LILT Projects marked as `Done`. When found, the content of these completed Projects is automatically sent back into WorldServer and the workflow step is advanced for final review and approval in WorldServer.


# Sharepoint
Source: https://support.lilt.com/kb/sharepoint



LILT + [Sharepoint](https://www.microsoft.com/en-us/microsoft-365/sharepoint/collaboration) connector enables companies to automatically push and pull content between Sharepoint and LILT. This saves you time by providing seamless localization while letting you continue to work in the systems you know.

## Overview

The SharePoint LILT connector is an integration tool designed to streamline the content translation process between SharePoint and LILT. This connector inherits its core functionalities from the base FileSystem connector, making it consistent with other filesystem-based connectors such as Google Drive, Dropbox, and git. Additionally, it supports WebDAV connections, offering flexibility in terms of API usage and authentication methods.

The SharePoint x LILT connector supports a range of features and workflows that enhance productivity and translation management:

* **File Import/Export**: Utilizes SharePoint folders for importing source documents and exporting translated files.

* **Flexible File Handling**: Includes patterns to specify which files to include or exclude during the synchronization process.

* **Advanced Path Mapping**: Uses templates to determine export paths for files based on file type, target language, and other attributes.

* **Automated Memory Management**: Automatically creates translation memories for new language pairs, facilitating ongoing translation efforts.

* **Customizable Workflows**: Supports various translation workflows like direct translation, review phases, and customer reviews, configurable per project needs.

* **Integration with LILT API**: Leverages the LILT API for seamless translation management, supporting features like pretranslation and use of translation memories.

* **Error Handling and Notifications**: Configurable to send error messages and notifications through Slack, enhancing monitoring and response times.

* **Security and Authentication**: Secure OAuth implementation for authentication with the SharePoint instance, ensuring data integrity and security.

## Setup

* In SharePoint:
  1. **Create** a new SharePoint Add-In for LILT
  2. **Register** the add-in in Azure AD
  3. **Grant** the add-in the following API Permissions:
     * `Files.Read.All`: Allows the add-in to read all files in SharePoint.
     * `Sites.Read.All`: Allows the add-in to read site information.

To configure the SharePoint LILT connector, the following information is required:

* **SharePoint URL**: The base URL of the SharePoint instance (e.g., `https://xxxxxxx.sharepoint.com/sites/LILT`).
* **SharePoint Add-In Credentials**:
  * **Client ID**: The client ID of the SharePoint Add-In.
  * **Tenant ID**: The tenant ID associated with the SharePoint instance.
  * **Client Secret**: The client secret of the SharePoint Add-In.
* **Folder and File Configuration**:
  * **Source Folder**: The specific SharePoint folder(s) where source language files will be placed.
  * **Target Folder**: The specific SharePoint folder(s) where translated files will be delivered.
  * **Nested Folders**: A list of all nested folders within the "Source Folder" that need to be processed.
  * **File Extensions**: A list of all file extensions to be processed (e.g., .docx, .xlsx, .pptx). It is recommended to provide sample files to create appropriate filters.

Once all this information is provided, the LILT team can proceed with the connector configuration.

## Workflow

* **Job creation**: Place source files in the designated "Source Folder" in SharePoint. The connector will periodically check this folder for new or updated files and automatically create new LILT jobs for translation.

* **Job delivery**: Upon job completion in LILT, translated files are automatically exported back to the specified "Target Folder" in SharePoint.


# Shopify
Source: https://support.lilt.com/kb/shopify



The LILT Connector for Shopify 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 Shopify account.

2. Go to the Shopify app store and search for "LILT Connector."

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.

   <Frame>
     <img />
   </Frame>

5. Contact us through [this link](https://resources.lilt.com/contact-us) and tell us “I need a LILT token for the Shopify app”.

   <Frame>
     <img />
   </Frame>

6. Our team will reach out to help with everything needed to start translating your Shopify 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).

   <Frame>
     <img />
   </Frame>

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 Shopify app.

## Pricing

The app is free to download and will be charged on a wordcount basis. After downloading the Shopify app, click into the Pricing tab on your menu, upon which you’ll see the following packages listed below. From here, you will be able to choose the package that works the best for you!

Pricing Packages

1. **1 Language Package**

   * **Price:** \$2,200

   * **Words Included:** 10,000 new and fuzzy Verified words

   * **Instant Translate:** 15,000 words

   * **Validity:** 2 months from your first translation

   * 1 Source & Target Language Pair

   The Language Package is designed for those who need swift and reliable translation services within a defined timeframe. It's a cost-effective solution for both individuals and businesses looking for a short-term translation commitment.

2. **3 Language Package**

   * **Price:** \$6,450

   * **Words Included:** 30,000 new and fuzzy Verified words

   * **Instant Translate:** 45,000 words

   * **Validity:** 2 months from your first translation

   * 3 Source & Target Language Pairs

   The 3 Language Package offers expanded language support, ideal for those seeking multilingual communication capabilities. Connect with diverse audiences effortlessly and broaden your reach.

3. **5 Language Package**

   * **Price:** \$10,500

   * **Words Included:** 50,000 new and fuzzy Verified words

   * **Instant Translate:** 75,000 words

   * **Validity:** 3 months from your first translation

   * 5 Source & Target Language Pairs

   For organizations with extensive translation needs over a more extended period, the 5 Language Package is the optimal choice. Reach and engage with a global audience without interruption.

Enhance Your Package with Add-Ons!

* **Add-On: 3,000 words**

* **Price:** \$720

* **Words Included:** 3,000 new and fuzzy Verified words

* **Instant Translate:** 4,500 words

* **Validity:** 3 months from your first translation

Need more translation capacity? Our Add-On option allows you to extend your package and never run out of words when you need them.

<Frame>
  <img />
</Frame>


# Sitecore XP 10.0
Source: https://support.lilt.com/kb/sitecore-xp-10-0



# **Overview**

The Sitecore Connector allows for seamless integration between your Sitecore CMS and LILT, enabling automated content translation workflows.

## **Supported versions**

This connector supports Sitecore Experience Platform 10.0. 

## **Installation**

The connector is installed as a standard Sitecore package, which you will receive from the LILT team. Ensure all dependencies are met before proceeding with the installation. To install the LILT plugin for Sitecore:

1. Navigate to the main Sitecore dashboard and select "Control Panel".
2. Navigate to Administration -> Install a package
3. In the modal window that's presented, select "Choose Package"
4. Then "Upload".
5. Then select the relevant zip file to upload. If you have not yet received an installation package, contact your LILT representative for support.
6. Then press "Next".
7. Choose the package you've just uploaded and press "Open".
8. Then press "Next".
9. Then press "Install".
10. If Sitecore states that the item already exists, select "Overwrite".
11. Then press "Apply".
12. When the installation is complete, restart the Sitecore Client and close the window. When you reopen Sitecore and visit the dashboard, you’ll see a new option under "LILT" called "Translation".

## **How to mark fields as translatable**

In Sitecore, translation is controlled at the field level, not automatically for the whole item. These field-level settings can be configured using the process below. **Only Versioned fields should be used for translatable content.**

### **Shared vs. Unshared vs. Versioned fields**

* **Shared fields**
  * Same value across *all languages*
  * Shared fields are not translatable
  * Examples: IDs, settings, toggles, system metadata
* **Unshared fields**
  * Same across languages, different per version
  * Unshared fields are *usually not used for translation*
* **Versioned fields**
  * Different per language *and* per version
  * **Versioned fields are your translatable content**
  * Examples: titles, body copy, CTAs, descriptions

When creating or editing a field in a Template:

1. Go to **Template Builder**
2. Select the field
3. In the **Data** section, check:
   * **Shared** → unchecked
   * **Unversioned** → unchecked
4. Result: the field is **Versioned** (and therefore translatable)

There’s no checkbox called “Translatable”. Sitecore treats fields as untranslatable by default unless they are configured as Versioned.

## **How to access LILT translation inside Sitecore**

After the plugin is installed, LILT translation is accessed from the LILT plugin area in Sitecore, primarily via the Jobs interface:

1. Open Sitecore and navigate to the LILT translation plugin.
2. Go to the Jobs tab.
3. Use the Jobs UI to create, submit, sync, and review translation work.

### **Create a translation job**

1. Click New Job to open the Job review page.
2. Provide a Job name and confirm the Job status (starts as *Draft*).
3. Choose Source language (defaults to the Sitecore site language).
4. Choose Target language(s). Options are restricted to languages already added in Sitecore.
5. Click Add a page to open a page-selection modal:
   1. Browse pages in a tree/menu.
   2. Select pages (or groups of pages) and confirm to add them to the job.
6. Review the job’s page list:
   1. Each entry shows title, version selector, author, created/updated date.
   2. Warnings appear if a page is already on another active job (*Submitted* / *In progress*).
7. Choose a Translation workflow (e.g., Instant or Verified).
8. Click Save to keep the job as a draft (returns to Jobs list).

### **Submit to LILT for translation**

When ready:

1. From the Jobs list (or job page), click Translate. This is only available when status is *Draft*.
2. The plugin exports content to LILT and, on success, updates the job status to Submitted.

Once submitted, the job becomes read-only in Sitecore.

### **Track progress**

1. Users click Sync Job(s) on the Jobs page (or inside the job) to refresh status.
2. Status progresses to In progress when translation begins in LILT.

### Receive translated content 

When the translation is complete, the plugin downloads translated files and updates the placeholder target-language page versions by:

1. Clearing placeholder text.
2. Inserting translated text while keeping the original formatting/layout intact.

The Sitecore job status then updates to Complete.

After completion:

1. The job is no longer editable, but the UI is no longer “greyed out.”
2. Users can open the translated page versions, preview, and publish using normal Sitecore publishing flows.
3. Completed jobs can be deleted from the Jobs list. Deleting the job does not delete the created page versions.


# Smartling TMS
Source: https://support.lilt.com/kb/smartling-tms



The LILT + Smartling TMS connector enables companies to automatically push and pull web content between Smartling TMS and LILT. This saves you time by providing seamless localization while letting you continue to work in the systems you know.

## Configuration

1. Within Smartling, create a new user **with the PM role** and provide its login credentials to your contact at LILT. For this example, we’ll call the user “Smartling User”.
2. Create a workflow template that assigns this user as the linguist under the “translate” step. Share this with your LILT contact.
3. Provide all languages and locales you’d like to have enabled as part of your workflow to your LILT contact
4. Invite the LILT contact to your project needing translation

## Workflow

Once the connector is configured, content is automatically moved between LILT and Smartling as outlined in the sections below.

### Project creation

Create a translation project in Smartling under the LILT Smartling User. LILT periodically checks for new projects assigned to the LILT Smartling User. When found, new content is automatically pulled into LILT to create new LILT Projects where the content can be translated.

### Project completion

When a project is "Delivered" in LILT, translations are sent back into Smartling and a workflow step is advanced for final review and approval in Smartling.

## FAQ

**Q: Why are some segments from Smartling not imported into Lilt?**

**A:** Segments that are "locked 100% matches" in Smartling are not included in the XLIFF file that Lilt receives. This is intended behavior from the Smartling side, and Lilt cannot change this as it's a limitation of the Smartling API that Lilt uses.

**Q: Why doesn't the Smartling connector show up in the new Connectors UI?**

**A:** The connector needs to have an `liltOrganizationId` associated with it to appear in the new UI. Connectors created through the older `connectors-admin` tool might not have this ID, but it can be added by a Customer Engineer.

**Q: What is the logic behind the `.` character being added to strings in the Smartling connector?**

**A:** The `.` was added to work around Smartling's caching logic, forcing it to accept segments that were unchanged in Lilt. This is under active development and may change in the future.

**Q: Is it possible to show Lilt statuses in Smartling?**

**A:** It is not currently feasible to show Lilt statuses directly in Smartling due to limitations in Smartling's API.


# Tags QA Limitations
Source: https://support.lilt.com/kb/tags-qa-limitations



Due to the nuances of different languages, the [Tags Quality Assurance](/kb/tags-quality-assurance) checks may not always determine the correct placement of tags. When an error is raised during QA Checks, if the linguist has confirmed tag placement is correct, they can override the raised error and continue to deliver the Project.


# Team Resources
Source: https://support.lilt.com/kb/team-resources



This article explains how Jobs and Data Sources are accessible to different team members of an organization.

## Jobs accessibility

Jobs are owned by individuals, but when a manager of an organization creates a Jobs, the Job is treated as a resource of the organization (even if the manager leaves the organization). Below are all the rules for Job accessibility.

**Role accessibility:**

* Current organization administrators and managers can access all the organization’s Jobs.

* Translators and reviewers can only access Jobs they are assigned to (regardless of what organization they are in).

**Job creation:**

* Jobs created by current administrators and managers of the organization are treated as the organization’s Jobs.

* Jobs created by translators and reviewers are always treated as private Jobs that are not accessible to the organization.

* Jobs created by any user while they are not part of the organization are treated as private Jobs that are not accessible to the organization. Even if the user later joins the organization, Jobs created before joining remain private.

## Data Source accessibility

Jobs created by current organization members (including translators and reviewers) can leverage any Data Sources the organization has available.


# Terminology Management
Source: https://support.lilt.com/kb/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 client-facing materials (such as a website), the customer's marketing and branding department may need to get involved.

* When dealing withterminology in a product, a product team and technical writing team would make the final decision.

For these reasons, the localization department of the customer typically does not have final decision-making authority for terminology. Instead, customer reviewers are responsible for making the final decision on terminology.

## Term submission process

When Liltlancers 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 appear within any document sharing the same LILT Data Source.

## Term submission guidelines

Term submission should be done with caution since the decision-making responsibility belongs to the customer. Keep the following points in mind when you want to add or approve a new term.

### Do

* 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 Translation Data Source doesn’t already contain the term you want to add in any form (singular, plural, lowercase, capitalized, or as part of combined words).

* 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 the following metadata to each entry you add:

  * Part of speech (POS)

  * Context

### Don't

**Don't add:**

* 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


# Termweb
Source: https://support.lilt.com/kb/termweb-connector



## Setup and Configuration Guide for the LILT-Termweb Connector

This guide will help you set up and configure the connector between LILT and Termweb to seamlessly sync your terminology between the two platforms.

### Prerequisites

Before starting, ensure the following prerequisites are met:

* A **dictionary** must exist in TermWeb:

  * It should contain one or more concepts with target language translations.

  * At least one target term must have a **blank** or **Published** "Term Process Status."

  * **Note**: Terms with the **Deprecated** status will not be transferred to LILT.

- A **Data Source** must be mapped in the connector. Terms will sync or update in this specified Data Source.

- All terms synced via this connector will use the default term status (Draft, Unreviewed, or Reviewed) based on the Data Source settings. To change this default status:

  1. Open the **Settings** panel of the Data Source.

  2. Set the **Default TB Entry Status**.

### Steps in TermWeb

1. **Create a LILT Account**: Ensure you have an account with LILT. It is recommended that the password expiration is set to 'indefinitely' for continuous connectivity.

2. **Set Up Permissions**: Determine how content is shared or assigned to LILT. Termweb has user-based permissions for various **Dictionaries** and potentially API usage permissions. (Refer to TermWeb documentation for API usage permissions.)

3. **LILT User Settings**: The user in LILT must have an **Administrator Role**.

### Running the Connector Job

To transfer terms (as a .tbx file) from Termweb to LILT, ensure the following:

1. **Connector Configuration**: All fields listed above in the "Configuration" section must be filled out.

2. **Dictionary in Termweb**:

   * Must contain at least one **term** (concept) with:

     * A target language entry.

     * A "Term Process Status" that is **not Deprecated** (should be **blank** or **Published**).

3. **Trigger the Import**:

   * Set up the **Schedule** and **Next Schedule** fields, or

   * Click the **Submit Import Job** button to start the process manually.

### FAQs and Technical Details

1. **What term metadata is available through the Termweb API?**

   * Review Termweb API documentation to understand the available metadata and how it integrates with LILT.

2. **Handling Multiple Translations**:

   * If a term has multiple translations in a single language (e.g., French), only the first translation will be imported. Consider use cases where this might need to change.

3. **API Calls for Language Codes**:

   * Use the `/dictionaries` endpoint in Termweb to retrieve language codes required for configuration.

4. **Handling Term Updates**:

   * If a term is updated in Termweb, the new version will be included in the subsequent file added to the associated LILT Data Source.

### Workflow Summary

1. **Log in to Termweb**.

2. **Select the Dictionary** with the terms to import.

3. **Open the Connector Configuration** in LILT and complete the setup as described.

4. **Submit the Terms** through the connector.

5. **Open the Target Data Source** in LILT to confirm the imported terms.

6. **Manage Resources**: Verify the file upload and term import status.


# Trados Enterprise
Source: https://support.lilt.com/kb/trados-enterprise



LILT +[Trados Enterprise](https://www.rws.com/localization/products/trados-enterprise/) connector enables companies to automatically push and pull web content between Trados Enterprise TMS 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, contact your LILT Account team for assistance.

2. You will need to provide your LILT Account team with the following information to ensure that the necessary configurations are enabled for integration between your LILT and Trados Enterprise instances. If you need assistance finding any of the below information in Trados, a member of LILT’s Solutions team can support collecting these during an onboarding call.

   1. Trados API URL ([https://lc-api.sdl.com/public-api/v1/](https://lc-api.sdl.com/public-api/v1/))

   2. Trados Authentication URL ([https://sdl-prod.eu.auth0.com/oauth/token](https://sdl-prod.eu.auth0.com/oauth/token))

   3. Trados Client ID

   4. Trados Tenant ID (Found in the Manage Accounts page of Trados)

   5. Trados User ID ( This can be found by navigating to Users tab on Trados and clicking on your user. The User ID will be at the end of the URL)

      * NOTE: The LILT user must be one of the following roles to achieve necessary permissions for the integration: \{“Admin”, “Developer”, “Project Manager”}

3. The LILT team will also ask you about your workflow preferences to derive any optional configurations for the LILT + Trados Enterprise connector. This may include:

   1. Your workflow stage names

   2. Target data sources

   3. Optional setting to auto-create new data sources for new language pairs

   4. Project naming conventions, including any custom fields from Trados you would like to include in the LILT project names.

   5. Intention to sync full translation memories or termbases from Trados to LILT

***

## **Setting up Translation Workflows to be sent to LILT**

1. In Trados Enterprise, create or edit a Workflow on the **Resources > Workflows** tab such that the LILT User (from step 2f above) is the default assignee for the workflow stage where translation should occur. Alternatively, LILT can be assigned on a project-by-project basis if you prefer not to have a default assignee for the entire workflow.

2. (OPTIONAL) If you intend to use the LILT + Trados Enterprise connector to transfer and sync Data Sources, the Workflow should also include a dedicated stage with the LILT User assigned.

***

## **Sending a Request for Translation**

### **Project creation**

1. Create a Project in Trados with the relevant workflow (defined above)

2. In the **General** tab:

   1. Select source and target languages

   2. Add a Description (which will be sent to LILT as Project Notes)

   3. Select “Default File Type Configuration”

   4. Upload translatable and reference files to the project and designate these in the “Usage” column, respectively

3. Click “Next”

4. In **Translation Engine** tab:

   1. Select “LILT Translation Engine”

   2. Remove any Translation Memories by hovering on the row and clicking the “X” icon. These translation memories will be automatically mapped to LILT in a later step.

5. Click “Next”

6. No changes specific to LILT are needed in the **Pricing Model** tab. Click “Next”.

7. In the **Workflow** tab:

   1. Select your translation workflow and click “Create” to kick off the project in its workflow.

### **Viewing the Project in Trados Enterprise**

1. Once the project has pre-processed, you can see it in the **Stages** tab of the selected Project.

2. Once in the translation stage assigned to LILT, you will be able to see LILT translation statuses for each target language.

   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 Trados Enterprise 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 status in Trados Enterprise 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 Trados Enterprise. Your language pair statuses will update in real time as they are delivered.

   4. Once all languages are complete the project can be moved to the next stage of the workflow.

***

## **Optional Features**

### **Domain-specific Data Sources**

If you would like LILT translations to leverage distinct data sources that are domain-specific, you can notify your LILT Account team during the connector configuration stage of onboarding. They will ask you for the following information to configure the LILT + Trados Enterprise connector accordingly:

1. The “Name” and associated “Trados Domain API Internal ID” of the Custom Field which designates the domain or content type of each Project created in Trados Enterprise.

2. Which data sources (in LILT) should be designated with each domain or content type. This will drive the mapping.

Your LILT Account team will then configure your connector to automatically detect this domain information projects are sent to LILT for translation.

### **Data Source Sync (workflow stage)**

In some scenarios, it can be beneficial to re-sync the translation memory from Trados to LILT after the translation step - e.g. after an external in-context review. You can optionally set up the LILT + Trados Enterprise connector with a specific workflow stage that re-syncs the translation memory. If you would like to set this up, you can notify your LILT Account team during the connector configuration stage of onboarding. They will ask you for the following information to configure the connector accordingly:

1. What “Workflow Stage Name” from Trados Enterprise you wish to trigger the sync to LILT

2. Whether or not you want duplicate entries to be skipped when importing to LILT (default/recommendation is to skip duplicates)

### **Termbase Sync (separate configuration)**

If terminology changes are happening outside of LILT, it can also be helpful to configure a regular cadence of syncs, e.g. weekly or daily, to ensure that LILT always has the most up-to-date terms during translation. If you would like to set this up, you can notify your LILT Account team during the connector configuration stage of onboarding. They will ask you for the following information to configure the connector accordingly:

1. Termbase “Name” and associated “Trados resource id” in Trados Enterprise. The resource id can be found at the end of the URL of the selected termbase.

2. Which Data Sources in LILT should receive updates from Trados.

3. Frequency at which you would like to have updates sent to LILT.


# Translate with Assist
Source: https://support.lilt.com/kb/translate-with-assist



LILT Assist allows users to translate text or complex files (e.g., documents, presentations, websites) into multiple languages using a conversational AI interface.

### Key Features

* **Intelligent Content Analysis:** Assist automatically identifies context, file formats, and source content to ensure proper processing.
* **Strategic Recommendations:** Based on content analysis, Assist recommends the best approach—choose **Instant Translation** for speed or **Verified Translation** for quality-critical, expert-verified content.
* **Workflow Orchestration:** Automate the localization lifecycle, including task assignments, handoffs, and real-time progress monitoring.
* **Terminology & Style Management:** The Agent ensures adherence to your brand-specific glossaries and style guides for consistent global communication.
* **Seamless Delivery:** Receive notifications when jobs are done and download completed files directly within the Assist chat.

### How to Use

1. To get started, use a prompt (e.g., *"Translate a document"*) or click the <kbd>Translate Content</kbd> card.
2. Click <kbd>+</kbd> to upload single files (see [supported file formats](https://support.lilt.com/kb/supported-file-formats#supported-file-formats)) or entire folders. You can also paste text directly into the chat.
3. Define your source/target languages and quality requirements (e.g., *"English to Spanish, verified translation"*).
4. Review the Agent’s proposed plan (file details, languages, and workflow) and confirm to begin.
5. Ask Assist for an update at any time by providing the project name, ID, or asking for past projects.
6. Once notified (via LILT or email), you can download the finished file directly in the Assist interface.

<iframe title="YouTube video player" />

### Best Practices for Translation Prompts

<Tip>
  The more specific you are regarding file names, languages, and deadlines, the better the agent can assist you.
</Tip>

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 done? (*Translate, check status, quote*)
* **Object:** What are you working with? (*File, text, project ID*)
* **Parameters:** Key details (*Languages, workflow type, scope*)
* **Context:** Any special requirements? (*Deadline, quality level, target audience*)

### Quick-Start Prompts

**New Translation Requests**

* *Translate this marketing brochure from English into Portugese and French.*
* *Translate my product manual from English to Japanese. I need Verified Translation.*
* *Translate this internal memo to Korean using Instant Translation.*
* *Upload and translate this file to Spanish, French, and German using verified translation.*

**Status and Strategy**

* *Give me the status of all projects sent for translation this week.*
* *Show me the status of my recent translation projects.*
* *What's the progress on my \[Project Name] translation job?*
* *Give me the status of all projects sent for translation into Italian this year.*

### Sample Agent Interactions

```text theme={null}
User: "I have a marketing brochure in English that I need translated to Spanish and French"

Assist: "I can help you translate your marketing brochure. Let me ask a few questions:
- Do you have the file ready to upload?
- Is this for external customers or internal use?
- Do you need human review for quality assurance?"

User: "Yes, I have the file. It's for customers, so quality is important."

Assist: "I'll set up a workflow with human review to ensure high quality. Let me create a translation project for you..."
```

```text theme={null}
User: "Check the status of my most recent verified translation project?"

Assist: "I'd be happy to help you check the status of your most recent verified translation project. Let me gather that information for you.

Your verified translation project from English to German (Germany) was created on 02-18-2026. The project contains 420 source words and is currently in the Translation stage.

You can view the full project details at this link."
```


# Translating JSON Files
Source: https://support.lilt.com/kb/translating-json-files



LILT offers the ability for you to translate JSON files. This article outlines how LILT imports JSON data.

## Configuration

Please reach out to the Production Team at [production@lilt.com](mailto:production@lilt.com) to configure this functionality, as this has to be done on a Project basis.

## Workflow

When uploading JSON files to a Project with JSON uploading enabled, LILT understands that not all content within a JSON file is intended to be translated. When LILT detects this, the content that is not meant to be translated is imported as segment metadata.

Let's look at how LILT would load the following example JSON file:

```json theme={null}
{
  "title": "This is the title of something, it's translatable",
  "productKey": "12BCLKJ1283"
}
```

LILT will recognize that the `title` data is translatable and will load it as the segment source text.

LILT will recognize that the `productKey` data is not translatable, so instead, it is treated as content group metadata. Metadata is displayed within LILT on the individual segments.


# Best Practices For Productivity
Source: https://support.lilt.com/kb/translator-best-practices-360020816133



This article is a compilation of productivity tips for translators and reviewers that will help you get the most out of the LILT platform.

## How can I increase my productivity in LILT Translate?

1. **Don't wait for suggestions.** Typing the translation directly can often be faster than waiting for the suggestions to update. Instead of relying on machine translation suggestions, try to only consider the suggestions during pauses in typing.

2. **Ignore suggestions if you know the translation.** When you're a fast typist, and you know the translation, the machine assistance will only slow you down.

3. **Learn the advanced [Hotkey](/kb/hotkeys) shortcuts** to avoid using the mouse.

   * **Post-edit if and when you want to.** Use the hotkey `Shift`+`Enter` to insert the full suggestion, and then make manual changes from there. This technique can be faster when you only want to make minor changes.

   * **Learn the copy-source-to-target hotkey: **`Ctrl`+`I`**.** The MT system will corrupt non-linguistic strings composed of numbers, equations, and punctuation.

4. **For CJK input (Chinese, Japanese, Korean), we recommend the following tools:**

   * [Google Input Tools for Chrome](http://www.google.com/inputtools/chrome/)

   * [Pinyin Sougou](https://pinyin.sogou.com/)

5. **Enable your browser QA plug-in.** In addition to LILT’s internal Auto Review, we recommend that you enable your external browser plug-in for spell checking. Please see a GIF below on how to enable your browser’s spell checker plug-in.

<Frame>
  <img />
</Frame>

## How can I improve LILT's suggestions?

LILT is an adaptive system, which means it needs data (specifically, source/target pairs) for adaptation. Here are some rules of thumb for improving translation quality:

* **LILT works best when custom Data Sources are created for each domain.** You may have LILT Data Sources for software, legal, medical, etc. A common mistake is to aggregate all data into default sources. This limits the system's ability to adapt to any one domain.

* **10,000 segments per Data Source**is about the point when you will start to notice increases in translation quality.

* **Full-length sentences** in Data Sources improve domain suggestions the fastest. Short sentences and word dictionaries are more suitable for the Termbase. See [TM Size and Content Guidelines](/kb/tm-size-content-guidelines) for more information.

* **Google Translate / Microsoft Translator are broader domain systems** trained on more data. The baseline (unadapted) quality of LILT is competitive for some domains, better for some domains (e.g., medical), and worse for some domains (e.g., software strings).

* **Fine-grained lexical distinctions for common words (e.g., "Party") take time to learn.** The training data likely contains a given word millions of times; the system will need to see your preference many times to learn the distinction reliably. You should find that it learns rarer words and phrases faster.

## What is the most efficient way to review?

In [LILT Translate](/kb/introduction-to-lilt-translate), confirmed segments are reduced in size to make more segments fit on the screen. Clicking on a confirmed segment will unconfirm it for editing. You must confirm the segment again to save it. When translating long documents, you may accidentally unconfirm or skip a segment. That's where the view filtering comes in.

To filter out segments in LILT Translate, open the `View` tab and select the segment types you want to view. You can use these filters to quickly locate untranslated/unsaved segments.

<Frame>
  <img />
</Frame>

The QA Mode is also ideal for reviewing and making quick edits.

## Can I come back later to edit my document if I close LILT?

LILT continuously saves the content of each segment’s target text as you make edits. LILT also automatically saves whether a segment has been marked as confirmed/accepted. If you close LILT or leave the document for any reason, you can return to the document at any time to continue editing from right where you left off.


# Webflow
Source: https://support.lilt.com/kb/webflow

Connect your Webflow site to LILT to translate your website content across languages.

## Overview

The LILT's Webflow Connector is a plugin-based integration that allows you to translate your Webflow content with ease. The connector supports all content types, including text, images, and other file assets in your Webflow CMS.

This modern, plugin-based connector replaces the legacy Webflow connector, offering a more streamlined and self-serve experience. By installing the LILT app from the Webflow Marketplace, you can directly manage and send content for translation from within your Webflow environment.

### Key Features

* **Translate Everything**: Handle all content types, from text fields to file assets.
* **Seamless Integration**: Install the LILT app directly from the Webflow Marketplace.
* **In-Context Control**: Select and manage the scope of your translation projects from within Webflow.
* **Automated Workflows**: Set up automated content synchronization to keep your multilingual sites up-to-date.

## Setup

### Prerequisites

* A Webflow account with admin access to the site you want to connect.
* Webflow's [Localization add-on](https://webflow.com/pricing?tab=localization-tab#add-ons) enabled on your site.
* A **Primary Locale** set up in Webflow. This is the source language for your content.
* One or more **Secondary Locales** added in Webflow. These are the languages you want to translate your content into.
* A LILT account with the Webflow connector enabled. Contact your LILT representative if you need assistance.

### Step 1: Install the LILT App in Webflow

1. Navigate to the [Webflow Marketplace](https://webflow.com/integrations) and search for the "LILT" app.
2. Click **Install App** and follow the on-screen instructions to add it to your Webflow site.

### Step 2: Configure the LILT App in Webflow

1. In your Webflow site, open the LILT app you installed.
2. You will be prompted to enter your LILT API Token. Paste the token you received after LILT enabled the connector for your account.
3. Once authenticated, you can configure the connector's settings.

## Usage

Once the connector is configured, you can manage your translation projects directly from Webflow:

* **Sending Content**: Select new or updated content and send it to LILT for translation.
* **Monitoring Status**: Track the progress of your translation jobs within the LILT app.
* **Receiving Translations**: In the LILT app, click **Import** on a completed job to pull translations back into Webflow.

### Translating Collections vs Items in a collection

When sending content for translation, you have the option to select either entire collections or individual items within a collection.

* **Collections**: Select the **Resource Type** "Collections", then choose the specific collections you want to translate. This option is useful when you want to translate all items within a collection.
* **Items in a collection**: In the **Resource Type** drop-down, select the name of the collection which contains the items you wish to translate, then choose the specific items you want to translate.

## FAQ

**Why am I unable to connect to LILT?**

* Double-check that your LILT API Token is correct.

**Why isn't my content being sent for translation?**

* Ensure that you have selected the correct items and target languages in the LILT app within Webflow.
* Ensure that source content has been added or updated in the **Primary Locale**. LILT looks for new or changed content to send for translation.

For further assistance, please contact [LILT support](https://lilt.atlassian.net/servicedesk/customer/portals).


# WPML WordPress
Source: https://support.lilt.com/kb/wordpress



LILT + [WPML](https://wpml.org/) [WordPress](https://wordpress.org/) connector enables companies to automatically push and pull web content between WordPress and LILT. This saves you time by providing seamless localization while letting you continue to work in the systems you know.

Here's a step-by-step guide on connecting your WordPress site to LILT using WPML.

## Configuration

1. Download and install the [WPML plugin](https://wpml.org/purchase/) on your WordPress site.

2. Get your LILT API key from the LILT user interface.

3. In your site's admin, go to WPML → Translation Management → Translators and find LILT in the list of available Translation Management Systems. Click to activate it, then click the **Authenticate** button and enter your LILT API key.

<Frame>
  <img />
</Frame>

For more detailed information, see [WPML's set up and usage guide](https://wpml.org/translation-service/lilt/).

## Workflow

Once the connector is configured, content is moved between LILT and WordPress as outlined in the sections below.

### Project creation

1. In your WordPress site, go to the WPML → Translation Management page and select the posts and pages you want translated

<Frame>
  <img />
</Frame>

2. Select **Assign translation service** as the translation method and set the batch name and deadline if needed.

3. Click the **Translate** button to send content to LILT for translation.

<Frame>
  <img />
</Frame>

### Project completion

Once a Project is completed in LILT, follow these steps to manually pull the localized content into WordPress:

1. On your site, go to WPML → Translation Management page.

2. Click the **Check status and get translations button** to update the status of translation jobs and pull the content of completed LILT Projects into WordPress.

<Frame>
  <img />
</Frame>

Once content has been pulled from LILT into WordPress, you can navigate to the Translation Jobs page to check the status of all your translation jobs. For jobs that have been completed, you can then review and publish the content.

## Limitations and FAQ

**Question:** Are there concerns/constraints in running multiple instances of LILT/WordPress integrations?

**Answer:** No, WPML can be installed in each case and configured with the API key: [https://wpml.org/translation-service/LILT/](https://wpml.org/translation-service/lilt/)

**Question:** What is the oldest release level that we support with our WordPress connector?

**Answer:** Any version supported by WPML: [https://wpml.org/home/minimum-requirements/](https://wpml.org/home/minimum-requirements/)

## Instant Translation Workaround

The WPML connector does not natively support Instant Translation. However, a workaround has been implemented to allow for automated instant translations without manual intervention from LILT's production team.

This workaround uses a webhook to detect and automatically process jobs for instant translation.

### How it Works

1. **Job Naming:** To trigger the instant translation workflow, the batch name of the job in WPML must start with `instant_WPML`. This is case-sensitive.
2. **Webhook Trigger:** A webhook is configured to monitor for jobs with this specific naming convention.
3. **Automated Processing:** When a job is detected with the `instant_WPML` prefix, the webhook automatically triggers the following actions:
   * The job is pre-translated using Translation Memory (TM) and Machine Translation (MT).
   * The project is marked as "Done".
4. **Content Delivery:** The translated content is delivered back to your WordPress site.
5. **Manual Refresh:** To view the translated content, you must manually refresh the batch sync in WPML by clicking the **Check status and get translations** button.


# Workflows For Translators
Source: https://support.lilt.com/kb/workflows-for-translators



## Project Opportunities

The platform supports the following language features:

* [119 language pairs](/kb/supported-languages) with Contextual AI support.
* Unlimited languages using Translation Memory (TM).
* Ability to specify language locales (regional variations) on a per-project basis.

We work with a variety of content types, from marketing, to user interface, to technical hardware manuals.

We aim to provide our freelance translators with consistent, recurring work opportunities. This means most of our customers are large companies with high-volume translation needs.

We aim to pair you with the perfect project team based on your language pair, direction, and content specialization. When a match is found, we will send you an email with the assignment, as well as an overview of the project.

<Frame>
  <img />
</Frame>


# XLIFF Status Handling
Source: https://support.lilt.com/kb/xliff-status-handling



XLIFF documents are the industry standard for exchanging translatable text and localization-related data across different localization tools. XLIFF files consist of translation units that appear as tags:

\<trans-unit>\
...\
\</trans-unit>

Within each translation unit is a source/target segment pair, where the target segment can be empty or populated depending on whether the segment has been translated.

The benefit of XLIFF files is that they can contain additional information beyond the source and target text, making it easy to pass all the necessary information about each segment between different localization tools.

This article looks at how the status of segments is utilized when XLIFF documents are imported into LILT.

## Importing XLIFF files into LILT

LILT supports the importing of [*Document Actions*](/kb/document-actions) *article.*

When importing XLIFF files, LILT utilizes the XLIFF state field to:

* Populate the segment’s target content field within LILT.

* Set the segment status within LILT.

The different XLIFF states that LILT recognizes are shown in the table below, along with how each state is used to populate the target content and set the status of each segment.

| **XLIFF segment state:** | **LILT segment target content is populated using:** | **LILT segment status is set to:** |
| - | - | - |
| translated | Available translation | Confirmed <img /> |
| final | Available translation | Accepted <img /> |
| signed-off | Available translation | Accepted <img /> |
| new | — | — |
| needs-translation | — | — |
| needs-adaptation | Available translation | — |
| needsl10n | — | — |
| needs-review-adaptation | Available translation | — |
| needs-review-l10n | Available translation | — |
| needs-review-translation | Available translation | — |
| (no state) | Available translation (if different from source content) | — |

Example XLIFF 1.2 file (using English source text and Spanish target text):

\<?xml version="1.0" encoding="UTF-8"?>\
\<xliff its:version="2.0" version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2" xmlns:its="[http://www.w3.org/2005/11/its](http://www.w3.org/2005/11/its)" xmlns:itsxlf="[http://www.w3.org/ns/its-xliff/](http://www.w3.org/ns/its-xliff/)" xmlns:okp="okapi-framework:xliff-extensions">\
\<file datatype="html" original="sample.html" source-language="en-US" target-language="es-ES">\
\<body>\
\<trans-unit id="tu1" restype="x-title-tu1">\
\<source xml:lang="en-US">HTML title\</source>\
\<target xml:lang="es-ES" state="translated">Título HTML\</target>\
\</trans-unit>\
\</body>\
\</file>\
\</xliff>

If this document is imported into LILT, the following would happen with the available translation unit:

* LILT finds the source text `HTML title` and adds that in a new segment entry within LILT.

* LILT finds the state of the target segment field: `state="translated"`. Referencing the table above, this means LILT will:

  * Populate the segment’s target text with the available translation: `Título HTML`.

  * Mark the segment as confirmed

    <Frame>
      <img />
    </Frame>

    .

<Frame>
  <img />
</Frame>


# XTM Cloud
Source: https://support.lilt.com/kb/xtm-cloud



The LILT + [XTM Cloud](https://xtm.cloud/) connector enables companies to automatically push and pull web content between XTM and LILT. This saves you time by providing seamless localization while letting you continue to work in the systems you know.

At a high-level, LILT's XTM LSP connector handles:

* **Submission via XTM**: Create new projects in LILT by creating a project in XTM using a project template assigned to the LILT LSP.

* **Project Progress:** Using XTM, check on the status of the content you sent to LILT for localization.

* **Delivery to XTM:** LILT to deliver localized content to XTM for approval.

* **TM Creation**: Use XTM to select a TM you want uploaded to LILT.

* **TM Write-back**: Update XTM translation memories with LILT changes.

* **Send TB**: Export XTM termbase to LILT.

<Frame>
  <img />
</Frame>

## Configuration

### Initial setup

1. Add LILT as an LSP within their instance of XTM.

   * Go to the `Users`>`LSPs` and click `Add LSP`.

     <Frame>
       <img />
     </Frame>

   * Fill in the fields marked with a red asterisk and click the `Add` button.

     <Frame>
       <img />
     </Frame>

   * For additional information, reference XTM's documentation on [How to set up subcontracting in XTM](https://xtm.cloud/knowledge-base/how-to-set-up-subcontracting-in-xtm/).

2. Adding LILT as an LSP within your XTM instance will trigger XTM to send an email to the address specified in the previous step. Once LILT has added the customer's credentials (specified in the email) to LILT's XTM instance, XTM will send an email back to the customer with instructions for how to complete the handshake process.

   <Frame>
     <img />
   </Frame>

3. Complete the process by heading to the `Users`>`LSPs` and click the `LILT LSP` option to open the LSP editor. Navigate to `Connection` and fill in `Connection information from the LSP` fields using the information provided to the customer (via email) by XTM.

   <Frame>
     <img />
   </Frame>

4. Now you will have the ability to assign LILT as the LSP for a particular project.

### Building a workflow with LILT

You will need to create a workflow in XTM that assigns the LILT LSP to the translate step of the workflow. This will allow content to be transferred between XTM and LILT.

1. Create one or many XTM project templates which you can use to send content to LILT for localization. Having more than one LILT-specific project template is useful for accommodating different localization workflows.

2. Navigate to the Projects tab and click `Add Project`.

3. Define the following attributes for your template **(\* starred fields are required)**:

   * **Customer Name\***

   * **Project name\***

   * Description

   * **Source language (one)\***

   * **Target languages (many)\***

   * TMs

   * Subject matter

   * **Workflow\***

   <Frame>
     <img />
   </Frame>

   * For additional information, reference XTM's documentation on [How to create a project template.](https://xtm.cloud/knowledge-base/create-project-template/)

4. Once you have specified your desired template properties and workflow, click `Save a template` to create the template.

5. Head to the template and navigate to the workflow subpage. Here will see the workflow you assigned to the project template.

6. Assign the LILT LSP to the `translate` workflow step in order to ensure projects created using this template are sent to LILT for localization.

7. Define any additional workflow steps for XTM to carryout once LILT has returned the localized content.

   * For additional information, reference XTM's documentation on [Setting up and monitoring project workflows in XTM](https://xtm.cloud/tutorials/set-monitor-project-workflows/).

8. Click the `save` button to finalize your template.

## Workflow

Once the connector is configured, content is automatically moved between LILT and XTM as outlined in the sections below.

### Project creation

Creating a project in XTM (using the project template assigned to the LILT LSP) will automatically create new LILT Projects for the content to be localized. The following properties defined during project creation will be carried over to LILT:

1. * Project name

   * Due date

   * Source language

   * Target language(s)

   * Translation memories

### Project monitoring

Using XTM, you can check on the status of the content you sent to LILT for localization.

### Project completion

When a LILT Project is marked as `done`, the Project's contents are automatically sent back to XTM and the workflow step is advanced.

## Limitations

### XTM batch delivery

By default, files submitted in a batch to LILT via XTM get added under one LILT Project. Project files are only returned to XTM when all the files have been localized and the Project has been marked as done.

If you want to circumvent this, you could submit smaller batches to LILT, but this reduced the efficiency of batch uploads. Luckily, there is a better solution! You can configure the maximum number of files allowed per LILT Project when submitting via XTM. When the file count exceeds this number, separate projects are created to house the files.

The example image below shows what would happen if nine files were submitted and each LILT Project was limited to three files. In this case, the files would appear in three separate LILT projects. When all three files in any Project are translated, the Project could be marked as done to send those files back to XTM without having to wait on any of the other Projects.

<Frame>
  <img />
</Frame>

Smaller maximum file counts accelerates the average speed at which individual files are delivered back through XTM. However, smaller maximum file counts can make things more challenging to manage. Experiment with different maximum file counts to find what works best for you.

## Demo access

LILT has a demo system and test configurations set up. Access can be provided upon request.

## Additional Information

When a job's active step matches the configured `xtm_review_workflow_stage,`the file will be marked as a memory resource, translation workflow will be set to HITL, appropriate memory configuration filters will be applied, the file will be processed differently from standard translation files


# Zendesk Guide
Source: https://support.lilt.com/kb/zendesk



LILT’s [Zendesk](https://www.zendesk.com/) Guide connector automatically sends Zendesk Help Center articles to LILT for translation at a set cadence, then delivers the translated articles back to Zendesk.

# What happens when you create or update an article in Zendesk

1. You create or update an article in Zendesk Guide.
2. At regular intervals configured during setup, the connector detects the change and creates a Job in the LILT Platform with the article content.
3. LILT processes the content according to the translation workflow you have configured (Instant or Verified).
4. When the Job is complete, the translated article content is delivered back to Zendesk for review and publishing.

# Choosing a translation workflow: Instant vs Verified

You can translate Zendesk articles using one of two workflows:

* **Instant Translation**: LILT immediately translates the article using LILT’s Contextual AI.
* **Verified Translation**: LILT routes the article to LILT’s in-house translators for human translation.
* **Instant + Verified (Both):** LILT immediately translates and delivers the article using LILT's Contextual AI for fast coverage. In parallel, a Verified job is created in Lilt. Once the Verified job is complete, the translation is pushed back to Zendesk, overwriting the Instant translations.

By default, the connector uses the workflow configured in the connector settings.

## Label-based filtering and routing (applies to both Instant and Verified)

Zendesk [*<u>labels</u>*](https://support.zendesk.com/hc/en-us/articles/115010596788-Using-labels-on-your-help-center-articles) can be used for two separate purposes:

1. **Filtering**: Control which articles are processed at all.
2. **Routing** (optional): Send different sets of labeled articles to different LILT workflows.

This routing logic can apply regardless of whether the destination workflow is Instant or Verified.

### **1) Filtering: include and exclude labels**

You can configure the connector to process or skip articles based on their Zendesk labels.

* **Include labels**: Process an article only if it has **at least one** label from the include list.
* **Exclude labels**: Skip an article if it has **at least one** label from the exclude list.
  * If an article matches both include and exclude, **exclude wins**.
  * Label matching is **case-sensitive**.

### 2) Routing: map labels to workflows (optional)

If you configure a label-to-workflow mapping, the connector will choose the LILT workflow like this:

1. If the article matches an entry in the mapping, it is routed to that workflow.
2. If it does not match any mapping entry, the connector uses the default workflow configured on the connector.
3. If the article matches the exclude list, it is skipped and **not** routed.

## Configuration

During onboarding, LILT will confirm whether the Zendesk integration is suitable for your environment and will help set up the connector.

## Considerations

The connector checks for new content and completed Jobs periodically, not continuously. The check frequency is determined during connector setup.


# LILT for Claude Marketplace
Source: https://support.lilt.com/lilt-for-claude-marketplace



# Connecting to LILT in Claude Marketplace

To enable Claude to use the LILT MCP server, configure it in your Claude Desktop client. You must be the primary owner on the Anthropic account to configure a custom connector.

**Note:** Requires Claude Pro, Team, or Enterprise.

1. Open Claude (either in browser or desktop client).
2. Navigate to **Settings** > **Connectors** > **Organization Connectors/Connectors** tab.

<img alt="Screenshot2025 09 22152418 Pn" />

3. Click **Add custom connector** and enter the following values:
   * Name: LILT
   * Remote MCP Server URL: [https://mcp.lilt.com/mcp](https://mcp.lilt.com/mcp)

<img alt="Screenshot2025 09 22152444 Pn" />

4. Click **Add**. Your LILT MCP Connector should now show "Enabled".

<img alt="Screenshot2025 09 22152618 Pn" />

5. Refresh the Connectors screen, find **LILT**, and click **Connect**.

<img alt="Screenshot2025 09 22152635 Pn" />

6. You will be redirected to the LILT sign-in page. Select **Sign up**.

<img alt="Screenshot2025 09 22152704 Pn" />

7. Sign up using SSO, or enter your preferred name, email, and password.

<img alt="Screenshot2025 09 22152730 Pn" />

8. Select **Allow Access**. The top right of your screen should display "Successfully connected to LILT". You can now close this page.

<img alt="Screenshot2025 09 22152752 Pn" />

9. For subsequent logins, navigate to [https://mcp.lilt.com/](https://mcp.lilt.com/) and sign in using your existing credentials. **Note:** These accounts are separate from lilt.com accounts.

<img alt="Screenshot2025 09 22152808 Pn" />

## Available Tools

The LILT MCP server provides the following tools for Claude to use.

### Translation

| Tool | Description |
| :- | :- |
| `translate_text` | Translates a piece of text instantly using LILT. |
| `translate_files_with_verification` | Creates a formal, verified translation job in LILT. |
| `get_credit_balance_information` | Checks the current balance for both instant and verified translation credits. |
| `check_job_status` | Checks the status of a verified translation job. |
| `download_job` | Triggers a job export and returns a download link for the completed job. |

### File Handling

| Tool | Description | Parameters | Returns |
| :- | :- | :- | :- |
| `upload_file` | Uploads a single file to LILT and polls until it is ready for processing. Non-plain-text formats (PDF, DOCX, RTF, PPTX, XLSX, etc.) are expected to already have their text extracted by the client; the tool appends a `.txt` extension to the filename to reflect this (e.g. `report.docx` becomes `report.docx.txt`). | `name` (str), `content` (str, raw or extracted text), `content_type` (str, defaults to `text/plain`) | An object with `id`, `name`, and `status` on success, or `error` and `status` on failure. |

### Models & Resources

| Tool | Description | Parameters | Returns |
| :- | :- | :- | :- |
| `create_trained_model` | Creates a new trained translation model for a specific language pair. This is a prerequisite for using `translate_files_with_verification` with that language pair. | `src_lang` (str, IETF BCP 47 tag), `trg_lang` (str, IETF BCP 47 tag) | Nothing (`None`) on success. |
| `list_resources` | Lists and filters existing jobs or trained models. | `resource_type` (str, `"model"` or `"job"`), `archived` (bool, jobs only, defaults to `False`) | A list of metadata objects. For `"model"`: `src_lang`, `trg_lang`. For `"job"`: `id`, `name`, `src_lang`, `trg_langs`, `num_files`. |

## Security and Privacy

* All secrets and credentials are managed exclusively through environment variables.
* The server uses an HTTP-only session cookie for authenticating users for its web interface.
* Cross-Origin Resource Sharing (CORS) is restricted to a list of known and trusted origins.

## Account & App Distinction

The LILT MCP App on Claude Marketplace offers a streamlined version of the platform, distilling core features to empower individual users and workloads. It includes a simple, self-service interface for sending and managing translation jobs, exposed primarily as a set of MCP tools.

Users can self-register and pay as they go, and users must specifically create an account for the LILT MCP app at [mcp.lilt.com](https://mcp.lilt.com).

This server exposes a set of tools that allow Claude or other MCP server hosts to perform actions such as:

* Translating text instantly
* Uploading files for translation
* Creating verified translation jobs
* Requesting translation quotes
* Downloading translated files
* Checking job status
* Creating custom-trained translation models
* Listing existing jobs and trained models


# Sample Agent Prompts
Source: https://support.lilt.com/sample-agent-prompts



Once connected to LILT's MCP Server, you have full access to the [<u>LILT Assist feature suite</u>](https://support.lilt.com/kb/agent-kb). To verify your setup is working correctly, you can test the following core capabilities directly inside your AI client. 

| Core Capability | Sample Use Case | Sample Prompt to Test |
| - | - | - |
| Instant Text Translation | Safely translating a customer support response or marketing copy using company-approved terminology. | *"Use LILT to translate the following email draft into Spanish: \[Insert Text Here]"* |
| Instant or Verified Document Translation | Uploading and translating an entire localized asset (like a .json or .docx file) on the fly | *"Translate this attached onboarding document into French using LILT."* |
| Job Tracking & Management | Checking the completion percentage or status of an active human-verified translation project. | *"Ask LILT for the status and progress of my current translation jobs."* |
| Organization/Domain Management | Quickly identifying which business units or specialized linguistic domains are active in your workspace. | *"List all of the available domains in my LILT organization."* |
| Datasource/Model Management | Verifying which specific translation memories, custom dictionaries, or AI models are currently connected to your profile. | *"Show me the active LILT data sources and translation models I have access to."* |
| User Governance | Add, remove, and change permissions for different users. | *"Add these new 5 users to my LILT account with a \[SPECIFY ROLE] permission"* |
| Program Analytics | Reviewing monthly localization performance, translation ROI, or monitoring AI model accuracy gains over time. | *"Ask LILT for our localization program analytics, specifically tracking AI translation accuracy and on-time delivery trends."* |

<br />


# 2024 Q4 Release Notes
Source: https://support.lilt.com/self-managed/v6.1/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.*

<Frame>
  <img alt="" />
</Frame>

#### **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.

<Frame>
  <img alt="" />
</Frame>

#### **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.

<Frame>
  <img alt="" />
</Frame>

#### **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).

<Frame>
  <img alt="" />
</Frame>

#### **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](/self-managed/v6.1/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.

<Frame>
  <img alt="" />
</Frame>

#### **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).

<Frame>
  <img alt="" />
</Frame>

#### **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.

<Frame>
  <img alt="" />
</Frame>

#### **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.

<Frame>
  <img alt="" />
</Frame>

#### **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](/self-managed/v6.1/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).

<Frame>
  <img alt="" />
</Frame>

### **LILT Manage**

#### **Edit Model Names**

<Frame>
  <img alt="" />
</Frame>

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.

<Frame>
  <img alt="" />
</Frame>

### **LILT Manage**

#### **LILT Financial File Download**

<Frame>
  <img alt="" />
</Frame>

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/self-managed/v6.1/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)

<Frame>
  <img alt="" />
</Frame>

### **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](/self-managed/v6.1/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.

<Frame>
  <img alt="" />
</Frame>

**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](/self-managed/v6.1/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](/self-managed/v6.1/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/self-managed/v6.1/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/self-managed/v6.1/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/self-managed/v6.1/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.


# LILT 5.3 Release Notes
Source: https://support.lilt.com/self-managed/v6.1/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: "<your-rabbitmq-password>"  # 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 <node-name> 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: "<your-minio-access-key>"
      S3_SECRET_KEY: "<your-minio-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: "<your-rabbitmq-password>"
```

## **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 <gpu-node-name> 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 <worker-node-name> 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 <node-name> 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: "<correct-rabbitmq-password>"
   ```

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: "<access-key>"
         S3_SECRET_KEY: "<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
   ```


# Create Backup
Source: https://support.lilt.com/self-managed/v6.1/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 <DBHost> --user root -p lilt_dev > backup.sql
```

\<DBHost> 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:

<Info>
  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.
</Info>

<Warning>
  **Do not run these steps without performing a back-up. It will irrevocably delete all data in the system.**
</Warning>

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.


# Disk Space Requirements
Source: https://support.lilt.com/self-managed/v6.1/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% |


# 2025 LILT February Patch Release Notes
Source: https://support.lilt.com/self-managed/v6.1/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.


# Infrastructure Release Notes
Source: https://support.lilt.com/self-managed/v6.1/infrastructure-release-notes



This article details the infrastructure changes required when installing this version of LILT.

## 6.1.0

<Warning>
  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.
</Warning>

### 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.

<Note>
  **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.
</Note>

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](/self-managed/v6.1/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](/self-managed/v6.1/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 `<NAME>_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](/self-managed/v6.1/node-labels) describes the expected labeling of nodes.

### Troubleshooting

Updated the [Troubleshooting](/self-managed/v6.1/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](/self-managed/v6.1/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 <<EOF >> /etc/security/limits.conf
soft nofile 131072
hard nofile 131072
EOF

cat <<EOF >> /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](/self-managed/v6.1/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](/self-managed/v6.1/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](/self-managed/v6.1/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](/self-managed/v6.1/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](/self-managed/v6.1/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](/self-managed/v6.1/set-custom-domain-and-certificates) and [Set Connectors Domain](/self-managed/v6.1/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](/self-managed/v6.1/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)](/self-managed/v6.1/generate-evaluation-metrics-wpa-bleu) , are now enabled by default.

#### SMTP Notifications

See the new page around configuring SMTP Notifications here: [SMTP Email Notifications](/self-managed/v6.1/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](/self-managed/v6.1/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.


# System Architecture
Source: https://support.lilt.com/self-managed/v6.1/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

<Frame>
  <img alt="Lilt Architecture Overview" />
</Frame>

## 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.

<Frame>
  <img alt="LILT GCP Hosted Architecture" />
</Frame>

**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.

<Frame>
  <img alt="LILT Self-Managed AWS Architecture" />
</Frame>

**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.

<Frame>
  <img alt="LILT Self-Managed Bare Metal Architecture" />
</Frame>

**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


# Move The System Offline
Source: https://support.lilt.com/self-managed/v6.1/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 <nodeName> node-type=worker
# kubectl label nodes <nodeName> node-role.kubernetes.io/master=master
# kubectl label nodes <nodeName> node-role.kubernetes.io/worker=worker
# kubectl taint nodes <nodeName> 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
```


# Self-Managed Features
Source: https://support.lilt.com/self-managed/v6.1/self-managed-features



This article describes the options and features provided for self-managed LILT deployments.

## LILT Platform Features

The features listed below can be enabled/disabled during the LILT installation process.

| **LILT Application Feature** | **Functionality** |
| - | - |
| Audit logging | Logs database and access events received by the LILT Platform. Users can perform an audit of the application by querying the logs for events of interest, such as database access or API access. |
| Custom UI banners | The following aspects of the LILT Platform UI header and footer can be changed<br /><br />• Header text<br /><br />• Footer text<br /><br />• Text color<br /><br />• Background color<br /><br />Custom UI banners does not support images.<br />Custom UI banners can be updated at any time. |
| Document security scan | All files uploaded into LILT are scanned for malicious threats. The scan is performed against the [Clam AntiVirus](https://www.clamav.net/) image. Document security scanning is not supported for files uploaded into LILT via API. |
| [Hard delete](/kb/segment-deletion-document-management) | When deleting documents and projects, segment information is permanently removed from the system. |
| [Instant translate documents](/kb/instant-translate-documents) and [Instant translate text](/kb/instant-translate-text) | Users can utilize the organization’s Translation Memories to quickly translate documents and text blocks outside the [LILT Translate](/kb/introduction-to-lilt-translate). |
| [Single sign-on (SSO)](/self-managed/v6.1/single-sign-on-sso) | Users can authenticate to the LILT Platform using an identity provider other than LILT. |
| Segment logging | Segment information is logged in the Platform's backend logs. Admin can enable/disable this feature at any time. |

## Technical features

### Super admin user

**Functionality:** The super admin user is the initial Platform user with administrative privileges. It has admin privileges only inside its own organization.

**Configuration:** By default, the super admin user is set to [admin@LILT.com](mailto:admin@LILT.com), but can be changed during the initial LILT installation process.

### GPU batch worker count

**Functionality:** GPU batch workers are used for parallel batch processing. GPU batch workers speed up document processing by providing quicker translations and memory updates.

**Configuration:** The following GPU batch worker settings can be set for the cluster:

* maximum number of GPU batch workers

* number of standby GPU batch workers

The optimal number of GPU batch workers is dependent on the available resources and the organization’s translation workflow. Optimal configuration will speed up parallel batch processing operations.

### Minimum segments count for GPU batch workers

**Functionality:** Each document must meet or exceed a minimum segment count before a GPU batch worker will process the document.

**Configuration:** Batch-related custom configurations are available to set the minimum segment count. Since GPU resources are limited in availability, care should be taken when setting the minimum segment count so that GPU usage benefits your workflow and is not just a resource drain.

### Persistent data location

**Functionality:** The persistent data location is used to store persistent data for LILT and the applications listed below in the *Infrastructure applications* section. Data is stored and retrieved from this location during application usage. Data is not removed if the applications are deleted.

**Configuration:** The admin can configure the persistent data location during the LILT Platform installation. The volume should be attached to the Kubernetes worker nodes. The volume cannot be updated without destroying the cluster.

### Host name

**Functionality:** The host name is used to access the LILT Platform. Customizing the host name allows for each organization to create a host name that can be easily remembered by the organization’s members.

**Configuration:** The host name can be specified during the LILT Platform installation and can be updated at any time after installation. When configuring the host name, failure to provide a valid SSL certificate and key for the host name will result in SSL error and inability to access the LILT Platform.

## Infrastructure applications

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/): relational database

* [MongoDB](https://www.mongodb.com/): audit logs database

* [ClickHouse](https://clickhouse.com/): analytics database

* [Elasticsearch](https://www.elastic.co/): search and indexing

* [Qdrant](https://qdrant.tech/): vector database

* [Redis](https://redis.io/): data structure caching

* [RabbitMQ](https://www.rabbitmq.com/): message queue

* [Istio](https://istio.io/): service mesh and ingress gateway, deployed in [ambient mode](https://istio.io/latest/docs/ambient/overview/) (per-node `ztunnel` proxy for transparent mTLS, no sidecars)

* [MetalLB](https://metallb.io/): bare-metal LoadBalancer that provides the external IP for the Istio ingress gateway

* [Argo CD](https://argo-cd.readthedocs.io/): GitOps continuous delivery for managing in-cluster releases

* [KubeRay](https://github.com/ray-project/kuberay): Kubernetes operator for Ray distributed compute

* [Prometheus](https://prometheus.io/): metrics collection

* [Nvidia-device-plugin](https://github.com/NVIDIA/k8s-device-plugin): GPU management in Kubernetes


# Upgrade LILT
Source: https://support.lilt.com/self-managed/v6.1/upgrade-system



## Overview

This article walks the installer through the process of upgrading an existing on-premise system. Given an available Kubernetes cluster, this document guides you through a partially-automated install process to deploy and configure LILT in your environment.

#### 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 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.

#### Run commands as root

```bash theme={null}
sudo su -
```

## Prerequisites

This upgrade document is only valid for an existing on-premise install previously installed using on-prem-installer scripts.

#### Data Location

Ensure that the new/updated Docker 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.

## Backup

Backup up the current running system prior to upgrade. This backup is **highly recommended**, and will be used to restore projects, documents and memory content in case of any errors.

#### **Step 1: 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 -`).

**Backup Install Directory**

Backup previous Install Directory (structure might be slightly different than the following example):

```bash theme={null}
mkdir -p /install_dir_backup
cp -r /install_dir/ /install_dir_backup
```

**Database**

Backup mysql database:

```bash theme={null}
# this will dump a file to the mysql pod temp memory
kubectl exec --stdin --tty mysql-0 -- /bin/bash -c "mysqldump --host mysql.lilt.svc.cluster.local --user root -p<password> lilt_dev > /tmp/mysql_dump.sql"

# copy dump file from mysql pod to local directory on master node
kubectl cp lilt/mysql-0:/tmp/mysql_dump.sql /mysql_dump/mysql_dump.sql
```

**Minio (optional)**

Take note of the existing minio pvc (`pvc-eiurty3794t679eryt495ytotoer`) for future commands:

```csharp theme={null}
# get minio pvc
kubectl get pvc | grep minio
```

Example output:

```powershell theme={null}
minio  Bound  pvc-80e6a0a5-9861-42ac-9e3f-ee6c7d439914   400Gi      RWO   openebs-hostpath
```

#### **Step 2: 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 -`).

**Persistant Volumes**

Backup storage volumes (pvcs) managed by openebs mount folders, default directory is `/liltdata`:

```bash theme={null}
# make backup dir
mkdir /lildtata_backup

# copy all pvcs
cp -r /liltdata/ /liltdata_backup 
```

## Upgrade Preparation

#### Step 1: Import New Images and Installer Packages

Download new images from remote s3 bucket and/or installer package. Details describing this process are documented in [Install System (Rocky Linux 8)](/self-managed/v6.1/install-system-amazon-linux-2023-or-rocky-8-9)

<Frame>
  <img />
</Frame>

<Note>
  NOTE: ensure that required images for each specific node are imported/loaded via containerd and that the installer package is correctly unpacked per steps in the documentation.
</Note>

#### Step 2: Update Custom Values

If changes were made to the default values in an existing install, compare files and modify as required (see the next section).

```swift theme={null}
diff -y /old_releaase/lilt/values.yaml  /new_release/lilt/values.yaml
```

In previous versions of LILT, values were spread across `lilt/values.yaml` and `lilt/environment/lilt/values.yaml`, which made it hard to differentiate what is a customer-centric vs default.

In subsequent release versions, default values `lilt/values.yaml`**should remain default**, and custom-values set in `lilt/environment/lilt/values.yaml`.

As an example, the first file is default `values.yaml`:

```yaml theme={null}
# values.yaml
front:
  enabled: true
  onpremValues:
    # Image credentials secrets to fetch the docker image
    imagePullSecrets:
    - name: docker-registry-secret
    # Create new image credentials, used when we aren't using local docker registry
    createimageCredentials:
      enabled: false
      name: docker-registry-secret
    # Enable biConnector(analytics-api), verify the port from biConnector configs
    biconnector:
      enabled: false
      Port: 8080
    # tls enabled, using dummy certificate for bare-tmp.lilt.com, please use new certs if available
    tls:
      enabled: true
      # set to true if tls secret exists
      existingSecret: false
      # Enter secret name
      secretName: front-app-tls
    env:
      # Theme configurations
      THEME_HEADER_BGCOLOR: "f0f0f0"
      THEME_HEADER_COLOR: "333333"
      THEME_HEADER_FONTSIZE: "12px"
      THEME_HEADER_TEXT: "My Company"
      THEME_FOOTER_BGCOLOR: "f0f0f0"
      THEME_FOOTER_COLOR: "333333"
      THEME_FOOTER_FONTSIZE: "12px"
      THEME_FOOTER_TEXT: "Test Installation Footer"
```

Add custom values for `THEME_HEADER_TEXT: "My Company"`, update `lilt/environment/lilt/values.yaml` as in the following:

```yaml theme={null}
# lilt/environment/lilt/values.yaml
front:
  onpremValues:
    env:
      THEME_HEADER_TEXT: "My Company"
```

<Frame>
  <img />
</Frame>

<Note>
  NOTE: this is a one-time migration, no necessary to repeat after custom values are set.
</Note>

#### Step 3: Update Custom Secrets

Verify custom secrets, no changes required unless specifically mentioned. The customer-centric secrets file is located at:

`lilt/environment/lilt/secrets.yaml`

#### Step 4: Environment Setup (Optional)

For multiple environments, create customer-centric *values.yaml* and *secrets.yaml* inside each respective environments folder as required.

## Upgrade LILT

After all new images, install files and custom environment variables have been set, run install LILT script.

#### **Step 1: 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 -`).

Change to install directory determined above:

```bash theme={null}
$ cd /install_dir
```

Output should look similar to the following:

```powershell theme={null}
api              install-lilt-docker-registry.sh  localpv-provisioner  nginx-ingress
clickhouse       install-lilt.sh                  metrics-server       nvidia-device-plugin
dev-scripts      install_scripts                  migration_utilities  output-container-images.py
docker-registry  istiod                           minio                prometheus
elasticsearch    istio-ingressgateway             mongodb              redis
flannel          jenkins                          mq-rabbitmq          uninstall-lilt.sh
grafana          lilt                             mysql
```

It is not necessary to re-install all third-party applications, just LILT. As an example, view the scripts included in `install-lilt.sh`:

```powershell theme={null}
cat install-lilt.sh
```

Output should be similar to the following:

```bash theme={null}
# Install devops charts
sh install_scripts/install-nginx-ingress.sh
# sh install_scripts/install-docker-registry.sh
sh install_scripts/install-nvidia-device-plugin.sh
sh install_scripts/install-mongodb.sh
sh install_scripts/install-mysql.sh
sh install_scripts/install-clickhouse.sh
sh install_scripts/install-cache-redis.sh
sh install_scripts/install-rabbitmq.sh
# sh install_scripts/install-grafana.sh
sh install_scripts/install-prometheus.sh
sh install_scripts/install-metrics-server.sh
sh install_scripts/install-minio.sh
sh install_scripts/install-elasticsearch.sh
sh install_scripts/install-istio-ingressgateway.sh
sh install_scripts/install-api.sh
# Install LILT Charts
sh install_scripts/install-lilt-charts.sh
```

Only need to run the last script:

```bash theme={null}
sh install_scripts/install-lilt-charts.sh
```

#### Step 2: Verification

Ensure all the pods are healthy (running status), this can take up to 15-30 minutes as some images will have to be reloaded.

```bash theme={null}
$ kubectl get pods -n lilt
```

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.

## Rollback (only if necessary)

If errors persist and LILT will not function, rollback to backup previous values/images and run `sh install_scripts/install-lilt-charts.sh`

## Restore MySql DB (only if necessary)

Restore DB from the backup performed in the above section.

#### Step 1: Copy Dump File to MySql Pod

```ruby theme={null}
kubectl cp /mysql_dump/mysql_dump.sql lilt/mysql-0:/tmp/mysql_dump.sql
```

#### Step 2: Restore File

```bash theme={null}
kubectl exec --stdin --tty mysql-0 -- /bin/bash -c "mysql --user root -p<password> -D lilt_dev < /tmp/mysql_dump.sql"
```

#### Step 3: Restore SequalizeMeta

During restore, `.ts` and `.js` files are mismatched, the following reestablishes correct file extensions:

```swift theme={null}
kubectl exec --stdin --tty mysql-0 -- mysql -u root -p<password> lilt_dev -e 'INSERT INTO `SequelizeMeta` VALUES ("20211206161036-insertEnableWorkflowsSetting-only-on-prem.js"),("20211208093745-bootstrap-workflows-on-prem.js"),("20211208115112-setDefaultWorkflow-only-on-prem.js"),("20211214100926-filtered-tmx-enable.js"),("20211214102401-enable-filtered-tmx-on-prem-only.js"),("20220303094802-enableJobsListPaginated.js"),("20220311151105-project-list-indices.js"),("20220314130118-LinguistQualities-indices.js"),("20220325124422-drop-qaconfig-srclang-trglang.js"),("20220329223422-create-qa-checks.js"),("20220331145745-add-organizations_isserviceaccount.js"),("20220331223422-create-qa-check-results.js"),("20220418193734-add-connector-tokens.js"),("20220420090333-create-ProjectChangelogs.js"),("20220420092243-create-DocumentChangelogs.js"),("20220427104748-create-mandatoryErrorFlaggingSecondaryReviewCommercial-setting.js"),("20220427104803-create-showPreviousStageCommentsSecondaryReviewCommercial-setting.js"),("20220429223422-recreate-qa-check-results.js"),("20220502094431-translation-done-required-review-stage.js"),("20220504202653-create-SegmentWorkflowStages.js"),("20220505123749-apply-customer-reviewer-role.js"),("20220505132017-create-scheduled-events.js"),("20220509105002-create-enableNextWordSuggestions-setting.js"),("20220510132117-enable-reject-document.js"),("20220511054900-create-neural-batch-translation-reqs-and-jobs.js"),("20220531155509-lagging_linguist_query_indexes.js"),("20220601223420-create-async-checks.js"),("20220601223422-create-async-check-results.js"),("20220602154639-edit-lingustlanguagepairs-locale-constraints.js"),("20220609102900-add-lingustqualities-is-available.js"),("20220614133322-drop-ScheduledEvents_unique_index.js"),("20220627154145-create-SSConfigurations.js"),("20220729021311-create-OrganizationLangPairSamplePercentage.js"),("20220729103939-limit-assignments-to-onboarded-users.js"),("20220809081110-add-index-notifications.js"),("20220817123018-add-MemoryCheckResults_ConfirmedByUserId_createdAt.js"),("20220908205552-add-workflow-group.js"),("20220909010816-add-OrganizationLangPairSamplePercantage-isDeleted.js"),("20220914150537-update-workflow-group.js"),("20220922130312-add-MemoryCheckResults-issueTypes-index.js"),("20221013194559-linguistAvailabilityToggle.js"),("20221013195401-autoAssignDueDates.js"),("20221014115910-create-customer-role.js"),("20221021103702-limit-assignments-to-onboarded-users-defaulted-false.js"),("20221024120044-update-customer-and-cr-roles.js"),("20221114153435-update-default-role-permissions.js"),("20221125151839-create-user-fingerprints.js"),("20221129124055-add-customer-review-sampling-columns.js"),("20221129143620-LinguistOrganization-Review-Allowance.js"),("20221130010816-add-backend_version_to_neural_batch.js"),("20221201010816-add-backend_version_to_neural_update_manager_requests.js"),("20221202163800-preaccepted-segments-remove-segment-id-unique.js"),("20221209130938-control-copy-and-paste-settings.js"),("20221212185204-add-hourly-rate-to-linguist-language-pairs.js"),("20221214123158-create-connector-jobs-index.js"),("20221230143840-viewprojectstats.js"),("20230110140105-add-memory-hashes.js"),("20230127162613-create-workflow-task-reasons.js"),("20230302235253-viewContextualAI.js"),("20230306124148-longer-locales-varchar.js"),("20230306170809-demo-user-metadata-setting.js"),("20230319121009-create-LanguagePairsScalar.js"),("20230330222759-enableConnectorsView.js"),("20230425235845-create-SegmentMemoryMetadata.js"),("20230509155908-create-generated-content.js"),("20230510191322-OrgSettingForTmFuzzyMatchDisablement.js"),("20230516230606-create-JobParameters.js"),("20230606131341-generatedContentPreferences.js"),("20230613125129-create-lilt-create-role.js"),("20230621154632-connectors-organization-update-tables.js")'
```


# 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`.

<Frame>
  <img />
</Frame>

You can also accept or reject assignments directly from the email notification by clicking on the `Accept all` / `Reject all` buttons or the check <img /> / cross <img /> buttons next to each document.

<Frame>
  <img />
</Frame>

## 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:**

<Frame>
  <img />
</Frame>

**Email notification:**

<Frame>
  <img />
</Frame>


# Overwrite Confirmed Segments
Source: https://support.lilt.com/kb/auto-propagation



Overwrite Confirmed Segments (formerly called Auto-Propagation) is a feature of [LILT Verify](/kb/introduction-to-lilt-translate) that saves linguists time by automatically completing and confirming repeated segments. Overwriting confirmed segments affects only the current document.

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

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.


# Bi-Directional Text Marks
Source: https://support.lilt.com/kb/bi-directional-text-marks



[LILT Verify](/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 Verify 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.

<Frame>
  <img />
</Frame>

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 |


# 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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>


# 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 Verify](/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.

<Frame>
  <img />
</Frame>


# Connectors
Source: https://support.lilt.com/kb/connectors

Connect LILT to your CMS, code repository, file storage, or TMS for continuous localization with automatic content import and delivery.

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.

***

<CardGroup>
  <Card title="Adobe Workfront" href="/kb/adobe-workfront" />

  <Card title="AEM" href="/kb/aem" />

  <Card title="Amazon Workdocs" href="/kb/amazon-workdocs" />

  <Card title="Amplience" href="/kb/amplience" />

  <Card title="AWS S3" href="/kb/aws-s3" />

  <Card title="Azure Blob" href="/kb/azure-blob" />

  <Card title="Bitbucket" href="/kb/bitbucket" />

  <Card title="Box" href="/kb/box" />

  <Card title="Braze" href="/kb/braze" />

  <Card title="Contentful" href="/kb/contentful" />

  <Card title="Contentstack" href="/kb/contentstack" />

  <Card title="Craft" href="/kb/craft" />

  <Card title="Crowdin" href="/kb/crowdin" />

  <Card title="Drupal" href="/kb/drupal" />

  <Card title="Figma" href="/kb/figma" />

  <Card title="GitHub" href="/kb/github" />

  <Card title="GitLab" href="/kb/gitlab" />

  <Card title="Google Drive" href="/kb/google-drive" />

  <Card title="Helpshift" href="/kb/helpshift" />

  <Card title="Heretto (fka EasyDITA)" href="/kb/easydita" />

  <Card title="HubSpot" href="/kb/hubspot" />

  <Card title="Inriver PIM" href="/kb/inriver" />

  <Card title="Intercom" href="/kb/intercom" />

  <Card title="Lokalise" href="/kb/lokalise" />

  <Card title="Magento" href="/kb/magento" />

  <Card title="Optimizely (fka EPIserver)" href="/kb/Optimizely" />

  <Card title="Phrase TMS" href="/kb/phrase-tms-fka-memsource" />

  <Card title="Salesforce Commerce Cloud" href="/kb/salesforce-commerce-cloud" />

  <Card title="Salesforce Knowledge" href="/kb/salesforce-knowledge" />

  <Card title="Sanity" href="/kb/sanity" />

  <Card title="SDL TMS" href="/kb/sdl-tms" />

  <Card title="SDL WorldServer" href="/kb/sdl-worldserver" />

  <Card title="SharePoint" href="/kb/sharepoint" />

  <Card title="Shopify" href="/kb/shopify" />

  <Card title="Sitecore XP 10.0" href="/kb/sitecore-xp-10-0" />

  <Card title="Smartling TMS" href="/kb/smartling-tms" />

  <Card title="Termweb" href="/kb/termweb-connector" />

  <Card title="Trados Enterprise" href="/kb/trados-enterprise" />

  <Card title="Webflow" href="/kb/webflow" />

  <Card title="WebTranslateIt" href="/kb/lilt-connector-compatible-with-webtranslateit" />

  <Card title="WPML WordPress" href="/kb/wordpress" />

  <Card title="XTM Cloud" href="/kb/xtm-cloud" />

  <Card title="Zendesk" href="/kb/zendesk" />
</CardGroup>


# 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 <img /> 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 <img /> 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 <img /> 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.

<Frame>
  <img />
</Frame>

## 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.

  <Frame>
    <img />
  </Frame>

* Assignments can be set from the Document card by clicking any of the `Assign` or `Set due date` buttons.

  <Frame>
    <img />
  </Frame>

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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

Once translation and review due dates are set, they are displayed on the Document card.

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

\*\*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.

<Frame>
  <img />
</Frame>

\*\*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.

<Frame>
  <img />
</Frame>

## Pretranslate documents

<Frame>
  <img />
</Frame>

Under the document options dropdown <img />, 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

<Frame>
  <img />
</Frame>

Under the document options dropdown <img />, 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

<Frame>
  <img />
</Frame>

Under the document options dropdown <img /> , 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.

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

## Search documents

Search for documents by name by typing into the search bar. Documents will filter in real-time as you type.

<Frame>
  <img />
</Frame>


# Document Navigation Tab
Source: https://support.lilt.com/kb/document-navigation-tab



The Document sidebar tool in [LILT Verify](/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.

<Frame>
  <img />
</Frame>


# 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).

<Frame>
  <img />
</Frame>

## 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).

<Frame>
  <img />
</Frame>

## 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:

<Frame>
  <img />
</Frame>

Review deadline:

<Frame>
  <img />
</Frame>

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.


# 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](/self-managed/v6.1/enable-features).

## Translation & Workflow

<ResponseField name="additionalGuidelines" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="autoAssignDueDates" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="autoConfirmExactMatchesAndRepetitions" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="autoPretranslateAcceptAndLock" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="autoPretranslateCaseSensitiveTranslation" type="Admin CLI">
  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`).
</ResponseField>

<ResponseField name="autoPretranslateExactMatchesAuthorship" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="autoPretranslateUseMtForUnmatchedSegments" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="defaultPostProcessing" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="defaultVerifiedTranslationJobCreation" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="defaultWorkflow" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="disableTMFuzzyMatch" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableASR" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAutoPretranslate" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="enableAutoPretranslationSetting" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAutoRevisions" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableBackwardPropagation" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableDataLabeling" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableDirectToCloudUploads" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableFilteredTMX" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableFixedLinguistPayment" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableGoogleTranslateInTMLookup" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableJobJiraTickets" type="Admin CLI">
  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`).
</ResponseField>

<ResponseField name="enableJobsFlow" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableJobsListPaginated" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableJobV2" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableOrgDefaultMemory" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enablePostProcessing" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableQuickTranslate" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableRejectWorkflows" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableStringInfoFiles" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableSubfiltersSegmentation" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableUniversalFileUploadEnterprise" type="Org Settings UI">
  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`).
</ResponseField>

<ResponseField name="enableUnlockExactMatchedSegmentsByStage" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="enableVideoDubbing" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableWorkflows" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="externalModelId" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="humanAIOptimizedWorkflow" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="nonTranslatablePatterns" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="showVerifiedQuotingV2" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="surfaceEnableAutoRevisionsOrgSetting" type="Admin CLI">
  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.
</ResponseField>

## Review & QA

<ResponseField name="aiQAExcludeExactMatches" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="automaticBatchQaCustomerReviewer" type="Org Settings UI">
  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).
</ResponseField>

<ResponseField name="automaticBatchQaReviewer" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="automaticBatchQaTranslator" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="defaultReviewSamplingSize" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="defaultSecondaryReviewSamplingSize" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="enableAIQA" type="Org Settings UI">
  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`.
</ResponseField>

<ResponseField name="enableAIReview" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableBlockReviewUnlessTranslationDone" type="Org Settings UI">
  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`).
</ResponseField>

<ResponseField name="enableCustomerReviewQA" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableCustomQAConfig" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableMarkForReview" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableMQMIssueType" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableNeuralAutoReview" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enablePII" type="Org Settings UI">
  Org-level toggle that enables PII redaction. When enabled, `shouldRedactPII` causes PII to be redacted for any user who lacks the `ExportPII` permission.
</ResponseField>

<ResponseField name="enableRejectDocument" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableTmEditorQa" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableTmEditorQaGrammarSpelling" type="Admin CLI">
  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`).
</ResponseField>

<ResponseField name="enableVerifySegments" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="mandatoryErrorFlagging" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="mandatoryErrorFlaggingSecondaryReviewCommercial" type="Org Settings UI">
  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`).
</ResponseField>

<ResponseField name="multimediaQAChecks" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="qaCheckPrompts" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="requireBatchQaCustomerReviewer" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="requireBatchQaReviewer" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="requireBatchQaTranslator" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="requireDistinctReviewers" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="reviewSamplingExcludeExactMatches" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="secondaryReviewSamplingExcludeExactMatches" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="showPreviousStageCommentsSecondaryReviewCommercial" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="skipReviewerIfTranslatorPreferred" type="Admin CLI">
  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.
</ResponseField>

## Editor

<ResponseField name="caseSensitiveTMMatch" type="Org Settings UI">
  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`.
</ResponseField>

<ResponseField name="catMTSuggestionProvider" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="controlCopyAndPaste" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="disable101TMMatches" type="Org Settings UI">
  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`.
</ResponseField>

<ResponseField name="enableCatInfiniteScroll" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableNextWordSuggestions" type="Admin CLI">
  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`.
</ResponseField>

<ResponseField name="enablePromptLabeling" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="enableTargetCharLimit" type="Org Settings UI">
  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`.
</ResponseField>

<ResponseField name="TSFStyleGuide" type="Org Settings UI">
  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.
</ResponseField>

## AI Providers & Models

<ResponseField name="aiReviewModelsPreferences" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="audioToTextModelsPreferences" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="enableAmazonTextract" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAmazonTranscribe" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAmazonTranslate" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAzureGPT35" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAzureGPT5" type="Admin CLI">
  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`).
</ResponseField>

<ResponseField name="enableBedrockAI21Jurassic" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableBedrockClaude2" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableBedrockClaude3Sonnet" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableBedrockTitan" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableBedrockTitanTextExpress" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enabledAIProviders" type="Org Settings UI">
  JSON object of enabled external AI providers (e.g. \{"aws": true, "google": true}).
</ResponseField>

<ResponseField name="enableDeepL" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableGoogleCloudASR" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableGoogleCloudVision" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableGooglePalm2" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableGoogleTranslate" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableGoogleTranslateV3" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableGoogleTranslateV3Migration" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableLiltHostedNvidia" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableLLaMa2" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableLLMConfigurationSettings" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableMcp" type="Org Settings UI">
  Org-level toggle to enable the Model Context Protocol (MCP) integration.
</ResponseField>

<ResponseField name="enableOCR" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableOpenAIGPT3_5" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableOpenAIGPT4" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableOpenAIGPT4_Turbo" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableOpenAIGPT4O" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableOpenAIGPT5" type="Admin CLI">
  Gates the OpenAI GPT-5 option (`createOpenAIModel` with high speed, high cost, high quality) in the LILT Create / AI Hub generative model list.
</ResponseField>

<ResponseField name="enableOpenAIGPT5Mini" type="Admin CLI">
  Gates the OpenAI GPT-5 Mini option (high speed, medium cost, high quality) in the LILT Create / AI Hub generative model list.
</ResponseField>

<ResponseField name="enableOpenAIGPT5Nano" type="Admin CLI">
  Gates the OpenAI GPT-5 Nano option (high speed, low cost, medium quality) in the LILT Create / AI Hub generative model list.
</ResponseField>

<ResponseField name="enableOpenAiWhisper" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableTesseract" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="GeneratedContentPreferences" type="API">
  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.
</ResponseField>

<ResponseField name="GeneratedContentService" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="generativeModelsPreferences" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="imageToTextModelsPreferences" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="translationModelsPreferences" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="viewContextualAI" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="ENABLE_EXTERNAL_MODEL_CONFIG" type="Environment Variable">
  Shows the External Models tab under Organization Settings, letting admins toggle which external AI providers are available.
</ResponseField>

## Authentication & Security

<ResponseField name="enableWSO2Login" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="sessionTimeout" type="Admin CLI">
  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.
</ResponseField>

## Connectors

<ResponseField name="allowedConnectors" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAutoDeliveryBlocking" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableConnectorsBuilder" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableConnectorsManualSubmission" type="Admin CLI">
  Org-level toggle to allow manual submissions for connectors flows. When enabled, users can select content from a connector and submit it manually.
</ResponseField>

<ResponseField name="enableConnectorsView" type="Admin CLI">
  Org-level toggle for the Connectors nav entry: gates the "Connectors" link/card on the homepage and manage-home navigation (`NavigationCards`/`ManageHomepage`, via `useHasSetting`).
</ResponseField>

## Analytics

<ResponseField name="customAnalyticsKey" type="Admin CLI">
  Customer identifier embedded into the Looker Studio embed URL for the AnalyticsV2 Custom Analytics tab (`AnalyticsV2/CustomAnalytics`).
</ResponseField>

<ResponseField name="enableAIAccuracyPerModel" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAnalyticsV2" type="Org Settings UI">
  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`).
</ResponseField>

<ResponseField name="enableCustomAnalytics" type="Org Settings UI">
  Shows the Custom Analytics tab inside AnalyticsV2 (`AnalyticsV2/index.tsx`), which embeds a customer-specific Looker Studio report via `CustomAnalyticsKey`.
</ResponseField>

<ResponseField name="enableFinancialData" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableFinancialsAnalytics" type="Org Settings UI">
  Shows the Financials tab inside AnalyticsV2 (`AnalyticsV2/index.tsx`), exposing financial reporting alongside the Overview, AI Accuracy, and Quality tabs.
</ResponseField>

<ResponseField name="enableLQA" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableOPMStats" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableOpportunitySync" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="grossMarginPercentHumanAiOptimized" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="grossMarginPercentVerified" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="programInsightsKey" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="usageAnalytics" type="Admin CLI">
  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`).
</ResponseField>

<ResponseField name="viewEmbeddedAppInsights" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="viewEmbeddedAppInsightsB" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="viewLinguistStats" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="viewProgramInsights" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="viewProjectsStats" type="Admin CLI">
  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.
</ResponseField>

## Users & Assignment

<ResponseField name="accountLinguistQualitiesIsAvailable" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="autoTriggerAssignment" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAutoAssignment" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableCustomerReviewerDomainAssignment" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableDomains" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableExperts" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableNewLinguistPage" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="fullNameMandatory" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="jobInstructionsEmailTemplate" type="Org Settings UI">
  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`.
</ResponseField>

<ResponseField name="limitAssignmentsToOnboardedUsers" type="Org Settings UI">
  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`.
</ResponseField>

<ResponseField name="linguistAvailabilityToggle" type="Org Settings UI">
  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`).
</ResponseField>

<ResponseField name="organizationInstructionsEmailTemplate" type="Org Settings UI">
  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.
</ResponseField>

<ResponseField name="organizationTrainingRequired" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="projectInstructionsEmailTemplate" type="Org Settings UI">
  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`).
</ResponseField>

<ResponseField name="timezoneMandatory" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="userCreateLimit" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="userDomainsPreferences" type="API">
  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.
</ResponseField>

<ResponseField name="userLanguagePreference" type="API">
  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.
</ResponseField>

<ResponseField name="userLimit" type="Admin CLI">
  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`).
</ResponseField>

## Misc

<ResponseField name="availableAgentTools" type="Org Settings UI">
  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).
</ResponseField>

<ResponseField name="defaultHomepage" type="Admin CLI">
  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`.
</ResponseField>

<ResponseField name="enableAgentHomepage" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableAIAssistant" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableGeneratedContentServiceSelection" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableHomePage" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableOrgSettingsView" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enablePlatformRedesign" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableProjectSettingsView" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="enableSplitSettingsPage" type="Admin CLI">
  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.
</ResponseField>

<ResponseField name="navigationLayoutMode" type="Admin CLI">
  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).
</ResponseField>

<ResponseField name="ALLOW_INCOMPATIBLE_BROWSERS" type="Environment Variable">
  Allows users on unsupported/incompatible browsers to access the platform instead of being blocked.
</ResponseField>


# Find & Replace
Source: https://support.lilt.com/kb/find-replace



The Find and Replace sidebar tool in [LILT Verify](/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`).

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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.***


# Hotkeys
Source: https://support.lilt.com/kb/hotkeys



[LILT Verify](/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` |


# 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.

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

### 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.


# 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.

<Frame>
  <img alt="Image" />
</Frame>

## How to setup

1. As an Admin user, navigate to Manage > Users. Select the Role tab, and click "New role".

   <Frame>
     <img alt="Image" />
   </Frame>
2. Create an AI Only User Role. Set Default Home view as "AI Only Home" and Role type as "AI Only".

   <Frame>
     <img alt="Image" />
   </Frame>
3. Enable permissions for the role.
   * Enable Create/Edit permissions for "Instant Translate".
   * Enable Upload/Download permissions for "Files".

     <Frame>
       <img alt="Image" />
     </Frame>
4. Navigate to Users and User Management. Set the new Instant Translate Role for an existing user.

<Frame>
  <img alt="" />
</Frame>

*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.*


# Job Stats
Source: https://support.lilt.com/kb/job-stats



<Frame>
  <img />
</Frame>

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

<video />


# 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.

<Frame>
  <img alt="" />
</Frame>

## 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).

<Frame>
  <img alt="" />
</Frame>

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).

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

#### 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.

<Frame>
  <img alt="Image" />
</Frame>

### 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.

<Frame>
  <img alt="" />
</Frame>

#### OTD Per Language Pair

The "OTD Per Language Pair" table provides a breakdown of on-time delivery performance for different language pairs.

#### Project Stats

<Frame>
  <img alt="" />
</Frame>

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.


# Create
Source: https://support.lilt.com/kb/lilt-create



<Note>
  LILT Create has been retired and consolidated into **LILT Assist**. Content generation is now available through Assist's Content Creation capability.
</Note>

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).


# 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.”

<Frame>
  <img alt="" />
</Frame>

## 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.

<Frame>
  <img alt="" />
</Frame>

### 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.

   <img alt="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.


# 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!

<Frame>
  <img />
</Frame>

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.


# 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).

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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:

  <Frame>
    <img />
  </Frame>

* Review mode status indicator:

  <Frame>
    <img />
  </Frame>

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.

<Frame>
  <img alt="" />
</Frame>

On the Jobs page, Admin and Managers can see the workflow defined for the job.

<Frame>
  <img alt="" />
</Frame>

For added visibility, Admins and Managers can also see which workflow was selected at the top of the Documents page.

<Frame>
  <img alt="" />
</Frame>

#### Document Status

Document statuses automatically update based on user actions as illustrated below.

<Frame>
  <img alt="" />
</Frame>

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.

<Frame>
  <img alt="" />
</Frame>

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)

<Frame>
  <img alt="" />
</Frame>

Project level assignment. Project is using the Translate only workflow.

<Frame>
  <img alt="" />
</Frame>

### 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.


# 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.

   <img alt="Screenshot2025 10 23at14 14 05 Pn" />

<Frame>
  <img alt="" />
</Frame>


# Preview mode
Source: https://support.lilt.com/kb/monolingual-preview



Preview mode is a feature of [LILT Verify](/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 Verify, click the `View` tab and select `Preview mode` (shortcut: `Ctrl`+`Shift`+`P`).

<Frame>
  <img />
</Frame>

How to access Preview mode

Once open, the in-context document preview displays the translated content with paragraph and HTML formatting.

<Frame>
  <img />
</Frame>

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 |


# 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.

<Frame>
  <img alt="Image" />
</Frame>

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.

<Frame>
  <img alt="Image" title="Image" />
</Frame>

## 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.

<Frame>
  <img alt="" />
</Frame>

* **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.

<Frame>
  <img alt="" />
</Frame>

* **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.

<Frame>
  <img alt="" />
</Frame>

## 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.

<Frame>
  <img alt="Image" />
</Frame>

## Deliver a Job

<Frame>
  <img alt="" />
</Frame>

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

<Frame>
  <img alt="" />
</Frame>

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

<Frame>
  <img alt="" />
</Frame>

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

<Frame>
  <img alt="" />
</Frame>

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

<Frame>
  <img alt="" />
</Frame>

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**

<Frame>
  <img />
</Frame>

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`.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

## Assign Projects

<Frame>
  <img />
</Frame>

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.*

<Frame>
  <img />
</Frame>

## Deliver Projects

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

## Archive Projects

<Frame>
  <img />
</Frame>

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

<Frame>
  <img />
</Frame>

Click `Download files` to download a ZIP file containing the Project's target files.

## Download a Project's TMX memory file

<Frame>
  <img />
</Frame>

Click `Download memories` to download a TMX file of the Project's data source.

## Delete Projects

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

## 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.

<Frame>
  <img />
</Frame>

<Frame>
  <img />
</Frame>


# 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 Verify](/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.

<Frame>
  <img />
</Frame>

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 Verify**

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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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 Verify.

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:

* * \<br>

  * \<img>

* 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:

* \<strong> … \</strong>

Using paired Non-Translatables in this format causes LILT to treat them as tags within LILT Verify. 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 <b>bold and <i>italics</i> together {{0}}</b>.`

LILT does not currently support paired Non-Translatables in any other formats, such as:

* \{strong} … \{strong}

* \[bold] … \[/bold]


# Organization Settings
Source: https://support.lilt.com/kb/organization-settings



LILT provides organizations with several settings that can be tweaked to streamline the translation process in the way that works best for your organization.

To find the settings, navigate to the `settings gear` on the left sidebar.

Organization settings are broken down into the following sections:

* Custom QA checks
* Translate / CAT Editor
* Workflow
* Assignment
* Style guide
* API
* Assist
* External Models (self-managed only, when [enabled](/self-managed/v6.1/enable-features#external-model-configuration))

For the complete list of feature flags and org settings across the platform, see the [Feature Flag Reference](/kb/feature-flags).

<img alt="Screenshot2025 08 20at13 06 07 Pn" />

The options within the `Settings` page affect all users and projects across your organization. Changing settings will affect your session immediately and will take effect for other organization members when they refresh their page.

## Custom QA checks

Customers are able to upload and use custom QA configurations at the organization level. These QA checks will be applicable when running Batch QA in the CAT editor. The ability to upload QA config files is restricted to admin users.

Files must be .qccfg file type, and LILT will prevent the upload of any other file type. LILT only allows 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.

<img alt="Screenshot2025 08 20at13 29 12 Pn" title="Screenshot2025 08 20at13 29 12 Pn" />

## Translate / CAT Editor

<img alt="Screenshot2025 08 20at13 09 08 Pn" />

**AI provider for CAT suggestions:** If the AI provider is set to "LILT Contextual AI", linguists will see suggestions in both the CAT and the CAT sidebar. If suggestions are set to "None", there will be no suggestions. "None" is typically used when a translation needs zero MT bias.

**Allow Copy/Paste:** If the`Allow Copy/Paste` setting is set to "Warn", linguists will get the below popup if they copy/paste content from outside of the LILT Platform into LILT Translate. If the setting is set to "Block", all copy and paste will be blocked within LILT Translate.

<Frame>
  <img alt="" />
</Frame>

**Fuzzy match threshold:** This is a set 75% threshold and not configurable. More information is available in [Data Source Memory Matching](https://support.lilt.com/kb/translation-memory-matching-and-suggestions#tm-match-scores).

**Case-sensitive matching:** If this is turned on, Data source matches are forced to respect case-sensitivity.

**Segment character limit control:** When enabled, this will warn the translator that the space of the translation is limited based on character count metadata (if available).

**Prioritize recency:** If enabled, this will disable 101% match priority and allow for recency-based match prioritization. 101% matches will be treated as equivalent to 100% matches, prioritizing recency over context precision. For more information, please reference [Translation Memory Matching and Suggestions](https://support.lilt.com/kb/translation-memory-matching-and-suggestions).

<frame name="frame" />

**Mandate Error logging:** If turned on, error logging is mandatory in the selected stage(s) when a reviewer changes anything in the target segment. For more information on error flagging, please reference [Segment Comments and Error Flagging](https://support.lilt.com/kb/segment-comments).

### Subtitling QA checks

Please reference [Subtitling QA checks](https://support.lilt.com/kb/subtitling-and-captioning#subtitling-qa-checks) for more information.

<img alt="Screenshot2025 08 20at13 18 50 Pn" />

### Non-Translatable Placeholders

Org admins can now control which placeholder formats should be excluded from translation, directly from org settings. Toggle on the pattern types your content uses:

* **Double curly braces** — e.g. `{{variable}}`
* **Single curly braces** — e.g. `{0}`, `{placeholder}`
* **Percent format specifiers** — e.g. `%s`, `%d`

Once enabled, LILT will automatically recognize and preserve these patterns during translation, so placeholders stay intact in the target content. If your organization uses a pattern that isn't listed here, reach out to your LILT contact to have it added.

<Frame>
  <img alt="Image" />
</Frame>

## Workflow

The Workflow settings section allows you to set the default settings for new Projects created within your organization. These settings can be overridden on a per-Project basis from the [Project Settings](/kb/project-settings) page of existing Projects.

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

### Allow unlocking locked segments

Unlocking locked segments allows for any role to unlock and update locked segments during the selected workflow stage(s). This is intended as a safety valve specifically for Reviewers and Customer Reviewers if errors are spotted during their review so they can quickly and easily correct any errors present, instead of needing to manually update Data Sources. After making any changes to a locked segment, the segment will be re-accepted and will no longer appear as locked. Any changes made will update the data source, auto-propagate to other exact matches in the document, and update in other translations in progress. The default status for this setting is OFF.

**Note: Billing for LILT Services customers**

If you use LILT Services, turning this setting on for the **Translate** or **Review** stage means exact matches (100% and 101%) are reviewed and billed. Here's how it works:

* **Your contracted rate applies** if your agreement includes a Verified Exact Match rate.
* **A default rate of \$0.02 per word applies** if your agreement doesn't include one.
* **All exact-match words in scope are billed**, whether or not they're changed during review.
* **Quotes and invoices show exact matches** as a separate line item.

Enabling this for **Secondary Review** only does not add exact-match charges.

## Assignment settings

When a linguist is assigned to a document, they are automatically sent an email notification. Whatever content is in the `Organization level instructions` field will be included in all assignment emails for the organization. This is a great place to include:

<Frame>
  <img alt="" />
</Frame>

Note that assignment instructions can also be added at the Project level, as described in the [Project Settings](/kb/project-settings) article.

**Limit Assignments:** Only users and linguists directly in the organization can be assigned.

**Auto assign linguists:** When turned on, Auto Assign will trigger 30 minutes after job creation.

## Style guide

LILT’s style guide contains settings that are used for LILT Create and AI Review. Additionally, the style guide is available to linguists as part of Reference Materials and displayed directly within the CAT editor sidebar. Default values are applied, which can then be customized at the organization level as needed. Changes are saved on a field change. When a toggle switch is activated to indicate “Yes”, an open text box appears to provide additional specifics as needed.

**LILT Create** - The LILT Create prompt is customized with all inputs from the style guide to provide context for content generation. To access the style guide from LILT Create, users can click on “Update your settings for LILT Create”, which will open the style guide in a new tab.

**AI Review** - The AI Review scoring and automated revisions are customized with all inputs from the style guide, with the exception of the Formatting section, as those require document-level and external source context.

The style guide is broken down into six sections:

* General
* Terminology
* Conventions
* Style
* Special rules
* Formatting

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

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<br />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.


# Project Custom Properties
Source: https://support.lilt.com/kb/project-custom-properties



Using Project custom properties, you can add metadata to a Project’s TM entries. This metadata is included when you deliver your Project to an external system, which can be particularly useful if you have LILT connected to an external Content Management System (CMS). For example, you could use metadata to add reference IDs for external systems like ticket numbers or configuration settings. Custom properties are also useful in managing metadata that gets used for automation/API purposes.

By default, custom properties metadata only affects the Project; it does not add metadata to the associated Data Source and does not affect other Projects using the associated Data Source.

To manage a Project's custom properties, open the desired Project, navigate to the `Settings` tab, and scroll down to the `Custom Properties` section.

<Frame>
  <img />
</Frame>

This sections below discusses adding, editing, and deleting custom properties. It is important to note that changes to custom properties are only applied if you click the `Save` button at the bottom of the `Custom Properties` section.

If you want to undo any changes you have made, simply refresh the page without clicking the `Save` button and the changes will be reverted.

## Adding custom properties

In the `Custom Properties` section, click the `Add custom property` button to add new empty entries.

<Frame>
  <img />
</Frame>

Each entry has the following fields to fill out:

* **Propagate (checkbox):**

  * **If not selected**, the custom property will only exist as metadata within the Project.

  * **If selected**, the custom property becomes locked and is added to all the associated Data Source TM entries. This means other projects using the same Data Source will also be affected. Locked custom property entries cannot be edited, but can be deleted. Be careful when propagating; propagation is not always easily undone for the following reasons:

    * Deleting a custom property from a Project does not delete it from the associated Data Source.

    * An existing custom property with the same name as your new custom property will have its value overwritten in all the Data Source TM entries.

* **Name (text field):** Add the name of the custom property. This is a unique identifier of the metadata field. If you use the same name as any existing custom properties, the existing value will be overwritten.

* **Value (text field):** Add the value of the custom property.

<Frame>
  <img />
</Frame>

When finished adding new entries, click the `Save` button to apply any changes you have made.

## Editing custom properties

If you need to edit any custom property entries, click the name or value text fields, modify the text, and click the `Save` button.

Note that locked custom properties cannot be edited from the Project settings page. Instead, you can edit the name field on the associated [Data Source Settings Page](/kb/memory-settings), and you can edit the value field on an individual basis for each of the Data Source's[TM Entries](/kb/managing-termbase-and-translation-memory-entries).

## Deleting custom properties

If you need to delete any custom properties, click the Delete icon for each entry you want to remove and then click the `Save` button to permanently delete them.

Deleting a custom property from a Project will only remove it from that Project. If any custom properties were propagated to the associated Data Source, you can delete them on the [Data Source's Settings Page](/kb/memory-settings).


# Project Delivery
Source: https://support.lilt.com/kb/project-delivery



When a Project is complete, you can use the `Deliver` button in the top right corner of the page to send the finalized content.

<Frame>
  <img />
</Frame>

## Project TMX

Clicking the `Download TMX` button generates a TMX file for you to download containing the translation data for the entire project.

## Project ZIP

Clicking the `Download project ZIP` button generates a ZIP file of the project for you to download. The file contains the most current translations for all project documents (whether or not the translations have been reviewed).

## Document list

Clicking the `Download document list` button downloads an Excel file with basic document metadata and statuses.

## Revision Report

Clicking the `Download revision report` button downloads an Excel file with a read out of all segment revisions and comments made during Review stages.

## Deliver

When it comes time to notify that a project has been completed, click the `Deliver` button and confirm this action. Confirmation will move the project from the Active Projects list to the Delivered Projects list, and send the content through any LILT Connector that is integrated.

## Delivering content

There are several ways that completed translation content can be delivered to its target destination:

1. Manually download the content and send them to where they need to go.

2. Use one of the available [Integrations](/kb/connectors) to send content directly between the platform and the connected application.

3. Use the [LILT for Developers](/kb/developers) to build your own custom delivery solution.


# Project Settings
Source: https://support.lilt.com/kb/project-settings



The Project `Settings` page allows you to adjust the settings of your Projects to help you better manage and streamline the translation process.

<Frame>
  <img />
</Frame>

The `Settings` page contains the following sections that are each discussed below:

* [General settings](/kb/project-settings#h_01FF3405BNRDV3XFJ7M3WWKMVX)

* [Custom properties](/kb/project-settings#h_01FF340AEXXC39FHRH3KEBS857)

* [Workflow settings](/kb/project-settings#h_01FF340F2DY59C5XC7YG7MD96N)

* [Assignment settings](/kb/project-settings#h_01FF3411DER24VEETPE3J54932)

* [Archive and delete](/kb/project-settings#h_01FF340V4NJH3Z1EP786R38MPD)

## General settings

Under general settings, you can change the **Project Name** and **Deadline** of a Project. Click the `Save settings` button to apply any changes you make.

<Frame>
  <img />
</Frame>

## Custom properties

Custom properties add metadata to all segments (of all documents) within a Project. Read the [Project Custom Properties](/kb/project-custom-properties) article for details on how custom properties work and when to use them.

<Frame>
  <img />
</Frame>

## Workflow settings

Note: the default workflow settings for new Projects created within your organization can be set in [Organization Settings](/kb/organization-settings). Adjusting the settings in the Project settings area will only affect that Project.

<Frame>
  <img />
</Frame>

* [**Review sampling rate**](/kb/review-sampling): The percent of segments to be included in the review sample.

* [**Include exact matches**](/kb/review-sampling): Whether to include exact matches from the sample when review sampling.

* **Pretranslate by default:** Whether to automatically Instant Translate documents immediately when they are uploaded. If enabled, you will be able to select the options you want to apply to the documents. These options are explained in the ['Instant Translate as part of your Workflow'](/kb/pretranslating-documents) article.

<Frame>
  <img />
</Frame>

* **Auto-confirm exact matches & repetitions:** TM Leveraging is a feature of LILT that automatically populates unreviewed 100% and 101% [TM matches](/kb/translation-memory-matching) into the empty target text fields of repeated segments across a document that share a Data Source. When the `Auto-confirm exact matches & repetition` option is enabled, segments populated by TM Leveraging:

  * are automatically confirmed

  * have the metadata of the most recent TM match (reviewed or unreviewed)

  * can still be edited by translators and reviewers

*For information on the differences between TM Leveraging and Overwrite Confirmed Segments, see the *[*Overwrite Confirmed Segments*](/kb/auto-propagation)* article.*

## Assignment settings

When a linguist is assigned to a document, they are automatically sent an email notification. Whatever content is in the `Project level instructions` field will be included in all assignment emails for the Project. This is a great place to include any Project instructions that will help your linguists.

<Frame>
  <img />
</Frame>

Note that assignment instructions can also be added at the Organization level, as described in the [Organization Settings](/kb/organization-settings) article.

## Archive and delete

Clicking the `Archive` button archives the Project. This moves the Project from the `Active projects` page to the `Archived projects` page, where it is stored indefinitely. The `Archive` button will then turn into an `Unarchive` button that you can use to move the Project back to the `Active projects` page. Projects can also be unarchived at any time on the `Archived projects` page, as described in the [Navigating the Projects List](/kb/navigating-the-projects-list) article.

Archiving Projects allows you to keep your Active Projects page clean from Projects that aren’t currently being worked on, while still retaining the Project's TM entries in the associated [Data Source](/kb/managing-your-lilt-memories).

<Frame>
  <img />
</Frame>

Clicking the `Delete project` button opens a popup form that walks you through the permanent deletion of the Project. Deleting a Project will permanently delete all its documents and all its TM entries from the associated [Data Source](/kb/managing-your-lilt-memories). Deleting a Project will not delete the associated Data Source.


# Project View
Source: https://support.lilt.com/kb/project-view



When you open a project from the [Projects List](/kb/navigating-the-projects-list), it brings you into the Project view. The Project view gives you access to all the tools you need to monitor and manage a project.

Follow the links below to read more about each page of the Project view:

* **[Documents](/kb/document-actions):** manage the translation documents.

* **[Reference Materials](/kb/reference-materials):** manage reference material to aid in translation.

* **Reports:**

  * **[Leverage Report](/kb/how-to-read-leverage-reports):** view information that can help estimate project duration and budget.
  * **[Project Report](/kb/how-to-read-project-reports):** view information on Project progress and linguist efficiency.
  * [**Revision Report:**](/kb/how-to-read-revision-reports) view segment level revisions and comments from Review stages.

* **[Settings](/kb/project-settings):** adjust the individual Project's settings.

* **[Delivery](/kb/project-delivery):** download, review, and deliver the finalized Project.

<Frame>
  <img />
</Frame>


# Reference Materials
Source: https://support.lilt.com/kb/reference-materials



Reference materials can be added to Projects to provide context for translators and reviewers during translation. For example, if a document describing an image is being translated, it could be useful to provide the image to translators and reviewers. Project managers can utilize the reference materials page to keep all relevant Project files in one place, making the translation process as easy as possible for linguists.

To see the reference material for a Project, navigate to the Project and open `Reference Materials` tab to view the `Project instructions` page and the `Files` pages.

<Frame>
  <img />
</Frame>

## Files

Any reference materials that have been uploaded to the Project will be shown under the `Files` page. Reference material files are Project-specific.

<Frame>
  <img />
</Frame>

## Project instructions

The `Project instructions` page displays additional assignment information for linguists. This information is set by the managers in the [Organization Settings](/kb/organization-settings) (not project-specific) and [Project Settings](/kb/project-settings) (project specific).

<Frame>
  <img />
</Frame>

## Uploading reference materials

Any user with write permissions can upload reference material from their device (for more information on user role permissions, see the [RBAC](/kb/role-based-access-control) article).

Reference materials can be quickly added to Projects during Job creation:

<Frame>
  <img />
</Frame>

To add new reference materials after a Project has already been created, open the Project, navigate to `Reference Materials` > `Files`, click on the `Upload new file` button in the upper-right, and select the files you want to upload. There is no file size limit, but for uploads exceeding 1 GB, it is advised to upload them as a ZIP file.

## Label reference materials

If a Project has many reference documents, labelling them can be a useful way to efficiently organize them. To label a document, click the label button on the right side of the Document card and select the labels you want to apply to the document.

<Frame>
  <img />
</Frame>

## Delete reference materials

If a piece of reference material is no longer needed, it can be deleted by clicking the delete button on the right side of the Document card. This brings up a popup to confirm you want to permanently remove the document from the Project’s reference material for all users.

## Download reference materials

<Frame>
  <img />
</Frame>

Users can download a document by clicking on the `Download` button on the right side of the Document card.

## Search and filter reference materials

If there are many reference materials in a Project, you can easily filter through the documents by their labels to find the documents you need:

1. Click the dropdown button on the Filter button.

2. Select the labels you want to filter by.

3. Clicking the `Apply` button.

You can also search for reference materials by typing into the search bar. The search results will actively filter as you type.

<Frame>
  <img />
</Frame>


# Review Sampling
Source: https://support.lilt.com/kb/review-sampling



LILT’s review sampling settings allow managers to find their team’s perfect balance between reviewing more segments to catch errors and reviewing fewer segments to save on time and money.

By default, a reviewer will review 100% of each document within a Project. However, it is possible to assign only a sample of the Project to be reviewed. Reducing the sample rate can help reduce the time and costs of translation projects.

The default settings for review sampling are managed at the organization level, but they can also be adjusted on a per-Project basis (either when creating a new Project, or in the Project settings page of existing Projects).

The sections below discuss the functionality of the different review sample settings and where the settings are managed within LILT.

## Review sampling workflow

A document must be marked as `Done` in the translation stage for review sampling to take effect. If the document is not marked as `Done` by the translator, the reviewer will be given the entire document to review.

When reviewing a document and review sampling is less than 100%, once the document has been marked as done in Translate mode, a portion of the segments in the document become locked (for both translators and reviewers) equal to the review sampling rate. Reviewers are shown the entire document, but they are only able to work on unlocked segments.

<Frame>
  <img alt="" />
</Frame>

Reviewers will go through all the unlocked segments to accept any segments with correct translations and edit any segments that need to be corrected.

When all documents in the Project are marked as done in Review mode, the manager will be notified.

<Frame>
  <img alt="" />
</Frame>

The manager is notified the project is completed via email. The email includes the number of segments reviewed and the error rate of those segments.

<Frame>
  <img alt="" />
</Frame>

Please note: Each time a document enters the "Review" stage, review sampling generates a fresh, unique set of segments. Returning to a previous workflow stage restarts the sampling process. For example, if a document follows a workflow like "Review > Translate > Review" (with sampling enabled), the sampled segments in the second review will be different from those in the first.

### How to unlock segments

*Once segments have become locked in a document, if you need to unlock any segments, follow these steps:*

1. ***`A project manager needs to open the document in Translate mode and click on File > Unlock document translation.`***
2. *In Review mode, the locked segments can now be unaccepted to unlock them in both Translate and Review mode.*
3. *Once the necessary segments have been modified, marked as done in Translate mode again to lock the segments and proceed with the document review.*

## Review sampling settings

### Review Sampling Rate

The review sample rate is a value from 10% to 100% and can be set in increments of 10%. This value controls the percent of segments that will be assigned for review. The review percentage applies to all documents in the Project.

For example, in a Project with a 20% review sample rate, a document with 100 segments would have 20 segments assigned for review.

### Include exact matches

If the “include exact matches” setting is **enabled**, the following segment types are **included** inthe pool of segments that can be selected for review:

* 100% TM matches
* Repeated segments

If this setting is **disabled**, the above segment types are **excluded** from the pool of segments that can be selected for review. There are two separate settings to apply this to the Review Sample and the Secondary Review Sample.

For example, if a document is 100 segments long and has 40 repeated segments, the remaining 60 segments will be included in the pool of segments that can be selected for review. If this document is in a project with a review sampling rate of 20%, then 20% of the remaining 60 segments would be sampled (12 segments).

## Managing review sample settings

The review sample settings are set in the [Organization Settings](/kb/organization-settings) and are used to populate the settings of new Projects. Review sample settings can also be set on a per-Project basis in Project settings.

### Organization setting

To set the review sample settings for your organization, navigate to the `Settings` page, open the `Workflow` tab, and scroll down to the `Review` section. From there, you can set the settings for:

* Review sampling rate (two separate settings for Review and Secondary Review samples)
* Include exact matches (two separate settings for Review and Secondary Review samples)

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

*Note: Changing the default setting for review sampling in the Organization Settings does not update the settings of existing Projects.*

The “Include exact matches” setting is toggled off by default. Turning on “Include exact matches” at an org level would then turn it on for all new projects, or you can turn it on on a project basis depending on their needs.

### Project setting

Once a Project has been created, you can change the review sample settings by opening the Project, navigating to the `Project settings` page, and scroll down to the `Workflow settings` section.

<Frame>
  <img alt="" />
</Frame>

After changing the settings, click the `Save settings` button to apply the changes. Making changes here will not affect documents that have already been sampled for review, nor will it affect the Organization workflow settings.


# Segment Comments and Error Flagging
Source: https://support.lilt.com/kb/segment-comments



[LILT Verify](/kb/introduction-to-lilt-translate) is equipped with an easy-to-use comment system for translators and reviewers. Comments are intended to help explain or accompany direct changes to segments rather than dictate changes to the translation itself. This comment system facilitates organized and efficient communication to save everyone time while processing documents. This article discusses ways that translators and reviewers can make the most of the LILT comment system.

### Comment scope

Comment data is only accessible from the document and Project the comment was made in. Comment data is not added to the translated content as any kind of metadata. To share comment information outside a Project, a manager can download and share the Project's [Revision Report](/kb/how-to-read-revision-reports).

### Comments in Translate mode

In Translate mode, comments can be added to any segment by clicking the `Add note` button next to the desired segment.

<Frame>
  <img />
</Frame>

Translators can utilize segment comments to communicate with reviewers and managers, add notes, make to-do lists, and create reminders. If there are multiple translators, comments can be used as a space for discussion among translators.

Multiple comments can be made on one segment and are kept in a thread, allowing you to see the entire comment history.

Comments can contain clickable URLs. As an example, sometimes you may want to link to web pages with term definitions.

If a segment has any comments, it will display the number of comments on the `Add note` button so it’s easy to tell which segments need attention.

<Frame>
  <img />
</Frame>

If your comment is about an issue that has been resolved, you can click the `Resolve` button.

<Frame>
  <img />
</Frame>

to remove your comment from the thread, and the comment will no longer show in the Translate stage.

If you need to edit or delete your comment, you can bring up those options by clicking the `More actions` button on the comment.

### Error flagging in Review and Secondary Review mode

In Review and Secondary Review mode, reviewers can flag any segment as having an error by clicking the "`Add/View errors"`button.

<Frame>
  <img />
</Frame>

To add an error, the reviewer will need to select an error category, sub-category, severity, and enter a comment about the error. Once completed, click the "`Add"` button.

<Frame>
  <img />
</Frame>

*Please note: If the organization setting for Error Logging is turned on, error logging is mandatory when a reviewer changes anything in the target segment. Please reference the [Organization Settings](/kb/organization-settings) page for more information.*

**Error categories**: Accuracy; Linguistic Conventions; Terminology; Style; Design; Locale convention; Audience appropriateness; Source

**Error sub-categories**:

* *Accuracy*: Addition, Omission, Mistranslation, Over-translation, Under-translation, Untranslated, Improper TM match, Do not translate

* *Linguistic Conventions*: Punctuation, Spelling, Grammar, Inconsistency, Character encoding, Unintelligible

* *Terminology*: Inconsistent with termbase, Inconsistent use of terminology, Wrong term

* *Style*: Awkward, Company style, Inconsistent style, Third-party style, Unidiomatic, Language register,Inconsistent with external reference

* *Design*: Local formatting, Markup, Missing text, Truncation/text expansion, Link/cross reference, Character formatting, Layout

* *Locale Convention*: Address format, Date format, Currency format, Measurement format, Shortcut key, Telephone format, Number format, Time format

* *Audience appropriateness*: Culture Specific Reference, Offensive

* *Source*: Source error

**Error Severities:** Critical, Major, Minor, Neutral, Kudos, and RepeatedError

If your error flag is about an issue that has been resolved, you can click the `Resolve` button to remove your error flag from the thread, which means it will no longer show in the Review stage.

<Frame>
  <img />
</Frame>

If you need to edit or delete your error flag, you can bring up those options by clicking the `More actions` button on the comment.

If a segment has any error flags, it will display the number of error flags on the `Add/View errors`button so it’s easy to tell which segments need attention.

<Frame>
  <img />
</Frame>

Errors are compiled into a [Revision Report](/kb/how-to-read-revision-reports) that is delivered to the translators at the end of the project. The report displays the source text and target text so translators can learn from errors made during the project.

## Error Flagging 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 change. For example, if there was a shift in meaning and also a typo, use category “Accuracy” and severity “Major”. Please see the [Error Typology](/kb/segment-comments#SegmentCommentsandErrorFlagging-ErrorTypology) table below for definitions of severities, categories, and sub-categories.

**What should I do if I have a repeated error?**

The first time you see an error, mark it as usual: using a category, sub-category, and severity. The second time onward, use the same category/sub-category, but use the severity *Repeated Error*. This should be done if:

* The segments are identical

* 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.

Please see the definition for *Repeated Error* in the Error typology table below for a complete definition.

## Error Typology

<table>
  <tbody>
    <tr>
      <th>
        <p><strong>Error Severities</strong></p>
      </th>
    </tr>

    <tr>
      <td>
        <p>Critical</p>
      </td>

      <td>
        <p>This is the severest category type available, weighing above Major in its extreme severity. Usage is strictly restricted to only the most extremely severe of errors, which would render the content unfit for use. </p>
        <p><em>Example: The error renders the target text unfit for purposes or incomprehensible, or poses a risk for serious physical, financial or reputational harm.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Major</p>
      </td>

      <td>
        <p>An error that changes the core meaning significantly. It is likely to seriously mislead or confuse the user.</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Minor</p>
      </td>

      <td>
        <p>An error that doesn’t lead to loss of meaning and wouldn’t confuse or mislead the user, but would be noticed.</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Neutral (Not an Error)</p>
      </td>

      <td>
        <p>Used for edits that are not error corrections, but reflect an evaluator’s choice or preference.</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Repeated Error</p>
      </td>

      <td>
        <p>If the same, identical error recurs, record the 2nd occurrence onwards as 'Repeated'. For example, if dates have been written as MM/DD/YYYY consistently through the text, as opposed to DD/MM/YYYY, record the 2nd instance onwards as a repeated error.</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Kudos</p>
      </td>

      <td>
        <p>Used to highlight a particularly good translation or one that has a high positive impact.</p>
      </td>
    </tr>
  </tbody>
</table>

<table>
  <tbody>
    <tr>
      <th>
        <p><strong>Error Categories and Sub-Categories</strong></p>
      </th>
    </tr>

    <tr>
      <td>
        <p>Accuracy</p>
      </td>

      <td>
        <p>Addition</p>
      </td>

      <td>
        <p>Target content that includes content not present in the source.</p>
        <p><em>Example: A translation includes portions of another translation that were inadvertently pasted into the document.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Omission</p>
      </td>

      <td>
        <p>Errors where content is missing from the translation that is present in the source.</p>
        <p><em>Example: A paragraph present in the source is missing in the translation.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Mistranslation</p>
      </td>

      <td>
        <p>Target content that does not accurately represent the source content.</p>
        <p><em>Example: A source text states that a medicine should not be administered in doses greater than 200 mg, but the translation states that it should be administered in doses greater than 200 mg (i.e., negation has been omitted).</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Over-translation</p>
      </td>

      <td>
        <p>Target text that is inappropriately more specific than the source text.</p>
        <p><em>Example: The source text refers to a boy, but is translated with a word that applies only to young boys rather than the more general term.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Under-translation</p>
      </td>

      <td>
        <p>Target text that is inappropriately less specific than the source text.</p>
        <p><em>Example: The source text uses words that refer to a specific type of military officer, but the target text refers to military officers in general. </em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Untranslated</p>
      </td>

      <td>
        <p>Errors occurring when a text segment that was intended for translation is left untranslated in the target content.</p>
        <p><em>Example: A sentence in a Japanese document translated into English is inappropriately left in Japanese.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Improper TM match</p>
      </td>

      <td>
        <p>A match from the translation memory has been left unedited in the target text, where it does not accurately reflect the source.</p>
        <p><em>Example: A 99% match from the translation memory has been inserted into the translation but has not been edited to include the extra tag that exists in the new source text.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Non-Translatables</p>
      </td>

      <td>
        <p>Errors occurring when a text segment or even a whole section of a text marked in the specifications as “Do not translate!” is translated in the target text.</p>
        <p><em>Examples: </em></p>

        <ul>
          <li>
            <p><em>A marketing slogan for worldwide use is intended to remain in English. </em></p>
          </li>

          <li>
            <p><em>A product name should not be translated because it is supposed to remain in English.</em></p>
          </li>
        </ul>
      </td>
    </tr>

    <tr>
      <td>
        <p>Linguistic Conventions</p>
      </td>

      <td>
        <p>Punctuation</p>
      </td>

      <td>
        <p>Punctuation incorrect for the locale or style.</p>
        <p><em>Example: An English text uses a semicolon where a comma should be used.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Spelling</p>
      </td>

      <td>
        <p>Error occurring when the letters in a word in an alphabetic language are not arranged in the normally specified order.</p>
        <p><em>Example: The German word Zustellung is spelled Zustetlugn.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Grammar</p>
      </td>

      <td>
        <p>Error that occurs when a text string (sentence, phrase, other) in the translation violates the grammatical rules of the target language.</p>
        <p><em>Example: An English text reads: The man was seeing the his wife.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Unintelligible</p>
      </td>

      <td>
        <p>Text garbled or incomprehensible, perhaps due to conversion or other processing errors.</p>
        <p><em>Example: The following text appears in an English translation of a German automotive manual: “The brake from whe this કુતારો િસ S149235 part numbr,,.”</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Character encoding</p>
      </td>

      <td>
        <p>Error occurring when characters garbled due to incorrect application of an encoding.</p>
        <p><em>Example: A text document in UTF-8 encoding is opened as ISO Latin-1, resulting in all upper ASCII characters being garbled.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Inconsistency</p>
      </td>

      <td>
        <p>Inconsistency in Linguistic Conventions can arise when a translation fails to consistently apply the rules and stylistic preferences of the target language. This may include variations in terminology, grammatical structures, punctuation, capitalization, and idiomatic expressions.</p>
        <p><em>Example: Irregular application of capitalization rules, such as capitalizing certain nouns in one instance but not in others, contrary to the conventions of the target language.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Terminology</p>
      </td>

      <td>
        <p>Inconsistent with termbase</p>
      </td>

      <td>
        <p>Use of a term that differs from term usage required by a specified termbase or other resource.</p>
        <p><em>Examples:</em></p>

        <ul>
          <li>
            <p><em>A termbase specifies that the term USB memory stick should be used, but the text uses USB flash drive.</em></p>
          </li>

          <li>
            <p><em>A French text translates English e-mail as email but terminology guidelines mandated that courriel be used.</em></p>
          </li>

          <li>
            <p><em>The English musicological term dog is translated (literally) into German as Hund instead of as Schnarre, as specified in a terminology database.</em></p>
          </li>
        </ul>
      </td>
    </tr>

    <tr>
      <td>
        <p>Inconsistent use of terminology</p>
      </td>

      <td>
        <p>Use of multiple terms for the same concept in cases where consistency is desirable.</p>
        <p><em>Example: The text refers to a component as the brake release lever, brake disengagement lever, manual brake release, and manual disengagement release.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Wrong term</p>
      </td>

      <td>
        <p>Use of a term that is not the term a domain expert would use or because it gives rise to a conceptual mismatch. </p>
        <p><em>Example: The word 'river' in an English source text is translated into French as 'rivière' . But the river in question flows into the sea, not into a lake or another river, so the correct French translation should have been ' fleuve'.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Style</p>
      </td>

      <td>
        <p>Awkward style</p>
      </td>

      <td>
        <p>Style involving excessive wordiness or overly embedded clauses, often due to inappropriate retention of source text style in the target text.</p>
        <p><em>Example: A text is written with many embedded clauses and an excessively wordy style. While the meaning can be understood, the text is unnatural and difficult to follow.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Company style</p>
      </td>

      <td>
        <p>Errors occurring where the text violates company-specific style guidelines.</p>
        <p><em>Example: Company style states that passive sentences may not be used, but the text uses passive sentences.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Inconsistent style</p>
      </td>

      <td>
        <p>Style that varies inconsistently throughout the text, often due to multiple translators contributing to the target text.</p>
        <p><em>Example: One part of a text is written in a light and terse style while other sections are written in a more verbose style.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Third-party style</p>
      </td>

      <td>
        <p>Errors occurring when the text violates a third-party style guide.</p>
        <p><em>Example: Specifications stated that English text was to be formatted according to the Chicago Manual of Style, but the text delivered followed the American Psychological Association style guide.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Unidiomatic style</p>
      </td>

      <td>
        <p>Style that is grammatical, but unnatural, often due to interference from the source language.</p>
        <p><em>Example: The following text appears in an English translation of a German letter: “We thanked him with heart” where “with heart” is an understandable but non-idiomatic rendering, better stated as “heartily”.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Inconsistent with external reference</p>
      </td>

      <td>
        <p>Errors occurring when text fails to conform to an external resource.</p>
        <p><em>Examples:</em></p>

        <ul>
          <li>
            <p><em>A translation refers to a court decision but does not accurately reflect the language of the decision.</em></p>
          </li>

          <li>
            <p><em>A target text translates text that should have been quoted from an existing text.</em></p>
          </li>
        </ul>
      </td>
    </tr>

    <tr>
      <td>
        <p>Register</p>
      </td>

      <td>
        <p>Errors occurring when a text uses a level of formality higher or lower than required by the specifications or by common language conventions.</p>
        <p><em>Example: A formal letter uses contractions, colloquialisms and expressions characteristic of spoken rather than written language, and thus makes a less serious impression than intended.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Design</p>
      </td>

      <td>
        <p>Layout</p>
      </td>

      <td>
        <p>Inappropriate presentation format of paragraphs, headings, graphical elements, and user interface elements and their arrangement on a form, page, website, or application screen.</p>
        <p><em>Example: A fully justified paragraph was copied from one document and pasted into another where surrounding paragraphs were flush left, ragged right, creating a visual mismatch.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Character formatting</p>
      </td>

      <td>
        <p>Inappropriate application of any glyph variation that is applied to a character or string of characters, such as font, font style, font color, or font size.</p>
        <p><em>Examples:</em></p>

        <ul>
          <li>
            <p><em>A corporate style guide specifies that body text in technical publications should be set in a serif font, but body text in advertising and public reports should be set in a sans serif font. </em></p>
          </li>

          <li>
            <p><em>The body text for an annual report was incorrectly set using the serif font specified for technical publications.</em></p>
          </li>
        </ul>
      </td>
    </tr>

    <tr>
      <td>
        <p>Markup tag</p>
      </td>

      <td>
        <p>Incorrect markup tag or tag component.</p>
        <p><em>Example: Markup is used incorrectly, resulting in incorrect formatting.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Missing text</p>
      </td>

      <td>
        <p>Existing text missing in the final laid-out version.</p>
        <p><em>Example: A translation is complete, but during DTP a text box was inadvertently moved off the page and so the translated text does not appear in a rendered PDF version.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Truncation/text expansion</p>
      </td>

      <td>
        <p>Target text that is longer or shorter than allowed or where there is a significant and inappropriate discrepancy between the source and the target text lengths.</p>
        <p>Examples:</p>

        <ul>
          <li>
            <p>The German translation of an English string in a user interface runs off the edge of a dialogue box and cannot be read.</p>
          </li>

          <li>
            <p>An English sentence is 51 characters, but its German translation is 253 characters and does not fit in the available space.</p>
          </li>

          <li>
            <p>A source text is 300 characters but the translation is 15 characters, indicating a likely problem.</p>
          </li>
        </ul>
      </td>
    </tr>

    <tr>
      <td>
        <p>Link/cross-reference</p>
      </td>

      <td>
        <p>Incorrect or invalid (no longer active) link or URI.</p>
        <p><em>Example: An HTML file contains numerous links to other HTML files; some have been updated to reflect the appropriate language version while some point to the source language version.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Locale formatting</p>
      </td>

      <td>
        <p>Errors or inconsistencies in the visual or structural presentation of translated content that fails to align with the locale-specific conventions or expectations. These issues are distinct from text-specific translation errors and focus on the design aspects that influence how the content is perceived and understood in the target locale.</p>
        <p><em>Example: Failing to adapt the layout and orientation of content for right-to-left languages like Arabic or Hebrew, leading to awkward or confusing user experiences.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Locale convention</p>
      </td>

      <td>
        <p>Address format</p>
      </td>

      <td>
        <p>Inappropriate address format for its locale.</p>
        <p><em>Example: An online form translated from English to Hindi requires a house number even though many addresses in India do not include a house number, or the postal code is in the wrong position for a given locale.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Number format</p>
      </td>

      <td>
        <p>Inappropriate number format for its locale.</p>
        <p><em>Example: US-English target text retains German-style use of full stops and commas.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Date format</p>
      </td>

      <td>
        <p>Inappropriate date format for its locale.</p>
        <p><em>Example: A German text has 06/07/2012 for 7 June 2012 instead of 07.06.2012.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Currency format</p>
      </td>

      <td>
        <p>Incorrect currency format for its locale.</p>
        <p><em>Example: A text dealing with business transactions from English into Hindi assumes that all currencies will be expressed in simple units, while the convention in India is to give such prices in lakh rupees (100,000 rupees).</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Measurement format</p>
      </td>

      <td>
        <p>Inappropriate measurement format for its locale.</p>
        <p><em>Example: A text created for use in France uses feet and inches and Fahrenheit temperatures.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Shortcut key</p>
      </td>

      <td>
        <p>Shortcuts in a translated software product do not conform to locale expectations or make no sense for the locale.</p>
        <p><em>Example: A software product uses CTRL-S to save a file in Hungarian, rather than the appropriate CTRL-M (for menteni).</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Telephone format</p>
      </td>

      <td>
        <p>Inappropriate telephone form for telephone numbers for its locale.</p>
        <p><em>Example: A German text presents a telephone number in the format (xxx) xxx - xxxx instead of the expected 0xx followed by a group of digits separated into groups by spaces.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Time format</p>
      </td>

      <td>
        <p>Error involving incorrect time format for its locale. </p>
        <p><em>Example: Unless specified as using a 24 hour clock, US time formats report time after noon using 12-hour notation (for instance, '7:54:12 pm' instead of '19:54:12' used in many other countries.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Audience appropriateness</p>
      </td>

      <td>
        <p>Culture specific reference</p>
      </td>

      <td>
        <p>Errors where content inappropriately uses a culture-specific reference that will not be understandable to the intended audience.</p>
        <p><em>Example: An English text refers to steps in a process as First base, Second base, and Third base, and to successful completion as a Home run and uses other metaphors from baseball. These prove difficult to translate and confuse the target audience in Germany.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Offensive</p>
      </td>

      <td>
        <p>Content that breaches commonly accepted standards of decent and proper speech, and is hence likely to offend the intended audience or other likely readers. </p>
        <p><em>Example: A source text refers to bacon as an example of a tasty food, but the reference is offensive when translated into Arabic.</em></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Source</p>
      </td>

      <td>
        <p>Source error/ambiguity</p>
      </td>

      <td>
        <p>An error introduced due to an error or ambiguity in the source text.</p>
      </td>
    </tr>
  </tbody>
</table>


# Segment Context
Source: https://support.lilt.com/kb/segment-context



LILT's Segment Context sidebar provides linguists with a range of tools to assist with translation. Utilizing these tools helps to maintain consistent translations across documents that share a Data Source.

The Segment Context sidebar displays the following information for the active segment:

* Any Translation Memory (TM) matches
* Any Termbase (TB) matches
* Suggested translation (powered by LILT's Contextual AI Engine)
* Segment metadata (e.g. character limits)

<Frame>
  <img alt="" />
</Frame>

## TM match results

If the active segment matches with any TM entries in the associated Data Source, the matching TM entries are displayed.

TM entry display order:

* **reviewed** (green `TM` icon) / **unreviewed** (gray `TM` icon)
* **match percent** (matches below 75% are not displayed)
* **most recently updated**

***Note that while TM entries in the Segment Context sidebar are displayed in order of reviewed/unreviewed status, the reviewed/unreviewed status does not affect TM match prioritization or model training.***

If there are any duplicate TM entries, this will be displayed as an `identical results` dropdown. Click on the dropdown to display the `author` and `time updated` data for each of the identical entries.

Use keyboard shortcut “Ctrl + Shift + S” to insert the top TM entry into the segment editor.

<Frame>
  <img alt="" />
</Frame>

## TB match results

Matching TB entries are displayed in `Segment context` sidebar. If a source term has more than one approved target term, each is shown as a separate match (up to the 4 most recent).

<Frame>
  <img alt="" />
</Frame>

**Note that terms must be been marked as reviewed to be able to show up as matches.**

As described in the [Terminology](/kb/terminology) article, new TB entries can be added directly from inside [LILT Verify](/kb/introduction-to-lilt-translate) by clicking the `Add New` button.

### TB entry metadata

To view TB entry metadata, click on the term or the info icon.

<img alt="Screenshot 2026 10 01 At 2 41 52 Pm" />

When importing files, LILT looks for and imports metadata based on common patterns, such as Excel cell locations, JSON keys, web page property types, etc. If your file is highly customized or provides metadata in an alternate method, that metadata may not show up on the Segment Metadata section of the Segment Context sidebar. Metadata fields can also be added inside the LILT application, as described in the following articles:

* [Managing Termbase and Translation Memory Entries](/kb/managing-termbase-and-translation-memory-entries)
* [Data Source Settings](/kb/memory-settings)

Metadata typically is structured into relevant information for a given word or phrase in regard to the part of speech, participle, case, as well as links to image context.

## Contextual AI result

TheContextual AI result displayed in the Segment Context sidebar is the same as the translation suggestion displayed under the segment when the target text is empty.

The translation [suggestion](/kb/machine-translation) is generated by the trained Contextual AI model and the associated Data Source.

<Frame>
  <img alt="" />
</Frame>

### Opening, closing and resizing the sidebar

The sidebar sits on the right of the editor, next to an icon rail.

* **Close:** click the active rail icon. The sidebar collapses to the rail and the segment editor expands to fill the space.
* **Open:** click any rail icon to open the sidebar to that tab.
* **Resize:** drag the sidebar's left edge to make it wider or narrower. This is especially helpful when reviewing the style guide or concordance, where a larger viewing pane is often needed. The width resets to the default when you reload the page.

The editor expands when the sidebar is closed in both default and split view.


# Segment State Indicators
Source: https://support.lilt.com/kb/segment-state-indicators



The segment state indicators within [LILT Verify](/kb/introduction-to-lilt-translate) display the state of each segment to translators and reviewers at a glance, allowing them to spend their time efficiently when working within LILT Verify.

## Translation indicators

When a translator confirms a segment, a \*\*single checkmark icon \*\*is displayed on the left side of the confirmed segments. This icon indicates that the segment is confirmed and ready for review. Unconfirmed segments do not have any checkmarks.

<Frame>
  <img />
</Frame>

Confirmed segment state

## Review indicators

Once a reviewer starts working on the document, they will see segments with **single checkmarks**, indicating that those segments are ready for review. When a reviewer accepts a segment, the icon will convert to **double checkmarks in a solid green circle**.

<video />

Review segment state

## Locked segment state

You may encounter locked segments during your review. For example, if [Review Sampling](/kb/review-sampling) is enabled, segments that are not included in the review sample are marked with a **padlock icon in a gray circle**.

<Frame>
  <img />
</Frame>

Locked segments from Review Sampling

Organizations may allow linguists to unlock and update locked segments during the Review workflow stage. This is intended as a safety valve specifically if errors are spotted during a Review so you can quickly and easily correct any errors present. To unlock a segment, click on the unaccept button. Make any necessary edits and re-accept the segment.

*Please note: If the segment you unaccepted was an exact match, an* <img /> *icon will appear and share that information upon hover.*

<video />

Unlocking and updating locked segments


# Source Highlighting Tool
Source: https://support.lilt.com/kb/source-highlighting-tool



[LILT Verify](/kb/introduction-to-lilt-translate) comes with a source highlighting tool that gives linguists quick access to terminology tools. To open the tool options popup, simply highlight the desired word or phrase in the source text. Once open, click any of the options to perform the corresponding action.

<Frame>
  <img />
</Frame>

Source highlighting tool options:

* **Copy to clipboard:** Copies the highlighted source words to the clipboard.

* \*\*Copy to target: \*\*Copies the highlighted source words into the target text field.

* **Lookup in Segment Context:** Opens the [Segment Context](/kb/segment-context) sidebar, puts the selected source text into the search field, and searches for the text.

* **Lookup in Concordance:** Opens the [Concordance](/kb/concordance) sidebar, puts the selected source text into the search field, and searches for the text.


# Split & Merge Segments
Source: https://support.lilt.com/kb/split-merge-segments



[LILT Verify](/kb/introduction-to-lilt-translate) contains functionality to easily split and merge segments, allowing linguists to organize a document's segments as they see best.

When a document is uploaded, LILT processes the source text into segments in a way that aims to maximizethe quality of AI-generated translations. While segments can range in length from a paragraph to a one word header, quality tends to degrade with sentence length, so LILT prefers shorter segments. The segmenter can sometimes make mistakes, but these mistakes can be corrected afterward by manually splitting or merging segments.

The split and merge tools can be accessed at any time by clicking on the `Segment editing tools` button within the segment you want to edit.

<Frame>
  <img alt="" />
</Frame>

Confirmed segments cannot be split or merged. To perform these actions with a confirmed segment, you need to first unconfirm the segment.

## Splitting a segment

1. Click the `Split segment` button to bring up the split segment tool. This tool displays as a vertical marker within the segment.

<Frame>
  <img alt="" />
</Frame>

2. Drag and drop the vertical marker to set the split position. All content before the marker will be kept in the current segment. All content after the marker will be split into a new segment inserted after the current segment.

<Frame>
  <img alt="" />
</Frame>

3. Once the vertical marker is where you want it, click the check mark in the bottom-right to split the segment. You can also cancel by clicking on the `X` button in the top-right.

## Merging segments

Click the `Merge with next segment` button to merge the current segment with the segment below it.

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

Note that LILT does not allow merging of segments that are:

* from different paragraphs in the source text
* from two different cells in a spreadsheet
* two different trans-units in XLIFF files
* already confirmed (to rectify, unconfirm the segments, merge them, and then re-confirm)


# Tags & Formatting
Source: https://support.lilt.com/kb/tags-formatting



[LILT Verify](/kb/introduction-to-lilt-translate) supports the importing, exporting, and arranging of tagged text. This includes both structural tags (e.g. spacing, line breaks) and formatting tags (e.g. **bold**, *italic*, underline). Other arbitrary tags may not be displayed in LILT Verify, but they will be preserved in the document.

As an example, let's see how LILT would display a Word document containing the following sentence:

This sentence has some bold text.

In LILT Verify, the bolded text will be wrapped in a tag pair. Each tag pair holds information about what kind of formatting should be applied to the text within the tag pair.

<Frame>
  <img />
</Frame>

Tags in the source text are fixed, but tags in the target text can be moved around to allow linguists to ensure the structure and formatting of content is carried over correctly during translation.

This article covers the following topics:

* [Tags overview](/kb/tags-formatting#h_01F3XZVKB947Q7MNV9S6NKXFMQ)

* [Editing tags](/kb/tags-formatting#h_01F3XZVT0JMME25K4Q3HWRW2PS)

* [Tag color indicators](/kb/tags-formatting#h_01F3XZVXZCKZYRAM1T4JY9EZKP)

* [Tag validation](/kb/tags-formatting#h_01F3XZW26BMVK83STNKKR3E3AR)

* [Tag auto-propagation](/kb/tags-formatting#h_01F3XZW655X48736XD7ETV4HJV)

For information on Tags QA, see the [Tags Quality Assurance](/kb/tags-quality-assurance) article.

## Tags overview

Once a segment has been translated and confirmed, LILT will automatically project the source tags into the translated text. For this reason, tags can generally be ignored during translating. *For more information on our Research Team's work on tag projection, see [this article](https://aclanthology.org/2021.findings-emnlp.299.pdf).*

<video />

If you want to move tags around before confirming a segment, you can manually project the tags at any time by opening the `Tags` tab and selecting the `Project target tags` option (shortcut `Ctrl` + `Alt` + `N`). Note that tags can be moved even after the segment is confirmed.

<video />

Once tags have been projected into the target text, they will always be displayed. For this reason, we recommend using the menu to Project target tags, and then move the tags if required before confirming the segment. Tags will project automatically when the segment is confirmed, and must be checked before moving onto the next segment.

Each tag is part of a tag pair that marks where the tag starts and ends:

* **The opening tag:**

  <Frame>
    <img />
  </Frame>

  contains the tag number and tipple dot: `...`

* **The closing tag:**

  <Frame>
    <img />
  </Frame>

  contains a backslash and the tag number

Clicking on the tipple dot `...` part of an opening tag displays information about the tag.

<video />

## Display settings

<Frame>
  <img />
</Frame>

**Show source tags** - By default, LILT Verify displays source text tags. If you find this gets in the way during translation, you can hide the source tags by deselect the `Show source tags` option in the `Tags` tab.

* Note that 100% and 101% TM matches with the same source text, but different source tags, are counted as 99% matches.

**Show target tags** - By default, LILT Verify displays target tags. Disabling this setting hides all tags in the target segment (even if the segment has been confirmed). QA still checks for tag errors and linguists will need to fix any tag errors before they can confirm a segment. LILT will automatically unhide tags in the target segment if segment confirmation fails because of tag errors (ignoring the setting for just that segment) so linguists don’t have to manually turn off the setting every time.

**Project target tags** - If you want to move tags around before confirming a segment, you can manually project the tags at any time by opening the `Tags` tab and selecting the `Project target tags` option (shortcut `Ctrl` + `Alt` + `N`). Note that tags can be moved even after the segment is confirmed. Once tags have been projected into the target text, they will always be displayed. For this reason, we recommend using the menu to Project target tags, and then move the tags if required before confirming the segment. Tags will project automatically when the segment is confirmed, and must be checked before moving onto the next segment.

## Editing tags

Once tags have been projected into the target text, they can be manipulated with keyboard shortcuts so you don’t have to take your hands off the keyboard while processing segments in LILT Verify.

<video />

You can find the tag hotkeys listed in the `Tags` tab and in the [Hotkeys](/kb/hotkeys) article.

If you prefer to use your mouse, tag editing can be accomplished by mousing over a tag, clicking it, dragging it to where you want, and then releasing the mouse button to place the tag.

<video />

A few notes about tag manipulation:

* Manipulating tags will unconfirm/unaccept segments.

* Tags are automatically saved after being placed. No additional saving is required.

* Tags cannot be added, changed, or deleted.

## Tag color indicators

Tags are shown in different colors to indicate different states:

* <img />

  **Gray:** normal tag

* <img />

  **Green:** currently selected tag (use the keyboard shortcuts to move the currently selected tag)

* <img />

  **White with green outline:** the matching paired tag for the currently selected tag (you can use the keyboard shortcut to jump to the matching tag)

* <img />

  <img />

  **Red:** invalid position (nesting does not match source)

## Tag validation

LILT has automatic checks to determine whether tags are positioned and nested correctly. When a tag is invalid, it shows as red and cannot be saved (or segment confirmed) until the tag position is resolved to be valid.

<Frame>
  <img />
</Frame>

LILT also has a [QA check tool](/kb/quality-assurance-tools) that allows linguists to search for potential [tag issues](/kb/quality-assurance-tools) at any time across a single segment or all segments in a document.

## Tag auto-propagation

If forward auto-propagation or backward auto-propagation are turned on in the `Settings` tab, tag changes are automatically propagated across the document for segments with 100% TM matches. This means that if you change target tag positions in a segment and confirm the segment, in any other segment with the same source tags, the target tags will be propagated to match.

<video />


# Terminology
Source: https://support.lilt.com/kb/terminology



LILT provides a range of tools for project managers, translators, and reviewers to efficiently manage terminology. The tools and functions of [LILT Verify](/kb/introduction-to-lilt-translate) encourage translators and reviewers to adhere to terminology standards for a given project.

Terminology refers to terms (words or phrases) that have pre-defined translations. In LILT, terminology is held inside the Data Source as Termbase (TB) entries, where each TB entry contains a source term and a target term.

## Terminology in LILT Verify

When a document is opened in LILT Verify, LILT automatically searches the associated Data Source for matching TB entries that are marked as reviewed. When a match is found, the term is highlighted in the following places:

1. **Source text:** Source terms are highlighted in orange if the corresponding target term is not already in the target text area. If the term is in the target text area, the source term is highlighted in green.
2. **Translation suggestions:** The Contextual AI Engine displays terminology suggestions in orange.

Once the term has been used, the word is highlighted in green in the source and target text.

<Frame>
  <img alt="" />
</Frame>

If there are overlapping term entries (e.g. for "Ancient Greece" and "Greece"), only the longest term is highlighted in the source text and displayed in the tooltip.

In the Segment Context sidebar, each approved target term is now shown as a separate match with its own metadata (up to the 4 most recent). The Segment Context sidebar also displays term metadata about who approved the term and the approval date.

### Multiple target terms

A source term can have more than one approved target term — for example, when the right translation depends on context. When this happens, the Segment Context sidebar shows each target term as a separate match, with its own metadata, so you can choose the right one for the segment.

* Up to the **4 most recent distinct target terms** are shown for each source term.
* If the same source and target pair appears more than once in the termbase, it's shown once, using the metadata from the most recent entry.
* **AI QA and terminology checks** treat any of these target terms as correct. Using an approved alternative won't be flagged as an error.
* **AI Review** uses the most recent target term.

If your termbase has many duplicate or conflicting entries, we recommend cleaning them up or adding metadata (such as a definition or usage note) so experts can tell the options apart.

## Case sensitivity for TB matching

The case sensitivity of TB matching is set in the [Settings](/kb/memory-settings) page of each Data Source. By default, newly created Data Source have the `Case-sensitive matching` option enabled.

<Frame>
  <img alt="" />
</Frame>

As an example, let's see what would happen if we are use an English to GermanData Source with only one TB entry:

bananas > bananen

<Frame>
  <img alt="" />
</Frame>

We'll also add a document with the following segment into a Project that utilizes this Data Source:

Bananas come in different sizes and colors, but all bananas grow in clusters.

If the `Case-sensitive matching` option is disabled, LILT ignores differences in case when finding matches. In LILT Verify, we will see that both "Bananas" and "bananas" are found to have TB matches.

<Frame>
  <img alt="" />
</Frame>

If the `Case-sensitive matching` option is enabled, LILT obeys differences in case when finding matches. In LILT Verify, we see that only "bananas" is found to have a TB match.

<Frame>
  <img alt="" />
</Frame>

## Searching existing terminology

You can search for terminology in the Segment Context sidebar. If you are searching for an item which has multiple variations within the Termbase, several options may appear in the target list. Depending on how thorough the Termbase is that was uploaded into the Data Source, this functionality assists in selecting the best possible translation for the source content you are translating.

## Adding new terminology

Translators and reviewers can manually add new terminology to the Termbase for future reference. When operating in teams, this can be an especially powerful tool to help maintain consistency across the team.

TB entries can be added by opening the `Segment context` sidebar and clicking the `Add entry` button (Windows shortcut: `Alt`+`A`; Mac shortcut: `Option`+`A`) to open the `Add new entry` form.

<Frame>
  <img alt="" />
</Frame>

Adding new terminology from the sidebar

The `Add new entry` form has the following fields to fill in:

* **Source text**
* **Target text**

**Approval status (managers and reviewers only):** Draft, reviewed, unreviewed. Note: when translators add an entry, the approval status will be set to `unreviewed`.  Entries must be in the `reviewed` state for them to be displayed in LILT Verify.

* **Custom fields:** Custom fields allow metadata to be added.

In addition, the following fields are automatically filled in (based on the segment in focus) and cannot be changed:

* Segment source
* Segment target

<Frame>
  <img alt="" />
</Frame>

## Reviewing and approving new terms

Managers and reviewers who open a document in Review mode have the ability to approve new terms from directly within the LILT Verify. *Note: Reviewers must be assigned to the document to be able to open the document are review the relevant added terms.*

In Review mode, you will see an `unreviewed terms` indicator (matching the number of terms to review) on the segment links sidebar icon. Click the segment links icon, then review each term to either `approve` the term to move it to the `reviewed` state, or `ignore` the term to leave it in the `unreviewed` state.

\*\*Note: \*\***`Entries must be in the reviewed state for them to be displayed in LILT Verify.`**

<Frame>
  <img alt="" />
</Frame>

## Terminology metadata

Click on any TB match in the sidebar (either the info icon or on the term directly) to see any metadata attached to the term. When a source term has multiple target terms, each one shows its own metadata.

<img alt="Screenshot 2026 10 01 At 2 41 52 Pm" />

## Source highlighting tool

The source highlighting tool functions as a way to quickly access the terminology tools. Using the mouse, highlight the source text you're interested, then right-click on the text to open the tool options:

* **Copy to target:** Copies the highlighted source words into the target text field.
* **Lookup in Segment context:** Opens the Segment Context sidebar, puts the selected source text into the search field, and searches for the text.
* **Lookup in Concordance:** Opens the Concordance sidebar, puts the selected source text into the search field, and searches for the text.

<Frame>
  <img alt="" />
</Frame>

## Terminology and Contextual AI

LILT Contextual AI is aware of the terminology and will in most cases reproduce the correct target term, sometimes in inflected form to match the grammatical structure of the target language sentence. In some cases it may choose to omit the term, e.g. if the uploaded translation memories contain examples that do not use the term.

## Maximum Character in Terminology Entries

Term base entries of 60 characters or less will be recognized in the CAT editor. Entries over 60 characters will not be recognized in the editor.


# Translating Documents
Source: https://support.lilt.com/kb/translating-documents



[Translate](/kb/introduction-to-lilt-translate) has a range of tools that provide a streamlined workflow for document translators. This article outlines the workflow and tools available to translators using LILT.

Before a translator can access and begin working on a document, a project manager needs to assign the translator to the document. A translator can then [accept the document assignment](/kb/accepting-document-assignments) and begin translating.

## Translating documents

When a translator opens a document, it will load [LILT Verify](/kb/introduction-to-lilt-translate) in Translate mode. The Translate mode interface is the same editor used for [Review](/kb/reviewing-documents), but with a few slight differences, as described in the [Introduction to LILT Verify](/kb/introduction-to-lilt-translate) article.

The role of a translator is to translate all the segments of a document. The various tools and features (as described in the [Introduction to LILT Verify](/kb/introduction-to-lilt-translate) article) all come together to create an efficient translation workflow. The most important tools for translators to know are the [segment editor](/kb/introduction-to-lilt-translate), [quality assurance tools](/kb/quality-assurance-tools), and [hotkeys.](/kb/hotkeys)

After a translator has translated a segment, they click `Confirm` in the bottom-right of the segment to indicate that the segment has been translated. Once confirmed, the segment can be unconfirmed if it needs to be edited. [*Note: Once a segment has been accepted in Review mode, that segment can no longer be edited in Translate mode.*](/kb/reviewing-documents)

<img alt="Screenshot2025 08 26at18 58 58 Pn" />

Translators can add [comments](/kb/segment-comments) to a segment if they have questions or want to add notes.

To learn about who is given authorship for a segment's translation, see the [Data Source Memory Matching](/kb/translation-memory-matching) article.

## Marking the document as done in Translate mode

When all segments in a document have been confirmed by the translator, a `Mark as done` popup will appear, allowing the translator to mark that the document has been completed in Translate mode.

<Frame>
  <img alt="" />
</Frame>

Mark as done popup

If a manager [requires Quality Assurance Tools checks for translators](/kb/mandatory-batch-qa-check), the translator will need to run Quality Assurance Tools (which runs a QA check on all the document's segments) before the document can be marked as done.

Documents can also be marked as done from the `File` tab.

<Frame>
  <img alt="" />
</Frame>

Mark as done from File tab


# Access To MongoDB
Source: https://support.lilt.com/self-managed/v6.1/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. <Frame>
     <img />
   </Frame>

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 <mongo-pod-name> -- /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. <Frame>
        <img />
      </Frame>

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 <NODE_IP_ADDRESS> --port <MONGODB_SERVICE_NODEPORT> --authenticationDatabase admin -u root -p --tls --tlsCertificateKeyFile <path-to-mongodb-pem> --tlsCAFile <path-to-ca-file> --tlsAllowInvalidHostnames
```

This should set up connectivity and allow for interaction with the MongoDB as shown from within the cluster above.


# AWS Access Requirements
Source: https://support.lilt.com/self-managed/v6.1/aws-required-permissions

Executive summary of the AWS IAM permissions and roles to grant LILT before a managed Amazon EKS deployment — written for review by your cloud security team.

## Executive summary

To run LILT in your own AWS account, LILT's deployment automation provisions a
standard set of AWS resources — a **managed Amazon EKS cluster with EKS-managed
node groups**, an S3 bucket, an RDS MySQL database, an optional SQS queue, the
supporting network, and the encryption keys that protect them — and then runs
the LILT platform on that cluster. AWS manages the Kubernetes control plane and
the worker-node instance lifecycle; this is not a self-managed cluster running
on hand-operated virtual machines.

This document is the **access request**: it lists exactly what your security
team needs to grant, why each item is needed, how it is scoped, and how long it
is required. There are two grants:

<CardGroup>
  <Card title="1 · Deployment role" icon="key">
    One IAM role, used **only while creating or updating infrastructure**. Grant
    it the [deployment permissions](#grant-1-deployment-role) below. It can be
    disabled or removed between deployments — it is not needed for day-to-day
    operation.
  </Card>

  <Card title="2 · Runtime roles" icon="gears">
    A set of narrowly-scoped roles the deployment **creates for you** and that
    the cluster's workloads assume at runtime. Your team's role here is to
    **review and approve** them — see [runtime roles](#grant-2-runtime-roles).
  </Card>
</CardGroup>

### What you are granting, at a glance

| Grant | Purpose | Scope | Lifetime |
| - | - | - | - |
| **Deployment role** | Create/update/delete the EKS cluster, S3, SQS, RDS, networking, IAM roles, and KMS keys for LILT | AWS account (services listed below); tightenable to a naming prefix | Only during install/upgrade — can be removed afterward |
| **Runtime — EKS service roles** | Let the control plane and worker nodes operate (standard AWS-managed policies) | The LILT cluster | Life of the cluster |
| **Runtime — application & add-on roles** | Let LILT pods use their own S3 bucket, SQS queue, KMS key, and DNS zone | The specific bucket / queue / key / hosted zone LILT owns | Life of the cluster |

### Security posture

What your team can rely on when granting this:

* **Least privilege.** Every policy lists only the actions the component needs.
  Runtime roles are additionally scoped to the specific resource LILT owns (its
  bucket, queue, key, or DNS zone) — they cannot touch anything else in the
  account.
* **No long-lived keys.** Access is brokered by short-lived, federated
  credentials (EKS Pod Identity for workloads; your choice of federation for the
  deployment role). LILT does not require static IAM access keys.
* **Time-boxed deployment access.** The broad create/delete permissions live on
  the deployment role, which is only needed during install or upgrade and can be
  detached the rest of the time.
* **Encryption by default.** S3 and RDS are encrypted with dedicated KMS keys;
  the RDS database is private (no public endpoint) and reachable only from within
  the VPC. The DB master password is managed by AWS Secrets Manager
  (`manage_master_user_password`) — no password is stored in Terraform state.
  Application workloads retrieve it via the External Secrets Operator
  or directly from Secrets Manager.
* **Auditable.** The runtime policies are fixed and enumerated in this document,
  so a granted deployment produces a known, reviewable set of standing roles.

<Note>
  **Placeholders.** The policies below use <code>\<ACCOUNT\_ID></code>, <code>\<REGION></code>,
  <code>\<CLUSTER\_NAME></code>, <code>\<PREFIX></code> (an environment name prefix, e.g. `prod`), and the
  <code>\<\*\_ARN></code> / <code>\<HOSTED\_ZONE\_ID></code> values — substitute the ones for your environment.
  This request assumes a single-region deployment; multi-region follows the same
  model per region.
</Note>

***

## Grant 1 · Deployment role

Create one IAM role for LILT's deployment identity and attach the permissions
below. This is the complete set of `create`, `describe`, `modify`, `tag`, and
`delete` actions required to stand up **and later tear down** the resources LILT
manages. It is needed only while provisioning; you may detach it between changes.

**Why each service is needed:**

| Service | What it is used for |
| - | - |
| **EKS** | Create and manage the Kubernetes cluster, node groups, add-ons, and admin access entries |
| **EC2 / VPC** | Create the private subnets, NAT, route tables, security groups, and node launch templates the cluster runs in |
| **S3** | Create the object-storage bucket (application assets and the container registry backend) |
| **SQS** | Create the queue used for S3 event notifications; the app workload role has send/receive/delete access at runtime |
| **RDS** | Create and configure the MySQL 8.0 database (private endpoint, KMS-encrypted, AWS-managed master password stored in Secrets Manager) |
| **KMS** | Create the encryption keys that protect S3 and RDS |
| **IAM** | Create the runtime roles in Grant 2 and their Pod Identity associations |
| **Route 53** | Create the DNS zone and records for the application endpoints |
| **Secrets Manager, CloudWatch Logs, EventBridge, SSM** | Store the DB master secret, cluster log groups, and node-lifecycle event rules |

<Tip>
  The statements are split into four documents purely to stay under the AWS
  6,144-character managed-policy size limit — attach all four to the same role.
</Tip>

<AccordionGroup>
  <Accordion title="Policy 1 — STS, ECR, Secrets Manager, S3">
    ```json theme={null}
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "STSAuth",
          "Effect": "Allow",
          "Action": "sts:GetCallerIdentity",
          "Resource": "*"
        },
        {
          "Sid": "ECRManagement",
          "Effect": "Allow",
          "Action": [
            "ecr:CreateRepository", "ecr:DeleteRepository", "ecr:DescribeRepositories",
            "ecr:GetRepositoryPolicy", "ecr:SetRepositoryPolicy", "ecr:DeleteRepositoryPolicy",
            "ecr:TagResource", "ecr:UntagResource", "ecr:ListTagsForResource",
            "ecr:CreateLifecyclePolicy", "ecr:DeleteLifecyclePolicy", "ecr:GetLifecyclePolicy",
            "ecr:PutLifecyclePolicy", "ecr:GetAuthorizationToken"
          ],
          "Resource": "*"
        },
        {
          "Sid": "SecretsManager",
          "Effect": "Allow",
          "Action": [
            "secretsmanager:CreateSecret", "secretsmanager:DeleteSecret", "secretsmanager:UpdateSecret",
            "secretsmanager:PutSecretValue", "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret",
            "secretsmanager:TagResource", "secretsmanager:UntagResource",
            "secretsmanager:ListSecretVersionIds", "secretsmanager:RestoreSecret"
          ],
          "Resource": "arn:aws:secretsmanager:*:<ACCOUNT_ID>:secret:*"
        },
        {
          "Sid": "S3",
          "Effect": "Allow",
          "Action": [
            "s3:CreateBucket", "s3:DeleteBucket", "s3:ListBucket", "s3:ListAllMyBuckets",
            "s3:GetBucketLocation", "s3:GetBucketAcl", "s3:PutBucketAcl",
            "s3:GetBucketCORS", "s3:PutBucketCORS", "s3:GetBucketLogging", "s3:PutBucketLogging",
            "s3:GetBucketNotification", "s3:PutBucketNotification",
            "s3:GetBucketPolicy", "s3:PutBucketPolicy", "s3:DeleteBucketPolicy",
            "s3:GetBucketPublicAccessBlock", "s3:PutBucketPublicAccessBlock",
            "s3:GetBucketTagging", "s3:PutBucketTagging",
            "s3:GetBucketVersioning", "s3:PutBucketVersioning",
            "s3:GetEncryptionConfiguration", "s3:PutEncryptionConfiguration",
            "s3:GetLifecycleConfiguration", "s3:PutLifecycleConfiguration",
            "s3:GetReplicationConfiguration", "s3:PutReplicationConfiguration",
            "s3:GetBucketObjectLockConfiguration", "s3:PutBucketObjectLockConfiguration",
            "s3:GetBucketRequestPayment", "s3:PutBucketRequestPayment",
            "s3:GetIntelligentTieringConfiguration", "s3:PutIntelligentTieringConfiguration"
          ],
          "Resource": "*"
        }
      ]
    }
    ```
  </Accordion>

  <Accordion title="Policy 2 — SQS, RDS, EKS">
    ```json theme={null}
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "SQS",
          "Effect": "Allow",
          "Action": [
            "sqs:CreateQueue", "sqs:DeleteQueue", "sqs:GetQueueAttributes", "sqs:SetQueueAttributes",
            "sqs:GetQueueUrl", "sqs:ListQueues", "sqs:TagQueue", "sqs:UntagQueue", "sqs:ListQueueTags"
          ],
          "Resource": "*"
        },
        {
          "Sid": "RDS",
          "Effect": "Allow",
          "Action": [
            "rds:CreateDBCluster", "rds:DeleteDBCluster", "rds:DescribeDBClusters", "rds:ModifyDBCluster",
            "rds:CreateDBInstance", "rds:DeleteDBInstance", "rds:DescribeDBInstances", "rds:ModifyDBInstance",
            "rds:RebootDBInstance",
            "rds:CreateDBSubnetGroup", "rds:DeleteDBSubnetGroup", "rds:DescribeDBSubnetGroups", "rds:ModifyDBSubnetGroup",
            "rds:CreateDBParameterGroup", "rds:DeleteDBParameterGroup", "rds:DescribeDBParameterGroups", "rds:ModifyDBParameterGroup",
            "rds:CreateDBClusterParameterGroup", "rds:DeleteDBClusterParameterGroup", "rds:DescribeDBClusterParameterGroups", "rds:ModifyDBClusterParameterGroup",
            "rds:ListTagsForResource", "rds:AddTagsToResource", "rds:RemoveTagsFromResource",
            "rds:DescribeDBEngineVersions", "rds:DescribeOrderableDBInstanceOptions",
            "rds:CreateDBSnapshot", "rds:DeleteDBSnapshot", "rds:DescribeDBSnapshots",
            "rds:CreateDBClusterSnapshot", "rds:DeleteDBClusterSnapshot", "rds:DescribeDBClusterSnapshots",
            "rds:DescribeCertificates"
          ],
          "Resource": "*"
        },
        {
          "Sid": "EKS",
          "Effect": "Allow",
          "Action": [
            "eks:CreateCluster", "eks:DeleteCluster", "eks:DescribeCluster", "eks:ListClusters",
            "eks:UpdateClusterConfig", "eks:UpdateClusterVersion",
            "eks:CreateNodegroup", "eks:DeleteNodegroup", "eks:DescribeNodegroup", "eks:ListNodegroups",
            "eks:UpdateNodegroupConfig", "eks:UpdateNodegroupVersion",
            "eks:CreateAddon", "eks:DeleteAddon", "eks:DescribeAddon", "eks:UpdateAddon",
            "eks:ListAddons", "eks:DescribeAddonVersions",
            "eks:CreateAccessEntry", "eks:DeleteAccessEntry", "eks:DescribeAccessEntry",
            "eks:AssociateAccessPolicy", "eks:DisassociateAccessPolicy",
            "eks:ListAccessEntries", "eks:ListAccessPolicies", "eks:ListAssociatedAccessPolicies",
            "eks:TagResource", "eks:UntagResource"
          ],
          "Resource": "*"
        }
      ]
    }
    ```
  </Accordion>

  <Accordion title="Policy 3 — EC2 / VPC, IAM, KMS">
    ```json theme={null}
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "EC2ForEKSAndRDS",
          "Effect": "Allow",
          "Action": [
            "ec2:CreateVpc", "ec2:DeleteVpc", "ec2:DescribeVpcs", "ec2:ModifyVpcAttribute",
            "ec2:CreateSubnet", "ec2:DeleteSubnet", "ec2:DescribeSubnets", "ec2:ModifySubnetAttribute",
            "ec2:CreateInternetGateway", "ec2:DeleteInternetGateway", "ec2:DescribeInternetGateways",
            "ec2:AttachInternetGateway", "ec2:DetachInternetGateway",
            "ec2:CreateNatGateway", "ec2:DeleteNatGateway", "ec2:DescribeNatGateways",
            "ec2:AllocateAddress", "ec2:ReleaseAddress", "ec2:DescribeAddresses",
            "ec2:CreateRouteTable", "ec2:DeleteRouteTable", "ec2:DescribeRouteTables",
            "ec2:CreateRoute", "ec2:DeleteRoute", "ec2:AssociateRouteTable", "ec2:DisassociateRouteTable",
            "ec2:CreateSecurityGroup", "ec2:DeleteSecurityGroup", "ec2:DescribeSecurityGroups",
            "ec2:AuthorizeSecurityGroupIngress", "ec2:RevokeSecurityGroupIngress",
            "ec2:AuthorizeSecurityGroupEgress", "ec2:RevokeSecurityGroupEgress",
            "ec2:CreateLaunchTemplate", "ec2:DeleteLaunchTemplate", "ec2:DescribeLaunchTemplates",
            "ec2:DescribeLaunchTemplateVersions", "ec2:CreateLaunchTemplateVersion", "ec2:DeleteLaunchTemplateVersions",
            "ec2:DescribeAvailabilityZones", "ec2:DescribeKeyPairs", "ec2:DescribeInstances",
            "ec2:DescribeInstanceTypes", "ec2:DescribeImages", "ec2:DescribeNetworkInterfaces",
            "ec2:CreateTags", "ec2:DeleteTags", "ec2:DescribeTags"
          ],
          "Resource": "*"
        },
        {
          "Sid": "IAM",
          "Effect": "Allow",
          "Action": [
            "iam:CreatePolicy", "iam:DeletePolicy", "iam:GetPolicy", "iam:GetPolicyVersion",
            "iam:ListPolicyVersions", "iam:CreatePolicyVersion", "iam:DeletePolicyVersion",
            "iam:TagPolicy", "iam:UntagPolicy", "iam:ListEntitiesForPolicy",
            "iam:CreateRole", "iam:DeleteRole", "iam:GetRole", "iam:UpdateRole",
            "iam:UpdateAssumeRolePolicy", "iam:AttachRolePolicy", "iam:DetachRolePolicy",
            "iam:ListAttachedRolePolicies", "iam:ListRolePolicies", "iam:TagRole", "iam:UntagRole",
            "iam:PassRole",
            "iam:CreateInstanceProfile", "iam:DeleteInstanceProfile", "iam:GetInstanceProfile",
            "iam:AddRoleToInstanceProfile", "iam:RemoveRoleFromInstanceProfile",
            "iam:CreateOpenIDConnectProvider", "iam:DeleteOpenIDConnectProvider", "iam:GetOpenIDConnectProvider",
            "iam:UpdateOpenIDConnectProviderThumbprint", "iam:TagOpenIDConnectProvider",
            "iam:UntagOpenIDConnectProvider", "iam:ListOpenIDConnectProviders"
          ],
          "Resource": "*"
        },
        {
          "Sid": "KMS",
          "Effect": "Allow",
          "Action": [
            "kms:CreateKey", "kms:DescribeKey",
            "kms:GetKeyPolicy", "kms:PutKeyPolicy", "kms:GetKeyRotationStatus",
            "kms:EnableKeyRotation", "kms:DisableKeyRotation",
            "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion",
            "kms:ListKeys", "kms:ListAliases", "kms:CreateAlias", "kms:DeleteAlias", "kms:UpdateAlias",
            "kms:TagResource", "kms:UntagResource",
            "kms:CreateGrant", "kms:ListGrants", "kms:RevokeGrant"
          ],
          "Resource": "*"
        }
      ]
    }
    ```
  </Accordion>

  <Accordion title="Policy 4 — Route 53, extended EC2, CloudWatch Logs, EKS Pod Identity, EventBridge, SSM">
    ```json theme={null}
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "Route53",
          "Effect": "Allow",
          "Action": [
            "route53:CreateHostedZone", "route53:DeleteHostedZone", "route53:GetHostedZone",
            "route53:ListHostedZones", "route53:ListHostedZonesByName",
            "route53:ChangeResourceRecordSets", "route53:ListResourceRecordSets", "route53:GetChange",
            "route53:ChangeTagsForResource", "route53:ListTagsForResource"
          ],
          "Resource": "*"
        },
        {
          "Sid": "EC2Extended",
          "Effect": "Allow",
          "Action": [
            "ec2:RunInstances", "ec2:TerminateInstances", "ec2:StopInstances", "ec2:StartInstances",
            "ec2:CreateNetworkAcl", "ec2:DeleteNetworkAcl", "ec2:CreateNetworkAclEntry",
            "ec2:DeleteNetworkAclEntry", "ec2:ReplaceNetworkAclAssociation", "ec2:DescribeNetworkAcls",
            "ec2:CreateNetworkInterface", "ec2:DeleteNetworkInterface",
            "ec2:DescribeNetworkInterfaceAttribute", "ec2:ModifyNetworkInterfaceAttribute",
            "ec2:DescribeInstanceAttribute", "ec2:DescribeInstanceCreditSpecifications",
            "ec2:ModifyInstanceAttribute", "ec2:DescribeVolumes"
          ],
          "Resource": "*"
        },
        {
          "Sid": "CloudWatchLogs",
          "Effect": "Allow",
          "Action": [
            "logs:CreateLogGroup", "logs:DeleteLogGroup", "logs:DescribeLogGroups",
            "logs:PutRetentionPolicy", "logs:DeleteRetentionPolicy",
            "logs:TagResource", "logs:UntagResource", "logs:ListTagsForResource"
          ],
          "Resource": "*"
        },
        {
          "Sid": "EKSPodIdentity",
          "Effect": "Allow",
          "Action": [
            "eks:CreatePodIdentityAssociation", "eks:DeletePodIdentityAssociation",
            "eks:DescribePodIdentityAssociation", "eks:ListPodIdentityAssociations"
          ],
          "Resource": "*"
        },
        {
          "Sid": "EventBridgeRules",
          "Effect": "Allow",
          "Action": [
            "events:PutRule", "events:DeleteRule", "events:DescribeRule",
            "events:EnableRule", "events:DisableRule",
            "events:PutTargets", "events:RemoveTargets", "events:ListTargetsByRule",
            "events:TagResource", "events:UntagResource", "events:ListTagsForResource"
          ],
          "Resource": "arn:aws:events:*:<ACCOUNT_ID>:rule/*"
        },
        {
          "Sid": "SSMReadServiceParams",
          "Effect": "Allow",
          "Action": ["ssm:GetParameter", "ssm:GetParameters"],
          "Resource": "arn:aws:ssm:*::parameter/aws/service/eks/*"
        }
      ]
    }
    ```

    <Note>
      For an EKS **managed node group** cluster like LILT's reference deployment:

      * The `eks:*PodIdentityAssociation` actions (`EKSPodIdentity`) **are
        required** — LILT binds every workload to its IAM role via EKS Pod
        Identity, so the deployment creates these associations. Do **not** drop
        them.
      * `EventBridgeRules` and the EKS-service `ssm:GetParameter` read are only
        needed for node auto-provisioning (Karpenter); they can be dropped here.
      * The instance-lifecycle actions in `EC2Extended` — `ec2:RunInstances`,
        `ec2:TerminateInstances`, `ec2:StopInstances`, `ec2:StartInstances` — are
        only needed for **self-managed nodes or Karpenter**. With EKS-managed node
        groups the EKS service manages instance lifecycle, so the deployment role
        does not use them; the remaining `EC2Extended` network-interface / ACL /
        volume actions are still required.
    </Note>
  </Accordion>
</AccordionGroup>

***

## Grant 2 · Runtime roles

These roles are **created for you** by the deployment (using Grant 1) and are
assumed by the cluster and its workloads at runtime. You do not hand-craft them;
they are enumerated here so your team can review the standing access that will
exist in the account after install.

### EKS service roles (AWS-managed policies)

The cluster and its worker nodes use roles built entirely from **AWS's own
managed policies** — AWS's least-privilege definitions for these service roles.
No custom permissions are involved.

| Role | Assumed by | AWS-managed policies attached |
| - | - | - |
| **Cluster role** | the EKS control plane | `AmazonEKSClusterPolicy`, `AmazonEKSVPCResourceController` |
| **Node role** | worker EC2 instances | `AmazonEKSWorkerNodePolicy`, `AmazonEKS_CNI_Policy`, `AmazonEC2ContainerRegistryReadOnly`, `AmazonEKSVPCResourceController`, `CloudWatchAgentServerPolicy` |
| **Node role (auto-provisioning)** | as above | additionally `AmazonSSMManagedInstanceCore` |
| **EBS CSI driver** | the storage driver (EKS Pod Identity) | `service-role/AmazonEBSCSIDriverPolicy` |

<Note>
  LILT's reference cluster also attaches the legacy `AmazonEKSServicePolicy` to the
  cluster role. On EKS 1.24+ its permissions are folded into
  `AmazonEKSClusterPolicy`, so it is **optional** on new clusters.
</Note>

<Note>
  LILT runs on **EKS-managed node groups**: the worker and GPU nodes are EC2
  instances whose lifecycle Amazon EKS manages for you (creation, replacement,
  and scaling via the node group's `min`/`max`/`desired` config). There are no
  self-managed EC2 instances or Auto Scaling groups to operate. As a result the
  **Cluster Autoscaler** and **Karpenter** roles below, and the "auto-provisioning"
  node-role variant above (`AmazonSSMManagedInstanceCore`), are **not enabled by
  default** — Karpenter is a future release; they are documented here for
  deployments that opt into node auto-provisioning.
</Note>

### Application & add-on roles (custom, least-privilege)

Each of these is a role with a small inline policy, scoped to the specific
resource LILT owns and assumed by one named Kubernetes workload via short-lived
federated credentials (EKS IRSA or Pod Identity). None of them can access
resources outside the ones LILT created.

<AccordionGroup>
  <Accordion title="LILT application — its own S3 bucket, SQS queue, KMS key" icon="star">
    The core LILT platform. Reads/writes objects in the LILT bucket, uses that
    bucket's KMS key, and consumes/produces on the LILT SQS queue — nothing else.

    ```json theme={null}
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "AllowS3Access",
          "Effect": "Allow",
          "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:ListBucket", "s3:GetBucketLocation"],
          "Resource": ["<S3_BUCKET_ARN>", "<S3_BUCKET_ARN>/*"]
        },
        {
          "Sid": "AllowKMSForS3",
          "Effect": "Allow",
          "Action": ["kms:Decrypt", "kms:Encrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey"],
          "Resource": "<S3_KMS_KEY_ARN>"
        },
        {
          "Sid": "AllowSQSAccess",
          "Effect": "Allow",
          "Action": ["sqs:SendMessage", "sqs:ReceiveMessage", "sqs:DeleteMessage", "sqs:GetQueueAttributes", "sqs:GetQueueUrl"],
          "Resource": "<SQS_QUEUE_ARN>"
        }
      ]
    }
    ```

    <Note>
      The SQS queue is always provisioned by the module. The `AllowSQSAccess`
      statement shown above is always present in the app workload role — it is not
      optional. The queue ARN is surfaced as the `queue_arn` output.
    </Note>
  </Accordion>

  <Accordion title="ExternalDNS — the LILT DNS zone only">
    Keeps DNS records in sync for the application endpoints, scoped to LILT's
    hosted zone.

    ```json theme={null}
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "AllowChangeRecords",
          "Effect": "Allow",
          "Action": ["route53:ChangeResourceRecordSets"],
          "Resource": "arn:aws:route53:::hostedzone/<HOSTED_ZONE_ID>"
        },
        {
          "Sid": "AllowListZones",
          "Effect": "Allow",
          "Action": ["route53:ListHostedZones", "route53:ListResourceRecordSets", "route53:ListTagsForResource"],
          "Resource": "*"
        }
      ]
    }
    ```
  </Accordion>

  <Accordion title="cert-manager — TLS certificate issuance (DNS-01)">
    Proves domain control for automated TLS certificates, scoped to LILT's
    hosted zone.

    ```json theme={null}
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "AllowGetChange",
          "Effect": "Allow",
          "Action": ["route53:GetChange"],
          "Resource": "arn:aws:route53:::change/*"
        },
        {
          "Sid": "AllowDNS01Challenge",
          "Effect": "Allow",
          "Action": ["route53:ChangeResourceRecordSets", "route53:ListResourceRecordSets"],
          "Resource": "arn:aws:route53:::hostedzone/<HOSTED_ZONE_ID>"
        },
        {
          "Sid": "AllowListZones",
          "Effect": "Allow",
          "Action": ["route53:ListHostedZonesByName"],
          "Resource": "*"
        }
      ]
    }
    ```
  </Accordion>

  <Accordion title="Cluster Autoscaler — scaling the LILT cluster's node groups">
    Only present if the cluster scales via managed node groups. Scaling actions
    are gated on the cluster-ownership tag.

    ```json theme={null}
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "AllowDescribe",
          "Effect": "Allow",
          "Action": [
            "autoscaling:DescribeAutoScalingGroups", "autoscaling:DescribeAutoScalingInstances",
            "autoscaling:DescribeLaunchConfigurations", "autoscaling:DescribeScalingActivities",
            "autoscaling:DescribeTags",
            "ec2:DescribeImages", "ec2:DescribeInstanceTypes", "ec2:DescribeLaunchTemplateVersions",
            "ec2:GetInstanceTypesFromInstanceRequirements", "eks:DescribeNodegroup"
          ],
          "Resource": "*"
        },
        {
          "Sid": "AllowScale",
          "Effect": "Allow",
          "Action": ["autoscaling:SetDesiredCapacity", "autoscaling:TerminateInstanceInAutoScalingGroup"],
          "Resource": "*",
          "Condition": { "StringEquals": { "aws:ResourceTag/kubernetes.io/cluster/<CLUSTER_NAME>": "owned" } }
        }
      ]
    }
    ```
  </Accordion>

  <Accordion title="Node auto-provisioning (Karpenter) — cluster-tagged EC2 only — future release, disabled by default">
    Optional — disabled by default; available in a future release. Launches and terminates nodes for the LILT cluster;
    every mutating action is gated on the cluster tag and region. This is the
    upstream Karpenter controller policy.

    ```json theme={null}
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "AllowScopedEC2InstanceAccessActions",
          "Effect": "Allow",
          "Resource": [
            "arn:aws:ec2:<REGION>::image/*", "arn:aws:ec2:<REGION>::snapshot/*",
            "arn:aws:ec2:<REGION>:*:security-group/*", "arn:aws:ec2:<REGION>:*:subnet/*",
            "arn:aws:ec2:<REGION>:*:capacity-reservation/*"
          ],
          "Action": ["ec2:RunInstances", "ec2:CreateFleet"]
        },
        {
          "Sid": "AllowRegionalReadActions",
          "Effect": "Allow",
          "Resource": "*",
          "Action": [
            "ec2:DescribeCapacityReservations", "ec2:DescribeImages", "ec2:DescribeInstances",
            "ec2:DescribeInstanceStatus", "ec2:DescribeInstanceTypeOfferings", "ec2:DescribeInstanceTypes",
            "ec2:DescribeLaunchTemplates", "ec2:DescribePlacementGroups", "ec2:DescribeSecurityGroups",
            "ec2:DescribeSpotPriceHistory", "ec2:DescribeSubnets"
          ],
          "Condition": { "StringEquals": { "aws:RequestedRegion": "<REGION>" } }
        },
        {
          "Sid": "AllowSSMReadActions",
          "Effect": "Allow",
          "Resource": "arn:aws:ssm:<REGION>::parameter/aws/service/*",
          "Action": "ssm:GetParameter"
        },
        {
          "Sid": "AllowPricingReadActions",
          "Effect": "Allow",
          "Resource": "*",
          "Action": "pricing:GetProducts"
        },
        {
          "Sid": "AllowInterruptionQueueActions",
          "Effect": "Allow",
          "Resource": "<KARPENTER_SQS_QUEUE_ARN>",
          "Action": ["sqs:DeleteMessage", "sqs:GetQueueUrl", "sqs:ReceiveMessage"]
        },
        {
          "Sid": "AllowPassingInstanceRole",
          "Effect": "Allow",
          "Resource": "<NODE_ROLE_ARN>",
          "Action": "iam:PassRole",
          "Condition": { "StringEquals": { "iam:PassedToService": ["ec2.amazonaws.com"] } }
        },
        {
          "Sid": "AllowAPIServerEndpointDiscovery",
          "Effect": "Allow",
          "Resource": "arn:aws:eks:<REGION>:<ACCOUNT_ID>:cluster/<CLUSTER_NAME>",
          "Action": "eks:DescribeCluster"
        }
      ]
    }
    ```

    <Note>
      Abbreviated to the core statements. The full policy additionally scopes
      `ec2:CreateFleet` / `RunInstances` / `CreateLaunchTemplate` / `CreateTags` /
      `TerminateInstances` and the `iam:*InstanceProfile` actions by the
      <code>kubernetes.io/cluster/\<CLUSTER\_NAME>: owned</code> and `karpenter.sh/nodepool`
      tags — use the current published
      [Karpenter controller policy](https://karpenter.sh/docs/reference/cloudformation/)
      for your Karpenter version.
    </Note>
  </Accordion>

  <Accordion title="AWS Load Balancer Controller — load balancers it creates">
    Provisions the ALB/NLB load balancers for the application's public
    endpoints. Management actions are gated on the controller's ownership tag.

    ```json theme={null}
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "AllowCreateServiceLinkedRole",
          "Effect": "Allow",
          "Action": ["iam:CreateServiceLinkedRole"],
          "Resource": "*",
          "Condition": { "StringEquals": { "iam:AWSServiceName": "elasticloadbalancing.amazonaws.com" } }
        },
        {
          "Sid": "AllowDescribe",
          "Effect": "Allow",
          "Action": [
            "ec2:DescribeAccountAttributes", "ec2:DescribeAddresses", "ec2:DescribeAvailabilityZones",
            "ec2:DescribeInternetGateways", "ec2:DescribeVpcs", "ec2:DescribeVpcPeeringConnections",
            "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups", "ec2:DescribeInstances",
            "ec2:DescribeNetworkInterfaces", "ec2:DescribeTags", "ec2:GetCoipPoolUsage",
            "ec2:DescribeCoipPools", "ec2:GetSecurityGroupsForVpc", "ec2:DescribeIpamPools",
            "elasticloadbalancing:Describe*"
          ],
          "Resource": "*"
        },
        {
          "Sid": "AllowManageOwnedResources",
          "Effect": "Allow",
          "Action": [
            "elasticloadbalancing:CreateLoadBalancer", "elasticloadbalancing:CreateTargetGroup",
            "elasticloadbalancing:CreateListener", "elasticloadbalancing:DeleteListener",
            "elasticloadbalancing:CreateRule", "elasticloadbalancing:DeleteRule",
            "elasticloadbalancing:ModifyLoadBalancerAttributes", "elasticloadbalancing:SetSubnets",
            "elasticloadbalancing:SetSecurityGroups", "elasticloadbalancing:DeleteLoadBalancer",
            "elasticloadbalancing:ModifyTargetGroup", "elasticloadbalancing:ModifyTargetGroupAttributes",
            "elasticloadbalancing:DeleteTargetGroup", "elasticloadbalancing:RegisterTargets",
            "elasticloadbalancing:DeregisterTargets", "elasticloadbalancing:ModifyListener",
            "elasticloadbalancing:AddTags", "elasticloadbalancing:RemoveTags",
            "ec2:CreateSecurityGroup", "ec2:AuthorizeSecurityGroupIngress",
            "ec2:RevokeSecurityGroupIngress", "ec2:CreateTags", "ec2:DeleteTags"
          ],
          "Resource": "*",
          "Condition": { "Null": { "aws:ResourceTag/elbv2.k8s.aws/cluster": "false" } }
        }
      ]
    }
    ```

    <Note>
      Condensed for readability. Deploy the exact, tag-condition-complete policy
      from the
      [AWS Load Balancer Controller install guide](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/installation/)
      matching your controller version.
    </Note>
  </Accordion>

  <Accordion title="External Secrets Operator (optional) — read LILT-managed secrets">
    Optional — when the External Secrets Operator is enabled, this role
    allows it to pull any secret whose name begins with
    the environment prefix — scoped to `<PREFIX>/*` in Secrets Manager. It cannot
    read secrets outside that prefix. Assumed by the `external-secrets-sa` service
    account in the `external-secrets` namespace via EKS Pod Identity.

    ```json theme={null}
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "AllowReadLiltManagedSecrets",
          "Effect": "Allow",
          "Action": [
            "secretsmanager:GetSecretValue",
            "secretsmanager:DescribeSecret"
          ],
          "Resource": "arn:aws:secretsmanager:<REGION>:<ACCOUNT_ID>:secret:<PREFIX>/*"
        }
      ]
    }
    ```
  </Accordion>

  <Accordion title="Harbor container registry (optional, future release) — S3 backend access">
    Optional — disabled by default. Harbor requires
    access to the S3 bucket that backs its image registry and the KMS key used to
    encrypt that bucket. The module provisions Pod Identity associations for three
    Harbor service accounts (`harbor-core`, `harbor-registry`, `harbor-jobservice`)
    in the `harbor` namespace — all three assume the same role.

    <Note>
      Harbor support is included in the module for organizations that run a
      self-hosted registry. For most deployments, **ECR is
      the recommended path** — no additional infrastructure is needed and images
      are pulled directly by node groups that already hold `AmazonEC2ContainerRegistryReadOnly`.
    </Note>

    ```json theme={null}
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "s3:PutObject", "s3:GetObject", "s3:DeleteObject",
            "s3:ListBucket", "s3:GetBucketLocation"
          ],
          "Resource": [
            "<S3_BUCKET_ARN>",
            "<S3_BUCKET_ARN>/harbor/*"
          ]
        },
        {
          "Effect": "Allow",
          "Action": ["kms:GenerateDataKey", "kms:Decrypt"],
          "Resource": "<S3_KMS_KEY_ARN>"
        }
      ]
    }
    ```
  </Accordion>

  <Accordion title="ECR private registry (optional) — push/pull access for app workloads">
    Optional — disabled by default. Creates a private
    ECR repository and grants the `app_workload` role push and pull permissions
    scoped to that repository. Node groups always receive
    `AmazonEC2ContainerRegistryReadOnly` (pull-only) regardless of this toggle.

    ```json theme={null}
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": ["ecr:GetAuthorizationToken"],
          "Resource": "*"
        },
        {
          "Effect": "Allow",
          "Action": [
            "ecr:BatchCheckLayerAvailability", "ecr:GetDownloadUrlForLayer",
            "ecr:BatchGetImage", "ecr:InitiateLayerUpload", "ecr:UploadLayerPart",
            "ecr:CompleteLayerUpload", "ecr:PutImage",
            "ecr:DescribeImages", "ecr:ListImages"
          ],
          "Resource": "<ECR_REPOSITORY_ARN>"
        }
      ]
    }
    ```
  </Accordion>

  <Accordion title="Bastion host (optional) — describe the cluster + Session Manager">
    Optional — present when the bastion is enabled. An EC2 instance
    role that lets operators run `aws eks describe-cluster` /
    `update-kubeconfig` against this one cluster and reach the private bastion
    over AWS Systems Manager Session Manager (no public IP or open SSH port
    required). It attaches the AWS-managed `AmazonSSMManagedInstanceCore` policy
    plus the inline statement below.

    ```json theme={null}
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": ["eks:DescribeCluster"],
          "Resource": "arn:aws:eks:<REGION>:<ACCOUNT_ID>:cluster/<CLUSTER_NAME>"
        }
      ]
    }
    ```
  </Accordion>
</AccordionGroup>

***

## Cluster service account & Pod Identity wiring

The runtime roles above are not attached to pods directly. Each is bound to a
named **Kubernetes service account (SA)**, and an **EKS Pod Identity
association** maps that SA to the IAM role. This section describes how LILT's
terraform sets that up so your team can see exactly which in-cluster identity
receives which AWS permissions.

### The LILT application service accounts

LILT's application runs under one or more service accounts in the `lilt`
namespace. The module variable `app_workload_service_accounts` (default:
`["app-workload-sa"]`) controls which service accounts receive Pod Identity
associations to the app workload IAM role. Each named SA gets its own
`aws_eks_pod_identity_association`. The service accounts themselves are created
by your cluster's application deployment (e.g. Helm chart), **not** by this
Terraform module — the Pod Identity association is the AWS-side binding only.

```hcl theme={null}
# Each SA in app_workload_service_accounts gets its own association
resource "aws_eks_pod_identity_association" "app_workload" {
  for_each = toset(var.app_workload_service_accounts)

  cluster_name    = aws_eks_cluster.main.name
  namespace       = "lilt"
  service_account = each.value
  role_arn        = aws_iam_role.app_workload.arn
}
```

### How the pieces fit together

Three objects have to agree for a pod to receive AWS permissions:

1. **The Kubernetes service account** — the identity the pod runs as
   (`namespace` + `name`).
2. **The IAM role** — carries the least-privilege policy (e.g. the S3 + KMS
   permissions) and has a **trust policy that allows `pods.eks.amazonaws.com` to
   assume it** (`sts:AssumeRole` + `sts:TagSession`). This is what makes it a
   Pod Identity role (`sts:AssumeRole` + `sts:TagSession` from `pods.eks.amazonaws.com`). Under IRSA (`iam_auth_method = "irsa"`), the trust policy uses `sts:AssumeRoleWithWebIdentity` with a service-account-scoped condition against the cluster OIDC provider instead.
3. **The Pod Identity association** (Pod Identity mode only) — the AWS-side record that says "SA *namespace/name* on *this cluster* may assume *this role*." Under IRSA, the Kubernetes SA carries an `eks.amazonaws.com/role-arn` annotation in place of this association.

At runtime the **EKS Pod Identity Agent** (installed as a cluster add-on) sees a
pod running under that service account, matches it to the association, and hands
the pod **short-lived, automatically-rotated credentials** for the mapped role.
No static keys are involved in either mode.

<Warning>
  Because the association is keyed on `namespace` + `service account name`, those
  must match on both sides. If the SA is renamed, moved to another namespace, or
  recreated in a different namespace without updating the association, the pod
  loses its AWS access. Some add-on service accounts additionally have **fixed
  names** required by their controllers — e.g. the EBS CSI driver expects
  `ebs-csi-controller-sa` and the External Secrets Operator expects
  `external-secrets-sa` — and cannot be renamed.
</Warning>

### Service-account-to-role map

| Kubernetes service account | Namespace | Bound IAM role (Grant 2) | Grants |
| - | - | - | - |
| `app-workload-sa` (configurable via `app_workload_service_accounts`) | `lilt` | App workload role | S3 bucket + KMS key + SQS queue (module-owned resources only) |
| `aws-load-balancer-controller-sa` | `kube-system` | AWS Load Balancer Controller role | Manage the cluster's ALBs/NLBs |
| `cluster-autoscaler-sa` | `kube-system` | Cluster Autoscaler role | ASG describe + scale (cluster-scoped tag) |
| `external-dns-sa` | `kube-system` | ExternalDNS role | Route 53 zone change + list (optional) |
| `cert-manager-sa` | `cert-manager` | cert-manager role | Route 53 DNS-01 challenge (optional) |
| `ebs-csi-controller-sa` | `kube-system` | EBS CSI driver role | `AmazonEBSCSIDriverPolicy` |
| `external-secrets-sa` | `external-secrets` | External Secrets role | Read `<PREFIX>/*` Secrets Manager secrets (optional) |
| `karpenter` | `kube-system` | Karpenter controller role | EC2 fleet + SQS interruption queue (optional, future release) |
| `harbor-core`, `harbor-registry`, `harbor-jobservice` | `harbor` | Harbor role | S3 bucket + KMS key (optional, future release) |

<Note>
  The LILT cluster service account also carries in-cluster **RBAC** (Kubernetes
  `Role`/`RoleBinding`s for the application and Argo Workflows components). That
  RBAC governs access to the Kubernetes API *inside* the cluster and is entirely
  separate from the AWS IAM permissions granted through the Pod Identity
  association described here — the same SA simply serves both roles.
</Note>

***

## How access is brokered

No component uses a long-lived IAM access key. Each principal obtains
short-lived credentials via a federated trust:

| Principal | Mechanism | How it is trusted |
| - | - | - |
| App workload, ExternalDNS, cert-manager, Cluster Autoscaler, LB controller, ESO, Harbor (optional), Karpenter (optional) | **EKS Pod Identity** (default) or **IRSA** | Pod Identity: each SA bound via `aws_eks_pod_identity_association`, no OIDC provider. IRSA: OIDC provider provisioned, each role uses `sts:AssumeRoleWithWebIdentity`. Controlled by `iam_auth_method`. |
| External Secrets Operator (if used) | **EKS Pod Identity** | The `external-secrets-sa` service account in the `external-secrets` namespace |
| EBS CSI storage driver | **EKS Pod Identity** | The EKS Pod Identity service on your cluster |
| Worker nodes | **EC2 instance profile** | The node role, assumed by EC2 |
| Bastion host (if enabled) | **EC2 instance profile** | The bastion role, assumed by EC2 |
| Control plane | **EKS service role** | Assumed by the EKS service |
| **Deployment role (Grant 1)** | **Your choice** | You decide who may assume it — a federated CI identity or a named administrator, per your own access standards |

<Note>
  LILT's reference Terraform module supports two IAM authentication modes, selected via `iam_auth_method`:

  * **`pod_identity`** (default, recommended) — all workload roles use EKS Pod Identity. No OIDC provider is provisioned. Every role trusts `pods.eks.amazonaws.com` via `sts:AssumeRole` + `sts:TagSession`. Pod Identity associations wire each Kubernetes service account to its role on the AWS side.
  * **`irsa`** (backward compat) — an OIDC identity provider is provisioned for the cluster, and each role uses `sts:AssumeRoleWithWebIdentity` with a service-account-scoped condition. Use this for environments already running IRSA that are not yet ready to migrate.
</Note>

<Warning>
  The deployment role's **trust policy is yours to define** — this document does
  not prescribe who may assume it. Grant the Grant 1 permissions to whichever
  identity your team authorizes to run the deployment, following your federation
  and access-control standards.
</Warning>

***

## Helm chart sourcing for constrained environments

By default, LILT's deployment pulls community Helm charts from their upstream
HTTPS repositories (Artifact Hub, `kubernetes-sigs`, `aws.github.io`, etc.).
In environments with restricted egress, two variables let you redirect chart
sources without changing any other module configuration.

### Option A — OCI registry mirror (recommended)

Mirror all charts to a private OCI registry (e.g. Amazon ECR) and point the
module at the base URL. All add-ons pull from that registry; no public internet
access is required. The ECR VPC endpoint is included when VPC endpoints are enabled.

```hcl theme={null}
# Mirror charts first:
#   helm pull cluster-autoscaler --repo https://kubernetes.github.io/autoscaler --version 9.46.0
#   helm push cluster-autoscaler-9.46.0.tgz oci://123456789.dkr.ecr.us-east-1.amazonaws.com/helm-charts

helm_chart_registry = "oci://123456789.dkr.ecr.us-east-1.amazonaws.com/helm-charts"
```

### Option B — per-chart OCI override

Override individual charts while leaving others at their defaults (or at the
`helm_chart_registry` base). Useful when only a subset of charts has been
mirrored.

```hcl theme={null}
helm_chart_sources = {
  "cert-manager" = {
    repository = "oci://123456789.dkr.ecr.us-east-1.amazonaws.com/helm-charts"
    chart      = "cert-manager"
  }
}
```

Valid keys: `cluster-autoscaler`, `metrics-server`, `prometheus-node-exporter`,
`external-dns`, `cert-manager`, `kube-state-metrics`, `datadog-operator`,
`aws-load-balancer-controller`, `external-secrets`.

### Option C — break-the-glass (local `.tgz`, no network)

For fully isolated environments where even ECR is unreachable. Pre-fetch chart
tarballs onto the machine running `terraform apply`, then reference them by
absolute path. Setting `repository = null` tells the Helm provider to skip all
registry lookups.

```hcl theme={null}
helm_chart_sources = {
  "cluster-autoscaler" = { repository = null, chart = "/mnt/charts/cluster-autoscaler-9.46.0.tgz" }
  "cert-manager"       = { repository = null, chart = "/mnt/charts/cert-manager-1.17.2.tgz" }
  # … one entry per enabled chart
}
```

<Warning>
  Local `.tgz` paths must exist on the machine running `terraform apply`. This
  option is not portable across runners unless all paths are pre-populated.
  Options A and B are preferred for reproducible deployments.
</Warning>


# Back Up and Restore Elasticsearch
Source: https://support.lilt.com/self-managed/v6.1/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](/self-managed/v6.1/upgrade-elasticsearch).

<Note>
  Every command on this page assumes the LILT namespace is `lilt`. If you
  installed into a different namespace, substitute it for `NAMESPACE`.
</Note>

## 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.

<Warning>
  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.
</Warning>

### 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.

<Warning>
  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.
</Warning>

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`.

<Warning>
  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.
</Warning>

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`.

<Warning>
  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.
</Warning>

### 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": "<nightly-{now/d}>",
  "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.

<Warning>
  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.
</Warning>

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](/self-managed/v6.1/upgrade-elasticsearch)


# Configuring GPU Worker Counts In LILT
Source: https://support.lilt.com/self-managed/v6.1/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
```


# Configuring the Internal OCR Provider
Source: https://support.lilt.com/self-managed/v6.1/configuring-internal-ocr-provider



## Overview

The `internalOcrProvider` flag controls which OCR engine is used when processing image and scanned PDF files. It determines whether OCR is handled by the bundled Tesseract engine or by the neural multimodal OCR service.

The default value is `tesseract`.

## Options

| Value | Engine | Description |
| - | - | - |
| `tesseract` | Tesseract | Traditional OCR using the Tesseract engine bundled in the service container. Requires a local `tessdata` directory. |
| `neural` | Neural Multimodal OCR | Uses the neural multimodal OCR service for higher-accuracy extraction, particularly on complex layouts and non-Latin scripts. Requires the neural OCR service to be deployed. |

## Configuration

### Helm values

Set the flag in your `install_dir/lilt/environments/lilt/values.yaml` file under the file-job service configuration:

```yaml theme={null}
      internalOcrProvider: NEURAL   # or TESSERACT
```

### Behavior by provider

**Tesseract (default)**

* Uses the Tesseract engine bundled in the service container.
* Requires the `tessdata` directory to be present (defaults to `/usr/share/tesseract-ocr/4.00/tessdata/`).
* OCR is performed synchronously during file processing.

**Neural**

* Delegates OCR to the neural multimodal OCR service, which must be deployed separately.
* OCR is performed asynchronously — file processing completes once the neural service returns results.

## When to use each provider

* **Tesseract** is appropriate for environments that do not have the neural OCR service deployed, or where self-contained OCR processing is preferred.
* **Neural** is recommended when higher OCR accuracy is needed — particularly for complex layouts or non-Latin scripts — and when the neural OCR service is deployed in the environment.

<Note>
  The neural OCR service relies on a GPU-accelerated LLM. Ensure your environment has sufficient GPU resources available before enabling the `neural` option. In environments without dedicated GPU capacity, use `tesseract` instead.
</Note>


# Connector Login Credentials
Source: https://support.lilt.com/self-managed/v6.1/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 <name> --password <pass>
```

**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 <NAMESPACE>

# 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:

<Frame>
  <img />
</Frame>


# Create ImagePullSecrets
Source: https://support.lilt.com/self-managed/v6.1/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": "<your-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": "<your-service-account>@<your-project-id>.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>
  NOTE: Google Artifact Registry is REPOSITORY specific, not just region. Secrets are also namespace specific, must create a new secret for each additional namespace.
</Note>

```bash theme={null}
kubectl -n lilt create secret docker-registry <your-secret-name> \
    --docker-server="https:us-docker.pkg.dev/<your-repository>" \
    --docker-username=_json_key \
    --docker-password="$(cat key.json)" \
    --docker-email="<your-service-account>@<your-project-id>.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 <your-secret-name> --namespace=lilt -oyaml | grep -v '^\s*namespace:\s' | kubectl apply --namespace=<other-name-space> -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:
    - <your-secret-name>
```


# Create User/Organization
Source: https://support.lilt.com/self-managed/v6.1/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 <frontPod> -c front -- /bin/bash`

<Note>
  Steps to fetch \<frontpod>:

  * connect to the kubernetes cluster

  * fetch \<frontpod> by running:

    * `kubectl get pods -n lilt | grep -i front`
</Note>

#### 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 <email> --password <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=<email> --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.

<Frame>
  <img />
</Frame>


# Creating Jobs
Source: https://support.lilt.com/self-managed/v6.1/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.

<Frame>
  <img />
</Frame>

### 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>
  \*\*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.
</Note>

\*\*Once finished, click \*\*`Next: Select target languages` to advance to the next screen.

<Frame>
  <img />
</Frame>

### 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.*

<Frame>
  <img />
</Frame>

*Default Project settings can be modified in the [Organization Settings](/kb/organization-settings) area.*

<Note>
  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.
</Note>

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.


# Trusting a Custom CA for S3 Storage
Source: https://support.lilt.com/self-managed/v6.1/custom-ca-for-s3

Configure LILT's neural services to trust a private or corporate CA for S3-compatible object storage using AWS_CA_BUNDLE

## Overview

Some self-managed environments reach their S3-compatible object storage through TLS that is not signed by a public certificate authority — for example:

* An S3-compatible endpoint (MinIO, ECS, StorageGRID, etc.) serving a certificate issued by a private or corporate CA
* A TLS-inspecting egress proxy that re-signs traffic to AWS S3 with a corporate CA

In these environments, LILT's neural services must be told to trust that CA, or S3 requests fail TLS verification. This page covers the supported way to do that: the standard AWS SDK `AWS_CA_BUNDLE` environment variable.

<Note>
  Requires LILT release 6.1 or later. Earlier releases ignore `AWS_CA_BUNDLE` on the neural S3 client.
</Note>

## Why not `SSL_ENABLED`?

The `SSL_ENABLED` switch exists, but it is a **shared** switch: enabling it also forces application-level TLS on the Redis and RabbitMQ connections. On deployments where the service mesh already secures pod-to-pod traffic (Istio ambient mode), that breaks Redis and RabbitMQ connectivity. `AWS_CA_BUNDLE` scopes the custom CA to S3 only and leaves everything else untouched.

## Configuration

Neural services deploy via the shared `lilt-application` chart, so the wiring is a plain environment variable plus a volume mount on each neural service block in `lilt/values.yaml`:

```yaml theme={null}
translatev4:
  env:
    AWS_CA_BUNDLE: /certs/client/ca-bundle.crt
  volumes:
    - name: s3-ca
      secret:
        secretName: neural-s3-ca          # Secret with key ca-bundle.crt
  volumeMounts:
    - name: s3-ca
      mountPath: /certs/client
      readOnly: true
```

Create the Secret from your CA bundle file first:

```bash theme={null}
kubectl create secret generic neural-s3-ca \
  --namespace lilt \
  --from-file=ca-bundle.crt=/path/to/ca-bundle.crt
```

Repeat the `env` / `volumes` / `volumeMounts` block for every neural service that talks to S3 (`translatev4`, `updatev4`, `update-managerv4`, `langid`, `routing`, `batchv4`, `batch-worker-gpuv4`, `batch-worker-cpu-3pmt`, `automqm`, `alignment`, `tag-projection`, `nncache`, and the vLLM/Whisper inference services), then run the installer as usual.

## Requirements and behavior

* **The file must be a complete CA bundle.** A path in `AWS_CA_BUNDLE` *replaces* the AWS SDK's default trust store rather than extending it. Concatenate the public root CAs your endpoint chain needs (for AWS S3, the public AWS roots) together with your private CA into one PEM file.
* **Use a CA certificate, not a client certificate.** Pointing `AWS_CA_BUNDLE` at a client cert such as `tls.crt` produces a trust store that can verify nothing.
* **Plain-HTTP endpoints ignore it.** If your S3 endpoint URL is `http://` (the default in-cluster MinIO wiring), there is no TLS handshake and `AWS_CA_BUNDLE` has no effect. It only matters for `https://` endpoints.
* **Leave it unset on EKS.** EKS deployments reach AWS S3 directly, and those certificates verify against the default trust store. Setting `AWS_CA_BUNDLE` there would only narrow trust.
* **`SSL_ENABLED` takes precedence.** If `SSL_ENABLED=true` with `VERIFY_IDENTITY` is configured, the neural services use `/certs/client/ca.crt` from that configuration and `AWS_CA_BUNDLE` is not consulted.

## Related pages

* [Using S3 instead of MinIO](/self-managed/v6.1/using-s3-instead-of-minio) — switching object storage backends
* [Set Custom Domain And Certificates](/self-managed/v6.1/set-custom-domain-and-certificates) — TLS certificates for LILT's own ingress (a separate concern from S3 egress trust)


# Custom QA
Source: https://support.lilt.com/self-managed/v6.1/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”

<Frame>
  <img alt="" />
</Frame>

## Step 2: Select “Custom QA checks”

<Frame>
  <img alt="" />
</Frame>

## 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.

<Frame>
  <img alt="" />
</Frame>

To delete a config file, click on the dropdown arrow next to the download button and select “Delete”.

<Frame>
  <img alt="" />
</Frame>


# Custom Role For Instant Translate
Source: https://support.lilt.com/self-managed/v6.1/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.

<Frame>
  <img />
</Frame>

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:

<Frame>
  <img />
</Frame>


# Data Cleanup & Building Data Sources
Source: https://support.lilt.com/self-managed/v6.1/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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

On the Data Source view, navigate to the `Manage resources` page. This page displays all documents that have been uploaded to the Data Source.

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

**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.

<Frame>
  <img />
</Frame>


# Dataflow Analytics Pipeline
Source: https://support.lilt.com/self-managed/v6.1/dataflow-analytics

Understand and configure the Dataflow analytics service, including ETL jobs, backfill operations, and the initial data load process

## Overview

Dataflow is the analytics ETL (Extract, Transform, Load) pipeline that powers LILT's reporting and usage metrics. It continuously moves data from the primary MySQL database into ClickHouse, an analytics-optimized column store, where it is aggregated into materialized views for dashboards and operational reporting.

Dataflow runs as a collection of scheduled jobs orchestrated by Argo Workflows inside your Kubernetes cluster. Each job handles a specific data domain (file translations, documents, users, connector jobs, etc.) and runs on its own schedule.

Two special operational modes exist beyond the regular scheduled ETL:

* **Initial Load**: Automatically runs all enabled ETL jobs in sequence when the system is first installed or upgraded. This ensures ClickHouse is populated with historical data.
* **Backfill**: A manually-triggered operation that rebuilds ClickHouse materialized views. Used after schema changes or when historical data needs to be reprocessed.

## Architecture

### Data Flow

```
MySQL (primary database)
    │
    ▼
Dataflow ETL Jobs (Python, running as Argo Workflows)
    │
    ▼
ClickHouse (analytics database, lilt_analytics schema)
    │
    ▼
Materialized Views (pre-aggregated metrics for dashboards)
```

### Key Components

| Component | Description |
| - | - |
| **Argo Workflows** | Orchestrates all ETL jobs as CronWorkflows (scheduled) or Workflows (manual/one-shot) |
| **CronWorkflows** | Kubernetes resources that run ETL jobs on defined schedules (e.g., every 15 minutes, every 2 hours) |
| **WorkflowTemplates** | Reusable job definitions shared across all ETL jobs |
| **Cloud SQL Proxy** (GCP only) | Sidecar container providing secure MySQL connectivity |
| **ClickHouse** | Analytics database using `lilt_analytics` schema with ReplacingMergeTree tables |

### How ETL Jobs Work

Each ETL job follows the same pattern:

1. **Connect** to MySQL and ClickHouse
2. **Read the high-water mark** — the timestamp of the last record processed in ClickHouse
3. **Fetch a batch** of records from MySQL that are newer than the high-water mark
4. **Transform** the records into the ClickHouse schema format
5. **Insert** the batch into ClickHouse
6. **Repeat** until no more new records are found
7. **Sleep** between batches to avoid overloading the source database

ClickHouse tables use the **ReplacingMergeTree** engine, which provides upsert semantics — if a record with the same primary key is inserted again (e.g., during a backfill), the latest version automatically replaces the old one during background merges.

## ETL Job Reference

The following jobs are available. Each can be independently enabled or disabled in your configuration:

| Job Name | Default Schedule | Description |
| - | - | - |
| `ingest-file-translation` | Every 15 minutes | File translation records and metadata |
| `ingest-documents` | Every hour | Document-level translation data |
| `ingest-users` | Every 2 hours | User account information |
| `ingest-connectorjobs` | Every 2 hours | Connector integration job records |
| `ingest-comments` | Every 2 hours | Translation comments and annotations |
| `segment-quality` | Every 2 hours | Segment-level quality metrics |
| `ingest-otd` | Daily (3am, 2pm) | On-time delivery data |
| `ingest-revision-reports` | Daily (5am) | Revision report data |
| `ingest-financialdata` | Daily (5am) | Financial and billing data (GCP only) |
| `linguist-activity-cdc` | Every 2 hours | Linguist activity change data capture (GCP only) |
| `ingest-wpa-minio` | Daily (2am) | Word-pair analysis data from object storage |
| `ingest-wpa-bigquery` | Every 2 hours | Word-pair analysis data from BigQuery (GCP only) |
| `generate-memory-snapshot` | Daily (8pm) | Translation memory snapshots |
| `refresh-reviewed-words` | Every 2 hours | Verified/reviewed word counts |
| `backfill` | Manual | Rebuild materialized views |
| `debug` | Manual | Debug pod (runs indefinitely for troubleshooting) |

<Note>
  Jobs marked **(GCP only)** depend on Google Cloud services and are not applicable to self-managed deployments. They should remain disabled in your configuration.
</Note>

## Initial Load

### What It Does

The Initial Load is a one-time workflow that runs automatically after a Helm install or upgrade (when enabled). It ensures that ClickHouse is fully populated with data by executing all enabled ETL jobs in series, followed by the backfill job.

### Execution Order

1. All enabled ETL jobs run **one at a time, in sequence** (excluding `backfill` and `debug`)
2. Each job is allowed to fail without blocking subsequent jobs
3. The `backfill` job runs **last**, rebuilding materialized views with the freshly ingested data

### When It Runs

The Initial Load is triggered as a **Helm post-install/post-upgrade hook**. It runs automatically whenever the dataflow chart is installed or upgraded, provided it is enabled in your configuration.

<Note>
  The Initial Load workflow may take significant time depending on the volume of historical data. Monitor progress via `kubectl` (see [Troubleshooting](#troubleshooting)).
</Note>

### Configuration

```yaml theme={null}
dataflow:
  onpremValues:
    jobs:
      initialLoad:
        enabled: true  # Set to true to run on install/upgrade
```

### Manually Triggering an Initial Load

If you need to re-run the Initial Load outside of a Helm install/upgrade cycle, create a new Workflow from the existing WorkflowTemplate:

```bash theme={null}
kubectl create -n <namespace> -f - <<EOF
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: <release-name>-initial-load-manual-
spec:
  workflowTemplateRef:
    name: <release-name>-initial-load
EOF
```

Replace `<release-name>` with your Helm release name (typically `lilt`) and `<namespace>` with your deployment namespace.

## Backfill Operations

### What It Does

The backfill job rebuilds ClickHouse **materialized views** — pre-aggregated summary tables that power dashboards and reports. This is necessary when:

* New columns have been added to base tables (via ClickHouse migrations)
* Historical data needs to be reprocessed to populate new fields
* Materialized views have become inconsistent or corrupted

### How It Works

1. **Drops** existing materialized views
2. **Recreates** them with the current schema definition
3. **Backfills** historical data in time-based batches:
   * Batch 1: Last 12 months (most recent data first)
   * Batch 2: 12–24 months ago
   * Batch 3: Older than 24 months

This batched approach ensures that the most valuable recent data is available first and prevents timeouts during large rebuilds.

### Key Materialized Views

| View | Purpose |
| - | - |
| `mv_mt_translation_throughput` | Aggregated instant/MT translation metrics by user, date, language pair, and domain |
| `mv_user_daily_verified_words` | Daily verified translation word counts per user |
| `mv_verified_translation_throughput` | Project-level verified translation throughput |
| `mv_online_offline_total` | Online vs offline translation totals |
| `mv_jobs_costs_summary` | Job cost summaries by domain |

### Configuration

The backfill job is defined as a manually-triggered CronWorkflow:

```yaml theme={null}
dataflow:
  onpremValues:
    jobs:
      scripts:
        backfill:
          enabled: true   # Create the CronWorkflow resource
          # trigger is always "manual" — no automatic schedule
```

When `enabled: true`, a **suspended** CronWorkflow is created. It will not run on a schedule — it must be triggered manually.

### Running a Backfill

Trigger the backfill by creating a new Workflow from the CronWorkflow's WorkflowTemplate:

```bash theme={null}
kubectl create -n <namespace> -f - <<EOF
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: <release-name>-backfill-manual-
spec:
  workflowTemplateRef:
    name: <release-name>-job
  arguments:
    parameters:
      - name: command
        value: "python -m bin.rebuild_materialized_views"
EOF
```

### Monitoring Progress

```bash theme={null}
# List running workflows
kubectl get workflows -n <namespace> | grep dataflow

# Watch workflow status
kubectl get workflow -n <namespace> <workflow-name> -w

# Stream pod logs for a running workflow
kubectl logs -n <namespace> -l workflows.argoproj.io/workflow=<workflow-name> -f
```

## Configuration Reference

### Enabling/Disabling Jobs

Each ETL job can be independently toggled. For self-managed deployments, the recommended configuration is:

```yaml theme={null}
dataflow:
  onpremValues:
    jobs:
      initialLoad:
        enabled: true

      scripts:
        # Enable for self-managed (uses object storage)
        ingest-wpa-minio:
          enabled: true

        # Disable — requires Google BigQuery (not available in self-managed)
        ingest-wpa-bigquery:
          enabled: false
        ingest-financialdata:
          enabled: false
        linguist-activity-cdc:
          enabled: false

        # Enable for backfill operations
        backfill:
          enabled: true

        # Optional debug pod (enable only when troubleshooting)
        debug:
          enabled: false
```

<Note>
  Jobs that depend on Google BigQuery (`ingest-wpa-bigquery`, `ingest-financialdata`, `linguist-activity-cdc`) must remain **disabled** in self-managed deployments as the BigQuery service is not available.
</Note>

## ClickHouse Migrations

Dataflow includes a **migration job** that runs automatically during Helm sync operations. This job applies any pending ClickHouse schema changes (new tables, columns, or materialized views) before ETL jobs run.

The migration job:

* Runs as a Kubernetes Job with an ArgoCD sync hook
* Applies migrations sequentially and idempotently
* Is automatically cleaned up after completion (default TTL: 10 minutes)

<Note>
  After a migration adds new columns to existing tables, a **backfill** may be required to populate those columns for historical records. Check the release notes for your version to determine if a backfill is recommended after upgrade.
</Note>

## Troubleshooting

### Viewing Job Status

List all dataflow CronWorkflows:

```bash theme={null}
kubectl get cronworkflows -n <namespace> | grep dataflow
```

List recent workflow runs:

```bash theme={null}
kubectl get workflows -n <namespace> --sort-by=.metadata.creationTimestamp
```

### Common Issues

#### Jobs are not running

1. **Check that Argo Workflows is installed and healthy:**
   ```bash theme={null}
   kubectl get pods -n <namespace> | grep argo
   ```

2. **Verify CronWorkflows exist and are not suspended** (scheduled jobs should show `suspend: false`):
   ```bash theme={null}
   kubectl get cronworkflows -n <namespace> -o yaml | grep -A2 "name:\|suspend:"
   ```

3. **Check that the dataflow image can be pulled:**
   ```bash theme={null}
   kubectl get events -n <namespace> --field-selector reason=Failed | grep dataflow
   ```

#### ClickHouse migration job hangs or fails

1. **Check the migration job logs:**
   ```bash theme={null}
   kubectl logs -n <namespace> -l job-name=<release-name>-clickhouse-migration-job-<revision>
   ```

2. **Verify the `lilt_analytics` database exists** in ClickHouse:
   ```bash theme={null}
   kubectl exec -it -n <namespace> <clickhouse-pod> -- \
     clickhouse-client --query "SHOW DATABASES"
   ```

#### Initial Load did not run after upgrade

The Initial Load only runs as a Helm hook. If it did not trigger:

1. Verify `initialLoad.enabled: true` in your values
2. Check Helm hook execution:
   ```bash theme={null}
   kubectl get workflows -n <namespace> | grep initial-load
   ```
3. Manually trigger if needed (see [Manually Triggering an Initial Load](#manually-triggering-an-initial-load))

### Enabling the Debug Pod

For deeper troubleshooting, enable the debug pod to get an interactive shell with the dataflow environment:

```yaml theme={null}
dataflow:
  onpremValues:
    jobs:
      scripts:
        debug:
          enabled: true
```

After deploying, trigger the debug workflow:

```bash theme={null}
kubectl create -n <namespace> -f - <<EOF
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: <release-name>-debug-manual-
spec:
  workflowTemplateRef:
    name: <release-name>-job
  arguments:
    parameters:
      - name: command
        value: "sleep infinity"
EOF
```

Then exec into the running pod:

```bash theme={null}
kubectl exec -it -n <namespace> <debug-pod-name> -- /bin/bash
```

This gives you access to the full dataflow environment for running individual ETL commands, testing database connectivity, or inspecting the runtime configuration.

### Error Retry Behavior

ETL jobs include built-in retry logic for transient errors:

| Error Type | Behavior |
| - | - |
| HTTP 500/502/503/504 | Retries up to 3 times with 5-second delay |
| Connection reset/refused | Retries up to 3 times with 5-second delay |
| Timeout errors | Retries up to 3 times with 5-second delay |
| ClickHouse memory limit exceeded | Fails immediately (increase resource limits) |
| Other database errors | Fails immediately (check logs for details) |


# Troubleshooting
Source: https://support.lilt.com/self-managed/v6.1/deleting



## Resetting AI Models

To reset AI models, follow the guide at [Enable/Disable Features](/self-managed/v6.1/enable-features) and run the command:

`npm run dist-admin-cli -- mass-reset-ai --orgId=<ORG_ID>`

## 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/\<id here>/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/\<id here>/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


# Enable/Disable Features
Source: https://support.lilt.com/self-managed/v6.1/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](/self-managed/v6.1/enable-features#enable-features-via-admin-cli) | [Linguist Homepage](#linguist-homepage) below |
| enableLiltCreate | Both | [LILT Create](#lilt-create) below |
| Incompatible Browsers | [Environment Variable](/self-managed/v6.1/enable-features#enabling-features-via-environment-variables) | [Incompatible Browsers](#incompatible-browsers) below |
| enableOCR | [Admin CLI](/self-managed/v6.1/enable-features#enable-features-via-admin-cli) | Enable OCR using internal Tesseract deployment |
| enableOpenAiWhisper | [Admin CLI](/self-managed/v6.1/enable-features#enable-features-via-admin-cli) | Enable ASR using internal Whisper deployment |
| enableWSO2Login | [Admin CLI](/self-managed/v6.1/enable-features#enable-features-via-admin-cli) | See [WSO2 SSO configuration](/self-managed/v6.1/single-sign-on-sso#wso2) |
| External Model Configuration | [Environment Variable](/self-managed/v6.1/enable-features#enabling-features-via-environment-variables) | [External Model Configuration](#external-model-configuration) below |

## Enable Features via Admin CLI

<Note>
  NOTE: For LILT November 2023 release onwards, please use `npm run dist-admin-cli` instead of `admin-cli`
</Note>

Perform the following steps to enable features for the organization:

1. Connect to front pod:\
   `master# kubectl exec -it -n lilt <frontpod> -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 `<ORG_ID>` with the relevant Organization ID:\*\*

   ```bash theme={null}
   npm run dist-admin-cli -- set-org-setting --orgIds <ORG_ID> --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).

<Frame>
  <img />
</Frame>

#### 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=<ORG ID>
```

## 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.

<Frame>
  <img />
</Frame>

#### 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](/self-managed/v6.1/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 <ORG_ID> \
  --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 |

<Note>
  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.
</Note>


# Enable Incompatible Browsers
Source: https://support.lilt.com/self-managed/v6.1/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.


# Generate Evaluation Metrics (WPA, BLEU)
Source: https://support.lilt.com/self-managed/v6.1/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 <update-neural-pod-name> -- bash scripts/metrics/visualize_wpa.py --datastore csv --base-path s3://lilt/wpa --start_date <start-date yyyy-mm-dd> --end_date <end-date yyyy-mm-dd> --memory_id <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://<path>`

* `--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%
```

<Note>
  * **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.
</Note>

## 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: <sqlalchemy.engine.base.Connection object at 0x7f29b916b1c0>
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
```

<Note>
  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`.
</Note>


# GPU Profiles And Values Overlays
Source: https://support.lilt.com/self-managed/v6.1/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/<ENV_NAME>/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.

<Warning>
  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.
</Warning>

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
```

<Note>
  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.
</Note>

### 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.

<Warning>
  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.
</Warning>

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.

<Note>
  `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.
</Note>

### 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/<provider>.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.

<Warning>
  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.
</Warning>

### 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 |

<Warning>
  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.
</Warning>

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 <pod> | 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)](/self-managed/v6.1/install-system-aws-eks)
* [Self-managed hardware requirements](/self-managed/v6.1/self-managed-hardware-requirements)
* [Single sign-on (SSO)](/self-managed/v6.1/single-sign-on-sso)


# ICU Support
Source: https://support.lilt.com/self-managed/v6.1/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 <a>UniFi Protect</a>.} uosOnly {Update <a>UniFi OS</a>.} other {Update <a>UniFi OS</a> and <a>UniFi Protect</a>.}}",
    "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 <a>HDD selection</a>.",
    "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/self-managed/v6.1/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.


# Install on an Existing EKS Cluster
Source: https://support.lilt.com/self-managed/v6.1/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](/self-managed/v6.1/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`.

<Warning>
  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.
</Warning>

* 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](/self-managed/v6.1/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](/self-managed/v6.1/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
```

<Note>
  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.
</Note>

<Warning>
  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.
</Warning>

## 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=<choose one>
```

### Registry Paths

A full image reference is `<REGISTRY_BASE>/<REGISTRY_PATH_*>/<image>`. 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 `<REGISTRY_BASE>/<image>` 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.

<Warning>
  The certificate must cover all of these names. They are siblings, not subdomains, so a single `*.<SUBDOMAIN>.<DNS_DOMAIN>` wildcard is not enough:

  ```
  *.<SUBDOMAIN>.<DNS_DOMAIN>
  <SUBDOMAIN>.<DNS_DOMAIN>
  core-api-<SUBDOMAIN>.<DNS_DOMAIN>
  connectors-api-<SUBDOMAIN>.<DNS_DOMAIN>
  wso2-<SUBDOMAIN>.<DNS_DOMAIN>
  ```

  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.
</Warning>

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 |

<Warning>
  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.
</Warning>

## 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](/self-managed/v6.1/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)](/self-managed/v6.1/install-system-aws-eks).


# Provision AWS Infrastructure with Terraform
Source: https://support.lilt.com/self-managed/v6.1/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)](/self-managed/v6.1/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](/self-managed/v6.1/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
```

<Warning>
  `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.
</Warning>

## 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 `<name>-<subdomain>.<base_domain>`. |
| `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. |

<Warning>
  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.
</Warning>

## 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 = {}`.

<Warning>
  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.
</Warning>

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.

<Warning>
  **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
  ```
</Warning>

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. |

<Note>
  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`.
</Note>

### 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 `<PREFIX>-eks`
* `RDS_IDENTIFIER` becomes `<PREFIX>-rds`
* `S3_BUCKET` becomes `<PREFIX>-s3`
* `SQS_QUEUE_URL` becomes `https://sqs.<AWS_REGION>.amazonaws.com/<account>/<PREFIX>-sqs`
* `APP_WORKLOAD_ROLE_NAME` becomes `<PREFIX>-app-workload`
* `CLUSTER_AUTOSCALER_ROLE_NAME` becomes `<PREFIX>-cluster-autoscaler`
* `CERT_MANAGER_ROLE_NAME` becomes `<PREFIX>-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.

<Warning>
  Whichever path you choose, the certificate must cover every LILT hostname. The hostnames are siblings, not subdomains, so a `*.<subdomain>.<base_domain>` 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.
</Warning>

## 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](/self-managed/v6.1/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)](/self-managed/v6.1/install-system-aws-eks) — configure `install.env` and run the install.


# install.env Reference
Source: https://support.lilt.com/self-managed/v6.1/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 `<name>-<SUBDOMAIN>.<DNS_DOMAIN>`. |
| `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 `<PREFIX>-<suffix>` 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` | `<PREFIX>-eks` | EKS cluster to target. |
| `RDS_IDENTIFIER` | `<PREFIX>-rds` | RDS instance lookup key. |
| `DB_NAME` | `lilt_dev` | Application database. |
| `S3_BUCKET` | `<PREFIX>-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` | `<PREFIX>-app-workload` | IAM role name, matched as a substring. |
| `CLUSTER_AUTOSCALER_ROLE_NAME` | `<PREFIX>-cluster-autoscaler` | IAM role name for Cluster Autoscaler. |
| `CERT_MANAGER_ROLE_NAME` | `<PREFIX>-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](/self-managed/v6.1/install-aws-terraform-module#workload-identity). |

## DNS and TLS

See [Set custom domain and certificates](/self-managed/v6.1/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 `<REGISTRY_BASE>/<REGISTRY_PATH_*>/<image>`. See [Install package](/self-managed/v6.1/install-package).

| Variable | Default | Purpose |
| - | - | - |
| `REGISTRY_BASE` | `harbor.<SUBDOMAIN>.<DNS_DOMAIN>` 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` | `<STORAGE_CLASS>-retain` | Retaining variant. |

<Warning>
  `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.
</Warning>

<Warning>
  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.
</Warning>

## Registry Seeding

Off by default. See [Seed your container registry](/self-managed/v6.1/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)](/self-managed/v6.1/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](/self-managed/v6.1/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 `<SMTP_SECRET_PATH>`, 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. |

<Warning>
  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.
</Warning>

<Warning>
  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.
</Warning>

## Secret Backend

See [Secrets and Vault](/self-managed/v6.1/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. |
| `<NAME>_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/<PREFIX>-vault-unseal` | KMS key for auto-unseal. |
| `VAULT_UNSEAL_ROLE_NAME` | `<PREFIX>-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.<SUBDOMAIN>.<DNS_DOMAIN>` | 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. |

<Warning>
  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.
</Warning>

### 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=<your-role-id> \
  --from-literal=secret-id=<your-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](/self-managed/v6.1/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)](/self-managed/v6.1/install-system-aws-eks)
* [Install package](/self-managed/v6.1/install-package)
* [Secrets and Vault](/self-managed/v6.1/secrets-and-vault)
* [Set custom domain and certificates](/self-managed/v6.1/set-custom-domain-and-certificates)
* [GPU profiles and values overlays](/self-managed/v6.1/gpu-profiles-and-values-overlays)


# Install from a Bastion
Source: https://support.lilt.com/self-managed/v6.1/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_<hash>.tar.gz
test -f install-lilt-eks.sh   # confirms this is the EKS flavor
```

See [Install package](/self-managed/v6.1/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 <region> --name <cluster-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)](/self-managed/v6.1/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](/self-managed/v6.1/install-package#seed-your-container-registry) for the full options.

<Warning>
  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.
</Warning>

## 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.

<Accordion title="Optional: run the installer as a systemd unit">
  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.
</Accordion>

## 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 `<pending>`. Stuck at `<pending>` 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://<your-host>/
```

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](/self-managed/v6.1/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](/self-managed/v6.1/install-system-aws-eks#resuming-a-failed-install).


# Install K8S In Offline Environment (Rocky 8)
Source: https://support.lilt.com/self-managed/v6.1/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 <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/$K8S_VERSION/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/$K8S_VERSION/rpm/repodata/repomd.xml.key
exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni
EOF
```

Pull packages, saved in `/k8s` directory:

```bash theme={null}
sudo dnf install -y --downloadonly --downloaddir=/k8s kubelet kubeadm kubectl --disableexcludes=kubernetes
```

Compress directory for easier transfer:

```bash theme={null}
tar -zcvf /k8s.tar.gz /k8s
```

#### Step 3 (optional): Determine Dependencies

Required dependencies are already listed in the following step, but can verify if necessary.

Check which version of K8S was downloaded:

```bash theme={null}
ls /k8s | grep kubeadm
```

Output should look similar to the following:

```
kubeadm-1.29.12-150500.1.1.x86_64.rpm
```

In this example, using `v1.29.12`. Set variable for `kubeadm` version:

```bash theme={null}
export KUBEADM_VERSION=v1.29.12
```

Download `kubeadm` binary, make executable, and move to bin:

```bash theme={null}
# download
curl -L https://dl.k8s.io/release/$KUBEADM_VERSION/bin/linux/amd64/kubeadm -o kubeadm_$KUBEADM_VERSION

# move binary
sudo mv kubeadm_$KUBEADM_VERSION /usr/local/bin/kubeadm

# set permissions to execute
sudo chmod +x /usr/local/bin/kubeadm
```

List dependencies:

```bash theme={null}
kubeadm config images list --kubernetes-version=$KUBEADM_VERSION
```

Output should be similar to the following:

```bash theme={null}
registry.k8s.io/kube-apiserver:v1.29.12
registry.k8s.io/kube-controller-manager:v1.29.12
registry.k8s.io/kube-scheduler:v1.29.12
registry.k8s.io/kube-proxy:v1.29.12
registry.k8s.io/coredns/coredns:v1.11.1
registry.k8s.io/pause:3.9
registry.k8s.io/etcd:3.5.16-0
```

#### Step 4: Prepare Dependency Images

Pull all required images, can use `Docker` or `containerd`.

**Using Docker:**

```bash theme={null}
docker pull --platform=linux/amd64 registry.k8s.io/kube-apiserver:v1.29.12
docker pull --platform=linux/amd64 registry.k8s.io/kube-controller-manager:v1.29.12
docker pull --platform=linux/amd64 registry.k8s.io/kube-scheduler:v1.29.12
docker pull --platform=linux/amd64 registry.k8s.io/kube-proxy:v1.29.12
docker pull --platform=linux/amd64 registry.k8s.io/coredns/coredns:v1.11.1
docker pull --platform=linux/amd64 registry.k8s.io/pause:3.9
docker pull --platform=linux/amd64 registry.k8s.io/etcd:3.5.16-0
```

Save the images as compressed files so that they can be transferred to the offline system:

```bash theme={null}
docker save -o kube-apiserver_v1.29.12.tar registry.k8s.io/kube-apiserver:v1.29.12
docker save -o kube-controller-manager_v1.29.12.tar registry.k8s.io/kube-controller-manager:v1.29.12
docker save -o kube-scheduler_v1.29.12.tar registry.k8s.io/kube-scheduler:v1.29.12
docker save -o kube-proxy_v1.29.12.tar registry.k8s.io/kube-proxy:v1.29.12
docker save -o coredns_v1.11.1.tar registry.k8s.io/coredns/coredns:v1.11.1
docker save -o pause_3.9.tar registry.k8s.io/pause:3.9
docker save -o etcd_3.5.16-0.tar registry.k8s.io/etcd:3.5.16-0
```

**Using containerd:**

```bash theme={null}
ctr image pull --platform=linux/amd64 registry.k8s.io/kube-apiserver:v1.29.12
ctr image pull --platform=linux/amd64 registry.k8s.io/kube-controller-manager:v1.29.12
ctr image pull --platform=linux/amd64 registry.k8s.io/kube-scheduler:v1.29.12
ctr image pull --platform=linux/amd64 registry.k8s.io/kube-proxy:v1.29.12
ctr image pull --platform=linux/amd64 registry.k8s.io/coredns/coredns:v1.11.1
ctr image pull --platform=linux/amd64 registry.k8s.io/pause:3.9
ctr image pull --platform=linux/amd64 registry.k8s.io/etcd:3.5.16-0
```

Save the images as compressed files so that they can be transferred to the offline system:

```bash theme={null}
ctr image export --platform=linux/amd64 kube-apiserver_v1.29.12.tar registry.k8s.io/kube-apiserver:v1.29.12
ctr image export --platform=linux/amd64 kube-controller-manager_v1.29.12.tar registry.k8s.io/kube-controller-manager:v1.29.12
ctr image export --platform=linux/amd64 kube-scheduler_v1.29.12.tar registry.k8s.io/kube-scheduler:v1.29.12
ctr image export --platform=linux/amd64 kube-proxy_v1.29.12.tar registry.k8s.io/kube-proxy:v1.29.12
ctr image export --platform=linux/amd64 coredns_v1.11.1.tar registry.k8s.io/coredns/coredns:v1.11.1
ctr image export --platform=linux/amd64 pause_3.9.tar registry.k8s.io/pause:3.9
ctr image export --platform=linux/amd64 etcd_3.5.16-0.tar registry.k8s.io/etcd:3.5.16-0
```

#### Step 5: Transfer Binaries/Images to Offline System

Transfer downloaded binaries and images to offline system. This can be done via secure ssh or removable storage media.

* k8s.tar.gz

* kube-apiserver\_v1.29.12.tar

* kube-controller-manager\_v1.29.12.tar

* kube-scheduler\_v1.29.12.tar

* kube-proxy\_v1.29.12.tar

* coredns\_v1.11.1.tar

* pause\_3.9.tar

* etcd\_3.5.16-0.tar

## Install K8S

### Offline System without Internet Access

Import all binaries and images from the system with internet access to the offline system. This example uses a linux machine.

Commands have to be performed as root (since it involves installation of Kubernetes).

```bash theme={null}
sudo su -
```

#### Step 1: Install K8S Packages

Unzip k8s.tar and install, then enable `kubelet`:

```bash theme={null}
# unzip k8s components
tar -zxvf k8s.tar.gz

# install k8s
rpm -ivh --replacefiles --replacepkgs /k8s/*.rpm

# enable kubelet
systemctl enable kubelet.service
systemctl start kubelet.service

# check status
sudo systemctl status kubelet
```

#### Step 2: Load K8S Dependency Images

Load K8S images with either `docker` or `containerd`(using containerd for this example):

```bash theme={null}
sudo ctr -n=k8s.io images import kube-apiserver_v1.29.12.tar
sudo ctr -n=k8s.io images import kube-controller-manager_v1.29.12.tar
sudo ctr -n=k8s.io images import kube-scheduler_v1.29.12.tar
sudo ctr -n=k8s.io images import kube-proxy_v1.29.12.tar
sudo ctr -n=k8s.io images import coredns_v1.11.1.tar
sudo ctr -n=k8s.io images import pause_3.9.tar
sudo ctr -n=k8s.io images import etcd_3.5.16-0.tar
```

#### Step 3: Initialize K8S

Initialize and setup cluster control-plane node:

```bash theme={null}
CNI_CIDR="192.168.100.0/19"
SERVICE_CIDR="192.168.200.0/19"
NODE_NAME="my-node"
kubeadm init \
    --pod-network-cidr $CNI_CIDR \
    --service-cidr $SERVICE_CIDR \
    --node-name $NODE_NAME
```

<Note>
  NOTE: Ensure that CNI and Service CIDRs are consistent with previous or desired installation.
</Note>

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>
  NOTE: `coredns` pods will be in *“Pending”* state until flannel (or other CNI) is installed.
</Note>


# Install Package
Source: https://support.lilt.com/self-managed/v6.1/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_<hash>.tar.gz` | `install-lilt-eks.sh` | You run LILT on Amazon Elastic Kubernetes Service. |
| On-premises | `on-prem-installer_<hash>.tar.gz` | `install-lilt.sh` | You run LILT on bare-metal or virtual machines that you manage. |

`<hash>` 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](/self-managed/v6.1/install-system-aws-eks#component-flags).

<Note>
  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](/self-managed/v6.1/install-aws-terraform-module).
</Note>

## Download the Package

LILT gives you an S3 release URI for your version, in the form `s3://<bucket>/lilt-enterprise-<version>/`. 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`.

<Note>
  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 `<PREFIX>-s3` by the Terraform module, and is set with `S3_BUCKET` in `install.env`.
</Note>

Every release uses the same layout under the release prefix:

```
lilt-enterprise-<version>/
├── 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://<bucket>/lilt-enterprise-<version>"
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.

<Warning>
  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.
</Warning>

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-<component>.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. |

<Warning>
  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.
</Warning>

## 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.

<Warning>
  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 <region> | crane auth login --username AWS --password-stdin <account>.dkr.ecr.<region>.amazonaws.com`.
</Warning>

### 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://<bucket>/lilt-enterprise-<version>` | 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://<bucket>/lilt-enterprise-<version>"
export TARGET_REGISTRY="<account-id>.dkr.ecr.<region>.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
```

<Note>
  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.
</Note>

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.

<Warning>
  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.
</Warning>

### 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](/self-managed/v6.1/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)](/self-managed/v6.1/install-system-aws-eks) — configure and run the EKS install.
* [Provision AWS infrastructure with Terraform](/self-managed/v6.1/install-aws-terraform-module) — create the cluster, database, and IAM roles with the `lilt-aws-env` module.
* [Install on an existing EKS cluster](/self-managed/v6.1/install-aws-existing-cluster) — use infrastructure you provisioned yourself.
* [Install System (Amazon Linux 2023 or Rocky 8/9)](/self-managed/v6.1/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/self-managed/v6.1/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/self-managed/v6.1/lilt-system-architecture](https://self-managed-docs.lilt.com/self-managed/v6.1/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](/self-managed/v6.1/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
```

<Note>
  The installer requires Helm 4 and refuses to run with Helm 3. Verify with `helm version --short`.
</Note>

#### 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 <<EOF >> /etc/security/limits.conf
* soft nofile 131072
* hard nofile 131072
EOF

cat <<EOF >> /etc/systemd/system.conf
DefaultLimitNOFILE=131072
EOF
```

#### Step 5: Set kernel parameters as required by Kubernetes

```bash theme={null}
bash -c 'cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
nf_nat
xt_REDIRECT
xt_owner
iptable_nat
iptable_mangle
iptable_filter
EOF'

modprobe overlay
modprobe br_netfilter
modprobe nf_nat
modprobe xt_REDIRECT
modprobe xt_owner
modprobe iptable_nat
modprobe iptable_mangle
modprobe iptable_filter

bash -c 'cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF'

sysctl --system
```

#### Step 6: Turn off swap, disable SELinux, update local firewall changes, and modify max\_map\_count

<Frame>
  <img />
</Frame>

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/
```

<Frame>
  <img />
</Frame>

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 <<EOF > /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 <<EOF > /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 <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v$K8S_V/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v$K8S_V/rpm/repodata/repomd.xml.key
exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni
EOF

# install kubelet, kubeadm, kubectl, create symlink
sudo dnf install -y kubelet kubeadm kubectl --disableexcludes=kubernetes

# enable kubelet
sudo systemctl enable --now kubelet
```

Verify the installation by checking the packages version

```
kubectl version --client && kubeadm version
```

#### Step 11: Reboot node/server

```
reboot
```

#### Step 12 (GPU NODE ONLY): Install NVIDIA Drivers

Each base OS has different package requirements.

* *Amazon Linux 2023*:

```bash theme={null}
# update dependnecies and kernel
dnf check-release-update
sudo dnf update -y
sudo dnf install -y dkms 
sudo systemctl enable --now dkms
if (uname -r | grep -q ^6.12.); then
  sudo dnf install -y kernel-devel-$(uname -r)  kernel6.12-modules-extra
else
  sudo dnf install -y kernel-devel-$(uname -r)  kernel-modules-extra
fi

# add nvidia repo
sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/amzn2023/x86_64/cuda-amzn2023.repo

# clean cache
sudo dnf clean expire-cache

# install driver
sudo dnf module install -y nvidia-driver:565-dkms

# install cuda toolkit
sudo dnf install -y cuda-toolkit-12-6

# install cudnn
wget https://developer.download.nvidia.com/compute/cudnn/redist/cudnn/linux-x86_64/cudnn-linux-x86_64-9.6.0.74_cuda12-archive.tar.xz

# unpack
tar -xf cudnn-linux-x86_64-9.6.0.74_cuda12-archive.tar.xz

# copy to dirs
sudo cp -P cudnn-linux-x86_64-9.6.0.74_cuda12-archive/include/* /usr/local/cuda/include/
sudo cp -P cudnn-linux-x86_64-9.6.0.74_cuda12-archive/lib/* /usr/local/cuda/lib64/

# set permissions
sudo chmod a+r /usr/local/cuda/include/cudnn*.h
sudo chmod a+r /usr/local/cuda/lib64/libcudnn*

# optional, remove downloads to free up space
rm -rf cudnn-linux-x86_64-9.6.0.74_cuda12-archive*

# update libarary cache
sudo ldconfig

# install container toolkit
# add repo
sudo dnf config-manager --add-repo https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo
# install
# 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.


# reboot to complete install
reboot
```

* *Rocky 8*:

```bash theme={null}
# extra required packages
sudo dnf -y install epel-release

# get rhel/rocky OS current version
export cur_ver="rhel$(rpm -E %rhel)"

# install kernel headers
sudo dnf install kernel-devel-$(uname -r) kernel-headers-$(uname -r) -y

# install cuda-toolkit
sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/$cur_ver/x86_64/cuda-$cur_ver.repo
sudo dnf clean all
sudo dnf -y install cuda-toolkit-12-6

# update nvidia path
export PATH=/usr/local/cuda-12.6/bin${PATH:+:${PATH}}

# install nvidia driver
sudo dnf -y module install nvidia-driver:565-dkms

# zlib is required for cudnn
sudo dnf -y install zlib

# install cudnn
sudo dnf -y install cudnn-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.

# reboot to complete install
reboot
```

* *Rocky 9*:

```bash theme={null}
sudo dnf install -y epel-release dnf-utils gcc make kernel-devel-matched kernel-headers
sudo dnf install -y dkms
sudo dnf config-manager --set-enabled crb

sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86_64/cuda-rhel9.repo
sudo dnf clean all

# cuda toolkit required for cudnn
sudo dnf -y install cuda-toolkit-12-6

# nividia driver
sudo dnf -y module install nvidia-driver:565-dkms

# Run nvidia-smi and capture the output and error
nvidia_output=$(nvidia-smi 2>&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>
  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.
</Note>

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>
  NOTE: STATUS will be `NotReady` until Flannel is installed.
</Note>

```
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:

<Frame>
  <img />
</Frame>

NOTE: STATUS will be `NotReady` until Flannel is installed.

```
NAME     STATUS     ROLES           AGE    VERSION
master   NotReady   control-plane   149m   v1.32.4
worker   NotReady   <none>          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>
  NOTE: `STATUS`will be `NotReady` until Flannel is installed.
</Note>

```
NAME     STATUS     ROLES           AGE    VERSION
gpu      NotReady   <none>          9s     v1.32.4
master   NotReady   control-plane   177m   v1.32.4
worker   NotReady   <none>          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.

<Frame>
  <img />
</Frame>

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 `<release-tag>`):

```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 `<release-tag>`):

```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 `<release-tag>`):

```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](/self-managed/v6.1/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 <namespace> create secret docker-registry <secret-name> \
  --docker-username=<username> \
  --docker-password=<password> \
  --docker-server=<registry-url> \
  --docker-email=<email>
```

<Note>
  NOTE: Image pull secrets are namespace specific, must create a new secret for each additional namespace.
</Note>

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:
    - <secret-name>
```

## 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 <name>-<SUBDOMAIN>.<DNS_DOMAIN>
DNS_DOMAIN=example.com            # your base domain; the main page will be <SUBDOMAIN>.<DNS_DOMAIN>
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
```

<Note>
  The certificate SANs must cover `<SUBDOMAIN>.<DNS_DOMAIN>` 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.
</Note>

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://<SUBDOMAIN>.<DNS_DOMAIN>` (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 `<SUBDOMAIN>.<DNS_DOMAIN>` 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://<SUBDOMAIN>.<DNS_DOMAIN>/signin`:

<Frame>
  <img />
</Frame>

After the admin password is set, LILT can be accessed via `https://<SUBDOMAIN>.<DNS_DOMAIN>/signin`.

<Frame>
  <img />
</Frame>

#### 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 <podname>`

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 <elasticsearch pvc as per above command>
## 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.

<Warning>
  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.
</Warning>

```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 <pvc-name> ...

# Reinstall.
sh install_scripts/install-elastic-eck-cluster.sh
```

<Note>
  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.
</Note>

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>
  NOTE: reseting the cluster will not remove all configuration artifacts. Follow the onscreen output instructions from the below reset command.
</Note>

#### 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/self-managed/v6.1/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](/self-managed/v6.1/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](/self-managed/v6.1/install-aws-existing-cluster) |

Both paths converge here for the second layer.

<Note>
  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)](/self-managed/v6.1/install-system-amazon-linux-2023-or-rocky-8-9).
</Note>

## 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.

   <Warning>
     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.
   </Warning>

   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](/self-managed/v6.1/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](/self-managed/v6.1/install-package).

<Note>
  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](/self-managed/v6.1/install-from-a-bastion).
</Note>

## 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 <<EOF >> /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
```

<Accordion title="Custom or non-EKS-optimized AMI: the full baseline">
  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 <<EOF | sudo tee /etc/modules-load.d/k8s.conf
  overlay
  br_netfilter
  nf_nat
  xt_REDIRECT
  xt_owner
  iptable_nat
  iptable_mangle
  iptable_filter
  EOF

  for m in overlay br_netfilter nf_nat xt_REDIRECT xt_owner \
           iptable_nat iptable_mangle iptable_filter; do
    modprobe "$m"
  done

  cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
  net.bridge.bridge-nf-call-iptables  = 1
  net.bridge.bridge-nf-call-ip6tables = 1
  net.ipv4.ip_forward                 = 1
  EOF

  sysctl --system

  # The kubelet does not start with swap enabled.
  swapoff -a
  sed -e '/swap/s/^/#/g' -i /etc/fstab

  # SELinux, on distributions that enforce it.
  sudo setenforce 0
  sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
  ```

  An unset `xt_REDIRECT` or `xt_owner` is worth calling out: the mesh's traffic redirection depends on them, and without them pods start and then fail to reach each other, which reads as a networking or DNS fault rather than a missing kernel module.
</Accordion>

## 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](/self-managed/v6.1/install-env-reference).

The settings almost every install needs:

| Variable | Purpose |
| - | - |
| `SUBDOMAIN`, `DNS_DOMAIN` | Every ingress hostname is `<name>-<SUBDOMAIN>.<DNS_DOMAIN>`. 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 <Component> ---` before it runs, so the last such line names the component that failed.

* Checks its own `ENABLE_<NAME>` 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 |

<Note>
  `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.
</Note>

**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`.

<Warning>
  Prerequisites are foundational, and everything after them depends on them. Disable one only on a cluster where that step has already completed.
</Warning>

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.

<Warning>
  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.
</Warning>

See [Secrets and Vault](/self-managed/v6.1/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](/self-managed/v6.1/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](/self-managed/v6.1/gpu-profiles-and-values-overlays#single-sign-on-profiles) for the full value list.

<Warning>
  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.
</Warning>

## 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://<SUBDOMAIN>.<DNS_DOMAIN>/
```

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 `<pending>`. 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](/self-managed/v6.1/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 <Component> ---` line names it.

1. Inspect the component that failed:

   ```bash theme={null}
   kubectl get pods -n lilt
   kubectl describe pod <pod> -n lilt
   kubectl logs <pod> -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
```

<Warning>
  Pass `WIPE_DATA` and `PURGE_CRDS` on the command line only. Never put them in `install.env`, which persists across installs.
</Warning>

<Warning>
  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.
</Warning>

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](/self-managed/v6.1/install-package)
* [Provision AWS infrastructure with Terraform](/self-managed/v6.1/install-aws-terraform-module)
* [Install on an existing EKS cluster](/self-managed/v6.1/install-aws-existing-cluster)
* [Install from a bastion](/self-managed/v6.1/install-from-a-bastion)
* [Self-managed hardware requirements](/self-managed/v6.1/self-managed-hardware-requirements)
* [Infrastructure release notes](/self-managed/v6.1/infrastructure-release-notes)


# Instructions To Delete Container Images
Source: https://support.lilt.com/self-managed/v6.1/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 `<image-id>` with the ID of the image you want to delete:

   ```python theme={null}
   docker rmi <image-id>
   ```

   Or, if you prefer to use the image name and tag, replace `<image-name>:<tag>` with the name and tag of the image you want to delete:

   ```ruby theme={null}
   docker rmi <image-name>:<tag>
   ```

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 `<image-name>` with the name of the image you want to delete:

   ```bash theme={null}
   ctr images rm <image-name>
   # use namespace if necessary
   ctr -n k8s.io images rm <image-name>
   ```

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.


# Introduction To LILT Translation
Source: https://support.lilt.com/self-managed/v6.1/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.

<Frame>
  <img />
</Frame>

## 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

<Frame>
  <img />
</Frame>

or

<Frame>
  <img />
</Frame>

<Frame>
  <img />
</Frame>

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:

<Frame>
  <img />
</Frame>

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

<Frame>
  <img />
</Frame>

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

<Frame>
  <img />
</Frame>

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

<Frame>
  <img />
</Frame>

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.

<Frame>
  <img />
</Frame>

* \*\*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.

<Frame>
  <img />
</Frame>

* **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.

<Frame>
  <img />
</Frame>

* **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.

<Frame>
  <img />
</Frame>

* **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.

<Frame>
  <img />
</Frame>

* **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.

<Frame>
  <img />
</Frame>

### Insert tab

The `Insert` tab has a range of tools for interacting with text in the segment editor.

<Frame>
  <img />
</Frame>

* **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).

<Frame>
  <img />
</Frame>

* **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.

<Frame>
  <img />
</Frame>

* **[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.


# Scheduling Maintenance-Window Banners
Source: https://support.lilt.com/self-managed/v6.1/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 <frontPod> -c front -- /bin/bash`

<Note>
  Steps to fetch \<frontpod>:

  * connect to the kubernetes cluster

  * fetch \<frontpod> by running:

    * `kubectl get pods -n lilt | grep -i front`
</Note>

#### 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 "<start-iso-utc>" --end "<end-iso-utc>" --message "<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.
```

<Note>
  Record the `id` from the output. You will need it to cancel the banner before its scheduled end time.
</Note>

## Cancel a scheduled banner

#### Connect to the front pods

`$ kubectl exec -it <frontPod> -c front -- /bin/bash`

#### Delete by id

`$ npm run dist-admin-cli -- delete-maintenance-window --id <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.


# Data Source/Terminology Management
Source: https://support.lilt.com/self-managed/v6.1/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/self-managed/v6.1/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)](/self-managed/v6.1/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)](/self-managed/v6.1/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              = <value recorded from the source>
```

`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 <<EOF
[client]
host=$RDS_ENDPOINT
user=<rds-master-user>
password=<rds-master-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 '<app-password>';
ALTER USER 'lilt'@'%' IDENTIFIED WITH mysql_native_password BY '<app-password>';
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 <<EOF
[client]
host=127.0.0.1
port=13306
user=root
password=$SRC_PASS
EOF
```

A default installation runs the in-cluster database without TLS, which is what the connection above assumes. If custom certificates have been applied to the database outside of the service mesh, add an explicit mode to the credentials file. `REQUIRED` encrypts the connection without validating the server certificate, which is normally what is wanted for an export running through a local tunnel:

```text theme={null}
[client]
host=127.0.0.1
port=13306
user=root
password=<source-password>
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 <<EOF
[client]
host=$RDS_ENDPOINT
user=lilt
password=<app-password>
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 <rds-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)](/self-managed/v6.1/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 <front-pod> -c <init-container> | 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/self-managed/v6.1/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>
  NOTE: live migration will NOT work on a full Lilt deployment. Nodes are unable to reschedule due to LLM image file sizes.
</Note>

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 <<EOF | sudo tee /tigera-operator/on-prem-values.yaml
tigeraOperator:
  registry: <registry>
  image: tigera/operator
  version: v1.34.3
calicoctl:
  image: <registry>/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: <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/self-managed/v6.1/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)](/self-managed/v6.1/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 <minio-pod> -- 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 <minio-pod> -- 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     "<minio-root-user>"     --profile minio
aws configure set aws_secret_access_key "<minio-root-password>" --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="<bucket-name-from-previous-command>"
```

#### 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 `-<n>` 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/<key>` maps to `s3://$DEST_BUCKET/<key>`. 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 "<key>" \
  --body "$STAGE_DIR/<key>" --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 "<key>"
```

#### 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.

* **Stored object references.** If the destination bucket has a different name from the source, the object URIs already stored in the database still name the old bucket, and every pre-existing download, export, and TMX re-import fails until they are rewritten. Follow [Rename the Object Storage Bucket](/self-managed/v6.1/rename-object-storage-bucket) before returning the environment to service. If you can keep the bucket name identical, do so and skip that step.

* **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 <minio-data-dir>/<bucket>/ 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 "<key>"`.

**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.

**New uploads work but anything created before the migration cannot be downloaded or exported**: the bucket was renamed and the stored object URIs were not rewritten. See [Rename the Object Storage Bucket](/self-managed/v6.1/rename-object-storage-bucket).


# Navigation In The Platform
Source: https://support.lilt.com/self-managed/v6.1/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.

<Frame>
  <img />
</Frame>

**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 <img /> icon, and see inbox notifications.


# Node Labels
Source: https://support.lilt.com/self-managed/v6.1/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 name> 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 <node name> capability=gpu
```

Optional: if the GPU node has sufficient resources to run additional workloads, also add worker label:

```bash theme={null}
> kubectl label nodes <node name> capability=gpu node-type=worker
```

**Verify output**

```bash theme={null}
# Show labels
kubectl get nodes --show-labels
```

<Note>
  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.
</Note>

### 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>
  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.
</Note>

This example will only schedule pods on a node that contains BOTH labels:

```bash theme={null}
nodeSelector:
  node-type: worker
  capability: gpu
```


# OneDrive Configuration
Source: https://support.lilt.com/self-managed/v6.1/onedrive-configuration



In order to use OneDrive via Connectors, set the following OIDC values in the `lilt/environments/lilt/values.yml` file:

```yml theme={null}
connectors:
  onpremValues:
    env:
      ONEDRIVE_CLIENT_ID:
      ONEDRIVE_CLIENT_SECRET:
```


# Rename the Object Storage Bucket
Source: https://support.lilt.com/self-managed/v6.1/rename-object-storage-bucket



<Note>
  From release **N+2** (the first release that ships the ENG-32953 migration) stored object
  references no longer carry a scheme or bucket, and renaming the bucket or switching between
  MinIO, S3 and GCS is a configuration change only, provided every service is configured with
  the same bucket. This procedure applies to releases up to **N+1**, and to a JSON or text
  column that still embeds a URI.
</Note>

## Overview

LILT stores object references in the database as full URIs that include the bucket name, for example `s3://lilt/prod/converter-service/...`. Every service that reads one of these URIs checks that the bucket segment equals the bucket it is configured with, and refuses the read if it does not. Copying the objects into a bucket with a different name and pointing the configuration at it is therefore not enough: every reference written before the move still names the old bucket and fails outright.

The symptoms are immediate and affect only pre-existing work. New uploads and new exports succeed, while anything created before the rename fails with `File export failed`, a `500` or `Local URI` error on download, a TMX re-import failure, or `Wrong bucket name` from the neural services. Because the errors show a plausible-looking S3 path, the wrong bucket segment is easy to miss.

This article covers rewriting the stored URIs so an existing installation can move to a bucket with a new name. It applies after the objects have been copied key-for-key, for example by following [Migrate Object Storage (MinIO to S3)](/self-managed/v6.1/migrate-object-storage-minio-to-s3). If you can keep the bucket name identical across the move, do so and skip this procedure entirely.

The table and column inventory below was verified against LILT 5.3.4. Other releases may add columns; the census in the first step is the check.

## Order of Operations

1. Back up the application database (`lilt_dev` by default), or at minimum the tables listed below.
2. Quiesce writers. Scale `front`, `converter-core`, `file-translation-core`, `tm-core`, `job-core`, and `file-job-core` to zero, or pick a quiet window. In-flight RabbitMQ messages carry full URIs, so let the queues drain (`rabbitmqctl list_queues`) before rewriting.
3. Run the census. Every prefix group should show the old bucket or `NULL`. Record the counts.
4. Run the rewrite inside one transaction. Each `UPDATE` is preceded by a `COUNT`; after the update the same count must be zero.
5. Run the JSON and text column rewrites only for columns whose census count was greater than zero. On a stock 5.3.x installation every one of those is expected to be zero.
6. Update the bucket name in every configuration location listed at the end, redeploy, and re-run the census. Only the new bucket should remain.

Set the two values once per session so the statements below can be pasted as written. Both end with a slash so that `lilt` cannot match `lilt-prod`.

```sql theme={null}
SET @old = 's3://lilt/';
SET @new = 's3://lilt-prod/';
```

The `LIKE CONCAT(@old, '%')` anchor cannot match a URI that already carries the new bucket, so re-running any statement is harmless.

## Census

Read-only. Group every URI column by its `scheme://bucket` prefix.

#### Permanent references

These are read for source download, re-export, TMX re-import, estimates, and PDF re-export. Every row must be rewritten.

```sql theme={null}
SELECT 'Documents.fileLocation' col, SUBSTRING_INDEX(fileLocation,'/',3) p, COUNT(*) FROM Documents WHERE fileLocation IS NOT NULL AND fileLocation<>'' GROUP BY p;
SELECT 'Documents.xliffLocation', SUBSTRING_INDEX(xliffLocation,'/',3), COUNT(*) FROM Documents WHERE xliffLocation IS NOT NULL AND xliffLocation<>'' GROUP BY 2;
SELECT 'Files.fileLocation', SUBSTRING_INDEX(fileLocation,'/',3), COUNT(*) FROM Files WHERE fileLocation IS NOT NULL AND fileLocation<>'' GROUP BY 2;
SELECT 'FileTranslations.xliffLocation', SUBSTRING_INDEX(xliffLocation,'/',3), COUNT(*) FROM FileTranslations WHERE xliffLocation IS NOT NULL AND xliffLocation<>'' GROUP BY 2;
SELECT 'FileTranslations.exportUri', SUBSTRING_INDEX(exportUri,'/',3), COUNT(*) FROM FileTranslations WHERE exportUri IS NOT NULL AND exportUri<>'' GROUP BY 2;
SELECT 'UserResources.fileLocation', SUBSTRING_INDEX(fileLocation,'/',3), COUNT(*) FROM UserResources WHERE fileLocation IS NOT NULL AND fileLocation<>'' GROUP BY 2;
SELECT 'UserResources.xliff (URI rows)', SUBSTRING_INDEX(xliff,'/',3), COUNT(*) FROM UserResources WHERE xliff LIKE 's3:%' OR xliff LIKE 'gs:%' GROUP BY 2;
SELECT 'Estimates.fileLocation', SUBSTRING_INDEX(fileLocation,'/',3), COUNT(*) FROM Estimates WHERE fileLocation IS NOT NULL AND fileLocation<>'' GROUP BY 2;
SELECT 'DocumentIntermediateFiles.storageLocation', SUBSTRING_INDEX(storageLocation,'/',3), COUNT(*) FROM DocumentIntermediateFiles WHERE storageLocation IS NOT NULL AND storageLocation<>'' GROUP BY 2;
```

`UserResources.xliff` is named like a content column but holds the imported-XLIFF URI for translation memory and termbase resources.

#### Regenerable references

The application can regenerate these, but it reads the stored value first (the Download button, hard-delete cleanup), so rewrite them too.

```sql theme={null}
SELECT 'Documents.exportURI', SUBSTRING_INDEX(exportURI,'/',3), COUNT(*) FROM Documents WHERE exportURI IS NOT NULL AND exportURI<>'' GROUP BY 2;
SELECT 'Projects.exportURI', SUBSTRING_INDEX(exportURI,'/',3), COUNT(*) FROM Projects WHERE exportURI IS NOT NULL AND exportURI<>'' GROUP BY 2;
SELECT 'Memories.exportURI', SUBSTRING_INDEX(exportURI,'/',3), COUNT(*) FROM Memories WHERE exportURI IS NOT NULL AND exportURI<>'' GROUP BY 2;
SELECT 'Jobs.exportURI', SUBSTRING_INDEX(exportURI,'/',3), COUNT(*) FROM Jobs WHERE exportURI IS NOT NULL AND exportURI<>'' GROUP BY 2;
SELECT 'Uploads.fileLocation', SUBSTRING_INDEX(fileLocation,'/',3), COUNT(*) FROM Uploads WHERE fileLocation IS NOT NULL AND fileLocation<>'' GROUP BY 2;
SELECT 'DocumentExports.storageLocation', SUBSTRING_INDEX(storageLocation,'/',3), COUNT(*) FROM DocumentExports WHERE storageLocation<>'' GROUP BY 2;
SELECT 'JobExports.storageLocation', SUBSTRING_INDEX(storageLocation,'/',3), COUNT(*) FROM JobExports WHERE storageLocation<>'' GROUP BY 2;
SELECT 'ProjectExports.storageLocation', SUBSTRING_INDEX(storageLocation,'/',3), COUNT(*) FROM ProjectExports WHERE storageLocation<>'' GROUP BY 2;
SELECT 'MemoryExports.storageLocation', SUBSTRING_INDEX(storageLocation,'/',3), COUNT(*) FROM MemoryExports WHERE storageLocation<>'' GROUP BY 2;
```

#### Legacy single-slash form

Older releases wrote `s3:/bucket/...` with one slash, and core still accepts it. Expect zero.

```sql theme={null}
SELECT 'legacy Documents.fileLocation', COUNT(*) FROM Documents WHERE fileLocation LIKE REPLACE(CONCAT(@old,'%'),'://',':/')
UNION ALL SELECT 'legacy Documents.xliffLocation', COUNT(*) FROM Documents WHERE xliffLocation LIKE REPLACE(CONCAT(@old,'%'),'://',':/')
UNION ALL SELECT 'legacy Files.fileLocation', COUNT(*) FROM Files WHERE fileLocation LIKE REPLACE(CONCAT(@old,'%'),'://',':/');
```

#### JSON and text columns

These columns could embed a URI. No 5.3.4 writer puts one there, so expect zero everywhere. Rewrite only what the census finds.

```sql theme={null}
SELECT 'AsyncRequests.requestMessage', COUNT(*) FROM AsyncRequests WHERE CAST(requestMessage AS CHAR) LIKE CONCAT('%',@old,'%')
UNION ALL SELECT 'ScheduledEvents.payLoad', COUNT(*) FROM ScheduledEvents WHERE CAST(payLoad AS CHAR) LIKE CONCAT('%',@old,'%')
UNION ALL SELECT 'FileJobs.jobParams', COUNT(*) FROM FileJobs WHERE CAST(jobParams AS CHAR) LIKE CONCAT('%',@old,'%')
UNION ALL SELECT 'UserNotifications.data', COUNT(*) FROM UserNotifications WHERE CAST(data AS CHAR) LIKE CONCAT('%',@old,'%')
UNION ALL SELECT 'ExternalModels.providerConfig', COUNT(*) FROM ExternalModels WHERE CAST(providerConfig AS CHAR) LIKE CONCAT('%',@old,'%')
UNION ALL SELECT 'Projects.metadata', COUNT(*) FROM Projects WHERE CAST(metadata AS CHAR) LIKE CONCAT('%',@old,'%')
UNION ALL SELECT 'Documents.converterConfig', COUNT(*) FROM Documents WHERE converterConfig LIKE CONCAT('%',@old,'%')
UNION ALL SELECT 'Projects.converterConfig', COUNT(*) FROM Projects WHERE converterConfig LIKE CONCAT('%',@old,'%')
UNION ALL SELECT 'FileTranslations.converterConfig', COUNT(*) FROM FileTranslations WHERE CAST(converterConfig AS CHAR) LIKE CONCAT('%',@old,'%')
UNION ALL SELECT 'ConverterConfigs.config', COUNT(*) FROM ConverterConfigs WHERE CAST(config AS CHAR) LIKE CONCAT('%',@old,'%')
UNION ALL SELECT 'Documents.apiMeta', COUNT(*) FROM Documents WHERE apiMeta LIKE CONCAT('%',@old,'%')
UNION ALL SELECT 'ConnectorJobs.args', COUNT(*) FROM ConnectorJobs WHERE CAST(args AS CHAR) LIKE CONCAT('%',@old,'%')
UNION ALL SELECT 'Connectors.args', COUNT(*) FROM Connectors WHERE CAST(args AS CHAR) LIKE CONCAT('%',@old,'%')
UNION ALL SELECT 'NeuralBatchTranslationRequests.request (in-flight only)', COUNT(*) FROM NeuralBatchTranslationRequests WHERE request LIKE CONCAT('%',@old,'%')
UNION ALL SELECT 'NeuralBatchRequests.request (legacy rows only)', COUNT(*) FROM NeuralBatchRequests WHERE CAST(request AS CHAR) LIKE CONCAT('%',@old,'%');
```

If the neural services run with `storageType: minio` (the stock 5.3.x value), their internal URIs use the `minio://` scheme instead of `s3://`. Repeat the two neural counts with `@old` set to the `minio://` form.

## Rewrite

Run as one transaction. `Documents.fileLocation` goes first because front derives new export URIs from it. Compare each count before and after; after must be zero.

```sql theme={null}
START TRANSACTION;

SELECT COUNT(*) FROM Documents WHERE fileLocation LIKE CONCAT(@old,'%');
UPDATE Documents SET fileLocation = REPLACE(fileLocation,@old,@new) WHERE fileLocation LIKE CONCAT(@old,'%');
SELECT COUNT(*) FROM Documents WHERE xliffLocation LIKE CONCAT(@old,'%');
UPDATE Documents SET xliffLocation = REPLACE(xliffLocation,@old,@new) WHERE xliffLocation LIKE CONCAT(@old,'%');
SELECT COUNT(*) FROM Documents WHERE exportURI LIKE CONCAT(@old,'%');
UPDATE Documents SET exportURI = REPLACE(exportURI,@old,@new) WHERE exportURI LIKE CONCAT(@old,'%');
SELECT COUNT(*) FROM Files WHERE fileLocation LIKE CONCAT(@old,'%');
UPDATE Files SET fileLocation = REPLACE(fileLocation,@old,@new) WHERE fileLocation LIKE CONCAT(@old,'%');
SELECT COUNT(*) FROM FileTranslations WHERE xliffLocation LIKE CONCAT(@old,'%');
UPDATE FileTranslations SET xliffLocation = REPLACE(xliffLocation,@old,@new) WHERE xliffLocation LIKE CONCAT(@old,'%');
SELECT COUNT(*) FROM FileTranslations WHERE exportUri LIKE CONCAT(@old,'%');
UPDATE FileTranslations SET exportUri = REPLACE(exportUri,@old,@new) WHERE exportUri LIKE CONCAT(@old,'%');
SELECT COUNT(*) FROM UserResources WHERE fileLocation LIKE CONCAT(@old,'%');
UPDATE UserResources SET fileLocation = REPLACE(fileLocation,@old,@new) WHERE fileLocation LIKE CONCAT(@old,'%');
SELECT COUNT(*) FROM UserResources WHERE xliff LIKE CONCAT(@old,'%');
UPDATE UserResources SET xliff = REPLACE(xliff,@old,@new) WHERE xliff LIKE CONCAT(@old,'%');
SELECT COUNT(*) FROM Estimates WHERE fileLocation LIKE CONCAT(@old,'%');
UPDATE Estimates SET fileLocation = REPLACE(fileLocation,@old,@new) WHERE fileLocation LIKE CONCAT(@old,'%');
SELECT COUNT(*) FROM DocumentIntermediateFiles WHERE storageLocation LIKE CONCAT(@old,'%');
UPDATE DocumentIntermediateFiles SET storageLocation = REPLACE(storageLocation,@old,@new) WHERE storageLocation LIKE CONCAT(@old,'%');
SELECT COUNT(*) FROM Projects WHERE exportURI LIKE CONCAT(@old,'%');
UPDATE Projects SET exportURI = REPLACE(exportURI,@old,@new) WHERE exportURI LIKE CONCAT(@old,'%');
SELECT COUNT(*) FROM Memories WHERE exportURI LIKE CONCAT(@old,'%');
UPDATE Memories SET exportURI = REPLACE(exportURI,@old,@new) WHERE exportURI LIKE CONCAT(@old,'%');
SELECT COUNT(*) FROM Jobs WHERE exportURI LIKE CONCAT(@old,'%');
UPDATE Jobs SET exportURI = REPLACE(exportURI,@old,@new) WHERE exportURI LIKE CONCAT(@old,'%');
SELECT COUNT(*) FROM Uploads WHERE fileLocation LIKE CONCAT(@old,'%');
UPDATE Uploads SET fileLocation = REPLACE(fileLocation,@old,@new) WHERE fileLocation LIKE CONCAT(@old,'%');
SELECT COUNT(*) FROM DocumentExports WHERE storageLocation LIKE CONCAT(@old,'%');
UPDATE DocumentExports SET storageLocation = REPLACE(storageLocation,@old,@new) WHERE storageLocation LIKE CONCAT(@old,'%');
SELECT COUNT(*) FROM JobExports WHERE storageLocation LIKE CONCAT(@old,'%');
UPDATE JobExports SET storageLocation = REPLACE(storageLocation,@old,@new) WHERE storageLocation LIKE CONCAT(@old,'%');
SELECT COUNT(*) FROM ProjectExports WHERE storageLocation LIKE CONCAT(@old,'%');
UPDATE ProjectExports SET storageLocation = REPLACE(storageLocation,@old,@new) WHERE storageLocation LIKE CONCAT(@old,'%');
SELECT COUNT(*) FROM MemoryExports WHERE storageLocation LIKE CONCAT(@old,'%');
UPDATE MemoryExports SET storageLocation = REPLACE(storageLocation,@old,@new) WHERE storageLocation LIKE CONCAT(@old,'%');

COMMIT;
```

If the census found legacy single-slash rows, normalise them to the double-slash form of the new bucket in the same transaction:

```sql theme={null}
SET @old1 = REPLACE(@old,'://',':/');
UPDATE Documents SET fileLocation  = REPLACE(fileLocation, @old1,@new) WHERE fileLocation  LIKE CONCAT(@old1,'%');
UPDATE Documents SET xliffLocation = REPLACE(xliffLocation,@old1,@new) WHERE xliffLocation LIKE CONCAT(@old1,'%');
UPDATE Files     SET fileLocation  = REPLACE(fileLocation, @old1,@new) WHERE fileLocation  LIKE CONCAT(@old1,'%');
```

#### JSON and text columns

Run a statement only if its census count was greater than zero. Check the column type first with `SHOW CREATE TABLE`: a JSON-typed column needs the `CAST(... AS JSON)` form so MySQL re-validates the document, while a TEXT column takes plain `REPLACE`. The replacement string contains no quotes or backslashes, so the JSON stays valid.

```sql theme={null}
-- TEXT column
UPDATE AsyncRequests SET requestMessage = REPLACE(requestMessage,@old,@new) WHERE requestMessage LIKE CONCAT('%',@old,'%');

-- JSON column
UPDATE AsyncRequests SET requestMessage = CAST(REPLACE(CAST(requestMessage AS CHAR),@old,@new) AS JSON) WHERE CAST(requestMessage AS CHAR) LIKE CONCAT('%',@old,'%');
```

The same two forms apply to `ScheduledEvents.payLoad`, `FileJobs.jobParams`, `UserNotifications.data`, `ExternalModels.providerConfig`, `ConnectorJobs.args`, and `Connectors.args`.

The neural tables need care. `NeuralBatchTranslationRequests.request` holds in-flight work only and is deleted on completion, and the batch workers cache these rows in memory at startup. Prefer draining the `neural.batch.*` queues so the rows finish or fail before the cutover. If rows must be rewritten, scale the neural batch workers to zero first.

## Columns to Leave Alone

These look like paths but are not bucket URIs. Do not rewrite them.

* `Users.imageURL`: an HTTP profile picture URL from the identity provider.
* `Documents.xliff`: inline XLIFF content on legacy rows, not a path.
* `Segments.*`: `xliffFileId` and `transUnitId` are XLIFF attributes.
* `NeuralBatchTranslationJobs.request`: `dataFilePath` is a bare key with no bucket.
* Neural model storage: bare keys under `model_storage_v4/` and `trained/`; the bucket comes from configuration.
* Redis upload hand-off keys hold full URIs but live only for one request. No flush is required.

## Configuration That Must Change

After the rewrite, every location that names the bucket must say the new name. A single global value can be shadowed by a stale per-service override, so check each one in the installer values file (`lilt/values.yaml` in the on-prem installer).

* Core services: `<alias>.onpremValues.app.args.bucket` for converter, tm, job, workflow, file-job, file-translation, segment, memory, and the rest.
* file-job and job: `onpremValues.env.BUCKETNAME`.
* core-api and dataflow: `BUCKETNAME` in `env`.
* front: `front.onpremValues.config.front_configmap_values.awsS3Bucket`. This key is not present in the installer values file by default and falls back to the chart default of `lilt`, so it must be added explicitly.
* neural: `<alias>.onpremValues.config.bucket` and `init.outputPath` (`s3://<new-bucket>/trained/`).
* core chart init containers: `init.outputPath` and `filePaths` for lexicon and file-job (`s3://<new-bucket>/lexicon-data/`, `s3://<new-bucket>/tesseract/`).

Redeploy, then re-run the census. Only the new bucket prefix should remain.

## Troubleshooting

**New work downloads but anything created before the move fails**: the rewrite was skipped or ran against the wrong database. Re-run the census.

**Downloads fail for one service only**: that service still carries the old bucket in a per-service override. Compare the rendered configuration of the failing service against a working one.

**Neural reports `Wrong bucket name`**: the neural `config.bucket` or `init.outputPath` was not updated, or the neural tables still hold old URIs from work that was in flight at the cutover.


# Resource Metrics
Source: https://support.lilt.com/self-managed/v6.1/resource-metrics



## Overview

Details of specific measurements used to assess and quantify the resource utilization of LILT applications. These metrics provide insights into the performance, capacity, and scalability requirements of the applications. They include parameters such as CPU utilization, memory consumption, disk size and concurrent user sessions. By establishing baseline measurements and setting thresholds, usage-sizing metrics help identify normal operating levels and define boundaries for resource usage. These metrics enable proactive capacity planning, resource optimization, and the ability to detect anomalies or performance bottlenecks.

The table below is meant to be a reference guide, and not an exact match to your individual environment, as each installation may choose to enable or disable specific services.

## Usage-Sizing Metrics

| **App Name** | **Min Recommended vCPUs** | **Max Recommended vCPUs** | **Min Recommended Memory (GB)** | **Max Recommended Memory (GB)** | **GPU Requirements** |
| - | - | - | - | - | - |
| **Web Application Services** | | | | | |
| Front | 0.5 | 2 | 4 | 8 | |
| Beehive | 0.1 | 4 | 4 | 4 | |
| **Core Translation Services** | | | | | |
| Core-api | 0.01 | 0.1 | 0.256 | 0.256 | |
| Converter | 1 | 12 | 26 | 28 | |
| QA | 0.5 | 1 | 3 | 4 | |
| Linguist | 0.5 | 1 | 1 | 2 | |
| Search | 0.05 | n/a | 21 | 22 | |
| TM | 4 | 12 | 30 | 32 | |
| TB | 1 | n/a | 30 | 30 | |
| Batch-TB | 2 | 7 | 22 | 30 | |
| Indexer | 0.05 | n/a | 21 | 22 | |
| Watchdog | 0.1 | n/a | 2 | 3 | |
| Segment | 0.5 | 2 | 4 | 4 | |
| File-translation | 3 | 6 | 14 | 15 | |
| Job | 0.5 | 1 | 2 | 3.5 | |
| Tag | 0.5 | 1 | 2 | 3.5 | |
| Auditlog | 0.5 | 1 | 2 | 3.5 | |
| Assignment | 1 | 2 | 4 | 4 | |
| Workflow | 1 | 2 | 2 | 2 | |
| File-job | 2 | 4 | 16 | 16 | |
| Memory | 1 | 2 | 4 | 4.5 | |
| Notification | 0.5 | n/a | 2 | 4 | |
| Auth | 0.01 | n/a | 0.5 | 1 | |
| **Neural/ML Services** | | | | | |
| Translatev4\*\*\*\* | 0.7 | 0.7 | 32 | 32 | 2 GPUs |
| Updatev4 | 0.6 | 0.6 | 38 | 38 | |
| Langid | 0.5 | 3 | 5 | 5 | |
| Update-managerv4 | 0.4 | 0.4 | 2.5 | 2.5 | |
| Routing | 0.1 | 0.35 | 1.5 | 1.5 | |
| Batchv4 | 0.25 | 0.5 | 2 | 2 | |
| Batch-worker-gpuv4\*\*\*\* | 1.2 | 1.2 | 18 | 19 | 1 GPU |
| Batch-worker-cpu-3pmt | 5 | 5 | 18 | 18 | |
| Llama-vllm-inference\*\*\*\* | 5 | 14 | 100 | 100 | 4 GPUs |
| LLM-inference-whisper\*\*\*\* | 1 | n/a | 8 | 8 | 1 GPU |
| Gemma-vllm-inference\*\*\*\* | 12 | 12 | 80 | 80 | 2 GPUs |
| Automqm | 0.4 | 0.4 | 3 | 3 | |
| Alignment | 0.7 | 0.7 | 13 | 13 | |
| Tag-projection | 0.8 | 0.8 | 6 | 6 | |
| NNcache | 0.5 | 0.5 | 5 | 5 | |
| VMF (Vector Manipulation) | 2 | 4 | 8 | 8 | |
| Rayman\*\*\*\* | 6 | 12 | 24 | 72 | 1 GPU (+1 optional) |
| **Connectors Platform** | | | | | |
| Connectors-ingressgateway | 0.1 | 2 | 0.128 | 1 | |
| Connectors-builder | n/a | n/a | n/a | n/a | |
| **Infrastructure Services** | | | | | |
| nginx-ingress | 0.1 | n/a | 0.128 | n/a | |
| istiod | 0.5 | 0.5 | 2 | 2 | |
| istio-ingressgateway | 0.1 | 2 | 0.128 | 1 | |
| Qdrant\*\*\* | 4 | n/a | 12 | 12 | |
| Prometheus | n/a | 0.5 | n/a | 2 | |
| Grafana | n/a | 0.5 | n/a | 0.5 | |
| **Data Stores** | | | | | |
| Redis | 0.2 | 0.6 | 4 | 10 | |
| RabbitMQ | 1 | 2 | 4 | 4 | |
| MySQL | 0.5 | n/a | 4 | 8 | |
| MongoDB | 0.5 | 0.5 | 0.5 | 0.5 | |
| MinIO | 0.1 | 0.5 | 1 | 1.5 | |
| ClickHouse | 0.5 | n/a | 1 | 16 | |
| Elasticsearch\*\*\* | 1 | 2 | 4 | 4 | |
| **Total\*** | **49.77 vCPUs** | **147.25 vCPUs** | **633.884 GB RAM** | **748.756 GB RAM** | **11 GPUs** |
| **Total Disk Requirements\*** | **1 TB minimum** | | | | |

###### \*The following specifications are recommended for installing LILT on bare-metal hardware to support the given applications. It is important to note that these specifications may need to be adjusted based on the specific load requirements.

###### \*\*To efficiently handle parallel batch requests, it is recommended to have the same number of GPUs as the number of required concurrent batch requests. This enables the system to effectively distribute the workload and process multiple requests simultaneously, leveraging the processing power of each GPU to improve throughput.

###### \*\*\* These values may be doubled when multiple replicas are configured

###### \*\*\*\* These pods require GPU nodes for operation

###### Rayman is the neural translation service on Ray (Ray Serve / KubeRay). It runs on a single GPU by default; the neural v4.0 pipeline that provides optional Uzbek and Chechen language support (replacing the former Emma model) requires one additional GPU. vCPU and memory ranges reflect the combined Ray head, application, and model worker groups.

###### n/a marked services have no specified limit in the configuration and can use available resources on the node. Services marked with n/a for both min and max have no explicit resource specifications defined in the helm charts and will use default values.


# Restore From Backup
Source: https://support.lilt.com/self-managed/v6.1/restore-from-backup



## Restoration

Restores the system to a backed-up version.

#### **node**

Copy the backup of \$shared\_storage/PVC(s) to newly created PVCs, overwriting existing files.

Ensure file permissions are not getting updated.

For this you need to find which PVC belongs to a service, please find it by running below command in k8s-master.

`$ kubectl get pvc -n lilt`

*Alternatively, we can import the database from backup.sql and content of minio-pvc only as that contains the required trained data, memory and documents. Do that by running below command on the master server*

`$ mysql -u [user] -p [database_name] < [backup].sql`

#### **master**

Restart pods by running:

`$ kubectl get pods -n lilt | awk '{print $1}' | grep -v NAME | xargs kubectl delete pods -n lilt`

#### **Verification**

Browse the application and ensure all data has been restored.


# Secrets And Vault
Source: https://support.lilt.com/self-managed/v6.1/secrets-and-vault



LILT reads its application secrets from one of three places. This article covers how to choose, what the shipped in-cluster Vault does, and how to point LILT at a secret manager you already run.

## Choose a Backend

`SECRET_BACKEND` in `install.env` selects the source.

| Value | Source | Available on |
| - | - | - |
| `seed` (default) | The secrets file that ships in the tarball | Both flavors |
| `vault` | HashiCorp Vault, through External Secrets Operator | EKS |
| `aws` | AWS Secrets Manager, through External Secrets Operator | EKS |

<Warning>
  External Secrets Operator is installed only on the EKS path. `install-lilt.sh` never calls `install-external-secrets.sh`, and the `external-secrets` component is not in the on-premises tarball. On an on-premises install, `SECRET_BACKEND` has no effect and secrets always come from the seed file.
</Warning>

## Seed Mode

With `SECRET_BACKEND=seed`, secrets come from `lilt/environments/seed_custom_values/secrets.yaml` on the on-premises flavor and `eks-secrets.yaml` on EKS. The installer copies that file to `lilt/environments/<ENV_NAME>/secrets.yaml`, where `ENV_NAME` defaults to `lilt`.

<Warning>
  The shipped values are placeholders, most of them the literal string `dummypass`. They let a fresh cluster start without a secret manager. Do not run a production install with them.
</Warning>

The two flavors differ in how the copy behaves on a re-run:

* **On-premises** seeds the file only if it does not already exist, so your edits survive.
* **EKS** overwrites it from the seed file on **every** run while `SECRET_BACKEND=seed`. Edits do not persist. To manage EKS secrets outside the tarball, use `vault` or `aws`.

<Warning>
  On EKS the AWS credential fields are intentionally empty. Workload identity supplies them. A static value there overrides the role and breaks S3 access.
</Warning>

## The Shipped Vault

`ENABLE_VAULT` defaults to `true`, so both flavors install a single-node HashiCorp Vault into a namespace called `vault`, backed by a 10 GiB Raft volume.

| | On-premises | EKS |
| - | - | - |
| Seal mode | Shamir, one key share | AWS KMS auto-unseal |
| Unseal after a restart | Manual, or re-run the bootstrap script | Automatic |
| Consumed by ESO | No — ESO is not on this path | Yes, this is the default backend |

Override the seal mode with `VAULT_SEAL_MODE`. Setting `shamir` on EKS is supported: the installer strips the KMS seal stanza before it installs.

### Initialisation and Unseal

`vault-bootstrap.sh` runs after the pod starts, gated by `ENABLE_VAULT_BOOTSTRAP` (default `true`). It initialises Vault, enables the KV v2 mount, configures Kubernetes auth, and unseals.

<Warning>
  The initialisation output, which contains the unseal key and the root token, is written to a Kubernetes Secret named `vault-init` in the `vault` namespace. Nothing is printed and nothing is written to disk.

  Anyone who can read that Secret can unseal Vault and mint tokens. Restrict access to it, back it up somewhere outside the cluster, and treat losing it as losing the Vault. Once you have another way in, such as userpass or OIDC auth, revoke the root token.
</Warning>

On an on-premises install, a pod restart or a node drain brings Vault back **sealed**. A sealed pod is `Running` but not `Ready`. The bootstrap runs at install time only, so nothing unseals it automatically. Re-run `sh install_scripts/vault-bootstrap.sh`, which is idempotent, or unseal manually. On EKS, KMS auto-unseal handles this.

### How ESO Reads It

On EKS the installer creates a `ClusterSecretStore` pointing at `http://vault.vault.svc.cluster.local:8200`, authenticating with the Kubernetes auth method as the `external-secrets` service account against a Vault role named `eso`. That role's policy grants read-only access to the KV mount.

| Setting | Variable | Default |
| - | - | - |
| KV mount | `VAULT_KV_MOUNT` | `lilt` |
| Vault role for ESO | `VAULT_ESO_ROLE` | `eso` |
| Auth method | `VAULT_AUTH` | `kubernetes` |
| Path prefix for secrets | `BASE_VAULT_PATH` | `lilt/bare/aws` |

Set `BASE_VAULT_PATH` to a prefix that suits your environment, for example `lilt/prod/aws`.

## What Vault Must Contain

Paths are `BASE_VAULT_PATH` plus the suffix below. These are KV v2 mounts: the `data/` infix appears in the API path but not in the `vault kv` CLI, so `vault kv get lilt/prod/aws/mysql` addresses what ESO calls `lilt/data/prod/aws/mysql`.

| Path suffix | Keys | Where the value comes from |
| - | - | - |
| `mysql` | `username`, `mysql-password`, `host` | Must match the `lilt` user the installer creates and your database endpoint. Derived, not invented. |
| `mongodb` | `mongodb-password`, `mongodb-root-password` | Generate |
| `rabbitmq` | `password`, `cookie` | Generate. `cookie` is the Erlang cluster cookie. |
| `clickhouse` | `password` | Generate |
| `cache-redis` | `password` | Generate |
| `common/auth` | `auth_jwt_secret`, `passport_secret`, `SINGLE_OIDC_PROVIDER_CLIENT_SECRET` | Generate the first two. The third comes from your identity provider. |
| `common/api-keys` | `apryse_key`, `apryse_docx_key`, `llm_api_key`, `oidc_client_secret` | All external: your Apryse licence, your LLM provider, your identity provider. |
| `common/connectors` | `CONNECTORS_ADMIN_PASSWORD`, `manager_ui_secret_key`, `webhook_auth_token` | Generate |
| `common/smtp` | `smtp_password` | Your SMTP provider |

`datadog` with key `api_key` is seeded too, but only matters if you enable Datadog.

External Secrets Operator reads secrets. It never creates them. Every path must exist before you install.

### Overriding a Single Path

Each secret has its own `<NAME>_SECRET_PATH` variable that overrides the derived path. The variable is named after the secret rather than the path suffix, which is easy to get wrong for the `common/` entries.

| Variable | Overrides |
| - | - |
| `MYSQL_SECRET_PATH` | `mysql` |
| `MONGODB_SECRET_PATH` | `mongodb` |
| `RABBITMQ_SECRET_PATH` | `rabbitmq` |
| `CLICKHOUSE_SECRET_PATH` | `clickhouse` |
| `CACHE_REDIS_SECRET_PATH` | `cache-redis` |
| `DATADOG_SECRET_PATH` | `datadog` |
| `AUTH_SECRET_PATH` | `common/auth` |
| `API_KEYS_SECRET_PATH` | `common/api-keys` |
| `CONNECTORS_SECRET_PATH` | `common/connectors` |
| `SMTP_SECRET_PATH` | `common/smtp` |
| `RDS_CA_SECRET_PATH` | The RDS CA bundle |
| `LILT_SECRETS_SECRET_PATH` | The composed `lilt-secrets` secret |

## Seed the Paths

`install_scripts/seed-vault-secrets.sh` creates every path with a placeholder, so a first install does not fail one missing key at a time. It derives the path and key list from the same ExternalSecret manifests the operator reads, so it cannot drift from what LILT actually asks for.

Authenticate to the target Vault first, with `VAULT_ADDR` set, then run it from the tarball root:

```bash theme={null}
BASE_VAULT_PATH=lilt/prod/aws sh install_scripts/seed-vault-secrets.sh           # report only
BASE_VAULT_PATH=lilt/prod/aws sh install_scripts/seed-vault-secrets.sh --apply   # write
```

The script is non-destructive. It writes only keys that are missing and leaves existing values alone, so re-running it never overwrites a real secret with a placeholder.

Two behaviours worth knowing:

* Values default to the literal `REPLACE_ME`. Override with `PLACEHOLDER`, or set `SEED_RANDOM=true` to generate a random value per key, for an install that has to come up unattended.
* The `mysql` path is the exception. Its `username`, `mysql-password`, and `host` are taken from the database user the installer actually creates, because ESO feeds them to every application and they have to match.

After the install, replace every remaining placeholder with a real value.

## Use Your Own Vault

To point LILT at a Vault you already run, set `SECRET_BACKEND=vault` and `VAULT_AUTH=approle`, with `VAULT_ADDR` pointing at your server.

AppRole authentication needs a Kubernetes Secret named `vault-approle` in the `external-secrets` namespace, holding the keys `role-id` and `secret-id`. Create it before you install:

```bash theme={null}
kubectl create secret generic vault-approle \
  --namespace external-secrets \
  --from-literal=role-id=<your-role-id> \
  --from-literal=secret-id=<your-secret-id>
```

The installer never creates this Secret and stops if it is missing. There are no `VAULT_ROLE_ID` or `VAULT_SECRET_ID` variables: keeping the credentials out of `install.env` keeps them out of a file that could be committed.

<Warning>
  Your own Vault and the shipped in-cluster Vault are mutually exclusive. Two secret stores of the same name must never both be active on one cluster. Set `ENABLE_VAULT=false` when you use your own.
</Warning>

## Use AWS Secrets Manager

Set `SECRET_BACKEND=aws`. External Secrets authenticates with workload identity as the `external-secrets` service account in the `external-secrets` namespace. The same path and key table applies, under the prefix you set.

If you provision with the LILT Terraform module, grant that access with `enable_eso_aws_sm = true` and scope it with `eso_aws_sm_secret_prefix`. That role binds the service account External Secrets actually runs as, and its trust policy follows `iam_auth_method`.

<Warning>
  Do not use `enable_external_secrets = true` for this. It creates an older, overlapping role whose Pod Identity association binds a service account named `external-secrets-sa`, which is not the name the External Secrets chart creates, and whose trust policy is hard-coded to Pod Identity regardless of `iam_auth_method`. Nothing errors: the role and the association are created and simply never attach to a pod, and External Secrets then fails with an access-denied error that does not mention the mismatch.
</Warning>

## Turn the Shipped Vault Off

`ENABLE_VAULT=false` skips the Vault install entirely. With `SECRET_BACKEND` left unset it falls back to seed mode, which is the safe default.

<Warning>
  Nothing guards the combination `ENABLE_VAULT=false` with `SECRET_BACKEND=vault` and the default `VAULT_AUTH=kubernetes`. The installer then points External Secrets at an in-cluster Vault that was never installed, and the install fails at the point where it waits for the first ExternalSecret to become ready. If you disable the shipped Vault, set `SECRET_BACKEND` to `seed` or `aws`, or use `VAULT_AUTH=approle` with your own server.
</Warning>

## The Vault UI

`ENABLE_VAULT_UI` defaults to `false`. Setting it to `true` publishes the Vault UI on its own hostname, `vault.<SUBDOMAIN>.<DNS_DOMAIN>` by default, overridable with `VAULT_UI_HOST`.

It needs a hostname of its own because the Vault UI serves only at the root with absolute asset paths, so it cannot live under a path prefix.

Enabling it requires a DNS record for that hostname and a TLS certificate that covers it. See [Set custom domain and certificates](/self-managed/v6.1/set-custom-domain-and-certificates). Without both, use a port-forward instead:

```bash theme={null}
kubectl port-forward -n vault svc/vault-ui 8200:8200
```

## Related Articles

* [Install System (AWS EKS)](/self-managed/v6.1/install-system-aws-eks)
* [Set custom domain and certificates](/self-managed/v6.1/set-custom-domain-and-certificates)
* [GPU profiles and values overlays](/self-managed/v6.1/gpu-profiles-and-values-overlays)


# Self-Managed Hardware Requirements
Source: https://support.lilt.com/self-managed/v6.1/self-managed-hardware-requirements



LILT can be installed on custom hardware in a private data center or on major cloud platforms. The tables below provide approximate monthly cost estimates for running the base LILT system V4 models in a cloud environment.

These estimates include long-term pricing discounts where applicable. However, resources (especially storage) may need to be increased to suit your needs. These costs reflect the cloud platform vendor's pricing at the time of publication and are not guaranteed.

Network, bandwidth, security groups, permission management, and other platform costs are not included in these estimates.

Interested in installing LILT's self-managed solution? [Contact Sales](https://lilt.com) from the LILT homepage.

<Warning>
  **Plan for two environments.** A standard self-managed installation includes **two separate environments — one test and one production**. The test environment lets you validate upgrades, configuration changes, and integrations before promoting them to production. Because it mirrors the production footprint, budget for **roughly double** the total cloud costs shown in the estimates below, which reflect a single environment.
</Warning>

## GPU Requirements by Service

The sizings on this page are for **LILT 6.1.0**. Every LILT feature that uses a GPU is backed by one or more of the services below; a feature runs only when each of its services can be placed on your GPU nodes.

| Service | Powers | VRAM (on one node) | Min. compute capability | Node RAM | CPU fallback |
| - | - | - | - | - | - |
| rayman 3.5 | Translation (base language pairs) | 22 GB | 8.0 (Ampere or newer) | 60 GB | No |
| rayman 4.0 | Translation, V4 language pairs (Uzbek, Chechen) | 22 GB, one extra GPU on top of rayman 3.5 | 8.0 (Ampere or newer) | 60 GB | No |
| batch-worker-gpu | Batch translation (jobs over \~3,000 segments) | 15 GB | 7.5 | 30 GB | No |
| whisper | ASR | 15 GB | 7.5 | 20 GB | Yes (slower) |
| whisper + Sorani | ASR, Sorani (Kurdish) model loaded in the same pod | 25 GB | 7.5 | 20 GB | No |
| gemma | OCR, AI Review, LILT Create | 45 GB | 8.9 (Ada or newer) | 80 GB | OCR only (Tesseract) |
| updatev4 | Adaptive translation model updates | None by default (CPU) | n/a | 38 GB | Yes, CPU is the default; GPU is optional and requires LILT configuration |

Placement rules:

* **Whole GPUs, no sharing.** Each service takes its GPUs entirely; leftover VRAM on a card cannot host another service.
* **VRAM adds up only within one node.** A 45 GB requirement is met by one 48 GB card or by two 24 GB cards in the same server, never by cards on different servers. One large card can replace several small ones.
* **Compute capability is a gate, not a size.** T4 (7.5) clears the batch worker and ASR but not rayman, however much VRAM the node has. Reference values: T4 7.5, A100 8.0, A10/A6000 8.6, L4/L40S 8.9, H100 9.0.
* **Ampere and Gemma.** Ampere cards (8.0 to 8.6: A100, A10, A6000) run Gemma at reduced throughput but are not enabled by the default installer; ask LILT before sizing Gemma on Ampere.
* **One large card for Gemma.** On-prem installs default to two 24 GB cards for Gemma. A single card of 48 GB or more is supported by applying the `gemma-single-large` GPU profile shipped with the installer; EKS installs default to the single-card sizing.

## Recommended Production Configurations (AWS EKS)

The following are reference sizings for AWS EKS production deployments, based on configurations validated with LILT EKS customers. Three tiers are offered — **Standard ★**, **Medium**, and **Large** — sized to the number of concurrent users. Unless noted, a component matches the Standard tier. For a detailed per-resource cost breakdown, see the [AWS EKS](#aws-eks) section below.

<table>
  <tbody>
    <tr>
      <td>
        <p><strong>Prod environment — three tier options</strong></p>
      </td>
    </tr>

    <tr>
      <td>
        <p><strong>Prod component</strong></p>
      </td>

      <td>
        <p><strong>Standard ★</strong></p>
      </td>

      <td>
        <p><strong>Medium</strong></p>
      </td>

      <td>
        <p><strong>Large</strong></p>
      </td>
    </tr>

    <tr>
      <td>
        <p><em>Concurrent users supported</em></p>
      </td>

      <td>
        <p><strong>30–50</strong></p>
      </td>

      <td>
        <p><strong>100–150</strong></p>
      </td>

      <td>
        <p><strong>150+</strong></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Database node</p>
      </td>

      <td>
        <p>RDS: db.m5d.xlarge</p>
      </td>

      <td>
        <p>Same as Standard</p>
      </td>

      <td>
        <p>Same as Standard</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Translate / Uzbek-Chechen (rayman v4.0) / OCR + AI Review / LILT Create (Gemma)</p>
      </td>

      <td>
        <p>1× g6e.12xlarge (4× L40S, 48 vCPU, 384 GB)</p>
      </td>

      <td>
        <p>Same as Standard</p>
      </td>

      <td>
        <p>1× g6e.24xlarge (4× L40S, 96 vCPU, 768 GB)</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Batch / Whisper</p>
      </td>

      <td>
        <p>1× g6.24xlarge (4× L4, 96 vCPU, 384 GB)</p>
      </td>

      <td>
        <p>Same as Standard</p>
      </td>

      <td>
        <p>Same as Standard</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Worker Node</p>
      </td>

      <td>
        <p>none</p>
      </td>

      <td>
        <p>1× m5.8xlarge (32 vCPU, 128 GB)</p>
      </td>

      <td>
        <p>none</p>
      </td>
    </tr>

    <tr>
      <td>
        <p><em>Total instances</em></p>
      </td>

      <td>
        <p><strong>2</strong></p>
      </td>

      <td>
        <p><strong>3</strong></p>
      </td>

      <td>
        <p><strong>2</strong></p>
      </td>
    </tr>
  </tbody>
</table>

<Note>
  ★ The **Standard** tier is the recommended default starting point for most deployments. As your usage grows, you can scale up to the **Medium** and **Large** tiers as needed.
</Note>

## Cloud Provider Cost Estimates

* [AWS Commercial](#aws-commercial)
* [AWS Top Secret](#aws-top-secret)
* [AWS EKS](#aws-eks)
* [GCP](#gcp)
* [Microsoft Azure](#microsoft-azure)

## AWS Commercial

##### Last Revised: 23 Jul 2026

<table>
  <tbody>
    <tr>
      <td>
        <p><strong>AWS Commercial</strong></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Platform</p>
      </td>

      <td>
        <p>Resource Identifier</p>
      </td>

      <td>
        <p>Specifications</p>
      </td>

      <td>
        <p>Quantity</p>
      </td>

      <td>
        <p>Unit</p>
      </td>

      <td>
        <p>Unit cost<sup> \[1]</sup></p>
      </td>

      <td>
        <p>Cost <sup>\[2]</sup> per month</p>
      </td>

      <td>
        <p>Cost <sup>\[3]</sup> per month</p>
      </td>

      <td>
        <p>Notes</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>AWS</p>
      </td>

      <td>
        <p>m5.xlarge</p>
      </td>

      <td>
        <p>4vCPU / 16G RAM / 200GB</p>
      </td>

      <td>
        <p>1</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$0.192</p>
      </td>

      <td>
        <p>\$118.93</p>
      </td>

      <td>
        <p>\$104.33</p>
      </td>

      <td>
        <p>K8s Master</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>AWS</p>
      </td>

      <td>
        <p>r5.16xlarge</p>
      </td>

      <td>
        <p>64vCPU / 512G RAM / 1TB</p>
      </td>

      <td>
        <p>2</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$8.064</p>
      </td>

      <td>
        <p>\$4,584.66</p>
      </td>

      <td>
        <p>\$4,028.40</p>
      </td>

      <td>
        <p>K8s Nodes</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>AWS</p>
      </td>

      <td>
        <p>g6.12xlarge</p>
      </td>

      <td>
        <p>4 L4 GPUs <sup>\[4]</sup> / 48vCPU / 192G RAM / 2TB / 96GiB VRAM</p>
      </td>

      <td>
        <p>1</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$4.60</p>
      </td>

      <td>
        <p>\$2,893.52</p>
      </td>

      <td>
        <p>\$2,346.82</p>
      </td>

      <td>
        <p>Standard Services (Translate, Batch)</p>
      </td>
    </tr>

    <tr>
      <td>
        <p><strong>Total Cost</strong></p>
      </td>

      <td>
        <p><strong>All v4 lang-pairs with standard service</strong></p>
      </td>

      <td>
        <p><strong>\$12.86</strong></p>
      </td>

      <td>
        <p><strong>\$7,597.11</strong></p>
      </td>

      <td>
        <p><strong>\$6,479.55</strong></p>
      </td>

      <td>
        <p />
      </td>
    </tr>

    <tr>
      <td>
        <p>AWS</p>
      </td>

      <td>
        <p>g6e.4xlarge (Optional)</p>
      </td>

      <td>
        <p>1 L40S GPU / 16vCPU / 128G RAM / 2TB / 48 GiB VRAM</p>
      </td>

      <td>
        <p>1</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$3.00</p>
      </td>

      <td>
        <p>\$1,817.98</p>
      </td>

      <td>
        <p>\$1,541.65</p>
      </td>

      <td>
        <p>OCR + AI Review / LILT Create (Gemma)</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>AWS</p>
      </td>

      <td>
        <p>g4dn.2xlarge (Optional)</p>
      </td>

      <td>
        <p>1 T4 GPU / 8vCPU / 32G RAM / 1TB / 16 GiB VRAM</p>
      </td>

      <td>
        <p>1</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$0.752</p>
      </td>

      <td>
        <p>\$477.85</p>
      </td>

      <td>
        <p>\$426.02</p>
      </td>

      <td>
        <p>ASR (Whisper)</p>
      </td>
    </tr>

    <tr>
      <td>
        <p><strong>Total Cost (incl. optional services)</strong></p>
      </td>

      <td>
        <p><strong>Standard service + OCR/AI Review/Create & ASR</strong></p>
      </td>

      <td>
        <p><strong>\$16.61</strong></p>
      </td>

      <td>
        <p><strong>\$9,892.94</strong></p>
      </td>

      <td>
        <p><strong>\$8,447.22</strong></p>
      </td>

      <td>
        <p />
      </td>
    </tr>
  </tbody>
</table>

## AWS Top Secret

##### Last Revised: 9 Feb 2026

<table>
  <tbody>
    <tr>
      <td>
        <p><strong>AWS Top Secret</strong></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Platform</p>
      </td>

      <td>
        <p>Resource Identifier</p>
      </td>

      <td>
        <p>Specifications</p>
      </td>

      <td>
        <p>Quantity</p>
      </td>

      <td>
        <p>Unit</p>
      </td>

      <td>
        <p>Unit cost<sup> \[1]</sup></p>
      </td>

      <td>
        <p>Cost <sup>\[2]</sup> per month</p>
      </td>

      <td>
        <p>Notes</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>AWS</p>
      </td>

      <td>
        <p>m5.xlarge</p>
      </td>

      <td>
        <p>4vCPU / 16G RAM / 200GB</p>
      </td>

      <td>
        <p>1</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$0.45</p>
      </td>

      <td>
        <p>\$260.90</p>
      </td>

      <td>
        <p>K8s Master</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>AWS</p>
      </td>

      <td>
        <p>r5.16xlarge</p>
      </td>

      <td>
        <p>64vCPU / 512G RAM / 1TB</p>
      </td>

      <td>
        <p>2</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$15.42</p>
      </td>

      <td>
        <p>\$8,199.32</p>
      </td>

      <td>
        <p>K8s Nodes</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>AWS</p>
      </td>

      <td>
        <p>g6.12xlarge</p>
      </td>

      <td>
        <p>4 L4 GPUs <sup>\[4]</sup> / 48vCPU / 192G RAM / 2TB / 96 GiB VRAM</p>
      </td>

      <td>
        <p>1</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$9.24</p>
      </td>

      <td>
        <p>\$5,694.56</p>
      </td>

      <td>
        <p>Standard Services (Translate, Batch)</p>
      </td>
    </tr>

    <tr>
      <td>
        <p><strong>Total Cost</strong></p>
      </td>

      <td>
        <p><strong>All v4 lang-pairs with standard service</strong></p>
      </td>

      <td>
        <p><strong>\$25.11</strong></p>
      </td>

      <td>
        <p><strong>\$14,154.78</strong></p>
      </td>

      <td>
        <p />
      </td>
    </tr>

    <tr>
      <td>
        <p>AWS</p>
      </td>

      <td>
        <p>g6e.4xlarge (Optional)</p>
      </td>

      <td>
        <p>1 L40S GPU / 16vCPU / 128G RAM / 2TB / 48 GiB VRAM</p>
      </td>

      <td>
        <p>1</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$6.03</p>
      </td>

      <td>
        <p>\$3,532.53</p>
      </td>

      <td>
        <p>OCR + AI Review / LILT Create (Gemma)</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>AWS</p>
      </td>

      <td>
        <p>g4dn.2xlarge (Optional)</p>
      </td>

      <td>
        <p>1 T4 GPU / 8vCPU / 32G RAM / 1TB / 16 GiB VRAM</p>
      </td>

      <td>
        <p>1</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$1.62</p>
      </td>

      <td>
        <p>\$958.48</p>
      </td>

      <td>
        <p>ASR (Whisper)</p>
      </td>
    </tr>

    <tr>
      <td>
        <p><strong>Total Cost (incl. optional services)</strong></p>
      </td>

      <td>
        <p><strong>Standard service + OCR/AI Review/Create & ASR</strong></p>
      </td>

      <td>
        <p><strong>\$32.76</strong></p>
      </td>

      <td>
        <p><strong>\$18,645.79</strong></p>
      </td>

      <td>
        <p />
      </td>
    </tr>
  </tbody>
</table>

## AWS EKS

##### Last Revised: 23 Jul 2026

<table>
  <tbody>
    <tr>
      <td>
        <p><strong>AWS EKS</strong></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Platform</p>
      </td>

      <td>
        <p>Resource Identifier</p>
      </td>

      <td>
        <p>Specifications</p>
      </td>

      <td>
        <p>Quantity</p>
      </td>

      <td>
        <p>Unit</p>
      </td>

      <td>
        <p>Unit cost<sup> \[1]</sup></p>
      </td>

      <td>
        <p>Cost <sup>\[3]</sup> per month</p>
      </td>

      <td>
        <p>Notes</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>AWS</p>
      </td>

      <td>
        <p>Amazon EKS</p>
      </td>

      <td>
        <p>N/A</p>
      </td>

      <td>
        <p>1</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$0.10</p>
      </td>

      <td>
        <p>\$73.00</p>
      </td>

      <td>
        <p>EKS Control Plane</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>AWS</p>
      </td>

      <td>
        <p>RDS db.m5d.xlarge</p>
      </td>

      <td>
        <p>4vCPU / 16G RAM</p>
      </td>

      <td>
        <p>1</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$0.419</p>
      </td>

      <td>
        <p>\$305.87<sup> \[5]</sup></p>
      </td>

      <td>
        <p>Database node (RDS)</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>AWS</p>
      </td>

      <td>
        <p>g6e.12xlarge</p>
      </td>

      <td>
        <p>4 L40S GPUs / 48vCPU / 384G RAM / 2TB / 192 GiB VRAM</p>
      </td>

      <td>
        <p>1</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$10.49</p>
      </td>

      <td>
        <p>\$5,384.70</p>
      </td>

      <td>
        <p>Translate / Uzbek-Chechen (rayman v4.0) / OCR + AI Review / LILT Create (Gemma)</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>AWS</p>
      </td>

      <td>
        <p>g6.24xlarge</p>
      </td>

      <td>
        <p>4 L4 GPUs / 96vCPU / 384G RAM / 2TB / 96 GiB VRAM</p>
      </td>

      <td>
        <p>1</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$6.68</p>
      </td>

      <td>
        <p>\$3,404.58</p>
      </td>

      <td>
        <p>Batch / Whisper (ASR)</p>
      </td>
    </tr>

    <tr>
      <td>
        <p><strong>Total Cost</strong></p>
      </td>

      <td>
        <p><strong>All v4 lang-pairs with standard service</strong></p>
      </td>

      <td>
        <p><strong>\$17.69</strong></p>
      </td>

      <td>
        <p><strong>\$9,168.15</strong></p>
      </td>

      <td>
        <p />
      </td>
    </tr>
  </tbody>
</table>

<Note>
  \[1] Price calculated for plan: "On-Demand Instances"

  \[2] Price calculated for plan: "Compute Savings Plans" (1 year)

  \[3] Price calculated for plan: "EC2 Instance Savings Plans" (1 year)

  \[4] The standard services require 3 × L4 GPUs (or other 24 GB cards with compute capability 8.0 or higher). T4 GPUs cannot run the translation inference server (rayman), which requires an Ampere-or-newer GPU with at least 22 GB of VRAM; T4 remains valid for the batch worker and ASR. AWS does not currently offer an instance type with exactly 3 x L4 GPUs, so g6.12xlarge (4 × L4) is recommended as the closest available option. Please choose the available instance type best suited to your infrastructure.

  \[5] RDS is priced at On-Demand; the EC2 Instance Savings Plan does not apply to Amazon RDS. A separate RDS Reserved Instance (1 year) would lower this line item.

  Sources:

  * Commercial: [AWS Commercial Estimate](https://calculator.aws/#/estimate?id=7ba8faa2c2f52dd20d5982c5c9f49ad2aa5b5581)

  * Top Secret: [AWS Top Secret Estimate](https://calculator.aws/#/estimate?ctrct=5423f8cd3b711c6f899ba4dade31b50c\&id=d2613478b80f403351e723e764682503b4fe20ed)

  * EKS: [AWS EKS Estimate](https://calculator.aws/#/estimate?id=a0a7b163ee2bb9b8cd212f2a9b34f88afad3c3c8)

  <strong>Recommended EKS deployment</strong><br />
  This EKS table follows the Standard tier of the Recommended Production Configurations table above: the platform runs on two GPU nodes (`g6e.12xlarge` for Translate, Uzbek-Chechen rayman v4.0 and OCR; `g6.24xlarge` for Batch and Whisper/ASR), backed by an RDS database node — no separate CPU worker node is required at this tier.

  <strong>Optional GPU-Accelerated Services</strong><br />

  * AI Review & LILT Create — Served by the same Gemma deployment as OCR on the `g6e.12xlarge` node; no additional instance is required.
  * OCR (Gemma) and ASR (Whisper) — In this configuration these are co-located on the standard GPU nodes above and do not require additional instances. ASR with the Sorani (Kurdish) model needs 25 GB of VRAM on one node and has no CPU fallback.
  * Uzbek and Chechen Language Support — Provided through the neural v4.0 pipeline in rayman (which replaces the former dedicated Emma model), co-located on the `g6e.12xlarge` node.
</Note>

## GCP

##### Last Revised: 23 Jul 2026

<table>
  <tbody>
    <tr>
      <td>
        <p><strong>GCP</strong></p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Platform</p>
      </td>

      <td>
        <p>Resource Identifier</p>
      </td>

      <td>
        <p>Specifications</p>
      </td>

      <td>
        <p>Quantity</p>
      </td>

      <td>
        <p>Unit</p>
      </td>

      <td>
        <p>Unit cost<sup> \[1]</sup></p>
      </td>

      <td>
        <p>Cost <sup>\[1]</sup> per month</p>
      </td>

      <td>
        <p>Cost <sup>\[2]</sup> per month</p>
      </td>

      <td>
        <p>Notes</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>GCP</p>
      </td>

      <td>
        <p>n1-standard-4</p>
      </td>

      <td>
        <p>4vCPU / 15G RAM / 500GB</p>
      </td>

      <td>
        <p>1</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$0.19</p>
      </td>

      <td>
        <p>\$138.70</p>
      </td>

      <td>
        <p>\$87.38</p>
      </td>

      <td>
        <p>K8s Master</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>GCP</p>
      </td>

      <td>
        <p>n2-highmem-64</p>
      </td>

      <td>
        <p>64vCPU / 512G RAM / 1TB</p>
      </td>

      <td>
        <p>2</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$8.38</p>
      </td>

      <td>
        <p>\$6,120.90</p>
      </td>

      <td>
        <p>\$3,856.01</p>
      </td>

      <td>
        <p>K8s Nodes</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>GCP</p>
      </td>

      <td>
        <p>g2-standard-48</p>
      </td>

      <td>
        <p>4 L4 GPUs <sup>\[4]</sup> / 48vCPU / 192G RAM / 2TB / 96 GiB VRAM</p>
      </td>

      <td>
        <p>1</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$4.00</p>
      </td>

      <td>
        <p>\$2,921.24</p>
      </td>

      <td>
        <p>\$2,445.43</p>
      </td>

      <td>
        <p>Standard Services (Translate, Batch)</p>
      </td>
    </tr>

    <tr>
      <td>
        <p><strong>Total Cost</strong></p>
      </td>

      <td>
        <p><strong>All v4 lang-pairs with standard service</strong></p>
      </td>

      <td>
        <p><strong>\$12.57</strong></p>
      </td>

      <td>
        <p><strong>\$9,180.84</strong></p>
      </td>

      <td>
        <p><strong>\$6,388.82</strong></p>
      </td>

      <td>
        <p />
      </td>
    </tr>

    <tr>
      <td>
        <p>GCP</p>
      </td>

      <td>
        <p>g2-standard-24 (Optional)</p>
      </td>

      <td>
        <p>2 L4 GPU / 24vCPU / 96G RAM / 2TB / 48 GiB VRAM</p>
      </td>

      <td>
        <p>1</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$2.00</p>
      </td>

      <td>
        <p>\$1,460.58</p>
      </td>

      <td>
        <p>\$1,222.75</p>
      </td>

      <td>
        <p>OCR + AI Review / LILT Create (Gemma)</p>
      </td>
    </tr>

    <tr>
      <td>
        <p><strong>Total Cost (incl. optional services)</strong></p>
      </td>

      <td>
        <p><strong>Standard service + OCR/AI Review/Create</strong></p>
      </td>

      <td>
        <p><strong>\$14.57</strong></p>
      </td>

      <td>
        <p><strong>\$10,641.42</strong></p>
      </td>

      <td>
        <p><strong>\$7,611.57</strong></p>
      </td>

      <td>
        <p />
      </td>
    </tr>
  </tbody>
</table>

<Note>
  \[1] Price calculated for plan: "On-Demand Instances"

  \[2] Price calculated for plan: "Committed use discount options" (1 year)

  Source: [GCP Pricing Calculator Estimate](https://cloud.google.com/products/calculator?hl=en\&dl=CjhDaVF3WXpka01tUmxNUzFqT0Rka0xUUmxaVGd0T0RZMllTMWtZVEJoTnpJM1pqQXdaVEFRQVE9PRAIGiQzMDBDMThDMi1GMEM1LTQxMDItODFBNi05NzdCOTg5NkM5RDY)

  <strong>Optional GPU-Accelerated Services</strong><br />
  In addition to the standard deployment, several optional services require extra GPU resources:

  * OCR, AI Review & LILT Create — All three are served by one Gemma (vLLM) deployment, which needs 45 GB of VRAM on a single node (one 48 GB card, or two 24 GB cards in the same server) and 80 GB of node RAM, as shown in the optional row above. Enabling AI Review or LILT Create on top of OCR adds no GPU.
  * Uzbek and Chechen Language Support — Provided through the neural v4.0 pipeline in rayman (which replaces the former dedicated Emma model). When enabled, it requires one additional L4 or A10 GPU with at least 24GB VRAM; when disabled, rayman runs on a single GPU.
  * ASR (Automatic Speech Recognition) — GPU-accelerated ASR requires one additional T4 GPU with 16 GB VRAM. By default, it runs on CPU. ASR with the Sorani (Kurdish) model needs 25 GB of VRAM on one node (two 16 GB or two 24 GB cards in the same server, or one 48 GB card) and has no CPU fallback.
</Note>

## Microsoft Azure

##### Last Revised: 23 Jul 2026

<table>
  <tbody>
    <tr>
      <th>
        <p><strong>Microsoft Azure</strong></p>
      </th>
    </tr>

    <tr>
      <td>
        <p>Platform</p>
      </td>

      <td>
        <p>Resource Identifier</p>
      </td>

      <td>
        <p>Specifications</p>
      </td>

      <td>
        <p>Quantity</p>
      </td>

      <td>
        <p>Unit</p>
      </td>

      <td>
        <p>Unit cost<sup> \[1]</sup></p>
      </td>

      <td>
        <p>Cost <sup>\[1]</sup> per month</p>
      </td>

      <td>
        <p>Cost <sup>\[2]</sup> per month</p>
      </td>

      <td>
        <p>Notes</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Azure</p>
      </td>

      <td>
        <p>D3 v2</p>
      </td>

      <td>
        <p>4vCPU / 14G RAM / 512GiB</p>
      </td>

      <td>
        <p>1</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$0.29</p>
      </td>

      <td>
        <p>\$213.89</p>
      </td>

      <td>
        <p>\$147.58</p>
      </td>

      <td>
        <p>K8s Master</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Azure</p>
      </td>

      <td>
        <p>E64as v5</p>
      </td>

      <td>
        <p>64vCPU / 512G RAM / 512GiB</p>
      </td>

      <td>
        <p>2</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$7.23</p>
      </td>

      <td>
        <p>\$5,279.36</p>
      </td>

      <td>
        <p>\$3,579.93</p>
      </td>

      <td>
        <p>K8s Nodes</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Azure</p>
      </td>

      <td>
        <p>Standard\_NV72ads\_A10\_v5</p>
      </td>

      <td>
        <p>2 A10 GPU / 72vCPU / 880G RAM / 2880GiB/ 48GB VRAM</p>
      </td>

      <td>
        <p>2</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$13.04</p>
      </td>

      <td>
        <p>\$9,519.20</p>
      </td>

      <td>
        <p>\$7,923.78</p>
      </td>

      <td>
        <p>Standard Services (Translate, Batch)</p>
      </td>
    </tr>

    <tr>
      <td>
        <p><strong>Total Cost</strong></p>
      </td>

      <td>
        <p><strong>All v4 lang-pairs with standard service</strong></p>
      </td>

      <td>
        <p><strong>\$20.56</strong></p>
      </td>

      <td>
        <p><strong>\$15,012.45</strong></p>
      </td>

      <td>
        <p><strong>\$11,651.29</strong></p>
      </td>

      <td>
        <p />
      </td>
    </tr>

    <tr>
      <td>
        <p>Azure</p>
      </td>

      <td>
        <p>Standard\_NV72ads\_A10\_v5 (Optional)</p>
      </td>

      <td>
        <p>2 A10 GPU / 72vCPU / 880G RAM / 2880GiB/ 48GB VRAM</p>
      </td>

      <td>
        <p>1</p>
      </td>

      <td>
        <p>Hour</p>
      </td>

      <td>
        <p>\$6.52</p>
      </td>

      <td>
        <p>\$4,759.60</p>
      </td>

      <td>
        <p>\$3,961.89</p>
      </td>

      <td>
        <p>OCR + AI Review / LILT Create (Gemma)</p>
      </td>
    </tr>

    <tr>
      <td>
        <p><strong>Total Cost (incl. optional services)</strong></p>
      </td>

      <td>
        <p><strong>Standard service + OCR/AI Review/Create</strong></p>
      </td>

      <td>
        <p><strong>\$27.08</strong></p>
      </td>

      <td>
        <p><strong>\$19,772.05</strong></p>
      </td>

      <td>
        <p><strong>\$15,613.18</strong></p>
      </td>

      <td>
        <p />
      </td>
    </tr>
  </tbody>
</table>

<Note>
  \[1] Price calculated for plan: "Pay as you go"

  \[2] Price calculated for plan: "1 year savings plan"

  Source: [https://azure.com/e/41227c0f7aed4a208bbe74cacb734acc](https://azure.com/e/41227c0f7aed4a208bbe74cacb734acc)

  <strong>Optional GPU-Accelerated Services</strong><br />
  In addition to the standard deployment, several optional services require extra GPU resources:

  * OCR, AI Review & LILT Create — All three are served by one Gemma (vLLM) deployment, which needs 45 GB of VRAM on a single node (one 48 GB card, or two 24 GB cards in the same server) and 80 GB of node RAM, as shown in the optional row above. Enabling AI Review or LILT Create on top of OCR adds no GPU. The A10 is an Ampere card (compute capability 8.6): it runs Gemma at reduced throughput and is not enabled by the default installer, so confirm with LILT before sizing on the Standard\_NV72ads\_A10\_v5 row above, or choose an Ada-class SKU.
  * Uzbek and Chechen Language Support — Provided through the neural v4.0 pipeline in rayman (which replaces the former dedicated Emma model). When enabled, it requires one additional L4 or A10 GPU with at least 24GB VRAM; when disabled, rayman runs on a single GPU.
  * ASR (Automatic Speech Recognition) — GPU-accelerated ASR requires one additional T4 GPU with 16 GB VRAM. By default, it runs on CPU. ASR with the Sorani (Kurdish) model needs 25 GB of VRAM on one node (two 16 GB or two 24 GB cards in the same server, or one 48 GB card) and has no CPU fallback.
</Note>


# Set Custom Domain And Certificates
Source: https://support.lilt.com/self-managed/v6.1/set-custom-domain-and-certificates



LILT derives every hostname it serves from two variables in `install.env`. You set the domain once, and the installer resolves it into every values file, route, and service URL.

<Warning>
  Do not edit hostnames in `lilt/values.yaml`, `lilt/environments/*/values.yaml`, or the chart values files directly. Those files hold `__SUBDOMAIN__` and `__BASE_DOMAIN__` placeholders that the installer substitutes at install time. An edit there is either overwritten on the next run or leaves the deployment inconsistent with its routes.
</Warning>

## Set the Domain

Set both variables in `install.env`:

```bash theme={null}
SUBDOMAIN=prod
DNS_DOMAIN=example.com
```

`DNS_DOMAIN` is required on every install path. Together the two produce the hostnames in the following table.

## Hostnames LILT Serves

Every hostname is a sibling of the others, not a subdomain of the main one. This matters for both DNS and certificates.

| Hostname | Serves |
| - | - |
| `<SUBDOMAIN>.<DNS_DOMAIN>` | The web application and the public API |
| `core-api-<SUBDOMAIN>.<DNS_DOMAIN>` | The core API |
| `connectors-api-<SUBDOMAIN>.<DNS_DOMAIN>` | The connectors API |
| `wso2-<SUBDOMAIN>.<DNS_DOMAIN>` | The WSO2 identity server. Routed by default on EKS. On-premises it is opt-in: the routes ship disabled and `install-wso2.sh` is not called by `install-lilt.sh`. |
| `minio-<SUBDOMAIN>.<DNS_DOMAIN>` | MinIO object storage, on-premises installs only |
| `minio-<SUBDOMAIN>-ui.<DNS_DOMAIN>` | The MinIO console, on-premises installs only |
| `vault.<SUBDOMAIN>.<DNS_DOMAIN>` | The Vault UI, only when `ENABLE_VAULT_UI` is true. Override with `VAULT_UI_HOST`. |

## Point DNS at the Ingress

All hostnames resolve to the same address: the load balancer in front of the Istio ingress gateway.

### On-premises

MetalLB hands the ingress gateway the address you set in `LB_IP`:

```bash theme={null}
# install.env
LB_IP=10.124.0.234
```

`LB_IP` is required when `ENABLE_METALLB` is true, which is the default. The install stops with an error if it is unset. Create an A record for each hostname in the preceding table pointing at that address.

### On AWS EKS

The ingress gateway provisions a Network Load Balancer. Read its address after the install:

```bash theme={null}
kubectl get svc -n istio-ingressgateway
```

Create a Route53 alias record for each hostname pointing at that load balancer. To have the installer create the records for you, set:

```bash theme={null}
# install.env
ENABLE_DNS=true
HOSTED_ZONE_ID=Z0EXAMPLE1234567890
```

The installer then needs Route53 write access. See [Install from a bastion](/self-managed/v6.1/install-from-a-bastion#iam-permissions).

### Testing Before DNS Exists

To reach the application before the records are live, map the ingress address in your own `/etc/hosts`. Add every hostname, not only the main one, or sign-in fails when the browser is redirected to the identity server.

```
203.0.113.24  prod.example.com core-api-prod.example.com connectors-api-prod.example.com wso2-prod.example.com
```

## Certificates

Every listener on the ingress gateway reads one Kubernetes secret, `lilt-com-tls`, in the `istio-ingressgateway` namespace. `install-lilt-networking.sh` is what writes it, and it picks a source in this order: cert-manager if `ENABLE_CERT_MANAGER=true`, then `TLS_CRT_FILE` and `TLS_KEY_FILE`, then an existing secret it leaves alone. If none of those apply it warns and continues, and the gateway serves no HTTPS.

Choose one source of certificates.

| Path | How | Use it when |
| - | - | - |
| Your own certificate | Set `TLS_CRT_FILE` and `TLS_KEY_FILE` in `install.env`. | On-premises, air-gapped, or any deployment with its own certificate authority. This is the default path. |
| cert-manager | Set `ENABLE_CERT_MANAGER=true`. cert-manager issues the certificate through a Route53 DNS-01 challenge and then owns the secret. | EKS deployments with Route53 access and the cert-manager IAM role. Needs `ENABLE_DNS=true`, or DNS records that already exist for the challenge to resolve against. |
| The Terraform module, indirectly | Set `enable_tls_certificate = true` in `lilt-aws-env`. The module runs the ACME challenge and stores the certificate in Vault. It does not write the Kubernetes secret. | EKS deployments that want the certificate provisioned alongside the infrastructure. You still deliver it to the cluster, either by writing the files out and setting `TLS_CRT_FILE` and `TLS_KEY_FILE`, or by creating `lilt-com-tls` yourself. |

<Warning>
  Do not enable two of these. cert-manager and the Terraform module both run ACME challenges against the same Let's Encrypt identifier set, which is limited to five certificates per 168 hours. Two owners exhaust the quota and neither gets a certificate.

  Setting `TLS_CRT_FILE` together with `ENABLE_CERT_MANAGER=true` is safe but pointless: the installer skips the file seed when cert-manager is on, so your file is ignored.
</Warning>

### Required Subject Alternative Names

A certificate you supply yourself must cover every hostname LILT serves. Because the hostnames are siblings rather than subdomains, a single `*.<SUBDOMAIN>.<DNS_DOMAIN>` wildcard does not cover them.

```
*.<SUBDOMAIN>.<DNS_DOMAIN>
<SUBDOMAIN>.<DNS_DOMAIN>
core-api-<SUBDOMAIN>.<DNS_DOMAIN>
connectors-api-<SUBDOMAIN>.<DNS_DOMAIN>
wso2-<SUBDOMAIN>.<DNS_DOMAIN>
```

Add the MinIO hostnames on an on-premises install, and the Vault UI host if `ENABLE_VAULT_UI` is true.

<Warning>
  A missing name is easy to miss and slow to diagnose. Browsers that already trust the main hostname keep working, while API clients fail hostname verification against the API hosts. The symptom reads as a TLS bug rather than as an incomplete certificate.
</Warning>

Check what a certificate actually covers before you install:

```bash theme={null}
openssl x509 -in tls.crt -noout -text | grep -A1 'Subject Alternative Name'
```

### Supplying the Certificate

Point the two variables at PEM files on the machine running the installer:

```bash theme={null}
# install.env
TLS_CRT_FILE=/opt/lilt/certs/tls.crt
TLS_KEY_FILE=/opt/lilt/certs/tls.key
```

`TLS_CRT_FILE` must be the full chain: your certificate followed by any intermediates. A chain missing its intermediate still satisfies a browser that has cached it, and fails later in a stricter client.

## Apply a Change

Both the domain and the certificate take effect when you re-run the installer. Every component uses `helm upgrade --install`, so a re-run only changes what differs.

```bash theme={null}
sh install-lilt.sh        # on-premises
sh install-lilt-eks.sh    # EKS
```

## Rotate a Certificate

When cert-manager or the Terraform module owns the secret, rotation is automatic and you do nothing.

For a certificate you supply, replace the files and re-run the installer. It overwrites `lilt-com-tls` with the new material:

```bash theme={null}
cp new-tls.crt /opt/lilt/certs/tls.crt
cp new-tls.key /opt/lilt/certs/tls.key
sh install-lilt-eks.sh
```

The ingress gateway picks the new certificate up without a restart. Confirm the expiry date changed:

```bash theme={null}
kubectl get secret lilt-com-tls -n istio-ingressgateway \
  -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -dates
```

## Verify

```bash theme={null}
# The certificate the gateway serves, and its names.
openssl s_client -connect <SUBDOMAIN>.<DNS_DOMAIN>:443 -servername <SUBDOMAIN>.<DNS_DOMAIN> </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

# Every hostname should answer, and verify cleanly. Drop wso2- if you do not
# run the identity server.
for h in "" core-api- connectors-api- wso2-; do
  printf '%s: ' "$h<SUBDOMAIN>.<DNS_DOMAIN>"
  curl -sS -o /dev/null -w '%{http_code} verify=%{ssl_verify_result}\n' \
    "https://$h<SUBDOMAIN>.<DNS_DOMAIN>/"
done
```

`verify=0` on every hostname means DNS, the load balancer, and the certificate are all correct. The status code itself varies by host, and a 401, 404, or redirect is still proof that the request reached the gateway over a valid certificate. A connection or TLS error is not.

## Troubleshooting

**The gateway serves no HTTPS at all.** The installer warns and continues when no certificate is available. Check whether the secret exists:

```bash theme={null}
kubectl get secret lilt-com-tls -n istio-ingressgateway
```

If it is missing, neither `TLS_CRT_FILE` nor cert-manager was configured. Create it directly, then re-run the installer:

```bash theme={null}
kubectl create secret tls lilt-com-tls -n istio-ingressgateway --cert=tls.crt --key=tls.key
```

**Sign-in redirects to a hostname that does not resolve.** The identity server runs on its own hostname. Confirm that `wso2-<SUBDOMAIN>.<DNS_DOMAIN>` resolves and is covered by the certificate.

**A hostname returns 404 through the gateway.** The route for it did not install. Check the HTTPRoutes:

```bash theme={null}
kubectl get httproute -n istio-ingressgateway
```

## Related Articles

* [Install System (AWS EKS)](/self-managed/v6.1/install-system-aws-eks)
* [Install on an existing EKS cluster](/self-managed/v6.1/install-aws-existing-cluster)
* [Provision AWS infrastructure with Terraform](/self-managed/v6.1/install-aws-terraform-module)
* [Single sign-on (SSO)](/self-managed/v6.1/single-sign-on-sso)


# Single Sign On (SSO) For Self-Managed
Source: https://support.lilt.com/self-managed/v6.1/single-sign-on-sso



For **self-managed customers** only, LILT supports Single Sign-On (SSO), allowing users to sign in to LILT using an identity provider other than LILT. Organizations can utilize SSO to simplify account management and reduce password fatigue.

Currently, for installations without WSO2, a user account must pre-exist in the LILT system before SSO can be used to authenticate the user.  If WSO2 is installed with the package then users will be auto-provisioned with the `lilt_api` and `lilt_role` attributes mentioned in the WSO2 configuration section.

## Google SSO

LILT customers can sign in via their Google account.

After being invited to join LILT by someone in your organization, you can create an account using Google Sign-On.

Users with existing LILT accounts that use traditional username/password sign in can access their accounts and all their data using Google Sign-On with an email address that matches their existing account. Users may use both sign-in methods interchangeably.

## OpenID Connect

LILT Platform users can sign in through their organization's SSO once configured via OpenID Connect (OIDC).

[OpenID Connect](https://openid.net/developers/how-connect-works/) is an interoperable authentication protocol based on the OAuth 2.0 framework of specifications (IETF RFC 6749 and 6750). It simplifies the way to verify the identity of users based on the authentication performed by an Authorization Server and to obtain user profile information in an interoperable and REST-like manner. OIDC can be leveraged through many identity providers such as Amazon, Microsoft, Okta, etc.

### Configuration

* LILT must be registered as a client with your OpenID Connect (OIDC) provider before installation. Client key, secret, and configuration parameters need to be configured during installation. Those parameters will be set by your systems administrator under the front:config:SSO property in the helm values file.
* A LILT installation can support only one OIDC configuration at a time.
* OpenID support has currently been tested with the following two signing algorithms: SHA256 and HS256.
* The integration supports encryption with the OpenID provider via HTTPS but does not additionally encrypt the OpenID payload.

### Custom Claims

The following custom claims can be configured in your OIDC provider to enable auto-provisioning and domain assignment:

* **`lilt_api`** (required for JIT provisioning) — Your organization's API key, used to identify which LILT organization the user belongs to. Set this as a static claim value — it is the same for all users in the organization.
* **`lilt_role`** (recommended) — The user's role within LILT. Accepts three formats:

  | Format | Example | Notes |
  | :- | :- | :- |
  | Numeric role ID | `"4"` | Most reliable — never changes |
  | Internal role name | `"Agency Translator"` | Case-sensitive, must match exactly |
  | Localized display name | `"External Linguist"` | Case-insensitive |

  If omitted or unrecognized, the user receives the organization's default role.
* **`lilt_domains`** (optional) — Assigns the user to specific domains on first login. Supports multiple formats:

  | Format | Example |
  | :- | :- |
  | Single value | `"Marketing"` |
  | Comma-separated | `"Marketing,Sales,Legal"` |
  | JSON array | `["Marketing", "Sales"]` |
  | Domain ID | `"123"` |
  | Mixed | `"Marketing,456,Sales"` |

  Domain names are case-sensitive. Numeric values are resolved as domain IDs. Domain assignments are only applied on first login — subsequent logins do not update assignments.

### Usage

* After configuration, OIDC authentication can be used to authenticate existing LILT accounts and their data.
* To create new user accounts, users must first be invited by email using the "New member" screen in the LILT Organizations tab. After being invited, new users can sign in using the SSO button on the sign-in page.
* NOTE: Automated user provisioning and de-provisioning is only supported when using WSO2.

## WSO2

### Configuring WSO2 Identity Server with LILT

This section describes how to configure WSO2 Identity Server for single sign-on (SSO) authentication with LILT.

#### Prerequisites

WSO2 ships **disabled** in a self-managed installation. Enabling it takes three changes, not one — the install script alone leaves the platform pointing at a provider it will not reach.

**1. Install WSO2**

Uncomment the `install-wso2.sh` line in `<install dir>/install-lilt.sh`, then run it:

```sh theme={null}
sh install_scripts/install-wso2.sh
```

**2. Enable the OIDC provider in the platform**

In `lilt/values.yaml`, set the flag to `true` for **all three** services — missing one leaves that service unable to authenticate through WSO2:

```yaml theme={null}
front:
  env:
    EMBEDDED_OIDC_PROVIDER_ENABLED: 'true'
av-scan:
  env:
    EMBEDDED_OIDC_PROVIDER_ENABLED: true
auth-service:
  env:
    EMBEDDED_OIDC_PROVIDER_ENABLED: true
```

**3. Enable the ingress routing for WSO2**

In `lilt-networking/on-prem-values.yaml`, set `enabled: true` on all three `wso2-is` entries — the `gateways` entry, the `virtualservices` entry, and the `wso2-is-tls` entry under `destinationrules`. Without these, `wso2-<subdomain>` is not published and the OIDC endpoints above resolve to nothing.

Then re-run the platform install so the values take effect.

<Note>
  Steps 2 and 3 are what the platform reads to find the identity provider. If WSO2 is installed but they are left disabled, sign-in falls back to LILT accounts and every OIDC endpoint — authorize, token, userinfo and logout — points at a host with no service behind it.
</Note>

Also required:

* Access to WSO2 Identity Server Console with Super Admin privileges -- username and password are `admin` by default.
* LILT application deployed

#### Step 1: Configure User Attributes

##### 1.1 Access User Attributes

1. Log into the WSO2 Identity Server Console as Super Admin
2. Navigate to **User Attributes & Stores** → **Attributes**
3. Click on **Attributes** to view and manage user attributes

##### 1.2 Add Custom LILT Attributes

You need to add two critical attributes for LILT integration:

**Add lilt\_role Attribute:**

1. Click **New Attribute** button
2. Configure the attribute:
   * **Attribute Name**: `lilt_role`
   * **Attribute URI**: `http://wso2.org/claims/lilt_role`
   * **Protocol Mappings**:
     * OpenID Connect: `lilt_role`
     * SCIM 2.0: `urn:scim:schemas:extension:custom:User:lilt_role`
   * **Attribute Display Name**: `LILT Role`
3. Click **Finish** to save
4. Scroll down on the page and make sure to select `Display` under the `Administrator Console` column for the `Attribute Configurations` section

**Add lilt\_api Attribute:**

1. Click **New Attribute** button again
2. Configure the attribute:
   * **Attribute Name**: `lilt_api`
   * **Attribute URI**: `http://wso2.org/claims/lilt_api`
   * **Protocol Mappings**:
     * OpenID Connect: `lilt_api`
     * SCIM 2.0: `urn:scim:schemas:extension:custom:User:lilt_api`
   * **Attribute Display Name**: `LILT API`
3. Click **Finish** to save
4. Scroll down on the page and make sure to select `Display` under the `Administrator Console` column for the `Attribute Configurations` section

**Add lilt\_domains Attribute (Optional):**

1. Click **New Attribute** button again
2. Configure the attribute:
   * **Attribute Name**: `lilt_domains`
   * **Attribute URI**: `http://wso2.org/claims/lilt_domains`
   * **Protocol Mappings**:
     * OpenID Connect: `lilt_domains`
     * SCIM 2.0: `urn:scim:schemas:extension:custom:User:lilt_domains`
   * **Attribute Display Name**: `LILT Domains`
3. Click **Finish** to save
4. Scroll down on the page and make sure to select `Display` under the `Administrator Console` column for the `Attribute Configurations` section

#### Step 2: Configure OpenID Connect Scopes

##### 2.1 Access OIDC Scopes Configuration

1. Navigate to **User Attributes & Stores** → **Attributes** → **OpenID Connect** -> **Scopes**

##### 2.2 Add to Roles Scope

1. Click **Roles** to configure the scope
2. Click **New Attribute**
3. Choose the `lilt_role` attribute
4. Click **Save**
5. Click **Save Changes**

##### 2.3 Add to Profile Scope

1. Return to the scopes page from 2.1
2. Click **Profile** to configure the scope
3. Click **New Attribute**
4. Choose the `lilt_api` attribute
5. Click **Save**
6. If using `lilt_domains`: Click **New Attribute** again, choose the `lilt_domains` attribute, and click **Save**
7. Click **Save Changes**

#### Step 3: Create and Configure the LILT Application

##### 3.1 Create New Application

1. Navigate to **Applications**
2. Click **New Application**
3. Select **Standard-Based Application**
4. Choose **OAuth2.0/OpenID Connect**
5. Configure basic settings:
   * **Name**: `LILT` (or your preferred application name)
   * **Description**: LILT Application for SSO
6. Click **Register**

##### 3.2 Configure Protocol Settings

1. In the application configuration, go to the **Protocol** tab
2. Configure the following OAuth/OIDC settings:

**Allowed Grant Types:**

* ✓ Code
* ✓ Client Credentials
* ✓ Organization Switch

**URLs Configuration:**

Authorized Redirect URLs:

```
https://<your-domain>/signin2
https://<your-domain>/auth/embedded-oidc/logout
https://<your-domain>/auth/embedded-oidc/callback
```

**Important Note:** Replace `<your-domain>` with your actual LILT instance domain.

Allowed Origins:

```
https://<your-domain>
```

**Access Token:**

* Select: `JWT` as the **Token type**

##### 3.3 Configure User Attributes

1. Go to the **User Attributes** tab
2. Select the following attributes to be included in the ID token:
   * ✓ Email
   * ✓ Groups
   * ✓ Profile (Expand to make sure `lilt_api` is included)
   * ✓ Roles (Expand to make sure `lilt_role` is included)
3. Select `Assign alternate subject identifier`
   * Select `Email` in the dropdown

##### 3.4 Configure API Authorization

1. Go to the **API Authorization** tab
2. Click **Authorize an API Resource**
3. Configure the API authorization:
   * **API Resource**: Select the API resource you need to authorize
   * **Authorized Scopes**: Select appropriate scopes for your implementation
   * **Authorization Policy**: Role Based Access Control (RBAC)
4. Click **Finish**

**Note:** Repeat this process for each API resource that needs to be authorized for your LILT implementation.

#### Step 4: Configure Login Flow

1. Go to the **Login Flow** tab in your application
2. Configure the authentication flow based on your requirements:

**Basic Login Flow (Username & Password):**

* **Step 1**: Sign in with Username & Password

**Multi-Factor Authentication Options (Optional):**

You can add various MFA methods as a second step:

* Email OTP
* Push Notification
* SMS OTP
* TOTP
* Passkey
* Magic Link

#### Step 5: Configure SSO Settings (Optional)

If you want to integrate with external identity providers:

1. Navigate to **Connections** → **New Connection**
2. Select your identity provider type
3. Configure the connection settings based on your IdP requirements
4. Map the external attributes to WSO2 attributes

**Note:** You can auto-navigate to SSO by removing the Username & Password login screen and only selecting the SSO option in the Login Flow section

#### Step 6: User Management

##### Creating New Users

When creating users in WSO2 for LILT access:

1. Navigate to **User Management** → **Users**
2. Click **Add User**
3. Fill in required fields:
   * Username
   * Email
   * First Name
   * Last Name
   * Password
4. **Important**: Add the custom attributes:
   * **lilt\_role**: Assign appropriate LILT role. Accepted formats (tried in order):
     1. **Numeric role ID** (e.g., `4`) — matches by role ID
     2. **Internal role name** (e.g., `Administrator`, `Manager`) — exact match, case-sensitive
     3. **Localized display name** (e.g., `External Linguist`, `Korrektor`, `外部担当者`) — case-insensitive match via alias map
   * If `lilt_role` is omitted or does not match any role, the user will be assigned the organization's default role (typically "Customer")
   * **lilt\_api**: API key -- this is only required if the user does not already exist in LILT
   * **lilt\_domains** (optional): Comma-separated domain names or IDs (e.g., `"Marketing,Sales"`). Domain names are case-sensitive. Numeric values are resolved as domain IDs.
5. Save the user

**Note:** If the **lilt\_role** and **lilt\_api** fields do not appear when adding a user revisit step 1.2. These attributes are used for auto-provisioning. If **lilt\_domains** does not appear, ensure you completed the optional attribute setup in step 1.2.

**Note:** The `lilt_domains` claim is only applied when a user is first provisioned (JIT). Subsequent SSO logins do not update domain assignments. To change domain assignments for existing users, update them directly in LILT.

##### Modifying Existing Users

For users already in the system:

1. Navigate to the user profile
2. Edit user attributes
3. Add the `lilt_role` and `lilt_api` attributes if required
4. Save changes

#### Tying it to the application

All of the information needed can be found in the **Quick Start** and **Info** tabs in the WSO2 application that was just created.  The environment variables required are shown below:

<Note>
  After configuring the environment variables below, you must also enable the `enableWSO2Login` feature flag for each organization using the Admin CLI:

  ```bash theme={null}
  npm run dist-admin-cli -- set-org-setting --orgIds <ORG_ID> --settingName=enableWSO2Login --value=true
  ```

  **Note: If users were already created before enabling this flag, their account type in the database will be set to `local` and they will not be able to sign in via SSO.**

  **To fix this, you must edit the database row for each affected user and change their account type to `embedded-oidc`.**

  This flag enables the authentication type selector in the user invite UI and allows WSO2/Embedded OIDC to be set as the authentication method for new users.
</Note>

```yaml theme={null}
front:
  onpremValues:
    env:
      # Embedded OIDC Provider
      EMBEDDED_OIDC_PROVIDER_ENABLED: true
      EMBEDDED_OIDC_PROVIDER_CLIENT_ID: "<WSO2 app client id>"
      EMBEDDED_OIDC_PROVIDER_CLIENT_SECRET: "<WSO2 app client secret>"
      EMBEDDED_OIDC_PROVIDER_ID_TOKEN_SIGNED_RESPONSE_ALG: "RS256"
      EMBEDDED_OIDC_PROVIDER_ISSUER_ENDPOINT: "https://<your-wso2-domain>/oauth2/token"
      EMBEDDED_OIDC_PROVIDER_ISSUER_AUTH_ENDPOINT: "https://<your-wso2-domain>/oauth2/authorize"
      EMBEDDED_OIDC_PROVIDER_ISSUER_TOKEN_ENDPOINT: "https://<your-wso2-domain>/oauth2/token"
      EMBEDDED_OIDC_PROVIDER_ISSUER_USERINFO_ENDPOINT: "https://<your-wso2-domain>/oauth2/userinfo"
      EMBEDDED_OIDC_PROVIDER_ISSUER_JWKS_URI: "https://<your-wso2-domain>/oauth2/jwks"
      EMBEDDED_OIDC_PROVIDER_ISSUER_END_SESSION_ENDPOINT: "https://<your-wso2-domain>/oidc/logout"
      EMBEDDED_OIDC_PROVIDER_INTEGRATION_APIS_WSO2_IS_ENABLED: false
      EMBEDDED_OIDC_PROVIDER_INTEGRATION_APIS_WSO2_IS_ASGARDEO: false
      EMBEDDED_OIDC_PROVIDER_INTEGRATION_APIS_WSO2_BASE_URL: ""
      EMBEDDED_OIDC_PROVIDER_INTEGRATION_APIS_WSO2_TENANT: ""
      EMBEDDED_OIDC_PROVIDER_INTEGRATION_APIS_WSO2_LILT_ROOT_ORG: ""
```

#### Organization Alias Mapping (Optional)

If your organization uses multiple names or identifiers that should resolve to the same LILT organization, you can configure organization aliases via a Kubernetes ConfigMap.

Organization identifiers are normalized before lookup: converted to lowercase, trimmed, and spaces are replaced with hyphens (e.g., "My Org" becomes "my-org").

**Configuration:**

Create or update the ConfigMap mounted at `/home/lilt/server/config/sso-org-aliases.json` with a JSON object mapping aliases to canonical organization identifiers:

```json theme={null}
{
  "alternate-name": "canonical-org-name",
  "old-company-name": "canonical-org-name"
}
```

Both alias keys and canonical values must be valid identifiers: alphanumeric characters, dots (`.`), hyphens (`-`), and underscores (`_`) only, up to 255 characters.

#### Testing the Configuration

After completing the configuration:

1. Navigate to `https://<your-domain>/signin`
2. You should be redirected to the WSO2 login page
3. Enter credentials for a user with proper `lilt_role` and `lilt_api` attributes
4. Upon successful authentication, you should be redirected back to LILT with proper access

#### Troubleshooting WSO2 Integration

If users cannot access LILT after authentication:

* Verify the lilt\_role and lilt\_api attributes are properly configured
* Check that redirect URLs match exactly
* Ensure all required scopes are configured
* Verify API authorizations are in place
* Check application logs for specific error messages

## Direct Integration (SINGLE OIDC)

The version 1.20.0 (September 2023) release of LILT Enterprise supports two new kinds of customization of the Single Sign On feature:  "custom certs" and "non-standard overrides".  The intent is to expand the environments where SSO can be used.

These customizations are discussed in more detail in the following section, where we will reference the configuration shown immediately below.  This particular configuration illustrates using custom certificate info, as well as overrides to standard OIDC behaviour, so that login using Active Directory Federation Services (ADFS) on Windows 2016 can be achieved.

```yaml theme={null}
front:
  onpremValues:
    env:
      # SSO configurations
      #
      # OIDC
      SINGLE_OIDC_PROVIDER_ENABLED: true
      SINGLE_OIDC_PROVIDER_CLIENT_ID: "lilt"
      SINGLE_OIDC_PROVIDER_CLIENT_SECRET: "SAMPLE"
      SINGLE_OIDC_PROVIDER_ID_TOKEN_SIGNED_RESPONSE_ALG: "RS256"
      SINGLE_OIDC_PROVIDER_ISSUER_NAME: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs"
      SINGLE_OIDC_PROVIDER_ISSUER_AUTH_ENDPOINT: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs/oauth2/authorize/"
      SINGLE_OIDC_PROVIDER_ISSUER_TOKEN_ENDPOINT: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs/oauth2/token/"
      SINGLE_OIDC_PROVIDER_ISSUER_USERINFO_ENDPOINT: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs/userinfo"
      SINGLE_OIDC_PROVIDER_ISSUER_JWKS_URI: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs/discovery/keys"
      #
      # OIDC - overrides for working with ADFS
      SINGLE_OIDC_PROVIDER_OVERRIDES_RESOURCE_QUERY_PARAM: "urn:microsoft:userinfo"
      SINGLE_OIDC_PROVIDER_OVERRIDES_IDTOKEN_CLAIM_NAME_FOR_LILT_EMAIL_ADDRESS: "upn"
    config:
      # singleOidcProviderTlsOptions provides a means to customize HTTP requests made from the front container
      # to the OIDC Provider, when using the SingleOidcProvider SSO feature.  Using these options means you
      # should NOT use any other OIDC-based login strategy besides that of the SingleOidcProvider SSO feature, or at
      # least be aware other strategies implemented via the openid-client library will also be affected by these options.
      singleOidcProviderTlsOptions:
        # existingSecret should be set to true if you are going to manage the secret yourself; otherwise set existingSecret
        # to false and the template will manage the secret.  If managing the secret yourself, you can provide key-value pairs
        # in the secret for any of the following keys:
        #    ca, cert, key, passphrase, crl, pfx
        # However, you MUST also provide a non-empty string value in the map below for the keys that you want to be used.
        # It does not matter what non-empty string you provide below in that case -- e.g.,
        #    ca: "use-the-existing-secret-value"
        # added below would cause your existing secret's ca value to be used.
        existingSecret: false
        secretName: "single-oidc-provider-tls-options"
        # ca, cert, key, passphrase, crl, and pfx are used to customize HTTP calls from the oidc-client library to the OIDC Provider
        # Only those with non-empty values will be used; all others will be ignored.
        # If existingSecret is false, the values you specify below should be base64 encoded.
        # Their meaning can be found at:  https://nodejs.org/api/tls.html#tlscreatesecurecontextoptions
        ca: |-
          SAMPLE
        cert: |-
          SAMPLE
        key: ""
        passphrase: ""
        crl: ""
        pfx: ""
```

#### Azure Active Directory, Graph

If using Azure Active Directory with Graph API, the following need to be configured on the provider:

Configure Authentication:

1. Click Authentication (left sidebar)
2. Click Add a platform
3. Select Web
4. Configure:
   Redirect URIs:
   `https://<host_name>/auth/openid/callback`
   Front-channel logout URL: (leave blank)
   Implicit grant and hybrid flows:
   ❌ Access tokens (used for implicit flows) - UNCHECK
   ❌ ID tokens (used for implicit and hybrid flows) - UNCHECK
   Click Configure
   Scroll down to Advanced settings:
   Allow public client flows: No
   Enable the following mobile and desktop flows: (leave as is)
   Click Save at the top

Configure API Permissions:

1. Click API permissions (left sidebar)
2. You should see Microsoft Graph with some permissions already
3. Click Add a permission
4. Select Microsoft Graph
5. Select Delegated permissions
6. Search and check these permissions:
   ✅ email (under OpenId permissions)
   ✅ openid (under OpenId permissions)
   ✅ profile (under OpenId permissions)
7. Click Add permissions
8. Grant Admin Consent:
   Click Grant admin consent for \[Your Organization]
   Click Yes to confirm
   Wait for green checkmarks to appear
   Final state should look like:

```bash theme={null}
Microsoft Graph (3)
├── email          - Delegated - ✅ Granted for [Org]
├── openid         - Delegated - ✅ Granted for [Org]
└── profile        - Delegated - ✅ Granted for [Org]
```

Update `values.yaml`:

```yaml theme={null}
front:
  onpremValues:
    env:
      # SSO configurations
      # OIDC
      SINGLE_OIDC_PROVIDER_ENABLED: true
      SINGLE_OIDC_PROVIDER_CLIENT_ID: "<client_id>"  # "", if using existing secret
      SINGLE_OIDC_PROVIDER_CLIENT_SECRET: "<client_secret>" # "", if using existing secret
      SINGLE_OIDC_PROVIDER_ID_TOKEN_SIGNED_RESPONSE_ALG: "RS256"
      SINGLE_OIDC_PROVIDER_ISSUER_NAME: "https://login.microsoftonline.com/<directory_tenant_id>/v2.0"
      SINGLE_OIDC_PROVIDER_ISSUER_AUTH_ENDPOINT: "https://login.microsoftonline.com/<directory_tenant_id>/oauth2/v2.0/authorize"
      SINGLE_OIDC_PROVIDER_ISSUER_TOKEN_ENDPOINT: "https://login.microsoftonline.com/<directory_tenant_id>/oauth2/v2.0/token"
      SINGLE_OIDC_PROVIDER_ISSUER_USERINFO_ENDPOINT: "https://graph.microsoft.com/oidc/userinfo"
      SINGLE_OIDC_PROVIDER_ISSUER_JWKS_URI: "https://login.microsoftonline.com/<directory_tenant_id>/discovery/v2.0/keys"
```

## SSO configuration format changes, starting at version 1.19.0 (SINGLE OIDC)

Changes were made to how the SSO configuration values are specified, starting with version 1.19.0.  Note that the "regular" SSO-related configuration values are now specified as environment variables, nested under front.onpremValues.env has shown in this excerpt:

```yaml theme={null}
front:
  onpremValues:
    env:
      # SSO configurations
      #
      # OIDC
      SINGLE_OIDC_PROVIDER_ENABLED: true
      SINGLE_OIDC_PROVIDER_CLIENT_ID: "lilt"
      SINGLE_OIDC_PROVIDER_CLIENT_SECRET: "SAMPLE"
      SINGLE_OIDC_PROVIDER_ID_TOKEN_SIGNED_RESPONSE_ALG: "RS256"
      SINGLE_OIDC_PROVIDER_ISSUER_NAME: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs"
      SINGLE_OIDC_PROVIDER_ISSUER_AUTH_ENDPOINT: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs/oauth2/authorize/"
      SINGLE_OIDC_PROVIDER_ISSUER_TOKEN_ENDPOINT: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs/oauth2/token/"
      SINGLE_OIDC_PROVIDER_ISSUER_USERINFO_ENDPOINT: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs/userinfo"
      SINGLE_OIDC_PROVIDER_ISSUER_JWKS_URI: "https://active-directory-bare-windows-vm-shared-vpc.ssodev.lilt.dev/adfs/discovery/keys"
```

## Client ID and Secret

Can use an existing secret for client ID and SECRET. Ensure that a generic kubernetes secret already exists in the cluster.

```yaml theme={null}
front:
  onpremValues:
    env:
      # SSO configurations
      #
      # OIDC
      SINGLE_OIDC_PROVIDER_ENABLED: true
      SINGLE_OIDC_PROVIDER_CLIENT_ID: ""
      SINGLE_OIDC_PROVIDER_CLIENT_SECRET: ""
    config:
      oidc:
        useExistingSecret:
          enabled: true
          existingSecretRef: <secret_name>
          ## This defines where to find the keys for OIDC credentials in the existingSecretRef
          # Keys in the secret for OIDC client ID and client secret
          clientIdKey: <id_key_name_in_secret>
          clientSecretKey: <secret_key_name_in_secret>
        ## If oidc.useExistingSecret.enabled is false or not set, values fall back to
        ## env.SINGLE_OIDC_PROVIDER_CLIENT_ID and env.SINGLE_OIDC_PROVIDER_CLIENT_SECRET
```

## SSO TLS customization

Communication from the LILT app to your OIDC IdentityProvider occurs over a connection secured by TLS. For this communication to be successful, certificate information is exchanged and verified. In many environments, this verification can succeed using well-known CertificateAuthority information that is part of the default network stack in nodejs (the platform used to implement the SSO feature). In some environments, it will be necessary to provide additional TLS-related configuration. Support for doing so was added to LILT Enterprise starting at version 1.20.0.

### singleOidcProviderTlsOptions

Specifically, it is now possible, via the `front.onpremValues.config.singleOidcProviderTlsOptions` object, to provide the following configuration values affecting the TLS communication for calls made from the LILT appserver to your OIDC IdentityProvider:

* ca
* cert
* key
* passphrase
* crl
* pfx

The meaning of the above six parameters can be found in the nodejs documentation at:

[TLS (SSL) | Node.js v24.6.0 Documentation](https://nodejs.org/api/tls.html#tlscreatesecurecontextoptions)

In testing where Active Directory Federation Services (ADFS), running on Windows Server, was used as the IdentityProvider, it was necessary to specify `ca` and `cert` values, but not the others.

Further instructions for using these configuration values can be found in the comments in the YAML shown at the start of this SSO section.

## Using ADFS 2016 in lieu of standard OIDC Identity Provider

Microsoft's ADFS 2016 does not conform to the OIDC standard when acting as an identity provider. Starting with version 1.20.0, the LILT application can work around this non-conformance, if you leverage two new environment variables, as discussed below.

### SINGLE\_OIDC\_PROVIDER\_OVERRIDES\_RESOURCE\_QUERY\_PARAM

ADFS 2016 needs an additional "resource" query parameter to be used when calling the OIDC authenticaiton endpoint. Set the `SINGLE_OIDC_PROVIDER_OVERRIDES_RESOURCE_QUERY_PARAM` as shown in the YAML at the start of this SSO documentation (above).

### SINGLE\_OIDC\_PROVIDER\_OVERRIDES\_IDTOKEN\_CLAIM\_NAME\_FOR\_LILT\_EMAIL\_ADDRESS

ADFS 2016 does not include the expected `email` property in the response from the Userinfo OIDC endpoint. As a workaround, you can adjust the settings in ADFS 2016 to provide the user's email address as the value of a claim in the ID\_TOKEN. Use the `SINGLE_OIDC_PROVIDER_OVERRIDES_IDTOKEN_CLAIM_NAME_FOR_LILT_EMAIL_ADDRESS` setting as shown in the YAML at the start of this SSO documentation (above) to tell your LILT installation which claim in the ID\_TOKEN will contain the email address.

The following articles might be helpful when attempting to configure ADFS to provide an email address via an ID\_TOKEN claim:

[Blog Michael Boeynaems](https://www.michaelboeynaems.com/keycloak-ADFS-OIDC.html)

[OIDC configuration with AD FS | Qlik Sense for administrators Help](https://help.qlik.com/en-US/sense-admin/May2023/Subsystems/DeployAdministerQSE/Content/Sense_DeployAdminister/QSEoW/Administer_QSEoW/Managing_QSEoW/OIDC-configuration-ADFS.htm)

Note that in the example shown above (and excerpted again below), the `upn` property in the IdToken is being leveraged, but it may or may not correspond to an email address used by your users. It likely is in the same format as an email address, and uniquely identifies a user in your IdentityProvider, and so may be suitable for using in this way if it is not possible to provide an email address via a property in the IdToken.

```yaml theme={null}
front:
  onpremValues
	  env:
	    SINGLE_OIDC_PROVIDER_OVERRIDES_RESOURCE_QUERY_PARAM: "urn:microsoft:userinfo"
	    SINGLE_OIDC_PROVIDER_OVERRIDES_IDTOKEN_CLAIM_NAME_FOR_LILT_EMAIL_ADDRESS: "upn"
```

## SSO Troubleshooting

### Communication paths

The OpenIDConnect (OIDC) standard used in the implementation of SSO in LILT Enterprise depends on two communication paths being open and configured properly:

* the path from user's browser to the OIDC IdentityProvider
* the path from the LILT app-server (front pod in the Kubernetes cluster) to the OIDC IdentityProvider

**Testing communication path from user's browser to the OIDC IdentityProvider:**

It will be apparent whether that first path is open and functioning when the user is redirected to the sign-in page hosted by your OIDC IdentityProvider. If that sign-in page loads, then that path is functioning. (To be clear, this is not the initial "Sign in to LILT" page hosted by the LILT app; rather, it is the page that loads after clicking the "Sign in with SSO" button on the "Sign in to LILT" page.)

It is also informative to load in your browser the "…well-known…" configuration page served up by your OIDC IdentityProvider. The URL will depend on how you have configured your IdentityProvider, but will be something like "https\://YOUR\_IDP\_DOMAIN\_NAME/adfs/.well-known/openid-configuration".

**Testing communication path from the LILT app-server to the OIDC IdentityProvider:**

Determining whether that second path is open and configured appropriately is more challenging. The following steps can be used to help diagnose when there is a problem.

```bash theme={null}
# ssh into the master vm for the Kubernetes cluster
# (exactly how to do that is site specific)
# store the front pod name in a variable, for ease of use
fpod=$(kubectl get pods | grep front | awk '{print $1}')
# "kubectl exec" into the "front" container of the "front" pod
kubectl exec --stdin --tty $fpod -- /bin/sh
#
# At this point, you should have a shell prompt in that front container
#
# Use `curl` to verify domain name of your IdentityProvider can be resolved
curl YOUR_IDP_DOMAIN_NAME
## Failure to resolve will look something like this:
##
## curl: (6) Could not resolve host: YOUR_IDP_DOMAIN_NAME; Unknown error
##
# Use `curl --insecure` to verify the ".well-known" configuration page served by
# your IdentityProvider can loaded, ignoring certificate issues.
# (Note that the "adfs" in the URL below may not match what your IdentityProvider
# uses.  But there should be a URL with ".well-known" that is valid.
curl --insecure https://YOUR_IDP_DOMAIN_NAME/adfs/.well-known/openid-configuration
# If successful, the curl command above should return a result something
# similar to:
## {"issuer":"https:\\/\\/YOUR_ID_DOMAIN_NAME\\/adfs","authorization_endpoint":"https:\\/\\/YOUR_ID_DOMAIN_NAME\\/adfs\\/oauth2\\/authorize\\/","token_endpoint":"https:\\/\\/YOUR_ID_DOMAIN_NAME\\/adfs\\/oauth2\\/token\\/","jwks_uri":"https:\\/\\/YOUR_ID_DOMAIN_NAME\\/adfs\\/discovery\\/keys","token_endpoint_auth_methods_supported":["client_secret_post","client_secret_basic","private_key_jwt","windows_client_authentication"],"response_types_supported":["code","id_token","code id_token","id_token token","code token","code id_token token"],"response_modes_supported":["query","fragment","form_post"],"grant_types_supported":["authorization_code","refresh_token","client_credentials","urn:ietf:params:oauth:grant-type:jwt-bearer","implicit","password","srv_challenge","urn:ietf:params:oauth:grant-type:device_code","device_code"],"subject_types_supported":["pairwise"],"scopes_supported":["winhello_cert","user_impersonation","vpn_cert","logon_cert","profile","openid","allatclaims","email","aza"],"id_token_signing_alg_values_supported":["RS256"],"token_endpoint_auth_signing_alg_values_supported":["RS256"],"access_token_issuer":"http:\\/\\/YOUR_ID_DOMAIN_NAME\\/adfs\\/services\\/trust","claims_supported":["aud","iss","iat","exp","auth_time","nonce","at_hash","c_hash","sub","upn","unique_name","pwd_url","pwd_exp","mfa_auth_time","sid"],"microsoft_multi_refresh_token":true,"userinfo_endpoint":"https:\\/\\/YOUR_ID_DOMAIN_NAME\\/adfs\\/userinfo","capabilities":["kdf_ver2"],"end_session_endpoint":"https:\\/\\/YOUR_ID_DOMAIN_NAME\\/adfs\\/oauth2\\/logout","as_access_token_token_binding_supported":true,"as_refresh_token_token_binding_supported":true,"resource_access_token_token_binding_supported":true,"op_id_token_token_binding_supported":true,"rp_id_token_token_binding_supported":true,"frontchannel_logout_supported":true,"frontchannel_logout_session_supported":true,"device_authorization_endpoint":"https:\\/\\/YOUR_ID_DOMAIN_NAME\\/adfs\\/oauth2\\/devicecode"}
# Use `curl` to verify certificates used by the TLS setup are ok
curl https://YOUR_IDP_DOMAIN_NAME/adfs/.well-known/openid-configuration
# If successful, you should see the same result as the `curl --insecure` command.
# If instead you see something like the output below, you may need to configure
# one or more of the parameters of
#
#     `front.onpremValues.config.singleOidcProviderTlsOptions`
#
# as described in sections above.
#
## curl: (60) SSL certificate problem: unable to get local issuer certificate
## More details here: <https://curl.se/docs/sslcerts.html>
##
## curl failed to verify the legitimacy of the server and therefore could not
## establish a secure connection to it. To learn more about this situation and
## how to fix it, please visit the web page mentioned above.
## command terminated with exit code 60
```

### Deleting session information

When troubleshooting the SSO configuration, it may be helpful to delete session information stored in the browser for both the LILT app and your OIDC IdentityProvider.

To delete session information for the LILT app, load the `/signin` page of the LILT app, and use your browser's tools to delete the cookies and storage associated with the LILT app domain name.

To delete session information associated with your OIDC IdentityProvider, load the "…well-known…" configuration page (e.g., "https\://YOUR\_IDP\_DOMAIN\_NAME/adfs/.well-known/openid-configuration") in the browser, and use your browser's tools to delete the cookies and storage associated with your IdentityProvider.

Note that if you do not delete the session info associated with your OIDC IdentityProvider, when you click on "Sign in with SSO" it may skip taking you to the IdentityProvider's login screen to type in password information; instead, it will re-use the previous successful login session, if any.

### Configuration to TEMPORARILY enable debug logging for SSO

The following configuration will cause details about the HTTP/TLS communication with the OIDC identity provider to be included in the front pod logs. PLEASE BE CAREFUL USING THESE OPTIONS. This extra logging should not be enabled for production use.

```yaml theme={null}
front:
  onpremvalues:
    env:
      DEBUG: "openid-client,lilt:singleOidcProvider"
      NODE_DEBUG: "http,tls"
```

The options can be adjusted to include only a subset of the debug logging available. For instance, you can just specify the `DEBUG` setting shown, but leave out the one for `NODE_DEBUG`.


# SMTP Email Notifications
Source: https://support.lilt.com/self-managed/v6.1/smtp-email-notifications



1. [Self-Managed Documentation](/self-managed/v6.1/self-managed-features) /
2. [System Administration](/self-managed/v6.1/install-system-amazon-linux-2023-or-rocky-8-9) /
3. [System Configuration](/self-managed/v6.1/enable-features)

[Skip table of contents](#article-inner-content)

LILT’s SMTP email integration enables customers to set up email integrations for core workflows like user sign up, job creation, job assignment, and job state changes. The following email integrations are available:

* **Account creation email**, that invites new users to log into LILT for the first time.

* **Password reset email**, so users can safely and securely reset their password.

* **Job creation email**, so users know when a job has been successfully submitted.

* **New project assignment email**, so linguists and users can accept or reject the project assignment.

  * There are three distinct emails: translator assignment email, reviewer assignment email, and Instant + Review assignment email.

* **Project rejection email**, so users can effectively manage projects.

* **Project completion email**, so users can track and understand progress.

* **Revision report email**, for linguists to learn from errors and quality feedback.

## PII-Safe Email Mode

For organizations with strict data privacy requirements (such as healthcare or financial services), LILT supports a **PII-safe email mode** that anonymizes document titles in assignment notification emails. When enabled:

* Document names and job names are **not included** in email notifications
* Assignment emails direct users to log into the LILT platform to view project details
* The installation/customer name is displayed instead of specific job information
* Applies to translator, reviewer, and secondary reviewer assignment emails

This feature helps prevent accidental exposure of sensitive information (PHI/PII) that may be contained in document or job names when emails are delivered outside of a secure environment.

## Configuration instructions

In order to configure LILT’s SMTP Notifications feature, the following configurations must be set in `$install_dir/lilt/environments/lilt/values.yaml`

The comments next to each value describe the information needed for each setting.

#### Notes:

* `white-list-email-domains` is an optional value. Leaving empty indicates any domain is allowed to be sent to.

* The bottom `option1` is purposefully set to the empty string in order to overwrite the existing value.

```bash theme={null}
notification:
  enabled: true
  onpremValues:
    env:
      HIDE_PII_IN_EMAILS: "" # set to "true" to enable PII-safe email mode (anonymizes document titles)
      LILT_INSTALLATION_NAME: "" # customer/installation name displayed in PII-safe emails (required if HIDE_PII_IN_EMAILS is "true")
    app:
      args:
        defaultsenderemail: "" # default sender email. Required for sending emails
        notificationdomain: "" # domain to be used for sending email links to redirect the user back to the app. Required for sending emails
        white-list-email-domains: "" # comma separated list of email domains to be whitelisted for sending emails
        smtp-host: "" # smtp host. Required for sending emails
        smtp-port: "" # smtp port. Required for sending emails
        smtp-user: "" # smtp user. Required for sending emails
        smtp-password: "" # smtp password. Required for sending emails
front:
  onpremValues:
    env:
      MAILER_PROVIDER: ""
      MAILER_ENABLED: ""
      SMTP_HOST: ""
      SMTP_PORT: ""
      SMTP_USER: ""
      SMTP_PASS: ""
      MAILER_ADDRESSES_NOREPLY: ""
      SMTP_WHITELIST_DOMAINS: ""
assignment:
  onpremValues:
    app:
      args:
        option1: ""
```

## SMTP Transport Security Options

By default, the notification service performs an opportunistic STARTTLS upgrade on every connection. For most SMTP relays this is the right behavior, but some self-managed deployments run against internal mail relays that:

* listen on plain port 25 and do not advertise STARTTLS, or
* advertise STARTTLS but present a certificate that the default JVM trust store does not accept, or
* require implicit TLS (SMTPS) on a non-standard port such as 465.

To support these scenarios, the notification service exposes five additional environment variables. All of them are optional — the defaults below reproduce the historical behavior, so existing deployments do not need to change anything.

<Note>
  These transport-security variables are available starting in **LILT 6.0** and beyond. Earlier releases (including LILT 5.3.x) force opportunistic STARTTLS and have no equivalent configuration.
</Note>

| Variable | Default | Purpose |
| - | - | - |
| `SMTP_STARTTLS_ENABLE` | `"true"` | Opportunistic STARTTLS upgrade on the SMTP connection. Set to `"false"` to permit unencrypted SMTP (for example, port 25 with no encryption). |
| `SMTP_STARTTLS_REQUIRED` | `"false"` | Require STARTTLS — the send fails if the server does not advertise it. |
| `SMTP_SSL_ENABLE` | `"false"` | Use SMTPS (implicit TLS) instead of plain SMTP. Typically paired with port `465`. |
| `SMTP_SSL_TRUST` | `""` | Hosts to trust when verifying SMTP TLS certificates. Use `"*"` to trust all hosts (useful with internal CAs or self-signed certs). |
| `SMTP_AUTH` | `""` (derived) | Explicit override for SMTP AUTH. When unset, auth is enabled if and only if `smtp-password` is non-empty. |

These variables are set under `notification.onpremValues.env` in the same `values.yaml` shown above. They apply only to the notification service — the `front` pod uses a separate transport (see the `front.onpremValues.env` block above).

### Example: unencrypted SMTP on port 25

If your relay accepts plaintext SMTP on port 25 with no auth and you want the notification pod to behave the same way the `front` pod already does:

```bash theme={null}
notification:
  enabled: true
  onpremValues:
    env:
      SMTP_STARTTLS_ENABLE: "false"
    app:
      args:
        defaultsenderemail: "noreply@example.com"
        notificationdomain: "example.com"
        smtp-host: "smtp-relay.internal"
        smtp-port: "25"
        smtp-user: ""
        smtp-password: ""
```

### Example: SMTPS (implicit TLS) on port 465

```bash theme={null}
notification:
  enabled: true
  onpremValues:
    env:
      SMTP_STARTTLS_ENABLE: "false"
      SMTP_SSL_ENABLE: "true"
    app:
      args:
        smtp-host: "smtp.example.com"
        smtp-port: "465"
        smtp-user: "username"
        smtp-password: "password"
```

### Example: STARTTLS against an internal CA

If your relay advertises STARTTLS but uses a certificate from an internal CA that the JVM does not trust, add the host to `SMTP_SSL_TRUST`:

```bash theme={null}
notification:
  enabled: true
  onpremValues:
    env:
      SMTP_SSL_TRUST: "smtp.internal.example.com"
    app:
      args:
        smtp-host: "smtp.internal.example.com"
        smtp-port: "587"
        smtp-user: "username"
        smtp-password: "password"
```

Use `SMTP_SSL_TRUST: "*"` to trust any host — convenient for testing, but skip cert validation only when you understand the risk.

Below is an example configuration:

```bash theme={null}
notification:
  enabled: true
  onpremValues:
    env:
      HIDE_PII_IN_EMAILS: "true"
      LILT_INSTALLATION_NAME: "Example Corp"
    app:
      args:
        defaultsenderemail: "user@example.com"
        notificationdomain: "example.com"
        white-list-email-domains: "test.com"
        smtp-host: "smtp.example.com"
        smtp-port: "587"
        smtp-user: "username"
        smtp-password: "password"
front:
  onpremValues:
    env:
      MAILER_PROVIDER: "smtp"
      MAILER_ENABLED: "true"
      SMTP_HOST: "smtp.example.com"
      SMTP_PORT: "587"
      SMTP_USER: "username"
      SMTP_PASS: "password"
      MAILER_ADDRESSES_NOREPLY: "user@example.com"
      SMTP_WHITELIST_DOMAINS: "test.com"
assignment:
  onpremValues:
    app:
      args:
        option1: ""
```


# SRX Upload Documentation
Source: https://support.lilt.com/self-managed/v6.1/srx-upload-documentation



Here are the steps to set SRX files:

**Required Step!** Make sure that `EnableSubfiltersSegmentation` is enabled on your instance prior to uploading SRX. To learn more on how to enable it, follow to [Enable/Disable Features](/self-managed/v6.1/enable-features)

## Step 1: Click “Manage” on the left rail

<Frame>
  <img />
</Frame>

## Step 2: Click on “File Loaders”

<Frame>
  <img />
</Frame>

## Step 3: Click on “+ New Loader” in the top right corner

<Frame>
  <img />
</Frame>

## Step 4: Select “Segmentation Only”

<Frame>
  <img />
</Frame>

## Step 5: In the Segmentation dropdown on the right section select “Upload Custom SRX File”

<Frame>
  <img />
</Frame>

## Step 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

<Frame>
  <img />
</Frame>

<Frame>
  <img />
</Frame>

## Step 7: After uploading the file, click Next in the bottom right corner

<Frame>
  <img />
</Frame>

## Step 8: Name the loader

#### OPTIONAL STEPS

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 organisation

<Frame>
  <img />
</Frame>

## Step 9: Click “Create” at the bottom of the screen and you SRX file loader should be ready.


# Syncing Language Data
Source: https://support.lilt.com/self-managed/v6.1/sync-language-data



Language data (languages, locales, and language-locale pairs) is synced
automatically by the `front-init` container on startup. The
`sync-language-data` admin-cli command can be run manually in production to
retry or debug syncing language data in case of any issues or missing language
pairs.

## Applying Changes

1. Preview changes with a dry run (no database modifications):

`yarn admin-cli sync-language-data -d`

2. Run the sync:

`yarn admin-cli sync-language-data`

The command will prompt for confirmation before making changes. The current git commit hash is recorded as the migration identifier for traceability.

## Rolling Back Changes

If you need to undo a sync, use the `--undo` / `-u` flag. This is a two-step process:

1. On the commit that was synced, run undo to delete the pairs it inserted:\
   `yarn admin-cli sync-language-data --undo`

2. Check out the previous commit and re-run the sync to restore any rows that were updated:\
   `git checkout <previous-commit>`\
   `yarn admin-cli sync-language-data`

<Info>
  The undo only removes `LanguageLocalePairs` rows matching the commit's
  migration ID. It does not revert updates to existing rows (such as changes to
  providers or MT settings). Re-running the sync from the previous commit
  handles that.
</Info>


# Upgrade Elasticsearch Across Major Versions
Source: https://support.lilt.com/self-managed/v6.1/upgrade-elasticsearch



## Overview

LILT runs Elasticsearch under the ECK operator. A LILT release can ship both a
newer operator and a newer Elasticsearch major version, and **the order in
which they are upgraded matters**: a newer operator refuses to manage
Elasticsearch nodes below its supported floor. If the operator is upgraded
first, it stops reconciling the existing cluster — the discovery configuration
goes stale, and any Elasticsearch pod that restarts afterwards can no longer
rejoin the cluster.

This applies to **any existing install whose running Elasticsearch major
version is behind the version shipped with the new release**, regardless of
which LILT version it was installed from.

Newer installers detect this and abort the operator upgrade with:

```
install-elastic-eck-operator: ERROR refusing to upgrade the operator over Elasticsearch <running> (target <shipped>)
```

This page is the procedure to follow when you hit that error, or whenever you
know your upgrade crosses an Elasticsearch major version.

## The Rule

Never skip an Elasticsearch major version, and never upgrade the operator past
what your running Elasticsearch supports. Per major version, the order is:

1. **With the currently installed operator**, upgrade the Elasticsearch
   resource to the **last minor of the running major** (the bridge version —
   for 8.x it is 8.19, shipped as the pinned tag `8.19.20`).
2. Wait until the cluster is `green` and every node reports the bridge
   version.
3. Run the new installer normally: it upgrades the operator, then applies the
   shipped Elasticsearch version, which is now a supported single-major hop.

If your install is **more than one major behind** the shipped version, upgrade
through the intermediate LILT release(s), or contact LILT support — the
installer you have only ships one operator version, and each major must be
bridged under an operator that supports it.

## Prerequisites

* The cluster is `green` before you start:

  ```bash theme={null}
  kubectl -n lilt get elasticsearch eck-cluster
  ```

* The **bridge-version Elasticsearch image is available to your nodes** (in
  your registry or loaded locally). Deliveries that cross an Elasticsearch
  major include the pinned bridge image (currently `8.19.20`) as an additional
  image — verify it is present in your registry before starting.

## Steps (example: 8.x to 9.x)

Run from the installer directory on the master node:

```bash theme={null}
# 1) With the CURRENT (old) operator still installed, move the
#    Elasticsearch resource to the bridge version of the running major,
#    using the pinned bridge tag shipped with your delivery (currently
#    8.19.20). Keep version and image.tag identical.
. install_scripts/utils.sh
VALS=$(resolve_placeholders "eck-cluster/${VALS_FILE:-on-prem-values.yaml}")
helm upgrade eck-cluster "$(chart_ref eck-cluster)" -n lilt \
  -f "$VALS" \
  --server-side true --force-conflicts \
  --set version=8.19.20 --set image.tag=8.19.20

# 2) Wait until health is green and every node reports the bridge version:
kubectl -n lilt get elasticsearch eck-cluster \
  -o jsonpath='{.status.health} {.status.availableNodes} {.status.version}'

# 3) Re-run the installer: it upgrades the operator and then applies the
#    shipped Elasticsearch version.
./install-lilt.sh
```

## Gotchas

1. **Order is everything.** Elasticsearch data is upgraded in place; each step
   is irreversible for the data. Take a backup before starting — see [Back Up
   and Restore Elasticsearch](/self-managed/v6.1/backup-and-restore-elasticsearch), which also
   covers registering the snapshot repository the installer does not create.
2. **The Elasticsearch StatefulSet uses `updateStrategy: OnDelete`** — a
   `kubectl rollout restart` rolls nothing. The operator handles pod cycling;
   if you must recycle by hand, delete pods one at a time and wait for ready.
3. **Do not downgrade the operator to recover.** It collides with immutable
   StatefulSet fields the newer operator wrote. If you already upgraded the
   operator first and the cluster froze, contact LILT support — the recovery
   (deleting the StatefulSet with `--cascade=orphan` so pods and data survive)
   is easy to get wrong.
4. **Long maintenance windows can outlive registry credentials.** If your
   registry uses short-lived pull tokens, refresh them before the final
   rolling upgrade, or the new-image pull fails and a pod is left waiting on
   an image.

## Verification

```bash theme={null}
kubectl -n lilt get elasticsearch eck-cluster
```

must show `green`, the full node count, and the shipped version. The
Elasticsearch-dependent applications (indexer, search, segment, core-api)
recover on their own once the cluster is reachable again — no restarts needed.


# Upgrade Kubernetes
Source: https://support.lilt.com/self-managed/v6.1/upgrade-kubernetes



## Overview

This article walks the installer through the process of upgrading K8S from a previous version.

In working through the installation, references will be made as appropriate to provide context.

#### System Parameters/Versions:

* Base OS:

  * Amazon Linux 2023: `ami-05576a079321f21f8`

  * Rocky 8.10

* K8S

  * current version: v1.30.9

  * upgrade version: v1.31.7

#### Requirements:

K8S must be upgraded incrementally from each version. As an example, if upgrading from v1.29 to v1.31, you must install each increment and repeat the process until the desired version is installed:

* v1.29 → v1.30

* v1.30 → v1.31

In this example, upgrading from v1.30 to v1.31 so only need to apply the process once.

## Upgrade K8S

#### Step 1: Check Current Versions

`kubeadm`, `kubelet`, and `kubectl` versions must match. Verify that the current versions are the same:

`kubeadm` version:

```bash theme={null}
kubeadm version
```

Example output:

```bash theme={null}
kubeadm version: &http://version.Info {Major:"1", Minor:"30", GitVersion:"v1.30.9", GitCommit:"a87cd6906120a367bf6787420e943103a463acba", GitTreeState:"clean", BuildDate:"2025-01-15T14:40:03Z", GoVersion:"go1.22.10", Compiler:"gc", Platform:"linux/amd64"}
```

`kubectl` version:

```bash theme={null}
kubectl version
```

Example output:

```bash theme={null}
Client Version: v1.30.9
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
```

`kubelet` version:

```bash theme={null}
kubectl get nodes
```

Example output:

```
NAME     STATUS   ROLES           AGE   VERSION
gpu      Ready    <none>          48d   v1.30.9
master   Ready    control-plane   48d   v1.30.9
worker   Ready    <none>          48d   v1.30.9
```

#### Step 2: Update Base OS

On ALL nodes in the cluster (master, worker, and gpu). Each base OS has different package updates.

* *Amazon Linux 2023*:

```bash theme={null}
# update OS
dnf check-release-update
sudo dnf update -y
```

* *Rocky 8*:

```bash theme={null}
# update system
dnf update -y
```

#### Step 3: Update Repository Config

On ALL nodes in the cluster (master, worker, and gpu), update repository config file to desired version. In this example, using v1.31:

```bash theme={null}
# set version
export K8S_V="1.31"

# set repository and repo
cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v$K8S_V/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v$K8S_V/rpm/repodata/repomd.xml.key
exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni
EOF
```

#### Step 4: Upgrade Control Plane Kubeadm

On the master node, upgrade `kubeadm`. Worker/GPUs nodes will be updated separately.

Get list of possible upgrade versions:

```bash theme={null}
sudo dnf list --showduplicates kubeadm --disableexcludes=kubernetes
```

Example output:

```bash theme={null}
Installed Packages
kubeadm.x86_64                                                   1.30.9-150500.1.1                                                  @kubernetes
Available Packages
kubeadm.aarch64                                                  1.31.7-150500.1.1                                                  kubernetes
kubeadm.ppc64le                                                  1.31.7-150500.1.1                                                  kubernetes
kubeadm.s390x                                                    1.31.7-150500.1.1                                                  kubernetes
kubeadm.src                                                      1.31.7-150500.1.1                                                  kubernetes 
```

Install new `kubeadm` version:

```bash theme={null}
# upgrade kubeadm
sudo dnf install -y kubeadm-"1.31*" --disableexcludes=kubernetes
```

Check new version:

```bash theme={null}
kubeadm version
```

Example output:

```bash theme={null}
kubeadm version: &http://version.Info {Major:"1", Minor:"31", GitVersion:"v1.31.7", GitCommit:"da53587841b4960dc3bd2af1ec6101b57c79aff4", GitTreeState:"clean", BuildDate:"2025-03-11T20:02:21Z", GoVersion:"go1.23.6", Compiler:"gc", Platform:"linux/amd64"}
```

#### Step 5: Upgrade Control Plane Components

On the master node, upgrade control plane components.

Run a plan to show what can/will be updated:

```bash theme={null}
sudo kubeadm upgrade plan
```

Example output shows the possible v1.30 and 1.31 minor/patch upgrades. For this example, upgrading minor version to 1.31.7:

```
[preflight] Running pre-flight checks.
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[upgrade] Running cluster health checks
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: 1.30.9
[upgrade/versions] kubeadm version: v1.31.7
I0313 23:37:23.319175  600006 version.go:261] remote version is much newer: v1.32.3; falling back to: stable-1.31
[upgrade/versions] Target version: v1.31.7
[upgrade/versions] Latest version in the v1.30 series: v1.30.11

Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
COMPONENT   NODE      CURRENT   TARGET
kubelet     gpu       v1.30.9   v1.30.11
kubelet     master    v1.30.9   v1.30.11
kubelet     worker    v1.30.9   v1.30.11

Upgrade to the latest version in the v1.30 series:

COMPONENT                 NODE      CURRENT    TARGET
kube-apiserver            master    v1.30.9    v1.30.11
kube-controller-manager   master    v1.30.9    v1.30.11
kube-scheduler            master    v1.30.9    v1.30.11
kube-proxy                          1.30.9     v1.30.11
CoreDNS                             v1.11.3    v1.11.3
etcd                      master    3.5.15-0   3.5.15-0

You can now apply the upgrade by executing the following command:

        kubeadm upgrade apply v1.30.11

_____________________________________________________________________

Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
COMPONENT   NODE      CURRENT   TARGET
kubelet     gpu       v1.30.9   v1.31.7
kubelet     master    v1.30.9   v1.31.7
kubelet     worker    v1.30.9   v1.31.7

Upgrade to the latest stable version:

COMPONENT                 NODE      CURRENT    TARGET
kube-apiserver            master    v1.30.9    v1.31.7
kube-controller-manager   master    v1.30.9    v1.31.7
kube-scheduler            master    v1.30.9    v1.31.7
kube-proxy                          1.30.9     v1.31.7
CoreDNS                             v1.11.3    v1.11.3
etcd                      master    3.5.15-0   3.5.15-0

You can now apply the upgrade by executing the following command:

        kubeadm upgrade apply v1.31.7

_____________________________________________________________________
```

Upgrade to minor version v1.31.7 (can take up to five mins to complete):

```bash theme={null}
kubeadm upgrade apply v1.31.7 -y
```

When complete, view `kube-system` pods. If the upgrade was successful, the `kube*` pods will have a newer age than the others:

```bash theme={null}
kubectl get pods -n kube-system
```

Example output (upgrade was executed 13h ago):

```
NAME                              READY   STATUS    RESTARTS      AGE
coredns-55cb58b774-m7b6h          1/1     Running   3 (2d ago)    24d
coredns-55cb58b774-s5qqr          1/1     Running   4 (20h ago)   24d
etcd-master                       1/1     Running   0             13h
kube-apiserver-master             1/1     Running   0             13h
kube-controller-manager-master    1/1     Running   0             13h
kube-proxy-4bg5s                  1/1     Running   0             13h
kube-proxy-4mk8s                  1/1     Running   0             13h
kube-proxy-7h8ww                  1/1     Running   0             13h
kube-scheduler-master             1/1     Running   0             13h
metrics-server-5f6bd8776f-l6lg8   1/1     Running   3 (20h ago)   22d
```

#### Step 6: Upgrade Control Plane Kubectl and Kubelet

On the master node, upgrade `kubectl` and `kubelet` components. Versions need to match `kubeadm` from previous steps (v1.31.7):

```bash theme={null}
sudo dnf install -y kubelet-"1.31.7" kubectl-"1.31.7" --disableexcludes=kubernetes
```

Restart the `kubelet` daemon:

```bash theme={null}
systemctl daemon-reload
systemctl restart kubelet
```

After upgrading `kubectl`, need to export config:

```bash theme={null}
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
```

Verify `kubectl` version:

```bash theme={null}
kubectl version
```

Example output:

```bash theme={null}
Client Version: v1.31.7
Kustomize Version: v5.4.2
Server Version: v1.31.7
```

List all nodes to verify that the control-plane (master node) `kubelet` was upgraded successfully to v1.31.7 (other nodes will still show previous version):

```bash theme={null}
kubectl get nodes
```

Example output:

```
NAME     STATUS   ROLES           AGE   VERSION
gpu      Ready    <none>          48d   v1.30.9
master   Ready    control-plane   48d   v1.31.7
worker   Ready    <none>          48d   v1.30.9
```

#### Step 7: Upgrade Worker/GPU Node Components

Although the worker and gpu nodes can be upgraded in parallel, it is highly recommended to only upgrade ONE node at a time.

`kubeadm` and `kubectl` are not required on the worker/gpu nodes (only `kubelet`); however, in this example going to install all three for possible future use.

<Note>
  NOTE: if workloads/pods need to remain running during upgrade, each node must be drained, cordoned, and pods rescheduled. This example assumes that the cluster is not operational and that the pods will not be reachable until the upgrade is complete.
</Note>

Execute each of the following steps on the worker and gpu nodes.

Upgrade `kubeadm`:

```bash theme={null}
sudo dnf install -y kubeadm-"1.31.7" --disableexcludes=kubernetes
```

Verify `kubeadm` upgrade:

```bash theme={null}
kubeadm version
```

Example output:

```bash theme={null}
kubeadm version: &http://version.Info {Major:"1", Minor:"31", GitVersion:"v1.31.7", GitCommit:"da53587841b4960dc3bd2af1ec6101b57c79aff4", GitTreeState:"clean", BuildDate:"2025-03-11T20:02:21Z", GoVersion:"go1.23.6", Compiler:"gc", Platform:"linux/amd64"}
```

Upgrade `kubelet` and `kubectl`:

```bash theme={null}
sudo dnf install -y kubelet-"1.31.7" kubectl-"1.31.7" --disableexcludes=kubernetes
```

Restart the `kubelet` daemon:

```bash theme={null}
systemctl daemon-reload
systemctl restart kubelet
```

Verify `kubectl` upgrade:

```bash theme={null}
kubectl version
```

Example output:

```bash theme={null}
Client Version: v1.31.7
Kustomize Version: v5.4.2
The connection to the server localhost:8080 was refused - did you specify the right host or port?
```

#### Step 8: Verify all Nodes Upgraded

On the master node (control plane), confirm the correct `kubelet` version for all nodes:

```bash theme={null}
kubectl get nodes
```

Example output:

```
NAME     STATUS   ROLES           AGE   VERSION
gpu      Ready    <none>          49d   v1.31.7
master   Ready    control-plane   49d   v1.31.7
worker   Ready    <none>          49d   v1.31.7
```


# Upgrade NVIDIA/CUDA Drivers
Source: https://support.lilt.com/self-managed/v6.1/upgrade-nvidia-cuda-drivers



## Overview

This article walks the installer through the process of upgrading NVIDIA drivers from a previous install.

In working through the installation, references will be made as appropriate to provide context.

#### System Parameters/Versions:

* Base OS:

  * Amazon Linux 2023: `ami-05576a079321f21f8`

  * Rocky 8.10

## Upgrade NVIDIA Drivers

#### Step 1: Update base OS

Each base OS has different package updates.

* *Amazon Linux 2023*:

```bash theme={null}
# update OS
dnf check-release-update
sudo dnf update -y
```

* *Rocky 8*:

```bash theme={null}
# update system
dnf update -y
```

#### Step 2: Update Driver

Each base OS has different package requirements.

* *Amazon Linux 2023*:

```bash theme={null}
# update kernel
sudo dnf install -y dkms kernel-devel kernel-modules-extra

# enable dkms for the drivers
sudo systemctl enable --now dkms

# add nvidia repo
sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/amzn2023/x86_64/cuda-amzn2023.repo

# clean cache
sudo dnf clean expire-cache

# optional, lilt available driver packages
dnf module list nvidia-driver

# because a prevous install exisits, need to reset and enable new driver
sudo dnf module reset -y nvidia-driver
sudo dnf module enable -y nvidia-driver:570-dkms

# install driver
sudo dnf module install -y nvidia-driver:570-dkms
```

* *Rocky 8*:

```bash theme={null}
# extra required packages
sudo dnf -y install epel-release

# get rhel/rocky OS current version
export cur_ver="rhel$(rpm -E %rhel)"

# install cuda-toolkit
sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/$cur_ver/x86_64/cuda-$cur_ver.repo

# optional, lilt available driver packages
dnf module list nvidia-driver

# because a prevous install exisits, need to reset and enable new driver
sudo dnf module reset -y nvidia-driver
sudo dnf module enable -y nvidia-driver:570-dkms

# install nvidia driver
sudo dnf -y module install nvidia-driver:570-dkms
```

#### Step 3: Reboot

Necessary for new settings and drivers to be applied.

```bash theme={null}
# reboot to complete install
reboot
```

#### Step 4: Verify new Driver

Verify that the NVIDIA drivers were correctly installed.

```
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:

```
 NVIDIA-SMI 570.124.06             Driver Version: 570.124.06     CUDA Version: 12.8     |
|-----------------------------------------+------------------------+----------------------+
| 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%   23C    P8              9W /  300W |       1MiB /  23028MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   1  NVIDIA A10G                    Off |   00000000:00:17.0 Off |                    0 |
|  0%   23C    P8             12W /  300W |       1MiB /  23028MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   2  NVIDIA A10G                    Off |   00000000:00:18.0 Off |                    0 |
|  0%   23C    P8              9W /  300W |       1MiB /  23028MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   3  NVIDIA A10G                    Off |   00000000:00:19.0 Off |                    0 |
|  0%   24C    P8             10W /  300W |       1MiB /  23028MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   4  NVIDIA A10G                    Off |   00000000:00:1A.0 Off |                    0 |
|  0%   23C    P8             16W /  300W |       1MiB /  23028MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   5  NVIDIA A10G                    Off |   00000000:00:1B.0 Off |                    0 |
|  0%   24C    P8             10W /  300W |       1MiB /  23028MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   6  NVIDIA A10G                    Off |   00000000:00:1C.0 Off |                    0 |
|  0%   23C    P8             13W /  300W |       1MiB /  23028MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   7  NVIDIA A10G                    Off |   00000000:00:1D.0 Off |                    0 |
|  0%   24C    P8             13W /  300W |       1MiB /  23028MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
                                                                                         
+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|  No running processes found                                                             |
+-----------------------------------------------------------------------------------------+
```


# Upgrade Qdrant
Source: https://support.lilt.com/self-managed/v6.1/upgrade-qdrant



## Overview

LILT stores the vectors behind translation-memory matching and nearest-neighbour
suggestions in Qdrant. The installer upgrades Qdrant in place, on its existing
persistent volume, when you run the normal install command.

Qdrant has two properties that make its upgrade different from every other
component in LILT:

* **Qdrant migrates its storage one minor version at a time and cannot skip
  one.** If your installation is more than one minor version behind the release
  you are installing, the installer stops rather than crossing several versions
  in a single restart, which can leave the storage partly migrated.
* **Qdrant cannot be rebuilt from the LILT database.** A snapshot is the only
  way to recover its contents.

<Warning>
  A snapshot is your only recovery path for Qdrant. No tool rebuilds the vectors
  from the LILT database, so an upgrade that damages the storage with no
  snapshot in hand is not recoverable. Losing Qdrant degrades translation-memory
  adaptation and nearest-neighbour matches.
</Warning>

<Note>
  Every command on this page assumes the LILT namespace is `lilt`. If you
  installed into a different namespace, substitute it for `NAMESPACE`.
</Note>

## Connect to Qdrant

Every `curl` command on this page reaches Qdrant through a port forward:

```bash theme={null}
NAMESPACE=lilt
kubectl -n $NAMESPACE port-forward svc/qdrant 6333:6333 &
```

Leave this running while you work, and stop it when you finish.

### Collections

Qdrant stores vectors in *collections*. LILT creates and names them itself, one
per organization and language direction, so you never choose a name — you look
up the ones your installation has. Names look like
`memory_segments_source_organization_BM25_9058`, where the trailing number is
the LILT organization ID.

Wherever a command on this page shows `COLLECTION`, substitute one of these
names:

```bash theme={null}
curl -s localhost:6333/collections | jq -r '.result.collections[].name'
```

The backup procedure loops over that list, so it needs no names from you. The
restore procedures act on one collection at a time, so they do.

If the list comes back empty on a running Qdrant, nothing has been indexed yet
and there is nothing to back up.

### Version

To see the version that is running, read the image from the pods rather than
from the StatefulSet. A rollout that failed leaves the StatefulSet naming the
new image while the storage on disk is still the old version:

```bash theme={null}
kubectl -n $NAMESPACE get pods -l app.kubernetes.io/name=qdrant \
  -o jsonpath='{range .items[*]}{.metadata.name}{"  "}{.status.containerStatuses[0].image}{"\n"}{end}'
```

## Where Qdrant keeps snapshots

By default, Qdrant writes snapshots to `/qdrant/snapshots`, which is a directory
on the **same volume** as its data. A volume you lose takes its snapshots with
it.

Because of that, always copy a snapshot off the pod, as the following procedure
does. To keep snapshots on their own volume instead, contact LILT support: the
change adds a second volume to the Qdrant StatefulSet, which Kubernetes cannot
apply to a running StatefulSet without recreating it.

## Back up before you upgrade

Take a snapshot before every upgrade. Each version step changes the data on disk
and cannot be reversed.

1. Snapshot every collection and record its point count:

   ```bash theme={null}
   for c in $(curl -s localhost:6333/collections | jq -r '.result.collections[].name'); do
     snap=$(curl -s -X POST "localhost:6333/collections/$c/snapshots" | jq -r '.result.name')
     pts=$(curl -s "localhost:6333/collections/$c" | jq -r '.result.points_count')
     printf '%s\t%s\t%s\n' "$c" "$pts" "$snap"
   done | tee qdrant-backup.tsv
   ```

   Keep `qdrant-backup.tsv`. The point counts it records are how you tell a
   complete restore from a partial one.

2. Confirm that each snapshot completed. A snapshot with a size of `0`, or one
   missing from this list, did not finish:

   ```bash theme={null}
   curl -s localhost:6333/collections/COLLECTION/snapshots \
     | jq -r '.result[] | "\(.name)\t\(.size)"'
   ```

   Substitute a collection name for `COLLECTION`.

3. Copy the snapshots off the pod:

   ```bash theme={null}
   POD=$(kubectl -n $NAMESPACE get pods -l app.kubernetes.io/name=qdrant \
     -o jsonpath='{.items[0].metadata.name}')
   mkdir -p qdrant-backup
   kubectl -n $NAMESPACE cp "$POD:/qdrant/snapshots" qdrant-backup
   ```

   `kubectl cp` is slow on a large collection. To download one snapshot over the
   API instead:

   ```bash theme={null}
   curl -s "localhost:6333/collections/COLLECTION/snapshots/SNAPSHOT" \
     --output "qdrant-backup/SNAPSHOT"
   ```

4. Record the Qdrant version you noted earlier alongside the files. A snapshot
   restores only into the version that produced it or the next minor version, so
   the version is part of the backup.

## Upgrade

Qdrant is upgraded by one component script, which the full installer also runs.
For a Qdrant version change you do not need to re-run the whole installer:

```bash theme={null}
sh install_scripts/install-qdrant.sh
```

<Warning>
  A component script does not read `install.env`. Only `install-lilt.sh` and
  `install-lilt-eks.sh` load that file, so when you run a component on its own
  you have to load it yourself:

  ```bash theme={null}
  set -a; . ./install.env; set +a
  sh install_scripts/install-qdrant.sh
  ```

  On an AWS EKS installation, also set `VALS_FILE`, because the script defaults
  to `qdrant/on-prem-values.yaml` and the EKS installer package ships only
  `qdrant/eks-values.yaml`:

  ```bash theme={null}
  set -a; . ./install.env; set +a
  VALS_FILE=eks-values.yaml sh install_scripts/install-qdrant.sh
  ```

  Skipping `install.env` on AWS goes wrong in two ways. With `DNS_DOMAIN`
  unset the script stops with `ERROR: DNS_DOMAIN is required`. Worse, 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 — leaving the pod unable to start its new image. The
  check that catches a missing `REGISTRY_BASE` lives in the entrypoint, not in
  the component script.
</Warning>

The script runs `helm upgrade`, restarts the StatefulSet, and then waits up to
five minutes for the pod to become ready. Qdrant migrates its storage while it
starts, so on a large collection that wait can expire before the migration
finishes. If it does, the script reports a failed rollout; check the pod before
you re-run anything:

```bash theme={null}
kubectl -n $NAMESPACE logs -f statefulset/qdrant
```

A pod still logging migration progress is working, not stuck. Wait for it to
become ready, then confirm your collections as described in [Verify the
restore](#verify-the-restore).

## If the installer stops with a version error

The installer stops with a message like this:

```
install-qdrant: ERROR refusing to change Qdrant 1.16 -> 1.19 in place.
```

This means your Qdrant is more than one minor version behind the release you are
installing. Qdrant cannot skip a minor version when it migrates its storage, and
it cannot be downgraded, so you walk the existing instance up one minor version
at a time until it is one version below the release.

<Warning>
  Do not set `QDRANT_ALLOW_VERSION_SKIP=true` to get past this message. The
  check exists because crossing several minor versions in one restart can leave
  the storage silently half-migrated, and there is no way back.
</Warning>

Read these points before you start:

* **Run the climb inside the maintenance window, before you upgrade LILT
  itself.** The climb moves the Qdrant server ahead of the LILT services still
  talking to it, and those services are only tested against the Qdrant version
  their release shipped with. Open the maintenance window, climb, then run the
  installer, which upgrades LILT to matching versions. Never climb while LILT is
  serving traffic.
* **Expect downtime at each step.** A single-replica Qdrant stops and starts on
  the same volume, and it migrates the storage as it starts.
* **Every step is irreversible.** Take the snapshot first.

1. Find the repository the running pod uses. The intermediate versions ship in
   your release under the same name:

   ```bash theme={null}
   REPO=$(kubectl -n $NAMESPACE get statefulset qdrant \
     -o jsonpath='{.spec.template.spec.containers[0].image}' | sed 's/:[^:]*$//')
   echo "$REPO"
   ```

2. Read the intermediate tags your release ships. Do not type version numbers
   of your own: only the delivered tags exist in your registry, and their exact
   form varies between releases:

   ```bash theme={null}
   RUNGS=$(sed -n 's#.*/qdrant:\([^[:space:]]*\)#\1#p' additional-shipped-images.yaml \
     | while IFS= read -r t; do printf '%s\t%s\n' "${t#v}" "$t"; done \
     | sort -V | cut -f2)
   echo "$RUNGS"
   ```

   The tags print lowest version first. Confirm that each one you need is
   present in your registry before you start, because an air-gapped
   installation cannot fetch a missing one part-way through the climb and there
   is no way back:

   ```bash theme={null}
   for t in $RUNGS; do echo "$REPO:$t"; done
   ```

   Start from the tag just above the **lowest** version any pod reports, and
   skip any rung at or below it.

3. Read the chart pin from the install script, so these commands cannot go stale
   against your release:

   ```bash theme={null}
   . install_scripts/utils.sh
   eval "$(grep -E '^CHART_(NAME|VERSION)=' install_scripts/install-qdrant.sh)"
   CHART="$(chart_ref "$CHART_NAME")"
   ```

4. Apply each remaining tag from `$RUNGS`, in order, one at a time. Wait for
   the pod to become ready before you move to the next — do not paste the whole
   sequence at once, because each step migrates the storage on disk:

   ```bash theme={null}
   helm upgrade qdrant "$CHART" -n $NAMESPACE --version "$CHART_VERSION" \
     --reuse-values --set qdrant.image.tag=RUNG_TAG

   kubectl -n $NAMESPACE rollout status statefulset/qdrant --timeout=600s
   ```

   Substitute one tag from `$RUNGS` for `RUNG_TAG`, then repeat for the next.
   Confirm the running image before continuing, since a failed rollout leaves
   the StatefulSet naming the new tag while the storage is still on the old
   version:

   ```bash theme={null}
   kubectl -n $NAMESPACE get pods -l app.kubernetes.io/name=qdrant \
     -o jsonpath='{range .items[*]}{.status.containerStatuses[0].image}{"\n"}{end}'
   ```

5. Run the component script again. The remaining step is a single minor
   version, so the check passes and the script completes the upgrade with the
   values your release ships:

   ```bash theme={null}
   sh install_scripts/install-qdrant.sh
   ```

   Load `install.env` first, and on AWS prefix the command with
   `VALS_FILE=eks-values.yaml`, as described in [Upgrade](#upgrade).

## Restore from a snapshot

A restore replaces the contents of the collection it targets. Run it in a
maintenance window with LILT quiesced, otherwise LILT writes new vectors while
the restore is in progress.

Both procedures use `priority=snapshot`, which makes the snapshot's data win
over anything already in the collection. That is what a restore means. The
default, `replica`, keeps the live data instead.

### When the snapshot is still on the Qdrant volume

```bash theme={null}
curl -s -X PUT "localhost:6333/collections/COLLECTION/snapshots/recover" \
  -H 'Content-Type: application/json' \
  -d '{"location": "file:///qdrant/snapshots/COLLECTION/SNAPSHOT", "priority": "snapshot"}'
```

Qdrant creates the collection if it does not exist, so this also works against
an empty store after you lose a volume, as long as the snapshot survived. That
is what copying snapshots off the pod is for.

### When you are restoring a copy from outside the cluster

```bash theme={null}
curl -s -X POST "localhost:6333/collections/COLLECTION/snapshots/upload?priority=snapshot" \
  -H 'Content-Type: multipart/form-data' \
  -F "snapshot=@qdrant-backup/SNAPSHOT"
```

The upload is a single request and cannot resume. For a snapshot of several
gigabytes, copy the file into the pod first and then use the preceding
procedure:

```bash theme={null}
kubectl -n $NAMESPACE cp "qdrant-backup/SNAPSHOT" \
  "$POD:/qdrant/snapshots/COLLECTION/SNAPSHOT"
```

### Verify the restore

Compare the point counts against the baseline you recorded:

```bash theme={null}
while read -r c pts snap; do
  now=$(curl -s "localhost:6333/collections/$c" | jq -r '.result.points_count')
  [ "$now" = "$pts" ] && status=OK || status="MISMATCH (expected $pts)"
  printf '%-60s %-12s %s\n' "$c" "$now" "$status"
done < qdrant-backup.tsv
```

Every collection must report `OK`, and its status must be `green`:

```bash theme={null}
curl -s localhost:6333/collections/COLLECTION | jq -r '.result.status'
```

A collection that reports `yellow` is still building its index. One that reports
`red` failed to restore, so recover it again.

## Related pages

* [Upgrade Elasticsearch Across Major Versions](/self-managed/v6.1/upgrade-elasticsearch)
* [Back Up and Restore Elasticsearch](/self-managed/v6.1/backup-and-restore-elasticsearch)
* [Upgrade Third Party Applications](/self-managed/v6.1/upgrade-third-party-applications)


# Upgrade Third Party Applications
Source: https://support.lilt.com/self-managed/v6.1/upgrade-third-party-applications



## Overview

LILT depends on third-party applications for storage, messaging, networking and
scheduling. The installer upgrades all of them as part of a LILT upgrade, so you
do not normally upgrade one on its own.

Read [Which applications need care](#which-applications-need-care) before you
upgrade. Most components upgrade in place with no attention, but four do not,
and two of those stop the installer rather than risk your data.

## What LILT installs

An on-premise installation includes the following. An AWS EKS installation
replaces MySQL with Amazon RDS, MinIO with Amazon S3, and MetalLB, Flannel and
the local persistent-volume provisioner with the equivalent AWS services.

| Function | Applications |
| - | - |
| Databases and storage | MySQL, MongoDB, ClickHouse, MinIO |
| Search and vectors | Elasticsearch (via the ECK operator), Qdrant |
| Cache and messaging | Dragonfly, RabbitMQ |
| Database proxy | ProxySQL |
| Networking | Istio, Gateway API, MetalLB, Flannel |
| Scheduling and delivery | Argo CD, Argo Workflows, Argo Rollouts, Ray |
| Secrets | HashiCorp Vault, External Secrets Operator |
| Monitoring | Prometheus, metrics-server |
| GPU | NVIDIA GPU Operator or NVIDIA device plugin |

<Note>
  Earlier releases of LILT also installed Grafana, ingress-nginx and Redis.
  Istio and the Gateway API replaced ingress-nginx, and Dragonfly replaced
  Redis. If you are upgrading from a release that installed them, the upgrade
  removes them.
</Note>

## Which applications need care

Most of these applications upgrade in place, keeping their persistent volumes
bound to the new pods, and need no attention from you. Four are different.

<Warning>
  Do not assume that a failed upgrade of a data store repairs itself. Only data
  that LILT can regenerate is rebuilt automatically. MySQL, MinIO and Qdrant
  hold data that exists nowhere else.
</Warning>

**MySQL and MinIO hold all of your LILT data.** On an on-premise installation,
back both up before you upgrade. See [Back up MySQL and
MinIO](#back-up-mysql-and-minio).

**Qdrant cannot skip a minor version, and cannot be rebuilt from the
database.** If your installation is more than one minor version behind, the
installer stops. See [Upgrade Qdrant](/self-managed/v6.1/upgrade-qdrant).

**Elasticsearch cannot cross a major version in one step.** If your
installation is a major version behind, the installer stops. See [Upgrade
Elasticsearch Across Major Versions](/self-managed/v6.1/upgrade-elasticsearch). Elasticsearch
data is derived from the LILT database, so it can be rebuilt, but only in part:
see [Back Up and Restore
Elasticsearch](/self-managed/v6.1/backup-and-restore-elasticsearch), which also covers
registering the snapshot repository the installer does not create.

## Upgrade

Run the installer, which upgrades LILT and every third-party application
together:

```bash theme={null}
sh install-lilt.sh
```

On an AWS EKS installation, run `sh install-lilt-eks.sh` instead.

To upgrade a single application, run its install script. Using ClickHouse as an
example:

```bash theme={null}
sh install_scripts/install-clickhouse.sh
```

Each script runs `helm upgrade`, which adds a new revision of the release and
leaves the previous one available to `helm rollback`.

<Warning>
  Do not use `helm delete` or `helm uninstall` to recover from a failed
  upgrade. Uninstalling removes every revision of the release, and for most of
  these applications it deletes the persistent volume claim with it. Use
  `helm rollback` instead.
</Warning>

## Back up MySQL and MinIO

This procedure applies to an on-premise installation, where MySQL and MinIO run
in the cluster. An AWS EKS installation keeps this data in Amazon RDS and Amazon
S3, so back those up with RDS snapshots and S3 object versioning instead. This
procedure does not apply there.

### 1. Stop writes

Disable LILT `front` so that nothing writes to MySQL or MinIO while you copy
the data:

```bash theme={null}
vi lilt/environments/seed_custom_values/values.yaml

# Set front to disabled:
front:
  enabled: false

sh install_scripts/install-lilt-charts.sh
```

### 2. Back up MySQL

Record which database migrations have been applied. You need this list to
restore, and it is specific to your installation, so capture it now rather than
reusing one from another system:

```bash theme={null}
export db_pass="DB_PASSWORD"

kubectl exec -n lilt mysql-0 -- \
  mysql --user root -p$db_pass lilt_dev -N -e 'SELECT name FROM SequelizeMeta' \
  > sequelize_meta.txt
```

Substitute your database password for `DB_PASSWORD`.

Create the dump and copy it off the pod:

```bash theme={null}
kubectl exec -n lilt mysql-0 -- /bin/bash -c \
  "mysqldump --host mysql.lilt.svc.cluster.local --user root -p$db_pass lilt_dev > /tmp/mysql_dump.sql"

kubectl cp lilt/mysql-0:/tmp/mysql_dump.sql ./mysql_dump.sql
```

### 3. Back up MinIO

MinIO stores objects on a persistent volume, so you copy the volume's contents.
All LILT data is under the `lilt` subdirectory of the claim.

```bash theme={null}
kubectl get pvc -n lilt | grep minio
```

The output names the volume, for example
`pvc-f6c7eda9-e7bb-4975-bb40-80c808718d0d`. Connect to the worker node and copy
it:

```bash theme={null}
mkdir /backup
cp -a /liltdata/PVC_NAME /backup/PVC_NAME
```

Substitute the volume name for `PVC_NAME`.

### 4. Re-enable front

```bash theme={null}
vi lilt/environments/seed_custom_values/values.yaml

# Set front to enabled:
front:
  enabled: true

sh install_scripts/install-lilt-charts.sh
```

## Restore MySQL and MinIO

### Restore MySQL

Copy the dump back to the pod and load it:

```bash theme={null}
kubectl cp ./mysql_dump.sql lilt/mysql-0:/tmp/mysql_dump.sql

kubectl exec -n lilt mysql-0 -- /bin/bash -c \
  "mysql --user root -p$db_pass -D lilt_dev < /tmp/mysql_dump.sql"
```

Restore the migration list you captured in step 2. The dump records migration
filenames with the wrong extension, so LILT re-runs migrations that have already
been applied unless you restore the list:

```bash theme={null}
while read -r name; do
  kubectl exec -n lilt mysql-0 -- \
    mysql -u root -p$db_pass lilt_dev \
    -e "INSERT IGNORE INTO \`SequelizeMeta\` VALUES (\"$name\")"
done < sequelize_meta.txt
```

### Restore MinIO

Copy the `lilt` directory from your backup into the new volume. Do not
overwrite data that the new volume already holds:

```bash theme={null}
kubectl get pvc -n lilt | grep minio

cp -an /backup/OLD_PVC_NAME/lilt /liltdata/NEW_PVC_NAME/
```

Substitute the old and new volume names for `OLD_PVC_NAME` and `NEW_PVC_NAME`.

## Related pages

* [Upgrade Elasticsearch Across Major Versions](/self-managed/v6.1/upgrade-elasticsearch)
* [Back Up and Restore Elasticsearch](/self-managed/v6.1/backup-and-restore-elasticsearch)
* [Upgrade Qdrant](/self-managed/v6.1/upgrade-qdrant)
* [Upgrade LILT](/self-managed/v6.1/upgrade-system)


# User Domains Documentation
Source: https://support.lilt.com/self-managed/v6.1/user-domains-documentation



## Background

#### **What Are Domains?**

* A LILT Domain defines a working group within your LILT organization. Each Domain specifies the translation environment available to the domain members.

#### **Benefits of Domains**

* Simplified User Experience: Users in a Domain can access only the language data and models selected and the translation jobs created within that Domain.

* Enhanced Administrative Control: Administrators easily configure Domains to assign users, and choose the language models, file loaders, and translation preferences.

* Improved Data Privacy and Security: Domains can be configured to restrict access to sensitive data and maintain confidentiality between teams.

#### Considerations

* When setting up Domains, consider grouping users by departments, projects, or language needs.

* Clearly communicate Domain changes to your team to ensure a smooth transition.

## Steps to create a user Domain

1. **Required Step!** Make sure that `enableDomains` is enabled on your instance prior to uploading SRX. To learn more on how to enable it, follow to [Enable/Disable Features](/self-managed/v6.1/enable-features)

2. Admins must enable Domains under a given user role in User Management

<Frame>
  <img />
</Frame>

## Step 1: Click “Manage” on the left rail

<Frame>
  <img />
</Frame>

## Step 2: Click “Manage Domains”

<Frame>
  <img />
</Frame>

## Step 3: Click “ + New Domain”

<Frame>
  <img />
</Frame>

## Step 4: Enter names of users to be added to a new Domain and click Next

<Frame>
  <img />
</Frame>

## Step 5: Enter the name of the models to be added to the Domain and click Next

<Frame>
  <img />
</Frame>

## Step 6: Name the Domain, enter any other Domain preferences and click “Save Domain”

Available values to set:

* **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.

<Frame>
  <img />
</Frame>

## Step 7: Click on the user profile to switch between Domains

<Frame>
  <img />
</Frame>


# Using Amazon RDS Instead of Local MySQL
Source: https://support.lilt.com/self-managed/v6.1/using-rds-instead-of-mysql

Configure LILT to use Amazon RDS for managed database services instead of a local MySQL installation

## Overview

This guide provides comprehensive instructions for configuring LILT to utilize Amazon Relational Database Service (RDS) as a managed database solution in place of locally deployed MySQL instances within your Kubernetes cluster. Implementing RDS offers significant advantages including enhanced scalability, automated backup management, built-in high availability, and reduced operational overhead for database administration.

## Prerequisites

The following prerequisites must be satisfied before proceeding with the RDS configuration:

1. **AWS Account Access**: An active AWS account with appropriate IAM permissions to create and manage RDS instances
2. **RDS Instance**: A properly configured RDS MySQL instance deployed within the same Virtual Private Cloud (VPC) as your LILT deployment
3. **SSL Certificate Bundle**: The Amazon RDS Certificate Authority (CA) certificate bundle (global-bundle.pem) for establishing secure SSL connections
4. **Kubernetes Secrets**: Pre-configured Kubernetes secrets containing your RDS database credentials

## Configuration Steps

### 1. Prepare RDS Connection Details

Collect and document the following information from your RDS instance configuration:

* **RDS Endpoint**: The fully qualified domain name (FQDN) of your RDS instance
* **Port Number**: Database connection port (default: 3306)
* **Database Name**: The target database schema name
* **Authentication Credentials**: Master username and corresponding password

### 2. Create Kubernetes Secrets

RDS credentials must be securely stored within Kubernetes secrets. The following example demonstrates the standard approach, though your organization may employ alternative secret management solutions such as External Secrets Operator or HashiCorp Vault.

```bash theme={null}
kubectl create secret generic lilt-rds-creds \
  --from-literal=username=your-rds-username \
  --from-literal=password=your-rds-password \
  --from-literal=endpoint=your-rds-endpoint
```

**Note**: The endpoint parameter may alternatively be configured directly within the overlay configuration file, depending on your organizational requirements and deployment preferences.

### 3. Configure SSL Certificates

Secure database connections require proper SSL certificate configuration. The RDS CA certificate bundle must be uploaded to a Kubernetes secret for authentication purposes.

The required certificates can be obtained from the [AWS RDS SSL/TLS Documentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html#:~:text=Any%20commercial%20AWS%20Region).

**Important**: LILT currently requires the global certificate bundle. If utilizing regional certificates, ensure the certificate files are renamed to match the expected global-bundle naming convention.

```bash theme={null}
kubectl create secret generic rds-tls-ca-cert \
  --from-file=global-bundle.pem \
  --from-file=global-bundle.p7b
```

A convenience script is added to the installer. You can update the bundle files
in `<installer_dir>/mysql/rds_ca/` and set the option to generate the secret
file in `install_scripts/run-mysql-migrations.sh` set option `BOOTSTRAP_DB_CA`
accordingly. If `BOOTSTRAP_DB_CA="true"` The installer then will generate the
secret in the required namespace. If you would like to provide the secret from a
different process, you should generate the file as mentioned before.

### 4. Update Overlay Configuration

The overlay configuration file, located at `lilt/environments/seed_custom_values/database.yaml` within the installer directory, serves as the central configuration point for all database-related components.

**Note**: If this overlay is not required for your deployment, ensure the file is cleared to prevent unintended configuration conflicts.

Configure the overlay YAML file with the following settings:

#### Database Connection Settings

Configure the following RDS connection parameters within your overlay file:

* **`rds_host`**: The RDS endpoint URL (optional if configured within the secret)
* **`rds_port`**: Database connection port (default: 3306)
* **`rds_database_name`**: Database schema name (currently limited to 'lilt\_dev')
* **`rds_db_secret_name`**: Reference to the Kubernetes secret containing database credentials (must exist in the deployment namespace)
* **`rds_db_username_key`**: Secret key containing the database username
* **`rds_db_password_key`**: Secret key containing the database password
* **`rds_db_host_key`**: Secret key containing the RDS endpoint
* **`rds_ca_secret`**: Reference to the secret containing CA certificates (global-bundle)

#### Component Configuration

The overlay configuration applies RDS settings across all LILT platform components:

* **Frontend Services**: Web application and API interfaces
* **Neural Services**: Including tag-projection, alignment, and automqm modules
* **Connectors**: Integration and synchronization services
* **Core Services**: Converter, quality assurance, search, and processing modules
* **Core API**: Primary application programming interface
* **Dataflow**: Data pipeline and processing infrastructure

Each component references the existing Kubernetes secret for database authentication rather than generating new credentials. Configuration parameters may be specified either through secret key references or explicit values, providing flexibility in deployment approaches.

The provided example configuration utilizes a unified secret containing username, password, and endpoint values. Organizations requiring alternative configurations should review and adjust component-specific settings accordingly.

### 5. Apply Configuration

Execute the LILT installation procedure with the RDS overlay configuration:

```bash theme={null}
./install-lilt.sh
```

This command applies the overlay configuration to your LILT deployment, establishing connections to the RDS instance for all configured components.

### 6. Upgrade Considerations

While the LILT development team implements rigorous testing procedures, database upgrades inherently carry potential risks. Organizations must implement comprehensive backup strategies before initiating any upgrade procedures to ensure data recovery capabilities in the event of unexpected issues.

**Critical Recommendations**:

* Perform complete database backups before upgrades
* Test upgrade procedures in non-production environments
* Maintain documented rollback procedures
* Verify backup restoration processes regularly

## Overlay File Structure

The overlay configuration file employs a structured approach to managing RDS settings across the LILT platform:

### 1. Global Configuration Variables

The file utilizes YAML anchors (&) and aliases (\*) to define reusable configuration parameters:

* Database connection specifications (host, port, database name)
* Kubernetes secret references and key mappings
* SSL/TLS certificate configurations
* Shared connection string templates

### 2. Component-Specific Sections

Each platform component maintains its own configuration section with inherited global settings:

* **Frontend Services** (Lines 26-70): Web application and API configurations
* **Neural Services** (Lines 74-117): Machine learning and processing modules
* **Connectors** (Lines 121-150): Integration service configurations
* **Core Services** (Lines 154-231): Primary processing and business logic
* **Core API** (Lines 235-255): API service configurations
* **Dataflow** (Lines 260-302): Data pipeline settings

### 3. Configuration Patterns

The overlay implements consistent configuration patterns across all components:

* **`useExistingSecret.enabled: true`**: Enforces the use of existing Kubernetes secrets for authentication
* **`createSecret: false`**: Prevents automatic generation of new database credentials
* **SSL Certificate Volumes**: Properly configured volume mounts for TLS certificate access
* **Environment Variables**: Standardized database connection parameters
* **YAML Anchors**: Ensures configuration consistency and reduces redundancy

### 4. Security Features

The configuration prioritizes security through several mechanisms:

* **Credential Isolation**: Database credentials are never stored directly in configuration files
* **SSL/TLS Enforcement**: Mandatory encrypted connections to RDS instances
* **Secret Management**: Integration with Kubernetes native secret handling
* **Template-based Connection Strings**: Prevents hardcoding of sensitive connection details

## Configuration Example

The following excerpt demonstrates the overlay configuration structure and implementation:

```yaml theme={null}
# RDS Database Configuration Overlay
# This overlay configures endpoint, username, and password parameters for RDS database connectivity
# across all LILT platform component charts
# Secret Configuration References
rds_db_secret_name: &rds_db_secret_name "lilt-rds-creds"  # Kubernetes secret containing RDS credentials
rds_db_username_key: &rds_db_username_key "username"      # Key for database username within the secret
rds_db_password_key: &rds_db_password_key "password"      # Key for database password within the secret
rds_db_host_key: &rds_db_host_key "endpoint"              # Key for RDS endpoint URL within the secret

# Database Connection Parameters
rds_host: &rds_host null                                  # RDS endpoint (null if provided via secret)
rds_port: &rds_port "3306"                                # Database connection port
rds_database_name: &rds_db_name "lilt"                    # Target database schema name

# SSL/TLS Certificate Configuration
rds_ca_secret: &rds_ca_secret "rds-tls-ca-cert"           # Secret containing RDS CA certificates
# Note: LILT expects certificate keys to be named 'global-bundle.pem' and 'global-bundle.p7b'

# ==================================================
# Template Definitions (Do not modify unless required)
# ==================================================
x-rds_ca_certificate_path: &x-rds_ca_certificate_path /rds_cacerts/global-bundle.pem
x-rds_ca_mount_path: &x-rds_ca_mount_path /rds_cacerts
x-rds_jdbc_connection_string: &x-rds_jdbc_connection_string "jdbc:mysql://${DB_HOST}:${DB_PORT}/${DB_NAME}"

# Component-Specific Configurations
front:
  onpremValues:
    init:
      enabled: true
    config:
      database:
        useExistingSecret:
          enabled: true
          existingSecretRef: *rds_db_secret_name
          # Key mappings within the referenced secret
          # Falls back to front_secret_values/front_configmap_values if unspecified
          userKey: *rds_db_username_key
          passKey: *rds_db_password_key
          hostKey: *rds_db_host_key
          # portKey: (optional - uses default port if unspecified)
          # databaseKey: (optional - uses default database if unspecified)
        createSecret: false  # Prevents creation of new secrets

      front_secret_values:
        dbPwd: null  # Null when using existing secret
      front_configmap_values:
        dbHost: *rds_host
        dbPort: *rds_port
        dbUser: null  # Null when using existing secret
        dbName: *rds_db_name
    env:
      SSL_MYSQL_PATH_TO_CA: *x-rds_ca_certificate_path
      SSL_MYSQL_PATH_TO_CERT: null  # Client certificate (optional)
      SSL_MYSQL_PATH_TO_KEY: null   # Client key (optional)
    
    # Volume configuration for SSL certificates
    sslCertSecretVolumes:
      - name: tls-client-certificates
        secret:
          secretName: "tls-client-certificates"
      - name: *rds_ca_secret
        secret:
          secretName: *rds_ca_secret
    
    # Volume mount configuration for SSL certificates
    sslCertSecretVolumeMounts:
      - name: tls-client-certificates
        mountPath: /etc/ssl/client-certs
        readOnly: true
      - name: *rds_ca_secret
        mountPath: *x-rds_ca_mount_path
        readOnly: true
```


# Using S3 instead of MinIO
Source: https://support.lilt.com/self-managed/v6.1/using-s3-instead-of-minio

Configure LILT to use Amazon S3 for object storage instead of the default MinIO installation

## Overview

By default, LILT comes with MinIO enabled. However, if an environment has access to S3 directly, this is the recommended approach.

This document covers configuring LILT to use S3 instead of MinIO--it does not cover how to transition an existing MinIO deployment to S3. Please work with your program manager to facilitate this process.

There are three options for authentication with S3 depending on the type of cluster and EKS configuration:

* **Unmanaged**: Identity and Access Management (IAM) using an AWS access key and secret key
* **Managed (EKS) — IRSA**: IAM Roles for Service Accounts via OIDC federation (legacy; requires an OIDC provider in your cluster)
* **Managed (EKS) — Pod Identity**: EKS Pod Identity Agent (recommended for new EKS environments; no OIDC provider required)

## Uninstall MinIO

There is currently no mechanism in LILT to automatically remove MinIO from a deployment. This is a feature we are working to implement by the end of 2025. In the meantime, MinIO may be removed directly by:

```bash theme={null}
helm uninstall minio
```

## Configure LILT

### Update Secrets

LILT ships with a default AWS credential. This needs to be removed.

Edit `lilt/environments/lilt/secrets.yaml` and remove the following line:

```yaml theme={null}
front:
  onpremValues:
    config:
      front_secret_values:
        s3secretkey: testsecretkey # Only remove this line
```

## Option 1: Unmanaged IAM

### Update Values

### If you plan to use Cloud Upload (direct upload to S3) create an SQS queue

Ref: [https://us-east-1.console.aws.amazon.com/sqs/v3/home?#/create-queue](https://us-east-1.console.aws.amazon.com/sqs/v3/home?#/create-queue)\
You can keep all as default but attach a policy, you'll need to modify it once\
the S3 Bucket is created in the next step.\
Sample Policy:

```json theme={null}
{
  "Version": "2012-10-17",
  "Id": "__default_policy_ID",
  "Statement": [
    {
      "Sid": "__owner_statement",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<AWS_ACCOUNT>:root"
      },
      "Action": "SQS:*",
      "Resource": "arn:aws:sqs:<AWS_REGION>:<AWS_ACCOUNT>:<QUEUE_NAME>"
    }
  ]
}
```

Keep note of the Queue name and URL for later use.

### Create an S3 bucket in case you don't have one

Ref: [https://us-east-1.console.aws.amazon.com/s3/bucket/create](https://us-east-1.console.aws.amazon.com/s3/bucket/create)
Keep note of the name for later use.\
Attach the following CORS policy to the bucket

```json theme={null}
[
  {
    "AllowedOrigins": ["https://yourdomain.com"],
    "AllowedMethods": ["GET", "PUT", "POST", "HEAD"],
    "AllowedHeaders": ["*"],
    "ExposeHeaders": ["ETag"],
    "MaxAgeSeconds": 3000
  }
]
```

Configure the bucket to send Upload notifications to the SQS Queue you created in the previous step. Under `Properties`, add an `Event Notification`.

```json theme={null}
Event types -> Object Creation:
All object create events
s3:ObjectCreated:*

Put
s3:ObjectCreated:Put
---
Destination: SQS queue
---
SQS queue: <QUEUE_NAME>

```

### Update SQS Access policy (if needed) to allow the S3 bucket to write on the SQS queue

Ref: [https://us-east-1.console.aws.amazon.com/sqs/v3/home?#/queues](https://us-east-1.console.aws.amazon.com/sqs/v3/home?#/queues)
Access your queue and click on Access policy Edit button.
Add the following block to the statements:

```json theme={null}
{
  "Sid": "AllowS3SendMessage",
  "Effect": "Allow",
  "Principal": {
    "Service": "s3.amazonaws.com"
  },
  "Action": "SQS:SendMessage",
  "Resource": "arn:aws:sqs:<AWS_REGION>:<AWS_ACCOUNT>:<QUEUE_NAME>",
  "Condition": {
    "ArnEquals": {
      "aws:SourceArn": ["arn:aws:s3:::<BUCKET_NAME>"]
    }
  }
}
```

### Create an IAM Policy:

Ref: [https://us-east-1.console.aws.amazon.com/iam/home?#/policies/create](https://us-east-1.console.aws.amazon.com/iam/home?#/policies/create)
Replace the fields `<...>` with the names you got in the previous steps\
Keep note of policy name for later use.

```json theme={null}
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::<BUCKET_NAME>",
        "arn:aws:s3:::<BUCKET_NAME>/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
          "sqs:SendMessage",
          "sqs:ReceiveMessage",
          "sqs:DeleteMessage",
          "sqs:GetQueueAttributes"
      ],
      "Resource": "arn:aws:sqs:<AWS_REGION>:<AWS_ACCOUNT>:<QUEUE_NAME>"
    }
  ]
}
```

### Create an AWS user for the workload

Ref: [https://us-east-1.console.aws.amazon.com/iam/home?#/users/create](https://us-east-1.console.aws.amazon.com/iam/home?#/users/create)
Keep note of the username you generate for later use.\
Attach the policy generated in the previous step

### Collect the following information for your bucket:

```
AWS_ACCESS_KEY: <AWS_ACCESS_KEY>
AWS_SECRET_KEY: <AWS_SECRET_KEY>
AWS_BUCKET: <AWS_BUCKET>
AWS_REGION: <AWS_REGION>
AWS_S3_ENDPOINT_URL: <AWS_S3_ENDPOINT_URL>
AWS_S3_ENDPOINT_URL_SSL: <AWS_S3_ENDPOINT_URL_SSL>
UPLOADER_SUBSCRIPTION_NAME: <QUEUE_URL>
```

```
AWS_S3_ENDPOINT_URL: http://s3.us-east-1.amazonaws.com
AWS_S3_ENDPOINT_URL_SSL: https://s3.us-east-1.amazonaws.com
```

> Remember to change the region in the example URLs (e.g., `us-east-1`) if your S3 bucket is in a different AWS region.

Edit your override values at `lilt/environments/lilt/values.yaml`.

Add all the following values, replacing values within `<>` with the values documented from above:

```yaml theme={null}
AWS_ACCESS_KEY: &AWS_ACCESS_KEY <AWS_ACCESS_KEY>
AWS_SECRET_KEY: &AWS_SECRET_KEY <AWS_SECRET_KEY>
AWS_BUCKET: &AWS_BUCKET <AWS_BUCKET>
AWS_REGION: &AWS_REGION <AWS_REGION>
AWS_S3_ENDPOINT_URL: &AWS_S3_ENDPOINT_URL <AWS_S3_ENDPOINT_URL>

# Compound strings, please replace <AWS_BUCKET> with the bucket name and keep the rest of the text 
S3_WPA_PATH: &S3_WPA_PATH "s3://<AWS_BUCKET>/wpa/"
S3_TRAINED_DATA_PATH: &S3_TRAINED_DATA_PATH "s3://<AWS_BUCKET>/trained/"
S3_TESSERACT_PATH: &S3_TESSERACT_PATH "s3://<AWS_BUCKET>/tesseract/"
S3_MINIO_ENDPOINT: &S3_MINIO_ENDPOINT s3://<AWS_BUCKET>

UPLOADER_SUBSCRIPTION_NAME: &UPLOADER_SUBSCRIPTION_NAME "https://sqs.<AWS_REGION>.amazonaws.com/<AWS_ACCOUNT>/<QUEUE_NAME>"
UPLOADER_STORAGETYPE: &UPLOADER_STORAGETYPE s3
UPLOADER_EVENT_SOURCE_TYPE: &UPLOADER_EVENT_SOURCE_TYPE sqs
UPLOADER_MAX_FILE_SIZE_DEFAULT: &UPLOADER_MAX_FILE_SIZE_DEFAULT "2147483648"
AV_SCANNER_HTTP_TIMEOUT_MS: &AV_SCANNER_HTTP_TIMEOUT_MS "3600"

### ---- NO NEED TO MODIFY BELOW ---- ###
front:
  onpremValues:
    env:
      UPLOADER_SUBSCRIPTION_NAME: *UPLOADER_SUBSCRIPTION_NAME
      UPLOADER_EVENT_SOURCE_TYPE: *UPLOADER_EVENT_SOURCE_TYPE
      AWS_SQS_ACCESSKEY: *AWS_ACCESS_KEY
      AWS_SQS_SECRETKEY: *AWS_SECRET_KEY
      UPLOADER_MAX_FILE_SIZE_DEFAULT: *UPLOADER_MAX_FILE_SIZE_DEFAULT
      AV_SCANNER_HTTP_TIMEOUT_MS: *AV_SCANNER_HTTP_TIMEOUT_MS
      MM_BUCKET: *AWS_BUCKET
    config:
      front_secret_values:
        awsSecretAccessKey: *AWS_SECRET_KEY
        s3secretkey: *AWS_SECRET_KEY
      front_configmap_values:
        awsAccessKeyId: *AWS_ACCESS_KEY
        bucket: *AWS_BUCKET
        s3-region: *AWS_REGION
        awsRegion: *AWS_REGION
        s3accesskey: *AWS_ACCESS_KEY
        awsS3Bucket: *AWS_BUCKET
        awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
        awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
        awsS3EndpointUrlPublic: *AWS_S3_ENDPOINT_URL_SSL
        storagetype: *UPLOADER_STORAGETYPE

converter:
  onpremValues:
    config:
      awsSecretAccessKey: *AWS_SECRET_KEY
      s3-privatekey: *AWS_SECRET_KEY
      s3-accesskey: *AWS_ACCESS_KEY
      awsAccessKeyId: *AWS_ACCESS_KEY
      bucket: *AWS_BUCKET
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
    app:
      bucketname: *AWS_BUCKET
      args:
        s3-endpoint: *AWS_S3_ENDPOINT_URL_SSL
        s3-region: *AWS_REGION
        bucket: *AWS_BUCKET

assignment:
  onpremValues:
    app:
      bucketname: *AWS_BUCKET

auditlog:
  onpremValues:
    app:
      bucketname: *AWS_BUCKET

batch-tb:
  onpremValues:
    app:
      bucketname: *AWS_BUCKET

tb:
  onpremValues:
    app:
      bucketname: *AWS_BUCKET

tm:
  onpremValues:
    app:
      bucketname: *AWS_BUCKET
      args:
        s3-endpoint: *AWS_S3_ENDPOINT_URL_SSL
        s3-region: *AWS_REGION
        bucket: *AWS_BUCKET

indexer:
  onpremValues:
    app:
      bucketname: *AWS_BUCKET

linguist:
  onpremValues:
    app:
      bucketname: *AWS_BUCKET

memory:
  onpremValues:
    app:
      bucketname: *AWS_BUCKET

qa:
  onpremValues:
    app:
      bucketname: *AWS_BUCKET

search:
  onpremValues:
    app:
      bucketname: *AWS_BUCKET

segment:
  onpremValues:
    app:
      bucketname: *AWS_BUCKET

tag:
  onpremValues:
    app:
      bucketname: *AWS_BUCKET

watchdog:
  onpremValues:
    app:
      bucketname: *AWS_BUCKET

job:
  onpremValues:
    app:
      bucketname: *AWS_BUCKET
      args:
        s3-endpoint: *AWS_S3_ENDPOINT_URL_SSL
        s3-region: *AWS_REGION
        bucket: *AWS_BUCKET

workflow:
  onpremValues:
    app:
      bucketname: *AWS_BUCKET
      args:
        s3-endpoint: *AWS_S3_ENDPOINT_URL_SSL
        s3-region: *AWS_REGION
        bucket: *AWS_BUCKET

file-translation:
  onpremValues:
    config:
      awsSecretAccessKey: *AWS_SECRET_KEY
      s3-privatekey: *AWS_SECRET_KEY
      s3-accesskey: *AWS_ACCESS_KEY
      awsAccessKeyId: *AWS_ACCESS_KEY
      bucket: *AWS_BUCKET
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
    app:
      bucketname: *AWS_BUCKET
      args:
        s3-endpoint: *AWS_S3_ENDPOINT_URL_SSL
        s3-region: *AWS_REGION
        bucket: *AWS_BUCKET
        s3-accesskey: *AWS_ACCESS_KEY
        s3-privatekey: *AWS_SECRET_KEY

file-job:
  onpremValues:
    config:
      awsSecretAccessKey: *AWS_SECRET_KEY
      s3-privatekey: *AWS_SECRET_KEY
      s3-accesskey: *AWS_ACCESS_KEY
      awsAccessKeyId: *AWS_ACCESS_KEY
      bucket: *AWS_BUCKET
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
    extraInitContainer:
      BUCKETNAME: *AWS_BUCKET
    app:
      bucketname: *AWS_BUCKET
      args:
        s3-endpoint: *AWS_S3_ENDPOINT_URL_SSL
        s3-region: *AWS_REGION
        bucket: *AWS_BUCKET

dataflow:
  onpremValues:
    env:
      MINIO_ENDPOINT: *S3_MINIO_ENDPOINT
      MINIO_ACCESS_KEY: *AWS_ACCESS_KEY
      MINIO_SECRET_KEY: *AWS_SECRET_KEY
      MINIO_REGION: *AWS_REGION

translatev4:
  onpremValues:
    config:
      awsSecretAccessKey: *AWS_SECRET_KEY
      awsAccessKeyId: *AWS_ACCESS_KEY
      bucket: *AWS_BUCKET
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
    init:
      outputPath: *S3_TRAINED_DATA_PATH

updatev4:
  onpremValues:
    config:
      awsSecretAccessKey: *AWS_SECRET_KEY
      awsAccessKeyId: *AWS_ACCESS_KEY
      bucket: *AWS_BUCKET
      awsRegion: *AWS_REGION
      wpaDataStoreBasePath: *S3_WPA_PATH
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL

langid:
  onpremValues:
    config:
      awsSecretAccessKey: *AWS_SECRET_KEY
      awsAccessKeyId: *AWS_ACCESS_KEY
      bucket: *AWS_BUCKET
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL

update-managerv4:
  onpremValues:
    config:
      awsSecretAccessKey: *AWS_SECRET_KEY
      awsAccessKeyId: *AWS_ACCESS_KEY
      bucket: *AWS_BUCKET
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL

routing:
  onpremValues:
    config:
      awsSecretAccessKey: *AWS_SECRET_KEY
      awsAccessKeyId: *AWS_ACCESS_KEY
      bucket: *AWS_BUCKET
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL

batchv4:
  onpremValues:
    config:
      awsSecretAccessKey: *AWS_SECRET_KEY
      awsAccessKeyId: *AWS_ACCESS_KEY
      bucket: *AWS_BUCKET
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL

batch-worker-gpuv4:
  onpremValues:
    config:
      awsSecretAccessKey: *AWS_SECRET_KEY
      awsAccessKeyId: *AWS_ACCESS_KEY
      bucket: *AWS_BUCKET
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL

batch-worker-cpu-3pmt:
  onpremValues:
    config:
      awsSecretAccessKey: *AWS_SECRET_KEY
      awsAccessKeyId: *AWS_ACCESS_KEY
      bucket: *AWS_BUCKET
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL

automqm:
  onpremValues:
    config:
      awsSecretAccessKey: *AWS_SECRET_KEY
      awsAccessKeyId: *AWS_ACCESS_KEY
      bucket: *AWS_BUCKET
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL

alignment:
  onpremValues:
    config:
      awsSecretAccessKey: *AWS_SECRET_KEY
      awsAccessKeyId: *AWS_ACCESS_KEY
      bucket: *AWS_BUCKET
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
    init:
      outputPath: *S3_TRAINED_DATA_PATH

tag-projection:
  onpremValues:
    config:
      awsSecretAccessKey: *AWS_SECRET_KEY
      awsAccessKeyId: *AWS_ACCESS_KEY
      bucket: *AWS_BUCKET
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
    init:
      outputPath: *S3_TRAINED_DATA_PATH

nncache:
  onpremValues:
    config:
      awsSecretAccessKey: *AWS_SECRET_KEY
      awsAccessKeyId: *AWS_ACCESS_KEY
      bucket: *AWS_BUCKET
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL

# Llama inference
llama-vllm-inference:
  onpremValues:
    config:
      awsSecretAccessKey: *AWS_SECRET_KEY
      awsAccessKeyId: *AWS_ACCESS_KEY
      bucket: *AWS_BUCKET
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
    init:
      outputPath: *S3_TRAINED_DATA_PATH

# Whisper inference
llm-inference-whisper:
  onpremValues:
    config:
      awsSecretAccessKey: *AWS_SECRET_KEY
      awsAccessKeyId: *AWS_ACCESS_KEY
      bucket: *AWS_BUCKET
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
    init:
      outputPath: *S3_TRAINED_DATA_PATH

# Gemma3 inference
gemma-vllm-inference:
  onpremValues:
    config:
      awsSecretAccessKey: *AWS_SECRET_KEY
      awsAccessKeyId: *AWS_ACCESS_KEY
      bucket: *AWS_BUCKET
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
    init:
      outputPath: *S3_TRAINED_DATA_PATH
```

#### Run the installer as usual

```bash theme={null}
./install-lilt.sh
```

#### Enable the feature for the organization

Log in to the front pod and enable the Cloud Upload feature.\
This is a one-time enable per ORG\_ID.\
Default ORG\_ID for a new installation is 1.

```bash theme={null}
kubectl exec -it -n lilt $(kubectl get pod -n lilt -lapp=front -o name) -- \
    npm run dist-admin-cli set-org-setting -o <ORG_ID> -s enableDirectToCloudUploads -v true
```

***

## Option 2: Managed (EKS) IRSA

### Create AWS IAM Policy and Role

In the AWS console or via terraform, create IAM role and policy for accessing the s3 bucket and then attach them to each other. The following assumes that you are using an OIDC provider.

```json theme={null}
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::<my-bucket-name>",
        "arn:aws:s3:::<my-bucket-name>/*"
      ]
    }
  ]
}
```

```json theme={null}
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/<OIDC_PROVIDER>"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "<OIDC_PROVIDER>:sub": "system:serviceaccount:<SERVICE_ACCOUNT_NAMESPACE>:<SERVICE_ACCOUNT_NAME>"
        }
      }
    }
  ]
}
```

Once the role and policy are attached, copy the arn. Example:
`arn:aws:iam::<ACCOUNT_ID>:role/<role_name>`

### Create Service Account

Either via terraform or kubectl, create a service account for use by the pods.\
Example using kubectl:

```bash theme={null}
kubectl create serviceaccount <service-account-name> -n <your-namespace>
kubectl annotate serviceaccount <service-account-name> \
  -n <your-namespace> \
  eks.amazonaws.com/role-arn=<your-arm>
```

### Update RBAC

Pods can only reference ONE service account. This overrides any default cluster and pod permissions so any additional requirements must be included within the same RBAC roles.\
For example, `neural` requires access to `pods` and `deployments`, `dataflow` requires access to `argo`, etc....

Create a role yaml and apply it to the cluster:

```yaml theme={null}
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: lilt-batch4-neural-role
  namespace: <your-namespace>
rules:
  - apiGroups: [""]
    resources: ["deployments", "deployments/scale", "jobs", "pods", "pods/status", "pods/log", "configmaps", "secrets"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: ["apps"]
    resources: ["deployments/scale"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

---

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: lilt-argo-workflows-server-role
  namespace: <your-namespace>
rules:
  - apiGroups: [""]
    resources: ["configmaps", "events"]
    verbs: ["get", "watch", "list"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch", "delete"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get", "list"]
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["watch", "create", "patch"]
  - apiGroups: ["argoproj.io"]
    resources:
      - "eventsources"
      - "sensors"
      - "workflows"
      - "workfloweventbindings"
      - "workflowtemplates"
      - "cronworkflows"
    verbs: ["create", "get", "list", "watch", "update", "patch", "delete"]

---

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: lilt-argo-workflows-workflow-role
  namespace: <your-namespace>
rules:
  - apiGroups: ["argoproj.io"]
    resources: ["workflowtaskresults"]
    verbs: ["create", "patch"]

---

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: lilt-argo-workflows-workflow-controller-role
  namespace: <your-namespace>
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create", "get", "list", "watch", "update", "patch", "delete"]
  - apiGroups: [""]
    resources: ["pods/exec"]
    verbs: ["create"]
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "watch", "list"]
  - apiGroups: [""]
    resources: ["persistentvolumeclaims", "persistentvolumeclaims/finalizers"]
    verbs: ["create", "update", "delete", "get"]
  - apiGroups: ["argoproj.io"]
    resources: ["workflows", "workflows/finalizers", "workflowtasksets", "workflowtasksets/finalizers", "workflowartifactgctasks"]
    verbs: ["get", "list", "watch", "update", "patch", "delete", "create"]
  - apiGroups: ["argoproj.io"]
    resources: ["workflowtemplates", "workflowtemplates/finalizers"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["argoproj.io"]
    resources: ["workflowtaskresults", "workflowtaskresults/finalizers"]
    verbs: ["list", "watch", "deletecollection"]
  - apiGroups: ["argoproj.io"]
    resources: ["cronworkflows", "cronworkflows/finalizers"]
    verbs: ["get", "list", "watch", "update", "patch", "delete"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["create", "patch"]
  - apiGroups: [""]
    resources: ["serviceaccounts"]
    verbs: ["get", "list"]
  - apiGroups: ["policy"]
    resources: ["poddisruptionbudgets"]
    verbs: ["create", "get", "delete"]
  - apiGroups: ["coordination.k8s.io"]
    resources: ["leases"]
    verbs: ["create"]
  - apiGroups: ["coordination.k8s.io"]
    resourceNames: ["workflow-controller", "workflow-controller-lease"]
    resources: ["leases"]
    verbs: ["get", "watch", "update", "patch", "delete"]
  - apiGroups: [""]
    resourceNames: ["argo-workflows-agent-ca-certificates"]
    resources: ["secrets"]
    verbs: ["get"]

---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: lilt-argo-workflows-namespace-access
rules:
  - apiGroups: [""]
    resources: ["namespaces"]
    verbs: ["get", "list", "watch"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: lilt-argo-workflows-clusterworkflowtemplates-access
rules:
  - apiGroups: ["argoproj.io"]
    resources: ["clusterworkflowtemplates", "clusterworkflowtemplates/finalizers"]
    verbs: ["get", "list", "watch"]
```

Bind the role to the previously created service account:

```yaml theme={null}
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bind-lilt-batch4-neural-role
  namespace: <your-namespace>
subjects:
- kind: ServiceAccount
  name: <your-service-account>
  namespace: <your-namespace>
roleRef:
  kind: Role
  name: lilt-batch4-neural-role
  apiGroup: rbac.authorization.k8s.io

---

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bind-lilt-argo-workflows-server-role
  namespace: <your-namespace>
subjects:
- kind: ServiceAccount
  name: <your-service-account>
  namespace: <your-namespace>
roleRef:
  kind: Role
  name: lilt-argo-workflows-server-role
  apiGroup: rbac.authorization.k8s.io

---

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bind-lilt-argo-workflows-workflow-role
  namespace: <your-namespace>
subjects:
- kind: ServiceAccount
  name: <your-service-account>
  namespace: <your-namespace>
roleRef:
  kind: Role
  name: lilt-argo-workflows-workflow-role
  apiGroup: rbac.authorization.k8s.io

---

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bind-lilt-argo-workflows-workflow-controller-role
  namespace: <your-namespace>
subjects:
- kind: ServiceAccount
  name: <your-service-account>
  namespace: <your-namespace>
roleRef:
  kind: Role
  name: lilt-argo-workflows-workflow-controller-role
  apiGroup: rbac.authorization.k8s.io

---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: bind-lilt-argo-workflows-namespace-access
subjects:
- kind: ServiceAccount
  name: <your-service-account>
  namespace: <your-namespace>
roleRef:
  kind: ClusterRole
  name: lilt-argo-workflows-namespace-access
  apiGroup: rbac.authorization.k8s.io

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: bind-lilt-argo-workflows-clusterworkflowtemplates-access
subjects:
- kind: ServiceAccount
  name: <your-service-account>
  namespace: <your-namespace>
roleRef:
  kind: ClusterRole
  name: lilt-argo-workflows-clusterworkflowtemplates-access
  apiGroup: rbac.authorization.k8s.io
```

### Update Values

First, collect the following information for your bucket:

```bash theme={null}
AWS_BUCKET: <AWS_BUCKET>
AWS_REGION: <AWS_REGION>
AWS_S3_ENDPOINT_URL: <AWS_S3_ENDPOINT_URL>
AWS_S3_ENDPOINT_URL_SSL: <AWS_S3_ENDPOINT_URL_SSL>
STORAGETYPE: s3
```

```bash theme={null}
AWS_S3_ENDPOINT_URL: http://s3.us-east-1.amazonaws.com
AWS_S3_ENDPOINT_URL_SSL: https://s3.us-east-1.amazonaws.com
```

> Remember to change the region in the example URLs (e.g., `us-east-1`) if your S3 bucket is in a different AWS region.

Service Account:

```bash theme={null}
<SERVICE_ACCOUNT>: <service-account-name>
```

Edit your override values at `lilt/environments/lilt/values.yaml`.

Add all of the following values, replacing values within `<>` with the values documented from above:

```yaml theme={null}
AWS_BUCKET: &AWS_BUCKET <AWS_BUCKET>
AWS_REGION: &AWS_REGION <AWS_REGION>
AWS_S3_ENDPOINT_URL: &AWS_S3_ENDPOINT_URL <AWS_S3_ENDPOINT_URL>
AWS_S3_ENDPOINT_URL_SSL: &AWS_S3_ENDPOINT_URL_SSL <AWS_S3_ENDPOINT_URL_SSL>
STORAGETYPE: &STORAGETYPE s3
SERVICE_ACCOUNT: &SERVICE_ACCOUNT <SERVICE_ACCOUNT>

# Compound strings, please replace <AWS_BUCKET> with the bucket name and keep the rest of the text
S3_WPA_PATH: &S3_WPA_PATH "s3://<AWS_BUCKET>/wpa/"
S3_TRAINED_DATA_PATH: &S3_TRAINED_DATA_PATH "s3://<AWS_BUCKET>/trained/"

front:
  enabled: true
    env:
      MM_BUCKET: *AWS_BUCKET
      UPLOADER_EVENT_SOURCE_TYPE: *STORAGETYPE
      UPLOADER_STORAGETYPE: *STORAGETYPE
    config:
      front_configmap_values:
        awsAccessKeyId: ""
        awsRegion: *AWS_REGION
        awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
        awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
        awsS3EndpointUrlPublic: *AWS_S3_ENDPOINT_URL
        awsS3Bucket: *AWS_BUCKET
        s3accesskey: ""
      front_secret_values:
        awsSecretAccessKey: ""
        s3secretkey: ""
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

converter:
  enabled: true
  onpremValues:
    config:
    app:
      bucketname: *AWS_BUCKET
      args:
        s3SslVerificationMode: NONE
        storagetype: *STORAGETYPE
        bucket: *AWS_BUCKET
        s3-endpoint: *AWS_S3_ENDPOINT_URL
        s3-region: *AWS_REGION
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

qa:
  enabled: true
  onpremValues:
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

linguist:
  enabled: true
  onpremValues:
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

search:
  enabled: true
  onpremValues:
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

tm:
  enabled: true
  onpremValues:
    app:
      bucketname: *AWS_BUCKET
      args:
        storagetype: *STORAGETYPE
        bucket: *AWS_BUCKET
        s3-endpoint: *AWS_S3_ENDPOINT_URL
        s3-region: *AWS_REGION
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

tb:
  enabled: true
  onpremValues:
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

batch-tb:
  enabled: true
  onpremValues:
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

indexer:
  enabled: true
  onpremValues:
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

segment:
  enabled: true
  onpremValues:
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

file-translation:
  enabled: true
  onpremValues:
    app:
      bucketname: *AWS_BUCKET
      args:
        s3-accesskey: ""
        s3-privatekey: ""
        storagetype: *STORAGETYPE
        bucket: *AWS_BUCKET
        s3-endpoint: *AWS_S3_ENDPOINT_URL
        s3-region: *AWS_REGION
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

job:
  enabled: true
  onpremValues:
    env:
      BUCKETNAME: *AWS_BUCKET
    app:
      bucketname: *AWS_BUCKET
      args:
        storagetype: *STORAGETYPE
        bucket: *AWS_BUCKET
        s3-endpoint: *AWS_S3_ENDPOINT_URL
        s3-region: *AWS_REGION
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

tag:
  enabled: true
  onpremValues:
    env:
      BUCKETNAME: *AWS_BUCKET
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

auditlog:
  enabled: true
  onpremValues:
    env:
      BUCKETNAME: *AWS_BUCKET

assignment:
  enabled: true
  onpremValues:
    env:
      BUCKETNAME: *AWS_BUCKET
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

workflow:
  enabled: true
  onpremValues:
    env:
      BUCKETNAME: *AWS_BUCKET
    app:
      bucketname: *AWS_BUCKET
      args:
        storagetype: *STORAGETYPE
        bucket: *AWS_BUCKET
        s3-endpoint: *AWS_S3_ENDPOINT_URL
        s3-region: *AWS_REGION
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

dataflow:
  enabled: true
  onpremValues:
    env:
      MINIO_ENDPOINT: *AWS_S3_ENDPOINT_URL
      MINIO_ACCESS_KEY: ""
      MINIO_SECRET_KEY: ""
      MINIO_REGION: *AWS_REGION
      MINIO_SSL_CERT_FILE: ""
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

file-job:
  enabled: true
  onpremValues:
    config:
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsRegion: *AWS_REGION
      awsSecretAccessKey: ""
      awsAccessKeyId: ""
    env:
      BUCKETNAME: *AWS_BUCKET
    app:
      bucketname: *AWS_BUCKET
      args:
        storagetype: *STORAGETYPE
        bucket: *AWS_BUCKET
        s3-endpoint: *AWS_S3_ENDPOINT_URL
        s3-region: *AWS_REGION
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT
    extraInitContainer:
      BUCKETNAME: *AWS_BUCKET

memory:
  enabled: true
  onpremValues:
    env:
      BUCKETNAME: *AWS_BUCKET
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

notification:
  enabled: true
  onpremValues:
    env:
      BUCKETNAME: *AWS_BUCKET
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

translatev4:
  enabled: true
  onpremValues:
    config:
      awsSecretAccessKey: ""
      awsAccessKeyId: ""
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
      caBundlePath: ""
      storageType: *STORAGETYPE
      btcJobBucket: *AWS_BUCKET
      bucket: *AWS_BUCKET
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT
    # Init container to copy neural trained v4 models
    init:
      enabled: true
      outputPath: *S3_TRAINED_DATA_PATH

updatev4:
  enabled: true
  onpremValues:
    config:
      awsSecretAccessKey: ""
      awsAccessKeyId: ""
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
      caBundlePath: ""
      storageType: *STORAGETYPE
      btcJobBucket: *AWS_BUCKET
      bucket: *AWS_BUCKET
      wpaDataStoreBasePath: *S3_WPA_PATH
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

langid:
  enabled: true
  onpremValues:
    config:
      awsSecretAccessKey: ""
      awsAccessKeyId: ""
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
      caBundlePath: ""
      storageType: *STORAGETYPE
      bucket: *AWS_BUCKET
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

update-managerv4:
  enabled: true
  onpremValues:
    config:
      awsSecretAccessKey: ""
      awsAccessKeyId: ""
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
      caBundlePath: ""
      storageType: *STORAGETYPE
      bucket: *AWS_BUCKET
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

routing:
  enabled: true
  # All messages from other teams' services go through the routing service.
  # Increase the number of replicas in environments with high load.
  onpremValues:
    config:
      awsSecretAccessKey: ""
      awsAccessKeyId: ""
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
      caBundlePath: ""
      storageType: *STORAGETYPE
      bucket: *AWS_BUCKET
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

batchv4:
  enabled: true
  onpremValues:
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT
    config:
      awsSecretAccessKey: ""
      awsAccessKeyId: ""
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
      storageType: *STORAGETYPE
      bucket: *AWS_BUCKET

batch-worker-gpuv4:
  enabled: true
  onpremValues:
    config:
      awsSecretAccessKey: ""
      awsAccessKeyId: ""
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
      caBundlePath: ""
      storageType: *STORAGETYPE
      bucket: *AWS_BUCKET
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

batch-worker-cpu-3pmt:
  enabled: true
  onpremValues:
    config:
      awsSecretAccessKey: ""
      awsAccessKeyId: ""
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
      caBundlePath: ""
      storageType: *STORAGETYPE
      bucket: *AWS_BUCKET
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

automqm:
  enabled: true
  onpremValues:
    config:
      awsSecretAccessKey: ""
      awsAccessKeyId: ""
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
      caBundlePath: ""
      storageType: *STORAGETYPE
      bucket: *AWS_BUCKET
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

alignment:
  enabled: true
  onpremValues:
    config:
      awsSecretAccessKey: ""
      awsAccessKeyId: ""
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
      caBundlePath: ""
      storageType: *STORAGETYPE
      bucket: *AWS_BUCKET
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT
    init:
      outputPath: *S3_TRAINED_DATA_PATH

tag-projection:
  enabled: true
  onpremValues:
    config:
      awsSecretAccessKey: ""
      awsAccessKeyId: ""
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
      caBundlePath: ""
      storageType: *STORAGETYPE
      bucket: *AWS_BUCKET
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT
    init:
      outputPath: *S3_TRAINED_DATA_PATH

nncache:
  enabled: true
  onpremValues:
    config:
      awsSecretAccessKey: ""
      awsAccessKeyId: ""
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
      caBundlePath: ""
      storageType: *STORAGETYPE
      bucket: *AWS_BUCKET
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT

# Llama inference
llama-vllm-inference:
  enabled: true
  onpremValues:
    config:
      awsSecretAccessKey: ""
      awsAccessKeyId: ""
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
      caBundlePath: ""
      storageType: *STORAGETYPE
      bucket: *AWS_BUCKET
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT
    init:
      outputPath: *S3_TRAINED_DATA_PATH

# Whisper inference
llm-inference-whisper:
  enabled: true
  onpremValues:
    config:
      awsSecretAccessKey: ""
      awsAccessKeyId: ""
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
      caBundlePath: ""
      storageType: *STORAGETYPE
      bucket: *AWS_BUCKET
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT
    init:
      outputPath: *S3_TRAINED_DATA_PATH

# Gemma3 inference
gemma-vllm-inference:
  enabled: true
  onpremValues:
    config:
      awsSecretAccessKey: ""
      awsAccessKeyId: ""
      awsRegion: *AWS_REGION
      awsS3EndpointUrl: *AWS_S3_ENDPOINT_URL
      awsS3EndpointUrlSsl: *AWS_S3_ENDPOINT_URL_SSL
      caBundlePath: ""
      storageType: *STORAGETYPE
      bucket: *AWS_BUCKET
    serviceAccount:
      enabled: true
      name: *SERVICE_ACCOUNT
    init:
      outputPath: *S3_TRAINED_DATA_PATH
```

## Option 3: Managed (EKS) — Pod Identity

EKS Pod Identity is the recommended authentication method for new EKS environments. It does not require an OIDC provider and uses the EKS Pod Identity Agent DaemonSet to intercept IMDS credential requests.

### Prerequisites

The `eks-pod-identity-agent` add-on must be enabled on your EKS cluster. If you are using the Lilt-managed `lilt-aws-env` Terraform module, this is enabled by default.

### Required AWS IAM Permissions

The operator performing setup needs `eks:CreatePodIdentityAssociation` on the cluster. This replaces the `oidc:CreateOIDCProvider` permission required by IRSA and does not require managing a separate OIDC provider.

### Create AWS IAM Policy and Role

Create an IAM policy granting access to the S3 bucket:

```json theme={null}
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::<my-bucket-name>",
        "arn:aws:s3:::<my-bucket-name>/*"
      ]
    }
  ]
}
```

Create an IAM role with a trust policy for EKS Pod Identity:

```json theme={null}
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ]
    }
  ]
}
```

Attach the policy to the role and note the role ARN.

### Create Pod Identity Association

Bind the IAM role to the Kubernetes service account using an EKS Pod Identity association. Via the AWS CLI:

```bash theme={null}
aws eks create-pod-identity-association \
  --cluster-name <CLUSTER_NAME> \
  --namespace <SERVICE_ACCOUNT_NAMESPACE> \
  --service-account <SERVICE_ACCOUNT_NAME> \
  --role-arn <ROLE_ARN>
```

No service account annotation is required — the association is managed by EKS directly.

### Create Service Account

Create the Kubernetes service account (no annotation needed):

```bash theme={null}
kubectl create serviceaccount <service-account-name> -n <your-namespace>
```

### Update RBAC

See the [IRSA RBAC section](#update-rbac) above — the same RBAC Role and RoleBinding apply for Pod Identity.

### Update Values

The Helm values configuration is identical to Option 2 (IRSA). Set `serviceAccount.name` to match the service account bound by the Pod Identity association. AWS credentials (`awsAccessKeyId`, `awsSecretAccessKey`) should be left empty — the Pod Identity Agent injects credentials automatically via IMDS.

```yaml theme={null}
front:
  onpremValues:
    config:
      front_configmap_values:
        awsAccessKeyId: ""
        awsRegion: <AWS_REGION>
        awsS3EndpointUrl: <AWS_S3_ENDPOINT_URL>
        awsS3EndpointUrlSsl: <AWS_S3_ENDPOINT_URL_SSL>
        awsS3Bucket: <AWS_BUCKET>
        s3accesskey: ""
      front_secret_values:
        awsSecretAccessKey: ""
        s3secretkey: ""
    serviceAccount:
      enabled: true
      name: <SERVICE_ACCOUNT>
```

Repeat the `serviceAccount` block for each component as shown in Option 2.

## Cloud Upload setup (front service)

The Cloud Upload feature is owned by the `front` service and builds on top of the S3 bucket/credentials already defined above. The values below summarize the environment variables that must be provided so front can sign presigned URLs and advertise the `s3` storage backend:

```yaml theme={null}
front:
  onpremValues:
    env:
      MM_BUCKET: *AWS_BUCKET
      UPLOADER_EVENT_SOURCE_TYPE: *UPLOADER_EVENT_SOURCE_TYPE
      UPLOADER_STORAGETYPE: *STORAGETYPE
      UPLOADER_S3_ENDPOINT: *AWS_S3_ENDPOINT_URL
      UPLOADER_S3_REGION: *AWS_REGION
```

The field values should reuse the same anchors (`*AWS_BUCKET`, `*STORAGETYPE`, etc.) that other services already consume so all clients target the same bucket/region. `MM_BUCKET` is the bucket where uploads land, and the `UPLOADER_*` variables tell front which storage type and endpoint to advertise in the signed URLs.

* `MM_BUCKET` – the S3 bucket where uploads land and that matches the `awsS3Bucket`/`bucket` values used across the values.yaml.
* `UPLOADER_EVENT_SOURCE_TYPE` and `UPLOADER_STORAGETYPE` – both should mirror the `STORAGETYPE` anchor (typically `s3`) so the service advertises the correct storage backend in the presigned URLs.
* The `front` pod’s IAM role / IRSA service account must have the `s3:GetObject`, `s3:PutObject`, `s3:ListBucket`, and `s3:DeleteObject` permissions on the bucket because it signs upload URLs.

After installing or updating the platform, you must enable the Cloud Upload feature for each organization. While connected to the front pod, run the `dist-admin-cli` command provided earlier:

```bash theme={null}
kubectl exec -it -n lilt $(kubectl get pod -n lilt -lapp=front -o name) -- \
    npm run dist-admin-cli set-org-setting -o <ORG_ID> -s enableDirectToCloudUploads -v true
```

This command both turns on the feature and lets the front service exchange metadata with the Cloud Upload API. With the env vars in place and the org setting enabled, your applications can request presigned URLs directly from front and push files straight to the bucket without passing through the API tunnel.


# Language Models
Source: https://support.lilt.com/self-managed/v6.1/v2-language-models



## Supported Languages

### V3 Languages

Starting in V3, our models will be trained in groups as opposed to single language pairs.

| **Language Grouping** | **Explanation** | **Codes** |
| - | - | - |
| **Asian:** English, Japanese, Korean, Chinese (Simplified), Chinese (Traditional) | Any two languages in this grouping | EN,JA,KO,ZH,ZT |
| **Eastern European:** English, Belarusian, Bulgarian, Czech, Croatian, Lithuanian, Latvian, Polish, Romanian, Russian, Slovak, Slovenian, Albanian, Serbian, Ukrainian | Any two languages in this grouping | EN,BE,BG,CS,HR,LT,LV,PL,RO,RU,SK,SL,SQ,SR,UK |
| **Eastern Hemisphere:** English, Arabic, Bengali, Central Kurdish, Persian (Farsi), Dari, Gujarati, Hebrew, Hindi, Kannada, Malayalam, Marathi, Nepali, Panjabi, Pushto, Tamil, Telugu, Tajik, Urdu | Any two languages in this grouping | EN,AR,BN,CKB,FA,FS,GU,HE,HI,KN,ML,MR,NE,PA,PS,TA,TE,TG,UR |
| **European Group 2:** English, Afrikaans, Danish, German, Greek, Amharic, Finnish, Hungarian, Armenian, Dutch, Norwegian, Swedish, Turkish | Any two languages in this grouping | EN,AF,DA,DE,EL,ET,FI,HU,HY,NL,NO,SV,TR |
| **European:** English, German, Spanish, French, Italian, Portuguese | Any two languages in this grouping | EN,DE,ES,FR,IT,PT |
| \*\*Other: \*\*English, Indonesian, Igbo, Javanese, Malay, Burmese, Thai, Tagalog, Samoan, Somali, Swahili, Vietnamese | Any two languages in this grouping | EN,ID,IG,JV,MS,MY,TH,TL,SM,SO,SW,VI |

### Unsupported Languages

Enlarges the table by opening it in a full screen dialogOpen

| **Source Language** | **Target Language** | **Contextual AI Support** | **Baseline Model** | **On-Premise** |
| - | - | - | - | - |
| Amharic | English | No | N/A | Not available |
| Azeri | English | No | N/A | Not available |
| Catalan | English | No | N/A | Not available |
| English | Amharic | No | N/A | Not available |
| English | Azeri | No | N/A | Not available |
| English | Bosnian | No | N/A | Not available |
| English | Catalan | No | N/A | Not available |
| English | Creole | No | N/A | Not available |
| English | English | No | N/A | Not available |
| English | Icelandic | No | N/A | Not available |
| English | Kazakh | No | N/A | Not available |
| English | Khmer | No | N/A | Not available |
| English | Kinyarwanda | No | N/A | Not available |
| English | Lao | No | N/A | Not available |
| English | Maori | No | N/A | Not available |
| English | Mongolian | No | N/A | Not available |
| English | Sinhala | No | N/A | Not available |
| English | Zulu | No | N/A | Not available |
| Khmer | English | No | N/A | Not available |
| Kinyarwanda | English | No | N/A | Not available |
| Lao | English | No | N/A | Not available |
| Maori | English | No | N/A | Not available |
| Mongolian | English | No | N/A | Not available |
| Sinhala | English | No | N/A | Not available |
| Zulu | English | No | N/A | Not available |

## Large Language Models

LILT is shipped with:

* META: Llama-3-70B-Chat-AWQ

* OpenAI: Whisper-large-v3

### GPU Requirements

`V4` language models require a minimum of three dedicated GPUs:

| **Service** | **GPU(s)** |
| - | - |
| translatev4 | 1 |
| batchv4 | 1 |
| rayman | 1 (+1 optional) |
| **Total** | **3 (+1 optional)** |

<Note>
  `vmf-service` runs on CPU — after the B25/BM25 retrieval migration, most language pairs no longer require the dense embedding model, so it no longer counts against the GPU budget.
</Note>

<Note>
  `rayman` is the neural translation service and runs on a **single GPU** by default. The neural v4.0 pipeline that provides optional **Uzbek and Chechen** language support requires **one additional GPU**. If that optional feature is disabled, `rayman` runs on a single GPU and the baseline total is four GPUs.
</Note>

<Note>
  Each GPU (or GPU split) must provide at least **24GB of VRAM** (for example, an NVIDIA L4). This is required to run the translate pod successfully.
</Note>

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.

### Costs

For accurate figures, make use of the [AWS cost calculator](https://calculator.aws/) or refer to your cloud provider’s infrastructure cost tool.

### New Language Support

We add new AI-supported languages to the LILT Platform continuously based on three criteria:

* community and customer demand

* availability of training data

* baseline translation quality that is competitive with Google Translate and Microsoft Translator

Email us at [sales@LILT.com](mailto:sales@lilt.com) to request LILT support for additional languages.


# Volume and User Activity
Source: https://support.lilt.com/self-managed/v6.1/volume-and-user-activity



The Volume and User Activity modules allow enterprises to track how much value they get from LILT by volume, throughput, and individual user activity. This data is rolled up at the Organization level, allowing administrators to better understand how people throughout their organization are making use of LILT over time.

## Volume

The Volume tab provides a view into the total volume of words processed through LILT over time.

* **Filters** are available to narrow down the analysis by date range, source language, and target language.
* **Volume Charts** show total instant source words, total verified source words, source word count trends over time.
* **Throughput Charts** show average instant source words per hour, average verified source words per hour, and average human expert processing speed in words per hour. Customers using their own in-house translators and review experts can view statistics related to individual expert performance.
* The **Model Usage** chart shows the total source words translated over time.
* The **Export to CSV** button allows for data export from the Analytics dashboard.

## User Activity

The User Activity tab provides insight into how users are making use of LILT.

* **Filters** are available to narrow down the analysis by date range, source language, and target language.
* **Logins** show total logins, unique logins, and logins over time.
* **User Activity by Workflow Stage** shows the breakdown of user activity by words submitted, words verified, and words reviewed.


# Create an API key
Source: https://support.lilt.com/api-reference/api-keys/create-an-api-key

/api-reference/openapi-bundled.yaml post /v2/api-keys
Mint a new `lilt_*` API key under the caller's current organization. Requires the `apiKey.write` permission.

The plaintext secret is returned in the `key` field of the response and is shown exactly once — store it securely, as it cannot be retrieved again. The optional `userId` lets an admin create a key on behalf of another user who already has a grant in the current organization.




# Get an API key
Source: https://support.lilt.com/api-reference/api-keys/get-an-api-key

/api-reference/openapi-bundled.yaml get /v2/api-keys/{id}
Retrieve a single API key in the caller's current organization.

Keys belonging to other organizations return `404`. Within the current organization, the caller must own the key or hold the `apiKey.read` permission.




# List API keys
Source: https://support.lilt.com/api-reference/api-keys/list-api-keys

/api-reference/openapi-bundled.yaml get /v2/api-keys
Retrieve all non-deleted API keys scoped to the caller's current organization.

Callers with the `apiKey.read` permission see all keys in the organization; all other callers see only their own keys. The plaintext secret is never returned by this endpoint — only the key prefix is shown.




# Remove an API key from listings
Source: https://support.lilt.com/api-reference/api-keys/remove-an-api-key-from-listings

/api-reference/openapi-bundled.yaml delete /v2/api-keys/{id}/permanent
Remove an already-revoked or expired key from the list-keys response. The record is retained; this call only hides it from listings.

The key must already be revoked or expired — this call does not disable an active key. The caller must own the key or hold `apiKey.write` on the current organization.




# Revoke an API key
Source: https://support.lilt.com/api-reference/api-keys/revoke-an-api-key

/api-reference/openapi-bundled.yaml delete /v2/api-keys/{id}
Revoke an API key, preventing further authentication.

The operation is idempotent — revoking an already-revoked key still returns `204`. The caller must own the key or hold `apiKey.write` on the current organization.




# Rotate an API key
Source: https://support.lilt.com/api-reference/api-keys/rotate-an-api-key

/api-reference/openapi-bundled.yaml post /v2/api-keys/{id}/rotate
Replace the prefix and secret of an existing API key, invalidating the previous secret and returning a new plaintext secret. The key's name and expiry are preserved.

The new secret is shown exactly once. Revoked keys cannot be rotated. The caller must own the key or hold `apiKey.write` on the current organization. The request body must be empty.




# 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 <strong>id</strong> request parameter. To retrieve all files, omit the <strong>id</strong> 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).

<a href="/kb/introduction-to-lilt-translation" target=_blank>Refer
to our KB</a> 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' ```




# 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.

<Info>
  **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.
</Info>

## 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). |

<Tip>
  **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.
</Tip>

## 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.

<Note>
  **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.
</Note>


# 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>
  **Tip**

  Upload all of the files first before creating a Job with them.
</Tip>

## 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<String, Object> uploadRequest = new HashMap<>();
        uploadRequest.put("filename", filename);
        uploadRequest.put("type", contentType);

        Map<String, Object> 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<String> response = httpClient.send(request, HttpResponse.BodyHandlers.ofString());

        if (response.statusCode() != 200) {
            throw new RuntimeException("Failed to initiate upload: " + response.body());
        }

        Map<String, Object> 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<String, String> headers = (Map<String, String>) uploadParams.get("headers");
        if (headers != null) {
            headers.forEach(uploadRequestBuilder::header);
        }

        HttpRequest uploadRequest = uploadRequestBuilder.build();
        HttpResponse<String> 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<String, Object> uploadRequest = new HashMap<>();
        uploadRequest.put("filename", filename);
        uploadRequest.put("type", contentType);

        Map<String, Object> 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<String> response = httpClient.send(request, HttpResponse.BodyHandlers.ofString());
        Map<String, Object> initResponse = objectMapper.readValue(response.body(), Map.class);

        String uploadId = (String) initResponse.get("uploadId");
        String key = (String) initResponse.get("key");
        List<Map<String, Object>> 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<String> partResponse = httpClient.send(partRequest, HttpResponse.BodyHandlers.ofString());
                Map<String, Object> 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<String> uploadPartResponse = httpClient.send(uploadPartRequest, HttpResponse.BodyHandlers.ofString());

                Map<String, Object> part = new HashMap<>();
                part.put("ETag", uploadPartResponse.headers().firstValue("etag").orElse(""));
                part.put("PartNumber", partNumber);
                parts.add(part);

                partNumber++;
            }
        }

        // 3. Complete multipart upload
        Map<String, Object> 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<String> 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` |

<Tip>
  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.
</Tip>


# 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.

<Frame>
  <img alt="Image" />
</Frame>

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...

<Frame>
  <img alt="Image" />
</Frame>

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!


# Audit Logs
Source: https://support.lilt.com/self-managed/v6.1/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.<br />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,<br />usually an email | String |
| **userId** | unique identifier for the user | Integer |
| **teamId** | unique identifier for the team | Integer |
| **eventType** | one of "LOGIN\_EVENT",<br />"API\_CALL\_EVENT",<br />"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<br />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<br />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\"}",
}
```


# Brute Force Protection
Source: https://support.lilt.com/self-managed/v6.1/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 <front pod> -- /bin/bash
```

#### Updating the max consecutive failed attempts and block duration

```bash theme={null}
yarn admin-cli update-max-failed-login-attempts -m <updatedMaxConsecutiveLogins> [-b <blockDuration>]
```

```bash theme={null}
npm run dist-admin-cli -- update-max-failed-login-attempts -m <updatedMaxConsecutiveLogins> [-b <blockDuration>]
```

* 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 <email>
```

```bash theme={null}
npm run dist-admin-cli -- unblock-user -e <email>
```

* 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.


# Encryption And Access Control
Source: https://support.lilt.com/self-managed/v6.1/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.


# Information Assurance (IA)
Source: https://support.lilt.com/self-managed/v6.1/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.


# Manage Memory and Termbase
Source: https://support.lilt.com/self-managed/v6.1/manage-memory-and-termbase



## Create new model and add custom assets (Translation memory & Termbase)

* Go to `Contextual AI > Models`

<Frame>
  <img />
</Frame>

* Click on `New model` and enter `Source language`, `Target language` and `Reference data source`

<Frame>
  <img />
</Frame>

<Note>
  If a default model doesn't exist for that language pair, it will also be created
</Note>

<Frame>
  <img />
</Frame>

* To view the model entries, click on `Show source`

<Frame>
  <img />
</Frame>

* Use `Upload files` option to import the `Memory(TM)` and `Termbase(TB)` entries

<Frame>
  <img />
</Frame>

<Note>
  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.
</Note>

* Use `Manage entries` to manage Memory and Termbase

<Frame>
  <img />
</Frame>

* (Optional) Change model `settings` and set `Reviewed` by default

<Frame>
  <img />
</Frame>

* Create a New entry to do the following

  * Create entry to train the memory. To do this, add a `Memory` type entry

  <Frame>
    <img />
  </Frame>

  * Create a `Termbase` entry to overwrite the memory without training it. This is same as glossary or dictionary items

<Frame>
  <img />
</Frame>

* Added `Termbase` entry will be highlighted during the translation

<Frame>
  <img />
</Frame>


# Quick Start Guide
Source: https://support.lilt.com/self-managed/v6.1/quick-start-guide-w-videos



The LILT Playbook exercises require only basic knowledge of the LILT Platform and Instant Translate interface. This guide will help with the LILT features used in each exercise.

<Frame>
  <img />
</Frame>

## Logging into LILT

<Frame>
  <video />
</Frame>

1. Navigate to [http://Lilt.com](http://Lilt.com) .

2. Select “Sign In” in the upper right-hand corner.

3. Sign in with the username and password provided by the LILT team.

## Creating a Job and Project

<Frame>
  <video />
</Frame>

<Frame>
  <img />
</Frame>

1. From the “Jobs” page, select “New Job” in the upper right corner

2. Name the Job

3. Select Source Language

4. Upload Source and Document

5. Select “Add Target Language”

6. Select Target Language

7. Select or create Data Source

8. Select “Add Target Language”

9. Select “Create Job”

<Frame>
  <img />
</Frame>

## Instant Translate

<Frame>
  <video />
</Frame>

<Frame>
  <img />
</Frame>

1. Click “Contextual AI” on the left side of the LILT interface

2. Select “Instant Translate”

3. Select the correct Source and Target language

   a. Click “Advanced” to select memory

4. Paste text for translation

5. Click “Translate”

## Review Mode

<Frame>
  <img />
</Frame>

### Assigning a reviewer

<Frame>
  <video />
</Frame>

1. Instructors can view student projects

2. From the project level click the down arrow to the right of “Translate”

3. Click “Assign”

4. Enter the username of the reviewer

5. Click “Update Settings”

6. The chosen reviewer will receive notification to accept the document for review

7. Reviewer should click “Accept”

8. Next the Reviewer should click “Review” from the notifications tab.

   a. If clicking Review does not open the document, click it one more time.

### Exporting Revision Report

<Frame>
  <video />
</Frame>

<Frame>
  <img />
</Frame>

1. Open Job and Project

2. On the top of the page click “Reports” and then “Revision Report”

<Frame>
  <img />
</Frame>

3. Click “Deliver”

4. Choose “Download Revision Report”

## Creating a vocabulary list (LILT Termbase)

<Frame>
  <img />
</Frame>

<Frame>
  <video />
</Frame>

1. Users can add terms to a vocabulary list in order to keep track of new words encountered in a difficult translation

2. Click “New Term” on the right-hand side of the screen

3. Users can also use Windows shortcut: Alt+A; Mac shortcut: Option+A to open the same screen

4. Enter/Paste in the desired source and target meaning

5. Select “Add Entry”

## Context Search (LILT Concordance)

<Frame>
  <video />
</Frame>

Concordance assists translators and reviewers by providing quick access to information about word and phrase usage in a target language

<Frame>
  <img />
</Frame>

1. Click the book icon on the right side of the screen to open the concordance search.

2. Type in a term or phrase

3. Indicate which language it is, Arabic or English

4. Click the magnifying glass icon to search

## Source Text Editing

<Frame>
  <video />
</Frame>

Source text editing allows a user to change the text to be translated.

<Frame>
  <img />
</Frame>

1. Click the pencil icon to the right of the   segment

2. Edit the source text

3. Click “Save Changes”

## Segment Editing

<Frame>
  <video />
</Frame>

Segment editing is available to the right of each segment

### Split Segment

Ability to break larger segments into smaller segments

<Frame>
  <img />
</Frame>

<Frame>
  <video />
</Frame>

1. Select the desired segment

2. On the right of the selected segment, select “Segment Editing Tools” and then “Split Segment”

3. Drag and drop the green vertical marker to where the segment should be split

4. Confirm the split by selecting the checkmark, or cancel the split by clicking the X

<Frame>
  <img />
</Frame>

### Merging Segments

Can only be performed on split segments, or segments where there are no line breaks in the original formatting

<Frame>
  <img />
</Frame>

<Frame>
  <video />
</Frame>

1. Select the desired segment

2. On the right of the selected segment, select “Merge with next segment.

3. If the merge button is grayed out and not selectable, there is a character break prohibiting the merge (Ex: background paragraph break)