如何估算使用翻译插件的翻译成本

支持
1

没有理由将功能限制在某个类别……

除非你有大量话题，并且需要考虑翻译所有内容所带来的成本：sweat_smile
这就是为什么我们考虑只保留一个类别。

这一点本身让我想起了第一篇帖子中的这段内容：
image

我认为，如果我们为所有类别启用该功能，对我们论坛来说将是一笔不小的开支：sweat_smile
你能否就如何估算该成本提供一些建议？我想这应该是基于字符数量，但我不清楚插件在后端是如何工作的。它是否会只抓取每篇帖子的前 X 个字符，以降低语言检测的成本？

因此，我们考虑了我们的使用场景：允许英语使用者将特定类别中的非英语帖子翻译成英语，以便用英语进行回复；随后，话题作者也能将这些回复翻译成他们自己的语言（即首篇帖子所使用的语言）。

2

成本确实是一个我之前未曾考虑到的重要点。我们一直使用微软的翻译服务，从未为此付费，但那是因为我搭建的站点规模相对较小。也许按类别限制翻译确实是一个合理的功能请求。

就我个人而言，我也从未完全弄清楚究竟有多少内容被发送到翻译服务，以及它在实际中是如何运作的。它只是“能正常工作”。

3

这是我为我论坛做的成本估算方法。所有查询都是针对数据探索器（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 个字符的费率。

希望这对您有帮助！

4

这条回复太棒了！非常详细，@lee-dohm，所以我把你从翻译主题帖中移了出来，以免被删除，这样其他人也能从中受益。

5

感谢这份指南。我有两个问题：

  • 基于以下内容：

    如果能将 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'
6

我们在决定发布后没有进行任何追踪，所以我不确定这是否产生了影响，没有。不过，将你的查询纳入成本估算确实是个好主意 :+1: