Питання по інструментарію — система синхронізації структур даних (в XML? в JSON? ще якось?)

Вихідна задача — розробити багатомовний веб-інтерфейс.

Так мені то виглядає, що можна взяти набір XML (або JSON, або щось типу) структур даних, які описують всі елементи інтерфейсу і зґенерити з них необхідні шаблони (така задача сама по собі за рамками сформульованого тут питання — це для мене не є для проблемою).

Для перекладу на другу мову — досить перекласти текстові елементи в вихідній структурі даних — все просто.

Але при внесенні правок — упс! — треба автоматом фіксувати відмінності — як між структурами даних на різних мовах, так і між версіями даних в файлі деякої мови; а далі — оновлювати файл «другої» мови.

В ідеалі, по-моєму, рішення мало би бути симетричним — щоб вносити правки в довільний з «мовних» файлів, а потім просто проходити по diff’ах і фіксити відповідні місця в решті.

Чи може хто парадити якусь «малу механізацію» для такої задачі?

Наче й написати таке не дуже довго — але невже нема стандартних рішень?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Привет. Занимался подобными решениями. Оставь свое мыло и какой еще контакт, как с тобой связаться.

gpb — це, як я зрозумів, щось типу JSON. Мені ж ідеться не про ввід-вивід, але про порівняння структур і подальший пост апдейтів до них.

Зрештою, код того виявився нескладним — порівняння я вже собі написав, апдейти — зроблю десь-якось на днях. Наскільки доречно було би анонсувати такий інструментик в цьому форумі?

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

В принципі, можливе для мене рішення, спасибі.

Але і тріґґер, і подальші процедури оновлення даних — теж треба писати самому (так само як і синхронізацію для текстових файлів). Але остання, все ж, це рішення більш універсальне, яке може придатись і для инших задач. Тому наразі більше схиляюсь до синхронізації XML/JSON.

Если это все рассматривать через амбразуру MS SQL 2005 — то триггер если сделать на SQL-CLR — он сам сможет делать XML и JSON текстовые файлы, по мере своего срабатывания. Ну или отдельная SQL-CLR хранимая процедура, которая по таблице эти файлы построит.

Так... Тільки я поки що сиджу в иншому доті :-)

Ну тогда, если вариант с триггером, и без «тяжелой артилерии» — поставьте себе СУБД sqlite3 (sqlite.org), повесьте триггер, а из командного файла пошлите sqlite процессору команду, типа:

.output testfile.txt

select * from datatable;

Если подключить REXX интерпретатор — вы вывод сможете даже в JSON сформатировать

Вот Вам сразу готовый вариант перегона из sqlite в CSV (не менее мощная структура, чем XML и JSON): forums.mysql.com/...145,71867,92624

Ясно, спасибі. Зрештою, питання не у виборі тріґґерного інструментарію — я вже бачу, як це зробити в тексті і, думаю, через вихідні викладу-покажу результат.

Вдогонку: www.sqlite.org/sqlite.html — тут найдете команды синхронизации с текстовым файлом:
.import FILE TABLE Import data from FILE into TABLE
.output FILENAME Send output to FILENAME
.mode MODE ?TABLE? Set output mode where MODE is one of:
csv Comma-separated values
column Left-aligned columns. (See .width)
html HTML <table> code
insert SQL insert statements for TABLE
line One value per line
list Values delimited by .separator string
tabs Tab-separated values

tcl TCL list elements

А sqlite — простая, как бревно, и миниатюрная, СУБД. Она даже ставится на embedded системах. Даже в Андроид впихнули.

Питання трохи в сторону. Для задач, які би я назвав «nosql» — швидко вибрати/вставити рядок даних, без всяких там вкладених запитів чи пов’язаних таблиць — чи sqlite добрий? достатньо шустрий? надійний на великих масивах даних? чи, все ж, варто шукати-ставити те, що звуть"nosql-сервером"?

Да, он очень шустрый, надежный, открытый, лимит базы — 2 терабайта, с его командным процессором можно работать из командной строки операционной системы. Почитайте о нем на его сайте по ссылке, что я дал

