+1 for removing it based on Dan's reasoning. Sarge
> On 20 Oct, 2017, at 13:59, Dan Smith <dsm...@pivotal.io> wrote: > > +1 for removing it. > > I do think it would be nice if we add localization in the future. But > I don't really like the idea of leaving stuff in our code just in case > we decide to implement a feature in the future - we might not even > want what we left in there! In this case even with localization we > might want to move these constants into their specific command classes > anyway - the constant might just look up the localized string instead > of being hardcoded. > > -Dan > > On Fri, Oct 20, 2017 at 9:57 AM, Anilkumar Gingade <aging...@pivotal.io> > wrote: >> As others mentioned this was done to support localization in the product; >> this was driven from customer request; mainly from AMEA customers... >> Now being open source; to build a wider community, Localization may become >> a key requirement...Having a framework will help community to build on >> that... >> >> -Anil. >> >> >> On Thu, Oct 19, 2017 at 4:32 PM, Mark Hanson <mhan...@pivotal.io> wrote: >> >>> 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 >>>> >>> >>>
