Topics

Translation management with file-system-based editing/publishing #translation


Radu Coravu
 

Hi Frank,

Replying to you on the new group.

If you are using Oxygen XML Editor, we created some time ago a translation package builder add-on, it has a readme explaining how it should be used:

https://github.com/oxygenxml/oxygen-dita-translation-package-builder

Regards,

Radu

Radu Coravu

Oxygen XML Editor


On 11/8/19 4:09 PM, Frank Dissinger frank.dissinger@... [dita-users] wrote:


Hi list,


I am working with dita files on the file system level, without the use of a CMS. I edit with FrameMaker, publish PDF using DITA-FMx and publish online help from the command line using DITA-OT+plug-ins+scripts.


Until now I have written everything in English, now I also have to create German translations for some projects. This means that I'll have to remember which English files have German counterparts and whether the German translation needs to be updated or not.


Are there any tools or DITA-OT plug-ins for this purpose --- which would still allow me to edit and publish in the way I do now? I do not want to use a CMS system. (I already evaluated DITAToo and VirtualDrive, but this solution did not work out as expected.)


Thank you.


Frank


--

Frank Dissinger

Documentation Manager

....................................................................

CGS Publishing Technologies International GmbH

Email frank.dissinger@... | Web www.cgs-oris.com

Address Kettelerstr. 24 | D-63512 Hainburg | Germany

Phone +49 6182 9626-27 | Fax +49 6182 9626-99

Commercial register Offenbach, HRB no. 21495

Managing directors Bernd Rückert, Andreas Kämmerer, Christoph Thommessen



__._,_.___

Posted by: Frank Dissinger <frank.dissinger@...>



__,_._,___

-- 
Radu Coravu
Oxygen XML Editor


 

Hi Frank,

your requirement is a translation management topic. Not sure how or even why DITA-OT could come in for this.

Translation Management is a core capability of any CMS and one main reason why companies decide for a CMS, especially when there is more than just one target language. XML Documentation for Adobe Experience Manager, for example, keeps always track of your source files and your translations and will monitor which files got out of sync in the target language(s) when you changed something, or if you added new contact.

However, as you have just one single target language, maybe just Excel is enough? A simple table with the file names in one column, and then a few more columns for "translated", "needs translation update" status (like "in translation") might be already enough.

Cheers,
*Stefan.


Frank Dissinger
 

Thank you, Radu.
I'll take a look at the add-on.

Regards,
Frank

Am 09.11.2019 um 19:15 schrieb Radu Coravu:

Hi Frank,

Replying to you on the new group.

If you are using Oxygen XML Editor, we created some time ago a translation package builder add-on, it has a readme explaining how it should be used:

https://github.com/oxygenxml/oxygen-dita-translation-package-builder

Regards,

Radu

Radu Coravu

Oxygen XML Editor


On 11/8/19 4:09 PM, Frank Dissinger frank.dissinger@... [dita-users] wrote:


Hi list,


I am working with dita files on the file system level, without the use of a CMS. I edit with FrameMaker, publish PDF using DITA-FMx and publish online help from the command line using DITA-OT+plug-ins+scripts.


Until now I have written everything in English, now I also have to create German translations for some projects. This means that I'll have to remember which English files have German counterparts and whether the German translation needs to be updated or not.


Are there any tools or DITA-OT plug-ins for this purpose --- which would still allow me to edit and publish in the way I do now? I do not want to use a CMS system. (I already evaluated DITAToo and VirtualDrive, but this solution did not work out as expected.)


Thank you.


Frank


--

Frank Dissinger

Documentation Manager

....................................................................

CGS Publishing Technologies International GmbH

Email frank.dissinger@... | Web www.cgs-oris.com

Address Kettelerstr. 24 | D-63512 Hainburg | Germany

Phone +49 6182 9626-27 | Fax +49 6182 9626-99

Commercial register Offenbach, HRB no. 21495

Managing directors Bernd Rückert, Andreas Kämmerer, Christoph Thommessen



__._,_.___

Posted by: Frank Dissinger <frank.dissinger@...>



__,_._,___


--

Frank Dissinger

Documentation Manager

....................................................................

CGS Publishing Technologies International GmbH

Email frank.dissinger@... | Web www.cgs-oris.com

Address Kettelerstr. 24 | D-63512 Hainburg | Germany

Phone +49 6182 9626-27 | Fax +49 6182 9626-99

Commercial register Offenbach, HRB no. 21495

Managing directors Bernd Rückert, Andreas Kämmerer, Christoph Thommessen


Sascha.Nothofer@...
 

Hi Frank,

the translation package builder add-on for Oxygen XML Editor is perfect to identify changes during milestones in your base language.

Additionally we are using GIT version control to manage our translation files for 7 languages. We have split our DITA project folder into a "translated-topics" GIT repository and a GIT repo for not translated ressources (Illustrations, DITAVALs, DITA-Maps, ...)

In the "translated topics" repo, each translation is located in a language specific GIT branch (never merged anywhere). File names and folder structures are identical in all languages.

We are using GIT version tags to identiify translation milestones in both repositories.

 

Pros:

- you have to maintain only one DITA maps structure for all languages

- no manual file management for all translation files

- Easy quick fix and sync of small changes in all languages during authoring. Switch branch to switch language in all Topics opened in Oxygen / XML Editor.

- see changes in orignial languages and translations via GIT commit history

 

Cons:

- maybe difficult to publish multi lang publications (never tried to find a solution)

 

 


Frank Dissinger
 

Hm... it's a question of budget... We do not produce a large amount of documentation and I have to make translations for just one language once in a while. So purchasing a CMS would be overkill. And my self-created publishing workflow would not longer be working...


Am 09.11.2019 um 19:35 schrieb Stefan Gentz via Groups.Io:

Hi Frank,

your requirement is a translation management topic. Not sure how or even why DITA-OT could come in for this.

Translation Management is a core capability of any CMS and one main reason why companies decide for a CMS, especially when there is more than just one target language. XML Documentation for Adobe Experience Manager, for example, keeps always track of your source files and your translations and will monitor which files got out of sync in the target language(s) when you changed something, or if you added new contact.

However, as you have just one single target language, maybe just Excel is enough? A simple table with the file names in one column, and then a few more columns for "translated", "needs translation update" status (like "in translation") might be already enough.

Cheers,
*Stefan*


--

Frank Dissinger

Documentation Manager

....................................................................

CGS Publishing Technologies International GmbH

Email frank.dissinger@... | Web www.cgs-oris.com

Address Kettelerstr. 24 | D-63512 Hainburg | Germany

Phone +49 6182 9626-27 | Fax +49 6182 9626-99

Commercial register Offenbach, HRB no. 21495

Managing directors Bernd Rückert, Andreas Kämmerer, Christoph Thommessen


Frank Dissinger
 

Thank you, Sascha, i'll definitely take a look at that add-on. Regards, Frank.



Am 11.11.2019 um 09:51 schrieb Sascha.Nothofer@...:

Hi Frank,

the translation package builder add-on for Oxygen XML Editor is perfect to identify changes during milestones in your base language.

Additionally we are using GIT version control to manage our translation files for 7 languages. We have split our DITA project folder into a "translated-topics" GIT repository and a GIT repo for not translated ressources (Illustrations, DITAVALs, DITA-Maps, ...)

In the "translated topics" repo, each translation is located in a language specific GIT branch (never merged anywhere). File names and folder structures are identical in all languages.

We are using GIT version tags to identiify translation milestones in both repositories.

 

Pros:

- you have to maintain only one DITA maps structure for all languages

- no manual file management for all translation files

- Easy quick fix and sync of small changes in all languages during authoring. Switch branch to switch language in all Topics opened in Oxygen / XML Editor.

- see changes in orignial languages and translations via GIT commit history

 

Cons:

- maybe difficult to publish multi lang publications (never tried to find a solution)

 

 


--

Frank Dissinger

Documentation Manager

....................................................................

CGS Publishing Technologies International GmbH

Email frank.dissinger@... | Web www.cgs-oris.com

Address Kettelerstr. 24 | D-63512 Hainburg | Germany

Phone +49 6182 9626-27 | Fax +49 6182 9626-99

Commercial register Offenbach, HRB no. 21495

Managing directors Bernd Rückert, Andreas Kämmerer, Christoph Thommessen


David H
 

Hi Frank,

It is possible to do it all with keys.

Use language specific folders.

Use flat 'content maps' that simply include all the topics for a language, and define keys for each topic.

Use a single 'ToC map' that defines the document.

Use 'build maps' for each language. These bring together one of the content maps and the ToC map.

It's a bit convoluted, because to add a topic requires an addition to two maps, the content map and the ToC map. But, it's probably suitable for limited translation requirements without a CMS. Your publishing workflow should be fine with this setup.

it does, however, mean that there is only a single ToC map that defines the document, reused for all languages. There's no need to remember to add new topics to every language.

HTH,
David


Hm... it's a question of budget... We do not produce a large amount of documentation and I have to make translations for just one language once in a while. So purchasing a CMS would be overkill. And my self-created publishing workflow would not longer be working...


Frank Dissinger
 

Hi David,

Thank you for your reply. Sounds like an interesting approach...

But I don't use flat ditamaps. This is the directory structure I use -- see below. It cannot be changed because the publishing workflow relies on this structure.

Your approach is not likely to work with this file organization, is it?

Regards,
Frank

milestone (e.g. "recent")
- build (publishing scripts, ant xml and properties files, ditaval files...)
  - out (deliverables generated from root ditamaps)
  - sources
    - language_all (no translation needed)
    - language_1 (e.g. "deu") same structure as "enu"
    - language_2 (e.g. "enu")
      - product_all (dita files shared between all products)
      - product_1_and_2 (shared between these products only)
      - product_1
      - product 2
      - product_3 (root ditamaps for publishing, sub ditamaps)
        - concept (concept type topics referenced by these submaps)
        - task (task type topics...)
        - reference (...)
        - reuse (library files with id'ed elements shared between these topics)
        - images



Am 11.11.2019 um 11:15 schrieb David H:

Hi Frank,

It is possible to do it all with keys.

Use language specific folders.

Use flat 'content maps' that simply include all the topics for a language, and define keys for each topic.

Use a single 'ToC map' that defines the document.

Use 'build maps' for each language. These bring together one of the content maps and the ToC map.

It's a bit convoluted, because to add a topic requires an addition to two maps, the content map and the ToC map. But, it's probably suitable for limited translation requirements without a CMS. Your publishing workflow should be fine with this setup.

it does, however, mean that there is only a single ToC map that defines the document, reused for all languages. There's no need to remember to add new topics to every language.

HTH,
David


Hm... it's a question of budget... We do not produce a large amount of documentation and I have to make translations for just one language once in a while. So purchasing a CMS would be overkill. And my self-created publishing workflow would not longer be working...

--

Frank Dissinger

Documentation Manager

....................................................................

CGS Publishing Technologies International GmbH

Email frank.dissinger@... | Web www.cgs-oris.com

Address Kettelerstr. 24 | D-63512 Hainburg | Germany

Phone +49 6182 9626-27 | Fax +49 6182 9626-99

Commercial register Offenbach, HRB no. 21495

Managing directors Bernd Rückert, Andreas Kämmerer, Christoph Thommessen


Frank Dissinger
 

Hi Radu and Sascha,

Would the Translation Package Builder add-on also be helpful for me if I did the actual dita file editing outside oXygen? (I usually use FrameMaker, for some tiny changes also Notepad++.)

Regards,
Frank



Am 09.11.2019 um 19:15 schrieb Radu Coravu:

Hi Frank,

Replying to you on the new group.

If you are using Oxygen XML Editor, we created some time ago a translation package builder add-on, it has a readme explaining how it should be used:

https://github.com/oxygenxml/oxygen-dita-translation-package-builder

Regards,

Radu Coravu
Oxygen XML Editor




Am 11.11.2019 um 09:51 schrieb Sascha.Nothofer@...:

Hi Frank,

the translation package builder add-on for Oxygen XML Editor is perfect to identify changes during milestones in your base language.

Additionally we are using GIT version control to manage our translation files for 7 languages. We have split our DITA project folder into a "translated-topics" GIT repository and a GIT repo for not translated ressources (Illustrations, DITAVALs, DITA-Maps, ...)

In the "translated topics" repo, each translation is located in a language specific GIT branch (never merged anywhere). File names and folder structures are identical in all languages.

We are using GIT version tags to identiify translation milestones in both repositories.

 Pros:

- you have to maintain only one DITA maps structure for all languages

- no manual file management for all translation files

- Easy quick fix and sync of small changes in all languages during authoring. Switch branch to switch language in all Topics opened in Oxygen / XML Editor.

- see changes in orignial languages and translations via GIT commit history

 Cons:

- maybe difficult to publish multi lang publications (never tried to find a solution)

 



On 11/8/19 4:09 PM, Frank Dissinger frank.dissinger@... [dita-users] wrote:


Hi list,

I am working with dita files on the file system level, without the use of a CMS. I edit with FrameMaker, publish PDF using DITA-FMx and publish online help from the command line using DITA-OT+plug-ins+scripts.
Until now I have written everything in English, now I also have to create German translations for some projects. This means that I'll have to remember which English files have German counterparts and whether the German translation needs to be updated or not.
Are there any tools or DITA-OT plug-ins for this purpose --- which would still allow me to edit and publish in the way I do now? I do not want to use a CMS system. (I already evaluated DITAToo and VirtualDrive, but this solution did not work out as expected.)

Thank you.

Frank

--

Frank Dissinger
Documentation Manager
....................................................................
CGS Publishing Technologies International GmbH
Email frank.dissinger@... | Web www.cgs-oris.com
Address Kettelerstr. 24 | D-63512 Hainburg | Germany
Phone +49 6182 9626-27 | Fax +49 6182 9626-99
Commercial register Offenbach, HRB no. 21495
Managing directors Bernd Rückert, Andreas Kämmerer, Christoph Thommessen


Frank Dissinger
 

I've just done a quick test with oXygen's Translation Package Builder.

I understand that this is a tool for just detecting which translation SOURCE files have changed. The tool does not know anything about the translation TARGET files. So, when I set a milestone, the tool assumes that I have translated (or will be translating) the coresponding target files. When it then detects the modified source files, I know which target files (translations) I have to update.

Correct or am I missing something?

But what if the files get translated into more than one language? One is getting translated now, but the other later... and meanwhile the source files are being modified... ?



Am 11.11.2019 um 12:32 schrieb Frank Dissinger:

Hi Radu and Sascha,

Would the Translation Package Builder add-on also be helpful for me if I did the actual dita file editing outside oXygen? (I usually use FrameMaker, for some tiny changes also Notepad++.)

Regards,
Frank



Am 09.11.2019 um 19:15 schrieb Radu Coravu:

Hi Frank,

Replying to you on the new group.

If you are using Oxygen XML Editor, we created some time ago a translation package builder add-on, it has a readme explaining how it should be used:

https://github.com/oxygenxml/oxygen-dita-translation-package-builder

Regards,

Radu Coravu
Oxygen XML Editor




Am 11.11.2019 um 09:51 schrieb Sascha.Nothofer@...:

Hi Frank,

the translation package builder add-on for Oxygen XML Editor is perfect to identify changes during milestones in your base language.

Additionally we are using GIT version control to manage our translation files for 7 languages. We have split our DITA project folder into a "translated-topics" GIT repository and a GIT repo for not translated ressources (Illustrations, DITAVALs, DITA-Maps, ...)

In the "translated topics" repo, each translation is located in a language specific GIT branch (never merged anywhere). File names and folder structures are identical in all languages.

We are using GIT version tags to identiify translation milestones in both repositories.

 Pros:

- you have to maintain only one DITA maps structure for all languages

- no manual file management for all translation files

- Easy quick fix and sync of small changes in all languages during authoring. Switch branch to switch language in all Topics opened in Oxygen / XML Editor.

- see changes in orignial languages and translations via GIT commit history

 Cons:

- maybe difficult to publish multi lang publications (never tried to find a solution)

 



On 11/8/19 4:09 PM, Frank Dissinger frank.dissinger@... [dita-users] wrote:


Hi list,

I am working with dita files on the file system level, without the use of a CMS. I edit with FrameMaker, publish PDF using DITA-FMx and publish online help from the command line using DITA-OT+plug-ins+scripts.
Until now I have written everything in English, now I also have to create German translations for some projects. This means that I'll have to remember which English files have German counterparts and whether the German translation needs to be updated or not.
Are there any tools or DITA-OT plug-ins for this purpose --- which would still allow me to edit and publish in the way I do now? I do not want to use a CMS system. (I already evaluated DITAToo and VirtualDrive, but this solution did not work out as expected.)

Thank you.

Frank

--

Frank Dissinger
Documentation Manager
....................................................................
CGS Publishing Technologies International GmbH
Email frank.dissinger@... | Web www.cgs-oris.com
Address Kettelerstr. 24 | D-63512 Hainburg | Germany
Phone +49 6182 9626-27 | Fax +49 6182 9626-99
Commercial register Offenbach, HRB no. 21495
Managing directors Bernd Rückert, Andreas Kämmerer, Christoph Thommessen


Kristen James Eberlein
 

Hi, Frank.

If you add in multiple target languages -- especially if translated at different times -- that's when the scenario becomes difficult to handle without a CCMS.

And your current requirement to use FrameMaker for both authoring and PDF publishing rules out many of the CCMS solutions. (Obviously, AEM has support for FrameMaker, but its price point puts it out of the running for all but large, enterprise companies.)
 
If you have not done so already, take a look at the translation-related tool that Rudolfo Ray's company produces: https://www.maxprograms.com/

Are you open to using XLIFF for translation?

Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)

On 11/11/2019 7:49 AM, Frank Dissinger wrote:
I've just done a quick test with oXygen's Translation Package Builder.

I understand that this is a tool for just detecting which translation SOURCE files have changed. The tool does not know anything about the translation TARGET files. So, when I set a milestone, the tool assumes that I have translated (or will be translating) the coresponding target files. When it then detects the modified source files, I know which target files (translations) I have to update.

Correct or am I missing something?

But what if the files get translated into more than one language? One is getting translated now, but the other later... and meanwhile the source files are being modified... ?



Am 11.11.2019 um 12:32 schrieb Frank Dissinger:
Hi Radu and Sascha,

Would the Translation Package Builder add-on also be helpful for me if I did the actual dita file editing outside oXygen? (I usually use FrameMaker, for some tiny changes also Notepad++.)

Regards,
Frank



Am 09.11.2019 um 19:15 schrieb Radu Coravu:

Hi Frank,

Replying to you on the new group.

If you are using Oxygen XML Editor, we created some time ago a translation package builder add-on, it has a readme explaining how it should be used:

https://github.com/oxygenxml/oxygen-dita-translation-package-builder

Regards,

Radu Coravu
Oxygen XML Editor




Am 11.11.2019 um 09:51 schrieb Sascha.Nothofer@...:

Hi Frank,

the translation package builder add-on for Oxygen XML Editor is perfect to identify changes during milestones in your base language.

Additionally we are using GIT version control to manage our translation files for 7 languages. We have split our DITA project folder into a "translated-topics" GIT repository and a GIT repo for not translated ressources (Illustrations, DITAVALs, DITA-Maps, ...)

In the "translated topics" repo, each translation is located in a language specific GIT branch (never merged anywhere). File names and folder structures are identical in all languages.

We are using GIT version tags to identiify translation milestones in both repositories.

 Pros:

- you have to maintain only one DITA maps structure for all languages

- no manual file management for all translation files

- Easy quick fix and sync of small changes in all languages during authoring. Switch branch to switch language in all Topics opened in Oxygen / XML Editor.

- see changes in orignial languages and translations via GIT commit history

 Cons:

- maybe difficult to publish multi lang publications (never tried to find a solution)

 



On 11/8/19 4:09 PM, Frank Dissinger frank.dissinger@... [dita-users] wrote:


Hi list,

I am working with dita files on the file system level, without the use of a CMS. I edit with FrameMaker, publish PDF using DITA-FMx and publish online help from the command line using DITA-OT+plug-ins+scripts.
Until now I have written everything in English, now I also have to create German translations for some projects. This means that I'll have to remember which English files have German counterparts and whether the German translation needs to be updated or not.
Are there any tools or DITA-OT plug-ins for this purpose --- which would still allow me to edit and publish in the way I do now? I do not want to use a CMS system. (I already evaluated DITAToo and VirtualDrive, but this solution did not work out as expected.)

Thank you.

Frank

--

Frank Dissinger
Documentation Manager
....................................................................
CGS Publishing Technologies International GmbH
Email frank.dissinger@... | Web www.cgs-oris.com
Address Kettelerstr. 24 | D-63512 Hainburg | Germany
Phone +49 6182 9626-27 | Fax +49 6182 9626-99
Commercial register Offenbach, HRB no. 21495
Managing directors Bernd Rückert, Andreas Kämmerer, Christoph Thommessen


Rodolfo M. Raya
 

Hi,

Take a look at Fluenta, https://www.maxprograms.com/products/fluenta.html 

With Fluenta you can manage the translation of your DITA files to multiple languages It works on the files you already have in the file system, no CMS required.

In another message mentioned an interesting layout for language folders. You might consider switching to a structure like the one I mention at https://ditatranslation.com/articles/organize_files.html 

Regards,
Rodolfo M. Raya


Frank Dissinger
 

Thank you, Rodolfo.

I'll take a look at Fluenta to see how it can help me managing DITA translations.

Regards, Frank



Am 11.11.2019 um 15:23 schrieb Rodolfo M. Raya:

Hi,

Take a look at Fluenta, https://www.maxprograms.com/products/fluenta.html 

With Fluenta you can manage the translation of your DITA files to multiple languages It works on the files you already have in the file system, no CMS required.

In another message mentioned an interesting layout for language folders. You might consider switching to a structure like the one I mention at https://ditatranslation.com/articles/organize_files.html 

Regards,
Rodolfo M. Raya


--

Frank Dissinger

Documentation Manager

....................................................................

CGS Publishing Technologies International GmbH

Email frank.dissinger@... | Web www.cgs-oris.com

Address Kettelerstr. 24 | D-63512 Hainburg | Germany

Phone +49 6182 9626-27 | Fax +49 6182 9626-99

Commercial register Offenbach, HRB no. 21495

Managing directors Bernd Rückert, Andreas Kämmerer, Christoph Thommessen


Frank Dissinger
 

Thank you, Kris. I'll take a look at Fluenta when I have some time.
Regards, Frank.



Am 11.11.2019 um 14:44 schrieb Kristen James Eberlein:

Hi, Frank.

If you add in multiple target languages -- especially if translated at different times -- that's when the scenario becomes difficult to handle without a CCMS.

And your current requirement to use FrameMaker for both authoring and PDF publishing rules out many of the CCMS solutions. (Obviously, AEM has support for FrameMaker, but its price point puts it out of the running for all but large, enterprise companies.)
 
If you have not done so already, take a look at the translation-related tool that Rudolfo Ray's company produces: https://www.maxprograms.com/

Are you open to using XLIFF for translation?

Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)

On 11/11/2019 7:49 AM, Frank Dissinger wrote:
I've just done a quick test with oXygen's Translation Package Builder.

I understand that this is a tool for just detecting which translation SOURCE files have changed. The tool does not know anything about the translation TARGET files. So, when I set a milestone, the tool assumes that I have translated (or will be translating) the coresponding target files. When it then detects the modified source files, I know which target files (translations) I have to update.

Correct or am I missing something?

But what if the files get translated into more than one language? One is getting translated now, but the other later... and meanwhile the source files are being modified... ?



Am 11.11.2019 um 12:32 schrieb Frank Dissinger:
Hi Radu and Sascha,

Would the Translation Package Builder add-on also be helpful for me if I did the actual dita file editing outside oXygen? (I usually use FrameMaker, for some tiny changes also Notepad++.)

Regards,
Frank



Am 09.11.2019 um 19:15 schrieb Radu Coravu:

Hi Frank,

Replying to you on the new group.

If you are using Oxygen XML Editor, we created some time ago a translation package builder add-on, it has a readme explaining how it should be used:

https://github.com/oxygenxml/oxygen-dita-translation-package-builder

Regards,

Radu Coravu
Oxygen XML Editor




Am 11.11.2019 um 09:51 schrieb Sascha.Nothofer@...:

Hi Frank,

the translation package builder add-on for Oxygen XML Editor is perfect to identify changes during milestones in your base language.

Additionally we are using GIT version control to manage our translation files for 7 languages. We have split our DITA project folder into a "translated-topics" GIT repository and a GIT repo for not translated ressources (Illustrations, DITAVALs, DITA-Maps, ...)

In the "translated topics" repo, each translation is located in a language specific GIT branch (never merged anywhere). File names and folder structures are identical in all languages.

We are using GIT version tags to identiify translation milestones in both repositories.

 Pros:

- you have to maintain only one DITA maps structure for all languages

- no manual file management for all translation files

- Easy quick fix and sync of small changes in all languages during authoring. Switch branch to switch language in all Topics opened in Oxygen / XML Editor.

- see changes in orignial languages and translations via GIT commit history

 Cons:

- maybe difficult to publish multi lang publications (never tried to find a solution)

 



On 11/8/19 4:09 PM, Frank Dissinger frank.dissinger@... [dita-users] wrote:


Hi list,

I am working with dita files on the file system level, without the use of a CMS. I edit with FrameMaker, publish PDF using DITA-FMx and publish online help from the command line using DITA-OT+plug-ins+scripts.
Until now I have written everything in English, now I also have to create German translations for some projects. This means that I'll have to remember which English files have German counterparts and whether the German translation needs to be updated or not.
Are there any tools or DITA-OT plug-ins for this purpose --- which would still allow me to edit and publish in the way I do now? I do not want to use a CMS system. (I already evaluated DITAToo and VirtualDrive, but this solution did not work out as expected.)

Thank you.

Frank


--

Frank Dissinger

Documentation Manager

....................................................................

CGS Publishing Technologies International GmbH

Email frank.dissinger@... | Web www.cgs-oris.com

Address Kettelerstr. 24 | D-63512 Hainburg | Germany

Phone +49 6182 9626-27 | Fax +49 6182 9626-99

Commercial register Offenbach, HRB no. 21495

Managing directors Bernd Rückert, Andreas Kämmerer, Christoph Thommessen


etudsbery
 

Hi there,

 

I translate to German and Japanese while using Framemaker.

 

I let the translation agency handle the pain in this instance.

 

I have a top-level ditamap. I make an archive of this using the Dita-fmx >>Utilities>>Create archive functionality. I send this to the translation agency. When there is a new version I re-create the archive and send this.

 

The translation agency then auto-translate everything they have done before and see what is new, and just translate this. It seems to work OK.

 

Regards,

 

Ed

 

From: dita-users@groups.io <dita-users@groups.io> On Behalf Of Frank Dissinger via Groups.Io
Sent: 15 November 2019 15:39
To: dita-users@groups.io
Subject: [dita-users] Translation management with file-system-based editing/publishing

 

Thank you, Kris. I'll take a look at Fluenta when I have some time.

Regards, Frank.

 


 

Am 11.11.2019 um 14:44 schrieb Kristen James Eberlein:

Hi, Frank.

If you add in multiple target languages -- especially if translated at different times -- that's when the scenario becomes difficult to handle without a CCMS.

And your current requirement to use FrameMaker for both authoring and PDF publishing rules out many of the CCMS solutions. (Obviously, AEM has support for FrameMaker, but its price point puts it out of the running for all but large, enterprise companies.)
 
If you have not done so already, take a look at the translation-related tool that Rudolfo Ray's company produces: https://www.maxprograms.com/

Are you open to using XLIFF for translation?

Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)

On 11/11/2019 7:49 AM, Frank Dissinger wrote:

I've just done a quick test with oXygen's Translation Package Builder.

 

I understand that this is a tool for just detecting which translation SOURCE files have changed. The tool does not know anything about the translation TARGET files. So, when I set a milestone, the tool assumes that I have translated (or will be translating) the coresponding target files. When it then detects the modified source files, I know which target files (translations) I have to update.

 

Correct or am I missing something?

 

But what if the files get translated into more than one language? One is getting translated now, but the other later... and meanwhile the source files are being modified... ?

 


 

Am 11.11.2019 um 12:32 schrieb Frank Dissinger:

Hi Radu and Sascha,

 

Would the Translation Package Builder add-on also be helpful for me if I did the actual dita file editing outside oXygen? (I usually use FrameMaker, for some tiny changes also Notepad++.)

 

Regards,
Frank

 


 

Am 09.11.2019 um 19:15 schrieb Radu Coravu:

Hi Frank,

Replying to you on the new group.

If you are using Oxygen XML Editor, we created some time ago a translation package builder add-on, it has a readme explaining how it should be used:

https://github.com/oxygenxml/oxygen-dita-translation-package-builder

Regards,

Radu Coravu
Oxygen XML Editor

 


 

Am 11.11.2019 um 09:51 schrieb Sascha.Nothofer@...:

Hi Frank,

the translation package builder add-on for Oxygen XML Editor is perfect to identify changes during milestones in your base language.

Additionally we are using GIT version control to manage our translation files for 7 languages. We have split our DITA project folder into a "translated-topics" GIT repository and a GIT repo for not translated ressources (Illustrations, DITAVALs, DITA-Maps, ...)

In the "translated topics" repo, each translation is located in a language specific GIT branch (never merged anywhere). File names and folder structures are identical in all languages.

We are using GIT version tags to identiify translation milestones in both repositories.

 Pros:

- you have to maintain only one DITA maps structure for all languages

- no manual file management for all translation files

- Easy quick fix and sync of small changes in all languages during authoring. Switch branch to switch language in all Topics opened in Oxygen / XML Editor.

- see changes in orignial languages and translations via GIT commit history

 Cons:

- maybe difficult to publish multi lang publications (never tried to find a solution)

 


 

On 11/8/19 4:09 PM, Frank Dissinger frank.dissinger@... [dita-users] wrote:




Hi list,

I am working with dita files on the file system level, without the use of a CMS. I edit with FrameMaker, publish PDF using DITA-FMx and publish online help from the command line using DITA-OT+plug-ins+scripts.
Until now I have written everything in English, now I also have to create German translations for some projects. This means that I'll have to remember which English files have German counterparts and whether the German translation needs to be updated or not.
Are there any tools or DITA-OT plug-ins for this purpose --- which would still allow me to edit and publish in the way I do now? I do not want to use a CMS system. (I already evaluated DITAToo and VirtualDrive, but this solution did not work out as expected.)

Thank you.

Frank

 

--

Frank Dissinger

Documentation Manager

....................................................................

CGS Publishing Technologies International GmbH

Email frank.dissinger@... | Web www.cgs-oris.com

