Консольное приложение нацелено на .NET Core 2.1, сама библиотека для .NET Standart 2.0. Если не запускается под линухой, значит там устаревшая версия .NET Core.
Как вариант, можно перенацелить проект на более старую версию коры, должно работать.
На самом деле, «осемнадцать» – интересный пример. Казалось бы, возможно равное сопоставление как с «восемнадцать», так и с «семнадцать», но добавление буквы «в» стоит немного дешевле, чем удаление «о», т.к. длина токена «восемнадцать» больше на 2 символа, получаем 1 / 12 (0.083) против 1 / 10 (0.100). Поэтому однозначный ответ – 18 с величиной ошибки 0.083.
Сначала я использовал третью версию tesseract. Белый список символов позволил хорошо распознавать сами числа, но не текст прописью. Для некачественных изображений ситуация была ужасная. Кроме того, пенальти для слов не из словаря, – нерекомендуемое средство, оно не только не улучшает разбор, а напротив, зачастую ухудшает его.
Переход на четвертую версию позволил достаточно хорошо распознавать как числа, так и текст. Но в четвертой версии, по крайней мере пока, не поддерживается белый/черный список. Единственный вариант, как можно повлиять на разбор – переобучить tesseract, а это достаточно сложный процесс.
В целом же четверка дает значительно более качественный разбор, чем тройка при меньшем времени обработки, что для моей задачи критично.
Разумеется. Если в слове «жук» сделать две ошибки, то получится «ежик», и хотя это совершенно разные слова, с точки зрения программы они отличаются лишь наполовину.
Алгоритм помимо значения возвращает величину ошибки в пределах от 0 до 1. По ней можно сделать вывод, считать ли полученное число нужным Вам результатом или нет.
Схема, создаваемая в редакторе на фронте, будет использоваться в бэке для обработки данных. Информация о типах пригодится для воссоздания классов на языке обработчика.
Другими словами, будет аналогичный десериализатор этой схемы на другом объектно-ориентированном языке.
А как это решит проблему с сохранением информации о типах? К тому же придется везде писать свою реализацию toJSON и поддерживать ее в дальнейшем. В моем варианте ничего дописывать не надо.
Во-первых, и это самое главное, я хотел рассказать о динамических функциях и байт-коде. Это только один из примеров, где их можно использовать.
Во-вторых, строковые метки, как выразился автор первого комментария, требуют кода, который будет сопоставлять их со значениями из модели. В шаблонизаторе этого не требуется. Кроме того, можно передать в модель заведомо избыточную информацию (данные о пользователе — порядка 30 параметров, данные о рассылке, данные о системе), а автор шаблона, который вообще говоря не является программистом, сам решит, какие поля ему нужны в шаблоне, а какие нет.
В-третьих, задача не одноразовая. В различных вариантах мне приходилось решать ее и ранее.
Еще пользуемся понятием Боевая система («выложить на боевой»), выше упоминалась, остальное — русские варианты английских терминов и образованные от них слова: таск (задача в TFS), закоммитить, запостить, отдебажить, хардкорный и т.д…
Сленга практически не употребляем, за исключением слова костыль. В этом плане у нас скучновато )
Возможно, я неформал, но очень не люблю таскать чужие библиотеки в своих проектах. Уж извините, такая у меня слабость.
Но вы подкинули хорошую идею. Добавлю в библиотеку возможность подстановки полей классов, если соответствующий аргумент является классом. В моем синтаксисе это будет выглядеть примерно так: %0.Name%
Да, читал о нем, но его функционал не подходит для моего проекта. Там есть только поддержка множественного числа и ничего более.
А для меня важно было иметь возможность расширения функционала пакетов своими функциями, возможность подгрузки и смены пакетов «на лету», возможность, в конце концов, использовать числа в качестве идентификаторов. Последнее имеет принципиальное значение при передаче сообщений между клиентом и сервером — не будете же вы передавать по сети длинную строку идентификатора вместо компактного числа.
Зачем переводчику заменять названия функций? Это нелогично, т.к. функции оформлены спец-символами, а именно %Plural(%0, "str1", "str2", "str3")%
Но если это все же произошло (например, написали %Множественный(%0, "str1", "str2", "str3")%), интерпретатор выдаст исключение о том, что функция «Множественный» не найдена.
Плюс, при желании, можно добавить свои функции или переопределить уже существующие, например так:
И в дальнейшем использовать наиболее удобный псевдоним.
Хотя, надо признать, сейчас не реализована полная проверка синтаксиса строк, и если допустить ошибку (забыть знак %), то в некоторых случаях программа упадет.
В DEBUG-версии библиотеки при попытке получения строки с несуществующим идентификатором, будет возвращено пустое значение, но сама строка при этом будет создана и при завершении работы программы эти изменения можно будет сохранить.
Но лично я вижу более удобное решение, которое уже реализовано в другом проекте, где используется эта библиотека, а именно: коды строк, их значения и краткие описания (для переводчиков) хранятся в Excel-файле, а специальная программа по требованию парсит его и генерирует для каждого листа класс-набор констант, примерно так:
public static class STR_COMMON
{
public const int Welcome = 0x00000001;
public const int ServerUnavailable = 0x00000002;
public const int ConnectionRefused = 0x00000003;
// и т.д.
}
Заодно пополняет словарь локализации, в программе остается вызывать только package[STR_COMMON.Welcome] и строка получена.
Для потенциального переводчика надо будет только перевести тексты сообщений в Excel-файле для получения локализации на другом языке.
Как вариант, можно перенацелить проект на более старую версию коры, должно работать.
Один из пользователей пообещал расписать правила для немецкого, для английского я и сам сделаю.
Если у кого есть желание, можете прислать мне на почту правила для интересующего вас языка (другими языкам я не владею), а я запилю конвертер для них.
Это тысяча.
Переход на четвертую версию позволил достаточно хорошо распознавать как числа, так и текст. Но в четвертой версии, по крайней мере пока, не поддерживается белый/черный список. Единственный вариант, как можно повлиять на разбор – переобучить tesseract, а это достаточно сложный процесс.
В целом же четверка дает значительно более качественный разбор, чем тройка при меньшем времени обработки, что для моей задачи критично.
Алгоритм помимо значения возвращает величину ошибки в пределах от 0 до 1. По ней можно сделать вывод, считать ли полученное число нужным Вам результатом или нет.
Другими словами, будет аналогичный десериализатор этой схемы на другом объектно-ориентированном языке.
Для моей текущей задачи даже имеющийся функционал избыточен, а интерфейс был дописан специально для статьи.
Во-вторых, строковые метки, как выразился автор первого комментария, требуют кода, который будет сопоставлять их со значениями из модели. В шаблонизаторе этого не требуется. Кроме того, можно передать в модель заведомо избыточную информацию (данные о пользователе — порядка 30 параметров, данные о рассылке, данные о системе), а автор шаблона, который вообще говоря не является программистом, сам решит, какие поля ему нужны в шаблоне, а какие нет.
В-третьих, задача не одноразовая. В различных вариантах мне приходилось решать ее и ранее.
Толстый клиент — десктопное приложение, локальный клиент, АРМ.
Тонкий клиент — веб-версия.
Еще пользуемся понятием Боевая система («выложить на боевой»), выше упоминалась, остальное — русские варианты английских терминов и образованные от них слова: таск (задача в TFS), закоммитить, запостить, отдебажить, хардкорный и т.д…
Сленга практически не употребляем, за исключением слова костыль. В этом плане у нас скучновато )
Но вы подкинули хорошую идею. Добавлю в библиотеку возможность подстановки полей классов, если соответствующий аргумент является классом. В моем синтаксисе это будет выглядеть примерно так:
%0.Name%А для меня важно было иметь возможность расширения функционала пакетов своими функциями, возможность подгрузки и смены пакетов «на лету», возможность, в конце концов, использовать числа в качестве идентификаторов. Последнее имеет принципиальное значение при передаче сообщений между клиентом и сервером — не будете же вы передавать по сети длинную строку идентификатора вместо компактного числа.
%Plural(%0, "str1", "str2", "str3")%Но если это все же произошло (например, написали
%Множественный(%0, "str1", "str2", "str3")%), интерпретатор выдаст исключение о том, что функция «Множественный» не найдена.Плюс, при желании, можно добавить свои функции или переопределить уже существующие, например так:
И в дальнейшем использовать наиболее удобный псевдоним.
Хотя, надо признать, сейчас не реализована полная проверка синтаксиса строк, и если допустить ошибку (забыть знак %), то в некоторых случаях программа упадет.
Но лично я вижу более удобное решение, которое уже реализовано в другом проекте, где используется эта библиотека, а именно: коды строк, их значения и краткие описания (для переводчиков) хранятся в Excel-файле, а специальная программа по требованию парсит его и генерирует для каждого листа класс-набор констант, примерно так:
Заодно пополняет словарь локализации, в программе остается вызывать только package[STR_COMMON.Welcome] и строка получена.
Для потенциального переводчика надо будет только перевести тексты сообщений в Excel-файле для получения локализации на другом языке.