[Post 3 of the DITA Loc Wire Series]
Just when we think the formatting dinosaurs are extinct, we continue to find legacy issues in DITA source content. Many of these issues are relatively easy to fix and make your content more global-ready.

Bold and Italic formatting falls into this category of low-hanging fruit.

As stated in the DITA presentation from OASIS, the whole point of DITA is to separate the content from the formatting to facilitate re-use.

Accordingly, there should not be any such <b>… </b> or <i>…</i> sequences, as this formatting is embedded in the text.

Why remove bold and italic inline formatting from DITA?

Bold and italic are hard to read in sign-based languages

Most languages use the Roman alphabet, where bold and italic are common.
Click on Edit would display correctly in Slovak kliknite na Upraviť

In languages that use a different alphabet, the bold and italic styles aren’t available in the standard fonts, because they are either not used or not applicable:

In Arabic, bold reads poorly انقر فوق تحرير – and italic is worse. How about Traditional Chinese?

“You can use the method of Peak Adjusting to find the parameter or manually select the starting point and the end point of the integration” Would translate as follows:

可採用調整波峰尋找參數或手動選擇積分起點及終點這兩種方法 – here, bold reduces readability. It’s best to emphasize the words by using a different font color.

可採用調整波峰尋找參數或手動選擇積分起點及終點這兩種方法

Bold and italic deserve to be updated along with the corporate image

A corporate image changes periodically or needs to be adapted to the audience or channel. Here are some examples:

• When the content is published by another brand (white label, co-branding, etc.),
• After a company takeover or a merge,
• After a brand image make-over.

The corporate image typically impacts the title and paragraph styles, the colors and layout; it rarely goes as deep as applying bold and italic. Now is an excellent time to start including them, when it makes sense.

Our alternatives to inline bold and italic in DITA

We have found that in many instances, bold and italic elements result either from the migration of legacy content, or pre-DITA technical writing habits.

Instead, try one of these methods:

• Use a semantically specific element, such as uicontrol, cite, codeph, keyword or glossterm, if it is available. The first example, click on Edit, should be written:
  <step><cmd>Click on <uicontrol>Edit</uicontrol></cmd></step>
  instead of <step><cmd>Click on <i>Edit</i></cmd></step>

• Create a Specialization to include content types that are not covered by the standard DITA semantic elements.

• Apply the outputclass attribute, which will be handled by the style sheet (CSS) in the publishing process. If you want to write Never open this box! to put a strong emphasis on the restriction, instead of writing :
  <p><b>Never</b> open this box!</p>
  You should write:
  <p><ph outputclass=”emphasis”>Never</ph> open this box!</p>
  The CSS will then translate the emphasis in the format specific to each language: bold, new font, new color, or a special sign. We recommend that the chosen ouputclass be among the official outputclasses managed by the information architect.

As a conclusion, although the <b> and <i> tags are legal in DITA, we don’t recommend using them. A simple Schematron rule can be added in the authoring tool or in the CMS check-in process to warn the writer or report errors.