What is "LCTOOLS" ?

"LCTOOLS" is a tool set developed and provided to you by the Windows Localizability team. The tool set provides you with a global commenting model build on top of LocStudio no-compile technology. The tool set can also be used to create pseudo localized and pseudo mirrored builds. As the tools are build on top of generic tools 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 commenting model for compiled files in your product.
  • Creation of pseudo localized and pseudo mirrored files.
  • Checking if your file is in a localizable format. LCTOOLS is based on the same parser technology as our corporate localization tool 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://toolzone/locstudio )

In this help file you can find the following topic:

  • What is Pseudo Localization
  • LCTOOLS basics
  • Commenting tool LCAdmin.exe
  • Pseudo build tool LCCmd.exe
  • Mirroring tool mirror.exe
  • Importing and exporting lc-files in LocStudio
  • LC-file scan utility LCScan.exe
  • PLP configuration utility PLConfig.exe

The following aliases are provided for information and feedback:

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

*) LCTOOLS is build on top of the LocStudio parser model and PLP (Pseudo Localization Platform) owned by PTT (Productivity Tools Team). LCTOOLS is compatible with LocStudio 451a qfe 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 as specified by the pseudo language. The pseudo language has been designed to test the localizability of string translation. The pseudo localization process will also expose a number of other localizability and process issues.

An example of the possible appearance of UI in a pseudo build:

Pseudo localization screenshot

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 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 localization can increase the test coverage of localized products in areas that are not always tested broadly for localized languages

Pseudo language:

The pseudo language needs to stress the system for its localizability and find as many functional and often cosmetic problems as possible. 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 of delimiters to see how strings are put together during runtime

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

  • Stretching dialogs 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, identifier, etc.

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 very start of a project cycle, pilot localization later in the project 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 Localization testing.


LCTOOLS basics:

  • LCTOOLS installation and configuration
  • Process using LCTOOLS
  • LCTOOLS input files
  • Localizability instructions used by LCTOOLS
  • Known limitations and file list of LCTOOLS
  • Pseudo localization settings
  • Pseudo mirroring
  • HTML pseudo localization


Installing and configuring "LCTOOLS":

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:

Installation of LCTOOLS is very straightforward. Either install through the self-extracting installation program, or copy the program files to a folder on your machine then add this folder to your path. The tools are registered through the self-extracting installation program, the first time running lcadmin/lccmd, explicitly through running "lccmd -r" or option "Register DLLs" in the "File" menu in lcadmin. Explicit registration is needed if configuration changes are made.

Note: Installing LCTOOLS on a machine with LocStudio installed will overwrite parser settings. LCTOOLS is based on LocStudio 4.51a QFE and includes several unchanged files released with this LocStudio version.

Parsers and parser settings:

LCTOOLS is based on the parser model of LocStudio (we don't support the POM-model). You can add/remove any parser supported by this parser model by deleting parsers from and adding parsers to the LCTOOLS folder, and then re-registration of the tools. Without any further configuration, the parsers are working according to their default values. If you want to further configure your parsers, you will need to do this through the registration file lcdef.reg. The settings in this file will be written into the registry when you register the tools (through "lccmd -r" or through "File"/"Register DLLs" in lcadmin). There are two different kind of settings that can be set, the extension list and the parser options.

For your convenience, all default parser settings have been written to lcdef.reg, this will make it easier for you to modify these settings.

Extension list:

The 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 extension list of that parser. The extension list of a parser can be found in
"HKLM\Software\Microsoft\LocStudio 4.51\Parsers\<Parser#>\ExtensionList". When a parser is registered, the default extension list for the parser will be written to this location. If you want to modify this list, you can write the updated list into this registry key directly. To share this updated setting with more people, or prepare a LCTOOLS package for your project, export the updated registry keys and add to lcdef.reg.

Parser options:

The settings of a parser determine the way a file is parsed. The parser settings for LCTOOLS can be found in "HKCU\Software\Microsoft\LocStudio 4.51\LC Parser Options". By default no parser options need to be written in the registry as default parser options will apply. The structure of the parser settings is identical to the parser settings set as user settings in LocStudio, those are stored in "HKCU\Software\Microsoft\LocStudio 4.51\Parser Options". You can modify the parser settings by using LocStudio and set all user settings to the settings you want LCTOOLS to use (note that you have to turn-off the default values when doing this). Then you can copy/rename the registry keys with these settings or export the registry keys and add and rename to lcdef.reg

Using multiple parser options:

Not all files within a project can always be parsed using one set of parser options. You can create different sets of parser options and use these different sets of options as input value of lccmd (-s swith). Parser options are generally written to "HKCU\Software\Microsoft\LocStudio 4.51\<Parser Options>". In the default case, the parser options are taken from the "LC Parser Options" key, and no input value is needed for lccmd. lcadmin only supports the default parser options.

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 kind of information is parsed from an HTML or script file, what tags are regarded localizable or non-localizable, etc. 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 current configuration or to create a new configuration. Settings are generally written to "HKLM\Software\Microsoft\Weaver\Loom\<HTML Settings>" and the configuration used is one of the parser options.

To change the HTML configuration, use LoomConfig to create a new configuration, export this new configuration from the registry and add this to lcdef.reg. Also update the configuration used by changing the parser option of the HTML parser and/or HTML sub parser accordingly. The default settings have been added to lcdef.reg.

XML configuration:

XML localization is configured through two files, locxml.dtd and locxml.xml. PTT (Productivity Tools Team) published documentation on how to configure these files:

  • XML parser: http://toolzone/tools/locstudio/ls45/parserdocs/xmlparse.htm

HTML pseudo localization:

HTML strings are consider as one of the following: HTML-text (localizable), non-localizable (filenames, etc), or adaptable (strings can only change to certain values, eg attributes, font names, etc). For this we can configure what string categories are localizable (HTML-text) and what strings are not localizable (not localizable strings or adaptable). This setting is saved in "HKLM\Software\Microsoft\LCTools\HTML". There are 3 sub keys:

  • FontName: String categories that contain font names. Translation of these strings will be looked up in the mapping table.
  • HTML: String categories of strings that are localizable
  • Other: String categories of strings that are not localizable

To change the way string categories are assigned to these groups, you can modify the registry, export these modified settings and add to lcdef.reg. The default settings have been added to lcdef.reg.

Pseudo localization settings:

There are several utilities that specify how a file is being pseudo localized. These utilities are all being described at other locations and there for we will suffice with providing you with links to that information:

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


LCTOOLS process:

LCTOOLS can be used for your project in many ways. The tools can be fully implemented as part of the development process where the lc-files will be an additional handoff to localization. The tools can also be implemented as part of the localization process, where lc-files are used as an easy mean of communication with development and for trouble shooting and pseudo localization.

Below several aspects of the tools are highlighted to give you an impression on how you could implement the tools in your process:

Tokenization (change tracking):

Tokenization is an easy way of doing change tracking of 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 WINDIFF or other utilities. For more information, see tokenization.

LC-maintenance (commenting):

Comments and instructions are maintained in lc-files. When resources are updated, lc-files might need to be updated. Also for new files in the project, lc-files might need to be created. Development teams are encouraged to provide as much useful information as possible on string resources. Lc-file maintenance is done through the UI-utility LCAdmin, for more information, see Commenting in LCAdmin.

LCTOOLS also comes with a utility LCScan to do report generation of lc-files and some batch-maintenance. For more information, see LCScan.

LC-verification:

LC-files can be easily 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 possibly 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. LCTOOLS provides a wide range of pseudo localization options through the pseudo build tool lccmd. For more information, see Pseudo building with Lccmd.

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

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

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 with LocStudio extensions that make exchange of information possible. Correctness of translations can be checked through LocVer, a module build into LocStudio. For more information, see import/export extensions.


Input files of "LCTOOLS":

The following are the input files used by LCTOOLS:

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

LC-file:

An lc-file is the carrier of comments and instructions for a certain file. The lc-file has 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.

Mapping table:

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

  • String dependencies: Some strings need to be translated consistently to ensure correct functioning software. Example of string dependencies are account names and folder names (of course it is better to prevent or remove these string dependencies). By marking depending strings with a map-instruction, these strings will be looked up in the mapping table and so consistency is insured.
  • Adaptation: Strings marked with an adaptation instruction might have to be translated. An example of this is a font name that might need to be changed for a certain language. All strings marked as adaptation will be looked up in the mapping table as well.

The mapping table is a Unicode comma separated text file with only two columns (more columns is not supported). Strings with commas included can be added with surrounding quotes. The mapping table is case-sensitive. If a string is not found in the mapping table, the string is not translated.

PLP-configuration file:

LCTOOLS use PLP as the pseudo translation engine. PLP can be configured through an XML-file created with PLConfig. Without specifying a PLP configuration file, the default settings built into LCTOOLS are used. For more information see PLConfig.


Instruction set used by LCTOOLS:

The following instructions are supported by LCTOOLS:

  • Locked instruction: {Locked}
    • This feature is used when a string is not localizable. Think of registry keys, API 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"
    • When a placeholder is set for part of a string, we do not add string extension or delimiters anymore. This enables you to specify that the beginning or the end of a string can not be localized.
    • 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} added.
  • Maxlength instruction: {MaxLength=x}
    • Used when there is limitation on the size of the string.
  • Map instruction: {Map}+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
    • 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
  • Adaptation instruction: {Adaptation}+comment
    • An adaptation instruction is specified when a string is used for adaptation. Think of font names, font sizes, URLs, numeric info like LCID, codepage, or just a switch that is used to turn on/off a feature. These strings need to be localizable and need to be localized by some languages, but cannot be localized randomly
    • When entering an adaptation instruction, you will be asked to enter a comment

Beside the above instructions, we have the following semi-instructions:

  • NoRules: {NoRules}
    • When you change the default placeholders set by the tool, a instruction NoRules will be used to remember not to use this default behavior.
  • Comment: Comment
    • Comments are extremely useful for localization. Note that comments added to WIN32 sourcecode 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.
  • {RTL} Markers for BIDI MessageBox localization
    • 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.


Limitations and filelist of LCTOOLS:

Limitations of LCTOOLS:

Listed below is a number of the known limitations of LCTOOLS.

  • LCTOOLS is not using the POM-model LocStudio 451 supports. There are very few POM-parsers at the moment and all POM-parsers have alternative parsers. New developed POM-parsers will not work for LCTOOLS and improvements of the POM parsers compared to the pre POM parser are not available.
  • The pre-POM model does not support localization of XML-islands in HTML-files.
  • 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 work correctly.
    • Files are associated with file parsers through an extension list. If a file extension is not listed under the 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. Most of LCTOOLS have ways to force the use of alternative file parsers that are not recognized by default
  • The LocStudio extension to import/export lc-files has several limitations. These limitations are document under LocStudio import/export extension.
  • 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)

File list:

LCTOOLS:

lcadmin.exe: UI commenting utility to create/maintain lc-files
lccmd.exe: command line pseudo build and tokenize utility
lcman.dll: LCTOOLS libraries
lcdef.reg: registration settings for LCTOOLS
lctools.chm: lctools help file
converter.dll: import/export LocStudio extension
lcgen.dll: import/export LocStudio extension
lcscan.exe: utility to scan lc-files

PLP:

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

LocStudio files (LocStudio 451a QFE):

crunch.dll: WIN32 auxiliary resource remover DLL
esputil.dll: Espresso utility DLL
locutil.dll: LocStudio utility DLL
mitdiff.dll: word breaking engine of LocStudio
mitutil.dll: internal tools utility DLL
parseman.dll: parser manager
parsutil.dll: parser utility DLL

LocStudio parsers (LocStudio 451a QFE):

bitparse.dll: BLT template files
dos7pars.dll: DOS 7 files
infparse.dll: INF-files
iniparse.dll: INI-files
ldfparse.dll: LDF-files
mac.dll: macintosh-files
mactok.dll: macintosh token files
msgparse.dll: message files
msiparse.dll: MSI-files
msiparse.ini: MSI parser configuration
netparse.dll: Network files
ppdparse.dll: Postscript files
riffpars.dll: RIFF-files
rplboot.dll: RPL boot files
scanpars.dll: scandisk files
srgparse.dll: SRG-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
tokparse.dll: windows token files

