Jump to content

violy

Members
  • Posts

    15
  • Joined

  • Last visited

Profile Information

  • First Name
    Arthur
  • Last Name
    Violy

violy's Achievements

Newbie

Newbie (1/14)

2

Reputation

  1. J'avais proposé une Pull Request sur GitHub, sur la version 1.6 mais celle-ci a été close. https://github.com/PrestaShop/PrestaShop/pull/2602
  2. I find a solution. My initial problem is to make a single translated selector for countries + countries languages. Each countries where a shop exists is a Shop entity, with languages supported in this country. also, each of this Shops have a virtual_uri, based on iso_code. And so, I map the virtual_uri converted as iso_code with the Countries table, who is translated. But it's a trick thank you.
  3. Thank you, I find this field, i don't look the translation selector ?
  4. Hi. I've a multisite configuration, with multiple zones and multiple shop, corresponding to all my shops around the world, in different languages. But the shop name is unique, with no translations options. What is the best option to translate this "shop name" ? thanks.
  5. Prestashop est installé par défaut avec plus de 240 pays, associés à leurs codes ISO. le nom de chacun est traduisible et on peut modifier son nom. c'est très bien mais j'ai eu une mauvaise surprise lors de mes traductions. Quand j'ai ajouté mes 9 nouvelles langues, les pays n'ont pas été traduits. toutes mes traductions affichent le nom du pays en français... N'existe-t-il pas des traductions qui serait prêtes à l'emploi pour les pays ? et installées avec les packs de langue ? ai-je raté quelque chose dans ma configuration ou ajout de langue ? ça fait quand même 240 pays à traduire dans 10 langues … à la main c'est long ?! merci de votre aide.
  6. attention aussi, il y a une différence entre "un panier" et "une commande" est-ce que le client doit passer commande sans payer (où à 0€) ? ou bien en mode "payer à la livraison" ? où bien est-ce purement une logique d'affichage : le client fait un "panier" et il ne passe jamais commande. au quel cas c'est simplement une problématique d'affichage.
  7. À titre personnel, je suis intégrateur, et j'ai souvent eu la question de la traduction de contenu, PrestaShop n’a rien de simple en terme de traduction, par moment il est très pratique, à d'autre pas du tout. Il y a a deux gros mode de traduction : - la traduction des templates (front-office et module, cf post de stopher) - la traduction des contenus (prodiuit, CMS, etc) Certaines fonctionnalités de traduction font défaut : - pas de dictionnaire global (si je veux utiliser une traduction de "category" ou "next" dans un module, il faudra traduire pour chaque module - pas de système de gestion de progression des traductions des contenus (on ne peut pas savoir "ce qu'il reste à traduire" - toutes les traduction se font via backoffice (avec enregistrement dans des fichiers éparpillés un peu partout…) pas de possibilité d'utiliser un éditeur comme PoEdit par exemple.
  8. Bonjour, J'ai un problème assez basique il me semble, mais qui m'amène à penser que le système de traduction de Prestashop est parfois assez complexe, mal documenté, lacunaire… ou bien c'est moi ! Venons en au fait, j'ai voulu — dans le cadre de développement d’un module — afficher sur le front un <select> avec une liste des 12 mois traduit dans les langues de mes boutiques. j'ai donc utiliser la fonction Tools::dateMonths dans mon controller : $this->context->smarty->assign('date_months',Tools::dateMonths()); puis dans mon template smarty : <select name="month">{foreach $date_months as $m=>$month}<option label="{l s=$month mod='mon_module'}" value="{$m}" ></option>{/foreach} je pensais que je pourrais ensuite traduire mes mois dans les traductions du module. il n'en n'était rien. j'ai donc trouvé un fix, rajouter au sein de mon template, manuellement, en dur et en commentaire, les mois à traduire. <!-- {l s='January' mod='mon_module'} --> <!-- {l s='February' mod='mon_module'} --> <!-- {l s='March' mod='mon_module'} --> <!-- {l s='April' mod='mon_module'} --> <!-- {l s='May' mod='mon_module'} --> <!-- {l s='June' mod='mon_module'} --> <!-- {l s='July' mod='mon_module'} --> <!-- {l s='August' mod='mon_module'} --> <!-- {l s='September' mod='mon_module'} --> <!-- {l s='October' mod='mon_module'} --> <!-- {l s='November' mod='mon_module'} --> <!-- {l s='December' mod='mon_module'} --> Mais donc voilà, c'est quand même sacrément capilotracté pour afficher la liste des mois ? Qu'en pensez vous, comment faire mieux ? Comment utiliser des traductions du contexte global (qui seraient présente dans les imports de langues) Merci d'avance.
  9. hello #PrestaShopDay is somebody here ?
  10. Bonjour, quelques questions : quel est votre hébergeur ? quelle est la nature de votre hébergement (dédié, mutualisé, cloud, …) quelles version(s) de PrestaShop utilisez-vous ?
  11. Malheureusement, il ne s’agit pas uniquement d’un travail sur les images. Imaginez seulement un theme qui exigent plusieurs ratios d’image différents, carré par endroit, paysage à d’autre, portrait à d’autre. Si ça vous semble farfelu, je vous assure que je vis ce problème en qualité d’intégrateur au sein de mon agence, sur de multiples boutiques. Je vous concède que ça ne simplifie pas la vie, mais le cas est fréquent dans notre agence. pour répondre à votre dernière remarque, je précise que ces options ne seraient pas gérées image par image, mais par type d’image (class ImageType) j’ai créé une issue dans la forge http://forge.prestashop.com/browse/PSCSX-4894 j’en ai profité pour soumettre une nouvelle idée, dans la même veine, un encodage de destination propre à chaque type d'image. ainsi, une miniature pourrait être en PNG pour préserver la qualité, une image HD serait en JPEG pour rester légère. Aujourd'hui, cette gestion est tout ou rien, pas forcément très optimisé. je vais essayer de programmer ça !
  12. Je pense que cela dépend énormément des secteurs d’activités, et du design de la boutique. Quelques exemples que j'ai en tête : des produits blancs (tshirt, dessin sur papier, …) des produits où les bandes sont traditionnellement noires (cinema, photographie) et les formats ne répondent en rien à mes demandes en terme de redimensionnement/crop en effet, si j'utilise des photographies non détourées pour mes produits, et que ces photographies peuvent être en format portrait ET en paysage (j'ai en tête les photos d'un site d'immobilier) j'aurais aujourd'hui nécessairement des bandes, et nécessairement blanches. je sais que proposer un choix sur cette couleur et ce mode de redimensionnement n'est pas très compliqué à développer, et que l'implémentation est totalement rétro-compatible. Je comprends qu'un certain nombre de personne s'en passe depuis des années, mais n'est t'on pas là pour améliorer ? merci.
  13. hello. I'm a french front-end developer, works in a web-agency, works in team with Prestashop framework, on many projects. I've recently participated at the official « Prestashop integrateur niveau 2 » (front-end level 2) lesson. here is my opinion : the Javascript usages in Prestashop are very deficients. some topics : massive usage of global scope, function and variable no dependencies management theme js/autoload directory : cool for starters dev, wrong for pro dev no alternative to autoload mechanism in theme. hard dependencies on many jQuery plugins (fancybox, …) in theme usage of inline javascript call in link <a href="javascript:[…]"> usage of inline javascript tag <script></script> usage of ugly* name for functions and variables names, any guideline for those names ? I know that the retro-compatibilities are very hard, specially in front-end development. I know that prestashop is a PHP Framework, made by backend dev. * When i say ugly names (all those functions have a global scope, in default-bootstrap theme) : get (yes, get function is also a part of ECMASCRIPT, never-mind) submitFunction (yes, this function must submit something, may be a function, or maybe this function is a function ?) display (this function must display something ! but what !) dropDown (a jqueryPlugin for that, too much simple) totalValue (this function must calculate something…) accordion (this function is not a var, this is not a jQuery plugin, this is accordion) accordionFooter (this function is only a fork of the well known accordion function) blockHover (this function is not a block initiator, not a hover event callback, maybe both of them, but nobody knows the block) quick_view (yes, underscore is a cool thing — sometime) function_exists (you are not in PHP environment, don't care) totalValue (the total value of everything, everything) deleteProductFromSummary (AllYourBaseAreBelongToUs) refreshOddRow (refreshing stuff is very cool, specially HTML table row) … If you are PHP dev, imagine use those functions in global scope, with global vars… I'm the only front-end who practice a modern Javascript here ? Is there a project for javascript developers in the forge ? thank you.
  14. Bonjour, je suis nouveau sur ce forum ! J'ai suivi une formation intégrateur niveau 2 prestashop je voudrais participer au projet OpenSource, et mon formateur m'a invité à participer, ça fera même gagner des points à mon agence si on faisait un Pull Request ! Il m'a dit que je devais procéder comme ça : aller voir sur le forum, chercher, et pourquoi pas en parler. aller voir sur la forge, rechercher si l’issue est présente (elle l'est partiellement) si la demande n'est pas présente, la créer si je me sens capable de le faire, coder l'amélioration et proposer un Pull Request ça c'est la théorie, et j'ai à peu prêt compris. Venons en maintenant à la pratique, je résume ma demande : les redimensionnements des images sont vraiment très lacunaires ils ne gèrent pas de mode de redimensionnement (cover, contain, no_resize, adjust) ils ne gèrent pas d'alignement du redimensionnement (top, bottom, left, right, center) par défaut, le fond débordant est blanc. pas moyen de sélectionner une autre couleur. ce dernier point étant déjà reporté dans une issue du projet 1.5 j'aimerai donc avoir dans les options des formats d'image, un select pour le mode de redimensionnement (par défaut contain) un select pour l'alignement du redimensionnement (par défaut center center) un colorpicker pour la couleur d'arrière-plan en cas de bande-noire (blanche actuellement !) Cette amélioration est totalement rétro-compatible, je pense ? Ce sont donc 3 points qui sont liés (il affecte la même partie du code) mais qui correspondent à 3 fonctionnalités. Dois-je soumettre 1 ou 3 issues pour ces nouvelles fonctionnalités Si la demande que j'ai trouvée sur la forge est sur le projet 1.5, est-ce que ça rend cette demande obsolète ? ​si c'est le cas, dois-je créer une nouvelle demande dans le nouveau projet ? associer cette demande à l'ancienne ? déjà beaucoup de questions donc ! merci d’avance, et n'oubliez pas que je suis newbie !
×
×
  • Create New...