Add a facet 'languageCode'

[Jörg Knappen]

The link in the language row of the resource view takes a detour via infra.clarin.eu. This detour can go wrong when infra.clarin.eu expand the code to something different than the VLO, as can be seen for Nepali

(an example resource)
​http://catalog.clarin.eu/vlobeta/record?24&docId=11858_47_00-229C-0000-0001-B071-C_64_type_61_dataprovider_38_id_61_10&fq=language:Nepali&index=347&count=750

(click on Nepali brings us here)
​http://infra.clarin.eu/service/language/info.php?code=nep

(click on Search Virtual Language Observatory for data about Nepali (macrolanguage) ... brings us here)
​http://catalog.clarin.eu/vlo/?3&fq=language:Nepali%2520%28macrolanguage%29

... and no resources are found (this time in VLO 2.18, but VLO 3.0 beta also finds nothing with this call)
​http://catalog.clarin.eu/vlobeta/search?26&fq=language:Nepali%2520%28macrolanguage%29

[Twan Goosen]

Although a valid and relevant observation IMO, I see no clear way to solve this in a straightforward way, and in any case I don't think this is crucial enough to hold back the 3.0 release. Putting it on the 3.1 milestone.

[Twan Goosen]

Note: the following could be a clean way to resolve this (but may need some thinking through):

• add a (hidden) facet 'languageCode' to the VLO
• populate this with the language code derived from the language name during import
• modify the VLO link in the ​language service to use this facet

Remaining question: how to represent the selection of this hidden facet in the VLO UI? A mapping to 'language' would still be needed - or we could get rid of the language facet as it exists altogether and migrate to a languageCode facet which has user friendly language name rendering (could be localised) in the UI.

[teckart@informatik.uni-leipzig.de]

I would vote for the last approach. There is already a separation of the language facets that causes unnecessary redundancy: a facet "language" that contains the language name (right now used on the search page) and "languages" that contains the HTML links to the language service for the expanded result page.

A better way would be to just store the language codes in Solr and generate the links in the webapp. If there are no objections I create the new hidden facet "languageCode" that just contains the language codes and the required PostProcessor?. "language" and "languages" can be removed when the Webapp was migrated.

[Twan Goosen]

Maybe a facet "language" should be kept in addition to "languageCode", that gets populated only in cases where the value for some reason cannot be traced back to a language code. This should be quite rare but I don't think we can rule such cases out.
It would be great to get rid of the "languages" facet, which indeed serves no purpose once we have "languageCode".

[teckart@informatik.uni-leipzig.de]

New facet "languageCode" was commited (r5143), facet "languages" still in trunk. Will be removed when the VLO Webapp won't use it anymore.

[Twan Goosen]

Renamed and retyped the ticket.

Note: this ticket probably makes #170 redundant (I'll let Thomas decide)

[Twan Goosen]

The more thought I give it, the more I prefer having a single language facet. Having a 'fallback' facet requires a lot of added complexity in the front-end, and some things cannot be worked around (e.g. we probably do not want to have *two* language facets showing up in the browser and combining two fundamentally distinct facets is a recipe for trouble). So how about the following amendment to Thomas's improvement:

• If a language code can be determined for a language value, it gets stored in the facet prefixed with 'code:'
• If a language code cannot be determined, it gets stored in the facet prefixed with 'name:'
• The frontend will apply a rendering strategy per value depending on the prefix
• As far as facet queries and page parameters are concerned, the prefix is simply part of the value

We can decide on the name of this facet. Maybe just 'language' covers its usage and semantics best.

Maybe this requires some further thought. Are there any downsides apart from the added front-end logic (which I think is quite acceptable)?

[teckart@informatik.uni-leipzig.de]

These changes were commited to trunk (r5188) for facet "languageCode". The facet can be renamed to "language" as soon as the current facets "language" and "languages" are not needed anymore in the webapp.

[Twan Goosen]

I created #553 as a follow up ticket for the web app. Thomas, you can decide on the fate of this one :)

[teckart@informatik.uni-leipzig.de]

Ok, I'll close it then as most of the remaining work is now in the webapp development. No need for a reminder to clean up the importer process as I will be happy to remove all the redundant code as soon as the work on the webapp is finished.

[Twan Goosen]

Changes are now reflected in the front end (see #553). The facets 'language' and 'languages' can be completely removed from the importer (making the code cleaner and should have a positive effect on performance as well).

[Twan Goosen]

Another TODO, after production deployment: update the logic in the info page (e.g. ​for Nepali). As a reminder, I added a note on this to the UPGRADE instructions (r6016:6017).