Address Kettelerstr. 24 | D-63512 Hainburg | Germany

Phone +49 6182 9626-27 | Fax +49 6182 9626-99

Commercial register Offenbach, HRB no. 21495

Managing directors Bernd Rückert, Andreas Kämmerer, Christoph Thommessen

 


If you wish to view the CPA Global group email disclaimer, please click here



Frank Dissinger
 

Hi Ed,

Yes, of course, you're right...  It depends on your approach.

If you just let the LSP (translation agency) do everything, then why bother about managing translations? The translations are stored in their TMS system and they can reuse them for the next source file update. The only thing I then would do is make a copy of all my DITA files and store them under a milestone name. This allows me to integrate changes to the translation (which need to be made in a revision cycle) while at the same time continuing to edit the source dita files.

However, if you want to keep the translation memory in house, then the XLIFF approach seems to be appropriate.

In my case, I write the source files in English and a LSP provides the Japanese translation.5 For some projects, I also create a German translation myself, usually with a TMS (Transit NXT), but sometimes not -- which seems to be a bad idea...

Regards,
Frank



Am 15.11.2019 um 16:32 schrieb etudsbery:

Hi there,

 

I translate to German and Japanese while using Framemaker.

 

I let the translation agency handle the pain in this instance.

 

I have a top-level ditamap. I make an archive of this using the Dita-fmx >>Utilities>>Create archive functionality. I send this to the translation agency. When there is a new version I re-create the archive and send this.

 

The translation agency then auto-translate everything they have done before and see what is new, and just translate this. It seems to work OK.

 

Regards,

 

Ed

 

From: dita-users@groups.io <dita-users@groups.io> On Behalf Of Frank Dissinger via Groups.Io
Sent: 15 November 2019 15:39
To: dita-users@groups.io
Subject: [dita-users] Translation management with file-system-based editing/publishing

 

Thank you, Kris. I'll take a look at Fluenta when I have some time.

Regards, Frank.

 


 

Am 11.11.2019 um 14:44 schrieb Kristen James Eberlein:

Hi, Frank.

If you add in multiple target languages -- especially if translated at different times -- that's when the scenario becomes difficult to handle without a CCMS.

And your current requirement to use FrameMaker for both authoring and PDF publishing rules out many of the CCMS solutions. (Obviously, AEM has support for FrameMaker, but its price point puts it out of the running for all but large, enterprise companies.)
 
If you have not done so already, take a look at the translation-related tool that Rudolfo Ray's company produces: https://www.maxprograms.com/

Are you open to using XLIFF for translation?

Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)

On 11/11/2019 7:49 AM, Frank Dissinger wrote:

I've just done a quick test with oXygen's Translation Package Builder.

 

I understand that this is a tool for just detecting which translation SOURCE files have changed. The tool does not know anything about the translation TARGET files. So, when I set a milestone, the tool assumes that I have translated (or will be translating) the coresponding target files. When it then detects the modified source files, I know which target files (translations) I have to update.

 

Correct or am I missing something?

 

But what if the files get translated into more than one language? One is getting translated now, but the other later... and meanwhile the source files are being modified... ?

 


 

Am 11.11.2019 um 12:32 schrieb Frank Dissinger:

Hi Radu and Sascha,

 

Would the Translation Package Builder add-on also be helpful for me if I did the actual dita file editing outside oXygen? (I usually use FrameMaker, for some tiny changes also Notepad++.)

 

Regards,
Frank

 


 

Am 09.11.2019 um 19:15 schrieb Radu Coravu:

Hi Frank,

Replying to you on the new group.

If you are using Oxygen XML Editor, we created some time ago a translation package builder add-on, it has a readme explaining how it should be used:

https://github.com/oxygenxml/oxygen-dita-translation-package-builder

Regards,

Radu Coravu
Oxygen XML Editor

 


 

Am 11.11.2019 um 09:51 schrieb Sascha.Nothofer@...:

Hi Frank,

the translation package builder add-on for Oxygen XML Editor is perfect to identify changes during milestones in your base language.

Additionally we are using GIT version control to manage our translation files for 7 languages. We have split our DITA project folder into a "translated-topics" GIT repository and a GIT repo for not translated ressources (Illustrations, DITAVALs, DITA-Maps, ...)

In the "translated topics" repo, each translation is located in a language specific GIT branch (never merged anywhere). File names and folder structures are identical in all languages.

We are using GIT version tags to identiify translation milestones in both repositories.

 Pros:

- you have to maintain only one DITA maps structure for all languages

- no manual file management for all translation files

- Easy quick fix and sync of small changes in all languages during authoring. Switch branch to switch language in all Topics opened in Oxygen / XML Editor.

- see changes in orignial languages and translations via GIT commit history

 Cons:

- maybe difficult to publish multi lang publications (never tried to find a solution)

 


 

On 11/8/19 4:09 PM, Frank Dissinger frank.dissinger@... [dita-users] wrote:



Hi list,

I am working with dita files on the file system level, without the use of a CMS. I edit with FrameMaker, publish PDF using DITA-FMx and publish online help from the command line using DITA-OT+plug-ins+scripts.
Until now I have written everything in English, now I also have to create German translations for some projects. This means that I'll have to remember which English files have German counterparts and whether the German translation needs to be updated or not.
Are there any tools or DITA-OT plug-ins for this purpose --- which would still allow me to edit and publish in the way I do now? I do not want to use a CMS system. (I already evaluated DITAToo and VirtualDrive, but this solution did not work out as expected.)

Thank you.
Frank



--

Frank Dissinger

Documentation Manager

....................................................................

CGS Publishing Technologies International GmbH

Email frank.dissinger@... | Web www.cgs-oris.com

Address Kettelerstr. 24 | D-63512 Hainburg | Germany

Phone +49 6182 9626-27 | Fax +49 6182 9626-99

Commercial register Offenbach, HRB no. 21495

Managing directors Bernd Rückert, Andreas Kämmerer, Christoph Thommessen


Elizabeth Gschwind (FICO)
 

I would just add that we are humans after all, and it’s very nice to know at a glance what language the file is in. If it were me, I would definitely add some sort of language tag to the file names to make it easier to quickly know what you are looking at (and to avoid overwriting the English file with your localized files). For example, “GettingStarted.xml” could become “GettingStarted_FR.xml” for the French version. You can do bulk file name editing pretty quickly using Python. (Fortunately for me, our CMS handles all of this.)

 

