Franciser les verbes REST

On 12/7/06, Jonathan T. [email protected] wrote:

Et oui, mais je suis certains que les gens “normaux” (j’adore cette
catégorisation ;)) ils seraient très heureux de pouvoir retrouver une
url (qu’ils ont mis en bookmark sur leur machine) lorsqu’ils sont
chez des amis ou mettre_ici_votre_lieu. Et dans notre problème je
pense qu’il faut plutot considérer des url du style http://toto.com/
screen/wide vs http://toto.com/ecran/large, il est évident que les
urls complexes (cf: 32456 de l’url d’avant) ne seront jamais
“retenues” (en même temps ce n’est pas forcément le but).

Moi perso je trouve par exemple que les url de flickr sont plutot bien
foutues et pourtant j’arrive jamais à me rappeler si c’est
tag/photos/user ou user/photos/tag ou photos/tag/user etc… Alors je
me vois mal me rappeller de ecran/plat ou ecrans/plat ou
electronique/ecrans/plats…

Ça peut aider à la compréhension de la page mais surement pas à se
souvenir de l’url et comme l’a dit quelqu’un d’autre, si t’as besoin
d’une url pour comprendre une page c’est que cette dernière est
vraiment mal faite. Quand au référécement, là aussi si tu comptes sur
ton URL pour te positionner c’est que ta page ne doit pas être
terrible :slight_smile:

philippe lachaise wrote:

Mon grain de sel :

TOUT en englais, 100% pure roastbeef !

Ca évite de se poser la question.

Ca évite d’introduire des bugs super-subtils et générateurs de nuits
blanches et de calvitie précoce.

Y’a déjà assez de blagues avec la pluralisation :slight_smile:

Justement, quitte à y aller - autant y aller franchement…
je reste convaincu qu’une URL globalisée est complètement nécessaire car
elle contribue à améliorer l’ergonomie du site. Surtout avec la
completion d’URL proposé par les navigateurs modernes.

Je préfère voir s’afficher (lors de la completion)

http://www.maboutique.com/utilisateur/dupont/compte
que
http://www.maboutique.com/?id=09203902932&exec=account&module=user

Par contre, utiliser de l’url rewriting côté Apache est peut être une
alternative à étudier…

Si j’extraie un jour un plugin, les chinois vont jamais comprendre :
“def ma_super_fonction_qui_fait_un_cafe_franchouillard()”

Je sais pas toi, mais moi j’ai jamais eu l’occasion de développer avec
un développeur Chinois… Et puis si je fais un plug ins je
m’adresserait à un public international et dans ce cas j’utiliserais la
langue adéquate.

