Василий Банников

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

Исключение делают только азиатским языкам (китайский/корейский/японский), тк там очень низкая доля знания английского и графика опять же сильно отличается.

Можешь максимум проверку правописания на русском установить

но не будет ли возникать конфликтов в работе клиента и сервера,

Не должно. Просто разруливай по путям - что к бэку должно идти, а что на статику.

А чтобы "без порта" надо запускать на 80 и 443 порте.
Но если на этой же машине nginx стоит, то будет конфликт.

Совсем немного ускорит благодаря тому что по одному соединению в http/2 может идти несколько запросов одновременно.
=> Нужно будет открывать меньше новых соединений.
+ Он бинарный => всякие multipart запросы также будут передаваться в чуть более компактном виде.
+ В нём есть сжатие заголовков => заголовки тоже будут в более компактном виде идти.

Сделай вместо статического поля - виртуальное нестатическое свойство у которого будет только get.

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

Да, такое может быть. В таком случае цена заявки с такого источника будет ниже.

Когда мы суммируем сpa и сравниваем это может быть незаметно, и канал который за большие деньги принес меньше заявок может по сpa оказатся более выгодным, или я что-то неправильно считаю?

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

Незнаю понятно ли задал вопрос.

Покажи пример своих расчётов.

"непрерывно" - для этого тебе придётся дома резервирование интернета сделать и резервный источник энергии.

"Без лагов" - для этого тебе нужно будет поближе к серверам телеги его расположить - в идеале в ДЦ (тогда сразу и вопрос резервирования решается) и чтобы мощности хватало с запасом.

Так что посмотри, сколько твой бот жрёт на твоём компьютере под нагрузкой (прикинь какая нагрузка будет при работе) и подбери соответствующее железо.

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

pair - массив из двух элементов или объект с двумя полями.
["a", "b"]
{"fst": "a", "snd": "b"}

map<string, vector<float> > Объект или Map у которого в качестве значения - массив, а в качестве ключа-строка.
{"a": [1.2, 3.5]}

map<pair<string, string>, float> С этим сложнее, тк что массивы, что объекты в js сравниваются по ссылке => вариант того, как мы представляем pair сам по себе не подойдёт.

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

const map = {};
const a = "abc";
const b = "123";
const key = `${btoa(a)}$${btoa(b)}`;
map[key] = 42;

Есть разные алгоритмы консенсуса.

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

В случае если сеть не приходит к консенсусу - происходит форк: часть пиров будут продолжать одну цепочку, а часть - другую.
Рано или поздно одна из цепочек станет более длинной и конфликт исчезнет.

А вот если конфликт системный (например из-за несогласия людей), то может произойти хард-форк, и тогда это уже две разные сети.

Какой конкретно алгоритм консенсуса в биткоине предусмотрен - не скажу.

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

оставшись безнаказанным, верно?

Неа.

Компания уже не очень хорошо поступает с человеком, поскольку не оплачивает его работу

Ваш друг не в рабстве и сам согласился на эти условия. Да, это не по ТК, но его никто не держит и если ему не нравится, что он бесплатно работает - он может спокойно собрать вещи и уйти обратно на рынок труда.
А ещё часто неоплачиваемую стажировку как образовательные/консультационные услуги оформляют => может оказаться, что стажировка не то чтобы бесплатная, так ещё и должен остаёшься при несоблюдении каких-то условий)
(Хотя подобные пункты почти всегда через суд признаются кабальными и ничтожными)

PS: ну и я сомневаюсь, что он ничего не подписывал. В зависимости от конкретной ситуации и грамотности юристов - можно очень много весёлых уголовных статей навесить)

Нет.

нет возможности редактировать DNS записи

Это не большая проблема, да и в принципе это не входит в обязанности регистратора. Просто делегируй домен на какой-нибудь сторонний dns-хостинг (например я yandex cloud DNS пользуюсь)

не выдают документ о владении доменом

Наверное из-за того что таких документов в принципе не существует, из-за того что домен не является объектом собственности.

canary - это собственно канареечная версия. Всегда самая свежая версия, но стабильность и адекватность не гарантируется.

Любые, какие не противоречат закону, и какие по силам этому новичку.