Forum posts to 'Desktop Publishing'

Conditional Text, and how to take advantage of it for cost savings

bmann — Tue, 03 Aug 2010 16:57:17 -0600

What is conditional text?

Per Wikipedia (correct in this case), "Conditional text is content within a document that is meant to appear in some renditions of the document, but not other renditions."

FrameMaker, and now InDesign, have the ability for the document author to create documents with conditional text.

As an example, let's say you have two similar products, one called Widget X1000 and the other, Widget X2000. Their product manuals might be 90% the same, except for a few added features and specs.

Rather than creating two separate manuals with 90% of the content copied and pasted into the other, it is much more efficient to create one conditional manual that contains all of the content and have the ability to hide the features you want to hide before outputting to PDF for the printer.

Furthermore, if the manual needs to be updated in part of the "unconditional" content, then you only have to update it in one place, rather than each manual. This ensures changes and updates appear completely and consistently in your product manuals.

And finally, by combining and reusing the content of two manuals into one, you are getting significant localization savings. If your two separate manuals are 90% similar, you still end up paying for "repetition", albeit at a very reduced rate. In a conditional manual, you have consolidated the repetitions and they only appear once to the translator.

Important things to consider:

Granularity—Applying the condition to the correct amount of text is critical. In one extreme, you don't want to have two sections of the document each with a different condition but with a lot of the same content. This would defeat the purpose of using conditional text. At the other extreme, you don't want to apply conditions to different words in a single sentence, as that becomes very difficult to manage, and especially difficult if not impossible to translate! The ideal application of conditional text is at the sentence or paragraph level.

Formatting—The formatting of the document must be well-defined enough that if you hide bodies of the text, you don't end up with widows and orphans or largely blank pages. The best way to handle this is to use the "Keep" options of the software to make sure headings stay with their supporting paragraph, bullets in lists stay together, figure captions stay with figures, etc. This is even more important as the document goes through the localization process. The change from English to a different language means text will expand to different pages or areas of the page. The Keep options make sure that when that happens, the correct bodies of text stay together. Avoid using Page Breaks as much as possible, as they can cause pagination problems when text "moves", such as large portions of pages ending up blank.

Spaces—It is easy to forget that a space in a sentence can be conditional. If you aren't careful, you could have some words "butting up" against each other when your conditional text is hidden. Our advice is to use underlining in combination with a color as a conditional indicator and always work in the document with conditional indicators showing. This will allow you to see where the conditional text is, and if a space is conditional it will show an underline, since a space has no color. It is always good to toggle the conditional text and review the document in all versions so you can see if there are formatting issues before final output.

Cross-Refs, TOCs, Numbering—When you show or hide text in the document, anything that refers to a page number or cross-reference will need to be updated again. Use the Update Book function from the Edit menu before final output.

Posted to: Conditional Text, and how to take advantage of it for cost savings Show Thread | Post Reply

Re: Handling UI terms in your localized software documentation

Roman Mironov — Wed, 14 Jul 2010 01:05:15 -0600

In my experience, another good approach to handling the UI terms is a descriptive translation.

Example:
English: Check for proper ECG signal again on the Gating Control Window.
Russian: В окне управления синхронизацией повторно проверьте наличие надлежащего сигнала ЭКГ.

A descriptive translation is very appropriate in the two scenarios below:
1. The UI is not highlighted specifically in the sentence, e.g. by using a bold font or quotation marks.
2. The actual UI was already mentioned above and localized using a translation in brackets.

Benefits
The main benefit of a descriptive translation is that it doesn't directly refer the reader to a specifically named UI term on the screen. This almost eliminates the risk of potential confusion mentioned by Ben in the initial post—the end user looking for a non-existent name on the screen. Instead of looking for a specific UI term, the user would identify the necessary UI by using deductive thinking.

Another benefit is shortening and simplifying the translation. Instead of providing the source UI term + translation in brackets each time in your translation, you can provide the translation in brackets just for the first occurrence of the UI term and use the descriptive translation thereafter. As the text becomes shorter and therefore easier to understand, the end user will be happier with the documentation. The DTP team will be happier as well, because the length of the translation will be closer to the length of the source, resulting in less adjustments at the typesetting step.

