Introduction

LSP (Language Service Provider) is just another name for a subcontractor → a third-party company who has their own XTM instance which is connected to the Contractor’s account and from whom receives translation projects.

At this point, there is an important remark to be made with regard to the two meanings of the term “Subcontractor”.

The first one refers to a separate type of subscription in XTM that is simply called “Subcontractor”. Clients with the aforementioned subscription cannot create projects on their account by themselves or store their own TM/terminology resources - they can only work on projects received from the Contractor and with the use of Contractor’s resources.

This article, however, aims at describing possibilities and constraints put onto a “standard” client who receives a translation project from the Contractor, thus acting as a subcontracting party - a second meaning of the term in question.

LSP project restrictions resulting from Contractor settings

Generally speaking, the LSP can do as much as their Contractor will let them do in a subcontracted project, as it is all set up in the Contractor settings in the main XTM instance and, in most cases, those settings are nowhere to be changed on the LSP side.

LSP access rights

The most important settings for the LSP are located in an LSP profile on the Contractor instance (Users → LSPs → LSP editor → Access rights).

Here the Contractor can define such items as:

• customers to which projects the LSP can be assigned;

• accessibility of LQA results and reports for the LSP (click here for more information);

• customers whose terminology resources the Contractor can allow the LSP to use (if selected at the project creation stage);

• extent of terminology management - what the LSP can actually do with Contractor terminology;

• customers whose translation memory (TM) resources the Contractor can allow the LSP to use (if selected at the project creation stage);

• extent of translation memory (TM) management - what the LSP can actually do with Contractor TM.

Workflow and access

The second place wherein the LSP rights are defined are the Contractor global settings (Configuration → Settings → Translation → Workflow and access).

The naming convention of some of the sections contained therein might seem to be confusing (for example, Linguist general options) but they do apply to LSPs as well. In other words, all the settings displayed there also take effect to LSPs since in the context of assigning actors to a workflow the term “linguist” also refers to subcontractors. Linguist metadata access is the only section in which a distinction is made between “Linguists” (internal linguists) and LSPs (subcontractors).

Other than that, the only option that was designed specifically for LSPs is Show Customer name on LSP account in the Linguist general options section.

Project settings

What cannot the LSP do?

Last but not least, the vast majority of the options pertaining to a given project that are configured during its creation are valid to the LSP (project creation stage) - the sections such as:

• General information (i.e. customer, project template);

• Translation (i.e. source language and target languages, filter template, QA profile, joining files, segment filter profile, pre-processing, subject matter, source files, additional files (reference material, segment ID images));

• Settings (i.e. customer TM and terminology resources, anonymization, disabling term decoration, using not approved memory, marking certain segments as “locked”, monitoring target length);

• Machine translation (all settings);

• Tag settings (all settings).

The settings contained in the above-mentioned sections can only be regulated by the Contractor, and the LSP cannot change it in any way.

There are some options in the Project Editor → General info section of a subcontracted project on the LSP side (if enabled in the global settings by the LSP) which seem to be available for selection, but their potential change will not bring about any effect:

• Translation memory settings: Use not approved memory, Hide repeated segments, Mark segments as locked when:, Disable term decoration, Allow editing of ICE segments;

• Machine translation settings.

What can the LSP do?

There are some options in the Project Editor → General info section of a subcontracted project on the LSP side (if enabled in the global settings by the LSP) which are available for selection/editing, but they serve more as internal information/guidelines and have no direct effect on the project as a whole (the Contractor settings take priority):

• Project name;

• Description;

• Reference ID;

• Payment status;

• Proposal approval status;

• Project Manager;

• Custom fields;

• Due dates (i.e. workflow start date, workflow due date, delivery due date);

As for due dates, the system will make sure to inform the LSP in Workflow editor about any discrepancies in due dates applied to workflow steps between the Contractor and the LSP:

Other than that, the LSP can also add their own workflow steps to a project workflow.

LSP project restrictions independent of Contractor settings

Irrespective of the settings imposed by the Contractor, the LSP also faces other restrictions that are default and expected in the case of subcontracted projects.

1. The LSP does not have access to the Project editor → Estimates section.

2. The LSP cannot re-analyze projects.

3. The LSP cannot archive projects.

4. The LSP has the option to delete the project on their side but cannot delete TM they created within the framework of this project.

5. The LSP cannot force projects to be finished/re-opened.

6. The LSP cannot approve ICE and Leveraged matches.

7. The LSP cannot download a project (general) LQA report (click here for more information).

8. The LSP does not have access to one of the Workbench segment filters: Modification: Any updates to target, status or comments (click here for more information).