[fpc-devel] Russian locale information not compatible with FPC locale variables

Marco van de Voort marcov at stack.nl
Tue Jul 29 10:45:22 CEST 2008


> On Tue, Jul 29, 2008 at 10:30 AM, Marco van de Voort <marcov at stack.nl> wrote:
> > of little ad-hoc changes to support workarounds.
> 
> I did not suggest ad-hoc changes, I meant FPC should fully support
> unicode strings as Delphi is doing in the next release.  Unicode is
> not something new, it's just Delphi that is way behind with their
> implementation compared to the demand, and FPC now seems to be in the
> same boat.  I don't see any point in waiting for Delphi, after all, we
> may NOT look at their implementation anyway!

No, but we can try to keep compability.
 
> Is there any FPC discussions as to how this is going to be tackled and
> what implications there are etc..? 

There have been, but they are now postponed till we have real Tiburon usage
data.

> Anything I can join?  Any timeline for developers to expect unicode
> support?

When it is ready (tm). Probably it will also depend on the plans for the
2.3.x branch, and how intrusive the new string type will be. If it is very
intrusive it might be post 2.4.

I don't think it is realistic to expect anything releaseworthy in the next
year.

>  Anything we can help test or write unit tests for?

Yes. You can make tests using widestrings. When it is working, translate all
literals to utf-8. Do so for preferably all sysutils,dateutils and strutils
string routines, but start with the more important ones. Probably you can
see if there are already routines testing this for ansistring in the
testsuite and build on that.

It will help me/us to start making UTF-8,16 versions of the RTL routines.
That work is parallelizable with the compiler work, and these will have to
be done anyway sooner or later, and fairly independant of the exact outcome
of the string types.




More information about the fpc-devel mailing list