[Gdal-dev] GDAL on WinCE?

[Alain Rist]

Franck,

That's why I did not think it was a priority. But a french or japanese translation of gdalinfo might interest. My thinking was to have easier access to the literal stuff and put some translating macros in strategic places. Error messages are never understandable by a regular user. But info could be displayed in user language.

If you, or anyone on the list, are curious of that, you will find the Unicode macros and functions in MS compilers tchar.h headers. Roughly it is something like 
#ifdef UNICODE 
typedef wchar_t TCHAR; 
#else 
typedef char TCHAR;
#endif

Changing the char definitions in GDAL code to TCHAR is a tedious but simple operation. You ask the real question: Who would pay time or money for that ?

Regards

AR

----- Original Message ----- 
From: "Frank Warmerdam" <fwarmerdam at gmail.com>
To: "Alain Rist" <ar at navpoch.com>
Cc: <gdal-dev at xserve.flids.com>
Sent: Wednesday, December 08, 2004 6:56 PM
Subject: Re: [Gdal-dev] GDAL on WinCE?


> On Wed, 8 Dec 2004 18:43:55 +0100, Alain Rist <ar at navpoch.com> wrote:
> >  
> > Franck, 
> >   
> > WinCE systems are Unicode only. 
> >   
> > You can process char, char*, char& and char[] types as usual, but any string
> > transfer with the system ( file names, error messages etc..) is Unicode. 
> >
> > Many places in GDAL code embed such strings. All these char* or char[]
> > should be changed to TCHAR ( a macro that expands to wchar_t if Unicode is
> > enabled ) , without touching the real char type used in the formats. 
> >   
> > By the way, Unicode enabling GDAL is a very good idea : if coupled with
> > grouping of all message strings and hard-coded names in some resource
> > location, it would open the possibility for non english speakers to use GDAL
> > ! 
> >   
> > But if it is on your TODO list, I am afraid it gets a very bad scoring. 
> 
> Alain, 
> 
> I can't say unicode enabling GDAL has been high on my priority list. 
> It is a sufficiently major job that I think I would need a paying client
> who needs the capability enough to foot the bill.  And I hate to think
> what complexities it would pose for "normal" applications using
> the library the old way.  I would definately want to look at doing
> such a conversion in a way not unduely incompatible with what is
> done now. 
> 
> I am also not keen on translatability of messages.  I just find it hard
> to imagine anyone wanting to get error messages from GDAL in
> another language badly enough to justify the effort of translating and
> trying to maintain all the error messages.  I also don't like messages
> getting "too far away" from the code that issues them.  Generally I
> have seen this be a recipe for "message rot" where it is too much 
> trouble to find the messages and update them when the code changes. 
> Knowing my own laziness in this regard I would need a strong 
> motivation to make such a change.  Likewise, I do a crappy job at
> keeping the format documentation up to date as it is now.  Imagine
> how much less likely this would be done well in another language. 
> 
> I  guess my point is that I try hard to limit the amount of 
> documentation work so as to prevent me and others from just
> giving up on it.  I am leery of anything that complicates the effort. 
> 
> Best regards,
> -- 
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20041208/62ef00b4/attachment.html