Impact of text language on WPF

Finally, the examples I mentioned on my last post about text.

Let’s take the WPF text rendering engine as my example of a text processor that’s sophisticated enough to handle this correctly.

First off, as explained in xml:lang Handling in XAML, the XAML parser is actually smart enough to know that xml:lang is an important part of the document, and will set the Language property on the objects instantiated. You can also build up text programmatically that is language-aware by using this property from code directly, or allow the user to change it at runtime if for example you’re building a text editor.

A good place to see some of the text rendering in action is the Bidirectional Features in WPF Overview. This topic also talks about fun things you can do to change directions (there’s also some support for this using special Unicode characters) and get number substition for your text.

Another example of text language support is even clearer in the spell checker support that the RichTextBox has. In this example, we have two paragraphs. The first one is marked as English, so it works fine, but the second one has a mix of English and Spanish text runs (yes, xml:lang and the Language property work at multiple levels and cascade down as you would expect!). One of the runs is marked incorrectly, however, and a bunch of red squiggles show up.

  <Paragraph xml:lang=’en-us’>
   This is tagged as en-us and is English, so there are no red underlines.
  <Paragraph xml:lang=’es-ar’>
   <Run> <!– inherits the value from the paragraph. –>
    This is tagged as es-ar but is English, so there are plenty of red underlines.
    Esta parte no, sin embargo.
   <Run xml:lang=’en-us’>(translation: not this part, however)</Run>

Here’s a screenshot:


Comments (1)

  1. I’ve written in the past about XML and languages, and why you might be interested in being aware of the

Skip to main content