hcard-user-interface-fr: Difference between revisions
([fr:translation draft hcard-user-interface-fr]) |
m ([fr:fixed link in french]) |
||
| Line 8: | Line 8: | ||
* [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc] | * [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc] | ||
;Traduction | |||
:[[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 | |||
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# | # 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# | # 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 | 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. | ||
Revision as of 06:42, 29 September 2007
Interface Utilisateur hCard
Cette page est dédiée aux techniques et problématiques autour des user-interfaces pour écrire, publier et afficher des hCards.
Auteurs
- Traduction
- Christophe Ducamp
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 fn, avec n omis), le fait de capturer individuellement les parties du composant du nom permet la construction propre sur n 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 toujours 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 n valide.
Un algorithme suggéré 'best-guess' pourrait être :
- Si le nom est un mot, essayez optimisation implicite "nickname"
- Si le nom fait deux mots, essayez optimisation n implicite
- 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 plutôt que générer un hCard invalide.