CliStrings has nothing to do with localization. The original authors of GFSH simply stored all GFSH strings as static final constants in that class.
As for LocalizedStrings, it was a non-standard way of doing localization and was abandoned by the development team years ago because it's garbage. There was a single developer a decade ago that added it and for some crazy unknown reason decided to invent a new way to do something that was already well-supported in Java. LocalizedStrings has also not been used or kept up-to-date for several years now. 90% or more of new strings visible to Users that were added over the last 5+ years have been coded in place in instead of using LocalizedStrings. My vote is to remove both CliStrings and LocalizedStrings. If we decide that Apache Geode should support localization then we should switch to using Java Localization. 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 > > > >
