Обсуждение модуля:Отексте

Подключение подмодулей

@Lozman как можно подключить подмодуль, например Модуль:Отексте/ТСД3. Ссылку на него где-указывать, или достаточно просто создать страницу и он сам подхватывается? --Vladis13 (обсуждение) 01:03, 16 августа 2017 (UTC)

В шаблоне заголовка через {{#invoke:Отексте|textinfo|dict=ТСД3}} (если название подмодуля совпадает с префиксом названий статей, можно указывать dict=generic, если нет — нужно указывать буквально). В принципе, этого должно быть достаточно в большинстве случаев. — Lozman (talk) 01:22, 16 августа 2017 (UTC)

Спасибо, заработало. --Vladis13 (обсуждение) 11:20, 16 августа 2017 (UTC)

Категории "Ручная ссылка"

@Lozman посмотрите пожалуйста. В ТСД3/Федосевна ставятся категории "ТСД3:Статьи со ссылками на Википедию" и "Викитека:Ручная ссылка:ТСД2" и "Викитека:Ручная ссылка:Википедия". Вроде многовато, и не то издание. Используется Модуль:Отексте/ТСД3.

А ещё ошибка когда пытаюсь убрать из модуля ненужные строки для других изданий (1 и 2) из массивов p.indexpat и p.scanpat. --Vladis13 (обсуждение) 04:26, 29 августа 2017 (UTC)

Категории с префиксом "Викитека:" добавляются через Модуль:Другие источники. "ТСД2" в данном случае означает, что из этой статьи есть ручная ссылка на статью в ТСД2, так что там все правильно. Ссылочные категории с префиксами по словарям ввел в употребление Участник:Henry Merrivale, я только перенес их в модуль. Да, они частично дублируют ссылки первого типа, но только частично, поэтому какой-то смысл в них есть (категории с "Викитека:" могут включать статьи из разных словарей, и не только из словарей). По второму вопросу — можете уточнить, какая ошибка? В сохраненных версиях модуля нет ни одной с такими изменениями. Или редактор не позволяет сохранить страницу? Тогда это может быть синтаксическая ошибка, он проверяет синтаксис перед сохранением. — Lozman (talk) 15:58, 29 августа 2017 (UTC)

По категориям понял.

Вот убираю лишние строки для других изданий. Теперь статья поломана: ТСД3/Федосевна. --Vladis13 (обсуждение) 16:55, 29 августа 2017 (UTC)

Нужно поменять цифирки в параметре scan в списке томов (с 3 на 1). А то функция ищет третий элемент в списке, где есть всего один. — Lozman (talk) 17:34, 29 августа 2017 (UTC)

Не видится словник

Шапки не видят словников. Например в ТСД3/Юнона (ТСД-словник/3/Ю), и аналогично по другим буквам: «Э, Ю, Я». Хотя работает по буквам «Ъ, Ы, Ь» и «Ф» (ТСД3/Фазан, ТСД-словник/3/Ф). Модуль:Отексте/ТСД3. Что за магия? --Vladis13 (обсуждение) 04:55, 31 августа 2017 (UTC)

• Причина была в указании словников которых нет, в списке listnum. Из-за этого все последующие словники списка не обрабатывались. --Vladis13 (обсуждение) 08:24, 31 августа 2017 (UTC)
  • Причина в том, как в Lua сортируются строки в Юникод. Сортировка идет не в алфавитной последовательности, а в соответствии с кодами символов. Т. е. порядок сортировки примерно такой: ЁЄЅІЇ(А—Я)(а—я)ёєѕіїѠѡѢѣѤѥѦѧѨѩѪѫѬѭѮѯѰѱѲѳѴѵѸѹѺѻѾѿ. Если определитель выстроен не в этом порядке, некоторые секции могут не обнаруживаться. — Lozman (talk) 12:39, 31 августа 2017 (UTC)
  • P.S. Насчет Ё я, впрочем, не уверен, возможно, она интерпретируется как вариант Е. Но применение table.sort() к алфавиту дало такой результат, как я показал выше. — Lozman (talk) 12:42, 31 августа 2017 (UTC)

Ошибка

В статьях словника ТСД-словник/2/І,Ѵ с СО-названиями на букву «И», например ТСД2/Иокать. Если не ошибаюсь, проблема в расчёте номера тома в массиве wl2volume в Модуль:Отексте/ТСД2. Там для букв «И» и «І,Ѵ» указаны разные тома, но название страницы одно. Как бы разрулить? --Vladis13 (обсуждение) 11:53, 2 сентября 2017 (UTC)

В wl2volume был нарушен алфавитный порядок секций, потому не работал определитель. Исправил. А словник нужно выпрямлять, это не дело, когда статьи из разных томов в одной секции. Вообще идея с «буквенными» секциями мне представляется не очень удачной. Я бы предпочел, как в других словнарях, делить на секции более-менее одного размера с нарезкой по границам букв (где возможно), но без обязательного соответствия «1 секция — 1 буква». Некоторые секции выходят неоправданно мелкими, а число секций — неоправданно большим. Опять же, числовые названия секций удобнее в использовании и дают меньшую вероятность ошибок. — Lozman (talk) 21:26, 2 сентября 2017 (UTC)

Спасибо! Словник разделил. Просто в том формате это технически не мешало, а по восприятию было чуть проще — вариации одной современной буквы «И».

Границы имхо лучше оставить по буквам. Выигрыш в числе секций будет минимальный. Но для читателей будет проблематично: например чтобы найти какое-то слово на буквы «Ра», надо искать посреди словника на буквы «П», «Б» искать в «А»… а если они ещё и называются номерами… Другая проблема с нумерованными названиями секций, что при разделении словника посредине нумерации (например словники 3-4-5, разделить 4), придётся переименовывать все (половину 4 в 5, 5 в 6, 6 в 7, и тд.). Из-за этой проблемы ещё в старом языке программирования BASIC, где нумеровались строки, их нумеровали с шагом 10, чтобы было место куда вставить новые строки; а в 90-х годах отказались от нумерации строк. И в базах данных (в которой хранятся викистраницы на сервере) у каждой страницы есть два свойства — порядковый номер и название — номер для компьютера, название для людей.

В ТСД словники ещё могут разделяться, сейчас там по 1000—1500 слов, возможно это много. Когда обсуждали их размер, сошлись на этом размере, ибо на большем были заметны тормоза прогрузки страниц. Но тогда использовался шаблон:Отексте, сейчас тормозов быть не должно, может так и оставить. --Vladis13 (обсуждение) 12:22, 3 сентября 2017 (UTC)

Думаю, число словников вполне реально было бы сократить и раз в два. Что до буквенных обозначений: мне кажется, поиск чаще начинается с оглавления словника, в котором указываются именно заголовки секций, поэтому для поиска не так важно, как эти секции названы. А для возможности переразбивки словников «на ходу» я придумал параметр splitvolume, который действует так: для каждого тома заводится одна секция с таким же номером (например, для тома 4 — секция 4); если статей оказывается слишком много для одной секции, от нее отделяется секция с прибавлением суффикса «-1» (т.е. секция 4-1); далее 4-2, и так сколько понадобится. Этот способ опробован на словниках к доп. томам ЭСБЕ (Энциклопедический словарь Брокгауза и Ефрона/Словник/83, Энциклопедический словарь Брокгауза и Ефрона/Словник/83-1 и т.д.). Каждая переразбивка затрагивает только секции в пределах тома, а если вести заполнение последовательно от начала тома, то по заполнению очередной секции, от нее просто отделяется следующая, и все. Так что у нас методы не хуже, чем в Бейсике. По размерам секций: я не знаю, какие лимиты налагает шаблон {{Статья в словнике ТСД}}, но использование {{Статья в словнике}} после перевода его на Модуль:Article позволяет без особых тормозов работать со словниками и по 2—2,5 тысячи статей (проблемы начинаются в районе 3 тысяч, почему пришлось делить словники доп. томов ЭСБЕ). Впрочем, я излагаю, как было бы удобнее работать со словниками ТСД мне; но поскольку я с ними не работаю, то ничего не буду навязывать. — Lozman (talk) 18:45, 3 сентября 2017 (UTC)

Загрузка статей из индекса

Есть ли возможность указать название секции, загружаемой из индекса, через параметр шапки в статье? Если оно отличается от названия страницы. --Vladis13 (обсуждение) 19:30, 2 сентября 2017 (UTC)

Да, есть параметр СЕКЦИЯ, который транслируется в data.p.section в модуле. — Lozman (talk) 20:25, 2 сентября 2017 (UTC)

Замечательно, то что надо! Ещё вижу параметры РЕДАКЦИИ и СТРАНИЦЫ, как их использовать? --Vladis13 (обсуждение) 11:02, 3 сентября 2017 (UTC)

Прараметр СТРАНИЦЫ предназначен только для статей ЭСБЕ. Там исторически сложилось так, что в редакции ДО текст статьи по умолчанию загружается из пространства Страница, а в СО — нет. Соответственно, параметр СТРАНИЦЫ переключает эту логику: включает в СО (с любым значением или даже пустой) и отключает в ДО (со значением "нет"). В некоторых других словарях этот параметр раньше использовался для прямого указания номеров страниц в скане, но теперь все это вынесено в словники. Параметр РЕДАКЦИИ управляет отображением списка редакций: значение no/нет отключает полностью, а 0/short/кратко — форсирует краткий формат списка (для многостраничных редакций: ссылки с подстраниц даются только на корневые страницы других редакций, а на соответствующие подстраницы в других редакциях — не даются; предназначено для редакций, в которых разная структура подстраниц). Этот параметр предназначен для обычных текстов, не для словарных статей. — Lozman (talk) 17:51, 3 сентября 2017 (UTC)

Модуль:ТСД

Вряд ли будет использоваться. Можно удалить. Или оставить, как пример сложного варианта с объедин. ред. на одной странице. --Vladis13 (обсуждение) 02:16, 5 сентября 2017 (UTC)

Решил оставить именно как пример. Вообще-то, если бы вы обратили на это внимание раньше, можно было не создавать отдельные подмодули ТСД1-2-3, а переделать этот по типу split (наподобие Модуль:Отексте/БЭЮ). Но пусть уже будет так. Зато эти подмодули можно еще несколько упростить, преобразовав в тип mono (т.к. после разделения join уже излишен). Стоило бы как-то набросать справку по всему этому хозяйству, но не знаю, как скоро руки дойдут. — Lozman (talk) 16:50, 5 сентября 2017 (UTC)

Можно объединить. Можно упростить — если покажите как сделать не-join, скопирую его в другие модули ТСД. --Vladis13 (обсуждение) 05:25, 6 сентября 2017 (UTC)

Справка по модулям

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

Имеет смысл сделать одну документацию (через перенаправления) для всех подмодулей энциклопедий — параметры одинаковые. Для начала: пара предложений об общей концепции их работы и сборки, и пояснения параметров — варианты и значения. --Vladis13 (обсуждение) 05:26, 6 сентября 2017 (UTC)

Пагинация в шаблон:Статья в словнике

Не понимаю как правильно указать пагинацию в шаблоне. Например, ТСД2/Вода, в словнике указано {{tsds|Вода||221-226|2}}. Где параметр 3 — диапазон страниц. А 4 — номер тома статьи, которое одновременно включает для данного слова показ пагинации в словнике, с шаблоном {{Отексте}} этот параметр не мешал. С новым модулем обнаружил, что 4-й параметр как-то им используется и конфликтует. — В шапке ТСД2/Вода в поле «источник» ссылка ведёт не на страницу скана, а на эту цифру «2».
Я подумав, что диапазон теперь надо указывать не через дефис/тире, а раздельно в 3 и 4 параметрах пробую так: {{tsds|Вода||221|226|2}}. Для проверки как статьи будут загружаться из ПИ «Страница» включаю p.transclude = true в Модуль:Отексте/ТСД2 (в предпросмотре для этой статьи), но опять не работает.

Корректно ли будут обрабатываться диапазоны, если указаны колонки страниц скана. Например, ТСД3/Юностный.

Вообще, функция загрузки из ПИ «Страница» надёжна? Два года собираемся ТСД так подключить. --Vladis13 (обсуждение) 18:25, 8 сентября 2017 (UTC)

В шаблоне {{Статья в словнике}} 3-й параметр (а также 5-й и 7-й, если есть) — номера страниц/столбцов в печатном издании (hard), 4-й (также 6-й и 8-й) — номера страниц в скане (soft). Несколько одинаковых параметров — для сборки статьи из нескольких источников (см., например ЭСБЕ/Россия — единственный пока пример, где используются 7-й и 8-й параметры). Оба параметра (hard и soft) — составные, т.е. могут состоять из нескольких значений через слэш: для hard — страницы/пагинация/том (пагинация — для случаев, когда том имеет несколько пагинаций, пока не используется); для soft — значения from/to/exclude для передачи в <pages>. Соответственно, значение 2 в 4-м параметре — это 2-я страница скана. Если этот параметр пустой или отсутствует, но в подмодуле имеется параметр offsets для данного тома — номера soft вычисляются на основе соответствующих номеров hard. А включать/отключать показ номеров страниц в словнике (вы это имели в виду под указать пагинацию в шаблоне?) шаблон {{Статья в словнике}} не умеет, номера страниц отображаются всегда. Если нужно сделать их отключаемыми — думаю, для этого стоит завести отдельный (именованный) параметр. А p.transclude = true потому и не работает, что ищет не на той странице.

Если нумерация не по страницам, а по столбцам (и вообще во всех случаях, где на одну страницу скана приходится более одного номера — например, сканы в разворот), используется параметр factor (например, при 2 номерах на страницу во всех томах: p.factor = 2; можно также локально для каждого тома). Также может потребоваться коррекция первой страницы, если номера идут не в порядке 1-2,3-4,5-6… (здесь достаточно factor), а 1,2-3,4-5… — тогда используется еще параметр correction = 1 для исправления этого сдвига.

Функция с автозагрузкой из ПИ Страница сейчас включена в ПБЭ и ЭЛ, вроде работает без проблем. Впрочем, перед подключением других словарей нужно еще будет основательно потестировать; по крайней мере, настроить вывод как можно больше отладочной информации для отлова возможных ошибок. Но это реально сделать. — Lozman (talk) 14:00, 9 сентября 2017 (UTC)

Большое спасибо за подробности.

Опция «включать/отключать показ номеров страниц в словнике» используется в ТСД, напр. ТСД-словник/3/В. — Для показа пагинации только в началах страниц. Чтобы не загромождать дублями номеров страниц у каждой статьи (на страницах в среднем по 30 статей — получится столько же дублей номеров). Переделаю текущий 4-й параметр {{tsds}} в именованный, это лучше всего, спасибо за идею.

Т. е. если имеется диапазон страниц, надо обязательно использовать и 3-й параметр (для отображения его в шапке), и 4-й — для указания диапазона страниц скана «from/to»? А модуль не может сам распарсить диапазон вроде «5-20» как две цифры, для каждой добавить смещение, и считать как from/to? Иначе придётся ботом словники переделывать. --Vladis13 (обсуждение) 18:22, 9 сентября 2017 (UTC)

А модуль не может сам распарсить диапазон вроде «5-20» как две цифры — может, по крайней мере такой функционал в нем предусмотрен, если не работает, нужно искать ошибку и устранять. Но вроде должен работать. — Lozman (talk) 15:56, 11 сентября 2017 (UTC)

Поправил. Там сепаратором в диапазоне пагинации учитывался только «—», добавил дефис «-». --Vladis13 (обсуждение) 18:23, 12 сентября 2017 (UTC)

Логгирование ошибки трансклюзии

P.S. Пока не нашел, как проконтролировать, загружен ли текст из ПИ Страница или нет: вызов тэга <pages> заменяется strip marker'ом и пока модуль не завершит работу, содержимое этого маркера недоступно. А было бы здорово иметь возможность отследить результат загрузки для отлова ошибок, вручную просматривать все страницы как-то не хочется. — Lozman (talk) 14:32, 9 сентября 2017 (UTC)

Похоже не работает noText = "[[Категория:Отсутствует текст статьи]]". Вспомнил, мы же делали гаджет на JavaScript, который показывает сообщение, проверяя наличие на полях отрендеренной странице ссылки на скан. В html эта ссылка вставлена в текст в тэгах <span>. На страницах, где не загрузилась трансклюзия рядом с ней будет пустое место, или соседний тэг «span». Способ не 100 % надёжный, и потребует опять создания гаджета, который бы запускался синхронно после всех асинхронных (AJAX) скриптов. --Vladis13 (обсуждение) 04:36, 20 сентября 2017 (UTC)

Было бы здорово, если бы разработчики расширения Proofread (или LST?) сделали на этот случай добавление специальной отслеживающей категории наподобие тех, что в Служебная:TrackingCategories. — Lozman (talk) 19:58, 20 сентября 2017 (UTC)

pages onlysection

Ошибка при загрузке ТСД2/Вода из ПИ Страница (в предпросмотре модуля Модуль:Отексте/ТСД2 для этой статьи). Изменил строку в словнике на {{tsds|Вода | |221—226|311/316}}. Но вместо одной секции показывается всё подряд. Указал СЕКЦИЯ в шапки статьи, не помогло. --Vladis13 (обсуждение) 18:22, 9 сентября 2017 (UTC)

Кажется проблема в том, что в модуле используются параметры «fromsection» и «tosection» тэга <pages>. А в ТСД используется «onlysection». Поэтому модуль загружает всё подряд постороннее, что находится на страницах между секцией на первой странице и на последней. Может лучше изменить на «onlysection»? --Vladis13 (обсуждение) 22:06, 10 сентября 2017 (UTC)

Подходы с fromsection/tosection и с onlysection концептуально различны и просто заменить один на другой не получится. Они по-разному обрабатывают неразмеченные секциями страницы внутри диапазона: fromsection/tosection включает их целиком, а onlysection — игнорирует. Т.е. при замене fromsection/tosection на onlysection в большинстве многостраничных статей перестанут отображаться все страницы, кроме первой и последней. Вероятно, потребуется как-то совместить оба подхода (на уровне подмодулей): либо добавить значение параметра transclude (например, transclude = "onlysection"), либо завести отдельный параметр (onlysection = true). Как-то так. — Lozman (talk) 15:56, 11 сентября 2017 (UTC)

Давайте один такой параметр для всего подмодуля. Отдельный параметр для шаблона вряд ли нужен, сомнительно что будут применяться разные подходы для разных страниц одного издания. --Vladis13 (обсуждение) 18:06, 12 сентября 2017 (UTC)

@Lozman добавил в модуль параметр p.transclude_onlysection = true;. В статье ТСД проверил, работает. Накидал на скорую руку, если думаете, что лучше переименовать, сделайте пожалуйста. --Vladis13 (обсуждение) 18:14, 14 сентября 2017 (UTC)

На мой вкус название чуть длинновато, зато так понятнее, для чего он. Пусть остается. — Lozman (talk) 12:13, 15 сентября 2017 (UTC)

Поправил, поскольку сломалась трансклюзия в ЭСБЕ. Проблема была, что объявление переменной «local _text» не работало внутри условия if. Вынес его уровнем выше, работает, хотя там тоже предыдущий if. Нюансы языка Lua. --Vladis13 (обсуждение) 11:28, 15 сентября 2017 (UTC)

Да, есть такая хитрость: у if собственная область видимости. Соответственно, если переменная должна быть доступна вне if, то и объявлять ее нужно вне. В данном случае переменная _text вычисляется и передается в функцию addToPage в пределах «внешнего» if и дальше нигде не используется, поэтому такой код работает. — Lozman (talk) 12:11, 15 сентября 2017 (UTC)

Не видятся статьи словника

Для страниц ТСД2/Заедать и нескольких следующих не подгружаются данные, они под номерами 669—773 в ТСД-словник/2/Заст. Причём в пред. ТСД2/Защурупливать и послед. ТСД2/Заэвакать статьях ссылки на них есть в шапках. Другие статьи в словнике работают. Общее у этих пожалуй буква «ѣ», но она во 2-м параметре, с названием статьи в 1-м не связано. Все буквы названий в словнике и заголовках идентичны и русские. --Vladis13 (обсуждение) 02:04, 17 октября 2017 (UTC)

Зае ищется на З, а не на Заст. Добавьте Заст в определитель второй секцией. — Lozman (talk) 07:51, 17 октября 2017 (UTC)

Исправил. После очистки кэша данные подгружаются. — Lozman (talk) 10:20, 17 октября 2017 (UTC)

Спасибо! --Vladis13 (обсуждение) 13:36, 17 октября 2017 (UTC)

Категория:Страницы, не указанные в словнике

@Lozman Возможно ли добавить автокатегоризацию для страниц, имеющих шапку модуля, но чьи названия не найдены в словнике. (Это опечатки, упущения, и потенциальные программные глюки). Сейчас я такие для ТСД Категория:ТСД:Статьи не указанные в словниках добавляю вручную, что довольно сложно, и надо постоянно обновлять-переделывать. --Vladis13 (обсуждение) 16:39, 17 октября 2017 (UTC)

Нашёл Категория:Страница в оглавлении не найдена. Это оно и есть, или для какой-то другой ошибки? --Vladis13 (обсуждение) 16:44, 17 октября 2017 (UTC)

Для этой. Есть еще Категория:Оглавление не найдено — на тот случай, если страница обращается к несуществующему оглавлению. — Lozman (talk) 17:12, 17 октября 2017 (UTC)

Худож. произведения

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

-- Селектор секций
p.listnum = {}

Сортировка модулем по алфавиту этим параметром не подойдет.

В корпусе 91 том, в каждом заморочки со смещениями страниц скана относительно книги. Т.ч. модуль был бы к месту. В первых томах - на том несколько произведений, или глав. А вот во второй половине - множество мелких авторских произведений и фрагментов.

Там ещё есть проблемы:

• Слева в шапке ставит ссылку "Словник", которая для худож. произведений не к месту. Пример.
• Принудительно добавляются префиксы названия страниц (через шаблоны {{статья в словнике2}} или {{статья в словнике}} + Модуль:Article). Вроде как у ЭСБЕ "ЭСБЕ/НазваниеСтатьи", но префикс не нужен для повестей/романов с названиями вроде "Казаки (Толстой)".
• Модуль не видит оглавления (похоже из-за префикса), если указывать его в параметре ОГЛАВЛЕНИЕ, как для шаблона Отексте.
• Не понял как в модуле указать доп. пагинацию. В томах их две, арабскими и римскими цифрами.

Зависимости: Модуль:Отексте/Толстой, Шаблон:ТолстойПСС, Индекс:L. N. Tolstoy. All in 90 volumes. Volume 6.pdf, тестирую здесь: Казаки (Толстой,1936). --Vladis13 (обсуждение) 10:34, 24 февраля 2018 (UTC)

• Или это смысла не имеет? Просто использовать шаблон Отексте? --Vladis13 (обсуждение) 19:07, 24 февраля 2018 (UTC)

• Давайте обойдемся шаблоном Отексте. И тегами <pages index="" header=4 from= to= next= prev= /> для отдельных глав. Ratte (обсуждение) 19:21, 24 февраля 2018 (UTC)

Теоретически такое сделать можно. Практически — неясно, чего это будет стоить и во что в итоге выльется. Конкретные отличия работы со словарными статьями от обычных текстов и что с этим можно сделать:

• Из «авторских» параметров используется только НЕТ_АВТОРА; решается таким способом: p.noauthor = { [false] = "''автор: [[Лев Николаевич Толстой]]''" }, визуально не должно отличаться — легко;
• Выводится картинка с томами ЭСБЕ и ссылка на словник с текстом «Словник» — можно завести пару дополнительных переменных в модуле, которые будут это отключать (или заменять текст ссылки на другой, например, «Оглавление») — несложно;
• Кроме общей, добавляется также лишняя алфавитная категория — потребуется небольшая модификация модуля для возможности ее отключения — несложно;
• Префиксное именование словарных статей, которое нужно отключить (скорее всего, модификацией модуля Article) — не очень сложно;
• В качестве оглавления используется словник, который по определению должен быть отсортирован в алфавитном порядке. Неотсортированное оглавление, разбитое по томам, на роль словника подходит плохо, т.к. придется либо 1) забивать в p.listnum почти весь алфавитный указатель (более-менее реально, но размер такого списка я оценить не берусь), либо 2) завести небольшой список префиксов названий, но для каждого придется указывать длинный список альтернативных номеров секций (может сильно сказаться на производительности), либо 3) сделать одно сводное оглавление для всех томов, а конкретный том указывать в оглавлении в виде {{статья в словнике|Казаки (Толстой)||3—150//06}} (сегменты: страницы/пагинация/том; значение пагинация зарезервировано, но пока не используется) — сложно;
• Дополнительные пагинации пока не реализованы — сложно;
• Неясно, как поступать с текстами, которые занимают более одного тома;
• В словарных статьях поддерживается только небольшое подмножество параметров шаблона Отексте (никаких ДАТАСОЗДАНИЯ, ДАТАПУБЛИКАЦИИ, ИЗЦИКЛА, ИЗСБОРНИКА, ОГЛАВЛЕНИЕ и даже ДРУГОЕ — нет); как их включить — пока не знаю, за это отвечает переменная (флаг) isDict, которая также управляет выбором рабочей функции (getDataMain() для обычных страниц, getDataExt() для словарных статей). Соответственно, true — словарная статья + сокращенный набор параметров, false = обычный текст + полный набор; других вариантов нет. Нужно менять эту логику: либо вводить еще один флаг для раздельного управления этими двумя состояниями, либо как-то еще;
• может, еще что-то упустил.

И, по сути, единственный бонус на выходе — возможность автоматически вычислять номера страниц в сканах, вместо того чтобы прописывать их вручную? Не уверен, что оно того стоит. Но сделать можно, да. Но я бы лучше сделал {{ТолстойПСС}} обычной надстройкой над шаблоном Отексте (как это у нас часто делается для сборников) — возни меньше, а эффект ничуть не хуже. Но страницы, увы, придется прописывать вручную. — Lozman (talk) 21:59, 24 февраля 2018 (UTC)

• Да, слишком дорогая унификация. Сложностей появится больше, чем с шаблоном, даже если сделать все эти модификации. И сама эта унификация в сторону абстракции повредит области применимости модуля. К тому же, крайне мало представляется сборников худож. сочинений, где ещё это можно применить. Тогда отбой. --Vladis13 (обсуждение) 00:03, 25 февраля 2018 (UTC)

Можно удалить Модуль:Отексте/Толстой. --Vladis13 (обсуждение) 15:54, 23 марта 2018 (UTC)

 Сделано. — Lozman (talk) 21:28, 23 марта 2018 (UTC)

Шаблон:Статья в другом словнике

Непонятка со 2-м параметром. Мне кажется, раньше параметр делал ссылки на версии статей в ДО. Потом, с переходом на модуль, стал использоваться для указания первой статьи след. словника, т.ч. я переписал описание шаблона. А сейчас вроде не используется. Разъясните пожалуйста. --Vladis13 (обсуждение) 15:48, 23 марта 2018 (UTC)

Раньше делал, и сейчас делает: см. например, ссылку вперед в ст. ПБЭ/ДО/Архелая. Технически он работает так же, как все остальные шаблоны для словников: регэкспом все параметры вытаскиваются в строку, которая затем нарезается в таблицу с помощью mw.text.split по символу | ([1] — СО, [2] — ДО). Его отличие от {{Статья в словнике}} только в том. что он ничего не выводит на экран. — Lozman (talk) 21:50, 23 марта 2018 (UTC)

Понял, ДО показывается в шапке. А я понять не мог зачем ДО в шаблоне, если для названий статей, но они все в СО. Поправлю описание шаблона. --Vladis13 (обсуждение) 23:04, 23 марта 2018 (UTC)

Размещение текстов в ПИ Страница, и при этом ссылки в шапках на скан РГБ

@Lozman возможно ли так сделать? Поскольку хотелось бы сохранить ссылки на РГБ, где качество сканов РСКД замечательное, но страницы сдвоенные и неровные. А на ВТ сканы постраничные, было бы удобно вычитывать, но невозможно сделать и залить сканы в хорошем качестве (размер получается непомерный в 3.5 ГБ). Для этого также придётся делать таблицы с пагинацией для обоих сканов, поскольку у них разное число страниц на лист. --Vladis13 (обсуждение) 14:25, 16 октября 2018 (UTC)

Сложно. С одной стороны, такая возможность уже существует: для сканов в подмодулях используется переменная scanpat, для индексов — indexpat соответственно. В шапке используется первая, для страниц — вторая. Но раздельное указание номеров страниц (или вычисление по смещениям) никак не предусмотрено, и я пока не придумал, как это сделать. Скорее всего, придется вынести код, отвечающий за вычисление по смещениям, выносит в отдельную функцию и вызывать его дважды с разным набором параметров. Или завести в itemdata параллельно к soft.from еще одно значение (скажем, soft.scanpage) и добавить его вычисление в имеющийся код? В любом случае, для раздельного указания номеров страниц потребуется второй блок смещений в подмодуле для каждого тома. — Lozman (talk) 12:42, 17 октября 2018 (UTC)

Да, видимо так. А как вы думаете, вообще имеет ли смысл такая функция? Вроде полезная, но перевешивает ли на другой чаше весов заморочку и усложнение кода? --Vladis13 (обсуждение) 18:26, 17 октября 2018 (UTC)

Думаю, да. На самом деле, ситуация не вполне нормальная: можно ссылаться на два разных файла, но нумерация страниц у них при этом должна быть идентичной. Нужно предусмотреть ситуацию, когда нумерация отличается. Насколько сложно — я посмотрю, может, все окажется вполне реализуемо. — Lozman (talk) 12:27, 19 октября 2018 (UTC)

Есть идея как реорганизовать структуру данных по смещениям. В настоящее время параметры scan и offsets (или startnum) существуют сами по себе, что не есть хорошо. Предлагаю свести их в одну структуру scans примерно следующего вида:

scans = {
	-- источник 1
	{ 
		source = { "01003599381", 1, "РГБ" }, -- используется шаблон scanpat[1]
		map = {
		    {    1,    4 },
		    {   54,   58 },
		    {  155,  163 },
		    {  189,  198 },
		    ...
		},
		factor = 2,
		correction = 1,
	},
	-- источник 2
	{ 
		source = { "", 2, "Commons" }, -- добавить scanpat[2]; строка пустая, т.к. нет номера тома
		map = {
		    ...
		},
		factor = 1,     -- default, можно не указывать
		correction = 0, -- "
		indexonly = false, -- если источник нужно использовать ТОЛЬКО для индекса
	},
},
index = 2 -- т.е. данные scans[2] использовать для индекса

Это позволит иметь несколько источников (переменная source) и указывать для каждого источника свой набор смещений (переменная map), соответственно, ссылаться не на один, а на несколько сканов при необходимости. Один из источников (по номеру) может использоваться также для для вычисления страниц индекса (переменная index); главное, чтобы источником был локальный файл. Легкая коррекция кода основного модуля (как я показывал ниже) позволяет обойтись без to, после чего остальные два значения превращаются в маппинг вида { print_page, scan_page } и вполне могут быть безымянными. Если какой-то диапазон страниц отсутствует в источнике, для предотвращения ссылок на него второе значение маппинга устанавливается в false. indexonly = true будет означать, что данный источник используется только для индекса, но не для ссылок на сканы (впрочем, можно сделать и проще: раз для индекса фактически не нужна переменная source, указывать source = false или просто опускать). — Lozman (talk) 21:24, 26 октября 2018 (UTC)

«В настоящее время параметры scan и offsets (или startnum) существуют сами по себе». — Разве они не в блоках по томам

p.volumes = {	
	["0"] = { 
		[false] = "Реальный словарь классических древностей (1885)", 
		[true]  = "Реальный словарь классических древностей (1885)", 
		scan = { "01003599381", 1 },
		offsets = { ... },
		factor = 2,
		correction = 1,
	},
}

Тогда scans в вашем примере уровнять с ["0"] (номером тома), заменив scan на source, offsets на map и т.д. ? --Vladis13 (обсуждение) 23:39, 26 октября 2018 (UTC)

В том и беда, что по томам: из-за этого таблица маппинга оказывается связанной напрямую с томом, а не с источником, как следовало бы, и невозможно использовать больше одной такой таблицы. А я предлагаю связывать с томом таблицу источников, а уже в каждом источнике иметь свою таблицу маппинга. Т.е. scans не вместо ["0"], а его дочерний элемент (вместо scan и offsets). Кстати, возможно, лучше именовать наоборот: таблицу источников — sources, а ее элемент с данными для ссылки — scan, как и сейчас? Примерно так:

p.volumes = {	
	["0"] = { 
		[false] = "Реальный словарь классических древностей (1885)", 
		[true]  = "Реальный словарь классических древностей (1885)", 
		sources = {
			{
				scan = { "01003599381", 1, "РГБ" },
				map = { ... },
				factor = 2,
				correction = 1,
			},
			{
				scan = { ... },
				map = { ... },
				factor = 2,
				correction = 1,
			},
		},
	},
}

Можно называть не scan, а, скажем, uridata linkdata — там как раз данные для ссылки. Или вообще расформировать эту таблицу, преобразовав в скалярные переменные (id, pattern и title?). — Lozman (talk) 14:56, 27 октября 2018 (UTC)

Выглядит хорошо. Единственно, эта опция с двумя источниками нужна мало где. (Пока только в РСКД, где проблема с загрузкой качест.скана.) Чтобы не усложнять везде без нужды, наверно надо сохранить возможность указывать параметры scan, map, factor, correction на 1-м уровне в томе. А если есть sources, тогда уже брать из него? --Vladis13 (обсуждение) 22:41, 28 октября 2018 (UTC)

Это может быть востребовано везде, где вместо одного качественного источника имеются два или более источника не очень высокого качества (например, в ВЭ). Также в умозрительном случае, если потребуется разбить чрезмерно большой файл скана на меньшие части — каждая из частей будет отдельным источником, и т.д. Если же источник безальтернативно один, можно предусмотреть возможность помещать данные непосредственно в volumes[i], а не в volumes[i].sources[1]. Это упростит структуру подмодуля, правда, несколько (не сильно) усложнит код обработчика в основном модуле. Еще один минус такого сокращения — при переходе со старой на новую структуру возможны конфликты, т.к. старые и новые данные будут находиться на одном уровне таблицы; а если новые данные помещаются в sources, развести их значительно проще. Хотя, возможно, это необоснованное опасение. — Lozman (talk) 00:34, 29 октября 2018 (UTC)

Вроде сделал для Модуль:Отексте/РСКД и Модуль:Отексте/ТСД3, тест на ТСД3/Аллегро и РСКД/Hercules. Приоритет взятия данных: если есть sources то оттуда, иначе с 1-го уровня. Переменная «index» уже есть (см. Модуль:Отексте/РСКД) — аналог «linkdata», но для индексов (надо бы объединить их), поэтому назвал новую как «usesource». Там есть нюанс, что если томов будет много, то из этих usesources надо делать отдельный массив, с указателями для какого тома использовать какой источник. Или внести её в массив «sources», но там списки источников, она тоже будет считаться как источник (sources = { {...}, {...}, usesources = 2} }). Или в источнике (напр. в sources[2]) включать использование как например «use = true». Но например, если в списке 60 томов, трудно будет выискивать/править эти переменные. Лучше через отдельный список-указателей (1-й вариант), напр. usesources = {{1,1}, {2,1},{3,1},{4,1},{5,1},{6,1}, ...} ? --Vladis13 (обсуждение) 00:26, 31 октября 2018 (UTC)

Сделал, по-моему, вполне уже работоспособную версию. Можно обкатывать на реальных примерах, отлавливать ошибки. Вместо volumes[i].usesource используется volumes[i].sources[j].index (ну или volumes[i].index для «плоской» версии (без sources). Формат index — такой же, как и был: { id, pattern }. В принципе, pattern можно не указывать, по умолчанию значение 1. — Lozman (talk) 22:11, 8 ноября 2018 (UTC)

Симпатичный код. Как работает index и почему может заменять usesource я смутно понимаю, магия.

А вот в Модуль:Отексте/ТСД3 есть строки вроде scan = { "1_(Даль_1903)", 1 },, это не дубликат index? может объединить? Если так, то лучше переименовать индекс в что-то вроде index_sufix? И сделать скалярными переменными, как вы раньше предлагали? А то забывается что за непонятный набор символов там. --Vladis13 (обсуждение) 23:37, 8 ноября 2018 (UTC)

Все магия, что не физика :) Скрипт просто перебирает все элементы таблицы sources, и в каком первом найдет true переменную index, тот и использует для генерации indexfile. Изначально index и замысливался скалярным (равно как и indexpat), но потом возникло такое чудо инженерной мысли как Модуль:Отексте/ТСД, которому понадобилось сразу три шаблона для indexfile. Отсюда и пошло усложнение. Но вы правы, почти во всех случаях (в том числе в 100% действующих подмодулей) эти данные избыточны. Сделал поддержку разных типов данных переменной index:

• таблица вида { id, pattern }, где id — переменная часть indexfile, а pattern — номер шаблона в таблице indexpat (почти всегда равно дефолтному 1, может опускаться)
• строка: при этом id = index и pattern = 1
• число: id = "" и pattern = index (для выбора одного из нескольких значений indexpat, но без подстановки переменной части)
• литерал true: используются аналогичные id и pattern значения из linkdata (или scan).

Также теперь можно использовать скалярное значение indexpat. — Lozman (talk) 22:33, 9 ноября 2018 (UTC)

А что насчёт тождественности scan и index? И может id переименовать в suffix? По сути, это суффикс имени файла, только в ссылках на РГБ суффикс = id. --Vladis13 (обсуждение) 11:55, 10 ноября 2018 (UTC)

Нет, id — не суффикс, он может находиться в любом месте строки, где-то посредине, как в тех же ссылках на РГБ, да хоть в самом начале. Переименовать можно, но название стоило бы придумать более удачное. Переменные scan и index (табличный формат) тождественны по структуре, а для одного и того же источника — скорее всего, и по содержанию. Для этого я и предложил значение index = true, которое позволяет избежать дублирования, используя для id и pattern значения из linkdata (или scan). — Lozman (talk) 14:37, 10 ноября 2018 (UTC)

Может label? Хотя и id тоже не плохо, если эти литералы уникально отличают имя файла от других, например "т._4_(1886)". Насчёт scan и index я все ровно мало что понимаю :), если тождественны то надо объединить чтоб не путали. --Vladis13 (обсуждение) 18:54, 10 ноября 2018 (UTC)

