Translations not saving

[x97wehner 49]

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?

[toplakd 182]

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.

[Factor 46]

I haven’t on 1.08 or BE.  Maybe check the file permissions in the backend.

[lesley 710]

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. 

[yaniv14 114]

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 

[x97wehner 49]

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.

[Traumflug 759]

Let's not forget this: https://github.com/thirtybees/thirtybees/issues/976

[datakick 1,134]

@x97wehner what tb version are you using? Is it bleeding edge? Please confirm

[x97wehner 49]

1 hour ago, datakick said:

@x97wehner what tb version are you using? Is it bleeding edge? Please confirm

bleeding edge

[the.rampage.rado 36]

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.

[rubben1985 82]

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

[datakick 1,134]

Have a look if you have these changes included in your code: https://github.com/thirtybees/thirtybees/commit/f3f0f1ab2538633111fdb902a7f2a40cbb835ae6

[rubben1985 82]

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.

 

[datakick 1,134]

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

[datakick 1,134]

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

[rubben1985 82]

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

[rubben1985 82]

@datakick all my test now they work now... I will post as soon as some day I find the problem

[led24ee 19]

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 

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"

[rubben1985 82]

@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 March 4 by rubben1985

[Peter 5]

On 2/28/2020 at 8:28 PM, datakick said:

Have a look if you have these changes included in your code: https://github.com/thirtybees/thirtybees/commit/f3f0f1ab2538633111fdb902a7f2a40cbb835ae6

I have this same problem but this file isn't at admin-dev/themes/default/template/controllers/translations/helpers/view/ I use 1.10 TB

[toplakd 182]

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 April 3 by toplakd

[toplakd 182]

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 April 3 by toplakd

[Sigi 5]

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?

[Wartin 13]

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.

[gatasi 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?

 

 

[toplakd 182]

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.