Elizabeth Gschwind

Localization Manager | FICO

 

From: dita-users@groups.io <dita-users@groups.io> On Behalf Of Frank Dissinger
Sent: Friday, November 15, 2019 10:04 AM
To: dita-users@groups.io
Subject: [dita-users] Translation management with file-system-based editing/publishing

 

Hi Ed,

 

Yes, of course, you're right...  It depends on your approach.

 

If you just let the LSP (translation agency) do everything, then why bother about managing translations? The translations are stored in their TMS system and they can reuse them for the next source file update. The only thing I then would do is make a copy of all my DITA files and store them under a milestone name. This allows me to integrate changes to the translation (which need to be made in a revision cycle) while at the same time continuing to edit the source dita files.

 

However, if you want to keep the translation memory in house, then the XLIFF approach seems to be appropriate.

 

In my case, I write the source files in English and a LSP provides the Japanese translation.5 For some projects, I also create a German translation myself, usually with a TMS (Transit NXT), but sometimes not -- which seems to be a bad idea...

 

Regards,

Frank

 


 

Am 15.11.2019 um 16:32 schrieb etudsbery:

Hi there,

 

I translate to German and Japanese while using Framemaker.

 

I let the translation agency handle the pain in this instance.

 

I have a top-level ditamap. I make an archive of this using the Dita-fmx >>Utilities>>Create archive functionality. I send this to the translation agency. When there is a new version I re-create the archive and send this.

 

The translation agency then auto-translate everything they have done before and see what is new, and just translate this. It seems to work OK.

 

Regards,

 

Ed

 

From: dita-users@groups.io <dita-users@groups.io> On Behalf Of Frank Dissinger via Groups.Io
Sent: 15 November 2019 15:39
To: dita-users@groups.io
Subject: [dita-users] Translation management with file-system-based editing/publishing

 

Thank you, Kris. I'll take a look at Fluenta when I have some time.

Regards, Frank.

 


 

Am 11.11.2019 um 14:44 schrieb Kristen James Eberlein:

Hi, Frank.

If you add in multiple target languages -- especially if translated at different times -- that's when the scenario becomes difficult to handle without a CCMS.

And your current requirement to use FrameMaker for both authoring and PDF publishing rules out many of the CCMS solutions. (Obviously, AEM has support for FrameMaker, but its price point puts it out of the running for all but large, enterprise companies.)
 
If you have not done so already, take a look at the translation-related tool that Rudolfo Ray's company produces: https://www.maxprograms.com/

Are you open to using XLIFF for translation?

Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)

On 11/11/2019 7:49 AM, Frank Dissinger wrote:

I've just done a quick test with oXygen's Translation Package Builder.

 

I understand that this is a tool for just detecting which translation SOURCE files have changed. The tool does not know anything about the translation TARGET files. So, when I set a milestone, the tool assumes that I have translated (or will be translating) the coresponding target files. When it then detects the modified source files, I know which target files (translations) I have to update.

 

Correct or am I missing something?

 

But what if the files get translated into more than one language? One is getting translated now, but the other later... and meanwhile the source files are being modified... ?

 


 

Am 11.11.2019 um 12:32 schrieb Frank Dissinger:

Hi Radu and Sascha,

 

Would the Translation Package Builder add-on also be helpful for me if I did the actual dita file editing outside oXygen? (I usually use FrameMaker, for some tiny changes also Notepad++.)

 

Regards,
Frank

 


 

Am 09.11.2019 um 19:15 schrieb Radu Coravu:

Hi Frank,

Replying to you on the new group.

If you are using Oxygen XML Editor, we created some time ago a translation package builder add-on, it has a readme explaining how it should be used:

https://github.com/oxygenxml/oxygen-dita-translation-package-builder

Regards,

Radu Coravu
Oxygen XML Editor

 


 

Am 11.11.2019 um 09:51 schrieb Sascha.Nothofer@...:

Hi Frank,

the translation package builder add-on for Oxygen XML Editor is perfect to identify changes during milestones in your base language.

Additionally we are using GIT version control to manage our translation files for 7 languages. We have split our DITA project folder into a "translated-topics" GIT repository and a GIT repo for not translated ressources (Illustrations, DITAVALs, DITA-Maps, ...)

In the "translated topics" repo, each translation is located in a language specific GIT branch (never merged anywhere). File names and folder structures are identical in all languages.

We are using GIT version tags to identiify translation milestones in both repositories.

 Pros:

- you have to maintain only one DITA maps structure for all languages

- no manual file management for all translation files

- Easy quick fix and sync of small changes in all languages during authoring. Switch branch to switch language in all Topics opened in Oxygen / XML Editor.

- see changes in orignial languages and translations via GIT commit history

 Cons:

- maybe difficult to publish multi lang publications (never tried to find a solution)

 


 

On 11/8/19 4:09 PM, Frank Dissinger frank.dissinger@... [dita-users] wrote:




Hi list,

I am working with dita files on the file system level, without the use of a CMS. I edit with FrameMaker, publish PDF using DITA-FMx and publish online help from the command line using DITA-OT+plug-ins+scripts.
Until now I have written everything in English, now I also have to create German translations for some projects. This means that I'll have to remember which English files have German counterparts and whether the German translation needs to be updated or not.
Are there any tools or DITA-OT plug-ins for this purpose --- which would still allow me to edit and publish in the way I do now? I do not want to use a CMS system. (I already evaluated DITAToo and VirtualDrive, but this solution did not work out as expected.)

Thank you.
Frank

 

 

--

Frank Dissinger

Documentation Manager

....................................................................

CGS Publishing Technologies International GmbH

Email frank.dissinger@... | Web www.cgs-oris.com

Address Kettelerstr. 24 | D-63512 Hainburg | Germany

Phone +49 6182 9626-27 | Fax +49 6182 9626-99

Commercial register Offenbach, HRB no. 21495

Managing directors Bernd Rückert, Andreas Kämmerer, Christoph Thommessen

This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.


 

Hi Kris,

"… rules out many of the CCMS solutions."
Out-of-the-box FrameMaker comes with built-in connectors for Adobe Experience Manager, DitaExchange, Documentum, SharePoint, and SharePoint Online.
But there are many more CMS that have an integration with FrameMaker. The (probably not even complete) list can be found here:
https://www.adobe.com/products/framemaker/cms-integration.html

