Download
Yeah I felt the "it's too late" argument as well when I wrote the post.
Perhaps a good road map would be to start adding support for separate translation files in one of the upcoming 3.3.x GS versions, so some plugin authors can start testing it & start recommending this approach 2 or 3 versions later, so that all plugins created after 3.5 or so use the SoC approach.
And of course keep the current functionality for backwards compatibility, until all long-available plugins with a reasonably large user base, -and which still receive updates-, have upgraded their translation files. I realize that could be a very lenghty process, maybe until GS 4.0.
However, you could also 'force' an update by providing a function that converts the PHP file to the new data format (as the PHP can be parsed, and is always in the same format, this shouldn't be too hard) in the user's GS install. Is this Github material?
Perhaps a good road map would be to start adding support for separate translation files in one of the upcoming 3.3.x GS versions, so some plugin authors can start testing it & start recommending this approach 2 or 3 versions later, so that all plugins created after 3.5 or so use the SoC approach.
And of course keep the current functionality for backwards compatibility, until all long-available plugins with a reasonably large user base, -and which still receive updates-, have upgraded their translation files. I realize that could be a very lenghty process, maybe until GS 4.0.
However, you could also 'force' an update by providing a function that converts the PHP file to the new data format (as the PHP can be parsed, and is always in the same format, this shouldn't be too hard) in the user's GS install. Is this Github material?
