Jump to content
finnenhawke

PrestaShop 1.7.5.1 - Translations not saving / updating

Recommended Posts

I'm using PrestaShop 1.7.5.1 with GamesHouse Theme from official Marketplace and some marketing modules.

The problem is that translations are not always being saved, no matter what module I edit. Basically, the rule of thumb is that when I open the translation menu for the first time, it will save properly. However, when then I edit more lines and try to save changes again, they won't save. Last translated fields become blank again, only the first batch remains translated. To be able to translate again, I have to log off and log back into administration panel. Then sometimes it works again, and sometimes even then it doesn't work and I have to just try saving over and over again until it finally saves.

Does anyone have some experience with that? Is that some kind of borderline aggressive caching from my hosting provider or what? 

Share this post


Link to post
Share on other sites

I will observe this topic as I have a corresponding issue with the same Presta version.

In my case translations are nicely saved in the back office but the front end of the site is not bothered by the changes... Even after clearing the cache. Classic theme (Presta's default).

Share this post


Link to post
Share on other sites

I also experience this after updating to 1.7.5.1

Share this post


Link to post
Share on other sites

The updated translations (is saved) but is not updated in front or back office, is still displayed the old value (1.7.5.1)

 

Edited by TonyJP (see edit history)

Share this post


Link to post
Share on other sites

I think you observe this because of enabled caching. Clear the caches or disable them temporarily. It happens for product edits as well, at least for me, that is.

 

Also, I have another problem with translations, which is that they are updated (I even see them through PHPMyAdmin in the tables) but still with all caches turned off, the texts in the contact form are not changing from English.

Other texts change, just those in the contact us and some partially translated strings in the cart stay in English. I checked them in the MySQL DB and they are translated, exported the language and they are translated. I have no idea what to do.

I think it is something from my theme Vinova Sport but I don't know what. Also at seemingly random, some of the translations just reset and clear to English and I have to translate them again which is weird and it happened about 5 times already.

Edited by wutsdis (see edit history)

Share this post


Link to post
Share on other sites

I have same thing as you wutsdis but with some other strings.

Share this post


Link to post
Share on other sites

The only workaround for the strings to appear translated is to hardcode them translated into the theme template code, but I don't like that solution particularly. 😞

Edited by wutsdis (see edit history)

Share this post


Link to post
Share on other sites

This had cost me so much time to solve. I hope it will help someone else. In my case, it seems that the theme creator made some kind of a problem. I am using the Vinova Sport theme.
 

The problematic strings I had were in the checkout templates, there were also some others in the /layouts and possibly more in other places. I changed their domain, in my case:

from

d='Shop.Theme'

to

d='Shop.Theme.Checkout'

and for some of the other missing strings from 

d='Shop.Theme'

to

d='Shop.Theme.Global'

Then I translated them from the back office and it worked.

Edited by wutsdis (see edit history)

Share this post


Link to post
Share on other sites

Glad that worked for you. ;:)

I'm still confused... One of the ones that doesnt work for me was:

{l s='Showing %from%-%to% of %total% items' sprintf=['%from%' => $pagination.items_shown_from ,'%to%' => $pagination.items_shown_to, '%total%' => $pagination.total_items] d='Shop.Theme.Catalog'}


I changed it to this and it works (as that old string already was translated long before).

{l s='Showing %from%-%to% of %total% item(s)' d='Shop.Theme.Catalog' sprintf=['%from%' => $pagination.items_shown_from ,'%to%' => $pagination.items_shown_to, '%total%' => $pagination.total_items]}


However, changing it and then translating the new string says "saved" and then doesn't show up in front office :(

{l s='Showing %from%-%to% of %total% products' d='Shop.Theme.Catalog' sprintf=['%from%' => $pagination.items_shown_from ,'%to%' => $pagination.items_shown_to, '%total%' => $pagination.total_items]}





Also, after it says that the translation got saved. It will say this above the field:
ShopThemeCatalog - 1 expression - -1 missing

Edited by nom (see edit history)

Share this post


Link to post
Share on other sites

I used these docs, maybe you could find something helpful in there https://devdocs.prestashop.com/1.7/development/internationalization/translation/translation-domains/

Try to add just the simple text string first and see if it works, maybe there is a problem with the %placeholders%.

I also get that red missing text warning a lot of times when saving, sometimes it increases to -5. I have no idea what it means.

Edited by wutsdis (see edit history)

Share this post


Link to post
Share on other sites

Tried {l s='Showing test' d='Shop.Theme.Catalog'} and that worked. :S Thank you so much for your advice. I will do a work around with the placeholders.

Share this post


Link to post
Share on other sites
On 3/23/2019 at 12:36 AM, wutsdis said:

I think you observe this because of enabled caching. Clear the caches or disable them temporarily. It happens for product edits as well, at least for me, that is.

 

I have completely and utterly disabled cache, yet it still happens. I also tried cleaning it every time I save. What I noticed, however, is that I simply have to wait after each time I save a new translation. So yes, you're partially right - it is caused by some kind of cache, even when I disable all of caching functions in PrestaShop settings.

