Скажите, существует ли способ узнать, есть ли статьи с ссылками или перенаправления на данный раздел или якорь в некоторой статье? Alexei Kopylov16:13, 30 апреля 2016 (UTC)
Да, похоже, что поиск игнорирует редиректы. А индексация тут не причём. Как же мне узнать, могу ли я убрать якорь из статьи, на который, как я думаю, больше никто не ссылается? Более серьезная проблема: довольно часто при переименовании разлела, ссылки на этот раздел ломаются. Нет ли какой-нибудь возможности сделать фильтр, который при попытки изменить/убрать название раздела, проверял бы нет ли на этот раздел ссылок (хотя бы только из основного пространства рувики), и если есть, предупреждал бы автора? Alexei Kopylov01:26, 6 мая 2016 (UTC)
Присоединяюсь.А правда, бред какой-то. При всей мощи поиска узнать редиректы на раздел, оказывается, никак нельзя. Перерыл разные справки, нигде этот момент не освещается. — Джек, который построил дом02:40, 6 мая 2016 (UTC)
Слева по борту страницы - Содержание, там раздел: Инструменты → Ссылки сюда → Страницы, ссылающиеся на [Название статьи] → Инструменты: Показать только перенаправления. Результат C уважением, --Olgvasil04:20, 6 мая 2016 (UTC)
Понял, спасибо. В таком случае правильно, что этот параметр обязательный. Просто имя параметра может сбить с толку. Оригинальное название - это не название в момент создания, как подумал коллега, а просто общепринятое название (возможно, на языке оригинала). Оно не может быть неизвестно. Vcohen12:07, 3 мая 2016 (UTC)
Так переименовать надо параметр. У любого нормального человека сочетание "оригинальное название" может быть прочтено только как название в момент создания/название, данное создателем. И никак иначе.--Dmartyn8014:42, 4 мая 2016 (UTC)
Работаю по категории Категория:Википедия:Статьи с сомнительной значимостью с целью добавления источников/вынесения на удаление. В эту категории статьи добавляют шаблоны {{Значимость}} и параметр notability в шаблоне {{rq}}. В первом случае указывается дата постановки шаблона, и статья попадает в одну из категорий Категория:Википедия:Статьи с сомнительной значимостью по давности. При использовании rq статьи складываются в общую категорию без какой-либо сортировки по дате. В связи с этим работа как с категорией, так и с самой статьёй сильно затрудняется: не понятно, запрос значимости вывешен вчера или пять лет назад (такие есть).
Возможно ли реализовать следующую схему: если в статье есть шаблон rq с параметром notability, определить дату добавления (по истории, видимо), поставить на страницу шаблон «Значимость» с полученной датой, убрать параметр из rq (если он там единственный, то и rq вместе с ним).
Пока хотелось бы просто узнать, возможно ли это реализовать. Если да, то могу создать более широкое обсуждение (если требуется; на общем форуме или ещё где). — Викиенот07:02, 30 апреля 2016 (UTC)
Не надо заменять строчку в rq (который и нужен для компактности) на отдельный здоровый шаблон. Лучше добавить в rq параметры дат. --INS Pirat09:59, 30 апреля 2016 (UTC)
Да тут и обсуждать нечего, и пример с шаблоном {{значимость}} — частный. Просто {{rq}} надо реорганизовать во что-то аналогичное английскому {{Multiple issues}}, где все эти тонкости с датами и прочим давно учтены: {{Multiple issues}} просто обёртывает группу шаблонов о проблемах, и они из полноценных шаблонов превращаются в его строчки. Время от времени бот проходит и обёртывает в него разросшиеся стопки. Можете добавить задачу в секцию проекта "Технические работы", или я сам добавлю. — Джек, который построил дом11:40, 30 апреля 2016 (UTC)
Добавление даты в rq тоже выглядит логичным. Меня в принципе больше результат волнует, а не средство. Если вас не затруднит, добавьте, пожалуйста. — Викиенот21:01, 30 апреля 2016 (UTC)
Сейчас добавлю.Только как дату в rq добавлять? Не одну же на весь шаблон, пункты списка могут добавляться и убавляться. Если только каким-то псевдосинтаксисом, типа {{rq|notability/1 мая 2016|sources/20 апреля 2016|...}}, что даже визуально неприятно. К тому же с rq есть проблема необходимости помнить имена параметров, отличные от названий шаблонов (недавно даже один администратор посетовал, что не помнит всех этих имён параметров). Идея с обёртыванием выглядит наиболее изящной.С другой стороны, придётся, конечно, попотеть над каждым шаблоном-предупреждением, чтобы в нём это реализовать. — Джек, который построил дом21:28, 30 апреля 2016 (UTC)
У меня был вариант что-то в духе {{rq |notability= 2016-05-01 |sources= 2016-05-01 | и т.д. }} (как в тех же шаблонах-карточках это выглядит). В случае, если дата не задана, то отображать без даты и добавлять в общую категорию (либо ботом дописывать, как сейчас это с шаблонами {{Значимость}} и {{Нет ссылок}}, например. Но что-то мне подсказывает, что всё не так просто. — Викиенот21:43, 30 апреля 2016 (UTC)
Только это уже ломает устройство шаблона {{rq}}, который не вникает, какие параметры ему передаются, а просто делегирует всё подстраницам, которые и выводят тексты пунктов. Если мы учитываем тонкости категоризации в rq, то мы по сути дублируем внутри rq и его подстраниц функциональность соответствующих шаблонов-предупреждений, которые могут категоризировать по очень хитрым принципам. А потом может возникнуть потребность в ещё каких-то параметрах, кроме даты... Уж легче, я думаю, сразу сделать всё универсально. — Джек, который построил дом22:06, 30 апреля 2016 (UTC)
С другой стороны, у {{rq}} есть преимущество в скорости записи. В свежесозданную плохо оформленную статью набор ключевых слов вставить быстрее, чем возиться с фигурными скобками. Так что если научить людей, например, писать так:
{{rq|notability|sources|date=2016-05-01}}
а при добавлении новых параметров заменять единую дату на индивидуальную для каждого параметра:
(или так, чтобы общая была по умолчанию, "если не указано иное") то будет весьма гибко и удобно. В свою очередь, если переписать на модуле, который будет иметь доступ к массиву переданных параметров, то их названия знать самому rq не надо будет — только дописывать даты в скобочках и передавать подстранице для дальнейшей обработки.Так что я засомневался. — Джек, который построил дом02:13, 1 мая 2016 (UTC)
На днях добавил в бота удаление всякой лишней юникодщины, вроде пробелов нулевой ширины, взяв регекспы у кого-то с англовики. Срабатывать он начал на удивление часто. Оказалось, что во многих статьях в рандомных словах (как правило, 1-2 на статью) стоит символ мягкого переноса (пример). Это такой магический символ, который позволяет в этом месте слово разбить на две строки, добавив в конце первой дефис. И вот начал я сомневаться: а нужно ли его удалять? С одной стороны, переносы — это хорошо, с другой стороны, всю статью так не отметишь, а два слова ничем не помогут, с учётом существующего зоопарка разрешений экранов. Да и когда в одном месте стоит перенос, а в другом оставлен отступ — некрасиво как-то. С одной стороны, они ничем особо не мешают при чтении Википедии, с другой — очень мешают при сканировании дампов, например (по второй причине такие символы удаляются из категорий и ссылок викификатором). Пока убрал удаление этого символа из бота, но вообще, хотелось бы этот вопрос обсудить. Кто что считает по этому поводу? ~Facenapalmобс, вкл18:36, 29 апреля 2016 (UTC)
Есть семейство шаблонов этого рода, см. {{shy}}, {{zwsp}} и т. д. Их сфера применения узка и касается каких-то специфических случаев. Например, shy может использоваться в каких-то узких ячейках таблиц (довольно недавно тема была о нём). Если автоматически удалять, то, возможно, только в тех случаях, когда эти символы располагаются в обычном строе текста, ни во что не обёрнутые. Предполагаю. — Джек, который построил дом18:52, 29 апреля 2016 (UTC)
Да, про строки таблиц я тоже вот подумал. Фиг с ним, вычёркиваю из бота безвозвратно. Буду удалять только внутри ссылок и категорий. ~Facenapalmобс, вкл19:00, 29 апреля 2016 (UTC)
Можешь самостоятельно поискать во вкладе моего бота: 29 апреля 2016 в 21:24 (по Москве) я остановил бота и убрал это исправление, до этого в некоторых статьях попадается. раз и два, например. ~Facenapalmобс, вкл20:10, 29 апреля 2016 (UTC)
Пример раз - копипаст из [2] два переноса на том же месте. Пример два - текст на иностранном языке в кавычках - высокая вероятность копипаста. --Hrum-Hrum15:34, 30 апреля 2016 (UTC)
Удалить, например, потому что wikiblame престаёт с ними работать: пример. Хотя, как показывает этот пример удаление мягких переносов, не чинит викиблайм. Он почему-то не ищет текст даже в последней версии, а если в поиске ввести текст с мягким переносом, то он находит его даже в версии, где мягкого переноса нет (пример). Так что это может быть аргумет за то, чтобы оставить (так хоть при копировании текста из статьи викиблайм будет работать). Alexei Kopylov19:58, 29 апреля 2016 (UTC)
Хороший аргумент. Теперь надо решить, что делать с узкими таблицами фиксированной ширины, где символ вставлен специально (хотя я таких случаев не видел, но в каких-нибудь карточках это может быть актуально). Сложными условиями вроде «удалять везде, кроме таблиц и шаблонов» я заморачиваться не буду: верну либо везде, либо оставлю только в категориях. Можно, правда, предположить, что в узких таблицах должны быть использованы шаблоны, а не символы — тогда вернуть можно. ~Facenapalmобс, вкл09:19, 30 апреля 2016 (UTC)
Плохой аргумент. Ссылаться на наше руководство по оформлению по каким-то специфическим вопросам, если за его положениями не прослеживается напряжения мысли (в обсуждениях или где-либо), — не лучшая идея. В данном случае процитированное положение очевидным образом следует из тривиальной идеи, что «переносов в вебе нет, и у нас не должно быть». Пх.Собственно, вот что говорят в английском разделе: en:MOS:SHY
Non-breaking: A non-breaking hyphen (‑ or {{nbhyph}}) will not be used as a point of line-wrap.
Soft hyphens: Use a soft hyphen to indicate optional locations where a word may be broken and hyphenated at the end of a line of text. Use of soft hyphens should be limited to special cases, usually involving very long words or narrow spaces (such as captions in tight page layouts, or column labels in narrow tables). Widespread use of soft hyphens is strongly discouraged, because it makes the wikitext very difficult to read and to edit (for example, This Wi­ki­source ex­am­ple is dif­fi­cult to un­der­stand). An alternative syntax improves readability:
Hyphenation involves many subtleties that cannot be covered here; the rules and examples presented above illustrate the broad principles that inform current usage.
Иногда переносы — единственная возможность корректно показать информацию и на узком, и на широком экране. Пример: {{Диапазоны радиоволн}} (поиграйте шириной окна браузера). А вот то, что все подобные служебные символы в коде статей должны быть видимыми (будь то путём использования HTML-мнемоник, шаблонов типа {{shy}}, {{nbsp}} и т. п., или каким-либо другим способом) — это да. DmitTrix10:03, 1 мая 2016 (UTC)
Кстати, невидимые мягкие переносы (как и пробел нулевой ширины и наверняка остальное) вообще не отображаются в виде символов в поле для редактирования с моноширинным шрифтом в Хроме (но каретка, если вести её стрелками на клавиатуре, два раза останавливается в одном месте). Так что невидимые мягкие переносы я и правда бы поддержал вырезать, это никуда не годится. А лучше, прежде чем вырезать, детектировать по ним копивио, как предложено ниже. — Джек, который построил дом11:13, 1 мая 2016 (UTC)
Тест­ирование → Тестирование Тест{{zwsp}}ирование → Тестирование Мягкий перенос символом после слога «мяг» Нулевой пробел символом после слога «ну» — Джек, который построил дом11:20, 1 мая 2016 (UTC)
Мягкие переносы нередко вставляются программами OCR, так что их наличие — повод присмотреться к тексту, в котором они найдены, на предмет копивио. Можно собрать статистику по их встречаемости (а в идеале — и по давности добавления. Чтоб не сильно долго работать, искать либо на полгода, либо на 50 правок вглубь)? 88.81.43.19814:09, 30 апреля 2016 (UTC)
Непонятен запрос. 1. Куда проставить, в карточку, категории, список? 2. Что проставить, врядли на этом форуме есть специалисты по распознаванию медалей по мелкому фото. --Vladis1319:06, 29 апреля 2016 (UTC)
Решил сделать замену по статьям с помощью ВП:AWB. Но тот, вместо того, чтобы искать «поисковый запрос для замены» в заданном списке, чтобы я смог проверить правку и нажать Save, начал помечать статьи из списка зелёным фоном. Я не понимаю. Думал, подожду, пока «докрасит» названия статей из списка. Но когда он дошёл до конца, то показывает мне на сером фоне последнюю статью с моей произведённой заменой. А что собственно дальше делать? Я не могу ни нажать Save, ни Skip. Помогите. ← Alex Greatобсуждение07:55, 28 апреля 2016 (UTC)
Я ещё подумал, что он уже совершил мою правку. Но зайдя на Википедию, он ничего не сделал. Я что-то сделал не так? Кстати, когда замена не проходит (если напортачить с регулярными выражениями, т.е. не находит в статье поискового запроса для замены), то AWB как и положено, начинает пропускать статьи удаляя их из списка. ← Alex Greatобсуждение07:58, 28 апреля 2016 (UTC)
Он для удобной фильтровки. Например, включаете опцию пропуска (skip) статей, не содержащих какой-то текст. Занимаетесь своими делами, а он в это время отфильтрует лишние, которые вы уже вручную просмотрите. Или когда нужно сразу получить список отфильтровки (который можно сохранить в файл, например) для отдельной работы. --Vladis1316:18, 29 апреля 2016 (UTC)
В статье Леонтьев, Василий Васильевич карточка «учёный» неожиданно посчитала, что Леонтьеву сейчас было бы 110 лет. Только вот проблема в том, что он умер в 1999 году.
Вроде бы сделал, но лучше если бы кто-нибудь проверил. Только там не дата «закрытия», а «дата ликвидации», как в самой статье.--Ksc~ruwiki 09:37, 26 апреля 2016 (UTC)
Уточню, что коллега, надо полагать, про последнюю реплику: «Тогда единственное разумное решение — допилить шаблон, чтобы он мог вызывать внешние ссылки для произвольного элемента викидаты. Тогда в статью о дискографии он пойдёт, вызывая элемент для артиста». — Джек, который построил дом19:26, 25 апреля 2016 (UTC)
Реализовать можно. А вот с магией сложнее. В принципе, если вызывается не из основной статьи, можно скрывать часть строк, но не очень понятно, какую часть. — putnik19:28, 25 апреля 2016 (UTC)
Конкретно в данном случае необходимо оставить блоки «Фото, видео и аудио» и «Тематические сайты», а блок «В социальных сетях» — скрыть. Если в статье о певице его наличие оправдано, то в статье о дискографии, на мой взгляд, не выглядит необходимым. --AleUst19:38, 25 апреля 2016 (UTC)
@putnik: Пожалуйста обратите внимание ещё и на вот это обсуждение в части ссылок на альбомы на сервисе «Яндекс. Музыка» и Москва.фм. Хотелось бы общими усилиями уже решить нужны они в шаблоне или нет. По Москва.фм возможно вообще удалить их надо --AleUst06:34, 26 апреля 2016 (UTC)
Никак не могу подать заявку на АПАТ. Хотелось бы узнать, это технические неполадки или это только у меня что-то не так? В истории все мои правки сохраняются, а в списке кандидатов моё имя не появляется. Sharon Avrielle15:34, 25 апреля 2016 (UTC)
Самому интересно, как я так умудрился:) Казалось бы, следовал и так несложной инструкции, но увы, "что-то пошло не так". Вроде бы не тыкал никуда. Спасибо:) Sharon Avrielle16:25, 25 апреля 2016 (UTC)
У меня было примерно такое же, когда вирус зарылся в браузере и левые рекламные ссылки вставлял в статьи Википедии, но у вас вроде как служебные шаблоны переломали страницу, не знаю даже как так. ← Alex Greatобсуждение03:56, 26 апреля 2016 (UTC)
Ну, оно ж не сразу. Обычно раз в неделю обновление накатывают, но тут из-за нового дата-центра возможно, что и позже. — putnik15:23, 25 апреля 2016 (UTC)
Коллеги, а почему он не работает адекватно? Посмотрите, как выглядит пример в документации и, например, в английской интервике --Arachn0обс10:52, 24 апреля 2016 (UTC)
Это делается за минуту копированием класса treeview и производных отсюда. (Кстати, кто-нибудь объяснит, почему в background негативные значения позиции?)--Любослов Езыкин12:42, 26 апреля 2016 (UTC)
Я не знаю, как назвать такие совпадения, но только что я почти перевёл инструкцию к шаблону и только потом чисто случайно увидел эту тему из «Ссылки сюда». Я было ещё хотел русифицировать этот шаблон и создать отдельно шаблоны:
Отлично! Я начал переводить/тестировать ещё утром, потом бросил и оставил на послеобеда/вечер/когда-нибудь. Вы исправили как раз, когда я бросил. :)--Любослов Езыкин15:32, 26 апреля 2016 (UTC)
Балуюсь я с дампом, и вдруг вижу такое вот перенаправление: ❶. Юникодный символ кто-то перенаправил на статью о числе. Ну ок. Ссылок на редирект нет, вбивать такое в поиск кто-либо будет едва ли (тем более, что подобные символы даже не во всех браузерах отображаются), в самой статье никак причастность этого символа к числу не комментируется. Перед тем, как отправить редирект на КБУ, я решил полистать дамп ещё и вытащил в общей сумме 150 (!) подобных перенаправлений.
Вдобавок оказалось, что в англовики такие перенаправления тоже есть: en:❶. Поэтому я решил для начала обсудить всё это здесь. Как по мне, это, как минимум, семантически некорректные перенаправления: символ «❶» не служит для обозначения единицы (для этого есть символ «1»), и, как я уже говорил, никакой информации о нём в статье о числе нет. Вдобавок, я не уверен, что это согласуется с правилами по именованию статей, не особо этот вопрос изучал.
@1234qwer1234qwer4: хотелось бы услышать твой, как автора, комментарий к этому вопросу. Возможно, есть какое-то логичное объяснение, которое я не учёл?
Кстати, судя по всему, у нас дохрена перенаправлений с одного юникодного символа на какую-то статью без ведущих на них ссылок. Надо будет изучить их правомерность тоже. ~Facenapalmобс, вкл15:39, 23 апреля 2016 (UTC)
Где-то эти символы, по-моему, были в ходу, именно как альтернативное обозначение чисел. В азиатских языках, что ли, каких-то программах… Вот, например посещаемость в английском разделе:
Удалить - хотя бы потому, что почему эти символы редиректят именно на цифры? Мало ли что они могут символизировать в каких-то контекстах (в частности, для знака ⑨ куда уместнее был бы редирект сюда) MaxBioHazard16:10, 23 апреля 2016 (UTC)
Ну, эти редиректы, на мой взгляд, корректны. Человек вводит/копирует юникодный символ и попадает на статью об этой серии юникодных символов. ~Facenapalmобс, вкл16:56, 23 апреля 2016 (UTC)
Спасибо. Я с аргументами там и согласен и не согласен одновременно. Скажем, 😂 — логичное перенаправление, а 👒 и ⬮ мне кажутся семантически неправильными. Вряд ли кто-то в здравом уме будет вводить юникодный символ, если ему захочется почитать про шляпу или овал. Я вижу два сценария: либо человек хочет узнать конкретно об этом юникодном символе, в этом случае такого класса редиректы — вред, либо он просто балуется, в этом случае на редиректы пофиг. Сам-то как считаешь? ~Facenapalmобс, вкл19:43, 23 апреля 2016 (UTC)
Редирект на блок — это хорошо, однако в текущем виде значительная часть перенаправлений попадает под ВП:КБУ, П5. Не лучше ли пока удалить, а потом создать заново, если и/или когда соответствующие статьи появятся? ~Facenapalmобс, вкл20:13, 23 апреля 2016 (UTC)
По-моему, ты не понял сарказма. :) Макс как раз говорил о том, что символы, перенаправляемые на статьи по принципу «похоже, на них изображено то-то» доверия не вызывают. Почему именно то-то, а не это-то? Где АИ? ~Facenapalmобс, вкл11:37, 24 апреля 2016 (UTC)
Как думаешь, уместно ли об этом писать в статьях Овал и Шляпа? Если да — к редиректам вопроса нет, надо только статьи подредактировать. Но по-моему, не совсем уместно. ~Facenapalmобс, вкл14:17, 24 апреля 2016 (UTC)
> Вряд ли кто-то в здравом уме будет вводить юникодный символ, если ему захочется почитать про шляпу или овал. Кстати, а почему нет? Именно графические символы есть то, что позволяет снизить "эффект Вавилонской башни". Шляпа в разных языках может именоваться по-разному, к тому же есть много разных видов шляп, но для такой шляпы в (практически) каждом языке есть своё имя. Ходишь по разделам и узнаёшь, как в них называется такая шляпа. Будущее, можно сказать. Картинки-то в поиск не вобьёшь. — Джек, который построил дом18:48, 24 апреля 2016 (UTC)
@Facenapalm: Его даже вводить не нужно, всё просто и удобно (причём, когда не включена запись, у меня показывает русскую статью). Так что не нужно трогать валидные редиректы только потому, что кто-то считает из бесполезными. Про некорректные редиректы разговор отдельный. — putnik23:04, 24 апреля 2016 (UTC)
@putnik: так разговор как раз о том и идёт, что редиректы эти нифига не валидные. Название синонимом не является, символ в составе более общей статьи не рассматривется. Семантика нарушена. Там, где не нарушена, я ничего против не имею. ~Facenapalmобс, вкл23:08, 24 апреля 2016 (UTC)
Вообще, давайте я формализую свою позицию, которую уже высказывал неоднократно: редирект с юникодного символа на статью возможен только в том случае, если в этой статье рассказывается про этот юникодный символ. Перенаправление с символа на его значение (😂 -> Смех, что обсуждалось по ссылке) — это что-то на уровне ОРИССа. Есть кто не согласен? ~Facenapalmобс, вкл19:52, 23 апреля 2016 (UTC)
Я видел это обсуждение, но ничего не сказал, потому что ничего нового сказать не смог. Раз меня позвали, повторю старое: я против удаления перенаправлений, потому что они могут использоваться где-нибудь вне Википедии. С другой стороны, перенаправление именно ❶ именно на число 1 действительно не выглядит убедительно. На что его перенаправить (кроме блока Юникода), я не знаю. Vcohen21:45, 23 апреля 2016 (UTC)
Всем привет. Если кого-то интересует моё мнение, то скажу следующее: то, что пытается довести топикстартер является верным. Я Против того, чтобы все эти перенаправления вели не туда куда следует! То есть цифорки в кружочках не должны вести на обычные арабские цифры, для этого куда уместнее создать статью о соответствующем блоке Юникода, либо написать статью Цифры в круге, где подробно и с помощью АИ нужно указать где, как и для чего эти символы используются. Перенаправления со шляпы и овала меня вообще убивают. Они должны вестись или на Эмодзи или на Смайлы (Юникод). Поэтому я поддерживаю идею о их удалении. @1234qwer1234qwer4, Vcohen: вы же понимаете, что у нас-то и сами статьи о символах многие подпажают под КБУ, их нужно тоже переписывать, а тут речь аж зашла о редиректах этих символов. Вот когда мы создадим соответствующие статьи о блоках, статьях об этих символах (да хоть даже это будет Эмодзи-символ шляпы), вот тогда будет правильно. А когда вписываешь какой-то символ математический, и он ведёт куда на маттермин, где его даже тупо поиском не найти в статье — очень плохо. Я несогласен с топикстартером лишь в одном: то, что эти символы Вы не можете вводить со своей клавиатуры или «даже не во всех браузерах отображаются» совсем не повод для их несуществования. Для этого у нас есть изображения (для наглядности правильного отображения символа), шрифты и шаблон {{спецсимволы}}. ← Alex Greatобсуждение04:48, 24 апреля 2016 (UTC)
Всё-таки надо понимать юзкейсы. Часто пытаешься, скопипейстив символ (математический, например; какой-нибудь ∩; ср. w:∩), понять таким образом, что он означает. И такая статья будет, конечно, не о самом символе, а о его означаемом. Иной раз более правильный путь — не удалять редирект, а дописывать статью, дополняя информацией о символе, если ей есть место. А если символ является заменой другого символа для некоторых письменностей (например, как я ткнул пальцем в небо для сабжа), то они вполне могут редиректить на символ, который они заменяют, до того, как о них создана самостоятельная статья. — Джек, который построил дом10:47, 24 апреля 2016 (UTC)
This is a redirect from a symbol to the meaning of the symbol or to a related topic. For more information follow the bold category link.
This is a redirect from a single Unicode character to an article or Wikipedia project page that names the character and describes its usage. For a multiple-character long title with diacritics, use template {{R from diacritics}} instead. For more information follow the bold category link.
∩ — это не то, о чём я говорю. Ты копипастишь символ, и попадаешь в статью, где рассказывается о том, где этот символ используется. Ну, не конкретно этот символ, а знак, который на нём изображён. И этот символ хотя бы в статье присутствует. Это — хорошее перенаправление. И семантически правильное. Правда, тут возникает вопрос: а почему именно перенаправление идёт на математический термин, а не на статью, в рамках которой рассказывается об этой юникодной группе? Если обе такие статьи существуют, можно создавать дизамбиг. Или шаблон {{redirect}} вешать, как минимум. А теперь другой use case: видит пользователь квадратик, являющийся на деле 👒, копирует в поиск и его перенаправляет на статью Шляпа. В которой вообще ничего о символе «👒» не говорится. Просто шляпа. Как это понять?
Ок. Мой посыл был в том, что редиректы на означаемое, а не означающее, вполне легитимны. Ну, квадратик это его проблема. Читать о символах Юникода — это всё-таки обычно не то, что нужно людям. Я бы рассчитывал по запросу «∩» попасть как раз на математическое понятие, им обозначаемое. — Джек, который построил дом18:48, 24 апреля 2016 (UTC)
Возвращаясь к тому, с чего началась тема: является ли «❶» синонимом единицы? Если да, то почему? Почему, в частности, в статье об единице тогда ничего о символе «❶» не сказано? Если нет, то зачем редирект? ~Facenapalmобс, вкл11:45, 24 апреля 2016 (UTC)
Точно тоже самое можно сделать с этим символом исправив редирект так, чтоб он вёл на статью не о цифре 1, а, к примеру на статью о монете, рубле, центе, медальке золотой и т.п. Что действительно некорректно. Если брать конкретно этот символ, то либо на статью о «цифрах в круге» либо Юникод-блок. Что тут думать-то? ← Alex Greatобсуждение12:36, 24 апреля 2016 (UTC)
Но надо быть уверенным, что нет языка, в котором традиционно цифры пишутся в круге, и ❶ есть точный перевод 1. Тогда прибавляется ещё один кандидат на редирект. — Джек, который построил дом18:48, 24 апреля 2016 (UTC)
Даже если такой язык есть, перенаправление, как я уже говорил, бесмысленно, пока об этом ничего не говорится в статье, на которую идёт редирект. ~Facenapalmобс, вкл18:57, 24 апреля 2016 (UTC)
А если язык, в котором это так, дико маргинален и не заслуживает упоминаний? Место в статье ценно, а редиректы дёшевы. Часто вижу в англовики категории, не подкреплённые текстом статьи, и такие же редиректы. Путает, но не смертельно; хотя бы даёт зацепку. — Джек, который построил дом19:06, 24 апреля 2016 (UTC)
Категорически с тобой не согласен. Нужно давать пользователю понять, почему он вдруг оказался в другой статье, хотя бы в общих чертах, хотя бы бездушным шаблоном уровня «юникодные символы, содержащие цифры, перенапарвляются сюда; на эти темы нужны отдельные статьи». Категории, не подркреплённые текстом статьи, вообще правилам противоречат, если не ошибаюсь. Ладно, послушаем ещё мнения. ~Facenapalmобс, вкл19:28, 24 апреля 2016 (UTC)
Что-то обсуждение шло долго и общими словами, а потом и вовсе затихло. Давайте так: если за неделю не появится аргументированных голосов «против», все редиректы из поста, а также редиректы с аналогичным нарушением семантики, вроде 👒, выставляются на КБУ или сразу удаляются ботом. В противном случае надо как-то правила редактировать, чтоль, а то эти редиректы в них не вписываются. ~Facenapalmобс, вкл11:50, 1 мая 2016 (UTC)
Я против. Типичная борьба с ветряными мельницами. Редиректы не занимают места. В таких случаях вообще появление вопроса «а кому они могут понадобиться» — признак того, что обсуждение пошло в неверном направлении. В Юникоде эти значки есть, значит «это кому-нибудь нужно»; наши знания ограниченны; у нас тут не экспертное обсуждение, а гадание дилетантов на кофейной гуще. Если нет заведомо нарушенной семантики — вреда в них нет, а польза, как я уже сказал, — снятие языковых ограничений и уменьшение эффекта Вавилонской башни. В случае с цифрами — меньше работы с текстом при копипейсте.👒 — это женская шляпа, перенаправляет на шляпу. В статье Шляпа есть упоминание женской шляпы. Всё легально. На en:Dingbat со значков этого юникодного блока редиректы на статьи об их означаемых, никому не мешающие. — Джек, который построил дом12:12, 1 мая 2016 (UTC)
Замечу, что я на аргументы «а кому они могут понадобится» не напирал, это скорее замечание. ВП:ПН: «в любом случае понятие, с названия которого осуществляется перенаправление, должно быть упомянуто и объяснено в статье, на которую это перенаправление указывает»; ВП:КБУ: «[удаляется] перенаправление на статью, название которой не является синонимом для термина, представленного названием перенаправления, и статья не описывает полностью этот термин в составе более общей статьи». Надо тогда правила редактировать, потому что обсуждаемые перенаправления под них не попадают. ~Facenapalmобс, вкл12:37, 1 мая 2016 (UTC)
ВП:ПН — руководство, а не правило. Смысл цитаты на КБУ в том, что термин должен либо быть синонимом заглавия, либо описываться внутри статьи (то есть быть релевантным статье в целом). Очевидно, что редирект с ✈ на Самолёт не является семантически некорректным перенаправлением (и непонятно, кому мы жизнь облегчим, если его удалим).Требование в ВП:ПН довольно бессмысленное и устаревшее, отдающее instruction creep'ом. Не вижу его аналогов на en:Wikipedia:Redirect#When should we delete a redirect? — Джек, который построил дом13:03, 1 мая 2016 (UTC)
Вопросы удаления не касаются технического форума. Спрашивали для чего могут быть нужны такие перенаправления, а собираетесь подвести итог КБУ. Для обсуждения удаления есть ВП:КУ, а не взваливайте такую ответственность на горстку заглянувших на тех.форум. --Hrum-Hrum12:32, 1 мая 2016 (UTC)
Редактирование Википедии в Sublime Text 3[править код]
Позавчера стал возможным предпросмотр правок без внесения изменений на вики-сайт при редактировании его в Sublime Text 3. Как это работает, расписал здесь. Править Википедию через эту программу с помощью плагина Mediawiker теперь очень удобно. Спасибо.--AnimaAWB19:11, 22 апреля 2016 (UTC)
Не все люди — счастливые обладатели FullHD мониторов, остальные не всегда сидят в интернете с них. На бюджетных ноутбуках самая распространённая ширина экрана — 1366, например. ~Facenapalmобс, вкл12:27, 22 апреля 2016 (UTC)
Так чем меньше ширина монитора, тем меньшую долю высоты всей статьи будет занимать карточка же (потому что сама статья будет удлиняться, а карточка - нет). MaxBioHazard14:32, 22 апреля 2016 (UTC)
Может, развернуть сам файл на 90 градусов? Вертикальная картинка будет смотреться в данном месте статьи лучше, чем горизонтальная. --VAP+VYK12:21, 22 апреля 2016 (UTC)
Shared tabular data storage for Commons![править код]
CCing from commons, please participate there as this will be a cross-wiki shared feature. Please translate.
During the last hackathon I created a new on-wiki tabular storage described in T120452, similar to CSV and TSV formats. It allows any user to create a page, e.g. "Data:List of interesting facts.tabular" (demo), and keep it as a table, rather than wiki text. Tabular storage allows strings, numbers, Booleans (true/false), and "localized strings" – a string that has different value depending on the language. Additionally, tabular data stores metadata, such as description (localized) and license. More metadata can be added as needed.
Tabular storage greatly simplifies storing data for lists, tables, and graphs. Graphs may directly access tabular data, and on-wiki tables and lists can be created by using simple Lua scripts. This storage is fundamentally different from Wikidata, because it works with "blobs" (batches) of data, whereas Wikidata works with tiny "facts". Wikidata technology is simply not suited for large storage such as the list of the most expensive paintings, the shoe size comparisons table, or data to plot Moscow subway growth graph.
After a long discussion, it seems Commons is the best fit for such data. Commons community already has good experience with international multi-licensed content. The current proposal is to create the data namespace on Commons, and use it from all of the wikis.
Technical notes: When storing, the data is validated and stored as JSON, so there are no delimeter problems common to the traditional CSV/TSV files. At this point, the wiki editor shows tabular data as a JSON, but very soon I hope to have a CSV/TSV editor to simplify copy/pasting, and afterwards – a full scale spreadsheet table editor. Eventually, I would also like to implement Q number support, allowing direct links to Wikidata. --Yurik21:09, 19 апреля 2016 (UTC)
Здравствуйте! Я задал этот вопрос на форуме Википедия:Запросы к ботоводам, но там переадресовали сюда, заявив, «Категоризация может быть провеедена автоматически путём соответствующей доработки шаблона».
Суть вопроса:
Существует замечательная Категория:Персоналии по языкам, но она очень неполная. Если в статьях, имеющим Шаблон:Писатель заполнены параметры "Язык произведений" и "Род деятельности" дополнить вложенные категории, а именно: если "Род деятельности" - Поэт или Поэтесса ► Поэты по языкам; Драматург ► Драматурги по языкам; Переводчик ► Переводчики по языкам. Поэты, драматурги, переводчики и литературные критики также являются писателями, но их почему-то не включают в категорию "писатели", оставляя там прозаиков, поэтому если "Род деятельности" - Прозаик, то в ► Писатели по языкам. Для литературных критиков нет категорий по языкам, нужна или нет я не знаю. В этом же шаблоне иногда встречаются журналисты-публицисты — их ► Публицисты по языкам. Возможно ли это сделать используя шаблоны? Если да - пожалуйста сделайте. Заранее спасибо. С уважением, 13:20, 19 апреля 2016 (UTC) And S Yu
Хочется настройку, которая бы расставляла список категорий внизу страницы по алфавиту. Иногда такие объёмные списки, что совершенно в них теряешься. — Igel B TyMaHe09:45, 19 апреля 2016 (UTC)
А что нестабильного в моём коде? Я скорее хвастаюсь своим незнанием jQuery. :) Хотя особых преимуществ его использования в десятистрочном скрипте не вижу. ~Facenapalmобс, вкл12:52, 19 апреля 2016 (UTC)
Он ломается при любом минимальном изменении разметки. В частности, перестаёт работать при включённом HotCat’е. Ну, и говоря о преимуществах, сортировка тегов прямо в DOM’е страницы — это очень смело. — putnik16:27, 19 апреля 2016 (UTC)
«В частности, перестаёт работать при включённом HotCat’е» — аргумент, не учёл. Вот только аргумент не в сторону jQuery, а в сторону продуманности твоего скрипта. Хотя я предупредил, что мой сделан на скорую руку. По поводу сортировке тегов прямо в DOM’е — большой вопрос, что производительней: она или одна смена innerHTML. Тем более, что innerHTML ещё и привязанный JS теряет, если он был. А других способов я не вижу. ~Facenapalmобс, вкл16:43, 19 апреля 2016 (UTC)
Начать с того, что слова на форуме "Общий · Новости · Вопросы · Предложения · Правила · Технический · Вниманию участников | Skype · IRC
Администраторов · Оспаривание итогов · Оспаривание админдействий · Технические админзапросы" показываьюся втри раза меньше, чем све остальные буковы. И тоже самое в окне редактирования, как мелкий шрифт в банковских договорах. А для каждой правки менять шрифт, а потом обратно менять после- ибо буквы в статье становятся огромными- напрягает. Что-то можно с этим сделать? --S, AV☎18:37, 18 апреля 2016 (UTC)
Да тут, как я понимаю, проблема была принципиально в другом. Заменил размер текста в шапке на относительный: стало лучше? Возможно, придётся сбросить кэш. ~Facenapalmобс, вкл22:08, 18 апреля 2016 (UTC)
Стало получше, но я ушел на Мозилу. Лучше на нем косячном, чем в мегабыстром Гугле. Потом если не поленюсь - выложу как в нем отображается. Теперь я понимаю ненависть людей к шаблонам. Все они небось в Хроме сидят и это реально жуть. Сайт созданный дошкольником будто. --S, AV☎09:07, 19 апреля 2016 (UTC)
Получается, что у нас все выборы держатся на одном участнике? Как-то это неправильно с точки зрения отказоустойчивости. 109.172.98.6913:03, 23 апреля 2016 (UTC)
А у меня чисто теоретический вопрос: существует ли техническая возможность провести тайные выборы (не эти, а вообще)? И есть ли опыт тайных выборов в каких-нибудь других интервиках? Alexei Kopylov08:13, 21 апреля 2016 (UTC)
@Schekinov Alexey Victorovich:Сделано. Шаблон будет добавлять статьи в две категории. При его использовании в других пространствах имён добавление не произойдёт. Если статью добавлять в категории не нужно, используйте параметр nocat с любым непустым значением: {{композиторские школы|nocat=1}}. Но не лучше ли включать статьи с этим шаблоном в одну категорию «Композиторские школы», а её сделать подкатегорией категории «Школы в музыке»? Гамлиэль Фишкин11:23, 18 апреля 2016 (UTC)
Лучше. Только условность деления подсказывает мне, что скоро одна из категорий будет удалена. Оставляю выбор за вами и спасибо) --S, AV☎11:40, 18 апреля 2016 (UTC)
Отдельное спасибо будет тому, кто поможет тут. На выбор: классическое спасибо, спасибо большое или огромное спасибо. --S, AV☎12:43, 18 апреля 2016 (UTC)
Шаблоны задают margin-top, у первого по умолчанию 2em и есть 6600 включений, у второго — 0.5 em и 200 включений. Очень часто используются перед навигационными таблицами в конце статьи, при этом у навигационных таблиц уже задано .navbox: margin-top: 1em и визуально почти ничего не меняется. Нужно ли такое использование? Ardomlank17:56, 17 апреля 2016 (UTC)
Как я заметил на РДБ, когда немалая доля (тысячи 3) этих шаблонов была удалена вместе с «вельдами», вот, скажем, тут{{^|1em}} стоит перед ambox'ом, CSS-правил для которого в таких случаях нет (в англовики тоже, кстати), и вроде как он уместен.Не исключаю, что такое большое число в 6600 может происходить оттого, что этот шаблон включён в какой-то другой шаблон или шаблоны, а не только связано с использованием перед навшаблонами (где они, конечно же, не нужны больше). — Джек, который построил дом18:39, 17 апреля 2016 (UTC)
Уважаемый коллега Dima st bk, по Вашему предложению я реализовал на тестовой подстранице шаблона {{НП}} возможность задавать развёрнутое или свёрнутое состояние карт, со свёрнутыми по умолчанию картами в статьях меньше 10 килобайт и с развёрнутыми по умолчанию — в статьях большего размера. Однако в коде шаблонов {{НП}} и {{НП+}} я вижу другое: возможность задавать состояние карт есть только в статьях меньше 10 килобайт, в статьях же большего размера карты неизбежно отображаются развёрнутыми. Зачем? Как видите, редакторам Википедии возможность сворачивания карт нужна не только в маленьких статьях. Гамлиэль Фишкин13:16, 18 апреля 2016 (UTC)
Коллеги, эти шаблоны-костыли участника ɪ чинят наползание маркеров на изображения в старых версиях Оперы: в версии 11.64 получается [6] -> [7]. Можно сделать это нормально, чем-то вроде добавления параметра list-style-position:inside к тегу li в MediaWiki:Common.css? Кстати, при размещении картинок слева маркер сползает чуть влево даже в последней версии Chrome — и с шаблоном, и без. Ardomlank15:59, 17 апреля 2016 (UTC)
Используйте специальный шаблон лучше. Вот так и читается проще, и не запутаешься. Не знаю, почему конкретно ваш код не работает в хроме и в каком хроме конкретно, надо читать спецификации CSS3 и смотреть, какие браузеры их поддерживают. Для старых хромов есть -webkit-column-count ещё. Но чтобы с этим всем не долбаться, проще вставить шаблон. ~Facenapalmобс, вкл12:06, 17 апреля 2016 (UTC)
Да почти у любого CSS-свойства есть такие же с префиксами. Это нормально, так веб устроен. Сначала какой-то браузер делает клёвую фишку с префиксом, потом все браузеры реализуют так же, потом это стандартизуется. ~Facenapalmобс, вкл15:28, 17 апреля 2016 (UTC)
А есть у «КОЛ» какой-нибудь англоязычный вариант, чтоб во всех разделах работал? Я бывает им тож правлю. Скажем, у нас я шаблон сделал, а у кое-кого на западе не худо бы на пару-тройку столбцов завернуть. --S, AV☎16:26, 17 апреля 2016 (UTC)
Извините за оффтоп, и да извинят меня участники-белорусы, но почему-то рассмешил их вариант. Со всем уважением к вашему языку и культуре. Извините. Такой примитивный тупой юмор. The-city-not-present17:37, 17 апреля 2016 (UTC)
Ну уж очень тупой юмор. :) В белорусском просто все безударные «о» пишутся как «а». Видимо, сокращение от «калонка», или чего-то подобного. ~Facenapalmобс, вкл23:16, 17 апреля 2016 (UTC)
В статье искаженно отображается последняя таблица. По-видимому, суть вот в этом сообщении — «Предупреждение: суммарный размер включаемых шаблонов слишком велик. Некоторые шаблоны не будут включены.», которое выдаётся при редактировании. Надо разбивать статью? Или есть другие рекомендации ? --Aesopus14:31, 15 апреля 2016 (UTC)
Там так просто — без знания источника — может быть, и не получится починить. В одном месте сноска такая:
<ref name="NewGrove">''New Grove Encyclopedia of Music'', pg. 664</ref>
В другом — на диапазон страниц:
<ref name="NewGrove">''New Grove Encyclopedia of Music'', "Italy", pp 637-680</ref>
Это-то можно исправить переименованием сноски. Но вот относительно десятка повторных сносок (<ref name="NewGrove" />) не ясно, что из этого подразумевалось. --INS Pirat17:42, 15 апреля 2016 (UTC)
Проблемы англовики решать в англовике, у нас использовать вторую сноску, так как диапазон pp. 637-680 включает и p. 664. Если принципы не позволяют, искать New Grove Encyclopedia of Music и лично проверять написанное. — Igel B TyMaHe19:38, 15 апреля 2016 (UTC)
Просто избранная статья ведущего раздела, я надеялся, что кому-то не безразлично. В принципе вполне бы устроило если бы носитель языка пинганул им через "сообщить об ошибке". --S, AV☎20:10, 15 апреля 2016 (UTC)
«(Зачем там вообще карта, парк наполовину лежит в Польше)» — заменил, имхо, на «более подходящую» («геополитически нейтральную»). Pticy uleteli07:31, 14 апреля 2016 (UTC)
Точно так же ведёт себя и <ref>. Решение простое, хоть и не очень красивое — обернуть неразрывный фрагмент в шаблон {{nobr}}: к 1230 {{nobr|году{{sfn|Gullick|2007|p=10}}.}}. — Vort08:25, 13 апреля 2016 (UTC)
Вероятно, для преамбул так стоит делать. А у разработчиков никто не запрашивал, чтобы после <ref> точка не переносилась?--SEA9908:39, 13 апреля 2016 (UTC)
Попробовал разобраться в том, что происходит на уровне HTML, и обнаружил интересную особенность: Internet Explorer точку не отрывает. Так что проблема вполне может быть на стороне браузеров или даже в стандарте HTML. — Vort09:51, 13 апреля 2016 (UTC)
По-хорошему, под {{nobr}} должно быть и число перед годом, а ещё лучше и предлог к, но это уже не с технической, а с оформительской стороны. --windewrix10:18, 13 апреля 2016 (UTC)
Получается, что метод не универсален — каждый браузер ведёт себя по-своему (у меня на Opera 12.18, к примеру, шаблон в этом примере работает как надо, а вот логику Chrome`а я понять не могу — в большинстве случаев всё нормально [и без шаблона], да только не всегда). — Vort12:44, 13 апреля 2016 (UTC)
Здравствуйте. Возникла некоторая проблема, обратился на общий форум, и меня направили сюда. Поэтому продублирую запрос.
Хотел подставить шаблон «древний город» в статью о Тигранакерте, но там вместо стандартной карты с контуром страны, на территории которой в наши дни находится город, появляется карта древней Армении с провинциальным делением. А вот в примере прилагаемой к шаблону документации, Эрибуни, выводится иная карта — Армянское нагорье без политических границ. Или иной пример — Гекатомпил. Там вообще выводится физическая карта мира. Возможно ли с этим как-то бороться? — 2.133.85.005:02, 13 апреля 2016 (UTC)
Нашёл источник, кажется. Видимо, позиционная карта задаётся вместе с параметром «страна», указывающим политическую принадлежность древнего города, а не как в англоязычном шаблоне «Ancient site» — отдельным параметром «map_type». Может кто-то с достаточными знаниями исправить это? — 2.133.85.006:24, 13 апреля 2016 (UTC)
copyWikilinks.js — скрипт для копирования вики-ссылок[править код]
Из выполнения просьбы Ardomlank убрать текст «[править | править вики-текст]» из скопированного заголовка страницы в третьей итерации вырос полноценный скрипт.
copyWikilinks.js
С ним можно простым нажатием клавиш добывать вики-ссылки для текущей страницы и раздела, а также для ссылок. Больше не надо никуда прокручивать и вручную выделять заголовок страницы или раздела; достаточно нажать:
ctrl+ё, чтобы получить всплывающее окошко, из которого можно скопировать вики-ссылку на текущую страницу;
ctrl+⇧ Shift+ё, чтобы получить всплывающее окошко, из которого можно скопировать вики-ссылку:
если курсор мыши находится над ссылкой на вики-страницу — на эту страницу;
если курсор мыши находится не над ссылкой — на раздел текущей страницы, над которым находится курсор (не обязательно над заголовком; лучше поместить курсор над текстом).
Всплывающее окошко затем убирается по нажатию Esc.
В качестве бонуса по нажатию alt+ё работает преобразование ссылок, содержащихся в выделенном тексте или перед курсором, в вики-ссылки. Если у вас установлен гаджет упрощения ссылок — скрипт вызывает его; в обратном случае использует собственный алгоритм, который несколько более прост, чем алгоритм гаджета. Если текст выделен на странице, а не в области редактирования, то всегда используется собственный алгоритм.
При этом на страницах истории, диффов и т. п. скрипт по нажатию ctrl+ё предлагает скопировать раскодированный URL, а не вики-ссылку.
Для установки скрипта добавьте в свой common.js:
importScript('Участник:Jack who built the house/copyWikilinks.js');
У скрипта есть настройки (записываемые как var переменная = значение;:
copyWikilinksSqBrackets — окружать ли вики-ссылки двойными скобками (по умолчанию true);
copyWikilinksSingleSqBrackets — окружать ли простые ссылки одинарными скобками (по умолчанию true);
copyWikilinksUseUrlDecoder — использовать ли гаджет упрощения ссылок для выделенного текста в области редактирования (в обратном случае — всегда использовать собственный алгоритм; по умолчанию true);
copyWikilinksHomePrefix — префикс (без двоеточий) родного раздела, который не будет включаться в вики-ссылки (по умолчанию 'ru').
Скрипт работает и в других разделах (при этом выдаёт вики-ссылки с соответствующим префиксом, например :en: в англовики), используйте код:
Прошу сообщать мне о багах. Работа скрипта проверялась в Хроме, Фаерфоксе и ИЕ. Если вы умеете работать с JavaScript, сочетания клавиш можно поменять на другие (ищите по коду 192 и заменяйте на номер клавиши, который можно узнать здесь, введя в текстовое поле справа и посмотрев на нижнюю цифру, с остальным разберётесь).
Пока скрипт тестируется, просьба на форум новостей не переносить. Пинги пользователям прошлых версий: @Igel B TyMaHe, Luterr, Olgvasil.
Ага, значит префикс tools использовать небезопасно — знаки вопроса в адресе превращаются в %3f. Про «Эйяфьядлайёкюдль#Примечания» — парадокс. Скрипт ищет первый тег заголовка по дереву выше элемента с :hover, то есть если он это выдавал, значит либо какое-то, возможно невидимое, содержимое этого раздела заслоняло страницу, либо он неверно интерпретировал это :hover. — Джек, который построил дом20:40, 12 апреля 2016 (UTC)
Зачем нужны кнопки OK и Cancel? Нельзя ли их убрать? Или сделать, кнопку, которая копирует ссылку в буфер.
Было бы естественно, чтобы ctrl+⇧ Shift+ё на страницах старых версий действовала так же как и ctrl+ё, например, если хочется получить ссылку на раздел в старой версии.
Хорошо бы, чтобы ссылка на раздел, создавалась в виде: [[Статья#Раздел|раздел]] (всё равно голые вики ссылки на раздел почти никогда не используются).
Ещё хорошо бы, чтобы при нажатии ctrl+⇧ Shift+ё на ссылку куда-то, получалась ссылка с этим же текстом: [[ВП:Заглавная страница|ссылку куда-то]].
Хорошо бы, чтобы можно было бы настроить, чтобы при копировании ссылки с иноязычного раздела, создавался бы шаблон {{нп5}}.
Нельзя ли в выпадающее меню добавить пункт "скопировать викиссылку"? или javascriot этого не позволяет?
Кнопки «ОК» и «Отмена» специально не программировались, а вшиты намертво в стандартное всплывающее окошко, которое вызывает функция prompt(). В теории можно создать собственный дизайн всплывающего окошка и даже реализовать функцию его автоматического закрытия при копировании, но предполагается, что Esc нажать нетрудно, коли руки уже на клавиатуре. Я пользуюсь подобным функционалом в личных целях при обычном сёрфинге, меня не напрягает. Кнопку, которая копирует ссылку в буфер, реализовывать будет очень напряжно, учитывая, что браузеры не предоставляют стандартных средств для копирования в буфер, видя в этом проблему безопасности. К тому же зачем кнопка, до которой надо тянуться мышью, если руки уже на клавиатуре?
Отдаю дань величию замысла. Не знаю, удастся ли соответствовать. Мне и старая версия нравится. Спасибо за Ваш труд! А пинг "на троих" не работает. С уважением, --Olgvasil19:54, 13 апреля 2016 (UTC)
Да, пинг не прошел. Спасибо, за ваш труд, наконец-то такая полезная функциональность реализована. --Luterr13:06, 2 мая 2016 (UTC)
У меня пинги проходят, но я пока не готов воспринимать новый функционал. Пользуюсь первоначальным тройным кликом и радуюсь. — Igel B TyMaHe13:27, 2 мая 2016 (UTC)
@Alexei Kopylov: Выпустил обновление. Реализовал пункты 2, 4, 5. Для работы 4-го пункта пропишите var copyWikilinksUseLinkText = true;. Для работы 5-го пункта пропишите var copyWikilinksUseIwTemplate = true; (вставляет шаблон {{iw}}, если нет русской интервики). Скрипт серьёзно переработан, встретите баги — пишите. Также теперь по умолчанию обычные (не вики-) ссылки копируются тоже с квадратными скобками. — Джек, который построил дом23:39, 28 апреля 2016 (UTC)
Хорошая задумка, одна проблема: я использую самопальную Бирмановкую раскладку, где [ повешен на AltGrey+х, а ] на AltGrey+ъ и так далее. И этот скрипт вызывается каждый раз при наборе символа! Причём даже просто Бирмановских символов, не добавленных мной, AltGrey+(жэбю), тоже выбрасывают окно. Можно это пофиксить? --Meliriusобс01:24, 23 апреля 2016 (UTC)
@Melirius: У меня самого бирмановская раскладка, проблема была не в ней. Оказалось, что это следствие проблемы Фаерфокса (у вас ведь он?), который по непонятной причине при нажатии «ё» определяет код клавиши как 0. Опрометчиво было думать, что так он делает только с «ё». Перенастроил слушатель событий, теперь реагирует на сами символы Ё, ё, ~ и `, проверяйте. — Джек, который построил дом23:39, 28 апреля 2016 (UTC)
@Jack who built the house: Спасибо. Меня от перехода на новую версию останавливает необходимость держать в голове эти комбинации клавиш (я не ежедневно такие ссылки ставлю, каждый раз придется в инструкцию глядеть). --Olgvasil12:35, 2 мая 2016 (UTC)
Около недели назад начались кое-какие проблемы с мобильной версией сайта — невозможно править статьи. Всё это время думал, само пройдёт, но решил таки написать сюда. Что скажете, коллеги? —Лука Батумец14:17, 12 апреля 2016 (UTC)
Здравствуйте, коллеги! При применении данного шаблона страницы относятся к категории Категория:Населённые пункты по годам основания. Однако, ключ сортировки шаблона предполагает применение только четырёхзначных годов, в результате, все города, основанные в первом тысячелетии или до нашей эры, например, в 985 году нашей эры, или в 43 году до нашей эры, идут в категории в самом конце, после 2015 года, что не слишком облегчает поиск по категории. Хотелось бы решить данный вопрос. --Ksc~ruwiki 13:33, 12 апреля 2016 (UTC)
Я так один год пытался проставить. Толка нет. Выходит, на полосе с годами, скажем 984 год (пустой), 986 год (пустой) и между ними 0985 год. Выглядит нелепо. Надо либо шаблон переделывать, либо просто подождать. В данном случае, наверное, лучше подождать. --Ksc~ruwiki 16:58, 12 апреля 2016 (UTC)
Насколько понимаю, изменения внесены, но лучше не стало. Стало по-другому плохо. Теперь сортировка идёт так: в 1, 10, 100, 1000, 2, 20 и т. д. году. Что так же выглядит странно. Или это пока какое-то промежуточное решение?--Ksc~ruwiki 13:02, 18 апреля 2016 (UTC)
Есть пользователськая подстраница (subpage), также называемая Участник:Yanpas/Синтаксис Си. Переводить я передумал, следовательно надо бы удалить, да только в справке тут и тут по этому поводу ничего не сказано. Подскажите как правильно и, пожалуй, добавлю эту информацию в справку :) Yanpas19:51, 11 апреля 2016 (UTC)
Добрый всем день. Столкнулся со следующей проблемой. В статье Ротинян, Левон Александрович есть источник № 8 (Национальный архив Армении, сборник документов. Ротинян, Л. А. стр. 121, 291) вот ссылка.
Если я его нежно вставляю в статью, то все работает из статьи.
Но если кто то отредактирует целиком статью, даже без викификации, то уже ссылка отдает код 403.
Если я её "опять нежно вставляю" - опять работает.
Что делать то, кроме архивирования?
Еще в чем "шайтан"... Если в браузере (в моем случае Мозила для Мак) отдало 403 по ссылке из статьи и прямо в этом же окне откопировать ссылку и вставить в новое окно браузера - опять работает...
Ну что за дела, никто не знает? Svkov219:20, 9 апреля 2016 (UTC)
Видимо, на сайте установлена какая-то проверка Referer (наподобие защиты от хотлинкинга изображений). Если Referer пуст или содержит имя сайта www.armarchives.am — доступ есть, в противном случае нет. (Пробелы в имени файла роли здесь не играют.) —Sauron (о⬩в) 19:43, 9 апреля 2016 (UTC)
Ну сейчас то с форума реферер другой, да и в статье тоже. А то работает, то нет. Вернее стабильно работает до редакции статьи. Как только её кто то отредактирует - перестает работать. Svkov219:46, 9 апреля 2016 (UTC)
Ну у меня без параметра 403, а с параметром нормально. Вообщем бог с ней с этой ссылкой, вернее с сайтом этим ненормальным "Армянского архива". Я её заархивировал и она доступна в статье - и ладно. Svkov211:02, 13 апреля 2016 (UTC)
Я её нашел "внешним поиском". То есть не знаю - есть ли вообще такая ссылка на сайте. Там вообще какой то поиск "не работающий"... Svkov214:32, 13 апреля 2016 (UTC)
Сделано Больше ссылок на Библейскую энциклопедию в Яндекс-словарях нет. Я молодец, хочу печеньку, кофе, орден, будёновку, шашку и барабан! S, AV☎14:16, 8 апреля 2016 (UTC)
Невозможно откатить последние изменения страницы «HD 20782 b», совершённые 178.234.56.233 (обсуждение | вклад), поскольку кто-то другой уже успел откатить эти правки или отредактировать страницу.
Последние изменения внёс 178.234.56.233 (обсуждение | вклад).
Это происходит, когда участник сначала вносит изменения, а потом следующей правкой их убирает, как и получилось в статье HD 20782 b: [10]. Это нормальное поведение движка MediaWiki, просто сообщение об ошибке вводит в заблуждение. -- Q-bit array09:49, 8 апреля 2016 (UTC)
Я только что посмотрел его код. Зря я это сделал. Должно стать так - w:Template:CSS image crop. А по поводу примеров: в первом у меня и там и там криво смотрится, во втором, третьем и четвертом всё одинаково. С уважением, Iniquity21:59, 7 апреля 2016 (UTC)
Кроп изображения делается меньше чем за минуту в окне браузера при помощи CropTool. Нужно просто перестать городить эти костыли с шаблонами. — putnik10:32, 8 апреля 2016 (UTC)
@putnik:, в том то и вся суть, некоторые изображения очень полезны необрезанными, а мы их фактически спрячем от читателя отдельным файлом. Уверен, что мало кто до оригинала доберется, особенно учитывая как работает наш любимый просмотрщик фотографий. Хотя в целом вопрос спорный. Я еще сам не определился с окончательным «как будет лучше». С уважением, Iniquity12:55, 8 апреля 2016 (UTC)
@Iniquity: Плюсы кропа: получается изображение, которое без проблем работает в любом представлении Википедии, включая мобильное, оффлайн-приложения и печатную версию; полученное изображение можно сразу использовать во всех разделах и может быть добавлено в Викиданные. Минусы кропа: кто-то не догадается нажать огромную синюю кнопку и поэтому не сможет найти оригинальное изображение. Ну ок, вопрос действительно спорный. — putnik13:13, 8 апреля 2016 (UTC)
putnik, ага, сначала огромную синюю, потом найти в самом последнем шаблоне маленькую строчку с оригинальным файлом. Еще идеи? С уважением, Iniquity14:48, 8 апреля 2016 (UTC)
putnik Если бы была возможность транслировать информацию из шаблона о кропе в «просмотрщик фотографий», то тогда да, шаблон был бы бесполезен. С уважением, Iniquity20:14, 8 апреля 2016 (UTC)
Бесят всякие технические нововведения в Вики. Вот для статьи Орстхойцы нужно поставить интервику Arshtins. Раньше я бы это сделала за 3 секунды. Сейчас потратил 3 минуты и не разобрался. Если кто-то улучшает Вики, может он задумается о том, что здесь не все фанаты разбираться с техническими моментами!? Помогите пожалуйста поставить эту интервику. --АААЙошкар-Ола18:59, 6 апреля 2016 (UTC)
В отличие от написания статей, способ проставления интервики — дело десятое. Тем более, что для пользователя рувики разницы не будет никакой. А ещё у нас есть бот, который занимается переносом интервик на викидату. Некоторые проблемные интервики я сам время от времени переношу. ~Facenapalmобс, вкл15:22, 7 апреля 2016 (UTC)
Если для вас интервики — это только ссылка в левом меню, то действительно дело десятое. Только вот не будет ни ссылок на другие проекты, ни данных из Викиданных, ни обратных ссылок. — putnik16:05, 7 апреля 2016 (UTC)
Ладно, в общем случае соглашусь, викиданные предпочтительнее. Конкретно в этом случае — один хрен для рувики. В английской на викиданных ничего полезного не было, и всё, что мы потеряли бы при простановке интервики — ссылки с английской версии статьи на две другие. ~Facenapalmобс, вкл20:04, 7 апреля 2016 (UTC)
@АААЙошкар-Ола:Оно и сейчас делается за 3 секунды, так что не надо необоснованно наезжать на кого-то там. У статьи без интервик слева вместо интервик есть ссылка "Добавить ссылки", по щелчку на которую вылезает окошко, где надо указать раздел (читай тот же код интервик, что и раньше) и статью. Если интервики уже есть, будет ссылка "редактировать ссылки", откровется страница викиданных, где интервики представлены в правом углу страницы, редактирование элементарно. --Sigwald15:41, 7 апреля 2016 (UTC)
Вы просто не в курсе. Вы мне дали ссылку на устаревшую инструкцию. Просто вносить интервики в статью я умею и делал это много лет. Сейчас изменился порядок добавления. Изменили его конечно предполагая добрые намерения, но сделали это очень коряво. Например сам алгоритм внесения интервики в разных статьях может быть разным. Поэкспереминтируйте, например в статьях Мухаджирство и Орстхойцы. Зачем мне вникать во все эти нюансы!? Предыдущий вариант был проще. --АААЙошкар-Ола16:04, 7 апреля 2016 (UTC)
Я её открыл: там портянка неконкретного текста. Кстати никаких пояснительных картинок. Я проделал указанные операции в статье Орстхойцы и ничего не получилось. Я повторил - тот же результат. Повторюсь, когда я осваивал простановку интервик раньше, мне понадобилось 3 мин. И конкретно меня не волнует инструкция, меня волнует почему алгоритм внесения интервики в разных статьях может быть разным? Зачем усложнять? А если усложнили, снабдите это дружественным интерфейсом и никакие инструкции не понадобятся.--АААЙошкар-Ола16:21, 7 апреля 2016 (UTC)
Есть два процесса: 1. связывание статьи без интервик с другой статьёй (или несколькими), 2. редактирование интервик в уже связанной статье. Это два абсолютно разных процесса, и, неожиданно, они делаются по-разному. — putnik16:39, 7 апреля 2016 (UTC)
Понял. Вот значит в чём дело. Кстати раньше я просто вносил интервики вручную и не делил это на два процесса. Но возможно сейчас это позволяет не забывать о какой-либо из интервик… Может оно и лучше. А вообще дискуссия бессмысленна — мне просто нужно в следующий раз вникать в новый алгоритм, из-за моих возмущений никто его упрощать не будет … --АААЙошкар-Ола16:52, 7 апреля 2016 (UTC)
Технологии с их развитием усложняются, это неизбежно. Плохо, когда такое усложнение происходит на пустом месте и не имеет смысла, но в данном случае это не так — Викиданные являются хорошим инструментом для наведения порядка в статьях, при чём во всех языковых разделах одновременно. — Vort17:16, 7 апреля 2016 (UTC)
Конкретно тут ситуация была хуже: и у русской, и у английской статьи были свои страницы на викиданных, и их надо было мёрджить. Что тоже делается за 3 секунды с гаджетом, но всё же. ~Facenapalmобс, вкл19:59, 7 апреля 2016 (UTC)
Ах вот оно что, это действительно не очевидно для первого раза. К сожалению, из примеров это было не понятно. Если есть идеи, как сделать этот процесс проще со стороны Википедии — предлагайте. — putnik10:45, 8 апреля 2016 (UTC)
Вот-вот, я не совсем глупый, просто я не умею мёрджить (слово-то какое!). Но я обязательно научусь, жалко, что это отнимает время у человека технически не образованного, а его так не хватает на написание статей … --АААЙошкар-Ола14:02, 8 апреля 2016 (UTC)
Да не особо умное слово-то. От английского merge — сливать (всё в одно место). Проблема была в том, что на викиданных было два элемента: один с английской интервикой, другой — с двумя остальными. Если бы ты открыл (а, может, и открыл) элемент в викиданных, связанный со статьёй в рувики, и попытался бы туда добавить английскую интервику, увидел бы сообщение примерно такого содержания: «добавление невозможно, так как эта ссылка уже используется в элементе Qddddd». В данном случае оказалось, что эти два элемента относятся к одному и тому же термину, поэтому их можно просто объединить с помощью гаджета Merge. Бывают случаи, когда гаджет не срабатывает: например, если в обоих указанных элементах есть английская интервики. Это называется интервики-конфликтом. Его можно либо самостоятельно решить (удалить некоторые интервики от одного элемента и приписать к другому, если эти элементы разные, но некоторые интервики оказались не там; удалить интервики, попавшие сюда по ошибке, и смёрджить остатки, если это одно и то же), либо подать заявку в какую-то там специальную тему, я уже не помню. Это на совсем сложные случаи, когда, например, оказывается, что в одном языковом разделе две статьи об одном и том же, и их надо бы объединить. На самом деле, техническое образование тут везде не при чём: просто у Викиданных не особо интуитивно понятный интерфейс, надо разбираться. И я всё же до сих пор считаю, что если кто-то добавит интервику в статью, а не на викиданные, ничего страшного не случится. Если что, можешь писать мне, я постараюсь помочь. ~Facenapalmобс, вкл22:46, 8 апреля 2016 (UTC)
Спасибо за развёрнутый ответ. Да я открывал страницу в Викиданных, да, после внесения интервики мне написали нечто подобное, и я не знал как действовать дальше. Инструкции об использовании гаджета Merge я не встретил. Теперь механизм стал понятнее. Но если что, я вам напишу.--АААЙошкар-Ола04:41, 9 апреля 2016 (UTC)
Нужно адаптировать его к Викитеке, как шаблон писатель. Музыканты так-то и тексты пишут и книги всякие. Нпр. Гулла, Джон Пейке - родной язык в ВД стоит, страничка его в ВТ есть. Это за неделю уж третий раз вижу, что нет выхода к ключевой информации статьи (по сути). S, AV☎10:52, 6 апреля 2016 (UTC)
Я бы и без текстов викитековал, ноты публикуются и переходят в ОД. Где их нынче положено размещать? На мой взгляд, в викитеке. — Igel B TyMaHe11:09, 6 апреля 2016 (UTC)
@WindEwriX:, каким образом, если этого параметра даже нет в шаблоне? Только Викисклад. Посмотрите на его (Ш:Музыкант) страницу. И еще, спасибо огромное - большое дело сделали) S, AV☎11:16, 13 апреля 2016 (UTC)
Словоформа определяется уже по конструкции {{ Население | Исетское (Свердловская область) | тс }} (↘173[1]), которую один участник понавставлял во все шаблоны, и определяется она, разумеется, неправильно. — putnik15:14, 7 апреля 2016 (UTC)
↑Численность и размещение населения Свердловской области(рус.). Всероссийская перепись населения 2010 года. Управление Федеральной службы государственной статистики по Свердловской области и Курганской области. Дата обращения: 16 апреля 2021. Архивировано из оригинала 28 сентября 2013 года.
Спасибо, сделал! Табличкой смотрится не очень красиво — разве что транспонировать (см. ниже), но вертикально сравнивать хуже, по моему. Ardomlank17:06, 5 апреля 2016 (UTC)
Давно хочу поднять вопрос о переименовании «Яндекс.Директ» в «Яндекс.Wordstat» в гаджете. Яндекс.Директ — это их рекламное агентство, тут вообще ни при чём. Название сервиса статистики отражено в самом url: https://wordstat.yandex.ru (англ. word — слово + stats — статистика). В заголовке сервиса написано «подбор слов». Аналогично называется в системе помощи сервиса: «Подбор слов (Wordstat)». --Vladis1318:00, 5 апреля 2016 (UTC)
Обновил (теперь версии в обсуждении отображаются некорректно, новая вместо старой и ошибка вместо временной новой). Ardomlank21:04, 9 апреля 2016 (UTC)
Там же есть и ссылка на скачку: [11], только вот формат весьма специфичный: для программы OruxMaps. Если этого достаточно — хорошо, если нет — значит надо тащить тайлы с базы и писать программу для их склейки. Готовых конвертеров что-то не нашлось. — Vort17:06, 4 апреля 2016 (UTC)
@АААЙошкар-Ола: Готово. Оригинальные тайлы были в формате JPEG. Чтобы второй раз их не пережимать и не портить дальше качество, я выбрал для картинки формат TIFF. Из-за этого она получилась довольно большая, может не хватить ресурсов компьютера для её обработки. Также, из-за размера я не решился её грузить на хостинги, поэтому даю прямую magnet-ссылку: [12]. — Vort05:19, 5 апреля 2016 (UTC)
Слабо сходу ответить на простой вопрос: сколькими способами, не считая тега <references />, можно добавить секцию «примечания» в статью? Ещё полгода назад я бы кроме шаблонов {{Примечания}} и {{Reflist}} едва ли что назвал. Но, как оказалось, в рувики есть минимум 17 (!) таких шаблонов, список ниже. И это крайне неудобно, на самом деле. Во-первых, это попросту не нужно; во-вторых, это создаёт немалые трудности при написании парсеров или ботов, причём даже у опытных участников. Вот пример: Rubinbot, не зная о наличии шаблона «Примечание» в статье, добавил ещё и шаблон «Примечания», тем самым раздвоив секцию. Короче говоря, зачем нам этот геморрой? Я бы почистил.
{{Примечания2}} — лично мне такой вариант «заголовок включён в шаблона» не очень нравится, но можно и оставить, в дизамбигах это удобно. Хотя, всего полсотни включений…
{{Комментарии}} — меньше десяти включений. Можно и вычистить. Хотя, название красивое, можно действительно использовать для того, чтобы не путать, где ссылки на источники, а где — комментарии. Можно его из редиректа превратить в секцию примечаний с конкретной заданной группой, например.
{{Sources}} — порядка 20 включений, исправляется викификатором. Тоже смысла не вижу. Теперь перенаправляется на другой шаблон.
{{Ref-list}} — 60 включений, но смысла в шаблоне нет.
{{Reflist}} — основной шаблон на английской Википедии, потому испольузется в значительной части переводных статей — 13 тысяч включений. Удалять, пожалуй, нецелесообразно.
{{Reflist+}} — в отличие от вышеперечисленных, не является редиректом на «примечания», но особых отличий в юзабилити я не вижу: используется так же, видимый результат, вроде, тот же. 200 включений.
Поскольку {{Список примечаний}} такой популярный, предлагаю пока его не удалять (всё-таки 4 тысячи правок, не меняющих статью визуально — это ад), но добавить его замену на {{Примечания}} в викификатор — хочется верить, это будет постепенно делать ситуацию лучше. @putnik:? ~Facenapalmобс, вкл08:27, 4 апреля 2016 (UTC)
Запустил я было бота по {{sources}}, как вдруг обнаружил занимательный факт: не используется этот шаблон для того, чтобы вставить в статью примечания (ещё один повод разгрести этот гадюшник). Добрая половина использований — в значении {{rq|sources}}. Пробегусь руками. ~Facenapalmобс, вкл09:46, 4 апреля 2016 (UTC)
Подведу небольшой итог: {{Примечания}} оставляем; {{Список примечаний}} и {{Reflist}} исправляем викификатором, а там видно будет; {{Reflist+}} и {{Примечания2}} вынесли на удаление; все редиректы быстро удаляем или уже удалили. Все высказывавшиеся это поддерживали или, по краней мере, не выступали против. Осталось решить, что мы делаем с {{Комментарии}}. Я вычистил все случаи, где он использовался неправильно, и у него осталось всего 5 включений. Он точно нам нужен в текущем виде? ~Facenapalmобс, вкл14:35, 4 апреля 2016 (UTC)
Ты меня опередил с этим замечанием и предложением. :) Вот только я, пока вычищал, очень много каких-то таких случаев видел: {{sources|img|stress}}. То есть тупо забывали добавить rq. Возможно, безопаснее будет просто удалить. ~Facenapalmобс, вкл15:32, 4 апреля 2016 (UTC)
Согласен ;) Боюсь только, что скоро кто-нибудь его восстановит (только не я :) — очень уж слово соблазнительное, умное. ←A.M.Vachin15:42, 4 апреля 2016 (UTC)
Все непопулярные редиректы вычищены. {{Комментарии}} я вычистил тоже: единственный аргумент против удаления этого редиректа относился скорее к секции комментариев в принципе, нежели конкретно к этому названию; причём даже в приведённом примере использовался шаблон {{Примечания}}. А всего 5 включений дают понять, что редирект, в общем-то, не нужен. В текущем виде, по крайней мере. Была идея преобразовать шаблон в специальный для комментариев, но она особой поддержки не получила. @Advisor: удалишь тоже?
Против идеи добавления замены /\{\{список примечаний/gi -> "{{примечания" в викификатор за чуть больше суток так никто и не высказался, зато половина отписавшихся поддержали (в том числе на ВП:РДБ). В любом случае, вреда даже гипотетического я не вижу никакого. @putnik: добавишь?
Как бонус, бот обнаружил и исправил под сотню статей, в которых было две секции примечаний; ещё в 20 подставил {{rq|sources}} вместо {{sources}} там, где изначально так и имелось в виду.
Ничего на месте нету. Т.е., не образно, а ваабще ничего! Подписываться даже тут ползаю в "быструю вставку" внизу. И вот чего я понять не могу- сделали беда-версию- так изгиляйтесь над ней или новые вплоть до омеги создавайте... Можно старую вообще не трогать? Мы, ретрограды, там остались именно потому, что не хотим изменений. Устраивает. Нет, надо обязательно каждую декаду нам чето подкидывать с непременными сопроводительными косяками? ((((( S, AV☎17:40, 3 апреля 2016 (UTC)
Круто, и в настройках дальше личных данных не пройти. Хотел типа кеш обновить. Низкий поклон вам господа разработчики. Чтоб вам в ваших производственных делах на вашем компе кто-то постоянно так помогал без предупреждения - в порядке сюрприза. S, AV☎17:47, 3 апреля 2016 (UTC)
Разработчики на данный форум не ходят. Включите монобук, старую панель редактирования, отключите всю бету и будет Вам счастье. Я вот вполне доволен. Advisor, 18:09, 3 апреля 2016 (UTC)
Думал под старой версией монобук имеется в виду... Тогда какой же вы ретроград?! Это мы, монобукисты, ретрограды :))) Присоединяйтесь... → borodun™18:14, 3 апреля 2016 (UTC)
Проверил- в Опере работает, а в Мозиле нет. И да, у меня монобук сколь себя помню (зашел уточнить это с оперы-с мозиды не реагируюи кнопки. Щас скажете, что мозила плохой...). S, AV☎18:18, 3 апреля 2016 (UTC)
Не знаю, у меня всё работает нормально. Тема векторная (по умолчанию), бета-тест улучшенные уведомления и связанные страницы, все настройки доступны, включены дополнительные гаджеты, браузер Opera. Oleg328022:03, 3 апреля 2016 (UTC)
Я и сказал, в Опере работает. В Мозиле нет. И появилась новая фишка- при нажатии на фото- никакой реакции теперь. Кнопок в описания правок вроде "викификация" тоже нет. Че просходит то, блин. S, AV☎05:23, 4 апреля 2016 (UTC)
@Schekinov Alexey Victorovich: Проблема только у вас, но при этом вы пытаетесь выставить ситуацию таким образом, что в этом виноваты все, кроме вас, флудите на форумах и используете выражения, которые в приличном обществе использовать не принято. Если вы продолжите в том же духе, то последует блокировка. — putnik08:05, 4 апреля 2016 (UTC)
Если бы вы вместо того, чтобы материться, подробно описали в каких условиях происходит проблема, что вы ожидаете увидеть и что получаете в реальности, я бы проверил. Но пока тут много ругательств и мало конкретики, а играть в экстрасенсов у меня желания нет. — putnik08:14, 4 апреля 2016 (UTC)
Мозилка — мой основной браузер. Никаких проблем не вижу. Уточните, что конкретно не должно работать? Попрошу без «всё не работает, абсолютно всё!». ~Facenapalmобс, вкл08:16, 4 апреля 2016 (UTC)
Проблема в окне редактирования. вверху должны быть кнопочки «Ж, К ... Подпись», а внизу кнопки описания правок «викификация, уточнение, и т.д.». Так вот этих кнопок нет. Есть только панель быстрой вставки. Во всех остальных проектах есть. В браузерах - Опере и Гугле тоже все работает. Но мне нужен мозила- там закладки лучше расположены, хотя Гугл и побыстрее думает. S, AV☎08:27, 4 апреля 2016 (UTC)
У меня всё отлично. Давайте танцевать с бубном: если из аккаунта выйти, проблема остаётся? Безопасный режим браузера помогает? ~Facenapalmобс, вкл09:32, 4 апреля 2016 (UTC)
Вспоминайте, что меняли. Пользовательские скрипты, оформление? Настройки? Бета-функции? Видимо, в чём-то набедокурили. Можно ещё попробовать браузер обновить — мало ли что. ~Facenapalmобс, вкл10:44, 4 апреля 2016 (UTC)
Я последнее, что делал- это рекламу фонда грохнул. Этому уж несколько месяцев. Но она стала просачиваться, скажем конкурс ФОТО ГОДА НА ВС - пролез. Только я уж и не помню че делал и даже где... Где эта страница? Видимо они теперь рекламу другим путем суют, а на тот поставили внутренние картинки. S, AV☎10:48, 4 апреля 2016 (UTC)
Здравствуйте, не могли бы добавить в него параметр, называемый ссылка или link, чтобы при клике по картинке был бы возможен переход по внешней ссылке, как у изображений, вставленных стандартным способом, без данного шаблона. Спасибо.--Анима❤ 11:08, 3 апреля 2016 (UTC
Если так, то да, но опять же опасно. Через пару лет в 90% случаях там будут ссылки и на внешние сайты и на внутренние статьи. Плюс Вы забываете, что страница для файла существует для отображения лицензий, убирать её никак нельзя. С уважением, Iniquity11:38, 3 апреля 2016 (UTC)
Не думаю, что опасно. В стандартной конструкции [[File:]] , с помощью которой вставлено подавляющее число картинок, этот параметр есть, и ничего не случилось. Тогда как узнать даже о существовании шаблона {{Биофото}} довольно проблематично, если не обращаться к биологическим статьям. Спасибо.--Анима❤11:49, 3 апреля 2016 (UTC)
Полагаю, около 99 процентов читателей предпочтут сразу перейти к полному изображению с мелкой прорисовкой нежели на страницу файла с лицензией. Спасибо.--Анима❤11:58, 3 апреля 2016 (UTC)
Сделал вот такой шаблон: {{ФЛ}}, может кому будет полезен. А возможность вставлять ссылки прямо в изображения существует уже очень давно (проверял это ещё лет 6-7 назад), и что-то не припомню эпидемий массового использования этой возможности. Pticy uleteli15:03, 3 апреля 2016 (UTC)
Ни в коем случае. Это, прежде всего, вопрос авторских прав и правового информирования читателя. При первом переходе файл должен сопровождаться лицензией: откуда взялось, как это можно использовать (или почему нельзя - для несвободных). Предлагаемый механизм не только скрывает сведения о файле, он даже не даёт ссылки на них. Это завсегдатаи знают что да как, а пользователей со стороны такими ребусами грузить нельзя. Retired electrician23:03, 3 апреля 2016 (UTC)
Ничего {{ФЛ}} не скрывает, внешне он аналогичен картинки с внутренней викиссылкой (различие лишь в том, что тут можно вставить внешнюю ссылку), поэтому утверждение: « он даже не даёт ссылки на них» в корне не верно, ссылка даётся (), и в таком же виде как и в случае широко применяемых картинок с внутренней викиссылкой, пример: [[Файл:Saintpaulia 20071016.jpg|thumb|link=Сенполия|50px]](результат см. справа)Pticy uleteli07:34, 4 апреля 2016 (UTC)
В абхазской Википедии создан гаджет, показывающий замо́чки в правом верхнем углу страницы. Предлагаю сделать и в РуВики такой. Я в 4-х вики уже локализовал его, поэтому полностью могу консультировать. С уважением, Илья Драконов08:30, 3 апреля 2016 (UTC).
Трансляция изображений и прочего-прочего из Викиданных в основные шаблоны статьи[править код]
Только не воспринимайте, как наезд, сразу скажу, что в принципе мне сия опция нравится, благодаря ей неоднократно находил изображения скажем немцев, портретов которых не было в немецкой Википедии, но были в непойминакакомязыке разделе... После чего проставлял их по всем языковым разделам.
Но опция эта имеет свои косяки, порой портреты откровенно не те, или скажем как тут - явно не портрет. Я не против этой иллюстрации, но не в шаблоне, но уберу из ВД, вставлю в статью - там могут не понять, а потом опять кто-то вставит и будет два фаллических элемента. Потому не трогал. А иногда по 5 иллюстраций транслирует сразу (редко, но было, чаще 2-3) Так вот нельзя-ли добавить в шаблоны новый параметр? Чтобы напротив
|изображение =
поставить, скажем «0» (пример - такой правкой) и трансляция в шаблоне отключалась, а статья включалась в скрытую категорию вроде «Статьи с неверными изображениями из Викиданных». Викиданщики бы эту категорию отслеживали и правили, и форум бы это освободило. Вон недавно Юля 70 жаловалась на такой косяк, и вообще это периодически возникает в обсуждениях.
В идеале бы было здорово, чтоб все параметры можно было так отключать и это могла бы в общую категорию вносить с названием по смыслу «ВД-косяки». И авторам проще и работающим с ВД тоже. Заглянули в категорию - все косяки там. --S, AV☎09:20, 2 апреля 2016 (UTC)
было предложение забивать неверные вики-данные параметром novalue, но, видимо, проблема решена рангом "не рекомендованный". ВО всяком случае, изображения отключаются именно так. Знатоки Викиданных меня поправят. — Igel B TyMaHe20:13, 2 апреля 2016 (UTC)
1. Уже давно можно поставить «-», и значение из Викиданных пропадёт. 2. Не нужно менять значение у неверных данных (например, картин в качестве изображения художника) на нерекомендованное, их нужно просто удалять. 3. Для изображений могил, гербов и всего прочего существуют отдельные свойства, например в примере выше это исправляется вот так. 4. В категории нет особого смысла, потому что это предложение сводится к «я замету мусор под коврик, пусть убирает кто-нибудь другой», а это плохо работает. — putnik09:43, 3 апреля 2016 (UTC)
Здравствуйте. После посещения статьи "Periodic table" в Английской Википедии (на телефоне) миниатюры изображений стали размытыми и нечёткими (даже, если я ещё не зарегестрировался). Подскажите, как это исправить?Изен06:52, 2 апреля 2016 (UTC)
Я пытался добавить ссылку используя шаблон {{Статья}}вот сюда. Но при этом почему-то у меня не получилось: после нажатия кнопки "Записать страницу" я остаюсь в окне редактирования - без всяких предупреждений. При этом в песочницу эта ссылка добавилась без проблем: [13] (правда после капчи). И просто ту же ссылку без использования шаблона я тоже смог добавить: [14]. 192.136.116.2 19:49, 1 апреля 2016 (UTC)
Попробую добавить эту ссылку тут: Dennis Upper.The unsuccessful self-treatment of a case of “writer's block” // Journal of Applied Behavior Analysis. — 1974. — Т. 7, вып. 3. — С. 497. — ISSN0021-8855. — doi:10.1901/jaba.1974.7-497a.. Страно, тут получается, в песочнице получается, а на странице удаления - нет. В чем дело? 192.136.116.219:52, 1 апреля 2016 (UTC)
@Михаил Марчук: это вы так пошутили? Я же просто скопировал первую строку кода, чтобы не вставлять сюда всё сразу. Но так и быть, специально для вас скопирую весь код:
Да не волнуйтесь вы, я уже вчера посмотрел эту правку на СО проекта. Да, не было здесь ошибки, я даже уже сравнил прошлые архивации добавленные вами, ничем не отличались от этой, но работали. Я сам не знаю в чем причина этого бага, но вы точно не виноваты в нём. Михаил Марчук05:23, 2 апреля 2016 (UTC)
«я даже уже сравнил прошлые архивации добавленные вами» — какие ещё прошлые архивации? Я как-то добавлял, помню, у себя на СО тот же код, но он не работал. В итоге, я архивирую всё вручную. ← Alex Greatобсуждение05:41, 2 апреля 2016 (UTC)
Может проблема в том, что указанный здесь способ архивации работает для СОУ? Вероятно, стоит использовать настройки для архивации форумов, как, например, это сделано в проекте Библиотека с указанием пути архивации в списке бота. И, как можно увидеть в истории страницы, бот исправно совершил сегодняшнюю архивацию. —Maxinvestigator07:53, 2 апреля 2016 (UTC)
@Maxinvestigator: никаких запросов, никаких инструкций не предлагается. А страницу со списком вообще запрещено редактировать. Это капец. К техадминам что-ли обращаться? Никаких гайдов нет. Как вообще бот архивирует? У автора может спросить? Мне кажется он меня проигнорирует. ← Alex Greatобсуждение10:21, 2 апреля 2016 (UTC)
Переход по произвольной ссылке при клике на картинку Википедии[править код]
Здравствуйте. Необходимо, чтобы при клике на картинку осуществлялся переход не на страницу файла на Викискладе или Википедии, а по произвольной ссылке на независимый от вики-проектов сайт. Например, если нужно, чтобы по клику осуществился переход на google.ru, в html написал бы следующее: <a href="https://www.google.ru" target="_blank"><img src="http://example.com/example.jpg"></a> . А как сделать также на вики-сайтах? Спасибо.--Анима❤07:36, 1 апреля 2016 (UTC)
Просто смотреть надо в код. en:Wikipedia:Extended image syntax: [[File:Name|Type|Border|Location|Alignment|Size|link=Link|alt=Alt|Caption]], Link the image to a different resource, or to nothing. Must not be set for non-public domain images unless attribution is provided in some other fashion. — Igel B TyMaHe10:01, 1 апреля 2016 (UTC)
Спасибо! А возможно ли, чтобы ссылки по умолчанию открывались в новой вкладке, а не активной? Т.е. как реализовать target="_blank"? я то всегда кликаю по средней кнопкой мыши, но некоторые читатели вики могут не знать о её предназначении.--Анима❤12:21, 1 апреля 2016 (UTC)
Спасибо. Но почему запрос ничего не находит, хотя есть редирект Поляризационное тождество? Alexei Kopylov 17:17, 30 апреля 2016 (UTC)
Вообщем я починил. ← Alex Great обсуждение 15:47, 25 апреля 2016 (UTC)
Решено. ← Alex Great обсуждение 03:57, 26 апреля 2016 (UTC)
Сделано, 
Против того, чтобы все эти перенаправления вели не туда куда следует! То есть цифорки в кружочках не должны вести на обычные арабские цифры, для этого куда уместнее создать статью о соответствующем блоке Юникода, либо написать статью Цифры в круге, где подробно и с помощью АИ нужно указать где, как и для чего эти символы используются. Перенаправления со шляпы и овала меня вообще убивают. Они должны вестись или на Эмодзи или на Смайлы (Юникод). Поэтому я поддерживаю идею о их удалении. @1234qwer1234qwer4, Vcohen: вы же понимаете, что у нас-то и сами статьи о символах многие подпажают под КБУ, их нужно тоже переписывать, а тут речь аж зашла о редиректах этих символов. Вот когда мы создадим соответствующие статьи о блоках, статьях об этих символах (да хоть даже это будет Эмодзи-символ шляпы), вот тогда будет правильно. А когда вписываешь какой-то символ математический, и он ведёт куда на маттермин, где его даже тупо поиском не найти в статье — очень плохо. Я несогласен с топикстартером лишь в одном: то, что эти символы Вы не можете вводить со своей клавиатуры или «даже не во всех браузерах отображаются» совсем не повод для их несуществования. Для этого у нас есть изображения (для наглядности правильного отображения символа), шрифты и шаблон {{спецсимволы}}. ← Alex Great обсуждение 04:48, 24 апреля 2016 (UTC)
—Лука Батумец 20:40, 15 апреля 2016 (UTC)
. Ardomlank 06:27, 5 апреля 2016 (UTC)
), и в таком же виде как и в случае широко применяемых картинок с внутренней викиссылкой, пример: 
