[Mapserver-inspire] options/questions regarding multi language support

[Stefan Leopold]

hello

in the following I try to summarize the different options available when
implementing multi language support for the inspire view service, hope you
can provide me some hints about your preferences, pros/cons, foreseeable
problems during implementation,... as it definitely affects client usage
too

-----------------------------------------------------

as far as I understand, we have to differentiate between two types of
"data" for multi language support:

#A# language specific metadata values
"wms_title" "my title"
"wms_title" "mein titel"

and

#B# language dependent reference data
DATA "shapes/rivers_eng.shp" 
DATA "shapes/rivers_ger.shp" 

-----------------------------------------------------

until now I can think of five different methods to handle them (I'm sure
there are much more):

(1) key extension
#A#
"wms_title_eng" "my title"
"wms_title_ger" "mein titel" 

#B#
not appropriate imo

the main question here is: should the resolving happen at
- write time (i.e. only wms_title goes into mapobject)
or 
- read time (everything goes into mapobject, corresponding key e.g.
wms_title_ger is used for reading -> perhaps problematic to validate, also
need
to be aware that key has _langaguage extension)

(2) runtime substitution
#A#
not appropriate imo

#B#
DATA "shapes/rivers_%language%.shp" 

with "language" being a request parameter or global setting

already implemented in mapserver - http://mapserver.org/cgi/runsub.html -
for several (covering all required?) parameters

(3) externalization
#A#
"wms_title" "IDC_TITLE"

#B#
DATA "IDC_SHAPES_RIVERS" 

with external files e.g.
lang.eng
IDC_TITLE=my title
IDC_SHAPES_RIVERS=shapes/rivers_eng.shp (or
IDC_SHAPES_RIVERS=shapes/eng/rivers.shp)

lang.ger
IDC_TITLE=mein titel
IDC_SHAPES_RIVERS=shapes/rivers_ger.shp (or
IDC_SHAPES_RIVERS=shapes/ger/rivers.shp)

i think it's the most common way for internationalization and there are
many tools available to externalize strings

again the question is: at which time the externalized value should be
resolved (e.g. while parsing mapfile, during msApplySubstitutions, ...)

(4) merge (i.e. using INCLUDE)
#A#
not appropriate imo

#B#
standard.map
LAYER
...
  NAME "rivers"
  INCLUDE "rivers.map"
...

rivers.map
DATA "shapes/rivers_ger.shp" 

already implemented in mapserver -
http://mapserver.org/mapfile/Include.html - based on languange the
corresponding map file (e.g. 
shapes/ger/rivers.shp) is included

(5) override (i.e. override certain values of the original "unchanged"
mapfile)

- with comments (probably generated by tool)
#A# and #B#
standard.map
"wms_title" "my title" #1
...
LAYER
...
  NAME "rivers"
  DATA "shapes/rivers_eng.shp" #2
   ...

override.ger
1="mein titel
2="shapes/rivers_ger.shp"

- explicitly referencing key
#A# and #B#
standard.map
"wms_title" "my title"
...
LAYER
...
  NAME "rivers"
  DATA "shapes/rivers_eng.shp"
  ...

override.ger
"wms_title"="mein titel
"layer[rivers]/DATA"="shapes/rivers_eng.shp" or "layer[0]/DATA"
"shapes/rivers_ger.shp" or ....

problem is how to provide path in hierarchical structures like layers
(perhaps XPath syntax?)

-----------------------------------------------------

patch #3608 - http://trac.osgeo.org/mapserver/ticket/3608 - currently uses
#A#(1) applied at read time and #B#(2)

-----------------------------------------------------


hope it is not too confusing, looking forward to your feedback
br
stefan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-inspire/attachments/20110525/95637295/attachment-0001.html