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

Вниз

Свой формат данных на основе XML   Найти похожие ветки 

 
Tab   (2007-06-03 13:28) [0]

Можно ли на примере простейшей структуры объяснить с чего начать (и продолжить) создание своего формата на XML. Допустим есть телефонный справочник(фио, телефон, список друзей(ссылки на другие записи)). С чего начат реализацию?


 
Kolan ©   (2007-06-03 13:53) [1]

> С чего начат реализацию?

<Item>
 <ID></ID>
 <Name></Name>
 <Tel></Tel>
 <AnotherItem></AnotherItem>
</Itme>


Так?


 
Tab   (2007-06-03 14:09) [2]

А если структура не такая тривиальная?  Например написать XML схему вначале?
У кого есть опыт раскажите пожалуйста.


 
Sergey Masloff   (2007-06-03 14:13) [3]

Ну напиши схему вначале. Непринципиально. По примеру схему сгенерировыать всегда можно.


 
Tab   (2007-06-03 14:17) [4]


> Ну напиши схему вначале. Непринципиально. По примеру схему
> сгенерировыать всегда можно.

ок. например схема готова. Далее?


 
Tab   (2007-06-03 18:10) [5]

up


 
Eraser ©   (2007-06-03 18:17) [6]

> [5] Tab   (03.06.07 18:10)

в данном случае все просто, см. [1].


 
X9 ©   (2007-06-03 18:51) [7]

> [0] Tab   (03.06.07 13:28)

Применение XML далеко не во всех случаях оправдано.
На парсинг большого файла уходит слишком много времени.

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


 
Sergey Masloff   (2007-06-03 21:12) [8]

X9 ©   (03.06.07 18:51) [7]
Это легенды. Никакой потери производительности нет. Ну вместо одной десятой секунды будет две десятые секунды. Непринципиально. А при убеспечиваем удобстве вообще говорить не о чем.


 
X9 ©   (2007-06-03 21:25) [9]

> [8] Sergey Masloff   (03.06.07 21:12)
> Это легенды.

Представьте себе стогигабайтную базу данных в формате XML.
И что, производительность такой базы будет не хуже базы, хранимой в бинарном формате?


 
Sergey Masloff   (2007-06-03 21:32) [10]

X9 ©   (03.06.07 21:25) [9]
Со стомегабайтной проблем точно не будет вообще никаких (это из личного опыта - написанная мной года 4 назад система в день обрабатывает сотни файлов среди которых и стомегабайтные - за четыре года о проблемах мне ничего неизвестно).
 Сбольшими размерами все тоже будет сравнимо по скорости - DOM парсеры не единственный тип парсеров.


 
X9 ©   (2007-06-03 21:41) [11]

> [10] Sergey Masloff   (03.06.07 21:32)
> Со стомегабайтной проблем

Стомегабайтная <> стогигабайтная, [9].

Опять же, всё зависит от задачи. В большинстве случаев вся "мощь" XML просто не нужна.


 
Sergey Masloff   (2007-06-03 21:48) [12]

X9 ©   (03.06.07 21:41) [11]
В большинстве нужна. Хотя бы из соображений простоты поддержки.
У вас реально используются стогигабайтные базы в собственном формате?
Даже если так то уверяю SAX парсер к примеру будет одинаково по скорости работать вне зависимости от размера файла - хоть со стотерабайтной базой.


 
X9 ©   (2007-06-03 21:54) [13]

> [12] Sergey Masloff   (03.06.07 21:48)

Хоть убейте, не поверю, что XML будет обработан так же быстро, как и бинарный файл. Хотя бы потому, что файл XML будет иметь больший размер, а на современных компьютерах скорость подобных операций в основном упирается в работу дисковой подсистемы.


 
sniknik ©   (2007-06-03 22:55) [14]

