Invision Community 4: SEO, prepare for v5 and dormant account notifications Matt November 11, 2024Nov 11
Posted May 13, 20231 yr 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). Will those be auto-deleted at any time? Is it in any way harmful or "bad" to have these still in place there, or can I just ignore them? Is there a way to manually remove outdated/deprecated language strings?
May 15, 20231 yr You can safely ignore them. They are indeed items t hat have been removed from the software
June 9, 20231 yr I have tagged our developers on this. As mentioned, they will not cause you any issues.
June 9, 20231 yr 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
June 9, 20231 yr Author 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, 20231 yr by MMXII
June 9, 20231 yr 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.
June 9, 20231 yr 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'] ) ) ) ); } }
June 9, 20231 yr Author To illustrate what I wrote above regarding the language string r__fields_manage, here is a short video showing the issue: language_strings.mp4
June 9, 20231 yr 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: language_strings.mp4 2.67 MB · 0 downloads That's a different problem/bug where 2 apps used the same key!
June 9, 20231 yr 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.
June 9, 20231 yr Author 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, 20231 yr by MMXII
June 9, 20231 yr Author 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.
June 9, 20231 yr 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.