In my cleanup of the Installer library, I've possibly made 20-25 strings unused so we should have some way of flagging this.

@daneinspane wrote a script https://github.com/Jensen-Technologies/Find-Unused-Joomla-Language-Constants that identifies these unused strings (it might miss some but it doesn't find false positives afaict)

Then its just a case of taking the results and adding the comment. Happy to do that if its a good idea.

Just a suggestion - rather than adding a comment above each unused key/string, I would add this once at the bottom of the language file: These strings are not used in the latest version of Joomla and kept for B/C. Do not translate these strings. If you still need one of the lines, just uncomment it by removing the ; in front.
;TPL_BEEZ3_YOUR_SITE_DESCRIPTION="Your site description"
;whatever...
;whatever...

BTW- There also is a tool for discovering missing strings: http://extensions.joomla.org/extensions/extension/miscellaneous/development/language-file-tool
(I've used it a few times long time ago for converting J1.x language files to J1.6. Worked well as far as I remember)

We can not comment out the unused strings for the same reason that we
cannot delete them. Someone might be using them elsewhere.

On 21 January 2015 at 20:11, Gitjk notifications@github.com wrote:

Just a suggestion - rather than adding a comment above each unused
key/string, I would add this once at the bottom of the language file: These
strings are not used in the latest version of Joomla and kept for B/C. Do
not translate these strings. If you still need one of the lines, just
uncomment it by removing the ; in front.
;TPL_BEEZ3_YOUR_SITE_DESCRIPTION="Your site description"
;whatever...
;whatever...

BTW- There also is a tool for discovering missing strings:
http://extensions.joomla.org/extensions/extension/miscellaneous/development/language-file-tool
(I've used it a few times long time ago for converting J1.x language files

to J1.6. Worked well as far as I remember)

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/5856
http://issues.joomla.org/tracker/joomla-cms/5856.

—
Reply to this email directly or view it on GitHub
#5856 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Also tools like Transifex will show a comment which is located just above a line. Grouping them together would not work for those afaik.

"Also tools like Transifex will show a comment which is located just above a line."

Just checked this in a Transifex project where I'm a translation manager (5000+ strings). The current version of Transifex doesn't show comments at all while in translation mode. Commented keys/strings show up as normal translatable strings. My experience from the past is that the majority of translators ignore or overlook it anyway. We even get many 'useless translations' for some files, even though there is a clear statement at the beginning of the language file that it is only relevant for a certain country (some payment plugins for example).

So imho grouping uncommented but outdated keys/strings into a block at the bottom wouldn't hurt Transifex translators. The reason I prefer that is that I don't use Transifex for my own translations. I usually load the source language file and the translation into Notepad++ side by side after sorting them alphabetically first and then use the 'Compare' feature to spot missing translations. Many comments in the file would result in having to sort the file alphabetically in small chunks in order to keep the comments in their correct position.

However, I'm currently not planning to get involved in Joomla core translations. So I'm not going to fight (verbally) against Brian's idea :-)

I have no problem at all with your idea - let me just confirm you are
proposing adding a new section at the bottom of the language file that
starts with the deprecated/unused comment and then all deprecated/unused
strings get placed there.

"...let me just confirm you are proposing adding a new section at the bottom of the language file that starts with the deprecated/unused comment and then all deprecated/unused strings get placed there."

Yes. The two advantages imho are:

• more easy to sort the language files (I like language alphabetically sorted language files, because they are more easy to compare and it makes it easier to spot missing or duplicate lines)
• more easy to locate the unused keys/strings (compared to for example 25 unused strings scattered in a long language file)

Thats fine with me - just wanted to confirm

Now I just need someone to say its OK to do it and then I will process the
files

On 22 January 2015 at 09:18, Gitjk notifications@github.com wrote:

"...let me just confirm you are proposing adding a new section at the
bottom of the language file that starts with the deprecated/unused comment
and then all deprecated/unused strings get placed there."

Yes. The two advantages imho are:

• more easy to sort the language files (I like language alphabetically sorted language files, because they are more easy to compare and it makes it easier to spot missing or duplicate lines)
• more easy to locate the unused keys/strings (compared to for example 25 unused strings scattered in a long language file)

—
Reply to this email directly or view it on GitHub
#5856 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

If a string can be used for B/C reasons, it should be translated imho.
If it is not used at all (and so specific that it can't be used by third party), it should just be deleted.
One should know that adding commented lines and regrouping "deprecated" strings at the bottom of the file may make it hard for Translators using .diff(s).

Careful with scripts like https://github.com/Jensen-Technologies/Find-Unused-Joomla-Language-Constants

1. they fail with combined constants
2. they fail on plural strings

They fail = they DO find false positives.

As we are not using them (and no one should be) a TT can chose to
translate or not. But we are at least able to see easily which they are so
they can be removed in the future.

The script has been updated to not report the plurals etc. So as I said it
may not be 100% accurate but it will not have false positives
On 22 Jan 2015 10:58, "infograf768" notifications@github.com wrote:

If a string can be used for B/C reasons, it should be translated imho.
If it is not used at all (and so specific that it can't be used by third
party), it should just be deleted.
One should know that adding commented lines and regrouping "deprecated"
strings at the bottom of the file may make it hard for Translators using
.diff(s).

Careful with scripts like
https://github.com/Jensen-Technologies/Find-Unused-Joomla-Language-Constants

1. they fail with combined constants
2. they fail on plural strings

They fail = they DO find false positives.

—
Reply to this email directly or view it on GitHub
#5856 (comment).

As we are not using them (and no one should be)

Wrong: the reason of B/C is that some 3rd party COULD use them genuinely

It may sound stupid, but here is my thought:
In every original file e.g. en-GB.com_ajax.ini keep ONLY the currently used strings
Add en-GB.com_ajax.deprecated.ini and put all the redundant/deprecated strings
Change the method to check if .deprecated file exists, and if so loaded as well
This way we have a clear separation between current and deprecated.
Of course this may not be an easy change in TT workflow...

Of course this may not be an easy change in TT workflow...

This would add almost as many "deprecated" files as present inis... + all the changes in the present inis...

Performance wise I think this will not be a problem, as long as cache is set.
Now about the effort that is needed to make this happen, personally speaking and without being member of any TT, it shouldn’t be more or less work than adding comments above a deprecated string. All that is required with this approach is to separate (e.g. copy-paste) the deprecated strings.
I think that whatever solution is selected here, some initial hard work should be expected for TT

I don't think it makes sense to have yet another file with language strings. We would end up loading multiple files for no reason except that some 3rd party may use it.
There is no gain over just having them in our current files as is.

I also don't see a big improvement by removing unused language strings. It will make it a bit simpler for new translations. But in the end it's probably negligible compared to the amount of strings we have that are still used

Keep it as simple and easy as possible. Either leave the strings just there or deprecate them if you want by adding a comment.
Personally I would jiust clean the files up before we release the next major. At that time we can remove them without issues.

Closing as there will never be a sensible approach to this that can accommodate the antiquated diffs that translation teams are given

@infograf768 Just being curious, what you mean by saying:

Wrong: the reason of B/C is that some 3rd party COULD use them genuinely

This is a valid point only for the core language files of joomla. I don’t think that any sane dev will ever load the com_content language file just to use some strings in their com_custom.
Same goes for modules, plugins, templates, so I think this is the case only for the en-GB.ini and the lib_ files.
Therefore I think we CAN actually clean and remove the deprecated from all com_ mod_ plq_ and tpl files without causing any trouble at all!

Am I missing something here?

You would be surprised. After 3.2 was released, there were issues from extension developers who were using com_config because that component was refactored and files moved around in the filesystem.

I would actually expect extension devs to use language files from com_content. Especially if they are having an article related extension.
The library files are available quite often as well and can be used by extension developers just fine.