Good point, it would set a precedent for new Resources Dan
From: Andrea Aime <andrea.a...@geo-solutions.it> Sent: 11 April 2020 13:50 To: Daniel Singh <dannybwoy2...@hotmail.com> Cc: Geoserver-devel <geoserver-devel@lists.sourceforge.net> Subject: Re: [Geoserver-devel] Some toughts on adding i18n to layers titles and abstract Interesting idea... at one point we'll have to version the REST API, there has been discussion about it, but I'm not sold on starting to version the single resource, if this approach takes hold we might see soon a lot of Resorce2, Resource3, spread around the API. Maybe it could be a parameter on the same resource... what I was suggesting would have made most of the existing clients just work ignoring the new object included in the configuration (adding properties happens all the time, the REST API is not using a XML schema, so we don't have issues adding elements) Cheers Andrea On Sat, Apr 11, 2020 at 1:08 PM Daniel Singh <dannybwoy2...@hotmail.com<mailto:dannybwoy2...@hotmail.com>> wrote: Would it make it easier if you created another REST endpoint e.g. …/Layers2 or .../LayersExt which allowed people to use internationalised string if they wanted? Then everything internal could use internationalised string and you just convert at the edge. Dan From: Andrea Aime <andrea.a...@geo-solutions.it<mailto:andrea.a...@geo-solutions.it>> Sent: 11 April 2020 09:44 To: Jody Garnett <jody.garn...@gmail.com<mailto:jody.garn...@gmail.com>> Cc: Geoserver-devel <geoserver-devel@lists.sourceforge.net<mailto:geoserver-devel@lists.sourceforge.net>> Subject: Re: [Geoserver-devel] Some toughts on adding i18n to layers titles and abstract On Fri, Apr 10, 2020 at 10:27 PM Jody Garnett <jody.garn...@gmail.com<mailto: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<mailto:Geoserver-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Regards, Andrea Aime == 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
