From owner-freebsd-questions@FreeBSD.ORG Sat Mar 26 21:32:21 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 344B616A4CF for ; Sat, 26 Mar 2005 21:32:21 +0000 (GMT) Received: from smtp11.wanadoo.fr (smtp11.wanadoo.fr [193.252.22.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4BFA43D48 for ; Sat, 26 Mar 2005 21:32:20 +0000 (GMT) (envelope-from atkielski.anthony@wanadoo.fr) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1107.wanadoo.fr (SMTP Server) with ESMTP id E0F551C000AF for ; Sat, 26 Mar 2005 22:32:19 +0100 (CET) Received: from pix.atkielski.com (ASt-Lambert-111-2-1-3.w81-50.abo.wanadoo.fr [81.50.80.3]) by mwinf1107.wanadoo.fr (SMTP Server) with ESMTP id C0F351C000AE for ; Sat, 26 Mar 2005 22:32:19 +0100 (CET) X-ME-UUID: 20050326213219790.C0F351C000AE@mwinf1107.wanadoo.fr Date: Sat, 26 Mar 2005 22:32:18 +0100 From: Anthony Atkielski X-Priority: 3 (Normal) Message-ID: <1176697413.20050326223218@wanadoo.fr> To: freebsd-questions@freebsd.org In-Reply-To: <86d5tmkst7.fsf@amidala.datadok.no> References: <968029093.20050326192627@wanadoo.fr> <86d5tmkst7.fsf@amidala.datadok.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: mot de passe root X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-questions@freebsd.org List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2005 21:32:21 -0000 Peter N. M. Hansteen writes: > I fail to see how switching from one set of message strings files in a > correctly written application would destabilize it. As I've explained, changing string lengths can be a source of trouble; string copies that worked before are suddenly overflowing buffers. Inserting variable data into messages is also difficult with localized software, as the order and format of the variables must often change, and sometimes a lot of extra code is required to accommodate this. Special characters can cause code to fail if it is not prepared to handle 8-bit data--setting the high-order bit is especially likely to make trouble. There are lots of potential problems. And that's just with software that facilitates localization, such as Windows executables. In other environments, it gets a lot worse. > Oh, you're talking about Windows. Yes, there's been a lot of > localization related trouble there. But then we're relatively safe > from the secret brainfarts of Microsoft developers here. As I've already pointed out, localization is actually cleaner and safer in Windows programs than in most other types of software. Windows allows you to isolate strings and similar data in resource files built separately from the executable code. In many other environments, you have to either hard code all language data directly into the program, or you have to write your own code to allow broad localization. -- Anthony