Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Потрепаться";
Текущий архив: 2005.12.25;
Скачать: [xml.tar.bz2];

Вниз

Варианты решения задачи на проектирование UI   Найти похожие ветки 

 
Янис Прасол ©   (2005-11-29 18:22) [0]

При проектировании пользовательского интерфейса в одном приложении возникла следующая проблема.

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

Вопрос: как поступать, если пользователь ввел начальную дату больше конечной?
Варианты решения, которые вижу я:

1. При попытке начать поиск, выдать ему сообщение, информирующее о некорректности введенных данных.
2. Не давать возможности нажать на кнопку, пока значения не будут введены верно (делать ее неактивной).
3. Не давать возможности ввести конечную дату меньше начальной (вешаться на OnChange) и наоборот.
4. При поиске менять местами границы интервала.
5. Игнорировать подобную некорректность, просто при поиске выдавать 0 результатов.

Какой вариант предпочтительнее и почему? Как бы вы решили эту задачу?
Если у вас есть другие варианты, предлагайте.


 
Ega23 ©   (2005-11-29 18:24) [1]


> 1. При попытке начать поиск, выдать ему сообщение, информирующее
> о некорректности введенных данных.


По опыту работы с UI и из опыта общения с теми самыми U, использующими мой I, первый вариант - самый оптимальный.


 
begin...end ©   (2005-11-29 18:24) [2]

1


 
Reindeer Moss Eater ©   (2005-11-29 18:25) [3]

Начальная дата, большая чем конечная автоматом присваивает такое же значение конечной дате.

И наеборот.


 
Reindeer Moss Eater ©   (2005-11-29 18:26) [4]

1. При попытке начать поиск, выдать ему сообщение, информирующее о некорректности введенных данных.

Бессмысленный вариант.


 
Игорь Шевченко ©   (2005-11-29 18:27) [5]

6. Вешаться на OnChange и подсвечивать некорректную дату ничего не запрещая. При поиске сказать, что диапазон некорректен.


 
vrem   (2005-11-29 18:27) [6]

Строка состояния в диалоге, в ней длина интервала или слово типа "не корректно". Пусть моргает как в win2k заголовок окна требующего ответа.
Тогда при ошибке не нужно будет заново открывать диалог выбора дат.


 
Янис Прасол ©   (2005-11-29 18:27) [7]

Первый вариант, безусловно, самый простой, но не самый лучший. Выдавать пользователю сообщения об ошибках в результате его корректных действий — дурной тон. Гораздо лучше не дать ему возможности совершать некорректные действия.


 
Alkid ©   (2005-11-29 18:28) [8]


> 1. При попытке начать поиск, выдать ему сообщение, информирующее
> о некорректности введенных данных.
>
> Бессмысленный вариант.

Не бессмысленный. Человек сразу получает информацию о том, где он напортачил. Так что я за 1-ый вариант.


 
Ega23 ©   (2005-11-29 18:30) [9]


> сообщения об ошибках в результате его корректных действий
> — дурной тон.


Это не сообщение об "ошибках в результате его корректных действий". Это указание того, что его действия - некорректны.


 
Gero ©   (2005-11-29 18:30) [10]

Вариант №1 плох еще и тем, что такая пара полей не одна. Представьте, каково будет пользователю, если он допустил ошибки в нескольких сразу?


 
Игорь Шевченко ©   (2005-11-29 18:31) [11]


>  Гораздо лучше не дать ему возможности совершать некорректные
> действия.


При этом желательно сказать, почему они некорректные.

Вариант 5 - работать по принципу: "Вы этого хотели - вот вам". Просто, но вряд ли пользователи оценят эту простоту.


 
Янис Прасол ©   (2005-11-29 18:32) [12]


> Reindeer Moss Eater ©   (29.11.05 18:25)
> Начальная дата, большая чем конечная автоматом присваивает
> такое же значение конечной дате.
>
> И наеборот.

