Standard View and Formatting View

The editor offers two views of the same document. Standard View keeps things plain so you can translate fast. Formatting View shows the inline codes and tags so you can finish the document precisely. For most work the order matters: translate the words first, then handle the formatting. This guide explains both views, when to use each, and how to move between them without losing work.

Two views of the same document

Both views edit the same translation. They differ only in what they show you and what they let you do.

View	What it shows	Best for
Standard View	Plain source and target text, with no codes in the way.	Translating the words quickly and comfortably.
Formatting View	The same text plus the inline codes and tags that carry formatting.	Placing formatting and finishing the document.

Figure 1. The same segment in both views. Standard View shows plain text. Formatting View shows the inline codes and tags that Standard View hides.

You switch between them with one button on the toolbar. Its label tells you where you are going: Switch to Formatting (Codes & Tags) view when you are in Standard View, and Switch to Standard view (plain source/target) when you are in Formatting View.

Figure 2. The view toggle on the toolbar. The label always names the view you are about to switch to.

Translate in Standard View first

When you start from an ordinary document — a Word or PowerPoint file you are translating from scratch — begin in Standard View and stay there until the translation is done. Plain text is faster to read and faster to type. You are not distracted by codes, and you cannot accidentally disturb them.

The simple rule

Translate the words first in Standard View. Treat formatting as a finishing layer that you add at the end in Formatting View. This keeps each task clean and avoids redoing work.

Figure 3. Standard View. Plain source and target, ideal for translating the text.

Switch to Formatting View to finish

Once the words are done, switch to Formatting View as the top, finishing layer. Here you make sure every inline code from the source lands in the right place in your target, and you apply any explicit formatting the translation needs.

Formatting View adds a formatting toolbar with the usual controls — Bold, Italic, Underline, Strikethrough, Superscript, and Subscript. These appear only in Formatting View.

Figure 4. Formatting View. The inline codes are visible, and the formatting toolbar appears for bold, italic, and the rest.

Lean on Place Codes for the transition

Placing every code by hand would be slow. Place Codes does the heavy lifting. It reads the codes in your source and positions them in your target translation for you, across the segments you choose. It is the key tool for moving from a finished Standard View translation to a properly formatted one.

In Formatting View, choose Place Codes from the toolbar.
In the Place Codes dialog, set your options and confirm.
bAIbel AV places the source codes into your targets and reports how many segments it updated.
If a previous run left some codes unplaced, bAIbel AV offers to retry only those segments, or to process all of them again.

Figure 5. The Place Codes tool. It positions the source’s inline codes into your finished translation, so you do not have to place them one by one.

Sweep up anything left over

Some codes may still need a human eye. Formatting View makes the remaining ones easy to find and fix:

A yellow Missing codes strip appears above the grid, holding any codes not yet placed in the current segment’s target. Drop them into place from there.
The Codes missing filter shows only segments that still have mandatory source codes missing from the target.
Press F8 to jump to the next segment with missing codes.

Figure 6. The Missing codes strip and the Codes missing filter. Together they make sure no mandatory code is left out of the target.

A different case: pre-populated bilingual files

The Standard-View-first order is for documents you translate from scratch. Some files arrive already translated. Bilingual files such as .xdxliff, .mqxliff, and .sdlxliff can come to you with the target already filled in — for example, when you are re-reading, reviewing, or correcting someone else’s translation.

These files usually already carry their formatting codes in the target. For them, a Formatting-View-centric workflow makes more sense. Work in Formatting View from the start, so you can see and preserve the codes that are already there as you review and correct.

Why not Standard View here

On a file that already has formatting placed, editing the plain text in Standard View can leave that formatting out of step with your edit. Staying in Formatting View keeps the text and its codes together while you review.

Your starting point	Recommended workflow
A new document to translate (Word, PowerPoint, and similar)	Standard View first for the words, then Formatting View to finish.
A pre-populated bilingual file for review (.xdxliff, .mqxliff, .sdlxliff)	Formatting View throughout, to preserve the formatting that is already there.

Switching back to Standard View

You can always switch back to Standard View, even after you have placed formatting. But once formatting is in place, going back is not free, and bAIbel AV warns you first.

Segments where you have placed formatting are marked with a pilcrow badge (¶). When you switch back to Standard View with such segments present, bAIbel AV shows the Switch to Standard View? warning.

What the warning means

Editing a ¶-marked segment in Standard View updates the words, but it does not move or reapply the formatting tags you placed in Formatting View. When you next return to Formatting View, those segments are re-seeded from the source’s formatting. In other words, the formatting work you did on them may be undone, and you may have to place it again.

Figure 7. The Switch to Standard View warning. It appears when segments already have formatting placed, so you can decide before any rework is needed.

Reading the ¶ badge

The pilcrow badge in the status column tells you a segment’s formatting state at a glance:

Badge	Meaning
¶ (neutral)	Formatting placed, and the text has not been edited since. The segment is in good order.
¶ (amber)	The plain text was edited in Standard View after formatting was placed. Return to Formatting View to re-seed this segment.

Figure 8. The pilcrow badges. A neutral badge means formatting is settled; an amber badge means the segment needs re-seeding in Formatting View.

The takeaway

Switching back is allowed, and sometimes you will need to fix wording late. Just know that for ¶-marked segments it can mean redoing formatting. The cleanest path is to finish the words in Standard View, then make Formatting View your last pass.

Terminology used in this guide

Standard View: The editor view that shows plain source and target text, with no codes.
Formatting View: The editor view that shows inline codes and tags, with a formatting toolbar.
Inline code (tag): A marker inside a segment that carries formatting or structure from the original document.
Place Codes: A tool that positions the source’s inline codes into your target translation across the segments you choose.
Missing codes strip: The yellow strip above the grid that holds source codes not yet placed in the current target.
Pilcrow badge (¶): A marker showing a segment has formatting placed; amber means it was edited afterwards and needs re-seeding.
Pre-populated bilingual file: A file such as .xdxliff, .mqxliff, or .sdlxliff that arrives with the target already translated, typically for review.