RWS · cornea-robert · Jun 25, 2026 · Jun 25, 2026
diff --git a/apiconcepts/projectautomation/about_packages.md b/apiconcepts/projectautomation/about_packages.md
@@ -1,9 +1,7 @@
-About Packages
-======
+# About Packages
 This section explains how packages are used in order to send around project files and related information to other participants in a localization project (e.g. from project managers to translators).
 
-Overview
------
+## Overview
 The initial phase of a localization project typically consists of a number of automatic steps in which the project files are prepared for translation. When this process is completed, the files will be present in SDLXliff format, with all available translation leverage applied. At this point, they are ready to be translated.
 
 Since the person who prepares the project will typically not be the person who translates and reviews the files, the project files will have to be sent to the translator, who will perform the actual translation work. As explained in [About Tasks](about_tasks.md), a human step in the workflow, like translation, is represented by a manual task.
@@ -42,8 +40,7 @@ For example:
 
 When creating a return package, the system is flexible when it comes to the files to include in that return package. The return package does not necessarily need to contain the exact same set of files that was received in the project package. The user can create partial return packages as and when required, and can also combine files received through multiple project packages in a single return package. The only limitation is the fact that all files in a return package need to belong to the same project.
 
-Project Packages
-----
+## Project Packages
 A project package contains the following information:
 
 * A single manual task.
@@ -54,8 +51,7 @@ A project package contains the following information:
     * AutoSuggest dictionaries.
 
 
-Return Packages
-----
+## Return Packages
 A return package contains the following information:
 
 * The manual tasks for which the return package contains files.
@@ -64,15 +60,13 @@ A return package contains the following information:
 
 A return package does not contain any translation memories. The translated files contained in the return package are generally used to update the main and/or project translation memories.
 
