Lingoport Wiki - User contributions [en]

Gerrit Data Source Credential

2023-11-17T18:46:08Z

Prosenthal:

= Creating a Gerrit Data Source Credential =
[Administrator]

The Administrator can create the data source credentials by selecting the [[File:CreateIcon.jpg|30px]] ('''Create new credential''') button on the Manage Data Source Credentials page.

'''Select the Gerrit card'''

[[File:GerritCard.png|120px]]

[[File:GerritStepTwo.png|600px]]

'''Enter a username, access token, server URL, and commit message hook URL.'''
* The username will be the user who authors the commits that are pushed back to the repository.
* The token is an HTTP access token associated with the username that you entered. To generate a new token:
** Log into your company's Gerrit web interface as the user you entered above.
** Go to your User Settings page.
** Select '''HTTP Credentials''' on the left navigation bar, or scroll down to that section in the page.
** Click '''GENERATE NEW PASSWORD''', and copy and paste the token that it shows you into the token section of the Gerrit Credential page in Command Center.
** We also recommend storing this token somewhere secure that you can access as well if you ever need to reference it in the future, because each time you generate a new token, it will invalidate the old token associated with the account, and for security reasons, neither the Gerrit web interface nor Command Center will ever show you this token again.
* The server URL is the prefix before the repositories that you would clone.
* The commit message hook URL is the url that you would make a curl request to in order to add the commit message hook that adds the change ID required by Gerrit.
* Usually the Gerrit web interface will give you one command to copy and paste in order to clone a repository. Here is an example of how to parse that command out into your server URL and your commit message hook URL:
** Given the command: <code>git clone "https://gerrit_username@gerrit.your-company.io/orgname/reponame" && (cd "reponame" && mkdir -p .git/hooks && curl -Lo `git rev-parse --git-dir`/hooks/commit-msg https://gerrit_username@gerrit.your-company.io/tools/hooks/commit-msg; chmod +x `git rev-parse --git-dir`/hooks/commit-msg)</code>
** The server URL would be: <code>gerrit.your-company.io/</code>
** The commit message hook URL would be: <code>https://gerrit_username@gerrit.your-company.io/tools/hooks/commit-msg</code>
* Once you are finished configuring the form, click '''Next''' in the top right corner of the page.

[[File:GerritStepThree.png|600px]]

'''Give the new credential a name and optionally grant access to managers'''
* The credential name is required, and it is how you will identify the credential for use later on.
* Granting access to manager users is optional.
** All administrator users on the system will have access to the credential.
** Only the manager users that you designate access to will be able to use the credential. They will not be able to modify the credential even if they have been granted access.
** No other users on the system will have the ability to access the credential at all.
* When you are satisfied with your credential name and manager access, click '''Create''' in the top right corner of the page.

File:GerritStepThree.png

2023-11-17T18:40:06Z

Prosenthal: A screenshot of the form where you assign your Gerrit Credential a name and allow certain managers to access it.

== Summary ==
A screenshot of the form where you assign your Gerrit Credential a name and allow certain managers to access it.

Gerrit Data Source Credential

2023-11-16T21:15:43Z

Prosenthal: Created page with "= Creating a Gerrit Data Source Credential = [Administrator] The Administrator can create the data source credentials by selecting the 30px ('''Create..."

File:GerritStepTwo.png

2023-11-16T21:12:45Z

Prosenthal: A screenshot of the form where you fill out the Gerrit username, access token, server URL, and commit message hook URL.

== Summary ==
A screenshot of the form where you fill out the Gerrit username, access token, server URL, and commit message hook URL.

File:GerritCard.png

2023-11-16T21:09:53Z

Prosenthal: A screenshot of the card to select when creating a Gerrit Data Source Credential

== Summary ==
A screenshot of the card to select when creating a Gerrit Data Source Credential

Jenkins Plugin Open Source Libraries

2022-03-03T00:05:01Z

Prosenthal:

== Localyzer Open Source Libraries ==
The Lingoport Jenkins plugin depends on all of the same open source libraries as Localyzer, see [[LRM Open Source Libraries]] for a complete list.

== Jenkins Plugin Parent POM ==
In addition to the open source libraries used by Localyzer, the Lingoport Jenkins Plugin is built upon version 3.2 of the [https://github.com/jenkinsci/plugin-pom Jenkins Plugin Parent POM]. The Jenkins Plugin Parent POM is released under MIT License.

== Additional Maven Plugins ==
The Lingoport Jenkins Plugin also depends on the following Maven Plugins to build:
=== Distributed under the [http://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 License] ===
* org.apache.maven.plugins:maven-antrun-plugin:1.8
* org.apache.maven.plugins:maven-clean-plugin:2.4.1
* org.apache.maven.plugins:maven-install-plugin:2.4
* org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1
* org.codehaus.mojo:extra-enforcer-rules:1.0-beta-4
* org.codehaus.mojo:animal-sniffer-maven-plugin:1.15
* org.jenkins-ci.tools:maven-hpi-plugin:3.2-SNAPSHOT

Jenkins Plugin Open Source Libraries

2022-03-03T00:03:24Z

Prosenthal: Created page with "== Localyzer Open Source Libraries == The Lingoport Jenkins plugin depends on all of the same open source libraries as Localyzer, see LRM Open Source Libraries for a compl..."

== Localyzer Open Source Libraries ==
The Lingoport Jenkins plugin depends on all of the same open source libraries as Localyzer, see [[LRM Open Source Libraries]] for a complete list.

== Jenkins Plugin Parent POM ==
In addition to the open source libraries used by Localyzer, the Lingoport Jenkins Plugin is built upon version 3.2 of the [https://github.com/jenkinsci/plugin-pom Jenkins Plugin Parent POM]. The Jenkins Plugin Parent POM is released under MIT License.

== Additional Maven Plugins ==
The Lingoport Jenkins Plugin also depends the following Maven Plugins to build:
=== Distributed under the [http://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 License] ===
* org.apache.maven.plugins:maven-antrun-plugin:1.8
* org.apache.maven.plugins:maven-clean-plugin:2.4.1
* org.apache.maven.plugins:maven-install-plugin:2.4
* org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1
* org.codehaus.mojo:extra-enforcer-rules:1.0-beta-4
* org.codehaus.mojo:animal-sniffer-maven-plugin:1.15
* org.jenkins-ci.tools:maven-hpi-plugin:3.2-SNAPSHOT

Google Translate

2021-12-29T19:45:02Z

Prosenthal: Fix typo in translation memory section

== Localyzer integration with the Google Cloud Platform Translation Service ==
=== How the process works ===
For information on Machine Translation and how the process works see [[Machine_Translation|Localyzer Integration with Machine Translation]].

== Supported Localyzer File Types ==
Not all file types are supported for machine translation. For a list of supported types see [[Machine_Translation#Supported_File_Types|Supported File Types]].

== Setting up your Localyzer group or project to use Google Translate ==
=== Configure a Google Translate subscription on Google Cloud Platform ===
==== Create a project ====
The first step in configuring an instance of Google Translate to be used with Localyzer is to log in to the [https://console.cloud.google.com/ Google Cloud Console] and select or create a Google Cloud project.
<ol>
<li>Log into [https://console.cloud.google.com/ console.cloud.google.com] with a Google Services email account. Use a secure account, as it will have “owner” permissions over the project.</li>
<li>Click on the project select drop-down in the top left of the page.</li>
[[File:GoogleCloudProjectDropdown.png|800px]]
<li>At this point if you already have a project set up which you would like to configure Google Translate on, you can skip to the next section, [[#Enable_billing|Enable billing]]. If not, or you otherwise would like to create a new project, click on ''New Project'' in the top right of the menu.</li>
<li>In the new project configuration screen, enter in a name for the project and select an organization to organize the project under. Pay special attention to the project ID, as this is important to the project, and cannot be changed later. Google Cloud Console will automatically generate a project ID for you, though if you would like to set one yourself just hit the ''Edit'' button.</li>
[[File:GoogleCloudNewProject.png|800px]]
</ol>

==== Enable billing ====
Once we have created a new project (or selected an existing one), we need to make sure that billing is enabled on the project before we can enable Google Translate.
<ol>
<li>Click on the navigation hamburger menu in the top left corner of the page, and then select ''Billing''.</li>
[[File:GoogleCloudBilling.png|320px]]
<li>If billing is already enabled on the project, you’ll see a billing overview page. If not, you will be prompted with a pop-up window containing instructions on how to enable billing for the project. Follow these instructions to enable billing on the project.</li>
</ol>

==== Enable the Cloud Translation API ====
Now that we have a project with billing enabled, we are ready to enable the Cloud Translation API.
<ol>
<li>Click on the navigation hamburger menu in the top left corner of the page, and then select ''APIs & Services'', and then select ''Library''.</li>
[[File:GoogleCloudAPIsLibrary.png|450px]]
<li>Use the search bar to search for "Cloud Translation API".</li>
<li>Select the Cloud Translation API, and click the ''Enable'' button.</li>
</ol>

==== Create a service account ====
Next, a service account must be created. This service account acts as the credentials for Localyzer to access your Google Cloud Translation service. To learn more about what service accounts are, and why they are used, see Google’s article on [https://cloud.google.com/iam/docs/understanding-service-accounts understanding service accounts].
<ol>
<li>Click on the navigation hamburger menu in the top left corner of the page, and then select ''IAM & Admin'', and then select ''Service Accounts''.</li>
[[File:GoogleCloudIAM.png|450px]]
<li>Click on ''Create Service Account'' near the top of the page.</li>
<li>Fill out the service account’s name, ID, and optional description. Do NOT hit done at this stage, instead click on the ''Save and Continue'' button.</li>
[[File:GoogleCloudServiceAccountStep1.png|500px]]
<li>Under the second step to creating a service account, ''Grant this service account access to project'', click on the ''Add role'' button, then click on the ''Select a role'' dropdown menu. Use the menu to search for the basic role "Owner", and add the role to the service account.</li>
[[File:GoogleCloudServiceAccountStep2.png|500px]]
<li>Now you can click ''Done'' to finish the creation of the service account.</li>
</ol>

==== Download the JSON credential file ====
Finally, after the service account is created, we can create or add a new key to the account. This key is in the form of a JSON file which is used by Localyzer to access the translation service.
<ol>
<li>From the main Service Accounts screen (the previous section in this tutorial), click on the 3 dot icon next to the service account that was just created, then click on ''Manage keys''.</li>
[[File:GoogleCloudManageKeys.png|800px]]
<li>Click on the ''Add Key'' dropdown menu, and then select the ''Create new key'' option.</li>
<li>Select Key Type JSON (it should already be selected by default), and click the ''Create'' button.</li>
<li>The JSON key file will be automatically downloaded to your machine at this point. All you need to do is upload the file to your Jenkins or Localyzer Express machine, and then configure the Google Translate Vendor in Jenkins settings or in Localyzer Express!</li>
</ol>

=== Add Google Translate Vendor ===
To set up the ability to machine translate your resource files using Google Translate you’ll need to have access to the Lingoport Jenkins Server. The vendor setup is located in the Jenkins System Configuration.

<pre>
Jenkins -> Manage Jenkins -> Configure System
</pre>

[[File:AddGoogleVendor.png|550px]]

The ''Add Google Translate Vendor'' button can be found under the ''LRM L10n Vendor Setup'' section of the Jenkins Configure System page. After clicking on ''Add Google Translate Vendor'', the ''Standard Info'' as well as the ''Google Translate Credentials'' field groups will be displayed.

[[File:GoogleGroupVendor.png|800px]]

=== Standard Info ===
This is the information that is standard to all vendor types.

For more information on setting up the standard vendor info see [[L10n_Vendors_and_Integration#Standard_Vendor_Info|Standard Vendor Info]].

=== Google Translate Credentials ===
All of the Google Translate credential information should be available through the department responsible for setting up your Google Cloud Platform service.

==== JSON Credential File Path ====
Services from a Google Cloud Platform Project, such as the Google Translate service, can be accessed securely using a [https://cloud.google.com/iam/docs/understanding-service-accounts/ Service Account Key]. These keys come in the form of a single credential file in JSON format.

The department responsible for setting up the Google Cloud Platform service can manage these service account keys from their [https://console.cloud.google.com/ Google Cloud Console]. See [[#Download_the_JSON_credential_file|Download the JSON credential file]] for more details.

Localyzer requires a service account with at least ''Cloud Translation API Admin'', ''Storage Admin'', and ''AutoML Admin'' roles (note: the ''Owner'' role is the easiest to select in this scenario as it has permission for every Google Cloud operation, including those provided by the other three roles).

In order for Localyzer to use Google Translate, the JSON credential file must be downloaded placed on the same system as the Lingoport Jenkins Server (typically in a location like /var/lib/jenkins/… because the jenkins user needs access to the file), and that location needs to be specified to Localyzer in this vendor setup process.

==== Location ====
Google Cloud Platform requires Localyzer to let it know the translation requests are coming from one of two locations: ''US Central'', or ''Global''.

Currently, Google requires the ''US Central'' location in order to use the advanced translation features such as [[#Glossary_Names|glossaries]] or [[#Train_a_custom_AutoML_model_for_translation|AutoML models]]. It is for this reason that the ''Global'' location should only ever be selected if those advanced features are not required at all, the Jenkins server is outside of the US, and you require lower latency calls to Google Translate than the ''US Central'' location can offer.

==== Glossary Names ====
Glossaries are an optional feature of the Google Cloud Platform Translation service that allows for phrases to have guaranteed translations, regardless of the phrase’s context or the translation algorithm’s decision. This is useful for preserving brand names, product names, and other translation memory.

Glossaries are identified by their names given to them upon creation. Google unfortunately does not provide any user interface for the department responsible for configuring the Google Cloud project to manage glossaries, though [https://cloud.google.com/translate/docs/advanced/glossary there are still ways to do it].

When configuring a Google Translate Vendor, multiple glossary names can be entered, separated by commas. Then when Localyzer uses Google Translate to translate your resources, the first glossary in the list that is compatible with the current source and target locales will be used.

Currently, Google only supports the glossary feature with the ''US Central'' [[#Location|location]].

==== Model ====
The model that is chosen determines the translation algorithm that is used. The Google Cloud Platform Translation service comes with two built in models that don’t require any configuration and work across all locales.

The first model, ''NMT'' or ''Neural Machine Translation'', is the default model for Google Translate. This is the preferred of the two built in models, it is newer and yields better results, though there might still be some rare edge cases where it still doesn’t work yet. In this scenario, the Google Cloud Platform Translation service will automatically fall back to the second built in model, ''PBMT'' or ''Phrase Based Machine Translation''. This model is the previous generation of Google Translate, and is generally less preferred, but it can still be selected to be used over the newer model if so desired.
The third option for a model is to enter the model ID of an [[#Train_an_AutoML_model_for_fully_customized_machine_translation|AutoML]] model. AutoML models are based on the built in ''NMT'' model, but they have been custom “trained” or “fine-tuned” to a large data-set of internal company documents. This can result in better domain specific translation than the built in ''NMT'' model if used properly.

==== Add QA Changes to Glossaries ====
Localyzer, when used in conjunction with Localyzer QA, has a Translation Memory feature, which can be enabled with this checkbox. See the [[#Automatically_update_glossaries_with_Translation_Memory|section on Translation Memory]] further down on this page for more information.

=== Test Connection ===
The ''Test Connection'' button is used to test the validity of the entered credentials. If the credentials are valid then the ''Network Access Test Succeeded!'' Message will be displayed, otherwise an error message will be displayed.

=== Saving vendor info and linking the vendor to your project ===
When the ''Save'' button is clicked, the vendor information will be stored in the Jenkins ''com.lingoport.plugins.jenkinsgyzrlrmplugin.global.GlobalSettings.xml'' config file.

If the ''Access Level'' is for ''Group'' then the ''/var/lib/jenkins/Lingoport_Data/L10nStreamlining/<group name>/config/config_l10n_vendor.properties'' file will be created containing the vendor information otherwise the ''config_l10n_vendor.properties'' will not be created until it is used by a project.

For more information on ''Access Level'' and linking this vendor to your project see [[L10n_Vendors_and_Integration#Standard_Vendor_Info|Standard Vendor Info]].

== Customize translations with glossaries and AutoML ==
=== Set up guaranteed translations with glossaries ===
Glossaries are source-target sets of phrases or sentences that the machine translator will always consistently translate the same, regardless of context around the phrase or sentence. They can be useful for:
<ul>
<li>Do not translate (DNT) terms</li>
<li>Product and/or brand names</li>
<li>Ambiguous words</li>
</ul>
Unfortunately at this time, Google doesn’t provide any basic web interface with their cloud platform to add, update, or manage glossaries. But your department responsible for setting up the Google Translate service still has two options for managing their glossaries. Option one is to follow the steps outlined in Google’s [Creating and using glossaries (advanced)](https://cloud.google.com/translate/docs/advanced/glossary) documentation. Option two is to set up the initial glossary files, and then contact Lingoport support to take care of the rest.

==== Preparing glossary files ====
Glossaries can be created out of files of either Translation Memory eXchange (TMX), Comma Separated Values (CSV), or Tab Separated Values (TSV) format. TMX is the most universal format for translation management systems, but CSV files can be easy to read and create as spreadsheets, so they each have their own advantages and disadvantages as file types.

===== Unidirectional glossaries =====
Typically, glossaries are associated with just two locales, their source locale (the locale which translations are occurring from), and their target locale (the locale which translations are occurring to). These most basic forms of glossaries are known as unidirectional glossaries.

For a CSV or a TSV file, there should be just two values per line/row: the first being the desired phrase in the source language, and the second being the desired phrase in the target language. What the locales actually are, shouldn’t be specified in the CSV or TSV file itself, as they are actually specified upon association of the file with the glossary itself.

For a TMX file, it shouldn’t have to be written itself, but rather exported from a different/previous service. Make sure that the TMX file follows the standards of TMX Version 1.4. [https://cloud.google.com/translate/docs/advanced/glossary#translation_memory_exchange_tmx this section in Google’s documentation on glossaries] contains an example TMX file if needed.

===== Equivalent terms set glossaries =====
If a glossary is needed in more than one source-target language set, either multiple versions of the unidirectional glossary can be created, or one single equivalent terms set glossary can accomplish the task as well. There are limits to the equivalent terms set glossaries however, such as they only support CSV files, so exporting or transferring files from another translation service might be a more complicated process than using unidirectional glossaries. But there are also advantages such as compacting many separate glossaries into one single glossary. A CSV file for an equivalent terms set glossary looks very similar to a file for a unidirectional glossary, except that it can contain as many entries/columns as the desired number of locales in the glossary, and the first row of the file is a headers row that specifies the the locales of the phrases in the columns below them with their corresponding ISO-639-1 or BCP-47 language code.

=== Automatically update glossaries with Translation Memory ===
When using multiple products within the Localyzer family together, a Translation Memory feature emerges. It allows for the changes that are made to a translation in [[#LocalyzerQA|LocalyzerQA]] to be automatically added to the most relevant glossary. That way not only the specific translation(s) targeted by the post edit will be changed, but also all future occurrences of the phrase(s) as well. This is accomplished by automatically adding the phrases and corrections from LocalyzerQA to the first glossary in the list that has the proper source and target locales.

==== Enabling Translation Memory ====
Turning on Translation Memory can be done from either Jenkins or from Localyzer Express, depending on which products from the Localyzer family you are using. From Jenkins, this is done in the Localyzer L10n Vendor Setup `Jenkins -> Manage Jenkins -> Configure System`. On Localyzer Express, this can be done from the custom machine translator configuration menu.

Select the option “Add QA Changes to Glossaries” and Translation Memory will be enabled on all eligible glossaries.

==== Dealing with duplicate phrases in Translation Memory ====
If you have had Translation Memory enabled for a while and have added a lot of phrases to it, you might start to come across emails with a message that reads something like this:
<pre>
com.lingoport.translationmemory.google.pipeline.stage.UpdateGoogleTranslationMemoryStage: The file `some-glossary-name-sources.tmx` already contains translation memory for the source phrase(s) `[Some phrase in the source locale.]`. These phrases were not updated in the Translation Memory and instead were left the same. All other phrases were added to Translation Memory. To update the Translation Memory for a phrase that has already been added to this vendors Translation Memory, the original phrase must be manually removed from the Translation Memory. Please see https://wiki.lingoport.com/Google_Translate#Dealing_with_duplicate_phrases_in_Translation_Memory for more details.
</pre>
This message is nothing to worry about at all, it is simply just letting you know that the phrase already exists in the glossary which Translation Memory is trying to update. To avoid duplicating phrases in the glossary, Localyzer chose not to add the new source and target phrase pair, and instead leave the old pair intact. If the previous source and target phrases are desired to be kept, then nothing needs to be done, as Localyzer already took appropriate action. However, if you desire to remove the previous source and target phrases so that they can be replaced with new corrections, then this must be done manually.
<ol>
<li>Log in to the [https://console.cloud.google.com/ Google Cloud Console], and make sure the desired project is selected (top left of the screen).</li>
<li>Click on the navigation hamburger menu in the top left corner of the page, and then select ''Storage'' (you might scroll the menu), and then select ''Browser''.</li>
[[File:GoogleCloudStorageMenu.png|420px]]
<li>Select the bucket named “{project id}-glossaries”.</li>
<li>Find the appropriate TSV, CSV, or TMX file associated with the glossary, and click on the download icon on the right side of the table. If you created the glossary by contacting Lingoport support, or by otherwise using Lingoport utilities, then the correct file will be named “{glossary name}-sources.{extension}”. If you created the glossary with your own methods, then the file will be named whatever you named it at the time.</li>
[[File:GoogleCloudStorageDownload.png|800px]]
<li>Open the file and edit it in your favorite text editor. It is up to you if you want to delete the entry altogether, or simply manually modify the contents of the entry.</li>
<li>Repeat whatever process you originally went through to [[#Set_up_guaranteed_translations_with_glossaries|create the glossary]] in the first place, using the new file this time.</li>
</ol>

=== Train an AutoML model for fully customized machine translation ===
Creating and managing AutoML models can be done by the department responsible for setting up the Google Translate service with ease thanks to the [https://console.cloud.google.com/translation/ AutoML Web Interface] that Google provides. This section will give a brief overview of how to add and manage AutoML models, though it should be noted that [https://cloud.google.com/translate/automl/docs/before-you-begin Google has a much more in depth documentation] on the subject if further inquiry is desired.

==== Preparing training data ====
AutoML models can use Translation Memory eXchange (TMX) formatted data for training purposes, which is a universal format that most translation management systems should be able to export in. At least 1000 sentence pairs are required for training an AutoML model, though at least 5000 is recommended, and 15 million sentence pairs is the maximum. Google recommends keeping sentences to less than 200 words each for the best results.

==== Creating a dataset ====
To create a dataset from the training data that you have prepared:

<ol>
<li>Visit the [https://console.cloud.google.com/translation/ AutoML Web Interface], and select the project to train the model for.</li>
<li>Under the [https://console.cloud.google.com/translation/datasets/ ''Datasets'' page], click the ''Create Dataset'' button.</li>
<li>In the ''Create Dataset'' dialog, enter a name for the dataset and select the source and target locales for the dataset.</li>
<li>Clicking ''Create'' will bring you to the ''Import'' dialog, where you can upload the training data that you prepared in the previous section, and finish creating the dataset.</li>
</ol>

==== Training a model ====
To train a model from the dataset that you have uploaded to Google Cloud:

<ol>
<li>Visit the [https://console.cloud.google.com/translation/ AutoML Web Interface], and select the project to train the model for.</li>
<li>Under the [https://console.cloud.google.com/translation/datasets/ ''Datasets'' page], click on the dataset to use in the model’s training process.</li>
<li>Use the ''Sentences'' tab at the top to review the dataset if desired, and the ''Train'' tab to start training the model.</li>
<li>Click ''Start Training'' and enter a name for the model to start the training process.</li>
<li>Under the [https://console.cloud.google.com/translation/models/ ''Models'' page], you will find a list of model names and IDs (to be entered in the Jenkins configuration section), as well as their status.</li>
</ol>

Google Translate

2021-12-29T19:23:41Z

Prosenthal: Add translation memory information and Google Cloud Platform information to the Google Translate page

== Localyzer integration with the Google Cloud Platform Translation Service ==
=== How the process works ===
For information on Machine Translation and how the process works see [[Machine_Translation|Localyzer Integration with Machine Translation]].

== Supported Localyzer File Types ==
Not all file types are supported for machine translation. For a list of supported types see [[Machine_Translation#Supported_File_Types|Supported File Types]].

== Setting up your Localyzer group or project to use Google Translate ==
=== Configure a Google Translate subscription on Google Cloud Platform ===
==== Create a project ====
The first step in configuring an instance of Google Translate to be used with Localyzer is to log in to the [https://console.cloud.google.com/ Google Cloud Console] and select or create a Google Cloud project.
<ol>
<li>Log into [https://console.cloud.google.com/ console.cloud.google.com] with a Google Services email account. Use a secure account, as it will have “owner” permissions over the project.</li>
<li>Click on the project select drop-down in the top left of the page.</li>
[[File:GoogleCloudProjectDropdown.png|800px]]
<li>At this point if you already have a project set up which you would like to configure Google Translate on, you can skip to the next section, [[#Enable_billing|Enable billing]]. If not, or you otherwise would like to create a new project, click on ''New Project'' in the top right of the menu.</li>
<li>In the new project configuration screen, enter in a name for the project and select an organization to organize the project under. Pay special attention to the project ID, as this is important to the project, and cannot be changed later. Google Cloud Console will automatically generate a project ID for you, though if you would like to set one yourself just hit the ''Edit'' button.</li>
[[File:GoogleCloudNewProject.png|800px]]
</ol>

==== Enable billing ====
Once we have created a new project (or selected an existing one), we need to make sure that billing is enabled on the project before we can enable Google Translate.
<ol>
<li>Click on the navigation hamburger menu in the top left corner of the page, and then select ''Billing''.</li>
[[File:GoogleCloudBilling.png|320px]]
<li>If billing is already enabled on the project, you’ll see a billing overview page. If not, you will be prompted with a pop-up window containing instructions on how to enable billing for the project. Follow these instructions to enable billing on the project.</li>
</ol>

==== Enable the Cloud Translation API ====
Now that we have a project with billing enabled, we are ready to enable the Cloud Translation API.
<ol>
<li>Click on the navigation hamburger menu in the top left corner of the page, and then select ''APIs & Services'', and then select ''Library''.</li>
[[File:GoogleCloudAPIsLibrary.png|450px]]
<li>Use the search bar to search for "Cloud Translation API".</li>
<li>Select the Cloud Translation API, and click the ''Enable'' button.</li>
</ol>

==== Create a service account ====
Next, a service account must be created. This service account acts as the credentials for Localyzer to access your Google Cloud Translation service. To learn more about what service accounts are, and why they are used, see Google’s article on [https://cloud.google.com/iam/docs/understanding-service-accounts understanding service accounts].
<ol>
<li>Click on the navigation hamburger menu in the top left corner of the page, and then select ''IAM & Admin'', and then select ''Service Accounts''.</li>
[[File:GoogleCloudIAM.png|450px]]
<li>Click on ''Create Service Account'' near the top of the page.</li>
<li>Fill out the service account’s name, ID, and optional description. Do NOT hit done at this stage, instead click on the ''Save and Continue'' button.</li>
[[File:GoogleCloudServiceAccountStep1.png|500px]]
<li>Under the second step to creating a service account, ''Grant this service account access to project'', click on the ''Add role'' button, then click on the ''Select a role'' dropdown menu. Use the menu to search for the basic role "Owner", and add the role to the service account.</li>
[[File:GoogleCloudServiceAccountStep2.png|500px]]
<li>Now you can click ''Done'' to finish the creation of the service account.</li>
</ol>

==== Download the JSON credential file ====
Finally, after the service account is created, we can create or add a new key to the account. This key is in the form of a JSON file which is used by Localyzer to access the translation service.
<ol>
<li>From the main Service Accounts screen (the previous section in this tutorial), click on the 3 dot icon next to the service account that was just created, then click on ''Manage keys''.</li>
[[File:GoogleCloudManageKeys.png|800px]]
<li>Click on the ''Add Key'' dropdown menu, and then select the ''Create new key'' option.</li>
<li>Select Key Type JSON (it should already be selected by default), and click the ''Create'' button.</li>
<li>The JSON key file will be automatically downloaded to your machine at this point. All you need to do is upload the file to your Jenkins or Localyzer Express machine, and then configure the Google Translate Vendor in Jenkins settings or in Localyzer Express!</li>
</ol>

=== Add Google Translate Vendor ===
To set up the ability to machine translate your resource files using Google Translate you’ll need to have access to the Lingoport Jenkins Server. The vendor setup is located in the Jenkins System Configuration.

<pre>
Jenkins -> Manage Jenkins -> Configure System
</pre>

[[File:AddGoogleVendor.png|550px]]

The ''Add Google Translate Vendor'' button can be found under the ''LRM L10n Vendor Setup'' section of the Jenkins Configure System page. After clicking on ''Add Google Translate Vendor'', the ''Standard Info'' as well as the ''Google Translate Credentials'' field groups will be displayed.

[[File:GoogleGroupVendor.png|800px]]

=== Standard Info ===
This is the information that is standard to all vendor types.

For more information on setting up the standard vendor info see [[L10n_Vendors_and_Integration#Standard_Vendor_Info|Standard Vendor Info]].

=== Google Translate Credentials ===
All of the Google Translate credential information should be available through the department responsible for setting up your Google Cloud Platform service.

==== JSON Credential File Path ====
Services from a Google Cloud Platform Project, such as the Google Translate service, can be accessed securely using a [https://cloud.google.com/iam/docs/understanding-service-accounts/ Service Account Key]. These keys come in the form of a single credential file in JSON format.

The department responsible for setting up the Google Cloud Platform service can manage these service account keys from their [https://console.cloud.google.com/ Google Cloud Console]. See [[#Download_the_JSON_credential_file|Download the JSON credential file]] for more details.

Localyzer requires a service account with at least ''Cloud Translation API Admin'', ''Storage Admin'', and ''AutoML Admin'' roles (note: the ''Owner'' role is the easiest to select in this scenario as it has permission for every Google Cloud operation, including those provided by the other three roles).

In order for Localyzer to use Google Translate, the JSON credential file must be downloaded placed on the same system as the Lingoport Jenkins Server (typically in a location like /var/lib/jenkins/… because the jenkins user needs access to the file), and that location needs to be specified to Localyzer in this vendor setup process.

==== Location ====
Google Cloud Platform requires Localyzer to let it know the translation requests are coming from one of two locations: ''US Central'', or ''Global''.

Currently, Google requires the ''US Central'' location in order to use the advanced translation features such as [[#Glossary_Names|glossaries]] or [[#Train_a_custom_AutoML_model_for_translation|AutoML models]]. It is for this reason that the ''Global'' location should only ever be selected if those advanced features are not required at all, the Jenkins server is outside of the US, and you require lower latency calls to Google Translate than the ''US Central'' location can offer.

==== Glossary Names ====
Glossaries are an optional feature of the Google Cloud Platform Translation service that allows for phrases to have guaranteed translations, regardless of the phrase’s context or the translation algorithm’s decision. This is useful for preserving brand names, product names, and other translation memory.

Glossaries are identified by their names given to them upon creation. Google unfortunately does not provide any user interface for the department responsible for configuring the Google Cloud project to manage glossaries, though [https://cloud.google.com/translate/docs/advanced/glossary there are still ways to do it].

When configuring a Google Translate Vendor, multiple glossary names can be entered, separated by commas. Then when Localyzer uses Google Translate to translate your resources, the first glossary in the list that is compatible with the current source and target locales will be used.

Currently, Google only supports the glossary feature with the ''US Central'' [[#Location|location]].

==== Model ====
The model that is chosen determines the translation algorithm that is used. The Google Cloud Platform Translation service comes with two built in models that don’t require any configuration and work across all locales.

The first model, ''NMT'' or ''Neural Machine Translation'', is the default model for Google Translate. This is the preferred of the two built in models, it is newer and yields better results, though there might still be some rare edge cases where it still doesn’t work yet. In this scenario, the Google Cloud Platform Translation service will automatically fall back to the second built in model, ''PBMT'' or ''Phrase Based Machine Translation''. This model is the previous generation of Google Translate, and is generally less preferred, but it can still be selected to be used over the newer model if so desired.
The third option for a model is to enter the model ID of an [[#Train_an_AutoML_model_for_fully_customized_machine_translation|AutoML]] model. AutoML models are based on the built in ''NMT'' model, but they have been custom “trained” or “fine-tuned” to a large data-set of internal company documents. This can result in better domain specific translation than the built in ''NMT'' model if used properly.

==== Add QA Changes to Glossaries ====
Localyzer, when used in conjunction with Localyzer QA, has a Translation Memory feature, which can be enabled with this checkbox. See the [[#Automatically_update_glossaries_with_Translation_Memory|section on Translation Memory]] further down on this page for more information.

=== Test Connection ===
The ''Test Connection'' button is used to test the validity of the entered credentials. If the credentials are valid then the ''Network Access Test Succeeded!'' Message will be displayed, otherwise an error message will be displayed.

=== Saving vendor info and linking the vendor to your project ===
When the ''Save'' button is clicked, the vendor information will be stored in the Jenkins ''com.lingoport.plugins.jenkinsgyzrlrmplugin.global.GlobalSettings.xml'' config file.

If the ''Access Level'' is for ''Group'' then the ''/var/lib/jenkins/Lingoport_Data/L10nStreamlining/<group name>/config/config_l10n_vendor.properties'' file will be created containing the vendor information otherwise the ''config_l10n_vendor.properties'' will not be created until it is used by a project.

For more information on ''Access Level'' and linking this vendor to your project see [[L10n_Vendors_and_Integration#Standard_Vendor_Info|Standard Vendor Info]].

== Customize translations with glossaries and AutoML ==
=== Set up guaranteed translations with glossaries ===
Glossaries are source-target sets of phrases or sentences that the machine translator will always consistently translate the same, regardless of context around the phrase or sentence. They can be useful for:
<ul>
<li>Do not translate (DNT) terms</li>
<li>Product and/or brand names</li>
<li>Ambiguous words</li>
</ul>
Unfortunately at this time, Google doesn’t provide any basic web interface with their cloud platform to add, update, or manage glossaries. But your department responsible for setting up the Google Translate service still has two options for managing their glossaries. Option one is to follow the steps outlined in Google’s [Creating and using glossaries (advanced)](https://cloud.google.com/translate/docs/advanced/glossary) documentation. Option two is to set up the initial glossary files, and then contact Lingoport support to take care of the rest.

==== Preparing glossary files ====
Glossaries can be created out of files of either Translation Memory eXchange (TMX), Comma Separated Values (CSV), or Tab Separated Values (TSV) format. TMX is the most universal format for translation management systems, but CSV files can be easy to read and create as spreadsheets, so they each have their own advantages and disadvantages as file types.

===== Unidirectional glossaries =====
Typically, glossaries are associated with just two locales, their source locale (the locale which translations are occurring from), and their target locale (the locale which translations are occurring to). These most basic forms of glossaries are known as unidirectional glossaries.

For a CSV or a TSV file, there should be just two values per line/row: the first being the desired phrase in the source language, and the second being the desired phrase in the target language. What the locales actually are, shouldn’t be specified in the CSV or TSV file itself, as they are actually specified upon association of the file with the glossary itself.

For a TMX file, it shouldn’t have to be written itself, but rather exported from a different/previous service. Make sure that the TMX file follows the standards of TMX Version 1.4. [https://cloud.google.com/translate/docs/advanced/glossary#translation_memory_exchange_tmx this section in Google’s documentation on glossaries] contains an example TMX file if needed.

===== Equivalent terms set glossaries =====
If a glossary is needed in more than one source-target language set, either multiple versions of the unidirectional glossary can be created, or one single equivalent terms set glossary can accomplish the task as well. There are limits to the equivalent terms set glossaries however, such as they only support CSV files, so exporting or transferring files from another translation service might be a more complicated process than using unidirectional glossaries. But there are also advantages such as compacting many separate glossaries into one single glossary. A CSV file for an equivalent terms set glossary looks very similar to a file for a unidirectional glossary, except that it can contain as many entries/columns as the desired number of locales in the glossary, and the first row of the file is a headers row that specifies the the locales of the phrases in the columns below them with their corresponding ISO-639-1 or BCP-47 language code.

=== Automatically update glossaries with Translation Memory ===
When using multiple products within the Localyzer family together, a Translation Memory feature emerges. It allows for the changes that are made to a translation in [[#LocalyzerQA|LocalyzerQA]] to be automatically added to the most relevant glossary. That way not only the specific translation(s) targeted by the post edit will be changed, but also all future occurrences of the phrase(s) as well. This is accomplished by automatically adding the phrases and corrections from LocalyzerQA to the first glossary in the list that has the proper source and target locales.

==== Enabling Translation Memory ====
Turning on Translation Memory can be done from either Jenkins or from Localyzer Express, depending on which products from the Localyzer family you are using. From Jenkins, this is done in the Localyzer L10n Vendor Setup `Jenkins -> Manage Jenkins -> Configure System`. On Localyzer Express, this can be done from the custom machine translator configuration menu.

Select the option “Add QA Changes to Glossaries” and Translation Memory will be enabled on all eligible glossaries.

==== Dealing with duplicate phrases in Translation Memory ====
If you have had Translation Memory enabled for a while and have added a lot of phrases to it, you might start to come across emails with a message that reads something like this:
<pre>
com.lingoport.translationmemory.google.pipeline.stage.UpdateGoogleTranslationMemoryStage: The file `some-glossary-name-sources.tmx` already contains translation memory for the source phrase(s) `[Some phrase in the source locale.]`. These phrases were not updated in the Translation Memory and instead were left the same. All other phrases were added to Translation Memory. To update the Translation Memory for a phrase that has already been added to this vendors Translation Memory, the original phrase must be manually removed from the Translation Memory. Please see https://wiki.lingoport.com/Google_Translate#Dealing_with_duplicate_phrases_in_Translation_Memory for more details.
</pre>
This message is nothing to worry about at all, it is simply just letting you know that the phrase already exists in the glossary which Translation Memory is trying to update. To avoid duplicating phrases in the glossary, Localyzer chose not to add the new source and target phrase pair, and instead leave the old pair intact. If the previous source and target phrases are desired to be kept, then nothing needs to be done, as Localyzer already took appropriate action. However, if you desire to remove the previous source and target phrases so that they can be replaced with new corrections, then this must be done manually.
<ol>
<li>Log in to the [https://console.cloud.google.com/ Google Cloud Console], and make sure the desired project is selected (top left of the screen).</li>
<li>Click on the navigation hamburger menu in the top left corner of the page, and then select ''Storage'' (you might scroll the menu), and then select ''Browser''.</li>
[[File:GoogleCloudStorageMenu.png|420px]]
<li>Select the bucket named “{project id}-glossaries”.</li>
<li>Find the appropriate TSV, CSV, or TMX file associated with the glossary, and click on the download icon on the right side of the table. If you created the glossary by contacting Lingoport support, or by otherwise using Lingoport utilities, then the correct file will be named “{glossary name}-sources.{extension}”. If you created the glossary with your own methods, then the file will be named whatever you named it at the time.</li>
[[File::GoogleCloudStorageDownload.png|800px]]
<li>Open the file and edit it in your favorite text editor. It is up to you if you want to delete the entry altogether, or simply manually modify the contents of the entry.</li>
<li>Repeat whatever process you originally went through to [[#Set_up_guaranteed_translations_with_glossaries|create the glossary]] in the first place, using the new file this time.</li>
</ol>

=== Train an AutoML model for fully customized machine translation ===
Creating and managing AutoML models can be done by the department responsible for setting up the Google Translate service with ease thanks to the [https://console.cloud.google.com/translation/ AutoML Web Interface] that Google provides. This section will give a brief overview of how to add and manage AutoML models, though it should be noted that [https://cloud.google.com/translate/automl/docs/before-you-begin Google has a much more in depth documentation] on the subject if further inquiry is desired.

==== Preparing training data ====
AutoML models can use Translation Memory eXchange (TMX) formatted data for training purposes, which is a universal format that most translation management systems should be able to export in. At least 1000 sentence pairs are required for training an AutoML model, though at least 5000 is recommended, and 15 million sentence pairs is the maximum. Google recommends keeping sentences to less than 200 words each for the best results.

==== Creating a dataset ====
To create a dataset from the training data that you have prepared:

<ol>
<li>Visit the [https://console.cloud.google.com/translation/ AutoML Web Interface], and select the project to train the model for.</li>
<li>Under the [https://console.cloud.google.com/translation/datasets/ ''Datasets'' page], click the ''Create Dataset'' button.</li>
<li>In the ''Create Dataset'' dialog, enter a name for the dataset and select the source and target locales for the dataset.</li>
<li>Clicking ''Create'' will bring you to the ''Import'' dialog, where you can upload the training data that you prepared in the previous section, and finish creating the dataset.</li>
</ol>

==== Training a model ====
To train a model from the dataset that you have uploaded to Google Cloud:

<ol>
<li>Visit the [https://console.cloud.google.com/translation/ AutoML Web Interface], and select the project to train the model for.</li>
<li>Under the [https://console.cloud.google.com/translation/datasets/ ''Datasets'' page], click on the dataset to use in the model’s training process.</li>
<li>Use the ''Sentences'' tab at the top to review the dataset if desired, and the ''Train'' tab to start training the model.</li>
<li>Click ''Start Training'' and enter a name for the model to start the training process.</li>
<li>Under the [https://console.cloud.google.com/translation/models/ ''Models'' page], you will find a list of model names and IDs (to be entered in the Jenkins configuration section), as well as their status.</li>
</ol>

File:GoogleCloudStorageDownload.png

2021-12-29T19:14:35Z

Prosenthal: A screenshot showing how to download an object from Google Cloud Storage.

== Summary ==
A screenshot showing how to download an object from Google Cloud Storage.

File:GoogleCloudStorageMenu.png

2021-12-29T19:13:25Z

Prosenthal: A screenshot showing how to access the storage browser on the Google Cloud Platform.

== Summary ==
A screenshot showing how to access the storage browser on the Google Cloud Platform.

File:GoogleCloudManageKeys.png

2021-12-29T19:11:22Z

Prosenthal: A screenshot showing how to get to the "Manage Keys" interface on the Google Cloud Platform.

== Summary ==
A screenshot showing how to get to the "Manage Keys" interface on the Google Cloud Platform.

File:GoogleCloudServiceAccountStep2.png

2021-12-29T19:08:05Z

Prosenthal: A screenshot of the process to create a service account on the Google Cloud Platform.

== Summary ==
A screenshot of the process to create a service account on the Google Cloud Platform.

File:GoogleCloudServiceAccountStep1.png

2021-12-29T19:07:05Z

Prosenthal: A screenshot of the process to create a service account on the Google Cloud Platform.

== Summary ==
A screenshot of the process to create a service account on the Google Cloud Platform.

File:GoogleCloudIAM.png

2021-12-29T19:03:29Z

Prosenthal:

File:GoogleCloudAPIsLibrary.png

2021-12-29T19:01:14Z

Prosenthal: A screenshot of the navigation menu in the Google Cloud Platform with the APIs & Services Library options highlighted.

== Summary ==
A screenshot of the navigation menu in the Google Cloud Platform with the APIs & Services Library options highlighted.

File:GoogleCloudBilling.png

2021-12-29T18:59:29Z

Prosenthal: A screenshot of the Google Cloud navigation menu with the link to "billing" highlighted.

== Summary ==
A screenshot of the Google Cloud navigation menu with the link to "billing" highlighted.

File:GoogleCloudNewProject.png

2021-12-29T18:54:45Z

Prosenthal: Screenshot of the interface used to create a new project on the Google Cloud Platform.

== Summary ==
Screenshot of the interface used to create a new project on the Google Cloud Platform.

File:GoogleCloudProjectDropdown.png

2021-12-29T18:53:03Z

Prosenthal: Screenshot of the dropdown menu to select the Google Cloud project.

== Summary ==
Screenshot of the dropdown menu to select the Google Cloud project.

Lingoport Error Codes

2021-07-15T18:08:36Z

Prosenthal: Add lingoport-tm-cli to error codes for Lingoport jar files

=Error codes for Lingoport jar files=
{| border="1" class="wikitable" style="width=50%"
!jar file
!lrm-cli
!lpcommon
!lrm-process
!lingoport-lingotek-cli
!lingoport-ftp-cli
!lingoport-ws-cli
!lrm-common
!lingoport-local-cli
!lingoport-mt-cli
!lingoport-tm-cli
|-
!Code Range
|100-1999
|2000-9999
|10000-14999
|15000-15999
|16000-16999
|17000-17999
|18000-18999
|19500-19999
|20000-20999
|30000-30999
|-

Microsoft Translator

2021-05-19T21:08:26Z

Prosenthal: add documentation on the custom translator portal

== Localyzer integration with the Microsoft Azure Cognitive Services Translator ==
=== How the process works ===
For information on Machine Translation and how the process works see [[Machine_Translation|Localyzer Integration with Machine Translation]].

== Supported Localyzer File Types ==
Not all file types are supported for machine translation. For a list of supported types see [[Machine_Translation#Supported_File_Types|Supported File Types]].

== Setting up your Localyzer group or project to use Microsoft Translator ==
To set up the ability to machine translate your resource files using Microsoft Translator you will need to have access to the Lingoport Jenkins Server. The vendor setup is located in the Jenkins System Configuration.

<pre>
Jenkins -> Manage Jenkins -> Configure System
</pre>

=== Add Microsoft Translator Vendor ===

[[File:AddMicrosoftVendor.png]]

The ''Add Microsoft Vendor'' button can be found under the ''LRM L10n Vendor Setup'' section of the Jenkins Configure System page. After clicking on ''Add Microsoft Translator Vendor'', the ''Standard Info'' as well as the ''Microsoft Translator Credentials'' field groups will be displayed.

[[File:MicrosoftGroupVendor.png]]

=== Standard Info ===
This is the information that is standard to all vendor types.

For more information on setting up the standard vendor info see [[L10n_Vendors_and_Integration#Standard_Vendor_Info|Standard Vendor Info]].

=== Microsoft Translator Credentials ===
All of the Microsoft Translator credential information should be available through the department responsible for setting up your Microsoft Azure Cognitive Services Translator.

==== Subscription Key ====
The subscription key, also sometimes referred to as the API key or the credential key, is a key-code, not meant to be shared publicly, that grants access to the Microsoft Translator resource.

==== Category ID ====
The category ID is an identifier that allows you to use the [[#Use_the_Custom_Translator_portal_for_dictionaries_and_trained_models|Custom Translator]] feature of Microsoft Translator for custom models or dictionaries. A category ID is not required, and the entry can be left blank in order to use Microsoft’s built in translator.

=== Test Connection ===
The ''Test Connection'' button is used to test the validity of the entered credentials. If the credentials are valid then the ''Network Access Test Succeeded!'' Message will be displayed, otherwise an error message will be displayed.

=== Saving vendor info and linking the vendor to your project ===
When the ''Save'' button is clicked, the vendor information will be stored in the Jenkins ''com.lingoport.plugins.jenkinsgyzrlrmplugin.global.GlobalSettings.xml'' config file.

If the ''Access Level'' is for ''Group'' then the ''/var/lib/jenkins/Lingoport_Data/L10nStreamlining/<group name>/config/config_l10n_vendor.properties'' file will be created containing the vendor information otherwise the ''config_l10n_vendor.properties'' will not be created until it is used by a project.

For more information on ''Access Level'' and linking this vendor to your project see [[L10n_Vendors_and_Integration#Standard_Vendor_Info|Standard Vendor Info]].

== Use the Custom Translator portal for dictionaries and trained models ==
The [https://portal.customtranslator.azure.ai Custom Translator portal] provides a web user interface for the department responsible for setting up the Microsoft Translator service to manage and customize the output of the machine translation. [[#Train_your_own_model|Custom trained fine-tuned models]] provide context sensitive customizations by fine-tuning one of Microsoft Translator’s base models to your company’s own pre existing translations, but require large amounts of data to train. [[#Train_a_custom_translator_with_a_dictionary|Dictionaries]] on the other hand can work with any size dataset, large or small, and work without context by forcing sentences or phrases to always have a desired translation.

To use either of these features a workspace must be created from the Custom Translator portal, see [https://docs.microsoft.com/en-us/azure/cognitive-services/translator/custom-translator/quickstart-build-deploy-custom-model Microsoft’s Custom Translator quickstart] for more details on workspaces. From this workspace, any number of projects can be created. Each project get’s a [[#Category_ID|Category ID]] associated with it which is used when configuring the vendor. One project can only have a single Custom Translator deployed on it at a time, so create multiple projects if you plan on having multiple Custom Translators deployed at the same time. Files for dictionaries or custom trained models can then be uploaded to a project for training.

=== Train your own model ===
Training your own model, or rather fine-tuning one of Microsoft Translator’s built-in models to your company’s own pre existing translations can provide domain specific machine translation results that are also context sensitive and more natural sounding. This comes at the cost of requiring a large dataset to train the model on, Microsoft Translator requires at least 10,000 pairs of sentences to train a model. See [https://docs.microsoft.com/en-us/azure/cognitive-services/translator/custom-translator/document-formats-naming-convention this list] from Microsoft’s documentation for a full rundown on supported file formats. We recommend using TMX files when possible as they are universal across many translation vendors.

Upload the document(s) for training to the [https://portal.customtranslator.azure.ai/ Custom Translator portal] by clicking on the Documents tab and then the Upload files button. Fill in the relevant information in the upload dialog that pops up (if using TMX you can skip over the Parallel Data section), and then click on the Upload button.

Once all the documents are uploaded, the model can be trained. Click on the Projects tab and select the project you want to train the model for. Use the checkboxes next to the documents that you have uploaded to select which ones will be used in the training of the model. Then click the Create model button to start the training process. Once the training has finished, the model can be deployed on that project.

=== Train a Custom Translator with a dictionary ===
Using dictionaries is a great way to customize the machine translator to be more domain specific because they work for datasets of all different sizes, large or small. Dictionaries are files of sentence (or phrase) pairs, just like the files to train a model on, but they are specially noted as dictionaries upon upload. When a Custom Translator is trained using a dictionary file, the sentence or phrase pairs in that dictionary will be consistent guaranteed translations regardless of context.

Custom translators can contain both custom models and dictionaries at once by selecting all of the training files as well as the dictionary files before training the Custom Translator. It is also possible to train a Custom Translator with just dictionary files, leaving out the custom model altogether. This results in a much faster (and therefore cheaper) training time for the Custom Translator, as well as allows for domain specific translation without the barrier of entry of a sentence pair minimum dataset. When a Custom Translator is trained with just dictionaries, it will use the Microsoft Translator base model for all translations that are not present in the dictionaries.

Microsoft Translator

2021-05-14T17:43:26Z

Prosenthal:

Microsoft Translator

2021-05-14T17:41:55Z

Prosenthal: Created page with "== Localyzer integration with the Microsoft Azure Cognitive Services Translator == === How the process works === For information on Machine Translation and how the process wor..."

File:MicrosoftGroupVendor.png

2021-05-14T17:41:08Z

Prosenthal: Prosenthal uploaded a new version of File:MicrosoftGroupVendor.png

== Summary ==
Screenshot showing the user interface for creating and configuring a Microsoft Translator vendor.

File:MicrosoftGroupVendor.png

2021-05-14T17:26:26Z

Prosenthal: Screenshot showing the user interface for creating and configuring a Microsoft Translator vendor.

== Summary ==
Screenshot showing the user interface for creating and configuring a Microsoft Translator vendor.

File:AddMicrosoftVendor.png

2021-05-14T17:25:36Z

Prosenthal: Screenshot showing the location of the Add Microsoft Vendor Button in the Localyzer Jenkins server configuration.

== Summary ==
Screenshot showing the location of the Add Microsoft Vendor Button in the Localyzer Jenkins server configuration.

Google Translate

2021-05-14T17:03:23Z

Prosenthal: Attempt to fix some links in Google Vendor page

Google Translate

2021-05-14T16:55:45Z

Prosenthal: Created page with " == Localyzer integration with the Google Cloud Platform Translation Service == === How the process works === For information on Machine Translation and how the process works..."

File:GoogleVendorServiceKeys.png

2021-05-14T16:31:10Z

Prosenthal: Screenshot showing the user interface for managing Service Account Keys for the Google Cloud Translate platform.

== Summary ==
Screenshot showing the user interface for managing Service Account Keys for the Google Cloud Translate platform.

File:GoogleGroupVendor.png

2021-05-14T16:29:34Z

Prosenthal: Screenshot showing the user interface for creating and configuring a Google Translate vendor.

== Summary ==
Screenshot showing the user interface for creating and configuring a Google Translate vendor.

File:AddGoogleVendor.png

2021-05-14T16:28:29Z

Prosenthal: Screenshot showing the location of the Add Google Vendor Button in the Localyzer Jenkins server configuration.

== Summary ==
Screenshot showing the location of the Add Google Vendor Button in the Localyzer Jenkins server configuration.

Test Page Masnes

2021-05-13T18:04:15Z

Prosenthal:

Test

Michael confirming Peter's account can edit.