[マ쾖旭蕞ミŴнаŧ ϊŝ ₤ČŤỐỞĹＳ !!! !!!]?

"LCTOOLS" is a tool set developed and provided to you by the Windows Localizability team. This tool set provides you with a global commenting model built on top of LocStudio no-compile technology. The tool set can also be used to create pseudo localized builds. As the tools are built on top of LocStudio technology *), the tools can be used for all projects using LocStudio for localization. The main features of the tools are:

  • Creation and editing of localization information files. These files contain comments and instructions on what strings can be localized and how they can be localized, providing a global commenting solution for any file format used in your product supported by LocStudio.
  • Creation of pseudo localized files for localizability test purposes. Pseudo localization can be done both from the command line as well as through LocStudio EDBs
  • Checking if your file is in a localizable format. LCTOOLS is based on the same parser technology as LocStudio, which means that you will see the same string resources in our UI-tool LCAdmin as those seen by our localizers using this localization tool. For more information on LocStudio, see http://tools/InfoCenter/LocStudioInfoCenter.asp
  • Change tracking of string resources of US files

LCTOOLS also provides you with an updated and much improved version of PLP and an updated pseudo extension in LocStudio. It is recommended that you use these updated versions when pseudo localizing files in LocStudio

In this help file you can find the following topics:

  • What is pseudo localization
  • Installation and configuration
  • LCTOOLS basics
  • Commenting tool LCAdmin.exe
  • Pseudo build tool LCCmd.exe
  • LocStudio functionality
  • Miscellaneous utilities

The following aliases are provided for information and feedback:

  • NTPSLOC: Alias of the Windows localizability team.
  • LCTOOLS: LCTOOLS information alias

*) LCTOOLS is built on top of the LocStudio parser model and PLP (Pseudo Localization Platform) owned by PTT (Productivity Tools Team). LCTOOLS 2.1 is compatible with LocStudio 4.54 and contains an updated version of PLP.


What is pseudo localization

[Шħáţ ĭ§ ρśęúđớ ļôсâℓϊżặтΐөπ !!! !!! !!! ]:

Pseudo localization is the process of creating/testing simulated localized builds. The process automatically "translates" all localizable string resources in a way specified by the pseudo language. The pseudo language has been designed to test the localizability of string translation. The pseudo localization process can also expose a number of other localizability and process issues, like dialog font localization, BIDI enabling issues, build issues, etc.

An example of a pseudo localized window:

What are the benefits of pseudo localization:

  • Pseudo localization can find the majority of localizability issues at an early stage of the project. This reduces the need for late code changes and/or code branches in a late stage of the product development cycle when changes are more risky and expensive.

  • Pseudo localization testing is valid for all languages, which means reducing the amount of testing on localized products

  • Pseudo localization helps development to better understand localization and localizability issues

Pseudo language:

The pseudo language needs to stress the system for its localizability and find as many functional problems as possible and certain categories of cosmetic problems. This can be done by:

  • Translating all strings translated by the localization teams, checking the localizability of the strings and checking for hard coded strings .

  • Using as many extended characters and code pages as possible, checking for correct use of fonts and code pages. The replacement of characters is mostly done by substituting characters in English strings by similar looking extended characters. This will result in a readable (US-English) and testable pseudo localized build.

  • Extending string length to stress the system for buffer overrun.

  • Using delimiters to see how strings are built during runtime .

  • Translating strings randomly to check for string dependencies (characters are substituted randomly to make sure that each string is translated differently)

  • Stretching dialogs (meaning increasing horizontal and/or vertical sizes of all dialog elements) to allow string length grow and checking for hard coded sizes (by stretching the dialogs we minimize the amount of truncations in pseudo localized builds to keep the pseudo builds readable and testable).

  • Using other options like prepending file name, resource identifier, etc.

  • Applying dialog font replacement or setting mirroring properties to find FE and BIDI enabling issues.

Pseudo localization versus pilot localization:

The use of pilot languages to test for the localizability of a product is a common practice in many groups. Both pseudo builds and pilot language builds will expose certain unique areas. The use of both pseudo and a pilot language should be encouraged, pseudo localization at the early stages of a product cycle, pilot localization later in the product cycle. The following is a comparison of both:

  • Pseudo translation is a pilot language, checking localizability and establishing localization/build processes

  • Pseudo translation tests the product on all its limitations, while a pilot language only gives a partial coverage (translations vary from language to language, no language would stress the system completely)

  • Pseudo translated builds can be created/updated much faster than pilot builds, important at the start of big projects. The configuration of pseudo builds can be changed per build, enlarging test coverage.

  • A pilot language is a real language. Some more language and terminology specific issues can be exposed in a pilot language that cannot be exposed in pseudo.

  • Certain scenarios can only be tested on localized builds. A simple example would be upgrade cases, ACT testing, etc..

Although less functional testing of localized builds is necessary, there will always be a need for a certain amount of localization testing as pseudo can not guarantee all test scenarios.

Information for testing and development:

  • Pseudo localization and testing

  • Pseudo localization and development


What is pseudo localization

[虍ポ滌旭ボＰ§ёчｄｏ ｌθζдｌｉｚλｔｉθπ аπｄ ｔе§ｔｉηｇ !!! !!! !!! !]:

There are many different definitions used by teams for internationalization terms, these are the ones used in Windows:

  • Globalization: Globalization (or Internationalization, I18N) of software is the ability of the US product to work using different locales, codepages, and language settings. Globalization issues can be found testing the US software.
  • Localizability: Localizability is the ability to localize the product in all its target languages, without introducing functional and certain cosmetic deficiencies. Localizability issues can only be found by localizing/testing the software.
  • Localization: Localization refers to the translation phase of the process

The definition of localizability tells us that there are certain bugs that are introduced in the US product that can only be reproduced on localized systems. This is where pseudo localization fits in. Pseudo localization provides us with a solution to produce simulated localized builds without going through a localization pass itself. The process is automated and different flavors can be produced very easily, targeting to simulate different localization scenarios.

Functional bugs:

The main focus of pseudo localization testing is functionality. Localization can break software through any of the following:

  • Strings or part of strings that are translated but that should have been left in English. Think of registry keys, function names, etc
  • Buffer overflows
  • Strings that need to be localized consistently throughout the product. Think of folder names, account names, etc
  • Functionality that is broken using extended characters in translation
  • Products that can not be adapted correctly to the local market

Cosmetic bugs:

Even if most cosmetics like dialog sizing and localization of hotkeys are the responsibility of localization, certain cosmetic bugs fall under the category of localizability and will need to be tested for.

  • Extended characters that are not displayed correctly
  • Hard coded sizes or strings
  • Dialog fonts that cannot be translated (this option will need to be enabled in the pseudo build. Far East languages do translate dialog fonts)
  • UI that is not correctly mirrored using the mirroring feature (mirroring is a technology that can be used for BIDI languages)


What is pseudo localization

[ŸÛ¡ÁNPsëµđơ lœ©ålïzåtíœñ æñđ ₫êvêl¤pmêñt !!! !!! !!! !!!]:

There are a few areas that are important for the localizability of a product:

  • All files are in a standard localizable format. This means that all resources that need to be localized are extracted by the tools used by localization. For Microsoft, this means that all files are supported by the LocStudio file parsers. If a new file format is introduced, a new LocStudio file parser will need to be developed.
  • Localization of resources does not introduce functional bugs. All resources exposed to localization are localizable in all the target languages of the product without introducing functional and some categories of cosmetic bugs. If there are limitations in the way string resources can be translated, information on these limitations will need to be provided.
  • A product is adaptable. Many products will need a certain level of adaptation. Think of changing fonts, spell checkers, speech recognizers, etc
  • The product is localizable in terms of terminology. No assumptions are made on the sequence of words, casing, and gender.
  • The product consists of minimal run-time UI. Run-time UI causes many cosmetic bugs in localized builds that can not easily be prevented by localization as in general localization tools only display static resources.

For more information on localizability best practices, see http://globalsys/pseudoloc/Localizability/Best_Practices.htm.

Files in localizable format:

You can use LCAdmin to check if a file is in a localizable format as LCTOOLS uses the same parser manager as the localization tool LocStudio. Open the file that needs to be localized in LCAdmin to check if all localizable string resources are parsed and displayed correctly. Note that information is displayed in the log window on errors reported by the parser manager.

For more information on LCAdmin and the commenting of files, see Commenting tool LCAdmin

Commenting model:

Many bugs are introduced in localized products because of the lack of information on localizable resources available to localization. A resource file is mostly just a collection of resources without additional information. Resources can either be used for display, but are often used functionally too. Even if the resource file contains comments and instructions, these are not saved in the compiled binary for most file formats. As localization uses the compiled files as input, they can not see the instructions provided. As a result, localization does not know how and if resources can be translated, and bugs are introduced.

LCTOOLS provides a generic commenting tool LCAdmin that can create instruction files for compiled files that need to be localized. These instruction files can contain specific instructions on how string resources need to be localized and can also contain regular comments and background information. Examples of instructions for localization:

  • Flags for strings that cannot be translated
  • Placeholder instructions telling what parts of strings can not be translated
  • Maxlength information on the maximum string length
  • etc

For more information on LCAdmin and the commenting of files, see Commenting tool LCAdmin

Creation of pseudo binaries:

Pseudo localization is a simulation of localization. LCTOOLS provides a pseudo localization build tool LCCmd that can be used to create pseudo binaries. These binaries can be tested to find out if they can be localized without breaking functionality or introducing cosmetic issues. LCCmd provides the ability to create pseudo binaries using different codepages and localization scenarios like mirroring and dialog font localization. The instruction files are used as input when pseudo binaries are created.

For more information on LCCmd and the pseudo localization of files, see Pseudo build tool LCCmd


<OBJECT id=hhctrl type="application/x-oleobject"

[ダ漾袢ポ虍Ιл§таｌｌαｔｉｏл αｎｄ ￠бηｆｉｇчｒдｔｉби !!! !!! !!! !]:

Below you can find more information on the installation and configuration of LCTOOLS::

  • Installation of LCTOOLS
  • Parsers and parser settings
  • HTML/XML configuration
  • Pseudo localization settings

Installation of LCTOOLS:

LCTOOLS comes in 3 different flavors:

  • LCTOOLS standalone package comes with the LCTOOLS files, LocStudio files, PLP, and LocStudio parsers
  • LCTOOLS LocStudio package comes with the LCTOOLS files, PLP, and LocStudio extensions
  • LCTOOLS LocStudio extension package comes with PLP (except for plputil.dll), LocStudio extensions, and lctools.chm

The standalone installation package releases with all default LocStudio parsers and parser settings. You can generate your own installation by taking the flat drop of files, adding/removing file parsers, and changing the configuration files lcdef.reg, lcdef.cmd, locxml.xml, and lctools.ini. These configuration files don't release as part of the LocStudio extension installation.

lcdef.reg:

lcdef.reg contains all the registry settings you can possibly set as part of your project. You can use this file to define parser settings, file extension settings, and HTML/XML settings. For more information on these settings, see Parsers and parser settings and HTML/XML configuration.

lcdef.reg in the standalone installation contains all default LocStudio parser settings and file extension settings to make modification easy. The LocStudio parsers that release with the standalone version of LCTOOLS will not be registered in case LocStudio is installed on your machine. lcdef.reg in the LocStudio installation contains only the LCTOOLS specific settings you might want to modify.

Note that any existing user settings and file extension lists in the registry will be overwritten if you register the standalone installation on a machine with LocStudio installed. Re-registration of a parser will always overwrite the file extension list with the default one, unless specified differently in lcdef.reg.

lcdef.cmd:

lcdef.cmd contains a list of elements that need to be registered beside LCTOOLS and the parser manager. You can use this file to add/remove LocStudio extensions you want to add these as part of your installation.

locxml.xml:

locxml.xml contains the XML parser configuration, for more information, see HTML/XML configuration.

lctools.ini:

lctools.ini contains the build number of LCTOOLS. Every time you run either LCCmd or LCAdmin, the installed LCTOOLS version in the registry will be compared with the build number in lctools.ini. If the build number (regular string comparison is used) doesn't match, the tools will be re-registered. This means that if you need to make a change in the configuration of the tools, you only have to update the build number in lctools.ini to have everybody use the latest settings. It also means that the tools are completely self-installed, so you can add the tools to the development environment and have everybody use the tools without having them to do any kind of installation. Explicit registration is also available through "lccmd -r" and the LCAdmin UI ("File"/"Register DLLs").

lctools.ini also contains a list of file parsers you want to install. If you want to add/remove file parsers, you will need to modify this list. The list was added to not have the parser manager enumerate all DLLs in the folder and register them as parsers as this slows down the tools registration.

