bug#16838: Confusing localization of seq

[Pádraig Brady]

On 02/21/2014 10:48 PM, Göran Uddeborg wrote:
> It seems the input arguments of "seq" are not localized, but the
> output is.  I was surprised to find this, and thought I'd ask here if
> it is an intentional decision.
> 
> More specifically, I'm using the Swedish locale, where the radix
> character is a comma.  The arguments to "seq" does not accept a comma,
> but the output is written using it.
> 
>     mimmi$ env LANG=sv_SE.utf8 seq 1 0.3 2
>     1,0
>     1,3
>     1,6
>     1,9
> 
> I realized this using coreutils-8.21 on Fedora.

That is an unfortunate asymmetry, though founded in pragmatism.

Similarly date(1) for example can't parse
the localized output that it can itself generate.

Do we really want to complicate the code
to support the many different numeric formats,
including different grouping sizes, grouping characters,
alternative digits like ۱٬۲۳۴ etc.?

More important to code complexity is the
simplification of the interface by restricting
the input to a subset format and only considering
localized output at the final step for presentation.

Now rather than consider changing these _programmatic_ interfaces,
we might support conversion of localized input in an explicit
entry point to the system.  We could isolate that
functionality in the new numfmt utility, which could
be updated to support these asymmetric localization conversions.

thanks,
Pádraig.