1

(15 replies, posted in Bistrot)

Bonsoir,

Je m'excuse de n'avoir pu venir à ma première AG, incompatible avec mon emploi du temps. J'espère néanmoins que ça n'était pas la dernière...
Quoi qu'il advienne, je comprendrai votre décision. Il n'y a pas de raison que ce soit toujours les mêmes qui donnent de leur temps, et si malgré les appels répétés personne n'a assez de temps à consacrer, c'est malheureux mais ça ne peut pas continuer éternellement.
Sauf peut-être à revoir le fonctionnement de l'asso, avec des "compensations financières" pour motiver les troupes... quitte à s'éloigner un peu de l'esprit TuxFamily ?
Comme beaucoup j'aimerais vous aider, mais en dehors d'un soutien financier, le temps ça ne s'invente pas :(

2

(2 replies, posted in Naissances)

Bonjour (ou bonne nuit),

J'ai le plaisir de vous annoncer la publication de la première version stable de ce wiki multilingue : Anwiki 0.2.0.
Une version de consolidation donc, mais également de nouvelles ressources :
- Une documentation en ligne
- Des composants additionnels pour :
* faire du Single Sign-On avec phpBB3 et Flyspray
* importer des fichiers de traduction (PHP ou PO), les synchroniser, puis les réexporter une fois qu'ils ont été traduits
* faire des documentations multilingues structurées, avec une table des matières dynamique

Sinon, on recherche toujours des traducteurs et/ou relecteurs :)

Super, c'est reparti comme en 40 :)

Bonjour TuxFamily, et merci pour tes services.

Petite question : Comment se fait-il que sur mon download-repository, je ne vois pas la même chose en FTP/SSH qu'en HTTP ?
Par exemple, en FTP/SSH, le répertoire /home/anwiki/anwiki-repository/webstatic/shared/_addons-static/contentclasses est vide.
Côté web, il contient un sous-dossier : http://download.tuxfamily.org/anwiki/we … ntclasses/

De plus, j'ai beau supprimer le dossier "contentclasses" ou lui rajouter des fichiers, rien ne change en HTTP :(
Et si je tente de copier le dossier  /home/anwiki/anwiki-repository/webstatic/shared/_addons-static/ vers un autre dossier du repository, le nouveau dossier n'est pas complet côté HTTP.

Est-ce que je fais quelque chose de travers ? Merci !

Ok, merci pour ces précisions :)

Bonjour,

J'ai deux petites questions concernant l'utilisation d'un espace de téléchargement.
Je pensais utiliser mon repository pour y placer des fichiers statiques du site web (images, JS, PNG), comme suggéré par la FAQ, mais je ne suis pas sûr d'avoir compris certains points :

Pour vos avatars de forum, ou les fichiers joints ou les uploads pour votre wiki, il est recommandé d'utiliser un download repository (ce sont des fichiers statiques, consommateurs d'espace disque).
Voir les recommandations par application pour savoir comment procéder pour chacun, en bref :
  * utiliser /data/repository/[votre_nom_de_groupe]/statique/
  * et faire en sorte que le lien fourni par votre application pointe sur http://download.tuxfamily.org/[votre_nom_de_groupe]/statique/

Le choix de créer un dossier "statique" (ou "static" dans la traduction anglaise) a t-il son importance, ou est-ce par simple souci d'organisation ?

D'autre part, je m'interroge sur le paragraphe suivant :

Vous pouvez accéder aux espaces de téléchargements à partir des serveurs web dans le répertoire /data/repository, par exemple /data/repository/vhffs4 pour le groupe vhffs4

Attention, vous ne devez pas faire des accès fréquent vers ce répertoire, il doit seulement être utilisé pour envoyer des fichiers du service web vers l'espace de téléchargement, vous ne devez pas lire des fichiers sur ces espaces et encore moins lister le contenu des répertoires. En gros gardez un index des fichiers uploadés de votre coté et fournissez des URLs du type http://download.tuxfamily.org/.../ à vos visiteurs.

Qu'est-il entendu par "vous ne devez pas lister le contenu des répertoires" ? Lister de manière dynamique via un script (ce qui me parait improbable vu que le serveur n'est pas destiné à héberger de contenus dynamique), ou est-il interdit de faire le moindre "ls" sur ce répertoire depuis un shell ?

Merci d'avance :)

Bonjour à tous,

