Skip to main content
Open

AttributeValidator: localizable messages

Related products:Transformers
  • February 25, 2016
  • 4 replies
  • 45 views

david_r
Celebrity

The AttributeValidator currently outputs the results in English. Since it is sometimes necessary to provide localized or custom messages, I suggest that the AttributeValidator include "message numbers" in addition to the full message, much like Oracle does with error messages (ORA-nnnn):

Currently: Attribute 'abc' with value 'a' fails check for Type is 'INT'

Suggested: Attribute 'abc' with value 'a' fails check for Type is 'INT' (FME-AV-1234)

Where 1234 would be a unique integer that identifies the message.

To translate, one could then search for FME-AV-nnnn rather than a specfic wording interspersed with attribute names etc.

4 replies

geosander
Forum|alt.badge.img+7
  • February 25, 2016

In general, I think error codes would be a good idea!


fmelizard
Safer
Forum|alt.badge.img+22
  • Safer
  • February 25, 2016

We've been trying to do this with the <Rejected> ports and the fme_rejection_code -- standardize on a small set of codes that are at least largely consistent and potentially localizable. Doing a similar thing for AttributeValidator is not a bad idea at all.


djmcdermott
Contributor
Forum|alt.badge.img+7
  • Contributor
  • March 10, 2016

I have started looking at the Attribute Validator following the How to Optimize GIS Workflows webinar. I agree that an additional column to provide custom error messages/codes would be very useful. It would allow me to use a TestFilter to split the errors into separate workflows.

Additionally, it could have the option to expose the validation as separate output....


davtorgh
Contributor
Forum|alt.badge.img+12
  • Contributor
  • December 22, 2020

As stated by @djmcdermott, an additional column to provide custom error codes would be very useful. With an AttributeValueMapper, for example, error codes could be used to give back localized or custom messages read from a lookup table.