vincent Personnellement, je pense que ça ne devrait pas être le cas. Selon moi, cela doit découler d’une action de la part du membre pour apparaître dans cette liste. Ce n’est selon moi pas grave si la page membre ne reflète pas la réalité en terme de nombre de personnes.
Ok pour ça.
vincent Pour autant, je pense que d’avoir le fichier déjà créé est intéressant, tout comme les autres dossiers, pour faciliter le on-boarding. Dans ce cas là je propose qu’il soit créé vide.
Oui notamment pour les histoires de véritable fichier plain text et d’encodage par défaut, c’est vrai que ça peut être pas mal si il est déjà présent.
vincent Je propose de modifier le script pour que ça ne le fasse plus, avant de mettre à jour le Skeleton.
Ça pourrait être une solution. Faut voir aussi ce que ça signifie vide. Par exemple touch créé un fichier véritablement vide, mais sans aucune information d’encodage ou de format de fichier. Donc seule l’extension pourra apporter des infos à l’éditeur de texte.
J’ai testé cette méthode pour créer un fichier UTF-8 avec BOM . Ça fonctionne correctement (en tout cas avec les éditeurs que j’ai à disposition), mais Wikipedia donne un avertissement :
Lorsqu’il est correctement interprété, [le BOM] n’est pas vu par l’utilisateur final du texte codé. Il existe cependant deux cas où ce caractère peut être mal interprété
Demo
$ touch test_touch
$ cat test_touch
$ file test_touch
test_touch: empty
$ file -bi test_touch
inode/x-empty; charset=binary$ printf '\xEF\xBB\xBF' > test_bom
$ cat test_bom
$ file test_bom
test_bom: Unicode text, UTF-8 text, with no line terminators
$ file -bi test_bom
text/plain; charset=utf-8En théorie le deuxième fichier est meilleur pour l’utilisateur, puisque l’éditeur devra lui-même être capable de détecter que le fichier est en UTF-8 bien qu’il soit virtuellement vide. Mais il faut checker que :
PHP le supporte correctement