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

Вниз

Нумерация документов   Найти похожие ветки 

 
Leon1   (2005-01-28 08:28) [0]

Народ, ни кто не сталкивался с данной штукой? как лучше реализовать? естественно Номер документа как первичный ключ не подойдет! У меня есть идеи например:
1)реализация с помощью отдельной таблицы с автоинкрементным полем в которую производится вставка перед открытием документа тем самым можно получить значение следующего номера, минус этого способа если документ будет открыт и не записан получится что номер пропал
2)То же что и первое но вставка производится после запсиси документа, а значение автоинкрементного поля получается в момент открытия документа и увеличивается на 1.. минус пользователь может держать фиг знает сколько этот документ открытым и могут родиться документы с содинаковыми номерами
3) SQL запрос на MAX(NumDoc) минус точно такой же как и у 2 способа
4) SQL запрос на COUNT(*) минус номера должны быть изменяемыми и если после первого пошел 10 то следующий получим не 11 а 3...
Мож кто то подскажет еще какие нибудь решения?????


 
Sergey13 ©   (2005-01-28 09:19) [1]

>номера должны быть изменяемыми
Это как? Что это за номера такие?
Процесс записи должен быть коротким. Прочитал запись в переменные, работай скока шочешь, перед записью проверь условия и, при выполнении их, быстро запиши.
ЗЫ: Для многопользовательской работы лучше применять соответствующие инструменты. (это я про Парадокс 8-)


 
Leon1   (2005-01-28 09:46) [2]

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


 
Sergey13 ©   (2005-01-28 09:51) [3]

2[2] Leon1   (28.01.05 09:46)
>Ну положем объем задачи не такой чтобы применять SQL сервера,
А какой объем, по твоему критичен?

>мало ли какая хрень может случиться что потребуется номер документа изменить...
Вот именно хрень. Документ же наверное имеет и печатную копию. Перепечатывать. Если ты меняешь один, то может и остальные перенумеровываешь? Это ж быардак получается, ИМХО. ИМХО, опять же, но номер это неизменный атрибут документа.
Что за документы у тебя вообще? Накладные какие нибудь или что?


 
ЮЮ ©   (2005-01-28 09:54) [4]

Во-первых, только не инкремент.
Во-вторых, в силу 1)-4) можно сразу взять номер на 1 болше, чем последний MAX(NumDoc) + 1, а при сохранении проверить, не записал ли кто документ с таким номером и, известив об этом сохраняющего документ пользователя, предложить ему новый номер.


 
Leon1   (2005-01-28 10:25) [5]

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


 
msguns ©   (2005-01-28 10:33) [6]

1. Номер документа должен состоять из двух полей: числового и символьного.
2. Номер документа может меняться как при вводе, так и при корректировке документа
3. Номер (числовой) при добавлении документа может вычисляться автоматически как MAX(<Числовая часть номера>) WHERE <Тип документа> and <Условие по году>
4. В структуре записи заголовка док-та предусмотреть поле "Входящий номер" (симв. не менее 24) и "Входящая дата" для сохранения там оригинальных (с документа) номера и даты (используется для приходных и возвратов от покупателей)


 
msguns ©   (2005-01-28 10:53) [7]

5. Перед записью нового/измененного заголовка документа можно давать запрос на поиск аналогичного и если есть, давать предупреждение с возможностью вычисления нового автономера. Эта фича, если честно, бывает практически не нужна: вероятность одновременного ввода однотипных документов за достаточно малое время мизерная.


 
Sergey13 ©   (2005-01-28 11:08) [8]

[6] msguns ©   (28.01.05 10:33)
Все правильно, только уж слишком, ИМХО. 8-)
Я не вижу особых причин вообще редактировать номер. Просто смысла не вижу, а гемороя добавляет. Может я и ошибаюсь.


 
Соловьев ©   (2005-01-28 11:13) [9]

>[D7, Paradox]
>3) SQL запрос на MAX(NumDoc) минус точно такой же как и у 2 >способа
Почему это минус? Для файловых СУБД это как раз ед. решение.


 
msguns ©   (2005-01-28 11:17) [10]

>Sergey13 ©   (28.01.05 11:08) [8]
>Я не вижу особых причин вообще редактировать номер. Просто смысла не вижу, а гемороя добавляет.

