Typo ellipsis, или роботы на защите многоточий

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

Eddy_Em, saahriktu, Lavos, принимайте пополнение в свои ряды.

Только полный дебил будет в исходники хрюникод лепить!

Нормальный приятный код: https://www.stackage.org/haddock/lts-8.11/configuration-tools-0.2.15/src/Conf...

Нет, ненормальный.

Это и не традиционная «математическая» запись, и не традиционный «код». И для математика, и для программмиста читать это мучительно.

Если бы формулы в коде записывались в обычном виде, типа https://files.catbox.moe/f7ly90.png или там https://files.catbox.moe/5qfp03.png - было бы гораздо нагляднее

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

в программировании русский язык не нужен

http://программирование-по-русски.рф/static/для-ИА/содержание.яргт

http://

В топку сразу.

да, юникод и всякая национальная маргинальщина в url'ах тоже ненужны. не пользуюсь принципиально.

Только полный дебил будет в исходники хрюникод лепить!

Ну я вот в одном месте исходников привёл список контрибуторов, и фамилию автора норвежского перевода (букмол, да) написал так, как он сам себя пишет (Allan Nordhøy). Как видим, присутствует юникодный символ. Я полный дебил или проявил уважение к человеку?

Или мне стоило отдельный файл ресурса заводить для этого списка контрибуторов? (По сути, тоже исходник, только не на C++.) Оверхедно как-то...

Заведи что-нибудь вроде Readme.utf32, туда и пиши всякую непотребность...

а фамилии можно операторами латеха записывать: Nordh{\o}y.

потому что несколько человек пишут всё в проекте на ASCII, а другое сексуальное меньшинство – покрывают всё свистопердящими стрелочками и emoji из Unicode

По-хорошему редактор сам должен заменять <= на ≤, ибо логически одна сущность и она прекрасно отображается в виде одного символа.

Через неделю он забудет про эти ellipsis’ы и в коде снова появятся ASCII-многоточия

Автозамена, опять же, или ворнинги, чтобы автор сам запилил.

если скормить такие исходные тексты компиляторам с некоторых не особо популярных платформ

Автор не исходники лялиха пилит, чтобы запускать их на кофеварках.

Ну кофеварка не кофеварка, а вот под какой-нибудь Raspberry Pi мне в будущем хотелось бы свой проект собрать (впрочем, на ней, подозреваю, проблем быть не должно).

под какой-нибудь Raspberry Pi

Под RPi или на RPi? Вопрос — тонкий намек на кросс-компиляцию.

Эм, а есть принципиальная разница в свежести инструментария?

Ну я вот в одном месте исходников привёл список контрибуторов, и фамилию автора норвежского перевода (букмол, да) написал так, как он сам себя пишет (Allan Nordhøy).

А должен был написать в исходниках Allan Nordhoy, а в файле перевода en_US.ts или подобном – Allan Nordhøy. Для этого они и созданы. Аналогично с копирайтами – В исходных текстах – (c), в файле перевода – Ⓒ.

По-хорошему редактор сам должен заменять <= на ≤, ибо логически одна сущность и она прекрасно отображается в виде одного символа.

Это если у проекта ровно один контрибьютор. А если их множество, то у кучи человек разные редакторы и разные настройки. В итоге в кодовой базе получается каша из ..., … и прочее непотребство из-за которого поиск по коду будет сильно затруднён.

Одно дело лигатуры шрифта, которые отображают <= как ≤, против них ничего не имею, другое дело – засирать исходники как символами <=, так и ≤.

Автозамена, опять же, или ворнинги, чтобы автор сам запилил.

Автозамена тут должна быть только в одну сторону – проверка файла на содержание Non-ASCII и приведение его к порядку.

Прошло 4 месяца. С тем же самым вопросом вылезло уже 2 человека. Причём на сей раз уже точно не боты и не скоронабиватели. Один пилит французский перевод, другой норвежский (тот самый Allan Nordhøy). От них отдача проекту точно есть, не отмахнёшься.

Мода, что ли по Европе пошла, что без многоточий жизнь не мила… Французу я ответил пока, что если я всё руками заменю, то во-первых, уйду от ASCII, во-вторых, что меня больше напрягает, подкину работу переводчикам. В lupdate ведь, как я понимаю, интеллектуальной замены нет, оно просто все старые переводы отметит как obsolete и добавит новые позиции, непереведённые от слова «совсем». И переводчикам их переводить с нуля. Или я чего-то про Лингвист не знаю?

Идея с en_US.ts выглядит многообещающе, кстати. Т.е. сырые строки из программы не показывать вообще, даже англоязычным, и сделать «перевод» и для них. Болванка для такового, кстати, в translations у меня валяется, только пустая пока…

Сижу, думаю грустно.

И поскольку у большинства в трекере темы отсортированы по первому сообщению, а не по последнему, кастую ещё alex-w и DarthVadimius.

И поскольку у большинства в трекере темы отсортированы по первому сообщению, а не по последнему, кастую ещё alex-w и DarthVadimius.

А я тут причём?

При том, что участник очень известного Qt-проекта с кучей переводов. :)

При том, что участник очень известного Qt-проекта с кучей переводов. :)

Для гуя мы используем юникод, да только в весьма ограниченном варианте (зачастую через QChar() что-то ставим) из-за того, что на разных платформах заявлено одинаковое представления юникода, а на деле оно разное и… не везде юникод есть в полном объёме. Сам код у нас ASCII, а вот комментарии и строки, которые отдаём пользователям - в юникоде. Ну и файлы в юникоде.

Что касается сборки, то GCC/Clang/MSVC/ICC собирают Stellarium без каких-либо проблем. LCC от МЦСТ тоже собирает без проблем, если грохнуть из исходников BOM, ну или в 23-й ветке lcc использовать ключик –ignore-utf8-bom

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

Спасибо!

Сам код у нас ASCII, а вот комментарии и строки, которые отдаём пользователям - в юникоде. Ну и файлы в юникоде.

Наверное, в эту сторону и буду выруливать…

P.S. Только сейчас увидел, что в похожих темах ЛОР-ИИ предлагает различные «ЗАЩО». Да, действительно. :)

Сижу, думаю грустно.

Найти все не ASCII-символы в кодовой базе можно с помощью чего-то вроде:

grep --color='auto' -P -n '[^\x00-\x7F]' -r src/main/

После чего планомерно их заменить.

нафига в CPP/H то использовать юникод? .ui для того и существуют, что бы там. Код на c++ - это ascii < 127 , чо за фигню там пытаются насаждать в любимый с++

typo ellipsis, added
typo ellipsis, added
typo ellipsis, added
typo ellipsis, added
typo ellipsis, added

совсем с дуба рухнули не сквошить такое, пусть идет в сад - формальный повод не принимать такую срань.

В топку сразу.

смищно)

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

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

чо за фигню там пытаются насаждать в любимый с++

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