Это и есть уникальный идентификатор данного тома в пределах издания (для локальных файлов) или всей библиотеки (для внешних ссылок типа РГБ). Поэтому переименовать можно, но большого смысла я в этом не вижу. Насчет объединения scan и index я выше предложил способ (и он уже реализован). Совсем свести эти переменные в одну нельзя, они играют роль флагов: наличие linkdata/scan (надо будет впоследствии везде заменить scan на linkdata, чтобы не путать) включает отображение этого источника в списке сканов, наличие index — отображение его же как индекса. Сделать это одной переменной если и получится, вряд ли выйдет проще, чем сейчас. К тому же теоретически значения этих переменных могут быть и разными. — Lozman (talk) 20:42, 10 ноября 2018 (UTC)

scan = linkdata, а не index? И к тому же перегружены как переключатели? А, ну хорошо, я просто запутался в них. --Vladis13 (обсуждение) 07:54, 11 ноября 2018 (UTC)

Из-за разобщённости scan и index с linkdata оказывается сломались статьи ТСД3. (Там пагинация скана много где задана в словниках, поэтому поломку других страниц не заметили.) Я наложил заплатку, но лучше проверьте. --Vladis13 (обсуждение) 12:16, 12 ноября 2018 (UTC)

Спасибо, это я недосмотрел. Впрочем, в дальнейшем scan все равно нужно будет везде заменить на linkdata (по смыслу это одно и то же). А зачем вы завели переменную st, она вроде нигде не исполльзуется? — Lozman (talk) 19:03, 12 ноября 2018 (UTC)

