[JS] Error when comparing with invalid locale (Incorrect locale information provided) #1204

kinow · 2021-09-14T10:27:06Z

At which URL did you encounter the problem?

Running Skosmos locally, with the locale en_US. In JavaScript, the locale needs - I think - to be replaced by en-US or en, otherwise we get a Incorrect locale information provided from String.localeCompare.

scripts.js:339 Uncaught RangeError: Incorrect locale information provided
    at String.localeCompare (<anonymous>)
    at naturalCompare (scripts.js:339)
    at a.jstree.plugins.sort.sort (hierarchy.js:534)
    at Array.sort (<anonymous>)
    at a.jstree.plugins.sort.sort (jstree.min.js:5)
    at a.jstree.plugins.sort.sort (jstree.min.js:5)
    at a.jstree.plugins.sort.<anonymous> (jstree.min.js:5)
    at HTMLDivElement.dispatch (jquery.min.js:3)
    at HTMLDivElement.r.handle (jquery.min.js:3)
    at Object.trigger (jquery.min.js:4)
naturalCompare @ scripts.js:339
sort @ hierarchy.js:534
sort @ jstree.min.js:5
sort @ jstree.min.js:5
(anonymous) @ jstree.min.js:5
dispatch @ jquery.min.js:3
r.handle @ jquery.min.js:3
trigger @ jquery.min.js:4
triggerHandler @ jquery.min.js:4
trigger @ jstree.min.js:2
k @ jstree.min.js:2
(anonymous) @ jstree.min.js:2

What steps will reproduce the problem?

Visit any concept of STW, for example
Switch to a locale with underscore (e.g. en_US, de_DE [is this correct?], etc)
Open browser console

What is the expected output? What do you see instead?

No errors, String.localeCompare uses a valid locale.

What browser did you use? (eg. Firefox, Chrome, Safari, Internet explorer)

Firefox & Chromium, Ubuntu LTS.

The text was updated successfully, but these errors were encountered:

osma · 2021-09-14T10:57:54Z

Thanks for reporting @kinow! How do you change the locale in step 2?

kinow · 2021-09-14T11:08:27Z

Thanks for reporting @kinow! How do you change the locale in step 2?

Changed the interface language. Here's my configuration for languages (the dockerfiles files are installing multiple locales):

    skosmos:languages (
        [ rdfs:label "ar" ; rdf:value "ar_AE.utf8" ]
        [ rdfs:label "da" ; rdf:value "da_DK.utf8" ]
        [ rdfs:label "de" ; rdf:value "de_DE.utf8" ]
        [ rdfs:label "en" ; rdf:value "en_GB.utf8" ]
        [ rdfs:label "en_US" ; rdf:value "en_US.utf8" ]
        [ rdfs:label "es" ; rdf:value "es_ES.utf8" ]
        [ rdfs:label "fa" ; rdf:value "fa_IR.utf8" ]
        [ rdfs:label "fi" ; rdf:value "fi_FI.utf8" ]
        [ rdfs:label "fr" ; rdf:value "fr_FR.utf8" ]
        [ rdfs:label "it" ; rdf:value "it_IT.utf8" ]
        [ rdfs:label "nb" ; rdf:value "nb_NO.utf8" ]
        [ rdfs:label "nl" ; rdf:value "nl_NL.utf8" ]
        [ rdfs:label "nn" ; rdf:value "nn_NO.utf8" ]
        [ rdfs:label "pl" ; rdf:value "pl_PL.utf8" ]
        [ rdfs:label "pt" ; rdf:value "pt_PT.utf8" ]
        [ rdfs:label "pt_BR" ; rdf:value "pt_BR.utf8" ]
        [ rdfs:label "ru" ; rdf:value "ru_RU.utf8" ]
        [ rdfs:label "sv" ; rdf:value "sv_SE.utf8" ]
        [ rdfs:label "zh" ; rdf:value "zh_CN.utf8" ]
    ) ;

And the search bar shows German too, which is strange I think?

osma · 2021-09-14T11:19:12Z

Ah, right - I think this is caused by the value of the lang variable that is passed from PHP to JS here:

Skosmos/view/scripts.twig

Line 22 in 4b4359d

var lang = "{{ request.lang }}";

It is passed to localeCompare within the naturalCompare function:

Skosmos/resource/js/scripts.js

Line 339 in 4b4359d

var nn = (an[0] - bn[0]) || an[1].localeCompare(bn[1], lang);

I think the underscore-style locale should be converted to what JS code expects somewhere - the best place to do that would probably be in the scripts.twig template or nearby (perhaps adding a new method to Request that returns the language in a JS-friendly format, which the template then calls instead of just {{ request.lang }})

Would you like to try to fix this @kinow? :)

osma · 2021-09-14T11:22:40Z

