Help Needed to Request a Feature

[Guest]

Hello folks!

There is a feature I have been awaiting paitently for years, ever since Conditional Build Tags came on the scene in RoboHelp. Adobe has gotten closer than any of its predecessors at providing this functionality, but just this week, I finally heard verbal confirmation from Adobe that it doesn't yet do what I need it to do.

I am appealing to you for help. It seems that the only thing that will motivate Adobe to provide this (or any) functionality is a preponderance of user requests on their Feature Request form. I have already filled this out more than once over the years, to no avail.

I have detailed below, in 1989 characters, just what I want and why I want it. If you are moved to also request this functionality, please go to

www.adobe.com/go/wish

select Feature Request, and if you want, simply copy and paste my text below into the form. There is a 2000-character limit, so I have tweaked the wording to make it all fit.

I have been drooling over this functionality for literally YEARS, because I must maintain 5 separate projects in order to provide my programmers with all of the different outputs (in essence, different languages) that we need.

Thanks a bundle!

Marjorie
*******Enhancement / FMR*********
Brief title for your desired feature:
Apply Conditional Build Tags (CBTs) to Topic Titles Appearing in Search Results
How would you like the feature to work?
Concise problem statement:
On all outputs, the Search Results list is being populated without my CBTs being applied.
Steps to reproduce bug:
1. Create English & French CBTs.
2. Apply English & French CBTs to topic content, including to the Topic Title, when displayed in the Design Editor pane. (This must be done in the Design Editor pane, because CBTs are not accepted by RH7 in the Topic Properties in the Topic Title field.)
3. Create 2 new duplicate layouts, which use the English & French CBTs.
4. Generate outputs for both English & French (WebHelp, FlashHelp, HTMLHelp--it does not matter which one).
5. View the French output & go to the Search tab.
Results:
6. Search for a French topic title. The Help file does indeed find the appropriate topic. However, the Search Results list displays the ENGLISH topic title. If I display the associated topic in the right-hand pane, I do see the French topic title there, as well as the French content.
Desired results:
7. The Search Results list should display the FRENCH topic title in the left-hand pane.
Why is this feature important to you?
No matter which language, our application is going to call the same specific URL to fulfill a Help request. I use the Map ID number in the Topic ID field. When I generate WebHelp output, each topic will have a "Name.htm" which appears as "MapIDNumber.htm". For instance, "388.htm" is the filename on WebHelp output for the topic whose Topic Title is "View" in English & "Afficher" in French.
This feature is important because RH7 will not allow the same Map ID number or the same Topic ID to be used on more than one source topic. I need to be able to apply the same Topic ID to whatever language condition I want, and therefore, my one source topic must contain all languages with their CBTs applied.

[Peter Grainge]

Marjorie

I can see the problem this gives you but I am not sure it is a bug.

There is a difference between the Topic Title, as in the Topic Properties and the Topic Heading, as at the top of your topic.

It sounds like your layout is to have English content and French content in the same topic and exclude whatever you need to for a particular output. I don't do any foreign language work but my understanding is that those who do maintain two topics and use the tags on the whole topic.

If a topic is in, then you will get whatever is in the Topic Title.

I suspect that would be because of the way the Microsoft compiler works and Adobe cannot control that, nor do I expect Microsoft to make any changes to accomodate this need.

Maybe some folks who work in multiple languages could chip in and advise how they work.

I am guessing that where Map IDs are used for the call, they maintain two projects so that the "same" topic can have the same ID.

[RoboColum_n_]

That is my understanding also although I, like Peter, don't do any translation work..........yet! Although it is a long way off from the top of the list of priorities for us, I think there are three two options. The first is to use separate topics as Peter describes and the other involves a translation agency and use of a separate project.

[Guest]

