From owner-freebsd-i18n Tue Mar 12 7:47:24 2002 Delivered-To: freebsd-i18n@freebsd.org Received: from gate.sim.ionidea.com (ion.so-com.net [212.110.132.83]) by hub.freebsd.org (Postfix) with ESMTP id 87B1D37B89B for ; Tue, 12 Mar 2002 07:46:14 -0800 (PST) Received: (from phantom@localhost) by gate.sim.ionidea.com (8.11.6/8.11.1) id g2CFGA758410; Tue, 12 Mar 2002 17:16:10 +0200 (EET) (envelope-from phantom) Date: Tue, 12 Mar 2002 17:16:09 +0200 From: Alexey Zelkin To: i18n@freebsd.org Subject: FreeBSD i18n related plans Message-ID: <20020312171609.A94497@gate.sim.ionidea.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.20i X-Operating-System: FreeBSD 4.2-RELEASE i386 Sender: owner-freebsd-i18n@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Folks, I'd like to share my and collect your plans related to internationalization work for next few months. Idea of this letter is: . To receive useful ideas, comments and feedback on current and future i18n way of FreeBSD. My targets are noted below and your comments/additions to this list are welcome! . To share information about ongoing i18n related projects. If you're involved to any such project please post short notice and project description to this mailing list. . To collect stale/suspended/not-started projects and possibly find volunteers to take them over. If you've information on such kind of projects/ideas please post it to this mailing list or to me directly. . And at general -- to make FreeBSD more friendly to not-english speaking/reading people. If you've notes by any of these points -- answer right now ! :-) Briefly about my short-term plans: 1. I am going to MFC bunch of locale and time specific changes soon to RELENG_4. Main aim of this merge is to sync -current and -stable locale handling code. This MFC brings to -stable few useful features, like: . support for LC_MESSAGES/LC_NUMERIC/LC_MONETARY locale categories (i.e. . support for nl_langinfo(3) . bunch of changes to str[fp]time(3) functions, like adding of new POSIX specifiers, removing of some non-standard specifiers (like %E[Ff]) As soon as it will be committed I would ask you to check these changes against your locale experience. I am using these changes at my system for some time, but I can prove their correctness against english and russian locales only. 2. I am going to port from NetBSD NLS stuff used to translate libc error and signal messages. This change will affect results of strerror(), strsignal(), perror() and psignal() functions. They'll return translated errors message according to current locale set. 3. We (few people) are planing to start implementing NLS support for base system utilities, i.e. to provide i18n support to applications which live in /bin, /usr.bin, etc. There're two possible options: a) implement this using standard NLS stuff (catopen()/catgets()/catclose()). Pros and Cons of this way: Pros: . infrastructure is already implemented and used in FreeBSD for long time Cons: . translated strings are referred by numeric Ids (this will require spending more time on synchronization) . no infrastructure to generate source catalogs and check outdated translated catalogs exists b) implement this using gettext. Actually there're two possible choices of infrastructure: GNU gettext (GPL) or Citrus libintl (BSDL). Pros: . simple maintaince of translated catalogs . no fixed Ids for messages . some of base tree tools already have translated catalogs (not imported to base tree by default) Cons: . In BSDL case: no maintaince tools under BSDL available, only library. . In GPL case: licensing problems. . In both cases -- possibility to hit into outdated library with new (changed) .po/.mo files format case. Also I am interesting in case of having both in-tree and ports versions of libintl. Any ideas how to do it (except exact renaming of in-tree version) ? 4) As continue of previous idea is to implement i18n of user interaction infrastructure. For example application should not just ask for: Are you sure [y/n]: yes but use nl_langinfo(3) to receive translated "yes" and "no" message. Like: printf("%s? [%s/%s] ", _i18n("Are you sure), nl_langinfo(YESSTR), nl_langinfo(NOSTR)); Also use "yesexpr" and "noexpr" (also available from nl_langinfo()) to parse answer (to respect national positive/negative answer values). 5) And last idea that I have in mind is to start implementing POSIX compatible localedef(1) utility and to completely replace our current source locale data with POSIX compatible ones. Additions, comments ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-i18n" in the body of the message