2 Replies Latest reply on Mar 20, 2017 12:29 PM by RoboFan

    Convert topic-based glossary to .GLO glossary

    RoboFan Level 1

      Not a question. Just sharing the knowledge I gained from converting our RoboHelp HTML topic-based glossary to RoboHelp HTML's .GLO glossary.

       

      For years we've provided a glossary via a single topic; terms and definitions were presented in 2-column tables - one table for each letter, A-Z, top to bottom. Jump links for each letter at the top of the topic. For various reasons, I've been looking at the .GLO function (I really like the hotspot wizard, but I'm still not sure if it'll create any unintended formatting consequences with our content (thousands of topics)). We have a couple hundred terms and manually copying/pasting them in RoboHelp HTML is NOT something we want to do so I decided to see if I could automate most of the process (particularly since there's a single .GLO file and the guts of the terms/definitions is basic HTML).

       

      What you'll need:

      • RoboHelp HTML 10 or RoboHelp HTML 2017 (likely applies to other versions; we have these two so I can verify it worked in both)
      • MS Excel (or some spreadsheet application)
      • Notepad++ (free)

       

      These are the basic steps. It took a little trial and error so these may not be exact, but there should be enough here.

      • Copy/paste terms+definitions from tables in topic to Excel.
      • Since our terms+definitions were in tables, the definitions appeared in the same row as the corresponding term, but also in a separate column.
      • Insert columns for each HTML tag so you end up with this in each row. This gives you 8 columns:

       

      <glossentry> | <glossterm> | TERM | </glossterm> | <glossdef> | TERM DEFINITION | </glossdef> | </glossentry>

       

      excel-glo.jpg

       

      • Copy/paste everything from Excel to Notepad++. Excel automatically inserted tabs between each column (this is good, because it makes it easier to search/replace in Notepad++ to format everything properly (see the next step)).
      • Use the Notepad++ replace tool to insert/remove tabs and properly format the line breaks (I had to use the Extended search mode with the \r\n switch) for the .GLO file. (Note: I'm really glossing over exactly what I did - find/replace-wise - to get the raw content (HTML codes, terms, and defs) formatted in standard .GLO format, but if you're reading this you should be able to figure it out - it's very easy.)
      • Once you have everything in Notepad++ formatted/looking like the .GLO file, copy/paste it to your .GLO file. The terms/defs should appear in the Glossary editor in RoboHelp HTML.
      • IMPORTANT: If nothing appears in the Glossary in RoboHelp HTML and all your open/close <glossentry>, <glossterm>, and <glossdef> tags are correct, you likely have an illegal character within your actual term or definition content. For example, an ampersand will cause this problem. Remove the problem character (view the content in Notepad++, which automatically displays characters like this in a different color) and should be good to go!
        • 1. Re: Convert topic-based glossary to .GLO glossary
          Captiv8r Adobe Community Professional & MVP

          Hi there

           

          Nice of you to provide the steps needed in the event someone needs them.

           

          I'm curious, however, about what led you to the decision to abandon your topic glossary and opt instead for the RoboHelp supplied glossary?

           

          When I facilitate a RoboHelp class, I usually mention that one also has the option of a Topic glossary as well as describing the limitations of the RoboHelp glossary. For example, using just the GLO file, you aren't able to insert images and provide links that point to additional content.

           

          Cheers... Rick

          • 2. Re: Convert topic-based glossary to .GLO glossary
            RoboFan Level 1

            Hi Rick. We haven't committed to switching, but we're evaluating it. We have several hundred terms, and manually copying/pasting those from a topic to the GLO pod would probably be sufficient to nix such a move. So this was a proof-of-concept exercise to see if/to what extent I could automate the switch. As to why we're considering the switch, here are several factors:

             

            • Broken JS: Our current single-topic glossary uses a custom JS file + topic to deliver 26 static letter jump-links (A, B, C, etc.) at the top of the topic; it was developed for us by a contractor nearly 15 years ago. It worked great while we were publishing CHM help, but we're moving to Responsive/HMTL5 output and it doesn't work there. I haven't dug into how to repair it, or what else we could replace it with while maintaining the single-topic enviro because.... (see next point)
            • Glossary Hotspot: I demo'd the hotspot feature in a smaller project and our users thought it was really slick. By delivering a term's definition in the topic, users don't have to "leave" the topic to go look it up. I do have concerns about running the wizard against a project with several thousand topics (manually choosing which "term" instances to apply it to/which to skip vs. crossing our fingers, holding our breath, and auto-applying to all instances and the likelihood that a term or phrase in a topic shouldn't receive the hotspot); not to mention the fact that we'll have to run the wizard every time we update the project (term, definition, or topic).
            • Output Integration/Accessibility: We like the way the glossary integrates with the responsive layout in RH2017 (always accessible, accessible similar to the other standard functions, etc.).
            • Less Content:
              • Content Development: We're transitioning from waterfall to Agile. With a bigger focus on providing core/basic content, we're trying to be more concise and less explicit in our content. This means less content.
              • Output Display: As we transition from CHM to responsive/mobile-based output, screen real estate carries a bigger premium; so we're content to exclude images from definitions.

             

            Obviously, many things to consider! We haven't made a decision, so if you have any additional thoughts on one vs. the other, please share!

             

            Thanks!