It’s been a long time since Google Summer of Code ended, and I still haven’t posted anything since August. I know I am very late (it’s hard to believe that 2011 is already coming to a close — Desktop Summit seemed like it was yesterday!), but besides being extremely busy with my regular job and lots of others little projects and my final paper, I don’t have an excuse.

I got 5 big tasks in my GSoC TODO list. I knew it was a lot right from the beginning, but I didn’t want to worry about the short timetable I would get in the program. I already was contributing in the web team and keeping working on it after GSoC wouldn’t be an issue. From May to August I got intense days in my university (considering it was winter here) and this delayed me a lot. I need to thank to Federico again for his support as my mentor .

As for the 5 tasks I got, I only didn’t work in one (which was about reorganizing the developer area). Two of the tasks are ready to be deployed (the one to add support for translating the GNOME website and the other to have a new applications area), and the other two (the community website — which I must say it could be an entire Summer of Code project — and the template update for subdomains) are half-done.

I’m about to give more details about my nearly finished tasks and on deploying them in another post soon (like the new Damned Lies template above which is completely out of context in this post) basically because I’m catching a bigger fish right now. For the past month I’ve been working in my final paper for university. I’m finishing my bachelors in Design and this is consuming all my free time as I need to get it done in the beginning of December. The good part is that it is an analysis of the information architecture for the GNOME website!

And as part of my final paper study, I’m about to publish a user survey which might give me some data regarding how people use GNOME website and its services. Stay tuned!

Meanwhile, please be patient . Thank you!

Disclosure: my old Dell laptop got the flu a few weeks ago, had some problems to start up, went really bad this weekend and officially died this morning. I’m really in a bad situation right now until I get the new laptop I just bought after this incident (which luckily is going to arrive on Friday 5th at Berlin).

⁂

Getting a custom BuddyPress theme is hard. That’s probably the reason there aren’t many different cool themes laying around. I’ve been spending some real time on this to get a proper theme without ugly hacks and I got some serious cool results. It’s taking much more time than I originally planned, but there are a lot of things done right now.

(unlike the last report, none of the following screenshots are mockups — they’re all working alive things)

I spent the week #9 and part of the week #10 hacking the BuddyPress theme. The members area is completely done. In this part, there is the user profile, user activities, profile edit form, change avatar and settings.

(in the user activities, people can comment on activities done and mark as favorite)

Also, I got the full implementation of geolocation support for users. People can view the position of the user in his/her profile page, and each user can edit it own position in the edit form. The “Location” field is not attached to a specific database nor with the map position, so the user can choose how accurate he’ll be located.

I got as well the layout for the list of members. The first page of this list already contains a map with all the members laying around the globe, which is quite nice (it even considers cache when doing such a hard database request).

⁂

This week #11 is going to be short. I’m without a proper computer to hack and I’ll be from Wednesday 11 AM to Thursday 19 PM between planes and airports in order to get in Berlin (yes, I’m going to Desktop Summit!).

The list of next tasks looks something like the following:

• Layout for Groups and Activities
• Home page with statistics and the interactive map
• Login and Register forms
• Integration with GNOME Services / Blip Monitor

(I’d like to be already working on integrating GNOME services with user activities, but it seems the development of pages are just as important as the integration)

⁂

In the last post Andre and John commented about Shaun‘s Blip Monitor. I didn’t know about it, and I really liked the idea of using it to avoid code rework regarding the integration of user activities with the GNOME services. I got the source code but didn’t have much time to understand it. Hopefully I can talk to some GNOME hackers personally in a few days to discover where to start properly

See you in Berlin!

(no, I didn’t loose any source code of my gsoc because of my laptop death)

It’s been a long week working with BuddyPress and the tools around it. As I wrote in some previous posts, my 3^rd task is to create a community system that integrates the people involved in GNOME and shows what is being done in the project in real time.

I’m using BuddyPress — a full featured WordPress-based social network system that supports members, activities and groups — to handle all the things together.

Activities and profiles

To do so, I’m making the activities timeline of each user be a big stream of things done in GNOME services. For example, every time I commit something to a GNOME git repository, an item will be added to my profile telling about this commit. The same will happen with bugs, translations etc.

