Production/Search bug - fixed in RH8 ?

[Guest]

Hi all,

in previous versions the search also found topics that were neither in the TOC nor referenced by hyperlinks. I allways had to add additional build tags only to tell RoboHelp not to produce topics that arent in the help TOC.

This was evidently buggy because nobody wants ALL topics appearing in the search even if they are neither in the TOC nor refenenced in any way.

With the new unicode support, RH would now offer the possibility to pack several languages into one project and to produce the different help files with separate single source layouts. I cannot imagine that Adobe would leave this problem unadressed, because each help file would contain ALL topics unless the author goes through the painful procedure of tagging them all with build tags.

Perhaps this problem has been solved in RH8, or there is another workaround?

[RoboColum_n_]

RH8 does offer the ability to exclude a topic from the search but this is set in the topic properties so would need to be set/unset as required for the single source output. The solution is still the use of build tags but I can't see why this is such an issue. This is precisely the kind of scenario build tags was invented for.

As an aside, could you arrange topics in different languages into separate folders and then apply a build tag to the lot in one fell swoop?

[Captiv8r]

Hi all

Hopefully Colum won't mind my chiming in on this as well.

Robert, Column is spot on with his statement about this being what Conditional Build Tags are intended to address.

Perhaps it might make more sense to you if we put it in different terms. Think of your help project as a big ole picnic basket. Perhaps you will use the picnic basket to carry Breakfast items, Lunch items, Dinner items or just for Snacks. In this case Breakfast, Lunch, Dinner and Snacks represent the possible uses for the basket.

You make different lists of what is inside according to whether it's Breakfast, Lunch, Dinner or Snacks. Think of the list as representing different TOC structures. Note that at this point the basket still includes everything.

Conditional Build Tags and the Conditional Build Expression are similar to using a list that says "Lunch items only". So anything not related to lunch gets pulled out of the basket, leaving behind only the lunch items.

I know in your case it would seem pretty straightforward to conclude that nobody would ever want a help output that has items not referenced by the TOC or by links in topics. And to an extent I might agree. But there are many help files produced that have exactly that setup and for good reasons. The reasons? Context Sensitive Help.

Many help authors have topics inside the help that are only referenced when the companion application issues a call for help and instructs to display a topic that is specific to the task at hand.

I'm not sure if I've actually helped here or just served to muddy the murky waters even more. But please know it was an attempt at helping.

Cheers... Rick

[Guest]

Hi all,

thanks for the helpuf information and comments!

Sorry - I´ll keep my opinion.. if a topic is not referenced (neither in the TOC, nor in other topics, nor in the map/ali files etc.), then it should not be included because the user will never be able to access it.

I do actually (or think so) understand the concept of conditional build tags. As long as multiple TOCs were not supported, this was the only way to seperate different output help versions.

But if you have 11 languages and three different versions in one project (Adobe encourages the multi-lingo-single-project-approach in their documentation) then thats a lot of tags to apply just for three basic help version.

RoboHelp should (or could..) be intelligent enought to include non-TOC topics for context-sensitive help into the output because these are referenced in the map/ali files.

The idea of organizing the topics in folders for different languages is principially the way to go. Regretably the customer who initiated the project does not separate by language (i.e. language folders) but rather by software modules due to other requirements. I guess we will try to convince him to reorganize based on languages.

Thanks again for the feedback!

[RoboColum_n_]

Hi Robert.

I also can't help but wonder how RH would know if the topic was intentionally left out of the TOC (e.g. a redirect topic) or if I just plain forget to add a topic to the TOC

[Guest]

Colum, I really hope RH will not intend to make such decisions for me in a future release..

But I think I did overlook something. I got mixed up with FL... anyway the other program. In RH, you cannot determine which map/ali-files are used in an output. So basically, if you have different context-sensitive help versions using different map/ali files, then RH cannot keep them apart. In this case, there would be no way to tell which topics are really needed in which output, except for manually applying build tags.

OK you was right..

[RoboColum_n_]

No problem Robert. As an aside, I think that Adobe have done a lot in the last couple of years to listen to their users and continue to do so. They don't always do what I'd like them to do but I feel a little more respected if they listened to me and made a considered decision. You can always use the wish list form for any enhancements you'd like (not) made.

[Captiv8r]

Hi all

And now, for my own comments.

Robert, I know you said Adobe encourages the multi-lingo-single-project-approach in their documentation.

Personally, I think I disagree with the approach. I would think it much simpler to have a different help project for each language. Most likely you won't be the person doing the localizing (translating). If the project is being converted from English to perhaps Spanish or French it would seem to me that it would be far more efficient to hand off a complete project to be translated than it would be to figure out which topics need translating.

But that's just me.

Cheers... Rick

[Guest]

I used the whishlist now, it can´t hurt. I requested to add a checkbox in the SSL to include only those topics in the output that are referenced in in either TOC, map/ali files, via hyperlinks in other topics or in the index.

Concerning the multi-lingo-single-project (I´ll call it MLSP), it makes things easier when you have common screenshots, stylesheets etc.
We don´t hand off RoboHelp projects, only the required files. As Colum mentioned above, organizing the languages in separate folders makes things a lot more simple.

I understand your concerns thought, in the previous versions we always worked with separate projects too so this is a new approach for me as well. I guess the MLSP does increase the possibility of making mistakes. For example, in a project with a Russian translation I have to swith the project language before each producion or else the TOC is scrambled.