Occam

Looks like she's still active (last time this evening).

@daokakao said in Translation: I wonder something slightly different - an absence of any kind of co-ordination / orchestration of such different-skilled devs. Oh, they did, but far too late. Alexandra does a very good job since, and her English skills in conversation and writing are excellent.

You really ask why? Just because many of the programmers had to look up their source code in the absence of English language skills. Therefor these sometimes unbelievable mistakes.

Thanks for this gender hint. In blocknewsletter there is an item gender that has the meaning of social title, whereas the gender in AdminGenders (Hashcode: AdminGenders019ec3132cdf8ee0f2e2a75cf5d3e459) really means gender. Not to mention the menu item Ttitles in Admin --> Customers --> Titles. This should be corrected to the real meaning Social Titles. It's no automatism, changing the name to thirty bees alone does not guarantee a correct source code for the translations. ;) And btw, in the German translation I often ignored the use of plural and single and prefered a consistent translation.

In German we have the same problem. Another example would be the item title. To avoid gross errors in translation we decided for PrestaShop some years ago to create a distinct item named social title. This is the PrestaShop ... pardon ... thirty bees' Stairway to heaven: :musicalnote: *"'Cause you know sometimes words have two meanings ...* :musicalnote: :) Actually, depending on the context there may even be more than two different meanings for e.g. title. Sometimes it is not possible to make distinctions, so you need to translate carefully and always mind the context.

Actually ... yes! You find these items displayed in the admin section Localization --> Countries --> --->Address display -->Required fields for the address Helpful for foreign users with no or poor English skills to understand the fields' meanings in the left Address format.

And what exactly is your problem? Why don't you just approve the Russian translation. ;)

@alwayspaws Sure there are a lot of bugs left in 1.0.2 , but this applies even more to 1.0.1. Honestly, I wouldn't launch a live shop before release 1.1. But testing is necessary for every release.

I can confirm this. Try to backup manually first and then start the upgrade with deactivated backup.

I made some revisions in comparison to the original PrestaShop translation. The German localization pack is now completed und 100% approved. :) Hope it will be available soon - in any case you can download it directly from Crowdin. Please test it and give us a feedback, if there's still something wrong or in need of improvement.

Just for the record: With a standard installation without any code changes I cannot reproduce the error you reported in this topic.You must have made some changes to the hook hookDisplayProductPriceBlock.tpl

@zimmer-media I cannot reproduce this error, though I tried several releases of AEUC with thirty bees. Anyway, either you seem to use a module for the weight display or you changed the code because "€10.00 per 100 g" is formatted with a different font size:

@DaoKakao said in Transformer Theme = How Compatible?: I have this theme installed on a fresh TB - and seems no issues awhile on the FO. To tell the truth, i didn't made a intensive load of this new site, not inserted any product even, but it seems like a 100% fresh new on the PS platform Maybe this makes the difference. Received this link today of another thirty bees live shop with Transformer theme: - with Redis and Page cache. But I had several times a fatal error during the upgrade process and started it again and again, though there were currently not more than some test orders with demo data and no additional modules except AEUC and Presta plus installed. After a while I canceled the backup options. But there were still some errors left, and I don't manage it to get the product and other images displayed though I already regenerated the images several times. I don't know what happens here. Ok, I'll try it again this weekend with a fresh install. Anyway, it should work without problem on an upgraded shop too.

I know the Transformer theme from PS 1.5 and 1.6. Tried it out this afternoon on thirty bees 1.0.2. Installation without problem, checkout ok so far, but the frontend seems to be a desaster. I guess the developer has much work ahead before this theme can be recommended as full compatible.

No, the logo to be displayed must have the module's name and the file extension .jpg (e.g. bankwire.jpg), no matter if the real file format is png. We had this error already with the shop logo in PrestaShop 1.5.

Checked it, seems so! I wasn't aware of it. Which means, the hook always expects the module's logo in the modules' main directories. And moreover, the file extension .jpg is mandatory, even if it is a png format.

