Каков хороший дизайн пользовательского интерфейса для управления многоязычными данными?

Question

Я собираюсь создать многоязычный веб-сайт (asp.net), и мне было интересно, как лучше всего справиться с большей частью работы интерфейса администратора, где конечный пользователь будет поддерживать списки данных, которые должны быть в нескольких языки. Кто-нибудь знает какие-нибудь хорошие примеры приложений, на которые я могу взглянуть?

Пример сценария. У меня есть экран, который администратор будет использовать, чтобы добавить новый продукт. Заголовок и описание должны быть сохранены для каждого языка в системе и будут необходимы для сохранения. Количество языков в идеале должно быть динамическим / настраиваемым, когда пользовательский интерфейс не нужно будет менять каждый раз, когда мы добавляем новый язык.

Мысли / предложения / примеры?

Answer 1

Наша предыдущая внутренняя CMS использовала довольно простую модель, которая, похоже, понравилась редакторам: над каждым полем ввода был выбран тонкий ряд переключателей (с поддержкой JS), какой язык редактировался в настоящее время:

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

Они ведут себя как переключатели, например выбор одного отменяет выбор всех остальных, и текстовое поле немедленно переворачивается, чтобы отразить это значение. Кнопки были достаточно маленькими, чтобы поместиться примерно на 16 над полем ввода, прежде чем оно стало громоздким.

Я бы также порекомендовал «главный переключатель» вверху страницы, который переключает все элементы управления одновременно.

Answer 2

Чтобы продолжить с ответом @ mikehall выше, я бы сделал что-то вроде этого наброска:

Ввод данных локализации http://redbitbluebit.com/images/language.png

Конечно, мои переводы составлены; -)

Answer 3

У нас есть старое приложение MFC, которое делает это. В нем есть текстовое поле для имени, которое будет именем объекта, которым вы управляете, на текущем языке диалога (на языке, который текущий пользователь установил и просматривает приложение). Ниже приведен список, в котором вы можете добавить остальные имена для каждого языка, который вы поддерживаете.

Одна вещь, которая может изменить ваш подход, - это если имя требуется для каждого языка, который вы поддерживаете. Если это так, вы можете предварительно заполнить представление списка строкой для каждого языка. Если нет, то они могут просто добавлять строки с именами по мере необходимости.

Answer 4

Я сохраняю идентификатор «locale» для каждой записи контента (например, продукт 1, локаль 1; product 1, локаль 2 и т. Д.)

Локаль связана с языком (английский, французский, японский ...) и регионом (США, Канада, Япония ...)

Таким образом, вы можете хранить «американский-английский» и «американский-испанский» отдельно, скажем, от испанского в Мексике.

Локализация обычно не только на основе языка, но и на основе контента. Например, некоторые продукты могут быть недоступны в некоторых странах.

На стороне управления контентом я обычно устанавливаю языковой стандарт с помощью файла cookie (то есть пользователь может выбрать «изменить языковой стандарт», изменить языковой стандарт и затем продолжить редактирование / создание контента). Причина, по которой я это делаю, заключается в том, что, кроме загрузки контента, у вас, как правило, нет одного и того же человека, который вводит контент, на нескольких языках (и те, кому это нужно, должны переключаться вручную, или они могут запутаться: Я снова работаю? ")

Это всего лишь несколько быстрых указателей - прокомментируйте, и я добавлю предложения, основанные на том, что я делал в прошлом (как для личных сайтов, так и для таких компаний, как Blockbuster и Avery Dennison) ...

Answer 5

Еще одно предложение - иметь серийный интерфейс. В случае вашего интерфейса добавления продукта у вас будет список полей заголовка / описания, по одному для каждого поддерживаемого языка.

Это может показаться упрощенным и расточительным для экранной недвижимости, но я думаю, что это необходимо по нескольким причинам:

1. Если для каждого языка требуются действительные значения для сохранения, то наличие единого динамического пользовательского интерфейса (языковые «переключатели», как предлагает Rex M) очень затруднит индикацию ошибок проверки пользователю.
2. Что касается последнего пункта, последовательный интерфейс пользователя позволяет быстро сканировать языковые интерфейсы. Это не просто для того, чтобы убедиться, что все заполнено, но и для того, чтобы пользователь мог быстро сравнить входные данные. Пример «Добавить продукт» по сути является пользовательским интерфейсом для ввода коротких переводов, поэтому возможность сравнения между родственными языками очень полезна. Вы можете сделать это еще более полезным, сгруппировав похожие языки.

Последовательный интерфейс может просто отображаться циклом, который перебирает все языки, которые вы в данный момент поддерживаете.