P.S. И все-таки, кажется, мы зря отказались от использования correction. Из-за ее устранения из формулы приходится прибегать к костылям типа { 337, 175 }, { 338, 176 } для исправления перекоса после «полусканов» (сканов с неполным набором страниц). А при использовании correction такие костыли не требуются. Нужно проверить на практике, во всех ли случаях это так (но я пока не встречал исключений). — Lozman (talk) 22:48, 9 ноября 2018 (UTC)

Если correction нужен то добавьте. Просто мне кажется это лишняя переменная, тоже костыльная. Номера страниц в map все ровно указываются как есть в источнике. Т. е. correction вроде и не нужно. Применяется исключительно для редких случаев (вкладки, тип.брак) вроде { 337, 175 }, { 338, 176 }. Но тогда, что делать если в каких-то диапазонах будет другое значение correction? Без него можно просто указать нужный номер страницы, а с ним… не представляю как придется выкручиваться. --Vladis13 (обсуждение) 11:51, 10 ноября 2018 (UTC)

Это не костыль, а как раз коррекция, т.е. системное исправление, для ситуации, обусловленной существованием двух концептуально разных типов распределения нумерации по страницам, у которых factor > 1: условно «кратный» и «некратный» (для factor = 2 — «четный» и «нечетный»). Первый характерен для страниц, набранных в два столбца (последний номер на странице четный), второй — для текстов, отсканированных в разворот (последний номер нечетный). Использование correction = 1 превращает нечетный тип в четный, что позволяет обрабатывать их в дальнейшем одинаково. Случаи такие отнюдь не редки, вставки и брак встречаются более чем в половине словарей/энциклопедий, с которыми мне приходилось сталкиваться. Гипотетическую ситуацию, в которой возможно использование разных значений correction в одной пагинации, я представить себе не смог; но если такое возможно (а вот это действительно будет очень редкий случай), то и здесь у нас есть «методы против Кости Сапрыкина»: можно обрабатывать диапазоны страниц с разной коррекцией как отдельные пагинации, или даже как отдельные источники с одинаковым набором linkdata, но с разными наборами страниц. Наконец, ваш способ с двойными номерами тоже никуда не девается: его можно использовать, оставив значение correction = 0. В общем, применять correction или нет — дело хозяйское, но сама такая возможность должна быть. — Lozman (talk) 13:59, 10 ноября 2018 (UTC)

