Good question.
I can’t think of anything you should keep in mind as such. I will do my best to prevent surprises for 1.x users. The changes will all be for the better, and the interface will be familiar. I will also ensure that any new version is available as a developer release long before automatic updates switch people over without their realising.
Work on 2.x has not begun yet, but here’s a summary of the biggest things on my mind, based on the most common questions/problems on this forum.
Compatibility:
Detection and management of text domains (and their relationship to plugins and themes) is paramount. Themes and plugins may use or share many different domains, sometimes not under their own folder. The current model can’t really cope with the reality that you’ll find in the pages of this forum.
User journeys:
The plugin was originally built for developers localising their own work. However, I was not prepared for the number of (often non-technical) translators localising other people’s work. This seems to have become the primary user base and is where the majority of the complaints come from.
It is likely that there will be two workflow modes for each package: “Author” for preparing your own package for translation (extracting strings etc..). And “Translator” which would insulate the inner workings of a package from someone who is not the author.
Collaboration:
I have since day one intended to link the plugin to the main Loco service via the API. This will open up collaboration as you’ll be able to pull translations down from a common repository. This will be entirely optional; a fully local/offline workflow will always remain.
Diagnostics:
In many cases it is impossible for me to help the people who get stuck. I get dozens of emails every week that simply say “Doesn’t work, help!”. The new system needs a step by step diagnostic tool to troubleshoot problems and establish whether the problem is with the theme or the server, etc..
There’s more on my list, but these are the big ones.