LocStudio HTML/XML parsers (LocStudio 451a QFE unless stated otherwise):

heat42.dll: web files, version 4.22.0.413
heat42s.dll: web files, win32 sub parser
loom.dll: web files parsing engine, version 4.51.0.141
locxml.dll: xml parser called by heat42.dll/heat42s.dll
locxml.dtd: xml parser configuration
locxml.xml: xml parser configuration

Mirroring files:

mirror.exe: utility to mirror rsrc token files
rsrc.exe: win32 tokenization utility
makemir.bat: template batch file for mirroring
mirror.xml: default PLP configuration for mirroring


Creating a Pseudo Localized build

Pseudo Localization settings:

There are a number of settings you need to decide on when creating pseudo builds. The settings you choose depend on what you want to achieve and the project characteristics. Below we shortly discuss a number of appearance options of LCTOOLS:

  • Replacement table (pseudo language)
  • Replacement methods
  • Dialog stretching
  • String extension

Replacement table:

LCTOOLS uses a number of Unicode based replacement tables. The choice depends on the language coverage needed (what languages do we need to release the product into), the coverage required of the build (e.g. do we 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 strings are displayed using the ANSI codepage, all characters will be displayed correctly.
  • OEM codepages: All characters used for replacement are part of a OEM codepage, which means that when strings are displayed using the OEM codepage, all characters will be displayed correctly.
  • 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
    • DBCS: The matching replacement table contains regular ASCII and double byte ASCII characters. The random table contains characters from the 4 FE ANSI codepages
    • ASCII: The random table contains all ASCII characters
    • Hindi: The random table contains a number of Hindi characters

You can display a list with available languages with "lccmd -l"

Replacement methods:

LCTOOLS can use 3 different replacement methods. The choice here depends also 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 can take place.

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.

You can display a list with available languages with "lccmd -k"

Dialog stretching:

For most pseudo builds, strings are made longer to test of 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 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 " !!!")


Creating a Mirrored build

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. 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.

For more information on mirroring, see mirroring information.


New Page 1

Localizing HTML using LCTOOLS:

HTML localization is quite complex. Without any special features, pseudo localization of HTML would be nearly impossible. LCTOOLS has a number of features built in 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 an attached identifier, so it can recognized the items and extract them for localization. For more information on creating localizable HTML, see Authoring HTML for localization.

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

String categorization:

The challenge with HTML pseudo localization is that many strings extracted by the file parser should only get localized in some cases. Items like font name, HTML property, or Style, can definitely not be localized in the random fashion used for other 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 a special way, tags and special characters don't get localized. By default, strings with resource type "Other"don't get localized at all.

All strings of files parsed by the HTML parser or the HTML Win32 sub parser are mapped onto the resource types "HTML" and "Other". This is done by looking at the string category of the string. For example the string categories "Property" and "ArgumentName" are mapped onto resource type "Other", while string categories "Text" and "ErrorMessage" are mapped onto resource type "HTML".

You can configure the string categories mapped onto "HTML" or "Other" by modifying the registry. You can find this configuration in "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\LCTools\HTML".

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

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 type HTML 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:

Most font names are marked as "adaptation". This because font names are not freely localizable and have to be localized for certain languages. By default, strings with an adaptation flag are looked up in the mapping table. In this way you can localize all font names consistently by adding an entry in the mapping table and marking up all strings with font names as "adaptation".

As HTML files contain many font names and are assigned the string category "FontName", we do a lookup of these strings with this string category in the mapping table by default. This prevents having to set many strings as "adaptation".

The string categories to be looked up in the mapping table is configurable in "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\LCTools\HTML".

Mirroring of HTML files:

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


lcAdmin web

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 added advanced 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 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 (only lock flags can be set through the main UI):

The options dialog ("Edit"/"Options") helps you further customize LcAdmin to better fit your needs. You can customize your UI environment, your default files location and best of all you can customize your pseudo settings to help you generate your own private pseudo binaries ("File"/"Generate Pseudo Binary")

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 out the door 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 a developer team 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 help localizers create less problems when simply localizing the build. 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 is not localizable. Think of registry keys, API 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"
    • When a placeholder is set for part of a string, we do not add string extension or delimiters anymore. This enables you to specify that the beginning or the end of a string can not be localized.
    • 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} added.
  • Maxlength instruction: {MaxLength=x}
    • Used when there is limitation on the size of the string.
  • Map instruction: {Map}+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
    • 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
  • Adaptation instruction: {Adaptation}+comment
    • An adaptation instruction is specified when a string is used for adaptation. Think of font names, font sizes, URLs, numeric info like LCID, codepage, or just a switch that is used to turn on/off a feature. These strings need to be localizable and need to be localized by some languages, but cannot be localized randomly
    • When entering an adaptation instruction, you will be asked to enter a comment

Beside the above instructions, we have the following semi-instructions:

  • NoRules: {NoRules}
    • When you change the default placeholders set by the tool, a instruction NoRules will be used to remember not to use this default behavior.
  • Comment: Comment
    • Comments are extremely useful for localization. Note that comments added to WIN32 sourcecode 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.
  • {RTL} Markers for BIDI MessageBox localization
    • 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 can be set/removed through the main UI
  • 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

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 earlier. You can pseudo localize using different code pages and 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 troubleshooting and can be linked into other processes.

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
  -x CFG                 PLP XML configuration file
  -s POpt                Parser options name
  -e ParserID            Parser ID
  -w                     Display the status of the operation

A few samples are given to 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 -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.

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 readible 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.

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 (lccmd supports different set of resource dumps), where option 1 is the default one and is used most frequently.

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
  -x CFG                 PLP XML configuration file
  -s POpt                Parser options name
  -e ParserID            Parser ID
  -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 an 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.

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.

LCCMD -r [regfile]
  -r  regfile            Register all parsers into system

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 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\LC 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 such 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 under (HKLM\SOFTWARE\Microsoft\LocStudio 4.51\Parsers)

Also see Parsers and parser settings

The use of system 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.
  • (Build in settings in LCTOOLS)


Mirror

MIRROR.EXE:

Mirror.exe is a simple to use command line utility that helps you mirror your compiled binary following the same procedure used by the BIDI localizers. Mirror.exe works on .rsrc text files and not directly on compiled binaries.

To find more information about mirroring technology in general, see mirroring information.

  • The usage of mirror.exe
  • The process of creating mirrored binaries
  • Makemir.bat template script file for mirroring
  • WIN32 resource dump utility Rsrc

The usage of Mirror.exe:

Usage:

Utility to set mirroring properties in a rsrc.exe token file

mirror.exe RsrcTokenFile yes|no LogFile

- The yes|no argument will specify whether the tool needs to add
  2 LTR markers to the File Description version resource
- The output will be a token file with the name RsrcTokenFile.mir

Example:
         mirror.exe notepad.exe.rsrc yes log.txt

The process of creating mirrored binaries:

We support mirroring of HTML files and WIN32 binaries.

HTML:
  1. Generate new files using Lccmd.exe with output language Arabic or Hebrew. The parser will add DIR=RTL to all embedded HTML tags. These tags are needed to change the direction of the file.

WIN32:

  1. Generate new files using Lccmd.exe with the WIN32 parser setting to extend dialogs. The dialog needs to be extended as the dialog attribute for direction is an extended style. It is recommended to use Arabic or Hebrew as output language.
  2. Extract the resources with rsrc.exe *) as follows:
    • rsrc.exe foo.exe -t (Where foo.exe stands for your compiled binary)
    rsrc will then generate foo.exe.rsrc
  3. Mirror the token file with Mirror.exe as follows:

    • mirror.exe foo.exe.rsrc Yes|No Logfile.txt

    The yes|no argument specifies whether the tool needs to add 2 LTR markers to the File Description version resource. This is mainly used for executables and binaries that use the CreateWindowsEx() API. This step will generate a file called foo.exe.rsrc.mir

  4. Build new WIN32 binary with rsrc as follows:

    • rsrc.exe foo.exe -l 401|40d -r foo.exe.rsrc.mir

    -l specifies the target language, 401 and 40d are the LCIDs for Arabic and Hebrew

In order to simplify this process you will find within your lctools a template batch file called MakeMir.bat that can be customized and tailored to your needs.