> Хоть убейте, не поверю, что XML будет обработан так же быстро, как и бинарный файл.
точно не будет, был печальный опыт когда прислали 2 гиговый xml (чуть больше гдето ~ 2.3гиг), мелкософтский IDom документ ее вообще открыть не мог (а искать чтото другое, покупать еще... увольте. если он "универсальный" формат, то открываться должен стандартными средствами).
меня пытались "напрячь" писать парсер для этой "базы"... а это была именно база т.к. пришла на запрос бэкапа из mssql от клиента, посмотреть что у него случилось.
ну а т.к. договаривался менеджер у которого лапшу пропагандистскую можно с ушей вилками снимать... то он и ляпнул чтобы выслали в xml-е (хотя их сколько раз предупреждали о технических аспектах не говорить вообще).
в общем попытки восстановить базу из этого xml-я длились гдето с неделю, пока начальство передало это мне. типа сделай из этого базу... а нафига? когда выяснил что, это такой бэкап, просто созвонился с админом "с той стороны" и обьяснил как делается нормальный бэкап (он этого не знал оказывается к томуже, а xml у них сам бэкофис выдает (на SAP вроде)).
в итоге нормальный бэкап получился и меньше (гдето около 300-400 мег) и формировался меньше (гдето 10 мин, против как он сказал, дня...) а уж восстановление в базу так вообще несоизмеримо, теже 10 мин как и архивация против недели на все попытки...

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


 
Sergey Masloff   (2007-06-03 23:01) [15]

sniknik ©   (03.06.07 22:55) [14]
Говорю ж msxml поддерживает не только DOM но и SAX. Уверяю что стандартным msxml парсером используя SAX двухгиговый файл распарсится абсолютно без проблем. Понятное дело что DOM которому все дерево в памяти построить надо призадумается ;-)


 
sniknik ©   (2007-06-03 23:06) [16]

> С чего начат реализацию?
с отказа от xml, там где нужна база. даже не имхо.
у тебя вся база только один справочник? без индексов, группировок, обьеденений, запросов, триггеров, транзакций и т.д., т.е. просто текстовый файл определенного формата, все остальную работу будеш делать сам? тогда xml подойдет.


 
Sergey Masloff   (2007-06-03 23:10) [17]

sniknik ©   (03.06.07 23:06) [16]
>с отказа от xml, там где нужна база. даже не имхо.
Там где нужна база конечно применять XML это бред. Тут мое не имхо совпадает ;-)


 
sniknik ©   (2007-06-03 23:16) [18]

> Понятное дело что DOM которому все дерево в памяти построить надо призадумается ;-)
это было бы не самое страшное... представь что такое база (ну знаеш, я думаю ;о)), теперь представь что эту базу сконвертировали каким нибуть клиентским ПО, ну 1С кой к примеру (не думаю что у других принцип отличается), переписали все справочники в xml...
теперь как из этого xml-я сделать оригинальную базу? откуда брать тригеры, процедуры и т.д.?  и чем бы помог SAX и иже с ними?
вот, вот, я тогда даже не на йоту не задумывался о собственно "открытии" этого xml-я, т.к. место такого, для задачи, только в корзине. меня больше другое волновало, целый отдел, неделю "парился", и даже не задумались а зачем собственно это нужно... т.е. им менеджер дал файл, сказал переложите в базу... они и пытаются.


 
ShaggyDoc   (2007-06-04 11:37) [19]

Если не спорить о возможностях применения XML там, где его применять нельзя, то на исходный вопрос


> Можно ли на примере простейшей структуры объяснить с чего
> начать (и продолжить) создание своего формата на XML

я бы ответил так:

1. Не надо изобретать свой формат XML. Раз нужно использование таблицы XML в качестве плоской, однофайловой базы данных, то лучше найти готовый компонент или библиотеку, где XML используется как DataSet. Это позволит использовать без лишней мороки все компоненты для работы с данными.

2. Я перебрал много таких библиотек. Борландовский ClientDataSet часто используют, но проблемы есть. Остановился на janXmlDataSet

http://jansfreeware.com/

Формат у него, в отличие от Борландовского DATAPACKET очень прост. Не требуется и никаких dll.

3. Вот этот Dataset я уже сам переработал и дополнил. Ввел множество свойств для таблицы (SummaryInfo, метаданные, настройки полей с дополнительными атрибутами). Здесь как раз проявляется преимущество XML - дополнительные, неизвестные атрибуты игнорируются, если программа их не знает. Но таблица продолжает обрабатываться.

