On Fri, Apr 10, 2020 at 10:32 AM Andrea Aime <andrea.a...@geo-solutions.it> wrote:
> Hi, > I'm looking into ways for internationalizing layer titles and abstracts. > Right now title and abstract are String > objects, appear as flat properties in the REST API and in configuration > storage, and have lots of call > points in the code (74 for title, 49 for abstract, including both Layer > and Resource property exposure). > > It would be tempting to turn them into InternationalizedString (or an > analogous class), but the API breakage > would be significant, and would likely prevent a backport (something that > might be a deal breaker funding wise). > 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. Multi-lingual support is such a bother I would like to think through it carefully; we did setup InternationalString deliberately to keep this idea from making our API difficult to maintain. > 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. Another minimal disruption approach is if fields contained optional elements inside title. In the default case (with no internationalization) existing REST API applications would continue to function. > 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? 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. > How does this sound? > It is an important issue, and any improvement here will be of great benefit to the project. > > Cheers > 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 > <https://www.google.com/maps/search/Via+di+Montramito+3%2FA%0D%0A55054++Massarosa?entry=gmail&source=g> > (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 >
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
