Как оценить стоимость перевода с помощью плагина переводчика

Нет причин пытаться ограничить функцию одной категорией…

Разве что у вас много тем и вы учитываете стоимость перевода всего контента :sweat_smile:
Именно поэтому мы думали остаться в рамках одной категории.

Это само по себе напомнило мне этот фрагмент из первого поста:
image

Думаю, если мы включим эту функцию для всех категорий, это будет существенной суммой для нашего форума :sweat_smile:
Могли бы вы дать совет, как оценить эти расходы? Мне кажется, они зависят от количества символов, но я не знаю, как плагин работает на стороне сервера. Может быть, он берёт только первые X символов каждого поста, чтобы снизить стоимость определения языка?

Таким образом, мы рассмотрели наш конкретный случай использования: позволить англоязычным пользователям переводить посты на других языках в одной конкретной категории, чтобы они могли отвечать на английском, а затем авторы тем смогут перевести эти ответы на свой язык (то есть на язык первого поста).

Стоимость — это важный момент, о котором я не задумывался. Мы используем сервис перевода от Microsoft и никогда не платили за него, но сайт, для которого я это настроил, довольно небольшой. Возможно, ограничение переводов по категориям — действительно обоснованное предложение по улучшению.

Лично я тоже никогда до конца не понимал, какой объём данных отправляется на перевод и как это работает на практике. Это просто «работает».

Вот как я рассчитал оценку затрат для своего форума. Все запросы предназначены для Data Explorer.

Оценка среднего количества символов на сообщение

На момент моей последней проверки плагин отправлял обработанный текст в сервис перевода.

SELECT AVG(LENGTH(p.cooked))
  FROM posts AS p
  JOIN topics AS t ON p.topic_id = t.id
 WHERE t.archetype != 'private_message'

Оценка количества сообщений, прочитанных за один визит пользователя

Я использовал данные за последние 30 дней, чтобы получить относительно свежую оценку.

-- [params]
-- int :from_days_ago = 0
-- int :duration_days = 30

WITH t AS (
    SELECT CURRENT_TIMESTAMP - ((:from_days_ago + :duration_days) * (INTERVAL '1 days')) AS START,
        CURRENT_TIMESTAMP - (:from_days_ago * (INTERVAL '1 days')) AS END
)

SELECT AVG(posts_read)
  FROM user_visits
  JOIN t ON visited_at > t.START AND visited_at < t.END

Количество визитов пользователей за последние 30 дней

-- [params]
-- int :from_days_ago = 0
-- int :duration_days = 30

WITH t AS (
    SELECT CURRENT_TIMESTAMP - ((:from_days_ago + :duration_days) * (INTERVAL '1 days')) AS START,
        CURRENT_TIMESTAMP - (:from_days_ago * (INTERVAL '1 days')) AS END
)

SELECT COUNT(1)
  FROM user_visits
  JOIN t ON visited_at > t.START AND visited_at < t.END

Оценка количества прочитанных символов за последние 30 дней

Перемножив три предыдущих показателя, я получил оценку количества обработанных символов в сообщениях, прочитанных за последние 30 дней.

Оценка количества пользователей, не использующих основной язык

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

Итоговая оценка

Затем я сделал оценку по трём сценариям (низкий/средний/высокий), предположив, что текущий уровень посетителей, не говорящих на английском, соответствует «типичному случаю». Для низкого сценария я уменьшил это значение вдвое, а для высокого — удвоил. Это дало мне низкое/среднее/высокое количество символов за 30 дней, которое я умножил на ставку за X символов для сервиса перевода.

Надеюсь, это поможет!

Этот ответ просто великолепен! Очень подробно, @lee-dohm, поэтому я перенёс его из темы переводчика, чтобы его не удалили, и он мог быть полезен другим.

Спасибо за это руководство. У меня два вопроса:

  • исходя из этого:

    Было бы неплохо всё же сопоставить данные из поля users.locale и получить процент пользователей, у которых оно установлено в значение, отличное от английского (если ваш сайт не адаптируется автоматически на основе окружения пользователя, что, как я полагаю, является опцией в настройках администратора)

  • заметили ли вы значительный всплеск при первом запуске плагина, основываясь на этом?
    image

    Я считаю, что что-то подобное всё ещё можно добавить для завершения оценки:

    SELECT  LENGTH(COALESCE(string_agg(posts.cooked, ''),''))
    FROM    posts
    JOIN    topics on posts.topic_id = topics.id
    WHERE   topics.archetype <> 'private_message'
    

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