What Does Your MadCap Flare Project Say About You?

This guest post was written by Scott Bass, the principal of LocFluent Consulting. Scott has been active in the language industry for over 30 years. 

You work hard preparing and maintaining the technical content for your organization. You have even committed to the “long game”— tackling the MadCap Flare learning curve. You know that committing to MadCap Flare for the long haul will pay huge dividends in the future. With Flare you will reduce repetition across all your content. You will improve consistency. You will be able to organize and manage critical data that is shared between documents. And you will be able to publish to myriad formats with minimal effort. Lastly, you can significantly improve the performance and cost savings when translating your content into multiple languages.

The way you design and execute in Flare will say a lot about what is important to you and your organization and what goals it is trying to achieve. After assessing hundreds of Flare projects for translation, we can tell a lot from a Flare project and who created it.

You Apply Inline Styles Instead of Using CSS

Maybe you just have not had the chance to take training on CSS. Cascading Style Sheets are complex, and it takes time and effort to learn and master their use. If you are under pressure to “just get the documents out” you might take some short cuts. You might think, “What’s the big deal? I’ll just format the text as I go.”

The truth is that by not using CSS you will bloat the underlying HTML code used by Flare. It will also make it difficult to make broad-sweeping changes. For example, let’s say you are documenting a software product and you want all commands referenced in your content to be in Courier font, bolded, and italicized. But you find out that Courier doesn’t look good in this context in Chinese. If you have not used a CSS style to manage this formatting, you will have to change all instances manually, which could be hundreds of instances. If this style had been defined in CSS, you could simply make one change and the problem would be solved.

You Embed Text in Your Images

Having static text in images means you just need to link the image you want within a Flare topic without having to create text overlays and insert the text. This is a barrier for translation since the image will have to be recreated with the translated text. And, if you must support multiple languages, the effort will have to be repeated for each language. Beyond this inefficient process, images often need tweaking due to text expansion or contraction. It is far more efficient to handle the textual part of your images within Flare.

A simple way to do this is to use MadCap Capture, a built-in image editing application that comes with Flare. It enables you to edit the image but using a text layer that will not be flattened into the image.

You Use Conditions Carefully

Using conditions is a core function in Flare that allows you to include or exclude text based on requirements for a specific document or output type. When using them you must be mindful of how they are being used in English. For example, using conditions to manage plurals must be avoided. If you condition the letter “s” to make nouns plural or single based on the output this will not work in languages that use different letters to form plurals.

You Make the Effort for an Error-Free MadCap Flare Project

Ensuring that your Flare project is as error-free as possible if it is going to be used as the source project for translation is the most important thing you can do to ensure a cost-effective and accurate translation process. It is helpful to think in terms of “multiplying effects”. Translation itself is a multiplier. Errors in the source project will be copied to the translated project. One error has become two. If you need to translate into five languages, one error is now five, and so on.

It is worth the extra time and effort to thoroughly check and correct your Flare projects before you publish. If you make corrections prior to publishing in English, then the source project will be worthy of publication when translated. The best method to manage this is to have your own project QC checklist. It might contain:

• All necessary outputs can be produced and have been checked for errors.
• You have checked for broken links and missing images.
• You have reviewed targets for correct conditions and variables.

To be fair, no one should be judged by the state of their Flare project. Frankly, we have seen many Flare projects that were given lots of care and attention but still needed special attention and correction to work well for translation. It is impossible to know how a decision you make today may impact an Arabic translation that will be needed two years from now! Nor would we ever judge you harshly for those decisions!!! The care, time, and effort you can put into your Flare projects is truly a reflection of your company’s priorities. If supporting your international customers with high-quality documentation is its goal, then be sure to advocate for the necessary time and resources to make your Flare projects shine.

You do not have to go it alone! MadTranslations is an expert in all things MadCap Flare and translation. We are here to help and ready to consult with you about the translatability of your Flare projects. Contact MadTranslations for a no-obligation consultation!