Параметр offset (смещение)

Терзают сомнения, может вместо смещения (и заморочек с его вычетами/прибавлениями в уме туда-сюда) сделать просто указатель начального номера, который будет также инкрементироваться последовательно? Т. е. вместо диапазона, например, «3, 7, -2» (начало, конец, смещение), что сделает номера «1, 2, …, 5», делать просто «3, 7, 1» (начало, конец, старт), что даст тот же результат.
Эта система действует в Викитеке на страницах Индекса, в теге <pagelist />. И кстати, когда делаю ботозаливки, неудобно пагинацию, уже сделанную в Индексе таким способом, пересчитывать в скрипте заливки, где сделана система через смещения. И так для каждой книги. --Vladis13 (обсуждение) 18:39, 17 октября 2018 (UTC)

Не знаю, возможно, такой способ был бы и правда удобнее. Кстати, можно заодно отказаться и от параметра to и просто считать до параметра from следующего диапазона, т. е. указывать диапазоны в виде «3, 1», «8, 7» и т. д. Но для этого потребуется в корне переработать формулу расчета смещений (и лучше также переименовать параметр, чтобы не вводил в заблуждение), а самое главное — переделать все подмодули, где уже используется нынешняя схема. А это трудозатратно и чревато проблемами, как минимум в переходный период. Как вариант, предлагаю не менять логику функционирования параметра offset, а завести параллельно ему какой-то новый параметр, в котором будет указываться именно реальный номер страницы, а не смещение, чтобы можно было использовать обе схемы одновременно, постепенно переводя подмодули на новую. Если же отказаться от to, то два оставшихся параметра по новой схеме теоретически можно сделать и безымянными: {3, 1}, {8, 7} и т. д. — Lozman (talk) 13:02, 19 октября 2018 (UTC)

