Question

Say we have an overlay DHTML panel on a web page that contains two buttons in the top occupying whole width of the dialog, like this:

Text for Button 1 and Button 2 should be localized. Content of checkbox group is static and should not be localized.

There can be a big difference between button text width in different languages (~100% extra space in comparison with English version).

The question is which strategy to apply for sizing Button 1 and Button 2 depending on the length of the text content:

1. Make buttons fixed width and truncate text content with ellipsis.
2. Make buttons fixed width and wrap text content on the subsequent lines making buttons grow in height.
3. Make buttons fixed width but make them wide enough to host text in all languages without truncation or wrapping.
4. Make buttons dynamically adjust width and make panel grow horizontally with their size.

I am leaning towards using third or forth option according to the several UI localization best practices that were found:

• Preparing the User Interface for Localization
• Best Practices for Globalization and Localization
• Globalization Step-by-Step – UI Considerations

Still we have some debate in the team discussing the best option and it would be interesting to hear concious outer voice of the community.

I am interested in the best approach for this specific case as well general guidelines for solving web UI sizing issues in regards of localization.

Thanks!

Answer 1

As you perhaps know, text shortened with ellipsis (or with a single dot) could be incomprehensible:

How compr. is th.?

You should seen a lot of this staff in mobile area (phones, tablets, etc.), such translations look ugly. OK, with lower screen resolutions you actually end up with no choice (unless you can create some auto-scrolling text). But in case of web interface you certainly have a choice.

Typically, there are two kind of solutions corresponding to your points #3 and #4. Personally, I am leaning to #4 – make buttons auto-sizable. This of course will result with inconsistently sized buttons, but there is little we can do about it.

If you cannot use solution #4 (i.e. UI Designer is strong opponent of this technique), you may modify solution #3 a bit. Basically, what I used in past projects was, I had buttons of fixed sizes and default size was capable to fit most of languages (except Polish and Russian of course), but I also had several CSS classes that defined wider buttons. When localizing into “too long” languages I simply used the most wide button class I could. If the text still didn’t fit, then I asked the translators for shortening it (usually re-phrasing it and shorten the text with a single dot as a last resort).
However, please keep in mind that it increases localization costs. This is the reason I would not recommend this method.

As for solution #2, you will end up with ugly looking UI. You simply have no control over how browser will wrap a text, and you will have a lot of texts that go outside the button clipping rectangle (overlap it).

As for solution #1, using ellipsis is a bad idea for two reasons. First one is, ellipsis is not valid in many languages (this especially regards to Asian languages). The second one is, as I understand you want to do that automatically. In this case, you won’t be able to measure strings – their actual, on screen size, written with a fall-back font. In case of web UI, you don’t know whether user has particular font installed, so you will be guessing the size (OK, with Dojo you can theoretically measure it on the client side). This will of course result in overlapping text (if you decide on dynamic shortening over your chosen font) or totally incomprehensible text (if you decide on shortening after say 8 characters). I had a project which started to use static shortening, it was a total mess. Then we switch to dynamic and it is still not good enough.
To counter potential UI Designer argument that goes “we have no space for string expansion”, I can only say that means that you designed the interface incorrectly for it is too crowded. This is the point where I18n goes hand in hand with UI design best practices: strive for simplicity (in UI design). The result would be easy to use and easy to localize application.