Rework language list admin user interface

In D7 we have the possibility to hide native English, it's just matter of exploiting it :)

http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/langua...

So, the focus of this issue is a bit confusing because much of it is related to removing English from this list. This screen can be better, for example no drag and drop, no default, no "enabled" in the case of one language. Also dropping the selection tab.

Additionally, can we move setting the default to the "edit" page?

I think to fix that UI we should fix first the API / modules / conceptual approach for which it is just the visible part. Copying some notes from here http://groups.drupal.org/node/161589#comment-542474

Language should be a 'core' concept somehow independent of localization or translation. In the same way you select a Country and a Timezone for your site you should be able to select also a language. Then you would have a single language site that may have the UI in English but that may only be seen by the site administrator.

(Whether locale is enabled automatically after you select a language for your site is a question of the install profile. Entry level install profiles should do that.)

One more step would be having a 'multilingual' site. Then you need a list of languages (current locale language configuration) a default one, etc. With our current set-up, by enabling locale, just because you want a single (non English) language site, the user runs into language lists, default language, etc, which are things we could save. Actually you have a bilingual site when all you want is a single language site but not an English site.

In short, translating into UI:
1. One language, you have a drop down, produced by system module.
2. More languages, you have radio buttons, like current UI more options (enabled, disabled, etc), provided by locale module
3. Language list is a core concept (system module) pretty similar to country list, only more configurable.

(sorry, fixed the comment in #3, bad markup..)

UX designs attached

Interesting start. I'm attaching a first pass review of the design with a bonus unrelated question.

The objective here though is to improve display of the single-language situation. It would be good to see that state mocked up in here. I'm interested to hear why the switch away from the default table for listing languages, instead going for something resembling the themes listing on Appearance page.

Hello everyone,

Here are my notes on our discussion of this issue at today's code sprint. Please correct or add to them if you see anything I've missed.

Montreal Code Sprint Notes and Recommendations

• English should be an editable, translatable removable language separate from default text used with interfaces.
• Concerns were raised that the UI depicted in #6 and #8 above would be unwieldy on sites with numerous languages. The bulk of the comments that follow relate to current UI as depicted in the issue summary.
• The direction column should be removed.
• Rows for disabled languages should be greyed out with an 'enabled' checkbox still exposed.
• A translation status column should be added depicting the percentage of text translated for each language depicted.
• The 'Add Language' action link should be replaced with a select list similar to the one described in the code sprint notes for issue 1260716.
• It was suggested that an action link be added alongside this for adding custom languages.

Some more mixed thoughts about the UI:

- What's that Language name in English? Shouldn't we just display the language name in the current locale? Then maybe show the proper language name somewhere but in any case the primary language name should be consistent with current locale.

- Having 'disabled' and 'non-existent?' languages is somehow confusing and limiting. I think we should consider al languages as 'existing' in the first place and have only Enabled and Disabled ones. We don't really need 3 different states for languages. Though it would make some sense if content in disabled languages got unpublished somehow.

- The old rows display was cleaner and more escalable IMHO (and allows reordering as Gabor points out)

So I would rework the display basically as:
- Rows of enabled languages.
- Rows of disabled languages (still with their edit/delete option), but this could be a collapsed section and maybe 2 cols so its shorter.
(Some option to add a custom language *at the bottom of the list*, search first, add if not found)

Adding a language is something that usually happens at site set up and then maybe once a year so we shouldn't optimize the UI for that. *We should optimize the UI for administering currently enabled languages* Then if we want an autocomplete for quick search, fine, but it could go at the top and filter both enabled and disabled languages.

@Gabor
Oh, right we've really shifted the focus here :-( Then I'm not sure there's anything wrong with the current language admin UI...

About using disabled languages for anything that's just an (my) ugly hack and we should look for something better. Like keeping this page for defining languages in general and have somewhere else interface languages and content languages defined (I think there's an issue abt that, cannot find it now).

