A file arrives with markup, repeated boilerplate, or a structure that memoQ’s normal import filters don’t handle the way your team needs. Someone cleans it by hand, another person imports it with different settings, and the project starts with two versions of what should have been the same source. A memoQ project template can move repeatable preparation into a defined workflow, but the template can’t invent the transformation program for you.
A project template is a saved collection of settings, commands, and scripts for creating projects in a repeatable way. memoQ supports templates for local and online projects, and its scripting features can transform a file before import and restore it after export. The key distinction is that a template configures when a program runs; you still need to write or acquire the program that performs the file changes. memoQ’s documentation describes the scripting workflow.
What a memoQ project template can automate¶
A memoQ project template is a reusable configuration for project creation, not a general-purpose file converter. It can hold settings for filters and import, configure scripts for document transformation, and define automated actions that run at project events. Projects created from the template inherit those choices, which helps a team apply the same setup repeatedly.
The distinction between settings and programs matters. A filter configuration tells memoQ how to read a file. A pre-processing program changes a file before memoQ reads it. Automated actions run memoQ tasks when a project event occurs, such as after document import. These mechanisms can be combined, but they solve different problems.
“Some documents must be transformed before you can import them into memoQ. This is done in project templates, through scripting.”
The quote describes a specific path: transformation is configured in the template, then a program changes the source into a form that can be imported. A template does not, by itself, remove unwanted text, convert a proprietary structure, or repair a malformed file.
memoQ’s documented transformation flow has five stages:
- Import the source file into the project workflow.
- Run a configured program to create a transformed file.
- Import the transformed file for translation.
- Export the translated transformed file.
- Run a program to restore the original format, when the workflow requires it.
That sequence separates the file a client supplied from the representation that memoQ translates. The first file might contain a format or structure that requires conversion; the transformed file is the one the import filter can handle. After translation, the restoration program can rebuild the delivery format from the translated representation.
The scripting feature is available only to projects created from templates. Editing a template doesn’t retroactively change existing projects: the template changes affect new projects. That makes template versioning and testing part of the workflow, not administrative cleanup to postpone until after launch. memoQ explains template editing and its effect on projects.
The supported-format documentation lists formats such as DOCX, XLSX, PPTX, PDF, IDML, HTML, JSON, Markdown, XML, YAML, XLIFF, and PO. Format support comes through import filters, and the available list can change with product releases. A file extension appearing in the supported list doesn’t guarantee that every file using that extension will import with the exact segmentation, structure, or text boundaries a particular job needs.
A useful mental model is a production recipe. The template records which settings and actions to apply; the script is the tool that carries out a custom conversion; the import filter reads the result. If a team treats all three as one feature, debugging becomes guesswork. If each component has a clear responsibility, the point of failure is easier to identify.
How pre-processing, filters, and import fit together¶
Import is the point where memoQ reads a source file and separates translatable text from the surrounding structure. A filter configuration tells memoQ how to interpret the file, extract text, and preserve formatting or other non-translatable content in a skeleton. The skeleton carries the structure needed to reconstruct the document after translation. memoQ’s document import guide explains the role of filters.
A filter is not the same thing as a script. Suppose a file contains fields, tags, or markup that should not appear as translation segments. A filter configuration can govern how memoQ handles the file during import. If the input needs to be changed before a filter can read it as required, pre-processing is the place for a separate program to make that change.
That division gives you a practical decision:
- If memoQ can read the file but needs different extraction or structure settings, review the import filter.
- If the file itself must be transformed before memoQ can read it, consider a pre-processing program.
- If memoQ can import it correctly but tasks need to follow import automatically, configure automated actions.
- If translation changes must be returned to a source system or original structure, plan the export and any restoration step.
A project template can map file extensions or file masks to import configurations. A mask is a pattern that matches a filename, such as *.json; rules can also include folder-qualified patterns. The order of the rules matters because memoQ stops at the first matching filter. The template settings documentation covers filter mappings and rule order.
| Template setting | What it controls | What to check |
|---|---|---|
| File extension or mask | Which files match a rule | Confirm the pattern matches the intended files and not unrelated ones |
| Import configuration | How memoQ reads a matching file | Check extraction, structure, and non-translatable content |
| Rule position | Which rule wins when patterns overlap | Put specific patterns before broader matches where appropriate |
| XML configuration | How memoQ interprets an XML document | Test the selected configuration against representative XML |
| Embedded content settings | Whether embedded images or objects are imported | Decide whether that content belongs in the translation workflow |
When no filter configurations are specified in a template, memoQ uses its default filter configurations for projects created from that template. Default behavior can be useful for straightforward files, but it isn’t a substitute for checking what gets extracted. memoQ notes that default import settings can produce unexpected results for some plain-text and XML documents. The import settings documentation describes differences by document type.
XML needs particular attention because XML is a container structure, not one uniform content type. A template can use an Auto-picked XML configuration, which lets memoQ select a suitable configuration based on document type information. That can reduce manual selection, but a team should still confirm that the chosen configuration extracts the intended text and handles tags and attributes as expected. memoQ’s template settings documentation describes Auto-picked XML configurations.
Template settings can also specify whether embedded images and embedded objects are imported for a filter configuration. The choice affects the scope of the work: a document may contain text that can be translated alongside objects that need a separate process or should remain untouched. Teams should decide what belongs in the project before relying on a template to import files automatically.
Content-connected projects have an extra interaction to consider. Template filter configurations take precedence over filter configurations supplied by a content connector. A connector may deliver content with its own settings, but the template’s filter rules win where they apply. Test that combination rather than assuming the connector’s configuration will control import. memoQ documents the precedence rule in template settings.
A pre-processing program also has to agree with the filter rules. If the program produces a file with a different extension, the template needs a matching rule for that output. If the program leaves the original extension in place while changing the structure, the existing filter may still match, but it may no longer be the right configuration. The program’s output and the template’s filter map should be designed as one interface.
How to configure a template workflow¶
Build the workflow around a known input and a known output. The purpose isn’t to automate every possible file; it’s to make one repeated preparation path predictable enough that a project manager can tell what will happen before the project is created.
1. Define the file change¶
Write down what the source file contains, what memoQ should receive, and what the delivery needs to look like. Be specific about which content should be translated, which content should remain unchanged, and whether the original file structure must be restored after export.
A useful specification distinguishes transformation from extraction. “Remove the header fields before translation” describes a change to the file. “Don’t extract this XML attribute” describes import behavior. The first may require a program; the second may be handled by the import configuration.
2. Decide whether a script is necessary¶
Try to solve an import problem with an import configuration when the file can remain structurally unchanged. Use pre-processing when a separate conversion is genuinely required before import. This keeps the automation smaller and makes errors easier to locate.
memoQ’s built-in Find and Replace tool is presented as an option for preparing or touching up text documents. Custom document changes need a program supplied by the user: memoQ doesn’t include programs that perform arbitrary document transformations. The scripting documentation explains both the requirement and the Find and Replace option.
“You need to write or acquire the program: memoQ doesn’t come with programs that make the necessary changes to documents or to the project.”
That boundary helps set the scope. A project manager can configure when a script runs in the template, but someone must still create and maintain the script. The script needs a defined input, a predictable output, and an error path the team understands.
3. Configure the pre-processing and post-processing path¶
Set up the transformation in the project template and decide whether the workflow also needs a restoration program after export. A restoration step is needed when the translated transformed file must be converted back to the original format or structure. If the transformed file is already an acceptable delivery format, restoration may not be part of the job.
A practitioner article describes the tool interface as passing full input and output paths through {InputFilePath} and {OutputFilePath}. The article also says the automation processes files one at a time, even when several files are imported together. Treat those implementation details as version-sensitive and test them against your current memoQ installation before building a production script. The practitioner walkthrough describes its implementation.
The one-file-at-a-time behavior has a practical implication: a batch import doesn’t necessarily mean that one script invocation receives a folder of files. A program should work correctly on an individual input and produce the expected output for that input. Test multiple files together as well as one file alone, since both workflows matter to project managers.
4. Match the transformed file to a filter configuration¶
Add a filter configuration for the file that the pre-processing program creates. Check its extension or mask, confirm the correct import configuration is selected, and examine the rule order. A correct script paired with a mismatched filter can still result in failed or incorrect import.
For XML, confirm whether a specific configuration or Auto-picked XML configuration fits the transformed document. For files with embedded images or objects, confirm whether the template should import them. Keep the file type, filter rule, and extraction behavior documented together so that later changes don’t break the relationship silently.
5. Configure automated actions separately¶
Automated actions handle memoQ tasks tied to project events; they don’t replace file transformation. A template can assign actions to triggers such as After document import. The documentation’s example assigns pre-translation and then project analysis to that trigger, and describes locking exact matches and context matches. Multiple tasks attached to a trigger run in their listed order, which can be changed in the template editor. memoQ’s automated-actions guide describes the triggers and task order.
Keep the sequence intentional. An action that analyzes the project before the relevant pre-translation step may produce a different result than an action that analyzes afterward. The template editor lets you order tasks, so write down the desired sequence and compare it with the saved configuration.
Other documented examples include X-Translate after document reimport, followed by pre-translation and analysis after that update. The guide also describes automatic export at project wrap-up or workflow completion, depending on whether the project is local or online. Those are examples of project actions, not replacements for a script that changes a file’s structure.
6. Test the whole cycle, not just the import¶
Use representative files, including one that is likely to reveal edge cases in the source structure. Check that the script creates the expected transformed output, the filter extracts the intended text, and the translated export can be restored if restoration is part of the workflow.
A good test checks both what appears and what doesn’t. Confirm that intended text becomes translatable, that protected content isn’t accidentally extracted, and that the output retains the required structure. Then test a case where input is missing, malformed, or doesn’t match the expected pattern. The goal is to make failure visible rather than silently creating an incomplete project.
The project-from-template wizard imports documents using settings already defined in the template; it doesn’t offer import customization at that stage. If a file imports incorrectly, you can reimport it after project creation with adjusted settings. That gives a recovery path, but it doesn’t remove the need to correct the template if the same input will recur. The project-from-template guide explains import behavior in the wizard.
When automation is useful, and when it isn’t¶
Pre-processing makes sense when the same type of source needs the same transformation before memoQ can import it as intended. A repeatable conversion can reduce one-off manual changes and make the project setup more consistent. The value comes from repetition and a stable input-output relationship, not from adding a script to every file type.
Common candidates include files that need a predictable structural adjustment before import, or a workflow where the translated result must be converted back to a defined original form. A script can also help when a team has settled on a consistent intermediate representation and wants a template to apply it to new projects.
A template is less useful when every input requires a different editorial decision. If someone must inspect each file and decide what to remove or preserve, a fixed script can encode the wrong assumption. In that case, a human preparation step followed by a stable import configuration may be safer than pretending the job is uniform.
Pre-processing isn’t the right first fix when the problem is simply that memoQ is using the wrong import settings. A filter configuration exists to control how memoQ reads a supported file. Start with the filter if the file itself is valid and the mismatch concerns extracted text, formatting, tags, or embedded content. The document import guide explains that settings differ by document type.
A second alternative is to leave the source unchanged and use a review or preparation step outside the template. That approach makes sense when the change is one-off, when a script would be more complex than the task, or when the file has unusual risks that require a person to inspect it. Automation is not automatically safer than a manual check; a repeatable mistake is still a mistake.
In a typical document-translation workflow, a file may also need preparation that has nothing to do with memoQ’s import engine: a scanned PDF may need OCR, for example, because the page is an image rather than selectable text. This guide to scanned PDF import in memoQ explains why a scan can fail where a text PDF imports normally. ChatsControl offers a separate document-translation workflow that reads scanned PDFs and rebuilds a formatted Word file, but it isn’t a CAT tool or a replacement for memoQ’s project-template scripting. ChatsControl is relevant when the immediate problem is handling a scan, not when a team needs translation-memory workflows or memoQ project automation.
A project template is useful when the team can explain the expected input, transformation, import configuration, and output without relying on undocumented assumptions. If those details change for every file, keep the decision visible and handle preparation case by case. For adjacent workflow questions, this practical file-preparation guide covers broader checks before a document reaches the CAT tool.
Security and maintenance for scripted templates¶
A local template and an online template don’t have identical setup requirements. Online-project templates are created and edited on the server, and project-template permissions are required to use a template on memoQ TMS. Confirm who can edit the template and who can create projects from it before relying on a shared server workflow. memoQ’s project-template documentation covers online templates and permissions.
Online scripting also has a security boundary. Custom code execution on memoQ TMS is disabled by default and must be explicitly configured. memoQ’s documentation warns that enabling script execution creates risk, because a service shouldn’t run scripts when the scripts aren’t needed. The TMS configuration guide explains the security setting.
“Custom code execution is disabled by default, for a good reason: you must not allow a service to run scripts when you do not need those scripts.”
The warning is practical, not a reason to avoid every script. Enable execution only when the workflow needs it, and make the decision part of server administration rather than an informal project-level workaround. Review the program’s purpose, access, expected inputs, and output behavior before permitting it to run.
The TMS documentation describes running scripts under a virtual service account and says not to use a built-in account. That choice matters because the program should have a deliberately scoped identity rather than inheriting broad access by default. An administrator should review the account and execution configuration alongside the script itself.
The same documentation describes a default custom-program timeout of 300 seconds, or five minutes, configurable in the Deployment tool. The timeout may be changed by an administrator, so treat it as a setting to confirm on the server, not a guarantee that every script has the same runtime allowance. A transformation that needs more time than the configured limit may fail before memoQ can import its output. The TMS guide covers the timeout setting.
The TMS configuration can also restrict executable types to batch, CMD, and PowerShell scripts rather than EXE files. The documentation presents that restriction as a way to limit vulnerability exposure. Teams using online automation should confirm which executable types their administrator permits and choose a workflow that fits the configured policy.
Template maintenance matters because changes affect newly created projects, not ones already underway. Record what the script expects, which filter rule handles its output, and what a successful run should produce. Before saving a template change, review the full settings overview, as memoQ recommends. A small change to a file mask or rule order can affect future projects without changing the source files themselves.
Common failure points and how to diagnose them¶
Most template problems become easier to trace when you separate four questions: did the program run, did it create the right output, did memoQ select the intended filter, and did the filter extract the right content? Checking each stage in order is more useful than changing several template settings at once.
The script ran, but memoQ didn’t import the transformed file. Check the output path and file extension, then compare the output with the template’s filter masks. A successful transformation doesn’t guarantee a matching import rule. Confirm that a broad rule isn’t catching the file before the intended specific rule, since memoQ stops at the first match.
The transformed file imports, but text is missing or extra content appears. Review the filter configuration and the file structure. Default settings can produce unexpected results for some plain-text and XML documents, so inspect what memoQ extracted rather than assuming that a successful import means the extraction is correct. memoQ’s import settings guide notes these format-specific differences.
The wrong XML configuration is selected. Check whether the template uses Auto-picked XML or a specific configuration, and test it against the actual document type information. A filename ending in .xml doesn’t by itself tell you which content should be translatable. Confirm tags, attributes, and embedded content against the intended translation scope.
A content connector’s settings appear to be ignored. Review the template’s filter configurations first. Template filter configurations take precedence over filter configurations from a content connector in content-connected projects. If the template defines a matching rule, the connector’s configuration won’t take precedence for that file. memoQ documents this rule in the template settings guide.
A project created from the template has the old behavior. Check when the project was created and when the template was edited. Template changes affect newly created projects, not existing ones. Reimporting with adjusted settings can correct a file in an existing project, but a template change is needed for future projects created from the updated configuration. memoQ’s template guide describes the scope of saved changes.
The online script doesn’t run. Ask the memoQ TMS administrator to check whether custom code execution is configured and whether the chosen script type is permitted. The feature is disabled by default, and TMS configuration may restrict which executable types can run. Don’t try to work around a server policy by moving the script into an unreviewed project process.
The script works for one file but fails during a multi-file import. Test whether the program expects a whole batch or one input at a time. A practitioner account of the memoQ tool interface says files are processed one at a time, including when several files are imported together. Because that detail can depend on version and implementation, validate it against the memoQ version in use. The practitioner article describes the behavior.
An automatic action runs, but in the wrong sequence. Open the automated-actions settings and review the order of tasks under the trigger. memoQ runs tasks in their listed order, and the template editor lets you change that order. Check that import, pre-translation, analysis, reimport-related actions, and export occur in the sequence your team expects. The automated-actions guide explains task ordering.
The best diagnostic habit is to preserve a known source file and compare it with the transformed output, the imported project content, and the exported result. Each comparison answers a different question. When a failure appears, change one component at a time and rerun the same test file; changing the script and filter configuration together makes it harder to know which change fixed or caused the result.
FAQ¶
Can memoQ run a script before importing a document?¶
Yes. A project template can configure a program to transform a source document before memoQ imports the transformed file. memoQ doesn’t supply a custom transformation program, so you must write or acquire one. The scripting documentation explains the pre-processing workflow.
How do I automate file preparation before import in a memoQ project template?¶
Configure the pre-processing step in the template, provide a program that creates the required transformed file, and map that output to an appropriate import configuration. Then test the transformation, import, translation export, and any restoration step on representative files.
How do memoQ template filter configurations control document import?¶
Template filter configurations map file extensions or masks to import configurations. memoQ stops at the first matching filter, so the order matters when rules overlap. The selected import configuration determines how memoQ reads the document and extracts its translatable content. See memoQ’s template settings guide.
Does memoQ require post-processing after pre-processing a file?¶
Not in every workflow. Post-processing is useful when the translated transformed file must be restored to the original format or structure. If the translated file is already suitable for delivery, the workflow may not need a separate restoration program. memoQ documents pre-processing and post-processing as parts of the template scripting workflow.
Can I customize import settings in the project-from-template wizard?¶
No. The project-from-template wizard uses the import settings already defined in the template and doesn’t offer customization at that stage. A file that imported incorrectly can be reimported after project creation with adjusted settings. memoQ’s project creation guide describes the wizard behavior.
Can I use scripts in an online memoQ project?¶
Online-project scripting depends on custom code execution being configured on memoQ TMS. The setting is disabled by default, and memoQ warns that allowing scripts creates a security risk. Ask the server administrator to review the execution configuration before using a scripted workflow. Read the TMS custom-code configuration guide.