번역기 플러그인으로 번역 비용 추정하는 방법

제품 지원
1

특정 범주로 기능을 제한할 이유는 없습니다…

다만, 토론이 매우 많고 모든 것을 번역하는 비용을 고려한다면 :sweat_smile:
그래서 우리는 하나의 범주로 한정하는 방안을 고려하고 있었습니다.

이 부분만으로도 첫 번째 게시글의 이 내용을 떠올리게 했습니다:
image

모든 범위에 대해 이 기능을 활성화할 경우 우리 포럼에는 상당한 비용이 발생할 것 같습니다 :sweat_smile:
이 비용을 추정하는 방법에 대해 조언을 구할 수 있을까요? 글자 수에 기반한다고 생각하는데, 플러그인이 백엔드에서 어떻게 동작하는지는 잘 모르겠습니다. 언어 감지 비용을 줄이기 위해 각 게시글의 처음 X자만 가져오는 방식일까요?

따라서 우리는 우리의 사용 사례를 고려해, 영어 사용자들이 특정 한 범위의 비영어 게시글을 번역하여 영어로 답변할 수 있도록 하고, 그 후 토론 작성자가 이 답변들을 자신의 언어(=첫 번째 게시글의 언어)로 번역할 수 있도록 하는 방안을 생각하고 있습니다.

2

비용 문제는 제가 고려하지 못했던 좋은 지적입니다. 저희는 Microsoft의 번역 서비스를 사용하는데, 지금까지 별도로 비용을 지불한 적이 없습니다. 다만 이 서비스를 설정한 사이트가 비교적 규모가 작기 때문일 수도 있습니다. 범주별로 번역을 제한하는 기능은 실제로 유효한 기능 요청일 수 있겠네요.

개인적으로도 번역기에 정확히 어떤 내용이 전송되는지, 실제로 어떻게 작동하는지에 대해 완전히 이해한 적이 없습니다. 그냥 "동작"하니까요.

3

다음은 내 포럼에 대한 비용 추정 방법을 설명한 것입니다. 모든 쿼리는 Data Explorer를 위한 것입니다.

게시글당 평균 글자 수 추정

마지막으로 확인했을 때, 플러그인은 번역 서비스에 cooked 텍스트를 전송합니다.

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일간 읽힌 게시글의 cooked 글자 수를 추정할 수 있습니다.

비(非)주요 언어 사용자 수 추정

우리 포럼의 주요 언어가 영어이므로, 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: