That’s why I started writing a HACKING file. It’s not complete, but it’s a start.

If you are developer, I would appreciate if you have a look and tell me if it made the architecture more clear. Or if it helped you find where some part of the code lives its happy life.

I’m Hugo, I work for Automattic as a Social Designer. I love designing user interfaces and craft the experiences so that a product is easy to use. I’m also part of the Portuguese WordPress Community and I’ve used GlotPress to help translate WordPress to Portuguese!

My friend and coworker Zé, asked me to “take a look” at the ui of GlotPress and brainstorm a bit on how it could be improved.

We started talking about a bunch of stuff and details, but I decided to focus on one thing at a time. Here are the priorities on my first iteration here:

• Improve the visual design of GlotPress (Zé mentioned he’d love to have it look more like the WordPress Dashboard)
• Improve the information architecture on the header – reducing the redundancy and streamlining the interaction
• Improve the List Actions / Sorting / Filters to match the needs of a power user, as well as to make it easy for newcomers

With this list in mind, I sketched some ideas and we ended up coming up with this:

Things worth mentioning:

• The visual design is much closer to the one on the WordPress Admin
• Got rid of the GlotPress logo at the top, as it didn’t really give any context and if you contribute to translations on multiple sites (ie: WordPress.org, WordPress.com, Genesis Framework, etc…). Now you get instantly a notion of where you are without any clutter
• Separated the Bulk Actions, Sorting and Filters into different areas, to make it clearer what each do. My thinking behind this was to have the filters (I’m calling it “Quick Filters” right up in the visual hierarchy, next to the contextual title (You’ll also notice a “Advanced Filters” link at the end, which I’ll mockup the interaction on a later iteration). On a second line you find the things that directly affect the list – Bulk Actions and Sorting on one side (made it much simpler by just using select items), and the Visualization options (Wishlist – like WordPress does with lists – more on this later on), item count (whishlist as well) and pagination.

I would like to get the discussion going around this and to get your opinion so I can know if I’m in the right direction or not (feel free to kick me in the but!)

Cheers!

Right now, it looks like this:

A preliminary patch for this is attached to this Trac ticket, but just contains the number of items per page, I’ll clean up what I’ve got now and add a second patch, but I’d love to know what you think should be in there…

Goals

Before showing you the mockups, here are what you should be able to accomplish on this page:

• Know which software application (or which parts of it) you can translate in this project and get more detailed information about the project and its structure (sub-projects).
• See all of its translations.

Apart from the general goals, there are more specific goals, depending on the user, visiting the page.

If you are a random user, just browsing around, you should be able to:

• Get acquainted with the project
• Quickly see stats for the project translations: in which languages are there translations and how complete they are

If you have come to this page to translate:

• Determine whether this is the right project to translate
• You should be able to easily access your language translation
• Quickly see how your language translations compares to other translations

If you are a validator:

• Add the translation in your language, if it’s missing in the list

If you are an administrator:

• Edit the project
• Create sub-projects
• Create translations sets in this project
• Import originals for this project

Mockups

Project Vertical

The first one has the same layout as the current page, with a couple of new things:

• Has Active project functionality. Active projects show random users what to translate. For example the Development projects should be active and the 3.0.x one shouldn’t be active, because it is designed to include only string fixes.
• The actions are moved to the top. Scrolling through all the translations was tedious for project admins.
• Sub-projects got inline descriptions.
• There is no delete link anymore. It should be incorporated in the Edit page.
• Validators will be able to create the translation sets themselves.
• Each user will be able to set preferred languages in their profile. These languages will always be shown on top.
• The extra column may include handy stuff, depending on the context. For example on WordPress.com we may include the last deployed time.

Another, more compact take:

Project Split

This is essentially the same, but sub-projects and translations were fit into two, instead of one long column. This layout will be great for projects, which have lots of sub-projects like WordPress (it still doesn’t but a fast forward a few releases and you’ll see).

We’d like to hear your comments on these mockups.

One thing I’ve learned from WordPress development is that implementing every feature users want rarely makes all users happier. Often those who requested it, don’t use it either. We should include only functionality that is useful for 99% of our users. With this smart advice in mind, I started sorting out through the hundreds of suggestions I had collected during last couple of months. But I encountered a little problem.

Most of the features in the list would be useful to 99% of the users. A collaborative translation editor, which makes translators’ life easy, wasn’t as simple as I wanted. The question again was: which features do we implement now and which do we implement later?

On the dev-day just after WordCamp San Francisco in May, we had a brainstorm session for features and their priority. You can see the result in the Active Tickets by Milestone report in trac. Roughly when we are done with tickets in the 1.0 milestone will be the time to release 1.0. In each milestone tickets are sorted by priority — these on top will be implemented first.

Implementation is the hardest part, even though above I complained how sorting out features and priority was hard. If you feel like coding, grab a feature and drop a line in the mailing list. We’ll be more than happy to help with any advice, testing and debugging.

This was the case with translate.wordpress.org. We made a project Twenty Ten for translating the new default theme in WordPress 3.0. The project was a sub-project of WordPress Development. Since all translators of the trunk version of WordPress would want to translate the new default theme too, I just synced the translation sets of Twenty Ten with those of WordPress Development using the new mass-create feature.

You can see the feature in action in this short video:

As shown in the video, you can choose which project to sync translation sets with and then preview the added/removed sets before clicking Submit.

• In [426] the first traces of documentation were added in the form of a README file;
• In [427] – [430] the format framework and the RRC format were added;
• [440] fixed a bug when the user wasn’t redirected properly after login. This was annoying.
• In [442] we added the Android format;
• [443] fixed a bug introduced in [441], which allowed non-logged in users to be super-admins in certain conditions.

The only changes were language variants standardizations and plural forms fixes, contributed by Zé. All variants language names are now in the form Main language (Region). Example: Spanish (Chile).

• In [407] – [410] we added proof-of-concept JSON API for the translations page. Just prepend /api in front of the URL. For example /projects/wp/dev/de/default gets you the HTML page for German translations and /api/projects/wp/dev/de/default will return the same information, but in JSON.
• Since [411] and [412] GlotPress can be installed in a directory different from the user-facing GlotPress URL. The purpose of that is mainly to have it as an svn external.
• In [419] – [421] project pages got visual fixes: description is now shown, the text for no translations isn’t show if there are sub-projects.
• [422] fixed a serious bug, which prevented users with approval access to discard warnings.