翻訳プラグインを使用して翻訳コストを見積もる方法

サポート
1

機能を特定のカテゴリに限定する理由はありません…

ただし、トピックが非常に多く、すべてを翻訳するコストを考慮する場合は別ですが:sweat_smile:
そのため、私たちは 1 つのカテゴリに絞ることを検討していました。

この点自体が、最初の投稿の以下の部分を思い出させました：
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 日間に読まれた文字数の見積もり

上記 3 つの数値を掛け合わせることで、過去 30 日間に読まれた投稿の調理済み文字数の推定値を得ました。

非主要言語ユーザー数の見積もり

当フォーラムの主要言語は英語であるため、Google アナリティクスを使用して、ブラウザ設定が英語以外の言語になっているユーザーの割合を把握しました。

最終的な見積もり

その後、現在の非英語訪問者の割合を「一般的なケース」と仮定し、それを半分にした値を低めの推定値、2 倍にした値を高めの推定値として、低/中/高の 3 つの見積もりを作成しました。これにより、30 日間の文字数の低/中/高の値が得られ、それを翻訳サービスの文字単価（X 文字あたりの料金）に乗算しました。

参考になれば幸いです！

4

この返信、すごく素晴らしい！とても詳細ですね、@lee-dohm さん。削除されてしまわないよう、翻訳トピックから外しました。他の人にも役立つと思います。

5

このガイドをありがとうございます。2 つ質問があります。

  • これに基づいて：

    サイトがユーザー環境に基づいて自動的に適応しない場合（これは管理設定でオプションになっていると思います）、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: