Почему теги обычно имеют нижний регистр?

Всюду, где я смотрю, я вижу, что всякий раз, когда сайт внедряет систему тегов, они конвертируют имена тегов в нижний регистр. Даже здесь, в StackOverflow.

Я думал о том, почему это так. Помимо предотвращения дублирования, я не могу придумать причины использовать строчные буквы. Я считаю, что это вредит практическому аспекту тегов. Люди привыкли читать "IBM" не "ibm" и "С#", а не "С#". Для пользователя требуется немного больше времени, чтобы понять, что означает значение тега, и мне интересно, следует ли мне разрешать Capitals в моей системе тегов или это соглашение, и я все понял неправильно.

Я хочу услышать ваше мнение.

Ответ 1

Спросите инженера причину, почему что-то определенно, и они пойдут на многое, чтобы понять это.;)

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

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

Ответ 2

Как вы уже заметили, это предотвращает дублирование. Люди не соответствуют своей капитализации. Просто посмотрите на теги здесь и обратите внимание, что люди не могут решить, будет ли это "objective-c" , "objc" или "objectivec". Бросьте "objective-c" , "objective-c" и т.д., И у вас будет настоящий беспорядок.

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

Ответ 3

Различные случаи всегда должны считаться эквивалентными для тегов.

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

Ответ 4

(Я не советую ни о каком конкретном сайте или системе в этом ответе - каждая конкретная система может иметь свои собственные соображения)

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

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

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

Это похоже на то, как имена пользователей работают во многих системах. Я бы не выбрал имя пользователя в смешанном случае, а вместо того, чтобы имена пользователей обрабатывались без учета регистра (поэтому я бы просто использовал случай, который имеет смысл в системе, в которой я находился, которая имеет нижний регистр в Unix, но в верхнем регистре в некоторых других старых системах). Затем в большинстве систем имеется некоторая другая информация, хранящаяся о пользователях, например, их длинное или полное имя, которое лучше читать, и поэтому многие пользовательские интерфейсы (например, Windows XP, Mac OS, и я думаю, также некоторые новые интерфейсы Unix для настольных компьютеров, такие как GNOME и KDE) на моделях входа в систему, сообщениях и т.д.

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

Ответ 5

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

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

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

http://en.wikipedia.org/wiki/List_of_case-sensitive_English_words

Тем не менее, красота английского лексикона - это способность адаптироваться, модифицироваться и развиваться.

Ответ 6

Это звучит как верный момент для меня. Я уверен, что они могли бы придумать простой синтаксический анализ, чтобы загладить каждое слово (разделенное тире), но как вы узнаете, что он должен быть IBM, а не Ibm? Я думаю, кому-то придется вручную изменить таблицу поиска тегов, чтобы выполнить это.

Ответ 7

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

  • IBM
  • IBM
  • I B M
  • I. B. M.
  • I.B.M.

Однако существует компромисс между увеличенным временем выполнения (не говоря уже об усилиях разработчиков) и увеличением полезности.

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

Ответ 8

При наборе текста вам нужно будет включить блокировку кнопок, чтобы сделать все в верхнем регистре. Люди ленивы.