Hi folks,
I am doing a lot of translation work (4 languages, in the near future the 5th will be added) and I do separate projects for each of the language.
From what I saw on different other software packages, the help it is installed and to which the user has access to, is the one in the language which got selected at installation time.
So, if you are using conditional building tags, you are able to have just one project and it will display in whatever language the user desires? (Or at least this is what it is supposed to do?)
Normally, on RH7 one has to establish the language it is to be used in the project, and one has to localize the system on which the localization is being done, so I do not quite see how can somebody do a helpfile in multiple languages (especially if you use different fonts like Japanese, Simplified Chinese, aso).
Did I understand the situation correcly?
Cheers,
Bogdan

[Peter Grainge]

I doubt they are doing one file. I suspect one output for each language and the developers install the requisite output based on language selected.

[Guest]

Hello, and thank you all so much for your interest in my quest!

Since I have much to address, I will quote each person and then reply to their comments. (Ooops! I have so much to say, I must address each of your posts separately.)

quote:

---

Originally posted by: Peter Grainge
Marjorie

I can see the problem this gives you but I am not sure it is a bug.

---

Peter,

It's a bug in the sense that the output is not fully in French, in every way possible.

quote:

---

Originally posted by: Peter Grainge
There is a difference between the Topic Title, as in the Topic Properties and the Topic Heading, as at the top of your topic.

---

Yes, you are right. In the Design Editor, I am editing the topic title where the Heading style is applied. I suppose the correct term for this item is indeed "Topic Heading."

quote:

---

Originally posted by: Peter Grainge
It sounds like your layout is to have English content and French content in the same topic and exclude whatever you need to for a particular output.

---

In actuality, I use the Advanced button on the Layout to Define my CBT Expression. I choose to INCLUDE my desired CBT by Adding the Tag for a particular output.

For English, I would choose to INCLUDE my English CBT; for French, I would choose to INCLUDE my French CBT.

In my world, there are multiple English names for the very same widget. Therefore, I use multiple English conditions to deterime which name should appear for a particular widget. I mark the rest of the text with ALL of my English conditions, and mark the French text with my French conditions. (I MUST mark the English as English, simply because my source topic also contains French text. This is the only way to leave the English out of the French outputs.)

Now, imagine that I want to output just one of my English conditions. If I were to use Exclude for all of the other English conditions, then the very text that is marked for all of my English condtions would never make it into my output.

I have tested this, and found that if I simply include only the desired CBT, it works beautifully. I don't get the French, and I do get all of the appropriate text for my indicated English condition.

quote:

---

Originally posted by: Peter Grainge
I don't do any foreign language work but my understanding is that those who do maintain two topics and use the tags on the whole topic.

---

That's what Adobe tried to tell me to do. I explained to them the issue with the same URL being used in all of my conditional outputs.

For instance, I want Help to come up and display the exact topic whose name in English is "View." This topic has been assigned a Map ID of 388. I have also edited the Topic ID to use the number 388. When I generate WebHelp output, you see this topic generated as "388.htm."

Now, in my French output, this topic would have a different title appearing--in French, it would be called "Afficher." My programmers have our application programmed to call "388.htm," regardless of what language is running.

RH source topics cannot use the same topic ID on more than one topic. Because of this RH limitation, I must put the source text for both languages inside only one source topic: the topic whose Topic ID is 388.

quote:

---

Originally posted by: Peter Grainge
If a topic is in, then you will get whatever is in the Topic Title.

---

I told the Adobe employee who called me that they need to code RH so it looks for the Topic Heading material for the text they use to populate their Search Results list. He sounded intrigued by my idea, and said he would tell their engineers about it.

The only other alternative I can imagine at this point is to allow CBTs to be applied to the Topic Title text. I have even attempted to manually apply this in the HTML Editor pane. The trouble is, when I switch away to the Design Editor pane and then back to the HTML Editor pane, all of the CBTs that I manually applied have been lost--and it doesn't matter if I Saved first! They are simply discarded by RH.

quote:

---

Originally posted by: Peter Grainge
I suspect that would be because of the way the Microsoft compiler works and Adobe cannot control that, nor do I expect Microsoft to make any changes to accomodate this need.

---

This is exactly the sort of programming issue they earn the big bucks to solve--establishing workarounds for the technologies at work.

