Jump to content
thirty bees forum

Occam

Members
  • Posts

    303
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by Occam

  1. @zimmer-media said in How to - time display in front office ?:

    I look for one of our shops the possibility of the time display in the frontoffice. In the shop are customers from all over the world. For example, a price rule with a limited duration - e.g. from 8.00 am - 12.00 and this is also communicated to Facebook and other social network - I would like to spare the customers the search, when the time is actually also their time zone. We also want to avoid unnecessary questions or angry messages. In the Prestashop forum I have already searched, but still nothing found. Do you have a solution or suggestion? Thank you in advance.

    Why don't you use Smarty? In the German PrestaShop forum it seems likely to have a look into the Benutzerleitfäden. :) You would have found in my hints and tutorial this link: Just for the record: Never use the awful search of the PrestaShop forum! Use Google with the keyword "Prestashop forum" and your question and your search will be successful in most cases. ;)

  2. Yes, we have both probably experienced at Crowdin that the developers of the Transformer theme seem to be indifferent to what the translators suggest. At the beginning there was at least some feedback, but not lately. And I suppose with the other themes (e. g. Panda) it is the same. As a consequence, this means that all users with little knowledge of English or all those who need a different shop language than English should avoid Sunnytoo's themes, regardless of whether they are thirty bees compatible or not. The developers seem to concentrate 100% on the English-speaking market. Might be understandable from an economic point of view, but Europeans should probably look for other themes.

  3. I really love the transformer theme and adapted it already for PrestaShop 1.5 for compliance with European law. But every non English user should be aware that this theme still comes along not only with in many parts poor English source texts but 80 % untranslated. Which means roundabout 3000 items. Items, not alone single words! OK, some time ago they went to Crowdin.com, but offer just about 10 or 20% for translation there. None of the modules! And considering the fact that proof reading seems to be very neclected, I guess it is curently waste time to help them with translations because they don't seem to be really interested. Moreover, translations can only be downloaded as xliff files (xml format). This makes absolutely no sense, lbecause it is useless. 30bees as well as Prestashop need a zip containing php files, even for direct upload. Sad, because this theme is awesome.

  4. @vzex Your welcome. Btw Prestools comes along with a small module that creates a new tab in the catalog menu. But with a small override you may integrate it directly in the back office order page so that it opens the current order for changes. Just copy /themes/default/template/controllers/orders/helpers/view/view.tpl to /override/controllers/admin/templates/orders/helpers/view/

    Open this file and search for Add here after

    the following lines {l s='Change order'}

    Clear cache and enjoy.

  5. @JamesBlond008 You can't be serious! Two threads on the same subject are no good idea. I also don't think that the forum mods would appreciate to prohibit translations into other languages in posts generally, as requested by member @alwayspaws. This demand has a simple history. Pet shop girl was just upset when I asked her some time ago to answer in the German subforum in German and not in English. This is what we do in the Prestashop forum, because you can expect everyone to use a translation program in order to be polite. The contribution can then be bilingual. After all, translation programs are not always reliable. But I think it's presumptuous of her to expect everyone to speak English just because she doesn't understand any other language.

    Das meinst du doch wohl nicht ernst! Zwei Threads zum selben Thema halte ich für keine gute Idee. Ich glaube auch nicht, dass die Foren-Mods es begrüßen würden, Übersetzungen in andere Sprachen in Beiträgen generell zu verbieten, wie das Mitglied @alwayspaws fordert. Diese Forderung hat eine einfach Vorgeschichte. Pet shop girl hat sich einfach darüber geärgert, als ich sie vor einiger Zeit bat, im deutschen Unterforum auf Deutsch und nicht auf Englisch zu antworten. Das machen wir im Prestashop-Forum auch so, denn man kann von jedem erwarten, dass er der Höflichkeit halber ein Übersetzungsprogramm benutzt. Der Beitrag kann dann auch ruhig zweisprachig erfolgen. Denn Übersetzungsprogrammen kann man ja nicht unbedingt immer trauen. Aber ich halte es für anmaßend von ihr, von jedem zu erwarten, dass er Englisch spricht, nur sie weil keine andere Sprache versteht. (Just for the record, @alwayspaws: This was the German translation of the above post)

  6. @alwayspaws said in Language in FrontEnd is still English, but i have only German installed?:

    Please speak English or move this to the German forum.

    Look, lack of skills in foreign languages in an interconnected world are sad, but neither my problem nor that of the other members who posted in this thread. The only one who didn't realize that the German users wrote their posts in both languages seems to be - you. :)

  7. @30knees said in Onepage Check-out like presta 1.7:

    Something to consider for a (one-page) checkout: The address should always be entered before the carrier selector on a one-page checkout.

    I've noticed that otherwise the shop gives a "No carriers available" error to guests/non-logged in customers. This is because the shop doesn't know what country the guest/non-logged in customer is. See: https://forum.thirtybees.com/topic/235/no-carriers-available-error

    Not only for OPC! You have to consider this already for the cart, no matter if you use opc or not. It is quite easy to handle, just by using global smarty variables. There is absolutely no reason for this (wrong) display "No carriers available". You can avoid this by simply adding a condition if the customer is_logged or not.

  8. @mdekker said in Better responsive checkout:

    Oh, never realized it bothered people so much, I use some forked PS 1.6 theme in my store, also with "scrollable tables" as I'd like to call it. It permanently shows a scroll bar BTW. That seems to make the visitors less confused.

    But erm how does the transformer theme cram it all inside 320px, must be a tiny font then?

    Depends. ? The Transformer theme's CSS is indeed very sophisticated, but even with less effort it should be possible to force the mobile display to switch from horizontal to vertical just by CSS. The most simple way is this: https://css-tricks.com/responsive-data-tables/ I used this for PrestaShop 1.5. But meanwhile there are different techniques you may apply: Responsive Data Table Roundup

  9. It is the same behavior like in Prestashop 1.6. I can confirm what was assumed in a post above. I didn't check it for thirty bees in particular, but in PS its even more worse with activated Advancedeucompliance module.

  10. Anyway, you should see to the import controller, @mdekker. A developer named gabdara posted a commit on Github last Friday. This fixes a bug in all PrestaShop 1.6 and 1.7 and thirty bees releases, which came along with a totally rewritten AdminImportController.php since 1.6.
    It occurs when trying a product csv import without option force ids, but with an id column in the csv file. Check the function categoryImportOne. You will find here the same bug for categories. Without fix!

  11. However, as already mentioned above there's need for improvement:

    maxinputvars = 10000; (should be enough) max_input_time = -1; (= unlimited) max_execution_time = 300; (or more)

    And in case the server has a suhosin extension you should add:

    suhosin.get.maxvars = 10000;_ suhosin.post.maxvars = 10000;_

    If you have no access to php.ini or/and are not allowed to create one on your own, you can try to change those values through entries in your .htaccess using the following format:

    php_value 0000 e.g. php_value max_input_vars 10000

  12. @traumflug said in Translation:

    @DaoKakao

    I really wondered, why such ugly/overcomplicated mixture of (almost)same terms appeared.

    Because there's more than one person involved in writing code. Each person has its own preferences on how to write code, this applies not only to translatable strings. And then ... well, when writing code, using elegant language in texts isn't exactly top priority. Code writers watch out much more for the code doing what it should do.

    That said, if you find such mismatching use of human language, don't hesitate to report them as code bugs (on Github). Changing such wording doesn't change how the code works, so it's easily replaceable.

    Nice try, but we're talking about translation items imported fom PrestaShop which have been messed up since years. And already in 2013 Francois and I had prepared a handout for the developers in order to harmonize the wording or at least the spelling. But things changed not until PrestaShop engaged a person reponsible for this with the authority to decide how the translatable strings had to look like. What we are dealing with here is to large extend a burden of the past!

×
×
  • Create New...