Outdated language strings?

[MMXII]

When I take a look at my translations (AdminCP > Customization > Languages), I found some empty language strings. For example:

I guess that these come from deprecated features (in this case acp log files for hosting errors when hosting was still a thing in the commerce app).

1. Will those be auto-deleted at any time?
2. Is it in any way harmful or "bad" to have these still in place there, or can I just ignore them?
3. Is there a way to manually remove outdated/deprecated language strings?

[Marc]

You can safely ignore them. They are indeed items t hat have been removed from the software

[MMXII]

Is there a way to get rid of these? They do not seem to get auto-deleted.

[Jim M]

Are the language strings still translated? 

[MMXII]

No, they are empty like you can see in the initial screenshot.

[Marc]

I have tagged our developers on this. As mentioned, they will not cause you any issues.

[Daniel F]

On 5/13/2023 at 12:45 PM, MMXII said:

Will those be auto-deleted at any time?

What version are you on?

These strings should have been deleted while the upgrade to 4.7.9 Beta 1

[MMXII]

I currently use version 4.7.10.

[MMXII]

Also, another weird behavior I noticed: When I look up for example the language string r__fields_manage (this exists twice, but I am talking about the outdated one tied to the Downloads app, as there is no English text provided anymore), it still holds my translation. When I delete my translation text and save the change, then leave the language section in the AdminCP, and go back there later, the language string again holds my translation. So deleting and saving does not seem to empty it.

The same goes for a couple more language strings. Their text cannot be deleted/emptied as it always returns once I reopen the translation.

Edited June 9, 2023 by MMXII

[Adriano Faria]

Are you using a custom language?

If it’s a custom, empty translated strings will indeed exists. They are language bits deleted by IPS but still present in your translation.

[Daniel F]

This shouldn't happen, we're removing them based on the app and key so it's going to remove it from all languages no matter if it's translated or customized.

	/* Delete removed language strings */ 
							if( file_exists( \IPS\ROOT_PATH . "/applications/{$data['key']}/setup/upg_{$_next}/lang.json" ) )
 							{
 								$langChanges = json_decode( \file_get_contents( \IPS\ROOT_PATH . "/applications/{$data['key']}/setup/upg_{$_next}/lang.json" ), TRUE );
 								if ( isset( $langChanges['normal']['removed'] ) and $langChanges['normal']['removed'] )
 								{
 									\IPS\Db::i()->delete( 'core_sys_lang_words', array( array( 'word_app=?', $data['key'] ), array( 'word_js=0' ), array( \IPS\Db::i()->in( 'word_key', $langChanges['normal']['removed'] ) ) ) );
 								}
 								if ( isset( $langChanges['js']['removed'] ) and $langChanges['js']['removed'] )
 								{
 									\IPS\Db::i()->delete( 'core_sys_lang_words', array( array( 'word_app=?', $data['key'] ), array( 'word_js=1' ), array( \IPS\Db::i()->in( 'word_key', $langChanges['js']['removed'] ) ) ) );
 								}
 							}

 

[MMXII]

To illustrate what I wrote above regarding the language string r__fields_manage, here is a short video showing the issue:

[Daniel F]

Just now, MMXII said:

To illustrate what I wrote above regarding the language string r__fields_manage, here is a short video showing the issue:

 

That's a different problem/bug where 2 apps used the same key!

 

[Adriano Faria]

11 minutes ago, Daniel F said:

This shouldn't happen, we're removing them based on the app and key so it's going to remove it from all languages no matter if it's translated or customized.

It’s in the XML so every time we update it, deleted language bits are back. It really should have a tool to detect orphaned language bits and doesn’t export them.

It's pretty hard and very time consuming to do this manually.

[MMXII]

So if I manually remove all empty outdated strings from the corresponding MySQL table, those strings should not be added to the XML file anymore, if I export the language file in the future, right?

Edited June 9, 2023 by MMXII

[Marc]

I believe it's the other way around

[MMXII]

I use this query

SELECT * FROM `core_sys_lang_words` WHERE `word_key` LIKE 'r__rss_add' ORDER BY `word_key` ASC 

to find for example the language string r__rss_add. Then I find the outdated string (which still holds my translation).

Then I have to manually remove this entry to a) remove the outdated string and b) be able to actually save the translation* to the correct string (which is the one that is tied to the Core app).

Wow, that is a lot of work, because there are tons of outdated language strings by now. 😞 I am afraid there is no easier way to do this? Or is there a reliable MySQL query to display all outdated strings?

* By the way: Only now this works! Before, even if I added a translation to r__rss_add via the language tools in the AdminCP, it would not let me save it permanently, which seems to be a bug.

[Daniel F]

2 hours ago, MMXII said:

* By the way: Only now this works! Before, even if I added a translation to r__rss_add via the language tools in the AdminCP, it would not let me save it permanently, which seems to be a bug.

The "issue"(not bug per se) is, that the system won't save the change once there are 2 or more language strings with the same key but in different apps.