I have to believe it's solvable, because, as I have told the Adobe folks, their competitor MadCap had the exact same issue with one of their early versions, and they even told me: "The Search Results list is being populated before the conditions are being applied." I called them on it, they worked to solve it, and they ultimately did solve it in Flare by reworking one of their *.DLL files.

Maybe I'm comparing apples to oranges, but I still have faith that this can be solved. My only problem is how long it is taking to get this issue onto their radar. I have been requesting this functionality for over 1.5 years!

quote:

---

Originally posted by: Peter Grainge
Maybe some folks who work in multiple languages could chip in and advise how they work.

I am guessing that where Map IDs are used for the call, they maintain two projects so that the "same" topic can have the same ID.

---

I already do this in RH X5. I maintain five separate projects, which contain about a dozen different conditions.

However, I have never yet used CBT functionality on the text in my 5 projects, because my source remains in Word to this day, and only RH HTML even comes close to giving me the conditional output I require. In today's Help files, our users must read and find the text that applies to their condition, because they are often presented with text like so:

Condition A
* If you are Condition A, then the software does this...
Condition B
* If you are Condition B, then the software does this...
Condition C
* If you are Condition C, then the software does this...
Condition D
* If you are Condition D, then the software does this...
Condition E
* If you are Condition E, then the software does this...

I was actually asked to split out our conditions in this manner by managers at my company.

Now, if I were a user, I would HATE having to read documentation like this.

We actually split out our conditions in this way in 2002!, anticipating that eHelp or (later) Macromedia or (now) Adobe would provide the CBT functionality so I could hide all of the other conditions, and give my users a Help file customized specifically for their business line. It's now 6 years and counting...

Since I will have some major prep work to do in order to import my text with minimum pain into RH 7 HTML, I just won't do it until or unless I can prove that I will be able to output all of my conditions flawlessly. It doesn't pay my company to do the import and cleanup if we can't produce the product we are required to give our users.

Marjorie (reply 1 of 4)

[Guest]

quote:

---

Originally posted by: Colum McAndrew
That is my understanding also although I, like Peter, don't do any translation work..........yet! Although it is a long way off from the top of the list of priorities for us, I think there are three two options.

---

Colum,

It sounds like you thought of 3 options, but discarded one? I'm curious about the one you may have discarded. Please, do tell.

quote:

---

Originally posted by: Colum McAndrew
The first is to use separate topics as Peter describes

---

