[PATCH] Notifications use field name instead of label for custom fields

[jflorian@…]

While it is very nice to have the custom fields appear in the notification mail, it would be better if they used the label given to them instead.

Often the field name is an abbreviation that can be quite confusing for most of our users whereas the labels would be something they'd recognize immediately.

[jflorian@…]

Sorry, forgot to set the version to what we're actually using.

[trac_dev at mail.ru]

add to cc

[osimons]

It is exactly as we do it on the regular fields also for web ui, so either we need to change the current practice for all fields, or else this won't make sense.

However, with current i18n effort underway, I suppose this is also related to that as it for many will make the default labels and fieldnames very different. Currently all labels and field names are the same (except capitalization) - that won't be the case later.

[Christian Boos]

… not to mention the fact that currently it's the same mail sent to everyone, and that with i18n we probably need to partition the recipient list according to their language and send as many differently translated mails as needed.

[Christian Boos]

#6854 was closed as duplicate

[hju@…]

while localization is an very interesting feature, I'm much more interested on the basic defect Notifications use field name instead of label for custom fields at the moment. It's exactly what I was looking for at the moment.

[hju@…]

Taking a brief look in the code, I implemented a little patch to change to label instead of names for all fields in notification.

Its not the overall solution, just a "hard change" to label.

The patch concerns notification.py:

trac/ticket/notification.py

@@ -156 @@
-         for f in [f['name'] for f in fields if f['type'] != 'textarea']:
-             if not tkt.values.has_key(f):
+         for f in [f for f in fields if f['type'] != 'textarea']:
+             if not tkt.values.has_key(f['name']):
                  continue
-             fval = tkt[f]
+             fval = tkt[f['name']]
              if fval.find('\n') != -1:
                  continue
              idx = 2 * (i % 2)
-             if len(f) > width[idx]:
-                 width[idx] = len(f)
+             if len(f['label']) > width[idx]:
+                 width[idx] = len(f['label'])
              if len(fval) > width[idx + 1]:
                  width[idx + 1] = len(fval)
              i += 1
@@ -175 +176 @@
          for f in [f for f in fields if f['name'] != 'description']:
              fname = f['name']
+             flabel = f['label']
+             if not flabel:
+                 flabel = fname
              if not tkt.values.has_key(fname):
                  continue
              fval = tkt[fname]
              if f['type'] == 'textarea' or '\n' in unicode(fval):
-                 big.append((fname.capitalize(), CRLF.join(fval.splitlines())))
+                 big.append((flabel.capitalize(), CRLF.join(fval.splitlines())))
              else:
-                 txt += format[i % 2] % (fname.capitalize(), fval)
+                 txt += format[i % 2] % (flabel.capitalize(), fval)
                  i += 1

The patch ist not overall tested, but implemented in our environment (0.11) an running properly (till now).

[dalemiller@…]

This change should not be limited to the email notifications. The label for custom fields should be used in the comments section when displaying information from the ticket_change table. Trac should also use the custom label in the timeline displays. A good example of this is with the Master Tickets Plugin. If one prefers to change the labels of "blockedby" and "blocking" to something else it can be confusing when the timeline and ticket comments use the names and not the labels.

[dale.miller@…]

correcting username in cc field. (it would not let me remove my incorrect entry)

[ebray]

I'm attaching a somewhat more complete patch for this. It uses the field labels (if available) in the ticket changelog, ticket diffs, reports, and queries. Didn't touch RSS or any of the export formats—the export formats in particular should be left alone for what I think should be obvious reasons.

The patch involves creating these silly little field_labels dicts everywhere, but I don't feel too bad about it now that the fields are cached.

I also refactored TicketSystem._get_ticket_fields() so that the labels for all of the built in ticket fields can be more easily translated. I generated a new messages.pot, but I figure there's no reason to include that in the patch.

[ebray]

Patch to use field labels when displaying field names in the ticket changelog, ticket diffs, the query page, the report page, and e-mail notifications.

[Christian Boos]

It's a good first step, but the patch needs to be fixed to use N_ when storing the label field names into the fields (a no-op, we're just marking the string for translation). Otherwise you'd store the translation for whatever language was the one of the first request which triggered the caching. Then those label keys have to be translated dynamically when processing a request, with gettext(field_labels[f]) (not _ here, as there's nothing to extract).

[Christian Boos]

Ping. Any chance to get an update on the patch?

[ebray]

Sorry for the delay on this. Updated patch with cboos's suggestions (there were a few spots in trac.ticket.api where _() needed to be replaced with N_() so that translated strings aren't put in the cache). I also updated a couple tests so that they work with these changes.

[Christian Boos]

The gettext call is missing, and having that many field_labels dicts look suboptimal, I'll have a more detailed look.

Still, thanks for the update!

[Christian Boos]

Applied Erik's patch in r8523, refactored it a bit to call gettext appropriately in r8524.

Further related i18n tweaks in r8525 and r8527.

Follow-up needed for the Custom Queries.

[Christian Boos]

Labels translated in the Custom Query as well with [8534].

There's still an issue with the Javascript there, adding a new filter still adds the name of the filter instead of the label, but I didn't want to touch the Javascript for now (see #7111).

If there's another place where the (translated) labels should have used, please reopen.

[Remy Blank]

The translation of ticket field labels has been fixed in [8604].