Так от тебя не требуется видеть смысл, от тебя требуется лишь предусмотреть такую возможность ;)

Ладно, так и быть, один из вариантов смысла:
Есть системы, в которых нет счетов. Вернее, они вообще-то могут печататься, по ним резервируется товар и т.д. Фактически же "счет" есть не что иное, как непроведенная накладная отгрузки. Когда покупатель забирает товар, то накладная проводится (снимаются остатки со склада) и "счет" становится "накладной". Естественно, нумерация счетов и накладных разная. Вот оператор перед проведением документа и меняет № с "Номера счета" на "Номер накладной отгрузки"


 
Sergey13 ©   (2005-01-28 11:43) [11]

2[10] msguns ©   (28.01.05 11:17)
>от тебя требуется лишь предусмотреть такую возможность
В том то и дело, что пока не требовалось. 8-)

>и "счет" становится "накладной".
Интересные превращения. Рубли там долларами не становятся? Нет? Жаль. 8-)
Можно конечно придумать ситуации, но смысл этого мне все равно не понятен. Я не против твоей концепции, просто мне она кажется слегка излишней на практике в подавляющем количестве случаев. Может я и ошибаюсь.


 
Leon1   (2005-01-28 12:17) [12]

Я как раз к этому и склоняюсь, тут как раз назревает вопрос о введении задним числом... это просто мрак получим
1
2
3
4
5
99
6
7
8
9

Как то явно не красиво получается а что делать... ничего...


 
Leon1   (2005-01-28 12:26) [13]

Вожможен еще вариант такой,
заводится отдельная таблица которая содержит
Уникальный идентификатор(Id),
номер документа(NumDoc),
дата документа(DateDoc),
время документа(TimeDoc),
далее таблица с шапкой документа там контрагенты договора прочая мерзлость, заводится еще одно поле грубо говоря Pid (Parent Id) этот самый Id связывается с Pid т.е. получаем что запись в шапочной таблице документа является дочерней для Таблицы с дребеденбью о номерах и т.п. в таблице с шапками документов на событие OnNewRecord вешаем что то вроде этого
With TQuery.Create(Self) do begin
DataBaseName:="CarsDataBase";
SQL.Add("SELECT MAX(Number)+1 AS MaxDocNumber FROM SRASPOR");
Open;
SRasporTable.Append;
SRasporTable.FieldByName("Number").AsInteger:=FieldByName("MaxDocNumber").AsInteger;
SRasporTable.FieldByName("DocTime").AsDateTime:=SysUtils.Time();
SRasporTable.FieldByName("DocDate").AsDateTime:=Date();
SRasporTable.Post;
Close;
Free;
End;

Тем самым гарантировано не произойдет колизии в момен записи документа номер будет занят на протяжении всего времени работы пользователя с документом а в случае отказа от создания документа можно просто удалить эту запись из таблицы... но это мое ИМХО....


 
Leon1   (2005-01-28 12:28) [14]

P.S. Кстати при такой схеме работы можно наполнять и табличную часть документа записями не запоминая при этом данные шапки!


 
Sergey13 ©   (2005-01-28 12:31) [15]

А какова первопричина твоей озабоченности? Дырки в нумерации? Неупорядоченность номеров при упорядочивании по дате? Так это вроде не регламентируется нигде и никем. Только "красивость" страдает.

Я бы забил на это.


 
Соловьев ©   (2005-01-28 12:31) [16]

2 Leon1   (28.01.05 12:26) [13]
Нарываюсь на msguns 8). Но!
Пока не поздно уйдите Вы от этой СУБД, перейдите на нормальную клиент/серверную - FireBird например(http://firebird.sourceforge.net , http://ibase.ru)
Избавите себя от кучи головной боли.


 
ЮЮ ©   (2005-01-28 12:33) [17]

>случае отказа от создания документа можно просто удалить эту запись из таблицы...

Последний был № 4
Первый пользователь взял № 5
Второй взял № 6
Второй сохранил
Первый отказался

№ 5 - пропушен

См.[4]
Первый пользователь взял № 5
Второй взял № 5
Второй сохранил
Первый отказался

Если и первый попытается сохранить, то получит предупреждение, что №5 уже существует и будет предложен №6.


 
Leon1   (2005-01-28 12:40) [18]

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


 
msguns ©   (2005-01-28 12:56) [19]

>Leon1   (28.01.05 12:26) [13]

Предусмотри текстовую часть. Дело в том, что возвраты часто "нумеруют" как <№ прихода>"Возврат" или подобное. Избавишь себя от траблов будущем. Послушайся совет стараго израненого ветерана ;)

