Mudlet: Arrêtez de perdre des traductions lors de la modification

Une idée de comment remédier ? @crowdin

Où tracez-vous la ligne entre conserver ou rejeter une traduction ?

Pour moi, remettre la traduction dans TM me semble le mieux, c'est très facile de la ressortir à nouveau et le traducteur peut décider s'il veut réutiliser le texte ou non.

Exactement, cette ligne doit être tracée individuellement pour chaque chaîne, comme le suggère la capture d'écran de Crowdin.

J'accueillerais favorablement une option permettant aux traducteurs de démarrer ce dialogue contextuel après avoir extrait les chaînes de github.

À l'heure actuelle, ils ne peuvent même pas distinguer quelles chaînes ont été traduites précédemment, pour corriger rapidement un pull.

Je ne pense pas qu'il soit raisonnable de passer des heures à chaque modification, à rechercher quelles traductions ont été cassées.

Lorsque vous utilisez le propre Linguist de Qt (ou plutôt lupdate ) pour mettre à jour directement un tas de fichiers .ts spécifiques à une langue à partir du code source, lupdate a une option :

          Drop all obsolete and vanished strings.

Ce n'est que si cette option est fournie que cela provoque des chaînes inutilisées ou obsolètes - c'est ainsi que je pense qu'un changement de commentaire est traité par CrowdIn - à purger des fichiers .ts . D'une manière ou d'une autre, nous devons faire en sorte que CrowdIn se comporte comme ça pour nous. :prier:

Surtout, je ne pense pas qu'un changement dans un commentaire (bien qu'un changement dans une désambiguïsation soit peut-être différent) devrait effacer la traduction - il pourrait être acceptable qu'il perde le statut "approuvé" mais pas qu'il soit oublié.

Salut tout le monde,

Sachez que vous pouvez également enregistrer les traductions des chaînes modifiées lors de la mise à jour du fichier via CLI / API / GitHub, en spécifiant le paramètre update_option dans le fichier de configuration ( crowdin.yml ) stocké dans votre dépôt.

Plus d'informations:
https://support.crowdin.com/configuration-file/#changed-strings-update

Après avoir effectué le changement, veuillez mettre en pause et reprendre l'intégration dans Crowdin pour appliquer les changements

J'espère que c'est exactement ce dont vous avez besoin !

Merci pour la réponse!

@Kebap quelle option souhaitez-vous ?

Merci les gars. C'est génial. Examinons les options en détail.

J'aimerais essayer l'option "update_as_unapproved", cela semble être un bon compromis : les traductions restent intactes, mais perdent leur statut approuvé.

Maintenant, quand j'ai testé cela, cela ne semblait pas fonctionner. Les chaînes perdaient toujours leurs traductions. Je suis même allé jusqu'à améliorer la brève mise en page créée automatiquement du fichier yaml de configuration , afin de refléter exactement l'exemple donné dans la section Base de connaissances liée ci-dessus.

Pourtant, le Crowdin a apparemment simplement remplacé les chaînes, au lieu de conserver leurs traductions et de simplement supprimer l'approbation. Est-ce que je le fais mal?

La chaîne avait auparavant une traduction et une approbation (l'approbation semble invisible dans le fichier .ts ?)

L'option de mise à jour "update_as_unapproved" a été testée avec une mise en page yaml courte et longue, toutes deux avec le même résultat

Après avoir modifié la chaîne (ou le commentaire), Crowdin affiche désormais la chaîne modifiée sans traduction ni approbation

Crowdin Diff signale que les chaînes sont "supprimées et ajoutées" et non "conservées mais ont perdu leur approbation"

-- Veuillez répondre au-dessus de cette ligne --

        Hi everyone,

Il semble que le problème est que dans votre projet, vos fichiers sont .html et
.ts. Les fichiers de ce type n'ont pas une structure KEY:VALUE claire,
par conséquent, lorsque vous mettez à jour les fichiers, chaque chaîne modifiée est
considérés comme de nouvelles chaînes. C'est le comportement attendu du système,
mais je demanderai aux développeurs s'il y a quelque chose qui peut être fait dans ce domaine
cas une fois qu'ils sont au bureau!

Comment évalueriez-vous ma réponse ?
Excellent [1] Correct [2] Pas bon [3]

--
Sincèrement,
Olga Kuhta
Responsable de la réussite client

Liens:

[1]
https://secure.helpscout.net/satisfaction/204306672/record/1818790773/1/
[2]
https://secure.helpscout.net/satisfaction/204306672/record/1818790773/2/
[3]
https://secure.helpscout.net/satisfaction/204306672/record/1818790773/3/

    > On Sat, Sep 8, 2018 at 1:34:23 EEST, Mudlet/mudlet <[email protected]> wrote:

Je voudrais essayer l'option "update_as_unapproved", cela semble être un
bon compromis : les traductions restent intactes, mais perdent leur valeur approuvée
statut.

Maintenant, quand j'ai testé cela, cela ne semblait pas fonctionner. Cordes toujours perdues
leurs traductions. Je suis même allé jusqu'à améliorer automatiquement
créé une brève mise en page du fichier de configuration yaml [1], afin de
reflètent exactement l'exemple donné dans la section Base de connaissances [2]
lié ci-dessus.

Pourtant, le Crowdin a apparemment simplement remplacé le
chaînes, au lieu de conserver leurs traductions et de simplement supprimer les
approbation. Est-ce que je le fais mal?

La chaîne avait auparavant une traduction et une approbation (l'approbation semble
invisible dans le fichier .ts ?)
[3]

L'option de mise à jour "update_as_unapproved" a été testée avec court et long
mise en page yaml, les deux au même résultat
[4]

Après avoir modifié la chaîne (ou le commentaire), Crowdin affiche maintenant modifié
chaîne sans traduction ni approbation
[5]

Crowdin Diff signale les chaînes comme "supprimées et ajoutées" et non "conservées mais
perdu leur approbation"
[6]

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub [7] ou désactivez le
fil [8].

Liens:

[1] https://github.com/Kebap/Mudlet/blob/crowdin-test/.crowdin.yml
[2]
https://support.crowdin.com/configuration-file/#changed-strings-update
[3]
https://user-images.githubusercontent.com/117238/45245753-12b3a300-b2fe-11e8-819a-fbc1cab389cd.png
[4]
https://user-images.githubusercontent.com/117238/45245828-632b0080-b2fe-11e8-8457-d16f53e62976.png
[5]
https://user-images.githubusercontent.com/117238/45245723-e7c94f00-b2fd-11e8-831d-14f3c0151aa8.png
[6]
https://user-images.githubusercontent.com/117238/45245651-843f2180-b2fd-11e8-8744-b431244e39e8.png
[7]
https://github.com/Mudlet/Mudlet/issues/1961#issuecomment -419583856
[8]
https://github.com/notifications/unsubscribe-auth/AA0k1tqzDWWwb2qGudFk9ENRg7Hm3D-Hks5uYvRcgaJpZM4WeaRq

Oui, Qt IDE utilise des fichiers .ts. Ce n'est certainement pas une niche. Une recommandation des développeurs Crowdin ?

Les commentaires de Qt n'étaient pas concluants :

(Kebap) Salut à tous ! Quelqu'un a-t-il déjà utilisé un site Web de service Web pour gérer les traductions et les traducteurs ? Nous utilisons Crowdin et ils semblent ne pas bien fonctionner avec le format de fichier Qt .ts. Ils semblent penser que chaque chaîne modifiée est une nouvelle chaîne et supprimera les anciennes traductions. Voir le fil suivant pour plus de détails. comment pouvons nous résoudre ceci? https://github.com/Mudlet/Mudlet/issues/1961
(frkleint) Kebap : Je recommanderais de publier sur la liste de diffusion http://lists.qt-project.org/mailman/listinfo/localization
(Kebap) On dirait que cette liste de diffusion concerne la traduction du projet Qt lui-même. Cependant, peut-être y a-t-il d'autres personnes qui construisent leur propre projet avec Qt et traduisent dans d'autres langues ?
(frkleint) Kebap : Oui, mais les bons mainteneurs/personnes le liront

Laissez-moi vérifier tous les détails, @Kebap. J'ai un "plan B" dans ma tête, mais je dois le tester.

Serait-il acceptable pour vous de stocker le texte source / les traductions dans le élément du fichier .ts ? Dans le vous pouvez avoir un ID de chaîne unique par exemple

À l'heure actuelle, nous importons/téléchargeons un fichier mudlet.ts qui contient le texte source vers CrowdIn et ils le traitent pour produire un mudlet_xx_YY.ts où xx est le code de langue à deux lettres et YY est un code de pays à deux lettres. Le mudlet.ts d'origine est, je crois, généré/mis à jour avec l'utilitaire Qt lupdate que je pense être exécuté à partir de notre répertoire source ./translations sous le nom lupdate -locations absolute ../src/mudlet.pro -ts ./mudlet.ts {at moins à partir d'un *nux OS}.

Il existe une alternative mais je ne sais pas si CrowdIn peut fonctionner comme ça dans laquelle nous fournissons les fichiers individuels .ts (actuellement :

• mudlet_de_DE.ts
• mudlet_el_GR .ts`
• mudlet_en_GB.ts
• mudlet_es_ES.ts
• mudlet_fr_FR.ts
• mudlet_it_IT.ts
• mudlet_nl_NL.ts
• mudlet_pl_PL.ts
• mudlet_ru_RU.ts
• mudlet_zh_CN.ts
• mudlet_zn_TW.ts

) fichiers à CrowdIn et demandez-lui/à l'équipe de traduction de travailler sur ceux-ci. Cela signifierait alors que les efforts de traduction existants sont conservés dans chaque fichier .ts - c'est en fait ainsi que Qt envisage la traduction - car le lupdate mettra alors à jour chaque fichier de traduction individuel avec les modifications des sources de code lors de son exécution mais ne supprimera pas (sauf indication explicite avec l'argument -no-obsolete ) les anciens textes qui n'apparaissent plus dans les sources. L'inconvénient est qu'il n'y a pas un seul fichier source pour toutes les traductions qui pourrait confondre/ne pas fonctionner avec le système CrowdIn. L'avantage est que # 1963 immédiat devient un non-problème car nous pouvons générer le fichier mudlet_en_US.ts contenant uniquement des pluriels et l'inclure simplement dans le téléchargement vers CrowdIn lors de la publication/version/quel que soit le changement...

Je pense que Crowdin nécessite un seul fichier en entrée. Je me souviens que lors de l'installation, il n'aimait pas plusieurs fichiers - à savoir, le problème était que le fichier d'entrée et de sortie était le même.

Bien que nous puissions simplement nommer les fichiers d'entrée et de sortie différemment ?

Crowdin peut certainement gérer plusieurs fichiers d'entrée, comme dans différentes chaînes à traduire. Cependant, dans le plan de SlySven, ils auraient tous un contenu identique. Cela signifierait que même l'équipe de traduction polonaise verrait tous les fichiers, y compris mudlet_it_IT.ts et mudlet_ru_RU.ts, etc. Par conséquent, nous n'avons pas continué sur cette voie beaucoup plus loin et avons plutôt opté pour un fichier de traduction central.

edit : L'explication pour la création de fichiers .ts est correcte, mais la vraie commande utilisée est : lupdate -recursive .\src\ -ts .\translationsmudlet.ts

Je ne sais pas ce que vous voulez dire là-bas, Vadim, mais je pense que Kebap est sur la même piste - nous pourrions entrer tous les fichiers, mais comment pouvons-nous ensuite dire/dire à CrowdId que seul le mudlet_ru_RU.ts de l'ensemble doit être montré au Traducteurs russes (Russie) ?

@vadi2 Vous avez raison, il est recommandé de télécharger un seul fichier source, Crowdin générera lui-même les fichiers traduits.

Veuillez ne pas télécharger de fichiers comme mudlet_ru_RU.ts dans le projet.

Nous pouvons probablement organiser un appel pour en discuter davantage ? Veuillez me joindre à andriy(at)crowdin.com

J'ai une idée en tête qui fonctionnera à coup sûr, mais j'ai besoin de savoir si vous en serez satisfait. Le fait est que .ts n'a pas d'identifiant unique pour chaque chaîne - comme dans .po, les fichiers où msgid est la source et l'identifiant en même temps, <source> est également le texte et l'identifiant (avec les éléments <context> et <name> , chaque chaîne est considérée comme unique et si vous modifiez <source> , la chaîne est considérée comme nouvelle et vous ne pouvez pas conserver les traductions pour les modifications chaînes dans le résultat).

Quoi qu'il en soit, il existe une assez bonne solution/contournement dont j'aimerais discuter/démontrer à votre équipe ;)

... et seuls certains contenus seraient les mêmes - les textes des sources - mais les traductions déjà faites pour chaque locale sont également stockées dans leur fichier respectif, et sont présentes dans chaque cycle de mise à jour-traduction suivant.

Si je comprends bien, le schéma d'identifiant de message unique est également autorisé dans le système Qt, mais il est plus difficile de travailler avec - et un changement en cours de projet n'est pas une tâche triviale (les deux systèmes s'excluent mutuellement et vous avez besoin d'une très bonne méthodologie pour trouver des identifiants significatifs) - et une partie de l'avantage du schéma existant est que les chaînes en double sont fusionnées en une seule traduction commune, c'est juste que changer l'un nécessite que les autres changent également s'ils sont destinés à être le même...

Lorsque nous traduisons toutes les chaînes dans une langue à 100 %, puis que nous en éditons quelques-unes dans une version, ne serait-il pas toujours très facile de les parcourir et de les rajouter grâce à TM ?

Ce problème ne semble être un vrai problème que parce que nous n'avons pas encore atteint 100 %.

@vadi2 au cas où vous souhaiteriez avoir la possibilité de traduire automatiquement les chaînes nouvellement ajoutées à l'aide de TM, vous pouvez configurer un tel flux de travail à l'aide de la fonction Advanced Workflows (je viens de l'activer pour votre compte)
https://support.crowdin.com/advanced-workflows/

Merci, apprécié :) nous allons étudier cela.

@Kebap a écrit :

edit : L'explication pour la création de fichiers .ts est correcte, mais la vraie commande utilisée est : lupdate -recursive .\src\ -ts .\translationsmudlet.ts

-recursive est le cas d'argument par défaut et n'est pas nécessaire - tout comme le -locations absolute pour les nouveaux fichiers apparemment... :slightly_smiling_face: - Je découvrais juste cela en vérifiant pour voir quel effet les problèmes que lupdate a toujours avec les littéraux de chaînes brutes C++11/14 { QTBUG , #1310} et si des chaînes sont perdues dans le fichier mudlet.ts parce qu'elles le confondent. . :froncer les sourcils:

@Kebap Est-ce toujours un problème ?

Oui, même si ce n'est pas aussi mauvais qu'avant le changement. Mais c'est toujours déroutant, même pour les initiés, comme vous pouvez le voir par le numéro lié d'il y a une semaine.

De plus, il y a un peu de course actuellement alors que la plupart des langues ne sont pas encore proches de 100 %, traduiront-elles les chaînes plus rapidement qu'elles ne perdront à nouveau les traductions ?

De plus, j'ai trouvé un problème qui semble ramener des traductions supprimées. Actuellement, je ne trouve aucun moyen de supprimer une traduction du Crowdin. Après la prochaine mise à jour, il sera à nouveau ajouté automatiquement.

@Andrulko Avez-vous des mises à jour ici ? Vous parliez d'un plan B ci-dessus..

Aussi, pourquoi Crowdin fait-il ce comportement étrange dans TM maintenant !? Voir la capture d'écran ci-dessous pour comparaison.

Tout ce que nous avons changé ici est h3 en a . Aucune autre étiquette n'a été touchée. Maintenant ce qui est arrivé?

Vous attendriez-vous à ce que les traducteurs remplacent chaque {[=-lt;-=]}h2{[=-gt;-=]}{[=-lt;-=]}u{[=-gt;-=]} par <h2><u> ou plutôt <0> manuellement ?

Lien vers l'exemple : https://crowdin.com/translate/mudlet/137/en-de
Capture d'écran de l'exemple :

Je pense que c'est un bogue dans Crowdin's TM. Il est probablement préférable de leur signaler un problème distinct.

Je les ai également informés ici : https://crowdin.com/contacts

Bonjour, nous avons déjà vérifié votre demande et répondu à votre e-mail. S'il vous plaît laissez-nous savoir si vous avez d'autres questions!