Jump to content

PrestaShop 1.7.5.1 - Translations not saving / updating

finnenhawke

By finnenhawke
in Bug reports

 Share

Recommended Posts

finnenhawke Newbie

finnenhawke

Posted
Posted

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? 

Link to comment
Share on other sites
webmasterBS Newbie

webmasterBS

Posted
Posted

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

Link to comment
Share on other sites
wutsdis Newbie

wutsdis

Posted
Posted (edited)

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)
Link to comment
Share on other sites
wutsdis Newbie

wutsdis

Posted
Posted (edited)

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)
Link to comment
Share on other sites
nom Newbie

nom

Posted
Posted (edited)

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)
Link to comment
Share on other sites
wutsdis Newbie

wutsdis

Posted
Posted (edited)

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)
Link to comment
Share on other sites
finnenhawke Newbie

finnenhawke

Posted
  • Author
Posted (edited)
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)
Link to comment
Share on other sites
  • 2 months later...
  • 3 weeks later...
  • 2 weeks later...
  • 1 month later...
  • 1 month later...
zod Newbie

zod

Posted
Posted

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.

 

Link to comment
Share on other sites
  • 1 month later...
  • 2 months later...
Dandry Newbie

Dandry

Posted
Posted

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.

Link to comment
Share on other sites
  • 1 month later...
zod Newbie

zod

Posted
Posted

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!

 

  • Like 3
Link to comment
Share on other sites
danieleindino Newbie

danieleindino

Posted
Posted
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

Link to comment
Share on other sites
  • 1 month later...
Dexter Morgan Newbie

Dexter Morgan

Posted
Posted

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

Link to comment
Share on other sites
mlemanczyk Newbie

mlemanczyk

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

Link to comment
Share on other sites
OwnedFiston Apprentice

OwnedFiston

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

Link to comment
Share on other sites
  • 2 weeks later...
prospect Newbie

prospect

Posted
Posted (edited)
On 4/6/2020 at 7:31 PM, prospect said:

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

translation problem of prestashop is all the time, version after version.

no one can solve it and properly explain the reason for it. there may be a million reasons and none real.
this should be a prestashop priority to solve the problem. unfortunately prestashop ignores this and you see it version after version.

how can it be that it is not possible to normally translate another theme or another module through the prestashop backend into a clean prestashop installed ???!!!?

 

Edited by prospect (see edit history)
Link to comment
Share on other sites
huymanutd Newbie

huymanutd

Posted
Posted
On 4/9/2020 at 11:33 PM, zod said:

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!

 

Hi zod,

Have you had success in changing the word 'Contact Us' to 'Contact' (top left hand corner of the classic theme)?

I'm having this precise issue and I tried the three methods above but they didn't work.

1. checked the 'translations' table to make sure the translation entry exists

2. checked the files app/Resources/translations/default/ModulesContactinfoShop.xlf and app/Resources/translations/en-us/ModulesContactinfoShop.xlf to change the line         <target state="final">Contact</target>

3. Cleared cache via back office (Performance > Clear Cache) and checked the content of the folders: cache/smarty/compile & cache/smarty/cache to see they were empty (just having index.php)

Totally agree the current translation scheme is not user friendly.

gs 2020-06-14 10.09.11.png

gs 2020-06-14 10.09.48.png

Link to comment
Share on other sites
zod Newbie

zod

Posted
Posted (edited)
7 hours ago, huymanutd said:

Hi zod,

Have you had success in changing the word 'Contact Us' to 'Contact' (top left hand corner of the classic theme)?

I'm having this precise issue and I tried the three methods above but they didn't work.

1. checked the 'translations' table to make sure the translation entry exists

2. checked the files app/Resources/translations/default/ModulesContactinfoShop.xlf and app/Resources/translations/en-us/ModulesContactinfoShop.xlf to change the line         <target state="final">Contact</target>

3. Cleared cache via back office (Performance > Clear Cache) and checked the content of the folders: cache/smarty/compile & cache/smarty/cache to see they were empty (just having index.php)

Totally agree the current translation scheme is not user friendly.

First thing first! When you want to change a string you need to find and analyze the template. In your case your template is this: /themes/classic/modules/ps_contactinfo/nav.tpl

So, you open it and you discover the link, and the string involved: <a href="{$urls.pages.contact}">{l s='Contact us' d='Shop.Theme.Global'}</a>

You modified the wrong strings, because the real one is in the Global section of your theme. 

Edited by zod (see edit history)
  • Like 1
  • Thanks 1
Link to comment
Share on other sites
huymanutd Newbie

huymanutd

Posted
Posted
4 hours ago, zod said:

First thing first! When you want to change a string you need to find and analyze the template. In your case your template is this: /themes/classic/modules/ps_contactinfo/nav.tpl

So, you open it and you discover the link, and the string involved: <a href="{$urls.pages.contact}">{l s='Contact us' d='Shop.Theme.Global'}</a>

You modified the wrong strings, because the real one is in the Global section of your theme. 

You got it! Yeah i was looking at the wrong template file under modules/ps_contactinfo/nav.tpl & didn't realise it is overwritten by the nav.tpl in the Global Theme.

After changing the two files: 

app/Resources/translations/en-US/ShopThemeGlobal.en-US.xlf & app/Resources/translations/default/ShopThemeGloba.xlf & clearing cache,  I was able to see the change.

Thanks heaps!

Link to comment
Share on other sites
  • 8 months later...
hstrom Newbie

hstrom

Posted
Posted

I had issues in regards to product listings, where "Add to cart" etc wasn't translated. In themes/TEMPLATE/templates/catalog/_partials/miniatures/product.tpl the string was "{l s='Add to cart'}". I followed @zod recommendation above - I changed it to: "{l s='Add to cart' d='Shop.Theme.Global'}" and now it works!

It seems to be theme related, not PS related... 

Link to comment
Share on other sites
  • 5 months later...
  • 4 months later...
manufourc Newbie

manufourc

Posted
Posted

Hi everyone,

I noticed that there are strings of characters that cannot be used in translations otherwise they are not saved. Here is the list:

  • %b and % b
  • %c and % c
  • %d and % d
  • %e and % e
  • %f and % f
  • %o and % o
  • %s and % s
  • %u and % u
  • %x and % x

Does anybody have the same problem ?

PS version : 1.7.7.1
PHP version : 7.3

Link to comment
Share on other sites
  • 1 year later...
WebmasterZv Newbie

WebmasterZv

Posted
Posted (edited)

Hello guys,

I had the same issues with translation of contact infos menu in Greek in 1.7.8 Prestashop. During my research i found that the same problem occurs in multiple languages stores especially with Greek, Czech and Polish language.
First try from BO to disable cache and clear it right after. Clear your browser's cache also and refresh your store's page. I hope this will work in most cases, if not i will write you what i have done.

I made a clean install of 8.0.4 in English language (first i deleted everything from my server, but i kept backup from DB files, like customers, addresses etc.).

When i finished with installation i turned off cashe and cleared it (turn it on again only when your store goes live and never before finish with translation and any modules installations, updates etc.).
Then i add my second language (Greek). I continued with English as primary and Greek as secondary.
Do not install any Theme or any module at this point until to finish with translations.

I translated from BO the files and saved them (now the files was saving from BO before they wasn't) but the translation in front store was still buggy.
I edited manually the 2 files in public_html/translations "ModulesContactinfoShop.el-GR.xlf" and "ShopThemeGlobal.el-GR.xlf".
I cleared browser cache and BOOM worked.

6454c9ce3b248.jpg

6453c0cfe6514.jpg

Edited by WebmasterZv (see edit history)
Link to comment
Share on other sites
  • 1 year later...
AlexLopatenco Newbie

AlexLopatenco

Posted
Posted

Hi.

This is an ongoing problem.
I have prestashop 1.7.8.11 installed with PHP 7.4
it was a headache but I found the problem (at least in my case). Maybe it will be of some help to someone.

I changed the translation in the 

Shop parameters -> Traffic & SEO -> SEO & URLs

And choose the desired Page that should be translated. (In my case, it was 'My account' and 'Addresses')
image.thumb.png.990edc334eaf83f895a7e69027abe17e.png

Link to comment
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
 Share
Go to topic listing
×
×
  • Create New...