Re: Anybody working on ISO/IEC 15435 (i18n.h)?

[Keld Jørn Simonsen <keld@xxxxxxxx>]

Hi!

WG20 is happy to receive any input you have on this document.
I am the editor, and I am happy to take informal discussions
with you, either on this email list or on the WG20 email list or privately.

You can also get onto the WG20 email list (after arrangements)
if you like.

Kind regards
Keld Simonsen


On Mon, Jan 31, 2000 at 08:25:00PM +0200, Kai Henningsen wrote:
> keld@xxxxxxxx (Keld J¢rn Simonsen)  wrote on 31.01.00 in <20000131132131.A1302@xxxxxxxxxxxxxx>:
> 
> > On Mon, Jan 31, 2000 at 12:52:55PM +0100, Bruno Haible wrote:
> > > Kai Henningsen writes:
> > > > NOTE: the above is not yet a standard.
> > > >
> > > > See: http://anubis.dkuug.dk/jtc1/sc22/wg20/docs/n612.{txt,doc,ps}
> > >
> > > It would be helpful to have some standardized API in this direction. But
> > > that particular draft doesn't cut it: 1. Its string datatype doesn't
> > > distinguish NULL and "" - a distinction which is essential in languages
> > > such as C, C++, Lisp, Java. 2. There is no easy way to convert between
> > > string and wchar_t*.
> >
> > There is a new draft in:
> > http://anubis.dkuug.dk/jtc1/sc22/wg20/docs/n714.pdf
> > I believe your concerns have been addressed there.
> 
> There still seem to be quite a number of problems.
> 
> For example:
> 
> - string results. Not all procedures specify error returns, and those that  
> do still sometimes talk about returning the empty string on error (instead  
> of the void string)
> 
> - stringn?copy is stringn?cpy in the C bindings. All other names are  
> identical.
> 
> - in the C bindings, for output string parameters, sometimes a maxlen  
> parameter is added, but not always. Also, it is unclear by what rules some  
> parameters are int and some are size_t. Some sort of general rule should  
> be used. (The origin of this problem is that a string lacks a "maxsize"  
> field. Maybe that should be changed?)
> 
> - there are a number of types that are translated as structs. This is  
> probably a bad idea; all of them are allocated, manipulated, and freed by  
> the library, so they probably ought to be opaque pointers (like FILE *).
> 
> Would you be interested in a i18n.h that tried to avoid these problems?  
> (And what should it do about the last two points?)
> 
> I'm interested in implementing at least part of this, if we can clear up  
> the interface problems.
> 
> MfG Kai
> -
> Linux-UTF8:   i18n of Linux on all levels
> Archive:      http://mail.nl.linux.org/lists/
-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/lists/