com.eldrix.hermes.impl.language — com.eldrix/hermes 0.8.346

SNOMED language and localisation support. There are four ways to consider locale in SNOMED CT.

1. A crude language label (e.g. "en" in each description. This should generally not be used.
2. Requesting using one or more specific language reference sets. This provides the most control for clients but the burden of work falls on clients to decide which reference sets to use at each request.
3. Request by a dialect alias. This simply maps aliases to specific language reference sets.
4. Request by IETF BCP 47 locale.

Options 1-3 are defined by SNOMED. Option 4 provides a wrapper so that standards-based locale priority strings can be used effectively.

Arguably, there are two separate issues. For clients, they want to be able to choose their locale and this should use IETF BCP 47. For any single service installation, there will need to be a choice in how a specific locale choice is met.

dialect->refset-id clj

(dialect->refset-id s)

Return the refset identifier for the dialect specified.

dialect-language-reference-sets clj

These use non-standard locales that cannot be used with the conventional locale matching standards, such as IETF BCP 47, but they are used in ECL for a crude alias for dialect, with an alias representing a distinct reference set. See https://confluence.ihtsdotools.org/display/DOCECL/Appendix+C+-+Dialect+Aliases

installed-language-reference-sets clj

(installed-language-reference-sets store)

Return a map of installed language reference sets keyed by Locale. For example {#object[java.util.Locale 0x31e2875 "en_GB"] (999001261000000100 900000000000508004), #object[java.util.Locale 0x7d55b894 "en_US"] (900000000000509007)}

language-reference-sets clj

Defines a mapping between ISO language tags and the language reference sets (possibly) installed as part of SNOMED CT. These can be used if a client does not wish to specify a reference set (or set of reference sets) to be used to derive preferred or acceptable terms, but instead wants some sane defaults on the basis of locale as defined by IETF BCP 47.

These are based on the contents of https://confluence.ihtsdotools.org/display/DOCECL/Appendix+C+-+Dialect+Aliases but hide the unnecessary complexity of multiple language reference sets for GB, and instead provide an ordered priority list.

TODO: consider a registry so that client applications can register a different set of priorities for any specific locale if they know better than the defaults.

match clj

(match store language-priority-list)

Convenience method to match a language-priority-list to the installed language reference sets in the store specified. Returns a sequence refset identifiers.

match-fn clj

(match-fn store)

Generate a locale matching function to return the best refsets to use given a 'language-priority-list'. Parameters:

• store : a SNOMED store Returns:
• a function that takes a single string containing a list of comma-separated language ranges or a list of language ranges in the form of the "Accept-Language " header defined in RFC 2616. That function will return a list of best-matched reference identifiers given those priorities.

This closes over the installed reference sets at the time of function generation and so does not take into account changes made since it was generated.

parse-accept-language-refset-id clj

(parse-accept-language-refset-id s)

Parse an 'Accept-Language' header specifying a refset identifier. This header should be of the form 'en-x-12345678902' The prefix should be any BCP 47 language tag, but this information will be ignored in favour of the specified refset identifier. Returns the refset specified or nil if the header isn't suitable.