VoidVolker

Легко - ставите расширение TemperMonkey и добавляете следующий скрипт в него:

// ==UserScript==
// @name         Исправление текста
// @namespace    http://tampermonkey.net/
// @version      2024-10-22
// @description  Заменяет все английские буквы во всех текстах на русские
// @author       VoidVolker
// @match        https://24forcare.com/*
// @icon         https://www.google.com/s2/favicons?sz=64&domain=24forcare.com
// @grant        none
// ==/UserScript==

;(function () {
    'use strict'
    $(function () {
        console.log('Скрипт запущен в работу...')

        // Английские символы
        let en = 'ABCEHKMOPTXYabcehkmoptxy'
        // Русские символы
        let rus = 'АВСЕНКМОРТХУавсенкмортху'
        // Таблица замены en -> ru
        let map = {}
        en.split('').forEach((char, i) => (map[char] = rus[i]))

        // Счетчик замен
        let charsCounter = 0
        let nodesCounter = 0

        // Нормализовать текст
        // В идеале следовало бы извлечь из текста слова
        // И уже в словах проверять наличие разных символов 
        function normalizeEn2Rus(str) {
            // Конвертируем строку в массив
            let arr = str.split('')
            // И проходим по всем символам в массиве
            for (let i in arr) {
                // Получаем символ
                let char = arr[i]
                // Если символ найден - заменяем его, если нет - оставляем оригинальный
                arr[i] = map[char] ?? char
                charsCounter++
            }
            // Конвертируем массив в строку и возвращаем результат
            return arr.join('')
        }

        // Получаем список всех элементов на странице
        let items = $('*', document.body)

        // Проходим по всем элементам
        items.each((i, item) => {
            // Исключаем ссылки, скрипты и стили из поиска
            if (item.nodeName === 'A' || item.nodeName === 'SCRIPT' || item.nodeName === 'STYLE') { return }
            // Получаем список детей у элемента
            Array.from(item.childNodes)
                // Фильтруем только текстовые элементы и те, в которых есть текст
                .filter((el) => el.nodeType == Node.TEXT_NODE && el.textContent?.length > 0)
                .forEach((el) => {
                    // Нормализуем текст элемента
                    el.textContent = normalizeEn2Rus(el.textContent)
                    console.log(el.textContent)
                    nodesCounter++
                })
        })

        console.log(`Скрипт завершил работу успешно. Всего заменено символов [${charsCounter}] в [${nodesCounter}] текстовых элементах.`)
    })
})()

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

Если он подходит по размерам и ТТХ - то вполне можно, почему нет-то?

Да, конечно можно проверить работу каждой фичи и функции ручками. Это если у тебя три-пять фич/функций, ну десяток еще можно, а изменения - раз в неделю. А если это надо делать на каждый коммит? Десять коммитов в день? А как проверять, если там 100 экранов, на каждом экране по сотне графических элементов, у которых по пять состояний в различных вариантах, два десятка эндпоинтов в бэкэнде, а в коде паутина из 10-100к функций и хрен знает сколько зависимостей? Итого 100 x 100 x 5 x 20 - уже миллион вариантов. Ой, а у нас там еще есть отдельная админка для этого вот всего, биллинг, мониторинг, отчеты, интеграция с тремя десятками платёжных систем и бакнов, почта, интеграции с мессенджерами, кэширование, резервирование, бэкапы и еще пара сотен зависимостей и интеграций с другими системами. Сколько месяцев или даже лет ручного труда потребуется для ручной проверки работы такого проекта в каждом коммите за время работы команды из десяти разработчиков в течении хотя бы одной недели?

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

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

А еще есть такая методика, как TDD: разработка через тестирование - сначала создаётся тест на фичу, а уже только потом создаётся сама фича.

Подойдёт ли Windows Forms? Мне ведь потом на мобилку порт делать.

Формы - это .Net и только для винды. Причем это уже очень старое легаси, которое имеет смысл использовать только для поддержки Windows XP - а у нас тут уже поддержка 10 заканчивается так-то. А .Net - это прежде всего C#. И вот на C# есть более новый WPF и кроссплатформенный MAUI. Для мобилки все равно придется переписывать с нуля или искать какие-то варианты решений, которые могут C# в мобилки.

Или на мобилку лучше не на C++ делать? Что посоветуете?

Не самое лучшее решение - там родная платформа Java и Swift. Qt умеет: https://doc.qt.io/qt-6/mobiledevelopment.html - но как оно там в результате будет работать сложно сказать и можно ожидать каких-нибудь слабопрогнозируемых глюков и сложностей. Спасибо Adamos.

Может кому-то известны нюансы при постройке такой программы?

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

В общем, у вас несколько вариантов. Вариант раз: если хотите именно плюсы - то вам следует использовать Qt и писать код сразу с учетом дальнейших доработок для работы в Linux, Mac и на мобилках - не знаю, как и на сколько хорошо Qt умеет в мобилки, но могут быть какие-то сложности/баги. Ну, в кроссплатформе от этого не уйти - придётся мириться и местами писать разный код для разных платформ.

Вариант два: если хотите сразу писать приложение сразу для всех платформ с единой кодовой базой и минимальными услиями - то можно использовать веб-платформы типа NWJS, Cordova и прочие браузерные платформы. Минус - приложение будет тяжёлым и ощутимо более медленным, чем нормальное нативное.

В целом, могу рекомендовать для начала просто сделать на плюсах с Qt хоть какое-то приложение для винды, далее внести доработки для работы в линуксе и маке. При наличии/доступности мака - можно сразу и для мака делать. Линукс прекрасно ставится и работает в VirtualBox и прочих виртуализаторах. Далее сделать поддержку сетевых фич, БД и прочего, а уже только потом переключаться на разработку для мобилок. При этом, вам надо будет организовать свой план разработки от меньшего к большему. Т.е., сначала самые простые функции делаете, а уже потом к ним добавляете что-то более сложное по мере изучения.

Да, есть: пачка денег плюс задача на фрилансе.

В принципе любой. Если ближе к образцу - то он на JS. Для веб полно графических либ и движков.

RTFM: Number.prototype.toFixed()

Return value
A string representing the given number using fixed-point notation.

UPD:

А как быть, если нужно сделать и toFixed() и toLocaleString('ru-RU')? К примеру, отобразить 1234.567 с точностью пять знаков и форматированием toLocaleString() (1 234,56700)?

Использовать Intl.NumberFormat():

new Intl.NumberFormat(undefined, { maximumFractionDigits: 5, minimumFractionDigits: 5 }).format(1234.567)
> "1 234,56700"
new Intl.NumberFormat('ru-RU', { maximumFractionDigits: 5, minimumFractionDigits: 5 }).format(1234.567)
> "1 234,56700"

Обычный скрипт на хоткей или, вероятнее, расширение какое-нибудь. В первых же ссылках гугла: https://marketplace.visualstudio.com/items?itemNam...

Самый простой и надёжный способ: поставить Windows, далее поставить в нём VirtualBox, а уже внутри виртуалбокса поставить любой линукс и спокойно его использовать с любыми опциями и не бояться сломать все, что есть. Виртуалки легко переносятся между разными машинами и легко бэкапятся/дублируются. Любая установка двух ОС на один ПК - это уже сам по себе геморрой и зависимости ОС одна от другой, когда ЛЮБОЕ обновление ЛЮБОЙ ОС легко ломает одну, вторую или обе ОС сразу. Вы же хотите мало того, что поставить их на один диск, так еще и зашифровать и второй диск тоже поделить на две части и для двух разных ОС - этим вы поднимаете градус геморроя в два раза за каждый диск и еще в два раза за шифрование. Оно вам надо? Не, если есть желание на практике освоить ручное восстановление разделов, загрузчиков, таблиц разделов, шифрования и прочего - то вперед, ставьте, осваивайте. Но только обязательно делайте ежедневный бэкап на отдельный носитель важны данных. В общем, я крайне не рекомендую так делать без понимания как оно всё вместе работает и знаний и опыта восстановления в случае, если что-то сломается. В идеальном варианте две ОС ставятся следующим образом: подключается целевой диск, ставится одна ОС, физически отключается, подключается второй диск во второй порт, ставится вторая ОС, подключается обратно первый диск и далее вручную добавляются записи загрузчиков обеих ОС друг к другу (ибо поведение дистрибутивов ОС при установке если уже есть другая ОС абсолютно непредсказуемо и там может произойти все что угодно). На случай если один загрузчик/ОС или диск сломаются - второй будет работать.

RTFM:
https://yandex.ru/dev/jsapi-v1-1/doc/ru/examples/
https://yandex.ru/dev/jsapi30/doc/ru/dg/concepts/map
Или исправить исходные данные:

var center = [56.964949, 60.623745]
...
    center: center,
    zoom: zoom

Или распарсить их:

var center = '56.964949, 60.623745'
...
    center: center.split(', ').map(parseFloat),
    zoom: zoom