Prestashop: Translations in override controllers or classes doesn't work

[bmagneCesi]

Hi,

I'm facing an issue with an override that i made on the frontController.php, i'm using the $this->trans() method but i can't find the translation in the BO.

I tried to pass many different domains like these ones:

Shop.Theme.Global
Shop.Theme.Action
Shop.Theme...

i even created a domain for my theme like it's explained on this page http://build.prestashop.com/howtos/translation/how-to-translate-your-theme/ but i can't find them in the BO.

I don't know if its an issue or if i don't do it the right way but i can't find moire informations on the internet on this problem.

Regards,

Ben

[khouloudbelguith]

Hi @bmagneCesi,

Thanks for your report.
Have you the same issue reported in this ticket: #10491?
Thanks!

[bmagneCesi]

Hi khouloudbelguith,

In fact my problem is related to controllers or classes overrides, not to modules.
i just want to add new fields, for exemple in the overrides/classes/controller/FrontController.php, like this :

$this->trans('Sentence to translate', array(), 'Shop.Theme.Global') or
$this->trans('Sentence to translate', array(), 'Shop.MyTheme')

but i can't see it in the BO then.

Regards,

Ben

[khouloudbelguith]

Hi @bmagneCesi,

Thanks for this clarifications.
I manage to reproduce the issue with PS1.7.5.0 & PS1.7.4.4.
I used this file /Project_Folder/override/classes/Product.php

<?php
/**
 * Created by PhpStorm.
 * User: khouloud.belguith
 * Date: 25/01/19
 * Time: 10:26
 */

class Product extends ProductCore
{

    public function __construct($id_product = null, $full = false, $id_lang = null, $id_shop = null, Context $context = null)
    {
        $this->trans('test 1', array(), 'Admin.Global');
        $this->trans('test 2', array(), 'Shop.MyTheme');
        $this->trans('test 3', array(), 'Shop.Theme.Global');
        print_r($this->trans('test 4', array(), 'Shop.MyTheme'));
        exit();
        parent::__construct($id_product, $id_lang, $id_shop);
    }
}
?>

& I could not find those expressions to translate them.

Thanks!

[kpodemski]

This is critical... any new strings in .PHP files are not available to translate...

[bmagneCesi]

Hi @khouloudbelguith, any news for this bug ?
It's very important and critical because I can't send translated variables to my javascript files with this issue. I need to send them from my controller via the Media::addJsDef() method.

[khouloudbelguith]

@bmagneCesi, sorry not yet, I added this issue to the debug roadmap. If you have already fixed it on your end or if you think you can do it, please do send us a pull request!

[kpodemski]

@khouloudbelguith

sorry but you're working (core team) on many things at this moment ignoring issues with translations for almost 2 YEARS

isn't it critical to have translations working properly in web application?

[khouloudbelguith]

ping @colinegin @marionf what do you think?
Can we add this issue to the roadmap PS1.7.6?
Thanks!

[colinegin]

@eternoendless @PrestaShop/prestashop-core-developers what do you think of this issue ?

[jolelievre]

I also think it's an important issue (I avoid using critical since everything is critical ^^)
I think we should/could add this issue to the PS 1.7.6, this would encourage people developing Symfony modules and switching to 1.7
Besides we are probably gonna need this feature for the migration of our modules (which are in the 176 roadmap)

But I lack knowledge about how it works and the complexity to make this work for modules, I believe @mickaelandrieu has looked into it some time ago? Do you have an idea of "how long" this would take?

[bmagneCesi]

@khouloudbelguith, any news about this issue ?

Regards,

Ben

[kpodemski]

@jolelievre
cc @eternoendless

there are many critical issues, i mean... really critical, like this one, yet y'all are working on migration... 1.7.6 improvements etc...

i have the feeling that every time we see main release, like 1.7.4, 1.7.5 bugs are postponed from version to version just to have time for other improvements and... new bugs

and what's annoying is that it's 1.7 FIVE, it's first time in history of PrestaShop when we have FIVE major versions and software is still with few very critical problems, 1.5.4 was stable enough, 1.6.1 was stable enough, what's the current state of 1.7?

1. Autoupgrade still has dozen of issues, problems with tabs permissions, broken currencies etc.

2. translation system is not working properly, spaghetti between legacy and modern system, third party modules and overrides are ignored, no possibility to translate module in context of the theme, huge regression from 1.6

3. combinations are still extremely slow and there are regressions from 1.6, for example you can't set final price of the attribute combination

4. recently discovered issues with template overriding for third party modules

5. 12110

6. regression in terms of managing currencies, position of the currency symbol, rounding etc.

and many other issues which make PrestaShop hard to use, even for developers

as 2, 5 are hard and i understand that it's a lot of work to make it available again or rework some of this stuff, rest of these points are critical, especially number 0 and 1

this is why i'm curious... why is project not frozen for some time? like: 'hey, lets stop doing improvements, lets go to Issues and try to fix most cricital ones'?

i'm just curious, i'll have more free time in upcoming weeks and i'll try my best to help y'all but i think that projects needs to be driven in a slightly different direction right now...

[bmagneCesi]

@colinegin do you know when someone will check this issue ?

[eternoendless]

Hi @kpodemski

