The locale attribute in the <gmd:LocalisedCharacterString> element is defined by the XML schema as a value of kind xs:anyURI. However SIS 0.3 handles it as a plain string containing directly the language code, except for the "#locale-" prefix (if present) which is ignored. This is incomplete, and may be wrong under some circumstances.
ISO 19139:2007 at pages 105 and 106 defines the management of multilingual metadata. A character string is localized as the example below:
The locale="#locale-fr" attribute references a locale definition provided elsewhere, typically as an element of the root metadata:
Since the locale attribute is a URI referencing an other element, that attribute value typically begins with # character, while the id attribute in <PT_Locale> does not. However there is nothing in the specification telling that the locale ID shall be prefixed by "locale-", neither that the text after that prefix shall be the language code. It just happen to be the convention followed in the examples given by the ISO specification.
A search on internet shows that this attribute is used in various ways:
Extract from ML_gmxCrs.xml:
- The locale attribute value is given by a XPath.
- The codeListValue attribute value in LanguageCode is "French" instead than an ISO language code.
Extract from Cruise2ISO on geo-ide:
- The locale attribute is a URL to a distant resource. However in this particular case attempts to fetch that resource give an error 404. Consequently there is no obvious way to find the locale for that example.
Extract from Google code:
- The locale attribute contains directly a parseable ISO language code. The absence of leading # suggest that there is no need to search for a definition elsewhere. This is the easiest case and is supported by current Apache SIS.
Extract from a mailing list:
- This is not really a parseable ISO code because of the missing - character. We would expect a definition to be provided elsewhere because of the # prefix, while the extract from the mail archive does not show it.
The fact that the <PT_Locale> elements providing locale definitions may appear after the localized string complicates the handling. One possible approach would be to create an internal object that keep a reference to a DefaultInternationalString, a String and a locale ID, then invoke the DefaultInternationalString.add(Locale, String) method at some later time when the Locale become known.