Globalyzer i18n Process

Lingoport Pre-Flights The term pre-flight is an analogy from aviation where pilots check the aircraft before take-off.

Lingoport has both products and services for internationalization (i18n) and localization (L10N) automation. For service engagements, the very first step is the process of discovery where the team dives into the repository to uncover the important issues about the software including programming languages, databases, libraries used, resource file types and structure, and directory structures. This process normally includes discussions with an architect that can help explain the structure of the software, interdependencies of the modules, and what is in or out of scope. Finally, there is a discussion around “deprecated code” as well as development priorities that might lead to re-writing or replacement of sections of the code. The pre-flight may or may not include the prioritization of the sequence of refactoring to align with the timing of customer/market needs.

Companies that are new to Globalyzer and/or LRM will likely want to have Lingoport assistance for at least the first few pre-flights.This is because Lingoport has over 18 years of experience with this discovery process and is familiar with the complexities that accompany large software projects.

IT Check

The first step is to make sure the IT setup is correct and complete. Lingoport provides a checklist to help with this process, and a script to check that the software installation was done correctly.

Basic Files Check

The next step is to run a utility to Count Lines of Code (CLOC) that is available from this link https://github.com/AlDanial/cloc. The CLOC reveals the types of programming languages and size of modules. It is a quick way to get a first look at the complexity of the code.

Globalyzer File Inspection

In addition to the Basic File Check, if Globalyzer scanning is part of the on-boarding, use the Globalyzer File Inspection to get a sense of what kind of possible rule sets to apply. From the Globalyzer workbench:

• Project->Run Project Files Inspector
• Browse to select the Excel Output file. Click Save.
• Click Generate to generate the report.
• The Console tab in the Workbench will tell you when/where the report was generated.
• Look at the File Inspection report to determine what scans this code base needs

Basic Code Check

Next is a first look at the code and the repository structure. The repository files can guide some of the on-boarding. For example, a repository named ‘jquery’ is highly likely to contain third party libraries that would be considered out of scope.

In Scope Check

The next step is a meeting or series of meetings with architects familiar with the code. These are busy people so the meetings are typically brief and to the point. The goal is to understand how the code works, what the components are, how they interact, what is user facing, and what is in scope and what is out of scope. Depending on the i18n requirements, out of scope code can include

• deprecated or dead code,
• application configuration modules,
• ALM settings,
• third party libraries,
• generated code,
• SQL dump files,
• Compiled code,
• Test code,
• Other code not created by the dev team.

These meetings provide substantial insight into the eventual Globalyzer setup.

Logical Grouping Check

Globalyzer projects need to be set up by logical components of the source code, especially in large applications where components are developed according to different frameworks, coding style and their specific libraries, often developed with different skill sets. For example, a Globalyzer project would be done for Android and another Globalyzer project for iOS, even if the repository contained both. Each of the logical components can then be configured as a Globalyzer project and may have its own Globalyzer Rule Sets. Use Globalyzer File Inspector on the project to double check the content of the module.

Project Creation Check

Globalyzer projects need to be set up by logical components of the source code, especially in large applications where components are developed according to different frameworks, coding style and their specific libraries, often developed with different skill sets. For example, a Globalyzer project would be done for Android and another Globalyzer project for iOS, even if the repository contained both. Each of the logical components can then be configured as a Globalyzer project and may have its own Globalyzer Rule Sets. Use Globalyzer File Inspector on the project to double check the content of the module.

Iteration Check

It is recommended to scan a small subset of the code known to be in scope to get a feel for the types of i18n issues that are most common and to get a sense for the scope of rule set refinement that will be needed. It also success tests the pathways to make sure the eventual full scans can be executed and the proper ports and access permissions are invoked properly. Each iteration is faster and can be validated more quickly. Validation of each iteration with a member of the development team is recommended, and the final configuration should be reviewed by an architect if possible.

Include/Exclude Check

The Globalyzer final configuration is will have the updated include/exclude list for directories and files in the repository.