You went really good to the point.  Can't image how you didn't got it.
 Well, it's the first appearance of a very wide and important problem
with Persian locale:  decimal separator is the same for both Latin and
Persian set of digits, and is NOT the usual dot (".").  So you should
have got it already:  When setting the whole locale to fa_IR, scanf
simply does not parse floats with dot as separator!!!  Here is the
simple test:

#include <stdio.h>
#include <locale.h>
                                                                     
          
int
main()
{
    double g = 0;
    setlocale(LC_ALL, "fa_IR.UTF-8");
    scanf("%d", &g);
    printf("%d\n", g);
}

Compile and run and see how 12.3 would be parsed as 12.

Fix:  In the mean time:  fontconfig parse it's config file with C
locale.  In the long run:  Add another decimal separator to the
locales definition.  You already know the issue.

behdad

Oops, Of course I mant "%lg" not "%d" in both cases above.
Here is it fixed:

#include <stdio.h>
#include <locale.h>
                                                                     
                                                                     
                                                         
int
main()
{
    setlocale(LC_ALL, "fa_IR");
    while (1) {
        double g = 0;
        char buf[100];
        scanf("%lg%[^\n]", &g, buf);
        printf("You entered %lg\n", g);
    }
}


And here is the run:

123
You entered 123
123.456
You entered 123
123Ù«456
You entered 123Ù«456


See how the Persian decimal separator works.

Behdad, it's not that problem. Try the same with a "fr_FR.UTF-8"
locale and see that the output of your program is the same (use the
comma instead of the Persian decimal separator in your last example).
While running gedit with with a fr_FR locale doesn't give you any
warnings.

BTW, fontconfig can't switch locales while running. It's not thread
safe to do that, I've heard from Keith Packard.

So, no, I don't know the issue here. My real guess is two bugs, one in
glib and one in fontconfig.

Created attachment 95867 [details]
patch to fix two-byte decimal separator problem

Attaching the one line patch.  Here is the description of the problem:
 In fcxml.c, FcStrtod, when the decimal separator is two bytes, *end
gets computed wrong, so later FcParseDouble nags.

Keith:  Would you take care of upstream? ;-)

Oops, s/Keith/Roozbeh/

Created attachment 95871 [details]
replacement patch

fixed a bug in the patch ;)

Created attachment 95872 [details]
glib-2.2.3 strtod 2byte decimal separator patch

Here is the patch for exactly the same bug in glib2.

Tested both patches. They fix the problem. Trying to report them upstream.

Behdad, I just talked to keithp. keithp says there is no need for the
second patch. "buf_end will be > dot whenever dlen is > 1". Can you
confirm?

fontconfig's bug fixed in its CVS HEAD and 2.2 branch. glib2's bug
reported at <http://bugzilla.gnome.org/show_bug.cgi?id=126640>.

Roozbeh:  Just for the record, we talked on IRC and you comment #10 is
not true.  Did you applied the second patch to fontconfig?

Please Close the bug as upstream.

Behdad: Yes, Keithp agreed that you were correct. The second patch was
applied to fontconfig.

Closing the bug as upstream.