Removing extra entries in Translatepress

For example, in my there trp_original_strings table, there are

5. SHOWROO
176. SHOWROOM
271. Showroom

How do I filter out those unused ones and delete them?
In my case, I want to remove 5 and 271

Thank you.

Or can I delete everything and make translatepress scan everything again?

Hello,

Thank you for reaching out to us!

For the time being, there is no in-built function that manages unusued translations.

Everything is saved into the database, string by string, in the wp_trp* tables and needs to be manually deleted.

>Or can I delete everything and make translatepress scan everything again?

Yes but please be careful not to delete the translation tables.

Best regards,

I also would be interested in such a feature.

However, I understand that this is not easy with the way translatepress works and I even think, in most cases, this is more a psychological issue:
Imagine, every second row in your trp database is “dead”. Would that worry you? Probably.
Now imagine, you only have one language (no translatepress), but your website will grow and next year you’ll have doubled your blog posts and articles. Would that worry you? Surely not.
In both cases, you are just having twice the amount of data than today. And wordpress will have no problem to handle that and a lot more.

I think the problem is smaller than it feels, but it can still be “a mess” (fortunately, limited to the trp_*-Tables) that grows when there is much data dynamically generated. Even if those dynamic data never gets translated, it will be stored by translatepress.

Feature Request #1
I assume, it should help to delete all the empty (= untranslated) rows from time to time. I’d like to see an “remove empty rows” next to the “remove duplicate rows”-feature. After that, translatePress will add only the strings that are still existing again.

Feature Request #2
To get rid of strings that actually have been translated but are not used any more, I would suggest a “last read”-column and a “log last read” debugging option for that. So, you could enable this setting for a limited time (because it would slow down the page, so only one week for example) and after that, every translation that was not used within that week would get moved to a “backup”-database. There it would be available via the translation memory function for the cases where you figure out that it is still needed even though it was not used in the logging period. And than there would be a “permanently remove unused translations” function that would empty the backup tables.

But I suspect that the developers of translatepress already had smarter thoughts on that topic than I was able to have ??
Please let me know.

• This reply was modified 3 years, 9 months ago by dartrax.

I’d also love Feature #1!!

Hi,

Maybe the solution would be to edit the string and not create a new string everytime we edit a string.

This way we won’t loose the translation everytime we edit a typo error
and this won’t create orphan string.

What do you think?

Hi @lenamtl,
that would not work. Once you edit a string in WordPress, translatepress looses the connection to the translations of this string, therefore it cannot edit the translations, it can only create new ones. This is because when you look from the view of a database, for translatepress the string itself is the ID that is used to make the connections to the translations. If you change the string, internally you change the ID, and the relationship is gone.

This is the drawback of being able to translate everything in a search-and-replace-manner.

• This reply was modified 3 years, 8 months ago by dartrax.

I have not installed any solution yet but I was motivated especially with the solution you provided for email translation.

Will Translatepress become slow after a while when scanning the page because of all those orphan string?

I just don’t know what to choose Translatepress or WPML, the only 2 solutions can be compatible with my installation?

• This reply was modified 3 years, 8 months ago by lenamtl.
• This reply was modified 3 years, 8 months ago by lenamtl.

I’d recommend to check out both in a testing environment. I made 4 copies of my website and compaired PolyLang, translatePress and FaLang against a one language only version. I’ve translated two pages (ecommerce catalog page and product page) in each plugin and compaired the loading speed (ttfb) – for each plugin in default and in translated version.
As it turned out, not only the page speed is important, also the user interface is quite different. With PolyLang for example, every product in your shop will be multiplied by the number of your languages. If you have 100 products in your shop, after translating in 3 languages you’ll have to manage 300 products on the UI. The same for categories, tags, attributes and so on. What a mess.
You also have to check:
– does the translation solution supports search and live search?
– does it support product variations and custom product attributs (FaLang and PolyLang does not!)?
– does it support translation Emails?
– does it support SEO?
– …
You can’t find that out without testing. So I really recommend to test for yourself and get your own opinion about it!

As for the speed, I don’t know. I believe that many orphaned strings will only have an small impact if any, but that’s only speculation, I do not know and I did not test. What I will do is to watch and clean the empty rows from time to time, and to hope that translatePress will come with a solution for this somewhere in the future.