SV: [Mapserver-inspire] options/questions regarding multi languagesupport

[Thomas Ellett]

+1for A1 and B1.

I think an external file is probably a cleaner way of doing it, but while the language dependent parameters are limited to titles and abstracts I think to have the extra language attributes within the same map file is easier to maintain.

However, if theres any chance that the number of parameters being affected by internationalization will increase in the future, then my choice changes to A3. Clear as mud?

Best Regards

 

Tom

 

Fra: mapserver-inspire-bounces at lists.osgeo.org [mailto:mapserver-inspire-bounces at lists.osgeo.org] På vegne av Stefan Leopold
Sendt: 25. mai 2011 20:33
Til: mapserver-inspire at lists.osgeo.org
Emne: [Mapserver-inspire] options/questions regarding multi languagesupport

 

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/20110526/6ae1243a/attachment-0001.html