In PDF there is the Format Action to format a field according to javascript rules.
There is for example date format to format an inputted date, or number format to format a number.

E.g.
You could format a Number 4212.126 so that it is displayed as "4,212.13 €"

A very common builtin script is "AF_NumberFormat". This is usually used together with "AF_NumberKeystroke" (executed in the fieldmodified event). To limit what a user can input so that the input matches the format. This task is not about implementing AF_NumberKeystroke as this would be unrelated and complex. Instead (and I actually find this a bit nicer) I'm adding localized number input based on QLocale.

So a German could input in a field:
1,23 (, is the decimal point in germany)
and it would be formatted according to the rules as (1.23)

In the same PDF someone with US Number Format could enter
1.23 and it would be formatted as (1.23)

If the German had entered 1.23 it would result in "Not a number" or vice versa.

IMO this is a good solution: Input in the locale your system is in. Output in the format the PDF wants.

I hope you don't find the code changes for this excessive, I tried to keep them to a minimum. But the importance here are e.g. Tax forms and for German institution"100.123" would be 100 thousand 123. This is especially a problem when combined with AF_SimpleCalculate as currently this expects US number format on any locale.

My main real world example is this German Health insurance form Calculate with Format example

This example currently would only accept decimal numbers like 1.234 and for a German this would be "one thousand two hundred and thirty four". So this Form would be unusable without formatting and number l10n.

Now for pretty pictures :-)

Adobe:

Okular (under en_IE locale):

In the examples above I forgot to show that we keep the original data before formatting. This is done by adobe, too.

TODO for me:

• Unit test
• Also add date format.

But I think the current patches could already be commented on.