Opened 9 years ago

Closed 8 years ago

#780 closed enhancement (fixed)

Language code in description prefix should always be ISO639

Reported by: Twan Goosen Owned by: Twan Goosen
Priority: critical Milestone: VLO-3.4
Component: VLO web app Version:
Keywords: Cc: Twan Goosen, teckart@informatik.uni-leipzig.de

Description

Follow-up of #778

Some records have content language prefixes with codes that are not lower case ISO639 three letter codes. For example this record has

{lang='en-US'}various arabic dialects
{lang='en-GB'}Dictionary Gate is a growing collection of lexical resources
{lang='en-US'}a simple search interface to the dictionaries in the dict-gate

The web app used to assume a 3 letter code but this was relaxed in r6404. This fixes the problem in the view, but it would be nicer to use a unified code scheme, as is the case with the values of the languageCode facet, for easier processing in the front end (note: currently no such processing takes place).

Note: as far as I'm concerned, this scheme does not necessarily have to be exactly the 3 letters scheme that was assumed first. Maybe we want to represent language variaties as illustrated by the example above?

Change History (8)

comment:1 Changed 9 years ago by DefaultCC Plugin

Cc: Twan Goosen added

comment:2 Changed 9 years ago by teckart@informatik.uni-leipzig.de

Cc: teckart@informatik.uni-leipzig.de added

comment:3 Changed 9 years ago by teckart@informatik.uni-leipzig.de

I don't see a reason why the region codes would be useful in the webapp. Therefore I think providing only ISO 639-3 codes is the best solution here.
That would leave the question if we want to stay with this value schema ("{lang='eng'}") or use the schema of the languageCode facet (including something like "{name:SOME_LANGUAGE_NAME}" for values that couldn't be mapped to ISO 639-3).

comment:4 in reply to:  3 Changed 9 years ago by Twan Goosen

Replying to teckart@…:

I don't see a reason why the region codes would be useful in the webapp. Therefore I think providing only ISO 639-3 codes is the best solution here.

Agreed.

That would leave the question if we want to stay with this value schema ("{lang='eng'}") or use the schema of the languageCode facet (including something like "{name:SOME_LANGUAGE_NAME}" for values that couldn't be mapped to ISO 639-3).

I think that would be nice for the sake of consistency if nothing else. We should be able to reuse some code here (at both ends) :)

comment:5 Changed 9 years ago by teckart@informatik.uni-leipzig.de

Component: VLO importerVLO web app

Fixed in r6653.

The output for the example record above is now:

{code:eng}various arabic dialects
{code:eng}Dictionary Gate is a growing collection of lexical resources
{code:eng}a simple search interface to the dictionaries in the dict-gate

If mapping to ISO 639-3 fails, the output would look like:

{name:XYZ}Description

Moving this ticket to VLO web app for adaptations there.

Last edited 9 years ago by teckart@informatik.uni-leipzig.de (previous) (diff)

comment:6 Changed 9 years ago by Twan Goosen

Milestone: VLO-3.5 or laterVLO-3.4

Since this change is in trunk and the adaptation in the webapp is expected to be minor, I'm moving this to the 3.4 milestone.

comment:7 Changed 9 years ago by Twan Goosen

Owner: set to Twan Goosen
Priority: minorcritical
Status: newaccepted

Marking this as criticial since the importer has been modified but the web app has not been adapted

comment:8 Changed 8 years ago by Twan Goosen

Resolution: fixed
Status: acceptedclosed

Fixed in ee658bc.

Note: See TracTickets for help on using tickets.