---------- Forwarded message ---------- Date: Mon, 21 Jul 2003 09:51:02 +0200 From: Rainer Gerhards <[EMAIL PROTECTED]> To: Richard E. Perlotto II <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], Andrew Ross <[EMAIL PROTECTED]> Subject: RE: Syslog Internationalization /UDP
Richard, > While I agree that some sort of internationalization would be good, we > lose the most important part of logging and that is a certain amount > of expected output. Will German devices only start producing logs > in German? Japanese devices in only Japanese? > > Whatever we propose will need to be able to be useable to the majority > but extensible enough such that those with non-English character sets > can still gain more than what is currently available. Do we require > these types of devices to be able to produce two types of > logging output? > We need something in between the two solutions. I would like to stress one motivation behind internationalization. I think there are two motivations behind this: #1 local names Local computer and user names are not uncommon at least in the European environment (I am not sure about Asia). What happens is we have an otherwise English message, but it will pick up some local e.g. system name with non US ANSI characters. Right now, this is simply not supported in any of the standards. In reality, most syslog clients (I know) don't care and send 8 bit data. With I18N, we can easily and "cleanly" include these local characters into our language stream. #2 localized messages In my point of view, this is radically different from #1. Here, the whole message is local text and English is potentially totally absent. The motivation behind this is obviously to make the message understandable to some non-English speaking folks. I agree that this poses a big problem to log analysers - they must support different languages in their parsing. However, it may not pose a problem to human readers... I think it is very dangerous to assume that everyone in IT speaks English and does so fluently. Granted, if you are with an international vendor OR with an international organization, chances are good you are not hired if you don't speak English. But even then, I guess (no real knowledge) that if you are with a French multinational, you may need to speak French as the official first language. However, as soon as you leave the multinationals, things change dramatically. You may find it surprisingly how few admins - even in large organizations - do not or only very weak speak English. I know this for sure for Germany and have the strong feeling it is also the case for Japan. My experience also tells me it is most probably the case in China, France, Italy and Spain. I don't have any real-world backed experience with other countries, but I assume you could easily extend the list. So I think we must be *very careful* when saying that non-English messages pose a problem. In fact, for those people, the English messages are useless. And keep in mind this goup of people is by far larger in size than the "mutlinational admins". So I would not jump on the wagon to say "it must be English to be good" (sorry for over-stressing the point a bit too much - my intension is to make the point very clearly visible). Given this philosophy, I honestly don't have any problem with Japanese devices only emiting Japanese messages and German ones only German. These message will make far more sense to those in the native language environment. Even think about low-end home users strugling with the routers... I think we should provide the necessary standard enabling vendors to create such devices. Then, let them (or better: the market) decide if it actually makes sense to them. Right now, we have *no* standard and do not leave the vendor any option to do this in a standards-compliant way. What happens? Everybody emiting local messages does it in a non-conformant way. I firmly believe: We can't and shouldn't tell vendors and customers their choice of doing logging. If they like local logs in multiple languages, let them do it. If they don't do that for good reasons, that's fine. But if we do not provide a solution to do it, they'll do it their own (and vendor-specific) way. Remeber: ultimately, it is not the ISO or IETF or evel local government (and least in the free world ;)) that tells them what the have to do: they decide themselfs based on market needs. The only thing we can do to get it in an interoperable way is to help them with a standard. Fortunatley, really bad ideas are sorted out quickly in the market ;) Comments? Rainer
