--- Begin Message ---
|
Subject: |
Re: [Bdtheme-dev] Re: |
|
Date: |
Sun, 18 Nov 2001 11:34:28 +0100 |
L> > Si celle dans html ne le sont pas, comment devriont nous operez le
> distinguo sources (src) / interface (htdocs) ?
on peut toujours, ainsi que tu l'as suggéré dans un précédent mail,
placer dans htdocs des résultats plausibles de la génération de pages
d'interface, afin que les visiteurs puissent voir quelque chose sans
devoir nécessairement installer le logiciel
l'idée c'est de n'avoir pas de dossier htdocs dans le CVS mais que ce
dossier soit généré en lançant une simple commande -> et c'est ce
dossier htdocs que nous mettrons sur le CVS du web (et non des sources)
> A ce que j'ai compris, les utilisateurs arrivent pas accueil.html
etc
> .. Alors ?
>
> Les pages dans HTML sont celles avec l'utilisateur interagit non ?
> Ces pages, comment sont-elles générées ? Ecrites à la main ?
> Ne devrait-on pas centraliser certaines infos qui servent pour
toutes
> les pages (format HTML et consort ?).
> Généralement je fais sur mes sites ce genre d'opération avec du
script
> shell. Apparement tu fais ça avec python, ce qui est dans tpl.
le code python ne doit contenir aucun code d'interface, c'est pourquoi
tout est dans les .tpl
on peut mettre de côté un "header.tpl" et un "footer.tpl" si on veut.
Par expérience je fais plutôt un "main.tpl", qui contient tout ce
qu'il
faut pour l'entête et le pied de la page, et inclut d'autres .tpl à
l'aide d'une variable {CONTENU}
Les fichiers dans HTML sont-ils générés avec ces tpl ? Ce devrait
logiquement être le cas.
Donc en fait, il faudrait que je travaille sur ces fichiers tpl.
Cela dit, je ne vois aucun « main » dans tpl, c'est « bdtheme.tpl » ?
Je remarque que certains tpl commençent par des bornes html /html ,
donc n'utilisent pas bdtheme.tpl.
Du fait que ce sont des frames ? En utilisant CSS2 à fond, on pourrait
en faire résoudre ce problème en ne mettant aucunes tables sur la page
de base.
le makefile servira à l'intallation
mais au bout du compte il y aura encore les .tpl
Oui, j'aimerais juste savoir si le contenu de html est une génération à
partir de tpl.
Si c'est le cas, nous ne devrions pas mettre ceci sur le CVS mais
mettre ceci sur le CVS du web, à titre de démonstration.
Si ce n'est pas le cas, est-ce pertinent que ça ne soit justement pas
le cas ?
les fichiers xml sont générés aussi, non ? (à ce que j'ai cru
comprendre en lisant les docs et regardant les scripts.py). Nous
devrions peut-être les mettre dans htdocs donc.
donc nous aurions src/tpl src/cgi src/img src/css src/js
et lors d'une installation, htdocs/*.html et htdocs/xml serait produit
> Comment fais-tu les traductions ? Peut-être aurait-il été très
> interessant d'avoir les traductions géré avec gettext (outil
standard
> bien pratique !)
mon expérience me dit qu'on s'en sort très bien en traduisant les .tpl
Le site de TINY a été traduit de cette manière. En combien de langues,
déjà ?
gettext sera surtout utile s'il faut aller à la pêche aux chaînhes à
traduire, dans le code lui-même.
Tu n'as pas tort.
Pour ce qui de l'internationalisation, nous ne devrions pas mettre ceci
dans le dossier cgi, car même si les cgi l'utilise et s, ce sont des
données qui devrait être bien matérialisée.
je propose src/i18n ou src/lang ou src/locale
Apparement, ton script locale.py fait la traduction en anglais. Ne
pourrait-on pas avoir un seul script locale.py qui lirait les infos,
soit dans src/locale/fr.py soit dans src/locale/en.py ?
C'est un peu bizarre parce que d'un coté c'est une forme de cgi,
puisque ça s'execute, mais finalement ce n'est que des valeurs qui sont
données...
C'est une question secondaire mais je pense que c'est à envisager (du
coup rapidement, histoire qu'on puisse élaborer l'arbre).
Tu n'as encore rien proposé pour le français ?
Comme se passe cette traduction ? Les fichiers sont nativement en
français et sont traduit si besoin est avec src/locale/en.py ?
Ne devrait-on pas nativement mettre en anglais, considérant que pour
des participations de non francophone, ça reste l'idéal ?
oui je sais
j'ai honte d'avoir du mal à me déshabituer : netscape a accompagné mes
premiers pas sous Linux, ça fait déjà un bon paquet d'années, et je
suis
vieille...
J'aime bien Galeon, mais j'ai du mal à trouver une alternative
raisonnable qui puisse correspondre à mes habitudes
Vu l'instabilité et la qualité d'affichage de netscape, j'ai
personnellement été ravi quand d'autres navigateurs sont apparu.
Galeon gere les mots de passe, permet une gestion appronfondie des
images (ne pas chercher sur telle serveur), à un gestionnaire de
cookies, permet de couper les pop-up, à une gestion d'onglets, utilise
gecko qui sait gerer correctement CSS2 et HTML4, connait la complétion
automatique des urls, à un système d'historique élaboré, utilise gtk+
(quand même plus joli que motif !), la barre d'outils est réellement
configurable, il y'a une barre personnelle dans laquelle on peut
directement lancer des recherches sur google ou dans un dictionnaire...
bref, la liste de motivations est longue..
A+
--- End Message ---