Difference between revisions of "L10n Vendors"

From Lingoport Wiki
Jump to: navigation, search
(→‎Translation FTP Vendor Integration)
(→‎Advantages)
 
(69 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 
=Supported L10n Vendors=
  
=Supported L10n Vendors=
  +
To get a current list of LSP ([[Terms_and_Definitions#localizationVendor|localization service provider]]) and TMS ([[Terms_and_Definitions#TMD|translation management system]]) companies that are integrated with Localyzer, please email ''sales@lingoport.com''.
−
Currently, LRM supports 5 [[Terms_and_Definitions#localization|localization]] paths for sending files to be translated. They are:
  
  +
−
*'''FTP'''
  
  +
= Recommended Approach =
−
*'''GlobalLink'''
  
  +
== Lingoport FTP Protocol ==
−
*'''Lingotek'''
  
  +
Lingoport strongly recommends using the FTP protocol. With that approach,
−
*'''Local'''
  
  +
* Lingoport automatically pushes valid resource files to be translated following a specific naming convention to an FTP end point
−
*'''Worldserver'''
  
  +
* The translation group picks up the files and [[Terms_and_Definitions#onboarding|on-boards]] them in the TMS following their own automated pattern
  +
* The translation group returns the translated resource files to another FTP end point as per their system
  +
* Localyzer picks up the translated files, validates them, and imports them into the proper repository
  +
  +
==Advantages==
  +
* '''Robustness''': FTP has been in place for decades and is one of the most reliable protocols for transmitting files from one system to another
  +
* '''Simplicity''': FTP and zip are well known and are well understood in the industry
  +
* '''Security''': FTP support SSH The FTP system can allow only some IP ranges to access the FTP port(s); (SSL encryption is not recommended)
  +
* '''IP restrictions''': IT can specify which IP addresses are allowed to communicate with the FTP server, so that only the TMS and Localyzer have access to the endpoints, making the server invisible to other systems
  +
* '''Automation''': Localyzer pushes and retrieves files automatically; The translation group supplies the automation to and from the automation end point
  +
* '''Network Failure Handling''': If the network goes down when accessing FTP, files are resent later when the network is up; Files are not lost due to downtime
  +
* '''Asynchronicity''': The Localyzer system and the TMS do not need any special connection; Files can be sent and received independently
  +
* '''Scalability''': The volume sent to an FTP system does not slow down either Localyzer or a TMS due to traffic. Each system can push or retrieve files without slowing down the other. FTP supports large volume of data
  +
* '''Configurability''': Configuring the FTP end point location is something well understood by IT departments and simple to configure (for Localyzer , see below)
  +
* '''Testability''': Checking the proper configuration is straightforward
  +
* '''Fast Set Up''': Given the above, setting up Localyzer with FTP is the fastest and simplest route
  +
  +
Note: Lingoport has set up Localyzer over FTP with many Translation Groups and the TMS of their choice and any TMS vendor can add their system to this integration pattern.
  +
* See '''[[Zip_Files_For_Prep_and_Import | FTP Integration Details ]]'''.
  +
  +
==Resource File Transmission Protocols==
  +
For most use cases, Lingoport recommends sending files to translation over '''SFTP'''. Direct API-based connections are also available to some TMS systems.
  +
  +
Overall, Localyzer supports 5 [[Terms_and_Definitions#localization|localization]] paths for sending files to be translated. They are:
  +
  +
'''Typical:'''
  +
* '''Local'''
  +
** Files are kept on the system Localyzer resides on. Good for debugging.
  +
* '''FTP'''
  +
** FTP/SFTP. Typical method of sending resource files to/from translation.
  +
  +
'''API Based:'''
  +
* '''GlobalLink'''
  +
* '''Lingotek'''
  +
* '''WorldServer'''
  +
  +
=Transmission Protocol Configuration=
   
 
The type of L10n Vendor is defined in the '''config_l10n_vendor.properties''' file that can exist at either the group or project level. See [[Group Configuration Files]]. A template of this file can be found at <code><HOME>/lingoport/lrm-server-x.y/deploy/templates/dir_structure/group/config</code>
  
The type of L10n Vendor is defined in the '''config_l10n_vendor.properties''' file that can exist at either the group or project level. See [[Group Configuration Files]]. A template of this file can be found at <code><HOME>/lingoport/lrm-server-x.y/deploy/templates/dir_structure/group/config</code>
Line 11: Line 48:
 
The default location of the config_l10n_vendor.properties file is at the group level.
 
The default location of the config_l10n_vendor.properties file is at the group level.
 
The default settings do not define a vendor so that an error will occur when prepping a kit, forcing the user to chose a vendor. The global L10n Vendor attributes are:
  
The default settings do not define a vendor so that an error will occur when prepping a kit, forcing the user to chose a vendor. The global L10n Vendor attributes are:
  +
*'''l10n.vendor=ftp''' - uncomment if using FTP/SFTP, the recommended approach
  +
 
*'''l10n.vendor=lingotek''' - uncomment if using Lingotek
  
*'''l10n.vendor=lingotek''' - uncomment if using Lingotek
−
*'''l10n.vendor=local''' - uncomment if storing the prep/translated files locally.
 +
*'''l10n.vendor=local''' - uncomment if storing the prep/translated files locally
 
*'''l10n.vendor=worldserver''' - uncomment if using Worldserver
  
*'''l10n.vendor=worldserver''' - uncomment if using Worldserver
−
*'''l10n.vendor=ftp''' - uncomment if using FTP
  
 
*'''l10n.vendor=globallink''' - uncomment if using GlobalLink
  
*'''l10n.vendor=globallink''' - uncomment if using GlobalLink
−
*'''l10n.vendor.nonsupported.extensions''' - a vendor may not support a specific extension such as .json. Enter any extensions that are not supported by the vendor but are supported by LRM. See [[LRM Fixing Issues]] for LRM supported extensions. An error will occur if there is no conversion protocol for a non-supported extension.
 +
*'''l10n.vendor.nonsupported.extensions''' - a vendor may not support a specific extension such as .json. Enter any extensions that are not supported by the vendor but are supported by Localyzer . See [[LRM Fixing Issues]] for Localyzer supported extensions. An error will occur if there is no conversion protocol for a non-supported extension.
   
 
Example file:
  
Example file:
 
<pre>
  
<pre>
  +
l10n.vendor=ftp
−
#Default to 'no vendor defined'
  
 
#l10n.vendor=lingotek
  
#l10n.vendor=lingotek
 
#l10n.vendor=local
  
#l10n.vendor=local
 
#l10n.vendor=worldserver
  
#l10n.vendor=worldserver
−
#l10n.vendor=ftp
  
 
#l10n.vendor=globallink
  
#l10n.vendor=globallink
 
l10n.vendor.nonsupported.extensions=
  
l10n.vendor.nonsupported.extensions=
Line 30: Line 67:
 
</pre>
  
</pre>
   
  +
=InContext Server Configuration=
−
==FTP==
  
  +
In order for a L10n Vendor to be able to communicate to the Lingoport InContext Server, there must be a valid Localyzer LQA license for the group as well as a valid configuration for the InContext Server. See [[LRM_Instrumentation|InContext License]] for more information. The InContext Server configuration is located in the L10n Vendor configuration file with the following keys.
  +
<pre>
  +
l10n.vendor.incontext.server.url=&lt;valid http or https URL pointing to the InContext Server &gt;
  +
l10n.vendor.incontext.auth.token=&lt;valid authorization token&gt;
  +
</pre>
   
  +
The authorization token will be supplied by your InContext Server administrator.
−
===FTP Configuration===
  
  +
During the prep kit process, the configured URL and token will be used to access the InContext Server. If these are not valid then an error will occur and the prep kit process will fail. If the defined InContext server is valid then all the resource files will be [[LRM_Commands_Reference#Create_Instrumented_files|instrumented]] and the prep kit files will contain the InContext decoration.
  +
  +
==InContext Decoration==
  +
When prepping a kit where there is a valid InContext server configuration, each of the keys that need to be translated will have an InContext tag above the key. The default tag prefix is '''LRM_INCONTEXT'''. Your L10n vendor may have a specific tag that is used for filtering. If this is the case, then a unique InContext tag can be configured in the L10n Vendor configuration file using the following key:
  +
<pre>
  +
l10n.vendor.incontext.unique.tag=
  +
</pre>
  +
  +
If this key is missing or has a blank value then the default, LRM_INCONTEXT, tag will be used.
  +
  +
===InContext decoration examples===
  +
  +
:'''L10n Vendor Configuration'''
  +
  +
<pre>
  +
l10n.vendor.incontext.server.url=http://ec5-4-3-2-1.amazonaws.com:8081
  +
l10n.vendor.incontext.auth.token=0qhZ9yTvtW5
  +
</pre>
  +
  +
::'''XML type prep kit file'''
  +
<pre>
  +
<?xml version="1.0" encoding="UTF-8"?>
  +
<!--MyProject_8_6 - CHANGES-ONLY-->
  +
<resources>
  +
<!--LRM_INCONTEXT http://ec5-4-3-2-1.amazonaws.com:8081/incontext-server/lookup?key=3130_192&token=0qhZ9yTvtW5-->
  +
<string name="Hello">Hello</string>
  +
</pre>
  +
  +
::'''Properties type prep kit file'''
  +
<pre>
  +
#MyProject_1_4 - CHANGES-ONLY
  +
#LRM_INCONTEXT http://ec5-4-3-2-1.amazonaws.com:8081/incontext-server/lookup?key=422_238&token=0qhZ9yTvtW5
  +
myString=Hello
  +
</pre>
  +
  +
===InContext decoration examples using unique InContext tag===
  +
  +
:'''L10n Vendor Configuration'''
  +
  +
<pre>
  +
l10n.vendor.incontext.server.url=http://ec5-4-3-2-1.amazonaws.com:8081
  +
l10n.vendor.incontext.auth.token=0qhZ9yTvtW5
  +
l10n.vendor.incontext.unique.tag=MY_SPECIAL_TAG
  +
</pre>
  +
  +
::'''XML type prep kit file'''
  +
<pre>
  +
<?xml version="1.0" encoding="UTF-8"?>
  +
<!--MyProject_8_6 - CHANGES-ONLY-->
  +
<resources>
  +
<!--MY_SPECIAL_TAG http://ec5-4-3-2-1.amazonaws.com:8081/incontext-server/lookup?key=3130_192&token=0qhZ9yTvtW5-->
  +
<string name="Hello">Hello</string>
  +
</pre>
  +
  +
::'''Properties type prep kit file'''
  +
<pre>
  +
#MyProject_1_4 - CHANGES-ONLY
  +
#MY_SPECIAL_TAG http://ec5-4-3-2-1.amazonaws.com:8081/incontext-server/lookup?key=422_238&token=0qhZ9yTvtW5
  +
myString=Hello
  +
</pre>
  +
  +
=FTP=
  +
  +
==FTP Configuration==
 
To choose FTP as the vendor, uncomment the <code>l10n.vendor=ftp</code> in the config_l10n_vendor.properties file.
  
To choose FTP as the vendor, uncomment the <code>l10n.vendor=ftp</code> in the config_l10n_vendor.properties file.
   
Line 66: Line 172:
 
Note: For special cases, like using One Planet, you may need to create an .ssh key http://www.linuxproblem.org/art_9.html.
  
Note: For special cases, like using One Planet, you may need to create an .ssh key http://www.linuxproblem.org/art_9.html.
   
−
==== FTP attributes ====
 +
=== FTP attributes ===
 
If the end point is FTP, the
 
If the end point is FTP, the
 
l10n.vendor=ftp
  
l10n.vendor=ftp
Line 78: Line 184:
   
   
−
* '''ftp.out.host''' - The hostname that the prep-kits prepared by LRM are being sent to.
 +
* '''ftp.out.host''' - The hostname that the prep-kits prepared by Localyzer are being sent to.
 
* '''ftp.out.location.path''' - the directory path on the host for the files to be translated
  
* '''ftp.out.location.path''' - the directory path on the host for the files to be translated
 
* '''ftp.out.password''' - password associated with the username that is using the protocol
  
* '''ftp.out.password''' - password associated with the username that is using the protocol
Line 85: Line 191:
 
* '''ftp.out.username''' - the username used with the protocol to send the files to be translated.
  
* '''ftp.out.username''' - the username used with the protocol to send the files to be translated.
   
  +
From a command line attempt to use the protocol (ssh, ssl or ftp) and the username and password to log into the host. This can verify the settings.
−
=== Translation FTP Vendor Integration===
  
  +
On the host, verify that the in and out paths exist.
−
Lingoport pushes zip files to the configured FTP outbound endpoint and consumes zip files sent on the incoming endpoint. The structure of the zip file is defined below:
  
   
  +
=== FTP Vendor Integration===
−
The files sent back and forth over FTP have the following characteristics:
  
  +
Lingoport pushes '''zip files''' to the configured FTP outbound endpoint, for example '''to_translation''' and consumes zip files sent on the incoming endpoint, for example '''from_translation'''.
   
  +
The '''structure''' of the incoming and outgoing zip files is defined in the following page:
−
* The data files to be translated or returned from translation are sent in a '''zip file'''.
  
  +
* See '''[[Zip_Files_For_Prep_and_Import | FTP Integration Details ]]'''.
−
* The '''zip file''' is named according to this convention: '''<code><group-name>.<project-name>.<kit-version>.<locale>.zip</code>'''. For example, a zip file could be named '''<code>Queens.Champions.1.fr_fr.zip</code>''': The group-name is Queens, the project-name is Champions, the kit version is 1, and the target locale is fr_fr.
  
−
* The zip file consists of '''one top level directory''', <code><group-name>.<project-name>.<kit-version>.<locale></code>, with all the files to be translated under it.
  
−
* There is '''one zip file per target locale'''. You may target 10 locales for translation for project "Champions" under group "Queens". You then would have 10 zip files to send over FTP.
 
−
* A zip file may contain '''more than one file and more than one file type'''.
 
−
* Each file to be translated has a comment at the top of the file which needs to be kept when returning the file from translation vendor.
  
−
* The '''translated files''' will be named the same as the original files (so they could be _en.properties even if the content is for French)
  
−  
−
Two FTP endpoints are necessary: a ''''to translation'''' end point and a ''''from translation'''' endpoint.
  
−  
−
==== Example of the Zip File Structure ====
  
−
The structure of the zip file for target locale ''de'' is as follows:
  
−
<pre>
  
−
Acme.frontend.1.de.zip
  
−
| -- Acme.frontend.1.de
  
−
| -- resources.properties
  
−
| -- messages.resx
  
−
| -- errors.json
  
−
</pre>
  
−
 
−
This is the structure of the zip file sent for translation on the FTP outbound endpoint and also the structure and name of the file received from translation on the FTP inbound endpoint.
 
−  
−
Notes:
 
−
* The names of the files (resources.properties) must be the same exact name when the translation is returned as it was in the zip file sent for translation.
 
−
* The files in one prep kit must all be returned in the translated zip file with a complete translation. If prep kit #1 had three files, the same three files must be returned in, say, German with every key/value pair returned.
  
−  
−
===Files Exchanged===
  
−
Lingoport pushes zip files to the configured FTP outbound endpoint and consumes zip files sent on the incoming endpoint. The structure of the zip file is defined below:
  
−  
−
====Naming Convention====
  
−
All the outgoing zip files (containing the translated files) must be named in the following manner:
  
−
*<code><group>.<project>.<prepkitversion>.<locale>.zip</code>
  
−
 
−
For instance, for the group <code>Acme</code> and the project <code>frontend</code>, the first zip file sent for a German translation would be named:
  
−
Acme.frontend.1.de.zip
  
−
Where
  
−
*'''Acme.frontend''' is the name of the group/project
  
−
*'''1''' is the kit version (how many times it's been sent over)
  
−
*'''de''' is the target locale.
  
−  
−
=== Zip File Structure ===
  
−
In addition the structure of the zip file is as follows:
  
−
<pre>
  
−
Acme.frontend.1.de.zip
  
−
| -- Acme.frontend.1.de
  
−
| -- resources.properties
  
−
| -- messages.resx
  
−
| -- errors.json
  
−
</pre>
  
−
 
−
This is the structure of the zip file sent for translation on the FTP outbound endpoint and also the structure and name of the file received from translation on the FTP inbound endpoint.
 
−  
−
Notes:
 
−
* The names of the files (resources.properties) must be the same exact name when the translation is returned as it was in the zip file sent for translation.
 
−
* The files in one prep kit must all be returned in the translated zip file with a complete translation. If prep kit #1 had three files, the same three files must be returned in, say, German with every key/value pair returned.
  
   
 
=== SSH/SFTP proxy server ===
  
=== SSH/SFTP proxy server ===
Line 154: Line 208:
 
* ProxySOCKS5
  
* ProxySOCKS5
   
−
==== ProxyHTTP ====
 +
=== ProxyHTTP ===
 
The expected java options for ProxyHTTP are:
  
The expected java options for ProxyHTTP are:
 
* ftp.proxyHost
  
* ftp.proxyHost
Line 163: Line 217:
 
:: <span style="background-color: #eaecf0;>export _JAVA_OPTIONS='-Dftp.proxyHost=theproxyhost -Dftp.proxyPort=123'</span>
  
:: <span style="background-color: #eaecf0;>export _JAVA_OPTIONS='-Dftp.proxyHost=theproxyhost -Dftp.proxyPort=123'</span>
   
−
==== ProxySOCKS4 ====
 +
=== ProxySOCKS4 ===
 
The expected java options for ProxySOCKS4 are:
  
The expected java options for ProxySOCKS4 are:
 
* ftp.socks4.proxyHost
  
* ftp.socks4.proxyHost
Line 172: Line 226:
 
:: <span style="background-color: #eaecf0;>export _JAVA_OPTIONS='-Dftp.socks4.proxyHost=theproxyhost -Dftp.socks4.proxyPort=123'</span>
  
:: <span style="background-color: #eaecf0;>export _JAVA_OPTIONS='-Dftp.socks4.proxyHost=theproxyhost -Dftp.socks4.proxyPort=123'</span>
   
−
==== ProxySOCKS5 ====
 +
=== ProxySOCKS5 ===
 
The expected java options for ProxySOCKS5 are:
  
The expected java options for ProxySOCKS5 are:
 
* ftp.socks5.proxyHost
  
* ftp.socks5.proxyHost
Line 181: Line 235:
 
:: <span style="background-color: #eaecf0;>export _JAVA_OPTIONS='-Dftp.socks5.proxyHost=theproxyhost -Dftp.socks5.proxyPort=123'</span>
  
:: <span style="background-color: #eaecf0;>export _JAVA_OPTIONS='-Dftp.socks5.proxyHost=theproxyhost -Dftp.socks5.proxyPort=123'</span>
   
−
===Encoding of translated files===
 +
==Encoding of translated files==
 
We are expecting the .properties to be returned in UTF-8 (no BOM) and so they should not have unicode escaped characters.
  
We are expecting the .properties to be returned in UTF-8 (no BOM) and so they should not have unicode escaped characters.
   
  +
= Other Integrations =
−
==GlobalLink==
  
  +
<!-- [[Special L10n Vendor Integrations | Special L10n Vendor Integrations ]] -->
−
===GlobalLink Configuration===
  
−
To choose GlobalLink as the vendor, uncomment the <code>l10n.vendor=globallink</code> in the config_l10n_vendor.properties file.
  
   
  +
[[Local Vendor]]
−
The information that is needed to upload the files to be translated as well as retrieve translated files is:
  
   
  +
[[GlobalLink]]
−
<pre>
  
−
#GLOBALLINK
  
−
#globallink.url=
  
   
  +
[[Lingotek]]
−
#globallink.password.for.upload=
  
−
#globallink.username.for.upload=
  
   
  +
[[WorldServer]]
−
#globallink.password.for.download=
  
−
#globallink.username.for.download=
  
   
  +
[[XTM]]
−
#globallink.project.name=
  
−
#globallink.project.shortcode=
  
   
  +
[[Memsource]]
−
#Owner is not required
  
−
#globallink.owner=
  
   
  +
[[TradosEnterprise]]
−
#When to download files - 1 is on completed status (default), 2 is for preliminary targets based on workflow steps
  
−
#globallink.download.option=1
  
−
</pre>
  
   
  +
MemoQ
−
===GlobalLink Locale Mapping===
  
−
GlobalLink does not allow language only locales. If there are LRM target locales that are language-only, then a mapping between the LRM locale and the GlobalLink locale should be entered into <code>config_gl_locale_mapping.properties</code> file if it doesn't already exist.
 
−  
−
Though the default location for the configuration file is at the global level (<HOME>/Lingoport_Data/L10nStreamlining/config), the file may also reside at the group or project level. The configuration file also exists in the LRM install directory's <code><HOME>/lingoport/lrm-server-x.y/deploy/templates/dir_structure/global/config</code> folder.
  
−  
−
===GlobalLink File Format Mapping===
  
−
The <code>config_gl_file_format.properties</code> file contains the mapping between LRM supported extensions and their corresponding GlobalLink file formats
  
−  
−
Though the default location for the configuration file is at the global level (<HOME>/Lingoport_Data/L10nStreamlining/config), the file may also reside at the group or project level. The configuration file also exists in the LRM install directory's <code><HOME>/lingoport/lrm-server-x.y/deploy/templates/dir_structure/global/config</code> folder.
  
−  
−
==Lingotek==
  
−
To choose Lingotek as the vendor, uncomment the <code>l10n.vendor=lingotek</code> in the config_l10n_vendor.properties file.
  
−  
−
The information that is needed to upload the files to be translated as well as retrieve translated files is:
  
−
<pre>
  
−
#Lingotek Attributes
  
−
#Contains the host URL and api request formats
  
−
lingotek.api.hosturl=https://cms.lingotek.com
  
−  
−
#Contains the ids for community, workflow and access token
  
−
lingotek.api.id.access.token=
  
−
lingotek.api.id.community=
  
−
lingotek.api.id.workflow=
  
−  
−
#Example callbackURL - replace job name (lingotek) with actual Jenkins job name
  
−
lingotek.api.callbackurl=http://jenkins.company.com:8080/buildByToken/buildWithParameters?job=LingotekCallback&token=LINGOSQUARE&
  
−  
−
#{0} is the access.token
  
−
lingotek.api.bearer=Bearer {0}
  
−
</pre>
  
−  
−
===Lingotek Locale Mapping===
  
−
Lingotek does not allow language only locales. If there are LRM target locales that are language-only, then a mapping between the LRM locale and the Lingotek locale should be entered into <code>config_lingotek_locale_mapping.properties</code> file if it doesn't already exist.
 
−  
−
The default location for the configuration file is at the group level (<HOME>/Lingoport_Data/L10nStreamlining/<group name>/config). The configuration file also exists in the LRM install directory's <code><HOME>/lingoport/lrm-server-x.y/deploy/templates/dir_structure/group/config</code> folder.
  
−  
−
== Local Vendor==
  
−
The ''Local'' vendor is used for storing the prep/translated files on the local machine (the same machine where LRM is running). This type of vendor is useful when testing out LRM.
  
−  
−
===Local Vendor Configuration===
  
−
To choose a Local vendor for the prep/translated files, uncomment (or add) the <code>l10n.vendor=local</code> in the appropriate config_l10n_vendor.properties file.
  
−  
−
The information that is required when configuring a local vendor is:
  
−
<pre>
  
−
##LOCAL VENDOR
  
−
##Absolute path for zip files to translation (outgoing)
  
−
local.out.absolute.path=
  
−
##Absolute path for zip files from translation (incoming)
  
−
local.in.absolute.path=
  
−
</pre>
  
−  
−
==Worldserver==
  
−
To choose Worldserver as the vendor, uncomment the <code>l10n.vendor=worldserver</code> in the config_l10n_vendor.properties file.
  
−  
−
The information that is needed to upload the files to be translated as well as retrieve translated files is:
  
−  
−
<pre>
  
−
#WORLDSERVER Attributes
  
−
## Worldserver attributes for import kit files
  
−
worldserver.in.host=
  
−
worldserver.in.location.path=
  
−
worldserver.in.password=
  
−
worldserver.in.port=22
  
−
#SSH, SSL or blank (for FTP)
  
−
worldserver.in.ftp.protocol=SSH
  
−
worldserver.in.username=
  
−
## ssl implicit flag. Set to 0 for explicit, set to 1 for implicit
  
−
worldserver.in.ssl.implicit=0
  
−  
−
##Zip file name that contains the translated files needs to beone of the following options.
  
−
## Option #1 for zip file prefix - Default
  
−
worldserver.in.file.name.prefix=${groupname}.${projectname}.${kitversion}.${lrmlocale}
  
−
## Option #2 for zip file prefix
  
−
#worldserver.in.file.name.prefix=${groupname}.${projectname}.${kitversion}.${wslocale}
  
−
## Option #3 for zip file prefix
  
−
#worldserver.in.file.name.prefix=${groupname}.${projectname}.${kitversion}.${lrmlocale}.${wslocale}
  
−  
−
## Worldserver attributes for send kit files
  
−
worldserver.out.url=
  
−
worldserver.out.user=
  
−
worldserver.out.password=
  
−
worldserver.client=
  
−
## Available tokens ${groupname},${projectname},${kitversion},${lrmlocale}, ${wslocale}
  
−
worldserver.out.project.name=${groupname}.${projectname}.${kitversion}.${lrmlocale}
  
−
</pre>
  
−  
−
=== Worldserver Locale Mapping ===
  
−
The <code>config_ws_locale_mapping.properties</code> configuration file contains the mapping between the LRM target locales and the unique Worldserver locale. The mappings must be unique!
  
−
All target locales must be represented in this configuration file.
 
−
The configuration file can exist at the project level and group levels. The configuration file also exists in the LRM install directory's <code><HOME>/lingoport/lrm-server-x.y/deploy/templates/dir_structure/group/config</code> folder.
  
−  
−
Example if target locales are de and fr_FR
  
−
<pre>
  
−
de=008_German
  
−
fr_fr=002_French_France
  
−
</pre>
  
−  
−
=== Worldserver Project Type Mapping===
  
−
The <code>config_ws_locale_projecttype_mapping.properties</code> configuration file contains the mapping between a LRM target locale and the Worldserver project type. All LRM target locales must be represented in this configuration file.
  
−
The configuration file can exist at the project level and group levels. The configuration file also exists in the LRM install directory's <code><HOME>/lingoport/lrm-server-x.y/deploy/templates/dir_structure/group/config</code> folder.
  
−  
−
Example if target locales are de and fr_FR
  
−
<pre>
  
−
de=1221
  
−
fr_fr=1221
  
−
</pre>
  

Latest revision as of 17:40, 26 May 2023

Supported L10n Vendors

To get a current list of LSP (localization service provider) and TMS (translation management system) companies that are integrated with Localyzer, please email sales@lingoport.com.

Recommended Approach

Lingoport FTP Protocol

Lingoport strongly recommends using the FTP protocol. With that approach,

  • Lingoport automatically pushes valid resource files to be translated following a specific naming convention to an FTP end point
  • The translation group picks up the files and on-boards them in the TMS following their own automated pattern
  • The translation group returns the translated resource files to another FTP end point as per their system
  • Localyzer picks up the translated files, validates them, and imports them into the proper repository

Advantages

  • Robustness: FTP has been in place for decades and is one of the most reliable protocols for transmitting files from one system to another
  • Simplicity: FTP and zip are well known and are well understood in the industry
  • Security: FTP support SSH The FTP system can allow only some IP ranges to access the FTP port(s); (SSL encryption is not recommended)
  • IP restrictions: IT can specify which IP addresses are allowed to communicate with the FTP server, so that only the TMS and Localyzer have access to the endpoints, making the server invisible to other systems
  • Automation: Localyzer pushes and retrieves files automatically; The translation group supplies the automation to and from the automation end point
  • Network Failure Handling: If the network goes down when accessing FTP, files are resent later when the network is up; Files are not lost due to downtime
  • Asynchronicity: The Localyzer system and the TMS do not need any special connection; Files can be sent and received independently
  • Scalability: The volume sent to an FTP system does not slow down either Localyzer or a TMS due to traffic. Each system can push or retrieve files without slowing down the other. FTP supports large volume of data
  • Configurability: Configuring the FTP end point location is something well understood by IT departments and simple to configure (for Localyzer , see below)
  • Testability: Checking the proper configuration is straightforward
  • Fast Set Up: Given the above, setting up Localyzer with FTP is the fastest and simplest route

Note: Lingoport has set up Localyzer over FTP with many Translation Groups and the TMS of their choice and any TMS vendor can add their system to this integration pattern.

Resource File Transmission Protocols

For most use cases, Lingoport recommends sending files to translation over SFTP. Direct API-based connections are also available to some TMS systems.

Overall, Localyzer supports 5 localization paths for sending files to be translated. They are:

Typical:

  • Local
    • Files are kept on the system Localyzer resides on. Good for debugging.
  • FTP
    • FTP/SFTP. Typical method of sending resource files to/from translation.

API Based:

  • GlobalLink
  • Lingotek
  • WorldServer

Transmission Protocol Configuration

The type of L10n Vendor is defined in the config_l10n_vendor.properties file that can exist at either the group or project level. See Group Configuration Files. A template of this file can be found at <HOME>/lingoport/lrm-server-x.y/deploy/templates/dir_structure/group/config

The default location of the config_l10n_vendor.properties file is at the group level. The default settings do not define a vendor so that an error will occur when prepping a kit, forcing the user to chose a vendor. The global L10n Vendor attributes are:

  • l10n.vendor=ftp - uncomment if using FTP/SFTP, the recommended approach
  • l10n.vendor=lingotek - uncomment if using Lingotek
  • l10n.vendor=local - uncomment if storing the prep/translated files locally
  • l10n.vendor=worldserver - uncomment if using Worldserver
  • l10n.vendor=globallink - uncomment if using GlobalLink
  • l10n.vendor.nonsupported.extensions - a vendor may not support a specific extension such as .json. Enter any extensions that are not supported by the vendor but are supported by Localyzer . See LRM Fixing Issues for Localyzer supported extensions. An error will occur if there is no conversion protocol for a non-supported extension.

Example file: 

l10n.vendor=ftp
#l10n.vendor=lingotek
#l10n.vendor=local
#l10n.vendor=worldserver
#l10n.vendor=globallink
l10n.vendor.nonsupported.extensions=

InContext Server Configuration

In order for a L10n Vendor to be able to communicate to the Lingoport InContext Server, there must be a valid Localyzer LQA license for the group as well as a valid configuration for the InContext Server. See InContext License for more information. The InContext Server configuration is located in the L10n Vendor configuration file with the following keys. 

l10n.vendor.incontext.server.url=<valid http or https URL pointing to the InContext Server >
l10n.vendor.incontext.auth.token=<valid authorization token>

The authorization token will be supplied by your InContext Server administrator. During the prep kit process, the configured URL and token will be used to access the InContext Server. If these are not valid then an error will occur and the prep kit process will fail. If the defined InContext server is valid then all the resource files will be instrumented and the prep kit files will contain the InContext decoration.

InContext Decoration

When prepping a kit where there is a valid InContext server configuration, each of the keys that need to be translated will have an InContext tag above the key. The default tag prefix is LRM_INCONTEXT. Your L10n vendor may have a specific tag that is used for filtering. If this is the case, then a unique InContext tag can be configured in the L10n Vendor configuration file using the following key: 

l10n.vendor.incontext.unique.tag=

If this key is missing or has a blank value then the default, LRM_INCONTEXT, tag will be used.

InContext decoration examples

L10n Vendor Configuration
l10n.vendor.incontext.server.url=http://ec5-4-3-2-1.amazonaws.com:8081 
l10n.vendor.incontext.auth.token=0qhZ9yTvtW5
XML type prep kit file
<?xml version="1.0" encoding="UTF-8"?>
<!--MyProject_8_6 - CHANGES-ONLY-->
<resources>
<!--LRM_INCONTEXT http://ec5-4-3-2-1.amazonaws.com:8081/incontext-server/lookup?key=3130_192&token=0qhZ9yTvtW5-->
<string name="Hello">Hello</string>
Properties type prep kit file
#MyProject_1_4 - CHANGES-ONLY
#LRM_INCONTEXT http://ec5-4-3-2-1.amazonaws.com:8081/incontext-server/lookup?key=422_238&token=0qhZ9yTvtW5
myString=Hello

InContext decoration examples using unique InContext tag

L10n Vendor Configuration
l10n.vendor.incontext.server.url=http://ec5-4-3-2-1.amazonaws.com:8081 
l10n.vendor.incontext.auth.token=0qhZ9yTvtW5
l10n.vendor.incontext.unique.tag=MY_SPECIAL_TAG
XML type prep kit file
<?xml version="1.0" encoding="UTF-8"?>
<!--MyProject_8_6 - CHANGES-ONLY-->
<resources>
<!--MY_SPECIAL_TAG http://ec5-4-3-2-1.amazonaws.com:8081/incontext-server/lookup?key=3130_192&token=0qhZ9yTvtW5-->
<string name="Hello">Hello</string>
Properties type prep kit file
#MyProject_1_4 - CHANGES-ONLY
#MY_SPECIAL_TAG http://ec5-4-3-2-1.amazonaws.com:8081/incontext-server/lookup?key=422_238&token=0qhZ9yTvtW5
myString=Hello

FTP

FTP Configuration

To choose FTP as the vendor, uncomment the l10n.vendor=ftp in the config_l10n_vendor.properties file.

The information that is needed to upload the files to be translated as well as retrieve translated files is: 

#FTP Attributes
## FTP inbound attributes for import kit files
ftp.in.host=
ftp.in.port=
ftp.in.location.path=
ftp.in.password=
ftp.in.username=
##SSH, SSL or empty
ftp.in.protocol=
## ssl implicit flag. Set to 0 for explicit, set to 1 for implicit
ftp.in.ssl.implicit=0

## FTP outbound attributes for prep kit files
ftp.out.host=
ftp.out.port=
ftp.out.location.path=
ftp.out.username=
ftp.out.password=
##SSH, SSL or empty
ftp.out.protocol=
## ssl implicit flag. Set to 0 for explicit, set to 1 for implicit
ftp.out.ssl.implicit=0

The ftp.out attributes refer to locations for files being sent out for translation. The ftp.in refers to locations for files coming back in (import) from translation.

Note: For special cases, like using One Planet, you may need to create an .ssh key http://www.linuxproblem.org/art_9.html.

FTP attributes

If the end point is FTP, the 

  l10n.vendor=ftp

must be uncommented. The 'in' attributes refer to the files coming back to Lingoport Resource Manager after translation. The 'out' attributes refer to the prep-kit files which are send from Lingoport Resource Manager.

  • ftp.in.host - the hostname where the translated files reside
  • ftp.in.location.path - the directory path on the host containing the translated files
  • ftp.in.password - password associated with the username that is using the protocol
  • ftp.in.port - the port for the protocol service. In general, SSH uses port 22 and FTP uses port 21
  • ftp.in.protocol - this can be SSH or SSL. If left blank, the protocol is FTP
  • ftp.in.username - the username used with the protocol to receive the translated files


  • ftp.out.host - The hostname that the prep-kits prepared by Localyzer are being sent to.
  • ftp.out.location.path - the directory path on the host for the files to be translated
  • ftp.out.password - password associated with the username that is using the protocol
  • ftp.out.port - the port for the protocol service. In general, SSH uses port 22 and FTP uses port 21
  • ftp.out.protocol - this can be SSH or SSL. If left blank, the protocol is FTP
  • ftp.out.username - the username used with the protocol to send the files to be translated.

From a command line attempt to use the protocol (ssh, ssl or ftp) and the username and password to log into the host. This can verify the settings. On the host, verify that the in and out paths exist.

FTP Vendor Integration

Lingoport pushes zip files to the configured FTP outbound endpoint, for example to_translation and consumes zip files sent on the incoming endpoint, for example from_translation.

The structure of the incoming and outgoing zip files is defined in the following page:

SSH/SFTP proxy server

If the ftp.out.protocol/ftp.in.protocol is SSH and there is a SFTP proxy server then the proxy host and proxy port are set up via java options.

There are 3 proxy protocols supported

  • ProxyHTTP
  • ProxySOCKS4
  • ProxySOCKS5

ProxyHTTP

The expected java options for ProxyHTTP are:

  • ftp.proxyHost
  • ftp.proxyPort

Linux example if setting java options within a shell session.

export _JAVA_OPTIONS='-Dftp.proxyHost=theproxyhost -Dftp.proxyPort=123'

ProxySOCKS4

The expected java options for ProxySOCKS4 are:

  • ftp.socks4.proxyHost
  • ftp.socks4.proxyPort

Linux example if setting java options within a shell session.

export _JAVA_OPTIONS='-Dftp.socks4.proxyHost=theproxyhost -Dftp.socks4.proxyPort=123'

ProxySOCKS5

The expected java options for ProxySOCKS5 are:

  • ftp.socks5.proxyHost
  • ftp.socks5.proxyPort

Linux example if setting java options within a shell session.

export _JAVA_OPTIONS='-Dftp.socks5.proxyHost=theproxyhost -Dftp.socks5.proxyPort=123'

Encoding of translated files

We are expecting the .properties to be returned in UTF-8 (no BOM) and so they should not have unicode escaped characters.

Other Integrations

Local Vendor

GlobalLink

Lingotek

WorldServer

XTM

Memsource

TradosEnterprise

MemoQ

Retrieved from "http://wiki.lingoport.com/index.php?title=L10n_Vendors&oldid=97465"