NewsLinuxFr >
LinuxFr en Ruby on Rails, ça peut marcher !
Comme beaucoup d'entre-vous le savent, depuis 2009, NoNo< a initié la réécriture de
LinuxFr en
RoR?, non sans y avoir mûrement réfléchi. Le résultat en version alpha est déjà disponible sur
http://alpha.linuxfr.org sous licence libre AGPL et fait l'objet d'un concours pour améliorer son apparence ou le tester efficacement voire envoyer des patchs, une
de tous ceux souhaitant s'inscrire et la possibilité de
. Il y a trois volets en fonction de l'implication de chacun :
- l'apparence de http://alpha.linuxfr.org avec une , celle pour avec quelques améliorations suggérées
- les fonctionnalités de base sont disponibles, celles qui vous manquent doivent^Wpeuvent être indiquées, n'hésitez pas à tester et suivre les suggestions de coordination des tests (si c'est sur github, c'est pris en compte, sur le tracker de linuxfr aussi comme la rubrique "nouvelle version RoR" le suggère)
- la en respectant la mise en forme (choix de Markdown en destination)
- quelques sont identifiées (barré et souligné), il manque peut-être de réels besoins ? Un changement de syntaxe (pour creole ?) demanderait d'abord des points bloquants identifiés, cf. ci-dessous pour la migration
- n'hésitez pas à identifier les dépêches ne respectant pas les standards du W3C
- vérifiez tous les contenus (forum, dépêche, journal) en donnant les URL pour reproduire l'anomalie identifiée, certaines particularités de LinuxFr devant être prises en compte, cf. suggestions d'un relecteur de LinuxFr
S'inscrire sur la
, vous permettra de toucher tous ceux intéressés par les évolutions et développements à venir autour de
LinuxFr, dans la durée (y participer ou simplement se tenir informé sur le long terme et suivre l'activité concrète ponctuellemen).
Ce serait ne pas parler de certaines moules< qui auront remarqué les "régressions" de la
tribune "libre" notamment le manque de prise en compte des nhorloges et des [:totoz], malgré la réactivité de
NoNo< à rendre le backend xml disponible, il y avait une certaine attente de réactivité induite des moules à proposer leur solution pour cette espace de liberté et d'innovation de
LinuxFr, qui ne saurait tarder (pour info les modérateurs aussi se plaignent du manque de gestion des nhorloges :D). À ne pas en douter les coincoin s'adapteront rapidement (pan ! pan !).
- proposer une tribune toute faite reprenant toutes les fonctionnalités existantes (nhorloges, [:totoz], affichage joli des threads de discussion...) est possible
- compatibilité assurée avec les coincoin< existants ou évolution de ces coincoin, au choix, peut être préconisé ;-)
- tous les tests sont les bienviendus en tout cas voire les suggestions d'ajouts de fonctionnalités
Beaucoup d'entre vous auront lu entre les lignes : "Le site
LinuxFr.org vit avec les dépêches que vous rédigez ou que vous contribuez à rédiger" et avec ceux prêts à lui
apporter des fonctionnalités (oui cet entête n'est pas suffisamment visible, aisément oublié, il y a un bug ouvert dessus, répondu partiellement, qui revient de temps en temps).
Choix de la syntaxe
Comme déjà indiqué, le Markdown a pour l'instant été retenu pour
LinuxFr en
RoR?. Le tout est d'identifier ce qui répond au besoin et quelques limites identifiées :
- par rapport à la migration des données existantes :
- liste des erreurs à migration ?
- envisager de corriger quelques données avant migration ?
- par exemple les liens comme (http://linuxfr.org) entre parenthèses qui ne passent pas bien dans templeet ?
- autres exemples ? Cela demande à être bien spécifié pour ne pas ajouter de régressions
- non respect des standards du w3c ? (capacité à tester l'ensemble des dépêches ? définir quelle norme doit être respectée, HTML5 a priori)
- perte de fonctionnalité : le barré (n'existe plus en HTML5 ?)
- par rapport aux balises disponibles : p,b,i,s,u,em,tt,strong,ol,ul,li,pre,code,q,blockquote,acronym (ainsi qu'en modération a et autre ?)
- ok : b, em, tt, ol, ul (et li), code, blockquote
- ko : p ? i (em) ? strong (b) ? pre (code) ? q (?) ? u (?) ? s (?) ?
- par rapport aux liens aussi il y a quelques limites bien connues
- wikiliens au fonctionnement erratique : entre les espaces, les _, les accents, les parenthèses
- le souci avec les crochets [ ] disparaît en markdown (utilisation des parenthèses), mais en fait apparaître un nouveau (avec les parenthèses ( ) justement, vu que l'imbrication n'est pas vraiment gérée), peut-être envisager une double syntaxe ?
Tests des utilisateurs