>Sergey13 ©   (28.01.05 12:31) [15]

Дело говорит

>Соловьев ©   (28.01.05 12:31) [16]

Это я против "птички" !? Саня, ты не прав. Если разрабатывается новый проект или коренным образом перерабатывется старый, я - первый, кто за то, чтоб забыть про локалки (любые)

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

При отображении списка документов на клиенте очень рекомендую предусмотреть панельку для ввода узером доп.условий выборки, куда обязательно включить контрагента и период. И по умолчанию сортировать по дате-времени создания документа (часто они должны совпадать с временем фактического перемещения товара). Такая схема удовлетворяет 99% пользователей проги. А то, что №№ документов будут не подряд - не страшно абсолютно. Хотя бы потому, что если можно, оператор (бухгалтер) может его перенумеровать (например, для внутренних или приходов) или поменять дату.


 
Leon1   (2005-01-28 12:59) [20]

2 Соловьев да сейчас помоему дело не в самой СУБД а в практике реализации нумерации документов, факт есть факт что инкреметное поле не подойдет, а Paradox это или Interbase именно в данной задаче роли нет ни какой, причем мне известно дофига примеров НОРМАЛЬНОЙ работы с БД Paradox, и помоему Interbase или Paradox дело каждого я лично предпочитаю MSSQL но склонять и пропогандировать к переходу на него не буду и не хочу:-) так лирическое отступление ни кого не хотел обидеть если что


 
msguns ©   (2005-01-28 13:06) [21]

>Leon1   (28.01.05 12:40) [18]
>и тута новая проблема..... ох...

Проблема не "тута", а в отсутствии опыта. Но это дело временное ;))
Не надо путать две вещи: заголовок документа (Гл.таблица) и фактура, отнесенные платежи и т.д., т.е. подчиненные таблицы. При добавлении в таблицу нового заголовка (создание нового документа) запись постится сразу. И только потом узер вводит фактуру. При этом новый № уже есть в БД и другой узер на другом компе получит свой автономер уже с учетом первого. Вероятность одновременного ввода новой заголовка отгрузки двумя узерами достаточно мала, но если такое даже случится, оба это увидят еще ДО печати документа и смогут исправить его (№). Проблема дубликатов, ИМХО, высосана из пальца и решается морями способов, в т.ч. с помощью упомянутой литерной части.

Советую обратить особое внимание на другие вещи: актуальность остатков и транзакционность (т.е.целостность пакета изменений в БД и т.д.). Здесь ожидаются куда более сурьезные траблы, особенно с учетом кривизны локалок, где парадокс чуть ли не лидирует по глюкавости.


 
Соловьев ©   (2005-01-28 13:08) [22]

Да политику формирования номера надо конечно решать на организационном уровне, но взявшись за дело, ты сразу почему-то уперся в кокретные проблемы Парадокса. а не организационные, в первом посте ты их описал.

Предпочитаю MS SQL и я, но на него деньги нужны и не малые. А FireBird бесплатен.


 
msguns ©   (2005-01-28 13:09) [23]

Ни в коем случае не инкремент для номера !!! Ни в коем случае ! Буквально через неделю эксплуатации проги операторы будут плеваться на такой автономер. Я уж молчу о сбросе нумерации с 1-го января и раздельной номурации для каждого типа документов при том, что заголовки их могут лежать в одной таблице.


 
Соловьев ©   (2005-01-28 13:10) [24]

msguns ©
Вам надо за посты памятник ставить, так много писать(и главное по делу) это надо уметь! 8)


 
Leon1   (2005-01-28 14:00) [25]

