Je viens de lire le fil « un contenu par URL » importé par Guillaume
Bouchard depuis un autre groupe. Tout d'abord, je dois dire que je suis
beaucoup plus en phase sur le sujet avec le point de vue de Patrick
Mevzek qu'avec celui de Guillaume, mais mon objectif avec ce nouveau fil
n'est pas d'intervenir dans cet échange. J'ai un problème très précis à
résoudre, pour lequel j'ai déjà fait certains choix, mais où tout n'est
pas encore parfaitement clair.
--------------
| Existant |
--------------
Il s'agit d'un ensemble de pages web, certaines statiques, d'autres
dynamiques (programmes écrits en C). Pour simplifier, je vais me
restreindre aux pages statiques. L'arborescence globale est assez
complexe, mais là encore je vais simplifier en supposant que toutes les
pages sont directement accessibles à la racine.
Chacune des pages existe en deux langues, anglais et français. Mettons
pour fixer les idées :
index.html.en, index.html.fr,
page1.html.en, page1.html.fr,
page2.html.en, page2.html.fr,
page3.html.en, page3.html.fr,
page4.html.en, page4.html.fr,
page5.html.en, page5.html.fr.
Il y en a beaucoup plus en réalité.
Grâce à la négociation de contenu, quelqu'un qui chercherait à accéder à
page1.html ou à page1 se retrouverait automatiquement redirigé vers
page1.html.en ou vers page1.html.fr, selon les préférences de son
navigateur. Mettons qu'il tombe sur page1.html.fr, il trouve sur cette
page un lien « version anglaise » vers page1.html.en, ainsi que des
liens vers index.html.fr, page2.html.fr, etc. Il peut donc soit aller
sur la page équivalente en changeant de langue, soit aller vers les
autres pages sans changer de langue.
Nous allons confier la traduction des pages dans différentes langues,
mais comme il y a beaucoup de pages on ne va pas tout traduire d'un
coup. Par ailleurs, il se trouve que les Allemands n'ont pas les mêmes
priorités que les Japonais, ce qui va donc donner :
-----------------
| Le problème |
-----------------
La question qui se pose est « que mettre dans les liens ».
Par exemple, si dans page1.html.de je mets tous les liens en
xxx.html.de, cela marchera pour page2.html.de, mais pas pour page4.html.de.
Inversement, si je mets tous les liens en xxx ou xxx.html, alors la
négociation de contenu se refera à chaque coup, et l'utilisateur risque
de se retrouver à chaque clic avec une page en anglais s'il n'a pas su
configurer son navigateur.
Si, enfin, je fais au cas par cas (avec extension si la page existe,
sans si elle n'existe pas), d'une part ce n'est pas très satisfaisant
pour l'esprit, d'autre part cela m'obligera à passer en revue toutes les
pages à chaque nouvelle traduction.
--------------------------
| Pour aller plus loin |
--------------------------
En fait, je me demande s'il ne serait pas possible d'avoir les deux
fonctionnements simultanément. Je m'explique.
L'utilisateur germanophone demande page2.html, ce qui va lui fournir la
version allemande de page2. Le lien vers page4 est intitulé page4.html,
ce qui lui fournit la version anglaise, et de là le lien vers page3
s'appelle page3.html, qui est livré en allemand.
Si d'ici il veut changer de langue, mettons pour le japonais, il aura
page3.html.ja, à partir duquel il peut accéder à index.html.ja de même
qu'à page4.html.ja : il est donc d'une certaine manière « verrouillé »
sur le japonais.
---------
| ??? |
---------
Comment feriez-vous, dans chacun des deux cas précédents, parties
intitulées « le problème » et « pour aller plus loin » ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Miakinen
Bonjour, et toutes mes excuses pour répondre aussi tard. J'ai voulu prendre le temps de relire attentivement la doc dont tu as donné le lien avant de le faire.
Le 16/05/2005 23:27, Patrick Mevzek m'a répondu :
La question qui se pose est « que mettre dans les liens ».
Par exemple, si dans page1.html.de je mets tous les liens en xxx.html.de, cela marchera pour page2.html.de, mais pas pour page4.html.de.
Récupérer les erreurs 404 (dûs à ce genre de liens invalides donc), et proposer une page en allemand qui dit juste: le document que vous cherchez n'est pas encore disponible en allemand, mais il est disponible en: suivi d'une liste des pages existantes avec les langues.
Eh oui, c'est une excellente idée, et si facile à faire en PHP... malheureusement pour le moment je n'ai pas accès à PHP, mais je vais probablement me compiler un CGI en C pour le faire.
Ca permet de déployer progressivement, il n'y a qu'une traduction à faire (c'est une page générique), et cela permet aux utilisateurs 1) de comprendre ce qui se passe 2) d'éventuellement choisir un second choix parmi les langues offertes
Un test rapide m'a montré que si j'essaye d'accéder à pageN qui n'existe dans aucune des langues configurées dans mon navigateur, alors il me propose toutes celles qui existent. En revanche, si je demande pageN.fr et qu'elle n'existe pas, alors c'est 404.
-------------------------- | Pour aller plus loin | --------------------------
J'ai moins compris le problème dans cette version, qui me parait idéale, donc je passe pour les commentaires.
Oui, la version me paraît idéale aussi, mais en rédigeant mon article je ne savais pas l'implémenter. D'ailleurs c'était une question plutôt pour fciw.serveurs que pour fciw.auteurs. Finalement, une possibilité serait d'avoir à la fois des pageN.html.fr et des pageN.fr.html, l'une des deux ayant des liens en pageM sans extension, et l'autre des liens avec extension complète.
BTW, je privilégie index.fr.html plutôt que index.html.fr comme nommage, car cela permet bien plus de choix dans les liens.
C'est ce que j'ai fait au début, mais j'en suis revenu. Je ne sais plus si c'était parce qu'il y avait une référence à index.html quelque part (auquel cas la page index.fr.html ne peut pas être trouvée) ou bien si c'était à cause d'un problème sous IIS (oui, parce que pour le moment j'essaye toujours que cela marche aussi avec IIS pour Windows).
Cf le § ``Note on hyperlinks and naming conventions'' de http://httpd.apache.org/docs/content-negotiation.html
Un grand merci pour cette doc. Je l'avais lue il y a quelques années, lorsque je n'en avais pas besoin et que c'était par simple curiosité, mais je l'avais oubliée depuis. Pourtant c'est un « must-read » comme le dit Pierre.
-- Olivier
Bonjour, et toutes mes excuses pour répondre aussi tard. J'ai voulu
prendre le temps de relire attentivement la doc dont tu as donné le lien
avant de le faire.
Le 16/05/2005 23:27, Patrick Mevzek m'a répondu :
La question qui se pose est « que mettre dans les liens ».
Par exemple, si dans page1.html.de je mets tous les liens en
xxx.html.de, cela marchera pour page2.html.de, mais pas pour
page4.html.de.
Récupérer les erreurs 404 (dûs à ce genre de liens invalides donc), et
proposer une page en allemand qui dit juste:
le document que vous cherchez n'est pas encore disponible en allemand,
mais il est disponible en:
suivi d'une liste des pages existantes avec les langues.
Eh oui, c'est une excellente idée, et si facile à faire en PHP...
malheureusement pour le moment je n'ai pas accès à PHP, mais je vais
probablement me compiler un CGI en C pour le faire.
Ca permet de déployer progressivement, il n'y a qu'une traduction à faire
(c'est une page générique), et cela permet aux utilisateurs
1) de comprendre ce qui se passe
2) d'éventuellement choisir un second choix parmi les langues offertes
Un test rapide m'a montré que si j'essaye d'accéder à pageN qui n'existe
dans aucune des langues configurées dans mon navigateur, alors il me
propose toutes celles qui existent. En revanche, si je demande pageN.fr
et qu'elle n'existe pas, alors c'est 404.
--------------------------
| Pour aller plus loin |
--------------------------
J'ai moins compris le problème dans cette version, qui me parait idéale,
donc je passe pour les commentaires.
Oui, la version me paraît idéale aussi, mais en rédigeant mon article je
ne savais pas l'implémenter. D'ailleurs c'était une question plutôt pour
fciw.serveurs que pour fciw.auteurs. Finalement, une possibilité serait
d'avoir à la fois des pageN.html.fr et des pageN.fr.html, l'une des deux
ayant des liens en pageM sans extension, et l'autre des liens avec
extension complète.
BTW, je privilégie index.fr.html plutôt que index.html.fr comme nommage,
car cela permet bien plus de choix dans les liens.
C'est ce que j'ai fait au début, mais j'en suis revenu. Je ne sais plus
si c'était parce qu'il y avait une référence à index.html quelque part
(auquel cas la page index.fr.html ne peut pas être trouvée) ou bien si
c'était à cause d'un problème sous IIS (oui, parce que pour le moment
j'essaye toujours que cela marche aussi avec IIS pour Windows).
Cf le § ``Note on hyperlinks and naming conventions''
de http://httpd.apache.org/docs/content-negotiation.html
Un grand merci pour cette doc. Je l'avais lue il y a quelques années,
lorsque je n'en avais pas besoin et que c'était par simple curiosité,
mais je l'avais oubliée depuis. Pourtant c'est un « must-read » comme le
dit Pierre.
Bonjour, et toutes mes excuses pour répondre aussi tard. J'ai voulu prendre le temps de relire attentivement la doc dont tu as donné le lien avant de le faire.
Le 16/05/2005 23:27, Patrick Mevzek m'a répondu :
La question qui se pose est « que mettre dans les liens ».
Par exemple, si dans page1.html.de je mets tous les liens en xxx.html.de, cela marchera pour page2.html.de, mais pas pour page4.html.de.
Récupérer les erreurs 404 (dûs à ce genre de liens invalides donc), et proposer une page en allemand qui dit juste: le document que vous cherchez n'est pas encore disponible en allemand, mais il est disponible en: suivi d'une liste des pages existantes avec les langues.
Eh oui, c'est une excellente idée, et si facile à faire en PHP... malheureusement pour le moment je n'ai pas accès à PHP, mais je vais probablement me compiler un CGI en C pour le faire.
Ca permet de déployer progressivement, il n'y a qu'une traduction à faire (c'est une page générique), et cela permet aux utilisateurs 1) de comprendre ce qui se passe 2) d'éventuellement choisir un second choix parmi les langues offertes
Un test rapide m'a montré que si j'essaye d'accéder à pageN qui n'existe dans aucune des langues configurées dans mon navigateur, alors il me propose toutes celles qui existent. En revanche, si je demande pageN.fr et qu'elle n'existe pas, alors c'est 404.
-------------------------- | Pour aller plus loin | --------------------------
J'ai moins compris le problème dans cette version, qui me parait idéale, donc je passe pour les commentaires.
Oui, la version me paraît idéale aussi, mais en rédigeant mon article je ne savais pas l'implémenter. D'ailleurs c'était une question plutôt pour fciw.serveurs que pour fciw.auteurs. Finalement, une possibilité serait d'avoir à la fois des pageN.html.fr et des pageN.fr.html, l'une des deux ayant des liens en pageM sans extension, et l'autre des liens avec extension complète.
BTW, je privilégie index.fr.html plutôt que index.html.fr comme nommage, car cela permet bien plus de choix dans les liens.
C'est ce que j'ai fait au début, mais j'en suis revenu. Je ne sais plus si c'était parce qu'il y avait une référence à index.html quelque part (auquel cas la page index.fr.html ne peut pas être trouvée) ou bien si c'était à cause d'un problème sous IIS (oui, parce que pour le moment j'essaye toujours que cela marche aussi avec IIS pour Windows).
Cf le § ``Note on hyperlinks and naming conventions'' de http://httpd.apache.org/docs/content-negotiation.html
Un grand merci pour cette doc. Je l'avais lue il y a quelques années, lorsque je n'en avais pas besoin et que c'était par simple curiosité, mais je l'avais oubliée depuis. Pourtant c'est un « must-read » comme le dit Pierre.
-- Olivier
Olivier Miakinen
Le 17/05/2005 10:23, Pierre Goiffon a écrit :
Mhhh Pourquoi ne pas adopter un système de template avec cache, qui permettrait de réellement séparer structure, forme et contenu, tout en ne pénalisant pas trop les performances du serveur ? Et puis, penser à renvoyer les bons en-têtes de cache...
Je ne suis pas sûr de comprendre l'histoire du cache. Mais quoi qu'il en soit, le seul moyen dont je dispose actuellement pour faire des pages dynamiques, c'est un programme en C. Alors si je peux faire du statique, je préfère... d'autant plus que chaque programme CGI doit être dupliqué dans toutes les versions d'OS (au moins Sun, AIX et Windows).
En tant qu'utilisateur personnellement, je m'attendrais à avoir sur chaque page un lien vers toutes les langues disponibles pour ce contenu. Même si l'on arrive sur page4.de.html avec un message "cette page est en cours de traduction, désolé" (exprimé en allemand évidemment), on devrait avoir un lien vers les pages déjà traduites (en-en et fr-fr)
Oui. Au passage, je ne comprends pas bien « fr-fr » (quoique cela pourrait être fr-FR pour « français-FRANCE », puisque la casse n'est pas prise en compte) ni surtout « en-en » : je connais une langue dont le code est « en », mais aucun pays dont le code soit « EN ».
D'ailleurs je ne fais pas de distinction entre les pays (fr-FR, fr-BE, fr-CH, fr-BJ ou en-GB, en-US, en-AU).
J'apprécierai aussi que même si l'on choisit pour moi à ma 1ere visite, on conserve mon choix de langue au cours de ma session,
Oui, bien sûr. C'est ce que je fais avec les liens « à extension » plutôt que les liens « nus ».
et me laisser aussi la possibilité de l'enregistrer pour les prochaines visites.
Ça, c'est possible en sauvant dans ses signets l'un des liens à extension. En revanche je ne le ferai pas par cookie.
En tant que concepteur, j'irai au plus simple, en prenant *extremmement* garde aux problématiques d'historiques et de cycle de vies de chaque version : tu t'apercevera très vite que chaque version de langue a sa vie propre, que le processus de traduction puis de validation puis de mise en ligne est long, et qu'ainsi on a bien des sites différents de langue à langue.
En l'occurrence, les pages statiques servant principalement de navigation vers diverses applications (CGI, Java et/ou JavaScript), aucune page existante ne devrait être modifiée, sauf à corriger des fautes d'orthographe où à changer les liens pour rajouter d'autres pages. C'est très différent d'un vrai site web où les pages comprennent des textes informatifs. Ce n'est donc pas la même problématique. Mais merci de ta remarque qui pourra servir à d'autres que moi.
Cordialement, -- Olivier Miakinen
Le 17/05/2005 10:23, Pierre Goiffon a écrit :
Mhhh
Pourquoi ne pas adopter un système de template avec cache, qui
permettrait de réellement séparer structure, forme et contenu, tout en
ne pénalisant pas trop les performances du serveur ? Et puis, penser à
renvoyer les bons en-têtes de cache...
Je ne suis pas sûr de comprendre l'histoire du cache. Mais quoi qu'il en
soit, le seul moyen dont je dispose actuellement pour faire des pages
dynamiques, c'est un programme en C. Alors si je peux faire du statique,
je préfère... d'autant plus que chaque programme CGI doit être dupliqué
dans toutes les versions d'OS (au moins Sun, AIX et Windows).
En tant qu'utilisateur personnellement, je m'attendrais à avoir sur
chaque page un lien vers toutes les langues disponibles pour ce contenu.
Même si l'on arrive sur page4.de.html avec un message "cette page est en
cours de traduction, désolé" (exprimé en allemand évidemment), on
devrait avoir un lien vers les pages déjà traduites (en-en et fr-fr)
Oui. Au passage, je ne comprends pas bien « fr-fr » (quoique cela
pourrait être fr-FR pour « français-FRANCE », puisque la casse n'est pas
prise en compte) ni surtout « en-en » : je connais une langue dont le
code est « en », mais aucun pays dont le code soit « EN ».
D'ailleurs je ne fais pas de distinction entre les pays (fr-FR, fr-BE,
fr-CH, fr-BJ ou en-GB, en-US, en-AU).
J'apprécierai aussi que même si l'on choisit pour moi à ma 1ere visite,
on conserve mon choix de langue au cours de ma session,
Oui, bien sûr. C'est ce que je fais avec les liens « à extension »
plutôt que les liens « nus ».
et me laisser
aussi la possibilité de l'enregistrer pour les prochaines visites.
Ça, c'est possible en sauvant dans ses signets l'un des liens à
extension. En revanche je ne le ferai pas par cookie.
En tant que concepteur, j'irai au plus simple, en prenant *extremmement*
garde aux problématiques d'historiques et de cycle de vies de chaque
version : tu t'apercevera très vite que chaque version de langue a sa
vie propre, que le processus de traduction puis de validation puis de
mise en ligne est long, et qu'ainsi on a bien des sites différents de
langue à langue.
En l'occurrence, les pages statiques servant principalement de
navigation vers diverses applications (CGI, Java et/ou JavaScript),
aucune page existante ne devrait être modifiée, sauf à corriger des
fautes d'orthographe où à changer les liens pour rajouter d'autres
pages. C'est très différent d'un vrai site web où les pages comprennent
des textes informatifs. Ce n'est donc pas la même problématique. Mais
merci de ta remarque qui pourra servir à d'autres que moi.
Mhhh Pourquoi ne pas adopter un système de template avec cache, qui permettrait de réellement séparer structure, forme et contenu, tout en ne pénalisant pas trop les performances du serveur ? Et puis, penser à renvoyer les bons en-têtes de cache...
Je ne suis pas sûr de comprendre l'histoire du cache. Mais quoi qu'il en soit, le seul moyen dont je dispose actuellement pour faire des pages dynamiques, c'est un programme en C. Alors si je peux faire du statique, je préfère... d'autant plus que chaque programme CGI doit être dupliqué dans toutes les versions d'OS (au moins Sun, AIX et Windows).
En tant qu'utilisateur personnellement, je m'attendrais à avoir sur chaque page un lien vers toutes les langues disponibles pour ce contenu. Même si l'on arrive sur page4.de.html avec un message "cette page est en cours de traduction, désolé" (exprimé en allemand évidemment), on devrait avoir un lien vers les pages déjà traduites (en-en et fr-fr)
Oui. Au passage, je ne comprends pas bien « fr-fr » (quoique cela pourrait être fr-FR pour « français-FRANCE », puisque la casse n'est pas prise en compte) ni surtout « en-en » : je connais une langue dont le code est « en », mais aucun pays dont le code soit « EN ».
D'ailleurs je ne fais pas de distinction entre les pays (fr-FR, fr-BE, fr-CH, fr-BJ ou en-GB, en-US, en-AU).
J'apprécierai aussi que même si l'on choisit pour moi à ma 1ere visite, on conserve mon choix de langue au cours de ma session,
Oui, bien sûr. C'est ce que je fais avec les liens « à extension » plutôt que les liens « nus ».
et me laisser aussi la possibilité de l'enregistrer pour les prochaines visites.
Ça, c'est possible en sauvant dans ses signets l'un des liens à extension. En revanche je ne le ferai pas par cookie.
En tant que concepteur, j'irai au plus simple, en prenant *extremmement* garde aux problématiques d'historiques et de cycle de vies de chaque version : tu t'apercevera très vite que chaque version de langue a sa vie propre, que le processus de traduction puis de validation puis de mise en ligne est long, et qu'ainsi on a bien des sites différents de langue à langue.
En l'occurrence, les pages statiques servant principalement de navigation vers diverses applications (CGI, Java et/ou JavaScript), aucune page existante ne devrait être modifiée, sauf à corriger des fautes d'orthographe où à changer les liens pour rajouter d'autres pages. C'est très différent d'un vrai site web où les pages comprennent des textes informatifs. Ce n'est donc pas la même problématique. Mais merci de ta remarque qui pourra servir à d'autres que moi.
Cordialement, -- Olivier Miakinen
Patrick Mevzek
Le Thu, 19 May 2005 00:57:36 +0200, Olivier Miakinen a écrit :
Récupérer les erreurs 404 (dûs à ce genre de liens invalides donc), et proposer une page en allemand qui dit juste: le document que vous cherchez n'est pas encore disponible en allemand, mais il est disponible en: suivi d'une liste des pages existantes avec les langues.
Eh oui, c'est une excellente idée, et si facile à faire en PHP... malheureusement pour le moment je n'ai pas accès à PHP, mais je vais probablement me compiler un CGI en C pour le faire.
Y a même pas Perl de disponible ?
Ca permet de déployer progressivement, il n'y a qu'une traduction à faire (c'est une page générique), et cela permet aux utilisateurs 1) de comprendre ce qui se passe 2) d'éventuellement choisir un second choix parmi les langues offertes
Un test rapide m'a montré que si j'essaye d'accéder à pageN qui n'existe dans aucune des langues configurées dans mon navigateur, alors il me propose toutes celles qui existent.
Oui, avec un code 300 je suppose (multiple choices)
Donc la même solution que celle exposée plus haut pourrait être batie au-dessus de ce code, pour améliorer la page renvoyée au client.
En revanche, si je demande pageN.fr et qu'elle n'existe pas, alors c'est 404.
Oui, là, plus de négociation de contenu, en tout cas sur la partie langue.
Finalement, une possibilité serait d'avoir à la fois des pageN.html.fr et des pageN.fr.html, l'une des deux ayant des liens en pageM sans extension, et l'autre des liens avec extension complète.
Je ne sais pas comment Apache réagira. Et pour éviter la duplication physique, peut-être que le mécanisme avec fichier 'map' (au début du document must-read) est meilleur, mais je ne le connais vraiment pas, et cela doit être spécifique à Apache.
BTW, je privilégie index.fr.html plutôt que index.html.fr comme nommage, car cela permet bien plus de choix dans les liens.
C'est ce que j'ai fait au début, mais j'en suis revenu. Je ne sais plus si c'était parce qu'il y avait une référence à index.html quelque part (auquel cas la page index.fr.html ne peut pas être trouvée) ou bien si
Oui, cela aurait été un problème. Au pire une petite règle de ré-écriture pour supprimer les .html finaux avec un redirection ``interne'' pour repartir dans la négociation de contenu.
c'était à cause d'un problème sous IIS (oui, parce que pour le moment j'essaye toujours que cela marche aussi avec IIS pour Windows).
Là, effectivement, IIS je ne connais pas du tout.
Cf le § ``Note on hyperlinks and naming conventions'' de http://httpd.apache.org/docs/content-negotiation.html
Un grand merci pour cette doc. Je l'avais lue il y a quelques années, lorsque je n'en avais pas besoin et que c'était par simple curiosité, mais je l'avais oubliée depuis. Pourtant c'est un « must-read » comme le dit Pierre.
Je pense surtout que c'est la seule documentation à ce sujet (c'est vraiment confidentiel la négociation de contenu...), en tout cas je ne suis jamais tombé sur autre chose de probant.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Thu, 19 May 2005 00:57:36 +0200, Olivier Miakinen a écrit :
Récupérer les erreurs 404 (dûs à ce genre de liens invalides donc), et
proposer une page en allemand qui dit juste: le document que vous
cherchez n'est pas encore disponible en allemand, mais il est
disponible en:
suivi d'une liste des pages existantes avec les langues.
Eh oui, c'est une excellente idée, et si facile à faire en PHP...
malheureusement pour le moment je n'ai pas accès à PHP, mais je vais
probablement me compiler un CGI en C pour le faire.
Y a même pas Perl de disponible ?
Ca permet de déployer progressivement, il n'y a qu'une traduction à
faire (c'est une page générique), et cela permet aux utilisateurs 1) de
comprendre ce qui se passe
2) d'éventuellement choisir un second choix parmi les langues offertes
Un test rapide m'a montré que si j'essaye d'accéder à pageN qui n'existe
dans aucune des langues configurées dans mon navigateur, alors il me
propose toutes celles qui existent.
Oui, avec un code 300 je suppose (multiple choices)
Donc la même solution que celle exposée plus haut pourrait être batie
au-dessus de ce code, pour améliorer la page renvoyée au client.
En revanche, si je demande pageN.fr et qu'elle n'existe pas, alors c'est
404.
Oui, là, plus de négociation de contenu, en tout cas sur la partie langue.
Finalement, une possibilité serait
d'avoir à la fois des pageN.html.fr et des pageN.fr.html, l'une des deux
ayant des liens en pageM sans extension, et l'autre des liens avec
extension complète.
Je ne sais pas comment Apache réagira. Et pour éviter la duplication
physique, peut-être que le mécanisme avec fichier 'map' (au début du
document must-read) est meilleur, mais je ne le connais vraiment pas, et
cela doit être spécifique à Apache.
BTW, je privilégie index.fr.html plutôt que index.html.fr comme
nommage, car cela permet bien plus de choix dans les liens.
C'est ce que j'ai fait au début, mais j'en suis revenu. Je ne sais plus
si c'était parce qu'il y avait une référence à index.html quelque part
(auquel cas la page index.fr.html ne peut pas être trouvée) ou bien si
Oui, cela aurait été un problème. Au pire une petite règle de ré-écriture
pour supprimer les .html finaux avec un redirection ``interne'' pour
repartir dans la négociation de contenu.
c'était à cause d'un problème sous IIS (oui, parce que pour le moment
j'essaye toujours que cela marche aussi avec IIS pour Windows).
Là, effectivement, IIS je ne connais pas du tout.
Cf le § ``Note on hyperlinks and naming conventions'' de
http://httpd.apache.org/docs/content-negotiation.html
Un grand merci pour cette doc. Je l'avais lue il y a quelques années,
lorsque je n'en avais pas besoin et que c'était par simple curiosité,
mais je l'avais oubliée depuis. Pourtant c'est un « must-read » comme le
dit Pierre.
Je pense surtout que c'est la seule documentation à ce sujet (c'est
vraiment confidentiel la négociation de contenu...), en tout cas je ne
suis jamais tombé sur autre chose de probant.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Thu, 19 May 2005 00:57:36 +0200, Olivier Miakinen a écrit :
Récupérer les erreurs 404 (dûs à ce genre de liens invalides donc), et proposer une page en allemand qui dit juste: le document que vous cherchez n'est pas encore disponible en allemand, mais il est disponible en: suivi d'une liste des pages existantes avec les langues.
Eh oui, c'est une excellente idée, et si facile à faire en PHP... malheureusement pour le moment je n'ai pas accès à PHP, mais je vais probablement me compiler un CGI en C pour le faire.
Y a même pas Perl de disponible ?
Ca permet de déployer progressivement, il n'y a qu'une traduction à faire (c'est une page générique), et cela permet aux utilisateurs 1) de comprendre ce qui se passe 2) d'éventuellement choisir un second choix parmi les langues offertes
Un test rapide m'a montré que si j'essaye d'accéder à pageN qui n'existe dans aucune des langues configurées dans mon navigateur, alors il me propose toutes celles qui existent.
Oui, avec un code 300 je suppose (multiple choices)
Donc la même solution que celle exposée plus haut pourrait être batie au-dessus de ce code, pour améliorer la page renvoyée au client.
En revanche, si je demande pageN.fr et qu'elle n'existe pas, alors c'est 404.
Oui, là, plus de négociation de contenu, en tout cas sur la partie langue.
Finalement, une possibilité serait d'avoir à la fois des pageN.html.fr et des pageN.fr.html, l'une des deux ayant des liens en pageM sans extension, et l'autre des liens avec extension complète.
Je ne sais pas comment Apache réagira. Et pour éviter la duplication physique, peut-être que le mécanisme avec fichier 'map' (au début du document must-read) est meilleur, mais je ne le connais vraiment pas, et cela doit être spécifique à Apache.
BTW, je privilégie index.fr.html plutôt que index.html.fr comme nommage, car cela permet bien plus de choix dans les liens.
C'est ce que j'ai fait au début, mais j'en suis revenu. Je ne sais plus si c'était parce qu'il y avait une référence à index.html quelque part (auquel cas la page index.fr.html ne peut pas être trouvée) ou bien si
Oui, cela aurait été un problème. Au pire une petite règle de ré-écriture pour supprimer les .html finaux avec un redirection ``interne'' pour repartir dans la négociation de contenu.
c'était à cause d'un problème sous IIS (oui, parce que pour le moment j'essaye toujours que cela marche aussi avec IIS pour Windows).
Là, effectivement, IIS je ne connais pas du tout.
Cf le § ``Note on hyperlinks and naming conventions'' de http://httpd.apache.org/docs/content-negotiation.html
Un grand merci pour cette doc. Je l'avais lue il y a quelques années, lorsque je n'en avais pas besoin et que c'était par simple curiosité, mais je l'avais oubliée depuis. Pourtant c'est un « must-read » comme le dit Pierre.
Je pense surtout que c'est la seule documentation à ce sujet (c'est vraiment confidentiel la négociation de contenu...), en tout cas je ne suis jamais tombé sur autre chose de probant.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Pierre Goiffon
Olivier Miakinen wrote:
Pourquoi ne pas adopter un système de template avec cache
Je ne suis pas sûr de comprendre l'histoire du cache
On reproche toujours aux traitements serveur leur consommation de cpu :)
Oui. Au passage, je ne comprends pas bien « fr-fr » (quoique cela pourrait être fr-FR pour « français-FRANCE », puisque la casse n'est pas prise en compte) ni surtout « en-en » : je connais une langue dont le code est « en », mais aucun pays dont le code soit « EN ».
Oui fr-fr pour français (France) en-en n'existe pas ?
En l'occurrence, les pages statiques servant principalement de navigation vers diverses applications (CGI, Java et/ou JavaScript), aucune page existante ne devrait être modifiée
Oui, ça change de bcp alors ! Dans l'optique de rédactionnels à modifier de temps en temps, il est sûr que le HTML n'est qu'une finalité - ce n'est pas un format de stockage idéal, il y aurait sans doute quelque chose en amont (base de données, autre ??) pour faciliter les mises à jour.
Olivier Miakinen wrote:
Pourquoi ne pas adopter un système de template avec cache
Je ne suis pas sûr de comprendre l'histoire du cache
On reproche toujours aux traitements serveur leur consommation de cpu :)
Oui. Au passage, je ne comprends pas bien « fr-fr » (quoique cela
pourrait être fr-FR pour « français-FRANCE », puisque la casse n'est pas
prise en compte) ni surtout « en-en » : je connais une langue dont le
code est « en », mais aucun pays dont le code soit « EN ».
Oui fr-fr pour français (France)
en-en n'existe pas ?
En l'occurrence, les pages statiques servant principalement de
navigation vers diverses applications (CGI, Java et/ou JavaScript),
aucune page existante ne devrait être modifiée
Oui, ça change de bcp alors !
Dans l'optique de rédactionnels à modifier de temps en temps, il est sûr
que le HTML n'est qu'une finalité - ce n'est pas un format de stockage
idéal, il y aurait sans doute quelque chose en amont (base de données,
autre ??) pour faciliter les mises à jour.
Pourquoi ne pas adopter un système de template avec cache
Je ne suis pas sûr de comprendre l'histoire du cache
On reproche toujours aux traitements serveur leur consommation de cpu :)
Oui. Au passage, je ne comprends pas bien « fr-fr » (quoique cela pourrait être fr-FR pour « français-FRANCE », puisque la casse n'est pas prise en compte) ni surtout « en-en » : je connais une langue dont le code est « en », mais aucun pays dont le code soit « EN ».
Oui fr-fr pour français (France) en-en n'existe pas ?
En l'occurrence, les pages statiques servant principalement de navigation vers diverses applications (CGI, Java et/ou JavaScript), aucune page existante ne devrait être modifiée
Oui, ça change de bcp alors ! Dans l'optique de rédactionnels à modifier de temps en temps, il est sûr que le HTML n'est qu'une finalité - ce n'est pas un format de stockage idéal, il y aurait sans doute quelque chose en amont (base de données, autre ??) pour faciliter les mises à jour.
Olivier Miakinen
Le 19/05/2005 01:20, Patrick Mevzek a écrit :
malheureusement pour le moment je n'ai pas accès à PHP, mais je vais probablement me compiler un CGI en C pour le faire.
Y a même pas Perl de disponible ?
Ben non. En fait, dans l'absolu il pourrait y avoir ce qu'on veut puisque nous installons le serveur web sur chaque machine cible en même temps que les pages HTML, mais il faut que quelqu'un ait le temps de s'en occuper (et surtout de vérifier que cela marche sur tous les systèmes, et qu'il n'y a pas de collision avec un éventuel Perl et/ou PHP qui serait déjà présent).
Finalement, une possibilité serait d'avoir à la fois des pageN.html.fr et des pageN.fr.html, l'une des deux ayant des liens en pageM sans extension, et l'autre des liens avec extension complète.
Je ne sais pas comment Apache réagira.
On peut s'en arranger avec une extension incomplète. Par exemple : - dans pageN.fr.html, href="pageM.fr.html" (langue verrouillée sur fr) - dans pageN.en.html, href="pageM.en.html" (langue verrouillée sur en) - dans pageN.html.fr, href="pageM.html" (négociation à chaque appel) - dans pageN.html.en, href="pageM.html" (négociation à chaque appel)
Et pour éviter la duplication physique, peut-être que le mécanisme avec fichier 'map' (au début du document must-read) est meilleur, mais je ne le connais vraiment pas, et cela doit être spécifique à Apache.
Je ne crois pas que l'on puisse éviter la duplication physique dans ce cas puisque je dois forcément multiplier par deux le nombre de pages pour chaque langue : une page verrouillant le choix de la langue, l'autre provoquant une renégociation à chaque lien.
-- Olivier Miakinen
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
Le 19/05/2005 01:20, Patrick Mevzek a écrit :
malheureusement pour le moment je n'ai pas accès à PHP, mais je vais
probablement me compiler un CGI en C pour le faire.
Y a même pas Perl de disponible ?
Ben non. En fait, dans l'absolu il pourrait y avoir ce qu'on veut
puisque nous installons le serveur web sur chaque machine cible en même
temps que les pages HTML, mais il faut que quelqu'un ait le temps de
s'en occuper (et surtout de vérifier que cela marche sur tous les
systèmes, et qu'il n'y a pas de collision avec un éventuel Perl et/ou
PHP qui serait déjà présent).
Finalement, une possibilité serait
d'avoir à la fois des pageN.html.fr et des pageN.fr.html, l'une des deux
ayant des liens en pageM sans extension, et l'autre des liens avec
extension complète.
Je ne sais pas comment Apache réagira.
On peut s'en arranger avec une extension incomplète. Par exemple :
- dans pageN.fr.html, href="pageM.fr.html" (langue verrouillée sur fr)
- dans pageN.en.html, href="pageM.en.html" (langue verrouillée sur en)
- dans pageN.html.fr, href="pageM.html" (négociation à chaque appel)
- dans pageN.html.en, href="pageM.html" (négociation à chaque appel)
Et pour éviter la duplication
physique, peut-être que le mécanisme avec fichier 'map' (au début du
document must-read) est meilleur, mais je ne le connais vraiment pas, et
cela doit être spécifique à Apache.
Je ne crois pas que l'on puisse éviter la duplication physique dans ce
cas puisque je dois forcément multiplier par deux le nombre de pages
pour chaque langue : une page verrouillant le choix de la langue,
l'autre provoquant une renégociation à chaque lien.
--
Olivier Miakinen
--
Olivier Miakinen
Non, monsieur le juge, je vous le jure : jamais je n'ai cité
Bruxelles dans ma signature.
malheureusement pour le moment je n'ai pas accès à PHP, mais je vais probablement me compiler un CGI en C pour le faire.
Y a même pas Perl de disponible ?
Ben non. En fait, dans l'absolu il pourrait y avoir ce qu'on veut puisque nous installons le serveur web sur chaque machine cible en même temps que les pages HTML, mais il faut que quelqu'un ait le temps de s'en occuper (et surtout de vérifier que cela marche sur tous les systèmes, et qu'il n'y a pas de collision avec un éventuel Perl et/ou PHP qui serait déjà présent).
Finalement, une possibilité serait d'avoir à la fois des pageN.html.fr et des pageN.fr.html, l'une des deux ayant des liens en pageM sans extension, et l'autre des liens avec extension complète.
Je ne sais pas comment Apache réagira.
On peut s'en arranger avec une extension incomplète. Par exemple : - dans pageN.fr.html, href="pageM.fr.html" (langue verrouillée sur fr) - dans pageN.en.html, href="pageM.en.html" (langue verrouillée sur en) - dans pageN.html.fr, href="pageM.html" (négociation à chaque appel) - dans pageN.html.en, href="pageM.html" (négociation à chaque appel)
Et pour éviter la duplication physique, peut-être que le mécanisme avec fichier 'map' (au début du document must-read) est meilleur, mais je ne le connais vraiment pas, et cela doit être spécifique à Apache.
Je ne crois pas que l'on puisse éviter la duplication physique dans ce cas puisque je dois forcément multiplier par deux le nombre de pages pour chaque langue : une page verrouillant le choix de la langue, l'autre provoquant une renégociation à chaque lien.
-- Olivier Miakinen
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
Olivier Miakinen
Le 19/05/2005 09:46, Pierre Goiffon a écrit :
Oui. Au passage, je ne comprends pas bien « fr-fr » (quoique cela pourrait être fr-FR pour « français-FRANCE », puisque la casse n'est pas prise en compte) ni surtout « en-en » : je connais une langue dont le code est « en », mais aucun pays dont le code soit « EN ».
Oui fr-fr pour français (France)
Comme je le disais, cela me semble une mauvaise idée. Si tu fais une page spécifique pour le français de France, cela veut dire que tu en feras une autre pour le français de Belgique, une pour le français de Suisse, une encore pour le français du Zaïre, celui du Bénin, celui du Canada, etc. À moins que tu n'aies beaucoup de temps à perdre ou que les différences entre pays soient importantes, il vaut mieux faire une seule page pour tous les francophones, donc tout simplement « fr ».
en-en n'existe pas ?
Non, vu qu'il n'existe aucun pays dont le code soit « en ». Il existe en-gb, en-us, en-au, et probablement un grand nombre d'autres associations possibles (au moins 12 d'après mon Mozilla, et il ne connaît déjà pas tous les pays francophones). Mais là encore je te déconseille de faire des pages différentes selon chaque pays où l'on parle anglais : « en » suffit.
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
Le 19/05/2005 09:46, Pierre Goiffon a écrit :
Oui. Au passage, je ne comprends pas bien « fr-fr » (quoique cela
pourrait être fr-FR pour « français-FRANCE », puisque la casse n'est pas
prise en compte) ni surtout « en-en » : je connais une langue dont le
code est « en », mais aucun pays dont le code soit « EN ».
Oui fr-fr pour français (France)
Comme je le disais, cela me semble une mauvaise idée. Si tu fais une
page spécifique pour le français de France, cela veut dire que tu en
feras une autre pour le français de Belgique, une pour le français de
Suisse, une encore pour le français du Zaïre, celui du Bénin, celui du
Canada, etc. À moins que tu n'aies beaucoup de temps à perdre ou que les
différences entre pays soient importantes, il vaut mieux faire une seule
page pour tous les francophones, donc tout simplement « fr ».
en-en n'existe pas ?
Non, vu qu'il n'existe aucun pays dont le code soit « en ».
Il existe en-gb, en-us, en-au, et probablement un grand nombre
d'autres associations possibles (au moins 12 d'après mon Mozilla,
et il ne connaît déjà pas tous les pays francophones). Mais là
encore je te déconseille de faire des pages différentes selon chaque
pays où l'on parle anglais : « en » suffit.
--
Olivier Miakinen
Non, monsieur le juge, je vous le jure : jamais je n'ai cité
Bruxelles dans ma signature.
Oui. Au passage, je ne comprends pas bien « fr-fr » (quoique cela pourrait être fr-FR pour « français-FRANCE », puisque la casse n'est pas prise en compte) ni surtout « en-en » : je connais une langue dont le code est « en », mais aucun pays dont le code soit « EN ».
Oui fr-fr pour français (France)
Comme je le disais, cela me semble une mauvaise idée. Si tu fais une page spécifique pour le français de France, cela veut dire que tu en feras une autre pour le français de Belgique, une pour le français de Suisse, une encore pour le français du Zaïre, celui du Bénin, celui du Canada, etc. À moins que tu n'aies beaucoup de temps à perdre ou que les différences entre pays soient importantes, il vaut mieux faire une seule page pour tous les francophones, donc tout simplement « fr ».
en-en n'existe pas ?
Non, vu qu'il n'existe aucun pays dont le code soit « en ». Il existe en-gb, en-us, en-au, et probablement un grand nombre d'autres associations possibles (au moins 12 d'après mon Mozilla, et il ne connaît déjà pas tous les pays francophones). Mais là encore je te déconseille de faire des pages différentes selon chaque pays où l'on parle anglais : « en » suffit.
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
Thierry Boudet
On 2005-05-19, Olivier Miakinen <om+ wrote:
Je ne crois pas que l'on puisse éviter la duplication physique dans ce cas puisque je dois forcément multiplier par deux le nombre de pages pour chaque langue : une page verrouillant le choix de la langue, l'autre provoquant une renégociation à chaque lien.
Et un lien symbolique, ça le fait pas ?
-- _/°< coin
On 2005-05-19, Olivier Miakinen <om+news@miakinen.net> wrote:
Je ne crois pas que l'on puisse éviter la duplication physique dans ce
cas puisque je dois forcément multiplier par deux le nombre de pages
pour chaque langue : une page verrouillant le choix de la langue,
l'autre provoquant une renégociation à chaque lien.
Je ne crois pas que l'on puisse éviter la duplication physique dans ce cas puisque je dois forcément multiplier par deux le nombre de pages pour chaque langue : une page verrouillant le choix de la langue, l'autre provoquant une renégociation à chaque lien.
Et un lien symbolique, ça le fait pas ?
-- _/°< coin
Olivier Miakinen
Le 19/05/2005 22:17, Thierry Boudet a écrit :
Je ne crois pas que l'on puisse éviter la duplication physique dans ce cas puisque je dois forcément multiplier par deux le nombre de pages pour chaque langue : une page verrouillant le choix de la langue, l'autre provoquant une renégociation à chaque lien.
Et un lien symbolique, ça le fait pas ?
Non pour la même raison : les url contenues dans les deux fichiers d'une langue donnée sont différentes.
Le 19/05/2005 22:17, Thierry Boudet a écrit :
Je ne crois pas que l'on puisse éviter la duplication physique dans ce
cas puisque je dois forcément multiplier par deux le nombre de pages
pour chaque langue : une page verrouillant le choix de la langue,
l'autre provoquant une renégociation à chaque lien.
Et un lien symbolique, ça le fait pas ?
Non pour la même raison : les url contenues dans les deux fichiers d'une
langue donnée sont différentes.
Je ne crois pas que l'on puisse éviter la duplication physique dans ce cas puisque je dois forcément multiplier par deux le nombre de pages pour chaque langue : une page verrouillant le choix de la langue, l'autre provoquant une renégociation à chaque lien.
Et un lien symbolique, ça le fait pas ?
Non pour la même raison : les url contenues dans les deux fichiers d'une langue donnée sont différentes.
