The Future of Languages in GetSimple

[mvlcek]

I want to centralize the discussions we are having in various topics about how to handle languages and what we envision of the future in regards to GetSimple.

My vision of GetSimple is like that:

1. In the admin back-end I can see which languages are installed for GetSimple itself and for each plugin .
   
2. For GetSimple itself and for each plugin I can click on a link "More languages" to see a list of available languages, select some, click Download and they are automatically downloaded and placed in the correct directory.
   
3. I can view the translation texts of a language for GetSimple itself or a plugin and change them or create a new language
   
4. I can upload the changed or newly created language to Extend
   
5. Any visitor can see which languages are available for a specific plugin or GetSimple.
   

The current status for above vision is:

1. available only for GetSimple
   
2. not available
   
3. available with the Translate plugin
   
4. not available
   
5. available only for GetSimple
   

This vision requires

• a standard to handle languages within plugins - this is available here
  
• changes in Extend/Extend API (save languages for plugins, identify plugins by name, provide the language information by some web service)
  
• changes in GetSimple ("more languages"-link, download functionality), however, this could also be handled by a plugin (though not so nicely integrated).
  

[Connie]

I fully support this "ToDo" and I would add one (two?) points:

- Plugins are written according to the language standard,
- not-compatible plugins (which do output text) will be categorized as "non-iL8n"-plugin

[ccagle8]

hmm... well thought out, but im not sure i want it to be this full featured right off the bat. Right now these are the baby steps I am going to take with 3.1:

• 1. Get the auto notification working when GS needs updating. (javascript reading the API and alerting with this)
  
• 2. Reuse that same technology to check for plugin updates. There will probably have to be some Extend API changes made to handle this - but I will cross that bridge when we get there.
  
• 3. Get a version of mvlcek's translation plugin working on get-simple.info as a signed in feature inside the Extend administration panel.
  

#3 will not work as a couple people have suggested before. It will not limit all users to only creating one German file, or one Polish file, etc. If there are 4 different variations of the German language file uploaded into Extend - then so be it. That's what the rating system is for and eventually a front runner will emerge as the favorite. I'm not going to be restrictive in that regard.

Same exact thing with the plugin language files. It will be up to the plugin developer to add different lang files to their plugins. I am not going to create a separate system where people can update someone else's plugin with their new language file. If they want their language file included in that plugin's download - email it to the plugin creator or post it on the forums.

The suggestion to download a GS language file from within the console seems like an interesting one, but I will deal with that once the 3 above points have been taken care of.

I am going to apologize right now to those who think I am not catering enough to the i18n crowd, but in reality I am just trying to weigh the ROI on some of these changes as well as the general need for it. While I know GS has a huge international crowd - i feel like there are a lot of other things that need attention rather than dedicating the time needed to do everything that mvlcek suggested above. Like i said - all are good ideas - i just don't know if or where they are going to fit into the current GS ecosystem.

[Tyblitz]

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

[shawn_a]

I agree with most arguments but it's too late to change now. There was no such thing as json or yaml when it was written afaik. Also all other formats need to be parsed. Parsers are typically slower that native objects this was especially true in early php 4 and 5

Propose a change .

I plan on moving to data formats in the future for stuff like this as well as cache files and confit files like menu data.

[Tyblitz]

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?

[shawn_a]

Yeah that would be easy or a shim lang file with a a single line of code that just loads the json file into the $i18n global