2 Соловьев MSSQL за баксы MSDE халява! :-) Поясню, поскольку в Delphi я человек не такой уж и опытный, то избрал для начала Paradox просто посмотреть что да как и вообще что кчему как работает и т.п. я конечно понимаю что есть масса компонент типа FibPLUS которые значительно способствуют у программиста развитие желания и интереса работать над самим программным продуктом а не ловить грабли на тему типа а почему IBTable такой плохой или а почему IBQuery не то.. то.. то.. Именно основное дело заключается в том, что отсутсвует нужная информация или за частую ее просто тяжело выловить в просторах сети или на книжных прилавках, подумайте, чему учат в институтах и в мудреных толстых томах, я лично имею немалый набор книг по Delphi но насколько помню в институте нас учили использовать BDE и Paradox а о сложных фомах мы и знать не знали... показывали общие примеры типа TDataBase TTable TQuery TDbGrid TDBNavigator все... за сим откланились взяли курсовые и бай бай... ни в одной книге я не видел описаний методик реализации механизма рассчета остатков... или механизма подбора по товарной номенклатуре все как то приведено в общем для небольшого количества и естественно литература не дает исчерпывающие ответы на вопросы, после чего возникают мучительные думки... блин а как этот механизм покажет себя на пактике... я сам в основном около 3 лет занимался конфигурированем 1С и как бы и подзабыл уже некоторые аспекты разработки ПО в таких системах как Delphi.... исключительно мое мнение... о данному вопросу... на рынке отсутсвуют просто методические пособия по написанию сложных ERP систем....


 
msguns ©   (2005-01-28 14:04) [26]

Крик души ?


 
Соловьев ©   (2005-01-28 14:05) [27]

у каждой халявы есть ограничения 8) у MSDE - 5 коннектов.


 
Соловьев ©   (2005-01-28 14:07) [28]

> по написанию сложных ERP систем....
о Парадоксе я тут промолчу ... :)


 
Leon1   (2005-01-28 14:22) [29]

По поводу таблиц посню явно, главная таблица реквизитов, есть таблица со строками документов грубо говоря по механизму
Master->Detail в основной есть Id в другой есть Pid поле, Id является сурогатным ключем следовательно для вставки данных в Detail таблицу нужно
а) чтобы запись с Pid = Id находилась в БД
б) нужно знать этот самый Id чтобы присвоить его Pid
Для любой субд (и это факт) до физического попадания Записи в Master таблицу предугадать какой Id пудет не возможно, если это конечно не однопользоватльская программа
т.е. получается пока шапка документа не записана то речи о вставке стро быть не может, т.е. сначала сохрани шапку а потом вбивай строчки

В случае если в дело вступает 3 таблица то получим следующее:
1) Таблица содержит(ID,NumDoc,DateDoc,TimeDoc);
2) Таблица содержит(IDDOC,KONTR,DOGOVOR, и т.п.);
3) Таблица содержит(PID,TOVAR,RASHOD);
При создании документа вставляем запись в 1 получаем что вставка для 2 и что самое важное для 3 производится до записи документа... пользователем в случае отмены все просто банально удаляется... вот суть идеи


 
Leon1   (2005-01-28 14:24) [30]

Можно расценить как крик души, а что разве с помошью Paradox нельзя создать путевую трехзвенку?  ;-)


 
Leon1   (2005-01-28 14:29) [31]

Я не упорствую на счет парадокса, поймите меня правильно... я если честно сма склонен к использованию Interbase или еще чего - то из Линейки SQL серверов...


 
Anatoly Podgoretsky ©   (2005-01-28 14:40) [32]

Соловьев ©   (28.01.05 13:08) [22]
Предпочитаю MS SQL и я, но на него деньги нужны и не малые. А FireBird бесплатен.

Заблуждение MS SQL тоже бесплатен, но только сооветстующая облегченная версия, называется MSDE

Leon1   (28.01.05 14:22) [29]
1) Таблица содержит(ID,NumDoc,DateDoc,TimeDoc); -> (ID,NumDoc,DateTimeDoc);


 
Leon1   (2005-01-28 14:43) [33]

Мне например удобнее DateDoc,TimeDoc, может я конечно и заблуждаюсь но если использовать DateTime то каким образом можно отгруппировать документы в итоге по дням? здается мне что полсе GROUP BY (DateRimeDoc) я получу отдельной строчкой кажный документ...???


 
Sergey13 ©   (2005-01-28 14:44) [34]

2[29] Leon1   (28.01.05 14:22)
>Для любой субд (и это факт) до физического попадания Записи в Master таблицу предугадать какой Id пудет не возможно, если это конечно не однопользоватльская программа

Это самое большое твое заблуждение.


 
Leon1   (2005-01-28 15:03) [35]