The descriptive translation also helps keep the translation current, even if minor changes are introduced to the source UI afterwards. For example, a developer may decide to change “Gating Control” to “Gating Monitoring” in the next version of the software. If the old documentation translation included specific references to “Gating Control,” all of these will need adjustment. However, if a descriptive translation was used, little or no changes will be required, because such translation will normally remain valid for the changed UI term as well—the change is minor and doesn't affect the translation.

A descriptive translation isn't always appropriate though, so caution should be exercised when you consider using it in your current translation.

Posted to: Handling UI terms in your localized software documentation Show Thread | Post Reply

Re: Layered, text-accessible graphics source files

bmann — Tue, 20 Apr 2010 14:53:14 -0600

If the source graphic file is not available, the flattened version can still be edited but it may take much more effort, and therefore time and cost. Flattened images can be edited in photo editing software, such as Adobe Photoshop, where the pixels will have to be "erased" so that a text layer can be created over the image. The amount of text in the image and the background on which the text appears are major factors in the effort necessary to localize the image.

Posted to: Layered, text-accessible graphics source files Show Thread | Post Reply

Re: Layered, text-accessible graphics source files

Susanne — Wed, 17 Mar 2010 10:00:32 -0600

Do you have any suggestions on what to do if the original artwork/source files are not available?

Posted to: Layered, text-accessible graphics source files Show Thread | Post Reply

Layered, text-accessible graphics source files

dhdunn — Tue, 16 Mar 2010 16:35:56 -0600

One of the items that is often missed when handing off files for translation to your translation / localization vendor are graphics files. Oftentimes, a company will provide flattened images that are not editable, such as .jpg (JPEG) files to their localization vendor. If graphics do not have text in them that requires translation, that's okay.

However, if the graphics do have text in them, your localization partner will need to receive the original, layered, text-accessible graphics source files that were used to create the original English graphics. This allows for translations of graphics text to be inserted in place of the English without the graphics having to be created from scratch. And thus, this saves both signficant cost and time, and is conducive to overall quality and consistency of look-and-feel of graphics throughout your documentation.

Posted to: Layered, text-accessible graphics source files Show Thread | Post Reply

PDFs and their usage in localization

bmann — Wed, 10 Feb 2010 17:40:33 -0700

PDFs can have varying degrees of usefulness in a localization project.

Here are some common uses:

1. Ballpark project cost estimate—The localization vendor can determine the approximate number of words, number of pages, and source document format to provide a rough estimate of the cost of localizing the original source file. The leverage against the translation memory cannot be determined, nor can the quality of the construction of the source document. Both of these factors can affect the cost significantly so it is always recommended to send the source document for the most accurate estimate.

2. Final English file for print or web output—This is the PDF that is used by your printer to create the hard copies or the PDF that you will host on your website or e-labeling. It is a good idea to send this to the localization vendor along with your source file(s) so that they can make sure the formatting of the localized version matches the English. This will also be used by the linguists as a visual aid when translating the content of the file.

3. Reference material for linguists—In a translation project, you may have an older version of your document already translated but not in translation memory software. A PDF of this document can be used by the linguist as a style and terminology reference for the new document.

4. Translation review—PDFs are the perfect document for linguistic review because they contain all of the required text, can be opened on any computer anywhere for free, and best of all—can be annotated extremely easily using Adobe Reader or Acrobat.

Here are ways PDFs are less likely to be useful:

1. As a source file—Using a PDF as the source file is not recommended unless your source format is Adobe Illustrator, which uses PDF as one of its native file types. For all other formats such as Microsoft Word, Adobe FrameMaker, Adobe InDesign, etc, the PDF does not contain the formatting information required to create a localized version of the document. Text from the PDF can, however, be copied into a Word doc and translated, if the formatting is not important in the localized document.

