Sur Google Map, les données de géolocalisation n’apparaissent pas par défaut. Voici donc un petit tutoriel très simple qui va vous permettre de facilement trouver la longitude et la latitude du centre de la carte affichée par Google Maps.
Lorsque vous avez localisé l’emplacement exact dont vous souhaitez obtenir la longitude et la latitude, faîtes un clique droit et sélectionnez « Centrer la carte ici ».
Ensuite, il ne vous reste plus qu’à coller le code Javascript ci-dessous dans la barre d’adresse de votre navigateur et de presser sur la touche Entrée de votre clavier :
javascript:void(prompt( »,gApplication.getMap().getCenter()));
Une boîte de dialogue apparaîtra et vous donnera les informations recherchées, que vous pourrez copier et coller dans l’application dont vous vous servez.
Si vous n’aimez pas utiliser le Javascript, il existe deux autres moyens d’obtenir la longitude et la latitude d’un lieu sur la carte, mais ces deux solutions nécessitent d’avoir un compte Google.
Connectez vous d’abord à votre compte Google, puis en haut de la page Google Maps, cliquez sur la petite fiole verte Google Maps Labs. 
En bas de la fenêtre qui s’ouvrira, vous devrez alors activer l’option Repère LatLng. Lorsque vous aurez trouvé l’emplacement qui vous intéresse, faîtes un clique droit sur la carte et choisissez « Ajouter un repère LatLng ». Un marqueur sera alors affiché sur la carte, avec la possibilité de copier coller la longitude et la latitude de ce point.
Enfin, une autre solution, moins précise et moins pratique celle là, consiste à activer l’option Info-bulle LatLng (toujours en passant par la petite fiole verte). Au survol de la carte, vous aurez en permanence la longitude et la latitude de tous les emplacements parcourus.
Archive pour le mot-clef ‘javascript’
Tutoriel Google Maps : obtenir la longitude et la latitude d’un emplacement
Mardi 14 septembre 2010L’iPad au centre des débats entre Apple et Adobe Flash
Mardi 23 février 2010
Lancé en grande pompe il y a quelques semaines, l’iPad se trouve au centre d’un polémique, voire d’une véritable guerre entre Apple et l’éditeur de la technologie Flash, Adobe. Steve Jobs, le patron d’Apple, le répète à l’envie : la technologie d’animation web est obsolète et, surtout, elle serait à l’origine de bugs qui feraient planter l’iPad. Verdict : la tablette numérique ne supportera pas les fichiers en Flash.
Mais la charge ne s’arrête pas là : Flash consommerait beaucoup trop de ressources processeurs, réduirait les performances de la batterie de l’iPad, présenterait des failles de sécurité et, surtout, serait en passe d’être remplacé par le HTML 5. Rien que ça ! En d’autres termes, le langage de programmation phare d’Adobe est bon à jeter à la poubelle, et le rendre compatible avec l’iPad serait une pure perte de temps.
Steve Jobs pousse le bouchon jusqu’à dire devant le Wall Street Journal que « Flash est un porc pour le processeur » et est aussi dépassé que les lecteurs de disquettes. C’est là l’une des nombreuses attaques portées contre Flash, toujours en petit comité dans le cadre de conférences de presse privées.
Preuve que Jobs s’avère être un homme d’affaire redoutable et ne recule devant aucun procédé pour arriver à ses fins. Si les sites lus sur l’iPad continuent d’utiliser la technologie d’Adobe, le dernier né d’Apple ne pourra afficher de nombreux contenus. Steve Jobs le sait et, à défaut de rendre l’iPad compatible avec Flash, il invoque les limites de cette technologie.
Mais n’y a-t-il pas un peu de mauvaise foi dans ces propos qui imputent à Adobe tous les maux du monde ? Le temps de cet article, faisons-nous l’avocat d’Adobe et reprenons, un à un, les arguments avancés par le patron d’Apple.
Sur le plan de la consommation d’énergie, les propos de Steve Jobs ne sont pas forcément dénués de sens. Flash est une plateforme qui, dans un souci de compatibilité, ne tire pas profit de la mémoire des cartes vidéo. Cette technologie consomme donc des ressources processeurs et, donc, énergétiques. Mais Flash est tout aussi gourmand que d’autres lecteurs de vidéo. Pointer Flash uniquement est réducteur, pour ne pas dire trompeur. Le blog ValleyWag le souligne d’ailleurs, précisant que les dix heures d’autonomie de l’iPad sont une utopie lorsqu’il s’agit d’afficher des formats vidéo.
Sur le plan de la compatibilité, Flash est utilisé par de nombreux lecteurs vidéo. C’est ainsi en Flash que sont développés les lecteurs de deux sites les plus importants en la matière : Youtube et Dailymotion. Une technologie vieille, dépassée et obsolète aurait-elle les faveurs de ces géants du web ?
Au contraire, l’utilisation du HTML 5 et de la balise < video > n’est pas lue par tous les navigateurs et est de toute façon beaucoup moins répandue que le Flash. Quand c’est le cas, ils ne le font pas de la même façon, en fonction du codec vidéo installé. Par exemple, Safari (le navigateur web d’Apple) et Chrome supportent le H.264 tandis que Firefox et Opera prennent en compte l’Ogg Theora.
Mais ce qu’oublie de préciser Jobs, c’est le format vidéo haute définition H.264 est une technologie brevetée nécessitant une licence d’exploitation qui ne permet pas de développer les mêmes environnements que Flash (animations, jeux, portfolios etc.). Surtout, ce format implique d’importants surcoûts là où Flash tend à l’économie.
De plus, limiter Flash à la seule lecture de vidéos est une nouvelle erreur. Cette technologie est utilisée par de nombreuses applications, comme les publicités dynamiques. On imagine mal les publicitaires revenir à l’ère du statique pour faire plaisir à Steve Jobs, celui-ci semblant perdu dans une réalité qui n’est que la sienne.
Accuser Flash de causer des bugs sur les Mac et qualifier par la même occasion les développeurs d’Adobe de fainéants est encore un faux problème. Ces-derniers l’ont d’ailleurs rappelé : Flash fonctionne parfaitement sur de nombreuses autres machines d’autres marques. Que Flash ne soit pas parfait est une chose, mais Apple inverse les rôles là où ses développeurs devraient plancher sur la compatibilité de leurs machines avec la technologie Flash. Une éventualité à laquelle Steve Jobs préfère l’attaque frontale.
Enfin, sur le plan de la sécurité, quel logiciel aussi répandu que Flash n’est pas bogué et ne présente pas de failles de sécurité ? Les hackers ne manquent pas d’imagination pour pirater n’importe quel code informatique. Mais réduire le problème à Flash est indigne d’un grand professionnel de l’informatique comme l’est Steve Jobs.
Si les raisons invoquées ne semblent donc pas si solides, c’est parce qu’il faut voir dans ce procès fait à Flash d’autres intentions, inavouées celles-là.
La première motivation de l’attaque contre Flash est que ce langage n’est pas ou peu compatible avec les fonctions tactiles de l’iPad comme le souligne Morgan Adams, développeur spécialiste de Flash. La cause est une propriété fondamentale de Flash, le « mouseover », qui change l’affichage d’un objet au survol de la souris. Or, que ce soit sur iPhone ou iPad, il n’y a pas de curseur. Il est donc impossible de déployer les objets survolés par cet hypothétique curseur. Quoiqu’il en soit, Apple pourrait décider d’afficher Flash même si dans la plupart des cas, l’utilisateur ne pourrait pas interagir avec le contenu.
Quel que soit le succès rencontré par les produits d’Apple, l’iPhone en tête, il parait peu probable qu’ils finissent par remplacer nos bons vieux ordinateurs de bureau et autres portables. La solution idéale serait qu’Adobe et Apple travaillent de concert pour rendre le mouseover compatible sur iPhone et iPad. D’ailleurs, le rendu de la fonction Javascript mouseover est à peu de choses près supporté sur iPhone.
Mais les récentes invectives de Steve Jobs à l’encontre d’Adobe ne laissent guère présager une future collaboration entre les deux firmes.
Notamment quand on évoque une seconde raison de cette bataille à mort dans laquelle semble s’être lancé le patron d’Apple : on compte plus de 140.000 applications disponibles sur iPhone, parmi lesquelles de nombreux jeux vendus sur l’App Store. Or, Flash est largement utilisé pour créer de petits jeux gratuits parfois très populaires, et qui empièteraient donc sur les plates-bandes d’Apple. Steve Jobs écarte d’emblée cette concurrence là sous couverts d’arguments purement opportunistes.
Dans tous les cas, cette polémique fait parler de l’iPad et c’est bien là le premier soucis de Steve Jobs qui, en plus d’écarter la concurrence de Flash d’un revers de main, s’offre le luxe d’une belle campagne de promo gratuite à-travers ce buzz.
Comment référencer un site web multilingue
Mercredi 27 janvier 2010
Le développement d’un site web en plusieurs langues demande quelques ajustements pour optimiser le référencement naturel. A titre liminaire, il convient tout d’abord de noter que les techniques de référencement se ressemblent d’un pays à l’autre. L’algorithme des moteurs de recherche fonctionne en effet de la même manière dans toutes les langues. Au-delà du contenu qui s’adresse à des utilisateurs de différents pays, c’est bien sur la structure du site que repose la principale différence avec le référencement d’un site internet monolingue. Cet article vous propose quelques conseils à suivre pour vous assurer que votre site web multilingue est préparé au mieux pour être référencé.
La question de l’hébergement de votre site
Idéalement, un site web doit être hébergé sur un serveur situé dans le pays de votre marché cible. Pour des raisons de rapidités, mais surtout pour garder une cohérence à laquelle les moteurs de recherche sont sensibles. L’hébergement d’un site multilingue doit être géo localisé. Un site à destination de la France sera sur un serveur avec une IP française, un site à destination des Etats-Unis sera sur un serveur avec une IP américaine et ainsi de suite…
Certains hébergeurs proposent de choisir la géo localisation de l’IP, ce qui permet de réduire le nombre d’hébergements nécessaires.
La structure de votre site web multilingue
Plusieurs choix s’offrent à vous. Pour ne rien faciliter, chaque structure retenue présente des avantages et des inconvénients.
Les trois solutions que j’aborderais ici sont :
- un nom de domaine par langue
- un répertoire par langue
- un sous-domaine par langue
1 – Un nom de domaine par langue
Souvent présentée comme la meilleure solution, cette technique consiste à avoir un nom de domaine par langue : www.site.fr pour la version française, www.site.com pour la version anglaise, www.site.cn pour la version chinoise etc.
L’avantage est qu’avec cette technique, le moteur de recherche pourra indexer indépendamment chaque site. Pas de problèmes en terme de géo localisation puisque vous pourrez héberger chaque site sur des IP des pays ciblés.
Un inconvénient est évidemment le coût de cette solution car vous devrez acheter autant de noms de domaine qu’il y a de versions de votre site. Il faut également, pour certains pays, avoir une autorisation juridique pour acheter un nom de domaine dans l’extension du pays. Par exemple, difficile d’avoir un nom de domaine en .fr sans une adresse physique en France.
La question de la disponibilité des noms de domaine se pose également. Un nom disponible en .fr ne le sera pas forcément dans sa version .com.
Enfin, pour les pays bilingues, voire trilingue comme la Suisse, un problème se pose : on ne pourra pas avoir trois versions (italien, français, anglais) sur le .ch de votre site web.
2 – Un répertoire par langue
La deuxième solution, qui consiste à créer sur un domaine unique un répertoire par langue est à évacuer d’emblée, les inconvénients dépassant largement les avantages. En utilisant cette technique, vous aurez un site sous la forme www.site.com/fr pour la version française, www.site.com/en pour la version anglaise, www.site.com/cn pour la version chinoise etc.
L’avantage est de réduire les coûts car vous n’aurez à prendre qu’un nom de domaine et qu’un hébergement, mais les moteurs de recherche ne verront qu’un site et cela risque de ne pas jouer en votre faveur en termes de référencement, alors surtout que la page d’accueil s’affichera dans la langue par défaut. En outre, la géo localisation s’avèrera impossible du fait de l’hébergement unique.
3 – Un sous-domaine par langue
Cette solution pour un site web multilingue est un très bon compromis entre les deux premières. Personnellement, c’est celle que j’aurais tendance à recommander. Cette technique consiste à créer un sous-domaine par langue disponible : www.fr.site.com pour la version française, www.en.site.com pour la version anglaise, www.cn.site.com pour la version chinoise etc. Par mimétisme également, c’est la solution que j’aurais tendance à choisir dans la mesure où Yahoo et Google (pour Wikipedia) l’ont en effet adoptée.
La structure d’un site web multilingue avec sous-domaines présente en effet les avantages de la première solution, car chaque sous-domaine se comporte comme un site web indépendant, et ceux de la solution 2 en terme de réduction des coûts. Vous pourrez également respecter le principe de géo localisation en hébergeant chaque sous-domaine sur une IP différente.
De la même manière qu’avoir un nom de domaine par langue, cette solution favorise le linking entre sites.
Si vous retenez cette solution, assurez vous que votre hébergeur ne facturera pas des frais supplémentaires pour la création de chaque sous domaine.
La détection automatique en fonction de la langue de l’internaute
Cette méthode consiste à mettre en place un script Javascript ou PHP de détection automatique de la langue du navigateur utilisé par un visiteur. En fonction de la langue détectée, une redirection automatique se fait vers la version du site dans la bonne langue.
Voici un code PHP de détection automatique de la langue :
$lang = explode(”,”,$HTTP_ACCEPT_LANGUAGE);
$lang = StrToLower(substr(chop($lang[0]),0,2));
Et pour le code Javascript permettant d’effectuer une redirection :
<script LANGUAGE=”JavaScript”>
<!–
if (top==self) {
if (navigator.appName == ‘Netscape’)
//Reconnaitre le type de navigateur
var language= navigator.language;
else
var language = navigator.browserLanguage;
if (bl == “fr” || bl == “fr-be” || bl == “fr-ca”
|| bl == “fr-lu” || bl == “fr-mc” || bl == “fr-ch”)
//il faut penser aux variantes de la langue {
this.location = “default.php?lang=fr”
}
else
this.location = “default.php?lang=en”
} //–>
</script>
L’URL rewriting
Bien entendu, il faudra penser à écrire vos URL de manière à les optimiser pour le référencement naturel. Par exemple, ne choisissez pas une URL de type www.en.site.com/location-de-voiture.html mais plutôt www.en.site.com/rent-a-car.html
Cela peut paraître une évidence, mais pour avoir vu certaines erreurs de ce type sur des sites multilingues, je préfère le rappeler.
Faire un audit sémantique
Prenons l’exemple d’un site français pour lequel vous souhaitez réaliser une version anglophone. Une traduction littérale pourrait s’avérer très handicapante pour le référencement naturel de votre site sur le marché anglophone car les mots-clés utilisés par les internautes pour trouver votre site ne seront pas forcément les mêmes. Il faut donc prendre en considération les habitudes des internautes anglophones en choisissant les mots-clés les plus appropriés.
Gardez à l’esprit qu’un mot ou expression ne sera pas forcément le même pour un anglais et un américain. « Colour » en anglais UK deviendra « Color » en anglais US ; « Jewellery » s’écrira « Jewelry » etc.
Pour une même langue, certaines désignations ne sont pas les mêmes également selon le pays où l’on se trouve. Des « barniques » désignent des lunettes au Québec. Un aspirateur deviendra une « balayeuse ». Les exemples ne manquent pas et des différences existent également pour le français de Suisse ou de Belgique. Idem pour la langue de Goethe, qui ne sera pas toujours la même selon que l’on se trouve en Allemagne ou en Autriche par exemple.
Une traduction effectuée par une personne native du nouveau pays ciblé peut certes s’avérer coûteuse, mais à terme, c’est sans aucun doute la meilleure solution. En effet, un mauvais contenu pénalisera votre site non seulement à l’égard des moteurs de recherche, mais aussi à l’égard des internautes qui n’auront pas ou peu d’intérêt pour un site mal écrit. A défaut de traducteur, faîtes relire votre contenu par un natif du pays auquel vous vous adressez.
La question des backlinks
Les backlinks sont sans aucun doute la pierre angulaire du référencement. Pour un site multilingue, il faudra redoubler d’efforts car il y a autant de pages à référencer qu’il y a de versions du site. Pour qu’ils soient efficaces, les liens qui pointent vers votre site doivent être placés sur des pages dont le contenu et la langue soient cohérents avec votre site.
Avoir un lien de la version anglaise de votre site sur une page en français est une « erreur » comparable à celle qui consiste à obtenir un lien sur un site immobilier pour votre page traitant de chirurgie dentaire. Il faut donc veiller à placer vos liens sur des sites web dont le contexte, tant rédactionnel que linguistique, s’apparente au vôtre.
Les erreurs à ne pas commettre
Même si cela peut paraître relever de l’évidence même au même titre que l’URL rewriting, l’erreur la plus grossière en matière de site multilingue consiste à proposer plusieurs langues sur une même page du site. Les différentes versions du site doivent bien entendu être dissociées.
