Define Language String Deprecation

[nibra]

Over time, the language files grow and grow. Some (core) extensions redefine language strings that already exist globally.

We need a mechanism to deprecate language strings (and suggest alternatives), as we have for classes and methods, so language strings can be removed safely.

This is related to issue #67 and PR #80.

[Bakual]

For translation tools like Crowdin, it's best to add a comment with the deprecation notice behind the string on the same line. This way it will show up in those tools as "context" information.

[nibra]

So
COM_USERS_OR="or" ; @deprecated 4.0 Use J_OR instead
would work?

[brianteeman]

for crowdin yes - probably not on other platforms or for manual translators

On 2 June 2016 at 15:59, Niels Braczek notifications@github.com wrote:

So
COM_USERS_OR="or" ; @deprecated Use J_OR instead
would work?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#94 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABPH8RJB0AIqlZBmac4D5zB8DvHjuZkeks5qHu_PgaJpZM4Isnih
.

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

[nibra]

Comments should work for manual translation as well. What other platforms do we need to consider?

[brianteeman]

You would think so but they will just end up translating the comment. Seen too many existing translations sadly. The real issue is should we even be deprecating them at all. I still believe if it's not being used it should be removed and haven't heard a good argument to keep them.

[nibra]

How do you know if it is used? Think of a 3PD module for com_users using the component's language file.

[brianteeman]

They should be using their own language strings. All deprecating before removing will do is give you the opportunity to say "I told you so" it won't notify them its deprecated or stop them following bad practice (Obviously a jglobal string is different)

[nibra]

Notification would be possible, if JHtml::_() would check the state (in debug mode).

[brianteeman]

That assumes the developer who was too lazy to create their own strings spent the time to check. History suggests they are not.

[nibra]

George Wilson mentioned on Twitter, that the Unused Language String Locator doesn't work for all the strings that are put together through string concat.

A special test suite could make sure, that no used string gets removed.

[brianteeman]

Yeah any script will fail on those and produce false positives

[Bakual]

for crowdin yes - probably not on other platforms or for manual translators

Afaik it also works this way for Transifex, but haven't tested it. For manual translators it would work as well for the more savvy translators 😄 . com_localise would have to be adjusted as it uses a different approach (I think the comment is on line before).

[mbabker]

Notification would be possible, if JHtml::_() would check the state (in debug mode).

JLanguage doesn't have a parser to read INI comments (we're basically doing parse_ini_string(file_get_contents($filename)) when parsing the files). So you'd need a parser to extract comments and be able to match those comments to a line, and you'd probably need to account for both commenting styles:

; @deprecated 4.0
JSTRING_WHATEVER="String Whatever"
JSTRING_WHY="String Why" ; @deprecated 4.0

JLanguage already has a debug mode attached to it so if such a parser is created you should just attach it there. Also, as done in the Framework, the debug parser should be extracted to a standalone method making it easier to run these checks.

[nibra]

Ole Bang Ottosen pointed out, that this has been discussed in depth at joomla/joomla-cms#9932.

[brianteeman]

Yes it has been discussed several times but never with any real conclusion

[nibra]

Well, I guess it is up to the PLT to make a decision.

[nibra]

Subject sent to PLT for decison. Closing.