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