Localization files in /languages folder

Could you please add localization files to /language folder inside your plugin?
Creation of language folder is a nice style of WP app architecture.
This way localization files will be automatically used upon switching to different locale.

Subscribe2 supports placing the language files in the root of the plugin folder, in a languages sub-folder and hopefully, once WordPress allows, in the core languages folder.

If you are suggesting I add localisation files to the release archive, well I’d love to do that but I get the translation files donated to me sporadically and some of the version I have are very old indeed. Furthermore, I don’t feel it’s right to push a code release that simply contains a new translation file when the core code remains identical.

> I get the translation files donated to me sporadically and some of the version I have are very old indeed.
That is not a big problem compared to the fact, that users currently are not getting ANY translations! Incomplete translation motivates users to update them!
That is the way most plugins I use are working!

> I don’t feel it’s right to push a code release that simply contains a new translation file when the core code remains identical.
You don’t need to do that. Push new localization updates with new version of software.

> Access to all the i18n files that have been submitted to me are available here
I was lucky to find this link as I wanted to start translation from zero!

You should definitely include all translations to release!
Besides, moving to GIThub will also be good for development of the project!

> I don’t feel it’s right to push a code release that simply contains a new translation file when the core code remains identical.
Besides, you can update release with lang. files without making a new version of it!

Maybe I’m missing something but I don’t see how your proposal will help end users or me.

I should include all translations with the code? Even one I know to be broken? That’s just going to result in more support requests saying the translations don’t work.

I am trying to preserve strings as far as possible between versions but sometimes even point releases contains changed or new strings so adding translations to new code releases is probably going to leave some strings untranslated.

Clearly you know about *.mo files and the principles of i18n but most people want to install the code, turn it on and have it work without doing anything further.

> I should include all translations with the code?
Yes!
> Even one I know to be broken?
What does it mean “broken”? If it results in functional problem, then no. If some string are not translated then it is not a big deal. Users might translate it later.
> so adding translations to new code releases is probably going to leave some strings untranslated.
No a big deal. Users who need translation will translate!
> Clearly you know about *.mo files and the principles of i18n but most people want to install the code, turn it on and have it work without doing anything further.
That is what software needed for!
See examples how users contribute translation when they need it:https://github.com/easydigitaldownloads/Easy-Digital-Downloads/commits/master/languageshttps://github.com/kregwallace/speakup-email-petitions/commits/master/languages

And many more! That is the way it is working right now!

> That’s just going to result in more support requests saying the translations don’t work.
Answer to these request such a way: “I would be glad to include updated translation if you will send me on!”. Do the programming stuff and leave translations to users!

> What are the benefits (and disadvantages) of moving to git from subversion?
I gave you links to Github just to show examples of localization process.

Advantage of GitHub over other code hosters is it social attraction for users. GitHub UI is very user friendly.
I don’t want to start holy war. Just in my opinion GitHub is mainstream currently…
I personally don’t know even how to contribute to SVN based projects. Somehow it is inconvenient as it lacks UI simplicity…

I guess you use the tools you are used to. I’ve always used subversion as that is what WordPress used when I started looking after the Subscribe2 code 6 or 7 years ago.

I saw the GitHub links but as I don’t use GitHub and am not failiar with it it didn’t mean much to me. So, can people just commit changes to the code? Is that how it becomes ‘social’? If that can commit changes for languages how do I retain control over the core code?

Wow! Lucky me i found this thread!
I was starting translate in italian the plugin when i stumble upon a reference to translation, so i came here and discoered that there are the updated italian translations!
You should tell people in the plugin’s description pager that you (great) plugin support, and has, translations!!!