Mudlet: Configurer un service de traduction Web pour Mudlet

Il y a POEditor comme intégration avec github, qui permet de traduire XLIFF
(qui sont censés être pris en charge par qt linguist). Et ils ont un OS
Licence.

Une autre option est Qordoba, qui ne semble rien coûter et nativement
prend en charge les fichiers ts.

Je n'ai jamais utilisé de service/d'application de traduction, donc je n'ai pas de préférences.

Vadim Peretokin [email protected] schrieb am So., 9 avril 2017,
13h14 :

Nous devons permettre aux gens de contribuer très facilement à la traduction de Mudlet.

• cela signifie quelque chose basé sur le Web où le seul obstacle est simplement de se connecter.
  Il existe peut-être un service Web existant qui pourrait nous offrir une
  licence open source pour obtenir la configuration.

Alternatives disponibles :
Launchpad https://translations.launchpad.net/ - c'est l'avenir
discutable cependant

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Mudlet/Mudlet/issues/856 , ou désactiver le fil
https://github.com/notifications/unsubscribe-auth/ABAeDUJoAsg-zvnOq1YUvuIqn-fbRwcCks5ruL2WgaJpZM4M3_u1
.

Re: XLIFF le _Qt Linguist Manual: Translators_ Qt Doc notes:

__Traduire des chaînes__
Vous ouvrez les fichiers source de traduction (TS) dans Qt Linguist pour la traduction. Les fichiers TS sont des fichiers XML lisibles par l'homme contenant des phrases source et leurs traductions. Les fichiers TS sont généralement créés et mis à jour par lupdate. Si vous n'avez pas de fichier TS, consultez Release Manager pour savoir comment en générer un.
Vous pouvez également utiliser Qt Linguist pour traduire des fichiers au format international XML Localization Interchange File Format (XLIFF) qui sont générés par d'autres programmes. Cependant, pour les projets Qt standard, seul le format de fichier TS est utilisé. La version minimale prise en charge pour les fichiers au format XLIFF est 1.1.

Il existe maintenant des plates-formes de traduction basées sur le Web qui présentent des avantages considérables par rapport aux applications de bureau : pas besoin d'installer de logiciel, de suggérer des traductions pour du texte déjà traduit, etc.

@SlySven J'ai lu ceci, c'est pourquoi j'ai dit ce que j'ai dit. Il se lit comme non entièrement pris en charge ou après coup, c'est pourquoi j'ai soi-disant ajouté (je ne l'ai jamais testé).

@vadi2 Les produits que j'ai mentionnés sont des plates-formes Web. Mais vous aurez toujours besoin d'utiliser qt linguist pour rendre la sortie de ces plates-formes utilisable par le framework de traduction Qt. Ce qui nous lie également aux formats supportés TS et XLIFF .

J'ai joué avec Linguist et l'interface utilisateur est assez bonne pour autant que je sache (je suis un fan :heart_eyes:), elle reproduit les dialogues de l'interface utilisateur {et affiche le code source d'où provient la chaîne de texte pour C++ provenant de QStrings } afin que vous puissiez avoir une bonne idée de ce à quoi ils ressembleront dans les différentes langues et que vous puissiez travailler sur plusieurs traductions simultanément. J'espère juste que Qt est plus rigide en ne réorganisant pas inutilement le contenu des fichiers TS pour réduire le bruit git lorsqu'un fichier est mis à jour par un contributeur - contrairement, par exemple, à QGridLayouts dans les fichiers .ui. * soupir *

Quant à la nécessité d'utiliser Qt Linguist - je pense que comme nous utilisons les bibliothèques Qt en général, nous sommes susceptibles de nous y engager (comme dans les niveaux d'engagement _Pig_ plutôt que _Chicken_ dans un _bacon-and-egg sarnie_) en plus de devenir natif gettext ne serait pas _difficile_ dans le bon sens, je crois.

On dirait que je suis intéressé à voir Qt Linguist exporter vers quelque chose de Web, avec la possibilité pour les gens d'installer et de prévisualiser leurs traductions en temps réel s'ils le souhaitent. Je vais regarder les services que vous avez mentionnés @keneanung , ils ont l'air sympa.

