ДЕФИС МИНУС - самый бесполезный символ в Юникоде.
Может кто-нибудь объяснить мне, почему слова в именах шаблонов заглушек разделены символом ДЕФИС МИНУС? Это нелогичный выбор с нескольких точек зрения:
- Слова должны быть разделены пробелами, как в английском языке ; Я уверен, ты бы не хотел, если бы все слова были разделены ДЕФЕНОМ-МИНУСОМ-теперь-ты бы? {{some-stub}} в высшей степени лучше, чем {{some-stub}}
- ДЕФЕН МИНУС - это бедствие Вселенной. Ни дефиса, ни минуса . Это наследие формата обмена данными ASCII вооруженных сил США и не является частью упомянутого английского языка.
- Символ ДЕФИС МИНУС почти всегда намного сложнее набирать, чем символ пробела (в моем случае Option – KpdMinus, а не пробел).
- Николай ( ответ ) @ 11:28, 27 апреля 2006 г. (UTC)
- «Дефис минус» - почти на всех компьютерных клавиатурах - это просто дефис (нижний регистр, рядом с нулем и так же легко набирать, если не больше, чем пробел). Дефис стал стандартом для заглушек еще в те времена, когда пробелы вызывали проблемы в шаблонах. Он по-прежнему широко используется в шаблонах в целом и настолько широко используется для заглушек, что было бы чертовски сложно все изменить. Это также очень полезно для уменьшения двусмысленности в типах заглушек - комбинация верблюжьих колпачков и дефисов обеспечивает четкое различие между уровнями разделения заглушек, чего не будет при использовании пробелов. Гипотетический пример: если бы у нас был {{ канадский футбольный корешок }}, он был бы для футбольных корешков из Канады или для корешков, связанных с отдельным видом спорта, канадским футболом? Теперь перейдем к Canadian-football-stub (прямой потомок football-stub и CanadianFootball-stub (прямой потомок stub). Вся двусмысленность исчезает. Резкость ... что ? 01:48, 28 апреля 2006 г. (UTC)
- Я понимаю, что эта тема немного устарела (и я могу предложить несколько теорий относительно того, почему, но это другая тема), но я должен полностью согласиться с Николасом в использовании пробела вместо тире (например, изменение WP: WSS / NG с как с точки зрения удобства использования, так и с точки зрения языка. Придется не соглашаться с Grutness (опять же!); утверждением, что легче дотянуться до правого верхнего угла клавиатуры наименее гибким пальцем руки, чем нажимать вниз большой палец, не требующий других движений, не только противоречит базовой логике, он был полностью опровергнут эргономическими исследованиями. Давайте не будем глупыми, пожалуйста! Если вы собираетесь защищать противоречивое и недружелюбное к пользователю соглашение об именах, полное странных переносов, пожалуйста делайте это по реальным причинам. PS: Нет мнения о том, где именно находится клавиатура; во всем мире используется очень широкий спектр клавиатур, и многие из них радикально отличаются от "типичных американских". ; Я считаю неразумным делать предположения о том, что компьютерные окружения похожи на ... Также нет мнения о его полезности в Unicode; Я не уверен, что у меня есть смысл. - SMcCandlish [ обсуждение ] [ вклад ]ツ22:16, 19 февраля 2007 г. (UTC)
- Я могу вспомнить несколько второстепенных причин, таких как нежелательность попытки защитить пространство как указание иерархии, по сравнению с ... фактическим пространством (та же проблема возникает с дефисами, но реже), но в основном после 3000+ шаблонов заглушек, я думаю, что у этого больше инерции, чем у имперских единиц, и просто не стоит тратить время на их изменение. А идея «пусть расцветет сотня цветов» была бы невыразимо ужасной даже для «переходного периода». Я думаю, что это очень "настоящая причина", в отличие от пренебрежительного вышеизложенного. Алай 02:28, 20 февраля 2007 (UTC)
- Тип рассуждения «слишком далеко, чтобы повернуть назад» работает для меня (однако я подозреваю, что бот может сделать это без особых проблем); тем не менее, уровень «инвестиций» уже высок, так что достаточно справедливо. Индикатор иерархии не работает для меня, потому что, как вы указываете на себя, он на самом деле не делает того, что должен; соглашения об именах должны были бы снова измениться, представляя ту же проблему «переименовать миллион вещей», так что в некоторой степени второй аргумент почти работает и для меня). NB: Я не сказал, что настоящей причины быть не может, я попросил одну . Итак, спасибо за более или менее предоставленную информацию (не столько спасибо за неверную интерпретацию и тому подобное, но я спишу это на последствия наших аргументов в другом месте) - SMcCandlish [ talk ] [ contrib ]ツ11:17, 20 февраля 2007 г. (UTC)
- Я могу вспомнить несколько второстепенных причин, таких как нежелательность попытки защитить пространство как указание иерархии, по сравнению с ... фактическим пространством (та же проблема возникает с дефисами, но реже), но в основном после 3000+ шаблонов заглушек, я думаю, что у этого больше инерции, чем у имперских единиц, и просто не стоит тратить время на их изменение. А идея «пусть расцветет сотня цветов» была бы невыразимо ужасной даже для «переходного периода». Я думаю, что это очень "настоящая причина", в отличие от пренебрежительного вышеизложенного. Алай 02:28, 20 февраля 2007 (UTC)
- Касательно: {{ Canadian-football-stubs }} - есть другие способы справиться с этой противоречивостью, когда она возникает до такой степени, что ее необходимо решать. Один из них - просто избегать двусмысленных конструкций. Если бы пространство статей WP: CUE было достаточно богатым, чтобы нуждаться во всевозможных новых заглушках, например, для игры в английский бильярд , я бы следовал номенклатуре permcat, которая, кажется, превратилась в «НАЦИОНАЛЬНЫЕ игроки НАЦИОНАЛЬНОЙ АМБИГАЦИОННОЙ игры» (я пришел в частности, с этим для английского бильярда, а затем он распространился на американский или канадский футбол или оба, в CfD около месяца назад.) Итак, если когда-либо возникла потребность в окурке и окурке для Категории: Австралийский Игроки в английский бильярд окурок будет {{ Australian-Englishbilliards-bio-stub }}, а окурок - это Категория: Австралийские игроки в корешки английского бильярда, по моим подсчетам (лично меня совершенно не волнует практика совместной игры , как и в английском бильярде, но я понимаю, что это требует некоторого бай-ина). В примере с Канадой, я думаю, у нас было бы {{ Canada-footy-stub }} для футбола в Канаде и {{ CanadianFootball-stub }} для другой игры в канадский футбол (последний "Canadian", а не "Canada", потому что игра - это «канадский футбол», а не «канадский футбол», и окурок не обязательно указывает на национальность: на самом деле есть американские игроки канадского футбола, в основном профессионалы, которые больше не попали в НФЛ / АФЛ. Если бы их было так много, что им понадобилась бы собственная заглушка с биографией, я думаю, это был бы {{ US-CanadianFootball-bio-stub }}.)
Единственное и множественное число
В интересах централизации обсуждения, пожалуйста, перенесите сюда обсуждение {{ sport-stub }} и его родственников. Ее привязанность (это она сама) 15:40, 15 февраля 2007 г. (UTC)
- Не по этой теме, пожалуйста. Это слишком бинарно и враждебно. Проблема уже слишком поляризована. В настоящее время я думаю о более гибком способе решения этой темы, возможно, а может и нет с конкретными идеями ревизии WSS / NG. - SMcCandlish [ обсуждение ] [ вклад ]ツ22:53, 19 февраля 2007 г. (UTC)
- Пошли совершенно другим маршрутом. Я думаю, что такого рода проблемы с беспокойством следует решать где-то на 3-м уровне новой редакции этого документа; даже не тронет их прямо сейчас. Вместо этого я сделал пересмотр уровня 1, подробно описанный ниже! - SMcCandlish [ обсуждение ] [ вклад ]ツ10:53, 20 февраля 2007 г. (UTC)
Переделка, этап 1
Мне стало ясно после того, как я какое-то время работал с этим Википроектом и в последнее время пытаясь использовать его в качестве общего Википедии, что WSS / NG остро нуждается в капитальном ремонте:
- Это устарело
- Это сбивает с толку
- Это открыто для неправильного толкования
- Он открыт для различных, но одинаково обоснованных интерпретаций.
- Это не закончено
- Он никогда не переживет процесс предложения руководящих принципов WP
- Это непосредственно порождает раздоры и раздоры.
- среди других проблем.
Вместо того, чтобы просто начинать редактировать его со своими взглядами на то, как он должен работать, и прибегать к множеству аргументов, я предлагаю совершенно другой путь. Возвратное редактирование и процесс обсуждения на странице обсуждения могут работать при редактировании «живого» руководства или другого документа, и даже когда он работает плохо ( см. WP: N с ноября 2006 г. по январь 2010 г.). 2007), он по-прежнему может давать хорошие результаты (сравните WP: N от 31 октября 2006 г. с текущей версией! Вау, какая разница.) Но это медленный, антагонистический, болезненный процесс, в котором смешиваются основные правки, основанные на здравом смысле. с очень спорными изменениями, и противопоставляет гномов воинам мнения.
Вместо этого, я думаю , что это должно осуществляться в четко определенных этапах , и будет сделано в проектах копий реального projectpage, что , когда будет достигнут консенсус по текущему проекту, «живая» страница может быть заменена с этим проектом, новый этап обсуждается и запланирован, и начался еще один проект, начиная с текста предыдущего, для достижения целей на следующем этапе, и так далее, пока не будет достигнут очень прочный документ, отражающий широкий консенсус и готовый стать настоящим Руководством .
Первый этап, очевидно, - Очистка. Он призывает к полному мораторию на существенные изменения, то есть изменения характера, специфики, намерений, целей, объема и т. Д. Документа и процесса, который он документирует. Возникает соблазн сказать: «Эй, пока мы это делаем, давайте исправим это», или «Я вообще не согласен с этим, и думаю, что вместо этого он должен этого требовать», или «Может быть, нам следует расширить это включить ... "Этому искушению нужно противостоять, иначе этот процесс не сработает, и эксперимент потерпит неудачу.
Я, как и все мы (иначе мы не были бы в WSS!), Устаю от слов «кто-то должен ...», «я бы хотел, чтобы это было как ...», «почему не лучше?» вид мышления. Так что я просто пошел и сделал это .
Полученный в результате первый повторный набросок - это капитальный ремонт почти во всех отношениях. Тем не менее (если я не ошибся) не изменил ни одного из видов моратория (самое близкое, что он заменил совершенно неправдоподобное оправдание чего-либо правдоподобным, не изменив «что-то»). Каждое крупное изменение было подробно задокументировано здесь , так что процесс и обоснование изменений независимо друг от друга ясны (что очень редко случается, когда кто-то вносит серьезное редактирование в «действующий» документ). Задача заключалась в том, чтобы взять старую колотушку 72-го года и сделать из нее хот-род (с другой стороны; двигатель вообще не трогал, он работает точно так же, как и раньше, но теперь просто повернет головы. ). Если не считать неизбежных придирок, я думаю, что WSS в целом он действительно понравится.
Процесс: пожалуйста, перечитайте его, желательно после или во время просмотра журнала изменений, исправьте проблемы, которые вы видите с ним, без внесения каких-либо существенных изменений в его внутренности, и в какой-то момент, надеюсь, в ближайшее время мы сможем провести формальное или неформальное согласованное обсуждение о том, чтобы заставить его "жить". Обсуждения процесса или даже достоинств всей идеи «WSS / NC 2.0», которую я предлагаю, должны быть здесь, я предлагаю, в то время как те, которые касаются деталей нового проекта, должны быть на его странице обсуждения.
PS: Я бы предположил, что на втором этапе будут базовые улучшения функциональности политик, которые не вызывают споров (в исходном коде есть комментарии HTML, предлагающие некоторые из этих улучшений); третий, разрешение спорных моментов (например, упомянутых на странице обсуждения WSS / NC и которые поднимаются, в том числе мной, на WSS / P и WP: SFD); и 4-е, Предложение по руководству. Я считаю, что доведение этого документа до уровня Руководства Википедии очень важно.
- SMcCandlish [ обсуждение ] [ вклад ] ツ10:51, 20 февраля 2007 г. (UTC)
- Перспективное примечание: я сделал эту переделку, притворившись, что это копировальная работа от коммерческого клиента, действительно хорошего клиента, чей флагманский продукт мне не нравился в некоторых аспектах, и что я не был уполномочен каким-либо образом изменять какие-либо факты. маркетинговые стратегии, умысел спина, слоганов или других заранее определяется аспектами, только copyedit чтобы представить факты, перегонять маркетинговые стратегии, невидимка в spindoctoring и выделить лозунги. Попытайся! - SMcCandlish [ обсуждение ] [ вклад ]ツ11:30, 20 февраля 2007 г. (UTC)
Если нет возражений, давайте сделаем текущий доработанный проект "живым".
Поскольку здесь нет разногласий или на странице обсуждения первого пересмотренного черновика, я планирую заменить содержимое «живого» WSS / NG первым переработанным черновиком в течение следующего дня (и без HTML-комментариев «давайте исправим это» в Это). Я думаю, что это будет хороший шаг вперед для WSS, и это позволит в следующем раунде улучшений соглашения об именах продолжить поспешно. Ура! - SMcCandlish [ обсуждение ] [ вклад ] ツ09:43, 6 марта 2007 г. (UTC)
- Работаю над этим сейчас. - SMcCandlish [ обсуждение ] [ вклад ]ツ00:57, 8 марта 2007 г. (UTC)
- Сделанный. - SMcCandlish [ обсуждение ] [ вклад ]ツ02:31, 8 марта 2007 г. (UTC)
Редрафтинг, этап 2
На лекции в Википедии: Сортировка заглушек в WikiProject / Руководство по именованию / Redraft2 Я перечислил кучу маловероятных спорных улучшений для документа NG. Большинство из них уже были четко обозначены в Redraft1 как комментарии HTML, а некоторые взяты из обсуждения Redraft 1 . Упомянутые HTML-комментарии все еще (на момент написания этой статьи) присутствуют в Redraft2, чтобы указать вероятные точки вставки. В зависимости от того, когда вы это читаете, некоторые из них, возможно, уже были заменены новым текстом или удалены из-за споров. Я бы предложил, чтобы любой пункт в списке, который кто-то считает спорным в любом случае, был вычеркнут и сохранен для Фазы 3 перерисовки, рассмотрения спорных вещей. Некоторым из них может потребоваться согласованное обсуждение, чтобы определить, что именно они должны сказать / посоветовать. Давай сделаем это! - SMcCandlish [ обсуждение ] [ вклад ] ツ04:50, 8 марта 2007 г. (UTC)
- Никто не запал на это. Я предлагаю, чтобы текущий черновик №2 и текущая реальная страница могли быть довольно легко объединены, и что проект №3, который готовится к выпуску, решит проблему ниже и некоторые другие не вызывающие споров моменты, оставив только (ta-DAAA) дебаты о спорные детали, такие как спорт против спорта и другие кости на выбор (и см. WP: SFD - я, например, гораздо менее спорный по некоторым из этих пунктов). - SMcCandlish [ обсуждение ] [ продолжение ] ‹(- ¿-)› 08:47, 6 августа 2007 г. (UTC)
«Мажор» vs. «подразделение»
Последний пересмотренный вариант продвинул (по крайней мере, структурно по разделам, а также, по-видимому, и по значимости) выделение «основных» и «подразделений». Поразмыслив, я не думаю, что это имело особый смысл в первую очередь, и, следовательно, делать его более заметным - вовсе не хорошая идея. Что нам на самом деле нужно здесь сказать, помимо того, что шаблоны-заглушки имеют ряд компонентов (в наши дни нет недостатка в экземплярах с тремя или более), что они примерно иерархичны (хотя иногда и перестановки фактической иерархии, это должно можно сказать), и что каждый компонент представляет собой существительное (фразу), отражающее язык соответствующей категории, или его некоторую стандартизированную аббревиатуру. Алай 02:09, 19 марта 2007 (UTC)
- Хм. Учебный / пояснительный текст в двух разделах довольно сильно отличается. Мне кажется, что «основные» - это все или большая часть из верхнего уровня иерархии категорий WP или на один уровень глубже, в то время как «подразделенные» в основном географические. Я понимаю, о чем вы говорите, но не уверен, что делать с тем, что говорится в тексте. Наверное, медведи перечитают его пару раз и сыграют в песочницу с помощью alt. текст. - SMcCandlish [ обсуждение ] [ вклад ]ツ02:52, 19 марта 2007 г. (UTC)
- PS: Вы видели предложенную идею на странице обсуждения Redraft2 о их переименовании, поскольку названия "major" и "subdivisional" не так уж и полезны? - SMcCandlish [ обсуждение ] [ вклад ]ツ02:53, 19 марта 2007 г. (UTC)
- Трудно предложить, как перерисовать (или переименовать), если я не знаю, какова цель, и я далек от этого. Я подозреваю, что в значительной степени остались следы старых добрых времен, когда было много шаблонов XY-заглушек, но не намного длиннее, поэтому «биномиальная классификация» была, по крайней мере, в некоторой степени устойчивой. Но в настоящее время было бы немного странно предполагать, что {{ US-stub }} не имеет основных компонентов и имеет одно подразделение, и что {{ 1860s-baseball-pitcher-stub }} состоит из трех основных частей, а не подразделения. Или это тоже подразделения «декады» и «кувшины»? (Я не думаю, что «основные» части находятся выше в дереве категорий, как вы предлагаете, и даже не выше, чем «подразделения».) Alai 04:11, 19 марта 2007 г. (UTC)
- Я тоже не уверен. Как я уже говорил в «Фазе 1», моей целью при переработке было просто прояснить существующий материал без изменения чего-либо существенного. Это включало номенклатуру. Я согласен с тем, что описания этих вещей больше не соответствуют действительности, просто в то время я не собирался заниматься этим. Если вы думаете, что пора, я не вижу причин откладывать это. Может потребоваться ломка головы относительно того, что именно делать вместо существующей дихотомии, но так оно и есть. - SMcCandlish [ обсуждение ] [ вклад ]ツ04:16, 19 марта 2007 г. (UTC)
- Таковы опасности выполнения указанных задач. :) (Я не уверен, в какой степени это связано с тем, что вы сделали это различие более заметным или просто привлекли к нему внимание самим фактом внесения изменений.) По сути, как я это вижу, иногда у нас есть X - заглушка и Y-заглушка, с дочерним общим XY-заглушкой (или, в равной степени, у YX-заглушки ...); иногда у нас есть Y-заглушка верхнего уровня, разделенная на XY-заглушки различного типа (хотя иногда на самом деле на YX-заглушке по причинам «естественного использования» - на самом деле см. пример выше). В последнем случае можно утверждать, что существует различие между «основным» и «подразделением», но, учитывая, что оно не имеет значения как такового и не имеет строгих последствий для наименования ...
- Возможно, нам следует просто сначала сформулировать общий принцип переноса элементов в соответствии с иерархией категорий (кроме случаев переупорядочения); затем перечислите те элементы, которые особенно распространены и / или имеют «стандартные» сокращения; изложить некоторые принципы относительно форм некоторых родовых компонентов (страны / народности как существительные, а не прилагательные; десятилетия полностью, а не только последние две цифры и т. д.); и, наконец, сделайте несколько наблюдений и приведите несколько примеров того, в каком порядке располагаются эти элементы, когда есть исключение из принципа «иерархии» или где иерархия может быть прочитана в любом случае. Алай 04:52, 19 марта 2007 г. (UTC)
- Это имеет смысл в моем туннеле реальности. - SMcCandlish [ обсуждение ] [ вклад ]ツ05:13, 19 марта 2007 г. (UTC)
- Я тоже не уверен. Как я уже говорил в «Фазе 1», моей целью при переработке было просто прояснить существующий материал без изменения чего-либо существенного. Это включало номенклатуру. Я согласен с тем, что описания этих вещей больше не соответствуют действительности, просто в то время я не собирался заниматься этим. Если вы думаете, что пора, я не вижу причин откладывать это. Может потребоваться ломка головы относительно того, что именно делать вместо существующей дихотомии, но так оно и есть. - SMcCandlish [ обсуждение ] [ вклад ]ツ04:16, 19 марта 2007 г. (UTC)
- Трудно предложить, как перерисовать (или переименовать), если я не знаю, какова цель, и я далек от этого. Я подозреваю, что в значительной степени остались следы старых добрых времен, когда было много шаблонов XY-заглушек, но не намного длиннее, поэтому «биномиальная классификация» была, по крайней мере, в некоторой степени устойчивой. Но в настоящее время было бы немного странно предполагать, что {{ US-stub }} не имеет основных компонентов и имеет одно подразделение, и что {{ 1860s-baseball-pitcher-stub }} состоит из трех основных частей, а не подразделения. Или это тоже подразделения «декады» и «кувшины»? (Я не думаю, что «основные» части находятся выше в дереве категорий, как вы предлагаете, и даже не выше, чем «подразделения».) Alai 04:11, 19 марта 2007 г. (UTC)
Страны: прилагательное или существительное?
Видя, как это обсуждается в ЮФО постоянно, я подумал, что официально подниму этот вопрос здесь. При создании категорий страна считается прилагательным или существительным? Я создал таблицу с множеством различных примеров для иллюстрации.
Бывший. # | Permcat | Stub cat (имя существительное) | Котенок (прилагательное) |
---|---|---|---|
1а | Категория: Канада | Категория: Канадские заглушки | Категория: Канадские заглушки |
1b | Категория: Канадское право | Категория: Закон Канады | Категория: Канадские законы |
1c | Категория: География Канады | Категория: Заготовки по географии Канады | Категория: Заготовки по канадской географии |
1д | Категория: История Канады | Категория: Заготовки по истории Канады | Категория: Заготовки по истории Канады |
2а | Категория: Израиль | Категория: Израильские заглушки | Категория: Израильские окурки |
2b | Категория: Израильское право | Категория: Законопроекты Израиля | Категория: Законопроекты Израиля |
2c | Категория: География Израиля | Категория: Незавершенные статьи по географии Израиля | Категория: Незавершенные статьи по географии Израиля |
2d | Категория: История Израиля | Категория: Заготовки по истории Израиля | Категория: Заготовки по истории Израиля |
3а | Категория: Буркина-Фасо | Категория: Заготовки Буркина-Фасо | Категория: окурки буркинабские |
3b | Категория: Закон Буркина-Фасо | Категория: Законопроекты Буркина-Фасо | Категория: Законодательные статьи Буркина-Фасо |
3c | Категория: География Буркина-Фасо | Категория: Новости географии Буркина-Фасо | Категория: Заготовки о географии Буркина-Фасо |
3d | Категория: История Буркина-Фасо | Категория: Незабудки по истории Буркина-Фасо | Категория: Заготовки по истории Буркинабе |
- Пример 1 показывает страну с довольно распространенной формой прилагательного.
- Пример 2 показывает страну с менее распространенной формой прилагательного. Все еще предположительно, но не так очевидно.
- Пример 3 показывает страну с очень редкой формой прилагательного. Об этом не догадаться.
- Примеры (а) показывают кошку базовой страны. В этом случае следовать permcat несложно. Мы просто добавляем «заглушки» в конец.
- Примеры (b) показывают постоянный кот, который использует форму прилагательного. В этом случае также легко следовать permcat. Мы просто добавляем «заглушки» в конец.
- Примеры (c) показывают связанный с географией permcat, который использует форму существительного в конце.
- Примеры (d) показывают не связанный с географией permcat, который использует форму существительного в конце.
Примеры (c) и (d) (по крайней мере, в примере 1) показывают, что мы интерпретируем permcat «
Возникает вопрос: что важнее?
- Следуя permcat и используя формы существительных?
- Согласиться с другими коротышками и использовать формы прилагательного?
Идея # 1
- "<имя существительное>
" permcats → "<имя существительное> stubs" - "<прилагательное страны>
" permcats → "<прилагательное страны> заглушки" - "
in / of " permcats → " stubs"
Казалось бы, это обеспечивает наибольшую согласованность с permcats. Хотя это не обеспечивает 100% согласованности между всеми котами-окурками, по крайней мере, все коты-окорочки одного и того же типа (история, география и т. Д.) Будут внутренне непротиворечивыми.
Идея # 2
- "<имя существительное>
" permcats → "<имя существительное> stubs" - "<прилагательное страны>
" permcats → "<прилагательное страны> заглушки" - "
in / of " permcats → " stubs"
Это немного отклоняется от согласованности с permcats. Тем не менее, он создает категории заглушек, которые все похожи (за исключением заглушек стран высокого уровня, ( Категория: заглушки Канады, которые могут оставаться как есть).
Идея # 3
(Предложено Caerwine)
- "<имя существительное>
" permcats → "<имя существительное> stubs" - "<прилагательное страны>
" permcats → "<прилагательное страны> заглушки" - "
в / из <существительное страны>" permcats → " в / из <имя существительного страны> stubs"
Это создает наибольшую согласованность с пермкатами. Хотя некоторые люди сочли бы строительную категорию «История Канады» заглушкой неудобной, поскольку она требует контекста, чтобы знать, является ли она категорией для коротких статей по истории Канады или категорией для статей об истории незавершенных статей о Канаде, но факт в том, что что контекст здесь и во всех подобных случаях ослепляюще очевиден.
Обсуждение
Я отчасти предпочитаю идею №2, потому что она создает устойчивые тупики. Пермские кошки часто меняются, поэтому может быть трудно соблюдать их правила именования. Пока каждый stubcat все еще связан с соответствующим permcat (с использованием {{ Stub Category }}), все в порядке. ~ Amalas rawr = ^ _ ^ = 16:41, 28 марта 2007 г. (UTC)
- Как вы уже знаете, я решительно предпочитаю вариант 1 (фактически, это в основном то, что я предлагал в качестве системы для параллельного выполнения permcats). Одна из причин, по которой я предпочитаю его варианту 2, заключается в том, что довольно часто permcats сознательно избегали использования прилагательного по уважительной причине. Таким образом, использование прилагательной формы для коротких кошек не дает цели. Первый вариант использует форму прилагательного, когда это считается наиболее приемлемым для permcats, и сохраняет форму существительного, где формы прилагательного избегаются в permcats. Конечно, это не на 100% грамматически, но ни одна система, вероятно, никогда не будет на 100% грамматической, когда мы пытаемся добавить слово «заглушки» в конец существующей фразы. Однако это логично, последовательно и легко отслеживается. Более того, хотя он не полностью удаляет странные и часто не поддающиеся угадыванию прилагательные демонимы, он удаляет их в тех случаях, когда они не могут быть мгновенно проверены с помощью permcat. Я, например, предпочел бы не искать некоторые из более причудливых форм прилагательных (Киттиско-Невисийский? Буркинабский? Экватогвинейский? И-Кирибати?) Всякий раз, когда мне нужно выяснить, как назвать кота-окурка. Резкость ... что ? 00:51, 29 марта 2007 г. (UTC)
- Я вижу, что теперь есть третий вариант - я бы предпочел его варианту «нет». 2, хотя я понимаю, что в прошлом были возражения против него по грамматическим причинам. Тем не менее, как я сказал выше, все, что мы делаем, скорее всего, не будет на 100% грамматическим. Резкость ... что ? 23:26, 29 марта 2007 г. (UTC)
- Я решительно поддерживаю идею №3 (предложенную выше), но немного предпочитаю идею №1 идее №2 по причинам, которые приводит Грутнесс. Кэрвин Каэр скулит 04:26, 29 марта 2007 г. (UTC)
- Это не было полностью проанализировано. Грутнесс предпочитает №1 №2; Амалас предпочел №2. - SMcCandlish [ обсуждение ] [ вклад ]ツ00:05, 31 марта 2007 г. (UTC)
- Исправлено так, что он разбирает. Кэрвин Каэр скулит 06:39, 31 марта 2007 г. (UTC)
- Это не было полностью проанализировано. Грутнесс предпочитает №1 №2; Амалас предпочел №2. - SMcCandlish [ обсуждение ] [ вклад ]ツ00:05, 31 марта 2007 г. (UTC)
- Я бы тоже выбрал №3; просто кажется, что намного легче запомнить, и это меньше футзинга формата ради него. - SMcCandlish [ обсуждение ] [ вклад ] ツ00:08, 31 марта 2007 г. (UTC)
- Проблема №3 в том, что нам пришлось бы переименовать почти все наши географические категории. Permcats находятся в "Географии <место>", а все наши коты-окурки находятся в "<месте> заглушках географии". Мне неприятно видеть этот ЮФО ... ~ Amalas rawr = ^ _ ^ = 15:31, 2 апреля 2007 г. (UTC)
- Похоже, это была просто ранняя ошибка (или другой способ мышления), и что исправить ее может бот. - SMcCandlish [ обсуждение ] [ вклад ]ツ02:12, 3 апреля 2007 г. (UTC)
- Это означало бы много работы с ботами, но если мы сможем зафиксировать один из этих трех вариантов в качестве соглашения, то общая номинация (и это будет не только для географических категорий!), Вероятно, не вызовет особой суеты. сам по себе - это просто замена, которая была бы вредителем (но не хуже, чем удаление всех этих "связанных" примерно год назад). Я предлагаю, чтобы мы объявили, что это обсуждение продолжается с каким-то информационным окном на WP: SFD, хотя (возможно, как тот, который используется для изменения политики NOR, которое сейчас появляется в списках наблюдения). Резкость ... что ? 02:18, 3 апреля 2007 г. (UTC)
- На самом деле, переименовать кота с помощью бота нелегко. Необходимо создать новое имя, а старое - удалить. Очень много времени. Но я полагаю, что независимо от того, какой путь мы выберем, потребуется масштабное переименование, так что этот вопрос в любом случае довольно спорный. ~ Amalas rawr = ^ _ ^ = 13:52, 3 апреля 2007 г. (UTC)
- Это означало бы много работы с ботами, но если мы сможем зафиксировать один из этих трех вариантов в качестве соглашения, то общая номинация (и это будет не только для географических категорий!), Вероятно, не вызовет особой суеты. сам по себе - это просто замена, которая была бы вредителем (но не хуже, чем удаление всех этих "связанных" примерно год назад). Я предлагаю, чтобы мы объявили, что это обсуждение продолжается с каким-то информационным окном на WP: SFD, хотя (возможно, как тот, который используется для изменения политики NOR, которое сейчас появляется в списках наблюдения). Резкость ... что ? 02:18, 3 апреля 2007 г. (UTC)
- Похоже, это была просто ранняя ошибка (или другой способ мышления), и что исправить ее может бот. - SMcCandlish [ обсуждение ] [ вклад ]ツ02:12, 3 апреля 2007 г. (UTC)
- Я предпочитаю вариант 1, сам. Вариант 2 имеет проблемы с непонятными прилагательными, а вариант 3 звучит неуклюже и сбивает с толку. Crystallina 02:18, 5 апреля 2007 г. (UTC)
- Вы можете уточнить? Я не понимаю, что вы имеете в виду под «неуклюжим и сбивающим с толку» в отношении пункта 3, который мне кажется самым простым и понятным. Может быть, вы думаете о гипотетических примерах, которые мне в голову не приходили, или что-то в этом роде. - SMcCandlish [ обсуждение ] [ продолжение ] ‹(- ¿-)› 14:44, 18 апреля 2007 г. (UTC)
- 2 ¢ / 2 €: Везде , где это возможно, использовать прилагательное как прилагательное, в противном случае « тема из существительного » (например, ради индексации, последовательной иерархии, и т.д.). По крайней мере, это то, что, кажется, работает большую часть времени. С уважением, Дэвид Кернов (выступление) 06:26, 10 апреля 2007 г. (UTC)
- Для меня это в значительной степени связано с вариантами №1 и №2. Пн, 13:40, 29 апреля 2007 г. (UTC)
- В общем, я предлагаю, чтобы мы предпочли форматы <имя существительного страны>, независимо от того, относятся ли они к типу «
in / of Страновые прилагательные вызывают проблемы в очень многих случаях: есть такие, как Буркина-Фасо, для которых прилагательное неясно, и другие, такие как Новая Зеландия и Демократическая Республика Конго, где явно отсутствует форма прилагательного. Затем есть те, для которых обычно используемое прилагательное неточно, например British для Соединенного Королевства . Поэтому я предпочитаю любое решение, которое избавляет от наибольшего числа прилагательных. - BrownHairedGirl (обсуждение) • ( вклад ) 18:59, 8 мая 2007 г. (UTC)» или « ».
- В общем, я предлагаю, чтобы мы предпочли форматы <имя существительного страны>, независимо от того, относятся ли они к типу «
- Первый принцип должен заключаться в том, что названия категорий-заглушек разумны как названия категорий . Это особенно верно с учетом того, что, хотя они и не являются «обычными» категориями пространства статей, они все же появляются в одной и той же иерархии (в отличие от категорий вне-и-обслуживания и википроектов). Соответственно, я не думаю, что приемлемо иметь «схему», которая «генерирует» названия категорий, которые были бы мгновенно удалены, если бы они были permcats («География Франции» и т. Д.), Из-за серьезного несоответствия нормальному использованию, которые летают только потому, что типы заглушек имеют отдельный жизненный цикл от permcats. Для меня это исключает № 1, по крайней мере, во всех случаях, когда существительное не является приемлемым атрибутивным атрибутом (все довольны существительным «Новая Зеландия» в качестве атрибута; кишки козла, кажется, дают смешанные сообщения о «Соединенном Королевстве». и "Соединенные Штаты", хотя это больше связано с тем, как точно следовать permcat, а не с тем, является ли это разумным использованием само по себе).
- Вариант №3 иногда кажется неудобным не из-за какой-либо контекстуальной двусмысленности, а потому, что он действительно неудобен: именная фраза с предложениями обычно не используется атрибутивно, особенно если она явно «переписываемая» для использования прилагательного (или множественной атрибутивности) вместо. Но иногда эквивалент №2 так же плох или хуже, поэтому я не думаю, что его следует обязательно избегать во всех случаях (и если это так или №1 в «мгновенном выпуске» / STV, он определенно превосходит последний. ). Менее непоследовательно наличие двух разных атрибутивных фраз (или префиксов, которые обычно не используются атрибутивно).
- Я бы предпочел "модифицированный № 2": вместо того, чтобы настаивать на полноценном прилагательном, я бы считал приемлемой любую фразу в атрибутивном использовании, с выбором, который должен быть сделан в соответствии со стилем, частотой использования, объемом ясность, нейтральность и максимальная горизонтальная согласованность. В тех случаях, когда предположительно каноническое прилагательное неясно или имеет проблемы с определением объема / нейтральностью, то, как правило, использование именной фразы является приемлемым и довольно частым использованием именно по этой причине.
- Имейте в виду, что названия категорий заглушек редко приходится «угадывать», особенно по сравнению с именами permcat, поэтому некоторые теоретические отклонения менее обременительны, чем в пространстве permcat (где они, тем не менее, довольно широко распространены), и должны быть сопоставлены со многими другими люди, которые воспринимают их как читателей (независимо от того, являются ли они редакторами или нет, поскольку меньше редакторов вообще редактируют их напрямую, и даже те, кто это делают, почти всегда делают гораздо реже).
- Обратите внимание, что - по крайней мере теоретически - ни одно из этих изменений (в любом из направлений) не потребует редактирования ботов; перекаттинг будет помещен в очередь заданий, и пока он не будет запущен в этот день, категории в конечном итоге будут изменены во всех статьях. Тем не менее, это все еще потенциально довольно много правок вручную. (По крайней мере, два правки и удаление для каждой категории, а часто и больше, когда есть подкатегории, ссылки и случай, о котором нужно позаботиться, ошибочно "отобранная" статья). Если мы решим не № 1, мы, вероятно, захотим Оставьте географию напоследок, просто из-за огромного количества цифр: мы могли бы в конце концов начать это делать, а затем, в конце концов, получить поток новейших материалов, говорящих о чем-то другом. Если мы хотим сделать географию «защищенным исключением», я мог бы даже смириться с этим. Алай 04:36, 14 мая 2007 г. (UTC)
- Я бы предпочел имена все существительные. Хотя бы из-за иногда трудно предсказуемого существительного -> сопоставления прилагательного. Последовательность - это хорошо, но не за счет ясности. - Корен (разговор) 19:56, 9 июля 2007 г. (UTC)
Заключение
Я прочитал все голоса / обсуждения всех и обнаружил, что № 3, похоже, является консенсусом. Я использовал систему «одобрительного голосования», чтобы люди могли голосовать за любое количество идей, которые, по их мнению, будут работать. Если кому нужна поломка, могу ее предоставить. Я не уверен, каков следующий шаг, но уверен, что он включает в себя множество переименований в SFD. ~ Amalas rawr = ^ _ ^ = 15:33, 7 августа 2007 г. (UTC)
Заготовки "на проект"
Я был удивлен, увидев, что {{ UK-waterway-stub }} так быстро номинировали на удаление. Хотя я не знал об этих рекомендациях и связанном с ними процессе, когда создавал его (они, кажется, не очень хорошо разрекламированы), мне кажется разумным, что должна быть возможность иметь тип заглушки с соотношением 1: 1. связь с каждым WikiProject (в данном случае WikiProject UK Waterways ). Мета-категория, такая как заглушки, связанные с проектом, может быть полезным дополнением. Энди Маббетт, 09:16, 19 апреля 2007 г. (UTC)
- Точно нет. Типы-заглушки не предназначены специально для использования отдельными проектами Wiki - они предназначены для использования всей Википедией, и поэтому им необходимо придерживаться как можно более единообразной схемы. У отдельных проектов есть свой собственный, совершенно другой механизм оценки статей, относящихся в первую очередь к ним - система оценок WikiProject на странице обсуждения. Эта система гораздо более адаптируется к потребностям отдельных Wiki-проектов, а также позволяет присваивать рейтинг всем относящимся к ней статьям, а не только заготовкам. Таким образом, для WikiProjects имеет гораздо больше смысла использовать это, чем пытаться заставить шаблон-заглушку соответствовать цели, для которой он не подходит оптимально, и при этом сгибать общую иерархию заглушек, чтобы приспособить ее. Если WikiProject работает через систему заглушек в масштабе WP, это не означает автоматически, что создание для него типа заглушки является хорошей идеей - по этой причине многие проекты WikiProject не имеют определенных типов заглушек. Учитывая, что UK Waterways WikiProject является одним из таких проектов, я бы посоветовал изучить использование системы оценки страниц обсуждения, а не типа заглушки. Резкость ... что ? 10:29, 19 апреля 2007 г. (UTC)
Заголовок текста ashish stubs
любезно напишите больше об индийских революционерах и героях
- Это сортировка заглушек Википроекта , а не написание заглушек . Сортируем уже написанные заглушки. Если вам нужно больше статей на определенную тему, лучше всего их написать. Резкость ... что ? 09:44, 12 июня 2007 г. (UTC)
Заключение
Кто-то, кто может найти свои очки и не испытывает напряжения глаз, которое у меня сейчас есть, должен прочитать все это и подвести итог. Последнее редактирование на projectpage было +19 Июню 2 007 . Нам давно пора закрыть это предложение либо с достижением консенсуса относительно каких-либо действий, либо с результатом «отсутствия консенсуса». И в любом случае с удалением ревущих желтых ящиков с предупреждениями на главных страницах, чтобы люди перестали приходить сюда и зевать, когда они осознают, насколько смертоносными являются дебаты. > ;-) - SMcCandlish [ обсуждение ] [ продолжение ] ‹(- ¿-)› 08:39, 6 августа 2007 г. (UTC)
PS: Сначала я понял, что #Countries: прилагательное или существительное? могут быть приняты меры , как и тема, непосредственно предшествующая этому, # "Major" vs. "subdivisional" - SMcCandlish [ talk ] [ продолжение ] ‹(- ¿-)› 08:44, 6 августа 2007 г. (UTC)
- Я опубликовал заключение и удалил все окна с предупреждениями. ~ Amalas rawr = ^ _ ^ = 15:38, 7 августа 2007 г. (UTC)
Переименовать в WP: WSS / Соглашения об именах
Посмотрим правде в глаза, WP: WSS рассматривает эту страницу как набор соглашений об именах, а не просто руководящих принципов, и страницу часто называют таковой. Шаблоны и категории часто переименовываются в WP: SFD, чтобы соответствовать установленным здесь стандартам, а реквизиты часто изменяются, чтобы соответствовать правилам этой страницы. По существу, для этой страницы было бы гораздо разумнее «сделать ее официальной», если бы она находилась в Википедии: WikiProject Stub sorting / Naming Conventions . В конце концов, эта страница уже давно значится как подстраница википедии: Соглашения об именах ; как таковой это было бы просто формализацией этой ситуации.
Я почти уверен, что это поднималось в прошлом и в целом поддерживалось, но я не могу найти ссылку на обсуждение (архивы WP: WSS и всех его подстраниц, мягко говоря, запутаны). если это так (и записи об этом можно где-то найти), тогда - если нет серьезных возражений - перемещение этой страницы должно быть выполнено довольно скоро. Резкость ... что ? 07:29, 18 августа 2009 г. (UTC)
- Я всегда думал, что эта страница называется «соглашениями об именах», поэтому я не вижу здесь проблем. Waacstats ( обсуждение ) 12:20, 18 августа 2009 г. (UTC)
- Хорошо, хорошо, если не будет возражений, скажем, на следующей неделе, я перенесу страницу. Резкость ... что ? 01:32, 21 августа 2009 г. (UTC)
- Ничего за или против больше шести дней ... наверное, достаточно близко. Перемещение страницы ... Резкость ... Что? 05:38, 27 августа 2009 г. (UTC)
- Хорошо, хорошо, если не будет возражений, скажем, на следующей неделе, я перенесу страницу. Резкость ... что ? 01:32, 21 августа 2009 г. (UTC)
Уведомление о влиянии RFC на эту страницу
Википедия: Деревенский насос (предложения) #RFC по роспуску Wikiproject Stub Sorting . - Red rose64 🌹 ( обсуждение ) 10:08, 6 апреля 2018 г. (UTC)