Es gibt keinen Grund, das Feature auf eine Kategorie zu beschränken…
Es sei denn, Sie haben viele Themen und bedenken die Kosten für die Übersetzung von allem
Deshalb dachten wir, wir bleiben bei einer einzigen Kategorie.
Das hat mich irgendwie an diesen Abschnitt aus dem ersten Beitrag erinnert:
Ich denke, es wäre eine erhebliche Menge für unser Forum, wenn wir es für alle Kategorien aktivieren würden
Könnten Sie mir einen Rat geben, wie man diese Kosten schätzt? Ich glaube, es basiert auf der Anzahl der Zeichen, aber ich weiß nicht, wie das Plugin im Backend funktioniert. Greift es vielleicht nur die ersten X Zeichen jedes Beitrags ab, um die Kosten für die Spracherkennung zu senken?
Deshalb haben wir über unseren Anwendungsfall nachgedacht: Es würde englischsprachigen Nutzern ermöglichen, nicht-englische Beiträge in einer bestimmten Kategorie zu übersetzen, um auf Englisch antworten zu können, und die Themenautoren könnten diese Antworten dann in ihre Sprache (= die Sprache des ersten Beitrags) übersetzen.
Die Kosten sind ein guter Punkt, den ich nicht bedacht hatte. Wir nutzen den Übersetzungsdienst von Microsoft und mussten dafür noch nie bezahlen, aber die Website, für die ich das eingerichtet habe, ist ziemlich klein. Vielleicht ist die Begrenzung von Übersetzungen nach Kategorie tatsächlich eine berechtigte Feature-Anfrage.
Persönlich habe ich auch nie wirklich vollständig verstanden, wie viel an den Übersetzer gesendet wird und wie das in der Praxis funktioniert. Es funktioniert einfach.
So habe ich die Kostenschätzung für mein Forum erstellt. Alle Abfragen sind für den Data Explorer.
Schätzung der durchschnittlichen Anzahl von Zeichen pro Beitrag
Der Plugin sendet den zubereiteten Text an den Übersetzungsdienst, zumindest laut meinem letzten Check.
SELECT AVG(LENGTH(p.cooked))
FROM posts AS p
JOIN topics AS t ON p.topic_id = t.id
WHERE t.archetype != 'private_message'
Schätzung der Anzahl der pro Benutzerbesuch gelesenen Beiträge
Ich habe die letzten 30 Tage herangezogen, um eine relativ aktuelle Schätzung zu erhalten.
-- [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
Anzahl der Benutzerbesuche in den letzten 30 Tagen
-- [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
Schätzung der Anzahl der gelesenen Zeichen in den letzten 30 Tagen
Durch Multiplikation der drei vorherigen Werte erhielt ich eine Schätzung der Anzahl der zubereiteten Zeichen der Beiträge, die in den letzten 30 Tagen gelesen wurden.
Schätzung der Anzahl der Nutzer, die keine Primärsprache verwenden
Da Englisch die Primärsprache unseres Forums ist, habe ich Google Analytics verwendet, um den Prozentsatz der Nutzer zu ermitteln, deren Browser für eine andere als die englische Sprache konfiguriert war.
Endgültige Schätzung
Anschließend habe ich eine Niedrig-/Mittel-/Hoch-Schätzung erstellt, indem ich davon ausgegangen bin, dass die aktuelle Rate an nicht-englischen Besuchern den „Normalfall
Diese Antwort ist wirklich toll! Sehr detailliert, @lee-dohm. Deshalb habe ich sie aus dem Übersetzer-Thema verschoben, damit sie nicht gelöscht wird und anderen nützen kann.
Es wäre vielleicht trotzdem sinnvoll, die Daten aus dem Feld users.locale zu korrelieren und den Prozentsatz der Benutzer zu ermitteln, die einen Wert außer Englisch eingestellt haben (falls Ihre Website sich nicht automatisch an die Benutzerumgebung anpasst, was meiner Meinung nach eine Option in den Admin-Einstellungen ist).
Haben Sie beim ersten Start des Plugins einen deutlichen Anstieg bemerkt, basierend auf diesem?
Ich denke, so etwas könnte noch hinzugefügt werden, um die Schätzung zu vervollständigen:
SELECT LENGTH(COALESCE(string_agg(posts.cooked, ''),''))
FROM posts
JOIN topics on posts.topic_id = topics.id
WHERE topics.archetype <> 'private_message'
Ich habe nach unserer Entscheidung für den Start kein Tracking durchgeführt, daher kann ich nicht sagen, ob das etwas beeinflusst hat, nein. Aber ja, es wäre gut, deine Abfrage in die Kostenschätzung einzubeziehen