J'avais aussi Transifex en tête mais ça ne semble plus bien marcher.

Autre plateforme de traduction web : https://hosted.weblate.org/projects/tilix/translations/

Voici comment le projet Mozilla gère la localisation et la traduction : https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Quick_start_guide/Translation_phase

Un autre grand regard en profondeur sur plusieurs alternatives et le processus en général dans ce mémoire d'étude de master sur les « Traductions dans les logiciels libres » : https://larjona.wordpress.com/translations-in-libre-software/

Merci @Kebap , j'ai lu le document que vous avez lié. Je suis intéressé par Weblate et Transifex - je vais les vérifier.

J'aimerais que cela ait la barrière d'entrée la plus basse possible et que cela exclue la traduction sur ordinateur où la personne doit télécharger et installer un logiciel, puis rechercher les bons fichiers avant d'avoir la possibilité de commencer à travailler.

Weblate semble sympa et open source, mais leur version hébergée est également en panne en ce moment - de même que toutes les traductions hébergées comme pour le projet Tilix. Pas bon. Je me méfie également d'héberger plus de choses sur notre serveur car il fonctionne déjà à la limite.

Je vais essayer la démo Transifex. Ils prennent en charge l'open source et semblent être un magasin beaucoup plus gros, donc beaucoup moins susceptible de tomber en panne, contrairement à Weblate.

Cela dit, si l'intégration de Weblates Git fonctionne réellement, ce sera beaucoup mieux à utiliser car elle _devrait_ mettre à jour automatiquement le nouveau texte source à partir de Git, et peut-être le valider à nouveau. Transifex, d'autre part, m'oblige à télécharger manuellement les fichiers à traduire.

Alors que Transifex prend en charge les fichiers .ts de manière native, il semble s'étouffer lors du téléchargement. L'utilisation de ts2po et le téléchargement .po fichiers

Il semble que vous puissiez avoir des mises à jour bidirectionnelles automatiques entre Transifex et Github avec un middleware : https://docs.transifex.com/integrations/github-txgh

J'ai pu télécharger un .po avec la traduction intacte de Transifex, mais po2ts étouffe le fichier avec une erreur d'encodage Python :

po2ts: WARNING: Error processing: input ./for_use_mudlet_rupo_1_ru.po, output ./for_use_mudlet_rupo_1_ru.ts, template None: 'ascii' codec can't encode characters in position 1994-1999: ordinal not in range(128)

Je laisserai le projet Transifex sur https://www.transifex.com/mudlet/mudlet/dashboard si quelqu'un d'autre souhaite le faire traduire @Kebap @keneanung. Je vais essayer Weblate ensuite.

Weblate est sympa - il a une _tonne_ d'options de connexion tierces, donc le rejoindre est vraiment sans friction.

@ vadi2 a écrit :

J'ai pu télécharger un .po avec la traduction intacte depuis Transifex, mais po2ts s'étouffe avec le fichier avec une erreur d'encodage Python :

Je pense avoir lu quelque part que leur version de po2ts ne fonctionne qu'avec une ancienne spécification de fichier .ts et avait besoin d'une mise à jour (à leur fin je suppose) - je note qu'elle provient de la boîte à traduction de Traduisez le code source de House page d'internationalisation mixxx .

En fait, cette erreur "d'encodage" donne l'impression qu'elle essaie de produire un fichier .ts où l'encodage est ASCII et NON UTF-8. qui ne sont pas ASCII...

Cette page a été mise à jour pour la dernière fois il y a quatre ans ! Le processus pour les développeurs est terminé
de date, je pense. C'est une documentation de traduction assez impressionnante
bien que!

Le mardi 19 septembre 2017, 18h18, Stephen Lyons [email protected] a écrit :

@ vadi2 a écrit :

J'ai pu télécharger un .po avec la traduction intacte de Transifex,
mais po2ts étouffe le fichier avec une erreur d'encodage Python :

Je pense avoir lu quelque part que leur version de po2ts ne fonctionne qu'avec un vieux
spécification du fichier .ts et mise à jour nécessaire (à leur fin je suppose) - je
notez qu'il provient de la boîte à outils de traduction
http://toolkit.translatehouse.org/ de la source Github de Translate House
code https://github.com/translate/translate et la dernière version est
2.2.5 (je ne sais pas ce qu'ils utilisent) au moment de la rédaction. Trouvé un
page Web d'un autre projet (pas sûr qu'il soit basé sur GitHub mais le
le processus global pour eux semblait être le genre de choses que nous devions faire : mixxx
page d'internationalisation
https://mixxx.org/wiki/doku.php/internationalisation .

-
Vous recevez ceci parce que vous avez été affecté.

Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Mudlet/Mudlet/issues/856#issuecomment-330592819 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAGxjEdeBPs-7fDkUwfoLjUt48eJJhl0ks5sj-lagaJpZM4M3_u1
.

Weblate ne semble pas être en bonne position. Je n'ai pas encore reçu de réponse pour mon application hébergée, et le projet ne reçoit pas beaucoup de mises à jour. De retour à Transifex, c'est ça.

Conseils sur la configuration de Transifex avec Qt : https://forum.qt.io/topic/36750/qt5-ts-files-and-transifex-continuous-translation-localization

https://bugreports.qt.io/browse/QTBUG-1136 :

enfin, le linguiste est essentiellement sous assistance respiratoire - nous avons cédé le terrain aux ISV spécialisés dans ce domaine.

Qt Linguist est une technologie sans issue - elle n'obtiendra aucune fonctionnalité à l'avenir, nous devons donc utiliser une plate-forme Web ici.

Je vais essayer de mettre en place les traductions Transifex maintenant que #1334 est disponible.

Juste pour réitérer ce que j'ai mentionné dans la référence croisée de Kebap que crowdin ressemblait également à un choix valide pour un projet Open Source comme le nôtre - et ils peuvent gérer les fichiers Qt .ts et ont également une intégration Github - la fonction de pseudolocalisation devrait également nous aider à éviter les problèmes dans l'interface graphique car nous n'avons pas structuré le texte correctement ( je pense ) et nous aidera certainement à nous assurer que nous laissons suffisamment de latitude pour les langues avec des chaînes plus longues que en-US ...

crowdin a l'air sympa - voyons comment il se compare à Transifex, j'ai un projet de test ici .

@SlySven, ce code déformé pour rendre le html plus agréable pour les traducteurs était prématuré - transifex, par exemple, gère déjà le balisage html vraiment bien :

Je l'ai compris - crowdin a aussi cette option. Sélectionnez simplement « masquer » dans les paramètres des balises de l'éditeur :

Cela signifie que nous n'avons plus à modifier le code que @SlySven a fait - nous pouvons utiliser HTML tel

Je suis heureux avec la suggestion de @SlySven d'utiliser @crowdin pour les traductions. @Kebap , @keneanung , @SlySven vos avis ?

Une fois que nous serons d'accord, je vais peaufiner le projet sur crowdin pour qu'il soit officiel, demander une licence open source et nous commençons à faire passer le mot aux traducteurs.

Hey,

Je fais partie de l'équipe Crowdin et je serai ravi d'aider à la configuration supplémentaire si nécessaire ! N'hésitez pas à me mentionner si des questions se posent

Je suis bien avec crowdin aussi. Son interface utilisateur a été déroutante au début, mais je suis sûr que nous (je) nous y habituerons.

J'avoue que je n'ai pas regardé de près celui de Transifex car je l'ai éteint mentalement car j'ai compris qu'il ne gérait pas bien/directement le format Qt .ts actuel - cela a-t-il changé ou étais-je incorrect dans cette croyance ?

Une chose à propos de Crowdin que je vois dans les récents commits git est que vous téléchargiez plusieurs fichiers .ts qui avaient été configurés localement pour être pour une langue spécifique. Vous l'avez en quelque sorte corrigé maintenant en n'envoyant qu'un seul fichier, un fichier mudlet_en.ts , mais cela ne me semble toujours pas tout à fait correct. Vous pouvez supprimer ou commenter les lignes TRANSLATIONS = dans le fichier mudlet.pro et avoir un script shell qui s'exécute (dans la base de la source) :

lupdate -recursive ./src/ -ts ./translations/mudlet.ts

pour générer un seul fichier non spécifique à une langue à transmettre au processus de traduction de Crowdin et l'obtenir pour produire les fichiers mudlet_xx_YY.ts nous voulons (j'ai déjà modifié un paramètre sur Crowdin pour spécifier le _xx_YY language+locale suffixes où il semblait à l'origine être défini uniquement sur une langue _xx ). Cela entraînera toujours la copie d'un ensemble de fichiers dans le même répertoire prêt pour lrelease .

BTW Il est utile de laisser le fichier simple sans suffixe, car cela signifie que les parties intéressées par la langue minoritaire peuvent le copier et le renommer pour qu'il fonctionne en privé s'ils le souhaitent pour une langue différente et non couverte avec le linguiste Qt fourni. {Peut-être un piratage pour le 19 septembre par exemple !!!}

Je pense que les mesures anti-obscurcissement HTML que j'ai prises semblent être devenues un peu moins nécessaires car le plugin Qt Designer semble être devenu un peu moins désireux de mutiler le HTML dans les deux dernières versions de Qt. Je ne suis pas encore totalement convaincu que cela ne gâchera pas les choses et ne changera pas les choses en forçant, par exemple, l'utilisation des polices particulières que la dernière personne à modifier a dans leurs systèmes plutôt que de la laisser être une police générique qui peut fonctionner sur toutes les plateformes. Je vais jeter un autre coup d'œil et signaler cela ici car cela affectera la façon dont nous enregistrons ce HTML dans notre travail.

J'avoue que je n'ai pas regardé de près celui de Transifex car je l'ai éteint mentalement car j'ai compris qu'il ne gérait pas bien/directement le format Qt .ts actuel - est-ce que cela a changé ou avais-je tort dans cette croyance ?

J'étais aussi, il semble que ça ait changé : https://docs.transifex.com/formats/qt-ts

Je n'ai pas l'intention d'utiliser le plugin Qt Designer, donc quelle que soit sa manipulation, ce n'est pas pertinent - crowdin gère assez bien les traductions tout seul, et son rendu HTML avec le style "masquer" est tolérable.

Oh, il le fait toujours - en insérant des tables et une DTD - donc, ce qui est plus facile à lire et à analyser par les humains, ceci :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
<html><head><meta name="qrichtext" content="1" /><style type="text/css">
p, li { white-space: pre-wrap; }
</style></head><body style=" font-family:'FreeSans'; font-size:9pt; font-weight:400; font-style:normal;">
<p align="center" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;"><span style=" font-size:large; font-weight:600;">Welcome to Mudlet!</span></p>
<p align="center" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">Click on one of the MUDs on the list to play.</p>
<p align="center" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">To play a game not in the list, click on <img src=":/icons/list-add_small.png" /><span style=" color:#555753;">New</span>, fill in the <span style=" font-style:italic;">Profile Name</span>, <span style=" font-style:italic;">Server address</span>, and <span style=" font-style:italic;">Port</span> fields in the <span style=" font-style:italic;">Required</span> area.</p>
<p align="center" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">After that, click <img src=":/icons/dialog-ok-apply_small.png" /><span style=" color:#555753;">Connect</span> to play.</p>
<p style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">Have fun!</p>
<p align="right" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">The Mudlet Team <img src=":/icons/mudlet_main_16px.png" /></p></body></html>

ou ceci, qui fait la même chose en ce qui nous concerne :

<html><head/><body><center><big><b>Welcome to Mudlet!</b></big></center></p>
<p><center>Click on one of the MUDs on the list to play.<center></p>
<p><center>To play a game not in the list, click on <img src=":/icons/list-add_small.png"/> <span style="color:#555753;">New</span>, fill in the <i>Profile Name</i>, <i>Server address</i>, and <i>Port</i> fields in the <i>Required</i> area.<center></p>
<p><center>After that, click <img src=":/icons/dialog-ok-apply_small.png"/> <span style=" color:#555753;">Connect</span> to play.</center></p>
<p>Have fun!</p>
<p align="right">The Mudlet Team <img src=":/icons/mudlet_main_16px.png"/></p></body></html>

Techniquement, il s'agit de tout le texte riche de Qt qui n'est qu'un sous-ensemble de HTML (alors pourquoi forcer l'inclusion de la stricte DTD HTML 4.0 ?)

Même en montrant < et > ici au lieu de < et > dans le fichier brut que les traducteurs verront, je pense qu'il est clair qui va être plus facile à utiliser en l'absence d'un widget d'affichage HTML/Qt Rich Text...

Je pense avoir lu quelque part que les langages CJK ne devraient vraiment pas utiliser d'effets de police en gras ou en italique (au lieu de cela, je pense qu'ils utilisent l'équivalent d'un accent de point sur un bord du glyphe) - donc dans ces cas, le balisage pourrait être impliqué dans le processus de traduction...

L'exécution de scripts shell n'est pas portable (pour Windows), donc je préfère ne pas le faire. Le fichier mudlet_en.ts actuel semble fonctionner correctement ?

C'est vendredi, alors tirons une conclusion à ce sujet dans les prochains jours afin que nous puissions commencer les prochaines étapes, qui, je pense, seraient :

1) processus permettant aux traducteurs de signaler des chaînes déroutantes - si un traducteur ne peut pas le comprendre, il est probable que nos utilisateurs non plus
2) processus de traduction réel et comment cela fonctionnerait-il avec notre flux de travail

Je recommanderais d'abord de réfléchir davantage aux détails des processus dont nous avons besoin, puis de décider ensuite quel outil leur convient le mieux.

D'après ce que je peux voir en ce moment, nous avons quelques sources principales de texte différentes :

• Client Mulet lui-même
• Site Web de Mulet
• Wiki de Mudlet
• Les "autres" textes spontanés doivent être inclus manuellement

Ensuite, les processus pour chacun sont sensiblement les mêmes, mais doivent être examinés séparément :

• Découvrez un moyen de distinguer les textes obsolètes des textes actuels pertinents qui nécessitent une traduction.
• Obtenez des textes à partir de sources (voir ci-dessus). Cela peut-il être automatisé avec n'importe quel outil ? Qui devrait être responsable ?
• Obtenez des textes dans l'outil de traduction.
• Outil de traduction interne (d'accord, c'est normal, mais nécessite également une bonne interface et des flux de travail)
• Les traducteurs rapportent des chaînes confuses à l'équipe Mudlet avec des informations sur la manière dont elles doivent être ajustées.
• L'équipe Mudlet met à jour le texte dans la source. Soit à cause des rapports, soit à cause de l'évolution naturelle.
• Les textes mis à jour à partir de la source nécessitent des mises à jour dans l'outil de traduction. Exporter et importer à nouveau, plus diff.
• Les textes traduits seront terminés. Exportez-les depuis l'outil de traduction. Encore une fois l'automatisation ?
• Importez le texte traduit dans la source.
• Affichage des traductions dans la source. Ici, nous aurons besoin d'une sorte de commutateur de langue dans chaque source.

J'ai remarqué quelques plugins pour Wordpress et Mediawiki, ainsi que l'intégration dans Crowdin et Transifex, mais je n'ai pas eu beaucoup de temps pour rechercher tout cela plus en détail.

J'aimerais un processus plus automatisé pour toutes les étapes ci-dessus et choisir l'outil le mieux adapté.

En ce qui concerne le code source/le dialogue (formulaires) :

• Découvrez un moyen de distinguer les textes obsolètes des textes actuels pertinents qui nécessitent une traduction.
• Obtenez des textes à partir de sources (voir ci-dessus). Cela peut-il être automatisé avec n'importe quel outil ? Qui devrait être responsable ?
  
  
  
  • Les deux sont effectués avec la commande lupdate qui extrait les textes source de, devinez quoi, le code source et en ajoute/met à jour les enregistrements dans le - ce que je pense devrait être mudlet.ts fichier mudlet_en.ts actuel signale à certaines parties qu'il détient spécifiquement des traductions en anglais - alors que - avec la façon dont nous l'utiliserons comme code source ==> support de transfert de date Crowdin, il sera utilisé pour tout sauf l'anglais (américain ) cas. Si elles ne sont pas invoquées avec l'option --no-obsolete , les chaînes existantes mais maintenant disparues ne seront pas supprimées - ce que nous souhaiterons au moins pendant les étapes de développement. La raison pour laquelle je propose d'en générer une distincte pour le en-US locale car ce sera une langue très courte qui ne contiendra que des chaînes pour les pluriels, c'est-à-dire des endroits où nous aurions des chaînes source telles que "supprimer %n pièce(s)" de sorte que, dans ce cas, soit "supprimer 1 pièce" ou "supprimer 2 pièces" sont utilisés.
  
  
• Obtenez des textes dans l'outil de traduction.
  
  
  
  • Le processus de mise à jour de la branche de développement devrait provoquer ce qui précède et le .ts à jour à être téléchargé à partir de (je suggère) la version Linux CI (car il est plus facile pour nous de scripter)
  
  
• Outil de traduction interne (d'accord, c'est normal, mais nécessite également une bonne interface et des flux de travail)
• Les traducteurs rapportent des chaînes confuses à l'équipe Mudlet avec des informations sur la manière dont elles doivent être ajustées.
  
  
  
  • Il semble que crowdin permet à n'importe qui de faire un commentaire ou de soulever un problème à propos de n'importe quelle chaîne source qui sera au moins visible pour le responsable (mais peut être ouverte à plus de parties)
  
  
• L'équipe Mudlet met à jour le texte dans la source. Soit à cause des rapports, soit à cause de l'évolution naturelle.
  
  
  
  • Y compris les endroits où le texte source est confus ou mal orthographié par rapport à la forme en_US attendue - par exemple, j'ai peut-être utilisé license (en-GB nom , cf licence comme en-GB verbe ) mais c'est toujours une licence en en-US pour les deux formes.
  
  
• Les textes mis à jour à partir de la source nécessitent des mises à jour dans l'outil de traduction. Exporter et importer à nouveau, plus diff.
  
  
  
  • réexécutez lupdate - mais cela devrait se produire naturellement via les scripts CI sur les mises à jour de la branche 'développement'
  
  
• Les textes traduits seront terminés. Exportez-les depuis l'outil de traduction. Encore une fois l'automatisation ?
  
  
  
  • L'un de nous peut "Télécharger les traductions" en tant qu'ensemble complet de fichiers mudlet_xx_YY.ts manuellement à partir de Crowdin et git les valider dans le répertoire /translations - rappelez-vous que ces fichiers ne sont pas mis à jour par lupdate sauf, peut - être, pour les pluriels-seulement mudlet_en_US.ts One - au contraire , ils sont générés à Crowdin de la mudlet.ts fichier.
  
  
• Importez le texte traduit dans la source.
  
  
  
  • Pas tout à fait ce qui est requis, les textes de traduction ne sont pas lus par l'application à partir des fichiers .ts . Au lieu de cela, une fois le code révisé et rendu public, l'application mudlet lira les traductions au moment de l'exécution en chargeant le fichier binaire mudlet_xx_YY.qm (avec le fichier Qt approprié - ce que je note, nous sommes déjà distribution avec les versions d'installation !) Donc, au départ, j'imagine que l'un de nous exécutera lrelease pour convertir les fichiers .ts fichiers .qm et les validera dans le référentiel git en tant que bien. Finalement, Vadim a suggéré que nous expédierons les versions finales avec un ensemble de fichiers .qm inclus en tant que fichier de ressources. Ceci est approprié pour les versions du programme d'installation, mais les emballeurs Linux s'attendront plutôt à les stocker, disons un /usr/share/mudlet/translations lecture seule (à côté des fichiers lua externes de Mudlet). J'ai un code prototype qui permettra de gérer ces deux arrangements, mais en permettant à l'utilisateur de charger des fichiers de traduction depuis un autre endroit (éventuellement à partir du répertoire /translations dans le code source), cela permettrait le développement autonome de traductions pour d'autres langues minoritaires par les parties intéressées avec l'outil Qt original Linguist - cela permettrait également aux développeurs de travailler sur des cas privés/de test.
  
  
• Affichage des traductions dans la source. Ici, nous aurons besoin d'une sorte de commutateur de langue dans chaque source.
  
  
  
  • De l'expérimentation, l'utilisation du QLangaugeEvent est plus complexe que ce dont nous avons besoin car il se déclenche à chaque fois que QQTranslator::load(...) est appelé - j'ai trouvé qu'il est plus simple d'avoir la classe emit mudlet emit a (void) signal_translatorChangeCompleted(const QString&, const QString&) où les arguments des codes xx_YY actuels et précédents (language_COUNTRY/REGION) sont largement inutilisés à l'exception de, IIRC le Host qui génère un événement lua pour le script /package gestionnaires d'événements avec lesquels travailler. Ce signal est envoyé à chaque classe avec des textes GUI persistants à un slot_guiLanguageChange() où il appelle le retranslateUi(this) requis qui est défini dans chaque classe qui utilise également setupUi(this) condition que vous configuriez le option dans Qt IDE correctement (je ne sais pas comment cela fonctionne lorsque vous utilisez directement qmake ):
    
    
    
    cet appel modifiera les traductions de chaque chaîne traduisible dans les formulaires/dialogue, puis nous devrons régénérer tous les textes de l'interface graphique que nous créons au moment de l'exécution, en tenant compte des conditions qui ont pu entraîner la création de différents textes. Ce n'est pas aussi grave que ça en a l'air car nous avons seulement besoin de modifier la chaîne persistante - c'est-à-dire qui existe depuis longtemps - car les textes transitoires utiliseront automatiquement la nouvelle traduction chaque fois que tr(...) est utilisé pour les créer.
  
  

Ce n'est pas tout ce que j'ai sur ce sujet, mais je peux voir comment la plupart des étapes devraient se dérouler pour les textes de l'interface graphique de l'application...

Merci pour ces détails SlySven ! Il me semble, peut-être avez-vous déjà fait cela? Pour une autre candidature ? Avec Corwdin ? Cela rendrait la traduction de l'application Mudlet elle-même beaucoup plus facile.

D'un autre côté, nous avons toujours les mêmes questions pour les autres sources de texte dans l'univers Mudlet, comme la documentation wiki, le site Web de Mudlet et des textes supplémentaires qui peuvent nécessiter d'être incorporés quelque peu manuellement, comme expliqué dans mon dernier message ci-dessus.

Je n'ai pas complètement parcouru la réponse ci-dessus, mais Crowdin a une intégration Github dont il ne tient pas compte - https://github.com/Mudlet/Mudlet/pull/1692 est un PR généré automatiquement, nous n'aurons pas besoin de le faire tout téléchargement ou téléchargement manuel ; fusionnez simplement les PR. Ainsi, le processus sera un peu plus simple que décrit !

L'essai de crowdin des gars expirera dans 4 jours, donc j'ai besoin d'un oui / non - nous semblons en être satisfaits jusqu'à présent

Il y avait un yay de moi !

Salut! ;)

J'ai essayé https://crowdin.com/ … pour traduire c'est ok, je ne sais pas si c'est bon pour les commentaires rapides, les demandes et ainsi de suite… comme "contestualisation" pour une traduction ou un exemple...

Qu'en est-il de la section commentaires dans crowdin?

Salut @Joker-ITA,

Il existe en fait plusieurs façons d'ajouter un contexte supplémentaire pour les traducteurs :

1) Dans l'éditeur, cliquez sur « Modifier le contexte » sous la chaîne pour fournir plus d'informations aux traducteurs ;
2) Vous pouvez laisser un commentaire pour n'importe quelle chaîne dans l'éditeur (sur le panneau de droite, tapez votre commentaire) ;
3) Ajoutez un contexte pour n'importe quelle chaîne via les paramètres du projet -> onglet Chaînes ;
4) Je parie que vous avez des termes spécifiques que les traducteurs réguliers peuvent ne pas comprendre, il est donc logique de créer un glossaire et de le télécharger sur Crowdin. Plus d'infos . Il peut s'agir même d'une feuille de calcul Excel avec 2 colonnes : Terme et description ;
5) Si vous avez des commentaires dans les fichiers (c'est-à-dire Android XML, chaînes iOS, .properties, .yml, Google Chrome JSON), ils seront importés automatiquement avec le fichier ;
6) Vous pouvez télécharger la capture d'écran sur Crowdin et marquer n'importe quelle chaîne dessus : https://support.crowdin.com/adding-screenshots/
7) Si nous parlons de webapp l10n, il est logique d'essayer notre fonctionnalité In-Context pour permettre aux traducteurs de traduire directement sur votre site Web.

Ce ne sont que les principaux moyens de contextualiser les textes à traduire 😄

@Kebap a écrit :

Merci pour ces détails SlySven ! Il me semble, peut-être avez-vous déjà fait cela? Pour une autre candidature ? Avec Corwdin ? Cela rendrait la traduction de l'application Mudlet elle-même beaucoup plus facile.

Uniquement manuellement en utilisant les propres outils de Qt (j'ai passé quelques semaines dans le sud de la France au cours des deux dernières années à travailler sur les détails). Nous en utiliserons encore deux - lupdate & lrelease - mais nous remplaçons Qt Linguist (étant l'outil qui ajoute les traductions aux textes sources présents dans un certain nombre de .ts fichiers générés par lupdate pour chaque traduction, avant que lrelease transforme en fichiers spécifiques à la langue/l'emplacement mudlet_xx_YY.qm nécessaires - encore un par traduction langue/emplacement offert) avec Crowdin qui prendra un seul fichier mudlet.ts † et générera les fichiers mudlet_xx_YY.ts à la place.

Une différence importante entre l'utilisation de linguist et ce que nous allons faire avec Crowid est que nous pouvons nous en sortir sans :

TRANSLATIONS =

dans le fichier de projet pour Crowid.

† En fait, je pense que nous aurons besoin de deux fichiers - mudlet.ts pour tous les paramètres régionaux et qui passeront par le processus Crowdin et mudlet_en_US.ts qui seront extraits avec l'option -pluralonly et n'auront quelques traductions pour convertir des messages comme tr("deleted %n room(s)", "", roomCount) en "deleted 1 room" ou "deleted 2 rooms" selon la valeur de roomCount et peut probablement être faite par votre serviteur...

Super - nous allons avec Crowdin :)

Je vais ajuster le nom du fichier comme le suggère @SlySven et configurer le projet dans Crowdin proprement dit afin que les gens puissent commencer à traduire. Toutes les traductions de test existantes que nous avons effectuées seront enregistrées dans la mémoire de transaction, il sera donc assez facile de les réappliquer.

Répondre aux questions de @Kebap en tenant compte de la réponse de @SlySven :

• Découvrez un moyen de distinguer les textes obsolètes des textes actuels pertinents qui nécessitent une traduction.
  
  
  
  • lupdate outil
  
  
• Obtenez des textes à partir de sources (voir ci-dessus). Cela peut-il être automatisé avec n'importe quel outil ? Qui devrait être responsable ?
• Obtenez des textes dans l'outil de traduction.
  
  
  
  • nous exécutons manuellement lupdate et les engageons dans development - cette partie pourrait être automatisée quotidiennement par Travis
  
  
  • crowdin les récupère automatiquement grâce à l'intégration de github
  
  
• Outil de traduction interne (d'accord, c'est normal, mais nécessite également une bonne interface et des flux de travail)
  
  
  
  • l'interface de traduction de crowdin
  
  
• Les traducteurs rapportent des chaînes confuses à l'équipe Mudlet avec des informations sur la manière dont elles doivent être ajustées.
  
  
  
  • écrire un problème dans crowdin
  
  
• L'équipe Mudlet met à jour le texte dans la source. Soit à cause des rapports, soit à cause de l'évolution naturelle.
• Les textes mis à jour à partir de la source nécessitent des mises à jour dans l'outil de traduction. Exporter et importer à nouveau, plus diff.
  
  
  
  • crowdin le ramasse
  
  
• Les textes traduits seront terminés. Exportez-les depuis l'outil de traduction. Encore une fois l'automatisation ?
  
  
  
  • oui, crowdin ouvre automatiquement un PR : https://github.com/Mudlet/Mudlet/pull/1717
  
  
• Importez le texte traduit dans la source.
• Affichage des traductions dans la source. Ici, nous aurons besoin d'une sorte de commutateur de langue dans chaque source.
  
  
  
  • @SlySven fera de la magie ici :)
  
  

Quel est le besoin d'avoir un fichier de traductions séparé avec uniquement les pluriels ?

Les instructions de traduction sont disponibles sur https://wiki.mudlet.org/w/Translating_Mudlet