vcard-suggestions-fr - Revision history

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

2008-12-20T18:46:25Z

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

Show changes

DomraCricd: alcorvar

2008-12-19T22:29:57Z

alcorvar

Show changes

ChristopheDucamp: /* Language */

2008-02-03T14:40:49Z

Language

← Older revision		Revision as of 14:40, 3 February 2008
Line 97:		Line 97:

	====Language====		====Language====
	(par ex. note) si toutes les propriétés ne devraient pas avoir un attribut "language", similaire à <code>lang</code> en HTML de façon à ce que les agents puissent déterminer comment restituer, et si applicable, les prononcer.		(par ex. note) si toutes les propriétés ne devraient pas avoir un attribut "language", similaire à <code>lang</code> en HTML de façon à ce que les agents puissent déterminer comment restituer, et si applicable, les prononcer.

	== Suggestions de Nouvelles Propriétés ==		== Suggestions de Nouvelles Propriétés ==

ChristopheDucamp: [fr: translated section]

2008-02-03T14:38:51Z

[fr: translated section]

← Older revision		Revision as of 14:38, 3 February 2008
Line 1:		Line 1:
	<h1> suggestions vCard </h1>		<h1> suggestions vCard </h1>
			{{TOC-right}}
	En tant que résultat de l'expérience d'utiliser [[hcard-fr\|hCard]] pour baliser les personnes, organisations et informations de contacts en général sur de [[hcard-examples-in-wild-fr\|véritables sites web du monde entier]], nous avons découvert quelques aspects de la {{RFC2426-fr}} vCard qui pourraient être améliorés. De ce fait, nous documentons les suggestions pour améliorer ici la vCard au fur et à mesure que nous en trouvons, organisé selon les propriétés {{RFC2426-fr}} avec une section "new" pour les nouvelles propriétés.		En tant que résultat de l'expérience d'utiliser [[hcard-fr\|hCard]] pour baliser les personnes, organisations et informations de contacts en général sur de [[hcard-examples-in-wild-fr\|véritables sites web du monde entier]], nous avons découvert quelques aspects de la {{RFC2426-fr}} vCard qui pourraient être améliorés. De ce fait, nous documentons les suggestions pour améliorer ici la vCard au fur et à mesure que nous en trouvons, organisé selon les propriétés {{RFC2426-fr}} avec une section "new" pour les nouvelles propriétés.

