Date: 19 Sep 2000 00:45:21 -0700 From: asami@FreeBSD.org (Satoshi - Ports Wraith - Asami) To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: ports@FreeBSD.org Subject: Re: Extending BSD.[local,x11].dist to include GNU gettext locale dirs Message-ID: <vqcpum04yge.fsf@silvia.hip.berkeley.edu> In-Reply-To: Maxim Sobolev's message of "Mon, 18 Sep 2000 21:00:03 %2B0300" References: <39C65823.42396A80@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* From: Maxim Sobolev <sobomax@FreeBSD.org> * We have a large number (~200) of ports that use GNU gettext, which implies that * they are sharing some common directories. Currently this behaviour is * unhandled, so maintainer of each particular port is free to deal with it * whatever he likes. The better solution of course is to add those dirs into our * mtree files, so the wheel will not have to be reinvented each time. The only * problem, though, is a lack of complete list of those dirs, which means that * potentially each softwar author can name his favorite locale whatever he likes, * however most of them are smart enough to choose common 2-letter names * optionally followed by encoding name. Following patch was prepared by greeping * all PLISTs, so it should be fairly complete. I would like to know what do * people think about it. * + locale * + af * + LC_MESSAGES Thanks for doing all the work, but I have one question: what's the difference between "nls" and "locale" dirs? We already have a whole bunch of subdirectories under "nls" already, can't those be used? Also, are these "locale" directories only used by gettext (and gettext-using ports)? If so, maybe we should implement something to let gettext supply an additional mtree file (I can work out a bsd.port.mk patch for this) so they don't have to be on everyone's system. Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?vqcpum04yge.fsf>