From my product background, maintaining a single file is often preferred for localization as mentioned by Mike, the big question, I would ask is how important is localization? If localization is important, then keeping a single or few file(s) will dramatically ease the localization process. So following Jared’s approach might make more work in the future, but it is certainly sound if there is no localization. This may also be an opportune time to review localization strategies within the code.
Thanks, Mark > On Oct 19, 2017, at 3:28 PM, Bruce Schuchardt <bschucha...@pivotal.io> wrote: > > +1 I thought we decided long ago to do this. We also have > LocalizedStrings.java and it looks like some folks are still adding new > StringIDs to it as well. > > > On 10/19/17 3:13 PM, Nick Reich wrote: >> +1 for moving those messages out of CliStrings if at all possible and >> placing them where they are used. In my experiences with those strings, I >> have rarely if ever seen them reused across classes, so they really should >> belong in the class they are used by. >> >> On Thu, Oct 19, 2017 at 3:05 PM, Jared Stewart <jstew...@pivotal.io> wrote: >> >>> I wanted to kick off a discussion about the usage of CliStrings. For >>> those unfamiliar, it’s a java class that contains about ~3000 lines of >>> String constants and has a javadoc explaining that it is an attempt at i18n >>> localization. Does anyone know if this localization is actually >>> implemented in practice? >>> >>> If not, I would like suggest that we try to move away from this pattern >>> going forward. We have ended up with many constants in CliStrings like >>> this: >>> CliStrings.CREATE_REGION__MSG__ONLY_ONE_OF_REGIONSHORTCUT_ >>> AND_USEATTRIBUESFROM_CAN_BE_SPECIFIED >>> The constant is only used in CreateRegionCommand, so I would be happier to >>> see it as a member of CreateRegionCommand (where there would be no need for >>> the unwieldy "CREATE_REGION__MSG__” prefix) unless there is localization >>> being done which I am unaware of. >>> >>> Thoughts? >>> >>> Thanks, >>> Jared >
