Hey guys!
I originally wrote this report as a post for my blog. http://vinicius.depizzol.com.br/blog/2011/05/gsoc-weekly-update-1/
Here it goes:
Google Summer of Code started last Monday. Before that we were officially in Community Bonding period, but since it seems I’m already part of the GNOME Project for a while, I started to work on it earlier. University is still eating most of my time by now, but I got nice improvements hacking at night.
So, this is my first weekly report with all the things that I’ve been doing for the last two weeks :).
To start I decided to take on the first task (of a total of five): I’m currently working on WPPO, a WordPress plugin to make the GNOME.org website translatable using the existing GNOME infrastructure for translation, based on GetText.
Before starting GSoC, I already had 449 lines of code of this WPPO plugin. It had the primitive basics of how it should replace the posts with the translated text, and how the translated text should be stored in a auxiliary table. Nothing more than that. Oh, in fact there was as well a TODO list :).
On May 15 I started working on cleaning the source code. From this cleaning to writing code, that’s what I did:
Separate PO files for static and dynamic content
To translate the website, the plugin generates a PO file with the strings to be translated. Since we can’t have freeze periods in the website content (and since the website editors will never stop adding news as they should), some conversation on i18n-coordination-list was interesting to agree that pages (and other static elements) should have separated PO files from news (and other posts that are updated all the time). This way translators know what are their priorities on translating the website.
Automatically check for changes
Now the plugin can check for changes when new PO files are sent to the website git repository. It will automatically parse the files and transform the strings in real translated pages. Also, a full log of received PO files is kept in a database table to eventually be displayed in the administration area.
Store all the available languages
The primitive WPPO plugin stored the translated content, but there was no fast way to discover what were the available languages, and how much of each language was translated. Now, I putted together a parser that scans every updated PO file, and fills a table in the database with statistics of the translation. This way, languages can be enabled or disabled based on how much they are translatable.
Implement search for translated website version
While the plugin was able to display all the content in the translated version, when some search was done, the default WordPress search engine would search only for terms in the original English posts. Now the search is correctly looking for results in the current language.
And other small things
- Restructured directory structure of PO files to fit with GNOME defaults
- Better error handling
- Redone the way the plugin identifies browser’s HTTP_ACCEPT_LANGUAGE to automatically select an available language if none is forced
- List recent page/post changes in WordPress administration area
This is how the same page in WordPress is looking in different languages. WPPO repository is located right now on github.
⁂
So, what’s next? Main things missing for WPPO are URL handling, to make addresses work like “/en/about” and “/es/acerca” (right now I’m accessing translated pages with a “?lang=es” in the URL); and a complete administration area, where website maintainers will be able to push changes to translators (by choosing when to regenerate the POT file), enabling/disabling languages and keeping track of page changes and language updates.
During this weekend I’ll try to fully understand the way WordPress handles URLs, and at least have the “push changes” part of admin done. But these are emotions for the next summary :).
See you!