hcard-issues-fr: Difference between revisions
Jump to navigation
Jump to search
([fr: sync'd with english version - translation in progress]) |
m (→2008: typo) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 8: | Line 8: | ||
Pour toutes les questions en rapport avec la spécification vCard elle même, voir [[vcard-errata-fr|vcard errata]] et [[vcard-suggestions-fr|vcard suggestions]]. | Pour toutes les questions en rapport avec la spécification vCard elle même, voir [[vcard-errata-fr|vcard errata]] et [[vcard-suggestions-fr|vcard suggestions]]. | ||
Voir aussi les autres [[issues-fr|problématiques]]. | |||
== Problématiques == | == Problématiques == | ||
== problématiques fermées == | == problématiques fermées == | ||
Voir [[hcard-issues-resolved-fr|hcard-problématiques-résolues]] | |||
== problématiques résolues == | == problématiques résolues == | ||
Voir [[hcard-issues-resolved-fr|hcard-problématiques-résolues]] | |||
=== | == problématiques == | ||
<span id="Problématiques">Ajoutez ici les nouvelles problématiques</span> en '''bas''' de la liste en copiant et collant le [[hcard-issues-fr#Gabarit|Gabarit]]. Relancez svp vers les problématiques résolues/rejetées avec de la nouvelle information plutôt que de soumettre à nouveau de telles problématiques. Les ajouts de problématiques doublons seront révoquées. | |||
=== 2006 === | === 2006 === | ||
* {{OpenIssue-fr}} 2006-10-21 soulevée par [[User:AndyMabbett|Andy Mabbett]] | * {{OpenIssue-fr}} 2006-10-21 soulevée par [[User:AndyMabbett|Andy Mabbett]] | ||
*# ''Il devrait y avoir quelque manière de dire que l'URL d'une hCard ou hCalendar est l'URL de la page elle-même, sans avoir à inclure un lien redondant et dommageable en accessibilité vers cette page, sur la page elle-même.'' | *# ''Il devrait y avoir quelque manière de dire que l'URL d'une hCard ou hCalendar est l'URL de la page elle-même, sans avoir à inclure un lien redondant et dommageable en accessibilité vers cette page, sur la page elle-même.'' | ||
| Line 378: | Line 36: | ||
=== 2007 === | === 2007 === | ||
* {{OpenIssue-fr}} 2007-01-26 soulevée par [[User::JamesCraig|JamesCraig]]. | * {{OpenIssue-fr}} 2007-01-26 soulevée par [[User::JamesCraig|JamesCraig]]. | ||
*# les valeurs 'type' RFC2426 ne peuvent pas être localisées/internationalisées dans hCard. Dans l'exemple en-desous, il n'y a pas de solution pour baliser la version Espagnole avec un type de 'home' parce que les valeurs RFC2426 sont définies en anglais. <strong>abbr-design-pattern</strong> suggérerait d'utiliser abbr, mais 'Casa' n'est pas une forme abrégée de 'home', par consquent la version actuellement recommandée (en dessous) n'est pas valide. <pre><nowiki> | *# les valeurs 'type' RFC2426 ne peuvent pas être localisées/internationalisées dans hCard. Dans l'exemple en-desous, il n'y a pas de solution pour baliser la version Espagnole avec un type de 'home' parce que les valeurs RFC2426 sont définies en anglais. <strong>abbr-design-pattern</strong> suggérerait d'utiliser abbr, mais 'Casa' n'est pas une forme abrégée de 'home', par consquent la version actuellement recommandée (en dessous) n'est pas valide. <pre><nowiki> | ||
| Line 403: | Line 60: | ||
*#Comment devrions-nous gérer les [http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates Styles Anciens et Styles Nouveaux de Dates] (par ex. le calendrier Julian vs. Gregorian), dans DoB ? Par exemple, [http://en.wikipedia.org/wiki/Boris_Pasternak Boris Pasternak], né le "10 February [O.S. January 29] 1890". Est-ce que la spec hCard devrait spécifier New Style , en utilisant le <code>abbr-design-pattern</code> si nécessaire : <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>? | *#Comment devrions-nous gérer les [http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates Styles Anciens et Styles Nouveaux de Dates] (par ex. le calendrier Julian vs. Gregorian), dans DoB ? Par exemple, [http://en.wikipedia.org/wiki/Boris_Pasternak Boris Pasternak], né le "10 February [O.S. January 29] 1890". Est-ce que la spec hCard devrait spécifier New Style , en utilisant le <code>abbr-design-pattern</code> si nécessaire : <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>? | ||
===2008=== | |||
*{{OpenIssue-fr}} <span id="tel-type-lang">2008-01-09 migrée à partir de vcard-suggestions</span> | |||
*#Nous ne pouvons spas avoir un nom de type générique du fait que nous devons le localiser en français. Aussi pour nous, le numéro de téléphone professionnel est : <nowiki><div class="tel"><span class="type">Travail</span> : <span class="value">0321596224</span></div></nowiki>. Comment fera un robot pour reconnaître ce type ? Nous ne pouvons pas spécifier tous les types dans chaque langue dans la spécification. C'est pourquoi je pense que quelque chose comme ça serait mieux : <nowiki>Travail : <span class="telwork">0321596224</span></nowiki> SVP, n'utilisez des attributs de classe et id UNIQUEMENT pour les spécifications microformats ! les #cdata et #data XML sont localisés ! Merci ! | |||
== Gabarit == | == Gabarit == | ||
{{issues-format-fr}} | |||
== Pages Apparentées == | == Pages Apparentées == | ||
{{hcard-related-pages-fr}} | {{hcard-related-pages-fr}} | ||
Latest revision as of 14:30, 3 February 2008
Problématiques hCard
Ce sont des problématiques soulevées à propos de hCard avec divers degrés de mérite. Par conséquent, quelques problématiques sont REJETEES pour un bon nombre de raisons évidentes (mais encore documentées ici dans le cas où elles reviendraient à surgir), et d'autres qui contiennent des discussions plus longues. Quelques problématiques peuvent être ACCEPTEES et peut-être provoquer des modifications ou des explications améliorées dans la spécification.
IMPORTANT : Lisez svp les hCard FAQ et la page hCard problématiques résolues avant de donner quelque réaction ou de soulever quelques problématiques car vos réactions/problématiques peuvent être déjà résolues/répondues.
Les problématiques proposées peuvent (et le seront probablement) être éditées et récrites pour une meilleure concision, clarté, rationnalité et une expression aussi neutre que possible. Ecrivez bien vos problématiques. — Tantek
Pour toutes les questions en rapport avec la spécification vCard elle même, voir vcard errata et vcard suggestions.
Voir aussi les autres problématiques.
Problématiques
problématiques fermées
Voir hcard-problématiques-résolues
problématiques résolues
Voir hcard-problématiques-résolues
problématiques
Ajoutez ici les nouvelles problématiques en bas de la liste en copiant et collant le Gabarit. Relancez svp vers les problématiques résolues/rejetées avec de la nouvelle information plutôt que de soumettre à nouveau de telles problématiques. Les ajouts de problématiques doublons seront révoquées.
2006
- problématique ouverte ! 2006-10-21 soulevée par Andy Mabbett
- Il devrait y avoir quelque manière de dire que l'URL d'une hCard ou hCalendar est l'URL de la page elle-même, sans avoir à inclure un lien redondant et dommageable en accessibilité vers cette page, sur la page elle-même.
- Très souvent je vois "une" page web accessible avec plusieurs URLs différentes. Typicament 1 URL est l'URL "préféré", attendue pour avoir une longue durée de vie. Parfois d'autres URLs sont des URLs "commodes" qui peuvent avoir été liées dans le passé, mais sont attendues pour s'en aller sous peu, qui pointent vers le même fichier (la "dernière version"). Puis il existe des URLs 'archive" qui présentent une copie exacte de cette page web comme elle est apparue il y a quelque temps dans le passé. Je pense que nous voudrons toujours utiliser l'URL préféré, peu importe laquelle de ces URLs sur lequels nous puissions tomber en premier -- ainsi l'URL n'est en fait pas redondante. (Comment est-ce "dommageable en accessiblité" pour une page de se lier sur elle-même ? Pourriez vous expliquer ou ajouter un lien vers une explication ?) --DavidCary 17:44, 5 Apr 2007 (PDT)
- "Comment est-ce "dommageable en accessiblité" pour une page de se lier sur elle-même ? Pourriez vous expliquer ou ajouter un lien vers une explication ?" - L'utilisateur novice clique sur un lien ; rien (il semble) n'apparaît. Répété à l'infini, jusqu'à ce que l'utilisateur quitte le site pour faire quelque chose d'autre. Andy Mabbett 02:43, 6 Apr 2007 (PDT)
- R: ACCEPTEE THEORIQUE. Alors que je tens à être d'accord avec les problématiques/lignes de conduite d'accessibilité notées ici en théorie, pour faire que ce soit un problème du vrai monde de plus grande prioriét, nous avons besoin de documentation d'exemples dans la jungle d'une hcard ou d'un événement hCalendar qui soit l'URL de la page elle-même, de façon que nous puissions utiliser ces exemples pour informer un brainstorming vers une solution. Tantek 15:11, 10 Apr 2007 (PDT)
- Les exemples dans la jungle où l'URL d'une hCard est l'URL de la page elle-même :
- La page Pipettes sur SXSW 2007 (1 parmi les 1000+ groupes). Il n'y a pas de liens vers la page elle-même sur la page pour marquer avec class="url". De ce fait ce serait joli d'avoir un moyen pour la hcard des pipettes d'indiquer que la page elle-même est l'URL de la hCard.
- Exemples dans la jungle où l'URL d'un évènement hCalendarest l'URL de la page elle-même :
- La page The Pipettes at La Zona Rosa à SXSW 2007 (1 parmi les 1000+ concerts). concerts, oui, même page que la page pour The Pipettes l'org). Il n'y a pas de liens vers la page elle-même sur la page pour marquage avec class="url". De ce fait ce serait joli d'avoir un moyen pour l'événement hCalendar pour The Pipettes at La Zona Rosa d'indiquer que la page elle-même est l'URL pour l'évènement hCalendar.
- Ceci est aussi une hReview problématique et de tout autre microformat qui a une propriété "url". Les exemples où l'URL d'un *item* potentiel hReview est l'URL de la page elle-même :
- Snow Crash (Bantam Spectra Book) (Paperback) on Amazon (millions d'items/produits potentiels en hReview avec des critiques sur leurs pages item).
- Les exemples dans la jungle où l'URL d'une hCard est l'URL de la page elle-même :
- Très souvent je vois "une" page web accessible avec plusieurs URLs différentes. Typicament 1 URL est l'URL "préféré", attendue pour avoir une longue durée de vie. Parfois d'autres URLs sont des URLs "commodes" qui peuvent avoir été liées dans le passé, mais sont attendues pour s'en aller sous peu, qui pointent vers le même fichier (la "dernière version"). Puis il existe des URLs 'archive" qui présentent une copie exacte de cette page web comme elle est apparue il y a quelque temps dans le passé. Je pense que nous voudrons toujours utiliser l'URL préféré, peu importe laquelle de ces URLs sur lequels nous puissions tomber en premier -- ainsi l'URL n'est en fait pas redondante. (Comment est-ce "dommageable en accessiblité" pour une page de se lier sur elle-même ? Pourriez vous expliquer ou ajouter un lien vers une explication ?) --DavidCary 17:44, 5 Apr 2007 (PDT)
- Il devrait y avoir quelque manière de dire que l'URL d'une hCard ou hCalendar est l'URL de la page elle-même, sans avoir à inclure un lien redondant et dommageable en accessibilité vers cette page, sur la page elle-même.
2007
- problématique ouverte ! 2007-01-26 soulevée par [[User::JamesCraig|JamesCraig]].
- les valeurs 'type' RFC2426 ne peuvent pas être localisées/internationalisées dans hCard. Dans l'exemple en-desous, il n'y a pas de solution pour baliser la version Espagnole avec un type de 'home' parce que les valeurs RFC2426 sont définies en anglais. abbr-design-pattern suggérerait d'utiliser abbr, mais 'Casa' n'est pas une forme abrégée de 'home', par consquent la version actuellement recommandée (en dessous) n'est pas valide.
<span class="tel" xml:lang="en">
<span class="type">Home</span> (<span class="type">pref</span>erred): <span class="value">+1.415.555.1212</span>
</span>
- REJETEE. TROP PEU D'INFORMATION. Fournissez svp l'URL précise vers la déclaration spécifique sur le forum de discussion accessify qui déclare qu'utiliser abbr n'est pas valide. Fournissez aussi une URL précise vers un exemple du *vrai *monde* dans la jungle (à l'inverse d'un cas de test artificiellement construit) d'une hCard non anglaise qui tente de spécifier l'information type RFC2426 sur une propriété "tel" et échoue à faire ainsi.
- ROUVERTE ET CLARIFIEE (retiré aussi la référence Accessify extraite de [la mention originale]).
- Bien que cela ait d'abord émergé sur la page accessibilité, ce n'est pas une problématique d'accessibilité. C'est une problématique de sémantique HTML pour l'internationalisation.
abbr[title]devrait être une forme augmentée de contenusabbr, dans la même langue. - Il existe des exemples du vrai monde en non anglais dans l'ensemencement actuel Mac OS 10.5. Cet exemple de code illustre suffisamment ce point.
- Laissez SVP la clarification comme telle même si vous sentez que vous devez la REJETER de NOUVEAU (ajoutez, ne reinitialisez pas). Mes points initiaux ont été perdus quand ils ont été retirés du contexte et migrés ici. -[[User::JamesCraig|JamesCraig]]
- Bien que cela ait d'abord émergé sur la page accessibilité, ce n'est pas une problématique d'accessibilité. C'est une problématique de sémantique HTML pour l'internationalisation.
- problématique ouverte ! 2007-03-19 soulevée par [[User::ChristinaHope|Christina Hope]]
- Est-ce que Microsoft Outlook 2003 permet l'utilisation de la propriété "role" ? Je l'ai ajoutée à toutes mes hCards et cela n'apparaît pas. Suis-je en train de faire quelque erreur ?
- URL? (si aucune URL vers un exemple démonstratif n'ets fourni dans un an, elle sera fermée comme REJETE INFORMATION INSUFFISANTE.)
- problématique ouverte ! 2007-03-31 soulevée par Andy Mabbett
- Le schéma WGS84 utilisé par défaut par
geone demeurera pas valide pour toujours. Heureusement, l'extension proposée geo extension, initialement destinée pour les coordonnées lunaires/Martiennes, fournit aussi une facilité pour la spécification, qui soulagera ce problème. Andy Mabbett 13:00, 31 Mar 2007 (PDT)- Notez aussi le schéma 89 à venir European Terrestrial Reference System (Voir aussi Etrs89 on Wikipedia. Andy Mabbett 03:11, 5 Apr 2007 (PDT)
- Le schéma WGS84 utilisé par défaut par
- problématique ouverte ! 2007-04-19 soulevée par Andy Mabbett
- Comment devrions-nous gérer les Styles Anciens et Styles Nouveaux de Dates (par ex. le calendrier Julian vs. Gregorian), dans DoB ? Par exemple, Boris Pasternak, né le "10 February [O.S. January 29] 1890". Est-ce que la spec hCard devrait spécifier New Style , en utilisant le
abbr-design-patternsi nécessaire : <abbr title="1890-02-10">29 January 1890</abbr>?
- Comment devrions-nous gérer les Styles Anciens et Styles Nouveaux de Dates (par ex. le calendrier Julian vs. Gregorian), dans DoB ? Par exemple, Boris Pasternak, né le "10 February [O.S. January 29] 1890". Est-ce que la spec hCard devrait spécifier New Style , en utilisant le
2008
- problématique ouverte ! 2008-01-09 migrée à partir de vcard-suggestions
- Nous ne pouvons spas avoir un nom de type générique du fait que nous devons le localiser en français. Aussi pour nous, le numéro de téléphone professionnel est : <div class="tel"><span class="type">Travail</span> : <span class="value">0321596224</span></div>. Comment fera un robot pour reconnaître ce type ? Nous ne pouvons pas spécifier tous les types dans chaque langue dans la spécification. C'est pourquoi je pense que quelque chose comme ça serait mieux : Travail : <span class="telwork">0321596224</span> SVP, n'utilisez des attributs de classe et id UNIQUEMENT pour les spécifications microformats ! les #cdata et #data XML sont localisés ! Merci !
Gabarit
SVP, utilisez ce format (copiez et collez ceci à la fin de la liste pour ajouter vos problématiques ; remplacez ~~~ par un lien externe si vous préférez) pour rendre compte des problématiques ou réactions :
<div class="vevent">
* {{OpenIssue-fr}} <span class="summary vcard"><span class="dtstart">AAAA-MM-JJ</span> soulevée par <span class="fn">~~~</span></span>
<div class="description">
*# Voici la première problématique/réaction que je rencontre.
*# Voici la seconde problématique/réaction que je rencontre.
</div>
</div>
Pages Apparentées
- hCard
- hCard anti-sèche - propriétés hCard
- hCard creator (réactions) - créez votre propre hCard.
- hCard publication - apprenez comment ajouter du balisage hCard à votre information de contact existante.
- hCard exemples - exemple d'usage de différentes classes dans la hCard.
- hCard exemples dans la jungle - une liste mise à jour de sites web qui utilisent les hCards.
- Profils utilisateurs supportant hCard - sites avec des profils utilisateurs marqués avec hCard - un exemple très commun.
- hCard FAQ - si vous avez quelque question à propos de hCard, regardez ici.
- implémentations hCard - les sites web ou outils qui génèrent ou parsent les hCards.
- hcard-implied-fr - une proposition pour créer une méthode alternative de baliser une hCard simple
- hCard parsage - détails des normes sur la manière de parser les hCards.
- hCards et pages - distinctions sémantiques entre différentes hCards sur une page, et comment identifier chacune
- hcard-interface-utilisateur - techniques et problématiques autour des interfaces-utilisateurs pour éditer, publier et afficher des hCards.
- hCard profile - le profil XMDP pour hCard
- hCard propriétés singulières - une explication de la liste des propriétés singulières dans hCard.
- hCard tests - une page wiki avec des véritables hCards embarquées pour essayer le parsage.
- hCard soutien - encourager d'autres à utiliser hCard
- hCard "to do" - travaux à faire
La spécification hCard est un chantier en cours. Au fur et à mesure que des aspects supplémentaires sont discutés, compris et écrits, ils seront rajoutés. Ces idées, problématiques et questions sont maintenues sur des pages distinctes.
- hCard brainstorming - brainstorms et autres explorations en rapport avec hCard. Voir aussi geo brainstorming.
- hcard-parsing-brainstorming - brainstorming spécifique au parsage de hCard
- geo brainstorming
- hCard réactions - feedback général (contrairement aux problématiques spécifiques).
- hCard problématiques - problématiques spécifiques à la spécification.
- vCard errata - corrections à la spécification vCard, sous jacentes à hCard.
- vCard suggestions - améliorations suggérées à la spécification vCard.