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