Вроде работает. Можно проверить на ТСД3 (factor=2) и ТСД2 (factor=1), где с подгрузкой из ПИ Страница, РСКД (factor = 2, correction = 1), где ссылки на скан РГБ. Vladis13 (обсуждение) 21:05, 22 октября 2018 (UTC)

Для переделки подмодулей я мог бы сделать скрипт (чтобы избавится от рутинных трудозатрат и риска опечаток). Можно сохранив параллельно схему с offset, на время перехода.

Скриптик для конвертации. Вставить здешнее значение offsets в одноимённую переменную там, нажать «Run». Расчёт для factor =1. Для =2 не сделать формулу, надо вручную. --Vladis13 (обсуждение) 19:25, 26 октября 2018 (UTC)

"to" для пагинации в сканах кажется и правда не нужен. Но в пагинации книг может использоваться на страницах-вставках где номер не надо отображать ("3, 4", вставка, "6, 7"), где вставка без номера ("3, 4", вставка, "5, 6"), разные цифровые диапазоны ("III, IV, 1, 2, 3"). Получится ли это в таблицах маппинга (номера скана = книги)? Vladis13 (обсуждение) 14:49, 20 октября 2018 (UTC)

Вставки не влияют на вычисление номеров страниц по файлу. При использовании параметра to они оказываются между to и from двух смежных диапазонов, а без to — в конце первого диапазона; в обоих случаях они игнорируются. Во втором случае до них просто не доходит очередь (диапазон «3, 4» печатных страниц соотносится с диапазоном файла «3, 4, вставка»). Единственный нюанс — при включении из ПИ Страница может оказаться, что такая вставка находится между страницами одной статьи (т.е. между hard.from и hard.to). При этом скорее всего будет неправильно вычисляться значение soft.to (без учета вставки). Но это недостаток действующего алгоритма вычисления смещений (offset вычисляется единожды для soft.from и используется без изменений для soft.to; нужно переделать код, чтобы он вычислялся для каждого значения отдельно). Что до «разных цифровых диапазонов», то для этого используются разные пагинации. Правда, я пока не придумал, как обрабатывать нумерацию римскими цифрами. А чтобы удобнее было использовать диапазоны без to, можно применить обратный перебор элементов таблицы, т.е. вместо for _, w in ipairs ( startnums ) do ... использовать for i = #startnums, 1, -1 do w = startnums[i] ... При этом, поскольку таблицы отсортированы в порядке возрастания from, будут пропущены все элементы, для которых v.hard.from < w.from и выбор остановится как раз там, где нужно (первый элемент с конца, для которого v.hard.from >= w.from). — Lozman (talk) 22:09, 22 октября 2018 (UTC)

По конвертации римских цифр: w:Шаблон:Roman -> w:Модуль:Math#Roman, w:en:Template:Roman — арабские в римские. Из римских в обычные на вики не нашёл. Есть много вариантов на python. На lua, [1]. --Vladis13 (обсуждение) 21:25, 25 октября 2018 (UTC)

Не понимаю как делать. 1. Не понятно как использовать отладчик Lua. В коде есть строки вроде mw.log("v.hard:",mw.dumpObject(v.hard),"w:",mw.dumpObject(w)), внизу редактора страницы Модуль:Отексте написано, что такие строки делают вывод в консоль. Но у меня ничего не выводится. 2. Пытаюсь умозрительно понять смысл переменных, изучая предыдущий код, но там много преобразований, непонятно. Например, тестирую на ТСД3/Аллегро. Но скрипт срабатывает на условии в 411 строке, а условия в 413 и 423 пропускает. Что такое «v.soft.from» непонятно, судя по выше это unpack ( split ( v.soft.raw ) )[1], а что такое «raw»? Это какое-то преобразование из «itemdata», а то что такое? Почему-то тестовая ТСД статья показывается нормально, со всем смещениями, которые были отключены… В тоже время для РСКД/Hercules срабатывает условие в 413, и не зная что в переменных, не могу сделать предложенный алгоритм. --Vladis13 (обсуждение) 19:19, 26 октября 2018 (UTC)

