Sorry for reviving an old topic, but I felt like it wasn't appropriate to post this in the Translate plugin topic, which referred me here. Regarding the 'standard to handle plugin languages': when I started developing my first plugin (GS Custom Settings), how to handle languages was one GS standard I just couldn't agree with.
The current standard (see http://get-simple.info/wiki/plugins:i18n ) actually demands that language data-files (there, I said it) be written in PHP, the processor. You must feel something is not right. From a Separation of concerns point of view, this makes no sense. All major CMS'es use separate language files written in a data format (Drupal uses .po, Joomla uses .xml, WP allows conversion from .po).
That's the reason I opted for JSON. It takes two simple calls, 1) to
The current standard also makes no sense for performance and security.
-
- Code in
There, that's my crusade against mixing of concerns
The current standard (see http://get-simple.info/wiki/plugins:i18n ) actually demands that language data-files (there, I said it) be written in PHP, the processor. You must feel something is not right. From a Separation of concerns point of view, this makes no sense. All major CMS'es use separate language files written in a data format (Drupal uses .po, Joomla uses .xml, WP allows conversion from .po).
That's the reason I opted for JSON. It takes two simple calls, 1) to
file_get_contents and 2) to json_decode. Although no translation utility exists, it would be dead simple to build one.The current standard also makes no sense for performance and security.
-
include is slower than file_get_contents, because 1) the PHP needs to be parsed, and 2) memory isn't freed up (see https://www.drupal.org/node/1198924).- Code in
include is parsed, and may execute (however unlikely) malicious code.There, that's my crusade against mixing of concerns