| BABYL OPTIONS: -*- rmail -*- |
| Version: 5 |
| Labels: |
| Note: This is the header of an rmail file. |
| Note: If you are seeing it in rmail, |
| Note: it means the file has no messages in it. |
| |
| 1, edited,, |
| From: terrell@druhi.ATT.COM (TerrellE) |
| Newsgroups: comp.sys.ibm.pc,sci.astro |
| Subject: Internationalization of Software? |
| Date: 30 Jun 89 19:05:23 GMT |
| Reply-To: terrell@druhi.ATT.COM (TerrellE) |
| Organization: AT&T, Denver, CO |
| |
| *** EOOH *** |
| From: terrell@druhi.ATT.COM (TerrellE) |
| Newsgroups: comp.sys.ibm.pc,sci.astro |
| Subject: Internationalization of Software? |
| Date: 30 Jun 89 19:05:23 GMT |
| Reply-To: terrell@druhi.ATT.COM (TerrellE) |
| |
| I know that there are some modifications that I will have to perform to |
| "internationalize" software products developed for use in the USA. |
| These changes include the obvious (translate the program |
| and documentation into the right language). However, some of the |
| other changes are more subtle. I'm sure that I've overlooked some, but |
| here's what I have so far: |
| |
| Necessary changes to "internationalize" a software product: |
| |
| 1. Flexible date format: |
| |
| dd/mm/yy |
| yy/dd/mm |
| yy/mm/dd |
| mm/dd/yy |
| |
| 2. Handle foreign daylight savings time. |
| |
| 3. Flexible radix (decimal) point (i.e. '.' or ','): |
| |
| 3.14159 |
| 3,14159 |
| |
| 4. Allow English or Metric units. |
| |
| 5. Use "one thousand million" rather than "one billion". |
| |
| 6. Flexible time format: |
| |
| hh:mm |
| hh.mm |
| hh'mm |
| |
| 7. Allow either ' ' or ',' for thousands delimiters: |
| |
| 1,000,000 |
| 1 000 000 |
| |
| |
| What else is necessary? Overseas users: what changes would you make |
| to your "US Version" software to make it approprate for use in other |
| countries? |
| |
| I'll post a summary of the results. Thanks in advance, |
| |
| |
| |
| Eric Terrell (att!druhi!terrell) |
| |
| 1,, |
| Xref: IRO.UMontreal.CA comp.std.c:13991 comp.software.international:607 |
| Path: IRO.UMontreal.CA!CC.UMontreal.CA!newsflash.concordia.ca!utcsri!utnut!cs.utexas.edu!howland.reston.ans.net!nctuccca.edu.tw!news.cc.nctu.edu.tw!mall!ywliu |
| From: ywliu@beta.wsl.sinica.edu.tw () |
| Newsgroups: comp.std.c,comp.software.international |
| Subject: Re: ANSI C Locale Character Sets |
| Followup-To: comp.std.c,comp.software.international |
| Date: 3 Oct 1994 06:39:25 GMT |
| Organization: Computing Center, Academia Sinica |
| Lines: 26 |
| Message-ID: <36o8ut$afu@mall.sinica.edu.tw> |
| References: <Cx0Mpy.7Lo@actrix.gen.nz> |
| NNTP-Posting-Host: ywliu%@beta.wsl.sinica.edu.tw |
| X-Newsreader: TIN [version 1.2 PL0] |
| |
| *** EOOH *** |
| From: ywliu@beta.wsl.sinica.edu.tw () |
| Newsgroups: comp.std.c,comp.software.international |
| Subject: Re: ANSI C Locale Character Sets |
| Followup-To: comp.std.c,comp.software.international |
| Date: 3 Oct 1994 06:39:25 GMT |
| Organization: Computing Center, Academia Sinica |
| References: <Cx0Mpy.7Lo@actrix.gen.nz> |
| NNTP-Posting-Host: ywliu%@beta.wsl.sinica.edu.tw |
| X-Newsreader: TIN [version 1.2 PL0] |
| |
| Gary Houston (ghouston@actrix.gen.nz) wrote: |
| : It seems to me there are a couple of details missing from the ANSI C |
| : locale stuff: |
| |
| : 1/ How can a program find out which character set is being used? |
| |
| |
| You may use setlocale(LC_ALL,NULL) to get the language info. |
| |
| : 2/ How can a program determine whether text files use multibyte or |
| : wide characters, or is it to be assumed that multibyte will |
| : always be used? |
| |
| As far as I am concerned, the wide character is used as the representation |
| inside your program. That is, wide character is your internal data |
| representatin form, as I/O operates on multi-byte characters. So, I always |
| read/write mutl-bytes and convert to wide character , and vice versa. |
| |
| : Does anyone know of other standards/conventions/plans which fill |
| : in this missing information? |
| |
| You may check out P.J. Plauger's "Standard C" column on CUJ May 1993 - July |
| 1993. There is another one "Internationlization and Localization" in CUJ July |
| 1993 too. I am looking for more material. |
| |
| Yen-Wei Liu |
| |
| 1, edited, answered,, |
| Mail-from: From orac.iinet.com.au!pdcruze Thu Nov 24 17:38:19 1994 |
| Return-Path: <orac.iinet.com.au!pdcruze> |
| Received: by icule (Smail3.1.28.1 #1) |
| id m0rAmnw-00009aC; Thu, 24 Nov 94 17:38 EST |
| Received: from lagrande.iro.umontreal.ca by iros1.IRO.UMontreal.CA (8.6.9) with ESMTP |
| id LAA06293; Thu, 24 Nov 1994 11:57:58 -0500 |
| Received: from saguenay.IRO.UMontreal.CA (root@saguenay32.IRO.UMontreal.CA [132.204.32.54]) by lagrande.iro.umontreal.ca (8.6.9/8.6.9) with ESMTP id LAA23939 for <pinard@lagrande.IRO.UMontreal.CA>; Thu, 24 Nov 1994 11:57:50 -0500 |
| Received: from uniwa.uwa.edu.au (root@uniwa.uwa.edu.au [130.95.128.1]) by saguenay.IRO.UMontreal.CA (8.6.9/8.6.9) with ESMTP id LAA20957 for <pinard@IRO.UMontreal.CA>; Thu, 24 Nov 1994 11:57:46 -0500 |
| Received: from orac.iinet.com.au (orac.iinet.com.au [203.0.178.134]) by uniwa.uwa.edu.au (8.6.9/8.6.9) with ESMTP id AAA09394; Fri, 25 Nov 1994 00:57:29 +0800 |
| Received: from orac.iinet.com.au (pdcruze@localhost [127.0.0.1]) by orac.iinet.com.au (8.6.9/8.6.9) with ESMTP id AAA08605; Fri, 25 Nov 1994 00:57:11 +0800 |
| Message-Id: <199411241657.AAA08605@orac.iinet.com.au> |
| To: pinard@IRO.UMontreal.CA |
| cc: meyering@comco.com |
| Subject: Re: Starting localization of GNU recode |
| In-reply-to: Your message of "Thu, 24 Nov 1994 01:11:00 EST." |
| <m0rAXP2-00008sC@icule> |
| Date: Fri, 25 Nov 1994 00:57:10 +0800 |
| From: "Patrick D'Cruze" <pdcruze@li.org> |
| |
| *** EOOH *** |
| To: pinard@IRO.UMontreal.CA |
| cc: meyering@comco.com |
| Subject: Re: Starting localization of GNU recode |
| In-reply-to: Your message of "Thu, 24 Nov 1994 01:11:00 EST." |
| <m0rAXP2-00008sC@icule> |
| Date: Fri, 25 Nov 1994 00:57:10 +0800 |
| From: "Patrick D'Cruze" <pdcruze@li.org> |
| |
| > I met a few points of discussion while doing so: |
| > |
| > * I got to decide that, even if the program will eventually make |
| > most of its output in the foreign languages, the input syntax, |
| > option values, etc., are not to be localized. |
| |
| Yes. The purpose of message catalogs was to provide an easy to use method |
| for displaying language independent messages. Hence little modifications |
| need to be made to support this. However, no easy method exists for |
| supporting language-independent inputs. So this will have to be left up to |
| the developer to decide how they are going to implement this. |
| |
| > * it is not useful that I modify the lib/ routines if not done in the |
| > true sources. How do you/I/they proceed for getting this job done? |
| > I presume that lib/ routines will all use gettext for the time being. |
| |
| Probably Roland (or another volunteer) will internationalize glibc. Linux's |
| libc has already been internationalised and a few message catalogs |
| already exist - French, German, Polish. It probably would be useful |
| modifying the routines in lib/ for those platforms that will be using |
| the routines located in libc/. |
| |
| > I was expecting a problem which I did not met. All localizable |
| > strings were luckily into executable positions, that is, affected |
| > to variables or given as parameter to functions. But I will not |
| > escape this problem in all my things, and will surely hit some |
| > localizable strings in structured initializations. I'll see once |
| > there, unless you thought out an all ready solution for this (?). |
| |
| I've come across this a few times within diffutils. Particularly struct |
| definitions and the like. I'll send you a list of guidelines when looking |
| for output messages. Will send this to you and Jim tommorrow. |
| |
| Regards, |
| Patrick |
| |
| |
| |
| 1, edited,, |
| Mail-from: From pinard Mon Nov 28 12:15:47 1994 |
| Return-Path: <pinard> |
| Received: by icule (Smail3.1.28.1 #1) |
| id m0rC9fz-00008uC; Mon, 28 Nov 94 12:15 EST |
| Message-Id: <m0rC9fz-00008uC@icule> |
| Date: Mon, 28 Nov 94 12:15 EST |
| From: pinard (Francois Pinard) |
| To: Richard M. Stallman <rms@prep.ai.mit.edu> |
| CC: Jim Meyering <meyering@comco.com> |
| Subject: GNU standards and localized message catalogs |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=US-ASCII |
| |
| *** EOOH *** |
| Date: Mon, 28 Nov 94 12:15 EST |
| From: pinard (Francois Pinard) |
| To: Richard M. Stallman <rms@prep.ai.mit.edu> |
| CC: Jim Meyering <meyering@comco.com> |
| Subject: GNU standards and localized message catalogs |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=US-ASCII |
| |
| * We also need a uniform convention about where, in the installed |
| hierarchy, to put translations of manuals in long term. The need is |
| not immediate. One friend volunteered to translate the GNU recode |
| manual in French. If this happens, I would like to know first *if* |
| the distribution should install it by default, and where it should |
| install it then. If not installed by default, what would be the |
| uniform naming scheme for Makefile goals installing documents? |
| |
| 1, edited,, |
| Mail-from: From pinard Sat Dec 24 23:51:00 1994 |
| Return-Path: <pinard> |
| Received: by icule (Smail3.1.28.1 #1) |
| id m0rLkv4-00009AC; Sat, 24 Dec 94 23:50 EST |
| Message-Id: <m0rLkv4-00009AC@icule> |
| Date: Sat, 24 Dec 94 23:50 EST |
| From: pinard (Francois Pinard) |
| To: rms@gnu.ai.mit.edu |
| In-reply-to: <199412250445.XAA25324@mole.gnu.ai.mit.edu> (message from Richard Stallman on Sat, 24 Dec 1994 23:45:19 -0500) |
| Subject: Re: GNU standards and localized message catalogs |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding: 8bit |
| |
| *** EOOH *** |
| Date: Sat, 24 Dec 94 23:50 EST |
| From: pinard (Francois Pinard) |
| To: rms@gnu.ai.mit.edu |
| In-reply-to: <199412250445.XAA25324@mole.gnu.ai.mit.edu> (message from Richard Stallman on Sat, 24 Dec 1994 23:45:19 -0500) |
| Subject: Re: GNU standards and localized message catalogs |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding: 8bit |
| |
| * We also need a uniform convention about where, in the installed |
| hierarchy, to put translations of manuals in long term. |
| |
| I think they should go in the Info tree just like English manuals. |
| |
| Yes, of course. Suppose I have a French recode.info, and an |
| English one. This kind of thing will not be immediate, but they |
| will come. We need some convention to install both. We are not |
| to give them different names, presumably. People will like to |
| say, on an individual basis: ``if a French version of something is |
| available, I'll prefer it over the standard English one''. So we |
| need a convention to stock these, and a convention to select them. |
| |
| 1,, |
| Mail-from: From gnu.ai.mit.edu!rms Sun Dec 25 05:16:06 1994 |
| Return-Path: <gnu.ai.mit.edu!rms> |
| Received: by icule (Smail3.1.28.1 #1) |
| id m0rLpze-00009IC; Sun, 25 Dec 94 05:16 EST |
| Received: from lagrande.iro.umontreal.ca (lagrande.IRO.UMontreal.CA [132.204.32.32]) by iros1.IRO.UMontreal.CA (8.6.9/8.6.9) with ESMTP id AAA12366 for <icule!pinard>; Sun, 25 Dec 1994 00:01:47 -0500 |
| Received: from saguenay.IRO.UMontreal.CA (root@saguenay32.IRO.UMontreal.CA [132.204.32.54]) by lagrande.iro.umontreal.ca (8.6.9/8.6.9) with ESMTP id AAA10584 for <pinard@lagrande.IRO.UMontreal.CA>; Sun, 25 Dec 1994 00:01:46 -0500 |
| Received: from mole.gnu.ai.mit.edu (rms@mole.gnu.ai.mit.edu [128.52.46.33]) by saguenay.IRO.UMontreal.CA (8.6.9/8.6.9) with ESMTP id AAA14869 for <pinard@iro.umontreal.ca>; Sun, 25 Dec 1994 00:01:37 -0500 |
| Received: by mole.gnu.ai.mit.edu (8.6.9/4.0) |
| id <AAA25411@mole.gnu.ai.mit.edu>; Sun, 25 Dec 1994 00:01:33 -0500 |
| Date: Sun, 25 Dec 1994 00:01:33 -0500 |
| Message-Id: <199412250501.AAA25411@mole.gnu.ai.mit.edu> |
| From: Richard Stallman <rms@gnu.ai.mit.edu> |
| To: pinard@iro.umontreal.ca |
| In-reply-to: <m0rLkv4-00009AC@icule> (pinard@iro.umontreal.ca) |
| Subject: Re: GNU standards and localized message catalogs |
| |
| *** EOOH *** |
| Date: Sun, 25 Dec 1994 00:01:33 -0500 |
| From: Richard Stallman <rms@gnu.ai.mit.edu> |
| To: pinard@iro.umontreal.ca |
| In-reply-to: <m0rLkv4-00009AC@icule> (pinard@iro.umontreal.ca) |
| Subject: Re: GNU standards and localized message catalogs |
| |
| We need some convention to install both. We are not |
| to give them different names, presumably. |
| |
| I would give them different names. They would have |
| separate menu items in the Info directory. That is the |
| easiest way and it seems good enough, so I don't see a reason |
| to spend time looking for any other way. |
| |
| |
| 1, edited,, |
| Mail-from: From pinard Tue Jan 3 16:17:29 1995 |
| Return-Path: <pinard> |
| Received: by icule (Smail3.1.28.1 #1) |
| id m0rPGbe-00008xC; Tue, 3 Jan 95 16:17 EST |
| Message-Id: <m0rPGbe-00008xC@icule> |
| Date: Tue, 3 Jan 95 16:17 EST |
| From: pinard (Francois Pinard) |
| To: vern@ee.lbl.gov |
| In-reply-to: <199501031914.LAA00333@daffy.ee.lbl.gov> (message from Vern Paxson on Tue, 03 Jan 95 11:14:17 PST) |
| Subject: Re: Internationalization of Flex |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding: 8bit |
| |
| *** EOOH *** |
| Date: Tue, 3 Jan 95 16:17 EST |
| From: pinard (Francois Pinard) |
| To: vern@ee.lbl.gov |
| In-reply-to: <199501031914.LAA00333@daffy.ee.lbl.gov> (message from Vern Paxson on Tue, 03 Jan 95 11:14:17 PST) |
| Subject: Re: Internationalization of Flex |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding: 8bit |
| |
| There are two categories of patches: a grouped set at initialization |
| time, and all-over-the-place one which marks localizable strings. |
| We can consider them separately (but I will most probably end up |
| suggesting we give them the same treatment...). |
| |
| What would be easier would be that the original Flex sources already |
| marks all strings which require localization. The way I do it in my |
| things is merely replacing each "STRING" by _("STRING") *if* STRING |
| should be translated. Flex could then be distributed with: |
| |
| #define _(String) (String) |
| |
| effectively ignoring the marks. I may provide an initial patch |
| to you for this. Later on, the maintenance would be relatively |
| easy for you: if you add or modify a string, you will have to |
| ask yourself if the new or altered string requires translation, |
| and include it within _() if you think it should be translated. |
| "%s: %d" is an example of string not requiring translation... |
| |
| The remaining work will be handled by group of volunteers from |
| different countries. I took the responsibility of organizing how |
| these things will be done. Once in a while, volunteers will provide |
| you some COUNTRY.tt files which you might accept to distribute |
| with Flex. (COUNTRY is a two letter code, like `de' for German.) |
| If the COUNTRY.tt files ever lag with regard to Flex modifications, |
| this would not break nationalized Flex: the current mechanics will |
| merely return the original English string if a proper translation |
| cannot be found. So you do not even have to feel tied to the |
| translators for releasing new distributions for Flex. And nothing |
| is subject to the GPL so far :-). |
| |
| The initialization is not very complex, and can be done within |
| less than a dozen easy lines of code, hardly GPL'able. I think |
| they could be included in standard Flex distribution, while being |
| conditionalized out. The only harder modifications come from me, |
| and touch Makefile.in, for including all the machinery to prepare |
| and install locale message catalogs provided the underlying system |
| has what is needed. In the way I am now distributing my things, this |
| machinery automatically cut itself out when GNU locale is not usable. |
| |
| Remain only two modules, currently named libintl.h and libintl.c |
| (this might change), which are covered by the GPL, which you |
| do not want to distribute with Flex. The Flex README could |
| suggest installers to grab them from any other GNU distribution. |
| The configuration machinery might automatically check if they have |
| been copied by the installer and, if not, forget about localization. |
| |
| This way, Flex will be easily and widely nationalized, the GPL |
| principle will be safe, Flex will stay free of the GPL, and the |
| burden on the installers, as well as both you and me, will be |
| minimal in the long run. |
| |
| There is a difficulty I have not studied yet, and which comes from |
| the fact that Flex generates C code (Bison has the same problem). |
| Flex itself could be nationalized, and this is orthogonal to the fact |
| Flex could generate nationalizable scanners. Both are desirable. |
| |
| |
| 1, edited,, |
| Mail-from: From pinard Thu Jan 12 07:41:07 1995 |
| Return-Path: <pinard> |
| Received: by icule (Smail3.1.28.1 #1) |
| id m0rSOpt-00007LC; Thu, 12 Jan 95 07:41 EST |
| Message-Id: <m0rSOpt-00007LC@icule> |
| Date: Thu, 12 Jan 95 07:41 EST |
| From: pinard (Francois Pinard) |
| To: vern@ee.lbl.gov |
| In-reply-to: <199501051930.LAA04658@daffy.ee.lbl.gov> (message from Vern Paxson on Thu, 05 Jan 95 11:30:54 PST) |
| Subject: Re: Internationalization of Flex |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding: 8bit |
| |
| *** EOOH *** |
| Date: Thu, 12 Jan 95 07:41 EST |
| From: pinard (Francois Pinard) |
| To: vern@ee.lbl.gov |
| In-reply-to: <199501051930.LAA04658@daffy.ee.lbl.gov> (message from Vern Paxson on Thu, 05 Jan 95 11:30:54 PST) |
| Subject: Re: Internationalization of Flex |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding: 8bit |
| |
| Besides, not long after having started this i18n effort for my |
| own things, I realized that the i18n attribute should really be |
| attached to strings themselves, and not to what we do with them. |
| A blatant example is an error message produced by formatting. |
| The format string needs i18n, while the result from sprintf may |
| have so many different instances that it is unpractical to list |
| them all in some error_string_out() routine. I also got other |
| cases forcing me to concentrate on strings for i18n. |
| |
| There is a stylistic issue here. I use _("hello"), adding three |
| characters to each localizable string, while you will most probably |
| use _( "hello" ), adding five characters per localizable string. |
| Yet, it has the advantage of being shorter than error_string_out, |
| and be done at the right level. |
| |
| By merely defining _(String) to be (String), you just turn off |
| localization in standard flex, with not a single nanosecond spoiled |
| on it. But this will then allow me to produce a quite smaller and |
| maintainable patch for i18n of flex. |
| |
| This [error_string_out()] routine could then look up every string |
| passed it in a translation table that's compiled into flex |
| like the skel[] array. All that's needed is a public-domain |
| description of the format of the COUNTRY.tt translation files |
| and the rest should be easy. |
| |
| If I clearly understand your idea, you will compile in flex |
| a French table, and obtain a French speaking binary. You will |
| produce different binaries for Catalan, Dutch, etc. That is not |
| practical on big sites having multinational users. |
| |
| Right now in my things, the setting of LANG in the environment |
| decides the language to use, and there is a single binary to handle |
| all things. Further, the evolving GNU locale will soon change its |
| *.tt file format, and will try to use the current system underlying |
| localization mechanics, if any good one is found at configure time. |
| |
| There is no need that you redo all this and throw new solutions to |
| this whole set of problems. The most workable solution to me looks |
| like standard flex distribution already have all _() included -- and |
| that you accept routinely adding _() to new localizable strings when |
| you are doing flex maintenance, and that a separately distributed |
| patch attaches flex to GNU locale complexities, without having you |
| discovering and solving them anew. |
| |
| Let me know if this is workable (I'm willing to do the work). |
| |
| Let me take one hour this morning to offer you a patch for _() for |
| 2.5.0.6, hoping that you will accept it. That would be a start. Let |
| me take care of the remaining organizational problems, synchronizing |
| with other teams, etc. I already do this for other GNU packages |
| and will eventually help with most of them (I've accepted that role). |
| |
| Once we will have had success with i18ned flex for some time, it |
| would then become easier to convince you to go further for other |
| aspects (like *producing* i18nable scanners :-). |
| |
| Let me hope that my pleading for the cause will touch your heart, |
| somewhere :-). Keep happy! |
| |
| -- |
| François Pinard ``Happy GNU Year!'' pinard@iro.umontreal.ca |
| A New Year's gift? Give us Programming Freedom! Write lpf@uunet.uu.net |
| |
| |
| 1, edited,, |
| Mail-from: From pinard Thu Jan 12 16:44:56 1995 |
| Return-Path: <pinard> |
| Received: by icule (Smail3.1.28.1 #1) |
| id m0rSXKA-00007VC; Thu, 12 Jan 95 16:44 EST |
| Message-Id: <m0rSXKA-00007VC@icule> |
| Date: Thu, 12 Jan 95 16:44 EST |
| From: pinard (Francois Pinard) |
| To: vern@ee.lbl.gov |
| In-reply-to: <199501121822.KAA21713@daffy.ee.lbl.gov> (message from Vern Paxson on Thu, 12 Jan 95 10:22:40 PST) |
| Subject: Re: Internationalization of Flex |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding: 8bit |
| |
| *** EOOH *** |
| Date: Thu, 12 Jan 95 16:44 EST |
| From: pinard (Francois Pinard) |
| To: vern@ee.lbl.gov |
| In-reply-to: <199501121822.KAA21713@daffy.ee.lbl.gov> (message from Vern Paxson on Thu, 12 Jan 95 10:22:40 PST) |
| Subject: Re: Internationalization of Flex |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding: 8bit |
| |
| I'm not sure having to remember to use error_string_out() instead |
| of fprintf( stderr ... ) is any easier, though. |
| |
| Not only error strings are being made localizable by the patch I |
| shipped this morning, but also statistics, version and help, and |
| some debug output. These are not always error messages, and not |
| always sent to stderr. |
| |
| Sometimes in flex, messages are constructed in pieces using %s to |
| insert parts. Translating at the string level is the right approach |
| in these situations. I'm not sure error_string_out() would have been |
| satisfying (but I'm not going to argue, since I have your favor! :-) |
| |
| 1, edited, answered,, |
| Mail-from: From twinsun.com!eggert Tue Feb 14 05:16:50 1995 |
| Path: bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv |
| From: mike@vlsivie.tuwien.ac.at |
| Newsgroups: comp.unix.questions,comp.std.internat,comp.software.international,comp.lang.c,comp.windows.x,comp.std.c,comp.answers,news.answers |
| Subject: Programming for Internationalization FAQ |
| Supersedes: <internationalization/programming-faq_787570857@rtfm.mit.edu> |
| Followup-To: comp.unix.questions,comp.std.internat,comp.software.international,comp.lang.c,comp.windows.x,comp.std.c |
| Date: 15 Jan 1995 10:26:57 GMT |
| Organization: TU Wien |
| Lines: 564 |
| Approved: news-answers-request@MIT.EDU |
| Expires: 28 Feb 1995 10:26:07 GMT |
| Message-ID: <internationalization/programming-faq_790165567@rtfm.mit.edu> |
| NNTP-Posting-Host: bloom-picayune.mit.edu |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding: 8bit |
| Summary: This FAQ discusses writing programs which can handle |
| different language conventions/character sets/etc. |
| Applicable to all character set encodings; with particular |
| emphasis on ISO-8859-1. |
| X-Last-Updated: 1994/11/15 |
| Originator: faqserv@bloom-picayune.MIT.EDU |
| Xref: bloom-beacon.mit.edu comp.unix.questions:38263 comp.std.internat:2069 comp.software.international:1289 comp.lang.c:65751 comp.windows.x:34580 comp.std.c:7917 comp.answers:9514 news.answers:33146 |
| |
| *** EOOH *** |
| From: mike@vlsivie.tuwien.ac.at |
| Newsgroups: comp.unix.questions,comp.std.internat,comp.software.international,comp.lang.c,comp.windows.x,comp.std.c,comp.answers,news.answers |
| Subject: Programming for Internationalization FAQ |
| Supersedes: <internationalization/programming-faq_787570857@rtfm.mit.edu> |
| Followup-To: comp.unix.questions,comp.std.internat,comp.software.international,comp.lang.c,comp.windows.x,comp.std.c |
| Date: 15 Jan 1995 10:26:57 GMT |
| Organization: TU Wien |
| Approved: news-answers-request@MIT.EDU |
| Expires: 28 Feb 1995 10:26:07 GMT |
| NNTP-Posting-Host: bloom-picayune.mit.edu |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding: 8bit |
| Summary: This FAQ discusses writing programs which can handle |
| different language conventions/character sets/etc. |
| Applicable to all character set encodings; with particular |
| emphasis on ISO-8859-1. |
| X-Last-Updated: 1994/11/15 |
| Originator: faqserv@bloom-picayune.MIT.EDU |
| |
| |
| Archive-name: internationalization/programming-faq |
| Posting-Frequency: monthly |
| |
| |
| |
| Programming for Internationalization |
| |
| |
| |
| DISCLAIMER: THE AUTHOR MAKES NO WARRANTY OF ANY KIND WITH REGARD TO |
| THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES |
| OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. |
| |
| Note: Most of this was tested on a Sun 10, running SunOS 4.1.* - other |
| systems might differ slightly |
| |
| This FAQ discusses topics related to the use of ISO 8859-1 based 8 bit |
| character sets. It discusses how to program applications which support |
| the use European (Latin American) national character sets on |
| UNIX-based systems and standard C environments. |
| |
| |
| |
| 1. Which coding should I use for accented characters? |
| Use the internationally standardized ISO-8859-1 character set to type |
| accented characters. This character set contains all characters |
| necessary to type (West) European languages. This encoding is also the |
| preferred encoding on the Internet (where accepted - see below). |
| |
| This character set is also used by AmigaDOS, MS-Windows (Code Page |
| 1252 in Microsoft Speak. This is for Windows versions delivered in |
| the US, Europe (except Eastern Europe) and Latin America. In Windows |
| 3.1 Microsoft added additional characters in the 0x80-9F range), |
| VMS (DEC MCS is a draft version of the current ISO 8859-1 character |
| set standard and differs in only two characters) and (most) UNIX |
| implementations. MS-DOS uses a different character set and is not |
| compatible with this character set. |
| |
| ISO 8859-X actually is a family of character set standards. Basically |
| all of the information given here is also valid for these standards. |
| These standards comprise 8859-X: |
| 8859-1 Europe, Latin America |
| 8859-2 Eastern Europe |
| 8859-3 SE Europe/miscellaneous (Esperanto, Maltese, etc.) |
| 8859-4 Scandinavia/Baltic (mostly covered by 8859-1 also) |
| 8859-5 Cyrillic |
| 8859-6 Arabic |
| 8859-7 Greek |
| 8859-8 Hebrew |
| 8859-9 Latin5, same as 8859-1 except for Turkish instead of Icelandic |
| 8859-10 Latin6, for Eskimo/Scandinavian languages |
| |
| Another nascent standard is UNICODE (ISO 10646). UNICODE is an |
| extension of ISO 8859-1 (which itself is an extension of US-ASCII) to |
| 16 bit characters. Thus most of the world's languages (including |
| Japanese, Korean, Chinese...) can be covered. |
| |
| Most of the information given here is independent of the character |
| encoding used (e.g. DEC MCS, etc.), but can be applied to any |
| character set, providing the programming environment has provisions |
| for this standard. |
| |
| |
| |
| 2. Getting your environment right |
| To configure your environment such that you can enter, process and |
| display 8 bit ISO characters, check out the ISO-8859-1 FAQ available |
| via anonymous ftp from ftp.vlsivie.tuwien.ac.at in |
| /pub/8bit/FAQ-ISO-8859-1. |
| |
| |
| |
| 3. Setting your environment for ISO-C (ANSI-C) programs |
| The ISO C Standard (ANSI C Standard 4.4) defines several functions for |
| supporting localization. To set your international environment on |
| program startup, you should make one or several calls to the setlocale |
| functions. Calls to this function will predetermine the reaction of |
| other localization functions according to your language/country |
| environment. |
| |
| To configure a particular aspect of you environment, say the number |
| representation, you would call |
| -- |
| setlocale (LC_NUMERIC, "Germany"); |
| -- |
| |
| This call would set all number representation functions defined in the |
| localization set to return numbers in the format used in Germany. If |
| the call was successful, setlocale will return the name of your |
| locale. A NULL return value indicates failure. Note that the |
| environments are predetermined outside your C program by the system |
| you run on. (So the example given here is likely to fail on all but a |
| few systems.) Check the setlocale manual page or your system |
| documentation to find out about the environments available. |
| |
| There are several LOCALE types available for different localization |
| aspects (currency sign, number representation, characters sets). The |
| value they can take is highly system dependent. Also, it should be up |
| to the use to define the local environment he needs. |
| |
| A C program inherits its locale environment variables when it starts up. |
| This happens automatically. However, these variables do not |
| automatically control the locale used by the library functions, because |
| ISO/ANSI C says that all programs start by default in the standard C |
| locale. To use the locales specified by the environment, The POSIX |
| standard defines the following call: |
| ----- |
| setlocale (LC_ALL, ""); |
| ----- |
| |
| Of course, you can only set part of your environment, by calling, say: |
| ---- |
| setlocale (LC_CTYPE, ""); |
| ---- |
| This only defines the character classification macros (defined in |
| ctype.h). |
| |
| This is a list of local categories: |
| |
| Effect of Specifying Environment Variable |
| category the Value Affected |
| __________________________________________________________ |
| |
| LC_ALL Sets or queries LANG |
| entire environment |
| LC_COLLATE Changes or queries LC_COLLATE |
| collation sequences |
| LC_CTYPE Changes or queries LC_CTYPE |
| character classifi- |
| cation |
| LC_NUMERIC Changes or queries LC_NUMERIC |
| number format infor- |
| mation |
| LC_TIME Changes or queries LC_TIME |
| time conversion |
| parameters |
| LC_MONETARY Changes or queries LC_MONETARY |
| monetary information |
| |
| |
| |
| |
| 4. Using the locale information for character classification |
| If you write a program which supports international use, you should |
| use the available standardized functions, as only these will be |
| influenced by the setlocale call. Thus, if you want to convert a |
| capital letter in c to a lower case letter in l, _don't_ write: |
| |
| l = c - 'A' + 'a'; |
| |
| While this will work for characters in the US-ASCII character set, it |
| will not work with many other character sets. The following, |
| standard-conformant code will: |
| |
| #include <ctype.h> |
| |
| .... |
| |
| l = tolower(c); |
| |
| Also note that the second code may actually be faster than even the |
| full "C" locale functionality (for most implementations), as it |
| replaces a complex expression ( (c<='Z' && c>='A')? c-'A'+a:c; )by a simple |
| table lookup! |
| |
| Note that this ISO standard is independent of the character set |
| encoding used! |
| |
| |
| |
| 5. Language independent messages |
| There are two competing standards for language independent messages: |
| one by X/Open, and another one by POSIX. The X/Open standard seems to |
| have found a larger following as it has been around for a longer time. |
| |
| 5.1 X/Open language independent messages |
| X/Open defines a method for providing language-independent messages. |
| Error messages are kept in a catalog which is opened upon program |
| start with a locale specification. Then the message number and a set |
| specification are used to index the message catalog. A default fourth |
| argument is specified which will be printed if a particular message |
| cannot be found in the catalog. |
| |
| Here is the world-famous C program using the language-independent |
| X/Open message standard: |
| -------------------------------------------------------------------------- |
| #include <stdio.h> |
| #include <nl_types.h> |
| |
| #define SET 1 |
| #define MSG_HELLO 1 |
| |
| nl_catd catfd; |
| |
| int main (int argc, char **argv) { |
| /* Open the message catalog. We use the basename of the program |
| * as the catalog name. Of course, several programs can also |
| * share a common catalog. |
| */ |
| catfd = catopen (basename (argv [0]), NL_CAT_LOCALE); |
| /* catgets returns message MSG_HELLO from set SET from the |
| * message catalog catfd. If catfd does not refer to a message |
| * catalog, or the requested message cannot be found, the |
| * catalog, or the requested message cannot be found, the |
| * fourth argument is returned. |
| */ |
| printf (catgets (catfd, SET, MSG_HELLO, "hello, world\n")); |
| catclose (catfd); |
| return 0; |
| } |
| ------------------------------------------------------------------------- |
| |
| For catopen, specify the constant NL_CAT_LOCALE to open the message |
| catalog for the locale set for the LC_MESSAGES variable; using |
| NL_CAT_LOCALE conforms to the XPG4 standard. You can specify 0 (zero) |
| for compatibility with XPG3; when oflag is set to zero, the locale set |
| for the LANG variable determines the message catalog locale. |
| |
| Several utilities exist for generating message catalogs and for |
| upgrading programs which contain hard-wired strings: |
| * gencat is used to generate message catalogs |
| [All other programs are OS-specific:] |
| * Ultrix and OSF support the extract program which will extract string |
| constants from the C source code, and has an option to replace these |
| strings with calls to catgets. |
| * HP/UX has a similar utility called findmsg. |
| * Under OSF, message catalogs may be listed with the dspcat utility. |
| * HP/UX calls a similar utility dumpmsg. |
| |
| |
| 5.2 Sun/XView |
| Sun implements a different set of functions functions to support i18n |
| of messages (the source is available with the XView code): |
| |
| You can either use: |
| ----------------------------------------------- |
| |
| main() |
| { |
| // get the message catalog named "helloprogram" |
| // for the hello world program |
| textdomain("helloprogram"); |
| |
| // get the translation for the "Hello, world\n" string |
| printf(gettext("Hello, world\n")); |
| } |
| ----------------------------------------------- |
| |
| or you can roll all in one and write |
| |
| ----------------------------------------------- |
| main() |
| { |
| // get the translation for the "Hello, world\n" string |
| // from the message catalog "helloprogram" |
| printf(dgettext("helloprogram","Hello, world\n")); |
| } |
| ----------------------------------------------- |
| |
| The LC_MESSAGES locale category setting determines the locale of |
| strings that gettext() returns. The message catalogs are generated |
| with either the installtxt or gencat commands. |
| |
| No opening of files as in the old SYS V and X/Open routines, and no |
| handling of message numbers that you must have in a database to |
| administer. |
| |
| |
| 5.3 POSIX language independent messages |
| Neither of the previous two mechanisms is in the POSIX standard. |
| There was much disagreement in the POSIX.1 committee about using the |
| gettext routines vs. catgets (XPG). In the end the committee couldn't |
| agree on anything, so no messaging system was included as part of the |
| standard. I believe the informative annex of the standard includes the |
| XPG3 messaging interfaces, "...as an example of a messaging system |
| that has been implemented..." |
| |
| They were very careful not to say anywhere that you should use one set |
| of interfaces over the other. |
| |
| |
| |
| 6. Other localization aspects in ISO/ANSI C (and POSIX environments) |
| For a more thorough discussion of localization and |
| internationalization (aka. i18n), check your system vendors |
| documentation, and the C library manual which comes with the FSF's |
| glibc library (Chapter 19, 'Locales and Internationalization'). |
| |
| |
| |
| 7. Internationalization under X11 |
| 7.1 Output |
| To output text encoded with ISO 8859-1 under X11, simply invoke the X |
| display routines with 8 bit characters as you would use them with |
| 7-bit ASCII. You should however choose a font which contains bitmaps |
| for these characters. You can use the xfd utility to display a font |
| to verify that it contains a full set of characters. |
| |
| |
| 7.2 Input |
| If you use a national keyboard (that is a keyboard, which has distinct |
| keys for your countries special characters), inputting accents is |
| straight forward and you'll get the corresponding characters by using |
| the X11 input functions. |
| |
| Sometimes it may be necessary to input characters for which there are |
| no keys on your keyboard (e.g. if you want to enter the German 'ß' |
| from a French keyboard). |
| |
| X11R5 and X11R6 both have extensive support for i18n, but due to a |
| variety of factors the R5 i18n was not well understood or widely |
| used. Many people resorted to a work-around and might have been |
| disappointed when R6 did not include this misfeature. It is important |
| to recognize that the correct use of R5 and R6 i18n features will |
| ensure maximum portability of your program. |
| |
| Footnote: Amongst other reasons, the X Consortium decision not to add |
| support for input methods to the Xaw Athena widget contributes to this |
| situation. Many users (and much of the PD software) live in an |
| Xaw-only world, so they will not be able to benefit from this i18n |
| effort. |
| |
| X11 R5 and R6 support input methods for entering non-ASCII, and |
| displaying and configuring text, menus etc. for a wide variety of |
| languages. This input method has to be installed by the application |
| by calls to the Xlib library (or an Xt toolkit call). |
| |
| [Under X11R5, some X servers (notably the Xsun server) will let you |
| enter ISO characters by supplying a built-in escape mechanism, if no |
| keys for these characters are on your keyboard, and will pass along |
| and display ISO 8859-1. This hack obviated the need to install an |
| input method, but was less flexible.] |
| |
| |
| If you are using a toolkit, it is quite simple to support localization |
| of you X11 code: |
| If you're using a toolkit -- Xt and a widget set like Motif or R6 Xaw -- |
| you need only add a single line of code to your source. Before any other |
| calls to Xt, add a call to XtSetLanguageProc, e.g.: |
| |
| int main (int argc, char** argv) |
| { |
| ... |
| XtSetLanguageProc (NULL, NULL, NULL); |
| top = XtAppInitialize ( ... ); |
| ... |
| } |
| |
| The LANG and LC_xxx environment variables (see section 3) will then be |
| used to determine the 'input method' for this X application. This |
| input method is responsible for managing COMPOSE character sequences |
| or any other input mechanism for this particular implementation. Also |
| see section 9 of ftp://ftp.vlsivie.tuwien.ac.at/pub/8bit/FAQ-ISO-8859-1, |
| the FAQ on ISO 8859-1 usage. |
| |
| |
| 7.3 Toolkits, Widgets, and I18N |
| The preferred way of inputing national characters when a national |
| keyboard is not available is one/several input methods. These input |
| methods will then support various kinds of compose sequences to enter |
| national characters. |
| |
| The environment variables LANG and/or LC_xxx select the language for |
| the Input Method (IM), but if several input methods exist, the |
| environment variable XMODIFIERS can be used to select a specific input |
| method. |
| |
| Xlib supports IMs |
| Xt supports IMs |
| Xaw does not support IMs |
| |
| Thus, applications written with Xlib or Xt can support IMs (see |
| section 7.2 on how to install input methods under Xt), but Xaw based |
| applications will not. |
| |
| Motif 1.2 or greater automatically uses the R5/R6 input method APIs. |
| Thus applications using Motif 1.2+ can be made to support IMs. |
| Several Motif 1.[01] versions also had similar functionality added to |
| them by the respective vendors, but these extensions are |
| vendor-specific and not portable. |
| |
| FOOTNOTE: If you can have comments/corrections for this section and on |
| OpenLook, please let me know. |
| |
| |
| 7.4 I18N under X11R6, General Information |
| Background information from the X11R6 announcement: |
| Internationalization (also known as I18N, there being 18 letters between the |
| i and n) of the X Window System, which was originally introduced in Release |
| 5, has been significantly improved in R6. The R6 I18N architecture follows |
| that in R5, being based on the locale model used in ANSI C and POSIX, with |
| most of the I18N capability provided by Xlib. R5 introduced a fundamental |
| framework for internationalized input and output. It could enable basic |
| localization for left-to-right, non-context sensitive, 8-bit or multi-byte |
| codeset languages and cultural conventions. However, it did not deal with |
| all possible languages and cultural conventions. R6 also does not cover all |
| possible languages and cultural conventions, but R6 contains substantial new |
| Xlib interfaces to support I18N enhancements, in order to enable additional |
| language support and more practical localization. |
| |
| The additional support is mainly in the area of text display. In order to |
| support multi-byte encodings, the concept of a FontSet was introduced in R5. |
| In R6, Xlib enhances this concept to a more generalized notion of output |
| methods and output contexts. Just as input methods and input contexts sup- |
| port complex text input, output methods and output contexts support complex |
| and more intelligent text display, dealing not only with multiple fonts but |
| also with context dependencies. The result is a general framework to enable |
| bi-directional text and context sensitive text display. |
| |
| The description of the X11R6 internationalization framework is |
| available via anonymous ftp from ftp.x.org in |
| /pub/R6untarred/xc/doc/specs/i18n. |
| |
| |
| |
| 8. Supporting I18N Network Protocols |
| 8.1 MIME |
| MIME is specified in RFC 1521 and RFC 1522 which are available from |
| ftp.uu.net. There is also a MIME FAQ which is available via anonymous |
| ftp from ftp.ics.uci.edu in /mh/contrib/multimedia/mime-faq.txt.gz. |
| (This file is in compressed format. You will need the GNU gunzip |
| program to decompress this file.) |
| |
| If you want to write applications which support the MIME protocol, |
| there are several libraries/tools which can ease your task: |
| |
| |
| 8.1.1 metamail |
| Source for supporting MIME (the `metamail' package) in various mail |
| readers is available via anonymous ftp from thumper.bellcore.com in |
| /pub/nsb. This distribution consists of several utilities, which can |
| be called by MIME applications to handle MIME types. |
| |
| |
| 8.1.2 MIMElt |
| A "lightweight" MIME library available via anon ftp from |
| oslonett.no:Software/MsDos/Comm/Offline/mimeltXX.zip |
| |
| It is source code (ANSI C) packaged as a library to facilitate |
| construction of a limited MIME facility (limited == handling only |
| character-set aspects of MIME, not the multimedia-aspects). It |
| includes hooks to recode character sets into whatever system you are |
| running off (e.g. if you read mail on a MsDos platform using CP-850, |
| MIMElite may be set up so that QUOTED-PRINTABLE ISO Latin 1 is recoded |
| into CP-850 for reading and saving to file). |
| |
| It's main use is to provide programmers of so-called "off-line |
| readers" (used by user's who access Internet mail through dial-up |
| service providers) with the tools needed to include proper support for |
| QUOTED-PRINTABLE encoding in their product. |
| |
| The archive also contain a couple of sample applications that |
| demonstrates how the library may be used. UNMIME is a stand-alone |
| utility to decode MIME-encoded messages (e.g. it works like UUDECODE |
| for binary files with BASE64 encoding), SENDMIME is a simple utility |
| to send MIME-encoded messages if your service provider doesn't have |
| PINE or similar tools. |
| |
| The current version (2.1) is limited to character set issues. I am |
| about to release version 2.2, which will support additional |
| Content-Types (e.g. "application/octet-stream"). |
| |
| |
| |
| 9. Programming in Prolog |
| SICStus Prolog accepts ISO characters as part of atoms, so you can |
| even define goal names containing accented characters. I/O of 8 bit |
| characters is (obviously) also supported. |
| |
| |
| |
| 10. ISO 8859-1 on non-UNIX systems |
| 10.1 MS-DOS |
| MS-DOS generally uses its own characters set. There are several code |
| pages (one with the same symbols as ISO 8859-1, albeit at different |
| character code positions, which can lead to problems with the transfer |
| of data). |
| |
| If interoperability without data conversion is your goal, you can |
| reconfigure your MS-DOS PC to use an ISO-8859-1 code page. Check out |
| the anonymous ftp archive ftp.uni-erlangen.de, which contains data on |
| how to do this (and other ISO-related stuff) in /pub/doc/ISO/charsets. |
| The README file contains an index of the files you need. |
| |
| Most (all?) C compilers/libraries for MS-DOS have only minimal support |
| for the ANSI/POSIX locale mechanism. The setlocale() and localeconv() |
| calls (and stuff like strxfrm()) are generally hardwired. |
| |
| |
| 10.2 MS Windows |
| MS-Windows (using code page 1252) normally uses the first 256 |
| characters of Unicode, which is (for all practical purposes) |
| equivalent to ISO 8859-1. Thus, data representation and conversion |
| for interoperability with other ISO 8859-1 compliant systems is not an |
| issue. |
| |
| It seems that C libraries for MS Windows do not support the ANSI/POSIX |
| locale mechanism. (If you have any experiences with that, please let |
| me know.) There is a POSIX-like mechanism in some Microsoft platform |
| services, but none in the compilers from any vendor. |
| |
| |
| 10.3 OS/2 |
| Text mode OS/2 programs generally suffer the same limitations as do |
| MS-DOS programs, because the display hardware is the same. |
| |
| Presentation Manager OS/2 programs using code page 1004 will order |
| the font glyphs in the same sequence as ISO 8859-1 (although of |
| course whether the glyphs will actually look anything like those |
| from ISO 8859-1 depends entirely from the font). |
| |
| The IBM CSet++ compiler supports full internationalization, with |
| several predefined locales. |
| |
| The Borland C++ compiler supports only the "C" locale. |
| |
| The Watcom C++ compiler supports only the "C" locale. |
| |
| The Metaware High C++ compiler supports only the "C" locale. It |
| does, however, also support UNICODE, providing UNICODE character |
| types and UNICODE versions of the appropriate parts of the standard |
| library (including I/O). |
| |
| |
| |
| 10.4 Apple Macintosh |
| MacIntoshes have their own non-standard character encodings; |
| the first 128 characters are US-ASCII but the remaining characters are |
| non-standard. |
| |
| I do not know whether C libraries (for which compilers?) for the |
| MacIntosh support the ANSI/POSIX locale mechanism. If you have any |
| experiences with that, please let me know. |
| |
| |
| 10.5 Amiga |
| The AmigaOS uses ISO-8859-1. As of OS version 2.1, Amiga-specific |
| means of localization are available. |
| |
| |
| |
| 11. Home location of this document |
| The most recent version of this document is available via anonymous |
| ftp from ftp.vlsivie.tuwien.ac.at under the file name |
| /pub/8bit/ISO-programming. |
| |
| ----------------- |
| |
| Copyright © 1994 Michael Gschwind (mike@vlsivie.tuwien.ac.at) |
| |
| This document may be copied for non-commercial purposes, provided this |
| copyright notice appears. Publication in any other form requires the |
| author's consent. |
| |
| Dieses Dokument darf unter Angabe dieser urheberrechtlichen |
| Bestimmungen zum Zwecke der nicht-kommerziellen Nutzung beliebig |
| vervielfältigt werden. Die Publikation in jeglicher anderer Form |
| erfordert die Zustimmung des Autors. |
| |
| Michael Gschwind, Institut f. Technische Informatik, TU Wien |
| snail: Treitlstrasse 3-182-2 || A-1040 Wien || Austria |
| email: mike@vlsivie.tuwien.ac.at note: real time != real fast |
| phone: +(43)(1)58801 8156 fax: +(43)(1)586 9697 |
| |
| |
| 1, edited, resent,, |
| Mail-from: From li.org!owner-li-international Fri Jan 20 08:56:04 1995 |
| Return-Path: <li.org!owner-li-international> |
| Received: by icule (Smail3.1.28.1 #1) |
| id m0rVJon-00009Da; Fri, 20 Jan 95 08:56 EST |
| Sender: li.org!owner-li-international |
| Received: from lagrande.iro.umontreal.ca (lagrande.IRO.UMontreal.CA [132.204.32.32]) by iros1.IRO.UMontreal.CA (8.6.9/8.6.9) with ESMTP id RAA25970 for <icule!pinard>; Mon, 16 Jan 1995 17:34:02 -0500 |
| Received: from saguenay.IRO.UMontreal.CA (root@saguenay32.IRO.UMontreal.CA [132.204.32.54]) by lagrande.iro.umontreal.ca (8.6.9/8.6.9) with ESMTP id RAA14270 for <pinard@lagrande.IRO.UMontreal.CA>; Mon, 16 Jan 1995 17:33:53 -0500 |
| Received: from uniwa.uwa.edu.au (root@uniwa.uwa.edu.au [130.95.128.1]) by saguenay.IRO.UMontreal.CA (8.6.9/8.6.9) with ESMTP id RAA07348 for <pinard@iro.umontreal.ca>; Mon, 16 Jan 1995 17:33:41 -0500 |
| Received: from orac.aust.li.org (orac.iinet.com.au [203.0.178.134]) by uniwa.uwa.edu.au (8.6.9/8.6.9) with ESMTP id GAA22040; Tue, 17 Jan 1995 06:29:21 +0800 |
| Received: (from majordom@localhost) by orac.aust.li.org (8.6.9/8.6.9) id FAA01118 for li-international-list; Tue, 17 Jan 1995 05:34:39 +0800 |
| Received: from alcor (alcor.twinsun.com [198.147.65.1]) by orac.aust.li.org (8.6.9/8.6.9) with ESMTP id FAA01112 for <li-international@li.org>; Tue, 17 Jan 1995 05:34:28 +0800 |
| Received: from twinsun.com (twinsun.twinsun.com [192.54.239.2]) by alcor (8.6.5/8.6.5) with SMTP id NAA04793 for <li-international@li.org>; Mon, 16 Jan 1995 13:06:52 -0800 |
| Received: from spot.twinsun.com by twinsun.com (4.1/SMI-4.1) |
| id AA06664; Mon, 16 Jan 95 13:33:30 PST |
| Received: by spot.twinsun.com (4.1/SMI-4.1) |
| id AA04256; Mon, 16 Jan 95 13:33:30 PST |
| Old-From: eggert@twinsun.com (Paul Eggert) |
| Message-Id: <9501162133.AA04256@spot.twinsun.com> |
| Date: 16 Jan 1995 13:33:28 -0800 |
| To: li-international@li.org |
| Subject: ISO Normative Addendum 1 and its effect on the C library |
| From: International List <li-international@li.org> |
| Sender: owner-li-international@li.org |
| Precedence: bulk |
| Reply-To: LI-international@li.org |
| |
| *** EOOH *** |
| From: eggert@twinsun.com (Paul Eggert) |
| Date: 16 Jan 1995 13:33:28 -0800 |
| To: li-international@li.org |
| Subject: ISO Normative Addendum 1 and its effect on the C library |
| Reply-To: LI-international@li.org |
| |
| Normative Addendum 1 (NA1) to the ISO C standard was approved last year, |
| and I recently ran across a nice summary written by Clive Feather. |
| Please see <http://sf.www.lysator.liu.se/c/nal.html> for this; |
| |
| Most of the changes required by NA1 are to the C library's wide |
| character and multibyte string support. I don't see these changes |
| mentioned in the latest glibc snapshot. I asked Roland McGrath, |
| glibc's developer, about this, and he replied: |
| |
| Date: Mon, 16 Jan 95 15:53:26 -0500 |
| From: Roland McGrath <roland@gnu.ai.mit.edu> |
| |
| I think if you make the specifications available to the Linux community, |
| the new library functions will get written and contributed to glibc. |
| Try the mailing list li-international@li.org. |
| |
| So I'm sending this message to li-international. I can forward a copy |
| of the NA1 summary to whoever needs it; just ask. |
| |
| Two of the NA1 changes (__STDC_VERSION__ and digraphs) require changes |
| to GCC itself; I've volunteered to do this. One change (namely |
| <iso646.h>) can be done either in GCC or in libc, though if GCC does |
| digraphs it may make more sense for it to do <iso646.h> as well. |
| But the other changes belong to the C library proper. |
| |
| |
| |
| 1,, |
| Mail-from: From twinsun.com!eggert Tue Feb 14 05:16:49 1995 |
| Return-Path: <twinsun.com!eggert> |
| Received: by icule (Smail3.1.28.1 #1) |
| id m0reKJK-00009mC; Tue, 14 Feb 95 05:16 EST |
| Received: from lagrande.iro.umontreal.ca (lagrande.IRO.UMontreal.CA [132.204.32.32]) by iros1.IRO.UMontreal.CA (8.6.9/8.6.9) with ESMTP id CAA00816 for <icule!pinard>; Tue, 14 Feb 1995 02:16:27 -0500 |
| Received: from saguenay.IRO.UMontreal.CA (root@saguenay32.IRO.UMontreal.CA [132.204.32.54]) by lagrande.iro.umontreal.ca (8.6.9/8.6.9) with ESMTP id CAA02807 for <pinard@lagrande.IRO.UMontreal.CA>; Tue, 14 Feb 1995 02:16:20 -0500 |
| Received: from alcor.twinsun.com (alcor.twinsun.com [198.147.65.1]) by saguenay.IRO.UMontreal.CA (8.6.9/8.6.9) with ESMTP id CAA29451 for <pinard@iro.umontreal.ca>; Tue, 14 Feb 1995 02:16:16 -0500 |
| Received: from twinsun.com (twinsun.twinsun.com [192.54.239.2]) by alcor.twinsun.com (8.6.5/8.6.5) with SMTP id WAA03362 for <pinard@iro.umontreal.ca>; Mon, 13 Feb 1995 22:44:50 -0800 |
| Received: from spot.twinsun.com by twinsun.com (4.1/SMI-4.1) |
| id AA08130; Mon, 13 Feb 95 23:15:06 PST |
| Received: by spot.twinsun.com (4.1/SMI-4.1) |
| id AA05763; Mon, 13 Feb 95 23:15:05 PST |
| From: eggert@twinsun.com (Paul Eggert) |
| Message-Id: <9502140715.AA05763@spot.twinsun.com> |
| Date: 13 Feb 1995 23:15:04 -0800 |
| To: pinard@iro.umontreal.ca |
| In-Reply-To: <m0rdrDE-00009QC@icule> (pinard@iro.umontreal.ca) |
| Subject: Re: glocale and Uniforum gettext simplicity |
| |
| *** EOOH *** |
| From: eggert@twinsun.com (Paul Eggert) |
| Date: 13 Feb 1995 23:15:04 -0800 |
| To: pinard@iro.umontreal.ca |
| In-Reply-To: <m0rdrDE-00009QC@icule> (pinard@iro.umontreal.ca) |
| Subject: Re: glocale and Uniforum gettext simplicity |
| |
| |
| Date: Sun, 12 Feb 95 22:12 EST |
| From: pinard@iro.umontreal.ca (Francois Pinard) |
| |
| Hello, Paul. |
| |
| For more on this topic please see the Programming |
| for Internationalization FAQ (Message-ID: |
| <internationalization/programming-faq_784901999@rtfm.mit.edu>) |
| which I can forward to you if you like. |
| |
| Would you do this, please? |
| |
| Sure, the latest revision be in my next message. For future |
| reference, the coordinates are |
| <ftp://rtfm.mit.edu/pub/usenet-by-group/comp.answers/internationalization/programming-faq>. |
| |
| Alas, I haven't had time to work on this much lately -- beset with hardware |
| problems at home and no time to fix them.... |
| |
| |
| 1, edited,, |
| Mail-from: From pinard Tue Mar 21 12:53:53 1995 |
| Return-Path: <pinard> |
| Received: by icule (Smail3.1.28.1 #1) |
| id m0rr87q-00009TC; Tue, 21 Mar 95 12:53 EST |
| Message-Id: <m0rr87q-00009TC@icule> |
| Date: Tue, 21 Mar 95 12:53 EST |
| From: pinard (François Pinard) |
| To: meyering@comco.com |
| CC: drepper@ipd.info.uni-karlsruhe.de |
| In-reply-to: <199503211712.LAA25472@idefix.comco.com> (message from Jim Meyering on Tue, 21 Mar 1995 11:12:49 -0600) |
| Subject: Re: international fileutils |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding: 8bit |
| |
| *** EOOH *** |
| Date: Tue, 21 Mar 95 12:53 EST |
| From: pinard (François Pinard) |
| To: meyering@comco.com |
| CC: drepper@ipd.info.uni-karlsruhe.de |
| In-reply-to: <199503211712.LAA25472@idefix.comco.com> (message from Jim Meyering on Tue, 21 Mar 1995 11:12:49 -0600) |
| Subject: Re: international fileutils |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding: 8bit |
| |
| There are three things to do for each package: |
| |
| * Adjust Autoconf and Makefiles |
| * Mark all localizable strings in sources and doing other adjustments |
| * Translating messages for French (and maybe, let's be fair, German :-). |
| |
| 1, edited,, |
| Mail-from: From pinard Sun Apr 23 13:26:30 1995 |
| Return-Path: <pinard> |
| Received: by icule (Smail3.1.28.1 #1) |
| id m0s35QR-00008FC; Sun, 23 Apr 95 13:26 EDT |
| Message-Id: <m0s35QR-00008FC@icule> |
| Date: Sun, 23 Apr 95 13:26 EDT |
| From: pinard (François Pinard) |
| To: Jim Meyering <meyering@comco.com>, |
| Ulrich Drepper <drepper@gnu.ai.mit.edu>, |
| Roland McGrath <roland@gnu.ai.mit.edu>, |
| Paul Eggert <eggert@twinsun.com> |
| Subject: GNU locale and Ulrich's effort |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding: 8bit |
| |
| *** EOOH *** |
| Date: Sun, 23 Apr 95 13:26 EDT |
| From: pinard (François Pinard) |
| To: Jim Meyering <meyering@comco.com>, |
| Ulrich Drepper <drepper@gnu.ai.mit.edu>, |
| Roland McGrath <roland@gnu.ai.mit.edu>, |
| Paul Eggert <eggert@twinsun.com> |
| Subject: GNU locale and Ulrich's effort |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding: 8bit |
| |
| I'm trying to get started the overall effort for GNU localization, |
| by offering translators GNU packages to translate, and the means |
| to do so. I also do not want to spoil the energies being offered. |
| Many pieces of the puzzle are in place already and, as usual, I |
| contemplate them all trying to see what is missing, and working |
| towards the complete picture. |
| |
| Surely to me, GNU locale (glocale, as a package) has to provide a |
| fairly complete set of self-contained tools for helping package |
| maintainers to internationalize their product, and also for |
| localizers to translate message catalogs. Further, being itself |
| internationalized, it should be a very carefully crafted example |
| for maintainers, about how one might set his/her own package to be |
| easily installed while localization is effective, and portably! |
| |
| |
| |
| 1,, |
| Mail-from: From pinard Mon May 1 22:16:31 1995 |
| Return-Path: <pinard> |
| Received: by icule (Smail3.1.28.1 #1) |
| id m0s67Vl-00008NC; Mon, 1 May 95 22:16 EDT |
| Message-Id: <m0s67Vl-00008NC@icule> |
| Date: Mon, 1 May 95 22:16 EDT |
| From: pinard (=?ISO-8859-1?Q?Fran=E7ois_Pinard?=) |
| To: gnu@prep.ai.mit.edu |
| CC: rms@gnu.ai.mit.edu |
| In-reply-to: <9505020044.AA12891@pizza> (gnu@ai.mit.edu) |
| Subject: Re: [pinard@iro.umontreal.ca: Internationalizing GNU: the maintainer side] |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding: 8bit |
| |
| *** EOOH *** |
| Date: Mon, 1 May 95 22:16 EDT |
| From: pinard (François Pinard) |
| To: gnu@prep.ai.mit.edu |
| CC: rms@gnu.ai.mit.edu |
| In-reply-to: <9505020044.AA12891@pizza> (gnu@ai.mit.edu) |
| Subject: Re: [pinard@iro.umontreal.ca: Internationalizing GNU: the maintainer side] |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding: 8bit |
| |
| It contains some statements that are harsh and, I believe, |
| not true. The practice of using gettext to mark strings is |
| *not* just "for the time being." |
| |
| Fran\cois: Could you work with rms to update the GNU coding |
| standards to describe what GNUers needs to be do to make their |
| GNU programs use GNU Locale. |
| |
| I may try, but do not know exactly how to proceed. I also confess |
| I've rewritten this paragraph twenty times, to merely censor myself. |
| |
| We can then post that section of the GNU coding standards, so |
| all the GNUers know what to do. |
| |
| If GNU ever publishes utilities for Native Language Support, their |
| own documentation should explain how to proceed, and maintainers |
| should find in there the information they need about what to do. |
| GNU standards might state the general principle, something like: |
| ``GNU programs and packages should be opened to Native Language |
| Support (NLS) and, in particular, be able to write their messages |
| translated into native languages, as selected at run time by |
| environment variables''. |
| |
| -- |
| François Pinard ``Vivement GNU!'' <pinard@iro.umontreal.ca> |
| Email lpf@uunet.uu.net for info about the League for Programming Freedom. |
| |
| |
| 1,, |
| Mail-from: From IRO.UMontreal.CA!pinard Tue May 2 05:16:32 1995 |
| Return-Path: <IRO.UMontreal.CA!pinard> |
| Received: by icule (Smail3.1.28.1 #1) |
| id m0s6E4E-0000CaC; Tue, 2 May 95 05:16 EDT |
| Received: from lagrande.iro.umontreal.ca (lagrande.IRO.UMontreal.CA [132.204.32.32]) by iros1.IRO.UMontreal.CA (8.6.9/8.6.9) with ESMTP id AAA19507 for <icule!pinard>; Tue, 2 May 1995 00:02:38 -0400 |
| Received: (from pinard@localhost) by lagrande.iro.umontreal.ca (8.6.9/8.6.9) id AAA00659 for icule!pinard; Tue, 2 May 1995 00:02:37 -0400 |
| Received: from saguenay.IRO.UMontreal.CA (saguenay32.IRO.UMontreal.CA [132.204.32.54]) by lagrande.iro.umontreal.ca (8.6.9/8.6.9) with ESMTP id AAA00657 for <pinard@lagrande.IRO.UMontreal.CA>; Tue, 2 May 1995 00:02:34 -0400 |
| Received: from mole.gnu.ai.mit.edu (mole.gnu.ai.mit.edu [128.52.46.33]) by saguenay.IRO.UMontreal.CA (8.6.9/8.6.9) with ESMTP id AAA08792 for <pinard@iro.umontreal.ca>; Tue, 2 May 1995 00:02:33 -0400 |
| Received: by mole.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id AAA07143; Tue, 2 May 1995 00:02:31 -0400 |
| Date: Tue, 2 May 1995 00:02:31 -0400 |
| Message-Id: <199505020402.AAA07143@mole.gnu.ai.mit.edu> |
| From: Richard Stallman <rms@gnu.ai.mit.edu> |
| To: pinard@IRO.UMontreal.CA |
| In-reply-to: <m0s67Vl-00008NC@icule> (pinard@iro.umontreal.ca) |
| Subject: Re: [pinard@iro.umontreal.ca: Internationalizing GNU: the maintainer side] |
| |
| *** EOOH *** |
| Date: Tue, 2 May 1995 00:02:31 -0400 |
| From: Richard Stallman <rms@gnu.ai.mit.edu> |
| To: pinard@IRO.UMontreal.CA |
| In-reply-to: <m0s67Vl-00008NC@icule> (pinard@iro.umontreal.ca) |
| Subject: Re: [pinard@iro.umontreal.ca: Internationalizing GNU: the maintainer side] |
| |
| ``GNU programs and packages should be opened to Native Language |
| Support (NLS) and, in particular, be able to write their messages |
| translated into native languages, as selected at run time by |
| environment variables''. |
| |
| I think that is too vague to be useful. I'd rather put in some |
| variant of what you sent before. But I don't have time right now |
| to fix it. |
| |
| |
| 1, answered, edited,, |
| Mail-from: From IRO.UMontreal.CA!pinard Wed May 3 00:19:10 1995 |
| Return-Path: <IRO.UMontreal.CA!pinard> |
| Received: by icule (Smail3.1.28.1 #1) |
| id m0s6Vty-0000CSC; Wed, 3 May 95 00:19 EDT |
| Received: from lagrande.iro.umontreal.ca (lagrande.IRO.UMontreal.CA [132.204.32.32]) by iros1.IRO.UMontreal.CA (8.6.9/8.6.9) with ESMTP id XAA19717 for <icule!pinard>; Tue, 2 May 1995 23:51:54 -0400 |
| Received: (from pinard@localhost) by lagrande.iro.umontreal.ca (8.6.9/8.6.9) id XAA20985 for icule!pinard; Tue, 2 May 1995 23:51:52 -0400 |
| Received: from saguenay.IRO.UMontreal.CA (saguenay32.IRO.UMontreal.CA [132.204.32.54]) by lagrande.iro.umontreal.ca (8.6.9/8.6.9) with ESMTP id XAA20983 for <pinard@lagrande.IRO.UMontreal.CA>; Tue, 2 May 1995 23:51:49 -0400 |
| Received: from nz11.rz.uni-karlsruhe.de (nz11.rz.uni-karlsruhe.de [129.13.64.7]) by saguenay.IRO.UMontreal.CA (8.6.9/8.6.9) with ESMTP id XAA12985 for <pinard@iro.umontreal.ca>; Tue, 2 May 1995 23:51:15 -0400 |
| Received: from ipd.info.uni-karlsruhe.de (actually i44ms.info.uni-karlsruhe.de) |
| by nz11.rz.uni-karlsruhe.de with SMTP (PP); |
| Wed, 3 May 1995 03:54:26 +0200 |
| Received: from i44pc2.info.uni-karlsruhe.de (i44pc2.info.uni-karlsruhe.de [129.13.171.31]) |
| by ipd.info.uni-karlsruhe.de (8.6.4/8.6.4) with SMTP id DAA00768; |
| Wed, 3 May 1995 03:57:08 +0200 |
| Message-Id: <199505030157.DAA00768@ipd.info.uni-karlsruhe.de> |
| To: "ois \"Pinard)\""@rz.uni-karlsruhe.de, meyering@comco.com (Jim Meyering), |
| eggert@twinsun.com (Paul Eggert), |
| roland@gnu.ai.mit.edu (Roland McGrath) |
| Original-To: pinard@iro.umontreal.ca (François Pinard), |
| meyering@comco.com (Jim Meyering), |
| eggert@twinsun.com (Paul Eggert), |
| roland@gnu.ai.mit.edu (Roland McGrath) |
| PP-Warning: Parse error in original version of preceding To line |
| Subject: nlsutils-0.4.2 |
| Date: Wed, 03 May 1995 03:56:24 +0200 |
| From: Ulrich Drepper <drepper@ipd.info.uni-karlsruhe.de> |
| |
| *** EOOH *** |
| To: "ois \"Pinard)\""@rz.uni-karlsruhe.de, meyering@comco.com (Jim Meyering), |
| eggert@twinsun.com (Paul Eggert), |
| roland@gnu.ai.mit.edu (Roland McGrath) |
| Original-To: pinard@iro.umontreal.ca (François Pinard), |
| meyering@comco.com (Jim Meyering), |
| eggert@twinsun.com (Paul Eggert), |
| roland@gnu.ai.mit.edu (Roland McGrath) |
| PP-Warning: Parse error in original version of preceding To line |
| Subject: nlsutils-0.4.2 |
| Date: Wed, 03 May 1995 03:56:24 +0200 |
| From: Ulrich Drepper <drepper@ipd.info.uni-karlsruhe.de> |
| |
| I tried hard to limit all external things in the libgintl directory. |
| You have to copy this, some variation of my code in aclocal.m4 |
| and acconfig.h. This should be all. |
| |
| 1, answered,, |
| Mail-from: From IRO.UMontreal.CA!pinard Thu May 4 08:22:15 1995 |
| Return-Path: <IRO.UMontreal.CA!pinard> |
| Received: by icule (Smail3.1.28.1 #1) |
| id m0s6zv4-0000CSC; Thu, 4 May 95 08:22 EDT |
| Received: from lagrande.iro.umontreal.ca (lagrande.IRO.UMontreal.CA [132.204.32.32]) by iros1.IRO.UMontreal.CA (8.6.9/8.6.9) with ESMTP id HAA19349 for <icule!pinard>; Thu, 4 May 1995 07:48:32 -0400 |
| Received: (from pinard@localhost) by lagrande.iro.umontreal.ca (8.6.9/8.6.9) id HAA24822 for icule!pinard; Thu, 4 May 1995 07:47:28 -0400 |
| Received: from saguenay.IRO.UMontreal.CA (saguenay32.IRO.UMontreal.CA [132.204.32.54]) by lagrande.iro.umontreal.ca (8.6.9/8.6.9) with ESMTP id HAA24816 for <pinard@lagrande.IRO.UMontreal.CA>; Thu, 4 May 1995 07:47:25 -0400 |
| Received: from nz11.rz.uni-karlsruhe.de (nz11.rz.uni-karlsruhe.de [129.13.64.7]) by saguenay.IRO.UMontreal.CA (8.6.9/8.6.9) with ESMTP id HAA17159 for <pinard@iro.umontreal.ca>; Thu, 4 May 1995 07:48:25 -0400 |
| Received: from ipd.info.uni-karlsruhe.de (actually i44ms.info.uni-karlsruhe.de) |
| by nz11.rz.uni-karlsruhe.de with SMTP (PP); |
| Thu, 4 May 1995 13:45:17 +0200 |
| Received: from i44pc2.info.uni-karlsruhe.de (i44pc2.info.uni-karlsruhe.de [129.13.171.31]) |
| by ipd.info.uni-karlsruhe.de (8.6.4/8.6.4) with SMTP id NAA06097 |
| for <pinard@iro.umontreal.ca>; Thu, 4 May 1995 13:48:06 +0200 |
| Message-Id: <199505041148.NAA06097@ipd.info.uni-karlsruhe.de> |
| To: pinard@IRO.UMontreal.CA |
| Subject: Re: Path to message? |
| In-Reply-To: Your message of "Thu, 4 May 95 00:45 EDT" |
| References: <m0s6snG-00008NC@icule> |
| X-Mailer: Mew beta version 0.89 on Emacs 19.28.1 |
| Mime-Version: 1.0 |
| Content-Type: Text/Plain; charset=iso-8859-1 |
| Date: Thu, 04 May 1995 13:47:46 +0200 |
| From: Ulrich Drepper <drepper@ipd.info.uni-karlsruhe.de> |
| Content-Transfer-Encoding: 8bit |
| X-Original-Encoding: quoted-printable |
| |
| *** EOOH *** |
| To: pinard@IRO.UMontreal.CA |
| Subject: Re: Path to message? |
| In-Reply-To: Your message of "Thu, 4 May 95 00:45 EDT" |
| References: <m0s6snG-00008NC@icule> |
| Mime-Version: 1.0 |
| Content-Type: Text/Plain; charset=iso-8859-1 |
| Date: Thu, 04 May 1995 13:47:46 +0200 |
| From: Ulrich Drepper <drepper@ipd.info.uni-karlsruhe.de> |
| Content-Transfer-Encoding: 8bit |
| X-Original-Encoding: quoted-printable |
| |
| From: pinard@iro.umontreal.ca (François Pinard) |
| Subject: Path to message? |
| Date: Thu, 4 May 95 00:45 EDT |
| |
| > Ulrich, always me. I do not understand that xgettext --help writes: |
| > |
| > Suchpfad ist: /usr/local/share/nls/src |
| > |
| > while /usr/local/share/locale/de/LC_MESSAGES is indeed searched. |
| > Could we solve this inconsistency? |
| > |
| |
| Not quite. /usr/local/share/locale/de/LC_MESSAGES is the path where |
| the .mo/.cat files will go. The search path (Suchpfad :) represents |
| the path to additional directories where other .po files can be found. |
| |
| I thought to use this feature for standard .po files for, say, libiberty |
| etc. Each package would have to translate it again and again but if |
| we could install this somewhere and use the -x option to exclude this |
| strings from the generation. |
| |
| Perhaps I should use a different description? |
| |
| -- Uli |
| ________--------------------------------------------------------------- |
| \ / Ulrich Drepper / Univ. at Karlsruhe, Germany / CS Dept. / IPD |
| L\inux/ email: drepper@gnu.ai.mit.edu smail: Rubensstr. 5 |
| \ / drepper@ipd.info.uni-karlsruhe.de 76149 Karlsruhe |
| \/1.2.7 ------------------------------------------- Germany -------- |
| |
| |
| 1, forwarded, edited,, |
| Mail-from: From pinard Thu May 4 15:27:13 1995 |
| Return-Path: <pinard> |
| Received: by icule (Smail3.1.28.1 #1) |
| id m0s76YH-00008NC; Thu, 4 May 95 15:27 EDT |
| Message-Id: <m0s76YH-00008NC@icule> |
| Date: Thu, 4 May 95 15:27 EDT |
| From: pinard (=?ISO-8859-1?Q?Fran=E7ois_Pinard?=) |
| To: ajc@di.uminho.pt |
| In-reply-to: <9505041601.AA20254@shiva.di.uminho.pt> (ajc@di.uminho.pt) |
| Subject: Re: tar is ready for pt |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding: 8bit |
| |
| *** EOOH *** |
| Date: Thu, 4 May 95 15:27 EDT |
| From: pinard (François Pinard) |
| To: ajc@di.uminho.pt |
| In-reply-to: <9505041601.AA20254@shiva.di.uminho.pt> (ajc@di.uminho.pt) |
| Subject: Re: tar is ready for pt |
| Mime-Version: 1.0 |
| Content-Type: text/plain; charset=ISO-8859-1 |
| Content-Transfer-Encoding: 8bit |
| |
| Even if it is not completely official yet in GNU, the format of |
| translation file is being revised, and the extension is being |
| changed from `.tt' to `.po'. This should bring the format closer |
| to one of the few standards in existence for translation files. |
| Hopefully, we think that translation files will be more easily |
| manageable afterwards. We do not want to make a religious issue of |
| this format selection, as each standard has proponents and opponents. |
| Please help us by being receptive to the format GNU uses. |
| |
| Existing `.tt' translation files are being converted to `.po' files |
| by maintainers. Translators should switch to using the `.po' format, |
| as soon as possible. This is an easy job. The `.po' translation |
| file format is quite affordable. Schematically, it looks like: |
| |
| msgid STRING-TO-TRANSLATE |
| msgstr TRANSLATED-STRING |
| |
| msgid STRING-TO-TRANSLATE |
| msgstr TRANSLATED-STRING |
| |
| msgid STRING-TO-TRANSLATE |
| msgstr TRANSLATED-STRING |
| [...] |
| |
| `msgid' and `msgstr' are kind of keywords, written at the beginning |
| of a line. Each STRING-TO-TRANSLATE or TRANSLATED-STRING respects |
| the C syntax for a character string, including the surrounding |
| quotes, escape sequences, and usual techniques for writing multi-line |
| C strings. |
| |
| Outside strings, white lines and comments may be used freely. |
| In the schema, white lines preceding the msgid lines are optional. |
| Comments start at the beginning of a line with `#' and extend until |
| the end of line. Comments written by translators should have the |
| initial `#' immediately followed by some white space. If the `#' |
| is not immediately followed by white space, this comment is most |
| likely generated and managed by specialized GNU tools. |
| |
| There is a conventional, uniform way of presenting a `.po' file, but |
| a description of this format is not yet available. It will be all |
| easy to make suggested adjustements at a later time, so do not worry |
| right now about precise conventions. Further, there are normalizing |
| tools automating conformance to a great extent, to be published soon. |
| |
| And another question: what happens when new versions of the |
| program are released, with new messages? |
| |
| Usually, most GNU packages are pretested before being released. |
| All teams of translators are made aware of localizable prereleases. |
| A special tool regenerates a `.po' file with obsolescent strings |
| commented out, and new strings put in evidence. |
| |
| Further, for those of us using GNU Emacs, a special editing mode is |
| being written for `.po' files, in which mode translators is able |
| to navigate easily in the `.po' file, find untranslated entries, |
| examine at will the context of these strings in the program sources, |
| and also observe other translations already made in other languages, |
| for the string being translated. |
| |
| Teams members should share their translations and resolve linguistic |
| or terminological issues. When they reach something satisfying, |
| the team should formally submit the translation to the package |
| maintainer for the final release. The precise formalities are not |
| organized yet, and there are many details to clear up. Some legal |
| aspects also have to be addressed, this is under study right now. |
| |
| Special means should be used for transiting translation files |
| over email. The simplest way is using GNU shar in default mode, |
| or else, uuencoding the `.po' file prior to mailing. |
| |
| -- |
| François Pinard ``Vivement GNU!'' <pinard@iro.umontreal.ca> |
| Email lpf@uunet.uu.net for info about the League for Programming Freedom. |
| |
| |
| 1, edited,, |
| Mail-from: From IRO.UMontreal.CA!pinard Thu Apr 20 16:54:03 1995 |
| Return-Path: <IRO.UMontreal.CA!pinard> |
| Received: by icule (Smail3.1.28.1 #1) |
| id m0s23Ea-0000CxC; Thu, 20 Apr 95 16:53 EDT |
| Received: from lagrande.iro.umontreal.ca (lagrande.IRO.UMontreal.CA [132.204.32.32]) by iros1.IRO.UMontreal.CA (8.6.9/8.6.9) with ESMTP id KAA12085 for <icule!pinard>; Thu, 20 Apr 1995 10:13:02 -0400 |
| Received: (from pinard@localhost) by lagrande.iro.umontreal.ca (8.6.9/8.6.9) id KAA08298 for icule!pinard; Thu, 20 Apr 1995 10:12:34 -0400 |
| Received: from saguenay.IRO.UMontreal.CA (saguenay32.IRO.UMontreal.CA [132.204.32.54]) by lagrande.iro.umontreal.ca (8.6.9/8.6.9) with ESMTP id KAA08254 for <pinard@lagrande.IRO.UMontreal.CA>; Thu, 20 Apr 1995 10:10:49 -0400 |
| Received: from nz11.rz.uni-karlsruhe.de (nz11.rz.uni-karlsruhe.de [129.13.64.7]) by saguenay.IRO.UMontreal.CA (8.6.9/8.6.9) with ESMTP id KAA20778 for <pinard@iro.umontreal.ca>; Thu, 20 Apr 1995 10:10:25 -0400 |
| Received: from ipd.info.uni-karlsruhe.de (actually i44ms.info.uni-karlsruhe.de) |
| by nz11.rz.uni-karlsruhe.de with SMTP (PP); |
| Thu, 20 Apr 1995 16:05:34 +0200 |
| Received: from i44pc2.info.uni-karlsruhe.de (i44pc2.info.uni-karlsruhe.de [129.13.171.31]) |
| by ipd.info.uni-karlsruhe.de (8.6.4/8.6.4) with SMTP id QAA28513; |
| Thu, 20 Apr 1995 16:08:10 +0200 |
| Message-Id: <199504201408.QAA28513@ipd.info.uni-karlsruhe.de> |
| To: pinard@IRO.UMontreal.CA (Francois Pinard), |
| meyering@comco.com (Jim Meyering), |
| roland@gnu.ai.mit.edu (Roland McGrath) |
| Subject: more points to discuss |
| X-Mailer: Mew beta version 0.89 on Emacs 19.28.1 |
| Mime-Version: 1.0 |
| Content-Type: Text/Plain; charset=iso-8859-1 |
| Date: Thu, 20 Apr 1995 16:08:55 +0200 |
| From: Ulrich Drepper <drepper@ipd.info.uni-karlsruhe.de> |
| Content-Transfer-Encoding: 8bit |
| X-Original-Encoding: quoted-printable |
| |
| *** EOOH *** |
| To: pinard@IRO.UMontreal.CA (Francois Pinard), |
| meyering@comco.com (Jim Meyering), |
| roland@gnu.ai.mit.edu (Roland McGrath) |
| Subject: more points to discuss |
| Mime-Version: 1.0 |
| Content-Type: Text/Plain; charset=iso-8859-1 |
| Date: Thu, 20 Apr 1995 16:08:55 +0200 |
| From: Ulrich Drepper <drepper@ipd.info.uni-karlsruhe.de> |
| Content-Transfer-Encoding: 8bit |
| X-Original-Encoding: quoted-printable |
| |
| BTW my implementation will be able to process a lot of strange situation: |
| - strings in preprocessor macros |
| - something like gettext ("jkh" "jkhlk") |
| or even |
| - gettext ("jkkjh\ |
| sdfsdf") |
| |
| 1, edited,, |
| Received: from titan.comco.com (root@titan.comco.com [198.214.63.11]) by idefix.comco.com (8.6.9/8.6.9) with ESMTP id QAA16073 for <meyering@idefix.comco.com>; Sat, 19 Nov 1994 16:03:48 -0600 |
| Received: from alcor.twinsun.com (alcor.twinsun.com [198.147.65.1]) by titan.comco.com (8.6.9/8.6.9) with ESMTP id QAA03006 for <meyering@comco.com>; Sat, 19 Nov 1994 16:04:38 -0600 |
| Received: from twinsun.com (twinsun.twinsun.com [192.54.239.2]) by alcor.twinsun.com (8.6.5/8.6.5) with SMTP id NAA19013; Sat, 19 Nov 1994 13:55:18 -0800 |
| Received: from spot.twinsun.com by twinsun.com (4.1/SMI-4.1) |
| id AA29144; Sat, 19 Nov 94 14:01:01 PST |
| Received: by spot.twinsun.com (4.1/SMI-4.1) |
| id AA02990; Sat, 19 Nov 94 14:01:00 PST |
| From: eggert@twinsun.com (Paul Eggert) |
| Message-Id: <9411192201.AA02990@spot.twinsun.com> |
| Date: 19 Nov 1994 14:00:59 -0800 |
| To: rms@gnu.ai.mit.edu (Richard Stallman) |
| Cc: meyering@comco.com, pdcruze@orac.iinet.com.au |
| Subject: Re: glocale and diffutils |
| Status: RO |
| |
| *** EOOH *** |
| From: eggert@twinsun.com (Paul Eggert) |
| Date: 19 Nov 1994 14:00:59 -0800 |
| To: rms@gnu.ai.mit.edu (Richard Stallman) |
| Cc: meyering@comco.com, pdcruze@orac.iinet.com.au |
| Subject: Re: glocale and diffutils |
| |
| The Uniforum proposal addresses this problem by partitioning message |
| catalogs into ``textdomains''. Each textdomain can be maintained |
| separately. Programs can share textdomains. Messages in different |
| textdomains cannot clash. With diffutils, for example, I would expect |
| one textdomain for diffutils programs and another for libc. The main |
| module would use the default textdomain and invoke `gettext ("No |
| newline at end of file")' just as diffutils-2.7.1 does; libc modules |
| would use a system textdomain and would invoke something like |
| `dgettext ("SYS_libc", "No such file or directory")'. |
| |
| |
| |