Dialogs and forms can currently both specify a label and description.
They are displayed in the same location. To be confirmed: the dialog's should have priority, so it can override a more generic form label.

We current have hacks in place in both FormDialogPresenterImpl and FormBuilder - they check if the label/description's value "is a message key" by looking for dots and spaces. This is completely unreliable. If the value "is a key", then we don't use to override an otherwise specified label.

Other possibilities:

• look at undecorated value
• put some of this logic in the key generators (not convincing)
• don't overwrite if there's already a value (dialog's label is set first, so FormBuilder should never overwrite it)
  • this would only work if we'd explicitly set all dialog labels
• add a feature to i18nsystem such that a form's label and description could be marked as optional (@I18nText(optional=true))
  • TranslationService could return "" instead of a missing key for these. But doesn't that make it hard to figure keys out ?

In STK, our forms have a label, dialogs rarely do (since this is new)