Parsers and parser settings:

LCTOOLS is based on the parser model of LocStudio. This means that exactly the same set of parsers can be used and the same strings are parsed as in LocStudio itself. Most binary information parsed by LocStudio is not parsed by LCTOOLS, exceptions are some dialog properties of WIN32 dialogs (dialog font, dialog size, mirroring flag, and dialog sizes) which are not displayed in LCAdmin, but which can be changed using the pseudo localization feature.

You can add/remove parsers as is described in the above section on lctools.ini.

There are two kind of settings used by the LocStudio file parsers, the parser options and the file extension lists. Both settings can be configured in lcdef.reg as described above.

Parser options:

LCTOOLS shares the parser options with the LocStudio user settings for parser options. The parser options are stored in "HKCU\Software\Microsoft\LocStudio 4.51\Parser Options". This means that LocStudio can be used to configure the parser options in lcdef.reg. Open LocStudio with the correct parsers installed, goto "Software"/"Parser Settings...", and configure the user settings for the parser options (it is recommended to set all user settings to non-default as you might have conflicts otherwise on machines with different user settings specified). Then export the branch "HKCU\Software\Microsoft\LocStudio 4.51\Parser Options" and add/replace the parser options in lcdef.reg.

Multiple sets of parser options:

Not all files within a project can always be parsed using one set of parser options. You can create multiple sets of parser options and specify a different set of parser options through the LCCmd command line switch "-s <ParserOption>" or through the LCAdmin file open dialog (Parser Setting). Parser options are stored in "HKCU\Software\Microsoft\LocStudio 4.51\<ParserOptions>". In the default case, the parser options are taken from the "Parser Options" branch, and no input value is required for the LCCmd switch. If you need to generate multiple sets of parser options, use LocStudio to create the branch "HKCU\Software\Microsoft\LocStudio 4.51\Parser Options", rename "Parser Options" in the registry, export the renamed branch, and add/replace in lcdef.reg.

File extension list:

The file extension list of a parser is used by the parser model to associate file extensions with file parsers. For a file to be recognized by a parser, its file extension needs to be listed in the file extension list of that parser. The file extension list of a parser can be found in
"HKLM\Software\Microsoft\LocStudio 4.51\Parsers\<Parser>\ExtensionList". You can either use LocStudio or the registry editor to modify the file extension list in the registry. To configure the file extension lists in lcdef.reg, export the branch "HKLM\Software\Microsoft\LocStudio 4.51\Parsers" and add/replace to lcdef.reg.

You can force LCTOOLS to use a certain parser through the lccmd command line switch "-e <ParserId>" or through LCAdmin file open dialog (Parser Type).

HTML/XML configuration:

HTML/XML is highly configurable as the file formats are highly diverse. You can specify how the files are parsed and what strings are (pseudo) localizable.

HTML configuration:

You can configure what information is parsed from an HTML or script file, what tags are regarded localizable or non-localizable, etc, by configuring the Loom HTML parser. The configuration is written to the registry and the default configuration is saved in "HKLM\Software\Microsoft\Weaver\Loom\Factory Settings". LocStudio releases with a utility LoomConfig.exe that you can use to modify the current configuration or to create a new configuration. Settings are generally written to "HKLM\Software\Microsoft\Weaver\Loom\<HTML Settings>" and the configuration to use is one of the parser options of the HTML parser. Loomconfig.exe and loomconfig.chm are included in LCTOOLS and LocStudio

To change the HTML configuration, use LoomConfig to modify the existing or to create a new configuration, export this modified/new configuration from the registry and add/replace this in lcdef.reg.

More information on localization of HTML:

  • Authoring HTML for localization: \\cptoolzone\toolbox\locstudio\docs\html\authoring HTML for localization.doc

XML configuration:

XML localization is configured through two files, locxml.dtd and locxml.xml. Read the below for more information.

  • XML parser: http://cptoolzone/tools/locstudio/ls45/parserdocs/xmlbestpractices/xml best practices.doc

HTML pseudo localization:

LCTOOLS considers strings parsed by the Loom HTML parser as either HTML-text (localizable), or as non-localizable text (type Other) by looking at the string category assigned to the string by the parser (configurable by the Loom settings). The mapping of what string categories are mapped to HTML-Text or non-localizable text is specified in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\LCTools\HTMLResMap. The default values are written in the registry by the registration of LCTOOLS and can be easily modified by adding them to lcdef.reg.

Some HTML strings are font names or font sizes which need (pseudo) localization. In most cases you can determine if a string is either a font name or font size, by looking at the resource identifier assigned to the item by the Loom HTML parser. If certain values are substrings of the identifier, the item is determined a font name or font size. The item is treated as an item with a Adaptation flag and possible translations are looked up in the mapping table. If a translation is not found in the mapping table, the item is left unlocalized. The strings used to determine if a item is a font name or font size are specified in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\LCTools\AdaptationRule. The default values are written in the registry by the registration of LCTOOLS and can be easily modified by adding them to lcdef.reg.

For more information on the use of adaptation instructions and the mapping table, see Mapping table process.

Pseudo localization settings:

There are several utilities that specify how a file is being pseudo localized.

  • Main configuration utility PLConfig
  • Build options and system variables for LCCmd
  • Build options within LCAdmin


[£CTΦΩ£S bάsιςs !!! !!!]:

  • Processes using LCTOOLS
  • LCTOOLS input files
  • Localizability instructions set
  • Limitations and file list
  • Pseudo localization settings
  • Pseudo mirroring
  • HTML pseudo localization
  • Mapping table process


[虍チ漾ゼミProcesses using LCTOOLS !!! !!! !!]:

LCTOOLS is a very versatile tool that can be used to help you with many internationalization aspects of your project. Below, a number of features are highlighted in a logical way in which they can form a localizability and pseudo localization process. Several of these functionalities can be used standalone too.

Tokenization (change tracking):

Tokenization is an easy way of tracking changes in string resources between builds. All string resources parsed by the LocStudio file parsers are dumped into so called token files in Unicode text format. These token files can be compared using any diff utilities. For more information, see Tokenization.

LC-maintenance (commenting):

One of the most important and useful features of LCTOOLS is the commenting feature. LCTOOLS enables a global commenting model for all file formats that are localized with LocStudio. Developers can and are encouraged to create lc-files (text files containing instructions and comments) which are then passed on to localization and imported and enforced in their EDBs. LC-files can also be used as input for pseudo localized builds, verifying the information added in the lc-file. LC-file maintenance is done through the UI-utility LCAdmin, for more information, see Commenting tool LCAdmin.

LCTOOLS also comes with a handy utility LCScan to create reports on the contents of a set of lc-files. For more information, see LC-file scan utility LCScan.

LC-verification:

LC-files can easily be out of date when many resource changes happen in a project. To prevent having to check all instructions in lc-files regularly, lccmd has an option that checks if string changes happened and instructions are out of date or redundant. For more information, see LC-file verification.

Building pseudo localized files (testing localizability and lc-info):

To test for localizability issues and to test the correctness of provided information in lc-files, pseudo builds can be created based on these lc-files. LCTOOLS provides a wide range of pseudo localization options through the pseudo build tool lccmd. For more information, see Pseudo build utility Lccmd.

Beside building pseudo builds through LCCmd, an updated pseudo extension and PLP are included in LCTOOLS. Install these pieces in your LocStudio environment to enable pseudo localization of your EDB. For more information, see Pseudo localization extension.

Building pseudo mirrored files (testing files for correct BIDI-enabling):

The pseudo mirroring process is targeted to find BIDI-enabling issues. LCTOOLS provides a process to generate pseudo mirrored files. For more information, see pseudo mirroring.

Information exchange with localization (instruction enforcement):

It is very important that information gathered and tested through LCTOOLS and pseudo localization, is provided and enforced to localization. LCTOOLS releases LocStudio extensions that make this exchange and enforcement possible. Correctness of translations can be checked through LocVer, a module built into LocStudio. For more information, see LC import/export.


[LCЋЮФLS їйpµт fїlёs !!! !!! !]:

The following are the input files used by LCTOOLS:

  • LC-file
  • Mapping table
  • PLP-configuration file

LC-file:

The lc-file is the carrier of comments and instructions for a file. The lc-file has the extension .lc and this extension is appended to the file name by default (eg notepad.exe.lc). The lc-file is a text file in the following format:

[Strings]
StringId="String"
...
[Checksum]
StringId=1234
...
[Constraints]
StringId={Locked}
...
[Comment]
StringId=comment
...

Only strings with comments or instructions will have entries in an lc-file. If a file has no comments or instructions at all, no lc-file will be created. The checksum will be used by the verification of the correctness of an lc-file. The strings in each section of the lc-file will be sorted by StringId.

Mapping table:

A mapping table is a lookup table for translations and is being used for two purposes:

  • String dependencies: Some strings need to be translated consistently to ensure correct functional software. Example of string dependencies are account names and folder names (of course it is better to prevent or remove such string dependencies). By marking strings with dependencies with a map-instruction, these strings will be looked up in the specified mapping table and so consistency is assured.
  • Adaptation: Strings marked with an adaptation instruction might have to be translated, but can only be translated by certain values. Example of these are font names that need to be changed for certain languages, or LCIDs that require to be set to the correct value of the target language. These kind of strings are used to adapt software. All strings marked with a adaptation will be looked up in the mapping table too.

The mapping table is a Unicode comma separated text file with four columns, source string, target string, property, and comment. The mapping table is case-insensitive. If a string is not found in the mapping table, the string is not translated. For more information, see Mapping table process.

PLP-configuration file:

LCTOOLS uses the pseudo localization engine PLP. PLP can be configured through a XML-file created with PLConfig. Without specifying a PLP configuration file, the default settings built into LCTOOLS are used. For more information on the creation of a configuration file, see PLP configuration utility PLConfig.


[ऴग़ऱॉउLocalizability instruction set !!! !!! !!! !]:

The following instructions are supported by LCTOOLS:

  • Locked instruction: {Locked}
    • This feature is used when a string can not be translated. Think of registry keys, API names, file names, etc.
  • Placeholder instruction: {PlaceHolder="substring"}
    • A placeholder is used when a part of a string is not localizable. An example is the wildcards used in "All files (*.*)|*.*||"
    • Some placeholder are set by default through PLP. You can configure PLP for the rules to use using PLConfig. The rules used by default:
      • Don't localize words containing the characters '%', '$', '_', '@', '[', or ']'
      • Don't localize the following substrings "\NULL", "\n", "\t"
    • You can remove a placeholder by selecting it in LCAdmin and clearing it. The default behavior will now be turned off and an instruction {NoRules} will be added automatically.
  • Maxlength instruction: {MaxLength=x}
    • Used when there is limitation on the size of the string.
  • Map instruction: {Map="string"} or {Map="string",Property} + comment
    • This instruction is used for strings that need to be localized consistent throughout the product. Think of account names and folder names, which are localized for several languages
    • The translation for a mapped string is looked up in a mapping table, specified through LCCmd
    • The property is used when multiple strings have string dependencies, but not necessarily to each other. By specifying a property, the tool can distinguish the cases and look up the correct translation. For example, "System" can both be an account name and a folder name.
    • When a map instruction is set, no string extension or delimiters will be used
    • When entering a map instruction, you will be asked to enter a comment
    • For more information, see Mapping table process
  • Adaptation instruction: {Adaptation} or {Adaptation,Property} + comment
    • An adaptation instruction is specified when a string is used for the adaptation of a product. Think of font names, font sizes, URLs, numeric info like LCID, codepage information, or just a value that is used to turn on/off a feature. These strings need to be localizable and need to be localized by some languages following certain rules, but cannot be localized randomly
    • The property is used when multiple strings are used for adaptation, but not necessarily have to be translated the same. By specifying a property, the tool can distinguish the cases and look up the correct translation.
    • When entering an adaptation instruction, you will be asked to enter a comment
    • For more information, see Mapping table process

Beside the above instructions, we have the following semi-instructions that are used for pseudo loc or commenting only:

  • NoRules: {NoRules}
    • When you change the default placeholders set by the tool, an instruction NoRules will be used to remember not to use this default behavior.
  • NoDelim: {NoDelim}
    • When you don't want any characters to be prepended or appended to a string, you can specify a NoDelim instruction.
  • Comment: Regular text
    • Comments are extremely useful for localization. Note that comments added to source code mostly are not saved in the compiled binaries. Localization tools extract strings from the compiled binaries and hence these comments are not seen by the localizers. LCTOOLS enables a global commenting model.
  • RTL MessageBox marker: {RTL}
    • For Arabic and Hebrew, you have the option to add the 2 RTL markers to any MessageBox text by simply adding the {RTL} rule. LcAdmin gives you the choice to either type {RTL} manually in the comments field or to simply click on the provided UI {RTL} button.


