The i18n problem

When designing for an internationalized app there are some feasibility issues that come up against UX concerns. Here's the one that's on my mind.

To account for variable text length, I've always taken the 'label aligned above' model. I don't dislike this design from a usability standpoint. You need to apply white space carefully to avoid confusion, but when designed well it functions well.

But what if I want to try something different? Take a look at this English / French sample.

Two design solutions for internationalized field label translations

If you've tried this in an i18n product or have seen a successful alternate path:
Are there UX issues with expanding label real estate to one side of the field?
Are there design strategies to avoid those pitfalls?
Should I just stick with my boring, safe solution and delight in the fact that I could translate to Uzbek if I wanted?

Clarification of intent: I primarily want to validate that I'm not taking reasonable and usable options off the table purely out of habit.

  • Thx for the typo catch @user1757436 May 15, 2015 at 22:17

4 Answers 4


I am just confused about your statement that form labels above form provide usability issues as usability studies have shown that the closer a form label is to the form field, the faster it is to fill up. To quote this article

So, we were not surprised when we noticed that most of the fixations were right on the input fields rather than on the labels, as the eyetracking data in Figure 3 shows.

Figure 3—Testing left-aligned labels above input fields

enter image description here

Placing a label right over its input field permitted users to capture both elements with a single eye movement. Also, if a label indicated data that was very familiar to users—for example, their first name or family name—users did not fixate on the label separately to read it. They were able to view both the label and the input field in the same foveal area; thus eliminating the need for additional fixations and saccades.

I also recommend looking at this article The Definitive Guide to Form Label Positioning for a exhaustive comparison of different labeling methods and the benefits and disadvantages as well. One highlight there is this decision matrix:

Decision matrix based on requirements

Now coming to localization of form labels

As Vitaly pointed out that both top labeled and left aligned labels would work, the fact that same phrases would have different lengths in different languages would cause your form alignment to be be totally out of sync which can give an impression of a discontinous and broken form design. To quote this article on form label localization

When it comes to international flexibility, however, there is a clear winner. Whether your online form is a shopping cart, registration page or another type of data collection, the most important thing to remember is not all languages are created equally. Some are longer and some are shorter. If you place labels to the side of the field and allow 180 pixels of space, “Cardholder Name” will fit well in English with room to spare. But change the language to French, and “Nom du titulaire figurant sur la carte” will more than max out your allotted 180 pixels. The more languages you plan to translate into, the more likely you will encounter this issue. Especially if you plan to be cross-browser compatible!

The best way to save yourself a few headaches is to place the label above the field. There is a lot of room up there, especially if you have longer fields. This is the perfect location to allow longer languages to expand without destroying your CSS floats.

When not placed above the field, labels that are too long can push the page’s code structure, and consequently your fields, out of alignment:

enter image description here

Whereas when the labels are above the field, there are no issues:

enter image description here

Hence to summarize, go with top labels as they would ensure a consistent experience and are safer as well

  • Sorry if my wording was confusing. I thought this made my opinion on labels above pretty clear: "I don't dislike this design from a usability standpoint." It's not that I dislike it, it's that I'm wondering if there's a problem with the alternative in internationalized apps. May 15, 2015 at 22:14
  • Thx for the eye tracking example by the way. Honestly, I validated this approach so long ago that I haven't refreshed myself on the research in a while. #lazyUX May 15, 2015 at 22:21

It can work reasonably well with text boxes, but what do you do with dropdowns, checkboxes, radio buttons and more or less any other control?

The safe solution is, well, safer :)

  • Not sure I understand your point. I'm talking about field labels. Other controls are other controls. May 15, 2015 at 19:33
  • I'm assuming that you follow the same convention with other controls, so that if you place labels above input fields, you will also be placing them above dropdowns or radio button groups. No..? May 15, 2015 at 19:36
  • I see what you're saying ... yes. That is probably mostly true. I think there would be some flexibility, e.g. when you have a sentence or paragraph that leads into a choice. Radio button groups would require some though. But I get your basic recommendation: Labels above always work. May 15, 2015 at 19:47

I would prefer to align inputs and labels to an imaginary axis (the red vertical line in the sketch below) and giving the inputs the length it should takes as the French words and expressions maybe longer than English.


download bmml source – Wireframes created with Balsamiq Mockups

This tip is usually used in the movies closing credits.

enter image description here

  • Your movie credit example illustrates two of my concerns with this approach: (1) Long labels eat up valuable field area and (2) variable label length makes scanning difficult. In move credits, they set it up to emphasize actor names ... this always frustrates me when hunting for characters. Movie credits are a great UX dark pattern. May 18, 2015 at 16:20

We use a tabular layout with right-aligned labels to the left of the fields, and allow labels to word-wrap if they don't fit into the predefined width of the label column. The controls are aligned to completely fill their table cells.

Edit: We use percentages of the screen width for the column widths, and allow users to preselect the width of the controls column. So, the users can either resize the window, or allow more space for the labels, if they find that the labels don't fit.

  • Do you find that long, wrapped labels make a visual mess in your forms? This is really where my i18n concerns lie. May 18, 2015 at 16:22
  • That happens rarely, since we allow a lot of space for the labels to start with, and if it happens, it makes a mess in a way that doesn't interfere very much with usability, since the controls don't change their size and position depending on the length of the label.
    – hbarck
    May 18, 2015 at 17:33
  • Do you find that the extra space dedicated to labels to be "wasted" or does it help in some way? May 18, 2015 at 17:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.