dourouc05 a écrit 11 commentaires

Merci pour ce retour :) !

À quel point êtes-vous satisfaits du logiciel pour la traduction, Weblate, par rapport à Pootle ? De ce que j'ai compris, les deux sont plus ou moins libres (GPL), mais était-ce un critère de choix ?

J'ai l'impression que ces deux logiciels sont prévus pour de la traduction de logiciels, mais pas de livres ou de contenu textuel aussi gros. Par exemple, le contexte n'est pas forcément bien indiqué. Dans la traduction de LFS, je vois que Weblate ne comprend pas du tout la syntaxe DocBook (https://translate.linuxfromscratch.org/translate/linux-from-scratch-11-3/chapter02_hostreqs/fr/ :
<emphasis role="strong">, par exemple) et n'indique pas ce qui pourrait être un titre (ce qui aide énormément à se retrouver dans un document).

Un logiciel qui comprend plus le fonctionnement d'un document ne serait-il pas mieux ? Je pense à SDL Trados Studio, surtout parce que c'est le seul dont j'ai entendu parler ><. Par exemple, dans la vidéo https://www.trados.com/products/trados-studio/whats-new-studio-2022.html, vers 3:00, ou encore https://www.youtube.com/watch?v=-QxkyjtP5zM, ils montrent la traduction d'un document avec des titres bien mis en évidence, avec du formatage de texte (gras, italique).

Tu produis une œuvre : tu possèdes tous les droits sur cette œuvre. C'est juste ça, "copyright". Tu décides de ce que tu en fais et, surtout, de ce que les autres peuvent en faire.

