hcard-feedback-fr - Revision history

ChristopheDucamp: /* 2007 */ typo

2008-01-27T06:43:32Z

2007: typo

← Older revision		Revision as of 06:43, 27 January 2008
Line 11:		Line 11:

	=== 2007 ===		=== 2007 ===
	* Toutes les réactions hCard en date du 2007-04-27 ont été résolues, et les problématiques résolues ont été migrées sur la section [[hcard-issues-fr#problématiques_résolues\|hCard problématiques ~~résolue~~]] ~~section~~. Remarquez qu'il existe encore quelques [[hcard-issues-fr#problématiques\|problémtiques en attente]]. [[User:Tantek\|Tantek]] 08:46, 14 Dec 2007 (PST)		* Toutes les réactions hCard en date du 2007-04-27 ont été résolues, et les problématiques résolues ont été migrées sur la section [[hcard-issues-fr#problématiques_résolues\|hCard problématiques résolues]]. Remarquez qu'il existe encore quelques [[hcard-issues-fr#problématiques\|problémtiques en attente]]. [[User:Tantek\|Tantek]] 08:46, 14 Dec 2007 (PST)

	=== 2008 ===		=== 2008 ===

ChristopheDucamp at 06:43, 27 January 2008

2008-01-27T06:43:05Z

← Older revision		Revision as of 06:43, 27 January 2008
Line 1:		Line 1:
	<h1> hCard réactions </h1>		<h1> hCard réactions </h1>
			{{TOC-right}}
	Les réactions générales à propos de [[hcard-fr\|hCard]] peuvent être fournies ici, et le(s) éditeur(s) feront de leur mieux pour essayer de se plier et d'accomoder à de telles réactions. Plus la réaction est spécifique, plus il y aura de chance qu'elle soit prise en compte. Pour les problématiques spécifiques avec la spécification (à l'inverse des problèmes généraux et réactions), utilisez svp la page [[hcard-issues-fr\|hCard problématiques]].		Les réactions générales à propos de [[hcard-fr\|hCard]] peuvent être fournies ici, et le(s) éditeur(s) feront de leur mieux pour essayer de se plier et d'accomoder à de telles réactions. Plus la réaction est spécifique, plus il y aura de chance qu'elle soit prise en compte. Pour les problématiques spécifiques avec la spécification (à l'inverse des problèmes généraux et réactions), utilisez svp la page [[hcard-issues-fr\|hCard problématiques]].

	'''IMPORTANT''' : Lisez SVP '''avant''' la page [[hcard-faq-fr\|hCard FAQ]] en donnant toute réaction ou pour soulever toutes les problématiques car vos réactions/problématiques peuvent avoir été déjà résolues ou traitées.		'''IMPORTANT''' : Lisez SVP '''avant''' la page [[hcard-faq-fr\|hCard FAQ]] en donnant toute réaction ou pour soulever toutes les problématiques car vos réactions/problématiques peuvent avoir été déjà résolues ou traitées.

	La réaction peut (et sera probablement) éditée et récrite pour une meilleure concision, clarté ~~rationnalité~~ et sous un point de vue aussi neutre que possible. Utilisez le gabarit fourni et ajoutez votre réaction à la fin de la section Réaction. Ecrivez bien votre réaction. — [http://tantek.com/log/ Tantek]		La réaction peut (et sera probablement) éditée et récrite pour une meilleure concision, clarté, rationalité et sous un point de vue aussi neutre que possible. Utilisez le gabarit fourni et ajoutez votre réaction à la fin de la section Réaction. Ecrivez bien votre réaction. — [http://tantek.com/log/ Tantek]

	~~__TOC__~~

	== Réactions ==		== Réactions ==
			Ajoutez-ici vos réactions, par ordre séquentiel anté-chronologique :

	* 2006-11-15 soulevée par [http://lachy.id.au/ Lachy] dans [irc://freenode/whatwg #whatwg] (un canal IRC sur [http://freenode.net/ freenode] à propos de [http://whatwg.org/ The WHATWG]).		=== 2007 ===
	*~~# ''Je pense que la totalité de la spécification [[hcard-fr\|~~hCard~~]] a besoin d'être restructurée.''~~		* Toutes les réactions hCard en date du 2007-04-27 ont été résolues, et les problématiques résolues ont été migrées sur la section [[hcard-issues-fr#problématiques_résolues\|hCard problématiques résolue]] section. Remarquez qu'il existe encore quelques [[hcard-issues-fr#problématiques\|problémtiques en attente]]. [[User:Tantek\|Tantek]] 08:46, 14 Dec 2007 (PST)
	*# ''C'est incroyablement difficile de travailler avec ce que chaque nom de classe signifie et comment les utiliser correctement.''


	* 2006-11-~~15 soulevée par hsivonen dans #whatwg.~~
	*# ''Sans connaître iCalendar ou vCard, ~~c'est vraiment non-évident de voir ce à quoi s'adapteront les hCards ou les hCalendars. La partie normative est extrêmement courte~~ et ~~ne semble pas établir suffisamment clairement un mapping entre~~ les ~~microformats et les RFCs.''~~
	# Ceci (et la ~~seconde réaction de Lachy au point ci-dessus) devrait être résolu en clarifiant le mapping avec un meilleur usage du~~ [[hcard-~~profile~~-fr\|hCard ~~profile~~]] ~~qui mappe vraiment clairement les noms de classes vers les propriétés vCard properties et les sections de la spécification vCard qui les définit~~. ~~- Tantek~~


	* 2006-11-15 soulevée par Hixie dans #whatwg (et accord par [http://lachy.id.au/ Lachy] et hsivonen).
	*# '~~'La spec~~ [[hcard-fr\|~~hCard]~~] ~~se lit basiquement comme un brainstorm, pas une spec normative.''~~


	* 2006-11-17 soulevée par [http://lachy.id.au/ Lachlan Hunt].
	*# Principes de Design XHTML Sémantique : Cette section devrait partir. Les lignes de conduite sur la façon d'écrire une spécification de microformats n'appartiennent pas à la spec elle-même.
	*# Format - Plus d'Equivalents Sémantiques : Les explications sur la façon d'utiliser correctement chaque propriété devraient être données avec chacune et toutes les propriétés, pas simplement en lister quelques-unes en haut avant que les propriétés n'aient été définies.
	*# Singulier vs. Pluriel : Il est peut clair de ce que veut dire les propriétés singulière vs plurielle. Ordinairement, un pluriel est un mot qui fait référence à plusieurs objets, mais dans cette spec, il est utilisé pour désigner une propriété qui peut être utilisée plus d'une fois. Cela ne fait pas de sens parce que la propriété elle-même n'est pas un pluriel. A côté de cela, cette section devrait partir. Le nombre de fois où une propriété peut être utilisée devrait être listé avec chaque description individuelle de propriété.
	*# Plural Properties Singularized: What the...? After attempting to read that paragraph several times, I still can't comprehend what on earth it's trying to say.
	*# Human vs. Machine Readable: This title only makes some sense for the use of the abbr element. Everything in this section should be moved to a Conformance Requirements section, which explains how to extract values from the markup. It should also use RFC 2119 terminology that describes exactly what a UA has to do. Presently, it's written to informatively, rather than normatively (particularly for the abbr element).
	*# Property List: This section is almost useless, it's effectively written like an index of properties but doesn't link to or help define, in any way whatsoever, what the actual meaning of a property is, nor how to use it. For every single property, all of the following information should be listed
	# Property name
	# Expansion (e.g. it's not clear from this section what fn stands for. First Name? Family Name? Full Name? Flight Number?)
	# Definition. (e.g. either copy the definition directly from vCard or provide a short summary, and also a link to the relevant vCard section. Saying just "See section #.#.# of RFC 2426.", as done in the profile, is not so easy to do.)
	# Usage
	#* Contexts in which this property may be used
	#* Content model (e.g. list of sub properties, expected elements, text, or whatever)
	#* Syntax of the value (i.e. plain text, number, URI, etc.)
	#* Elements this property may be used on
	# How to interpret the value (may link to relevant section in Conformance Requirements)
	**I second all of the above. [[User:~~AndyMabbett~~\|~~Andy Mabbett~~]] 07:15, ~~17 Nov 2006~~ (PST)

	==~~Gabarit~~ ==		=== 2008 ===
			<div class="vevent">
			* {{OpenIssue-fr}} <span class="summary vcard"><span class="dtstart">2008-01-13</span> soulevée par <span class="fn">Christopher Allen</span> à l'OpenIDDevCamp (recueillie par [[User:Tantek\|Tantek]]).</span>
			<div class="description">
			*# Quelle est la bonne pratique pour publier votre TZ dans votre hCard ? Car publier simplement un décalage fixe aboutira probablement à une erreur d'une heure la moitié de l'année pour la plupart des gens, compte tenu du fait que le reste de la hCard sera proablement statique.
			</div>
			</div>

	~~Utilisez svp ce format (copiez et collez ceci à la fin de la liste pour ajouter votre réaction ):~~		=== gabarit ===
	* AAAA-MM-~~JJ soulevée par [http://votrepagepersonnelle.exemple.com VOTRENOM].~~		{{issues-format-fr}}
	*# ''Voici la première réaction générale que j'ai.''
	*# ''Voici la seconde réaction générale que j'ai.''

	== Pages apparentées ==		== Pages apparentées ==
	{{hcard-related-pages-fr}}		{{hcard-related-pages-fr}}

ChristopheDucamp at 20:06, 9 January 2007

2007-01-09T20:06:25Z

← Older revision		Revision as of 20:06, 9 January 2007
Line 1:		Line 1:
	<h1> hCard réactions </h1>		<h1> hCard réactions </h1>

	Les réactions générales à propos de [[hcard-fr\|hCard]] peuvent être ~~fournis~~ ici, et le(s) éditeur(s) feront de ~~leurs~~ mieux pour essayer de se plier et d'accomoder à de telles réactions. Plus la réaction est spécifique, plus il y aura de chance qu'elle soit prise en compte. Pour les problématiques spécifiques avec la spécification (à l'inverse des problèmes généraux et réactions), utilisez svp la page [[hcard-issues-fr\|hCard ~~problématique~~]].		Les réactions générales à propos de [[hcard-fr\|hCard]] peuvent être fournies ici, et le(s) éditeur(s) feront de leur mieux pour essayer de se plier et d'accomoder à de telles réactions. Plus la réaction est spécifique, plus il y aura de chance qu'elle soit prise en compte. Pour les problématiques spécifiques avec la spécification (à l'inverse des problèmes généraux et réactions), utilisez svp la page [[hcard-issues-fr\|hCard problématiques]].

	'''IMPORTANT''' : Lisez SVP '''avant''' la page [[hcard-faq-fr\|hCard FAQ]] en donnant toute réaction ou pour soulever toutes les problématiques car vos réactions/problématiques peuvent avoir été déjà résolues ou traitées.		'''IMPORTANT''' : Lisez SVP '''avant''' la page [[hcard-faq-fr\|hCard FAQ]] en donnant toute réaction ou pour soulever toutes les problématiques car vos réactions/problématiques peuvent avoir été déjà résolues ou traitées.
Line 9:		Line 9:
	__TOC__		__TOC__

	== ~~Réaction~~ ==		== Réactions ==

	* 2006-11-15 soulevée par [http://lachy.id.au/ Lachy] dans [irc://freenode/whatwg #whatwg] (un canal IRC sur [http://freenode.net/ freenode] ~~about~~ [http://whatwg.org/ The WHATWG]).		* 2006-11-15 soulevée par [http://lachy.id.au/ Lachy] dans [irc://freenode/whatwg #whatwg] (un canal IRC sur [http://freenode.net/ freenode] à propos de [http://whatwg.org/ The WHATWG]).
	*# ''Je pense que la totalité de la spécification [[hcard-fr\|hCard]] a besoin d'être restructurée.''		*# ''Je pense que la totalité de la spécification [[hcard-fr\|hCard]] a besoin d'être restructurée.''
	*# ''C'est incroyablement difficile de travailler avec ce que chaque nom de classe signifie et comment les utiliser correctement.''		*# ''C'est incroyablement difficile de travailler avec ce que chaque nom de classe signifie et comment les utiliser correctement.''
Line 28:		Line 28:
	*# Principes de Design XHTML Sémantique : Cette section devrait partir. Les lignes de conduite sur la façon d'écrire une spécification de microformats n'appartiennent pas à la spec elle-même.		*# Principes de Design XHTML Sémantique : Cette section devrait partir. Les lignes de conduite sur la façon d'écrire une spécification de microformats n'appartiennent pas à la spec elle-même.
	*# Format - Plus d'Equivalents Sémantiques : Les explications sur la façon d'utiliser correctement chaque propriété devraient être données avec chacune et toutes les propriétés, pas simplement en lister quelques-unes en haut avant que les propriétés n'aient été définies.		*# Format - Plus d'Equivalents Sémantiques : Les explications sur la façon d'utiliser correctement chaque propriété devraient être données avec chacune et toutes les propriétés, pas simplement en lister quelques-unes en haut avant que les propriétés n'aient été définies.
	*# ~~Singlular~~ vs. ~~Plural~~: ~~It is unclear what is meant by singular~~ vs. ~~plural properties. Ordinarily~~, ~~a plural is word that refers to multiple objects~~, ~~but in this~~ spec, it'~~s being used to designate a property that can be used more than once~~. ~~It doesn't make sense because the property itself isn~~'~~t a plural~~. ~~Besides~~, ~~this~~ section ~~should go~~. ~~The number of times a property can be used should be listed with each individual property~~ description.		*# Singulier vs. Pluriel : Il est peut clair de ce que veut dire les propriétés singulière vs plurielle. Ordinairement, un pluriel est un mot qui fait référence à plusieurs objets, mais dans cette spec, il est utilisé pour désigner une propriété qui peut être utilisée plus d'une fois. Cela ne fait pas de sens parce que la propriété elle-même n'est pas un pluriel. A côté de cela, cette section devrait partir. Le nombre de fois où une propriété peut être utilisée devrait être listé avec chaque description individuelle de propriété.
	*# Plural Properties Singularized: What the...? After attempting to read that paragraph several times, I still can't comprehend what on earth it's trying to say.		*# Plural Properties Singularized: What the...? After attempting to read that paragraph several times, I still can't comprehend what on earth it's trying to say.
	*# Human vs. Machine Readable: This title only makes some sense for the use of the abbr element. Everything in this section should be moved to a Conformance Requirements section, which explains how to extract values from the markup. It should also use RFC 2119 terminology that describes exactly what a UA has to do. Presently, it's written to informatively, rather than normatively (particularly for the abbr element).		*# Human vs. Machine Readable: This title only makes some sense for the use of the abbr element. Everything in this section should be moved to a Conformance Requirements section, which explains how to extract values from the markup. It should also use RFC 2119 terminology that describes exactly what a UA has to do. Presently, it's written to informatively, rather than normatively (particularly for the abbr element).

ChristopheDucamp: /* Réaction */ translation to be achieved

2006-12-14T18:20:02Z

Réaction: translation to be achieved

← Older revision		Revision as of 18:20, 14 December 2006
Line 17:		Line 17:

	* 2006-11-15 soulevée par hsivonen dans #whatwg.		* 2006-11-15 soulevée par hsivonen dans #whatwg.
	*# ''~~Without knowing~~ iCalendar or vCard, ~~it is totally~~ non-~~obvious to see what~~ hCards or hCalendars ~~would be conforming~~. ~~The~~ normative ~~part is extremely short and doesn't seem to establish clear enough a~~ mapping ~~between the~~ microformats ~~and the~~ RFCs.''		*# ''Sans connaître iCalendar ou vCard, c'est vraiment non-évident de voir ce à quoi s'adapteront les hCards ou les hCalendars. La partie normative est extrêmement courte et ne semble pas établir suffisamment clairement un mapping entre les microformats et les RFCs.''
	# ~~This~~ (~~and~~ Lachy~~'s 2nd feedback~~ point ~~above~~) ~~should be addressed by clarifying the~~ mapping ~~with better use of the~~ [[hcard-profile-fr\|hCard profile]] ~~which does clearly map the class names to~~ vCard properties ~~and the~~ sections ~~of the~~ vCard ~~specification that defines them~~. - Tantek		# Ceci (et la seconde réaction de Lachy au point ci-dessus) devrait être résolu en clarifiant le mapping avec un meilleur usage du [[hcard-profile-fr\|hCard profile]] qui mappe vraiment clairement les noms de classes vers les propriétés vCard properties et les sections de la spécification vCard qui les définit. - Tantek


Line 26:		Line 26:

	* 2006-11-17 soulevée par [http://lachy.id.au/ Lachlan Hunt].		* 2006-11-17 soulevée par [http://lachy.id.au/ Lachlan Hunt].
	*# ~~Semantic~~ XHTML ~~Design Princples~~: ~~This~~ section ~~should go~~. ~~Guidelines for how to write a~~ microformats ~~specification do not belong in the~~ spec ~~itself~~.		*# Principes de Design XHTML Sémantique : Cette section devrait partir. Les lignes de conduite sur la façon d'écrire une spécification de microformats n'appartiennent pas à la spec elle-même.
	*# Format - ~~More Semantic~~ Equivalents: ~~Explanations of how to use each property correctly should be given with each and every property~~, ~~not just list a few at the top before the properties have even been defined~~.		*# Format - Plus d'Equivalents Sémantiques : Les explications sur la façon d'utiliser correctement chaque propriété devraient être données avec chacune et toutes les propriétés, pas simplement en lister quelques-unes en haut avant que les propriétés n'aient été définies.
	*# Singlular vs. Plural: It is unclear what is meant by singular vs. plural properties. Ordinarily, a plural is word that refers to multiple objects, but in this spec, it's being used to designate a property that can be used more than once. It doesn't make sense because the property itself isn't a plural. Besides, this section should go. The number of times a property can be used should be listed with each individual property description.		*# Singlular vs. Plural: It is unclear what is meant by singular vs. plural properties. Ordinarily, a plural is word that refers to multiple objects, but in this spec, it's being used to designate a property that can be used more than once. It doesn't make sense because the property itself isn't a plural. Besides, this section should go. The number of times a property can be used should be listed with each individual property description.
	*# Plural Properties Singularized: What the...? After attempting to read that paragraph several times, I still can't comprehend what on earth it's trying to say.		*# Plural Properties Singularized: What the...? After attempting to read that paragraph several times, I still can't comprehend what on earth it's trying to say.

ChristopheDucamp: traduction à finir

2006-12-14T07:24:58Z

traduction à finir

New page

<h1> hCard réactions </h1>

Les réactions générales à propos de [[hcard-fr|hCard]] peuvent être fournis ici, et le(s) éditeur(s) feront de leurs mieux pour essayer de se plier et d'accomoder à de telles réactions. Plus la réaction est spécifique, plus il y aura de chance qu'elle soit prise en compte. Pour les problématiques spécifiques avec la spécification (à l'inverse des problèmes généraux et réactions), utilisez svp la page [[hcard-issues-fr|hCard problématique]].

'''IMPORTANT''' : Lisez SVP '''avant''' la page [[hcard-faq-fr|hCard FAQ]] en donnant toute réaction ou pour soulever toutes les problématiques car vos réactions/problématiques peuvent avoir été déjà résolues ou traitées.

La réaction peut (et sera probablement) éditée et récrite pour une meilleure concision, clarté rationnalité et sous un point de vue aussi neutre que possible. Utilisez le gabarit fourni et ajoutez votre réaction à la fin de la section Réaction. Ecrivez bien votre réaction. — [http://tantek.com/log/ Tantek]

__TOC__

== Réaction ==

* 2006-11-15 soulevée par [http://lachy.id.au/ Lachy] dans [irc://freenode/whatwg #whatwg] (un canal IRC sur [http://freenode.net/ freenode] about [http://whatwg.org/ The WHATWG]).
*# ''Je pense que la totalité de la spécification [[hcard-fr|hCard]] a besoin d'être restructurée.''
*# ''C'est incroyablement difficile de travailler avec ce que chaque nom de classe signifie et comment les utiliser correctement.''

* 2006-11-15 soulevée par hsivonen dans #whatwg.
*# ''Without knowing iCalendar or vCard, it is totally non-obvious to see what hCards or hCalendars would be conforming. The normative part is extremely short and doesn't seem to establish clear enough a mapping between the microformats and the RFCs.''
*#* This (and Lachy's 2nd feedback point above) should be addressed by clarifying the mapping with better use of the [[hcard-profile-fr|hCard profile]] which does clearly map the class names to vCard properties and the sections of the vCard specification that defines them. - Tantek

* 2006-11-15 soulevée par Hixie dans #whatwg (et accord par [http://lachy.id.au/ Lachy] et hsivonen).
*# ''La spec [[hcard-fr|hCard]] se lit basiquement comme un brainstorm, pas une spec normative.''

* 2006-11-17 soulevée par [http://lachy.id.au/ Lachlan Hunt].
*# Semantic XHTML Design Princples: This section should go. Guidelines for how to write a microformats specification do not belong in the spec itself.
*# Format - More Semantic Equivalents: Explanations of how to use each property correctly should be given with each and every property, not just list a few at the top before the properties have even been defined.
*# Singlular vs. Plural: It is unclear what is meant by singular vs. plural properties. Ordinarily, a plural is word that refers to multiple objects, but in this spec, it's being used to designate a property that can be used more than once. It doesn't make sense because the property itself isn't a plural. Besides, this section should go. The number of times a property can be used should be listed with each individual property description.
*# Plural Properties Singularized: What the...? After attempting to read that paragraph several times, I still can't comprehend what on earth it's trying to say.
*# Human vs. Machine Readable: This title only makes some sense for the use of the abbr element. Everything in this section should be moved to a Conformance Requirements section, which explains how to extract values from the markup. It should also use RFC 2119 terminology that describes exactly what a UA has to do. Presently, it's written to informatively, rather than normatively (particularly for the abbr element).
*# Property List: This section is almost useless, it's effectively written like an index of properties but doesn't link to or help define, in any way whatsoever, what the actual meaning of a property is, nor how to use it. For every single property, all of the following information should be listed
*#* Property name
*#* Expansion (e.g. it's not clear from this section what fn stands for. First Name? Family Name? Full Name? Flight Number?)
*#* Definition. (e.g. either copy the definition directly from vCard or provide a short summary, and also a link to the relevant vCard section. Saying just "See section #.#.# of RFC 2426.", as done in the profile, is not so easy to do.)
*#* Usage
*#** Contexts in which this property may be used
*#** Content model (e.g. list of sub properties, expected elements, text, or whatever)
*#** Syntax of the value (i.e. plain text, number, URI, etc.)
*#** Elements this property may be used on
*#* How to interpret the value (may link to relevant section in Conformance Requirements)
**I second all of the above. [[User:AndyMabbett|Andy Mabbett]] 07:15, 17 Nov 2006 (PST)

==Gabarit ==

Utilisez svp ce format (copiez et collez ceci à la fin de la liste pour ajouter votre réaction ):
* AAAA-MM-JJ soulevée par [http://votrepagepersonnelle.exemple.com VOTRENOM].
*# ''Voici la première réaction générale que j'ai.''
*# ''Voici la seconde réaction générale que j'ai.''

== Pages apparentées ==
{{hcard-related-pages-fr}}