Difference between revisions of "Globalyzer i18n Process"
(→In Scope Check) |
(→Manager in Dashboard) |
||
| (33 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | == Introduction == |
||
| − | '''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. |
||
| − | 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. |
||
| + | * For service engagements, an initial step is the process of discovery: the customer and services team dive 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 a customer's architect that can help explain the structure of the software, inter-dependencies of the modules, what is in or out of scope, and the first priorities. Finally, there is a discussion around “deprecated code” as well as other development priorities that might lead to re-writing or replacement of sections of the code. The analysis 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. |
||
| + | |||
| + | * Companies that are new to Globalyzer (and/or Localyzer) will likely want to have Lingoport assistance for at least the first few i18n iterations, be it with the code refactoring itself or how to set up the first iterations. Lingoport has over 18 years of experience with this discovery process and is familiar with the complexities that accompany large software projects. |
||
| + | |||
| + | |||
| + | |||
| + | == Overview Diagram == |
||
| + | |||
| + | [[File:Globalyzer Iterations.PNG|600px|center]] |
||
| + | |||
| + | Before starting with Globalyzer, make sure to verify the IT setup, and which iterations to start with before going on to the next iteration. I18n project may have to address thousands of issues and development teams may be overwhelmed. |
||
| + | |||
| + | Lingoport recommends addressing issues in a step by step way and keep the i18n work manageable for all involved. |
||
| + | |||
| + | An iteration can be based on a module, a set of user facing screens, a type of issues, a repository. |
||
| + | |||
| + | Before starting with Globalyzer, make sure to have an identified iteration. |
||
==IT Check== |
==IT Check== |
||
| − | The first step is to make sure the IT setup is correct and complete. |
+ | 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. Before any other step, please make sure to have the checklist (mail support at lingoport dot com if that is not the case), and that each prerequisite checklist step is completed before going to the next step. |
||
| + | |||
| + | == Programming Language == |
||
| + | An application typically consists in many layers, each with its own programming language. Each may require a specific Globalyzer rule set (how to scan the code) and refactoring approach. One iteration may focus on a programming language in the application. |
||
| − | == Basic Files Check == |
+ | === 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. |
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 == |
+ | === 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: |
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 |
* Project->Run Project Files Inspector |
||
| Line 20: | Line 40: | ||
* Look at the File Inspection report to determine what scans this code base needs |
* Look at the File Inspection report to determine what scans this code base needs |
||
| − | == |
+ | == Module == |
| + | === 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. |
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== |
+ | ===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. |
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 |
Depending on the i18n requirements, out of scope code can include |
||
| − | * deprecated code, |
+ | * deprecated or dead code, |
| − | * dead code, |
||
* application configuration modules, |
* application configuration modules, |
||
* ALM settings, |
* ALM settings, |
||
| Line 33: | Line 53: | ||
* generated code, |
* generated code, |
||
* SQL dump files, |
* SQL dump files, |
||
| + | * Compiled code, |
||
| − | * Any code not created by the dev team. |
||
| + | * Test code, |
||
| + | * Infrastructure, |
||
| + | * Other code not created by the dev team. |
||
These meetings provide substantial insight into the eventual Globalyzer setup. |
These meetings provide substantial insight into the eventual Globalyzer setup. |
||
| − | ==Logical Grouping Check== |
+ | ===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. |
+ | 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. |
||
| + | In particular, identification of a module around a user facing functionality may lead to clear and immediate feedback post refactoring and redeployment of the application. |
||
| − | ==Iteration Check== |
||
| + | |||
| + | ===Include/Exclude Check=== |
||
| + | The Globalyzer iteration configuration is will have the updated include/exclude list for directories and files in the repository. |
||
| + | |||
| + | == i18n Issue Type== |
||
| + | An iteration may address only certain i18n issues, for instance Embedded String, or Date Format issues. A Globalyzer project based on the target issue will focuses the iteration, allow to refine the rule set specifically for that issue type, and the i18n team can go through the issues with the same refactoring approach, for instance externalizing Embedded Strings using a utility or refactoring Date Format issues with the proper method for the programming language. |
||
| + | |||
| + | For instance: |
||
| + | |||
| + | * What method(s) do you use for debug? (strings passed to those methods need to be filtered out) |
||
| + | * What is the default severity of i18n scanning you'd like to start with? |
||
| + | ** P1, possibly P2, to start - recommended |
||
| + | |||
| + | * Do you want to scan for everything i18n, or limit scans to: |
||
| + | ** Strings |
||
| + | ** Concatenations |
||
| + | ** Certain locale sensitive methods, like date/time |
||
| + | |||
| + | ==Iteration Check - Addressing i18n Issues== |
||
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. |
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. |
||
| + | At the end of each iteration, '''the i18n issues need to be addressed'''. This can be done in many ways: |
||
| − | ==Include/Exclude Check== |
||
| + | * Correcting the i18n issue in the code. |
||
| − | The Globalyzer final configuration is will have the updated include/exclude list for directories and files in the repository. |
||
| + | * Ignoring the detected issue, especially if it's a false positive. |
||
| + | ** See: https://wiki.lingoport.com/False_Positives#Globalyzer_Comment_Tags |
||
| + | ** Modifying the Rule Set to ignore certain |
||
| + | ** Excluding files or directories from the scanning |
||
| + | |||
| + | If the issues are not addressed, going to the next iteration will only add issues and may overwhelm the development and the localization team |
||
| + | |||
| + | == Globalyzer in IDE for Developers == |
||
| + | Developers should use Globalyzer in IDE in order to fix or ignore issues. Please see: |
||
| + | * https://vimeo.com/693626014 |
||
| + | * https://wiki.lingoport.com/Globalyzer_in_IDE |
||
| + | * https://www.globalyzer.com/gzserver/help/referenceLite/globalyzer-lite-IDE-usage.html |
||
| + | |||
| + | == Dashboard for Managers == |
||
| + | Managers should track progress of the i18n project using Dashboard. Please see: |
||
| + | * https://wiki.lingoport.com/Dashboard_Users_Guide |
||
| + | |||
| + | == Globalyzer Workbench for i18n Experts == |
||
| + | I18n experts should configure and refine rule sets using Workbench. Please see: |
||
| + | * https://www.globalyzer.com/gzserver/help/usersguide/toc.html |
||
| + | * https://www.globalyzer.com/gzserver/help/tutorials/toc.html |
||
| + | * https://lingoport.com/recordings/globalyzer-tutorials/ |
||
| + | |||
| + | == Tying it all Together == |
||
| + | From Workbench to Dashboard to Globalyzer in IDE, how things are tied together: |
||
| + | *https://vimeo.com/693626014 |
||
Latest revision as of 18:44, 22 August 2022
Contents
Introduction
Lingoport has both products and services for internationalization (i18n) and localization (L10N) automation.
- For service engagements, an initial step is the process of discovery: the customer and services team dive 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 a customer's architect that can help explain the structure of the software, inter-dependencies of the modules, what is in or out of scope, and the first priorities. Finally, there is a discussion around “deprecated code” as well as other development priorities that might lead to re-writing or replacement of sections of the code. The analysis 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 Localyzer) will likely want to have Lingoport assistance for at least the first few i18n iterations, be it with the code refactoring itself or how to set up the first iterations. Lingoport has over 18 years of experience with this discovery process and is familiar with the complexities that accompany large software projects.
Overview Diagram
Before starting with Globalyzer, make sure to verify the IT setup, and which iterations to start with before going on to the next iteration. I18n project may have to address thousands of issues and development teams may be overwhelmed.
Lingoport recommends addressing issues in a step by step way and keep the i18n work manageable for all involved.
An iteration can be based on a module, a set of user facing screens, a type of issues, a repository.
Before starting with Globalyzer, make sure to have an identified iteration.
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. Before any other step, please make sure to have the checklist (mail support at lingoport dot com if that is not the case), and that each prerequisite checklist step is completed before going to the next step.
Programming Language
An application typically consists in many layers, each with its own programming language. Each may require a specific Globalyzer rule set (how to scan the code) and refactoring approach. One iteration may focus on a programming language in the application.
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
Module
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,
- Infrastructure,
- 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.
In particular, identification of a module around a user facing functionality may lead to clear and immediate feedback post refactoring and redeployment of the application.
Include/Exclude Check
The Globalyzer iteration configuration is will have the updated include/exclude list for directories and files in the repository.
i18n Issue Type
An iteration may address only certain i18n issues, for instance Embedded String, or Date Format issues. A Globalyzer project based on the target issue will focuses the iteration, allow to refine the rule set specifically for that issue type, and the i18n team can go through the issues with the same refactoring approach, for instance externalizing Embedded Strings using a utility or refactoring Date Format issues with the proper method for the programming language.
For instance:
- What method(s) do you use for debug? (strings passed to those methods need to be filtered out)
- What is the default severity of i18n scanning you'd like to start with?
- P1, possibly P2, to start - recommended
- Do you want to scan for everything i18n, or limit scans to:
- Strings
- Concatenations
- Certain locale sensitive methods, like date/time
Iteration Check - Addressing i18n Issues
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.
At the end of each iteration, the i18n issues need to be addressed. This can be done in many ways:
- Correcting the i18n issue in the code.
- Ignoring the detected issue, especially if it's a false positive.
- See: https://wiki.lingoport.com/False_Positives#Globalyzer_Comment_Tags
- Modifying the Rule Set to ignore certain
- Excluding files or directories from the scanning
If the issues are not addressed, going to the next iteration will only add issues and may overwhelm the development and the localization team
Globalyzer in IDE for Developers
Developers should use Globalyzer in IDE in order to fix or ignore issues. Please see:
- https://vimeo.com/693626014
- https://wiki.lingoport.com/Globalyzer_in_IDE
- https://www.globalyzer.com/gzserver/help/referenceLite/globalyzer-lite-IDE-usage.html
Dashboard for Managers
Managers should track progress of the i18n project using Dashboard. Please see:
Globalyzer Workbench for i18n Experts
I18n experts should configure and refine rule sets using Workbench. Please see:
- https://www.globalyzer.com/gzserver/help/usersguide/toc.html
- https://www.globalyzer.com/gzserver/help/tutorials/toc.html
- https://lingoport.com/recordings/globalyzer-tutorials/
Tying it all Together
From Workbench to Dashboard to Globalyzer in IDE, how things are tied together:
