I was not arguing in favor of locking the spec for English text only, but that the spec that we write must have conditions on how the internationalization is utilized so that it is all done consistently. I wanted to bring up the issue of having a multitude of character sets now available and to ensure that we are not compounding the problem.
Because of the current market, you can assume that all devices will be used all over the world. This means that those in Argentina are very likely to be using devices from China. If the logs are set for Chinese, then they will be useless for those attempting use the logs. I just want to make sure that whatever we suggest it is actually useful and will work across the board. French just for the sake of French is not sufficient. Richard -----Original Message----- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2003 12:51 AM To: Richard E. Perlotto II Cc: [EMAIL PROTECTED]; Andrew Ross 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