i have the feeling that every time we see main release, like 1.7.4, 1.7.5 bugs are postponed from version to version just to have time for other improvements and... new bugs

Improvements are needed to fix root problems, otherwise we could spend our lives playing bug whack-a-mole (see the 23 patch releases for 1.6.1.x). Regarding "new bugs", new regressions are now being fixed either during the pre-release cycle (as they appear) or in patch releases (if they are specific to the minor version). There are currently only two known, unfixed regressions for 1.7.5.x.

it's 1.7 FIVE, it's first time in history of PrestaShop when we have FIVE major versions and software is still with few very critical problems

That's right, we're _still_ paying up the massive amount of technical debt that PS accumulated during 10 years, and many wrong choices that were made during the first phase of 1.7 (up until 1.7.2). Unfortunately we still have a very long way to go. This will probably become more clear once I publish part 2 on this series, where I will explain the main things that are very wrong in PS right now at that are seriously dragging the project behind.

Autoupgrade still has dozen of issues, problems with tabs permissions, broken currencies etc.

Right, but look at the enormous progress that we made during the last year alone. Automatic upgrade is a very complex task, and we are continually working on making it better. Microsoft has been working at it for over 25 years and they still don't get it right 100% of the time.

translation system is not working properly

This is being sorted out right now. It is kind of tricky because new wordings are discovered by performing source code analysis via AST traversal.

If a translation key is not being discovered by the BO, you can try inserting it in ps_translation directly.

combinations are still extremely slow

This is unfortunately a design flaw (using a single huge form). I'm not sure how we'll be able to fix that as it will require reworking the whole product page.

regression in terms of managing currencies, position of the currency symbol

You mean regarding 1.6? This is extremely complex to get right. The good news is that after two years of work we have now successfully merged our new implementation of the CLDR standard which will fix some issues, but more importantly, will allow us to introduce the possibility to add nonstandard currencies, and customize them (for those who dislike standards).

rounding [regressions]

This is partially due to the fact that many math operations regarding prices in PS still aren't performed using arbitrary-precision numbers yet (it's known that floats carry precision errors). This must be changed everywhere.

The bottom line is that there are thousands of tasks to be done, hundreds of stakeholders screaming "fix _my_ problem first!"... and only a handful of developers to do it.

It will take time. Will you help us?

[bmagneCesi]

Hi @eternoendless,

This is being sorted out right now. It is kind of tricky because new wordings are discovered by performing source code analysis via AST traversal. If a translation key is not being discovered by the BO, you can try inserting it in ps_translation directly.

I tryed to add it mannually into the database but I can't find it in the BO...anything else to do in order to make it works ?

[eternoendless]

@bmagneCesi I think that adding it in the database won't make it available in the BO but will make it available when you're using it in your code.

Just make sure to clear the translator cache in /var/cache/<env>/translations once you have finished doing your edits.

Also remember that domains in the database are stored without dots (eg. Admin.Actions -> AdminActions)

[atatos]

@khouloudbelguith any news about this bug ? is it fixed ?

[khouloudbelguith]

Hi @atatos,

As commented here: https://github.com/PrestaShop/PrestaShop/issues/12300#issuecomment-472992465, there is an available workaround.
This issue is still en todo.

Thanks for your understanding!

[fromcouch]

Hi,

i did a non-elegant-a-lot-of-dirty solution to this problem.

My client ask me to change the word Category inside product-listing. I can't, obviously due this problem.

I did next steps:

I overrode CategoryControllerCore in override folder:

class CategoryController extends CategoryControllerCore
{
    public function getListingLabel()
    {
        parent::getListingLabel();

        return $this->trans(
            '#text#: %category_name%',
            array('%category_name%' => $this->category->name),
            'Shop.Theme.Catalog'
        );
    }
}

I was changed to some sort of variable called #text#.

Then in catalog/listing/product-list.tpl I was search for product_list_header block and did some development

{block name='product_list_header'}
      {if $listing.label|strpos:"#text#" !== false}
        {capture name="title"}{l s="My Translation" d="Shop.Theme.Ebavs"}{/capture}
        {assign var='title' value=$listing.label|replace:'#text#':$smarty.capture.title}
      {else}
        {assign var='title' value=$listing.label}
      {/if}
      <h2 class="h2">{$title}</h2>
{/block}

Then if #text# exists in $listing.label I was replacing for some Translated text.

I want to insist that is a dirty solution but will help meanwhile developers solve problem.

Regards,

[maxime-aknin]

Hello,

I managed to find a solution to address this problem. For now you can see the changes in this commit (made in my fork).

How it works

For it to work you need to use the Override domain in override files (e.g $this->trans('Nasty error', [], 'Override.Notifications.Error'), it will scan the override folder and create files in app/Resources/translations (similar to what's done for theme templates translations).
I also modified AdminTranslationsController to add a Override translations choice in admin page (translation for this button is not done).

Notes

I tested it and deployed in a PS1.7.2 shop (with some difference, the config file structure in PrestashopBundle has changed) but I have not tested it in PS1.7.7. Also note that there is not tests, and it is most likely not a perfect solution (it might be kind of hacky in some ways), but I think it's a good start to fix the problem later in a more elegant way. If I have time I'll test it in lastest version and create a pull request.

Cheers