Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

  • 1
x97wehner

Translations not saving

Question

If I try and make a translation change of any sort, it doesn't work. Sometimes it shows in the translation mod UI, and sometimes not. I haven't found a pattern there. The only constant is that after clearing cache and reloading the affected web site pages, the translations are not taking. I check the translation file on the backend and it doesn't have my modifications included either.

Anyone else having the same behavior?

Share this post


Link to post
Share on other sites

Recommended Posts

  • 1

There is a bug in AdminTranslationsController.php which showed up after new version was introduced which does not need max_input_vars.

But, the one who rewrote the controller did not test it enough before putting it into official version.

You can either replace the controller with version from 1.0.8 or temporary modify the current one so existing translations don't get deleted.

Not able to save empty string means you are not able to save blank field.

  • Like 1

Share this post


Link to post
Share on other sites
  • 0

To make sure, are you aware of where the translations files save? If so, can you check the actual file to see if it saves in the file. I have seen this before on a couple of shops where the server is setup to not revalidate in opcache, causing it to load cached data for the translation, even though the change has actually saved. 

Share this post


Link to post
Share on other sites
  • 0

If you referring to theme module translations, there is a known bug.

I've committed a fix for that, but its only partial fix.

https://github.com/thirtybees/thirtybees/pull/958/commits/64f4bb9a238c08dd77252bc009ce37a5c0ff6124

Whats actually happening now is that the page shows the theme modules translations but when saving it saves it to the default theme instead.

If you are referring to other type of translation (not modules) than please explain exactly whats your issue with 

Share this post


Link to post
Share on other sites
  • 0

I'm referring to the UI within thirtybees back office. If I make adjustments to translations there, they do not save to a translations file as they should on a regular basis. For instance, if I pick @datakick's revws module, and attempt to modify core translations, via the UI, they will not save.

@lesley, yes, I'm aware. I've been able to open the translation files via ftp and attempt to do some of them, but I don't have the GUID's for each field to do them all. If I modify the actual file, via ftp, the translations take fine. It seems to be some issue in saving the file edits from the back office.

Share this post


Link to post
Share on other sites
  • 0

I noticed this today.

I had to revert to a backup of the db but I doubt it's the problem.

I noticed few strings that I'm pretty sure were translated and when I click save nothing happens, the page reloads with normal success text and the translation is not saved.

Tried disabling all caches, etc... Noting helped UNTIL I remembered the recent fix in template compilation.

Please can somebody make a info text there saying " "Please enable Force compilation" when you make manual changes to the templates or translations through BO". This will help lot of merchants I think.

  • Like 1

Share this post


Link to post
Share on other sites
  • 0

Is this already solved? I have 1.1.x bleeding edge from a couple of months ago but it is still present. I would update to last version if it is solved but if not I would not like to risk because the site is quite stable

Share this post


Link to post
Share on other sites
  • 0

Yes, i have them.

It seems after trying like a hundred times, it save some times.

I also had problems in front-office translations:

I modified a field-> Some others were deleted. After, I tried to modified those that were deleted and I only keep them not empty If I complete the whole "section". After a lot of times translating and saving, translating and saving (each time some fields were saved, others not...) I got them to stay but It seems there is some problem in the saving process.

 

Share this post


Link to post
Share on other sites
  • 0

I can't reproduce this. Can you show some screenshots? 

Share this post


Link to post
Share on other sites
  • 0

Also, note that you can translate only one 'section' at the time. It's a bit unfortunate 

image.png.138e8b101d1e310a5e556cd58d927633.png

  • Like 1

Share this post


Link to post
Share on other sites
  • 0

I tried to recorded but now it seems to work. As I have to work on translation next week, as soon as I have problems again, I will record to send you. Maybe there is a pattern to produce the error....

  • Like 1

Share this post


Link to post
Share on other sites
  • 0
On 2/28/2020 at 10:05 PM, datakick said:

Also, note that you can translate only one 'section' at the time. It's a bit unfortunate 

image.png.138e8b101d1e310a5e556cd58d927633.png

This one section was really annoying in the beginning, this wasn't so in PS. Now I'm accustomed. I think these buttons are better to rename. Simplest can add some words like "this section"

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

@datakick this could be why some of my translations did not work for me because I did not know it worked like that in TB. I would also suggest to change title to "Save this section" and "Save this section and stay". Still pending to reproduce the one that deleted the section. If that happens, I will recorded.

Edited by rubben1985

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

I found out something interesting when saving frontoffice translations for community/niara on V1.1 and Latest bleeding edge (totally fresh install).

When saving Address section, Addresses section above gets empty after saving.

Same with order-address-multishipping - order-address-multishipping-products  gets empy.

If I make save on authenthication all other sections that begin with authenthication- get empty.

I have tested with default englich language and made "upgraded language" before each test.

 

On 1.0.8 where we still needed max_input_vars, there is no such issue (tested)

Edited by toplakd
  • Like 1
  • Sad 1

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

Removing Line 1325 in AdminTranslationsController.php solves this issue with emptying other fieldsets that start with same name like address...

$_POST['theme'] or  $_POST['lang'] or  $_POST['type']

 

 

Only thing is, that one can not save empty string if that line is removed.

Edited by toplakd

Share this post


Link to post
Share on other sites
  • 0

i have this strange problem too. Changing a translation for a word in front-office, it deletes automatically existing translations.

What do you @toplakd mean with "one can not save empty string"? What are the consequences of this? Does it mean, I have to translate everything to be able to save?

Share this post


Link to post
Share on other sites
  • 0

It's really annoying, several times it un-translates some of the strings. Specially NEW and REDUCED PRICE (the whole product-list-item just becamed blank).

In a new TB there are 0 non translated strings (Spanish). After using TB for a couple of weeks I have like 250 in front office and 490 in modules.

FEATURE REQUEST: it would be really nice to import from a file but just non-translated strings.

Share this post


Link to post
Share on other sites
  • 0
On 4/3/2020 at 12:08 PM, toplakd said:

Removing Line 1325 in AdminTranslationsController.php solves this issue with emptying other fieldsets that start with same name like address...

$_POST['theme'] or  $_POST['lang'] or  $_POST['type']

 

 

Only thing is, that one can not save empty string if that line is removed.

I have the same issue.

"$_POST['lang'],", "$_POST['theme']," and "$_POST['type']" are lines 1323, 1325 and 1326 respectively. Did you comment 1325 only or all of them?

 

 

Share this post


Link to post
Share on other sites
  • 0

This is not correct solution for the problem, but removing the one at least don't empty other fields once saving.

For correct solution someone like @datakick or @Traumflug should take a look to see what can be done.

  • Like 1

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