Regarding the search bar: that's probably a different issue altogether. It could be that it reverts to the default language of STW (German) because of some language comparison mismatch (e.g. "en_US" != "en"). I suggest fixing the main issue first, then looking at this later on.

kinow · 2021-09-14T11:51:21Z

I think the underscore-style locale should be converted to what JS code expects somewhere - the best place to do that would probably be in the scripts.twig template or nearby (perhaps adding a new method to Request that returns the language in a JS-friendly format, which the template then calls instead of just {{ request.lang }})

+1 sounds like a plan!

Would you like to try to fix this @kinow? :)

Yup, I always use localeCompare when sorting JS arrays, but I never thought about what values are valid for the locale (always used en). Good opportunity to learn while fixing the issue.

Writing a test might be a bit harder, but I'll try too. Thanks @osma!

kinow · 2021-09-15T09:19:17Z

Under the hood, looks like String.localeCompare uses Intl.Collator. To reproduce the bug:

new Intl.Collator('en_us') # error
new Intl.Collator('en-us') # ok

kinow · 2021-09-15T09:30:29Z

In the ECMAScript document https://tc39.es/ecma402/#intl-object, it says the locale is a valid BCP47 tag, so en-us or en-US, not en_US. I tested in the browser values like pt-BR, en-US, and en-GB. So the simplest fix appears to be to simply replace _ by a - 👍

osma · 2021-09-15T09:39:22Z

Excellent digging @kinow!

This sort of begs the question why language tags with underscores are even used in config.ttl - BCP47 is also used for RDF language tags and web technologies in general, including HTML. Would the issue be resolved simply by using en-US instead of en_US as the rdfs:label value in your configuration file, or would that create new problems?

Underscores are used in locale names like en_US.UTF8 but that's a different system anyway.

kinow · 2021-09-15T09:55:41Z

Oh, excellent question @osma.

We have values like

[ rdfs:label "pt_BR" ; rdf:value "pt_BR.utf8" ]

The label is used internally to match the JS selected values, and the configuration values. Then I guess it's used to submit queries to Jena, e.g.

Skosmos/model/sparql/GenericSparql.php

Line 1411 in 4b4359d

    
           $labelcondLabel = ($lang) ? "FILTER( langMatches(lang(?label), '$lang') )" : "";

From what I remember, I added pt_BR and not pt-BR because of the Linux locale format: https://man7.org/linux/man-pages/man1/locale.1.html#EXAMPLES

I think we use the locale code (with underscore) also because somewhere we use... a get---- function to load i18n strings, no? (Can't recall the name of the function, nor find it in the IDE).

kinow · 2021-09-15T09:56:21Z

(just saw your comment in the PR, sorry, was searching in the IDE and writing here 👍 but agree with you that that's strange to have _ (especially if the value in Jena might differ?)

osma · 2023-03-06T14:15:27Z

It seems to me that this was a user error - BCP47 language tags should be used for rdfs:label values in config.ttl - with dashes, not underscores, as the separator.

I'm closing this issue, but feel free to reopen if you disagree.

osma added the bug label Sep 14, 2021

kinow mentioned this issue Sep 15, 2021

Use BCP-47 tags for locale in JS #1206

Open

osma closed this as completed Mar 6, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[JS] Error when comparing with invalid locale (Incorrect locale information provided) #1204

[JS] Error when comparing with invalid locale (Incorrect locale information provided) #1204

kinow commented Sep 14, 2021

osma commented Sep 14, 2021

kinow commented Sep 14, 2021 •

edited

Loading

osma commented Sep 14, 2021 •

edited

Loading

osma commented Sep 14, 2021

kinow commented Sep 14, 2021

kinow commented Sep 15, 2021

kinow commented Sep 15, 2021

osma commented Sep 15, 2021

kinow commented Sep 15, 2021

kinow commented Sep 15, 2021

osma commented Mar 6, 2023

[JS] Error when comparing with invalid locale (Incorrect locale information provided) #1204

[JS] Error when comparing with invalid locale (Incorrect locale information provided) #1204

Comments

kinow commented Sep 14, 2021

At which URL did you encounter the problem?

What steps will reproduce the problem?

What is the expected output? What do you see instead?

What browser did you use? (eg. Firefox, Chrome, Safari, Internet explorer)

osma commented Sep 14, 2021

kinow commented Sep 14, 2021 • edited Loading

osma commented Sep 14, 2021 • edited Loading

osma commented Sep 14, 2021

kinow commented Sep 14, 2021

kinow commented Sep 15, 2021

kinow commented Sep 15, 2021

osma commented Sep 15, 2021

kinow commented Sep 15, 2021

kinow commented Sep 15, 2021

osma commented Mar 6, 2023

kinow commented Sep 14, 2021 •

edited

Loading

osma commented Sep 14, 2021 •

edited

Loading