Cheers,
Stefan


Frank Dissinger
 

Sorry for my late reply. I just want to thank everyone who contributed to this thread for their help. You have provided very helpful information. I will have to deal with this subject later, as currently I have deadlines to meet.


Thank you to:

  • Sascha
  • Radu
  • Stefan
  • Rodolfo
  • Elizabeth
  • Ray
  • Kristen
  • Ed
  • Thomas
  • Wim
  • Jang
  • Bernard

Regards,

Frank




Am 15.11.2019 um 19:03 schrieb Frank Dissinger:

Hi Ed,

Yes, of course, you're right...  It depends on your approach.

If you just let the LSP (translation agency) do everything, then why bother about managing translations? The translations are stored in their TMS system and they can reuse them for the next source file update. The only thing I then would do is make a copy of all my DITA files and store them under a milestone name. This allows me to integrate changes to the translation (which need to be made in a revision cycle) while at the same time continuing to edit the source dita files.

However, if you want to keep the translation memory in house, then the XLIFF approach seems to be appropriate.

In my case, I write the source files in English and a LSP provides the Japanese translation.5 For some projects, I also create a German translation myself, usually with a TMS (Transit NXT), but sometimes not -- which seems to be a bad idea...

Regards,
Frank



Am 15.11.2019 um 16:32 schrieb etudsbery:

Hi there,

 

I translate to German and Japanese while using Framemaker.

 

I let the translation agency handle the pain in this instance.

 

I have a top-level ditamap. I make an archive of this using the Dita-fmx >>Utilities>>Create archive functionality. I send this to the translation agency. When there is a new version I re-create the archive and send this.

 

The translation agency then auto-translate everything they have done before and see what is new, and just translate this. It seems to work OK.

 

Regards,

 

Ed

 

From: dita-users@groups.io <dita-users@groups.io> On Behalf Of Frank Dissinger via Groups.Io
Sent: 15 November 2019 15:39
To: dita-users@groups.io
Subject: [dita-users] Translation management with file-system-based editing/publishing

 

Thank you, Kris. I'll take a look at Fluenta when I have some time.

Regards, Frank.

 


 

Am 11.11.2019 um 14:44 schrieb Kristen James Eberlein:

Hi, Frank.

If you add in multiple target languages -- especially if translated at different times -- that's when the scenario becomes difficult to handle without a CCMS.

And your current requirement to use FrameMaker for both authoring and PDF publishing rules out many of the CCMS solutions. (Obviously, AEM has support for FrameMaker, but its price point puts it out of the running for all but large, enterprise companies.)
 
If you have not done so already, take a look at the translation-related tool that Rudolfo Ray's company produces: https://www.maxprograms.com/

Are you open to using XLIFF for translation?

Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)

On 11/11/2019 7:49 AM, Frank Dissinger wrote:

I've just done a quick test with oXygen's Translation Package Builder.

 

I understand that this is a tool for just detecting which translation SOURCE files have changed. The tool does not know anything about the translation TARGET files. So, when I set a milestone, the tool assumes that I have translated (or will be translating) the coresponding target files. When it then detects the modified source files, I know which target files (translations) I have to update.

 

Correct or am I missing something?

 

But what if the files get translated into more than one language? One is getting translated now, but the other later... and meanwhile the source files are being modified... ?

 


 

Am 11.11.2019 um 12:32 schrieb Frank Dissinger:

Hi Radu and Sascha,

 

Would the Translation Package Builder add-on also be helpful for me if I did the actual dita file editing outside oXygen? (I usually use FrameMaker, for some tiny changes also Notepad++.)

 

Regards,
Frank

 


 

Am 09.11.2019 um 19:15 schrieb Radu Coravu:

Hi Frank,

Replying to you on the new group.

If you are using Oxygen XML Editor, we created some time ago a translation package builder add-on, it has a readme explaining how it should be used:

https://github.com/oxygenxml/oxygen-dita-translation-package-builder

Regards,

Radu Coravu
Oxygen XML Editor

 


 

Am 11.11.2019 um 09:51 schrieb Sascha.Nothofer@...:

Hi Frank,

the translation package builder add-on for Oxygen XML Editor is perfect to identify changes during milestones in your base language.

Additionally we are using GIT version control to manage our translation files for 7 languages. We have split our DITA project folder into a "translated-topics" GIT repository and a GIT repo for not translated ressources (Illustrations, DITAVALs, DITA-Maps, ...)

In the "translated topics" repo, each translation is located in a language specific GIT branch (never merged anywhere). File names and folder structures are identical in all languages.

We are using GIT version tags to identiify translation milestones in both repositories.

 Pros:

- you have to maintain only one DITA maps structure for all languages

- no manual file management for all translation files

- Easy quick fix and sync of small changes in all languages during authoring. Switch branch to switch language in all Topics opened in Oxygen / XML Editor.

- see changes in orignial languages and translations via GIT commit history

 Cons:

- maybe difficult to publish multi lang publications (never tried to find a solution)

 


 

On 11/8/19 4:09 PM, Frank Dissinger frank.dissinger@... [dita-users] wrote:



Hi list,

I am working with dita files on the file system level, without the use of a CMS. I edit with FrameMaker, publish PDF using DITA-FMx and publish online help from the command line using DITA-OT+plug-ins+scripts.
Until now I have written everything in English, now I also have to create German translations for some projects. This means that I'll have to remember which English files have German counterparts and whether the German translation needs to be updated or not.
Are there any tools or DITA-OT plug-ins for this purpose --- which would still allow me to edit and publish in the way I do now? I do not want to use a CMS system. (I already evaluated DITAToo and VirtualDrive, but this solution did not work out as expected.)

Thank you.
Frank

--

Frank Dissinger

Documentation Manager

....................................................................

CGS Publishing Technologies International GmbH

Email frank.dissinger@... | Web www.cgs-oris.com

Address Kettelerstr. 24 | D-63512 Hainburg | Germany

Phone +49 6182 9626-27 | Fax +49 6182 9626-99

Commercial register Offenbach, HRB no. 21495

Managing directors Bernd Rückert, Andreas Kämmerer, Christoph Thommessen