Keeping a Comment in Generated Output?

[Jared Hess]

So, the way our localization process is currently setup, we generate a chm file from RH, then decompile the chm to get all the .htms etc and then we send the dcompiled info to the translators. I'm looking for a way to include author comments for our translators into the source and then have those comments show up in the final output but not show up visible to our customers. Any suggestions on how to do this?

I've tried creating a conditional build tags called "TranslationInstructions".

But something like this in the source...

<?rh-cbt_start condition="TranslationInstructions" ?><p class="BodyText">Test

instructions for the translator.</p><?rh-cbt_end ?>

...shows up as this in the output:

<p class="BodyText">Test

instructions for the translator.</p>

That doesn't help because it pulls out the conditoinal idendifying bits.

I also tried doing a standard HTML comment, like this:

<!-- Translation Instructions: Make sure the info below is blah blah blah -->

But this is excluded completely from the generated output.

Any other ideas? Is there a way to define a custom tag that gets passed through to the output but that isn't recognized and displayed in a browser (help viewer)?

[Willam_van_Weelden]

Hi,

In the topic properties, you can add comments. Could that be what you need?

You can also try to add meta tags to your topics. I think they are retained in the output, but you'll have to add thos tags manually in HTML view. See http://www.webmarketingnow.com/tips/meta-tags-meta-author.html for an explanation.

Greet,

Willam

[Jared Hess]

Thanks Willam.

Unfortunately, the topic comments via properties won't help. Since our translators do not translate from the RH project, this wouldn't be visible. We need something that will survive at the tag level and end up in the generated output at the code level but won't be interpreted by the browser. Like if I could define some sort of custom tagged pair like this: <translation_instructions>Translators, please be aware that... blah blah blah</translation_instructions>.

Meta tags might work, but the limitation is that the note could only be added into the header. I'd like to be able to add it into the actual body of the html file if possible.

[Captiv8r]

Hi gents

Ummmm, is there a reason you can't simply click Insert > HTML > Comment and add your desired comments via the ensuing dialog? I just tested and the comments I add that way seem to be part of the CHM after I generate.

Just wondering... Rick

Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7, 8 or 9 within the day! Adobe Certified RoboHelp HTML Training SorcerStone Blog RoboHelp eBooks

[Jared Hess]

Thanks Rick. That was weird. I'm 90% sure that when I tested this the first time, it didn't work. Yet this time using the HTML comment did work. Maybe I was looking at a different file when I did my initial test or something. We'll give it a try for now. Thanks again.

[Jared Hess]

Ok. We did some tests, while the comment HTML tag <--!  --> does appear in the output, the tool our translators use (Across language server) doesn't expose this to them. Back to the drawing board.

[Willam_van_Weelden]

How about using hidden fields? Insert > HTML > Form > Hidden field. They show up in the Design view but are invisible in the output. The value of the hidden field could be your comment.

Greet,

Willam

[Captiv8r]

Hi Willam

I think something you stated contains the rub.

You said: ...They show up in the Design view...

That would imply that the translation company is using RoboHelp as well. And if they were, that would be great because even the comments show up in Design View if you choose to show them.

But in Jared's reply, he said: ...the tool our translators use (Across language server)...

That seems to suggest they aren't using RoboHelp to edit the content.

Cheers... Rick

Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7, 8 or 9 within the day! Adobe Certified RoboHelp HTML Training SorcerStone Blog RoboHelp eBooks

[Willam_van_Weelden]

Hi Rick,

That's not exactly what I meant with that remark. Hidden fields are retained in the output and I hope the translation tool picks up the hidden fields. The fact they are visibile in the design view will just make it workable for the author in RoboHelp.

Greet,

Willam

[Jared Hess]

JaredHess wrote:

So, the way our localization process is currently setup, we generate a chm file from RH, then decompile the chm to get all the .htms etc and then we send the dcompiled info to the translators.

As previously stated, the translators aren't using RoboHelp, just the authoring team is. Translators are localizing decompiled chm files. I'll take a look at Hidden fields.

[Captiv8r]

Hi Jared

Yeah.... about that process.

Why are you taking that approach? I must be missing something. Please allow me to try stating the process but using different terms.

You said you compile a CHM, then decompile it? To me, that's like saying that you need a company to work on tires for new cars. So you assemble the car first, then you take the tires and wheels off and remove the tires so you can ship the tires to the company. So what are you gaining by sending the HTML files from a decompiled CHM? Why not send the "pre-compiled" files from the RoboHelp project?

Cheers... Rick

Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7, 8 or 9 within the day! Adobe Certified RoboHelp HTML Training SorcerStone Blog RoboHelp eBooks

[Jared Hess]

For a few reasons. Some were due to merely what we believed to be true the time we first started using RH (version 5.x) and may not have been founded on fact and may not be applicable anymore, but here's what they were:

• Translators would have needed to to have copies of RH to do the translation (maybe only in some languages?). We didn't want to foot the bill.
• We were nervous about how RH-specific kadov tags were going to affect our existing translation memory so we wanted to strip out anything specific to RH from the localized content.
• We weren't sure how to handle conditional build tags at the sentence level. We have many items that are written like this (pseudo code): "Please see the such and such concept <printonly>below</printonly><onlineonly>here</onlineonly>." I realize now, of course, that such items should be written as separate sentences and each sentence should be conditionally marked. But that too would then drive up costs of translation. Very big project with thousands of htms.

Anyway, we've started localizing a test RH project to learn the ins and outs and determine ways of improving our localization process. While I see benefits to localizing the RH project and would LOVE to make the switch, the biggest reason we don't right now is simply due to cost:

From our tests we'd take around an 80% hit in 100% matches in our existing translation memory segments due to all the RH-specific tags RH adds into the htms at the project level. We have lots of translation memory and 17 languages. It adds up to lots of money.

So we're kind of locked into the process for our older projects, even though it's not ideal. So it's cheaper to disassemble the car to get the tires, than to redesign the entire car piece by piece, though I imagine that's what we'll have to gradually do as we move forward.