[Łîmíťăťíóňş ăňď fîĺę łíśţ !!! !!! !!!]:

Limitations of LCTOOLS:

Below are listed a number of the known limitations of LCTOOLS.

  • LCTOOLS is based on the LocStudio parser model and has a number of the same limitations as LocStudio
    • Several functionalities of LCTOOLS require the user to have Administrative rights on the local machine. It is recommended to have Administrative right on the local machine to ensure the tools to work correctly.
    • Files are associated with file parsers through an extension list. If a file extension is not listed under the correct file parser, the file is not recognized. Also, some extensions can be listed under different file parsers and the parser model can not always uniquely determine the correct parser to use. Both LCCmd and LCAdmin can force the use of a certain file parser.
  • Correct pseudo localization of strings can be very complex using certain combination of settings and instructions. As the tools have been developed and improved during its use on some projects, not all configurations have been tested to its fullest. Please send feedback and bugs to NTPSLOC (LCTOOLS development) or LCTOOLS (LCTOOLS discussion alias)
  • There are some limitations in PLP with the handling of hotkeys. If placeholders and other instructions are set for the part of the string after the hotkey, correct pseudo localization can not be assured.

File list:

  • LCTOOLS standalone package comes with the LCTOOLS files, LocStudio files, PLP, and LocStudio parsers
  • LCTOOLS LocStudio package comes with the LCTOOLS files, PLP, and LocStudio extensions
  • LCTOOLS LocStudio extension package comes with PLP (except for plputil.dll), LocStudio extensions, and lctools.chm

LCTOOLS:

  • htmlfont.exe: mapping table utility for HTML font names
  • lcadmin.exe: UI commenting utility to create/maintain lc-files
  • lcbuild.exe: Utility to build pseudo files from LCTOOLS token files
  • lccmd.exe: command line pseudo build and tokenize utility
  • lcdef.cmd: setup configuration file
  • lcdef.reg: setup configuration file
  • lcman.dll: LCTOOLS libraries
  • lcscan.exe: utility to scan lc-files
  • lctools.chm: lctools help file
  • lctools.ini: setup configuration file
  • maploc.exe: mapping table localization utility
  • mapmerge.exe: mapping table utility

LocStudio extensions:

  • lcimport.dll: LocStudio extension to import/export lc-files
  • lvmap.dll: custom DLL for LocStudio extension LocVer
  • PLExtension.dll: LocStudio pseudo extension

PLP:

  • plp.dll: PLP libraries
  • plputil.dll: PLP libraries
  • plconfig.exe: PLP configuration tool

LocStudio files:

  • crunch.dll: WIN32 auxiliary resource remover DLL
  • esputil.dll: Espresso utility DLL
  • locutil.dll: LocStudio utility DLL
  • loomconfig.chm: Loom config utility help file
  • loomconfig.exe: Loom config utility
  • LSOM.dll: LocStudio object model
  • mitdiff.dll: word breaking engine of LocStudio
  • mitutil.dll: internal tools utility DLL
  • parseman.dll: parser manager
  • parsutil.dll: parser utility DLL

LocStudio parsers:

  • bltparse.dll: BLT template files
  • basictmpls.mac: Macintosh template files
  • dos7pars.dll: DOS 7 files
  • heat42s.dll: HTML, win32 sub parser
  • infparse.dll: INF-files
  • iniparse.dll: INI-files
  • ldfparse.dll: LDF-files
  • loom.dll: HTML parser engine
  • locxml.dll: xml parser
  • locxml.dtd: xml parser configuration
  • locxml.xml: xml parser configuration
  • mac.dll: macintosh-files
  • macheat.dll: Macintosh HTML parser
  • macheats.dll: Macintosh HTML sub parser
  • macO96.dll: Macintosh Office sub parser
  • macsdm.dll: Macintosh SDM sub parser
  • mactok.dll: macintosh token files
  • msgparse.dll: message files
  • msiparse.dll: MSI-files
  • msiparse.ini: MSI parser configuration
  • netparse.dll: Network files
  • pomhtml: HTML parser
  • POMParser.dll: POM parser
  • POMXML.dll: XML parser
  • ppdparse.dll: Postscript files
  • riffpars.dll: RIFF-files
  • rplboot.dll: RPL boot files
  • scanpars.dll: scandisk files
  • sqlparse.dll: SQL parser
  • srgparse.dll: SRG-files
  • tokparse.dll: windows token files
  • vxdparse.dll: VXD-files
  • win16.dll: win16 files
  • win32.dll: win32 files
  • win32o96.dll: office win32 sub parser
  • win32sdm.dll: SDM win32 sub parser
  • winboot.dll: winboot files


Creating a Pseudo Localized build

[헭헭亐乂侢Ｐśěｕｄθ ļồсạｌίｚāｔіőη šểｔｔīňğｓ !!! !!! !!! ]:

There are a number of settings you need to decide on when creating pseudo localized builds. The settings you choose depend on what localization scenario you want to simulate and depends on the project characteristics. Below we shortly discuss a number of pseudo localization settings in LCTOOLS:

  • Replacement table
  • Replacement methods
  • Dialog stretching
  • String extension
  • Mirroring and dialog font replacement

Replacement table:

LCTOOLS uses a number of replacement tables. The choice of replacement table depends on the language coverage needed (what languages do you release the product into), the coverage required of the build (e.g. do you want to catch Unicode enabling issues), and project characteristics (e.g. are multiple builds using different pseudo languages feasible, do you change pseudo language for each build level, etc) The following are replacement tables available:

  • ANSI Codepages: All characters used for replacement are part of the ANSI codepage, which means that when the pseudo localized strings are displayed using the ANSI codepage, all characters will be displayed correctly.
  • OEM codepages: All characters used for replacement are part of the OEM codepage, which means that when the pseudo localized strings are displayed using the OEM codepage, all characters will be displayed correctly. Note that the strings used by LocStudio are still based on Unicode and that the conversion is done by either the file parser or by code (eg resources of Windows WIN32 command line utilities are Unicode based, the conversion to the console codepage is done by code)
  • Macintosh codepages: All characters used for replacement are part of a Macintosh codepage, which means that when strings are displayed using the Macintosh codepage, all characters will be displayed correctly.
  • Non-Windows codepages:
    • Unicode/Unicode2: Both tables contain characters from a range of Windows and non-Windows codepages. The use of these tables depend on availability of glyphs on the system. The Unicode2 table contains mainly characters displayed by both system fonts, Unicode contains the double byte ASCII characters part of all FE codepages. The Unicode random table contains all random character tables of the 4 Far East ANSI code pages, the unicode2 random table contains the same characters as the matching replacement table.
    • DBCS: The matching replacement table contains regular ASCII and double byte ASCII characters. The random table contains only double byte ASCII characters.
    • 1255/1256/874: The Hebrew, Arabic, and Thai matching replacement table contains characters that sound similar as the characters they replace. Native speakers who read the strings out loud will be able to recognize the US stings.
    • ASCII: The random table contains all ASCII characters, the matching table is empty.
    • Hindi: The random table contains a number of Hindi characters, the matching table is empty.

You can display a list with available replacement tables with "lccmd -l"

You can review the tables by using the below links:

1250_matching.txt 1250_random.txt Central European ANSI codepage
1251_matching.txt 1251_random.txt Cyrillic ANSI codepage
1252_matching.txt 1252_random.txt West European ANSI codepage
1253_matching.txt 1253_random.txt Greek ANSI codepage
1254_matching.txt 1254_random.txt Turkish ANSI codepage
1255_matching.txt 1255_random.txt Hebrew ANSI codepage
1256_matching.txt 1256_random.txt Arabic ANSI codepage
1257_matching.txt 1257_random.txt Baltic ANSI codepage
1258_matching.txt 1258_random.txt Vietnamese ANSI codepage

10000_matching.txt 10000_random.txt Roman macintosh codepage
10006_matching.txt 10006_random.txt Greek macintosh codepage
10007_matching.txt 10007_random.txt Cyrillic macintosh codepage
10029_matching.txt 10029_random.txt Central European macintosh codepage
10081_matching.txt 10081_random.txt Turkish macintosh codepage

437_matching.txt 437_random.txt Latin US DOS codepage
737_matching.txt 737_random.txt Greek DOS codepage
775_matching.txt 775_random.txt Baltic DOS codepage
850_matching.txt 850_random.txt Latin1 DOS codepage
852_matching.txt 852_random.txt Latin2 DOS codepage
857_matching.txt 857_random.txt Turkish DOS codepage
866_matching.txt 866_random.txt Cyrillic DOS codepage

874_matching.txt 874_random.txt Thai ANSI codepage
932_matching.txt 932_random.txt Japanese ANSI codepage
936_matching.txt 936_random.txt Chinese simplified ANSI codepage
949_matching.txt 949_random.txt Korean ANSI codepage
950_matching.txt 950_random.txt Chinese traditional ANSI codepage

ascii_matching.txt ascii_random.txt ASCII characters
dbcs_matching.txt dbcs_random.txt DBCS ASCII characters
hindi_matching.txt hindi_random.txt Hindi characters
unicode_matching.txt unicode_random.txt Unicode character table
unicode2_matching.txt unicode2_random.txt Unicode character table (excluding DBCS chars)

Replacement methods:

LCTOOLS can use 4 different replacement methods. The choice depends on the language coverage needed and if the UI needs to be readable or not. Some languages do not use characters that look like Latin characters and hence no readable replacement of characters is possible.

For matching replacement, a character gets replaced with a random similar looking character (if available). For random replacement or for prepending of characters, random characters get picked randomly from the characters available in the table. A last replacement method is a combo replacement where both random characters get prepended as well as characters get replaced with matching characters.

You can display a list with available replacement methods with "lccmd -k"

Dialog stretching:

For most pseudo builds, strings are made longer to test for buffer overflow. To keep a build readable, more space needs to be available for display. For this, horizontal (and vertical) dialog stretching has been implemented. The dialog is stretched like a piece of elastic, it is x% wider (and/or higher), each dialog element is x% wider (and/or higher), and each dialog element is positioned x% more to the right (and/or below). The below dialog is stretched 50% horizontally (the default in LCTOOLS).

You can change the rate of horizontal/vertical dialog stretching by creating a PLP Configuration file. This is done with PLConfig. For more information, see PLP configuration utility PLConfig.

String extension:

One of the most used features in pseudo localization is extending string length. In LCTOOLS, this can be done by specifying the following different settings:

  • Choosing delimiters. You can choose starting and ending delimiter (by default "[" and "]")
  • Choosing relative and absolute string extension (by default 40% and 2 characters)
  • Choosing extension string, this string is repeated until the calculated length is reached (by default the extension string is " !!!")

Mirroring and dialog font replacement:

LCTOOLS comes with a number of features to simulate special localization scenarios, two of which are described below. The first is mirroring. In a mirrored build the direction of a build and all its elements changes from left-to-right to right-to-left. This technique is used by our BIDI languages Arabic and Hebrew. For more information, see pseudo mirroring. Another feature is dialog font and size replacement. This localization process is used by our FE-languages. Samples of dialogs produced by both features can be found below.


Creating a Mirrored build

[Psέΰdσ Mιrrσrίηg !!! !!!]:

  • Introduction to pseudo mirroring
  • More detailed information on mirroring
  • How to create pseudo mirrored binaries

Introduction to pseudo mirroring:

Pseudo mirroring is the process of changing the direction of the displayed items. BIDI-languages (Hebrew and Arabic) use a right-to-left direction instead of a left-to-right direction most other languages use. The target of the mirroring process is to change the direction of the displayed language.

An example of a mirrored Window:

You can choose if you want to combine pseudo localization and pseudo mirroring in one build or if you want to create special mirrored builds only without changing anything else.

More detailed information on mirroring:

For Right-To-Left (RTL) languages (Arabic and Hebrew currently are the only supported RTL languages), not only does the text alignment and text reading order go from right to left, but also the UI element layout should follow this natural direction of going from right to left. This layout change only applies to localized RTL languages. There are two technologies used by products to achieve this change of direction, flipping and mirroring. Flipping means that all UI elements have all properties like direction and position changed, mirroring means that this process is mainly done by the operating system using a number of flags.

What mirroring does is automatically flip the UI element horizontally over the Y axis. Rather then having the (0,0) X\Y coordinates on the top left portion of your window, we now have it on the top right instead. The X axis increments from right to left and the Y axis increments the same as before from top to bottom.

In order to support this technology, applications developed at Microsoft need to be mirroring aware. Mirroring technology can be either implemented in code by setting the correct flags/API's. Additionally any well written application should still be easily mirrored through resource localizations. Lctools mirrors compiled binaries through resource localization. For example, mirroring a dialog does require that the calling executable process be stamped with the correct mirroring flags. To do so from the resources, a localizer needs to add the 2 LTR (Left to Right markers Alt+0253) markers in front of the File Description resource in the version resource section of the affected binary (most exe's, cpl's..etc..). On the other hand all win32 dialogs have their own properties and they need to be mirrored individually. This can be easily implemented by turning on the WS_ES_LAYOUT_RTL flag. To do so, the localizer needs to explicitly check the RTL Layout flag in the more extended style resource for every dialog resource as follows:

The No layout inheritance flag is set in case some limitations arise where mirroring the children control on the specific dialog is not desirable. Lctools does not have an option that would allow you to turn on or off this feature. From LCTOOLS point of view this is either a code issue or a localization preference.

For detailed descriptions regarding Mirroring technology and definitions, please refer to mirroring awareness .

How to create pseudo mirrored binaries:

Pseudo mirrored binaries can only be created through the pseudo build tool LCCmd. Pseudo localization is also available through a LocStudio extension, but this does not support mirroring. To create pseudo mirrored binaries in LCCmd, use the option -b. For more information on this utility, please refer to lccmd.exe page.

Lctools, behaves in the same way as real BIDI localization does. We support mirroring of HTML files and WIN32 binaries.

HTML:

When you pseudo localize an HTML file or a Binary using Lccmd.exe with output language Arabic or Hebrew, the parser automatically adds to any HTML file or to any embedded HTML resource DIR=RTL to all HTML tags. These tags are needed to change the direction of the file. There is no need to set the -b switch to get mirrored HTML files. Setting the output language to either Arabic or Hebrew is simply enough.

WIN32:

The following is happening when mirroring a Win32 binary using Lccmd.exe with the -b switch.

  • using: lccmd -b Yes, prepends 2 Unicode LTR markers in front of the file description version resource string. The OS underlying code, looks for these markers when the CS language support is installed on the machine, and if such markers do exist, the Window will become mirrored when the binary is invoked. In addition to the 2 Unicode LTR markers, all dialog properties are stamped with the WS_EX_LAYOUTRTL flag. With these two operations, all dialogs become mirrored.
  • using: lccmd -b No, does not prepend the 2 Unicode LTR markers in front of the file description version resource string, but it only mirrors the dialogs as described above.

MessageBoxes:

Additionally, you can mirror any MessageBox by simply adding the 2 RTL markers in front of any MessageBox string resource. You can do so by adding the {RTL} instruction to the resource in question. Please refer to Lcadmin.exe documentation to learn how this is done.


New Page 1

[HŢMŁ pşéµďô ľöčąłížâţíóń !!! !!! !!!]:

HTML localization is quite complex. Without any special features, pseudo localization of HTML would be nearly impossible. LCTOOLS has a number of built-in features that make pseudo localizing HTML fairly straightforward.

HTML (and other script formats) gets parsed by the parsing engine called loom (loom.dll). Loom can be configured and told what strings to extract, what properties and string categories to assign to them, etc. Loom requires many items of a file to have assigned identifiers, so it can recognize the items and extract them for localization. For more information on creating localizable HTML, see \\cptoolzone\toolbox\locstudio\docs\html\authoring HTML for localization.doc

  • String categorization
  • HTML elements in non-HTML files
  • Font handling
  • Mirroring of HTML files

String categorization:

The difficulty with HTML pseudo localization is that many strings extracted by the file parser should only get localized in certain cases and to certain fixed values. Items like font name, HTML property, or style, can definitely not be localized in the same random fashion as is done for regular strings. In terms of localizability instructions, you would have to mark all these items as "adaptation" to make sure that they are localizable in certain situations, but not localized randomly.

LCTOOLS bases its pseudo localization on resource types. You can configure the way each resource type gets pseudo localized in PLP. Two of these resource types are "HTML" and "Other". Strings with resource type "HTML" get localized in an appropriate way for HTML, tags and special characters don't get localized. HTML strings marked as type "Other" don't get pseudo localized at all.

HTML string before pseudo localization: <H4 id=Hello ><font color="#FF0000">Hello World</font></H4>
HTML string after pseudo localization: <H4 id=Hello >[<font color="#FF0000">Hêllö Wòrlð</font> !!! !!! !!! !!! !]</H4>

The HTML parsing engine LOOM assigns string categories to all items, LCTOOLS maps these string categories to the resources types "HTML" and "Other" through a mapping table specified in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\LCTools\HTMLResMap, meaning that for items parsed by LOOM, items are determined localizable or non-localizable by this mapping in the registry in combination with the LOOM configuration.

HTML elements in non-HTML files:

In some cases, you can find HTML strings in other files than parsed by one of the HTML parsers. These strings are not mapped to the resource types "HTML" or "Other" and the HTML-syntax is pseudo localized. You will need to set placeholders in LCTOOLS for tags and special characters to make sure that these strings get correctly pseudo localized.

Font handling:

Some HTML strings are font names or font sizes which need (pseudo) localization. In most cases you can determine if a string is either a font name or font size by looking at the resource identifier assigned to the item by the LOOM parser. If certain values are substrings of the identifier, the item is determined a font name or font size. In these cases, items are automatically treated as an item with a Adaptation flag and possible translations are looked up in the mapping table. If a translation is not found in the mapping table, the item is left unlocalized. The strings used to determine if a item is a font name or font size are specified in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\LCTools\AdaptationRule. The default values are written in the registry by the registration of LCTOOLS and can be easily modified by adding them to lcdef.reg.

Mirroring of HTML files:

For BIDI languages (Arabic and Hebrew), LCTOOLS adds "DIR=RTL" to all HTML tags. This is consistent with LocStudio behavior dealing with BIDI target binaries.


New Page 1

[詰댛댛뭕흝Mapping table process !!! !!! !]:

  • Introduction to map-instructions
  • Adaptation-instructions and the mapping table process
  • Mapping table
  • Map.inf
  • Mapping table process

Introduction to map-instructions:

One category of localizability bugs found is when strings need to be localized consistently to ensure correct functionality, but are not. Examples of strings that require such consistency are folder names and account names. LCTOOLS supports using such consistencies (or dependencies as they are also called) by the use of map-instructions and the use of a mapping table. Strings or substrings marked with a map-instruction will be looked up in this mapping table.

Map-instruction look as follows:

{Map="string"} or {Map="string",Property}

A map-instruction can be defined for the whole string, or for a substring. One string can contain multiple map-instructions. As there might be multiple translations required for a certain string that is mapped, you can add a property for a map-instruction to look up the correct translation. Examples of the need of multiple translations are folder names that have different translations in different versions of the OS, or a string that is used both as account name and as folder name.

Adaptation-instructions and the mapping table process:

The mapping table can also be used for the localization of adaptation-instructions. Adaptation-instructions are used for strings that are not randomly localizable, but that need to be translated to certain values, used to adapt the software. Examples of these are font names or sizes, LCIDs, spell checkers, numeric info, etc.

Adaptation instructions look like:

{Adaptation} or {Adaptation,Property}

If a string is marked with an adaptation-instruction, the whole string (with the property if that one is present) is looked up in the mapping table.

Font name and size information in HTML files is recognized by LCTools based on the resource identifiers assigned by the parser and the values specified in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\LCTools\AdaptationRule. If the identifier contains any of the strings specified in this registry location, it is interpreted as font name or size and is automatically treated as a string with an adaptation instruction.

For more information on this process, see also HTMLFont.exe utility

Mapping table:

A mapping table is a comma separated file in Unicode format containing the following information:

source string, target string, property, comment

The lookup of strings in the mapping table is case-insensitive

Map.inf:

To provide an automated way to localize mapping tables and to provide an interface of mapping tables for localization, we defined a map.inf file that is a partial translation of the mapping table. Each entry in map.inf looks as follows:

Identifier = "string" ; Property & Comment

The identifier is the MD5 checksum created of the US string and property, the property is not displayed in map.inf.

Mapping table process:

The below is a graphical representation of the mapping table process:

1) The creation of the mapping table with LCScan:

All map-instructions are recorded in lc-files. By using LCScan.exe, you can create a mapping table containing all map-instructions from all lc-files. The resulting mapping table has both source and target strings in English. Additionally LCScan.exe can create an adaptation table (Adapt.txt as illustrated above).

For more information on LCScan, see LC scan utility LCScan

2) HtmlFont.exe is a utility that searches the Unicode token files created by lctools for font names and font sizes. These font names and sizes are recognized when the identifier of the string contains certain substrings defined in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\LCTools\AdaptationRule. This utility is especially used to find dialog names and sizes in HTML strings.

3) Mapmerge.exe is a utility that merges all the different created mapping, adaptation and HtmlFont tables into a full mapping table which covers all the different mapping rules available to PLP.

4) Translation of the mapping table with MapLoc and LocStudio:

As the mapping table is not in a very suitable format to be localized and maintained, you can transform the mapping table in an INF file with MapLoc.exe. This INF file can be localized very easily with LocStudio. By maintaining a LocStudio EDB with this map.inf, you can do easy updating and change tracking of map.inf too. Once you have generated a localized version of map.inf, you can use MapLoc.exe to add the translated strings back into the mapping table.

For more information on MapLoc, see Mapping table utility MapLoc

5) Map.inf localization:

To verify map-instructions in localized builds, the file map.inf is handed off to localization and translated according to the comments provided. The localized map.inf is then generated and used for the verification of map-instructions in localized builds through LocVer (localization verification).

For more information on Localization verification, see Localization verification


lcAdmin web

[لسي آدمنCommenting tool LCAdmin !!! ]:

LCAdmin is a simple to use UI utility that allows the owner of a compiled binary or the Localizability PM to edit certain predefined attributes for the resources parsed by the LocStudio parser model. Basically, LCAdmin is a UI commenting tool that allows a developer or the Localizability PM to enter and maintain comments and instructions based on a predefined set of rules. For example: a user can define whether a certain string should not be localizable, what strings represent folder names, etc. LCAdmin is also a great tool for you to see what resources are extracted for localization and if a file is in a localizable format.

In addition to the above, LCAdmin has many options that can help you generate pseudo localized binaries using your customized settings. To learn more about LCAdmin, please check out the following links:

  • LCAdmin UI
  • Purpose of commenting
  • The different localizability instructions
  • How to use LCAdmin
  • Advanced options

LCAdmin UI:

Running LCAdmin provides you with the below UI. The most important elements can be accessed through the tool bar elements:

The left top window provides you with a tree view of the file you opened. You can open branches of the tree structure and open resources of a certain branch by right clicking and choosing "Show All Resources". Only string resources will be displayed. The displayed strings will be displayed in the right top window. The bottom window will display messages provided by the parser manager. These can either be status messages, but can also be warning or error messages. It is useful to read these messages when you open or generate files. You can select multiple resources in the right top window and apply a number of instructions in batch mode through the right click menu.

The property dialog (double click on a string, right click on a string and choose "properties", or select a string and goto "Edit"/"Properties") will enable you to enter instructions and comments for one string resource (limited default properties can be applied through the main UI as described above):

LcAdmin custom Open File Dialog

Purpose of commenting:

In the past the localization team would take a US compiled binary and get it fully localized. Once it is fully localized, functional bugs (like G.P. Faults) started to appear and lots of troubleshooting time was spend on fixing the issues. This is a costly route and not the most efficient way to get localized builds released with the shortest delta possible. It would also mean having to make changes in US code late in the project cycle or having to include hotfixes. The LCAdmin utility provides developers with an easy way to document what strings can be localized and how they can be localized. LCAdmin generates an lc (localization Info) file that contains all the required info to prevent localizers to create bugs when localizing the product. This information gets propagated to the localizers desktop and enforced in the localized builds. The file will also be used to create pseudo localized builds, testing the correctness of the information.

