I've received feedback, and our Second Tier Support team believes that this issue may be linked to user account permissions. Upon inspecting the current existing accounts, I noticed that certain permissions are listed below the backend profile dashboard, as depicted in the attached screenshot. However, when I created a new user, these permissions did not appear.
I'm not sure why the new user doesn't have it. Does something have to be set somewhere in the settings of your plugins so that all users can see their additional capabilities?
I have some feedback to share based on what our 2nd Tier Support mentioned.
It has come to our attention that the admin string "tablepress_tables" is being translated. It is advisable to either match the translation with the original value or refrain from translating this option altogether.
Please refer to the provided screenshot. In the original, the last ID is 74, whereas in the translation, it is 40. Consequently, users with their language set to Croatian will encounter errors if they attempt to access a table with an ID higher than 40. This can be resolved by either aligning the translation with the original value or switching the user's language/admin language to English, enabling access to all values up to 74.
To rectify this issue, we copied the original string to the translation and now it works. Could you please verify?
I confirm that I can now normally enter data into any table and save.
I can also create new tables. Can you explain again:
a) How did this problem occur?
b) How did you solve it?
c) How can we not have that bug in the future?
d) Can we remove the admin string "tablepress_tables" so that it is not translated? Will that help us to not have this problem?
a) How did this problem occur?
According to our 2nd Tier Support, the admin string - tablepress_tables was translated and we cannot trace who did it.
b) How did you solve it?
As shown in the attached screenshot, we removed the strings and used the copy option so that both languages use the same string.
c) How can we not have that bug in the future?
We cannot promise since we have no clue why the admin string - tablepress_tables was translated.
d) Can we remove the admin string "tablepress_tables" so that it is not translated? Will that help us to not have this problem?
Please backup before you try this.
Maybe I should reformulate the questions a bit,
Why can the tablepress plugin and its tables be translated into another language even though you don't support it?
Does this mean we can translate tables normally like other posts?
How is it possible that the ids of the tables do not match in the languages?
Is it maybe a problem or maybe those tables ended up being translated because there used to be an option included in the settings of the plugin: 'TablePress Tables (tablepress_table)'->Translatable.
I also managed to solve the problem by setting:
TablePress Tables (tablepress_table)'->Not Translatable and I delete the entire tablepress_tables from String translations.
Now I don't know which option is better for me for production because we did all this on staging. Should I go with your option:
'we removed the strings and used the copy option so that both languages use the same string' or should I go with complete deletion?
As you know, tablepress is not fully tested with WPML or compatible, so we cannot answer your questions about whether or not tablepress can be translated normally like posts.
Since you're able to solve the problem TablePress Tables (tablepress_table)'->Not Translatable and I delete the entire tablepress_tables from String translations, I'd suggest using the method here.
Then, kindly ask the plugin author to join our 'Go Global' program (https://wpml.org/documentation/support/go-global-program/) where our Compatibility developers will help them make their product 100% compatible with WPML for free.