Сообщения mw.log выводятся в режиме предпросмотра при редактировании (либо страницы, использующей модуль, либо самого модуля — с помощью инструмента «Предварительный просмотр страницы с использованием этого шаблона или модуля»): в самом низу страницы, в разделе «Данные анализатора» → «Журналы Lua». Переменная v.soft.raw получает значение 4-го параметра шаблона «Статья в словнике» или его аналогов (необработанное = raw), а приведенный вами код разбирает его на from, to и skip для использования с <pages>. Значения, полученные из v.soft.raw, имеют безусловный приоритет перед любыми вычисляемыми смещениями — для возможности ручного переопределения в особо сложных случаях, с которыми модуль не справляется. Если в шаблоне указан непустой 4-й параметр, будет использован именно он (срабатывает строка 411), поэтому для работы смещений он должен быть пустым или отсутствовать (тогда управление перейдет к строке 413, а при отсутствии startnums — к 423). — Lozman (talk) 20:17, 26 октября 2018 (UTC)

Сообщения mw.log выводятся ... в самом низу страницы, в разделе «Данные анализатора» → «Журналы Lua». — Да, что-то есть. Большое спасибо! буду изучать. --Vladis13 (обсуждение) 22:55, 26 октября 2018 (UTC)

#startnums почему-то имеет значение "0" (стр. 416-121, тест на РСКД/Hercules). Поэтому не работает for i = #startnums, 1, -1 do w = startnums[i] ... Странно, как это так? --Vladis13 (обсуждение) 23:17, 28 октября 2018 (UTC)

Да, обидно: для таблиц, загруженных через mw.loadData(), #value не работает, как и большинство «табличных» функций; ipairs() работает, но идет всегда от начала. Можно, конечно, отсортировать map в обратном порядке, но стоит ли? Можно попробовать эмулировать это значение как-то так: local len = 0; for i, v in ipairs(startnum) do len = i end, и вместо #startnums использовать значение len, но не уверен, что сработает. — Lozman (talk) 00:14, 29 октября 2018 (UTC)

Работает. :) --Vladis13 (обсуждение) 00:21, 29 октября 2018 (UTC)

Названия переменных

Ещё предлагаю переименовать "correction" в "shift" ("смещение, сдвиг"), ибо "коррекция" непонятно, слишком обще. И "factor", например, в "numsperpage". Vladis13 (обсуждение) 21:12, 22 октября 2018 (UTC)

Названия я выбрал не самые удачные, пожалуй, но не уверен, что shift в данном контексте понятнее (и что shift не будет по смыслу путаться с offset). Numsperpage точнее передает смысл переменной, но выглядит как-то неуклюже. Надо подумать. — Lozman (talk) 22:16, 22 октября 2018 (UTC)

Диапазоны с дублирующейся пагинацией

