I’ve been working on a proposal for Google Summer of Code for the last three weeks. It consists on the rewriting of Gtranslator using Vala programming language. Gtranslator is the official Gnome .po file translation tool.
In spite of being the official application it’s quite buggy and it has an important lack of features if we compare it with other existent applications. In my opinion a rewriting in Vala, a much more friendly language than C with GObject, can help to increase the number of developers interested in the project.
The project mentor, Nicolás Satragno, has told me that defining a developing plan will be a great idea as a contribution to the project previous to the proposal submit. I have made this draft:
Phase 1. Analysis.
In this phase we have to define what we want that our application does. In order to do this we use two sources of knowledge, the users and the existent software.
We will ask translators, using mail lists, how the perfect tool would be for them. In addition it’s a good idea to ask them how they think that the information should be presented in the program (User Interface).
On the other hand we can analyze existing translation tools and see where they excels and where they fail and try to pick the best of each application.
Phase 2. Design.
My idea is to split the task in two parts. In the first part we will build a basic but functional application and in the second part we will create a plugin engine. To know what is part of the basic application and what’s not is part of the analysis phase but I believe that this is a good approach to the basic application:
- Open, edit and save .po files.
- Navigate thought the document (go to the next untranslated,…).
- Search and replace.
- Fuzzy translations support.
- Undo and redo.
- Translator profile support.
- Customizable keyboard shortcuts.
This two phases are strongly related so its a good idea to define the general structure of the whole system in this phase and to deal with the details in further phases.
Phase 3. Design 1st part:
In this part we will care about the details of the basic part of the application. The UI design is a very important part of this phase.
Phase 4. Programming 1st part:
We will implement the designed on the last phase. The idea is to have something that can be showed by the GUADEC people.
Phase 5. Designing 2nd part:
We will focus in designing a good plugin engine. This is a very important part of the project. We need to provide a powerful but easy to use API to our plugins developers. Define some basic plugins structures for plugins would be a good idea.
Phase 6. Programming 2nd part:
Programming the second part.
Phase 7. Documentation.
It’s important that documentation goes together with all phases of the project. The created diagrams and explanations about what every class means and is useful for, is a very important part of the project. In this very last phase we will finish the documentation of the code that is not documented yet. It’s important to make a special focus in the Plugin engine API. It would be a great idea to provide examples of plugins in order to help people to create their own ones.
There are some projects that can help during this process Doxygen(I dont know if it has Vala language support) and Valadoc may be good options.
I expect some kind of feedback so please don’t hesitate and post a comment with your thoughts!! 😀
EDIT 1: I modify the documentation phase to explain that the documentation must be transversal, it means go together with the other phases. However I keep this phase to emphasize the importance of this part of the project and because I believe that is a good idea to write some examples of the Plugin API working.
EDIT 2: I’ve change the title. As Yaron says in the comments, the project has more aspects of a redesigning than rewriting aspects.