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) "[EMAIL PROTECTED]"? 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, [EMAIL PROTECTED]) should be provided), because it becomes the different locale each other. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