(rien n’interdit, ceopendant d’aliaser each() en chaque() si ça tente
qqun

J’ai parlé de francisation des identifiants, pas des tokens du langage
lui même (ces tokens sont un “standard” de fait, mes identifiants non)

D’ailleurs c’est même un argument commercial. Lorsqu’un client
s’inquiète de la lisibilité du code que je vais fournir il apprécie
toujours quand je lui précise que tous les identifiants sont francisés.
En terme de maintenance de code c’est un vrai plus, surtout sur des
applications métier pour lesquelles il y a déjà une terminologie
spécifique.

Tu me vois déclarer retrieve_indemnites_de_transport() ? C’est
franchement ridicule. Quant à anglicisser indemnites_de_transport j’y
pense même pas.

Maintenant, si c’est pour coder un nième système de blog à la noix,
style geeks en folie je t’accorde que ça a beaucoup moins
d’importance…

Vous la dictez comment au téléphone par exemple ?
Bonne remarque :slight_smile:

Je serais tenté de dire que, pour les URL comme pour le reste, la lingua
franca c’est l’anglais, c’est fait pour.

Les problèmes potentiels liés à la localisation des URL sont tellement
nombreux (tiens pourquoi pas, toto.com/fr/catalogue/affiche/42 et
toto.com/en/catalog/display/42) qu’elle ne justifient pas l’effort.

Ce qui est bizarre c’est que personne n’a, à ma connaissance, pensé Ã
faire
un autocomplete dans la barre d’adresse.

Je ne sais pas si c’est faisable avec les navigateurs existants mais
imaginons :

Au lieu de bêtement lister les URL récentes commençant par ce qu j’ai
saisi
il fonctionnerai (Ã l’instar de l’explorateur de fichiers Windows) en
proposant tout ce qui est possible après le “/”

http://toto.com
http://toto.com/

http://toto.com/signup
http://toto.com/catalog
http://toto.com/contact

http://toto.com/catalog/

http://toto.com/catalog/create
http://toto.com/catalog/edit
http://toto.com/catalog/update
http://toto.com/catalog/bazarde ( :wink:

Vou voyez où je veux en venir :
On arrête de se maltraiter la mémoire avec des URLs à coucher dehors :slight_smile:

Et si c’est pas possible dans la barre d’URL on le colle dans la page.
En
ajax ça doit pas être méchant à faire…

Sinon y’a un truc encore plus simple, la sitemap

Le Jeu 7 décembre 2006 10:54, philippe lachaise a écrit :

Des URL en français (ou en polonais) c’est joli, mais je ne crois
vraiment pas que ce soit un gain, ni pour l’utilisateur, ni pour le
référencement.

C’est mon opinion et je la partage ! (Sapeur Camembert :wink:

Vous dites ça parce que justement les url sont dans votre langue. Pas en
français, mais avec votre alphabet et une langue que vous, informaticiens,
vous comprenez au moins à peu près.

Maintenant utilisez des URL en chinois et revenez me dire que
l’internationalisation des ces URL est inutile …
Vous la dictez comment au téléphone par exemple ?

Après sur le principe je suis d’accord, en théorie une URL est opaque.
Elle ne serait constituée que d’une chaîne aléatoire que ça devrait aller.
En pratique elle fait partie de l’interface utilisateur. Il y a accès en
lecture et en écriture. Il cherche à la manipuler et à la transmettre.

Jette la pierre celui qui n’a jamais recopié une URL sur ou à partir d’un
papier, d’un spot TV, d’un copain/collègue qui la lit au téléphone, …
Maintenant si vous n’avez pas lancé de pierre, c’est certainement que des
URLS compréhensibles par l’humain sont bénéfiques (pas nécessaires, mais
bénéfiques).


Eric D.

Le Jeu 7 décembre 2006 14:35, philippe lachaise a écrit :

Vous la dictez comment au téléphone par exemple ?
Bonne remarque :slight_smile:

Je serais tenté de dire que, pour les URL comme pour le reste, la lingua
franca c’est l’anglais, c’est fait pour.

Pour toi, français informaticien.
Ce n’est pas plus une lingua franca, c’est juste une solution de
facilité
pour nous français informaticiens parce que c’est une langue qui nous est
suffisamment proche.

Les problèmes potentiels liés à la localisation des URL sont tellement
nombreux (tiens pourquoi pas, toto.com/fr/catalogue/affiche/42 et
toto.com/en/catalog/display/42) qu’elle ne justifient pas l’effort.

Ils sont nombreux, comme les problèmes d’accessibilité, de montée en
charge, d’ergonomie, de tout ce que tu veux en fait. Si tu es en train
de
dire qu’on ne fera jamais rien de parfait je suis d’accord. Probable
aussi
que la gestion des URL ne soit pas la partie prioritaire.
Maintenant, une fois les taches prioritaires effectuée, il reste
intéressant de se pencher sur la question pour faire un “mieux” à défaut
d’un “parfait”. Et cette phrase vaut pour à peu près tous les sujets
évoqués plus haut.

Ce qui est bizarre c’est que personne n’a, à ma connaissance, pensé à
faire un autocomplete dans la barre d’adresse.

Mon Firefox le fait, je crois qu’Internet Explorer aussi. Par contre ce
n’est pas toujours fait au mieux. Disons que c’est déjà ça.

Mais je saute sur la remarque : Si tes URL sont en
/informatique/écrans/plat et /electroménager/seche-linge, tu pourras
choisir entre tes completions plus facilement que si tu as des signes
cabalistiques (bon, en fait le navigateur montre en même temps un morceau
du titre pour aider mais les urls sont souvent plus pratiques à l’usage,
je parle là d’expérience).


Eric D.

Le Jeu 7 décembre 2006 14:19, Patrick A. a écrit :

Moi perso je trouve par exemple que les url de flickr sont plutot bien
foutues et pourtant j’arrive jamais à me rappeler si c’est
tag/photos/user ou user/photos/tag ou photos/tag/user etc… Alors je
me vois mal me rappeller de ecran/plat ou ecrans/plat ou
electronique/ecrans/plats…

Je vais dire une chose : si tu as remarqué qu’elles sont bien foutues,
c’est que c’est utile. Si c’était inutile tu n’aurais pas fait attention.

Une url significative n’implique pas forcément que tu t’en rappelles, par
contre tu auras beaucoup plus de chances de te rappeler d’un
/tag/photos/user que d’un /uversion2_appel.do?se=%2E%34%EP&ko=toto&=@@

Maintenant hors de s’en rappeler, qui concerne peu de monde :

  • tu peux la dicter simplement
  • tu peux prédire à quel genre de contenu tu accèderas quand tu la lis
    dans un mail ou dans un texte
  • tu peux l’écrire et la recopier
  • tu peux (et même des débutants le font) manipuler l’URL (passer de
    /informatique/écrans/plats à /informatique/écrans/)
  • tu auras moins l’impression de complexité et d’un environnement que tu
    ne maitrises pas (et ça pour l’utilisateur c’est important même si ça ne
    joue que sur le ressenti et pas le fonctionnel)

Quand au référécement, là aussi si tu comptes sur
ton URL pour te positionner c’est que ta page ne doit pas être
terrible :slight_smile:

Ca ne fait pas tout, très loin de là, mais avoir des url de pages
significatives ça joue de manière non négligeable sur certains moteurs
comme google.


Eric D.

Bonjour tout le monde,

Juste pour dire que perso, je mets tout en français, et je râle quand je
vois de l’anglais partout.
Pourquoi ?
Parceque ça me permet de diférencier d’un coup d’oeil ce qui est de ma
production, et ce qui est issu du langage en lui meme, ce que j’ai
récupéré
ailleurs, …
Au meme titre, que j’avais l’habitude de mettre les champs des tables en
majuscules, pour pouvoir les repérer aisément dans le code. (oui, j’ai
changé cette habitude avec rails!)
Et au meme titre, que j’aime php avec les $ devant les variables…

Voila, il y a 2 écoles, et je pense qu’il n’y en a pas une meilleure que
l’autre.
Je trouve important, pour les débutants, de cerner ces différences
facilement.

++Tous

2006/12/7, philippe lachaise [email protected]:

Le 7 déc. 06 à 14:19, Patrick A. a écrit :

Moi perso je trouve par exemple que les url de flickr sont plutot bien
foutues et pourtant j’arrive jamais à me rappeler si c’est
tag/photos/user ou user/photos/tag ou photos/tag/user etc… Alors je
me vois mal me rappeller de ecran/plat ou ecrans/plat ou
electronique/ecrans/plats…

Tout à fait, d’où ma remarque sur les url courtes uniquement.

Ça peut aider à la compréhension de la page mais surement pas à se
souvenir de l’url et comme l’a dit quelqu’un d’autre, si t’as besoin
d’une url pour comprendre une page c’est que cette dernière est
vraiment mal faite.

J’ai bien précisé aussi que le but n’est pas de fournir de
l’information supplémentaire mais pour assurer la cohérence et donc
participer à l’amélioration du repérage.

Quand au référécement, là aussi si tu comptes sur
ton URL pour te positionner c’est que ta page ne doit pas être
terrible :slight_smile:

Je n’ai jamais dis que c’était une fin, mais plutot un moyen pour
améliorer la visibilité. Après, je reste évidemment convaincu que le
plus important dans la page c’est le contenu, mais la différence
actuellement se fait justement sur les détails (sémantique du code,
titrage, url).

Tron J.
http://jonathan.tron.name_______________________________________________
Railsfrance mailing list
[email protected]
http://lists.rubyonrails.fr/mailman/listinfo/railsfrance

On 12/7/06, Jonathan T. [email protected] wrote:

Le 7 déc. 06 à 14:19, Patrick A. a écrit :

Moi perso je trouve par exemple que les url de flickr sont plutot bien
foutues et pourtant j’arrive jamais à me rappeler si c’est
tag/photos/user ou user/photos/tag ou photos/tag/user etc… Alors je
me vois mal me rappeller de ecran/plat ou ecrans/plat ou
electronique/ecrans/plats…

Tout à fait, d’où ma remarque sur les url courtes uniquement.

on est donc d’accord sur les urls courtes. Qu’elles soient en français
ou en anglais donc c’est pas trop important.
Et puis le % de personne qui fait attention à ce genre de détail n’est
pas très élevé et encore moins ceux qui dans ce petit pourcentage ne
comprennent même pas l’anglais basique genre user/photo. Traduire les
url ce serait donc se préocuper des 0.0001% des geeks qui ne
connaissent même pas l’anglais basique, bref c’est un peu du temps
perdu pour moi mais ça c’est juste mon avis of course :slight_smile:

Si c’est réellement une préoccupation pour certain, ça justifierait le
développement d’un plugin (genre LocaleURL) qui mappe les verbes REST
(pour
revenir à l’origine du débat) localisés, les controlleurs, actions, ids
etc. et intervient au niveau routes.rb pour désamorcer méthodiquement
les
pièges de l’affaire.

Mon sentiment est que, sinon, traiter ça au cas par cas c’est s’attirer
des
ennuis.

Mais c’est quand même luxueux :slight_smile:

Le 7 déc. 06 à 15:37, Patrick A. a écrit :

on est donc d’accord sur les urls courtes. Qu’elles soient en français
ou en anglais donc c’est pas trop important.

Justement c’est la qu’on est pas d’accord, le fait qu’elle soit en
français ou en anglais c’est une différence qui peut être importante.

Et puis le % de personne qui fait attention à ce genre de détail n’est
pas très élevé et encore moins ceux qui dans ce petit pourcentage ne
comprennent même pas l’anglais basique genre user/photo.

Ce n’est pas m’ont avis justement : tous les utilisateurs sont
importants. C’est le même problème que de rendre un site accessible,
ça va toucher quoi 2% de la population et encore dans ces 2% combien
vont sur le net et plus loin même sur ton site ? Pourtant, c’est
maintenant bien accepté que de rendre un site accessible bénéficie à
tous les utilisateurs et pas seulement aux déficients. Il me semble
qu’on est dans la même logique (toutes proportions gardées).

Traduire les
url ce serait donc se préocuper des 0.0001% des geeks qui ne
connaissent même pas l’anglais basique, bref c’est un peu du temps
perdu pour moi mais ça c’est juste mon avis of course :slight_smile:

D’où le post de E.Daspet avec lequel je suis tout à fait d’accord, ce
n’est pas la première priorité mais c’est un plus que l’on peut
prendre en compte à la fin.

Tron J.
http://jonathan.tron.name

nuno :

Bonjour, quitte à faire du RESTful je me dis que je pourrais franciser
les actions - Bonne idée ou pas ?

T’as plusieurs choix :

1/ Tu veux des URLs en français et ce n’est pas gênant si les actions
de ton contrôleur sont éventuellement toujours en anglais.

Donc t’as une ressource, on va dire maison. Dans routes.rb, t’as
mis map.resources :maisons

Bon, ben on a déjà fait la moitié du boulot.

Si on regarde les requêtes HTTP qu’on obtient on a :

index: GET /maisons
show: GET /maisons/1
new: GET /maisons/new
create: POST /maisons
edit: GET /maisons/2;edit
update: PUT /maisons/3
destroy: DELETE /maisons/1

Tout va bien sauf /maisons/new et /maisons/2;edit
Pour le deuxième, on voudrait bien GET /maisons/2;modifier
ça peut s’arranger :

map.resources :maisons, :member => { :modifier => :get }

ça correspondra à l’action modifier, on aura les url helpers
modifier_maison_{path,url}

L’action modifier soit appellera l’action edit (attention au double
render, à voir si ça marche), soit se débrouille comme un grand,
largement inspiré par le code de l’action edit.

De même si on a d’autres opérations sur les maisons ou sur
une maison en particulier, ben on les définit en français.

:member => { :telephoner => :get }

-> GET /maisons/4;telephoner

-> action telephoner (E.T. est un de nos utilisateurs :slight_smile:

:collection => { :cambrioler => :get }

-> GET /maisons;cambrioler

-> action cambrioler (c’est le premier exemple qui m’est venu Ã

l’esprit !)

Il ne reste plus que GET /maisons/new. On veut GET /maisons/nouveau
Honnêtement, pas testé, mais en rajoutant une route spécifique
(éventuellement
nommée), ça doit marcher. Et on définit nouveau dans MaisonsController.

Remarque : t’auras toujours /maisons/new, c’est gênant ou pas,
placer une route qui intercepte cette url avant le map.resources peut
marcher, Ã tester.

2/ Tu veux des URLs en français et tu tiens absolument à ce que
les actions de ton contrôleur soient en français

Alors là , à ta place, je ferais un plugin similaire à simply_restful :
simplement_restafarien (simplement_restien ? simplement_restal ?
simplement_restique ? restement_votre ?)
qui définit la méthode #ressources dans Mapper pour pouvoir écrire
dans routes.rb :

map.ressources :maisons # 3 s et non 2 s !

Tu reprends le code de action_controller/resources.rb et ça revient,
grosso
modo, Ã transformer les new en nouveau, edit en modifier, etc.
(classe Ressource, module Ressource)
Tu auras donc le nom des url helpers et des actions que tu souhaites.
Tu crées tes conventions.

Il restera par la suite, à faire une version adaptée du générateur
scaffold_resource (echaffaudage_ressource ?), qui suit tes
conventions françaises.

Bien sûr, le jour où tu voudras utiliser simply_helpful, ça marchera
pas, car il suit les conventions “normales” et non tes conventions
françaises. Il suffira de faire un plugin version française
(simplement_aimable ?), il y a 3 fois rien à changer par rapport
à simply_helpful.

-- Jean-François.

moi perso pour faire les url en français je ferais comme ça:

imaginons l’url:
http://monsite.com/products/screen/edit/42

dans mon routes.rb:
map.connect ‘/produits/ecran/modifier/:id’, :controller =>
‘products’, :action =>‘edit’,:producttype=>‘screen’

d’ailleurs, je ne suis pas certains mais si t’utilises gettext tu
pourrais peut-être faire:
map.connect _(‘/products/screen/edit/:id’), :controller =>
‘products’, :action =>‘edit’,:producttype=>‘screen’

et dans ton fr.po entrer la traduction de /products/screen/edit/:id
c’est à dire /produits/ecran/modifier/:id mais ça j’ai jamais éssayer.
En tout cas si ça marche ce serait cool pour gérer facilement des url
traduites en plusieurs langues. Quelqu’un sait si c’est possible?

Pat

Sounds simply_painful to me :wink:

Tu me vois déclarer retrieve_indemnites_de_transport()

Oui :

create_indemnite_de_transport()
retrieve_indemnite_de_transport()
update_indemnite_de_transport()
delete_indemnite_de_transport()

CRUD sont des mots clés auquels on ajoute nos identifiants métier.

Tout le mond peut mémoriser 4 mots-clé (ou même 40) et mixer les
langues
n’est choquant qu’au début.

Par contre, je retiens d’une de mes vies antérieurs de traducteur que
TOUTE
traduction introduit une ambiguité (traddutore-tradditore !) et un
éclatement des terminologies.

update_indemnite_de_transport() ==
met_a_jour_indemnite_de_transport() ?
modifie_indemnite_de_transport() ?
maj_indemnite_de_transport() ?
nouvelle_indemnite_de_transport() ?

pareil pour les autres…

C’est suivant le goût de chacun et on a perdu le lien évident avec CRUD.

D’ailleurs pour être exact :

create_indemnite_de_transport()
read_indemnite_de_transport() # et non retrieve
update_indemnite_de_transport()
delete_indemnite_de_transport()