When I started GlotPress one of its goals…

When I started GlotPress, one of its goals was to be a sandbox for ideas, which could eventually land in WordPress. Some of the experiments made it depart a little from the (Word|Back)Press code structure. Which can be a little bit for new-coming GlotPress contributors.

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.

#code, #hacking

Projects Page

The projects page, listing all sub-projects and translations, is one of the most visited pages in GlotPress. But its current layout lacks vital information. Like which translation teams have reaches furthest in the translation race. Or where should I start translating, if I am not an active translator. That’s why we have some mockups of the project page, redesigned.

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.

Future Roadmap and 1.0

GlotPress has been alive and kicking for a couple of months now. There has been positive feedback and there has been not-so-positive feedback. But there have been tons of feedback. Translators have been using inferior tools for years and already have a long list of features they want in a translation editor. This led to the logical question: which feature do we implement next?

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.

Mass-create Translation Sets

When you create a new project, it doesn’t have any translations and all translation sets have to be created one by one. In case of a larger GlotPress installation it usually makes sense to use the same translation sets from another project. Usually a parent one.

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.

#bulk, #project, #sub-project, #translation-set

The GlotPress Report #3 (Feb 26 – Mar 12 2010)

The most important changes since the last report are the new formats for import/export. GlotPress now can use Blackberry RRC and Android XML files.

  • 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 GlotPress Report #2 (Feb 19 – Feb 25 2010)

It was a slow week for GlotPress.

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).

The GlotPress Report #1 (Feb 5 – Feb 18 2010)

Before diving into specific features and bug-fixes, this week’s news it that translate.wordpress.org was launched. It is a GlotPress install, which allows all WordPress translators to collaborate and will host the translations of all the projects in the family like bbPress and BuddyPress.
  • 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.