-API Overview
------
+## API Overview
 There are two parts of Project API related to working with packages, serving two main scenarios:
 
 1. **Working with packages within the context of a Project API-based project**: The Project Automation API provides a high-level API for creating and opening packages within the context of a project. See [High-level API](#high-level-package-api).
 2. **Working with packages outside of the context of a Project API-based project**: You can manipulate packages independently of a Project API-based project using the Low-level Package API
 
-High-level Package API
------
+## High-level Package API
 
 When you have an existing Project API-based project, you can create packages from this project using the high-level package functionality integrated into the Project Automation API. The Project Automation API provides the following package-related functionality:
 
@@ -83,12 +77,11 @@ When you have an existing Project API-based project, you can create packages fro
 Each of the methods above returns an object that derives from `IPackageOperation`. This object represents the package operation and can be used to monitor that operation though events and to access the results when the operation is completed. After calling the above methods and attaching the relevant event handlers, call **Start** to start the operation.
 During package import operations, certain situations may result in callbacks being invoked to allow external control of the package import process. An example of such a situation is when the package contains files which are older than the files that already exist in the project. A callback allows the calling code to decide whether the file should be overwritten. When doing a package import through Var:ProductName, this results in the user being asked a question. The callback are accessed through the `IPackageImportEvents` interface.
 
-Low-level Package API
-----
+## Low-level Package API
 > [!NOTE]
-> This part of the package API functionality will significantly change going forward. The idea is to produce a separate package API and package format, which is entirely independent of the Project Automation API and the desktop project file format.
+> This part of the package API functionality will significantly change going forward. The goal is to produce a separate package API and format, entirely independent of the Project Automation API and the desktop project file format.
 
-The Project Automation API also provides functionality to create and open packages independently from a Project API-based project. Use this functionality when creating packages containing content originating from external systems or to open packages for other purposes than importing their content into a Project API-based project.
+The Project Automation API also creates and opens packages independently of a Project API-based project. Use this when packaging content from external systems or when opening packages for purposes other than importing into a project.
 
 The package functionality is implemented as a special type of desktop project, a **package project** (see **IPackageProject**). As a result the API to be used for creating and manipulating package files shares most of its functionality with the API used for creating and manipulating projects.
 
@@ -104,8 +97,7 @@ The creation of project packages in Var:ProductName is fully wizard-based. Users
 
 The screenshot above highlights the various options that are available when creating a project package.
 
-See Also
-----------
+## See Also
 [Creating a Project Package](creating_a_project_package.md)
 
 [Creating a Return Package](creating_a_return_package.md)

diff --git a/apiconcepts/projectautomation/about_project_files.md b/apiconcepts/projectautomation/about_project_files.md
@@ -1,29 +1,25 @@
-About Project Files
-====
-This section gives an overview of the types of files that can be part of a localization project and explains how the Var:ProductName models these.
+# About Project Files
+This section provides an overview of file types in a localization project and explains how Var:ProductName models them.
 
-Project Files
-----
-As mentioned before, the main type of files that play a part in a localizable project are files that should be translated. From now on we will call these files *translatable files*. To be more specific, we define translatable files as files that can be processed and translated using RWS's tools, more specifically files from which the translatable content can be extracted and manipulated through the *File Type Support Framework*. For more information, see [Translatable Files](#translatable-files).
+## Project Files
+The primary files in a localizable project are those that require translation—referred to here as *translatable files*. Specifically, translatable files are those from which the File Type Support Framework can extract and manipulate content. For more information, see [Translatable Files](#translatable-files).
 
 Certain project types may consist of a large quantity of translatable files, which each only contain a small amount of content, for instance a website translation project, or files that were exported from a content management system. To facilitate processing these types of projects, the Var:ProductName offers the ability to merge a number of these files into a single translatable, so that it can be processed and edited as one big unit. Merging files could happen at various stages in the project: upfront as part of project preparation, or on a more ad-hoc basis by a translator who wants to edit multiple files at once. For more information, see [Merged Translatable Files](#merged-translatable-files).
 
-There are files that need to be localized, but for which RWS does not provide a file type definition that can extract translatable content. An example of these are graphics files that contain text. Those files are called localizable files, which indicates that they can be localized as part of the project, but not through the standard workflow with RWS tools, for instance with a graphics editor. For more information, see [Localizable Files](#localizable-files).
+Some files require localization but lack an RWS file type definition capable of extracting translatable content. Graphics files containing text are a common example. These *localizable files* can be localized within the project, but outside the standard RWS tool workflow—for instance, using a graphics editor. For more information, see [Localizable Files](#localizable-files).
 
-Another type of files are *reference files*. These are files that need to be part of the project, but that are not expected to be modified during translation, for instance external graphics that are required to preview an HTML file. For more information, see [Reference Files](#reference-files).
+*Reference files* belong to the project but remain unmodified during translation—for example, external graphics required to preview an HTML file. For more information, see [Reference Files](#reference-files).
 
-Sometimes, processing a translatable file, produces additional files that are linked to that translatable file, and that need to travel throughout the remainder of the translation process. We call those files *auxiliary files*. An example of this is a PDF preview file that is generated for a translatable file, and that can be used for commenting. For more information, see [Auxiliary Files](#localizable-files).
+Processing a translatable file sometimes produces additional linked files that must accompany it through the rest of the translation process. These *auxiliary files* include items such as PDF preview files generated for commenting. For more information, see [Auxiliary Files](#localizable-files).
 
-File Object Model
----
-**IProjectFile** is the base for all files that can be part of a project and provides common properties and functionality such as the ability the download it, etc.
+## File Object Model
+**IProjectFile** serves as the base for all project files and exposes common properties and functionality, such as downloading.
 
 An **ILanguageFile** is a project file that is associated with a specific project language, which could be a source or a target language. Initially, when a file is added to the system, it is typically a source language file. The source language file then goes through some source language specific processing, for instance, conversion into the SDLXliff file format and segmentation. At some point, a target language file is created for every target language in the project, after which target language- specific processing takes place, such as translation memory analysis and translation. All types of project files are language files and are therefore associated with a specific project language. Every source language file has the ability to find its related target language files and vice-versa.
 
-All types of project files that can be modified after they have been added to the project are versioned, i.e. a full version history is maintained for these. This includes all files except reference files.
+The system versions all modifiable project files, maintaining a full version history. Reference files are the exception.
 
-Translatable Files
------
+## Translatable Files
 Translatable files are files that can be processed and translated using RWS's tools, i.e. for which a file type definition exists in the  File Type Support Framework. As a result, translatable files can carry some additional information:
 
 * **File Type**: Identifies with which file type definition this particular file will be processed. It also specifies any other file-type specific aspects, such as how to preview this file, how to verify the content of this file, which QuickInsert (=special characters or tags that can be inserted during editing) items are valid for use, etc.
@@ -34,20 +30,17 @@ Translatable files are files that can be processed and translated using RWS's to
 
 Translatable files are represented by the `ITranslatableFile` interface in the object model.
 
-Merged Translatable Files
------
+## Merged Translatable Files
 A merged translatable file is a translatable file which is created by merging a number of translation files into one. The Var:ProductName provides capabilities to define which files should be merged into one. Subsequently, the files can actually be merged by creating one consolidated SDLXliff file containing the merged content of all the files. After working on the merged file, it can be split into single files again. Apart from the fact that you can merge and split a merged translatable file, it is just a normal translatable file, and can be manipulated as such.
 
 Merged translatable files are represented by the ```IMergedTranslatableFile``` interface in the object model.
 
-Localizable Files
------
+## Localizable Files
 Localizable files are files that need to be changed as part of the localization process, but that cannot be processed using standard RWS tools (i.e. the File Type Support Framework). As a result of that, localizable files do not have analysis or confirmation statistics. Other than that, localizable files are changeable, versioned files.
 
 Localizable files are represented by the ```ILocalizableFile``` interface in the object model.
 
-Reference Files
-----
+## Reference Files
 Reference files are files that need to be part of the project, for instance for preview reasons, but that can be changed as part of the project. Reference files are language files, which means they are associated with a particular project language.
 
 Reference files are represented by the `IReferenceFile` interface in the object model.
@@ -56,8 +49,7 @@ Reference files are represented by the `IReferenceFile` interface in the object
 
 The screenshot above illustrates how project files are selected in Var:ProductNameWithEdition.
 
-See also
--------------
+## See also
 [Adding Files and Folders](adding_files_and_folders.md)
 
 [Creating a Merged File](creating_a_merged_file.md)

diff --git a/apiconcepts/projectautomation/about_project_translation_memories.md b/apiconcepts/projectautomation/about_project_translation_memories.md
@@ -1,9 +1,7 @@
-About Project Translation Memories
-=====
+# About Project Translation Memories
 This section explains what project translation memories are, how they are modeled in the Project Automation API and how they should be used in the recommended workflow.
 
-Project Translation Memories
-------
+## Project Translation Memories
 As explained in the [Project Configuration](project_configuration.md) section, every language direction in a project can have one or more translation providers associated with it. The primary type of translation providers are translation memories, which are used within the project to look up translations. Any new translations created by the user are also added to one or more of these translation memories. The user can specify which of the translation memories in the list are updated.
 
 One issue is that there is no control over which translation units end up in the translation memories. During the course of the project, unreviewed, potentially invalid content ends up in there with no easy way to clean this up. The solution to this is the use *project translation memories*: a project translation memory (project TM) is a translation memory that is created specifically for use within one project, and that is discarded once the project is complete. At the end of the project, when all the files have been translated, reviewed and signed off, all translations within these files are added to the main translation memories (we call the translation memories that are added to a project the "main translation memories" to make a clear distinction with the "project translation memories"). Doing this ensures that the only content that ever ends up in the main translation memories has been reviewed, and that any work in progress or invalid content is kept out of the main translation memories and effectively only occurs in the project translation memories which can be discarded at the end of the project.
@@ -18,6 +16,5 @@ Both file- and server-based project translation memories are supported. Server-b
 > 
 > The use of project translation memories is entirely optional. Users can choose not to use project translation memories for a project.
 
-See Also
--------
+## See Also
 [Project TM Creation Settings](project_tm_creation_settings.md)
diff --git a/apiconcepts/projectautomation/about_projects.md b/apiconcepts/projectautomation/about_projects.md
@@ -1,17 +1,16 @@
-About Projects
-====
-This section provides a high-level overview of projects in the Project Automation API context.
+# About Projects
+This section provides a high-level overview of projects within the Project Automation API.
 
-We define a localization project as the data, resources and process required to localize a set of source files in a given language, the source language, into one or more target languages. As implied in this, the main inputs to a translation project are:
+A localization project encompasses the data, resources, and processes required to localize source files from one language (the source language) into one or more target languages. The main inputs to a translation project are:
 
 * **The documents to translate**: Files to translate are the main input, although various other file types come into play in real-life project, as explained in the About Project Files section.
 * **The source language**: This is the language of the files that need to be translated. At the moment, projects only support one source language. At the same time, files with mixed-language content are not supported either.
 * **The target languages**: A single project models the translations of files into one or more target languages. The main reasons for this are the usefulness of being able to manage this translations together and the fact that some processing (manual and automated) on the source language content can be shared between these translations.
 
 
-Apart from the files to translate and the language information, an important aspect of a project is configuration. This configuration ranges from which translation memories and termbases to use for the project, over settings for specific automated steps in the project preparation process or workflow, up to custom settings for integration purposes with external systems. For more information, see [Project Configuration](project_configuration.md).
+Beyond files and language information, project configuration plays a critical role. Configuration covers translation memories and termbases, settings for automated preparation steps, and custom settings for external system integration. For more information, see [Project Configuration](project_configuration.md).
 
-Apart from data and settings, the process followed during the execution of a localization project is an important aspect. The Project Automation API addresses this through the concepts of tasks, which can be automated (file preparation, translation memory analysis) as well as manual (translation, review). Tasks can be run in an automated fashion, driven by a workflow, or in a more ad-hoc way.
+The execution process of a localization project is equally important. The Project Automation API models this through tasks—both automated (file preparation, translation memory analysis) and manual (translation, review). Tasks can run as part of a workflow or on an ad-hoc basis.
 
 Another important aspect of translation projects is their distributed nature. Frequently, the participants in a single localization project are spread across the globe and vary in size from large corporations, who produce content, over language service providers, who provide localization project management to freelance translators and reviewers. This aspect of localization projects is commonly referred to as the localization supply chain. The Project Automation API provides a way to deal with this, through the concept of packages: work (manual tasks) can be sent across the localization supply chain bundled into packages, containing for instance files to translate together with configuration and settings. These packages can be produced and opened by tools like Var:ProductName. For more information, see [About Packages](about_packages.md).