4. Скорость обработки XML зависит от парсера. Встречал сравнения по скорости. MSXML вроде самый тормозной. janXmlDataSet (вернее, его парсер) быстрее на порядок. Писали, что на больших объемах данных у него ошибки бывают, но я не сталкивался пока. Скорость обработки таблиц до 100 тыс. записей (больше мне не надо) практически такая же, как у обработки такой же DBF.

5. Если имеем Dataset на XML, то доступны и любые экспортно-импортные операции - библиотек полно.

Мне пришлось сделать программу, которая предназначена для ввода первичных данных на сотнях рабочих мест. Сохраняется в XML. А уже потом эти данные отправляются в настоящую слиент-серверную БД. Отдельные таблицы вполне возможно и цдобно использовать самостоятельно - например, в качестве телефонного справочника.


 
Tab   (2007-06-04 13:16) [20]

Я задумался над XML,  просто  было интересно как и что делается.
Ну а вообще  я не поддерживаю стремление пихать его везде и всюду
ибо как правильно здесь сказали, все зависит от задачи.
Всем спасибо за ответы.


 
Val ©   (2007-06-04 13:49) [21]

>[18] sniknik ©   (03.06.07 23:16)
теперь как из этого xml-я сделать оригинальную базу? откуда брать тригеры, процедуры и т.д.?  и чем бы помог SAX и иже с ними?
Если выгружаются данные, что мешает выгружать и метаданные?


 
DeadMeat ©   (2007-06-04 16:36) [22]


> ShaggyDoc   (04.06.07 11:37) [19]

Хмм.. Скачал. Установился (пардон) через зад. Если быть точным, то пришлось править исходник на предмет добавления юнитов (стандартных) и убирания какихто левых запятых в параметрах вызова его же (родных) функций.
Вроде встал. Попытался загрузить XML


 
DeadMeat ©   (2007-06-04 16:37) [23]


> ShaggyDoc   (04.06.07 11:37) [19]

Хмм.. Скачал. Установился (пардон) через зад. Если быть точным, то пришлось править исходник на предмет добавления юнитов (стандартных) и убирания какихто левых запятых в параметрах вызова его же (родных) функций.
Вроде встал. Попытался загрузить XML из примеров. Получил AV, а сам XML благополучно затерся.


 
DeadMeat ©   (2007-06-04 16:37) [24]

Пардон за двойной пост. Инет моросит.


 
TUser ©   (2007-06-04 18:41) [25]

Если предполагается редактирование кофигов пользователем, то одназначно, лучше ini.


 
ShaggyDoc   (2007-06-05 07:41) [26]


> DeadMeat ©   (04.06.07 16:37) [23]

Возможно, не то скачал и ставил.
Надо http://jansfreeware.com/easyxml4.zip

Там в подкаталоге components лежат:

janXMLparser2.pas
janstrings.pas
janXMLDataSet2.pas
BaseDataset.pas
janXMLDataSet2.dcr
janXPathTokenizer.pas
janMruMenu.dcr
janMruMenu.pas
janSQLStrings.pas

Пример таблицы БД - easydb.xml


 
DeadMeat ©   (2007-06-05 08:38) [27]


> ShaggyDoc   (05.06.07 07:41) [26]

Именно это я скачал и поставил. Я понимаю, если бы я может чтото не так делал, но вид вызова функции типа MyFunc(temp1, temp2,) мягко говоря меня смутил. И таких я там много исправлял чтобы "встало".


 
sniknik ©   (2007-06-05 08:49) [28]

> Если выгружаются данные, что мешает выгружать и метаданные?
возьми и попробуй. и посмотришь, что тебе помешает.

можеш не на SAP (сам его в глаза не видел) но у 1С 8.0 тоже есть механизм выгрузки в xml, сделай на нем.

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


 
Reindeer Moss Eater ©   (2007-06-05 09:55) [29]

К теме универсальности.

Есть система, в которой шаблоны отчетов хранятся в БД. Причем иерархически.
К каждому отчету может быть приликован запрос по которому строится отчет. (тоже в БД)
У каждого отчета может быть пре- и пост действия (произвольный PL/SQL блок)
У каждого отчета может быть форма ввода пользовательских параметров.
И так далее.