www.sqlite.org/whentouse.html

У меня первейшая с ним проблема — конкурентный доступ (блокируется вся база). А так, все круто, быстро и просто. =)

Конкурентний доступ — маєте на увазі, під час того, як відкрита транзакція? А версія SQLLite?

В текущий момент времени можно только либо читать (всем), либо только писать (одному)

Да. Если кто-то читает, то никто писать не может. Это не зависит от версии. Архитектура у нее такая. Лочит не таблицы, а всю базу (вся база — один файл).

Обычно это не проблема (или не очень большая проблема), но знать об этом заранее надо.

Ага... Зато в FIDO нодах, все скрипты голого деда писались на нем :)

В то время, такого слова даже не было :)

www.microsofttranslator.com
API и его виджеты
translate.google.com

API (только от с 1 декабря обещают deprecated) и его виджеты

Ще й Вам відповім — я не питаю про спосіб перекладу чи інтернаціоналізації. Я питаю про спосіб синхронізації довільних структур даних — не більше, але й не менше. Рівно про це :-)

Погляньте на gettext для обраної мови програмування. Наприклад, для Django документація виглядає так: docs.djangoproject.com/...ationalization

Та ні, gettext() тут не при ділах. Мені йдеться виключно про синхронізацію структур даних (інтернаціоналізація — вихідна задача, але я про неї саму зовсім нічого тут не запитую).

Тоді починайте із чогось простого, як двері, покривайте тестами та покращуйте швидкодію. Почати можна із такого:

[
{
"en": {
"text": "Hello",
"revision": 0
}
"ua": {
"text": "Привіт",
"revision": 0
}
}
]


[
{
"en": {
"text": "hello",
"revision": 1
}
"ua": {
"text": "Привіт",
"revision": 0
}
}
]


[
{
"en": {
"text": "hello",
"revision": 1
}
"ua": {
"text": "привіт",
"revision": 1
}
}
]


[
{
"en": {
"text": "hello",
"revision": 1
}
"ua": {
"text": "доброго дня",
"revision": 2
}
}
]


[
{
"en": {
"text": "good afternoon",
"revision": 2
}
"ua": {
"text": "доброго дня",
"revision": 2
}
}
]

По ходу п’єси зробите свій git із блек-джеком та іншими прибамбасами.

От, власне. Тільки вважаю за потрібне різномовні дані писати в різних файлах (бо якщо втулити всі мови в один файл — не буде зручно мати з ним справу) — і налагодити синхронізацію між ними. Відтак і постало питання синхронізації структур даних — і я це питання тут і запитую.

Такий файл (особливо якщо обраним форматом виявиться XML) людина в очі бачити не має, тим більше, що людина може зробити його неузгодженим при неправильному використанні. Оператор повинен працювати зі зручним інтерфейсом, який нескладно буде потім дописати і який допускає лише коректні операції, які переводять таку документальну базу даних із одного несуперечливого стану до іншого.

Оператор то повинен :-) А от як саме досягнути узгоджености і несуперечливости — про це й допитуюсь, чи хто знає подробиці.

Every time you edit XML file by hand... God kills a kitten.

Даруйте, але я, все ж, запитую не про інструменти інтернаціоналізації, як такої, але виключно про інструменти синхронізації структур даних.

Так, я хочу мати власне рішення щодо інтернаціоналізації. Розумію, що це, впевному сенсі, «відкривання америки», але складність такого рішення для мене — виключно в питанні синхронізації даних, весь же подальший ланцюжок від даних до самого сайту, можна сказати, наявний. Тому загальні i18n-рішення — ага-ага — але, якщо конкретно, то й не знаю, яким боком їх застосувати :-)

Крім того універсальні утиліти синхронізації даних можуть придатись і в иншому контексті — то чому б не мати їх під рукою?

Тому й питаю, що задача цікава, може мати кучерявості. За ланки спасибі — шкода, але не вмію так само майстерно гуглити «непрямі питання» :-(

Підписатись на коментарі