Ok, my test invironment doesn't support SSL, that's why I cannot check if the following modifications work: Open /modules/stripe/views/templates/hook/payment.tpl Apply these changes from line 23 on: <div class="col-xs-12 col-md-12"> <p class="payment_module" id="stripe_payment_button"> <a id="stripe_payment_link" href="#" title="{l s='Pay by Credit Card' mod='stripe'}"> <!--<img src="{$module_dir|escape:'htmlall':'UTF-8'}/views/img/stripebtnlogo.png" alt="{l s='Pay by Credit Card' mod='stripe'}" width="64" height="64" />--> <img src="{$this_path_stripe}stripebtnlogo.png" alt="{l s='Pay by Credit Card' mod='stripe'}" width="86" height="49" /> {l s='Pay by Credit Card' mod='stripe'} {if $showPaymentLogos} <!--<img src="{$module_dir|escape:'htmlall':'UTF-8'}/views/img/creditcards.png" alt="{l s='Credit cards' mod='stripe'}" /> {if $stripe_alipay}<img src="{$module_dir|escape:'htmlall':'UTF-8'}/views/img/alipay.png" alt="{l s='Alipay' mod='stripe'}" />{/if} {if $stripe_bitcoin}<img src="{$module_dir|escape:'htmlall':'UTF-8'}/views/img/bitcoin.png" alt="{l s='Bitcoin' mod='stripe'}" />{/if}--> <img src="{$this_path_stripe}creditcards.png" alt="{l s='Credit cards' mod='stripe'}" /> {if $stripe_alipay}<img src="{$this_path_stripe}alipay.png" alt="{l s='Alipay' mod='stripe'}" />{/if} {if $stripe_bitcoin}<img src="{$this_path_stripe}bitcoin.png" alt="{l s='Bitcoin' mod='stripe'}" />{/if} {/if} </a> </p> </div> Paypal seems to choose depending on the country its logo from /modules/paypal/logo.xml. I guess this is started by the file /modules/paypal/views/templates/hook/column.tpl. But I'm not sure.

/modules//views/templates/hook Oops, sorry, that was PS 1.5! In 1.6 (and thirty bees?) The file is called just payment.tpl

That's strange, because AEUC just uses the modules' file displayPaymentInfo.tpl in this place. Therefor you need to check if all files provide the same informations.

@marci123 There is no "blockchain for PrestaShop" afaik, all this is about is a complete new business model, a strategic reorientation of the Paris company. Prestashop's CEO seems to believe that you can make more money with this new business plan than with PrestaShop. That's all!

You seem to have missed Bitcoin. Without block chain technology no Bitcoin! ?

@Traumflug said in PrestaShop Will Enforce Encrypted Modules Soon: Now, if this PrestaTrust thing could offer a code encryption technology in the sense that module customers can no longer read the code, it'd be a useful technology. Similar to what IonCube does. To my knowledge, "borrowing" code from competitors happens among module creators, which isn't always helpful for the success of these modules. Can't say whether PrestaTrust offers this, because, well, I can't read French either. To my surprise I seem to be the only one here who can read French. I didn't find a hint that Prestatrust offers this. So I do not want to heat on long shots. And I guess it wouldn't be easy to encrypt simple interpreter languages like php. Or am I wrong about this?

I'm not sure if all modules are really up to date. I checked some of them already but currently my leisure time is limited. And there is a lot of translations (concerning PS Addons e.g.) that were ok for PS but are currently wrong or unnecessary for thirty bees.

Though it is quite common I hate this term Standardsprache. And in this special case you are right, the current translation is misleading. I did not follow exactly your proposal and btw changed not only the hint, but the field item too. Hope this is OK for you: Memorize the language used in Admin panel forms --> Spracheinstellung des Back Office merken Allow employees to select a specific language for the Admin panel form. --> Mitarbeiter dürfen eine andere Sprache für das Back Office wählen. Anyway, the source text is ... worthy of improvement.

@dprophitjr said in PrestaShop Will Enforce Encrypted Modules Soon: Some part of the module software has to phone home to create the tracking. They'll have to encrypt some or part of the module and cripple it if the license is invalid. This is what I called pidgeonholing. :)