In our previous episode, Dani?l Mantione said:
> >
> > Accepting both Arabic and Westernized Arabic numerals would possibly break a
> > lot of code anyway, since to string and back wouldn't be reversible.
>
> It has never been reversible. Think about val('$100',v);
See one line further down.
> > actually already isn't with Delphi I know, due to hex and padding handling,
> > but this would be a magnitude worse)
>
> You want to handle it transparently. Otherwise you get a mess like
> that people need all kind of ugly case constructs, having to call a
> different "val" routine depending on the language the program is shown in.
> That way you never will get good multi-lingual support.
IMHO one should separate GUI val from system val. IMHO it is a presentation
layer problem and should be dealt with there.
> For many people Unicode is just "let's go UTF-8". It's far more than that
> and 100% supporting Unicode is even next to impossible.
Correct, but that is what I'm suggesting. UTF-16 is not a cure all either,
only at a first superficial glance. I'm btw not for UTF-8, but for working
in the native encoding per platform.
> > You can't seperate val from str, and what would str(100,s) do?
>
> It could accept an extra optional parameter for the desired script or
> something like that.
If you think that is acceptable, you can also do it for val.
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