J'ai le plaisir de vous annoncer la naissance d'Anwiki. C'est un garçon, 3.7kg, il se porte bien ;-)
Plus sérieusement, c'est l'aboutissement d'un travail commencé il y a un an pour créer un système de wiki/CMS réellement efficace pour la gestion de contenus multilingues.
Encore un CMS de plus, me direz-vous ! Oui, un de plus, mais il apporte de vraies innovations : il a été entièrement pensé pour gérer du contenu multilingue, dès sa conception.

En démo ici : http://demo.anwiki.com

C'est en effet un véritable cauchemard de maintenir plusieurs langues à jour, lorsque le contenu évolue souvent. Sur le long terme, à moins d'une extrème rigueur, les traductions ne se ressemblent plus ou sont obsolètes.
Pour pâlier à ce problème, Anwiki utilise un algorithme spécial qui permet de mettre automatiquement à jour l'ensemble des traductions, dès qu'un contenu est modifié dans l'une des langues. Celles-ci restent synchronisées en permanence, du point de vue de la structure.
Si on ajoute un paragraphe dans l'une des langues, celui-ci sera ajouté dans les autres et marqué comme "non traduit". Si on inverse deux titres, l'inversion sera effectuée dans les autres langues, sans perdre ce qui a déjà été traduit !

Ensuite, Anwiki dispose d'une interface interactive très sympa pour traduire du contenu "à la volée".
Mieux encore, le système peut gérer tout type de contenus fortement structurés, définis à l'avance. Un traducteur peut ainsi traduire indifféremment du contenu xhtml classique, mais aussi des menus de navigation structurés, des fichiers de traductions d'applis externes importés dans le système, des news... ou tout autre contenu dont vous aurez défini le gabarit.

Ajoutons que l'architecture du système, bien que non documentée pour le moment, permet d'écrire différents types de composants qui viennent se greffer sur Anwiki. On peut ainsi se faire ses propres modules d'import, ses drivers de connexion à des bases utilisateurs/sessions/acls/stockage persos, ses plugins et ses classes de contenus facilement échangeables et sans galère lors des mises à jour. Plus d'excuses pour ne pas contribuer! ^_^

Lors d'un passage en coup de vent à un stand Tuxfamily il y a quelques mois, vous m'aviez fait part de la difficulté de maintenir à jour votre FAQ disponible dans pas mal de langues...
Anwiki est peut-être encore un peu jeune et ne dispose d'aucun script d'import, mais ça pourrait être une solution pour le futur.

Un grand merci à Tuxfamily pour ses services qui vont nous être très utiles : web, SVN, mail, mailing-list, download repository... tout fonctionne à merveille :-)

8

(5 replies, posted in Suggestions)

Je ne sais pas exactement comment ça se configure, mais si ça marche c'est une fonctionnalité qui m'intéresserait également :)
Y a t-il un quelconque inconvénient à configurer par défaut (tous?) les dépots SVN pour reconnaitre $LastChangedDate$ et $Id$ ?

Je suis tout à fait d'accord, attendons qu'une solution plus propre soit dispo :)

Merci pour ces explications, j'ignorais que la lib openssl souffrait de cette limitation et je ne connaissais pas CAcert.

Si l'on ne peut faire tourner qu'un seul certificat par port/ip, il reste la possibilité de générer un certificat unique qui serait valide:
1) soit pour l'ensemble des domaine hébergés qui en feraient la demande (je ne sais pas s'il y a une limite par certificat)
2) soit pour l'ensemble des sous-domaines (*.tuxfamily.org)

Pour la première solution, ce serait top, mais j'imagine que c'est difficilement réalisable (nécessité de recréer le certificat régulièrement), quoique ça peut s'automatiser.
La deuxième solution me paraît réalisable, mais elle ne concernerait que ceux qui ont un sous-domaine TF.

Salut à tous !

Je viens de constater que le HTTPS est activé sur les domaines hébergés par TuxFamily, cool :)
Par contre, le certificat semble avoir expiré le 13 juillet 2007, ce qui provoque un warning des navigateurs.

Autrement, je me demandais s'il était possible ou envisagé de permettre aux hébergés d'utiliser leurs propres certificats SSL ? ça éviterait l'alerte qui indique que le certificat provient du domaine web.tuxfamily.org. On en trouve maintenant à des prix abordables.

Ce n'est absolument pas une demande, perso je peux m'en passer, c'est juste une suggestion ;)
A bientôt et merci pour votre super boulot