Polskie wsparcie PrestaShop
PrestaShop => Polska wersja językowa => Wątek zaczęty przez: pdrozniak w Czerwiec 06, 2010, 11:23:57 pm
-
Witam
Mam kilka koncepcji, które sprawiłyby że PrestaShopPL 1.3 będzie bardziej "polska":
1. Polskie znaki w eksportowanej Fakturze Pro Forma - jest z tym problem. Być może wystarczy jakiś poradnik zamieścić na forum lub w FAQ jak to zrobić krok po kroku.
2. Zmiany w fakturze proforma. Nie dokońca jest ona tworzona w formie jaka jest w Polsce przyjęta. Jest to szczególnie ważne przy zakupach dokonywanych przez firmy. W linku pzredstawiam taką przykładową proformę: kliknij http://www.cf.nrow.pl/Presta-pdf.pdf (http://www.cf.nrow.pl/Presta-pdf.pdf) jaką często sam dostaję. Chodzi oczywiście o zawartość merytoryczną, a nie styl czy układ.
3. Faktura proforma nie jest dostępna od razu, gdy zamówienie ma satus Oczekiwanie na przelew itp. A mogłaby być ponieważ po dokonaniu zamówienia Klient nie ma możliwości wydrukowania sobie takiej faktury - pojawia się ona dopiero po zmianie statusu przez Admina sklepu. Sklep internetowy działa jednak 24h i nie zawsze admin może reagować od razu.
4. Mail potwierdzający zamówienie wysyłany do Klient mógłby również zawierać rozrówznienie na kwoty netto i brutto w tabeli.
Dwa pierwsze są szczególnie istotne. Moim zdaniem.
-
Zgadzam się z powyższym, do tego mam zastrzeżenie, że w wersji 1.1.118 była ciekawa opcja, juz w 1.25 nie, no i w 1.30 też nie. Chodzi o "newsletter", który klikałem nad modułami (obok "pozycja") i mogłem wysłać sformatowany e-mail do wybranych grup klientów.
Może gdzieś to jest, ale widzę tylko w tej najstarszej, nierozwijanej wersji.
-
jaki czas temu przerabiałem go jak bys był zainteresowany pisz na prv. i do której wersji :>
-
1. Polskie znaki w eksportowanej Fakturze Pro Forma - jest z tym problem. Być może wystarczy jakiś poradnik zamieścić na forum lub w FAQ jak to zrobić krok po kroku.
Hack/rozwiązanie na Polskie znaki w PDF jest na:
http://prestashopforum.pl/index.php?topic=286.msg9325#msg9325
Rozwiązanie z 1.1 działa też na 1.3, jednak ze względów na licencję (czcionki Arial) nie będzie na razie implementowane w pełnej wersji.
Dlaczego na Priv, skoro jest forum publiczne i można włączyć się w Projekt: http://prestashopforum.pl/index.php?topic=2429.msg8465#msg8465
?
Nie rozumiem, dlaczego wolicie sami sobie rozwijać PrestaShop ...
w takim razie po co uczestniczycie w tym forum?...
.. i tracić tylko niepotrzebnie swój czas
Każdy sobie coś tam skrobie, zamiast połączyć siły :(
No ale cóż, jeśli tak wolicie ...
-
Ale są czasem tematy, które lepiej poruszyć na priv, dzięki lof za chęc pomocy :)
A tez uważam, że prestę dobrze jest rozwijać razem :)
A tak z innej beczki, kiedy myślicie, ze wersja 1.3 będzie na tyle dopracowana, by móc ją bez wyrzutów sumienia, że zaraz coś się sypnie wykorzystać? Tak jak wersja 1.1. (118) niby stara, nierozwijana, ale wszystko dopięte na ostatni guzik i śmiga?
-
Dlaczego na Priv, skoro jest forum publiczne i można włączyć się w Projekt: http://prestashopforum.pl/index.php?topic=2429.msg8465#msg8465
?
Nie rozumiem, dlaczego wolicie sami sobie rozwijać PrestaShop ...
w takim razie po co uczestniczycie w tym forum?...
.. i tracić tylko niepotrzebnie swój czas
Każdy sobie coś tam skrobie, zamiast połączyć siły :(
No ale cóż, jeśli tak wolicie ...
to pokaż mi ludzi który tutaj świadczą pomocą - bo ostanio tego coraz mniej, ja odpisuje tyle ile moge i na ile mam sił...
-
to pokaż mi ludzi który tutaj świadczą pomocą - bo ostanio tego coraz mniej, ja odpisuje tyle ile moge i na ile mam sił...
lof - i za to bardzo dziękuję ... że choć Ty jeszcze nie straciłeś zapału.
Choć do SVNa też mógłbyś coś od czasu do czasu wrzucić ;)
Bo kto inny to poprawi jeśli nie Ty, skoro masz wiedzę jak, co i gdzie należy poprawić?
Ale są czasem tematy, które lepiej poruszyć na priv, dzięki lof za chęc pomocy :)
OK. Uzgodnić na PRIVie ... i wprowadzić w czyn w SVN --> http://www.prestashop.pl/pliki.html#SVN (http://www.prestashop.pl/pliki.html#SVN)
Bo jeśli będzie pozostawać tylko w strefie PRIV to nie będzie się rozwijać ...
A tez uważam, że prestę dobrze jest rozwijać razem :)
A tak z innej beczki, kiedy myślicie, ze wersja 1.3 będzie na tyle dopracowana, by móc ją bez wyrzutów sumienia, że zaraz coś się sypnie wykorzystać? Tak jak wersja 1.1. (118) niby stara, nierozwijana, ale wszystko dopięte na ostatni guzik i śmiga?
Już można używać bez wyrzutów sumienia.
Od strony technicznej bazuje na 1.3.1.1 a więc z najnowszą
poprawką bezpieczeństwa z 3 czerwca 2010.
A więc jest tak samo dobra jak wersja Angielska
Jak nie będziecie używać wersji PL 1.3.1 , to jak wychwycimy ewentualne bugi by wykonać np. poprawki w tłumaczeniach polskich?
PS
No i ważne by też włączać się do SVNu i samemu też poprawiać
- a jeśli nie wiesz jak, to pokażę - SVN nie jest taki straszny ... na jaki wygląda ;)
-
Nie rozumiem, dlaczego wolicie sami sobie rozwijać PrestaShop ...
w takim razie po co uczestniczycie w tym forum?...
.. i tracić tylko niepotrzebnie swój czas
Nie twierdzę, iż jest to zła rzecz takie projekty, ale mają one pewne minusy.
Nigdy nie wiadomo, kto Ci co dopisze do kodu (nie mowie o jakichs zlosliwosciach, lecz o niewydajnym kodzie).
Jesli chodzi o tych co pisali preste, to oni nie pozwalają każdemu (nie oceniam nikogo umiętności ani nic) dobierać się do źródeł.
Jak już znajde troche czasu, to przerobie pdf'y na polskie języki i podziele się :) Ale ja raczej wole nie brać kodu którego nie znam.
Może przesadzam, ale (to akurat nie wy zrobiliście, ale Ci co pisali preste.) Otóż moduł pobierający najnowsze produkty i wyświetlający tylko nazwe, cene i link.... a Zapytanie MySQL wyglada tak
Db::getInstance()->ExecuteS('
SELECT p.*, pl.`description`, pl.`description_short`, pl.`link_rewrite`, pl.`meta_description`, pl.`meta_keywords`, pl.`meta_title`, pl.`name`, p.`ean13`,
i.`id_image`, il.`legend`, t.`rate`, m.`name` AS manufacturer_name, DATEDIFF(p.`date_add`, DATE_SUB(NOW(), INTERVAL '.(Validate::isUnsignedInt(Configuration::get('PS_NB_DAYS_NEW_PRODUCT')) ? Configuration::get('PS_NB_DAYS_NEW_PRODUCT') : 20).' DAY)) > 0 AS new,
(p.`price` * ((100 + (t.`rate`))/100) - IF((DATEDIFF(`reduction_from`, CURDATE()) <= 0 AND DATEDIFF(`reduction_to`, CURDATE()) >=0) OR `reduction_from` = `reduction_to`, IF(`reduction_price` > 0, `reduction_price`, (p.`price` * ((100 + (t.`rate`))/100) * `reduction_percent` / 100)),0)) AS orderprice
FROM `'._DB_PREFIX_.'product` p
LEFT JOIN `'._DB_PREFIX_.'product_lang` pl ON (p.`id_product` = pl.`id_product` AND pl.`id_lang` = '.intval($id_lang).')
LEFT JOIN `'._DB_PREFIX_.'image` i ON (i.`id_product` = p.`id_product` AND i.`cover` = 1)
LEFT JOIN `'._DB_PREFIX_.'image_lang` il ON (i.`id_image` = il.`id_image` AND il.`id_lang` = '.intval($id_lang).')
LEFT JOIN `'._DB_PREFIX_.'tax` t ON (t.`id_tax` = p.`id_tax`)
LEFT JOIN `'._DB_PREFIX_.'manufacturer` m ON (m.`id_manufacturer` = p.`id_manufacturer`)
WHERE p.`active` = 1
AND p.`date_add` > DATE_SUB(NOW(), INTERVAL '.(Validate::isUnsignedInt(Configuration::get('PS_NB_DAYS_NEW_PRODUCT')) ? Configuration::get('PS_NB_DAYS_NEW_PRODUCT') : 20).' DAY)
AND p.`id_product` IN (
SELECT cp.`id_product`
FROM `'._DB_PREFIX_.'category_group` cg
LEFT JOIN `'._DB_PREFIX_.'category_product` cp ON (cp.`id_category` = cg.`id_category`)
WHERE cg.`id_group` '.(!$cookie->id_customer ? '= 1' : 'IN (SELECT id_group FROM '._DB_PREFIX_.'customer_group WHERE id_customer = '.intval($cookie->id_customer).')').'
)
ORDER BY '.(isset($orderByPrefix) ? pSQL($orderByPrefix).'.' : '').'`'.pSQL($orderBy).'` '.pSQL($orderWay).'
LIMIT '.intval($pageNumber * $nbProducts).', '.intval($nbProducts));
I teraz kto mi wyjaśni, po co komu takie dane jak
`description`
`description_short`
`link_rewrite`
`meta_description`
`meta_keywords`
`meta_title`
`name`
`ean13`,
`id_image`
`legend`
`rate`
`name` AS manufacturer_name
Ja wszystko rozumiem, ale moduł nowych produktów spowalnia sklep że nie wiem....
Pracuje często na sklepach z ponad 18 tys produktów, jak takie zapytanie przejedzie przez 18tys produktów, to dziękuję....
-
Ja chętnie pomogę ale na razie mam maaaasę pracy, po za tym pracują na swojej paczce Presty, która często jest w rozsypce ale jak będę miał więcej czasu to podrzucę chociaż Wam fakturki z polskimi znakami bo mam zrobione ;)
-
Nie twierdzę, iż jest to zła rzecz takie projekty, ale mają one pewne minusy.
Nigdy nie wiadomo, kto Ci co dopisze do kodu (nie mowie o jakichs zlosliwosciach, lecz o niewydajnym kodzie).
Jesli chodzi o tych co pisali preste, to oni nie pozwalają każdemu (nie oceniam nikogo umiętności ani nic) dobierać się do źródeł.
(...)
GackuSSJ4, nie należy się bać, wszystko możesz sprawdzić.
SVN w oparciu o który pracujemy:
http://www.prestashop.pl/pliki.html#SVN
zawiera całą historię od wersji angielskiej, i późniejszych zmian i spolszczeń,
a więc żeby sprawdzić co się zmieniło, wystarczy wziąć ostatnią wersję Z SVN i porównać z pierwszą czyli oryginalną angielską.
SVN ma tu narzędzia i jak na dłoni możesz sprawdzić co się zmieniło.
-
Wlasnie moge, ale jak czasem to za głowę się łapię, przykład z dzisiaj: [z modułu Price Wars]
$Products = Product::getProducts(Language::getIdByIso("pl"), 0, NULL, 'name', 'ASC');
A za chwilkę taki kod:
foreach ($Products AS $Product){
if ($Product['active']==1) {...}
A funkcja wyglada tak:
static public function getProducts($id_lang, $start, $limit, $orderBy, $orderWay, $id_category = false, $only_active = false)
To po co dodatkowe 2 parametry
Po co sciagac z bazy rekordy rekordy, i je sprawdzać kiedy można tylko napisać takie coś jak:
$Products = Product::getProducts(Language::getIdByIso("pl"), 0, NULL, 'name', 'ASC', false, true);
i w tym momencie, caly skrypt skraca czas wykonania, redukuje ilość przesyłanych danych między MySQL i zwalnia pamieć... czasem nawet bardzo dużo.
Wyobrażasz sobie jak wielki będzie obiekt na 5 tys produktów?? a Co jeśli tylko 1000 jest aktywnych, a 4000 to produkty archiwalne? W tym wypadku wszystkie są pobierane i trzymane w pamięci, a tylko 1/5 użyta.
W wolnym czasie przerobie ten moduł toszkę i może dorobie manager jakiś który będzie pozwalał na zaznacznie/odznaczanie produktów które maja być eksportowane.
PS: mam nadzieję, że autor sie nie pogniewa :P