Line 15:		Line 15:

	=== <span id="3.3.1_TEL_Type_Definition">TEL Type Definition</span> === <!--span préserve l'ancienne ID-->		=== <span id="3.3.1_TEL_Type_Definition">TEL Type Definition</span> === <!--span préserve l'ancienne ID-->

	:'''Voir : {{RFC2426-fr}} section 3.3.1		:'''Voir : {{RFC2426-fr}} section 3.3.1

	* Le "type" pour "TEL" manque d'une option "textphone" (pour les terminaux utilisés par exemple par des personnes qui sont sourdes ou ont des difficultés d'élocution. Exemple : [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)]. Ce peut être bien de considérer d'ajouter une valeur "textphone" au "type" pour "TEL".		* Le "type" pour "TEL" manque d'une option "textphone" (pour les terminaux utilisés par exemple par des personnes qui sont sourdes ou ont des difficultés d'élocution. Exemple : [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)]. Ce peut être bien de considérer d'ajouter une valeur "textphone" au "type" pour "TEL".
	** +0 Tantek : je pense que repenser la taxonomie des types TEL est mérité, mais ne suis pas certain si cela vaut la peine de faire grandir la taxonomie existante limitée ou au lieu de cela permettre à l'utilisateur d'avoir des types TEL définis et de ce fait permettre une évolution naturelle d'une folksnonomie des types TEL.		** +0 Tantek : je pense que repenser la taxonomie des types TEL est mérité, mais ne suis pas certain si cela vaut la peine de faire grandir la taxonomie existante limitée ou au lieu de cela permettre à l'utilisateur d'avoir des types TEL définis et de ce fait permettre une évolution naturelle d'une folksnonomie des types TEL.
Line 33:		Line 31:

	=== <span id="3.3.2_EMAIL_Type_Definition">EMAIL Type Definition</span> === <!--span préserve l'ID précédente-->		=== <span id="3.3.2_EMAIL_Type_Definition">EMAIL Type Definition</span> === <!--span préserve l'ID précédente-->

	:'''Voir : {{RFC2426-fr}} section 3.3.2'''		:'''Voir : {{RFC2426-fr}} section 3.3.2'''

Line 49:		Line 46:

	====Initiales====		====Initiales====

	N" (Voir sous propriété {{RFC2426-fr}} section 3.1.2) ; pour les personnes dont le prénom n'est pas déclaré (par ex. "A. N. Autre", dont le prénom pourrait être, disons, "Adrien" ou "Norbert") ; afin de permettre des valeurs comme :		N" (Voir sous propriété {{RFC2426-fr}} section 3.1.2) ; pour les personnes dont le prénom n'est pas déclaré (par ex. "A. N. Autre", dont le prénom pourrait être, disons, "Adrien" ou "Norbert") ; afin de permettre des valeurs comme :

Line 59:		Line 55:

	au lieu du plus guindé :		au lieu du plus guindé :


	<pre>		<pre>
Line 74:		Line 69:
	</pre>		</pre>

	~~and~~:		et :

	<pre>		<pre>
Line 107:		Line 102:
	<!--triées par ordre alphabétique-->		<!--triées par ordre alphabétique-->

	===~~Alternative dates~~===		===Dates Alternatives===
			Pour les chiffres historiques où aucune naissance ou date de décès ne son connus une paire de dates "'''flourished'''" ou "'''flourished from'''"+"'''flourished to'''" serait utile.
	~~For historic figures, where no birth and/ or death~~ dates ~~are known a~~ "'''flourished'''" ~~date, or~~ "'''flourished from'''"+"'''flourished to'''" ~~pair, would be useful~~.

	~~In genealogy~~, ~~some people have no recorded birth~~ date, ~~but their "'''baptised'''"~~ date ~~is known.~~		En généalogie, quelques personnes n'ont pas de date de naissance enregistrée, mais leur date de baptême est connue

	===<span id="~~Date of Death evidence~~">~~Deceased~~</span>=== ~~<!--span preserves former ID-->~~		===<span id="Evidence date de décès">Décès</span>===
	~~aka~~ "date of death"		aussi connue comme "date of death"
	*~~See~~ [[hcard-date-of-death]]		*voir [[hcard-date-of-death-fr\|hcard-date-of-death]]

	===Genre===		===Genre===

ChristopheDucamp: [sync'd]

2008-02-03T14:31:55Z

[sync'd]

Show changes

ChristopheDucamp: [fr: sync'd with english version]

2008-01-05T16:20:33Z

[fr: sync'd with english version]

@@ Line 19: / Line 19: @@
 === 3.3.2 EMAIL Définition Type ===
 * Le "type" pour "EMAIL" manque de distinction pour différentes types d'email, par ex. '''work''' ou '''home'''.
 == Suggestions pour de Nouvelles Propriétés ==
@@ Line 28: / Line 42: @@
 ====Evidence du Genre====
-*la plupart des sites de réseaux sociaux (voir [[profile-examples-fr|exemples de profils]]) publient le genre de l'individu.
+Voir [[gender-examples-fr|genre-exemples]].
-*beaucoup de pages publien l'information implicite du genre, pas facilement parsables par les machines, en utilisant des noms  (Andrew, Andrea), de titres (Mr, Mrs, Miss), des relations (mari, frère), des pronoms (he, she), etc. Voir aussi [[genealogy-brainstorming-fr|genealogy-brainstorming]]
-===Décès ===
+* Beaucoup de pages publient de l'information de genre implicite, pas facilement parsable par une machine - en utilisant des noms (André, Andrée), des titres (Mr, Mrs, Miss), des relations (mari, frère), des pronoms (il, elle), etc. Ajoutez svp de telles pages avec leurs URLs spécifiques et citations de l'information explicite, et les genres implicites sur la page  [[gender-examples-fr#exemples|genre-examples]].
-====Evidence Date de Décès====
+===Décès ===
-*Toutes les entrées +56,000 du [http://www.oxforddnb.com/public/lotw/ Oxford Dictionnaire National des Biographies]
+*Voir [[hcard-date-of-death-fr|hcard-date-de-décès]]
 ===Messagerie Instantanée===
 *Voir [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770].
@@ Line 55: / Line 63: @@
 ===Elévation===
 *Voir [[geo-extension-elevation-fr|geo-extension-elevation]]
 == Suggestions pour gérer les encodages ==
@@ Line 60: / Line 92: @@
 Pour aller plus loin, ceux qui créent des lecteurs de vCard seraient encouragés à supporter les fichiers vCard .vcf à démarrer par une séquence UTF-8 BOM. Si lest trois premiers bits du fichier sont 0xEF 0xBB 0xBF, le fichier texte est encodé UTF-8, et le lecteur de vCard devrait supposer qu'UTF-8 est le défaut. Malheureusement beaucoup de lecteurs échouent aujourd'hui à reconnaître le UTF-8 BOM et voient le fichier comme une vCard corrompue.
 ==Note==

ChristopheDucamp: /* Suggestions pour gérer les encodages */ traduction

2007-08-05T08:30:26Z

Suggestions pour gérer les encodages: traduction

← Older revision		Revision as of 08:30, 5 August 2007
Line 57:		Line 57:

	== Suggestions pour gérer les encodages ==		== Suggestions pour gérer les encodages ==
	~~The~~ vCard ~~standard specifies that~~ US-ASCII ~~is assumed to be the encoding in the~~ absence ~~of a~~ MIME content type header ~~or a~~ CHARSET ~~parameter that indicates otherwise~~. ~~This was an unfortunate choice~~. vCard .vcf ~~files stored on a~~ local ~~filesystem do not contain a~~ MIME ~~header and the only way to reliably use an encoding other than~~ ASCII ~~is to tag each field with the~~ "CHARSET=" ~~label~~. ~~This makes the~~ vCard ~~stream more complicated than necessary~~. ~~This could be simplified by a revision of the~~ standard ~~that specifies~~ UTF-8 ~~as the default encoding~~. ~~This could work safely with existing~~ vCard .vcf ~~files~~, ~~which do not contain a~~ MIME ~~content header~~. ~~The first~~ vCard ~~VERSION field would be the same encoded as either~~ ASCII or UTF-8, ~~so readers could easily determine which encoding to default to.~~		Le standard vCard spécifie que l'US-ASCII est supposé être l'encodage en l'absence d'un "MIME content type header" ou d'un paramètre CHARSET qui indiquerait autre chose. Ceci a été un choix malheureux. les fichiers vCard .vcf stockés sur un système de fichiers local ne contiennent pas de header MIME et les seul moyen d'utiliser en toute confiance un autre encodage que l'ASCII est de marquer chaque champ avec le label "CHARSET=". Ceci rend le flux vCard plus compliqué que nécessaire. Ceci pourrait être simplifié par une révision du standard qui spécifie UTF-8 comme l'encodage par défaut. Ceci pourrrait fonctionner en toute sécurité avec les fichiers existant vCard vcf, qui ne contiennent pas de header MIME de contenu. Le premier champ VERSION vCard serait le même encodé soit sous ASCII ou UTF-8, ainsi les lecteurs pourraient facilement déterminer quel est l'encodage par défaut.

	Furthermore, those creating vCard readers should be encouraged to support vCard .vcf files that begin with a UTF-8 BOM sequence. If the first three bytes of the file are 0xEF 0xBB 0xBF, the text file is UTF-8 encoded, and the vCard reader should assume UTF-8 is the default. Unfortunately many readers today fail to recognize the UTF-8 BOM and view the file as a corrupt vCard.

			Pour aller plus loin, ceux qui créent des lecteurs de vCard seraient encouragés à supporter les fichiers vCard .vcf à démarrer par une séquence UTF-8 BOM. Si lest trois premiers bits du fichier sont 0xEF 0xBB 0xBF, le fichier texte est encodé UTF-8, et le lecteur de vCard devrait supposer qu'UTF-8 est le défaut. Malheureusement beaucoup de lecteurs échouent aujourd'hui à reconnaître le UTF-8 BOM et voient le fichier comme une vCard corrompue.

	==Note==		==Note==

ChristopheDucamp: sync'd

2007-08-05T08:22:45Z

sync'd

← Older revision		Revision as of 08:22, 5 August 2007
Line 3:		Line 3:
	En tant que résultat de l'expérience d'utiliser [[hcard-fr\|hCard]] pour baliser les personnes, organisations et informations de contacts en général sur de [[hcard-examples-in-wild-fr\|véritables sites web du monde entier]], nous avons découvert quelques aspects de la RFC 2426 vCard qui pourraient être améliorés. De ce fait, nous documentons les suggestions pour améliorer ici la vCard au fur et à mesure que nous en trouvons, organisé selon le numéro de section de RFC 2426 pour amélioration des propriétés actuelles, et une section "new" pour les nouvelles propriétés.		En tant que résultat de l'expérience d'utiliser [[hcard-fr\|hCard]] pour baliser les personnes, organisations et informations de contacts en général sur de [[hcard-examples-in-wild-fr\|véritables sites web du monde entier]], nous avons découvert quelques aspects de la RFC 2426 vCard qui pourraient être améliorés. De ce fait, nous documentons les suggestions pour améliorer ici la vCard au fur et à mesure que nous en trouvons, organisé selon le numéro de section de RFC 2426 pour amélioration des propriétés actuelles, et une section "new" pour les nouvelles propriétés.

	; Auteurs : Tantek Çelik, [[User:AndyMabbett\|Andy Mabbett]]		; Auteurs :
			: [[User:Tantek\|Tantek Çelik]]
			: [[User:AndyMabbett\|Andy Mabbett]]
	; Traduction en cours : [[Christophe Ducamp]]		; Traduction en cours : [[Christophe Ducamp]]
	== Suggestions pour les Propriétés Existantes ==		== Suggestions pour les Propriétés Existantes ==
Line 9:		Line 11:
	Les suggestions pour l'amélioration pourrait inclure de nouvelles fonctionnalités et d'autre modifications majeurs à la spécification, organisées sous des titres qui reflètent les numéros de section de la RFC 2426 vCard et des titres. Pour les erreurs de documentation, corrections, errata pour la vCard, reportez-vous svp à [[vcard-errata-fr\|vcard-errata]].		Les suggestions pour l'amélioration pourrait inclure de nouvelles fonctionnalités et d'autre modifications majeurs à la spécification, organisées sous des titres qui reflètent les numéros de section de la RFC 2426 vCard et des titres. Pour les erreurs de documentation, corrections, errata pour la vCard, reportez-vous svp à [[vcard-errata-fr\|vcard-errata]].

	=== 3.3.1 TEL Type ~~Definition~~ ===		=== 3.3.1 TEL Définition Type===
	* Le "type" pour "TEL" manque d'une option "textphone" (pour les terminaux utilisés par exemple par des personnes qui sont sourdes ou ont des difficultés d'élocution. Exemple : [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)]. Ce peut être bien de considérer d'ajouter une valeur "textphone" au "type" pour "TEL".		* Le "type" pour "TEL" manque d'une option "textphone" (pour les terminaux utilisés par exemple par des personnes qui sont sourdes ou ont des difficultés d'élocution. Exemple : [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)]. Ce peut être bien de considérer d'ajouter une valeur "textphone" au "type" pour "TEL".
	** +0 Tantek : je pense que repenser la taxonomie des types TEL est mérité, mais ne suis pas certain si cela vaut la peine de faire grandir la taxonomie existante limitée ou au lieu de cela permettre à l'utilisateur d'avoir des types TEL définis et de ce fait permettre une évolution naturelle d'une folksnonomie des types TEL.		** +0 Tantek : je pense que repenser la taxonomie des types TEL est mérité, mais ne suis pas certain si cela vaut la peine de faire grandir la taxonomie existante limitée ou au lieu de cela permettre à l'utilisateur d'avoir des types TEL définis et de ce fait permettre une évolution naturelle d'une folksnonomie des types TEL.
	** +1 [[User:AndyMabbett\|Andy Mabbett]] : Il existe un nombre limité de types. Notez aussi la problématique cell vs mobile.		** +1 [[User:AndyMabbett\|Andy Mabbett]] : Il existe un nombre limité de types. Notez aussi la problématique cell vs mobile.
			* Le "type" pour "TEL" manque d'une option "freephone". Ce pourrait être bien de considérer d'ajouter une valeur "freephone" au "type" pour "TEL". Généralement les numéros de freephone ne sont pas accessibles à partir de l'étranger ainsi cela pourrait aider les parseurs à quelque chose ?

			=== 3.3.2 EMAIL Définition Type ===
			* Le "type" pour "EMAIL" manque de distinction pour différentes types d'email, par ex. '''work''' ou '''home'''.

	== Suggestions pour de Nouvelles Propriétés ==		== Suggestions pour de Nouvelles Propriétés ==

	===Genre ===		===Genre ===
	*Il n'existe pas de ~~propriété~~ de Carte pour le genre. Un contournement : ajouter le tag/catégorie/mot-clé "male", "female", etc. Voir aussi la [[hcard-faq-fr#Comment_le_genre_est_repr.C3.A9sent.C3.A9\|première discussion]].		*Il n'existe pas de propriétés de Carte pour le genre. Un contournement : ajouter le tag/catégorie/mot-clé "male", "female", etc. Voir aussi la [[hcard-faq-fr#Comment_le_genre_est_repr.C3.A9sent.C3.A9\|première discussion]].
	** -1 Tantek : Je pense que les tags/categories sont suffisamment bien à cette heure.		** -1 Tantek : Je pense que les tags/categories sont suffisamment bien à cette heure.
	** +1 [[User:AndyMabbett\|Andy Mabbett]] : les tags sont souvent non appropriés, comme selon la discussion citée.		** +1 [[User:AndyMabbett\|Andy Mabbett]] : les tags sont souvent non appropriés, comme selon la discussion citée.

			====Evidence du Genre====
			*la plupart des sites de réseaux sociaux (voir [[profile-examples-fr\|exemples de profils]]) publient le genre de l'individu.
			*beaucoup de pages publien l'information implicite du genre, pas facilement parsables par les machines, en utilisant des noms (Andrew, Andrea), de titres (Mr, Mrs, Miss), des relations (mari, frère), des pronoms (he, she), etc. Voir aussi [[genealogy-brainstorming-fr\|genealogy-brainstorming]]

	===Décès ===		===Décès ===
Line 27:		Line 37:
	** +1 for date-of-death [[User:CiaranMc\|Ciaran McNulty]] : la date-de-décès est une information utile dans quelques applications (tout particulièrement la généalogie).		** +1 for date-of-death [[User:CiaranMc\|Ciaran McNulty]] : la date-de-décès est une information utile dans quelques applications (tout particulièrement la généalogie).
	** -1 pour le flag 'deceased' [[User:CiaranMc\|Ciaran McNulty]] : le tag peut couvrir cette sorte de tag binaire.		** -1 pour le flag 'deceased' [[User:CiaranMc\|Ciaran McNulty]] : le tag peut couvrir cette sorte de tag binaire.


			====Evidence Date de Décès====
			*Toutes les entrées +56,000 du [http://www.oxforddnb.com/public/lotw/ Oxford Dictionnaire National des Biographies]
			La plupart des biographies sur Wikipedia des personnes décédées, par ex. [http://en.wikipedia.org/wiki/Walt_Disney Walt Disney], [http://en.wikipedia.org/wiki/John_Bonham John Bonham] (la plupart de celles-ci sur Wikipedia-EN utilisent déjà la hCard)[http://www.findagrave.com/ Find-a-Grave] par ex. [http://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=680 Karl Marx], [http://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=676 Chico Marx]
			*Utilisée dans les nécrologies, par ex. [http://www.westmidlandbirdclub.com/obituaries/norris.htm Tony Norris (WMBC)] ; [http://www.guardian.co.uk/obituaries/story/0,,1725211,00.html Ivor Cutler (Guardian)] ; [http://www.britarch.ac.uk/BA/ba8/ba8obit.html Grahame Clark (British Archaeology)]
			*Utilisée sur les pages des mémoriaux de guerre, par ex. [http://tinyurl.com/2ddlvq Captain Ronald Wilkinson]
			*Utilisée dans les biographies par ex [http://www.biography.com/ Biography.com] ([http://www.biography.com/impressionists/monet-bio.jsp Camille Monet])
			*[http://en.wikipedia.org/wiki/List_of_saints Liste de saints sur Wikipedia]

	===Messagerie Instantanée===		===Messagerie Instantanée===
	*Voir [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770].		*Voir [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770].

			===Subject differentiator===
			L'utilisation de "fn" et "fn org" fair la différence entre les hCards de personnes et d'autres entités, mais nous avons peut-être besoin d'un différenciateur plus approfondi, disons entres les organisations et les lieux (y compris les immeubles, les divisions gouvernementales, les points de parcours, etc.) à déterminer à un certain niveau de granularité. [[User:AndyMabbett\|Andy Mabbett]] 14:30, 11 Jul 2007 (PDT)

	===Elévation===		===Elévation===
	*Voir [[geo-elevation~~-examples~~-fr\|geo-elevation~~-exemples~~]]		*Voir [[geo-extension-elevation-fr\|geo-extension-elevation]]

	== Suggestions pour gérer les encodages ==		== Suggestions pour gérer les encodages ==
Line 41:		Line 63:

	==Note==		==Note==
	Le 2006~~-11-24~~, Paul Hoffman de l'[http://www.imc.org/ Internet Mail Consortium], responsable du développement et de la promotion du standard vCard, a écrit en réponse à un email provenant de [[User:AndyMabbett\|Andy Mabbett]] l'informant sur sa page web :		Le 24 novembre 2006, Paul Hoffman de l'[http://www.imc.org/ Internet Mail Consortium], responsable du développement et de la promotion du standard vCard, a écrit en réponse à un email provenant de [[User:AndyMabbett\|Andy Mabbett]] l'informant sur sa page web :
	<blockquote>		<blockquote>
	Il n'y a presque pas d'intérêt à réviser le standard vCard. Ceci du fait d'un manque d'énergie, pas d'un manque de bonnes suggestions.		Il n'y a presque pas d'intérêt à réviser le standard vCard. Ceci du fait d'un manque d'énergie, pas d'un manque de bonnes suggestions.
	</blockquote>		</blockquote>

			Néanmoins, on pourra regarder en anglais [[events/2007-09-18-calconnect-vcard-workshop]] pour un événement avec la modification de la vCard à l'ordre du jour.

	== Voir aussi ==		== Voir aussi ==

	* [[vcard-errata-fr\|vCard errata]]		* [[vcard-errata-fr\|vCard errata]]
	* [[hcard-fr\|hCard]]		* [[hcard-fr\|hCard]]
	* [http://www.imc.org/imc-vcard/ vCard mailing list] - un endroit pour soulever ces problématiques et où des problématiques similaires peuvent être trouvées.		* [http://www.imc.org/imc-vcard/ vCard mailing list] - un endroit pour soulever ces problématiques et où des problématiques similaires peuvent être trouvées.

ChristopheDucamp at 11:49, 14 April 2007

2007-04-14T11:49:18Z

← Older revision		Revision as of 11:49, 14 April 2007
Line 10:		Line 10:

	=== 3.3.1 TEL Type Definition ===		=== 3.3.1 TEL Type Definition ===

	* Le "type" pour "TEL" manque d'une option "textphone" (pour les terminaux utilisés par exemple par des personnes qui sont sourdes ou ont des difficultés d'élocution. Exemple : [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)]. Ce peut être bien de considérer d'ajouter une valeur "textphone" au "type" pour "TEL".		* Le "type" pour "TEL" manque d'une option "textphone" (pour les terminaux utilisés par exemple par des personnes qui sont sourdes ou ont des difficultés d'élocution. Exemple : [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)]. Ce peut être bien de considérer d'ajouter une valeur "textphone" au "type" pour "TEL".
	** +0 Tantek : je pense que repenser la taxonomie des types TEL est mérité, mais ne suis pas certain si cela vaut la peine de faire grandir la taxonomie existante limitée ou au lieu de cela permettre à l'utilisateur d'avoir des types TEL définis et de ce fait permettre une évolution naturelle d'une folksnonomie des types TEL.		** +0 Tantek : je pense que repenser la taxonomie des types TEL est mérité, mais ne suis pas certain si cela vaut la peine de faire grandir la taxonomie existante limitée ou au lieu de cela permettre à l'utilisateur d'avoir des types TEL définis et de ce fait permettre une évolution naturelle d'une folksnonomie des types TEL.
Line 34:		Line 33:
	===Elévation===		===Elévation===
	*Voir [[geo-elevation-examples-fr\|geo-elevation-exemples]]		*Voir [[geo-elevation-examples-fr\|geo-elevation-exemples]]

			== Suggestions pour gérer les encodages ==
			The vCard standard specifies that US-ASCII is assumed to be the encoding in the absence of a MIME content type header or a CHARSET parameter that indicates otherwise. This was an unfortunate choice. vCard .vcf files stored on a local filesystem do not contain a MIME header and the only way to reliably use an encoding other than ASCII is to tag each field with the "CHARSET=" label. This makes the vCard stream more complicated than necessary. This could be simplified by a revision of the standard that specifies UTF-8 as the default encoding. This could work safely with existing vCard .vcf files, which do not contain a MIME content header. The first vCard VERSION field would be the same encoded as either ASCII or UTF-8, so readers could easily determine which encoding to default to.

			Furthermore, those creating vCard readers should be encouraged to support vCard .vcf files that begin with a UTF-8 BOM sequence. If the first three bytes of the file are 0xEF 0xBB 0xBF, the text file is UTF-8 encoded, and the vCard reader should assume UTF-8 is the default. Unfortunately many readers today fail to recognize the UTF-8 BOM and view the file as a corrupt vCard.

ChristopheDucamp at 11:47, 14 April 2007

2007-04-14T11:47:45Z

← Older revision		Revision as of 11:47, 14 April 2007
Line 22:		Line 22:
	** +1 [[User:AndyMabbett\|Andy Mabbett]] : les tags sont souvent non appropriés, comme selon la discussion citée.		** +1 [[User:AndyMabbett\|Andy Mabbett]] : les tags sont souvent non appropriés, comme selon la discussion citée.

	===~~Deceased~~ ===		===Décès ===
	*Il n'y a pas moyen de baliser une personne comme étant décédée - soit par une marque "deceased" ou date-de-décès. Un moyen de contourner : ajouter le tag/category "deceased". Voir aussi [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007324.html la liste de discussion sur le tag pour 'deceased']		*Il n'y a pas moyen de baliser une personne comme étant décédée - soit par une marque "deceased" ou date-de-décès. Un moyen de contourner : ajouter le tag/category "deceased". Voir aussi [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007324.html la liste de discussion sur le tag pour 'deceased']
	** -1 Tantek : je pense que les tags/categories sont bien suffisantes à cette heure.		** -1 Tantek : je pense que les tags/categories sont bien suffisantes à cette heure.
Line 28:		Line 28:
	** +1 for date-of-death [[User:CiaranMc\|Ciaran McNulty]] : la date-de-décès est une information utile dans quelques applications (tout particulièrement la généalogie).		** +1 for date-of-death [[User:CiaranMc\|Ciaran McNulty]] : la date-de-décès est une information utile dans quelques applications (tout particulièrement la généalogie).
	** -1 pour le flag 'deceased' [[User:CiaranMc\|Ciaran McNulty]] : le tag peut couvrir cette sorte de tag binaire.		** -1 pour le flag 'deceased' [[User:CiaranMc\|Ciaran McNulty]] : le tag peut couvrir cette sorte de tag binaire.

			===Messagerie Instantanée===
			*Voir [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770].

			===Elévation===
			*Voir [[geo-elevation-examples-fr\|geo-elevation-exemples]]


	==Note==		==Note==