In effect, I already do this by virtue of the fact that I currently maintain 5 separate projects in RH X5. That way, I can use the same Map ID on "View" (#388) as I do on "Afficher" (#388).

quote:

---

Originally posted by: Colum McAndrew
and the other involves a translation agency and use of a separate project.

---

Yes, I already do use a translation agency and separate projects in my current world.

Marjorie (reply 2 of 4)

[Guest]

quote:

---

Originally posted by: Boggym
Hi folks,
I am doing a lot of translation work (4 languages, in the near future the 5th will be added) and I do separate projects for each of the language.

---

I do this, too, Bogdan.

quote:

---

Originally posted by: Boggym
From what I saw on different other software packages, the help it is installed and to which the user has access to, is the one in the language which got selected at installation time.

---

That is true for our client/server apps.

For our Web apps (which are simply a Web version of our client/server apps), we use the WebHelp output. When a user logs in, the login credentials determine which system they see, and theoretically, this would extend to which Help system they would be served.

quote:

---

Originally posted by: Boggym
So, if you are using conditional building tags, you are able to have just one project and it will display in whatever language the user desires? (Or at least this is what it is supposed to do?)

---

If you are guessing that the Help file would dynamically sense which type of user (English or French), and would serve up the appropriate Help system, then no. It would have to be the login credentials which determine which Help system would be served, and only one Help system would be served, with no option to switch to a different one.

quote:

---

Originally posted by: Boggym
Normally, on RH7 one has to establish the language it is to be used in the project, and one has to localize the system on which the localization is being done, so I do not quite see how can somebody do a helpfile in multiple languages (especially if you use different fonts like Japanese, Simplified Chinese, aso).

---

Hmm, Bogdan, you are making me wonder about something. Our client/server app is the only one we have produced in French as of today. (The Web version of this is not yet available.) When I compile the WinHelp for that French client/server app, I was originally concerned, because the TOC, Index, and Find tabs were showing up in English in my French Help file. However, it was discovered in testing that if this same Help file was run from a French-localized PC, these tab labels were driven by the localization on the PC in question (driven by the OS). So, we did not have to worry about it.

In my testing of RH7, Adobe asked me to try changing File > Project Settings > Language to "French (Canada)" to see if this would solve my issue with the Search Results list. While it did nothing to solve this issue, it did affect the tab labels on my French WebHelp output, which is what I tested.

Hmmm, you are making me wonder: will I have to manually change this setting when I want to compile my French outputs, so that they will come out right? Or will the WebHelp tab labels be influenced by the PC on which the Help is viewed? This raises more questions...I'm glad to know this could be an issue, because it certainly affects which outputs I generate at any given time using the Batch Generation process...

quote:

---

Originally posted by: Boggym
Did I understand the situation correcly?
Cheers,
Bogdan

---

Bogdan, you made me wonder about my OWN understanding of all of this...thanks for the heads up!

Marjorie (reply 3 of 4)

[Guest]

quote:

---

Originally posted by: Peter Grainge
I doubt they are doing one file. I suspect one output for each language and the developers install the requisite output based on language selected.

---

Peter,
You are right for our client/server apps, and (just a little) wrong for our web apps. See the above explanation I wrote to Bogdan about maintaining separate projects and the output we use for our web apps.

THANK YOU TO ALL, and I look forward to your replies.

Marjorie (reply 4 of 4)

[Guest]

You are welcome Marjorie!
I know that I had the first big issues when I did my translation in Japanese, and everything was nice in the content, however the TOC and indes were in a language not from this world.
After I talked to the forum, and thanks to those great guys, I got the first glimpse about the fact that I have to localize the machine where I am doing the development work and compilation so that I will have the results in that language.
If you do the localization for one zone, do it completely. Like, if you do a French localization, do it for France, and not French-Canadian, OK? And do it in the whole Regional settings of Windows. Otherwise you might get some mixed results.
It takes a reboot after you do that, but I think it is worth it.
Have fun,
Bogdan

[Guest]

Bogdan,

So, if I understand you correctly, this is what you are telling me:

If I want to output WebHelp for my French-Canadian output, it is NOT enough to simply change File > Project Settings > Language to "French (Canada)." You are telling me I must configure the PC where I plan to generate my French-Canadian output so that the OS is ALSO localized?

Ugh. I will have to make sure I write myself a reminder to do this when I am producing my French-Canadian output for a Production version, because I won't be doing this much configuring all the time...

Marjorie

[Guest]

Marjorie,

First, without having read the entire thread, I'm guessing that you're providing help for localized software. My suggestion is that you may want to coordinate with your testing folks, who should be testing the software in all languages. Maybe you could arrange with them to test on different computers rather than trying to reconfigure your own computer multiple times. I don't think the burden should be entirely on you to be testing your outputs in various languages because typically each of your users will have his/her computer configured for one language, so in theory the output in his/her particular language would work on his/her particular machine. (In other words, I would think it's rare that the same end user is going to want to view the help in multiple languages, so they wouldn't encounter the problems inherent in trying to generate help in multiple languages on the same computer.)

Just a thought...

--Ben

[Guest]

Marjorie,

What I meant is that you have to go through all the tabs from the Regional settings dialogue. And, if you want to do the localization for Quebec only, then go for French-Canadian. I thought that you would like to make it generally for French speaking users.
I am doing the localizations for all those 4 I mentioned above on my system, and it is OK with me to localize my system as I am moving to a new project in a new language.
As Ben was saying, I also do not see why a user would like to see help in multiple languages, and it is also just a thought of mine.

Cheers,
Bogdan

[Peter Grainge]

Marjorie

IT'S A BUG IN THE SENSE THE OUTPUT IS NOT FULLY IN FRENCH

I understand your view but one could argue it is not a bug but a problem caused by the fact that you are trying to get multiple languages out of one project instead of having one per language, which I believe is the normal practice. In other words, you could argue the product is working as designed and you have chosen to use a different approach. That does not mean your approach is wrong, simply that it does have this deficiency. I am not seeking to argue with you on this, just saying there might be a different view. Read on before reacting.

RH SOURCE TOPICS CANNOT USE THE SAME TOPIC ID IN MORE THAN ONE TOPIC ... SO BOTH LANGUAGES GO INTO ONE TOPIC

If you did have one project per language, that would not be a problem. The developers would simply install the output for the language and the map ids would work.

ADOBE EMPLOYEE INTRIGUED BY IDEA OF SEARCHING TOPIC HEADINGS

It already does that. The problem is that in the list displayed, as with the index, it is the topic title that gets displayed in the list of results and, as previously, the topic title is not necessarily the same as the topic heading.

Many authors have their projects set up knowing it will be title that appears in the search results and will choose to have a heading that is not exactly the same. If the change is mandatory, those customers will be knocking on your door! Would I be right in thinking the Flare DLL changed things to what you want but does not give an option? The good news is that if MadCap have made that change and the compiler is happy, then the way that works is not an issue. So a change request on that might be more forthcoming.

HOW TO GET WHAT YOU WANT

I wonder if the previous requests got lost because those evaluating because they took the view the problem could be avoided. I am not saying they did or that you should change your way of working. Simply that other requests got prioritised. I'm with you, just putting a possible angle on it and trying to help put it in a way that will succeed.

I recently responded to a post where somebody wanted the topic title to be a user defined variable (introduced in RH6) and it occurs to me that you could use that idea. Each topic title would be a variable and you would define the appropriate values for each language. So try posting this on the wishlist as it combines your requirement with another thereby increasing the chances.

****************************************
When a user searches, the list displayed is the relevant Topic Title. There should be an option for this to be based on the Topic Heading as conditional tags and variables would then allow different lists of results to be generated for different outputs. For example, different languages or different customer names.

****************************************

The last part of your post, if I have understood it correctly, sounds like merged help is needed where each customer has the parent and the children relative to their condition.

Hope that helps.

[Guest]

Peter,

I was rereading this thread today, and realized I never got around to replying one last time. So, here goes:

quote:

---

ADOBE EMPLOYEE INTRIGUED BY IDEA OF SEARCHING TOPIC HEADINGS

It already does that. The problem is that in the list displayed, as with the index, it is the topic title that gets displayed in the list of results and, as previously, the topic title is not necessarily the same as the topic heading.

---

I earlier stated that "they need to code RH so it looks for the Topic Heading material for the text they use to populate their Search Results list." Yes, I understand that RH searches the Topic Headings in order to build the Search Results list. I meant that they should use only Topic Headings to write the list of results, and not use the Topic Titles.

quote:

---

Originally posted by: Peter Grainge
Many authors have their projects set up knowing it will be title that appears in the search results and will choose to have a heading that is not exactly the same.

---

Peter, since we last commented on this thread, my new boss is now asking me to create a combined RH 7 project that will contain all of my English conditions. She will be attempting to get the business to buy into the idea of simplify the naming conventions that are being used by the company, so that the same widgets will have the same names in English, at least.

Right now, in today's world, if you are Condition A, then a certain widget is called [this], but if you are Condition B, then the same widget is called [that]. Even though both [this] and [that] are both in English, they each use a different term for the same widget, and this fact has caused us to maintain separate projects thus far, just as if they were different languages! What is a different language to RH, anyway, if not a different string of language characters?

In any case, even if her attempt is not successful, your comment here has given me an idea:

EVEN IF I must create a Topic Title that says something like "Creating a [This] or a [That]," I could still make each conditional Topic Heading reflect only the one desired condition:

"Creating a [This]"
or
"Creating a [That]"

In this way, I could limit how kludgy my Topic [ahem] "Titles" appear in the rest of the Help file: only the Search Results list would contain a title like

"Creating a [This] or a [That]"

However, in the right-hand pane, where the topic is opened, on the TOC tab, and on the Index tab, I could conditionalize my output to show only

"Creating a [This]"
or
"Creating a [That]"

--based on the desired condition, of course.

quote:

---

Originally posted by: Peter Grainge
Would I be right in thinking the Flare DLL changed things to what you want but does not give an option? The good news is that if MadCap have made that change and the compiler is happy, then the way that works is not an issue.

---

I was not given an option, and the updated Flare DLL did give me the output I wanted.

quote:

---

Originally posted by: Peter Grainge
HOW TO GET WHAT YOU WANT

I wonder if the previous requests got lost because those evaluating because they took the view the problem could be avoided.

---

Peter, I'm with you on this. I think this is exactly why it has not happened yet in RH.

quote:

---

Originally posted by: Peter Grainge
I recently responded to a post where somebody wanted the topic title to be a user defined variable (introduced in RH6) and it occurs to me that you could use that idea. Each topic title would be a variable and you would define the appropriate values for each language.

---

Hmm, if RH would only use the Topic Headings instead of the Topic Titles, then I could use user-defined variables for some of the words in my titles, but not for the whole title. However, your workaround could be useful if this idea was embraced by Adobe's developers.

In today's RH 7, though, the Topic Title field appears to use only straight ASCII alphanumeric data (letters, spaces, and numbers) to the exclusion of any codes that stand for things like CBTs, user-defined variables, etc. Any CBTs I attempted to apply manually on the HTML Editor pane were simply discarded by RH, and it did not matter if I Saved first. So, Adobe has some major progamming to do to make this a reality.

quote:

---

Originally posted by: Peter Grainge
So try posting this on the wishlist as it combines your requirement with another thereby increasing the chances.

---

Yes, I agree, combining wishlist requests should increase the chances of success.

quote:

---

Originally posted by: Peter Grainge
****************************************
When a user searches, the list displayed is the relevant Topic Title. There should be an option for this to be based on the Topic Heading as conditional tags and variables would then allow different lists of results to be generated for different outputs. For example, different languages or different customer names.

****************************************

---

This restates what I said above about "they should use only Topic Headings to build the list of results, and not the Topic Titles." It also incorporates the use of both CBTs and user-defined variables in the data that populates the Search Results list.

quote:

---

Originally posted by: Peter Grainge
The last part of your post, if I have understood it correctly, sounds like merged help is needed where each customer has the parent and the children relative to their condition.

---

I'm not sure where you get the idea that I'm using merged help. I've actually never done this.

quote:

---

Originally posted by: Peter Grainge
Hope that helps.

---

Yes, Peter, it does. Thank you.

Marjorie

[Peter Grainge]

"I may be gone for a while" while I read this.

[Peter Grainge]

Marjorie

So to summarise you need either or both of the following:

1] Topic titles that can be conditionalised.

