+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 >> > >> >>
