hcard-faq-fr - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:26:09Z

Replace <entry-title> with {{DISPLAYTITLE:}}

← Older revision		Revision as of 16:26, 18 July 2020
Line 1:		Line 1:
	~~<entry-title>~~FAQ hCard ~~</entry-title>~~		{{DISPLAYTITLE:FAQ hCard }}

	Ceci documente les question fréquemment posées et les réponses (FAQs) à propos de [[hcard-fr\|hCard]]. Pour les FAQs concernant les microformats en général ou sur d'autres microformats, regardez les [[faq-fr\|FAQ microformats]].		Ceci documente les question fréquemment posées et les réponses (FAQs) à propos de [[hcard-fr\|hCard]]. Pour les FAQs concernant les microformats en général ou sur d'autres microformats, regardez les [[faq-fr\|FAQ microformats]].

ChristopheDucamp: /* Comment marquez-vous une organisation */ hcard-authoring-fr#hCards_pour_les_organisations

2009-11-11T15:42:44Z

Comment marquez-vous une organisation: hcard-authoring-fr#hCards_pour_les_organisations

← Older revision		Revision as of 15:42, 11 November 2009
Line 118:		Line 118:
	</source>		</source>

	Voir aussi : [[hcard-authoring-fr#~~hCards_Organisation~~\|publication hCard :hCards Organisations]].		Voir aussi : [[hcard-authoring-fr#hCards_pour_les_organisations\|publication hCard :hCards Organisations]].

	=== Que veut dire FN ===		=== Que veut dire FN ===

ChristopheDucamp: [fr: sync'd with original -to be reviewed]

2009-11-11T15:28:26Z

[fr: sync'd with original -to be reviewed]

Show changes

Brian: Reverted edits by BasdrOnelr (Talk) to last version by ChristopheDucamp

2008-12-16T19:41:44Z

Reverted edits by BasdrOnelr (Talk) to last version by ChristopheDucamp

Show changes

BasdrOnelr: tadelricgete

2008-12-16T18:29:18Z

tadelricgete

Show changes

ChristopheDucamp: sync'd

2007-09-03T06:36:55Z

sync'd

← Older revision		Revision as of 06:36, 3 September 2007
Line 330:		Line 330:
	</nowiki></pre>		</nowiki></pre>

	~~Some have suggested having the~~ IMG ~~alt~~ (~~and other such textual~~ alternatives) <em>~~always~~</em> ~~be part of surrounding property values~~, ~~and while this may initially seem appealing~~, ~~this was deliberately rejected at the creation of~~ hCard ~~to give publishers more control~~.		Certains ont suggéré de faire que le alt IMG (et d'autres alternatives textuelles équivalentes) fasse <em>toujours</em> partie des valeurs de propriété environnantes, et que même si ce peut initialement sembler séduisant, ceci fût délibérément rejeté lors de la création de hCard pour donner plus de contrôle aux éditeurs.

	~~In addition all too often there is~~ "~~garbage~~" (~~or just extra unwanted text~~) in alt ~~attributes for a variety of publisher reasons~~, ~~and that extraneous text would pollute otherwise clean property values in numerous existing~~ sites.		En outre il y a aussi bien trop souvent du "détritus" (ou simplement du texte non voulu) dans les attributs alt pour une quantité de raisons dépendant des auteurs, et ce texte étranger polluerait autrement les valeurs de propriétés propres dans de nombreux sites existantes.

	~~Thus only if the publisher explicitly~~ <em>~~wants~~</em> ~~the text from the alt attribute do they add the~~ respective ~~class value to get it~~.		De ce fait, seulement si l'auteur <em>veut</em> le texte extrait de l'attribut, il ajoutera la valeur de classe respective pour l'obtenir.

	~~Finally~~, ~~it is~~ <em>~~simpler~~</em> ~~and more predictable for publishers if they know that for~~ images ~~and other such URL related elements~~ (a, ~~object~~, etc.) ~~that whether they are specifying a~~ URL ~~property~~ (~~like~~ "email", "photo", "url", etc.) ~~or a text property~~ (~~like~~ "fn", "nickname", etc.) ~~in either case~~ <em>~~directly~~</em> ~~specifying the property on the element is the way to do it~~.		Pour finir, il est <em>plus simple</em> et plus prévisible pour les auteurs, s'il savent que pour les images et autres éléments URLs en rapport (a, objet, etc) que s'ils spécifient une propriété URL (comme "email", "photo", "url", etc.) ou une propriété texte (comme "fn", "nickname", etc.) dans tous les cas <em>directement</em>, spécifier la propriété sur l'élément est la façon de faire ça.

	=== Comment marquer chaque ADR avec un GEO ===		=== Comment marquer chaque ADR avec un GEO ===
Line 344:		Line 344:
	* Plus long : il y a deux raisons pour ne pas marquer une ADR avec un GEO :		* Plus long : il y a deux raisons pour ne pas marquer une ADR avec un GEO :
	** Tout d'abord et le plus important, ADR et GEO ne veulent pas dire la même chose, par conséquent vous NE DEVEZ PAS simplement marquer une ADR avec un GEO.		** Tout d'abord et le plus important, ADR et GEO ne veulent pas dire la même chose, par conséquent vous NE DEVEZ PAS simplement marquer une ADR avec un GEO.
	** ~~Second~~, ~~even if you did consider them to be the same~~ information, ~~you shouldn't do so for~~ DRY (Don't Repeat Yourself) ~~reasons~~. ~~Duplicating~~ information ~~increases the probability inconsistent~~ information ~~due to one copy being updated without the other being updated~~.		** Deuxièmement, si vous les considériez vraiment comme étant la même information, vous ne devriez pas faire ainsi pour des raisons de DRY (Don't Repeat Yourself). La duplication d'information accroît la probabilité d'information incohérente du fait d'une copie étant mise à jour sans que l'autre ne soit mise à jour.
	* ~~Details~~: ADR ~~and~~ GEO ~~represent different semantics~~, an ADR ~~representing~~ <em>an</em> ~~address of the~~ hCard ~~object~~ (~~thus~~ hCards ~~may have multiple~~ ADRs), ~~whereas a~~ GEO ~~if present represents~~ <em>~~the~~</em> ~~physical location of the~~ hCard ~~object~~ (~~thus an~~ hCard ~~may have at most a single~~ GEO). ~~In addition~~, ~~they represent a different data~~ <em>types</em>, ~~i.e. an~~ ADR ~~represents an area of land which is a polygon~~ (~~or perhaps a space in a~~ building ~~which is a polyhedron~~), ~~whereas a~~ GEO ~~only represents a single~~ point.<p>~~Attempting to duplicate an~~ ADR ~~with a~~ GEO ~~property with nearby~~/~~representative coordinates~~ (~~e.g. as you might derive by using an online mapping~~ service) ~~is also undesirable from the~~ DRY ~~perspective for all the usual duplicates getting out of sync problems~~.</p>		* Détails : ADR et GEO représentent différentes sémantiques, une ADR représentant <em>une</em> adresse de l'object hCard (de ce fait les hCards peuvent avoir plusieurs ADRs), tandis qu'un GEO s'il est présent représente <em>le</em> lieu physique de l'objet hCard (de ce fait une hCard peut avoir au plus un unique GEO). En outre, ils représentent des <em>types</em> de données différentes, à savoir une ADR représente un domaine de terrain qui est un polygone (ou peut-être un espace dans un building qui est un polyedre), tandis qu'un GEO ne représente uniquement qu'un point unique. <p>Essayer de dupliquer une ADR avec une propriété GEO avec des coordonnées avoisinantes/représentatives (par ex que vous pourriez dériver en utilisant un service en ligne de cartographie) est aussi non désirable du fait de la perspective DRY pour tous les doublons habituels obtenus lors des problèmes de non synchronisation.</p>

	<h2> Pages Apparentées </h2>		<h2> Pages Apparentées </h2>
	{{hcard-related-pages-fr}}		{{hcard-related-pages-fr}}

ChristopheDucamp at 23:29, 2 September 2007

2007-09-02T23:29:12Z

← Older revision		Revision as of 23:29, 2 September 2007
Line 307:		Line 307:
	Vous pouvez utiliser la valeur alt de <code><nowiki><img></nowiki></code> afin de spécifier n'importe quelle valeur de propriété texte (à savoir pas une URL) en plaçant le nom de classe <em>directement</em> sur l'élément <code><nowiki><img></nowiki></code> lui-même. D'autres alterantives d'éléments sont documentées dans [[hcard-fr#Lisible_par_Humain_vs._Machine\|hCard : Lisible par les Humains vs lisible par les machines]].		Vous pouvez utiliser la valeur alt de <code><nowiki><img></nowiki></code> afin de spécifier n'importe quelle valeur de propriété texte (à savoir pas une URL) en plaçant le nom de classe <em>directement</em> sur l'élément <code><nowiki><img></nowiki></code> lui-même. D'autres alterantives d'éléments sont documentées dans [[hcard-fr#Lisible_par_Humain_vs._Machine\|hCard : Lisible par les Humains vs lisible par les machines]].

	Voici un exemple de le produire FAUX et la façon correcte d'y aller. L'espace ~~blan~~ a été ajouté pour la lisibilité :		Voici un exemple de le produire FAUX et la façon correcte d'y aller. L'espace blanc a été ajouté pour la lisibilité :

	<h4>~~WRONG~~</h4>		<h4>FAUX</h4>

	<pre style="background:#FEE"><nowiki>		<pre style="background:#FEE"><nowiki>
Line 319:		Line 319:
	</nowiki></pre>		</nowiki></pre>

	<h4>~~RIGHT~~</h4>		<h4>BON</h4>
	~~Note the moving of the class names~~ "fn" ~~and~~ "photo" ~~from the~~ <nowiki><a></nowiki> ~~to the~~ <nowiki><img></nowiki>		Remarquez la migration des noms de classes "fn" et "photo" à partir du <nowiki><a></nowiki> vers l'<nowiki><img></nowiki>

	<pre style="background:#EFE"><nowiki>		<pre style="background:#EFE"><nowiki>
Line 338:		Line 338:
	Finally, it is <em>simpler</em> and more predictable for publishers if they know that for images and other such URL related elements (a, object, etc.) that whether they are specifying a URL property (like "email", "photo", "url", etc.) or a text property (like "fn", "nickname", etc.) in either case <em>directly</em> specifying the property on the element is the way to do it.		Finally, it is <em>simpler</em> and more predictable for publishers if they know that for images and other such URL related elements (a, object, etc.) that whether they are specifying a URL property (like "email", "photo", "url", etc.) or a text property (like "fn", "nickname", etc.) in either case <em>directly</em> specifying the property on the element is the way to do it.

	=== ~~How do I mark up each~~ ADR ~~with a~~ GEO ===		=== Comment marquer chaque ADR avec un GEO ===
	''~~I have an~~ hCard ~~with multiple addresses~~. ~~How do I mark-up each~~ ADR ~~with a~~ GEO?''		''J'ai une hCard avec plusieurs adresses. Comment marquer chaque ADR avec un GEO ?''

	* ~~Short answer~~: ~~don't~~. ~~See also~~ [[hcard-faq#~~Can_a_GEO_be_inferred_from_an_ADR_in_an_hCard~~\|~~Can a~~ GEO ~~be inferred from an~~ ADR ~~in an~~ hCard]].		* Réponse rapide : ne le faite pas. Voir aussi [[hcard-faq-fr#Est-ce_que_GEO_peut_.C3.AAtre_inf.C3.A9r.C3.A9_.C3.A0_partir_d.27un_ADR_dans_une_hCard\|Est-ce qu'un GEO peut être inféré à partir d'une ADR dans une hCard]].
	* ~~Longer~~: ~~There are two reasons not to mark-up an~~ ADR ~~with a~~ GEO.		* Plus long : il y a deux raisons pour ne pas marquer une ADR avec un GEO :
	** ~~First and most importantly~~, ADR ~~and~~ GEO ~~don't mean the same thing~~, ~~therefore you MUST NOT simply mark-up an~~ ADR ~~with a~~ GEO.		** Tout d'abord et le plus important, ADR et GEO ne veulent pas dire la même chose, par conséquent vous NE DEVEZ PAS simplement marquer une ADR avec un GEO.
	** Second, even if you did consider them to be the same information, you shouldn't do so for DRY (Don't Repeat Yourself) reasons. Duplicating information increases the probability inconsistent information due to one copy being updated without the other being updated.		** Second, even if you did consider them to be the same information, you shouldn't do so for DRY (Don't Repeat Yourself) reasons. Duplicating information increases the probability inconsistent information due to one copy being updated without the other being updated.
	* Details: ADR and GEO represent different semantics, an ADR representing <em>an</em> address of the hCard object (thus hCards may have multiple ADRs), whereas a GEO if present represents <em>the</em> physical location of the hCard object (thus an hCard may have at most a single GEO). In addition, they represent a different data <em>types</em>, i.e. an ADR represents an area of land which is a polygon (or perhaps a space in a building which is a polyhedron), whereas a GEO only represents a single point.<p>Attempting to duplicate an ADR with a GEO property with nearby/representative coordinates (e.g. as you might derive by using an online mapping service) is also undesirable from the DRY perspective for all the usual duplicates getting out of sync problems.</p>		* Details: ADR and GEO represent different semantics, an ADR representing <em>an</em> address of the hCard object (thus hCards may have multiple ADRs), whereas a GEO if present represents <em>the</em> physical location of the hCard object (thus an hCard may have at most a single GEO). In addition, they represent a different data <em>types</em>, i.e. an ADR represents an area of land which is a polygon (or perhaps a space in a building which is a polyhedron), whereas a GEO only represents a single point.<p>Attempting to duplicate an ADR with a GEO property with nearby/representative coordinates (e.g. as you might derive by using an online mapping service) is also undesirable from the DRY perspective for all the usual duplicates getting out of sync problems.</p>

ChristopheDucamp: sync'd -> section à traduire

2007-09-02T23:17:52Z

sync'd -> section à traduire

@@ Line 12: / Line 12: @@
 Envisagez d'utiliser un texte plus amical, comme '''Ajouter au Carnet d'Adresses'''.
 Il y a beaucoup d'exemples de cela dans la page des [[hcard-examples-in-wild-fr|exemples hCard]]. Remarquez que le [http://feeds.technorati.com/contacts/ service Technorati Contacts Feed] est basé sur le "X2V" open source XSLT produit par Brian Suda et d'autres. Si vous voulez, vous pouvez installer vous-même X2V et faire fonctionner votre propre convertisseur local.
 === Devrais-je utiliser ADDRESS pour les hCards ===
@@ Line 41: / Line 40: @@
 De cette façon vous n'aurez pas à vous soucier des duplicatas de données provenant d'ailleurs. - mettes simplement à jour le contenu de votre page de contact balisée avec hCard et tous ceux qui recevront votre vCard recevront automatiquement l'information de contact mise à jour sans que vous n'ayez à vous soucier de mettre à jour un fil séparé.
-=== Comment supporter une URL vCard existante ===
+===Comment supporter une URL vCard existante ===
 ''J'ai déjà une vCard que je maintiens à jour. Je ne veux pas changer quelque référence vers elle, car cela pourrait casser quelque chose d'autre, que puis-je faire ?''
 * Vous pouvez utiliser .HTACCESS pour récrire les liens vers votre vCArd vers un service web qui convertit une page dynamiquement vers la vCard, pour faire ça vous avez besoin d'ajouter quelque chose de similaire à votre fichier .htaccess
@@ Line 92: / Line 91: @@
 === Est-ce que GEO peut être inféré à partir d'un ADR dans une hCard ===
 ''Puis-je automatiquement ajouter GEO à partir d'une adresse au moment de transformer une hCard en vCard s'il n'est pas présent ?''
-* Non, une adresse représente une construction qui est un polygône, tandis qu'un GEO ne représente qu'un point unique
+* Non, une adresse représente un domaine de terre qui est un polygône (ou peut-être un espace dans une construction qui est un polyèdre), alors qu'un GEO ne représente qu'un point unique. Ils ne sont pas équivalents.
 ===X2V ne convertit pas l'email avec un nom en texte clair ===
@@ Line 301: / Line 300: @@
 </div>
 </nowiki></pre>
 <h2> Pages Apparentées </h2>
 {{hcard-related-pages-fr}}

ChristopheDucamp at 23:04, 2 September 2007

2007-09-02T23:04:26Z

← Older revision		Revision as of 23:04, 2 September 2007
Line 29:		Line 29:

	* Le nom de classe "url" est nécessaire pour distinguer explicitement les hyperliens qui sont des éléments URL pour la hCard, des autres hyperliens qui peuvent être apparentés à l'item ou autrement dans le même élément conteneur mais qui ne devraient pas être inclus dans la hCard. Les liens communs qui peuvent apparaître dans le document mais ne pas être l'information de contact sont des liens apparentées avec l'action (données de téléchargement, ajout à liste d'amis, etc.) des hyperliens de contact (email, messagerie interne de site, autocomposeurs), tout comme les hyperliens vers les photos ou tous les autres hyperliens au hasard qui surviennent à être à l'intérieur de la hCard.		* Le nom de classe "url" est nécessaire pour distinguer explicitement les hyperliens qui sont des éléments URL pour la hCard, des autres hyperliens qui peuvent être apparentés à l'item ou autrement dans le même élément conteneur mais qui ne devraient pas être inclus dans la hCard. Les liens communs qui peuvent apparaître dans le document mais ne pas être l'information de contact sont des liens apparentées avec l'action (données de téléchargement, ajout à liste d'amis, etc.) des hyperliens de contact (email, messagerie interne de site, autocomposeurs), tout comme les hyperliens vers les photos ou tous les autres hyperliens au hasard qui surviennent à être à l'intérieur de la hCard.


			=== j'ai un problème à servir un fichier vcf vCard ===
			''J'ai un problème à servir un fichier .vcf de vCard qui a l'information de ma page /contact/ provenant de mon site web. Par exemple les navigateurs ne font qu'afficher le texte du fichier vcf de la vCard au lieu de la télécharger.

			Le chose la plus facile à faire et pour le support (tout spécialement avec de plus en plus de consommateurs de vcar ici sur leurs propres territoires) est de faire ainsi : :

			# [[hcard-authoring-fr\|Ajouter du marquage hCard]] à votre page de /contact/ là où vous avez déjà votre informatin de contact visible dans le contenu. Voir aussi [http://microformats.org/code/hcard/creator/ hCard creator] un outil qui est utile pour aprendre comment fonctionne le marquage hCard.
			# Changez le lien vers votre fichier vCard .vdf pour : <nowiki>http://feeds.technorati.com/contacts/http://votresiteweb .exemple.com/contact/</nowiki>

			De cette façon vous n'aurez pas à vous soucier des duplicatas de données provenant d'ailleurs. - mettes simplement à jour le contenu de votre page de contact balisée avec hCard et tous ceux qui recevront votre vCard recevront automatiquement l'information de contact mise à jour sans que vous n'ayez à vous soucier de mettre à jour un fil séparé.

	=== Comment supporter une URL vCard existante ===		=== Comment supporter une URL vCard existante ===

ChristopheDucamp: sync in progress

2007-09-02T22:55:48Z

sync in progress

← Older revision		Revision as of 22:55, 2 September 2007
Line 18:		Line 18:

	Oui l'élément <address> est plus sémantique, mais il est ''trop'' spécifiquement sémantique pour la plupart des usages hCard. L'élément pauvrement nommé <address> veut véritablement signifier <info-contact-pour-cette-page-web>. La [http://www.la-grange.net/w3c/html4.01/struct/global.html#h-7.5.6 définition HTML4 de l'élément ADDRESS] dit qu'il est utilisé pour "pour fournir les informations de contact du document ou d'une partie essentielle de celui-ci, comme un formulaire." Par conséquent <address> ne devrait être utilisé pour hCard SEULEMENT SI cette hCard représente l'information de contact pour la page ou une partie essentielle de celle-ci. Un exemple d'un tel usage est sur [http://tantek.com/log/ le blog de Tantek]. Un autre moyen de dire ceci sont les deux déclarations suivantes : Chaque <address> sur une page DEVRAIT être une hCard. Mais toute hCard ne devrait pas être une <address>. <br/>En résumé, N'utilisez '''PAS''' <address> pour baliser les adressses en général. Ne l'utilisez que pour baliser l'information de contact pour la page (ou la partie essentielle de celle-ci), et si vous faites ainsi, utilisez-le pour baliser l'information de contact "entière" (via <address class="vcard">), pas simplement l'adresse du contact.		Oui l'élément <address> est plus sémantique, mais il est ''trop'' spécifiquement sémantique pour la plupart des usages hCard. L'élément pauvrement nommé <address> veut véritablement signifier <info-contact-pour-cette-page-web>. La [http://www.la-grange.net/w3c/html4.01/struct/global.html#h-7.5.6 définition HTML4 de l'élément ADDRESS] dit qu'il est utilisé pour "pour fournir les informations de contact du document ou d'une partie essentielle de celui-ci, comme un formulaire." Par conséquent <address> ne devrait être utilisé pour hCard SEULEMENT SI cette hCard représente l'information de contact pour la page ou une partie essentielle de celle-ci. Un exemple d'un tel usage est sur [http://tantek.com/log/ le blog de Tantek]. Un autre moyen de dire ceci sont les deux déclarations suivantes : Chaque <address> sur une page DEVRAIT être une hCard. Mais toute hCard ne devrait pas être une <address>. <br/>En résumé, N'utilisez '''PAS''' <address> pour baliser les adressses en général. Ne l'utilisez que pour baliser l'information de contact pour la page (ou la partie essentielle de celle-ci), et si vous faites ainsi, utilisez-le pour baliser l'information de contact "entière" (via <address class="vcard">), pas simplement l'adresse du contact.

			* L'élément <code><nowiki><address></nowiki></code> est plus sémantique, mais il est ''trop'' spécifiquement sémantique pour la plupart des usages hCard. L'élément pauvrement nommé <code><nowiki><address></nowiki></code> signifie vraiment <info-contact-pour-cette-page-web>. La [http://www.la-grange.net/w3c/html4.01/struct/global.html#h-7.5.6 définition HTML4 de l'élément ADDRESS] dit qu'il est utilisé pour "pour fournir les informations de contact du document ou d'une partie essentielle de celui-ci, comme un formulaire." Par conséquent <address> ne devrait être utilisé pour hCard SEULEMENT SI cette hCard représente l'information de contact pour la page ou une partie essentielle de celle-ci. Un exemple d'un tel usage est sur [http://tantek.com/log/ le blog de Tantek]. Un autre moyen de dire ceci est la double déclaration : Chaque <address> sur une page DEVRAIT être une hCard. Mais toute hCard ne devrait pas être une <code><nowiki><address></nowiki></code>. <br />Pour faire court, <strong>N'UTILISEZ PAS</strong> <code><nowiki><address></nowiki></code> pour marquer les adresses physiques/rues/mailing en général. Ne l'utilisez uniquement que pour marquer l'<em>information de contact pour la page</em> (ou une partie majeure de celle-ci), et au moment de faire ainsi, utilisez la pour marquer l'information de contact <em>complète</em> (via <address class="vcard">), pas juste une adresse physique/rue/mailing pour le contact.

	=== Pourquoi la propriété adr est-elle nécessaire ===		=== Pourquoi la propriété adr est-elle nécessaire ===
Line 288:		Line 290:
	</div>		</div>
	</nowiki></pre>		</nowiki></pre>


	<h2> Pages Apparentées </h2>		<h2> Pages Apparentées </h2>
	{{hcard-related-pages-fr}}		{{hcard-related-pages-fr}}