Date   

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

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


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

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...


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

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


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

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


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

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)

 

 


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

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


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

 

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.


Re: 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


Re: dita-users successfully transferred to Groups.io #admin

Tonia
 

Thanks for doing this. Have a great weekend.

On Nov 9, 2019, at 2:42 AM, Kristen James Eberlein <@keberlein> wrote:

I just got the formal notice from Groups.io. Hopefully every active (non-bouncing) subscriber to the list will have gotten an e-mail.

It looks as if the most recent messages (between 12 October 2019 and today) were not transferred.

Please stop posting to the old address (dita-users@...) and begin posting to dita-users@groups.io.

--
Best,
Kris

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




dita-users successfully transferred to Groups.io #admin

Kristen James Eberlein
 

I just got the formal notice from Groups.io. Hopefully every active (non-bouncing) subscriber to the list will have gotten an e-mail.

It looks as if the most recent messages (between 12 October 2019 and today) were not transferred.

Please stop posting to the old address (dita-users@...) and begin posting to dita-users@groups.io.

--
Best,
Kris

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


Enabling search in Frameset Output

Rick Smith
 

Hi,

How do we enable search in a Frame (or tocjs) output. Any pointers or best practices or suggestions?

Appreciate your help!!

Thanks,
Rick


Re: Can a in be formatted?

Chris Papademetrious
 

Thanks Joe! Actually, I am trying to preserve semantics here (our FrameMaker source books use <command> and <variable> in some of the See Also links to indicate semantics). Since this is not representable in a <link> in a manner where the link text is auto-generated, I'll just remove the semantic tag and mark it for the writer to review.

Thanks!

 - Chris



Re: Single HTML file with TOC

Mica Semrick
 

The simplest way might be to use pandoc on your single dita file: https://github.com/jgm/pandoc/wiki/Pandoc-Tricks#toc-generation


On October 25, 2019 2:50:09 AM PDT, "Frank Dissinger frank.dissinger@... [dita-users]" wrote:

Hi list,


Using DITA-OT, I would like to generate a single HTML file from a single dita reference file. The HTML file should have a TOC at the beginning, generated from all headings (topic and section titles). In other words, a TOC followed by the actual file contents, all in one HTML file. Can this be done?


I know that a TOC is usually created from the files referenced by a ditamap. But this use case requires a very simple source file which is easy to edit. Creating separate files for each heading would be too much work.


Regards,

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


[Ann] Oxygen XML Web Author 21.1.1 release

Radu Coravu
 

Hi everyone,

We just released version 21.1.1 of the Oxygen XML Web Author in-browser DITA editor.

Among the features interesting for DITA editing:

- The addition of a DITA Map view showing the DITA Map as a table of contents on the left side of the edited topic:

https://www.oxygenxml.com/img/wn_21_1_1_ditamap_large.png

- An in-browser visual DITA (and XML) file comparison tool which is probably the first of its kind:

https://www.oxygenxml.com/img/wn_21_1_1_diff_large.png

- Support to use drag and drop for editing content.
- Support to upload images just by dropping them in the editing area.

The complete list of added improvements can be found here:

https://www.oxygenxml.com/xml_web_author/whats_new.html

and the web editing tool can be tested for free on our online demo server:

https://www.oxygenxml.com/oxygen-xml-web-author/app/oxygen.html

Regards,
Radu

Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com


Single HTML file with TOC

Frank Dissinger
 

Hi list,


Using DITA-OT, I would like to generate a single HTML file from a single dita reference file. The HTML file should have a TOC at the beginning, generated from all headings (topic and section titles). In other words, a TOC followed by the actual file contents, all in one HTML file. Can this be done?


I know that a TOC is usually created from the files referenced by a ditamap. But this use case requires a very simple source file which is easy to edit. Creating separate files for each heading would be too much work.


Regards,

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


Re: DITA specialization questions

Daud Vyd
 

Chris,

How do I remove the blue underline from link text? The CSS below correctly sets the font weight but does not remove the color or underline. I'd like to declare a default rendering for links and then several case by case overrides. CSS is designed for such an approach--right?

*[class~="topic/ph"][outputclass="actor"] {
    text-decoration: none;
    font-weight: 600;
}

-da'ud


Re: DITA specialization questions

Daud Vyd
 

Thanks Chris. That works!


Re: Can a <link> in <related-links> be formatted?

Nicholas Mucks
 

Hi Chris,
It’s probably best not to wrap elements just to get styling. You may not want the same styling in all outputs.

For pdf, I think the default pdf2 plugin has a links attribute template that you can override to apply formatting to the related links.

For html, look for the class attribute on the element in the html output and apply CSS. If that doesn’t work for you, then you can override its template too with a different block and attributes.

Take care,
- Nick

Sent from mobile

On Oct 24, 2019, at 10:55 AM, chrispitude@... [dita-users] <dita-users@...> wrote:

 

Hi all,


In running body text, I can wrap formatting around an to style the text that is created during production:


Also see the documentation for the command.


However, I don't see an equivalent way to do this with , as you can't wrap formatting around a


I'd rather not provide (as then it won't update per the target automatically) nor do I want to resort to @outputclass solutions because then formatting elements.


Does anyone have any clever solutions to formatting auto-generated links in ?


 - Chris




Re: Can a <link> in <related-links> be formatted?

Joe Williams
 

What's the output? HTML5? If so, you could modify the CSS maybe?


Re: DITA specialization questions

Chris Papademetrious
 

Hi da'ud,

In CSS, you'll need to match a DITA class entry value *in* the @class attribute, like this:

*[class~="topic/ph"][outputclass="actor"] {background-color:red}

The reason for the wildcard * element is two-fold:
  • It will match specializations of the element as well as that element itself.
  • When the output is published to HTML5, it might become a <span> or <div> or some other kind of thing, but it will still have the same @class value and so the formatting will still apply.
@id values definitely matter in DITA. Some elements, like <topic> elements, must have IDs. For others, it's optional (like a list item) but by defining it, you can reference that item in an <xref>. See the examples at


for different types of reference flavors that use filenames, topic IDs, element-in-topic IDs, and various combinations of those.

To configure the CSS used for authoring in Oxygen XML Author, go to Options > Preferences > Document Type Association, choose the DITA framework and choose "Extend", then in the configuration for your extension framework, go to Author > CSS tab and add your own alternate CSS file to the list. You'll then be able to choose this CSS file from the Styles drop-down in Oxygen. See:


Don't worry about asking for help, we've all been there!

 - Chris