J'ai un petit soucis, à savoir que pour un site sur lequel je travaille,
l'horodatage est *très important* et le serveur de dev et le serveru de
prod ne sont pas au même endroit (l'un en france, l'autre aux US).
Forcémment, quand je passe le site "fonctionnel" en prod, je me prend 6h
dans la vue.
Je voudrais éviter de reprendre toutes mes fonctions date() pour leur
rajouter 6h, y'a t'il un moyen de dire à mes scripts que je veux qu'il
compte le décalage horaire en plus?
Merci d'avance
--
Découvrez Original War: http://www.original-war.org
Humour: http://www.chatfou.com
Tchattez en liberté: http://www.crazy-irc.net
Le Fri, 13 May 2005 13:05:03 +0000, Guillaume Bouchard a écrit:
je ne vois pas pourquoi une même URL pourrait pointer vers deux langues.
Je ne vois pas pourquoi il faudrait 2 URL pour pointer vers une même page.
;-)
-- Christophe PEREZ Écrivez moi sans _faute !
Patrick Mevzek
Et bien, si c'était *ma* vision des choses, ce serait juste une opinion que je me serai faite à priori, là c'est une opinion que je me suis faite à partir de faits statistiques.
Vous jouez parfaitement sur les mots...
Par contre, j'ai bien l'impression que votre vision ne repose sur aucun fait concret, vous balancer des idées et des vérités sas jamais décrire la démarche qui vous mène à ces conclusions.
Votre vision est manifestement à courte portée. Tant pis.
[snip le paragraphe sur les statistiques]
C'est ça les statistiques, on lisse les données pour éliminer du panel les cas marginaux et ceux qui ne peuvent rien apporter.
Je ne fais pas beaucoup confiance aux statistiques en général mais manifestement comment vous faites les votres je ne leur apporte aucune confiance : vous triturez les chiffres pour enlever tout ce qui vous gêne, et ainsi arriver aux conclusions que vous voulez.
En laissant de côté les vrais problèmes ou en faisant croire qu'ils ont des solutions simples : il n'y a *pas* de moyen fiable de récupérer une *langue* à partir d'une IP.
Mais en conjuguant les paramètres poue éviter de trop biaiser les résultats on arrive à s'en sortir.
On peut effectivement toujours arriver à croire qu'on justifie son point de vue avec des statistiques qu'on a manipulé en ce sens.
Mais d'un autre côté il y a *très* peu de sites web qui utilisent la négociation de contenu correctement: en général les contenus dans des langues différentes sont accessibles à des URLs différentes, ce qui est l'exact opposé de la négociation de contenu.
De toute façon, on avait bien compris, il n'y a que vous à savoir le faire de la négociation de contenu.
Non, quelques autres personnes aussi manifestement :-)
Personellement, je comprend dans négociation de contenu que le *serveur web donne à l'utilisateur le contenu approprié* comme le fait Apache, que ce soit à une URL donnée ou qu'il redirige vers une autre, la méthode importe peu, c'est le résultat qui compte.
Relisez la définition de négociation de contenu dans le RFC idoine alors, manifestement vous êtes pas sur la bonne.
Je tiens quand même à vous préciser que mes clients sont très satisfaits de mais services, notament en terme d'ergonomie des applications.
Ca c'est l'argument qui tue: toute façon, quoi que je fasse, on est content de moi, alors forcément c'est bien ce que je fais.
Désolé, cela ne marche pas avec moi. Et termine de vous discréditer complétement, cher anonyme.
-- 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>
Et bien, si c'était *ma* vision des choses, ce serait juste une opinion
que je me serai faite à priori, là c'est une opinion que je me suis
faite à partir de faits statistiques.
Vous jouez parfaitement sur les mots...
Par contre, j'ai bien l'impression que votre vision ne repose sur aucun
fait concret, vous balancer des idées et des vérités sas jamais décrire
la démarche qui vous mène à ces conclusions.
Votre vision est manifestement à courte portée. Tant pis.
[snip le paragraphe sur les statistiques]
C'est ça les statistiques, on lisse les données pour éliminer du panel
les cas marginaux et ceux qui ne peuvent rien apporter.
Je ne fais pas beaucoup confiance aux statistiques en général mais
manifestement comment vous faites les votres je ne leur apporte aucune
confiance : vous triturez les chiffres pour enlever tout ce qui vous
gêne, et ainsi arriver aux conclusions que vous voulez.
En laissant de côté les vrais problèmes ou en faisant croire qu'ils ont
des solutions simples : il n'y a *pas* de moyen fiable de récupérer une
*langue* à partir d'une IP.
Mais en conjuguant les paramètres poue éviter de trop biaiser les
résultats on arrive à s'en sortir.
On peut effectivement toujours arriver à croire qu'on justifie son point
de vue avec des statistiques qu'on a manipulé en ce sens.
Mais d'un autre côté il y a *très* peu de sites web qui utilisent la
négociation de contenu correctement: en général les contenus dans des
langues différentes sont accessibles à des URLs différentes, ce qui
est l'exact opposé de la négociation de contenu.
De toute façon, on avait bien compris, il n'y a que vous à savoir le
faire de la négociation de contenu.
Non, quelques autres personnes aussi manifestement :-)
Personellement, je comprend dans négociation de contenu que le *serveur
web donne à l'utilisateur le contenu approprié* comme le fait Apache,
que ce soit à une URL donnée ou qu'il redirige vers une autre, la
méthode importe peu, c'est le résultat qui compte.
Relisez la définition de négociation de contenu dans le RFC idoine alors,
manifestement vous êtes pas sur la bonne.
Je tiens quand même à vous préciser que mes clients sont très satisfaits
de mais services, notament en terme d'ergonomie des applications.
Ca c'est l'argument qui tue: toute façon, quoi que je fasse, on est
content de moi, alors forcément c'est bien ce que je fais.
Désolé, cela ne marche pas avec moi. Et termine de vous discréditer
complétement, cher anonyme.
--
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>
Et bien, si c'était *ma* vision des choses, ce serait juste une opinion que je me serai faite à priori, là c'est une opinion que je me suis faite à partir de faits statistiques.
Vous jouez parfaitement sur les mots...
Par contre, j'ai bien l'impression que votre vision ne repose sur aucun fait concret, vous balancer des idées et des vérités sas jamais décrire la démarche qui vous mène à ces conclusions.
Votre vision est manifestement à courte portée. Tant pis.
[snip le paragraphe sur les statistiques]
C'est ça les statistiques, on lisse les données pour éliminer du panel les cas marginaux et ceux qui ne peuvent rien apporter.
Je ne fais pas beaucoup confiance aux statistiques en général mais manifestement comment vous faites les votres je ne leur apporte aucune confiance : vous triturez les chiffres pour enlever tout ce qui vous gêne, et ainsi arriver aux conclusions que vous voulez.
En laissant de côté les vrais problèmes ou en faisant croire qu'ils ont des solutions simples : il n'y a *pas* de moyen fiable de récupérer une *langue* à partir d'une IP.
Mais en conjuguant les paramètres poue éviter de trop biaiser les résultats on arrive à s'en sortir.
On peut effectivement toujours arriver à croire qu'on justifie son point de vue avec des statistiques qu'on a manipulé en ce sens.
Mais d'un autre côté il y a *très* peu de sites web qui utilisent la négociation de contenu correctement: en général les contenus dans des langues différentes sont accessibles à des URLs différentes, ce qui est l'exact opposé de la négociation de contenu.
De toute façon, on avait bien compris, il n'y a que vous à savoir le faire de la négociation de contenu.
Non, quelques autres personnes aussi manifestement :-)
Personellement, je comprend dans négociation de contenu que le *serveur web donne à l'utilisateur le contenu approprié* comme le fait Apache, que ce soit à une URL donnée ou qu'il redirige vers une autre, la méthode importe peu, c'est le résultat qui compte.
Relisez la définition de négociation de contenu dans le RFC idoine alors, manifestement vous êtes pas sur la bonne.
Je tiens quand même à vous préciser que mes clients sont très satisfaits de mais services, notament en terme d'ergonomie des applications.
Ca c'est l'argument qui tue: toute façon, quoi que je fasse, on est content de moi, alors forcément c'est bien ce que je fais.
Désolé, cela ne marche pas avec moi. Et termine de vous discréditer complétement, cher anonyme.
-- 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>
cleo
Je ne comprends pas vos jacquasseries, C'est bien ce qu'on vous reproche :-)
Le "on", c'est sûrement "VOUS" et votre "EGO". Dans le fond c'est comique de vous regarder vous exiter sur chaque post, ceci dit, je ne comprends pas réellement votre croisade ... Bref, j'entends vos arguments, mais je pense que d'autres façons d'entrevoir les choses sont possibles (avec un peu d'imagination, sans quoi ...). Xul, aspx, prado, ... sont d'autres voies séduisantes à étudier, mais avant, il faut que j'apprenne comment fonctionnent ces satanées sessions :-)))
-- Cléo
Je ne comprends pas vos jacquasseries,
C'est bien ce qu'on vous reproche :-)
Le "on", c'est sûrement "VOUS" et votre "EGO". Dans le fond c'est comique de
vous regarder vous exiter sur chaque post, ceci dit, je ne comprends pas
réellement votre croisade ...
Bref, j'entends vos arguments, mais je pense que d'autres façons d'entrevoir
les choses sont possibles (avec un peu d'imagination, sans quoi ...). Xul,
aspx, prado, ... sont d'autres voies séduisantes à étudier, mais avant, il
faut que j'apprenne comment fonctionnent ces satanées sessions :-)))
Je ne comprends pas vos jacquasseries, C'est bien ce qu'on vous reproche :-)
Le "on", c'est sûrement "VOUS" et votre "EGO". Dans le fond c'est comique de vous regarder vous exiter sur chaque post, ceci dit, je ne comprends pas réellement votre croisade ... Bref, j'entends vos arguments, mais je pense que d'autres façons d'entrevoir les choses sont possibles (avec un peu d'imagination, sans quoi ...). Xul, aspx, prado, ... sont d'autres voies séduisantes à étudier, mais avant, il faut que j'apprenne comment fonctionnent ces satanées sessions :-)))
-- Cléo
ftc
[SNIP]
C'est ça les statistiques, on lisse les données pour éliminer du panel les cas marginaux et ceux qui ne peuvent rien apporter.
Je ne fais pas beaucoup confiance aux statistiques en général mais manifestement comment vous faites les votres je ne leur apporte aucune confiance : vous triturez les chiffres pour enlever tout ce qui vous gêne, et ainsi arriver aux conclusions que vous voulez.
Non bien, sûr, vous préférez rester sur vos certitudes de grand GURU du développement qui preche la bonne parole en disant: "C'est comme ça qu'on fait et pas autrement."
Je ne titure pas les chiffres mais applique des méthodes statistiques ( lissage de panel, élimination du panel de données pouvant biaiser l'analyse ... ).
En laissant de côté les vrais problèmes ou en faisant croire qu'ils ont des solutions simples : il n'y a *pas* de moyen fiable de récupérer une *langue* à partir d'une IP.
Je n'ai jamais dit que c'était simple et non plus que c'était fiable à 100%, vous le savez comme moi rien n'est fiable à 100% en informatique.
Le boulot du développeur, ce n'est pas faire des choses simples pour lui, mais des choses simples pour l'utilisateur mais j'ai l'impression que c'est une notion qui vous dépasse un peu.
[SNIP]
Relisez la définition de négociation de contenu dans le RFC idoine alors, manifestement vous êtes pas sur la bonne.
Il n'y a pas que les RFC dans la vie. Les RFC ne sont pas un grand dico universel mais juste des propositions de standardisation.
Je tiens quand même à vous préciser que mes clients sont très satisfaits de mais services, notament en terme d'ergonomie des applications.
Ca c'est l'argument qui tue: toute façon, quoi que je fasse, on est content de moi, alors forcément c'est bien ce que je fais.
Rien à voir avec cela, il arrive aussi que j'ai des clients insatisfaits comme tout le monde.
L'objectif final est quand même la satisfaction du client et celui-ci n'en a rien à cirer des considérations techniques du genre il ne faut pas utiliser les cookie ou javascript c'est nul, il voit le produit fini et est beaucoup plus satisfait devant une application ergonomique.
Désolé, cela ne marche pas avec moi. Et termine de vous discréditer complétement, cher anonyme.
Je n'essaie pas de vous convaincre de quoi que ce soit, c'est une chose impossible à en voir vos arguments. et je n'ai pas besoin non plus d'une quelconque considération ou crédibilité à vos yeux.
[SNIP]
C'est ça les statistiques, on lisse les données pour éliminer du panel
les cas marginaux et ceux qui ne peuvent rien apporter.
Je ne fais pas beaucoup confiance aux statistiques en général mais
manifestement comment vous faites les votres je ne leur apporte aucune
confiance : vous triturez les chiffres pour enlever tout ce qui vous
gêne, et ainsi arriver aux conclusions que vous voulez.
Non bien, sûr, vous préférez rester sur vos certitudes de grand GURU du
développement qui preche la bonne parole en disant: "C'est comme ça
qu'on fait et pas autrement."
Je ne titure pas les chiffres mais applique des méthodes statistiques (
lissage de panel, élimination du panel de données pouvant biaiser
l'analyse ... ).
En laissant de côté les vrais problèmes ou en faisant croire qu'ils ont
des solutions simples : il n'y a *pas* de moyen fiable de récupérer une
*langue* à partir d'une IP.
Je n'ai jamais dit que c'était simple et non plus que c'était fiable à
100%, vous le savez comme moi rien n'est fiable à 100% en informatique.
Le boulot du développeur, ce n'est pas faire des choses simples pour
lui, mais des choses simples pour l'utilisateur mais j'ai l'impression
que c'est une notion qui vous dépasse un peu.
[SNIP]
Relisez la définition de négociation de contenu dans le RFC idoine alors,
manifestement vous êtes pas sur la bonne.
Il n'y a pas que les RFC dans la vie. Les RFC ne sont pas un grand dico
universel mais juste des propositions de standardisation.
Je tiens quand même à vous préciser que mes clients sont très satisfaits
de mais services, notament en terme d'ergonomie des applications.
Ca c'est l'argument qui tue: toute façon, quoi que je fasse, on est
content de moi, alors forcément c'est bien ce que je fais.
Rien à voir avec cela, il arrive aussi que j'ai des clients insatisfaits
comme tout le monde.
L'objectif final est quand même la satisfaction du client et celui-ci
n'en a rien à cirer des considérations techniques du genre il ne faut
pas utiliser les cookie ou javascript c'est nul, il voit le produit fini
et est beaucoup plus satisfait devant une application ergonomique.
Désolé, cela ne marche pas avec moi. Et termine de vous discréditer
complétement, cher anonyme.
Je n'essaie pas de vous convaincre de quoi que ce soit, c'est une chose
impossible à en voir vos arguments. et je n'ai pas besoin non plus d'une
quelconque considération ou crédibilité à vos yeux.
C'est ça les statistiques, on lisse les données pour éliminer du panel les cas marginaux et ceux qui ne peuvent rien apporter.
Je ne fais pas beaucoup confiance aux statistiques en général mais manifestement comment vous faites les votres je ne leur apporte aucune confiance : vous triturez les chiffres pour enlever tout ce qui vous gêne, et ainsi arriver aux conclusions que vous voulez.
Non bien, sûr, vous préférez rester sur vos certitudes de grand GURU du développement qui preche la bonne parole en disant: "C'est comme ça qu'on fait et pas autrement."
Je ne titure pas les chiffres mais applique des méthodes statistiques ( lissage de panel, élimination du panel de données pouvant biaiser l'analyse ... ).
En laissant de côté les vrais problèmes ou en faisant croire qu'ils ont des solutions simples : il n'y a *pas* de moyen fiable de récupérer une *langue* à partir d'une IP.
Je n'ai jamais dit que c'était simple et non plus que c'était fiable à 100%, vous le savez comme moi rien n'est fiable à 100% en informatique.
Le boulot du développeur, ce n'est pas faire des choses simples pour lui, mais des choses simples pour l'utilisateur mais j'ai l'impression que c'est une notion qui vous dépasse un peu.
[SNIP]
Relisez la définition de négociation de contenu dans le RFC idoine alors, manifestement vous êtes pas sur la bonne.
Il n'y a pas que les RFC dans la vie. Les RFC ne sont pas un grand dico universel mais juste des propositions de standardisation.
Je tiens quand même à vous préciser que mes clients sont très satisfaits de mais services, notament en terme d'ergonomie des applications.
Ca c'est l'argument qui tue: toute façon, quoi que je fasse, on est content de moi, alors forcément c'est bien ce que je fais.
Rien à voir avec cela, il arrive aussi que j'ai des clients insatisfaits comme tout le monde.
L'objectif final est quand même la satisfaction du client et celui-ci n'en a rien à cirer des considérations techniques du genre il ne faut pas utiliser les cookie ou javascript c'est nul, il voit le produit fini et est beaucoup plus satisfait devant une application ergonomique.
Désolé, cela ne marche pas avec moi. Et termine de vous discréditer complétement, cher anonyme.
Je n'essaie pas de vous convaincre de quoi que ce soit, c'est une chose impossible à en voir vos arguments. et je n'ai pas besoin non plus d'une quelconque considération ou crédibilité à vos yeux.
Patrick Mevzek
Patrick Mevzek wrote:
Mais d'un autre côté il y a *très* peu de sites web qui utilisent la négociation de contenu correctement: en général les contenus dans des langues différentes sont accessibles à des URLs différentes, ce qui est l'exact opposé de la négociation de contenu.
Je pense qu'il faudrait faire comme cela. je ne vois pas pourquoi une même URL pourrait pointer vers deux langues.
Parce que c'est la base de la négociation de contenu : à une même URL on a différents documents, dans différents formats (ex: xhtml vs html, png vs gif), dans différentes langues, et dans différents format de compression.
Ca permet de donner une seule et même URL aux visiteurs et le logiciel va s'adapter pour récupérer la ``meilleure'' version, selon les paramètres personnels et les possibilités.
On en parle en détail dans un autre (nouveau) thread si vous voulez.
-- 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>
Patrick Mevzek wrote:
Mais d'un autre côté il y a *très* peu de sites web qui utilisent la
négociation de contenu correctement: en général les contenus dans des
langues différentes sont accessibles à des URLs différentes, ce qui est
l'exact opposé de la négociation de contenu.
Je pense qu'il faudrait faire comme cela. je ne vois pas pourquoi une
même URL pourrait pointer vers deux langues.
Parce que c'est la base de la négociation de contenu : à une même URL on
a différents documents, dans différents formats (ex: xhtml vs html, png
vs gif), dans différentes langues, et dans différents format de
compression.
Ca permet de donner une seule et même URL aux visiteurs et le logiciel va
s'adapter pour récupérer la ``meilleure'' version, selon les paramètres
personnels et les possibilités.
On en parle en détail dans un autre (nouveau) thread si vous voulez.
--
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>
Mais d'un autre côté il y a *très* peu de sites web qui utilisent la négociation de contenu correctement: en général les contenus dans des langues différentes sont accessibles à des URLs différentes, ce qui est l'exact opposé de la négociation de contenu.
Je pense qu'il faudrait faire comme cela. je ne vois pas pourquoi une même URL pourrait pointer vers deux langues.
Parce que c'est la base de la négociation de contenu : à une même URL on a différents documents, dans différents formats (ex: xhtml vs html, png vs gif), dans différentes langues, et dans différents format de compression.
Ca permet de donner une seule et même URL aux visiteurs et le logiciel va s'adapter pour récupérer la ``meilleure'' version, selon les paramètres personnels et les possibilités.
On en parle en détail dans un autre (nouveau) thread si vous voulez.
-- 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>
John GALLET
Bonjour,
des solutions simples : il n'y a *pas* de moyen fiable de récupérer une *langue* à partir d'une IP.
Déjà que la validité de cette adresse IP n'a strictement aucun sens, de toutes façons, on va pas aller bien loin. Je rappelle qu'il n'est pas possible, et ceci est directement lié au fonctionnement même de tcp/ip, de connaître côté serveur l'IP d'un client avec certitude (proxy, etc...). Et si on l'obtient par une solution côté client (modulo les security managers etc...), une fois qu'on aura 192.168.x.y, on sera pas plus avancés.
a++; JG
Bonjour,
des solutions simples : il n'y a *pas* de moyen fiable de récupérer une
*langue* à partir d'une IP.
Déjà que la validité de cette adresse IP n'a strictement aucun sens, de
toutes façons, on va pas aller bien loin. Je rappelle qu'il n'est pas
possible, et ceci est directement lié au fonctionnement même de tcp/ip, de
connaître côté serveur l'IP d'un client avec certitude (proxy, etc...). Et
si on l'obtient par une solution côté client (modulo les security managers
etc...), une fois qu'on aura 192.168.x.y, on sera pas plus avancés.
des solutions simples : il n'y a *pas* de moyen fiable de récupérer une *langue* à partir d'une IP.
Déjà que la validité de cette adresse IP n'a strictement aucun sens, de toutes façons, on va pas aller bien loin. Je rappelle qu'il n'est pas possible, et ceci est directement lié au fonctionnement même de tcp/ip, de connaître côté serveur l'IP d'un client avec certitude (proxy, etc...). Et si on l'obtient par une solution côté client (modulo les security managers etc...), une fois qu'on aura 192.168.x.y, on sera pas plus avancés.
a++; JG
John GALLET
Le "on", c'est sûrement "VOUS" et votre "EGO". Diantre. Le tout est tellement gros que j'en vois deux autres couples.
Dans le fond c'est comique de vous regarder vous exiter sur chaque post, Rassurez vous, ça m'en touche une sans me faire bouger l'autre.
ceci dit, je ne comprends pas réellement votre croisade ... Bref, L'amour des belles choses ? Aider les autres à comprendre ? Sont-ce là
tellement des notions inhabituelles dans ce monde de médiocrité ?
j'entends vos arguments, Alors c'est tout ce qui m'intéresse. Autres choses que je me tue à répéter
depuis des années : 1) à chaque problème technique la solution qui lui est la plus adaptée 2) l'essentiel est de *comprendre* ce que l'on fait pour choisir en connaissance de cause.
avant, il faut que j'apprenne comment fonctionnent ces satanées sessions :-))) Vous avez un chapitre complet là dessus sur le cours que je diffuse sur
www.saphirtech.com (lien en bas). Ca vous permettra de comprendre le principe. N'hésitez pas à poser des questions, ou ici ou directement par mail.
a++; JG
Le "on", c'est sûrement "VOUS" et votre "EGO".
Diantre. Le tout est tellement gros que j'en vois deux autres couples.
Dans le fond c'est comique de vous regarder vous exiter sur chaque post,
Rassurez vous, ça m'en touche une sans me faire bouger l'autre.
ceci dit, je ne comprends pas réellement votre croisade ... Bref,
L'amour des belles choses ? Aider les autres à comprendre ? Sont-ce là
tellement des notions inhabituelles dans ce monde de médiocrité ?
j'entends vos arguments,
Alors c'est tout ce qui m'intéresse. Autres choses que je me tue à répéter
depuis des années :
1) à chaque problème technique la solution qui lui est la plus adaptée
2) l'essentiel est de *comprendre* ce que l'on fait pour choisir en
connaissance de cause.
avant, il faut que j'apprenne comment fonctionnent ces satanées sessions
:-)))
Vous avez un chapitre complet là dessus sur le cours que je diffuse sur
www.saphirtech.com (lien en bas). Ca vous permettra de comprendre le
principe. N'hésitez pas à poser des questions, ou ici ou directement par
mail.
Le "on", c'est sûrement "VOUS" et votre "EGO". Diantre. Le tout est tellement gros que j'en vois deux autres couples.
Dans le fond c'est comique de vous regarder vous exiter sur chaque post, Rassurez vous, ça m'en touche une sans me faire bouger l'autre.
ceci dit, je ne comprends pas réellement votre croisade ... Bref, L'amour des belles choses ? Aider les autres à comprendre ? Sont-ce là
tellement des notions inhabituelles dans ce monde de médiocrité ?
j'entends vos arguments, Alors c'est tout ce qui m'intéresse. Autres choses que je me tue à répéter
depuis des années : 1) à chaque problème technique la solution qui lui est la plus adaptée 2) l'essentiel est de *comprendre* ce que l'on fait pour choisir en connaissance de cause.
avant, il faut que j'apprenne comment fonctionnent ces satanées sessions :-))) Vous avez un chapitre complet là dessus sur le cours que je diffuse sur
www.saphirtech.com (lien en bas). Ca vous permettra de comprendre le principe. N'hésitez pas à poser des questions, ou ici ou directement par mail.
a++; JG
ftc
Bonjour,
des solutions simples : il n'y a *pas* de moyen fiable de récupérer une *langue* à partir d'une IP.
Déjà que la validité de cette adresse IP n'a strictement aucun sens, de toutes façons, on va pas aller bien loin. Je rappelle qu'il n'est pas possible, et ceci est directement lié au fonctionnement même de tcp/ip, de connaître côté serveur l'IP d'un client avec certitude (proxy, etc...). Et si on l'obtient par une solution côté client (modulo les security managers etc...), une fois qu'on aura 192.168.x.y, on sera pas plus avancés.
Cessez de dénigrer sans cesse le travail des autres parce que vous n'êtes pas d'accord et de faire croire que des choses ne sont pas possibles quand elles le sont.
La détection de l'IP pour déterminer la localisation d'un utilisateur est fiable à 80%, couplé à d'autres informations ( il y a quand même déjà pas mal d'infos dans les en-têtes HTTP ), on peut déduire la localisation réelle du visiteur avec une précision assez importante. Et rien n'empeche de laisser une occasion au visiteur de pouvoir préciser celle-ci si elle n'est pas bonne.
Ces solutions sont utilisées par des sites de ventes à distance ainsi que par les systèmes de paiements électroniques pour limiter la fraude.
Vous savez comme moi qu'en informatique, on ne parle jamais de certitude puisque ça n'existe pas, ce n'est quand même pas une raison pour ne pas essayer.
J'imagine bien mon navigateur me demander sans arret quel est l'encodage de la page que je consulte parce que ce n'est pas précisé dans l'en-tête HTML ou que l'en-tête HTTP est faux. Non il essaie de trouver tout seul avec des méthodes statistiques qui ne sont pas fiable à 100% et il lui arrive de se tromper. Allez-vous mettre ces navigateurs à la poubelles parce qu'il n'ont pas une techno fiable à 100% ? Je ne crois pas.
Bonjour,
des solutions simples : il n'y a *pas* de moyen fiable de récupérer une
*langue* à partir d'une IP.
Déjà que la validité de cette adresse IP n'a strictement aucun sens, de
toutes façons, on va pas aller bien loin. Je rappelle qu'il n'est pas
possible, et ceci est directement lié au fonctionnement même de tcp/ip, de
connaître côté serveur l'IP d'un client avec certitude (proxy, etc...). Et
si on l'obtient par une solution côté client (modulo les security managers
etc...), une fois qu'on aura 192.168.x.y, on sera pas plus avancés.
Cessez de dénigrer sans cesse le travail des autres parce que vous
n'êtes pas d'accord et de faire croire que des choses ne sont pas
possibles quand elles le sont.
La détection de l'IP pour déterminer la localisation d'un utilisateur
est fiable à 80%, couplé à d'autres informations ( il y a quand même
déjà pas mal d'infos dans les en-têtes HTTP ), on peut déduire la
localisation réelle du visiteur avec une précision assez importante. Et
rien n'empeche de laisser une occasion au visiteur de pouvoir préciser
celle-ci si elle n'est pas bonne.
Ces solutions sont utilisées par des sites de ventes à distance ainsi
que par les systèmes de paiements électroniques pour limiter la fraude.
Vous savez comme moi qu'en informatique, on ne parle jamais de certitude
puisque ça n'existe pas, ce n'est quand même pas une raison pour ne pas
essayer.
J'imagine bien mon navigateur me demander sans arret quel est l'encodage
de la page que je consulte parce que ce n'est pas précisé dans l'en-tête
HTML ou que l'en-tête HTTP est faux. Non il essaie de trouver tout seul
avec des méthodes statistiques qui ne sont pas fiable à 100% et il lui
arrive de se tromper. Allez-vous mettre ces navigateurs à la poubelles
parce qu'il n'ont pas une techno fiable à 100% ? Je ne crois pas.
des solutions simples : il n'y a *pas* de moyen fiable de récupérer une *langue* à partir d'une IP.
Déjà que la validité de cette adresse IP n'a strictement aucun sens, de toutes façons, on va pas aller bien loin. Je rappelle qu'il n'est pas possible, et ceci est directement lié au fonctionnement même de tcp/ip, de connaître côté serveur l'IP d'un client avec certitude (proxy, etc...). Et si on l'obtient par une solution côté client (modulo les security managers etc...), une fois qu'on aura 192.168.x.y, on sera pas plus avancés.
Cessez de dénigrer sans cesse le travail des autres parce que vous n'êtes pas d'accord et de faire croire que des choses ne sont pas possibles quand elles le sont.
La détection de l'IP pour déterminer la localisation d'un utilisateur est fiable à 80%, couplé à d'autres informations ( il y a quand même déjà pas mal d'infos dans les en-têtes HTTP ), on peut déduire la localisation réelle du visiteur avec une précision assez importante. Et rien n'empeche de laisser une occasion au visiteur de pouvoir préciser celle-ci si elle n'est pas bonne.
Ces solutions sont utilisées par des sites de ventes à distance ainsi que par les systèmes de paiements électroniques pour limiter la fraude.
Vous savez comme moi qu'en informatique, on ne parle jamais de certitude puisque ça n'existe pas, ce n'est quand même pas une raison pour ne pas essayer.
J'imagine bien mon navigateur me demander sans arret quel est l'encodage de la page que je consulte parce que ce n'est pas précisé dans l'en-tête HTML ou que l'en-tête HTTP est faux. Non il essaie de trouver tout seul avec des méthodes statistiques qui ne sont pas fiable à 100% et il lui arrive de se tromper. Allez-vous mettre ces navigateurs à la poubelles parce qu'il n'ont pas une techno fiable à 100% ? Je ne crois pas.
John GALLET
de faire croire que des choses ne sont pas possibles quand elles le sont.
Bon, halte aux conneries maintenant. On ne PEUT PAS connaître l'ip de la machine cliente avec certitude, c'est le protocole qui l'impose, point barre. Et vous annoncez vous même une fiabilité de merde (80%) pour le reste (oui, oui, un mec sur 5 qui n'a pas la bonne information, c'est une fiabilité DE MERDE).
localisation réelle du visiteur avec une précision assez importante. Et rien n'empeche de laisser une occasion au visiteur de pouvoir préciser celle-ci si elle n'est pas bonne.
C'est vraiment incroyable d'être amputé du bulbe à ce point là. Ce qu'on se tue à vous dire, c'est justement que la détection automatique est du nice-to-have et non pas la solution principale parce que 1) comme vous l'avouez vous même elle n'est fiable que 4 coups sur 5 et 2)l'utilisateur doit pouvoir la surcharger manuellement.
fu2 qui va bien. Et je ne vous salue pas.
-- Si la connerie était cotée en bourse,tu serais incarcéré pour délit d'initié... -+- EB in: Guide du Cabaliste Usenet - Les initiés ont la cote -+-
de faire croire que des choses ne sont pas possibles quand elles le
sont.
Bon, halte aux conneries maintenant. On ne PEUT PAS connaître l'ip de la
machine cliente avec certitude, c'est le protocole qui l'impose, point
barre. Et vous annoncez vous même une fiabilité de merde (80%) pour le
reste (oui, oui, un mec sur 5 qui n'a pas la bonne information, c'est une
fiabilité DE MERDE).
localisation réelle du visiteur avec une précision assez importante. Et
rien n'empeche de laisser une occasion au visiteur de pouvoir préciser
celle-ci si elle n'est pas bonne.
C'est vraiment incroyable d'être amputé du bulbe à ce point là. Ce qu'on
se tue à vous dire, c'est justement que la détection automatique est du
nice-to-have et non pas la solution principale parce que 1) comme vous
l'avouez vous même elle n'est fiable que 4 coups sur 5 et 2)l'utilisateur
doit pouvoir la surcharger manuellement.
fu2 qui va bien. Et je ne vous salue pas.
--
Si la connerie était cotée en bourse,tu serais incarcéré pour
délit d'initié...
-+- EB in: Guide du Cabaliste Usenet - Les initiés ont la cote -+-
de faire croire que des choses ne sont pas possibles quand elles le sont.
Bon, halte aux conneries maintenant. On ne PEUT PAS connaître l'ip de la machine cliente avec certitude, c'est le protocole qui l'impose, point barre. Et vous annoncez vous même une fiabilité de merde (80%) pour le reste (oui, oui, un mec sur 5 qui n'a pas la bonne information, c'est une fiabilité DE MERDE).
localisation réelle du visiteur avec une précision assez importante. Et rien n'empeche de laisser une occasion au visiteur de pouvoir préciser celle-ci si elle n'est pas bonne.
C'est vraiment incroyable d'être amputé du bulbe à ce point là. Ce qu'on se tue à vous dire, c'est justement que la détection automatique est du nice-to-have et non pas la solution principale parce que 1) comme vous l'avouez vous même elle n'est fiable que 4 coups sur 5 et 2)l'utilisateur doit pouvoir la surcharger manuellement.
fu2 qui va bien. Et je ne vous salue pas.
-- Si la connerie était cotée en bourse,tu serais incarcéré pour délit d'initié... -+- EB in: Guide du Cabaliste Usenet - Les initiés ont la cote -+-
