Opened 10 years ago

Closed 10 years ago

Last modified 9 years ago

#547 closed enhancement (fixed)

Add a facet 'languageCode'

Reported by: Jörg Knappen Owned by:
Priority: minor Milestone: VLO-3.1
Component: VLO importer Version:
Keywords: Cc:


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

(an example resource)

(click on Nepali brings us here)

(click on Search Virtual Language Observatory for data about Nepali (macrolanguage) ... brings us here)

... and no resources are found (this time in VLO 2.18, but VLO 3.0 beta also finds nothing with this call)

Change History (15)

comment:1 Changed 10 years ago by DefaultCC Plugin

Cc: added

comment:2 Changed 10 years ago by Twan Goosen

Owner: set to Twan Goosen
Status: newassigned

comment:3 Changed 10 years ago by Twan Goosen

Milestone: VLO-3.0

comment:4 Changed 10 years ago by Twan Goosen

Milestone: VLO-3.0VLO-3.1
Priority: majorminor

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.

comment:5 Changed 10 years ago by 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.

comment:6 Changed 10 years ago by

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.

comment:7 Changed 10 years ago by 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".

comment:8 Changed 10 years ago by

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

comment:9 Changed 10 years ago by Twan Goosen

Summary: [vlo 3.0 beta] Link to the language in the expanded view can go wrongAdd a facet 'languageCode'
Type: defectenhancement

Renamed and retyped the ticket.

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

comment:10 Changed 10 years ago by Twan Goosen

Owner: changed from Twan Goosen to

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)?

comment:11 Changed 10 years ago by

Owner: changed from to Twan Goosen

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.

comment:12 Changed 10 years ago by Twan Goosen

Component: VLO web appVLO importer
Owner: changed from Twan Goosen to

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

comment:13 Changed 10 years ago by

Resolution: fixed
Status: assignedclosed

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.

comment:14 Changed 9 years ago by 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).

comment:15 Changed 9 years ago by 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).

Note: See TracTickets for help on using tickets.