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.
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.
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
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:
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.
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.
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 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  the first traces of documentation were added in the form of a README file;
- In  –  the format framework and the RRC format were added;
-  fixed a bug when the user wasn’t redirected properly after login. This was annoying.
- In  we added the Android format;
-  fixed a bug introduced in , which allowed non-logged in users to be super-admins in certain conditions.
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).
Here is the zeroth edition of the GlotPress report. This series of posts will give you an overview of what happened with GlotPress in the last week.
- In  we added a button to fill-in the current translation field via Google Translate:
- In  we added bulk translation via Google Translate. It affects only strings without translation and if the translation was successful sets their status to
- In  we simplified the bulk menu: no more radio buttons for both approve and reject. Now there are two separate buttons:
#bulk, #google-translate, #report
Sometimes projects have too many strings and the developers want to show the translators what is important and what — not.
Here is how GlotPress helps.
First, if you can administrate a project, you can set priorities:
Setting a priority
Then, the translators can see each string’s priority:
Hidden — shown only to admins
The new default sort order is by priority. Translators can also manually sort by priority:
Sorting by priority
In this blog you will find updates on GlotPress development and description of some of its features.