hcard-user-interface-fr - Revision history

Tantek: /* Interface utilisateurs supplémentaires / CSV is values*

2011-04-11T11:38:03Z

Interface utilisateurs supplémentaires: CSV is *values*

← Older revision		Revision as of 11:38, 11 April 2011
Line 32:		Line 32:
	** ajouter aux carnets d'adresses Gmail, Yahoo Mail, Hotmail (etc.)		** ajouter aux carnets d'adresses Gmail, Yahoo Mail, Hotmail (etc.)
	** envoyer vers Bluetooth, pour un transfert rapide de l'information de contact provenant du web vers un téléphone mobile.		** envoyer vers Bluetooth, pour un transfert rapide de l'information de contact provenant du web vers un téléphone mobile.
	** exporter sous texte / [[csv\|comma-separated-~~variables~~]] (CSV) pour permettre l'édition, le tri et/ou l'importation dans des feuilles de calcul/bases de données, etc. (ou concaténation à un fichier existant)		** exporter sous texte / [[csv-fr\|comma-separated-values]] (CSV) pour permettre l'édition, le tri et/ou l'importation dans des feuilles de calcul/bases de données, etc. (ou concaténation à un fichier existant)
	** afficher tous les détails de contact dans un [[semacode-fr\|semacode]] téléchargeable ou sur l'écran (pour leur permettre d'être lu par les terminaux mobiles)		** afficher tous les détails de contact dans un [[semacode-fr\|semacode]] téléchargeable ou sur l'écran (pour leur permettre d'être lu par les terminaux mobiles)
	** Si un <code>tel</code> (numéro de téléphone) type <code>home</code>, <code>work</code> ou <code>cell</code> est présent, fournir les options pour le composer (NB s'applique à un numéro à la fois seulement ; exception faite pour les usages de conférence téléphonique) ou via		** Si un <code>tel</code> (numéro de téléphone) type <code>home</code>, <code>work</code> ou <code>cell</code> est présent, fournir les options pour le composer (NB s'applique à un numéro à la fois seulement ; exception faite pour les usages de conférence téléphonique) ou via

ChristopheDucamp at 22:40, 21 October 2007

2007-10-21T22:40:00Z

← Older revision		Revision as of 22:40, 21 October 2007
Line 25:		Line 25:

	Le principe derrière cette suggestion est qu'il est mieux de faire une bonne supposition et de mal catégoriser potentiellement un composant de nom ambigu plutôt que générer un hCard invalide.		Le principe derrière cette suggestion est qu'il est mieux de faire une bonne supposition et de mal catégoriser potentiellement un composant de nom ambigu plutôt que générer un hCard invalide.


			== Interface utilisateurs supplémentaires ==

			** "Ajouter au Carnet d'Adresses" (convertit la hCard vers une vCard (.vcf) et la passe sur l'OS pour l'ouvrir/incorporer automatiquement à l'intérieur de l'application carnet d'adresses local préféré de l'utilisateur)
			** ajouter aux carnets d'adresses Gmail, Yahoo Mail, Hotmail (etc.)
			** envoyer vers Bluetooth, pour un transfert rapide de l'information de contact provenant du web vers un téléphone mobile.
			** exporter sous texte / [[csv\|comma-separated-variables]] (CSV) pour permettre l'édition, le tri et/ou l'importation dans des feuilles de calcul/bases de données, etc. (ou concaténation à un fichier existant)
			** afficher tous les détails de contact dans un [[semacode-fr\|semacode]] téléchargeable ou sur l'écran (pour leur permettre d'être lu par les terminaux mobiles)
			** Si un <code>tel</code> (numéro de téléphone) type <code>home</code>, <code>work</code> ou <code>cell</code> est présent, fournir les options pour le composer (NB s'applique à un numéro à la fois seulement ; exception faite pour les usages de conférence téléphonique) ou via
			*** modem intégré
			*** commande bluetooth vers un terminal apparié (par ex. téléphone cellulaire)
			*** application de téléphonie par défaut (par ex. skype-out)
			** Si un <code>tel</code> (numéro de téléphone) type <code>home</code>, <code>work</code> ou <code>cell</code> est présent, fournir les options pour envoyer un MMS :
			***directement
			***en utilisant un service en ligne
			***commande bluetooth vers un terminal apparié (par ex. téléphone cellulaire)
			** Si un <code>tel</code> de type <code>fax</code> est présent, fournir les options pour envoyer un fax à ce numéro via :
			*** service en ligne efax
			*** modem fax intégré
			** si une date d'anniversaire est présente, la traiter comme un événement hCalendar récurrent (voir en-dessous).

			==Voir aussi ==
			{{hcard-related-pages-fr}}

ChristopheDucamp: /* Auteurs */