В каком месте это делать? Пре введении или при старте поиска?


 
Reindeer Moss Eater ©   (2005-11-29 18:33) [13]

В каком месте это делать? Пре введении или при старте поиска?

Нарисуй фрейм и обрабатывай все в нем прямо на этапе ввода.

Вариант №1 бессмысленный потому, что никакой пользы не приносит.
Когда введенная начальная дата больше конечной это безусловно неправильно.
Выходов два - уменьшить начальную или увеличить конечную.

Первый выход неправильный, так как отменяет то, что ввел пользователь по своей доброй воле.
Выход второй - правильный и потому единственно возможный.

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


 
Джо ©   (2005-11-29 18:34) [14]

Я делал так:
http://kmp.ho.com.ua/datedialog.jpg
Т.е, при выборе всегда показывается кол-во дней между двумя выбранными данными (для контроля), вне зависимости от того, в каком порядке указаны границы диапазона. Соответственно, при обработке введенных значений интервал корректируется, без всяких сообщений, блокирования кнопок и проч.


 
begin...end ©   (2005-11-29 18:34) [15]

> Янис Прасол ©   (29.11.05 18:27) [7]

> Гораздо лучше не дать ему возможности совершать некорректные
> действия.

Вот ты и не даёшь ему совершить некорректное действие -- начать поиск с некорректными параметрами.

> Gero ©   (29.11.05 18:30) [10]

> Представьте, каково будет пользователю, если он допустил
> ошибки в нескольких сразу?

Представь, сколько пользователь будет чесать репу в случае вариантов 2 или 5.


 
Игорь Шевченко ©   (2005-11-29 18:34) [16]

Gero ©   (29.11.05 18:30) [10]

Я проверяю по мере ввода, подсвечивая некорректные значения "цветом неверности", сам понимаешь - по умолчанию желтым, с возможностью настройки.

Если человек обратит внимание на подсветку, то его незачем пугать страшными сообщениями вида "ты полный идиот, тебе нельзя работать с программой". Кстати, сообщения об ошибке лучше сделать не MessageBox по центру экрана, а неким аналогом Baloon Tips со стрелочкой, указывающей на неверное значение.


 
Jeer ©   (2005-11-29 18:36) [17]

Янис Прасол ©   (29.11.05 18:32) [12]

Поиск - это следующая операция и не нужно возвращать пользователя назад.
Поддерживаю Reindeer Moss Eater ©   (29.11.05 18:25) [3]
Так и делаю всегда, если нет особых условий по диапазону.


 
Игорь Шевченко ©   (2005-11-29 18:36) [18]

Джо ©   (29.11.05 18:34) [14]


> Я делал так:
> http://kmp.ho.com.ua/datedialog.jpg


А что, с 30.11.2005 по 29.11.2005 действительно два дня прошло ? :))


 
Джо ©   (2005-11-29 18:38) [19]


>  [18] Игорь Шевченко ©   (29.11.05 18:36)
> Джо ©   (29.11.05 18:34) [14]
> А что, с 30.11.2005 по 29.11.2005 действительно два дня
> прошло ? :))

Не прошло, но запрашиваются данные именно за 2 дня: 29-е и 30-е.


 
Янис Прасол ©   (2005-11-29 18:39) [20]


Reindeer Moss Eater ©   (29.11.05 18:33)
> Например у юзера выставлен правильный период времени, но
> он его хочет сдвинуть дальше в будущее.
> Он волен делать это начиная с любого контрола.
> И если он начнет с начальной даты, и введет значение, превышающее
> конечное, алгоритм выставит правильное конечное значение.

А если он хочет сдвинуть его в прошлое и начнет с конца?


 
Jeer ©   (2005-11-29 18:39) [21]

Джо ©   (29.11.05 18:38) [19]
В таком случае, вводить нач. дату и ко-во дней, а устраивать "машину обратного времени" -  как-то с логикой плохо.


 
Джо ©   (2005-11-29 18:42) [22]


