Drupal 8.0 alpha2 is the first tagged release of Drupal 8 that comes with a package downloadable from drupal.org. What does this mean for Drupal software translators? Well, it means it is made directly available on localize.drupal.org for translation. We make tagged releases available so that translators don't need to chase a moving target.
Looking at Drupal core releases on the translation site, Drupal 7 has 440+ files parsed for translatable strings and about 4600+ strings found there. In comparison, Drupal 8 has 5200+ files parsed (almost 12 times as many files) with 6700+ strings found (almost 1.5 times Drupal 7). So translating Drupal 8 will definitely be a bigger task compared to Drupal 7.
But! You should not jump into translating Drupal 8 yet if you don't want your changes to go unused in the final version. First of all many things are still in flux, texts may change dramatically, user interface cleanups will happen, and so on. Watch out for an announcement much later on text to be ready for translations.
What is also pretty important, all these translatables are just from the places where Drupal 8 uses the same API as Drupal 7. Drupal 8 for example removed st() and $t() in favor of using t() at more places, which does not change the situation for localize.drupal.org. But there are also API changes which made translatable strings move around places. Module info files are now info.yml, some hooks got converted to annotations. Default configuration that used to be saved into the database with a t() at install time are now shipped in .yml files in English (and not translated to the site install language in the original file by design). These are all great changes, but the translation server needs to adapt to them.
So far @ksenzee is the only person who signed up to work on making the backend of localize.drupal.org capable of handling the new APIs properly. There is a whole set of issues to make these happen at https://drupal.org/project/issues/search/potx?issue_tags=Drupal%208%20co... and we need more hands to help, test the patches and make this happen. I believe it would be a grand mistake to attempt to release Drupal 8 without these issues resolved, because only if these are resolved can translators ensure that Drupal 8.0 is fully translated in their language for release (even if there are already 1.5x as many strings, there will be even more). And given our enormous push for multilingual improvements in Drupal 8, we should support this with full translations as possible for release.
Who else is up to make localize.drupal.org ready to support Drupal 8? Comment here or contact me at http://drupal.org/user/4166/contact so we can coordinate.Read more
As part of working on the site upgrade, our messaging and notifications system is discussed. Unfortunately we don't have a reliable number on how many people rely on email notifications from localize.drupal.org (due to automated signups) and the complexity of the upgrade process for notifications (given that we need to migrate to new modules) might set back our upgrade process even longer.
While the Drupal Association is busy with updating drupal.org itself to Drupal 7, the DA is not directly involved with the localize.drupal.org site maintenance and upgrade (similar to other subsites), so we are not tied to the main site upgrade in any way (neither do we get financing for this work).
One possible shortcut is to sidestep email notifications for the immediate upgrade and get back to the feature later. Are you heavily relying on notifications from localize.drupal.org? Please speak up at http://drupal.org/node/1392694! Thanks!Read more
Localize.drupal.org is becoming one of the least taken care of properties on drupal.org. Although Sebastien Corbin does a heroic job preparing the Drupal 7 site upgrade, that is still off in the future. There are existing bugs (in translation packaging, project parsing, performance, etc). Noticed that the frontpage stats have been disabled for performance reasons for months? Yeah. There are infrastructure tasks and Sebastien also needs people to join porting the site to Drupal 7.
With Drupal 8 planned to be relying even more on data from localize.drupal.org directly, the site will gain even more prominence. We can safely say though that pretty much nothing is going to change/be fixed on the site if people don't step up. Time for you to make a contribution!
To help people get started I'm holding a BoF at DrupalCon Munich titled "We love localize.drupal.org". If you do too, and want to help, come and discuss.Read more
We are planning several changes for Drupal 8 to improve the user experience around translations of the Drupal software (including its modules, themes and distributions). We plan to build in the Localization update module into Drupal 8 core, and we are on track doing some of those steps. We also want to improve the general user experience of some software translation tools we have in Drupal, and your feedback on both counts would be very appreciated.
Improvements to the built-in software translation interface
We have fixed a long standing bug of idenification of singular/plural string pairs such as "1 minute"/"@count minutes". If you did not load in a .po file in Drupal 7 and before, the identification of these source strings never related them to each other, and translating them properly was impossible on the user interface. We fixed this bug by changing the storage for singular/plural pairs, and introduced a temporary complication to the built-in translation UI. We kept the search/overview screen as-is in Drupal 7 and before. See the third and second images at http://drupal.org/node/532512#comment-5641302.
We think that people go to the translation screen to actually translate things, and also that it is more likely that people want to translate multiple things into one language (which the current UI does not support at all) versus translating one thing to many languages (which the current UI is optimized for). So we have an ongoing discussion at http://drupal.org/node/1452188 with various UI idea to move forward. The most up to date list of options we considered is at http://drupal.org/node/1452188#comment-5777686
Because there are so many directions we can go, and we don't necessarily agree on the exact goals of the UI either, feedback from translators would be extremely valuable. If we cannot agree, the worst thing that can happen is that we'll release with the UI as-is now in Drupal 8, which I think is not ideal. Your feedback welcome!
Custom string translation tracking
We already centralized .po file lookup into one directory, so Drupal 8 will not look at various places under modules, etc. for .po files. This is very useful to support distribution and staging/deployment of translations without interference to version control of the source repositories. Adding in automated download and import of .po files from the community is still to be done.
However, because most community translations are not complete and we want to keep the possibility for people to customize translations downloaded from the community, we are building custom string tracking and customized string protection into the APIs and the UI. This is being discussed in http://drupal.org/node/1445004 with the main UI simplification / new UI additions explained in http://drupal.org/node/1445004#comment-5673836 and the following comments. I hope/believe that even though we are adding some new functionality here, we can also use this opportunity to not complicate the UI much at the same time and build in the automated translation feeding in a way that people can still customize and divert from as needed. Because the proposal does add some new concepts and UI components to the .po import/export screen to understand, it would be great if you could help provide feedback on whether the additions make sense and the simplification of the extended functionality helps make it easier to understand overall.
If the changes proposed look exciting to you and you are interested in being involved, the Drupal 8 Multilingual Initiative is meeting every second Wednesday on IRC in the #drupal-i18n channel. Meeting announcements with exact times are posted on http://groups.drupal.org/drupal-initiatives. People from all experience levels and all angles are welcome!Read more
Drupal 7 was released 13 months ago, and while Drupalcon sites (like Denver and Munich) are built on Drupal 7, none of the permanent Drupal.org sites are on Drupal 7 yet (or started to being ported to Drupal 7). This is usually due to (a) huge custom built modules or setups used that are hard to migrate (b) ongoing improvements to introduce better user functionality. With localize.drupal.org the situation is a bit more interesting. As I wrote in my last news post in October, Dashamir Hoxha mostly updated the huge base module for the site to Drupal 7 and Organic groups has a Drupal 7 version too, so the two biggest base modules are available. There are some interesting challenges however. The drupal.org theme (bluecheese) is not yet ported to Drupal 7 (help at http://drupal.org/node/1438716), the Organic Groups User Roles module functionality is integrated in Groups for Drupal 7 but there is no upgrade path and we'd like to switch to simpler solutions from the Messaging and Notifications monolith.
The update to Drupal 7 would be great to lead by example for other sites on drupal.org as well as keep improvements to the Localization Server module suite to one active branch. With the Drupal 7 port there and the Drupal 6 version used actively on the site, feature requests and bugfixes come in for Drupal 6 and there is a lot of extra work to port them to both versions at once.
Finally, I don't personally have time to head the effort but I can help provide guidance. Sebastien Corbin signed up to help do test upgrades and would very welcome any of your help. Want to work on updating the Drupal.org theme to Drupal 7? Figure ou an upgrade path for Organic Groups User roles to Drupal 7 Groups configuration? Help migrate Messaging and Notifications signups to a simpler framework? There are lots of opportunities to help out there. If you are interested see Sebastien's issue at http://drupal.org/node/1424984 and signal your interest there!Read more
It has been a while since I've posted an update on localize.drupal.org services for various reasons. I greatly hoped that our Google Summer of Code project for activity tracking announced with big fanfare in May goes through well, but unfortunately my student dropped out from the program lacking time due to family reasons and did not make useful progress to roll out improvements.
Also, Dries selected me to lead an effort to dramatically improve language support in Drupal core for Drupal 8 and that has a scope way beyond just software translation. We did a pretty good job of providing tools for software translations so far with localize.drupal.org, l10n_update and l10n_client modules, but for Drupal 8, the focus is to bring complete core features and more usability to these and content and configuration translation alike. It is very exciting and going to bring Drupal to a whole new level where language support is needed! To follow that effort, see the video and mindmap at http://drupal.org/node/1260534. It is a huge undertaking and it required me to dramatically dial down my focus on localize.drupal.org improvements.
However, in the meantime, our misterious problems with some packages being partially parsed did not solve themselves, and we could not figure out the real reasons, so Zoltán Balogh got tired enough of the problem that he coded a workaround for every team manager to be able to request a release to reset itself and parsed again. That was just rolled out, so now every translation community manager should be able to see a Start over link on project release lists, with which you can request for a broken parsed release to be parsed again. Because our release parsing problems are transient, this should get you back a fully parsed release pretty soon afterwards.
There is also continued interest to set up new teams on the site, I've just added Oriya, Lao, Azerbaijani and Tamil (Sri Lanka) to the list of languages, which is now just one shy of a hundred (not counting our test language playground). That is an amazing number! Get ready to pop your champagnes! Who is going to be number 100?
Finally, Dashamir Hoxha did a stellar job to come in fresh to the Drupal community and update such a huge module as the Localization server module to Drupal 7! Yes! It passes all tests (although the test suite does not cover all of the functionality, it does cover all the basics and a sizable part of what localize.drupal.org needs). It would need more work, but we are a lot closer to be able to update localize.drupal.org to Drupal 7 in the future.
Now with all this while there are very nice prospects for localize.drupal.org, I will likely not be able to dedicate a good amount of time to the site, so I decided to post a public call for help instead, while I still have resources to help mentor people who would like to contribute and possibly eventually take over maintenance and improvement of the site. For a long time, localize.drupal.org was the posterchild of great improvements on drupal.org, now that all the awesome improvements are going on on drupal.org we should not leave localize.drupal.org behind either. Are you interested in working on gradual improvements? Porting the site to Drupal 7 (og, messaging and notifications and all that)? Comment and let's see how I can help you help Drupal!Read more
At the end of March, when the Google Summer of Code 2011 Drupal group was in an idea collection phase, I've posted two suggestions: Expose Drupal translation activity and Gettext API for Drupal contrib and core. The first one involved tapping into the huge hidden activity that happens on localize.drupal.org. To quote from my suggestion:
Due to technical and scalability reasons the site uses custom code to provide translation of 7000 modules and about 20000 releases of these modules. Each release is parsed and ends up in the database of the site which results in almost 270000 strings to translate. That's a lot of stuff! Now add up that we have almost 100 languages and each string can have any number of suggestions for any language. Finally, each of these suggestions have their own "commit" history with data on who submitted them, when, via which method (multiple sources supported with a remote API in the mix), when was it approved, declined and approved again by whom and when, and so on. So you can consider this a 3 dimensional version control system in a database (version control per strings * languages * suggestions).
Now since this is all stored in this form, the activity happening is pretty "invisible". Moderators and fellow translators see little of this activity. Some teams use a wiki page to list things they work on, informing moderators that new stuff is available to review. Without that, reviewers can only look actively for stuff to review, which is tedious. Its a definite characteristic of communities online and offline that seeing the momentum, the activity and work being done energizes others and moves them to contribute more. So exposing all this information in natural and automated ways is crucial.
I'm happy to report that the immense task to expose all this activity with activity streams and graphs was taken on by a Hungarian student named Ádám Lippai, who is going to work on the project this summer. It should be an interesting mix of working on the drupal.org testing/staging environments, Hudson, our localization data storage and exposing the data changes in a meaningful way on the UI.
I'd like to thank both Ádám for signing up and the Google Summer of Code program for financing the project. This should really help take localize.drupal.org to another level.
Ps. Check out the other accepted projects at http://drupal.org/node/1139168 - note that we also have a project to work on activity exposure on drupal.org projects, so there'll be even more of this type of work on the site. Also, I'm still looking for people to work with on Gettext API for contrib and core (although no financing attached), as it should be part of efforts to improve multilingual support even further in Drupal 8.Read more
There has been tremendous growth on localize.drupal.org lately thanks to new teams launching from all over the world. The latest ten teams launched are: Maltese, Uighur, Occitan, Bengali, Malagasy, Scots Gaelic, Sinhala, Tigrinya, Kurdish and Kyrgyz. We are approaching 100 teams fast with 94 translations projects in the system at the moment (including our testing group). There are also many more in the queue being discussed.
Since our last usability update in January, there have been a few subtle but hopefully helpful changes on the site, including the following:
- Direct linking to source strings is now even easier. The # marks that were previously hidden by default are now displayed as "list item markers" in the filtering list results, so they are a more natural part of the page. Just clicking them gets you the permalink for translations of the given source string.
- There were also some improvements in the backend. We've prepared the file packaging system to be able to provide progress status of their translation readiness at a later point. This also helped debugging some Drupal project release parsing issues.
- Partly as a result of those backend improvements, we now have a new release listing page for each project. See http://localize.drupal.org/translate/projects/views/releases for example. This exposes some previously internal data such as when did we pull in the release for parsing, how many files and actual source strings did we find in the release, and whether we found warnings in the releases. You can also look at details of a release, review the files we parsed and the warnings we found.
- The front page got some great new possibilities to order the Drupal core project status by different criteria. It is still ordered by language by default but it can be ordered by progress or contributor count. The contributor count only includes people who actually contributed to translations in that language (vs. members of the group). The language overview page got the same treatment and both pages got some better introductory help.
- The project listing page got alphanumeric filtering possibilities and is on its way to be simplified and get actual sorting support at a later point. It is not made up from one SQL query, so not exactly trivial to dress up with sorting features (much like the language listing pages), but it is going to happen.
- Projects removed from drupal.org or those which never had releases are not displayed in the project listings from now on. This was a long overdue bugfix and should make project browsing more meaningful.
- Translation export pages got lots of attention and are much more simplified. Archaic export options for CVS commits, or Drupal 6 or 5 structured packaging are gone. Remember to use l10n_update module for best experience downloading translations for your sites.
- Finally, you can actually trust the pager on the translation pages now, it will count the number of source strings to display not the number of translations and suggestions matched by your filter.
I hope these usability improvements make it easier for all of you to use the site day by day. As always, see the issues page to submit bugs and requests.Read more
At the time of this writing the Drupal.org git migration is still fresh, and I expect project maintainers and especially translation maintainers to possibly wonder about one thing. Sure, CVS ID strings were removed from all files with the git migration, but one more thing happened: all translation files were removed from drupal.org projects. As it was announced in the Drupal.org Maintainers newsletter over two months ago, translations are now to be contributed to localize.drupal.org. The drupal.org projects themselves should not have .po files committed and maintained, as that would duplicate the work going on at localize.drupal.org. The files were removed in an automated commit on each project branch by the Drupal Git User with the comment Removing translation directories. (Therefore the files are available for reference in the history).
Project maintainers should not accept .po files anymore for inclusion with modules or themes, localize.drupal.org builds these for download, and Localization update can be used to automate the download and even the update of these for releases of modules and themes. There are various advantages to this including the possibility to release and fix translations after a module release goes out, making downloads smaller and only grabbing the languages you actually need.
Translation projects themselves are kept (such as the 6.x-1.x branch of the Hungarian project). These projects should also move to localize.drupal.org entirely, but in the interest of them being available for reference (not just in the CVS read-only backup), the projects are migrated to git. These are however also to be considered as reference and not to be worked on in git.
Any questions about this transition? Let me know in the comments.Read more
One of the goals of localize.drupal.org is to provide a simple UI on top of a complicated process: translation submission and approval. The system handles strings in three states: suggestion (pending approval), translations (which are approved) and declined strings (which were deemed to have bad quality). For the sake of approaching this as simple as possible, the backend focused on the submission and approval details so far, and neglected other transitions. However, in practice many limitations became evident.Read more