Missing "Save all" button in translation

[ALM]

Hi, guys,

For translation purposes I use a translation module with 1-click translation for all strings that are not translated. Somehow I miss the button "Save all" in TB. For this reason I have to save each module one by one, step by step. This is not really comfortable and quite time consuming.

In the attachment I provide screenshots of PS1.6 and TB. Is there a reason for the missing "Save All" button in TB?

Regards
Alexander

[Wartin]

9 hours ago, ALM said:

Hi, guys,

For translation purposes I use a translation module with 1-click translation for all strings that are not translated. Somehow I miss the button "Save all" in TB. For this reason I have to save each module one by one, step by step. This is not really comfortable and quite time consuming.

In the attachment I provide screenshots of PS1.6 and TB. Is there a reason for the missing "Save All" button in TB?

Regards
Alexander

Maybe it is in the bottom of the page?

[ALM]

18 hours ago, Wartin said:

Maybe it is in the bottom of the page?

 

unfortunately not ;-(

The following is a comparison of the availability of the save buttons:

Save button for all modified strings of all modules in PS: Yes
Save button for all modified strings of one module in PS: Yes

Save button for all modified strings of all modules in TB: NO
Save button for all modified strings of one module in TB: Yes

For translation purposes I use a translation module with 1-click translation for all strings for all modules, but I cannot save it at all.

Any idea what goes wrong here?

Edited October 1, 2020 by ALM

[ALM]

Hey,

Am I the only person using the 1-Click module for translation? Any comments from the 30bees core team?

[datakick]

The translation page used to submit *all* translation strings, which could be a lot. This often caused server issues with max_input_vars php settings:

Warning! Your PHP configuration limits the maximum number of fields allowed in a form to 1000
Please ask your hosting provider to increase this limit to 2266 at least, or you will have to edit the translation files.

On many shared servers this parameter could not be changed, which made the translation process totally unusable. Even if it was possible to change this php configuration parameter, this was still a nasty UX issue - translation functionality was not readily available for many users.

In thirtybees 1.1.0 this was 'fixed' by submitting single section only.

This fix was definitely not optimal. First of all, it's not a real fix -- if one section contains more than max_input_vars strings then users will still encounter the same issue. There are other ways to bypass this php limitations and keep the option to submit more than one section at the time. Maybe in the future such solution will be implemented. Until then you will have to save each and every translation section separately.

[yaniv14]

Maybe you can try hold CTRL while clicking on save button on each section.

This will submit the request in a new tab and keep the current tab open, so basically you can keep on clicking all the other sections.

[ALM]

@yaniv14 Very good idea, but unfortunately this workaround does not work. If you hold down the CTRL key while clicking the "Save" button in each section, the request will not be opened in a new TAB, but will remain in the same TAB (tested with Mozilla and IE)

@datakick Thanks for the explanation. I just wanted to make sure that my TB installation works properly after the migration. Anyway, to be honest, with PS1.6 I never had the problem of max_input_vars with translation processes on shared servers. The above workaround might be a good solution, but unfortunately it does not work for me.

So far it is not a big problem, but not comfortable.

[datakick]

4 minutes ago, ALM said:

@datakick Thanks for the explanation. I just wanted to make sure that my TB installation works properly after the migration. Anyway, to be honest, with PS1.6 I never had the problem of max_input_vars with translation processes on shared servers. The above workaround might be a good solution, but unfortunately it does not work for me.

Many merchants run on pretty good servers, so they were lucky enough to never experience this problem. But there are a lot of them that did, unfortunately. If you search for this error message on ps forum you will find countless threads dealing with this issue, such as this one: https://www.prestashop.com/forums/topic/633811-warning-your-php-configuration-limit/. Or another one here on thirtybees forum: https://forum.thirtybees.com/topic/2317-2317/solved-warning-your-php-configuration-limits-the-maximum-number-of-fields-allowed-in-a-form-1000-for-max_input_vars/

 

 

Thanks to the fix, thirtybees is in better shape than it was before. We used to have merchants reporting issues like "I can't use translation tool". Now we have requests like "I would like to save more translations strings at once". The first one was a bug, the later is the feature request. Hopefully we will be able to implement it soon 🙂

[led24ee]

This translation thing is better keep in file and import. Yes this can be take more time, but You  have all translations and when your store "blows up" then all translations will be completely safe (of course depends where you hold this file). You can add in this file all kind extra stuff, even these what you can't find in original "language import" file. For example all items on admin panel menu, all emails, etc. After all, usually this translation is done once, later you Can make corrections. But then again, this is all different when there are several people for whole process: one find error, another report this error, then there is need to "approve" this correction and then there is some guy who is permitted to "press button".

[ALM]

OK, is there any short instruction available how to handle translation "in file and import"?

Sorry, never did that before...

[led24ee]

I don't have this instruction. For me this know-how is only thru the practice. Also this isn't easy way. It takes pretty much time to understand how and why there are some thing. (At least for me) But how this file looks ? You can start with export (this is in translation page) and then look inside compressed file. Also if this translation is once done You can also make "export file" and then You have not all, but something like 80% of translations and in next shop there is need for "import" and then look what is missing. For gzip file I use 7-zip. Inside this package are text files with php extension and for editing these files I use Notepad2. I started all this when there PS 1.6 and now if I need start new shop there is only need for "import". Yes, when there is new module then I insert all this data to this gzip file and this takes some time. But then again, all translations are in one place when there is need. Thru all versions on TB there is 4 or 5 items, which are unable to translate, because there is something wrong in TB. But this is in administrator area some error messages and in "real life" i haven't seen never these errors. Well, if all this didn't look very scary then You can try.

Edited October 8, 2020 by led24ee

[Raymond]

Hello

This workaround is ok for those not using a powerful server but at the same time creates lots of time losses to those who do not have that problem.

I think that leaving the chance to use a save all button while advising with a note to first back up the language files might be a middle way solution for the case?

 

[ALM]

Hello,

I would also appreciate the suggestion to be able to use the "Save All" button with a note. To be honest, my store runs on a shared server, but I've never had any problems with the "Save All" button in PS.

[datakick]

I have created an issue for this 'bug': https://github.com/thirtybees/thirtybees/issues/1434

In my opinion, the change to save translations per section was very bad decision, and should be fixed. Of course, the fix should ensure that the original problem with max_input_vars is addressed as well.