Обсуждение пользователей: Матиаспол

Список сокращений в фотографии [ править ]

Привет! Спасибо за ваш полезный вклад в список фотографических сокращений, который я начал несколько месяцев назад. Долгое время казалось, что я один работаю над этим. Я рад, что у меня есть другие специалисты по расширению и исправлению ошибок. Я составил список, когда вернулся к серьезной фотографии в цифровую эпоху после долгого отсутствия в 35-мм пленочной фотографии. Я нашел многочисленные сокращения, которые использовались в цифровых дискуссионных группах, сбивающими с толку, поэтому я начал их перечислять, отчасти для самообразования, а отчасти потому, что такие новички, как я, не имели легкого доступа к перечисленным объяснениям. Всех помощь приветствую! martinev ( разговор ) 13:59, 5 сентября 2011 (UTC)

И тебе спасибо. - Матиаспол ( разговор )

Информация об авторстве старой правки [ править ]

Просто для записи, я хочу подтвердить, что следующие правки IP в англоязычной Википедии принадлежат мне (на случай, если по ним возникнут вопросы и кто-то захочет связаться со мной):

• 1 правка под IP 84.63.54.118 от 2006-11-05T03: 53: 55 к статье:

Carl Zeiss AG

• 5 правок под IP 84.63.15.78 между 2007-02-11T02: 42: 21 и 2007-02-11T02: 54: 00 в статье:

Carl Zeiss AG

• 2 правки под IP 84.63.26.89 между 2007-02-11T03: 10: 22 и 2007-02-11T03: 14: 18 в статье:

Carl Zeiss AG

• 3 правки под IP 80.137.104.82 между 2007-02-12T05: 45: 50 и 2007-02-12T05: 57: 16 в статьях:

Carl Zeiss AG , Minolta AF

• 13 правок под IP 84.63.32.95 между 2007-02-12T19: 07: 21 и 2007-02-12T19: 56: 24 статей:

Carl Zeiss AG

• 1 правка под IP 84.63.35.82 от 2007-02-25T13: 10:07 на статью:

Carl Zeiss AG

• 3 правки под IP 84.63.52.179 между 2007-02-28T11: 07: 20 и 2007-02-28T11: 09: 35 в статье:

Carl Zeiss AG

• 2 правки под IP 84.63.10.5 между 2007-03-01T12: 34: 15 и 2007-03-01T12: 37: 03 в статье:

Carl Zeiss AG

• 1 правка под IP 84.63.56.115 от 2007-03-03T21: 21: 48 к статье:

Carl Zeiss AG

• 1 правка под IP 84.63.16.87 2007-03-09T03: 14: 29 в статье:

Carl Zeiss AG

• 2 правки под IP 84.63.7.199 между 2007-07-19T00: 40: 04 и 2007-07-19T00: 45: 27 в статье:

Carl Zeiss AG

• 4 правки под IP 84.63.51.146 между 2007-07-20T23: 43: 59 и 2007-07-21T00: 20:55 в статье:

Carl Zeiss AG

• 1 правка под IP 84.63.43.156 2007-09-08T06: 09: 28 в статье:

Carl Zeiss AG

• 1 правка под IP 84.63.24.232 от 2007-10-03T00: 08: 35 к статье:

Боке

• 1 правка под IP 84.63.4.241 от 2007-11-10T18: 35: 26 к статье:

Carl Zeiss AG

• 2 правки под IP 84.63.55.36 между 2007-11-11T01: 42: 21 и 2007-11-11T01: 44: 28 в статье:

Carl Zeiss AG

• 2 правки под IP 84.63.25.174 между 2009-07-20T22: 39: 24 и 2009-07-21T10: 11: 56 в статье:

SilverFast

• 2 правки под IP 84.63.19.99 между 2009-07-29T01: 12: 21 и 2009-07-29T01: 13: 56 в статье:

SilverFast

• 33 правки под IP 84.63.52.9 между 2009-10-01T17: 58: 20 и 2009-10-09T19: 03: 37 статей:

Видео Floppy , Sony Mavica , полный кадр цифровой SLR , Обсуждение: Sony Alpha , Кроп - фактор , Обсуждение: Кроп - фактор , Херберт Кеплер , Kodak DCS Pro 14n , Kodak DCS Pro SLR / л , Kodak DCS Pro SLR / с , Обсуждение: Nikon D3 , Шаблон: Цифровые зеркальные камеры Konica Minolta / Sony

• 9 правок под IP 84.63.26.178 в период с 2009-10-13T03: 26: 16 и 2009-10-17T17: 06:50 статей:

Bulb (фотография) , Обсуждение: Bulb (фотография) , Полнокадровая цифровая SLR , Sony Alpha , Шаблон: Цифровые зеркальные камеры Nikon

• 2 правки под IP 88.77.199.34 между 2010-07-03T20: 57: 11 и 2010-07-03T21: 23: 58 в статье:

Герберт Кепплер

• 5 правок под IP 88.77.213.52 между 2010-07-20T12: 37: 09 и 2010-07-20T12: 55: 57 статей:

Sony Mavica , байонет Sony E

• 1 правка под IP 88.77.193.105 от 17.10.2010T18 : 33: 01 к статье:

Антиб

• 2 правки под IP 88.77.204.184 между 2010-10-17T18: 56: 36 и 2010-10-17T19: 04: 20 в статьях:

Обсуждение файлов: Château Grimaldi, Antibes, Alpes-Maritimes, France.jpg

• 2 правки под IP 88.77.222.170 между 2010-10-17T22: 54: 42 и 2010-10-17T23: 03: 02 в статьях:

Википедия: График Lab / Фотография семинар , Обсуждение файла: Château Гримальди, Антиб, Альпы Приморский, France.jpg

• 1 правка под IP 84.63.115.171 на 2010-12-18T17: 16: 19 к статье:

Кодирование DX

• 1 правка под IP 88.76.55.197 от 26.02.2011 T16 : 32: 50 к статье:

Ртутный аккумулятор

• 7 правок под IP 88.76.59.246 между 2011-04-03T20: 18: 29 и 2011-04-04T17: 30: 29, а также в статьях:

Ультразвуковой двигатель , SSM , SDM , HSM , Xsm , USD

• 4 правки под IP 88.77.214.179 между 2011-05-01T21: 25: 00 и 2011-05-01T22: 57: 12 в статьях:

Код AARD , Разговор: Код AARD

• 3 правки под IP 92.72.226.118 между 2011-05-04T03: 52: 31 и 2011-05-04T13: 21: 53 в статье:

башмак для вспышки iISO

• 1 правка под IP 88.76.47.138 от 2011-04-25T03: 38: 20 в статье:

Ян Каллимор

• 12 правок под IP 84.63.113.180 между 2011-07-11T01: 50: 44 и 2011-07-10T19: 46: 56 статей:

Приоритет выдержки , Диск переключения режимов , Приоритет диафрагмы , число f

• 5 правок под IP 88.77.195.147 в период с 2011-07-11T11: 16: 39 и 2011-07-11T20: 43: 36 статей:

f-число , Обсуждение: f-число

• 2 правки под IP 88.77.221.243 между 2011-07-12T19: 02: 55 и 2011-07-12T19: 04: 26 в статье:

Система APEX

• 1 правка под IP 88.76.63.184 на 2011-07-14T19: 36: 23 в статье:

Скорость пленки

• 5 правок под 88.76.55.125 между 2011-07-23T02: 25: 55 и 2011-07-23T03: 14: 50 в статье:

Кодирование DX

• 1 правка под 88.77.214.88 от 2011-07-23T13: 07: 53 в статье:

Кодирование DX

• 3 правки под IP 88.77.217.152 между 2011-07-24T13: 49: 32 и 2011-07-24T20: 50: 05 в статье:

Скорость пленки

• 35 правок под IP 88.77.217.84 между 2011-07-25T10: 53: 40 и 2011-07-26T05: 20: 14 в статьях:

Скорость пленки , Обсуждение: Скорость пленки , Шаблон: стандарты ISO , Список стандартов DIN , ISO 518 , Список стандартов Международной организации по стандартизации , Международная организация по стандартизации

• 9 правок под IP 88.76.53.220 между 2011-07-26T10: 43: 59 и 2011-07-26T18: 22: 45 в статьях:

Скорость пленки , Обсуждение: Скорость пленки

• 2 правки под IP 88.77.219.92 между 2011-07-26T21: 22: 06 и 2011-07-26T23: 31: 50 в статьях:

Юлиус Шайнер , Обсуждение: Скорость пленки

• 43 правки под IP 84.63.121.25 между 2011-07-27T09: 31: 48 и 2011-07-28T05: 22: 38 в статьях:

Скорость фильма , Эдвард Уэстон (значения) , Уэстон , Эдвард Уэстон (химик) , Уэстон (фамилия) , Ge , HD , SCH , Deutsches Institut für Normung , Фердинанд Хертер , Веро Чарльз Дриффилд , Хертер и Дриффилд

• 26 правок под IP 88.77.212.191 в период с 2011-07-28T11: 04: 33 и 2011-07-29T01: 14: 22 в статьях:

Светочувствительности пленки , Фотопленка , Обсуждение: светочувствительности пленки

• 7 правок под IP 88.77.198.150 между 2011-07-29T10: 29: 39 и 2011-07-29T11: 58: 30 в статьях:

Скорость пленки , Хертер и Дриффилд , Разговор: Скорость пленки

• 38 правок под IP 88.77.221.103 между 2011-07-30T13: 18: 48 и 2011-07-31T05: 23: 27 в статьях:

Скорость пленки , Хертер и Дриффилд , Йозеф Мария Эдер , Эдвард Вестон (химик) , ISO 6 , ISO 2240 , ISO 5800 , Фердинанд Хертер , Веро Чарльз Дриффилд , Американский национальный институт стандартов , ISO 12232 , Обсуждение: Скорость пленки , Гудвин (фамилия) , Обсуждение: Медаль Говарда Н. Поттса , Гудвин , Леон Уорнерке , Сенситометрия

• 20 правок под IP 88.77.216.217 между 2011-07-31T12: 31: 54 и 2011-08-01T00: 44: 51 в статьях:

Йозеф Мария Эдер , Скорость фильма , Разговор: Скорость фильма , Леон Варнерке , Эдвард Уэстон (химик)

• 5 правок под IP 88.77.222.188 между 2011-08-01T11: 15: 00 и 2011-08-01T17: 19: 41 в статьях:

Пленка , Canon A-1 , Фокальный затвор

• 19 правок под IP 84.63.123.118 между 2011-08-02T11: 18: 41 и 2011-08-03T01: 12: 31 в статьях:

Хертер и Дриффилд , Скорость фильма , Лойд А. Джонс , Фердинанд Хертер , Веро Чарльз Дриффилд , Йозеф Мария Эдер , Альфред Уоткинс , Леон Варнерке , Джулиус Шайнер

• 12 правок под IP 88.77.201.19 между 2011-08-03T10: 40: 56 и 2011-08-03T14: 20: 49 в статьях:

Йозеф Мария Эдер , Скорость пленки , Уильям де Вивелесли Абни , Скорость пленки , Сенситометрия , Обсуждение: Kodachrome , Эдвард Уэстон (химик)

Я больше не использую эти динамические IP-адреса и не претендую на авторство правок в отношении этих IP-адресов до или после указанных выше диапазонов дат.

Было больше публикаций в англоязычных и иностранных Википедиях, в частности, в немецкой Википедии, но их трудно вспомнить после стольких лет. До сих пор самая ранняя редакция, которую я мог отследить, была от 2 июля 2005 года. В основном из собственного любопытства я продолжу документировать их, когда я случайно наткнусь на них, но, возможно, когда-нибудь в будущем станет технически возможным объединить такие изменения IP в учетную запись пользователя. Посмотрим.

- Матиаспол ( разговор )

БЕЗЗЕРКАЛЬНЫЕ КАМЕРЫ С СМЕННЫМ ОБЪЕКТИВОМ (MILC) [ править ]

Привет, Матиас. Я думаю, вы не совсем понимаете последствия полного включения Pentax Q в категорию MILC. На самом деле, MILC были изначально разработаны для «обеспечения SRL-подобного изображения в небольшом корпусе», тогда как - из-за своего сенсора - Pentax Q представляет собой просто «компактную камеру со сменными объективами», без преимущества в качестве изображения по сравнению с остальными компактными камерами. . Следовательно, включив его в MILCS, вы фактически измените исходное определение MILC  !! Я согласен с очень расплывчатым и плохим определением, потому что в аббревиатуре MILC нет упоминания о «большом датчике». тем не менееЕсли вы хотите использовать MILC для того, что это буквально означает, и применить его ко всем беззеркальным камерам со сменными объективами, вы не можете остановиться, отредактировав введение: вам нужно отредактировать все последующие абзацы, в которых говорится, что MILC обеспечивают лучшее изображение, чем компактная камера. !! Не все "ваши MILC" делают !! Таким образом, вы либо переходите к редактированию всей статьи, либо ее нужно вернуть в предыдущее состояние. Теперь это противоречиво и ложно . Маркус МаркусGR ( разговор ) 17:47, 4 октября 2011 (UTC)

Привет, Маркус. Проблема с исходным определением МИЛК в том, что его нет. Пожалуйста, укажите мне авторский источник, в котором он определен, я совершенно уверен, что вы его не найдете. Таким образом, термин составлен нечетко. Вот почему у разных людей разные представления о том, что это может означать. Насколько мне известно, я интерпретирую это буквально и не вижу в нем никакого подразумеваемого значения, такого как «больший сенсор, чем в компактных цифровых камерах», «лучшее качество, чем в компактных», «качество как у зеркальных фотокамер». Это просто маркетинговый ход и не имеет отношения к статье. Поэтому я предлагаю сохранить вступление статьи без каких-либо подразумеваемых предположений. В конце концов, WP - это энциклопедия,и мы должны быть очень осторожны в наших формулировках, чтобы сами не придумывать новые термины и значения или позволить WP стать инструментом вирусного маркетинга. Если существует несколько реальных или предполагаемых значений термина, мы не должны тем или иным образом чистить статью (что только создаст новую предвзятость), а обсудить эти различные определения ниже в статье (но не во вступлении, это просто там не место). И мы должны быть осторожны, используя нейтральный язык. Честно говоря, мой интерес к статье ограничен (до тех пор, пока она остается в общем плохом состоянии), я просто видел слишком много отвлекающего жаргона и мельницы слухов, появляющихся во вступлении, и поэтому попытался предложить еще какое-то энциклопедическое направление по дальнейшему развитию статьи. Кажется, вы хотите внести свой вклад в статью, поэтому, пожалуйста,но, возможно, попытайтесь использовать менее «восторженный» язык, учитывая, что это не форум или что-то подобное, а энциклопедия. Всего наилучшего. -Матиаспол ( разговор ) 12:18, 5 октября 2011 (UTC)

Размеры фотометрических единиц [ править ]

Привет, Матиаспол. Можете ли вы ответить на вопрос в беседе о шаблоне: Световые единицы СИ # Неверный столбец размеров? , о столбце Размеры, который вы добавили в Шаблон: световые единицы СИ ? - Срлеффлер ( доклад ) 03:11, 5 октября 2011 г. (UTC)

Ответ дан на странице обсуждения. - Матиаспол ( разговор ) 12:18, 5 октября 2011 г. (UTC)

WP: VPT [ править ]

Спасибо за очистку моего WP: неправильное редактирование VPT . По крайней мере, теперь я знаю, куда делся мой набор текста. - Депип ( разговор ) 21:15, 15 октября 2011 г. (UTC)

;-) Рад, что смог помочь. Думаю, это случалось со всеми нами временами ... - Матиаспол ( разговор )

Barnstar [ править ]

Спасибо. - Матиаспол ( разговор ) 09:15, 10 ноября 2011 г. (UTC)

Talkback [ править ]

IEP очистка [ править ]

Здравствуй. Если вы столкнетесь с множеством разрушительных правок IP, которые привязаны к Индии, или если отдельные IP-адреса имеют историю постоянных нарушений, особенно в таких статьях, как Пятилетние планы Индии , сообщите мне напрямую, и я рассмотрю возможность полузащиты страницы и / или блокирование нарушителей. Спасибо. - Кудпунг กุด ผึ้ง ( разговор ) 03:38, 2 ноября 2011 (UTC)

Ага. - Матиаспол ( разговор )

Ваш запрос на откат [ править ]

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

• Откат не более важен, чем установка Twinkle .
• Откат никогда не следует использовать для редактирования войны .
• В случае злоупотребления права отката могут быть отозваны.
• Используй здравый смысл.

Если вам больше не нужен откат, напишите мне, и я его удалю. Кроме того, для получения дополнительной информации о том, как использовать откат, см. Википедия: Новая школа администрирования / Откат (даже если вы не являетесь администратором). Я уверен, что вы справитесь с откатом, но не стесняйтесь оставлять мне сообщение на моей странице обсуждения, если у вас возникнут проблемы или возникнут какие-либо вопросы о правильном / несоответствующем использовании отката. Спасибо за помощь в уменьшении вандализма. Удачного редактирования! Swarm ^X 20:04, 2 ноября 2011 г. (UTC)

PS Спасибо за ваши усилия по очистке и продолжайте в том же духе. Swarm ^X 20:04, 2 ноября 2011 г. (UTC)

Спасибо. - Матиаспол ( разговор )

Две звезды по цене одной! (Как часто вы это видите?) [ Править ]

Между прочим, вы могли бы критиковать анализ закона Планка # Crash_course_in_radiometry, если вы видите какие-либо возможности для исправлений, улучшений и т. Д. Эта статья находится под осадой с 13 октября, учитывая аномальный уровень трафика на ее странице обсуждения с тех пор. . - Воан Пратт ( разговор ) 06:58, 10 ноября 2011 г. (UTC)

Какой приятный сюрприз, спасибо. ;-) Я сейчас очень занят, но посмотрю, когда позволит время. - Матиаспол ( разговор ) 09:15, 10 ноября 2011 г. (UTC)

Множественное наследование [ править ]

Здравствуй. Спасибо за ответ. Я считаю, что сообщество обеспокоено этой очень серьезной проблемой copyvio. Я знаю, что многие из моих однокурсников сделали то, что действительно печально. Приношу извинения от их имени. Но я не понимаю необходимости полностью удалять свое содержимое со страницы, даже если это не было подтвержденным copyvio. Я имею в виду, что я покажу своему инструктору? Срок моего проекта также истек. Подскажите, пожалуйста, что мне делать. Также наш инструктор сообщил, что необходимо прекратить все дальнейшие правки в википедии. Думаю, это ответ на ваш вопрос. РАДЖАТПАСАРИ ( разговор ) 08:07, 10 ноября 2011 (UTC)

Ответ дан на странице обсуждения. Надеюсь, тебе удастся разобраться с этим, Раджат. - Матиаспол ( разговор )

«необъяснимое добавление тегов» [ править ]

Я дал пояснение в первом параметре {{ prod }}: по моему мнению, статьи, которые я помечал, не соответствовали критериям известности . Возможно, мне следовало быть более многословным: я не смог найти значительного освещения в нескольких надежных источниках, и я серьезно сомневаюсь, что кто-то может его найти (и, кстати, " Doscore ", скорее всего, был создан в нарушение WP: COI , но я решил не поднимать этот вопрос; должно быть достаточно не быть заметным). В конце концов, если бы тематика статей была заметной, добавить к ним надежные источники было бы легко, верно? Но именно этого вы не сделали, хотя бремя доказательства того, поддается ли контент проверке, лежит на том, кто утверждает, что он. Поэтому я думаю, что удаление этих тегов еще менее оправдано, и поправьте меня, если я ошибаюсь, но, учитывая ваше резюме редактирования, мне это кажется просто актом злобы. Что касается «повестки дня по удалению большого количества статей» - ну да, я сторонник удаления . И немедленный помощник тоже. И я случайно наткнулся на несколько страниц, которые, на мой взгляд, не заслуживали включения. Чего мне ждать, прежде чем предлагать каждый из них для удаления? Спасибо за внимание. 212.87.13.73 ( разговорное ) 22:13, 19 ноября 2011 (UTC)

Просьба о времени: обучение по программе образования в Индии [ править ]

Здравствуй. Я пишу с просьбой об одолжении. Пилотная программа образования для Индии завершается в Пуне, Индия. Это было чрезвычайно сложно, и из пилотного проекта был извлечен ряд уроков, которые мы намерены принять во внимание, чтобы определить дальнейший путь. Я обещал честный, открытый и всесторонний обзор. Есть несколько способов, которыми мы пытаемся сопоставить и выделить эти знания. Одна из них заключается в том, что Фонд заказал исследование для проведения подробных интервью с широким кругом людей, которые прямо или косвенно участвовали в пилотном проекте. Сюда входят обсуждения со студентами, послами, преподавателями, а также с такими членами мирового сообщества, как вы. Я подумал, что было бы действительно полезно, если бы мы могли узнать ваше мнение. Вы участвовали в проекте (хотя и не в рамках официальной структуры проекта.) Благодарю за участие. Вы сделали несколько интересных и проницательных комментариев в ходе обсуждений, в которых участвовали. Будете ли вы готовы и доступны для человека, работающего над этим исследованием, чтобы он мог получить ваши отзывы, предложения и комментарии? Если да, не могли бы вы сообщить мне об этом на моей странице обсуждения? Также дай мне знать, как я могу заставить ее связаться с тобой. Спасибо заранее.Хишам ( разговор ) 10:01, 23 ноября 2011 (UTC)

Спасибо, Хишам. Я ответил на твоей странице обсуждения. - Матиаспол ( разговор )

Не могли бы вы объяснить аббревиатуру? [ редактировать ]

Fälschungserschwerende Schrift сокращенно FE-Schrift. Если «Е» не от ende , то откуда оно взялось? S Б Н Arris 20:49, 26 ноября 2011 (UTC)

Здравствуй! Я попробовал это в сводке редактирования, но это было сложно из-за ограничения по длине. Немецкий термин « FE-Schrift » является сокращением от «Fälschungserschwerende Schrift» (что на английском языке напрямую переводится как «шрифт, препятствующий фальсификации»). FE происходит от сложного слова « f älschungs e rschwerend». «-End» в «erschwerend» не имеет ничего общего с немецким словом «Ende» (английский: конец), он просто отмечает это слово как прилагательное, а поскольку «die Schrift» (шрифт) на немецком языке женского пола, «-e» добавляется после прилагательного, отсюда «erschwerende Schrift». Соответствующий глагол будет «erschweren» (препятствовать). Привет.- Матиаспол ( разговор ) 21:00, 26 ноября 2011 г. (UTC)

Это имеет смысл. Не могли бы вы добавить это в статью .en? Поскольку для англоязычных читателей совсем не очевидно, какая буква E используется для аббревиатуры / акронима «FE» и почему. Спасибо! S Б Н Arris 21:08, 26 ноября 2011 (UTC)

Очень красивое дополнение. Теперь это имеет смысл для английских пользователей. Еще раз спасибо. S Б Н Arris 21:43, 26 ноября 2011 (UTC)

Пожалуйста. - Матиаспол ( разговор ) 21:44, 26 ноября 2011 г. (UTC)

План пилотного анализа Пуны [ править ]

Здравствуй! Поскольку вы очень активно обсуждали пилотный проект Индийской образовательной программы в Пуне, я хотел бы обратить ваше внимание на Википедию: India_Education_Program / Analysis , страницу, на которой документируется наш план анализа на следующие несколько месяцев. Я призываю вас присоединиться к обсуждению, если у вас есть какие-либо мысли. - ЛиАнна Дэвис (WMF) ( разговор ) 23:09, 1 декабря 2011 г. (UTC)

Спасибо за указатель, ЛиАнна. Я посмотрю. - Матиаспол ( разговор ) 14:43, 7 декабря 2011 г. (UTC)

Привет, я только что отправил вам электронное письмо об участии в обзоре пилотного проекта Пуны. Toryread ( разговор ) 00:24, 5 декабря 2011 (UTC)

Хорошо, Тори, я получил твое письмо. Ждите моего ответа до конца недели. - Матиаспол ( разговор ) 14:43, 7 декабря 2011 г. (UTC)

"FAT64" [ править ]

Спасибо за напоминание. Но в тот момент, когда я увидел ваши изменения на странице exFAT [недавно читал о путанице в терминах], я позаботился об этом. Слово «FAT64» больше не существует на моем сайте. ;-)
Я также изменил URL-адрес, чтобы он указывал на http://www.mdgx.com/secrets.htm#XFAT [Я также обновил URI на странице вики ;-)], и теперь заголовок раздела читает exFAT .
Кстати ... exFAT * - это * для всех намерений и целей Microsoft FAT32 «следующего поколения» [поэтому на момент выпуска его также называли FAT64] для портативных накопителей / USB-накопителей / SSD / карт / картриджей. Они в основном исправили большинство недостатков FAT32 + ограничений и добавили некоторые функции NTFS / ext4 / HFS в перфорацию. Они могли бы расширить / улучшить NTFS, но вместо этого выбрали старую FAT32. ; - / Мне не было любопытно узнать почему (пока).
Спасибо, что держали нас в тонусе.
С наилучшими пожеланиями,
MDGx ^{☹ ☺} 22:26, ​​6 декабря 2011 г. (UTC)

Большое спасибо. - Матиаспол ( разговор ) 13:39, 7 декабря 2011 г. (UTC)

Поскольку вы упомянули, что «при выпуске он назывался FAT64», можете ли вы указать мне на документы Microsoft, на самом деле изначально называющие его FAT64? Спасибо. - Матиаспол ( разговор ) 14:43, 7 декабря 2011 г. (UTC)

Я больше нигде на сайте MS не нашел оригинальной формулировки. Должно быть, они его тоже сняли. ; - /
Я нашел доказательства того, что MS считает exFAT преемником FAT32: здесь .
НТН [надеюсь , что это помогает]
MDGx ^{☹ ☺} 21:25, 9 декабря 2011 (UTC)

У Microsoft может больше не быть ссылок на FAT64, но у этих ребят есть. Я понятия не имею, как / если их FAT64 относится к exFAT MS. У них есть слайд-презентация PowerPoint с подробностями.
HTH
MDGx ^{☹ ☺} 21:44, 9 декабря 2011 г. (UTC)

Я также нашел эту книгу , которая относится к FAT64 в качестве псевдонима для EXFAT: поиск через книгу [Дно поле поиска веб - страницы], я нашел 2 ссылки на FAT64, на страницах 3 + 76.
НТН
MDGx ^{☹ ☺} 22:10, 9 Декабрь 2011 (UTC)

Где нет такого ограничения и реализации FAT32 в других операционных системах? [ редактировать ]

Не верьте, если ссылка отсутствует - 211.127.229.23 ( обсуждение ) 06:29, 7 декабря 2011 г. (UTC)

Привет, ИП! Что ж, может быть сложно дать ссылку на то (предел), которого не существует. ;-) Я могу только догадываться, почему Microsoft документирует ограничение на количество записей подкаталогов для своей реализации FAT32, но они также документируют ограничение на размер 32 ГБ для своей реализации FAT32. Конструкция файловой системы FAT32 не имеет таких ограничений, и ограничение в 32 ГБ, и ограничение в 65534 являются искусственными.

Практический предел размера для томов FAT32 составляет 2 ТБ, потому что это когда 32-битная запись для количества секторов заканчивается в таблице разделов в MBR и исходном загрузочном секторе FAT32 (где размер раздела указан в секторах). ), а также потому, что большинство драйверов файловой системы и дисков реализуют только 32-битную арифметику. Для незагрузочных томов FAT32, которые не обязательно указаны в таблице разделов или должны иметь стандартный FAT32 BPB, для секторов размером более 512 байт фактические конструктивные ограничения FAT32 еще выше. Том FAT32 может иметь около 2 ^ 28 кластеров, поэтому, предполагая, что максимальный размер кластера составляет 32 КБ, предел FAT32 будет равен 8 ТБ, а для кластеров 64 КБ это будет 16 ТБ. (Некоторые операционные системы даже реализуют проприетарные расширения для этого оригинального дизайна FAT32, например,они используют размер логических секторов до 16 КБ, размер кластера до 256 КБ или ширину FAT 32-битной вместо 28-битной, но я не буду здесь вдаваться в подробности таких сторонних расширений.) Как вы можете видеть , ограничение на размер раздела в 32 ГБ в операционных системах MS является полностью искусственным и не является результатом каких-либо технических ограничений.

Точно так же Microsoft задокументировала 65534 количества записей на подкаталог, ограничение также является искусственным. Подкаталог мало чем отличается от файла с установленным атрибутом каталога. Обычно максимальный размер файла на томе FAT32 составляет 4 ГБ - 1 (это налагается записью 32-разрядного размера файла в таблице каталогов), поэтому (отложив на мгновение LFN VFAT), это теоретически позволит для 134217728 записей каталога (каждая длиной 32 байта). LFN VFAT занимают дополнительные записи, и чем длиннее имя VFAT, тем больше. Для каждой записи файла можно использовать до 20 записей VFAT (каждая длиной 32 байта). Поскольку LFN VFAT являются необязательными, мы получаем от 1 до 21 записи каталога (то есть от 32 до 672 байтов), используемых для каждого файла или подкаталога на томе FAT. Таким образом, даже в худшем случае у нас все равно будет до 6391320 записей каталога.

В любом случае, конструкция FAT32 не имеет этого ограничения как такового. На самом деле, для подкаталогов размер записи установлен на 0 для «N / A», то есть у них нет чего-то вроде размера, измеряемого в байтах. Они ограничены только длиной их цепочки кластеров в FAT, поэтому, пока есть свободные кластеры для расширения цепочки, подкаталоги могут расти «бесконечно». Как обсуждалось выше, том FAT32 (в соответствии с исходным дизайном, а не упомянутыми сторонними расширениями) может иметь до 2 ^ 28 - 12 (268435444) кластеров. Конечно, если предположить, что каждая запись каталога соответствует файлу, файлы, определенные этими записями каталога, имеют свои собственные цепочки кластеров в FAT. Предполагая, что все они очень маленькие или имеют размер не менее одного байта, каждый из них также занимает один кластер в FAT,уменьшение количества доступных кластеров для цепочки подкаталогов соответственно.

Тем не менее, даже в худшем случае мы все равно получим в несколько тысяч раз больше записей, чем те 65534 записи, задокументированные Microsoft. Поскольку достаточно хорошая реализация не вводит искусственных ограничений, отсутствующих в структуре файловой системы, нет причин, по которым такие ограничения должны существовать в сторонних реализациях FAT32. - Матиаспол ( разговор ) 13:39, 7 декабря 2011 г. (UTC)

Secure Digital [ править ]

Здравствуй! Спасибо за правки и технические знания FAT32 и exFAT, на что я полагаюсь. Я обработал большой абзац, который вы редактировали, по причинам, указанным в истории изменений; примечательно, что отчасти это кажется редакционной статьей против решения SDA использовать exFAT. Это противоречие не является неподходящей темой для статьи, но вы должны указать на цитаты этого мнения, а не просто заявить его как свое собственное.

У меня есть другие канцелярские проблемы с правками. В первом предложении «Совместимость с SDHC» вы начинаете словами «Если контроллер карты был усовершенствован для поддержки этого…» Я бы по крайней мере повернул это, чтобы сначала определить «это». Но я понял, что спецификация SDXC требует, чтобы хост-устройства поддерживали старые карты. Если это неверно - если это допускает «двойную совместимость» хост-устройств, то вы измените предложение: «Хост-устройства либо делают, либо нет», и было бы лучше ничего не говорить.

И в последнем предложении «на уровне протокола» меня смущает. В предложении уже говорилось, что проблема заключается в выборе файловой системы, а поддержка на уровне протокола не имеет значения, если гаджет не будет работать. Spike-from-NH ( разговор ) 12:30, 14 декабря 2011 г. (UTC)

Просто примечание для вас обоих, которое мы все знаем, не упоминайте что-то, что НЕ общедоступно, например SD Card Spec 4.0. Вам нужно будет ограничить заявления до того, что можно найти в открытом доступе о 4.0, например, веб-страницы SD Card Spec, пресс-релизы и сторонние статьи. Я не являюсь участником спецификации SD-карты, поэтому я не могу загрузить 4.0, как и большая часть мира. Я бы хотел, чтобы у меня был доступ ко всем документам SDA, но, к сожалению, у меня нет. • Sbmeirow • Обсуждение • 17:44, 15 декабря 2011 г. (UTC)

Хотя SDA решила потребовать от производителей карт SDXC поставлять с exFAT, на самом деле это незначительное ограничение, поскольку карту можно переформатировать для других более популярных файловых систем. Это следует сделать очевидным и пояснить в статье. • Sbmeirow • Обсуждение • 17:44, 15 декабря 2011 г. (UTC)

SDSC [ править ]

Благодарим вас за отмену отмены SDSC; Сбмейров отметил, что SDSC используется в спецификациях на странице обсуждения статьи . Отдельно я верну ваше изменение, которое сделало условным утверждение в начале «Совместимость с SDHC». В дополнение к моей расплывчатой ​​цитате на странице обсуждения Sbmeirow, в Simplified Physical Layer v3.01 говорится: «Хосты, которые могут получить доступ ... SD-карты памяти емкостью более 32 ГБ и до 2 ТБ [то есть SDXC], также должны иметь доступ к картам памяти SD емкостью 32 ГБ или меньше ». Раздел 3.3.2, примечание 3. Вы утверждали, что решение использовать exFAT будет проблематичным; но это, казалось бы, единственная проблема на пути обратной совместимости хост-устройств. Spike-from-NH ( разговор ) 17:56, 16 декабря 2011 г. (UTC)

Хм, термин SDSC, кажется, отошел на второй план. Попробуйте поискать его в Google, пока почти никто не использует этот термин. Тем не менее, хорошо, что SDA придумала это название, потому что одно и то же наименование старого типа карт и семейства карт вызвало большую путаницу.

Что касается проблем совместимости, exFAT по определению является обязательным для всех карт SDXC. Хотя мы можем переформатировать в FAT32 при использовании карты SDXC для обмена данными между ПК, все цифровые камеры и кордеры с поддержкой SDXC, которые я видел до сих пор, не принимают карты SDXC, переформатированные в FAT32. Даже в руководствах пользователя производители четко заявляют, что SDXC требует использования exFAT и что это поддерживается только несколькими (обычно перечисленными) операционными системами. - Матиаспол ( разговор ) 15:52, 17 декабря 2011 г. (UTC)

Дальнейшие правки [ править ]

Я понимаю, почему вы изменили «доминирующий» на «широко распространенный» [sic] в конце первого абзаца статьи. Но смягченный результат почти ничего не говорит. Поскольку единственная функция этого пункта заключалась в том, чтобы предоставить официальную интерпретацию предшествующей статистике, я просто удалил его полностью - вставив комментарий, что, если кто-то хочет указать на авторитетную интерпретацию доминирования SD, он должен снова вставить его, но с цитатами.

Мне не нравится подтекст, который вы повторно вставили, что, по сути, у SDA не было веских причин переходить на exFAT и следовало придерживаться FAT32. Я склонен согласиться с выводом, но язык кажется осуждающим. Если верно утверждение, что FAT32 размером более 32 ГБ будет законным, но не будет поддерживаться Windows, это серьезная причина не соглашаться с ним.

Ваша пометка с помощью {fact} противоречит тому, что я думал, что знал, но могу ошибаться. Еще предстоит исправить грамматические и организационные аспекты ваших правок. Spike-from-NH ( разговор ) 17:33, 18 декабря 2011 г. (UTC)

Тип раздела [ править ]

Ваш новый материал о типе перегородок требует доработки. SDHC «Емкость меньше 8 ГБ» и «Емкость больше 8 ГБ» оставляет неоднозначную картину того, что вы делаете, когда емкость составляет ровно 8 ГБ. Точно так же над ним «от 16 МБ до 32 МБ» могут потребоваться дополнительные слова, чтобы гарантировать включение конечных точек.

Отдельно вопрос о том, какой тип раздела объявлять для достижения наилучших результатов в данной ОС, не кажется специфичным для SD, и, возможно, его следует указать в другой статье. Spike-from-NH ( разговор ) 12:47, 31 мая 2013 г. (UTC)

Якоря в таблице размещения файлов [ править ]

Здравствуй,

Я не понимаю, почему вы повторно вставили многочисленные комментарии формата <!-- NB. The header "FAT16B" is used in redirects to this page. -->: они излишни, потому что это все равно подразумевается {{ anchor }}, или просто заголовком для # FAT32 (хотя я пошутил, добавив туда привязку). Кроме того, вариант для exFAT просто неверен: не должно быть перенаправлений на таблицу размещения файлов # exFAT , поскольку вместо этого они должны указывать прямо на отдельную статью.

Между прочим, приношу свои извинения за замену видимых космических объектов: я недостаточно внимательно смотрел на вывод. Крис Каннингем (пользователь: thumperward) ( разговор ) 11:27, 17 декабря 2011 г. (UTC)

Привет, Крис. Люди часто меняют заголовки разделов, не подозревая, что они могут использоваться в качестве якорей для перенаправления. Поэтому в Википедии принято указывать использование раздела в качестве привязки в комментарии сразу после заголовка раздела. Я согласен, комментарии могут быть удалены там, где мы можем использовать шаблон привязки, поскольку его использование подразумевает, что на них есть перенаправления. Я добавил их просто для единообразия. Вы правы насчет метки exFAT, которая вряд ли будет использоваться в качестве цели перенаправления, учитывая, что существует отдельная статья exFAT. Я предполагал, что он может стать локальным якорем для быстрой навигации внутри самой статьи, подобно тому, как это делается при скорости пленки.article, где ссылки типа «ISO», «ASA» или «DIN» будут переходить не на внешние статьи, а только на локальный раздел, а внутри соответствующего раздела они будут переходить к соответствующей внешней статье. Тем не менее, упрощает навигацию, требует определенной степени согласованности в статье. Мы достигли этого в скорости пленки в течение нескольких месяцев, но структура статьи о таблице размещения файлов сейчас не совсем ясна, поэтому я думаю, что в настоящее время в комментарии нет необходимости, и я удалил его. - Матиаспол ( разговор ) 12:47, 17 декабря 2011 г. (UTC)

ИМО, если комментарии дублируют {{ якорь }}, то их следует удалить: мы обычно не комментируем использование шаблонов в статьях. Что касается использования внутренних ссылок, IMO это пасхальные яйца : читатели ожидают, что синяя ссылка будет переходить на страницу с таким заголовком, а не прыгать по странице. Крис Каннингем (пользователь: thumperward) ( обсуждение ) 15:18, 18 декабря 2011 г. (UTC)

Крис, комментарии уже были удалены вчера, когда мы использовали шаблон {{ anchor }}, так что это уже не проблема.

По поводу внутренних ссылок, боюсь, не согласен. Пожалуйста, посмотрите на светочувствительность пленки, который был оформлен таким образом, и попробуйте сами. Если вы находитесь на странице о светочувствительности пленки и там есть ссылка на термины «ISO», «ASA» или «DIN» и т. Д., Первое, что вы хотите узнать о них, - это «скорость пленки ISO», «скорость пленки ASA» или «Скорость пленки DIN», а это там, где ссылки локально. До изменения действительно раздражало («пасхальное» или так сказать), что переходы по этим ссылкам ничего не раскрывали о скорости пленки, но приводили вас к несвязанным статьям в органах стандартизации, в основном не относящимся к контексту кино. скорости. Однако, как только вы попадаете в раздел, например, о «DIN», больше не имеет смысла ссылаться на заголовок этого самого раздела, поэтому вместо этого вы:Приведем к статье об организации DIN. Это совершенно интуитивно понятно. Те, кто действительно искал объяснение аббревиатуры DIN, в первую очередь, либо найдут эту основную информацию в разделе DIN, либо им придется щелкнуть другую ссылку, чтобы фактически перейти к внешней статье.

Как бы то ни было, это зависит от объема, структуры и длины статьи, хорошо ли это работает или может причинить вред. Я предполагаю, что статья FAT будет еще одной статьей такого рода, чтобы вы могли переключаться между разделами FAT12, FAT16, FAT32, VFAT, BPB, EBPB, XBPB и т. Д. За секунду без какой-либо раздражающей прокрутки и поиска. Но в настоящее время статья не имеет последовательной структуры и номенклатуры для достижения этого, и прошли месяцы на добавление фактического содержания в статью, работу над номенклатурой и улучшение фраз, прежде чем что-либо подобное можно или нужно попробовать, ИМО. Я не говорил, что собираюсь представить эту схему сейчас (или когда-либо), я просто упомянул, что это то, что я должен был иметь в виду, когда изначально добавлял HTML-комментарий к разделу exFAT. Тем не менее, в настоящее время это не проблема,так как комментарий давно исчез со вчерашнего дня, во всяком случае. -Матиаспол ( разговор ) 15:59, 18 декабря 2011 г. (UTC)

Боюсь, я должен не согласиться. Оглавление предназначено для навигации по статье. Я испытываю сильное отвращение к использованию внутристатейных ссылок, особенно, конечно, в отношении светочувствительности пленки . Это, по-видимому, относительно недавнее дополнение к указанной статье и, конечно же, не широко используется и не предлагается в MoS. Проблемы с навигацией в статье FAT в основном связаны с ее большой длиной: вероятно, пора серьезно подумать о том, чтобы разделить ее и превратить в WP: РЕЗЮМЕ отдельных подстатей. Крис Каннингем (пользователь: thumperward) ( разговор ) 20:32, 18 декабря 2011 г. (UTC)

Пэт Виллани [ править ]

Здравствуй! Я только что вошел в систему после долгого перерыва в Вики и увидел ваше сообщение о моей странице пользователя для Пэта Виллани.

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

Я также хотел сообщить вам, что на самом деле я дочь Пэта Виллани, и в текущей статье есть несколько небольших ошибок и непроверенных фактов, которые я могу исправить или подтвердить как истину, однако использование себя в качестве источника, безусловно, приведет к Нарушение Википедии: Нет оригинальных исследований . Вы более опытный википедист, чем я - есть идеи, как нам с этим справиться? - Aeonian ( разговорное ) 17:37, 5 января 2012 (UTC)

Привет, Эрика, приятно слышать от тебя, и я надеюсь, что с тобой все в порядке. На самом деле, я оставил заметку еще до того, как сам начал расширять статью в (в конечном итоге успешной) попытке предотвратить ее удаление. Хотя я знал вашего отца по проекту FreeDOS и не сомневался в его достижениях в отношении проекта, оказалось довольно сложно определить известность (в терминах WP) из доступных онлайн-источников, но, к счастью, предлагаемое удаление в конечном итоге может быть отклонен. Я тем временем собрал еще немного материала, но не решился добавить его в статью. Если вы можете помочь с лучшими ссылками, в том числе оффлайн-источниками, до тех пор, пока они являются цитируемыми, или можете иным образом уточнить статью за пределами материала FreeDOS, или если вы можете исправить детали, я думаю, это будет очень кстати.Если вы считаете, что вам удастся сохранить нейтральную точку зрения, я бы посоветовал вам просто пойти дальше, и если у вас есть вопросы, я с радостью помогу. Ваше здоровье --Матиаспол ( разговор ) 15:29, 8 января 2012 (UTC)

BAP (немецкий оркестр) [ править ]

Здравствуй. После изменения вы сделали вступительную формулировку (немецкой группы) BAP статьи здесь , вы не думаете , что люди , читающие эту статью , теперь предположим , что название группы является аббревиатурой произносится «БАТ» таким же образом , как такие группы, как AKB48 , AC / DC , KRS-One , UB40 и UFO (диапазон) ? Предлагаю вам ознакомиться со статьями о Kiss (группа) , Chemistry (группа) , Exile (японская группа) и Glay., так как это все хорошие примеры статей для групп, которые обычно пишут свои имена стилистически заглавными буквами, но которые правильно следуют руководству Wikipedia по стилю, изложенному на WP: MOSTM . Я надеюсь, что вы тоже сможете поработать над приведением этой статьи в соответствие со стандартами Википедии. Спасибо. - DAJF ( разговор ) 11:31, 28 февраля 2012 г. (UTC)

Здравствуй. Из упомянутых статей, как мне кажется, наиболее похожая на szenario с BAP - это статья на Glay, потому что Kiss, Chemistry и Exile - все это «нормальные» слова в английском языке, поэтому применять правила английской грамматики вполне естественно. Как и Glay, BAP не является «нормальным» словом. Однако есть и различия: игра слов Glay основана на английском языке, тогда как игра слов BAP основана на иностранном языке, Kölsch, сильном диалекте немецкого языка. язык. Кроме того, насколько мне известно, в японском языке нет понятия прописных и строчных букв. В немецком языке, конечно, есть, и правила более строгие и строгие, чем в английском языке. Итак, то, что может быть почти безразличным или модным для японской группы,это аспект идентичности немецкой группы. Кроме того, в статье Glay говорится «(стилизовано как GLAY)», тогда как в статье BAP указано «(часто стилизовано как BAP)», что просто неверно (если мы не опускаем «часто» и не заменяем «стилизовано как» на «написано» в качестве"). Вы не найдете никаких публикаций (кроме английской Википедии и ее производных), где название группы было бы написано как Bap, поэтому я не считаю вопрос стиля написать его BAP, это само собой разумеющееся. Я не знаком с Glay, поэтому не знаю, используют ли они обе формы Glay и GLAY, а просто предпочитают форму GLAY. Если форма GLAY постоянно используется в публикациях, я считаю неправильным представлять их как Glay в Википедии.Цель Руководства по стилям - не изобретать новые формы, которых нет в других местах, а помочь принять правильное решение, если на выбор доступно несколько стилей. MOS бесполезен, если есть только один доступный вариант и нет альтернативы, как в случае BAP. Изобретение новой формы «Bap» - это то, что я считаю исходной интерпретацией или оригинальным исследованием; это в корне неверно по правилам Википедии. Решение, похоже, состоит в том, чтобы уточнить Руководство по стилю, чтобы разрешить такие исключения, как GLAY и BAP, чтобы мы могли избежать таких обсуждений в будущем.форма - это то, что я считаю исходной интерпретацией или оригинальным исследованием; это в корне неверно по правилам Википедии. Решение, похоже, состоит в том, чтобы уточнить Руководство по стилю, чтобы разрешить такие исключения, как GLAY и BAP, чтобы мы могли избежать таких обсуждений в будущем.форма - это то, что я считаю исходной интерпретацией или оригинальным исследованием; это в корне неверно по правилам Википедии. Решение, похоже, состоит в том, чтобы уточнить Руководство по стилю, чтобы разрешить такие исключения, как GLAY и BAP, чтобы мы могли избежать таких обсуждений в будущем.

Хорошим контрпримером Glay может быть INXS . Никто не стал бы писать их как «Inxs» только из-за соответствия MOS Википедии. Отличие от BAP в том, что INXS широко известен в англоязычном мире, поэтому люди легко распознают проблему с Inxs, тогда как те же люди, похоже, не видят аналогичной проблемы с Bap.

(Действительно ли НЛО произносится как НЛО?) - Матиаспол ( разговор ) 13:31, 28 февраля 2012 г. (UTC)

Для вашего интереса «bap» - это обычное слово в английском языке, точно так же, как «поцелуй» и «химия». Группа «UFO» произносится как «UFO» (а не «yoofow»). - DAJF ( разговор ) 13:42, 28 февраля 2012 г. (UTC)

Спасибо, я этого не знал. ;-) - Матиаспол ( разговор ) 13:58, 28 февраля 2012 (UTC)

Спасибо [ редактировать ]

Очень признателен . 86.144.228.49 ( обсуждение ) - Предыдущий недатированный комментарий добавлен в 13:07, 4 марта 2012 г. (UTC).

Категоризация [ править ]

Я подумал, что категоризация перенаправлений, например, Википедия: IPA для Кёльша не разрешена Wikipedia MoS; однако я могу ошибаться. - Карнби ( разговор ) 20:49, 1 апреля 2012 г. (UTC)

Привет, Карнби. Не все перенаправления должны иметь категории, но правильная категоризация перенаправлений явно желательна, либо косвенно, с использованием большого набора шаблонов {{R ...}}, предопределенных для этой цели, либо путем прямого указания категорий. Есть много применений. Его можно использовать, например, для перечисления статей в категориях под разными ключевыми словами, и он позволяет находить подтемы статьи в разных (и, возможно, независимых) наборах категорий, что не относится к фактической статье, но только тщательно подобранный набор редиректов, указывающих на статью. - Матиаспол ( разговор ) 22:22, 1 апреля 2012 г. (UTC)

Спасибо за ваше объяснение. В будущем я буду более осторожен. - Карнби ( разговор ) 16:20, 6 апреля 2012 г. (UTC).

Значение байта 69h по смещению 0 в загрузочных секторах дискет FAT12 или FAT16 [ править ]

Мой первоначальный вопрос, поднятый на странице обсуждения Asmpgmr, был: «Просьба помочь решить небольшую загадку: значение байта 69h со смещением 0 в загрузочных секторах дискет FAT12 или FAT16?

Возможно, вы похожи на меня и любите разгадывать чудеса, когда на них натыкаетесь. Из исторического интереса иногда полезно узнать, почему разработчики выбрали определенные «магические» значения в своем программном обеспечении. Есть один вопрос, на который я не мог ответить сам, и мне пришло в голову, что вы, возможно, знаете ответ (или знаете тех, кого спрашивают, кто знает ответ), поэтому я попробую:

Когда DOS входит в дисковый том, он проверяет наличие определенных байтовых шаблонов со смещениями +0 .. + 2 в загрузочном секторе, прежде чем предположить, что присутствует BPB (есть дополнительные проверки работоспособности, но я оставлю их здесь для ясности - вы, конечно, знаете о них столько же, сколько и я): Поскольку допустимые загрузочные диски x86 для DOS 2.0 должны начинаться либо с короткого перехода, за которым следует NOP (opstring EBh ?? h 90h с DOS 1.1 и снова с DOS 3.0) или близкий прыжок (E9h ?? h ?? h на дисках DOS 2.x). На жестких дисках DR-DOS также принимает замененную последовательность JMPS, начиная с NOP (90h EBh ?? h), тогда как MS-DOS / PC DOS этого не делает. На съемных дисках MS-DOS / PC DOS и DR-DOS также принимают последовательность 69h ?? h ?? h. Это также задокументировано по крайней мере в одной книге («Внутренности DOS» Джеффа Чаппелла), к сожалению, без упоминания того, для чего предназначен этот 69-часовой байт или последовательность.Итак, вот мой вопрос:

Что это такое? Это тоже последовательность опкодов (возможно, даже переход?), Но тогда для какого типа ЦП? Поскольку это не похоже на действительный код операции x86 (то есть в последовательности запуска загрузочного сектора и, возможно, даже код запуска, который не должен запускаться в BPB через несколько байтов позже), я также проверил другие параметры и направления: Мог ли это быть какой-то недокументированный код операции в ранних процессорах x86 или в прототипах процессоров, это код операции, поддерживаемый сериями NEC V20 / V30 и т. д. (возможно, в режиме эмуляции)? Это артефакт, модифицированный для 86-DOS? Одно время Microsoft имела MSX-DOS, которая работала на процессорах 8080 / Z80, и были двухпроцессорные варианты (для 8080/8086) Concurrent DOS 8-16 от Digital Research, которые также поддерживали файловые системы DOS. Фактически, существовала даже Concurrent DOS 68K для процессоров Motorola 68000.Серия Atari ST также поддерживает FAT12 / FAT16. У IBM была компьютерная машина под названием RT, использующая процессор ROMP. И ранние версии Windows NT от Microsoft поддерживали и другие платформы ... Возможно, я что-то упустил, но до сих пор я не мог найти код операции ни в одном из известных мне классов ЦП для поддержки файловых систем FAT примерно в сроки DOS, что могло бы принести много пользы. смысл в этом конкретном месте. Итак, это вообще код операции или подпись для чего-то еще? Или бит 7 был удален (E9h -> 69h) по какой-то странной причине? Возможно, вы знаете ответ или, по крайней мере, сможете отследить его во времени и в Microsoft или IBM, чтобы сузить возможные интерпретации этой странной магии 69h? Спасибо. ;-) -И ранние версии Windows NT от Microsoft поддерживали и другие платформы ... Возможно, я что-то упустил, но до сих пор я не мог найти код операции ни в одном из известных мне классов ЦП для поддержки файловых систем FAT примерно в сроки DOS, что могло бы принести много пользы. смысл в этом конкретном месте. Итак, это вообще код операции или подпись для чего-то еще? Или бит 7 был удален (E9h -> 69h) по какой-то странной причине? Возможно, вы знаете ответ или, по крайней мере, сможете отследить его во времени и в Microsoft или IBM, чтобы сузить возможные интерпретации этой странной магии 69h? Спасибо. ;-) -И ранние версии Windows NT от Microsoft поддерживали и другие платформы ... Возможно, я что-то упустил, но до сих пор я не мог найти код операции ни в одном из известных мне классов ЦП для поддержки файловых систем FAT примерно в сроки DOS, что могло бы принести много пользы. смысл в этом конкретном месте. Итак, это вообще код операции или подпись для чего-то еще? Или бит 7 был удален (E9h -> 69h) по какой-то странной причине? Возможно, вы знаете ответ или, по крайней мере, сможете отследить его во времени и в Microsoft или IBM, чтобы сузить возможные интерпретации этой странной магии 69h? Спасибо. ;-) -но до сих пор я не мог найти код операции ни в одном из известных мне классов ЦП для поддержки файловых систем FAT примерно в период времени DOS, что имело бы смысл в этом конкретном месте. Итак, это вообще код операции или подпись для чего-то еще? Или бит 7 был удален (E9h -> 69h) по какой-то странной причине? Возможно, вы знаете ответ или, по крайней мере, сможете отследить его во времени и в Microsoft или IBM, чтобы сузить возможные интерпретации этой странной магии 69h? Спасибо. ;-) -но до сих пор я не мог найти код операции ни в одном из известных мне классов ЦП для поддержки файловых систем FAT примерно в период времени DOS, что имело бы смысл в этом конкретном месте. Итак, это вообще код операции или подпись для чего-то еще? Или бит 7 был удален (E9h -> 69h) по какой-то странной причине? Возможно, вы знаете ответ или, по крайней мере, сможете отследить его во времени и в Microsoft или IBM, чтобы сузить возможные интерпретации этой странной магии 69h? Спасибо. ;-) -Матиаспол ( разговор ) 12:35, 9 июля 2012 (UTC) "

Я давно не думал об этом. Напомню, что это был остаток кода из DOS 1.x. Код проверяет наличие 69h, E9h и EBh. Думаю, 69h - это то же самое, что E9h на 8086/8088. Помните, что весь диапазон кодов операций 6xh не используется на 8086/8088, большинство кодов операций в этом диапазоне были добавлены с 80186/80188, еще пара на 80286 и префиксы (64h - 67h) на 80386. Если вы иметь доступ к системе 8086 или 8088, тогда было бы интересно проверить, работают ли коды операций 6xh так же, как коды операций Exh. Asmpgmr ( обсуждение ) 15:28, 9 июля 2012 (UTC)

Спасибо за Ваш ответ. Таким образом, мы оба предполагаем в основном одни и те же недокументированные или неполно декодированные коды операций 8088/8086.

Вы написали «остатки DOS 1.x». Но DOS 1.x не использовал BPB, а загрузочные секторы DOS 1.0 и 1.1, которые я видел до сих пор, не начинались с 69h. Итак, как это должно быть остатком от или для DOS 1.x? И зачем кому-то использовать недокументированные коды операций, если документированные могут делать то же самое? Какая-то странная схема защиты, которая работает только на определенных машинах? Но почему?

К сожалению, все еще доступные «нормальные» ПК были модернизированы процессорами NEC V20 (включая, как мне кажется, очень ранний ПК IBM с проводной материнской платой). IIRC Sirius 1 все еще имеет 8088, но его загрузочные дискеты стали слабыми ... А у 200LX уже есть 186-ядерный. Похоже, время для небольшой работы по обмену. - Матиаспол ( разговор ) 23:47, 23 июля 2012 г. (UTC)

Я помню, что в этом разделе кода E9h упоминалось как «прыжок DOS 2» или что-то в этом роде (это было некоторое время, я работал над DOS в середине 90-х), поэтому подразумевается, что 69h использовался в DOS 1. x или каким-либо программным обеспечением ранней эпохи DOS 1.x. Вполне возможно, что позже в DOS был добавлен код для проверки наличия определенных загрузочных дисков. Код был странным, поскольку 69h - это IMUL на 80186+, что, конечно, не имеет смысла в качестве первого кода операции загрузочного сектора, поэтому, по-видимому, он должен выполнить какой-то недокументированный переход на 8086/8088 или, возможно, на более ранний процессор NEC. Asmpgmr ( разговор ) 18:07, 26 июля 2012 (UTC)

Исходная информация / обсуждения:

• https://en.wikipedia.org/w/index.php?title=File_Allocation_Table&action=historysubmit&type=revision&diff=469451628&oldid=469431099 (04.01.2012)
• https://en.wikipedia.org/w/index.php?title=User_talk:Asmpgmr&oldid=515075153#Request_to_help_solve_a_little_mystery:_Byte_value_69h_at_offset_0_in_boot_12_f_loppies ? (2012-07-09)
• https://en.wikipedia.org/wiki/Talk%3AFile_Allocation_Table%2FArchive_6#Boot_sector_jump_code_0x69 (30 августа 2013 г.)

Последующее обсуждение - приятно видеть, что другие продолжают пытаться разгадать это чудо - однако несколько разочаровывает то, что источник обсуждения и различные оригинальные мысли там не упоминаются:

• http://www.os2museum.com/wp/undocumented-8086-opcodes/ (2013-12-21)
• http://www.os2museum.com/wp/theres-another-possibility/ (02.01.2018)

- Матиаспол ( разговор ) 21:38, 20 сентября 2018 г. (UTC)

Шаблон: Нравится [ редактировать ]

Здравствуй. Насколько я понимаю, изображения на Викискладе можно бесплатно использовать и повторно использовать на вики-сайтах Викимедиа. Я не понимаю вашего изменения в Template: Like, и я соответственно отменил его. Об этом уже говорилось ранее. Я думаю, что разумно сказать, что если изображение будет продолжать храниться в Wikimedia Commons в результате ряда обсуждений удаления, его можно использовать в вики-сайтах Wikimedia, таких как английская Википедия. Пожалуйста, дайте мне знать, если это необоснованно. - MZMcBride ( разговор ) 06:00, 24 июля 2012 г. (UTC)

Мэтью Энтони Смит [ править ]

См. Обсуждение в Википедии: WikiProject Computing # Пользователь: Мэтью Энтони Смит . - Рууд, 21:11, 22 августа 2012 г. (UTC)

Спасибо за внимание, Рууд. Надеюсь, он научится придерживаться правил ... - Матиаспол ( разговор ) 15:54, 17 сентября 2012 г. (UTC)

О Sony Cyber-shot DSC-RX1 [ править ]

В статье вы сказали: «Существуют высококлассные 35-миллиметровые пленочные камеры, которые * намного * меньше, например TC-1».

Однако вы упустили из виду то, что в статье говорится: «Самая маленькая в мире полнокадровая ЦИФРОВАЯ камера», а не «самая маленькая в мире полнокадровая ФИЛЬМ-камера». Поэтому я удалил только этот ошибочный раздел вашего редактирования. Надеюсь, вы согласитесь с этим. M Torleeb TALK 00:50, 22 сентября 2012 (UTC) - предшествующий неподписанный комментарий добавлен MoTorleeb ( обсуждение • вклад )

На самом деле, это я добавил «цифровой» к рассматриваемому предложению, чтобы решить проблему. ;-) До того, как я отредактировал, было написано просто «это самая маленькая полнокадровая камера в мире», но это не так. Раздел, который вы удалили, не был «живым» содержанием статьи, а просто моим скрытым комментарием HTML, объясняющим мои изменения, чтобы другие редакторы могли его прочитать. Ничего страшного в этом не было, но в любом случае, я могу его удалить. - Матиаспол ( разговор ) 07:18, 22 сентября 2012 г. (UTC)

Ой! Мне очень жаль то, что я написал ранее. Надеюсь, вы не обиделись. Спасибо, что прояснили ситуацию. M Torleeb РАЗГОВОР 02:58, 23 сентября 2012 г. (UTC) - MoTorleeb добавил предшествующий неподписанный комментарий ( обсуждение • вклад )

Не волнуйтесь, я совсем не обиделась. ;-) - Матиаспол ( разговор ) 17:43, 27 сентября 2012 (UTC)

Спасибо Вам большое. M Torleeb РАЗГОВОР 01:40, 29 сентября 2012 (UTC) - MoTorleeb добавил предшествующий неподписанный комментарий ( обсуждение • вклад )

Джим Оллчин [ править ]

Здравствуйте, я восстановил так называемую "тираду", которую вы ранее восстановили. Я надеюсь, что с тобой все еще хорошо. 216.86.177.36 ( разговорное ) 22:59, 29 сентября 2012 (UTC)

Редактирование списка литературы, который является «неполным или продвигает неправильный немецкий» [ править ]

Исходные данные ссылки для Canon Pellix статьи, используется и необходимость написания этой статьи в соответствии с требованиями для любого вклада Википедии. Фактически использовавшаяся книга Minolta - это Minolta's Kamera Technik…, опубликованная в 1990 году. Любое искажение этой информации или ссылка на какое-либо другое издание не может рассматриваться в качестве первоисточника статьи. Насколько мне известно, я не предоставил неполную информацию, и я не продвигаю неправильный немецкий язык. Ответственность за название книги несут авторы, а не я. При изменении ссылок или их части список становится недействительным. Критерии, указанные для редактирования ссылок, не имеют отношения к делу и являются нарушением моих обязательств по предоставлению проверяемой информации.

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

С уважением, - Ян фон Эрпеком 19:18, 16 октября 2012 г. (UTC)

Привет, Ян, я полностью осознаю тот факт, что вы использовали второе издание книги для справки, и в этом нет ничего плохого.

По каким-то странным причинам имена авторов были сокращены на обложке этого издания, и они выбрали название «Minoltas Kamera Technik». Несмотря на то, что это неправильный немецкий язык, вы правильно представили заголовок в том виде, в котором он использовался авторами (за исключением дополнительного апострофа, которого не было в исходном заголовке).

Когда я добавил полные имена авторов, я сделал это с третьим изданием книги передо мной (которое гласит «Minolta Kameratechnik»), и поэтому я предположил, что не только случайный апостроф, но и пробел в " Kamera Technik "была бы результатом непреднамеренной ошибки трансформации. Вот почему я исправил и это, пока был там.

Когда вы отменили мое изменение, я просмотрел это в старом издании книги и увидел, что тогда там действительно читалось «Kamera Technik». Итак, если бы авторы не опубликовали третье издание, в котором они исправили бы свою ошибку (ну, вроде бы, чтобы быть на 100% правильным немецким, нужно было бы читать «Minolta-Kameratechnik»), у нас не было бы иного выбора, кроме как использовать неправильное название. Но поскольку есть более новая версия, мы можем использовать и ее, чтобы полностью избежать проблемы.

Когда я дал свое резюме редактирования как «Нет причин давать неполные ссылки или продвигать неправильный немецкий, поэтому заменено последним изданием книги», я имел в виду не «вы» лично, а «нас», сообщество редакторов Википедии (включая ты и я). Это было вовсе не как критика вашей предыдущей работы, а как конструктивный комментарий, например, «эй, мы можем избежать неправильного названия на немецком языке, так что давайте улучшим его». Если каким-то образом это было сочтено оскорблением, я приношу извинения за это.

Что касается двух других вопросов, которые вы подняли, вполне нормально заполнить неполную информацию об авторе, как это сделал я. Также можно заменить существующие ссылки на более качественные. У нас нет обязательств придерживаться первоисточников, если мы найдем лучшие. Все, что нужно, - это чтобы источник поддерживал то, что написано в статье. Единственная причина, по которой я удалил 2-е издание, заключается в том, что все, что там использовалось для статьи, также описано в 3-м издании, и нет смысла перечислять два издания одной и той же книги.

В заключение я также хотел бы указать, почему я заключил термин Nifcalette в рамку [sic]. Несколько лет назад (но после даты публикации 3-го издания) несколько «историков Минолты» выяснили, что камера на самом деле была названа Nifcarette, а не Nifcalette.

- Матиаспол ( разговор ) 22:05, 16 октября 2012 г. (UTC)

Бирьяни [ править ]

Здравствуйте, мистер Матиас, с одной стороны, я вижу, вы указываете на то, что список известных продавцов бирьяни не входит в энциклопедию. По тем же меркам, что-то вроде известного ювелира Tiffany _ & _ Co. или даже компьютеры Apple не принадлежат энциклопедии. ИМО, поскольку список ограничен установленными и известными местами, он действует как справочник знаний (в отличие от коммерческого накопления). Например, этот список будет полезен тем, кто исследует аутентичные стили бирьяни в разных регионах. Если вы хотите переоценить разворот, я хотел бы поблагодарить за ваше время. В любом случае, хорошего дня! Фигурные скобки ( обсуждение ) 18:09, 1 ноября 2012 (UTC)

Я не хочу вас разочаровывать, но Википедия не является ни сборником рецептов, ни кулинарией, ни путеводителем, и мы, конечно, не можем перечислить все рестораны, закусочные или фаст-фуд, предлагающие ту или иную форму бирьяни - их несколько. из них в большинстве городов на этой планете. - Матиаспол ( разговор ) 17:13, 12 ноября 2012 г. (UTC)

Таблица размещения файлов [ править ]

Спасибо, я не заметил, что это ссылка на ссылку, моя беда. - 151.75.122.123 ( разговорное ) 12:41, 9 ноября 2012 (UTC)

Не волнуйтесь, это может произойти очень легко, а также легко исправить. ;-) Приветствую, Матиаспол ( разговор ) 17:13, 12 ноября 2012 (UTC)

Я только что заметил вашу публикацию на машинах FAT и NCR. Я запомнил эту модель как 8200 или 8500. Я посмотрел на модели NCR и, похоже, это был 7520. Я реализовал его на 7200, у которого была добавлена ​​двойная 8-дюймовая коробка для гибких дисков, поэтому мы получили не настоящий 7520, а новая карта и оборудование. Обе машины имели 8080 процессоров. Структура FAT была только на машине в связке была Basic. StandAlone Disk Basic имел точно такой же формат файла. - Марк Макдональд (MarcMcd)

Ваши правки и отмены [ править ]

Здравствуй. Также ваши правки в основном в порядке,

1. Опять же: статья Bionz плохая, напишите лучше или оставьте. Википедия для ЧИТАТЕЛЕЙ!
2. Ссылка на перенаправление противоречит правилам Википедии

Прекратите возвращаться. Tagremover ( обсуждение ) 12:17, 12 ноября 2012 (UTC)

Привет и там. К сожалению, ваши утверждения выше неверны и не подтверждаются нашими рекомендациями, поэтому я прошу вас прекратить отменять мои изменения (которые поддерживаются нашими рекомендациями):

Назначение разделов «См. Также» (в соответствии с нашим Руководством по стилю WP: SEEALSO ) состоит в том, чтобы ссылаться на другие статьи (независимо от их состояния), которые могут быть интересны читателю первой статьи (но почему-то уже не упоминалось в теле статьи). Статьи Nikon Expeed , Canon DIGIC и Sony Bionz явно ортогонально связаны и подходят для одного и того же типа считывателя, и поэтому должны быть связаны друг с другом.

Хотя я согласен с тем, что статья Sony Bionz в настоящее время является всего лишь заглушкой, это немного не меняет сказанного выше - и подавление ссылки является суждением и, следовательно, нарушением нашей основной политики WP: NPV . Мы просто не фильтруем статьи, потому что они все еще находятся в очень развивающемся состоянии - это должно оставаться в домене читателя, чтобы решить, полезно / было для них чтение статьи или нет.

Что касается переадресации, наши руководящие принципы WP: NOTBROKEN и WP: NOPIPE очень ясно дают понять, что ссылки на переадресацию совершенно нормально (и часто даже более желательно, чем ссылка на целевую статью, если перенаправление ссылается только на связанную тему) и что нам следует избегать конвейерных ссылок, если вместо этого мы можем использовать перенаправления.

- Матиаспол ( разговор ) 13:21, 12 ноября 2012 г. (UTC)

Извините, но: Вы ошибаетесь:

1. «Ссылки в разделе« См. Также »должны быть релевантными, должны отражать ссылки, которые будут присутствовать во всеобъемлющей статье по данной теме, и должны быть ограничены разумным числом.»: BIONZ не имеет отношения к делу и не является исчерпывающим.
2. «Таким образом, во многих высококачественных, всеобъемлющих статьях нет раздела« См. Также »». : Уменьшить число!
3. Ссылка на перенаправление не имеет смысла, если это НИКОГДА не будет независимой статьей: Canon DIGIC всегда будет перенаправлением, как и DIGIC . Хотя это разрешено, в таком случае это не имеет смысла .
4. WP: NOPIPE : Хорошее название; посмотреть, куда он перенаправляется ...
5. «подавление ссылки является суждением и, следовательно, нарушением нашей основной политики WP: NPV»: Действительно ???? Ссылки на все?
6. «Мы просто не фильтруем статьи, потому что они все еще находятся в стадии разработки»: шутите? BAD редактор добавляет такие ссылки.

Результат: Следует ограничивать количество ссылок, НЕ добавлять полезную информацию, и ДОЛЖНО быть сделано в хороших статьях. Tagremover ( обсуждение ) 13:44, 12 ноября 2012 (UTC)

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

1. Тема BIONZ абсолютно актуальна в контексте EXPEED или DIGIC - это прямой аналог. Мы согласны с тем, что сама статья в настоящее время оставляет желать лучшего, но это не имеет отношения к вопросу, существует ли связь между темами (и, следовательно, должна быть размещена ссылка). Создание инфраструктуры не обязательно связано с улучшением самой статьи, хотя часто и то, и другое можно делать одновременно. Могут быть редакторы, которые могут вносить свой вклад в содержание статьи, но не видят связей, и другие редакторы, которые мало знают о конкретной теме, но знают, как она соотносится с другими темами. Мы должны сделать все, что можем, в первую очередь, нет смысла откладывать создание сети до тех пор, пока статья BIONZ не станет полноценной статьей.Мы не говорим о красных ссылках или статьях без возможностей, статья существует и имеет (довольно много) возможностей.

2. Уменьшение количества ссылок "См. Также" - это нормально, но не обязательно, и вряд ли необходимо, поскольку в настоящее время всего две ссылки. Даже если они намного больше статьи BIONZ, статьи EXPEED и DIGIC в настоящее время также далеки от исчерпывающих. Если в статье не упоминаются связанные темы, которые могут быть интересны читателю, их следует упомянуть в разделе «См. Также». Это и есть цель этого раздела согласно WP: SEEALSO :

См. Также раздел: Содержание: маркированный список [...] внутренних ссылок на соответствующие статьи Википедии. [...] Редакторы должны предоставить краткую аннотацию, когда релевантность ссылки не сразу очевидна, когда значение термина может не должны быть общеизвестными или если термин неоднозначен. [...] Принадлежит ли ссылка к разделу «См. также», в конечном итоге является вопросом редакционного суждения и здравого смысла. Ссылки в разделе «См. также» должны быть релевантные, должны отражать ссылки, которые будут присутствовать во всеобъемлющей статье по данной теме, и должны быть ограничены разумным числом. Как правило, в разделе «См. также» не должны повторяться ссылки, которые появляются в теле статьи или в ее навигации. коробки. [...] Ссылки в разделе «См. также»Раздел не обязательно должен быть напрямую связан с темой статьи, потому что одна из целей ссылок «См. также» - дать читателям возможность изучить темы, которые имеют второстепенное значение. Раздел «См. Также» не должен содержать ссылок на несуществующие страницы (красные ссылки) или на страницы значений (если они не используются для дальнейшего устранения неоднозначности на странице значений) ».

(Возможно, вы смешиваете это с красными ссылками в разделах «См. Также» или с внешними ссылками, для которых применяются другие правила?)

3. Мы, конечно, могли бы обсудить, следует ли нам лучше ссылаться на « Canon DIGIC », «Canon DIGIC » или просто « DIGIC », но не в том случае, если «нет смысла» ссылаться на перенаправления. В соответствии с рекомендациями, ссылки, которые могут быть не самоочевидными в разделе См. Также, должны быть объяснены, поэтому просто ссылка на DIGIC слишком коротка (пользователь Nikon может не знать, что это такое), мы должны, по крайней мере, добавить «Canon DIGIC ". Лично я бы предпочел Canon DIGIC, потому что таким образом мы могли бы избежать лишнего текста (см. выше, если возможно, предпочтительнее использовать простой маркированный список ссылок), и это также заголовок, к которому на самом деле будет принадлежать статья, поскольку мы обычно префикс компании name, чтобы избежать конфликтов имен в будущем, и вполне возможно, что мы будем вынуждены перенести эти статьи в эти новые заголовки рано или поздно (следовательно, у них есть «возможности»). Перенаправления также (согласно руководящим принципам) являются инструментом для «измерения» предпочтительного названия статьи, и это приведет к нарушению цели, если мы обойдем существующие перенаправления. Итак, либо Canon DIGIC, либо «Canon DIGIC"можно использовать, но не варианты с конвейером, такие как [[DIGIC | Canon DIGIC]] или [[Expeed | Nikon Expeed]], которые явно противоречат рекомендациям. По той же причине правильнее и предпочтительнее ссылаться на µITRON, а чем использование канала, как в [[проект ITRON | µITRON]].

4. WP: NOPIPE правильно перенаправляет на соответствующий раздел в этой статье, а там на следующий абзац:

«Как правило, не рекомендуется размещать ссылки по конвейеру просто для того, чтобы избежать перенаправления. Количество ссылок на страницу перенаправления может быть полезным показателем того, когда было бы полезно перенести подтему статьи на отдельную страницу».

См. Выше.

5. Вы написали: «« подавление ссылки является осуждением и, следовательно, нарушением нашей основной политики WP: NPV »: Действительно ???? Ссылки на все?»

Конечно, не на все (это не то, что я сказал), но мы делаем ссылки на связанные и актуальные темы, также для сохранения нейтральной точки зрения. BIONZ - связанная тема в контексте EXPEED и DIGIC, поэтому подавление ссылки там, где она должна быть, является формой отказа от нашей нейтральной точки зрения и добавления предвзятости и личных суждений в статью.

6. Вы написали: «Мы просто не фильтруем статьи, потому что они все еще находятся в стадии разработки»: Шутка? ПЛОХОЙ редактор добавляет такие ссылки ».

Фактически, мы иногда даже ссылаемся на несуществующие статьи (хотя и не в разделах «См. Также»). Если мы этого не сделаем, мы не сможем построить сеть. Если вы хотите узнать мое личное мнение, большинство статей в английской Википедии находится в очень плохом состоянии, нам просто нужно смириться с этим, помочь и надеяться, что со временем они будут улучшены. Ссылки помогают ознакомить читателей со статьями и тем самым улучшить их. Если бы мы не ссылались на темы, которые нам не нравятся, но которые актуальны в контексте, мы бы создавали отдельные статьи с обоими, с недостатком большого количества информации и с большим количеством ненужной избыточности одновременно. Подавление ссылок - это не то, как работает построение логической (инфра) структуры. Я не смог найти правила, которые запрещали бы ссылки на статью Sony Bionz только потому, что эта статья все еще незавершенная.Если найдете, дайте мне знать.

- Матиаспол ( разговор ) 16:53, 12 ноября 2012 г. (UTC)

Трудно ответить, поскольку вы настаиваете на своей точке зрения: пожалуйста, прочтите еще раз. И: Чтобы еще раз прояснить: ваши правки в основном в порядке, я только что отменил двух (ОБНОВЛЕНИЕ: ОДИН), которые не улучшили, чтобы помочь вам разобраться.

• Производитель исключен из названия продукта: imho, это стандарт Википедии: я помню, было обсуждение. Я поддерживаю изменение: байонет объектива Canon EF > байонет EF или аналогичный.
• Изменять ссылки на перенаправления, чтобы вызвать трафик по названию статьи, которое вы предпочитаете, неверно. Период.
• Быстрое удаление редиректов: вы сами создаете множество редиректов. Пожалуйста, примите тот факт, что другие тоже видят необходимость в перенаправлении.
• Крик: Иногда уместно и редко нужно, здесь, к сожалению, часто нужно.
• «Мы ...»: ВЫ здесь самый важный человек, представитель Википедии  ? Tagremover ( разговор ) 01:20, 13 ноября 2012 (UTC)

Рецензент [ править ]

Здравствуйте, после проверки ваших вкладов я включил права рецензента для вашей учетной записи. Это дает вам возможность:

• Принять изменения на страницах, на которых происходят ожидающие изменения ,
• Автоматическое принятие ваших изменений на защищенных страницах уровня 2 ожидающих изменений и
• Управляйте отзывами о статьях .

Помните, что это право пользователя:

• Может быть удален в любое время за неправильное использование, и
• Не дает вам особого статуса по сравнению с другими редакторами.

Вам, вероятно, также следует прочитать WP: PROTECT , поскольку эта привилегия пользователя в основном связана с защитой страницы. Поскольку требования для этой привилегии все еще изменяются , я бы посоветовал вам быть в курсе последних событий на странице WP: REVIEWER . Не стесняйтесь спрашивать меня, если у вас есть вопросы! Удачного редактирования! Reaper Eternal ( разговор ) 22:06, 26 ноября 2012 (UTC)

Sony BIONZ: Сделайте это заметным [ править ]

Можем ли мы иметь возможное соглашение о добавлении его в Expeed и DIGIC, если вы или кто-либо другой удвоите размер текста (не путем интеграции килобайт референсов или ссылок). Он IS уже связан мной в процессор обработки изображения . Tagremover ( разговор ) 20:11, 26 января 2013 (UTC)

Tagremover, у меня нет проблем работать с вами, пока вы придерживаетесь правил (то есть наших рекомендаций) и не наносите вред проекту. Однако это не место для каких-либо «частных договоренностей», не поддерживаемых нашими политиками и руководящими принципами, например «если вы добавите x в статью y, я не верну вас». Я много раз говорил вам: вы НЕ ДОЛЖНЫ отказываться от вклада других редакторов, если только они не работают против наших правил, и вы не можете сами улучшить их правки. К сожалению, именно вы смело, сознательно и сознательно действуете вопреки нашим установленным руководящим принципам - вы даже, кажется, гордитесь этим, учитывая, что вы открыто заявили «Игнорировать все правила» в качестве своего принципа действий.

Я уже дал вам расширенный бонус новичка и потратил много часов, пытаясь объяснить / обучить вас некоторым концепциям совместной работы в проекте сообщества и тому, как некоторые вещи должны работать, но поскольку вы удалили эти объяснения и продолжаете игнорировать установленные руководящие принципы до настоящего времени, я определенно не хочу тратить еще больше времени, чтобы помочь вам. Пока вы не исправляете свое поведение, это будет пустой тратой времени, и вы уже давно переоценили мое время - и учитывая ваши многочисленные задокументированные проблемные случаи с другими участниками этого проекта, время и энергию многих других редакторов, как Что ж. Разве это не приходило в голову, что если вы упорно продолжать работать против стены, ядро ​​проблемы могут быть связаны с вами?

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

Теперь дело за вами. - Матиаспол ( разговор ) 00:25, 27 января 2013 г. (UTC)

В следующий раз просто отмените мои правки [ править ]

Я умею читать сводки редактирования и не хочу ввязываться в обратную войну. Мне не очень нравится фальшивое дружелюбие и "предложения" на моей странице обсуждения. Баккиад ( разговор ) 04:37, 27 января 2013 (UTC)

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

В любом случае, после долгого перерыва добро пожаловать в Википедию! (Надеюсь, это было не слишком дружелюбно ;-)) - Матиаспол ( разговор ) 06:02, 27 января 2013 г. (UTC)

Форматирование шаблона камеры [ править ]

Я вижу, что вы принимаете активное участие в обсуждениях на Template talk: цифровые зеркальные камеры Nikon . Кого я могу попросить отформатировать Шаблон: Цифровые зеркальные камеры Kodak и Шаблон: Цифровые зеркальные камеры Fujifilm в таблицах? - TonyTheTiger ( T / C / BIO / WP: CHICAGO / WP: FOUR ) 15:12, 28 января 2013 г. (UTC)

Я переработал шаблон Fujifilm DSLR, но точные даты объявления, отгрузки и окончания производства должны быть исследованы более подробно, и шаблон соответствующим образом настроен.

Шаблон Kodak немного сложнее, поскольку временная шкала охватывает гораздо более длительный период, задействованы два разных крепления для камеры, а некоторые модели были доступны во многих второстепенных вариантах, и я не помню их всех после всех этих лет. Я буду думать, как организовать этот шаблон. - Матиаспол ( разговор ) 00:36, 31 января 2013 г. (UTC)

Я не понимаю этого редактирования, которое указывает на перенаправления шаблона. Таким образом, шаблон не выделяется жирным шрифтом на страницах, к которым он переходит. Это очень странно, - TonyTheTiger ( T / C / BIO / WP: CHICAGO / WP: FOUR ) 17:04, 2 февраля 2013 г. (UTC).

Это веский (и хороший!) Аргумент и исключение из общего правила не обходить перенаправления, Тони. В этом случае преимущество отображения ссылок жирным шрифтом перевешивает преимущества переадресации в статистике, обслуживании и удобочитаемости. Я изменил это соответствующим образом.

- Матиаспол ( разговор ) 22:43, 2 февраля 2013 г. (UTC)

HX DOS Extender [ править ]

Как правило, я, к сожалению, не могу добавить юзерификацию. Если бы он был удален из-за проблем с известностью, у меня не было бы проблем с перемещением его туда, но поскольку это вопрос авторских прав, который должен оставаться удаленным. Однако я, по крайней мере, предоставлю информационное окно и ссылки, которые использовались:

Внешняя ссылка:

• Сайт HX
• HX и общий форум по разработке и поддержке DOS
• Альтернативные / дополнительные документы и список совместимого программного обеспечения

Надеюсь, это поможет, это все, что я могу предоставить. Wizardman 23:53, 2 февраля 2013 (UTC)

Хорошо, Wizardman, спасибо, это начало. И вы уверены, что претензия на G12 была обоснованной? Кто добавил этот тег? - Матиаспол ( разговор ) 00:04, 3 февраля 2013 г. (UTC)

Его добавил Пользователь: Insidious611 , который с тех пор не редактировал. Я проверил текст по трем внешним ссылкам, указанным выше, и обнаружил, что вся статья скопирована дословно, то же самое для пары более ранних версий, которые я проверял. Wizardman 00:58, 3 февраля 2013 (UTC)

К счастью, я имел в виду не этого пользователя, так что это не была попытка обыгрывать систему.

Проверяя ссылки, которые вы дали, я теперь тоже вспоминаю сходства. Учитывая, что это проект с открытым исходным кодом, один из авторов мог изначально внести текст в WP, я не знаю. Но тогда в истории редактирования должно быть какое-то замечание со стороны редактора, объявляющего об этом. Если это так, то проблемы с COI все еще могут быть решены, но, по крайней мере, это больше не проблема copyvio. Думаю, я свяжусь с ними и постараюсь выяснить. - Матиаспол ( разговор ) 01:40, 3 февраля 2013 г. (UTC)

Спасибо за письмо. Я надеюсь, что найду время и сам когда-нибудь напишу статью об этом (ИМХО весьма важном) расширителе ...

- Матиаспол ( разговор ) 01:04, 9 июля 2013 г. (UTC)

Звезда о проекте Star Trek ! [ редактировать ]

Большое спасибо. :-) - Матиаспол ( разговор ) 02:23, 31 марта 2013 (UTC)

Мы должны присоединиться или создать группу по ретро-операционным системам (оперативная группа и т. Д.). Он был бы более конкретным, чем группа ретро-вычислений, в которую входили бы тонны 8-битных и других экстремальных эзотериков. Но это было бы чертовски широко. Спасибо, что возились с OS / 2 . Надеюсь, вам также понравится то, что я сделал с MkLinux , Workplace OS и множеством экзотических вещей, связанных с Mac OS. Голубые пирожные, Система 7, раннее какао и т. Д. Старые предания! - Smuckola (Электронная почта) (Обсуждение) 23:36, 28 мая 2013 г. (UTC)

Продолжайте хорошую работу. - Матиаспол ( разговор ) 01:04, 9 июля 2013 г. (UTC)

Еврейское кладбище Ольсдорф [ править ]

Привет, извините за поздний ответ, я думаю, вам лучше сделать это, так как вы являетесь носителем немецкого языка (если я не ошибаюсь), и по этой причине вам намного легче найти информацию. Википедия затрудняет ввод информации без ссылки на какой-либо источник, так как же мне это сделать, не зная немецкого? В мои намерения не входит нарушение авторских прав, но тогда Википедия должна перестать запрашивать ссылки на источники и ссылки. Cheers Evangelidis ( разговор ) 23:28, 30 марта 2013 (UTC)

Я дал свой ответ на вашей странице обсуждения ( [1] ). Привет. - Матиаспол ( разговор ) 02:23, 31 марта 2013 г. (UTC)

Создание перенаправления [ править ]

Это редкий случай, когда добавление собственной сводки редактирования - плохая идея . Пожалуйста, оставьте поле пустым - все знают, зачем вы их создаете, но цель не всегда очевидна. Incnis Mrsi ( разговор ) 14:46, 12 апреля 2013 (UTC)

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

- Матиаспол ( разговор ) 18:58, 22 апреля 2013 г. (UTC)

Типография [ править ]

Пожалуйста, не используйте в статьях собственную нестандартную терминологию . Вы всегда можете обратиться к боковой панели {{ Знаки препинания }} или к соответствующим статьям. Incnis Mrsi ( разговор ) 14:46, 12 апреля 2013 (UTC)

Ваше утверждение может быть истолковано так, как будто я буду использовать или применять мою нестандартную терминологию повсюду. Я, конечно, вообще этим не занимаюсь. Это единственное изменение было настоящей ошибкой, и как бы я ни был благодарен за исправление, мне интересно, если бы простое исправление уже не помогло. На немецком языке двоеточие называется Doppelpunkt, возможно, именно поэтому я пришел к выводу, что на английском оно будет называться двойным двоеточием ... ;-)

- Матиаспол ( разговор ) 18:58, 22 апреля 2013 г. (UTC)

Ссылка на изменения в основной загрузочной записи [ править ]

Привет, Матиас

Надеюсь, я не беспокою вас, но я чувствую, что пора нам собраться по поводу правок в статье основной загрузочной записи, потому что, очевидно, у нас есть проблемы с пониманием цели друг друга. (Конечно, есть; в одном из ваших сводок редактирования говорится, что вы не уверены.)

В моей редакции 12:17 от 19 апреля 2013 г. я:

• Использованы диспенсеры / ссылки для улучшения стиля цитирования восьми ссылок
• Преобразовал все экземпляры <tt> в <code> (потому что Reflinks предупредил меня, что <tt> устарел в HTML5)
• Удален неправильно установленный маркер оглавления (из-за которого между полем оглавления и первым заголовком было слишком много места)
• Добавлен {{ Reflist }} вместо вложенных тегов <reference>
• Забыл включить все это в поле сводки редактирования

Сам Reflinks удалил подчеркивание (_) из якорей.

Затем я увидел вашу правку в 22:01, 19 апреля 2013 года . В нем были вещи, в которых я не был уверен, что вы намеревались быть там, только я не мог сказать, какие именно. (Я был уверен, что маркер TOC, например, не предназначен.) Но в вашем сводке редактирования говорилось, что вы предпочитаете использовать тег <tt>. Итак, я внес правки 09:30, 20 апреля 2013 г. и 09:36, 20 апреля 2013 г. Я вернулся к версии Yobot, которая, по моему мнению, была наименее оспариваемой, и повторил свой список редактирования, за исключением пункта № 2.

Я думал, что это должно решить наш маленький спор, но разве я не ошибался? Я не уверен, что означает эта часть сводки редактирования: «Я снова переформатирую шаблоны, чтобы в них не было болтающихся пробелов (что технически плохо)». Я вижу разрывы строк перед каждым параметром (который я не поддерживаю и не против) и |author=параметры, на которые разбиваются |first=и |last=(что я ценю). Что еще я пропустил?

С уважением,
Кодовое имя Лиза ( разговор ) 17:53, 20 апреля 2013 (UTC)

Привет, Лиза.

Да, токен TOC точно может пройти. Хорошо подмечено! Он был вставлен, когда статья еще не была полностью структурирована, так что оглавление появилось в нужном месте. Как-то я пропустил это при редактировании.

Что касается < code> и < tt >, до некоторой степени они взаимозаменяемы, по крайней мере, до тех пор, пока только один из них используется в одном изделии. Однако в статьях, посвященных обоим, я почти постоянно видел, что <tt> используется для чисел, а <code> - для фрагментов кода, команд и т. Д. Я не знаю, устарел ли <tt> (я мог бы посмотреть это вверх), но тогда нам пришлось бы разработать шаблон макроса, чтобы имитировать его внешний вид телетайпа (без изменения цвета фона), поскольку использование <code> может действительно отвлекать, когда числа имеют другой цвет фона, чем обычный текст. В таблицах это тоже выглядит очень странно, поскольку затенение фона также не соответствует оттенку фона таблиц по умолчанию.

Что касается подчеркивания ('_'), к счастью, это работает в обоих направлениях. Я обычно использую пробелы ('') в обычном (потоковом) тексте и подчеркивания в идентификаторах, таких как символы. Поскольку я рассматриваю невидимые привязки и имена ссылок как символы, я использую для них подчеркивания. Опыт показал, что использование пробелов в символах делает синтаксический анализ более сложным и подверженным ошибкам, поскольку пробелы также используются в качестве разделителей, и необходимы дополнительные правила, чтобы различать пробелы, которые на самом деле что-то ограничивают, и пробелы, которые этого не делают. Wiki-синтаксис допускает оба способа почти во всех случаях (до тех пор, пока парсер не сломан), поэтому здесь нет четкого правильного или неправильного, я просто думаю, что мы должны использовать тот же стиль в ссылке, что и в соответствующая цель ссылки. Итак, если мы свяжемся с якорем с именем #abc_123,кажется странным использовать#abc 123в ссылке просто потому, что «мы можем». Рано или поздно это вызовет проблемы.

Что касается ссылок, я не был уверен, почему вы сначала отменили мою правку, чтобы снова применить большую часть этого материала в следующем редактировании. ;-) В конце концов, я уже позаботился о <tt>, так что ваш откат, похоже, был нацелен в основном на ссылки - только то, что я не сделал много со ссылками, кроме переформатирования их до одного параметра в строке ( где возможно), тем самым зафиксировав два болтающихся work=иpages=параметры и оптимизация дат для использования международного формата даты, как определено в ISO 8601 (и ранее использовалось в статье). Как и вы, у меня нет личного предпочтения помещать все это в одну строку или использовать одну строку для каждого параметра (возможно, очень небольшое предпочтение по сравнению с первым, поскольку оно не вводит переводы строк в качестве еще одного подстановочного символа в синтаксический анализ параметров. ), однако я просто пытаюсь использовать все, что используется на существующей странице (если можно определить предпочтения - возможно, не в этой конкретной статье ;-)). Однако по тем же причинам, что указаны выше (потенциальные трудности синтаксического анализа), я стараюсь избегать пробелов перед или после аргумента как части аргумента. Если я имею в виду " test string", почему я должен писать "  test string", " test string " или даже " test string "? Я бы сделал это, только если пробел является важной частью самого аргумента. Следовательно, зная, что вертикальная черта '|' здесь является разделитель, рекомендую

argument1=test string|argument2=test string|argument3=test string

вместо форм вроде

argument1= test string|argument2=test string |argument3=test string

В противном случае синтаксический анализатор (ревизия) может рассматривать пространство как часть аргумента, вызывая неоднозначность. Конечно, синтаксический анализатор может удалять пробелы на обоих концах аргумента (в настоящее время он делает это для именованных параметров, но не для безымянных параметров), но что, если бы существовали действительные аргументы, которые действительно должны содержать пробелы в этих местах? Это потребует реализации большего количества обходных путей, исключений или выполнения вне очереди, что сделает его более сложным и, следовательно, более подверженным ошибкам и трудным в обслуживании. (У нас уже есть ряд особых случаев для конечных точек, включая необходимость в дополнительных параметрах для отмены этих значений по умолчанию.; ->) В случае многострочных шаблонов мы можем (безопасно?) Предположить, что преднамеренный перенос строки также используется как разделитель,по крайней мере, это гораздо менее вероятная часть аргумента, чем незавершенное пространство.

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

Привет. - Матиаспол ( разговор ) 22:09, 20 апреля 2013 г. (UTC)

Здравствуй.

Я расспрашивал о парсере. Предполагая, что у нас есть |name=value:

• Начальные и конечные пробелы вокруг трубы (|) допустимы
• Начальные и конечные пробелы вокруг имени параметра допустимы
• Конечный пробел после значения - это нормально
• Пробел перед значением (после знака равенства) не всегда допустим. Он анализируется, но может игнорироваться парсером второго уровня, который интерпретирует код шаблона. Таким образом, это варьируется от шаблона к шаблону.

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

Что касается преобразования между <tt>...</tt>и <code>...</code>, меня просят перестать беспокоиться и не предпринимать преднамеренных попыток выполнить или оспорить преобразование, поскольку оно касается только синтаксического изменения.

С наилучшими пожеланиями,

Кодовое имя Лиза ( разговор ) 09:08, 21 апреля 2013 (UTC)

Двоичное число и шестнадцатеричное [ править ]

Привет, Матиаспол,

Я хотел сообщить вам, что недавно я отменил два ваших редактирования, одно в двоичное число, а другое в шестнадцатеричное . В обоих случаях вы добавили замечание по поводу слов «соглашение Intel» и «соглашение Motorola». Я не знаю, распространены ли эти обычаи (я математик), но мне не удалось найти никаких ссылок, использующих цитируемые фразы. В шестнадцатеричной статье я подумал, что комментарий был излишним, поскольку в абзаце уже упоминается в обоих случаях, когда используется соглашение; в статье о двоичных числах было бы полезно объяснение, подобное шестнадцатеричному, особенно с цитатами. К сожалению (как я уже отмечал) я действительно ничего не знаю по этой теме и поэтому не знаю, в каком надежном источнике может быть такая информация.

Всего наилучшего, JBL ( обсуждение ) 17:57, 22 апреля 2013 (UTC)

Привет, Джоэл, спасибо, что сообщил мне о вашем возврате. Что ж, я настолько привык к этим условиям, что мне это не пришло в голову, что кто-то может их усомниться. Надеюсь, вы не сомневаетесь в существовании этих обозначений, а только в их именах, или вы? Я мог бы придумать много старых книг по программированию (эпоха 1980-х годов), цитирующих эти обозначения как используемые (и, по-видимому, первоначально введенные) Intel и Motorola, но может быть трудно найти источник, формально определяющий их как «соглашение Motorola». или «соглашение Intel», именно так я видел, как эти обозначения использовались в устном общении на протяжении десятилетий.

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

Приветствую, Матиаспол ( разговор ) 18:58, 22 апреля 2013 (UTC)

Привет, Матиаспол,

Ну, как я уже сказал, я мало что знаю об этом, но у меня нет причин сомневаться в правильности обозначений в том виде, в котором они представлены; я также не сомневаюсь в вашей компетентности в этом вопросе (и если вы повторно вставите свой текст, я не потерплю недовольства и не вернусь снова, хотя мне кажется, что это покрыто шестнадцатеричным числом). Мне кажется, что если у вас есть готовый доступ к такого рода информации, было бы здорово (по причинам, которые вы указали) добавить к двоичному номеру информацию о статье, аналогичную шестнадцатеричной, то есть краткий список контекстов (Intel, Motorola, а также другие, если вы их знаете), где используются различные перечисленные обозначения.

Всего наилучшего, JBL ( обсуждение ) 23:20, 30 апреля 2013 (UTC)

Теперь я столкнулся с двумя источниками, поддерживающими мой первоначальный вклад в отношении соглашений Intel и Motorola . Поэтому я вернул его, добавив те ссылки.

- Матиаспол ( разговор ) 18:11, 5 августа 2015 (UTC)

Для оспариваемых утверждений нужен источник [ править ]

Привет, Матиас

Я должен поторопиться, поэтому заранее прошу прощения за резкое и грубое сообщение. Об этом: [2] . Возможно, вы уже знаете, что публикации в Википедии без ссылок могут быть оспорены или удалены. Я уже зарегистрировал возражение против грубых резюме редактирования 82.236.210.11 на его странице обсуждения, но согласно политике Википедии, никто не должен восстанавливать его удаления без предоставления источника, подтверждающего оспариваемое утверждение.

Фактически, я сам действительно хочу увидеть доказательства того, что Windows 9x была основана на DOS.

С уважением,
Кодовое имя Лиза ( выступление ) 08:25, 29 апреля 2013 г. (UTC)

Раньше лингвистика vs. техническая точность; теперь источник [ править ]

Привет, Матиас

Я надеюсь , что я вас не беспокоит , но я думал , что я дам вам записку о моем BRDing ваш редактировать в Windows 95 . Вы написали «При запуске компонент MS-DOS в Windows 95». На данный момент я полагаю, что с технической точки зрения это полностью верно. Однако с лингвистической точки зрения это не так. Другими словами, люди не так говорят (или пишут). «Компонент MS-DOS в Windows 95» может относиться ко многим вещам, включая COMMAND.COM и командную строку.. Итак, ваше предложение в лучшем случае расплывчато, если не странно. Просто для проверки я показал ваше предложение своему брату, и он действительно подумал, что ему следует нажать F8 после появления экрана приветствия Windows 95 и что у него есть огромное окно возможностей для этого до появления рабочего стола. (Что подкрепляло его интерпретацию, так это то, что в абзаце позже говорилось о «выходе в DOS», который происходит только при работе Windows 95.) Однако загрузчик часто ассоциируется с меню, которое позволяет им выбирать операционную систему. Он оказался более успешным, потому что предполагал, что перед запуском операционной системы необходимо нажать F8.

Я помню, как Ричард Столлман пытался убедить людей начать говорить «отфотошопил» и вместо этого говорить «GIMPing», когда они говорят о подделке изображения. Ему это не удалось, потому что он не смог понять, что язык не является предметом высшей технической точности: слова создаются в языке, но затем их значение развивается, в то время как их форма ускользает от изменений. Итак, да, возможно, код загрузчика Windows 95 представляет собой код MS-DOS, как вы говорите (технически правильно), но написание статьи - это вопрос правильного сочетания точности, естественности и эмоциональной реакции. Это вопрос написания того, что люди понимают, а не того, что один редактор считает наиболее правильным с технической точки зрения.

С уважением,
Кодовое имя Лиза ( выступление ) 10:00, 4 мая 2013 г. (UTC)

PS Я вижу, что вы сделали обратный ход, пока я писал это. Хммм ... Думаю, теперь весь смысл обсуждения потерян. Кодовое имя Лиза ( разговор ) 10:02, 4 мая 2013 (UTC)

Мэтт, похоже, ты вовлечен в конфликт редактирования . Пожалуйста, придерживайтесь РГ: BRD : Когда кто-то отменяет вас и оставляет вам сообщение, пожалуйста, обсудите с ним. Когда кто-то возвращается и не оставляет сообщение, вы делаете это. Что бы вы ни делали, не редактируйте-войну. И, кстати, я думаю, что то, что вы написали, является явной чепухой, не стесняйтесь добавлять источник; Я хотел добавить «если можешь», но ты не можешь, потому что это неправда.

И кодовое имя Лиза, ради бога, перестаньте вести себя рыцарски и негативно. Сообщите о воинах редактирования WP: ANI. Командование флотом ( разговор ) 10:26, 4 мая 2013 (UTC)

Привет ребята. Я не думаю, что здесь или в статье есть какие-либо примеры рыцарства или негатива, и я думаю, что преждевременно называть кого-либо «воином редактирования» или даже думать о WP: ANI или WP: AN / EW . Однако преждевременно выдвигать обвинения вроде «преуменьшения роли MS-DOS». Сначала нам нужно доказать роль MS-DOS, а затем пойти по этому пути. И я стараюсь не быть ни одним из тех, кто кричит «это было на основе MS-DOS», или тех, кто кричит «это ерунда». Однако я хотел бы защитить то, что называть его «загрузчиком» не противоречит его названию «Код MS-DOS». Загрузчики - это тоже код; таким образом, они могут быть кодом MS-DOS. (Но для этого нам нужен источник.) Я предлагаю эти два источника:

• http://support.microsoft.com/kb/217210
• http://support.microsoft.com/kb/155034

С наилучшими пожеланиями,

Кодовое имя Лиза ( разговор ) 11:10, 4 мая 2013 (UTC)

И снова здравствуйте, Матиас. И снова я проявил добросовестность к людям, которые не предоставляют исходный код, и разочарован: согласно [3] , [4] и [5] , возможность выхода в MS-DOS доступна только в системах, которые поддерживают мультизагрузку. DOS и Windows 95. Несмотря на то, что я не исключаю возможности того, что эти источники могут подвергаться различным интерпретациям, я также не исключаю возможность того, что ИЛИ без ссылки, написанное в статье, могло быть результатом аналогичной ошибки.

В заключение я цитирую WP: V : «Любой материал, который оспаривается или может быть оспорен, должен быть отнесен к надежному опубликованному источнику с использованием встроенной цитаты». С уважением, Кодовое имя Лиза ( выступление ) 11:32, 4 мая 2013 г. (UTC)

@Fleet: Я действительно удивлен, когда вы видите противоречие между мной и Лизой, но я, конечно же, не вижу. Я полностью расслаблен, и я думаю (надеюсь на это) Лиза тоже. Кроме того , мы будут обсуждать , когда вещи нужно обсуждать, но я не думаю , что каждый прав в потребностях потока должны быть отражены на страницах обсуждения. Вот для чего нужны сводки редактирования.

Лиза, добросовестно исправляя статью, сделала технически некорректное заявление, которое я улучшил. Затем Лиза вернулась по лингвистическим причинам, а я восстановил, потому что, как бы я ни любил хорошую прозу, я чувствую, что правда (техническая точность) более важна, если и то и другое не может быть достигнуто одновременно. В резюме я объяснил, почему использование термина «загрузчик» в этом контексте здесь неуместно, но призвал ее найти более подходящие слова. На самом деле, я вижу здесь форму конструктивного сотрудничества, а не противодействия редактированию. В любом случае, все это было вызвано тем, что несколько дней назад рассерженный IP удалил большие части статьи, которые я восстановил, потому что я нашел их жизненно важными для понимания определенных аспектов этой операционной системы. Я не был автором этих частей. - Матиаспол ( разговор) 13:22, 4 мая 2013 г. (UTC)

(Править конфликт) Привет, Лиза, ничего не потеряно. Я бы тоже связался с вами, но вы были быстрее. Дело, однако, в том, что здесь важно быть технически точным, потому что это один из ключей к пониманию гибридной архитектуры этого продукта под названием Windows 9x, который был связкой MS-DOS 7.xx + Windows 4 .xx. Как вы, возможно, знаете, операционная система изначально рекламировалась Microsoft как полностью новая, переписанная и без каких-либо следов MS-DOS, хотя на самом деле базовая архитектура не изменилась по сравнению с DOS + Windows 3.xx с запущенной частью Windows. в 386 расширенном режиме. Одно из отличий заключается в том, что процесс запуска MS-DOS запутан, поскольку MS-DOS отображает графический логотип, поэтому пользователи не могут видеть (все еще происходящий) обычный текстовый вывод, и что он запускает WIN.COM автоматически (как вы, вероятно, знаете,отключить это тривиально, но у простых пользователей все еще создается впечатление, что DOS больше не существует). Другое отличие состоит в том, что Windows 4, конечно, имеет лучшую поддержку драйверов, поэтому она может обрабатывать больше данных в 32-битном защищенном режиме без необходимости передавать это «вниз» в MS-DOS и / или BIOS. Есть много других усовершенствований и дополнений, но ничего, что могло бы изменить базовую гибридную архитектуру - даже не в Windows ME (MS-DOS 8.0 + Windows 4.9). Я заключил «в кавычки» выше, потому что то, что происходит на самом деле, сложнее и труднее описать, если вы не знакомы с защищенным режимом 386 и виртуальным режимом x86. Вот где «внутри», «на» и «под» имеют больше, чем очевидные значения (согласно MOS), и, в конечном счете, это были все эти обсуждения,является ли Windows 9x собственной операционной системой или нет, и если MS-DOS является ее жизненно важной частью, все еще находится в ожидании совместимости, используется только во время загрузки или не существует вообще, исходит из. Когда-то это был вопрос на несколько миллионов долларов, который активно обсуждался в отрасли, поэтому важно быть технически точным, и мы должны постараться не использовать для некоторых целей лексику, неправильно использованную в этой «войне операционных систем». В конце концов, мы хотим сказать правду, а не "новое слово" одной партии? Microsoft, конечно же, пыталась убедить людей, что DOS больше не нужна и используется только опционально для запуска устаревшего приложения DOS и в качестве «загрузчика», в то время как независимые отраслевые эксперты продемонстрировали в статьях журналов, в книгах, а также успешно в суд, что это явно не так.Если вам действительно интересна эта тема, я рекомендую вам изучить книги Эндрю Шульмана «Недокументированная DOS» (2-е издание) и «Неавторизованная Windows 95». Эти книги далеко не охватывают все связанные с этим аспекты, но они технически точны, хорошо читаются и очень хороши. хорошее введение. Изучив их, вы также поймете, почему ответ Microsoft на одну из этих книг (ссылка на этот IP-адрес) также является макроскопически правильным (конечно), но в основном (намеренно) не по делу. Даже в нашем недавнем IP-заявлении говорилось, что «теория» Эндрю (как выразилось в IP - на самом деле это не теория, а технические факты) полностью опровергнута, в то время как на самом деле это не так.Эти книги далеко не охватывают все связанные с этим аспекты, но они технически точны, их хорошо читать и очень хорошо вводить. Изучив их, вы также поймете, почему ответ Microsoft на одну из этих книг (ссылка на этот IP-адрес) также является макроскопически правильным (конечно), но в основном (намеренно) не по делу. Даже в нашем недавнем IP-заявлении говорилось, что «теория» Эндрю (как выразилось в IP - на самом деле это не теория, а технические факты) полностью опровергнута, в то время как на самом деле это не так.Эти книги далеко не охватывают все связанные с этим аспекты, но они технически точны, их хорошо читать и очень хорошо вводить. Изучив их, вы также поймете, почему ответ Microsoft на одну из этих книг (ссылка на этот IP-адрес) также является макроскопически правильным (конечно), но в основном (намеренно) не по делу. Даже в нашем недавнем IP-заявлении говорилось, что «теория» Эндрю (как выразилось в IP - на самом деле это не теория, а технические факты) полностью опровергнута, в то время как на самом деле это не так.но в основном (намеренно) не по делу. Даже в нашем недавнем IP-заявлении говорилось, что «теория» Эндрю (как выразилось в IP - на самом деле это не теория, а технические факты) полностью опровергнута, в то время как на самом деле это не так.но в основном (намеренно) не по делу. Даже в нашем недавнем IP заявлено, что «теория» Эндрю (как выразилось в IP - на самом деле это не теория, а технические факты) полностью опровергнута, в то время как на самом деле это не так.

Но вернемся к исходному вопросу, возможно, если бы мы подробно описали весь процесс запуска с момента, когда объемная загрузочная запись передает выполнение в BIOS DOS (один из компонентов в IO.SYS), до момента загрузки графической оболочки (WIN. INI SHELL = EXPLORER.EXE), мы также найдем более естественное и лингвистически более приятное место для описания меню загрузки параллельно с этим процессом. Однако статьи о Windows 9x в настоящее время не входят в круг моих непосредственных интересов, поэтому время, которое я готов потратить на них, определенно ограничено (по крайней мере, в настоящее время). Мне просто не нравится, когда там распространяется ложь, поэтому я удалил некоторые неверные утверждения, которые вызывают неправильное впечатление и поэтому не помогают понять, как эта система на самом деле работает.

- Матиаспол ( разговор ) 12:42, 4 мая 2013 г. (UTC)

Я хотел бы помочь Матиасу здесь. Здесь важна техническая точность как с энциклопедической точки зрения, так и с точки зрения нейтральности. В то время как в целом «операционная система по сравнению с графической оболочкой» обсуждение было когда - то весьма спорным, нет абсолютно никаких споров о том , как W95 работает с чисто технической точки зрения (спросить , есть ли у вас Shulman или разработчик ядра Windows) . В состязательности вопроса только начать прибыть, как только вы попытаетесь свести всю эту техническую сложность к двоичному выражению «операционная система» или «графическая оболочка», и, соответственно, когда вы начнете применять такие ярлыки, как «операционная система» или «загрузчик», MS-DOS компонент W95. - Рууд, 14:03, 4 мая 2013 г. (UTC)

Привет, Матиас. Привет, Рууд.

На данный момент я воздерживаюсь от комментариев этих заявлений. Однако в свете противоречивых заявлений нашего приглашенного редактора и источников, которые я нашел, этот вопрос больше не является вопросом технической или естественной формулировки. (Я изменил заголовок, чтобы отразить эту проблему, но это ваша страница обсуждения, Матиас; вы можете вернуть ее.) Согласно WP: V , «любой материал, который оспаривается или может быть оспорен, должен быть отнесен к надежному опубликованному источнику с использованием встроенное цитирование ".

С уважением, Кодовое имя Лиза ( выступление ) 16:36, 4 мая 2013 г. (UTC)

Вы не смогли понять, о чем говорят эти источники. Фактически, источники, которые вы упомянули в сводке редактирования, полностью согласуются с утверждением, которое вы удалили и утверждали, что это были оригинальные исследования. Вам, должно быть, каким-то образом удалось неверно истолковать утверждение «Возможность загрузки предыдущей версии MS-DOS будет присутствовать только в том случае, если MS-DOS была установлена ​​до установки Windows 9x.» Из одного из источников, как означающее все меню загрузки исчезает, а не просто 7-й вариант. - Рууд 17:11, 4 мая 2013 г. (UTC)

Привет. Вот что я сказал: вы представляете свою собственную интерпретацию. И, как я уже сказал, я не против и не поддерживаю. Но предложение, которое вы только что вернули в статью: есть ли у нее источник? Нет. Итак, я добавляю к нему {{citation required}}, чтобы отразить эту проблему, но не буду возражать, если вы удалите его. И, пожалуйста, не поймите меня неправильно: я не хочу сказать, что то, что я делаю, абсолютно правильно; на самом деле, любые отзывы приветствуются. С уважением, Кодовое имя Лиза ( выступление ) 18:52, 4 мая 2013 г. (UTC)

Привет ребята. Просто взял копию Windows 95. Я был прав и неправ. Часть, которую я был прав, касалась интерпретации [6] : исчезла только опция №7, а не все меню (как предложил Рууд). Однако я ошибался в том, что к настоящему моменту я предполагаю, что можно загрузиться в DOS с помощью опции № 5, «Только командная строка». Я не мог сделать это в своей системе, потому что система перестает отвечать, но я определенно видел попытку загрузить COMMAND.COM. Тем не менее ... там много всего ... С уважением, Кодовое имя Лиза ( выступление ) 07:30, 5 мая 2013 г. (UTC)

Отмена моих правок в статье SuperDrive [ править ]

Не могли бы вы объяснить, почему вы отменили мои недавние правки к этой статье? Bumm13 ( разговорное ) 00:27, 22 мая 2013 (UTC)

Возможно, вам будет полезно осознать, что Wikipedia: Piped link не является действительной политикой, и что я действительно не согласен с тем, что вы вернете мои добросовестные правки в SuperDrive , особенно с учетом вашей относительной неопытности в качестве редактора Википедии. Спасибо Bumm13 ( обсуждение ) 01:03, 22 мая 2013 (UTC)

Привет Bumm13. Думаю, все относительно. Ваши правки были определенно добросовестными (я не сомневался в этом и никогда не говорил об обратном), но, тем не менее, они были неправильными и, следовательно, должны были быть исправлены кем-то. Я дал указатель на WP: NOPIPE , потому что этот раздел, естественно, ведет к WP: REDIR и WP: NOTBROKEN , которые являются установленными правилами редактирования. В этих рекомендациях четко указано, что мы не должны заменять перенаправления конвейерами (как вы это сделали здесь: [7] ):

* [[FAT12]] -> [[Таблица размещения файлов № FAT12 | FAT12]]

* [[ProDOS]] -> [[Apple ProDOS | ProDOS]]

* [[CD]] -> [[Компакт-диск | CD]]

На самом деле мы должны делать прямо противоположное:

* [[Таблица размещения файлов № FAT12 | FAT12]] -> [[FAT12]]

* [[Apple ProDOS | ProDOS]] -> [[ProDOS]]

* [[Компакт-диск | CD]] -> [[CD]]

Поэтому я был бы признателен, если бы вы сами отменили свой возврат к моему исправлению вашего редактирования, а не мне (или кому-то другому), чтобы это сделать.

Я не проверял вашу историю изменений, но если вы делали аналогичные изменения в недавнем прошлом, было бы неплохо заранее пересмотреть и, при необходимости, исправить их.

Другое примечание: комментарии, подобные этому ( [8] ), в которых вы пытаетесь запугать и подтолкнуть другого редактора, не подходят для любого администратора, в частности, по поводу чего-то столь же незначительного, как эта полная не проблема. Я отвечаю на разговоры, когда нахожу для этого время (и думаю, что это необходимо), а не когда кто-то пытается подтолкнуть меня (в данном случае даже с фактически неверными утверждениями). Однако, исходя из вашей добросовестности, я предполагаю, что вчера у вас как-то был плохой день, и поэтому желаю вам удачи. - Матиаспол ( разговор ) 11:23, 22 мая 2013 г. (UTC)

Проблема в том, что вы не указали никакой реальной причины того, почему мои правки были неправильными, кроме тех страниц псевдополитики WP: THISPAGE и WP: THATPAGE, которые подтверждают ваше мнение по этому вопросу. Конкретное утверждение « Необязательно направлять ссылки просто во избежание перенаправления» было добавлено пользователем: Rockero 23 июня 2006 г. (согласно [ этой разности ]). В его заявлении нет ничего авторитетного, и оно противоречит чистым прямым ссылкам на страницы статей. Иными словами, редирект служит потребностям редакторов, а не наоборот. Это не ваша вина, что этот вопрос не был поднят в разговоре в Википедии: Канальная ссылка страница обсуждения до сих пор, но рассматривать мои правки так, как если бы они не отличались от вандализма, и действовать путем их отмены, возможно, демонстрирует плохую осмотрительность в отношении того, что вы сами сказали, «что-то столь же ничтожное, как это полное не-проблема».

Что касается указателя на WP: NOPIPE, который «естественно» ведет к WP: REDIR и WP: NOTBROKEN , похоже, вы сами добавили ссылку на WP: NOTBROKEN (согласно этому [ diff ]). Я был бы осторожен при сопоставлении такого слова, как «естественно», с «потому что я считаю его естественным и, таким образом, добавил то, с чем я согласен, на страницу в Википедии».

Что касается моего комментария, на который вы ссылались ранее, я извиняюсь за грубость или напористость, но я отредактировал комментарий (удалив его), поэтому я могу только надеяться, что вы примете мои извинения. Я здесь не для того, чтобы подталкивать других редакторов или что-то в этом роде; Я хочу, чтобы Википедия продолжала совершенствоваться как хранилище знаний. С уважением, Bumm13 ( разговор ) 03:12, 24 мая 2013 (UTC)

Bumm13: «Проблема в том, что вы не указали никакой реальной причины того, почему мои правки были неправильными, кроме тех страниц псевдополитики WP: THISPAGE и WP: THATPAGE, которые подтверждают ваше мнение по этому вопросу».

Матиаспол: Бумм, на самом деле, я думаю, что это резюме редактирования ( [9] ) было довольно ясно о том, что не так с редактированием. Возможно, я мог бы сказать WP: NOTBROKEN вместо WP: NOPIPE , но результат был бы тот же. Как я уже сказал, я хотел указать вам на оба одновременно, поэтому я использовал WP: NOPIPE . Я имею в виду, что мы здесь не для того, чтобы играть в игры типа «кто знает лучше WP: SOMETHING pointer», но мы здесь, чтобы делать «правильные вещи», или, другими словами, даже если я вообще не давал никаких сводок редактирования или если бы вы были неопытным редактором или даже IP-адресом, ваши правки, о которых идет речь, все равно были бы некорректными, и, согласно вашим изменениям на Википедии: страница ссылок на канал ( [10]) вы знали о директивах WP: NOTBROKEN и WP: REDIR (и, следовательно, о том, что ваши недавние правки нарушали их) до того, как пожаловались на то, что WP: NOPIPE не является директивой на моей странице обсуждения ( [11] ). Мне это кажется немного странным.

Не волнуйтесь, я не хочу делать из этого "аргументы" (потому что я здесь, чтобы улучшить WP, и меня совсем не интересует трата времени), но, учитывая ваш ответ выше, я просто хочу укажите, что эта конкретная «проблема» существует не потому, что я (или кто-то другой) допустил ошибку, а потому, что вы, по-видимому, каким-то образом не знали о WP: NOTBROKEN и WP: NOPIPE до ваших правок. Нет проблем, поэтому мы можем сравнивать и возвращаться. Я бы не стал называть «ошибкой» незнание каких-то случайных рекомендаций (у всех нас, конечно, есть белые пятна), но, пожалуйста, не пытайтесь найти оправдания где-нибудь еще.

Bumm13: "Конкретное утверждение" Необязательно прокладывать ссылки просто, чтобы избежать перенаправления "было добавлено пользователем: Rockero 23 июня 2006 г. (согласно [ этой разности ]). В его заявлении нет ничего авторитетного, и оно бросает вызов чистых прямых ссылок на страницы статей ".

Матиаспол: Это «авторитетно» в том смысле, что, по-видимому, подавляющее большинство редакторов согласны с ним с 2006 года. Фактически, текущий текст существует после согласованного обсуждения на странице обсуждения в Wikipedia talk: Канальная ссылка # Использование конвейера для создания ссылок длиннее, чем необходимо в 2007 году / 2008. И в каналах нет ничего более «чистого», чем в редиректах. Оба они служат ряду хороших целей, и их также можно заставить работать для вещей, для которых они не подходят. Наши усилия всегда должны быть направлены на использование наилучшего доступного инструмента для конкретной цели в данном сценарии.

Я понимаю, что это может быть неловко и - на первый взгляд - даже может показаться плохой идеей использовать переадресацию, когда вы предпочитаете и привыкли использовать каналы и каким-то образом пропустили соответствующие рекомендации за все эти годы, но, пожалуйста, позвольте мыслить, что перенаправления на самом деле намного превосходят каналы, во многих случаях они осваиваются в течение нескольких дней и пытаются без предвзятости сравнивать их плюсы и минусы (и их технические возможности). Я совершенно уверен, что вы научитесь ценить их так же, как и все остальное сообщество. (Я знаю, что перенаправления в текущей реализации не идеальны (и, возможно, одна из их особенностей является причиной, по которой они вам не нравятся), но это связано только с проблемами реализации, которые со временем будут преодолены, тогда как каналы , если их использовать в неправильных местах, они действительно становятся серьезнымпроблема , потому что они концептуально являются неправильным инструментом и прямо подрывают рост и ремонтопригодность Википедии и будущей семантической сети («Веб 3.0»).

Bumm13: «Это не ваша вина, что этот вопрос не поднимался на странице обсуждения в Википедии: канальная ссылка до сих пор»,

Matthiaspaul: Bumm13, вина это Нун, есть не никакой проблемы с содержанием на Википедии говорить: Водопроводной ссылку в ее нынешнем виде вообще, по крайней мере , не на мой взгляд (и , видимо , не по мнению большинства других редакторов , а также, в противном случае все эти годы они вызывали бы серьезные опасения).

Bumm13: «но относиться к моим правкам так, как если бы они не отличались от вандализма, и действовать путем их отмены - это, возможно, проявление плохой осмотрительности в отношении того, что вы сами сказали,« что-то столь же ничтожное, как это полное несущество ».

Матиаспол: Я очень огорчен, увидев, что тебе почему-то причинили боль, но тебе действительно не нужно обижаться только потому, что кто-то вернул тебя (по какой-то причине). Однако я не согласен с вами, когда вы пытаетесь привести доводы, которых на самом деле нет. Единственный способ справиться с этими конкретными вашими изменениями ( [12] ) - это отменить их ( [13]). Это не было обязательным, поскольку они явно нарушали наши правила. Также невозможно «наполовину вернуть» плохо отформатированную ссылку. Я мог бы «незаметно» вернуться к старой версии и предоставить сводку редактирования, такую ​​как «фиксированные ссылки на руководящие принципы», не указывая, что я действительно вернул вас, но я бы рассмотрел возможность преднамеренного предоставления вводящих в заблуждение сводок редактирования в качестве игры в систему. Поскольку ваши изменения распространились на 5 правок, я не хотел отменять пять аналогичных отдельных ваших правок, поэтому я отменил их все за один раз и, в соответствии с руководящими принципами, был вынужден сделать фиктивное редактирование, чтобы модернизировать соответствующее резюме редактирования. Это именно то, что я сделал, и я улучшил ваше изменение сноски в той же редакции. Моя сводка редактирования гласит: «Сводка редактирования для предыдущего отката:Мы сознательно стараемся избегать труб там, где это возможно, в соответствии сРГ: НОПИП . Повторно применил усовершенствование Bumm13 для обозначения неоднозначности, но теперь с использованием соответствующего шаблона ". В нем нет ни малейшего намека на недобросовестность или даже вандализм. Пожалуйста, не пытайтесь прочитать это в нем, его там нет.

Bumm13: «Что касается указателя на WP: NOPIPE, ведущего« естественно »к WP: REDIR и WP: NOTBROKEN , похоже, что вы сами добавили ссылку на WP: NOTBROKEN (согласно этому [ diff ])».

Матиаспол: Конечно.

Bumm13: «Я был бы осторожен с корреляцией такого слова, как« естественно », с« потому что я считаю его естественным и, таким образом, добавил что-то, с чем я согласен, на страницу в Википедии ».

Матиаспол: Я добавил эту ссылку, чтобы редакторам было проще найти соответствующую информацию о наших установленных правилах редактирования. WP: NOPIPE и WP: NOTBROKEN тесно связаны друг с другом в своих практических последствиях и рассуждениях. Ссылки на связанное содержимое («естественно») - это нормальное явление. Я действительно не понимаю, что вы думаете здесь не так.

Что касается вопроса, почему перенаправления в большинстве случаев превосходят каналы, а также некоторых исключений, в которых их нет, см. Также страницы обсуждения соответствующих руководящих принципов. При разработке этого руководства было обсуждено и учтено множество вещей, которые отражают консенсус сообщества, достигнутый за многие годы. Здесь я мог только повторить плюсы и минусы. Если вы не согласны с ними, сообщите о своих сомнениях на соответствующих страницах обсуждения. Если хотите, мы можем продолжить обсуждение плюсов и минусов там, но, насколько я понимаю, я хотел бы, чтобы некоторые технические проблемы были решены, но с точки зрения системного архитектора я доволен "стратегическим"указание, изложенное в этих рекомендациях, в сторону логического и атрибутивного связывания (перенаправления) вместо низкоуровневого физического связывания (каналы). Жизненно важно, чтобы проект такого размера и сложности был управляемым сейчас и в долгосрочной перспективе. В конце концов, Википедия 2013 года уже не та, что была десять лет назад.

Остается один важный вопрос: исправите ли вы свои недавние правки в WP: NOTBROKEN или оставите это мне или другим редакторам?

Привет. - Матиаспол ( разговор ) 12:18, 24 мая 2013 г. (UTC)

Здесь были внесены изменения ( Обсуждение в Википедии: Redirect # Section_.22Don.27t_fix_links_to_redirects_that_aren.27t_broken.22_suggested_change ) всего девять дней назад, которые указывают на отсутствие консенсуса по вопросу WP: NOTBROKEN, но вы отменили мои изменения, как будто есть абсолютный консенсус по этому поводу (его нет и никогда не будет).

Поскольку мои правки ничего не сломали, они останутся как есть. Если вы лично решите отменить их (даже если они никоим образом не вредят Википедии и не являются вандализмом), я буду считать вас вовлеченным в затяжной спор об изменении, и у меня не будет другого выбора, кроме как продолжить процесс разрешения спора. Bumm13 ( разговорное ) 21:49, 24 мая 2013 (UTC)

Для записей, это «обсуждение» продолжилось на лекции в Википедии: Redirect # Restoring_links_to_redirects

- Матиаспол ( разговор ) 01:04, 9 июля 2013 г. (UTC)

Пример кода Intel 8086 [ править ]

Спасибо за исправления кода для Intel 8086 . И да, код предназначен для иллюстрации различных типов кодов операций, доступных для ЦП, и не предназначен для использования в качестве наиболее оптимального кода ассемблера. Я мог бы написать более эффективный код, но результат не будет так легко понят новичкам и людям (вроде меня), которые просто хотят увидеть небольшой, довольно простой для понимания образец того, как выглядит код для ЦП. Я добавил примеры сокращенного кода в другие статьи ( 8008 , 6800 , 6502 , 8080 , Z80 ), где для правильности можно использовать другую пару глаз. Моя цель - в конечном итоге иметь пример короткого кода во всех основных исторических статьях о процессорах (например,IBM 360 , IBM 370 , PDP-8 , PDP-10 , PDP-11 , 4004 , 6809 , Z8000 , 80386 и т. Д.). - Loadmaster ( разговор ) 04:37, 5 июня 2013 (UTC)

Пожалуйста. Планируете ли вы использовать один и тот же пример для всех процессоров? Это могло бы помочь в перекрестном сравнении стилей кодирования для разных целевых процессоров, но не показало бы конкретных возможностей некоторых процессоров, если мы не будем использовать REP MOVSBи т. Д. В примере для 8086. Это может заставить людей думать о 8086 как о гораздо менее способный, чем есть на самом деле.

Хм, возможно, есть более подходящий пример задачи, чтобы показать разнообразие набора команд процессора. Возможно, проблема с простой сортировкой по массиву или списку? Или какая-то проблема с преобразованием чисел? Или проблема с извлечением потоковых данных? Конечно, он должен был быть коротким, если его следовало включить в статью.

Другой вопрос: разве код или комментарии не должны учитывать модификацию регистров CX, SI, DI и Flags?

Приветствую, Матиаспол ( разговор ) 10:59, 6 июня 2013 (UTC)

Я использую тот же memcpyпример для 8-битных процессоров ( 8008 , 6502 , 6800 , 8080 , Z80 ). У меня есть немного более сложный strtolowerпример для 16-битных процессоров (который пока есть только в статье 68000 ; я бы хотел добавить что-то подобное для IBM S / 360 , PDP-10 , PDP-11 , Z8000. , 80386 и др.). Другие примеры подпрограмм, которые могут быть поучительными:

• Сложение двух 8-значных упакованных десятичных значений;
• Суммирование всех элементов целочисленного (или с плавающей запятой) массива из n элементов ;
• 16-битное умножение (для 8-битных процессоров) и 32-битное или 64-битное умножение (для 16-битных и 32-битных процессоров);
• Удаление узла из двусвязного списка;

...и так далее. В идеале было бы наиболее поучительно показать полдюжины или около того кодов операций в подпрограмме, длина которой не превышает, скажем, 20 строк. Я не думаю, что читателей заинтересует код, который длиннее полстраницы или около того. Я также хотел бы иметь возможность показать фактические двоичные коды (большинство примеров, которые я написал, мне приходилось собирать вручную, что утомительно и подвержено ошибкам). Примеры не предназначены для использования в реальном производственном коде.

Я не хочу показывать слишком много сложных инструкций, если они действительно не типичны для данного процессора. Например, я сомневаюсь в использовании REPкодов операций для 8086 ; с одной стороны, они являются более эффективными инструкциями и поэтому, вероятно, будут использоваться в практических приложениях, но с другой стороны, их труднее понять случайным программистам / читателям. Также обратите внимание, что в статьях об архитектуре PDP-11 и PDP-8 дается гораздо более подробная разбивка форматов команд ЦП; такая штука была бы хороша для других процессоров. В статье PDP-8 также есть несколько очень маленьких примеров кодирования. - Loadmaster ( разговор ) 23:56, 6 июня 2013 г. (UTC)

Список людей Йельского университета [ править ]

Привет, Матиаспол, не знаешь ли ты, в какой раздел можно добавить Asoka Bandarage ? Лотье ( разговор ) 12:01, 19 июня 2013 (UTC)

Привет, Лотье. Я бы поместил ее в Список людей # профессоров и ученых Йельского университета или Список людей # религии Йельского университета . Привет. - Матиаспол ( разговор ) 12:11, 19 июня 2013 г. (UTC)

Раскладки клавиатуры [ править ]

Здравствуйте! Можете ли вы рассказать мне, какой у вас источник об итальянской раскладке клавиатуры? Я прожил в Италии большую часть своей жизни и никогда не видел ничего QZERTY (я также использовал старые механические пишущие машинки, просто для развлечения, и они были QWERTY). Единственное место, где я видел разные макеты, была лаборатория на факультете математики и информатики, где я учился, в которой использовались американские клавиатуры (которые, кстати, тоже QWERTY), которые позже были заменены обычными итальянскими клавиатурами QWERTY. Не могли бы вы показать мне свой источник? А недавно? Посмотрите на эту пишущую машинку итальянского производства. http://commons.wikimedia.org/wiki/File:Olivetti_Lettera_32_(2).jpg

LtWorf ( разговор ) 13:57, 27 июня 2013 (UTC)

Привет, лейтенант. Я пытался подчеркнуть, что в Италии используется более одной раскладки клавиатуры, как правильно показано на карте. Вот почему я вернулся к вам, когда вы заявили, что итальянцы используют только один макет.

Это было некоторое время назад, когда я был разработчиком драйверов клавиатуры и поэтому провел обширное исследование раскладки клавиатуры по всему миру. У меня все еще хранятся груды документов, но они сейчас не очень удобны (и на самом деле у меня нет времени искать их в ближайшее время - извините). Однако одним источником различных раскладок клавиатуры являются реестры раскладок клавиатуры в Microsoft и IBM. Они присвоили идентификаторы большинству макетов, которые они поддерживают или поддерживают в своем программном обеспечении. База знаний Microsoft идентифицирует ID 141 (IIRC, это был вариант QZERTY, но мне пришлось бы поискать его, чтобы быть уверенным) и ID 142 (определенно вариант QWERTY), мой старый пост в группе новостей ( [14]) также упоминает ID 146, который, как я обнаружил, поддерживается в какой-то версии DOS, я думаю (но мне бы пришлось поискать его, чтобы быть уверенным, это также могла быть OS / 2). В реестре раскладки клавиатуры IBM упоминается ID 142 (как указано, вариант QWERTY), ID 293 (другой вариант QWERTY) и ID 150G (вариант QWERTZ, используемый в некоторых районах Северной Италии).

Надеюсь, это поможет. Приветствую, Матиаспол ( разговор ) 09:28, 28 июня 2013 (UTC)

Устранение неоднозначности [ править ]

Привет, Матиаспол. Когда вы переместили Convertible на новый заголовок, а затем изменили старый заголовок на страницу с разрешением неоднозначности , вы, возможно, не знали о WP: FIXDABLINKS , в котором говорится:

Кодекс чести для создания страниц значений неоднозначности заключается в исправлении всех возникающих неверно направленных ссылок.

Перед перемещением статьи на квалифицированное имя (чтобы создать страницу значений неоднозначности на основе базового имени, переместить существующую страницу значений неоднозначности на это имя или перенаправить это имя на страницу значений неоднозначности), нажмите « Какие» ссылки здесь, чтобы найти все входящих ссылок. Восстановите все входящие ссылки, чтобы использовать новое название статьи.

Было бы большим подспорьем, если бы вы проверили другие статьи Википедии, содержащие ссылки на «Convertible», и исправили их, чтобы привести читателей к нужной статье. Спасибо. R'n'B ( зовите меня Расс) 09:57, 3 июля 2013 (UTC)

Конечно, Расс, я почти всегда так делаю. Однако в этом конкретном случае я не был готов вручную редактировать сотни статей (в частности, не в то время, которое я оставил вчера), и я сначала хотел немного конкретизировать новую страницу разрешения неоднозначности (что и произошло тем временем). Кроме того, просматривая длинный список, я обнаружил несколько случаев входящих перенаправлений, когда я не мог принять правильное решение, куда они должны указывать (я вообще не увлекаюсь автомобилями и вагонами). Тем временем я изменил некоторые из этих перенаправлений, чтобы обойти страницу с разрешением неоднозначности, но оставил другие, указывающие на нее.

Если мы составим список входящих ссылок, которые должны обходить страницу устранения неоднозначности и переходить непосредственно к Convertible (автомобиль) (чтобы охватить наибольшее количество затронутых ссылок), не кажется ли вам, что это будет идеальной задачей для бота: выполнить собственно правки?

Привет. - Матиаспол ( разговор ) 13:23, 3 июля 2013 г. (UTC)

Что ж, я начал исправлять ссылки вручную, но после изменения нескольких сотен из них другой редактор изменил «Конвертируемый», чтобы он стал основной темой, а другие значения были устранены в «Конвертируемом» (значения). Хотя я не думаю, что значение автомобиля является основным значением этого термина, это также приемлемое решение (поскольку оно позволяет избежать более одного альтернативного значения, упомянутого в основной статье). Поэтому я перестал конвертировать оставшиеся ссылки.

- Матиаспол ( разговор ) 01:04, 9 июля 2013 г. (UTC)

Системный менеджер изменить на системного администратора [ править ]

Здравствуй,

Это не значит, что я не согласен с перенаправлением System Manager на System Administrator, я не согласен с тем, что в верхней части страницы должна быть ссылка на «Datapac Multiuser DOS and System Manager». Это пустой раздел почти полностью несущественного программного обеспечения.

Если у нас это будет, почему бы не это:

http://en.wikipedia.org/wiki/IBM_Web-based_System_Manager

или это:

http://en.wikipedia.org/wiki/PureSystems

или это:

http://en.wikipedia.org/wiki/System_Manager_7#System_Manager

Нужна ли для "System Manager" страница значений? - Пользователь: StandaloneSA , 2013-07-03T16: 26: 42

Что ж, вы правы насчет Datapac System Manager, но не насчет многопользовательской DOS, хотя это уже давно.

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

Приветствую, Матиаспол ( разговор ) 15:46, 3 июля 2013 (UTC)

Отлично, я думаю, это действительно хорошо работает. Большое спасибо. Надеюсь, я не стал слишком нахальным. Я новичок в редактировании Википедии, поэтому не уверен в правильных протоколах.

Спасибо!

StandaloneSA ( обсуждение ) 15:58, 3 июля 2013 (UTC)

Спасибо за ваш отзыв. Рада что тебе понравилось. :-) - Матиаспол ( разговор ) 01:04, 9 июля 2013 (UTC)

Поддержка 64-битной версии (снова) [ править ]

Привет, Пол

Надеюсь, я не беспокою вас, но я хотел сообщить вам об одном из ваших правок в виртуальной машине DOS . Я частично отменил ваше редактирование (не все) и начал обсуждение на Talk: Virtual DOS machine § Поддержка 64-битной версии (снова), где вы можете обсудить или защитить свое редактирование и достичь консенсуса или компромисса, если хотите. Я должен сказать заранее, что мы очень ценим ваш дух сотрудничества.

Однако основная причина, по которой я позвонил вам, заключается в том, что я использовал Википедию: VisualEditor . Видите ли, у вас есть привычка обрабатывать ссылки, что не влияет на окончательный рендеринг. Я, конечно, не трачу свое время на такие вещи, но ваше время ваше. Теперь VisualEditor этого не уважает. Если кто-то изменит одну опечатку в статье или добавит пробел, VisualEditor сгладит ваши правки. Это примечание, предназначенное для того, чтобы вы были готовы не быть застигнутыми врасплох, если вы увидите, что редактирование разницы очень сильно.

С уважением,
Кодовое имя Лиза ( выступление ) 16:21, 3 июля 2013 г. (UTC)

Sockpuppets С. Ника Баруа [ править ]

Я открыл SPI в Википедии: расследование Sockpuppet / Mike willaims и перечислил различные sockpuppet, которые я заметил. Но вы также отслеживали и отклоняли его спам и, возможно, захотите добавить дополнительные сведения. Msnicki ( разговорное ) 20:23, 9 июля 2013 (UTC)

Спасибо, что открыли это дело. Я добавил в список еще один IP-адрес и учетную запись Commons, а также ссылку на недавнюю ветку обсуждения. - Матиаспол ( разговор ) 21:10, 9 июля 2013 г. (UTC)

Я видел это. Спасибо, это было очень полезно. Я был разочарован тем, что 119.18.148.3 также не был заблокирован - 7 июля было всего 2 дня назад и мне не кажется, что он устарел - но что-то мне подсказывает, что у нас будет еще одна причина, чтобы в ближайшее время запросить дополнительные блоки довольно. Мсницки ( разговор ) 21:19, 9 июля 2013 (UTC)

Да, такое же внутреннее чувство, к сожалению ... - Матиаспол ( разговор ) 21:23, 9 июля 2013 г. (UTC)

Присоединяйтесь к WikiProject Microsoft ! [ редактировать ]

Технические характеристики FAT [ править ]

Слушайте, я понимаю, вы потратили много времени на добавление всех этих кодов загрузочного сектора в статью о FAT . Кстати ... это слишком технически. Вы можете создать перенаправление технических спецификаций, если хотите заявить о себе для новой вики.

Главный редактор не зря оставил комментарий в вики.

Исправьте гребаную статью. Читается как дерьмо с лишними графиками загрузочных секторов и излишне подробной информацией. Это как поместить биографию Стиви Уандера в статью. В чем смысл?

Если вы действительно хотите конкретизировать технические данные, существуют платформы викии для ИТ-любителей -----------

например:

http://community.wikia.com/wiki/Hub:Technology

Гэри Килдалл [ править ]

Привет, я заметил, что вы отменили изменения / улучшения, которые я внес в статью, что потребовало от меня значительных усилий. Я думаю, что у меня должно быть более 10.000 статей (в нескольких проектах), но я никогда не испытывал такой ограниченности пространства в разделе справочной информации, как вы создали вокруг «отрывка из заголовка файла BDOS.PLM». Если эта иллюстрация настолько важна, можете ли вы переместить ее в статью и объяснить еще раз?

Также кажется, что вы спрятали в справочном разделе (см. Здесь ) три цитаты , которые довольно сложно читать. Есть своего рода стандарт для представления таких цитат; в основном в Викицитаторе (когда они доступны в Википедии, большую часть времени они перемещаются в Викицитатник).

- Mdd ( разговорное ) 18:09, 14 августа 2013 г. (UTC)

Привет, мдд. Ну, они никогда не были цитатамисам по себе мной, как и обычные ссылки, включая цитату из исходного источника с использованием параметра quote =. Хотя большинство ссылок идет без встроенных цитат, я чувствовал, что имеет смысл включить их сюда для исторической точности, учитывая, что источники о ранней истории CP / M очень редки, и хотя в рассказе Киллиана о том, что произошло, есть некоторые неточности, вместе взятые эти источники могут помочь дать определенные ответы на несколько вопросов о ранней истории CP / M. Я согласен с вами в отношении пробелов в заголовке файла BDOS.PLM, но я вообще не хотел вмешиваться в форматирование этого исторического документа. Это отрывок из исходного исходного кода одной из самых ранних версий CP / M, и он исторически важен, потому что это самый ранний сохранившийся документ, использующийОбозначения BIOS и BDOS , термины, используемые до сих пор . Я согласен с вами, что пустое пространство в разделе ссылок выглядит немного странно, но потом я подумал, что все будет в порядке, учитывая, что он правильно отформатирован в соответствии с правилами шаблона цитирования и не находится в статье body (где это может нарушить поток читателей), но только в разделе ссылок, который люди обычно просматривают, только если их интересуют дальнейшие подробности.

Я только отменил редактирование, в котором вы заменили эти ссылки на цитаты, потому что ваше переформатирование было, по-видимому, причиной того, что редактор IP, редактирующий статью после вас, распознал их как сомнительные и неподтвержденные утверждения, а не как точно полученные цитаты из исторических источников, которыми они . - Матиаспол ( разговор ) 20:58, 14 августа 2013 г. (UTC)

Спасибо Maththiaspaul. Причина, по которой я удалил его в первую очередь, заключалась в том, что я хотел добавить тег {{ref | 2}}, чтобы воссоздать справочный раздел в 2 столбца. С тем оригинальным текстом все получилось запутанным, и я не смог его почистить. Я только предполагаю, что в следующий раз опытный редактор, незнакомый с этим вопросом, столкнется с теми же проблемами. Или другие продолжают интересоваться этой иллюстрацией в справочном разделе. Пожалуйста, переместите его в статью или в аналогичную статью. Или, если это не так важно, переместите его на страницу обсуждения.

Что касается этих цитат (или просто текста из ссылок), я также добавил их в лемму Wikiquote Гэри Килдалла. Не стесняйтесь изменять эти цитаты или добавлять другие цитаты, если вам интересно. - Mdd ( разговорное ) 21:53, 14 августа 2013 г. (UTC)

Ошибочные заглавные буквы и орфографические ошибки [ править ]

Почему вы повторно добавили в EXIF категорию «от неправильного написания» ? Технически это неправильное использование заглавных букв, но правильное написание аббревиатуры (то есть оно содержит те же буквы в том же порядке, что и «Exif», но отличается только заглавные буквы). Или в Википедии существует соглашение, согласно которому аббревиатура, написанная с ошибкой заглавной буквы, считается неправильным написанием? Или я совсем что-то пропустил?

(Если вас смутило отсутствие слова «неверный» в шаблоне: перенаправляет на , поэтому я решил использовать последнее напрямую.) - SoledadKabocha ( обсуждение ) 00:14, 15 августа 2013 г. (UTC){{r from incorrect capitalization}}{{r from other capitalisation}}

Привет, СоледадКабоча. Кажется, у нас обоих были (и есть) одинаковые намерения в отношении EXIF, но мы выбрали разные пути, пытаясь достичь цели.

Добавление R из орфографической ошибки было моей попыткой пояснить, что EXIF ​​недействителен, потому что аббревиатура должна быть написана как Exif (за исключением случаев, когда окружающий текст также написан заглавными буквами). Некоторые люди не осведомлены о том факте, что аббревиатура формата файлов изображений Exchangeable - Exif, и они неправильно используют EXIF, когда добавляют ссылки на формат файлов изображений Exchangeable в других статьях. Я чувствовал, что R с другими заглавными буквами не был достаточно "сильным", учитывая, что он не отмечает форму как неправильную. Умные редакторы и боты могут использовать наличие R из шаблона орфографии (или в соответствующей категории) для полуавтоматического исправления таких ошибок, но они не могут этого сделать дляR с другой заглавной буквы . Согласно документации, R от неправильного написания может использоваться для орфографических ошибок и опечаток, и хотя неправильное использование заглавных букв обычно не является типографской ошибкой, я чувствовал, что он здесь достаточно хорошо вписывается.

Если бы EXIF ​​не использовался уже на нескольких страницах обсуждения, я думаю, что лучшим решением было бы просто удалить это конкретное перенаправление. Это удержит людей от использования неправильных заглавных букв в статьях (по крайней мере, когда они ссылаются на них), в то время как поле поиска без учета регистра все равно будет принимать любые заглавные буквы в оставшемся перенаправлении Exif.

Следующим лучшим решением, IMHO, было бы переключиться с R с других заглавных букв на R из неправильного использования заглавных букв (я не знал об этом конкретном, спасибо!) И, возможно, улучшить шаблон, чтобы он работал аналогично R из-за неправильного написания .

Приветствую, - Матиаспол ( разговор ) 08:32, 15 августа 2013 (UTC)

Вы, наверное, заметили, что я уже переключил его на R из-за неправильного написания заглавных букв ... но что вы имеете в виду под «возможно улучшить шаблон, чтобы он работал так же, как R из-за неправильного написания »? Оба уже относятся к категории «непечатные». - СоледадКабоча ( разговор ) 15:38, 15 августа 2013 г. (UTC)

Да, я это видел, и мне это нравится.

Я имел в виду изменить R с неправильным написанием заглавных букв, чтобы он добавлял соответствующие перенаправления в Category: Redirects также от орфографических ошибок (как это делает R от орфографических ошибок ). Хотя в строгом смысле ошибки с заглавными буквами сюда не относятся, я думаю, было бы нормально, если бы мы могли таким образом избежать создания Категории: перенаправления из неправильных заглавных букв, учитывая, что эта категория предназначена только для обслуживания.

- Матиаспол ( разговор ) 22:13, 15 августа 2013 г. (UTC)

Nitpicking [ править ]

Привет, Матиас

Я уже говорил вам однажды, но, похоже, мне нужно напомнить вам еще раз: инструменты, гаджеты и VisualEditor, такие как WikiEd, Twinkle, ProveIt !, и т. Д., Могут автоматически вносить изменения, такие как выравнивание цитат (удаление разрывов строк между шаблонами цитирования) и удаление подчеркивания. То, что вы здесь вернули , является одним из тех правок.

Я не против, если вы снова и снова будете возвращать такие незначительные правки; вы владелец своего времени, и я не осуждаю вас, если вы считаете, что такие правки не тратят его зря. На самом деле я это уважаю. Но тогда вы должны ожидать, что комментарии типа «Пожалуйста, пишите якоря так, как они определены, вместо ненужного изменения подчеркивания на пробелы или наоборот», не останутся незамеченными. Редакторы не всегда могут контролировать оптимизацию инструментов, и даже если бы они это сделали, они по своему усмотрению не могут им мешать. В конце концов, это не так.

С уважением,
Кодовое имя Лиза ( выступление ) 22:36, 31 августа 2013 г. (UTC)

Спасибо за подсказку, Лиза, но, к сожалению, я здесь с тобой не согласен. Хотя wikisyntax позволяет заменять символы подчеркивания и пробелы местами (чтобы обойти несколько случаев, когда один из этих символов должен быть заменен другим), это не означает, что мы должны заменять символы подчеркивания на пробелы или наоборот, и никакие такие изменения не одобряются. , На самом деле, наоборот. Мы должны использовать все, что используется в определении. В большинстве случаев это будут пробелы, но иногда есть причины, по которым использовались подчеркивания, и если да, то это также должно быть отражено в ссылках (если вы не столкнетесь с одним из немногих сценариев, в которых замена необходима).

Как я объяснял вам недавно, я обычно использую пробел в «читаемых» именах и подчеркивания в символических именах, подобных тем, о которых идет речь здесь, чтобы их было легче отличить от обычного текста. Я использую символические имена, когда они очень специфичны, и я намеренно не хочу, чтобы это имя когда-либо конфликтовало с обычным читаемым именем, которое может быть создано другим редактором в будущем, и я сознательно не использую пробелы в таких символических именах. Для этого у меня есть веские причины. Это предотвращает обертывание таких символов в редакторах, снижает вероятность того, что дополнительные пробелы будут случайно вставлены в имя символа в результате последующего переформатирования исходного кода, происходящего на странице (что в конечном итоге приведет к разрыву ссылки), и, прежде всего,Согласованность улучшает читаемость и значительно упрощает поиск шаблонов и поддержку этих символов во многих статьях.

Хотя вы абсолютно свободны игнорировать мои предложения и соглашения об именах и выбирать свой собственный стиль, вам все равно не следует менять подчеркивание на пробелы или наоборот, если нет причины, по которой пробелы здесь предпочтительнее, и вы делаете это во всех задействованных местах по порядку для обеспечения согласованности (однако в этом случае я бы использовал дефисы вместо подчеркивания). Хотя это, к счастью, ничего не сломает, и ссылки пока будут работать, внесение таких несоответствий все же мягко нарушит ремонтопригодность статей, и, таким образом, вы значительно усложните другим редакторам возможность вносить свой вклад. . Это ненужный песок в шестеренке. Следовательно, это нежелательно, если не считать неконструктивным, хотя, конечно, не предназначено как таковое. Я беру это,что вы не знали о том, что вы внесли эти изменения. Что ж, если ваши инструменты вносят изменения, не зависящие от (вашего) контроля, откажитесь от этих инструментов! Просто как тот. Если они меняют подчеркивание на пробелы в ссылках, несмотря на то, что они определены с использованием подчеркивания в целевом объекте и без вашего ведома, они содержат ошибки и должны быть исправлены. Отправьте отчет об ошибке. В конце концов, каждый несет ответственность за свои правки на основе полученного исходного кода вики, и не имеет значения, какие инструменты используются (я тоже использую свой набор инструментов, но я не использую их как оправдание).Отправьте отчет об ошибке. В конце концов, каждый несет ответственность за свои правки на основе полученного исходного кода вики, и не имеет значения, какие инструменты используются (я тоже использую свой набор инструментов, но я не использую их как оправдание).Отправьте отчет об ошибке. В конце концов, каждый несет ответственность за свои правки на основе полученного исходного кода вики, и не имеет значения, какие инструменты используются (я тоже использую свой набор инструментов, но я не использую их как оправдание).

КСТАТИ. Хотя есть много редакторов, редактирующих ссылки, так что они используют тот же стиль интервалов / подчеркивания, что и в целевой странице , за все эти годы вы единственный редактор, который, как я помню, менял ссылки, чтобы они выглядели иначе, чем на целевой странице, в отношении пространства. / подчеркивания.

Приветствую, Матиаспол ( разговор ) 05:30, 1 сентября 2013 (UTC)

( Комментарий от стороннего редактора ) Привет. Мне было любопытно, поэтому я проверил. Это изменение , кажется, вызвали изменения. Гаджет, вызвавший изменение, называется AutoEd, и я вижу, что он также внес множество других хороших изменений.

Теперь вы говорите «бросьте эти инструменты!» Это выход из строя. Если другие люди не хотят тратить свою жизнь на мелкие исправления, которые можно автоматизировать, вы не можете винить их, и я очень хорошо понимаю, если они не хотят тратить впустую выигранное время, придерживаясь произвольных соглашений, которые вы хотите обеспечить соблюдение.

И последнее, но не менее важное: если вы не видели, это не значит, что его не существовало. Это просто означает, что вы не видели. Многие инструменты, такие как Reflinks и WikEd, исправляют подчеркивание в ссылках. Командование флотом ( разговор ) 07:24, 1 сентября 2013 (UTC)

Привет, Флит. Спасибо за комментарий, но, к сожалению, я вижу, что моя позиция значительно неверно истолкована в вашем комментарии.

Это хорошо , что существуют инструменты для автоматизации исправления , где вещи должны быть исправлены. Однако в данном конкретном случае исправлять было нечего, и даже если бы это было так, определенно инструмент (или стоящий за ним редактор) не должен был вносить несоответствия , которых раньше не было (даже при сокращении объема до этой единственной статьи. только) - это просто не было улучшением. В то время как некоторые изменения Лизы были в порядке, некоторые другие правки также сомнительны, но это откроет банку червей, и я не хочу придираться - поэтому я просто вернул то, что вообще не нужно было менять в первую очередь, и что важно, чтобы на самом деле не тратить свое времяпри продолжении работы над статьей в качестве одного из основных авторов контента .

Если некоторые из этих инструментов вызывают непреднамеренные изменения как «побочный ущерб», как, по-видимому, произошло в этом случае (учитывая, что в статье не было ссылок с подчеркиванием, которые требовали исправления, и предполагая, что Лиза не намеревалась изменять символы подчеркивания в именах привязок на пробелов), нужно отрегулировать не все наше поведение при редактировании, а те инструменты, которые нужно исправить, чтобы они делали именно то, что они должны делать, и ничего больше. В конце концов, это всего лишь код. То, что делают программы, всегда находится под нашим контролем, а не наоборот. Иногда программы бывают несовершенными, обычно потому, что мы, как их создатели, что-то упустили в первую очередь или нам было лень реализовать это правильно. В этом случае у нас есть выбор: либо не использовать эти инструменты, пока они не будут исправлены (и если мы не сможем исправить их сами,хотя бы инициировать то, что необходимо, чтобы их исправили те, ктоможет исправить их), или овладеть им еще делать то , что мы хотим , чтобы они делали , несмотря на свои недостатки. Однако просто игнорировать их ошибки или даже использовать их как оправдание вряд ли приемлемо. Это сделало бы нас рабами наших собственных творений. И «экономия времени» на ненужные изменения за счет траты времени других редакторов также нежелательна, однако мы все знаем, что это иногда случается даже из лучших побуждений, и поэтому я могу терпеть это до тех пор, пока это происходит спорадически и непреднамеренно. Как и в этом случае, я обычно не делаю из этого проблемы, а просто исправляю ее.

То же, что и с ботами: либо они делают то, что должны делать, либо их нужно останавливать и исправлять. Ответственность за редактирование всегда лежит на человеке, использующем инструмент или запускающем бота, потому что у него / нее всегда есть выбор не использовать инструмент, если он не используется или не может быть освоен. Мы никогда не отказываемся от ответственности перед инструментами.

Вы написали: «Если другие люди не хотят бросать свою жизнь на мелкие исправления, которые можно автоматизировать, вы не можете их винить»

Чтобы уточнить факты, проблема здесь не у меня, а у Лизы. Очевидно, ей не понравилась моя редакция, иначе она бы не жаловалась на это на моей странице обсуждения. Для меня это не было бы проблемой, потому что никогда не было проблем с автоматическими инструментами, заменяющими символы подчеркивания на пробелы, где это не было предназначено. Если бы это была обычная проблема, я бы никогда не принял эту конвенцию много лет назад, но пока это было совсем не так. Итак, либо у нас было недавнее изменение руководства, требующее пробелов в якорных ссылках даже там, где в цели используются подчеркивания, либо все еще нет проблемы. Как я уже сказал, я с радостью могу настроить использование дефисов или других символов, если подчеркивание вызовет какие-либо проблемы, но до сих пор проблем не было.

Вы написали: «И я очень хорошо понимаю, если они не хотят тратить впустую выигранное время, придерживаясь произвольных соглашений, которые вы хотите соблюдать».

Хм, это довольно натянутое отражение моей позиции. Меня не волнует, выберут ли другие редакторы «мое» соглашение или нет, и я, конечно, не навязываю им какие-либо произвольные соглашения, но при добавлении содержимого имена привязок должны были быть выбраны как-то, и просто так получилось, что я выбирали символьные имена без пробелов (причины см. выше). Если у кого-то есть концепция получше, отлично! Они могут использовать то, что хотят, и я также открыт для предложений по применению моего стиля. Все, что я прошу, - это не вносить несоответствий, особенно когда вы выполняете только быстрое редактирование "проезжая мимо".

Это как раз наоборот, если бы другие редакторы внезапно начали вводить те же несоответствия и «навязывать» пробелы в якорях повсюду, где я раньше использовал подчеркивания, это действительно было бы огромной тратой моего времени, поскольку это было бы значительно усложняют ведение статей с помощью моих инструментов. Моим решением было бы вообще избегать пробелов и подчеркиваний в символических якорях (на самом деле, я все равно могу это сделать). Однако пока для этого просто не было причин, так как всем остальным удавалось не вносить таких несоответствий - и другие редакторы также использовали всевозможные инструменты.

Привет, Матиаспол ( разговор ) 15:49, 1 сентября 2013 г. (UTC)

Здравствуй. Вау, это один длинный ответ; Мне повезло, это не для меня. Бедное командование флота, кто должен это прочитать. С уважением, Кодовое имя Лиза ( выступление ) 09:34, 3 сентября 2013 г. (UTC)

Здравствуй. Нет, я не собираюсь отказываться от гаджета. Условные обозначения и инструменты должны служить цели; то, что вы спрашиваете, - это наоборот. Даже если бы то, о чем вы спрашивали, было правилом, я мог бы его проигнорировать . С уважением, Кодовое имя Лиза ( выступление ) 13:10, 1 сентября 2013 г. (UTC)

Барнстар для вас! [ редактировать ]

Оспаривается быстрое удаление: Serial ata [ править ]

Привет, Матиаспол, и спасибо за патрулирование новых страниц! Я просто сообщаю вам, что я оспаривал быстрое удаление Serial ata , страницы, которую вы пометили для быстрого удаления, из-за следующей проблемы: это не будет бесспорным удалением. Редиректы с других заглавных букв являются обычным явлением. Более того, эту страницу посещают довольно часто ( http://stats.grok.se/en/latest30/Serial_ata ), что означает, что люди фактически используют это перенаправление для навигации. Вы можете ознакомиться с критериями быстрого удаления, прежде чем добавлять теги на другие страницы. Спасибо.

Подпись съела из-за ошибки BracketBot. Простите за это. Вышеупомянутое сообщение было первоначально предоставлено сайтом Cymru.lass . Хуон ( разговор ) 00:57, 15 сентября 2013 (UTC)

Caldera (компания) interwiki [ править ]

Привет, я удалил ikw, потому что Caldera (Unternehmen) на dewiki - это только страница перенаправления, поэтому она не может существовать в Викиданных. Регс, доктор ( разговор ) 00:09, 23 сентября 2013 г. (UTC)

Привет, я уже это предположил. ;-)

Однако перенаправления являются допустимыми целями между вики-ссылками (и этот пример прекрасно иллюстрирует, почему иногда это необходимо). Синтаксис для локальных меж-вики-ссылок продолжает поддерживаться после запуска викиданных по одной из причин, заявленной, что он может помочь в решении проблем, которые сложно настроить с помощью викиданных. Поэтому я не думаю, что нам следует удалять полностью функциональные ссылки на нужные страницы только потому, что они не используют викиданные. Было достаточно сложно разобраться в полном беспорядке в английском WP, смешавшем разные компании Caldera. Я могу сделать это также в немецком WP когда-нибудь в будущем (если никто другой не сделает этого), однако пока я только установил меж-вики-ссылки, так что, по крайней мере, есть инфраструктура и правильные темы. связаны между собой, чтобы кто-то мог их использовать.

КСТАТИ. В прошлом мне удавалось устанавливать ссылки на перенаправления с использованием викиданных, но это несколько сложно, и ИМО просто не стоит дополнительной работы и хлопот, пока все работает нормально без них.

Приветствую, Матиаспол ( разговор ) 00:38, 23 сентября 2013 (UTC)

Посмотрев на страницу в польском WP, она, к сожалению, также смешивает различные компании Caldera. Однако мой польский слишком плох, чтобы там исправлять факты. Итак, если бы вы могли что-то с этим сделать (используя английскую страницу в качестве ссылки, которая теперь правильно различает компании), это было бы очень признательно ... ;-) - Матиаспол ( разговор ) 00:55, 23 сентября 2013 г. (УНИВЕРСАЛЬНОЕ ГЛОБАЛЬНОЕ ВРЕМЯ)

Это правда, у нас с этим беспорядок на plwiki. Я видел ваше сообщение в обсуждении , постараюсь поправить эту статью. Докторант ( доклад ) 13:30, 25 сентября 2013 г. (UTC)

Код AARD [ править ]

Спасибо за чтение содержимого, которое я удалил из кода AARD после добавления соответствующей ссылки. Очень признателен! - Ямла ( разговор ) 13:49, 25 сентября 2013 г. (UTC)

R из Unicode [ править ]

Прошла неделя. Я планирую вернуться ваши реверсии из моих правок в переадресовывает как NEC μPD96050 . Хорошо? Горобай ( разговор ) 22:38, 17 ноября 2013 (UTC)

Ответили на странице пользователя. - Матиаспол ( разговор ) 21:01, 9 февраля 2014 г. (UTC)

MS-DOS на арабском языке внесена в список перенаправлений для обсуждения [ править ]

Редактор попросил обсудить проблему перенаправления арабского MS-DOS . Поскольку вы имели какое-то отношение к перенаправлению MS-DOS на арабский язык , вы можете принять участие в обсуждении перенаправления (если вы еще этого не сделали). � ( разговор ) 17:44, 22 декабря 2013 (UTC)

Проблема решена добавлением небольшого абзаца на арабском, иврите и других специальных версиях DOS. На самом деле, эти версии достаточно отличаются (от западных выпусков DOS), чтобы заслуживать более подробного обсуждения, но у меня сейчас нет на это времени. Будем надеяться, что другие воспользуются этим в качестве старта. - Матиаспол ( разговор ) 21:01, 9 февраля 2014 г. (UTC)

Сироты [ править ]

Вы восстановили неразрывные пробелы в таблице размещения файлов, утверждая, что это решает проблему сиротского набора (набор) . Сироты связаны с разрывами страниц. В сети нет разрывов страниц. То, что вы, по-видимому, пытаетесь решить, - это строки из одного слова в конце абзаца. Я не знаю никаких эстетических проблем с ними. Если есть проблема, она будет существовать для всех статей и должна быть решена как техническая проблема с системой MediaWiki, возможно, в Википедии: Village_pump_ (технический) . ~ KvnG 14:32, 5 февраля 2014 г. (UTC)

На самом деле существует три типа сирот: те, которые связаны с разрывами страниц, те, которые связаны с разрывами столбцов, и те, у кого разрывы строк в конце абзаца (точные определения, похоже, немного различаются между странами, и они иногда имеют довольно разные имена в других странах). языков, но основная идея в основном та же). Лучше всего в книжном оформлении избегать всех трех типов (но особенно первых двух), либо адаптируя интервалы, либо перефразировав соответствующий раздел, меры, которые не работают для веб-страниц по очевидным причинам. Один старый способ избежать третьего типа на веб-страницах - это вставить&nbsp; между двумя последними словами абзаца. Между тем, эту проблему также можно решить с помощью CSS, но поддержка CSS отличается в разных браузерах, а старые браузеры не поддерживают их вообще, поэтому &nbsp; метод более универсален - его поддерживают даже устаревшие браузеры. В любом случае это лишь незначительное раздражение. - Матиаспол ( разговор ) 21:01, 9 февраля 2014 г. (UTC)

Это интересно, и я ценю объяснение, но я не думаю, что желательно или возможно вручную вставлять неразрывные пробелы в конце каждого абзаца. Если вы считаете, что это проблема, вы должны отстаивать ее общее решение. ~ KvnG 16:23, 13 февраля 2014 г. (UTC)

Хотя я действительно думаю, что общее решение будет оценено, и я использую его в своих публикациях, для меня не будет серьезной проблемой, если другие не соблюдают традиционные типографские правила. Для меня было бы слишком много времени пытаться начать что-то по этому поводу здесь. - Матиаспол ( разговор ) 15:36, 21 апреля 2014 г. (UTC)

.app внесен в список редиректов для обсуждения [ править ]

Редактор попросил обсудить проблему перенаправления .app . Поскольку вы принимали участие в перенаправлении .app , вы можете принять участие в обсуждении перенаправления, если вы еще этого не сделали. Резонановы ( обсуждение • вклад ) 10:58, 10 марта 2014 (UTC)

Альфа 4/5/7 ходов [ править ]

Я сделал все возможное, чтобы отменить эти ваши правки, чтобы создать огромные страницы с неоднозначностью, касающиеся альтернативных имен для группы камер, которые не являются тем именем, под которым они наиболее известны на английском языке. Нет смысла создавать страницы значений неоднозначности только для того, чтобы заполнить их до краев недопустимыми перенаправлениями. - Рюлонг (琉 竜) 12:09, 12 апреля 2014 г. (UTC)

Для альтернативных имен, подобных тому, что вы предлагаете, вы должны использовать {{ hatnote }} вместо того, чтобы делать миллиард перенаправлений на одну и ту же страницу. - Рюлонг (琉 竜) 12:29, 12 апреля 2014 г. (UTC)

Я создал страницы разрешения неоднозначности для Alpha 5 и Alpha 7, поскольку под этими названиями существует более трех тем без основной темы, а страницы устранения неоднозначности - наш устоявшийся способ справиться с этим сценарием в соответствии с нашим руководством по редактированию WP: DISAMB .

Если вы имеете в виду камеры Minolta Maxxum, боюсь, что, за исключением США, они гораздо более известны под названиями Dynax и Alpha (на самом деле, вся система во всем мире называется системой A-mount. с 1985 года - угадайте, что означает буква А?). Википедия - международный проект, американские имена не более актуальны, чем те, которые используются в других частях мира. Владелец Minolta Alpha 7 может не знать о том, что камера была доступна под маркой Minolta Maxxum 7 в США. Читатель может разумно ожидать, что он будет направлен к соответствующему содержанию, если он / она наберет Alpha 7. Направление читателя к соответствующей статье является самой целью перенаправлений и страниц устранения неоднозначности.

Более того, под этим названием Sony Alpha 7 продается в США (как и везде).

Итак, у нас есть три или более темы под одним и тем же названием без основной темы. Согласно WP: DISAMB, правильный способ справиться с ситуацией - создать страницу разрешения неоднозначности под этим самым именем для WP: PRIMARYTOPIC и WP: 2DABS .

Сноски обычно используются только до тех пор, пока есть только две темы с одним и тем же именем, которые необходимо различать, и только если одна из них является основной. В этом случае, однако, даже если мы консервативно подсчитываем, у нас есть три записи под Alpha 5 ( Alpha 5 (Minolta) , Alpha 5 Digital и Alpha 5 (Power Rangers) - и еще больше появятся в ближайшем будущем) и семь или более записей в рамках Alpha 7 ( Alpha 7 (Minolta) , Alpha 7 Limited , Alpha 7 Digital , Sony Alpha 7 , Sony Alpha 7R , Sony Alpha 7S , Alpha 7 (Power Rangers) ).

Ясный довод в пользу страницы с разрешением неоднозначности и полностью подкреплен нашими рекомендациями. Вы не должны были возвращать меня, но выразили свои опасения на странице обсуждения статьи. - Матиаспол ( разговор ) 13:40, 12 апреля 2014 г. (UTC)

Создание набора перенаправлений с альтернативных имен этих камер не оправдывает вашего поведения. Если лучше, то это материал для шляп. Не устранение неоднозначности страничного материала. Вымышленный персонаж по-прежнему остается главной темой в этом случае, потому что статьи о камерах не относятся к «Alpha 5 (Minolta)» или «Alpha 5 Digital». Это всего лишь два перенаправления на другие модели камер, которые иногда называют этими именами, но их нет в английской Википедии и нет в местах, где говорят по-английски, где может возникнуть такая путаница. Кроме того, камера «Alpha 7» перенаправляет просто указатель на те же 3 страницы. То, что вы можете создавать эти перенаправления, не означает, что они полезны. Просто все это выглядит как какая-то ненужная одержимость этими камерами и их альтернативными названиями.Я вижу, что несколько перенаправлений, которые вы сделали, были отправлены в RFD как ненадлежащие.Рюлонг (琉 竜) 21:39, 12 апреля 2014 (UTC)

Обсуждение продолжилось и закончилось в этой ветке:

Обсуждение: Альфа 5 (Могучие Рейнджеры) # Запрошенный ход

- Матиаспол ( разговор ) 15:36, 21 апреля 2014 г. (UTC)

Перенаправления [ править ]

Здравствуй,

Признаюсь в двух вещах, друг мой: я стар и технически не самый умный человек. Это означает, что я помню далекое прошлое, когда поле поиска не было таким удобным с разными заглавными буквами. Это также означает, что я склонен к консервативному подходу к удалению перенаправлений, потому что они «дешевые» и, как правило, их существование приносит больше пользы, чем вреда для навигации читателя (конечно, при условии, что они точны и непрерывны. Я следую книге: я смотрю, соответствует ли причина удаления руководящим принципам . Я также рассматриваю, действительно ли причина удаления не рекомендуется руководящими принципами.. В этом случае, хотя ваш запрос (как вы сейчас объяснили) звучит нормально, я не вижу, чтобы ваше обоснование поддерживалось в руководстве. Я действительно вижу, что вашему обоснованию могут противоречить пункты 1, 2 и 5 «причин не удалять перенаправления».

Позвольте мне прояснить: у меня действительно нет страстного мнения по этому поводу. Вы вполне можете быть правы. Однако, учитывая мое чтение руководящих принципов, я все еще не думаю, что это случаи быстрого удаления . Боюсь, вам придется перечислить их в RfD, где несколько экспертов могут изучить проблему. Мне правда очень жаль; Я всегда чувствую себя глупо, обсуждая такие мелочи, как если бы они были серьезными. Тем не менее, согласно букве руководства, эти перенаправления кажутся мне скорее полезными, чем вредными. С наилучшими пожеланиями, Ксолоз ( разговор ) 16:23, 20 апреля 2014 (UTC)

Происхождение этой темы: Обсуждение: Xoloz # Перенаправление как поисковые термины

Я понимаю и ценю вашу точку зрения, Ксолоз. Я довольно консервативен в удалении вещей, если это не очевидный мусор. Тем не менее, я также стараюсь избегать бюрократии там, где это возможно и (на мой взгляд) не вредит (потому что это требует времени, которое в противном случае лучше было бы потратить на улучшение статей). Не видя применения пунктов 1 и 5, а пункта 2 лишь частично по слову, но не по духу, я выдвинул перенаправления для обсуждения сейчас. Меня не очень волнует результат, так как я сделал все возможное, чтобы убрать (и уже потратил на это слишком много времени). Приветствую, Матиаспол ( разговор ) 15:36, 21 апреля 2014 (UTC)

Что касается вашего перемещения содержимого Alpha Five в Alpha 5 [ править ]

Я хочу сообщить вам, что я отменил ваш перенос содержимого Alpha Five с Alpha 5 на Alpha 5 . Причина, по которой я сделал это, заключается в том, что нельзя выполнять операции вырезания и вставки: это нарушает атрибуцию истории редактирования на страницах, поскольку история редактирования будет на неправильной странице. Пожалуйста, см. WP: CUTPASTE для получения более подробной информации. Если вы хотите переместить страницу в новое название, лучше всего запросить перемещение WP: RMTR (если кто-то не возражает) Steel1943 ( обсуждение ) 23:20, 20 апреля 2014 г. (UTC)

Привет и спасибо за указатель! Мне известно о WP: CUTPASTE, но почему-то я подумал, что ни на одной из этих страниц никогда не было значительного содержимого и истории редактирования, так что ничего не пропало бы из-за свопа, и я хотел избежать бюрократических накладных расходов для всех нас (уже слишком много времени потрачено на этот тривиальный вопрос, если вы спросите меня). Но, перепроверив это сейчас, у Alpha 7 действительно есть соответствующая история редактирования, так что действительно имеет смысл делать это должным образом. Привет. - Матиаспол ( разговор ) 23:51, 20 апреля 2014 г. (UTC)

На самом деле у Alpha 7 есть соответствующая история редактирования, а у Alpha 5 - нет. ;-)

В любом случае я пошел по предложенному вами маршруту, и страница была перемещена без проблем. Что касается сохранения историй редактирования, то в таких не столь важных случаях, как этот, я нахожу результирующую конструкцию с подстраницей Alpha 5 / версии 2 значительно более причудливой, чем то, что могло бы быть результатом простой замены содержимого и предоставления надлежащих сводок редактирования, указывающих на это ( в конце концов, согласно нашим руководящим принципам, резюме редактирования достаточно, чтобы указать происхождение, также в реальных случаях слияния статей , до тех пор, пока исходная страница не удалена, поэтому этого должно быть достаточно и для страницы разрешения неоднозначности с только тривиальной историей редактирования) .

Я просто надеюсь, что теперь все довольны новой организацией и что даже Рюлонг научится ценить ее. - Матиаспол ( разговор ) 15:36, 21 апреля 2014 г. (UTC)

Перенаправления для Alpha 5 перечислены в разделе Перенаправления для обсуждения [ править ]

Редактор попросил обсудить перенаправления, которые вы создали для Alpha 5 . Пожалуйста, примите участие в обсуждении перенаправления, если вы еще этого не сделали. Steel1943 ( разговор ) 15:36, 22 апреля 2014 (UTC)

Обсуждение RfD закрыто как Keep . - Матиаспол ( разговор ) 22:26, ​​1 мая 2014 г. (UTC)

Изменения в блоке управления файлами [ править ]

Когда разрабатывалась DOS 2, попытки «поддерживать несколько процессов или пользователей, использовать файловые системы, отличные от FAT, или обмениваться файлами по сети» были не более чем тремя годами позже. Эти функции не были включены в DOS 2, и я не знаю, было ли когда-либо намерение их включать. Устаревание FCB не было непосредственным прямым и необходимым следствием добавления подкаталогов, но они действительно пошли вместе, поскольку использование FCB позволяет вам получить доступ только к файлам в текущем каталоге по умолчанию на каждом диске. FCB не могли быть удобной и полезной частью общего набора системных вызовов для работы с файлами в системе иерархически вложенных каталогов без некоторой радикальной переформулировки ... AnonMoos ( обсуждение ) 20:34, 12 мая 2014 г. (UTC)

Приятно, что вы нашли источник, но все же довольно странно, что вы даете объяснение с точки зрения того, что было еще далеко, когда кодировалась DOS 2.0, при этом полностью игнорируя то, что фактически реализовывалось, когда DOS 2.0 была кодируется (т.е. иерархическая файловая система). AnonMoos ( разговор ) 23:58, 4 июня 2014 (UTC)

У вас новое сообщение! [ редактировать ]

Привет, Матиаспол. Пожалуйста, проверьте свою электронную почту; У вас новое сообщение!
Сообщение добавлено 17:56, 14 мая 2014 г. (UTC). С момента отправки электронного письма может пройти несколько минут, прежде чем оно появится в вашем почтовом ящике. Вы можете удалить это уведомление в любое время, удалив шаблон {{ You got mail }} или {{ ygm }}.

Никкимария ( разговор ) 17:56, 14 мая 2014 (UTC)

Re: Сортируемые таблицы и ключи сортировки [ править ]

Пинг. User_talk: C._A._Russell # Sortable_tables_and_sort_keys -  К.А. Рассел  ( выступление ) 22:10, 19 июня 2014 г. (UTC)

RfC заархивирован [ править ]

Я удивлен, учитывая вашу общую позицию о том, что разработка статьи должна идти медленно, с широким обсуждением, что вы заархивировали открытый RfC по организации таблицы размещения файлов без объяснения причин. Это потому, что вы ВЛАДЕЕТ статьей, или это ошибка. ~ KvnG 14:22, 1 июля 2014 г. (UTC)

Перенаправление консоли [ править ]

В разделе «Сравнение командных оболочек», «Общие характеристики» вы должны объяснить, что такое перенаправление консоли . Концепция консоли в Unix расплывчата, и оболочка обычно не запускается в консоли, поэтому этот столбец не имеет смысла, если он не означает что-то еще. Кстати, для bash сказано «Да», но на странице руководства bash даже нет слова «консоль». Винсент Лефевр ( разговор ) 23:19, 15 июля 2014 (UTC)

Secure Digital bis [ править ]

Я отредактировал вас по грамматике. После этого Анон отредактировал вас, чтобы попросить цитировать. Он изменил ваш текст и, возможно, ваше значение, но я думаю, что его точка зрения верна, что в вашем резюме текущего состояния устройств с поддержкой SDXC можно использовать ссылку. Spike-from-NH ( разговор ) 20:28, 23 июля 2014 (UTC)

Разъяснение к статье о колесе прокрутки [ править ]

Привет, не могли бы вы пояснить, почему вы внесли это изменение ? Колесо прокрутки на мыши не связано с клавишей блокировки прокрутки клавиатуры AFAIK, что гарантирует наличие ссылки там? DraugTheWhopper ( разговор ) 19:11, 2 августа 2014 (UTC)

Здравствуй. В зависимости от операционной системы, конфигурации и используемых приложений есть (или, по крайней мере, может быть) сходство между включением Scrollock или переключением третьей кнопки или колесика мыши (которая является частью колеса прокрутки). Следующие отрывки из статьи должны дать ключ к разгадке, но если вы не можете воспроизвести поведение в своей среде, аналогия может быть не сразу очевидна.

«В исходном дизайне Scroll Lock предназначался для изменения поведения клавиш со стрелками. Когда режим Scroll Lock был включен, клавиши со стрелками прокручивали содержимое текстового окна вместо перемещения курсора. В этом случае Scroll Lock - это клавиша переключения блокировки, такая как Num Lock или Caps Lock, состояние которых сохраняется после отпускания клавиши. [...]

В большинстве сред GUI игнорируется Scroll Lock, что означает, что прокрутка должна выполняться с помощью мыши с использованием таких средств, как полосы прокрутки или колеса прокрутки. Часто средняя кнопка мыши или кнопка с колесиком мыши работают как переключатель, определяющий, будут ли движения мыши перемещать курсор мыши или прокручивать содержимое в окне прокрутки ».

Надеюсь, это поможет. Привет. - Матиаспол ( разговор ) 20:12, 2 августа 2014 г. (UTC)

Сводка ваших изменений в командной строке [ править ]

Пожалуйста, не делайте необоснованных утверждений в отношении других пользователей Википедии, как вы это сделали в своей сводке редактирования в командной строке . Я, например, поддерживаю изменение User: Codename Lisa (хотя я однажды отменил его из-за очень неуместной сводки редактирования, оставленной этим пользователем). Dogmaticeclectic ( разговор ) 21:10, 2 августа 2014 (UTC)

Я наблюдаю два отдельных обсуждения: одно между Codename Lisa и Jenks24 и другое между Dogmaticeclectic и EdJohnston. По сути, Codename Lisa и Dogmaticeclectic завершили все три этапа WP: BRD, и их возврат сохранился. Единственное, что осталось, - это ваши четыре возврата, один с вашей учетной записью и три с вашими IP-адресами. (О, да, мы знаем, что они ваши.) Вы вовлечены в конфликт редактирования и ни разу не общались с Codename Lisa или Dogmaticeclectic; вместо этого вы использовали личные нападки против одного из них.

Эта вражда между вами и CL длилась достаточно долго. Пора вам двоим загладить свою вину, пока не поздно.

Командование флотом ( разговор ) 04:57, 3 августа 2014 (UTC)

КОПИРОВАТЬ (команда), указанная в Перенаправлениях для обсуждения [ править ]

Редактор попросил обсудить проблему перенаправления COPY (команда) . Поскольку вы принимали участие в перенаправлении COPY (команда) , вы можете принять участие в обсуждении перенаправления, если вы еще этого не сделали. Ойярбепси ( разговор ) 03:37, 6 августа 2014 (UTC)

• Просто чтобы вы знали, я не хочу удалять его, но я думаю, что он может быть нацелен на более релевантную статью. Ойярбепси ( разговор ) 03:44, 6 августа 2014 (UTC)

Предлагаемое исключение из параметра замены [ править ]

Привет, Матиаспол. Я хотел сообщить вам, что предлагаю удалить начатую вами статью « Параметр замены» , потому что я не думаю, что она соответствует нашим критериям для включения. Если вы не хотите, чтобы статья удалялась:

1. редактировать страницу
2. удалите текст, который выглядит следующим образом: {{предлагаемое удаление / датировано ...}}
3. сохранить страницу

Кроме того, не забудьте объяснить, почему, по вашему мнению, статью следует оставить в сводке редактирования или на странице обсуждения статьи . Если вы этого не сделаете, он все равно может быть удален позже.

Вы можете оставить заметку на моей странице обсуждения, если у вас есть вопросы. Стив Люкс младший ( разговор ) 19:57, 7 августа 2014 г. (UTC)

MOS: WEBADDR [ править ]

Здравствуй.

Вы пытаетесь заставить меня убить себя, утомляя меня от чтения? (; Нет причин повторять одно и то же предложение три раза, и совершенно необходимо не писать технические детали, которые редактору не нужно знать для редактирования.

Теперь есть части вашего редактирования, которые прямо противоречат общепринятой практике. Я и многие другие (см. Выше, вашу собственную страницу обсуждения) несколько раз говорили вам, что Википедии все равно, что делают другие; следовательно, принятие того, что делают другие, требует консенсуса всего сообщества. Пожалуйста, отведите их на страницу обсуждения. Кстати, похоже, что небольшая проблема с DNS-адресом FreeDOS настолько сильно потрясла вас, что вы резко меняете MoS! Вы же знаете, что ответ на это - «возьми себя в руки, чувак!», Не так ли?

С уважением,
Кодовое имя Лиза ( выступление ) 16:31, 10 августа 2014 (UTC)

Параметр замены указан в разделе "Перенаправления" для обсуждения [ править ]

Редактор попросил обсудить вопрос о параметре замены перенаправления . Поскольку вы принимали участие в перенаправлении параметра Replacement , вы можете принять участие в обсуждении перенаправления, если вы еще этого не сделали. - Keφr 16:25, 11 августа 2014 г. (UTC)

ANI [ править ]

В настоящее время в Википедии: Доска объявлений для администраторов / Инциденты обсуждается проблема, с которой вы могли быть связаны. Тема - Персональные атаки со стороны пользователя: Matthiaspaul . Спасибо. Кодовое имя Лиза ( разговор ) 21:41, 14 августа 2014 (UTC)

О, смотрите, вы уже ANI'd! Итак, вы можете частично не обращать внимания на мое сообщение ниже. Командование флотом ( разговор ) 09:51, 15 августа 2014 (UTC)

MOS: CLI [ править ]

Я видел ваш откат в MOS: CLI, и вот ваше резюме редактирования:

Отмена жирного изменения, по которому нет единого мнения

В этом есть две лжи: утверждение, что это жирный шрифт, и утверждение, что по нему нет единого мнения. Я закончил с твоей ложью. Итак, получите следующее: если вы продолжите этот обман, я передам дело в WP: AN3 , я произведу как обсуждение в Talk: Cmd.exe, в котором установлено это утверждение, так и предложение в MOS: CLI, в котором указано точное то же самое.

О, и спасибо за то, что вы дали мне должное за мою «яростную попытку принудительно использовать строчные буквы в статьях» [ sic ]. Только я не понимаю: какого черта Кодовое имя Лиза делит кредит. Могу я остаться вами, если бы я начал обсуждение переезда? Это я достиг консенсуса, и именно я буду следить за тем, чтобы каждая статья о вычислительной технике с заголовком в верхнем регистре была перемещена или удалена? Кодовое имя Лиза - прекрасное существо, но она даже не стала бы запускать запрос на перемещение, как это было в CHKDSK. Редакторы, подобные ей, слишком запутаны своими собственными убеждениями о том, что нужно вести себя хорошо. В общем, вы кусаете не того новичка . Командование флотом ( разговор ) 09:49, 15 августа 2014 (UTC)

DOS 30 внесен в список редиректов для обсуждения [ править ]

Редактор попросил обсудить проблему перенаправления DOS 30 . Поскольку вы имели какое-то отношение к перенаправлению DOS 30 , вы можете принять участие в обсуждении перенаправления, если вы еще этого не сделали. - The ChampionMan 1234, 10:22, 31 августа 2014 г. (UTC)

Выдвижение DOS 0 на исключение [ править ]

Обсуждается вопрос о том, подходит ли статья DOS 0 для включения в Википедию в соответствии с политиками и руководящими принципами Википедии или ее следует удалить .

Статья будет обсуждаться в Википедии: Статьи для удаления / DOS 0 до тех пор, пока не будет достигнут консенсус, и любой желающий может принять участие в обсуждении. Номинация объяснит политику и рекомендации, которые вызывают озабоченность. Обсуждение сосредоточено на высококачественных доказательствах, а также на наших правилах и рекомендациях.

Пользователи могут редактировать статью во время обсуждения, в том числе для улучшения статьи, чтобы устранить проблемы, поднятые в ходе обсуждения. Однако не удаляйте уведомление об удалении статьи в верхней части статьи. - Keφr 10:44, 2 сентября 2014 г. (UTC)

SmartShot Alpha против ILCE [ править ]

Я думаю, что приоритет в английской Википедии отдается английскому пресс-релизу. С уважением, Самсара  ( FA  •  FP ) 17:46, 6 сентября 2014 г. (UTC)

Разделитель DOS [ править ]

Не могли бы вы найти подходящий способ включить эту информацию. Это полезно. Я не добавлял его для здоровья. -G ( разговор ) 03:09, 27 сентября 2014 (UTC)

Привет, Грегори. Мне жаль слышать о вашем здоровье и надеюсь, что вы скоро поправитесь. Что касается вашего запроса, вы говорите о своем 2014-05-08T19: 33: 11 редактировании списка команд DOS, которые я вернул, или о какой-то новой информации, которую нужно добавить в статью? Старые правки к этой статье в настоящее время заблокированы, так как Пользователь: Asmpgmrнекоторое время назад добавил в него много материалов, защищенных авторским правом, поэтому я не могу найти то, что вы написали в мае. Но из истории редактирования я понимаю, что вы добавили некоторую информацию, относящуюся к Windows, хотя эта статья посвящена только командам DOS, и, следовательно, эта информация не относилась к ней (и, что более важно, это сбило бы людей с толку в контексте этой статьи, поскольку они Предположим, это связано с DOS, а не с Windows). Может быть, информация пригодится в другой статье или нужно написать аналогичную статью для Windows? Однако, не зная, что вы на самом деле написали, я, к сожалению, не могу сейчас сделать правильного предложения. Если вы не хотите редактировать статью самостоятельно, возможно, хотя бы поднимите эту тему на странице обсуждения статьи? Пожалуйста, дайте мне знать, когда я смогу помочь. - Матиаспол (разговор ) 16:42, 27 сентября 2014 (UTC)

Привет, Матиас. Я рад видеть, что номинант отозвал свой AFD для списка команд DOS. Когда-нибудь я могу переделать это. Я думаю, что из него получится хорошая сортируемая таблица со столбцами для имени команды, номера версии, где впервые появилась, внутренняя или внешняя, кто ее написал (Microsoft, IBM или какая-либо третья сторона), класса команды и краткого описания функции, моими словами. Было ошибкой допускать сложные детали, включая синтаксис и все переключатели. Я до сих пор не дошел до более тщательного обзора статей о FAT, но в последний раз, когда я смотрел на них, я подумал, что они значительно улучшились по сравнению с тем, что я помню ранее. Мне было интересно, знаете ли вы о какой-либо связи между Asmpgmr и этим парнем? Кто-то добавил все сборки PC DOS 7.1 на мою временную шкалу, используя сайт этого парня в качестве ссылки. Мне неудобно держать их в списке, но и удалять их тоже неудобно, если вы понимаете, о чем я. По всей видимости, все они являются внутренними никогда не выпускавшимися версиями, поэтому только разработчик может иметь о них прямую информацию. Wbm1058 ( обсуждение ) 15:52, 4 октября 2014 (UTC)

Если подумать, список выглядит не так уж плохо, теперь, когда он был очищен. Wbm1058 ( разговорное ) 16:06, 4 октября 2014 (UTC)

Привет, Wbm, я так занят другими проектами прямо сейчас, что даже не узнал, что он был номинирован на удаление. Хорошо, что номинация была отозвана, так как это центральная статья списка и элемент навигации по многим существующим (и даже будущим) статьям, связанным с DOS.

На самом деле, я не думаю, что допущение включения деталей было ошибкой, просто перечисление синтаксиса не делает его само по себе практическим руководством, как некоторые, кажется, полагают. Фактически, я считаю, что перечисление синтаксиса где-то абсолютно необходимо для достижения долгосрочных целей Википедии, но я видел перечисление синтаксиса в / этой / конкретной статье списка только как временную меру до отдельных статей для каждой и любой DOS команда будет создана в конечном итоге. В этих статьях следует обсуждать и сравнивать все версии и разновидности DOS в контексте, а не только одну. Имеется достаточно примечательной энциклопедической (и не учебной) информации, доступной для обоснования отдельных статей, я думаю, я мог бы написать несколько страниц для каждой из них, если бы у меня было на это время (к сожалению, у меня нет).

Однако я думаю и полностью согласен с вами, что было ошибкой позволить материалу, защищенному авторским правом, проникнуть в статью (синтаксис был непосредственно скопирован пользователем: Asmpgmr со справочных экранов PC DOS 7 ). Тогда я даже несколько раз просил его остановить это, но безрезультатно (и тогда админы никак не отреагировали на это), поэтому я в конце концов отказался от этого и надеялся, что кто-то рано или поздно перепишет материал. Да, я тогда проверил настоящую личность этого редактора (тогда веб-страницы не существовало), и хотя я думаю, что он был проблемным редактором, по крайней мере, предоставленная им информация была технически верной, за исключением нескольких подлинных ошибки (которые я исправил).

Что касается выпусков OEM DOS 7.1 для ПК, я в глубине души знаю (и почти наверняка заархивировал) четыре / выпущенных / сборок этой конкретной версии (их может быть больше). Я мог бы даже написать о них в одной из своих статей, так что, хотя это не обязательно RS сам по себе, это будет по крайней мере второй (и внешний) источник для резервного копирования некоторых из этих номеров сборки. Однако, учитывая мои другие обязанности, может потребоваться некоторое время, чтобы найти его. Привет,

- Матиаспол ( разговор ) 17:28, 4 октября 2014 г. (UTC)

Благодарим за редактирование страницы "Сиэтлские компьютерные продукты" [ править ]

Я изучаю компанию моего деда, SCP. Его зовут Родни Брок, и он не очень разговорчив, но все равно идет. Поскольку вы его редактировали, я подумал, что вы можете кое-что об этом знать. Пожалуйста, свяжитесь со мной: [email protected] [или @ hush.com] или позвоните мне 253-391-1866. Мой адрес в AIM - Tiberiusfury. Мне нужна помощь - я в бедности и скоро стану бездомным. Ищу дружбу и благотворительность. Спасибо, Матиаспол. Приветствую. - Предыдущий неподписанный комментарий добавлен Jonha.silverworm ( обсуждение • вклад ) 21:20, 30 октября 2014 г. (UTC)

Ослабьте правило дублирования ссылок (снова!) [ Править ]

Привет, Матиас,

Возможно, вам будет интересно узнать, что я вновь открываю проблему повторяющихся ссылок в Wikipedia_talk: Manual_of_Style / Linking # Relax_duplicate_linking_rule . - Slashme ( разговор ) 21:43, 21 февраля 2015 (UTC)

Отказ от ускоренного удаления - Genie (feral child [ править ]

Я отклонил ваше скорейшее удаление. WP: CSD # R3 применяется только к недавно созданным перенаправлениям, а этот существует с 2013 года. Для этого есть веская причина: когда перенаправление присутствует в течение некоторого времени, на него могут быть внешние ссылки, которые будут сломано удалением. В статистике трафика показывает , что это один получает что - то вроде 20 хитов в день. Если вы считаете, что его следует удалить, перейдите в WP: Redirects для обсуждения , но сначала прочтите WP: RFD # Когда следует удалять перенаправление? JohnCD ( разговор ) 13:44, 29 марта 2015 (UTC)

Викификация статьи [ править ]

6 апреля 2015 г. вы указали, что статья об архитектуре управления распределенными данными IBM нуждается в «серьезной викификации». Что это значит? Буду признателен за конкретную критику и предложения. Ричард А. Демерс ( разговор ) 20:10, 6 апреля 2015 (UTC)

Привет, Ричард, не волнуйся, это уже хорошая статья. Под «викификацией» я имел в виду, главным образом, то, что статья должна стать более тесно связанной с другими статьями. В нем очень мало ссылок на другие статьи, и в настоящее время на него не так много ссылок из других статей. В статье может быть больше ссылок, и они должны поддерживать отдельные утверждения, а не целые главы. Ссылки не следует помещать в заголовки разделов, а термины без входящих перенаправлений не следует выделять жирным шрифтом ( вместо этого используйте курсив ), но это просто косметика, предлагаемая нашим руководством по стилю (MOS).

Также было несколько областей, в которых я надеялся найти более подробную информацию / справочную информацию, например, в отношении файлов на основе записей и таких типов файлов, как последовательные, прямые, ключевые и случайные файлы. Мой интерес проистекает из FlexOS (на которой основаны ОС 4680 и 4690), поддерживающей аналогичные концепции IIRC. Приветствую, Матиаспол ( разговор ) 00:33, 7 апреля 2015 (UTC)

Привет, Матиас, я очень рад, что моя статья оказалась для вас интересной и достойной включения в Википедию.

• Я включил ссылки на другие статьи по темам, которые я упомянул в статье, но я не пытался добавлять ссылки DDM к этим статьям. Это то, что вы ищете?
• При написании статьи я активно использовал статьи, которые я написал и опубликовал в IBM Systems Journal, а также опубликованные документы об уровне 3 архитектуры DDM. Не могли бы вы предложить лучший способ сослаться на эти статьи (как я пытался сделать в заголовках разделов). Откровенно говоря, было бы сложно и однозначно связывать отдельные утверждения в моей статье в Википедии с конкретными утверждениями в статьях системного журнала. Обратите внимание, что моя статья в Википедии - это полностью новый текст; Я не занимался плагиатом.
• Можно было бы предоставить значительную дополнительную информацию о различных типах файлов, ориентированных на записи. Руководство программиста DDM содержит хорошие описания каждого типа, включая графику. Я не хотел бы переписывать и перерисовывать эту информацию, но что я могу законно скопировать и изменить из Руководства программиста? Потребуется ли мне специальное разрешение от IBM, издателя? Если так, то совсем не понятно, кого бы я спросил.
• Если бы мне пришлось предоставить дополнительную информацию о файлах, ориентированных на записи, я не думаю, что было бы целесообразно расширять статью DDM, если она не была помещена в отдельный раздел. В качестве альтернативы, это можно было бы добавить в статью о файловых системах, ориентированных на записи, но я несколько не решаюсь добавить это большое изменение в чужой текст. Пожалуйста, порекомендуйте.
• Я лично ничего не знал о FlexOS, хотя знал, что IBM 4680 реализует архитектуру DDM.

Спасибо за множество косметических изменений, которые вы внесли. Ричард А. Демерс ( разговор ) - Предыдущий недатированный комментарий добавлен в 02:37, 8 апреля 2015 г. (UTC)

Пожалуйста, Ричард. Позвольте мне ответить на некоторые из ваших вопросов:

• объявление 1) Да, везде, где это имеет смысл.
• ad 2) На самом деле, повторяющийся стиль был бы предпочтительнее. Тем не менее, вам нужно определить ссылки только один раз в статье. Если вы примените к ним имена, вы можете повторно вызывать их по имени без добавления избыточности.
• ad 3) Прямое копирование из источников будет нарушением авторских прав, если вы не можете получить разрешение от владельцев авторских прав (сложно и, вероятно, не стоит пытаться в этом случае). Вам придется перефразировать это своими словами.
• ad 4) Да, статья о файловой системе, ориентированная на записи, может быть хорошим местом для добавления такой информации. Вам не нужно беспокоиться об изменении других статей. Статьи Википедии никому не принадлежат. Если вы можете добавить полезное содержимое или внести исправления, вы можете редактировать любую статью, не спрашивая разрешения. Это совместные усилия. Если вы думаете (или знаете), что редактирование будет спорным, лучше всего поднять эту тему на странице обсуждения статьи, чтобы сначала обсудить ее с другими редакторами. Но вы, кажется, уже имеете правильное отношение к совместному редактированию.
• ad 5) FlexOS также поддерживает доступ к файлам на основе записей в файловой системе FAT, но распределенные файлы в FAT уникальны для ОС 4680 и ОС 4690. Я ищу более подробные сведения о реализации, как именно они реализуют эту функцию в файловой системе FAT.

Приветствую, - Матиаспол ( разговор ) 22:34, 18 апреля 2015 (UTC)

Привет, Матиас! После продолжительного отпуска я вернулся к статье об архитектуре управления распределенными данными . Основные изменения, которые я внес в статью:

• Я не выделил IBM в названии, потому что DDM имеет гораздо более широкий охват, чем просто продукты IBM. В статье до сих пор упоминается, что IBM спонсировала разработку DDM.
• Я удалил технические детали из раздела «История» и написал новые подразделы в разделе «Внутри DD», чтобы лучше объяснить файлы, ориентированные на записи, потоки, файлы и т. Д.
• Я нашел и добавил ссылки на многие другие концепции и продукты, упомянутые в статье.
• Я просмотрел многие страницы, на которые есть ссылка в статье, и добавил обратные ссылки на DDM и то, как он использовался в этом контексте.

Я надеюсь, что это удовлетворило вашу просьбу о «серьезной викификации». Я, конечно, открыт для дальнейших предложений. - (без подписи) 2015-06-14T17: 05: 18 Радемерс

TWL HighBeam регистрация [ править ]

Здравствуйте, пользователи библиотеки Википедии!

Вы получили это сообщение, потому что в библиотеке Википедии есть запись о получении вами годовой подписки на HighBeam. Это краткое обновление, напоминающее вам об этом доступе:

• Убедитесь, что вы все еще можете войти в свою учетную запись HighBeam; Если у вас возникнут проблемы, свяжитесь со мной для получения дополнительной информации. Когда ваш доступ истечет, вы можете повторно подать заявку на WP: HighBeam .
• Помните, что если вы найдете этот источник полезным для вашей работы с Википедией, обязательно включите цитаты со ссылками в Википедии: ссылки на партнерские ресурсы - это один из немногих способов продемонстрировать нашим партнерам использование учетных записей и спрос на них. Чем выше связь, тем больше вероятность возобновления полезного партнерства. Дополнительные сведения о цитировании этого источника см. В Википедии: HighBeam / Citations.
• Пишите необычные статьи, используя источники этого партнера? Создал ли доступ к этому источнику новые возможности для сообщества Википедии? Если у вас есть уникальная история о своем вкладе, дайте нам знать, и мы можем предоставить вам возможность написать сообщение в блоге о своей работе с одним из ресурсов нашего партнера.

Наконец, мы были бы очень признательны, если бы вы заполнили этот небольшой опрос . Опрос помогает нам не только лучше обслуживать вас, способствуя этому конкретному партнерству, но также помогает нам узнать, какие другие партнерские отношения и услуги может предложить библиотека Википедии.

Спасибо.Отправлено MediaWiki, доставка сообщения ( обсуждение ) в 16:45, 13 апреля 2015 г. (UTC)

Предупреждения 1, 2, 3 и 4 [ править ]

1. WP: COI : Контрабанда в ссылке на хороший самопубликованный источник из моего POV. Хорошо, согласно WP: IAR, если ничто другое не покрывает это правильно, но 36 ссылок на NWDOSTIP.TXT являются грубыми, а ссылки на записи форума с author = self тоже не пойдет.
2. РГ: ИЛИ : FAT + - это черновик, реализованный одним соавтором. Если это упомянуто один раз для WP: IAR по сравнению с известностью, этого более чем достаточно, ему не нужны четыре перенаправления FAT + , FAT16 + , FAT32 + , FATPLUS , с аналогичным зоопарком на dewiki, где вы ввели FATplus как "орфографическую ошибку". FAT32B - это ваше собственное оригинальное исследование, запись на немецком форуме не является ссылкой, я удалил ее. Конечно, FAT32B - это WP: NEO, если только кто-то другой не упоминает об этом где-то за пределами Википедии в смысле WP: 42..
3. WP: NEO : FAT32X и FAT16X - ненужные неологизмы для того, что вы (среди прочих) уже охватили типом раздела # PID_0Ch и типом раздела # PID_0Eh . Однако вы не можете просто создать новые типы разделов для FAT + и FAT32B в этом списке без надлежащих ссылок, где «правильный» - это снова то, что проходит проверки работоспособности WP: COI , WP: OR и WP: 42 .
4. WP: CIVIL : Сводка редактирования «Безосновательное возвращение редактора, предоставляющего надежный источник, является разрушительным» - это нормально, если это правда, но якобы предоставленный надежный источник имел интересную историю: AnomieBot добавил дату в мой запрос на цитирование, вы заменили ее на <ref name = "Caldera_1998_FDISK"> {{cite | title = FDISK | издатель = Caldera, Inc. | date = 1998}} </ref>, утверждая, что он охвачен #Nomenclature , отозвано мной после того, как я ничего не нашел в #Nomenclature и поддельной (пустой) ссылке. Это не было ни «беспочвенным», ни «надежным источником», возможно, это был случай «дерьма случается». Ссылки теперь лучше, спасибо,но по-прежнему в основном основан на программных продуктах с двумя разделами, в которых используетсяРГ: NEO для маркетинговых целей. Файловая система FAT, указанная ECMA (и Microsoft для FAT32), не зависит от LBA и типов разделов .

- Be..anyone ( разговор ) 23:10, 19 апреля 2015 (UTC)

Четырехместный (вычислительный) перечислен в разделе "Перенаправления" для обсуждения [ править ]

Редактор попросил обсудить проблему четверного перенаправления (вычисления) . Поскольку у вас было какое-то участие в четырехместном (вычислительном) перенаправлении, вы можете принять участие в обсуждении перенаправления, если вы еще этого не сделали. . Ditto Quartet (вычисления) , Tetrade (вычисления) и Half-byte . - Be..anyone ( разговор ) 02:00, 30 апреля 2015 (UTC)

Номинация на удаление четырех допустимых терминов, используемых экспертами в соответствующих областях, кем-то, кто, кажется, одержим удалением вещей, которые он лично не знает как «неологизмы», и кто (среди прочего) явно не понимает цели перенаправления . Хотя контроль качества - это очень хорошо, он часто требует более глубокого понимания предмета, и необоснованное переборщение с ним легко становится контрпродуктивным, поскольку такие методы излишне связывают драгоценное время и ресурсы других редакторов и тем самым наносят ущерб прогрессу проекта.

Результатом обсуждения стало сохранение всех четырех перенаправлений . - Матиаспол ( разговор ) 12:24, 21 июня 2015 (UTC)

Speedy удаление Выдвижение日独写真機商店[ править ]

На日 独 写真 機 機 機был размещен тег с просьбой о его скорейшем удалении из Википедии. Это было сделано в соответствии с разделом A2 критериев быстрого удаления , поскольку статья выглядит как статья на иностранном языке, которая была скопирована и вставлена ​​из другого проекта Викимедиа или была перенесена в другой проект. Пожалуйста, обратитесь к Википедии: Перевод, чтобы узнать о запросах и координации переводов из Википедии с иностранных языков на английский.

Если вы считаете, что эту страницу не следует удалять по этой причине, вы можете оспорить номинацию , посетив страницу и нажав кнопку с надписью «Щелкните здесь, чтобы оспорить это быстрое удаление». Это даст вам возможность объяснить, почему вы считаете, что страницу не следует удалять. Однако имейте в виду, что после того, как страница помечена для быстрого удаления, она может быть удалена без промедления. Пожалуйста, не удаляйте тег быстрого удаления со страницы самостоятельно, но не стесняйтесь добавлять информацию в соответствии с политиками и рекомендациями Википедии . Если страница удалена, и вы хотите восстановить удаленный материал для дальнейшего использования или улучшения, обратитесь к администратору удаления, или, если вы уже сделали это, вы можете разместить запросздесь . TF92 ( разговор ) 10:04, 4 июня 2015 (UTC)

A2 вообще не применяется к перенаправлениям, но, что более важно, это действительный термин для перенаправления. Сохранено на основании моего оспаривания и последующего обсуждения в беседе с пользователем: RHaworth / 12 июня 2015 # .E6.97.A5.E7.8B.AC.E5.86.99.E7.9C.9F.E6.A9.9F.E5 .95.86.E5.BA.97

- Матиаспол ( разговор ) 12:24, 21 июня 2015 (UTC)

Вы нужны библиотеке Википедии! [ редактировать ]

Мы надеемся, что библиотека Википедии была полезным ресурсом для вашей работы. TWL быстро расширяется, и нам нужна ваша помощь!

Имея всего пару часов в неделю, вы можете иметь большое значение для обмена знаниями. Зарегистрируйтесь и помогите нам одним из следующих способов:

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

Отправить от имени библиотеки Википедии с помощью доставки сообщений MediaWiki ( обсуждение ) 04:31, 7 июля 2015 г. (UTC)

Способы улучшения Список камер Sony с байонетом E [ править ]

Привет, я Сульфурбой. Матиаспол, спасибо за создание списка камер Sony с байонетом E !

Я только что пометил страницу, используя наши инструменты курирования , как имеющую некоторые проблемы, которые нужно исправить. Не работает то, чем не является Википедия.

Теги могут быть удалены вами или другим редактором после решения упомянутых в них проблем. Если у вас есть вопросы, вы можете оставить комментарий на моей странице обсуждения . Или, если вам нужна дополнительная помощь в редактировании, поговорите с волонтерами в Чайном доме . Sulfurboy ( разговор ) 20:52, 14 июля 2015 (UTC)

X flash синхронизация Комментарий [ править ]

Вы понимаете, что «X» - это не раздел на целевой странице, верно? Это не перенаправление ни на что конкретное на странице. Compassionate727 ( разговорное ) 15:56, 16 июля 2015 (UTC)

Да, но наличие таких якорей на целевой странице не обязательно. Цели ссылок существуют, чтобы помочь возможному будущему развитию статьи, поскольку они помогают разделять логически или семантически разные вещи, независимо от того, как статья будет развиваться в будущем. Ссылка на громоздкий заголовок раздела, такой как в статье, - не лучшая идея, так как заголовок, скорее всего, изменится в будущем.

Хотя это и не обязательно, я просто добавил анкеры к статье. - Матиаспол ( разговор ) 16:01, 16 июля 2015 г. (UTC)

Семантические отношения [ править ]

Привет, Матиаспол. Повторите это редактирование . Я согласен с тем, что диоптрия концептуально актуальна и должна остаться. В общем, семантические и лингвистические отношения совершенно не важны для См. Также ссылки. Это потому, что Википедия: Википедия - это не словарь . В частности, тема статьи - это не название статьи. Тема статьи - это то, что описывает название. То, что имеет лингвистическое отношение к заголовку статьи, но не концептуальное отношение к актуальной теме статьи, совершенно неуместны . Дело не в степени. - Срлеффлер ( разговор ) 19:59, 25 июля 2015 (UTC)

катадиоптер или катадиоптр [ править ]

Привет, я отменил добавление [15] слов «исторически также известного как катадиоптер или катадиоптр », потому что это утверждение не подтверждается приведенной ссылкой, это не исторический трактат по этимологии и просто показывает, что кто-то использует одно из этих слов. Википедия - это не словарь, в котором мы видим используемое слово, а затем пытаемся придумать определение, и это очень оригинальное исследование по стандартам Википедии. Я искал подходящее определение и потерпел неудачу, он продолжает появляться как термин на иностранном языке или использоваться людьми, не говорящими по-английски [16] (они могут неправильно использовать это слово). На этом этапе вам действительно нужно выполнить WP: BURDEN, т.е. ссылка на надежный источник, который напрямую поддерживает статью. Фонтаны Брин-Маура ( разговор ) 18:36, 26 июля 2015 (UTC)

Ваше редактирование: объектив Minolta shift [ править ]

Привет. При редактировании части Minolta на странице управления линзами перспективы вы изменили мою ссылку Rokkor на крепление SR , заявив: «Не имеет ничего общего с Rokkor, кроме крепления SR». Понятия не имею, что вы имеете в виду, потому что этот объектив на самом деле был объективом Rokkor. (Раньше у меня был такой, и вы действительно можете проверить это, просмотрев изображение в моем первом источнике или на этой странице KEH .) Вы правы, что он был сделан для крепления SR, но обе вещи могут быть правдой на то же самое время, и на самом деле, когда дело доходит до этого объектива. Хзой ( разговорное ) 23:08, 10 августа 2015 (UTC)

Привет, Хзой, да и нет. Я не спорю, что ваш объектив имел маркировку «Rokkor», но в период с 1976 по 1985 год Minolta выпустила пять версий этого объектива. Все они были объективами с байонетом SR, но только две версии 1976 года были линзами Rokkor, которые были заменены версией без Rokkor уже в 1977 году. Итак, общим свойством, описывающим этот объектив, является то, что это был объектив с креплением SR, а не то, что это был объектив Rokkor. Тот факт, что это был объектив с креплением SR, также важно знать по соображениям совместимости при обзоре линз управления перспективой, в то время как тот факт, что была также версия с маркировкой Rokkor, возможно, полезно знать (нам) пользователям Minolta, но Это не совсем актуально в статье, в конце концов, Rokkor - это всего лишь маркетинговое название, а не физическое свойство объектива. Фактически,конкретное упоминание версии Rokkor в этом контексте излишне сужает объем, поскольку исключает версии, не относящиеся к Rokkor, и поэтому вводит в заблуждение. Вот почему я удалил его. Это пять версий объектива:

• Minolta Shift CA Rokkor 2,8 / 35 мм (MPN 613-018, 1976-1977, тип: "MC-X")
• Minolta Shift CA Rokkor-X 2,8 / 35 мм (MPN 613-318, только США, 1976-1977, тип: "MC-X")
• Minolta Shift CA 2,8 / 35 мм (MPN 613-310, 1977-1978, тип: "MD-I")
• Minolta Shift CA 2,8 / 35 мм (MPN 613 - ???, 1978-1982, тип: "MD-II")
• Minolta Shift CA 2,8 / 35 мм (MPN 613-810, 1982-1985, тип: "MD-III")

(Кстати, у меня есть MD-III.) ... ;-)

Приветствую, Матиаспол ( разговор ) 15:44, 11 августа 2015 (UTC)

Интересно. Моя ошибка, я не знал, что существуют версии, отличные от Rokkor или Rokkor-X; Я изменю свое редактирование. Значит, у вашей версии есть зубец подтверждения фокусировки для X-600? Хзой ( разговор ) 18:13, 13 августа 2015 (UTC)

Да, у моего объектива есть штифт X-600, поэтому, согласно номенклатуре Денниса Ломанна, это на самом деле «MD-III-i», а не «MD-III». Итак, собственно говоря, у нас есть еще одна версия (613-818). - Матиаспол ( разговор ) 21:47, 13 августа 2015 г. (UTC)

Интересно. Думаю, у меня был только один объектив MD со штифтом фокусировки - 24 / 2,8. Не то чтобы это имело большое значение, поскольку я владел X-600 всего пару лет, прежде чем новинка перестала действовать. Хзой ( разговор ) 22:36, 13 августа 2015 (UTC)

Нет, наверное, 50 / 1,7. В любом случае, у меня был только один с последним креплением MD. Хзой ( разговорное ) 22:40, 13 августа 2015 (UTC)

Микро [ править ]

Привет. Я надеялся, что вы поделитесь своей мотивацией для переноса страницы Mikro на Mikro (греческая группа) и перенаправления на страницу dab, учитывая, что, похоже, нет другой конфликтной темы. Спасибо! - Фираэль ( разговор ) 05:03, 24 августа 2015 (UTC)

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

Причина, по которой я переместил страницу, заключается в том, что «Mikro» - это просто альтернативный вариант написания «Micro», и многие темы на странице DAB могут также выполняться поиском в «Mikro». Такие варианты написания часто комбинируются на одной странице DAB для удобства, тем более что это очень распространенный префикс, используемый в науке и технике, а также есть еще один диапазон с именем «Micro». Альтернативой была бы сноска в статье группы, указывающая на другую группу Micro и страницу с устранением неоднозначности, но я действительно чувствовал, что греческая группа не является основной темой здесь (в статье нет ссылок и только несколько входящих ссылок, так что даже неясно, соответствовала бы статья нашим критериям известности, если бы ее оспорили). Привет,- Матиаспол ( разговор) 09:48, 24 августа 2015 (UTC)

РПЛ [ править ]

Спасибо за тщательную очистку ссылок и за удаление фактически неверных утверждений относительно «определения» RPL, которые я пометил как сомнительные. :)

Я не собирался делать введение слишком многословным (хотя так оно и стало), но вместо этого я пытался прояснить, что аббревиатура «RPL» на самом деле «официально» не расширяется ни на что, хотя обычно ее расширяют до Reverse Польский Лисп - спасибо за замену «означает» на «производное от». :)

Если вас устраивает, я хотел бы включить хотя бы ссылку на сноску, которая уже включена в ссылки, но скрыта - если бы в ней был свой собственный раздел «== Notes ==» с цитатой Викса , то я думаю, было бы меньше путаницы в отношении любых «разногласий» вокруг «определения» аббревиатуры «РПЛ». Если вы не думаете, что это хорошая идея, тогда это нормально - просто предложение. :)

Спасибо и привет, Jdbtwo ( обсуждение ) 18:23, 14 сентября 2015 (UTC)

Спасибо тебе, Jdbtwo. Забавно то, что я планировал переработать вводящую в заблуждение формулировку и уже подготовил ссылки для включения в статью, когда увидел, что вы отметили неверное утверждение и добавили некоторые из тех же ссылок. Думаю, удачное время. ;-)

По поводу определения РПЛ. Я не думаю, что необходимо более подробно разбираться в этой статье - на самом деле, нет особой проблемы со смыслом: большинство пользователей просто воспринимают RPL как «обратный польский лисп», полуофициальный или нет. Я смог найти только один (1987 г.) источник "Процедурного языка на основе ПЗУ" (и еще несколько, обсуждающих это). Добавляя больше об этом, мы рискуем придать чрезмерное значение второму значению. Мы уже цитируем источник в справочнике - так что эта информация есть для всех, кому интересно. Это уже «сверх стандарта», поэтому я не думаю, что нам нужно ставить это на более видное место. Я бы предпочел увидеть расширение статьи в отношении самого языка.

Приветствую, - Матиаспол ( разговор ) 00:18, 18 сентября 2015 (UTC)

Re: Запрос на перемещение страницы [ править ]

Я разместил здесь, чтобы получить дополнительный консенсус по предлагаемым шагам. С уважением, Самсара 23:46, 15 сентября 2015 (UTC)

Уведомление о разрешении неоднозначности от 20 октября [ править ]

Здравствуй. Спасибо за ваши недавние правки. Википедия ценит вашу помощь. Однако мы заметили, что вы добавили несколько ссылок, указывающих на страницы значений . Такие ссылки почти всегда являются непреднамеренными, поскольку страница значений неоднозначности - это просто список заголовков статей типа «Вы имели в виду ...». Прочтите FAQ  • Присоединяйтесь к нам на DPL WikiProject .

Воздушные очки

добавлена ​​ссылка на Droop

Cosmolabe

добавлена ​​ссылка на Астрономический инструмент

История счетчика

добавлена ​​ссылка на Droop

Измерительный инструмент

добавлена ​​ссылка на Астрономический инструмент

Это сообщение можно удалить. Кроме того, чтобы перестать получать эти сообщения, следуйте этим инструкциям по отказу от рассылки . Спасибо, DPL-бот ( разговор ) 09:37, 20 октября 2015 (UTC)

Arcfourth [ править ]

Матиас, Arcfourth ссылается на Minute and second of arc # Fourth , но этот раздел не существует, а слово «четвертый» даже не появляется в статье. Куда должна быть направлена ​​эта цель? Ойярбепси ( разговор ) 02:22, 27 октября 2015 (UTC)

• Похоже, что у нескольких других созданных вами перенаправлений возникла такая же проблема. Пожалуйста, посмотрите. Ойярбепси ( разговор ) 02:23, 27 октября 2015 (UTC)

Привет, Ойярбепси. Да, я знаю. Это потому, что другой редактор удалил эту информацию. Он будет снова добавлен с другими источниками, но прежде, чем я займусь этим, мне сначала нужно закончить ряд других уже подготовленных изменений. Перенаправление уже указывает на правильную цель. - Матиаспол ( разговор ) 02:42, 27 октября 2015 г. (UTC)

Уведомление о ссылке на устранение неоднозначности от 1 декабря [ править ]

Здравствуй. Спасибо за ваши недавние правки. Википедия ценит вашу помощь. Однако мы заметили, что когда вы редактировали Sexagesimal , вы добавляли ссылку, указывающую на страницу значений Tierce . Такие ссылки почти всегда являются непреднамеренными, поскольку страница значений неоднозначности - это просто список заголовков статей типа «Вы имели в виду ...». Прочтите FAQ  • Присоединяйтесь к нам на DPL WikiProject .

Это сообщение можно удалить. Кроме того, чтобы перестать получать эти сообщения, следуйте этим инструкциям по отказу от рассылки . Спасибо, DPL-бот ( разговор ) 10:47, 1 декабря 2015 (UTC)

Приходит против Microsoft, перечисленных в Redirects для обсуждения [ править ]

Редактор попросил обсудить проблему перенаправления Comes v. Microsoft . Поскольку вы имели отношение к перенаправлению Comes v. Microsoft , вы можете принять участие в обсуждении перенаправления, если вы еще этого не сделали. Кодовое имя Лиза ( разговор ) 21:05, 23 января 2016 (UTC)

Обсуждение закрыто как «Keep» согласно Википедии: Перенаправления для обсуждения / Журнал / 23 января 2016 г. # Comes v. Microsoft - Матиаспол ( обсуждение ) 13:16, 1 мая 2016 г. (UTC)

Барнстар для вас! [ редактировать ]

Это действительно исправляло только незначительную проблему, но все равно спасибо. ;-) - Матиаспол ( разговор ) 13:16, 1 мая 2016 (UTC)

IJ [ править ]

Здравствуй! По поводу [17] см. IJ (орграф) . Ура, - Рууд 20:04, 20 апреля 2016 г. (UTC)

Привет, Рууд! Спасибо за информацию, очень ценим! Я должен признать, что видел оба варианта капитализации, когда жил в Нидерландах (несколько десятилетий назад), но это было недалеко от границы с Германией, так что это могло быть связано с «художественной лицензией», учитывая, что этой лигатуры не существует. на немецком языке, за исключением нескольких слов, производных от голландского. В любом случае, учитывая, что в «IJssel» это явно не комбинация двух слогов, не лучше ли нам изменить это на лигатуру «IJ» вместо «IJ», чтобы продвигать наилучший вариант написания? - Матиаспол ( разговор ) 21:03, 20 апреля 2016 г. (UTC)

Нет, эту лигатуру Unicode использовать не следует (см. IJ (digraph) #Encoding ). Боюсь, мне просто придется напоминать неголландцам не «исправлять» написание :) - Рууд 21:12, 20 апреля 2016 г. (UTC)

У меня есть хороший опыт использования {{ Not a typo }} в таких случаях. - Матиаспол ( разговор ) 22:09, 20 апреля 2016 г. (UTC)

Перенаправляет в отсутствующий раздел [ править ]

Привет, я видел , что вы создали инструкции фиксированной длины и набор команд фиксированной длины , но они перенаправлять Instruction_set # Fixed_length который является раздел , который не существует, было то , что намеренно? Mlkj ( разговор ) 13:11, 30 мая 2016 (UTC)

Здравствуй. Да, это было сделано намеренно, чтобы сгруппировать несколько входящих перенаправлений на логически различимые подтемы в целевой статье. Соответствующие якоря могут уже существовать в статье (хотя и не обязательно в виде заголовков разделов), или они могут быть добавлены на более позднем этапе (либо мной, либо другими редакторами, работающими над статьей и регулярно проверяющими входящие ссылки по порядку. определить области для возможного улучшения и реорганизации статьи). Даже если якоря не существуют (пока), нацеленные на них ссылки не являются ошибочными, поскольку эти расширения #hash являются полностью необязательными и могут также рассматриваться как форма неявной документации. Если они не существуют, браузер начнет отображать статью вверху, и это будет так же, как если бы невидимые якоря для них были бы припаркованы вверху статьи с помощью {{якорь }}.

Таким образом, в идеале они разрешаются в определенных областях целевой статьи, обсуждая термин (и если статья уже достаточно хорошо организована, я обычно добавляю невидимые привязки), однако, даже если нет подходящего места, где цель #hash могла бы указывают на то, что это может произойти после будущей реорганизации статьи, поэтому все еще может иметь смысл добавить такие цели, чтобы помочь лучше организовать информацию в будущем. Кроме того, в самоорганизующемся проекте параллельной разработки тот факт, что конкретная целевая статья уже не в хорошей форме, не должен препятствовать другим редакторам уже ссылаться на более конкретные подтемы целевой статьи. Люди работают по всем направлениям одновременно ...

Если, однако, перенаправление явно использует {{ R to anchor }} или {{ R to section }}, привязка также должна существовать. Итак, если вы обнаружите, что перенаправления помечены таким образом, а в целевой статье отсутствуют соответствующие привязки, проверьте историю редактирования, чтобы узнать, была ли привязка удалена (случайно) в процессе редактирования и можно ли ее повторно применить. Если нет, удалите (или измените) соответствующий rcat. Только если цель #hash вообще не имеет смысла (как это могло произойти после серьезной реструктуризации или развития статьи в совершенно другом направлении, чем предполагалось изначально), цель #hash следует удалить.

- Матиаспол ( разговор ) 14:30, 30 мая 2016 г. (UTC)

Опрос исполнительного директора Фонда Викимедиа, 2016 г. [ править ]

Совет попечителей Фонда Викимедиа назначил комитет, который возглавит поиск следующего исполнительного директора фонда. Одна из наших первых задач - написать описание должности исполнительного директора, и мы просим мнение сообщества Викимедиа. Уделите несколько минут и заполните этот опрос, чтобы помочь нам лучше понять ожидания сообщества и персонала в отношении исполнительного директора Фонда Викимедиа.

• Опрос (проводится Qualtrics)

Спасибо, Исполнительный директор Фонда Викимедиа Руководящий комитет по поиску через доставку сообщений MediaWiki ( доклад ) 21:50, 1 июня 2016 г. (UTC)

Цитаты [ править ]

Повторите вашу правку [18] , мне любопытно: что вы используете в MOS в качестве поддержки для подавления всех параметров template: cite ... в непрерывном тексте? Это противоположность ремонтопригодности: очень трудно вообще читать исходный код, потому что все параметры шаблона собраны вместе с обычным текстом. По крайней мере, перенос строки должен отделять параметры цитирования от тегов <ref>, особенно для длинных цитат. - Эльфион ( разговор ) 19:07, 22 июня 2016 г. (UTC)

Привет, Эльфион, у меня нет особых предпочтений в отношении разрывов строк в цитатах. Лично я их больше не использую (когда-то использовал), так как в наши дни этот стиль, похоже, используется редко. Но если бы я редактировал статью, в которой постоянно используется этот стиль, я бы внес соответствующие изменения. MOS также не имеет предпочтительного стиля, он просто требует согласованности, чтобы улучшить ремонтопригодность. К сожалению, в статье использовались всевозможные стили, что затрудняло просмотр исходного кода. Итак, одной из причин моего редактирования было простое обеспечение большей согласованности между цитатами в статье, и, поскольку в меньшем количестве цитат использовались разрывы строк, я преобразовал их, а не другие цитаты.

Если вы спросите меня, в идеале я бы хотел, чтобы все цитаты были перенесены в разделы (и) ссылок (и примечаний), чтобы в тексте статьи были нужны только короткие цитаты - это значительно улучшает читаемость. Но сделать это вручную для примерно 40 цитирований - довольно сложная работа, поэтому я обычно выполняю этот шаг только тогда, когда я больше участвую в разработке статьи (еще не в этой).

- Матиаспол ( разговор ) 20:25, 22 июня 2016 г. (UTC)

Перемещение страницы разрешено [ править ]

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

Пожалуйста, найдите время, чтобы просмотреть Википедию: Перемещение страниц для получения дополнительной информации об этом праве пользователя, особенно о критериях перемещения страниц без выхода из перенаправления . Не забывайте следовать процедурам очистки после перемещения и при необходимости вносить исправления в ссылки, включая неработающие двойные перенаправления, когда они suppressredirectиспользуются. Это можно сделать с помощью Special: WhatLinksHere . Также очень важно, чтобы никто другой не имел доступа к вашей учетной записи, поэтому вам следует подумать о том, чтобы потратить несколько минут, чтобы защитить свой пароль . Как и в случае со всеми правами пользователя, имейте в виду, что в случае злоупотребления или использования спорными способами без согласия ваш статус перемещения страницы может быть отменен .

Полезные ссылки:

• Википедия: Запрошенные ходы
• Категория: Статьи, которые нужно переместить , для запросов на переименование статей, ожидающих действия.

Если вы больше не хотите, чтобы движок страницы работал правильно, напишите здесь или просто дайте мне знать. Спасибо и удачного редактирования! Након 01:13, 23 июля 2016 (UTC)

пи на пилькроу [ править ]

почему вы добавили пи в качестве знака еще и к pilcrow? мне кажется, что они не связаны между собой, кроме того, что они начинаются с одинаковых букв EggsInMyPockets ( обсуждение ) 04:36, 2 августа 2016 г. (UTC)

Привет, я уже давал объяснение в статье. ;-) Они не связаны напрямую, за исключением того, что у них есть похожие глифы: pilcrow (¶), pi (π, Π). В некоторых шрифтах они выглядят практически одинаково.

Во времена 7-битных и 8-битных кодовых страниц людям иногда приходилось проявлять творческий подход из-за ограниченного количества доступных глифов, поэтому, в зависимости от кодовой страницы, глифы иногда использовались для разных целей в зависимости от контекста. Например, на компьютерах IBM в их конфигурации по умолчанию с кодовой страницей 437 (которая имела только строчную букву «пи»), если в некотором программном обеспечении требовалось отображать прописную букву «пи», вместо нее часто использовался символ пилькроу. Подобным образом, другой символ использовался как для греческой строчной буквы бета, так и для немецкого острого s .

В общем, ссылки в разделе «См. Также» могут быть ссылками на очевидно связанные статьи (которые по некоторым причинам до сих пор не упоминались в основной части), но они также существуют для соединения тем, которые могут быть связаны только удаленно через некоторые ассоциации (см. WP: SEEALSO ). Они должны помочь читателю найти другое содержание, которое могло бы поместить исходную статью в некоторый более широкий контекст или лучше различать их. Рассмотрение двух статей с точки зрения похожих на вид глифов, безусловно, является одной из них, не только для того, чтобы помочь читателям, заканчивающим одну статью, найти другую, но и для того, чтобы читатели осознали тот факт, что похожий на вид глиф вообще существует. (чтобы они могли, например, улучшить программное обеспечение для распознавания символов, чтобы лучше различать их).

- Матиаспол ( разговор ) 08:36, 2 августа 2016 г. (UTC)

PCS и Cadmus [ править ]

Давным-давно, в галактике ^ W ^ W ^ Побережье далеко, я брал интервью в компании под названием «Cadmus Computer Systems», расположенной в Лоуэлле, Массачусетс ; у этой компании была линейка рабочих станций Unix на базе 68k (у меня есть смутные воспоминания об интервью в какой-то компании, возможно, из Массачусетса, возможно, во время той же поездки, у которой была «Unix-подобная» операционная система в старом понимании, т. е. система, которая не была Unix-совместимой системой, но была «похожа» на Unix в ее API, но я, возможно, неправильно запомнил). Была ли эта компания связана с Periphere Computer Systeme и какая связь? Cadmus (компьютер) перенаправляет на Periphere Computer Systeme # Cadmus , но Periphere Computer Systemeне содержит слова «Cadmus» где-либо, кроме раздела «См. также», так что это не очень полезный редирект. Гай Харрис ( разговор ) 02:50, 16 августа 2016 (UTC)

Привет, парень, Cadmus - это линейка 68k Unix-рабочих станций, созданная PCS (Cadmus 9000, Cadmus 9900 и т. Д.). В немецком WP есть статья о них: de: Cadmus Workstations . У PCS в течение нескольких лет была дочь в США, которую назвали Cadmus Computer Systems, основанную в 1985 году.

- Матиаспол ( разговор ) 09:44, 16 августа 2016 г. (UTC)

Lacta- внесен в список редиректов для обсуждения [ править ]

Редактор попросил обсудить проблему переадресации Lacta- . Поскольку вы имели какое-то отношение к Lacta- редиректу, вы можете принять участие в обсуждении перенаправления, если вы еще этого не сделали. Пэм Д 09:21, 18 августа 2016 (UTC)

...следовать за. Привет!

Я все еще пытаюсь исследовать это: спасибо за ссылку на итальянский перевод справочника Ланге (в лакхской статье), но я не могу найти никакого доступа к содержанию этой книги. Вы знаете, что там на самом деле написано? Не могли бы вы поделиться электронным письмом Кардарелли по этому поводу; если он ответит на вопрос, то это может избавить меня от вопроса снова. Спасибо! : Imaginatorium ( разговор ) 02:30, 31 августа 2016 (UTC)

Пожалуйста, давайте не будем открывать для этого еще одну ветку и (теперь, когда RfD закрыт) оставим ее на Talk: Metric prefix # Lacta?

- Матиаспол ( разговор ) 07:04, 31 августа 2016 г. (UTC)

Lacta- внесен в список редиректов для обсуждения [ править ]

Редактор попросил обсудить проблему переадресации Lacta- . Поскольку вы имели какое-то отношение к Lacta- редиректу, вы можете принять участие в обсуждении перенаправления, если вы еще этого не сделали. Imaginatorium ( разговор ) 06:36, 2 сентября 2016 (UTC)

Номинация на удаление шаблона: PII [ править ]

Шаблон: PII был номинирован на удаление . Вам предлагается прокомментировать обсуждение в разделе шаблона на странице Шаблоны для обсуждения . Энди Маббетт ( Свиноядное крыло ); Поговорите с Энди ; Редакции Энди 19:19, 2 сентября 2016 г. (UTC)

Номинация MfD пользователя: Jacques-Laporte [ править ]

Пользователь: Jacques-laporte , страница, которую вы создали или в которой внесли существенный вклад, была номинирована на удаление . Ваше мнение по этому поводу приветствуется; вы можете принять участие в обсуждении, добавив свои комментарии в Википедию: Разное для удаления / Пользователь: Jacques-laporte и не забудьте подписать свои комментарии четырьмя тильдами (~~~~). Вы можете редактировать содержимое User: Jacques-laporte во время обсуждения, но не должны удалять шаблон для удаления из верхней части страницы; такое удаление не завершит обсуждение удаления. Спасибо. MSJapan ( обсуждение ) 01:14, 22 сентября 2016 (UTC)

Названия продуктов [ править ]

Что касается недавнего переименования статей о камерах Sony, обратите внимание на Википедию: Article_titles # Foreign_names_and_anglicization , в частности:

Имена, изначально не написанные на латинском алфавите, такие как греческие, китайские или русские имена, должны быть транслитерированы.

Похоже, это политика английской Википедии.

HTH,

Самсара 04:47, 2 октября 2016 г. (UTC)

грамматический пункт [ править ]

Привет, дорогой чувак. Скажи мне, пожалуйста, в чем разница между «должен» и «должен»? спасибо Альборзагрос ( разговор ) 11:08, 3 декабря 2016 (UTC)

Выборы в ArbCom 2016 : Открыто голосование! [ редактировать ]

--LINUX -.--- внесен в список редиректов для обсуждения [ править ]

Редактор попросил обсудить проблему перенаправления --LINUX -.--- . Поскольку у вас было какое-то участие в перенаправлении --LINUX -.--- , вы можете принять участие в обсуждении перенаправления, если вы еще этого не сделали. -  Godsy  ^{( TALK} _{CONT )} 8:32, 19 декабря 2016 (UTC)

Перенаправление из "WDR Sinfonieorchester" в "NDR Elbphilharmonie Orchestra" [ править ]

Re: ваш перенаправление с WDR Sinfonieorchester на NDR Elbphilharmonie Orchestra . Я ожидал, что WDR Sinfonieorchester вместо этого перенаправит на WDR Symphony Orchestra Cologne . [19]  - Tea2min ( разговор ) 09:28, 12 января 2017 г. (UTC)

Спасибо, что заметили это! Создание "WDR Sinfonieorchester" было ошибкой копирования и вставки из "NWDR Sinfonieorchester". На самом деле я хотел создать "NDR Sinfonieorchester", который, однако, уже существует.

- Матиаспол ( разговор ) 11:00, 12 января 2017 г. (UTC)

Наклейка ASCII [ править ]

Куда должны были указывать стик ASCII и стик (ASCII) ? - Диспенсер 19:42, 18 января 2017 г. (UTC)

86DOS и 86 DOS [ править ]

Похоже, вы отнесли эти перенаправления к категории , но я не вижу доказательств того, что Википедия в настоящее время рассматривает варианты межсловного интервала и пунктуации как «орфографические ошибки». Другими словами, такие различия, как правило, не настолько плохи, чтобы их нельзя было распечатать , поскольку они вместо этого упоминаются в , что не претендует на пригодность для печати:{{R from misspelling}}{{R from modification}}

«Это перенаправление от модификации заголовка цели; например, переставлены слова или изменена пунктуация в имени » (курсив мой).

Даже если бы эти перенаправления были непечатными, в частности, были бы другие более подходящие Rcats . Это касается имен, которые были официально объявлены предметом статьи как неправильные, но ваши сводки редактирования, похоже, не совсем соответствуют этому правилу.{{R from incorrect name}}

Здесь есть смысл? Или вы могли бы объяснить, почему R от неправильного написания , тем не менее, более подходит, чем R от модификации или любой другой Rcat для этих конкретных перенаправлений? - SoledadKabocha ( разговор ) 05:26, 20 января 2017 (UTC)

Привет, я пометил их как орфографические ошибки, потому что это орфографические ошибки. ;-) Пожалуйста, проверьте исходные файлы и документацию SCP.

За прошедшие десятилетия появилось множество вариантов написания, поэтому нам нужны эти перенаправления с вариантов написания на статью, находящуюся с правильным написанием. Однако, как энциклопедия, мы обязаны оставаться исторически правильными, поэтому важно пометить эти другие варианты написания как орфографические ошибки, чтобы они отображались в специальной категории обслуживания и могли быть легко исправлены, если кто-то добавит ссылки через них из других статьи. Хорошо, что эти орфографические ошибки помечаются как не подлежащие печати, чтобы они не распространялись дальше.

Да, R из модификации также применяется (я только что добавил его), но в случае названий продуктов модификация также является ошибкой.

R от неправильного имени также может применяться, но я видел, что это используется в основном в тех случаях, когда перенаправление отличается намного больше, чем модификация. Например, вы можете найти термин Open Access Development Group в книге, относящейся к японскому консорциуму OADG, который, однако, официально расширяется до Open Architecture Developers 'Group .

- Матиаспол ( разговор ) 11:14, 20 января 2017 г. (UTC)

Да, я понял, что в ваших сводках редактирования фактически цитируется источник, чтобы обосновать, что эти имена были кем-то сочтены неверными, но у меня было сомнение относительно того, насколько это квалифицируется как «официальные» утверждения.

Более того, однако, они, похоже, не удовлетворяют тому, что я знаю, как словарное определение «орфографической ошибки», по крайней мере, согласно Wiktionary (смысл 4: «(переходный) Букв: составить (a слово)."). ( wikt: ссылки с ошибками на wikt: опечатки на wikt: опечатки на wikt: spell ) Эти конкретные перенаправления содержат те же буквы в том же относительном порядке, что и их цель. По общему признанию, это определение ничего не говорит о числах и т. Д.

Прошу прощения, если, возможно, вы более знакомы с другим языком, в котором родственное слово «орфографическая ошибка» имеет более широкий смысл, чем в английском языке, что приближает его значение к тому, что английская Википедия называет «непригодным для печати»; Моя точка зрения заключалась в том, что существуют определенные категории для определенных подтипов непечатаемых перенаправлений, по какой-то причине.

Я не буду вносить никаких изменений в эти перенаправления, если вы согласны с тем, что они не нужны. Однако, возможно, позже в другом месте будет еще что обсудить определения этих Rcats. - SoledadKabocha ( разговор ) 17:10, 20 января 2017 (UTC)

Зенти - внесен в список редиректов для обсуждения [ править ]

Редактор попросил обсудить проблему перенаправления Zenti- . Поскольку вы имели какое-то отношение к Zenti- redirect, вы можете принять участие в обсуждении перенаправления, если вы еще этого не сделали. Pam D 15:32, 3 февраля 2017 г. (UTC)

Стили CSS в шаблонах [ править ]

Всем привет и искренние извинения, если вы получаете это сообщение более одного раза. Просто предупреждаю о том, что в настоящее время ведется работа над расширением для включения стилей CSS в шаблонах. Пожалуйста, проверьте документ на mediawiki.org, чтобы обсудить лучшие методы хранения и то, чего нам следует избегать при реализации. Спасибо, м: Пользователь: Melamrawy (WMF) , 09:11, 6 февраля 2017 г. (UTC)

Страница, которую вы открыли (Гейзер с холодной водой), была просмотрена! [ редактировать ]

Спасибо за создание гейзера с холодной водой , Матиаспол!

Редактор Википедии DarjeelingTea только что просмотрел вашу страницу и написал для вас следующую заметку:

хорошая статья

Чтобы ответить, оставьте комментарий на странице обсуждения DarjeelingTea .

Узнайте больше о курировании страниц .

DarjeelingTea ( разговорное ) 19:18, 11 февраля 2017 (UTC)

RS-232 и последовательный порт [ править ]

Спасибо за вашу значительную работу над этим! Дже ( разговор ) 07:06, 6 марта 2017 (UTC)

Спасибо. - Матиаспол ( разговор ) 11:13, 10 марта 2017 г. (UTC)

Предлагаемое удаление Octad [ править ]

Статья Octad была предложена для удаления по следующим причинам:

Ненужная страница WP: DAB , может быть лучше с примечаниями к шляпе вверху каждой статьи

Хотя любой конструктивный вклад в Википедию приветствуется, контент или статьи могут быть удалены по любой из нескольких причин .

Вы можете предотвратить предлагаемое удаление, удалив {{proposed deletion/dated}}уведомление, но, пожалуйста, объясните причину в своем резюме редактирования или на странице обсуждения статьи .

Пожалуйста, подумайте об улучшении статьи, чтобы устранить поднятые проблемы. Удаление {{proposed deletion/dated}}остановит предложенный процесс удаления , но существуют и другие процессы удаления . В частности, быстрый процесс удаления может привести к удалению без обсуждения, а статьи, подлежащие удалению, позволяют при обсуждении достичь консенсуса в отношении удаления. - KAP03 ( ^{Обсуждение  • Вклад  • Электронная почта} ) 22:24, 26 марта 2017 г. (UTC)

Номинация на быстрое исключение в категории: Гостиницы, созданные в 2017 году [ править ]

В категории «Отели», созданной в 2017 году, был размещен тег с просьбой о его скорейшем удалении из Википедии. Это было сделано в соответствии с разделом C1 критериев быстрого удаления , поскольку категория была пустой в течение семи или более дней и в настоящее время не обсуждается в категориях для обсуждения или в категориях разрешения неоднозначности .

Если вы считаете, что эту страницу не следует удалять по этой причине, вы можете оспорить номинацию , посетив страницу и нажав кнопку с надписью «Конкурс на это быстрое удаление». Это даст вам возможность объяснить, почему вы считаете, что страницу не следует удалять. Однако имейте в виду, что если страница помечена для быстрого удаления, она может быть удалена без промедления. Пожалуйста, не удаляйте тег быстрого удаления со страницы самостоятельно, но не стесняйтесь добавлять информацию в соответствии с политиками и рекомендациями Википедии . AusLondonder ( разговорное ) 06:48, 30 марта 2017 (UTC)

Ссылки в десятичной системе с двоичным кодом [ править ]

«Добавлена ​​ссылка. Начато перемещение ссылок в раздел ссылок для упрощения обслуживания»

Мы должны это делать? Для меня это затрудняет обслуживание. Если вы хотите отредактировать ссылки, а также текст для раздела, вам нужно отредактировать всю статью (а не только раздел), а затем переходить между ними. Я просто не вижу преимущества в том, чтобы иметь дело с рефери в очереди. Дже ( разговор ) 18:38, 5 апреля 2017 (UTC)

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

С другой стороны, исходный код статей с более чем несколькими ссылками или с более длинными ссылками часто почти нечитаем из-за всего беспорядка, вызванного ссылками (иногда несколько страниц с фактическим содержанием всего нескольких слов между ними). Это затрудняет дальнейшую работу над текстом. Перемещение «беспорядка» в раздел справки делает текст статьи снова доступным для чтения на уровне исходного кода. Кроме того, для повышения качества ссылок часто требуется много итераций, а иногда и сравнения или копирования и вставки между ссылками (также для того, чтобы со временем привести их всех к одному и тому же уровню качества и формата). Это намного проще сделать, если все ссылки хорошо сгруппированы вместе и только этот раздел нужно «заблокировать» для редактирования при улучшении ссылок.- Матиаспол( разговор ) 19:16, 5 апреля 2017 (UTC)

Очки взяты. Тем не менее, я стону всякий раз, когда редактирую статью, написанную таким образом. Я все еще буду. Думаю, я работаю над рефами больше, чем над обычным редактором.

Жаль, что невизуальный редактор не имеет возможности свернуть текст ссылки. Или, в случае LDR, показать их, как если бы они были написаны в строке. Может быть, VE и умеет, но я разбираюсь в языке разметки. Джех ( разговорное ) 20:19, 5 апреля 2017 (UTC)

Перенаправления в Word (компьютерная архитектура) [ править ]

Я только что заметил, что вы недавно создали несколько перенаправлений в Word (компьютерная архитектура), которые пересылают разделы или якоря, которых не существует. Планируете ли вы создать эти разделы или разместить соответствующие привязки? Steel1943 ( разговор ) 18:52, 5 апреля 2017 (UTC)

• ... То же самое и с перенаправлениями, которые вы недавно создали на Byte . Вы создали перенаправления на Byte, которые ведут к разделам или якорям на Byte , которых не существует. Steel1943 ( разговор ) 18:54, 5 апреля 2017 (UTC)

Конечно, эти расширения #hash являются необязательной частью синтаксиса, они не должны существовать. Это не ошибка.

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

Когда я создаю такие логические группы перенаправлений, я часто добавляю такие цели #hash, чтобы облегчить возможную организацию и реорганизацию содержимого статьи.

В этом конкретном случае я ожидаю, что когда-нибудь в будущем различные размеры байтов и слов будут рассмотрены более подробно - именно поэтому я в первую очередь создал перенаправления. Как только они появятся и со временем станут использоваться, читатели могут использовать их для своих исследований посредством обратного поиска определенной ширины битов, упомянутой в других статьях, что было бы невозможно, если бы все эти статьи были просто связаны со статьями в байтах и ​​словах в Общее. Конечно, обратный поиск также работает без якорей, и до тех пор, пока в целевой статье не обсуждаются более подробно различные размеры слов, эти якоря можно опустить или все они могут быть сгруппированы вместе, чтобы «задокументировать» их существование. Однако было бы напрасной тратой энергии, если бы они не были добавлены в перенаправления с самого начала,поскольку для этого потребуется, чтобы кто-то еще добавил их на более позднем этапе, а добавление их с самого начала не создает накладных расходов.

- Матиаспол ( разговор ) 19:56, 5 апреля 2017 г. (UTC)

Я понимаю, что вы имеете в виду, но это не помогает другим читателям, которые могут использовать эти перенаправления, а затем посмотреть на «код» перенаправления и увидеть, что перенаправление должно привести их к разделу или привязке, которые не существовать. Фактически, редакторы в Википедии разработали внешние перенаправления, которые фактически находят такие перенаправления, как те, которые вы создали, и отмечают их как содержащие ошибки, поскольку их соответствующий раздел или привязка не существует. (Например, инструмент в [20] обнаруживает входящие перенаправления для поиска ошибок перенаправления раздела / привязки.) Кроме того, если создается соответствующий раздел или привязка для представления субъектов, которые вы создали перенаправления, но привязка / раздел не называется вы поместили его в перенаправления, перенаправления по-прежнему будут просто перенаправлять в верхнюю часть страницы. Так что вы'по сути, играемWP: CRYSTALBALL - игра в угадывание того, как такие предметы будут создаваться на их целевых страницах, если, как я просил, вы не собираетесь создавать предметы самостоятельно. Итак, если вы не планируете создавать эти разделы / якоря в ближайшем будущем, перенаправления раздела / якоря в этих перенаправлениях, вероятно, следует удалить. Steel1943 ( разговор ) 20:51, 5 апреля 2017 (UTC)

Предлагаемое исключение из Списка несуществующих производителей жестких дисков [ редактировать ]

Статью Список производителей несуществующих жестких дисков было предложено удалить по следующим причинам:

За исключением списка компаний, эта статья дублирует раздел Manurfacturing History Истории жестких дисков . Сам список является неполным, неточным и оригинальным исследованием , см. « Энциклопедия этой статьи - Удалить?»

Мы приветствуем любой конструктивный вклад в Википедию, однако страницы могут быть удалены по любой из нескольких причин .

Вы можете предотвратить предлагаемое удаление, удалив {{proposed deletion/dated}}уведомление, но, пожалуйста, объясните причину в своем резюме редактирования или на странице обсуждения статьи .

Пожалуйста, подумайте об улучшении страницы для решения поднятых проблем. Удаление {{proposed deletion/dated}}остановит предложенный процесс удаления , но существуют и другие процессы удаления . В частности, быстрый процесс удаления может привести к удалению без обсуждения, а статьи, подлежащие удалению, позволяют при обсуждении достичь консенсуса в отношении удаления. Tom94022 ( разговорное ) 00:16, 12 апреля 2017 (UTC)

Выдвижение диаграммы Джонстона на удаление [ править ]

Обсуждается вопрос о том, подходит ли диаграмма Джонстона статьи для включения в Википедию в соответствии с политиками и руководящими принципами Википедии или ее следует удалить .

Статья будет обсуждаться в Википедии: статьи для удаления / диаграмма Джонстона до тех пор, пока не будет достигнут консенсус, и любой желающий может принять участие в обсуждении. Номинация объяснит политику и рекомендации, которые вызывают озабоченность. Обсуждение сосредоточено на высококачественных доказательствах, а также на наших правилах и рекомендациях.

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

метрические сокращения [ править ]

Меня ввел в заблуждение акцент в руководстве NIST . То, что более правильные формы («килоом», а не «килоом» и т. Д.) Являются стандартными, очень приветствуется. Однако ссылка [6] ^[1] в этом руководстве не кажется легкодоступной. Вы бы знали, как получить доступ к его тексту? Это было бы полезно с точки зрения того, как статья Ома решает эту проблему , и в том, что мы считаем соответствующей формой в статьях в WP в целом. - Quondum 14:49, 9 июня 2017 г. (UTC)

ED Floppy Disk [ править ]

Ваше недавнее редактирование изменило определение аббревиатуры FD «ED» с «Extended Density» на «Extra high Density». Поисковые запросы Google обнаруживают и то, и другое, и я даже нашел «Extra Density». Я проверил стандарт ECMA, но он не дал никаких указаний относительно маркировки. Я предпочитаю "Extended Density", учитывая, что IBM, кажется, использовала его в некоторых своих продуктах, и они были ранними, если не первыми пользователями (некоторые говорят, что Apple). В отсутствие вводной литературы по продуктам от первых производителей накопителей и носителей, я думаю, мы должны использовать и то, и другое в Википедии. есть идеи? Tom94022 ( разговор ) 07:14, 16 июня 2017 (UTC)

Привет, Том, меня тоже поразило довольно большое количество неправильных обращений в Google, но это не первый случай, когда ошибки в Википедии распространяются на Интернет и Google. Тем не менее, «ED» правильно означает дополнительную (-высокую) плотность, а не расширенную плотность. Все дискеты ED, которые у меня есть (IBM, 3M, Toshiba), имеют "сверхвысокую плотность", и, чтобы подтвердить свою память, я просто просмотрел это в старой книге. Я надеюсь найти время для более систематической проверки моей библиотеки на следующей неделе, чтобы увидеть, смогу ли я найти «расширенный» в каком-либо авторском источнике того времени. Что касается решения этой проблемы, у меня нет проблем с созданием переадресации, помеченной как «R из неправильного названия», как мы обычно делаем для распространенных неправильных терминов. - Матиаспол ( разговор ) 11:26, 16 июня 2017 г. (UTC)

Тем временем я проверил много старых источников (книги, журналы), все они определяют это как «сверхвысокую плотность». Я не смог найти ни одного современного источника, определяющего его как «расширенную плотность», это определение можно найти только в недавних источниках (которые не считаются, потому что на них явно влияет ложная информация в Интернете или в Википедии). Кто-то, должно быть, перепутал дискеты ED (сверхвысокой плотности) с несвязанными спецификациями EDD (расширенный дисковый накопитель) или XDF (формат расширенной плотности).

Я добавил несколько быстрых ссылок в статью, но у меня нет времени, чтобы отформатировать несколько десятков ссылок в правильный формат.

- Матиаспол ( разговор ) 23:19, 17 июня 2017 г. (UTC)

Хорошо - отмеченные дискеты от этих поставщиков являются убедительным доказательством. Искал такие изображения без особого успеха и давно выкинул все свои ФД. Если у вас есть несколько свободных минут, вы можете разместить фотографии в Wiki Media, на которые затем можно будет ссылаться из статьи. Спасибо за продолжение. Tom94022 ( разговор ) 18:24, 18 июня 2017 (UTC)

Объективы Sony с байонетом E [ править ]

Привет, Матиаспол, твое изменение понято. Статья становилась немного загроможденной, и с тех пор я начал новую страницу с подробным описанием сторонних линз в предыдущей версии рассматриваемой статьи.

- Chevy111 ( разговор ) 11:12, 20 июня 2017 г. (UTC)

Готово и сделано. Редирект активен. Я также только что понял, что вы редактор, который дал мне красную звезду. Спасибо ;)

- Chevy111 ( разговор ) 11:45, 20 июня 2017 г. (UTC)

Ссылка на поиск в каталоге статья-постфикс [ править ]

Можно ли изменить {{ ссылку для поиска в каталоге }}, чтобы не было пробелов между статьей и связанным идентификатором? |article-postfix=похоже, не удаляет неразрывное пространство. Меня это лично не особо интересует (поскольку кажется, что это было бы странно для нескольких идентификаторов и не соответствовало бы WP: CS1 и WP: CS2 ), но Дэвид Эппштейн, похоже, хочет такую ​​функциональность для {{ MR }}. Я ценю, что вы смотрите и комментируете такие вещи. Спасибо, Узуме ( разговор ) 23:32, 22 августа 2017 (UTC)

Выполнено. - Матиаспол ( разговор ) 00:58, 23 августа 2017 г. (UTC)

Я ценю это. Я |leadout=также замечаю, что пробелы. Есть ли решение этой проблемы или, возможно, было бы лучше, чтобы {{ MR }} не поддерживал |leadout=. Спасибо, Узумэ ( разговор ) 04:29, 23 августа 2017 (UTC)

Сделано тоже. Выглядит немного странно, но работает. На каком-то этапе в будущем шаблон, вероятно, будет преобразован в Lua. Это упростит повторную реализацию таких особых случаев, как этот. - Матиаспол ( разговор ) 11:19, 23 августа 2017 г. (UTC)

VDOS внесен в список редиректов для обсуждения [ править ]

Редактор попросил обсудить проблему перенаправления VDOS . Поскольку вы принимали участие в перенаправлении VDOS , вы можете принять участие в обсуждении перенаправления, если вы еще этого не сделали. � ( разговорное ) 15:19, 23 октября 2017 (UTC)

高 德納 в списке редиректов для обсуждения [ править ]

Редактор попросил обсудить проблему перенаправления高 德納. Поскольку вы принимали участие в перенаправлении高 德納, вы можете принять участие в обсуждении перенаправления, если вы еще этого не сделали. - T avix ^{( разговор )} 13:33, 24 октября 2017 г. (UTC)

Страница, которую вы открыли (Int. Symp. On Circuits and Systems), была рассмотрена! [ редактировать ]

Спасибо за создание Int. Symp. по схемам и системам , Матиаспол!

Редактор Википедии RileyBugz только что просмотрел вашу страницу и написал для вас следующую заметку:

Хотя я одобряю это, в следующий раз не могли бы вы сделать перенаправления в соответствии с ISO 4 ? Например, не включайте артикли и предлоги.

Чтобы ответить, оставьте комментарий на странице обсуждения RileyBugz .

Узнайте больше о курировании страниц .

RileyBugz^会話_投稿記録18:52, 28 октября 2017 (UTC)

RileyBugz , не стесняйтесь создавать перенаправления, соответствующие ISO 4, но я создал эти перенаправления на основе сокращений, используемых в ссылках, независимо от того, соответствуют ли они ISO 4 или нет. По сути, я делаю это, чтобы помочь сделать использование этих раздражающих / сбивающих с толку / неудобных сокращений устаревшими., поскольку они часто настолько загадочны, что большинство читателей не могут понять их без исследования. Поскольку Википедия - это не бумага, использование сокращенных названий журналов - анахронизм. Кроме того, наша MOS не рекомендует использовать сокращения, за исключением тех, которые, как ожидается, будут понятны каждому (или объяснены в статье) - сокращенные названия журналов среди них встречаются редко. Поэтому всякий раз, когда я сталкиваюсь с ними в ссылках, я заменяю их развернутой формой (то есть, если я могу расшифровать аббревиатуру) и создаю перенаправление (если оно еще не существует), чтобы улучшить поведение окна поиска в будущем. читатели, сталкивающиеся с той же проблемой в другом месте. Если вы считаете, что одни из таких переадресаций более "официальны", чем другие,не стесняйтесь отмечать необычные с помощью {{ R от неправильного названия}} или похожие.

Обычно я отвечаю там, где был начат разговор - или, в редких случаях, перемещаю всю цепочку в лучшее место (в этом случае я думаю, что лучшим местом была бы страница обсуждения перенаправления). Итак, если вы хотите, чтобы я отвечал где-нибудь еще, начните разговор с этого места и напишите мне.

- Матиаспол ( разговор ) 19:31, 28 октября 2017 г. (UTC)

Понятно! Поскольку ваши перенаправления кажутся полезными, я буду принимать их, когда наткнусь на них. RileyBugz^会話_投稿記録19:34, 28 октября 2017 (UTC)

Проверка новой страницы [ править ]

Добавлен рецензент новой страницы [ править ]

Привет, Матиаспол. Ваша учетная запись была добавлена ​​в группу New page reviewersпользователей, что позволяет вам просматривать новые страницы и отмечать их как проверенные , отмечать их для проблем с обслуживанием или, в некоторых случаях, отмечать их для удаления. Список статей, ожидающих рассмотрения, находится в ленте новых страниц . Обзор новых страниц - жизненно важная функция для контроля качества энциклопедии. Если вы еще этого не сделали, вы должны прочитать новое руководство в New Pages Review , связанные руководства и эссе и полностью понять различные критерии удаления . Если вам нужна дополнительная помощь или вы хотите обсудить процесс, присоединяйтесь или начните обсуждение в разговоре с рецензентом страницы .

• СРОЧНО : подумайте о том, чтобы как можно скорее сократить огромный объем невыполненной работы до приемлемого количества страниц.
• Будьте вежливы с новыми пользователями - они часто не подозревают, что делают что-то не так.
• Пользователи часто будут просить вас объяснить, почему их страница удаляется - относитесь к ним формально и вежливо, даже если это не так.
• Не просматривайте страницу, если не знаете, что делать. Просто оставьте это другому рецензенту.
• Помните, что качество является важнейшим условием хорошего патрулирования. Не торопитесь, чтобы патрулировать каждую статью, никакой спешки. Воспользуйтесь функцией сообщений и дайте базовый совет.

Право рецензента не влияет на ваш статус или на то, как вы можете редактировать статьи. Если вам больше не нужно это право пользователя, вы можете попросить любого администратора удалить его за вас в любое время. В случае злоупотребления или стойкой неточности обзора, право может быть отозвано в любой момент администратором. Алекс Ши ( разговорное ) 05:54, 29 ноября 2017 (UTC)

Speedy удаление Выдвижение UniBIT [ править ]

На Unibit был размещен тег с просьбой о его скорейшем удалении из Википедии. Это было сделано в соответствии с разделом A7 критериев быстрого удаления , потому что статья, похоже, посвящена компании, корпорации или организации, но не дает достоверных указаний на то, как и почему эта тема важна или значима: то есть, почему статья об этом предмете следует включить в энциклопедию. Согласно критериям быстрого удаления , такие статьи могут быть удалены в любое время. Пожалуйста, прочтите больше о том, что принято считать примечательным .

Если вы считаете, что эту страницу не следует удалять по этой причине, вы можете оспорить номинацию , посетив страницу и нажав кнопку с надписью «Оценить это быстрое удаление». Это даст вам возможность объяснить, почему вы считаете, что страницу не следует удалять. Однако имейте в виду, что если страница помечена для быстрого удаления, она может быть удалена без промедления. Пожалуйста, не удаляйте тег быстрого удаления со страницы самостоятельно, но не стесняйтесь добавлять информацию в соответствии с политиками и рекомендациями Википедии . Если страница удалена, и вы хотите восстановить удаленный материал для дальнейшего использования или улучшения, обратитесь к администратору удаления . Кольцо Whispe 05:14, 20 декабря 2017 (UTC)

Конечно, его не следует удалять, иначе я бы его не создал ... Перешел на страницу значений, чтобы охватить и другие значения. - Матиаспол ( разговор ) 19:16, 23 июля 2018 г. (UTC)

Службы защищенного режима DOS [ править ]

Привет, Матиаспол. Я вижу, что вы приняли некоторые из моих изменений и отклонили другие, но я не понимаю, почему. В нескольких случаях вы настаивали на сохранении издателя, на который ссылаются вики-ссылки, несмотря на рекомендации в Template: Cite journal # Publisher и Template: Cite book # Publisher .

Имя издателя; может быть добавлен вики, если уместно . Издатель - это компания, которая публикует цитируемую работу. Не используйте параметр издателя для названия работы (например, книга, энциклопедия, газета, журнал, журнал, веб-сайт). Обычно не используется для периодических изданий .

( мой акцент )

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

В конкретном случае « Academic Press, Inc. ( AP Professional )» вторая ссылка фактически является перенаправлением на первую. Ни одна из ссылок не дает читателю никакой пользы, но первая в любом случае избыточна.

(Кстати, параметры работы и веб-сайта являются синонимами - нет никакой разницы в том, как шаблон обрабатывает их.) Колонии Крис ( доклад ) 11:57, 4 января 2018 г. (UTC)

Извините за задержку, отвечу на следующей неделе. - Матиаспол ( разговор ) 12:13, 6 января 2018 г. (UTC)

Кодовая страница 777 [ править ]

Я нашел ссылку на нее, а где? - 2018-03-13T22: 04: 00 Alexlatham96

Если вы хотите создать для него статью, я бы предложил кодовую страницу 777 .

- Матиаспол ( разговор ) 21:21, 13 марта 2018 г. (UTC)

Шаблон: WP RFC внесен в список редиректов для обсуждения [ править ]

Редактор попросил обсудить шаблон перенаправления : WP RFC . Поскольку вы имели отношение к перенаправлению Template: WP RFC , вы можете принять участие в обсуждении перенаправления, если вы еще этого не сделали. {{3x | p}} ery ( talk ) 03:40, 27 марта 2018 г. (UTC)

В результате получился Keep . - Матиаспол ( разговор ) 19:16, 23 июля 2018 г. (UTC)

Предстоящие изменения в синтаксическом анализе викитекста [ править ]

Привет,

В течение следующих нескольких недель будут внесены некоторые изменения в способ анализа викитекста . Это повлияет на все пространства имен. Вы можете увидеть список страниц, которые могут отображаться некорректно в Special: LintErrors . Поскольку большинство простых проблем уже решены в англоязычной Википедии, я специально обращаюсь к технически подкованным редакторам, таким как вы, с этим разовым сообщением в надежде, что вы сможете изучить оставшиеся высокоприоритетные страницы в течение в следующем месяце.

Существует около 10 000 статей (и еще много страниц, не относящихся к статьям) с высокоприоритетными ошибками. Наиболее важными из них являются статьи с неверно вложенными тегами и проблемами с таблицами . Некоторые из них связаны с шаблонами, такими как информационные блоки, или с тем, как шаблон используется в статье. В некоторых случаях «ошибка» - это незначительное, несущественное различие во внешнем виде. В остальных случаях результаты нежелательны. Вы можете увидеть сравнение любой статьи до и после, добавив? Action = parsermigration-edit в конец ссылки, например: https://en.wikipedia.org/wiki/Arthur_Foss?action=parsermigration-edit (который показывает разницу в том, как анализируется {{ infobox ship }}).

Если вы заинтересованы в помощи в этом проекте, см. Википедию: ЛИНТЕР . Также есть несколько основных инструкций (и ссылки на дополнительную информацию) на https://lists.wikimedia.org/pipermail/wikitech-ambassadors/2018-April/001836.html. Вы также можете оставить заметку на WT: Linter, если вы есть вопросы.

Спасибо вам за все хорошее, что вы делаете для английской Википедии. Whatamidoing (WMF) ( обсуждение ) 21:18, 19 апреля 2018 (UTC)

7400 серия [ править ]

Что касается этой правки , есть ли у вас источник за 1968 год? - РойСмит (разговор) 19:58, 18 июня 2018 г. (UTC)

Привет, Рой, я добавил ссылку на книгу приложений Philips, датированную маем 1968 года (очевидно, первое издание - также было четвертое издание в 1974 году).

- Матиаспол ( разговор ) 20:39, 18 июня 2018 г. (UTC)

Спасибо. Теперь следующая проблема заключается в том, что я даже не уверен, что NORBIT был TTL. Фактически, это в значительной степени означает, что это не так. Я бы хотел, чтобы вы подали 240 В переменного тока на вход TTL, и не вышел весь волшебный дым :-)

Я не думаю, что семейство NORBIT 2 (1967) было TTL. Я добавил их больше для схожести случаев, чем для того, чтобы быть TTL, но снова удалил их. Первоначальные НОРБИТЫ 1960-х были RTL (некоторые DTL). - Матиаспол ( разговор ) 08:29, 21 июня 2018 г. (UTC)

Линия сращивания указана в разделе "Перенаправления" для обсуждения [ править ]

Редактор попросил обсудить проблему сращивания линии перенаправления . Поскольку вы принимали участие в перенаправлении соединения линии , вы можете принять участие в обсуждении перенаправления, если вы еще этого не сделали. Pam D 21:18, 18 июня 2018 г. (UTC)

Сохранил и превратил в статью мной. - Матиаспол ( разговор ) 19:16, 23 июля 2018 г. (UTC)

Электрические соединения перечислены в разделе "Перенаправления" для обсуждения [ править ]

Редактор попросил обсудить перенаправление электрического сращивания . Поскольку вы принимали участие в перенаправлении электрического монтажа , вы можете принять участие в обсуждении перенаправления, если вы еще этого не сделали. Pam D 21:19, 18 июня 2018 г. (UTC)

В результате получился Keep . - Матиаспол ( разговор ) 19:16, 23 июля 2018 г. (UTC)

Пара металлов указана в редиректах для обсуждения [ править ]

Редактор попросил обсудить пару перенаправлений Metal . Поскольку вы принимали участие в перенаправлении пары Metal , вы можете принять участие в обсуждении перенаправления, если вы еще этого не сделали. Pam D 21:24, 18 июня 2018 г. (UTC)

Сохранено и изменено на страницу значений, чтобы охватить еще больше значений. - Матиаспол ( разговор ) 19:16, 23 июля 2018 г. (UTC)

Автопатруль сломан [ править ]

Имейте в виду, что права пользователя на автоматическое патрулирование нарушены, поэтому новые статьи таких редакторов, как я, появляются в последних изменениях, а не должны. Похищение ( рассуждение ) 09:39, 30 июня 2018 г. (UTC)

Спасибо, что сообщили мне об ошибке. К сожалению, было бы непрактично сначала проверять права каждого редактора перед просмотром страницы. Надеюсь, ошибка скоро будет исправлена. Спасибо и привет. - Матиаспол ( разговор ) 13:22, 30 июня 2018 г. (UTC)

Re " Делай то, что я имею в виду ":

Спасибо за обзор. Мне уже давно ничего не нужно было пересматривать, это следствие создания новой страницы? В таком случае, почему мы идем назад с точки зрения дополнительной работы, когда авторевьюеры раньше не требовали проверки? Widefox ; разговор 09:39, 30 июня 2018 (UTC)

Привет, Widefox , как вы оба писали одновременно, возможно, вы не видели записку Абдуктива. Очевидно, это связано с недавней ошибкой - очевидно, я не проверял права пользователя перед просмотром страниц, немного помогая в NPP. (См. Википедию: Деревенский насос (технический) # Проблема с автопатрулем? )

Всего наилучшего, Матиаспол ( обсуждение ) 13:22, 30 июня 2018 г. (UTC)

Re " Председатель Китая ":

Я WP: APAT . Вам не нужно было просматривать эту страницу. Сконцентрируйтесь на тех сотнях новых страниц, которые действительно нуждаются в рецензировании. Нарки Блерт ( разговор ) 21:13, 30 июня 2018 (UTC)

Я делаю. См. Выше. ;-) - Матиаспол ( разговор ) 21:16, 30 июня 2018 (UTC)

Повторное "рассмотрение" редиректов:

Это действительно необходимо? Я получаю много уведомлений о переадресации и других мелочах, не относящихся к содержанию, которые были проверены , и это не похоже на то, что это дает что-то полезное. Я не уверен, какой из этих процессов проверки их генерирует. Вы можете уточнить?  -  SMcCandlish ☏ ¢  😼  21:25, 30 июня 2018 г. (UTC)

Пожалуйста, прочтите выше (и перейдите по ссылкам) для дальнейших объяснений. Это вызвано недавней ошибкой, которая, надеюсь, будет исправлена ​​через пару дней. Непрактично проверять права каждого пользователя перед просмотром страницы, поэтому все, что попадает в очередь, будет проверяться независимо от того, кто ее создал. В настоящее время существует накопитель невыполненных работ на АЭС, сводящий очередь к нулю. - Матиаспол ( разговор ) 21:33, 30 июня 2018 г. (UTC)

Автопатроллинг разрешен [ править ]

Привет, Матиаспол! Я просто хотел сообщить вам, что я добавил к вашей учетной записи разрешение «с автоматическим патрулированием », поскольку вы создали множество действительных статей. Эта функция не повлияет на ваше редактирование и просто предназначена для уменьшения нагрузки на новые патрульные страницы . Для получения дополнительной информации о праве с автоматическим патрулированием см. Wikipedia: Autopatrolled . Не стесняйтесь оставлять мне сообщение, если у вас есть какие-либо вопросы. Удачного редактирования! ~ Амори ( u • t • c ) 16:43, 30 июня 2018 г. (UTC)

Большое спасибо. Как только вышеупомянутая ошибка будет исправлена, я надеюсь, что это поможет несколько снизить рабочую нагрузку на других новых патрульных ... - Матиаспол ( разговор )

Благодарность за накопление невыполненных работ на АЭС [ править ]

Спасибо. - Матиаспол ( разговор ) 09:33, 1 июля 2018 г. (UTC)

PDP-10 [ править ]

PDP-10 имел двоичную систему с плавающей запятой, а не систему счисления 8, как утверждает ваша редакция. Кроме того, я не верю, что «восьмеричная числа с плавающей запятой» - стандартное название для «плавающей запятой с основанием 8». См., Например, [21] . Я вижу, что в книге « Справочник по арифметике с плавающей запятой» утверждается, что используется система счисления 8, но это неверно. Надеюсь, что другие не повторяли эту ошибку. - Макракис ( разговор ) 22:45, 17 июля 2018 г. (UTC)

Привет, Ставрос, если PDP-10 действительно не поддерживал восьмеричный режим с плавающей запятой, жаль, что авторы не исправили его в (ссылка выше) новом издании книги, которое было опубликовано всего через пару недель. назад. Мне нужно было посмотреть только предыдущее издание, и в нем уже указаны DEC PDP-10, а также Burroughs 570 и 6700. Savard перечисляет Atlas и Burroughs B5500.

- Матиаспол ( разговор ) 23:23, 17 июля 2018 г. (UTC)

Я согласен. Я отправил автору письмо. - Макракис ( разговор ) 02:05, 18 июля 2018 г. (UTC)

Отлично. - Матиаспол ( разговор ) 06:48, 19 июля 2018 г. (UTC)

Оказалось, что в источнике Burroughs 570 тоже была опечатка. Машина на самом деле называлась Burroughs B5700 (около 1971 г.). - Матиаспол ( разговор ), 12:02, 7 декабря 2019 г. (UTC)

Перенаправления по имени сортировки [ править ]

Что касается редиректов, таких как Cowlishaw, Mike Frederic и Cowlishaw, Micheal Frederic , fyi, пожалуйста, ознакомьтесь с последними изменениями в документации по шаблону .  Пэйн Эллсворт отправился туда 06:41, 19 июля 2018 г. (UTC)    

Спасибо за внимание, Пейн. Я не знал об этих дополнительных параметрах. - Матиаспол ( разговор ) 06:48, 19 июля 2018 г. (UTC)

Это приятно, и спасибо вам за работу на переадресовывает, Matthiaspaul ! bd2412, и я только что закончил работу, необходимую для разделения громоздких категорий «Категория: перенаправления из имен сортировки» и « Категория: перенаправления из неоднозначных имен сортировки» , поэтому следовало ожидать, что редакторы не будут знать об изменениях.  Пэйн Эллсуорт прибыл туда 08:40, 19 июля 2018 г. (UTC)    

Серия E [ править ]

Матиас, поскольку вы отменили мой шаг по удалению дефиса в E-серии предпочтительных чисел , я еще немного искал источники, чтобы узнать, поддержат ли власти этот странный дефис по сравнению с обычными английскими правилами пунктуации. Я нашел один стандарт, который говорит о том, что я был прав: IEC 60063 . И нет недостатка в других вариантах использования без нечетной запятой: [22] , [23] , [24] . Дефис имеет смысл в таких вещах, как «числа серии E» или «предпочтительные числа серии E», где составное существительное «серия E» используется в качестве модификатора, но не иначе (хотя многие источники ошибаются, я согласны). Что вы думаете о том, почему это было «правильно»?с дефисом? Диклион ( разговор) 16:02, 23 июля 2018 г. (UTC)

Привет, Дик, это кажется трудным. Я нахожу множество источников, использующих его в любом случае, включая Nikon F-Mount ( [25] ). Хотя бывают случаи, когда следует избегать дефиса, и случаи, когда его нужно использовать, также, похоже, есть золотая середина, где нет четкого правильного или неправильного, и это зависит от предпочтений (или, возможно, традиционных против современного английского, не знаю).

«Серия E» и «Серия E» кажутся одним из таких примеров: для меня опускание дефиса здесь выглядит ужасно неправильным (как жирная опечатка), и требуется некоторое время, пока случайная буква «E» не будет мысленно связана с «серия», чтобы образовать составное существительное - полностью разрушая поток. (Но не так для «книжных серий», где я был бы с вами, чтобы избежать дефиса, если он не используется в качестве модификатора.) Думая о том, почему это так, мое чутье подсказывает мне, что это должно быть либо потому, что «серия E» - это довольно необычное (составное) существительное или потому, что "Е" очень короткое. Можно ли вообще "E" считаться словом? Проверяя, например, это руководство ( [26] ), принимая «E» как слово, использование дефиса, похоже, регулируется Правилом 2b (« При написании нового, оригинального,или необычные составные существительные, писатели должны ставить дефис во избежание путаницы.") Однако, учитывая, что" E "является своего рода префиксом, сокращением, усечением, цифрой или буквой, далее вниз по Правилу 1 (" Расставляйте префиксы, когда они идут перед именами собственными или собственными прилагательными ") или Правилом 6 (" Писатели часто переносят префиксы, когда они считают, что слово может отвлекать или сбивать с толку без дефиса "), похоже, применимы. С другой стороны, использование" серии E "в стандарте, безусловно, тоже хороший аргумент, но опять же, похоже, что это не так. на выбор писателя.

- Матиаспол ( разговор ) 19:01, 23 июля 2018 г. (UTC)

Я не уверен, почему вам кажется неправильным опускать дефис; может потому что это так непохоже было бы сделано на немецком? Это довольно стандартный английский, как и в определяющих источниках. У такого дефиса нет нормальной роли, если соединение не используется в качестве модификатора. То же самое с креплением F; большинство книг это правильно понимают. Для серии E это несложно; определяющий источник следует обычным правилам грамматики английского языка, как и некоторые источники; тот факт, что некоторые также добавляют ложный дефис, не должен нас смущать. Диклион ( разговорное ) 20:52, 24 июля 2018 (UTC)

Если вы уверены, верните его обратно. Если нет, дайте мне знать, и я начну обсуждение RM. Диклион ( разговорное ) 23:18, 24 июля 2018 (UTC)

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

- Матиаспол ( разговор ) 18:26, 7 августа 2019 г. (UTC)

Страницы значений неоднозначности [ править ]

Привет, Матиаспол. Когда вы переместили T-Series на новый заголовок, а затем изменили старый заголовок с перенаправления на страницу с разрешением неоднозначности , вы, возможно, не знали о WP: FIXDABLINKS , в котором говорится:

При создании страниц значений неоднозначности исправляйте все возникающие неверно направленные ссылки.

Перед перемещением статьи на квалифицированное имя (чтобы создать страницу значений неоднозначности на основе базового имени, переместить существующую страницу значений неоднозначности на это имя или перенаправить это имя на страницу значений неоднозначности), нажмите « Какие» ссылки здесь, чтобы найти все входящих ссылок. Восстановите все входящие ссылки, чтобы использовать новое название статьи.

Было бы большим подспорьем, если бы вы проверили другие статьи Википедии, которые содержат ссылки на «T-Series», и исправили их, чтобы привести читателей к нужной статье. Спасибо. - R'n'B ( зовите меня Расс) 10:05, 25 июля 2018 г. (UTC)

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

Сегодня с помощью Вивека Рэя мы исправили ссылки (приблизительное предположение: около 900). Осталось еще одно включение в серию T, для которого я не смог найти источник. Было бы здорово, если бы вы могли разобраться в этом. - Матиаспол ( разговор ) 19:21, 25 июля 2018 г. (UTC)

Пожалуйста, разместите пример «удаленной информации» для таблиц набора символов [ править ]

Я оставил открытым вопрос о том, какая информация была уничтожена в Talk: ASCII и TALK: ISO-8859-1, и вы так и не ответили. Пожалуйста, перейдите на user talk: spitzak и обсудите это, а не просто скажите «консенсуса не было». Шпицак ( разговор ) 19:56, 23 сентября 2018 (UTC)

ISO-8859-1 был возвращен и отредактирован с несколькими шагами к предлагаемой новой версии. Пожалуйста, проверьте это. Также были отменены ISO-8859-2 и ISO-8859-3 и применены изменения поля и орфографии, но оставлены десятичные числа. Это проще, чем я, хотя удалить десятичные числа, их не нужно удалять. Это сделало бы возврат с сохранением правок намного проще. Шпицак ( разговор ) 04:59, 25 сентября 2018 (UTC)

Теперь я обновил EBCDIC, добавив довольно утомительное воспроизведение всего редактирования, которое я делал раньше, оставив удаление десятичных чисел напоследок. Пожалуйста, взгляните! Шпицак ( разговор ) 06:58, 26 сентября 2018 (UTC)

Редактировать войну в OrCAD [ править ]

Вам действительно следует воздерживаться от разногласий при редактировании, поскольку вы работаете в OrCAD . Toddst1 ( разговор ) 22:21, 19 октября 2018 (UTC)

Войны редактирования не было, просто два редактора пытались удалить важную часть статьи, а двое других пользователей по праву восстанавливали предыдущее состояние. - Матиаспол ( разговор ) 21:26, 4 августа 2019 г. (UTC)

Re: награды Codie [ править ]

Большое спасибо! Прошло много времени с тех пор, как я в последний раз получал одну из них. Codie / SIIA - важная тема, и я просто рад, что она в некоторой степени освещена в Википедии. JimmyBlackwing ( разговорное ) 23:01, 6 ноября 2018 (UTC)

Ты это заслужил. :-) - Матиаспол ( разговор ) 18:26, 7 августа 2019 (UTC)

PC Magazin внесен в список редиректов для обсуждения [ править ]

Редактор попросил обсудить вопрос о перенаправлении журнала PC Magazin . Поскольку вы имели какое-то отношение к перенаправлению PC Magazin , вы можете принять участие в обсуждении перенаправления, если вы еще этого не сделали. Headbomb { t · c · p · b } 15:11, 6 декабря 2018 г. (UTC)

Договорились удалить редирект во избежание путаницы. German PC Magazin не имеет отношения к английскому PC Magazine.

- Матиаспол ( разговор ) 18:26, 7 августа 2019 г. (UTC)

Кау ман (значения) внесен в список редиректов для обсуждения [ править ]

Редактор попросил обсудить вопрос о перенаправлении Каумен (значения) . Поскольку вы имели какое-то отношение к перенаправлению Каумен (значения) , вы можете принять участие в обсуждении перенаправления, если вы еще этого не сделали. ~ GB fan 17:02, 11 января 2019 г. (UTC)

Результатом было сохранение и корректировка редиректа. - Матиаспол ( разговор ) 21:26, 4 августа 2019 г. (UTC)

Луис Филипе Виейра [ править ]

Вы вернули меня и написали: «Восстановлены параметры даты доступа. Это желаемая информация в цитате с URL-адресом».

В документации по шаблону этого не говорится. SLBedit ( обсуждение ) 16:42, 11 февраля 2019 (UTC)

Привет, SLBedit. Так оно и есть, возможно, не по слову, а по значению (согласно давнему консенсусу сообщества). Как становится ясно из Help_talk: Citation_Style_1 # access-date, вы читаете в нем что-то, чего там нет, ссылки почти никогда не бывают стабильными в долгосрочной перспективе (десятилетия). К сожалению, это относится даже к так называемым «постоянным реферерам» (поэтому некоторые пользователи считают дату доступа для них неактуальной). Таким образом, дата доступа актуальна почти всегда, когда цитируется ссылка на некоторое онлайн-содержимое, чтобы помочь нашему WP: Vполитика. Если ссылка когда-либо рискует стать мертвой в долгосрочной перспективе или содержимое под ней может измениться (что может произойти для PDF-файлов так же легко, как и для HTML), важна дата доступа, потому что без информации, когда цитата была (по-прежнему) признана надежной поддержкой утверждения, цитирование и, следовательно, также заявление в статье подвергаются гораздо более высокому риску быть оспоренным и удаленным. Если подумать, вся неосновная информация в Википедии может быть удалена через пару десятилетий, поэтому большая часть нашей тяжелой работы по сохранению истории и созданию надежной энциклопедии будет бесполезным занятием. Следовательно, параметр даты доступа очень важен для защиты нетривиальной информации.

Однако я согласен с вами, что документация по шаблону должна быть более ясной по этому поводу.

- Матиаспол ( разговор ) 18:35, 11 февраля 2019 г. (UTC)

ЗАДАЧА [ править ]

Я бы посоветовал вам использовать шаблон: в стадии разработки, пока вы улучшаете статью, поскольку ваше явно заметное резюме , скорее всего, будет протестировано в AfD, если оно не на месте. Для некоторых претензий могут потребоваться независимые ссылки. Спасибо. Djm-leighpark ( разговор ) 20:11, 11 февраля 2019 (UTC)

Нет необходимости в том, что источники не IMO достаточно хорошо для WP: ГНГ и т.д. - Matthiaspaul ( разговор ) 21:26, 4 августа 2019 (UTC)

Забастовка школьников за климат [ править ]

Привет, я видел на странице Ende Gelände 2018, что вы сделали немецкий перевод, и надеялся, что вы можете помочь с некоторыми короткими цитатами, чтобы прояснить обоснованность ссылок на странице школьной забастовки за климат, которые были получены из немецких СМИ. Я сделал пару из французских СМИ, хотя мой французский очень трепетный, что требовало простого добавления предложения в кавычки = ref на английском языке, подтверждающих количество забастовщиков. Любая помощь очень ценится. BorisAndDoris ( разговор ) 22:27, 17 февраля 2019 (UTC)

Спасибо за вклады на главной странице и пояснения на странице обсуждения. Оба были очень полезны. BorisAndDoris ( разговор ) 09:56, 18 февраля 2019 (UTC)

Спасибо за восстановление см. Также с объяснением. NewsAndEventsGuy ( обсуждение ) 00:54, 18 марта 2019 (UTC)

Удовольствие. - Матиаспол ( разговор ) 01:27, 18 марта 2019 г. (UTC)

Привет, Матиаспол,

Я видел, что вы один из главных редакторов « Греты Тунберг» . Учитывая ваш интерес к статьям, связанным с изменением климата, я приглашаю вас взглянуть на Wikipedia: WikiProject Environment / Climate change Task Force . Некоторое время он был неактивным, но я твердо верю, что в этой теме должна быть активная группа сотрудничающих редакторов, которые будут помогать друг другу критическим взглядом. Если вы хотите внести свой вклад, добавьте свое имя в раздел участников, добавьте задачу в список дел или помогите сделать список дел немного короче.

Фемке Нейссе ( разговор ) 19:56, 14 мая 2019 (UTC)

Префиксы IEC [ править ]

В 1024 году добавленное вами утверждение вводит в заблуждение. Даже в технических компьютерных журналах KiB и Kib редко используются (возможно, потому, что числа до 1024 встречаются редко). Возможно, нам удастся найти достоверное и не вводящее в заблуждение утверждение. («Текущее» заявление вводит в заблуждение, поскольку подразумевает, что есть время, до или после 2009 г., когда соглашение об использовании было принято в целом.) - Артур Рубин (доклад) 20:13, 9 марта 2019 г. (UTC)

Привет, Артур, я не добавил заявление, но удалил его, потому что считаю, что оно подталкивает определенную точку зрения и рекомендацию не использовать соглашение, то есть это не нейтрально.

ИМО, мы должны полностью удалить это предложение, потому что в противном случае мы откроем банку с червями. Чтобы быть нейтральными, мы должны обсудить принятие стандарта и найти источники, поддерживающие и не одобряющие его. Это действительно того стоит? ИМО, в контексте этой статьи проще просто описать, что соглашение существует как стандарт (потому что это нейтральный и неоспоримый факт), и предоставить читателю сделать свои выводы и либо использовать, либо не использовать его. Если читателя интересует дополнительная информация, он / она найдет это в двоичном префиксе - статье, на которую мы уже ссылаемся.

Однако, поскольку вы прочитали, что IMO является заявлением POV, я попытался хотя бы смягчить его и соответствовать тому, что на самом деле говорится в ссылке. Я добавил «2009», потому что ссылка не может быть использована для описания чего-либо после этого года. Принятие стандартов - медленный процесс, поэтому неудивительно, что они вообще не были приняты ни в 2009 году, ни сейчас. Подумайте о ISO 8601, который является официальным форматом даты в нескольких европейских странах с 1990-х годов. Хотя сейчас он используется гораздо чаще, чем в прошлом, его общее внедрение все еще продолжается - но это просто нормально, а не является признаком «неудавшегося» стандарта или чего-то подобного.

Вот почему я думаю, что было бы улучшением статьи удалить это предложение без замены. Но если вы не можете согласиться с этим и найти формулировку, которая поддерживается ссылкой и не подразумевает, что соглашение лучше не использовать, потому что это будет «неудавшийся стандарт» и «никто не использует его» (потому что это не правда), пожалуйста.

Кстати, просто чтобы у вас не сложилось неправильное впечатление, я тоже не являюсь особенным поклонником внешнего вида этого соглашения, но я принимаю тот факт, что абсолютно необходимо иметь какое-то простое в использовании соглашение, чтобы выражать двоичные префиксы по-разному. от десятичных префиксов, и поэтому я приветствую существование стандарта - вместо чего-то лучшего можно использовать его вместо того, чтобы продолжать злоупотреблять десятичными префиксами и вызывать неоднозначность. (Тем не менее, лично я предпочитаю использовать B-нотацию, где это возможно, то есть 1024 = 1B10.)

- Матиаспол ( разговор ) 22:18, 9 марта 2019 г. (UTC)

Я понимаю вашу точку зрения. Поскольку предыдущее предложение обозначено как «придумано», а не «предложено» или «принято», пояснение кажется ненужным. Существуют и другие контексты, в которых МЭК вообще не следует упоминать, поскольку точная и не вводящая в заблуждение формулировка может оказаться невозможной. - Артур Рубин (разговор) 22:36, 9 марта 2019 г. (UTC)

Отлично, теперь мне нравится. Спасибо. - Матиаспол ( разговор ) 09:54, 10 марта 2019 г. (UTC)

Запрошены данные относительно диаграммы регистров HP Saturn [ править ]

Здравствуйте :) Обновил диаграмму регистров ЦП HP Saturn на странице ЦП HP Saturn . Сначала я пытался получить желаемый вид с помощью вики-разметки, но отказался от этого. Затем я создал диаграмму SVG с миниатюрой PNG. Мне пришлось удалить вашу диаграмму реестра, так как я не мог ее должным образом прокомментировать. Если у вас есть какие-либо предложения по поводу того, что вы хотите включить в новую диаграмму, я все слышу :) Файл SVG находится на Викискладе, так что вы можете отредактировать его самостоятельно, если хотите :) Jdbtwo ( talk ) 15:32, 29 апреля 2019 (UTC)

Обсуждение проходило на странице обсуждения Артиса.

- Матиаспол ( разговор ) 18:26, 7 августа 2019 г. (UTC)

Я не просмотрел страницу, которую вы курировали [ редактировать ]

Спасибо за обзор Матиаса Пола (актера) , Матиаспола.

Болейн снова просмотрел эту страницу и пометил ее как непроверенную. Их примечание:

Вроде автобиография - нереальная биография живого человека.

Пожалуйста, свяжитесь с Болейном для любых дальнейших вопросов. Спасибо.

Сообщение доставлено с помощью инструмента курирования страницы от имени рецензента.

Болейн ( разговорное ) 06:53, 9 июня 2019 (UTC)

Статья, которую вы недавно создали, Матиас Пол (актер) , не имеет достаточного количества источников и цитат, чтобы ее можно было опубликовать. Она нуждается в большем количестве цитат из надежных , независимых источников . ( ? ) Информация, на которую нельзя ссылаться, должна быть удалена ( проверяемость имеет центральное значение в Википедии). Я переместил ваш черновик в область черновика (с префиксом " Draft:" перед названием статьи), где вы можете инкубировать статью с минимальными нарушениями. Когда вы чувствуете, что статья соответствует общему руководству Википедии о известностии, таким образом, готов к использованию в основном пространстве, нажмите "Отправить свой черновик на рассмотрение!" кнопку вверху страницы. Болейн ( разговорное ) 06:53, 9 июня 2019 (UTC)

Я написал статью, но не рецензировал ее. Это был перевод статьи в немецком WP (на который нет ссылок, но он был стабильным в течение многих лет и не содержал никаких утверждений, которые нельзя было бы подкрепить источниками в Интернете).

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

- Матиаспол ( разговор ) 17:37, 3 августа 2019 г. (UTC)

Вам действительно не следовало переносить это в основное пространство без независимой проверки кем-то, не имеющим отношения к теме. Praxidicae ( разговор ) 17:27, 10 июня 2019 (UTC)

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

- Матиаспол ( разговор ) 17:37, 3 августа 2019 г. (UTC)

Информационный бюллетень New Page Review, июль-август 2019 г. [ править ]

Доставка сообщений MediaWiki ( обсуждение ) 04:38, 30 июня 2019 г. (UTC)

Случайный пинг [ править ]

Привет, извините за беспокойство. Вы отредактировали обсуждение удаления (а именно это ), но по какой-то причине меня вызвали ... Есть идеи, почему это так? Я вообще не вижу упоминания в разнице. Я понимаю, что прокомментировал обсуждение, но обычно мне нравится отвечать на все запросы, но я понятия не имею об этом. С наилучшими пожеланиями, Ли Виленски ^{( обсуждение • вклад )} 16:49, 2 июля 2019 г. (UTC)

Привет, Ли, как ты уже правильно понял, я не звонил тебе. У меня нет реального объяснения того, почему вас пингуют, но я исправил некоторые отступы / форматирование в потоке, возможно, это заставило систему предположить, что вам нужно будет пинговать, я не знаю. Привет,

- Матиаспол ( разговор ) 16:59, 2 июля 2019 г. (UTC)

GOOGL (NASDAQ) внесен в список редиректов для обсуждения [ править ]

Редактор попросил обсудить проблему перенаправления GOOGL (NASDAQ) . Поскольку вы имели отношение к перенаправлению GOOGL (NASDAQ) , вы можете принять участие в обсуждении перенаправления, если хотите. _{ZXCVBNM ( РАЗГОВОР )} 14:19, 20 июля 2019 (UTC)

Ищу ссылки на S / DOS [ править ]

Здравствуй! В статье PTS-DOS вы упомянули «Source DOS» под названием S / DOS 1.0 и сказали, что это «открытый исходный код», есть ли у вас ссылки на это? Я нашел документ FreeDOS, в котором упоминается Source-DOS и говорится, что исходный код распространяется, но ничего не говорится о его природе «с открытым исходным кодом». Мне эта история очень интересна, и я ищу дополнительную информацию по этой теме. :-) - Илвикц ( разговор ) 23:58, 6 августа 2019 г. (UTC)

S / DOS 1.0 можно найти на красном компакт-диске Paragon, содержащем двоичные файлы PTS-DOS 6.51CD. Это изображено в статье. S / DOS был открытым, но, тем не менее, коммерческим продуктом. Вы должны были купить его, чтобы использовать или изменить, и это было только для личного использования.

S / DOS была в основном урезанной версией PTS-DOS с отсутствующими некоторыми компонентами. Он был написан на ассемблере и имел довольно лаконичные комментарии. Изучая исходные коды, можно было увидеть, что ему не хватало большой доработки и не учитывались многие особые случаи, реализованные в других DOS, и поэтому он не будет хорошо работать с плохо работающими программами или на менее совместимых машинах. Я также видел довольно много реальных ошибок в исходном коде, и он не очень хорошо поддерживал многоуровневую модель (например, некоторые вызовы BIOS в инструментах вместо вызовов DOS). В связи с этим я бы не рекомендовал его в качестве учебного пособия. С другой стороны, он был очень эффективным с точки зрения памяти, а также имел несколько приятных уникальных функций.

(Кстати. Тот старый документ FreeDOS, который вы упомянули, не точен в некоторых деталях.)

- Матиаспол ( разговор ) 00:55, 7 августа 2019 г. (UTC)

Поскольку вы слишком заняты преследованием других редакторов ... истоки вашей «священной войны» форматирования [ править ]

Все началось с этого редактирования здесь одним пользователем, Пользователь: TreyHarris , на 18:04, 21 января 2006. Поскольку я проделал всю эту работу за вас , почему бы вам не закончить задачу, показав мне длительные обсуждения, приведшие к WP: NOTBROKEN , WP: NOPIPE и MOS: NOPIPE ? Удачи в твоих будущих ... эээ, начинаниях! Bumm13 ( разговорное ) 21:54, 16 августа 2019 (UTC)

Пожалуйста, уберите полосу с глаз. Я мог бы быть посланником ( [27] [28] [29] ), но я не ваш враг. Ваши правки нарушают наши установленные правила WP: NOTBROKEN , WP: NOPIPE и MOS: NOPIPE в течение многих лет. Поскольку это наносит ущерб проекту, его необходимо остановить. Просто как тот. Обсуждение происходит на вашей странице обсуждения: User_talk: Bumm13 # "Formatting_fix"

- Матиаспол ( разговор ) 01:11, 17 августа 2019 г. (UTC)

Что касается записей, редактор решил заархивировать обсуждение через 80 минут после последнего сообщения ( [30] [31] ). Будем надеяться, что теперь он, наконец, скорректирует свое поведение, чтобы каждый мог продолжать создавать энциклопедию.

- Матиаспол ( разговор ) 13:35, 18 августа 2019 г. (UTC)

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

Мое редактирование, «создавшее» это руководство, было 13 лет назад, так что я не могу точно вспомнить, но я точно знаю, что перед его добавлением это обсуждалось в IRC достаточно подробно; В то время IRC-канал #wikipedia был очень активен и обычно считался хорошим местом для обмена идеями с людьми, если вы опасались быть смелым . Но тогда определенно было не так, чтобы такое небольшое дополнение к политике прошло через такой процесс, как сегодня.

Это редактирование было сделано в то время, когда самой большой проблемой для редакторов была очистка. Википедия стала достаточно большой, чтобы стать жизнеспособным справочником, заменяющим другие традиционные справочные материалы, но надежность была реальной проблемой. Были добавлены такие механизмы, как патрулирование, и изменена политика цитирования. И в результате общий набор правок быстро изменился.

До этого большинство правок в пространстве имён статей было добавлением фактического (или похожего на факты) материала, за которым следовали редактирующие правки, за которыми следовали изменения формулировок, за которыми следовали административные правки (категоризация, управление шаблонами и т. Д.). Но все изменилось, когда цитаты стали чем-то, что, как сообщество, мы решили включать по умолчанию с новыми фактическими правками, а не просто «когда факт может быть неожиданным или поставленным под сомнение» или «когда кто-то добавил« необходима цитата » ».

И результирующий набор правок был сильно изменен: теперь на копируемые правки - особенно на чистку, категоризацию и цитирование - приходилась львиная доля правок. У этого было два важных ответвления:

1. Был поток редакторов, желающих «вмешаться» в эту инициативу по очистке, и многие взяли на себя определенные повторяющиеся задачи, которые им нравились: исправление орфографических ошибок, проверка правильности форматирования цитат, добавление цитат к существующим материалам и т. Д. сосредоточенные на определенных видах правок во всей Википедии, а не на конкретных предметных областях, списки наблюдения не были столь полезны для их отслеживания.
2. Теперь патрульным пришлось иметь дело с этим новым потоком мелких правок.

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

Это было особенно важно для правок, которые можно было автоматизировать; ботам требовалось разрешение (в то время, может быть, только тогда, когда они превышали определенную скорость редактирования? Я не помню), но их исходный код не подвергался тщательной проверке, поэтому некоторые иногда вносили нежелательные изменения, которые не были обнаружены при чтении описаний их авторов их или просмотр результатов небольшой выборки правок.

Все это объясняет мотивацию: в стремлении уменьшить количество правок, увеличивающих объем работы, без особой ценности очистки энциклопедии, почти самым низким из низко висящих плодов были правки для «исправления» перенаправляющих ссылок. (Вероятно, более бесполезными были только правки, стандартизирующие количество пробелов после каждого предложения в статье.) Они загрязняли списки наблюдения, списки патрулей и все остальные списки редактирования между статьями.

Редакторам не требовалось никаких знаний о предмете статьи, чтобы «исправить» переадресацию ссылки. Но последующим редакторам, если они не были знакомы с предметом статьи, их было бы трудно быстро понять. Редактирование, которое было описано как просто ссылка на исправление и дельта которого была, [[plane change]] → [[orbital inclination change|plane change]]может быть опубликовано почти без усилий, но может потребоваться минута или две исследования, чтобы выяснить, хорошее ли это изменение или нет - если вы не знали, что это был перенаправлением на другой.

Таков был контекст этого дополнения к политике: перед лицом нового и постоянно увеличивающегося объема исправлений для очистки укажите, что этот конкретный тип редактирования, который выполнялся оптом, просто создавал работу почти без всякой выгоды.

Я надеюсь, что этот исторический контекст будет вам полезен. TreyHarris ( разговорное ) 18:39, 5 октября 2019 (UTC)

(ps Я полагаю, честно говоря, я должен отметить User: Bumm13 обратно, так как именно упоминание - вот что привело меня сюда. TreyHarris ( разговор ) 18:55, 5 октября 2019 (UTC))

А также потому, что именно он нарушает WP: NOTBROKEN , WP: NOPIPE и MOS: NOPIPE в течение многих лет, как было указано во многих старых обсуждениях мной и другими редакторами за эти годы. То, что он открыл грязную ветку на моей странице, в то время как его проблемное поведение обсуждалось на его странице обсуждения, было всего лишь попыткой привлечь внимание в другом месте.

Хотя я не думаю, что это удовлетворит Bumm13 (потому что он думает, что все равно может игнорировать наши рекомендации), спасибо за небольшую «историческую» перспективу происхождения этого давно установленного правила. - Матиаспол ( разговор ) 19:57, 6 октября 2019 г. (UTC)

просто любопытно ... [ править ]

привет, спасибо за вашу работу над исходниками и форматированием в Грете Тунберг. Просто любопытно, как вы думаете, почему мы должны использовать один формат даты в теле, а другой в ссылках? Меня не волнует, что мы используем, но переходить туда и обратно сложно. NewsAndEventsGuy ( обсуждение ) 17:53, 24 августа 2019 (UTC)

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

Однако в теле статьи мы обычно используем длинные форматы даты, и поскольку формат ISO 8601 там не так часто используется, как другие форматы (хотя это использование неуклонно растет (за пределами WP), а пока это официальная дата) формат во многих странах), наша MOS по-прежнему просит нас использовать там либо dmy, либо mdy. Поскольку формат mdy используется только в США (и в любом случае это не самый логичный формат), предпочтительным форматом даты для прозы в статье без сильных связей с США или, как в данном случае, даже международного масштаба, является формат dmy.

Фреймворк цитирования cs1 / cs2 ввел автоматическое форматирование даты несколько месяцев назад. Это хорошо для единообразия (и, надеюсь, в будущем также для возможности настройки пользователем предпочтений формата даты), однако некоторые инструменты и боты все еще необходимо обновить, чтобы они соответствовали параметру cs1-date шаблона «Использовать даты xyz», в противном случае они иногда вставляют даты в неправильном формате даты, что парадоксальным образом может создать новую несогласованность на уровне исходного кода (если не удалить). Из-за автоматического форматирования даты это только косметическое средство, но идея, конечно же, состоит в том, чтобы они вставили дату в надлежащем формате и в будущем, чтобы мы наконец получили решение с необходимым уровнем гибкости и консистенция в сочетании со стабильностью. Я предполагаю, однако, что переходная фаза продлится какое-то время.

- Матиаспол ( разговор ) 19:01, 24 августа 2019 г. (UTC)

Спасибо за то, что вы уделяете пристальное внимание этим тонкостям, так что ленивые редакторы, подобные мне, могут спотыкаться, не портя вещи слишком сильно, даже если наши глаза косятся, когда мы слышим это вслух! NewsAndEventsGuy ( обсуждение ) 20:12, 24 августа 2019 (UTC)

Математические функции [ править ]

Здравствуй,

Что касается вашего редактирования Special: Diff / 912554909 , я думаю, что «eˣ-1» следует заменить на «eˣ − 1», то есть на настоящий минус, как в −1 .

Более того, разве «грех (тригонометрия)» не должен быть «грехом (математической функцией)», как для sinh? То же самое для cos, tan, arcsin, arccos и arctan. Я думаю, что они более общие, чем область тригонометрии , в частности, если учесть их сходство с гиперболическим вариантом со сложными аргументами. Или, возможно, «функция греха» и т. Д., Например, есть гамма-функция и множество других примеров в категории «Специальные функции».

Винсент Лефевр ( разговорное ) 15:37, 26 августа 2019 (UTC)

Привет Винсент, хорошее предложение! Первую часть я уже реализовал.

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

- Матиаспол ( разговор ) 08:59, 27 августа 2019 г. (UTC)

Хамбах [ править ]

Здравствуйте, спасибо за добавление ссылок в раздел Hambach_Forest # Large_demonstration_ (October_2018) . Если честно, я все еще не впечатлен списком, но если на него есть ссылка, у меня нет проблем с ним. Мне было интересно, есть ли у вас ссылки на раздел Hambach_Forest # Arrests_of_activists_ (spring_of_2018) ? Прямо сейчас там ничего нет, я осмотрелся, но ничего не нашел. Может быть, это оригинальные исследования, а может быть, источники существуют, возможно, только на немецком языке. В любом случае, извините, что мы вот так встретились, но, как и вы, я очень хочу улучшить эту статью!  Муджинга ( разговорное ) 22:51, 17 сентября 2019 (UTC)

Хия, спасибо, что добавили несколько ссылок в этот раздел. На мой взгляд, MOS здесь отстает, поскольку мне не удалось найти руководство, но я бы посоветовал при добавлении ссылок на иностранном языке добавить соответствующую цитату, где это уместно, чтобы другим редакторам было легче проверить. Я сделал это, например, на We Are Here (коллективный) . Я начал добавлять переведенные цитаты, но потом понял, что в эпоху машинного перевода лучше ставить оригинальный текст. Статья улучшается, может быть, со временем ее можно будет отправить в статус «Хорошая статья», это было бы здорово.

Кстати, я видел, как вы удалили Ende Gelände 2019, что я считаю странным, поскольку согласно MOS: ТАКЖЕ : Одна из целей ссылок «См. Также» - дать читателям возможность исследовать косвенно связанные темы Mujinga ( разговор ) 07:26, 23 сентября 2019 г. ( УНИВЕРСАЛЬНОЕ ГЛОБАЛЬНОЕ ВРЕМЯ)

Иногда я добавляю цитаты к цитатам, особенно если источник, который я цитирую, очень редок или точная формулировка важна для сохранения для будущих поколений, но у меня нет времени делать это все время. Кроме того, более важно, чем цитаты, убедиться, что онлайн-ссылки правильно заархивированы, чтобы предотвратить гниение ссылок. В любом случае |quote=он предназначен для исходного языка - строго говоря, перевод больше не является цитатой. Я несколько раз просил |trans-quote=параметр, но пока он не материализуется, перевод может быть добавлен |quote=в [квадратные скобки] после исходной цитаты.

Что касается удаления ссылки См. Также, это произошло потому, что группа, которая занимала экскаватор на карьере Хамбах 24 июня 2019 года, не имела отношения к Ende Gelände, поэтому ссылка будет вводить в заблуждение. Есть ссылки на Ende Gelände 2017 и 2018, потому что они были нацелены непосредственно на рудник Хамбах. - Матиаспол ( разговор ) 19:15, 23 сентября 2019 г. (UTC)

Да, в том-то и дело, это не кажется важным, когда говорят на обоих языках (с Хамбахом в вашем случае на английском и немецком, с We Are Here в моем случае на голландском и английском), но я думаю, что если вы этого не сделаете, тогда это настроит блок, как будто я не собираюсь просматривать ссылки на немецкие языки, если мне действительно не нужно, и поскольку машинный перевод продолжает улучшаться, я думаю, что метод ссылок должен измениться, чтобы упростить проверку цитат. Я согласен с тем, что архивирование очень важно, я очень доволен своим плагином Firefox, который позволяет очень легко добавлять обратные ссылки на машины. Это интересно в отношении транскотирования, я думаю, проблема в том, что перевод всегда можно оспорить.В любом случае, спасибо за ваш ответ. Мне интересно обсудить это, и, возможно, в конечном итоге я предлагаю обновить MoS, чтобы отразить ситуацию.Муджинга ( разговор ) 19:09, 28 сентября 2019 (UTC)

Ануна Де Вевер [ править ]

Просто чтобы вы знали, я разместил уведомление о постоянных спорных изменениях IP в Википедии: Administrators'_noticeboard # Persistent_vandalism_at_Anuna_De_Wever . - Андреас Филопатер ( разговор ) 23:15, 22 сентября 2019 г. (UTC)

Да спасибо. Что на самом деле необходимо, так это полустраничная защита страницы, как уже было запрошено несколько часов назад в Википедии: Requests_for_page_protection # Anuna_De_Wever . Просто сегодня они кажутся не особенно быстрыми ... ;-) - Матиаспол ( разговор ) 23:21, 22 сентября 2019 г. (UTC)

Предлагаемое исключение из .sch (расширение файла) [ править ]

Статью .sch (расширение файла) было предложено удалить по следующим причинам:

Статья представляет собой список неизбирательных предметов ; он перечисляет шесть несвязанных приложений, все из которых используют одни и те же три буквы для своих иначе не связанных форматов файлов.

Мы приветствуем любой конструктивный вклад в Википедию, однако страницы могут быть удалены по любой из нескольких причин .

Вы можете предотвратить предлагаемое удаление, удалив {{proposed deletion/dated}}уведомление, но, пожалуйста, объясните причину в своем резюме редактирования или на странице обсуждения статьи .

Пожалуйста, подумайте об улучшении страницы, чтобы решить поднятые проблемы. Удаление {{proposed deletion/dated}}остановит предложенный процесс удаления , но существуют другие процессы удаления . В частности, быстрый процесс удаления может привести к удалению без обсуждения, а статьи для удаления позволяют обсуждению достичь консенсуса в отношении удаления. текущие сны ( страница обсуждения ) 05:27, 7 октября 2019 (UTC)

Номинация ученых на будущее для исключения [ править ]

Обсуждается вопрос о том, подходит ли статья « Ученые для будущего» для включения в Википедию в соответствии с политиками и руководящими принципами Википедии или ее следует удалить .

Статья будет обсуждаться в Википедии: Статьи для удаления / Ученые для будущего, пока не будет достигнут консенсус, и любой, включая вас, может принять участие в обсуждении. Номинация объяснит политику и рекомендации, которые вызывают озабоченность. Обсуждение сосредоточено на высококачественных доказательствах, а также на наших правилах и рекомендациях.

Пользователи могут редактировать статью во время обсуждения, в том числе для улучшения статьи, чтобы устранить проблемы, поднятые в ходе обсуждения. Однако не удаляйте уведомление об удалении статьи в верхней части статьи. A1Cafel ( разговор ) 16:41, 8 октября 2019 (UTC)

«Алгоритм Андерсона Эрла Голдшмидта Пауэрса» внесен в список редиректов для обсуждения [ править ]

Редактор попросил обсудить алгоритм перенаправления Андерсона Эрла Голдшмидта Пауэрса . Поскольку вы имели некоторое отношение к перенаправлению алгоритма Андерсона Эрла Голдшмидта Пауэрса , вы можете принять участие в обсуждении перенаправления, если хотите. Д. Лазард ( разговор ) 14:30, 24 октября 2019 г. (UTC)

Информационный бюллетень New Page Review, ноябрь 2019 г. [ править ]

Доставка сообщений MediaWiki ( обсуждение ) 08:33, 3 ноября 2019 г. (UTC)

Приближается Google Code-In 2019 - займитесь некоторыми задачами по документации! [ редактировать ]

Привет,

Google Code-In , конкурс, организованный Google, в котором участвует Фонд Викимедиа, стартует через несколько недель. Этот конкурс посвящен тому, чтобы старшеклассники окунулись в мир открытого исходного кода. Я отправляю вам это сообщение, потому что вы недавно редактировали страницу документации в английской Википедии.

Прошу вас принять участие в Google Code-In в качестве наставника. Это означало бы подготовить по крайней мере одну задачу (это может быть документация или что-то еще - другие категории - это код, дизайн, обеспечение качества и информационно-пропагандистская деятельность) для участников и помочь студенту выполнить ее. Зарегистрируйтесь на странице конкурса и отправьте нам адрес своей учетной записи Google на [email protected], чтобы мы могли пригласить вас!

По моему собственному опыту, Google Code-In может быть интересным, вы можете завести нескольких новых друзей, привлечь новых людей в свою вики и сделать их частью своего сообщества.

Если у вас есть какие-либо вопросы, сообщите нам об этом по адресу [email protected].

Спасибо!

- Пользователь: Мартин Урбанек ( разговор ) 21:58, 23 ноября 2019 г. (UTC)

Caldera International номинирована на премию "Знаете ли вы" [ править ]

Категория: Обратные эллиптические функции Якоби номинированы на обсуждение [ править ]

Категория: Созданные вами обратные эллиптические функции Якоби номинированы на возможное удаление, объединение или переименование. В настоящее время обсуждается, соответствует ли это предложениеруководящим принципам категоризации . Если вы хотите принять участие в обсуждении, вам предлагается добавить свои комментарии в записи к данной категории по категориям для обсуждения страницы. Спасибо. 1234qwer1234qwer4 ( обсуждение ) 09:04, 15 декабря 2019 (UTC)

Информационный бюллетень New Page Review, декабрь 2019 г. [ править ]

Доставлено MediaWiki, доставка сообщения ( обсуждение ) в 16:11, 20 декабря 2019 г. (UTC)

"Сено-молоко" внесено в список редиректов для обсуждения [ править ]

Редактор попросил обсудить проблему перенаправления сена-молока . Поскольку у вас было какое-то отношение к перенаправлению сена-молока , вы можете принять участие в обсуждении перенаправления, если хотите. Steel1943 ( разговор ) 18:32, 23 декабря 2019 (UTC)

DYK для Caldera International [ править ]

 -  Амакуру ( разговор ) 12:02, 4 января 2020 г. (UTC)

2016–17 Тур де Ски [ править ]

В WP: RMTR поступил запрос на 2016-17 гг. Вы переместили его в другую сторону еще в феврале . Должен ли он быть открыт для полного обсуждения хода? Спасибо, ЭдДжонстон ( выступление ) 18:35, 5 января 2020 г. (UTC)

Здравствуйте, я удалил ваш оспариваемый технический запрос, так как уже выполнил его (случайно забыл удалить). Пожалуйста, отправьте WP: RM, если вы захотите переместить страницу назад. Ваше здоровье! - qedk ( t 桜 c ) 19:13, 5 января 2020 г. (UTC)

«4680» внесено в список редиректов для обсуждения [ править ]

Редактор попросил обсудить проблему перенаправления 4680 . Поскольку вы имели некоторое отношение к перенаправлению 4680 , вы можете принять участие в обсуждении перенаправления, если хотите. США ( разговорное ) 20:04, 7 января 2020 г. (UTC)

Re: Ссылка в статье с цифрами [ править ]

Уведомление о ссылке на устранение неоднозначности от 21 января [ править ]

Здравствуй. Спасибо за ваши недавние правки. Автоматизированный процесс обнаружил, что когда вы недавно редактировали X (значения) , вы добавили ссылку, указывающую на страницу значений Trans ( отметьте, чтобы подтвердить  |  исправить с помощью решателя Dab ). Такие ссылки обычно неверны , поскольку страница значений - это просто список несвязанных тем с похожими названиями. (Прочтите FAQ  • Присоединяйтесь к нам на DPL WikiProject .)

Это сообщение можно удалить. Кроме того, чтобы перестать получать эти сообщения, следуйте этим инструкциям по отказу от рассылки . Спасибо, бот DPL ( разговор ) 08:32, 21 января 2020 (UTC)

"Универсальная гиперболическая геометрия" перечислена в Перенаправлениях для обсуждения [ править ]

Редактор попросил обсудить переадресацию универсальной гиперболической геометрии . Поскольку вы имели отношение к перенаправлению универсальной гиперболической геометрии , вы можете принять участие в обсуждении перенаправления, если хотите. - Дьякон Ворбис  ( углерод  •  видео ) 14:26, 1 февраля 2020 г. (UTC)

Уведомление о ссылке на устранение неоднозначности от 7 февраля [ править ]

Автоматизированный процесс обнаружил, что при недавнем редактировании Rebasing вы добавили ссылку, указывающую на страницу разрешения неоднозначности Microsoft Exchange ( отметьте, чтобы подтвердить  |  исправить с помощью решателя Dab ).

( Инструкции по отказу .) - DPL-бот ( разговор ) 13:44, 7 февраля 2020 г. (UTC)

Информационный бюллетень New Page Reviewer Февраль 2020 г. [ править ]

16:08, 13 февраля 2020 г. (UTC)

«0-серия (производство)» внесена в список перенаправлений для обсуждения [ править ]

Редактор попросил обсудить вопрос о перенаправлении 0-й серии (производство) . Поскольку вы имели какое-то отношение к перенаправлению 0-й серии (производство) , вы можете принять участие в обсуждении перенаправления, если хотите. Steel1943 ( разговор ) 19:10, 14 февраля 2020 (UTC)

Выдвижение 0 серий на удаление [ править ]

Обсуждается вопрос о том, подходит ли серия статей 0 для включения в Википедию в соответствии с политиками и руководящими принципами Википедии или ее следует удалить .

Статья будет обсуждаться в Википедии: Статьи для удаления / 0 серий до тех пор, пока не будет достигнут консенсус, и любой, включая вас, может принять участие в обсуждении. Номинация объяснит политику и рекомендации, которые вызывают озабоченность. Обсуждение сосредоточено на высококачественных доказательствах, а также на наших правилах и рекомендациях.

Пользователи могут редактировать статью во время обсуждения, в том числе для улучшения статьи, чтобы устранить проблемы, поднятые в ходе обсуждения. Однако не удаляйте уведомление об удалении статьи в верхней части статьи. Дуг Мехус T · C 21:39, 14 февраля 2020 г. (UTC)

«Блок свободы» внесен в список редиректов для обсуждения [ править ]

Редактор попросил обсудить вопрос о блоке свободы перенаправления . Поскольку вы имели какое-то отношение к перенаправлению блока Freedom , вы можете принять участие в обсуждении перенаправления, если хотите. Дуг Мехус T · C 22:16, 24 февраля 2020 г. (UTC)

(идентификатор) перенаправляет [ править ]

Вы годами пытались добиться этого. Пожалуйста, остановитесь, у вас нет консенсуса по этому поводу, а также нет специальных идентификаторов ISBN или PMID, которые требуют устранения неоднозначности, когда это делается с помощью шаблонов идентификаторов, связанных с другими местоположениями, чем шаблоны CS1 | 2. Они разработаны для соответствия выходам CS1 | 2.

Если вы хотите изменить эту функциональность, получите консенсус в RFC на Help talk: CS1 . Headbomb { t · c · p · b } 02:04, 8 марта 2020 г. (UTC)

На самом деле, нет формального консенсуса и для прямых ссылок, это просто статус-кво для старых шаблонов - вполне естественно, поскольку Википедия улучшается шаг за шагом, и нормально сначала обратиться к основной функциональности, чтобы получить что-нибудь. вне дома и позже думаю о дальнейших улучшениях. Некоторые созданные мной шаблоны уже используют (d) ссылки (идентификаторы) с самого начала - и определенно никогда не было консенсуса, чтобы изменить их на что-то еще, как это сделали вы ... Итак ...

В любом случае, обсуждение, о котором вы просите, уже существует по адресу: Help talk: Citation Style 1 # Предложение добавить поддержку параметра SBN . Попробуем найти оптимальное решение для большинства пользователей.

- Матиаспол ( разговор ) 17:10, 12 марта 2020 г. (UTC)

"D70F01.EXE" внесен в список редиректов для обсуждения [ править ]

Редактор попросил обсудить проблему перенаправления D70F01.EXE . Поскольку вы имели какое-то отношение к перенаправлению D70F01.EXE , вы можете принять участие в обсуждении перенаправления, если хотите. 1234qwer1234qwer4 ( обсуждение ) 19:57, 15 марта 2020 (UTC)

"Alle Rechte vorbehalten" внесены в список редиректов для обсуждения [ править ]

Редактор попросил обсудить вопрос перенаправления Alle Rechte vorbehalten . Поскольку вы имели какое-то отношение к перенаправлению Alle Rechte vorbehalten , вы можете принять участие в обсуждении перенаправления, если хотите. 1234qwer1234qwer4 ( обсуждение ) 21:25, 16 марта 2020 (UTC)

".acc" внесен в список редиректов для обсуждения [ править ]

Обсуждается вопрос о том, следует ли удалить, сохранить или перенаправить перенаправленный .acc . Это будет обсуждаться в Википедии: Перенаправления для обсуждения / Журнал / 24 марта 2020 г. # .acc до тех пор, пока не будет достигнут консенсус, и любой, включая вас, может принять участие в обсуждении. Номинация объяснит политику и рекомендации, которые вызывают озабоченность. Обсуждение сосредоточено на высококачественных доказательствах, а также на наших правилах и рекомендациях. 1234qwer1234qwer4 ( обсуждение ) 12:32, 24 марта 2020 (UTC)

ARDS [ править ]

Просто час работал над этой информацией и ссылками на первый абзац ARDS в COVID-19. Зачем ты его взорвал? Ян Ферст ( разговор ) 01:01, 27 марта 2020 г. (UTC) без учёта. Спасибо. Ян Ферст ( разговор ) 01:03, 27 марта 2020 (UTC)

Привет, Ян, не уверен, что там происходит, я, конечно, не удалял это (но это каким-то образом было удалено с моим редактированием). Когда я пытался сохранить правку, я получал «сообщение об ошибке обслуживания Викимедиа». Во всяком случае, исправлено. - Матиаспол ( разговор ) 01:08, 27 марта 2020 г. (UTC)

"AUTOEXEC.BAS" внесен в список редиректов для обсуждения [ править ]

Редактор попросил обсудить проблему перенаправления AUTOEXEC.BAS . Поскольку вы имели какое-то отношение к перенаправлению AUTOEXEC.BAS , вы можете принять участие в обсуждении перенаправления, если хотите. 1234qwer1234qwer4 ( обсуждение ) 11:42, 27 марта 2020 (UTC)

4-значные годы на MOS [ править ]

Я заметил, что вы вносили ряд правок в серию статей о коронавирусе, используя сводку редактирования «4-значные годы на MOS». Я прошу вас проявлять осторожность и быть уверенным, что вы правильно понимаете WP: MOSNUM . Хотя действительно правильно, что годы должны указываться в виде 4-х цифр, диапазоны лет могут и обычно указываются в формате 4 + 2 (т. Е. «2019–20»), за исключением рубежа веков (т. Е. «1997–2002 гг.»). Заменив «2019–20» на «2019–2020» в этих ссылках на статьи, вы заменили правильно отформатированные и правильно связанные статьи перенаправлением статей, как вы видите здесь . Во многих случаях вы также вставляли параметр |cs1-dates=y, который был неуместным, поскольку он нарушает WP: RETAIN: почти все эти статьи отображали формат даты, который изначально был либо dmy, либо mdy (это называется нашим "правилом первого основного участника". Поэтому нецелесообразно изменять его, вставляя параметр. С уважением, -  Ohc  ¡digame ! 19:33, 5 апреля 2020 г. (UTC)

Нет, вам нужны полные годы в диапазонах лет, см. MOS: DATERANGE . Винсент Лефевр ( разговорное ) 19:51, 5 апреля 2020 (UTC)

Привет, Ohconfucius, сокращенные годы разрешены в диапазонах лет при некоторых ограниченных обстоятельствах, но, как уже указывал Винсент, предпочтительным и обычным форматом является использование не сокращенных лет согласно RFC и MOS: YEARRANGE . В дополнение к этому у нас есть общее правило избегать сокращений, если их нельзя избежать (или они действительно полезны). Хотя в этом конкретном случае (последовательные годы за пределами диапазона 1–12) аббревиатура технически не вызывает путаницы, она все же затрудняет расшифровку даты для многих людей, поскольку обычно понимается формат «гггг-мм». вместо «гггг-гг» на Дальнем Востоке и в Восточной Европе, а также во всех регионах, где ISO 8601был принят (почти во всех странах мира) или даже является обязательным (в некоторых странах Западной и Средней Европы). А с момента официального принятия расширенного формата даты / времени (EDTF) в 2019 году многие формы за пределами диапазона 1..12 также стали неоднозначными, так что это растущая проблема, а не только небольшое неудобство. Чтобы избежать этой потенциальной двусмысленности, сообщество согласилось не использовать эту форму (как «гггг-мм», а также «гггг-гг») там, где это не обязательно. Поскольку Википедия - это WP: NOTPAPER , нет необходимости экономить здесь место, в первую очередь используя сокращенные годы. Таким образом, хотя мое редактирование не было абсолютно необходимым в данном конкретном случае, оно, тем не менее, было улучшением качества статьи и полностью одобрено нашим MOS.

Кроме того, тот факт, что некоторые из не сокращенных диапазонов лет были перенаправлены через перенаправления, вовсе не является проблемой и не должен быть «исправлен» вами (как вы это делали в этой редакции [32] ). Как указывалось выше, это не были «ненужные перенаправления». Пожалуйста, прочтите WP: NOTBROKEN , WP: NOPIPE и MOS: NOPIPE для некоторой предыстории. По сути, ваше редактирование замаскировало тот факт, что целевые статьи должны быть переименованы, чтобы они также содержали не сокращенные годы.

Что касается |cs1-dates=yпараметра, WP: RETAIN здесь вообще не применяется, но вы, вероятно, имели в виду MOS: DATEVAR или MOS: RETAIN.. Возможно, вы упустили это из виду, но в статьях уже использовался числовой формат ymd в списках и таблицах (и, в некоторой степени, также в цитатах), поэтому было логичным использовать его и в цитатах из соображений согласованности (еще одна цель, которую мы пытаемся добиться в целом). (Другим возможным решением было бы переключиться на формат dmy также в таблицах, но это нежелательно по причинам, связанным с пространством и удобочитаемостью, а также потому, что потенциально таблицы включаются в несколько статей, возможно, с использованием разных форматов даты, поэтому использование ymd является хорошим середина) , я считаю , что это достаточно веская причина , чтобы показать это использование через. |cs1-dates=yпараметра и МОС: DATEVAR «s" изменение уменьшает неопределенность"поддерживает это до тех пор, пока не будет использоваться согласованный формат.

- Матиаспол ( разговор ) 20:02, 6 апреля 2020 г. (UTC)

Целинная земля [ править ]

Если подумать, то ваша точка зрения о том, что иммунитета ранее не существовало, - это хорошо. Но не в лидерах, кто-то другой рано или поздно все изменил бы. Возможно, пара предложений, расширяющих концепцию, в разделе «Эпидемиология». Пожалуйста, найдите цитату, а также вики-ссылку. Счастливой Пасхи! Робертпедли ( разговор ) 16:32, 12 апреля 2020 (UTC)

Интерес к новым проектам [ править ]

Привет, Матиас,

Я много читал о вашей работе над DR-DOS, WinGlue, WinBolt и т. Д., И приятно видеть, что вы все еще участвуете в этом! Мне было интересно, интересовались ли вы новыми проектами, связанными с DOS.

Есть несколько проектов, в которых, я думаю, ваш вклад был бы очень интересен. Как вы думаете, возможно ли для кого-нибудь адаптировать другую DOS, чтобы в ней работала Windows 9x? Теперь есть другие хосты DPMI, которые могут запускать исходную Windows 3.1. Как вы думаете, может ли Windows 9x поддерживаться сторонним хостом DPMI? Вот конкретные вопросы, по которым, я полагаю, вы должны быть осведомлены: https://github.com/dosemu2/dosemu2/issues/988 https://github.com/joncampbell123/dosbox-x/issues/1217

Надеюсь, вы не против, что я пишу здесь. Я не был уверен, актуальна ли другая контактная информация, которую я нашел в Интернете.

Заранее спасибо и с наилучшими пожеланиями! Юлиус Шварценберг - Предыдущий комментарий без подписи, добавленный 2001: 985: 2C6E: 1: 5D7B: 5178: CAC7: 7F09 ( обсуждение ) 19:06, 13 апреля 2020 г. (UTC)

Dr-dos another life questions [ править ]

Здравствуй,

Я Николас из Франции. Извините, что беспокою вас другими жизненными вопросами. Я создаю загрузочные диски DOS с несколькими ядрами, чтобы протестировать поведение различных менеджеров памяти и влияние ядра на доступную память. Я не могу найти другого способа связаться с вами, кроме как здесь. Когда я копался в Интернете в поисках dr-dos, мне в голову пришло 2 вопроса: 1. Что касается файла ядра dr-dos, некоторые люди говорят о версии 7.08, но я не могу найти ничего после 7.07, существует ли она или была ли 7.07 версия Последняя версия ? 2. Есть ли способ получить доступ к файлам ядра версии 7.07 или лучше? Лучше, что я нашел, была версия 7.04 для файлов ibmdos и ibmbios в Dr-dos 7.05.

Спасибо

Хорошего дня

Auf wiedersehen Nico7550 ( обсуждение ) 22:34, 25 апреля 2020 г. (UTC)

«RISM (идентификатор)» указан в списке редиректов для обсуждения [ править ]

Обсуждается проблема перенаправления RISM (идентификатора) . Обсуждение будет происходить в Википедии: Перенаправления для обсуждения / Журнал / 3 мая 2020 г. # RISM (идентификатор) до тех пор, пока не будет достигнут консенсус, и любой, включая вас, может принять участие в обсуждении. Фрэнсис Шонкен ( выступление ) 10:30, 3 мая 2020 г. (UTC)

«Третий (угол)» указан в разделе «Перенаправления для обсуждения» [ править ]

Обсуждается вопрос о третьем перенаправлении (угол) . Обсуждение будет происходить в Википедии: Перенаправления для обсуждения / Журнал / 7 мая 2020 г. # Третий (угол) до достижения консенсуса, и любой, включая вас, может принять участие в обсуждении. Spinning Spark 17:02, 7 мая 2020 г. (UTC)

Фотография Эдварда Дж. Маккласки? [ редактировать ]

Здравствуй! Вы случайно не знаете, изображен ли Эдвард Дж. Маккласки на картинке File: McCluskey J (I198201) .jpg (якобы из польского журнала информатики pl: Informatyka (czasopismo) ) ? - Йохен Бургхардт ( разговор ) 14:11, 12 мая 2020 г. (UTC)

Привет, Йохен, к сожалению, качество изображения настолько низкое, что на нем особо не на что смотреть. Может быть, как он причесался? Есть какое-то отдаленное сходство, но это могло быть и много других людей. Если вы подумаете о включении фотографии в его статью, возможно, нам стоит подождать, пока не появится лучший портрет.

• https://news.stanford.edu/2016/02/25/ed-mccluskey-obit-022516/
• https://www.thocp.net/biographies/mccluskey_edward.htm
• https://www.ieee.org/about/awards/bios/vonneumann-recipients.html#
• https://alchetron.com/Edward-J-McCluskey
• https://ieeetv.ieee.org/mobile/video/2012-ieee-honors-john-von-neumann-medal (см. [0:49] и [0:57] в видео, где показаны его молодые портреты инженер)

Привет,

- Матиаспол ( разговор ) 15:45, 12 мая 2020 г. (UTC)

Fundstelle [ править ]

Lieber Matthiaspaul, wie nett, einen Deutschen hier zu treffen. Ich finde es doch recht kompliziert, meine diesbezüglichen Fragen auf Englisch zu formulieren. Также ... vor einiger Zeit hatte ich gefragt, wie man aus einem Sammelwerk zitiert на английском языке. Ich schreib hier mal, wie ich es на Deutsch mache, und wie mir gesagt wurde, es на английском языке:

• Deutsch <ref> {{Literatur | Autor = René Hirner | Titel = Fluten. Художественный музей Хайденхайма 1998 | Hrsg = Рене Хирнер; Ричард Гассен | Sammelwerk = Ахим Земан: Художественный музей Хайденхайма / Музей Вильгельма Хака, Людвигсхафен, Ausstellungskatalog | Verlag = Kunstmuseum Heidenheim / Wilhelm-Hack-Museum Ludwigshafen | Ort = Heidenheim; Людвигсхафен | Datum = 1999 | ISBN = 9783931182618 | Seiten = 5-8 | Fundstelle = S.8}} </ref>
• Englisch <ref> {{cite book | last = Hirner | first = René | editor1-last = Hirner | editor1-first = René | editor2-last = Gassen | editor2-first = Richard | title = Ахим Земан: Художественный музей Хайденхайма / Wilhelm-Hack-Museum Ludwigshafen, Ausstellungskatalog | trans-title = Achim Zeman: Art Museum Heidenheim / Wilhelm-Hack-Museum Ludwigshafen, каталог выставки | publisher = Kunstmuseum Heidenheim / Wilhelm-Hack-Museum Ludwigshafen | place = Ludwigshafen | 1999 | chapter = Fluten. Kunstmuseum Heidenheim 1998 | trans-chapter = Flood. Художественный музей Хайденхайма 1998 | ISBN = 9783931182618 | page = 14}} </ref>
• Mir wurde damals gesagt, dass man nur die Seitenzahl des Zitats - также die "Fundstelle" на английском языке. Jetzt bei der Diskussion im Teahouse meinte jemand, ich könnte zweimal Seiten angeben, aber das funktioniert mit der Vorlage "цитировать книгу" eben gerade nicht. Da kommt immer "du hast zweimal Seitenzahln angeben, das ist ein Fehler" - sinngemäß formuliert. Könntest du mir erklären, wie man es doch hinbekommt? Ich habe in der Diskussion im Teahouse das hier überhaupt nicht verstanden "{{Sfn}} или {{rp}} - dann bräuchte man zwei Vorlagen in einer ??? Ich finde es so unglaublich kompliziert, in jeder Sprache die richtige Formatier für mich ist das sehr anstrengend zu verstehen. Wäre daher für Input sehr dankbar! - Гьянда ( разговор ) 21:13,14 мая 2020 (UTC)

Привет, Гьянда, действует мгновенно, но с английским языком Zitiervorlage. In der Regel verhält es sich andersherum, aber es gibt tatsächlich Dinge, wo die deutsche Vorlage Literaturden englischen Vorlagen etwas voraus hat - und da es leider sehr viele prinzipielle Neinsager unter den Nutzern gibt, ist es schwer, mögliche Verbesserungsideen aus den anderssprachigen Wikipedien zu übernehmen. Das braucht meist etliche Anläufe und mitunter Jahre, bis sich die ein oder andere Funktion mal durchsetzt. Momentan ist das Thema Seitenzahlangaben mal wieder heiß diskutiert, und wir versuchen gerade, eine geeignete Notation zu finden und Unterstützung dafür auch в Form neuer Параметр в die CS1- / CS2-Zitiervorlagen einzubauen. Vielleicht hast Du ja Lust, Dich zu beteiligen und zur Durchsetzung dieser Funktion etwas beizutragen:

• Help talk: Citation Style 1 # цитирование разных страниц одной и той же книги
• Справка: стиль цитирования 1 # количество страниц
• Обсуждение: Citation Style 1 # Вопрос о параметрах страницы в шаблоне: Cite journal
• Обсуждение помощи: Стиль цитирования 1 # Предложение: диапазон страниц
• Обсуждение помощи: стиль цитирования 1 # Использование страниц в журнале Cite
• Википедия: Чайхана / Вопросы / Архив 1060 # Вопрос по форматированию

( Справка: Стиль цитирования 1 ist die Hilfeseite für die am häufigsten verwendeten Zitiervorlagen vom Typ CS1 und Help talk: Citation Style 1 das am besten geeignete Forum für Fragen dazu.)

Венна Du Beide Seitenangaben Schon Jetzt unterbringen Willst, оЬпе Dass ES dafür Schon Neue Параметр Gibt, würde Ich empfehlen, Дас Wie folgt цу Machen: |pages=5–8 [8], |pages=50–98 [60, 66–67, 84]Одер Bei Айнем besonders zerklüfteten Magazinartikel Vielleicht |pages=50–52, 54, 57, 60–64, 67 [51, 61–62], а также ден Seitenbereich де Kapitels / Artikels anzugeben, gefolgt фон дер Liste der Individualuellen Fundstellen in eckigen Klammern (das scheint die Notation zu sein, die die meisten an der Diskussion Beteiligten wohl unterstützen).

Был ли Zitiervorlagen wie {{ rp }} oder {{ sfn }} angeht, das kann man so machen (und einige Leute bevorzugen das auch), aber die Mehrzahl der Anwender findet das unübersichtlich und übertrieben, Nurn es человек индивидуальный ausweisen muß. In den meisten Fällen reicht es, diese, wie in den obigen Beispielen gezeigt, zusammenzufassen.

- Матиаспол ( разговор ) 09:09, 15 мая 2020 г. (UTC)

Danke für deine ausführliche Antwort, Matthiaspaul. Ich habe in dem einen Thread nachgelesen und finde bisher dieses at = am besten, wenn es funktioniert. Ich bin auch froh darüber, dass die deutsche Wikipedia das mit der Fundstelle hat. Ich finde, es ist schon eine wichtige Information, ob ein Artikel, der ein Thema behandelt, 20 или 50 или 2 Seiten hat, von daher probier ich demnächst mal das mit dem at. Ich finde auch, dass unser Unterforum bei Fragen zur Relevanz huge hilfreich ist, und dass es sehr schade ist, dass es das hier nicht gibt. Ich mag natürlich keinen Artikel schreiben, der sofort wieder gelöscht wird, daher frage ich, wenn ich mir unsicher bin, gern in dem Unterforum. Nochmals herzlichen Dank! LG, - Гянда ( разговор ) 11:25, 15 мая 2020 г. (UTC)

Код Грея [ править ]

Матиас, я не хотел наступать тебе на ноги, когда отменил твое дополнение, не полученное от источника, поэтому я предложил тебе вернуть его с исходным кодом (это несложно, сначала не требуется откат - просто отредактируйте свой версия для добавления источника). В любом случае, дело сделано. Повторяю про Варека, спасибо за то, что нашел эти источники. Мне кажется, что они использовали обычный код Грея, за исключением пропуска некоторых состояний при кодировании десятых и двенадцатых. Они называют это отраженным двоичным кодом Грея. Кто-нибудь называл это кодом Varec? Может, нам лучше отказаться от этого странного оборудования? Диклион ( разговор ) 02:45, 17 мая 2020 (UTC)

В основном я жаловался на отношение, поэтому и хотел вызвать у вас тревогу.

Что касается кода Varec, много лет назад я видел, что его называли "кодом Varec", "кодом датчика Varec", "импульсным кодом Varec" и т.п., в частности, в документах, намного более старых (1960-е?, Возможно, даже 1950-е?), Чем два I добавлено вчера. В то время как первые два варианта кода напоминают отраженный код О'Брайена I с длиной цикла 20, третья часть достаточно уникальна в использовании разных длин цикла (20, 24, 32) для разных цифр. Поскольку это не (отраженный) код BCD, код Varec следует указать в первой группе кодов.

- Матиаспол ( разговор ) 22:56, 17 мая 2020 г. (UTC)

Кодекс Либоу-Крейга [ править ]

Насколько я могу судить, код Либоу-Крейга представляет собой 5-битный десятичный код. Некоторые из ваших источников описывают это как более общее, чем это? Диклион ( разговорное ) 03:46, 26 мая 2020 (UTC)

Нет, я видел, как это упоминается также в контексте 4-битных кодов, но «как есть» всегда обсуждается как 5-битный пятизначный код.

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

В коде Либоу – Крейга достаточно примечательного материала , так что в какой-то момент в нем, вероятно, будет отдельная статья. Прямо сейчас я просто создавал для этого некоторую инфраструктуру.

Код 1-2-1, вероятно, также следует упомянуть в этом контексте.

- Матиаспол ( разговор ) 12:24, 26 мая 2020 г. (UTC)

Номинация на быстрое исключение категории: принтеры DEC [ править ]

В категорию «Принтеры DEC» помещен тег с просьбой о его скорейшем удалении из Википедии. Это было сделано в рамках раздела С1 критериев для быстрого удаления , потому что категория была пуста в течение семи дней или больше , и это не категория неоднозначности , категория редирект , признаки категория темы , обсуждаемые в Категории для обсуждения или категория проекта, которая по своей природе может иногда становиться пустой.

Если вы считаете, что эту страницу не следует удалять по этой причине, вы можете оспорить номинацию , посетив страницу и нажав кнопку с надписью «Конкурс на это быстрое удаление». Это даст вам возможность объяснить, почему вы считаете, что страницу не следует удалять. Однако имейте в виду, что если страница помечена для быстрого удаления, она может быть удалена без промедления. Пожалуйста, не удаляйте тег быстрого удаления со страницы самостоятельно, но не стесняйтесь добавлять информацию в соответствии с политиками и рекомендациями Википедии . L iz ^{Read! Разговаривать!} 17:37, 2 июня 2020 г. (UTC)

Информационный бюллетень New Page Reviewer, июнь 2020 г. [ править ]

Доставка сообщений MediaWiki ( обсуждение ) 02:52, 18 июня 2020 г. (UTC)

«Кризис короны» внесен в список редиректов для обсуждения [ править ]

Обсуждается вопрос о переадресации кризиса Corona . Обсуждение будет происходить в Википедии: Перенаправления для обсуждения / Журнал / 2020 23 июня # Кризис коронавируса до достижения консенсуса, и любой, включая вас, может принять участие в обсуждении. Тридуульф ( разговор ) 15:29, 23 июня 2020 (UTC)

Объем очистки страницы [ править ]

Здравствуй! Прежде всего позвольте мне сказать, что мне очень нравится ваша работа. Каждый раз, когда я вижу одну из ваших правок, меня впечатляет качество.

Re: [33]. Похоже, что мне нужно либо убедить вас принять изменения, которые вносит WP: AutoEd, либо мне нужно убедить Plastikspork - разработчика AutoEd - прекратить вносить эти изменения. Я не хочу вручную отменять изменения AutoEd, с которыми я согласен. Есть большое количество пользователей AutoEd. Если одно из изменений, внесенных AutoEd, неверно, нам нужно это исправить. Если они не ошибаются, вам нужно прекратить их возвращать.

Если мы не сможем прийти к соглашению по этому поводу, я могу опубликовать RFC, но я не думаю, что это необходимо. Вы, я и «Пластикспорк» - давние и добросовестные участники, и мы должны иметь возможность договориться о том, что здесь делать.

Кстати, я считаю, что волшебство происходит в Wikipedia: AutoEd / wikilinks.js . - Гай Мейкон ( разговор ) 01:40, 30 июня 2020 г. (UTC)

Гай Мейкон , я отключил эту строку в скрипте. Я считаю, что один из них был унаследован от Википедии: WikiProject User scripts / Scripts / Formatter , или, может быть, просто вдохновлен им. Мы могли бы сделать его менее агрессивным, чтобы он изменился [[word (computer architecture)|wo]]rdsна, [[word (computer architecture)|word]]sно оставался в [[word (computer architecture)|word]]sпокое. Спасибо! Пластикспорк ―Œ (обсуждение) 13:29, 30 июн 2020 (UTC)

Привет вам обоим. Это уже кажется значительным улучшением, Пластикспорк.

Ваше предложение учитывает только исключения в скобках, или оно также сработает для таких вещей, как [[round-off error|round-off]]sили [[round-off error|error]]s?

И, я полагаю, если аффикс «s», «d» или «ing», его всегда следует оставлять нетронутым (не уверен, будет ли достаточно безопасно отделить его от (правой части) ссылки, но если его уже кто-то отколол, его нужно оставить в покое - наверное, они знали, что делали).

Привет,

- Матиаспол ( разговор ) 07:39, 1 июля 2020 г. (UTC)

ALUSidebar Приглашение на спор [ править ]

@ Матиаспауль : Привет! Я заметил , что вы были вовлечены в такие технические и связанные с вычислительными статьи как карты Карно , Брент-кунг сумматор , Kogge-Stone сумматор , Bit нарезка и т.д. , так что вы хотели бы принять участие в споре ALUSidebar ? Короче говоря, я создал боковую панель, чтобы собрать кучу всего, что связано с ALU, в одном месте, но позже пришла другая группа, переименовала ее и начала удалять "ненужные" вещи, сеющие хаос. Помощь в достижении консенсуса приветствуется. Спасибо! AXO NOV (разговорное) ⚑ 23:06, 4 июля 2020 (UTC)

Ошибка повторяющихся имен ссылок [ править ]

Здравствуй! Ваше редактирование здесь привело к такой ошибке . (Ищите "error:" в ревизиях до и после вашего редактирования.) Не могли бы вы исправить это? - Палосиркка ( разговор ) 00:03, 6 августа 2020 г. (UTC)

Фиксированный. Я объединил две ссылки Бергмана, потому что они были избыточными, за исключением диапазонов страниц. - Матиаспол ( разговор ) 03:09, 6 августа 2020 г. (UTC)

Спасибо! Я бы хотел, чтобы программное обеспечение объединяло идентичные ссылки, автоматически избавляя нас от проблем с мясом. :) - Palosirkka ( разговор ) 09:12, 7 августа 2020 (UTC)

«Снижение шума при радиовещании» внесено в список редиректов для обсуждения [ править ]

Обсуждается вопрос о снижении шума при перенаправлении в радиовещании . Обсуждение будет происходить в Википедии: Перенаправления для обсуждения / Журнал / 20 августа 2020 г. # Снижение шума в радиовещании до достижения консенсуса, и любой, включая вас, может принять участие в обсуждении. Steel1943 ( разговор ) 06:54, 20 августа 2020 (UTC)

Большое спасибо [ править ]

Статья о Microsoft DOS HMA буквально безошибочная. Спасибо, он мне нужен как источник для редактирования страниц расширенной памяти и расширенной памяти, которые содержат дезинформацию, неосведомленные обобщения и просто ошибочны. Я являюсь редактором страницы реального режима на вики по истории компьютеров Массачусетского технологического института : 170.75.140.124 ( обсуждение ) 20:38, 26 августа 2020 г. (UTC)

Параметры с переносом [ править ]

Я видел , как вы в последнее время сделать несколько изменений , как этот . Какой смысл убирать вариант без дефиса? Я считаю, что это хорошо, что у нас есть синонимы, и редакторам не нужно запоминать точные имена параметров; принуждение их к этому - небольшой шаг к менее удобной для редактора энциклопедии. Я что-то упускаю ? - R8R ( обсуждение ) 12:35, 13 сентября 2020 г. (UTC)

Привет, я понимаю вашу точку зрения, но вам не о чем беспокоиться; мы позаботимся об этом.

Основная причина исчезновения некоторых псевдонимов параметров заключается в достижении большей согласованности в пользовательском интерфейсе и документации, чтобы помочь пользователям увидеть всеобъемлющие концепции интерфейса и соглашения об именах / синтаксисе и тем самым облегчить пользователям запоминание параметров. На самом деле читателей смущает то, что некоторые параметры отформатированы по-разному даже в одной и той же статье и шаблоне, в то время как некоторые устаревшие параметры существуют только в форме без дефиса, а все новые параметры - только в форме с дефисом. Что менее важно, это также позволяет немного очистить код, чтобы иметь лучшую основу для некоторой оптимизации производительности и для фактически новых функций в будущем, улучшая функциональность и удобство.

В 2014 году у нас был RfC, чтобы больше не вводить какие-либо новые варианты параметров без дефиса. Итак, с тех пор основным правилом для всех пользователей шаблонов, связанных с CS1 / CS2, является использование только параметров с дефисом, другие варианты существуют только для поддержки устаревших версий.

Когда мы видим, что некоторые устаревшие варианты параметров без дефиса на самом деле не используются (вообще или больше), нет смысла продолжать их поддерживать, поэтому мы отказываемся от них. В некоторых случаях интерфейс параметров модифицируется другими способами, например, объединением функций нескольких параметров в один. В таких ситуациях новый интерфейс будет поддерживать только варианты параметров с дефисом. В других случаях параметры без переноса имеют всего несколько десятков применений, так что их достаточно легко изменить вручную на их варианты с переносом.

В данном конкретном случае фактической целью моего редактирования были редко используемые псевдонимы параметров |displayeditors=и |editormask=параметры, но, в любом случае, редактируя статью, я, конечно, воспользовался возможностью также переключить несколько других параметров того же класса на их варианты с переносом через дефис ( даже при том, что они не будут устаревать в ближайшее время, потому что их количество использования все еще слишком велико для редактирования вручную).

В любом случае, даже если поддержка параметра будет в конечном итоге удалена, наши шаблоны цитирования объединяют «систему предложений», так что, если пользователь продолжит вводить параметр без дефиса, он / она получит сообщение с указанием нового имени параметра. , так что он / она не заблудится и переход будет плавным.

- Матиаспол ( разговор ) 17:43, 13 сентября 2020 г. (UTC)

Большое спасибо за то, что вы нашли время, чтобы объяснить мне это так подробно. Мне не приходило в голову, что существование синонимов может на самом деле привести к путанице, но теперь, когда вы это объяснили, это имеет смысл. Но в таком случае я бы посоветовал упомянуть об этом в документации по шаблонам, таким как {{ cite journal }}. Это решило бы этот вопрос для меня, а также запретило бы добавление новых экземпляров параметров без переноса - R8R ( разговор ) 13:25, 16 сентября 2020 г. (UTC)

Сейчас это все еще подготовительная работа, но, конечно, она, в конце концов, будет задокументирована в документации CS1.

- Матиаспол ( разговор ) 13:53, 16 сентября 2020 г. (UTC)

"" 6 и 2 "кодировки" перечислены в разделе "Перенаправления" для обсуждения [ править ]

Обсуждается вопрос о кодировке перенаправления «6 и 2» . Обсуждение будет происходить в Википедии: Перенаправления для обсуждения / Журнал / 2020 Сентябрь 14 # Кодирование «6 и 2» до достижения консенсуса, и любой, включая вас, может принять участие в обсуждении. Steel1943 ( разговор ) 17:48, 14 сентября 2020 (UTC)

Без кота [ править ]

Относительно этого редактирования страницы архива: сколько примерно заархивированных страниц FAC имеют параметр no-cat? Если 5 страниц, это вообще не проблема. Если их 500, то страницы редактировать не надо. - Данк ( нажми и говори ) 18:57, 22 сентября 2020 г. (UTC)

Привет, Данк, что касается |no-cat=псевдонима параметра шаблонов цитирования CS1 / CS2, количество использований было не более трех десятков, и они готовы.

В общем, как бы я ни ненавидел это делать, редактирование некоторых заархивированных страниц в этом случае неизбежно, потому что в противном случае шаблоны на этих страницах больше не подавляли бы категоризацию, то есть эти архивные страницы внезапно начали бы отображаться в категории система, хотя изначально параметр использовался именно для того, чтобы этого избежать. ;-) Так что просто оставить эти страницы нетронутыми (как наша обычная процедура, когда мы улучшаем шаблоны) здесь не вариант.

Как ни странно, у этой функции много псевдонимов параметров (слишком много для такой редко необходимой функции), и некоторые из этих имен пересекаются с именами параметров других шаблонов, которые часто используются. Таким образом, невозможно определить точное общее количество использованных устройств. Кроме того, время ожидания поиска хотя бы одного из этих псевдонимов параметров Cirrus истекло. Поскольку функция этого параметра заключается в отключении категоризации, у нас также нет категории отслеживания для этого. Это своего рода кошмар обслуживания. Кроме того, каноническое имя параметра ( |template-doc-demo=) вообще не вписывается в соглашения об именах параметров в шаблонах цитирования, поэтому это необходимо исправить.

План состоит в том, чтобы уменьшить количество псевдонимов и переименовать каноническое имя параметра во что-то осмысленное и уникальное, чтобы оно стало доступным для поиска (в противном случае нам потребуется категория отслеживания для параметра, предназначенного для отключения категоризации).

Из-за этих зависимостей это будет медленный процесс, возможно, потребуется еще два цикла обновления, пока он не будет завершен.

См. Также: Help_talk: Citation_Style_1 # no-cat_parameter_cleanup

- Матиаспол ( разговор ) 19:43, 22 сентября 2020 г. (UTC)

У меня есть список отслеживания всех страниц FAC, которые были продвинуты с 1 января 2016 года (я думаю), и я заметил только одно изменение, поэтому, если вы закончили с этим раундом, тогда нет никаких проблем (со страницами архива FAC ). Спасибо. - Данк ( PTT ) 19:56, 22 сентября 2020 г. (UTC)

"Hades DeskTop" внесен в список редиректов для обсуждения [ править ]

Обсуждается проблема перенаправления Hades DeskTop . Обсуждение будет происходить в Википедии: Перенаправления для обсуждения / Журнал / 4 октября 2020 г. # Hades DeskTop до тех пор, пока не будет достигнут консенсус, и любой, включая вас, может принять участие в обсуждении. Шхнотсолоуд ( разговор ) 18:53, 4 октября 2020 (UTC)

"Hades cliXX" внесен в список редиректов для обсуждения [ править ]

Обсуждается проблема перенаправления Hades cliXX . Обсуждение будет происходить в Википедии: Перенаправления для обсуждения / Журнал / 4 октября 2020 г. # Hades cliXX до тех пор, пока не будет достигнут консенсус, и любой, включая вас, может принять участие в обсуждении. Шхнотсолоуд ( разговор ) 18:54, 4 октября 2020 (UTC)

"Hades (отпечаток)" внесен в список редиректов для обсуждения [ править ]

Обсуждается вопрос о перенаправлении Аида (отпечаток) . Обсуждение будет происходить в Википедии: Перенаправления для обсуждения / Журнал / 4 октября 2020 г. # Hades (выходные данные) до тех пор, пока не будет достигнут консенсус, и любой, включая вас, может принять участие в обсуждении. Шхнотсолоуд ( разговор ) 18:54, 4 октября 2020 (UTC)

"NFT Ventures" внесены в список редиректов для обсуждения [ править ]

Обсуждается вопрос о перенаправлении NFT Ventures . Обсуждение будет происходить в Википедии: Перенаправления для обсуждения / Журнал / 6 октября 2020 г. # NFT Ventures до достижения консенсуса, и любой, включая вас, может принять участие в обсуждении. Роберт МакКленон ( выступление ) 16:50, 6 октября 2020 г. (UTC)

Категория: Mac OS [ править ]

Категория: Программное обеспечение резервного копирования для Mac OS может быть переименовано, см. Википедию: Категории для обсуждения / Журнал / 28 октября 2020 г. # Категория: Программное обеспечение для Mac OS . - Fayenatic л ondon 15:56, 7 ноября 2020 года (UTC)

Атрибут «nbk» для «цитировать книгу» [ править ]

Здравствуйте, не могли бы вы рассмотреть запрос атрибута "nbk" (книжная полка NCBI) для "цитировать книгу" ? Максим Масютин ( разговорное ) 21:26, 7 ноября 2020 (UTC)

"Druck (key)" внесен в список редиректов для обсуждения [ править ]

Обсуждается вопрос о перенаправлении Druck (ключ) . Обсуждение будет происходить в Википедии: Перенаправления для обсуждения / Журнал / 14 ноября 2020 г. # Druck (ключ) до тех пор, пока не будет достигнут консенсус, и любой, включая вас, может принять участие в обсуждении. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 ( 𝗍𝗮𝘭𝙠 ) 15:29, 14 ноября 2020 (UTC)

Сообщение избирателя ArbCom 2020 Elections [ править ]

Категория: Перенаправления с идентификаторов цитирования номинированы на объединение [ править ]

Категория: Перенаправления с идентификаторов цитирования номинированы на объединение. В настоящее время обсуждается, соответствует ли это предложениеруководящим принципам категоризации . Если вы хотите принять участие в обсуждении, вам предлагается добавить свои комментарии в записи к данной категории по категориям для обсуждения страницы. Спасибо. - MJL  - Обсуждение - ^☖ 21:17, 30 ноября 2020 г. (UTC)

Декабрьский информационный бюллетень New Page Patrol [ править ]

18:16, 10 декабря 2020 г. (UTC)

Категория: Лемнискатические эллиптические функции номинирована на объединение [ править ]

Категория: Лемнискатические эллиптические функции номинирована на объединение. В настоящее время обсуждается, соответствует ли это предложениеруководящим принципам категоризации . Если вы хотите принять участие в обсуждении, вам предлагается добавить свои комментарии в записи к данной категории по категориям для обсуждения страницы. Спасибо. - Прачечная Пицца 03 ( d c̄ ) 03:58, 17 декабря 2020 г. (UTC)

"Datenknoten (CCC)" внесен в список редиректов для обсуждения [ править ]

Обсуждается вопрос о перенаправлении Datenknoten (CCC) . Обсуждение будет происходить в Википедии: Перенаправления для обсуждения / Журнал / 2021 8 января # Datenknoten (CCC) до тех пор, пока не будет достигнут консенсус, и любой, включая вас, может принять участие в обсуждении. UnitedStatesian ( разговорное ) 02:14, 8 января 2021 (UTC)

"Datenpirat (CCC)" внесен в список редиректов для обсуждения [ править ]

Обсуждается вопрос о перенаправлении Datenpirat (CCC) . Обсуждение будет происходить в Википедии: Перенаправления для обсуждения / Журнал / 2021 Январь 8 # Datenpirat (CCC) до тех пор, пока не будет достигнут консенсус, и любой, включая вас, может принять участие в обсуждении. UnitedStatesian ( разговорное ) 02:14, 8 января 2021 (UTC)

CVE (идентификатор) [ править ]

• CVE (идентификатор)
• CVE-2018-3665

Итак, вы отметили CVE (идентификатор) как {{ R to related topic }}, чтобы упростить обратный поиск, но теперь, когда существует {{ R from CVE }}, нужно ли это больше? - MJL  - Обсуждение - ^☖ 18:07, 17 января 2021 (UTC)

Привет, MJL. Да, важно сохранять {{ R from identifier }} в перенаправлении CVE (идентификатора), поэтому он отображается в Категория: Перенаправления с идентификаторов . Однако, {{ R в соответствующей теме }} уже не важно с {{ R от ССО }} , конечно , будучи лучше RCAT описать отношения. Я соответственно обновил CVE (идентификатор) .

- Матиаспол ( разговор ) 18:25, 17 января 2021 г. (UTC)

Altium Designer [ править ]

Быстрый вопрос, поскольку я все еще учусь. Я переместил все ссылки из списка внизу в основную часть статьи, но вижу, что вы переместили их обратно . Это вещь предпочтения или руководство по стилю. В любом случае у меня нет проблем, но я хочу убедиться, что ничего не испортил, когда делаю какие-либо правки. Заранее спасибо. - RTotzke ( разговор ) 18:10, 17 февраля 2021 (UTC)

Привет, наша MOS допускает оба стиля, и применяются CITEVAR и BRD, но многие опытные редакторы предпочитают списковые ссылки, по крайней мере, для существенных статей, которые достигли определенного уровня стабильности и / или зрелости. Списочные ссылки имеют несколько преимуществ; они избегают беспорядка в теле статьи и, таким образом, значительно упрощают словесное оформление прозы в редакторе исходного кода (где в противном случае вы часто почти не можете увидеть прозу с множеством перемежающихся ссылок) и последовательно улучшать ссылки без поиска их в исходном коде или необходимость блокировать всю статью при работе со ссылками. Большинство статей начинаются со встроенных ссылок, поскольку ссылки просто добавляются в статью там, где это необходимо,и часто они меняются на стиль списка позже (если только не активные редакторы объекта статьи).

- Матиаспол ( разговор ) 22:43, 19 февраля 2021 г. (UTC)

Спасибо за объяснение. Итак, если я правильно понимаю, использование inline на самом деле не проблема, но если я вижу ссылки, определенные списком, я должен их оставить. Еще раз спасибо за совет. - RTotzke ( разговор ) 16:45, 22 февраля 2021 (UTC)

Ага. - Матиаспол ( разговор ) 16:13, 23 февраля 2021 г. (UTC)