Мне интересно знать, какие задачи программирования наиболее важны для редакторов. Поэтому я сгруппировал запросы функций по нескольким основным категориям. Пожалуйста, проголосуйте за категорию, над которой, по вашему мнению, должны работать разработчики. Добавьте свои голоса с помощью ~~~.
Если вы хотите комментировать категории, а не голосовать (или в дополнение к голосованию), вы можете сделать это под голосами.
Голосуйте только по одной категории.
Качество (25)
Скрининг на вандализм, с улучшенными списками наблюдения, более настраиваемыми страницами вкладов и RC и т. Д. Функции для организованного патрулирования, отмечая изменения как отмеченные.
- Добавьте свой голос в маркированный список ниже
- ALargeElk | Обсуждение 09:05, 5 июля 2004 г. (UTC)
- ну, если мы получим только один, это должно быть так. получить правильное качество, и это решит большинство других проблем. Эрих, 09:06, 5 июля 2004 г. (UTC)
- Да, это, безусловно, самое важное. → Raul654 09:06, 5 июля 2004 г. (UTC)
- Да, звучит хорошо, если (а) это не замедляет работу базы данных и (б) не создает препятствий на пути участников. - Heron, 10:03, 5 июля 2004 г. (UTC)
- Со всеми согласен. Было бы ужасно приятно иметь это. blankfaze | •• | •• 10:42, 5 июля 2004 г. (UTC)
- Да, отслеживание изменений - это самое важное, что мы делаем - мне достаточно сложно следить за своим списком наблюдения! - Arwel 12:35, 5 июля 2004 г. (UTC)
- Да, проверка редактирования была бы полезна. Он должен, по крайней мере, позволять краткое изложение причины принятия или отклонения редактирования. Jrincayc 12:53, 5 июля 2004 г. (UTC).
- Pcb21 | Пит . Тим не хочет здесь подробностей, но я приветствовал бы мозговой штурм на User: Pcb21 / Checked edits, поэтому у нас есть хорошие идеи, которые мы можем предложить разработчикам, если придет время.
- Дать согласие. Правки должны быть помечены как «отмеченные», ничего сложного. [[Пользователь: Meelar | Милар (разговор) ]] 19:57, 5 июля 2004 г. (UTC)
- Дать согласие. Я стараюсь проводить около получаса в день на дистанционном патрулировании, и все это время я щелкаю как сумасшедший, пытаясь не отставать. Все, что позволяет мне видеть со страницы RC, что какой-то другой вошедший в систему пользователь подтвердил анонимное редактирование, было бы здорово. - gadfium 20:47, 5 июля 2004 г. (UTC)
- Мне очень хочется проголосовать за производительность, но правда в том, что мы всегда можем добавить пару серверов, но мы не можем справиться с ростом вандализмов и т. Д. Dori | Обсуждение 01:10, 6 июля 2004 г. (UTC)
- Эту «особенность» следует рассматривать как требование . - Леди Лисике Икисиле | Обсуждение 01:49, 6 июля 2004 г. (UTC)
- Дать согласие. Было бы неплохо, если бы на странице Special: Contributions для пользователя были ссылки «diff» и «hist» (например, Special: Recentchanges ) для каждого редактирования, а не только «hist». - Сторми, 04:03, 6 июля 2004 г. (UTC)
- Эльф | Обсуждение . Трудный выбор между этой панелью и производительностью. Эти инструменты не обязательно так полезны, если производительность плохая. Но когда производительность хорошая, обнаруживать и устранять вандализм все равно сложно. Умм - думаю, это не совсем голосование, так как я должен голосовать только один раз (за исполнение). Но мне тоже очень нужны эти функции.
- Да, для всех, но особенно для выявления вандализма. Если мы хотим привлечь больше читателей и больше участников, абсолютно необходимо сделать его безопасным для всех, кто добавляет ценный и законный контент. Дитер Саймон 23:18, 6 июля 2004 г. (UTC)
- Я думаю, что качество - самая важная характеристика, а поиск - на втором месте. Производительность сейчас хорошая, иначе было бы самое главное. Все, что помогает отслеживать качество, сейчас очень поможет. - ssd 04:59, 7 июля 2004 г. (UTC)
- Кроме того, некоторая система кармы, в которой люди могут отмечать других пользователей как « ОК» или что-то в этом роде, а те, у кого достаточно голосов, будут иметь другой цвет в RC, что позволит людям не тратить так много времени на проверку доверенных пользователей, когда они ищут вандализм. Конечно, все правки заслуживают проверки, но практически этого не произойдет. Между тем, проверили окно было бы здорово, с каким - то образом остановками людей от двух счетов, вандализма на одной и маркировки, проверялись на другом, может привести к ложной безопасности. - var Arnfjör Bjarmason 02:55, 12 июля 2004 г. (UTC)
- Простая галочка, чтобы другие могли отметить, что они одобрили статью или изменение, звучит разумно. Остановка двух учетных записей может быть частично подделана путем проверки IP-адресов (если IP-адрес слишком похож, скажем, первые 24 бита идентичны, тогда большая вероятность, что это один и тот же человек). Правила, помогающие обнаруживать «вероятные проблемы» (с использованием наивного байесовского метода, страницы, которые в прошлом часто обрабатывались, добавление внешних гипертекстовых ссылок, людей, которые не совершали так много принятых статей, и т. Д.) Для отметки недавних изменений, которые с большей вероятностью могут быть вандализмом. тоже может помочь. Dwheeler 05:13, 2004 25 июля (UTC)
- Сделайте списки версий на альтернативных языках автоматически переходными: в настоящее время необходимо редактировать страницу в каждой языковой версии, чтобы вручную скопировать списки версий на других языках. - аноним, 19:14, 19 июля (CEST)
- Да для всех. мнемоника 04:12, 2004 июл 23 (UTC)
- Да для всех. Лучшие списки наблюдения помогут предотвратить вандализм. Эти функции не должны занимать слишком много времени, поэтому сосредоточьтесь на производительности. - Taxman 14:14, 28 июля 2004 г. (UTC)
- Звучит неплохо. Возможность добавить список вкладов пользователя в ваш список наблюдения была бы удобна. Это был бы один из способов борьбы с вандализмом. DivisionByZero 31 июля 2004 г., 20:30 (UTC)
- Да. Список наблюдения ... может быть. Узел 21:12, 24 августа 2004 г. (UTC)
- BrokenSegue 20:10, 21 сентября 2004 г. (UTC)
- penubag 05:49, 17 мая 2008 г. (UTC)
Производительность (25)
Полнотекстовый поиск, регулярно обновляемые специальные страницы, время отклика, предотвращение сообщений об ошибках в часы пик, масштабируемость. Работа над производительностью снижает затраты на оборудование.
- Добавьте свой голос в маркированный список ниже
- Deepak IMO, все остальные аспекты довольно хороши / приемлемы. Медленный веб-сайт - убийца, и он не позволит широко принять его. OTOH, вероятно, проблема в оборудовании. Может ли программирование помочь сверх точки?
- Джонго 12:52, 19 июля 2004 г. (UTC)
- - Рябчик 13:26, 8 июля 2004 г. (UTC)
- Джей
- Анжела . Другие варианты довольно бессмысленны, если люди даже не могут пользоваться сайтом. Это должно быть приоритетом.
- Эльф | Обсуждение . Низкая производительность - это самая большая причина, которая отговаривала меня от патрулирования новых страниц и недавних изменений. Следовательно = большему количеству вандалов это сходит с рук.
- Не уверен, что это действительно называется «производительностью», но да, мы должны сделать так, чтобы программное обеспечение перестало ломаться, в качестве главного приоритета. Энтони (см. предупреждение)
- Я бы хотел поиск только по заголовку ... особенно при поиске по категориям. Я снимаю все флажки, кроме категории, и провожу поиск, и он обнаруживает все эти статьи, не относящиеся к категории, в названии которых даже нет моего слова. Я уверен, что если я не делаю то, что хочу, это вредит производительности. - ssd 04:54, 7 июля 2004 г. (UTC)
- Я ждал, чтобы проголосовать, и немного подумал над этим. Мое непосредственное желание состояло в том, чтобы пойти со стадом и проголосовать за качество, но качество IMO больше зависит от человеческих усилий. Было бы неплохо иметь более совершенные инструменты, помогающие поддерживать качество, но все напрасно, если WP настолько медленный, что удерживает людей от его использования. Я могу ошибаться в этом, но я не думаю, что повышение производительности просто связано с добавлением большего количества оборудования. Я думаю, что оптимизация производительности - это очень сложная работа и, возможно, не столь приятная для разработчиков, как создание новых функций пользовательского интерфейса (которые часто имеют своего рода фактор «чудаковатости»). И, говоря лично, я знаю, что избегаю таких вещей, как проверка RC или новых страниц, когда что-то работает медленно. старше ≠ мудрее 15:15, 7 июля 2004 г. (UTC)
- AaronSw
- Acegikmo1 18:54, 10 июля 2004 г. (UTC) Я не знаю, что означает полнотекстовый поиск, но любой вид поиска полезен, особенно тот, который у нас есть в настоящее время, очень хорош. Google никогда не помогал мне при поиске слов в Википедии, возможно, Google плохо индексирует W'pedia. W'pedia не обязательно полагаться на Google. Джей 15:10, 5 июля 2004 г. (UTC)
- Etaoin 02:36, 11 июля 2004 г. (UTC)
- Да. На мой взгляд, сайт слишком часто не работает, а в загруженное время он часто работает медленно, до такой степени, что редактирование чего-либо становится невозможным. Decrypt3 00:44, 12 июля 2004 г. (UTC)
- DocUK 21:29, 14 июля 2004 г. (GMT) Википедия прекрасна, но единственное, что не дает ей превзойти любую программную альтернативу, - это скорость. Меньшее время отклика и повышение производительности поиска были бы определенным улучшением и высшим приоритетом.
- Я согласен с Анжелой ; производительность, масштабируемость и стабильность должны быть приоритетом номер один. Какой смысл добавлять функции и т. Д., Если никто не может пользоваться сайтом (или его использование затруднительно ...)? Как программист, я вижу, что PHP, вероятно, не лучший выбор. Рассматривались ли другие языки? Т.е. переписывать MediaWiki (для Википедии) на Perl? Perl / mod_perl и Apache немного быстрее PHP. Я знаю, потому что я разработал приложения с большой нагрузкой на обоих этих языках. Торо 11:32, 20 июля 2004 г. (UTC)
- То, что PHP медленнее Perl, для меня новость - равная, спорная, но медленная? Странный. Во всяком случае, комментарии других убедили меня. Я до сих пор помню, как вечно ждал, когда мои правки на VfD произойдут, только чтобы узнать, что произошел конфликт редактирования. Джонлимк | Talk 13:14, 20 июл 2004 (UTC)
- Я тестировал только приложения на Perl и PHP, работающие под mod_perl / mod_php (Apache). Я не уверен, насколько «автономные» Perl и PHP сравниваются друг с другом. Но это не проблема, поскольку такой сайт, как Википедия, должен работать в «усиленной среде». Большинство тестов, распространяемых в сети, похоже, было выполнено человеком, не знакомым ни с одним из языков программирования (или как правильно настроить mod_perl и Apache, чтобы получить от него максимальную отдачу). Мой личный вывод таков: легко создать быстрое и небольшое приложение на обоих языках, но его намного проще масштабировать с помощью Perl. Торо 17:06, 20 июля 2004 г. (UTC)
- То, что PHP медленнее Perl, для меня новость - равная, спорная, но медленная? Странный. Во всяком случае, комментарии других убедили меня. Я до сих пор помню, как вечно ждал, когда мои правки на VfD произойдут, только чтобы узнать, что произошел конфликт редактирования. Джонлимк | Talk 13:14, 20 июл 2004 (UTC)
- gracefool 03:55, 28 июл 2004 (UTC)
- Падду 18:19, 31 июля 2004 г. (UTC)
- Патик 16:31, 5 августа 2004 г. (UTC)
- Без колен 06:38, 07 августа 2004 (UTC)
- Джонлимк | Обсуждение 14:17, 8 августа 2004 г. (UTC)
- rhyax 05:15, 2 сентября 2004 г. (UTC)
- AHM 01:46, 8 сентября 2004 г. (UTC)
- [[Пользователь: Eequor | ηυωρ ]] 20:28, 12 сентября 2004 г. (UTC)
- - Q uadell ( ток ) ( помощь ) [[]] 16:08, Sep 19, 2004 (UTC)
- Настраиваемые страницы вкладов Ellmist не приносят много пользы, когда статьи загружаются бесконечно.
Синтаксис и рендеринг (5)
Шаблоны с параметрами, которые действительно работают, новые типы данных, например, химические структурные формулы, шахматы, музыка и т. Д., Совместимость с браузером, доступ к WAP.
- Добавьте свой голос в маркированный список ниже
- [[Пользователь: OldakQuill | Oldak Quill ]] 11:48, 6 июля 2004 г. (UTC) Очень полезная функция. Больше никаких химических формул ASCII. Очень полезно для музыковедов, таких как я
- Нейтралитет 05:09, 14 июля 2004 г. (UTC)
- F i P 16:31, 26 июля 2004 г. (UTC) инструмент для создания химических формул может быть неплохим ^^
- Доступ к WAP был бы хорош. Но есть проблема совместимости - например, в Японии используют iMode, а не WAP (хотя я думаю, что японские устройства могут также читать WAP), не все устройства поддерживают Unicode или изображения ... Новые виды данных. .. хм ... как насчет "древовидных" диаграмм? т. е. показать генеалогическое древо, или языковую семью (которая будет значительно отличаться от родословной), или таксономические отношения между родами? Узел 21:29, 24 августа 2004 г. (UTC)
- [[Пользователь: Eequor | ηυωρ ]] 20:29, 12 сентября 2004 г. (UTC)
Распределение (4)
Формальный обзор, CD, DVD, распечатка, статические HTML-дампы.
- Добавьте свой голос в маркированный список ниже
- [[Пользователь: Sverdrup | ❝ S verdrup❞ ]]
- arj 15:59, 5 июля 2004 г. (UTC)
- Уткурш 6 июля 2004 г.
- Vrabcak 15:11, 14 июля 2004 г. (UTC) WAP-доступ будет отличным
Права пользователя (1)
Частичные запреты для пользователей, например, из пространств имен или заданных наборов статей, или количества правок в день. Альтернативные методы дезинфекции и дезинфекции. Опасные действия кворумом или консенсусом. Частичная защита страницы с использованием замены файла или подобного. Автоматическая проверка носков марионеток. Метрики доверия.
- Добавьте свой голос в маркированный список ниже
- theresa knott 17:51, 5 июля 2004 (UTC) это даст AC гораздо больше гибкости
Предложения по функциям
Это голосование, а не страница с предложениями функций! Но вы все равно можете добавить свои предложения ниже.
- Возможность аннотировать фрагмент текста, по крайней мере, сообщением или, в лучшем случае, обсуждением вики, без возможности того, чтобы он стал еще одной бесполезной записью в Википедии, предназначенной для аннотирования фрагмента текста в другой записи. Обратите внимание, я думаю, что это в В ваших интересах реализовать эту функцию, поскольку многие статьи в Википедии описываются с уникальной точки зрения, которой не делятся. Книги могут быть аннотированы, википедия - нет .. Аннотации означают не просто создание примечаний на другой странице, но и ссылку на уникальную запись, просто отметив ее и написав заметку.
Я думаю, что это в пределах разумного, что Javascript и Ajax могут предоставить эту утилиту, поскольку можно связать идентификатор с фрагментом текста, выделенным с помощью выбора мыши. Википедия в любом случае нуждается в обновлении, и это не нарушает целостность информации. Кстати, YouTube теперь предлагает эту функцию для своих видео. Вы можете подумать, как YouTube может превзойти полезность литературного ресурса.
- На мой взгляд, поисковая система должна быть значительно улучшена. Скажем, если человек не знает, как правильно писать «парашют», и набирает «парашют» в окне поиска, Wiki не сможет найти ни одной статьи с таким же сочетанием букв. В этом смысле Webster.com, например, намного лучше. KNewman 20:15, 9 августа 2004 г. (UTC)
- Сисопы должны иметь возможность просматривать IP-адрес вошедших в систему пользователей, чтобы проверить наличие sockpuppetry. Поскольку это также проблема конфиденциальности, ее следует ограничить только сисопами. → Raul654 08:51, 5 июля 2004 г. (UTC)
- Меня это беспокоит. Это действительно проблема конфиденциальности, и я не уверен, что мне нравится, что все администраторы имеют такую возможность. Однако вполне могут быть похожие варианты. Как насчет того, чтобы администраторы могли видеть информацию вроде « User: PotentialSockpuppet имеет тот же IP-адрес, что и User: EstablishedWikipedian », но не видеть на самом деле, что это за IP-адрес. - ALargeElk | Обсуждение 09:04, 5 июля 2004 г. (UTC)
- Я не согласен с высоко Raul.- S V
- Разве это не то, для чего нужны checkusers ...? 208.71.51.110 ( разговорное ) 15:07, 17 апреля 2008 (UTC)
- Я не согласен с высоко Raul.- S V
- Меня это беспокоит. Это действительно проблема конфиденциальности, и я не уверен, что мне нравится, что все администраторы имеют такую возможность. Однако вполне могут быть похожие варианты. Как насчет того, чтобы администраторы могли видеть информацию вроде « User: PotentialSockpuppet имеет тот же IP-адрес, что и User: EstablishedWikipedian », но не видеть на самом деле, что это за IP-адрес. - ALargeElk | Обсуждение 09:04, 5 июля 2004 г. (UTC)
- Просмотр вкладов из диапазона - вполне возможно, что мы будем вандализированы рядом IP-адресов, и сисопы никогда не узнают. Один IP-адрес (abc50) будет подвергаться вандализму, пока он не будет заблокирован системным администратором Q. Затем вандал переключается на другой IP-адрес (abc56), пока он не будет заблокирован администратором R. Пользователь должен иметь возможность просматривать недавние сообщения с заданного диапазона IP-адресов для проверки согласованные атаки. → Raul654 08:55, 5 июля 2004 г. (UTC)
- Пожалуйста, дайте нам простой способ отменить перемещение страниц. → Raul654 08:56, 5 июля 2004 г. (UTC)
- Второй этот. Я думаю, это подпадает под "производительность". Энтони (см. предупреждение)
- Хорошо. Возможно, выгрузите целевой текст (обычно перенаправление) на подстраницу. - S V
- Второй этот. Я думаю, это подпадает под "производительность". Энтони (см. предупреждение)
- Способ перемещения / копирования страниц между вики, т.е. Псевдо-пространство имен "Trans".
- [edit] ссылки для раздела 0. Это мелочь, но поможет. Диспрозия 09:03, 5 июля 2004 г. (UTC)
- Второй этот. - OwenBlacker 01:58, 8 августа 2004 г. (UTC)
- «История для всех страниц в моем списке наблюдения с момента последнего просмотра», а не самая последняя запись в истории для каждой страницы за последние три дня (или что-то еще). Другими словами, недавние изменения, но отфильтрованные в мой собственный список наблюдения, показывающие изменения, которые мне, возможно, придется просмотреть. «С момента последнего просмотра» может быть основано на файле cookie, в котором хранится время последнего доступа к странице. Также разрешите фиксированные периоды времени, как в текущем списке наблюдения, для тех, кто случайно обновил страницу. - Avaragado 10:29, 5 июля 2004 г. (UTC)
- Безусловно, это была бы одна из моих любимых функций! : o) - OwenBlacker 01:58, 8 августа 2004 г. (UTC)
- Это было бы прекрасно! Greeves ( ток • вклад ) 21:35, 25 июня 2007 (UTC)
- То же самое, улучшены последние изменения, но отфильтрованы в мой собственный список наблюдения («с тех пор, как я последний раз смотрел» не требуется, для меня достаточно выбираемого периода времени) - Патрик 13:16, 5 июля 2004 г. (UTC)
- Как и в случае с двумя вышеупомянутыми, как насчет «скрыть статьи, которые я последний раз редактировал» в списке наблюдения или «скрыть страницы, отредактированные / не редактировавшиеся последними этим пользователем» ... - ssd 20:26, 5 июля 2004 г. (UTC)
- Мне это тоже нравится. - OwenBlacker 01:58, 8 августа 2004 г. (UTC)
- Как и в случае с двумя вышеупомянутыми, как насчет «скрыть статьи, которые я последний раз редактировал» в списке наблюдения или «скрыть страницы, отредактированные / не редактировавшиеся последними этим пользователем» ... - ssd 20:26, 5 июля 2004 г. (UTC)
- Переименование категорий. - Avaragado 10:29, 5 июля 2004 г. (UTC)
- Визуализация категорий. Стороннее программное обеспечение, позволяющее визуализировать ссылки на категории как генеалогию / дерево, а не просто как список. Это может помочь с сокращением / устранением избыточности, возможно, специальная страница, которая позволяет сисопам запускать определенные сценарии ботов для сокращения категорий.? - S V 19:05, 25 июля 2004 г. (UTC)
- [Безопасность / Вандализм]: «Мягкая защита» отдельных страниц. "Мягко защищенную" страницу можно редактировать, но нельзя перемещать . Я предполагаю, что страницы с огромной историей, такие как pump и vfd, будут постоянно защищены программным обеспечением. Некоторые вандалы узнали, что перемещение страниц - это эффективная тактика. Наша текущая защита от этого (отключение всех перемещений страниц) не так эффективна, поскольку требует вмешательства разработчиков, в то время как модель «мягкой защиты» может управляться администраторами. Pcb21 | Пит, 11:11, 5 июля 2004 г. (UTC)
- Было бы очень полезно отметить правки как отмеченные. Я думаю, что нужно, чтобы было легче увидеть, какие правки были приняты. Он также должен позволять прикреплять короткий комментарий (например, сводку редактирования), чтобы можно было указать причину, по которой редактирование было проверено или нет (не вдаваясь каждый раз в разговор). Я бы предложил, чтобы каждый редактор мог пометить правку как одно из следующих:
- Принять - изменение является полезным вкладом и не требует дальнейшей доработки.
- Нейтрально - редактирование не является очевидным вандализмом, но в настоящее время редактор не может проверить его правильность. Например, в статье о минимальной заработной плате я недавно заметил изменение размера минимальной заработной платы для Канады. Я понятия не имею, правильно это или нет, поэтому я бы не отмечал, что он принят, но я могу добавить текстовый комментарий, даже если я не могу принять его в настоящее время.
- Требуется доработка - редактирование является улучшением, но требует исправления орфографии, грамматики и т. Д.
- Отклонить - изменение следует отменить. Если бы этот флаг был там, это помогло бы решить проблемы, связанные с незнанием, есть ли общий консенсус в отношении отмены редактирования.
- Затем, если бы это было привязано к спискам наблюдения, можно было бы легче увидеть, проверял ли кто-нибудь редактирование и проверял ли я редактирование (сделайте самопроверку специально выделенной, может быть, жирным шрифтом или чем-то еще). Кроме того, если бы он был привязан к недавним изменениям, это упростило бы поиск непроверенных правок. Jrincayc 12:53, 5 июля 2004 г. (UTC)
- Я ответил пользователю: Pcb21 / Проверенные правки, где я впервые увидел ваши точки. Pcb21 | Пит 16:50, 5 июля 2004 г. (UTC)
- Удаление copyvios из истории
- На самом деле в этом нет необходимости, но удаление уродливой истории (например, безумных войн вспять и вандализма) может быть демистифицировано. - S V
- Настраиваемая пользователем панель инструментов редактирования и персональная панель инструментов
Live RC, хорошо, IRC достаточно хорош, но в долгосрочной перспективе я бы хотел увидеть какой-нибудь веб-интерфейс.
- Больше вариантов сортировки для RC - теперь он проходит слишком быстро. -SV
- Ссылка «Добавить в список наблюдения» на RC и ссылка «Удалить из списка наблюдения» в списке наблюдения. - S V
- Автоматическое архивирование ; Глупо, что мы должны ломать себе голову, очищая от обсуждений VP, Vfd, FAC и т. Д.; нам нужно разработать автоматическое архивирование. (Думаю, это вызов, который нужно разработать при управлении простой структурой базы данных вики)
- IRC - это новый вице-президент, но в нем отсутствует прямой интерфейс имени пользователя и автоматические маскировки IP. Форум был бюстом, но простая резьба поста возможности для очень активных страниц могут работать, при условии , что они функционируют в рамках одного входа interface.- S V
- Разделите викитекст на викитекст и мета поля; мета-поле будет содержать заглушки, langlinks, категории и другие вещи, которые мы можем добавить в будущем.
- [[Пользователь: Sverdrup | ❝ S verdrup❞ ]] 13:52, 5 июля 2004 (UTC)
- Обратите внимание, что у нас уже есть live RC, использующий IRC. Pcb21 | Пит, 15:56, 5 июля 2004 г. (UTC)
- Таблицы с более красивыми стилями CSS ( пример красивой таблицы ). почему им здесь так пренебрегли? многие пользователи неохотно добавляют их или совершенно противны использованию таблиц из-за их уродства. Таблицы теперь представляют собой некрасивые пороки для статей, которые в остальном выглядят элегантно. ✈ Джеймс С. 19:22, 2004 25 июля (UTC)
- реальная система опроса , я знаю , что это не маленькая особенность. учитывая, что демократический процесс является такой неотъемлемой частью Википедии, я думаю, что такая конвенция заслуживает надежной инфраструктуры. текущие реализации опросов грубые и неудобные и не подходят для крупномасштабного использования. ✈ Джеймс С. 19:22, 2004 25 июля (UTC)
- Число, указывающее, сколько пользователей просматривают определенную страницу. Если я увижу небольшое число, я останусь и буду смотреть страницу, пока трафик не увеличится и не появится больше людей в своих списках наблюдения. Количество наблюдателей также будет показателем популярности страницы, это полезная статистика. Джей 15:10, 5 июля 2004 г. (UTC)
- Разворачивать и сворачивать обсуждения на страницах обсуждения, что-то вроде интерфейса почты Google. Джей 15:10, 5 июля 2004 г. (UTC)
- согласовано. Мне бы хотелось полностью переработать формат страницы обсуждения, более похожий на формат онлайн-форума. прямо сейчас страницы обсуждения трудно использовать для продуктивных обсуждений. формату не хватает ясности и простоты, столь необходимых для частых и сложных дебатов. ✈ Джеймс С. 19:22, 2004 25 июля (UTC)
- Расширенная функциональность на случайной странице, связанная с проблемами качества. Например, «смотреть случайный окурок » (или просмотреть случайную статью в этой категории ...); случайная статья, которую мало смотрели (см. количество списков наблюдения выше); случайное недавнее редактирование и т. д. Это можно использовать как еще одно средство выборочной проверки. - ssd 20:32, 5 июля 2004 г. (UTC)
- Сортировка категорий по RC / предпочтениям?
- Распределенные последние изменения (DRC) и списки наблюдения (DWL). DRC будет работать, назначая тем, кто просматривает страницу, определенные правки, чтобы редакторы, выполняющие патрулирование RC, не смотрели одни и те же правки. Это может быть так же просто, как установка небольшого флажка для правок на основе идентификатора пользователя. DWL должен быть отделен от основного списка наблюдения, и он распределяет количество всех статей среди некоторого набора активных участников. В идеале должно быть некоторое совпадение, но с нашим текущим количеством активных пользователей и статей я не уверен, что это было бы хорошей идеей. Дори | Обсуждение 01:18, 6 июля 2004 г. (UTC)
- У меня была идея, похожая на эту. На странице различий может быть ссылка «следующая», которая выбирает последнее изменение, основанное на каком-то хитром алгоритме, для просмотра редактором. Непроверенные правки будут выбраны с высокой вероятностью, правки будут проверяться только новым пользователем с немного меньшей вероятностью, правки будут проверены несколькими доверенными пользователями с очень низкой вероятностью. Возможно, можно было бы учесть поле интересов пользователя. - Тим Старлинг, 05:52, 6 июля 2004 г. (UTC)
- На странице пользователя (например, на бесплатном шахматном сервере в Интернете) отображается «процент времени, проведенного в сети», чтобы предупредить о зависимости. Pjacobi 00:28, 11 июля 2004 г. (UTC)
- Лучшая документация mediawiki, упрощающая присоединение заинтересованных разработчиков, диаграмма того, как она основана, рабочий процесс отрисовки типичной страницы, где хранятся все глобальные переменные, и т. Д. И на самом деле напишите на мета такие вещи, как «ваша первая особенность». - var Arnfjör Bjarmason, 03:06, 13 июля 2004 г. (UTC)
- Пользовательское предпочтение для редактирования статей в UTF-8 , чтобы символы вне ISO Latin-1 можно было вводить напрямую, вместо того, чтобы преобразовывать их в ссылки на символьные сущности . См. Википедию: Юникод . Gdr 11:10, 2004 13 июля (UTC)
- Как насчет того, чтобы сделать еще один шаг и фактически поддержать UTF-8 на en. он поддерживается всеми остальными. - var Arnfjör Bjarmason 11:21, 13 июля 2004 г. (UTC)
- Это было бы еще лучше, но могло бы вызвать споры. Предпочтение пользователя для редактирования в UTF-8 повлияет только на тех, кто решил его использовать. Gdr 12:06, 2004 13 июля (UTC)
- Единственная причина, по которой это не было сделано, заключается в том, что преобразование всей базы данных немного затруднительно, и спор не является причиной. В идеальном мире ru. уже будет использовать UTF-8. До сих пор никто не хотел сохранить ISO-8859-1 в пользу UTF-8 по какой-либо другой причине. - var Arnfjör Bjarmason 19:53, 14 июля 2004 г. (UTC)
- Обратите внимание, что это не только en в ISO 8859-1, но также da, de, sv, nl и es. - Тим Старлинг, 00:42, 15 июля 2004 г. (UTC)
- Но в чем же проблема с конверсией? Некоторые нерешенные технические трудности? и если да что ?. - var Arnfjör Bjarmason, 06:53, 15 июля 2004 г. (UTC)
- Это время от времени обсуждается на wikitech-l. Проблема заключается в минимизации времени простоя. В настоящее время можно было бы преобразовать его, переключив вики в режим только для чтения на пару дней. Мы обсудили несколько способов сократить время, проводимое в режиме только для чтения, теперь кто-то должен закодировать один из них. - Тим Старлинг, 05:54, 17 июля 2004 г. (UTC)
- У каждой статьи может быть флаг, указывающий, была ли она в UTF-8 или ISO 8859-1 . Всякий раз, когда кто-то редактирует статью в ISO 8859-1, она конвертируется в UTF-8. Другие статьи можно конвертировать так быстро или медленно, как вам нравится, без простоев. Gdr 12:06, 2004 21 июля (UTC)
- Я думаю, вы обнаружите, что есть более фундаментальная проблема, чем это. Я подозреваю, что изменение набора символов требует настройки чего-то низкоуровневого в реальной базе данных. Независимо от того, делаете ли вы это с уже заполненной базой данных или с пустой базой данных, которая затем должна быть повторно заполнена, это нетривиальный процесс и не займет тривиального количества времени или усилий. - Фил | Talk 13:52, 21 июля 2004 г. (UTC)
- Но тексты, закодированные в UTF-8 и ISO 8859-1, являются просто потоками байтов; нет ничего особенного в кодировании. Я сомневаюсь, что база данных знает или заботится. Преобразование символов выполняется просто, поскольку каждый символ ISO 8859-1 появляется в одной и той же кодовой точке в Юникоде. Пока не понимаю, в чем проблема. Gdr 16:50, 2004 21 июля (UTC)
- Ты думаешь в правильном направлении, Б-г, но такие вещи легче сказать, чем сделать. Нет недостатка в идеях и непреодолимых технических проблем, просто нехватка рабочей силы. - Тим Старлинг, 09:21, 22 июля 2004 г. (UTC)
- Но тексты, закодированные в UTF-8 и ISO 8859-1, являются просто потоками байтов; нет ничего особенного в кодировании. Я сомневаюсь, что база данных знает или заботится. Преобразование символов выполняется просто, поскольку каждый символ ISO 8859-1 появляется в одной и той же кодовой точке в Юникоде. Пока не понимаю, в чем проблема. Gdr 16:50, 2004 21 июля (UTC)
- Я думаю, вы обнаружите, что есть более фундаментальная проблема, чем это. Я подозреваю, что изменение набора символов требует настройки чего-то низкоуровневого в реальной базе данных. Независимо от того, делаете ли вы это с уже заполненной базой данных или с пустой базой данных, которая затем должна быть повторно заполнена, это нетривиальный процесс и не займет тривиального количества времени или усилий. - Фил | Talk 13:52, 21 июля 2004 г. (UTC)
- У каждой статьи может быть флаг, указывающий, была ли она в UTF-8 или ISO 8859-1 . Всякий раз, когда кто-то редактирует статью в ISO 8859-1, она конвертируется в UTF-8. Другие статьи можно конвертировать так быстро или медленно, как вам нравится, без простоев. Gdr 12:06, 2004 21 июля (UTC)
- Это время от времени обсуждается на wikitech-l. Проблема заключается в минимизации времени простоя. В настоящее время можно было бы преобразовать его, переключив вики в режим только для чтения на пару дней. Мы обсудили несколько способов сократить время, проводимое в режиме только для чтения, теперь кто-то должен закодировать один из них. - Тим Старлинг, 05:54, 17 июля 2004 г. (UTC)
- Но в чем же проблема с конверсией? Некоторые нерешенные технические трудности? и если да что ?. - var Arnfjör Bjarmason, 06:53, 15 июля 2004 г. (UTC)
- Обратите внимание, что это не только en в ISO 8859-1, но также da, de, sv, nl и es. - Тим Старлинг, 00:42, 15 июля 2004 г. (UTC)
- Как насчет того, чтобы сделать еще один шаг и фактически поддержать UTF-8 на en. он поддерживается всеми остальными. - var Arnfjör Bjarmason 11:21, 13 июля 2004 г. (UTC)
- Возможность просмотра «расширения» категории (т.е. содержимого категории, включая подкатегории). Затем мы можем развернуть, например, « Категория: Люди» и показать, что это глупая идея для категоризации следующим образом: Триллер -> Майкл Джексон -> Музыканты . Когда это действительно должно быть Триллер -> Альбомы Майкла Джексона -> Поп-альбомы . На данный момент людям сложно представить себе это, поскольку категория «расширение» не видна. - Chuq 05:51, 19 июля 2004 г. (UTC)
- Я согласен с Чуком в том, что возможность просматривать расширение категорий - это то, что сейчас нужно Википедии больше всего. Сполдинг, 19:30, 6 сентября 2004 г. (UTC)
- Специально: загрузка может иметь раскрывающееся меню с возможными положениями авторских прав / лицензий для загруженного файла, как указано в Википедии: Теги авторских прав на изображения (или, по крайней мере, наиболее распространенные теги). Выбранный тег будет добавлен на страницу изображения вместе с начальным комментарием. Gdr 12:06, 2004 21 июля (UTC)
- (Первоначально это не моя идея, расширять его.) Если шаблон включен с {{name}}, было бы возможно вместо того, чтобы просто записывать содержимое этого шаблона в html-файл, как это сделано сейчас, чтобы обернуть его в
Содержимое шаблона: имя
чтобы его можно было добавить в файлы CSS для рендеринга определенных шаблонов определенным образом, это было первоначально предложено на странице обсуждения template: stub и было реализовано так, чтобы пользователи могли скрыть шаблон-заглушку в своих CSS, я думаю, что это было бы Однако здорово сделать это глобальным. - var Arnfjör Bjarmason 15:07, 22 июля 2004 г. (UTC)
- Это действительно мелочь, но это то, что сводит меня с ума: при отображении статей я бы хотел, чтобы не было разрывов строк до / после категорий и межъязыковых ссылок. Прямо сейчас, если в статье 10 категорий, и каждая [[Категория:]] была помещена в отдельную строку, вы увидите большое пустое пространство в конце (или начале, в зависимости от того, где были размещены ссылки). Я называю это запросом функции, а не ошибкой, потому что такое поведение вполне логично и просто раздражает. - Hob 14:10, 26 июля 2004 г. (UTC)
- Проблема с объединением загрузки Interwiki-ссылок в одну строку заключается в том, что это искажает отображение страниц DIFF, например, делая отображаемый текст очень широким. Я обнаружил, что во многих случаях ответ состоит в том, чтобы аннотировать ссылки Interwiki и категории с описанием их HTML-комментариями, следя за тем, чтобы вы не оставляли фактически пустых строк: это, похоже, вызывает коллапс белого пространства. См. Недавнее обсуждение в Village Pump . HTH HAND - Фил | Talk 14:40, 26 июля 2004 г. (UTC)
- Живой CD-проект. Вариант Knoppix, который включает Apache и Wikipedia и содержит любые полезные инструменты и конфигурации разработчиков для работы над кодированием и редактированием для WP. Если проблемы с лицензией препятствуют включению, программное обеспечение отображается в списке, и ссылки для загрузки / установки / процессы упрощаются.
- Реализация LatexWiki для встроенной математики. Дэн Гарднер 18:40, 26 июля 2004 г. (UTC)
- Расширенные параметры кнопки случайной страницы. Например, в половине случаев речь идет о переписи населения. Я хотел бы иметь возможность ограничивать свой случайный выбор типами страниц (по крайней мере, длиной x, не генерируемых автоматически) и категориями страниц (все, что касается биологии, но не истории биологии). - Ignignot 15:21, 30 июля 2004 г. (UTC)
- Настоящая многоязычная поддержка для настоящей многоязычной работы над содержанием вместо «содержания на определенном языке». Это самое главное, и это возможно, я это чувствую. Идея эволюционировала с тех пор, как я указал вам на нее на irc #mediawiki. Пожалуйста, взгляните еще раз на мета-вики: многоязычное общение . Мета-вики: редактируемые заголовки тоже ссылаются. И сообщество-вики: Как писать на многоязычных страницах? . Эта штука также есть здесь, в wikipedia: wikipedia: многоязычное общение (чтобы использовать очень правильный адрес wikilandia для этой страницы;)) кстати, но у меня еще не было времени, чтобы исправить это должным образом. Спасибо. MattisManzel 11:49, 26 августа 2004 г. (UTC)