Vous êtes ici : Accueil > Espace de discussion
Discuter:Contenu : heures et dates dans des formats internationaux
Cette page est consacrée aux discussions sur la bonne pratique Contenu : heures et dates dans des formats internationaux.
Vous pouvez :
- créer un nouveau fil de discussion
- répondre à un message à l'aide de son bouton
- répondre à un message en le citant à l'aide de son bouton
- modifier vos propres messages à l'aide de leur bouton
Vous pouvez également consulter les éventuels fils de discussions fermés dans les Archives des discussions
Sujet : format internationaux, format normalisé ou formats non ambigüs ?
Laurent Denis, 18 juin 2005 à 06:10:14 (heure française)
Le libellé aurait besoin d'être précisé. S'agit-il d'indiquer la date :
- dans un format international : lequel ?
- dans un format normalisé : peut-on vraiment exiger l'usage systématique d'ISO 8601 ( YYYY-MM-DD ), qui est tout sauf familier pour les dates affichées ?
- ou plutôt dans un format non ambigü, où l'année, le mois et le jour, quelque-soit leur présentation, sont aisément distingables ? (How do I prepare my web pages to display varying international date formats? et Dates and Time, W3C)
La 3e possibilité semble la plus appropriée pour les dates affichées.
La seconde est évidemment inévitable, pour les dates métadonnées (par exemple, signalées dans des éléments dubin core).
Ne faudrait-il pas commencer par différencier deux bonnes pratiques ?
Monique, 18 juin 2005 à 10:28:15 (heure française)
Une page intéressante à ce sujet [1]
Il y est fait allusion aux propos de Jacob Nielsen qui recommande de toujours indiquer le nom du mois en toute lettre. Ce qui n'est pas toujours possible pour les documents commerciaux, dans lesquels on devrait utiliser la norme ISO 8601
- DATE
(toujours de la plus grande unité temporelle à la plus petite - année, mois, jour, heure, minute, seconde) Comment représenter le premier jour de mai de 2005 ? Norme ISO : 2005-05-01
- DATE+HEURE+MINUTE+SECONDE
Comment représenter le 2 mai 2005, 23 heures, 20 minutes et 50 secondes ? Norme ISO : 2005-05-02T23:20:50
Les deux situations sont clairement différentes, avec des exigences propres.
L'existence de deux bonnes pratiques me semble une bonne idée.
Laurent Denis, 25 juin 2005 à 07:29:58 (heure française)
Proposition de reformulation du libellé pour une bp sur les dates affichées :
L'heure et de la date sont affichées soit:
- dans un format normalisé international, un lien ou une explication de celui-ci étant fournis dans le document.
- dans un format ne prêtant pas à ambiguïté sur son interprétation.
(Les solutions techniques détaillant le choix entre ISO 8601 (avec explications dans la page) et choix d'expliciter et d'identifier les mentions du mois (en le nommant) et de l'année (4 chiffres et non 2))
Proposition de libellé pour une bp dates métadonnées :
L'heure et de la date précisées en métadonnées sont indiquées dans un format normalisé international adapté au format du document et au protocole de communication.
(Ce qui renvoie pour les solutions techniques à ISO 8601 côté code (en (X)HTML) et à RFC 1123 côté serveur (pour HTTP1.1 )
Jérémie Bouillon, 14 juillet 2005 à 17:34:19 (heure française)
Laurent Denis, 18 juin 2005 à 06:10:14 (heure française) avait dit:
- dans un format normalisé : peut-on vraiment exiger l'usage systématique d'ISO 8601 ( YYYY-MM-DD ), qui est tout sauf familier pour les dates affichées ?
J'en doute ; je suis même férocement contre. Ca serait irréaliste, et pas vraiment bien/utile en plus.
À mon sens, sur la problématique des dates, tout existe déjà coté serveur. Une date est descendante d'un élément qui dispose d'un attribut langue (il y a bien une BP qui demande ça quelque part ?) ; on doit se fier à l'attribut langue pour gérer la date.
En clair : la date 01-02-2005 dans une page en-us ne veut pas dire la même chose que dans une page fr-fr.
La bonne pratique serait donc plutôt du coté des UA, qui doivent en tenir compte et informer leurs utilisateurs.
Laurent Denis, 14 juillet 2005 à 20:45:18 (heure française)
À mon sens, sur la problématique des dates, tout existe déjà coté serveur. Une date est descendante d'un élément qui dispose d'un attribut langue (il y a bien une BP qui demande ça quelque part ?) ; on doit se fier à l'attribut langue pour gérer la date. En clair : la date 01-02-2005 dans une page en-us ne veut pas dire la même chose que dans une page fr-fr.
ah... une date anglo-saxonne dans une page en anglais en-us sera-t-elle explicitement une date à lire selon les règles de datation américaine, pour un lecteur français, à supposer qu'il les connaissse ?
Quid des pages en français dans un site en-us ? Ou dans un site québecois ?
D'autre part, en l'absence d'un élément "date" en HTML, il est impossible de demander à l'UA de tenir compte de la langue pour adapter un contenu qui est anonyme :
<p lang="en_us">Last Updated : 01-03-2005</p>
Comment l'UA peu-il saisir la date et agir dessus ? Quelle serait la validité d'un message ajouté (comment ?) par l'UA disant "dans ce paragraphe, s'il y a une date, et que l'auteur a bien fait son travail, elle devrait être au format nord-amérivain. S'il n'y a pas de date, oubliez ce message" ?
Normand, 17 juillet 2005 à 04:30:33 (heure française)
Localisation ou internationalisation?
Si on opte pour internationaliser, alors c'est le schéma AAAA-MM-JJ qui s'impose (pour un format compressé, s'entend; car si on écrit la date au long, il n'y a tout simplement plus de problème).
Si on opte pour localiser, alors... alors bonne chance. Une chose est claire en tous cas, la langue n'y suffira pas.
Laurent Denis, 17 juillet 2005 à 06:54:06 (heure française)
Résumons, pour les dates affichées :
- format YYYY-MM-AA (ISO 8601, normalisé et international) : très différent des habitudes respectives des différents visiteurs. Particulièrement déroutant pour les visiteurs accoutumé à un calendrier spécifique type calendrier bouddhiste.
- localisation et recours aux en-têtes http pour adapter la datation aux préférences de langues exprimées par le navigateur : source de multiples confusions car le navigateur de reflète pas forcément l'utilisateur
- libre choix d'un format local, mais dénué d'ambiguïté : format énonçant le mois en toutes lettres (ou en lettres abrégées non ambigues) et l'année avec 4 chiffres : solution AMHA la plus praticable, mais sous réserve qu'elle soit compatible avec les règles locales du droit commercial. Qui peut confirmer ou infirmer ce point ?
Les solutions techniques peuvent reprendre ces trois possibilités, dès lors que l'intitulé serait reformulé pour éviter la confusion sur le terme "international".
Donc :
Sachant qu'il reste à vérifier si le problème de l'heure n'est pas similaire.
Normand, 18 juillet 2005 à 02:17:39 (heure française)
Laurent Denis, 17 juillet 2005 à 06:54:06 (heure française) avait dit: Sachant qu'il reste à vérifier si le problème de l'heure n'est pas similaire.
Voici une petite mise en situation pour illustrer le type de problème occasionné par le format de l'heure:
— Rendez-vous ici demain à 8 heures. — D'accord.
Si l'interlocuteur est nord-américain, le rendez-vous peut aussi bien avoir été fixé à 8:00 a.m. (8h) qu'à 8:00 p.m. (20h).
Bref, il y a deux formats et il faut pouvoir juger auquel on se réfère. Le format de 12 heures (avec a.m. et p.m. pour distinguer l'avant-midi de l'après-midi) et le format de 24 heures.
Bien sûr, de 13h à 23h, aucune ambiguïté possible.
Laurent Denis, 18 juillet 2005 à 08:52:31 (heure française)
Oui, bien-sûr.
Mais par "problème similaire", je faisais allusion au problème d'un format normalisé strictement recommandable, puisque cela ne s'avérait pas pertinent dans le cas des dates.
Les différents formats normalisés indiquant heures, minutes etc. me semblent très loin d'être recommandables pour l'affichage de contenus ;)
De la même manière que pour les dates, la libellé (et les solutions) devraient donc préciser le point d'ambiguïté : ici la confusion possible matin/après midi.
Ah, je sens que le fuseau horaire va pointer le bout de son nez ;)
Ent fait, s'il y a lieu (et s'il est possible), de définir une bonne pratique sur la non ambiguïté des heures, elle devrait sans doute être séparée de celle-ci.
Jérémie Bouillon, 19 juillet 2005 à 22:47:53 (heure française)
Laurent Denis, 14 juillet 2005 à 20:45:18 (heure française) avait dit: ah... une date anglo-saxonne dans une page en anglais en-us sera-t-elle explicitement une date à lire selon les règles de datation américaine, pour un lecteur français, à supposer qu'il les connaissse ?
Si on écrit en américain, on date en américain. Si l'on lit de l'américain, on lit des dates américaines.
Quid des pages en français dans un site en-us ? Ou dans un site québecois ?
Le texte sera alors en fr-fr. Même dans le cas d'un petit bout de texte français dans une page américaine, la page est déclarée en-us, le texte est déclaré fr-fr.
D'autre part, en l'absence d'un élément "date" en HTML, il est impossible de demander à l'UA de tenir compte de la langue pour adapter un contenu qui est anonyme :
C'est déjà nettement plus vrai. Ca demand eun peu de travail à ce niveau là, à priori un travail humain.
Jérémie Bouillon, 19 juillet 2005 à 22:54:50 (heure française)
Laurent Denis, 17 juillet 2005 à 06:54:06 (heure française) avait dit:Elle va être difficile à mettre en place celle-ci. D'autant que si l'on veut faire du forcing, il faut que la solution proposée soit en béton. Comment gérer la fuseau horaire par exemple : une date peut être fausse même si lisible, car dépendante d'un contexte. On en revient au problème de contexte. Comme pour le format de notation, si je dis 08/07/05 aux gens d'ici, ils sauront tous de quelle date je parle. Sur d'autres sites, ça ne serait plus le cas. C'est donc à mon sens un problème de contexte. Or le seul à avoir les outils pour gérer ce contexte, c'est la machine. Mais elle ne le fait pas (cf la discussion précedente sur la gestion des héritages de langues par les UA). Si l'on veut écrire une BP sur le sujet, à mon sens elle doit être nettement plus générique. Quelque chose autour du sens de : « n'oubliez pas que vous ne pouvez prédire ou contrôler le public d'un site web, et que ce public a certainement une manière de lire les dates et les heures différentes de la votre. Reportez vous à [tel] document pour connaître les autres formats, et mettez en pratique cette connaissance pour éviter la confusion de votre public ».
- libre choix d'un format local, mais dénué d'ambiguïté : format énonçant le mois en toutes lettres (ou en lettres abrégées non ambigues) et l'année avec 4 chiffres : solution AMHA la plus praticable
Laurent Denis, 20 juillet 2005 à 06:05:17 (heure française)
Jérémie Bouillon, 19 juillet 2005 à 22:47:53 (heure française) avait dit: Si on écrit en américain, on date en américain. Si l'on lit de l'américain, on lit des dates américaines. ... Le texte sera alors en fr-fr. Même dans le cas d'un petit bout de texte français dans une page américaine, la page est déclarée en-us, le texte est déclaré fr-fr.
Hum... Pour mettre plus clairement en évidence les difficultés, prenons un exemple :
<p lang="en-us"> 05/02/05: Jeremy Bouillon said <q lang="fr-fr">Le 05/02/05, nous avons...</q> </p>
Le lecteur est-il supposé tenir compte de la langue, connaître les différentes habitudes de datation nationales, et décrypter de lui-même 05/02/05 comme changeant de sens, à quelques mots d'intervalle, pour signifier une fois le 2 mai et la fois suivante le 5 février ? Sans compter que rien ne va lui indiquer, via son navigateur, que la première date est au "format" us, et non au format anglais européen...
Il me semble que nous créons de l'ambiguïté, au lieu de l'éviter, non ?
Maintenant, imaginons que nous fassions intervenir la négociation de contenu sur l'en-tête HTTP Accept-Language envoyé par le navigateur pour formatter les dates à la volée. Dans un lieu public, je suis amené à utiliser une machine dont j'ignore la configuration précise. Il se trouve qu'elle envoit comme HTTP Accept-Langage : en-us. Cela me donne donc :
<p lang="en-us"> 05/02/05: Jeremy Bouillon said <q lang="fr-fr">Le 02/05/05, nous avons...</q> </p>
Encore une fois, rien ne m'indique que, cette fois-ci, les deux dates sont à lire au format US (format dont je peux encore une fois ignorer les subtilités).
Je reviens un peu plus tard sur le même document, depuis une machine envoyant un HTTP Accept-Langage : en-uk, ou fr-fr:
<p lang="en-us"> 02/05/05: Jeremy Bouillon said <q lang="fr-fr">Le 05/02/05, nous avons...</q> </p>
Les dates vont avoir changé, ce qui en soi peut déjà me dérouter considérablement (un copié collé du document effectué la première fois ne correspondra plus au document que j'ai à présent sous les yeux). Et l'obligation de lire selon les règles de l'anglais européen une date dans un document que je sais être en américain me semble assez confusante...
En revanche, ce qui suit ne prête plus à confusion, car aucune gymnastique n'est demandée à l'utilisateur, et le résultat est indépendant du navigateur.
<p lang="en-us"> 2 may 2005: Jeremy Bouillon said <q lang="fr">Le 5 février 2005, nous avons...</q> </p>
Enfin, je propose définitivement de séparer cette BP "jour-mois-années affichées" de celles éventuelles :
- sur le format des dates non affichées (metadata DC, attribut datetime... qui doivent, elles, respecter des formats "machine" bien précis)
- sur le format des heures-minutes
Le affichable (qui vise le contenu textuel et l'attribut title des liens est une simple piste à améliorer. Je ne suis d'ailleurs pas certain que cette mention soit nécessaire, car il n'y a pas conflit avec le fait que les dates <ins datetime="..."> sont soumises aux règles définies par http://www.w3.org/TR/NOTE-datetime, par exemple.
