Over time, we observed that many customers tend to have similar problems in various fields that could be solved by software. This resulted in a set of solutions that address common challenges in Technical Documentation. Some of these are rather for one-time use (for example, during migration, or for a single clean-up action. Others are software tools for permanent use for which we sell licences.
Management of supplier documentation
Particularly in the plant engineering branch, but also in other branches of industry, there is the need to collect documentation from suppliers and integrate it with documentation of in-house products, typically controlled by a parts list from the ERP system. Together with reinisch, we built a web-based, standard solution that addresses these requirements.
The Supplier Documentation Management System (SDMS) is available as standard software and can be hosted by yourselves or by us on standard Linux platforms. It reads parts lists from the ERP, and automatically calculates documentation requirements based on configurable rules. These can, for example, use target language, target market or component type as parameters to select the rule set(s) to be applied.
The requests can be reviewed and edited by the purchase department employees before submitting them. Once submitted, registered suppliers are notified by email and are asked to upload defined documentation units like:
- Data sheets
- Installation instructions
- User's manual
The system also defines the language(s) and format(s) to be uploaded, according to the rules, as well as deadlines. If deadlines are approaching or even exceeded, the system notifies the suppliers by email, containing links directly leading to the requests to be completed.
The system integrates the project manager role for review and release tasks as well as a documentation service provider role for basic review and organizational tasks.
The entire data collected can, out of the box, be exported into a configurable folder hierarchy. A programming interface allows to attach alternative output targets, like Content Delivery Portals or Service Management Systems.
Translation Memory clean-up and quality control
Translation Memory Systems can leverage efficiency gain by automatic translation of known segments only if there is exactly one translation of the segment per target language. When we analyze TMs from customers that have grown over time, we often find ambiguities of the type that there are multiple translations for the same source segment and target language. If the TM finds such a segment, it can't automatically decide which translation to use.
Analyses of such real-world TMs rarely reveal no ambiguities at all, typically, 2-10% of the segments have multiple translations. Commonly, they are almost identical and just differ in additional blanks, different wording in the same sentence etc.
It is possible, but difficult to find such ambiguities in the common TM software systems. To make this task easier, we built a standard solution called Translation Memory Quality Editor (TMQE), together with reinisch, that reads TMX exports from TM systems (currently supported: Trados, Transit, Across, but basically it works with all TMX exports). It searches the TMs for ambiguities, lists them in a table and allows the users to edit them.
For an ambiguous segment, users can choose to:
- Make one of the existing translations the standard.
- Choose none of the existing translations, but insert a new one.
The segments that were edited are highlighted in green, if an existing translation was chosen or yellow, if a new one was provided.
The work status can be saved any time. When done, the result can be exported to TMX that can be imported back into the TM system.
Apart from ambiguities, TMQE can check by rules based on Regular Expressions. This allows custom rule configuration for checks like "blank before punctuation in French" or "no blank before punctuation for non-French languages".
Configurable visualization of ontology data
We provide consultancy and other services on Ontology Databases. In complex multi-system environments, we also recommend using an Ontology Database for modelling purposes.
On the market, there are powerful commercial Ontology Databases, but their price scope is beyond using them as a temporary modelling tool. We typically use the Open Source solution WebProtégé for this purpose. However, it has only rudimentary export and visualization capabilites.
To fill this gap, we built a solution that reads OWL files exported from an Ontology Database and applies rules to create filtered diagrams of certain aspects of the ontology. Configuration exposes a broad range of visual styles, like shapes, sizes and colors. The output is written as source data for the Open Source yEd graph editor.
A programming interface allows to create filtered output in other target formats, and not only for visualization purposes.
Migration framework for semi-automatic source to target conversion
When introducing a system like a CCMS or moving from one to another, it is often necessary to convert the data into the target system's structure. This involves converting the source to the target format, applying heuristics, for example, for mapping Microsoft Word paragraph formats to DITA elements. Migration also involves modularization, application of semantics and re-use.
The entire migration is a process that integrates manual and automatic steps, not in the way that automation creates output and then the authors work them over, but rather as a sequence of manual and automatic steps, for example:
- Automatic: conversion of Microsoft Word documents to DITA, breaking up to modules by rules.
- Manual: merging, splitting and editing the modules.
- Manual: application of semantics, like deciding, a module will be a DITA task.
- Automatic: Recreating the module from the source based on the semantic logic.
- Manual: re-using modules instead of creating duplicates.
- Automatic: extracting metadata from the content.
- Manual: editing or completing the metadata.
- Automatic: import into the CCMS.
The integration of manual and automatic steps is handled by our Conversion Framework Tool. Structural conversions can be coded in XQuery, allowing easy access and complex logics and heuristics. Programming interfaces allow to attach custom code. To efficiently use the tool, some XQuery and other coding is required, but considering the amount of data typically affected, it helps saving a large amount of manual copy / paste work and avoiding errors.
DITA-OT based publication from PIM
Typically, DITA Open Toolkit is used to publish modular manuals to diverse target formats. A key advantage of DITA Open Toolkit is the flexibility, allowing simple changes like borders, margins and fonts by accessible parameters, while giving style sheet designers the possibility to replace any of the standard templates by custom XSL. This combination of accessibility and power makes DITA Open Toolkit a good approach for other data sources as well.
We have built a model case, together with a partner, that consists of two parts:
- Product data and associated documentation managed in the Open Source PIM system pimcore is automatically exported to DITA, containing attributes controlling the layout rules to be applied.
- A matching DITA Open Toolkit PDF style sheet to publish the documentation.
While we have the pimcore based solution ready to use, it can be adapted to other data sources with moderate effort.
What we can do for you
- Provide consultancy if you have any of the requirements addressed above, or other requirements that can be solved by software.
- Suggest the best solution for your case, including third-party products available on the market.
- Adapt the standard software matching your needs, and help you using it.