Difference between revisions of "Globalyzer Lite for Continuous Globalization"

From Lingoport Wiki
Jump to: navigation, search
(Created page with "= Introduction = Globalyzer Lite can be integrated into a developer's IDE. It allows i18n scanning of a project based on a Globalyzer project definition file most likely at th...")
 
Line 1: Line 1:
 
= Introduction =
 
= Introduction =
Globalyzer Lite can be integrated into a developer's IDE. It allows i18n scanning of a project based on a Globalyzer project definition file most likely at the top level directory of the source code so that developers can check their code before pushing them to the main repository. It does not have the power features of Workbench, but does not demand developers leave their IDE to check code for i18n candidate issues.
+
Globalyzer CLI can be deployed on a Continuous Globalization system. It allows i18n scanning of a project based on a Globalyzer project.gproj saved filed most likely at the top level directory of the source code; the results are then pushed to the Dashboard.
   
 
= Target User=
 
= 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 Globalyzer Lite user is a developer working on a global market application.
 
  +
  +
The typical Globalyzer CLI <code>actor</code>is a Jenkins system which automates the tasks of scanning and pushing the results to the Dashboard.
   
 
= Typical Deployment =
 
= Typical Deployment =
  +
The Globalyzer client, including the Command Line Interface jar file, has been installed on the Continuous Globalization system, with a database to store the results of the scans.
Lite has been unzipped on the software developer's desktop and configured as an external tool in their IDE. The source code has a Globalyzer project definition file at the top level directory which specifies how the code should be scanned. The developer's desktop has access to the Globalyzer server
 
  +
The source code may have a <code>project.gproj</code> file at the top level directory which specifies how the code should be scanned.
   
[[File:Lite for Software Developers.gif]]
+
[[File:CLI for CI.gif]]
  +
  +
<b>Note</b>: If you add LRM to this picture, the Continuous Globalization system needs to be a Linux machine, preferably Ubuntu.
   
 
= Typical Workflow=
 
= Typical Workflow=
The developer uses to Lite within the IDE to:
+
Jenkins uses the Globalyzer CLI via scripts to:
* Scan the code being worked on for potential i18n issues before checking in the code to the source code repository
+
* Get the code to be analyzed from a repository
  +
** Optionally, import the Globalyzer project from the <code>project.gproj</code> file <i>if necessary</i>; The project may already exist in the database.
* refactors the code based on the checks
 
* pushes that code to the repository
+
* Scan the code for potential i18n issues
  +
* Push the results of the scan to the Dashboard
  +
   
This requires the rule sets used to scan the code have been vetted and the Globalyzer project definition file makes sense.
+
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 20:33, 26 August 2015

Introduction

Globalyzer CLI can be deployed on a Continuous Globalization system. It allows i18n scanning of a project based on a Globalyzer project.gproj saved filed most likely at the top level directory of the source code; the results are then pushed to the Dashboard.

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 Globalyzer CLI actoris a Jenkins system which automates the tasks of scanning and pushing the results to the Dashboard.

Typical Deployment

The Globalyzer client, including the Command Line Interface jar file, has been installed on the Continuous Globalization system, with a database to store the results of the scans. The source code may have a project.gproj file at the top level directory which specifies how the code should be scanned.

CLI for CI.gif

Note: If you add LRM to this picture, the Continuous Globalization system needs to be a Linux machine, preferably Ubuntu.

Typical Workflow

Jenkins uses the Globalyzer CLI via scripts to:

  • Get the code to be analyzed from a repository
    • Optionally, import the Globalyzer project from the project.gproj file if necessary; The project may already exist in the database.
  • Scan the code for potential i18n issues
  • Push the results of the scan to the Dashboard


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