Each user will have a profile with the activities done in the project, some bio text with fields like “where I live” and “where I am right now”, his/her friends and groups.

Keeping the geolocation of each user will allow us to know if lapo is real where in the world are the GNOME participants, instead of using some archaic method. Also, we aim to have in the home page a featured map with balloons popping up in real time showing what is happening in the community right now.

Groups

Once the main GNOME.org website will be available in several languages, there is no point keeping subdomains like br.gnome.org with outdated translated content. With groups in the Community website, users will be able to interact each other and post news.

What’s the status of this?

Since last week I’ve been working hard on planning the features of the Community website, along with the BuddyPress theme. The theme itself is keeping me busier than I though, and I’m going to spend more days on it until I get something decent.

I also spent a lot of time studying BuddyPress and some GNOME systems like BugZilla and Damned Lies in order to know how to get fetch generated data.

How to get activity data

In order to fill the profiles with the activities done in GNOME systems, we’ll need specific code for each system.

For BugZilla, there is XMLRPC communication support. I need to study it a bit deeper, but if I’m not wrong it’s not hard to get all the recent actions so I can execute a script getting it regularly.

For Damned Lies, I can get a feed of actions (like this), but only if I specify a language or a module. Hacking it to provide a global feed of actions (and informing the user email in the feed) would solve the case (Stéphane Raimbault, I’m looking at you ).

For git, I can use server-side post-receive hook or parse cgit feeds (like this). Still need to study this.

There are some not-very-clear parts, like how to handle received activity of users without registered accounts to the Community website. Maybe we should just ignore it .

⁂

For this week I’m planning to have something really done regarding the theme and get the geolocation support for users functional.

I’d love to hear some feedback regarding this. Thanks!

It’s been long two weeks since my last report. While this does sound like a bad thing, there were two great happenings responsible for it.

1. Went to FISL — I couldn’t miss one of the biggest free software conferences in the world. This year the event had almost 7000 participants, and it was great to meet so many great people at cold Porto Alegre.
2. Final tests of the last semester of University are over — I had plenty of work for most of my classes during the past 3 weeks, and last week in special I had what the university calls “Semester tests”, which was a week with a test each day with all the content of the semester. With all of this done, I’m really happy to say I only need to work on my post-course final paper after September to graduate .

Regarding my GSoC project, yes, I’m a bit late due to those two items. I just didn’t have time to work on it during the Semester tests week, and also didn’t do it at FISL, as opposed to what was planned in my schedule.

Still, I got some things done, as it’s listed bellow:

Polished Applications home page

To finish the Applications section, I added a new meta box in admin to allow website editors to choose which projects will appear in the “Featured” page.

Also, just commited all the code to my github account.

Planned a common layout header for subdomains in GNOME.org

While we already have a new layout for GNOME.org, the subdomains websites shouldn’t have exactly the same header structure. Having the same black bar in all GNOME websites but with completely different items in each one would create lots of confusion for users. Also, the existing header doesn’t look well with logo changes.

To accomplish this, I started working on a common layout header for subdomains in GNOME.org. This task is related with three items of my task: create the Community website, reorganize developer.gnome.org and migrate the subdomains of GNOME to use the new layout.

This is the screenshot of what I got. It’s right implemented in html/css with few resources as possible (it doesn’t require external libraries like grid systems, so it can be reused anywhere):

(the map in the screenshot is a fake demo of Leaflet, a cool map library I’m planning to use)

The idea is to use this layout as base for all subdomains in GNOME websites, as the following examples:

I already started to work in a BuddyPress theme, but as soon as I get the basics I’ll try to focus in implementing the features needed for the Community website, like geolocation of users, apply the user activities on the map and get support to update user activities based on things done inside the project.

⁂

For this week I’m planning to get a working simple version of the BuddyPress theme and start hacking on users geolocation and the home page map.

See you!

Another late summary. Same excuse. Final tests are finally about to end by the end of next week.

Among the plans of the week, my list consisted of finishing the Applications area for the GNOME website and starting on the Community site. Even with plenty of University works and tests, I managed to get all my gsoc plans in time (this summary had to wait — for a good cause ).

