My Outreachy internship is already more than halfway through.
After being somewhat lost in the beginning, I managed to grasp the basic concepts of Gtk+ and the way the applications are written. I have only scratched the surface, but I started to have a lot of fun while coding and grew very fond of my project(s) which I now can't imagine leaving.
Anyhow, in this post, I would like to present my project(s)/community and describe in more detail what I am working on.
To refresh your memory: I am designing and implementing an (initial) integration of Gtranslator and Damned Lies. They are both applications (the former a desktop app, the latter a web app) for translators of the GNOME project.
About Gtranslator
Gtranslator is a GetText PO file editor for GNOME. Besides basic editing, it supports message ordering, searching and replacing text, adding comments to translations and multiple plural forms. It also allows to set up multiple translator profiles in which a user specifies their details and the language they are translating into. Based on these, Gtranslator can then generate headers of the PO file, and also checks for mismatch of the file's and user profile's plural forms.
About Damned Lies
Damned Lies (DL) is a web app for managing localisation of the GNOME project. It is organized around languages and teams with information about their coordinator, members, RSS feed and (other) related links. It also contains a list of modules (these are apps, libraries, and other components of the GNOME environment) and, on their respective pages, basic information about the module as well as maintainers' contacts, branches and—the most relevant part for us—a link to detailed page for every language, which includes information about the module translation state, history of actions, links to POT and PO files and statistics of translated strings (overall percentage, number of completed, missing and fuzzy translations).
The key feature is the interface for the flow of the translation process. Translators are able to download the corresponding PO file, then edit it to add or modify translations, and afterwards upload the new version. Changes are then merged with existing translations, i.e. committed to the module repository.
Integration or This is where I come in
Currently, the workflow of translators (in those teams that use Damned Lies to organize and upload their files) is as follows:
- download the PO file from Damned Lies
- open it in the editor (Gtranslator)
- edit and save the file
- upload it to Damned Lies
The first goal is to eliminate the initial redundant steps: saving and opening the file manually. The idea is to load the translation file directly in Gtranslator, thus skipping steps 1 and 2. In order to carry this out, we need the path to the file; and to uniquely specify the file, we need to know
- which module and
- which domain (e.g. 'UI translations' or 'User Guide') we are translating
- into which language and
- in which branch (this can be, for example,
masteror something likegnome-3-30).
In addition to the features mentioned before, Damned Lies also provides an (older) API to get lists of modules, teams, languages and releases. Based on what we have just listed, we need additional information to be able to define the file we require. The Damned Lies team has already prepared a new API with new and updated endpoints which return the data we need, so we are good to go!
For now, I have prepared the widgets (dropdowns) with values from DL API; after a user has selected a value from all (four), an additional call to API is executed to get the path to the file the user wants to load. Lastly, the file is loaded into Gtranslator.
Further integration and improvements
Both Damned Lies as a whole and the translation workflow specifically are much more expansive and there are numerous other possibilities on how to integrate them with Gtranslator. Looking at the steps above, the next logical improvement would be uploading the updated file directly from Gtranslator instead of uploading it manually through the web app.
Since a user has to be logged in to contribute to a PO file, a login widget would have to be added to Gtranslator to handle the authentication. When we would have that, we could also take into account that translators are usually part of one team, so we could, for example, omit manually selecting the language.
This is a story for another time, though.