@aDaneinSpain has created a tool for searching for unused language strings. https://github.com/Jensen-Technologies/Find-Unused-Joomla-Language-Constants
I have done a quick test of one component (banners) it would appear that the tool is finding a lot of unused strings.
Anyone got any suggestions on how we should handle this. Surely it is better not to have unused strings as that just makes the job of translators harder - especially for new languages
If they are not being used then why cant they be removed now. There is no
b/c issue if an unused language string in com_banners is removed. In 2
years we might not even have com_banners
As long as language files are not “locked” to a specific version strings cannot be removed. Eg: you get swiss lang file for 3.3.7 (latest) but you run on 3.2, if strings are removed in the latest version you get some ugly text… One way to solve this is to lock files per version e.g.. swiss_3-3-7.pkg (or something like that), but I don’t know if there are other side effects doing that.
There is no reason for someone to be running an old, outdated and insecure version of joomla. A missing language string isnthe least of their problems
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4898.
Of course you’re right! I just stated my own, still fresh, experience and the lesson I learned: don’t touch lang files
Maybe a little bent of the rules here is not that bad. We can keep this B/C policy but for all 3.2.X, 3.3.X etc So if you are on 3.3.1 to 3.3.9 get 3.3.9. Or something like that.
It doesn’t really make any sense to keep inflating the files UNTILL 4.0
When we wrote the new strategy, we also discussed the language strings in PLT. As far as I remember we decided to not remove them. I couldn't find it in the final document however.
Imho, it doesn't really hurt to keep them. It makes the language packs a little bit bigger in size. It isn't worth the risk of breaking a site by removing one string that is still used (and be it only in an override).
As for new languages: If we can mark the strings as "deprecated" / "no longer used", then translators could skip those if they want.
Indeed, we should not take them off as people using 3.2 may need them.
As I explained on slack:
This means that a user with 3.2.x (because of PHP version) is getting lang packs updates from the last version
=> we can't really cleanup all strings
Closing then.
Feel free to deprecate them however.
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2014-10-23 08:11:20 |
I really dont agree btu its a decision and I respect that. There is no
point in deprectating the strings as by the time we get to 4.0 it will be
irrelevant so I wont waste my time.
@infograf768 can you please paste your comment on slac in here. Not
everyone uses or has access to slac and we should have a single point of
truth. Plus slac isnt archived.
On 23 Oct 2014 09:11, "Thomas Hunziker" notifications@github.com wrote:
—
Reply to this email directly or view it on GitHub
#4898 (comment).
@brianteeman
thsi was a conversation with Soren when he proposed his script
I think it can be reevaluated once we have decoupled the extensions and sorted how to translate them in future. Especially the second part can take some time I guess.
@Bakual so we can add the Reevaluate for v4.0 Label here? https://github.com/joomla/joomla-cms/labels/Reevaluate%20for%20v4.0
Labels |
Added:
?
|
Done :)
3.2? End of this month.
I guess we can do some clean up, in this window… @brianteeman are you still interested?
For com_banners, the tool shows me the following constants as not used:
(11 constants) D:\xampp\htdocs\joomla3.3/administrator/language/en-GB/en-GB.com_banners.ini
COM_BANNERS_EDIT_BANNER: Edit Banner
COM_BANNERS_FIELD_CLIENT_NAME_LABEL: Client Name
COM_BANNERS_FIELD_VALUE_USECOMPONENTDEFAULT: -- Use Component Default --
COM_BANNERS_FILENAME: %1$s-banners-tracks-%2$s
COM_BANNERS_HEADING_ACTIVE_ASC: Active ascending
COM_BANNERS_HEADING_ACTIVE_DESC: Active descending
COM_BANNERS_MANAGER: Banner Manager
COM_BANNERS_METADATA: Metadata
COM_BANNERS_NO_CLIENTS_SELECTED: No clients selected
COM_BANNERS_TYPE1: Impressions
COM_BANNERS_TYPE2: Clicks
(2 constants) D:\xampp\htdocs\joomla3.3/administrator/language/en-GB/en-GB.com_banners.sys.ini
COM_BANNERS_CATEGORY_ADD_TITLE: Category Manager: Add A New Banners Category
COM_BANNERS_CATEGORY_EDIT_TITLE: Category Manager: Edit A Banners Category
(2 constants) D:\xampp\htdocs\joomla3.3/language/en-GB/en-GB.mod_banners.ini
MOD_BANNERS_FIELD_CACHETIME_DESC: The time before the module is recached
MOD_BANNERS_FIELD_CACHETIME_LABEL: Cache Time
(0 constants) D:\xampp\htdocs\joomla3.3/language/en-GB/en-GB.mod_banners.sys.ini
Some of them for sure are sure still needed.
Which ones are still used?
That is something one should check :)
but the sys,ini
COM_BANNERS_CATEGORY_ADD_TITLE: Category Manager: Add A New Banners Category
COM_BANNERS_CATEGORY_EDIT_TITLE: Category Manager: Edit A Banners Category
are used
Thanks @infograf768 I will take a look at those.
if ($lang->hasKey($component_title_key = $component . ($section ? "_$section" : '') . '_CATEGORY_' . ($isNew ? 'ADD' : 'EDIT') . '_TITLE'))
@infograf768 That one isn't used. It uses the generic title built a few lines later. com_categories doesn't even load the sys.ini file. The title would have to be in the other language file to take effect
So in fact all are not used.
The module one is a bit strange in that it now uses strings from the component. Which is a bit of a hack.
After asking PLT for the document I found out that I was searching in the old one...
See http://developer.joomla.org/news/586-joomla-development-strategy.html, section 6.1.6. We can't remove strings until 4.0.
@infograf768 That one isn't used. It uses the generic title built a few lines later. com_categories doesn't even load the sys.ini file. The title would have to be in the other language file to take effect
You are right. In this case it is the code
$title = JText::sprintf('COM_CATEGORIES_CATEGORY_' . ($isNew ? 'ADD' : 'EDIT') . '_TITLE', $this->escape(JText::_($component_section_key)));
which is used.
the sys.ini strings are used in 2.5
But... you are wrong concerning the loading of the sys.ini in 3.x. They are loaded:
**Loaded** : JROOT/administrator/language/en-GB/en-GB.com_banners.sys.ini
Ah. then they are loaded elsewhere.
Milestone |
Added: |
Milestone |
Added: |
We can remove them with Joomla 4.0.
Mark them deprecated with a comment so we remember :)
----- Ursprüngliche Nachricht -----
Von: Brian Teeman
Gesendet: 22.10.2014 23:11
An: joomla/joomla-cms
Betreff: [joomla-cms] Large number of unused language strings (#4898)
@aDaneinSpain has created a tool for searching for unused language strings. https://github.com/Jensen-Technologies/Find-Unused-Joomla-Language-Constants
I have done a quick test of one component (banners) it would appear that the tool is finding a lot of unused strings.
Anyone got any suggestions on how we should handle this. Surely it is better not to have unused strings as that just makes the job of translators harder - especially for new languages
Reply to this email directly or view it on GitHub:
#4898