Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setting metadata geographic extent fails to validate for locales that use comma decimal separator #469

Open
karbah-geodata opened this issue Sep 20, 2022 · 4 comments

Comments

@karbah-geodata
Copy link

Describe the bug
When configured with language/locale that uses comma as a decimal separator instead of period (e.g. Norwegian), the geographic extent selector sets the coordinate inputs with comma values. This in turn fails to validate when saving, since the validation presumably expects english numbers.

To Reproduce
Steps to reproduce the behavior:

  1. In geoportal/src/main/webapp/index.html turn on Norwegian language with locale: "nb".
  2. Login and click create new metadata (the editor should now be in Norwegian).
  3. Navigate to the tab "Identifikasjon - Ressurs - Omfang" and click "Angi geografisk utstrekning".
  4. Draw a random rectangle in the popup map and click "OK".
  5. The extent coordinates will now show with comma decimal separators.
  6. Click "Save".
  7. In the list of error messages should now be the extent coordinates complaining that they need to be numeric ("Verdi må være et tall. (desimalgrader)").

Expected behavior
The editor should recognize the decimal separator according to the locale. Alternatively it should convert it to a standard english numeric format.

Desktop (please complete the following information):

  • OS: Windows 11
  • Browser: Chrome
  • Version: ?

Additional context
Is there a quick temporary solution for this problem? Maybe some way to configure the numeric format to be different than the locale language? Or some code I can hardcode/override?

@karbah-geodata
Copy link
Author

karbah-geodata commented Nov 8, 2022

We have looked into this issue but still unable to fix it. Are there any obvious locale options we are missing here? Or pointer to which file needs to be patched?

@mhogeweg
Copy link
Member

mhogeweg commented Nov 9, 2022

You will have to look at the JS API for this:
https://js.arcgis.com/3.36/esri/dijit/metadata/form/tools/geoExtentUtil.js:formatted

In the app, open the dev tools, open the source code and find the above file. then set a breakpoint on the first line in formatCoordinate() (you may need to format the minimized code, should be around line 26).

I'm expecting that replacing the comma with a period as decimal sign would resolve this. All of the metadata standards I see (including ISO, INSPIRE) have periods for decimal numbers. The comma turns the value into a string and that results in a validation rule in the geoportal editor.

You can get the JS API from the Esri developer site: https://developers.arcgis.com/downloads/#javascript

Once unpacked, you can put the JS API metadata files in your geoportal server install. Then recursively update the references in the gxe files from esri/dijit/metadata/form/iso/GeoExtentTool to something like ../../../../form/iso/GeoExtentTool (relative path). Get all the relative references also (../tools/ClickableTool, ../tools/GeoExtentDialog, ../tools/GeoExtentView, ../tools/geoExtentUtil). Some more work to do on the .../kernel references, as you need to remove those for locally hosted files. Same with a snippet like this that you will see in several files.

  if(has("extend-esri")) {
    lang.setObject("dijit.metadata.form.iso.GeoExtentTool", oThisClass, esriNS);
  }

@karbah-geodata
Copy link
Author

Thanks, will have a look at the file you described and try to override it with a local one.

However, I'm just wondering if there's some other option I'm missing such as number format locale? If what you describe is the only way to fix it, I would suggest that geoportal uses a patched local version of the GeoExtentTool that respects the decimal separator of the chosen locale out of the box, since this is not an edge case and I'm surprised the issue hasn't been raised previously. In fact, most non-English languages use comma decimal separators meaning that most non-English localized versions of GeoPortal would result in the same validation error when using the geographic extent tool.

I confirmed this by setting "locale: fr", after which setting the geographic extent resulted in the same comma separated coordinates and validation error:

image

@karbah-geodata
Copy link
Author

karbah-geodata commented Nov 10, 2022

Once unpacked, you can put the JS API metadata files in your geoportal server install.

Which exact folders/files do I unzip and where in geoportal do I put them in locally? My application is currently only focused on the iso standards, so I just copied the files from the esri "form/iso" folder to the existing (but incomplete) "webapp/app/gxe/form/iso" folder in geoportal, as well as "types/iso" into "webapp/app/gxe/types/iso".

Get all the relative references also (../tools/ClickableTool, ../tools/GeoExtentDialog, ../tools/GeoExtentView, ../tools/geoExtentUtil)

What do you mean by "get" them? There is exactly 1 reference for each that have references to those files as esri paths (eg define("esri/dijit/metadata/form/tools/ClickableTool"), which I replaced with their relative path, ie define("../tools/ClickableTool". There are several places where the files are already references with their relative paths, do I just leave them?

Some more work to do on the .../kernel references, as you need to remove those for locally hosted files.

There are quite a few files inside "form/iso" that contain such references. For example, does that mean I should just change this:

define("esri/dijit/metadata/form/iso/AbstractObject",["dojo/_base/declare","dojo/_base/lang","dojo/has","../Element","../../../../kernel"])

to this:

define("esri/dijit/metadata/form/iso/AbstractObject",["dojo/_base/declare","dojo/_base/lang","dojo/has","../Element","../../../../kernel"])

Same with a snippet like this that you will see in several files.

When you say "same" you mean they also have to be removed? The code snippet you referenced was only found inside one file, and that was inside the dublin core folder which is not really used in my use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants