Il n’y a aucune raison de limiter la fonctionnalité à une seule catégorie…
Sauf si vous avez beaucoup de sujets et que vous considérez le coût de la traduction de l’ensemble
C’est pourquoi nous pensions nous en tenir à une seule catégorie.
Cela m’a d’ailleurs rappelé ce passage du premier message :
Je pense que cela représenterait un montant considérable pour notre forum si nous l’activions pour toutes les catégories
Pourriez-vous nous donner des conseils sur la façon d’estimer ce coût ? Je pense que cela se base sur le nombre de caractères, mais je ne sais pas comment le plugin fonctionne en arrière-plan. Est-ce qu’il récupère peut-être seulement les X premiers caractères de chaque message pour réduire le coût de la détection de la langue ?
Ainsi, nous avons réfléchi à notre cas d’usage : il consisterait à permettre aux anglophones de traduire des messages non anglophones dans une catégorie spécifique, afin de pouvoir répondre en anglais, puis à ce que les auteurs des sujets puissent traduire ces réponses dans leur langue (c’est-à-dire la langue du premier message).
Le coût est un point pertinent que je n’avais pas envisagé. Nous utilisons le service de traduction de Microsoft et n’avons jamais eu à payer pour cela, mais le site pour lequel j’ai configuré cela est assez petit. Limiter les traductions par catégorie est peut-être en effet une demande de fonctionnalité valable.
Personnellement, je n’ai jamais vraiment compris exactement quelle quantité de données est envoyée au traducteur et comment cela fonctionne concrètement. Cela fonctionne tout simplement.
Voici comment j’ai établi l’estimation des coûts pour mon forum. Toutes les requêtes sont destinées au Data Explorer.
Estimer le nombre moyen de caractères par publication
Dernière fois que j’ai vérifié, le plugin envoie le texte cuit au service de traduction.
SELECT AVG(LENGTH(p.cooked))
FROM posts AS p
JOIN topics AS t ON p.topic_id = t.id
WHERE t.archetype != 'private_message'
Estimer le nombre de publications lues par visite d’utilisateur
J’ai pris les 30 derniers jours pour obtenir une estimation relativement récente.
-- [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
Nombre de visites d’utilisateurs au cours des 30 derniers jours
-- [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
Estimation du nombre de caractères lus au cours des 30 derniers jours
En multipliant les trois chiffres précédents, j’ai obtenu une estimation du nombre de caractères de publications cuites qui ont été lus au cours des 30 derniers jours.
Estimation du nombre d’utilisateurs ne parlant pas la langue principale
Comme l’anglais est la langue principale de notre forum, j’ai utilisé Google Analytics pour déterminer le pourcentage d’utilisateurs ayant configuré leur navigateur pour une langue autre que l’anglais.
Estimation finale
Ensuite, j’ai établi une estimation basse/moyenne/haute en supposant que le taux actuel de visiteurs non anglophones représenterait le « cas courant », en le divisant par deux pour l’estimation basse et en le doublant pour l’estimation haute. Cela m’a donné un nombre bas/moyen/élevé de caractères sur 30 jours, que j’ai multiplié par le tarif par X caractères du service de traduction.
Cette réponse est super ! Très détaillée @lee-dohm, alors je l’ai déplacée hors du sujet du traducteur pour qu’elle ne soit pas supprimée et qu’elle puisse être utile à d’autres.
Il serait peut-être intéressant de corréler tout de même les données du champ users.locale et d’obtenir le pourcentage d’utilisateurs qui l’ont défini sur une valeur autre que l’anglais (si votre site ne s’adapte pas automatiquement en fonction de l’environnement de l’utilisateur, ce qui, je crois, est une option dans les paramètres d’administration).
avez-vous remarqué un pic significatif lors du lancement initial de ce plugin, basé sur ceci ?
Je pense qu’un élément similaire pourrait encore être ajouté pour compléter l’estimation :
SELECT LENGTH(COALESCE(string_agg(posts.cooked, ''),''))
FROM posts
JOIN topics on posts.topic_id = topics.id
WHERE topics.archetype <> 'private_message'
Je n’ai effectué aucun suivi après avoir décidé de lancer le projet, donc je ne sais pas si cela a eu un impact, non. Mais oui, inclure votre requête dans l’estimation des coûts serait une bonne idée