Things done this last week:

Application page

The core of the Applications area in the GNOME website is the content exhibition of each App. To get it right, I worked with custom posts and custom taxonomies in WordPress, and used some other tools to make things work well.

App Screenshots

Screenshots of each application are images uploaded trough the Media panel in WordPress admin, attached to the app page. Each app can have any amount of screenshots and each screenshot can have its own description. If more than three images are provided for an app, a carousel-like navigation will appear on the app page so all the screenshots can be viewed.

App content sections

The app page can contain any kind of content. In fact it works like any other wordpress page. However, there are some predefined styles and titles that optionally can be used to provide consistent information. Right now there are two parts that have an specific style: Highlights and Install. More sections can be added later.

To do so, basically the template looks for <h2> tags and parses as desired. The creation of specific content is as easy as creating the following code (I still need to make some documentation on live.gnome.org explaining all the behaviors of this for content writers):

<h2>Highlights</h2>

    <strong>Customizable Interface</strong>
    Each task requires a different environment and GIMP allows you to customize
    the view and behavior the way you like it.

    <strong>Color correction</strong>
    The included channel mixer gives you the flexibility and power to get your
    B/W photography stand out the way you need. 

<h2>Install</h2>

    <h3>Ubuntu</h3>

        Ubuntu or Debian users can simply run <code>apt-get install gimp</code>
        to get the latest stable release of GIMP.

    <h3>OpenSuse</h3>

        SUSE users can install GIMP by running <code>yast -i gimp</code> or
        <code>zypper in gimp</code>, depending on the distribution version.

    <h3>MacOS X</h3>

        The GIMP team doesn't provide official Mac binaries. You can, however, install
        GIMP 2.6 easily on the Mac using the packages provided by
        <a href="http://gimp.lisanet.de/">GIMP on OS X</a>.

        <a class="download_button" href="http://gimp.lisanet.de/Website/Download.html">Download GIMP 2.6</a>

        Running GIMP on Mac OS X requires Apple's X11 environment. It is included on the
        "Optional Installs" package on the OS X install disk.

Which will render like this:

Quick links

Bellow each app we planned to put a list of interesting links. To do such a thing in a nice way, I made a better manager of links inside WordPress admin instead of adding manual custom fields:

Application categories

I used custom taxonomies to provide category support for the apps. Content writers then have full control over it, and the website will display the menus accordingly. The list of apps also gets pagination when necessary.

News Section

Daniel suggested a news section in the app page, that gets a RSS feed from the project website. It can be very interesting for some apps, but I’d like to discuss this with others designers before implementing it. Didn’t have time for that yet.

Community website

After getting the Applications section up, running, working and rocking, I spent just some time up to now on the Community website for GNOME. I studied BuddyPress a little more, specially the theming support.

⁂

For this next week, I’m planning to have something to show regarding BuddyPress theming. See you!

Hello! This is a late summary report for my 4th week on Google Summer of Code. Default fault goes to university, which is disturbing my studies with final tests et cetera. Finally they’re ending! (first week of July is not that close, is it?)

This last week I really wanted to start and finish my second task of GSoC: Create an Applications area in the GNOME website. While I didn’t succeed with my original promise to myself, I got quite a things done (related to the 2nd task or not), which are described in the following list:

Language selector for the GNOME website template

After having all the corners polished in WPPO plugin, I integrated the default GNOME Grass WordPress theme to work together with it. As a result, when someone clicks in footer’s “Swich Language”, an underground area slides up and list all available languages, with links that convert the currently open page to the selected language.

Design the pages for Applications area

The main reason to have an Applications list in the GNOME website is to inform and recommend to end users applications that runs on top of GNOME in a nice and uncomplicated way.

To get this done I did some tests and drew those mockups (click for full size). Lots of contributions and suggestions on making those comes from #gnome-design crew, and lots more from Daniel Siegel, which pointed several interesting considerations (sorry, I didn’t spend my time redrawing the mockups with all of his points — I’m implementing them!).

Implementation of Applications area

Implementing the Applications area on top of the GNOME website requires two pieces of work: doing the html & javascript & css part (and parsing the produced content to render as desired in the template), and group the things together inside WordPress core with custom posts, custom taxonomies and the admin area editing forms.

The first part of this (the client side one) is almost ready. I took some time to study the WordPress behaviors for custom posts, and I’m just working on finishing this to have something to show up.

BuddyPress Community Zone

I installed BuddyPress on my machine to see what I’ll have to do for my task #3 (Create a new area on GNOME website that will focus on Community), and spend a lot of time studying the platform.

BuddyPress is mostly likely the tool I think I’ll use to create this. It already supports user activities (to be able to log all the actions we want, like bug reports, translations, commits and wiki edits) and creation of groups (for local communities). Also, BuddyPress runs on top of WordPress, which makes code pretty much integrated with the existing way of doing things.

⁂

During this week #5 I’m planning to fully finish the applications area by implementing all the missing parts, providing at least one application with real content as sample, and start next task by hacking on BuddyPress for real. See you!

Third weekly report. It is great to say the plugin I’ve been working on to integrate GNOME website to the translation infrastructure is done. During this last week I’ve been doing lots and lots of tests and fixes, and worked on all the missing improvements for the plugin. Here’s the detailed list:

Improvements in admin area

In the last report I told about having all main actions of the admin area done. Now the plugin has a nice table of recent activities of changes in the website, allowing to website editors keep track of what is being done and specially when to send changes to translators (or, in other words, when to regenerate the POT file so Damned Lies can get the changes).

Also, I did a full area for managing the languages, allowing to add/remove and list all the available ones with statistics of how much is translated, and also inform (when hovering in those red asterisks) when the theme of the website and the WordPress instance itself is not available in each of the languages. As a plus, when adding a new language, WPPO will automatically try to download the translation files of WordPress for the desired language.

Tweaks in URL

Now I’m safe to say all the links, including the manual ones that were inserted in the middle of the pages and posts will have proper addresses when using WPPO, with URLs like http://www.gnome.org/pt-br/download/. Also, now all this part has a much saner source code.

Default widget for choosing language

Added simple functions to allow templates to get the list of available languages, and also a simple widget to add such support for any theme.

⁂

After having all these corners polished in WPPO, put it to work for real is the last item of this first task, which I’ll do together with the next task I’ve just started. Now I’m working to make a nifty area for the Projects/Apps in the GNOME website. But this I’ll cover on the next report .

It’s been a week after my first weekly report, and it is time to release a new one! Right now I’m finishing the pending tasks of WPPO, a plugin that makes WordPress websites translatable using the same existing infrastructure that exists and is done for GNOME software.

Last week I wrote about the two main missing things in WPPO, and I’m very happy to say that I got really nice improvements in both of the items:

URL handling

The base of a website that have versions in multiple languages is a URL system that understands and create permalinks to each language of all the pages. WordPress comes with a Rewrite API that allows managing the website link rules.

In our scenario, we need links like gnome.org/pt-br/about and gnome.org/es/news/2011/. So, the language is much more like a global prefix to all link structures other than new rules in the Rewrite API.

I checked some existing plugins for WordPress that try to do the same language prefix in URLs (polyglot2, qtranslate and transposh are on the list), and I didn’t think their implementations were really good. Basically those plugins duplicate all the existing rules and add a regex to understand the language prefix in the beginning of each single rule.

The problem with this method is that it duplicates all the rules and ends up being an ugly workaround to something that should come before the rewrite rules (as a suffix of the home url).

Then, to create the URL handling for WPPO, I replaced REQUEST_URI global variable with a version that doesn’t contain the language part before WordPress checks for it. This move avoids the plugin to have to hack around all rewrite rules. WP will then blindly feel fine with a fake permalink that looks like default. To finish I added some filters around redirects and url creations to make everything work as expected. Code of this is here.

Administration area

Now website maintainers have an area inside WordPress admin to check for translation statuses, changes in pages and posts that weren’t sent to translating yet (with links to diff compare between old and new changes), options to activate and deactivate languages and regenerate POT file.

⁂

For this next week I’m planning to to finish all the details around WPPO, make some more tests, polish the administration area, and put a test site online. Then I start my task #2: Create an Projects/Apps section in GNOME.org website.

See you in Summary #3

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!