making images conditional

[kmaddox1]

This isn't necessarily an RH support question, but it does apply to using RH in the real world...

Here's my dilemma: I've been working for some time on a project that will soon be translated into a number of different languages. I'm trying to do what I can now to reduce the localization costs later. One area I've been looking into is making the Help usable with or without images.

Currently I use SnagIt screen shots to illustrate my instructions and examples. In most cases, these aren't simple screen grabs--to produce a typical image, I set up our software to display just the right text, then edit the captured image in SnagIt. While I've gotten feedback that these illustrations are helpful, I realize that they're going to be expensive to localize. I've also observed that I when I hide the images (by applying a conditional "no graphics" tag to each image), the Help is still useful--just not quite as painstakingly friendly as before.

Which brings me to my questions:
1. Is there a way to apply a conditional tag to a style? That is, if I wanted to hide all images in the output, could I somehow add my "no graphics" condition to my "figure" style? (vs having to style the paragraph and then apply the condition).
2. When translation companies work on RH files, how do they work with images and conditional text? That is, is the right approach simply to apply an "English-only" condition to the highly customized graphics that I don't want localized and then request that they apply this condition when generating any output in the other languages?
3. Is there another approach I should consider instead?
Thanks in advance for your ideas and insights.

[RoboColum_n_]

Hi Kathy.

There is no way to apply a build tag to a style. You will have to apply the style and then the build tag. As far as how the translation company would work, I think that is entirely a matter for you. They should only translate what you require. You should tell them up front that anything tagged with an "english only" condition should not be translated.

BTW I think you are right about the images not being entirely necessary. Without wanting to start an "images" or "no images" debate I try and avoid them where possible.

[MergeThis]

If you initially save your SnagIt capture as a .snag file, you could then make copies of that base file for each language (Fig3_Fr.snag, Fig3_Deu.snag, etc.). You would then "layer" text translations (using Tahoma or Arial, as defined in your app) over the original locations in each of the localized .snag files, and save subsequent iterations as .gif files for insertion into your RH project. Text inside text boxes are easier, but labeled text would need to use the specific window background color for your app.

Whether you do this with the translated text supplied by your localization provider, or they do it, would need to be determined.

You could then conditionalize the various graphics versions at each location and produce your localized outputs (a build tag phrase of NO FR and NO US, for example, to get the German DEU version).

Of course, I would delay doing the translation-text-layering thing until the developers were done designing on-the-fly, as it were.


Good luck,
Leon

[Linux Rules]

Hello Kathy -

Several questions and "thinking out loud" idea.

> How will the application be distributed - all languages at once (selected during setup) or language specific distribution?

> If "all in one" how are the Help files positioned/integrated into each language build? For example, do you have a file structure something like this:

[root] Install
|
|-EnglishApp
| |
| EnglishHelp
|
|-FrenchApp
| |
| FrenchHelp
(etc)

> Regarding your app screens/windows by language, are fields and labels in the same location (coordinates) on each language version (with the exception of label lengths)? Are the app screens/windows the same size (as in "x" pixels by "y" pixels) language-to-language?

If the Help is a subset of the app by language and the windows/fields/labels are the same size and coordinates (such that overlaying English window screen shot on French window screen shot only has minor label length differences) then you could consider screen shots saved by language SAVED AS THE SAME NAME but stored in the language specific Help subdirectory.

In your "core" Help project (your "master" project) make an image map on the screen shot with an on-hover displaying a "screen tip text" - it is this text that your translator would change (it is in the HTML of the help topic page). Then you would copy > overwrite the language-specific image in the correct language subdirectory version. If both image are the same size and fields/labels have the same coordinates, you will see the "correct language" image and translated tip text.

You could also create hot spot image mapping along with the tip text and create an in-topic bookmark linked to the hot spot - hover to see the (language) tip text, click on to jump to the bookmark in the (language) topic.

Like I started, just thinking out loud.

Regards,
GEWB

[kmaddox1]

Thanks, GEWB. That's a clever solution, but we're not far enough along with our translation planning process to know exactly how the application will be deployed in the different languages. Also, since our screens are quite large, I typically capture only a portion of any given window. So I can't guarantee that the screen shots in the different languages will be exactly the same size.

I think that also negates Leon's SnagIt solution, since the underlying graphics won't always be the same size as the overlaying text. Or am I missing something in that approach?

I'm now thinking of this approach--in SnagIt, add numbered callouts to any screen shot to highlight the sections I'm discussing. Then, include a key below the image (that is, within the topic), explaining the meaning of each number. That way, all the translators would need to do is to capture the screen in the different language and insert the numbers where needed.

Would that work?

[Linux Rules]

Hello Kathy -

"but we're not far enough along" is a good thing because it gives you time to plan.

How are the Help topics called from your application? Have you and the developers established the Help files path? If so (and if not) I hope ALL of the Help is in a (or a series of) subdirectories of the app - that is, not dumped into the root directory of the app.

"all the translators would need to do is to capture the screen in the different language and insert the numbers where needed" is relying way too much on the translator and it will increase your cost.

If you are somewhat experienced with The GIMP or Photoshop, positioning and resizing the canvas of you images is a piece of cake. That way you can make the umages the same size . Then you could try the image map and bookmark idea I presented above. Try it with one sample page of Lorem Ipsum ( http://www.lipsum.com/ ) and two or three screen shot of anything and see what is involved.

Regards,
GEWB

[MergeThis]

The sad truth is, you're going to have to tailor your solution to the budget that the higher-ups have decided on for the localization effort.

As GEWB suggests, try a few graphics to see how much resources you would be expending for each of the solutions he and I have offerred (or even a combination of pieces from each one). That would at least give you some ammunition when the negotiating starts (that is, how many languages, who'll do the image tweaking, etc).


Good luck,
Leon

[kmaddox1]

My thanks again for your insights and ideas.

Right now, each of the main areas of our application links to its corresponding main project file (we're using Webhelp). There's a help subfolder for each area. We don't currently use merged help or context sensitive help.

In the interes of time and money, I'm starting to rethink my original idea of eliminating many of the English graphics or of hiding them in the translated text. Or, what do you think of this thought from one of my co-workers--go ahead and include the English screen shots in the translated text as "rough" guides to what the screen should look like. Then, use numbers for any callouts, and put the number key in the topic to be translated. While the non-English users won't see fully localized screens, at least they''ll get something that resembles what's on their screen. Would this be insulting or better than no screen shot at all?

[kmaddox1]

My thanks again for your insights and ideas.

Right now, each of the main areas of our application links to its corresponding main project file (we're using Webhelp). There's a help subfolder for each area. We don't currently use merged help or context sensitive help.

In the interes of time and money, I'm starting to rethink my original idea of eliminating many of the English graphics or of hiding them in the translated text. Or, what do you think of this thought from one of my co-workers--go ahead and include the English screen shots in the translated text as "rough" guides to what the screen should look like. Then, use numbers for any callouts, and put the number key in the topic to be translated. While the non-English users won't see fully localized screens, at least they''ll get something that resembles what's on their screen. Would this be insulting or better than no screen shot at all?

[MergeThis]

You could increase the opacity of the screen shots so that even the English labels would hardly be legible, thereby visually stressing to the user that the graphic was not really meant for reading, but only as a guide. The number key would lead them to the real stuff.

Sounds like a plan!


Good luck,
Leon

[Linux Rules]

quote:

---

Originally posted by: Kathy Maddox
Then, use numbers for any callouts, and put the number key in the topic to be translated. While the non-English users won't see fully localized screens, at least they''ll get something that resembles what's on their screen. Would this be insulting or better than no screen shot at all?

---

Hello Kathy -

I don't think it would be insulting. Many software users are accustomed to seeming labels in a different language with English the most common. I have used software with German or French labels and didn't take offense as long as the Help text was in English.

Leon's idea of munging the labels is OK but it means more time in The GIMP or Photoshop BUT you still need to add the numbers so it may not be a factor. Consider adding the numbered callouts as part of the image then create an image map in RoboHelp and bookmark links to the topic section. PM me your email address if you would like to see a sample of this method - I have a LARGE graphic with around 150 image mapped tip texts and bookmark links to entries in a table. It's 560kb zipped.

Regards,
GEWB

[kmaddox1]

I think I've mostly resolved this question simply by applying my "english-only" condition tag to all but a few of the screen captures. To my surprise, the conditional version WITHOUT the graphics seems just about as clear as my old version. Not to mention cleaner, leaner, and easier to maintain. Makes me wonder if I should simply stop using screen shots altogether, except in those sections where I describe how to use the application's controls and menus (where using numbered callouts on an English screen would probably work fine for localization). Comments?