>  [21] Jeer ©   (29.11.05 18:39)
> Джо ©   (29.11.05 18:38) [19]
> В таком случае, вводить нач. дату и ко-во дней, а устраивать
> "машину обратного времени" -  как-то с логикой плохо.

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


 
Игорь Шевченко ©   (2005-11-29 18:42) [23]

Джо ©   (29.11.05 18:38) [19]

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


 
Jeer ©   (2005-11-29 18:43) [24]

Джо ©   (29.11.05 18:42) [22]


> программистский ход мысли


"Тут я сильно засомневался".


 
Gero ©   (2005-11-29 18:44) [25]


Игорь Шевченко ©   (29.11.05 18:34)
> Кстати, сообщения об ошибке лучше сделать не MessageBox
> по центру экрана, а неким аналогом Baloon Tips со стрелочкой,
> указывающей на неверное значение.

Да, вот с этим согласен. Кстати, Baloon Tips когда в винде появились? В w2k?


 
Reindeer Moss Eater ©   (2005-11-29 18:46) [26]

А если он хочет сдвинуть его в прошлое и начнет с конца?

Такой же точно алгоритм, только корректируем начальную дату.


 
Янис Прасол ©   (2005-11-29 18:51) [27]


> Reindeer Moss Eater ©   (29.11.05 18:46)

Да, понял, тоже очень хороший вариант.


 
arhis   (2005-11-29 18:51) [28]

И откуда только у некоторых программистов такие дурацкие вопросы только появляются? Вы всерьез отделяете себя от остальной массы пользователей? Комплекс бога не замучал? Самому то как прощще?


 
Янис Прасол ©   (2005-11-29 18:55) [29]


> Reindeer Moss Eater ©   (29.11.05 18:46)

В нем один нетостаток только имеется. Предположим, пользователь вводит сначала начальную дату, потом конечную и случайно нажимает не на ту клавишу, конечная получается больше начальной и начальная корректируется. Пользователю приходится вводить все заново.

Мне кажется, это хороший способ вызвать раздражение у пользователя.


 
Джо ©   (2005-11-29 18:55) [30]

Объсню свой вариант.

Вначале было так. Подписи гласили "Начальная дата", "Конечная дата". Надписи "количество дней" не было. При неверном указании диапазона выводилось сообщение. Я стал получать постоянные "дурацкие" вопросы о том, как правильно вводить даты, какую указывать первой и.т.д... ибо, как я понял, пользователей пугала
1. Необходимость указывать даты в каком-то определенном порядке (это на самом деле субъективно)
2. Дело усугублял Warning.
И это всего лишь внутрифирменная утилита, я представляю, что  было бы если бы она пошла гулять "в свет".

После того, как сделал [14] все вопросы прекратились. Вводи, как хочешь, программа сама скорректирует алгоритм. Для контроля всегда показывается кол-во дней, за которые будут получены данные. Также изменил подписи на "с, по" без упоминания слов "конечная, начальная".


 
Джо ©   (2005-11-29 18:57) [31]

И, все-таки, еще раз: ЗАЧЕМ заставлять вводить даты в каком-то одном определенном порядке? Какой в этом смысл?


 
Reindeer Moss Eater ©   (2005-11-29 18:58) [32]

В нем один нетостаток только имеется. Предположим, пользователь вводит сначала начальную дату, потом конечную и случайно нажимает не на ту клавишу, конечная получается больше начальной и начальная корректируется. Пользователю приходится вводить все заново.

Коррекция дат должна происходит не по нажатию "Ok", а в процессе ввода.


 
Gero ©   (2005-11-29 18:59) [33]


> Джо ©   (29.11.05 18:57)

Незачем. Просто пользователи привыкли именно к такому варианту, к последовательности. А «умные» варианты могут запросто его запутать.


 
Янис Прасол ©   (2005-11-29 19:01) [34]


> Reindeer Moss Eater ©   (29.11.05 18:58)

Вот-вот, именно в процессе ввода. Когда пользователь будет вводить конечную дату, он может ошибится, что сразу же повлияет на начальном значении.


 
vrem   (2005-11-29 19:04) [35]

Так у вас выходит два, и оба, и вылечат? :)))


 
Igorek ©   (2005-11-29 19:07) [36]

Думаю надо не давать возможность ввести некорректный диапазон. Вот представьте что надо выбрать отрезок. Логично продоставить что-то типа линейки с двумя ползунками. Левый ползунок нельзя переместить правее правого и наоборот. Также и здесь: вначале корректный диапазон; менять каждую дату можно только в определенном диапазоне (дальше просто не крутится селектор даты и дни деактивированы).
Можно даже сделать один селектор на диапазон.


 
Igorek ©   (2005-11-29 19:11) [37]

Никакой автокоррекции. Этими "умными" программами лично я уже сыт по горло.

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


 
Янис Прасол ©   (2005-11-29 19:15) [38]


> Igorek ©   (29.11.05 19:07)

От линейки с ползунками отличается тем, что ползунки двигаются последовательно, а дату пользователь может ввести какую-угодно сразу.

> Этими "умными" программами лично я уже сыт по горло.

Да, тоже об этом думаю.


 
Piter ©   (2005-11-29 19:24) [39]

Янис Прасол ©   (29.11.05 18:22)
1. При попытке начать поиск, выдать ему сообщение, информирующее о некорректности введенных данных


ну или что почти тоже самое:

Игорь Шевченко ©   (29.11.05 18:27) [5]
6. Вешаться на OnChange и подсвечивать некорректную дату ничего не запрещая. При поиске сказать, что диапазон некорректен


Игорь Шевченко ©   (29.11.05 18:34) [16]
лучше сделать не MessageBox по центру экрана, а неким аналогом Baloon Tips со стрелочкой, указывающей на неверное значение.


соглачсен.


 
Piter ©   (2005-11-29 19:28) [40]

arhis   (29.11.05 18:51) [28]
И откуда только у некоторых программистов такие дурацкие вопросы только появляются


только из-за того, что они программисты, а не батонокидатели.


 
Джо ©   (2005-11-29 19:37) [41]


>  [33] Gero ©   (29.11.05 18:59)
> Незачем. Просто пользователи привыкли именно к такому варианту,
> к последовательности. А «умные» варианты могут запросто
> его запутать.

Надо полагать, статистика уже собрана? ;) На основании чего такой вывод?

Про специальный контрол-селектор тоже думал. Как мне показалось, будет неудобно вводить длинные интервалы. Представьте, что нужны будут данные за несколько лет, "с" и "по" определенную дату. Очень мелкий "ползунок" будет и большая погрешность при перетаскивании.


 
Янис Прасол ©   (2005-11-29 19:40) [42]


> На основании чего такой вывод?

На основании личных ощущений, например.

> Про специальный контрол-селектор тоже думал. Как мне показалось,
> будет неудобно вводить длинные интервалы. Представьте, что
> нужны будут данные за несколько лет, "с" и "по" определенную
> дату. Очень мелкий "ползунок" будет и большая погрешность
> при перетаскивании.

Это точно. Нужны конкретные значения.


 
vuk ©   (2005-11-29 19:53) [43]

У нас для ввода периода есть специальный элемент управления.
Для начала поясню, что для удобства выделены несколько видов периодов:
1. год (вводится число)
2. квартал года (Год, номер квартала)
3. месяц (Год, месяц)
4. Произвольный (две даты)
5. За последние X дней (число дней)

Элемент управления представляет собой редактор с 3-мя кнопками. По нажатию на кнопку вываливается диалог, где есть PageControl c закладкой на каждый вид периода. Оставшиеся две кнопки предназначены для быстрого сдвига вперед и назад на интервал, который меняется в зависимости от выбранного вида периода. Например, если выбран вид периода "месяц", то нажатие на кнопки будет сдвигать период вперед или назад на месяц.

Примерно так...


 
Antonn ©   (2005-11-29 19:54) [44]

Янис Прасол ©   (29.11.05 18:22)
Вопрос: как поступать, если пользователь ввел начальную дату больше конечной?

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


 
GuAV ©   (2005-11-29 23:02) [45]


> Вариант №1 плох еще и тем, что такая пара полей не
> одна. Представьте, каково будет пользователю, если он
> допустил ошибки в нескольких сразу?

Он увидит только одно окно и фокус будет установлен на нужное поле.


> Гораздо лучше не дать ему возможности совершать
> некорректные действия.

Ну поставь dtpSince.MaxDate := dtpTo.Date и dtpTo.MinDate := dtpSince.Date . Вряд ли это кому понравится.


 
Янис Прасол ©   (2005-11-29 23:26) [46]

На основании советов постараюсь принять какое-то решение.
Всем ответившим спасибо.


 
iZEN ©   (2005-11-30 00:15) [47]


> Янис Прасол ©   (29.11.05 18:22)

Классическая задачка из области проектирования удобного и дружественного пользовательского интерфейса.
Решение можно найти в книжке Джефа Раскина "Интерфейс".

Основные принципы:
1. Не позволять пользователю указывать неверные значения в силу невозможности произведения оных (у вас возможно).
2. Никакие диалоги типа "Это неверно! Повторите ввод." ненужны.

Возможное решение (по-моему): один слайдер шкалы времени с двумя физически непересекающимися движками, которые указывают на "Начальная дата" и "Конечная дата" соответственно; заданный интервал - расстояние между движками. И, конечно же, кнопка начала операции. Боюсь, что этот вариант возможен только в контролах Java Swing, для Windows нужно штудировать литературу.


 
Gero ©   (2005-11-30 01:14) [48]


iZEN ©   (30.11.05 00:15)
> один слайдер шкалы времени с двумя физически непересекающимися
> движками

Подобный вариант уже обсуждали. Недостатки смотри в [41].


 
КаПиБаРа ©   (2005-11-30 05:54) [49]


>Основные принципы:
> 1. Не позволять пользователю указывать неверные
> значения в силу невозможности произведения оных (у вас
>возможно).
> 2. Никакие диалоги типа "Это неверно! Повторите ввод."
> ненужны.


В соответствии с этими правилами.

1. Если в текущий момент времени введен некоректный диапазон кнопку "Продолжить" сделать неактивной.

2. Показать пользователю в чем проблема. Для этого вывести сообщение прямо над кнопкой, а лучше возле того контрола в котором введены некорректные значения. Для этого можно использовать всплывающую подсказку или специальный значек (как в MS Excel).


 
ANB ©   (2005-11-30 09:30) [50]

Ползунок - жутко неудобно.
Коррекцию контролов делал - не очень удобно, хотя если интервал, как правило, фиксированный - то это оправдано.
Нормальных идей 2 :
1. Сообщение об ошибке (лучше не окошко)
2. Поменять местами начало и конец.
Все стырено.
Кстати, во времена ЕС ЭВМ при написании программ для терминалов в виде формы ввода частенько использовался следующий прием :
При посылке данных в компьютер (нажатие ввода) данные проверялись в программе и, если что не так - выводилась строка об ошибке (моргала внизу экрана) и курсор устанавливался на место ошибки. Было довольно удобно. Когда пошли программы под ДОС на бейсике - жутко добивал построчный ввод.

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


 
msguns ©   (2005-11-30 09:42) [51]

>2. Не давать возможности нажать на кнопку, пока значения не будут введены верно (делать ее неактивной).
>3. Не давать возможности ввести конечную дату меньше начальной (вешаться на OnChange) и наоборот.

Страшно неудобный интерфейс, не позволяющий вводить данные в произвольном порядке, в т.ч. частично Есть одна прога из "Центра", которая требует строго последовательный ввод всех данных (порядка 30 полей) - жутко противная прога !

>4. При поиске менять местами границы интервала.

Вообще рулез ;))

