Difference between revisions of "LRM for Continuous Globalization"

From Lingoport Wiki
Jump to: navigation, search
(Created page with "= Introduction = The Lingoport Resource Manager, or LRM, is to be deployed on a Continuous Globalization system. It automates the tasks for tracking, checking, sending, receiv...")
 
Line 1: Line 1:
 
= Introduction =
 
= Introduction =
 
The Lingoport Resource Manager, or LRM, is to be deployed on a Continuous Globalization system. It automates the tasks for tracking, checking, sending, receiving, and pushing checking resource bundles to a repository, and provides a true status of the translation from the code perspective in the Dashboard.
 
The Lingoport Resource Manager, or LRM, is to be deployed on a Continuous Globalization system. It automates the tasks for tracking, checking, sending, receiving, and pushing checking resource bundles to a repository, and provides a true status of the translation from the code perspective in the Dashboard.
  +
  +
It integrates seamlessly with translation products, such as Lingotek.
   
 
= Target User=
 
= Target User=
Line 6: Line 8:
 
 
 
The typical LRM <code>actor</code> is a Jenkins system which automates the different tasks and pushes the results to the Dashboard.
 
The typical LRM <code>actor</code> is a Jenkins system which automates the different tasks and pushes the results to the Dashboard.
  +
  +
= Typical Deployment =
  +
LRM is installed on the Continuous Globalization system, with a database to track the actions and the status of the resource bundles.
  +
The LRM project has been on-boarded on the Continuous Globalization system.
  +
  +
[[File:CLI for CI.gif]]
  +
  +
<b>Note</b>: the Continuous Globalization system needs to be a Linux machine, preferably Ubuntu.
  +
  +
= Typical Workflow=
  +
Jenkins uses LRM via scripts to:
  +
* Get the code from a repository
  +
* Establish the status of the translation for all resource bundles
  +
* Push prep kits to translation products if necessary and if the critical checks pass.
  +
* Pull translated files from the translation products if necessary
  +
* Check the translated files and push them to the repository at the right location if the critical checks pass
  +
* Notify the configured recipients of the actions taken
  +
  +
  +
This requires the rule sets used to scan the code have been vetted and the Globalyzer <code>project.gproj</code> file makes sense.

Revision as of 22:22, 26 August 2015

Introduction

The Lingoport Resource Manager, or LRM, is to be deployed on a Continuous Globalization system. It automates the tasks for tracking, checking, sending, receiving, and pushing checking resource bundles to a repository, and provides a true status of the translation from the code perspective in the Dashboard.

It integrates seamlessly with translation products, such as Lingotek.

Target User

The results are presented via the Dashboard for any registered users, such as development team members, development management, i18n specialists, L10n management, translators, QA, etc.

The typical LRM actor is a Jenkins system which automates the different tasks and pushes the results to the Dashboard.

Typical Deployment

LRM is installed on the Continuous Globalization system, with a database to track the actions and the status of the resource bundles. The LRM project has been on-boarded on the Continuous Globalization system.

CLI for CI.gif

Note: the Continuous Globalization system needs to be a Linux machine, preferably Ubuntu.

Typical Workflow

Jenkins uses LRM via scripts to:

  • Get the code from a repository
  • Establish the status of the translation for all resource bundles
  • Push prep kits to translation products if necessary and if the critical checks pass.
  • Pull translated files from the translation products if necessary
  • Check the translated files and push them to the repository at the right location if the critical checks pass
  • Notify the configured recipients of the actions taken


This requires the rule sets used to scan the code have been vetted and the Globalyzer project.gproj file makes sense.