Debug Outputs: Usage Scenarios

A Debug Output streamlines the process of ironing out any potential issue or bug introduced at design time. Although Flare's XML Editor and Preview features are a great help to fine tune the layout and formatting of any topic, it is not uncommon for issues to be detected only in the resulting output.

One advantage of implementing the debug features right from the start of the development cycle is they will be available in all subsequent stages: translation, proofreading, engineering, etc.

Before publishing, it is customary for Flare content to be reviewed by one or more Subject Matter Experts who are not necessarily familiar with the particulars of single-source elements.

Therefore, a Debug Output helps such experts in pinpointing, refereeing, and documenting any potential issue.

A full-fledged Flare localization process includes an early evaluation of the original Flare project aiming to flag potential issues at the teething stages of the process and thus, avoiding the snowball effect of having any such issue getting repeated over and over across all target language versions.

A Debug Output version is particularly helpful when evaluating the interactions between the different HTML and single-source elements (soft content) and the regular text (hard content)

When combined with pseudo-translation, a Debug Output increases the chances of early detection of potential issues. While dummy characters highlight layout and display issues, the debug formatting helps to pin those issues to a particular source: regular text, variable, snippet, etc.

When applied to the screened translatable files (as opposed to the whole source Flare project), debug/pseudo-translation match-up it's particularly helpful in detecting single-source elements skipped in the screening process.

If the goal to translate a designated target language ahead of the rest is to pinpoint early localization and localizability issues, a Debug Output version of this pilot language will further contribute to achieve such goal.

Translating HTML source code can be challenging and Flare's single-source elements add to that challenge. Elements like conditional text, variables or snippets are seen as cryptic tags in the CAT application editor, providing little context to figure out how the translated text will be rendered in the output.

By referring to a regular text output, a linguist can have an overview of the content being translated but will struggle to locate where the different HTML tags, variables, and snippets pieces of the puzzle fit in.

The described situation is especially relevant when it comes to translate snippets in general and text snippets (as opposed to block snippets) in particular. Having a chance to see them in context helps to accurately understand and translate their content.

Because of the added complexity stemming from the very nature of any single-source underlying code, it is not uncommon tag-related issues compromising the XHTML compliance are introduced during translation.

Therefore, a Flare localization process includes a post-translation stage meant to implement the newly translated files and to fix any potential issue originated in the translation process.

A Debug Output is a great companion to tap into when it comes to pinpointing and tackling such potential issues.

Similarly to the translation process, performing a Linguistic Quality Assurance (LQA) or proofreading a localized Flare project can also benefit from a Debug Output version, only this time around the links pointing at the target topics are available.

The issues or bugs logged during LQA need to be fixed (debug) before the final localized Flare project is signed off.

The Debug Outputs are valuable tools to pinpoint the culprit of a large amount of those issues, bearing in mind linguists log any issue found regardless of their source which, in a localization environment, in most cases involve languages and scripts unknown to the personnel tackling those issues.