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
Cc: | Twan Goosen added |
---|
comment:2 Changed 9 years ago by
Cc: | teckart@informatik.uni-leipzig.de added |
---|
comment:3 follow-up: 4 Changed 9 years ago by
comment:4 Changed 9 years ago by
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
Component: | VLO importer → VLO 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.
comment:6 Changed 9 years ago by
Milestone: | VLO-3.5 or later → VLO-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
Owner: | set to Twan Goosen |
---|---|
Priority: | minor → critical |
Status: | new → accepted |
Marking this as criticial since the importer has been modified but the web app has not been adapted
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).