[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#142072: acknowledged by developer (Re: libc6: pre Euro currencies obseleted too soon)



At Tue, 1 Apr 2003 17:12:11 +0200,
Denis Barbier wrote:
> 
> On Tue, Apr 01, 2003 at 11:45:29PM +0900, GOTO Masanori wrote:
> [...]
> > > > > Of course these currencies are obsolete, but applications may want
> > > > > to define pre-Euro locales for whatever reason.
> > > > > When UTF-8 becomes the standard, will current legacy encodings be
> > > > > dropped because they are obsolete?  I hope they won't.
> > > > 
> > > > So please submit the report to the appropriate standard group to show
> > > > the criteria of the int_curr_symbol with the obsolete currency symbol.
> > > 
> > > I do not understand, sorry.
> > > Q2.3 in http://www.linuxbase.org/test/lsb-runtime-test-faq.html
> > > tells that obsolete currencies must be defined.
> > 
> > So LSB is wrong.  Q2.3 is crap.  Reread my post.  Rethink what is the
> > locale.  The principle is the real world requirement, not the standard
> > conformance.  Blind follower might not be always good result.  Be not
> > the standard fundamentalism.
> 
> I could understand your point of view if there was a conflict between
> standard conformance and real world requirement, but this is not the
> case.  We ask you to allow people generating their own locales with
> pre-Euro currencies if they need to, nothing more; current locales
> are unchanged.

Hmm.  we can say int_curr_symbols have no ability to handle the
multiple/obsolete currencies.  But should we provide (ex) "de_DE@DTM"?
Is it really needed?  I don't think it's really needed.  In addition,
changing some fields with the same locale should be avoided (so the
separate locales (de_DE, de_DE@DTM) should be provided), because it
becomes the different locale each other.

Regards,
-- gotom



Reply to: