Johnny Jazeix a écrit 58 commentaires

Est-il possible d'avoir une capture d'écran de votre essai ? Je n'arrive pas à reproduire de mon côté

Normalement chaque niveau est décorrélé donc passer à un niveau supérieur et revenir en arrière ne devrait pas avoir d'impact.
Je viens d'essayer le calcul que vous avez donné et je n'ai pas eu de problème.

Bonjour,
quelle addition faites-vous, que mettez-vous comme résultat et quelle est l'erreur ?

Il faut bien mettre les retenues pour que le résultat soit validé.

A l'époque, on avait porté GCompris pour qu'il fonctionne sur Sailfish OS, mais le fait que la version de Qt du SDK soit restée en 5.6 fait que nous avons dû arrêter de fournir un paquet pour Sailfish OS.

Du peu de recherche que j'ai fait (https://docs.sailfishos.org/Reference/Qt/), c'est toujours cette version qui est utilisée et ça n'a pas l'air d'évoluer (https://forum.sailfishos.org/t/what-version-of-qt-are-we-on/4964/46, de mars 2023).

On fournit aussi des paquets auto-extractibles sous Linux : https://gcompris.net/downloads-fr.html#linux qui devraient fonctionner si le kernel n'est pas trop ancien

Je ne suis pas sûr de comprendre à quelle inversion tu fais allusion, est-ce dans la dépêche ou dans le jeu lui-même ? Si c'est le cas, peux-tu envoyer qu'une capture qui permettra de mieux me faire comprendre ?

Non, ce n'est pas Bruno Coudoin qui est revenu :-).

Super, on a hâte d'avoir les retours !
Pour la grammaire, un professeur nous a proposé de mettre à jour les phrases proposées. Selon le nombre qu'on a, je pense qu'on pourra toujours en intégrer plus et limiter le nombre de questions par niveau à 10 ou 20.

Bien reçu aujourd'hui. Merci à vous !

J'ai oublié de mettre quelques images (ce qui me fait voir que j'ai oublié de les mettre à jour suite au changement de nom) :

Merci !
Effectivement j'avais trouvé le nom/prénom de la personne, mais pas de mail direct.
Je préfèrerais ne pas avoir à envoyer un mail sur l'adresse mail d'un de ses collègues de travail mais si c'est la dernière solution que je trouve pour le contacter, je le ferai dans quelques jours.

C'est une discussion assez récurrente qui revient (entre Git et les interfaces en ligne pour traduire) : il y a une tâche avec énormément d'aller-retours.

De ce que je comprends, après un passage rapide :

• migrer les scripts actuels, il faut un volontaire ;
• même si cela permettrait d'avoir plus de contributeurs, cela n'assurerait pas une meilleure qualité ;
• SVN reste un outil "interne" dans le sens où, si quelqu'un veut faire une modification, ce sont en général les mainteneurs ;
• d'un point de vue sysadmins, l'équipe préférerait évidemment que la traduction migre à Git car c'est le dernier cas d'utilisation de SVN ;
• il faudrait peut-être revoir la structure du/des dépôts, pour le moment, toutes les traductions sont dans le même dépôt SVN et on peut cloner seulement une langue. Avec Git, soit il faut splitter les dépôts, soit tout télécharger…

La discussion est très longue donc j'ai seulement pris quelques arguments rapidement, mais il y en a d'autres…

Récemment, il y a aussi eu la migration des scripts Pology qui étaient en Python 2 en Python 3. Étant donné que c'est un gros code avec peu de tests unitaires, que le but est de toucher pas mal de chaînes de caractères, la volonté de changer était présente, mais les compétences moins donc ça a pris plusieurs années.

Pour les manuels utilisateurs (accessibles ici), on peut les remplacer pour chaque langue si quelqu'un fait le travail. Par exemple, pour KStars :

• français
• anglais

Pour cela, il faut mettre les images traduites dans le SVN.

Je suis en train de me renseigner, c'est à priori possible de faire pareil pour les sites web (au moins ceux codés en Hugo) en mettant dans le git une image traduite (j'imagine en postfixant avec "-$locale") mais je n'ai pas trouvé d'exemple où c'est réalisé

Comme pour tous les fichiers, si plusieurs personnes les modifient en même temps, il risque d'y avoir des conflits au moment de la fusion des fichiers avec ceux du dépôt.

En général, c'est assez rare que plusieurs personnes travaillent sur le même fichier en même temps, et pour éviter ça, nous préférons que les personnes "réservent" des fichiers pour être sûr d'éviter de dupliquer du travail (car une personne qui a pris le temps de faire une traduction et voit son travail échangé va avoir moins d'envie de contribuer).

Après, s'il y a des conflits au niveau du fichier (car la version récupérée par le traducteur est trop vieille par exemple et il y a eu pas mal de changements sur les chaînes en anglais entre temps), selon le niveau technique de la personne qui traduit, les coordinateurs vont gérer eux-mêmes les conflits, committer le fichier sous SVN et ensuite demander au traducteur de repartir du dernier fichier en conf.

Il y a deux raisons principales pour moi :

• il y a beaucoup d'outils permettant de travailler avec les fichiers .po (https://www.gnu.org/software/gettext/manual/gettext.html) ;

• et surtout il n'y a pas que les applications développées en Qt qui ont besoin de traduction. Par exemple, les sites internet (par exemple, le site internet de GCompris utilise pybabel pour extraire les chaînes d'un site généré statiquement en Jinja2) ou la documentation qui est au format docbook.

Si des utilisateurs veulent aider à améliorer la traduction, n'hésitez pas (les fichiers sont dans https://fr.l10n.kde.org/apps/pofiles.php#kdenlive).
Nous sommes en train de préparer une dépêche pour expliquer de façon plus générale l'état des lieux de la traduction des logiciels de KDE et comment contribuer

On a aussi mis à jour quelques langues (turc complété entre autres)

La version 3.2 qui est sortie il y a quelques jours est disponible sous snap :).

La personne qui créé les paquets snap pour KDE dispose d'un gofundme (https://www.scarlettgatelymoore.dev/kde-snaps-many-new-releases-more-to-come/) si vous souhaitez l'aider financièrement.

Ça doit être bon maintenant. Le paquet a été mis à jour dans la journée.

Il y a un problème actuellement pour mettre à jour les applications KDE en snap, c'est en cours.
Donc ça va arriver, mais je ne peux pas donner de date !

C'est bien le cas, il manque un paquet côté openSUSE, je viens de remonter le problème à l'un des packageurs.
Merci d'avoir remonté ce problème.

L'équipe est limitée en terme de personnes mais oui, on essaie au mieux d'intégrer les fonctionnalités souhaitées !

Un autre exemple, l'activité de morse a été commencée par un étudiant il y a 4-5 ans et j'ai seulement trouvé du temps cette année pour la finaliser.

Ce n'est pas l'équipe de GCompris qui gère directement ce canal. Je me renseigne et je reviens :). Normalement, pas de raison de ne pas l'avoir !

Je viens de corriger le bug des ancrages, cela devrait fonctionner correctement maintenant.

Merci !

Merci à l'équipe !

Je ne connais pas assez qbs pour me prononcer, ses capacités en plus ou moins par rapport à CMake ni ses différences pour mettre en place la compilation multiplateformes, gérer des sous projets avec des systèmes de compilation différents (ici, qml-box2d compile avec qmake, openssl avec un configure/make), avoir des targets spécifiques (on se sert aussi de CMake pour récupérer les fichiers de traduction, les compiler, créer des fichiers rcc pour les activités)…

Ici les problèmes étaient pas mal de "vieux" code et le fait d'avoir des sous-modules à compiler et installer au bon endroit. Je ne sais pas si avoir un autre système de build aurait changé grand chose à ces soucis.