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.
Timing and the focus of the study
The study was spread out during the 3rd and 4th weeks of December 2012. The three key questions were:
- Can users add a foreign language to an existing site?
- Can users configure translatability / language options for entities?
- Can users do a basic node translation?
Participants
There were ⅘ participants in total. All of them worked in IT and have at least basic familiarity with web based applications. All of them had at least working knowledge of a web based CMS (in a range of products) or similar. One used both Drupal 6 and 7 extensively, and helped administer a small Drupal 7 Commerce site.
Task 1: Adding Croatian to an English Site
In this task, what we have been looking for is that people realize that language setup is provided by a module that needs to be enabled, understand how to add a language and explain the three special languages in core that were added in Drupal 8 (not applicable, not specified and multiple).
Every participant behaved like the participant’s in Gábor’s study: all of them looked in the Regional and Languages area of the Configuration page first. Following that, they would look into Content, Structure with Extend being the distant third (and in once case fourth when the user opened up Appearance before).
- The “wall plugin” comment first noted in Gábor’s study was also heard a couple of times.
- I have a feeling that everyone expected that the CMS would be able to handle multiple languages and that “you do not need to extend it to do that”.
- Three participants looked and enabled the Languages straight away. Of the three, two noticed Entity
- Translation but did not associate it with the task at hand and left it disabled, because they did not understand what it would do. The third enabled it “just in case”.
- Again, just like in the Hungarian study, none of the participants noticed or enabled the language switcher block.
After the language was enabled all of the participants concluded that now they need to go to Configuration page.
When asked to comment on the process, most of the participants expressed confusion as to why they had to enable the entity translation module, as they expected that adding a language to the site implied that the content will be translatable as well.
The second comment most had was that it would be more logical to enable the language module, and get taken to the configuration page right away.
Task 2: Making Things Translatable
The cornerstone of this task was the patch from http://drupal.org/node/1810386 which we applied to the test environment.
From this point on everything went fine for my participants. Clicking around for task one got them all comfortable enough with the logic of the GUI, and all of them went straight to the configuration page and found the Content translation settings link with ease and immediately figured out what it was.
The settings page was easy to navigate and to use for all of them. They did ignore the configuration options, and when asked could accurately figure out what they do (the default language option and the hide language selector option) as all of them actually read the descriptions next to both the options.
The only issue, as mentioned in task 1, was the need for the few participants to go back and enable Entity Translation module. All of my participants commented that it looked like an extra unnecessary step in the process.
Task 3: Translating Content
Just when I thought that the previous task was uniform and easy, we got to the third task. All of the participants immediately went to the content section and could easily translate the sample article.
All of the realised that the title was not translatable, and could not understand why. The warning label was noticed, so no one went to the translation configuration page to enable it, but it was not a good experience for any of them.
While doing the test most of the participants wanted to see the full experience and created their own content and translated it. All of them got the interface easily, but could not understand why you needed to save the content and then add a translation. Again, all who tried did figure out that that is how it works without any guidance, but did not like it.
Comments
I think that task 2, making
I think that task 2, making things translatable might test better if task 1 had not been done, since enabling content translation has the side effect of enabling languages and needing a language added.
Cathy Theys
thanks for doing this test and report!
Thanks for doing this test and the report! Based on our great progress with the findings in the Budapest study (most of which was confirmed above, great :), we made some good inroads into fixing most issues identified above. Here is my review of the issues mentioned:
Read through this report again to try to identify new things to work on given all the work done to day.
People epecting to find languages in "Regional settings" is somewhat solved by moving the "Default language" setting there (if the language module is enabled). http://drupal.org/node/1803638
Extend icon: http://drupal.org/node/1891096 - no solution yet. Not really a D8MI problem though :)
Language should be out of the box: with the integration of the language selector in the installer (and the consequence of enabling locale and language modules), interface translation will be naturaly enabled out of the box. Content translation will not be, but the installer cannot assume you want a multilingual site vs. a single foreign language site. An option would be to put a checkbox in the installer for enabling mutilingual content. Not sure this really belongs there, there are almost no other features like this. (You mention this problem 3 times :) I opened http://drupal.org/node/1917212 for this.
"Entity translation" module not noticed: this got renamed to "Content translation" and is now grouped with the other multilingual modules in a module group: http://drupal.org/node/1833184
Language switcher block message: http://drupal.org/node/1891450 - not solved yet
Success of the entity translation UI sounds great :) http://drupal.org/node/1810386
Title not translatable: http://drupal.org/node/1818556 and http://drupal.org/node/1498674 - this will take a while still to resolve. Not a piece of cake :)
Saving nodes needed before translating them: well, not sure how we could even improve this. You don't have a translate tab on nodes before you save them, so no data loss is possible by clicking away. So this is more of a basic thing to learn I guess. I don't think we have a chance to improve on this in Drupal 8 by making node submission use a Views like multiform-stored-value model where translation can be entered up front before saving. That is a huge disconnect from how nodes are handled now.