nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Decimal Separator

uwe_wolfinger

I created a custom content type with a property of type "double". In share-config-custom.xml i configured the field to use the number.ftl template.

The whole system and browser have a language/locale setting of "de".

Unfortunately,in the form, i am not able to enter the double property with a "german" decimal sepetator (i.e. ,), i am always forced to enter the data in a way 123.345 instead of 123,345.

So my question is, is there a way to force the form/model to use the german decimal separaotr? Or is there no way to achieve this?

Kind Regards,
Uwe

Find more posts tagged with

Comments

afaust

Hello,

yeah, number inputs can be a real pain. Using the normal number.ftl you won't be able to get german decimal separator support. It basically is just a regular text field and the text input is (transparently) converted into a numeric on the backend. Sure, the backend will know about your locale, but it can't distinguish user input (where german decimal separator would need to be applied) from technical input (some piece of code that is not using the same separator).

You can get german separators in two "standard" ways, but both of them require a bit of coding / development and can't be done with just configuration or rules.

One option would be to write a custom number.ftl that consists of two fields - the input field and a hidden field holding the actual value. When the input field changes, some JavasScript client side logic uses the current locale to parse the user input into a technical JavaScript number and update the hidden field. That way, the change is only "cosmetic" without impacting any backend.
The second option would be to write a so-called form filter in Java which enhances the backend and parses the input received from the form using the proper locale before it is passed to persistence layer.

Regards
Axel

jacek_pater

Alex, I have read your answer regarding the solution for setting the decimal separator of numeric data types.
In Poland we also use the comma (,) character instead of the decimal point (.)
Because the topic was discussed in 2015, so probably it concerned previous versions of alfresco. And since it did not appear later, I would like to ask whether for the alfresco version 5.2.0 (share 5.2.f) this solution is still valid or maybe there was another solution (some additional setting or a simple configuration).