Михаил Р.

А теперь расскажу как человек, который давно и плотно интересуется локализацией, но в глаза Unity не видел.
Локализация ДОЛЖНА храниться в простенькой базе «ключ-значение», это может быть INI, CSV, XML или что-то ещё. А то часто бывают половинчатые решения, когда общие строки локализуются, а прописанные где-то в скриптах — через зад (StarCraft первый). Или одна и та же строка служит и ключом чего-то, и выводимой локализованной строкой (Atreides/Ordos/Harkonnen в Dune II).

Существуют два основных подхода к локализации.

1. Есть так называемый «основной» язык, прописанный ПРЯМО в EXE-файле, ПРЯМО в скриптах игры и так далее. Локализация имеет вид
«Open»,cmd → «Открыть»
«The door is locked.»,level1 → «Дверь закрыта.»

Как вы видите, ключ состоит из двух частей: строки-оригинала и уточнения. Если ключ совпадает, а уточнение — нет, берём строку без уточнения, а если и таковой нет — то что угодно. А если и ключ не совпадает — берём непереведённую.

Адепты этого подхода — Gettext и Qt.

2. Даже первый язык наравне с остальными.
Cmd.Open → «Открыть»
Level1.Locked → «Дверь закрыта.»

Вариант 2.1: первый язык (обычно английский) используется как резервный, если локализации не нашлось.

Сам я в пользу второго подхода, но он сложнее.

САМАЯ простая база ключ-значение, чаще всего использовавшаяся на Java ME, где с памятью швах,— это простой линейный массив.
[0] Открыть
[1] Дверь закрыта.
Всё преобразование из человекочитаемых идентификаторов S_CMD_OPEN в номера происходит на машине разработчика, генерацией файла
constexpr unsigned S_CMD_OPEN = 0;

Какой из методов брать?
1. Насколько много локализации?
2. Есть ли скрипты, GUI-формы и прочие ресурсы, способные содержать строки локализации?
3. Насколько много больших текстов?
4. Если программа параллельно разрабатывается и переводится: насколько тексты стабильны? Первый подход совершенно не выдерживает ситуации, когда исходные тексты меняются.
5. Возможны ли неофициальные локализации? Метод 2 без уточнения 2.1, если программа «живая», исключает их.
6. Что поддерживается вашим движком из коробки?
7. Локализация встроена изначально, или приходится переводить неготовую к этому прогу?
8. Насколько много интерфейса? У интерфейса есть противная фишка: нужно расщеплять строки, то есть давать одинаковым строкам разный ID (Open=«Открыть», «Открыто» и т.д.), и первый поход по умолчанию объединяет, второй по умолчанию расщепляет.

И ма-ахонький апдейт. Есть ещё такое понятие, как сегмент — кусок МЕНЬШЕ локализуемого текста. То есть сегменты есть только на уровне комплекта локализации, в экспортированных текстах они склеиваются в единый текст. Обычно предложение или абзац. Сегментация используется в переводе больших текстов, особенно в интерфейсах, с такими целями.
• Существуют тексты-«козы», которые могут найтись в памяти переводов. Например: «Серп и молот символизирует крестьян и рабочих. Осторожно, в вашем законодательстве эта символика может быть запрещена.»
• Из-за недостатков интерфейса проги перевода можно пропустить целое предложение. Да, бывает!
• В «живых» программах — можно помечать плохо переведённым кусок меньший, чем целый текст.
(Живой я называю программу, которая параллельно разрабатывается и переводится. Благо методика «аджайл» предполагает частые небольшие выпуски.)

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

Да, так оно и работает.

или есть способы попроще

Проще уже некуда.

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

Похожий вопрос рассматривался здесь:
https://stackoverflow.com/questions/436220/how-to-...

Может помочь модуль chardet.

Пример работы модуля из документации:

>>> import urllib.request
>>> rawdata = urllib.request.urlopen('http://yahoo.co.jp/').read()
>>> import chardet
>>> chardet.detect(rawdata)
{'encoding': 'EUC-JP', 'confidence': 0.99}

Ну, во-первых - где был запрос - в браузере или системный? Во-вторых, и в браузере и в системе есть возможность посмотреть разрешения, выданные приложению (или сайту).

Kwork
FL.ru
Профи.ру
ХедХантер,
Авито
Фриланс чаты в ТГ

...из наших вроде всё

1. В России алгоритмы не патентуются.
Защищены только конкретные реализации (исходный код или железка, которая этот алгоритм реализует).

2. Текст на этом сайте распространяется под cc-by-sa, так что ты можешь спокойно скопировать оттуда текст, если соблюдешь условия

3. Если ты реализуешь этот алгоритм на каком-нибудь ЯП по человеческому описанию с сайта, то это уже будет новое произведение, а не производное => даже ссылка на оригинал не нужна.

Внизу странички есть лицензия
Материалы распространяются под CC BY-SA
https://creativecommons.org/share-your-work/cclicenses/

Алгоритмы в россии не патентуются, в отличии от их реализации в программе.
Система патентования запутанная, сложная.. но просто математические выкрутасы точно не патентуются. Тем более тема однозначно не подходит для коммерческой реализации,.. вот если кто то создаст на основе этого алгоритма крутую железку, которая будет в 2 раза быстрее перемножать числа, тогда да, вот ЭТУ реализацию можно патентовать

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

Зачем нужны такие программы? В чём смысл такой разработки?

но ты его минимум захотел установить, у тебя были альтернативы?

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

Не нужно. Это сродни операции замены человекопонятных имён переменных, полей и классов на рандомные комбинации букв i,I и тп aka обфускации. "защитой" должен заниматься другой слой например тот же самый jwt как носитель билета доступа, выдачу которого и проверку легитимности осуществляют другие механизмы (аутентификация, авторизация и т.п.)