On Job Overview page use 'Title' of source language instead of 'Label'

A job can have multiple job items, so we can't use "the" node title easily.

I think there is already a similar issue to this one. What might be possible is using the title of the first job item + " and X more" as a title?

Ah, not the same, but related #1606400: Allow translator plugins to customize job labels

I like that idea.

Added the suggestion to the related ticket: #1606400: Allow translator plugins to customize job labels. Can we close this one as a duplicate?

Also, i haven't started on 1606400 yet, so please take it if you want. I can get to it in a week or so, if not.

I suggest to improve the default label in this issue and keep the other one open for what it says in the title, in case we still want to add a possibility for this at a later point, if there still is a reason to do so.

Follow-up to #1606400-5: Allow translator plugins to customize job labels, this belongs in this issue.

MyGengo can only track single texts, it is a technical limitation. This issue has nothing to do with Mygengo. It also has nothing to do with reviews.

A job can have multiple job items (e.g. multiple nodes). E.g. by using the node source overview that allows you to translate multiple nodes in one step (Again, in Drupal. Mygengo tracks this differently and can only do so).

Examples:

* Current default job label (no matter how many nodes): From English to Japanese
* Proposed label with a single job item/node called "Title A" (has *nothing* to do with the amount of fields): "Title A to Japanese"
* Proposed label with 7 job items/nodes, the first called "Title B": "Title B and 6 more to Japanese".

Again, this has nothing to do with MyGengo or any other translator, that is a completely different topic.

Here's a proof of concept.

I like how this looks visually, but it doesn't scale, it means that we load all the items of all jobs displayed in the overview.

I'm not sure yet what to do about this. Possibly actually storing the generated label when saving/submitting the job.

Wrong issue. Moved to #1715166: UI: Job label (the way of functionality)

Now that the other issue is fixed and we save the default label, this patch actually isn't a problem anymore.

Re-rolled and added another check that generates the default label when it's empty before saving. Does not yet cover jobs created through the API, that's a bit tricky. As we don't know when to re-generate the default label, so that's an information we'd need to save.

Here's a re-roll that should fix the test failures.

Not sure yet what exactly we should use for the label.

Right now, the patch does "Node Title (English to Geman)" or "Node Title and 3 more (English to German)". This is a bit long and the languages are duplicat

Alternatives would be:

- Just "Node Title" or "Node Title and 3 more" (we could still add the languages just for the job page title)
- "Node Title to German" or "Node Title and 3 more to German"
- Something else?

Applied and tested. Works fine and is much better than the original as it makes it at least possible to identify a job, even if you forgot to set a specific label by hand.

Additional suggestion:

"Node Title to German (Date and Time created in short form)" or "Node Title to German and 3 more (Date and Time created in short form)".

I see no reason to add "from language A to language B" in the title.
Same for the creation date.

Note also, we have the number of items available as columns. "and ... more" also looks repetitive.

We have all that in separate fields and can display it in columns in the overview.

I think i would try to create a title field representing the content like you started:
So possibly i would loop over the items and add more of them as long as the resulting title is below some # of characters...

Title 1, Title 2, ...

Dunno :-) but i would just focus on the title.

The job overview isn't the only place where we use the job label, it is also used in page titles, breadcrumbs, the job item page and more places like that, where we don't have additional information. Oh, and we don't display the item count on the job overview page.

And I also prefer "title and x more" over Title, Title, Title because the max # of characters is relatively low, we have a lot of columns in the table and not that much space for the label.

I currently tend towards leaving out the language but adding it manually to the page title, together with the current state (which is what we already do).

+++ b/includes/tmgmt.entity.incundefined
@@ -1010,7 +1010,18 @@ class TMGMTJob extends Entity {
+    if (count($items) == 1) {
+      return t('@title (@source to @target)', array('@source' => $source, '@target' => $target, '@title' => reset($items)->getSourceLabel()));
+    }
+    elseif (count($items) > 1) {
+      return t('@title and @count more (@source to @target)', array('@source' => $source, '@target' => $target, '@count' => count($items), '@title' => reset($items)->getSourceLabel()));
+    }

Any reason against using format_plural() here?

+++ b/includes/tmgmt.entity.incundefined
@@ -1010,7 +1010,18 @@ class TMGMTJob extends Entity {
+      return t('@title and @count more (@source to @target)', array('@source' => $source, '@target' => $target, '@count' => count($items), '@title' => reset($items)->getSourceLabel()));

When I have 3 items, it currently says ".. and 3 more", which actually implies 4 items in total. We need to subtract one from the count.

Attached patch fixes both issues above, and also removes the (@source to @target) porition from the default label and moves it to the site title (next to the state), as suggested above.

+++ b/ui/includes/tmgmt_ui.pages.incundefined
@@ -255,10 +252,22 @@ function tmgmt_job_form($form, &$form_state, TMGMTJob $job, $op = 'edit') {
+  $language_label = t('@source to @target', array('@source' => $source, '@target' => $target));
+
+  // Set the title of the page to the label and the current state of the job.
+  drupal_set_title($job->label() . ' (' . $language_label . ', ' . $wrapper->state->label() . ')');

This should probably be a single t() string, something like '@label (@source to target, @state').

Wondering if we want a label callback in hook_menu() that does this, but the problem is that especially the language part is dynamic and for a new job, uses the default, something that we can't re-created in a label callback.

So probably just leave it like this for now.

+++ b/ui/includes/tmgmt_ui.pages.incundefined
@@ -482,6 +491,10 @@ function tmgmt_job_form_submit($form, &$form_state) {
+  // Make sure that we always store a label as it can be a slow operation to generate the default label.
+  if (empty($job->label)) {
+    $job->label = $job->label();

Comment is > 80 characters.

The test failures are very likely unrelated.

Attached patch fixes the comment and t() call.

I agree that test failures look unrelated.

Hm. While those tests do look unrelated, they only fail here. Will need to have a look before I can commit this. Or you could, if you have time :)

#21: better-default-label-1620380-21.patch queued for re-testing.

Hm, the failing test is not using the TMGMTJobItem::getData() method but accessing TMGMTJobItem::$data directly... my guess is that calling TMGMTJob::getItems() in the default label method causes things to only load partially. Let's see if attached patch solves it.

It was a problem with the static cache. Something called getLabel(), which called getItems() so they were in the entity cache. This should pass.

@cgalli, can you do another test with this?

Installed and tested. Runs fine.
With this, jobs can be identified much better

Great, commited and pushed.

Yei! :)