2. As a previous translation to be reused—Modern technology allows us to reuse previously translated content in the form of a database called a translation memory. This database is integrated into the translation project to create the efficient and low cost process that the localization vendor provides you. Previously translated content that is in another form, such as a PDF, is not efficiently integrated like the translation memory. Yes, the content can be used, but it has to either be converted line-by-line into a translation memory or simply referenced by the linguist during the translation process. Keep in mind that only content in a translation memory can be leveraged for cost reduction.

3. Scanned text—Most scanners can output right to PDF. This is great for hand sketches or your kids' watercolor paintings but when it comes to translation, scanned documents require an extra step in the process. Either someone will have to transcribe the text into a computer or, if the scanned document was created from a word processor, the image may be converted to text using Optical Text Recognition (OCR) and then edited.

Posted to: PDFs and their usage in localization Show Thread | Post Reply

Handling UI terms in your localized software documentation

bmann — Thu, 10 Dec 2009 12:59:54 -0700

You take great care to ensure your medical software documentation contains step-by-step instructions on how to use the software, with screenshots. The clarity and readability of these instructions are essential to the end user and the lack thereof could lead to critical and possibly life threatening errors.

It is important that the user interface (UI) terms in the documentation of the software are consistent with the software itself. For example, the documentation may have instructions to:

"Press the Setup button".

The French documentation will say,

"Appuyer sur le bouton Configurer".

However, when the French end user looks on the screen, there is no button that says "Configurer" because the software is in English. The most common way to deal with this is to provide the English UI term with the translation in parentheses immediately following.

"Appuyer sur le bouton Setup (Configurer)."

The French end user now knows what button to look for as well as what it means.

Down the road you may decide to localize the software. In this case, you would need to remove the English UI terms from the documentation and add localized screenshots of the software. For screenshots, you can replace all of the graphics in the graphics folder with the new ones and then go into the document to resize them as necessary. If you took care to make the screenshot dimensions identical to the English, no adjustments would be necessary.

With the UI terms, it will take a desktop publisher time to go through the localized documentation, manually remove all of the English UI terms, and handle the reflow of the document text. However, if you are authoring in Adobe FrameMaker, here's an ideal way to create your English document with localization in mind:

Create and apply one condition to the English UI term, create a copy of the English immediately after and apply a second condition, and then use a third condition for the parentheses around the second instance and the space between. Note, this is one of the few times it is recommended to use multiple conditions in the same sentence.

In this example, the three colors represent the three conditions, the underscore represents a space:

Press the Setup_(Setup) button.

During translation, only the second instance will be translated. This will enable you to use the show/hide conditional text feature to switch between English only (blue), translation only (red), or both (red+blue+green) in the localized document. This provides flexibility and will save time and cost when you are unsure if the software will be localized.

Posted to: Handling UI terms in your localized software documentation Show Thread | Post Reply

Tips for document authoring

bmann — Mon, 31 Aug 2009 12:40:48 -0600

Here are some tips for creating your English source documents with localization in mind!

Create and apply paragraph and character styles to create consistency in your document. It also facilitates style changes. Use style overrides as little as possible.
Design the document assuming text will expand at least 30% in the localized version. If the text cannot flow to additional or blank pages, leave space on the page for text expansion.
Use keep options instead of page breaks. If you create a page break and then add text before it you can end up with awkward or misplaced page breaks.
Take advantage of auto-generated text such as table of contents, index, and cross-references.
Use Open Type Fonts that support multiple languages such as Myriad Pro. This ensures that the localized version of the document will retain as much of the look and feel as the original as possible. Check your font documentation for specifications on which languages they support.
Avoid having text in placed images, especially bitmapped images (JPG, GIF, TIF, etc) where it is very difficult to change. Instead, place text in text boxes of your authoring software and overlay them onto the graphic when possible.
Link graphics instead of embedding them into the document when possible.
When working with linked graphics, each graphic should have a unique name rather than using files with the same name in separate graphics folders.
Use master pages for background images and header and footer text rather than pasting it on multiple pages.
Use paragraph spacing (before and after) instead of empty paragraph returns.
Use line breaks instead of paragraph breaks, when applicable.
Use indents instead of extraneous tabs or spaces.

Posted to: Tips for document authoring Show Thread | Post Reply