Andrea I am interested in seeing the best solution implemented (best being for the long term health of the codebase).
If you are choosing between several approaches please keep in mind our offer of putting some time towards this activity. This task has also gathered a lot of response so there may be interest from others in taking part also. I will leave the specific technical tradeoffs to proposal writing; just wanted to be very clean on the offer of assistance. -- Jody Garnett On Sat, 11 Apr 2020 at 01:44, Andrea Aime <andrea.a...@geo-solutions.it> wrote: > On Fri, Apr 10, 2020 at 10:27 PM Jody Garnett <jody.garn...@gmail.com> > wrote: > >> This issue is very much of interest to GeoCat and our customers; if you >> feel that using InternationalString would result in a more maintainable >> codebase in the long run, I would be happy to join you in a proposal to >> make this API change, and assist with untangling any conflicts / backports >> etc...during the period of transition. >> > > This approach would has a significant implementation overhead. But, given > you have a business interest for it, I'd be interested in you to joining > the implementation, and handling the code changes that would result from > this approach, while I work on the OGC service support. > > >> REST wise it would also make existing clients fail, if they stumble into >> an internationalized version of title and abstract >> >>> (which I supposed would show up inside the same tags, nested <value >>> lang="xy">title in lang</value> elements). >>> >>> I was wondering about doing something that would be more transparent to >>> users. How about a: >>> >>> - defaultLang property, indicating the language for the existing >>> title and abstract >>> - alternateTitles, a InternationalizedString >>> - alternateAbstract, a InternationalizedString >>> >>> This way they'd be new fields, could have defaults, and existing >>> applications that are not aware of them can blissfully >>> ignore them most of the time. >>> >> >> I do see the attraction on adjusting the XML format on disk in the way >> you describe. >> >> > The "on disk" side is under our control, it is not a problem, we can make > it backwards compatible. > The REST API change will break existing clients instead. This makes the > approach non backportable, > which is a likely a deal breaker. > > >> >> >>> The GUI would probably have a checkbox to enable internationalization, >>> and in that case, it would show a table based >>> editor with languages and values. >>> >> >> I have some recent experience in exactly this kind of trade off :P >> Would that checkbox be per field, or once for the entire document? >> > > One GUI checkbox that enables the internationalization in the two fields > where internationalization makes sense (and could enable it in more, should > they appear). > Each field (title, abstract) would have its own little entry table, > something similar to the layer group editor. > > >> I was thinking for users the decision to use internationalization is >> likely to be made once, rather than on a field by field basis. GeoNetwork >> has a multi-lingual field which may be worth duplicating (see example >> here >> <https://www.geonetwork-opensource.org/manuals/trunk/eng/users/user-guide/describing-information/multilingual-editing.html> >> ).Workflow: Enabling >> multi-lingual support once (by setting a default language at the top of the >> form) which would enable language selection (under the InternationalString >> fields). Resulting in minimal user interface disruption. >> > > Not sure I can replicate that with Wicket, seems difficult. But since you > clearly have a business interest, maybe you are interested in donating also > a similar GUI? > > Cheres > Andrea > > == > > GeoServer Professional Services from the experts! Visit > http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf > Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa > (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 > http://www.geo-solutions.it http://twitter.com/geosolutions_it > ------------------------------------------------------- *Con riferimento > alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - > Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni > circostanza inerente alla presente email (il suo contenuto, gli eventuali > allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i > destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per > errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le > sarei comunque grato se potesse darmene notizia. This email is intended > only for the person or entity to which it is addressed and may contain > information that is privileged, confidential or otherwise protected from > disclosure. We remind that - as provided by European Regulation 2016/679 > “GDPR” - copying, dissemination or use of this e-mail or the information > herein by anyone other than the intended recipient is prohibited. If you > have received this email by mistake, please notify us immediately by > telephone or e-mail.* >
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