>5. Игнорировать подобную некорректность, просто при поиске выдавать 0 результатов.

Ага, особенно на базе из нескольких десятков миллионов записей. Думать будет минут 10, а в это время юзер будет материть "тупую" прогу, ищущую документы "с февраля по январь".

Оптимальный способ ввода периода указал uk ©   (29.11.05 19:53) [43]
Очень удобно, быстро, понятно. Покрывает 100% потребности. Реализуется достаточно просто.


 
vlad433 ©   (2005-11-30 09:52) [52]

По-моему, проще всего в OnExit конечной даты проверять и выдавать сообщенние с фокусом на ней.


 
msguns ©   (2005-11-30 09:56) [53]

>vlad433 ©   (30.11.05 09:52) [52]
>По-моему, проще всего в OnExit конечной даты проверять и выдавать сообщенние с фокусом на ней.

Прочитай [51] (первый комментарий)


 
vlad433 ©   (2005-11-30 10:08) [54]

[43]-сложнее и юзеру думать надо. А две даты обычно повторяются, в смысле при показе формы уже присвоены. Например бух считает обороты. Он их за день считает раз 100 и все время те же (для баланса). Что ему, каждый раз думать, что вводить ? :)


 
КаПиБаРа ©   (2005-11-30 10:11) [55]

msguns ©   (30.11.05 9:42) [51]
Оптимальный способ ввода периода указал uk ©   (29.11.05 19:53) [43]
Очень удобно, быстро, понятно. Покрывает 100% потребности. Реализуется достаточно просто.


vuk ©   (29.11.05 19:53) [43]
4. Произвольный (две даты)


Опять возвращаемся к нашему вопросу. Как реализовать ввод двух дат? :)


 
ANB ©   (2005-11-30 13:02) [56]


> Опять возвращаемся к нашему вопросу. Как реализовать ввод
> двух дат? :)

Надо сделать специальный компонент для ввода периода.


 
vuk ©   (2005-11-30 17:46) [57]

to vlad433 ©   (30.11.05 10:08) [54]:
>сложнее и юзеру думать надо.
Ну... Юзеру думать всегда надо, просто так никто в фильтры не лезет, и значит уже подумал. В любом случае интервал дат не с потолка берется. А в данном элементе управления нужный интервал обычно всего выбирается в один клик мышкой, т.к. чаще всего выставлен интересующий пользователя вид периода и нужен только его сдвиг (например, навигация вперед или назад по дням или месяцам). Наличие же периодов типа "за x последних дней" приводит к тому, что интервал часто вообще не нужно выбирать - он уже нужный стоит при открытии пользователем формы. Дело в том, что как показала практика, самый распространенный фильтр - "за 1 последний день".

>Что ему, каждый раз думать, что вводить ? :)
А запомнить настройки формы - не судьба?

to КаПиБаРа ©   (30.11.05 10:11) [55]:
>Опять возвращаемся к нашему вопросу. Как реализовать ввод двух дат? :)
Два выпадающих календаря. Выбор во втором даты меньше, чем в первом или выбор в первом даты больше, чем во втором не проходит. То есть остается старое значение, никакой ругани. Выбор не самый быстрый из возможных, но с учетом того, что произвольный период реально используется реже всего, это не страшно.



Страницы: 1 2 вся ветка

Форум: "Потрепаться";
Текущий архив: 2005.12.25;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.63 MB
Время: 0.012 c
4-1130328960
Mpokemonov
2005-10-26 16:16
2005.12.25
открыть DLL


2-1133883102
BackGround
2005-12-06 18:31
2005.12.25
TCriticalSection


2-1134134646
Bandit
2005-12-09 16:24
2005.12.25
Мастера! Помогите с TQuickRep!!!


2-1134038542
kyn66
2005-12-08 13:42
2005.12.25
Данные из таблицы показать в ComboBox


4-1130140872
DVM
2005-10-24 12:01
2005.12.25
Заголовочный PAS-файл к Intel Jpeg Library





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский