When I explored this issue previously (Canada always wants French and English)
an inline approach was recommended to provide all the translations at the same
time … cannot quite figure out how this works for a GetCapabilieis document
(they may of just been having me on):
<title>Hello World<span xml:lang="it">Ciao Mondo</span></title>
I assume just encoding something like the above does not do it for you?
GUI wise I can think of a compromise between your two suggestions:
Next to each translatable field indicate which translations are filled in:
Title: Hello World
fr DE [EN] es it
(So in the above we have english and german text for Hello World, and english
is currently displayed)
Clicking on a language can switch the whole page over to that language,
including the current field, leave the field empty, or offer "the default"
which will otherwise be used if a translation is not proved (as shown below).
Title: Hello World
fr DE EN es [it]
(In the above we still have english and german text for hello world)
The translation can be typed in to replace the default:
Title: Ciao Mondo
fr DE EN es [IT]
(We have now filled in Italian)
When editing it may be feasible to show all the translations for that field as
a tooltip style overlay.
--
Jody Garnett
On Friday, 22 February 2013 at 5:11 AM, Andrea Aime wrote:
> Hi,
> recently we started thinking on how to support internationalized OWS services
> in GeoServer, and I wanted to share some considerations with the community
> and gather some feedback (btw, no, don't hold your breath on it just yet,
> this is just preliminary
> research).
>
> The first bit would be to make the capabilities documents generated by
> GeoServer
> respect the lang parameter and return caps documents in a specific language.
> While the layer/feature type names would not change, this would require
> metadata
> like title and abstract, as well as some parts of
> the service description to be available not as simple strings, but as list of
> values
> in different languages (maps).
> Keywords already seem to support the language concept, and I'm wondering if
> metadata links may need internationalization support too.
>
> Configuration wise I'd see this as a change from using String to use GeoTool's
> own InternationalString interface, XML storage wise the change would be
> similar,
> e.g. from:
>
> <title>buildings</title>
>
> to:
>
> <title>
> <value lang="en">buildings</value>
> <value lang="it">edifici</value>
> <value lang="fr">batiments</value>
> </title>
>
> The XStream reading code would be backwards compatible and associate
> the eventual single string to the default language.
>
> And oh, there would be some place in GeoServer (global settings I guess)
> where the list of supported languages would be made configurable.
>
> GUI wise I'm picturing a situation in which multilanguage fields would appear
>
> in all the different supported languages at the same time.
> The idea of having some sort of combo, either local to the text field or the
> page, allowing to switch the current language, has been taken into
> consideration
> as well, but there are downsides:
> - the field local one is a bit tedious, as one would have to switch it for
> every field
> - the page global one makes it difficult/impossible to locate the few fields
> that need to be
> internationalized
> - either case would make it difficult to see if all the languages have been
> filled in.
>
> A setup where the field is repeated for all the configured languages, each
> version clearly
> labelled with the language, is better in all the above respects, even if it
> would eat quite
> a bit of space.
> Maybe we could have only the configured languages appear, with a button to
> add a
> field for any of the missing languages... but I mean, the point of having a
> internationalize
> server is really to fill all the metadata in the various languages anyways,
> so one would
> have to expand all the languages anyways.
>
> Internationalizing the other requests presents greater difficulties: GetMap
> should
> report labels in the requested language, GetFeatureInfo and GetFeature should
> return strings in the proper language.
> Now, I imagine a database structure having columns such as name_en,
> name_fr, name_it, and GeoServer needs to expose those as "name" picking
> the right column from the data source based on the currently requested
> language.
> And we'd need to make this "attribute grouping" configurable too from the UI.
>
> I believe this could be doable using the TransformFeatureStore I've been
> working
> on last year, now available as a community module in GeoTools,
> by creating a filter function that is language aware... special optimizations
> for
> this one would be nice too, so that the code only ends up reading the string
> we need from the database.
> The GUI for the name field would then associate it with a CQL expression like:
> "internationalize(env('lang'), 'en', name_en, 'fr', name_fr, 'it', name_it)"
> (maybe for this one a custom GUI could be made to simplify the setup...).
>
> Making sure that also all filters work fine against these fields, and be
> efficient
> too, might prove to be "loads of fun" (TM) :-p
>
> Anyways, what do you think? Opinions welcomed
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
>
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> (mailto:[email protected])
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
