Из Википедии, свободной энциклопедии
Перейти к навигации Перейти к поиску

Последовательность именования [ править ]

из архива в Википедии: Соглашения об именах (системы письма)

Кодировки GB-18030 в шаблоне: charmap [ править ]

Здесь вам нужны отзывы об использовании . Пользователь: HarJIT создал конвертер UTF для стандарта GB 18030 - GB 18030 алгоритмически включает всю UCS - и реализовал функцию для отображения этой кодировки в шаблоне: charmap. Большой вопрос заключается в том, следует ли включать отображение кодировки GB 18030 по умолчанию в таблице charmap, например UTF-8 и UTF-16 для суррогатных кодовых точек, или же оно должно отображаться только тогда, когда явно установлен флаг «IncludeGB = yes» набор. Шаблон charmap в настоящее время развернут примерно на 500 страницах для символов латинского, кириллического, греческого, семитского (иврита и персидско-арабского языков), шрифта Брайля и шрифтов Кана. Спасибо за твои мысли. Ван Исаак WS{{charmap}}продолжение 08:12, 19 августа 2020 г. (UTC)

Я предпочитаю, чтобы он отображался только тогда, когда установлен флаг IncludeGB = yes. DRMcCreedy ( обсуждение ) 15:24, 19 августа 2020 (UTC)
Есть ли у вас какое-либо представление о том, где это определенно должно отображаться, а где определенно не может быть? Van Isaac WS, продолжение 02:11, 20 августа 2020 г. (UTC)
Нет, но я бы не хотел, чтобы это появилось неожиданно или непреднамеренно. Пользователь: HarJIT , наверное, лучше знает. DRMcCreedy ( обсуждение ) 04:22, 20 августа 2020 (UTC)

Для справки - исчерпание других форматов преобразования Unicode и предполагаемые причины, по которым они включены или не включены:

  • UTF-8 является наиболее распространенным в международном обмене и предписывается стандартами HTML5 / WHATWG, поэтому он показан.
  • UTF-32 будет заявлять очевидное (одно кодовое слово, соответствующее кодовой точке), поэтому оно не отображается (если только кто-то не может утверждать, что сама строка скалярного значения Unicode учитывается). Он часто используется внутри (вне Windows), редко, если вообще когда-либо используется для обмена, и не разрешен в HTML5.
  • UTF-16 аналогичным образом заявляет об очевидном, если все коды находятся в базовой многоязычной плоскости, поэтому он отображается только в том случае, если хотя бы один из них не является. Иногда он используется для обмена и включается (с некоторой неохотой) WHATWG.
  • BOCU-1 не может быть осмысленно показан, поскольку последовательность кодирования является функцией как самой кодовой точки, так и предыдущей кодовой точки в потоке.
  • Punycode работает со строкой в ​​целом, а не строго по кодовой точке за кодовой точкой, и поэтому аналогично не может быть осмысленно показан.
  • SCSU потребуется больше, чем просто одна строка таблицы, чтобы обрисовать различные способы доступа к данному символу, и префиксы, необходимые для этого из различных начальных состояний: это было бы чрезмерным весом для кодировки, которая обычно используется только для внутреннее хранилище, а не обмен.
  • UTF-7 - это в значительной степени специализированная схема защиты ASCII для потока UTF-16. Это запрещено в HTML5. Теоретически это могло быть указано (в том же смысле, что преобразование Quoted-Printable UTF-8 могло быть указано отдельно), но, вероятно, не должно.
  • LMBCS, хотя и является почти UTF в своей текущей версии, в значительной степени предшествует Unicode как концепции и, как следствие, имеет несколько кодировок для многих символов, большинство из которых тривиально связаны с другими кодировками, которые, вероятно, уже перечислены вручную.
  • UTF-EBCDIC мог бы быть указан, но, поскольку он, по-видимому, относительно редко встречается даже в системах EBCDIC и неслыханно в других местах, вероятно, не должен. Единственное место, где я думаю, что он указан на данный момент, - это знак At § Unicode , где он находится просто в заголовке строки, дающей список вариантов EBCDIC, использующих эту конкретную однобайтовую кодировку для символа.
  • CESU-8 (UTF8mb3) на самом деле представляет собой испорченный UTF-8, унаследованный от некоторых систем баз данных (и TCL / Tk), а не то, что предполагается использовать. Это запрещено в HTML5 как отдельная кодировка (и в своем определении UTF-8 стандарт кодирования WHATWG ограничивает диапазон первого байта продолжения после определенных ведущих байтов, чтобы исключить как чрезмерно длинные кодировки, так и суррогатные коды).
  • UTF-1 был заменен на UTF-8 и удален из ISO 10646; UTF-5 и UTF-6, поскольку предложения были отклонены в пользу Punycode; UTF-9 был всего лишь первоапрельской шуткой (а сопутствующий UTF-18 даже не является полным UTF: он даже не закодировал все неприкосновенные блоки с тех пор, как Unicode 13 вышел в начале этого года).

Что касается GB18030: это обязательный стандарт в материковом Китае, он включен в стандарт кодирования WHATWG, он указан в стандарте HTML как резервная кодировка по умолчанию для упрощенного китайского языка. Это также надмножество GBK, которое само по себе является надмножеством EUC-CN (8-битный GB 2312), которые являются основными устаревшими кодировками для упрощенного китайского (хотя GBK также адекватно поддерживает традиционный китайский и японский, и оба они поддерживают русский и Болгарский).

По сути, есть несколько способов взглянуть на это:

  1. Это UTF, используемый для обмена, поэтому он должен появляться везде.
  2. Это кодировка CJK, и она должна быть указана в полях, в которых перечислены другие кодировки CJK, такие как варианты Shift JIS, а также те, которые характерны для покрытия GB 2312 (то есть упрощенные формы материка).
  3. Это модификация GBK для полного охвата, и ее следует указывать в полях для символов из сценариев, которые хотя бы частично покрываются GBK (например, римский, греческий, кириллица, kana, hanzi, zhuyin).
  4. Это стандартная кодировка материкового Китая, и ее следует указывать для символов из сценариев, используемых в материковом Китае, доминирующей группой или иным образом (например, ханзи, римский / пиньинь, тибетский, монгольский, уйгурский арабский…)

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

Для защиты систем письма [ править ]

Мы боремся с вандализмом в вики, поэтому мы должны бороться и с вандализмом систем письма в реальности: https://forum.unilang.org/viewtopic.php?f=1&t=57993

Это обычная российская практика, кстати:

  • https://lenta.ru/articles/2004/11/16/language/ (на русском языке) - «криминализованная латынь», «запрещен любой переход на латынь»
  • https://en.wikipedia.org/wiki/Lithuanian_press_ban
  • https://en.wikipedia.org/wiki/Ems_Ukaz#Yaryzhka
  • и так далее, и так далее, и так далее ... - Предшествующий неподписанный комментарий добавлен Prognadzvy4ajn ( обсуждение • вклад ) 07:36, 28 августа 2020 (UTC)

RfC CPAC этап Odal форма - на Odal_ (руна) статьи [ править ]

На Обсуждении открыт RFC: Odal_ (rune) #RfC_CPAC_stage_Odal_shape . Возникает вопрос: «Следует ли в статье упоминать то, что некоторые источники отметили, что сцена CPAC имела внешний вид, похожий на Odal?». - dlthewave ☎ 03:50, 14 марта 2021 г. (UTC)

Abecedaria, numeraria и алфавитный акростих [ править ]

В недавней редакции глаголицы [1] я упомянул abecedaria, numeraria и алфавитную акростику (термины, использованные в источнике). Позже я подумал, что некоторые вики-ссылки будут полезны для таких технических терминов, и при быстрой проверке мне показалось, что имеет смысл связать abecedaria с Abecedarium, а алфавит acrostic с Abecedarius , я не нашел ничего подходящего для нумерарии, и они могут быть не актуальны для многих скрипты. Обе статьи abecedariu * имеют столь необходимое устранение неоднозначности друг для друга, но не включены в этот проект (по крайней мере, судя по шаблонам страниц обсуждения), и если их тема или это название достаточно общие, они могут извлечь выгоду из некоторого расширения. В настоящее время стихотворение с алфавитом перенаправляется на Абеседария, а песня с алфавитоместь своя собственная статья (касающаяся только недавних - «двух столетий» английских примеров, что в некоторой степени разумно; вероятно, некоторые акростики старого алфавита также пели в качестве мнемоники, но это кажется предположением и добавлением примеров для каждого современного языка кажется необоснованным). Я в основном ищу предложения по моему примеру и спрашиваю, не упускаю ли я чего-то (например, более общих терминов / статей о таких письменных источниках), требуют ли эти темы и упомянутые статьи большего внимания со стороны этого проекта и в целом для мнения кого-то в этой области (извините за возможный анаколутон). Personuser ( разговор ) 06:52, 23 марта 2021 (UTC)