Makemir.bat template script file for mirroring:

The following is the source code used in MakeMir.bat. It can easily be customized to fit your own requirements. You can change your target Language from Arabic to Hebrew or you can combine Pseudo Localization and Mirroring technology into the same script. In the below case we set Pseudo Localization replacement table to -k "None" using the lccmd.exe line below.

@echo off
rem MakeMir.bat template can be used as a starting point to help you design
rem your mirroring script

rem a required file name argument is expected.
if "%1"=="" goto usage
if "%2"=="" goto usage
if "%3"=="" goto usage
if "%2"=="yes" goto start_mirroring
if "%2"=="no" goto start_mirroring
goto usage

:start_mirroring

echo Mirroring %1

rem Use lccmd to extend the dialogs. Standard US dialogs are not extended,
rem to set the mirroring dialog flags, the dialogs need to be extended.
rem Input language is set to English US 409 "lccmd -i 9 "
rem Output language is set to Arabic Saudi Arabia "-o 1 1"
rem Use mirror.xml configuration file. This xml file prevents stretching of the
rem dialogs and does not allow delimiters and exclamation points added to the
rem resource. You might have to change the location of this file in the script.
rem "-l 1256" specifies the replacement table
rem "-k None" specifies the replacement method, in this case characters will
rem not be replaced and you get pure english mirrored file as result
lccmd -i 9 1 -o 1 1 -x %LCTOOLSDIR%\mirror.xml -l 1256 -k none -g %1 2> Nul > Nul

rem Tokenize your binary using rsrc.exe
rsrc.exe %1 -q -t 2> Nul > Nul

