urecheatu007

Eu unul sunt perfect de acord cu aceste 2 reguli. Intern, la serviciu, exact asa facem traducerile pentru siturile clientilor. In masura in care cadem de acord ca ramane asa, ma voi apuca in viitorul apropiat sa re-contribui la traducerea oficiala de pe crowdin

Fontul self-hosted inseamna ca e un font care e copiat pe server, in general in tema (eu creez un folder font in paralel cu img, css etc din tema si acolo pun fisierele fontului si declaratia @font-face cu calea corecta e in fisierul css de baza al temei chiar la inceput). Kiturile @font-face de la font squirell vin cu un demo in arhiva, trebuie doar sa modifici calea (adaugi ../font/ in fata numelui fisierului fontului din blocul @font-face), urci fisierele in folderul font din radacina temei (tu il creezi) si setezi fontul fie la declaratia html fie la body, aici depinde de tema. Sigur se gasesc si tutoriale pe web pt asta. Ideea cu fonturile self-hosted e ca fiecare client isi ia si isi instaleaza fontul dat de tine, cel testat si verificat de tine in prealabil, astfel ca ai un nivel de incredere ridicat ca vor vedea textul asa cum intentionezi tu.

Problema este de la font in sine. Singura solutie este sa folosesti un altul cu suport corect pentru diacriticile romanesti. Cum anume inlocuiesti fontul e alta poveste, depinde de felul in care il servesti : via javascript (google fonts and co.) sau self hosted. Pentru fonturi self-hosted poti filtra de ex pe font-squirrel dupa fonturi cu subset de romana, nu sunt chiar multe, si acelea vor merge ok cu diacriticile romanesti. La google fonts nu mai tin minte pt ca nu folosesc decat fonturi self-hosted (@font-face). PS: ar mai fi o a treia posibilitate: fontul folosit nu este decat listat in font-family si am intalnit chestii din astea cu diacriticile "fukuite" cand primul font listat nu suporta diacriticile respective si browserul le inlocuia pe alea cu urmatorul font din lista, ceea ce nu tin minte sa fie comportament chiar conform standardelor dar se intampla. In orice caz, recomandarea mea e sa folosesti font cu suport complet pt diacriticile romanesti servit cu @font-face, e solutia cea mai buna din punct de vedere tehnic.

Off course you just need to enable the features needen for filters in the layered module in the corresponding filters template. The module works like this: you have templates that are applied for different sets of categories. For each template you can select what filters you want to display (the common ones, features and attributes) and how and in which order. When you enable the layered module you get a defaut template applied to all your categories with just the common stuff enabled (like price, condition, manufacturer). You could edit that template and select to display your desired features or you can delete it and create new ones for sets of categories.

O lista de reguli pentru traducere ar fi nu numai bine venita ci chiar necesara de la un anumit punct incolo. Deja traducerea Prestashop nu mai e chiar simpla de facut avand in vedere numarul de stringuri (undeva peste 20k - depinde si de module) + mailurile, ceea ce face abordarea traducerii integrale din perspectiva unei singure persoane un pic intimidanta. PS: prima traducere pt presta am facut-o pt 1.2.4, asa ca am o idee destul de buna legata de evolutia textelor din presta. PS2: sunt membru in echipa de traducere de pe crowdin din mai , doar ca sistemul asa cu propunere stringuri si eventuala lor aprobare ulterioara de altcineva care le urmareste nu e usor de digerat. Stiu din experienta ca nu e tocmai usor, sunt de cativa ani moderator pt limba romana la drupal, si parcurgerea / editarea / urmarirea a cateva mii de propuneri in fiecare zi nu e tocmai cel mai placut lucru de pe fata pamantului. Sistemul vechi de traducerere macar avea avantajul vitezei.

La un moment dat era cineva de la ei (o frantuzoaica) care se ocupa, dar asta era acum vreo 2 ani, cand verificam stringuri pentru ei intr-un excel din asta online pt lansare si era inca interfata aia veche de traduceri (instalare modificata de presta).

