Non, le message précédent n'a pas été supprimé par l'équipe de modération. Ce n'est qu'un petit malin qui a posté un commentaire similaire. Les commentaires vraiment supprimés l'équipe de modération ont la classe CSS deleted, ce qui se traduit par une bordure rouge à gauche du message avec le feuille de style par défaut.
Si cela venait à se reproduire, nous serions bien moins clément (fermeture du compte).
Pour le manifestement illégal, c'est marqué : « édition/suppression systématique + prévenir ».
On prévient par email la personne dont le contenu/commentaire à été modifié/supprimé, pas tous les utilisateurs.
Et dans le cas du fameux dérangeant, c'est marqué :«pas d'édition/suppression sans discussion, commentaire de rappel à systématiser pour éviter les dérives».
Dans un premier temps, on rappelle aux utilisateurs les règles élémentaires de courtoisie et de respect des autres utilisateurs sur le site. Puis, si ça ne suffit pas, l'équipe de modération en discute et prend une décision ensemble (un modérateur ne doit pas modifier/supprimer ce contenu ou commentaire avant qu'un consensus ne soit atteint ou qu'un délai suffisant soit passé).
Par contre, cela ne dit pas que l'équipe de modération doit se justifier publiquement (même si dans la pratique, elle le fera quasi-systématiquement).
Des règles ont été écrites, ce n'est pas moi qui les ai écrites, c'est l'équipe de modos. Donc, nous simples utilisateurs, on s'attend quand même à ce qu'elles soient respectées.
Jusque là, elles ont été respectées.
Or, là un cas pratique se présente, pas très grave, plutôt facile à gérer, et c'est déjà le bordel.
Ce n'est pas un cas pratique de la mise en application de ces règles. La charte de modération ne dit nulle part ce qui se passe quand un modérateur clique sur le mauvais bouton.
Dans quel sens ? Le sous-domaine ou le reverse-proxy cache ?
Actuellement, c'est déjà ce sous-domaine qui sert pour les utilisateurs qui uploadent leurs CSS. Par contre, ça ne passe par le mécanisme de reverse-proxy cache, ce sont juste des fichiers statiques qui sont servis.
Si c'est bien du reverse-proxy cache dont on parle, quel serait l'intérêt de le faire ?
Si je ne me trompe, le fait d'héberger les CSS devraient permettre de servir ces CSS en https, non ? Dans ce cas, fini les navigateurs qui râlent si on navigue en https et que la css perso est en http !
Effectivement, les feuilles de style hébergées sur LinuxFr.org sont servies via une URL en protocol relative (cf RFC 1808 partie 2.2 et RFC 3986 partie 4.2), donc en HTTPS quand on navigue sur le site en HTTPS.
Le premier commentaire sur ce journal demandait l'ajout d'un lien au journal. Un modérateur a fait cela puis a supprimé le commentaire en question par erreur. On voyait encore le commentaire, mais avec la phrase « Ce commentaire a été supprimé par l'équipe de modération ». Cela a fait réagir plusieurs lecteurs, d'où le fil de discussions. Dans le même temps, l'équipe de modération a taché de comprendre pourquoi le commentaire avait été supprimé et, quand l'erreur a été avérée, l'a remis en ligne.
Pour les références à "foin 3 jours avant" je vais aller trouver tout seul…
Ce n'est pas simple pour des raisons de sécurité : les CSS peuvent contenir du javascript et donc faire des vilaines choses.
Pour contourner ce problème, les CSS seront hébergées sur un sous-domaine et non pas le domaine principal. Les règles de Same Origin Policy des navigateurs nous protège alors des attaques que les CSS pourraient contenir.
Ce cas d'usage peut être fait simplement si on peut uploader une feuille de style. Il suffit juste d'importer la feuille de style que l'on veut surcharger au début de sa CSS avec un @import.
Ce que je voulais dire c'est que les membres permanents de l'association, son cercle dirigeant, peut très bien cautionner le bannissement d'une moule même si c'est totalement arbitraire, genre pour raison personnelle. Non ?
Bah, toujours pas. L'association LinuxFr.org a pour objet de promouvoir Linux et le Logiciel Libre et les membres de l'association ne peuvent utiliser ses ressources que pour réaliser cet objectif. Cela laisse beaucoup de marges d'interprétation (tel utilisateur nuit à l'ambiance du site, ce qui gêne pour la promotion de Linux et du Logiel Libre => on le bannit), mais ça ne sera jamais totalement arbitraire.
Mais là, on nous a fait tout un foin sur le fait qu'il y a des règles pour éviter l'arbitraire, et ces règles sont écrites.
Je n'ai pas vraiment l'impression que l'équipe de modération en ait fait tout un foin. Nous avons été sévèrement critiqué pour avoir agi de manière différente sur des cas similaires, nous avons eu des conflits au sein de l'équipe de modération qui ont provoqué le départ de certains modérateurs, il nous a donc semblé sain de se mettre d'accord sur des règles et de les communiquer.
Donc, je me dis que ça serait bien qu'il y ait une certaine transparence sur l'application de ces règles, ça me semble normal. Sinon, ça revient à retourner dans l'arbitraire (et donc au passage à se foutre implicitement de la gueule des utilisateurs en leur faisant croire qu'il y a des règles).
Il y a deux choses : l'application des règles et la communication vis-à-vis des utilisateurs du site. Les modérateurs doivent respecter les règles et en rendre compte à l'association LinuxFr.org, pas aux utilisateurs. Pour la communication, il n'y a pas d'obligation (il n'est pas marqué dans la charte que l'équipe de modération devra justifier son intervention ou d'autre chose équivalent).
Par contre, à titre personnel, je reste favorable sur le fait d'expliquer les raisons qui nous amènent à supprimer des commentaires. Mais ça peut venir plus tardivement (comme ça a été le cas ici), parce que cela nécessite parfois un peu plus de coordination de l'équipe de modération. On peut vouloir supprimer rapidement un commentaire mais prendre un peu de temps pour l'expliquer car on sait que certains utilisateurs vont nous tomber dessus si on emploie une formulation malheureuse.
Au final, j'ai quand même l'impression que c'est surtout un problème de confiance dans l'équipe de modération. Pour caricaturer : « si elle ne précise pas la raison tout de suite, c'est que c'est forcément une mauvaise raison et on va râler pour le faire savoir ».
LinuxFR n'est pas un service publique, LinuxFR n'est pas un service payant auquel tu es abonné. LinuxFr est un site privé, si il y a embrouille entre un membre et un modérateur, le bannissement, qu'il soit justifié ou non sur un plan éthique, est un droit que possède ce modérateur.
C'est plus compliqué que ça. LinuxFr.org est un site web géré par l'association LinuxFr.org. L'association donne des pouvoirs à certains membres, les modérateurs, pour régler les problèmes qui pourraient survenir sur le site. Ça ne veut pas dire que les modérateurs ont tous les droits. Mais bannir ceux qui ne respectent pas les règles, ça, ils ont tout à fait le droit.
Et du coup, une fois que le commentaire a été supprimé, comment on fait pour savoir à quelle catégorie il appartient ?
Les modérateurs peuvent poster un commentaire en réponse pour expliquer leur démarche. Il est également envisager de fournir une raison lorsque l'on supprime un commentaire.
Mais la vraie question est pourquoi tu aurais besoin de connaître la catégorie à laquelle il appartient. Tu ne fais aucune confiance à l'équipe de modération ?
Ce n'est pas un reproche, j'aimerais juste comprendre pourquoi on se prend des commentaires désobligeants à chaque fois qu'un commentaire est supprimé alors que je n'ai vraiment pas l'impression que l'on se sert souvent de ce pouvoir et ni que ce soit des abus quand c'est le cas.
Et dans le cas pratique qui nous intéresse ici, ça rentre dans quel catégorie ?
Aucune de celles citées, c'est juste une erreur de manipulation. Tu devrais lire les autres commentaires avant de poster (cf celui de neox)
Et pourquoi les exceptions ne sont pas documentées dans les règles (parce que sinon, ça sert à rien d'avoir des règles) ?
Quand un auteur demande à retirer son commentaire, ce n'est pas de la modération, juste l'application de son droit le plus strict (comme indiqué en bas des pages : « les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables. »).
Pour le reste, je t'invite à relire la charte, c'est documenté. L'exemple du spam est traité un peu au-dessus des propos que tu as cité : « les contenus, commentaires et comptes de spammeurs → édition/suppression systématique ».
Je fais mon chieur, mais bon la nouvelle sur ces règles et les nombreuses questions soulevées trouvent ici une application pratique qui montre les limites des dites règles.
Évidemment que les règles en question n'empêchent pas les erreurs des modérateurs.
pas d'édition/suppression sans discussion, commentaire de rappel à systématiser pour éviter les dérives
Sauf pour le "manifestement illégal"
Il y a pas mal d'autres exceptions à cette règle, comme le spam ou l'auteur qui demande à ce que l'on supprime son commentaire. En fait, la règle en question ne s'applique qu'à la catégorie « Le dérangeant divers et varié (et peut-être illégal) » (catégorie dont le nom n'est pas forcément très heureux, mais bon), et le commentaire en question n'entre pas dans cette catégorie.
EPUB 3 prend en charge ce problème grâce à MathML. Tu peux, par exemple, tester ça avec Readium en allant sur le premier livre (A First Course in Linear Algebra).
Tu peux détailler pourquoi html serait insuffisant pour les meta-données ? Pour autant que je sache, les meta-données utilisées en epub sont les mêmes qu'en html (Dublin Core, <meta> et <link>).
un sommaire n'est jamais qu'un agrégat de liens. Exemple ici.
Exact, mais il faut un format précis.
Certes un sommaire doit pouvoir être lisible par une machine, mais html fournit déjà des titres (<h1> à <h6>) qui devrait permettre à une liseuse d'afficher un sommaire. Ce sommaire est construit automatiquement et n'est pas décrit dans un document à part. Ça donne moins de souplesse aux créateurs d'ebooks pour choisir ce qui va dans le sommaire mais me semble suffisant dans beaucoup de cas.
Bien sûr : EPUB est basé sur HTML. Mais pas seulement, parce qu'HTML ne suffit pas.
Pour moi, EPUB, c'est un fichier zip qui contient plusieurs fichiers HTML et des ressources pour les accompagner (images, CSS, etc.). Après on rajoute dans le zip un fichier d'index parce que ce serait compliqué de faire sans. Il liste les fichiers présents dans le zip (<manifest>, je ne sais pas à quoi il sert), dit dans quel ordre il faut afficher les fichiers HTML (<spine>, ce que tu sembles appeler le sommaire même s'il n'y a aucun titre dedans, juste une suite de référence de fichiers) et enfin des méta-infos (<metadata>, que l'on a mis dans ce fichier juste pour ne pas avoir à deviner dans quel(s) fichier(s) elles sont).
Pour des ebooks simples, je ne vois rien qui empêcheraient de faire ça en HTML :
les métas, on peut (cf ci-dessus) ;
le sommaire, idem (suffit d'extraire les balises <h1> à <h6>) ;
plusieurs chapitres, html5 propose une balise <section> qui me paraît bien convenir pour ça ;
des images, on peut les encoder en base64 et les embarquer à coup de data URI.
Après, ce n'est pas parce que l'on peut que c'est souhaitable. Pour les ebooks simples (des romans par exemple), html convient bien à mon avis. Pour les trucs plus poussés, EPUB a des avantages.
Maintenant, je ne prétends pas être un expert en EPUB, donc si je me trompe, n'hésite pas à me corriger.
Le premier commentaire de ce journal n'a pas été censuré, il a juste été supprimé à la demande de l'auteur suite à une maladresse d'un des modérateurs.
De la même manière, il serait appréciable de remplacer lorsque c'est possible "l'équipe de modération" par le pseudo de l’intéressé.
Nous en avons déjà discuté et cela ne changera pas. L'équipe de modération agit de manière construite et solidaire. La suppression d'un commentaire n'est pas le résultat d'une action personnelle mais l'application de la charte de modération. En particulier, les cas litigieux sont discutés par l'équipe et donc peu importe qui appuie sur le bouton au final.
Tu es sûr de vouloir faire du C++ ? Dans le cas contraire, je te conseillerais d'aller jeter un coup d'oeil à Go.
À mon avis, il conviendrait bien pour ça. Par exemple, tu parlais de 200 000 clients et Go peut très bien gérer 200 000 goroutines (une sorte de thread en plus léger). Le passage de messages entre ces goroutines se fait avec des chans (ça vient de base avec le langage).
Maintenant, si tu préfères rester sur du C++, ce que je peux comprendre, je n'ai pas grand chose à te conseiller ;-)
# Déplacé dans l'aide
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi 403 Sur le wiki ?. Évalué à 3 (+0/-0).
En fait, cette page de wiki a été supprimée car son contenu a été déplacé dans l'aide : http://linuxfr.org/aide#aide-karma.
Par contre, c'est vrai que ce n'est pas idéal d'un point de vue expérience utilisateur et qu'il y a sûrement quelque chose à faire de ce coté-là.
# Gif animé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Limiter la taille des avatars. Évalué à 3 (+0/-0).
Il faudrait aussi interdire les GIF animés pour les avatars. Cf https://linuxfr.org/suivi/justifier-les-censures#comment-1373024 par exemple.
[^] # Re: Protégez-vous..
Posté par Bruno Michel (site web personnel) . En réponse au journal Ubisoft fait mieux que Sony. Évalué à 2.
Non, le message précédent n'a pas été supprimé par l'équipe de modération. Ce n'est qu'un petit malin qui a posté un commentaire similaire. Les commentaires vraiment supprimés l'équipe de modération ont la classe CSS
deleted, ce qui se traduit par une bordure rouge à gauche du message avec le feuille de style par défaut.Si cela venait à se reproduire, nous serions bien moins clément (fermeture du compte).
[^] # Re: Correction du lien non fonctionnel
Posté par Bruno Michel (site web personnel) . En réponse au journal Debian 8.0 A.K.A Jessie. Évalué à 4.
On prévient par email la personne dont le contenu/commentaire à été modifié/supprimé, pas tous les utilisateurs.
Dans un premier temps, on rappelle aux utilisateurs les règles élémentaires de courtoisie et de respect des autres utilisateurs sur le site. Puis, si ça ne suffit pas, l'équipe de modération en discute et prend une décision ensemble (un modérateur ne doit pas modifier/supprimer ce contenu ou commentaire avant qu'un consensus ne soit atteint ou qu'un délai suffisant soit passé).
Par contre, cela ne dit pas que l'équipe de modération doit se justifier publiquement (même si dans la pratique, elle le fera quasi-systématiquement).
Jusque là, elles ont été respectées.
Ce n'est pas un cas pratique de la mise en application de ces règles. La charte de modération ne dit nulle part ce qui se passe quand un modérateur clique sur le mauvais bouton.
[^] # Re: cool
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche trop stylé en mobilité !. Évalué à 4.
Dans quel sens ? Le sous-domaine ou le reverse-proxy cache ?
Actuellement, c'est déjà ce sous-domaine qui sert pour les utilisateurs qui uploadent leurs CSS. Par contre, ça ne passe par le mécanisme de reverse-proxy cache, ce sont juste des fichiers statiques qui sont servis.
Si c'est bien du reverse-proxy cache dont on parle, quel serait l'intérêt de le faire ?
[^] # Re: cool
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche trop stylé en mobilité !. Évalué à 5.
Effectivement, les feuilles de style hébergées sur LinuxFr.org sont servies via une URL en protocol relative (cf RFC 1808 partie 2.2 et RFC 3986 partie 4.2), donc en HTTPS quand on navigue sur le site en HTTPS.
[^] # Re: EPUB ou rien
Posté par Bruno Michel (site web personnel) . En réponse au journal livre numérique des éditions eni. Évalué à 6.
Je recommande The Pragmatic Bookshelf. Ils fournissent les ebooks aux formats Epub, PDF et mobi, sans DRM.
[^] # Re: Correction du lien non fonctionnel
Posté par Bruno Michel (site web personnel) . En réponse au journal Debian 8.0 A.K.A Jessie. Évalué à 7.
Le premier commentaire sur ce journal demandait l'ajout d'un lien au journal. Un modérateur a fait cela puis a supprimé le commentaire en question par erreur. On voyait encore le commentaire, mais avec la phrase « Ce commentaire a été supprimé par l'équipe de modération ». Cela a fait réagir plusieurs lecteurs, d'où le fil de discussions. Dans le même temps, l'équipe de modération a taché de comprendre pourquoi le commentaire avait été supprimé et, quand l'erreur a été avérée, l'a remis en ligne.
Il fait référence à la charte de modération annoncée dans la dépêche Règles de modération des contenus, commentaires et comptes problématiques.
[^] # Re: s/rappelle/rappellent
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche War§ow 1.0 est sorti !. Évalué à 4.
Effectivement, c'est corrigé.
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Hébergement de css. Évalué à 3 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/4dfde4a1aeb507fb083565ed94a8b21624f91791
[^] # Re: Pas évident
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Hébergement de css. Évalué à 3 (+0/-0).
Pour contourner ce problème, les CSS seront hébergées sur un sous-domaine et non pas le domaine principal. Les règles de Same Origin Policy des navigateurs nous protège alors des attaques que les CSS pourraient contenir.
[^] # Re: Oui juste avoir un champ CSS per
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Hébergement de css. Évalué à 3 (+0/-0).
Ce cas d'usage peut être fait simplement si on peut uploader une feuille de style. Il suffit juste d'importer la feuille de style que l'on veut surcharger au début de sa CSS avec un
@import.[^] # Re: Correction du lien non fonctionnel
Posté par Bruno Michel (site web personnel) . En réponse au journal Debian 8.0 A.K.A Jessie. Évalué à 5.
Bah, toujours pas. L'association LinuxFr.org a pour objet de promouvoir Linux et le Logiciel Libre et les membres de l'association ne peuvent utiliser ses ressources que pour réaliser cet objectif. Cela laisse beaucoup de marges d'interprétation (tel utilisateur nuit à l'ambiance du site, ce qui gêne pour la promotion de Linux et du Logiel Libre => on le bannit), mais ça ne sera jamais totalement arbitraire.
Merci :)
[^] # Re: Correction du lien non fonctionnel
Posté par Bruno Michel (site web personnel) . En réponse au journal Debian 8.0 A.K.A Jessie. Évalué à 6. Dernière modification le 30 juillet 2012 à 09:15.
Je n'ai pas vraiment l'impression que l'équipe de modération en ait fait tout un foin. Nous avons été sévèrement critiqué pour avoir agi de manière différente sur des cas similaires, nous avons eu des conflits au sein de l'équipe de modération qui ont provoqué le départ de certains modérateurs, il nous a donc semblé sain de se mettre d'accord sur des règles et de les communiquer.
Il y a deux choses : l'application des règles et la communication vis-à-vis des utilisateurs du site. Les modérateurs doivent respecter les règles et en rendre compte à l'association LinuxFr.org, pas aux utilisateurs. Pour la communication, il n'y a pas d'obligation (il n'est pas marqué dans la charte que l'équipe de modération devra justifier son intervention ou d'autre chose équivalent).
Par contre, à titre personnel, je reste favorable sur le fait d'expliquer les raisons qui nous amènent à supprimer des commentaires. Mais ça peut venir plus tardivement (comme ça a été le cas ici), parce que cela nécessite parfois un peu plus de coordination de l'équipe de modération. On peut vouloir supprimer rapidement un commentaire mais prendre un peu de temps pour l'expliquer car on sait que certains utilisateurs vont nous tomber dessus si on emploie une formulation malheureuse.
Au final, j'ai quand même l'impression que c'est surtout un problème de confiance dans l'équipe de modération. Pour caricaturer : « si elle ne précise pas la raison tout de suite, c'est que c'est forcément une mauvaise raison et on va râler pour le faire savoir ».
[^] # Re: Correction du lien non fonctionnel
Posté par Bruno Michel (site web personnel) . En réponse au journal Debian 8.0 A.K.A Jessie. Évalué à 5.
C'est plus compliqué que ça. LinuxFr.org est un site web géré par l'association LinuxFr.org. L'association donne des pouvoirs à certains membres, les modérateurs, pour régler les problèmes qui pourraient survenir sur le site. Ça ne veut pas dire que les modérateurs ont tous les droits. Mais bannir ceux qui ne respectent pas les règles, ça, ils ont tout à fait le droit.
[^] # Re: Correction du lien non fonctionnel
Posté par Bruno Michel (site web personnel) . En réponse au journal Debian 8.0 A.K.A Jessie. Évalué à 5.
Les modérateurs peuvent poster un commentaire en réponse pour expliquer leur démarche. Il est également envisager de fournir une raison lorsque l'on supprime un commentaire.
Mais la vraie question est pourquoi tu aurais besoin de connaître la catégorie à laquelle il appartient. Tu ne fais aucune confiance à l'équipe de modération ?
Ce n'est pas un reproche, j'aimerais juste comprendre pourquoi on se prend des commentaires désobligeants à chaque fois qu'un commentaire est supprimé alors que je n'ai vraiment pas l'impression que l'on se sert souvent de ce pouvoir et ni que ce soit des abus quand c'est le cas.
Aucune de celles citées, c'est juste une erreur de manipulation. Tu devrais lire les autres commentaires avant de poster (cf celui de neox)
Quand un auteur demande à retirer son commentaire, ce n'est pas de la modération, juste l'application de son droit le plus strict (comme indiqué en bas des pages : « les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables. »).
Pour le reste, je t'invite à relire la charte, c'est documenté. L'exemple du spam est traité un peu au-dessus des propos que tu as cité : « les contenus, commentaires et comptes de spammeurs → édition/suppression systématique ».
Évidemment que les règles en question n'empêchent pas les erreurs des modérateurs.
[^] # Re: Faut arrêter de voir de la censure partout...
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Justifier les censures. Évalué à 3 (+0/-0).
Les commentaires dans le journal en question sont très agressifs et montrent également un manque de confiance dans l'équipe de modération.
[^] # Re: Correction du lien non fonctionnel
Posté par Bruno Michel (site web personnel) . En réponse au journal Debian 8.0 A.K.A Jessie. Évalué à 3. Dernière modification le 29 juillet 2012 à 23:48.
Il y a pas mal d'autres exceptions à cette règle, comme le spam ou l'auteur qui demande à ce que l'on supprime son commentaire. En fait, la règle en question ne s'applique qu'à la catégorie « Le dérangeant divers et varié (et peut-être illégal) » (catégorie dont le nom n'est pas forcément très heureux, mais bon), et le commentaire en question n'entre pas dans cette catégorie.
[^] # Re: EPUB ou rien
Posté par Bruno Michel (site web personnel) . En réponse au journal livre numérique des éditions eni. Évalué à 6.
Précisions pour Tanguy Ortolo : Readium utilise Mathjax, donc on peut aussi le faire avec du HTML ;-)
[^] # Re: EPUB ou rien
Posté par Bruno Michel (site web personnel) . En réponse au journal livre numérique des éditions eni. Évalué à 7.
EPUB 3 prend en charge ce problème grâce à MathML. Tu peux, par exemple, tester ça avec Readium en allant sur le premier livre (A First Course in Linear Algebra).
[^] # Re: EPUB ou rien
Posté par Bruno Michel (site web personnel) . En réponse au journal livre numérique des éditions eni. Évalué à 10.
Tu peux détailler pourquoi html serait insuffisant pour les meta-données ? Pour autant que je sache, les meta-données utilisées en epub sont les mêmes qu'en html (Dublin Core,
<meta>et<link>).Certes un sommaire doit pouvoir être lisible par une machine, mais html fournit déjà des titres (
<h1>à<h6>) qui devrait permettre à une liseuse d'afficher un sommaire. Ce sommaire est construit automatiquement et n'est pas décrit dans un document à part. Ça donne moins de souplesse aux créateurs d'ebooks pour choisir ce qui va dans le sommaire mais me semble suffisant dans beaucoup de cas.Pour moi, EPUB, c'est un fichier zip qui contient plusieurs fichiers HTML et des ressources pour les accompagner (images, CSS, etc.). Après on rajoute dans le zip un fichier d'index parce que ce serait compliqué de faire sans. Il liste les fichiers présents dans le zip (
<manifest>, je ne sais pas à quoi il sert), dit dans quel ordre il faut afficher les fichiers HTML (<spine>, ce que tu sembles appeler le sommaire même s'il n'y a aucun titre dedans, juste une suite de référence de fichiers) et enfin des méta-infos (<metadata>, que l'on a mis dans ce fichier juste pour ne pas avoir à deviner dans quel(s) fichier(s) elles sont).Pour des ebooks simples, je ne vois rien qui empêcheraient de faire ça en HTML :
<h1>à<h6>) ;<section>qui me paraît bien convenir pour ça ;Après, ce n'est pas parce que l'on peut que c'est souhaitable. Pour les ebooks simples (des romans par exemple), html convient bien à mon avis. Pour les trucs plus poussés, EPUB a des avantages.
Maintenant, je ne prétends pas être un expert en EPUB, donc si je me trompe, n'hésite pas à me corriger.
# Faut arrêter de voir de la censure partout...
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Justifier les censures. Évalué à 6 (+0/-0). Dernière modification le 29 juillet 2012 à 23:49.
Le premier commentaire de ce journal n'a pas été censuré, il a juste été supprimé
à la demande de l'auteursuite à une maladresse d'un des modérateurs.Nous en avons déjà discuté et cela ne changera pas. L'équipe de modération agit de manière construite et solidaire. La suppression d'un commentaire n'est pas le résultat d'une action personnelle mais l'application de la charte de modération. En particulier, les cas litigieux sont discutés par l'équipe et donc peu importe qui appuie sur le bouton au final.
[^] # Re: surtout s'il n'y a pas de titre dans ledit commentaire !
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi "Sommaire" dans les commentaires longs. Évalué à 3 (+0/-0).
Depuis avant-hier (cf https://github.com/nono/linuxfr.org/commit/f6daaf913bf8607924239f51bc63331757258cf9), les sommaires pour des contenus sans titre ne sont plus insérés.
Maintenant, savoir si un commentaire long avec des titres mériterait d'avoir un sommaire ou non est une autre question.
[^] # Re: Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Commentaire qui passe pas. Évalué à 4 (+0/-0).
C'est fait.
# Sûr de vouloir faire du C++ ?
Posté par Bruno Michel (site web personnel) . En réponse au message Choix d'un moteur réseau/event. Évalué à 2.
Tu es sûr de vouloir faire du C++ ? Dans le cas contraire, je te conseillerais d'aller jeter un coup d'oeil à Go.
À mon avis, il conviendrait bien pour ça. Par exemple, tu parlais de 200 000 clients et Go peut très bien gérer 200 000 goroutines (une sorte de thread en plus léger). Le passage de messages entre ces goroutines se fait avec des chans (ça vient de base avec le langage).
Maintenant, si tu préfères rester sur du C++, ce que je peux comprendre, je n'ai pas grand chose à te conseiller ;-)