Les CC sont des licences : tu donnes des droits aux autres, mais uniquement parce que tu es charitable. Tu cèdes certains de tes droits. Dans tous les cas, en Europe, tu ne peux pas céder tous tes droits : tu gardes toujours la paternité de ton œuvre (c'est ton nom qui est mis dessus).

Pour Julia, il me semble qu'il n'y a pas d'interpréteur?

Non, pas besoin : tout est compilé à la volée (avec optimisations et tout). Ils ont des projets pour déployer un vrai interpréteur, mais ça ne semble pas si important.

-leur système de typage ne permet pas de différencier les 2 types de tableaux

Aucun problème : les tableaux standard sont des Vector, OffsetArray permet de changer les indices (pas juste commencer à zéro). Ce dont tu parles, c'est d'incompétents qui utilisent une interface trop générique pour leurs capacités de codage (AbstractVector n'indique jamais qu'un tableau commence avec l'indice 1, mais les types doivent implémenter axes s'ils ne respectent pas ce point). Ce n'est pas un problème de langage, mais d'utilisateurs… Et Julia est loin d'être le seul langage avec un problème de gens qui ne respectent pas les interfaces qu'ils implémentent ou utilisent.

Ils auraient pas pu utiliser des tableaux avec des index de début arbitraire (à la Ada) dès le début plutôt que de reléguer ça à une librairie???

C'est comme ça que le langage a été conçu : pas trop de choses dans la bibliothèque standard ou les types primitifs, mais laisser un maximum de liberté aux utilisateurs. Notamment, pourquoi imposer une seule manière d'implémenter cette fonctionnalité ? De ce que j'ai vu, Ada ne permet pas de surcharger l'opérateur d'indexation sur un tableau : comment implémenter quelque chose comme https://github.com/JuliaArrays/FFTViews.jl ? Je n'ai pas vu de bibliothèque proposant un type DataFrame (comme en R, Python, Julia, etc.) en Ada, alors que ces API utilisent énormément l'opérateur d'indexation.

En fait, avec la hauteur d'eau, tu peux calculer le débit plus ou moins facilement. C'est, par exemple, le principe d'un débitmètre. Pour les principes, tu peux regarder https://engees.unistra.fr/fileadmin/user_upload/pdf/shu/cours_HSL_FI_2006.pdf, page 31, mais ça nécessite pas mal de paramètres sur chaque rivière (pente, coefficient de rugosité). Si tu veux approfondir, regarde des cours d'écoulements à surface libre (open channel flow)

On a plutôt enfin un gouvernement, plus d'un an après la démission du dernier :) !

Lien vers l'article, si quelqu'un le cherche (accès payant…) : https://plus.lesoir.be/286535/article/2020-03-12/coronavirus-le-cabinet-de-block-dit-oui-lutilisation-des-donnees-telecoms

Plus que les optimisations, l'avantage de Julia est qu'il n'y a qu'un seul langage à apprendre : pour du code Python rapide, il n'y a pas trop le choix, il faut sortir de Python (écrire une extension, utiliser un compilateur à la Pythran, utiliser une implémentation de Python avec un JIT, etc.). Au contraire, avec Julia, on peut optimiser très fort son code sans sortir de Julia (et changer de langage n'apportera que des améliorations très marginales de performance, de l'ordre du pour cent).

De base, un code Julia ne sera pas forcément plus rapide qu'un code Python, si on l'écrit avec les pieds (aucune annotation de type, des fonctions qui peuvent renvoyer tout et n'importe quoi, le tout à l'intérieur des boucles qui prennent la majorité du temps de calcul, c'est se tirer une balle dans le pied). Avec un peu d'habitude, on finit vite par prendre le pli (pour un informaticien, en tout cas…) et écrire un code pas trop mauvais, mais on peut toujours améliorer la performance.

J'ai beau être sous Windows et utiliser un Azerty, sous le 6, je n'ai que § et ^ d'accessibles : tout le monde n'utilise pas la disposition française ! Ça a déjà causé quelques incompréhensions avec ces expressions qui n'ont de sens qu'en France…

Il y a quand même une série d'éditeurs WYSIWYM plus que corrects, parfois gratuits, mais rarement libres… (Le WYSIWYG n'a pas de sens, puisque DocBook n'a pas d'indication concernant la mise en page.) oXygen est mon préféré, mais payant (et pas donné) ; XMLmind est français (bon, c'est pas une raison) et gratuit (l'export PDF depuis l'éditeur a quelques altérations, il faut bien que la version payante ait quelque chose de plus). Les deux sont écrits en Java et sont utilisables sous tous les systèmes d'exploitation majeurs (et même sur le Web).

http://oxygenxml.com/
http://www.xmlmind.com/

Côté libre, j'ai entendu parler de Vex, une extension pour Eclipse, mais je n'ai jamais réussi à l'utiliser. (Problèmes d'installation.)

https://marketplace.eclipse.org/content/vex-latest-milestone

Sinon, oui, vraiment, pour moi, l'aspect sémantique est le gros avantage de DocBook par rapport à ces formats "modernes" : certes, pas besoin d'un éditeur spécifique, mais impossible de créer un premier index de manière automatisée (par exemple, en repérant tout le contenu des balises <firstterm>).

Sur une autre communauté francophone (dont je fais partie), Developpez.com pour ne pas la citer, on a une certaine culture de la traduction. Notamment, la traduction de Symfony3 est en cours de traduction, avec deux grosses parties publiées (le reste suit) : http://symfony.developpez.com/documentation/symfony3/part01-symfony3-et-les-fondamentaux-http/ et http://symfony.developpez.com/documentation/symfony3/part-02-symfony-vs-php-plat/. Le livre Think in Python a été traduit.

Par contre, il n'y a aucune volonté d'intégration : cette doc Symfony ne sera jamais donnée au projet (à moins d'une contrainte légale forte). L'habitude du site est de ne jamais de publier sous une licence libre. Il n'empêche, il a hébergé pas mal de gros projets de traduction (plus anciens), comme Think in C++ ou la documentation de Qt. Aussi, ce qui a été traduit n'est qu'exceptionnellement mis à jour…

Ne serait-ce pas dans la veine de ce que tu cherches ?

Quelque chose comme LyX ? J'adore son éditeur d'équations, très visuel (pour moi, largement supérieur à MathType) ; il est toujours possible de faire du copier-coller de code LaTeX vers un éditeur de texte brut au besoin. Un certain nombre de styles de document est disponible. Par contre, pour les images, il reste très loin d'Ulysses, à en voir le site : c'est plutôt une interface graphique pour LaTeX qu'autre chose (format de fichier différent, basé sur LaTeX, toujours en texte brut, avec des lignes de taille limitée : relativement facile de travailler à plusieurs avec Mercurial — ou Git ou autre pour ceux qui préfèrent). Pour les fonctionnalités non inclues, il reste possible de mettre son propre code LaTeX dans le document (en plus du préambule).

Niveau interface, cependant, c'est la même génération qu'un Word 95-2003. (La transition est difficile après le ruban Office.)