И все это дело надо реплицировать/импортировать/экспортировать.
Причем идентификация одинаковых объектов на разных серверах осуществляется по именам, а иерархия строится по числовым ID (sequence)

Можно конечно без особых проблем засунуть все это в бинарный файл.
Но вот когда на обнаруживается ситуация, что на принимающем сервере нет какой-то группы отчетов, (или есть но ключ у него другой) то я просто получаю XPath"ом список узлов, у которых парентом укзан этот объект и меняю им всем парент ссылку на новую.
Причем я волен прямо в процессе импорта добавлять служебные атрибуты или даже новые узлы в структуру транспортного файла и это никак не влияет на логическую целостность данных.
Визуализация результатов импорта/экспорта, а так же самого содержимого транспортного файла делается так же лекго, просто и изящно.
Все узлы, успешно загруженные метятся нужными атрибутами, все ошибочные узлы снабжаются кодами и текстами ошибок и т.д.
на все это накатывается xsl и отображается либо в web браузере либо просто в мемо в лучшем виде c нужной степенью детализации и нужным форматированием.


 
Val ©   (2007-06-05 10:51) [30]

>[28] sniknik ©   (05.06.07 08:49)
вообще ничего не мешает - метаданные - текст - текст выгрузить в текстовый файл проблема? в этом и вопрос.
может, посоветуешь мне поискать выгрузку в хмл у фокса досовского еще? я где-то написал про выгрузку метаданных из 1с или чего-либо еще его штатными средствами?
p.s. понты нафиг.


 
sniknik ©   (2007-06-05 11:47) [31]

> вообще ничего не мешает - метаданные - текст - текст выгрузить в текстовый файл проблема? в этом и вопрос.
проблема. и в этом ответ.
и главное проблема высосанная из пальца, для любителей не решать основную задачу, а помучиться с каким нибудь гиблым, надуманным путем решения.
(слова маркетологов об универсальности глаза застят? или полный 0 в базах? или то и другое?)
вместо того чтобы сменить инструмент и сделать тоже самое нажатием одной кнопки в нужном месте (пысть там даже и получается совершенно не универсальный, бинарный файл... ужас какой.).

> я где-то написал про выгрузку метаданных из 1с или чего-либо еще его штатными средствами?
я писал, когда обьяснял, что было сделано и почему, с чего мне предлагалось восстанавливать оригинал.
sniknik ©   (03.06.07 22:55) [14]
> а xml у них сам бэкофис выдает (на SAP вроде)
1C предложил потому как механизмы вроде похожи, и его я  хоть немного знаю, а их офис (как говорил уже) в глаза не видел.

> p.s. понты нафиг.
начинай!


 
Reindeer Moss Eater ©   (2007-06-05 11:51) [32]

слова маркетологов об универсальности глаза застят?

А если допустить, что ничего кроме документации по xml человек не читал.
В частности не читал никаких трудов маркетологов?
И при этом нашел, что xml это удобно и универсально.

Я например не читал ничего "маркетологического" по xml


 
sniknik ©   (2007-06-05 11:58) [33]

> И при этом нашел, что xml это удобно и универсально.
а вот это оно и есть

> Я например не читал ничего "маркетологического" по xml
а говоришь не читал.


 
Val ©   (2007-06-05 12:12) [34]

>[31] sniknik ©   (05.06.07 11:47)
еще раз - я говорю о беспроблемной принципиальной возможности выгрузки в хml метаданных и загрузки их в нужную базу при файловом обмене(естественно при разумном использовании, а не замене им(xml) стандартных средств экспорта/импорта или скриптов), т.е. ты привел _не_те_ аргументы против него.
P.S. Николай, я смотрю, тебе если что-то не понравилось - ты не собираешься отступать ни на йоту :) ... а стоит ли? (Вспомнились твои ругательства в адрес того же оракла...)


 
Reindeer Moss Eater ©   (2007-06-05 12:13) [35]