Ну положем есть в FibPlus штуевина которая может определить для InterBase значение генератора, но тем неменее когда Master запись отсутствует все равно нельзя вставлять запись в Detail таблицу с отсутсвующим Id из Master...


 
msguns ©   (2005-01-28 15:20) [36]

>Leon1   (28.01.05 15:03)

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

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

С уважением и пожеланием успехов в совсем нелегком деле проектирования Баз Данных.


 
Leon1   (2005-01-28 15:36) [37]

Мы по всей видимости гом о разных вещах, не составляет проблем сделать нумерацию, не составляет труда написать софт, и модель данных давно есть, вся база данных на лицо, и про реляционные теории мне говорить не нужно, вопрос стоял ели еще кто то понминт есть ли еще способы реализовать мехнаизм нумерации? вместо этого беспочвенные оскорбления и т.п. Просто негде подчерпнуть информацию о том как это реализуется на практике от того и неуверенность прав ли я или нет.... нормализация избыточность целостность..... транзакции... 1НФ 2НФ 3НФ 4НФ.... все это теория... у нормального программиста нормализация БД должна быть автоматически заложена... ай у меня температура 39 меня плющит...


 
Digitman ©   (2005-01-28 16:04) [38]


> вопрос стоял ели еще кто то понминт есть ли еще способы
> реализовать мехнаизм нумерации?


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

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


 
msguns ©   (2005-01-28 16:38) [39]

>Leon1   (28.01.05 15:36) [37]
>вместо этого беспочвенные оскорбления

Давайте разберемся.
1. По поводу оскорблений. Видимо, основанием для такого "тяжелого" аргумента послужило мое вот это:
У Вас, простите, каша в голове

Это Вы считаете оскорблением ?

Во-первых, видимо, Вас никто никогда не оскорблял.
Во-вторых, если заменить это на слово "неразбериха", Вам станет легче ? Если да, то я не против, давайте заменим. Более нигде, сколько не читал свои посты, не заметил даже намека на оскорбление. Более того, пытался с максимальной вежливостью и ясностью Вам помочь. Причем, вполне искренне.

2. Что касается "почвенности", то о каше я сказал после Ваших [14], [18], [20], [25], [29-31], [33] и (особенно !) [35]
Попробуйте непредвзято прочитать эти свои посты и оценить сам себя. Определенно складывается впечатление, что человек нахватался терминов и кое-каких отрывочных знаний об этих терминах, но четкой картины и, главное, понимания концепции построения БД, у него нет: трехзвенки, ERP, "колизии", "Линейки серверов" - все нарублено в одну кастрюлю, как венегрет.
Это не значит, что чел безграмотный. Вполне возможно, что он спец в программировании, но в другой области., например, в 1С.  
Кроме того, на лицо явно недостаточное знание объекта автоматизации, т.е. торговли, а также делопроизводства и бухгалтерии. О чем Вам, кстати, многие тут намекали. Причем в достаточно вежливой форме.

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

И еще напоследок: перечитайте еще раз Правила Форума. Там четко сказано, что здесь никто никому ничем не обязан. В следующий раз, прежде чем оскорбиться и, не разбирая клавиш, строчить "ответку", вспомните это золотое правило. Глядишь, и температура не будет повышаться.


 
Petr V. Abramov ©   (2005-01-28 18:47) [40]

Если нужна нумерация уникальная и "без дырок" - без пропуска номеров, тогда
 заводим табличку из одной записи с одним полем last_num,
update ... set last_num = last_num + 1, читаем и сразу commit
 Другого способа нет, или "дырки" будут, или потенциальное нарушение уникальности



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

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

Наверх




Память: 0.59 MB
Время: 0.034 c
3-1107117217
Intelect
2005-01-30 23:33
2005.02.27
КАК DELPHI взаймодействует с MSSQL у вас нет примера!


1-1107936598
Suvit_
2005-02-09 11:09
2005.02.27
Выравнивание ширины текста в RichEdit


9-1101119796
mefisto
2004-11-22 13:36
2005.02.27
Карта 2000 x 2000 с помощью DelphiX


10-1084008974
ivs
2004-05-08 13:36
2005.02.27
Передача массива данных


3-1107163259
Bless
2005-01-31 12:20
2005.02.27
Проблемка с кодом возврата хранимой процедуры в Delphi





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