Jaa

Localization Bugs: Clipped text, #1

  • Artikkeli

About as common as duplicate hotkeys are dialogs with clipped text. And just as with duplicate hotkeys, there are a couple of different ways these can happen. I'll show a few examples, starting with the most trivial case.

One note before I start: I will talk about clipped text, not truncated text. For the purpose of these posts, "clipped text" means that the entire string survived until it was drawn on the screen, but there wasn't room to draw the full string and so not everything is visible to the user. "Truncated text" on the other hand means that the string was cut off by code somewhere after it was loaded from the localizable binaries but before it was drawn on screen. From the user's point of view these can appear to be the same thing, and we might even use the same fix [shorten the string]. Most of the time though both the cause and fix differ.

Let's start.

The absolutely simplest example of clipped text is where I can already see the text as clipped in my favourite localization tool. It can look something like this:

or like this:

Both of these are trivial. There's nothing really interesting going on here; the strings simply do not fit within their controls. What's good about these cases is that they're easy to detect. Anyone can see that the first one is clipped, since you can see half of the lower row. The second one might be trickier though since you don't have a visual clue that the text is clipped, but a native speaker would spot it quickly and even a non-native could notice that the string doesn't end with a colon. That's a good clue. Also, both of these are easy to detect automatically, either at localization time or at runtime.

How do I fix them? Either resize the controls, or shorten the string. The first one above, I'd resize. Just make the label a few pixels taller. The second, I'd change the translation from "Contact name:" to just "Name:". I'd also change the second string from "Phone number:" to just "Number:". I could size the dialog to fit the text, but it'd look strange and the words "Contact" and "Phone" don't really add anything useful to the text. The context makes it clear what kind of name and what kind of number you should enter.

To me, this type of bug is very similar to the first kind of hotkey bug I showed - easy to prevent, easy to detect. Therefore we rarely see this type of clipping bug any more.

Next up I'll show something a little bit more challenging.

  This posting is provided "AS IS" with no warranties, and confers no rights

Comments

  • Anonymous
    November 22, 2004
    Hmm...

    If you are using VisualStudio.NET you should not get this localisation issue with forms providing you are using the built-in facilities:

    1. Change the property "Localizable" for the form to "True" for the form.
    2. Set the language you wish to localise the form to
    3. Change the labels and text, resizing and adjusting controls as required for that language

    I can only assume you are instead using a single non-localised form and manually loading in the resource strings using the ResourceManager? While this is okay for dialogs, for forms it gives problems - as you can see for yourself.

    [)amien
  • Anonymous
    November 22, 2004
    The comment has been removed
  • Anonymous
    November 22, 2004
    Damien, we're not using VS.net because it's not a localization tool :)

    The typical work flow for me is is to first translate text, then turn to dialog layout. It's more efficient to keep these as separate tasks, and it's good to take some time between translating a string and proofreading it.

    The examples I gave here are straight Win32 (maybe I should have spelled it out), but the process for us is about the same for managed code. I translate text first, then I use winres.exe to size it. I don't do the actual translation work inside the visual editor.
  • Anonymous
    November 22, 2004
    Anon, yup, that could look nicer and would definitely be easier for me. I could have made this change when localizing, but I always try not to change the layout of a dialog too much.

    Most of the time we start localizing long before the English application is frozen. For instance, I started localizing XP SP2 about a year ago now and that didn't ship until towards the end of this summer.

    This means that anything I localize today might change again tomorrow. Including sizing. So if I spend a lot of time beautifying a dialog now, that work might be totally in vain. Also, if it differs much from US, it might make it harder for me to spot that something is out of sync. This can give rather subtle bugs.

    In this case, I could of course have tracked down the developer and asked him to change the source layout to give me some more space. Sometimes that's what I do. But in this case it seemed both easier and better to just cut the translations.