joomla-x/joomla-pythagoras

Define Language String Deprecation

Closed this issue · 17 comments

nibra commented

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.

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 commented

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

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 commented

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

nibra commented

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

nibra commented

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

nibra commented

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.

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).

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 commented

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

nibra commented

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

nibra commented

Subject sent to PLT for decison. Closing.