views:

214

answers:

5

I am going to be creating a multi-lingual website (asp.net) and was wondering how to best handle much of the administrative screen UI work where the end user will be maintaining lists of data that will need to be in multiple languages. Anyone know of any good sample applications I can take a look at?

Example scenario. I have a screen that an admin would use add a new product. The title and description would need to be stored for each language in the system and would be required in order to save. The number of languages would ideally be dynamic/configurable where the UI would not need changing each time we add a new language.

Thoughts/suggestions/examples?

+3  A: 

Our previous in-house CMS used a fairly simple model which the editors seemed to like: over each input field, a thin row of toggle buttons (JS-powered) selected which language was currently being edited:

[EN-US] [FR-FR] [SW-SE] [RU-RU] [ZH-CN]
 _____________________________________
| textbox                             |
|_____________________________________|

They behave kind of like radio buttons, e.g. selecting one deselects all the others, and the textbox immediately flips to reflect that value. The buttons were small enough to fit about 16 above an input field before it started to get unwieldy.

I'd also recommend a "master toggle" at the top of the page which switches all controls at the same time.

Rex M
+2  A: 

We have an old MFC application that does this. It has a textbox for the name that will be the name for the object you're administrating in the dialog's current language (in the language that the current user has set and is viewing the application in). Then there is a listview below where you can add the rest of the names for each language that you support.

One thing that might change your approach is if a name is required for every language that you have support. If so, you can have the listview prefilled with a row for each language. If not, then they could just add rows with names as needed.

Mike Hall
This is very similar to the way I have implemented things like this in the past.
y0mbo
A: 

Another suggestion would be to have a serial UI. In the case of your Add Product UI, you would have a list of Title/Description fields, one set for each supported language.

This may seem simplistic and wasteful of screen real estate, but I think it's necessary for a few reasons:

  1. If valid values are required for every language in order to save, then having a single dynamic UI (language "radio buttons" as Rex M suggests) will make it very difficult to indication validation errors to the user.
  2. Related to the last point, a serial UI allows quick scanning of language UIs. This is not simply to make sure everything is filled in, but also to allow the user to quickly compare inputs. The Add Product example is essentially a UI for inputting short translations, so being able to make comparisons between related languages is very useful. You can make this even more useful by grouping similar languages together.

The serial interface can simply be rendered by a loop that iterates over whatever your languages you currently support.

Eric Nguyen
A: 

I store a "locale" id with each content entry (for example, product 1, locale 1; product 1, locale 2, etc...)

A locale is associated to a language (English, French, Japanese...) and a region (US, Canada, Japan...)

This way, you can store "US-English" and "US-Spanish" separately from, say Spanish in Mexico.

Localization is usually not just language-based, but also content-based. For example, there may be some products that are not available in certain countries.

On the content management side, I usually have locale set via a cookie (i.e. the user can select "change locale", change the locale, and then continue editing/creating content). The reason I do this is because, other than content loading, you usually don't have the same content entry person entering multiple languages (and those that do should have to manually switch, or they can get confused: "now, what language am I working with again?")

These are just some quick pointers -- comment and I'll add suggestions based on what I've done in the past (both for personal sites, and for companies like Blockbuster and Avery Dennison)...

Jeffrey Berthiaume
+1  A: 
y0mbo
I like this because it would be a lot easier to validate that all of the languages had values. Rex's solution is probably cooler from a UI perspective and uses less real estate but validation might be tougher there. Thanks for the ideas!
Jeremy Coenen