Pai cam asta fost si problema mea, intr-un timp facusem o traducere full si mai mult sau mai putin corecta pentru 1.5.0.ceva - prelansare. Doar ca imediat dupa lansare am vazut ca altcineva din cei care primisera drepturi sa umble la traduceri inlocuise varianta aia cu una facuta cu piciorul - cam ce avem acum. De atunci mi-am bagat picioarele in traducerea oficiala, oricum nu am drepturi de editare, pot doar sa propun stringuri si unul din aia de au varzuit traducerea decide; asa ca acum am varianta proprie de traducere pt 1.6 pe care o folosesc de la un proiect la altul - macar am partea de frontend cvasi ok. Problema cu diacriticile e ca intre timp s-au cam inmultit problemele legate de ele, vinovatul principal fiind fonturile de web - 99,99% dintre ele nu au latin extended, ca sa nu vorbesc de subset pentru romana. Oricum, ca sa fiu sigur ca nu sunt probleme, folosesc doar @font-face (font-squirrel e un prieten de nadejde) si doar fonturi cu subset de romana - nu sunt multe oricum. Mai nou, ca sa scutesc si requestul ala catre fontul de pe server (care oricum nu era blocking cum sunt requesturile de javascript) am inceput sa servesc fontul embeded direct in css.

Hmm, i don't thnk you know how php works if you think that the server will magically process the new products list etc. without a explicit request to do so either via an url, via a get or post request. Please do us all a favor and do some reading on the subject of how php works (or the http / web for that matter) before maiming your clients shops too much. Besides, allmost everything you so eagerly remove from your clients implementation has its role and place in a proper online shop, provided of course you are building real shops, not product lists with a buy me button. For example: crosselling is a way to show to the visitor some other products that might be of interest to him, mostly useful side products related to the visited one. The new products page gives you a convenient way to see what's new, etc etc.

Eu am creat campurile necesare direct in baza de date si am facut override pe clasa client + modificarile necesare pentru ele (adica adaugare campuri unde e nevoie) in template-urile din frontend. In linii mari, nu e nevoie de override pe controllere - din cate tin minte nici pentru admin, oricum asta a fost acum cam 1 an si pana acum nu au fost probleme cu situl respectiv.

A se vedea cele bolduite. Pentru mai multe fonturi Google fonts poate fi de un real ajutor, dar si font squirrel, un site dedicat fonturilor libere care are si kituri de fonturi pt @font-face si un generator. Ziarele folosesc fonturi comerciale. Incearca sa afli cat costa licenta pentru un font de genul, si in plus data fiind "inteligenta" demonstrata de presa romaneasca din ultima perioada nu m-ar mira sa nu fi aflat de existenta standardului romanesc. Daca toata lumea bate cuie cu pantoful nu inseamna ca e si ok.

Esti constient ca vorbim in general de 1 request de cca 30KB (non-blocking) in conditiile in care restul paginii (html + imagini + css + js) trec in general mult de 1MB? Servirea unui font prin @font-face nu afecteaza timpul de incarcare al unui magazin online, cu atat mai mult ca dupa prima accesare a paginii fontul este servit din cache-ul local al clientului.

Am uitat sa mentionez ca si pt xp exista suport pentru diacriticele corecte - exista un update de suport pentru fonturi si layouturi de tastatura, din cate tin eu minte nici nu necesita wga ala. In alta ordine de idei, tocmai mentionasem mai sus, exista ssi varianta @font-face - adica ii dai tu clientului fontul pe care sa-l foloseasca, ceea ce permite folosirea diacriticelor corecte inclusiv pe xp, singuree diferente fiind in modul de randare a textului (pe xp arata in general mai urat )

Pai daca ai Windows de la Vista incoace ai implicit si suport pentru diacriticele corecte (daca alegi romania vei avea 3 variante de layout de tastatura - cea denumita mai nou programmers, adica us international, fara diacritice, si 2 variante de layout romanesc, din care legacy inseamna sedila). Din punct de vedere tehnic lucrurile s-au mai schimbat in ultimul an, cota de utilizare a lu XP a cazut destul de mult si in plus merita luata in considerare servirea de fonturi cu @font-face, existand deja cateva fonturi super ok cu suport de diacritice romanesti (Ubuntu si derivatele, fontul lui Android, Open Sans etc, toate libere de folosit, fara probleme de licentiere). Problema ramane deschisa in continuare in privinta folosirii sau nu a diacriticelor, si nu e doar cea tehnica ci tine de modul de introducere a continutului mai degraba.

Well, at least is a start. I don't know how old is your site, but have you entered the meta title and meta description for the categories and products?

You can use Awstats if it is available (depends on the hosting, usually cPanel has it enabled) or you can see in webmaster tools (https://www.google.com/webmasters/tools/crawl-stats)