Aller au contenu

shumisha

Actif
  • Compteur de contenus

    18
  • Inscrit(e) le

  • Dernière visite

Réputation sur la communauté

0 Neutre
  1. Oui, c'est dans les recommendations que l'on peut trouver dans Webmaster help center : Cordialement
  2. Bonjour, Oui, ça ne pose pas de problème. Bien sur, je peux imaginer que les résultats seraient meilleurs avec un domaine par langue, mais pour des petites structures, gérer un domaine et un hébergeur (pour avoir l'ip locale) dans 10 ou 15 pays, ce n'est pas raisonnable (pour nous, ES = 5 pays, FR = 3 pays, EN = une dizaine). Un site, un hébergeur, toutes les traductions dans la même interface, bien rangées, une seule sauvegarde globale, c'est infiniment plus simple... Cordialement
  3. Bonjour, et merci de ta réponse. Bon je vais donner un peu plus de détails : Si, dans tous les cas toutes les langues sont accessibles depuis toutes les pages, car des drapeaux présents sur chaque page permettent d'accéder à la même page dans toutes les langues. Donc que ce soit les visteurs ou les moteurs de recherche, il n'y a pas de problème d'indexation. Pour être clair, il s'agit de sites Joomla, et j'en exploite plusieurs de cette manière depuis plusieurs années, donc je sais par expérience que l'indexation des différentes langues ne pose pas de problème. La redirection initiale n'est là que pour le confort. Le visiteur peut changer lui-même de langue à son gré, et son choix est bien sur sauvé dans un cookie pour sa prochaine visite. Google ne prend pas le cookie, donc on l'envoie sur la langue par défaut, mais les drapeaux déjà mentionnés lui permettent d'accéder aux autres langues. Dans la version actuelle, il n'y a pas redirection, mais le cms renvoie la page dans la langue déterminée par le HTTpP accept (encore une fois, lors de la première visite : dés que le visiteur clique sur un drapeau, son choix est conservé par cookie). Cela fait que suivant les cas, la même URL (www.monsite.com) peut renvoyer une page en FR, EN ou ES. Il me semble que les moteurs de recherche (google.fr, .com, .es) ont des bots avec un HTTP ACCEPT différent, non ? Dans ce cas, cela signifie que les différents bots de Google vont voir un contenu différent pour la même page,et quand tout cela va être regroupé dans l'index unique de Google, cela ne nous sera pas favorable. D'où l'idée d'une redirection "propre". J'ai cherché un peu, vu que plusieurs gros sites faisaient dans ce cas des 302 (Google.com comme déjà cité, www.ibm.com aussi,...) ce qui me parait logique. La 303 me parait encore plus logique, mais je ne sais pas si elle est bien supporté. Merci de m'avoir lu, j'espère que c'est plus clair maintenant Cordialement
  4. Bonjour à tous, Je gère notamment des sites multi-langues sur un même domaine, dans lesquels les différentes versions sont réperées par des codes iso : www.monsite.com pour la langue par défaut, www.monsite.com/en/ pour l'anglais, /es/ pour l'espagnol, etc Créer une tld par langue comme préconisé par Google n'est pas envisageable pour diverses raisons. Chaque page dans chaque langue comporte des petits drapeaux pour que le visiteur (y compris les moteurs de recherche) puissent accéder à toutes les langues à tout moment. Au niveau de l'accès initial au site (le visiteur qui tape www.monsite.com pour la première fois, à la racine ou n'importe où dans l'arborescence), nous voudrions le rediriger vers la page correspondante dans sa langue supposée, en fonction du HTTP ACCEPT de son navigateur. La question que je me pose est de savoir quel type de redirection est préférable, du point de vue de l'optimisation des résultats de recherche : 301 me paraît exclut, je penche pour 302 (Google.com par exemple fait cela pour nous renvoyer vers google.fr, et j'ai trouvé d'autres exemples) et en lisant la définition peut-être 303, mais je ne la vois pas utilisée Je n'ai pas trouvé de réponse franche, ni récente, et toute information ou expérience de votre part serait très appréciée ! NB: la question ne porte pas sur le comment faire cette redir, cela ne pose pas de problème. C'est vraiment : quelle type de redirection est la plus efficace ? Cordialement
  5. Bonjour, Ma réponse serait aussi Joomla, qui propose tout ce que tu demandes en standard ou avec des composants additionnels très courants (y compris module de recherche ajax). En particulier, pour une communauté de 50 personnes, tu n'as même pas besoin du bridge SMF ou du bridge PHPBB, mais Joomlaboard, qui s'intalle en un clic, fera très bien l'affaire, en s'intégrant directement dans ton ou tes templates de page qui plus est, c'est à dire sans avoir à refaire de css.
  6. J'examine toutes ces possibilités en ce moment, et je confirme absolument ce que vient de nous dire brocexco. Toute activité rémunératrice entraine cotisation. Dans ton cas, la déclaration en tant que travailleur indépendant est la bonne solution certainement, et c'est l'urssaf qui recevra ta demande. Il existe beaucoup d'information sur internet, dont les sites déjà listés. Par rapport à l'urssaf (qui est à la fois CFE, centre de formalité des entreprises, pour les prof. libérales et collecteur de cotisations), ils te diront que tu peux être exonérés de cotisations la première année, et ensuite tu peux étaler le paiement sur 5 ans à partir de la deuxième année. C'est vrai, mais il faut aussi contacter : - les impots (TVA, et surtout Taxe professionnelle dont tu es exempté la première année mais à laquelle tu ne peux pas échapper à partir de la deuxième), - le CIPAV, qui gère les retraites des professions libérales (tu peux y echaper si tu restes salarié en parallèle, avec au moins 450 heures d'activité salarié dans l'année, et que tes revenus salariés soient supérieurs à ceux de ton activité libérale) - la CAMPLP, caisse d'assurance maladie des professions libérales, tu peux aussi y échapper si tu restes salarié, avec le même genre de condition Chacun de ces organismes prélève des cotisations obligatoires, il n'y a pas que l'urssaf!
  7. Effectivement, les composants écrits par des tiers ne suivent pas tous forcemment les règles requises pour produire des URL correctes. Avoir beaucoup de composants externes est une des forces de Joomla, c'est aussi une faiblesse bien sur, dans la mesure où c'est très facile à faire puisqu'il n'y a qu'à connaître PHP et HTML/CSS. Alors tout le monde ne suit pas toutes les règles ! Cela dit, si le composant en question est courant, il est souvent facile de faire, ou faire faire la modif par quelqu'un dans la communauté . PS : Je ne sais pas ce que tu entends pas "titrés"
  8. Non, c'est plutôt la tendance, encore plus dans la version 1.5 qui devrait sortir ... bientôt. Beaucoup de fonctions sont déplacées dans des plugins, comme le multilingue ou donc le SEF. Il y a toujours eu des histoires très compliquées à propos des url 'significatives' dans mambo, puis joomla, à cause du fait que SEF Advanced est créé et vendu par un membre de la core team. OpenSEF est une sorte de réponse à ça, je pense, également maintenu dorénavant par un membre de la coreteam. Il y a également eu beaucoup de discussions sur le "poids" des urls significatives, que ce soit dans les forums joomla, ou sur webmasterworld, ou webrankinfo, et bien souvent le résultat des courses était que c'était un point positif, mais sans plus. Le contenu lui-même, les BL, etc semblent être des facteurs infiniment plus important. Par exemple, si l'on recherche 'mambo url rewriting', on trouve des quantités de messages postés dans les forums avec des url genre forum.joomlafacile.com/archive/index.php?t-1098.html, pas spécialement siginificative. Le résultat a été que l'URL rewriting "de base" de joomla n'est jamais allé plus loin que ce qui est décrit plus haut. Personellement, j'ai deux sites mambo,l'un avec l'url rewriting de base, l'autre avec 404SEF (un autre composant GPL similaire à SEFAdvanced, j'y pense maintenant), et j'aurai du mal à dire que l'un fait mieux que l'autre dans l'évolution du positionnement. Mais ce n'est qu'un exemple bien sur.
  9. Non, Joomla inclut en standard des URL rewritées, qui remplacent les index.php?xxxxx par du ihttp://www.domain.com/content/view/689/79/ Il y a ensuite un bot standard (GPL) qui permet de faire du rewriting plus sophistiqué (www.domain.com/nomsection/nomcategorie/titreoualiasarticle.html et du même ordre, il y opensef (GPL), dont la version 2 est en RC4 à ce jour, qui donne encore plus de liberté dans la construction des URL, car on peut les saisir à la main complètement si on veut. Le module payant auquel vous faites allusion est SEF advance, qui est similaire à OpenSEF
  10. Perso, je te conseille aussi Joomla. Ton design ne comporte que des éléments standards ou des modules disponibles dans Joomla, donc tu n'auras qu'à créer la feuille de style, c'est à dire transcrire tes styles existants dans ceux de Joomla. Tu bénéficieras aussi du bridge vers phpBB, si par exemple tu veux avoir des utilisateurs enregistrés sur ton site avec des éléments qui leurs sont réservés,et leur login commun avec phpBB
  11. Votre avis m'interesse sur Joomla en Intranet. Pourriez-vous développer SVP : 1 - Quels sont les composants qui ne fonctionnent pas en Intranet ? 2 - Dans quelles applications la vitesse est-elle un pb ? il y a des sites internet sous Joomla qui traitent 50 000 visiteurs distincst /jour avec des downloads assez importants. Quelle taille d'intranet constituerait un maxi d'après votre expérience ? Par avance merci
  12. et surtout de tous les composants et modules disponibles. Ce sont eux les plus difficiles à faire passer en "accessible". Joomla a cet objectif dans sa roadmap pour la fin de l'année, ou plus surement 2007. Mais tous les auteurs de composants doivent faire le même effort. Et ça c'est plus difficile
  13. Oui, justement, c'est le principe. C'est toi qui y passe du temps, pour que eux ne s'en occupent pas du tout. Il faut effectivement définir les classes pour ceux des "éléments" standards que l'on va utiliser... C'est pas pour absolument tout de suite je pense. En attendant, on peut déjà créer les templates en 100% CSS/XHTML, etc...
  14. Je ne parle pas de prendre un template standard et faire rentrer les infos du client dedans, mais bien de prendre les infos du clients et de faire un template adapté à leur affichage. La simplicité et la rapidité de réalisation d'un template sont l'un des points forts de Mambo/Joomla. Qui plus est , je ne parle pas de look standard. Mambo/Joomla excelle justement dans le look non-standard. Et je parle évidemment uniquement de sites profesionnels. Là où le bât blesse (un peu) c'est lorsque qu'il faut faire appel à des infos dynamiques type base de données produits, etc, c'est à dire des données qui ne sont pas prises en compte directement par Mambo/Joomla ou un composant existant. Je te rejoins évidemment sur cette partie, qui est commune à tout bon travail et est justement la valeur ajoutée du bon professionnel. Mais cela n'a pas de lien direct avec l'outil utilisé. Lorsque la structuration de l'information est établie, on construit effectivement le gabarit, et la méthode utilisée par M/J permet d'obtenir un résultat très rapidement. Les prix baissent effectivement, et donc la productivité à chacune des étapes est chaque jour plus importante !
  15. Bonjour ! Encore une fois, je suis surpris de lire que Mambo/Joomla est "pénible" ou "inefficace" au niveau de la création de template. Je crois qu'il faut faire la part des choses et bien identifier le besoin. Si l'on parle d'afficher un catalogue produit en allant chercher dans une base Mysql le nom, les caractéristiques, le prix ou je ne sais quoi d'autre, là c'est peut-être plus difficile qu'ailleurs car cela revient finalement à créer un composant ou un module (sauf justement à utiliser un composant déjà existant) Par contre, si l'on parle de 80% des sites où l'on va afficher des articles, des news, des photos, des animations flash, des bannières, adsense, etc, la création de template est vraiment la plus simple et surtout la plus rapide que je connaisse (j'en connais quelques uns quand même), et ce quelle que soit la disposition, le layout souhaité. En gros, il faut créer le gabarit en HTML/CSS, et c'est tout. Si l'on reste donc dans le domaine d'application correct (données nécessitant peu de traitements comme déjà indiqué : tests conditionnels, requetes spécifiques), au contraire, pour moi, Mambo/Joomla est le plus "efficace", et donc les prix seraient plutôt à -20% qu'à +20% !
×
×
  • Créer...