2] The option to use Topic Headings rather than Topic Titles in the list of topics displayed in response to a search.

I will put this forward but I cannot support changing from Topic Titles to Topic Headings. Too many users would not want that so it has to be an option.

Also I still do not accept this is a bug. This is working as designed. The fact that it does not suit your method of working does not make it a bug. What is needed is a feature change. It is one that would suit other users for various reasons.

Looking through the thread, it does seem as though using variables could be a benefit to you.

You commented that you didn't know where I got the idea that you are using merged webhelp. I didn't get that idea. I suggested that you might want to consider using it.

[Guest]

Peter,

Thanks for taking the time to reread this thread, and thank you for replying.

quote:

---

Originally posted by: Peter Grainge
So to summarise you need either or both of the following:

1] Topic titles that can be conditionalised.

2] The option to use Topic Headings rather than Topic Titles in the list of topics displayed in response to a search.

---

The functionality in the first option is already available, except in the case of the titles that appear in the Search Results list, which is what you are discussing in the second option.

quote:

---

Originally posted by: Peter Grainge
I will put this forward but I cannot support changing from Topic Titles to Topic Headings. Too many users would not want that so it has to be an option.

<snip>

Looking through the thread, it does seem as though using variables could be a benefit to you.

---

Most definitely. Being able to use variables in the Topic Title field and in the TOC (not just in the Topic Headings and in the topic content) would be a tremendous benefit. Perhaps you can emphasize this when you put this forward, like you said before, by combining the feature requests in order to have a better chance at success. Thank you!