rem Mirror the token file using Mirror.exe and add 2 LTR markers in front of
rem the file description resource in the version information if you specify this.
rem This is mainly done for *.exe/*.cpl
mirror.exe %1.rsrc %2 %3 2> Nul > Nul

rem replaced US resource with the Mirrored ones.
rsrc %1 -l 401 -q -r %1.rsrc.mir 2> Nul > Nul

del %1.rsrc /q
del %1.rsrc.mir /q

echo Done!
goto :eof

:usage

echo.
echo Usage:
echo.
echo Makemir.bat FileName yes/no LogFile
echo.
echo FileName: The binary to be mirrored
echo yes/no: specifies if 2 LTR markers need to be added in front of the File
echo Description in the version information.
echo The value specified needs to be entered in lowercase
echo LogFile: log file, output will be appended to this file
echo.

WIN32 resource dump utility Rsrc:

Rsrc is a tokenization command line utility developed by the Windows core team. To learn more about rsrc.exe run the following at the cmd prompt: rsrc -h

Rsrc - Manage Win32 executable resources.

Usage: rsrc -h
or: rsrc executable [-l LangId] [-i include-opts] [-q]
[ [-t|-d] [text-output] [-c unloc]
| [-a|-r] [text-input] [-s symbols] ]

Arguments

-h Help
-q Quiet (default is to show resource stats)
-t tokens Write resources in checkin format to token file
-c unloc Unlocalised executable for comparison
-d tokens Write resources in hex dump format to token file
-a tokens Append resources from token file to executable (multi-language update)
-r tokens Replace executable resources from token file (single language update)
-s symbol Symbol file whose checksum is to track the executable checksum
-l lang Restrict processing to language specified in hex
-u unlocl Unlocalised langauge, default 409
-i opts Include only resource types specified:

c - Cursors t - Fonts
b - Bitmaps a - Accelerators
i - Icons r - RCDATAs
m - Menus g - Message tables
d - Dialogs v - Versions info
s - Strings x - Binary data
f - Font directories n - INFs
o - all others a - All (default)

Examples

rsrc notepad.exe                                                          - Show resource stats for notepad.exe
rsrc notepad.exe -t                                                      - Extract tokens to notepad.exe.rsrc
rsrc notepad.exe  -l 401 -r notepad.exe.rsrc             - Translate from US using Arabic tokens in
rsrc notepad.exe -d dmp -i im                                    - Hexdump of Icons and Menus to dmp


Advanced Mirroring topics

Additional Mirroring References:

What is 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 (currently implemented only for Arabic and Hebrew languages). Our Pseudo Mirroring tools are designed to do just that.

What mirroring does is flipping 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 app should still be easily mirrored from the resources by the localizers. Lctools mirrors compiled binaries from the resources. For example mirroring a window would 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 do 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.

An example of a mirrored Window:

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


Importing and exporting lc-files in LocStudio:

An important aspect of pseudo localization is the exchange of information between pseudo localization information (lc-files) and localization (LocStudio EDBs). For this purpose, LCTOOLS comes with a LocStudio Import/Export extensions. The information in the EDB can be checked/enforced in LocStudio through the module LocVer. For more information, see your LocStudio documentation. Also, check the WEB-site http://globalsys/pseudoloc for more information.

Below you can find information how to install and use the extensions and information on their limitations.

Installing and using extensions:

Follow the below steps to install and use the extensions:

  • Install LocStudio 4.51a QFE (the extensions likely work with other versions of LocStudio too, but as LCTOOLS releases with LocStudio files, care should be taken to use the matching version of LocStudio)
  • Install LCTOOLS, as part of the installation "lccmd -r" the LocStudio extensions lcgen.dll and converter.dll get installed.
  • Set a global variable BINARY_DIR pointing at the source path of the project (the same as the source path specified in the EDB), a local variable is not enough. In the below example the source path is c:\project\source

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

After installation, you will find add-ins "EDB->LC" and "LC->EDB" in LocStudio. The lc-files will be imported to and exported from a folder LCS under the location where the EDB can be found. The lc-files need to be in the structure as the files in the source folder. Files that don't contain instructions/comments will not have lc-files created.

Limitations:

There are several limitations in the import/export mechanism. The import/export works more as a side product from the rest of LCTOOLS instead of a LocStudio functionality only. This might be addressed in future releases.

  • All source files need to have English (US) resources (source language in LocStudio EDB)
  • You cannot specify the file parser to be used for a file. The default parser LocStudio associates with a file will be used. Extension lists for parsers are configurable though.
  • Instructions not in a format recognized by the extension will not be exported.
  • Comments in the EDB will need to be in the format {Comment="string"} to be exported.
  • LocStudio parser settings will not be used. The default parser settings configured for LCTOOLS will be used instead. This means that by default only one set of parser settings can be used. To use multiple sets of parser settings, additional scripting needs to take place.

How do the imported instruction appear in the EDBs:

Once you import your lc files into your EDB project, you will notice that the instruction set appears as follows. This format insures readability and makes it easier on the localizers to understand the added instruction:

  • {Placeholder="string"} (in the lc-file it is {PlaceHolder=x..y})
  • {Map="string"} (in the lc-file it is {Map=x..y})
  • {Comment="string"} (in the lc-file it is a regular string in the comment section)
  • {Adaptation}
  • {NoRules}
  • {Maxlength=x}
  • {RTL} (in the lc-file this is a substring in the comment string)
  • UsrSrcLock in the EDB are {Locked}-instructions in the lc-file

Note: when exporting lc-files, the instructions in the EDB need to follow the above format. Instructions not in that format will not be exported and saved in the lc-file.

For more information on how to configure LCTOOLS, see "Configuring LCTOOLS"


Miscellaneous utilities:

Several miscellaneous utilities have been developed to enhance the process around LCTOOLS. Please consult the WEB-site http://globalsys/pseudoloc to find available utilities.

The following utilities have been included in the release:

  • LC-file scan utility LCScan
  • PLP configuration utility PLConfig


New Page 1

LCSCAN:

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 list all map instructions for the maintenance of a mapping table. LcScan.exe contains also a few modes that you can use to batch change the contents of your lc-files.

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

LCSCAN -d|-u ReportFile
-d deletes entries listed in ReportFile from lc-files
-u updates comments listed in ReportFile from lc-files
ReportFile is a tab-separated report file created with lcscan

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

LcScan.exe -m foo.exe.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

Additionally, suppose you need to edit and standardize your comments in your lc tree for a certain rule. You can generate a tab separated text file called report.txt as describe above. Do a batch comments changes, and then you can update these changes back to your lc files using the following syntax:

LCSCAN -u report.txt


New Page 1

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 build 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.