Although SPSS translates the user interface and output to many languages, there is often a need for some output in other languages. The translator package provides tools for user-created translations.
This package, which can be downloaded from SPSS Developer Central, provides code that can read a set of translation definition files and replace text in pivot tables, headings, titles, and outline contents with the matching translation. Details of this process are explained in the documentation in the package.
What I want to write about here is the interesting situation of straddling extension commands and autoscripts that arises in this package.
My first approach was based on autoscripts. Autoscripts are Python or Basic scripts that are triggered by events such as the creation of a pivot table. The Base autoscript, if there is one, is called for every event, and other autoscript files can be attached to particular table types (See Edit>Options>Scripts for details.) Python autoscripts, though, are called by using import rather than by invoking a specific function in the script file.
That’s fine, but this package also provides an extension command named SPSSINC TRANSLATE OUTPUT. The extension command provides syntax that lets the job stream translate selected output when the syntax is executed rather than when a table is created. This is much easier to install compared to type-specific autoscripts. It also has the advantage of less overhead in many cases. An autoscript has to be loaded afresh each time the triggering event occurs. That means reloading the translation dictionaries each time. (The package documentation discusses how to minimize this startup cost.) The syntax version, though, can translate the entire output or the selected types in one invocation. It only loads the translation dictionaries once per command, although it will load incremental dictionaries as required when table types are encountered.
So mostly the same code needs to work for both autoscripting and the extension command. Since the extension command passes control to Python by calling the Run method in the module while the autoscript executes by using import, making both work is a little tricky.
Importing in Python actually means executing the contents of the imported module. Code inside a function or class would get defined but not executed by import as def and class are executable statements that define their objects. There is code needed for processing the parsed input for the extension command form, but we want to minimize the overhead of that when running as an autoscript.
The solution is simple. The file SPSSINC_TRANSLATE_OUTPUT.py has the Run method required for handling the parsed input and processes the syntax. It is not used when an autoscript is run. Run then calls code in translator.py, which is also the module used for autoscripting and has most of the code for this package.
When translator.py is imported, its last line,
dotrans(importing=True)
is executed, because it is outside any function definition. This starts the translation process.
When the extension command is run, it calls dotrans but does not set the value of the importing parameter. dotrans itself has a default value for this parameter of False. Combining this with the
SpssClient.GetScriptContext()
api allows dotrans to figure out what to do. When imported and it is an autoscript, it gets called and does the translation. When imported by the Run method in SPSSINC_TRANSLATE_OUTPUT.py, it is not executed until the Run method has set up the proper parameters and called dotrans.
There are other ways to solve this problem, but this solution shows some of the advantages of being able to use the same Python module both as an autoscript and as a collection of callable functions and classes.