А что, если документ можно крутить/вертеть и как датасет и как xml и как просто текст это не унивесрсальность?


 
Reindeer Moss Eater ©   (2007-06-05 12:15) [36]

Да что их уговоривать?
Нам же больше ништяков достанется.
:)


 
sniknik ©   (2007-06-05 12:39) [37]

> еще раз - я говорю о беспроблемной принципиальной возможности выгрузки в хml метаданных и загрузки их в нужную базу
а разговор шел, о копии базы клиента, КОТОРОЙ У НАС НЕТ, ни нужной, ни вообще никакой, ни структуры, ни метаданных, НИЧЕГО. и если хочеш, попробуй сохранить ВСЮ инфу базы, в xml. просто для самообразования, посмотришь на трудности которых уверенно мне доказываешь, что их нет.
   
т.е. по аналогии
говорю что не могу доехать в нужный район, т.к. нужный автобус который мне посоветовали оказывается не ходит...
и тут мне начинают о принципиальной возможности хождения/возможности восстановить маршрут и т.д.
только нафига? если нужно это было вчера, и я уже доехал и на метро, и уже вернулся обратно.

> Вспомнились твои ругательства в адрес того же оракла...
и ничего не изменилось. и потом не перевирай, я говорил о личном негативном опыте при кратких "знакомствах", а не огульно его ругал, при том, там же допускал, что другие с ним успешно работают иначе не было бы популярности.
и допускал мысль, что доведись(вдруг придется) поработать подольше, то чтото бы и понравилось.
(вообще когда человек прикладывает слишком много усилий на изучение, ему не просто отказаться от этого, чисто психологически... проще расстаться с тем, что попробовал и сразу получилось, хотя по логике то что проще в использовании но аналогично по функционалу(етс) лучше. такой вот парадокс. не раз наблюдал)

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


 
sniknik ©   (2007-06-05 12:44) [38]

> ВСЮ инфу базы
имеется ввиду базы MSSQL, просто уточнение, а то "не обратите внимания" на ранние упоминания Enterprise Manager-а, и сделаете для парадокса... (а что, тоже база)


 
Val ©   (2007-06-05 13:23) [39]

>[37] sniknik ©   (05.06.07 12:39)
>а разговор шел, о копии базы клиента, КОТОРОЙ У НАС НЕТ, ни нужной, ни вообще никакой, ни структуры, ни метаданных, НИЧЕГО..
ну и что, если ты имеешь выгруженные и данные и метаданные и приложение которое тебе их загрузит?
> ВСЮ инфу базы
а где ж ты ранее говорил о ВСЕЙ-то? говорил о метаданных? - говорил, я тебе сказал - выгрузи и их, на что ты стал как-то резко реагиовать..хз почему. Или тебе где-то показалось, что я объвил о том, что ты несешь чушь, а я свободно xml"ем двигаю майкрософтовские да и оракловские, до кучи, базы? Говорю громко: НЕ двигаю, пользуюсь стандартными средствами.
Но если налоговая инспекция говорит, что отныне будем принимать отчеты в xml, то сделаю в xml, а не буду становиться в позу - бессмысленно.
кстати - аналогия хреновая, однобокая. ты говорил не о конкретике, а: "возьми к примеру.." и т.д.
>и потом не перевирай
это где я успел? :)


 
sniknik ©   (2007-06-05 15:18) [40]

> ну и что, если ты имеешь выгруженные и данные и метаданные и приложение которое тебе их загрузит?
кто имеет то, какое приложение? ты читал вообще о чем говорилось?
да и не выгрузишь ты все, при озвученных условиях, и даже программой на дельфе сомневаюсь чтобы учел все, попробуй убедись. (хотя бы просто зайди в EM, открой тестовую базу и полазь, полюбопытствуй, по системным таблицам, вюхам, процедурам и т.д. и учти что ко многому просто, так запросом, ты доступа не имеешь. нужны знания. и немалые чтобы получить ВСЕ)

> а где ж ты ранее говорил о ВСЕЙ-то? говорил о метаданных?
когда говорил, что на самом деле нужен был бэкап, если подумать, который с успехом и был сделан.
или тебе неясно что представляет из себя бэкап? придираешься что слово не прозвучало? так кто же знал что среди буквоедов такие .... э... не могу придумать ничего цензурного.

