Localization (L10N) UI Help

Contents

General

The MethodScript website supports localization efforts, to better serve communities that are primarily non-English speaking. While much of the application itself is necessarily written in English (function names, etc would be a disaster to try to localize), the documentation for the application does not necessarily need to be in English.

To this end, a Localization (or L10n) framework has been put in place to facilitate bilingual localizers to help translate the documentation into languages other than English! Much care has been put into ensuring the accuracy of the documentation, and the language of it is no exception. General help for the localization framework can be found on the website here, and you should be familiar with that before using this tool, but this help file describes use of the tool itself.

In order to use this program, you must have git installed and available on your path. For instructions on how to install this, see the git installation guide.

There are two main workflows when doing localization, the categorization workflow, and the translation workflow. Before a segment may be translated, it must first be categorized. Categorization is simply the act of ensuring whether or not the segment itself is appropriate, that is, ensuring that the original English is correct, and that the segementation logic behaved correctly. It is also about categorizing it as machine translatable or not. To complete categorization, review the original English, and ensure it is correct. If it is untranslatable, because it is for instance, completely a technical string, mark it as untranslatable, and the categorization is done. This prevents translation of the segment in any locale. Similarly, if the English is incorrect, or the segmentation logic was wrong, and this segment has something wrong with the original English in such a way that it should be fixed, mark the segment as "suspect", which prevents the segment from being translated in any locale, and flags the segment to be reviewed by developers. Due to the way the segmentation logic works, this should not be translated, as segments can't be changed. Changing the text of a segment creates a brand new segment, but the old segment remains in the database until manually removed later. Finally, the segment should be reviewed for suitability for machine translation. If the segment partially contains technical strings that are plain words, but shouldn't be translated for technical reasons, then the segment should be marked as not eligible for machine translation.

Once the segment is fully categorized, this unlocks the translation panel for all locales. Each segment must be reviewed before it can be localized, but this review only needs to happen once to unlock it in all locales. There are filters available to help guide these workflows, depending on what you've set out to do.

There are 4 filters, in addition to the one that shows all segments, and are intended to support the following workflows:

Fork Repository

Before the system can be used, you must fork the primary repository, and create a local copy. Go to Tools->Fork Database... to launch the fork tool, which will help you get a repository initially set up.

Allowing Machine Translations

To use the machine translation features of the tool, a subscription to the Azure Cognitive Services must be set up. More information about how to sign up for an account and subscription can be found here. While paid subscriptions exist, there is a free tier, which can be used in limited amounts per month. Once a subscription to Cognitive Services is set up, the key and endpoint can be found under Resource Management -> Quick Start. These values can be copied into the tool under Tools->Add Azure Key. You can choose to store the values to your computer, so they don't need to be re-entered every time, but do keep in mind that they are stored in plain text in your local persistence network, so it may be unwise to do so.