The different localizability instructions:

  • Locked instruction: {Locked}
    • This feature is used when a string can not be translated. Think of registry keys, API names, file names, etc.
  • Placeholder instruction: {PlaceHolder="substring"}
    • A placeholder is used when a part of a string is not localizable. An example is the wildcards used in "All files (*.*)|*.*||"
    • Some placeholder are set by default through PLP. You can configure PLP for the rules to use using PLConfig. The rules used by default:
      • Don't localize words containing the characters '%', '$', '_', '@', '[', or ']'
      • Don't localize the following substrings "\NULL", "\n", "\t"
    • You can remove a placeholder by selecting it in LCAdmin and clearing it. The default behavior will now be turned off and an instruction {NoRules} will be added automatically.
  • Maxlength instruction: {MaxLength=x}
    • Used when there is limitation on the size of the string.
  • Map instruction: {Map="string",Property} + comment
    • This instruction is used for strings that need to be localized consistent throughout the product. Think of account names and folder names, which are localized for several languages
    • The translation for a mapped string is looked up in a mapping table, specified through LCCmd
    • The property is used when multiple strings have string dependencies, but not necessarily to each other. By specifying a property, the tool can distinguish the cases and look up the correct translation. For example, "System" can both be an account name and a folder name.
    • When a map instruction is set, no string extension or delimiters will be used
    • When entering a map instruction, you will be asked to enter a comment
    • For more information, see Mapping table process
  • Adaptation instruction: {Adaptation,Property} + comment
    • An adaptation instruction is specified when a string is used for the adaptation of a product. Think of font names, font sizes, URLs, numeric info like LCID, codepage information, or just a value that is used to turn on/off a feature. These strings need to be localizable and need to be localized by some languages following certain rules, but cannot be localized randomly
    • The property is used when multiple strings are used for adaptation, but not necessarily have to be translated the same. By specifying a property, the tool can distinguish the cases and look up the correct translation.
    • When entering an adaptation instruction, you will be asked to enter a comment
    • For more information, see Mapping table process

Beside the above instructions, we have the following semi-instructions that are used for pseudo loc or commenting only:

  • NoRules: {NoRules}
    • When you change the default placeholders set by the tool, an instruction NoRules will be used to remember not to use this default behavior.
  • NoDelim: {NoDelim}
    • When you don't want any characters to be prepended or appended to a string, you can specify a NoDelim instruction.
  • Comment: "Regular text"
    • Comments are extremely useful for localization. Note that comments added to source code mostly are not saved in the compiled binaries. Localization tools extract strings from the compiled binaries and hence these comments are not seen by the localizers. LCTOOLS enables a global commenting model.
  • RTL MessageBox marker: {RTL}
    • For Arabic and Hebrew, you have the option to add the 2 RTL markers to any MessageBox text by simply adding the {RTL} rule. LcAdmin gives you the choice to either type {RTL} manually in the comments field or to simply click on the provided UI {RTL} button.

How to use LCAdmin:

You open a binary in LCAdmin and load the lc-file (localization instruction file) if available:

  • Open the binary by typing "LCAdmin filename.exe" or "LCAdmin filename.exe filename.exe.lc"
  • Launch LCAdmin, open binary first and then load the lc-file

You edit the comments and instructions:

  • Lock flags, default rules and no rules can be set/removed through the main UI. You could do multiple selection with the right click functionality enabled.
    • You need to be very careful using the norule functionality with the Multiple selection.
  • Other instructions and comments can be set through the property dialog
  • All instructions can be seen in the main UI
  • Exclamation marks indicate that a string contains a comment or instruction
  • Strings with comments or instructions that are changed since the last time the file was opened will be indicated by a red bar

You save the lc-file:

  • If a file does not contain any instructions, no lc-file will be created

Other things to know:

  • Right-clicking a node in the resource tree can open all resources below that node
  • You can view options (edit menu) to set default folders, formatting options, etc
  • You can also generate a pseudo binary from the file menu
  • You can register the tool from the file menu, however the tool will register automatically upon launching.
  • To see a sample of an lc-file, see lc (localization Info)

Advanced LCAdmin options:

In order to make LcAdmin more user friendly, few extra UI and user customization settings are also available:

Pseudo Binary Generation:

You can generate your own Pseudo Localized Binary using LcAdmin without having to learn much about Lccmd.exe and its rich features. To generate your own private binary using LcAdmin, you have to do the following:

Go to the Edit\Options dialog and set your Generation preferences as follows:

  • Default target folder option sets the default location where your Pseudo Localized binary would end up.

  • Default target language helps you set the correct target language to best fit your pseudo localization needs.

  • The Replacement method helps you select one of the following:

    • Matching: Specifies whether you want to choose similar looking replacement characters methods as follows: Thé špê¢îƒìêð vªlüë ƒör Çòñvêñtîøñãl Mëmórÿ ïš îñválîð.

    • Random: Character replacement is done randomly.

    • Prepend: Sets Whether to keep the translated string in English prepended with some randomly Pseudo localized characters.

    • None: All characters remain in English.

Get Prompted always to load lc file:

You can customize your user settings to get prompted to load lc from the lc default location every time you try to load a binary. To enable this functionality, you need to do the following:

Go to the Edit\Options dialog and set your Generation preferences as follows:

Set your own UI formatting preferences:

You can also customize your own UI formatting options. To do so you need to do the following:

Go to the Edit\Options dialog and set your Generation preferences as follows:

Set your default Source/lc folder location:

You can set your default folder location for your source binary and lc loc info folder location. To enable this functionality, you need to do the following:

Go to the Edit\Options dialog and set your Generation preferences as follows:


LCCMD

[קתצתמPseudo build tool LCCmd !!!]:

LCCmd is the command line build tool for the creation of pseudo localized files. LCCmd takes a compiled US binary as input and generates a pseudo localized file as output. An instruction file created by LCAdmin can be specified as additional input, ensuring that the generated pseudo strings will follow the instructions specified before. You can pseudo localize using different code pages using matching or replacement table technology. In addition, LCCmd has a very useful tokenization feature. You can extract all text resources from a compiled binary of any language and save these in a Unicode text file. These token files provide you with a basis for change tracking and troubleshooting.

To learn more about LCAdmin please check out the following links:

  • Pseudo build option
  • Tokenization option
  • Verification option
  • Miscellaneous options
  • Advanced information

Pseudo build option:

The most important feature of LCCMD is the build feature. For this the following syntax is used:

LCCMD [OPTIONS] -g InputFile [OutputFile]
  -g                     Generate pseudo localized binaries
     InputFile           Input File
     OutputFile          Output File

OPTIONS:
  -i {PID SID}|LangID    Input language, Primary- and Sub-Lang IDs, dec/hex
  -o {PID SID}|LangID    Output language, Primary- and Sub-Lang IDs, dec/hex
  -a RuleFile            LC-file containing constraints
  -l ReplacementTable    Replacement table used for pseudo localization
  -k ReplacementMethod   Replacement method used for pseudo localization
  -m MappingTable        Mapping table
  -b Yes|No              File needs to be mirrored. Yes|No specifies if 2 LTR
                         markers need to be added to the file description
  -x CFG                 PLP XML configuration file
  -s POpt                Parser options name
  -e ParserID            Parser ID
  -n ReportFile          Generate reports from parsers
  -w                     Display the status of the operation

The following samples highlight the working of this feature. The other switches not highlighted are only used in special cases and will be further explained in a page to come.

lccmd -w -i 0x0409 -o 0x0411 -l 932 -k matching -a notepad.exe.lc -g notepad.exe

  • All US string resources (LCID 0x0409) will be pseudo localized and stamped as Japanese (LCID 0x0411)
  • The file will be pseudo localized in Japanese (codepage 932) using matching replacement. Matching means that every character is replaced with a similar looking character, specified in the replacement table. To get a full overview of available replacement tables and replacement methods, type "LCCMD -l" and "LCCMD -k"
  • Localization info file notepad.exe.lc is used as input. All pseudo localized strings generated will follow the instructions specified in this information file. If the file specified is not available, the file will be pseudo localized without information file.
  • notepad.exe will be overwritten by the pseudo localized file as no separate output file is specified.
  • The status of settings will b e displayed as part of the operation

lccmd -i 0x0409 -o 0x0407 -l unicode -k random -m map.txt -a notepad.exe.lc -g notepad.exe notepad1.exe

  • All US string resources (LCID 0x0409) will be pseudo localized and stamped as German (LCID 0x0407)
  • The file will be pseudo localized using a Unicode replacement table. This table contains a wide range of Unicode characters, not limited to one ANSI codepage. Using this table, we can find bugs in files that are not Unicode enabled. The characters will be picked by random, so the text won't be readable anymore
  • A mapping table map.txt is used as a lookup table for strings that are marked up with map-instructions. By adding map-instructions to multiple instances of a string and by adding this string plus translation to the mapping table, these strings will be replaced by the translation in the mapping table, ensuring consistent translation. This is needed for things like folder names, account names, etc
  • Localization info file notepad.exe.lc is used as input. All pseudo localized strings generated will follow the instructions specified in this information file. If the file specified is not available, the file will be pseudo localized without information file.
  • A new file notepad1.exe will be created and notepad.exe will stay unchanged.

lccmd -i 0x0409 -o 0x0411 -n log.txt -l unicode -k combo -a notepad.exe.lc -b Yes -g notepad.exe notepad2.exe

  • All US string resources (LCID 0x0409) will be pseudo localized and stamped as Japanese (LCID 0x0411)
  • The file will be pseudo localized using a Unicode replacement table. The -k combo applies the combination of both matching and prepend technologies. This option allows the ability to both use FE prepended characters with matching DBCS characters for the US string. If a {NoDelim} instruction is used, the localized resource will not be prepended with FE characters, but still pseudo localized using the Matching technology.
  • In this example, Notepad1.exe will also be mirrored. The -b Yes option specifies that the binary is to be mirrored with the 2 LTR markers added to the file description version resource.
  • Localization info file notepad.exe.lc is used as input. All pseudo localized strings generated will follow the instructions specified in this information file. If the file specified is not available, the file will be pseudo localized without information file.
  • A new file mirrored with prepended/matching pseudo localized resources notepad2.exe will be created and notepad.exe will stay unchanged.
  • A log file log.txt will be created with any message generated by the file parsers used

One useful feature for build needs to be highlighted and this is the use of system variables. You can set a number of input variables globally instead of having to specify these for each call of LCCMD. The following are the system variables available.

InputLanguage        (-i option)
OutputLanguage       (-o option)
PLPConfigFile        (-x option)
ReplacementTable     (-l option)
ReplacementMethod    (-k option)
MappingTable         (-m option)

You can see the current used system variables, by typing "lccmd -v"

Tokenization option:

A useful feature of LCCmd is the creation of token files. The string resources extracted by the LocStudio parsers will be saved in a Unicode text file. This token file can be used for trouble shooting, glossary generation, and possibly be linked into test automation. You can create token files in different formats (some are more resource dumps), with the option 1 used most frequent.

LCCMD [OPTIONS] -t InputFile [OutputTokenFile]
-t Extract token to output file
OutputTokenFile Output token file. By default, InputFile.tok
There are alternative tokenization options -t0 till -t4

OPTIONS:
  -i {PID SID}|LangID    Input language, Primary- and Sub-Lang IDs, dec/hex
  -o {PID SID}|LangID    Output language, Primary- and Sub-Lang IDs, dec/hex
  -a RuleFile            LC-file containing constraints
  -l ReplacementTable    Replacement table used for pseudo localization
  -k ReplacementMethod   Replacement method used for pseudo localization
  -m MappingTable        Mapping table
  -b Yes|No              File needs to be mirrored. Yes|No specifies if 2 LTR
                         markers need to be added to the file description
  -x CFG                 PLP XML configuration file
  -s POpt                Parser options name
  -e ParserID            Parser ID
  -n ReportFile          Generate reports from parsers
  -w                     Display the status of the operation

lccmd -t notepad.exe notepad.exe.tok

  • This option will create a Unicode token file of notepad.exe with each line containing a identifier created by LCTOOLS (very similar to the identifier in LocStudio) and the string itself.
  • There are 4 different dump options used with the -t tokenization switch. The default option is 1. This will generate a UNICODE token output file. The other tokenization options are design for internal lctools debugging purposes.
  • The switches available to the tokenization option are the same as available to the pseudo option, however only a few (-i, -s, -e) have any meaning for this operation

Verification option:

Lccmd can check if the information in an lc-file still matches the binary it has been created for. It can very easily happen that a binary has changed resources and the lc-file is not updated to match these changes. This option will report redundant items in an lc-file and changed items (the checksum is used for this verification)

LCCMD [-i {PID SID}|LangID] [-d LogFile] -c RuleFile InputFile
  -i  {PID SID}|LangID   Input language, Primary- and Sub-Lang IDs, dec/hex
  -d  LogFile            Log file containing differences
  -c                     Check consistency between Rule file and Input file
      RuleFile           LC-file whose content needs to be validated
      InputFile          File against which the LC-file needs to be validated

Miscellaneous options:

Registration of tools: This option will register all file parsers in the LCTOOLS folder, register the two LocStudio extensions lcgen.dll and converter.dll, and register the information in the regfile. If no regfile is specified, the information in lcdef.reg will be registered. When LocStudio is installed, default registration will not re-register the file parsers, if this is required, you can do so by using the "-f-option".

LCCMD -r [-f] [regfile]
-r regfile Register all parsers into system
-f Force to register parser options

Help screens:

LCCMD [-h|?]
  -h|?                   Display help message

Display of available replacement tables, replacement options, or applicable system variables set

LCCMD [-l] [-k] [-v]
  -l                     Display the list of replacement tables
  -k                     Display the list of replacement methods
  -v                     Display the list of system variables

Advanced information:

There are a few options that are less frequently used than the others

-x option:

When you use a different PLP-configuration file, you need to specify the option "-x PLPConfigFile"

-s option:

When your project requires the use of different parser settings for different sets of file, you will need to add different parser setting to the registry. Without the use of the -s option, the settings are retrieved from "HKCU\Software\Microsoft\LocStudio 4.51\Parser Options". You can add multiple keys "HKCU\Software\Microsoft\LocStudio 4.51\<Parser Options>" next to this key with the parser settings requested. You can force LCCmd to use alternative parser options by specifying "-s <Parser Option>"

Also see Parsers and parser settings

-e option:

The LocStudio parser model uses extension lists in the registry to associate a parser with a file. This association does not always work, sometimes a file has a non-regular file extension, and sometimes a file extension is used for different file formats and LocStudio cannot correctly associate the file parser. In these cases, you can force the use of a certain parser by specifying the parser ID. You can find the parser ID by looking in the registry (HKLM\SOFTWARE\Microsoft\LocStudio 4.51\Parsers)

Also see Parsers and parser settings

The use of variables:

Input variables for LCCmd can be specified in 3 different ways. The following are in the sequence of priority:

  • Input provided at the command line. For options available, type "lccmd" at the command prompt.
  • System variables. For variables available and if they are specified, type "lccmd -v" at the command prompt.
  • Variables specified in the PLP-configuration file. To use this configuration file, the option -x needs to be specified.
  • (Built-in settings in LCTOOLS)


[ÚáÔå§£óç§tüðìø fûñ¢tìôñälìtÿ !!! !!! !!]:

LocStudio is Microsoft's main localization tool, developed by PTT (Productivity Tools Team). LCTOOLS has been developed to implement a number of new functionalities not available in our localization process and to extend and incorporate these into the LocStudio environment. Also some existing LocStudio components, like PLP (pseudo localization platform) were updated. To find more information on LocStudio, see http://tools/ToolCenter/LocStuToolCtr.asp

LCTOOLS is closely integrated with LocStudio:

  • LCTOOLS is based on the LocStudio parser model.
  • LCTOOLS comes with a updated version of PLP, a tool that releases as part of LocStudio
  • LCTOOLS provides a process that is closely integrated with LocStudio
  • LCTOOLS provides a special LocStudio setup

The functionalities that are closely integrated with LocStudio are available through LocStudio extensions:

  • LC import/export
  • Localization Verification
  • Pseudo localization extension


[อญบศอLC import/export !!! !!!]:

An important aspect of the process around LCTOOLS is the exchange of information between our commenting model and pseudo localization (lc-files) on one side, and localization (LocStudio EDBs) on the other side. Information gathered through the commenting model and verified through pseudo localization, needs to be available to our localization teams. For this purpose, LCTOOLS comes with a LocStudio extension to import and export lc-files. The instructions imported in the EDB need to be enforced and can be checked through the existing LocStudio extension LocVer (Localization Verification). Note that LCTOOLS installs an extension to LocVer to extends its functionality. For more information, see Localization verification).

Installing lc import/export:

The extension lcimport.dll can be installed in two different ways:

  • lcimport.dll is being installed and registered through LCTOOLS LocStudio installation feature
  • Copy lcimport.dll in your LocStudio folder and register it through "lccmd -r"

Using lc import/export:

There are two ways of using extensions in LocStudio:

  • Launch an extension through the LocStudio UI. In the menu "Add-ins" you can find all extensions available. The lc import/export extension adds two entries in this menu, "EDB->LC" (export) and "LC->EDB" (import).
  • Use an extension through the command line utility LSCmd

The import/export extension has some requirements towards the structure of files on the machine when importing lc-files:

  • The lc-files are in a folder LCS in the location of the EDB
  • The lc-files are in the same structure as the files in the EDB
  • The lc-files have the same file names as the files in the EDB with the extension ".lc" appended

The below graph will show the required structure:

c:.
└───project
    │ project.edb
    │
    ├───lcs
    │   │   file1.ext.lc
    │   │   file2.ext.lc
    │   │
    │   └───subfolder
    │           file3.ext.lc
    │
    └───source
        │   file1.ext
        │   file2.ext
        │
        └───subfolder
                file3.ext

When exporting lc-files, the same structure as described above will be created (meaning the location where the EDB is to be found is writable). On import/export operations the following log-files are created:

  • When importing/exporting lc-files, a log file lcimportexport.log will be written in the folder LCS. This log file will contain an overview of all imported/exported lc-files.
  • When importing lc-files in an EDB, a log file <EDBname>_lcimport.log will be written in the same location as the EDB. This log file will contain an overview of all changed instructions.

Import/export functionality:

The lc-information will be written in the instruction field of the EDB between <lc></lc>-tags. This to clearly separate lc-information and non-lc-information in the EDB. This enables lcimport also to update lc-information in the EDB without overwriting or deleting information added by the localizer. All instructions will be written in the EDB in the same format as in the lc-file:

  • Lock-flags will also be written in the instruction field as {Locked}. It is optional to set the UsrSrcLock when a lock flag is imported. This option is turned on by default.
  • Placeholders and map-instructions in the EDB specify the string resources they work on instead of string location as is done in the lc-file. For this reason we cannot always guarantee a round trip conversion.

When exporting lc-file information, only information between <lc></lc>-tags is exported.


[Ĺởсăľίźảτịộп Vėяΐƒîςдтịỗη !!! !!! !!!]:

LocStudio comes with a very important feature LocVer (localization verification) that can verify a certain set of instructions added to the "instructions" column of the EDB. The instruction set supported by LocVer is far more elaborate than what is implemented by LCTOOLS, for more information, please consult the LocStudio help file.

Verification of instructions added and tested through lc-files is key to our localizability process. We will need to make sure that the localized builds follow the same information as our pseudo builds were tested on, minimizing the risk of introducing additional bugs. LocVer comes with this needed functionality.

Using LocVer:

LocVer can be run as any extension, either through the LocStudio UI as well as through LSCmd command line utility. Any special requirements for LocVer to run depends on the instruction set verified. For example, when LocVer dependency rules are used, a dependency database will first need to be created. When LCTOOLS map-instructions are being used, a localized map.inf file will need to be available in the location of the EDB. For more detailed information on configuring and using LocVer, please consult the LocStudio help file.

LocVer and the LCTOOLS instruction set:

LCTOOLS only uses a small part of the instruction set supported by LocVer, below you find an overview of what is supported:

  • Locked instruction: Does not require any support from LocVer as locked strings in a EDB are automatically reverted to the source language
  • Placeholder instruction {PlaceHolder="substring"}: Is supported by LocVer
  • Maxlength instruction {MaxLength=x}: Is supported by LocVer
  • Map instruction {Map="string"} or {Map="string",Property}: Is supported by LocVer through a custom LocVer DLL lvmap.dll released as part of LCTOOLS
  • Adaptation instruction: {Adaptation,Property}: Not supported
  • NoRules {NoRules}: Not supported
  • NoDelim {NoDelim}: Not supported
  • RTL marker {RTL}: Not supported

Mapping table verification:

There are two requirements when verifying map-instructions as used by LCTOOLS:

  • The custom LocVer DLL lvmap.dll needs to be installed. lvmap.dll is installed by default as user setting through the LocStudio installation package, but in all other scenarios, you need to install through:
    • Make sure lvmap.dll is in your LocStudio folder
    • Add an entry lvmap.dll in the project settings (Software/Project Settings) or user settings (Tools/User Settings) for Extensions. Go to the settings for "Localization Verification Extension", select "Custom Rule DLLs" and add lvmap.dll as shown below.

  • A localized version of Map.inf needs to be located in the same location as the EDB

The following will be checked by lvmap.dll

  • If map.inf is available
  • If the string with a map-instruction can be found in map.inf
  • If the translation found in map.inf is part of the target string in the EDB
  • If the translation found in map.inf matches the whole target string in the EDB in case the map-instruction matches the whole source string in the EDB

For more information on the mapping table process, see Mapping table process.


[ΠωόύςPsεΰdσ lθςαlίzατίόη έxτεηsιόή !!! !!! !!! !]:

LCTOOLS releases with PLP 2.0. Many feature enhancements and bug fixes were made in PLP and the LocStudio pseudo localization extension was updated accordingly. Any team currently using the pseudo localization feature in LocStudio is encouraged and recommended to install the updated pseudo localization functionality. LCTOOLS comes with a special PLP-setup that will only update PLP components in LocStudio.

For a reference to the working of the pseudo functionality in LocStudio, please consult the LocStudio help file. Below we list a number of important changes made in PLP 2.0 and the pseudo extension.

  • Most instances of the Instruction Generation have been turned of by default, even if these were turned on in PLP 1.0. The only instructions turned on by default:
    • Format Specifier Rule with characters "%$@_[ ]". Any word that contains any of these characters will not be pseudo localized. In LCAdmin, these words will be seen as default placeholders.
    • Lock Substring Rule with strings "\NULL","\t", and "\n". Any instance of such strings will not be localized. In LCAdmin, these strings will be seen as default placeholders.
    • Minimal length rule with value 1: Any string shorter than 1 character (= empty string) will not get pseudo localized
  • Features for HTML pseudo localization have been added. The values for HTML pseudo localization are configurable through the LocStudio UI for extension settings. For more information, see the following sections:
    • HTML pseudo localization
    • HTML/XML configuration
  • A number of default settings were updated to match a better pseudo localization scenario. Some of these changes are listed below:
    • Absolute string enlargement: 2
    • Relative string enlargement: 40
    • Horizontal dialog stretching: 50 (vertical dialog stretching was added, default is 0)
    • Extension string: " !!!" (adding spaces is important to have extended strings wrap correctly)
  • The list of mapping tables was updated. For a full list of available tables, see replacement tables.
  • A new "combo" replacement method was introduced. With this option you can both prepend a number of random characters using the random replacement table and replace characters of the strings to pseudo localize with characters of the corresponding matching replacement table. The limited replacement method was removed. This method was meant to cover for OEM and Macintosh codepages, separate OEM and Macintosh replacement tables were introduced instead.
  • You can now specify a configuration file created with PLConfig as input of your pseudo extension. The configuration file specifies all settings to be used during pseudo localization. Using this feature, you can automate the generation of multiple pseudo builds with different settings. For more information on PLConfig, see PLP configuration utility PLConfig. There is one limitation of this feature, it will only work for settings applied to string translation, settings used for the pseudo localization of non-string info like dialog sizing and dialog font and size localization are still picked up from the regular settings.
  • The verification part of PLP was not modified. Instead, a custom DLL for LocVer (localization verification) was introduced. The important instructions as defined as part of the localizability process can all be verified using LocVer and this custom extension. For more information on LocVer, see Localization verification.

Pseudo mirroring:

Mirroring as available through the command line build utility LCCmd is not available through the LocStudio pseudo extension. The main reason for this is that the mirroring process sets 2 LTR markers in front of the file description version resource string on a file level. The LocStudio pseudo extension works on an EDB level, making configuration on a file level impossible, something which is required for the pseudo mirroring process.

For more information on pseudo mirroring, see pseudo mirroring.


[FLJzsMiscellaneous utilities !!! !!! !!]:

Several miscellaneous utilities have been developed to enhance the process around LCTOOLS. Information on the utilities included in our LCTOOLS release has been included in this help file. Please consult the WEB-site http://globalsys/pseudoloc to find information on other utilities.

The following utilities have been included in the release:

  • LC-file scan utility LCScan
  • PLP configuration utility PLConfig
  • Mapping table utility MapLoc
  • MapMerge.exe utility
  • HtmlFont.exe utility
  • Build utility LCBuild


New Page 1

[£Ç-fîlé sçâñ µtîlîtý £Ç§¢åñ !!! !!! !!! ]:

LCScan.exe is a command line utility that creates reports of the contents of a set of lc-files. For example, you can list all maxlength instructions for bug follow up, list all lock instructions for project statistics, or create a mapping table containing all map-instructions. LCScan.exe contains also a few modes that you can use to batch change the contents of your lc-files.

LC-file scan utility.

LCSCAN -p|-l|-t|-m|-x|-n|-i|-a|-c|s|-z|-e [-r] FileName
-p returns all placeholders
-l returns all locks
-t returns all Adaptation
-m returns all maps
-x returns all maxlength
-n returns all norules
-i returns all NoDelim
-a returns all instructions (not including strings with comments only)
-c returns all comments
-s lists placeholders and map instructions containing spaces
-e returns the filename if the lc file is empty-r work recursively
FileName is the lc file or subdirectory name

LCSCAN -d|-u ReportFile
-d deletes entries listed in ReportFile from lc-files
-u updates [Constraints] and [Comment] listed in ReportFile from lc-files
ReportFile is a tab-separated report file created with lcscan

LCSCAN -f [-r] FileName MapFile [AdaptationFile]
-f creates translation tables for map and adaptation instruction
-r work recursively
FileName is the lc file or subdirectory name
MapFile is a csv map instructions table (Unicode)
AdaptationFile is an optional csv adaptation instruction table (Unicode)

Report creating:

For example running the below command returns all map instructions in a set of lc-files. To create a report, you have to redirect the output of the command.

LcScan.exe -m -r *.lc > report.txt

The format of the report is a tab-separated file with the following info:

Filename (including relative path)
Identifier
Instruction
All instructions of string
map/placeholder string if these instructions are used
Comment
String

Batch updating of lc-files:

Another option of lc-file is to do some batch updating of lc-files. Providing a modified report generated by LCScan as input, you can do a number operations, delete entries from lc-files (after this you can use LCScan -e to list all empty lc-files), and update changed constraints and comments.

Creation of a mapping table:

You can use LCScan to generate a mapping table (or adaptation table) to be used as part of the mapping table process. For more information on the mapping table process, see Mapping table process.


New Page 1

[ऱऩ०ऍग़PLP configuration utility PLConfig !!! !!! !!! !!!]:

Plconfig.exe is a UI utility that helps you create and generate your own XML custom configuration file. To start creating your own custom XML configuration file you need to do the following:

Open PLConfig and goto "File"/"New Config". The newly opened document now contains the same settings as the ones built into LCTOOLS. You can now start editing your settings. Please note that the PLconfig options are divided into three categories:

  • Instruction Generation
  • Pseudo Translation
  • General

A lot of settings can be specified per resource type. You will find the following resource types:

  • Dialog

  • HTML

  • Menu

  • Message

  • String table

  • Other

  • All

To learn more about the different features and options in Plconfig, you need to browse through the different options and read the tool tip at the bottom of the dialog describing exactly what that specific option does.


New Page 1

[ββνχύMapping table utility MapLoc !!! !!! !!! ]:

MapLoc.exe is a simple utility that helps you with the mapping table process. MapLoc includes two modes:

  • Generate a INF file from the mapping table. The INF file will contain the source strings from the mapping table
  • Update the mapping table with the information from the INF file. As the INF file is assumed to be localized, the target strings from the mapping table will be updated

A second reason the INF file is generated is to have the file localized by our localization team and then used as part of the localization verification process. For more information, see the following:

  • Mapping table process
  • Localization verification

The syntax of MapLoc:

Mapping table localization utility.

MAPLOC.EXE -s|-t MapFile MapInf
-s Generates the MapInf from the source strings in MapFile.
-t Generates the MapInf from the target strings in MapFile.
MapFile is the input file generated by LcScan -f utility.
MapInf is the output file containing all string in INF file format.

MAPLOC.EXE -l MapFile MapInf NewMapFile
-l Localizes the MappingTable.txt based on strings in MapInf.
MapFile is the first input file generated by LcScan -f utility.
MapInf is the second input file with localized strings.
NewMapFile is the output file with translated strings.


New Page 1

[жДўзуЪцїld цтїlїтў LCbµїld !!! !!! !]:

LCBuild was more or less developed as a test utility for LCTOOLS, but is included in the release as it can be quite handy as a troubleshoot tool for (pseudo) localization. LCBuild can tokenize files in a similar fashion as is done by LCCmd, but can also generate new binaries using those token files. This means that LCBuild is a partial build solution around LocStudio file parsers for localized builds, partial as it can only handle string resources. However these string resources are in the majority of cases the cause of localizability bugs, making LCBuild a useful tool for the troubleshooting of these bugs.

Pseudo localization token replacement utility.

LCBUILD [options] -t InputFile [OutputTokenFile]
-t Create Token File
InputFile Input File
OutputTokenFile Output Token File

LCBUILD [options] -r InputFile InputTokenFile [OutputFile]
-r Replace old resources with tokens
InputFile Input File
InputTokenFile Input Token File used for replacement
OutputFile Output File

OPTIONS:
-i {PID SID}|LangID Input language, Primary- and Sub-Lang IDs, dec/hex
-o {PID SID}|LangID Output language, Primary- and Sub-Lang IDs, dec/hex
-s POpt Parser options name
-e ParserID Parser ID
-d Don't process strings with developer lock flags
-w Display the status of the operation

LCBUILD -reg [regfile]
-reg Register LCBUILD

LCBUILD [-h|?] [-z]
-h|? Display help message
-z Display Error message table


New Page 1

[ββνχύMapMerge.exe !!! !!! !!! ]:

MapMerge.exe is a simple utility that merges the different mapping table files created by LcScan.exe and HtmlFont.exe. To learn more about MapMerge.exe please check out the Mapping table process.

  • Mapping table process
  • Localization verification

The syntax of MapMerge.exe:

Merge mapping tables utility.

MAPMERGE.EXE MapFile AdaptFile FontFile OutputFile
MapFile is the input file generated by LcScan -f utility.
AdaptFile is the input file generated by LcScan -f utility.
FontFile is the input file generated by HtmFont utility.
OutputFile is the output file generated.


New Page 1

[ββνχύHtmlFont.exe !!! !!! !!! ]:

HtmlFont.exe is a simple utility that helps you enhance the mapping table process. HtmlFont.exe searches through the Unicode token files created by the Lccmd -t option for instances of font names and font sizes for HTML-elements. The HTML parser uses certain strings as part of the string identifiers that make it possible to identify the strings that are font names or sizes. The strings HtmlFont is looking for are specified in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\LCTools\AdaptationRule. The output file created by HtmlFont.exe is a comma separated file that follows the same format as the mapping file format.

For more information on the Mapping table process, please check out:
  • Mapping table process
  • Localization verification

The syntax of HtmlFont.exe:

Utility to strip out all font face names/sizes in HTML token files

Usage:
HtmlFont.exe [-r] TokenFile OutputLogFile

-r : Optional recursive search.
TokenFile : Token file generated using the Lccmd -t option
OutputLogFile: Log file that rceives Font Face Names & Font Sizes.


BEGIN{
aâäàåáª,
cç¢,
eéêëè,
fƒ,
iïîìí¡,
nñ,
oôöòóº°,
uüûùúµ,
yÿ,
AÄÅ,
Bß,
CÇ,
EÉ,
L£,
NÑ,
OÖ,
UÜ,
Y¥,
®r,
©c,
¾.,
}END


BEGIN{
âäàåáªç¢éêëèƒïîìí¡ñôöòóº°üûùúµÿÄÅßÇÉ£ÑÖÜ¥
}END


BEGIN{
aαά,
cζς,
dδ,
eεξέ,
iιίϊ,
kκ,
nηπήⁿ,
oθοσό°,
pρφ,
tτ,
uμυϋύ,
vν√,
wώωψ,
yγ,
AΑΔΛΆ,
BΒβ,
EΕΣΈ,
HΗΉ,
IΙΊΪ,
KΚ,
MΜ,
NΝΠ,
OΘΟΩΏΌΦ,
PΡ,
RΓ,
TΤ,
WΨ,
XΧχ,
YΥΎΫ,
ZΖ,
®r,
©c,
¾.,
½.,
¼.,
}END


BEGIN{
aāäåą,
cčć¢©,
eéēęė,
gģ,
iīį,
kķ,
lłļ,
nńņ,
oōöøóõ,
rŗ®,
sśš§,
uüųūµ,
x×,
zžżź,
AÄÅĀĄ,
Bß,
CĆČ,
EÉĘĖĒ,
GĢ,
IĪĮ,
KĶ,
L£ĻŁ,
NŃŅ,
OÖØÓŌÕ,
RŖ,
SŚŠ,
UÜŲŪ,
ZŹŻŽ,
}END


BEGIN{
āäåąčć¢©éēęėģīįķłļńņōöøóõŗ®śš§üųūµ×žżźÄÅĀĄßĆČÉĘĖĒĢĪĮĶ£ĻŁŃŅÖØÓŌÕŖŚŠÜŲŪŹŻŽ
}END


BEGIN{
aâäàåáãª,
bþ,
cç¢©,
dð,
eéêëè,
fƒ,
iíïîì,
nñ,
oôöòøºóõ°,
r®,
s§,
uüûùúµ,
x×,
yÿý,
AÄÅÁÂÀÃ,
BßÞ,
CÇ,
DÐ,
EÉÊËÈ,
IÍÎÏÌ,
L£,
NÑ,
OÖØÓÔÒÕ,
UÜÚÛÙ,
Y¥Ý,
}END


BEGIN{
âäàåáãªþç¢©ðéêëèƒíïîìñôöòøºóõ°§üûùúµ×ÿýÄÅÁÂÀÃßÞÇÐÉÊËÈÍÎÏÌ£ÑÖØÓÔÒÕÜÚÛÙ¥Ý
}END


BEGIN{
aâäáąă,
cčçć,
dďđ,
eéëęě,
iîí,
lľĺł,
nńň,
oöôőó°,
rŕř,
sśşš§,
tťţ,
uüůúű,
x×,
yý,
zżžź,
AÄĄĂÂÁ,
Bß,
CÇĆČ,
DĎĐ,
EÉĘËĚ,
IÎÍ,
LĽĹŁ,
NŇŃ,
OÔÖŐÓ,
RŔŘ,
SŚŞŠ,
TŤŢ,
UŮÜÚŰ,
YÝ,
ZŻŹŽ,
®r,
©c,
¾.,
½.,
¼.,
}END


BEGIN{
âäáąăčçćďđéëęěîíľĺłńňöôőó°ŕřśşš§ťţüůúű×ýżžźÄĄĂÂÁßÇĆČĎĐÉĘËĚÎÍĽĹŁŇŃÔÖŐÓŔŘŚŞŠŤŢŮÜÚŰÝŻŹŽ
}END


BEGIN{
aâäàåáãª,
cç©¢,
eéêëè,
gğ,
iıîïíì,
nñ,
oóôöòøºõ°,
r®,
sş§,
uüúûùµ,
x×,
yÿ,
AÄÅÁÂÀÃ,
Bß,
CÇ,
EÉÊËÈ,
GĞ,
IİÍÎÏÌ,
L£,
NÑ,
OÖØÓÔÒÕ,
SŞ,
UÜÚÛÙ,
Y¥,
}END


BEGIN{
âäàåáãªç©¢éêëèğıîïíìñóôöòøºõ°®ş§üúûùµ×ÿÄÅÁÂÀÃßÇÉÊËÈĞİÍÎÏÌ£ÑÖØÓÔÒÕŞÜÚÛÙ¥
}END


BEGIN{
aад,
bвьъ,
cс,
eезёэє,
hн,
iї,
kк,
mм,
nийлп,
oбфо°,
pр,
rгя,
tт,
uчц,
v√,
wщш,
xхж,
yуў,
AАД,
BБВЪЬ,
CС,
EЕЗЭЁЄ,
HН,
IЇ,
KК,
MМ,
NПЛЙИ,
OФО,
PР,
RГЯ,
TТ,
UЧЦ,
WЩШ,
XХЖ,
YУЎ,
®r,
©c,
¾.,
½.,
¼.,
}END


BEGIN{
aา,
bบ,
cค,
dด,
eเ,
fฟ,
gก,
hฮ,
iไ,
jจ,
kฅ,
lล,
mม,
nน,
oอ,
pพ,
qฆ,
rร,
sส,
tท,
uย,
vว,
wฬ,
xซ,
yญ,
zศ,
Aา,
Bบ,
Cค,
Dด,
Eเ,
Fฟ,
Gก,
Hฮ,
Iไ,
Jจ,
Kฅ,
Lล,
Mม,
Nน,
Oอ,
Pพ,
Qฆ,
Rร,
Sส,
Tท,
Uย,
Vว,
Wฬ,
Xซ,
Yญ,
Zศ,
}END


