Spanish locale: how to make commas become the default input separator for Decimal fields in the AppSheet UX


I am developping an app in Spanish locale. Here are the set of pre-requeriments I have checked boxed:

  • The Spreadsheet is configured on the Spanish Locale (File -> Spreadsheet settings -> Locale -> Spain)
  • A table Products contains a column named Price which is defined in the Appsheet side as Decimal, with 2 digital values
  • The App interface device (Google Chrome) is configured with the proper locale settings (chrome://settings/languages --> Spanish as default)

When the App is executed from a Spanish flavored Chrome and a screen to create a New Product is opened, we will not be able to input “3,25” as the intended value for the field. IF we do, the entry will be considered as Invalid and the record will not be saved.

I will need to input “3.25” as the Price value in order for the record to be properly saved. Back to the Spreadsheet, the value will be perfectly visible as “3,25”. Back to the App, the value will be perfectly read as “3,25”. But once again, if I wish to modify the value to, say “3,50”, I will not be able to… unless I modify it to “3.50” instead

This issue is even more annoying when the app is opened directly inside the Appsheet app in a Spanish mobile phone, for as the digits input pad will not offer a “dot” character but only a “comma” character… So everytime we will wish to add or modify a Product Price we will need to click on the digits input pad extensor key (the “*+#” key) in order to access the alternative special characters, then locate the required “dot”, click on it, then click back the digits input pad key to return to the digits default pad (“123” key) then input the two intended digits, then Save the record.

I would love to discover that this issue is only a missing pre-requirement on my side instead of a bug. Praying for that to be the case.

Thanks in advance,


Additional infos

(thousand separator activated)

When I input a Product Price to X —> the App shows Y —> Good or Bad ? --> If bad, what is good ?

325.25 --> 325,25 --> Good
325.00 --> 325.00 --> Bad --> Should be 325,00
3245.15 --> 3245,15 --> Bad --> Should be 3.245,15 (thousand separator ON)
33245.15 --> 33.245,15 --> Good (thousands separators are working when more than 10 thousands)
300 --> 300.00 --> Bad --> Should be 300,00

I assume your table locales are correct as well in the app. Any chance that your default locale language is not the first one in a list on Chrome’s settings? It should be the first one.

1 Like

Hi Aleksi,

The table locales in the App are

Table --> View Data -> Localization -> Data Locale : Spanish (Spain, International Sort)

As for Chrome settings, Spanish is indeed the first listed:

I can reproduce this behavior consistently in other browsers as well (Firefox).

Another internationalization / locale bug…

The “New” label is not translated to the appropriate locale value on *_Details screens. Example at the bottom of the Table (View | Add) :

Such label is indeed translated correctly to the appropriate locale value on *_Form screens. Example at the bottom of the table (View | New) :

It would seem that for some reason on the *_Details screens there is an old “Add” label being used which should be substituted by a “new” label instead. I can not see “Add” in the list of localizable labels under UX --> Localize. Only “New” exists.

For the “Add” button in inline view in detail view , you can rename it as you wish in the display name setting of that table’s system generated “Add” action.


Nice one Suvrutt. Your suggestion works nicely to workaround the inlineView/formView discrepancies. Thank you so much indeed.

Only the numeric locale issues above (first 2 updates in this thread) remain open now !

1 Like

Hi @Marcos_Ares,

Good to know the action name part works per your need. I may mention here that I will be unable to add anything to your numeric locales issue.

Would you please send an email to, thanks.

Done. Thanks Aleksi. I will notify about the outcome via a Reply to this thread as soon as I will get a remedy/solution.

Hi all,

To close the thread in pure beauty: thanks to Adam and the AppSheet support team for having fixed successfully all of the points risen in this thread.