fortify
Output: Should tree format output formatted/internationalized attribute names?
The -o tree option outputs data in tree format using the original JSON property names. Since this is supposed to be a human-readable format, we should probably output formatted and possibly internationalized names instead.
Table output format already has support for this, so we could duplicate this behavior. However, table output currently uses flattened property names to look up corresponding headers in the resource bundle, but tree format supports both flattened and unflattened trees.
To be consistent with other places where property names are used, the resource bundle lookup should use unflattened property names for both table and tree outputs. This basically means that AbstractFormattedRecordWriter needs to keep a mapping between (optionally) flattened property names and the original property name, such that we can do a resource bundle lookup based on either unflattened or flattened property name.
To implement this, FlattenTransformer should probably keep track of the renamed/flattened properties, such that AbstractFormattedRecordWriter can store this mapping between optionally flattened property name and original property names in an instance variable. AbstractFormatterRecordWriter should then add a getHeaderName(String optionallyFlattenedProperty) method that looks up the original property name based on the given optionally flattened property name, and then uses the original property name to look up the header in the resource bundle. If no resource key is found, PropertyPathFormatter::humanReadable should be called to produce a (somewhat) human-readable header name. Both TableRecordWriter and TreeRecordWriter would then simply call getHeaderName() to get the internationalized/formatted header name.
How do you feel about a generic -i or --i18n option for the output that allows the user to simply enable internationalized attribute names, regardless of what output format a user chooses?
I'd like to limit the number of generic options. If we implement this functionality, i18n will simply be enabled when outputting to tree format, just like we do for table output. I don't see much value in making this configurable. If we do want to make this configurable, we should do so through config commands, where a user can configure whether he wants to have internationalized or English table/tree output, but I don't see much value in such a feature.
For now, we only support English language anyway, the fcli config commands for changing language have been hidden. So, until we implement proper multi-language support, there's no need to work on this issue.