What actually happens is that when I press "Save" the translation is correctly saved to the PHP file (modules/module_name/translations/pl.php). The translation file gets immediately updated on the server. However, it simply takes some time for PrestaShop to detect the updated PHP file and show the translations in the administration panel 

In other words, every time I am translating something, I make sure to simply wait around 5-10 minutes each time I press "save". I press "Save", the website reloads and the translations fields remain empty. That's the moment where I have to wait. I leave the translation settings and come back after 5-10 minutes. Boom, last translations show up and I can continue adding more. 

I have to be careful not to press "Save" again before PrestaShop detects previous translations. If I do it before PrestaShop detects the last translations they will be replaced with empty strings. SUPER annoying. I think it might have to do something with the cache on the website hosting for PHP files?

Edited by finnenhawke (see edit history)

Share this post


Link to post
Share on other sites

Yes, this is what is doing it for me, it is called OPcache, I should've been more clear. It is something you should have control over from the cpanel of your hosting provider.

Share this post


Link to post
Share on other sites

I am using Prestashop v 1.7.5.2 and it seems the module translation is not working (empty fields after submit, not saving). Anyone found how to solve this?
 

Share this post


Link to post
Share on other sites

I had a similar issue and just could not save the Shop > Theme > Catalog translation properly.  I manually entered the row in table ps_translations.  It worked.

Share this post


Link to post
Share on other sites

This is so freaking annoying!!!

1.7.6.1, opcached disabled.. I translate one string and there... done for the day...

Has this been figured out already? The issue is closed!

Share this post


Link to post
Share on other sites

The new translation system is bugged. I posted a report starting from here: https://github.com/PrestaShop/PrestaShop/issues/15432#issuecomment-528809111

I had problems with a theme and some modules. The theme could have an error breaking the file parsing.
About the module i could resolve translating it manually, like the old method (module folder, "languages", file with iso code .php). The problem could happen with old modules. The BO could have empty strings, or they could seem working, but the xlf files are ignored, so the module remains not translated. I reported the solution here https://github.com/PrestaShop/PrestaShop/issues/15432#issuecomment-528836586

They suggest to report the problem to the module/theme developers, but i had to guess by myself what was going on... and hopefully i fond the work around.

 

Share this post


Link to post
Share on other sites

My problem is the string is already translated but i need to change it.. It changes in the backoffice but the frontoffice remains the same..

I try again the next day and it works..

  • Like 1

Share this post


Link to post
Share on other sites

i had smiliar issue too. i changed my php version to 7.2 and now its working

Share this post


Link to post
Share on other sites

I am still facing this issue @1.7.6.3. The workaround is to add the translations manually:

INSERT INTO `ps_translation` 
(
  `id_lang`,
  `key`,
  `translation`,
  `domain`,
  `theme`
) VALUES
(
  yourlangid,
  'An email has been sent to your mail address %email%.',
  'your translation text here with placeholder of %email%.',
  'ShopThemeCheckout',
  'yourthemename'
);

Replace yourlangid with the id of your language and 'yourthemename' with the name of your theme. You can safely ignore the id_translation value in your insert statement because that is a primary key with auto increment.

Share this post


Link to post
Share on other sites

Huge prestashop problem with translations saving continues from one version to another. Prestashop does nothing with issue in all new versions.

Share this post


Link to post
Share on other sites

I try to help you finding what is happening in your website. I did a lot of research in this issue and I sum all my findings so far.

Problems

  1. The theme is not translated using the official method via Back Office. The theme is missing some strings, or is not saving what you input, or is not showing what is really translated in Front Office.
  2. The modules are not translated using the official method via Back Office.
     

