Yep, a patch would be welcome (I noticed this yesterday when testing i18n).
Also it is really obvious if you read the docs, but of course I did not read carefully enough. Turns out in a bit of classic WMS goodness AcceptLanguages is a KVP property; and not determined by http header. Jody On Mon, Jan 31, 2022 at 6:52 PM Gabriel Roldan <gabriel.rol...@gmail.com> wrote: > Indeed, looks like misbehavior in both cases IMHO though. > > Can't speak for the PSC, but my community vote goes for getting rid of > that hardcoding. > > Cheers, > > On Mon, 31 Jan 2022 at 20:04, Justin Deoliveira <jdeol...@gmail.com> > wrote: > >> Thanks Gabriel, nice to hear from you too! >> >> You're right in that for layer groups this has always been the behavior. >> What I think happened in the recent i18n refactor was that some code was >> refactored to share the encoding of the title and abstract for LayerInfo >> and LayerGroupInfo, and in doing so changed the behavior for single layers >> (non layer-group). I believe this was the change in that commit that did it: >> >> >> https://github.com/geoserver/geoserver/commit/3ea0b9817a4f1264c815d874ae612bf5e6d6fea4#diff-ce88fe929a6cf41c007f131c83eae16caedb0e849ccc0ccfe2ddcec7bdaead3cL1003 >> >> >> On Mon, Jan 31, 2022 at 11:33 AM Gabriel Roldan <gabriel.rol...@gmail.com> >> wrote: >> >>> Hey man, nice to hear from you. >>> >>> That seems strange actually, but couldn't track down when it was added, >>> it's already there at the first >>> git commit (44bacafcf1) in June 2011, so it's from the svn days. >>> >>> Wait, yeah, been like that since 2007 at least: >>> https://github.com/geoserver/geoserver-history/commit/9ab43af58a#diff-26d7a2ab35bebf3788e69ccb99b9722baf3a0fdb72f65278c620b6a80803dc49R964 >>> >>> That said, it makes all sense to me to remove it and emit an empty >>> element instead. >>> >>> Cheers! >>> >>> On Mon, 31 Jan 2022 at 14:07, Justin Deoliveira <jdeol...@gmail.com> >>> wrote: >>> >>>> Howdy folks, >>>> >>>> First off amazing job on the project, great to see GeoServer thriving >>>> and be such a robust and stable tool, kudos to all of the core developers >>>> for their hard work. >>>> >>>> I have a question about a change that I am seeing after upgrading a >>>> Geoserver instance from a 2.18.x to the latest stable 2.20.x, with regards >>>> to layer abstracts in the WMS capabilities document. I wanted to check here >>>> whether it's considered a bug or not before I file a ticket, or work on a >>>> patch. The issue in question I believe traces back to the recent work done >>>> to allow for i18n of the capabilities document: >>>> >>>> - Pre-change, when a layer had no abstract the element would show up as >>>> empty in the capabilities document. >>>> - Post-change, the abstract gets a default value of "Layer-Group type >>>> layer: <layerName>" >>>> >>>> I guess my ultimate question is whether this is desirable behavior? I >>>> am thinking an abstract referencing "Layer-Group" in the cases where it's >>>> not a layer group is perhaps an oversight. >>>> >>>> The bigger question is whether it's desirable to have a fallback value >>>> at all. In the case of the project I am working on there is an application >>>> that displays those abstracts to the user, which after the upgrade started >>>> to get a bit confusing with all of the default abstracts in there. I >>>> imagine there are GIS clients and web applications powered by GeoServer >>>> that do the same, which is why I wanted to ask. >>>> >>>> Thanks GeoServer crew! >>>> >>>> Justin >>>> >>>> _______________________________________________ >>>> Geoserver-devel mailing list >>>> Geoserver-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>>> >>> >>> >>> -- >>> Gabriel Roldán >>> >> > > -- > Gabriel Roldán > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > -- -- Jody Garnett
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