quote:

---

Originally posted by: Peter Grainge
Also I still do not accept this is a bug. This is working as designed. The fact that it does not suit your method of working does not make it a bug. What is needed is a feature change. It is one that would suit other users for various reasons.

---

The reason I originally referred to this as a bug is because RH/Adobe made functionality promises that didn't pan out, yes, in my preferred method of working. They should have put conditions on their statement that you could 'handle more than one condition in the same project.' It works great when you include or exclude whole topics and/or content, but if you attempt to use more than one name for a single widget, and you want to include each of these different names in separate outputs, all from one project, the results don't deliver. Whether we call it a bug or a feature request, that still doesn't change the fact that it does not work as designed today.

quote:

---

Originally posted by: Peter Grainge
You commented that you didn't know where I got the idea that you are using merged webhelp. I didn't get that idea. I suggested that you might want to consider using it.

---

Ahhh...I misunderstood your wording as if you were commenting on an existing situation with my company that I was attempting to meet with this functionality, when in fact, I have no working knowledge of it. Ahh, the difficulties of email communications! Gotta love it!

I'd like to close by saying that I do appreciate wrestling with these issues with you. I often look to you for suggestions and advice, and I appreciate your help. Thanks for persevering, and for all the time and effort you put forth on behalf of the RH community. It is definitely noticed.

Marjorie

[Peter Grainge]

Tell me how to conditionalise a Topic Title. I know how to conditionalise a Topic Heading, that is at the top of the topic and you apply a condition. The Topic Title appears via Properties and I don't believe you can conditionalise that. That is why I suggested [1] above so that you could apply a condition.

What promise is it you believe that Adobe have not fulfilled? You say

They should have put conditions on their statement that you could 'handle more than one condition in the same project.' It works great when you include or exclude whole topics and/or content, but if you attempt to use more than one name for a single widget, and you want to include each of these different names in separate outputs, all from one project, the results don't deliver.

Give me an example of what you mean by that.

[Guest]

quote:

---

Originally posted by: Peter Grainge
Tell me how to conditionalise a Topic Title. I know how to conditionalise a Topic Heading, that is at the top of the topic and you apply a condition. The Topic Title appears via Properties and I don't believe you can conditionalise that. That is why I suggested [1] above so that you could apply a condition.

---

Sorry, Peter, I was thinking like a Help user when I responded to you, not a Help developer using RH.

You are absolutely right, and I've bemoaned this myself throughout this thread.

When a user sees a topic title ( generically speaking, not specifically the data from that particular Properties field), it will appear in the TOC, in the Index, or in the right-hand pane when they open a topic.

All of those items that users see can be conditionalized.

You can create a TOC for each condition OR you can apply CBTs to TOC books and pages,

You can apply CBTs to Index Keyword entries, and

You can apply CBTs to the Topic Headings so that what users see in the right-hand pane uses the conditions.

What you cannot conditionalize is the Topic Title field contents, which is what RH uses to build the topic titles it uses in the Search Results list.

quote:

---

Originally posted by: Peter Grainge
What promise is it you believe that Adobe have not fulfilled? You say

They should have put conditions on their statement that you could 'handle more than one condition in the same project.'

---

I'm not clear what you are asking me. That is the promise conveyed by the RH feature descriptions I have read over the years, when I've been drooling over Conditional Build Tag functionality. Within one project, it can currently be successfully applied to all elements of a Help file except for the Search Results list.

[Guest]

Whoa, I obviously don't know how to use the bullets feature on this forum!

Here's what I treid to include in my 3 bullet points above:

* You can create a TOC for each condition OR you can apply CBTs to TOC books and pages,

* You can apply CBTs to Index Keyword entries, and

* You can apply CBTs to the Topic Headings so that what users see in the right-hand pane uses the conditions.