> я тебе сказал - выгрузи и их
ну во первых выгрузить это нужно было не мне (очевидно из первого же поста)
> на что ты стал как-то резко реагиовать..хз почему.
потому что я понимаю сложность реализации твоего глупого совета, и мне не нравятся люди которые "ляпают не думая", ничего в предметной области не понимающие.

> а я свободно xml"ем двигаю майкрософтовские да и оракловские, до кучи, базы?
не надо громких слов, просто сделай бэкап базы в xml, так чтобы можно восстановить... естественно не пользуясь стандартными(может в 2005м уже есть чтото подобное, допускаю) а своими силами.
хотя бы часть (ничего невозможного, из того что и я могу и довольно легко, долго, муторно но легко (но вот обьяснить админу по удаленке это нереально) - структуру таблиц с индексами, ключами, внешними ключами, процедуры, юзеров и их привилегии), все, хотя бы это. чтоб знать, можно ли с тобой дальше говорить "на равных" в предметной области.

> Но если налоговая инспекция говорит, ...
> ты говорил не о конкретике,
не притягивай за уши другие задачи, описывалась всетаки конкретная ситуация и конкретные условия. я и сам могу сказать где использую xml, и это ничего не значит.
> а: "возьми к примеру.." и т.д.
а это говорилось о варианте самому сделать тоже самое, т.к. доступа к тому инструменту нет и не будет и знаний по нему 0, а примерно то же самое позволяет 1С. не видиш разницы?


 
Reindeer Moss Eater ©   (2007-06-05 15:25) [41]

Все это очень интересно, но к теме никак не относится.

А то можно решить, что дампы оракловой схемы - это намного лучший вариант обмена данными (если даже у корреспондента нет оракла)


 
Reindeer Moss Eater ©   (2007-06-05 15:28) [42]

речь ведь шла не о  трудностях извлечения данных/метаданных из 1С, а о легкости их струкурирования в xml


 
sniknik ©   (2007-06-05 15:58) [43]

> Все это очень интересно, но к теме никак не относится.
всего лиш ответил на вопрос/совет. что получилось то получилось...

> речь ведь шла не о  трудностях извлечения данных/метаданных из 1С, а о легкости их струкурирования в xml
не совсем. речь шла, вернее началась с вопроса "С чего начат реализацию?" для телефонного справочника, с выбором за базу почемуто xml-я.
(надеюсь уже одумался... т.к. база это не только легкость структурирования)


 
Val ©   (2007-06-05 16:02) [44]

>[40] sniknik ©   (05.06.07 15:18)
Продолжать не буду. Создается чувство, что мы о разных вещах параллельно вещаем. Вполне возможно, что равных тебе нет :)


 
VEG ©   (2007-06-05 17:57) [45]


> <Item>
>  <ID></ID>
>  <Name></Name>
>  <Tel></Tel>
>  <AnotherItem></AnotherItem>
> </Itme>
>
> Так?

На мой взгляд лучше использовать атрибуты.
<progname version="">
 <telbase>
   <tel id="1" name="Vasya" num="5552356" />
   <tel id="2" name="Evgen" num="5552357" />
 </telbase>
</progname>
Так на мой взгляд выглядит привлекательнее :)
А вообще если база большая, то я не думаю, что XML — хороший выбор. Какая-нибудь бинарная база будет лучше.



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

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

Наверх





Память: 0.6 MB
Время: 0.04 c
11-1164483786
KingMidas
2006-11-25 22:43
2007.07.08
Проблема с Memo и CheckBox


15-1181023046
vajo
2007-06-05 09:57
2007.07.08
Excel 2003. Число прописью


3-1176204004
allucard
2007-04-10 15:20
2007.07.08
Как хранить компоненты в БД?


3-1176199544
Micke_2007
2007-04-10 14:05
2007.07.08
linked server


2-1181839775
Zero
2007-06-14 20:49
2007.07.08
procedure TMainForm.FormCreate





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
Английский Французский Немецкий Итальянский Португальский Русский Испанский