Catching up from the blog post that introduced Pontoon, I’d like to present the project in a little more detail and the vision for a near future.
Clients
As stated previously, Pontoon 0.1 introduces two types of clients – web client and jetpack client. Both share majority of code base (Pontoon, jQuery, jQueryDomec and heavily modified editableText plugin), but because of the limitations of jetpack prototype I had to merge them into one JS file.
user experience
For user interface of Pontoon 0.2 I’d like to focus on a few key aspects that may make Pontoon a tool ready to use in work environment:
- Introduce identification system that will sign contributions made by a given user. We may use Verbatim accounts for now.
- Figure out a way to recognize the state of localization and allow for continuing localization.
- Add ability to view/edit entity in a source view. (much like wordpress’s HTML view)
- Fix some common cases like entity with a single anchor should treat the anchor as an entity, not its parent
- Improve UI to look nicer and inform user on the outcome of his actions.
With those six improvements (including two top ones which are major), Pontoon will become, in my opinion, ready for real life use and we may offer it for one of the upcoming small websites for those brave souls who would like to test it.
code base
On the code base front, I will definitely want to clean up the sources, which will be easier when jetpack client get updated to new jetpack architecture. editableText plugin will require a cleanup and will be extended to allow source view, so it may make sense to fork it as a separate project, while other classes should be refactored and site-dependent code should be moved away from libraries. Also, CSS inclusions should be merged into libraries.
One thing I’d like to see soon is a third type of a client – one that may be embedded into any website so that the website author can turn on and off the “localization” mode.
Server
Pontoon server will require adaptation to the client side changes, like ability to identify/authenticate users, and then two new things should be possible with the data received from a client. First, server should be able to add translations as suggestions in Verbatim. This way users will be able to suggest translations, leaving up to the registered localizers what to do with it. This workflow is an intended one for Pontoon.
Second thing, is that we should be able to generate a pure, localized HTML file out of a source one and translation list. This way we will be able to localize things like SUMO documents or plain HTML sites that do not use Gettext or even PHP.
Hooks
Hooks will go through a major rewrite, because I want to test the concept of providing an external meta file with information like lists of entities for the client to read. Such meta information is the most natural way to also add ability to pick up localization from a midpoint. The issue here is that of course this will not help the client with localization of websites that do not use pontoon hooks.
It would be also great to add Django hooks, since so many websites this days are migrating to django, and it would also allow us to test how cross-linguistic the hook system is.
Summary
This is my plan for a short term, and I’ll try to get as many of the features described above into Pontoon 0.2 as possible. I prepared a wiki article describing the plan, and I’m open to feedback, ideas, and of course, contribution. 🙂