(It was just easier to use disabled languages than to add another page to define content languages which is what we should have done and what I'd like for D8).

Really, when you start using disabled languages for anything, the 'Enabled' option just means use as an interface language. Then the 'Existing' one (having the language defined) means it can be used for content, or for anything else. The whole thing gets confusing.

So I am wondering wether this could be better the place to define a list of languages. Nor disabled nor enabled nor anything, just a plain list of languages (code, name, ....). Then somewhere else we decide which ones we use for UI, which ones for content, which is the admin language, or which ones as a value for a language Field for an entity....

We're talking about this page in a lot of issues - perhaps we should open up a meta issue to talk about what it actually contains and allow the individual issues to deal with the single challenges.

Here's a mockup of the Languages page that contains inspiration from Jose Reyero's request in #1260860: Rework language list admin user interface, Gabor's previous comment, and #1266318: Make English a first class language. My own addition was adding in an easy css visual representation of the completeness of the language.

• The graph makes it a little more pleasing, some quick information that isn't just cold numbers, but
• More importantly, it gives this table the space to include many more columns of stats.
  If five modules use that hook to display items, the table will be overloaded. But, if we just shrink the bar and hide the text with overflow:hidden; it's accessible, AND lets us populate this page with all of the information we need.

@emarchak

Just nitpicking. I like the progress bar, but it needs a better label. The interface being 95% done is a little disconcerting, taken literally.

Maybe "Strings translated"?

@tarmstrong

I agree completely, but we'll have to think of a short label, as this table could get over populated very quickly. Maybe something like "Completion," or "Progress"? Although that sounds like an upload status :P

@emarchak: "Completeness"? (Which I think is subtly different from "Completion")

"in my recollection, I don't think we agreed on that we should move away from the action link, and instead discussed the page that the action link leads to, so we can keep the pattern of these pages like elsewhere."

@Gabor: We had talked about having something in the action link area to add new languages (now inside the table in #18). I assumed that we were looking at removing the action link and replacing it with this.

I think the #18 language search within the table makes a great deal of sense. I like that it mirrors existing patterns from things like field API. The progress bar style for translation seems a bit more graceful than a fraction and a percentage.

More comments about having the add language UI within the table as seen in number #18: If this is implemented with a select list, language names should probably be presented in the language being used by the admin user. It's not clear to me what the function of the text box is. I suspect as well that a button of some sort is needed to trigger the add language process.

I missed some discussion on the topic yesterday, but after speaking with emarchak it sounds like there was some debate as to whether or not a UI like this is to quickly add languages is necessary in a situation where most users are going through this process only a few times.

Edit: I posted this without seeing #25. The text box I suppose is was meant for adding custom languages. I wonder if this could be handled by making 'Custom Language' an option in the select list and pushing users to an interface for adding custom languages only when this is chosen.

Amazing work has been done this weekend!
Suscribing!

About this option
"(D) Multiple languages => possibly no problem since we need to have a list of them with settings, enabled ones, default, selection, etc. so if we can improve the UI good, but it is at least OK"

I notice if someone wants to add all languages a lot of clicking on "Add Language" would be required at the moment. (With Facebook Connect it is much easier for a site to go global.)

We could get this by listing all available languages in a VBO like table with the ability to select all instead of the current single dropdown select. Perhaps we could even do away with the "Add Language" screen, and have a list of all available languages with enable disable VBO like checkbox, filtered to show the top ones so it is not overwhelming.
#1288936: Add multiple / all languages easily - currently we can only add languages one at a time Redirected this request here

Thanks Gábor, please see my anwsers:

1. "And really, how common it is for a website to add tens of languages? What do you think?"
I guess it was not common so far, for one reason because it is difficult with the current tools be it Drupal or another CMS. Another reason simply could be it is not needed for lots of websites. That does not mean that many others dont need it and it has to stay as it is. I am sure webmasters that needed lot of languages have looked elsewhere as well.
For example, I understand you work at Acquia, and winning an EU CMS contract would need strong multilingual capabilities. An EU government site has to provide minimum 3 languages, but preferable 20-30 for all the member states. Check out http://europa.eu . How many language options do you see there?

What I am saying is a VBO like setup could be put up there in 2 minutes where users can tick the languages they want and see all the existing languages in a nice filterable views. :) If not that is fine as well, I will just write an imacro for adding all those languages.

2. "Adding a language will not make it magically work without further effort."
That is where user generated content comes into the (or at least my) picture. Just like Facebook asked its users to help translate the interface. I am not building a facebook clone, just a social app that can be used all over the world as an fb app.

Thanks Gábor, I was just presenting two separate use cases, certainly the EU would never crowsdource the translation of its website. :)

Just a final try if you dont mind, feel free to delete this post if you dont like it:
I still think presenting a nice Views with VBO for available languages would make sense, and this view could give more info on the status of a language instead of a single dropdown box. It could have columns like %ready etc.
We could present 2 Vertical Tabs, one for Enabled languages, another one for Available Languages. :) This way there would be no clutter.

Small nit... 'n/a' sometimes means 'not available' and at other times 'not applicable'. Why not replace the 'n/a' text for English in the interface translation column with either "Not applicable' or perhaps even better 'Always present'?

@Gábor - re: #37: So once both patches land, the English row in #35 would have the enabled check box active, an interface translation cell something like '1665/1665 (100%)' and both edit and delete operations? Is my understanding correct? If so, my small nit comment in #36 is Not applicable! LOL

+++ b/modules/locale/locale.admin.inc
@@ -54,8 +52,17 @@ function locale_languages_overview_form() {
+  $form['stat_values'] = module_invoke_all('locale_language_stats');

1) The hook name should not contain an abbreviation... make it hook_[locale_]language_statistics().

2) Same for the $form structure key; why not simply 'statistics'?

+++ b/modules/locale/locale.admin.inc
@@ -54,8 +52,17 @@ function locale_languages_overview_form() {
+  $form['actions'] = array(
+    '#type' => 'actions',
+    'submit' => array(
+      '#type' => 'submit',
+      '#value' => t('Save configuration'),
+    ),
+  );

That's a very unorthodox way for declaring form actions/buttons ;)

$form['actions'] = array('#type' => 'actions');
$form['actions']['submit'] = array(
  ...
);

plz :)

+++ b/modules/locale/locale.admin.inc
@@ -90,23 +100,48 @@ function theme_locale_languages_overview_form($variables) {
+      // Add individual stats columns to language overview.
+      foreach ($form['stat_values'] as $stat_index => $stat_type) {
+        if (is_array($stat_type) && isset($stat_type['#title']) && isset($stat_type['#values'])) {
+          $stat_headers[$stat_index] = $stat_type['#title'];
+          if (isset($stat_type['#values'][$key])) {
+            if (!empty($stat_type['#values'][$key]['path'])) {
+              $row['data'][] = l($stat_type['#values'][$key]['value'], $stat_type['#values'][$key]['path']);
+            }
+            else {
+              $row['data'][] = $stat_type['#values'][$key]['value'];
+            }
+          }
+          else {
+            $row['data'][] = '';
+          }
+        }
+      }
...
+      $row['data'][] = l(t('edit'), 'admin/config/regional/language/edit/' . $key) . (($key != 'en' && $key != $default->language) ? ' ' . l(t('delete'), 'admin/config/regional/language/delete/' . $key) : '');

This complex logic does not belong into a theme function. We can already prepare and build proper renderable array elements in the original $form structure.

Use #type 'markup' and 'link' respectively. Meaning that we end up with a couple of simple drupal_render()s in this theme function.

+++ b/modules/locale/locale.admin.inc
@@ -90,23 +100,48 @@ function theme_locale_languages_overview_form($variables) {
+  // These contained elements we rendered above, so we don't need the markup
+  // wrapper for them polluting the end of the form.
+  drupal_render($form['enabled']);
+  drupal_render($form['site_default']);

This entire form structure looks very weird to me. Normally you'd do $form[$key]['foo'] if your intention is to render the output as a table. That $form['foo'][$key] structure is the primary cause for why this theme function and surrounding code is a lot more complex than it would have to be.

+++ b/modules/locale/locale.module
@@ -48,16 +48,13 @@ function locale_help($path, $arg) {
-      $output = '<p>' . t('This page provides an overview of available translatable strings. See the <a href="@languages">Languages page</a> for more information on adding support for additional languages.', array('@languages' => url('admin/config/regional/language'))) . '</p>';
-      return $output;
+      return '<p>' . t('This page allows a translator to search for specific translated and untranslated strings, and is used when creating or editing translations. (Note: For translation tasks involving many strings, it may be more convenient to <a href="@export">export</a> strings for offline editing in a desktop Gettext translation editor.) Searches may be limited to strings in a specific language.', array('@export' => url('admin/config/regional/translate/export'))) . '</p>';

1) "a translator" -- so, not me, as I'm looking at the page?

2) Overall, this can be heavily shortened and made less wordy. The help/usability team can support here.

3) Let's retain the $output variable (as I'm fairly sure this will turn into 2 paragraphs, if the note is being kept).

+++ b/modules/locale/locale.module
@@ -135,25 +132,17 @@ function locale_menu() {
+    'title' => 'Interface translation',

Wondering whether "User interface translation" wouldn't be more concise (and also better for translation)?

+++ b/modules/locale/locale.module
@@ -135,25 +132,17 @@ function locale_menu() {
+    'page callback' => 'locale_translate_seek_screen', // search results and form concatenated

1) Let's drop the in-line comment.

2) That page callback function name confuses me for more than five years already.

+++ b/modules/locale/locale.module
@@ -135,25 +132,17 @@ function locale_menu() {
+    'weight' => 0,

Normally, we assign -10 here, if we assign something, no?

+++ b/modules/locale/locale.module
@@ -1056,3 +1045,39 @@ function locale_form_comment_form_alter(&$form, &$form_state, $form_id) {
+ * Implements hook_locale_language_stats().

Missing API documentation for this hook.

+++ b/modules/locale/locale.module
@@ -1056,3 +1045,39 @@ function locale_form_comment_form_alter(&$form, &$form_state, $form_id) {
+  // Set up overview table with default values, ensuring common order for values.
+  $stats['#values'] = array();

You need to decide whether this is a hook that returns statistical data and numbers, or whether it is a hook that returns a form section/structure/element(s).

Right now, it appears to want to be both, and that doesn't really make it beautiful.

If you want a hook that extends a form, lemme hand you a present: hook_form_locale_language_overview_alter() ;)

And in fact, yes, this looks like a simple hook_form_alter() use-case to me. There's not really a point in abstracting this data and form construction that much.

+++ b/modules/locale/locale.module
@@ -1056,3 +1045,39 @@ function locale_form_comment_form_alter(&$form, &$form_state, $form_id) {
+      $stats['#values'][$langcode] = array('path' => '', 'value' => t('n/a'));

This "n/a" is actually bogus. It says "not available", but in fact, all strings are available, not the opposite.

+++ b/modules/locale/locale.module
@@ -1056,3 +1045,39 @@ function locale_form_comment_form_alter(&$form, &$form_state, $form_id) {
+      $stats['#values'][$langcode] = array('path' => $path, 'value' => '0/' . $num_strings . ' (0%)');

It would be beneficial to have the raw data/numbers available in array keys.

-3 days to next Drupal core point release.

+++ b/modules/locale/locale.admin.incundefined
@@ -90,23 +100,48 @@ function theme_locale_languages_overview_form($variables) {
+  // These contained elements we rendered above, so we don't need the markup

Should it be "These are the..."? Had to read the comment a couple of times to understand it.

+++ b/modules/locale/locale.moduleundefined
@@ -135,25 +132,17 @@ function locale_menu() {
+    'page callback' => 'locale_translate_seek_screen', // search results and form concatenated

In-line comment on separate line above starting with capital letter?

Otherwise the code style looks good. Can't comment on the logic :)

Revised.

Thanks! Looks ready to fly for me.

Committed to 8.x. Great patch.