2007-09-29T06:43:32Z

Auteurs

← Older revision		Revision as of 06:43, 29 September 2007
Line 1:		Line 1:
	<h1> Interface Utilisateur hCard </h1>		<h1> Interface Utilisateur hCard </h1>
	Cette page est dédiée aux techniques et problématiques autour des [[user-interface-fr\|~~user-~~interfaces]] pour écrire, publier et afficher des [[hcard-fr\|hCards]].		Cette page est dédiée aux techniques et problématiques autour des [[user-interface-fr\|interfaces utilisateurs]] pour écrire, publier et afficher des [[hcard-fr\|hCards]].

	__TOC__		__TOC__

ChristopheDucamp: [fr:fixed link in french]

2007-09-29T06:42:45Z

[fr:fixed link in french]

← Older revision		Revision as of 06:42, 29 September 2007
Line 8:		Line 8:
	* [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc]		* [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc]

	~~== Contributeurs ==~~		;Traduction
	* [[Christophe Ducamp]] ~~- traduction en cours~~		:[[Christophe Ducamp]]


	== Saisie Unique de Champ pour les Noms ==		== Saisie Unique de Champ pour les Noms ==
			Au moment de capturer la donnée de nom qui devra être plus tard présentée comme un hCard, il est important que la donnée soit collectée avec la plus haute fidélité possible. Parce que tous les noms ne concordent pas pur une optimisation implicite-n de hCard (et par conséquent ne peuvent pas être produits sous <code>fn</code>, avec <code>n</code> omis), le fait de capturer individuellement les parties du composant du nom permet la construction propre sur <code>n</code> au moment de générer la hCard.
	Au moment de capturer la donnée de nom qui devra être plus tard présentée comme un hCard, il est important que la donnée soit collectée avec la plus haute fidélité possible. Parce que tous les noms ne concordent pas pur une optimisation implicite-n de hCard (et par conséquent ne peuvent pas être produits sous <code>fn</code>, avec <code>n</code> omis), le fait de capturer individuellement les parties du composant du nom permet la ~~constrution~~ propre sur <code>n</code> au moment de générer la hCard.

	Néanmoins, parfois, les contraintes exigent qu'un nom soit collecté dans un champ unique. Un tel exemple est commun sur les CMSs de blog (WordPress, TextPattern) qui utilisent un champ unique de base de donnée pour sauvegarder le nom sur chaque commentaire de billet. Dans de tels cas il est <em>toujours</em> désirable de trouver un moyen de collecter le nom avec le plus haut niveau de fidélité. Néanmoins, si cela ne peut pas être produit simplement, l'implémenteur pourrait choisir d'essayer de supposer pour le mieu les sections du composant du nom pour former un <code>n</code> valide.		Néanmoins, parfois, les contraintes exigent qu'un nom soit collecté dans un champ unique. Un tel exemple est commun sur les CMSs de blog (WordPress, TextPattern) qui utilisent un champ unique de base de donnée pour sauvegarder le nom sur chaque commentaire de billet. Dans de tels cas il est <em>toujours</em> désirable de trouver un moyen de collecter le nom avec le plus haut niveau de fidélité. Néanmoins, si cela ne peut pas être produit simplement, l'implémenteur pourrait choisir d'essayer de supposer pour le mieu les sections du composant du nom pour former un <code>n</code> valide.
