Occam

As for technical problems I'd agree, but for me this is not the only criterion. Many themes from Themeforest (incl. Panda and Transformer for Prestashop 1.5) aren't compliant with European law and require core changes, and often lack of translations proof evidence for this fact. But ... "a few translations"? You must be kidding! This theme like Panda brings along lots of own modules ( see my post above). This is a critical issue for people with no or poor skills in English, particularly due to the fact that source sometimes proves ... moderate.

@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. ;)

I just checked it. Are you sure? Seems to me like a downgrade from a luxury car to an ordinary family car. Transformer theme sets standards by which other themes must have to be judged. And ... Autumn imho seems to be a more conventional lightweight.

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.

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.

Just for the record: You are sure that you uploaded Prestools Suite to a subdirectory of your admin directory? The only thing the module does is providing a new tab to open quickly the tools and opportunity to store username and password.

No idea what happens, maybe it's the dispatcher. I installed this module before upgrading to 1.0.2. You may add the line Tools::getValue('controller'); to this function to force a message which controller causes this error. Or ask the developer @musicmaster himself. He is a member of this forum.

@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.

@30knees Just install musicmaster's awesome free Prestools suite and you are able to edit much more than just the carrier.

@vzex However, in any case this should just be optional if added. Because this is not allowed in Europe, particularly in Germany, except you have an explicit permission of the customer to submit his mail address.

Did you test, if the pdf is correct too when activating this for other status, like e.g. preparation?

Seems to me that TB cannot handle your pay by invoice module.

@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)

Here we go again! So what exactly is your contribution to this thread's problem that the theme's language is not automatically included when choosing this language during the install process of thirty bees?

@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. :)

This should always be the first step if the translation is missing or incomplete. Das sollte sowieso immer die erste Maßnahme sein, wenn die Übersetzung fehlt oder unvollständig ist.

@30knees Technically yes, it should solve the bug. But as long as TB ignores overrides in this place, the clear answer is NO. It works fine with PrestaShop, but not with TB. Btw some of the additional features of PrestaPlus like individual delivery times (in stock and OOS) for every single product were implemented into PS 1.7 core last week.

Gift wrapping - totally agree! Never used it. Guest checkout: I'm sorry, but this is a must-have for many shops! OPC of coolstuff.com: nice design, but not even close to comply with European law, German legal requirements in particular.

@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.

@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

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.

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!

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

@Traumflug My advice for you: Read carefully ... reflect ... then answer. ? You're barking up the wrong tree.

@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!