D8MI news

Drupal 8 has now automatic interface translation import, and we need you to test it! With Localization Update module for Drupal 6 and 7 some people experience problems with when importing or large translation files. For Drupal 8 we have improved the code and added it to Drupal core. All works fine on our development servers, but how does it work in the real world? You can help!

Follow the steps below to test. Especially people who have experienced problems with Localization Update module and people with a slow server or a slow internet connection are encouraged to join the test.

1. Check if your server matches the Drupal 8 requirements.
2. Download and install the latest Drupal 8 development release.
3. Select your language in the first installation step and install Drupal.
4. During the installation the translation will be imported using a batch process. You will recognise a batch process by the blue progress bar. This import should continue smoothly until 100% completed.

When the translations get imported without errors, your test is successful. Please tell us. If not, please report your experience, preferably with screen capture video or screenshots. This video shows the installation in Dutch: http://www.youtube.com/watch?v=XzQAmCo8I1U

There is more to test, but it is a little harder. When you enable a module in your Drupal 8 site, the Interface Translation module will attempt to download and import its translation from the translation server at localize.drupal.org. But the translation server only provides translations of released modules, and not for development releases. To overcome this the Local Tamper module was developed which simulated a number of Drupal 7 modules (for which translations are available) and the Interface Translation module will downloads and imports these translations.

1. Make sure you have Interface Translation and Language translation enabled and have added at least one non-English language. But if you have successfully followed the steps above, this has already been provided.
2. Download the Locale Tamper module from http://drupal.org/project/locale_tamper.
3. Unpack and install the module.
4. Enable the Locale Tamper module.
5. It will now attempt to find and download Locale Tamper translations (but none will be found).
6. Go to the Available translation updates page (admin/reports/translations).
7. Click 'Check manually' to refresh the translation status.
8. The status will now show that a number of translation are available for the mocked modules: Better Formats, CKEditor Link, Compact Forms, Context, Chaos tools and Delta API.
9. Click 'Update translations' to download and import the translations.
10. This will start the download and import of a number of translations. Again a batch process runs to per form this. Again, this should progress until finished.

If the translations are imported without errors, your test is successful. Please tell us. If not, please report your experience, preferably with screen capture video or screenshots. This video shows how I used Locale Tamper: http://www.youtube.com/watch?v=Ivn0EvIXf5o

As I posted earlier in mid-December in Feedback needed on configuration metadata formats that our prior discussion on CMI metadata formats did not lead to successful results, and after a 320+ comment thread, it was broken down into three other issues to discuss more possible options. One of those has since been closed and the two other ones received little feedback and little progress.

However, the problems being resolved are not really avoidable in Drupal 8, so if we don't have better ideas, it looks productive to go with our best results so far (as opposed to not solving these problems in Drupal 8 altogether), so Greg Dunlap (leading the configuration management initiative) set a deadline of January 15th for decisions on the metadata formats, which would still give us some time to figure out any remaining concerns with the implementation before the extended feature freeze on the 18th of February. I agree this is a very timely announcement. Here is a full reproduction of his words:

I would like to establish a deadline for deciding how we're going to proceed with this. If we don't, we are going to go back and forth on these decisions in a circle until feature freeze comes and then we're screwed. My feeling is we will probably need about a month to implement any new proposal and get it to RTBC, so I'd like to lay down January 15 as our deadline or deciding what to do. If we haven't agreed on any new proposal, then we reroll the original RTBC patch from #285 and get it in. We have to get this done, and right now I don't see any light at the end of the tunnel which scares the crap out of me.

So there is just under a month to work out the new proposals and establish consensus. Lets do it or admit its not getting done and go with what we've got.

Explore the options and follow up on issues listed at https://drupal.org/node/1648930#comment-6859916 please. Thanks all for being involved and making this as good as we can!

The study was conducted after Gábor Hojtsy made an open call for the multilingual user testing results. It was originally planned to run as many tests as possible on the second day of Drupal Balkan Summit in Zagreb, but the snow prevented me from going to day one, and a personal emergency had me out of the second day within an hour of getting to the summit. This started a trend, as every other session was plagued by something or other. The results are compiled from my notes and backup audio recording I made over my phone.

In a beautiful 320+ comment thread we discussed introducing a metadata format for configuration in Drupal 8 to use for identifying translatable strings, potentially generate translation forms for configuration (or per-group or per-domain configuration) and possibly other uses (such as validation).

Our primary use case is multilingual configuration, and our efforts were not successful to get the change in core. If we want to be able to translate views, content types, user notification email text, and so on at least as shipped with core and contributed modules (even if not the configuration you create on your own site), we have no way to avoid solving this problem.

The most contentious question that contributed to the original patch series being turned down was how metadata is defined for configuration (file format and underlying system used), where (file naming and placement) and how you refer to metadata of outside dependencies. To explore this problem space, we now have not less than three parallel efforts lead by a star lineup of core contributors, @chx, @effulgentsia and @reyero. We all want to productively push forward and move on to other things once this one is successfully resolved, so your feedback is welcome on all three issues:

1. One using kwalify and typed data: #1866610: Yet another schema format for Drupal configuration (Based on kwalify)
2. Another one using typed data only: #1865300: Introduce configuration definition file format and API for reading it
3. And finally one not even using typed data: #1861640: Provide config metadata solely for translation

For a short summary of how we ended up needing a metadata system of some sort, see https://drupal.org/node/1648930#comment-6840700 (and/or the design goals in the original metadata issue summary). If you have questions, find us on in IRC and on the issues!

Thanks a lot for your input!

One of the key things I wanted to do in the Drupal 8 Multilingual Initiative after the December 1st feature freeze hits is to go and do lots of user testing of the functionalities we built and adapt the user interfaces and flows to make it easier to build multilingual sites (and then test it again). Not many people believed this would actually happen (when you say in an issue you'll follow up with more user testing, and so on, it can be seen as just a way out to move on). However I've got outstanding help from Bojhan Somers, Dharmesh Mistry and Lisa Rex on best practices for user testing. I not only got help on the tools to use, but also building out a concrete test plan with Dharmesh and Bojhan actively involved. To say the test was well prepared is an understatement.