BEGIN{
าบคดเฟกฮไจฅลมนอพฆรสทยวฬซญศ
}END


BEGIN{
ｱタチ穴ソ噂欺啓ゼゾダボポマミ蕁袢衵虍滌漾穐旭袷厓晙
}END


BEGIN{
亊亐侢狜獈迳孱彐弪齄唱府靠
}END


BEGIN{
갂갵흞걖윜걂흐쾖선괕뭕줡춝헭흝땔리에뎝瀁俺冶呂詰닼댃댛
}END


BEGIN{
云月加功包四吋宇否址現票許替墮慧餐坼琵騱鱋琥跑鉤漬腶遒鋓暪樖嬏憉籲乂牧悅蕞
}END


BEGIN{
aáâăäą,
AÁÂĂÄĄ,
Bß,
cćçč,
CĆÇČ,
dđď,
DĐĎ,
eéęëě,
EÉĘËĚ,
iíî,
IÍÎ,
lłľĺ,
LŁĽĹ,
nńň,
NŃŇ,
oóôőö,
OÓÔŐÖ,
rŕř,
RŔŘ,
sşšś,
SŞŠŚ,
tţť,
TŢŤ,
uůúűüµ,
UŮÚŰÜ,
yý,
YÝ,
zžżź,
ZŻŹŽ,
¼.,
½.,
¾.,
}END


BEGIN{
áâăäąÁÂĂÄĄßćçčĆÇČđďĐĎéęëěÉĘËĚíîÍÎłľĺŁĽĹńňŃŇóôőöÓÔŐÖŕřŔŘşšśŞŠŚţťŢŤůúűüŮÚŰÜýÝžżźŻŹŽ
}END


BEGIN{
aд,
AД,
bвБьъ,
BbЪЬ,
c©,
eзёєэ,
EЗЁЄЭ,
hнћ,
HЊ,
iї,
IЇ,
kкќ,
KЌ,
mм,
nийпл,
NИЙПЛ,
oфюб,
OФЮ,
rѓґгя,
RЃҐГЯ,
tт,
TЋ,
uџцµ,
UЏЦ,
wшщ,
WШЩ,
xж,
XЖ,
yучў,
YУЧЎ,
®ѓґгя,
¼.,
½.,
¾.,
}END


BEGIN{
дДвБьъbЪЬзёєэЗЁЄЭнїЇкмийплИЙПЛфюбФЮгяГЯтцЦшщШЩжЖучўУЧЎ
}END


BEGIN{
aªàáâãäåæ,
AÀÁÂÃÄÅÆ,
bþ,
BÞß,
cç¢,
CÇ,
DÐ,
dð,
eèéêë,
EÈÉÊË,
fƒ,
iìíîï,
IÌÍÎÏ,
L£,
nñ,
NÑ,
oòóôõöø,
OÒÓÔÕÖØ,
sš,
S§Š,
uùúûüµ,
UÙÚÛÜ,
yýÿ,
YÝ¥,
}END


BEGIN{
àáâãäåæ@ÀÁÂÃÄÅÆßç¢©ÇèéêëÈÉÊËìíîïÌÍÎÏ£ñÑòóôõöøÒÓÔÕÖØùúûüµÙÚÛÜÿ¥
}END


BEGIN{
aάα,
AΆΔΛ,
Bβ,
cς,
eέε,
EΈΣ,
HΉ,
iΐίιϊ,
IΊΪ,
L£,
kκ,
nήη,
NΠ,
oθσφό,
OΌΏΘΦΩ,
RΓ,
tτ,
uΰµϋύ,
vν,
wωώ,
YΎ¥Ϋ,
Xχ,
®r,
¼.,
½.,
¾.,
}END


BEGIN{
άαΆΔΛβςέεΈΣΉίιϊΊΪκήηΠθσφόΌΏΘΦΩΓτϋύνωώΎχ
}END


BEGIN{
aàáâãäå,
AÀÁÂÃÄÅ,
Bß,
c¢ç,
CÇ,
eèéêë,
EÈÉÊË,
fƒ,
gğ,
GĞ,
iìíîï,
IÌÍÎÏİ,
L£,
nñ,
NÑ,
oœòóôõø,
OŒÒÓÔÕÖØ,
sšş,
SŠŞ,
uµùúûü,
UÙÚÛÜ,
yÿ,
YŸ¥,
®r,
}END


BEGIN{
àáâãäåæÀÁÂÃÄÅÆß¢©çÇèéêëÈÉÊËğĞìíîïÌÍÎÏİ£ñÑòóôõøÒÓÔÕÖØşŞµùúûüÙÚÛÜÿ¥
}END


BEGIN{
aא,
bב,
cך,
dד,
eה,
fף,
gג,
hח,
iי,
jן,
kכ,
lל,
mמ,
nנ,
oם,
pפ,
qק,
rר,
sס,
tת,
uו,
vט,
wש,
xצ,
yע,
zז,
Aא,
Bב,
Cך,
Dד,
Eה,
Fף,
Gג,
Hח,
Iי,
Jן,
Kכ,
Lל,
Mמ,
Nנ,
Oם,
Pפ,
Qק,
Rר,
Sס,
Tת,
Uו,
Vט,
Wש,
Xצ,
Yע,
Zז,
}END


BEGIN{
אבךדהףגחיןכלמנםפקרסתוטשצעז
}END


BEGIN{
aا,
bب,
cك,
dد,
eي,
fف,
gغ,
hه,
iي,
jج,
kك,
lل,
mم,
nن,
oو,
pپ,
qق,
rر,
sس,
tط,
uي,
vف,
wو,
xإ,
yي,
zظ,
Aا,
Bب,
Cك,
Dد,
Eي,
Fف,
Gغ,
Hه,
Iي,
Jج,
Kك,
Lل,
Mم,
Nن,
Oو,
Pپ,
Qق,
Rر,
Sس,
Tط,
Uي,
Vف,
Wو,
Xإ,
Yي,
Zظ,
}END


BEGIN{
ابكديفغهيجكلمنوپقرسطيفوإيظ
}END


BEGIN{
aåąāäæ,
bß,
cčć¢,
eēéėę,
gģ,
iīį,
kķ,
lłļ,
nńņ,
oōóõö°ø¤,
rŗ,
sśš§,
uüųūµ,
x×,
zżžź,
AĄĀÄÅÆ,
CČĆ,
EĖĘĒÉ,
GĢ,
IĪĮ,
KĶ,
LĻ£Ł,
NŃŅ,
OŌÕÖÓØ,
RŖ,
SŚŠ,
UŪÜŲ,
ZŻŽŹ,
}END


BEGIN{
āäåæąßć¢©čęėéēģīįķłļńņōöøóõ¤ŗ®śš§üųūµ×żźžÄÅÆĀĄĆČÉĘĖĒĢĪĮĶ£ŁĻŃŅÖÓŌÕØŖŚŠÜŲŪŹŻŽ
}END


BEGIN{
aàáâăäåæª,
bß,
cç©¢,
dđ₫,
eèéêë,
fƒ,
iíîï,
j¡,
nñ,
oóôơöøœ°¤,
r®,
uùúûüưµ,
x×,
yÿ,
ÀÀÁÂĂÄÅÆ,
Bß,
CÇ,
DĐ,
EÈÉÊË,
E€,
IÍÎÏ,
L£,
NÑ,
OÓÔƠÖØŒ,
S§,
UÙÚÛÜƯ,
Y¥Ÿ,
}END


BEGIN{
aàáâăäåæªbßcç©¢dđ₫eèéêëfƒiíîïj¡nñoóôơöøœ°¤r®uùúûüưµx×yÿÀÀÁÂĂÄÅÆBßCÇDĐEÈÉÊËE€IÍÎÏL£NÑOÓÔƠÖØŒS§UÙÚÛÜƯY¥Ÿ
}END


BEGIN{
aàáâãäå,
cç¢©,
eèéêë,
fƒ,
iìíîï,
nñ,
oòóôõöø,
r®,
s§,
uùúûüµ,
yÿ,
AÄÅÀÃÁÂ,
Bß,
CÇ,
EÉÈÊË€,
IÌÍÎÏ,
L£,
NÑ,
OÖØÕÒÓÔ,
UÜÙÚÛ,
Y¥Ϋ,
¼.,
½.,
¾.,
}END


BEGIN{
àáâãäåç¢©èéêëƒìíîïñòóôõöø®§ùúûüµÿÄÅÀÃÁÂßÇÉÈÊË€ÌÍÎÏ£ÑÖØÕÒÓÔÜÙÚÛ¥Ϋ
}END


BEGIN{
aάα,
cς,
eεέ,
iΐϊί,
IΊ,
L£,
kκ,
nηή,
oθσό,
tτ,
uΰϋύ,
vν,
wωώ,
AΆΛΔ,
Bβ,
EΈ,
HΉ,
NΠ,
OΩΌΏΘΦ,
RΓ,
YΫΎ¥,
Xχ,
¼.,
½.,
¾.,
}END


BEGIN{
άαςεέΐϊίΊ£κηήθσότϋύνωώΆΛΔβΈΉΠΩΌΏΘΦΓΫΎ¥χ
}END


BEGIN{
aд,
bвБьъ,
c©,
eзёєэ,
hнћ,
iї,
kкќ,
mм,
nийпл,
oфб,
rѓгя,
tт,
uџцµ,
wшщ,
xж,
yчў,
AД,
BbЪЬ,
EЗЁЄЭ,
IЇ,
KЌ,
NИЙПЛ,
OФ,
RЃГЯ,
TЋ,
UЏЦ,
WШЩ,
XЖ,
YЧЎ,
¼.,
½.,
¾.,
}END


BEGIN{
двБьъ©зёєэнћїкќмийплфбѓгятџцµшщжчўДbЪЬЗЁЄЭЇЌИЙПЛФЃГЯЋЏЦШЩЖЧЎ
}END


BEGIN{
aáąä,
cčć,
dď,
eéěę,
ií,
lłľĺ,
nńň,
oóôöő,
rŕř,
sšś,
tť,
uúüůű,
yý,
zźžż,
AÄĄÁ,
Bß,
CČĆ,
DĎ,
EÉĚĘ,
IÍ,
LĽĹŁ,
NŃŇ,
OÖŐÓÔ,
RŔŘ,
SŠŚ,
TŤ,
UÜŮÚŰ,
YÝ,
ZŹŽŻ,
¼.,
½.,
¾.,
}END


BEGIN{
áąäčćďéěęíłľĺńňóôöőŕřšśťúüůűýźžżÄĄÁßČĆĎÉĚĘÍĽĹŁŃŇÖŐÓÔŔŘŠŚŤÜŮÚŰÝŹŽŻ
}END


BEGIN{
aáàâãäå,
cç¢,
eèéêë,
gğ,
iìíîï,
nñ,
oòóôõ,
sş,
uùúûü,
yÿ,
AÄÅÀÃÁÂ,
Bß,
CÇ,
EÉÈÊË,
GĞ,
IİÌÍÎÏ,
L£,
NÑ,
OÖÕÒÓÔ,
SŞ,
UÜÙÚÛ,
YŸ,
¼.,
½.,
¾.,
}END


BEGIN{
áàâãäåç¢èéêëğìíîïñòóôõşùúûüÿÄÅÀÃÁÂßÇÉÈÊËĞİÌÍÎÏ£ÑÖÕÒÓÔŞÜÙÚÛŸ
}END


BEGIN{
}END


BEGIN{
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
}END


BEGIN{
AAＡ,
BBＢ,
CCＣ,
DDＤ,
EEＥ,
FFＦ,
GGＧ,
HHＨ,
IIＩ,
JJ,
KKＫ,
LLＬ,
MMＭ,
NNＮ,
OOＯ,
PPＰ,
QQＱ,
RRＲ,
SSＳ,
TTＴ,
UUＵ,
VVＶ,
WWＷ,
XXＸ,
YYＹ,
ZZＺ,
aaａ,
bbｂ,
ccｃ,
©c,
ddｄ,
eeｅ,
ffｆ,
ggｇ,
hhｈ,
iiｉ,
jjｊ,
kkｋ,
llｌ,
mmｍ,
nnｎ,
ooｏ,
ppｐ,
qqｑ,
rrｒ,
®r,
ssｓ,
ttｔ,
uuｕ,
vvｖ,
wwｗ,
xxｘ,
yyｙ,
zzｚ,
}END


BEGIN{
ＡＢＣＤＥＦＧＨＩJＫＬＭＮＯＰＱＲＳＴＵＶＷＸＹＺａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚ
}END