Expecting UTF8
| Chapter 27. Internationalization and Localization |

## Expecting UTF8

A properly internationalized application will not make assumptions about the number of bytes in a character. That means that you shouldn't use pointer arithmetic to step through the characters in a string, and it means you shouldn't use `std::string` or standard C functions such as `strlen()` because they make the same assumption.

However, you probably already avoid bare char* arrays and pointer arithmetic by using `std::string`, so you just need to start using `Glib::ustring` instead. See the Basics chapter about `Glib::ustring`.

### Glib::ustring and std::iostreams

Unfortunately, the integration with the standard iostreams is not completely foolproof. gtkmm converts `Glib::ustring`s to a locale-specific encoding (which usually is not UTF-8) if you output them to an `ostream` with `operator<<`. Likewise, retrieving `Glib::ustring`s from `istream` with `operator>>` causes a conversion in the opposite direction. But this scheme breaks down if you go through a `std::string`, e.g. by inputting text from a stream to a `std::string` and then implicitly converting it to a `Glib::ustring`. If the string contained non-ASCII characters and the current locale is not UTF-8 encoded, the result is a corrupted `Glib::ustring`. You can work around this with a manual conversion. For instance, to retrieve the `std::string` from a `ostringstream`:

    std::locale::global(std::locale("")); // Set the global locale to the user's preferred locale.
                                          // Usually unnecessary here, because Glib::init()
                                          // or Gtk::Application::create() does it for you.
    std::ostringstream output;
    output << percentage << " % done";
    label->set_text(Glib::locale_to_utf8(output.str()));

Marking strings for translation |  | Pitfalls