Идеи

В момента тази статия или раздел е в процес на изграждане или съществено преработване.

Моля, не я редактирайте, докато този шаблон не бъде премахнат! Прегледайте историята на статията, ако искате да видите кой е поставил този шаблон, за да се свържете с него. Ако прецените, че е изминало много време, през което няма промени по статията или раздела, за която се отнася, моля премахнете шаблона!

Задължително посочване на имейл

Идеята в едно изречение

Трябва задължително всеки потребител да си е посочил e-mail за връзка.

Пълно описание

Тази идея има отношение, както към раздел „Връзка с екипа“, така и към това, че комуникацията между потребителите ще се улесни значително.

Необходими умения за реализацията й

Достъп до административната част на сайта, както и придобиване уменията на Борислав. :)

Приоритет: 1

Причини: Изпуснати потенциални помощници и зависване на записи в ателието заради неосъществена комуникация с потребителите.

Забележки

Не е сигурно, че при въвеждането на тази възможност ще има 100% осъществена комуникация, но е крайно време да бъде въведена.

Коментар: Предлагам следната корекция: „Всеки потребител, който използва страницата „Връзка с екипа“ или желае да се включи в обработката на текстовете, трябва да е посочил валиден имейл за връзка.“ Излишно е да се задължава всеки потребител да регистрира имейл; в крайна сметка базата ще се напълни с [email protected], което на практика ще е същото. Според мен не е необходим достъп до административната част на сайта, просто трябва да се модифицират съответните модули. — Mandor 12:42, 11 април 2011 (EEST)

Коментар (2): Подкрепям вариантът на Борислав за напомнящо съобщение при липса на имейл в страницата „Връзка с екипа“. Между другото, смятам за много полезно, че „Връзка с екипа“ е достъпна и за нерегистрирани потребители. — Mandor 12:55, 11 април 2011 (EEST)

Отписване на потребители от ателието

Идеята в едно изречение

Премахване на записани потребители в ателието от някой запис на произведение.

Пълно описание

Включвайки се потребител, който частично е направил обработка на качените изображения в ателието и заявявайки, че текстът е готов за добавяне в библиотеката, е недопустимо. По този начин друг доброволец има възможност да се подлъже и да започне обработката на частично разпознатия текст вместо да разпознае изображенията. Това ще е голяма загуба на време за всички. Идеята ми е да има възможност от няколко потребителя с повече права да премахват файла и въобще псевдонима на потребителя от записа в ателието, така че пак записа да се върне в изходно положение (напр. „Очакват се коректори“).

Необходими умения за реализацията й

Да си програмист разбиращ php и бази от данни. :)

Приоритет: 5

Причини: Подобряване на работния процес в ателието.

Забележки

Преди изтриването на потребителя, от дадения запис, е задължително да се осъществи комуникация с него.

Коментар: Струва ми се излишно. 1. Наистина е недопустимо текстът да се маркира като очакващ проверка, но е напълно възможно някой потребител да разпознае текста и да направи начална корекция (като vens), а друг да извърши същинската, пълна корекция. Изображенията така или иначе ще останат (от първия потребител). 2. Хората, които ще вземат решение дали текстът е достатъчно готов, така или иначе имат право да променят статуса на записа в ателието. Освен това такива случаи са сравнително редки и ще е по-практично да обезпокоим Борислав за 10 мин веднъж на месец, отколкото да се добавя такава функция. Да не говорим, че така се отваря възможност за бъдещи проблеми. — Mandor 12:50, 11 април 2011 (EEST)

„Олекотяване“ на SFB

Идеята в едно изречение

Премахване на излишни маркери от SFB-парсера.

Пълно описание

Да се премахнат следните маркери:

• S (знак) — в блоковия и едноредовия му вариант. Вместо него да се използва например

M> frame

• L (писмо). Вместо него да се използва само цитат (C).

Необходими умения за реализацията й

Уеб-програмиране (PHP)

Приоритет

2 (за да не е 1)

Промяна вътрешния формат на текстовете

Идеята в едно изречение

Замяна на сегашното представяне на текстовете (SFB) с XML.

Пълно описание

В момента текстовете в Читанка се съхраняват във формат SFB. Това налага средно сложен анализ на файла, преди да се конвертира към някой от крайните формати (TXT, FB2, ePub), като този анализ се извършва винаги, когато исканият краен формат не съществува в кеша на сайта. Предложението е текстовете да се съхраняват в XML-блокове; дори не е необходимо да е пълноценен XML-файл. Това дава следните предимства:

• Еднократен (сложен) анализ на изходния SFB-файл;
• Възможност за (почти) директно конвертиране на вътрешния XML файл в някой от изходните формати, например чрез XSLT.
• Възможност за усложняване на SFB-парсера по такъв начин, че да улавя повече невалидни конструкции; в момента това е непрактично.

При тази организация на текстовете SFB-форматът ще се превърне в още един от изходните формати за конвертиране, който е интересен само за коректорите.

Необходими умения за реализацията й

Уеб-програмиране (PHP, MySQL); познаване на модулите за конвертиране.

Приоритет

(направо не искам да предполагам :-)

Забележки

• „Пакетните“ файлове, които описват книгите и сборните издания, също ще се представят чрез XML.

Добавяне на метаданни към SFB-формата

Идеята в едно изречение

Добавяне на пълен набор от метаданни за произведението/книгата в реализацията на SFB-формата.

Пълно описание

В началото всички метаданни бяха добавяни „на ръка“ при качването на текста в сайта. В последствие функционалността на информационния блок се разшири така, че да обхваща базовите метаданни (предположение: които в момента се поддържат от базата данни) — оригинално заглавие, поредица, номер, преводач и т.н., — реализирани чрез двойка „променлива“=„стойност“. Предложението е наборът от метаданни да се разшири до по-пълноценно множество (за основа може да се използва FB2-спецификацията и да се допълнят евентуалните липси), което да се добавя в началото на SFB-файла, или да се използва отделен файл (FBI: Fiction Book Info — информация за художествена книга). За представянето отново може да се използват двойки „променлива“=„стойност“, но е желателно имената да са на кирилица и да са групирани по предназначение („Информация за произведението“, „Информация за изданието“ и т.н. — по аналогия с FBS-формата). Този набор ще се записва в базата данни и ще помага за генериране на по-пълноценни изходни файлове, както и при евентуално разширяване на функционалността на сайта.

Необходими умения за реализацията й

Уеб-програмиране (PHP, MySQL); познаване на модулите за конвертиране.

Приоритет

?