The code in the templates and hints on how we can access to the translations

  1. In themes, the new system defines two parameters: the string (variable s), and the domain (variable d). Example: {l s='Refresh' d='Shop.Theme.Actions'}. You use the Back Office, translations, and then choose the theme translation. You find many sub groups, open them according the domain.
  2. In modules there is a mess, we can have 4 different scenarios (maybe more? I don't know):
    1. a string identical to the theme domain, for example {l s='My alerts' d='Shop.Theme.Catalog'}, so, this is translated by the theme, under the sub group "Modules". You need to know the name of the module, in this case "Mailalerts", and then you find "Shop".
    2. a string slightly different, for example {l s='Message' d='Shop.Forms.Labels'}, in this case we know it is the module "contactform", but it is useless, because you can't find it in the sub group "Modules" like before, instead, the strings are inside the sub group "Shop", then "Forms", then "Labels". Don't ask me why.
    3. a string having domain Modules instead of Shop, for example {l s='You have chosen the cash on delivery method.' d='Modules.Cashondelivery.Shop'}. This is the Cash on Delivery module. This time you must not translate the theme, you select the module translation. Again, don't ask me why they decided to put some modules in the theme, and others in the modules translation.
    4. Last but not least, a string translated by the module itself, in the old school (Prestashop 1.6 and below), for example: {l s='Account' mod='roy_levibox'}. We find this many times, because modules are old, in this case the Back Office can manage them pressing the button "translate" when you are inside a module (you need to access via "Module Manager"). But sometimes this method is useless too, no matter how much you try, Back Office is not working.
      You can do two different solutions: you could replace the strings in templates using the new domain system, so you can translate with Back Office. Or, you better translate the module manually! Make a folder "translations" inside the module, then make a PHP file with iso code as name, if you want italian you make "it.php", and inside the file you write all strings according the old syntax, with MD5 and so on (explanations are too long, find them, learn from other modules). 

 

Positions where the translations could be, why Prestashop is behaving weird

  1. In database there is a table "ps_translation" (prefix could be different), this is the first source where Prestashop takes the strings for your theme (and some modules as well, isn't it?). If you think you are missing some strings, see the comment of Dandry for the SQL injection of new records. Or use PhpMyAdmin, you can see the parameters are:
    id_lang -> ID language, if you have a fresh install with just one language, it should be "1", always. Else, you find the ID of each language in the table ps_lang
    key -> Original string to translate, example "Checkout"
    translation -> Your translation, example "Cassa"
    domain -> Now you understand what this weirdo is. For example "ShopThemeActions", in your template it is separated by dots "Shop.Theme.Actions".
    theme -> your theme name, for example "leo_shopsmart". Attention: when you install more themes and you remove them, the records in this table are never deleted accordingly, you can clean the crap manually.
  2. The xlf files inside the folder app/Resources/translations/ are the second source where Prestashop takes the strings. If your Back Office is acting weird, you can't find some strings, or your Front Office is never updated, then you can find the strings in these files, and modify them manually.
  3. The translations folders inside the modules, this is the old school. Add or modify languages as I described already.


You did anything i told you, and your Front Office is still WRONG???

Wait! No panic, Prestashop is making Smarty cache. It was disabled already? Well, don't trust Prestashop, i told you it is weird. Press that blue button "clear cache".
Now it should be good. Epico!

 

Share this post


Link to post
Share on other sites
On 10/18/2019 at 5:50 PM, taniacr said:

My problem is the string is already translated but i need to change it.. It changes in the backoffice but the frontoffice remains the same..

I try again the next day and it works..

Same problem here... i'm getting crazy

Share this post


Link to post
Share on other sites
Posted (edited)

Ok, this is crazy

1.7.6.4 here

Find the xml files and edit by hand

app/Resources/translations/*.xml

 

 

 

Edited by Courage2000 (see edit history)

Share this post


Link to post
Share on other sites

Hey Guys !

Find it !

It is an applicative cache issue

You need to connect to your server ny FTP or SSH

and remove the content of the folder  app/cache/*

Thanks

Share this post


Link to post
Share on other sites

You have Remove Cache on Performance Settings.

The problem is that the translation is NOT SAVED!

Share this post


Link to post
Share on other sites

Hi, we are having same issues. I've tried different things and the front-end translations doesn't change.

I've cleared cache, recompiled templates, changed translation files manually and nothing. Front-end keeps the old translations.

Ps version: 1.7.6.2

Share this post


Link to post
Share on other sites

Permissions checked they seem to be ok (755 for folders and 644 for files).

Didn't find the module for fixing them though.

Share this post


Link to post
Share on other sites
16 minutes ago, Dexter Morgan said:

Tested no changes.

whats your php version?

Share this post


Link to post
Share on other sites

My prestashop 1.7.6.5 with PHP 7.3 Save Translation only if i click on Save Button 2 times and all single quote doesn't work.

Share this post


Link to post
Share on other sites

Well the thing is that translations are saved (at least the ones I am worried about) but they are not applied to the pages even though I recompile all templates.

Share this post


Link to post
Share on other sites
On 5/20/2020 at 9:59 AM, Dexter Morgan said:

Well the thing is that translations are saved (at least the ones I am worried about) but they are not applied to the pages even though I recompile all templates.

I'm having the same issue on PrestaShop 1.7.6.4. I can see the translations saved into DB, but they're not reflected on frontend. Cache is disabled. The problem is very weird. One day the translation for mod='modulename' didn't work, so I switched all to d='Shop.Theme.Global' and it started working. Another day I found out that Shop.Theme.Global no longer works. I switched back to mod='modulename' and it worked then.

This issue should be given high priority. I find it critical for successful shop management. Now we're dealing with 1 shop, but we'll shortly add couple more. If I new about this bug before we decided to use PrestaShop, we would probably choose another engine. It's highly concerning that it hasn't been fixed for a year, now.

Share this post


Link to post
Share on other sites
On 5/19/2020 at 12:41 PM, xlkiller said:

My prestashop 1.7.6.5 with PHP 7.3 Save Translation only if i click on Save Button 2 times and all single quote doesn't work.

I solve my single quote problem. 

I replace single quote ' by typographic symbol ’ (ALT+0146)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More