Pull to refresh

Comments 27

Спасибо, интересно было почитать! Я реализовал так: на английском спрашиваю на старте на каком языке человек хочет получать новости (de, es, fr, ru, en), далее либо всё на русском, либо на английском, а источники новостей будут на выбранном языке. Ну и в коде текст тоже как одна переменная, которой присваивается значение исходя из выбранного языка.

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

Да, думал об этом, добавлю выбор языка интерфейса первым делом после старта. Я явно пока не делал функционала подсчёта, просто захожу в БД и вижу пользователей, а в лог пишутся команды, которые они выполняли, кстати много поправил исходя из этого. Юзеры творят нереальную, нелогичную дичь. Я больше самоучка в Java, поэтому удивляюсь :)) Планирую снять видео с обзором бота и кодом. Кстати классный у Вас бот, заценил!

Спасибо, надеюсь бот будет становиться только лучше.
Да, пользователи непредсказуемы. Кстати по вашему комментарию я задумался, что до этого интересовался только "чем занимаются пользователи в кокой-то точке бота" и упустил, что возможно интересно посмотреть чем заснимается пользователь в боте. Т.е. посмотреть путь движения пользователей по боту. Надо будет добавить и поанализировать.

Отдельное спасибо за статистику. Я тоже проводил подобный анализ. Скажу что с иностранными пользователями еще все хуже. У меня почти 90% русскоязычных пользователей. Остальные с английским языком.

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

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

Вы абсолютно правы. Я использую эту логику для определения языка для приветствия. Тут больше вопрос что делать если человек пришел к примеру на Болгарском, что ему показывать? Делать на все случаи жизни очень дорого.

Кстати да, вот так можно! Прикрутим, спасибо! Главное проверить, что languageCode не пустая.

в некоторых случаях поле language_code сообщения от телеграм действительно может быть пустым - тут как раз заменить на язык "по умолчанию" и вперед

А почему не стали использовать i18n? Это вроде стандарт для таких вещей, может конечно для чего-то маленького и нет смысла его использовать, но интересно причину узнать.

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

А зачем нагромождение if elif else, если только 2 языка? Разве if else не достаточно будет?

Это как раз явное указание официальности английского языка в боте. Чтобы при расширении не забыть. Но для текущей реализации вы абсолютно правы - elif избыточен

Для своих телеграм-ботов я решил вопрос с локализацией, например, вот так: https://github.com/GrakovNe/kindle-sideload/blob/main/src/main/kotlin/org/grakovne/sideload/kindle/telegram/localization/LocalizationService.kt

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

То есть, чтобы добавить поддержку нового языка, мне нужно взять оригинальный ресурсный файл, например, https://github.com/GrakovNe/kindle-sideload/blob/main/src/main/resources/messages.json и скопировать его с нужным постфиксом, локализовав содержимое, а потом сделать то же самое с текстом кнопок в другом ресурсном файле

Это избавляет от перебора через if-else-if, паттерн-матчинга и любых других механизмов, которые хардкодят набор языков в коде

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

Спасибо, полистал ваш код и задумался. Действительно при старте я могу по имеющимся ресурсам (автоматом выделяя все языки) создать словарь типа
lexicon = { 'ru' = LEXICON_RU, 'en' = 'LEXICON_EN', ...}
и тогда функция перевода get_text можно написать в 1 строчку
return lexicon.get(lang, lexicon['en']).get(param,param)
это сделает автоматическим добавление новых языков в функцию перевода, при добавлении ресурсных файлов нового языка
Благодарю
я в kotlin не силен, а не накладно на каждое сообщение загружать темплейт с проверкой ресурсов? Просто если 100 чел сниферят по боту - это все поток сообщений.

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

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

В том коде, что я скинул работает очень наивная реализация: при получении пачки апдейтов апплик начинает процессить каждое входящее сообщение и типа-параллельно (на корутинах) отвечать на них чем-то. Для моего бота с конвертером книжек и другого, который трекает swift-платежики и имеет около 500 пользователей в день, этого хватает с лихвой на самом дешевом железе DigitalOcean.

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

Короче говоря, вариантов много и все это системные подходы, которые порешают именно время обработки сообщений от входа до выхода, а не точечно пофиксят момент парсинга файлов ответа

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

Но оптимизировать болезни производительности стоит при их наличии) - это правильно. Меня как человека, начинавшего писать по микроконтроллеры в 2000-х на подкорке сидит забота о ресурсах, т.к. о "докинуть нод" в МК речи не шло :)

В своем боте сделал перевод с помощью ии (подходят gemini pro и chatgpt instruct).

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

bot_reply_tr(message, 'Сообщение юзеру.', 'подсказка для переводчика')

Язык юзера берется из message(язык интерфейса телеграм клиента), или из БД если он менял настройки, переводы кешируются что бы не дергать ии лишний раз, если ии сфейлился (запрещенка) то перевод отдается в гугл транслейт.

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

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

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

https://github.com/theurs/tb1

Круто там у вас все. Мой хост с 1 ядром и 2ГБ без GPU точно не потянет собственное ИИ. Если я все правильно понял, вы используете внешние инстансы ИИ? Это платные аккаунты или бесплатные? Просто в боте я стараюсь руководствоваться тем, чтобы он не тянул из меня денег. У меня есть задача, в которой без ИИ похоже не обойтись, но пока это большие задержки и стоимость. Буду благодарен за наводку для перевода.
И еще вопрос при завышении "температуры" не получится так что интерфейс будет менять под настроение ИИ? Типа генерироваться новые надписи.

Там же, судя по описанию, все надписи генерируются один раз при первом запросе и сохраняются в локальном кэше/базе. И их потом даже вручную поправить можно, если ИИ облажался.

gemini pro сейчас бесплатно работает. Будет(а может не будет) стоить примерно как чатгпт, копейки если учесть что перевод 1 раз делается.

не, мне под другие задачи (у меня есть сервис конвертора информационных СМС) с постоянной нагрузкой на перевод. Поэтому если сможете подсказать бесплатные альтернативы - буду признателен. Про Gemeni Pro понял - посмотрю

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

Если взять какое-нибудь отечественное яндексгпт и посчитать сколько стоит перевод короткой фразы то получится что то типа такого

(20 + 32) × 1.0 × ($0.0032/1000) = $0.000166 = 0.0146р

Where:

  • 20: Number of prompt tokens.

  • 32: Number of response tokens.

  • 1.0: Multiplier for using the YandexGPT Lite model in synchronous mode.

  • $0.0032: Cost per 1,000 tokens.

  • $0.0032/1000: Cost per token.

Как я говорил, я за то чтобы проект не напрягал финансово. Сколько позакрывалось проектов, которые стали отягощать своих создателей ежемесячной нагрузкой. Да и ответов от внешних сервисов зачастую приходится ждать долго.
Как вариант можно использовать тот же Libre Translate либо по API, либо подняв свой инстанс (для скорости). Но он конечно не панацея для всего, поэтому ищу нормальный ИИ. Может после выход GPT 4,5 или GPT 5 цена на 4 упадет. А вот качества его для перевода вполне достаточно.

Либра транслейт это аналог Гугл транслейта, он просто переводит, подсказки не понимает. Может перевести слово logs как брёвна и ничего ты с этим не сделаешь. То есть тут он вообще не подходит.

Sign up to leave a comment.

Articles