Для обработки диапазонов с дублирующейся нумерацией страниц надо идти по нумерации скана, она уникальна; в отличие от произвольной нумерация страниц книги. (Примеры: много дубликатных и смещённых нумераций в РСКД, в ЭЛ/7 три нумерации «I,II,III… 1,2,3…1,2,3».)
Но это невозможно, поскольку в словниках указывается именно книжная пагинация, что универсально и правильно. Указывать фиксированную для скана там неудобно. И вообще, теперь, с появлением возможности указания нескольких вариантов источников, неясны перспективы указания там пагинации лишь одного скана.
Тогда предлагаю добавить в маппинг ещё параметр — id диапазона с другой пагинацией, где не нужен не ставить. Тогда и в словниках надо указывать этот id, емнип, в {{статья в словнике}} есть возможность указывать несколько параметров для разных пагинаций через «/». Это нормально если id др. пагинации будет отображаться на странице, раз в самой книге такая пагинация.
(Хотя если др. нумерация римскими цифрами, можно не отображать, римские цифры говорят сами за себя. Но также иногда бывает и несколько диапазонов римскими, например в начале и в конце книги «I, II, III, … 1,2,3… I, II, III».) --Vladis13 (обсуждение) 07:44, 4 ноября 2018 (UTC)

Такой функционал уже есть. Переменная v.pagination берет значение из 3-го параметра шаблона в словнике (формат параметра: страницы/пагинация/том). Значение v.pagination служит ключом для таблицы volumes[i].paginations, структурно аналогичной самой volumes[i]. Сделал аналогично и для новой схемы (volumes[i].sources[j].paginations). Пока не опробовал. — Lozman (talk) 22:20, 8 ноября 2018 (UTC)

Модуль расширения

@Lozman посмотрите пожалуйста. Ошибки в В чём моя вера? (Толстой), Модуль:Отексте/ТолстойПСС.
1) Почему-то в шапке показывается «переводчик» и «язык оригинала».
2) «Часть» не задана, но в шапке на этом месте показывается тире к пустому месту.
3) Категория не ставится, хотя задана в модуле.
Кстати, в каком формате указывается КАТЕГОРИИ, массивом, вроде ['КАТЕГОРИИ']= {'Одна', 'Вторая'}? --Vladis13 (обсуждение) 16:56, 26 ноября 2018 (UTC)

Служебная:Diff/3495851: тонкости манипуляции со строками в Lua. origLang == nil воспринимается как неизвестный язык, для которого должен быть переводчик. Инфо о переводе подавляется, если значение origLang совпадает с одним из ключей таблицы ignoreLang (например, "ru", "русский" или пустая строка, но не nil). Наоборот, part игнорируется только при значении nil (или false), а пустая строка интерпретируется так же, как и непустая. Категории могут передаваться двояко: либо через параметр categories (но не category — этот только для словарных статей); список категорий объединяется в строку, разделенную тильдами, т.е. "Категория 1~Категория 2". Либо более удобный способ — через вторую возвращаемую таблицу в формате { "[[Категория:Категория 1]]", "[[Категория:Категория 2]]" }. — Lozman (talk) 19:55, 26 ноября 2018 (UTC)

Понятно, спасибо. --Vladis13 (обсуждение) 20:11, 26 ноября 2018 (UTC)

frame входных данных в модулях расширений

@Lozman Сейчас приём и нормализация входных данных реализована так: массив с параметрами шаблона передаётся в расширение, и там надо нормализовывать все эти переменные, и задавать также все стандартные, чтобы они тоже были в модуле и необходима их нормализация, которую не узнать не изучая основной модуль. (Например в Модуль:Отексте/ТолстойПСС, надо добавлять стандартный параметр is(a[«ДРУГОЕ»]), который модуль не меняет, и все другие стандартные, и предусматривать его нормализацию посредством is(), и т. п.) И так придётся с каждым модулем-расширением. В случае обновления параметров или добавления новых в {{Отексте}} придётся обновлять и все расширения.

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

local pargs = frame:getParent().args
if isExt then
    data.p = require( extpath ).wrapper( frame, pargs )
else
    data.p = {
	quality = pargs["КАЧЕСТВО"],

А будет расположен перед обработчиком.

local pargs = frame:getParent().args
if isExt then
   pargs = require( extpath ).wrapper( frame, pargs )
end
data.p = {
   quality = pargs["КАЧЕСТВО"],

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

Т. е. массив поступает в расширение в виде например: parg = { [«ЧАСТЬ»]=bar, [«НАЗВАНИЕ»]=foo) }, расширение изменяет только параметр parg[«НАЗВАНИЕ»]=foobaz, всё это возвращает в главный модуль как parg = {[«ЧАСТЬ»]=bar, [«НАЗВАНИЕ»]=foobaz)}. И главный модуль нормализует как ему нужно. --Vladis13 (обсуждение) 07:12, 5 декабря 2018 (UTC)

Не уверен, что это сработает. Все-таки pargs — не совсем нормальная таблица, возможно, ее нельзя так переопределить (можно, впрочем, использовать вместо pargs какую-то временную таблицу, скажем, xargs; тогда в вашем примере будет xargs = require( extpath ).wrapper( frame, pargs ) и quality = xargs.q or pargs["КАЧЕСТВО"],). Но нынешний способ передачи параметров делался именно с упором на то, что модуль расширения сам определяет, какие параметры ему нужны, а остальные отбрасывает. А при том способе, который предлагаете вы, все штатные параметры шаблона Отексте будут присутствовать и в расширении, даже если они там не нужны и мешают. Можно попробовать гибридный способ: скажем, пусть модуль расширения возвращает основному модулю флаг, который сигнализирует, нужно ли проводить дообработку параметров или оставить как есть. Например, params.postProcess = true. — Lozman (talk) 23:13, 5 декабря 2018 (UTC)

@Vladis13 проверил, работает! Обновите Модуль:Отексте/ТолстойПСС (имена ключей возвращаемой таблицы). Поразмыслив, пришел к выводу, что никакой флаг передавать не нужно: пусть модуль расширения сам определяет, какой набор параметров возвращать. Скажем, если нужно переопределить значения только некоторых параметров, а остальные вернуть неизменными, можно присваивать их индивидуально: pargs["ДРУГОЕ"] = other, отключая лишние при необходимости: pargs["УТРАТИЛ СИЛУ"] = nil. Если же нужно передать небольшой ограниченный набор параметров — пересоздавать всю таблицу, при этом можно повторно присваивать первоначальные значения: pargs = { ["ДРУГОЕ"] = pargs["ДРУГОЕ"], ... }. — Lozman (talk) 18:19, 6 декабря 2018 (UTC)

Замечательно! Спасибо. --Vladis13 (обсуждение) 11:10, 7 декабря 2018 (UTC)

Задержка в отрисовке css шапки на несколько секунд

У шапки есть заметная проблема. Когда открываешь страницу, то сначала она отображается одним оформлением, а через несколько секунд оно меняется. Особенно заметно при открытии на телефоне.
Связано с тем CSS грузятся после загрузки всего текста. Если текст большой, то задержка дольше. Вообще, отрисовка должна срабатывать сразу при загрузке html-контейнера (div, span), возможно модуль как-то задерживает завершение </div> блока шапки до того как загрузит текст, и в нем какие-то ключевые для шапки стили CSS?
Надо бы вынести CSS из кода модуля, назначая в нем только структуру и содержимое контейнеров, а для связи с css использовать html атрибуты class и id. Vladis13 (обсуждение) 14:40, 8 августа 2023 (UTC)

• Кажется это проблема мобильной версии. https://ru.m.wikisource.org/wiki/%D0%9A%D0%BD%D0%B8%D0%B3%D0%B0_%D0%BE_%D1%81%D0%BC%D0%B5%D1%80%D1%82%D0%B8_(%D0%90%D0%BD%D0%B4%D1%80%D0%B5%D0%B5%D0%B2%D1%81%D0%BA%D0%B8%D0%B9)/2 Vladis13 (обсуждение) 14:47, 8 августа 2023 (UTC)