كيفية تقدير تكلفة الترجمة باستخدام المكون الإضافي للمترجم

الدعم
1

لا يوجد سبب لمحاولة حصر الميزة في فئة واحدة…

إلا إذا كان لديك عدد كبير من المواضيع وتعتبر تكلفة ترجمة كل شيء :sweat_smile:
لهذا السبب كنا نفكر في الالتزام بفئة واحدة فقط.

هذا في حد ذاته ذكّرني بهذه الفقرة من المنشور الأول:
image

أعتقد أن تفعيلها لجميع الفئات سيكون عبئًا كبيرًا على منتدانا :sweat_smile:
هل يمكنك تقديم أي نصيحة حول كيفية تقدير هذه التكلفة؟ أعتقد أنها تعتمد على عدد الأحرف، لكنني لا أعرف كيف يعمل الملحق في الخلفية. هل يقوم ربما بسحب أول X حرف فقط من كل منشور لتقليل تكلفة كشف اللغة؟

لذلك، كنا نفكر في حالة الاستخدام الخاصة بنا، وهي السماح للمتحدثين بالإنجليزية بترجمة المنشورات غير الإنجليزية في فئة محددة واحدة، حتى يتمكنوا من الرد باللغة الإنجليزية، ثم يتمكن مؤلفو المواضيع من ترجمة هذه الردود إلى لغتهم (=لغة المنشور الأول).

2

التكلفة نقطة جيدة لم أكن قد أخذتها في الاعتبار. نحن نستخدم خدمة الترجمة من مايكروسوفت ولم نضطر أبدًا لدفع مقابلها، لكن الموقع الذي قمت بإعداده لهذا الغرض صغير نسبيًا. ربما يكون تحديد الترجمات حسب الفئة مطلبًا ميزاتًا صحيحًا.

شخصيًا، لم أفهم أبدًا تمامًا مقدار ما يُرسل إلى المترجم وكيف يعمل ذلك عمليًا. الأمر ببساطة “يعمل”.

3

إليك كيفية إجراء تقدير التكلفة الخاص بي للمنتدى. جميع الاستعلامات مخصصة لاستكشف البيانات.

تقدير متوسط عدد الأحرف في كل منشور

آخر مرة تحققت منها، كان الإضافة ترسل النص المطبوخ إلى خدمة الترجمة.

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: