Same here. Internationalization is often implemented as properties files/resources, where you possibly load in a file based on the system setting for Locale (like processor_names_en_US.properties). If we were to do internationalization this way (i.e. a non-code based solution, which is more flexible), then ironically displayName() might/should be deprecated in favor of using the value of name() as the key in a properties/lookup file; the corresponding value would be the appropriate locale-specific "display name".
Brandon's links show this approach, I have seen this i18n approach on other projects/products and it seems to work pretty well. Regards, Matt On Fri, May 6, 2016 at 9:11 AM, Joe Witt <joe.w...@gmail.com> wrote: > I share Bryan's perspective. > > On Fri, May 6, 2016 at 9:05 AM, Bryan Bende <bbe...@gmail.com> wrote: >> I might just be resistant to change, but I am still on the fence a little >> bit... >> >> In the past the idea has always been you start out with name, and if you >> later need to change what is displayed in the UI, then you add displayName >> after the fact. >> >> It sounds like the issue is that a lot of people don't know about >> displayName, so I am totally in favor of increasing awareness through >> documentation, >> but I'm struggling with telling people that they should set displayName as >> the default behavior. >> >> For code that is contributed to NiFi, I would expect the PMC/committer >> doing the review/merging to notice if an existing property name was being >> changed and point that out in the review. >> If it was someone else's custom NAR, or even made it through the review, I >> think what happens is that the flow starts up and the processor/component >> becomes invalid because it now has an unknown property. >> This is the same behavior when we remove a property from an existing >> processor and someone upgrades, and we deemed this acceptable behavior for >> that scenario. >> >> The internationalization aspect could possibly sell me more, but I think I >> would need someone to explain how internationalization would be >> implemented, and how setting the displayName helps. >> What Brandon described makes sense to me because it is something outside >> the Java code, which is different then saying all PropertyDescriptor >> instances need name and displayName. >> >> -Bryan >> >> >> On Fri, May 6, 2016 at 8:44 AM, Brandon DeVries <b...@jhu.edu> wrote: >> >>> +1. I think being able to move the displayName out of code an into config >>> / ResourceBundle will make it much easier to support i18n[1]. If no config >>> is provided, the name is the default... otherwise, the name displayed is >>> determined by the locale. Updating the mock framework to complain about >>> the absence of a ResourceBundle will encourage adoption, and we'll >>> gradually work our way to not being English only. >>> >>> Brandon >>> >>> [1] https://docs.oracle.com/javase/tutorial/i18n/intro/quick.html >>> >>> On Thu, May 5, 2016 at 11:46 PM Adam Lamar <adamond...@gmail.com> wrote: >>> >>> > On Tue, May 3, 2016 at 12:09 PM, Andy LoPresto <alopre...@apache.org> >>> > wrote: >>> > >>> > > As a result of some conversations and some varying feedback on PRs, I’d >>> > like >>> > > to discuss with the community an issue I see with PropertyDescriptor >>> name >>> > > and displayName attributes. I’ll describe the scenarios that cause >>> issues >>> > > and my proposed solution, and then solicit responses and other >>> > perspectives. >>> > >>> > Andy, >>> > >>> > I'd be +1 on this as well. I think the power of this approach will >>> > become more clear over time, and some of the automation will make it >>> > possible to more widely enforce. >>> > >>> > What do you think about a mixed mode where config reading code can >>> > fetch the property value with either the name or display name as the >>> > key, defaulting to the name if it is present? A sample read of >>> > flow.xml.gz might look like this: >>> > >>> > * Processor asks for value of MY_CONFIG_PROPERTY >>> > * Configuration code looks for key "my-config-property", returns if >>> present >>> > * Configuration code looks for key "My Config Property", returns if >>> present >>> > * On finding no valid key, configuration returns blank/default/null >>> > value (whatever is done today) >>> > >>> > On configuration write, the new attributes could be written as the >>> > normalized name (instead of display name), to allow processors that >>> > have made the switch to start using the normalized name field and >>> > start taking advantage of the new features around it (e.g. >>> > internationalization). Perhaps a disadvantage to this approach is that >>> > it auto-upgrades an existing flow.xml.gz, making it difficult to >>> > downgrade from (for example) 0.7 back to 0.6. >>> > >>> > A strategy like this (or something similar) might help speed adoption >>> > by making the process a bit smoother for existing flow.xml.gz files >>> > and easier to upgrade processors incrementally. At 1.0, display names >>> > as configuration keys could be dropped, and the upgrade path for users >>> > on old 0.x releases would be to upgrade to the latest 0.x before >>> > making the jump to 1.0. >>> > >>> > Cheers, >>> > Adam >>> > >>>
