microformats-2-fr - Revision history

ChristopheDucamp: #REDIRECT microformats2-fr

2012-09-06T04:23:24Z

#REDIRECT microformats2-fr

Show changes

ChristopheDucamp: [fr: translation - content updated - sync'd with original - to be studied and completed with french examples]

2012-06-13T07:36:53Z

[fr: translation - content updated - sync'd with original - to be studied and completed with french examples]

Show changes

ChristopheDucamp: [fr: translation - content updated - sync'd with original - to be studied and completed with french examples]

2012-06-13T07:34:00Z

[fr: translation - content updated - sync'd with original - to be studied and completed with french examples]

← Older revision		Revision as of 07:34, 13 June 2012
Line 520:		Line 520:
	# Quelques règles spécifiques à certains formats spécifiques (optimisations marquage/contenu)		# Quelques règles spécifiques à certains formats spécifiques (optimisations marquage/contenu)

	Ceci voulait dire qu’à chaque fois qu’un nouveau microformat est ~~« drafté »~~/spécifié/adopté, les parseurs ont besoin d’être mis à jour pour le gérer correctement, à un minimum pour les parser quand ils sont à l’intérieur d’autres microformats et évitent des propriétés implicites errantes de l’un à l’autre (confinement, problème [[mfo-fr\|mfo]]).		Ceci voulait dire qu’à chaque fois qu’un nouveau microformat est « drafté »/spécifié/adopté, les parseurs ont besoin d’être mis à jour pour le gérer correctement, à un minimum pour les parser quand ils sont à l’intérieur d’autres microformats et évitent des propriétés implicites errantes de l’un à l’autre (confinement, problème [[mfo-fr\|mfo]]).

	==== conventions de dénomination pour analyse générique ====		==== conventions de dénomination pour analyse générique ====

ChristopheDucamp: [fr: /* UTILISATEURS */ 1st draft translation]

2012-04-18T16:31:07Z

[fr: UTILISATEURS: 1st draft translation]

← Older revision		Revision as of 16:31, 18 April 2012
Line 673:		Line 673:

	=== UTILISATEURS ===		=== UTILISATEURS ===
	~~Need more tools and~~ interfaces ~~that~~:		Besoin de plus d'outils et d'interfaces qui :
	* ~~publish~~		* publient
	* ~~copy~~/~~paste~~		* copient/collent
	* ~~right~~-~~click on a~~ microformat		* clic-droit sur un microformat
	* ~~share~~		* partagent
	* ~~search results~~		* recherchent des résultats

	~~discussed some existing like~~: [[H2VX]] ~~converts~~ hCard to vCard, hCalendar to iCalendar		discuté de quelques outils existants comme : [[h2vx-fr\|H2VX]] convertit hCard en vCard, hCalendar en iCalendar

	~~how would we re~~-~~implement~~ Live Clipboard ~~today~~, ~~making it easier for publishers and developers~~?		Comment ré-implémenterions-nous Live Clipboard aujourd'hui, en le rendant plus facile pour les auteurs, éditeurs et développeurs ?

	=== VOIR AUSSI ===		=== VOIR AUSSI ===

ChristopheDucamp: [fr : /* A Propos de ce Brainstorm */ grammar]

2012-04-18T09:59:18Z

[fr : A Propos de ce Brainstorm: grammar]

← Older revision		Revision as of 09:59, 18 April 2012
Line 335:		Line 335:
	* La valeur 'location' renvoie le texte visible de son élément, y compris les espaces et la ponctuation, tout comme l'abréviation de l'état 'OR'. Les valeurs de propriété 'h-card' sont les seules qui sont marquées, et par conséquent contiennent des valeurs de structure sans ponctuation supplémentaire, et l'état prend la forme étendue à partir de l'attribut <code>title</code> de son élément <code><abbr></code>.		* La valeur 'location' renvoie le texte visible de son élément, y compris les espaces et la ponctuation, tout comme l'abréviation de l'état 'OR'. Les valeurs de propriété 'h-card' sont les seules qui sont marquées, et par conséquent contiennent des valeurs de structure sans ponctuation supplémentaire, et l'état prend la forme étendue à partir de l'attribut <code>title</code> de son élément <code><abbr></code>.

	== A Propos de ce Brainstorm ==		== À Propos de ce Brainstorm ==
	Ce brainstorm est actuellement écrit en format narratif/exploratoire, ce qui veut dire, ~~en remerciant~~ le succès ~~qu'ont eu~~ les microformats, pourquoi c'est ainsi, et puis une promenade à travers les problématiques connues des microformats en général associée à l'itération de chemins pour résoudre les dites problématiques, pour ~~se conclure~~ avec le design actuel microformats 2.0 ~~en guise de conclusion~~.		Ce brainstorm est actuellement écrit en format narratif/exploratoire, ce qui veut dire, remercier le succès rencontré par les microformats, pourquoi c'est ainsi, et puis une promenade à travers les problématiques connues des microformats en général associée à l'itération de chemins pour résoudre les dites problématiques, pour finir en guise de conclusion avec le design actuel microformats 2.0.

	Les propositions se construisent les unes sur les autres pour aboutir à une solution qui résout la vaste majorité des problématiques générales. Les modifications proposées méritent une incrémentation de version majeure, d'où microformats 2.0.		Les propositions se construisent les unes sur les autres pour aboutir à une solution qui résout la vaste majorité des problématiques générales. Les modifications proposées méritent une incrémentation de version majeure, d'où microformats 2.0.

	Ce style mathématique de preuve/dérivation est utilisé pour encourager explicitement la compréhension (et la double-vérification) des étapes rationnelles dans le développement de microformats 2.0. Les raisons sont ~~documentés~~, parfois associées à des alternatives envisagées (et les raisons de rejet de ces alternatives).		Ce style mathématique de preuve/dérivation est utilisé pour encourager explicitement la compréhension (et la double-vérification) des étapes rationnelles dans le développement de microformats 2.0. Les raisons sont documentées, parfois associées à des alternatives envisagées (et les raisons de rejet de ces alternatives).

	Quand le brainstorm microformats 2.0 aura suffisamment évolué pour démontrer quelque degré de stabilité, d'utilisabilité, et de capacité à être implémenté, il sera ré-écrit dans un style de spécification plus déclaratif, et cette dérivation/narration sera archivé vers une page de développement à des fins historiques.		Quand le brainstorm microformats 2.0 aura suffisamment évolué pour démontrer quelque degré de stabilité, d'utilisabilité, et de capacité à être implémenté, il sera ré-écrit dans un style de spécification plus déclaratif, et cette dérivation/narration sera archivé vers une page de développement à des fins historiques.

ChristopheDucamp: [fr: translation of original page - to be studied and continued.]

2012-04-18T09:55:59Z

[fr: translation of original page - to be studied and continued.]

Show changes

ChristopheDucamp: [fr : /* distinguer les propriétés des autres classes */ first draft translation]

2012-04-18T09:16:39Z

[fr : distinguer les propriétés des autres classes: first draft translation]

← Older revision		Revision as of 09:16, 18 April 2012
Line 487:		Line 487:

	==== distinguer les propriétés des autres classes ====		==== distinguer les propriétés des autres classes ====
	~~Current~~ microformats ~~properties re~~-~~use generic terms like~~ "summary", "photo", "updated" ~~both for ease of use and understanding~~.		Les propriétés actuelles des microformats ré-utilisent des termes génériques comme "summary", "photo", "updated" à la fois tant pour la facilité d’usage que la compréhension.

	~~However~~, ~~through longer term experience~~, ~~we've seen~~ sites ~~that accidentally drop~~ (~~or break~~) ~~their~~ microformats ~~support~~ (~~e.g~~. Upcoming.org, Facebook) ~~because~~ web ~~authors sometimes rewrite all their class names~~, ~~and either are unaware that~~ microformats ~~were in the~~ page, ~~or couldn't easily distinguish microformats property class names from other~~ site~~-specific class names~~.		Néanmoins, à travers une expérience à plus long terme, nous avons vu des sites qui ont abandonné accidentellement (ou rompu) leurs supports des microformats (par ex. Upcoming.org, Facebook) parce que les auteurs web écrivent à nouveau tous leurs noms de classes, et ne sont soit pas conscients que les microformats étaient dans la page, ou ne pouvaient pas facilement distinguer les noms de classe des propriétés des autres noms de classes spécifiques au site.

	~~This issue has been reported by~~ a ~~number of~~ web ~~authors~~.		Ce problème a été rapporté par un certain nombre d’auteurs web.
	* ~~See~~: [[issues#class-collisions]]		* Voir : [[issues#class-collisions]]

	~~Thus~~ microformats 2 ~~uses~~ ''~~prefixes~~'' ~~for property class names~~, ~~e.g~~.:		Par conséquent microformats 2 utilise des ''préfixes'' pour les noms de classes des propriétés, par ex. :
	* '''p-summary''' ~~instead of~~ ''summary''		* '''p-summary''' au lieu de ''summary''
	* '''u-photo''' ~~instead of~~ ''photo''		* '''u-photo''' au lieu de ''photo''
	* '''dt-updated''' ~~instead of~~ ''updated''		* '''dt-updated''' au lieu de ''updated''

	~~Such prefixing of all~~ microformats ~~class names was first suggested by~~ Scott Isaacs of Microsoft to Tantek ~~on a visit to~~ Microsoft ~~sometime in~~ 2006/2007, ~~but specifically aimed at making~~ microformats ~~easier to parse~~. ~~At the time the~~ suggestion ~~was rejected since~~ microformats ~~were focused on~~ web ~~authors rather than parsers~~.		Préfixer ainsi tous les noms de classes de microformats fût suggéré initialement par Scott Isaacs de Microsoft à Tantek durant une visite chez Microsoft en 2006/2007, mais destiné spécifiquement pour faire en sorte que les microformats soient plus faciles à parser. À cette date, la suggestion avait été rejetée parce que les microformats étaient plus focalisés sur les auteurs web que les parseurs.

	~~However~~, ~~since experience has shown that distinguishing property class names is an issue for '''both~~ web ~~authors and parser developers~~''', ~~this is a key change that~~ microformats 2 ~~is adopting~~. ~~See the next~~ section ~~for details~~.		Néanmoins, parce que l’expérience a montré que les noms de classes distinctifs est une problématique tant ‘’’pour les auteurs web que les développeurs de parseurs''', c’est un changement-clé que microformats-2 adopte. Voir la prochaine section pour les détails.

	=== COMMUNAUTÉ et OUTILS ===		=== COMMUNAUTÉ et OUTILS ===

ChristopheDucamp: [fr: translation of original page - to be studied and continued.]

2012-04-18T09:09:13Z

[fr: translation of original page - to be studied and continued.]

Show changes

ChristopheDucamp: [fr : /* simplifier pour n'avoir besoin que d'un seul élément */ translation : first draft to be reviewed]

2012-04-18T05:48:30Z

[fr : simplifier pour n'avoir besoin que d'un seul élément: translation : first draft to be reviewed]

← Older revision		Revision as of 05:48, 18 April 2012
Line 431:		Line 431:

	==== simplifier pour n'avoir besoin que d'un seul élément ====		==== simplifier pour n'avoir besoin que d'un seul élément ====
	~~It's very~~ important ~~for the~~ simple ~~case to be as~~ simple as possible, ~~to enable the~~ maximum ~~number of people to get started with minimum~~ effort. (~~The idea of using a single class name for~~ a ~~microformat was proposed by~~ Ryan Cannon in 2006 ~~specifically~~ [[hcard-implied\|~~for~~ hCard]], ~~and rediscovered by~~ [[User:Tantek\|Tantek]] in 2010 ~~and subsequently generalized to all~~ microformats.)		Il est très important pour le simple cas d'être aussi simple que possible, de permettre aux maximum de personnes de démarrer avec un effort minimal. (L'idée d'utiliser un nom de classe unique pour un microformat a été proposée par Ryan Cannon en 2006 spécifiquement [[hcard-implied-fr\|pour hCard]], et redécouverte par [[User:Tantek\|Tantek]] en 2010 et généralisée par la suite pour tous les microformats.)

	~~From there on~~, it'~~s ok to require incremental~~ effort ~~for incremental return~~.		À partir de là, c'est bien d'obliger à un effort incrémental pour un retour incrémental.
			Ce qui veut dire ajouter toute information additionnelle à propos d'une personne, ajouter des noms de propriété explicites.

	~~E.g. to add any additional information about a person, add explicit property names.~~		'''Comment fonctionne ce cas d'unique racine ?'''

	~~'''How does this simple root-only case work?'''~~		* le nom de classe racine reflète le nom du microformat
			* chaque microformat doit avoir besoin tout au plus d'une propriété (de préférence 0)
	* ~~root class name reflects name of the~~ microformat		** admettons qu'avoir besoin d'un champ dans une application résulte simplement dans du bruit (le problème 90210 - des apps qui ont besoin du code postal reçoivent beaucoup d'entrées 90210), et spécifier que n'importe quel cas d'usage d'application qui semble "avoir besoin" de propriétés spécifiques doit au lieu de cela définir comment signifier des valeurs sensibles par défaut pour elles.
	* ~~every~~ microformat ~~must require at most 1 property~~ (~~preferably~~ 0)		* si un seul nom de classe est spécifié, signifier les contenus entiers texte de l'élément comme la valeur de la propriété de base du microformat à savoir :
	** ~~admit that requiring a field in an~~ application ~~just results in noise~~ (~~the~~ 90210 ~~problem~~ - apps ~~which require zip~~ code ~~get lots of false~~ 90210 ~~entries~~), ~~and specify that any~~ application ~~use cases which appear to~~ "~~require~~" ~~specific properties must instead define how to imply sensible defaults for them~~.		** "hcard" insinue "fn"
	* ~~when only a root class name is specified~~, ~~imply the entire text contents of the element as the value of the primary property of the~~ microformat~~. e.g.~~		** hcalendar event - "hevent" - insinue "summary"
	** "hcard" ~~implies~~ "fn"		** "hreview" insinue "summary"
	** hcalendar event - "hevent" - ~~implies~~ "summary"		** "hentry" insinue "entry-summary" (à réduire peut-être en "summary" - en pratique ils ne sont pas suffisamment distincts sémantiquement pour avoir besoin de noms de propriété séparés)
	** "hreview" ~~implies~~ "summary"		** '''OU''' au lieu de produire l'unique propriété implicite à avoir un vocab spécifique, introduire une nouvelle propriété générique 'p-name' (applicable à tous les vocabulaires) (subsuming hCard's 'fn'). Voir [[microformats-2-brainstorming#further_simplifications\|microformats 2 brainstorming: further simplifications]] pour les dernières idées le long de ces lignes, comprenant les propriétés génériques suivantes spécifiques de marquage pour tous les microformats (basées sur des cas d'usages de marquage existants et publiés)
	** "hentry" ~~implies~~ "entry-summary" (~~perhaps collapse into~~ "summary" - ~~in practice they're not sufficiently semantically distinct to require separate property names~~)
	** '''OR''' ~~instead of making the one implied property be vocabulary specific~~, ~~introduce a new generic (applicable to all vocabularies)~~ 'p-name' ~~property~~ (subsuming hCard's 'fn'). ~~See~~ [[microformats-2-brainstorming#further_simplifications\|microformats 2 brainstorming: further simplifications]] ~~for latest thoughts along these lines~~, ~~including the following specific mark-up implied generic properties across all~~ microformats (~~based on existing published markup use-cases~~)
	*** 'p-name'		*** 'p-name'
	*** 'u-url'		*** 'u-url'

ChristopheDucamp: [fr: /* renommage pour utilisabilité */ first draft translation to be reviewed]

2012-04-18T04:51:26Z

[fr: renommage pour utilisabilité: first draft translation to be reviewed]

← Older revision		Revision as of 04:51, 18 April 2012
Line 401:		Line 401:

	==== renommage pour utilisabilité ====		==== renommage pour utilisabilité ====
	~~Otherwise known as~~, ~~choosing one form of consistency over another~~.		Autrement connu sous, choisir une forme de cohérence sur une autre.

	'''~~Can we do even better~~?'''		'''Pouvons-nous faire même encore mieux ?'''

	~~One of the most common~~ questions ~~asked about~~ hCard is:		L'une des questions les plus communément posée à propos de hCard est :

	[[hcard-faq#~~Why_does_hCard_use_vcard_as_the_root_class_name~~\|~~Why does~~ hCard ~~use~~ vcard ~~as the root class name~~?]]		[[hcard-faq-fr#Pourquoi_hCard_utilise_vcard_comme_le_nom_de_classe_racine\|Pourquoi hCard utilise vcard comme nom de classe racine ?]]

	~~This slight inconsistency between the name of the~~ format ~~and the name of the root class name consistently causes~~ confusion ~~in a large percentage of newcomers to~~ microformats.		Cette légère incompatibilité entre le nom du format et le nom de classe racine prête naturellement à confusion pour un grand nombre de nouveaux venus sur les microformats.
	* ~~See~~ [[issues#hcard-vs-vcard-name]] ~~for details~~/~~links~~.		* Voir [[issues#hcard-vs-vcard-name]] pour les détails/liens.

	~~Though in~~ microformats ~~we believe very strongly in the~~ [[principle]] of [[reuse]], ~~we have to admit that in this case experience~~/~~evidence has shown that this may be~~ a ~~case where we re-used something too far beyond it's~~ original ~~meaning~~. ~~Thus~~:		Même si dans les microformats, nous croyons fermement au [[principle-fr\|principe]] de [[reuse-fr\|réutilisation]], nous devons admettre que dans ce cas, l'expérience/évidence a montré que ceci peut être un cas où nous avons réutilisé quelque chose bien au delà de son sens original. Par conséquent :

	'''~~Proposal~~: ~~use root class name~~ "hcard" ~~instead of~~ "vcard" ~~for future~~ hCards.'''		'''Proposition : utiliser le nom de classe racine "hcard" au lieu de "vcard" pour les futures hCards.'''

	~~This would result in~~:		Ceci donnerait :

	<source lang=html4strict>		<source lang=html4strict>
Line 422:		Line 422:
	</source>		</source>

	~~making the~~ simple ~~case even simpler~~:		rendant le cas simple même encore plus simple :

	~~Just~~ 1 ~~additional class name~~, ~~named the same as the~~ format ~~you're adding~~. ~~Think~~ hCard, ~~markup~~ class="hcard".		Juste 1 nom de classe additionnel, nommé du même nom que le format que vous ajoutez. Pensez hCard, marquez class="hcard".

	~~At a~~ minimum ~~for compatibility we should document that parsers should accept~~ "hcard" ~~as an~~ alternative to "vcard" ~~as the root class name for~~ hCard 1.0, ~~and similarly for~~ hCalendar 1.0: "hcalendar" ~~in addition to~~ "vcalendar", "hevent" ~~in addition to~~ "vevent".		Pour un minimum de compatibilité, nous devrions documenter que les parseurs devraient accepter "hcard" comme alternative à "vcard" comme le nom de classe racine pour hCard 1.0, et de la même manière pour hCalendar 1.0 : "hcalendar" en plus de "vcalendar", "hevent" en plus de "vevent".

	~~However~~, ~~for~~ [[microformats-2-fr\|microformats 2]] ~~we are going to distinguish root class names further by using an~~ "h-" ~~prefix~~ (~~e.g~~. "h-card"). ~~Read on to understand why~~.		Néanmoins, pour [[microformats-2-fr\|microformats 2]] nous allons distinguer les noms de classes racine plus en profondeur en utilisant un préfixe "h-" (par ex. "h-card"). Continuez à lire pour comprendre pourquoi.

	==== simplifier pour n'avoir besoin que d'un seul élément ====		==== simplifier pour n'avoir besoin que d'un seul élément ====