Line 20:		Line 18:
	Un algorithme suggéré 'best-guess' pourrait être :		Un algorithme suggéré 'best-guess' pourrait être :

	# Si le nom est un mot, essayez [[hcard#~~Implied_~~.22nickname.~~22_Optimization~~\|optimisation implicite ~~pseudo~~]]		# Si le nom est un mot, essayez [[hcard-fr#Optimisation_implicite_du_.22nickname.22\|optimisation implicite "nickname"]]
	# Si le nom fait deux mots, essayez [[hcard#~~Implied_~~.22n.~~22_Optimization~~\|~~implied~~ n ~~optimization~~]]		# Si le nom fait deux mots, essayez [[hcard-fr#Optimisation_implicite_.22n.22\|optimisation n implicite]]
	# Pour trois mots ou plus		# Pour trois mots ou plus
	## Exécutez une recherche sur les combinaisons connus des sous-noms (par ex. 'Sarah Jane', 'Vander Wal')		## Exécutez une recherche sur les combinaisons connus des sous-noms (par ex. 'Sarah Jane', 'Vander Wal')
	## Appliquez la grammaire "(préfixe-honorifique) prénom nom-supplémentaire(s) nom de famille (suffixe-honorifique)"		## Appliquez la grammaire "(préfixe-honorifique) prénom nom-supplémentaire(s) nom de famille (suffixe-honorifique)"

	Le principe derrière cette suggestion est qu'il est mieux de faire une bonne supposition et de mal catégoriser potentiellement un composant de nom ambigu que de générer un hCard invalide.		Le principe derrière cette suggestion est qu'il est mieux de faire une bonne supposition et de mal catégoriser potentiellement un composant de nom ambigu plutôt que générer un hCard invalide.

ChristopheDucamp: [fr:translation draft hcard-user-interface-fr]

2006-07-09T06:28:49Z

[fr:translation draft hcard-user-interface-fr]

New page

<h1> Interface Utilisateur hCard </h1>
Cette page est dédiée aux techniques et problématiques autour des [[user-interface-fr|user-interfaces]] pour écrire, publier et afficher des [[hcard-fr|hCards]].

__TOC__

== Auteurs ==
* [http://allinthehead.com/ Drew McLellan]
* [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc]

== Contributeurs ==
* [[Christophe Ducamp]] - traduction en cours

== Saisie Unique de Champ pour les Noms ==

Au moment de capturer la donnée de nom qui devra être plus tard présentée comme un hCard, il est important que la donnée soit collectée avec la plus haute fidélité possible. Parce que tous les noms ne concordent pas pur une optimisation implicite-n de hCard (et par conséquent ne peuvent pas être produits sous <code>fn</code>, avec <code>n</code> omis), le fait de capturer individuellement les parties du composant du nom permet la constrution propre sur <code>n</code> au moment de générer la hCard.

Néanmoins, parfois, les contraintes exigent qu'un nom soit collecté dans un champ unique. Un tel exemple est commun sur les CMSs de blog (WordPress, TextPattern) qui utilisent un champ unique de base de donnée pour sauvegarder le nom sur chaque commentaire de billet. Dans de tels cas il est <em>toujours</em> désirable de trouver un moyen de collecter le nom avec le plus haut niveau de fidélité. Néanmoins, si cela ne peut pas être produit simplement, l'implémenteur pourrait choisir d'essayer de supposer pour le mieu les sections du composant du nom pour former un <code>n</code> valide.

Un algorithme suggéré 'best-guess' pourrait être :

# Si le nom est un mot, essayez [[hcard#Implied_.22nickname.22_Optimization|optimisation implicite pseudo]]
# Si le nom fait deux mots, essayez [[hcard#Implied_.22n.22_Optimization|implied n optimization]]
# Pour trois mots ou plus
## Exécutez une recherche sur les combinaisons connus des sous-noms (par ex. 'Sarah Jane', 'Vander Wal')
## Appliquez la grammaire "(préfixe-honorifique) prénom nom-supplémentaire(s) nom de famille (suffixe-honorifique)"

Le principe derrière cette suggestion est qu'il est mieux de faire une bonne supposition et de mal catégoriser potentiellement un composant de nom ambigu que de générer un hCard invalide.

hcard-user-interface-fr - Revision history

Tantek: /* Interface utilisateurs supplémentaires */ CSV is *values*

ChristopheDucamp at 22:40, 21 October 2007

ChristopheDucamp: /* Auteurs */

ChristopheDucamp: [fr:fixed link in french]

ChristopheDucamp: [fr:translation draft hcard-user-interface-fr]

Tantek: /* Interface utilisateurs supplémentaires / CSV is values*